To Unify Architecture With Methodology
The Rational Unified Process meets the Zachman Information Systems architecture

Terry Moriarty                
April 16, 2001

Modeling a business well and translating that model to good application design has long been a challenge. But the tasks of developing, integrating, and managing information systems create pressure to meet this challenge. The Rational Unified Process (RUP) and the Zachman Information Systems Architecture framework are complementary techniques that help bridge the gap between business model and application creation.

What the UML Is and Isn't

The Unified Modeling Language (UML) is a standard for a set of interrelated diagrams that specify the design of object-oriented (OO) applications. The diagrams depict the structural and behavioral aspects of the system under analysis.

The class diagram provides the structural view of the system by identifying the object classes involved in the system, their interactions with one another, the properties that must be known about each, and the types of operations that each can perform. As such, the class model provides a more static view of the system.

The system's dynamic aspect is primarily depicted through a series of use case diagrams that represent the expected behavior of the system under specific circumstances. Each use case can be supported by a variety of diagrams that provide further insight into the details of the behavior. These diagrams include the object interaction, sequence, activity, and state change diagrams.

Finally, the configuration of the technology components that represent the infrastructure for the application is presented through the component and deployment diagrams.

Most UML proponents recognize that it is essentially a standard notation and set of rules for creating diagrams. These diagramming standards are not enough to ensure that a business is properly modeled and that application designs correctly specify what needs to be built. A process must exist to guide in defining how to use the diagrams properly.

A Process to Support UML

Rational Software Corp. stepped up to the challenge of creating a process that supports UML modeling by developing the RUP, a systematic approach to:

• Modeling a business
• Identifying its information system requirements
• Converting those requirements into the appropriate technology components (such as object classes, use cases, modules, components, databases, communication software, and hardware platforms)
• Implementing the information system.

You can find a good description of the RUP in Philippe Kruchten's book, The Rational Unified Process: An Introduction (Second Edition, Addison Wesley, 2000).

The Procedure

The RUP divides a project into different perspectives: Business Modeling, Requirements, Analysis, Component Design, and Implementation/Deployment. I was pleased to see that business modeling is separated from requirements analysis. The business model is supposed to describe the essence of the business without describing how that business will be supported by its information systems. The focus is on what the business is, what it needs to know, what events it must respond to, and the processes it must be able to do. After management understands these essential business components, it can decide which aspects of the business automated information systems will support. The requirements for those information systems are then derivable from the business model.

In the analysis stage, the focus shifts to identifying the best configuration of use cases and object classes necessary to support the business requirements. It is here that you are interested in identifying what types of forms, reports, and transmissions must be provided. This stage exposes the logic for enforcing business rules. It also highlights the information that must persist over time. All this knowledge appears on the class diagrams as boundary, control, and entity object classes. The behavioral diagrams illustrate transaction and dialog sequencing, rather than the business process flows developed during business modeling. However, all these OO constructs are defined independently of any specific technology.

At the component design stage, you model the technology configuration and map the model to the analysis construct it supports. Now you're deciding which aspects of the system will be coded in Java or C++, which parts will require CORBA or COM objects, and how the entity object classes will be persisted. If you're using a relational DBMS for the persistence layer, you'll transform the class model into a physical database design model.

A Systems Planning Framework

In the mid-1980s John Zachman, then of IBM, proposed a simple matrix as a framework for planning information systems. The matrix puts on one axis the "things of interest" - things that must be considered or created to manage information (data, function, network, people, time, and motivation). On the other axis, it shows the various perspectives you need to consider for each of those things (enterprise, information system, technology, and noncontextual, for example). These categories became the row and column headings of Zachman's framework ("A Framework for Information Systems Architecture," IBM Systems Journal, vol. 26, no. 3, 1987).

The particular forms the things of interest take, as the matrix intersections show, vary from one perspective to the next. For example, the information systems perspective is interested in entities, attributes, and relationships, but the technology perspective is concerned with the tables, columns, and constraints that support those information system constructs within a relational database. In fact, in many cases, there is a process by which the constructs from one perspective are transformed into necessary supporting constructs of the next perspective. Each transformation moves you closer to the final, working information system.

The Zachman framework has gained enormous acceptance within the data management community. I use it as a way to explain the complexities of developing information systems, as the basis for my repository metamodel, and as a device for assessing the comprehensiveness of a tool. (For a discussion of one such tool, see my review of Rational Rose, "Bridging Two Worlds", Intelligent Enterprise, 3/27/2001)

