Another article that’s right on the money by Mark Allen, the co-author of Master Data Management in Practice – Achieving True Customer MDM.
“MDM should be a business driven program” is the mantra we hear time and time again. And while that is the right prevailing wisdom, doesn’t it seem that there is far more articulation about the technical elements of MDM than about the business elements?
So often I have seen MDM publications and presentations start with the “should be business driven” perspective but then quickly shift to covering the technical elements of MDM, topics related to architecture, data models, data integration, metadata management, match logic, consolidation, synchronization, application services, and so on.
Yes, those all are important elements in the MDM equation, but this over-abundance of technical insight can be frustrating for those seeking practical knowledge and guidance for the business planning of an MDM program. After all, without a strong business presence, MDM can’t develop into a core competency throughout the company. So why, in comparison, is so little insight provided about the business side of the equation?
Actually, it’s easy to understand this situation. The plethora of technical insight is a byproduct of the influence that IT and vendors have on the MDM market. And that’s not suggesting that business organizations don’t care to promote their MDM practices, it’s just that there is much more uniqueness and latency involved with getting these business components established, and these dynamics are harder to articulate.
Let’s take a closer look at these influences and dynamics.
The call for MDM
The initial need and sponsorship for an MDM initiative often emerges from the IT and/or analytical groups in a company. These groups usually exist separately or on the periphery of the business. The IT and analytical areas responsible for activities such as system integration, data migration, information management, data warehousing, business intelligence and reporting will typically be the first to expose where poor data quality and lack of data governance is creating project delivery delays, data management problems, integration issues, distrust of the data, and reporting problems.
Therefore, it’s understandable that these groups become initial proponents of MDM solutions. And while the root cause for many of these data problems lies in front-end business practices and data entry points, the IT and analytical groups are most directly impacted and naturally tend to implement their own back-end corrective actions.
At some point these ongoing problems and workarounds become a tangled mess, and that situation becomes a catalyst for seeking an MDM solution. Current state issues, improvement opportunities, and cost/benefit projections cited in MDM proposals are usually centered on correcting these legacy issues, improving data governance and information management practices, and eliminating the workaround overhead. In other cases, MDM programs often emerge when legacy applications are being replaced with more integrated platforms such as business application suites, data hubs, and enterprise warehouses where IT planning and activity is already underway.
Product vendor and consulting influence
Because of the large market opportunity and competition among MDM product vendors and consulting firms, it is expected that they will have a significant influence on the MDM information being presented. Technology and consulting help should always be factored into an MDM assessment and implementation plan. Although the overall impact and practical use of both can often be overstated, good technology and consulting help applied in the right places can definitely advance MDM capability and reach.
But many other aspects of implementing MDM involve new and unique business practices, business context, and process management where technology and consulting help will only have limited application, if any.
MDM is as much about people and process as it is about technology, which is why product vendors are increasingly looking at improving their business consulting practices or consulting partnerships as a competitive advantage. Over time this trend should help bring a better balance of information and practical insight for the planning and implementation of MDM.
Discovery and Analysis
At the onset of an MDM initiative, a “Discovery and Analysis” phase is conducted to fully detail the issues, root causes, business and system impacts, and opportunities for improvement. This discovery and analytical phase is often led by IT or an analytical team, if not a consulting group. Business leads should be actively involved in this phase, but specifically how and where business groups will be needed to drive and support MDM plans will largely depend on what priorities and direction come out of this discovery and analysis work. And where the business engagement needs are identified, the business groups will often need time to plan, budget, and prepare for these activities.
Implementing process improvements and driving data governance activity can be new or disruptive territory for business organizations. Many MDM programs do not have sufficient budgets to cover these business area needs, therefore the implementation of these business elements can take some time.
MDM job roles
IT groups already have most of the necessary job roles and skill sets needed (e.g. analysts, architects, project managers, programmers, data miners, database administrators) to initiate and support the technical aspects of MDM. The business roles needed within a MDM program (e.g. data governance leads, data stewards, process analysts, quality managers, data access gatekeepers) often do not already exist as formal job roles. Consequently these roles either have to be assigned to existing resources that have other job responsibilities and/or created through new hires, job transfers, or contracted positions which can require budget allocation and also take time to fulfill. Therefore it’s common to see IT and analytical related activity initiated early on while the business roles and needs are being addressed.
In MDM and data governance maturity models, we typically see the advanced levels of maturity defined using terms such as Managed, Optimized, Proactive, Advanced, or Transformational. But in many of these models, those levels are characterized by more system and analytical orientated achievements, related to systems integration, establishing a system of record, business process automation, using SOA/SaaS, quality monitoring, delivering trusted analytics and KPIs, and so on.
The business area maturity needs and milestones — associated with data governance, data life cycle management, and quality control — are much less apparent in these maturity models.
Granted, much of the program development and maturity on the business side of a MDM program is going to be tied to unique business practices that are harder to generalize in a high-level maturity model. Therefore it often takes some digging in MDM and data governance forums or finding business case studies to gain good insight on how and where the business events and the maturity of business practices have occurred in a MDM implementation.
A developing dynamic
So even though it is critical for business to be involved and provide leadership in an MDM program, defining, articulating, and achieving that is likely to be a developing dynamic that spawns from IT and analytical underpinnings where product vendors and consulting firms are also well entrenched. As more companies launch MDM initiatives and develop their MDM core competencies across their business model, we can expect to see increasing amounts of business insight and best practice information made available that will express how and where business roles and business practices evolved in MDM programs. I look forward to that.
Mark Allen is co-author of the book “Master Data Management in Practice: Achieving True Customer MDM”. Mark has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and with leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.