Establishing Multi-Domain Data Governance
This chapter covers the discipline and practice of data governance in a multi-domain model, including the relationships and focus needed between data governance and the Master Data Management (MDM) program management office, business areas, and information technology (IT). In addition, it will provide strategies and examples of how to establish a consistent, transparent governance model across MDM domains.
Throughout Part 1 of this book, we have emphasized the relationship needed between MDM and data governance. In this book’s preface, we described MDM as “the application of discipline and control over master data in order to achieve a consistent, trusted, and shared representation of the master data.”
Now, let’s also consider the definition of data governance provided by the DAMA Data Management Body of Knowledge (DMBOK 2010):
Data governance is the exercise of authority and control (planning, monitoring, and enforcement) over the management of data assets.
The words discipline, authority, control, and data assets used in these definitions convey the common objectives of MDM and data governance.
Chapter 1 mentioned that as much as data governance does not require MDM, the opposite is not true, especially in an inherently complex, multi-domain MDM. Whether the MDM model is top-down, middle-out, agile, or hybrid, an MDM program requires strong data governance support at many points. As MDM is expanded into more domains that cover an increasing amount of master data, the need for data governance becomes even more critical because the data management activities, decisions, prioritization of work, and user base naturally increase as well. And as MDM focus expands across more operational and analytical groups, each of these groups can have different or competing data management practices, data definitions, views, metrics, and quality requirements for the master data that it uses.
The challenge for data governance and the MDM Program Management Office (PMO) becomes how to move domain master data from a fragmented state into a more conformed state and, ultimately, into a more integrated state. Figure 6.1 illustrates this concept. As master data moves into a more integrated state, the data governance focus will shift more toward the enterprise management and quality control of the data. As the MDM program and data governance processes mature, the management and quality control of master data become more embedded in the day-to-day business operations and IT functions, largely through data stewardship roles and quality monitoring processes.
The extent of how much a domain can achieve a conformed state or integrated state depends on the information model and systems architecture within each domain area. For example, a domain with a data hub architecture and operational data store (ODS) will be positioned well to support a highly integrated state, whereas a more federated architecture may only be able to achieve a conformed state through the implementation and enforcement of common standards across various source systems and process areas. But in either case, without a data governance process to define and drive the necessary policies, standards, and rules to support conformed and integrated states, the individual business or analytical groups will make decisions that best serve their own interests, but those may not necessarily be sound enterprise decisions. This will only perpetuate a fragmented state. Therefore, the MDM PMO and data governance need to develop a strong partnership to ensure that decisions related to master data are fully vetted and support enterprise strategies, policies, and standards.
The Data Governance Role and Relationship with MDM
The MDM PMO, like most program and project teams, focuses primarily on the planning and implementation of MDM objectives, infrastructure, and deliverables. During the planning and implementation phases, many issues and conflicts regarding usage, definition, and alignment of master data will be revealed that exist across the business process areas. Chapter 2 described how these cross-functional differences are revealed when examining the sources and use cases of master data.
The ability to resolve many of these cross-functional issues exceed the scope of the MDM PMO and require an authoritative data governance process to be engaged. In a multi-domain MDM strategy, the MDM program will need data governance to help establish priorities, make domain selections and data ownership decisions, and address various issue/resolution needs that will emerge from the MDM PMO and business process areas. If such a data governance process is not already available for the MDM program to use, the strategy and execution plan for MDM will need to identify data governance as a critical path dependency, and the MDM program itself will need to become the driving force for the implementation of a data governance process.
Figure 4.2 in Chapter 4 provided a high-level illustration of the roles and relationship between the MDM program, data governance, and operational process areas where data stewards need to be engaged. Now let’s take a closer look at those roles indicated for data governance and how they relate to the MDM program.
Domain Jurisdiction and Line of Business (LOB) Representation
As is often pointed out, data governance should be primarily a business-driven process, but defining the governance model and aligning business functions to specific data domains and associated governance bodies may not always be straightforward. It can require some deeper assessment to align business representation with the domain structures and their jurisdictions. Some business models, such as a Health Care model that has line of business (LOB) areas such as Member, Provider, Contracts, Claims, and Care Management, will have their data domains and subject areas described in a similar way thus enabling alignment between business functions and data domains. However, within a product- and manufacturing-oriented business model with LOB areas such as Marketing, Sales, Operations, Service, and Finance, there will not be clear functional alignment with data domains such as Customer, Product, Partner, Supplier, and Materials (the typical data domains in this type of business model).
Organizational structures and the hierarchies within them will not typically provide obvious alignments to a data domain. Organizationally, business units are more vertical, whereas data domains will typically have a more horizontal alignment across various business units that use the data. Figure 6.2 provides an example of these vertical and horizontal relationships and shows where business functions intersect with data domains. Examining these relationships and how these functions interact with data will reveal the type of representation and interests that the functional area should have with a data domain, particularly as it applies to the management and control of master data.
Figure 6.2 also suggests why the governance of master data in a multi-domain model will require a federated data governance approach. If an existing data governance process has been operating with a centralized approach—that is, one committee or council that has a singular authority for data governance decisions, policies, and standards across the business and IT functions—the planning and implementation of a multi-domain MDM strategy require the governance process to take on a federated approach. This is needed create more specific data governance and quality management focus for each domain, but still operate within a common overall enterprise data governance framework with oversight from an executive steering committee.
Federated Data Governance
A federated data governance model is a structure that supports decisions, policies, standards, and information sharing between multiple semiautonomous entities, such as data domains, committees, business and IT functions, and projects. A federated data governance model is typically used in a complex business model to ensure that decisions made within or across these semiautonomous bodies represent outcomes that are consistent with or support enterprisewide standards and strategies. A federated model will usually have a steering committee that oversees the governance process and addresses issues or needs that can’t be addressed at the domain level. Figure 6.3 provides an example of a federated data governance model.
Data Governance Team Resources
More often than not, staffing a data governance team sufficiently will become a continual challenge in a multi-domain model. Conceptually, most data governance team structures aim to have a multitier team structure involving an executive sponsor layer, a decision-making layer, a data steward layer, and they may also include some IT support roles, such as business analyst, data analyst, or data architect. In practice, however, it may be difficult to fully enlist all these team members because these people will usually have other full-time roles and responsibilities that can create commitment conflicts. Most business areas and their leadership teams will acknowledge the needs and benefits of data governance but be reluctant to commit their time and sponsorship if they don’t have an immediate stake in the game or they don’t see a direct connection between data governance objectives and their business goals or revenue numbers for the year.
A reasonable approach is to have a data governance process work with business areas to identify various services and facilitation support to help implement a foundational level of data governance structure that can start demonstrating value. Over time, as the value proposition and visibility of this data governance process grows, so will the level of participation and support. In other words, be prepared for data governance to begin as a lean program that needs to apply data governance disciplines in project areas that are very receptive to and require data governance. Build governance value and recognition through those opportunities and use those attributes to continue to build a broader business case for expanding data governance. A MDM initiative should have these data governance requirements and provide the foundation for data governance to mature as the MDM program expands across more domains.
Bench Strength
Data governance should always have good bench strength to ensure that subject matter experts are available to participate in the many topics and decisions that need to be covered. For example, at times, there will be topics that may require representation from corporate functions such as Legal, Finance, Compliance, Security, or Human Resources (HR). Maintaining a good relationship and current set of contacts with personnel representing these corporate functions can greatly enhance the timeliness and effectiveness of data governance. And because business leaders who participate in the governance process are typically very busy, the team leader should work with the governance team members who have the authority to identify who they are comfortable to have act as proxies for these business leaders when they are unavailable to participate. Ideally, these people would be other existing members of the governance team who are familiar with the process and topics.
Define Policies and Rules
Master data is largely a fixed asset, with only a limited amount of ability to maintain, change, enrich, or cleanse it. Therefore, the value of master data is highly dependent on how accurately they are captured and how relevant they are in the context of their usage. The responsibility for developing master data, therefore, falls primarily on the data entry and operational processes. These data entry and operational processes are where the MDM program and data governance need to have sufficient influence and policies to ensure that data standards and quality control expectations are visible and actively enforced during the processes.
The ability to accurately capture master data often depends on how and where the data is entered and to what degree this data entry is subject to quality and integrity control conditions, such as format control, validation rules, reference data, user guidelines, and so on. Local data entry is typically influenced by the requirements and limitations associated with the particular application and business process being used. These types of data-entry conditions can vary by system, application, region, country, or any combination of these.
The net result is that the aggregate quality and consistency of this data from these various entry processes will undoubtedly be poor unless common policies, rules, and standards have been applied to these data entry and operational processes by a data governance process. This is where data governance influence matters the most to master data. The extent that data governance policies, rules, standards, and monitoring capability can directly influence master data entry practices and operational processes—but without undue burden that could negatively affect transactional performance—reflect how effectively data governance is operational within a company. Policies, rules, and standards will have little impact if they are not appropriately positioned and effectively enforced.
There needs to be a good balance, with the ability to execute and enforce policies, not just create and post them. A policy without the ability to execute and enforce it is of little value. Keep in mind that in most programs and projects, the resources needed for execution are always in short supply; therefore, any manager will typically assign resources based on execution needs rather than policy needs. This is an area where the MDM PMO or data governance team can help provide services to address policy needs without affecting project deliverables.
Quality Standards and Priorities
Chapter 5 presented examples of several data governance–related milestones that are important to the maturity of a multi-domain MDM model. Two of those milestones suggest the need for data governance to establish policies, standards, and priorities related to master data quality management and measurement:
• Data management policies and standards have been defined and implemented.
• Measurements and dashboards are in place to measure and drive master data quality and control.
Let’s take a closer look at these items to more fully describe how data governance–driven quality standards and priorities for master data are critical factors for an MDM program.
Data management policies and standards have been defined and implemented
For a multi-domain MDM program, being able to define and implement such policies, standards, and priorities across the master data requires a mature, cross-functional governance model with an executive steering committee to work through them. Considering that at various times in a multi-domain model, each MDM domain implementation will likely be at a different point in the MDM maturity model (as shown in Figures 5.2 and 5.3 in Chapter 5), the prioritization and execution of MDM policies and standards will be influenced by the maturity of these domains.
A mature MDM domain that has identified its master data assets, the sources and processes involved, the data touch points, and has established an accountable and responsive data governance process, will be ready to define and implement the quality policies and standards necessary to drive more quality control of the master data. Whereas a domain still in the early stages of its MDM plan and still in the process of identifying its MDM assets and touch points will not be ready to clearly understand what quality management policies and standards are needed and where they will need to be positioned. An existing data governance program may already have some broad policies and standards defined that may apply to all domains. For example, there may be standard change control policies, data integration rules, or quality measurement standards and rules that each domain will need to adopt. Execution of these enterprise policies and standards within the MDM program should be coordinated by the MDM PMO and the data governance program.
As more MDM domains are implemented, expect the need for additional quality policies and standards to emerge. As the MDM scope expands, more reference data and business term conflicts are likely to be discovered. As these conflicts or overlaps are discovered, these cases should be brought into the data governance process, where enterprisewide standards can be determined for adoption and enforcement.
Measurements and dashboards are in place to measure and monitor master data quality and control
In a multi-domain model, data governance needs to examine data quality measurement needs, any existing practices, and the ability to achieve a standard, common approach to measure and monitor data quality. If prior to implementation of MDM practices, a particular business area or data warehouse environment already has high-quality measurement and dashboard practices, such as reuse of various quality profiling rules, quality dimension definitions (e.g., how quality dimensions such as completeness, consistency, accuracy, and validity are defined) and quality scorecard formats, those practices may be good candidates for enterprisewide adoption. The data governance process should review existing data quality measurement practices, agree if any existing practices can serve an enterprise’s best practices, and determine the policies and the adoption needed to ensure that this will become standard operating procedure in the enterprise. Having such standards in place enables an MDM program to quickly absorb these standards and move forward.
Unfortunately, such enterprisewide quality standards that are ready for multi-domain adoption and use will not generally exist in a company. Similar to the previous discussion about reference data and business terms, various organizations and functions are more likely to have their own versions of quality measurement and reporting practices. In this scenario, the MDM PMO and data governance process will need to examine the variations and their requirements to propose and gain agreement on a standard approach for enterprise data quality measurement and reporting formats. Chapters 9 and 11 will provide further detail on more specific quality and performance measurement.
Issue Resolution
Chapter 4 mentioned that having clear charters and good working relationships between the data management support teams, MDM PMO, and data governance process will make it straightforward for support teams to be able to reach out to, or formally escalate master data issues to, the MDM PMO or data governance bodies per established engagement roles and responsibilities. Formally defining these engagement guidelines will help identify the type of items or issues that should be in scope across these relationships and how and when the data governance process should be engaged. A data governance team should also be aware of the other support and decision-making channels to ensure that any items not within the data governance scope that are being submitted by a person or team can be routed to the correct support group, hence avoiding any further misdirection or significant process delays.
Figure 6.4 provides an example of a common set of issues and how these should be coordinated between the support teams, MDM PMO, and data governance process. The engagement rules between these groups can vary depending on the actual agreements and functional roles, but this type of matrix will be very helpful for communication and training purposes across the MDM program.
A governance process should also provide clear guidance and good templates where needed to assist the submitting person or group with providing governance-ready information for the governance team to evaluate and act on. These details should include sufficient information, including the following.
The data governance program overview should clearly describe:
• The data governance charter, purpose, and value statements
• Key guiding principles and program objectives
• The data governance framework and management structure
• The functional model, intake process, key processes, and deliverables
• Operating governance teams and future roadmap
• Location of the program website and additional reference material and program websites
The data governance engagement guidelines should have the following elements:
• Guidelines for how and when to engage data governance
• Examples of in-scope and out-of-scope items or issues
• Who to contact if there are any scope or engagement questions
Item/issue submission, tracking, and presenting should include:
• A submission template indicating all required information
• An accessible log for tracking status and details from open to close
• A template for presenting material to the governance team
When an item submitted to data governance gets returned to the submitter, that most often occurs because it lacks sufficient detail or clarity for the data governance team to act on it. And this is usually due to insufficient background, context, or clarity as to what is being asked of the governance team. Gathering more information or clarifying the open questions usually results in getting the item accepted into the data governance process. If the approval and implementation of the submitted item require any further development, research, processes, or other specific task activity, the submitting party may need to be prepared to offer the funding necessary for this additional work to be executed.
Data governance groups often can only review and approve the concepts, proposals, solution approaches, policies, and standards or guidelines associated with the data item. They don’t have the scope or ability to assign resources for implementing many types of corrective action. Here are some examples of actions that typically are beyond the scope of data governance:
• Application fixes or enhancements
• Operational process improvements
• Data-quality corrections at the source
• Process area user guides and training
A well-established data governance process will frequently be engaged in the review, approval, and prioritization of these type of items, but implementing the corrective action typically needs to be addressed by the MDM PMO, project teams, IT functions, or business process areas that actually own the applications or processes needing correction. These application or process areas are likely to have a change control process to address the corrective action request, and depending on the impact and level of effort involved, there may need to be funding required from the requesting party to implement the correction. The application or business process area may have the budget in place for planned improvements and may also have some discretionary funding set aside for handling other low- to medium-effort corrections, but otherwise, funding may be required from the area requesting the change.
Therefore, as data governance items are submitted and reviewed, the submitting party and the data governance team need to know that a decision made supporting a corrective action could be subject to funding requirements in order for the action to be executed. A mature data governance process should be aware of these types of cases and set expectations accordingly to help the requesting party consider its funding responsibilities should such arrangements be necessary. Similar to the discussion in Chapter 4 regarding the importance of building cross-functional alignment, the data governance scope should be clear and appropriate engagement guidelines established with other functional areas. This will distinguish the data governance scope, function, and capabilities from other IT, project, or process management functions that own the actual change control and implementation processes for the applications and business processes.
All significant items or issues that data governance accepts and addresses should be formally entered into an issue/item tracking process that will capture sufficient detail regarding the nature of the requesting person and group, the nature of the request, supporting details, summaries of discussions and decisions or other outcome details, what governance members or teams were involved, and any other information that provides clarity and acceptable detail from an auditing perspective. Data governance always needs to clearly track how, where, and why decisions were made. In a multi-domain MDM model, the data governance intake and closure process should also be able to clearly identify and record what data domains the issue/item is associated with. During the intake process, this can trigger an alert with the MDM PMO and domain team leads, who then can determine if they or other people will need to be involved in solving the problem, and on the closure side, this can trigger closure communication with the interested parties.
Enterprise Communication
A standard artifact of any data governance process should be a RACI chart to identify what roles are responsible or accountable for, or consulted or informed about various decision events. A RACI chart can and often will be customized to best suit the decision process and communication model dynamics, but however it takes shape, the RACI concept is important to a high-functioning governance process. This RACI chart provides a vehicle where master data decisions can be leveraged to ensure that there is clear engagement and communication for these decisions. Figure 6.5 provides an example of a RACI chart.
In general, the tracking and management of key communication items as they relate to master data should be managed closely by the MDM PMO using the data governance RACI chart as a communication tool. Although these audiences on the RACI chart will also be interested in other data governance–related communications, they should always be kept informed about any major policies, standards, rules, changes, events, and other important items involving master data.
Conclusion
This chapter covered the discipline and practice of data governance in a multi-domain model, including the relationships and focus needed between data governance and the MDM PMO, business areas, and IT. The discussion provided strategies and examples for how to establish a consistent, transparent governance model across MDM domains, with an emphasis on developing a federated approach where master data issue tracking, decision making, communication, policies and standards, and corrective action can best be addressed in a cross-functional manner. As MDM expands into more domains covering a larger amount of master data, the need for data governance becomes even more critical because the data management activities, stewardship needs, and prioritization of work efforts become inherently more complex, resulting in the need for more governance authority, policies, and standards to help manage this.
Because master data has many touch points and consumers, data governance needs to ensure that the data domain structure and business functions are aligned across the business model. This will enable the MDM PMO to effectively leverage the data governance model for support with communications, issues, decisions, and corrective action needs that require cross-functional engagement across a diverse application and business process landscape.