CHAPTER 19
Where Do We Go from Here?

We have finally arrived at the point in the book that allows us to talk about the future of Master Data Management. Throughout the book, we have used various ways to describe MDM and to articulate the business drivers and technical challenges of implementing MDM initiatives. We showed the complexities surrounding MDM architecture, paid close attention to often-overlooked issues of data security and visibility, and shared the authors’ personal experiences in addressing implementation concerns on a number of MDM projects across several industries.

Review of the Key Points Covered in the Preceding Chapters

We have stated in the beginning of the book that MDM is a broad, complex, and multidiscipline set of technologies organized into a policy-driven comprehensive framework that can be viewed from several business and technical perspectives. We introduced the notion of MDM classification dimensions that allows us to better understand how to consider, design, deploy and obtain benefits from an MDM system. As MDM continues to mature and attract attention of enterprise decision makers across a wide spectrum of industries, the amount of available information about MDM continues to grow as well, and in order to make sense of various, sometimes contradictory assertions about MDM, we need to apply a proven approach to the reduction of complexity—an approach of decomposition and classification or categorization. This approach allows us to organize available information and discuss various aspects of MDM according to a well-defined structure. The MDM classification dimensions that we introduced in Chapter 1 enable us to better understand the relevance and importance of various factors affecting the product selection; architecture, design, and deployment choices; impact on the existing and new business processes; and overall MDM strategy and readiness for the enterprise. The latter is based on a number of variations of the capability maturity model including the Capability Maturity Models for MDM introduced in Chapter 12 and the Capability Maturity Model for data governance that we discussed in detail in Chapter 17. The sections that follow provide a brief summary of lessons that we learned up to this point.

A Brief Summary of Lessons Learned

Let’s quickly review all major points that are relevant to any MDM initiative regardless of the data domain, industry, geography, and other deployment requirements.

Lesson Learned: MDM Classification Dimensions

Several commonly accepted MDM classification schemes or dimensions that we introduced in Chapter 1 include the Design and Deployment dimension, the Use Pattern dimension, and the Information Scope or Data Domain dimension. We showed these dimensions as persistent characteristics of any MDM solution regardless of the industry or master data domain. Let’s recap the key classification dimensions here:

• Design and Deployment This classification describes MDM architecture styles that support a full spectrum of MDM implementations—from a thin MDM reference-only layer to a full Master Data platform (or MDM Data Hubs). The entire range of the MDM Data Hub variations (from thin to thick) can support all business processes including transaction processing. These styles—Registry, Coexistence, and Transaction Hub—were discussed in greater detail in Part II of the book.

• Use Pattern This classification differentiates MDM solutions based on how the master data is used. We see three primary use patterns for MDM data usage—Analytical MDM, Operational MDM, and Collaborative MDM.

• Analytical MDM supports business processes and applications that use master data primarily to analyze business performance and provide appropriate reporting and insight into the data itself, perhaps directly interfacing with Business Intelligence suites; Analytical MDM tends to be read-mostly, in that it does not change/correct source data in the operational systems, but does cleanse and enrich data in the MDM Data Hub; from the data warehousing perspective, Analytical MDM builds complex data warehousing dimensions.

• Operational MDM allows master data to be collected, changed, and used to process business transactions; Operational MDM is designed to maintain semantic consistency of master data affected by the transactional activity. Operational MDM provides a mechanism to improve the quality of data in the operational systems, where the data is usually created.

• Collaborative MDM allows its users to author master data objects and collaborate in the process of creation and maintenance of master data and associated metadata.

• Information Scope or Data Domain This dimension describes the primary data domain managed by the MDM solution; in the case of Customer MDM, the resulting solution is often called Customer Data Integration or CDI; in the case of product MDM, the solution is known as Product Information Management or PIM; other data domains may not have formal definitions yet, but could have an impact on how the MDM solution is designed and deployed.

Lesson Learned: Key Requirements of a Successful MDM Initiative

