Do Enterprise Architecture (EA) Frameworks Matter?

The short answer is no. EA
frameworks are outdated, limit planning and arguably distract from real change. Great, let’s go home!

Of course, it’s not actually that simple. First, that actually means framework choices can be really impactful. Second, just because being a die-hard TOGAF or Zachman fan is limiting, those frameworks still have something to teach you. If you’re
going to break the framework rules, you need to understand those rules in the first place. What’s more, abandoning frameworks is only really possible if you have the tools in place to take a more flexible approach.

Here, we will explain the limitations of EA frameworks, explore the pros and cons of some of the most popular EA frameworks, and then help you think about how to move past a restrictive approach towards EA methodology and architect a more flexible
future for enterprise architecture. Let’s go!

Suggested reading: For a detailed rundown of what good EA planning looks like, check out our updated — The
Definitive Enterprise Architecture Blueprint.

Mục Lục

What is an EA framework?

An EA framework establishes common practices for the creation, interpretation and analysis of business, IT and application architecture. Basically, it’s a way to standardize your approach to EA, which is useful because it:

Provides language and concepts for EA planning.
Helps keep architects on track within the complexity of an EA project.
Supplies metrics that can be used to benchmark the success of your EA project and improve communication and coordination of action.

In theory, EA frameworks help you develop, communicate and action your EA plans. Depending on the nature of those plans and your business, different frameworks will be better suited to help you succeed.

What’s wrong with EA frameworks?

EA frameworks are theoretical. More often than not, they focus on planning, conceptualization and rationalization. “That’s the point of EA!”, we hear you say. Well, if that’s you… you’re wrong. Planning is an important
part of EA, but the point of EA is to improve organization capabilities, efficiency and communication.

The structure of an EA framework is helpful, but it also has the potential to encourage two of the worst tendencies in enterprise architecture:

The creation of “ultimate solutions”: A lot of EA frameworks take it for granted that defining an ideal architecture is your challenge and goal. What this doesn’t recognize is that organizations always change, and
there never is one single solution or “end-state” that can be defined and described. EA frameworks make it easy to get caught up in trying to plan everything, rather than improving what’s in front of you.
Being a roadblock rather than an enabler: EA needs to work collaboratively with stakeholders across the business in order to enable solutions that matter to people (and the business). If EA architects start planning for the sake of
planning, they’ll be more focused on integrating a new application or process into their model than solving an actual problem.

EA’s reputation for being an Ivory Tower exists for a reason.1 EA architects have historically spent a lot of time developing unrealistic plans that are detached from the reality on the ground.
EA frameworks contribute to this by focusing on the art of planning rather than the art of action.

The most popular EA frameworks

Like EA frameworks themselves, the analysis of EA frameworks is often entirely speculative. It judges frameworks at face value based on what they say about themselves. So, what’s the reality? There are three big ones worth talking about, and a few honorable
mentions.

The Zachman Framework

Developed by John Zachman for IBM in the 1980s, The Zachman Framework is kind of the granddaddy of all EA frameworks — although this has probably been overstated. Zachman has a lot of similarities with older
BSP (Business System Processing) ideas that it was developed to work alongside.2

The Zachman Framework centers around a two-dimensional, 30-cell taxonomy of architectural terms. Over time, this original matrix has been updated and expanded. However, the framework remains focused on the definition of terms that can be used to direct
planning, communication and strategy. Zachman’s popular because it’s relatively simple to use. However, The practical value of the framework is far harder to define.

Pros of the Zachman Framework:

It helps conceptualize what needs to be done and provides language for theoretical planning.
It’s easy to use while still being flexible enough to meet the needs of a variety of enterprises.
It has a lot of history behind it and continues to be developed to try and accommodate modern architecture.

Cons of the Zachman Framework:

It’s entirely theoretical and encourages an Ivory Tower mentality.
The framework doesn’t include guidelines for deployment within an architectural process.
Updated and expanded editions to Zachman aren’t as simple as the original and can verge into the overly complex.
The framework was developed in the late 1970s and early 1980s at a time when standalone, mainframe systems were the norm — which is baked into some of its foundations.

The bottom line: The Zachman Framework will help you standardize language, contextualize planning and evaluate how different levels of your EA plan relate to each other. However, it can lead to endless planning cycles and won’t
directly help you put plans into action.

