Business Model Canvas ... the end of a long road.

I'm currently hitting a road block with the latest memes around business model canvas and it's driving me nuts. First, let me be clear, I find business model canvas an extremely useful tool but it's not the beginning but the end of a long road.

Whenever I look at doing something in business, the first thing I do is map out the landscape focusing on the user needs. In figure 1, is an example map (an old early draft) from a section of the security industry.

Figure 1 - Security Industry.

The next thing I do is look at WHERE we can attack i.e. the various plays open to us. This usually is an intensive process of discussion. In figures 2 & 3 are two example plays from a dozen odd potential plays in the map in figure 1.

Figure 2 - Play 1 - a commodity play around Identity.

Figure 3 - Play 2 - Trust as a Service

The map usually provides immediate cues as to what is risky, what has potential now and what has potential for the future. I then normally look at what steps we can use to make the plays happen (see figure 4) looking for supporting and complimentary approaches.

Figure 4 - Potential Steps

I then take these multiples WHEREs and examine the outside market, looking at competitors, inertia they have, inertia we have, what we can exploit, what capabilities are needed, where we can build ecosystems, what constraints exist, buyer / supplier strengths, likely economic effects - an example of a small part of very old map in a different field is provided in figure 5.

Figure 5 - Comparison to outside

I then normally pick a few of the most attractive WHERE's which we can influence highly (either through open approaches or use of dark arts) and have beneficial properties (constraints we can exploit, potential for ecosystems, poor strategic play by competitors) and run a few scenarios looking for how things are likely to evolve, potential for co-evolution, impacts of points of change, predictability of change, what's likely to emerge, what we should discontinue or sell elsewhere etc e.g. see figure 6 - from another industry.

Figure 6 - Scenario comparison

At this point, I normally have multiple WHERE's, the user needs, the potential impacts of changes, what we can influence, target markets and information on how to play the game. This can take a lot of effort, for a reasonable size business then you could be talking a few days work or even a week or so of hard graft. But at the end of this process then I'm at the point of saying WHY we should attack one space over another or WHY we should attack multiple points. I'll normally have a map and the background info to demonstrate this in a way that everyone in the organisation can understand, discuss and input into.

It's at this point we can develop our chosen point of attack - I can usually state all the activities , practice and data involved, how we should attack, what the user need is (and what we emphasise on), what components we need, where the constraints are (and how we exploit), what markets to focus on, our revenue models, how we should manipulate (e.g. open approaches) and estimate the likely cost structures from the components. I have a good idea of how to play the game, cope with competitors, who we should acquire and what to watch for. I'll have a pretty decent idea on how to play the game to our advantage.

I'll even have a decent idea of how to manage and organise around this, what we need to build, what techniques to use, where to differentiate, where to copy and what we need to experiment on etc (see figure 7)

Figure 7 - Managing a system

At this point, I'll have ALL the information I need to fill out a business model canvas (see figure 8).

Figure 8 - Business Model Canvas

I prefer just to use the maps since the business model canvas is an artefact of the process. However, it's a neat summary of the bits of the map (or maps) that I want us to focus on and hence I do find it can help. The map however provides the greater context and situational awareness is key with strategic planning.

Oh, and just for your info, mapping is the stuff I used when I was CEO of a Canon subsidiary and when I ran strategy for Canonical. I would never hand this off to some other company or agency. Mapping was important in understanding how to play the game which is what we would do next. Let me emphasise - WE played the game which meant WE had to understand the landscape that WE were competing in.

So, given I think Business Model Canvas is a useful technique then what's my problem with it?

I'm starting to get companies asking me what do I think of their Business Model Canvas which is all good. BUT, I normally respond with "can I see your map or some other expression of situational awareness, the plays, comparison to market / competitors and your scenarios examined?"

A disturbingly frequent response is "we don't have that but what do you think of our canvas?"

Let me be clear to everyone. I think you're foolish to even consider committing one cent to an idea expressed on a business model canvas without any situational awareness of the competitive landscape or scenario planning. The business model canvas is not where you start, it's at the end of a long road which could take a week to travel. Ok, it's better than the even more crazy ideas of not even expressing what you're planning to do in a clear form but the canvas is all about the 'how, what and when'. You really do need to answer the 'where' and then 'why' before you start using it. The canvas is the end of a journey and not what you fill in at the beginning!

Don't get me wrong. The business model canvas is an extremely useful tool BUT if you think that filling it out has anything to do with understanding strategic play then you are sorely misguided. Yes, you may well still be successful but you're not looking at the environment and that's a bad move on average as you're leaving more stuff to chance than necessary.

Aspiring for more Fiasco … again

The Times today screamed one of those eye catching headlines - "Whitehall IT Fiasco" - with a fairly detailed dissection of the HMRC Aspire contract. The relished shout of "failure" was only surpassed by the monumental fallacy of "the solutions". I think it's worth exploring why.

Lets start by simply taking the Times and its "experts" views that Aspire is a project that has 'spun out of control' with 'spiralling costs' and is beset by 'previous disasters'. I won't argue whether this is true or not but simply ask the question - why?

IT failure is not an unusual story in both the public and private sector. There is however a common factor at the heart of many of these problematic systems which is best illustrated with a map. Mapping, for those who don't know, is a process of comparing value chain against evolution. In figure 1 I've provided a map from current government system (I've removed the terms describing each component because it isn't relevant). The map is derived from three user needs (components A, B & C).

Figure 1 - A 'Wardley' map

The key thing about mapping a complex environment is it teaches you that ANY complex system contains multiple components at different stages of evolution. For example, in the above map there are 24 different components, some of which are in the 'uncharted' space (3 components - D, E & F) and some are highly 'industrialised' (G to M).

Now, each of those stages of evolution have different characteristics and require different methods to manage. For example, the uncharted space is best suited to in-house development with agile techniques because it's uncertain and it requires experimentation as the requirements are unknown. However the industrialised is best suited to outsourcing to a market with highly structured methods (e.g. six sigma). The industrialised is known, it's defined.

