For people who come from a software architecture background and have used UML as their primary visual language to describe technology systems, ArchiMate can sometimes seem like a sort of inferior cousin - kind of the same family, but not quite. And while it’s true that, for example, there isn’t the equivalent of the extremely useful sequence diagram in ArchiMate, it does have some features that might make even the most hardened UML modeller look again. It’s worth acknowledging that both languages have extension mechanisms, so UML can, and has been extended, to allow it to be used more like ArchiMate by tool vendors. The reasons for using ArchiMate below reflect out-of-the-box UML.
A modeled technology solution should always make it clear what the business context is it is expecting to operate within. ArchiMate has a rich set of elements that provide a solution architect with the opportunity to describe what that business context is, and specifically, the relationship between a technology solution and the business context.
This is an area where UML is weak because of it’s focus on software architecture. Use cases and Actors are the key elements that are used, but they don’t come close to ArchiMate’s ability to describe business processes & functions, motivational elements such as goals & outcomes and its ability to link those to software applications.
Mixed Structural & Dynamic Views
UML has two broad types of views - structural & dynamic. This is a nice way of thinking about things and creates clear separation between classifications of things (Class, Component etc) which are described in structural diagrams (e.g. class diagram), and instances of those classifications which are described in dynamic diagrams (e.g. sequence diagram). It’s very important to do this when you are thinking about software design.
When you’re creating a solution architecture, sometimes it’s useful to show both behaviour and structure on the same diagram. This is because you’re often working at a different layer of abstraction from what UML is intended to support and therefore trying to communicate something different.
Because ArchiMate doesn’t have the concept of instance at all - everything is just an element/object - it means that a diagram can be created that has an aspect of both structure & behaviour. This provides a level of flexibility in communicating things that UML doesn’t support (for arguably good reasons given it’s domain).
Because UML is intended to allow any aspect of a software architecture and/or design to be described in a visual and structured way, there are a very complex sets of elements and relationships for a UML modeller to learn. For many people who model in UML, they will only scratch the surface of the language.
ArchiMate on the other hand is relatively simple in its structure - there are types of elements & types of relationships with some minor additional things like groups, but the biggest challenge for ArchiMate modellers is understanding the correct use of the different element types and the correct relationships to use. There is still a fair amount of learning to be proficient, but compared to UML it is a lot less complex as a language.
The reasons listed above are not meant as a criticism of UML (or ArchiMate). Each language has its strengths in its particular domain and there will be situations even for solution architecture where UML may be a better choice. The usual nature of solution architecture however is that it connects the business domain with the technology domain which is something that ArchiMate does very well.
We are modelling specialist at Cyma, with years of experience on many different tools in many different industries and sectors. We can also draw some pretty good diagrams. If you want to know more about modelling and how to use it effectively and efficiently in your environment, then fill out this form and we will contact you, or if you are interested in our online training programs from our partners at Good-eLearning you can click here.