I wrote about software ecosystems and their importance in my previous blog entry and what needs to be added to this discussion is the use of effective APIs (Application Programming Interface). This is not the first time I have emphasized the need for software vendors to focus on APIs and build solutions that can be consumed by other vendors. Software vendors that build old-fashioned “stove-pipe” solutions will be left behind and smaller and nimbler vendors creating services for others could run into amazing opportunities going forward.
I read today an excellent case study in InformationWeek of how Ancestry.com has built its platform with the idea that it has well-defined interfaces that can be consumed by Ancestry.com developers as well as ecosystem partners. However, based on the article, standardizing development and building a common architecture takes time and lots of education of the developers and architects. The article explains the misery of having to deal with APIs that have not been architected in a way that they are easy to use. At Ancestry.com, the management has decided to commit time and money on an internal development platform which in the end of the day should shorten time to market and should become a good foundation for additional software solutions in form of software product lines.
Ancestry created helps and tools to guide its developers in the process and some of these tools were things such as a wiki portal, documented development standards, a technical knowledgebase, posters and newsletters, API design training and a documentation hub.
The Ancestry.com case demonstrates not only that software vendors need to be more disciplined how software is developed. It also shows that software vendors have to turn their view on how other organizations can consume services of the platform. This could become a revenue generator for the software vendor and with some innovation built into the solution such as use of multi-tenancy in a new way, a solution can be built to service channel partners in a way that was not possible in the past.
A good example of such a solution is the solution from Ancile, a software organization with a solution that enables channel partners to include guided help (Help-as-a-Service) as part of the solution. In this scenario, Ancile uGuide provides a consumable APIs that channel partners can consume and each channel partner will get is own instance of the Ancile uGuide. This type of solution was not possible before. The solution is powered by Microsoft Azure, which have given also other benefits for Ancile as part of the technology platform.
The learning and takeaway from this blog entry should be to look around at the ecosystem that you want to serve and build a solution with effective APIs that you can provide and serve and make some money along the way.