ArchiMate Application Component, Bending the Rules
This article is part of the The ArchiMate Series
ArchiMate is an enterprise architecture modelling language for modelling the high level architecture of complex systems, its metamodel of layers and aspects, is great for representing the big picture. For example, the ArchiMate application layer has elements for modelling components, interfaces, services etc but when it comes to representing the lower level details of the solution or application architecture then UML diagrams are more suitable.
We create architecture models and diagrams with the intention of communicating a clear and concise message. Whether representing the big picture or the low level details, there are many decisions to be made regarding the level of detail to include or exclude from any given diagram.
When the stakeholders of a particular architecture diagram are software developers it is important to get down to a level of detail where they know what needs to be implemented and how that implementation fits into an existing code base. This can be tricky as the boundary between enterprise architecture and solution/software/application architecture isn't clear cut. In order to have meaningful conversations across this boundary we need a means of transitioning across it.
We often need to show how a new piece of code fits into the bigger picture. In this scenario, we can represent the high level components in ArchiMate and the lower level details in UML. We can bridge the gap between the two models by representing an application component in both modelling languages, elaborating on the detailed design in UML, with classes etc. This is all possible but there is a disconnect between the two models which breaks up the story, making it more difficult to communicate some concepts.
So what are the options?
The Data Object
According to the ArchiMate specification, the Data Object can be
used in the same way as data objects (or object types) in well-known data modeling approaches, most notably the "class" concept in UML class diagrams. However, this doesn't work for behavioral elements as it's a Passive element which can only represent data objects.
The Application Component
According to the ArchiMate specification,
An Application Component is a self-contained unit. As such, it is independently deployable, re-usable, and replaceable. The specification also states that "The application component element is used to model entire applications and individual parts of such applications, at all relevant levels of detail."
Bending the Rules
Now for the bending the rules part, I often use the Application Component to represent a code class, purists may baulk but pragmatism wins out for me here. While a code class isn't "independently deployable", the piece about "all relevant levels of detail" lets me use it with a clear conscience if its a valid part of the message being communicated.
Now, I don't suggest that you try to create full class diagrams in ArchiMate, you will hit a wall very quickly as the language certainly doesn't have full OOP support. However, having a class on a ArchiMate diagram does give you a nice way to bridge between ArchiMate and UML class diagrams, a reader can see how a class fits into the big picture and they can then jump into the lower-level detail of the UML class diagram or even better, into the code itself.
In the Specialization of Elements and Relationships section of the ArchiMate specification it states that:
The stereotype notation with angled brackets may also be used to denote a specialized concept. In the example given for specialisation of an Application Component it also mentions that it must be a
deployable component of functionality. Ok, so we're back to "deployable" but that is the bending the rules part.
Adding a «class» stereotype to the element name (using Guillemet characters) makes it clear that we are representing a class. Fig 1. shows a simple example where the Orders Web API is composed of the AuthenticationHandler class and served by the Authentication Provider.
See the Archi Tips and Tricks article for more details on adding stereotypes.
Adding the following properties to the elements is also useful:
- Namespace - this helps you remember where the class resides in the code base
- Stereotype - with a value of "class", this helps with filtering the model elements
Some architecture modelling tools support both ArchiMate and UML views in the one model, allowing links between the elements, this works well for those who have access to such tools but not so well for those who don't.
Archi is a great tool for modelling in ArchiMate, it does not support UML, but it does generate very nice ArchiMate diagrams for use in architecture documentation and presentations.
- How to Use the ArchiMate® Language with UML - Open Group Whitepaper