Gerben Wierda, our On Slippery Ice columnist, author of the Mastering Archimate series of books and recognised thought leader on the use of the Archimate language, brings us an insightful view of the new release of Archimate, version 3.0.
ArchiMate 3 – Richer, with new capabilities
ArchiMate 3 has recently been released. It is the third (fourth, if you count the original R&D project) release of what can certainly be said to be the major Enterprise Architecture modelling language in the world. Note, being ‘major’ still does not say much: most architecture is stil illustrated with (we cannot call this modelling) free graphics such as Visio or OmniGraffle documents or even Powerpoint slides. [Note: if you haven’t been working with ArchiMate yet, go to this link and get the free Syntax Excerpt of the Mastering ArchiMate book, still ArchiMate 2.1, but you’ll get the basics which haven’t changed very much.]
Now that ArchiMate 3 is out, and ArchiMate is nine years old, we should expect it to have matured. And indeed, it has now become rather rich with its 56 different types of elements. It has become a bit bloated, it seems, but then we should acknowledge that these elements are not all for the same use or domain and you will probably not use them all and almost certainly not use them all at the same moment.
If you look closely, you see that ArchiMate offers support for modelling four (related) aspects of enterprise architecture:
- To model the actual enterprise, with its processes, roles, behaviour, IT and — since ArchiMate 3 — the physical world, there is the Core which has been there since the beginning of ArchiMate. It is what ArchiMate makes an Enterprise Architecture language in the first place, because you can model all these different aspects in a single coherent model.
- As of ArchiMate 2, to model the intentions of an architecture (the ‘why’) there is the Motivation section (Drivers, Goals, Requirements, Principles, etc.). In ArchiMate 2 this was called the Motivation Extension.
- As of ArchiMate 2, the change of the actual enterprise, is modelled with the Implementation and Migration elements. In ArchiMate 2 this was called the Implementation and Migration Extension. We might call this the Change section of ArchiMate.
- And, as of ArchiMate 3, to model the strategy of the enterprise, there is the Strategy section of ArchiMate (Capability, Resource, Course of Action)
So, in short, we have:
- The Enterprise (ArchiMate: Core elements)
- The Change of The Enterprise (ArchiMate: Implementation and Migration, siblings of core elements)
- The Strategy of The Enterprise (ArchiMate: Strategy, abstractions of core elements)
- The Intention of The Architecture (ArchiMate: Motivation)
Then, in ArchiMate, there is the fundamental separation into active structure (who acts), behaviour (what act), and passive structure (upon what), resembling subject, object, and verb of natural language. And within active structure and behaviour (in the core language) there is the split between the visible/external and the invisible/internal, e.g. the split between the business service and the behaviour (e.g. process) that realises it or the application and its interface.
In a picture, adapted from the full framework picture in the standard:
The standard itself shows the structure differently, clearly marking the BAT layers from ‘orthodox’ enterprise architecture (again, adapted, e.g. the colouring is mine, I prefer to colour the aspects more than I prefer to colour the layers):
(In the standard, by the way, Technology and Physical are presented fully separated like the other layers, but I’ve taken the ’attached’ way of displaying the Technology and Physical layers from Marc Lankhorst’s presentation at NAF, recently. It is better than the one in the standard itself, because both layers actually share elements.)
Now, this is a major update, so I can’t discuss everything. Here are some highlights.
Notable changes
ArchiMate 3 has a big improvement under the hood, something ordinary users will not notice that much: the specification now contains an improved description of the metamodel.
This metamodel also contains two very often requested additions:
- Capability
- Modelling the physical world
Capability
Capability is part of the new Strategy domain of ArchiMate and in ArchiMate it is positioned as an abstraction. Personally, I’ve always favoured a more concrete/tangible style of modelling, where even a Capability is just a composition/aggregation of elements of the enterprise. The ArchiMate designers, however have a more abstraction-oriented approach. Even a service is seen as an abstraction of sorts, not something tangible. For service or capability, the choice between abstraction and construction isn’t a big deal though, in the end you can express both. In other places it does matter: abstraction has the tendency to create multiple occurrences of the same ‘thing’ in your model, one for each abstraction. Something likewise happens in ArchiMate with Stakeholder (from the Motivation domain) and Role from the Core, where if a Role is also a Stakeholder, you have to model the same thing in both places and the language doesn’t come with a way to link them up properly. I’ve long proposed that the language should be more constructive/integrated and less abstract/‘replicating’, but here the designers and I disagree.
Anyway, ArchiMate 3 takes the approach that strategy is an abstraction that is realised by the enterprise. Capability is thus positioned as something that is part of the strategical view on the (development of the) enterprise, and is thus placed in this abstract layer. It is also purely behavioural. In ArchiMate, this is an important distinction. Many architects for instance see a ‘function’ as some abstract ‘actor’ in the enterprise that performs some behaviour and the function is the ’embedded’ behaviour. In ArchiMate, a function is purely behavioural. It does not perform anything, it is performed (by some ‘acting’ element). So, when a Capability is behavioural in ArchiMate, something needs to make that behaviour happen, and that in ArchiMate is a Resource. So, we have Resources assigned-to Capability. Interestingly enough, here, the split between active and passive structure is gone — so ArchiMate’s summary ‘map’ shown above is technically incorrect. Some may find that irritating, but I think it more shows that ArchiMate is not a logical structure, but a practical structure (though many logical arguments have gone into the discussions that resulted in the grammar).
As said before, this abstraction approach means that the same thing can be seen several times in a single model. In an example:
It will be hard for people to understand the difference between both layers, I think, and some will wonder why you need both. Luckily we may use ArchiMate’s ‘derived’ relations to summarise. So, we could forget about modelling the Resources as such and do something like:
which comes pretty close to the idea of a capability as some sort of collection (of people, material, skills, etc.) in your enterprise. It’s a matter of taste, I guess. If you like the Resources idea and the abstraction away from the actual enterprise enough, you won’t be bothered that the same things is modelled twice. Besides, the granularity of the whole strategy modelling will generally be far less than the granularity of modelling the real enterprise, so in realistic situations you might want to actually use some sort of grouping into some sort of collection/abstraction. And then you could use the new/improved Grouping element or you could use Resource. Or you could Resource to model skills. Or (etc. etc. etc.), as in any language, there are endless ways to write the same thing.
Anyway, if I make a more complete picture:
I now have 7 elements representing the Ledger (and I could have expressed the printed Ledger as Material, even), with some clearly useful for expressing a clearly different aspect and some clearly overlapping, even being completely equivalent. I show this to illustrate that there is enough rope in ArchiMate to hang yourself by. That doesn’t mean it is useless, just as a big toolbox with a lot of slightly overlapping tools isn’t useless, but it pays to learn to use the tool properly. It also illustrates that the full complexity of ArchiMate is probably not something you want to get exposed to management.
Modelling the physical
The only element that ArchiMate had from its inception that was intended to represent any form of material passive object was Representation (seen in the above example). The idea was that in information-heavy enterprises (something ArchiMate was invented for), you would sometimes have something on paper (physical) too, the office yet being far from ‘paperless’. With ArchiMate being so IT/information-oriented, people wrestled with ArchiMate when they needed to model physical aspects of enterprises. This problem has become more urgent, now that the ubiquitous marriage of IT and ‘stuff’ is becoming important (think “Internet of Things”, robotics and so forth).
ArchiMate 3 repairs this gap by supporting the modelling of the physical side of enterprises as well. For this, the Technology layer (formerly IT Infrastructure layer) has been extended with concepts to model the physical side. These are Material (the physical sibling of Artefact; Artefact represents bits/bytes), Equipment (the ‘physically operating’ sibling of (computing) Device), Facility (specifically meant to model physical environments, such as factories, but with a focus on providing an environment for physical activities). These elements together will allow modellers to model physical production, especially. An example could be: 
Here, we have a factory assembling Daleks. To assemble these, we need a pre-assembled mechanical body and a pre-grown biological brain (the computer module) which are sent from the warehouse. When these are sent from the warehouse to the factory, a message is being sent as well that they are on their way, so the factory can do its planning. As the example above shows, you can now do all sorts of modelling of the physical side.
Now, this part of the update to the standard is still rather raw and new. It would go too far to list all of the kinds of large and small issues here, but as an example, let’s illustrate some of these.
First, In the picture above, there is already something special going on. After all, in ArchiMate’s metamodel, Material can be Assigned to a Facility and a digital Artefact can be Assigned to System Software, both meaning “resides on”, but here we see that a digital Artefact can be Assigned to a Facility. Why? This is because in the metamodel, System Software is a specialisation of Node and any Node may Compose any other Node. Facility is also a Node, so we are allowed to do Facility Composes System Software (which is Assigned-To Artefact). Which is fine. But we also can do System Software Composes Facility (which is Assigned-To Material). Which is silly. Which only proves once more that you cannot create meaning or guard against nonsense via purely syntactical mechanisms. That is a failed dream, a dream that was already destroyed last century, mainly by Uncle Ludwig.
Second, other interesting connections in the maze of elements and relations are possible too, and some may even be quite intuitive if you see them, but that may be a coincidence. Take the picture below:
The Factory is Assigned to a Business Process. Normally a Role is Assigned to a Business Process to signify the Role performs the Process. Facility performs Process makes sense from our perspective of course. After all, it is the Facility with its Equipment that performs the (fully automated) Business Process. However, the reason that we are allowed to create this Assignment in ArchiMate has quite a different origin. Assignment is also used for ‘resides on’. E.g. an Artefact can reside on System Software (a file can reside on an operating system). And, as shown above, Material can reside on a Facility. Now, in the metamodel we also have an Actor ‘residing on’ a Facility (kind of an overlap with Location). And since an Actor can perform a Business Process (performing is also expressed by Assigned-To) we have Business Process is Assigned from (performed by) Actor which is Assigned from (resides on) Facility). Assignment even has a third meaning: fulfills.
Before going on I have to briefly explain ArchiMate’s interesting concept of derivation. This is easiest to do with an example:
Here you see a Node (a server of sorts), providing a service (say, a file share) which is used by an application, which in turn provides a service (say editing a file) that is used in a business process (say answering a letter). A lot of detail that you often do not need. But ArchiMate has a mechanism that lets you calculate ‘summary relations’ from one end to the other. In this case, that relation (in red) is ‘serves’ (formerly used-by’) and it means we can conclude that the server is used by the process and if we have a model with all these dependencies, that we can draw useful conclusions.
Now, back to our Assignments:
The ‘summary’ relation is also Assigned-To. But what does it mean? And in these kind of situations, how do I answer the question “who performs the process?”. I would say in this case “The Actor performs the Process at the Facility”. So the red ‘summary’ doesn’t really say ‘performs’ at all.
What all of this shows is that something as complex as ArchiMate and with the goal of ArchiMate (being able to model ‘everything’) almost by necessity has ‘issues’. Is that bad? I would say, no. Only purists will have problems. But it does become important to watch your step, to learn the language well before using it, and to make sure you use well agreed-on patterns so people know what you mean. A grammar (which is what ArchiMate is) does not equate to (clear) meaning. Uncle Ludwig again.
Back to our physical example. We might add the networks explicitly and we can now model both a communication network and a physical distribution network. I’ve let these Realise the ‘Warehouse Distribution’ together:
Another option would have been to let the Assemble Dalek (Technology Process) Realise the (abstract) Produce Daleks (Business Process). But the derivation of that route produces a Realisation from Facility to Business Process, not an Assignment. Confused already? Don’t be. Think of it as the way some authors (Germans seem to particularly good at it, like Thomas Mann who writes sentences as long as paragraphs or Heidegger who invents his own language and thus becomes rather difficult to follow for the rest of us) can create confusing and complex sentences and paragraphs. Would you blame the language? Or should you blame their way of writing, or your lack of command, or both?
Other notable things
Another thing to notice is: TOGAF seems to be invading ArchiMate a bit more every time there is a new release under TOG’s guidance. I’ll give a small example: ArchiMate now allows Application Components Realising Application Components. It is nowhere explained in the text of the standard, but I’ve got it from a reliable source that this has been done to give the TOGAF people a way to express the difference between ‘physical application’ and ‘logical application’ within ArchiMate’s application layer. It is also yet another way of expressing abstraction in the language. Not a bad thing, if you like TOGAF’s way of describing IT landscapes of course (and many do). It thus adds to the richness, but it also adds to the drawbacks of the richness. As Ric Phillips commented quite astutely on my other review:
[…] there is an inverse relationship between semantic ambiguity and structural complexity in all languages. The more formally closed and precise one tries to be the more complicated and unreadable the language gets. Look at any legal document.
Quite right. So dreams of a simpler language could well hit a road block in that it doesn’t help enough to create the structure we need for for instance analysis of models. E.g. in an example from the infrastructure domain: if every type of device is a Node, how can you create models that show clearly the different types of devices, each of which have a different role: servers, firewalls, switches, routers, load balancers, and so forth? It is not for nothing that most IT infrastructure architects use Visio and a set of forms depicting all these different types of devices? It helps their communication needs.
Going back to that abstraction, we could in fact argue that it should be possible to abstract anything in a model with the Realisation relation, not just Application Components. Such things have already been introduced, e.g. Application Process can now Realise a Business Process to signify a Business Process is automated. That way of modelling makes the Business Process an abstraction of the Application Process.
In this area, ArchiMate remains a curious mix of concrete (humans performing a business process) and abstract (machines realising a business process).
Conclusion
As I’ve written elsewhere in a more detailed and critical technical review, ArchiMate is very rich but it also has become a bit ‘overcrowded’. That overcrowding is sometimes preferable to not having some of these new elements at all, and yet, misusing existing IT-oriented elements to express the physical or capability elements is also not very clean. Remember Ric’s warning about the inverse relation between ambiguity and complexity (and redundancy, I would add).
All the layers and aspects, and the confusion here and there, and the mix of abstraction and construction, make ArchiMate quite complex. It is definitely no longer the simple language that was intended to make communication between architects and management about the content of their IT projects and landscapes easier. As a language between architects, or between architects and engineers, it remains powerful and practical. There is no need to use everything, you can (and it is wise to) create your own patterns for its use. A final word of warning: don’t take pattern creation lightly. Using the language with good patterns is a breeze, you can teach it people in a few hours. Designing robust and flexible patterns for what you need to express and how you need to use your models is hard and it takes experience to do it well.
