SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

By Philip Russom

tdwi.org

TDWI RESE A RCH

Sponsored by

TDWI CHECKLIST REPORT

2 FOREWORD

3 NUMBER ONE MDM needs DG’s collaborative environment.

4 NUMBER TWO MDM needs DG’s stewardship capabilities.

4 NUMBER THREE MDM needs DG’s change management process.

5 NUMBER FOUR MDM needs DG’s mandate.

5 NUMBER FIVE MDM needs DG as it grows into enterprise scope.

6 NUMBER SIX MDM needs DG’s guidance as it matures into new generations.

6 NUMBER SEVEN MDM needs DG to support its priorities.

7 ABOUT OUR SPONSOR

7 ABOUT THE TDWI CHECKLIST REPORT SERIES

7 ABOUT THE AUTHOR

7 ABOUT TDWI RESEARCH

© 2012 by TDWI (The Data Warehousing InstituteTM), a division of 1105 Media, Inc. All rights reserved. Reproductions in whole or in part are prohibited except by written permission. E-mail requests or feedback to info@tdwi.org. Product and company names mentioned herein may be trademarks and/or registered trademarks of their respective companies.

AUGUST 2012

SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

TABLE OF CONTENTS

1201 Monster Road SW, Suite 250 Renton, WA 98057

T 425.277.9126 F 425.687.2842 E info@tdwi.org

tdwi.org

TDWI CHECKLIST REPORT

By Philip Russom

2 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

FOREWORD

According to a recent TDWI survey, many of the challenges to master data management (MDM) are organizational and collaborative issues—not technical ones.1 (See Figure 1.) Luckily, many of MDM’s challenges can be remedied by a well-designed and mature program for data governance (DG). For example:

Half of users surveyed (56%) realize that MDM can be hamstrung without DG. The similar practice of data stewardship is also critical. As this report explains, MDM can suffer without DG’s processes for collaboration, stewardship, and change management.

MDM’s broad goals are hard to reach without support from business management. DG programs are usually founded on a strong mandate, and DG can share this mandate with related practices such as MDM to provide executive sponsorship (40%) and a business case (34%).

An MDM program won’t get far without ample collaboration. A mature DG program is inherently collaborative, providing processes for cross-functional cooperation (38%) and coordination with other data disciplines (20%), especially data integration and quality.

DG’s collaborative process gets MDM past many roadblocks. Common examples include turf wars over data ownership (21%) and squabbles over master data definitions (17%).

Hence, there are good technology and business reasons why master data management needs data governance. This TDWI Checklist Report drills into these reasons as well as use cases and organizational situations where DG and MDM work well together.

1 According to the 2012 TDWI Best Practices Report Next Generation Master Data Management, available at tdwi.org. See the discussion around Figure 4.

DEFINING MDM AND DGFor readers who are new to MDM and DG, here’s a brief overview of each.

Master data management (MDM) is the practice of developing consistent definitions of business entities (such as customers, products, financials, or partners), then expressing the definitions in reference data. MDM’s entity definitions and reference data facilitate the accurate sharing of data across the IT systems of multiple departments and possibly outward to business partners. MDM can improve data-driven initiatives such as business intelligence, integrating business units via common data, 360-degree views, supply chain efficiency, the compliant use of data, and customer interactions that span multiple touch points.

Data governance (DG) is manifested as an executive-level board, committee, or other organizational structure that creates and enforces policies and procedures for the business use and technical management of data across an enterprise. A mature data governance program has two mandates with different but related goals:

1. DG’s compliance and related business goals are mostly about controlling people’s access to data for compliance purposes with internal and external regulations for data usage. The same controls may also reduce risk exposure relative to data.

2. DG also has data standards and related technical goals. Compliance and related issues aside, DG should also adjudicate internal standards for data quality, integration, data models, and MDM’s reference data. The goal is to improve data and make it uniform so that it’s easier to share enterprisewide as a global asset. Note that DG must be mature enough to embrace these technology goals if it is to foster MDM and similar disciplines such as data quality and integration.

