Blijf op de hoogte!
ArchiMate is one of the best things that have happened in enterprise architecture. This modelling standard helps enterprise architects understand each other. It is rapidly becoming the international standard for architecture modelling. Although it is well thought out, ArchiMate has its limitations like anything else designed by mankind. Let's have a look at three limitations I frequently encounter and workarounds that I use to deal with them.
First limitation is in the motivational extension. This extension provides concepts to model the relation between the architecture and its context. A very powerful combination is the drilldown from business goal via principle to requirement. It enables us to reconstruct for each requirement why it is relevant, or in other words how it contributes to business goals. This is done by following the realisation relations between elements.
However, in many organisations principles exist in a hierarchy with top-level principles and one or more lower levels of principles. There, a principle realised by a requirement does not directly point to a business goal, but to a principle at a higher level. Unfortunately, ArchiMate does not allow a lower-level principle to realise a higher-level principle. And thus the chain of realisations is broken.
Luckily, a workaround is available and easy. Just model the relation between both principles as an aggregation, i.e. the higher-level principle aggregates the lower-level principle(s). Using the algorithm for derived relations, you can reconstruct that the requirement does realize the business goal In the end. Still, it would be great if the Open Group would add that single ‘r’ in appendix B2 of the ArchiMate specification!
Second limitation is the inability to model classes of application components. I’ll explain: Imagine an organisation having two similar applications for storing customer related data. One is an implementation of Microsoft Dynamics named “Custard”, the other is a self-built application named “ClientBase”. Architects will refer to these as being both “customer relationship management systems”. And it would make sense to model this accordingly in ArchiMate, just like we model classes of business actors as business roles (e.g. Alice and Bob are both assigned to the role of “helpdesk agent”). Unfortunately, ArchiMate does not provide us with an application role concept.
Luckily, there is a workaround for this too. Model a high-level application function that aggregates all application functions that you would assign your application role to. In the example, this might be “customer relationship management functionality”. Then, assign your application components to this high-level application function and you’re done! Nevertheless, introducing an application role concept would be an improvement to ArchiMate, not only because it is more consistent with the habit of speaking in terms of “systems” (e.g. CRM system, accounting system), but also because it would enable more precise modelling of relations with application interface and application collaboration.
Third limitation is the lack of a concept for modelling standards. Architecture is all about using standards to improve interoperability, replaceability, etc. So why is there no ArchiMate concept for such an important thing? To be honest, I don’t know. But I do know that you can model standards with current ArchiMate concepts and relations. First of all, we must realise what a standard really is. Java, for instance, is not a standard. It is a programming language. But the use of Java as programming language in specific situations might be a standard. So, a standard is an agreement to always use the same thing in equivalent situations. But a statement like “When X, we always do Y” is just an architecture principle!
Therefore we can model a standard as an architecture principle associated (using the association relation type) with a specification of some kind (in the example: of the Java programming language). An advantage of modelling standards this way is that your standard-as-a-principle can hold all relations of architecture principles, including the realisation of business goals that motivate why the standard is relevant, and requirements imposed on individual systems as an implication of the standard.
Please note that other workarounds to these limitations may exist and be just as good as the ones presented here. Do you have other limitations of ArchiMate that you have found a workaround for – or are still looking for one? Reply to this posting to share it with others!
Erwin Oord (email@example.com) is a principal consultant and managing partner at ArchiXL.
Neem contact op met ons, we vertellen er graag meer over!