In a recent blog post for the DataFlux Community of Experts I discussed what an MDM Strategy is. In the post I raised one of my all time favourite quotes on strategy from Sun Tzu:
All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.
Having a strategy to guide your enterprise MDM operation is critical to success. However a strategy without a plan for deployment is all hot air, it’s about as useful as a chocolate teapot.
Therefore in this post I would like to prove that I am not all hot air, and stake a claim at being more like a china teapot than a chocolate one.
Background to the MDM Deployment Model
It was quite a few years ago that I developed a model very similar to this as part of a repeatable methodology for traditional BI deployments. Over the years I have used this to great success in a number of large BI deployments.
As I ventured into the world of MDM, if felt that the model could be adapted to provide a similar methodology for MDM deployment. I think it works, however, I suppose if I didn’t I wouldn’t be writing about it …
What is a Deployment Model
To continue on a military theme for definition – ‘Deployment’ in military terms means ‘the distribution of military forces prior to battle’. Taking that into a business context a Deployment Model serves as a framework for the distribution of all resources prior to deployment.
i.e. getting all your ducks in a row before you embark on your MDM initiative.
What does the MDM Deployment Model look like?
I have found the easiest way to define what the Deployment Model is, is through the graphic below.
Each section relates to a task, process and high level deliverable or work product common throughout a typical MDM program. And being a project management geek I have annotated each of them to allow the creation of a detailed program blueprint and product flow diagram. Cool eh??
Ummm, there is a lot going on in that graphic, what does it mean?
Behind this graphic sit a couple of documents that detail each deliverable in ‘business speak’. These highlight what is required (at a summary level) and where each deliverable fits in, in a typical project flow.
It is important here that these deliverables are detailed in ‘business speak’. This model is a great ‘tool’ in promoting the need for proper structure to your MDM initiative, and proper structure comes at a cost. Having a tool that can be understood at a business level goes a long way in helping build sponsorship and a financial support.
Peeling off the layers
This model is a layered approach, taking its lead through aligning to the business strategy and goals.
MDM Strategy is the overarching governance that defines the goals, reasons, approach and standards by which individual initiatives will be implemented. For long term success in MDM it is imperative that a MDM strategy is defined prior to any implementation at any level.
MDM Principles and Standards are the documented ‘governance’ principles around how MDM is to be implemented and how it adheres to IT strategy and architecture standards. It also aligns to the compliance and regulatory principles of the business.
MDM Delivery Methodology is an overarching approach to how MDM is implemented in the specific business scenario, including the definition of the program / project approach and the business context within which the MDM initiative will sit. This deliverable allows for the model to be customized ensuring it is fit for purpose and relevant to the business need and situation.
The Project Management layer includes the project management approach and style, business requirements and the key Data, Technology and Application and Organizational Tracks. It is multifaceted by design allowing for each project to pick the key work-products that are relevant to each initiative as you move through your MDM program. No MDM project is the same, and the approach to each project needs to be dynamic, whilst still operating under a structured framework.
Deployment is pretty much as it says on the tin. Chose a deployment method that fits the organisation and requirement and the project management will control its delivery.
Maintenance is an important component of the model. Ensuring that you focus on how you are going to manage continued support and maintenance of your MDM environment is critical to on-going success, something I touched on in my blog post ‘The Continuous Improvement Model in Data Governance’
Conclusion
As I started with a quote from Sun Tzu, I thought I would end with one:
The general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat … It is by attention to this point that I can foresee who is likely to win or lose.
The MDM Deployment Model provides that structured approach to allow us to make the calculations necessary before we embark on our MDM initiative. And in doing so we will be successful in ‘doing MDM’ – allowing us to win the battle.
I am interested in what you think, let me know if you feel we need to add to or adjust the model in any way?
Charles;
If brevity is the soul of wit, then economy must be the heart of a good model: well done.
Only one small observation and you may have covered this off already…the data model should look beyond the usually limiting dimensions of ‘our enterprise’ to make sure it can accommodate all enterprises in the future. As the Sun master says: All modelling is obsolete once the enemy is engaged.
John O’
John,
Thank you for your comments. I totally agree, the model needs to be extendable and customizable to ensure it will work in any future enterprise. The project management layer needs to be a collection of ‘pick and choose’ best practices and tools to fit any MDM initiative along with defining the other layers to fit the enterprise.
Thanks
Charles