Four Basic Smackdowns on Economic Competition

Tl;dr Competitive gameplay requires an understanding of the landscape, the rules and experience in playing the game - there are no shortcuts.

The Problem

I read an awful lot at the moment on Entrepreneurship and I have to say that most suffers from a one size fits all mentality. It's the same issue with statements like culture eats strategy for breakfast  but usually expressed in terms of the top ten secrets of being a successful entrepreneur. Alas competition isn't that simple and the methods you use have to adapt with what you're doing. To demonstrate this I thought I'd cover some of the basic games of competition.

First, let us start with the simple premise that competition in business is like playing a game of chess. In order to play the game then you have to understand the board (the landscape), the rules of the game and then learn how to play. Many companies I met have no clear way of understanding the board let alone anything else. Hence everything seems random and one size fits all - either agile versus six sigma, push vs pull, network vs hierarchical, unstructured vs structured - tend to rule and we're bombarded with over simplifications from culture to disruptive innovation. 

Mapping

Contrary to popular belief there are ways of viewing the board. A technique that I've used successfully for the last eight years is mapping and I've given an example of a map from an extremely large heavy engineering project in figure 1.

Figure 1 - Mapping a heavy engineering project.

The map uses an axis of value chain from the visible needs of customers to the more invisible components needed to meet those needs versus an axis of evolution i.e. how evolved those components are. Once you have a map, there are some general rules of the game that need to be understood.

Basic Rules

• Organisations consist of many value chains

• Value chains consist of many components: Some of these components meet visible user needs and others that are invisible but enable that need to be met.

• Components include activities, practices and data.

• Everything evolves: All components evolve due to competition.

• Characteristics Change: As components evolve their characteristics change. For example the uncharted are rare, chaotic, constantly changing, deviating from what existed before, uncertain and a source of differential. The same component as it evolves becomes more industrialised and its characteristics are common, often provided through standard and what appear to be "linear" interfaces, it is known, measurable, deviation is undesirable and it becomes a cost of doing business.

• No one size: Since a value chain is likely to consist of many components at different stages of evolution with polar opposite characteristics (uncharted versus industrialised) then no one single management method is applicable across the entire value chain.  For any complex system it becomes important to break the system down into smaller components and apply appropriate methods i.e. it shouldn't be a case of agile versus six sigma but agile plus six sigma with each being appropriately used.

• Genesis begets evolution begets genesis: as any component evolves to a more industrialised form then this can allow for the rapid development of novel higher order systems, as in higher up the value chain.  For example, standard mechanical components (such as nuts and bolts) enabled the rapid development of machinery and engines. This is an effect known as componentisation.

• Efficiency, Agility and Wealth: evolution increases efficiency in provision but also through componentisation the rapid development and agility in building higher order systems. These higher order systems are also new sources of future wealth e.g. utility electricity enabled the creation of television and the media industry. 

• Choice is an illusion: The combined benefits of efficiency, agility and new sources of economic wealth are powerful competitive forces and hence organisations are forced to adapt as components evolve.  This is known as the Red Queen Effect.

• Co-evolution: the evolution of a component can force other components to co-evolve. For example, the evolution of computing infrastructure from product to utility has forced co-evolution of architectural practices from scale-up and n+1 to  distributed systems and design for failure.

• Inertia: Both consumers and vendors have inertia to change due to past success, existing business models, changes in capital whether knowledge (i.e. new skillsets needed due to co-evolved practices), social (i.e. changing vendor relationships), financial (i.e. past investment) or political (i.e. past choices). Inertia whilst manageable can often be fatal for an organisation by limiting adaptation when adaptation is actually a necessity.

• The speed of change is deceptive: Diffusion of any change has an exponential element but we are often lulled into a view of more linear change of evolutionary state because one “product” tends to be replaced by another “product”.  Hence we have the impression of a relatively long and linear process of improving computing servers (i.e. products). The shift from one evolutionary state to another e.g. product to utility has the same exponential element as the Red Queen creates a network effect of increasing pressure as more competitors adapt to it. In these circumstances our inertia to change due to co-evolving practices which is normally reflected in the “legacy question” combined with our past belief of more linear change (due to the long period of time that products have existed) tends to reinforce a belief that change will be gradual. It won't. This period of rapid but surprising change we call a Punctuated Equilibrium.

• The economy has states: The interplay between evolution and inertia creates different economics states that occur at both a macro and micro economic level. These include a relatively peaceful state of relative competition between product vendors where sustaining changes tends to exceed disruptive followed by a war state, a fight for survival caused by the evolution of product to utility. The war state is characterised by new forms of co-evolved practice, rapid and deceptive speed of change, new entrants and disruption of past companies stuck behind inertia barriers. This is then overlapped with a state of wonder where we see rapid development of new higher order systems, increased in new forms of data and flows of capital from past industry to these new wealth generating industries.

• Organisations evolve: The interplay between co-evolved practices (caused by evolution) and the changing economic states (i.e. peace to war) causing the disruption of past vendors tends to create new forms of organisation e.g. Fordism, Web 2.0. These organisations tend to demonstrate all the co-evolved practices and often have new methods of strategic gameplay.

• The map can be manipulated:  The landscape can be altered by changing rates of competition, use of open approaches (whether open source, open data or open hardware) or by deliberately driving a component to a more utility form. There are many strategic reasons for doing this from creating a new opportunity, undermining a competitors barrier to entry, building an ecosystem and running an ILC model, playing a tower and moat game to playing a standardisation game. 

Four Basic Smackdowns

Ok, now we have an idea of how to map and the basic rules of the game we can talk about four basic smackdowns of competition - i.e. how you fight.

Building the new
The first play is to build something that is actually novel and new i.e. the genesis of an activity such as the first ever telephone, first ever computer, first ever television. By nature this is highly uncertain, you don't know what customers will actually want as the act is new. 

You need to be adaptive, take a minimal viable approach and quickly create feedback loops with customers. You're in a fight to establish the new thing as being relevant and useful often in the face of bewilderment. Inherently this whole approach is uncertain, you just don't know whether it will succeed and whether people will want it. 

Building the novel and new can be done at any time, though there are certain times when the cost of reduction of underlying components makes certain novel acts possible.  The first televisions depended upon home electricity supply to be economically viable. This is why whenever we have an economic state of war caused by commoditisation (Custom made nuts and to bolts to standard nuts and bolts with Maudslay Screw cutting lathe, Electricity from own generators to utility services with Westinghouse and Tesla, Computing from products to utility services with Cloud)  then we see an explosion of higher order novel systems - a state of wonder. 

However being economically viable doesn't mean the act will succeed. Because the act is uncertain then you just don't know if it will work, you have to experiment, to fail fast and to gamble. Get used to it and work on this basis.

Substituting one product with another product
A second play is to go after an established product market with a view of substituting it for your product. I'm not going to talk about the more general product versus product competition of improving features as this is normal fare but instead the replacement of one category with another e.g. one format of hard drive with another format. 

To do this you have to find a property of the value chain which is not catered for and which will become important - e.g. size of hard drive, power consumption, provision of an application store. This novel property is uncertain and to establish it you'll almost always need to find an underserved market due to inertia within existing markets (i.e. customers and vendors are used to the other format). This is the classic case of disruptive innovation, using an uncertain property often developed in an alternative market to improve the product to a point that you can assault the main market where the vendors will be suffering from inertia due to existing business models.  

The uncertain nature of the property is both friend and foe. It protects you against incumbents because they'll tend to dismiss it but at the same time you don't know if it'll work. Hence this is another gamble but when it works you can seriously damage incumbents and take a chunk of the future e.g. smart phones vs mobile phones or ARM vs Intel.

Substituting one product with a utility
A third play is to go after an established product which is widespread and fairly well defined and create a utility service for it. This has all the benefits of a product to product substitution with existing vendors having inertia however it has several advantages over the former. First, it's not uncertain but instead a known process of evolution not reliant upon creating novel properties, hence it's far less of a gamble. Of course, this means it's more defendable against but since most companies have poor situational awareness of the landscape (i.e. they can't view the board) then they're not likely to defend against your move. 

Secondly, you can use ecosystem effects through models like ILC along with a host of other tactical plays such as using open source, open APIs, open data to enhance your position. This is the easiest play to make and the one most likely to give you success however the opportunity to make such a play depends upon the act being suitable and so you have to wait for the right timing. 

This is what has been going on with cloud and why I talked at OSCON in 2009 on how it was the perfect time to disrupt great giants. It might feel like you're David vs Goliath but just remember Goliath is looking the wrong way and can't see you coming.  You don't have to worry about their size, all they will do is help validate your market.  Naturally, the easy pickings have already been taken though some opportunity still exists but the window is closing. 

Examples of this include Amazon vs Dell, where Dell has now had the good sense to realise it has lost the public computing infrastructure battle for an activity (computer infrastructure) which it once was a dominant player. Knowing when to retreat is also an important part of the game.

Don't worry if you've missed the boat a new window of opportunity will open up around 2020 related to 3D printing / Printed Electronics and commoditisation of the manufacturing industry.

Substituting one utility with a utility
A fourth play which is incredibly hard to make work is to substitute one utility with another. Once a utility gets established and inertia sets in due to a large ecosystem built on top of the component provided then it's difficult to shake it. It becomes very hard if the vendor behind this is playing a good ecosystem game. Taking this on is less David vs Goliath and more like David vs Goliath and an Army of His Brothers all pointing straight at David with Gatling guns. 

To stand a chance, you'll have to counteract the impact of their ecosystem. Now remember, this isn't the same as a product ecosystem where information flows are slow (i.e. marketing surveys) but one which information flows are based upon consumption data and are almost real time. This is the toughest of all battles and the best plays are around co-option rather than substitution and huge bets i.e. think billions per year if you're taking on Amazon. Oh, and you'll need a master kung fu black belt oracle of strategy to make it happen and before you think you can just hire one, the number of people that I know who can pull off this trick are very few. They currently work for Amazon, Google, Microsoft, Dell, UK Gov, Cambridge University, Canoncial and seven other companies. None of them are consultants, you've almost certainly never heard of them and most of them are very wealthy. Good luck in trying to find one.

Beyond the Smackdowns

Now there's a myriad of options and gameplay beyond the four basic smackdowns from the use of resource constraints against opponents, weakening focus by reducing barriers to entry in an opponents business models, misdirection, tower and moat play, use of alliances, organisational structure and cultural fit, to an endless barrage of dark arts. Remember I've been doing this for eight years and it would take a long time to write this all down.

However, the point I want to mention is that even with the four basic smackdowns the approaches you need, the type of information available, how you focus, where you attack and when you can do this vary from a high risk gamble (building the new) to a low risk but time dependent gamble (product to utility substitution).

The idea that there are ten basic secrets applicable to all is like the idea there are ten basic secrets of playing chess. Beyond the trivial i.e. understand the board, know the rules, learn to play the game then the moves you make depend upon the situation at hand. Certainly you can learn basic moves which are applicable to certain situations but they are not applicable to all.

Culture eats strategy for breakfast ... sometimes.

Tl;dr whilst culture often matters more than strategic gameplay, this isn't true in all circumstances.

I often hear the line that culture eats strategy for breakfast but do we really know this? What we do know is that activities evolve through a common path from genesis to custom built examples to products with rental services and onto commodity with utility services. What we also know is the style of competition changes (from wonder to peace to war) as things evolve and that companies have inertia to change due to many factors from past success to changing practices to changes in capital (physical, financial, social and knowledge).

Now when faced with change, to use the concepts of John Boyd, we first have to observe and orient around the change then make a decision and act upon it. The former is about situational awareness, the latter is about culture. But herein lies a problem because not all change is the same.

From figure 1, the genesis of an act is uncertain as by its very nature it is novel and new. The best we can hope to say is not what will be created but when something novel might appear as a result of componentisation effects (i.e. utility provision of computing is likely to create an explosion of new activities which consume computing). Product to product substitution is also uncertain caused by a change in the value network - we have no way of knowing that the iPhone was going to be a success. But evolution of an activity is not uncertain i.e. the shift from product to utility is known. It will happen, and our only issue is when and this can be determined by looking for weak signals (suitability, technology exists, concept exists, willingness of customers to adapt).

Figure 1 - Changes of predictability with evolution

When faced with a product to product substitution then cultural aspects tend to dominate over situational awareness as an indicator of whether a company can take advantage of the change or even survive. Situational awareness doesn't help us because the reasons for the change (i.e. a delta in the value network) are uncertain and unpredictable. Those companies at threat of disruption by such a substitution will have inertia due to past success and unfortunately for them this is only reinforced by the uncertain nature of the change with concerns over cannibalisation and disintermediation of existing models. Hence they will often react late due to inertia or even deny the change is occurring and when they finally accept it, they need to adapt fast. The ability to decide and act in response to such a change in a short period of time depends upon their culture which in many cases resists the change. Doom awaits for those whose culture cannot respond.

Examples of this include Nokida and RIM and whilst many mis-steps were made such as not co-opting Android, ultimately they didn't know what was going to happen. Whilst their respective CEOs have been lambasted in the popular press, the disruption was difficult to predict and hence protect against. Culture was the key defence mechanism here in order to react and no amount of situational awareness or chess playing would prevent them being in this position. They were caught out by an uncertain change they couldn't respond to. Alas, that happens.

However, not all change is uncertain and unpredictable. For example, the cloud space which represents a shift from product to utility is highly predictable and we've even had have forty years prior notice that this would happen. In this case, situational awareness of a predictable change is critical to prevent a company continuing to build the wrong things. Inertia to change naturally exists but there is plenty of time to overcome this. Disruption should not happen because of the predictable nature. However as many former giants in the hardware world are finding out, disruption still occurs. But Why?

Well, the reason for disruption is spelt out in figure 2. The cause is not cultural but purely down to poor situational awareness.  In this case, those CEOs whose primary job was to see the highly visible storm heading their way and move the company out of its path were snoozing at the wheel. These companies will fail because their CEOs couldn't see the predictable storm, they had atrocious situational awareness and were basically playing a game of chess by not looking at the board. You can't blame their company's culture for that failing.

Figure 2 - Culture and Situational Awareness

The point of this post is simple. For certain stages of evolution then culture is critical but for others situational awareness (i.e. strategic play) matters most. Now any organisation is a mass of activities at different stages of evolution hence some parts are predictable whilst others are not. You hence always need to strive towards good chess play and an adaptive culture.

As Techcrunch pointed out - "While We’re Trying To Follow His Game Of Checkers, Jeff Bezos Is Playing Chess" - some people are better chess players.  But the brutal truth is not that competitor CEOs are daft or foolish but instead they simply cannot see the board they're playing on. If you've ever played chess, you'll soon discover that not looking at the board is a quick way to lose.

Many are playing a game of blind chess and are unaware that whilst some change is uncertain, a lot of change is highly predictable.  It is fair to say that some companies are being disrupted because their executive teams don't know how to play the game and manage predictable change. However, in other cases (like RIM, Nokia) then cultural aspects mattered more because no amount of situational awareness can prepare you for an uncertain change. 

When it comes to business, understanding the landscape, knowing the rules of the game and what is and what isn't predictable is a key part of playing the game and why I've used mapping for the last eight years. Bland statements like culture eats strategy for breakfast fail to appreciate the rich complexity of competition. Sometimes culture matters more, other times strategic gameplay and situational awareness are critical.  In the latter circumstances, no amount of the right type of culture will protect you from a better chess player. Of course, even when culture is supreme then you've still got to get the right balance of cultures within your organisation.

What? You think there's only one that matters?

Why Map?

Mapping is all about situational awareness and understanding the context of a complex system whether an organisation, a line of business or a technical system. Without good situational awareness then it's extremely difficult to identify where to attack and hence strategic why (since 'why' is a relative statement - why here over there). It's even difficult to know how to manage something.

Without this, you might as well write a strategy which starts with general platitudes :- 

"We're going to be innovative, be efficient, be agile, focus on core, create a strong culture, create shareholder value, and establish ourselves in [XYZ]"

Where [XYZ] is fundamentally what everyone else is doing - cloud, social media, big data, digital first, 3D printing - i.e. replace with whatever is popular amongst competitors at the time in hand and hence currently reported in the popular management press - HBR, Economist etc.

From my own work, the problem with situational awareness stems from how we view the landscape. In figure 1 is a typical box and wire diagram for a large complex system (this could be an IT architecture diagram, a business process map, a user flow diagram etc). I've removed the terms of the components so we can focus on the diagram.

Figure 1 - A typical box and wire diagram.

It's a great wiring diagram from the point of view of plugging boxes together whether those boxes are technology systems or business processes but it's less than ideal for strategic planning.  The diagram tells us nothing about how to manage the environment, where there might be opportunities to attack, how to play the game and how things might change.

