Efficiency vs Effectiveness - Repeated.

I'm bumping into this sort of madness at an alarming rate. Any illusion that I once held that business is sane is rapidly diminishing. I'm going to use an example, not including names and slightly modified to include other examples of practice just to ram the point home. This covers a company working in the financial sector.

The company has its own data centres and it is rapidly growing which is creating a problem because of the time it takes to order and install new servers. The basic process is fairly straightforward, they order new servers, the servers arrive at goods in, they are then modified and mounted. The company analysed the flow (a rough diagram is provided in figure 1) and found that the bottleneck was caused by modification of the servers due to the number of changes which need to be made before mounting. 

Figure 1 - The flow.

The solution? To automate the process further including investigating the possible use of robotics. It turns out that the process of modification is not only time consuming but can cause errors and the cost of automating this process (given the rise of general purpose robotic systems) can be made given the future expectation of growth. The figures seems encouraging. Getting rid of bottlenecks in a flow sounds like a good thing.  It all sounds reasonable.

But it’s all barking mad. The first thing to do is map out their environment including the flow. The map is provided in figure 2. 

Figure 2 - The map

Now, as we can see from the map then goods-in and ordering are fairly commodity (i.e. well defined, commonplace) and that makes sense. Computing on the other hand is treated as a “product” which seems suspect but far worse is they are making some fairly custom modifications to this “product” before mounting. Also, what is racks doing in the custom built section? Racks are pretty standard things aren’t they?

Well, not in this case. Here the company is using custom built racks which are slightly smaller than the 19 inch standard. Which is why they need to modify the servers. “Eh, What?” I hear you scream. Yes, the company needs to take the cases off the servers, drill new holes and mount rails to make them fit. “Eh, What?” I hear you scream. And so, yes, the proposed automation is about using robots to improve that process of drilling and modifying servers to fit into custom built racks.  Wait, can’t we just use standard racks? 

If we take our map, and mark on how things should be treated (see figure 3) then surely it makes sense to use standard racks and get rid of the modification. “But, that’s how we’ve always done it!” comes the cry. Oh, heaven help us. It may have somehow made sense in the long distance past but that's the long distant past.

Figure 3 - The modified map.

In fact if we look at the map, we should also mark compute as a utility (which is what it is now). I’ve done this in figure 4. Which now begs the question that we’re a finance house, what the hell are we messing around with servers in the first place for, let alone drilling holes in servers to make them fit custom built racks. We shouldn't be "improving" this flow, we should be getting rid of it entirely.

Figure 4 - An alternative flow

I'm writing this whilst looking at another example which has nothing to do with finance or racks but it's as equally daft in all senses except scale. This one is a lot bigger, a lot more expensive and they've even splashed out a good few million on consultants to help define their "reasonable approach". This includes lots of nice charts, flow diagrams and even a value stream map (a mechanism for improving flow). I'm starting to think that large chunks of business can only operate because competitors are doing equally daft things. Making ineffective mechanisms more efficient isn't a good thing. You really need to understand context before embarking on this type of stuff.

I need a large cup of tea, a nice biscuit and a good sit down. I'm trying desperately hard to be polite and hold back the expletives. 

My top predictions for 2016

Here are my top five predictions for things you absolutely should do but will ignore in 2016.

Focus on user needs. Lets face it, playing with tech is far more fun than actually understanding your user needs and so you'll probably argue that buying a whole load of VR gear is fulfilling this requirement. It's not but that won't stop you and it's not like the business knows what it's up to anyway.

Improving situational awareness. Making decisions, determining strategy and even effective operations requires an understanding of the environment. But hey, why bother starting now since you've been living for so long without it. The whole idea of actually understanding your landscape sounds very complicated especially when I can buy a report from McKinsey to tell me what to do. 

Getting over one size fits all. Whether it's agile, lean, six sigma or outsourcing then by now you should suspect that one size doesn't fit all. In fact, the techniques are specific to different stages of evolution. Eh? What? Oooh, that sounds complex. Especially since I can roll a dice and pick one.

Organising around evolution. New things appear and evolve. They start in the uncharted space (a world of exploration) then we learn more about them (the transitional space) before finally over time they become more commodity like (the industrialised space). You really need to organise around this evolution using cell based structures (e.g. Haier / Amazon Two Pizza) and models such as pioneers - settlers - town planners which require multiple cultures within a single organisation. This does seems like an awful lot of work and anyway Gartner has told us to go bimodal. Following orders has always been so much easier than thinking.

Coping with inertia. Change in an economic system caused by supply and demand competition is often resisted due to past success. There are 16 different forms of inertia to cope with and it's worth remembering that inertia is a killer. However, a bigger killer is rocking the boat prior to retirement, so if you can just hang on in there, keep things steady and learn a few good buzzwords - digital, ecosystem, platform, disruption - then why do you care what happens after you go?

These are my big five things that you absolutely should get to grips with but will ignore in 2016, replacing instead with meaningless buzzwords and tech gadgets. The good news is because most other companies will do exactly the same then you're likely to get away with it.

Duplication and bias - two problems that cost you a fortune and are easy to solve.

Having just had a rant on the ridiculous attitude some take to outsourcing, I'm now going to skewer another pair of bugbears of mine - duplication & bias. Again this uses mapping.

I'm going to start with two maps, both from a Government department. One is an internal system, the other is external. Now, you can argue about the position of pieces on the maps but that's not the issue. What I want to point to are the green dots which are replicated from one map to another. Lets now look at those maps (figure 1 & figure 2)

Figure 1 - An Internal System

Figure 2 - An External System

What the maps tell me is I have multiple components, repeated and often treated in different ways. Sometimes we even use different terms for the same thing. The more maps I add, the more duplication I find. Eventually with enough maps then most components are green i.e. duplication is everywhere. 

I can use these maps to create a profile for an organisation by adding all the green dots from many maps to a single page. I've shown this in figure 3, highlighting the level of duplication, examples of bias and a "cluster" for how things should be treated.

Figure 3 - A Profile for activities within an Organisation

The purpose of this profile is it tells you were you are duplicating, where you have bias and gives you information to go and challenge what is being done. This is the real power of mapping, the act of sharing these maps enable you take out waste and start learning common patterns. But is this just a Government thing? 

