Multidomain MDM: Make Sure You Do the Homework First

Marty Moseley

There are two categories of in-depth analysis required when determining which multidomain master data management (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.

The business case analysis must always come first. And 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 example, a business-to-business or a business-to-consumer company might want to build a multidomain MDM service that puts all customer data in one place and manage it to achieve incremental business value. It might also want to identify opportunities to cross-sell and up-sell to increase revenue, which means it will require information about the interrelationships between customer and product data, and it also will need to look at data about the products it wants to sell.

To boost wallet share, it is likely that this company will also want to know which licenses or entitlements its customers have. In addition, the organization may have a strong business need to better manage its product catalog to improve customer satisfaction and to ensure that customers are receiving consistent prices across all channels: offline, online, direct and indirect, etc. Finally, the company will most likely want to perform marketing analytics to make its 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 a focus and thus overlooking likely use cases, such as providing consistent prices to customers.

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 they affect the proposed system. This analysis helps to ensure that overall system availability, scalability and reliability requirements are met for each potential business use.

A number of areas need to be analyzed to determine which multidomain MDM architecture is best for an organization. They include:

  • 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 immediately? Several hours later? Or next day?
  • Volumetric analysis looks at the size of the master data domain. How many records will it have? How many years of history will it have to support? What are the scalability requirements for the master data service container? 
  • 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 data to a master data domain, 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 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 required? When they are taken down, are they ever managed separately?
  • 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 (registry, hybrid or centralized) might be best for the multidomain MDM service.  None of the three multidomain MDM architectural styles are right or wrong on its own. Deciding 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 re-engineering 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.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.