The main hierarchy of behavior and structure elements of the ArchiMate language is presented in the metamodel fragment of Figure 4. It defines these elements in a generic, layer-independent way. Note that most of these elements (the white boxes) are abstract metamodel elements; i.e., these are not instantiated in models but only serve to structure the metamodel. The notation presented in this chapter is therefore the generic way in which the specializations of these elements (i.e., the elements of the different architecture layers) are depicted. The concrete elements (the gray boxes), which can be used to model the Enterprise Architecture at a strategic level, are described in more detail in Chapter 7.
Figure 4: Hierarchy of Behavior and Structure Elements
This generic metamodel fragment consists of two main types of elements: structure (‘nouns’) and behavior elements (‘verbs’).
Structure elements are the strategic element resource, and structural elements, which can be subdivided into active structure elements and passive structure elements. Active structure elements can be further subdivided into external active structure elements (also called interfaces) and internal active structure elements.
Behavior elements are the strategic elements course of action and capability, and behavioral elements, which can be subdivided into internal behavior elements, external behavior elements (also called services), and events.
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).
Figure 5 specifies the main relationships between the behavior and structure elements defined above. For an explanation of the different types of relationships, see Chapter 5. In this and other metamodel figures, the label of a relationship signifies the role of the source element in the relationship; e.g., a service serves an internal behavior element.
Figure 5: Behavior and Structure Elements Metamodel
Note: This figure does not show all permitted relationships: every element in the language can have composition, aggregation, and specialization relationships to elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.6. The full specification of permitted relationships can be found in Appendix B.
Active structure elements are the subjects that can perform behavior. These can be subdivided into internal active structure elements; i.e., the business actors, application components, nodes, etc., that realize this behavior, and external active structure elements; i.e., the interfaces that expose this behavior to the environment. An interface provides an external view on the service provider and hides its internal structure.
An internal active structure element represents an entity that is capable of performing behavior.
An external active structure element, called an interface, represents a point of access where one or more services are provided to the environment.
Active structure elements are denoted using boxes with square corners and an icon in the upper-right corner, or by the icon on its own.
Figure 6: Generic Active Structure Elements Notation
Behavior elements represent the dynamic aspects of the enterprise. Similar to active structure elements, behavior elements can be subdivided into internal behavior elements and external behavior elements; i.e., the services that are exposed to the environment.
An internal behavior element represents a unit of activity performed by one or more active structure elements.
An external behavior element, called a service, represents an explicitly defined exposed behavior.
Behavior elements are denoted in the standard iconography using boxes with round corners and an icon in the upper-right corner, or by the icon on its own.
Figure 7: Generic Behavior Elements Notation
Thus, a 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 offered to the user of the service provides the motivation for the existence of the service. For the users, only this exposed behavior 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.
In addition to this, a third type of behavior element is defined to denote an event that can occur; for example, to signal a state change.
An event is a behavior element that denotes a state change.
An event may have a time attribute that indicates the moment or moments at which the event happens. For example, this can be used to model time schedules.
Figure 8: Generic Event Notation
Passive structure elements can be accessed by behavior elements.
A passive structure element is a structural element that cannot perform behavior. Active structure elements can perform behavior on passive structure elements.
Passive structure elements are often information or data objects, but they can also represent physical objects.
Figure 9: Generic Passive Structure Element Notation
Going one level deeper in the structure of the language, the collective nature of a behavior can be made either implicit (several active structure elements assigned to the same internal behavior) or explicit through the use of a collective internal behavior (interaction) that is performed by (a collaboration of) multiple active structure elements.
A collaboration is an aggregate of two or more active structure elements, working together to perform some collective behavior.
This collective internal behavior can be modeled as an interaction.
An interaction is a unit of collective behavior performed by (a collaboration of) two or more active structure elements.
Figure 10: Generic Collaboration and Interaction Notation
Furthermore, for individual internal behavior elements, a distinction is made between processes and functions.
A process represents a sequence of behaviors that achieves a specific outcome.
A function represents a collection of behavior based on specific criteria, such as required resources, competences, or location.
Figure 11: Generic Process and Function Notation
The specializations of core elements are summarized in Figure 12. Within each layer, it is permitted to use composition and aggregation relationships between processes, functions, and interactions; e.g., a process can be composed of other processes, functions, and/or interactions.
Figure 12: Specializations of Core Elements
Table 1 gives an overview of the core elements, their definitions, and their default graphical notation. But note that most of these elements are abstract; they are not used in models but only their descendants in the different layers of the ArchiMate language.
|
Specializations |
Definition |
Notation |
|
|
Active Structure |
|||
|
Internal active structure element |
An entity that is capable of performing behavior. |
|
|
|
|
Collaboration |
An aggregate of two or more active structure elements, working together to perform some collective behavior. |
|
|
Interface |
A point of access where one or more services are exposed to the environment. |
|
|
|
Behavior |
|||
|
Internal behavior element |
A unit of activity performed by one or more active structure elements. |
|
|
|
|
Process |
A sequence of behaviors that achieves a specific outcome. |
|
|
|
Function |
A collection of behavior based on specific criteria, such as required resources, competences, or location. |
|
|
|
Interaction |
A unit of collective behavior performed by (a collaboration of) two or more structure elements. |
|
|
Service |
An explicitly defined exposed behavior. |
|
|
|
Event |
A state change. |
|
|
|
Passive Structure |
|||
|
Passive structure element |
An element on which behavior is performed. |
|
|
The core elements of the ArchiMate language focus on describing the architecture of systems that support the enterprise. They do not cover the elements which, in different ways, drive the design and operation of the enterprise. These motivation aspects correspond to the “Why” column of the Zachman framework [5].
Several motivation elements are included in the language: stakeholder, value, meaning, driver, assessment, goal, outcome, principle, and requirement, which in turn has constraint as a subtype. In this section, the generic motivation element is introduced. The more specific motivation elements are described in Chapter 6.
Figure 13: Overview of Motivation Elements
The motivation elements address the way the Enterprise Architecture is aligned to its context, as described by these intentions.
A motivation element is an element that provides the context of or reason behind the architecture of an enterprise.
Figure 14: Generic Motivation Element Notation
Motivation elements are usually denoted using boxes with diagonal corners.
Table 2: Motivation Element
|
Element |
Definition |
Notation |
|
Motivation element |
An element that provides the context of or reason behind the architecture of an enterprise. |
|
Next to the motivation elements described in the previous section, the language also includes a number of strategy elements, notably capability, resource, and course of action, as exhibited in Figure 4. These are defined as specializations of the generic behavior and structure elements and are defined in more detail in Chapter 7.
Figure 15: Strategy Elements
Composite elements consist of other concepts, possibly from multiple aspects or layers of the language. Grouping and location are generic composite elements (see Figure 16). Composite elements can themselves aggregate or compose other composite elements.
The grouping element aggregates or composes concepts that belong together based on some common characteristic.
The grouping element is used to aggregate or compose an arbitrary group of concepts, which can be elements and/or relationships of the same or of different types. An aggregation or composition relationship is used to link the grouping element to the grouped concepts.
Figure 17: Grouping Notation
Concepts may be aggregated by multiple (overlapping) groups.
One useful way of employing grouping is for modeling Architecture and Solution Building Blocks (ABBs and SBBs), as described in the TOGAF framework [4].
Another useful application of grouping is for modeling domains. For example, the TOGAF framework Glossary of Supplementary Definition (Section A.40) defines Information Domain as: “grouping of information (or data entities) by a set of criteria such as security classification, ownership, location, etc. In the context of security, Information Domains are defined as a set of users, their information objects, and a security policy”.
In Example 1, the Grouping element is used to aggregate a conglomerate of two processes and an object that together realize a service (both with nesting and explicitly drawn aggregation relationships).
Example 1: Grouping
A location is a place or position where structure elements can be located or behavior can be performed.
The location element is used to model the places where (active and passive) structure elements such as business actors, application components, and devices are located. This is modeled by means of an aggregation relationship from a location to structure element. A location can also aggregate a behavior element, to indicate where the behavior is performed. This element corresponds to the “Where” column of the Zachman framework [5].
Figure 18: Location Notation
Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Bookstore as document C179.
