This week Orbus is unveiling its improved support for ArchiMate 3.0, so it seems an opportune time to make a few observations about the latest iteration of the ArchiMate standard. There are others who have already passed plenty of commentary about the content of ArchiMate 3 and the changes it introduces – in particular, Gerben Wierda of Mastering ArchiMate fame has provided an analysis that shows his usual depth and rigor. But instead, what is interesting for me is to talk about the role of community engagement around standards.
Now, I personally have always pushed for the use of ArchiMate in every location that I've worked. It's not because it's the only modeling language on offer. TOGAF has its own meta-model, so does DODAF, so does PEAF; then there are software tools that offer their own meta-models; and then there are organizations that have their own homebrew meta-models as well. Some of these are associated with symbols, some are not. So why do I always recommend ArchiMate? Is it simply leaps and bounds ahead of any of the alternative? With all respect to the work put into it, no – it's not a cataclysmic leap forward.
Why I recommend ArchiMate is because of the community, or to use another word, the ecosystem that has grown up around it. I remain convinced that there were two truly important factors in the rise of BPMN to be become the de facto standard for process modeling, and the same two factors are at work in ArchiMate's favor.
The first factor was the fact that BPMN was a vendor neutral standard – no one vendor owned it. In the same way, ArchiMate does not belong to any vendor – there are a couple of tools explicitly designed around ArchiMate, but they aren't required to use ArchiMate.
The second factor was the community, or to use a buzzword, ecosystem that grew up around BPMN – the wealth of tutorial resources and examples that were and are available, probably the best known of which is Bruce Silver's “BPMN Method and Style” book and associated training course. In the same way, an ecosystem of resources has grown up around ArchiMate. The most prominent examples is the LinkedIn forum for ArchiMate that regularly sees requests on how to model situations – requests that always get suggestions. There's also the aforementioned “Mastering ArchiMate” book and blog from Gerben.
Which is why it's interesting to see what changes have made it into the ArchiMate 3.0 specification. Almost all can be related to either a recurring question on the ArchiMate forums or a criticism from thought leaders like Gerben (or both). Some examples -
- “How can we model capabilities?” is something that has historically come up again and again. Now ArchiMate 3 explicitly defines that mechanism.
- There's an explicit acceptance that different organizations may need viewpoints other than the traditional set of ArchiMate viewpoints – so guidance on viewpoint definition is provided with the traditional ArchiMate viewpoints offered as examples. Compare the skepticism of standardized viewpoints expressed in Mastering ArchiMate.
- I've seen several posts in the past struggling with how best to model physical situations in ArchiMate 2; ArchiMate 3 explicitly introduces a physical layer.
So the thing that struck me most about ArchiMate 3.0 was how clearly responsive it was to feedback from the community. Of course, this should be true of every standard but traditionally the mechanism for this has relied on involving specialist consultants and trainers in the defining committee. The problem with this model is the filtering that each member will impose – people all have their own agendas, after all. It seems that ArchiMate has shown a more inclusive way to drive changes in the specification, and it's why I'm quite pleased to see the changes that they've introduced.