What Is Enterprise Architecture (EA)? Definition, Principles & How to Start

We often hear “Enterprises aren’t like physical items. They don’t need the level of specificity of buildings or airplanes or ocean liners, right?”

In two words: why not? We don’t know why people believe this.

We believe that enterprises are actually much more complex than any of these physical items. If you are building a rowboat, you probably do not need much architecture. If you are building an ocean liner, you need extensive architecture, and at great detail. If you are building a model airplane, you probably do not need much architecture. If you are building a Boeing 747 that flies over water at night (with us in it!), you need extensive architecture. Compare, too, a log cabin to a one-hundred-story building. Ask the people who completed the Trump International Hotel and Tower in Chicago how much time they spent on architecture and how much they spent on implementation. You might be surprised. But we don’t think you will be surprised at the level of detail in the buildings’ architecture.

If you are building a worldwide enterprise that has thousands of employees and is undergoing constant change, you need extensive architecture. Architecture is the baseline for managing complexity and change.

Without it, what will you use to address complexity and change, and what are you going to do to avoid unintended consequences (that is, you had no details in your architecture)? Architecture is about planning, analyzing, designing, and constructing, and is the explicit baseline for addressing and managing change.

We wish enterprises would stop using the life cycle: constructing, maintaining, maintaining, maintaining. What is your approach to managing complexity and change if it isn’t EACOE Enterprise Architecture?

We aren’t saying that you have to do everything at once. Enterprise Architecture is a continuous process with greater granularity of its artifacts over time as the enterprise changes and as more of the enterprise is mechanized or automated. Architecture occurs prior to making a change. Documentation occurs after the change is made. This is the only logical, practical, and cost-effective way to proceed. The objective of EACOE Enterprise Architecture is to continually reduce the risk of unintended consequences and inappropriate changes.

It is not a question of mutual exclusivity (one or the other). Enterprise Architecture is about both the enterprise (business understanding) and the technology enablement (IT) of the enterprise.

The definition of Enterprise Architecture above shows this. By the way, “technology” can mean something as simple as a pencil and paper.

We’re not really sure what the phrase “enterprise information technology architecture” means.

If it means the current layout and inventory of technology assets, then it should be called technology assets and logistics layout. If it means the connectedness of various technology assets, it can be called the technology blueprint.

Architecture and implementation are different. The definition of Enterprise Architecture is about understanding the business intent and the technology to achieve it.

Setting up an IT enterprise architecture out of context from the Enterprise Architecture is not advisable.

The Enterprise Architecture Center Of Excellence (EACOE) Quick Start Enterprise Architecture Methodology provides a step-by-step approach to Enterprise Architecture, ensuring the organization meets the strategic goals and objectives established by management.

The Methodology enables organizations to use Enterprise Architecture as a decision-making tool for business strategy, information technology development and alignment, risk management and analysis, and project and program prioritization.

The EACOE Methodology includes explicit, detailed guidance that is required to develop and understand the organization’s architecture from both a business and technology perspective, to create the target architecture, and to define the business transformations that are required to meet the organization’s goals.

To address issues with resultant quality, involvement, and acceptance, the EACOE Methodology makes certain that the correct stakeholders are participating at the right times.

The EACOE Methodology can be applied to the entire enterprise, a business unit, a department, a function, or a strategic project. The broader the scope of the Enterprise Architecture project, the more likely the organization is to reap the benefits of Enterprise Architecture: integration, reuse, agility, and cost savings.

The Methodology can be used in all of its robustness, or it can be treated as a set of tools. If an organization chooses not to represent the whole enterprise, it needs to make informed decisions about which parts of the organization it is initially going to focus on. It also needs to understand why it is focusing on those organization units, and the impact of not focusing on the other units.

Many mistakenly believe that the Enterprise Architect does everything in the field of Architecting the Enterprise. But doctors do not do everything in the medical profession, electrical engineers do not do everything in the engineering profession, and so on.

The EACOE defined twelve mutually exclusive Architectures and Modeling Roles (The Architectures and Architect Roles In an Enterprise), providing clear and complete role responsibilities. There are no loose ends or unassigned gray areas to be overlooked or to be a source of concern in an Architecture practice.

The different architectures and roles are:

• Enterprise Architecture,

• Business Architecture,

• Process Architecture,

• Data Architecture,

• Policy/Rule Architecture,

• Role Architecture,

• Logistic Architecture,

• Event/Sequence Architecture,

• Rule Assertion Architecture,

• Workflow Architecture,

• Technology Architecture,

• and Event State Architecture.

Of course, to deploy all of these roles efficiently and effectively, they must be governed by a clear frame of reference – an Enterprise Framework.

A framework is a structure that organizes a set of related artifacts.*

The framework shows the relationships of the artifacts of the chosen subject area and brings a totality perspective to otherwise individual ideas.

A framework, therefore, makes the unorganized organized and coherent, and it is fundamental to any profession or discipline (engineering, chemistry, physics, language, music— anything). Framework elements must be mutually exclusive and collectively exhaustive.