In addition to the introduction of the MDM classification dimensions, we extensively discussed two major requirements of any MDM initiative, and showed that in many cases failing to address either of these requirements would most likely result in a failure of the MDM project. These two major requirements of a successful MDM project are

• The creation and acceptance of a compelling, justifiable, and comprehensive

• The establishment and continuous involvement of an enterprise-wide Data Governance framework and a dedicated Data Governance team that is empowered and accountable for the implementation and enforcement of data governance policies and procedures

These two major MDM requirements are continuously confirmed not just by the authors’ extensive experience in developing MDM solutions, but also by a number of industry analysts that conduct large-scale surveys and publish interesting and compelling statistics. For example, according to Forrester’s August 2009 Global Master Data Management/Data Quality Online Survey,¹ 68 percent of surveyed organizations that embarked on the MDM journey require either a formal, detailed business case with a clearly articulated ROI, or a more high-level business case that defines the MDM blueprint in the context of the overall enterprise business and technical architecture but does not have to include a detailed analysis. And likewise, according to the same Forrester Research report, 95 percent of organizations rate data governance as important, very important, or critical to the successful implementation and rollout of MDM solutions.

Lesson Learned: MDM Is a Global, Industry-Agnostic Enabler of Enterprise Transformation

There are many MDM implementation challenges, and they span organizational, business, and technical aspects of the MDM. Let’s briefly summarize some of these key points of MDM that often drive the implementation challenges. We discussed these points in detail throughout the book.

• The ability to recognize individual entities as members of arbitrary complex groups (for example, households and extended families for individuals, holding companies and other organizational hierarchies for business entities such as corporations, product bundles for product components, and so on) is one of the key properties of Master Data Management, and it applies equally well to MDM for Customer Data domain, Reference Data Management, Product Master Hubs, and so on, with the complexity of the associations and grouping depending in large part on the completeness and accuracy of the data and the business rules driving the resolution of conflicting or undetermined links.

• Master Data Management is a horizontal technology that applies equally well to all industries and markets and is global in nature. This point has two equally important aspects:

• MDM in general, with its variants such as the customer-centric version known as Customer Data Integration or CDI and the product master version sometimes called Product Information Master or PIM, is especially effective in modernizing a global enterprise.

• The need for an authoritative, accurate, timely, and secure “single version of the truth” is pervasive and is not particular to a specific industry, data domain, country, or geography.

• At the time of this writing, Master Data Management for Customer domain continues to be the predominant MDM variant. While evolutionary from the pure technological point of view, it is revolutionary in its potential business impact of transforming the enterprise into a customer-centric model. In that, MDM Customer (CDI) represents a particularly interesting opportunity to any customer-or citizen-facing organizations including commercial businesses and government agencies alike.

• Master Data Management can enable an enterprise to achieve a sustainable competitive advantage by improving the levels of customer service and overall customer experience, reducing the attrition rates, growing customer-based revenue as a share of their wallet by understanding and leveraging the totality of customer relationships with the enterprise, and helping the enterprise to be in a better position to achieve regulatory compliance, to name just a few.

• MDM benefits extend well beyond the Customer domain. For example, MDM can significantly improve enterprise efficiencies where a holistic view of the products can help streamline various business processes, enable effective innovation, and improve new products, competitiveness and time-to-market metrics.

• MDM can be extremely beneficial to various government agencies and businesses not only from a customer service point of view but also in helping law enforcement agencies in threat detection and prevention.

Key Lessons Learned about MDM Technical Approaches

In addition to the organizational, process-related, and business challenges, MDM presents a number of challenges that are driven by the complexity of its technology framework and the variety of approaches designed to address them. Throughout the book, we discussed key MDM technical approaches and challenges. Among them are the following:

• Building an MDM solution as an instance of a service-oriented architecture (SOA)

• Building MDM solutions to utilize Web Services as the insulation vehicle between new master data, legacy data stores, business processes, and applications

