Integration and the art of Archimate – The Good, The Bad and the Ugly.

Many organisations only use a small portion of the Archimate palette. Most often I encounter application only landscapes. The relationships shown in these topologies are, most often again, the integrations between these applications:

Figure 1 – A typical Application only Landscape with Integrations

If you’d model these integrations explicitly, that is, using an application artifact instead of a relation, a myriads of benefits will fall into your lap. I will therefore use this application-only-landscape as the starting point for my application-layer integration modelling in archimate.

In this post I will show you how you should (the good), how you shouldn’t (the bad) and how you could (the ugly compromise) be modelling integrations in the application layer. Last I will discuss and show the benefits of ‘the good’.

The Good

Using archimate’s service-oriented features and adhering to the meta-model, the way to “properly” depict an integration within an application only landscape would be as follows:

Figure 2 – The Good – meta-model compliant

The Employee Management application is assigned to the Manage Employee function that performs the actual functional behaviour of managing the Employee data-object. The Manage Employee function also realizes the Integration Employee application-integration-service which serves (is consumed by) the respective Manage Employee Schedule function of the Employee Scheduling application.

Note: Irrespective of the direction of the flow in the Application landscape view, it is the owner of the data-object that is being shared that realizes (should realize) the integration service.

Note 2: Notice that every integration involves not one but two data-objects. This second data-object is just as important but mostly forgotten when modelling application only archimate views.

However correct this approach might be, replacing all data-flows this way within (existing) Application Landscape views will probably not improve the clarity of the view at all. Therefore and because there is a better way to work out the integrations more detailed later on, I prefer to leave out the functions for now and focus on the integration service only. By using derived relationships to relate the integration service to the providing and consuming applications, you get:

Figure 3 – The Good – with derived relations

Adopting the ‘typical Application only Landscape’ from above to this new way, yields:

Figure 4 – Typical Application only Landscape with “the Good” integrations

Now you might find this view also not very appealing. Fortunately archimate’s possibilities to adjust a view to specific purposes are practically endless. With a slight realignment and resizing you could get a far better overview. Like this:

Figure 5 – Realigned typical Application only Landscape with “the Good” integrations

Alternatively, you could apply a more “separation of functionality” overview with operational applications on one side and the reporting, money applications and external parties on the other side:

Figure 6 – Alternative realigned typical Application only Landscape with “the Good” integrations

The Bad

Let me get this straight: If a relation is allowed according to the archimate Application Layer meta-model, then you can use it within your model or view. But the meta-model does not contain a flow-relation between application components (Internal Active Structure Elements). Therefore, if you use it,  it must be a derived relation.

Figure 7 – The Bad’s flow relation between Application Components is a derived relation

And because flow relations between Application Components are derived relations, you should either add more information (e.g. use “the Good”) or find another way to model the actual integration (spoiler alert: use “the Ugly).

With using a flow relation between application components, there is no way you can gain the same benefits as the benefits that “the Good” offers you (see Benefits).

The Ugly

Now, if you don’t like or don’t want to model application landscapes the good way, but you do want the benefits of it i.e. separately view, group, categorize and reuse integrations, then there is always option three: “the Ugly”.  The Ugly, combines the “clean” view of “the Bad” with the notion that to acquire the aforementioned benefits of “the Good”, you need at least an application-service to point to your flow-relation.

By using Archimate’s option to “attach” an object, e.g. a service, to a relation you could relate the integration-service to a flow like this:

Figure 8 – The Ugly

Now you can leave your original Application Landscape view as it is and have all the benefits that you get from having a separate integration service. Albeit using “the Ugly” relating to a relationship archimate option.

Benefits

By applying ‘The Good’ or ‘The ugly’ to you models, the following modelling benefits are achievable:

Separately view
Try to put a relation on a canvas. You just can’t! But, with depicting integrations as a service, you can now put any number of integrations on a canvas to have, for example, an overview of all your integrations. Which will be easier still if you apply some naming conventions to your integrations:

Figure 9 – Overview of integrations

Group and Categorize

Even better than just having an overview of certain integrations, you could group specific integrations according to some characteristics you came up with:

Figure 10 – Grouping of integrations

Integration service registry

One of the holy grails of the Service Oriented Architecture was to have a catalogue of integration-services that you could reuse. This was always an after-implementation enforced manual effort. Usually on a per integration pattern base and therefore maintained decentralized and hidden for any other than the designer/developer of the specific integration team. When you standardize your modelling of integration across the organization for all solution architects within one tool you could get:

Figure 11 – Payroll part of the Integration Shop Window

Still enforced and manual maintained. But now at least before implementation, centralized, standardized, discoverable and using an archimate element that’s right about perfect. We’re calling it “de etalage” which can be translated into “the integration-services shop window”.

Reuse

One of the bigger benefits is the possibility of reuse (another of the holy grails of the Service Oriented Architecture).

Figure 12 – Reuse – The Good

Figure 13 – Reuse – The Ugly

Realization

When describing “The Good”, you archimate-realize an integration service through its data-object-management function. But that’s only part of the story. Every integration is also being  provided by means of at least one integration. Hence in archimate it should be realized by, what I like to call, a core integration function.

This archimate-realisation is a specific specialisation of one of the five integration patterns (see my previous post):

1. There is an Integrating-Employee application-(integration)-service that shares the Employee data-object of the Employee-Management Application with the Employee Scheduling Application
2. This Integrating-Employee application-(integration)-service is archimate-realized by the Manage-Employee function (not in this figure – see figure 2).
3. .. but also by a (specific) File-Integrate-Employee function
4. This File-Integrate-Employee function is itself a specialisation of the File Integration Function which is a Core Integration Capability (CIC)
5. And this CIC has the integration-Architectural Building Block (i-ABB) Managed-File-Integration Assigned to it.

Now the circle is getting complete. If we do this realisation consequently in all our integration modelling, we can ask our archimate repository questions like “which integration services are realized by the File integration capability?” or “with which integration patterns is this data-object realized?”.

There is a more extended way of modelling the integration services so to being able to ask questions like: what happens if I change this service? Which applications are using this service and what are they doing with the XYZ data object? More of this in my next post on “how to model integrations with archimate”.
As before, You can get these diagrams and more as architool repository. Just drop me a line.