The Map Is the Architecture

In the second workshop with a distributor that sells into four European countries, the CIO asked when he would see the architecture diagram. Behind us, two days of whiteboard: one customer order followed from an email in one country to a shipped box in another, through three business systems, typed in by hand three times. We said the whiteboard was the design. He didn't look convinced. This is the longer answer, and it holds whether you move parts, patients, policies or parcels.

Growth stalls at the handoffs

Growth arrives as more volume, new markets or an acquisition. What breaks is rarely a team; it is the space between teams: the order copied from one system into another, the PDF a person reads and retypes, the monthly figure stitched together from spreadsheets. Each is a handoff between a person, a system and a document, and one done by hand has the capacity of that person's week. When the business doubles, that is where the queue forms.

So the map we draw in the first week follows one piece of work that growth is squeezing, from start to finish, through whichever systems and countries it crosses. The handoffs are where everything we later build will sit.

A handoff is an agreement

On the whiteboard a handoff is an arrow. In the system it is a written agreement: what the data looks like, what each field means, which totals must add up, when it arrives, and who owns each end. Left as "the file we send every night", it fails quietly: a date format changes after an update, a total goes missing, and nobody notices for a month. Under an agreement, a file that breaks it is held back whole, and its owner hears about it the same morning.

Writing them takes most of the first month, because two teams that have swapped a file for years often mean different things by "delivered". They are also the first thing a new market needs: when the distributor's fourth country joined, the work was one new agreement and a table matching its product codes to everyone else's.

A step has a kind

Before anyone picks an AI model, every box on the map is marked as one of three kinds of work.

Reading turns something written for a person into data a system can use: a supplier's PDF into lines with batch numbers and expiry dates, an email into an order, a referral letter into a case, a service ticket into a category. This is where AI earns its place, because the input has no fixed shape and no rule can be written for it.

Checking has one right answer: a quantity against what was ordered, a stock level against the point where you reorder, a ticket category against the team that handles it. This goes to ordinary software, which costs nothing per run and which the team can read. AI can do the sum too, but it charges for each one and gets some wrong.

Deciding changes something the company will be held to: stock is accepted into the warehouse, a report is signed off, an order is confirmed to a customer. This belongs to a named person, who sees the evidence on one screen and says yes or no.

Steps move in one direction only, from AI toward ordinary software. Once a supplier's document layout has stayed the same for long enough, the reading step gets a fixed parser and becomes a checking step. For a public agency we built ticket sorting this way, inside the agency's own network: AI reads and classifies, fixed rules send each ticket to a team, and the agency's staff change those rules without us.

A decision says how much the AI may do

Each deciding step carries one more line on the map: how far the AI is trusted there. It may only suggest, or prepare work for a person to approve, or act and report afterwards. That level is earned on evidence, case type by case type, and it lives on the map beside the step, where the responsible manager can see it. Because the map also knows what feeds each step, it knows when the evidence has gone out of date. On an order desk we tested for a hardware supplier, the rule beside the reading step says: if a new order format starts arriving, every decision it feeds goes back to "a person approves" until it has proved itself again. A settings screen inside an AI tool can't express that rule; it doesn't know where its input comes from.

One record runs along the map

Every handoff is logged with its result, every reading step with what it read and where, every decision with the evidence, the person and the time. For a group that combines the accounts of more than twenty companies into one board report, that record enforces a simple rule: a wrong number is never fixed in the report, only in the company's own books. When a figure looks off, the record says which company, which system, which line.

The running system reads the map

The difference between a whiteboard and an architecture diagram is that our system runs from the map. The agreements, the kinds of step, the trust levels and the routing rules sit in one folder of files with a full history of every change, inside the client's own environment. Changing the map means changing those files through the client's normal approvals. An AI prompt is one file there, and never holds the rules of the business.

This matters more now that much software is written with AI. An AI coding tool does exactly the task in front of it, well, with no sense of how it fits the whole. The map says where each kind of work belongs before anyone, person or AI, writes it. A change with no place on the map is not accepted.

Keeping it true

The most common failure we find in systems built before we arrive is a map drawn once and left behind as the work changed, until the handoff everyone relies on is a spreadsheet emailed on Fridays. A map stays true only when daily work cannot run without it, so the queue of exceptions is organised by the map's steps, the test cases are labelled by step, and every change to the system is a change to the map.

After we leave, two named people on the client's side own it: the manager responsible for the work, who approves changes the way they approve any change to how their team works, and one engineer who built it with us. We have got the level of detail wrong more than once; a map with every click on it is as useless as one with none.

To try this on one piece of work: put the people who do it in the room, follow it from start to finish, write the five agreement lines on every arrow, write reads, checks or decides in every box, and a name on every decision. Then ask whether an engineer who has never met you could add your next market from it. If not, it is still a diagram.