Wardley Map - a set of useful posts.

Ok, for those who want to learn how to map, I've provided a few links to what I consider useful posts.

A quick video (speaking is my preferred medium)

Another quick video


A longer and more detailed version.




Various Posts.

NB Some use the older terms Chaotic & Linear which I changed to Uncharted & Industrialised (more apt). I've put this list here (there's about 950+ posts on this blog). I'll try and add more, tidy things up and you never know ... persuade someone else to turn it into something readable.

Basics.
An introduction to Wardley Maps
A step guide to mapping
On creating a value chain
Getting stuff done.
A guide to mapping.
What's in a Wardley map and the need for a cheat sheet.
From strategy to mapping to pioneers (slides)
The good bits about mapping
The amazing bits of mapping
The wow of mapping
On terms that I use
On Doctrine and Gameplay
From purpose to leadership and back again.
A useful summary post
The get fit plan

Concepts & History
Evolution
Properties of evolution
On diffusion and evolution
Inertia
Componentisation
Componentisation II
There are many chasms to cross
Co-evolution
The Two Extremes
Oh, no Six Sigma vs Agile
Agile vs Lean vs Six Sigma
Early failures
When to use a curve
On services
How commodity is something.

Operations & Practice
On user needs and listening to customers.
Basics of operation
Let the Towers Burn
Government, Purchasing
Duplication and bias
Maps are imperfect but that's ok.
Rough guide - use cloud, build cloud and microservices.
On maps, components and markets
This is not the data you are looking for.
Cloud is outsourcing but it's not outsourcing.
Why no consultants.
Finding easy competitors to take out.

Patterns
Of Perils and Alignment.
Revolution
Company Age
Ecosystems
On Ecosystems and Porter.
On platforms and ecosystems
Punctuated Equilibriums
Consumerisation.
On the two forms of disruption
What's right and wrong with Christensen.
On evolution, disruption and the pace of change.
Does maturity matter
Ten graphs on organisational warfare.

Structure & organisation
Organisational Evolution
Spotting the Next generation
Somethings change, some remain the same
How we used to organise ourselves
Pioneers, Settlers and Town Planners
(another post on PST)
Two speed IT / Bimodal.
Dual Operating systems and bolt ons.
Continuous and Sustainable Competitive Advantage comes from Managing the Middle not the Ends
Two Speed Business? Feels more like inertia.
If you want Bimodal, you'll need to give something up
On Pioneers, Settlers, Town Planners and Theft.
Can I just do Town Planners?

Strategy
Why most businesses aren't playing chess.
Quick route to building a strategy.
Strategy starts with where not why

The importance of Where
Where, why, how, what and when.
Without a map you have no strategy.
Fool's Mate in Business

Mapping and Playing Games.
On the common fallacy of hypothesis driven business

Open Plays
Open source, gameplay and cloud
Open source as a weapon.
Scenario planning
Strategy vs Action
On disruption and executive failure.
Epic Fails of Sensible CEOs
Tower and Moat.
On Chess and Business
Preparing for War
Dungeons and Dragons vs The art of Business.
On D&D and Ant Battles.
Four basic smackdowns on competition
Does commoditisation lead to centralisation.
Fast Follower Conundrum.
Attack, defend and the Dark Arts.
Self disruption and super linear.
On the death of great companies.
The interesting thing about cutting costs.
Jevons in a nutshell

Other tools
Business Model Canvas ... the end of a long journey
Maps and the Target Operating Model.
Why flow isn't enough
Efficiency vs Effectivness - repeated.
Other Tools I use with Mapping
When to use a BMC or a SWOT
SWOTs

Gameplay
Open source cloud, start playing the long game.
What to do about Amazon and gaming
Looking at Lumberyard a bit more.
Amazon and the last man standing

General Stuff
Project, Products, Open source and Proprietary.
Context, situation and components.
Composability.
Is war the mother of invention?
The abuse of innovation
Half completed book

There's also the team at WardleyMaps (I'm not affiliated with) who are trying to turn my long and sometimes rambling concepts into something readable. That book be found here -

For reference, all my writings are creative commons 3.0 share alike licensed, as is the entire mapping concept, maps and evolution diagrams.

Evolution, diffusion, hype cycle and early failures.

With mapping, one of the axes is evolution (the other being value chain - I've written an introduction on Wardley Mapping which covers the basics.).

One axis describes what something is (the value chain, from the user needs to the components required to meet it through a chain of needs). The other axis (evolution) describes change.

I've posted before on how the evolution axis was determined but when exploring this subject, I didn't start with the evolution axis as I had to discover it. In the very early days (2000 - 2004), I tried all sorts of different forms of measuring change. All failed.

The evolution axis (see figure 1) has a number of specific properties. It is :-

Figure 1 - Evolution

1) Universal. It appears to apply to all things that undergo competition whether activities, practice, data or knowledge. 

2) Causation. It is caused by the interaction of demand and supply competition. Without competition then it doesn't occur. It also doesn't require the need for a crystal ball as time is abolished from the axis. Evolution is measured over ubiquity vs certainty.

3) Measurable. The evolution of any component can be measured using a combination of publication types and how widespread the component is in a field. Unfortunately, only the past can accurately be measured which means the component has to become defined on the certainty axis (i.e. a commodity) before its past can be fully described. Until that point, there is an increasing element of uncertainty with position as the component becomes more uncertain (i.e. unknown).

We have no crystal ball and cannot predict precisely when things will evolve (I had to abolish time to create the evolution curve) however we can test evolution through the measurement of the past and secondary effects (i.e. other consequences caused by evolution). We can also use weak signals to anticipate evolutionary change.

4) Usefulness. There is a long list of reasons why mapping across the evolution axis is useful.

5) Consistency. There is only one evolution path. The evolution of one activity can be directly overlaid on the evolution of another. There is no need for a vague 'time' axis where 'time' is not a measurement but a direction of travel. 

