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 Process^TM (EUP) extends the Rational Unified Process (RUP) with the ZF.

1. 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.
2. The ZF isn’t well accepted within the development community and few developers even seem to have even heard about it.
3. 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.
4. The ZF appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community).

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 7^th 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.

• 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).