So, in figure 2 here's an alternative mapping view from @crankypotato and his post on mapping. Now I know nothing about what value chain this represents because they've not given me the terms (it's a blank diagram) but there's an awful lot I can say about game play from this diagram.

Figure 2 - An unknown value chain

First of all, from the above I can immediately identify what should be representing the visible need of the user.  From this I can determine a few potential differentials. At the same time, I can see what are the hidden components and where potential opportunities for efficiency might exist (targets). I'll also note that two of the more hidden components appear to either be operational advantages or potential constraints. I've summarised this in figure 3.

Figure 3 - Needs, Differentials and Efficiencies.

I can also now look at focus and parts of the map clearly need an experimental focus e.g. minimal viable, willingness to experiment and fail etc. Others need an approach of feature differentiation and tight feedback loops whilst the more hidden components I should be looking to drive towards more commodity, standardising with open approaches and the use of competitive markets where possible. I've summarised this in figure 4.

Figure 4 - focus

Now, I can start to look at how I can manage things. Obviously in practice I'd challenge the map and question whether some of the activities are really as they have been described. It's quite common for people to describe something which is ubiquitous and well defined as needing a custom built solution when in reality it doesn't.  However, assuming the map is roughly right and there's no glaring errors (like treating a CRM system as bespoke) then it's fairly easy to identify what should be built in-house with agile techniques, what should be a modified project, where we should be using out of the box and areas where we should be looking at more utility or cloud services. See figure 5.

Figure 5 - How to manage?

Ok, now at this point I have an idea of where I can find differentials, areas of efficiency, the focus I need and how to manage but I've got a question of how to measure?  The mechanism of measurement will vary again with context, so I can take a stab at what I should be using. This I've added in figure 6.

Figure 6 - How to measure?

Now, I have a basic understanding of the landscape, what to focus on, how to measure, how to manage etc.  I can now take a look at where to attack. Remember that disruption can occur in the product space with substitution (i.e hydraulic to cable excavators) but that's difficult to predict. Evolution from product to utility is again disruptive (combination of inertia with a punctuated equilibrium) but its far easier to predict. So, I can look at the activities (or practices or data) and identify those which are suitable for utility provision, where inertia barriers exist and where I can build ecosystem (exploiting an ILC like model).  I've summarised this in figure 7.

Figure 7 - Possible "where's" to attack

Once I've identified the where, I can look for why this route over that (i.e. type of competitors, probability of exploiting inertia) and ask questions of how I do this? Can I use an open approach to drive commoditisation and create a competing market, can I alter buyer / supplier relationships, can I undermine barriers to entry in a competitor's space, can I build a tower and moat play ... a long list. 

I can enhance this further by looking at competitors maps, anticipating likely changes and potential competitor constraints. The more details I have (i.e. what the dots in the diagram actually mean) then I can dig further and write some form of sensible strategic play. With more maps, I can build ways of identifying common service and I can even look into how to organise a company avoiding the usual business alignment issue (an artefact of structure). 

However, that's not the point of this post. What I wish to demonstrate is that mapping is a far more useful tool for strategic planning than the box and wire diagram. Certainly box and wire can't be beaten for implementation but for strategic planning ... they're lousy.

Without good situational awareness then any strategy is likely to become full of how, what and when (i.e. implementation, operational, tactical and purchasing details) with little or vague "why" which where it exists will be one of those common platitudes.

Whilst I have no idea of what value chain @Crankypotato is talking about (i.e. I don't have the details), I can already ask some reasonable questions and if we ever sit down to discuss it then we can have reasonable debate on what the map means and how to manipulate the landscape.

This is why mapping is a useful tool.

When should I fire my CISO?

If you've ever been a CEO of any company then you'll quickly learn the role is not just about leadership and strategy but also about balance. Whether balancing existing business models and the inertia they create with the future, the culture that has been created or the various factions within it. 

It's very easy to lose sight of this balance. 

Everything we do is ultimately about meeting some user need. Those needs are multiple from the thing itself, the way it is operated, how it is interacted with, the experience, any regulatory requirements and any needs for security. Those needs also vary according to the type of user and what we're doing (the context), so for example security needs for a private wiki are somewhat different for a public wiki.

All of these needs have to be balanced with the context in mind. 

It's therefore a dangerous route to allow one need (such as user experience) to override all other needs (such as security) and establish itself as a principle for the organisation. It is dangerous because the needs vary with the context and so you can't have generic principles but instead end up with vague platitudes like "appropriate security measures need to be taken", "appropriate UI design is needed" etc.

Such "principles" give ample opportunity for groups to run amok in an organisation and a plethora of such principles loses sight of the one thing that matters - meeting user needs.

And that ultimately is the balance that a CEO needs to continually maintain by creating an environment which  meets user needs today and the user needs of tomorrow (the two are obviously not the same). To make matters worse the meeting of user needs today (i.e. a successful business model) will invariably create practices and cultural norms which will resist meeting the user needs tomorrow (i.e. inertia to change). This all has to be managed.

In specific circumstances such as when the change is unexpected (i.e. difficult to predict) this inertia can have dire consequences for an organisation through disruption. Examples of which are product substitution such a cable versus hydraulic excavators or different sizes of hard disks. This is what is classically called disruptive innovation.

In other circumstances such as the evolution of an act from a product to a utility (e.g. cloud) then the change is expected and can be managed with planning. Often companies get disrupted in these circumstances but that's really a consequence of executive failure and CEOs snoozing at the wheel.

But let us assume you're wide awake, you understand the issue of balance and the importance of user needs. So, what has this got to do with the CISO (Chief Information Security Officer)? The problem is Shadow IT.

Shadow IT occurs when your organisation is screaming at you that you're not meeting their needs and so they've gone and found their own way of doing it. Shadow IT is born out of frustration, it's a worrying sign that something has gone wrong with the balance.  Now, it's not simply just a case of users using some other more useful service to get something done because we've given it a name - 'Shadow IT'. The name implies its outside of our norms of operating which means our norms of operating aren't meeting our user needs. This should set alarm bells ringing.

At this point the CEO should be asking the CIO and CISO what is happening? There are two key message which are important.

If you hear the message that we need to make 'Shadow IT' part of the norm by enabling our users to use such services then this is good news. The focus is on user need, it's about abolishing 'Shadow IT' by making it an operating norm and by applying any techniques needed to ensure our other needs (e.g. security) are met.

However, if you hear the message that we need to ban 'Shadow IT' and force users to use our systems then you know that one user need (security) is overriding other user needs and you have a problem. This is the point where you need to start thinking about pruning some attitudes from the organisation.

Punctuated equilibriums and boiling frogs

For many years, I've talked about the power of punctuated equilibriums in our economic and technological systems.  These occur during an economic state known as 'war' which is caused by the commoditisation of a pre-existing act after a more relatively 'peaceful' period of product competition. 

These punctuated equilibriums are dangerous to companies because of :-

• the inertia to change that is created by successful business models built during the more peaceful competitive state.

• the likelihood we will underestimate the speed of change due to the previous more peaceful and slower changing competitive state.

• the exponential nature of the change.  This exponential growth is driven by numerous factors including compound forces of adaptation i.e. the benefits of cloud (efficiency, agility in higher order systems, new sources of wealth creation) encourage competitors to adapt, the more our competitors adapt the greater the pressure on us to adapt becomes just to retain our relative competitive position (this is known as the Red Queen effect).

These days with cloud, I see all the signals of a punctuated equilibrium plus all the usual consequences of people misunderstanding exponential change.  They believe that they have time because the market of cloud is just a "small fraction of the computing market" etc. 

Hence, I provide the following as a sobering reminder. This is an estimated growth of AWS updated with various analysis statements (NB. Amazon is very careful not to publish actual figures, this is based upon analysis of Q4 figures and calculating a forward revenue i.e. by the end of 2015, I calculate that AWS forward revenue will be over $15 billion p.a.) with a % figure of revenue vs world wide server revenue.  Currently this stands around 3% but these figures are not as important as the growth rate.  Assuming Amazon continues on the estimated growth rate from the past six years then it'll probably represent somewhere between 30-50% of worldwide server revenues during 2017.  

Such a rapid change would not be unusual as we've experienced punctuated equilibriums in many forms of systems - environmental, economic, biological and technological.  However, this might be a bit of shock to those applying a linear model of growth (hence the delta of "future shock").  In fact, the only thing shocking is that people don't understand basic concepts like exponential change. 

In the cloud world this translates to companies thinking the effects are minor and rather than seeing the changes as a threat to the company, they often believe that they have time to exploit and manage the transition to this new revenue stream. It's like frogs discussing how the cold water they are in has warmed up and it feels quite pleasant and certainly manageable. 

So, if exponential growth is not something you're truly familiar with, then in order to do my bit for the community - please watch the following Dr Bartlett video on Arithmetics, Population and Energy as recommended by a good friend of mine, Artur Bergman.

[9th April 2015 - the video is no longer available]

-- 29th January 2016

The model is spiked. Actual revenue in 2015 did not exceed $8Bn but $7.8Bn. The actual run rate for Amazon by the end of 2015 was $10Bn (assuming this includes growth). I had AWS down for >$15.5Bn revenue in 2016 (i.e. each year after 2015). Oh, well.

Mapping and playing games

Personally, I find mapping a useful tool for determining predictable changes (and manipulating the environment accordingly) and anticipating possible but ultimately uncertain changes by narrowing the range of the likely.  Maps are never perfect but they provide a view.

I thought I'd explain this with two past examples - Fotango and Canonical - where I've used mapping.  I won't go through the details of mapping (I've covered this many times before) but instead how I used it.

My Fotango Story

Almost a decade ago when I was CEO of Fotango (a profitable and growing company), we had a problem on the horizon. We needed to find new external sources of revenue to rebalance our portfolio. James Duncan and I mapped out the environment on a whiteboard and used this to determine our play. For reference, a copy of that map (which I've simplified and tided up) is provided in figure 1.

Figure 1 - Map of Fotango

By examining the value chains associated with Fotango (the more faded circles and lines in the diagrams), we had determined that:-

1) Platform were going to become ubiquitous and provided through more utility like services.

2) That customers and past vendors would have inertia to the change (black bars) which we could reduce by creating a competitive market of providers and use of an open source play

3) That the marketplace would allow for formation of exchanges, assurance mechanisms (reporting on providers as per a Moody's rating agency) and a u-switch like model. 

4) That an ecosystem (the large shaded circle) could be built around the platform play and exploited through an ILC like model to identify new sources of future value.

5) That raw infrastructure (compute) would move to a utility.  Though we had already been running our own pre-cursor to a private cloud for some time (known as Borg), we could exploit the movement of a new entrant into this space to reduce our capital expenditure cost. I suspected it was going to be Google who made the first move, the following year we discovered it was Amazon.

We built our model around this and some of the other anticipated effects (change of practices etc) and Zimki, almost certainly the first modern PaaS was launched publicly (2006) as Amazon EC2 revealed its beta. We announced our plans to open source, create competitive markets and focus on building higher order systems.  Amazon's move mean't we started to immediately reposition to run on Amazon.

Everything was rosy, it was rapidly growing and the timing was spot on.  Alas the parent company had been persuaded that the future wasn't the stuff we were working on - utility computing, 3D printing, impact of mobile phones on cameras - but instead outsourcing IT, big ERP implementations and televisions.

In another universe, if a different route had been taken then Canon might today be a rival to Amazon in the cloud and have sown up the 3D printing industry.  But the same "if only" can be said of Xerox, Kodak and many others. We will just never know whether those decisions cost significant future losses of market cap since Fotango and Zimki were killed off and we can't replay the past.

I lost. C'est la vie. 

Fortunately a useful lesson in political capital was learned and the mapping technique survived even if Zimki didn't.

My Canonical Story

After leaving Fotango and working on various pet projects, I met with Mark Shuttleworth. Actually, a very smart troublemaking friend of mine introduced us under false pretences.  Mark wanted a designer, I said "I know nothing about Design" and so we decided to just have a chat.  What I explained to Mark was the principles of evolution and how this applied to the computing industry.  Mark asked me to come work with Canonical on strategy and so I joined in 2008.

The first five people I met in Canonical when I told them I was there to work on "Cloud" were pretty dismissive. "It's a fad" etc was actually fairly normal in the industry.  Fortunately, I had a great boss in Steve George and quickly met some smart folks in Rick Clark, Soren Hansen, Nic Barcet, Gustavo Niemeyer and John Pugh.  They were all open minded to the concept of evolution and change, so we plotted a plan.

The problem for Canonical (and Ubuntu) was that though it was strong on the desktop for a linux based OS, we were fighting RedHat on the server market and they owned it.  So, we mapped out the environment (on a huge whiteboard though interspersed with some content intense presentations of mine), had various arguments over how to play the game and roughly settled on an approach.  Figure 2 is a simplified summary of that process, a map that I've cleaned up (the original was actually far more complex and messy) and added some modern terms so it makes more sense for today (devops etc).

Figure 2 - Canonical Map

The principle play was:-

1) We accepted that RedHat owned the server OS (for the time being) but that didn't matter, we were going to own the future and let the industry catch up to us.

2) We would focus on being the dominant guest OS on any compute utility by building a cut down version of Ubuntu which anyone could use. Nic just made this happen with his 'just enough' concepts and support of others in the wider community who had led the charge. 

3) Companies would have inertia to the change so we would acquire an open source private cloud equivalent which matched the dominant player in a transitional hybrid (public + private) play. Hence our early involvement with Eucalyptus which John Pugh and Mark managed to hook in 2008 and Rick and Soren worked furiously on.

4) We knew that new practices would appear and so we would look at bringing those toolsets into Ubuntu (e.g. Chef) and modify Landscape (our management tool) appropriately.  In fact, Gustavo went much further and took this into the whole area of JuJu which is something I had serious doubts at over the time due to education barriers. In retrospect, I think Gustavo was right and I was clearly wrong here.

5) We knew that we needed to own any future platform plays and push application development onto Ubuntu. In fact the latter was already happening, the community was strong and the desktop and community team with people like Jono Bacon were doing an incredible job. However, we needed to get everyone in the cloud building on Ubuntu.

Steve would always (and rightly so) twist my arm over revenue stream. He would certainly give me numerous challenges on my approach to server.  As I pointed out there were multiple different revenue streams possible in the future (from support to brokerage to assurance to private cloud installations etc). However, my focus was to own the future, use it as a door opener (opportunities multiply as they are seized) and then build revenue streams.  I always take a view it's better to own the future and then monetize it rather than own a route to monetization but not the future.  Steve, was always supportive and both him and Mark are exceptional in terms of understanding opportunity and game play.  Any inertia that might have been, quickly evaporated when Mark made it clear that we were focused on cloud.

We didn't get every step right (I certainly had some bust ups over my insistence on Chef for example) and I certainly made a bucketful of errors.  But today, Ubuntu is without question the dominant OS in cloud.  The team at Canonical have done a stirling job in creating that future.

Let us be clear, Canonical (a relatively small company) literally stole the future from RedHat and all the other giants in the field and this was done with very modest investment and barely a shot fired by the competitors. The ability for Canonical to help itself to the prize whilst giants were sleeping around it was stunning but then I've often seen this scenario.

Now, some people seem to think I had a big part in this and so I want to correct that view as my role was minor. I was motivated to do this because of some very kind comments from Jorge Castro at OSCON which though appreciated overstated my influence.  My role was providing a way of viewing the landscape, sensing where to attack, exploiting the battlefield and evangelism.  Today, I teach all sorts of companies and Government organisations the same sort of techniques for mapping and certainly my maps have become a lot better over time.