Lack of data governance or stewardship 55%

Lack of executive sponsorship 40%

Lack of cross-functional cooperation 39%

Lack of business driver or business case 34%

Turf wars over data ownership 21%

Coordination with other disciplines (DI, DQ) 20%

Squabbles over master data definitions 17%

Figure 1. Challenges to MDM success. Source: TDWI Best Practices Report Next Generation Master Data Management, Q2 2012.

3 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

COLLABORATIVE DGA well-designed and mature program for data governance will foster collaboration about data both within and among different groups of people. (See Figure 2.) To enable broad collaboration, DG should be staffed by a mix of people from multiple business and technical functions.

Business management goals. Business people take the lead to determine business goals and communicate them in the context of data. Business managers and data professionals on the governance board then collaborate to map business management goals to data requirements that data management teams can act on.

Data management teams. Achieving complex business goals for data usually involves the work of multiple data management teams. Data governance serves many purposes, and one is to provide an organizational structure for collaboration and coordination of diverse data management teams and solutions. Multiple technical teams need to develop and agree to common models, architectures, interfaces, and so on.

Alignment of data management with business goals. When collaborative data governance works well, the result is a pragmatic and sometimes visionary alignment of data management work to business management’s goals.

Assuming an organization has a DG program, an MDM program can tap its resources. Instead of reinventing the wheel with its own, independent collaborative process, MDM programs should rely on DG and its collaborative organizational structure to achieve a richer and broader reach. Additional benefits come with collaborative DG, such as an executive mandate, enterprise reach, procedures for change management, and processes for proposing data standards.

Align data management work to business goals.

Figure 2. Collaborative data governance.

NUMBER ONEMDM NEEDS DG’S COLLABORATIVE ENVIRONMENT.

COLLABORATIVE MDMBy definition, MDM is a collaborative discipline that requires plenty of communication and coordination among individuals in several types of roles. This is especially true of entity definitions, because there is rarely one person who knows all the details that must go into a standard definition of a customer or other entity. The situation is compounded when multiple definitions of an entity are required to make reference data “fit for purpose” across multiple IT systems, lines of business, and geographies.

For example, sales, customer service, and finance all interact with customers, but they have different priorities that should be reflected in a comprehensive entity model. Likewise, preexisting IT systems may have technical requirements that the model must address. Many entities are complex hierarchies or have dependencies that take several people to sort out, as in a bill of material (for products) or a chart of accounts (for financials).

Once a definition is created from a business viewpoint, further collaboration and review are needed to gain approval before applying the definition to IT systems. At some point, business and technical people must come together to decide how best to translate the definition into the required technical media (typically reference data in master data sets).

Furthermore, technical people working on disparate systems must collaborate to develop the data standards needed for the exchange and synchronization of reference data across systems. Because applying MDM definitions often requires that changes be made to IT systems, managing those changes demands even more collaboration.

That’s a lot of collaboration! To organize it all, many firms put together an organizational structure where interested parties can come together and communicate according to a well-defined business process. For this purpose, data governance committees or boards have become popular, although stewardship programs and competency centers may also provide a collaborative process for MDM and other data management disciplines (especially data quality and integration).

Determine and communicate business

goals and their data requirements

Coordinate diverse data management teams

and their solutions

4 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

When a DG program governs data standards (not just compliance issues), it gains a practical efficiency from incorporating data stewardship. After all, a knowledgeable manager (acting as a data steward) can prioritize data management work to align with business goals, giving the firm the biggest bang for its buck. In the context of MDM, stewards assigned by a DG program can likewise supply prioritization and business alignment for reference data, master data sets, and standards for the exchange and aggregation of reference data.

Many IT and business people have told TDWI that their MDM programs would not have started successfully without DG and stewardship. “Data governance with a stewardship slant was a critical success factor for MDM because it got the business people involved up front [by forcing them to prioritize master data problems] and helped them understand how their business goals are linked to master data elements,” said the manager of enterprise information architecture at a national retail chain.