6) Direction. A thing evolves in a single direction, i.e. the past is behind it, the future is ahead. It doesn't start evolving, become a product and then suddenly jump back into genesis as an unknown thing. When examining complex products, what we find is objects like a 'smart phone' are actually a grouping of many underlying components.

7) Recursive. Evolution can be equally applied at a high level (e.g. a specific business activity) or at a low level (e.g. a component of an IT system).


The early days

Before discovering the process of evolution, I did try to map with all sorts of things. These were inevitably failures. I thought I'd go through a couple and explain why.

Diffusion Curves.

Diffusion Curves (as per Everett Rogers) are extremely useful in many contexts. They are measurable (adoption vs time) but unfortunately the time span is inconsistent between different diffusion curves. If you overlay multiple diffusion curves on exactly the same time axis then you get multiple different curves. They also lack direction i.e. the diffusion of a particular phone A1 (from early adopters to laggards) is followed by the diffusion of a better phone A2 (from early adopters to laggards) which is followed by the diffusion of an even better phone A3 (from early adopters to laggard).  ... and so on. Hence the evolution of an activity is seen as a constant set of jumps back and forth rather than a direction of travel and the future of an act can be both ahead and behind it on the map. I've compared a map based on evolution (see figure 2)  with a map based upon diffusion (see figure 3).

Figure 2 - Map based upon evolution, direction.

Figure 3 - Map based upon diffusion, direction.

Hence from a mapping perspective, this makes diffusion curves useless. However, don't confuse that with diffusion curves being useless, in other contexts they are extremely useful.

Hype Cycles

Hype cycles are extremely useful in many contexts. They are not however based upon any physical measurement but instead are aggregated opinion. This means they are not testable, so we just have to accept them at face value (even when they do change the axis from visibility to expectations). The other axis is time (though it used to be maturity).  Time, in this case, is more of a vague direction of travel rather than any measurement of time. It also suffers from a lack of direction in the same way diffusion curves do. 

In figure 4, I've added four different hype cycles from 2002, 2005, 2010 and 2013. First thing is the axes have changed from visibility vs maturity to expectation vs time whilst the curve has remained the same. I even have a couple with expectation vs maturity.  This doesn't matter. The hype cycle isn't based upon measurement of some physical property, it's based upon opinion, so this is fine.

However, we have software as a service / ASP being in the slope of enlightenment in 2005 and cloud computing being in the peak of inflated expectations in 2010. Now, this all depends upon opinion and whatever definition they wish to choose. But, as with diffusion there's no direction i.e. one thing doesn't evolve into another but rather one thing in the slope of enlightenment becomes another related thing in the peak of inflated expectations. So, when it comes to mapping rather than compute (as a product) evolving to include compute (as a rental service) then evolving to compute (as a commodity) including compute (as a utility), with the hype cycle you have the same back and forth that you have with diffusion curves.

Figure 4 - Four Hype Cycles

This variation of direction (i.e. movement) is shown in figure 5.

Figure 5 - Direction

As I found out long ago, the hype cycle in the context of mapping is not useful (as with diffusion curves). Don't confuse that with the hype cycle being useless itself. In many contexts as a source of aggregated opinion, then it is very useful.  

I looked at many techniques to measure change and found all of them wanting. I spent years finding out that lots of things weren't useful for describing evolution. This is why I spent so long in the British Library cataloguing many thousands of publications. There was no effective means of describing the process of evolution until I'd done this work and found a process that seemed to work.

But then that's the point, diffusion curves measure diffusion, hype cycles provide an aggregated opinion on hype, whilst the evolution curve measures evolution (it doesn't measure either diffusion or hype). All have their purpose.

When it comes to mapping and improving situational awareness then you need to focus on what an organisation is (the value chain) and how the components of the value chain are changing (evolution). Does this mean the evolution curve is right? No, of course not. It's just the best model at this moment in time for examining evolution and as such it's an essential part of mapping.


--- 13th March 2015

Based upon Henry's question (below), I've added a graph to show the link between diffusion curves (Adoption vs Time) and Ubiquity.

The first graph shows adoption curves for different instances of an evolving activity A [through various instances A1 to A6], but rather than simply add adoption as the Y axis, I've added applicable market. The reason for this is adoption is to an applicable market and the market sizes for each evolving act are different.

Figure 6 - Diffusion Curves (adoption vs time). 

I've then added where each evolved instance of the act A is in the evolution curve.

Figure 7 - Evolution

