|
Whenever multiple IT systems need to communicate amongst each other, some typical basic problems arrise.
For example data harmonisation: Consider you have a Customer object that allows your system to link information to a specific customer.
In an ideal world, you would define a global Customer object to be used by all systems.
We call this tight-coupled approach data harmonisation and in the age of monolithic host systems it was a good approach. Harmonised data ensures good data quality, the less you harmonise your data all over your systems, the bigger the risk that information fragmentises and data quality becomes poorer.
On the other hand, a global Customer object that fits the needs of all affected systems could contain too much information for each single system. Maybe the financial systems stores information about the creditability of a customer of which the helpdesk system should not be aware. Perhaps the CRM stores specific marketing information (last sales contact, special eletronic addresses) completely useless for the contract system of e.g. an insurance or bank.
Nowadays approach therefor goes towards wrapping data and passing only the information to a system that is of interest for it.
As you could imagine, very equal problems occur whenever it comes to integrate enterprise systems. Not surprisingly, a lot of enterprise integration patterns were developed, and as there is already a de facto standard book on it (Hohpe and Woolf [sic], see here), you'll find their list of patterns here.
|