As we have seen, master data integration and master data management are not truly the end objectives; rather they are the means by which other objectives are successfully accomplished, such as those promised by customer relationship management systems, product information management systems, Enterprise Resource Planning (ERP) systems, and so on. And while the principles that drive and support MDM reflect sound data management practices, it would be unusual (although not unheard of) that senior management would embrace and fund the MDM effort solely for the sake of establishing good practices.

That being said, the business justification for MDM should be coupled with those programs that will benefit from the availability of the unified view of master data. That means that MDM can be justified in support of a business initiative that relies on any of the following MDM benefits:

In this context, enterprise applications such as Customer Relationship Management (CRM) and ERP maintain components that apply to instances of the same object type across processing streams (e.g., “Order to Cash”), and maintaining a unified version of each master data object directly supports the enterprise initiative. Therefore, it is reasonable to justify incorporating an MDM initiative as part of these comprehensive projects.

The key deliverables of this stage are the materials for documenting the business case for the stakeholders in the organization, including (not exclusively) the following:

The implementation of a complex program, such as MDM, requires strategic planning along with details for its staged deployment. Specifying a road map for the design and development of the infrastructure and processes supporting MDM guides management and staff expectations.

Managing the participants and stakeholders associated with an MDM program means clearly articulating each specific role, each participant's needs, the tasks associated with each role, and the accountability associated with the success of the program. A sampling of roles is shown in Figure 13.2.

To ensure that each participant's needs are addressed and that their associated tasks are appropriately performed, there must be some delineation of specific roles, responsibilities, and accountabilities assigned to each person; in Chapter 2 we reviewed using a RACI model, with the acronym RACI referring to the identification of who is responsible, accountable, consulted, and informed of each activity.

Within the model, the participation types are allocated by role to each task based on whether the role is responsible for deliverables related to completing the task, accountable for the task's deliverables, consulted for advice on completing the task, or is informed of progress or issues associated with the task.

The key deliverables of this stage include the following:

As the road map is refined and the specific roles and responsibilities identified, a detailed project plan can be produced with specific tasks, milestones, and deliverables. For each of the phases specified in the road map, a more detailed list of milestones and deliverables will be listed, as reflected by the responsibilities in the RACI matrix. The list of tasks to accomplish each milestone or deliverable will be detailed, along with resource/staff allocation, estimated timeframes, dependencies, and so on. The project plan will incorporate the activities in the following sections of this chapter. The key deliverable for this stage is a detailed project plan with specific milestones and deliverables.

Business operations are guided by defined performance management goals and the approaches to be taken to reach those goals, and applications are developed to support those operations. Applications are driven by business policies, which should be aligned with the organization's strategic direction, and therefore the applications essentially implement business processes that execute those policies.

Although many application architectures emerge organically, they are always intended to implement those business policies through the interaction with persistent data. By documenting the business processes at a relatively granular level, analysts can understand which data entities are touched, determine if those entities reflect master object types, and map those data entities to their corresponding master type. Ultimately, looking at the ways that these applications access apparent master data objects embedded within each data repository helps drive determination of the initial targets for integration into the master environment.

Finally, and most important, one must consider both the existing applications that will be migrated to the new environment and how their operations must evolve, as well as any new business processes for which new applications will be developed targeting the master data environment. Evaluating the usage scenarios shows the way that the participants within each business process will access master data, which will contribute later to the decisions regarding master data models, master data services, and the underlying architectures.

The key deliverables for this activity are as follows:

During this activity, the business process models are reviewed to identify applications and their corresponding data sets that are suitable as initial targets for mastering. The business process models reflect the data interchanges across multiple processing streams. Observing the use of similar abstract types of shared data instances across different processing streams indicates potential master data objects.

Because the business justification will associate master data requirements with achieving business objectives, those requirements should identify the conceptual master data objects that are under consideration, such as customers, products, or employees. In turn, analysts can gauge the suitability of any data set for integration as a function of the business value to be derived (e.g., in reducing cross-system reconciliation or as a by-product of improving customer profiling) and the complexity in “unwinding” the existing data access points into the master view. Therefore, this stage incorporates the development of guidelines for determining the suitability of data sets for master integration and applying those criteria to select the initial data sets to be mastered.

The key deliverable for this phase is a list of the applications that will participate in the MDM program (at least the initial set) and the master data object types that are candidates for mastering. The actual collection of metadata and determination of extraction and transformation processes are fleshed out in later stages.

As discussed in Chapter 4, data governance essentially focuses on ways that information management is integrated with controls for management oversight along with the verification of organizational observance of information policies. In this context, the aspects of data governance relate to specifying the information policies that reflect business needs and expectations and the processes for monitoring conformance to those information policies. This means introducing both the management processes for data governance and the operational tools to make governance actionable.

The key deliverables of this stage include the following:

