UAM in Detail
The framework, perspectives, language, processes and deliverables.
3.1 Introduction
UAM is roughly based upon the Zachman Framework and employs many industry and international standards. The UAM framework and methodology prescribes a modeling methodology and analytical methods, but is tool independent. This chapter provides an in-depth look at UAM. The approach, terminology, and notations used to describe the methodology are from the Unified Method Architecture (UMA) which is equivalent to the current OMG industry standard Software Process Engineering Meta-Model (SPEM) (OMG 2008). UMA is an evolution of SPEM version 1.1, which IBM updated and submitted back to OMG and was eventually published as SPEM V2.0. The complete UAM methodology definition and its associated processes, methods, artifacts, and guidance are published in the form of a web site. See Appendix C for an overview of UMA.
þ A simplified version of the UAM methodology and example architectures on the Internet: UAM Online: http://www.unified-am.com
References are provided in this book to additional information contained within the methodology. In the descriptions that follow the term system is used to refer to the portion of the business under study, be it the complete enterprise (i.e., EA) or some defined subset.
3.2 UAM Architecture Framework
The UAM architecture framework, shown in Figure 12, defines the viewpoints used to describe IT architectures. They are grouped horizontally into perspectives suitable for development and communications with various stakeholders. Similarly the viewpoints are grouped vertically into aspects that are also a useful focus for different sets of stakeholders.
The three perspectives defined by UAM are:
Business – four viewpoints describe the system using business concepts and terminology.
The level of detail is dictated by the context and objectives. Conceptual level views are defined with the primary stakeholders being business experts and managers and other business people. Using MDA terminology these are Computational Independent Models (CIMs)—no computing concepts (e.g., storage) appear in these viewpoints.
Logical – four viewpoints describe the system using generic technical concepts and terminology. The level of detail is dictated by the context and objectives. The primary stakeholders are architects, business experts, technical managers, technical experts, and technical design people. These are Platform-Independent Models (PIM) using MDA terminology—generic computing concepts are introduced.
Technical – four viewpoints describe the system using specific technical concepts and terminology. The level of detail is dictated by the context and objectives. The primary stakeholders are technical design and technical implementation people. These are Platform-Specific Models (PIMs) using MDA terminology—specific computing elements are introduced.
Note that the scope of the system is defined and included within the Business Perspective. The scope is not a perspective or even a viewpoint, since it does not include any models, but does include a context diagram. It is a very simple summary that sets the context for the IT architecture including the scope of the effort and the definition of important business concepts and terms. The primary stakeholders are business managers and other business people.
The four UAM aspects provide another useful grouping of viewpoints for different sets of stakeholders:
Data – the what aspect of the architecture; defining what information the system produces and consumes. The primary stakeholders are business owners, business experts, business analysts, database designers, security specialists, system architects, and applications designers.
Activity – the how aspect of the architecture; defining how the information (or other products of the system) is produced and consumed by activities. It provides a complete picture of the business processes within the system. The primary stakeholders are business owners, business experts, business analysts, process designers, application architects, system architects, and technology architects.
Location – the where aspect of the architecture; defining where the system under study has a presence in order to conduct its business. It models the business locations, the network, servers, and storage used by the system. The primary stakeholders are business owners, business experts, network designers, storage specialists, server specialists, technology architects, and systems architects.
People – the who aspect of the architecture; defining who interacts with the system, including partners, suppliers, customers, and employees. It models user access and interactions with the system, including roles and security aspects. The primary stakeholders are business owners, business experts, business users, user interface (GUI) designers, security specialists, and application architects.
The three UAM perspectives are described in detail in Chapter 4 (the Business level), Chapter 5 (the Logical level), and Chapter 6 (the Technical level).
3.2.1 Framework Concepts
Figure 12 defines the UAM framework, which is a subset of the Zachman Framework. It has only four columns representing Data, Activity, Location, and People, and the underlying concepts and metamodel for the UAM framework are also very different from the Zachman Framework. Where did the when and why columns end up in the UAM framework? The when column from the Zachman Framework is transformed into events in UAM—the events that drive the actions and responses in day-to-day business activities; they will show up in the Activity aspect (how) models. This is an important facet of current IT architectures, which are usually very event driven. The why column is transformed into business rules in UAM—the rules that govern everything from data or application access to the actions taken following an event; they also show up in the Activity aspect models.