[The two graphs above are purely illustrative. I've taken a few liberties to make the transition less complex.] 

Now, a couple of things are worth noting.

Ubiquity is a measure of how ubiquitous something is. In order to determine it, you need to know the end point i.e. when the activity has become a well established commodity. This point of ubiquity can only be accurately estimated when the act has become certain. At this point the past history can be graphed.

I have to emphasise, that the accuracy at which you can determine where something is or where something was on the graph increases as the act becomes more certain i.e. a commodity. If the act is not a commodity then where it currently is on the ubiquity axis becomes increasingly uncertain the newer the act is.

For this reason, you cannot when something novel appears (e.g. the genesis of electricity with the Parthian Battery in 400 AD) determine how ubiquitous electricity will become some 1600 years later. No-one can. This requires a crystal ball.  However by 1960s, you've a pretty good idea how ubiquitous electricity is and can graph the past.

The certainty axis is determined from publication types (see figure 8). In particular, it is a relative measure of type II and type III publication types.

Figure 8 - Publication types.

To graph the past, you need to first use the publication types (used to create the certainty axis) to determine if something has become an established commodity. You can then determine the point of ubiquity (what I call the reference point) and use this to determine how ubiquitous something was. You can then plot ubiquity against certainty in the past. An example of this covering a range of entirely different activities is provided in figure 9.

Figure 9 - Ubiquity vs Certainty.

You can then overlay the different areas where different states (custom built, product etc) dominate which gives figure 1 - the evolution curve at the beginning of the post.

To graph the future, you can't. The best you can do is to make a best guess at to where something is on the curve. Which is why with mapping I use broad categories - genesis, custom built, product etc. I get groups of people (with experience of the field) to estimate how far along it is. The accuracy of this will increase as the act becomes more certain.

To see evolution then you need to abolish time from graph (i.e. there is NO way to measure evolution over time in any form of repeatable pattern). However, whilst things will evolve over some (unspecified length of) time, you cannot accurately demonstrate where it is the evolution curve until it has become a commodity. Then you can accurately demonstrate where it was.

I cannot emphasise this more. The future is an UNCERTAINTY barrier which we cannot peek through. The more UNCERTAIN something is (i.e. genesis, custom built) the less able we are to see the end state. ONLY when something is close to being CERTAIN can we see the point of ubiquity (the reference point).

I do see people draw diffusion curves and start claiming things about them like here is a commodity, this end is an innovation. Alas, there is no repeatable graph of evolution over time.

We do NOT have a crystal ball. No-one does.

Diffusion <> Evolution. Evolution consists of many diffusion curves and there are many chasms to cross. The two are not the same, mix this up and you'll get lost.

Despite lacking any crystal ball, we can however say that something will evolve from genesis, custom built to product (+rental services) to commodity (+utility services). It will become more common and more certain. This change is driven by supply and demand competition. This is what figure 1 shows.


--- Just for Fun (13th March 2015)

Oh, and just because I like a good debate. I'll leave you with this graph of progress. Whilst being efficient with energy is good, anyone who thinks we can somehow reduce energy consumption permanently whilst maintaining progress needs to think again. Whatever we do, eventually if progress continues our energy consumption will exceed today. If you want to solve the energy related issues then you need to look for less damaging forms of production. Competition (whether life or business) is a constant exercise of reducing entropy within the local system through the consumption of energy.



Ubiquity vs Adoption (16th March 2015)

I thought this was fairly obvious but it seems there is still some confusion. I need to clarify.

100% Adoption of the iPhone 1 <> 100% Adoption of the iPhone 6. The markets are different.

Q. But can't we look at the smartphone market? 

Well, what do you measure against?

Q. When it's ubiquitous?

Define ubiquity

Q. When everyone has one?

So, gold bars aren't ubiquitous because not everyone has one? Gilts aren't ubiquitous because not everyone has one? CRM systems aren't ubiquitous because not everyone has one? Coffee beans aren't ubiquitous because not everyone has one? Computer servers are not ubiquitous because not everyone has one?

Except ... Gold bars, Gilts, CRM, Coffee beans and computer servers are all ubiquitous in their markets. It's just their markets are very different.

Q. But how do you convert adoption to ubiquity?

You need to find the point of ubiquity in a market. To do this you need to look at publication types and work out when something is a commodity. Then you can find the point of ubiquity and plot back how ubiquitous something was vs how certain (i.e. well defined, well understood) something was.

You cannot simply take adoption of something in its market and call that ubiquity. You cannot jump from an Everett Roger's diffusion curve to an Evolution curve. Just because they both happen to have an S-Curve shape doesn't make them the same thing.

Q. But that's what everyone does!

Well, they are all wrong.

Greg's Alarm Clock

Back at EuroOSCON in 2006, I gave a talk on commoditisation covering the Web of Things (what a group of us used to call the Internet of Things before IoT took over) and 3D printing. In that talk, I discussed Greg's Alarm Clock created by Greg McCarroll (who has since sadly passed away).

Greg's clock was in my opinion one of the first really useful and smart devices.

The alarm clock which consisted of a mix of lego and other components was just a prototype concept. It did one very simple thing. Before waking you up, it checked a web service with the local train station to determine if your train was delayed or cancelled. If the train was, then the clock reset itself to get you up in time for your next train. If it calculated you were going to be late for work, it sent an email to work informing them on your behalf.

All this happened whilst you were sleeping. 

This is how 'smart' things should work. I don't find much use in switching on my washing machine with a phone app. I prefer devices that understand the context, the environment and can operate on my behalf, a subject I covered in a previous talk called 'Any Given Tuesday'. 

I don't want my future devices littered with a sprawl of apps to control lighting, heating and the temperature of my fridge. I want my devices to ask the questions and take care of the details.

Hi Jim ...

A response to Jim's Cloud Post.

---

Hi Jim,

Not quite how I remember the conversation. Factors involved in adoption - efficiency in provision, increase in demand (price elasticity effects, long tail of unmet demand, evolution of higher order systems), rate of innovation of new services (ecosystem effects), ability to take advantage of new sources of wealth (development speed, reduced cost of failure), inertia (16 different forms) & competitor actions. When talking about the shift of infrastructure from product to utility then all these factors come into play. 

Efficiency of Amazon's provision. Do remember that since IT is price elastic and Amazon has a likely constraint e.g. acquiring land and building data centres then Amazon will certainly have to manage its pricing carefully i.e. if it dropped pricing too quickly then demand could exceed supply. So, you need to consider future pricing as well. In all likelihood AWS EC2 is operating at 60%+ margin but this will reduce over time.

Increase in demand. One of most amusing cloud 'tales' is the one that it'll save money. Infrastructure is a million times cheaper today than 30 years ago but has my budget dropped a million fold in that time? No. We don't tend to save money, we tend towards doing more stuff. This is Jevons Paradox. What we need to be mindful of is that our competitors will do more stuff. Which is why you need to be careful about future pricing. If your IT budget is 2% of total budget and your competitor has a 10x advantage then you might shrug it off as a small part of the budget. But, your competitor is likely to end up doing more stuff and suddenly (just to keep up) you'll find you're spending a lot more than 2%.

Rate of Innovation of new service. There are numerous ecosystem games to play in a utility world (such as ILC) which enables a provider to simultaneously be innovative, efficient and customer focused. This seems to be happening with Amazon as all three of those metrics appear to be accelerating. This provides direct benefit for the users of that environment in terms of new service release.

Ability to take advantage of new sources of wealth. Key here is speed and reducing the cost of failure both of which a utility provider offering volume operations of good enough but standard commodity components provides.

Inertia. We all have inertia to change (loss of previous investment, changes in governance / practice, loss of social capital, loss of political capital etc - 16 different forms in total). There will be a counter to any change

HOWEVER ...

The competitive pressure to adapt are often not linear but have exponential effects. If an adaptation gives competitors greater efficiency, increasing access to new services, increases their ability to take advantage of new sources of wealth then as more of your competitors adapt then the  pressure on you mounts. This creates the Red Queen Effect (prof van. valen). 

As a result these forms of change are not linear but exponential. It can take 10 years for such a technology change to reach 3% of the market and a further 5 years to hit 50%. Because of inertia to change and due to its non linear nature many companies (especially competing vendors) get caught out. However, in all such markets there are usually small niches that remain. 

There is also no reason why commoditisation has to lead to centralisation. Many of the forces can be countered. Unfortunately due to the incredibly sucky play of often past executives within competitors then in this case centralisation (to AWS, MSFT and Google a distant third) seems very likely. Some of those past executives were warned in 2008 about how to fragment the market by creating a price war with AWS clones forcing demand beyond Amazon's ability to supply due to the data centre constraint. It's shocking that they were so blinded that they've got large companies into this state.

So, 

1) Will infrastructure centralise to those players of AWS, MSFT and GooG? Yes plus clones of those environment. Competitors have shown pretty poor strategic play in the past and this is now the most likely outcome.

