ArchiMate relationships point in the same direction as the enterprise
When I give a presentation to a technical audience showing any kind of picture with an arrow in it (not necessarily an ArchiMate diagram), more often than not, someone will raise their hand and ask: “What does that arrow mean?” When I answer, they will follow up with “Shouldn’t it be the other way round?” Of course, when two things have a relationship you can always view that relationship from either end, so there is no ‘right’ way of choosing a direction; you have to make a conscious choice. In this blog, I want to clarify the choices on relationship directions that we made in the design of the ArchiMate language.
Serving
Perhaps the most contentious one is the ‘serving’ relationship (or ‘used by’ as it was called before ArchiMate version 3.0). This points from the element that provides some functionality to the element that consumes it. For example, in the figure below we see application services connected to a business process in this way.
Figure 1. Serving relationships point in the direction of service delivery.
To most business people, this is a direction that makes sense, since it shows the direction in which a service is delivered, independent from the specifics of that delivery.
However, software architects and developers that have been exposed to UML sometimes confuse this with UML’s dependency relationship, which may point in the opposite direction since it is often used to model a call graph that shows, for example, a software application calling (the services of) another application. But at an architecture level of abstraction, the specifics of the order in which services are called are less significant than the direction of delivery.
Moreover, the same service, certainly at the business level, can often be provided both proactively, where the initiative lies at the provider end, and reactively, where the consumer takes the initiative. These detailed communication patterns will be reflected in more fine-grained models of the implementation, but usually not in a description of the enterprise architecture.
Influence
Another relationship that is sometimes cause for discussion, is influence. As the standard says, “influence is used to describe that some architectural element influences achievement or implementation of a motivation element” (Sect. 5.2.3). It therefore points in the direction of this motivation element that models what the enterprise wants to achieve. The same holds for the realization of motivation elements; this relationship points towards these elements as well.
So, for example, if a business process helps to realize a requirement, the influence or realization relation will point towards that requirement.
But if you think about requirements as ‘governing’ or ‘constraining’ some implementation, then you may argue it should point in the other direction. Again, there is no right or wrong in this discussion, but ArchiMate has made a clear and consistent choice here: influence points from the ‘means’ to the ‘ends’.
Figure 2. Influence relationships point towards what you want to achieve.
Assignment
A third relationship for which its direction may confuse some users is assignment. Since ArchiMate version 3.0, this has a directed notation.
In general, this direction is from active structure elements to the behavior they execute, and within the business layer from business actors to the roles they play. Again, this direction was chosen because it points towards what the enterprise wants to deliver: active structure elements perform behavior that in turn realizes products and services, to serve customers and achieve the goals that have been set.
Of course, this direction towards desired results also holds for triggering and flow, which, by definition, point from start to end, towards the output you want to get from, say, a business process. No discussion there.
Figure 3. Resources are realized by core elements and assigned to capabilities, which realize the courses of action and outcomes of the enterprise, which contribute to its goals, which in turn satisfy its drivers.
If you put this all together, you will notice that ArchiMate models have a consistent direction to them, towards the goals and results of the enterprise:
- from work packages (e.g. projects and programs) and deliverables to things they realize in the core of the architecture (e.g. business processes, software applications and technical infrastructure)
- within this core from the underlying technology to the business being supported or realized
- from the active structure to the behavior that is performed, and within this behavior from start to end
- from the architecture core to the strategic capabilities and resources that are realized by this core
- from there to the courses of action the enterprise takes in employing those capabilities and resources to achieve the desired results
- from core and strategic elements to requirements, constraints and principles that have been defined to give direction to the development of the enterprise
- from all these elements to the goals and outcomes that the enterprise wants to achieve
- and ultimately from there to the drivers that cause the enterprise to define these goals
Summary
ArchiMate relationships may seem confusing at first, but their consistent design provides clarity once you understand the underlying principle: they always point toward enterprise goals and results. From serving to influence to assignment, the language reflects the journey from capabilities and resources to outcomes and drivers. For architects, keeping this in mind ensures models remain meaningful, aligned with strategy, and effective in guiding enterprise transformation.
FAQs
Because they emphasize the direction of service delivery—what is offered to the business or application process consuming it.
Influence points from the element providing impact toward the motivation element, aligning means with the ends an enterprise wants to achieve.
Always ask: Which end of the relationship is closer to the enterprise’s goals or desired outcomes? That’s usually the direction ArchiMate points.