However, this is just viewing the board and though it helps in playing the game what matters is how well you play the game and execute.  Mark and the group above and many more (which I haven't mentioned) within Canonical made it happen.  They are the truly exceptional ones and you should be in no doubt that Canonical is an outstanding place to work with some incredible talent. 

As for RedHat.  I kindly warned them to buy Novell and force an acquisition by IBM.  They didn't. They must by now realise the dangerous threat that Canonical has become and that the cost of reclaiming the future will be huge.  But that's not the fault of Red Hat's engineering talent nor their culture nor their community nor inertia nor their ability to execute, it was their executive management team that was outplayed.  They might have great engineering skills but in terms of executive management they had poor chess players.

C'est la vie.

Update 25th August 2013

I've been asked two questions. First does culture matter more than strategic play?  The answer to this is very complex and I'll have to do a number of posts to explain why.   The short answer is that in certain parts of the economic cycle then culture matters vastly more whilst in others strategic play appears to matter more. Where IT is at the moment, then for most companies, strategic play trumps.

The second question was what would I do if I was RedHat? I'll leave that to the reader to make their own suggestions but I would start by thinking about and mapping the landscape.  I'm not a great fan of ad-hoc plays without good situational awareness nor am I a fan of relying on "everyone else is doing this" or differentiation plays when not appropriate.  As a clue, my first step would be to embrace Cloud Foundry as the platform play.

Why Google Glass will change the world.

I've only played with Google Glass a few times (not owning a set) and it takes only a few seconds of use to realise there exists multiple killer applications which will change the way we interact with the world.

For me, Google Glass is more 1.0 and a predecessor to more powerful systems where your entire field of vision becomes interactive through printed and transparent electronics over the lens. In this latter case a whole host of other potential applications becomes immediately clear such as annotating of objects and people of interest in your field of view. However, this is all rather obvious and inevitable stuff but even in its current form there is a long list of killer apps i.e. multiple "where to attack" that a company might build a business in. Of these, one of my favourite examples is the second opinion model which actually takes advantage of the current display characteristics of Google Glass.

Before explaining how it works, I thought I'd explain why it's a killer application. I'm a great fan of mapping competitive environments through user needs and using this to predict market changes and opportunities (i.e. where to attack) by finding better ways of meeting user needs. The ideal scenario for me is to find a universal but poorly met need and there is one abundant example today which Google Glass solves.

To explain, I want you to think back to the last time you were going to buy a car or rent a home or were fixing something or in fact any time when a second opinion would have been useful. You probably actually phoned someone, had to describe the situation and they may have given you some advice on this but the process would most likely have been tiresome. Trying to explain over the phone a particular car and get their advice on what's a good price, what should you look for etc is never easy. Try asking someone whether a particular thing you've seen in an auction is a fake?

It's way much easier if you could show them and they can talk you through it. I've tried this in the past using skype on the phone but whilst that's better it's less than ideal. The core component of the killer app in Google Glass is hangout. When I create a hangout I can see and hear the person on the hangout whilst they can see what I'm looking at. Now obviously if we had full view interaction then they could point to areas of my field of vision that I should take an interest in but even in its current form the floating window of a person who can see what I'm looking at is highly effective and bizarrely reassuring. They can guide and direct me.

Now, ideally whatever situation I'm in I'd like an expert at hand. Burst pipe, instant plumber available who can see what I can see and give me advice. Travelling on a plane and the pilot and co-pilot are taken out by a mysterious ailment (I've obviously watched too many disaster movies) then instant pilot available. Is this car a good buy? Is this antique a fake? Funny looking boil on my leg should I go to the hospital?

There's an enormous list of situations where second opinions are good to have especially from someone who knows what they're talking about. And that's the the killer app. A connection to a personal assistant with a long list of available experts on a wide range of topics who can create a 1 to 1 hangout for me with someone who is knowledgeable about what I'm looking at. 

This one thing alone will change the way we interact with the world and stop me buying lemon cars, fake Picasso's and pressing the wrong button on an airplane. As for the boil, I suppose I'll call NHS Direct but I bet it would be easier if I could just show them.

--- 9th Sept 2013

I was asked for other examples of "where to attack" with Glass. To be honest, the list is huge, there's lots of potential and a hangout is just one. A few of the more obvious examples include :-

Interpretation of audio / visual events. Hear a bird signing, a song, a foreign language spoken, the roar of a motor car or see some impressive building or some other event then click here to interpret and identify.

Augmentation / Annotation of objects in the field of view. See something you like then click to buy it and variations of this form including in-field translation of text i.e. "What do these hieroglyphs mean?" will be a thing of the past. If my partner sees a present which she thinks our son might like (e.g. a new toy) then I expect her not only to be able to send me a photo but leave a virtual note on it. So, when I go into some other toyshop then my glasses will identify it and I can add my own views on suitability etc.

Streaming interpretation of audio / visual events. Having a conversation on some subject, don't worry Glass will be constantly streaming relevant information on the discussion to your field of view i.e. "Who was in the Rolling Stones?" will be a thing of past, the answer will be available immediately. Think MindMeld combined with Google Glass. Watching football will never be the seem again.

Remote viewing and control. Worried you've left the house without turning the cooker off or setting the fish tank onto "automated feed" mode? Quickly transport your vision back to home and reset / change what you need.

Augmentation / annotation of location. Need information on where you are, history, culture, practices or need a taxi (or a self driven car i.e. the future "utility" taxi) to your location or simply want to leave a virtual message at this space for others (think a virtual "I was here", "The building is unsafe, do not enter" note) then Glass will have a solution for that.

Basically there's a mass of new activities related to augmentation, annotation, interpretation, remote viewing, remote control based upon audio, visual and location information. No-one should be in any doubt that Google Glass will change the world.

And whilst the above is huge it is but peanuts compared to what is coming and the rise of intelligent software agents.  The combo of this with Glass will create true marvels of incredible use.

Few will care that privacy will further evaporate. In ten years time as I wander through a local craft store with my Glasses identifying something it calculates that my Mother would like for her birthday based upon its discussion with her Glasses then privacy won't be top of my thoughts.

What I'll be thinking about is the suggestion that my Glasses will make that if I take a twenty minute stroll (the weather is good, I need the exercise) upto this shop (directions provided) then an acquaintance has seen a better version (my Glasses asked their Glasses) and I could also stop and have a chat with them at the coffee shop next door. As my Glasses will point out they're working for company XYZ and are producing some product relevant to my research.

Today's browser based / smart phone world will seem like a bad memory in a decade. Like flared trousers or mullets.

Why would Bezos buy the Washington Post?

Well, there's two parts to the business - the news gathering and distribution but also the printing business.

There's all the usual suspects - a content strategy, a future news publishing platform play, buying influence or a trophy. However there is also the simple issue that large scale printing facilities cost a fortune to set up. Washington Post's smaller printing facility (which apparently was sold in 2010) cost around $230 million to build. Its printing facility in Springfield is said to be a monster.

Oh, but printing is dead ... isn't it? 

Well, as I said over a decade ago by 2020 large volume printed electronics should become a massive business and by 2030 most objects with macro physical and micro electronic features will be printed. It's all part and parcel of commoditisation of the manufacturing process. So I don't share the view that printing is dead. I take the view it has barely got started and it'll make cloud look like chicken feed.

So, along with a news business, Bezos has acquired a massive printing facility with capability, skills and know how just about the right time to get prepared for a printing revolution in electronics? Oh, I see I've already commented on Buffet buying up Newspapers with big printing facilities as well. Do they know something the rest of the industry hasn't figured out?

Is this their intention? No idea. It's pure speculation.

Still, there's money to be made in printing. How else do you think we're going to get ubiquitous computing without electronics flowing off the back of massive printers measured in many km per hour.

I've a really old and out of date report on this from 2006. It's fairly useless now (other than general interest) but if you want to know more on the subject then I'd look at the work that Kate Stone is doing or Bruce Kahn.

Anyway, my view is the news business is interesting and there is lots of overlap with Amazon's current properties. As for the printing business, well if the time, tech and capabilities are all right then this could be the bargain of the century. Why buy a newspaper to do this? Unless you wanted to clearly signal your intentions to competitors by buying up or building printing capabilities then it's the best way I know to silently slip into the field.

Of course, with Google's purchase of Motorola most people are talking about the patent portfolio and their latest range of smart phones with the customisations available in the Moto X. What people might not realise is that Motorola also has some serious history in printed electronics at large scale. We might actually be watching the carve up of the future of manufacturing by two tech giants.

For those who have never seen flexographic, offset or gravure printing of electronics then this video [removed link, now defunct 30/03/2015] might peak your interest or the following CNET article.

But then again, maybe the analysts are right and Bezos just bought a newspaper and it's all about the content, influence, a trophy, a news platform play or a bit of them all. I wouldn't however simply ignore the printing facility though.

The interface doesn't matter.

Excellent article by @somic on a "Response To Simon Wardley: Innovation in Interface Implementations" and well worth a read.

It's an intelligent article with little for me to take umbrage with, other than the "ideological footing" comment as very little of what I write comes from a particular ideology but instead pragmatism to eventual evolution of acts to more of a commodity. Other than that minor quibble, it's a well reasoned article (a blessing from the various Simon is a buffoon comments I get to read) but there are a couple of points worth raising.

Point 1 - Don't mix product and utility

The article states that "customers want differentiation". Differentiation in a function for a product like "cars"? Absolutely we want this.

But

"customers want differentiation" - in function for a utility like "electricity"? Really? Do I really want the interface to be changing from one socket to another? A different frequency, voltage and socket type? I don't think so. 

The two contexts are different, you cannot simply compare products versus utility. This alas is the flaw with the analogy given in the article. If we want to compare utility versus utility and use cars as the example then we would have to roll the clock forward to a time when cars are more of a utility i.e. a world of self driving cars where I just jump in and say where I want to go (a more automated form of today's taxis). 

Will I care about the diameter of the steering wheel in such a world … nope. It's an invisible component to me in a utility, I only care that I can jump in and say where I want to go. This act of saying where I want to go is the interface.

Will I care if someone changes the interface because of a desire to innovate and so when I jump in and say "Cowper Street" it returns back "Please tap out your directions on the driver's head rest in Morse code" … yep. I'll care quite a bit.

Will I care if different cars use different co-ordination / mapping systems such that a direction in one car will end up at a different location to another - you betch'a. I'll tend to get quite annoyed at this one behavioural change.

I'll be definitely writing posts that say the interface doesn't matter, please limit innovation to above the interface (would I like a fast route or a scenic one) or below it (operational efficiency of car) but leave the interface as standard and just adopt the dominant de facto please. 

Yes, we could have abstraction layers in which case I could walk around with a piece of kit which translates my speech to Morse where necessary and my directions to the right co-ordination / mapping system. Would it make me happy - nope. I'd think of it as a bloody waste of good engineering time and effort with no obvious benefit other than pandering to desires to innovate at the level of the interface.

Point 2 - We shouldn't care about the interface.

As the articles states "Has the generic IaaS interface changed in any significant way? Not really - no one is innovating in the interface any more because a lot of interesting work there has already been done"

Perfect. I couldn't agree more and would reiterate this has been the case for some time. However, if the above is true then why on earth can we not just adopt one interface then - the dominant defacto of the market. If the interface doesn't matter then we should simply adopt AWS APIs and co-opt their ecosystem because after all, this is a battle of ecosystems and co-opting is the right play.

Can OpenStack dominate IaaS?

tl;dr : only if it embraces ecosystem over egosystem.

To understand why, we need to cover some basics regarding the market as it is and examine how to win the space.

First, the basics :-

• Users (as in companies) are flocking to AWS because lets face it - it's useful. Many aspects of IT are evolving from a world of products (and rental services) to commodity (and utility) and this process is driven by competition (both supply and demand). As I've said for the last eight years, this is unavoidable.

• Despite any inertia that we may have to the change from past practices and past business models, competition not only forces the process of change, it also forces us to adapt and adopt. The reason for this is that utility provision is not just about efficiency but also agility in building higher order systems which are new sources of wealth. As competitors become more efficient, agile and able to extract new sources of wealth then the pressure on us mounts - this is the Red Queen effect.

• That mounting pressure has a network effect, as more competitors adapt then the pressure on us  to adapt also increases. This is why a trickle becomes a flood with respect to these changes and the speed of change occurs more rapidly than we expect. This is known as a Punctuated Equilibrium and it's why Amazon has exponential growth.

• An ecosystem model known as ILC (innovate-leverage-commoditise) can be built around utility services by exploitation of consumption information. Under this model, a company creates a utility which allows other to innovate. As those innovations diffuse and evolve this pattern can be spotted through consumption. Hence the company can use the ecosystem to spot new and successful change. This can then be commoditised to new components to grow the ecosystem. 
  
  
  Under a well run ILC model then a company can simultaneously appear to be :-

1. highly innovative, as others are actually taking the high risk gamble of innovation for it and successful changes are being included as components.
2. highly customer focused, as data on consumption in the ecosystem is being used to determine successful changes.
3. highly efficient, through volume operations and economies of scale in provision of the core utility components
4. highly stable revenue, by being a first mover to industrialise a component to utility services the company gains large (volume operations) but well established revenue streams.
5. maximum wealth generation, by being a fast follower to any spreading successful change then the company maximises new benefits without incurring risky and costly R&D.

All five of the above factors will increase simultaneously with the size of the ecosystem which can in turn increase in a super linear fashion to the physical size of the company.

Ok, now we have some basics lets understand the situation:-

• Cloud is simply about the shift from product to utility. Infrastructure as a Service is no different. Companies have inertia but we are experiencing a punctuated equilibrium hence the change is likely to be very rapid as we're all forced to adapt.

• Amazon is playing what looks very like an ILC model and it has dominant ecosystem which is growing exponentially in terms of revenue. As AWS gets bigger it will get more innovative, more efficient, more customer focused, more stable revenue and more wealth opportunities. It is literally chewing up the future market and it's way beyond the 800 lb gorilla in the room.

At first glance it looks a pretty dire situation and to be frank it is. This situation can be fought against by exactly the same mechanisms I described six years ago but its just much more difficult to play the game today.

The way you play the game is as follows :-

• Companies have a concern which is about second sourcing options and buyer / supplier relationship. What they want is a competitive market of IaaS providers. This concern is your friend and so embrace it.

• The ecosystem effects can be neutralised by co-opting the ecosystem i.e. building a market of AWS clones. This will also make it easier for existing AWS users to use the market. NB. 

1. you don't have to implement all of AWS but the most commonly used aspects of it to begin with. 
2. innovation needs to focus behind the interface (APIs) on operational efficiency.
3. you are only temporarily beholden to Amazon. As the ecosystem around the market grows to exceed the ecosystem around Amazon then the market of AWS clones actually takes control of the AWS APIs and can set the direction.

• Compute demand is elastic but building data centres is time and resource constrained. Hence by introducing a price war, a market can increase demand beyond the ability of a competitor to supply and hence naturally fragment a market in its favour.

Now, ideally this game would have been played many many years ago (2008 was ideal). But It wasn't. However it's still possible to play it today (just about). What is needed is:-

• a large player willing to spending billions on building an AWS clone around OpenStack.

• consolidation of OpenStack providers around this effort and the creation of a market of AWS clones.

• co-operation with other open source projects (Eucalyptus, CloudStack) to build an AWS compatibility suite and hence extend the AWS clone market to other technology platforms.

• introduction of assurance services which monitor the market for compatibility.

However, it's worth also noting what is not needed and what will almost certainly drive OpenStack into a niche from which it won't recover. These are :-

• continued focus on differentiation on the API as though the interface for a commodity is somehow a game changer.

• continued misunderstanding of the power of ecosystems and why they have to be neutralised. 

• focus on a temporary transitional market such as private cloud. Yes, you can win some space from VMware but that's buying into a market which is heading for niche under its own steam.

• the collective prisoner dilemma of OpenStack with everyone differentiating for their own position and existing product sets.

OpenStack's chance of success has IMHO been severely harmed over the last few years by what I can only describe as "flat earther" opinions e.g. a product mentality of feature differentiation and company competition applied to a utility world ruled by service quality differentiation and a battle of ecosystems. In terms of strategic play, pretty much the only thing OpenStack has got right is being open.

They need to stop using product examples to justify differentiation plays and realise they are ultimately not in a product game. If they lose the public arena then its niche time. They need to change soon. They need to learn how to play the game.

And this is the problem. OpenStack appears to have become a battle of egosystem over ecosystem. Without a forceful player changing this then the prognosis doesn't look good. This lack of strategic play is why I hold the view that OpenStack is a dead duck. Its future is with niches. I can't see this changing unless a miracle happens e.g. some level headed knight rides to the rescue with a few billion to spare.

Does commoditisation lead to centralisation?

tl;dr Maybe. 

This question came up again recently, so it's probably worth covering this very old ground. 

All activities commoditise to good enough components providing interfaces that allow higher order systems to be rapidly created - nuts and bolts, electricity, you name it. The process of how things evolve to become commodity is driven by competition (supply and demand) between all actors in the market. Evolution towards a commodity is inevitable if competition exists.

Do we end up with one interface or many? Generally, we tend towards very few for a single act though there can be constraints (e.g. geographical, political) along with specific forms of provision for specific (more niche) markets. 

Does this inhibit innovation? It's always worth separating out the interface (which represents the commodity or utility) from innovation above the interface (i.e. building  electronic goods which consume standard electricity supply) and innovation below the interface (i.e. operational improvements in power generation). It's worth noting that whilst the interface becomes standard, innovation occurs above and below the interface and the rate of innovation above the interface accelerates as the interface becomes more standard (componentisation effects).

Does that mean we end up with centralisation? Not at all. The question of central vs decentralised depends upon an entirely different set of economic characteristics and we can often yo-yo between both. Take for example, electricity provision for which behind the "interface" a wealth of change is allowing decentralisation of some of the supply. The reasons for centralisation vs decentralisation often have a lot to do with strategic game play i.e. when a market evolves from product to utility then if a few players perform well and the rest of the competitors run around like headless chickens then it tends to centralise around the few players. It doesn't have to be this way.

So, take cloud for example and in particular IaaS. Amazon has played a good game so far and built a powerful ecosystem which it exploits. The competitors (with the exception of Google and to a lesser extent Microsoft) appear to have been fairly clueless so far. Hence, we're likely to see centralisation around Amazon, Google and MSFT. It didn't have to be this way.

How could it not be this way? Well, the shift from product to utility was highly predictable and not an unexpected change. By 2004 it was crystal clear the change was about to happen but we had plenty of warnings as far back as 1966. So, this isn't the usual case of "disruptive innovation" where a combination of inertia and unexpected market change (i.e. product substitution due to some change in characteristic such as cable vs hydraulic excavators) disrupts a firm.  In this case, it's a highly predictable and expected market change which disrupts. This only occurs because of executive failure to prepare for this.

When Amazon launched EC2, the competitors had multiple options. For example, in '07 / '08 :-

1). They could have flooded the market with AWS clones and created a price war.  This would have increased demand (IT demand is elastic) beyond the ability of one competitor to supply (Data Centres are capital and time intensive) causing a fragmentation of the market. You would have created a federated market of clones and as the "clone" market grew to exceed the AWS ecosystem then it would in effect capture, dominate and own the AWS APIs.

2). They could have flooded the market with their own individual systems, creating a price war. Again a fragmentation play but also a more aggressive (and dangerous) ecosystem play. Ecosystems if properly used can enable a company to simultaneously increase innovation, efficiency, customer focus, stable revenue and wealth generation opportunities at a rate in proportion to the ecosystem. By flooding a market with your own systems, you're basically going for a sink or swim - either you'll build the bigger ecosystem and runaway with a chunk of the market or you won't and then its often niche land for you. Chances are we would end up with a few big providers and Amazon might not have been one of them.

3) They could have flooded the market with their own systems based upon a common system, creating a price war to fragment the market. In this case you're likely to end up with a federated market around the common system and assuming they quickly built a larger ecosystem (certainly possible in 2007) and didn't go off on some collective prisoner dilemma then it would have easily won creating a federated market without Amazon.

