David Loshin, president of Knowledge Integrity, Inc., is a recognized thought leader and expert consultant in the areas of data quality, master data management and business intelligence. David is a prolific author regarding data management best practices, via the expert channel at b-eye-network.com and numerous books, white papers, and web seminars on a variety of data management best practices. His book, Business Intelligence: The Savvy Manager’s Guide (June 2003) has been hailed as a resource allowing readers to “gain an understanding of business intelligence, business management disciplines, data warehousing and how all of the pieces work together.” His book, Master Data Management, has been endorsed by data management industry leaders, and his valuable MDM insights can be reviewed at mdmbook.com . David is also the author of The Practitioner’s Guide to Data Quality Improvement. He can be reached at loshin@knowledge-integrity.com.
In my last post, I pointed out that we data quality practitioners want to apply data quality assertions to data instances to validate data in process, but the dynamic nature of data must be contrasted with our assumptions about how quality measures are applied to static records. In practice, the
After working in the data quality industry for a number of years, I have realized that most practitioners tend to have a rather rigid perception of the assertions about the quality of data. Either a data set conforms to the set of data quality criteria and is deemed to be acceptable
With our recent client engagements in which the organization is implementing one or more master data management (MDM) projects, I have been advocating that a task to design a demonstration application be added to the early part of the project plan. Many early MDM implementers seem to have taken the
In the last post we looked at the use case for master data in which the consuming application expected a single unique representative record for each unique entity. This would be valuable in situations for batch accesses like SQL queries where aggregates are associated with one and only one entity record.
Last time I suggested that there are some typical use cases for master data, and this week we will examine the desire for accessibility to a presumed “golden” record that represents “the single source of truth” for a specific entity. I put both of those terms in quotes because I
I have probably touched on this topic many times before: accessing the data that has been loaded into a master data environment. In recent weeks some client experiences are really highlighting something that is increasingly apparent (and should be obvious) for master data management: the need to demonstrate that it
Transaction systems that feed master data repositories ensure a degree of synchronization that ensures proper transaction execution. The transaction processing system generally only looks at a few records at one time, and updates are committed so that they do not interfere with other transactions. Transaction within each subsystem are isolated
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
A way of paraphrasing what I suggested in my last post was that as master data practitioners, we are often focused too much on pulling data from source systems to populate a master entity model and not focused enough on understanding how dependencies across business processes may influence the proper
I thought it might be worth taking a short break from discussing metadata and instead cycle back to an idea that has been challenging me recently in a few of our current MDM consulting engagements. I have been examining patterns for master data use, and one of the common recurring
