What Is Enterprise Architecture—and Where Should It Stop?

Link: https://www.eatransformation.com/p/what-is-enterprise-architecture-and-where-should-it-stop

From Enterprise Architecture Transformation: A Practical Guide

The holiday was rather relaxed: some cottage time in the Nordics, some quiet days at home, and not too many plans or goals. Still, I ended up writing surprisingly much. Both a novel and a nonfiction book are now in the making.

Apparently, the sensible way to return to enterprise architecture (EA) is to ask one of its least simple questions:

What is EA, actually?

The question keeps coming up in articles, frameworks, client discussions, and architecture communities. I also see it regularly in the comments on my LinkedIn posts. There is no shortage of definitions for EA. The problem is that people understand it in different ways, and you can often deduce what they mean only from the rest of the discussion.

However, many of these disagreements are not really about EA itself. They are about its scope. People use the same term for different things and then wonder why the discussion goes nowhere.

The problem begins with the word architecture.

When we talk about a building, architecture usually means the structure and design of the building. It is related to architects, drawings, methods, reviews, and construction, but they are not all called architecture.

With EA, we are less disciplined. The term may refer to the actual structure of the organization, descriptions of that structure, the discipline of designing and maintaining it, the organizational function responsible for the work, or the profession.

In my own books and publications, I have focused mainly on the latter four. Ross, Weill, and Robertson take a broader view in Enterprise Architecture as Strategy, which I am currently rereading, and discuss the actual architecture of the enterprise. That also explains why almost anything can be linked to EA online: if EA means the structure of the whole organization, the umbrella becomes rather large.

The meanings are connected. But they are still different, and separating them is useful before deciding what EA should cover.

Five Meanings of Enterprise Architecture

First, an organization has an architecture regardless of whether anyone has formally modeled it or not. Its capabilities, processes, information, applications, technologies, products, services, and business units exist in specific arrangements and depend upon one another. Some parts of this structure have been deliberately designed. A significant portion, however, has accumulated over time through projects, acquisitions, reorganizations, and temporary workarounds that have persisted despite best efforts.

Second, EA represents a professional discipline. It establishes and utilizes a structured understanding of the organization to guide planning, decisions, and change. This systematic view helps determine what to modify, standardize, retire, or invest in—and clarifies what other areas may be impacted by those decisions.

Third, EA refers to a set of descriptions and models. These documents illustrate the primary structures and relationships at a logical, organization-wide level. They are concrete enough to inform strategic decisions, yet they avoid the high level of detail required to document individual process steps, database fields, or server configurations.

Fourth, EA functions as an organizational practice. Enterprise architects maintain shared viewpoints, support project and portfolio decisions, facilitate collaborative planning, identify critical dependencies, and prevent different business units from solving identical problems in mutually incompatible ways.

Fifth, EA is a distinct profession. Enterprise architects require an uncommon combination of modeling skills, facilitation, analytical thinking, communication, and organizational dynamics. While the job title may not be so rare, the core work is typically conducted by a relatively small group of specialists.

All five interpretations are valid. Difficulties arise only when people discuss them as if they represented the exact same concept.

The actual architecture of an organization can encompass virtually everything. The only limit is your definition of what architecture or structure means in this context. However, the discipline, the documentation, the organizational function, and the profession should have boundaries. No organization has access to unlimited architects, time, funding, or patience—even though certain organizations and practitioners occasionally conduct themselves as if there is no such limits.

Enterprise Architecture Needs Boundaries

EA should cover the structures and dependencies needed to manage organization-wide change on a high level. Broad, yes. Everything, no.

The boundary has two parts: what the EA function does and what EA descriptions include. Without this distinction, EA tends to expand until nobody can maintain it—or explain why it exists in the first place.

Scope of the Enterprise Architecture Function

The EA function connects strategy, business development, portfolio management, projects, IT, data, security, and operations. The work is not mainly about producing descriptions. Architects support planning, facilitate discussions, bring the right people together, structure difficult questions, and help decision-makers understand the wider effects of their choices.

In practice, this may mean facilitating target-state planning, supporting project preparation, clarifying scope and dependencies, comparing solution options, or helping a management team turn a rather general strategic objective into something that can actually be implemented. Good architects often spend as much time asking questions, challenging assumptions, and building shared understanding as they spend modeling.

