|Research, training, consultancy and software to reduce IT costs|
Minimal integration 11: integrate software packages
Integrating software packages is easy if you have a clear idea of what you are trying to achieve and if you ask the right questions. But you will have problems if you abdicate integration to the package vendor.
You should integrate commercial software packages in the same way as home-written systems.
It is particularly important that, after they are connected, packaged software and your other systems can be changed independently of each other. Your interfaces should even allow the package to be substituted without disrupting the other systems. To achieve this, you must not simply accept the interfaces provided by the package. Design the interfaces to and from the package to meet your business needs. Use simple XML and your chosen data transfer standards.
Of course the package will not implement your interface design directly. Build an intermediate process to convert between your design and the interfaces provided by the package. Usually the easiest way to do this is to write an additional interface layer which is implemented close to the package itself. The package then appears to all other systems to be implementing your interface design.
Sometimes there are irreconcilable differences of meaning between your interface design and the package's interfaces. These differences should be treated just the same as any other areas where business requirements do not match. Either the business has to accept the meaning of the package, or the package has to change. You can not solve these problems in integration code.
If you need to connect two packages, integrate each one using these rules. Do not bypass this by building a special interface between them. This would not be easy to maintain and would not allow you to easily connect other systems to either package.
Sometimes package vendors claim to have pre-built interfaces to packages from other vendors. I have never seen one that works and meets requirements. Only consider these if the vendor is contractually bound to keep them up-to-date across all possible combinations of versions of both packages.
Make sure you ask vendors the right questions. I used to ask vendors, "Can you integrate using XML and WMQ?" Every single one said "yes". But in practice their support for these standards was very weak indeed.
The right question is, "What is the best way of integrating into your system?" This lets you play to the strengths of each package by using it as it was designed. Although you will have to convert between the vendor's interfaces and your own design, at least you will be well supported by the vendor.
There is a common theme running through all of this. We have problems with package integration when we abdicate to the package vendor the responsibility for defining business meaning, for integrating to other packages, or for implementing our own standards. Although it may seem that the vendor is giving added value, it is a false economy. Meeting these responsibilities yourself is a much simpler and cheaper option.Next: Minimal integration 12: integration summarised
Minimal IT: research, training, consultancy and software to reduce IT costs.