Why ROI Is the Wrong First Question in Enterprise Architecture

Link: https://www.eatransformation.com/p/why-roi-is-the-wrong-first-question-in-enterprise-architecture

From Enterprise Architecture Transformation: A Practical Guide

In my previous article, I touched on enterprise architecture (EA) benefit realization at a fairly high level. The related LinkedIn post ended up reaching more people than any of my earlier EA-related writing on the platform, and it also brought in a noticeable number of new readers. That was a pleasant surprise.

So, before going any further, a quick thank you is in order: to those who commented thoughtfully, to long-time readers, and to everyone new who decided to subscribe along the way.

More importantly, it sparked discussion. And whenever a piece actually does that, a familiar pattern tends to repeat itself. Almost without exception, there is someone who steps in and demands either hard ROI numbers or declares that EA “does not work”—quickly and loudly.

What makes this interesting is not the question itself. Asking for return on investment is perfectly reasonable. What is more revealing is that the demand is often presented in one of the two forms: either ROI is demanded as a number detached from any value creation mechanism, or it is conveniently bundled with a software tool that claims to produce it automatically. In both cases, ROI becomes a rhetorical endpoint or a marketing pitch—not the start of a serious conversation about value creation.

I ran into exactly this reaction after my previous post. Most of the comments were thoughtful and engaged with the topic in different ways. One commenter, however, stood out. I have encountered it before, but rarely in such a confrontational form. Much of what they contributed added little to the substance of the discussion. Once the rhetoric was stripped away, the only coherent point that remained was a familiar one: a demand for ROI.

That response is not unusual. And that is precisely why this article exists.

The problem is not ROI, but skipping straight to it while bypassing the layer where EA value actually begins to form. Without immediate, direct benefits in place, any ROI discussion is simply disconnected from reality. EA sits alongside other management support functions—such as strategic planning, portfolio management, and risk management—that rarely produce isolated ROI, but consistently shape better decisions over time.

How Do Direct Benefits Actually Form?

Direct benefits are the ones that appear immediately, in real situations, when architecture is actually used.

They form in everyday work: projects starting, decisions being prepared, discussions getting stuck. In those moments, architecture either helps people think more clearly together—or not. There is no hidden pipeline where value magically accumulates.

The three mechanisms below are tightly connected, but distinct. Together, they explain why some EA efforts produce immediate value while others remain inert.

Clarity Is the First Real Outcome

Before anything else happens, architecture work either clarifies things or it fails. There is no neutral outcome. If describing an organization, an ecosystem, or a change effort results in more confusion, no downstream benefits should be expected later.

Clarity emerges when a structure is made explicit. A picture, a map, or a simple model forces fuzzy ideas into a shared form. It does not need to be exhaustive or elegant. What matters is that it introduces a visible structure of something: an application landscape, a capability set, a process, a dependency chain. Once that structure exists, people are no longer relying solely on their own internal interpretations.

This is also where thinking itself starts to change. When you try to explain a structure by pointing at it, gaps become obvious. Contradictions surface. Assumptions that felt solid suddenly look shaky. That friction is not a side effect—it is the mechanism through which clearer thinking is produced.

Simple example:

A digitalization project is about to start. The project manager, a couple of business leaders, and IT representatives are in the room. Someone asks a seemingly simple question: what exactly are we changing?

Everyone has an answer—but they are not the same answer.

Instead of debating the answers in the abstract, the group starts by working together on a first approximation of the scope. A single architecture view provides a shared starting point. It is assembled from elements that already exist in EA: the relevant processes, the applications that support them, the key data involved, and the most important integrations.

This is not about getting it right on the first attempt. It is about making an initial version of the scope visible. What is included, what is not, and where the boundaries roughly sit can now be discussed explicitly. Instead of starting from a blank slide, the conversation anchors itself to a shared structure that has already been named and thought through.

This is usually the moment when assumptions surface. Someone realizes that a system they considered “central” is actually peripheral. Another notices a dependency they were not aware of. The structure does not provide answers, but it gives the discussion a shape and a direction.

Knowing What We Are Actually Talking About

One of the most underestimated benefits of shared visuals is how effectively they reduce misunderstanding.

Without a common reference, conversations depend on language alone. And language is ambiguous by nature. “That application,” “customer data,” or “the core process” can mean completely different things to different people, even when everyone believes they are aligned. Misunderstandings stay hidden until decisions start producing unexpected results.

Simple example:

An organization wants to develop a specific business line. The intention is clear enough, but once the discussion starts, it becomes obvious that people mean different things by it.

For one person, development means improving customer service processes. For another, it is mainly about sales support. Someone else sees it as a data and reporting problem. IT focuses on the aging CRM system. The discussion keeps circling, not because people disagree, but because they are not talking about the same thing.

At this point, a capability map often helps more than further debate. By laying out the relevant business capabilities and naming them explicitly, the group can start by identifying which capabilities are actually in scope, and which are not.

Instead of arguing about solutions, the discussion shifts to structure. Are we talking about customer relationship management, billing, onboarding, or after-sales support? Once the capabilities are visible and named, it becomes easier to say: this is what we are focusing on now.

Disagreements do not disappear, but they become concrete. The group may still argue about priorities, but at least they are arguing about the same capabilities. At that point, architecture has already delivered a direct benefit: people know what they are actually trying to develop, and what they are not.

Dependencies and Impacts Become Visible

This is the point where architecture moves from shared understanding to decision support.

When they are visible, dependencies stop being an abstract idea and become something concrete. It becomes much easier to see what depends on what. Changes are no longer isolated decisions. A small adjustment in one place suddenly has a visible ripple effect elsewhere—across applications, processes, teams, or timelines.

Simple example:

A project is scoped as “just a small change” to one application. Once the architecture view is on the table, it becomes obvious that the application is tightly coupled to two others, relies on shared master data, and exposes interfaces used by external partners.

This is where many of the “surprises” in projects actually come from. Not from technical complexity, but from hidden dependencies that no one had articulated before.

Once dependencies are explicit, impacts can be discussed more honestly. What really changes if we choose option A over option B? What breaks if we delay this? What risks are we implicitly accepting?

Architecture does not answer these questions for you. But it makes it much harder to ignore them.

Why Direct Benefits Don’t Appear on Their Own

This is the point where many organizations get disappointed. Direct benefits do not appear simply because architecture descriptions exist. They do not emerge automatically from an architect’s advice. They certainly do not come from buying a tool. And they do not follow just from the fact that an organization has an “EA practice” or a formally named architecture function. All of these may be necessary conditions—but none of them are sufficient.

Benefits only start to appear when architecture content is actively used in real conversations, real planning, and real decision situations. When people engage with the structures, challenge them, refine them, and use them as a shared reference. Without that, architecture content remains inert, no matter how correct or complete it is. This is why it is more useful to talk about benefit mechanisms than benefits themselves.

In practice, a few very concrete conditions need to be in place.

Relevant architecture content has to be available and reasonably up to date. If people cannot find it, or if they do not trust it, it will not be used—regardless of how well it was originally produced.

Relevance also depends on the situation. Sometimes what is needed is a clear view of the current state. In other cases, a rough but shared picture of the target state is far more useful. In both cases, the content has to be understandable to its intended users. If a model only makes sense to the person who created it, it will not clarify anything for others. Architecture that requires constant translation fails at its primary task.

The structure must also be relevant to a real question or problem. Generic completeness rarely helps. Purpose does. Architecture works best when it is pulled into a discussion because someone needs it, not pushed in because it exists.

In addition, architecture models need to tell something that was not already visible in one place. The value often comes from bringing previously separate pieces together into a single, coherent structure. That synthesis—making relationships, overlaps, or gaps explicit—is often more important than any individual detail.

Finally, there must be a situation where people are forced to look at the structure together. Planning, prioritization, scoping, and risk discussions are typical examples. Clarity does not emerge in isolation. It emerges in interaction.

