Multidomain master data management can provide organizations with substantial value and measurable revenue and margin benefits. My previous article “Multidomain Master Data Management for Business Success,” discussed how mastering multiple data domains and managing their interrelationships will help companies realize shorter cycle times, reduced (or controlled) costs, and better forecasting, planning, and transactional and analytical outcomes.
This article defines three different architectural styles for deploying multidomain MDM, discusses the pros and cons of each approach and provides examples of which use cases might favor one style over another.
Organizations that are embarking on multidomain MDM should realize that, no matter which architectural style they choose, the process requires the management of both simple and complex master data objects. A simple master data object is an instance of a master data domain that exists by itself. A complex data object is a combination of detailed data about several master data objects that exist interdependently, and the data regarding the associations and relationships between them. Before a multidomain MDM system is deployed, master data comprising the simple and complex objects are managed independently, and often inconsistently, in various systems of record, which is what typically drives an organization to create a single version of the truth.
Let’s look at an example of a retailer of home building supplies. The company’s supplier data are complex data objects. In addition to corporate and contact information, each supplier also has master data on the products that it sells. The company also has data about volume purchase agreements, discounts and volume targets. that are facts about the relationship between the products and the vendor supplying them. If the retailer is sourcing windows, it can get the same window from several sources. One supplier may give better terms if the retailer is willing to wait a few days and order a larger quantity of products at once. Another may deliver the windows when ordered, but at a higher price. The third may deliver the windows in a scheduled shipment, and offer the most favorable payment terms. In this example, price is not a fact about the windows themselves, but rather about windows from a particular supplier and location, in specific quantities with given lead times and shipping methods. Price isn’t an attribute of the company, product or location master data objects themselves, but about the combination of those master data within the composite data object.
Multidomain MDM Architectural Styles: An Overview
Multidomain master data projects can be designed and implemented using one of three architectural styles: registry, hybrid and centralized. Determining which style is best for an organization will depend on a number of factors including how the data will be used, the number of applications that will rely on the solution, the stability of the ecosystem within which the solution will exist, and specific requirements for transactional throughput, uptime, response time, performance and scalability. Organizations should consult with an experienced enterprise architect to help them decide which architectural style makes the most sense. Enterprise architects have the requisite skills to define the characteristics of the system and to evaluate how specific business needs can and will be addressed by a chosen model today and in the future.
All three styles have something in common; they all have a master data service that is the container for simple or complex master data objects. The differences in these three styles are in the extent to which they store data inside these containers. For example, the registry style does not store all the data about the composite objects in the container, but instead stores only key references to the objects from the contributing systems. The actual detailed data is left in the external source systems. A registry system is based on a federated model that only brings the data together to complete a master data object as required.
Like the registry model, the hybrid model stores the key references to the composite object locally, but it also copies in all of the attributes required for that composite object from the outlying master data services. With a hybrid style, supplier, product, customer and other master data continue to reside in their external source systems, but a copy of the data from the different master data services is also in the centralized composite.
The centralized style consolidates multiple domains of master data into one location. In this model, customer, product, location and other master data services are no longer sourced by external systems, but instead from the centralized hub, which contains all of the attributes of the composite objects in one location and acts as the master for all data.
Companies need to determine which architectural style best meets their multidomain MDM requirements.
Registry Models are Leaner but Slower
A multidomain object implemented following the registry style contains all of the pointers and keys required to get details about the master data from the various source systems. It also includes any associative data about the interrelationships between those objects. The main advantages of a registry model are that it is lightweight (since it only has key data), can be deployed rapidly (because only a small amount of data is being moved around), is the least intrusive and is the most scalable. Registry models are also much easier to keep up to date because, once they are deployed, any additions or changes to attributes or interrelationships between master data can be made fairly easily, since usually only the external master data sources change, not the master itself. With a registry model, when a request for an object is made, the master data service can easily compile the single version of the truth by using the keys and relationship data from the various source systems contained inside the object.
