In response to: MDM Styles… Going out of StyleTrying to find next series of this good article. I couldn't find under same authors or links towards them. This was a year old article hoping we have published next series.
InfoSphere Master Data Management Best Practices
About this Blog Series
Master Data Management (MDM) solves the common problem of how to provide and maintain the single version of the truth for an information domain such as customer, product or account. Although there has been a lot written about selecting the right “MDM implementation style” for your project, the truth is that a single textbook MDM implementation style is rarely a perfect fit for an enterprise. Many implementations today are faced with designing around a single, less-than-ideal MDM style to simply move their solution forward. Taking this route incurs risk and may leave data owners, past and present, in the political battlefield where MDM solutions may end up stalling needlessly.
This blog series reviews the traditional MDM styles, the problems resulting from these rigid definitions and how adaptive MDM technologies, such as InfoSphere MDM, can address the evolution of an MDM solution in the enterprise. The only constant in an enterprise is change -- adaptive MDM fits you; you shouldn’t have to fit it.
Part 1: MDM Styles
Maintaining a single version of the truth across the enterprise is a must-have in most industries where compliance to standards and regulations is important. Master Data Management (MDM) is an approach that decouples master information from the applications that created it and pulls it all together to provide a single, unified view across business processes, transactional systems, and analytical systems. For a number of years now, my customers have been focused on improving their data quality and establishing prescriptive guidelines for data governance. There are a number of flavors to implementing such a solution - all having the common end goal of being the authoritative provider of timely, high-quality, master data to the information supply chain. An equally important goal is to ensure that master data gets consistently consumed and managed by the enterprise.
Equally common is the fact that each MDM solution tends to have its own nuances. As a result, speaking to the MDM styles in their purest form has one of two effects: it either puts the people in the back row to sleep or generates heated discussion around how the gaps in each of these styles.
The centralized or transactional style is an approach where all information relevant to providing a single view is loaded from the source systems into a new central repository. The matching and collapsing of records across the source systems is done and a single view of the party is typically persisted and updated in this repository. The MDM system now becomes the System of Record (SOR) for storing master data and the operational data management of master data and the source systems may or may not be in the picture still. If they are they may subscribe to consume updates to master data they care about as necessary.
In the registry style, the Systems of Record for master data are the source systems. That is, changes to master data continue be made through existing source systems – data ownership does not move to the MDM hub. Only enough information to match and provide the linkage between very similar or matching records is stored and a trusted view of this information is derived and supplied to the consumer on demand. In this style, a single view of the party is not persisted – master data is owned and modifications to it continue to be made via the source systems.
If MDM were only a technology problem, choosing one implementation style or another might address the need. But MDM is not just a technology problem. The introduction of MDM to an enterprise requires careful thought around existing business processes that need to be retained key new business processes that will be enabled to drive down cost and generate revenue. Implementation teams often find themselves working around these purist styles when they find themselves in more hybrid scenarios – scenarios where both registry and centralized MDM capabilities are required.
For example, it may be that the business is not ready to dive immediately into a centralized MDM implementation, but the business does have a clear plan to have a central authoring source for master data down the road. As another example, the business perhaps has no plan to have a central authoring source at all, but simply wants the flexibility to add information to the centralized version of the party while continuing to make changes to other information via the source systems.
How do you go about centrally managing some master data elements within the context of a registry implementation? How could you retain all source records and at the same time augment the enterprise version of the record with centrally owned attributes in the context of a centralized implementation? Can either of these approaches easily meet both the functional and non-functional requirements of the business?
What is clear from these scenarios and the questions they raise is that most implementations require a flexible mix of registry and centralized, or “hybrid” MDM capabilities. Whether the end goal of an MDM solution is to eventually have a single System of Record for all master data, or just to enable various stages of migrating to this ideal state, your MDM system should be adaptable.
In the next blog entry we will dive deeper into data ownership, the fact that data ownership in and of itself has a lifecycle, and the challenges data governance activities pose to data integration projects.