This is also why direct benefits rarely come from diagrams alone. Architecture descriptions do not use themselves. In practice, it usually requires the architect to step in: to bring the right people together, select the relevant views, and help interpret them in the context of the situation at hand. Sometimes this means jointly producing an initial description. Other times it is simply walking through existing views and testing whether they still hold.

In both cases, the value comes from shared use, not from the artifact itself. When business and IT experts work through the structures together, the architect helps keep the discussion grounded: what is actually in scope, what is not, where assumptions are being made—and what is being decided. Just as importantly, those decisions get captured in a form that can be revisited later.

This does not require a formal workshop. It can be a project kickoff, a steering group discussion, or a short working session. What matters is that someone actively enables the use of the descriptions and provides interpretation when needed.

When these conditions are met, conversations change. General statements give way to more concrete questions: what depends on what, what actually changes, and which decisions can no longer be postponed.

So Where Do the Real Benefits Come From?

The longer-term benefits people usually ask for do exist. Better decisions. Fewer surprises. Projects that start faster because basic dependencies are already understood. In some cases, even new business opportunities. Over time, these effects accumulate and begin to show up on the bottom line. For example, as cost savings in the IT portfolio, through fewer overlapping solutions, less rework, and a more coherent set of technologies to maintain.

But none of that happens without the immediate benefits first.

Before any cost reduction, productivity gain, or innovation can be credibly attributed to EA, something much more basic has to work. People have to think more clearly together. They have to share an understanding of what they are discussing. Misunderstandings have to decrease. Conversations have to become sharper and more concrete.

These are the direct benefits. They appear early, in meetings, planning sessions, and decision situations. They are not glamorous, and they rarely come with a price tag attached. But they are still the foundation for everything that follows.

Only once these direct benefits are consistently present does it make sense to talk about indirect benefits over time. Avoided mistakes. Projects that were never launched. Investments that did not drift off course. Occasionally, opportunities that become visible precisely because the structure made them easier to see.

These outcomes are harder to trace back to architecture, and they resist traditional cause–effect measurement. Still, they are not accidental. They are built on the same mechanisms, repeated over time. Without the initial clarity, they simply do not materialize.

Put bluntly: EA does not create value by existing, by being formalized, or by being well tooled. It creates value when it makes thinking visible and shared—early enough that decisions can still change.

Measuring What Actually Matters (and Inviting the Right Debate)

This also explains why EA benefits are difficult to measure in the traditional sense. You cannot reliably isolate them the way you would measure the ROI of a single investment, such as a factory, a machine, or a specific IT system. The effects are indirect, cumulative, and deeply intertwined with decision-making across the organization. Outcomes emerge from many interacting factors rather than a single cause.

That does not mean nothing can be measured. Direct benefits are often visible if you know where to look. Are discussions shorter or more focused? Do projects spend less time rediscovering the same dependencies? Are key questions raised earlier than before? Do decision-makers agree more often on what is actually being decided? If you cannot see these signals at all, the problem is rarely measurement—it is that architecture is not yet being used where it matters.

Often, the most honest picture comes from simply asking the people who actually use architecture in their work. Project managers, product owners, and decision-makers tend to notice very quickly whether architecture helps or gets in the way.

These signals are imperfect, but they are real. And they are far more honest indicators of architectural value than forcing everything into a spreadsheet that was never designed for this kind of use.

For the owner of the EA practice, this means accepting a different kind of accountability. You will not get instant ROI. What you get first is signal: clearer discussions, fewer surprises, and earlier visibility into risks. Managing EA is largely about recognizing and protecting these early signals long enough for the longer-term effects to accumulate.

I have unpacked the longer-term benefit mechanisms in more detail elsewhere, including in my PhD research, my EA book, and in an earlier article. This piece deliberately stays closer to the ground. If the immediate benefits do not appear, the long-term ones are largely theoretical.

Finally, a note on discussion. Debate about EA is both necessary and welcome. Strong disagreement is fine. What matters is that the debate stays focused on the substance—mechanisms, assumptions, and outcomes—not on people. If nothing else, architecture should help us have better arguments.

🔗 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.

📬 Want More Practical Enterprise Architecture Content?

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