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.
The Zachman Framework.
|The ZF has several strengths:
- It has been well accepted within the data community who considers it the
defacto standard for enterprise architecture.
- 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.
- 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:
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 ZF.
The ZF isn’t well accepted within the development
community and few developers even seem to have even heard about it.
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.
The ZF appears to be biased towards traditional,
data-centric techniques (thus explaining its popularity within the data
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
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.
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.
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.
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).