ArchiMate® 3.2 Specification

The ArchiMate language, as described in this standard, complements the TOGAF framework [4] in that it provides a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model “below the waterline”, which can be depicted in the form of TOGAF views.

The structure of the ArchiMate core language closely corresponds with the three main architectures as addressed in the TOGAF ADM. The strategy, motivation, implementation, and migration elements approximately map onto the remainder of the ADM (although these elements may also be used in Phases B, C, and D). This is illustrated in Figure 116. This correspondence indicates a fairly easy mapping between TOGAF views and the ArchiMate viewpoints. A more detailed description of this correspondence is given in [6].

Although some of the viewpoints that are defined in the TOGAF Standard cannot easily be mapped onto ArchiMate viewpoints, the ArchiMate language and its analysis techniques support the concepts addressed in these viewpoints. While there is no one-to-one mapping between them, there is still a fair amount of correspondence between the ArchiMate viewpoints and the TOGAF viewpoints and many viewpoints from both address largely the same issues. Moreover, the viewpoint mechanism described in Section 13.4 lends itself well to define TOGAF viewpoints using ArchiMate concepts.

It is important to reiterate that the ArchiMate Standard is a modeling language and not a framework. Therefore, the viewpoint definitions are more detailed and specify the stakeholders, concerns, level of detail, or abstraction level, and the entity types involved in the viewpoints. In the TOGAF Standard this is presented in a more general way. Therefore, some interpretation or transformation will be required.

In conclusion, the TOGAF and ArchiMate Standards can easily be used in conjunction:

See [6] for a detailed explanation of how the TOGAF and ArchiMate Standards can be used together, including how to create a minimal ArchiMate based metamodel, which covers the whole ADM cycle.

The ArchiMate language provides many concepts that are suitable for modeling Business Architectures. The core domains outlined in the BIZBOK Guide [18] – capabilities, value streams, organization, and information – are explicitly covered by relevant concepts in the Business Layer and strategy elements of the ArchiMate language. The other domains – stakeholders, strategies, policies, products, initiatives, and metrics – can also be described easily using appropriate ArchiMate concepts. The language supports key Business Architecture techniques such as capability mapping, organization mapping, information mapping, and value stream mapping, and with its extensive set of relationships it also covers the interconnections between these domains such as value stream – capability cross-mapping; e.g., see Example 21.

More advanced descriptions are also possible. In the TOGAF Series Guide: Value Streams [17] and the BIZBOK Guide, value streams are decomposed in a specific way. Stages in a value stream are not connected via relationships where value is exchanged, as in Example 21. Rather, the stages produce value items that are aggregated at a higher level into an overall value proposition, and the entry and exit conditions for each stage are specified explicitly. In the ArchiMate language, the former can be modeled with aggregation relationships and the latter using constraints.

The general approach in the design of the ArchiMate language is that it has some overlap with other modeling languages. Concepts that are shared between two languages can be used to bridge the gap and create integrated sets of models. This idea is illustrated in Figure 117.

This way, an ArchiMate model functions as a high-level “umbrella” that ties together different models at more detailed levels. From your Enterprise Architecture level, you can drill down into detailed models of specific aspects, and vice versa. The next sections illustrate this in more detail for the BPMN, UML, and BMM standards.

Both the ArchiMate language and BPMN [12] can be used for modeling business processes. Their aims are different, however. ArchiMate notation is typically used for high-level processes and their relations to the enterprise context, but is not intended for detailed workflow modeling, whereas BPMN supports detailed sub-process and task modeling down to the level of executable specifications, but lacks the broader enterprise context, for example, to model the application services that support a process or the goals and requirements it has to fulfill.

Both languages share the concepts of (business) process and event. In the ArchiMate notation there is a single business process element that may be decomposed in other processes that are related using flow and triggering relationships, possibly using junctions to represent more complex connections. BPMN has a more fine-grained set of elements, with various types of events, tasks, and gateways. Its metamodel also distinguishes explicitly between process and sub-process (although it lacks a graphical representation of a business process itself). The BPMN concept of participant (or pool) and the ArchiMate concepts of business role or business actor (or application component for automated processes) also correspond.

In a typical scenario, both languages can be used in conjunction. Mapping from ArchiMate notation down to BPMN is fairly straightforward. The other way around loses the detailed elements of BPMN. Moreover, there are structural differences between the languages that preclude a direct concept-to-concept mapping and may merit a pattern-based approach. A detailed description of such a mapping is beyond the scope of this standard.

The ArchiMate language has derived a number of concepts from UML [8]. For other concepts, straightforward correspondences can be defined.

In the Business Layer, the ArchiMate business process concept can be mapped onto UML activity diagrams, where more detailed specifications of such processes can be given (although BPMN would be the preferred language for detailed process and workflow modeling). The ArchiMate business actor and role concepts can both be mapped onto UML actors, although the latter can also be used for modeling automated actors. Business collaborations have been inspired by collaborations as defined in the UML standard [8], although the UML collaborations apply to components in the Application Layer.

In the Application Layer, the application component element corresponds to the UML component. This facilitates the direct linkage between higher-level Enterprise Architecture models described in ArchiMate notation and lower-level solution architecture and implementation models in UML in one continuous development chain. In a less direct manner, the ArchiMate application function concept can be mapped onto UML activity diagrams, and an application service to a use-case diagram. Application collaborations also correspond to UML collaborations.

Many of the elements of the ArchiMate Technology Layer correspond directly to UML. The node, artifact, device, system software, and path elements have a direct counterpart in UML (where system software is called execution environment).

In addition to these elements, many relationships in the ArchiMate language have close ties to UML as well. The ArchiMate association, composition, aggregation, specialization, and realization relationships have a direct counterpart in UML.

There are also some notable differences between the two languages. The ArchiMate serving relationship (formerly “used by”) is different from UML dependency. Although their notations are similar, their directions are different. UML dependency is often used to model, for example, function calls in software programs, but in ArchiMate notation, the direction of the serving relationship denotes the direction of service delivery, independent of whether this service is called by the user or offered pro-actively by the provider. At the architectural level at which the ArchiMate language is aimed, the run-time operational details of such call graphs are less important than the more stable and generic notion of service provision.

This also points to another important difference: UML does not have a separate service concept, since in its object-oriented paradigm the behavior expressed by a service is encapsulated within the interface offering that behavior (i.e., its operations). The ArchiMate language differentiates between interfaces and the services they provide to allow, for example, specifying that the same service is offered through multiple interfaces. Hence, an ArchiMate application interface does not equate directly with a UML interface.

Finally, UML has a predefined, fixed set of diagram types, whereas the ArchiMate viewpoint mechanism allows for the construction of custom, stakeholder-oriented views on an architecture.

See [16] for a more detailed explanation about how the UML language and the ArchiMate standard can be used together.

The ArchiMate strategy and motivation elements have been inspired partly by the Business Motivation Model (BMM) [15]. BMM distinguishes between means, ends, and influencers and assessments. It provides fairly detailed concepts for these categories. The ArchiMate course of action element corresponds directly with the course of action element in BMM, whereas its directive concepts can be modeled with the ArchiMate principle, requirement, and constraint elements.

BMM concepts for modeling ends are typically mapped onto the ArchiMate goal element. Its influencers correspond to the ArchiMate element of driver, whereas its assessments map directly onto the ArchiMate assessment element.

Although a mapping between many of the ArchiMate motivation and implementation elements and BMM concepts is possible, BMM provides a more detailed, fine-grained description of business motivation. In that sense, it is comparable to the other languages described in this appendix. Where the ArchiMate language aims to cover a broad scope and interlink various domains, these more specialized languages zoom in on the details of their specific domains.