The last twelve months

Last year, to the day, I wrote a post on my concerns on OpenStack and stated that in my opinion the next twelve months were critical.

Well, that twelve months is up. 

I don't see a benevolent dictator or a flourishing market of competitive providers with easy switching between them at scale. I do see a collective prisoner dilemma, a refocus on private cloud (a future niche) and capitulation in the public space with Amazon and Google gaining speed.

Back in October '12, I said

"I would like to see Open Stack succeed, there are many talented people (and friends involved). But I have my doubts because I feel it has wasted an opportunity, it has been very poorly led in my view despite its success in marketing."

Well, my view is that this project is not going to create the competitive public market we all hoped for back in 2010. There are outside chances it will be relevant due to the work of +Rick Clark, +Randy Bias and others but overall despite the claims of Mirantis that OpenStack will dominant everything and +Ben Kepes that is has thrown of its "dead duck" moniker - I don't buy it.

I'm fairly convinced that a number of companies will make a decent exit price around OpenStack, that a number of VMware based virtual data centres will come under pressure or be replaced by OpenStack . I'm sure some will claim that as success.

However, the grand idea was for a a future of public providers competing in a market with semantic interoperability based around an open source technology stack. Making such a grand idea happen needed more than just open source but good strategic play from co-option to massive scale investment. That hasn't happened.

Instead, what we're likely to see is consolidation of a market to Google, AWS and a few others. Fortunately, there will be a slow burn model around CloudStack / Eucalyptus and some groups within OpenStack to create a future more competitive market around open source but this will take considerable time. We're back into the old slog that open source found itself in the server market.

It didn't have to be this way.

I've got high hopes for Cloud Foundry to create a competitive market at the platform space around open source. I would wish that companies rather than trying to introduce alternative approaches which blur the market in order to support their dying past business models would just adopt. I expect them to however argue that differentiation on a commodity is key and the same old nonsense be repeated again. 

I would strongly urge people to get behind Cloud Foundry and ignore the rest. No thank you Mirantis, OpenStack has messed up one vision of competitive markets - I'd rather not see it mess up another.

Questions on how?

Twitter is an incredibly useful medium for numerous reasons but one of the things I like is that every now and then you're asked great questions. One of these for me was from Florian Otel on the use of incrementalism and the "art of muddling through".

To give a bit of background, when I talk about strategy it's all about the where (to attack) and the why (a relative statement of why here over there). Tactical choices are all about how you go about something and finally the what and when is simply implementation and operational planning. 

Most strategy documents I read have a tyranny of how, what and when and very little of the why because the where is almost always absent. I know they're called strategy documents but I usually refer to them as tactical and implementations plan with no strategy. On the most part, they're fairly hopeless.

Now in order to plan out a strategy you first need to map the landscape in order to determine where you might attack. For the last eight years I've happened to use a technique called mapping to do this though other techniques exist.

In figure 1, I've mapped out a hypothetical value chain of an organisation which is built from components (including activities, practices and data) over the state of evolution of the components. I will use this map to identify where I might attack and then determine why one route over another. 

Figure 1 - A Map

I'm not going to go through that exercise for now, since the above is a hypothetical example but instead I'll assume I've done the work and determined that the best option for strategic gameplay is three routes described in figure 2.

Figure 2 - The Strategic Play

The three routes are :

Step A) : A particular activity we consume is currently provided custom built and in-house but it is widespread and well defined enough to be suitable for provision by a product as evidenced by existing products on the market. I will therefore move away from our custom built example to using a more standard product with a view of minimising customisations. 

• How to go about it? I'd examine competing products for fit, check to ensure that data is extractable (i.e open data formats etc), determine standard market KPIs for implementation and probably implement with a waterfall method. A key part of this is ensuring that data is extractable because I know at a later stage the activity will evolve to a utility and for reasons of past business model it is unlikely that my vendor will provide the utility, so I'll have to move again. I'd therefore concentrate on what the cost of exit will be, aim to minimise it and certainly factor it into any purchasing decision.

Step B) : A particular activity we consume is provided as a product but it's widespread and well defined and suitable for utility provision. The technology exists to achieve this, I know customers are dissatisfied with the product cost but no utility provider exists. This is an opportunity for me. 

• How to go about it? If I have the technical capabilities then I'll aim to provide a utility service to the market based upon our experience of the product. We will focus on providing the utility through APIs and building up an ecosystem with an ILC model. Ecosystems are valuable future sensing engines if used correctly. I know existing vendors will have inertia due to past business models, this is beneficial to me. I know existing customers will have inertia due to past practices, changes in relationship (social capital), knowledge capital, prior investment along with concerns over lock-in. I'd look to counter by adopting an open approach (e.g. source). Since the activity is well known and defined, my focus is on industrialisation and hence I'd use a structured approached designed to remove deviation e.g. six sigma / ITIL.

Step C) : We've identified a concept for an entirely new activity which we believe has potential of being a differential.

• How to go about it? This novel act is uncharted by nature (being novel and new) and hence highly uncertain. It's a gamble but might provide us with a differential for our customers. I'd aim to minimise any costs by ensuring that underlying components consume commodity or utility services where possible. The approach we'd have to take is incremental i.e. we're going to be exploring our way and change is a necessity. I'd focus development on in-house with use of agile techniques (which include Test Driven Development). TDD is essential because though it incurs some overhead it reduces the overall marginal cost of change and I'm expecting lots of change. The approach will be one of minimal viable offering, quickly gathering feedback and "muddling through". We don't know what we will end up building, we'll have to find our way.

Now,  as per normal practice I'd break activities into small components with small teams (think FIST, Two Pizza etc) in order to focus on the right approaches, create the right cultural fit for that activity and use the right sort of people (pioneers, settler, town planners) but this is getting more into operational details. The point of the above is to show that once you've determined where and why, then the how varies accordingly. All three steps would probably occur simultaneously. Hence at the same time an organisation might embark on efficiency in one area, building of a utility in another and creation of entirely new activity with each using different approaches and methods.

Try doing that with one size fits all methods like "we're an agile shop", "we're a six sigma shop" etc etc. To answer Florian's question - incrementalism is a tactical approach (a how) to a specific type of problem. 

Now, if the above doesn't make sense to you, well I've been doing this for eight years and so it's easy for me to gloss over things and take them as granted. I will at some point write another beginner's series on this, just not now.

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.