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.