In Chapter 6, we looked at how the conceptual view of master metadata starts with basic building blocks and grows to maintain comprehensive views of the information that is used to support the achievement of business objectives. Metadata management provides an anchor for all MDM activities, and the metadata repository is used to “control” the development and maintenance of the master data environment by capturing information as necessary to drive the following:

Specifying the business requirements for capturing metadata relevant to MDM is the prelude to the evaluation and acquisition of tools that support the ways for resolving business definitions; classify reference data assets; document data elements structures, table layouts, general information architecture; as well as develop higher-order concepts such as data quality business rules, service level agreements, services metadata, and business data such as the business policies driving application design and implementation.

The following are the milestones and deliverables for this stage:

In Chapter 7, we looked at how the challenges of master data consolidation are not limited to determining what master objects are used but rather incorporate the need to find where master objects are used in preparation for standardizing the consolidated view of the data. This ultimately requires a strategy for standardizing, harmonizing, and consolidating the different representations in their source formats into a master repository or registry. It is important to provide the means for both the consolidation and the integration of master data as well as to facilitate the most effective and appropriate sharing of that master data. This stage takes place simultaneously with the development of the master data models for exchange and persistence. Actual data analytics must be applied to address some fundamental issues, such as the following, regarding the enterprise assets themselves:

The expected results of this stage will be used to configure the data extraction and consolidation processes for migrating data from existing resources into the master environment; they include the following:

In Chapter 8, we looked at the issues associated with developing models for master data—from extraction, consolidation, persistence, and delivery. This is the stage for developing and refining the models used for extraction, consolidation, persistence, and sharing. It is important to realize that becoming a skilled practitioner of data modeling requires a significant amount of training and experience, so it is critical to engage individuals with the proper skill sets to successfully complete this task.

Every master data modeling exercise must encompass the set of identifying attributes—the data attribute values that are combined to provide a candidate key that is used to distinguish each record from every other. This will rely on the cross-system data analysis and data profiling performed during the master data object analysis stage, and the outputs of that process iteratively inspire the outputs of the modeling processes. It also relies on the documented metadata that have been accumulated from analysis, interviews, and existing documentation.

The following are the expected deliverables from this stage:

One of the key value statements related to application use of master data is an increased level of trust in the representative unified view. This implies a level of trustworthiness of the data as it is extracted from the numerous sources and consolidated into the master data asset. At the operational level, business expectations for data quality will have been associated with clearly defined business rules related to ensuring the accuracy of data values and monitoring the completeness and consistency of master data elements. This relies on what has been accumulated within the master metadata repository, including assertions regarding the core definitions, perceptions, formats, and representations of the data elements that compose the model for each master data object.

The data governance guidance developed during earlier phases of the program will be operationalized using metadata management and data quality techniques. Essentially, monitoring and ensuring data quality within the MDM environment is associated with identifying critical data elements, determining which data elements constitute master data, locating and isolating master data objects that exist within the enterprise, and reviewing and resolving the variances between the different representations in order to consolidate instances into a single view. Even after the initial migration of data into a master repository, there will still be a need to instantiate data inspection, monitoring, and controls to identify any potential data quality issues and prevent any material business impacts from occurring.

Tools supporting parsing, standardization, identity resolution, and enterprise integration contribute to aspects of master data consolidation. During this stage, business requirements for tools necessary for assessing, monitoring, and maintaining the correctness of data within the master environment will be used as part of the technology-acquisition process.

The key deliverables for this stage are as follows:

At this point in the program, there should be enough information gathered as a result of the master object analysis and the creation of the data models for exchange and for persistence in order to formulate the processes for data consolidation. The collected information, carefully documented as master metadata, can now be used to create the middleware for extracting data from original sources and marshaling data within a linearized format suitable for data consolidation.

Providing data integration services captures the ability to extract the critical information from different sources and to ensure that a consolidated view is engineered into the target architecture. This stage is the time for developing the data extraction services that will access data in a variety of source applications as well as being able to select and extract data instance sets into a format that is suitable for exchange. Data integration products are designed to seamlessly incorporate the functions shown in the sidebar.

Developing these capabilities is part of the data consolidation and integration phase. For MDM programs put in place either as a single source of truth for new applications or as a master index for preventing data instance duplication, the extraction, transformation and consolidation can be applied at both an acute level (i.e., at the point that each data source is introduced into the environment) and on an operational level (i.e., on a continuous basis, applied to a feed from the data source).

This stage's key deliverables and milestones include the following:

There are different architectural styles along an implementation spectrum, and these styles are aligned in a way that depends on three dimensions:

One end of the spectrum employs a registry, limited to maintaining identifying attributes, which is suited to loosely coupled application environments and where the drivers for MDM are based more on the harmonization of unique representation of master objects on demand. The other end of the spectrum is the transaction hub, best suited to environments requiring tight coupling of application interaction and a high degree of data currency and synchronization. Hybrid approaches can lie anywhere between these two ends, and the architecture can be adjusted in relation to the business requirements as necessary.

