software ecosystems: implications for strategy, business model and

Intuit Proprietary & Confidential

January 26, 2011

Software Ecosystems: Implications for Strategy, Business Model and Architecture

Jan Bosch VP, Engineering Process Professor of Software Engineering


Why Software Ecosystems?

2

system/ product

software product

lines

software ecosystems

company-driven variability: many similar

products

customer-driven variability, i.e. customer

configuration


Three Key Take-Aways

• Software ecosystems offer the next phase of growth for successful product platforms

• Software ecosystems require business, architecture process and organizational changes

• Ecosystems partners are a platform company’s ticket to broad adoption and customer stickiness

3


Overview

• Preamble – Vem är jag? Wie ben ik? Who am I? – Introducing Intuit

• Software Ecosystems – Setting context: Trends in software – Software ecosystems: Why, what, how – Examples – Lessons learned

• Conclusion

4


From Research to Industry

Professor of software engineering (RuG, Netherlands) (BIT, Sweden)

Academia (+ consulting)

Head of research lab (Nokia, Finland)

Industrial research

Engineering Process (Intuit, USA)

Industrial development

?


Who We Are…

A leading provider of business and financial management solutions

Intuit Company Information

•  Founded in 1983

•  FY 2010 revenue of $3.5 billion

•  Intuit is traded on the NASDAQ: INTU

• Employs around ~8,000 people

• Major offices across the U.S. and in Canada and the United Kingdom

• More than 40 million people use our QuickBooks, Payroll, Payments, TurboTax, Digital Insight and Quicken products and services.


Revolutionizing People’s Lives… Solving Their Important Problems…

Creating Innovative Products and Services


Proven formula: lots of delighted customers…

Help small businesses be 20% more profitable… Customers revenues ~20% of U.S. GDP, pay 1 in 12 American workers

Help people get the maximum tax refund…

$33B in tax refunds, 1 out of every 3

tax returns e-filed

Help families find $1,000 annually… $400M in

consumer savings

Help accountants be 20% more productive today…

Serve half of all accounting firms

Improving

Lives 40M

Improve FI profit per customer by 20%…

IB customers equal to the 5th largest U.S. bank

8


Our Ecosystem: Millions of Customers and Developers

250,000 Accountants

1,600 Financial Institutions

serving

9 million End Customers

7 million Small Business

Users

12 million Consumer

Quicken Users

75,000 Developers

19 million TurboTax

Users


Markets and Opportunities

10

Small Business: QuickBooks

Plus Payroll & Payments

Tax Health Care

Global

Financial Institutions


Fortune Top 100 Places to Work


Most Admired: Software Industry

2004 2005 2006 2007 2008 2009 2010

7 Years in a row


Game Plan to Win: Connected Services Intuit’s focus is…

And capitalizing on three significant market trends…

By creating and acquiring…


Overview



• Conclusion

14


Trends in Software

• Speed •  Innovation • Architecture & Scale


Need for Speed in R&D – An Example

• Company X: R&D is 10% of revenue, e.g. 100M$ for a 1B$ product • New product development cycle: 12 months

• Alternative 1: improve efficiency of development with 10% – 10 M$ reduction in development cost

• Alternative 2: reduce development cycle with 10% – 100M$ add to top line revenue (product starts to sell 1.2 months earlier)

No efficiency improvement will outperform cycle time reduction

Intuit Proprietary & Confidential 17

yearly cycles

roadmapping & req. mgmt

pre-integrated products

build & maintain

meetings

global R&D

Traditional Software Engineering


yearly cycles

roadmapping & req. mgmt

pre-integrated products

build & maintain

meetings

global R&D

software product lines global software development

software ecosystems

causing

unacceptable complexity and coordination cost

Traditional Software Engineering


Web 2.0 Rules to SW Development (1/2)

19 Focus on one thing: Minimize Dependencies

Team size •  3x3 = 3 persons x 3 months (Google) •  2 pizza rule (Amazon) •  Principle: What is required is a team, where the roles are defined and

each member has the right skill for that role, and following a lean, agile, method — all focused on the customer.

Release cycle •  Weeks, not months •  Continuous deployment •  Principle: short cycles are key for agility, speed and decoupling Architecture •  3 API rule •  Mash-ups and web services •  Principle: architecture provides simplicity, compositionality and is

designed in parallel with software development


Web 2.0 Rules to SW Development (2/2)

