Systems Integration

I have recently noticed with a number of clients an interesting phenomenon. A project starts life as an application roll out or an upgrade but morphs over time into a systems integration project. First things first, what do we mean when we talk about systems integration?

Systems integration projects have a number of characteristic properties:

• The is a single holistic desired business outcome with an identified business sponsor accountable for achievement of this outcome;
• The outcome can not be achieved by delivery of a single isolated application but requires multiple applications integrated in some way, or a single application integrated with other back-end systems in some way;
• There are multiple organisational entities involved in delivery of the overall system. These could be external entities such as multiple suppliers delivering to the client, or could involve multiple internal entities, particularly in larger organisations.

What is striking about these evolved systems integration projects is that by accident or design some of the basics of systems integration get ignored, leading to fundamental (and in some case irresolvable) problems with systems delivery. Examples include:

• Having a clearly defined and baselined set of requirements under configuration and change management;
• Having a prime who is accountable for end to end systems integration. The National Programme for IT is a classic example of how things can go wrong when there isn’t a prime - you can’t federate systems integration;
• Putting in place mechanisms which allow individual suppliers to perform partial integration testing of their components. This could be for example provision of a sandpit environment or provision of test harnesses that suppliers can use in their own environments.

In future blogs I will return to some of these themes and explore them in more detail.