On Systems Integration – What’s the problem?


Integrating business systems can be a nightmare, and we who talk confidently of ‘seamless integration’ during sales presentations know this well. The fact is that it’s often a difficult and complex task, and advances in technology have done little to make the task easier. Rather, as systems have become more complex, reaching us wherever we are on devices of many different kinds, integration has become more complex too.

XML, web services, BizTalk, middleware, all these ease the passage of bits and bytes from one system to another, but none solves the underlying problem, which is only partly a technical one.

systems integration

The issue is particularly acute for those of us who sell ‘best-of-breed’ solutions rather than ‘fully integrated’ solutions. A ‘fully integrated’ solution is one where all the functions you need for your business, from accounting, to manufacturing, to distribution, to HR, can be found in a single large piece of commercial software. Whatever integrations are necessary are already there in the software code itself, and in the database that the entire body of code shares.

A ‘best-of-breed’ solution, by contrast, has its own database and software processes and when integration is required, a separate process must obtain data from one database and pass it to another system.

Why is this difficult?

Part of the problem lies the fact that systems often speak very different languages. I don’t mean that they use different programming languages. They may do that too, but that’s not the point. They speak different languages because they don’t always share a common ‘understanding’ of the ‘events’ which drive them and they don’t usually represent ‘events’ or ‘transactions’ in the same way in their respective databases. They may come close, but the devil lies in the detail. What an ‘invoice’ is, or how it is represented in one system, may be different in another. How an ‘item’ is  represented may differ, and so on. At the heart of ‘fully integrated’ systems lie common concepts of what things are and how they are to be represented by data.

Another problem lies in the detection of change. When systems don’t share a database items that are more or less common to both must be replicated from one database to another (you must usually define which is the ‘master’ or the ‘slave’ in this respect) and the relationship may not be one-to-one. To keep both systems up to date you must detect changes as they occur in one in order to pick them up and copy them to the other. You must do this as rapidly as possible if you are not to cause inconsistencies in the behaviour of both.

And of course ‘fully-integrated’ systems complete their processes in response to an ‘event’ (such as the arrival and booking of a supplier invoice), all at once. Such processes are usually designed so that they entirely succeed or entirely fail. Integrated best-of-breed systems, on the other hand, must do things in sequence. Sometimes it matters if systems get out of step with one other, and sometimes one or more steps may fail.

So when you’re integrating best-of-breed solutions there’s an additional task you must execute from time to time. You’re constantly reconciling your systems to ensure completeness and consistency. This is, in itself, an overhead, but the cost of dealing with failure to reconcile, and the know-how you must possess in order to handle this, add further to your system management costs.

So why would anyone ever choose to buy best-of-breed software systems and go to the trouble of integrating them?

There are several good reasons:

  • ‘Fully integrated’ systems are hugely complex. They must cater for far more variation in implementation. They have many more ‘switches’ that you must know how to control.
  • Their complexity makes them more expensive to buy and to implement.
  • They cause more disturbance to the status quo during implementation because you must throw away everything you already have and start all over again.
  • They’re often not as powerful or clever in some particular areas, despite their complexity, so you’ll sometimes need to choose a best-of-breed solution because it fits your particular needs better. These particular needs may be what makes your company special.

Sometimes, indeed often, the implementation of best-of-breed solutions will be the right choice.

But, what’s the best way of minimising the risks?

Let’s look at that in the next post.

2 thoughts on “On Systems Integration – What’s the problem?

  1. On Systems Integration – How to reduce the risk? – Adam Bager

  2. On Integration – Developing Software with Integration in Mind – Adam Bager

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s