ArchiMate can be used for holistic enterprise development purposes, as ArchiMate provides concepts that cover all the most relevant aspects of overall modelling. ArchiMate contains lots of elements, what makes it very powerful notation. However, only a subset of ArchiMate elements can be used for most of the cases – according to Pareto’s law (80/20 rule). The most relevant elements and relation types are illustrated in the meta-model diagrams below.
An ArchiMate meta-model can be applied to fit for purpose, to be aligned to what is appropriate. Idea behind a metamodel is to introduce those elements that are relevant, with which most of the cases can be modelled. Here is introduced 1) Core Meta-model, 2) Full Meta-model.
1. ArchiMate Core Meta-model
Note:
- The relation from “Node” to “Application Component” can be either “serving” or “realization” (according to derivation rules)
- These elements can be applied to most of the modelling cases (80%), added with relation type “Flow” (between actors, processes and applications).
3. ArchiMate 3.1 Full Meta-model
This meta-model (with simplified relations) below introduces also Motivation- and Strategy-elements (on the left side).
Note:
- Motivation elements (on the left) can be realized by Strategy and/or Implementation elements (bottom left), those of which can be aggregated from core structural and behavioral elements (on the right).
- Some relations are not visible on the diagram above (for the sake of simplicity), but those can be derived from the other relations – according to the ArchiMate derivation rules (link).
- “Process” element can be replaced with “Function” (e.g. Business Process -> Business Function, Application Process -> Application Function, Technology Process -> Technology Function).
- Two roles of “Product”: 1) composition of Business/Application/Technology Services and 2) implementation construct, which consists of behavioral and structural elements. (“Product” is slightly problematic concept in this diagram, as it is placed on implementation view, for the sake of agile development approach..)
Relationships
Relationships are introduced more detailed in the ArchiMate specification (link).
ArchiMate Metamodel Use Cases
Analysing & Planning WHY, HOW, WHAT
1. Start With WHY…
This metamodel encourages analyzing first the WHY question, then HOW, and finally WHAT. This approach is inspired by Simon Sinek’s “start with why” -concept (see introduction here). ArchiMate provides elements for each of those steps for thinking & modelling what is essential. The left side of the metamodel covers the WHY and HOW parts. With ArchiMate concepts such as Driver and Assesment, it is possible to identify the relevant elements for analyzing WHY something really important. The ArchiMate Stakeholder-concept can be used fore identifying the interest groups that have some concerns related to this specific development target.
2. HOW To…
After analyzing why something is important and essential, then the necessary steps to be taken can be analyzed with the rest of ArchiMate Motivation concepts. Those are: Goal, Outcome, Principle, Requirement. In addition, ArchiMate Strategy-concepts Course of Action, Capability and Resource can be used for modelling with which actions and with which resources it is possible to get certain abilities.
3. WHAT is the context…
The right side of this metamodel contains the behavior and structure concepts of ArchiMate. This metamodel introduces a subset of ArchiMate concepts, aiming to illustrate the most useful concepts only that are common to most of the cases. These concepts enable modelling what are the contextual elements for defining what building blocks there is, and if necessary, what there should be. Both as-is and to-be architectural views can be modelled with these core ArchiMate elements. Of course, other ArchiMate core concepts that are not introduced here, can be used when appropriate.
Capability-Based Planning (CBP)
This metamodel introduces how capabilities could be derived from Motivation -level concepts. As such, ArchiMate highly supports Capability-Based Planning (CBP) approach. It is necessary to analyze first the drivers and goals, and then identify what are the required capabilies. (For more details e.g. here).
Service-Driven Approach (SDA)
This metamodel illustrates how ArchiMate language promotes the concept of “service” as primary unit of behavior (functionality), note Business Service-, Application Service- and Technology Service concepts. Service-Driven Approach (SDA) for enterprise development focuses on “services” instead of projects, applications or technologies. Rather, the SDA encapsulates all the customer and business driven demands within a service. As a “service” can be associated with business value, that makes “service” the most important element of overall enterprise development. Note that a value can be associated with an outcome and with all core elements of an architecture as well as with outcomes (ArchiMate).
Microservices, Event-Driven Architecture (EDA), Robotics, AI etc.
New ArchiMate concepts such as Application Process and Application Event enable modelling of new important architectural things. For example, microservices and events they throw, automatized processes etc.
Holistic View
All in all, this metamodel supports the holistic view of overall enterprise development. This metamodel aims to interconnect elements between ArchiMate Motivation aspect with core layers (biz, app, tech). This can be achieved by utilizing the Motivation- and Strategy-concepts, and also by using implementation concepts Work Package and Deliverable, as well as e.g. Product -concept that is common to agile methods.
A holistic view can be taken by utilizing all these ArchiMate concepts, which can be linked together to model the trace from abstract goals to concreteness: from WHY to WHAT.
For more detailed modelling examples check: