Map evolution not maturity

Many people inquire if the evolution axis of a Wardley Map can be substituted with maturity. Although possible, I discarded this approach around 2004/05. Wardley Maps employ evolution rather than maturity for specific reasons, which I will illustrate using maps—no surprise there!

To clarify, I'll reference a recent example familiar to many of you, where equating evolution with maturity resulted in billions of dollars in losses for companies. This example is the adoption of cloud technology.

A journey into cloud - again!

Let us revisit 2004. At that time, I was running a company of application developers crafting various applications. These applications, ranging from custom-built to configurations of existing products, were supported by servers and guided by certain architectural practices. For simplicity in mapping, we represent our applications as a pipeline of choices within a square box, which can be expanded for detailed analysis.

The accompanying simple map reflects that architectural practices were increasingly aligning with established good practices. Meanwhile, servers, though still marketed aggressively by salespeople and vendors, were progressively treated as commodities. Astute buyers could often secure them at 80% off the list price—a price largely set to ensnare the unwary. (map link)

By 2006, the landscape represented in our map had evolved. It's important to note that, like geographical maps, these maps do not inherently include a time element. We discuss time in terms of how long it takes for one map to transition into another.

In that year, driven by internal frustration with technology vendors, Amazon launched EC2, a utility computing environment. EC2 was not the first attempt at utility computing, but it succeeded where others hadn't because several crucial elements aligned: the concept of utility provision, prevailing frustration with existing vendors (Attitude), the suitability of compute for utility services, and the necessary virtualisation technology. These factors—Concept, Attitude, Suitability, and Technology (CAST)—are essential to overcome inertia against change.

I have updated our 2006 map accordingly. You can add an inertia bar to visually represent resistance to change, but I'll leave that to the discretion of the reader. (map link)

Servers and cloud computing are essentially both forms of compute; the key difference is that servers are compute offered as a product, while cloud computing is compute provided as a utility. It's straightforward.

For clarity, I'll update the map to include a compute pipeline. This pipeline illustrates a choice between using servers or cloud. To depict this, I've expanded our square to encompass these options. However, the choice was somewhat artificial because cloud computing represents a more advanced stage of compute. Thus, the real consideration was not "if" cloud would be used, but "when". (map link)

It wasn't just the compute technology that was evolving; the practices surrounding computing infrastructure were also undergoing significant changes. Initially, we had traditional practices such as disaster recovery, scaling up, and building resilient machines—approaches well-documented in IBM RedBooks, which were invaluable for guiding infrastructure management. Simultaneously, a new set of practices was emerging, including distributed architectures, chaos engines, designing for failure, and continuous deployment. These were a collection of evolving concepts that lacked a formal designation until Patrick and Andy termed them "DevOps." By 2009, the significance of DevOps was recognised to the extent that the first DevOps conference was held.

Let's incorporate these developments into our map to reflect the broader scope of changes in the field. (map link)

As technology evolves, so do its characteristics. In the realm of computing, we've seen this transition from high MTTR (Mean Time to Recovery) with servers to low MTTR with cloud computing. MTTR measures the average time it takes to recover from a failure.

In the server-centric environment, a hardware failure could mean weeks or months before a new machine was purchased and installed, resulting in high MTTR. Conversely, in the cloud environment, recovery is as quick as making an API call, taking mere seconds, thus characterising it with a low MTTR.

The practices collectively known as DevOps, which emphasise rapid deployment and recovery, have both benefited from and co-evolved with the low MTTR characteristic of cloud computing. These modern practices contrast sharply with the more traditional ones that were tied to the older, high-MTTR infrastructure. Let's add this evolution to our map to illustrate these pivotal shifts. (map link)

The map I've described was a simplified version of one we used at Canonical (the company behind Ubuntu) in 2008, which played a key role in our rapid success in the cloud market.

Here's a summary of what we understood at the time:

1. The shift to cloud computing was inevitable because it represented a more evolved form of computing.
2. Architectural practices were evolving alongside the technological changes. Although we didn't yet have a name for these practices, we recognised they would eventually be labelled—later known as "DevOps."
3. The adoption of "DevOps" was unavoidable due to its integration with evolved computing forms. We knew our practices would need to adapt accordingly.
4. Companies would face inertia, rooted in their existing investments and established practices.

These insights were crucial to our early entry into the cloud market, helping Ubuntu become a leading operating system in the cloud. So, what does this have to do with maturity?

"Mapping" from a maturity axis.

Let us take that last map and redraw it with an axis based upon maturity rather than evolution. There are so many types of maturity scales out there, that I'll choose a generic - new to mature. If you do this then the map looks like the following. (map link)