Requirements and Roadmapping • Each team (3 persons) announces what they intend to release • Some (QA) requirements are shared across the board, e.g. performance, latency, etc. • Principle: the cost of overlapping teams is much lower than the cost of synchronized, planned roadmaps and plans

Process • CMMi and other process maturity approaches address the symptoms, not the root cause • Control is a very expensive illusion causing LOTS of inefficiency in the system • Principle: Architecture not process should manage coordination and alignment

20 From the Cathedral to the Bazaar


Towards Composition …

21

teams are self-selected (2 pizza rule)

components are backward

compatible and negotiate interfaces

architecture prioritizes simplicity

(3 API rule)

architectural compositionality

teams can be external (ecosystem)


Classification – Five Approaches

traditional product development

compositional development

traditional development

release groupings

release trains

independent deployment

open ecosystem


Trends in Software



What Do These Product Have in Common?


Innovation

New organic source revenue

Quantity of ideas

(at bats)

Quality of ideas

(right pitch)

Execution against ideas

(mechanics)

ƒ

New organic revenues…

… which are outputs from how we innovate

1

… are driven by 3 factors…

Ideas

Approach

People

Priorities

ƒ


Experiment System: Data, not Opinions

• Goal: increase the number of experiments (with customers) with an order of magnitude to ultimately accelerate organic growth

1.  Prioritizing/filtering most promising ideas 2.  Rapid, low cost way to test hypotheses with customers –  With business units –  With external partners –  In the center

3.  Assure transition of successful experiments into funded H3s

26

Ideas are dime a dozen; only validated concepts count!

Learning: the company running the most experiments against the lowest cost per experiment wins


Trends in Software



Role of Software Architecture

• Simplify, Simplify, Simplify

• Decoupling – Components – Teams – Organizations

•  Lean and agile at scale

28


Simplify, Simplify, Simplify

• Each architectural design decision adds design rules and constraints that cause complexity

•  Insist on simplicity (3 APIs rule)

• How – Push down in the stack – Hide – Automate – Redesign

29


Decouple Teams and Organizations

•  Interconnected teams and organizations asymptotically reduce productivity to zero

• Decouple teams and make sure no continuous interaction is needed

• How – Continuous deployment – No versions – No concurrent development

30


Lean and Agile at Scale

• Achieving lean & agile in large, legacy systems with large R&D organization considered an oxymoron

• Google, Amazon and Intuit are examples that it can be done

• How – Small teams – Short cycles – Direct customer connection – Clear success metrics

31


Overview



• Conclusion

32


Towards Web 3.0

“My prediction would be that Web 3.0 will ultimately been seen as applications which are pieced together. There are a number of characteristics: the applications are relatively small, the data is in

the cloud, the applications can run on any device, PC or mobile phone, the applications are very fast and they're very customizable. Furthermore, the applications are distributed virally: literally by

social networks, by email. You won't go to the store and purchase them... That's a very different

application model than we've ever seen in computing.”—Eric Schmidt


ecosystem

Consumer Consumer

Developer

Small Business

Big Business

Intuit

Developer

Intuit Intuit

Intuit

Expert

Expert

Expert

Big Business

Developer

Intuit

Small Business

Small Business

Developer

Developer

Big Business Expert

Small Business

Small Business

Consumer

Consumer

Consumer

Intuit Big Business

Expert

Small Business

people

ecosystem >> examples

people

ecosystem >> Intuit examples

E-‐mail Contact Manager Sparta


From Pre-Packaged Offerings to Customer-Assembled

platform

application

traditional

componentized platform

offering

contemporary

ecosystem platform

each customer his/her offering

the vision

3rd party asset

prosumer asset


What is an Ecosystem?

• An ecosystem is a natural unit consisting of all plants, animals and micro-organisms (biotic factors) in an area functioning together with all of the non-living physical (abiotic) factors of the environment. •  "Any unit that includes all of the organisms (ie: the "community") in a given area interacting with the physical environment so that a flow of energy leads to clearly defined trophic structure, biotic diversity, and material cycles (ie: exchange of materials between living and nonliving parts) within the system is an ecosystem.“

(source: Wikipedia)


Software Ecosystem?

• Here’s a try: A software ecosystem consists of a software platform, a set of internal and external developers and a community of domain experts in service to a community of users that compose relevant solution elements to satisfy their needs. • Some more detail: – Software platform: A hierarchical set of shared software