Seeking Consensus

I'm happy to say that Rational is aware of the Zachman framework. In fact, Rational has an internal white paper that is an initial attempt at mapping the Zachman framework and the RUP to one another (Roly Stimson, "The Zachman Framework for Enterprise Architecture and Rational Best Practices and Products"). One of Stimson's purposes for the paper is to stimulate discussion, with the ultimate goal of creating a mapping that is agreeable to advocates of both approaches. It's encouraging that Rational has already made its cut at mapping its products against the Zachman framework, because I too find that the RUP is highly correlated with the framework. (See Table 1.)

However, it's important to remember that these approaches are really addressing different scopes. As Stimson states, "The RUP explicitly supports projects, which produce specific deliverables for specific stakeholders within defined timescales and costs, whereas the Zachman framework exists above the individual project level, and aims to accommodate and classify all the outputs of all the various modeling projects within an enterprise." Furthermore, the Zachman framework is an architecture, a way of organizing and thinking about things. The RUP, on the other hand, is a process, an approach for creating the things that the Zachman framework prescribes.

With these caveats, I believe there is value in demonstrating how the UML diagrams fall within the context of the Zachman framework when those diagrams are developed using the RUP. (See Table 2) Interestingly, my mapping is about 90 percent in alignment with Stimson's, even though we approached the mapping from different backgrounds.

The Hits

Using the RUP, I can produce a set of diagrams that are consistent across each row in the Zachman framework. The trick is to figure out which UML features are employed within each perspective. For example, many have questioned whether UML diagrams are useful for developing business models. They are, when the diagrams are created using the RUP stereotypes of business object, business actor, business worker, and business use case. You name the model objects with terms that are meaningful to the business, using normal English spelling. The emphasis is on what the business does and what it needs to know about. The swim lanes in the activity and interaction diagrams are names of departments or business roles, such as customer, account officer, and the marketing department. Many UML constructs, such as attribute visibility and object class association navigation, are ignored at this point in time.

Diagrams from the information systems perspective are flavored more by technology architecture. Object classes are often stereotyped based on the role they play in the application architecture. For instance, the boundary stereotype is used to represent the user interface objects, the control stereotype represents those object classes that synchronize the interactions between objects, and the entity stereotype represents those object classes that must persist over time. Interaction diagrams describe how the user will interact with the system, through the use of forms that are represented as boundary object classes.

The Misses

It's easy to see that there are holes in the RUP's coverage of cells in the Zachman framework. Given the nature of the Scope perspective, which identifies at a high level what enterprise the Zachman framework is being applied to, diagrams are not necessarily the best way to communicate. If you were using diagrams to communicate the scope, I don't see why some variation of the UML diagrams couldn't be used. But they may be too structured to meet the needs of the intended audience.

Still, consider this: The business model is the specification of the enterprise's business rules. The analysis models illustrate how the information system constructs support those business rules. Therefore, no special diagram is necessary to communicate business rules for these perspectives. However, the Zachman framework includes the enterprise's mission, vision statement, goals, strategies, tactics, and plans in its motivation column. No UML diagrams exist to represent these constructs.

Although there is no specific UML diagram that supports the Network column, business object classes are exposed that represent the various locations where business is conducted. Therefore, while I may be stretching here, I mapped those location-oriented object classes into the Network column. Similarly, I included the object classes that represent the business actors and the roles they assume into the People column.

As you progress toward the technology perspective and begin to approach code, you use diagrams less and less. All the logic specified in an activity diagram or the rules for state transitions presented in a state chart must be allocated to some method in an object class. Persistent data must be represented through some database schema. To facilitate the interaction of the objects across the network, messages must be represented in the appropriate technology, such as COM or CORBA. Therefore, nothing exists within an OO application that can be allocated to the Out of Context (or Code) perspective of the Zachman framework.

The Convergence

Even though the Zachman framework and the RUP emerged from different disciplines, they are highly correlated. I find this fact very encouraging because it means that the standard modeling approaches being developed out of the OO community can play a role within the wider scope of enterprise architecture. The goal of all these efforts is to bring greater discipline to how information systems are developed, integrated, and managed. We come much closer to attaining this objective when our architectures and methodologies converge.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. She authored Enterprise View (originally the Repository Report and later the Data Architect) column for Database Programming & Design. You can reach her via email at terry@inastrol.com.

Copyright © 2001 Terry Moriarty ALL RIGHTS RESERVED