Our business model wasn’t scaleable and mainly consisted of consultancy revenues from the parent company i.e. we were highly dependent upon the parent. This situation had arisen out of past necessity, in other words survival.
When I had joined Fotango many years earlier, it was one of the leading online photo services in Europe. However the technology was in a poor shape, the company was making a significant loss, we had burnt through millions of VC funds and the internet bubble had burst. We were facing bankruptcy in six months and we were looking like a certain casualty.
We managed in short order to get the technology sorted, the site more stable and useable, reduced the burn rate and went looking for a buyer. We were lucky, Canon bought us literally weeks away from us hitting the wall. However, we were still haemorrhaging cash, so we had to borrow just to stay afloat.
Over the next two years, we built a consultancy arm, beefed up our internal engineering talent (by poaching from the open source world and London’s strong Perl community), turned profitable and paid of our debts. The company had survived, it was growing but the consultancy model was constraining.
By 2004, we had introduced a variety of techniques to give us more breathing room to look at developing new products and services. The old Fotango photo service had floundered and been superseded by other sites and we became aware of new heading our way. The parent company had taken the decision to outsource all IT activities and Fotango’s future (this time as a development shop) was in peril again.
We needed a new route for the company, a way of creating external revenue such that we could cope with the oncoming storm. It was at this point, I turned to that mapping technique that I had recently developed to see if it could help.
I examined the old Fotango model that still underpinned most of our consultancy work. As an online photo service, Fotango had developed a value chain based around numerous online activities from large scale photo storage, a web site, a standard development platform, online payment system (for customers of photo based products), fulfillment services, internal administration systems, a data centre and significant compute resources. Many of these components we had re-used in numerous of our consultancy projects.
The following figure provides a simplistic value chain of the main components related to our online photo service.
Figure 4 – Value Chain
Whilst some of the activities were custom built, many had become available as fairly standard products (e.g. servers, databases). Hence, I examined the components and mapped out at what stage of evolution the components were. An overview of the above value chain mapped against stage of evolution is given in figure 5.
Figure 5 – Value Chain vs Evolution
I understood that these component activities would continue to evolve towards more of a commodity through simple competition (both consumer and supplier). Hence the team went looking for components that were currently provided as products but could be provided as more standardised, even utility like services. We were hunting for things to commoditise.
I understood that industry often has inertia to change (more on this subject later) and hence there were likely to be a number of activities that should be provided as more of a commodity but wouldn’t be. The team ran a number of internal experiments and came up with numerous potential areas.
Figure 6 provides a rudimentary overview from 2005 of parts of our value chain mapped against the state of evolution with three of those potential new service areas identified. Whilst there were numerous opportunities, I’ll concentrate on the three marked which included an infrastructure as a service offering (based upon an internal technology known as BORG), a platform as a service offering (known as Zimki) and a generic utility billing engine (known as GUBE).
Figure 6 - A rudimentary map
We had limited set of chips to bet with, so I diversified ourselves from the old Fotango model (we were soundly beaten in this space) and focused in on the platform as a service space (part of what we commonly call “cloud” today) with a project known as Zimki.
Zimki was designed to be an online development platform where anyone could build any application online and be charged on a utility basis for consumption of the underlying compute resources. It supported one language throughout – JavaScript – it was simple to get started with and provided a range of useful features from a NoSQL like object store, detailed metrics on consumption, code libraries and templates.
By 2006, we had launched Zimki, one of the world’s first platforms as service offerings. The speed of development was fast, entire systems being built and released in days or hours. We anticipated how the market was going to change, the future need for exchanges and competitive markets due to concerns over lock-in, the importance of open source in order to make this happen, along with the educational and adoption barriers to “cloud”.
The service rapidly grew and as Amazon had entered the fray with EC2, we knew we had found a rich goldmine. The map had pointed the way and certainly made decisions easier.
Today, some seven years later, the anticipated changes to the market have all turned out to be true. Zimki was unfortunately caught up in the internal politics of the parent and its future quashed, a salient lesson in the importance of political capital. However, since those days we have seen Google App Engine, Heroku and more recently CloudFoundry (an open source platform play by VMware released in 2010) follow similar paths into the platform as a service space.
Am I really saying that the maps allowed us to anticipate how the cloud industry was going to develop some seven years in advance? Yes.
The figures above are of course simplistic representations and what the reader is missing is many of the details on how to read, understand and use the map i.e. how did we know about the inertia industry would have, the need for exchanges, the importance of open source etc.
Gaining a better understanding of what the map means is what we’re going to explore in the next few sections. At this moment in time, it’s enough that the reader is aware that a map of value chain vs evolution can be created and used to anticipate changes to an industry.
---
Part 5 of 200
---
Part 5 of 200
