TOGAF versus Zachman versus FEA

Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them. TOGAF complements Zachman  – and isn’t in competition with it.

TOGAF views the enterprise as a series (continuum) of architectures ranging from highly generic to highly specific.  It calls this continuum the Enterprise Continuum. It views the process of creating a specific enterprise architecture, such as MAM-EA, as moving from the generic to the specific. TOGAF’s ADM provides a process for driving this movement from the generic to the specific.

TOGAF calls most generic architectures Foundation Architectures. These are architectural principles that can, theoretically, be used by any IT organization in the universe.

Phase A begins with a Request for Architecture Work

• This document includes the business reasons for the request, budget and personnel information, and any constraints that need to be considered.
• The culmination of Phase A will be a Statement of Architecture Work, which must be approved by the various stakeholders before the next phase of the ADM begins. The output of this phase is to create an architectural vision for the first pass through the ADM cycle.
• The Architectural Vision created in Phase A will be the main input into Phase B.

Phase B – Create a detailed baseline and target business architecture and perform a full analysis of the gaps between them.

• Phase B is quite involved—involving business modeling, highly detailed business analysis, and technical-requirements documentation.
• A successful Phase B requires input from many stakeholders.
• The major outputs will be a detailed description of the baseline and target business objectives, and gap descriptions of the business architecture.

Phase C – Information-systems architecture what Phase B does for the business architecture, The most important deliverable from this phase will be the Target Information and Applications Architecture.

1. Develop baseline data-architecture description
2. Review and validate principles, reference models, viewpoints, and tools
3. Create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
4. Select data-architecture building blocks
5. Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
6. Review qualitative criteria (for example, performance, reliability, security, integrity)
7. Complete data architecture
8. Conduct checkpoint/impact analysis
9. Perform gap analysis

Phase D – technical infrastructure necessary to support the proposed new architecture.

This phase is completed mostly by engaging with Irma’s technical team.

Phases E  and F evaluate the various implementation possibilities and risk factors

identifies the major implementation projects that might be undertaken, and short-term wins (e.g. standardize data sharing between systems) versus long term wins (have error free data exchanges)

Phase G – prioritized list of projects and creates architectural specifications for the implementation projects. These specifications will include acceptance criteria and lists of risks and issues.

Phase H  – the architectural change-management process with any new artifacts created in this last iteration and with new information that becomes available

Flexibility of Phases

• TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation. So, it should be no surprise if two different TOGAF-certified consultants end up using two very different processes—even when working with the same organization.
• TOGAF is even more flexible about the actual generated architecture. In fact, TOGAF is, to a surprising degree, “architecture-agnostic”. The final architecture might be good, bad, or indifferent. TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture. For this, you are dependent on the experience of your staff and/or TOGAF consultant. People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely disappointed (as they will be with any of the methodologies).

Federal Enterprise Architecture (FEA)

The Federal Enterprise Architecture (FEA) is the latest attempt by the federal government to unite its myriad agencies and functions under a single common and ubiquitous enterprise architecture. FEA is still in its infancy, as most of the major pieces have been available only since 2006. However, as I discussed in the history section, it has a long tradition behind it and, if nothing else, has many failures from which it has hopefully learned some valuable lessons.

FEA is the most complete of all the methodologies discussed so far. It has both a comprehensive taxonomy, like Zachman, and an architectural process, like TOGAF. FEA can be viewed as either a methodology for creating an enterprise architecture or the result of applying that process to a particular enterprise—namely, the U.S. Government. I will be looking at FEA from the methodology perspective. My particular interest here is how we can apply the FEA methodology to private enterprises.

Most writers describe FEA as simply consisting of five reference models, one each for performance: business, service, components, technical, and data. It is true that FEA has these five references models, but there is much more to FEA than just the reference models. A full treatment of FEA needs to include all of the following:

1. A process for creating EAs
2. A transitional process for migrating from pre-EA to EA