Legacy System Integration
A major problem when any two organisations come together is how to merge and integrate their legacy business systems, and in particular their computing systems. At first the excitement is in the merger of the organisations, then reality sets in when the size of the problem emerges. This article explores some of the problems of achieving smooth legacy systems integration.
Two Company Legacy Integration Model
The diagram shows a highly simplified model to illustrate the problems. Both companies are the same size, and in same type of business. As a result they both have to perform similar business processes. In this model we have assumed there are only two processes: taking orders and raising invoices. The first thing to note is each company performs both functions but does different amounts of work for each. And in each of the functions the split between what is done manually, and what is done by a computer differs.
Four Strategies For Legacy Integration
There are four main strategies for legacy systems integration, with advantages and disadvantages for each:
- Keep both systems, and develop them to have the same functionality.
- Replace both systems with a new one.
- Select the best systems from each company and combine them.
- Select one company's systems and drop the other companies.
Strategy 1: Keep Both Legacy Systems
Keeping both systems has the advantage of continuity, with little cost required to retrain people in using a new system. However there are several problems with the approach. The main one is having two lots of support staff; meaning no reduction in costs. However if any attempt is being made to merge the brand, or other aspects of the business the problems are increased, as the two sets of systems are adjusted to be similar to each other.
- First there is a cost in trying to get both systems to have the same functionality. In the diagram the order system for company A covers many functions, but does few of them automatically, whereas company B's order system has few functions but is largely automatic. So matching these two approaches is difficult.
- While this is going on market opportunities can be lost, as the company focus is on the problem of doing similar upgrades to two systems requiring considerable resource.
- Staff that use the system in one half of the business cannot be easily transferred to the other half of the business.
Therefore the strategy of doing nothing can bring no benefits, increased costs, or both.
Strategy 2: Replace Both Legacy Systems
This looks an attractive strategy as one super new system can replace two old systems. The advantage is clear that this will suit the long-term future of the organisation. However there are many problems with this approach as to enable the new system to deliver, all development work on the existing systems must cease, or the new system will never catch up. This means:
- The merged company will operate as two separate companies for considerable time, with the benefits of merging not coming through.
- The developers will mainly be concentrating on the new system, but this still take a long time to appear.
As a result costs initially will be increased, and there will be no flexibility in the organisation for the short term. However in the long term, if the organisation can survive that long, the benefits will be great.
Strategy 3: Select The Best Systems From Each
This is another approach, which sounds great on paper. Each part of a merged organisation will have some state of the art systems, which they believe can be merged with those from the other side to make a super system. This approach is technically flawed. Each organisation over a number of years has produced a number of systems, which operate together. However it is nearly impossible for them to work with systems from another organisation. The main problems are:
- Systems have overlapping functionality. In the example if you integrated Company A's Ordering system with Company B's Invoicing system there would be a great deal of overlap which would have to be dealt with.
- Also there can be gaps. In the example integrating Company A's Invoicing system with Company B's Ordering system leaves a large gap for which a new connecting system may have to be developed.
- File and interchange formats will differ radically between the organisation, which means custom systems being developed to get the existing systems to communicate.
In short the technical problems mean that rather than having two good systems as at present you have one bad system made up of the best of the others; assuming it is ever delivered.
Strategy 4: Select One Company's System
The last major strategy is to select one or other set of systems and use these throughout the new merged company. This in turn will mean that one company's business model will be used throughout. The advantage is that you have a guaranteed system already, so all that has to be done is to grow it to deal with the increased volume of business, implement it, and train the staff from the new organisation to use it. The problems are:
- There can be "political" problems about which to select, though this is easier in a hostile takeover - the winners systems rule!
- Old systems are not well understood by their existing users, so it is difficult to see what changes have to be made to grow them, and how to train the new users.
- During the transfer to one system, little enhancement can take place.
Which Strategy To Use?
The answer as always is it depends.
- If a large firm is taking over a tiny one, then selecting the larger company's system seems the best choice. However there have been examples where the smaller company's system has been chosen magnifying the scaling problems.
- If neither existing system is good, then building a new one is worthwhile.
- If the companies are going to operate as separate entities, with separate brands, then a good case can be made for keeping both existing systems. Especially if there is a chance that the organisations may de-merge in the future.
- Finally even the seeming bad strategy of picking the best from each organisation can work if there is little close coupling between the systems, and so little need to integrate them.
Whichever is chosen a lot of testing needs to be done, including User Acceptance Testing. The two teams from the organisations need to get familiar with whatever is chosen. One of the best ways of doing this is to let people own part of the process by testing the systems.
Testing Issues
- Document Management Software Definitions - basic guidelines for Document Management Software.
- What Is UAT, And Why Do It? - why User Acceptance Testing is important.