Architecture Work or Architecture Theater?

Link: https://www.eatransformation.com/p/architecture-work-or-architecture-theater

From Enterprise Architecture Transformation: A Practical Guide

Enterprise architecture (EA) rarely fails because nothing is being done.

More often, the opposite is true. There are models, principles, governance processes, review forums, templates, and structured ways of working. Architecture is visibly present across initiatives. From the outside, the practice may look mature.

In fact, architects are often very good at finding things to work on—for themselves and for others.

But not all of that work is necessarily useful. The impact on actual decisions, priorities, or outcomes can remain limited.

The issue is rarely lack of effort—even if time and resources are often perceived as limited. It is also not always about quality. More often, it is about how the EA practice is positioned relative to planning, decision-making, and delivery. In some organizations, EA practices unintentionally create conditions where architecture work is actively done, but does not meaningfully influence outcomes.

That is architecture theater.

When Enterprise Architecture Practices Become Theater

Architecture theater emerges from recurring practices that look reasonable in isolation but gradually optimize for activity instead of impact. These practices may produce visible work, but their connection to outcomes is weak.

Architecture Defined Through Activity

In some organizations, architecture is understood mainly through what the EA practice produces and maintains: models, principles, roadmaps, standards, and governance activities such as meetings, reviews, and decision forums.

These outputs and routines can be useful. The problem emerges when their existence becomes the measure of progress. Work is considered complete when something has been produced, documented, or reviewed, not when it has informed or changed a decision.

This can be seen, for example, when capability maps are regularly updated but not used in prioritization, or when principles are defined but rarely applied in concrete design situations.

Architects keep busy, even when their impact is limited.

Governance Without Real Influence

Architecture governance may include review processes, checkpoints, templates, and approval mechanisms. Projects engage with the EA practice at defined stages, and the process looks structured.

The key question is whether the process changes anything.

Governance becomes theater when it mainly confirms decisions that have already been made, checks whether required materials exist, or documents choices without shaping them. Reviews may focus on whether documentation is complete and in the correct format rather than whether the underlying solution is sound or aligned with broader structure.

Governance creates value when it helps clarify options, improves decisions, and ensures that relevant aspects of the current state—such as existing capabilities, dependencies, and constraints—are properly taken into account.

Required Deliverables Without Purpose

As part of governance, some EA practices require projects to produce standard architecture deliverables regardless of context.

A project may need to create target state descriptions or provide detailed explanations of how principles are applied simply because the method requires them. In some situations, that can be useful. In others, the material is produced mainly to satisfy the process.

These deliverables can create value when they are actively used—for example, to assess the feasibility of a solution, to evaluate how well it fits with existing capabilities and constraints, or to align individual initiatives with broader architectural direction.

However, when the connection to actual use remains weak, the same work can become largely formal. Deliverables are created, reviewed, and stored, but do not meaningfully influence decisions.

In such cases, the practice may appear disciplined, while its impact on outcomes remains limited.

Optimizing the Practice Instead of the Outcome

EA practices can also become focused on their own internal consistency.

Effort goes into refining metamodels, improving notation, organizing repository, or making the practice more complete. In many cases, enterprise architects spend significant time on developing tooling—configuring architecture tools, extending data models, creating integrations, or optimizing how information is captured and maintained. In a similar way, effort may also go into aligning work with selected frameworks or ensuring compliance with methodology, regardless of whether it improves decision-making in practice.

These activities are not inherently wrong. They can support quality, consistency, and maintainability of architecture work.

The challenge emerges when the focus shifts from supporting decisions to improving the practice for its own sake. Tooling, models, structures, and framework alignment become increasingly refined, but their connection to real decision situations remains weak.

At that point, the practice may become internally strong but externally less relevant. A comprehensive architecture repository is useful only if it helps the organization reason about change.

Architecture Disconnected from Planning and Delivery

Perhaps the most important anti-pattern is architecture work that is not embedded in real planning, decision-making, and delivery processes.

Architecture may happen alongside the organization rather than inside the flow of work. Architects produce material, but are not consistently involved when priorities are set, trade-offs are made, or delivery decisions are finalized.

This disconnection can appear in several ways. Architecture deliverables may be produced too early, before the decision context is clear, or too late, after key choices have already been made. In some cases, relevant architecture input is not produced at all for the situations where it would matter most.

Interaction with stakeholders may also remain limited. If architects are not closely engaged with business, product, and delivery teams, the work may not reflect real needs or constraints. Without regular dialogue, architecture risks being based on assumptions rather than actual decision situations. Sometimes this is due to how the organization is structured—architects are just not invited into the right conversations early enough. In other cases, it may reflect how architects engage with stakeholders and position their contribution.

As a result, even well-structured material may remain unused, or used only partially. And when this happens, the EA practice may be active but structurally distant from outcomes.

Why This Happens in Practice

Architecture theater is rarely intentional. It often emerges from everyday, reasonable choices. Deliverables are easier to count than better decisions. Reviews are easier to schedule than meaningful influence. Framework compliance is easier to demonstrate than reduced complexity. Visible activity is easier to manage than impact.

All on all, it is often easier to produce something concrete than to influence decisions, which is more abstract and situational.

At the same time, the EA practice is not always positioned where decisions are actually made. It may sit slightly outside planning and delivery. Architects may be involved, but not always at the moments that matter most.

There are also practical constraints. Time is limited, priorities compete, and not every situation gets the attention it would ideally need. In such conditions, it is natural to focus on what is visible, structured, and expected.

Over time, these patterns reinforce each other. Organizations reward activity that can be seen and reported. EA practices adapt to those expectations.

The result can be a function that looks mature on paper, but has limited effect on how the organization actually changes.

Where Architecture Actually Creates Value

A useful way to evaluate an EA practice is to focus on where it changes something. Not where it produces artifacts. Not where it creates meetings. Not where it satisfies a method.

But where it leads to better choices, reduced complexity, or more consistent outcomes.

A few simple questions can help make this visible:

What is the intended purpose of this architecture work?
When was this architecture work last used?
Where does architecture actually change decisions?
In which situations would the outcome be different without it?
Which stakeholders actively use architecture in their work?
Where does architecture help avoid rework, duplication, or unnecessary complexity?

If these questions are difficult to answer, it may be a sign that the connection between activity and impact is weak.

Closing Thought

EA practices do not create value simply by existing. They create value when they improve how the organization plans, decides, and delivers change.

Architecture theater emerges when the form of architecture remains, but the connection to outcomes weakens.

The goal is not to remove structure, governance, or deliverables. The goal is to ensure that they are used in situations where they actually influence what happens next.

Because architecture work only becomes valuable when it changes how the organization acts.

🔗 You May Also Like

Looking to dive deeper? Here are more enterprise architecture insights you might find useful:

👨‍💻 About the Author

Eetu Niemi is an enterprise architect, consultant, and author.

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.