• Addressing data governance and data quality issues with a high focus on data quality metrics to achieve advanced levels of data governance

• Defining and applying accurate matching algorithms for batch and real-time processing

• Building an MDM solution as a policy-driven framework, with the policies providing context and directions for defining and applying survivorship rules for the “single version of the truth” records, solving complex data synchronization and reconciliation issues, and in general governing MDM system behavior

• Considering the complexity of new, MDM-enabled business transactions that span systems and applications not only within the enterprise but also across system domains of its business partners

• Addressing the scalability challenges of data volumes, transactional throughput, and structured and unstructured data types

• Enabling robust process controls to support audit and compliance reporting

• Designing effective approaches to protecting access to the integrated data as well as to the services and applications that can access that data—fine-grained access controls and policy—and entitlements-driven data visibility and security

Main Reasons MDM Projects Fail

It should come as no surprise that addressing the points in the preceding sections does not guarantee that an MDM project will be a success.

Master Data Management projects represent significant enterprise-wide undertakings that rely on and impact four pillars of successful MDM initiatives: business processes, people, organizational structure, and technology. These four pillars of MDM are needed to maintain the balance—break one pillar, and the entire MDM “house” may fall! In almost all cases, these four pillars depend heavily on the MDM maturity level of the organization. We discussed a few flavors of the MDM maturity model throughout the book and in Chapter 12, while Chapter 17 discusses CMM for Data Governance. These CMM models are very useful and in combination can profile the current state of MDM and Data Governance maturity and define the target state.

However, even higher levels of maturity may not prevent an MDM initiative from failure. We can see several predominant reasons why MDM initiatives fail, and many of these reasons apply to any MDM or Data Governance CMM level organization. We discuss these reasons in the following sections.

Review of the Key Reasons for MDM Project Failure

The following represents just some of the key reasons why MDM projects may fail

Lack of Justifiable, Business-Driven Business Case, Lack of Executive Support and Budgetary Commitment

As we mentioned several times, MDM initiatives can succeed only if there is executive-level support. This is the key since many MDM projects tend to become very large very quickly and last longer than a few months. Even though signing checks is critical, senior management commitment must go beyond that. Senior management must understand the key benefits, dependencies, release scope and timing, high-level risks, and trade-offs the project is facing. A formal business case is the primary vehicle to ensure this understanding and enterprise buy-in.

Lack of Coordination and Cooperation Between Business and Technology Organizations

The complexity, size, and the implementation risk of MDM initiatives require close coordination and cooperation between business and technology organizations involved in the MDM initiative not only in order to achieve the goals of the project but also to reach an agreement that these goals have been met. All too often a business unit defines high-level business requirements for an MDM solution and passes them on to the technology team to implement. The technology team analyzes the requirements and their technical feasibility, and defines the plan, the approach, the architecture, the infrastructure, and the tools required to deliver what has been requested by the business. However, sometimes the requirements are expressed in such high-level terms that their technical implications are not apparent to the business and technology organizations. Without a continuous joint effort to address the potential ambiguity of the requirements, the technology team may create a project plan that, from the business-unit point of view, is too long, too expensive, and does not deliver what the business sees as a timely value proposition. Without proper cooperation and coordination, this disconnect may be “discovered” several months into the project with the money already spent and no recognizable return on investment. A potential outcome might be the withdrawal of business support and funding that would lead to the cancellation of the project for failure to deliver. The business case must include a comprehensive MDM roadmap that is bound to define the target state vision as well as intermediate releases of MDM.

Lack of Consuming Applications

