We can use integration to help us change systems independently, but we need to define what we should treat as separate systems. This can be done pragmatically based on technical differences, or more rigorously by looking at how systems support different management responsibilities.
Last week I defined integration as the balance between the need to get systems to work together and the need to change them independently. I made a distinction between integration that guarantees independent change, and mere connection that does not.
We need to understand when to use integration, and when mere connection is appropriate.
The simple answer is that we need to use integration when we connect across a system boundary. But this poses another question, "how do you define system boundaries?"
Half of the answer is in what we are trying to achieve. We use integration to protect ourselves from changes in technology, data, processing and timing. So it makes sense to put a system boundary around each lump of functionality that has a different operating system, runtime environment, server, vendor, timing or database.
From a pragmatic viewpoint, you can define system boundaries around existing systems just using these simple distinctions.
But this is only half the answer. In an ideal world, you would define system boundaries so that they are meaningful in business terms. Then when you change systems to support a business change, the systems changes will not have an impact on other business areas. Integration gives business flexibility not just technical flexibility.
You could draw up a logical application architecture for the organisation, and define system boundaries around logical groupings of functionality.
I have never been successful with this. Integration is a long term project, and basing it on a corporate application architecture requires that the organisation maintains and uses the architecture in the long term. Unless you work in a very enlightened organisation, this simply will not happen.
If we want meaningful system boundaries we need a stronger structuring principle than an IT-led logical application architecture. In most organisations, managers are termed managers because they have some autonomy. That autonomy will show up as pressure to change systems. If you draw system boundaries around management responsibilities, changes will only be required to the systems that support one business area, and the systems will not force knock-on effects in other areas.
It is more important to define boundaries than to worry exactly where they should be. I would create system boundaries for any of these reasons:
When any of these apply, I would use a full integration approach to make sure the separate systems can be changed independently.
When these do not apply, I would use mere connection. I would use whatever technology seems most convenient, even if it does not keep the separate components independent. For example, I might use ActiveX to stitch together components to build a Windows PC application, or database connectivity to bolt a reporting tool onto a package application.
Having defined system boundaries, next week I will describe how we decide what information we need to send between systems, and how we should structure the information.