What will be represented in our ArchiMate model?
As indicated in the "motivation" file, we need to start with agreeing on what we will be representing in ArchiMate. In essence, we need to explicate how we look upon interconnections in application landscapes: what do we see as “components” and what are “connectors”?
To express our views and to provide a rationale for the choices we have made, we have taken the following three steps:
- Step 1: Categorize interconnections ("connectors") into types
Our objective is to introduce guidelines for the modeling of "as is" application landscapes in terms of components and connectors. For clarity and expressiveness, the models created in accordance with those guidelines should stay close to the observed reality. That is to say that the models should be understandable on the operational level and not only to enterprise architects. More specifically, the ArchiMate constructs should not be targeting “connectors” in general, but rather the concrete types of interconnections (connector types), as they exist in practice.
- Step 2: Clarify what do components in our C&C views represent
Our model should be reflecting the real-life topology of the application landscape. That implies that the components have to be identified from the perspective of IT operations when dealing with interconnections. In other words, the managed interconnections demarcate application components.
- Step 3: Decide which entities need to be represented for each interconnection type.
We aim to use ArchiMate elements as direct representations of real-life entities (like queues and topics) or easily recognizable concepts established in the operational practice. After categorizing interconnections, we have to choose which real-life entities and concepts should be representing them. We shall formulate our choices in informal, elementary non-ArchiMate meta-models describing each interconnection option (the connector type). We shall keep our C&C ArchiMate constructs in conformance with those meta-model: the elements from our meta-models are represented (one-to-one) with ArchiMate elements. That direct representation will be emphasized through ArchiMate Specialization.
Step 1: Categorizing interconnections:
Let us categorize interconnections by using integration styles, as described in the EAPJ article “Accurate Insights into the Runtime Topology of Application Landscapes.”. We would be thus using the (slightly adjusted) list of patterns defined by G. Hohpe and B. Woolf in Enterprise Integration Patterns (Addison-Wesley, 2003). Adjustments are needed to reflect the nowadays practices and product offerings.
Picking appropriate connector abstractions is often one of the most difficult jobs of producing effective architectural documentation using the C&C viewtype. If the connector abstractions are too low-level, then the view will become cluttered both with connectors and with components that are actually logically part of the connector mechanism (see below). If the connector abstractions are too high-level, it may be difficult to map from the C&C views to more implementation-oriented views. While deciding how abstract to make connectors is a matter of taste and the needs of architectural analysis, documentation that one finds for today’s systems tends to err on the side of being too low-level. (from: Documenting Software Architectures: Views and Beyond, Second Edition)
Request-Response (Remote Procedure Invocation)
An application exposes interfaces of some of its procedures so that they can be invoked via network endpoints, and other applications can invoke those to run behavior and exchange data. The interaction takes place in real-time and synchronously. By far most solutions nowadays are based on the HTTP protocol (SOAP, gRPC and REST-like web services/APIs). The use of web services is fully supported in all application platforms (Java, .NET, Python, etc.) and requires no intermediate components.
Point-to-point Messaging (Queuing)
An application sends a message to a receiving application via a queue. An intermediary messaging system facilitates queuing and ensures that the message is made available to the recipient.
Publish/Subscribe
An application publishes an event to an intermediary messaging system using a message that addresses a “topic.” One or more other applications are subscribed to this topic and are notified of the event.
File Exchange
Files are moved from one file location to another; alternatively, a “producing” application creates a file in a shared directory. Most commonly, receiving applications monitor the file location for changes.
Shared Database
Multiple applications share the same physical database.
(from: Accurate Insights into the Runtime Topology of Application Landscapes)
In C&C terms, we would be aiming at the following "connectors":
Connector Type (supported interactions) | Associated real-life Entity | Possible roles that can be taken by an attached component |
---|---|---|
API (Remote Procedure Invocation Style): Synchronous APIs (web services), possibly all based on HTTP. Encompasses WSDL/SOAP services, REST-like APIs, gRPC, etc. | Web service (API) or access point | Service provider (1), Service consumer (multiple) |
Queuing (Point-to-point messaging via queues) | Queue | Message producer (multiple), Message consumer (1) |
Topic (Publish/subscribe) | Topic | Publisher (multiple), Subscriber (multiple) |
File Exchange: FTP file transfers, shared directories | Directory or something else (?) | Source, Sink, Source&Sink (all multiple) |
Shared Database | Database | Source, Sink, Source&Sink (all multiple) |
Other: Any other integration option (presumably a “legacy”) | Source, Sink, Source&Sink (all multiple) |
Step 2: What do Application Components represent?
Obviously, components in our model should be representing recognizable real-life application components. However, this is not as straight-forward as it may appear and several issues require a discussion and a kind of consensus:
-
When describing "as is" application landscapes in terms of components and connectors, the managed interconnections demarcate the components. By saying "managed" we emphasize that not all interconnections are visible; there may be smaller grained application components embodied in larger components but not visible as such. In other words, some compositions of application components may not be visible in our views. Consequently, our model is intermixing components that are otherwise perceived as being at a different composition level.
-
To be complete, our model needs to show all interconnections which also includes those that support interactions across the organization's boundaries. Consequently, we need to show how the external applications are connected which also implies that we should show those external applications. If an internal application consumes an API provided by another organization, there is no knowledge about the component that exposes that API. The agreements about such interactions are made about the provided and consumed services, and the actual components of the other party are completely out of sight.
-
A similar situation arises with microservices, where the premise is that one component provides one service only. Consequently, some stakeholders talk only about services and disregard the providing components completely.
-
How to deal with integration brokers, ESBs and other application components that provide for application integration,B2B integration and orchestration of business processes? Products like Dell Boomi, Mule ESB, Azure Logic Apps, BizTalk … all provide “connectors”, a kind of advanced fabric that enable easy integration. It is likely the most appropriate to model runtime instances of these products as application components. The "connectors" of those products are oriented towards providing the functional integration (data model transformations and alike) and the concrete interconnections are based on some standard integration mechanism covered with our categorization.
To summarize (through examples), application components in our model (and C&C views) could represent:
- An enterprise application component deployed either on-premises or in a managed cloud infrastructure environment (IaaS, PaaS), as identified by its business owner. In most organizations, these components will have the highest presence;
- A SaaS application - Although we know that SaaS solutions are not monoliths, their inner structure is beyond the knowledge and concern of the organization using it;
- An external application authorized to interact with the enterprise’s applications by providing or consuming web services, being message queue producer or consumer … (external means that it is owned by another organization).
- An entire (partner) organization - For example, enterprise publishes selected APIs to partners – often we do not know which concrete application components consume exposed services and we equally don’t care – it is outside of the enterprise, beyond our concern … In this case, when specifying external components, we may aggregate all these to one (substitute) component;
- An instance of an integration/B2B broker, ESB or alike.
- All anonymous consumers of an API with unrestricted access - One component stands for multiple unidentifiable applications)
- A uniformly managed set of handheld or browser-based applications or information kiosk applications - One component stands for multiple runtime instances of an application;
- ...
Step 3: Which entities should be included?
Obviously, our model needs to include elements that stand for components and connectors. We have discussed what we intend to represent with component elements; in this section, we shall elaborate on what the connector element of each specific type is going to represent.
Later, in the chapter "Relation with other Viewpoints", we shall discuss the options for extending our meta-models with information that would be of use in other views. The ‘rudimentary’ meta-models laid down in this section will then be extended with the representations of other real-life entities. Here we assume that one would be retrieving the information over those entities in conjunction with the information about components and connectors. And, in addition, we shall elaborate on options for combining the derived ArchiMate models with other ArchiMate based information.
Request-Response (API) interconnections
Here we deal with remote procedure invocations:
An application exposes interfaces of some of its procedures so that they can be invoked via network endpoints, and other applications can invoke those to run behavior and exchange data. The interaction takes place in real-time and synchronously.
The API-functionality (or service) is thus central to API interconnections; therefore, it is natural to have connector elements representing that service. However, from the perspective of IT Operations, we cannot claim that we have any information about the functionality, except the interface to it - the API. And, with "interface", we do not mean an endpoint, but the interface as it is exposed by the providing application. (There could be multiple endpoints exposing the same service of a component – that is discussed in the chapter Relation with other Viewpoints).
The meta-model:
Interconnections realized through point-to-point and publish-subscribe messaging
An intermediate messaging system (a message broker) provides the technique for asynchronous message exchange. The message transmission is reliable - the reliability is ensured by persisting messages in a message store. In point-to-point messaging, messages are exchanged via queues: one application produces messages and the other one consumes them. In publish-subscribe messaging, messages are exchanged via topics: one application publishes a message to a topic, and the subscribed applications receive notifications. In our model we shall be representing the real-life objects queues and topics; those entities are determinative for their respective type of interconnection. That leads us to the following meta-models for point-to-point and publish-subscribe messaging.
All other (data-oriented) interconnections
This concerns interconnections based on integration patterns File Exchange, Shared Database, and all other data-oriented integration options. Those interconnections are not supported by integration mechanisms that are available in application platforms (unlike it is the case with APIs, point-to-point messaging and pub/sub messaging). Apart from that, there is very little in common among them.
However, we discuss their modeling option jointly because we focus on the direction of the data flow: interconnected applications can either be a source or a sink of data, or both. And that part we can represent with a single meta model. What will be different is the “connector” element; it has to stand for the entity that is determinative for the interconnection type being modeled, and they are obviously different.
The challenge is to decide which real-life entity or concept to represent in the model. For some types of data-oriented interconnections it is straightforward and for some other it is problematic. We propose the following for some (this list is by no means exhaustive):
-
For Shared Databases, represent the data table that is being shared
-
File Exchange:
Exchange Mechanism | Represented real-life entity/concept/... |
---|---|
Exchange via a shared directory | shared directory |
Exchange via a file hosting service (DropBox, Google Drive …) | hosting service |
Exchange via an FTP server | FTP service or exchange directory where the files are collected |
Compared to APIs and messaging, we are apparently lacking rigor here. However, that should not be regarded as a problem; these interconnection types are not frequent (disregarding how important they may be) and therefore there is no real need for uniformity, as in case with APIs. Yet it is important to ensure clarity by proper stereotyping and naming/labeling and possibly by adding a descriptive property.
The meta model: