EA framework

The existing EA "frameworks" help, but not much. In fact, are they really frameworks? According to whatis.com, a framework is "a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure". Current frameworks simply don't do that. 

Zachman's matrix tells us what the cells are not how to model them. It helps us think about EA (or any system for that matter) but not how to built the EA which is the job of the architect. The matrix stands for a taxonomy to store artefacts rather than for an Enterprise structure to glue the parts together, which is what we need from a framework. 

TOGAF serves us with a simple process (we use it every day to move from point A to B) with delivery checklists for the known layers. In fact, it may be called a process "framework". Views are considered, but in isolation. No navigation, impact analysis or integrated view of the Enterprise is possible. Also, for TOGAF, the business architecture is an afterthought, a late addition to IT. TOGAF was created by the Open Group an IT forum, with no obvious interest or expertise in business matters. It is too large to manage confortably. 

Neither TOGAF nor Zachman provide a generic Enterprise structure, as a framework should do, where components and artefacts fit back into the EA frame. As such, even if widely adopted, the existing "frameworks" cannot ensure consistent, predictable or repeatable results, fact confirmed by practical results. An EA develoment process or taxonomy support your effort but without a structure you are effectively left to design a blackbox. 

People, aware of the dire situation, are bold enough to come with their own EA definitions and easily claim the rank of Enterprise Architect in business or IT. 

More, EA is currently driven by IT for IT. Infrastructure architecture is predominant because it can be done separately. But no matter who drives or sponsors the EA, it would hardly deliver, except in cases where the architect builds an own approach and framework claiming compatibility though with de facto standards. 

The original EA vision covered the entire Enterprise. Nevertheless Zachman was an IBM-er, looking at how to build IT systems with the rigor of the airplane industry. So the vision was directed to IT which embraced it gladly, liberally using terminology like Enterprise for its technologies: EAI, ESB, EJB... 

The EA, as a concept and asset, is still valuable. It should start though from modelling the business. Then continue with the alignment of the technology and organization resources.

...

Zachman is a forceful, passionate advocate for EA. He is good at selling EA to the world. That pretty much sums it up. 

If you think about a house, you would have to ask yourself the same questions: Why do I need it? Who's going to live there? What should it look like? Where should it be, in case I buy or build a new one... 

And then you need an architect, designer, parts supplier etc. All good thinking. The matrix just tells you what the involved parts need to do; it does not tell you how to draw the architecture, how to build it... 

Zachman in fact leaves you exactly where the EA work begins. It might help an executive make his mind about EA but it does not help you build the EA. It asks the initial questions but gives no answers. 

So it is not about EA execution or method. 

...

The first approach to Enterprise Architecture, the Socratic one (see previous blogs), is an application of the wisdom of old. Kipling, in 1902, wrote for our little ones (and us, later) "The Elephant's Child" of "Just So Stories". I quote: 

"I Keep six honest serving-men: 

(They taught me all I knew) 

Their names are What and Where and When 

And How and Why and Who..." 

The method served us since infancy so why not use it now for Enterprise Architecture, which is in its own infancy. It's true that this time we address the questions to ourselves, that is, we have to come with the answers. After this "questioning" phase we have to clarify for ourselves what "What" means (data, objects, nodes, systems, functions etc) or "When"... mean, and so on. 

Nevertheless the "six honest serving-men" (What, Where, When, How...) serve us to check the scope of the EA. Have we covered the how, the why...? The approach establishes the bare bones of an EA. Unfortunately that's where it stops supporting our efforts. 

As these questions apply to any system, the framework would do equally well for a barn or an Enterprise Architecture design. That would leave us to define or find and use a reference structure of the type we need. 

But no EA framework currently provides Enterprise reference maps or templates to show the structure of the Enterprise, the typical parts in interconnection. It is like you start designing or modifying a building without understanding its purpose, the actual or future blueprint. It is only our relative experience that tells us that we need. 

For the Enterprise, what are the typical components? 

Here the business academy should help us more otherwise, how can we align our systems to an EA business architecture/map that does not exist? 

Unfortunately, the big names in business management do not show much interest in Enterprise Architecture, at least, not yet. No sign that they grasped the problem of the business architecture vacuum. I wonder, sometimes, how can they avoid using an architecture or business map in their work. 

The Enterprise Architecture discipline is itself condemned without a business architecture. 

An IT architecture would show only applications and technology in a myriad of interconnections without showing the business functions they perform, how the business processes work or what information is exchanged over the wires. The Business Architecture would respond to all questions starting with How and Why. 

...

An EA framework counts because most EA efforts build, again and again, their "own" frameworks at great costs, with poor results and in most cases to the detriment of the profession. 

A framework, according to whatis.com, is "a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure", like the chassis of a car or the frame of a bike where the parts mount on. 

An EA framework should similarly describe a structure to which the components and artefacts fit back. 

TOGAF though, is an EA development process (ADM), mostly. As such, I would call TOGAF a process framework. 

But a process is not enough of a framework to guarantee predictable and repeatable outcomes. A process stays the same for a bike or a car or no matter what. That is why probably most (TOGAF based) EA developments have little in common and look so different leaving the stakeholders disoriented. 

