ArchiMate® 3.1 Specification. The Open Group
A structure or behavior element in one of the core layers of the ArchiMate language.
Note: Core elements are described in detail in Section 3.4.
2.12 Element
Basic unit in the ArchiMate metamodel. Used to define and describe the constituent parts of Enterprise Architectures and their unique set of characteristics.
2.13 Layer
An abstraction of the ArchiMate framework at which an enterprise can be modeled.
2.14 Model
A collection of concepts in the context of the ArchiMate language structure.
Note: The top-level language structure is defined in detail in Section 3.2.
For a general definition of model, see the TOGAF framework [4].
2.15 Relationship
A connection between a source and target concept. Classified as structural, dependency, dynamic, or other.
Note: Relationships are defined in detail in Chapter 5.
3 Language Structure
This chapter describes the structure of the ArchiMate Enterprise Architecture modeling language. The detailed definition and examples of its standard set of elements and relationships follow in Chapter 4 to Chapter 13.
3.1 Language Design Considerations
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.
The design of the ArchiMate language started from a set of relatively generic concepts. These have been specialized towards application at different architectural layers, as explained 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 try to accommodate the needs of all possible users. In the interest of simplicity of learning and use, the ArchiMate language has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.
This standard does not describe the detailed rationale behind the design of the ArchiMate language. The interested reader is referred to [1], [2], and [3], which provide a detailed description of the language construction and design considerations.
3.2 Top-Level Language Structure
Figure 1 outlines the top-level hierarchical structure of the language:
• A model is a collection of concepts – a concept is either an element or a relationship
• An element is either a behavior element, a structure element, a motivation element, or a composite element
Note that these are abstract concepts; they are not intended to be used directly in models. To signify this, they are depicted in white with labels in italics.
Figure 1: Top-Level Hierarchy of ArchiMate Concepts
3.3 Layering of the ArchiMate Language
The ArchiMate core language defines a structure of generic elements and their relationships, which can be specialized in different layers. Three layers are defined within the ArchiMate core language as follows:
1. The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.
2. The Application Layer depicts application services that support the business, and the applications that realize them.
3. The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services. Physical elements are included for modeling physical equipment, materials, and distribution networks to this layer.
The general structure of models within the different layers is similar. The same types of elements and relationships are used, although their exact nature and granularity differ. In the next chapter, the structure of the generic metamodel is presented. In Chapter 8, Chapter 9, and Chapter 10, these elements are specialized to obtain elements specific to a particular layer.
In alignment with service-orientation, the most important relationship between layers is formed by “serving”1 relationships, which show how the elements in one layer are served by the services of other layers. (Note, however, that services need not only serve elements in another layer, but also can serve 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).
3.4 The ArchiMate Core Framework
The ArchiMate Core Framework is a framework of nine cells used to classify elements of the ArchiMate core language. It is made up of three aspects and three layers, as illustrated in Figure 2. This is known as the ArchiMate Core Framework.
It is important to understand that the classification of elements based on aspects and layers is only a global one. Real-life architecture elements need not strictly be confined to one aspect or layer, because elements that link the different aspects and layers play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, business roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements, and it may depend on the context whether a certain piece of software is considered to be part of the Application Layer or the Technology Layer.
Figure 2: ArchiMate Core Framework
The structure of the framework allows for modeling of the enterprise from different viewpoints, where the position within the cells highlights the concerns of the stakeholder. A stakeholder typically can have concerns that cover multiple cells.
The dimensions of the framework are as follows:
• Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application,