components providing functionality that is required and common for the developers constructing solutions on top of the platform.

– Evolution: Over time, the functionality in the ecosystem commoditizes and flows from unique solutions to the platform.

– Developers: Although internal and external developers use the platform differently, the platform often allows developers to build on top of each other’s results.

– Composition: Users are able to compose their own solutions by selecting various elements into a configuration that suits their needs optimally.


Why Software Ecosystems?

•  Increase value of the core offering to existing users •  Increase attractiveness for new users •  Increase “stickiness” of the application platform, i.e. it is harder to change the application platform • Accelerate innovation through open innovation in the ecosystem • Collaborate with partners in the ecosystems to share cost of innovation • Platformize functionality developed by partners in the ecosystem (once success has been proven) • Decrease TCO for commoditizing functionality by sharing the maintenance with ecosystem partners

40


Taxonomy of Software Ecosystems

41


Operating System-centric

Characteristics • Domain independent •  Installed for every device •  Focused on stand-alone applications •  Focus on development tools for developers Success factors • Number and relevance of applications built • OS needs to evolve constantly • Number of customers Challenges • Variation in underlying hardware configurations • No new Microsoft syndrome

42


Application-centric

Characteristics • Starts from a successful application • Platform company focuses on customer ease • Application developers extend the basic application • Deep integration for data, workflow and UX Success factors • Number of customers • Simplified contribution of 3rd party extensions • Mechanisms for extending data models and workflows • Monetization mechanism for 3rd party developers Challenges • Product versus platform strategy • Viable business model for 3rd party developers

43


End-User Programming

Characteristics •  Focused on domain experts without a SE degree • Typically use a pipes-and-filter architectural style • Creative composition, rather than new functionality Success factors • Value of a unique, user-specific solutions • Effective sharing of solutions between users Challenges •  Intuitive model of application domain with low complexity • Domain stability and DSL maintenance efforts

44


Questions One Might Ask …

customer data

Intuit ecosystem platform

DAAA Data Ecosystem developer data

Intuit domain service






Eco dev. domain service



Eco dev. joblet

Eco dev. joblet

Eco dev. joblet

Intuit ecosystem portal

Eco dev. joblet

Eco dev. joblet

Eco dev. joblet

Intuit joblet

Intuit joblet

Intuit joblet

Intuit joblet

Intuit joblet

other portals

Eco dev. joblet

Eco dev. joblet

other platforms

Eco dev. joblet

Intuit joblet

desktop apps

Can ecosystem developers store data

outside Intuit’s repository?

Are other platforms allowed in the ecosystem

and, if so, are these integrated?

Can ecosystem developers access

aggregated customer (DAAA) data?

Can ecosystem developers host their solutions outside

Intuit’s hosting infrastructure?

Does Intuit provide access to data defined by ecosystem developers to

other ecosystem developers

Does Intuit provide a development

environment for ecosystem developers?

How do we manage variability & configurability

for customers?

What mechanisms exist to insert ecosystem domain services into other

domain service workflows?

How do we maintain consistent user experience

between Intuit and ecosystem joblets?

Do ecosystem joblets have the same access to domain services

and data as Intuit joblets?

Do we sync desktop and cloud data real-time or

batch-wise?

How do we manage dynamic composition of joblets by

customers?

How rich is the set of basic services provided by the platform, e.g. authentication, authorization, monitoring, billing, search, marketing, etc.

Do we charge developers for developing and hosting in our ecosystem (beyond revenue

share)?


Assessing Existing Ecosystem Platforms


Software Ecosystem •  Customer

–  How do we manage variability & configurability for customers? –  How do we maintain consistent user experience between Intuit and ecosystem joblets? –  How do we manage dynamic composition of joblets by customers?

•  Ecosystem Developer –  Do ecosystem joblets have the same access to domain services and data as Intuit joblets? –  What mechanisms exist to insert ecosystem domain services into other domain service workflows? –  Can ecosystem developers host their solutions outside Intuit’s hosting infrastructure? –  Does Intuit provide access to data defined by ecosystem developers to other ecosystem developers –  Does Intuit provide a development environment for ecosystem developers? –  Can ecosystem developers store data outside Intuit’s repository? –  Can ecosystem developers access aggregated customer (DAAA) data? –  Do we charge developers for developing and hosting in our ecosystem (beyond revenue share)?