People often think that Government is the home to inefficiency. It might come as a shock when I tell you that the private sector excels at this. In one case, I know one large corporate with 380 customised versions of the same ERP system built by different teams but meeting the same types of needs for the same type of users. The private sector in my experience beats Government hands down for duplication, bias, waste and making decisions without any form of situational awareness.

Unfortunately because so few organisation do something as basic as mapping out their environment and collecting those maps, they have no continuous means of identifying duplication and bias. They endlessly create custom built examples of things that are well defined products and they rarely clear out the baggage except in some big "rationalisation" effort. Of course, most of those "rationalisation" efforts are a joke because they try to clean up their act with no maps of the landscape and hence no idea of what to clean up. It's all praying to the God of the water cooler that somehow people will take care of this through serendipitous discussions.

So, how common a problem is this? Well, most companies (i.e. > 99%) have no recognisable form of situational awareness.

What about a figure for the level of waste! It's difficult to put a number on that because it varies between organisations. But experience dictates that if you combine duplication, bias with inappropriate doctrine (e.g. outsourcing too much) then in a large organisation you are looking at around 90% waste.

90%!  You're kidding! Nope, I'm not. People will tell you it's lower (i.e. 20-30%) but when you get into the details then all sorts of things come out of the woodwork. In one case, I have an example where the cost reduction was 99.95%. The reason why people think it's lower is they have no mechanism of situational awareness and so they really have no idea how much duplication, bias and misapplication of doctrine there is. Never, ever underestimate the amount of waste that happens because people make decisions without understanding their environment or sharing that understanding with others.

Of course, don't tell them they're wasting bucket loads of cash, they'll just get defensive. It's better to lead them to that conclusion. Hence take about ten heads of different business units, put them in a room and ask them for maps of their landscapes. They'll look sheepish, often lots of foot gazing with a few claiming "we do mapping". Try to get them to discuss a system and ask who has got this. I can tell you now you'll quickly find that they all have lots of the same type of things but most likely they'll have all customised it. If you've people in the room with more experience of the environment, you'll quickly discover that most business units will have multiples of the "same" thing. Before long, you'll find an example where you'll be counting 30 or 40 different versions.

