Back in 2005, Fotango launched the world's first Platform as a Service (known as Zimki) though we called it Framework as a Service in those days (consultants hadn't yet re-invented the term). It provided basic component services (for storage, messaging, templates, billing etc), a development environment using isolated containers, a single language - Javascript - which was used to write applications both front and back-end plus exposure of the entire environment through APIs.
Zimki was based upon user need and the idea of removing all the unnecessary tasks behind development (known as yak shaving). It grew very rapidly and then it was shutdown in its prime as the parent company was advised that this was not the future. Today, Cloud Foundry follows identically the same path and with much success.
The lesson of this story was "Don't listen to big name strategy consultancy firms, they know less than you do" - unfortunately this is a lesson which we continuously fail to learn despite my best efforts.
Fotango was a very profitable company at the time and had it continued the path then there was every chance that Canon would have ended up a major player in Cloud Computing. The upside of this story is that I went on to help nudge Canonical into the cloud in 2008, wrote the "Better for less" paper in 2009/2010 which had a minor influence in helping nudge others and without this, I probably would never have got around to teaching other organisations how to map. This has started to turn out to be very useful indeed, especially in getting organisations to think strategically and remove their dependence upon overpriced strategy consultants. You can guess, I don't like strategy consultancy firms and the endless meme copying they encourage.
The most interesting part of Zimki was the play. It was based upon an understanding of the landscape (through mapping) and use of this situational awareness to navigate a future path.
The key elements of the play were ...
1) Build a highly industrialised platform with component services to remove all 'yak shaving' involved in the activity e.g. in developing an application. We used to have 'Pre Shaved Yak' T-Shirts to help emphasise this point. The underlying elements of the platform were used in many of Fotango services which themselves had millions of users. The use of component services was based upon limitation of choice, an essential ingredient for a platform unless you want to create a sprawl generator. To give you an idea of speed, the platform was so advanced in 2006 that you could build from scratch and release relatively complex systems in a single day. Nothing came close.
2) Expose all elements of the platform through APIs. The entire user interface of Zimki communicated through the same publicly available APIs. This was essential in order to create a testing service which demonstrated that one installation of Zimki was the equivalent of another and hence allow for portability between multiple installations. It's worth emphasising that there was a vast range of component services all exposed through APIs.
3) Open source the entire platform to enable competitors to provide a Zimki service. A key part of this was to use a trademarked image (the Zimki provider) to distinguish between community efforts and providers complying to the testing service (which ensured switching). The mix of open source, testing service and trademarked image was essential for creating a competitive marketplace without lock-in and avoiding a collective prisoner dilemma. We knew companies would have inertia to this change and they would attempt to apply product mentality to what was a utility world. The plan was to announce the open sourcing at OSCON in 2007, I had a keynote to discuss this but alas that plan was scuppered at the very last moment.
4) Use the open approach to further industrialise the space. Exploit any ecosystem building on top of the services to identify new opportunities and components for industrialisation. A key element of any platform is not just the ecosystem of companies building within the platform but the ecosystem of companies building on top of it by including the APIs in their products or services.
5) Co-opt anything of use. We had guessed in 2005 that someone would make an IaaS play (though back then we called it Hardware as a Service, those meme re-inventing consultants hadn't turned up yet). Turned out it was Amazon in 2006 and so we quickly co-opted it for the underlying infrastructure. With no-one else playing in this platform space, there was nothing else for us to really co-opt. We were first.
6) Build a business based upon a competitive market with operational efficiency rather than lock-in and feature differentiation. There were around 13 different business models we identified, we focused on a few and there was plenty to go around by building upon this idea of a 'small piece of a big pie'.
In the end, despite its growth, Zimki was closed down and the open sourcing stopped. I did however give a talk at OSCON in 2007 covering commoditisation (a rehash of an earlier 2006 talk), the creation of competitive markets and the potential for this.
A couple of points to note ...
- The Cloud Foundry model is straight out of the Zimki playbook and almost identical in every respect which is why I'm so delighted by their success. I know lots of the people there and I was in their office in Old Street last week (it's actually opposite the old Fotango offices) and so it was nice to "cross the road" after a decade and see a platform succeeding. The recent ODP (open data platform) announcement also follows the same play. This is all good and I'm a huge supporter.
- The OpenStack effort made the critical errors of not dealing with the tendency of product vendors to create a collective prisoner dilemma and compounded this by failing to co-opt AWS. They were warned but were hell bent on differentiation for the flimsiest of reasons (future speculation on API copyright). They'll survive in niches but won't claim the crown they should have done by dominating the market.
- OpenShift has failed to learn the essential lesson of limitation of choice. I'm sure some will adopt and learn the lessons of sprawl once again. I do tell RHT every year they should just adopt Cloud Foundry but c'est la vie.
Anyway, there's more to good gameplay than just open sourcing a code base. Keep an eye on Pivotal, they have good people there who know what they're doing.
