Introduction

UAM defines IT Architectures as an organized set of three perspectives, each of which contain four viewpoints, with each viewpoint containing elements that clear relationships to one another. Each perspective addresses the six interrogatives (i.e., who, what, when, where, why and how) and therefore the four viewpoints together form a complete model of the "system". In UAM there are three perspectives, or layers, used to describe the IT architecture—the Business Perspective, the Logical Perspective and the Technical Perspective. Each of these perspectives (and their set of four viewpoints) has their own context, that is, information important for the perspective and they also have relationships with each other, as shown in the figure below.

Context of the Three UAM Perspectives

Different people have different backgrounds and ideas that modify their opinions. When attempting to achieve a common understanding on something as complex as the enterprise IT environment (or a subset of it), including its processes, structure, and relationships, we need a way to describe architecture and architecturally significant issues in a way that will be understood by each impacted group. This is done by describing the enterprise at three different, yet related, perspectives or levels as shown below. Each of these perspectives has a context in terms of inputs or influences (across the top of the figure) and also there are relationships between them, as described below.

The Business Perspective is a description of the significant aspects of the IT architecture from a business viewpoint. The Logical Perspective is a description of the IT architecture from a logical perspective showing the applications and processes that support the business viewpoint, including how the applications are used, where they are logically deployed and how they interact with each other. Technical Perspective of the IT architecture is a description of the technical level (specific hardware) components, network, systems, storage systems etc that supports the Logical viewpoints, and in turn the Business viewpoints.

As illustrated in the figure, the Business Perspective will drive the structure and definition of the Logical Perspective, which in turn drives the definition of the Technical Perspective of the architecture. This does not imply a hierarchical relationship wherein the Business Perspective prescribes the Logical architecture, and the Logical architecture prescribes the Technical architecture. Rather, it means that architecture elements (and other information) are communicated in one direction, and architectural decisions must be made at the appropriate perspective level within the IT architecture, and these decisions and tradeoffs are reflected back (modify) up to the previous architectural levels so that the appropriate decision makers and other architects can be made aware of the impact. Rather, it means that architecture elements (and other information, called drivers) are communicated in one direction, and any Architectural Decision (that might be the result of tradeoffs) that affects the resulting architecture must be communicated to and made at a level within the enterprise (e.g., Business Domain vs. CIO) appropriate to the scope and impact of the decision. Also, and very important, decisions (tradeoffs) made at say the Technical level need to be reflected back and modify the Logical Perspective if required—likewise Logical to Business.

An architectural goal implies a desired condition, while an architectural constraint implies mandatory compliance; however, even constraints can be intentionally ignored. For example, a constraint that requires the business to comply with certain policies might be ignored because the cost of making the changes necessary to comply far exceeds the penalties incurred by non-compliance. These tradeoffs are communicated back to the Logical and Business Perspectives, and may require some updates to these perspectives or even executive level approval of trade-off decisions.

Architecting is about balancing forces and making tradeoffs to create a solution that optimally satisfies conflicting requirements. This means that the business model defines models and constraints that describe what it requires from the logical architecture. The same applies to the logical and the technical architecture. Where conflicts arise, as they always do, localized sub-optimal solutions must be found in order to ensure an optimum overall solution. When these decisions have a broad impact (i.e. beyond a local system and IT architecture, they apply to the business line or to the complete enterprise), they are termed Architectural Decisions and must be formally agreed to by stakeholders represented by an architecture board (See: Roadmap: AD Governance).

These different perspectives of IT architectures must always be considered when communicating with stakeholders—discussing only one of them with an individual may convey an incomplete picture. Furthermore, it can cause that individual to misunderstand the consequences of his or her decisions regarding the tradeoffs and compromises required in other perspectives. The impact of decisions at one of the perspectives must be translated to the other ones, and communicated. This helps stakeholders understand the benefits and disadvantages of tradeoffs, which leads to architectural alignment. Architectural alignment helps us understand the consequences of decisions.