Now, be careful here because people often raise the idea about common or shared services. There's nothing wrong with this idea as long you're talking about a fairly industrialised act (see the post on outsourcing). The problem with past "common" or "shared" service efforts is organisations didn't have any situational awareness (they still don't) and so they tried to share the wrong things (i.e. stuff that wasn't industrialised). You need to first use the profile to identify duplication and then eliminate bias (i.e. unnecessary customisation) and then with the industrialised stuff (which turns out to be a lot of IT) you can then look at common, shared services or outsourcing to a cloud provider.

Oh, and as for the person who said "we do mapping" ... the reality is it's extremely rare and so you can bet they don't. Organisations do use things such as value stream mapping, business process diagrams which are all fine but don't give you context and can therefore lead to all sorts of really bad decisions. For a map you need position (in this case a chain of needs relative to an anchor which is user need) and movement (in this case evolution) and without these two aspects then you'll just keep repeating the same old problems.

This "wisdom" is brought to you courtesy of 2007. For all our sake's, stop doing this sort of nonsense in Government IT. Don't build things without some form of situational awareness. I know a few Depts think of themselves as little Empires and don't want to share but we can't afford to waste vast sums rebuilding the same things over and over. If you're happy with the status quo then please go and work in the private sector instead because a) you won't harm Government or waste taxpayers' money b) the private sector has so much waste they won't notice you piling on a bunch more.

Cloud is outsourcing but it's not outsourcing (as was).

I'm tired of many of these discussions because they're ridiculous. However, once more unto the breach dear friends.

First, lets take a map. I'm using an example based upon HS2 (high speed rail) in figure 1. Now, the map contains many components, all evolving (under supply and demand competition) from the uncharted space through a transitional space to an industrialised world. I mention those three different stages just in case a hoard of bimodalites come raging past.

The methods you need to use depend upon how evolved the components are. For a handy guide, I've put down the normal range in figure 2. In the uncharted space, you're discovering and so you need to reduce the cost of change. Hence Agile (or more accurately, the Agile principles) are best suited. By the transitional stage, you know roughly where you're going and you need to reduce waste and learn more on the environment. Go read Lean for this. By the time the same act becomes industrialised then you're into reducing deviation and here Six Sigma rules.  So let us look at those figures.

Figure 1 - A Map (modified from HS2)



Figure 2 - Methods.

Now, most organisations (and by most I mean > 99%) have no map and therefore no situational awareness instead relying on story telling and SWOT diagrams. Hence the tendency to adopt one size fits all methods and all the other instruments of la la land including woeful strategy, meme copying, no mechanism of learning through context, masses of duplication and bias etc. If you want a good laugh, you should spend time in the boardroom when people discuss strategy ... any illusion of chess playing masters will quickly disappear. People are really shooting in the dark here and struggling because of it.

Since most people have no situational awareness, the best you'll get is a business process map or another box and wire which shows connections between things but no context. You'll get something like figure 3 and asked the question which bit should we outsource? In the past we tended to outsource the whole lot because we didn't have a clue.

Figure 3 - A box and wire



So what happens when you outsource the lot? Well, you'll try to put a well structured contract in place to make sure you know what's being delivered. But lets look at this box and wire in terms of a map. See figure 4.

Now this is a rough map (the only people who can actually map an environment are those actively working in it) but it'll do for this discussion.

Figure 4 - A map of the box and wire.

Now we can argue about the position of the pieces on the map but eventually we will get to something we agree on. Let me assume the above is about right and we've outsourced the lot to a friendly outsourcing supplier under a very structured contract because that's the "sensible" (chortle, chortle) thing to do.

What's going to happen is the stuff on the right (the industrialised bits) will hopefully be delivered effectively and efficiently by the supplier buying highly commodity components or well defined products. You certainly don't want them to be building a LIDAR like you're the first person to ever have one of these. Things like GPS, LIDAR and even geographical maps (though not included on the diagram here) are actually well understood and common and hence suitable for outsourcing, provision as commodity components etc. However, the stuff on the left in the uncharted space will change. We will be exploring this space, working out what do we actually need from a World Perception Server. The result of this change will of course be excessive cost control overrun through a change control process. Naturally the supplier will say that the excess cost is all your fault because you didn't specify well enough what you wanted in the World Perception Server etc but the reality is you could never specify well enough. Neither you nor anyone else could know what is required in the uncharted space. You have to experiment.

The problem with outsourcing in the past wasn't the concept of outsourcing but instead that organisations outsourced entire systems for which they had no situational awareness. This was foolish and of course outsourcing got a bad name except from the suppliers who cottoned onto the scam and made oodles of cash out of it. The simple reality is that there's nothing wrong with outsourcing if you break down complex environments into components and outsource those industrialised ones.

Which is where cloud comes in. Cloud is all about the shift of a bunch of product based IT activities to highly industrialised utility services. When you're using AWS for infrastructure e.g. EC2 then yes you're outsourcing infrastructure to AWS but in this case you're outsourcing a highly industrialised component to a utility service provider. Top marks, a dead sensible thing to do.

What you're not doing is the "old" form of outsourcing which means taking a whole bunch of components for which you do not understand the context and handing them to someone else in the hope they will take of it for you. For those going "people didn't really do this, did they?" ... oh boy did they and for endless reasons of gibberish e.g. from it's too difficult to deal with components and interfaces to it'll reduce risk. The only risk it reduces is the risk that the supplier won't make excessive profits. Trebles all round. 

So, yes ... cloud is all about outsourcing highly industrialised components to utility service providers. No, it's not like the outsourcing of the past which was barking mad in many cases. No, the mechanics of this are very different and before anyone says something really daft like "Isn't cloud like renting a room in hotel" ... I'll stop there.

This "wisdom" was brought to you care of 2006. Shame on you if you're still getting this wrong. I'm fed up with being nice to people on this, please go work in another industry and stop giving IT a bad name. Or go run Donald Trump's IT office and bankrupt him. Tell him you need custom built servers, oh hang on ... custom built chipsets ... oh wait, no tell him you need an entirely new form of power to run the web site (i.e. a dyson sphere) and outsource all the exploration to someone under a "fixed" contract like it's an industrialised component. At least you'd be doing everyone a favour.

For all our sakes, stop doing this in Government IT. Please, just leave. Regardless of what you think, we are in economic competition with other nations. There's better places to spend taxpayers money than flushing it down the toilet by outsourcing without situational awareness. Oh, and before anyone says "mapping is hard" etc ... with a bit of practice you can create a really useful map in a few hours. You can then start sharing maps and getting rid of duplication and bias - but that's a post for another time.

Btw, all the mistakes above such as outsourcing too much, one size fits all methods, creating dual structures are mistakes I've made but learnt from.

Finding easy competitors to take out

When mapping and determining gameplay, it's always worth having an occasional glance at your competitors - the game of strategy is an iterative one of observe, orient, decide and act. It’s really useful to know who are the easy competitors and the ones you should take out whilst avoiding the tougher spaces whilst you grow. There’s a number of signals to use which demonstrate easy targets. Most of these you can pick up from their own website, their public talks, forums etc.

Key to look for are

Duplication and bias. Without mapping or some equivalent then companies have no real mechanism of avoiding duplication and bias. They'll also be suffering with inertia. This is a goldmine as these companies will inevitably be slow and inefficient whilst being riddled with unnecessary complexity and inaction. In the worst case that I’ve found, a single company had 380 customised versions of the same ERP system. It’s often difficult to find out how bad the situation is without talking directly to ex employees etc but occasionally companies let slip by announcing future rationalisation projects. This form of competitors are great fun as they are just too slow to counter you. Think "stealing their pack lunch".

No position or movement. Without a means of visualising the environment then companies are unlikely to have much of a concept of position or movement. These companies are ripe for attack. You can pretty much guarantee they have no means of organisational learning or effective approach to anticipation, they certainly won’t understand repeatable forms of gameplay or context. Any “strategy” (I use that word loosely) is simply backward causality. You can often spot this by looking at their strategy statements (normally a long list of action items), their emphasis on story telling (no means of visualisation) and their fondness for memes. These competitors are easy to wreak havoc on as they just don’t how to react. Think "All you can eat buffet".

Single methods / dual operating system. These companies are very unlikely to even understand evolution which means they certainly can’t map and are unlikely to have developed any situational awareness. However, worse than this, they not only don’t understand the environment but they’re imposing a dogma of some type on it. You’re not going to be facing a cell based killing machine here but instead an organisation racked with difficulties, failing to manage the legacy, over-reliance on outsourcing & analysts and in a stupor to consultants.  Their own people will often be rallying against them as they boil under the tyranny of an imposed one size fits all method or create waring tribes. Morale is likely to be low and good engineers should be prime for poaching. The company might talk a good game (e.g. ecosystem, disruption, open source) but have no fear, they are really lost at sea. Send a note to the CEO with the words “boo” on it and then help yourself to their market and their good people. You can usually spot these companies a mile off because they’re announcing that they’re going “all agile” or “all digital” or "all openstack" etc. These are my favourite companies and you should treat them as an excellent recruiting ground. In this case it's less free lunch and more "Execs will come to your house and cook whatever meal you like" as these people are actively working in your favour.

There are other things you could look for but this is usually enough to spot the vast majority of easy targets.

Open source as weapon

I often talk about the use of an open play as weapon, a mechanism of changing the environment you exist in. Back in 2011, when I examined the phenotypic changes of companies (due to a particular cycle known as peace, war and wonder - more details here) there was a pronounced change in attitude in the next generation of companies from the use of open means for simply cost reduction to the provision of open means (source, APIs, data) to manipulate the market (see table 1).

Table 1 - Changes of phenotype from traditional to next generation.

In the following year, I examined the level of strategic play (based upon situational awareness) versus the use of open means to change a market and noticed a startling effect. Those who showed high levels of situational awareness and used open approaches to change a market showed positive market cap changes over a seven year period (see figure 1).

Figure 1 - Changes of market cap with Strategic Play vs Open approaches.

I've talked extensively about the use of Wardley mapping and how you can use this to identify where you might attack a market. I've also provided examples such as "Fool's mate" which is one of about 70+ different forms of repeatable gameplay that can be applied to a given context. In Fool's mate, you attack the underlying system with an open approach in order to gain a change in a higher order system. More details are provided here but figure 2 provides an outline.

Figure 2 - Fool's mate in business.

However, even if you do have reasonably high levels of situational awareness, you understand where to attack and how to manipulate a market through open approaches then this is not the end of the story. The use of open approaches is not a fire and forget system. You can't just declare this thing as "open" or create an "open consortium" and walk away.

Unfortunately, far too often in corporations I've seen people believe that "open" is synonymous with "free resources" and that somehow by opening up a system that the community will be so grateful for the gift that they'll just adopt it and success is assured. This is la la fantasy land. The majority of today's great tech corporations owe their success to the open source community, they are built on it and they do themselves no favours to disrespect the community in such a way.

If you decide to attack a market and you decide to use open as the means of changing it (what I like to call "open by thinking") then when you launch you'll going to have to put time, effort, money, resources and skill into making it happen. Hence the importance of "open by thinking" because going open should be seen as an investment decision which can pay handsomely if done right. There are numerous pitfalls to be avoid e.g. antagonising or not building a community, not listening to a community, not acting as a benevolent dictator for that community or failing to put its interests over your own, failing to steer a clear direction, failing to invest and worst of all establishing a collective prisoner dilemma.

You are the custodian, the gardener, the benevolent dictator of the community you hope to create. The act of throwing some code over the wall, creating an open source consortium and running a social media campaign on how "good" you are is a long way off from what you need to be doing. It is more akin to the self aggrandising but absentee landlord who claims the lack of tenants for their unsafe flats is purely because people renting properties are ungrateful.

Yes, you can use open approaches as a weapon to change the market in the battle between companies but it's a weapon that requires skill, dedication, investment and care.

BTW, I do love Chapter 12 - How to tell if a FLOSS [e.g. open source] project is doomed to FAIL. Hat tip to Jan Wildeboer for that one.

Two speed IT - the more I look, the worse it gets.

I've just been told of a "new" idea of using two speed IT with agile combined with a platform. Heaven help us. First, it's a very old idea and second it was as daft then as it is today.

Let's go through how things should work (see figure below). Your town planners (specialists in empires of scale) create your platform. Lets start with a simple code platform providing a utility like service. Your pioneers (the specialists of speed) build lots of new stuff on it. Your settlers (the specialists of learning, reducing waste) find the common patterns in all the new stuff and turn these into basic components whether products or libraries which they develop further. Let us be clear here, whilst your settlers may take "more" time to build a product or library component than your "hack it anyway it works" specialists, your settlers accelerate the speed of everyone building with those components. Hey, I just install the library rather than write one or there's an API to some rental like service (which is fairly stable).

Over time, your town planners convert these increasingly matured components into component services optimised for volume operations. Let us be clear here, these component services become extremely stable, change slowly (though new component services can be constantly added) and provide volume operations of good enough. Whilst the services may reliably provide volume operations of good enough, what "is" provided can be a highly standardised, less performing and less reliable component than available from the most super duper products. The key is volume operations, good enough, optimised for delivery and a very low mean time to recovery (MTTR) i.e. if the component fails, another is available rapidly. This forces architectural practice change (see Devops) but also the standardisation, change of focus, speed of delivery helps accelerate the speed of everyone who builds upon them.  For your pioneers, they don't have to install a library or product but instead they just use an API to a solid service which is super fast ... but they have to design for failure! It also helps your settlers who can include these component services in their libraries and products.

And so the cycle goes on and on, constantly driving us upwards and ensuring efficiency, agility, speed and removal of debt by the use of three groups, three speeds of operation, three types of people and three cultures. This was reasonable practice circa 2005.

So lets roll the clock forward to 2015. What we have is a "great" idea of one group builds the platform and then a second "agile" group running at a different speed builds the new things (see figure below). Certainly this might give you a short term bump in efficiency and delivery. The problem is there's no group identifying common patterns and evolving them. The "platform" group that builds industrialised component services aren't going to touch your flaky new "agile" thing (cue endless arguments to exacerbate any tension between the two groups). The agile team of course wants to move on, so they'll start building new things on top of their new things. This is a one way street to spaghetti junction, a bucket load of technical debt, an entire system that creaks and slows downs and a big "meeting" where we all get together to build the new platform of the future because the last one is now fscked. I've seen this so many times over the last decade that it ain't funny.

Two speed IT combining agile + platform ... that's my new shibboleth for the clueless. Almost anything is better than a big expensive platform effort which will grind to a halt requiring a huge future platform re-engineering effort and on and on. This is where you'll be heading and this is kids stuff. It's shockingly bad.

-- 6th January 2016 : On Speed
[added updates above]

Lots of people discussing the importance of speed. Please note, don't confuse the speed of how quickly something is built with the overall impact of the thing on speed i.e. it might take longer to build a library than a quick hack for the same activity but the advantage of the library is in re-use. The more industrialised something becomes then the speed of building / changing might become slower but the speed benefit it has on everything that is built on top becomes huge.

It's way quicker for me to chop down a tree and saw a plank of wood than it is to build a modern computerised sawmill. But if I need planks for a 100,000 homes then it's way better to have highly industrialised and standardised planks created by computerised sawmills than to have me with an axe and a saw.

-- 5th April 2016 : On Legacy
[added updates above to make clear the point]

Some people seem to think that "legacy" belongs with the town planners. Legacy is often the result of best architectural practice for consumption of a product which is different from best architectural practice for consumption of a utility. The issue is that architectural practice tends to co-evolve with the activity, so when we shift from product to commodity (+utility) then we get novel, then emerging, then good and finally best architectural practice for a commodity (+utility). In IT, we call this DevOps and I've written more on this subject in an earlier post.

Of course, though we experience this change of practice, we should be mindful that we've previously been through a cycle of novel, emerging, good and then best architectural practice for a product and the two sets of practices are fundamentally different as they are based upon different principles (e.g. low vs high MTTR, single vs volume instances, designed for purpose vs designed for delivery). A diagrammatic representation of this with respect to computing is ...



So often, the "legacy" can be found with the settlers who have built best architectural practice around consuming their product. This is the importance of theft, the town planners have to steal this activity from the settlers (overcoming any inertia), turn the activity into a more industrialised form (volume operations of good enough designed for delivery e.g. a cloud service for example) and allow for / encourage the development of a new set of architectural practices for consuming this commodity (+utility). In this case what's happening is your Town Planners are killing off the legacy that the Settlers want to hold onto.

Don't confuse Town Planners with the "keepers of the legacy", it just isn't so!

Legacy can incur throughout the structure i.e. there's co-evolution from custom built to product as well and so Pioneers are quite capable of building and maintaining for a very long time a mess of custom built legacy until someone drags it away from them (i.e. the Settlers). I know people talk about bimodal as having one part as managing the "legacy" and the other part managing "digital" but that's just ring fencing part of the organisation from inevitable change and giving them a justification to keep on doing what they were doing (often building data centres!)

I'm not a fan of bimodal, having experienced and been responsible for a dual party structure a decade ago. It creates a host of problems and rather than create a transition usually degenerates into utter warfare. If you're going to split into a "new" camp and "legacy" camp then you're going to be compounding these problems even more. You might as well call it Eloi vs Morlocks.

On a final note, "legacy" isn't something which belongs anywhere. A better description is Toxic IT and it's a debt to the past that is constantly created and needs to be constantly removed.

Uber, the not so disrupting disruptor?

A recent HBR article by Christensen on "What Is Disruptive Innovation?" states that Uber is not "genuinely disruptive" and it doesn't fit into his hypothesis of disruptive innovation. Well, he is certainly entitled to modify it anyway he sees fit but the article does raise concerns over post event classification i.e. the original claim that the iPhone wouldn't be disruptive followed by the article's claim that it wasn't in the smartphone market and it was in the PC market. I happen to agree with the basic premises of disruptive innovation though I do note that there appears to be at least two different forms of disruption - one anticipatable and the other not. That said, let us get to the point of this post which is Uber.

First, I'd argue that a case for Uber being disruptive can be made if you look at the right thing (a bit like the above HBR article which compares the iPhone not with the smartphone market but instead the PC market). The area to examine is whether Uber is replacing the human controller. The person who you called, who co-ordinated taxis and who told you the car would be there in five minutes (it never was) has been automated out of existence. I know taxi firms who dismissed the idea of an application doing this citing that people wouldn't trust it, the benefits of talking to a person, of accounts and a more personal service. Uber however took the controller and turned them into an automated bot creating the barest minimal of interaction.

In the process this automation also expanded its reach, there are limitations on how much any human controller can effectively control. So, whilst I agree that Uber is not disrupting taxis per se, it certainly seems to be disrupting the idea of a human taxi controller by first turning this interaction into volume operations of good enough. However, what's interesting in this topic is when people talk about the potential of Uber to disrupt the automotive industry.

To understand why, we first have to look at a map of the automotive industry. I won't start with today's map but one which has been rolled forward to 2025 (see figure 1).

Figure 1 - Automotive Map 2025

The user has two basic needs - status and getting from A to B. The latter has multiple sub needs from comfort (which includes safety and security) to affordability to route management. These are all encapsulated in the concept of the car and there is a pipeline here from the more product / differential focused automotive to the more commodity like vehicles. You can follow the chain down through systems to provide comfort (including entertainment and infotainment) to OEM to component manufacturers. To keep the map reasonable, I'm cutting down whole sections to nodes (e.g. power supply or material).

In this picture of 2025, intelligent agents have become increasingly common and hence most cars have some self driving capabilities. Cars are becoming increasingly immersive (the inside of the car is just one big set of screens, probably printed). What starts to differentiate cars is not the car itself but the design associated with the immersive experience and the connection between status and route management. By this point, cars provided on some sort of utility basis will be increasingly common. This trend of intelligent agents, immersion and design subscription will continue to diffuse. So what does this all mean?

By 2030, in all probability most of us won't own cars. When I leave a meeting then my car will certainly be there to pick me up but that same car will be the one that you were using 30 minutes beforehand. Cars, for most of us, will have become very commodity. What will distinguish our journeys will be the level of digital subscription service that we have. If you are a "platinum" service member then not only will the outside of the vehicle alter (colour, some other affects to show your status) but the immersive experience will be more tailored for you and your journey will be faster. Why? Well the cars driving us "silver" subscription members will get out of the way for your car. We won't even notice because we're inside in our immersive experience which for us "silver" members probably involves a lot more advertisements. 

The cars themselves will monitor their own performance, drive to the repair shop when needed, communicate between each other and re-route constantly based upon not only the journey time but the subscription services of other car users. Of course, human driving will be increasingly outlawed except for super high end status vehicles where the illusion of human driving (safely managed by an intelligent agent) is given. There's all the usual knock on effects to car parking (we don't need as much) to repair shops to traffic signals etc.