However, this didn't happen. The executives of the competitors did nothing and sat and watched AMZN steal the show. Today, AMZN ecosystem is so large that your moves are limited by its effect but it's still possible to build a federated market around AMZN or to co-opt GCE. Anything else is likely to end up niche pretty quickly. Though, niche isn't all bad as you can eek out some form of existence just not a very big one.

The point is don't confuse how things evolve to commodity and utility with the question of centralisation or de-centralisation. These are entirely different.

The process of evolution simply requires competition by all actors. The question of centralisation or decentralisation when a shift from product to commodity or utility occurs is usually a question of whether the competition is on the ball or clueless. 

Oh, and don't blame the engineers, culture or trot out the old "innovation dilemma" excuse - this is purely an executive responsibility. If centralisation occurs (which is likely) and you're not one of these big players then if you were a former giants, you've simply been outplayed. Strategic gameplay is critically important when it comes to change. 

It's like Canonical (Ubuntu) vs RedHat (RHEL). RedHat dominated the field and let Canonical steal the future. I'm sure, as we shall see over this decade, RedHat has hardly been the smartest player. Even OpenShift versus CloudFoundry doesn't appear to be going that well for them. They should have bought Novell, at least it would have forced IBM to acquire them.  Oh well, it does look like one of those ignominious endings awaits. Buy-out by Oracle or CA? I suspect it'll be something pretty miserable.

-- Update 21st August 2013

According to this recent article by @mjasay based upon Gartner's new research then "AWS Now Five Times The Size Of Other Cloud Vendors Combined". If I was a shareholder in any of those dominant hardware players of recent years, I'd be spitting fury by now. It's not like there wasn't oodles and oodles of warning.