Component and connector paradigm in ArchiMate
=== ADDED 26-04-2021 === @kalin and I have proposed that we continue to work on this matter in a workgroup, see issue 35.
With this post, I want to elicit feedback on the use of ArchiMate in representing the application landscape model that I have proposed in the EAPJ article “Accurate Insights into the Runtime Topology of Application Landscapes.” (you can also check my other writings related to this subject - the list is at the end of the attached PDF document). That model is intended to describe all application interconnections as observed from the perspective of IT Operations. The goal has been to define a maintainable model that accurately reflects the “as is” application landscape. The step I want to take is to represent that model in ArchiMate.
The ArchiMate representations I have identified are described in the attached document: Component_and_connector_paradigm_in_ArchiMate.pdf
Please share your thoughts on the subject; I’m looking forward to your input. Before proceeding, be aware that I’m not an ArchiMate expert; my ArchiMate models are meant to be an invitation to discuss the matter, not a claim. So, please read it that way.
=== ADDED 13-01-2021 ===
Before responding to latest comments (@Michaelb , @kalin , Joost Wijnings - via LinkedIn), I feel I need to add some clarity.
First, to reiterate the context.
- The model that needs to be represented in ArchiMate is intended to encompass all interconnections in an application landscape.
- The semantics of the model is limited to what is observable from the perspective of IT Operations (mostly to be collected through automation).
- The ArchiMate representation has to be generated programmatically.
About the goal. The ArchiMate representation is intended to provide an accurate model of interconnections in the entire, “as is” application landscape. The purpose of it is to provide a reliable basis for further modeling. The intended value is in knowing what is there. Once it is known that an interaction of a certain type exists, one can look for additional information and augment the model as needed.
This is my line of thinking regarding representing application-interconnections with the element “Application Interaction” (does not apply to interconnections based on APIs).
Although that model is based on representing real-life entities (queues, topics …), the “connectors”, even in that model, should not be viewed as mere on-on-one representations of those entities. Because we know the purpose of those entities, namely, to provide for interactions, we should regard connectors as abstract elements that depict the mediation of interactions between components. This is also fully in accordance with the “component and connector” viewpoint in describing architecture (meant to show runtime components and their interactions). Going from there to ArchiMate, the element “Application Interaction” is, in my opinion, a natural choice for representing connectors (except those depicting APIs, as discussed in earlier posts). This is what the ArchiMate Specifications says about it:
An application interaction describes the collective behavior that is performed by the components that participate in an application collaboration. This may, for example, include the communication pattern between these components. An application interaction can also specify the externally visible behavior needed to realize an application service …
A few more points:
- As the purpose of ArchiMate models is to describe Enterprise Architecture, I deliberately refrained from ‘over-modeling’ and attempting to “show things as they actually are”. For example, adding an element that would represent a topic as such would be of questionable value and likely be confusing. Once we have stated somewhere that the interaction mechanism is “publish-subscribe” we know that there must be a topic. The additional information regarding that topic can then be conveyed via properties of the interaction element.
- Similar reasoning has been used regarding the elements that describe the technique, like specifying the messaging middleware. In my opinion, those elements (from the Technology Layer) are useful in several situations but viewing them has to be optional. This is to say that one should be able to easily omit them from a view without affecting the rendering of relationships between components.
- I would advocate avoiding the modeling of superfluous information.