Taxis in this world will become a thing of the past except, in a sense, most of the cars are acting like taxis with automated controllers and automated drivers. We don't own these cars, we just subscribe to our service and pay for what we use. By 2045, well the scenarios get even more outlandish. But who will own this new world of vehicles? Will it be Uber or Google or Apple or Ford or even GM?

If you look at the above map, identify the points of war (i.e. the shift from product to more commodity), the impact of technologies undergoing the same change (e.g. immersive, robotics) and then add in the structural advantages (e.g. education, financial and manufacturing scale) and strategic gameplay of companies and nations (e.g. last man standing, creation of centres of gravity, directed investment etc) then a very different picture emerges. Figure 2 provides major impacts from points of 'war' (red boxes) and overlays examples of known gameplay of significant scale in China. Even by 2025 then China should be edging ahead in the automotive industry by building, designing and operating the most advanced forms of these vehicles. Alas, even today Western companies keep on underestimating the speed, agility and entrepreneurial spirit of China.

Figure 2 - China Gameplay in Automotive

The automotive industry seems destined for an immersive, self driving and digital future provided through highly commoditised vehicles. However, I expect the beneficiaries of this change to be Chinese OEMs combined with service companies such as Baidu and Didi Kuaidi. As for Uber then I agree it is disrupting the human controller. I also agree it will have a part to play in this new world for a time. But, I don't expect Uber to be the company disrupting the automotive industry even though it might dream it will.

