Much of the talking and doing related to Master Data Management (MDM) today revolves around the master data repository being the central data store for information about customers, suppliers and other parties, products, locations, assets and what else are regarded as master data entities.
The difficulties in MDM implementations are often experienced because master data are born, maintained and consumed in a range of applications as ERP systems, CRM solutions and heaps of specialized applications.
It would be nice if these applications were MDM aware. But usually they are not.
As discussed in the post Service Oriented Data Quality the concepts of Service Oriented Architecture (SOA) makes a lot of sense in deploying data quality tool capacities that goes beyond the classic batch cleansing approach.
In the same way, we also need SOA thinking when we have to make the master data repository doing useful stuff all over the scattered application landscape that most organizations live with today and probably will in the future.
MDM functionality deployed as SOA components have a lot to offer, as for example:
- Reuse is one of the core principles of SOA. Having the same master data quality rules applied to every entry point of the same sort of master data will help with consistency.
- Interoperability will make it possible to deploy master data quality prevention as close to the root as possible.
- Composability makes it possible to combine functionality with different advantages – e.g. combining internal master data lookup with external reference data lookup.
I agree 100% with what you’re saying here. The day where application data can sit in silos that are oblivious to each other is rapidly coming to an end. It’s fortunate that we have so many great tools that make it possible to wrap, layer and interface those nuggets of business goodness in such away that they can be composed, correlated and aggregated in meaningful ways.
Thanks for your optimistic comment Jeremy.