Understanding EA Frameworks

Enterprise Architecture by nature has a broad scope. In a sense, the typical Enterprise Architect is being asked to describe all things IT-related about any given enterprise in the course of their routine duties. What Architects determined fairly early on (in the relatively brief history of IT Architecture) was that this descriptive process is in most cases similar across organizations. And this realization is how the concept of Architecture Frameworks was born.

Before we begin defining EA Frameworks in greater depth, it is important to clarify what frameworks don't represent:

1. Frameworks are not design notation - so that's why we haven't included UML.
2. Frameworks are not ready-made solutions for the enterprise.
3. Frameworks are not design patterns. 

I will explain these clarifications as we proceed through the topic.

This is an example from an EA project using both the DODAF & FEAF Frameworks

EA Frameworks Defined

An Enterprise Architecture Framework is a meta-model for characterizing all IT related capabilities present within any given organization. At the heart of this model is a taxonomy that differentiates core capabilities into approximately a half dozen or so categories. These categories usually include; Business, Application, Data, Infrastructure and so on. 

By characterizing the enterprise in this type of meta-model, the Framework facilitates the ability to construct standard views of the enterprise (visual / diagrammatic or otherwise). The Framework provides even more value if translated into a repository-driven software tool that allows for all specific enterprise information to be captured and stored within the industry standard meta-model format (which then supports inter-operability / information sharing across organizations).  

All EA frameworks share these common features or goals. There are only a handful of Frameworks being used across industry; they include:

• Zachman - Arguably the first real Framework
• DODAF - Department of Defense Architecture Framework  (MODAF for Europe / NATO)
• FEAF - Federal Government (US) Architecture Framework
• TOGAF - The Open Group Architecture Framework

Each one of these have their own unique variations - two are more industry focused and two are primarily government focused. There are about a half a dozen tools dedicated to providing software support for EA frameworks and these include:

• System Architect
• Mega
• Sparx EA
• Troux (formerly Metis)
• Archimate
• ProVision

There are other tools, but ones listed above are most commonly used.

The Difference Between Design & Enterprise Architecture
Earlier I hinted that EA and design are not quite the same - especially where Enterprise Architecture Frameworks are concerned. This is in fact the same dichotomy we've introduced in our other posts regarding the difference between EA and Solution Architecture. If we want to describe the entire enterprise, then TOGAF provides a good medium for accomplishing the goal, but if we wish to describe or define a database schema then we'd look at using ERD or Dimensional Modeling techniques. If we wanted to design an application, then we'd use UML design notation and perhaps a pattern-based architecture approach.

How we coordinate or reconcile EA with Solution Architecture is a big topic and we will address that across a number of posts in this blog. We will also define in greater detail the other terms introduced here today.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc