Communications of the ACM
Successful Software Platforms Are the Byproducts of Successful Businesses
Most startup business plans I have encountered over the past few years mention that a side-effect of the business will be to create a software platform. The virtue of the software platform is that it will be capable of supporting the current business, and also create long-term value in delivering a foundation for developers outside the company to deliver products and enhancing a virtuous cycle of improvement. The effort made to create the platform is promised to return extraordinary value to the company through some future promised licensing, advertising, subscription or other arrangement.
Generally I find that these software platforms are wishful thinking. Any substantive effort to create a general-purpose software platform before a startup is successful is wasted effort. Given the limited resources of most startups, businesses must first be successful and profitable enough to sustain themselves. Any software platform that is established prior to a company being successful is likely to miss or under-deliver on the important requirements to first make the business profitable.
Examples of successful software platforms are well-known. The Microsoft Windows platform emerged after first making a tremendously successful O/S with some useful software applications. Facebook's developer's API came after it was a leading social networking site. Amazon's web service platform was preceded by it first becoming a leader in e-commerce. However, for every successful software platform there are many more startups that built solid, high-quality platforms that disappeared when the companies folded.
Amazon's web-services API began in-house as an alternative to using CORBA for stateless services. In the process of delivering "best-of-class" customer experience, other groups within Amazon came along and improved the services and began discovering issues and tradeoffs like:
- How to you deal with software hosted as web services?
- How do you manage with API revisions?
- How do you control access to the services?
- How do you monitor, maintain, build up and tear down services?
- How do you communicate error messages? Number, strings, codes?
The 20/20 hindsight is that these internal platform debates came as a by-product of building a tremendously successful e-commerce business. We had the luxury to have these debates and deploy incrementally enhanced services and standards about how to build successful XML based web services. Amazon's efforts to expose the services to external customers also had the benefit of incremental improvements. The first versions were APIs (Application Programming Interfaces) so that Amazon Associates could get easier access to search and catalog information. It wasn't until those services became successful as a business in driving traffic to Amazon, that API's evolved to where they are today as stand-alone business and services. The key to all this was that the platform emerged from the successful business. Had Amazon invested too early in creating a web-services platform it would not have created as successful an E-commerce business.
My advice for startups today is to make sure that their current business is successful and self-sustaining before they place serious effort in building a platform.
This article was inspired by reading Chris Devore's post on the platforms that occur outside of the software business. http://crashdev.blogspot.com/2010/03/platforms-arent-just-for-developers.html
No entries found