Achieving an Effective Enterprise-Wide MDM Model

As companies look to implement MDM across multiple data domains, this naturally creates the need to examine how to best coordinate and prioritize multi-domain activity and focus, particularly in regards to technology needs, quality improvement priorities, and demand for budget and IT resources. As with Customer MDM, the other data domains will typically start their MDM initiative by creating a charter and data governance team to establish the foundation needed to move forward. Although much of the MDM context and needs will be unique within each MDM domain, there are many common elements of MDM that can begin to compete and cause unnecessary redundancy across multiple domains if they are not effectively coordinated.

Coordination of these common elements may initially fall to an executive steering committee expected to oversee multiple MDM initiatives, but over time this responsibility is likely to shift to an enterprise MDM or Enterprise Data Governance type program office where a more specific team and set of resources are responsible to help facilitate and support cross-domain MDM needs by providing various tools and services. Figure 12.1 provides a simple example of an enterprise MDM model.

Figure 12.1 Enterprise MDM Model Example

The concept and charter for an enterprise MDM program office makes sense from a coordination and efficiency standpoint, but—a word of caution here—if the program office charter is too broad and overly controlling it can start overshooting its value if it takes away authority and empowerment from the domain specific MDM teams by attempting to create too much of a homogeneous enterprise MDM. Because many aspects of quality management, governance, and stewardship are unique within each domain, they should not be impeded with excessive central program office control. A well-conceived enterprise MDM program office should always be cognizant of how to continually coordinate and enable MDM programs and avoid over-managing where control and conformance is unnecessary. Otherwise this can become a path back to a stiff, stifling model that, as we have stated frequently, is not conducive to MDM growth and maturity.

If an MDM program is already successfully underway, a program office should continue to keep that runway open and as clear as possible. A program office needs to cultivate an environment where a maturing MDM team can lead by example with developing best practices, which other MDM teams can leverage to accelerate their domain implementations. Because Customer MDM is often the first MDM implementation, the foundation it creates for data governance, data stewardship, data quality management, and data access management practices create very repeatable models that can provide extensible technology to help prime the start-up or sustainability of other MDM implementations. Techniques and examples we have provided throughout this book can easily be adapted to other data domains, and it makes perfect sense to leverage the knowledge and experience from an existing MDM practice to help launch more MDM initiatives.

There are also many IT-oriented services needed in MDM such as metadata management, data analysis, data integration, data cleanup, or development of reports where competing demand is likely to occur across multiple MDM programs. An MDM program office needs to ensure that these services are as extensible and scalable as possible in order to manage the demand as economically and efficiently as possible. Launching too many MDM initiatives side by side with common dependencies and demand on IT can quickly lead to overload and bottleneck scenarios causing deliverables to be delayed, which can negatively impact the progress and expected deliverables across all the MDM initiatives. For example, consider these hypothetical scenarios:

• An aggressive enterprise MDM plan has launched MDM programs across multiple master data domains. In support of the MDM master plan, IT is implementing a third-party product that will provide the platform, methodology, and functionality for data quality analysis, metrics, scorecards, and quality monitoring across multi-domains. Use of this solution for completing the initial data analysis and quality scorecard is a required step before the MDM core teams can complete and submit their quality improvement proposals for the executive steering committee to review. However, IT has just indicated there will be a delay in the product implementation due to some recently determined technical complications and the need to work out some contract support issues with the vendor. Availability and use of the product will be more limited than expected until these issues are fully resolved. The MDM program office and MDM core teams are considering the impact of this and what options exist in the interim to still move forward with the data analysis and quality assessment needs.
• Internal development and deployment of a common metadata management repository is expected to enable the MDM teams to formally capture, organize, and support their metadata, business policies, standards, and work instruction material. However, the initial plan and conceptual design of this seems to be getting overrun with more requirements and functionally complicated elements that apparently will be needed to support the multi-domain and multi-entity levels of segmentation that are expected in this solution. There is growing concern that this may not be a feasible solution due to the growing complexity. The enterprise MDM steering committee is reevaluating the metadata management plan and approach.

These scenarios are examples of where overdependence or overkill may exist with technology plans. Where technology implementations are a key part of the plan for launching MDM programs, a program office should be prepared with alternate or interim plans to help mitigate technology delays or if the technology needs to phase in more slowly than had been expected. An MDM master plan and program office needs to carefully weigh out how and where technology can potentially create major dependencies, timing issues, and program implementation impacts.