Mastering Data Management

More in Business Process Management

• Improving Business Processes with MDM
• Mobility: Inventing the New Division of Labor
• Take Charge of your Data Environment: IBM Performance Management Solutions
• Top 5 InfoSphere Demos at IOD

More in MDM

• Top Books for your MDM Library
• Recent Reads: MDM & Data Governance
• Big Data Governance: A Framework
• Predictive Data Governance for Business Transformation

More from Marty Moseley

• IAIDQ Blog Carnival: Data Fitness & Garbage
• Mind the Gap and Do Data Governance Better
• Measuring Data Governance: Metrics that Matter
• Measuring Data Governance: How Do You Know You’ve Made a Difference?

Share this Post

Recent Comments

• Lorraine Fernandes on Response: A Universal Identifier Isn’t a Silver Bullet
• Henrik Liliendahl Sørensen on Response: A Universal Identifier Isn’t a Silver Bullet
• Response: A Universal Identifier Isn’t a Silver Bullet | Mastering Data Management on 3 Best Practices in Identity Management

The main benefit of a centralized model is that all the data ever required to create or evolve a composite object is most likely already present within the MDM container.

We’ve finally come to the final architecture model in use for multidomain MDM: the centralized model.

To recap, we have discussed the basics of multidomain MDM, some of the advantages, and the registry and hybrid models. View the previous posts in this series.

A centralized model puts all master data inside a single container and results in the outlying systems being dependent upon the central master. In the centralized model’s theoretically pure state, outlying systems may not even store copies of the data, but instead, they get the data as needed from the central master.

This approach is like the registry (federated) model turned on its head. Most of the advantages and disadvantages of other single platform systems, such as enterprise relationship management systems, apply to a centralized architecture approach.

The main benefit of a centralized model is that all the data ever required to create or evolve a composite object is most likely already present within the MDM container.

The only time this would not be the case is when significant additions are made to the definition of a composite object, a new source is being added to the ecosystem or new data is otherwise being added to the data universe that didn’t exist before.

Another benefit of a centralized approach over the hybrid model is that it is easier to evolve or expand the definition of a composite object because changes only need to be made to one system.

However, there are disadvantages to the centralized approach. The primary drawback is that very few commercial off-the-shelf (COTS) source systems are built to be dependent upon an external master; they are usually self-contained and built to be independent

There can be significant license and maintenance issues in making a COTS system behave according to a centralized model.

Contrary to what many may think, this model can suffer from performance problems because it creates a much bulkier platform that may be difficult to scale. In addition, since the centralized model has to respond to all transactions that need master data, it can be difficult to tune and may create a bottleneck or a weak link, instead of a high-performance master.

Making centralized systems highly available is challenging because, whenever a change is required of any type of master data, the entire system must be taken offline to perform the maintenance or evolve the platform.

Finally, the ROI of a centralized model can take much longer to realize as the system can take years to deliver, compared to six or eight months for a registry or hybrid system.

Now that we’ve covered the details of each of the three models, how do you choose what’s best for your organization? We’ll cover that hot topic in the next multidomain MDM post.

This post is part of Marty Moseley's Multidomain MDM Series. View the table of contents for links to any parts you may have missed.