MDM Multi-Domain Planning And Challenges, by Mark Allen
Our latest article is by Mark Allen, the co-author of a Master Data Management in Practice – Achieving True Customer MDM.
In the May 30th, 2011 edition of Hub Designs Magazine, you may recall the article The System of Record in MDM by Dalton Cervo (who is also the co-author of our new book Master Data Management in Practice: Achieving True Customer MDM).
In the article, Dalton aptly pointed out the underlying importance and challenges associated with defining a system of record (SOR) approach needed to enable a single version of the truth in a master data hub environment.
Expanding from that SOR aspect, MDM as a whole is an ongoing set of processes and disciplines aimed at achieving and maintaining a single version of the truth within one or more master data domains. Companies will typically begin their MDM focus in one master data domain area and expand to more domains with implementation of a multi-domain program model.
In some cases there may be a multi-domain plan from the start, but usually a single domain like Customer or Product will still be the starting point and set the program tone for subsequent domains. When taking this multi-domain leap, it is critical to determine what aspects of MDM planning and execution can be repeatable and scalable across the domains, as well as what are the domain specific elements. With that in mind, here are some perspectives and questions that are important to consider when pursing a multi-domain model.
Defining domains in a multi-domain model
There are a number of commonly identified MDM domains that are often referenced in MDM literature and business case examples such as Customer, Product, Locations, Materials, Employee, Supplier, and a few others that represent master data areas common to most business practices.
Depending on the business model, industry orientation, and application platforms involved, the actual master domains or domain names that a company defines may deviate somewhat from those common domain types. In fact, it would not be unusual in a multi-domain implementation to see a mix of domain types where the leading domains are some of the common MDM domains, followed by other data domains that may not necessarily fit a true MDM definition — such as a more transactionally oriented data set — but where MDM type disciplines can still be applied to achieve a desired level of improvement, consistency, and value with that data.
In such cases, this may appear to be an unconventional approach, but in practice it is reasonable to expect that regardless of the original intent and context, good data management practices and disciplines such as MDM will usually find their way into more general usage over time. A multi-domain model can often become a vehicle where good MDM practices become more generally applied across a company’s data sets. This is actually goodness, so keep in mind that the multi-domain makeup does not always have to be limited to just the master data context.
Prioritizing in a multi-domain model
As is often the case, starting an MDM initiative with a focus on the Customer or Product domain certainly makes sense since the viability and sustainability of most companies rests on customer and product dynamics. Most all sales, marketing, financial, service, and analytical functions in a company are tied to these customer and product dynamics, so this can be a natural starting point for MDM before venturing further.
Once the most critical domains area addressed, it will usually be easier for other data domain programs to get started and aligned within the overall MDM plan. However, there can be many strategic, operational, and technical reasons that can influence domain implementation order.
The MDM business case and investment decisions should be driving the overall MDM roadmap based on priorities that are typically associated with risk mitigation, revenue growth, cost reduction, or business efficiency. The MDM priorities are also going to be influenced by things like executive sponsorship, available resources, business process impacts, new technology, BI needs, and budget forecasts.
When planning a multi-domain program, sufficient time is needed to work out the right implementation approach, examine business impacts, determine critical path dependencies, and to define the ongoing program management model. Not fully addressing these items will likely lead to various program impacts and priority adjustments.
It is the business functions and transactional areas who are the primary creators and consumers of the master data, and since most transactional areas will interact with master data from multiple domains, the domain implementation plan and order can have significant impact on business operations. So be sure to plan and prioritize wisely.
Distinguishing the Program Management Office role from the data domain role
Implementing MDM across multiple domains 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.
A multi-domain MDM plan needs to start by creating a distinct enterprise level Program Management Office (PMO) charter and core team to establish the program foundation needed to move forward. In some cases, this charter may be assigned to an enterprise data governance group. However established, this is the program office that will need to provide the cross-domain program leadership, policies, standards, services, and core resources to help facilitate and support the multi-domain model. Each domain should still have its own domain specific program scope, responsibilities, and resources, but this should be in alignment with the multi-domain model and policies that the PMO puts forth.
Depending on an organization’s model and approach, the role and responsibility mix between the PMO and domain charters can vary, but generally there should be a clear separation of duties conducive to a collaborative and supportive relationship. Because many aspects of quality management, governance, and stewardship focus are unique within each domain, this should not be impeded by excessive PMO control.
If the PMO charter is too broad, overly controlling, and attempts to create too much of a homogeneous multi-domain model, it can start overshooting its value if it takes away authority and empowerment from the domain specific teams.
A multi-domain MDM program should not be a cookie-cutter process or a follow the bouncing ball type of affair. Rather, it is very much the orchestration of unique programs that have common threads and are on a common enterprise MDM mission but with different domain specific objectives and priorities. A well-conceived PMO should always be cognizant of how to continually coordinate and enable the various domain programs and avoid over-managing where control and conformance is not necessary, otherwise this can become a path toward a stifling model that is not conducive to overall MDM growth and maturity.
A PMO needs to cultivate an environment where a maturing MDM domain team can lead by example with developing best practices which other domain teams can leverage to accelerate their maturity. The leading domain implementation needs extra attention so that the business foundation it creates for data governance, stewardship, quality management, and technology usage, can create repeatable models to help prime the start up of the other domain implementations. This is critical for driving sustainability across the overall MDM model. Leveraging the knowledge, practices, and experience from a leading MDM practice should be a key strategy in a multi-domain plan.
There are also many IT-oriented services needed in MDM such as metadata management, data analysis, data integration, data cleanup, or development of metrics and reports where competing demand is likely to occur across multiple MDM programs. The PMO 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 and each 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.
Also, when planning your multi-domain program be careful not to create too many critical path dependencies on new technology because, as we all painfully know, these implementations will often be subject to delays and functionality issues. There are many business project areas of MDM programs (e.g. data governance, data steward setup, business analysis, process improvement, and many program management tasks) that don’t depend on technology, so be sure these type project areas and tasks are sufficiently identified in the program plan and can still move forward while other technology issues are being addressed.
Additional things to consider
Beyond what I have already covered about planning and implementing a multi-domain model, here are some other important questions and perspectives that should be considered:
- Can your IT models and practices sufficiently adjust to provide more flexibility and collaborative support across business-driven MDM programs?
- How much capacity will business and IT organizations have to support requirements and demands from a multi-domain plan?
- Will new technology actually help enable more MDM efficiency and accelerate ROI?
- Will any anticipated organizational change be a disruptive factor, enough to preclude a multi-domain MDM initiative from succeeding?
Simply stated, when planning and implementing a multi-domain model, expect a lot of variables and do the math. Complete necessary business analysis to fully identify what MDM and data governance oriented needs, benefits, and impacts can be expected; what will apply across the domains; and what will be associated to a specific domain. Gear your PMO office to help successfully facilitate the common and unique elements while also driving the domain programs to stay in scope of the overall enterprise MDM model and objectives.
A multi-domain plan can easily be a 3-5 year journey, but if persistently and successfully pursued, this should result in highly consistent and unified data management practices across the enterprise that can greatly benefit a company’s operational and analytical foundation.
I truly believe that MDM has the ability to drive more operational efficiency through continued application and maturity of its core disciplines in a multi-domain model. And while MDM oriented technology continues to be introduced that can greatly assist multi-domain implementations, fundamentally it is the due diligence done in the MDM planning stages and the ability to implement a flexible MDM program foundation that enables the efficient and cost effective application of the technology.
Mark Allen has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.