A framework that is in constant update and versioning is troubling. If it is, it is not (or was not) complete.

If we were using Version 4 of the framework and we now have Version 9, what does that say about the work we did with Version 4? Can you imagine the English alphabet starting off with fifteen letters (Version 1), then going to twenty-one (Version 2), and then twenty-six (version 3), with more proposed versions yet to come? How useful would that be?

Can you imagine the periodic table of chemical elements having multiple versions? Chemistry would be like alchemy. Can you imagine the system of musical notes to be in continuous versioning? (What would the orchestra sound like if each set of musicians had their own “framework”?)

A framework is fundamental to Enterprise Architecture. The Enterprise Framework™ and the framework defined by John Zachman (Zachman Framework) meet the criteria for an Enterprise Framework.

No. A framework is not a methodology, and a methodology is not a framework.

A framework can possibly accommodate many methodologies, but we have not seen a methodology work across multiple frameworks (at least not in the physical world). We can’t see how it could be different in the Enterprise Architecture world.

A methodology is a set of practices and procedures applied to a specific branch of knowledge. A methodology contains proven processes to follow in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration. An outstanding methodology guides, simplifies, and standardizes the process; it can be customized to meet an organization’s specific standards and practices. An outstanding methodology is correct, up to date, complete, and concise; it defines deliverables; it has methods, techniques, standards, practices, roles and responsibilities; it has suggested timings and sequences and dependencies; and it has associated education.

Guidelines are not methodologies either. A guideline might tell you what operations you can do or provide suggestions on deliverables. Methodologies should provide a predefined path or paths.

A methodology should allow you to do something “Monday morning” you shouldn’t have to figure out how to take a guideline and turn it into a path. The Enterprise Architecture Center Of Excellence (EACOE) Quick Start Methodology meets the criteria for an Enterprise Architecture Methodology.

Enterprise Architecture requires a blend of abilities across management, business, modeling, technology, and human domains, including project and program management to plan and coordinate architecture work; deep understanding of the specific business, its strategies, drivers, and priorities; skill in creating human‑consumable models and reports that faithfully represent business requirements and architectures; emotional intelligence to communicate with and influence business and technology leaders; systems thinking to view the enterprise as an integrated system and maintain consistency and integration across models; knowledge of IT governance, strong business and architecture modeling skills to produce enterprise and implementation models, along with prioritized, enterprise‑aligned projects and capabilities; financial modeling abilities to connect architecture choices to costs, benefits, and ROI; and the practical capability to define, maintain, and govern the EA, align initiatives with it, and drive implementation roadmaps so EA produces concrete, measurable change rather than shelfware.

We are not sure why it’s important to stay within one page, but whatever you’re trying to do, it is not an Enterprise Architecture. And high level means what to whom?

If you have ever had the privilege (or frustration) of building a house, you know you get a “scroll” of diagrams (blueprints) for the house. If something as simple as a house needs a scroll of drawings, an Enterprise Architecture will also require at least one.

This analogy suggests another hint: There is no one “picture” in the set of house blueprints that solves all constituents’ or stakeholders’ needs.

Similarly, no single drawing or representation solves all needs for all Enterprise Architecture stakeholders: the complexity is much greater. Different audiences require different criteria.

Our primary criteria for business-facing models are whether they are “human-consumable.” Our primary criteria for technology and implementation-facing models are whether they are transformable into solutions.

We suggest that there are thirty possible Architectural Model representations and 684 possible Implementation Model representations that may be of interest to segments of enterprise stakeholders. We can calculate this census of models because we have a frame of reference.

We don’t have to develop all of these representations—just the ones that we decide are relevant. However, just because something is not made explicit does not mean it does not exist; it is just implicit. But in not making something explicit, we are making a value judgment. We are very glad that we can understand what we know and are making explicit, but we also know what we are making assumptions about (what remains implicit) when we have the EACOE Enterprise Framework™ acting as our frame of reference.

The BAIT model is an attempt to define what models are required for Enterprise Architecture. It was developed with systems and process implementations as the primary target and was not based on a frame of reference (a Framework). Its most strident previous supporters now call this an “IT stack.“ And we agree that this positioning makes more sense.

There is no such thing as an Enterprise Architecture (or model, or series of models) that will fit any organization.

You might be able to leverage components from an internal prior effort, but you should review anything like that against your organization’s Goals, Processes, and Materials (data) requirements after you develop your models.

You need to define your enterprise’s own DNA first. We don’t recommend the practice of using “reference” models or vendor-provided models. If you are considering doing so as a shortcut, please think twice. Using these types of models as a review of your Enterprise Architecture Models is of only limited value, at best. You have to do the work!

Some government agencies believe that the industrial age is ending and that the information age is gaining momentum, so they want to reskill their people to address what they see as the new economy.

Other government agencies are investing in Federated Enterprise Architecture because citizens are increasing demand for government efficiency, integration (including interjurisdictional), accountability, and transparency.