The ArchiMate Specification, an Open Group Standard, is an open and independent modeling language for Enterprise Architecture modeling. This article provides a highlight on what is new in the ArchiMate 3.1 Specification which is a minor update to the ArchiMate 3.01 published in June August 2017.
Despite being ‘just’ a minor version update, it holds a number of useful additions and improvements for Enterprise Architecture practitioners.
The three most important improvements to the standard are:
Value streams are typically realized by business processes and possibly other core behavior elements. The stages in a value stream provide a framework for organizing and defining business processes, but different parts of the organization may have their own implementations of business processes that realize the same value stream stage. Conversely, one business process may realize multiple stages in a value stream.
Value Stream represents a sequence of activities that create an overall result for a customer, stakeholder, or end-user.
Value streams may be defined at different levels of the organization; e.g., at the enterprise level, business unit level, or department level. Value streams can be a composition or aggregation of value-adding activities. These are also modeled with the value stream element and are known as value (stream) stages, each of which creates and adds incremental value from one stage to the next. These stages are typically related using flow relationships to model the flow of value between them. Resources can be assigned to value streams and capabilities can serve (i.e., enable) a value stream.
The example below shows a model of a high-level value stream for an insurance company, where each stage in the value stream is served by a number of capabilities. Between these stages, we see the value flows with associated value items, and at the end the business outcome that this value stream realizes for a particular stakeholder.
Between the stages of the value stream, we see the value flows with associated value added by each stage, and at the end the business outcome of ‘well-founded decision-making’ that this value stream realizes for a particular stakeholder. Each stage in the value stream requires a number of capabilities, shown below the stages and also exhibiting how you can use the improved grouping concept to model this cross-mapping efficiently.
Resources can be assigned to value streams and capabilities can serve (i.e., enable) a value stream. This supports the common technique of capability–value stream cross-mapping, where you identify which capabilities the enterprise needs or uses to support the stages in a value stream.
The addition of a directed association relationship is a small improvement with great potential. One common use-case is to express navigability. An association relationship is always allowed between two elements, or between a relationship and an element. The association relationship can be used when drawing a first high-level model where relationships are initially denoted in a generic way, and later refined to show more specific relationship types.
For example that an insurance policy refers to the insured asset but not the other way around.
The Example below illustrates two directed association relationships between a contract and two business objects to which this contract refers. It also shows an association between a flow relationship and this contract, to indicate the kind of information that is communicated between the two functions.
In the ArchiMate language, you can derive indirect relationships between elements in a model, based on the modeled relationships. This makes it possible to abstract from intermediary elements that are not relevant to show in a certain model or view of the architecture and supports impact analysis. This is a more specialized subject that for most of you will be hidden inside your ArchiMate tools. These additions in ArchiMate 3.1 specification also introduces refined rules for the derivation of relationships.
For example, if A contains B and B contains C, A by definition contains C (using the composition relationship). This derivation is always valid.
Derivation of relationships is intended as a way to create summaries of detailed models. It is a way to remove (to abstract from) details in a model, while still making valid “statements”. Hence, derivation is always meant to go from more detail to less detail. This mechanism is one of the unique properties of the ArchiMate language compared to other modeling languages.
In Example below, assume that the goal is to abstract from the application functions, sub-functions, and services in the model. In this case, an indirect serving relationship (thick red arrow on the right) can be derived from “Financial Application” to the “Invoicing and Collections” business process (from the chain assignment – composition – realization – serving).
Derivation of relationships is intended as a way to create summaries of detailed models. It is a way to remove (to abstract from) details in a model, while still making valid “statements”. Hence, derivation is always meant to go from more detail to less detail. This mechanism is one of the unique properties of the ArchiMate language compared to other modeling languages.
ArchiMate language defines four categories of relationships, each of which can connect a predefined set of source and target concepts. The relationships are classified as follows:
The Table below gives an overview of the ArchiMate relationships with their definitions.
| Structural Relationships | Notation | Role Names | |
| Composition | Represents that an element consists of one or more other concepts. |  |
← composed of → composed in |
| Aggregation | Represents that an element combines one or more other concepts. |  |
← aggregates → aggregated in |
| Assignment | Represents the allocation of responsibility, the performance of the behavior, storage, or execution. |  |
← assigned to → has assigned |
| Realization | Represents that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity. |  |
← realizes → realized by |
| Dependency Relationships | Notation | Role Names | |
| Serving | Represents that an element provides its functionality to another element. |  |
← serves → served by |
| Access | Represents the ability of behavior and active structure elements to observe or act upon passive structure elements. |  |
← accesses → accessed by |
| Influence | Represents that an element affects the implementation or achievement of some motivation elements. |  |
← influences → influenced by |
| Association | Represents an unspecified relationship, or one that is not represented by another ArchiMate relationship. | |
associated with ← associated to → associated from |
| Dynamic Relationships | Notation | Role Names | |
| Triggering | Represents a temporal or causal relationship between elements. |  |
← triggers → triggered by |
| Flow | Represents transfer from one element to another. |  |
← flows to → flows from |
| Other Relationships | Notation | Role Names | |
| Specialization | Represents that an element is a particular kind of another element. |  |
← specializes → specialized by |
| Relationship Connectors | Notation | Role Names | |
| Junction | Used to connect relationships of the same type. |  |
|
