I blogged yesterday about two of the main use-cases of MDM: operational MDM and analytical MDM. Mark Beyer and I would “argue” if there was a way to denote the primary difference of the two, with respect to governance. I explained that in operational MDM, governance is “active” and in analytical MDM, governance is “passive”. I felt this was a good way to describe that in the former, there is explicit, business involvement day-to-day, to take decisions that changed processes and data in order to achieve and sustain, “single view”. In BI land, with analytical MDM, the work is much less day-to-day, in that rules are created by IT to be invoked during a data load.
In analytical MDM there is no message or alert sent to a business user, that is resolved during the normal cycle of work events. It would be more of a project, rather than a process. This is a major difference between the two domains; and a difference that must be taken heed of. Too many users miss the point and assume that what works with BI will work with MDM. I hear, too often, the comment, “I can ‘do’ MDM with my BI/data warehouse”. This is partially true in terms of the mechanics; but in terms of the process.
Mark is very fair, and logical, and he says that there is no governance in BI. He is very right, since for him, governance implies activity (not just mechanical rules). So we do agree; we just differ how we name the condition.
Guided Governance versus Mechanical Governance
Given that analytical MDM and operational MDM share common mechanics, it is easy for BI technology to be used (i.e . demonstrated) to support governance. The problem is that this is not the entire solution. I saw a vendor demonstrate a new “governance application” that showed, reasonably nicely, numerous mechanical activities a user would follow day-to-day. These mechanics supports an operational MDM environment – they could be seen to support day-to-day, business user activities that they would have executed anyway.
What was missing from the briefing was, as I said on the briefing, “guided governance”. The vendor had no demonstrable technology that provided the business user with analytics and metrics related to data quality, process exaction, or process design. As such, there were no guard rails or searchlights highlighting where business users (i.e. stewards) need to work their magic. It is like piloting an aircraft with a manual; everything goes great until environmental conditions change for which the manual cannot predict and instrumentation is needed to guide the user to make a decision. As with the example, bad news is what happens as a result of this lack of instrumentation.
I called this instrumented environment, “guided governance” versus the more common “mechanical governance” that this, and most other vendors, is initially focused on. It won’t be long before users help the vendors out and tell them what they need (once they start flying those planes).
Read Complimentary Relevant Research
100 Data and Analytics Predictions Through 2021
Over the next few years, data and analytics programs will become even more mission-critical throughout the business and across industries....
View Relevant Webinars
Digital Business Architecture: From Strategy to Guiding Execution
New techniques have emerged to help CIOs and EA practitioners leverage business architecture to guide investment and execution decisions,...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.