Organizations that deploy multidomain master data management services and manage interrelationships between multiple data domains will realize shorter cycle times, reduced (or controlled) costs, and better forecasting, planning and transactional and analytical outcomes. Before a multidomain MDM service is deployed, a company should conduct a thorough analysis of the business uses and value of the system and the demands placed on it. The results of the analysis will help determine which multidomain architectural model is best for them. 
This article, the third in a series of articles, is intended to assist companies in deploying successful multidomain MDM implementations and will discuss the types of decisions that need to be made and the analysis required to help define the optimal solution to meet a specific organization’s needs. The first article “Multidomain Master Data Management for Business Success” discussed different business cases and needs that would benefit from multidomain MDM systems. The second article “Choosing the Optimal Multidomain MDM Architecture” gave an overview of the three types of multidomain MDM architectural styles (registry, hybrid and centralized) and provided a high-level discussion of which styles were best for specific types of organizations and tasks. 
In this article, I discuss the two categories of in-depth analysis required when determining which multidomain MDM architecture style is best for an organization. The first is a business case analysis, which involves understanding how the system will be used to create value for the company by improving specific business processes. The second is an analysis of system environmental use metrics, which will ensure that availability, scalability and reliability requirements are supported. The combination of these analyses will help system architects determine whether a registry, hybrid or centralized architectural approach is best for their organization.

Business Case Analysis Comes First


The first questions that the multidomain MDM enterprise architect needs to answer are, what are the specific business value propositions for these services, and what are the interdependencies of the data being managed? When defining the potential use cases for these services, the architect should try to be realistic about how data will be used now and in the future, and attempt to balance short and long-term views – which can be a challenge for enterprise architects. 
For example, a business-to-business or a business-to-consumer company may want to build a multidomain MDM service that puts all of its customer data in one place and manage it to achieve incremental business value. They may also want to identify cross-sell and up-sell opportunities that increase revenue, which means that they will require information about the interrelationships between customer and product data, and they will also need to look at data about the products they want to sell. To boost wallet share, it is likely that this company will also want to know which licenses or entitlements their customers have. In addition, the organization may have a strong business need to better manage its product catalog to improve customer satisfaction and ensure that customers are receiving consistent pricing across all channels: off-line, online, direct and indirect, etc. Finally, the company will most likely want to perform marketing analytics that enable them to make their marketing campaigns more effective and increase revenue and profits. The goals for defining business use cases should be to avoid analyzing too many use cases that are unlikely to come to fruition, such as real-time tailored marketing, while not having too narrow of a focus and thus overlooking likely use cases, such as providing consistent pricing to customers.
After business priorities and the list of business use cases that will deliver the highest value for the multidomain MDM system have been completed, a thumbnail example of each use case should be developed. These thumbnail examples are representations of the component ecosystem and provide a high-level view of how system environmental metrics will be impacted by each use case.
The architect can use the completed thumbnails as references to begin to draw a network map that defines each data domain and the interdependencies (affinities) or stickiness between them. The lifecycle of data and business processes should be evaluated to determine which systems will provide the data for each process in the multidomain MDM service and what the affinities are between data domains.
After analyzing the affinities, an architect may determine that some interdependencies are so great that the best approach is to combine data domains, rather than keep them separate. 
For example, if 80 percent of the time a company uses customer name data, it also uses address data for that customer, then separating name and address into two separate data domains may add an unnecessary level of complexity and transaction overhead. Combining name and address data may be a more practical approach because the customer name is rarely used without an address. However, if customer data is only used a small percentage of the time that address data is used, it may be better to keep them separate because combining the two may unnecessarily burden address data (as it would be carrying customer data as a payload). These types of decisions will also depend on how they impact other system factors.
Sometimes there will be data domains, such as license or entitlement documents, that cannot exist without a customer and a product, which may result in a decision to co-locate them into a centralized model. However, after looking closely at transaction or other system requirements, the architect may determine that it makes more sense overall to use a registry or hybrid model.* In another situation a company may consider license data to be an attribute of the customer, and thus always includes it as part of customer data. Or, there may be circumstances where the affinity between license, customer and product data is so strong that an architect will decide to locate the license domain next to, or centralize it with, the customer or product domain.
Once the business use case portion of the multidomain MDM architecture analysis is complete, the next step is to conduct a more in-depth analysis of use cases and how it impacts the proposed system environment. This next phase of analysis helps to ensure that overall system availability, scalability and reliability requirements are met for each potential business use.