When to use a Business Model Canvas or a SWOT?

I've been asked for a bit more detail on my post on "Business Model Canvas, the end of a long road" and so I thought I'd use an example.

I was recently looking into the whole area of identity and access management (something I'm mulling over for future LEF tours) and so quickly put together a basic map of the industry. Now, I'm no expert on the subject and so I turned to others to give me input (I find my Wardley maps are useful for collaboration with others). A basic map is shown in figure 1.

Figure 1

The first thing I'd do with this was to look at weak signals (i.e. points where the industry is shifting from product to commodity [+utility]), add in competition forces (i.e. those areas where competition and hence evolution appears strongest) and add in known ecosystem plays such as ILC. This I've shown in figure 2.

Figure 2

At this point, I'm looking for potential. There are two "wheres" that I might attack for example in the above map. One of which is obvious and the other is a combination of components. The two are :-

• profiling and the development of an ecosystem around this.
• personal reputation and the development of a relatively novel system that combines components of both trust and profile.

This I've show in figure 3. Of course, there's numerous other points I might wish to attack and a vast array of games (repeatable forms of gameplay applicable to different contexts) that I can use.

Figure 3

I might have spent a few hours mapping out the landscape and collaborating with others but let us say, I push the boat out and go a bit overboard by spending another day and comparing with other players in the space, adding in inertia and constraints where necessary. Lets add another half a day for gameplay. I'll have a pretty extensive map of the landscape, multiple points (WHERE) that I can attack and a good idea of how to play this and the different games available.

By now I'll be looking for my WHY as in WHY here over there. Once I've played with a few scenarios (a few hours) and settled on one or two main points of attack then this is the point that I'd start using the maps to flesh out one or more business model canvas (and yes, I might even use a SWOT). For me, these tools are more an exercise of confirmation and challenge to the idea of my chosen point of attack. And before you ask, yes I could spend a whole three days on this entire analysis prior to embarking on a major effort but in practice I rarely need to.

I find it incredibly useful to understand the landscape, the points where you can attack and the games you can play before embarking on a chosen route. I never start with business model canvas or SWOTs but I often use them further down the line when I've got a good idea of WHERE I'm going to attack and WHY here over there.

Efficiency vs Effectiveness and why flow isn't enough.

Without naming names, I'm going to talk about a rather ridiculous situation that helps highlight the difference between efficiency vs effectiveness and why flow isn't enough. It concerns computing.

In this company, they have their own data centre which is full of custom built racks. These racks exist because that's the way they have done it but rather than being the standard 19" rack, these are a non standard sized and turn out to be slightly smaller. This unfortunately means that normal servers can't be racked but nevertheless the company has a solution. They buy relatively standard servers, they remove the shell and drill new holes into the body in order to fit it into the rack. Now users in the company can request compute resource but what's of interest here is the issue of when capacity is nearly reached. An order is made, new servers arrive in goods in, the shells are removed and new holes are drilled to modify the servers and then they are mounted. I've drawn the process in figure 1.

Figure 1

Now looking at this process, we find the mechanism of removing the shell and drilling holes (i.e. Modify) to be quite time consuming. It is also occasionally imprecise causing issues mounting the servers and waste. It is also bottlenecked by there being a limited number of people who are any good at doing this. Bizarrely metalwork is actually not a core competency of system admins. So we can propose any numbers of mechanisms to improve the efficiency of this process even to the point of automation with robotics if the scale demands it. 

However, I want to take a mapping view and show the same flow. When using maps, on the evolution axis then I tend to use activities (i.e. genesis to commodity) but do remember you can map practices (novel, emerging, good, best) and data (un-modelled, divergent, convergent, modelled) on the same axis. All of these components share the same characteristic changes as they evolve. 

In our process then order components and goods-in are fairly widely understood and established. The modify server (despite there being a guide written on how to do this) is fairly unusual and a newly employed system admin will probably have little idea on how to do this. Of course, even racking a modified server is reasonably straightforward. Hence I've provided a rough map of the above in figure 2. However I've also marked on a view as to where compute, racks and the practice of mounting a server are in the market.

Figure 2

What should be obvious is that we're trying to make Flow 1 efficient when it is in fact an ineffective process. The only reason why we're doing this is because of our use of custom built racks in a world where racks are standardised. If we use standard racks then the modification process goes away and mounting becomes vastly more standard. However, if we look up the value chain then compute has become far more of a utility and if we take advantage of this then flow 1 is simply replaced by an API call (flow 2). 

In the case of the above, the company shouldn't even own compute but should be using a public cloud service. It certainly shouldn't be investing in robotics to automate a process of customising standard servers to fit into custom built racks in order to make an ineffective system more efficient.

A map gives you two main axis. The first is position based upon a chain of needs relative to an anchor of visible user need. The second is movement (i.e. how things change, evolution). Within maps you have flows but mapping makes it much more obvious when you're trying to optimise and make efficient a highly ineffective flow. Of course, many of you are familiar with compute and would claim it would be obvious not to do this. But if I made a map of World Perception Systems or a Trading Ledger then you might not be so familiar. In which case, I suspect you might fall into the trap of optimising and making more efficient the wrong flow. I suspect this because I see it all the time. Endless efforts in corporations to make the wrong thing more efficient.

You can't also just say, well that company should be asking - "how does this process help us?"  - as the executive don't understand the inner workings of systems and the people involved in the process believe it's the right way. They're proud of their environment and have all the usual symbols of inertia. It's not that they're daft but instead they believe that what they're doing is right - it's what they've always done and they've invested considerable personal time and effort making it better. Of course, making it more efficient would help the company hence investing in robotic automation sounds "sensible". I can easily build a case for this as daft as it sounds (and it is daft).

Showing them a map, even with just pointing out the change if you start using more commodity components such as standard racks (see figure 3) rather than focusing on making an existing process efficient exposes the assumptions and workings of a company.

Figure 3.

Once you've explained that, it becomes far easier for people to make the leap towards not having racks at all (i.e. flow 2). I mention this because people often tell me about the importance of removing bottlenecks and ensuring efficient flow. I happen to think such techniques for value stream analysis are reasonably important but you have to be really careful that you're not making the wrong thing efficient. It's not enough to just look at flow (as in figure 1), you need to consider how evolved the components are (e.g. fig 2 and 3).

Which is why I always recommend you start with a map.

Strategy starts with where not why.

It doesn't matter whether you're competing against a foe in a battlefield, or in a game of chess or in business ... strategy always starts with where.

"Where can I move?" is the first question you must ask. To do this then situational awareness (i.e. understanding your environment) is critical. If you cannot visualise (even through mental models) the landscape then you cannot determine "where". Mapping is fundamental to strategy and to organisational learning (e.g. economic lessons and repeatable gameplay in business or battle plans in military history) because situational awareness is. The question of Why is a relative statement as in "why here over there?"

Sun Tzu understood the importance of the landscape and talked extensively about it. Alas, strategy has taken a bit of a downturn in the business world since the art of war was written a few thousand years ago.

"But surely strategy starts with why?" ... no, blind luck and meme copying starts with why. If you cannot see the environment, you'll either do something because others are (backward causality) or you're taking a complete gamble without understanding the landscape. This may pay off but starting with why is anything but strategy.  

"But surely our purpose is why?" ... no, purpose i.e. that which causes others to follow you and provides a moral imperative is an idea. It's either given (as in defence of the realm) or in the world of business it is transient and carved out of past strategic play (e.g. the pivoting of companies through their history). Nokia didn't start out as a telecoms company, it started out as a paper mill then a rubber company ... do you think its purpose hasn't changed because of the choices it made? Today's purpose was a historical heritage of past choices and its future purpose is unlikely to be the same as today. There is no "why" in this sense other than "we arrived here by accident, where next?" and "we wish to survive."

Take Odeo, an MP3 sharing service. Did it stick with its purpose? No, it created Twitter. It created a new purpose.

Take Ludicorp, an online game. Did it stick with its purpose? No, it created Flickr. It created a new purpose.

At some point both groups faced the decision of "why here over there" as in "Odeo or Twitter?" or "Ludicorp or Flickr?" and in both cases that choice was not only a question of different wheres but the answer changed their purpose, it altered their cultural heritage. 

Whilst the art of strategy is deciding "why here over there" and this in turn requires you to understand the possible wheres (i.e. your landscape), the consequence of making a decision can alter your purpose. 

"But they didn't use maps?" ... no, but then again it was more blind luck. They took a gamble in the unknown and it paid off. In military, sometimes things are won by sheer luck. That doesn't mean that maps are abandoned because of some notion that in this case luck worked. In military fields then patterns and repeatable gameplay can be learned - pincer movement etc. The same happens in business, for example the entire cloud field was anticipated long ago and many former giants have lost their position through not understanding the most basic concepts of their landscape. Others have exploited this.

Alas (or maybe this is a good thing depending upon your perspective), most businesses lack any form of situational awareness or mapping. Most don't even know it's possible relying on the pre-map navigational forms of story telling. Whilst there are no sure things in any form of competitive engagement, the understanding of the landscape and improving situational awareness can help swing the odds in your favour. To do this, you have to start by first asking where you can attack and then decide why here over there or there or there or maybe all?

Strategy starts with where not why.

Ten basic rules for dealing with strategy consultants

I'm no fan of strategy consultancy in general because most of what I see lacks any form of situational awareness and much of the field is uncomfortably close to snake oil. During my time as a CEO, I had to wade through endless drivel before I started to realise what the problem was. So, from my earlier post on "why big data won't improve your strategy", I thought I'd just spell out my ten basic rules of dealing with strategy consultants and how to spot and react to a dud.

How to react / deal with strategy consultants.

1) Focus on Why? As soon as someone says this, you should say "Why is a relative statement such as why here over there? How do we determine where?" - any bluster on this should make you point the way to the door. Remember - strategy always starts with "where?" and in their case the where should be the exit.

2) You're asking the wrong question! This is magic thinking, secret arts etc. Ask them "How do I know if I'm asking the right question?" - unless they can provide you with a repeatable method or if there is any bluster on this then you should politely ask them the right question of "Could you manage to close the door on your way out?"

3) Our method works! This should just make you run a mile. At best a method can teach you how to understand the environment, learn to play the game and learn to manipulate it to your advantage. Any mechanism for improving situational awareness will be imperfect. Any "formula" for success is again - magic thinking. Respond with your own formula of "you + exit = happiness".

4) Company X did this and they were successful. If this is a call to implement an activity then this is backward causality. They should show the competitive landscape, how Company X changed that landscape to their favour by the introduction of this act, whether this pattern is repeatable to your competitive landscape and what the underlying mechanisms of change are. If they can't do this then ask them to leave with the statement "Those other consultants successfully left, you should follow them".

5) 67% of companies have an XYZ strategy. This is just meme copying. Call security.

6) The top ten habits of successful ... run a mile AND call security. Unless they can provide a very precise mechanism to understanding the impact of those habits (i.e. understanding the environment and its manipulation by) then it's just backward causality on steroids.

7) The future is ... uncertain. Unless they can demonstrate repeatable and measurable patterns, the limitations of the patterns and the fundamental causes of the patterns in a manner which enables you to see the environment then this is not anticipation but guesswork or pre-existing trends that are so obvious they are of no differential value. Either case, you should explain "I bet you saw this coming but ... Next!"