Now, key to mapping is to realise that there is no magic one size fits all method to management. Of course, when it comes to dealing with a complex system then you could decide to apply a one size fits all approach (e.g. agile everywhere or outsource everything) rather than apply appropriate methods to each component.  However, this 'one size fits all' choice normally occurs because no-one has a map and so they don't realise that multiple methods are needed.

Now, a 'one size' can be fairly problematic. For example, suppose we decided to outsource the entire of the system described in figure 1. We are likely to want to implement a contract which describes in detail what we're getting for our money - that sounds perfectly reasonable. The supplier however is likely to implement some process for managing any changes. All very sensible. However, here's the problem. 

If you look at the map, then components D, E and F are all in the uncharted space. This means we don't actually know what we want, those components will change rapidly. But if we've implemented a one size fits all contract across the entire system based upon an idea that we do know what we want, then we're going to get stung with the expensive change control processes for components D, E and F.

To be honest, most vendors seem to know this. The beauty of this approach for them is they profit handsomely from change control and they certainly (as the article points out) have "little incentive to keep fees low for changes". Even better than this, when the customer complains then the vendor gets to blame us for not knowing what we wanted and can get to point to other more industrialised components (those that didn't change such as G to M) as having been efficiently delivered.

It's all our fault! But we couldn't know what we want! We could only know what we wanted with the more evolved, the more industrialised components.  The fault is of course with the process. We should have never outsourced these uncharted components but instead we should have used agile, in-house techniques. By all means, we should outsource the industrialised.

A better way to treat this project is described in figure 2. 

Figure 2 - using multiple methods

However, vendors tend to dislike this concept because they make a fortune on change control processes. In some cases, the effective treatment of a system as components has led to cost reductions of individual components in the order of 99.3% - 99.7%. The sums of money (or profits) involved can be significant.

So, now let us turn to Aspire or what is described as the "country's biggest IT contract … heading for disaster". I can assume (as with most private company projects) that HMRC in the past didn't have a map, which is a pity. I can only guess at that the number of components involved in a complex system like this. So let us say it is 100 - it maybe more, it maybe less. 

Now with no map, I can't tell what components are evolved and what are not. So let's take figure 2 as a benchmark and generalise it for all projects. We know from figure 2, that there are 24 components. In the legend, I've quickly summed up how many of each type exist. About 12% are uncharted and around 42% are highly industrialised with the rest in between. So let's assume this "benchmark" is also true with Aspire … it's not much to go on.

So our guess gives us around 12 uncharted components and 42 industrialised components in our 100 component system. The 12 uncharted components are more in the experimentation phase, more suitable  for in-house, agile development techniques whereas the 42 industrialised components will be suitable for outsourcing to utility providers. The remaining are suitable for products ideally with minimal change. It's worth noting that you can also map data, practices and knowledge along with activities. 

Now, at the moment we can't say (without a proper map) if those figures are even roughly right but we can be pretty certain that Aspire isn't all uncharted and it isn't all industrialised. If you decide to outsource this entire project then you're going to be hit with excessive change control costs because those 12 uncharted components will evolve, they won't stand still and we don't really know what we want. No amount of specification will solve this. We have to (and literally are forced to) experiment. 

Of course, you don't want to run the entire project in an agile manner because at least 42 industrialised components are suitable for high volume, low cost, tightly defined utility like services. 

So lets go back to the Aspire article and look at some points in detail.

1) "it's heading for disaster", "it a fail" … well as the article seem to emphasise it has been a disaster for 20 odd years. There's nothing new here other than practices around how to manage complex projects have significantly changed during that time.

2) "plans to split into 100 parts" … seems to be cited as the problem. But hold on, this system probably contains a 100 different parts. So we want to pretend it doesn't?  Breaking complex systems into relevant components rather than pretending it is one thing doesn't seem a bad idea. We don't build cars by pretending they are one thing, in fact we often have complex supply chains meeting the needs of all the components. Now, we could simply break Aspire into the relevant components and offer one supplier (as we've done in the past) all the components to provide. Ideally you'd use a market but even with a limited choice then the advantage here is we can make sure appropriate methods, measurement and contracts are deployed based upon the component. It might make a little bit more work but we're talking about a project which already has a running cost at over £8 billion and is considered to be 'spiralling out of control'. From Amazon (see two pizza) to USAF (see FIST) to Manufacturing (see the entire industry) then organisations have learned how to manage effectively componentisation with supply chains and they certainly don't find it "too difficult to manage". Why not here? Why not Gov? Treating components appropriately seems to be the sensible thing to do.

3) "It will cause chaos" … cue the old "riots on the street" line.  Given construction, automotive and many other industries have no problem with componentisation and given a worst case of getting one supplier to build all the components with appropriate methods (which they're likely to outsource some of this anyway) then I can't see how we jump to this notion. We've continued to repeat the "one size fits all" approach which has led to countless cost overruns and failures. This seems to be scaremongering and I'm not sure what the objection here is to learning from other industries.

4) "hundreds of experimental startups" - ok, this one is becoming surreal. If you break a complex system into components then you're likely to give a large number of highly industrialised components to established utility providers (e.g. companies like Amazon for infrastructure) but you won't give them all the components because some are going to be experimental (they're uncharted). For these components then you're likely to do this in-house with agile techniques or use a specialist company focused on more agile processes. I'm not sure how the "experts" jump from componentisation (a sensible action) to giving it all to "hundreds of experimental startups". This wreaks of nonsense and a desire to keep the current status quo.

5) "interfaces" - this is where we use appropriate standards. Pretending a complex 100 component system with uncharted and industrialised components that have interfaces between them is in fact one system with a one size fits all method and non existent interfaces is fantasy. Those components are there, same as the interfaces. The complexity doesn't go away simply by "outsourcing". All you've done is try and pretend that the complex thing you're building is somehow simple because then it's easier to manage. It's barking on the delusional and it's extremely poor and dated management. It would be like BMW or Apple outsourcing their entire product lines to someone else and trying to have no involvement because it makes management simple. Whilst some have apparently said that HMRC "doesn't know what it's doing", it has obviously realised that doing the same failed process over and over again won't make things better. Good on HMRC.

6) "more expertise" - let us be clear, so far the "expertise" has managed to create "spiralling", "out of control" projects over a 20 year period. Yes, the project "spiralled out of control partly because of four major renegotiations" and yes, three of those negotiations happened between 2006 to 2009 with some absolute corkers like "granting exclusivity" and costs rising from £1bn to £8.1bn by 2009. It's worth noting that when this all happened was well before any apparent "imposed ban" on management consultants. By the way, the rate of cost growth seems to have dramatically slowed since the supposed ban. 

So, can I check that what we actually need  is more of "spiralling" and "out of control" costs because that's what the "experts" seem to bring or at least the data points to this. I certainly agree that the past vogue of outsourcing had weakened the government ability to negotiate but this is changing (see OCTO, see GDS etc). I can understand why we need to develop skills in contract management and supply chains which seems to be happening as this is a perfectly reasonable thing to do. Other companies have, why not UK Gov?  I'm not sure why we want to take a backward step here.

7) "500 people to manage 100 contracts" - ok, this seems to be one (and there are many) of the most exaggerated claims. I used to work in purchasing, I managed around 100+ different active contracts on a daily basis with over 100 different suppliers buying everything from stationery to missile components to jet fighters. I can sort of see the argument for a team of 25-50 (at a push) but 500. I'm guessing the "experts" would have us outsource that as well, probably employing them into the bargain. 

8) "Labour" - you could point out that such monolithic disasters using inappropriate mechanisms and excessive outsourcing occurred during Labour's reign and even make pointed remarks about Ed Milliband and Ed Balls involvement. Yes, the coalition has been carefully trying to unpick the mess that was created. However, it seems pointless to dwell on the past unless there's some belief that Labour is hell bent on recreating it. I don't believe that's the case, so this is just unhelpful point scoring by the Times. Not needed.

Overall, if the report is correct then yes we seem to have a mess of a project based upon outdated methods of thinking, The problem is that the "experts" then describe the same failed and outdated modes of thinking as some sort of future solution. The article doesn't stand up to scrutiny, you could drive a truck through the gaping holes in this one. 

Yes, some past disasters are bearing fruit and need to be fixed and no, that doesn't involve repeating the same mistakes which made those disasters. As Einstein pointed out, "insanity is doing the same thing over and over again and expecting different results". HMRC seems to be learning that.

But learning is not much of a headline or a doom laden story. Which then begs a question - why was this article really written? 

Well, as the article points out the changes have "created a backlash" and there's been "concerns over the merging of back office systems like HR and payroll". However, the civil servants I've met seem broadly supportive of the changes and understand the need to do so. Government isn't there to waste taxpayers money, it's there to ensure it is wisely spent on things we need.

So, who benefits from encouraging a move back to the past and creating fear, uncertainty and doubt over the current changes and practices? It's worth noting that these change have simplified Government websites, won design awards, led to significant cost savings (National Audit Office) and propelled UK Gov IT from a backwater to a model being copied by other Governments. 

The question you really have to ask is who stands to lose the most by the continued progress and wants to paint a picture of heading towards disaster. There are two fairly obvious candidates and this is the real question that we should be looking into. 

As for HMRC, well problems in IT are not new and it's good to see that changes are being made. Many of the problems of the past are almost certainly due to single size contracts and the "expert" opinion involved. Obviously you're ruffling feathers and that's a good thing. Keep it up.

As for the "experts" - bah humbug. Given the widespread use of componentisation concepts in multiple industries over the last decade then I'd be more inclined to haul these "experts" in front of the Public Accounts Committee and where necessary hunt down those involved in this mess and sue them into oblivion for negligence. As a taxpayer, I save my wraith for them and not HMRC. I fully understand the awful games and exploitation of change control for commercial gain that happens. My preference is to use real experts which Government is already developing in groups like GDS etc.

Good on HMRC, Good on UK Gov IT. Keep going.

---

P.S. For clarity on any bias I might have. Though I'm not an employee of UK Government (either full time or as a contractor), I do spend time at various Government departments teaching them how to map out complex environments along with observing impacts. UK Gov is a member of the private research organisation that I belong to (the LEF) and I'm given considerable freedom by the LEF and UK Gov to observe the changes. I also (many years ago) wrote the 'Better for Less' paper with Liam Maxwell et al. I'm also 'old Labour' and whilst I might strongly disagree with many coalition policies,  I'm highly supportive of the positive changes that I see being led by the Cabinet Office. You'll often hear me saying "Rock on, Francis Maude!" which gives you an idea of both my age and that I can't give two hoots about politics when it comes to having the right person in the right role.

How accurate is a Wardley Map?

I was recently asked how accurate the 'Wardley' maps produced of a competitive landscape are? An example map (an early draft for a border control system) is provided in figure 1.

Figure 1 - An example map.

So how accurate is it? 

Well, first all maps are simply representations of what actually exists and are hence imperfect. Second, mapping is still in its infancy i.e. we're only just learning about how to map competitive environments, how to deal with bias, how to learn and exploit the landscape. We've had about a decade of practice at tops and there is a long way to go. So whilst the maps are useful tools for discussion, for risk mitigation, for management, for scenario planning - they are not even close to being accurate.

In business, I'd reckon we're about the stage of early Babylonian maps when it comes to mapping out the competitive environment. Very basic, with some understanding of principles but still a lot more useful than no map at all.

