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 with ArchiMate?

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 by a diagram.

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 support for OOP concepts. However, having a class represented on a ArchiMate diagram does provide 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.

Class Stereotype

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's the bending the rules part!

By adding a «class» stereotype to the element (using Guillemet characters) it 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 which is served by the Authentication Provider interface.

See the Archi Tips and Tricks article for more details on adding stereotypes.

Fig 1. Application Component with Class Stereotype

Modelling Tools

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.