TOGAF (The Open Group Architecture Framework)

Zachman might be the oldest framework, but TOGAF is the most popular and largest. Developed by The Open Group since 1995, and currently on version 9.2, the framework is grown collaboratively and takes inputs
from over 300 Architecture Forum members who represent some of the world’s leading companies and organizations.

TOGAF provides a step-by-step solution for end-to-end EA, which… if possible, would be fantastic. The problem with TOGAF is that you can’t really systematically walk your way through an enterprise architecture project. Generally, it’s
important to prioritize EA components that are more important at the time. This is lived out in the reality that many certified TOGAF-practitioners treat it as more of a label than a true set of guidelines.
3

Pros of TOGAF:

In theory, it can walk you through an EA project from start to finish.
The terms, notations, ideas and artifacts defined by TOGAF provide valuable tools for understanding and communicating ideas.
It has become the de-facto EA framework, and you can expect widespread familiarity with it among architects.
The framework can be adapted to work with other standards if needed.

Cons of TOGAF:

There is a lot to TOGAF (like multiple 500+ page long manuals), and it’s a complicated slog.
The step-by-step structure of TOGAF is impractical, making it more of a large unstructured repository of EA ideas that will be difficult to access for inexperienced practitioners.
It remains largely IT-centric, and has been criticized for focusing architects on IT solutions to all problems.

The bottom line: TOGAF
is the de facto EA framework, kind of a framework for frameworks, providing a huge body of knowledge about architecting. There is a lot of good stuff buried in TOGAF, but the people who need it most (new EA architects) will have the hardest time sifting
through its structure to find the right thing. Luckily, there is a multi-million dollar industry around selling TOGAF
training, which you can purchase… if you want.

FEAF (Federal Enterprise Architecture Framework)

Federal Enterprise
Architecture is an EA framework developed by the US federal government. This delivers a framework specifically designed for large government applications, rather than private-sector. With that said, it’s been adopted by the private sector as
well. Version
2 of the FEA was published in 2013.

Realistically, FEAF shares a lot with both Zachman and TOGAF, along with older BPS methodologies. It helps define terms and processes, but focuses heavily on planning and documentation.

Pros of FEAF:

It provides a comprehensive vision for overall EA planning.
It combines features of both Zachman and TOGAF in a streamlined yet feature-full package.
It can be useful for organizations that are heavily reliant on US government contracts that want to mirror the planning, processes or technology of government agencies.

Cons of FEAF:

It can lead architects down a path of planning for planning’s sake.
It can focus architects on details that aren’t important.
It was designed for government and doesn’t have the same flexibility that other frameworks provide.

The bottom line: FEAF is a good more modern alternative. However, it has simply duplicated many of the issues with traditional frameworks, and needs to be approached with caution.

And many many more

The list of EA frameworks just goes on. Two important honorable mentions are:

Department of Defense Architecture Framework (DoDAF): Developed for the US Defense Department in the mid-2000s, DoDAF is very similar to the older C4ISR
and provides a number of steps and models that can help define and direct EA projects.
The Gartner Methodology: Gartner’s Enterprise Architecture
Framework, otherwise known as the Gartner Methodology, doesn’t focus as much on definitions, but how to think about EA processes. Although, the model is always changing and is only available at a cost to Gartner members.

The list doesn’t stop there. Beyond the historic examples already addressed (BSP and C4ISR), there is the NIST EA Model and Stephen Spewak’s famous 1993 book, Enterprise Architecture Planning (EAP). Then there are other government models (e.g.
the Australian
Government Architecture Reference Model) and open resources like the Business Architecture
Body of Knowledge (BizBoK) — along with variations on all of these.

If not frameworks then what?

In one word, the answer is “flexibility”. There are several parts to this.

Part 1: Thinking about yourself first (being selfish)

When it comes to developing an effective EA methodology, you need to start by thinking about you. This is the only way to make sure that what you are focusing on actually matters to the business. Ask yourself:

