ArchiMate constructs: principles, assumptions, and constraints
Principles, assumptions, and constraints
- What is our concrete goal?
We want to introduce guidelines for modeling the observed runtime structure of application landscapes in terms of components and connectors. For clarity and expressiveness, those models should stay close to the observed reality; this is to say that the models should be understandable on the operational level and not only to enterprise architects.
- What is our approach?
As stated before, we first define non-ArchiMate meta-models that describe each interconnection option (the connector type) separately. The objective is to determine which real-life entities and concepts need to be modeled to appropriately represent interconnections. In doing that we also consider limitations in observing the actual application landscape: the model should include only the information that can be obtained without major efforts and that can be maintained.
After that, we elaborate the ArchiMate modeling options for each such meta-model (connector type). The elements from our meta-models are represented (one-to-one) with ArchiMate elements.
For specifically discussing the C&C views, we use illustrative examples (“example models”) based on the respective meta-model.
For clarity reasons, example models are intentionally reduced to include only the entities that may be a part of a C&C view. A separate section of the definitive document will describe how to include other entities (that in the real-world practice are also expected to be a part of the model).
We aim to produce ArchiMate models suitable for creating C&C views without model transformations – one should be able to create such views simply by excluding unnecessary elements and relationships.
- Which ArchiMate Layer?
It is self-evident that components and connectors should be represented in the Application Layer as much as possible.
- How to represent "components"?
It is equally evident that we should use the Application Component element to represent components.
- Structural vs Behavioral elements?
Regarding the use of structural vs. behavioral elements of ArchiMate for representing interconnections: Our model shows the structure of an application landscape; therefore, Intuitively, one may expect that ArchiMate representations should include only the structural elements. However, that would make the ArchiMate modeling less effective. Although we are dealing with interconnections (which stand for a structure), interconnections are there for a purpose, namely, to facilitate interactions. In the C&C approach, a connector primarily describes the behavior of the interaction it mediates. Accordingly, the preference is to use an ArchiMate behavioral element or an active structure element, if possible (?)
- C&C views are broadly defined. How to get most of it in our context?
C&C views are broadly defined so that they may be used to show the architecture of any system. The first step in using the approach of “Views and Beyond” should be narrowing down the available choices to our concrete needs. As outlined in the preceding paragraphs, we intend to represent application components as they are identified by observing their managed connections (or, in other words, the potential interactions with other application components). We also intend to have connectors representing the mainstream interaction mechanisms. This leads to the following reductions:
-
We will not use C&C ports. The abstraction “port” is introduced to specify different attachment points on the component element. That has no meaning in our case – we can assume that each attachment has its own, exclusive port.
-
The semantics of C&C roles will be assigned to attachments (relation between components and connectors). The ArchiMate relationship will then denote the role. That can be done either by using different relation types or, in cases where we can have only two roles, by using the direction of the relation. This is illustrated with the following example that shows how to represent three applications interacting via a topic.
- In general, language idioms evolve over time through usage practices. How would it be ensured that the proposed constructs representing connectors are recognized as (intended) idioms?
To achieve that we need to explicitly specify what the used elements and relations are representing. In other words, we shall use Specializations of ArchiMate concepts. All elements having a specific meaning will be denoted with a stereotype (UML guillemet notation) that would clearly indicate that meaning.
- Should we visualize connectors with connecting lines or with "in-between" boxes?
C&C views may visualize connectors as a line or as a box (showing connectors in a graph either by nodes or by edges). We assume that a box representation would be more suitable for most uses. We will thus primarily elaborate on how to represent connectors with ArchiMate elements (rather than with ArchiMate relationships). As in some cases one would prefer showing a connector with a line (for example, when one wants to focus on dependencies between applications in general) we will also discuss direct ArchiMate-relationships between interacting components.
- Should we uniformly represent all interconnections?
API interconnections are most commonly service-oriented, while all others are data-oriented. Accordingly, representing API-connectors differently than the rest would improve the expressiveness. There is not much value in striving for uniformity and representing all connectors in the same way.
-
Can our model include more information (extending C&C), and, if yes, how to deal with it?
-
The model representing the observed reality should include additional information if it is available. It may therefore also include additional elements, not only those representing components and connectors. Moreover, the model is intended to be a departing point for further modeling, therefore it should be accommodating for more information. However, the semantics of C&C must be preserved. This is to say, for example, that additional elements shouldn’t be in-between a component and a connector. In other words, the direct relation between components and connectors (that bears the semantics) must be preserved.
-
Not all information pertinent to application interconnection is suitable for ArchiMate representation, nor we need to have it stored in a modeling tool. (for example, some details like OpenApi or WSDL definitions) Instead, we should use links to switch from a modeling tool (ArchiMate) to another information source.
-
We may use properties to convey more information.