Introduction

IT architecture cannot be done properly without modeling the system. There are many known advantages to visual modeling, not the least of which is the "understanding of complex systems". What can be more complex that a complete enterprise, or even a business line or business domain within an enterprise? Visual modeling is therefore key if one is to do a proper job of IT architecture, especially for large systems. But the question may be asked: why do IT architecture? Again there are many well documented responses to this question—the reasons may be summarized as follows:

• Alignment - align IT with business needs and goals;
• Optimization - definition of an IT environment that works better for the business;
• Understanding - with understanding (or the enterprise and its processes/system) comes insight, which support the two points above, plus perhaps those breakthroughs that bring the enterprise to a whole other level.

The following concepts and approaches are used to deal with this complexity and providing usable models are described below:

• Visual Modeling
• System Partitioning
• Modeling Concepts:
  • Aggregation
  • Associations
  • Structured Classes
  • Generalization
  • Abstraction / Encapsulation
• Important EA Modeling Elements
• Model Diagrams
• Creation and Maintenance

Visual Modeling

Most people actually do get 1000 words from a picture; in other words, visually modeling really does have benefits. Understanding complex systems, or even developing a detailed model of a complex system, cannot happen without doing visual modeling. But visual modeling isn't enough on its own, we need to also add some modeling concepts and constructs to help out, namely abstraction (conceptualization) and encapsulation. These concepts help one deal with the complexity, permitting the construction of very complex models that fully describe the target, but at the same time can be understood. See Wikipedia: Visual Modeling. 

The audience for the models is important as well; these models need to be understood by business people, project managers and designers and by the implementation people. How do we accomplish this? Through the use of multiple views of the enterprise in question (e.g., system partitioning, see below), and through the use of abstraction and other techniques.

System Partitioning

The following definitions differentiates between the notions of layers and partitions. The term tier, while common in describing the logical architecture of a solution, is not often used in the IT architecture context. The terms layer and partition are better descriptions of partitioning notions used within IT architectures. 

Layer

1. A grouping modeling elements that are all at the same level of abstraction within a model. See also: Term Definition: Layer; 
2. A layer represents a horizontal slice through an architecture at a given level of abstraction, but a partition is a vertical slice which is typically a "functional" slice.

Partition

1. A portion of a model that organizes the elements based upon functional considerations. 
2. A partition represents a vertical (functional) slice through an architecture, whereas a layer represents a horizontal slice.

Therefore in the context of UAM IT architecture, layer and partition are equated to perspective and aspect respectively, as illustrated in the Figure 1 below.

Figure 1 - The UAM Framework Perspectives, Aspects and Viewpoints

The Perspectives defined in Figure 1 start at the business level (Business Perspective) and get more technical and closer to the implementation as one works down to the Technology Perspective, with each of these Perspectives being composed of four models: Data (entity), Activity, Location, and People (actors and role). Layering within each Perspective is also possible, permitting the drill-down to more and more detail (and complexity) as required.  

The Aspects as defined in Figure 1, on the other hand, are vertical slices through the architecture, each one focused on a particular aspect of the architecture.  

Modeling Concepts

Aggregation / Composition

Aggregation is used to structure models through the composition of elements, and permit re-use of model elements. For example, a car is an aggregation of it's various parts: body, wheels, tires, etc. See Wikipedia: Object Composition and Wikipedia: Aggregation.

Associations

Associations are used to define simple relationships between model elements. Associations are used for a number of different reasons. See Wikipedia: Association and Wikipedia: Class Diagram - Association.   

Generalization

Generalization structures are used to capture common properties between classes. Specialization is the opposite of generalization. See: Wikipedia: Generalization.

Abstraction / Encapsulation

The term encapsulation is often used interchangeably with information hiding, while some make distinctions between the two. It seems that people, however, fail to agree on the distinctions between information hiding and encapsulation though one can think of information hiding as being the principle and encapsulation being the technique. A software module hides information by encapsulating the information into a module or other construct which presents an interface. This technique is used to hide detail at one level, then providing a more detailed lower level view. One could view this as the same as layering, however it is not quite the same. Layering partitions the views based upon various organizational constructs such as the application layer, or middleware layer, which generally have to do with software or hardware layers. Encapsulation on the other hand defines simpler abstractions of various concepts or constructs, such as "Human Resources" which will eventually be further partitioned in various sub-activities. Also see: Concept: Architecture Perspectives and Viewpoints.

Important Modeling Elements

Entity

An entity represents a significant and persistent piece of information that is manipulated by business roles. Entities are passive; that is, they do not initiate interactions on their own. A entity might be used in many different business processes, and usually outlives any single interaction. Entities are produced and consumed by multiple business activities and tasks that together form a business process.

The notion of entity goes from conceptual at the business level to a more concrete at the technology level. See: Artifact: Business Entity.

Activity

An activity provides value-added business benefit while producing and consuming entities. Business roles may interact with these activities/tasks. An activity includes the notion of process and task, and is identical to the definition within the Business Process Modeling Notation (See: Whitepaper: BPMN - an Introductory Tutorial ).

The notion of activity goes from conceptual at the business level to a more concrete at the technology level. See: Artifact: Business Activity.

Location

Locations are a categorization (based upon the business activities supported) of locations with business systems under the authority of the enterprise (or portion) in question. 

The notion of entity goes from conceptual at the business level to a more concrete at the technology level. See:Guideline: Business Location and Artifact: Business Location. 

Role

Roles are a categorization, based upon required interaction with the business, of external interactions with the business systems.  

The notion of role goes from conceptual at the business level to a more concrete at the technology level. See: Artifact: Business Role,  Artifact: Business Actor and Guideline: Users, Actors and Roles. 

Events

Events represent important occurrences in the day-to-day tasks of the business. See: Guideline: Business Event.

Rules

A rule or business rule is a declaration of policy or a condition that must be satisfied; they direct or modify the execution of process and activities. See: Guideline: Business Rule.

Model Diagrams

A model is a representation of a system, typically addressing some particular area of concern. The system, possibly and enterprise architecture, is represented by a set of models since there are multiple concerns (and stakeholders) that need to be modeled and addressed. Each model (within a viewpoint: a view) is also constructed with varying levels of abstraction, from the more general, hiding or encapsulating detail, to the more specific, exposing more detail and explicit design decisions.

The viewpoints, mentioned above, are captured in models which show the things that are relevant for that particular viewpoint. These models are typically illustrated by visual diagrams of some kind. The intersection of the Perspective and Aspect define a viewpoint to be used to capture the architecture at a given level of abstraction, as shown in Figure1. Each of these viewpoints may include one or more models (or views). The architecture is captured in a set of models (and diagrams that visualize them) that express the architecture from various viewpoints and abstraction levels. As shown in the model Figure 1, there is a set of models (viewpoint) for every Perspective-Aspect combination.

Creation and 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 always 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.

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.