Enterprise Architecture Framework

An enterprise architecture framework gives architects a consistent way to do their work. It defines what to describe, such as capabilities, processes, data, applications and technology, how to organize those descriptions, and often the steps to follow when developing an architecture. Frameworks save organizations from inventing their own approach, provide a vocabulary that architects and business leaders can share and make it easier to compare work across teams and over time.

Dozens of frameworks exist, from broad methods such as TOGAF to classification schemes such as the Zachman Framework and sector-specific models used by governments and defense departments. Most organizations adopt one as a starting point and tailor it, often combining elements of several. For IT strategy and finance, the choice of framework matters less than whether it produces information that supports decisions about investment, consolidation and risk.

Definition of Enterprise Architecture Framework

An enterprise architecture framework, sometimes shortened to EA framework, is a reference structure for the practice of enterprise architecture. It typically includes some combination of a process, a content model, a classification scheme, reference models and governance guidance.

Frameworks differ in emphasis. Some focus on how to develop an architecture, others on how to classify and organize architecture descriptions, and others on the specific needs of a sector.

Common Elements

A method or process describes the steps for developing and maintaining an architecture, from setting scope to planning and governing change.

A content model defines the types of things architects describe, such as capabilities, applications and data entities, and how they relate to each other.

Viewpoints define standard ways of presenting architecture to different stakeholders, such as executives, project teams or security staff.

Reference models provide reusable patterns or standard terms, and governance guidance covers how architecture decisions are made and enforced.

Widely Used Frameworks

TOGAF, published by The Open Group, is the most widely used. Its Architecture Development Method guides architects through a repeating cycle of phases.

The Zachman Framework is a classification scheme that organizes architecture descriptions in a grid of perspectives and questions. It describes what to document rather than how to develop it.

Government frameworks include the US Federal Enterprise Architecture Framework and the Department of Defense Architecture Framework, known as DoDAF. Many consulting firms and tool vendors also offer their own frameworks, often based on these.

Importance of Enterprise Architecture Frameworks in IT Strategy

A framework speeds up the start of an architecture practice. Rather than debating basic terms and steps, teams can begin from an accepted structure and adapt it.

It improves consistency. When every architect uses the same content model and viewpoints, their work can be combined, compared and reused across projects. Consistency also makes it possible to load architecture information into a single repository, where it can be searched, analyzed and kept up to date.

It also supports communication. A shared vocabulary helps architects explain their work to business leaders, auditors and vendors, and helps new team members contribute quickly. Frameworks also give architecture work credibility with executives who may be unfamiliar with it, since they show the practice follows an established approach.

Choosing a Framework

The best choice depends on the organization's goals, size and sector. Large organizations running major transformations often benefit from a full method such as TOGAF.

Organizations that mainly need to organize and communicate architecture information may prefer a lighter approach built around a few core models, such as a business capability map and an application inventory.

Public sector and defense organizations may be required to use a specific framework. In every case, the framework should be judged by whether it helps answer the organization's real questions about investment, risk and change.

Tailoring and Combining

Few organizations use any framework exactly as published. Applying every step and deliverable usually produces more documentation than anyone needs. Heavy documentation also slows decisions, which undermines support for the practice among the delivery teams it is meant to help.

Common practice is to take the method from one framework, the modeling notation from another, such as ArchiMate, and add organization-specific content such as cost data.

Tailoring decisions should be written down, so that architects apply the framework consistently and new staff understand what is expected. A short guide is usually enough.