The old adage “if we build it they will come” does not always work in the case of Master Data Management. MDM projects are often positioned as infrastructure projects, and here lies the danger. Typically, an infrastructure initiative becomes “visible” only when the organization experiences an infrastructure-related problem, for example, the enterprise network is not available and a major application or customer channel is down, and so on. Successful infrastructure projects keep enterprises “alive” but are rarely appreciated unless a problem occurs. MDM projects hold a promise of significant business benefits and thus should not be invisible. To put it another way, it is very difficult to demonstrate the value and the benefits of an MDM solution if there are no applications and no end users that can take advantage of these new capabilities. Inability to demonstrate value may result in a negative perception of a project as a failure, with the project stakeholders withdrawing their support and looking for alternative solutions. For example, bundling MDM with customer on-boarding and account opening process can clearly demonstrate significant value and at the same time improve the quality of MDM-enabled applications and processes. In this case, the added value becomes clear since the business community obtains a new, more efficient and highly-visible account opening application that leverages higher quality customer data, reduced data entry errors, and streamlined processes.

Lack of User Adoption

This reason is closely related to the preceding one. One of the impacts of an MDM project is the ability to view, use, and manage critical enterprise data differently, possibly using different applications and business processes. That requires not only the availability of new consuming applications that can take advantage of the MDM solution, but also an educated and trained end-user community. End-user education should start as soon as the project is approved. Training is another critical area of user adoption. Training performed too early is not effective since the end users may forget what they learned by the time the system is in production. In addition, training should be flexible enough to accommodate users with different levels of computer literacy, from novices to “power” users.

Underestimating or Not Considering Impact of Legacy

Many MDM implementations have to be developed and deployed into already-established enterprise system environments, and therefore have to deal with existing data sources and applications. While the need for an accurate, timely, and authoritative system of record is understood and shared by both the business and technical teams, it is often the case that an application area in charge of an existing data store such as a data warehouse, CRM system, or a reference database would consider extending existing data stores and consuming applications as well as attempting to improve data quality in a tactical fashion by focusing on the local data stores. In addition, the legacy system owners may put forward an argument that since their legacy solution is already in place, there is no need for additional system integration work. In short, a legacy extension and modernization approach may present a tactical alternative to an MDM solution that can be perceived by the management as a lower risk approach. The MDM project team needs to assess the impact of the incremental system integration effort required to deploy a new MDM platform into the existing system environment, understand the potential shortcomings of legacy-based tactical solutions, and develop an MDM business case that would create compelling strategic arguments for a MDM solution.

Failing to Socialize MDM Throughout the Enterprise

MDM projects can affect practically every department in an enterprise. Therefore, MDM project owners must be also MDM evangelists and social champions who continuously work toward obtaining and maintaining enterprise-wide support, making sure that the project plan is built using realistic timelines and appropriate resources and budget. Effectively socializing the project’s goals and benefits would ensure the proper level of stakeholder involvement, from awareness to understanding and ownership.

Lack of the Data Governance Strategy That Includes Well-Defined Data Stewardship and Formally Managed Metrics-Driven Data Quality Program

This reason is practically self-explanatory; without proper measurable data quality metrics the MDM solution would be an integration point of inaccurate or incomplete data, which makes its usefulness questionable. We put a lot of focus on this aspect of Data Governance in Chapter 17.

Lack of a Comprehensive, Service-Oriented MDM Architecture

As MDM projects grow up from their initial pilot implementations, they need to be architected to be easily integrated with the enterprise architecture. This requirement is easy to understand if you consider that the goal of any MDM project is to create an authoritative, accurate, and, most importantly, enterprise-wide system of record. So, leveraging enterprise legacy infrastructure and applications and designing for interoperability, performance, scalability, and security are only a few aspects that have to be addressed. Using a comprehensive architecture framework to build service-oriented MDM solution helps decouple end-user business applications from the structure and the physical location of the existing and new data stores and thus helps reduce data and functional redundancy, and provides the flexibility, scalability, and adaptability of the MDM solution.

Choosing the MDM Data Model Poorly

A choice between a vendor-provided data model and a custom data model developed in-house could spell the difference between success and failure of the project. This choice has to be made carefully and in the context of the enterprise business strategy and capability requirements.

Project Staffing

