Interoperability

We integrate with X, and Y and Z.

-Any sales brochure.

A common requirement is for Product A to integrate with Product B. Unfortunately, this is often what goes on the requirements matrix. Such a requirement can be open to interpretation.

In short, beware of integration claims by vendors. Each integration requirement should offer specific functionality. Make sure you know exactly what that is. Which company maintains the integration between the two products? What versions of products are supported for the integration? How does the integration work? How long does it take to update the integration after one of the vendors updates their product? What happens if one of the systems goes down? These are just some of the questions that should be asked when dealing with interoperability.

To mitigate the risks associated with writing code to directly integrate products, another approach is to make the products with work a stable neutral ground. The additional complexity makes up by increasing flexibility down the road.

A basic example of this would be if Product A needed to send a file to Product B: It wouldn’t just send the file directly. There would be an output process in Product A to export it to a neutral ground (this could be something as simple as a secure share), and an input process on Product B to monitor the neutral ground and periodically pull all the files in. Depending on the products involved, this could be a very easy or a very difficult process. Naturally, an NTFS share is an oversimplified example.

One integration approach that I found to be cheap, fast and functional is to use a SOA type design. For example, a web service can be created to pull or push data to an application. This service would then be called from the other product. There are even applications that let you design and expose these services graphically. This creates a middle tier that provides a common platform to tie in multiple applications. That middle tier would have ties to all applications that need to play together. The advantages of this approach are self-evident; ease of testing, reliability, fast implementation, less custom code and most importantly component reuse.