Before geographical maps we used to rely on story telling and poems with named visible celestial features and prominent geographical landmarks to convey navigational directions. It's amusing how story telling is currently the vogue for business strategy. We've got a long way to go before we can reach the finery of military strategic play and situational awareness ... a very long way.

Dungeons and Dragons vs the art of business strategy

For those who have ever played Dungeons and Dragons then there are some basic practices which become ingrained. These same practices appear in MMORPG such as world of warcraft (WoW). These include ...

1) The importance of maps. Before launching your team of elves, halflings and dwarves into the midst of a battle then the first thing you do is scout out the landscape and improve your situational awareness. Understanding the landscape is critical to strategic play, to learning, to using force multipiers and to not getting spanked (beaten soundly by the opponent).

2) The importance of capabilities and roles. The biggest battles require a multitude of roles from damage (those who do our spanking usually from range) to tanking (defensive protection) to healing (those tanks get spanked a lot and need healing from our Clerics) to crowd control (those Wizard sleep spells aren't there for just looking at). The way you play and how the roles are deployed depends upon the scenario. Of course, without situational awareness then you're at a huge disadvantage.

3) The importance of team play. A multitude of roles requires team play which means communication, co-ordination, acting in the interests of the team etc. If you're taking on a Lich or a Beholder then your team (unless massively overpowered) better be on the ball. 

4) The importance of preparation. There's no point turning upto the fight with a Sphere of Annihilation if you don't know how to use it. Preparation, the role of each group, working with each other, timing and discussion of strategic / tactical plays are all essential elements to good play.

So, how does this compare to business?

1) Maps. In general we don't have them. Most companies suffer from poor situational awareness being caught out by predictable changes. The most telling factor here is that business strategy is normally a tyranny of action (how, what and when) as opposed to awareness (where and why).

2) Capabilities and Roles. On the whole, we do a bit better here as we recognise multiple capabilities (aptitudes) are needed. However, we often fall down by not considering attitude, the scenario (we have poor situational awareness) and isolation (operation in silos).

3) Team Play. We certainly try, often having team building exercises which can be a bit hit or miss. We often complain about communication despite the plethora of tools available. The problem can usually be traced back to poor situational awareness - if we don't know the landscape and create a plan of attack based upon this (replacing it instead with vague notions of vision or a story) then it's difficult to communicate how things are actually going.

