A global master data system is the authoritative source of nontransactional data that describes the core entities of a business (e.g., customers, products, merchants) and their relationships (e.g., hierarchies). In essence, master data systems organize profile data for these entities. In an ideal architecture, master data is referenced (not replicated) by both analytical and operational systems (see Figure 1). In reality, the enterprise's profile data is dispersed and duplicated across multiple applications, compromising the integrity of the company's most valuable data assets and making it ill-suited as a reference point for applications to consume.

Figure 1: An Overview of Master Data

To compensate for this problem, profile data used for analytical consumption is typically cleansed in the extract, transform and load (ETL) environment and supplied to data warehouses and marts. However, operational systems continue to wrestle with substandard data quality, often resulting in significant inefficiencies and associated higher costs. To these operational systems, MD's clean and referential characteristics offer an attractive proposition.

Problem Statement

Technically speaking, master data makes sense. Within a componentized architecture where every component serves a specific function, master data plays a referential role for all transactional and decision support systems. However, management of master data is far less simple, mainly because of the extensive human intervention involved in cleansing the data and subsequently keeping it clean. In short, master data management (MDM) is not a one-time process, but a continuous way of life of active governance.

For instance, deciding upon a hierarchy that can be fitted with existing master data while being flexible enough to accommodate future master data demands requires extensive debate, decisions and trade-off analysis. In this regard, technology requires leadership from the Business in improving analysis and in expediting decisions. I propose a set of recommendations to engage the business by describing benefits of master data and by defining a governance structure that allows their active participation in shaping one of the enterprise's most valuable data assets.


Talk to Business in a Language They Understand: Benefits

Master data's architectural excellence is easy for technologists to grasp. After all, good management is fundamentally about compartmentalization, which master data offers by serving a specific referential function. The challenge lies in convincing the business, and a statement of benefits can be instrumental in building confidence. By identifying key pain points, a strong case can be built for master data as a part of defining the overall strategy (see Figure 2).

Figure 2: Sample Master Data Benefits To Typical Business Needs And Challenges

As a point of note, the scope of this article centers around governance, not strategy; however, gaining business buy-in, which is part of strategy, needs further discussion. Master data aficionados will say that not enough emphasis is placed on convincing a skeptical business audience that indeed master data offers significant value. By purporting a strong case of benefits, the business will be galvanized into a partnership with technology, leading to the joint development of the master data strategy.

So how are benefits unearthed? First, processes that suffer from bad profile data should be identified (e.g., high maintenance costs of systems, missing or manual capabilities, workflow redundancies and other operational inefficiencies, etc.). Second, a cost benefit analysis should be performed that quantifies the problems and benefits of fixing the underlying profile data, leading to a prioritized scheme of processes to rectify first. Third, these benefits should be overlaid onto a roadmap. That is, include the benefits when documenting initiatives (e.g., on-boarding customer master data will yield qualitative benefits of ... resulting in quantitative benefits of $2 million saves annually).

The idea is that while talking to the business, a rationale is stated for why master data is important, what problems it plans to fix and what the value proposition is for fixing those problems. At the heart of the matter, the value of clean data to operations is being assessed. Once this value is quantified and explained, the business, having been engaged early on in the process, will be more active in assuming governance responsibilities for master data assets.

Implementing Governance

An organization that is willing to invest in master data must anchor progress to the strategy through the core mechanisms of governance: roles and process.


One of the core elements of governance is to set clear expectations of roles. The roles in turn can be assigned to groups or individuals, depending on organizational size and complexity. Master data roles specify who should get involved and under what circumstances. Along these lines, roles are stratified into two categories: decision-making mostly involves the business; decision-implementing includes the technology organization (see Figure 3).

Figure 3: Role Stratification into Decision-Making And Decision-Implementing

Business involvement in bearing responsibility for master data arises because in general, master data is a valuable enterprise asset and as such must be owned by those who have the greatest vested interest in its integrity. Two primary roles must be borne by the business: the business data owner (BDO) and the business data steward (BDS).

BDOs obtain, create and maintain authority over their subject-specific master data content. By extension of their authority, BDOs are also responsible for coordinating with compliance and regulatory groups when defining access rights. For example, compliance at credit card issuers may require that a person's name, address and Social Security data never be viewable in any single report or application. BDOs must remain abreast of these and other compliance requirements when defining access rights on their data.

BDSs do not hold dominion over the data per se; rather they operate at the business and technology intersection and see to it that effective policies and procedures are created and translated to implementation. Of the roles discussed, they have the widest range of collaborations, spanning architects to auditors to the business. They are recognized as being both capable of understanding business issues and of being technologically savvy. Of paramount importance, stewards have core responsibilities for data quality control and as such, help define quality goals and corresponding metrics that are evaluated on a continuous basis. Data stewards should be dedicated, full-time roles that focus on maintaining and improving master data quality over time.1

Technology data managers (TDMs) oversee the technical implementation of the policies and procedures set by stewards. TDMs are entrenched in the technology organization and coordinate with various IT experts (e.g., data modelers and architects, application developers, integration architects, DBAs, etc.) to follow through on master data modifications requested by the business. In smaller organizations, the TDM may be responsible for directly implementing all the changes. As indicated, stewards help in translating the requirements to TDMs and both groups work in close coordination, leveraging a feedback loop to create consumable policies that govern master data.


Governance is an iterative process: as updates and additions to master data trickle in over the life of the company, structured mechanisms must guarantee a controlled approach to capturing, directing and implementing changes. Integral to this mechanism is the monitoring of quality on an ongoing basis. Given master data's widely referenced utilization, changes to its structure have far-reaching consequences and must be strictly managed.

Figure 4 provides an example of running through changes requested to master data. These changes are not for the data itself, but the structures that enable capture and processing. For example, sales professionals who must update contact information need not be concerned with running though this process, but can simply update contact information from their wireless device. However, changing or adding data structures (changes to attributes, services or objects, etc.) that previously did not exist would require broader scrutiny.

Figure 4: Changes Requested To Master Data

The process begins in the master data governance forum: this regular meeting should exist for BDOs, BDSs and other business subject matter experts (SMEs) to bring forth and discuss modifications to master data. Ideally, technology data managers should be present as needed; however, the BDS can serve as the proxy. The goal of this forum is not to discuss how master data implementation should occur, but to understand the rationale for the change and impacts the changes will have on technology and master data consumers. It should serve as an important gating mechanism to assess the value and cost of the master data change being requested. As a part of this forum, the following actions should be undertaken:

  1. Ensure that all core affected business parties are present.
  2. Provide a list of structured master data changes and decisions that need to be made, including the business case for the recommendations.
  3. Engage in a structured debate on recommendations being made and finalize decisions.
  4. Capture follow-up actions that need to be taken (i.e., additional research on recommendations) with assignments and dates of completion.
  5. Define clear next steps for future forums to finalize pending decisions or hand off to BDS to carry forward to technology for implementation.

As previously mentioned, the governance forum exists for business-focused discussion on changes to master data. However, despite good due diligence, undoubtedly some changes that experience technical challenges may be volleyed back by technology through the BDS for another review. For example, master data changes that revise cost estimates to be significantly higher may require reexamination. The point is, while the governance forum facilitates discussion of business needs for master data changes, it cannot be completely divorced from implementation challenges or costs: a healthy balance between business need and cost of implementation should be at the core of the gating mechanism.
All approved master data changes are carried forward by the BDS. During these next steps, stewards leverage existing policies and procedures or create new ones. For example, if new master data is requested, stewards build and put into practice new data collection methods that are incorporated into training, coaching and the daily workflow of those in close proximity to the data (e.g., customer agents, sales agents, etc.). As a part of this process, new quality metrics are identified and prepared for implementation. Stewards, given their core responsibility for quality, have to oversee that what is implemented concurs with the needs of the Business. When all is said and done, the stewards are held to quality standards for master data.

The final leg is the close coordination of stewards with the TDMs. During this step, the required changes are explained in detail to TDM and associated technologists for implementation. The coordination process between TDM and technologists is not one-way. It entails both, providing guidance on implementation, but also on managing and reporting back to BDS on progress. This includes master data change issues that may not be in the best interests of the business. It is the responsibility of the TDM to provide this information back to the stewards, who can then make assessments about business impact. Issues most noteworthy of business owner attention are reported back to the master data governance forum for further discussion, closing the loop on the master data business to technology governance process.

MDM represents a key opportunity to curate arguably the most valuable data assets for use by transactional and analytic systems alike. MDM cannot be a technology-driven solution, but must be a joint effort between the business and IT. In this regard, MDM cannot be instituted based on its technical excellence alone; it must be bought in by the enterprise for the business problems it aims to solve.

The vision of clean, highly referenced master data is not just a matter of arriving at an idealized state, but maintaining it through active governance for the life of the institution. Maintenance can only occur through a structured set of organizational roles and processes that enable active and efficient coordination between the roles. Tying together individuals, groups and processes, the right master data governance promises an opportunity for solving operational inefficiencies that plague companies of all sizes.


  1. Alex Berson and Larry Dubov. Master Data Management and Customer Data Integration for the Global Enterprise. Chicago: McGraw-Hill, 2007.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access