Analyzing How Business Uses Impact The System Environment 


A number of areas of system analysis need to be conducted in order to determine which multidomain MDM architecture is best for an organization. They include the following:

  • Transaction analysis. Transaction analysis identifies how many and what size transactions the multidomain MDM service will need to support. Will the volume change over time or during certain times of the day or the year? Can the changes in use be predicted? Will the transactions be small and autonomous or larger and grouped? What is the required transaction response time immediate, several hours later or next-day notification? 
  • Volumetric analysis. Volumetric analysis looks at the size of the master data domain. How many records is it going to have? How many years of history will it have to support? What are the scalability requirements for the master data service container? 
  • Complexity analysis. Complexity analysis involves understanding how complex the ecosystem is for each of the master data domains. How many other systems will participate as nodes that feed a master data domain data, send it updates, or get data from it? Will data feeds, updates or data requests be synchronous in real time, or less time-sensitive or asynchronous? 
  • Availability analysis. Availability analysis evaluates how much uptime is required for each master data service. Do they need to be always available, or can they be offline for minutes or hours at a time? Are there periods during the year or a season when no downtime is a requirement? When they do get taken down, are they ever managed separately?  
  • Stability analysis. Stability analysis measures the static or dynamic nature of a master data domain. Are there domains with data that rarely change and are not very dynamic? Which domains contain data that are likely to change often? How much are the volumes of data in dynamic domains expected to increase?

Once the analysis of each of these areas is complete, an architect can evaluate the results and begin to make decisions about which architectural style might be best for the multidomain MDM service. Here are a few typical scenarios:

  1. When there are high transaction rates or high performance and throughput requirements, a hybrid model that has all of the required data contained within the master data service to process transactions is probably the best approach.
  2. If the number of records is going to be extremely large, a registry model might be preferred because it limits the amount of data that needs to be stored in the multidomain service. However, even if the number of records is large and the company has real-time business requirements and a fairly high transaction rate, then a hybrid model may be preferred, despite the fact that the number of data elements and records are going to keep going up.
  3. When the master data domain has a dozen or less systems sending and receiving updates, transaction rates at a couple hundred an hour and response times that are measured in seconds, rather than milliseconds or minutes, then putting the domains together in a centralized model will probably be okay.
  4. If domains have different downtime schedules for maintenance, loading or configuration, and there are some domains that have strict uptime requirements, then it makes sense to keep domains separate in either a registry or hybrid model. Otherwise, whenever one of the pieces changes, the entire system may have to be cycled to incorporate changes.
  5. When a system is dynamic and the data is expected to change frequently, then a registry model may be preferred because it is the lightest weight and the easiest to change. However, if the system also has high transaction rates and large volumes of data, it may make sense to use a hybrid model.

Making the Architectural Decision


None of the three multidomain MDM architectural styles are right or wrong on their own. Deciding on which style to choose depends on the specific needs of an organization, which is why a careful business and system analysis is required to make an intelligent and informed choice. Investing in the analysis upfront helps prevent unnecessary costs and reengineering efforts later. 
This process is complex and requires a company to involve an experienced enterprise architect in the project. The architect will be capable of understanding the challenges, metrics and business use cases and, based on that information, be able to make the best architectural decision for the organization.
Note: A registry system is based on a federated model that only brings data together to complete a master data object as required. The hybrid model stores key references to the composite object locally, but also copies in all of the attributes required for that composite object from the outlying master data services. The centralized style consolidates multiple domains of master data into one location, and master data services are not 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. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access