According to the 2012 TDWI MDM survey and report mentioned earlier, 49% of users surveyed are using “data governance and stewardship functions” with MDM today. An additional 41% will adopt these in the next three years.2 TDWI recommends that user organizations build data stewardship into their data governance programs so that centralized stewardship is enlightened by and contributes to DG’s compliance policies and data standards.

USER STORY

STEWARDSHIP AND OTHER PROGRAMS CAN LEAD TO A DG PROGRAM.According to an executive at an Internet-based firm in financial services, “Our founders were experienced with Six Sigma methods for product quality, so it’s natural that we had a data quality program early on in the 1990s, inspired by Six Sigma. From data quality, we learned data stewardship, and we made it our habit that each business head is a steward who’s responsible for the quality of data in his or her department. When new regulations arrived in the early 2000s, we extended our concept of stewardship to become data governance, such that business heads are now also responsible for the compliant use of applications and data.”

MDM NEEDS DG’S STEWARDSHIP CAPABILITIES.

NUMBER TWO

MDM NEEDS DG’S CHANGE MANAGEMENT PROCESS.

NUMBER THREE

One of the many things that MDM and data quality (DQ) programs have in common is that both inevitably require changes to be made to data owned by a variety of departments and sponsors. Similarly, they regularly require changes in how workers use diverse applications. We’ve already seen a track record of success with DQ changes being mandated and policed through the processes and policies of a DG board. We’re now seeing more organizations do the same with the changes that are required by MDM programs.

Here’s a bare-bones look at a typical DG process. The example is for a change order relevant to MDM or DQ programs, but the process would be similar for other situations.

Discuss a data problem or opportunity as well as its solution. Typical problems include redundant data driving up direct marketing costs or poor customer services due to a lack of standards for exchanging reference data across business units.

Propose a change or improvement. Solutions may include a specific form of matching to deduplicate a master data set or a standard record structure for exchanging reference data.

Review the proposed change. All stakeholders should read and react to the proposal. Other experts (who aren’t stakeholders per se) should also weigh in and add insight.

Revise the proposal and work toward consensus—whether approval or rejection. If approved, the proposal becomes an official DG policy or change order. The DG committee publishes documentation and alerts named parties.

Police the policy. DG committee members must periodically check that named parties and systems are complying as described in a policy or change order.

RECOMMENDATIONS CONCERNING DG PROCESSES FOR CHANGE MANAGEMENTEstablish a DG program first. Do this before initiating cross-functional, change-oriented measures for DQ and MDM.

Don’t reinvent data management processes per DQ and MDM programs. When possible, have one set of processes expressed via a DG program.

Realize that DQ and MDM both involve data standards. Develop those standards through a central DG program for greater clout and broader enterprise adoption, as well as to avoid competing standards from multiple sources.2 Ibid. See the discussion around Figure 12.

5 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

MDM NEEDS DG’S MANDATE.

NUMBER FOUR

Instead of establishing its own executive mandate and sponsorship, MDM should leverage DG’s mandate. After all, a DG program would not come into existence without a powerful mandate, and it’s unlikely that MDM or any other point solution can attain DG’s depth of clout and breadth of influence.

Even so, note that a DG committee should be selective about the data management disciplines, teams, solutions, and data sets that it decides to govern. As a DG committee takes on new responsibilities, its commitment should be apparent if the executive mandate it enjoys is to be effective as incentive.

Therefore, when a DG board takes on governance responsibilities for MDM, there needs to be visible, prioritized MDM work that results almost immediately. For instance, a common reason for DG to intervene in MDM is to force feuding parties to agree to one or more definitions of “customer.” Likewise, a DG intervention might be in order when data and application owners won’t share or receive reference data. Similarly, technical teams sometimes can’t decide on a common exchange standard for reference data or a common data model for aggregating master data sets.

USER STORY

