Enterprise Architecture Has an Identity Problem

Why enterprise architecture means different things in different organizations—and why clarifying its purpose is essential for demonstrating its value.

Mar 17, 2026

In the early 2000s, enterprise architecture (EA) was everywhere.

At the time, I was working in a university research project related to EA. A steady stream of material seemed to appear from all directions: research papers, consulting frameworks, government guidelines, and industry white papers. Especially in the United States, the public sector was producing large amounts of architecture-related material.

Around the same time, several frameworks and approaches gained wider attention. TOGAF was evolving into its modern form, and legislation such as the Clinger–Cohen Act had already pushed federal agencies to adopt architecture practices.

There was a fair amount of hype around the topic, as often happens when a new management idea gains momentum. But it also felt like EA was becoming a major new discipline for managing organizational complexity.

Twenty years later, the situation looks somewhat different. EA certainly still exists, and if anything, there are more frameworks, tools, and opinions about EA than ever before. But if you ask ten organizations what EA actually is, you may receive ten very different answers.

In some organizations, EA is a strategic function working closely with leadership. In others, it primarily plays a governance role, reviewing project designs and enforcing architectural principles. In many organizations, however, architecture ends up closer to everyday project work, with architects supporting development teams and helping resolve practical design issues. All of these interpretations—and more—exist in practice.

This variety is not necessarily a problem. Organizations are different, and architecture work naturally adapts to local needs. But the situation does raise a slightly uncomfortable question:

If EA means something different in almost every organization, what exactly is the discipline supposed to be—and how do you explain its purpose and value to leadership?

Different Faces of Enterprise Architecture

Part of the confusion is that EA is understood in many ways: as a set of architecture models, a process, an organizational function, a role, “everything in an organization”—or sometimes all of these at once. This also becomes visible in practice in how EA is used and where architects spend their time.

Over the years I have seen EA work take several different forms.

In some organizations, it is connected to strategy. Architects help translate strategic goals into concrete development directions. Capability maps, roadmaps, and high-level architecture views are used to guide long-term change.

In others, EA’s role is much more operational. Architects review project designs, participate in steering groups, and provide architectural guidance to development initiatives. They help projects navigate dependencies between applications, ensure that solutions follow agreed architectural principles, and sometimes contribute directly to solution planning.

Sometimes EA revolves around maintaining architecture descriptions. The focus is on building and updating models that describe the current state of processes, data, applications, and technology. These descriptions aim to create a shared understanding of the organization’s structure.

EA can also take a more formal governance role. Architects review solution designs, approve or challenge architectural decisions, and ensure that development follows agreed principles and standards. When this works well, it helps maintain coherence across projects. When it does not, architecture reviews may be perceived as little more than an additional bureaucratic step slowing down delivery.

And occasionally, the architecture role becomes something closer to internal consulting. Architects spend much of their time facilitating workshops, challenging assumptions, and helping teams think through complex problems.

In practice, much of the architecture work I have seen tends to fall into the operational end of the spectrum. Direct involvement in strategic decision-making appears somewhat less common, even though strategy is often mentioned as a central goal of EA.

None of these roles is inherently wrong. The problem arises when the expectations surrounding EA remain unclear.

When Expectations Are Misaligned

If stakeholders expect different things from EA, the work can quickly become confusing.

Leadership might expect strategic guidance. Project teams might expect practical design support. Architects themselves might believe their primary task is to maintain architecture models. Each of these expectations is reasonable on its own. But if they are not aligned, the architecture function may end up trying to do everything at once—and satisfying nobody particularly well.

This is one reason why EA sometimes struggles to demonstrate its value. The function is judged against multiple, partly conflicting expectations. Is EA supposed to guide strategy, support projects, maintain models, or all of the above?

In practice, this confusion is surprisingly common. EA often grows gradually rather than through a clearly defined mandate. New responsibilities are added over time, different stakeholders form their own assumptions, and eventually the architecture function finds itself operating without a shared understanding of what it is actually supposed to achieve.

Part of the explanation is simply how EA’s role evolves in practice. The work often ends up reflecting where architects are invited to participate and with whom they are able to collaborate. If architects are mostly involved in projects, the role naturally becomes project support. Strategic involvement, on the other hand, usually requires access to leadership discussions—something that does not automatically happen in every organization.

Without clarity on expectations and purpose, architecture work can easily drift. Architects may spend time on activities that feel useful but are not aligned with what the organization actually expects from them. Stakeholders may assume that the EA function is responsible for tasks it was never meant to handle.

Clarifying the Role of Enterprise Architecture

One useful starting point is simply to ask the stakeholders. Architecture leaders or external facilitators can interview key groups across the organization: executives, project managers, development teams, and other functions interacting with architecture.

Several simple questions often reveal a great deal. For example: What do you think EA means in this organization? What do you expect from it? And also: How do you actually interact with architects or architecture content today? Do people meet architects in projects, steering groups, or strategic discussions? Do they use architecture models at all? It is also useful to ask a more direct question: What do you feel you are currently getting from EA? The differences between these answers can be very revealing.

Once these expectations are visible, the organization can have a more explicit discussion about what EA should actually mean in that particular context. There is no universal answer. In some organizations, EA may primarily support strategy. In others, it may focus on guiding projects, maintaining shared current state views, or improving coordination between development initiatives.

What matters is that the organization defines it consciously—based on what EA is actually expected to do in practice, not only on what EA frameworks say it could provide in theory.

A clear identity does not mean that EA must only perform one role. In practice, EA often combines several responsibilities. But there should still be a shared understanding of its primary purpose: why the function exists, what problems it is expected to solve, and what kind of value it aims to deliver.

Once this purpose is reasonably clear, it becomes much easier to define the practical operating model that supports it—how architects work, where they participate in decision-making, what kind of architecture content is maintained, and how architecture interacts with projects and leadership.

Clarifying the identity of EA will not solve every challenge. But it provides something that many architecture initiatives initially lack: a shared understanding of what the discipline is actually trying to achieve in that organization.

A Simple Question

If EA in your organization disappeared tomorrow, what exactly would be missing?

Would leadership lose an important strategic perspective?
Would projects struggle without architectural guidance?
Or would the architecture repository simply stop being updated?

The answer says something important about what EA actually is in your organization, and whether its identity is clear enough for others to understand its value.

In a way, the question of EA’s identity has been present throughout the discipline’s history. My own recent book Enterprise Architecture: Your Guide to Organizational Transformation is one attempt to describe what EA could be when it works well in practice: how it connects strategy, development, and decision-making through a small set of shared architectural views.

Whether organizations adopt that kind of approach or something entirely different, one thing seems clear: without a reasonably shared understanding of what EA is supposed to achieve, it becomes very difficult for the function to demonstrate its value—or to design the operating model that allows it to deliver that value in practice.