When business architecture becomes theatre

Business architecture does not become theatrical because it is detailed. It becomes theatrical because nothing changes because of it. The enterprise produces artefacts, talks fluently about them, and still cannot show where any funding, sequencing, governance, or design choice improved as a result.

That is the failure mode to guard against in every Stage 3 module. And it is particularly dangerous because it does not feel like failure. Theatre feels productive. The workshops are busy. The artefacts accumulate. The terminology sounds rigorous. The only reliable signal that something is wrong is the absence of consequence: nothing actually changed because of the work.

The challenge is that theatre is often indistinguishable from useful architecture at the point of production. Both produce capability maps. Both produce value streams. Both produce gap logs. The difference only becomes visible later, when someone asks whether the artefact changed a decision. If the answer is no, the artefact was theatrical regardless of how well it was produced.

Five patterns appear repeatedly in enterprises where business architecture has become theatrical. Each one is dangerous because it mimics the appearance of productive architecture work.

1. Capability maps with no planning or governance consequence

The map exists, gets shown in presentations, and influences no investment, sequencing, or ownership decision. A useful capability map is one that the Architecture Board references when making a funding decision. A theatrical capability map is one that sits in a repository and is opened only when the architecture team needs to demonstrate that it has done architecture work.

In the London case, the capability map earns its place because it answers a specific question: "Which enterprise abilities constrain connections turnaround most severely?" That question has a governance consequence: the three weakest capabilities receive dedicated architecture depth in Phase C. Without that question and consequence, the same map would be decorative.

2. Value streams with no bottleneck evidence or no downstream action

The value stream has been drawn but nobody has used it to identify where value is delayed, degraded, or made expensive. Or the pain points have been identified but no downstream action follows from them. A value stream that identifies the assess-to-study handoff as the single largest source of delay but generates no gap-log entry and no capability-improvement recommendation is theatrical. It has produced the right analysis but discarded the consequence.

3. Organisation maps that restate the org chart without exposing interface risk

The map shows reporting lines rather than responsibility relationships, handoff failures, or contested ownership. A useful organisation view reveals the planning-to-design interface problem. A theatrical organisation view reproduces the HR structure with architecture labels attached.

4. Gap logs that list differences without consequence, dependency, or implied intervention

The log compares baseline and target without saying why the difference matters or what to do about it. As Module 23 explained, a gap log without consequence and intervention logic is a comparison table, not a planning tool. The comparison looks thorough but cannot support a single prioritisation decision.

5. Endless workshops that widen the conversation but never sharpen it

The architecture team facilitates more and more sessions, gathers more and more input, and produces more and more versions, without ever converging on a decision-ready output. Each workshop is described as "productive" and "useful", but the architecture never reaches a point where it can be used to make an actual decision. The workshops are the architecture. There is no separate output.

This pattern is especially dangerous because it consumes stakeholder time and goodwill. After enough workshops without consequence, stakeholders stop attending. The architecture team interprets declining attendance as stakeholder disengagement rather than as a signal that the work is not producing usable output.

Four questions can be applied to any business-architecture artefact to test whether it is earning its place. These questions should be asked during production, not only in retrospect. Waiting until the artefact is complete to discover that it has no consumer or no decision to serve wastes the time that was spent producing it.

Question 1: Which decision does this artefact improve?

If the artefact cannot name a specific funding, sequencing, governance, or design decision that it makes better, its purpose is unclear. The London capability map improves the decision about which capabilities receive dedicated Phase C depth. The London gap log improves the sequencing decision about which gaps to address in the first transition state. If an artefact cannot name its decision, it may be a solution looking for a problem.

Question 2: Which dependency, bottleneck, or governance issue does it expose?

If the artefact does not reveal something that was previously hidden or implicit, it is restating what the enterprise already knows. The London value stream exposes the assess-to-study handoff as the single largest source of delay. That was not visible before the value stream was produced. If the artefact exposes nothing new, it is documentation, not architecture.

Question 3: Who actually consumes it and for what action?

An artefact without a named consumer and a specific use case is an output without a customer. Architecture outputs need customers just as much as enterprise services do. The Architecture Board, a programme sponsor, a delivery team, a governance review, or a later architecture phase are all valid consumers. "The architecture repository" is not a consumer; it is a filing cabinet.

Question 4: What would be lost if the artefact did not exist?

This is the simplest and most honest test. If the answer is "nothing would change," the artefact is decoration. If the answer is "the Architecture Board would lose its basis for sequencing the first three work packages," the artefact is earning its place.

Applying the usefulness test is not about reducing the artefact set to the minimum. It is about ensuring that every artefact that exists is earning its keep. A small set of useful artefacts is worth more than a large set of decorative ones. And the discipline of asking these questions during production, not just in retrospect, keeps the architecture team focused on consequence from the start.

The usefulness test identifies theatre after it has happened. Three operational disciplines help prevent it from happening in the first place.

Discipline 1: Decision linkage

Every artefact should name the decision it serves before production begins. If the decision changes, the artefact should change. If the decision disappears, the artefact should be retired. This linkage prevents artefacts from becoming permanent fixtures that outlive their purpose.

In the London case, the capability heatmap is linked to the decision: "Which capabilities constrain connections turnaround most severely, and which should receive dedicated architecture depth in Phase C?" If the connections programme were cancelled, the heatmap would need to be linked to a new decision or retired. An artefact that persists without a current decision to serve is a candidate for theatre.

Discipline 2: Consumer identification

Every artefact should name who consumes it and what they do with it. The Architecture Board, a programme sponsor, a delivery team, a governance review, or a later architecture phase are all valid consumers. "The architecture team" is not a sufficient consumer because it implies the artefact exists for the team's own reference rather than for a downstream action.

If no consumer can be identified, the artefact should not be produced. This sounds harsh but it prevents the most common form of theatre: artefacts produced because a methodology recommends them rather than because someone needs them. TOGAF recommends many possible artefacts. Not all of them are relevant to every engagement. The discipline of naming a consumer before production keeps the artefact set focused.

Discipline 3: Consequence tracking

After the artefact has been in use for a cycle (typically three to six months), the team should be able to point to at least one thing that changed because of it. One funding decision influenced. One sequencing choice justified. One dependency exposed. One governance review improved. If nothing changed, the artefact needs revision or retirement.

Consequence tracking requires honesty. It is uncomfortable to admit that an artefact the team spent weeks producing has not influenced anything. But that honesty is what separates an architecture team that delivers value from one that delivers volume. In organisations where the volume of architecture output is treated as a proxy for architecture quality, consequence tracking is the corrective.

The London case from Module 24 provides a clear contrast between architecture with consequence and architecture as decoration. Each artefact in the London walkthrough can be tested against the four usefulness questions.

The capability map. Decision it serves: which capabilities constrain connections turnaround most severely. Dependency it exposes: network planning visibility blocking the assess-to-study handoff. Consumer: the Architecture Board, using it to prioritise Phase C depth. What would be lost: the Board would lack a structured basis for deciding where to invest architecture effort. Verdict: earning its place.

The value stream. Decision it serves: where to focus handoff improvement. Dependency it exposes: the assess-to-study information loss that accounts for the largest share of elapsed time. Consumer: the programme sponsor, using it to redirect attention from portal replacement to handoff redesign. What would be lost: the enterprise would continue blaming the portal for delays that sit at handoff points. Verdict: earning its place.

The footprint view. Decision it serves: whether the target business architecture is worth funding. Dependency it exposes: services without measures that cannot be evaluated. Consumer: the Architecture Board, using it to assess whether the transformation will deliver measurable improvement. What would be lost: the Board would approve or reject the target on instinct rather than evidence. Verdict: earning its place.

The gap log. Decision it serves: which gaps to address in the first transition state and which interventions each gap requires. Dependency it exposes: Gap 1 (planning-data visibility) is foundational, blocking Gaps 3 and 4. Consumer: Phase E and Phase F teams, using it to define work packages and sequencing. What would be lost: the roadmap would be sequenced by technical convenience rather than business priority. Verdict: earning its place.

Every artefact in the London pack passes the usefulness test because each one was produced with a specific decision, consumer, and consequence in mind. That is the standard to carry forward into every future architecture engagement.

What the London case makes the learner stricter about

The London walkthrough should make the learner stricter, not more indulgent, about what counts as useful architecture. Having seen artefacts tied to real consequences, the learner should now be uncomfortable with artefacts that cannot name their decision, their consumer, or their consequence. The London case is not just an example. It is a calibration. It sets the bar for what a useful Stage 3 pack looks like, and anything below that bar should prompt the question: is this architecture or is this theatre?