As I discussed in Part 1 portion of this blog, MDM is not a tool, but rather is a discipline that can be implemented in an organization through a program. And MDM Program could leverage a solution (referred to it as an MDM Platform) to help manage master data. So what is an MDM Platform made of? Before I answer that, I would like to point out again that an MDM Program is not single dimensional but rather has 4 dimensions as I listed in Part 1:
Therefore, any solution for MDM should be made of components that correspond to these dimensions. Also since these dimensions are related, the components need to be designed in an integrated fashion.
An MDM platform then has the following components:
- Data Governance – Includes data stewardship, change management, policies, standards, communication, and workflow functionality
- Data Quality – Data profiling, validation, search before create, integration ability with 3rdparty validation services
- Standard CRUD Services – Provides data services based on standard CRUD processes with encapsulation of business rules and DQ validation and Data Governance
- Master Data IntegrationLayer – Common data integration layer for ETL and access by downstream systems manageable by governance rules for data usage
- Single Master Data Source – A single data repository for master data attributes as the source for creation and access
- Single Master Data Architecture – A common data architecture for every master data object in alignment with business processes that ensures uniqueness and scalability.
Now, when we look at the list of MDM Platform components above, we can see that each can have a great deal of functionalities that can enable the management of master data. Each component’s functionality can be implemented in a variety of ways using different technologies and techniques. For example, Data Quality has much functionality associated to it and there are a lot of vendors that use different technologies and approaches to provide different solutions. That is true for data integration and all other components as well.
Before we get into the tools options, I think we need to address the different solution implementation. It is important to note at this point though that an effective MDM Program (and thus an MDM Platform) should have all these components in an integrated fashion to address most or all of an MDM Program’s need. There are tools that offer all the components in an integrated fashion. There are also vendors that offer only specific components in the above list. So what are your options? In general there are three approaches to MDM Platform implementation:
OPTION A: Full Vendor MDM Tool Implementation
IMPACT: Replacement of all existing MDM Solutions and Repositories, replacing all existing data integration for Master Data. More holistic, but very expensive and may not be scalable for future technology as components are tightly coupled
OPTION B: Full in House MDM Tool Build
IMPACT: Incremental deployment, replacing only some of the existing data integration for Master Data. Less expensive in short run but expensive in long term and will not scale as well we the components that are offered by industry core competency
OPTION C: Integrated Best of Breed MDM Platform
IMPACT: Leverages existing usable components and repositories. Uses best of breed for each component but integrate tightly through SOA. Less impact on IT and business, can be implemented incrementally, scalable as components can be replaced for future technology without impacting the solution
Having come from a business solution architecture background, it has been proven to me that an integrated solution of components is always better than tightly coupled solutions or functionalities. The architecture of integrated architecture is more flexible and scalable. It is flexible in a sense that it would allow you to pick the best current or future functionality and technology to support it without breaking the whole solution. It is scalable because it allows you to scale your solution to more functionalities and integration to other components, applications, or systems without impacting the integrity of the solution as a whole. But clearly this choice is requires careful architectural analysis as well. Sometimes the existing Architecture has already integrated the master data with ERP’s transactional functionality so tightly that it would be very costly to introduce new or external components to the mix. Also, there are ERP systems whose data models are not normalized (or even normal J) enough to allow easy integration of other best of breed components. Sorry, can’t name names!
So in conclusion, yes, I would say you must MDM, but MDM it right! Understand what MDM is and what it means to your organization. Then try to educate your executives or peers to understand that MDM should be an integral part of the company’s operation and culture. And make sure that you don’t make the mistake of thinking that MDM covers all your data management needs. Master data is important, but it is not all the data that you need to manage in your company.
Finally, in reality, master data management can be done without any fancy tools, but the tools will just makes things easier and more scalable. I am a firm believer that Information Management has existed way before technology has. If you can wrap your mind around that concept, then technology becomes your friend and you would think clearly when choosing the right vendor or tool for your data management needs.
But perhaps that is the subject for another blog! 🙂
(Original publish and Copyright date 2011 © Majd Izadian)