Let us now return to 2005 and put ourselves in the shoes of the CEO of software company that has a consultancy based business model that won’t scale under the given constraints due to a corporate wide freeze on recruitment, has an uncertain future due to planned outsourcing but an existing value chain and a talented engineering team. This is easy for me seeing I just have to wind the clock back.
I’ve replicated that same value chain (or parts of it that will we examine) mapped against the state of evolution in figure 29
Figure 29 – Value Chain vs Evolution of Fotango
We already know that: -
- All the activities, practices and data on the map are evolving due to consumer and supply competition.
- Existing consumers and suppliers will have inertia to change.
- The shift from products to utility services would initiate a change from peace to war. Many of those past giants will fail to act in a timely fashion, lulled into a false sense of gradual change whilst others will apply strategies such as cost reduction in a hope of recreating past norms.
- Component activities that become more commodity-like will accelerate the genesis of higher order systems (componentization) and benefit from volume effects.
- The combined benefits of increased agility, efficiency and the flow of capital towards new higher order systems will turn a trickle of adoption into a flood.
- Commodity activities are suitable for outsourcing – for example infrastructure to utility providers. Novel practices will develop to deal with this.
Hence two of the above components stood out as being of immediate interest – infrastructure and platform. In both cases there was a large existing market mainly served by products. In both cases the activities were widespread and fairly well defined. In both cases business consumers were grumbling over the cost associated and no-one seemed to consider either activity as providing a differential value.
However, whilst we had some capital we didn’t have the investment capability to build a large-scale infrastructure service (though we ran our own small private virtual data centre). But a large-scale computer utility would be useful to us if we focused on the platform layer as many of the capital costs would be taken care of.
I talked to a couple of huge hardware manufacturers about this computer utility idea and unsurprisingly we were given the cold shoulder. Fortunately, I knew that because the act of computing infrastructure was so widespread and well defined that it was likely that someone would play that game soon. That someone wouldn’t be an existing hosting or hardware company (both with inertia) but instead a former consumer. In 2005, I expected that player to be Google but in 2006 it turned out to be Amazon.
Hence in anticipation of these changes we focused on commoditizing the platform space. We knew that consumers would have inertia to the change, so we looked for means of mitigating this.
The fastest approach was to simultaneously offer a trial service (a public platform service) and allow businesses to build the system in their own data centres (a private platform service). This would give us time to build a customer base whilst we solved those concerns over lock-in, security of supply and pricing competition by creating a competitive market of suppliers with easy switching between them.
Such switching would require semantic interoperability i.e. you needed to be able to take your code and data from one platform supplier to another and know that it works. In order to make this happen, all the suppliers would have to be in effect running the same core system with competition based not on differentiation in features but in operation.
To achieve this, we would have to open source the system and provide some means of monitoring to ensure the suppliers were complying with the standard. We could play this assurance game with a trademarked image to show compliance.
Hence the plan was an open source platform play focused on creating a competitive market of suppliers with a higher order exchange that built upon lower order components supplied by future utility providers of infrastructure. We knew that inertia of existing platform suppliers would be high, so we had little to fear there and the competitive market would help reduce consumer concerns.
We also knew the importance of building a wide ecosystem of consumers and tools (more on ecosystems later), so everything had to be provided through APIs. This would also help with the exchange concepts.
Finally and most critical in this was speed of creating higher order systems, it had to be fast, it had to be accessible, it had to be easy, it had to provide useful metrics and it had to cover as wide a range of potential consumers as possible. However, developers (like everyone else) have inertia to change and there were going to be huge educational barriers. We needed a hook.
In 2005, the team started exploring and building out this space. It took three weeks until a sunny afternoon when I was sitting in the boardroom plotting our play for the hook to be found. Two of my outstanding engineers (they were all outstanding) walked in and said they could build a platform that used one language – JavaScript. The idea was developers would build entire applications front and back end in this single language.
The CIO promptly came in to lend to support to the idea expecting some sort of fight over this “crazy” idea. A fight happened but not the type they were expecting. The hook of JavaScript was perfect and our argument stemmed from me pushing them to open source everything from the get go. Rather than resistance they found enthusiasm.
The JavaScript hook was essential because whilst many developers would have inertia, there are a vast number of front-end developers with JavaScript skills who considered the back end a world of mystery. By taking this away, giving them one language, removing all the unpleasant tasks of building a system (what is commonly called Yak Shaving) then we had a new audience who could embrace whilst others adapted.
We could give the world a commoditized platform built on APIs with a single language, entirely open sourced with a competitive market and exchange. We could remove all those horrible yak shaving tasks of capacity planning, worrying about scaling etc. We could give the world “pre-shaved” Yaks.
And so, Zimki was born.
But what about the why we were doing this? After all the vagueness of why is where we started this whole discussion. Well, that bit is easy because we had a map. We knew our existing consultancy based value chain was going, we could see how the market would evolve, we were positioning ourselves to exploit this, to create new revenue streams around platforms and to take advantage of anticipated actions of new players in infrastructure and the inertia of past giants. Our map gave us the ability to see our choices and decide – the how, what and when was now harder than the why.
We weren’t some clumsy general bombarding a hill because every other general in every other battle was bombarding a hill. We had precise and clear situational awareness, we knew where to attack. But how long did it take Fotango to map out these changes and so accurately predict the movement and impacts of cloud half a decade in advance? Months? Weeks? Roughly a few hours but we did go overboard.
Now, whilst I’ve mainly talked about IT (principally because this story is based around a software company), the same exercise of mapping can be done with an insurance company, a law firm to a car parking company. All have activities, practices and data that are evolving.
So what happened with Fotango?
By 2006, a utility platform as a service provided through APIs was built. Libraries for common routines were created, a simple NoSQL object store developed, templating systems added, detailed metrics on pricing right down to individual function, automatic conversion of new routines to web services, a GUI, exchange capabilities and a host of useful stuff was ready.
The speed of development was lightning fast. One system, a new form of wiki, was built and delivered live on the web from scratch in under an hour. Nothing came close in terms of speed and flexibility. We launched.
At the same time Amazon launched and we couldn’t be happier. Not only had this big player immediately re-affirmed the market but also we could start to reposition the system to run on EC2. Our open source plans were announced in late 2006 and everything was timed for OSCON 2007.
I’ve plotted many of these changes in figure 30 showing inertia barriers, higher order components and anticipated actions.
Figure 30 – Examining the map and change
Our map also told us what to watch for. We knew that some of the higher order systems to be built would become highly valuable. Our platform actually gave us a way of determining diffusion and success through customer consumption, so we had the opportunity to spot these new sources.
We knew that practices would change (co-evolve) because of more utility provision and we had to keep an eye out for this and adapt rapidly. We knew the existing industry would resist and be dismissive. Education was going to be key to turn the trickle into the flood.
We knew that the techniques used to build utility services were fundamentally different from genesis of the novel and new, so we re-organised around this. In fact we re-organised the entire business around the flow of evolution but more on that later.
By early 2007 we were riding high. My CIO had done the first installation of Zimki onto EC2. The open source plans were ready and we have demonstrated the exchange capabilities and how you could switch from private to public supplier. We had the keynote at OSCON and Zimki was rapidly growing. Our last event in 2006 had been packed 5 or 6 layers deep around our booth. It was insane. We had hit a home run and we were ready to take on those past giants and become the new Titans.
But we failed.
Not because the strategy or map was wrong, it wasn’t. Today, the growth of services in the platform space shows this. We didn’t fail because of the engineering team or because of weaknesses in the technology as we were far ahead of any competitor and the team was outstanding. We didn’t fail to anticipate future consumer needs or competitor actions - all of this was spot on.
We failed because I failed.
I had estimated in 2005 that this future utility market (called cloud today) would be worth $200 billion by 2016, something that more recent analyst reports have born out. However in 2005, it seemed like a crazy concept for many people that the world could change so rapidly. Some of those people included my board.
It was too far out of their comfort zone, it seemed incredulous and despite running a profitable company I lacked the political capital to pull this transformation of. In their minds, IT was best dealt with through outsourcing whilst the parent company concentrated on their core products along with new products like TVs. They were uncomfortable with the whole notion, our tactical use of open source was counter to their normal experience of IP and they were set on their own path.
By the time of the keynote at OSCON, the open sourcing of Zimki was stopped, the plans to outsource the group became clear, Zimki and any notions of a management buy-out were a dead duck. These were perfectly rationale decisions based upon the parents focus on the current core and internal messaging and changes at that time. This is where the power of mapping comes into play, because as Nokia has showed repeatedly – today’s core is not tomorrow’s.
Would Zimki have succeeded if it continued? Well, ask VMware’s CloudFoundry, SalesForce’s Heroku or Goole’s AppEngine which followed much later. The answer is … we will never know. That time has passed.
By now, I’d hope the reader has some idea of the value of mapping value chains, how activities (and practices and data) evolve, how economies move through cycles, how characteristics change, why different techniques are needed at different stage of evolution and why companies have inertia.
In terms of progression, let us imagine a karate grading system of strategy. If we accept that in the outside world there are black belts (1st dan and above) in strategy then assuming this was all new to you at the beginning, we’ve probably just earned our first junior belt (7th kyu, Yellow). We at least have some idea of how to map the environment, some notions of what an organization is and how things change. We have a long way to go and even at the end of this series, we will be barely scrapping past 5th kyu. But continue we will.
I’m going to use the mapping techniques and fundamentals we’ve developed to explore new forms of organization, the fundamental importance of ecosystems, use of open as a tactical weapon, numerous strategies from defensive strategies such as tower and moat along with attacking strategies and the basics of putting together a battle plan. The mapping technique is important because it will help us see why this stuff matters rather than the usual unclear and hand waiving notions that abound with ecosystems and the like.
I cannot emphasize enough that this series won’t make you a master strategist and these people do exist – I work with several at the Leading Edge Forum who are truly frightening in terms of capability. But this series might help you and your company to survive in today’s battles.
---
Post 13 of 200
Next post in series ... No reason to get excited
Previous post in series ... Revolution
