The Architecture of integration - Part 1

The architecture of integration

Increasingly I am finding myself involved in Integration projects. Now for a moment, I do not doubt that many people have solved the problem before me. However, I am not sure, I can completely agree that the way it had been done before has completely solved the problem.

The new definition of the problem

To me, now the problem is fundamentally different from the way it has been theorized before. The older interpretation of the the problem has been about connectivity. About one system, user sending an element of data or a message to another department or system.

However, people now see the problem differently. Any business now has multiple views. The operational view, the management view, the financial view, the project view, the process view and so on. There are new views being added to the whole game. There is the regulatory view, the performance view, the strategic view, the spatial view, and so on.

Each of these views adds new contexts to the problem domain, abstracts and reveals new details, and in many cases serves the need of specific stakeholders. In many cases, the view is for a specific stakeholder department and may serve the needs of that specific entity.

The old paradigm of integration is just one trying to see the problem from one view

In the past, integration paradigms focused on a process view alone. So if purchasing makes a request for an order to be filled, when the account is filled, the payment, inventory and purchasing systems should be notified our updated. This started as point to point integration between different systems.

This lead to the problem of a spaghetti of connections. The hub and spoke model was a way to centralize all connections to a single hub. The hub and spoke integration architecture eventually evolved into the enterprise service bus architecture with its decoupled interfaces for business applications. However, these integrated views do not belong in these models.

The word integration appears because of people's ability to conceptually understand a content management system as being different from an enterprise resource planning system which is different from an enterprise asset management system. This is no different from people understanding a hospital as being different from a college being different from a library. However, in the modern city or even a rural city, a single facility may provide the roles of a medical college, a hospital, as well as a specialized library for students and doctors.

I'm trying to articulate the new integration paradigm. There is thus an opportunity to list all the business functions and figure out a combined program. Depending on the context some functions may actually belong as an integrated whole where as others may continue to be separate envelopes that are connected via interconnections.

The architectural problem then becomes which business functions sit within the same envelope and which functions get their own separate envelopes. This is the subject of my next post .....