logosm- real time data quality maintenance, conversions, and cleansing

sign in

Single source of truth when implementing MDM - it is not black and white

Written by Dianne Arneberg on 10/29/2012

In my many discussions on Master Data Management (MDM) a common goal is to achieve a single source of truth.  This literally means that data should only be stored once but really in terms of MDM it often really means that the data is consistent and visible in one place.  If you don't have consistency of master data across systems you can end up with differences in the exact same attribute across different systems.  This is bound to happen if the exact same system is maintained in different applications by different people. This does not necessarily mean that the all attributes must be maintained in a single system.  You need to be practical in terms of your approach for best managing the maintenance process.

An example can be the customer name.  If you maintain the official name of the customer in your CRM system, ERP system, Service system and Install Base application (system that tracks all serial numbers of what has been installed with a customer) and if this is maintained by different people it is highly unlikely that all the people change the name of the company or even bother to keep track of such changes at the same time (i.e. Apple Computers Inc. changes to Apple Inc.).  Unless you have either a Master Data Management process in place (which can be manual or integrated through automation) you will end up with differences across the different systems dependent on the name.

To maintain consistency and avoid this problem the obvious solution is to go in a direction where the different attributes of the master data record is maintained in a single system and then publish the changes to recipient systems.  You now end up with consistency across the different systems.  The direction then becomes to maintain all attributes to a master record in the Master Data Management system.  This is also known as an Enterprise Service Bus (ESB).  Though this seems a reasonable and logic solution to the problem the issue becomes that the number and complexity of managing the LOV of attributes and complexity of the integration becomes unmanageable.  Additionally the process for making changes becomes cumbersome and slows down the ability to make changes quickly.  

Instead of this black-and-white approach of maintaining everything centrally or fully distributed the answer lies somewhere in between and unfortunately not as simple from an IT perspective to optimize the control of attributes while at the same time making the process as flexible and fast as possible. The best approach is to balance which attributes are centralized vs. which are distributed.  I like to categrize the attributes in to the following categories when looking at the different attributes related to a master record:

(1) Multi-system dependent attribute.  Attribute which multiple systems are dependent on and typically defined early on in the process definition of a record such as official name, ship to address with trading partners or net weight, description or category when assessing SKU's / Product Master.  Single Source of Truth (SSOT) can be achieved in multiple different ways:

  • Select a single "source system" to be the owning system and publish changes in the the MDM system where the attribute is published to dependent systems
  • Maintain the attribute directly in the MDM system and publish to dependent systems
  • Not optimal but a "poor man's integration option" is to have a frequent comparison of the attribute values in different systems and then manually update the found changes

(2) Single system attribute but informative to others.  There are likely many attributes which are really only used in a single but may be useful to be viewed by multiple other groups but may not have direct access to those systems who "owns" the attribute.  An example of this can be Engineering related attributes related to the Product/Item Master. These types of attributes is likely managed in a PLM Engineering application and may be useful for others to be visible to who may not have access to the PLM Engineering applications.  Adding User access to these applications can often result in additional license fees where it may only be necessary to provide the information to a large set of users.  

For these types of attributes the best option is to let the system who owns the attribute manage the assignment of values there and instead publish to the MDM system where it can be visible to other low-frequency users.  If this is forced to be managed in the MDM system and have the data owners request updates to the MDM or even be required to log in to the MDM system to update. If the process becomes too cumbersome or takes significant effort they will simply not update the value and the information becomes stale and outdated.

(3) Single system attribute.  Some attributes may be of limited interest to other systems and should be kept outside of the MDM system and retain only the link to the entity it represents to the MDM system. Avoid cluttering up and overcomplicating the MDM system with information which has little interest to others outside the specific users who depend on the information.  An example could be the "planning time fence" which may only be relevant to a few planners within the whole company.  

In summary, Single Source of Truth in my mind means that relevant attributes are visible in one place such as in a MDM system.  It does not mean that all related attributes needs to be visible in the MDM system.  It does not mean that the ownership of maintenance should be owned in a single system.  




Leave a comment