What are you trying to achieve? Every company wants lower costs, greater revenues, better efficiency and so forth. But what are the true strategic objectives of your firm, and how will EA help to achieve these outcomes? Does your firm intend to achieve a particular market share for a particular product? Naturally, this can involve lowering costs and improving efficiency, but make sure not to lose sight of the final goal when aiming for outcomes.
What is the scope of your project? EA covers everything from how your business is structured to your IT infrastructure and applications.
What information will help you? Identifying the information you need to have about your existing architecture will help you evaluate what information you need to improve outcomes.
What industry-specific requirements do you have?
Compliance, security, due diligence and reporting requirements can all have an impact on your EA choices.

You then need to match your answers to these questions with a strategy that will get you to the right conclusion.

Part 2: EA software and an action-orientated mindset

The
whole point of moving beyond EA frameworks is to stop endless planning
and more rapidly effect positive change across your organization. The
longer it takes (on an ongoing basis) to capture, analyze and
communicate enterprise data, the more likely
you are to be planning with obsolete information. This is exactly
what you want to avoid.

The answer is a mindset shift towards smaller and more
incremental steps. You also need the tools available to make that
simple. At Orbus, we built iServer365 to make that possible to:

Unify your data: By pulling information
from across your organization, you get a single-source-of-truth for
faster planning and more accurate analysis.
Think big-picture: Deliver real business value through transformation outcomes that align with the overall business strategy.
Visualize and present: Quickly use
analytics tools to produce dynamic reports with clear and actionable
insights. Help figure out what to do and explain why you are doing it.
Standardize and automate: Out-of-the-box
support for different frameworks and templates makes it easy to use the
right language and get the most out of the frameworks you do use.

iServer365 takes the very best of EA frameworks and combines it with Orbus Software’s years of experience delivering EA projects to enable every client to leverage their enterprise architecture for the most value.

Fundamentally, a flexible way of working requires
flexible tools. EA software can free you from endless planning, but only
if you approach it with the right mentality.

Bonus Part: Understanding what EA frameworks have in common

For experienced architects, it can help to find the common factors between EA frameworks. This can then form a foundation from which to create your own framework or choose the most appropriate existing framework for your organization.

Most EA frameworks are about helping you structure and standardize planning in order to think about information and its relationship to your organization. Although different frameworks address these concepts differently, there are eight basic categories
that EA frameworks help you define. By focusing on this underlying framework, you can better conceptualize what EA frameworks are helping you achieve, and apply it to the specifics of your organization.

The 8 fundamental factors of EA Frameworks

Categories: This labels what type of information is being managed — e.g. products, places, accounts, etc. — making it possible to organize and analyze information on a basic level.
Understanding: This explains what information means and defines terms. For example, does the label “address” reference a place or an IP? Identifying common language and understanding is critical to communication.
Presentation: This defines how EA information is presented. For example, displaying figures in graphs vs tables vs text — each of which lends itself to different interpretations, and is better suited to different purposes.
Evolution: This explores how changes might happen to your architecture over time and how information should be updated. For example, keeping track of evolving product, sales and marketing should be part of your EA plan, rather than
simply treating all information in your system as static.
Knowledge: This draws lines between information that can be stored in a direct format and information that will remain tacet or hidden. For example, when managing B2B sales contacts, is it explicitly clear that individual contacts
represent businesses, or is it assumed that individuals accessing this information know this?
Responsibility: This is about who needs to take actions related to architecture. That could be capturing information, defining patterns or updating architecture. This is critical for implementing changes and maintaining your system.
Process: This looks at how information is actually used. For example, is data about sales prospects for analysis or used as contact information? This provides critical context for identifying who changes will impact and what the best
choices are.
Meta levels: The previous seven categories could all be considered metadata — information about information. Meta levels go one step further and provide administrative context about that metadata. For example, where information
is stored, accessed and used.

A more flexible EA future

Although we started this by saying that EA frameworks don’t matter, they can actually matter quite a bit… they just sometimes make things worse. Realistically, where they create the largest problems is where people take them too rigidly.
Using them appropriately actually requires devaluing their importance.

Use EA frameworks to develop a shared language, think about problems, and learn advanced tricks that will help you grow. Don’t use them to replace your ability to think and plan what’s right for your organization. And, whatever you do, don’t
fall into the trap of EA planning for the sake of planning. EA software provides the visibility and flexibility needed to put EA frameworks in their place and make a difference to the business. Find out for yourself and get a free demo of iServer365
today.