4) Preparation. Almost non-existent. In some areas we might attempt scenario planning and a few exec games (e.g. imagine you're a startup trying to disrupt your business) but on the whole we're often so busy with immediate work (e.g. firefighting) that there is little time to build an effective and prepared team. The largest guilds in some of these MMORPGs have many hundreds to thousands of players supported with extensive wikis, communication mechanisms, training and development, tactical game plays, UI engineering, structure, leadership, specialist cells and information systems. 

There's an awful lot to be said for learning about these aspects from online games - though it's rarely done effectively. However for anyone under the illusion that business is some bastion of strategic play then can I suggest you spend a few minutes either watching an experienced group play D&D or an organised raid on WoW. Those people tend to use levels of strategic and tactical play that businesses can only dream of.

Fortunately in business we're often up against other organisations that equally lack situational awareness, suffer from isolation, have weak team play, poor communication and lack preparation. The effect is somewhat remarkably similar to a group of inexperienced D&D players just charging at each other. An exciting brawl of chaos with often single participants (hero players) making the difference. Of course, face either team (or in fact both teams) against an experienced and well rehearsed group then it stops becoming a brawl and starts becoming a massacre. Opposing Clerics get wiped first, followed by crowd control, tanks and then poor (and undefended) damage dealers.

In the world of business, there are some really dangerous groups out there e.g. Amazon. Don't expect to go up against them with the usual 'Charge!!' approach. You won't last long. That's a hint to those gaming companies starting to be concerned about Amazon's encroachment into their space. Start learning from your own online players.

Cloud, 2016 and onwards ...

For me, 2016 will be an interesting year in cloud. This is fundamentally because I'll get to test whether a specific model that I built in 2005 (and wrote a business case on - the Zimki project) has any semblance to reality or not. There were numerous 'forecasts' from the model across multiple industries extending from 2015-2025. Two of these I'll mention because I've talked publicly about both and this is timely for me as I'm working on a piece on predicting the predictable for the LEF,

The first 'prediction' was that by 2020, utility computing (in all forms) would exceed $1trillion p.a. and that 'on premise' utility computing (what we call 'private cloud') would represent around 5% of the total. I've said this publicly several times and I've no reason to change my view despite the long range (15 years).

@geoffarnold : I'll stick with what I wrote '05. By 2020 utility compute market is almost $1T and private (on prem) cloud < 5% & declining.

— swardley (@swardley) May 9, 2013

The second 'prediction' was that at some point during 2015 to 2017, the decline of private cloud would start to kick in. Private cloud was always a 'transitional' model in my view. I've talked publicly about this part of the model since 2008, a year in which I narrowed the forecast down to the later part of 2016. More recently, I've said that I expect this time to turn into a bit of a bloodbath in that space. Again, this was a long range forecast and yes, I've seen no reason to change my view.

The problem with long range forecasts of this type is there appears to be a very specific uncertainty principle between the predictability of what and the predictability of when i.e. we can often accurately assign probabilities to what is going to happen but not when or vice versa. There are 'ways' to cheat this with weak signals but alas I have only ever had the most wobbly of evidence to support these weak signals.

Over the years, I've tried varying weak signals, experimenting with componentisation of forecasts, changing time ranges, altering risk of forecast and other techniques.  Bit by bit, I've been collecting data on veracity, on failures etc. It's still relatively early days and it'll take me at least a further decade before I'll know how supportable the weak signals are (if at all) and start feeling comfortable talking about it. There are some particular aspects of the work that I'm highly 'uncomfortable' with.

Hence 2016 will be an interesting year for me, part of the journey. I'm about halfway there with this by my reckoning - of course, that's a prediction which could well be suspect.

Amazon just bought ...

(or more specifically is in the process of buying) ... a further piece to the gaming industry puzzle.

Oh, shock!

@dermotcasey : NB IMHO I'm expecting AMZN to chew up gaming platforms, take a big bite out of grocery and then chow down on insurance.
— swardley (@swardley) November 16, 2012

Projects, Products, Open Source and Proprietary

A couple of points to note on terms. I'll use figure 1 and 2 to describe the process of change. For those completely unfamiliar with mapping then I'd suggest watching the video and reading through the slides provided in the early post on 'Playing Chess with Companies'.

Figure 1 - A 'Wardley' Map

Figure 2 - Evolution

From figure 1 : the overall map might be referred to as a system, line of business, programme, environment or even a project. It depends upon what you're looking at. Any complex environment however can be broken into multiple components sub components describing activities, practices or data. This is what figure 1 shows you - a complex environment consisting of multiple components.

Point A - Evolution (the x-axis)

The x-axis of a map describes evolution and you can read more about how this was created in this earlier post. The actual pattern I first used in 2004 at EuroFoo but it took until 2006/2007 to collect enough data to confirm it. Figure 2 shows how the pattern and the different domains on that x-axis are related. The terms here are very specific. I've used the same letters on both figure 1 & 2 to show the links.

Point B - Genesis : if you look at figure 1 you'll note point B - the creation of a new and novel act. Please note, this does not mean the first time that YOU have created the act but the first time that THE act itself has been created. If you examine figure 2, you will note that Genesis (also noted as point B) has low ubiquity and certainty. What this means is the act is rare, poorly understood and hence likely to change. Other terms used to describe Genesis are innovation, original, origin, unique etc.

Point C - Custom built :  refers to the re-implementation or copying of the act by others. From figure 2, the act is still fairly rare (i.e. low ubiquity) and poorly defined (i.e. low certainty) but it is more common and better defined than genesis. Such acts are also often described as bespoke, projects, own build etc.

Point D - Product :  the act has now become common and well defined enough (see figure 2) that products can be introduced. This is a world of feature differentiation, competition between vendors, development of brand etc. During this time we often see rental services appear (see figure 2).

Point E - Commodity :  the act has now become common and well defined enough (see figure 2) that feature differentiation no longer matters. The act is widespread, well defined and suitable for volume operation provision of good enough components. During this time we often see utility services appear (see figure 2) such services often being described as platforms.

Ok, so that's the basics of evolution. Now a couple of additional points are needed.

Point F - Uncharted to Industrialised : the map in figure 1 is not a static diagram as every component is evolving (from left to right) due to competition (supply an demand). As the acts evolve their characteristics change. Hence :-

• Uncharted space (genesis) - acts are novel, rare, poorly understood, constantly changing, require experimentation, future sources of worth, points of differentiation, unmeasurable etc.

• Industrialised space (commodity) - acts are common, well understood, stable, predictable, cost of doing business, volume operations, measurable, undifferentiated etc.

Everything on the map is evolving between those two states as long as competition exists.

Point G - Methods : because components are evolving between polar opposite characteristics (uncharted to industrialised) then the methods you require are also different i.e. Genesis requires agile techniques wheres commodity requires approaches like six sigma. Since any complex system will have multiple components at different stages of evolution then any environment is unlikely to be suitable for a single size method and instead you need to use both whether agile + six sigma or push + pull or networked + hierarchical or Hayek + Keynes.

Point H - Manipulation : points on the map can be manipulated by either accelerating or de-accelerating evolution. This is done by changing competition, for example open approaches will tend to accelerate. Patents, FUD and constraints can be used to de-accelerate.

Now, on the question of open vs proprietary then there is little evidence to suggest that either approach is better for the genesis of a novel act (I undertook a research report on this question back in 2011). However, there's plenty of evidence to show that an open approach will quickly drive an act to a more evolved state and that an open approach creates natural advantages (due to switching, interop etc) in the more evolved states (i.e. the more industrialised). 

It should also be noted that evolution equally applies to activities, practices, data and knowledge. When it comes to basic core research (the creation of novel concepts etc) it is worth noting that the majority of this is government funded (see national science foundation study) as opposed to applied research (used in developing products etc). However, the most significant changes in our society don't actually come from the genesis of an act (i.e. the first source of electricity provision - the Parthian Battery in 400AD) but instead from industrialisation of an act (Westinghouse and Tesla, utility provision of A/C electricity).  Hence, if a Government wanted to accelerate the rate of change in society and overall progression towards a more technically advanced society then the logical thing would be to open source / open commons all core research in order to drive it to a more industrialised state.

On the origins of this work, the map - commonly known as a 'Wardley' map or value chain mapping (though the latter term can be confused with Kaplan's value chain maps which are something entirely different) - and the evolution axis are entirely original pieces of work dating from 2004-2007. They are provided creative commons share alike purely for the reason of encouraging industrialisation of the process and improving situational awareness between companies. I have my reasons for having open sourced this method - part of which was contribution back to the community and the other part was around encouraging progress.

A rough guide to competitive mapping

I've been asked for a lot of advice on mapping recently. Some of it has been fairly basic, so I've put together a rough guide to get people started.

Steps for mapping - a rough guide from Simon Wardley

Basic rules of mapping

I've been asked for a basic set of rules on mapping. Tough question, so I thought I'd simply write down the process by which I develop my own maps. This isn't a list you should follow in stepwise order but instead a continual set of guiding principles to be applied. Be warned, it's rough notes.

Focus on Needs

The most important part of any map is the user need. Take care not to confuse this with your own needs, they are not the same. Needs change over time, new needs can appears as activities evolve. Don't ever think needs stand still. If you have multiple types of users then there's nothing wrong with creating multiple maps.

Meaningfully Tiny.

When mapping you should always aim to break down systems into as small a components as possible. In some cases you might want to have a high level component and then go and create a separate map for it e.g. a high level map (think world atlas) and then more detailed maps for components of interest (think street view).

Act Appropriately

When looking at a map, you want to do the minimal possible for creating whatever it is that you've mapped. Look to outsource commodity components or consume utility services. However, for those things you need to build then use an appropriate set of methods e.g. agile for development of novel components, six sigma if you're building an industrialised service, lean if it's a product in between.

Challenge Constantly

Whenever you have a map, share it with others. Get them to question the map, challenge the assumptions and you need to listen! Look at the outside market, especially mature markets. Challenge biases. Remember the map is fluid, things will change over time.

Order! Order!

When using your map to plan your attack and try and change a market or to build and exploit ecosystems or to use any of a hundred different tactical approaches then remember the order!

• Where before Why - understand where you can attack first.
• Why before How - understand why you should attack one space over another.
• How before What - determine how you're going to approach (the tactical plays) before the what of action.
• What before When - determine what you're going to do to make this happen before finally adding in the when.

Good Enough

No map is ever perfect. You can spend a lifetime trying to perfectly map something by which time it has all changed. The purpose of a map is to improve situational awareness and it doesn't take a great deal to do this. Think hours, maybe days when mapping before you start to act. Longer than that and you're taking too long, though obviously if it's your first time at mapping then give yourself a bit of leeway. Remember your map isn't going to stand still, it'll change.

Adapt to Facts 

To repeat - No map is ever perfect -  be prepared to change it, to iterate, to adapt to the situation on the ground, to events as they happen and to new sources of information. A map is a fluid instrument. 

Learn

Record what worked, what didn't and what patterns emerged. Maps are fundamentally a communication and learning instrument as opposed to a pretty visualisation for a presentation. They're often messy but that's not a bad thing.

Start
Probably the most important rule of all. You can't learn about mapping by reading about it. You have to go and do it, you have to try it. It's a bit like playing chess, there's only so far that reading books will get you. Eventually you have to play the game.

It's not really a catchy list but I thought it might help some. 

A corporate strategy guide to taking a holiday.

Today, I announced to my partner I had devised a corporate strategy for taking a holiday. 'What' we were going to do was take one and 'How' we were going to do it was 'By Plane' and 'When' - next week!

Sam, gave me one of those steely eyed stares, followed by the question 'Why?'

Quick as a flash, I responded 'Because 67% of other people have holidays!'

'And where are we going?' came the reply.

'No idea' I exclaimed, adding 'But I've got the why, how, what and when sorted. I've even created a story for this, would you like me to explain?'

Copying others is not a strategy!  Why is a relative term i.e. why here over there. If you don't have an understanding of where you can go, where you can attack then everything else - no matter how well crafted the story is - is basically pointless. 

Of course, understanding where requires some form of map even if it is one that has become embedded in our consciousness. If I had said, 'Where should we go on holiday - Tuvalu or Transnistria?' then I'd suspect a few alternative 'wheres' would have been suggested after which we'd end up discussing 'why' one over another. 

Whenever someone produces a strategy document you should first ask them to explain the 'Why?' of the strategy BUT before they start, interrupt and say 'Before explaining the Why we chose one set of options over another, can you first explain where we had the option to attack?'

If you're feeling evil, ask them to show you a map of where you could attack and where you currently are.

Keynes vs Hayek

The problem when looking at economic change is that predictability is not constant. By predictability, I mean our ability to assign an accurate probability that an event will occur. As activities evolve they transition through different economic states - one of peace, one of war and one of wonder. Those different states have different types of predictability.

For example, in the peace state (the time of products and rental services), we know that evolution towards more of a commodity will occur because evolution is driven by competition which depends simply upon the aggregate actions of all players. There is a high predictability [P] of what will occur. The problem is, that evolution involves stepwise changes which depends upon the actions of individual actors and hence the predictability [P] of when the change will occur is low.

So, let us take an activity (I've drawn this in figure 1 below). A[1] is an act that is evolving through competition and has various stages from A[1] to [A4]. We can often say what will happen (e.g. it will become more of a commodity), just not when. Keynes is right, we can predict macro effects e.g. the P[what] but so is Hayek, those changes depend upon individual actors actions, hence P[when] is low.

Figure 1 - Predictability and the economic cycle.

Now, as the act evolves from A[4] to A[5] and becomes more industrialised (normally represented by either commodity or utility services) it initiates a state of war in that industry. This has known effects including disruption of past vendors stuck behind inertia barriers, co-evolution of practice forcing changes to organisation and a rapid increase in novel activities (e.g. B[1]) leading to a state of wonder. Now this 'war' phase is usually reasonable predictable in terms of what will happen and through weak signals also when this change will occur i.e. P[what] and P[when] are moderate.

The state of wonder however has high P[when] i.e. we can often quite precisely say when it will occur. However what will appear? Well that's another matter. The P[what] is low as the novel activities are uncertain by nature, they have the navigational characteristics of uncharted spaces.

So with electricity, as with computing, as with many industries, the P[what] of the act itself becoming a commodity (e.g. A[5]) are quite well known and we can literally reel off the standard effects. But the P[what] of any new higher order systems (e.g. B[1]) built upon this commodity component is low. 

We can say what the effect of computing becoming a utility is likely to do but not what magical wonders will be built upon it.

Now, here is the fun part. When you start to examine predictability e.g. P[what] & P[when], you can categorise different areas of change. It's not all the same - see figure 2.

Figure 2 - P[what] vs P[when] - draft, incomplete, changing

Furthermore when you start to examine multiple points of change, you discover that various aspects of the economy are not in the same economic state - see figure 3.

Figure 3 - Economic state of various points of change - draft, incomplete, changing

Then, when you combine the different points of change plus what is and what isn't predictable with the value chain of different industries, you start to discover that changes themselves can be simultaneously sustaining and disruptive to different industries - see figure 4.

Figure 4 - Impacts of changes on various industries - draft, incomplete, changing

However, though it's complex there's a whole bunch of things you can anticipate. For example, whilst you might not be able to anticipate disruption in the peace phase (i.e. product vs product discontinuity), you can anticipate disruption from the shift of product to utility (i.e. the war part) well in advance often by a decade by looking at weak signals (e.g. publication types). Furthermore, you can anticipate it effects (rapid development of higher order systems, co-evolution of practice) and by looking at the value chains across organisations then you anticipate its magnitude.

So, this leads me back to the whole issue of Keynes vs Hayek. Our economies aren't in one state but different parts are in multiple states, varying between industry in how they're being impacted by multiple points of change at different stages of evolution. In certain circumstance this can manifest itself as larger business cycles but the application of a single method to a market by treating the market as one thing is fundamentally flawed. 

I'm not pro Keynes or pro Hayek, I'm pro both. I view it is necessary to use multiple methods simultaneously based upon deep situational awareness. It's no different to agile vs six sigma, insource vs outsource or push vs pull. With any large complex system, it's never one but both - see figure 5.

Figure 5 - multiple methods on a single large complex system - an old map of High Speed Rail IT.

I strongly view competition as the key element of ... competition. This requires the use of both free market and Government interference for reasons of market failure which includes market under investment, inertia to change etc. The effective use of Government force (the guiding hand) however depends upon good situational awareness. But where better to gain good situational awareness of changes from the market itself?

Alas when you examine the technology industry, then you find situational awareness (as exhibited by strategic play) is not uniform but varies from the good to the fairly atrocious - see figure 6.

Figure 6 - Market variation in strategic play in high tech industry.

But beyond often poor situational awareness, what you quickly learn is that when companies become large and successful then the one thing they don't appear to like is change. Organisations are not good at managing change, they are generally not designed to do so and they become enamoured of their existing business models and practices. Even the financial markets exhibits rampant inertia to change. Many would act in ways to limit competition, forming oligopolies or monopolies where possible, using everything from lobbied regulatory barriers to intellectual property to establish a steady state. 

This resistance to change, these attempts to limit and undermine competition have their counterpart in our social structures where those who have amassed the greatest wealth and income inequality attempt to maintain that position. Whether social or industrial both effects if left unchecked have the same consequence, the limitation and eventually stagnation of competition. Alas, the market exists beyond one nation and such stagnation can only lead to collapse. All nations are in competition and if you allow yours to stagnate either through social or industrial inaction don't expect another nation to return the favour.

There is a fundamentally important role of Government in maintaining competition and interference where necessary. The libertarian ideal of a rampant free market is as much of a fantasy as the centrally planned system, ignoring the importance of inertia and competition combined with the gravitational effect of wealth (it tends to accumulate) and human nature. Both systems will tend to inhibit competition through the establishment of an oligarchy.

However, I don't believe we've seen yet seen the most effective forms of Government organisation. Certainly China seems to exhibit signs of high situational awareness and gameplay. Others tend towards more dogmatic and singular methods. At some point in the future, I suspect we will all learn that multiple methods are needed to manage an inherently complex and evolving environment. But managed it must be, both in terms of industry and society.

In the meantime, when it comes to Hayek vs Keynes - I agree with both.

P.S. Don't confuse this with agreement with Friedmanism.

Income inequality, growth and mobility.

Income inequality is a useful tool for encouraging competition and progress. But, with income inequality there comes privilege through access and opportunity (i.e. better education for children) and a tricky issue that wealth tends to gravitate towards wealth (i.e. the return on capital depends upon how much capital you have).

However, a fairly high range of income inequality appears supportable as long as there exists opportunity and such opportunity is expressed through social mobility. The thorny issue is that those who have amassed wealth tend to want to reduce social mobility i.e. they want to maintain it for them selves and their offspring. They don't say this directly, they believe in opportunity but they just don't seem willing to accept that such opportunity for everyone means that they or more importantly their children must also be exposed to failure. So wealth has a tendency throughout history of concentrating within a privileged elite.

From a competition perspective, some inequality is good as long as you have social mobility. You not only want to encourage people in a society but give them the opportunity. Governments have to play the role of rebalancing the desires of the elite with the overall interests of the nation and this is nominally achieved through taxation and investment. Of course, the elite would want you to reduce the state and taxation despite most innovation in a society being government funded. More often than not, the elite have the power to do this.

So, rather than ending up with the most able people, we tend to end up being run by those born into privilege. In the pursuit of maintaining privilege and wealth, we often reduce taxation and thereby innovation in our society. The masses are left watching a society where income inequality grows, growth stagnates and opportunity declines. Overall, the state of competitiveness in a society reduces and this process then continues until a death spiral causes societal collapse. Everyone loses, especially the elite.

This has happened numerous times in history. Decline of a nation is normally preceded by decline in social mobility and excessive concentration of wealth in an elite. On the other hand, the most prosperous times for a society, the points of 'growth' are usually associated with high levels of social mobility and somewhat more moderate income inequality.

Why do I mention this? Well, when I look at China (both inequality and mobility) and compare to the US then there's only one conclusion I can come to. The US is a train wreck about to happen. Ruled by an often inherited elite (an oligarchy) that is quite happy to run the society into the ground to maintain their own position? They probably don't even see it this way. Maybe they think it's just how the market works or maybe they just don't think? I know some are questioning the wisdom of this - the pitchforks are coming - but the inertia to change is building and becoming embedded. 

It can only be a matter of 10-15 years before this becomes generally apparent, that China will dominate technology and Silicon Valley will decline in importance. This isn't happening overnight, by my reckoning then 2025 - 2030 is when the wheels start coming off the tracks. There is almost nothing you can do about it or certainly will be allowed to do about it. In any case, the US and Silicon Valley have both had extremely good innings. Of course, for some it will be a great shock - they've become habituated to the idea that the US dominates as though this is some sort of steady state, alas competition and the role of nations is much more fluid over time.

Could the US fix the problem? Of course. Will it? Of course not. The very things you need, higher taxation and re-distribution through government investment are the very things the elite and their media machines are dead set against. Of course, everyone in a position of power is going to agree that we need competition and opportunity. They'll all agree that we eventually need to solve the problem of inequality. Magic thinking will abound 'lets make everyone rich' as if wealth was an absolute rather than a relative. The problem is self interest. With mobility what they need is a solution that doesn't effect them, alas they are the "problem".

So, the only real question for me is whether China gets the crown or whether we in Europe can nick it in time. Obviously I'm hoping for the latter and the next decade will be crucial for this.

From ecosystems to open source to force multipliers - I've been a silly billy.

I've done numerous different talks over the last decade often with the same title - it's an old joke of mine. These talks have covered everything from the use of IT as weapon, to open source, to manipulation of markets and the importance of ecosystems and platform plays. Yes, there's a lot of common memes throughout. But in looking back, I realised that almost all the talks could have been improved if I had simply introduced mapping. 

The reason why I didn't do this before was because I didn't think it was important preferring instead to use other graphical means. It was purely by accident that I discovered that people didn't understand mapping which followed a rampage on my part to explain it to everyone. Silly billy.

Anyhow when I compare the videos from ...

PRE the accidental realisation (i.e. just before)

2010 - OSCON

2011 - STRATA

POST the accidental realisation (i.e. just after)

2013 - Alfesco Summit



2014 - OSCON

I can see now that not talking about mapping earlier and focusing purely on the economic patterns was a mistake. Note to self - must do better next time and stop assuming everyone knows this stuff. In my defence for those earlier presentations, the concept of mapping was probably too much of a leap and some of the presentations do actually contain mapping constructs - I just didn't explain it properly.

By the way more slides and details on mapping are provided here. 

A new photo

I don't photograph very well. 

I'm not exactly what you'd call a 'looker' especially with the wonky eyes (one tends to wander off when it's bored), the scruffy beard, the unkempt features, the lack of sleep and the shockingly poor teeth (I'm a smoker who is English ... never a good thing). Let's face it ... even my mum calls me a 'wreck'.

Still, Trav Williams at Broken Banjo Photography was taking speaker photos at OSCON and has somehow managed to create something decent. I'm assuming this involved hours of photoshop along with excellence in photography. Well, I now have a new headshot ... welcome to the new 'me' ... which is almost identical to the old me, even with the same tweed jacket, check shirt, cords etc etc etc.

On the accidental use of mapping

For those who know me, I've been using a technique called mapping to compete against other companies for a considerable amount of time. 

What you probably don't know, is that I actually thought everyone was doing this. It was by pure chance I found out that this wasn't the case.  Several years ago, I was sitting down with Liam Maxwell (UK Gov CTO) and explained a problem using a map. Liam's response was 'How did you do that?'

My immediate thought was that he was asking how did I solve that problem. It quickly transpired that the question he was asking was 'How did I do that mapping thing'. It was shortly after this that I discovered that something I thought everyone was doing turned out be to something that very few people did.

Mapping is a powerful technique in my opinion for everything from project to risk management, from strategy to gameplay, from organisation to culture, from scenario analysis to comparison. It might not be everyone's cup of tea but I'd always recommend that you give it a try.

I've provided three links, a keynote (OSCON), the slides from a 3 hour tutorial (OSCON) and a simple step guide to get started.

Keynote

Tutorial Slides

Playing chess with Companies from Simon Wardley

For a step guide, start here.

Also, if you do find it useful, don't forget to say thanks to Liam Maxwell (without whom, I'd have continued thinking everyone was doing this and probably not have said quite so much) and also say thanks to my partner in crime, James Duncan. Do remember this work is provided under creative commons share alike. These maps are often nicknamed 'Wardley Maps' which I do appreciate.

Finally, don't forget to say thanks to CSC's Leading Edge Forum who have allowed me the time over the last couple of years to perform some important tests including a population study on organisational evolution and the delta between companies in terms of gameplay (see figure 1)

Figure 1 - Gameplay.

* Note, size of the bubble represents number of companies occupying that position.

* The data for figure 1 is not CC licensed.

Recommended reading list on strategy.

I keep on being asked what business books I'd recommend about strategy and gameplay? First, you need to understand that I've been using mapping for almost a decade and generally I find most companies' gameplay is awful. Contrary to popular belief CxOs aren't generally playing some complex game of chess but instead picking moves in the dark with no idea of what the board looks like. 

Alas, this isn't entirely their fault. I blame the endless gibberish on strategy, leadership and organisation that seems to be commonplace. I used to suffer from this overload of nonsense when I was a CEO. For my sins, I now own several hundred business books on strategy. This doesn't mean they're all bad, many have neat ideas though admittedly the vast majority are tripe.

However, are they good? I have one set of criteria for a good book. To be a good book then in my opinion, you need to comply with the following rules :-

1.   Don't have concepts dressed up as theories.

2.   Have some form of data / experience rather than just anecdotes.

3.   Don't use backwards causality. 

4.   Don't have poorly researched ideas.

5.   Understand and explain causation and not just any correlation.

6.   Don't have endless buzzwords with little or not substance.

7.   Don't promise the world but fail to deliver anything of use.

8.   Provide a mechanism for me to understand and learn from my environment

9.   Provide me with something I can concretely use.

10. Be an easy and enjoyable read.

The honest truth is of those several hundred business books that I own, well not one book meets that standard. I don't have a "good" business strategy book to recommend because ... there aren't any that I'm aware of.

Oh, wait ... there is one ... Sun Tzu, the art of war.  So that's my recommended reading list, it might be short but it's useful. It also happens to be a military book that has been co-opted by business.