2) Will everything go to public infrastructure clouds? No. There will be niches. There is also inertia to the change but the pressure will mount (Red Queen) as competitors adopt cloud. The change usually catches people out due to its exponential nature.

3) Is it just price? No. Multiple factors involved. Price is one of those factors.

4) Why is Walmart building a modest sized private cloud? Probably because it's concerned over Amazon's encroachment into its own retail industry. In all likelihood they will end up adopting Azure or GooG over time.

Let the Towers burn ...

In this post I'm going to cover some issues with the SIAM Tower model. I'll use mapping to do this.

Wardley Mapping is a technique that I developed out of utter frustration with IT and the business. I've used it for over a decade with continued success. It's based upon two things. Firstly a value chain (derived from user needs) which describes an organisation. Secondly, evolution which describes the process of change. The two are essential because there's not point in try to deal with an organisation 'as is', you need to also consider 'where things are heading'.

The evolution axis wasn't developed by sitting in a room thinking up what might be a good idea in a powerpoint presentation. It took over six months of intensive collection of many thousands of data points just to test it. In total the mapping technique took over ten years to create (1995-2005) and several more years to test the validity of the axis.

I'm going to start with an example of a map, an early draft from HS2 (high speed rail) and then compare the approach. This is what a Wardley map looks like (see figure 1)

Figure 1 - a Wardley Map.

Couple of things to note with the map. At the top are the systems that provide the user needs. Underneath is a chain of needs i.e. components that the higher order systems require. Each component (or node) is positioned according to how evolved it is. 

What might not be is obvious is that each component could be an activity, practice, data or piece of knowledge. All components evolve through the same mechanism and as they evolve their characteristics (i.e. properties) change. The mechanism of evolution is shown in figure 2 (it is driven by demand and supply competition)

Figure 2 - Evolution

I've summarised some of the changes of properties in table 1. Ignore the class / phase part - that's part of a classification system which isn't relevant here.

Table 1 - Changing properties of an evolving component.

What this means is when you look at your Wardley map, then the components of the map have different properties depending up how evolved they are. This is summarised in figure 4. 

Figure 4 - Change of Properties.

Hence the Wardley map (figure 1) has the terms 'uncharted' and 'industrialised' at the top. When applying methods to a complex system then you have to use many methods because each method is suited to a different part of the map (see figure 5) whether it's project management or purchasing.

Figure 5 - Appropriate Methods

So when you start to manage your map, you treat each component individually and apply the right techniques.  In some cases you'll get variation in the high level maps because the node might represent an entire map underneath and has been simplified (see Sub Maps in Other Tools post). An example of applying the right methods is given in figure 6.

Figure 6 - Apply the right methods

Now the danger of outsourcing a large chunk of activities is that if you do this then it's probable that a single (and inappropriate) method will be applied i.e. a very structured method like six sigma will be used across all of the map. This will inevitably lead to change control costs overrun as the uncharted components will change (they are unknown, uncertain and require experimentation). There is nothing you can do to stop this cost overrun. You can't more fully specify the uncharted activities precisely because they're uncertain and unknown. Arguments inevitably kick off and the supplier will point to all the industrialised acts which didn't change and were delivered efficiency. The "fault is you" but this is NOT true. The fault is the application of a single and inappropriate method. I've summarised this in figure 7.

Figure 7 - How you don't want contracts to be structured.

Now, many companies have little or no situational awareness. They have no maps. So they outsource large chunks, get hit by excessive change control costs and invariably get told it was their fault for not knowing what they wanted and specifying enough. The vendor wins, the customer loses. This is pure hokum, it shouldn't happen and many vendors exploit this to their advantage. The reason for the cost overrun caused by excessive change control costs was simply the single method used. 

In general what you want to do is break down a system into small focused contracts which use the right methods i.e. you don't want some broad and widespread contract across the map. A comparison is given in figure 8.

Figure 8 - Contracts - Good vs Bad.

So, what's wrong with SIAM and the tower model? 

