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.