The complexity and multidisciplinary nature of Master Data Management initiatives requires the availability of a properly trained, knowledgeable cross-functional project team that has the appropriate number and the correct mix of subject matter experts, managers, planners, system architects, application developers, data analysts, database administrators, infrastructure designers, security experts, testers, and representatives of the business teams. Such a complex undertaking can be successful only if the project team has a respected, strong project leader who can also act as a visionary and evangelist who continues to reinforce the business value messages and to maintain effective collaboration and socialization among the team members.

MDM Guiding Principles

The reasons for MDM project failure that we discussed above should help MDM practitioners to avoid some obvious pitfalls on the road to MDM implementation. To further help readers to navigate turbulent MDM project waters successfully, we put together a concise set of MDM guiding principles that apply to practically any MDM initiative across any industry segment regardless of the specific MDM data domain or the architecture style. Some of these principles are conceptual while others are more focused on the specific technical issues and directions that help make an MDM initiative both useful and successful. These guiding principles are listed below:

• The MDM initiative has to start with well-defined, business-driven, and clearly justifiable business case.

• The MDM scope, design, architecture style, degree of federation and/or centralization, and the deployment roadmap shall be driven by sufficiently articulated business requirements and properly documented business processes.

• The MDM project approach, structure, and implementation roadmap shall include and be based on well-defined Data Governance rules and policies administered and enforced by an Enterprise Data Governance group.

• MDM and business processes are intrinsically linked: The MDM project team should design and deploy an MDM system in a way that can benefit, improve or optimize business processes.

• Whenever possible, make sure that the MDM system can support multiple data domains.

• Data that is mastered by an MDM system shall be captured once and validated at the source to the extent possible within the context.

• Any data modifications/corrections to the master data can be made only by the Master Data System according to the rules and policies established by the business, including the rules of resolving data change conflicts.

• Changes to the master data have to become available to all downstream systems at the time and in the form defined by the enterprise policies and business-specific SLAs.

• Every data item shall have an identified business owner and a steward (custodian).

• The quality of the master data shall be measured in accordance with information quality standards established by the organization. Whenever possible, the Data Governance/Data Quality Management team should apply Data Science and Information Theory principles to define measurable information quality standards.

• The MDM system architecture shall be designed from the ground up to ensure data security, integrity, visibility, and appropriate enterprise access controls.

• MDM shall be designed to support the appropriate versioning and retention of data at the appropriate level of granularity.

• The MDM system shall provide for and leverage standardization of sources, definitions, structures, and usage of shared and common information.

• MDM shall leverage consistent and validated metadata definitions for all data under management.

• At a minimum, the MDM architecture shall support key foundational MDM capabilities including but not limited to entity resolution; management of entity identifiers for all master entities; management of entity taxonomies, hierarchies, groups, and relationship; and entity data change capture, maintenance, notification, distribution, and reconciliation.

Master Data Management: Trends and Directions

Master Data Management solutions are still relatively new, and the road ahead has unexpected turns, peaks, and valleys. At the time of this writing, the market for MDM solutions continues to grow fast, and there are numerous research reports and surveys indicating current and future market sizes in terms of total expenditure and vendor revenue. According to the report published by Forrester Research, interest in MDM and a number of MDM initiatives continues to grow, and MDM is growing rapidly and becoming a clear priority for many organizations.² For example, “2008 Forrester’s Enterprise and SMB Software Survey for North America and Europe”³ found that 49 percent of organizations were planning to implement or expand their use of MDM software in 2009, a 9 percent increase from the previous year. We believe that the 2009–2010 economic recovery will help drive this trend to even higher numbers across industries and geographic locations.

However, the financial side does not necessarily indicate the direction that MDM would take going into the future.

It is hard to predict the future, and this is certainly true in the case of Master Data Management. Nevertheless, there are a number of research reports from various industry analysts that attempt to define market trends with various degrees of accuracy. In order to present a cohesive picture of MDM trends, we synthesized many of these predictions and analyses; supplemented them with our personal insights and observations based on practical, hands-on involvement in the MDM projects across different industry segments; and put together a compact and hopefully provocative list that takes into account not just MDM-specific trends but also major disruptive technology trends we are observing and experiencing in the second decade of the twenty-first century. We separate the discussion about the MDM trends into two categories: MDM market trends and MDM technical capabilities trends.

MDM Market Trends

These are the trends that we see developing in the MDM marketplace:

• Even though MDM is a multidomain discipline, two major domains—Party/Customer and Product—will continue to dominate enterprises’ MDM agendas. Specifically, in the case of Party/Customer domain (this domain includes customer, prospect, patient, citizen, supplier, and employee data), many MDM initiatives will be positioned to lead enterprises toward customer-centric transformations. In that, MDM project scopes will become more broadly defined and include not just the implementation of an MDM Data Hub but also activities focused on business process management and applications reengineering with the end goal of developing new, more agile, comprehensive, customer-centric, and user-friendly processes and applications.

• Many MDM initiatives will be defined and implemented specifically to address the growing issue of managing a diverse set of externally sourced and internally maintained reference data, with a particular focus on managing reference data hierarchies and building enterprise-wide reference data distribution service solutions that operate according to the terms of generally accepted data governance policies, rules, and service contracts.

• External reference data providers and their “trusted” data sources and services will play a more prominent role in MDM implementations. Companies such as Dun & Bradstreet, Acxiom, Lexus-Nexus, Transunion, and Experian are a few examples of these data providers. Although these companies may not offer complete MDM solutions, they will certainly be positioned to become key players in the data cleansing, rationalization, enrichment, and linking and matching space.

• Master Data Management solutions will proliferate throughout various industry segments but will be subjected to two opposing forces: one is to develop industry-specific or business-specific implementations that emphasize each enterprise’s strongest and differentiating competencies, while the other is the desire to implement MDM using newer, more flexible, multidomain-capable technology solutions to avoid creating numerous, possibly incompatible MDM platforms that would be difficult to integrate and may eventually result in higher development, maintenance, and, where appropriate, license costs.

• While the majority of MDM implementations will follow a service-oriented model, we see that both near-real-time (for example, near-real-time complete customer view) and batch designs (for example, a master file of pharmaceutical company customers—physicians and other healthcare providers) are going to co-exist in an enterprise, mostly dependent on the particular use case, data and application domain, and MDM architecture choices.

• Vendor solutions will evolve to concurrently support multiple domains, for example, delivering solutions such as Product Data Hub, Reference Data Hub, Location Data Hub, Account Data Hub, Privacy Data Hub, and others, using the same MDM engine. This is going to be especially true for the MDM solutions that focus on managing multidomain hierarchies and entity groups.

• The MDM vendor marketplace will continue to consolidate aggressively, with large system vendors acquiring smaller MDM specialty vendors. Given the typical size and complexity of MDM initiatives, the willingness of companies to partner with a larger vendor is part and parcel of the implementation risk mitigation strategy. The latest examples of such consolidation are the acquisition of Siperian by Informatica and the acquisition of Initiate Systems by IBM.

• Master Data Governance capabilities will grow and partly become embedded in the MDM Data Hub systems, including support for Data Governance metrics at different levels; organizations using these metrics will be able to establish a Master Data Governance group as an organizational unit with defined performance targets.

MDM Technical Capabilities Trends

We have seen the following technical capabilities in MDM emerging in the recent years:

• MDM solutions and vendor products will continue to extend master data capabilities along several dimensions:

• “Organically,” by evolving core functionality within the MDM engine

• Through integration with new complementary technologies such as advanced data quality and matching solutions

• Leveraging new computing paradigms such as virtualization, cloud computing (cloud computing is Internet-based computing model where shared computing resources such as CPU cycles, memory, software, and information are available to consumers such as application systems, devices and appliances on-demand, transparently and securely, based on the previously established service contracts), and cloud-related technologies such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), Data-as-a-Service (DaaS) and so on. These computing paradigms dramatically and often positively change the cost, scalability, manageability, and deployment factors of the MDM project equation.

• MDM becomes available as an Open Source solution. Open Source MDM is a new direction, and while the viability of this approach in the MDM space needs to be evaluated on the case-by-case basis, the promise of Open Source includes such benefits as improved development cycle, shorter time to market, and reduced cost. Moreover, Open Source MDM, by definition, can leverage the open source community as a collective requirements generator, idea generator, and diversified tester. The resulting Open Source MDM solutions may deliver robust, collaboratively developed data models and effective, shared, and broadly tested technology components and algorithms such as sophisticated entity resolution algorithms that are often proprietary and are controlled by a single vendor owner.

• The majority of today’s MDM solutions deal with structured data that can be represented in fixed tabular formats supported by relational database technology. An emerging trend in MDM technology is the support for unstructured and semi-structured data. This category of data represents at least 80 percent of all data under management, and having a single version of the truth of a large collection of semi-structured objects, images, XML documents, and other data types represents an interesting and exciting opportunity for MDM, for example, to enable rich content analysis; robust semantics processing; proximity and semantic searching; and management of such master objects as business, compliance, and security policies.

• A direct consequence of MDM support for the unstructured and semi-structured data is positioning MDM as a potential platform to centrally manage privacy policies and thus to help enforce trusted relationships between the enterprise and its customers.

• We stated repeatedly that master data managed by an MDM system must be protected not only from unauthorized, fraudulent use, but also from any attempt to access it that is against corporate business and security policy. These concerns are the subject of data security and visibility components of the MDM architecture. As the MDM market continues to mature, enterprises and vendors alike are developing standards-based policy enforcement mechanisms that can protect data and preserve existing business processes, while at the same time positioning the enterprise to be ready for verifiable, auditable compliance with government and industry regulations and laws concerning data security, visibility, confidentiality, and privacy protection.

• An obvious and easy prediction: MDM matching and linking technology will continue to evolve, will become much more sophisticated and powerful, and will support data matching for both structured and unstructured content, as well as support deep ontology-based semantic matching for complex objects in product domain.

• Business demands and vendor consolidation are already resulting in the availability of integrated MDM solutions that include sophisticated data quality components, flexible rules engines, metadata repositories, reporting and business intelligence tools, and even audit and compliance-monitoring capabilities in componentized service-based product suites. We believe that this trend will continue at least for the next several years.

Of course, this is far from a complete list of MDM trends. There are others, some more tactical and others that may be viewed as too radical or strange. Let’s consider the following examples:

• Current thinking in the MDM world is to build MDM systems as Data Hubs. But we know from networking technologies that there are better, more efficient topologies than hubs and spokes. Would it be possible to build the next generation of MDM solution as a secure “switch” or “data grid” fabric that scales effectively and intelligently as an infinitely flexible cloud?

• Current Analytical MDM solutions are designed to support downstream data warehouses and BI systems that become primary consumers of master data. However, if an MDM system can effectively manage the structures and contents of dimensional hierarchies, this can allow future data warehousing environments to contain only facts or measures, and manage the dimensions directly in the MDM Data Hub. This architecture appears to be more flexible, more federation-friendly, and thus offers higher affinity to various cloud computing and virtualization models.

• Because MDM relies on the availability and effective execution of various rules and policies, it may be possible to extend the current view of MDM to support the new MDM information domain type—the domain of policies and rules—thus creating MDM Policy Hub systems that can “govern” other MDM Data Hubs.

We may not be able to answer questions like this today, but we’re confident that collectively we will be able to see the answers emerging from the mist of the not-so-distant future. And then we can even find an answer to the big question: What is the next “disruptive” thing after MDM?

References

1. “Global Master Data Management/Data Quality Online Survey.” Forrester Research, August 2009.

2. Karel, Rob. “Trends 2009: Master Data Management.” Forrester Research (2009).

3. “Enterprise and SMB Software Survey, North America and Europe,” Q4 2008.