Connecting A to B: an indirect approach
Paying attention to the nuances of language often pays dividends in enterprise application integration (EIA). Never more so than in the harmless, direct, unambiguous world of phrases like "connecting A to B". Sometimes the best way to connect A to B does not involve connecting A to B at all. Try explaining that to a language pedant.
Now I am not talking about some warping of space/time in order to connect A to B without actually connecting them. I am talking about a slight warping of the English language though. Here is how it works...
Imagine that an integration between two systems A and B is identified as necessary. Perhaps a statement to that effect has come down from the very top. From the CEO perhaps. A and B need to be connected. Integrated. Make it so!
Sometimes, it pays to dig a little bit deeper before proceeding. Why do A and B need to be integrated? There are a number of common scenarios that can usefully be differentiated.
Scenario 1: A needs to send information to B to effect some advance in some business process that B is involved in.
Scenario 2: A needs to send information to B because without it, the reporting module from B will not have the full picture of the state of the business process. The result is that reports from system A and reports from system B must be compared, reconciled and perhaps merged in order to produce the consolidated reports the business needs.
In scenario 1, connecting A directly to B probably makes sense. If system B is the only one that needs the information from A, it probably does not make sense to worry too much about generalizing the hooking together of the business processes.
Scenario 2 however, has a very different feel to it. Here is an integration requirement driven by reporting rather than business process integration. For this type of scenario it often makes sense not to jump directly to inter-connecting A and B. Here is an alternative...
Imagine that systems A and B are both connected to a third system C. The purpose of C is not to do any business process execution. Rather, its goal is to gather up a copy of all the useful business information that systems like A and B hold. That copy is consolidated into a single business view that spans what goes on in A and what goes on in B. Reporting can then be conducted on C, presenting the pleasant and useful illusion that A and B are fully inter-connected...
The beauty of this is its flexibility and extensibility. Data can be transformed on the way out of A and B to make reporting even easier. Other systems can feed data into the reporting layer without any necessity to further change A and B.
This concept has a variety of acronyms and buzzwords in the industry. Some would call it data warehousing. Others, ETL. Still others, business intelligence (BI) or business activity monitoring (BAM). Take your pick!
The important thing is to make sure you look a level deeper into the business driver before you conclude that the way to connect A to B is to, um, connect A to B. Sometimes the best solution is to play loose with the English language instead.