Introduction

Architecture is a concept that is easy to understand and that most engineers intuitively relate to, but it is hard to define precisely. In particular, it is difficult to draw a sharp line between design and architecture—architecture is one aspect of design that concentrates on some specific features of the system. Also, what is the difference between architecture and engineering and how do they relate?

IT architecture, as defined by UAM, is largely characterized as the definition of the elements and their associated structure that satisfies the required functionality.  Architecture needs to deal with many aspects, such as organizational structures, where they and associated business services are located, and end-to-end business processes, which software and system architects generally do not deal with. The scope of the UAM architecture activities as well as the aspects examined are much broader that the software architecture or systems architecture.

UAM defines architecture as "the fundamental concepts or properties and organization of a system in its environment (i.e., context) embodied in its elements that may be almost arbitrarily arranged, their relationships, and in the principles guiding its design and evolution—defining the form (of elements) is the main objective, but balancing form and function is key".

In contrast, UAM defines engineering as "a more restrictive design activity where the components and their relationships are already defined (i.e., the architecture is defined) and now scientific rigor and precision is applied to ensure success—function is key".

See the definitions for Form and Function.

Architecture Description

To speak and reason about IT architecture, you must first define an architectural representation, a way of describing important aspects of an architecture. In UAM, this description is captured in the various viewpoint models (see: Concept: Architecture Perspectives and Viewpoints). Also, within each viewpoint, multiple levels (i.e., a hierarchy of models) is used to deal with the complexity involved in modeling a complete "system" (see: Concept: Complex IT Architectures).

Architectural Viewpoints

UAM represents IT architectures using multiple architectural viewpoints or models. Each architectural viewpoint addresses some specific set of concerns, specific to stakeholders in the development process: business owners and managers, designers and system/software engineers/architects, and project managers and implementors. The viewpoints capture the architecture by defining models for different architecture aspects, with these aspects being related to each other, with the resulting cohesive set of viewpoints defining a perspective. This is summarized below. 

The architectural choices and decisions made, and reflected in the viewpoint models, are all related back to the business requirements and many other other tactical and strategic inputs that shape the IT architecture. It should be noted that an IT architecture is in effect defining further constraints on the requirements and on the design decisions to be made at a lower level (e.g., detailed design and implementation).

IT architecture, as note, is described through a number of different architectural viewpoints that are arranged into perspectives. Each viewpoint shows the IT architecturally from a particular aspect. The set of perspectives and associated aspects:  

• Business Perspective (i.e. Computation Independent Models (CIMs))
  • Business Entities Model
  • Business Process Model
  • Business Locations Model
  • Business Roles Model
• Systems Model - Platform Independent Models (PIMs)
  • Logical Data Model
  • Logical Process Model
  • Logical System Model
  • Logical Roles Model
• Technology Model - Platform Specific Models (PSMs)
  • Physical Data Model
  • Physical Process Model
  • Physical System Model
  • Physical Roles Model

When developing an IT architecture, each of these three collections of models (perspectives) is defined. These perspectives (horizontal collection of viewpoints) and aspects (vertical collection of viewpoints) are depicted graphically in the following diagram:

Architectural Focus

Although these viewpoints could represent the complete detailed design of an IT architecture in all its gory detail, this is often not practical, therefore the architecture concerns itself only with important viewpoints and at an appropriate level of detail—the purpose of the architecture effort must always be kept in mind. It is recommended to only include:

• Structure - important architectural structures, patterns, and relationships;
• Key Elements - architecturally significant entities, processes, locations and roles;
• Key Scenarios - the 80% rule is a good one to follow, show the main business processes;
• Key Activities - capture the main business activities (activities & processes).

The architectural viewpoints of necessity are abstractions, or simplifications, of the "system" in order to focus on and better understand the important characteristics by leaving irrelevant details aside. The important characteristics are those that assist in understanding:

• Migration - how do we get from the current state to the future state as defined by the IT architecture;
• Patterns and Reuse - identification of architecture/design patterns and possible reuse;
• Non-functional Requirements -  understanding qualities, such as performance, volumes, security, availability, portability, and safety;
• Partitioning of the Model - related to the first point, how can we partition the IT system to aid in migration, management, and implementation;
• Architectural Decisions - the key objective of IT architecture is to make decisions; required decisions are discovered and best made with the help of well define architectural views;
• Context - related to partitioning, placing tasks, processes and related systems into its larger context aids in better understanding the system and the constraints placed upon it by this context.

Also see: Concept: Complex IT Architectures.

Architectural Patterns

Architectural patterns are ready-made structures or solutions that solve recurring architectural problems. An architectural framework or an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of architecture. Many architectural patterns exist that provide a structure for particular aspects of the enterprise architecture. See: Architectural Patterns. A number of architectural frameworks currently exist:

• Client-Server;
• Cloud Computing;
• Distributed Computing Pattern
• IT Security Reference Model
• Multitier Architecture;
• Service-oriented Architecture;
• Peer-to-Peer Architecture.

Architectural Perspective Languages 

UAM IT architecture viewpoints (and in fact each perspective) has a viewpoint language specified, which defines the generic modeling elements allowed (the metamodel) to be used for modeling the viewpoint. The result is better uniformity of created views, which are easier to develop and easier to understand. The defined UAM perspective languages and associated viewpoint languages both help in improving the integrity and understandability of the defined IT architectures. See: Supporting Material: UAM Perspective Languages. 

The Architecting Process

A UAM IT architecture is one of the outcomes of the IT Architecture Processes workflow. As the architecture effort follows this workflow, iteration after iteration, the IT architecture  is defined and revised until it is completed. Each iteration, for each perspective or viewpoint, includes an assessment and a review milestone, resulting in a robust and well understood architecture.