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.
