A friend was kind enough to remind me, this morning, that Archimate is still kicking around and making noises. In fact, for a modeling language that’s been in quiet development for many years, Archimate having something of a rebirth as it is now part of the Open Group.
Many Enterprise and Solution Architects are already quite familiar with the Open Group. This is the standards body that originally formed around Unix standards and has since taken on a variety of different domains including the popular architectural process model and framework: TOGAF, which just released version 9.
Unlike TOGAF, many folks are not so familiar with Archimate. This approach to modeling enterprise architecture was developed in the Netherlands by a public-private partnership of the Dutch government, industry and academia. The IP for Archimate was handed over to the Open Group in 2008 and was blessed by that group as a standard last fall. (If the Open Group were actually a group that represents EA, the blessing would have carried a little more weight, but that’s life.)
Alas, there were many sophisticated metamodels in existence before Archimate. Each of the major vendors of EA tools uses a metamodel. I cannot say that I’m familiar with all of them, but I am familiar with a few, as well as the metamodel that we’ve developed internally inside Microsoft IT.
Unlike the UML, Archimate didn’t start with a variety of different problems to solve, each with their own language. UML (+BPMN) is a collection of models that has come together over time from sources in academia and industry. What UML lacks is a solid and consistent metamodel that defines how the parts of different models are expected to relate to one another. In other words, UML does not answer the question: how does a business process relate to an IT service. Archimate does.
Archimate started with an understanding that these problems relate to one another; that the entire complex and difficult business of understanding IT requires a rich inter-relationship of completely different domains, from business motivation to business process to managed services to systems to infrastructure. Thus Archimate goes where UML doesn’t: it defines a metamodel that allows these relationships to be constructed, and constrained, and communicated. The constraints allow analysis, traceability, governance, and consistency. UML is unconstrained between model types. Archimate is not.
That is its strength.
It’s weakness is in the visualizations themselves. For some reason, the Archimate foundation felt the need to redefine the visual language of architecture, reusing familiar images from UML while redefining their semantics. This approach was used instead of leveraging and extending the UML notations. I cannot say that I agree with the approach. I find it unfortunate, with the consequences for confusion and a slow adoption process across industry.
As for the metamodel: Archimate has one, or at least, part of one. That puts it in good light with me. That doesn’t mean I believe that the Archimate metamodel is correct.
I’m not saying that Archimate is right or wrong. I have not reviewed it in detail. (I cannot. The open group ‘published’ the ‘standard’ to their members only, not to the rest of the world. Is that what they mean by ‘open standard?’ hmmm.) [update: since writing this post, a reader has responded with links to an online resource which provides details of the archimate notation and metamodel. See the comments for those links. They were NOT made available by the Open Group.]
Is it Archimate vs. UML then? Maybe. The diagramming model that is included in Archimate clearly overlaps with UML. On the other hand, they solve different problems. Archimate is a mechanism for understanding the meta-architecture of a technology environment. UML fits nicely under the covers, describing the implementation of the systems (both technical and process systems) from various viewpoints.
In effect, Archimate describes the structure of cities, while UML describes the structure of houses and office buildings. Both are needed, and they solve different problems. In that way, they do not intersect at all. Unfortunately, the diagramming notations are not so consistent.
If the Open Group were to create an accord with the OMG whereby OMG would own UML intra-model semantics while the Open Group would own UML inter-model semantics, then the Open Group could simply use the UML diagramming notations in the Archimate specification. I don’t know if something like that is possible, but we’d all benefit. If not, then I’d like to see Archimate use completely different visual representations than the UML, so that there is never any confusion.
Either way, the metamodel, or part of it that Archimate represents, has started to emerge in standards. This is a healthy thing.