Modelling Integrations

The Aplas schema for integrations is consciously designed to be both simple-to-model and simple-to-understand. While the term "integration" has been used to describe any number of complex transactional patterns, in Aplas we must ensure the model is simple enough to make sense to the broadest number of people.

In Aplas an integration is defined as, "software that carries specific data between two systems and doesn't store data at rest". The key attributes of the model are source application, target application and payload. Custom fields can be used to describe more complex integrations but, as we describe below, it is often not recommended.

Let's go through some integration patterns. When discussing the different integration patterns will use the term "transaction", just so we don't get confused over how we define "integration" in Aplas.

Single source and target

The simplest and the most common type of transaction fits perfectly into the Aplas model. Almost all transactions can be either simplified/split or conceptualised/merged to fit this model - allowing anyone to understand software architecture.

Single source with many targets

It is not uncommon for a single transaction to send the same data from one system to many target systems. We recommend splitting this into multiple integrations with a single source and target. If you wish to describe the underlying software that is responsible for the transaction, use an Aplas component and link to it from both integrations.

Multiple sources with one target

Single transaction

In a single transaction data is taken from multiple source systems and moved to a target system. We recommend you select a primary source application (often the triggering system), and define the other sources as cross-references using a custom field.

Multiple transactions

If multiple transactions are involved, often with multiple triggering systems we recommend multiple integrations. If you wish to describe this group of integrations as a whole, use an Aplas collection (often tagged as a sequential process).

Integration with software infrastructure

Generally, we do not recommend creating applications for software infrastructure (e.g. middleware, authentication services, etc). The best way to understand the reasoning for this is to contrast with geographic mapping. Imagine if we created one application for all roads, one for train lines, and another for all air routes - just because they used the same technology. This would make the map highly complex, greatly limit understanding, and provide limited benefit.

What about API platforms, ESBs, or other middleware platforms?

We recommend that you don't create an application for each middleware platform. The best way to represent the different middleware technologies is to create different integration tags for each. It is then possible to search for that middleware platform in metamap or create a style that highlights which applications/integrations use which middleware platform.
On a software map, it is best to think of middleware technologies as the "medium" for which data travels around, rather than a destination within themselves. This is further outlined in the next discussion about multistep transactions without data at rest.

What about authentication/logging or other shared services?

We suggest creating Aplas components for each shared service, then linking to the applications/integrations that use them. It is then possible to search for the shared service in metamap or create a style that highlights which applications/integrations use which shared services.

Multistep transactions

With intermittent data at rest

If there are multiple applications involved in a sequence we recommend creating multiple integrations to model each step. We consider this a business process that has multiple integrations. This can be described using an Aplas collection with a number of integrations contained within.

Without intermittent data at rest

If the intermittent applications don't hold data at rest and exist only for the purpose of transmitting data between other systems, we recommend reconsidering them as applications. The other option is to model such software as Aplas components contained within an integration (e.g. an AWS S3 bucket to temporarily store payloads with Lambda functions that translate/verify data).

Final recommendation

There is an important mental shift required to consistently describe integrations across a business over time. It requires separating the physical technology pattern that was used to build the integration from the logical integration problem that was solved.

You should always test your model by asking this question - if I was to change how the integration was built (aka. dev pattern), would this change how I logically describe the integration? Yes, is the wrong answer here. 😁

The simplicity of the model is our friend, it ensures integrations can be described by different people with varying technical backgrounds, in a consistent way, over time.