BIG CHANGES BENEFIT FROM DG’S MANDATE AND CHANGE MANAGEMENT.“After a few acquisitions in the early 2000s, we were eager to execute the leading reason for the acquisitions, namely cross-selling across multiple customer bases,” said the vice president of sales at a regional U.S. bank. “Customer data is critical to a successful cross-sell. Unfortunately, the data we had was from multiple firms, on various vendor platforms, in several data models—and each piece was owned by somebody. Luckily, we had the presence of mind to establish a data governance program that brought all these parties together so they could understand the urgency of the executive mandate and then contribute to the new world of customer data we had to build. Thanks to the collaboration and change management process of data governance, we quickly developed standards for customer data’s quality and reference models. Within a year, we had customer data merged into the condition we needed to execute a successful cross-sell campaign.”

According to the 2012 TDWI MDM research survey, most MDM solutions deployed today are silos (44%), and few organizations practice MDM with an enterprise scope (17%).3 This is a deplorable situation when you consider that one of the primary goals of any serious MDM implementation is to improve reference and master data so they become an enterprise asset that is easily shared and integrated among multiple applications, databases, and data domains across an entire enterprise.

HOW DID MDM GET SO SILOED?Silos are easy starting points, and they tend to succeed because they have obvious sponsors (typically a department head) and business cases (the needs of a single department). Furthermore, silos avoid potential showstoppers such as a lack of cross-functional cooperation. Success is good when the first generation of an MDM solution has such a narrow focus, and this explains why most MDM solutions deployed today are silos. Yet, the result is inherently limited to visibility for a single data domain within a single department. This approach leads to multiple silos (sometimes redundant and competing) that need consolidation or integration in a later generation, when enterprise-scope MDM is required.

HOW CAN MDM OVERCOME ITS SILOS AND BECOME ENTERPRISE IN SCOPE?When data governance is administered by a central, enterprise organizational body, it is inherently anti-silo. DG is almost always focused on data that travels. For example, data that is accessed and used by multiple departments is more of a compliance risk than data that never leaves a department. Likewise, the data standards for quality, integration, and reference data models that most DG boards adjudicate are usually designed for data that travels among various departments and their IT systems. Hence, a DG program can be instrumental in getting reference and master data to travel beyond their silos of origin and be shared and integrated with other systems, which is the first step toward MDM’s ultimate goal: treating reference and master data as a communal asset of enterprise scope.

MDM NEEDS DG AS IT GROWS INTO ENTERPRISE SCOPE.

NUMBER FIVE

3 Ibid. See the discussion around Figure 2.

6 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

MDM NEEDS DG’S GUIDANCE AS IT MATURES INTO NEW GENERATIONS.

NUMBER SIX

Instead of an MDM team making isolated decisions about the future functionality they will develop, imagine that team proposing such R&D decisions to a DG board. This way, the members of the board (from many business and technical functions) can offer advice and support that will help MDM solutions fit into larger business goals and enterprise data standards.

This level of scrutiny by a DG board is probably not appropriate to small details on an MDM solution’s release schedule. However, major releases and generational changes merit examination. Furthermore, MDM will eventually become enterprise infrastructure that is shared across departments, and MDM development decisions that impact infrastructure and multiple departments should be governed.

Guidance from DG is important right now because the majority of MDM programs and solutions are facing a redesign, major retrofit, or replacement that we can recognize as a generation. The next generation of MDM takes many forms:

• Some MDM programs focus on one data domain (often customers), and they need to move on to other domains. A DG board can prioritize enterprise needs relative to data domains and drive common domain definitions that coordinate or consolidate multiple MDM solutions.

• Many MDM solutions are siloed, whereas the goal of enterprise MDM is to integrate reference data across multiple applications. DG provides cross-department collaboration that can kick-start multi-application MDM solutions as well as provide data exchange standards.

• Most MDM solutions are built on simple hubs that do offline aggregation and standardization for reference data. Collaborative DG can help prioritize new functionality for these hubs, such as two-way data sync, real-time operation, identity resolution, and service bus integration.

Recent TDWI survey data shows that half of surveyed organizations plan to replace their MDM platform(s) within the next few years. Reasons for such a dramatic generational change center on the need for better solution architecture and interfaces, plus a need to scale up to more data domains and departments. All these impact the broad access to and use of a central MDM solution, and so they should be subject to governance.

MDM NEEDS DG TO SUPPORT ITS PRIORITIES.

NUMBER SEVEN

No organization implements MDM on a whim. MDM solutions are developed and deployed so that business processes and goals can be supported by data about specific entities and domains. Here are examples of how data governance can help MDM solutions deliver the master data sets and reference data that a business needs. The examples are in priority order as determined by TDWI’s MDM research survey.4

The need for a 360-degree view is the most common reason users implement MDM. A true 360-degree view collects reference data about a specific entity (customer, product, or partner) and aggregates it into a domain-specific master data set. Collaborative data governance provides procedures for requesting access to reference data and application changes that leverage views.

The need to share data across an enterprise is the second leading reason for MDM. DG enables people from various functions to collaborate and develop standards for data exchange and data models for the master data sets through which aggregated reference data is often shared.

Making data-based decisions is a high priority for MDM. Sixteen percent of survey respondents chose this as a first priority; another 15% say it’s a secondary priority. Likewise, customer intelligence is a first (13%) and second priority (13%) for MDM. BI professionals love data governance both because its collaborative processes get them access to more data and because its change management procedures improve data upstream so that it’s in better condition for downstream decision making.

MDM assists DG with compliance issues. This Checklist Report has described several examples of how DG assists MDM. But in closing, let’s flip that around and consider how MDM helps DG with compliance issues. Non-compliance can lead to an audit, whether you are audited by a government agency, a business partner, a legal team, or your employees. Surviving an audit is mostly about providing credible information to auditors, and MDM’s documentation of entity definitions and master data sets adds a lot of credibility to the audit trail.

4 Ibid. See the discussion around Figure 3.

7 TDWI RESE ARCH tdwi.org

TDWI CHECKLIST REPORT: SEVEN REASONS WHY MASTER DATA MANAGEMENT NEEDS DATA GOVERNANCE

www.dataflux.com

With data quality, MDM, and data governance capabilities, SAS DataFlux helps organizations develop and execute an end-to-end data management strategy. Through a unified development and delivery environment, SAS DataFlux helps organizations manage every phase of data management. Through an intuitive interface that empowers both IT and business to complete data management objectives, SAS DataFlux ensures consistent, accurate, and timely data throughout the enterprise.

ABOUT OUR SPONSOR

ABOUT THE TDWI CHECKLIST REPORT SERIES

TDWI Checklist Reports provide an overview of success factors for a specific project in business intelligence, data warehousing, or a related data management discipline. Companies may use this overview to get organized before beginning a project or to identify goals and areas of improvement for current projects.

TDWI Research provides research and advice for business intelligence and data warehousing professionals worldwide. TDWI Research focuses exclusively on BI/DW issues and teams up with industry thought leaders and practitioners to deliver both broad and deep understanding of the business and technical challenges surrounding the deployment and use of business intelligence and data warehousing solutions. TDWI Research offers in-depth research reports, commentary, inquiry services, and topical conferences as well as strategic planning services to user and vendor organizations.

ABOUT TDWI RESEARCH

Philip Russom is the research director for data management at The Data Warehousing Institute (TDWI), where he oversees many of TDWI’s research-oriented publications, services, and events. He’s been an industry analyst at Forrester Research and Giga Information Group, where he researched, wrote, spoke, and consulted about BI issues. Before that, Russom worked in technical and marketing positions for various database vendors. Over the years, Russom has produced more than 500 publications and speeches. You can reach him at prussom@tdwi.org.

ABOUT THE AUTHOR

SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are trademarks of their respective companies. 105975_S97530.0912