The EA function does not replace other functions. Strategy teams formulate strategy, process owners develop processes, solution architects design solutions, and engineers implement them. EA supports their work by providing context, shared principles, architectural knowledge, and a neutral view across organizational boundaries. In other words, enterprise architects may guide and connect activities across the TOGAF ADM cycle, but they are not responsible for performing all the work that the cycle touches.

The function should focus on areas where an organization-wide view and architectural support add value: major investments, cross-functional changes, shared information and platforms, lifecycle questions, and decisions with long-term consequences. Its role is to provide the basis, bring people around the same table, and help them choose a sensible route—not to control everything.

Scope of Enterprise Architecture Descriptions

EA descriptions show the main structures and relationships needed for planning and decisions. Typical content includes capabilities, processes, information, applications, technologies, initiatives, and the connections between them.

The descriptions should be coarse but concrete. Detailed workflows, solution designs, data models, technical specifications, security controls, and operating instructions belong mainly to their respective disciplines. EA may connect to them without copying everything into one heroic repository.

Descriptions can also become too abstract. A diagram filled with Digital Business, Customer Centricity, and Future Capabilities may look impressive, but it gives little guidance for what should change.

The useful level sits between these extremes: enough detail for analysis, but simple enough to understand and maintain. The goal is not more diagrams. It is consistent information that can be reused in real decisions. Coarse but concrete.

Dependencies Are the Main Point

A list of applications is useful, as are process and capability maps. But EA brings most value when two things come together: an enterprise-level view and the relationships between the parts. Which capabilities depend on which applications? Where does important information move? Which technologies support critical services? Which initiatives affect the same parts of the organization? And where does a sensible local decision create cost or complexity somewhere else?

I have seen this many times, most recently in an organizational renewal project where architecture work brought together people from different functions and roles. The challenge was not to design the organizational structure. That was the easy part. We rather needed to agree on how the different roles and business units would work together in practice. By structuring the discussions and making the connections visible, we helped the group define a shared target state and a common operating model.

That is easy to underestimate. Without a common view, each function tends to design its own part—usually quite sensibly—while the gaps between the parts remain for someone else to solve.

Few other disciplines or functions look at both the whole organization and the dependencies across it. Process management usually focuses on processes, portfolio management on initiatives, and IT management on IT services. Each sees an important part of the picture. EA connects the parts and keeps the enterprise-level view.

This combination is one of the most specific contributions of EA, especially where no single owner has responsibility for the whole chain. Without it, the connections often remain in separate systems, documents, or in the heads of a few experienced people who somehow seem to know everything.

Enterprise Architecture Between Strategy, Operations, Development, and Technology

EA forms a cohesive layer between strategy, operations, development, and technology. It is an artifact that can build shared understanding between diverse stakeholders. If you want to sound fancy, you could even call it a boundary object.

At its best, it translates strategic objectives into implications for capabilities, processes, information, applications, and technologies. It gives portfolio management a common view of initiatives, provides solution architecture with context and principles, and helps operations understand the sources of cost, complexity, risk, and technical debt.

This connecting role is where EA earns its keep. It makes information from different functions understandable as one whole.

But EA still needs to remain selective. A model understood only by architects has failed in a very professional-looking way. The aim is not to remove organizational complexity, but to make it visible and useful in decisions.

So What Is Enterprise Architecture?

In practical terms, EA is a discipline, a logical-level description layer, an organizational practice, and a specialized profession.

It is selective rather than comprehensive. It does not include every architecture-related activity or the most detailed version of every description. And despite some determined attempts, it is not a universal architecture repository.

Its value comes from showing how things fit together, what depends on what, and what a planned change is likely to affect. That requires deliberate boundaries: what the EA function does, what its descriptions cover, what belongs elsewhere, and where the organization-wide view adds value.

Clear boundaries do not weaken EA. They make it usable.

📰 A Small Publishing Update for This Substack

I am changing from weekly posts to one about every two weeks.

No, I am not running out of ideas for EA posts. It is simply because these topics usually need a bit more time. I hope the new publishing rhythm will be better for both the quality of posts and the sustainability of this newsletter.

So, there will be fewer posts, but hopefully they will be a bit more thought through.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related 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 strategy, change, and delivery.