Other dimensions also contribute to the decision: service layer complexity, access roles and integration needs, security, and performance. Considering the implementation spectrum (as opposed to static designs) within the context of the dependent factors simplifies selection of an underlying architecture. Employing a template like the one shown in Chapter 9 can help score the requirements associated with defined selection criteria. The scores can be weighted based on identified key aspects, and the resulting assessment can be gauged to determine a reasonable point along the implementation spectrum that will support the MDM requirements.

The following are some of the key deliverables and milestones of this phase:

Master data service implementations may vary, but as discussed in Chapter 12, the services can be characterized within three layers:

Figure 13.3 shows some example core services, such as the object create, update, and retire services, among others; access control; data consolidation; integration; and the components supporting consolidation, business process workflows, rule-directed operations, and so on. Although the differences inherent across many organizations will reflect slight differences in the business's catalog of services, this framework provides a reasonable starting point for evaluation and design.

There is a clearly mutual dependence between the success of applications relying on master data management and those reliant on a services-oriented architecture. A services-oriented approach to application development relies on the existence of a master data repository, and the success of an MDM program depends on the ability to deploy and use master object access and manipulation services. A flexible SOA enables the organizational changes necessary to use the data most efficiently. Driving application development from the business perspective forces a decision regarding harmonizing both the data objects and the ways those objects are used, and a services-based approach allows the organization to exploit enterprise data in relation to the ways that using enterprise data objects drive business performance.

Access to master data is best achieved when it is made transparent to the application layer, and employing a services-based approach actually serves multiple purposes within the MDM environment. During the initial phases of deploying the master environment, the use of a service layer simplifies the implementation of the master object life cycle and provides a transition path from a distributed application architecture into the consolidated master application infrastructure.

Key milestones and deliverables include the following:

Exposing master data for use across existing legacy applications poses a challenge for a number of factors, including the need for customized data extraction and transformation, reduction in the replication of functionality, and adjusting the legacy applications' data access patterns. Providing the component service layer addresses some of these issues; although the traditional extraction, transformation, and loading (ETL) method is insufficient for continuous synchronization, master data services support the data exchange that will use data integration tools in the appropriate manner. In essence, the transaction semantics necessary to maintain consistency can be embedded within the service components that support master data object creation and access, eliminating the concern that using ETL impedes consistency. The consolidation of application capabilities within a component service catalog through the resolution of functionality eliminates functional redundancy, thereby reducing the risks of inconsistency as a result of replication.

Yet the challenge of applications transitioning to using the master repository still exists, requiring a migration strategy that minimizes invasiveness. To transition to using the master repository, applications must be adjusted to target the master repository instead of their own local data store. Planning this transition involves developing an interface to the master repository that mimics each application's own existing interface, and the method discussed in Chapter 12 for this transition is developing a conceptual service layer as a stepping-stone in preparation for the migration using a design pattern known as “wrapper façades.”

During the transition stage, the data consolidation processes are iterated and tested to ensure that the right information is migrated from the source data systems into the master data asset. At the same time, any adjustments or changes to the master service layer are made to enable a cutover from dependence on the original source to dependence on the services layer (even if that services layer still accesses the original data). The application transition should be staged to minimize confusion with respect to identifying the source of migration problems. Therefore, instituting a migration and transition process and piloting that process with one application is a prelude to instituting that process on an ongoing basis.

Key milestones and deliverables include the following:

At this point, the fundamental architecture has been established, along with the policies, procedures, and processes for master data management, including the following:

Having the major components of the master data strategy in place enables two maintenance activities: the continued migration of existing applications to the master environment and ensuring the proper performance and suitability of the existing master data system. The former is a by-product of the pieces put together so far; the latter involves ongoing analysis of performance against agreed-to service levels.

At the same time, the system should be reviewed to ensure the quality of record linkage and identity resolution. In addition, MDM program managers should oversee the continued refinement of master data services to support new parameterized capabilities or to support newly migrated applications.

The following are the expectations of this phase:

Master data management can provide significant value to growing enterprise information management initiatives, especially when MDM improves interapplication information sharing, simplifies application development, reduces complexity in the enterprise information infrastructure, and lowers overall information management costs. In this chapter, we have provided a high-level road map, yet your mileage may vary, depending on your organization's readiness to adopt this emerging technology.

As this technology continues to mature, there will be, by necessity, an evolution in the way we consider the topics discussed here. Therefore, to maintain that view, consult this book's associated website (www.mdmbook.com) for updates, new information, and further insights.

That being said, there is great value in engaging others who have the experience of assessing readiness, developing a business case, developing a road map, developing a strategy, designing, and implementing a master data management program. Please do not hesitate to contact us directly ([email protected]) for advice. We are always happy to provide recommendations and suggestions to move your MDM program forward!