Transaction systems maintain synchronization of the stages of their execution sequences. That is a fact; otherwise users would never trust that the results of the process (think about it – you would not want to incur a service fee at your bank because your withdrawal was inadvertently processed before the deposit was processed). And business processes are ordered as well. The company won’t ship the ordered product until the payment is processed.

But at the end of the day we collect all the transactions from all the systems and blend them together by dumping them into the MDM system. The data extracted from each transaction system reflects the result of the day’s transactions but retains little if any history of the order in which transactions took place. And when data extracts are pooled in preparation for identity resolution and record linkage, in essence, without ensuring that the extracted data is processed in the same order as the original transactions were executed, we may be resolving entity information in the wrong order.

The issue is compounded when the different business processes expect the most updated data from the master registry. Recall our example from last time: An online order is processed and when the order is completed, the fulfillment process is triggered. So what happens in the scenario in which the customer updated his shipping address, and that updated address is only modified in the master customer registry at the end of the day? Here are some potential issues:

• If the Fulfillment process pulls the shipping address from the master customer registry, then there is a risk that the item will be packed and shipped to an out-of-date shipping location; or
• If the Fulfillment process needs to wait until the master customer registry is updated, that imposes an artificial delay on shipping; or
• If the Fulfillment process pulls data from the Order system, it is bypassing the customer master, and may miss some other relevant detail that is only available from the MDM system.

I know what you are saying: this is a contrived example, and it would never happen this way. In the cases where the systems are relatively new, you are probably right. Yet think about how many transaction systems in your organization are not real-time, operate in batch, and only forward updates on a daily basis. Then you’ll begin to see where ignoring the transaction synchronization order allows the MDM system to start playing tricks on you…