Introduction

Much has been written about the decomposing of architectures and designs into components or subsystems. This partitioning is done for several reasons: to group cohesive components into a system or to hide or otherwise deal with complexity when architecting a complex system. In the IT architecture context, complexity needs to be hidden, while at the same time permitting the detail to be documented. Therefore partitioning and layering is a very useful approach for dealing with complexity when developing IT architectures.

The following outlines a set modeling concepts and approaches that hide complexity, permitting better understanding of resulting models, but also having the ability to drill down into as much detail as needed.

Partitions and Layers

The following definitions from the UAM glossary contrast the notions of layers and partitions.

Layer

1. The grouping of IT architecture elements in a model at the same level of abstraction and detail;
2. Conversely, the organization of modeling elements at the same level of abstraction. A layer is a horizontal slice through the architecture, but a partition is a vertical slice through the architecture.

Partition

1. A portion of an IT architecture, or sub-element thereof, organized according to some criteria (e.g. responsible organization or function). Example in UAM is "swimlanes" in an activity or a UAM aspect (e.g. Location).
2. A set of elements that define a common vertical slice through an IT architecture (e.g., an aspect of the architecture such as "Data" or "Activity"), whereas a layer represents a horizontal slice (e.g., a perspective of the architecture such as "Business" or "Technical"). 

Therefore in the context of the UAM, layer and partition are, at the highest level, equated to Perspective and Aspect respectively, as illustrated in the Figure 1 below.

Figure 1 - The UAM Perspectives and Viewpoints

However, there is also partitioning and layering within each of the twelve UAM viewpoints. For example, the use of swimlanes (i.e., pools and lanes) for partitioning within activities. See: Guideline: Pool and Lane Usage.

Layering is also used to deal with complexity; hierarchies of elements. Simple high-level models can be drilled down to another layer that is mode detailed (less abstract).

The viewpoints defined start at the business level (Business Perspective) and get more technical and closer to implementation levels of detail as one works down to the Technology Perspective. The aspects as defined, on the other hand, are vertical slices through the architecture, each one focused on a particular aspect of the IT architecture.

Another way of looking at the viewpoints is shown below. Each level (perspective) has different concerns and motivations, but they are related in that the Business Perspective drives the Logical Perspective which in turn drives the development of the Technical Perspective. Similarly the decisions and compromises made at lower (more technical layers) need to be reflected back into high level perspectives, which will be updated if necessary.

Figure 2 - The UAM Perspectives

As shown in Figure 1, IT architecture definitions are documented in UAM using three perspectives (layers) each having four aspects, for a total of twelve viewpoints as follows:

• Business Perspective (Computation Independent Model)
  • Business Entities Model
  • Business Process Model
  • Business Locations Model
  • Business Roles Model
• Logical Perspective (Platform-Independent Model)
  • Logical Entities Model
  • Logical Process Model
  • Logical Locations Model
  • Logical Roles Model
• Technology Perspective (Platform-Specific Model)
  • Physical Entities Model
  • Physical Process Model
  • Physical Locations Model
  • Physical Roles Model

When developing an enterprise architecture, each of these four views is created.

Strict Partition

A strict partition is a partition where all services/tasks within the partition are accessed by clients/services outside the partition through service gateways. This implies that the partition has its own set of interfaces and as such it may be seen as a logical higher-level service provider. This is particularly useful for partitions that represent either business application boundaries or business process boundaries. It also allows for the interfaces it exposes to the rest of the business to be secured, isolating services internal to the strict partition from external access. This is a key concept for the security reference model defined in: Whitepaper: A Reference Model for Enterprise Security and is extremely useful when applied to IT architecture.

Maintenance

Typically all perspectives are created top-down, starting with the Business level, then the Logical and Technical levels are defined. Variations of this approach are certainly possible, as required by the objectives of the IT architecture. This is illustrated in one of the example IT architecture where only the Technical level locations models are defined. See: IT Research Network TLM. This architecture is leveraged from existing architectures.

A complete Business Perspective is required, at some level of detail (context), since IT architects and business managers need to understand this model in order to make informed decisions regarding strategies, plans and evolution. The Logical level may not be required, if the business, and to some extent the technologies used, do not change drastically. The Logical level is where the major (structural) decision are made, generally based upon the business processes in combination with the technologies chosen to support them.

Often manual tasks are not carried forward to the Technical level of the IT architecture. However, UAM recommends that they are retained in order to provide a more complete picture of the business. In some future iteration of the system, these manual tasks may be automated or integrated with the IT systems.

Existing system architectures are created at the Technical level. They are defined bottom-up since existing documentation is used, which defines the system at this level; typically the as-built level.