In my previous post about integration and ArchiMate, I argued that integration could be modelled as some sort of collaboration at the application level.
The business layer in this modelling was far above this mere-mortals-thing of integration and entirely not involved, let alone responsible or even accountable for, integration.
And while this way you can apply quite a few different ArchiMate diagrams, and it does get the integration gist, it did not satisfy me. For it actually does not address the most important aspect of integration: business ownership.
That’s why in this post I’ll approach integration and ArchiMate from a solution architecture shaping angle, starting with the business layer perspective. Now, the point is that many of the organizations I’m working for don’t do business layer modelling; for them it’s all about applications. So, I should give you a warning: Business Layer Modelling Stuff ahead!
Figure 1 – Integration as an application collaboration
Business Layer Integration modelling in ArchiMate
Part of my work involves giving workshops on what good integration is (and isn’t) and how to transform your organization into one that practices good integration. During these workshops, invariably someone will put up a sticky note with the question: “wt* is integration?”. I really do like that question and the answer is simple and quite well known amongst integration specialists. It is also not about connecting applications like most people assume:
Integration is about the sharing of business functionalities between business capabilities
If you start with this definition and model your integration in the Business Layer first, good chance that you’ve modelled your integration correctly and answered all questions needed for fast implementation and succesful operation. In ArchiMate we can depict this ‘sharing of business functionalities between business capabilities’ by:
- two business capabilities A and B
- that are realized by Business Functions A and B
- that have internal functionality, say a through d
- of which one function from Business Function A serves one function from Business Function B
Figure 2 – Representation in ArchiMate of what integration actually ís
Now, this definition might not fit the entire spectrum of integration, but for most of the integration I’m involved in, it covers it nicely. But wait, something’s missing. This representation does not show which of the internal business functionalities are available for use outside of the Business Capability, and which are not. Same on the consuming part; the model does not show which internal business functionality needs which specific provided internal business functionality’s input. I would want that to be explicitly shown and named, and for this (the exposure of internal behavior to the outside world) ArchiMate has a specific concept: the service. The business service to be more precise:
Figure 3 – Explicit providing and consuming of a Business Capabilities’ functionality
So, the Business Capability A exposes its internal capability (internal function A.a) to the business environment by the business service Providing A.a. Likewise the Business Capability B exposes a business service that consumes the provided business service A.a for use by its internal capability (internal function B.a). Note that I’m showing something important here:The providing business service just provides. The consuming business service on the other hand is responsible for making the consumed somehow fit its internal functionality. And for those who think I’m forgetting about loose coupling; this is the business layer. No loose coupling required here, for business capabilities themselves are not that frequently replaced or phased out like applications are.
Data
Data also seems to be important nowadays, so let’s show the data in this business integration diagram:
Figure 4 – Business objects involved in the business integration
As you can see, there is no data as such in the business layer, only the equivalent of data: Business Objects. The nice thing about the business layer and integration is that you don’t have to worry about the flexibility of your IT landscape. So no Loose Coupling needed at this level and the business capabilities, and their business functions are allowed to “know” each other, serve each other directly and use each other’s business objects, albeit indirectly. I think it’s good practice to think about the integration of business objects. You’ll need them eventually in the application layer because you don’t want application propriety data objects to end up with another application.
Ownership
I’ve added the ownership of all the integration business layer items as ArchiMate groupings. These are composition relationships. But because this ownership is an accountability, and is retained down through the application and technical layer, I prefer to show it as a grouping:
Figure 5 – Business integration ownership
This shows us another extremely important integration concept you’ll miss out when not considering the business layer:
- The providing business capability is the owner of the providing integration business service
- The consuming business capability is the owner of the consuming integration business service
Meaning the ownership of integration services, whatever their implementation, starts at the business level. In the end, it is data and application functionality that is being shared. That’s why the relation to business ownership must be clear up front. Integration should not start with, or be considered as, solely an IT concern, because every integration comes from a business driver, goal or constraint. You should catch that business driver, goal or constraint and model it in the business layer. This ownership is carried down through all the layers.
Business Integration Patterns
As the meta model describes, a service should be realized by a function. So you could (or should, actually) define a set of abstract business integration patterns, as opposed to the abstract application integration patterns you’ll need to define later on. These abstract patterns should be the basis of all business integration functions that realize the business integration services:
Figure 6 – Total view of involved archimate elements and relations in single business integration
Note: make sure your abstract business integration patterns do not contain or point directly to the abstract application integration patterns. Now these functions don’t have any inherent IT or technological aspect to them. They could easily have been defined without IT, like in business: “The billing department requires the customer department to share customer information every month” or government: “The consul requests the senate to approve some new law”. Business integration modelling in ArchiMate essentially is about modelling the what, not the how, just like all business modelling.
Discovery
To model business integration, I’ve been using a specialized form of the user story during analysis sessions. This specialized user story helps business owners, who are already familiar with defining user stories, to identify business integration requirements and it goes like this:
As [Department B], I need from [Department A] the [Business Object A.a] information for my own department’s [Business object B.a] information so that [a benefit/a value].
Participants are not allowed to think of let alone write down actual system or application names, technical terms like file, message, database, system, application, implementation, data(flow), API, interface and integration. Example: As a planning department, I want the vehicle management department to provide the available vehicle information for use in the schedule information so that we can plan the routes.
Summary
-
- Integration is about the explicit sharing of a business capability’s internal functionality.
- Integration comes from business drivers, goals or constraints.
- The business is responsible for the specific integration facilities that ensure its goals are met.
- Every business integration consists of a providing and a consuming service.
- Use the Business Integration User Story to define the Business aspects of an integration first.
- The total view of involved archimate elements and relations captures all required business aspects of a single business integration.
Next time I will delve into the application layer and show you the good, the bad and the ugly of application integration solution design.
