Why Enterprise Architecture ROI Is Hard to Prove and How to Make EA Valuable Again

When imagination meets reality, life often outperforms fiction. A large company recently asked me to prove the ROI of re‑implementing Enterprise Architecture (EA) functions.

The company had previously hired architects but eliminated them when they chose a large ERP system as the backbone of their operational information system (IS). Since the IS is organized around ERP functions, the need for an EA architect seemed unclear, and the EA role was often mistaken for an ERP editor.

No EA architect means the company defaults to a basic EA. In this case, the default EA is driven by ERP editor policies and works as long as the company’s strategy focuses on excellent commodity service implementation, cost reduction, and operational productivity, with only a few isolated business innovations managed outside ERP.

The company recently completed a business and IT review that identified ERP as a bottleneck for deploying new business lines and required IT drivers. Consequently, they decided to overturn ERP in many IS strategic areas, but they now lack an EA architect. Project owners continue to create ad‑hoc architectures for their own needs and resist change, so the EA ROI request aims to secure high‑level sponsorship to overcome operational resistance.

My answer was not “Are you kidding?” but it felt that way, and I lost the deal.

Risks

Think bigger, fail fast. I tried several unsuccessful ideas.

The first argument: Today, information systems are the core of every business strategy implementation. Without someone driving IS architecture, strategic success is hard to imagine, yet claiming EA’s value is difficult because the current situation appears to work fine.

The second argument: Benefits from the ERP editor’s own EA are diminishing as ERP usage shifts to non‑strategic commodity services, forcing ERP architects to be replaced by company architects, but project owners resist architectural oversight.

The third argument: I tried to discuss EA value with C‑level executives, believing they understand and would support re‑introducing EA, but received no response.

Then the danger arrives: why bring EA back? It is not a joke; the company truly needs EA.

How the Idea That EA Is Too Expensive Originated

The more abstract a concept, the harder it is to link exclusive benefits to it. Consequently, quantifying EA’s ROI is difficult. While we can roughly estimate the ROI of new business strategy deployment, isolating EA’s contribution is challenging, even with a well‑managed EA approach.

Cost calculation is straightforward: the main expense is labor – architecture work, composition, governance, support, and dissemination – plus tool costs and indirect costs such as delayed time‑to‑market.

Even with a default EA, these costs exist. Without deliberate architectural decisions, no one can build an information system. The question is whether we want to organize decisions in a managed way or let individuals decide at each point, and whether we want to consider decisions made elsewhere.

Misunderstandings About EA

The biggest mistake is assuming architects must do all the architectural work. Architects are the only ones who can use architectural artifacts to tell the “truth” because architecture is complex.

This situation is called “Ivory Tower Syndrome.” Architects produce artifacts solely for themselves, generating transformation impact analyses that represent 20% of the total cost but 80% of the value, requiring expensive tools and constant alignment with reality.

The remaining 80% of the cost is often produced by others or not produced at all, depending on stakeholders’ view of architectural issues. When core architectural descriptions are made without an architect, related decisions are still made.

We do not want to return to that bottomless‑well cost source, which is a major reason for distrust in EA.

How to Make EA Great Again?

Let’s try to achieve 80% of EA benefits with only 20% of the “big‑picture” EA cost.

The idea is to regain strategic/organizational control over architectural decisions and avoid letting those decisions be made at local sub‑levels or global meta‑levels.

We illustrate this idea using the 5W2H method before any major strategic transformation:

What? What changes are we making to the IS organization (architecture)?

Why? Why are we changing the IS architecture?

Where? Which part of the IS will be affected?

When? Is there a roadmap?

Who? Which organizational units will implement the changes?

How? Are there IT drivers that can facilitate easier changes?

How much? What are the costs related to reducing architectural debt and setting up new IT functions?

This resembles Phase A (Architecture Vision) of the TOGAF Architecture Development Method, but we focus on architecture as part of the overall transformation rather than architecture of architecture.

The goal is to share the architecture vision just as we share business, product, and organizational visions, making EA the glue between business needs, operational SI products, and people/resources to achieve the next strategic goal.