ArchiMate® 2.1 Specification

The unambiguous specification and description of enterprise architecture’s components and especially of their relationships requires an architecture modeling language that addresses the issue of consistent alignment and facilitates a coherent modeling of enterprise architectures.

This chapter presents the construction of the ArchiMate architecture modeling language. The precise definition and illustration of its generic set of core concepts and relationships follow in Chapters 3, 4, 5, 6 and 7. The concepts and relationships of the two language extensions are described in more detail in Chapters 10 and 11. They provide a proper basis for visualization, analysis, tooling, and use of these concepts and relationships.

Sections 2.1 through 2.5 discuss some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel. Section 2.6 presents the ArchiMate Framework, which is used in the remainder of this document as a reference taxonomy scheme for architecture concepts, models, viewpoints, and views. Sections 2.7 and 2.8 describe the basic structure of the two language extensions. Section 2.9 briefly describes the relationship between ArchiMate and TOGAF.

2.1   Design Approach

A key challenge in the development of a general metamodel for enterprise architecture is to strike a balance between the specificity of languages for individual architecture domains, and a very general set of architecture concepts, which reflects a view of systems as a mere set of inter-related entities. Figure 1 illustrates that concepts can be described at different levels of specialization.

Figure 1: Metamodels at Different Levels of Specificity

At the base of the triangle we find the metamodels of the architecture modeling concepts used by specific organizations, as well as a variety of existing modeling languages and standards; UML is an example of a language in this category. At the top of the triangle we find the “most general” metamodel for system architectures, essentially a metamodel that merely comprises notions such as “entity” and “relation”.

The design of the ArchiMate language started from a set of relatively generic concepts (higher up in the pyramid). These have been specialized towards application at different architectural layers, as explained below in the following sections.

The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most enterprise architecture modeling tasks. Many other languages, such as UML 2.0, try to accommodate all needs of all possible users. In the interest of simplicity of learning and use, ArchiMate has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

2.2   Core Concepts

The core language consists of three main types of elements (note, however, that the model elements often represent classes of entities in the real world):active structure elements, behavior elements, and passive structure elements (objects). The active structure elements are the business actors, application components, and devices that display actual behavior; i.e., the ‘subjects’ of activity (right side of the Figure 2).

Then there is the behavioral or dynamic aspect (center of Figure 2). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior.

Figure 2: Generic Metamodel: The Core Concepts of ArchiMate1

The passive structure elements are the objects on which behavior is performed.

In the domain of information-intensive organizations, which is the main focus of the language, passive structure elements are usually information or data objects, but they may also be used to represent physical objects. These three aspects – active structure, behavior, and passive structure – have been inspired by natural language, where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).

Second, we make a distinction between an external view and an internal view on systems. When looking at the behavioral aspect, these views reflect the principles of service orientation.

Thus, the service is the externally visible behavior of the providing system, from the perspective of systems that use that service; the environment consists of everything outside this providing system. The value provides the motivation for the service’s existence. For the external users, only this exposed functionality and value, together with non-functional aspects such as the quality of service, costs, etc., are relevant. These can be specified in a contract or Service Level Agreement (SLA). Services are accessible through interfaces, which constitute the external view on the active structural aspect.

An interface provides an external view on the service provider and hides its internal structure.

2.3   Collaboration and Interaction

Going one level deeper in the structure of the language, we distinguish between behavior that is performed by a single structure element (e.g., actor, role component, etc.), or collective behavior (interaction) that is performed by a collaboration of multiple structure elements.

This collective behavior can be modeled as an interaction.

Figure 3: Collaboration and Interaction

2.4   Relationships

Next to the core concepts outlined above, ArchiMate contains a core set of relationships. Several of these relationships have been adopted from corresponding relationship concepts that occur in existing standards; e.g., relationships such as composition, aggregation, association, and specialization are taken from UML 2.0, while triggering is used in many business process modeling languages.

Note:   For the sake of readability, the metamodel figures in the next sections do not show all possible relationships in the language. Refer to Section 6.5 on additional derived relationships. Furthermore, aggregation, composition, and specialization relationships are always permitted between two elements that have the same type.

 

2.5   Layering

The ArchiMate language defines three main layers (depicted with different colors in the examples in the next chapters), based on specializations of the core concepts described in Sections 2.2 and 2.3:

1.   The Business Layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors.

2.   The Application Layer supports the business layer with application services which are realized by (software) applications.

3.   The Technology Layer offers infrastructure services (e.g., processing, storage, and communication services) needed to run applications, realized by computer and communication hardware and system software.

The general structure of models within the different layers is similar. The same types of concepts and relationships are used, although their exact nature and granularity differ. In Chapters 3, 4, and 5, we further develop these concepts to obtain concepts specific to a particular layer. Figure 2 shows the central structure that is found in each layer.

In line with service orientation, the most important relationship between layers is formed by “used by” relationships, which show how the higher layers make use of the services of lower layers. (Note, however, that services need not only be used by elements in a higher layer, but also can be used by elements in the same layer.) A second type of link is formed by realization relationships: elements in lower layers may realize comparable elements in higher layers; e.g., a “data object” (Application layer) may realize a “business object” (Business layer); or an “artifact” (Technology layer) may realize either a “data object” or an “application component” (Application layer).

2.6   The ArchiMate Framework

The aspects and layers identified in the previous sections can be organized as a framework of nine cells, as illustrated in Figure 4.

It is important to realize that the classification of concepts based on aspects and layers is only a global...