Bimodal debunked and debugged

We are moving to a bimodal model for IT and along with the guild, am helping set the pace. For those unfamiliar with the term, it was coined by Gartner in what is widely considered a rather simplistic and muddled article from 2014, albeit one with a ring of truth to it. Details here:

I did my usual think, talk, read cycle and waited for fate to lend a hand. And as usual it did in the form of missing pieces located down the back of the sofa at Simon Wardley's Map Camp. My set complete, I drafted some models, workshopped the ideas in small groups then in interactive sessions in the larger guild using my new favourite toy, Microsoft Surface Hub. This excellent tool can join a Teams meeting and turn it into an interactive scribble fest-yum. As a result, I have pretty much completed a debug of bimodal ready for mainstream consumption. Here we go:

• Take the Wardley Map evolutionary stages of genesis, custom build, product and commodity
• Rotate 90 degrees to form a stack, label "industrialisation"
• Split in half and describe the left side pre and right side post. This is "modernisation
• Label top half mode 2 bottom half mode 1. It should now look like this:

This model assists sense-making in the modern enterprise:

1. Imagine a mobile phone, it is made up of commodity plastic, product and commodity chips, Android O/S etc. An E2E journey/experience traverses all layers of the stack
2. In technological terms we can interpret the model like a stack, with customer-supplier boundaries as we go up the abstractions
3. The picture is also a metaphor for a market economy with items starting in genesis and custom build and making their way down to product and commodity
4. It can also be seen as a giant code base in need of constant development and refactoring e.g. there is a cycling through the stack
5. Central management attempts to push pre-modernised products and commodities when need has moved on
6. Complete deregulation and balkanisation can cause sprawl and drift amongst genesis and custom build
7. Optimisation occurs when we know who are customers are, what they want, and how we deliver it, typically by being customers of suppliers of our own

Wicked problems

Many problems with enterprise computing are as a result of the following:

1. Missing layers
2. Complex interactions over simple abstractions
3. Service providers and customers not acting as such
4. Missing flow and refactoring
5. Role conflicts: tobacconist and doctor

Righteous solutions

1. Stand up your own stack as a fractal but provide your service at the appropriate layer (e.g. Public Cloud as awesome multi-fractal of these stacks exposed as a commodity)

A fractal view of this model

1. Sense-making- encourage people to explore their roles in the economy. E.g. who are your customers and what do they want?
2. Strong cohesion and loose coupling through the layers -sort out your abstractions to turn your org into a living system

This model unfinished but proving F useful --it just works. Let me know your thoughts ...

<Postscript>

Mark Smith raised the Simon Wardley objection in the comments. My response as follows:

1. The approach I follow is highly dualistic. I introduce the terms mode 2 and mode 1 since these are what have been used at leadership levels. My goal is to reinterpret within constraints to allow work and individuals to flourish i.e. I don't take the terms too seriously, and certainly Organisational Physics and my own Transformation Soup models apply amongst many others (and including Ed Brimmer's Art of War/Science of War dichotomy)
2. I have added a diagram to further illustrate the fractal point. Perhaps I could have been clearer, am suggesting this is complementary to Simon Wardley's model. And, indeed, Simon is purposely being simplistic to make a point
3. Re-read the article if you have time and tell me whether this makes more sense

And Mark did, and these are the great questions he asked (italics) and these are my responses:

What are the modes and what do they do, how do they arbitrate between themselves? - are they management structures/resource groups/budget ownership boundaries /constraint models / method boundaries?

Our adoption of the terminology at my present org means I am obliged to use the terms but wish to do so in a way that does maximum good and minimum damage. They have some use as they reflect the tension between operating models required in large complex organisations with a lot of the old and a fair bit of the new. Modes I have just reinterpreted as being short-hand for

• Mode 2: <Genesis and Custom Build> at the more chaotic/growing edge end of the Wardley industrialisation scale and
• Mode 1: <Product and Commodity> at the other, where abstractions are more settled (think lower levels of a protocol stack), nothing more than that.

This from Howard Thurman on the growing edge, curtesy of master weaver Curtis Ogden:

What are the fractal components? - are they cell-based teams or are they discrete products and services (your example of a mobile phone suggests the latter).

Good question, could be both and may depend on whether we are talking the breakdown within our org or that of our suppliers. E.g. in systems thinking terms. e.g.

• Public Cloud is used as a commodity inasmuch as we pay per use (broadly speaking) and consume through a standard interface that is the same for all customers (portal, API). But under the covers, AWS is a massively complex industrial economy in its own right even though this all rolls-up into its Cloud platform. As a user this is generally hidden from us
• We have a team that creates safe templates for use with Cloud. This is a sort of product that allows teams above to do better custom build. The team that creates these templates has its own internal stack of genesis, custom build, product commodity but exposes the result only as product

At a fractal level, who/what decides where the lower level fractal component sits in the upper level domain....and vice-versa??

Ideally the efficiency of the industrialisation process within the organisation as market economy e.g. if everyone is doing the same thing in <Custom Build> it is better treated as a <Product> or <Commodity>. Simon Wardley made this exact point at Map Camp. In the real world, limitations of teams, politics, budgets, organisation, culture introduce biases and resistance.

If it's fractal then how does recursion work? -?the fractal model implies mode 1 and mode 2 for each fractal level??- some other recursive models such as VSM have a structure to recursion and constraints such as requisite variety that I don't see here.

I am not an expert on Beer or viable systems model. Something to do with evolving itself. don't forget:

• the system as a whole can still be viable even though some of the components may not (e.g. traditional data centres)
• Some of the components will be more viable than the whole (AWS will likely outlive Centrica)

By all means disregard these questions if you think you are suggesting teal-based ideas?to a green thinker :-)?

Thanks for the complement. I see myself as a Teal thinker as well as Green, Orange, Amber and when absolutely necessary Red. This article is inspired by all these notions inasmuch as I want it to be both humanistic and ruthlessly efficient at the same time. It is more a reflection of my growing understanding of Wardley mappings than Teal, and also reflects a unique lens I have into the workings of a very complex organisation trying to evolve and modernise.

Hope that helps.

Postscript

Sparse graphs, scale-free networks, in this case factors in an engineering problem plotted against each other and interactions explored and ranked: