In this usage scenario, the focus is on the importation of data into the master data environment and the ways that the data is enhanced and modified to support the dependent downstream applications. The expectation is that as data is incorporated into the master environment, it is then available for “publication” to client applications, which in turn may provide feeds back into the master repository.

For example, consider a catalog merchant that resells product lines from numerous product suppliers. The merchant's catalog is actually composed of entries imported from the catalogs presented by each of the suppliers. The objective in this reference information usage scenario is to create the master catalog to be presented to the ultimate customers by combining the product information from the supplier catalogs. The challenges associated with this example are largely driven by unique identification: the same products may be provided by more than one supplier, whereas different suppliers may use the same product identifiers for different products within their own catalogs. The desired outcome is the creation of a master catalog that allows the merchant to successfully complete its order-to-cash business process.

In this scenario, data enter the master repository from multiple streams, both automated and manual, and the concentration is on ensuring the quality of the data on entry. Activities that may be performed within this scenario include the following:

In contrast to the reference information scenario, some organizations endeavor to ultimately supplement all application data systems with the use of the master environment. This means that operational systems must execute their transactions against the master data environment instead of their own data systems, and as these transactional business applications migrate to relying on the master environment as the authoritative data resource, they will consume and produce master data as a by-product of their processing streams.

For example, an organization may want to consolidate its views of all customer transactions across multiple product lines to enable real-time up-sell and cross-sell recommendations. This desire translates into a need for two aspects of master data management: managing the results of customer analytics as master profile data and real-time monitoring of all customer transactions (including purchases, returns, and all inbound call center activities). Each customer transaction may trigger some event that requires action within a specified time period, and all results must be logged to the master repository in case adjustments to customer profile models must be made.

Some of the activities in this usage scenario are similar to those in Section 9.2.1, but here it is more likely to be an automated application facilitating the interaction between the business process and the master repository. Some activities include the following:

Analytical applications can interact with master data two ways: as the dimensional data supporting data warehousing and business intelligence and for embedded analytics for inline decision support. One of the consistent challenges of data warehousing is a combination of the need to do the following:

Analytical applications are more likely to use rather than create master data, but these applications also must be able to contribute information to the master repository that can be derived as a result of analytical models. For example, customer data may be managed within a master model, but a customer profiling application may analyze customer transaction data to classify customers into threat profile categories. These profile categories, in turn, can be captured as master data objects for use by other analytical applications (fraud protection, bank secrecy act compliance, etc.) in an embedded or inlined manner. In other words, integrating the results of analytics within the master data environment supplements analytical applications with real-time characteristics.

Aside from the activities mentioned in previous sections, some typical activities within the analytical usage scenario include the following:

In a registry-style architecture (as shown in Figure 9.1), a thin master data index is used that captures the minimal set of identifying attribute values. Any presented record's identifying values are indexed by identity search and match routines (which are discussed in greater detail in Chapter 10). The master index provided in a registry model contains pointers from each uniquely identified entity to the source systems maintaining the balance of the master data attributes (see Figure 9.1). Accessing the “master record” essentially involves the following tasks:

The basic characteristics of the registry style of MDM are as follows:

The following are some assumptions regarding the registry style:

Simply put, a transaction hub (see Figure 9.2) is a single repository used to manage all aspects of master data. No data items are published out to application systems, and because there is only one copy, all applications are modified to interact directly with the hub. Applications invoke access services to interact with the data system managed within the hub, and all data life cycle events are facilitated via services, including creation, modification, access, and retirement.

Characteristics of the transaction hub include the following:

The following are some assumptions that can be made regarding the development of a repository-based hub:

A happy medium in contrast to both the “thin” model of the registry and the “thick” transaction hub provides a single model to manage the identifying attributes (to serve as the master data index) as well as common data attributes consolidated from the application data sets. In this approach, shown in Figure 9.3, a set of core attributes associated with each master data model is defined and managed within a single master system. The centralized master repository is the source for managing these core master data objects, which are subsequently published out to the application systems. In essence, the centralized master establishes the standard representation for each entity. Within each dependent system, application-specific attributes are managed locally but are linked back to the master instance via a shared global primary key.

