Master data management as a service-oriented architecture enabler

Learn how master data management provides service-oriented architectures a single location from which to manage data entities that are critical to enterprise processes.

Master data management and service-oriented architectureThe following is an excerpt from Enterprise Master Data Management: An SOA Approach to Managing Core Information, by Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul van Run and Dan Wolfson. It is reprinted here with permission from IBM Press; Copyright 2008. Read the chapter summary below to learn why and how master data management is essential to service-oriented architectures, or download a free .pdf of "Master data management as a service-oriented architecture enabler" to read later.

Chapter 1 is split into four parts. The authors recommend reading Chapter 1 before Chapter 2.


In this chapter we will discuss the usage of Master Data Management as an enabler of a Service Oriented Architecture.

Service Oriented Architecture (SOA) is an integration architecture in which components are available through services. These services are available through platform-neutral interfaces and communication protocols. They encapsulate application functionality to be delivered to the service consumer. They are loosely coupled and based on a formal definition or contract.

We can describe a conceptual model of an SOA architecture using four basic concepts. There is the Service Provider who realizes the service by providing an implementation for it, and who publishes a Service Description. The Service Consumer can either use the Service Description directly or optionally find it using the Service Broker. It can then bind to and invoke the service from the Service Provider. The Service Broker component (also known as a service registry and repository) is optional in this model. This component is a core repository and system of record for service definitions and policies. It is responsible for making (Web) service interfaces and implementation access information as well as metadata around policy enforcement available to potential requestors. The next figure is a depiction of the coherence of these four basic concepts.

Click image for larger view

Information is the key commodity upon which an enterprise runs. If the information stops flowing, the enterprise stops. If the information takes too long to flow from one part of an organization to another, then the business suffers. Information is stored, shared, analyzed, transformed, and consumed. Therefore, just as we seek to describe, implement, and consume discrete business services that may be reused in an SOA environment, we also need to consider how to describe, implement, and consume Information as a Service (IaaS). Without Information as a Service, processes are tightly coupled to the data. Such tightly coupled processes are brittle, and they do not adapt well to continuously changing business requirements. They also lead to:

Inconsistencies in the view and the packaging of the data:
Because each process creates its own custom access to data, the view of the data across those processes is inconsistent. For example, one process might get its customer data from a different place than another. The way the data is packaged typically also differs from process to process, which complicates integration efforts.

Inconsistencies in the rules applied to the data:
Because the rules are captured in stovepipe applications, they are tightly connected to the data, and they are not shared among processes. For example, data validation rules or the calculations involving that data can vary from process to process. This reduces the quality of the data.

Multiple points of Maintenance:
There is duplication of logic across the applications that access the data. This creates multiple points of maintenance for the same logic. This is complex, error-prone, time-consuming, and expensive. For example, each process needs to use the same logic to standardize telephone numbers or verify a product ID.

More about master data management and service-oriented architecture

Three master data management trends

SOAs and data management: Understanding the data service layer

SOA starts with the data

Using Information as a Service helps clients identify, access, manage, secure, and deliver information in real time regardless of the type of information or the platform on which it is stored. It ensures consistent packaging of data, consistent application of rules to the data, and centralized control and maintenance. To treat information as a service, one needs to agree on a number of characteristics of the information and have it commonly available: (1) the definition (structure and semantics), (2) the data quality and integrity and (3) Governance, changes to the service and the underlying information need to be governed in a uniform and consistent manner.

Click image for larger view

Without a foundation of usable information, your service-oriented architecture is just a loose confederation of abstract business processes. It's your business information that delivers the value to your SOA. Information as a service is about providing a new level of services that helps add value to information contained in data sources across an organization. By treating information as a service, organizations can improve the relevance and cost-effectiveness of their information, making information available to people, processes, and applications across the business and improving the operational impact that information can have in driving innovation.

Master Data Management (MDM) is a key component of the Information as a Service architecture. MDM provides IaaS, and SOA in general, a single location from which to manage those data entities that are critical to many of the processes in an enterprise: customers, products, accounts, locations, etc. MDM provides a consistent understanding and trust of these master data entities and a consistent mechanism for their usage across the organization.

An example of a master data element might be a customer entity. Retrieving such an entity given some identifying information sounds trivial but without MDM where does a getCustomer service get the customer information from? It will likely be scattered across in many different places in the enterprise: in the CRM system, in the billing system, in the web commerce system. So do we try to check each one and look for a consensus of its values? Do we choose one and hope it is correct? Does the context and security role of the getCustomer service invocation matter? Does each of the customer information sources structure the data in the same way? And what about the user of the service—how does a service consumer know which services he or she can trust to return clean and current data? With a single source of MDM information this problem is much easier to solve. This can be a reference source of MDM data, or a persisted form.

If we look at a SOA enterprise architecture an MDM system would typically provide the master data related atomic and composite services used by the business process layer and the associated cross cutting functionality for integration, security, monitoring etc. The shaded area in the following figure depicts this.

Click image for larger view

MDM also plays a central role in enabling the ability to change and to evolve by centralizing the maintenance and governance of the master data. Changes to the business typically affect the master data elements of an enterprise. The impact of these changes on the master data can be determined more accurately in a managed model using MDM, and the number of touch points where changes need to be applied is reduced when MDM is used. In this way, an MDM System can improve the responsiveness to business changes by centrally changing the way master data is maintained. An example of this would be new requirements around privacy regulations. Enabling privacy information, to be held at a customer level, in all of the systems that maintain customer information in an unmanaged master data environment is cumbersome and, because of resulting synchronization requirements, also error-prone. Using the MDM System to track such new privacy information at an enterprise level for customer master data reduces the impact of this extra requirement to the business significantly.

More information about enterprise master data management

Dig Deeper on MDM best practices