Introduction

In Concept: IT Architecture we find the idea of viewpoints (views and aspects) from which a system can be modeled. Location is one of the aspects, or vertical slices through the system, that defines and models a perspective that is useful in understanding the system and its operation. In the Unified Architecture Method (UAM), the purpose of a Location Model is to capture the decomposition of the system into locations that host business activities. This is done at several levels of abstraction, namely Business Location (the most abstract), Logical Location, and Technical Location (the least abstract, at which actual enterprise technical standards for hardware and software are described). The following is an introduction to the Business Locations (conceptual) level model.

At the business level described here, the notion of location is used to identify and describe the classes of location at which the system has a presence. The Business Locations Model supports this viewpoint by describing what business activities are carried on at the defined locations, and organizes them into a simple model. See: Guideline: Business Locations Model. The locations model works best if layering is used to deal with complexity and to provide views appropriate for the audience and objectives; and comprehension is greatly improved. Detail is hidden, while allowing for it to be defined in lower layers, as required to meet the objectives of the architecture effort.

 Note: Since UAM may model the complete enterprise (or business domain), the level of detail to be included in this model is a judgment call of the architect, based upon:

• The objective of the architecture effort
• The size of the enterprise or (business line)
• Time and resource constraints

Locations and Connections

A location represents the initial, abstract, somewhat physical partitioning and distribution of the enterprise, and is concerned with the geographic placement of (conceptual level) system resources (buildings, points-of-presence, and other notions) along with the business activities provided there. A locality expresses notionally where business process are supported, thus there is a strong connection between business location and business activity. The semantics of locality implies a tighter grouping of activities without defining exact geographic locations, or how the activity is to be supported. It is conceivable for very complex, very large enterprises, that there might be locations that decompose to finer-grained localities (just as a system might contain subsystems). The description of a location includes a general indication of the type of location being defined (e.g. Headquarters, factory, point-of-presence, etc.) along with the business activities supported at the location.

The Business Locations Model is also used to illustrate the conceptual level connections between the locations. Based on the business activities to be supported at the locations, collaborations of localities can be constructed to help characterize the connections between the localities.

The Business Location Model diagrams show how business processes are distributed across the locations, and how they are connected. In the lower level Logical and Technical Perspectives, developed based upon this business level view, the location of computing resources is defined, and is important when considering functional and non-functional requirements. For many systems engineers, this is "the architecture", the Logical and Technical level views. 

The Locations Model consists of two elements:

• Location - a location is a collection of system activities (processes and tasks) that provide services at that location.
• Connections - pathways (for information, mass, energy, or discrete physical items) supporting the required process interactions between locations.

The semantics of the location diagrams are similar to those of UML deployment diagrams, with locations represented as stereotyped UML nodes. In the UML standard, a node is a classifier that "... is a physical object that represents a processing resource, generally, having at least a memory and often processing capability as well. Nodes include computing devices but also human resources or mechanical processing resources." Therefore, UML allows us to extend the semantics of nodes, and the associations that connect them, through stereotyping and the application of tagged values. This is used to define locations and connections. The icon for a Business Location is a building (see the illustration below). 

Locations are characterized with:

• Business Activities - a list of the business activities provides at the location, which relates directly to the Business Process Model.
• Business level non-functional requirements - things such as importance, survivability and availability requirements of the location.

Connections are characterized by the following:

• Activities - the business activities that traverse the link.
• Business level non-functional requirements - things such as volumes, importance, survivability and availability requirements of the communications path. 

As you move to the Logical and Technical Locations Models, computing concepts are added to the locations model, becoming more like traditional IP network models. Business Location may also be refined into more than one Logical or Technical level location, as dictated by the requirements of the business. And location models can represent quite disparate things, ultimately realized, for example, as a collection of hardware platforms (e.g. network routers etc.), part of a computational resource (e.g. ATM, servers and storage), or groups of collaborating human resources (e.g. call-center).

Location Diagrams

The figure shows a simple Business Location Model for an enterprise—a bank. The bank has a headquarters, a number of ATMs, a Data Center, and Bank Branches. See: Guideline: Business Perspective Views.