The integrated view of common attributes in the master repository provides the “source of truth,” with data elements absorbed into the master from the distributed business applications' local copies. In this style, new data instances may be created in each application, but those newly created records must be synchronized with the central system. Yet if the business applications continue to operate on their own local copies of data also managed in the master, there is no assurance that the values stored in the master repository are as current as those values in application data sets. Therefore, the hybrid or centralized approach is reasonable for environments that require harmonized views of unique master objects but do not require a high degree of synchronization across the application architecture.

Some basic characteristics of the hybrid or centralized master architecture include the following:

The first question to ask focuses on the number of data attributes expected to be managed as master data. Depending on the expected business process uses, the master index may be used solely for unique identification, in which case the number of master attributes may be limited to the identifying attributes. Alternatively, if the master repository is used as a shared reference table, there may be an expectation that as soon as the appropriate entry in the registry is found, all other attributes are immediately available, suggesting that there be an expanded number of attributes. Another consideration is that there may be a limited set of shared attributes, even though each system may have a lot of attributes that it alone uses. In this case, you may decide to limit the number of attributes to only the shared ones.

The requirement for data consolidation depends on two aspects: the number of data sources that feed the master repository and the expectation for a “single view” of each master entity. From the data input perspective, with a greater number of sources to be fed into the master environment there is greater complexity in resolving the versions into the surviving data instance. From the data access perspective, one must consider whether or not there is a requirement for immediate access to all master records such as an analytics application. Immediate access to all records would require a higher degree of record consolidation, which would take place before registration in the master environment, but the alternative would allow the survivorship and consolidation to be applied on a record-by-record basis upon request. Consolidation is discussed at great length in Chapter 10.

As we will explore in greater detail in Chapter 11, the necessary degrees of timeliness and coherence (among other aspects of what we will refer to as “synchronization”) of each application's view of master data are also critical factors in driving the decisions regarding underlying architectures. Tightly coupled environments, such as those that are intended to support transactional as well as analytical applications, may be expected to ensure that the master data, as seen from every angle, looks exactly the same. Environments intended to provide the “version of the truth” for reference data may not require that all applications be specifically aligned in their view simultaneously, as long as the values are predictably consistent within reason. In the former situation, controlling synchronization within a transaction hub may be the right answer. In the latter, a repository that is closer to the registry than the full-blown hub may suffice.

This aspect is intended to convey more of the control of access rather than its universality. As mentioned in Chapter 6, master data management can be used to both consolidate and segregate information.

The creation of the master view must not bypass observing the policies associated with accessing authorization, authenticating clients, managing and controlling security, and protecting private personal information. The system designers may prefer to engineer observance of policies restricting and authorizing access to protected information into the service layer. Controlling protected access through a single point may be more suited to a hub style. On the other hand, there are environments whose use of master data sets might not necessarily be subject to any of these policies. Therefore, not every business environment necessarily has as strict a requirement for managing access rights and observing access control. The absence of requirements for controlling access enables a more flexible and open design, such as the registry approach. In general, the hub-style architecture is better suited for environments with more constrained access control requirements.

A reasonable assessment of the business functionality invoked by applications should result in a list of defined business services. A review of what is necessary to implement these services in the context of MDM suggests the ways that the underlying master objects are accessed and manipulated using core component services. However, the degree of complexity associated with developing business services changes depending on whether the MDM system is deployed as a thin repository or as a heavyweight hub. For example, complex services may be better suited to a hub, because the business logic can be organized within the services and imposed on the single view instead of attempting to oversee the application of business rules across the source data systems as implemented in a registry.

Applications that access and modify their own underlying data sets are able to process independently. As designers engineer the consolidation and integration of replicated data into a master view, though, they introduce a new data dependence across the enterprise application framework. An MDM program with a single consolidated data set suddenly becomes a bottleneck, as accesses from multiple applications must be serialized to ensure consistency. This bottleneck can impact performance if the access patterns force the MDM services to continually (and iteratively) lock the master view, access or modify, then release the lock. A naively implemented transaction hub may be subject to performance issues.

Of course, an application environment that does not execute many transactions touching the same master objects may not be affected by the need for transaction serialization. Even less constrained systems that use master data for reference (and not transactional) purposes may be best suited to the registry or central repository approaches.