Like SOA, properly architected MDM provides businesses with flexibility and agility. In addition, it can add a higher level of quality by presenting a cleansed federated view of corporate data so that there is only “one truth” to the questions that are asked by the consumers of data. Like SOA, I am a huge fan of MDM and will have some upcoming posts about how my company is leveraging it. But also like SOA, MDM can be another transformational initiative that can have disastrous consequences if we focus only on the technology side of the house. I wrote an article called the Top 10 Reasons Why People Make SOA Fail for CIO.com last year. Here is a summary:
- Fail to explain the business value
- Underestimate the impact of organizational change
- Fail to secure executive sponsorship
- Try to do it “on the cheap”
- Lack the required skills
- Poor project management
- Think of it as a project instead of an architecture
- Underestimate the complexity
- Fail to implement and/or adhere to governance
- Let vendors drive the architecture
Guess what? All of these same reasons apply to MDM. Granted the scope of MDM is typically smaller than SOA. In fact many SOA initiatives have a MDM component as part of the deliverable. But large MDM initiatives are extremely challenging especially since it targets the corporation’s crown jewel, the data! So here is my advice for those getting ready to start a MDM initiative.
- Start with the problem not the solution – Make sure MDM solves a key business problem and explain it as a business solution. Don’t use the words MDM with business people!
- Do an organizational change management assessment – Many techies scoff at this notion. This is critical to the success of large transformational projects. I highly recommend using a consultant because they can see things that those deeply rooted in the culture cannot.
- Secure strong executive sponsorship – Find a champion on the business side or leverage your C-Level IT folks if they have the integrity and respect of the leadership team. They need push this initiative down through the ranks and remove all obstacles that interfere with the success of the initiative.
- Don’t cut out steps to save money – When I say don’t do it on the cheap I am not saying you have to buy expensive tools. There are some great open source tools that may work for you. What I am saying is don’t cut out steps, don’t refrain from bringing in experts because they are expensive, don’t skip architecture and planning steps, etc.
- Partner with experts, acquire resources with the proper skills – Why reinvent the wheel? Hire an expert who has implemented MDM many times and leverage his/her expertise. Leverage some experienced consultants to work side by side with your people to get real on the job training. Hire some full time employees with MDM experience. If your budget does not allow for new hires, get rid of the dead weight or those resistant to change and replace them with people who have the necessary skills. Don’t put all of your eggs in the consulting basket!
- Put your best project manager(s) on the project – It still comes down to controlling scope, getting the right requirements, mitigating risks, and communicating effectively. This is one series of projects that you cannot afford to have fail.
- Think of MDM as an evolution, not a project – Define the future state and break up the initiative into a series of manageable deliverables. I recommend an architectural assessment and well defined strategy as an early deliverable. Why does the first deliverable always have to be production ready code? Get a plan in place first!
- Don’t underestimate the complexity – Take time up front to fully grasp what you are about to undertake. There is nothing more embarassing than telling your users that you need more time because you didn’t anticipate numerous tasks. In many cases they won’t care and will hold you to your original dates. Then you start to cut out steps (see #4).
- Implement and adhere to governance – There is nothing worse than devoting huge amounts of time building out a great architectural solution, only to see its value degrade over time due to lack of control and standards. If you are not going to govern your MDM, why bother go through the effort?
- Don’t let vendors drive the architecture – There are plenty of wonderful tools in the Magic Quadrants and in the Wave, but that doesn’t mean you need to buy them. You may already have everything you need. You may not need all of the features in commercial products and can find a reliable open source solution. Whatever you do, make sure you come to that decision by analyzing your business and technical requirements, evaluating tools based on these requirements, and performing a proof of concept before committing your precious capital. Don’t let the Power Point slides blind you! Anybody can make a nice Power Point deck. Only a few tools will actually meet your needs at your price!
Now that SOA is dead, let’s learn from this tragedy and not kill off another dear ally. Maybe we should even stop using the term MDM now and start talking about data services. Maybe we should discuss the concepts of “One view of the Truth” instead of talking to the business about data transformations and federated views. Maybe if we can get MDM right, we can bring SOA back to life. After all, I would argue that you are not really getting the benefits out of SOA without abstracting your data layer. Regardless, we need to focus on architecture. Define the future state and create a plan on how to get there one step at a time. It will be a long journey that pays dividends with every milestone that gets completed. Let’s get this one right!