Measuring Trust

Deciding which systems are trusted to update a master record can be daunting. Tools and techniques have been developed to measure and rank systems in order to calculate “trust” but just how practical are these in the real world?

By Martin Dunn

Architecture

In a previous life I developed the idea that you could measure the degree of trust you have in an attribute on a master data record. Together with our development team we built algorithms that accounted for the source of the data, age of the data, typical rate of decay for the type of data and the timeline over which this trust factor decays. This concept of trust still endures today in several technologies and it has become a staple term of the MDM industry.

However we came to realize that in practical terms, trust is more digital than analog.  You either trust something or you do not. An algorithm to calculate trust may produce an analog result, but the outcome results in one of three states – Trusted, Untrusted and Unsure. Within the Trusted and Untrusted states there can be no differentiation. By definition, if you have any doubt around your decision, then you are Unsure.

Another practical lesson is that trust is best assigned to a contributing system for any Master Data attribute or collection of attributes.

The major factors that contribute to trust include:

  1. The reliance of the system on the accuracy of this information
  2. Consistency of the definition of the data within the system and the MDM
  3. Validation in the system or business process that results in the update

1. Reliance of the System on the Data

 

A system is not reliant upon all of the data it stores. A lot of the data stored in any given application is supplementary. For example, a logistics system that prints shipping labels is reliant upon the shipping address but not telephone number, even if the telephone number is also printed on the shipping label.

Information on which a system is reliant is obviously more trustworthy than data that is supplementary to this system.

2. Consistency of Data Definition

 

Extending the logistics example, the logistics system provides a record of where an item was actually shipped and not necessarily the default address to which the customer usually has items shipped. If our MDM model calls for the default shipping address then the logistics system may not be a trusted source of this data after all.

A clear definition of the MDM data model is required to clarify where we source the trusted data.

3. Validation within the Business Process

 

Without additional validation, the data within a system is only as good as the interfaces that feed the system or the user that enters the data (gulp!). If the logistics system we have used as an example relies upon a user typing in a shipping label from a fax, then our trust would be degraded significantly. On the other hand, if the logistics system is fed directly from an online store, and the address is certified by the USPS database before a label is printed, then our trust would be enhanced.

Summary

 

The macro factors that define trust can be applied at a system level for any given attribute or collection of attributes. Systems should be classified as either trusted or untrusted sources of data. If data is changed within a trusted source, then this update should be applied to the master record. Changes to data in untrusted systems should not update the master record without further validation.

Martin Dunn

Author

Martin Dunn was the co-founder of Delos Technology which developed the MDM technology marketed under the Siperian brand. The Delos MDM technology introduced many MDM concepts that are now widespread within the MDM discipline including a data steward console to adjudicate match results, opt-in synchronization, cell level delta detection and the concept of measuring trust.

Martin is now a partner with Gaine Solutions and continues to advance the techniques by which enterprise Master Data is managed.

Related Posts

Opt-in Synchronization

Opt-in SynchronizationNot all operational systems will choose to, or be able to, consume the changes made to master data in an MDM hub. The reasons for being out-of-synchronization may be technical, regulatory, political or economic but at some point it will be...

Changing a Match Rule

Changing a Match RuleWhen we are talking to companies about our MDM platform we cover a broad range of topics, from measuring ROI, to more technical questions about the way the software operates. A common technical question is "How do we change a match rule?" Our...

Ready to master data mastering?

Subscribe to our mailing list and we’ll send you courses, insights, product updates, and more. Get to know the ins-and-outs of your Gaine MDX platform, features, and solutions.