•  Platform Architecture –  How rich is the set of basic services provided by the platform, e.g. authentication, authorization,

monitoring, billing, search, marketing, etc. –  Do we sync desktop and cloud data real-time or batch-wise? –  Are other platforms allowed in the ecosystem and, if so, are these integrated?


Transitioning to a Software Ecosystem

• Selecting the software ecosystem type

48

(Web) OS centric ecosystems •  OS (Windows, Google Android) •  Open-source (LAMP) •  Web technology (SOAP, Flex, Silverlight) •  Web hosting platform (Coghead, Google AppEngine, Ning) •  Web mashup (PopFly, Google Mashup, Yahoo! Pipes)

Application centric ecosystems •  Enterprise solutions (SAP) •  Desktop application suite (MS Office, QuickBooks) •  Web applications (SalesForce, eBay, Amazon, Facebook)

Preferred because: •  apps bring customers •  highest in value chain •  established success builds trust

Not preferred because: •  no next Microsoft •  commoditized functionality •  no success yet; risky investment


Transitioning to a Software Ecosystem

• Opening up the platform – Directed versus undirected partner and application selection – Tiers of developers • Internal developers • Strategic developers • Undirected developers • ISVs

• Building developer relationship – Customer relationship – Evolving the platform – Long term roadmap

49


Implications for Software Engineering

• Coordination mechanisms – Process “human-centric” coordination does not work – From integration-oriented to composition-oriented – From process- to architecture-based coordination – From centralized roadmapping and requirements mgmt to

decentralized and bottom-up – SCM and QA focus on backward compatibility and compositionality

• Engineering agility – Risk: frequency of platform releases decreases

• Product composition – End to end quality in customer-performed product composition – User experience

50


eco

syst

em

pla

tfo

rm

Intuit Ecosystem: One Perspective

World of opportunities: jobs to be supported and automated

app app app

app

non-differentiating, generic functionality, e.g. subscription, billing, entitlement, etc.

domain functionality, e.g. accounting, customer, employee, payments, etc.

compositional applications, e.g. accounting, customer, employee, payments, etc.

UX

, wo

rkflo

w &

data

co

mp

ositio

n

bre

ad

th o

f ap

plica

bilit

y

valu

e t

o in

div

idu

al u

ser

app app app

app app app app

app app

app

app app app

experiment & innovate

pla

tfo

rmiz

e

maintain sustainable competitive advantage

com

mo

dit

ize

minimize TCO through putting in OSS or replace with COTS


Overview



• Conclusion

52


SalesForce •  Classification: Web application centric ecosystem •  Description: Salesforce.com is the worldwide leader in on-demand customer relationship management

(CRM) services. •  Customer:

–  Configurability: Developers can build significant configurability through meta-data. –  Consistent UX: Not enforced, but basic platform provides tabs and VisualForce tool typically resulting

in similar look and feel –  Dynamic composition: Customers can dynamically add applications; these applications have access

to SalesForce data for that customer and are integrated in the existing configuration of the customer.

•  Ecosystem developer: –  Equal access: Not fully, but ecosystem developers have significant access. –  Behavioral integration: Mostly independent applications. –  Hosting alternatives: Not supported. –  3rd party data access: Supported through web service interfaces. –  Developer environment: Eclipse extension, .Net 2.0 explorer and a Flex/Air toolkit; support for many

programming languages. –  External data storage: Supported through web service interfaces. –  DAAA access: Not supported. –  Charges: Consulting, registration fees, etc.

•  Platform architecture: –  Platform services: Rich –  Desktop application sync: Not applicable. –  External ecosystems: Supports integration into existing enterprise applications, exposing an

application as a web service externally and access to external web services from within SalesForce


Amazon •  Classification: Web application centric ecosystem •  Description: Amazon Web Services (AWS) has provided companies of all sizes with an infrastructure

web services platform in the cloud. Combined with it’s webstore and fulfillment service, it provides a platform for merchants. 1

•  Customer: –  Configurability: Through authentication, user-specific content can be presented, but there is no

other support. –  Consistent UX: Provided for non-expert developers through configuration tools; no support for

expert developers. –  Dynamic composition: No support; intended for building independent applications that use Amazon

webstore infrastructure. •  Ecosystem developer:

–  Equal access: No evidence to the contrary, but likely to assume that this is not the case. –  Behavioral integration: Integration primarily through data models; not in the workflow. –  Hosting alternatives: Explicitly intended for hosting by Amazon. –  3rd party data access: Not explicitly supported. –  Developer environment: No development tools are provided. –  External data storage: Explicitly intended for data storage by Amazon. –  DAAA access: N/A –  Charges: Computing, storage, message queues, payment and fulfillment services are priced

separately. Typically a use-based or per-transaction fee is used. •  Platform architecture:

–  Platform services: Very rich set of services; basically everything needed for running a webstore. –  Desktop application sync: N/A –  External ecosystems: Not explicitly supported.

1 Amazon also provides a web hosting platform, but in this study we focus on the web application part.


Facebook •  Classification: Web application centric ecosystem •  Description: Facebook is a social networking website where users can join networks organized by city,

workplace, school, and region to connect and interact with other people. People can also add friends and send them messages, and update their personal profile to notify friends about themselves.

•  Customer: –  Configurability: Developer can obtain the user ID and configure their application accordingly. –  Consistent UX: FMBL helps in creating user interfaces, but there is no explicit support. –  Dynamic composition: Applications can be added dynamically, but application integration is not

supported. •  Ecosystem developer:

–  Equal access: No evidence to the contrary. –  Behavioral integration: Integration primarily takes place via Facebook defined data models; not

behavioural. –  Hosting alternatives: Facebook does not offer hosting and assumes the application runs on an

external server. –  3rd party data access: Can be built, but little explicit support. –  Developer environment: Only limited test tools are provided. –  External data storage: Hosting and data storage takes place outside Facebook’s servers. –  DAAA access: No possibilities. –  Charges: Developers make money by advertisement, sponsors, subscriptions, product sales;

Facebook through verification program. •  Platform architecture:

–  Platform services: Implicit authentication, –  Desktop application sync: N/A. –  External ecosystems: Facebook is offering is social network software to developers for incorporation

in their own site.


Android

•  Classification: Operating system centric ecosystems •  Description: An open and free software stack for mobile devices including an operating system (Linux),

middleware and key applications. •  Customer:

–  Configurability: Limited (preferences). –  Consistent UX: Platform only provides a UI framework. –  Dynamic composition: Only SQLite database and notion of “Content Provider” to share data between

applications. Non-technical users can’t do this themselves. •  Ecosystem developer:

–  Equal access: 3rd party applications are on equal footing with basic applications. –  Behavioral integration: No platform support for intra-application workflow extension. –  Hosting alternatives: Installed at each device. –  3rd party data access: 3rd party applications has to explicitly provide access to data via a “Content

Provider”. –  Developer environment: SDK for Eclipse, emulator, UI tools, debug tools, etc. –  External data storage: There is network support for sockets and HTTP. –  DAAA access: N/A. –  Charges: None.

•  Platform architecture: –  Platform services: Linux services –  Desktop application sync: N/A. –  External ecosystems: N/A.


Google AppEngine

•  Classification: Web hosting platform centric ecosystems •  Description: Run your web applications on Google's infrastructure •  Customer:

–  Configurability: Only user identity is provided –  Consistent UX: No support. –  Dynamic composition: No support.

•  Ecosystem developer: –  Equal access: Apps can access the data from the user’s Google Base, Calendar, Contacts,

Documents, Picasa Web Albums, Spreadsheets, YouTube –  Behavioral integration: No support. –  Hosting alternatives: No support. –  3rd party data access: No support. –  Developer environment: Only Python support, no development tools. –  External data storage: No support. –  DAAA access: No support; access to Google Base is provided. –  Charges: Free for small usage, Amazon-like fee for significant use.

•  Platform architecture: –  Platform services: Authentication, monitoring, search (generic Google search), data store, email. –  Desktop application sync: No support. –  External ecosystems: No support.


eBay

•  Classification: Web application centric ecosystem •  Description: “eBay is the world's largest online community of buyers and sellers” •  Customer:

–  Configurability: No explicit support in the platform. –  Consistent UX: Platform works to a significant extent as an OOFW, requiring developers to define

callback functions. –  Dynamic composition: No support; intended for building independent applications that use the eBay

infrastructure. •  Ecosystem developer:

–  Equal access: Ecosystem developers are extending a OOFW-based platform, resulting in an inherent inequality.

–  Behavioral integration: Deep integration possible, but only at the places where the framework allows for it.