Well, lets look at it (see figure 9). The grand idea is to break things up into smaller chunks called Towers (which is a good move) but these chunks completely ignore evolution. They are arbitrary divisions such as application development, hosting, operations, end user services etc. These are all then reintegrated and combined with business retained IT organisation. 

Fortunately, some of those towers are quite commodity by nature e.g. IT infrastructure. So we do strike lucky twice with smaller contracts and a few towers being commodity. But other than that, it's up there with Bimodal IT - lipstick on a pig. It is ignorant of the process of evolution and of dubious long term merit despite being slightly better than the past.

Figure 9 - SIAM and Tower model

Of course, most companies have no situational awareness, no maps and many will think the Towers of SIAM will be a grand idea because (by pure probability of placing the right components into a small contract and some of the towers being more commodity like) then it will be slightly better than the past models. But it's also easy for a savvy vendor manipulate, not grounded on any understanding of change and simply breaking a system into towers and outsourcing those is far removed from where good management is. It's true merit can only be as a transitional move to break an even more undesirable 'outsource everything' approach.

I wasn't surprised to hear Alex Holmes wanted to tear down the Towers. It's time they were. Departments need to start learning how to manage things effectively. Some already are.

The Towers of salmon and hungry bears

My post on the Towers of SIAM reminds me of a story I was told by one senior 'US official'. He used the story to explain how Government procurement works. He called it 'Bears and Salmon' and it went roughly like this ...

"Some of these suppliers are like bears. They expect to sit in the stream that is Government, stick their jaws into the water and scoop up tasty mouthfuls of food. Every year they expect their bounty to get bigger and their stomachs to be fuller.

One day, the salmon (that's us) decide we're going to take a different stream, we're going to find a better way of doing things because we're not about feeding hungry beers, we're about making the lives of people better. The bears stick their jaws in the water. No Salmon! They get angry.

The bears roar "It's our fault". "We shouldn't be allowed to change" they cry. We get told that by changing streams then all the bears will die. It will all be a disaster because we didn't keep swimming in their stream and jumping happily into their jaws. "They are our partners" and we need to work with them.

I don't feel like a partner, I feel like lunch. The bears should move and we should change streams more often."

Well, over the years UK Gov IT has changed streams. It has made it clear that it wants to focus on transparency, make things better, not being not afraid to admit mistakes, use modern practices and focus on our needs (as in ALL of us). Judging by the negative reaction to Alex Holmes' sensible post then some bears are angry.

Don't be surprised by how ferocious this might become. As Computer Weekly points out 'while large systems integrators still dominate government IT spending – thanks to the revenue from existing long-term deals – their share of new IT purchasing has fallen.' 

First, it's important to understand why the changes need to be made. I think Derek Du Preez nails it with the following paragraph 

"Holmes’ stance is essential for the development of government-as-a-platform. My instinct when reading his post was that taking a hard line on towers is being done because there has been a realisation that if the government wants to get itself into a position where government-as-a-platform is workable, then they need to be expelled."

The idea of Government as a Platform, re-using commodity components and providing services between departments to improve efficiency and speed must be truly frightening for some bears. There's a lot of profit made in massive amounts of duplication and the constant rebuilding of something that has already been built. Of course, you can't build such a platform if every department is using a silo'd approach and busily breaking projects into contract chunks which they outsource. 

What people forget is that Government as a Platform is unlikely to lead to smaller IT in Government. Yes, it means the things they do now will be more efficient but this almost always leads to new services. There is a long tail on unmet demand. Vendors might not be able to flog their old wares but then they can adapt ... bears need to move to a different stream when the salmon do.

In the bad old days of 'cloud', you'd hear vendors warning IT folk in a company that cloud would get rid of their jobs. Cloud doesn't reduce IT expenditure, it's enables us to do more things. Today I can buy with a $1,000 over a million times more compute than in the 1980s. Has my IT budget reduced a million fold because of this? No. We've just done more stuff. 

Why? Competition.

As things become more standard and cheaper components then competitors build new things more quickly. We have to keep up, we have to compete. The same holds with nations. Some don't realise that other nations are looking at and building Government as a Platform. They will end up doing more stuff and creating advantage for their economies. We have to compete. Alas, that does mean the bears must move. They won't want to. 

In these situations, inertia to change (there are sixteen different forms) normally exerts itself more visibly. This inertia can be seen from both the vendors (the bears) and those customers (salmon) who've become a bit too close. Often vendors will play up inertia in customers in order to keep existing contracts. For reference, I've included the types of inertia you'd expect to see in table 1.

Table 1 - Inertia

So when John Jones, director of strategic sales architects, Landseer Partners, which works with a number of suppliers on bids, including on service towers and SIAM, said 

"Government departments currently lack strong contract management skills. They just don't have them. Chunking up procurements into smaller service towers rather than giving it all to one outsourced vendor, at least gave departments the time to acquire contract management skills for the future."

Then you have to ask, if UK Gov has been running outsourced contracts for a few decades but not acquired strong contract management skills in that time then something is clearly wrong. Yes, there might be a need to invest in knowledge capital along with some cost of acquiring skill-sets (which they should really have) but that's no excuse for continuing with the past.  Is this supplier helping UK Gov or playing to inertia in the organisation?

I'll be keeping an eye on this over the next few weeks, should be interesting to see what examples turn up.

Towers of SIAM, trade associations and Civil Servants.

A few weeks back, I picked up on Alex Holmes post on the GDS website - "Knocking Down the Towers of SIAM". As a regular reader of UK Gov's GDS blog (well, I'm a British Citizen who takes an interest in what UK Gov does) then I was really pleased with this post. 

Why? Two reasons.

First, it's great to see my Government talk clearly in the open about these issues. I love this sort of transparency. In days gone past, many of these conversations would have been buried in huddled rooms with suppliers. I, as ultimately one of the many million of UK Citizens that pays for, votes and in effect employs UK Gov was usually left in the dark. 

The second reason was the post tackles a problem with good sense and is not afraid to admit the errors of the past. There's no hubris, just honesty.

From the post ...

"A fundamental part of our guidance was about taking accountability for decisions about technology and digital services back into government. For large parts of the Civil Service that had so completely outsourced their IT, this meant a massive shift in approach, which takes time and can be scary."

Spot on. There was a huge problem in the past with departments becoming reliant on vendors and having little ability to challenge. It's pleasing to see this change.

"This fear of change meant some organisations clung onto the concept of outsourcing, which they understood, but they also wanted to comply with the new policy of multi-sourcing IT provision – something that is recognised as best practice across the industry."

A normal reaction caused by inertia is to attempt to bring the past world of practices into the new world. In the old days, this sort of stuff usually got hidden under the carpet. No more.

"Unfortunately, the combination of these two forces created a hybrid model unique to government. The model is usually referred to as the Tower Model.  It combines outsourcing with multi-sourcing but loses the benefits of either." 

Clear and precise without trying to hide the issue. Something that was implemented was interpreted in a different way. 

"The model has arisen because organisation have used a procurement-led solution in response to legacy outsourcing contracts ending. Rather than changing their approach and emphasis, they have ended up outsourcing their IT again, but in pieces. It was still all about us, not about the needs of our users. "

Ah, the nub of the problem. Rather than apply the right sort of practices (agile for the uncharted, six sigma for the industrialised) and use the right sort of purchasing arrangements (see figure 6 from this post on Government and Purchasing) we've ended up with a undesirable hybrid. 

I'm so tempted to shout out "Go and Fix IT!" but wait ... 

"Organisations have adopted the Tower Model, believing they are following government policy and using best practice, but they are doing neither. I am now writing this post to be clear that the Tower Model is not condoned and not in line with Government policy."

Excellent. Outline the problem, explain the source and tell us what you're going to do about it. I couldn't be more pleased except the post then goes on to apply all sorts of common sense. 

"An important point about multi-sourcing is that different things are bought in different ways:  there is no “one size fits all” methodology.  Commodity products like hosting will still likely be outsourced to utility suppliers, but novel or unique things close to the user may be built in-house.  And components can – and will – be changed often."

"The Tower Model doesn’t work because it doesn’t fully consider what services are needed, or how they fit together and it uses a “one size fits all” methodology.  It relies on procurement requirements to bundle together vertically-integrated outsourcing contracts called things like ‘network’ or ‘desktop’. It also usually outsources the service accountability, architecture and management to a third party."

This is mana from heaven. I'm so pleased, thrilled and happy to hear UK Gov talk about projects in this way. Common sense, frank discussion, transparently and direct to me and the many million of other UK Gov employers (i.e. us voters, when it comes to Government then "they work for us"). This is a million miles away from secret conversations, voters being kept out of the loop and all the other nonsense that comes with such. This one post shows me how good UK Gov IT is and it couldn't make me happier.

However, I was astonished when I started to read some of the comments and subsequent press articles. Many of these were dubious at best and based upon a premise that the past was somehow better. I could spend weeks taking them apart but by fortune, I came across this little gem. 

In the post, techUK was

"surprised and concerned" by GDS announcing "significant change in policy" through a blog post "without any opportunity for industry consultation"

Ok, who are techUK? Well they're a trade alliance that represent companies that provide technology to Government. They help their members and the technology sector to grow. I'm sure they do a lot of good things.

BUT they also 'promote, encourage, foster, develop, co-ordinate and protect the interests of the Members' which. to you and I, is common tongue for lobbying.

I noticed they had suggested "industry" consultation rather than "public" which means firstly introducing a long delay through consultation and secondly we (as in the public) might not get to hear what's happening. I had images of cosy chats kept secret for reasons of commercial confidentiality. Based upon past experience, I prefer the UK Government route of being transparent and moving quickly.

I continued to read.

Apparently the GDS post "has caused our members some alarm". As a UK voter, I was delighted by the GDS post and so this didn't make sense? I'd be alarmed if UK Gov IT wasn't making things more efficient. But maybe that's the problem because making things more efficient usually means someone else isn't making quite so much profit. Could this cause alarm to a member's interest?

It went on ..

"Government must now engage with the whole of the industry, large and small, to help shape future transition and strategy and agree the best way to define and procure the solutions they need."

Again no mention of us (the public) but then it's an industry association I suppose. It felt a bit rich for a trade association to tell Government that it "must now engage". I'm sure I voted for Government to be in charge and not anyone else. I can't imagine that if one of techUK members decided to change their purchasing policy that their supplier would make such demands of them. 

It kept on nagging at me but who is standing up for us (as in the public) then?

So I re-read Alex's post. It was clear that Alex didn't say "Government should focus on a trade association needs" but instead that Government should "focus on user needs" i.e. all of us including you and me. That makes sense. Of course, to do this Government must find the best way to procure the solutions that we need.

We should remember, the whole problem with the past was that Government had outsourced so much it couldn't challenge what its vendors (or 'partners') were saying. This was then though and as Alex made clear - Government needs to decide, it needs to take responsibility. 

By now, I'm starting to feel a bit uncomfortable with the special pleading of a trade association. My sarcasm dial had reached 9. So, to speed the process up I decided to decipher their text into what I think they actually mean or plaintext as I like to call it.

"What is going to happen to current projects and those in the pipeline?"

Plaintext : Some of members have got interests in the projects in your pipeline and are worried that changes might hit their interests.

"What was the evidence base used to cause this change in policy?'

Plaintext : We need you to stop this.

"Will this new approach endure? Or will industry and departments be looking at another change at some time in the future?"

Plaintext : We're going to try and stop you.

It then went on to add a three point plan under the title "techUK outlines its plan for better public services". I was surprised by this. Let us think about this title and be clear about what it means.

