A fundamental question that people always seem to ask about enterprise modeling, and modeling in general, is how do various approaches such as enterprise business modeling, enterprise architectural modeling, and design modeling for a single project all relate to one another. The Zachman Framework (ZF), created in the 1980s by John Zachman, describes a good approach to addressing this very question. The ZF, depicted in Figure 1, describes a collection of perspectives pertinent to enterprise modeling. The rows of the framework represent the views of different types of stakeholders and the columns represent different aspects or views of your architecture. Traditionally, within a column the models are evolved/translated to reflect the views of the stakeholders for each row and within a single row should be consistent with one another. In this article I show how the Enterprise Unified ProcessTM (EUP) extends the Rational Unified Process (RUP) with the ZF.

Figure 1 The Zachman Framework.

The ZF has several strengths:

1. It has been well accepted within the data community who considers it the defacto standard for enterprise architecture.
2. The ZF defines the perspectives that your enterprise models should encompass, the implication being that you can apply its guidance within a process such as the EUP.
3. The ZF explicitly communicates that enterprise modeling has several stakeholders, not just enterprise architects and developers, whom you should involve in your modeling efforts.

However, the ZF suffers from several weaknesses:

1. It can lead to a documentation-heavy approach (although this does not have to be the case). There are 36 cells in Figure 1, each of which could be supported by one or more models.
2. It can lead to a process-heavy approach to development – you can instantly see the opportunity to define a collection of rigorous processes to support the ZF.
3. The ZF isn’t well accepted within the development community and few developers even seem to have even heard about it.
4. The ZF seems to promote a top-down approach to development. When people first read about the ZF, they tend to think that it implies a top-down approach where you start with the models in row 1, then work on row 2 models, and so on. This doesn’t have to be the case, you can in fact start in any cell and then iterate from there.
5. The ZF appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community).

My experience is that it is possible to apply the ZF successfully within the RUP/EUP if you focus on its strengths and address its weaknesses. Figure 2 shows how we have extended the ZF so that it aligns with the RUP/EUP disciplines. As you can see we have made significant changes to it:

1. We replaced the six rows with the sixteen disciplines of the EUP, providing a more finely detailed collection of views. The enterprise management columns are listed first then the project-level disciplines to remain consistent with the ZF’s top-down approach. The primary benefit of showing the disciplines as rows is that it makes it clear how to apply the questions represented by the framework columns to each aspect of the EUP. Unfortunately this approach could exacerbate many of the weaknesses of the ZF.
2. We've introduced a cost column. At the DAMA 2004 conference Graeme Simsion mused on a panel that the columns of the ZF reflect single word English interrogatives and that if John Zachman had spoken another language then the ZF may have looked different. For example French includes "combien" which translates as "how much" or "how many". It is very clear that financial concerns are important within IT organizations, hence the addition of a 7th column. The cells of this column, for the most part, identify the potential savings which you should achieve by implementing the discipline effectively. Yes, you will still incur the operational costs of performing the activities of each discipline but to simplify the chart we don't indicate this information. Interestingly, in German all the columns can be labelled with single word interrogatives starting with the letter "w"[md] was, wie, wo, wer, wann, warum, and wieviel respectively.
3. We refocused the first column. We’ve indicated that the first column, which addresses the question of “what”, is really a structural issue and not a data issue. This simple generalization helps to remove the data-oriented bias of the ZF, making it clear that you have more options available to you than data-oriented artifacts.
4. The cells describe the issues to address. Each cell indicates the potential issue(s) to address, if any, as well as suggest a potential artifact to explore those issue(s). Some cells are left blank because the column isn’t applicable to the discipline.

Figure 2. Mapping the ZF to the disciplines of the EUP.

It’s important to recognize that using the ZF is optional within the EUP – we believe that it provides very good guidance for your modeling and development efforts because it reminds you of the critical issues which you need to address. The following advice should help you to apply this enhanced version of the ZF with your organization:

• Keep it simple. You don’t need to create artifacts for all of the cells, the important thing is that you at least consider the issues for that cell. You can in fact be quite agile with the ZF if you choose. The secret is to avoid documentation-heavy, bureaucratic processes centered around the ZF. Remember, your goal is to develop working software not to create lots of fancy models and documentation.
• Remember that you have choices. Each cell indicates the required perspective, not suggested models. For example, in the Structure column, David Hay suggests that you create a language-divergent data model in row 2, a convergent entity/relationship model in row 3, and a database design in row 4 of the ZF of Figure 1. Moriarty suggests a business class diagram, a class diagram, and a schema data model respectively in the same rows. Object developers would probably suggest a component model, a class diagram, and another class diagram for these rows. All three approaches are valid, but all three represent the experiences and prejudices of the individual methodologists. Far better advice would be to understand the perspective represented by each box, understand the strengths and weaknesses of each type of modeling artifact, and then apply the right artifact(s).

Recommended Reading

• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning