Extending the Zachman Framework

1. It has been well accepted within the data community who considers it the defacto standard for enterprise architecture.
2. The Zachman Framework 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 Zachman Framework explicitly communicates that enterprise modeling has several stakeholders, not just enterprise architects and developers, whom you should involve in your modeling efforts.

However, the Zachman Framework suffers from several weaknesses:

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.

• 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 Zachman Framework.
• The Zachman Framework isn’t well accepted within the development community and few developers even seem to have even heard about it.
• The Zachman Framework seems to promote a top-down approach to development. When people first read about the Zachman Framework, 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.
• The Zachman Framework 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.

Figure 2. Mapping the Zachman Framework to the disciplines of the EUP.

It’s important to recognize that using the Zachman Framework 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 Zachman Framework 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 Zachman Framework if you choose. The secret is to avoid documentation-heavy, bureaucratic processes centered around the Zachman Framework. 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 Zachman Framework 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

This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context. This book represents leading-edge thinking about enterprise agile, some of which originated in the EUP and RUP.

This book, The Enterprise Unified Process: Extending the Rational Unified Process, defines the Enterprise Unified Process® (EUP), which was first introduced by myself in 1999 and later enhanced to support a wider variety of clients. The EUP is an extension to the IBM Rational Unified Process (RUP).  The EUP extends the RUP to include the operation and support of a system after it is in production and its eventual retirement.  Furthermore, because all but the smallest organizations have more than one system, the EUP also handles cross-system enterprise issues such as portfolio management, enterprise architecture, and strategic reuse.