The purpose of this artifact is not to list everyone involved. It is to find the people who can stop the work, and to write down what they actually care about before they tell you at the worst possible moment.

A stakeholder who can veto and whose concern you never recorded is the single most common cause of an architecture that gets built and then shelved.

Template

Deliberately excluded — who is not a stakeholder on this engagement, and why. Write this down. It is the field that prevents scope drift by committee.

…

Concerns that conflict — list the pairs that cannot both be fully satisfied, and which one the sponsor has said wins.

Worked example — Karoo Retail Group

Deliberately excluded

Supply chain and warehouse systems. They touch the customer record only via fulfilment status, and pulling them in doubles the estate under analysis for a read-only dependency. Revisit at the next cycle — recorded so nobody re-opens it mid-engagement as though it were an oversight.

Concerns that conflict

The two mistakes this artifact exists to prevent

Listing roles instead of people's actual concerns. "The CFO is concerned with cost" is a job description, not a concern. "The CFO has been burned by a programme that ran two years without shipping" is a concern, and it tells you that your roadmap needs a visible delivery early rather than a perfect one late.

Leaving the conflicts blank. Every real engagement has at least one pair of concerns that cannot both be fully met. If you do not name them and get a ruling early, you will discover them during delivery, when the cost of choosing has gone up and the person who could have chosen has moved on.

Most principle sets are useless, and they are useless in a predictable way: they are statements nobody would ever disagree with. "We will be secure." "We will prefer reuse." "We will be cloud-first." Nothing in a real argument is settled by any of them, because the opposing position never claimed to be insecure.

A principle earns its place only if it rules something out. If you cannot name a decision it forbids, it is a value, not a principle — delete it.

Template

Use one block per principle. Five to eight is plenty; more and nobody recalls them under pressure, which is the only time they matter.

P1 — <short imperative name>

Statement — one sentence, in the imperative.

Rationale — the specific pain this exists to prevent. Reference the real incident or cost if there is one.

Implications — what teams must now do differently. Concrete.

This principle forbids — name at least one thing that would otherwise be reasonable. If this is blank, the principle is not a principle.

When it does not apply — the honest exception. A principle with no stated boundary gets applied absurdly once, then ignored permanently.

Worked example — Karoo Retail Group

P1 — One fact, one owner

Statement — Every business fact has exactly one system of record; everything else holds a copy that is explicitly marked as a copy.

Rationale — Nine systems each held a customer record and each believed it was authoritative. Reconciling them was a standing monthly cost, and a deletion request could not be honoured with confidence.

Implications — New systems read the customer from the shared record rather than storing their own. Where a local copy is unavoidable for performance, it is read-only and carries the source's version.

This principle forbids — a new service creating its own customer table because the shared record's API is slower than a local join. That is precisely the trade this principle refuses.

When it does not apply — analytical stores and warehouses, which are copies by definition and are not consumed for transactional decisions.

P2 — Buy the boring, build the differentiating

Statement — Build only what a customer would notice us doing better than a competitor; buy or adopt everything else.

Rationale — Engineering capacity was being spent on a bespoke scheduler and a homegrown feature-flag system while the checkout experience went unimproved.

Implications — Every build proposal names the customer-visible difference it creates. If it cannot, procurement is the default path.

This principle forbids — writing our own identity provider, message broker, or job scheduler, however satisfying.

When it does not apply — where no viable product exists, or where the licensing model scales worse than our own maintenance cost. Both must be shown, not asserted.

P3 — No cutover the business can feel

Statement — Every migration step must leave the estate in a working state that could be run indefinitely.

Rationale — The business is open seven days a week. There is no weekend to switch anything off, and a rollback plan that has never been exercised is a document, not a plan.

Implications — Work is sequenced as transition architectures, each shippable and each independently valuable. Strangler patterns over big-bang replacement.

This principle forbids — a migration design whose intermediate states only work if the next step lands on schedule.

When it does not apply — genuinely isolated internal tools with no store or customer dependency.

P4 — Standards have an escape hatch, and it expires

Statement — Any team may deviate from a standard through a recorded dispensation with a named owner and an expiry date.

Rationale — The previous review board had no legitimate exception path, so teams stopped bringing decisions to it and deviated silently. Governance with no escape hatch does not produce compliance; it produces invisibility.

Implications — Dispensations are cheap to request, publicly visible, and tracked to expiry. Accumulated dispensations against one standard are treated as evidence the standard is wrong.

This principle forbids — an indefinite exception, and equally forbids refusing all exceptions.

When it does not apply — regulatory and data-protection controls, which are not dispensable.

The test

Take your last three contested technical decisions. For each, ask which principle would have settled it. If the answer is "none of them", the set is decorative — rewrite it around the arguments you actually have.

This is the scope fence. It is the artifact that lets you say "that is a new engagement" without it sounding like a refusal.

Keep it to two pages. A Statement of Architecture Work that nobody finishes reading fences nothing.

Template

Engagement name · Sponsor (the one person who can approve scope changes) · Architect · Period

1. Why now

Two or three sentences. The business event that made this urgent — not a general aspiration. If you cannot name what changed, the engagement has no deadline and will drift.

2. Scope — in

The domains, systems, and processes this engagement will produce architecture for. Name systems, not themes.

3. Scope — explicitly out

The things a reasonable person would assume are included, and are not. This section is longer than section 2 in a good document. Every line here is an argument you will not have twice.

4. Constraints

What is fixed and not up for redesign — contractual, regulatory, technical, or calendar.

5. Deliverables

One line each, with the phase that produces it.

6. What "done" looks like

Observable conditions, not documents produced.

7. Non-goals that will be proposed anyway

The predictable scope-creep requests, pre-refused with the reason.

8. Approval

Sponsor, date. Changes to scope require a new signature, not an email.

Worked example — Karoo Retail Group

Engagement Customer Record Consolidation · Sponsor Group CTO · Architect — · Period One financial year

1. Why now

The board has committed publicly to an omnichannel programme, and a data-protection audit found no single path to erase a customer. Both land in the same year, and both fail for the same underlying reason: the customer exists nine times.

2. Scope — in

• Point-of-sale (in-store transactions and returns)
• Ecommerce platform (accounts, orders)
• Loyalty platform (membership, points)
• The customer record itself: ownership, schema, lifecycle, and access path
• Integration between the three consumers above and the shared record

3. Scope — explicitly out

• Supply chain and warehouse. Read-only fulfilment status only. Not re-platformed, not re-integrated.
• The ecommerce front end. Its data access changes; its UX does not.
• Payments and PCI scope. Untouched. Any change here is a separate engagement with its own approval.
• Marketing automation. Consumes the record after this work; not migrated as part of it.
• Store hardware and the till application. No change at the till. This is a hard constraint from Retail Ops, not a preference.
• Analytics warehouse. Continues to receive copies. Not a system of record and not in scope for consolidation.

4. Constraints

• The estate operates seven days a week. No scheduled full outage is available.
• The loyalty campaign date is externally announced and cannot move.
• Data protection: a customer erasure request must be demonstrably satisfiable at the end of every transition state, not only at the end of the programme.

5. Deliverables

6. What "done" looks like

• One system of record for the customer, named and owned by a named person.
• Point-of-sale, ecommerce and loyalty all read that record rather than a local copy.
• A single erasure path exists and has been executed end to end at least once.
• No point-of-sale downtime attributable to the migration.
• Every remaining local copy is documented, read-only, and versioned to source.

7. Non-goals that will be proposed anyway

• "While we're in there, let's replace the loyalty platform." No. Replacing a consumer and consolidating the record at once means neither can be rolled back independently.
• "Can we add a single customer view for marketing?" Not in this engagement. It becomes trivial afterwards and expensive during.
• "Should we move to microservices?" Out of scope as an objective. Service boundaries change only where consolidation requires it.

8. Approval

Sponsor: ____________________ Date: __________

Why section 3 is the important one

Everyone writes section 2. The engagements that sprawl are the ones where section 3 was left thin, because scope creep almost never arrives as a request for something obviously outside the work. It arrives as something adjacent and apparently free — "we're already touching loyalty, so…" — and without a pre-written refusal and a reason, the honest answer in the room is "I suppose so".

A capability is something the business does, stated so that it stays true if you replaced every system and reorganised every team tomorrow. "Accept payment" is a capability. "Stripe integration" is not. "Warehouse team" is not.

The map earns its keep in exactly one way: it lets you argue about where a capability lives without the argument becoming about which department owns which system.

Template

Two levels is usually enough. Three is a research project.

<Value stream>
  ├── L1 Capability
  │     ├── L2 …
  │     └── L2 …
  └── L1 Capability

Then rate only what you are going to act on:

Contested capabilities — the ones performed in more than one place, where nobody agrees who owns them. These are the whole point of the exercise; list them explicitly rather than burying them in the table.

Worked example — Karoo Retail Group

Sell to a customer
  ├── Identify the customer            <- contested
  ├── Present products and price
  ├── Accept payment
  └── Fulfil the order
Keep a customer
  ├── Record customer consent           <- contested
  ├── Accrue and redeem loyalty value
  ├── Handle returns and refunds
  └── Communicate with the customer     <- contested
Run the estate
  ├── Manage stock position
  ├── Report on trading
  └── Erase a customer on request       <- contested, and performed nowhere completely

Contested capabilities

Identify the customer. Performed three times, three different ways. In store by loyalty card scan, online by account login, in the loyalty app by phone number. None of them can tell you they are looking at the same person. This is the capability the entire engagement exists to consolidate.

Erase a customer on request. Each system can delete its own rows. No system can assert the person is gone from the estate. A capability the business is legally required to have and does not actually have is the strongest possible argument to a funding committee — stronger than any efficiency case.

The two failure modes

Mapping the org chart. If your L1 capabilities correspond one-to-one with departments, you have drawn the organisation, not the business. The test: if the company reorganised next month, would the map need redrawing? It should not.

