Wardley Mapping and Strategy for Software Developers

There are often decisions made around us at work that seem odd, or lacking in detail, or just plain wrong. However, when economic times are turbulent, it might seem sensible to ignore these decisions. Sometimes, of course, you can’t.

Changes that impact the software development process can be smuggled in as business decisions, with little explanation or forethought. Senior developers — those entrusted to maintain product or service quality — have a responsibility to call out any decisions, however they were made, if they materially damage their team or work quality. But this opens up another issue.

All devs need to be aware of the “strategy”, otherwise they are locked out of conversations that should concern them. By the time a bad decision comes to your door, it is usually too late to start getting interested. But engineers also need to be proactive; technical expertise is often needed to spot certain competitive moves. For example, it took Kodak a long time to realize that digital photography had dealt them a fatal blow — even though they invented the concept.

“But it was filmless photography, so management’s reaction was, ‘That’s cute — but don’t tell anyone about it.’”

If you are dreaming of starting your own business, then you should naturally be sensitive to the business landscape. But it should be part of your skill set to have a solid model in your head.

Welcome to Wardley Mapping

So what does this actually mean practically? Simply visualizing your environment accurately is a win, which is why I quite like Wardley mapping (disclosure: I have met Simon Wardley, and I tease him regularly on Twitter). This is a more engineering-focused way to look at a business and isn’t dependent on stories, aphorisms or strange MBA terms. A few people have asked me personally whether this method really works. But it isn’t a “method” as such; just a way to agree on the environment that might otherwise be left unchallenged. Jennifer Riggins has already covered the background to Wardley mapping in detail, so I only need to summarize what we need to become aware of.

We’ve all seen diagrams like the one below. These do a job of trying to isolate the essential components of a business. But they are not actually maps as such. why? Well you can take any of the blobs and move them as you wish, but they won’t change the meaning. Technically this is a graph. A map should show people how to navigate through a space — and this does not.

Let’s improve on the above diagram a bit with a quick contemporary diagram of a very simple business. This one is just making a cup of tea for, I assume, a tea-making enterprise. But we will have some information on the Y-axis; the most customer-facing activities are nearest the top.

Let’s start with the customer and product:

Then put in the rest necessary components. These are the resources or services needed to make the product:

So the components are liberally scattered about, but at least we can see that the main resources are “cups”, “tea”, water and power for the kettle.

Now let’s use the X-axis to show evolution. This transforms the diagram into a map. But what does evolution mean exactly?

Usually, a business is a healthy mix of the bespoke, the off-the-shelf and the outsourced. An organization’s “secret source” is made internally; tech that is central but not vital to the business is bought off the shelf and stuff that is widely available is completely outsourced. For example, no one makes their own electricity or water. These are commodities. It is nice to sell a product or service as far to the left as possible, as that is rarer and has less competition. The further right your product is, the harsher will be the competitive climate.

The important observation that was made on the X-axis is that technology evolves. This means that when I invent something, it is new and appears on the left. Then I package it up and share it locally. Then a company uses it in a major product. Then the product is no longer sold but rented as it becomes ubiquitous. Eventually, it is just treated as a utility. The point is, evolution only moves in one direction. So every component you use will either slowly die, or migrate to the right. not necessarily smoothly; often in sudden bursts.

Now, you perhaps noticed that the kettle is too far to the left, in the wrong place. Where should it be? Should you use a kettle at all? The diagram allows you to challenge perspectives — it doesn’t solve anything on its own but encourages open discussion about the model.

But it is the movement of components, the migration towards the right that kind of represents a glimpse into the future. Below is a handmade map of the classic tea diagram (still with the out-of-place kettle) but focusing on the evolution of the tea itself.

Whereas the loose tea was artisanal, the industrialization and control of teabags is clearly a better bet for quality control — if your business is selling cups of tea. Now look at your company. Are there accidental “artisanal” elements? Are there any artisanal kettles? As light-hearted as this approach appears, many companies persist with processes that do not actually lend themselves to improving business. Companies hang on to old machines, old working habits, private cloud or on-premise solutions, because “they have always worked”, are part of some founding myth or are tied up in some parallel costs. These can blind a company to onward evolution.

On the other hand, observability comes into play when you want to see where to compete. By understanding the customer response to your product or service a little better, you might be able to remove, change around or improve a component. Maybe they like cooler tea? Or bring their own cups?

We know computing as an infrastructure is moving rapidly to becoming a commodity. We saw a strange decision at the end of last month concerning Microsoft, a British regulator and cloud gaming. While the ruling was unexpected, it is wise to assume that over time gaming will also migrate rightwards into the cloud. I remember when games were products you had to buy or rent in shops. Now they are downloaded from publisher platforms.

Getting Started Mapping

So how do you map your own projects? One good start is simply to get your team together and see if they can map out just the build process — with a build as the final product (the cup of tea). For example; starting from an agreed story, through to a change in the code in the repository, to a checkout into a staging build, to deployment. See if everyone even agrees what this looks like. The result should eventually be a common understanding.

There are plenty of introductions to mapping, but the important thing is to recognize that you can represent a business in a fairly straightforward way. Look at what your company does, work out its value chain and the required components. When you agree on a faithful representation, everyone can start thinking about the business in a connected way.