On Layers and Abstraction Levels in the ArchiMate Language
Oct 9, 2019
Our recent blog post on abstraction levels in architecture models resulted in a lively discussion on LinkedIn. As part of that discussion, the notion of layering was questioned, and in particular the layers that are built into the ArchiMate language. In this post I want to clarify the thinking behind the language structure.
The main reason for introducing layers or levels in general is to reduce the complexity of the world you are describing. Such layers are a convenient way of discretizing some dimension that may be (nearly) continuous. Dividing up a gradual range of possibilities in discrete buckets makes it easier to grasp what’s happening. In general, that’s what people do: we classify the world out there in understandable categories, labeling e.g. furniture as tables or chairs, even though there may be tables you can sit on or chairs you can eat from.
In our enterprise architecture discipline, you see this in the TOGAF Enterprise Continuum, for example, which is discretized into four levels. ArchiMate was also influenced by layered architecture approaches such as the OSI model, centered around the notion of ‘service’ at different (in OSI’s case 7) abstraction levels. This is one of the reasons for the prominence of the service concept in ArchiMate and for the ways its core layers are connected.
Now there are many different dimensions along which you can position the models of your enterprise (or of the world in general): generic vs. specific, abstract vs. concrete, low vs. high granularity, approximate vs. precise, functional vs. constructional, implementation-independent vs. -specific, descriptive vs. prescriptive, uncertain vs. certain, intent vs. effect, and more. In theory, all these dimensions should be treated as independent and orthogonal (unless proven otherwise). However, that would give us a multidimensional hypercube as the framework for our modeling approach, which is just too complicated for practical use.
Moreover, in practice you see that many of these dimensions are correlated: some design usually progresses from an abstract, high-level, generic, approximate, implementation-independent idea to a concrete, detailed, specific, and accurate specification and realization. So even though in theory these dimensions are orthogonal, not all possible combinations will occur in practice.
For these two reasons – simplicity and correlation – approaches like ArchiMate conflate some of these dimensions and discretize them in fixed levels. You also see that very explicitly in the Zachman framework, for example, which labels its dimensions in two ways: both with the abstraction levels and with the intended stakeholders, the underlying assumption being that certain stakeholders are only interested in certain abstraction levels.
This conflation of dimensions may not be correct in a formal sense, but it is often good enough for practical purposes. Moreover, a model can only be an approximation of reality anyway; as George Box famously quipped, “all models are wrong but some are useful”. So what really counts is whether the set of abstractions in a particular approach fit your modeling purpose, letting you create models that are ‘close enough’ to be of use.
Finally, in an enterprise architecture discipline that has a strong IT focus, the progression along these dimensions is often towards an IT implementation. ArchiMate was designed for mainstream practice and also to align with other methods in the field (like TOGAF), which is why it has somewhat of an IT bias too (although less so in more recent versions of the language). You might argue that ‘true’ EA should focus on the entire enterprise and not just the IT-related aspects (and I sympathize with that position), but in designing the language, we didn’t aim to change the discipline’s scope.
This progression towards IT implementations is visible in ArchiMate models where you move from Motivation elements (with e.g. stakeholder and their goals) via the Strategy layer (e.g. capabilities and resources), to the Business layer (business services and processes, organization structure), the Application layer supporting the business (application services, components etc.), and the Technology layer underpinning those applications. Note that ArchiMate does allow you to model non-IT aspects, both on the organizational side and in the physical world (the latter since version 3.0) but most practitioners are in the IT world and use it for IT-related purposes.
Above I mentioned the progression over time from design to implementation. We can position the ArchiMate language on this continuum from high-level idea to realized solution. No single modeling approach will cover all of that in its entirety and different methods have a different position. ArchiMate is currently positioned somewhat more ‘to the left’ than UML or BPMN on that axis, but still towards where designs have already crystallized somewhat. A nice visualization of this is given by the Process of Design Squiggle by Damien Newman, https://thedesignsquiggle.com/:
We may want to extend the language to support more of the early, exploratory stages, to the left in the figure. In line with what I mentioned about the progression of designs above, that would mean extending the language with more generic concepts or mechanisms. This will require some serious thought, since such an extension should not add undue complexity for users, be in keeping with the current structure and principles of the language, and be backwards compatible with previous versions to provide an easy upgrade path. Now that the new ArchiMate version 3.1 is about to be released (a minor update to the language), we can start thinking about such major, longer-term improvements and extensions. I’d be interested to hear your thoughts on this!