Mapping everything. A complete capability map of a mid-size retailer runs to hundreds of boxes and changes nothing, because no one can hold it in mind. Map the value streams the engagement touches, rate only what you intend to act on, and leave the rest unrated rather than guessing.

The output that matters is the contested list. Everything else is context for it.

The artifact that turns "our data is a mess" into a fundable, arguable, finishable piece of work.

You are looking for one thing: the same business fact stored in more than one place, with no agreement about which one is right. Not tables. Not databases. Facts.

Template

Pick one entity at a time. Customer first, almost always — it is the entity with the most duplication and the only one with a legal deletion requirement.

Entity: <name>

Reconciliation cost today — what is spent keeping these in agreement: people, jobs, and the failure that happens when they disagree.

The disagreement test — when two of these hold different values, which one wins today? If the answer is "whichever was updated last" or "nobody knows", write that down. It is the finding.

Target — one system of record, named. Every other row becomes one of: read-through (no local storage), cached copy (read-only, versioned to source), or retired.

Worked example — Karoo Retail Group

Entity: Customer

Reconciliation cost today A monthly manual exercise to align loyalty balances against POS transactions, plus a standing service-desk workload for customers who exist twice and cannot see their own points. When 1 and 3 disagree, the customer is told the balance from whichever system the agent happened to open.

The disagreement test There is no rule. Precedence is decided by which system the person answering looked at. That single sentence justified the engagement more effectively than any cost model.

Target

Note that points stay in the loyalty platform. A points balance is genuinely that system's own fact, not a duplicated customer attribute. Consolidating it into the record because it sits next to customer data would be the same mistake in the opposite direction.

How to run it without a six-month discovery

Do not model the estate. Ask one question of each system owner: "If this disagreed with another system about a customer's name, which one is right?"

You will get three kinds of answer — a confident "us", a confident "them", and a pause. Every pause is a finding, and the pauses are usually the majority. The audit is mostly a record of pauses.

The artifact almost every organisation gets half-right.

An architecture contract is bidirectional. The delivery team commits to something, and architecture commits back. Written as a one-way list of obligations on delivery, it is not a contract — it is a compliance checklist, and it produces the behaviour compliance checklists always produce: teams route around it and stop asking.

The second column is the one that makes governance work, and it is the one that is almost always missing.

Template

Delivery team · Work package · Period · Architect · Signed

The delivery team commits to

Architecture commits to

Review points

Escalation

Who decides when the two sides disagree, and how long that decision may take.

Worked example — Karoo Retail Group, Loyalty delivery team

Work package Loyalty reads the shared customer record · Period Transition 4 · Architect — · Signed —

The delivery team commits to

Architecture commits to

Note what column 4 does. Every architecture commitment has a stated consequence for architecture failing to meet it, and the consequence always favours delivery continuing. That is what makes the contract real rather than decorative. A governance process whose only failure mode is "the team waits" is a governance process that will be bypassed.

Review points

Three review points across a work package. Not every sprint, not every pull request — reviews attached to events where the answer can still change something.

Escalation

Unresolved after one working week: Group CTO decides, within two working days. Silence past that is treated as approval of the delivery team's position.

The test for whether yours is real

Cover the "delivery team commits to" column and read only what architecture committed. If it reads as an empty courtesy — "architecture will provide guidance" — you have a checklist. Real commitments have dates, numbers, and a named consequence when architecture is the one who misses.

A dispensation is a recorded, scoped, expiring permission to deviate from a standard.

Governance without a legitimate escape hatch does not produce compliance. It produces invisibility: teams stop asking, deviate quietly, and the architecture function finds out during an incident. The register exists so that deviation is cheaper to declare than to hide.

The expiry is not paperwork. A permanent exception is not a dispensation — it is an undocumented change to the standard.

Template

Standing rules

1. An expiry date is mandatory. No open-ended dispensations. If it genuinely cannot expire, that is a standards change, and it goes through standards change — not here.
2. Scope is written narrowly. "Team X may cache customer data" is too broad. "The loyalty campaign service may hold a read-only customer name and card number for the duration of the November campaign" is a dispensation.
3. The register is public. Hidden exceptions teach everyone that exceptions are shameful, which is exactly how you lose visibility.
4. Count them. Three or more dispensations against the same standard is evidence the standard is wrong, not that three teams are difficult. Review the standard.

Expiry review

Worked example — Karoo Retail Group

Expiry review

What the register tells you that nothing else does

D-001 is the interesting one. A team hit a genuine standard against a genuine external deadline. Without a dispensation path there were only two outcomes: the campaign misses its announced date, or the team quietly builds a customer table and nobody hears about it for a year.

The dispensation produced a third: the deviation happened, it was narrow, it was visible, it had a date, and it was actually removed. That is what a working governance process looks like — not the absence of deviation, but deviation you can see and unwind.

If your register is empty, the most likely explanation is not that everyone complies. It is that nobody is asking.