Wardley Mapping: Build vs Buy Decisions as Code

Last week I sat in a keynote by Simon Wardley, an introduction to the mapping technique that carries his name. I knew about Wardley Mapping and had never drawn one. Early on he put up an ordinary systems diagram, the boxes-and-arrows kind every one of us has in a slide deck somewhere, and said that it does not represent the architecture of the system. “It represents a belief.” It shows what we hope the system looks like. The code, he said, is the architecture: “the collection of all the decisions we’ve actually made.”

I partly disagree, and I will come back to why. I remember the line because of where he took it. He closed by saying the future of systems architecture “is all about deciding who makes what decisions and where.” That is a statement about judgement, and judgement is exactly what our diagrams are bad at showing. A box diagram tells you what talks to what. It says nothing about which of those boxes you should still be building yourself.

A Wardley map is a belief too. The difference is that it is explicit, shared and positioned, so you can point at a component and say it sits in the wrong place. This post covers what a map is, why resistance to change keeps components stuck on the wrong side of it, and how to draw your first one as a text file that lives in your repository next to your ADRs.