Mastering Data Management

More in Business Process Management

• New ebook: Understanding Big Data
• 37 Definitions of “Employee ID”
• Defining Terms: Agree, or Doom your Project
• Establishing a Valid Business “Need to Know” for Sensitive Data

More in MDM

• Best Practices in Test Data Management: Discovering and Subsetting
• TDWI Chicago Preview: Data Warehousing, Analytics & More
• Who’s Afraid of the Big Bad Data?
• MDM for Chief Privacy Officers: A healthcare provider example

More from Lawrence Dubov

• MDM Vs Data Governance: History and 8 Predictions
• What’s Harder: Starting or Sustaining MDM?
• Conclusion: Quantifying Assets
• 3 Essential Questions for Data Quality: Benchmarks, Penalties & Latency

Share this Post

Recent Comments

• ICMCC News Page » Where East Meets West: ehealth in China and the US on Where East Meets West: ehealth in China and the US
• Kim’s Training Podcast on Training as a Safety Net: Kim May
• TDWI Chicago Preview: Data Warehousing, Analytics & More | Mastering Data Management on New ebook: Understanding Big Data

Be sure to consider decomissioning obsolete systems as part of your MDM roadmap

We’ve already talked about several different types of data and information that must be included as part of your MDM roadmap. However, since MDM is often considered in part to increase efficiencies and streamline processes, you should also consider removing or excluding obsolete systems and applications as part of your MDM implementation.

Indeed, launching an MDM program often provides the impetus to holistically examine your processes, systems and data to determine what is no longer needed or extraneous.

Significant long term cost savings can be achieved if some systems or applications are decommissioned as a result of an MDM program. Decommissioning systems that have outlived their usefulness can release people and hardware resources. It can also result in cost avoidance you’re able to stop paying ongoing license costs.

For the most part, companies tend to add MDM data hub systems. Adding any system, no matter how well it is architected, complicates the overall data management. It is important to look at what workflows can be improved or eliminated and what systems can be decommissioned as a result of the MDM implementation.

Therefore if systems decommissioning is a part of the program, the decommissioning and related activities should be looked upon as a roadmap dimension. The decommissioning effort can be responsible for some additional costs in the short term but can provide significant operational and cost reduction benefits over the long run.

Even if decommissioning systems is planned only in future phases, it is still an important consideration that may impact MDM solution design decisions. If the strategy is to phase out a legacy system, the enterprise may not be willing to invest in new integration interfaces for the legacy system that are planned to be decommissioned.

Regardless, any MDM roadmap strategy shouldn’t be afraid to let go of systems or applications past their prime, and in fact should embrace the opportunity to do so. Building a comprehensive roadmap means not only determining what should be included, but what can be safely excluded.

Next week, we’ll take a look at usage and ownership styles of data hubs.

This is part of a series, Building an MDM Roadmap. For other posts and a complete index, view the Table of Contents.