Connecting A to B: A swivel chair approach

Let's not fight (and goodness knows it is possible to fight) about what these terms actually mean and let's not slug it out over the merits and demerits of each. Instead, let's start with something I think we can all agree on. Namely, that all of the above are examples of using Information Technology to solve problems for the current installed base of, um, Information Technology.

Sometimes, when my disposition shades towards the cynical end of the spectrum, I find myself comparing these things to pouring gasoline onto a fire. In more optimistic moments I compare them to laying down freeways. It is more concrete but designed to facilitate interconnection of existing concrete (buildings).

I find it interesting that we have a tendency to rush to find IT solutions to our IT problems. A good example of this I think is the speed with which we snicker at the very mention of a swivel chair-based integration strategy. It smacks of wrongness. We feel a strong urge to take the chair away and do it "properly".

This is another one of those "I was that soldier" moments. I have removed my fair share of swivel chairs over the years. However, I have also come to appreciate that they very much have a place in the pantheon of integration strategies.

I could pick many representative examples but let's limit it to just two. Scenario A. Two IT applications need to be integrated because of an acquisition/merger. There is no existing integration strategy or indeed even well-defined integration points because previously, the systems were completely separate and invisible from each other.

They need to be integrated now to meet some joined-up business process need. How to start? My advice is to start with a swivel chair. Yes indeed. Move data from one system to the next manually. If necessary, type it in. If possible, shift it on USB or via shared disk storage. Why? Well, the systems are being integrated for business reasons and it is likely that nobody knows for sure how this will all work out. After all, this is a merger/acquisition scenario. The obvious place to do the integration may not survive the detailed analysis of what needs to be done. Better to start with the Simplest Thing That Could Possibly Work, also known as Minimum Progress Required To Declare Victory. After all, if you cannot build a new end-to-end business process that covers both systems manually then you do not understand the requirements sufficiently to start coding it.

Scenario B. Two mission critical computer systems require to share information. They are old, clunky systems that have a significant amount of information and functionality in common. Something needs to be put in place to keep the information set for both applications in sync. Again, I would start with a swivel chair strategy. For two reasons this time. The first reason is as per Scenario A. i.e. if you cannot build a new end-to-end business process that covers both systems manually then you do not understand the requirements sufficiently to start coding it. The second reason is that right now you have two independent mission critical systems that work. Even if you do join them up using IT, the mission critical nature of the systems must be respected. What if the IT-based integration mechanism fails? Catering for such scenarios is vital in mission critical systems and ensuring that the swivel chair can be put into action if needed is an excellent "revert to manual" fall-back to be able to call upon.