An EA framework should be based on a business architecture framework that shapes the overall EA. TOGAF though, does not propose a business architecture or any structure for what it matters. 

The Open Group is an IT forum, not overly concerned with business architecture. TOGAF's organization, and in fact, all non IT activities are lumped in the "business" layer as the context for IT. TOGAF does not cover non-IT technology either. For these reasons, TOGAF looks to me like an IT EA process framework. 

...

"Capgemini has been developing its own architecture approach that covers business, information and technology since 1993". Quote from Cap's web site. Here it is, IAF. As I studied the IAF I discovered that the E2AF framework looks similar. 

While I won't copy the IAF picture in here, for copyright reasons, I will refer to it. You might open the URL above in another window. 

What I want to understand is how it works and how it compares to other frameworks. 

IAF reminds me of Zachman's because of a sub-set of its questions. They are shown as two dimensional thin bands crossing the rest of the framework's tri-dimensional elements, horizontally. The picture also shows us the four standard layers, found in any EA, in Spewak's work and later in TOGAF. The layers are not positioned top down, but from left to right and crossed by Zachman's questions, as thin bands. 

Hence, the "What", "How", "With What" question bands cross Business, Information, Information Systems and Technology Infrastructure layers forming a Matrix framework. 

The "What" question is subtitled "Conceptual". I can see little association though. In Zachman's the two are different dimensions. 

Zachman's "What" means, debatably, Information, for most practitioners. But Information is already another layer in IAF. So "What" does not mean Information in IAF. 

As the question is applied to all layers it appears that a conceptual architecture is required for each layer. 

The next question, "How" is associated with "Logical". Not that it matters a lot but it may confuse you since Logical and How, in Zachman's, are on different axes. 

The "How" is again applied to all layers meaning probably four Logical architectures. Does it make sense? At least, they would have to be aligned. I would have thought that a single logical architecture for the Enterprise suffices. 

"With what" or "Physical", the 3rd question is a new dimension for Zachman. But "With what", to my mind, looks like pointing to the technology resources implementing the Business layer. That creates a problem: we already have the Technology Infrastructure and Information Systems layers. So, what is the meaning then? 

I believe that the aim was to describe each EA layer in terms of concept, logic and physical, but layers don't exist as independent systems. They exist only in the context of one system, the Enterprise. Hence, I would say that a single conceptual and logical architecture would do for the Enterprise. The questions dimension then is unnecessary. 

The "Information Systems" layer probably denotes mostly "Applications layer" because of the potential overlap with the "Technology Infrastructure" layer. 

Security and Governance architectures have a tridimensional body, unlike the question bands, but like them they extend the length of the layers. 

But, if we have Security, we might like to have other views like Finance, Real Estate etc. Later. 

The "Why" band is floating on top of the framework, touching nothing. In its isolation, it looks like it's posing the question "Why are we doing this?" at all levels. 

All in all, I think IAF looks good for customers. It attempts to combine the goods of a few approaches. By using Zachman terms with different meanings it confused me though. I can see duplication between the "With what" and the IT (Information System and Technology) layers. 

The question bands suggest Conceptual, Logical and Physical views at each layer which looks good but unnecessary as we have one single system, the Enterprise. If you remove the question bands, what is left is the four layers architecture we all know, which is still good. 

...

DODAF, one of the most elaborate and mature EA frameworks, has been making steady progress and rallied customers along the way. But what does it mean to us in the business world? 

I am attempting here to summarily compare DODAF and variants to the "standard" four layer IT EA (Business, Information, Applications and Infrastructure) approach, accepted in the business world, TOGAF is proposing for instance. I do this because DODAF appears to be so different, so unapproachable from the business world, while I started believing that this should not be necessarily so. But it is true, in my belief, that the metamodel is complex and the vocabulary is different. 

Even before we start I have to admit that I am not a DODAF specialist. But without much ado, here it is: 

DODAF has four major viewpoints: 

AV- Views – for Summary and dictionary 

OV- Operational – describing the operational nodes, activities, information exchanged and organizational units and roles 

SV- Systems – depicting the systems, data and interfaces implementing the operational views 

TV- Technical Standards View – present and future standards and conventions the systems are subject to 

Key DODAF Views: 

Operational Viewpoint

OV-2 Nodes Model

OV-5 Activity Model

OV-3 Operational Info Exchanges, result of OV-2, OV-5 

OV-4 Roles and Org Units

OV-6a,b,c Operational Business Rules, State Transitions, Sequence Diagrams

OV-7 Information Model

System Viewpoint 

SV-1 Systems Interconnectivity Model 

SV-4 System Functions Model 

SV-6 System Data Exchanges, result of SV-1, SV-4 

SV-10a,b,c System Business Rules, State Transitions, Sequence Diagrams

SV-11 Data Model (as opposed to the Information Model) 

There are also performance, standards views and, in some DODAF variants, Strategic and Project Views. Also a few levels of detail and mapping/matrixes between the different Views, called also Views

...