8) You should align your strategy with your vision! A vision is a set of generalised aspirations. A strategy should be derived from an understanding of the context and the environment. I find throwing heavy books usually helps get them out of the room quickly.

9) You should align your business and IT strategy! Chances are you don't actually have a business strategy (otherwise you wouldn't be asking someone for help). It's also likely that you're suffering from low levels of situational awareness (i.e. an abundance of story telling, meme copying, magic sequences etc). If you did have high levels of situational awareness then you'd know that business and IT is an artificial division. If you've got a lion hidden under the table, now is the time to let it loose or at least tell them you're about to let one loose.

10) The key is to focus on execution! At times like this it is useful to have another door in the office that leads to a room with a table, a sheet of paper on it and a false floor covering a huge tank of sharks with frigging lasers. Say "Through that door is a room with a piece of paper on the table. If you answer the question quickly I'll give you a $100M strategy consultancy gig". As they charge into the room and turn the paper over, the false floor should disappear and the sharks should have their fun. Oh, as for the question on the paper - it should be "Well done on a speedy execution ... in your next life ... do you think situational awareness might help?" 

Final Note
If you need help in improving situational awareness in your organisation, then this CIO post on mapping is a good place to start. It's all creative commons and yes, I'm afraid, you have to learn yourself. Don't try and get some consultancy to do this for you as you're the one playing the game. There is no shortcut other than practice.

If you need help in implementing this into a large organisation then start with this 100 day plan. If you need a book then try the community one written on WardleyMaps, a group I'm not involved with but encourage.

Before you ask. 
No, I don't do consultancy.
Yes, I do teach others in my tribe (i.e. friends, my community in the open source world and members of LEF) and occasionally at other public conferences.
Yes, I could write your strategy but no, I won't. You need to learn to do this yourself.
Yes, I do write extensively on the subject here. No, there is no license fee. Yes, you are completely free to use as long as you honour the spirit of creative commons share alike.
Yes, here is a link to a set of useful posts to get you going.

That "cloud' term

IT consists of many components that are evolving. Some, like compute have evolved from being provided as a product (i.e. server) to being provided as a utility service (i.e. IaaS). Unfortunately rather than calling this a compute utility (which it is), we've been lumbered with the term "cloud".

This can create all sorts of confusion. For example, lets look at the figure below (using the form of a Wardley map).

Point

1) This is compute as a utility i.e. compute utility. Unfortunately we call this "cloud".

2) This is a never before invented human to kitten translator. It's something totally novel and new. Is it a utility ... No! But it's built on compute utility. Is it cloud? Well, that's where the confusion starts because some marketing folk know the value of the getting the cloud word in there and hence it'll be called "Human to Kitten translator on cloud" or "Human to Kitten translator cloud" before you know it.

3) This is a custom built intelligent software agent e.g. Siri. Is it a utility? No, hell I can't even buy Siri like capabilities as a product and it certainly doesn't provide you volume operations delivery of a good enough component. It's far from a utility. It might be built on a compute utility. Is it cloud though? Again talk to sales, they'll probably say yes if that helps.

4) This is an ERP product running on a compute utility. Is it a utility itself? No, it's most likely to be a single instance rental model. But is it cloudy ... do you think they're not going to advertise it as "ERP on cloud" or "Cloud ERP" for short?

5) This is a payroll utility i.e. it's one of those services that charges per transaction and in this case is built on a compute utility. Is the the payroll service a utility? Yes. Is it cloudy? Bizarrely in the financial world, some people don't show off their cloudy credentials and have been keeping quiet on this topic.

6) This is an invoicing service charging per invoice produced and it happens to be run on its own servers. It is a utility ... yes. Is it cloudy? Well here arguments start as another salesperson chimes in to say "It's not as cloudy as our cloud ERP which runs on IaaS" etc.

I like things simple e.g. product based ERP running on a compute utility or utility payroll running on a compute utility. A utility simply means volume operations of good enough components for a common and well defined activity charged on a per use basis. 

Cloud means ... oh, hell ... anything you want it to as almost everyone ignores NIST not that it was much of definition in the first place.

Agile vs Lean vs Six Sigma

When you look at a map of any complex environment, you have three domains - the uncharted, the industrialised and the in-between stage of transitional. The techniques you use for each are very different, for example in the uncharted space you cannot plan but as things evolve you can increasingly plan.

In figure 1, I show the changing characteristics and which methods are more applicable. In figure 2, I give an example of use applied to a map from 2005.

Figure 1 - Characteristics & Methods

Figure 2 - Map

Now whilst I've used multiple methods from small scale to huge scale endeavours for a decade, there is a major problem with it. Consultants and method priests hate it. The normal approach that is encouraged within corporations is one size fits all i.e. their method - let's be all agile! let's be all six sigma! etc. These are somewhat quasi religious wars where the believers demand their method is suitable everywhere.

Recently there have been attempts to create bipolar structures (ignoring the all important transition) as though creating two groups of quasi religious extremes will somehow magically solve the problem. Hmmm. Been there, bought the T-Shirt. You alas need (at least) three different methods, three different cultures, three different types of people to cope with any complex environment unless you're willing to give something up such as the creation of novel and new. This, by the way, is not new. I've been doing this for a decade and some of the original models date back to 1993.

In the uncharted space, you don't know where you're going and all you have are vague ideas. You need to explore, you need to discover. The one thing you know is you will need to change course rapidly as change is the one constant in such an environment. You cannot plan (other than set a time limit), you cannot write a specification and agile (which is a list of basic principles often best expressed through a technique like XP but not even needing this level of formality) combined with other tools such as hack days is what I've found to work best here. It requires multiple skills from both development and business but you have an unknown problem space and an unknown solution. You just don't know, you might pretend you do but you don't. You are the pioneers, exploring the uncharted waters and any metrics (not that these are much use) are based around how quickly you're discovering. Your goal is a working prototype. Something which might be of use. Of course that doesn't mean you're discovering everything for the first time. You don't have to build a ship from scratch when setting off to explore, that's already quite an evolved act. That's something you use.

At some point, you'll discover something i.e. Land Ahoy! Of course, your "path" is all over the place and in software this translates to a buggy, incomplete, half working, often overloaded with unnecessary features (artefacts of wrong paths taken) prototype. Don't feel bad about that, this is what exploration is all about. However, at least you have a "target". So, the mentality has to change. You have an identified problem space but you have a less than ideal solution. You're now into building a minimal viable product (i.e. something of use to others) and iterating quickly through this. Techniques like XP & Scrum work well but with added constructs (e.g. MVP, Value Stream Analysis, AARRR, Business Model Canvas) as your focus is now on reducing waste along with learning about a specific space as fast as possible and building something useful & viable. This is the transition and this is where Lean comes into play. The nautical equivalent would be building the first trade routes (i.e. how to get from A to B).

However, the act will continue to evolve, it'll become more complete, more well understood and defined. Eventually it becomes suitable for industrialisation. Here your focus changes again, as you know what is wanted (it's a known problem space) but you now need to build volume operations of good enough. Deviation is your opponent and techniques like six sigma will help stamp this out. You're building the empire of scale, the highly industrialised and automated trading routes where ship deliveries are timed to the week then the day then the hour then the minute. 

The methods and types of people you need for all three domains are different. The mindsets are different. You have to embrace that.

Alas, the method priests always try to make their chosen method applicable everywhere. Ultimately they bolt on more and more to cope with the different characteristics and when it doesn't work they explain it's your fault for not using the right bits. Ultimately the method which was once suitable for a specific domain becomes less suitable as they take agile and turn it into something like lean or they take lean and turn it into something like ITIL. You can call it all "Lean [something]" if you wish but remember, there are three very different domains.

So embrace the difference. Vive le difference!