Integration and the art of Archimate – Integration as Strategic Capability

Integration and the art of Archimate – Integration as Strategic Capability

Gartner defines integration as “styles” that can take the form of being either application, data or event centric. While archimate doesn’t do artistic expressions, I will use these three styles as a starting point for a strategy-to-solution-building-block derivation of integration capabilities using archimate.

I will show you first how to arrive at the business or strategic integration capability. Then I will discuss how to derive the integration architectural and solution building blocks (i-ABB’s and i-SBBs). Finally I will give an overview of the benefits of having an integration capability derivation.

Figure 1 – Gartner’s Integration styles as part of their Hybrid Integration Platform Capability Framework

In a previous post[i], I argued that integration is not a technical thing but comes from a business requirement with the following definition:

Using the three Gartner integration styles, I can now improve this definition into:

If you, like me, think that integration is of strategic importance you will arrive at the following top-level archimate representation:

Figure 2 – The Integration Business & Strategic Capability

Looking again at Gartner’s integration styles; they are about data, (application) events and application functionality. I choose to see them as application services that mirror the business functions:

Figure 3 – The Gartner Integration Styles as Archimate Integration Application Services

Because we already know what the application layer integration capabilities[ii] are, we can now map these to the Integration Application Services:

Figure 4 – Application Functions as Application Integration Capabilities

Integration experts will immediately argue that this is a too clean a model because you can also share data with Functionality Integration. Other integration experts will argue that File Integration and Message Integration is not a generic enough naming for the capabilities that will result in File Integration and Message Integration. I think that the more you think about it, the more exceptions and additions you need for the correct capability naming. Archimate allows you to model however you like. The actual problem you have to solve determines the model you ultimately end up with. Here is another way of modelling the Application Integration Capabilities:

Figure 5 – Another modelling of Application Integration Capabilities

Apart from these five application layer Core Integration Capabilities there are two more Core Integration Capabilities that are absolutely necessary to being able to define all i-ABB’s.

The first is named Exposure management. It is an aggregate capability combining non-functional-requirements that enable the decoupling, presenting, reusing, policy application, monetizing, trying, testing and securing integrations. It is also a tactical as well as an operational capability.

The second capability is named Integration tooling. It is an aggregate that delivers basic functionality like data-transformation, protocol transformation, validation, enrichment and routing.

The following diagram models the Core Integration Capabilities (CIC):

Figure 6 – All seven Core Integration Capabilities

With these now, I can define and assign the i-ABB’s. And I can specialize the i-ABB’s into their respective i-SBB’s:

Figure 7 – Example i-SBB’s for i-ABB’s

The resulting i-ABB to i-SBB diagram shows a typical ‘As-Is’ landscape like we at Ilionx frequently encounter at our customers. I’m sure you all recognize this.

Note: The Integration Shop i-ABB delivers tactical (e.g. browse, select and try integrations) integration capabilities where as all other assignments deliver operational (e.g. decoupling, policy application, monetizing and securing integrations) integration capabilities.

Stitching together all the shown diagrams produces the following view with the one, the three and the seven:

Figure 8 – End-to-end integration capability diagram showing a To-Be software landscape

So, what can you use this model for?:

• If you are convinced that integration is of strategic importance, you can use this diagram to visualise and manage the end-to-end responsibility and accountability of integration.
• The diagram can be used to scope the integration capability. More specifically, this diagram scopes at the application level, what I’d like call the Core Integration Capabilities (CIC). All other capabilities that can be associated with integration like Process Management, Hyper automation, Data-Hubs and the like should be considered as capabilities that make use of CIC but are not part of the CIC and therefore require separate people, process and material dimensions as well as funding.
• The diagram can (should) be used as the basis of your integration platform architecture.
• The diagram should be input to you integration general principles, frameworks and guidelines
• With the business integration capabilities in hand you can help the business selecting the right integration capability for their business question (especially when you expand the ‘Sharing Business Information’ business function into size and time dependent sub-functions). These sub-functions should be matching the three ‘Sharing data’ integration application functions.
• Use the application integration capabilities when designing an integration solution and have a design-time register of all solutions that use a particular integration capability or are dependent on certain i-SBB’s. I’ll show you how in my next post.
• Define your target integration architecture, subsequent integration roadmap and migration strategy with the As-Is and To-Be i-ABB to i-SBB landscape views.
• Can be used according to and as part of Togaf Capability Based Planning

As before, You can get these diagrams and more as architool repository. Just drop me a line.

[i] Integration and the Art of ArchiMate – part deux

[ii] Integration-transformation-as-a-driver-of-digitalization