To Unify Architecture With Methodology

The Rational Unified Process meets the Zachman Information Systems architecture

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.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

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 (terry@inastrol.com), president of Inastrol, a Southern California-based information management consultancy, specializes in customer relationship information and metadata management.

RESOURCES