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

Read More

Enterprise Architecture Defined

When examining the various flavors of IT Architecture it is worthwhile perhaps to start at what some might consider the “top.” By Top, we don’t mean the best or most difficult but rather the top level of architecture – e.g. that level which has an enterprise level or higher (cross-enterprise) scope. Many people define Enterprise Architecture (EA) differently, but the common thread that passes through all definitions is scope and reliance on formalized “Frameworks.”  Also, many EA practitioners view themselves as architecture integrators who provide oversight across all types of design work done within their respective organizations.

Other key considerations about EA include:

1. Most people who know about EA think of it in terms of the “Frameworks” which are used to produce EA “products” or “artifacts” (the output of EA). 
2. Frameworks represent design and notation paradigms and are generally supported by meta-models constructed to emulate IT enterprise environments.
3. Frameworks include: DoDAF, ToGAF, FEAF, Zachman, UML, MODAF, BPMN & BPEL, IDEF, C4ISR, ITIL…

Enterprise Architecture as a practice is most often associated with higher level processes such as Portfolio Management, Acquisition Management (mainly government-focused) and IT Strategy. EA artifacts tend to be more conceptual in nature with the expectation that the higher level description drives lower level designs (Solution Architecture) and artifacts. EA is also often times viewed in a more agnostic fashion in regards to specific technology than Solution or Infrastructure Architecture. 

This diagram illustrates how EA framework considerations might be reconciled with solution architecture elements

We will define EA frameworks in an upcoming post...

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More