–  Hosting alternatives: Supports external hosting. –  3rd party data access: Can be built, but little explicit support. –  Developer environment: Rich (Java, AJAX, Flex, PHP, Perl, Python, C#, .NET, etc.), but no tools

provided. –  External data storage: Can be built, but little explicit support. –  DAAA access: Only metrics for own application. –  Charges: For support and marketing.

•  Platform architecture: –  Platform services: Authentication, rich API set. –  Desktop application sync: N/A. –  External ecosystems: Not supported.


LongJump •  Classification: Web application centric ecosystem •  Description: LongJump is an on-demand platform for creating and delivering business applications to

manage data, streamline collaborative processes and provide actionable analysis. The intention is to allow users to create applications without coding, i.e. it is intended for non-expert developers.

•  Customer: –  Configurability: Development suite allows for configuration and editing of standard LongJump

components. –  Consistent UX: The development suite causes consistency of the UX. –  Dynamic composition: No support in the platform.

•  Ecosystem developer: –  Equal access: Yes (no evidence to the contrary and not in the interest of the company) –  Behavioral integration: Only through data models, not at behavioral level. –  Hosting alternatives: LongJump explicitly assumes hosting responsibility. –  3rd party data access: No explicit support in the platform. –  Developer environment: Java development suite is provided. –  External data storage: No explicit support in the platform. –  DAAA access: No explicit support in the platform. –  Charges: Revenue share.

•  Platform architecture: –  Platform services: Rich set of administrative services, data processing services and presentation

services –  Desktop application sync: No, except for some Outlook integration. –  External ecosystems: No support.


Ning

•  Classification: Web application platform ecosystem •  Description: Ning provides a platform for easily creating social networks •  Customer:

–  Configurability: Provides rich baseline for social network site with lots of configurability for developers.

–  Consistent UX: By virtue of baseline, not enforced or desired by Ning. –  Dynamic composition: Architecture supports common and open database access to all widgets.

•  Ecosystem developer: –  Equal access: Ning was explicitly designed to be open to 3rd party developers and provides, by and

large, equal access. –  Behavioral integration: Basic building block is the widget. Intra-widget workflow integration is

difficult. –  Hosting alternatives: Ning assumes hosting of widgets within its own hosting infrastructure. –  3rd party data access: Allowed for through Ning Content Store, but no explicit infrastructure. –  Developer environment: None. –  External data storage: Allowed for through Ning Content Store, but no explicit infrastructure. –  DAAA access: Simple roll-up mechanisms available. –  Charges: Advertisement based, but paid-for package removes ads.

•  Platform architecture: –  Platform services: Authentication, data store, search, version management and some smaller

services. –  Desktop application sync: No support (not applicable either). –  External ecosystems: Allowed, but no specific support.


PopFly

•  Classification: Web mashup centric ecosystem •  Description: Microsoft Popfly provides an easy way to build and share mashups, gadgets, games, Web

pages, and applications. •  Customer:

–  Configurability: Each PopFly block provides some or many configuration items. –  Consistent UX: UI framework encourages similar interaction between mashups, games, etc. –  Dynamic composition: Basically, pipes-and-filters architecture underlies the composition model, but

composition takes place at run-time. Users can build their own mashups relatively easily. •  Ecosystem developer:

–  Equal access: There seems to be equal access by all parties. –  Behavioral integration: Difficult to change “in-block” behavior, except through predefined settings. –  Hosting alternatives: Developer is free to host solution at any place of choice. –  3rd party data access: Datasource blocks wrap 3rd party data sources. –  Developer environment: PopFly plugin in Visual Web Developer –  External data storage: PopFly blocks can read from and write data to other data stores. –  DAAA access: N/A –  Charges: No direct charges.

•  Platform architecture: –  Platform services: Limited features at this point in time. –  Desktop application sync: N/A. –  External ecosystems: PopFly can be used to build applications for other ecosystems, e.g. Facebook


Overview



• Conclusion

62


Overview

• Customers first; developers second • Platform should be in the middle of every transaction • Proactively incorporate “horizontalizing” / commoditizing functionality and data models into the platform

• Communicate clear, multi-year roadmaps to avoid unintentional heads-on composition between platform and external developers

• Model platform as the next computing platform abstraction layer

• OS ecosystems get disrupted from the outside, application ecosystems from the inside

• Other players are drifting into the small business space, e.g. SAP, Microsoft, IBM.


Customers First; Developers Second

•  Description: Successful ecosystems offer value to customers and achieve their first wave of success through customer adoption. Converting the application into a platform for external developers creates a second wave of success.

•  Rationale: – Developers are interested in reaching lots of customers, either for financial

or prestige reasons. Technology is of secondary importance. – Customer success means the platform company has a durable competitive

advantage that can be defended over time, increasing attractiveness for external developers

•  Examples – SalesForce: First CRM application (1999-2004), then 3rd party apps (2005) –  Facebook: First social app (2004-2006), then 3rd party apps (2007) –  eBay: First auction app (1995- 2006) then 3rd party apps (2007) – Amazon: retail channel (1995-2000), platform for retailers (2001) –  Failure example: Open source competitors of Quicken


Customers First; Developers Second

•  Implications – Existing customer rich product lines are ticket to entry – A seamless desktop / web / mobile(?) integration will be crucial for at least

a decade – Customers adoption of our core web services (offerings) is critical for

developer involvement


Platform in the Transaction Stream

•  Description: The platform needs to be an integral part of every activity/transaction in the ecosystem

•  Rationale: –  The more activity occurs outside the core platform, the less the platform

company is required; over time the competitive advantage erodes. – Exercising control over the transaction stream enables better security and

trust. – Monetization often applies use-based or transaction-slice based

mechanisms.

•  Examples – SalesForce and several other ecosystems host 3rd party solutions,

presumably to maintain a control point in the transaction stream. –  Facebook, even though it does not host 3rd party solutions, still has

mechanisms to shut down these solutions. – All application-centric ecosystems offer ways for 3rd party developers to

extend the platform functionality but lack support for 3rd party developers to build on each others solutions. This is believed to be largely intentional.


Platform in the Transaction Stream

•  Implications – Minimize interaction outside (bypassing) platform – Allow for storing application specific data inside hosting platform – Host solutions inside hosting platform – Offer a set of “connecting services” that take the burden from developers –  Facilitate inclusion into the workflow to minimize the need to replicate the

workflow outside the platform


Proactively Extend Platform Functionality •  Description: Platform functionality commoditizes constantly and for the

platform to continue to be differentiating, it needs to incorporate new functionality continuously. Also, push functionality down into the next computing platform layer.

•  Rationale: – New computing platforms at higher abstraction levels are constantly created

and if the platform would need “move up” in the stack or it would lose its relevance over time.

–  Ignoring to push functionality out will bloat the platform, bind more and more engineering staff to non-differentiating work and may disconnect the platform from the rest of the industry.

•  Examples –  For more than a decade, Microsoft Windows has been incorporating functionality

originally thought of as application functionality, including network connectivity, audio and video solutions, accessibility, GUI frameworks, browser, etc. This has been critical to ward off low-end disruptions like Linux.

– SalesForce explicitly publishes a multi-year roadmap to allow ecosystem developers to “get out of the way” before the platform moves in.

–  Facebook recently replicated a feature of a popular Slide application called Top Friends (http://news.cnet.com/8301-1023_3-10021407-93.html)


Proactively Extend Platform Functionality

•  Implications –  The platform needs to consist of domain data models, functionality and

user interface solutions. – Constantly scan adoption of solutions developed by external developers

and look for domains where much revenue is generated; When the first signs of consolidation appear, incorporate the functionality (and possibly one of the companies) and nudge/drive other solutions out of the ecosystem.

–  Proactively re-architect the platform to align with maturing COTS solutions and swap when the cost of maintaining the internal component exceeds the cost of the external component.

– Consider open-sourcing commoditized functionality to drive adoption of functionality and share maintenance cost.


Communicate Clear, Multi-Year Roadmaps •  Description: The platform company needs to communicate clear, long-

term roadmaps of functionality that it intends to release as part of the platform

•  Rationale: – External developers can avoid entering into head-to-head competition with the

platform company (where they tend to be at a disadvantage). –  It warns external developers to leave an area of functionality that the platform

intends to incorporate and to move upstream early, minimizing disruption. –  The platform company and external developers can align the release of new

functionality to drive adoption of new solutions.

•  Examples – SalesForce publishes a platform roadmap. See for example:

http://www.slideshare.net/dreamforce2006/salesforce-prm-partner-edition-roadmap/

–  eBay example: http://pics.ebaystatic.com/aw/pics/devcon/2008/pdf/post/Trachtenberg_eBay_Product_Roadmap_v04.pdf

– AIM Analyst Laurie McCabe: importance of “open, neutral platform for developers and partners”


Communicate Clear, Multi-Year Roadmaps

•  Implications – Develop internal capability for multi-year roadmapping (most 3 year

planning tends to restart every year) –  Publish an updated roadmap concerning data models, domain services,

user experience solutions and compositionality with each release of the platform; guarantee that external communication is aligned with internal knowledge.

– Actively work with developers in functionality areas that you intend to draw into the ecosystem platform


Next Computing Platform Abstraction Layer

•  Description: Especially for application-centric ecosystems, it is important to present the platform as a computing abstraction layer that hides the platforms below it.

•  Rationale: –  It enables the platform to be part of as many activities/transactions in the

ecosystem as possible. –  It provides leverage over technology providers.

•  Examples – Google Chrome aims to define the web computing platform that minimizes

the ability of the underlying operating system to be differentiating. In that sense it aims to decrease the value of Microsoft Windows as a computing platform.

– SalesForce presents itself as the platform for CRM applications, not as a platform.

– Ning presents itself as the platform for social networks and social applications.


Next Computing Platform Abstraction Layer

•  Implications – Use dominance in one device category, e.g. the desktop, to claim a similar

dominance in other device categories – e.g. Intuit aims to provide the platform for small businesses (not just another platform)

– Design the platform such that external developers only use the platform, no external technologies or solutions

–  Prioritize stability of the platform to the highest extent possible; platforms provide backward compatibility

– Need to move fast, partner where appropriate and establish our “shaping view” for our ecosystem


Inside versus Outside Disruption

•  Description: OS ecosystems get disrupted from the outside. Application ecosystems may be disrupted from the inside.

•  Rationale: –  The only way to disrupt an operating system ecosystem is by providing a

better operating system, typically at the next layer of abstraction – Application ecosystems are where customers have their data, their

business processes, etc. Disruption can occur by “wrestling” the involvement in the transaction stream from the original platform company.

– Ecosystem developers view us as part of their ecosystem and hence aim to deploy their solution in multiple contexts. E.g. a typical IDN developer will deploy a solution standalone, integrated with Quickbooks or integrated with PeachTree.

•  Examples –  Linux and Mac OS X are looking to disrupt the operating system market

from the outside. – No application ecosystem has been around long enough to provide a good

example. Bill pay functionality in Quicken became disruptive to Quicken when ecosystem participants (FIs) provided it as a point solution on their property.


Inside versus Outside Disruption

•  Implications – Explicitly scan for areas in the ecosystem where disruptors seek to offer

solutions that can live in any platform. – Deploy “early warning mechanism” for partners that aim to draw customers

to another platform environment or independent from any higher level platform.

– Consider proactive acquisition of disruptors or neutralize otherwise.


Other Implications

•  Facilitating workflow integration between the platform and ecosystem developer solutions provides an important enabler and differentiator • Some ecosystems (especially mashup centric) provide key focus on non-technical people as content creators, e.g. creation of mashups. Support an approach that allows end-customers to create their own compositions • There is significant difference between ecosystems wrt the amount and complexity of code that needs to be written by ecosystem developers – simplicity helps adoption •  Inclusion of ecosystem developer solutions in other ecosystems is only supported by PopFly – how important is broad deployability of solutions for ecosystem developers? • Broad variation of developer tool and language support between ecosystems – little support needed in early tests


Open Issues

• Collecting information on the business success of the ecosystem part of the companies outlined in this study is difficult as little or no data is available. – Is the platform company receiving significant revenue from the

ecosystem? – Do the ecosystem developers have a viable business case and

“how steep is the pyramid”

• More clarity is needed to more precisely define what customer problems or jobs can be more effectively solved by an ecosystem, compared to in-house development.


Overview



• Conclusion

78


Conclusion: Why Software Ecosystems?

79

system/ product

software product

lines

software ecosystems

company-driven variability: many similar

products

customer-driven variability, i.e. customer

configuration


Three Key Take-Aways

• Software ecosystems offer the next phase of growth for successful product platforms

• Software ecosystems require business, architecture process and organizational changes

• Ecosystems partners are a platform company’s ticket to broad adoption and customer stickiness

80


THANK YOU

Mount Shasta (CA) - 4,322m, July 2009