Master Data Management (MDM) solutions are considered to hold the master for any given entity.
In computing, master data management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional_data (often Dimensional Data Modeling - Dimension (Perspective) of a cube and not a Dimensional Data Modeling - Fact Table) entities of an organization (also called reference data) :
MDM has the objective of providing processes for :
to ensure :
and control in the ongoing maintenance and application use of this information.
A MDM solution works basicly in two points:
However, most large enterprises have a heterogeneous application portfolio, with fragments of often inaccurate, incomplete and inconsistent data residing in various application silos. No comprehensive system contains the single view or is designed to manage the complete life cycle of the master data.
The MDM product trends to improve data Data Quality - Role (data steward) and governance facilities, including :
MDM systems are software products that:
MDM architectural styles vary in:
The applicability of the data model to your organization is a fundamental requirement. It must:
A good data model has little value if it lacks accurate, up-to-date data. MDM for data products should:
MDM products need to provide data integration facilities for loading the data in a fast, efficient and accurate manner. There will also be a need for data and application integration capabilities, including publish-and-subscribe mechanisms, to provide a communication backbone for the bidirectional flow of data between the central database (or hub) and the spoke systems. These facilities may be provided by the MDM vendor or by offering tight integration with products from specialist data and application integration partners. MDM for data products should be able to:
Many leading organizations plan to use the new master database as the basis for new operational and analytical applications. In the enterprise service-oriented architecture (SOA) world, service-oriented composite business applications may consume MDM for data business services through Web services standard interfaces.
MDM for customer data products should protect and complement the data layer with a layer of business services, at granular and more-coarse-grained levels, for accessing and manipulating the customer data that is built for an SOA environment, and exposing Web services interfaces.
In addition, there are some scenarios (such as collaborative centralized authoring or data quality improvement of customer data) in which MDM for data systems require a collaborative workflow capability and need to support their own business process modeling capabilities. In other scenarios (such as forming part of a wider, end-to-end create-customer process), they need to interact with enterprise business process management (BPM) tools. As MDM becomes core to SOA strategies, this MDM/BPM suite capability may need to be reconciled with the enterprise BPM strategy.
If an MDM for data product supports operational and analytical applications and is tightly integrated with established systems and new applications, then serious demands are likely to be made on its performance, scalability and availability. MDM for data products should have:
This functionality involves the availability of facilities for managing the MDM for data system, such as facilities for reporting on activities within the system. In addition, these capabilities include integrating the MDM for data system with common system management and security tools. On the security and data privacy management front, this involves the ability to:
The ability of MDM for data products to support a range of analytics from the performance of the technology, the MDM-enabled business processes themselves, as well as the accuracy of the master data. The MDM for data product needs to support users' ability to flexibly define data quality based on usage and use case, and to use these definitions in a real-time manner to report up-to-date information on the performance of MDM processes. This may be achieved by tight integration with a BI solution that embeds the analytics in the MDM for customer data system, or by an inherent analytical capability. The analytics need to extend across:
MDM for data products should be based on up-to-date, mainstream technologies and should be capable of flexible and effective integration with a wide range of application and infrastructure platform components (from one or more vendors) within the user organizations. They should be capable of flexible configuration into a range of architectural styles in terms of instantiation, latency and use of customer master data to enable it to satisfy such use case scenarios as consolidation, registry, coexistence and transaction scenarios. The vendors are also measured on the capabilities of their architectures to support global rollouts and localized international installations.
This service and support area includes:
The data also needs to be made available to the supply chain and contract management systems. And to ensure sales alignment, the MDM system needs to make customer and product information available to the data warehousing system for accurate and timely analysis and reporting.
A synchronization with both operational and analytical systems may also be essential to effectively address the specific business needs of your organization.
A multi-entity deployment (such as customer and product) and an architectural style that is not restricted to registry alone.
The challenge in employing the concept of “return on investment” for justifying the funding of an improvement project is the ability to monitor, over time, whether the improvements implemented through the project are facilitating the promised positive impacts.
Example of goal :
To succeed, you should put together a balanced MDM program that creates a shared vision and strategy, addresses governance and organizational issues, leverages the appropriate technology and architecture, and creates the necessary processes and metrics.
A pragmatic place to begin is to answer these three questions:
For example :
Next identify how business users will use the master data within their business processes to determine the most appropriate architectural style and usage modes to support the needs of the business users. For instance, to ensure that the same contracted rates for procuring different direct materials from a supplier are made available at different touch points, the MDM system needs to reconcile conflicting vendor, contract, and direct materials data and then centrally store it—an architectural style analysts call coexistence or transactional.
Finally, it is important to understand the business requirements for governing the master data to determine the requirements for master data availability, usability, integrity, and security.
For instance :
DQ Metric | Customer Data Quality Rule | Description or Example |
---|---|---|
Completeness | Attribute completeness | Discovers # and % of null values |
Completeness | Contact Completeness | Requires all name, address, SSN, … are not null |
Conformity | Data Type | Data type, length, & precision documented & found |
Conformity | Data Domain | All values are within specified domain |
Uniqueness | Restricted values | Values are not in a list of restricted values: e.g. “66666…”… |
Uniqueness | Unique Key discovery | Discovers # and % of unique values |
Pattern and Common Format | Name Standardization | First, Middle and Last name not null & properly capitalized |
Pattern and Common Format | Common Pattern | Common pattern required (e.g. phone, email), % conformity |
Pattern and Common Format | Name Capitalization | “Aaaa”, “Aaa Bbbb”, “Aa-Bbb”, … |
Pattern and Common Format | Extended Phone Numbers International Phone Numbers | More extensive definition of allowable phone number formats. Can extend to specific country formats, etc. |
No Access Lists | by Name Only by Name or SSN by Email List | Restriction lists for specific records, filtered by name, SSN and/or emails |