Here are a couple of important considerations when using a maturity-based "map":

1. The "map" does not indicate that computing will evolve into cloud technology; instead, it presents cloud as merely a "new" concept. Such a "map" might suggest sticking with the familiar and more mature servers. This perspective was common among CIOs in 2008, who believed they could choose to ignore cloud computing.
2. The newer practices, which would later be known as DevOps, are simply shown as new practices. There's no implied necessity to adopt them since the "map" does not suggest that cloud computing is a more evolved form of compute. Furthermore, without visible connections indicating a shift in technological characteristics, it's easy to mistakenly think that these DevOps practices could apply just as well to traditional, non-cloud infrastructures, without recognising the co-evolution taking place.

"Mapping" from a maturity perspective will lead to stagnation in a rapidly evolving technological world. I knew this in 2008, having previously seen the problem and dismissed the use of maturity as a mapping axis back in 2004/05 due to these limitations. So, why do people continue to use a maturity perspective in mapping, despite its risks?

Vendors

One group particularly fond of the maturity mapping approach was vendors of traditional products. They disliked my style of mapping because it highlighted that:

a) Their product space was on its way to becoming commoditised.

b) Their customers should transition away from these aging products towards newer but more evolved technologies.

These vendors preferred to portray cloud computing as "immature," suggesting that any emerging practices could still be effectively implemented on their mature, established products. Thus, they argued, organisations should continue purchasing their offerings. This narrative even evolved into promoting private clouds built using their products as a viable long-term solution, and later, the somewhat problematic concept of hybrid clouds emerged. Billions have been wasted on this.

It's wise to approach the maturity axis with extreme caution i.e. run away. It's almost always championed by salespeople who are trying to sell outdated technology that may not be in your best interest. It's not so much mapping the landscape but rather "mapping a perspective which says you should buy their product".

This is why Wardley Maps use EVOLUTION. They don't use maturity. They never will and they are not a maturity axis.

Learning how to map.

I rarely give masterclasses and I rarely travel. However, I have been persuaded to speak at GOTO Amsterdam in June and run a masterclass there.

ADDENDUM

Q1. How does value fit on your map?

A1. Take that final map from an application builder perspective and realise that applications are meeting a need. Consider how the effects of cloud (reducing cost) and DevOps (increasing speed) improve our ability to deliver new needs, to try things out, to experiment. Realise that those new needs will evolve if useful. This will give you a more complete picture (map link).

To answer your question, value is created by meeting the needs of others. It’s all over the map.

Q2. Is your map a network?

A2. The map is built upon concepts of modelling agent networks. You can map any form of collective from the individual (the collective or one) to nation-states. They are all networks.

Q3. How do capabilities fit onto your map?

A3. The ability to deliver something is a capability. A user has a need. To meet that need requires components. Those high-level components are capabilities, but they also have needs. Those require lower-level components to deliver something, which means more capabilities. Users, needs and capabilities are all different ways of saying the same thing?—?components.

Q4. Aren’t your maps about technology?

A4. I have maps of space satellites, maps of healthcare, maps of nation-states, maps of culture, maps of gender identity, maps of individuals?… and so on. You can map activities, practices, data, knowledge and even ethical values. If you wish to stay with technology, that's fine. Lots of people find them useful there.

Q5. Is there a link between maturity and evolution?

A5. Loosely. For example, take a standard diffusion curve for some activity - A[1] - from early adopters to laggards. We tend to think the activity will become more mature as it becomes more widely spread.

However, we tend to get multiple waves of improving versions of the activity i.e. a phone, then a better phone etc. Let's say five examples of improvement - A[1] to A[5] - each with their own diffusion curves.

But those diffusion curves aren't the same. The market itself tends to grow as the activity evolves and becomes suited to the area it is trying to fulfil. They all go to 100% adoption but 100% adoption of different markets.

These evolving markets and evolving instances are what creates the evolution curve i.e. evolution comes from many diffusion curves for many evolving instances of an activity.

This evolution curve creates the axis you see on a Wardley Map

The problem with maturity is:-

1) a single instance of an activity can become mature over time

2) even a stage of evolution for an activity can become mature i.e. A[2] represents an early instance of product whereas A[4] represents the mature product. Think IBM 650 to pizza box servers.

So if you "map" from novel to mature, you not only don't know what you're looking at (a single instance, a stage evolution) but you'll think you are sitting pretty with A[4] "the pizza box server" and scoff at this new and immature A[5] "the cloud" when it appears, and finally, you'll lose your shirt and the business.

Maturity will really bite you.