A trade association whose memorandum includes protecting members interests is outlining a plan for better services for the Government when some of its members have been providing the services that we need to make better? 

My sarcasm dial went up to 10.

Before starting to read the plan, I wrote down a couple of things that a worst case pleading scenario would have i.e. flogging innovation for stuff that doesn't matter, claiming to do stuff the Government was already doing, emphasising how it would help in some form of "partnership".  So, I opened the link and read the three point plan. It was - engagement, information and innovation.

My sarcasm dial went all the way up to 11. 

At this point a gentle bit of ribbing feels in order. I can't help but add my own translation of this plan with sarcasm set to the max (i.e. snarkytext).

"Better engagement, to support civil servants earlier in the process and help develop policy with technical expertise. techUK members are committing resource to engage much earlier in the process, ensuring officials develop policy with a proper understanding of what technology can do."

Snarkytext: In the good old days, UK Gov had outsourced all its capability to challenge any proposal made and was dependent upon suppliers. We feasted. We'd like to feast again. We are your "partners".

"Better information, providing standardised, transparent reporting. This will overcome the problems of wildly varying reporting requirements on public sector contracts, which had the effect of making one scheme impossible to compare with another. The industry will agree a standardised data and evaluation scheme, allowing Government to pick and choose suppliers more effectively."

Snarkytext: We are going to tell you what information you need and that's all you're going to get. We're going to call it transparency because we know you do a lot of this. But your kind of transparency is not the kind of transparency we want to use. We're going to tell you how to pick and choose vendors. We're going to tell you it's more effective that way. We'd like to feast again. We are your "partners".

"More innovation, giving civil servants the opportunity to experiment and explore solutions in a risk-free environment. techUK's 'innovation den' model will be used to provide a test platform for new projects, and is designed to overcome the problem of public sector innovation being strangled by the fear of failure. techUK will develop a 'techmap' of suppliers, ensuring Government is aware of all the options available to them."

Snarkytext: In the good old days, suppliers feasted because you didn't take responsibility. Civil Servants shouldn't take responsibility. We want to make it risk free. We like risk free because despite the past history of massive IT project failures, you still pay through the nose for it. We also like innovation because you pay through the nose for it. We'd sell you innovative sand if we could. We have a 'den'. If you want to play in our 'den' then give us what we want. We'd like to feast again. We are your "partners".

I'm sure trade associations like techUK do a lot of good work but UK Gov IT has been clear. They want to be transparent, they want to make things better, they're not afraid to admit mistakes and they want to focus on us (as in ALL of us). They want the future. It's time for others to adapt.

Alex is spot on. It is time for government to put user need first and take back control of its IT. 

Other tools I use with mapping

In this post I'm going to discuss some of the other tools I use with mapping. I'll start by expanding on the map I created in the Introduction to Wardley Maps post. This original map was used to determine user needs, strategic play, remove duplication and bias, enable collaboration between groups, communication and identify appropriate methods (whether project management or purchasing). See Figure 1

Figure 1 - Basic Map

Sub Maps

Sometimes maps can get very big and very complex. Hence I tend to use a high level map (as above) with several of the nodes representing a sub map. You lose granularity with high level maps in the same way that an atlas loses granularity of the street level. This is fine, the high level map is what you use to determine your overall play and the sub maps often contain quite tactical details. Hence you might use a high level map in the board but a project manager in one area of the business might use the high level map (to see how their part fits into the whole) and sub maps giving more details.

To create sub maps is trivial. Start with the component node as the new NEED i.e. if you select streaming service (in the above) then your users are Website and Internet broadcast and they both have a NEED for streaming service. See figure 2

Figure 2 Maps and Sub Maps

RISK

Critical Path / Fault Tree

I also use maps to help determine critical paths and fault trees i.e. if something happens to my recommendation engine where does that impact me? In the above scenario I can still commission shows and deliver a streaming service but it does impact the web site. If however I lose internal power then multiple systems can be impacted and no service is delivered. Hence I try to mitigate this with multiple sources of power or by pushing a higher order system (such as compute) into a more resilient environment. In this case because compute is a commodity, I'd tend to use a volume operations based service in which I distribute my risk across a wide geography (e.g. cloud services like AWS). I've shown an example of such analysis in figure 3.

Figure 3 - Fault Tree / Path analysis

Contract Analysis

One very useful technique is to overlay any existing contracts onto the map. Ideally, you want to have small contracts focused around each node rather than large all encompassing contracts with outside parties. The reason for this is that the methods you need to use vary with evolution (i.e. agile one side, six sigma the other) and if you have a large contract then what tends to happen is a single method (e.g. six sigma) is applied across the lot. More often than not, this is very costly in terms of change control with those uncharted activities. This is because they are going to change and a structured method will tend to punish change. You really should be using agile methods in that uncharted space.

Always break down those large contracts (unless you're a vendor in which case, take advantage and feast on the inevitable change control cost overruns caused by them). In figure 4 I've given an example of good and bad contract structure.

Figure 4 - Contract Structure and Maps

Methods

I've covered this many times before but I cannot emphasise enough the importance of using the right purchasing and project management methods within a large scale project. I use METHODS deliberately because there isn't a one size fits all method but instead you need to use many. Figure 5 provides a visualisation of where each method is appropriate.

Figure 5 - Project and Purchasing Methods

For heaven's sake, don't confuse those polar opposites of uncharted and industrialised with a need to create a bimodal structure. There is a huge gap between them. 

Anticipation

This is more a board level issue but worth noting. One of the huge advantages of mapping is organisational learning.  You quickly discover common economics patterns (from componentisation effects to creative destruction to the peace / war and wonder cycle) along with methods of manipulating the environment to your favour (open approaches, constraints, FUD etc). There's lots of games you can play and get good at.

When it comes to anticipation then weak signals are critical (there are numerous you can use). One of my favourite long term signals is publishing type (i.e. how the activity is described in common publications). Do remember that you can map activities, practices, data and knowledge and the weak signals apply across all.

With the peace, war and wonder cycle then the part which can be most anticipated is the 'war' phase. This phase can be highly disruptive but since you can anticipate it, then you can also prepare for the change. It's worth noting that are two forms of disruption - the more predictable product to utility substitution which creates the 'war' and the unpredictable product to product substitution. Don't confuse them.

Hence, I'll often look for 'predictable' points of change by identifying the wars (see figure 6) and then examining my map (see figure 7) to see where I will be affected.

Figure 6 - Points of Change and likely future 'Wars'

Point 7 - Points of War in your value chain.

So from the above I know that compute is undergoing drastic changes towards a utility (in fact we knew this was imminent in 2004). I know that traditional media (DVDs) is being impacted along with aspects like CRM that are on the verge of change. Recommendation Engines and Streaming services haven't industrialised yet (but remember this map is several years old). They will.

As with other changes of this type then I already know the impact (disruption of the past stuck behind inertia barriers, new forms of un-modelled data, co-evolution of practice, rapid explosion of higher order systems that use the component etc) before it has happened. I know that I'll also have inertia to the change but by being prepared and knowing where it will hit means that I can do something about it.

Business 

When is comes to business, then there are two aspects of mapping I use. The flow of money through the map and competitor analysis. These are quite detailed topics but I'll summarise.

Competitor / Market Analysis

I often use maps to look at competitors. This can be either by examining their value chains to identify any inertia they might have to predictable forms of change or I might look for any differentials that they have with us. I'll also use maps to look at different markets. This sort of analysis can give me an idea of where I need to protect, against whom, how I can exploit the situation to my advantage, and which region future competitors may come from. When I'm looking at different markets, I examine whether that market is more evolved or more emerging, whether the activity is price elastic or not, what constraints exist and what games (e.g. an open play) are being used in the wider market.

I've given an example of such a scenario planning exercise from a different industry in figure 8 and I'll often run games around these to tease out impacts and edge cases.

Figure 8 - Scenario Planning

Business Flow

I like numbers particularly when those numbers represent cash in a profitable way. When we think of business, I tend to think in terms of flows of revenue and cost. I hence use the map to create different flows through the system, identify cost and revenue and create business flow diagrams (see figure 9).

Figure 9 - Business Flow Diagram

Sometimes I'll find one business flow is more profitable than another. Sometimes an act will evolve and a particular flow will become unprofitable or another will become profitable or a further will become possible or most likely a combination of all the above will happen. These diagrams can be a bit tedious hence it's a good idea to like making money. However, the upside is that you can often find entirely new ways of making revenue during the process and it certainly helps you to focus on this.

Opportunity

I'll use maps to look for opportunity i.e. points which we can attack. An example is being the first mover to create an industrialised component and then building an ecosystem on top.  I might also look for areas where we might wish to gamble and experiment building an uncertain need. 

My preferred approach is not to gamble but to be the first mover to industrialise and the fast follower to any new activities built on those industrialised components. This is a technique known as Innovate, Leverage and Commoditise. You commoditise an act, get everyone else to Innovate on top of it and then mine (i.e. Leverage) the consumption data of your ecosystem to spot future successful innovations that are evolving.  You can then Commoditise those activities (or data) and rinse & repeat. See figure 10.

Figure 10 - ILC play.

Operation

Team Structure

Operations is one of my favourite topics (along with strategy) but in this case, it's all about getting stuff done. Its the execution side and that means people (but not in a Wolf Hall sense). I first start by using a map to break out the team structures that I'll need - see figure 12.

Figure 12 - Team structure

Now, I almost always break the map into small autonomous and self organising teams (i.e. two pizza model, no team bigger than 12 people). However, I cheat a bit by overlaying attitude (a technique known as pioneer, settler and town planner) to make sure I've got the right sort of attitude and aptitude in each team. I encourage everyone to work on FIST principles (Fast, Inexpensive, Simple and Tiny).

Now, if you're successful then the size of the system will grow. Hence, as this happens I tend to break down larger components into smaller components in order to keep the teams small (think Starfish model). It's worth noting that the lines between these the nodes on the map are interfaces of communication. I'll use these to create fitness functions for each team, so everyone knows what each team is supposed to be doing i.e. what needs they are meeting, their metrics against those needs, business flows etc. The maps help glue it all together to give a picture of what we're doing and where we're attacking.

Before you ask about the all important "Why?" of strategy. Do remember "Why?" is a relative statement as in "Why here over there?". Maps help you find the many wheres and hence determine the why. Strategy however is another discussion which I've touched upon in many previous posts.

Scheduling

For scheduling between teams, I use Kanban. I don't see the point of using anything else.

Evolutionary Flow

In some circumstance I'll create a profile for a system when it's a company or a line of business (LOB). This profile is useful in understanding the type of people I'll need to recruit and the balance of the organisation. These topics are beyond the scope of this post but such a diagram can be simply created by counting the frequency of components in each stage of your map - see figure 13

Figure 13 - A profile

Validation

Finally, it's worth mentioning that I use a couple of tools to help validate the maps. Despite my teasing of SWOT diagrams, I do find them useful in some circumstances. However the grand-daddy of them all is business model canvas (BMC) and my natural preferred choice.

Once I have a map from which I've removed bias, worked out strategic play, created the business flows and built an operational structure then I have everything I need to fill in a BMC. For me these are exercises in checking that I didn't miss anything obvious. I never start with a BMC but I do tend to use them in finishing stages my first draft of a map.

Why first draft? Well, maps are dynamic. The environment will change because everything evolves through competition. You can't stop it, just get used to it. Hence once I've validated my first draft then I tend to live of it and rarely will go through another validation exercise. We're in the game now and I know my maps will improve the more I play.