Zachman Framework within Enterprise Unified Process (EUP)

It is possible to apply the ZF successfully within the RUP/EUP if you focus on its strengths and address its weaknesses. Figure 1 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. 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. Introduced addition of a 7th column for costing. 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. Changed 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 1 The Zachman Framework within Enterprise Unified Process (EUP).

It’s important to recognize that using the ZF is optional within the EUP – 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. 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).

-> Abstract Technology's Offshore Development Center
-> Abstract Technology software development process
-> Abstract Technology free pilot trial