by Julie Hunt

It’s always great to get a briefing from a very knowledgeable and flexible founder of a young company: tapping into original vision that has been tempered by the experience of customer implementations can be a rich experience. Recently the MDM Think Tank chatted with Martin Turvey, CEO of Loqate, about location intelligence and data quality. Loqate may be a young company, but in many ways, it is not a “start-up” due to the extensive expertise of founders Turvey and Paul Flew, in the areas of address quality practices and location intelligence — and the technologies that support them. Flew’s strong NLP (natural language processing) background is also an important asset for Loqate.

For most businesses, accurate address data is essential; poor address quality costs companies tons of money and lost customers. Not only is missing address information a problem, but inconsistent address data across repositories impedes data synchronization and calls into question the accuracy of all of the data. Turvey provided an interesting point: over 80% of data has a location element (source: PBBI). This means that verifying and cleansing address data, and then adding geocoding, can greatly enhance the usability of this data.

Use cases for location intelligence include: fraud detection, insurance risk assessments, improving mailing and shipping operations, real time mapping of web content and news feeds. Loqate maintains a repository of reference data comprised of address, geocodes, languages and other data covering 242 countries and territories.

Loqate is one of the few independent software vendors for address quality / location intelligence services, since most of the other vendors have been acquired by the usual suspects. Traditional data management stacks from the large infrastructure vendors are not an option for many companies, especially in emerging markets and the larger international arenas for address quality needs.

So Loqate is positioning its independence as a competitive differentiator that allows it to target solution niches not usually covered by the big infrastructure vendors.  This positioning is strengthened by Loqate solution innovation and future direction, including an upcoming Cloud / SaaS offering. Turvey commented that most MDM solutions fail at what Loqate does well for address quality and location intelligence. As to sales model, the Loqate solution is only available through Loqate partner companies that OEM or sub-license the technology.

The components of Loqate are broken down into:  Verify, Geocode, Register, and Identify. Additional technology includes the Geo-Data Quality Engine and the Global Knowledge Repository.

In Verify, where validation and clean up are performed, powerful differentiation exists in the parsing methodology. Based on lexicon and context, parsing algorithms understand what the data should be, based on context parameters. Loqate parsing capabilities analyze and remediate data in situ, and do the hard work on single strings without breaking the string into components first. In fact, the string’s structural context provides cues for Loqate’s parsing / validation. Most other data quality tools require users to do quite a bit of hands-on mapping and other tedious work as preparation for remediation. This isn’t the case for Loqate Verify. Parsing is also trans-global for processing records and strings with mixed international character and language sets. Data can also be transliterated from one character set to another character set (e.g. Roman to Katakana in Japan)

Turvey cited a use case for Fraud Detection: cheats will use fake addresses made up of components that are valid on an individual basis (real street address, real city), but in combination the components do not add up to a valid address. Most other address quality and data quality solutions will vet the individual components but not the composite, which means they may validate a fraudulent address.

Loqate provides real value by trapping errors at data entry time when remediation is at the cheapest point. It’s also essential to trap inconsistencies at data entry to prevent fraud and block bad data from infecting processes such as shipping that can greatly impact costs.

Geocoding is available for every address data element “out of the box”. The geocode assignment results from high granularity generation of a latitude-longitude coordinate for any address worldwide. From the geocode a map visualization can be created, accurate to delivery point / rooftop levels.

Register provides smart data entry to reduce errors and speed up operational processes. This is particularly useful when working with customers, whether it’s a call center employee talking to a customer or a self-service interface for eCommerce.

Identify:  The Loqate Entity Extraction module enables location, additional geographic and contact information to be identEified and extracted from web content and other unstructured information sources. LocationV extractions enable content to be localized, driving location-based services and geographically targeted advertising.

Loqate has included the ability to quantify address data quality through its Accuracy Code analysis. A verification accuracy match score portrays the similarity between input data and the closest reference data match as a percentage between 0 and 100, with 100 as best match, as well as detailing what changes have been made to each key component during processing and determining validity of those components.

Right now, user tweaking is limited and is mainly accomplished through processing rules. There is no means as yet to tweak algorithms. Loqate is taking a slow approach here, being careful not to lead users astray, since algorithm changes can end in unexpected and harmful consequences.

Next up for Loqate is an impending Cloud / SaaS offering that should be available Spring 2012. Loqate is touting their Cloud services as “developer source for anything location”. It is also a great opportunity for further innovation since the Cloud can take software vendors in some very interesting directions.

About the author: Julie Hunt is a software industry strategist and analyst, providing market and competitive insights. Her 25+ years as a software professional range from the very technical side to customer-centric work in solutions consulting, sales and marketing.  Julie shares her takes on the software industry via her blog Highly Competitive and on Twitter at @juliebhunt   For more information, please visit Julie Hunt Consulting – Strategic Product & Market Intelligence Services. 

The event is sponsored by Trillium Software. Here are the invitation details:

Is your data governance program delivering?

Having a center of excellence to govern and manage your corporate data is no easy task. Yet, a solid data governance program is critical to making your data work for your organization.

In Part 4 of our Data Governance Series: Impact You Can See, you have the chance to hear from a panel of experts who explain how to make your data governance efforts help you achieve your organizations goals by aligning data to your business.

Have a question for our experts? We’d like to hear from you. Submit your question when you register and get the chance to have one of our experts answer it!

The featured speakers are:

• Dan Power, President, Hub Solution Designs
• Jon Asprey, VP of Strategic Consulting , Trillium Software
• Lovan Chetty, Senior Manager (Product Management), Kalido
• Patrick Beatty, Director of Information Management, PwC

Please click here to register.  It should be a very interesting session!

If it were so, I could redefine an entire industry with this article. The gray area between DG and MDM is real and (artificially) exists due to a lack of definition, maturity, or understanding within an organization. Considering that methodologies for MDM and DG have many variances, it would be a challenge to hit on every possible permutation of DG and MDM to define the dividing lines. Doing so would make for a long and painful read and probably be published under a self-help genre for curing insomnia. Instead, let’s generalize on the goals of each and try to find that utopian business model where there is complete harmony.

To do so, I have broken the discussion into three topics: DG, MDM, and that gray matter in between.

Governance

Data Governance organizations are business entities that define and manage the most vital corporate asset, business information. Governance organizations may vary in participation and influence, but they share common goals of corporate data policy definition, policy enforcement, and communication. DG initiatives arise from self-awareness amongst the business leadership that they create and own information and that IT serves as its librarian. Throughout the business are pockets of information, some self-contained within a single business process and some shared across many.

The self-contained “departmental” information can be manipulated, manufactured, and retired with little concern over consequences to external business processes and are of lesser concern to Governance organizations. But when information created by one business process is integral to other business processes, it becomes apparent that a lack of control introduces organizational risk. DG strives to define the structure within the organization to manage the complete information lifecycle of information deemed to be of business importance in order to mitigate risk.

The “best” or “most effective” methods to accomplish successful Data Governance can be the subject of numerous heated debates. I submit that such debates detract from the true mission of identifying what information is important, how to manage it, how to communicate about it, and most importantly, how to measure the effectiveness of your Governance efforts. If the business already realizes a need for Governance, half the effort is done. As long as there is a desire to institute and improve a process, most any dialog is a step in the right direction.

One aspect of Governance that is rarely in dispute is the identification of data owners and data stewards. Data Owners are responsible for the accuracy and completeness of the information and Data Stewards are entrusted to maintain this accuracy.  Also common is the Governance Council which defines the standards and processes to be followed by the Owners, Stewards, and Librarians. These standards and processes are company assets that become the ‘rules of law’ for all things data.  Like rules that govern acceptable behavior in our society, these rules are in place for the good of the business.

MDM

MDM is an information-centric business process to consolidate and manage specific enterprise data that just happens to use technology to assemble, merge, and distribute the data in question.  MDM arose from a need to ensure consistency of strategic shared information to improve data quality, accessibility, and security.

MDM is unique in that it is limited to specific shared information that is not transactional in nature such as: common reference codes, persons, products, or locations.  Value realized from an MDM solution occurs when information is made consistent across the organization, duplicate records are identified and resolved, and the quality of the information is markedly improved.

Achieving data consistency and quality generally requires a thorough understanding of the information at hand, how and where it is created or modified, and what roles and rules are needed to manage its data life cycle.

Methods for MDM, like DG, vary by business and business need.  Long before any MDM solution can be implemented, extensive process and information re-engineering must be planned for. Organizations that do not integrate information across departments effectively have a much harder time getting consensus during this planning process.  Despite the MDM data subject, methods, or tools used, a common practice of the planning process is to identify those responsible for the data in question and those responsible for its daily management (similar to the data owners and stewards above). For the select information within its domain, MDM should consider management from data inception through retirement and all uses between.  Roles of an MDM project include Business Analysts, Data Architects, Data Owners, Data Stewards, data providers, and data consumers.

Gray Matter

Unless my hints were not blunt enough or I’ve put you to sleep already, it should be apparent that there is significant overlap in the purpose, roles, and assets between Governance and MDM. Both processes define data elements and rules around their creation, management, and retirement.  They also both identify owners and stewards of information and place a structure around the process for ensuring data quality, security, and interaction.  So it seems simple that these overlapping roles would be one and the same, right?  Right?

In a utopian business world, the DG organization would be in place before an MDM initiative begins.  Such a DG organization would be structured with the foresight to handle an MDM initiative. In fact, in Utopia, the DG organization would be the driving force for identifying the business need and performing the cost-benefit analysis to justify such an MDM project.

Without tight coupling between MDM and DG, each initiative will see voids in their processes and fill them in order to be successful in their own right.  If DG has not instituted data standards prior to the MDM envisioning stage (or they are not followed), MDM may limit itself to what is needed to satisfy the current phase or one system. For example, “MDM in a vacuum” may have no reason to validate the business definition, domain, or business name of an attribute or list of values does not conflict with an already-established business data element.  A source system may use NULLs to indicate yes or no conditions or have other non-documented defaults that flow into the Best Version of Truth.

Without a global view of how Yes/No indicators should be handled, an MDM project could proliferate ambiguous data to all its consumers.

Another area of consideration is the logging and reporting of data errors and exceptions. In Utopia, I’m told, it is a law that each data element is assigned a data owner, a data steward, a domain of allowed values, restrictions, and a distinct definition. When data is introduced that break these laws, the violation is recorded and the owner or stewards are notified to rectify the situation. A clearly defined policy to automatically identify and report such violations along with a policy to address these issues in a timely manner ideally springs from a strong DG presence rather than an MDM afterthought.

It is expected that DG will evolve to handle new technologies regardless of whether the technology is new to the organization.  In the case of MDM, a DG organization needs to be able to address MDM concepts like trust and survivorship as well as create and expand policies around data dictionaries and canonical modeling. With tight coupling, an MDM project will look heavily to a DG organization for guidance and resources, and MDM will become another data standardization model to demonstrate the value of DG.

Summary

MDM should be considered an extension of DG.  Without proper controls and standardization of data, the worst case for an MDM project is that is becomes a waste of budget. The best case under the same lack of vision is that the project becomes a waste of potential.  Strong DG methods are undeniably needed when defining and standardizing information within an MDM solution. Without an Enterprise-wide focus on DG, an MDM solution will eventually arrive at a solution that meets the myopic needs of its immediate source/target systems, but little else. When an MDM expansion opportunity arises, the original lack of global vision will result in either a re-evaluation of the entire MDM solution or a limiting of the new audience to the initial design goals.

When considering a new or expanded MDM initiative, the first step should focus on your DG program. DG Stewards and Sponsors are the driving force for MDM justification and definition and are the true customer for MDM. Defined global controls should be finalized and introduced early into the process. Only then will you be considered a citizen of Information Utopia.

Rob DuMoulin is an information architect with more than 26 years of IT experience, specializing in master data management, database administration and design, and business intelligence.

“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.

Maturity models

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.

In the May 30th, 2011 edition of Hub Designs Magazine, you may recall the article The System of Record in MDM by Dalton Cervo (who is also the co-author of our new book Master Data Management in Practice: Achieving True Customer MDM).

In the article, Dalton aptly pointed out the underlying importance and challenges associated with defining a system of record (SOR) approach needed to enable a single version of the truth in a master data hub environment.

Expanding from that SOR aspect, MDM as a whole is an ongoing set of processes and disciplines aimed at achieving and maintaining a single version of the truth within one or more master data domains. Companies will typically begin their MDM focus in one master data domain area and expand to more domains with implementation of a multi-domain program model.

In some cases there may be a multi-domain plan from the start, but usually a single domain like Customer or Product will still be the starting point and set the program tone for subsequent domains. When taking this multi-domain leap, it is critical to determine what aspects of MDM planning and execution can be repeatable and scalable across the domains, as well as what are the domain specific elements. With that in mind, here are some perspectives and questions that are important to consider when pursing a multi-domain model.

Defining domains in a multi-domain model

There are a number of commonly identified MDM domains that are often referenced in MDM literature and business case examples such as Customer, Product, Locations, Materials, Employee, Supplier, and a few others that represent master data areas common to most business practices.

Depending on the business model, industry orientation, and application platforms involved, the actual master domains or domain names that a company defines may deviate somewhat from those common domain types. In fact, it would not be unusual in a multi-domain implementation to see a mix of domain types where the leading domains are some of the common MDM domains, followed by other data domains that may not necessarily fit a true MDM definition — such as a more transactionally oriented data set — but where MDM type disciplines can still be applied to achieve a desired level of improvement, consistency, and value with that data.

In such cases, this may appear to be an unconventional approach, but in practice it is reasonable to expect that regardless of the original intent and context, good data management practices and disciplines such as MDM will usually find their way into more general usage over time. A multi-domain model can often become a vehicle where good MDM practices become more generally applied across a company’s data sets. This is actually goodness, so keep in mind that the multi-domain makeup does not always have to be limited to just the master data context.

Prioritizing in a multi-domain model

As is often the case, starting an MDM initiative with a focus on the Customer or Product domain certainly makes sense since the viability and sustainability of most companies rests on customer and product dynamics. Most all sales, marketing, financial, service, and analytical functions in a company are tied to these customer and product dynamics, so this can be a natural starting point for MDM before venturing further.

Once the most critical domains area addressed, it will usually be easier for other data domain programs to get started and aligned within the overall MDM plan. However, there can be many strategic, operational, and technical reasons that can influence domain implementation order.

The MDM business case and investment decisions should be driving the overall MDM roadmap based on priorities that are typically associated with risk mitigation, revenue growth, cost reduction, or business efficiency. The MDM priorities are also going to be influenced by things like executive sponsorship, available resources, business process impacts, new technology, BI needs, and budget forecasts.

When planning a multi-domain program, sufficient time is needed to work out the right implementation approach, examine business impacts, determine critical path dependencies, and to define the ongoing program management model. Not fully addressing these items will likely lead to various program impacts and priority adjustments.

It is the business functions and transactional areas who are the primary creators and consumers of the master data, and since most transactional areas will interact with master data from multiple domains, the domain implementation plan and order can have significant impact on business operations. So be sure to plan and prioritize wisely.

Distinguishing the Program Management Office role from the data domain role

Implementing MDM across multiple domains naturally creates the need to examine how to best coordinate and prioritize multi-domain activity and focus, particularly in regards to technology needs, quality improvement priorities, and demand for budget and IT resources.

A multi-domain MDM plan needs to start by creating a distinct enterprise level Program Management Office (PMO) charter and core team to establish the program foundation needed to move forward.  In some cases, this charter may be assigned to an enterprise data governance group. However established, this is the program office that will need to provide the cross-domain program leadership, policies, standards, services, and core resources to help facilitate and support the multi-domain model. Each domain should still have its own domain specific program scope, responsibilities, and resources, but this should be in alignment with the multi-domain model and policies that the PMO puts forth.

Depending on an organization’s model and approach, the role and responsibility mix between the PMO and domain charters can vary, but generally there should be a clear separation of duties conducive to a collaborative and supportive relationship. Because many aspects of quality management, governance, and stewardship focus are unique within each domain, this should not be impeded by excessive PMO control.

If the PMO charter is too broad, overly controlling, and attempts to create too much of a homogeneous multi-domain model, it can start overshooting its value if it takes away authority and empowerment from the domain specific teams.

A multi-domain MDM program should not be a cookie-cutter process or a follow the bouncing ball type of affair. Rather, it is very much the orchestration of unique programs that have common threads and are on a common enterprise MDM mission but with different domain specific objectives and priorities. A well-conceived PMO should always be cognizant of how to continually coordinate and enable the various domain programs and avoid over-managing where control and conformance is not necessary, otherwise this can become a path toward a stifling model that is not conducive to overall MDM growth and maturity.

A PMO needs to cultivate an environment where a maturing MDM domain team can lead by example with developing best practices which other domain teams can leverage to accelerate their maturity. The leading domain implementation needs extra attention so that the business foundation it creates for data governance, stewardship, quality management, and technology usage, can create repeatable models to help prime the start up of the other domain implementations. This is critical for driving sustainability across the overall MDM model. Leveraging the knowledge, practices, and experience from a leading MDM practice should be a key strategy in a multi-domain plan.

There are also many IT-oriented services needed in MDM such as metadata management, data analysis, data integration, data cleanup, or development of metrics and reports where competing demand is likely to occur across multiple MDM programs. The PMO needs to ensure that these services are as extensible and scalable as possible in order to manage the demand as economically and efficiently as possible.

Launching too many MDM initiatives side by side and each with common dependencies and demand on IT can quickly lead to overload and bottleneck scenarios, causing deliverables to be delayed which can negatively impact the progress and expected deliverables across all the MDM initiatives.

Also, when planning your multi-domain program be careful not to create too many critical path dependencies on new technology because, as we all painfully know, these implementations will often be subject to delays and functionality issues. There are many business project areas of MDM programs (e.g. data governance, data steward setup, business analysis, process improvement, and many program management tasks) that don’t depend on technology, so be sure these type project areas and tasks are sufficiently identified in the program plan and can still move forward while other technology issues are being addressed.

Additional things to consider

Beyond what I have already covered about planning and implementing a multi-domain model, here are some other important questions and perspectives that should be considered:

• Can your IT models and practices sufficiently adjust to provide more flexibility and collaborative support across business-driven MDM programs?
• How much capacity will business and IT organizations have to support requirements and demands from a multi-domain plan?
• Will new technology actually help enable more MDM efficiency and accelerate ROI?
• Will any anticipated organizational change be a disruptive factor, enough to preclude a multi-domain MDM initiative from succeeding?

Simply stated, when planning and implementing a multi-domain model, expect a lot of variables and do the math. Complete necessary business analysis to fully identify what MDM and data governance oriented needs, benefits, and impacts can be expected; what will apply across the domains; and what will be associated to a specific domain. Gear your PMO office to help successfully facilitate the common and unique elements while also driving the domain programs to stay in scope of the overall enterprise MDM model and objectives.

A multi-domain plan can easily be a 3-5 year journey, but if persistently and successfully pursued, this should result in highly consistent and unified data management practices across the enterprise that can greatly benefit a company’s operational and analytical foundation.

I truly believe that MDM has the ability to drive more operational efficiency through continued application and maturity of its core disciplines in a multi-domain model. And while MDM oriented technology continues to be introduced that can greatly assist multi-domain implementations, fundamentally it is the due diligence done in the MDM planning stages and the ability to implement a flexible MDM program foundation that enables the efficient and cost effective application of the technology.

Mark Allen 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 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.

This large telecom company is getting ready to do an enterprise transformation program called PROTEA, which stands for Process Redesign, Organizational Transformation and Enterprise Architecture.

They recognized early on that master data management would be a critical part of their new enterprise architecture, so they reached out to Hub Designs last fall, when they were starting to put together their new program. We worked closely with them to help craft an engagement that would focus on developing a Strategic Roadmap and Business Case, and after being home from the Gartner MDM Summit for three days, we headed to South Africa to kick off that engagement.

Our main contact, Maurice, met us in the lobby and quickly ushered us through getting security badges and a quick tour of the facilities. Our first scheduled meeting was with Paul, the MDM program’s business sponsor, who would be an important ally. The meeting went very well, and we promised to work on some introductory slides he could use at the kickoff meeting coming up that Monday.

An hour later, we met the entire PROTEA team, including Maurice’s boss, Clark, plus the organizational change management team, led by Carol, the enterprise architect, Brian, a business analyst named Lisa, and project managers Joseph and Stephan. We were struck by the warm, welcoming feeling we got from the team, and the efficient way everyone got down to business, getting ready for the upcoming week’s workshops on MDM, data governance and the “As Is” and “To Be” states that we would be having with the business and IT community.

The next day, we spent time finalizing the presentations for those workshops, and meeting with the business sponsor again. We also started having some one-on-one meetings with people from the business, and we met with the project manager and talked about how we saw future phases of the program shaping up.

Friday was hectic, as we were putting the finishing touches on the presentations for the upcoming workshops. We would be presenting to and meeting with almost 50 people from across business and IT, and doing an “Intro. to MDM” session on Monday, for 3 hours in the morning, and then 3 hours in the afternoon. On Tuesday, we would do two 2 hour “As Is” workshop, and then on Thursday, two workshops on the desired “To Be” state. All told, we did more than 14 hours of workshops in three days.

Friday evening, the team was very gracious in inviting the Hub Designs folks out, along with the rest of the PROTEA team and a few international visitors, plus everyone’s families, to an authentic South African “brai, which involved a lot of great conversation, adult beverages and huge quantities of barbecued meats. It was a great time, and a very good way to get to know everyone on the team in a short time.

During the week, we also had some one-on-one meetings with a few key IT people who were critical to win over to the MDM initiative. They were skeptical at first, in some cases, but it seemed the meetings went well, and we reached a meeting of the minds that the PROTEA initiative, and the MDM component of it, was something they recognized the need for, and that MDM was something that “made sense” to them. So, a few more potential allies in the enterprise were identified.

The Monday “Intro. to MDM” workshops went very well. Lots of good discussion and questions, very interactive, engaged attendees from both business and IT, good evaluation forms, a big relief at the end of the day that it went so well.

Tuesday’s “As Is” sessions went well too, although it was a little harder because of the mixed audience of business and IT people. At one point, we were discussing some technical questions for a few minutes, and of the business chimed in and said that if we didn’t change the subject back to a more business-oriented track, she was going to leave. We immediately saw that she was right; we were losing the audience. So we apologized, explained that we would change back to a more business-oriented theme, and we’d take technical discussions “offline” if they came up in the future.

Wednesday was a national holiday so that South Africans could vote, but Tim Smith and myself came into the office and worked anyway, getting ready for the Thursday session and preparing for a Friday meeting with Africom’s CIO that had just been set up.

Thursday’s “To Be” sessions were very productive, leading to lots of back and forth discussions with the business users and the IT people about what the destination point for PROTEA should look like.

We used the Gartner Seven Building Blocks of MDM: A Framework for Success as a guide, with some additional Hub Designs frameworks added in as well. Basically, we focused on aligning the MDM vision with Africom’s overall business strategy, then developing an MDM strategy that supported that MDM vision, and creating some metrics (while working towards an MDM business case) that the MDM initiative can impact in a positive way.

Finally, we recognized that without a strong emphasis on governance, MDM is just “throwing technology at a problem” and is unlikely to be successful, so we planned for creating a data governance organization and corresponding processes. Only then did we envision the technology and future architecture that will facilitate the organizational transformation, process redesign and enterprise architecture that PROTEA requires.

Realizing that there are significant gaps between the “As Is” state and the “To Be” state, we dug in and spent a long working session on Friday listing those gaps. On Monday, we’ll prioritize the gaps and identify the gap closure strategies needed to remedy or close all of the gaps we identified.

We also had a great meeting with Africom’s CIO on Friday, who was very receptive and impressed me with his grasp of the implications of a business-led data governance organization on the relationship between business and IT at Africom. We spent 30 minutes talking with him and it was one of the best business conversations I’ve ever had with a C-level IT person.

Over the weekend, Tim Smith and I took a break and drove to the Pilanesberg National Park, a game reserve in the North West Province of South Africa. What a beautiful place! We saw zebra, gazelles, giraffes, Cape buffalo, hyenas, impala. Saturday night, we stayed in Sun City, which was an awesome resort about 15 minutes from the game reserve. Sunday morning, we went back and had the most amazing experience. Five or six elephants walked right in front of our car, including one giant one who stopped directly in front of us, eyeballed us for about 5 minutes, sniffing the hood of the car, even touching it with his trunk, trying to decide whether to charge us or not. Eventually though, he decided we were no threat and he wandered off to join the rest of his family.

We’ve got two more days of meetings, as we discuss the importance of data governance with Clark’s boss, meet with another critical senior IT person, have our gap closure strategies working session, and have a debriefing session at the end of the engagement on what we’ve accomplished, and what are the next steps.

We’ll be coming back in July for another two weeks to finalize the Strategic Roadmap and Business Case, and to spend some time socializing them with the business community and IT leadership that we’ve met on this trip. We’ve really enjoyed the first two weeks of this engagement and are looking forward to the next part in July.

Africom has a lot of work ahead of it as it brings PROTEA from the early stages to the execution stage. We’re looking forward to being one of their MDM and data governance partners, as they take on this massive program.

We look at it as an effort comparable to trying to lift a pyramid – you need someone at each corner and many people in between. “Many hands make light work.”

In partnership with the Africom business and IT staff, the SI firm they’ll engage to assist with PROTEA, and a local consulting firm that also specializes in data management and information quality, we think Hub Designs can continue to make a big impact on the MDM and data governance component of the PROTEA initiative.

Our experience, however, is that sticking to the truism of the need for “business & IT alignment” is an oversimplification at best and utterly misleading at worst. The chasm to bridge is often really not between “business” and “IT”.  It is also very much within business and within IT:

• Different business units / processes / functions refuse to see Master Data from the perspective of others: a salesman and a delivery person have different views on customer data; purchasing organization and manufacturing look at material data from very different perspectives;

• Professionals from different IT areas have varying viewpoints on Master Data Management: people with data warehousing and Extract/Transform/Load background do not talk the same language as Data Quality and MDM tool professionals.

The fundamental challenge in Master Data Management and Data Governance lies in the above situations, in real boundary-spanning cooperation between different parts of the organization.

Of course such cooperation is also needed when implementing enterprise systems like ERP as well, but in the case of MDM, an extra twist of difficulty is added. It is not just about making interfaces between processes and the organization work. It is about more profound boundary-spanning. It is about practicing true systems thinking.

Approach

So, what to do? The central tenet of Data Governance and Master Data Management, managing data as a critical asset across the entire organization, often doesn’t happen for the above discussed reasons.  Elegant jumps over the gaps are rarely possible. Turf wars abound, within business and within IT.

The answer is that a serious practitioner should learn from how boundary-spanning leadership is done and reflect them in his or her approach to overcoming Data Governance and MDM challenges. Quoting the Drucker Exchange:

“Our world is more interconnected than ever before, but what sorts of boundaries still keeps an organization divided within, thereby undercutting its chances for success?” the Drucker Exchange

In our next article, we’ll discuss how these boundaries can be recognized and managed in MDM and Data Governance programs.

Kimmo Kontra and Pertti Karhu are co-founders of a Finnish Data Management consulting company, Datpro. Both Kimmo and Pertti can be reached via their company’s web site, http://www.datpro.fi.  Kimmo tweets as @kimmokontra and occasionally blogs about topics that interest him in http://datalifeuniverse.blogspot.com. 

Inspired by Crysta Anderson from Initiate, who put together IBM’s Mastering Data Management blog Top 10 Posts of 2010, I decided to put together a similar “Top Ten Posts of 2010″ for the Hub Designs Blog.

In our holiday greetings article, Thank You To Our Readers, we covered some of the top articles from the beginning of this blog in July 2007, and included some readership statistics, which we won’t bore you with today.

Our reports on MDM vendors like Oracle, IBM Initiate, Informatica (formerly Siperian), Kalido, and Orchestra Networks were very popular in 2010.  And our series on MDM best practices, practicing enterprise architecture within MDM (by Jim Parnitzke) and on data profiling (by Rob DuMoulin) were also big hits.

Without further ado, here’s the Hub Designs Blog “Top 10 for 2010″.

1. Oracle’s MDM Strategy and Roadmap – A look at Oracle’s MDM strategy and roadmap, from the Oracle Applications Users Group (OAUG) COLLABORATE conference in April 2010.
2. Building MDM-Powered Solutions with Initiate Composer – A description of Initiate’s new Composer product, which is a framework for building solutions on top of IBM’s Initiate Master Data Service hub.
3. Master Data Management Best Practice Series, by Dan Power – A ten part series on MDM and data governance best practices, based on my presentation at Oracle OpenWorld 2010.
4. Modeling the MDM Blueprint, by James Parnitzke – A six part series on applying important enterprise architecture concepts to MDM projects.
5. Data Profiling For All The Right Reasons, by Rob DuMoulin – A five part series on data profiling and its role within MDM and data governance initiatives.
6. Siperian Acquired By Informatica – My analysis of Siperian’s acquisition by Informatica, written on the day the news broke.
7. Informatica Analyst Briefing – Hub Designs is regularly briefed by the major MDM vendors; this one by Informatica was about 2 months after the acquisition. A later briefing from October 2010 can be found here.
8. Kalido MDM and AB InBev – I live blogged this at the Gartner MDM Summit during a session by Kalido’s President and CEO Bill Hewitt and Jonathan Starkey, the Director of Business Intelligence at AB InBev North America.
9. Intersection of MDM, CRM and ERP – My article on Why Product Information Management in Information Management magazine sparked a short blog article by Andrew White of Gartner. The “Intersection of MDM, CRM and ERP” article is in response to Andrew’s.
10. Orchestra Networks Enters Gartner Magic Quadrant – We thought it was newsworthy that Orchestra Networks, a specialized MDM vendor, was included in Gartner’s “Magic Quadrant for Master Data Management of Product Data” for the first time. Also, Orchestra Networks sponsored a white paper titled A Real Multidomain MDM Solution or a Wannabe? by Hub Designs that was published in September.

It’s been a busy 2010.  I recently read the 2009 Year in Review from this time last year, and was exhausted just reading it, but this year has been the same – several conferences (Gartner MDM Summit, OAUG COLLABORATE, Oracle OpenWorld, Kalido), webinars (with eLearning Curve, TechTarget and Oracle Applications Users Group) and some exciting things to look forward to and update you on in 2011.

I’d like to to thank my wife and two boys for their unwavering support throughout 2010 – and my heartfelt thanks to the folks on the Hub Designs team - I couldn’t do it without you!

And thank you – as always – for your readership and support.  Happy New Year!

Well, another year has nearly passed, and I’d like to say “thank you” to everyone who has read and supported this blog over the past three and a half years.

Only one thing has made this blog possible: you. Whether you came here to learn about master data management (MDM) and data governance, or to follow the development of the consulting firm Hub Solution Designs, your support is what has kept us writing, with 265 articles to date.

We’ve had some great guest authors over the years, whose work you can see on the Top Series page.  They’ve helped to bring great insights and ideas to the blog; I hope you take the time to check out their work.

Our MDM Best Practice series was very popular this October, with the series as a whole receiving more than 2,100 page views in the past two months. The shorter article on Ten Best Practices for Master Data Management, which led to the ten part series, has received 5,100 views so far.

Five Essential Elements of MDM and CDI remains one of our most popular articles, and Joan Lawson’s MDM and SOA, a Strong Partnership is in the “Top Ten” as well.

A couple of the articles we’ve written about Oracle have proven popular as well: Oracle’s MDM Strategy and Roadmap, and the First Look at Oracle Fusion MDM Hub. Jim Parnitzke’s series on Modeling the Blueprint for MDM proved so popular, we re-ran it this summer, as did Rob DuMoulin’s series on Data Profiling for All The Right Reasons.

Our article on the Hidden Costs of Duplicate Customer Data has received 1,175 total views over the past year, and How Master Data Management is Similar to ERP has been averaging 200-300 views per year for more than three years now. MDM and Enterprise Architecture (also by Joan Lawson) is a good reminder of the central role that MDM plays in the practice of Enterprise Architecture.

I hope you enjoy reading the blog as much as I enjoy writing for you. And I hope your holiday season is filled with family, love and happiness, and that you have a safe, healthy and prosperous New Year!

Gartner Research is predicting 14% growth over 2009 levels for master data management (MDM) software license revenues, to $1.5 billion.

Business drivers for adoption range from delivering revenue, service, agility and risk management improvement, cost reduction and integration simplification. John Radcliffe, a research vice president at Gartner, said ”Today, most organizations juggle multiple sets of business and data applications across corporate, regional and local systems. At the same time, customers are demanding faster and more complex responses from organizations, leading to an inconsistency that hinders the organization’s ability to measure and move within the market. With MDM, CIOs can create a unified view of existing data, leading to greater enterprise agility, simplified integration and, ultimately, improved profitability.”

Some interesting predictions were included in the Bank Systems & Technology article:

• From 2009 through 2014, MDM software markets will grow at a compound annual growth rate of 18%, from $1.3 billion to $2.9 billion.
• Gartner foresees a larger, more unified MDM software market reaching nearly $3 billion by 2014.
• By 2015, 10 percent of packaged MDM implementations will be delivered as software as a service in the public cloud (MDM today is typically implemented on-premises)
• Through 2015, 66 percent of organizations that initiate an MDM program will struggle to demonstrate the business value of MDM.

This is not because MDM can’t show sufficient business value. The Bank Systems & Technology article goes on to say “If IT departments initiate an MDM initiative, they often struggle to get the business on board and to demonstrate the business value of MDM, particularly if there are no business-process-oriented metrics and financial quantifications to define and measure success, Gartner analysts say.” (emphasis added)

At Hub Designs, like many other MDM practitioners, we’ve been saying for quite a while that the business needs to own the MDM initiative.  This isn’t always a popular stance, particularly when the people bringing you into a particular client company are the IT people.  But it’s the truth – if the business doesn’t own it, the business won’t feel ownership.

The article goes on to say “MDM needs to align with the business vision and strategy, and will require executive business sponsorship, strong involvement of business stakeholders and change management.”

“It’s not just an IT project. The business needs to take responsibility and be accountable for master data governance and stewardship,” says Radcliffe.

“Unless organizations take a holistic, business-driven approach to MDM, addressing governance and metrics requirements in particular, they risk having their MDM programs fail,” he says. “Internal politics won’t be brought under control without a governance framework, and without a metrics structure, there will be no way of objectively defining what success looks like and measuring whether or not it has been achieved.”

We couldn’t agree more. In our “Ten Best Practices” series this October, we specifically discussed that topic in Master Data Management Best Practice #10 – Use a Balanced, Holistic Approach, saying “This may be the most important best practice of all: use a balanced, holistic approach – addressing people, process, technology and information. Start with the people, politics and culture, and then move on to the data governance and stewardship processes, then the technology.”

The MDM initiatives that companies are taking on right now aren’t “too big to fail”, but they are too important to fail.

As a long-time MDM evangelist, who is used to describing MDM and data governance in such a way that people get excited about the change it can make for their companies, I think we need the types of economic and technological changes described in Penny Crosman’s article. Too many companies are lurching into the 21st century with the baggage of a late 90′s technology infrastructure holding them back. Faster, better decision-making, increased revenue and reduced costs, easier compliance and risk management, improved business and IT agility – these are things that aren’t going to come easily but they are worth it, and MDM and data governance are a big part of the answer for a lot of companies.

So hats off to Penny Crosman and her article in Bank Systems & Technology, and to John Radcliffe and Andrew White at Gartner Research for all the good work that they do.

The results were not surprising, but I found them very interesting nonetheless. Keep in mind that this was a self-selecting group; that is, people who were interested enough in data governance to have taken the survey. That suggests that the general population would be even less mature.

The biggest finding was that only 10% of organizations have been able to move their data governance programs beyond the first two levels of data governance maturity. That matches well with our experience at Hub Designs – most companies are just getting started with data governance.

Despite the commonly expressed belief that data should be owned by the business, traditional IT organizations are accountable for data in nearly two-thirds (63 percent) of organizations.  At Hub Designs, we believe that the business should be accountable for the data – but sometimes, that’s a “bridge too far”. You’ve got to start where you are, and evolve over time to higher levels of maturity. If the center of gravity right now is in the IT organization, that that’s where you start. But over time, have a strategy for moving data governance into the business.

Nearly half (45 percent) of organizations taking the survey said they have a formal data governance council in place, but only 27 percent have established a data governance council with business representation and formal data stewardship. That tells me that even in places where they’re doing some type of (immature) data governance, there are still lots of opportunities for improvement, by increasing the level of business involvement, stewardship and data quality.

This finding I found stunning: more than half (57 percent) of organizations do not measure the performance of data management activities at all. That leads me to believe that those organizations won’t be doing data management for much longer, because lack of measurement tends to lead to lack of funding, because of a perceived lack of documented results.

Clearly, we have a long way to go in the corporate world in becoming more mature from a data governance perspective. I really liked Kalido’s survey, and you can find Winston Chen, Kalido’s VP of strategy and business development, discussing it on his blog at http://bit.ly/cbckxD.

Speaking of Kalido, Hub Designs is sponsoring their upcoming Virtual User Conference on December 7, 2010. The Kalido Connect virtual conference provides attendees with a cutting-edge platform for networking, exhibition, collaboration and learning. Attendees can watch a presentation in a packed auditorium, network with peers in the Kalido Connect Lounge, or visit fully interactive sponsor booths on the exhibit floor. From group chats to one-on-one discussions, the virtual platform allows for a live conference and exhibition floor with real-time user interaction. To register, just click http://bit.ly/kalido-register.

Kalido Connect offers:

• Real-world examples of Kalido’s business value as told by their customers
• Keynote sessions on BI, MDM and data governance trends and how to keep ahead of the curve
• Technical breakout sessions to maximize your investment in the Kalido Information Engine™ and expand your skill set
• Exhibit hall showcasing complementary products and services from Kalido partners and sponsors
• Opportunities to network with colleagues, industry leaders and executives

Last year, more than 300 people attended the Kalido Connect Virtual User Conference, and Kalido expects to double that this year.

Dan Power: Informatica MDM Tweet Jam like playing “stump Dan” – see if you can perplex, mystify and amaze me!

Dan Power: Actually, just kidding – want to have a good dialogue with everyone – would love to have a good MDM discussion.

Informatica Corp.: Right now! Join the #MDM TweetJam with @dan_power. 9am PT.

Dan Power: OK, the Tweet Jam is officially open!

Jakki Geiger: Dan, what are the most common concerns you hear about MDM?

Dan Power: IT people still seem concerned about how to involve the business and sell it to senior management.

Jakki Geiger: what advice do you give them?

Dan Power: IT seems to know that MDM is needed but sometimes can’t seem to get the business on board, and it can be hard to pitch to the C-Suite.

Dan Power: We advise building a compelling business case – getting outside help if needed – and recruiting internal business champions.

Jakki Geiger: What strategies to get the business on board have you seen work?

Dan Power: I wrote an article about that in a recent Information Management magazine and a blog article on Hub Designs Blog that accompanied it.

Jakki Geiger: We’ve seen IT successfully tie MDM to key strategic imperatives like improving cross-sell and up-sell=getting sales on board.

Ravi Shankar: One thing we have done to help IT is to quantify how much DQ issues can cut costs or increase revenue.

Dan Power: Getting the business on board means STARTING in the business – find out their pain points and recruit them to drive from Day 1.

Jakki Geiger: Others include onboarding channel partners onboard faster, which appeals to sales and channel operations.

Jakki Geiger: A huge driver has been regulatory compliance = appealing to those who gather data across the enterprise and create reports.

Ravi Shankar: I like what Charles Bloodworth of J&J said at Informatica World 2010 – “MDM is not just a project; it’s a discipline – a way of doing bus for us”.

Dan Power: Good points Jakki & Ravi – those are the pain points I’m talking about: increasing revenue / onboarding channel partners faster.

Jakki Geiger: One area I think is really going to take off is improving business processes = improve data to improve the process.

Jakki Geiger: One exec got buy in from exec team with “we need to manage our product supply chain and info supply chain equally efficiently”.

Ravi Shankar: Agreed – bus needs to be involved in MDM. Charles of J&J said bus involvement drove their MDM and data governance success.

Dan Power: That’s right – becomes a way of life – new discipline for the business – to have a golden copy of the data that they can trust.

Jakki Geiger: I agree with u. IT needs to understand what the business pains and strategic imperatives are, then evaluate “can MDM help?”

Dan Power: Product management and supply chain are just as fertile for most companies as customer data – so MDM is just getting started.

Dan Power: I’ve been talking to a lot of companies lately that have already done customer MDM and are now looking at doing product MDM.

Ravi Shankar: Product MDM: I see lot of demand for this from manufacturing companies. Just came from S. Korea – product MDM is hot.

Dan Power: Or even supplier MDM – in order to get global strategic sourcing initiatives off the ground, which can save millions of $.

Ravi Shankar: Customer MDM to product MDM – we’ve seen that with our own early customers – They leveraged the same Informatica platform.

Julie Hunt: How do you see MDM implementations evolving to take advantage of newer tech such as ‘cloud’?

Julie Hunt: And what advantages does the cloud offer to MDM solutions?

Dan Power: Good question, Julie – definitely see a movement towards the cloud – people don’t want to create tomorrow’s “legacy systems”.

Dan Power: So they increasingly are asking their vendors about cloud deployment options, even if they don’t rush to take advantage of them.

Dan Power: They want to know they’re available

Dan Power: To Julie’s Q about cloud, I think eventually we’ll see cloud deployments at lower cost than on-premise (particularly hardware).

Ravi Shankar: Let me outline 2 use cases we’ve seen @ InformaticaCorp.

Ravi Shankar: Use case 1: During peak times like holiday seasons, retailers can burst into cloud for additional capacity.

Ravi Shankar: Use case 2: Mktg mgrs can use self service tools to upload attendee list from event w/o having to bother IT.

Dan Power: The promise of cloud for me, is more flexibility as my business grows and if we have seasonal peaks and valleys of demand.

ocdqblog (Jim Harris): What do you say to companies that expected that from their data warehouse? How is MDM different from conformed dims?

Ravi Shankar: ocdqblog – welcome. Looking forward to a lively MDM discussion.

Dan Power: Good question, Jim. Most companies had unrealistic expectations from data warehouses, which ended up being expensive, read-only,

Dan Power: and updated infrequently. MDM gives them the capability to modify the data, publish to a DW, and manage complex hierarchies.

Dan Power: So to finish answering your question Jim, I think MDM offers more flexibility than the typical DW.

Dan Power: That’s why BI on top of MDM (or more likely, BI on top of a DW that draws data from an MDM) is so popular.

Ravi Shankar: MDM for DW – 90% of Informatica MDM customers use it for analytical use (in addition to operational).

ocdqblog (Jim Harris): Thanks Dan – Follow-up is do you see MDM as compliment or replacement for DW?

Dan Power: Definitely a compliment – fills void in the middle between trx systems and the DW – does things that neither can do to data.

Jakki Geiger: are you seeing this trend? Evolving beyond single customer view= visibility into 360 customer view w/products and channels, etc.

Dan Power: Yes, Jakki – people want more than a single view – they want multiple views on top of the single view.

Ravi Shankar: Siperian customers – We’re having a lively chat on MDM and data governance. Join in!

Ravi Shankar: Dan, what do you tell DW admins that DW provides their single view for enterprise?

Dan Power: I tell DW admins that most people in the enterprise aren’t completely happy with DW – that’s why there’s pain leading to MDM.

Jakki Geiger: Since the driver of MDM is the business, how are we getting master data into the hands of the business?

Dan Power: Good Q, Jakki – getting MDM data back into hands of the business should be built into the project – and the software platform.

Ravi Shankar: Compliance is driven out of DW – you need MDM for accurate compliance reports – Do you agree?

Dan Power: Yes, Ravi – Garbage in, Garbage out – you need quality data from the MDM system to feed into the data warehouse.

Julie Hunt: So we must advocate value of data governance as well as value of MDM with business, senior management?

Dan Power: I tell people to think of their initiative as a data governance project that happens to involve #MDM technology.

Dan Power: Not an #MDM technology project that requires data governance.

Dan Power: And to start the data governance piece about 6 months before the technology piece, if possible.

Julie Hunt: The importance of data quality = another layer to be advocated to the business and to management – show them the impact on outcomes.

Jakki Geiger: MDM is like a Ferrari. If you don’t use DQ with MDM, it’s like putting regular gas in Ferrari=sub optimal performance.

Dan Power: I’ve seen people try to do MDM without data quality – and it’s a disaster, like trying to run a submarine on dry land!

Dan Power: The fact is that #MDM and data quality are linked, just as #MDM and data governance are linked.

Ravi Shankar: Should data quality be integrated within #MDM?

Dan Power: Good question, Ravi – I’ve seen it both ways – a data quality engine integrated with the MDM platform or separate, both can work as long as the data quality tool is robust and the integration is solid, shouldn’t matter.

Dan Power: Most MDM platform vendors are not equally good at developing data quality tools – Informatica is one of the few that is.

Julie Hunt: How much does corporate culture impact success/failure of projects for #MDM, data governance etc.?

Dan Power: Great Q – corporate culture is a huge impact on success because data governance drives MDM and requires a lot of change mgt. So spend a lot of time on org. change in the data governance side of the #MDM initiative in order to be successful.

Ravi Shankar: Heard a customer say – “Don’t overdo data governance – do just what’s necessary” Do you agree?

Dan Power: I’d agree not to go overboard on data governance – balanced approach that’s right for your co. just enough to get the job done. Too much data governance can be worse than not enough – can be bureaucratic – the “data governance police”.

Ravi Shankar: Data governance applies to all data, but I hear that in MDM context a lot. Do you hear “master data governance” for MDM?

Jakki Geiger: Some argue shouldn’t call it data governance because the -ve connotation of “governance” thoughts?

Dan Power: I actually like that phrase – master data governance – makes it more clear and precise what we’re talking about

Dan Power: Because otherwise, data governance organization can get drawn into all kinds of weird things not related to master data

Dan Power: We need to recognized that data governance is (a) political, (b) controversial, (c) going to have an enforcement side.

Ravi Shankar: Now, do orgs do data governance first before implementing MDM or after they select an MDM product?

Dan Power: So in some ways, I actually like the term “data government” better – makes it more explicit what we’re talking about.

Dan Power: And it reminds people that we’re talking about governing the enterprise’s core master data – just like we govern other key assets.

Jakki Geiger: I think the challenge is that we’re still in the process of understanding that data is a strategic asset.

Dan Power: It’s ideal if they can start data governance before even selecting a product – so that the data governance org. can help w/ the selection process.

Ravi Shankar: Dan wrote an excellent whitepaper – “When Data Governance Turns Bureaucratic” – you can download it from http://bit.ly/ck2Gw8.

Dan Power: Truly competitive 21st century companies not only understand that data is a strategic asset, it’s how they run their business.

Dan Power: Forward looking businesses like Google, Amazon, Century 21, eBay, etc. realize that the data IS their business!

Jakki Geiger: “Data as strategic asset” is a fairly new concept. Visionaries recognize need 4 scale and intelligence=harnessing & analyzing data.

Dan Power: That was a fun white paper to write – looking forward to doing another one with the great folks at Informatica again soon!

Jakki Geiger: What I liked about Dan’s WP was the discussion around stopping the problem of data quality at the source.

Seth Grimes: Is data governance also (d) useful on balance and (e) capable of delivering ROI?

Dan Power: Yes, of course – or people wouldn’t be doing it. You can’t bring together massive amounts of data in an MDM hub and not have some type of governance framework in place. And if there was no ROI, it wouldn’t be happening.

Dan Power: I’m pretty familiar with Oracle’s data governance program, and for a huge company, it’s not real expensive.

Ravi Shankar: Welcome to #INFATJ – good data governance question.

Ravi Shankar: Successful Informatica MDM customers like J&J, Merrill, and numerous others have had strong global data governance orgs.

Ravi Shankar: Data is a key asset that many firms make a lot of money out of it – Bloomberg for e.g.

Ray Wang: RT @Ravi_Shankar_: Data is a key asset that many firms make a lot of money out of it – Bloomberg for e.g.

Dan Power: Good example with Bloomberg – welcome Ray!

Ravi Shankar: @rwang0 thx for the RT

Jakki Geiger: Can you create a career out of MDM? Many of our customers have extended MDM to address more and more issues in their orgs.

Dan Power: Good Q, Jakki – u can create a career out of it, I have for the last 6 years, but you’ve got to really have this in your blood

Ravi Shankar: Within Informatica customers, we’ve seen careers of several people take off b/c of successful #MDM data governance.

Julie Hunt: Thanks for great tweet jam!

Jakki Geiger: Thank you for participating! Looking forward to next time. Good luck to you all!

Dan Power: Thanks for joining us today – hope you enjoyed it! Check out the Hub Designs Blog at http://blog.hubdesigns.com.

Ravi Shankar: Thx for your insightful discussion and advice on #MDM data governance. Hope you all enjoyed it. Until next time!

Dan Power: This is Dan Power, signing off – have a great day everyone!

MAG is a not-for-profit community, founded by Pierre Bonnet, of users, software vendors, consultants and systems integrators who jointly invest their time and intellectual property in the development of a common best practice and procedure approach for the successful and sustainable implementation of Master Data Management projects.  Pierre is also author of the excellent book “Enterprise Data Governance“.

Hub Designs believes in the community driven approach that the MDM Alliance Group is pursuing, and we’ve been following their progress for quite a while. Their web site, www.mdmalliancegroup.com, has a lot of good information and downloadable assets on modeling procedures, prebuilt data models, webinar replays, and more.

Hub Designs sponsors The MDM Community, but so far that has been more of a forum for people to ask one another questions, to write blog articles, to discuss topics and post upcoming events. Perhaps at some point, The MDM Community will become a way for MDM practitioners to share digital assets with one another. But in the meantime, the MDM Alliance Group is doing great work, and Hub Designs is proud to be a member of it.

Also, a section of our white paper which was released on Sept. 14th, 2010 has been published on the MDM Alliance Group web site. This section deals with the importance of a model-driven approach and proactive data governance to delivering multidomain MDM. You can read that section of the white paper here.  You can also download the entire white paper.

Contact Hub Designs for advice on your MDM or data governance initiative.

A shorter, more targeted project (vs. the “ultimate” whiz-bang project with all the technology bells and whistles) pays off better in two important ways:

1. Generally, the costs are lower, because you’re incurring them for a shorter time. That’s obviously not always strictly true (some crash projects can end up being very expensive) but a 6-9 month project usually tends to be less expensive than a 12-24 month project.
2. You’re delivering the expected benefits that much sooner. So whatever value the business is going to gain from your MDM initiative, it will get that value roughly twice as fast if you can go with the targeted 6-9 month project instead of the 12-24 month “mega project”.

If you think back to our recent article on MDM Best Practice #1 – Start with the Need, Pain or Problem (Not “The Solution”), what the business really wants is for their problem to be solved. They don’t want the most elegant solution with the latest ‘whiz bang’ technology.

They’d like to be able to recognize their customer at all touch points; to be able to add new customers easily without accidentally creating a lot of duplicates; to be able to manage customer creditworthiness and risk in an efficient manner; to roll up sales by the customers’ corporate hierarchy; to be able to efficiently identify the untapped prospects in a corporate family, geography or vertical market; to be able to tie all interactions with a customer back to a single view of that customer; and so on.

Not a lot to ask, they’d probably tell you. They’ll probably ask, why can’t we do that now? After all the investments in all the ERP and CRM systems, in all the data warehouses, data marts and business intelligence solutions, we come along with MDM platforms and (gulp) data governance.

We tell the business users that with MDM, on the one hand, we can help them with their burning problems that never seem to get solved any other way. But on the other hand, it’s going to take their direct involvement in a way they’ve probably never had to do before: data governance.

So it’s matter of “to whom much is given, much is expected”. The business will have a new capability that will solve some important business problems, but the business owners and users will have to step up in a way they may not have had to before, by taking ownership of the data, setting policies around data quality, accuracy, completeness, timeliness and consistency, and then agreeing to enforcement of those policies.

Data government is primarily a political endeavor, and as a result, MDM projects have an explicitly political side to them. Be prepared for that, and remember, faster is better.

Contact Hub Designs for advice on your MDM or data governance initiative.

Start with the people, politics and culture, and then move on to the data governance and stewardship processes, then the technology.

The recent Gartner “Magic Quadrant for MDM of Customer Data” by John Radcliffe had a great statement: “To succeed, you should put together a balanced MDM program that creates a shared vision and strategy, addresses governance and organizational issues, leverages the appropriate technology and architecture, and creates the necessary processes and metrics.”

Another illustration of the need to balance the technology with the people and process is a quote by the inventor and entrepreneur, Dean Kamen: “The technology is the easy part. Understanding what drives people – individuals, societies, what makes cultures clash – all of those questions are way, way harder to answer than how to solve any particular technical problem.”

This Best Practices series is based on a talk that I’ve given at the Oracle Applications Users Group COLLABORATE and Oracle OpenWorld conferences a few times. The talk has evolved each time I’ve given it, but one consistent theme has been “being an MDM evangelist”. I believe in the nature of master data management and data governance to fundamentally change the IT architectures, business processes and organizational cultures (how we think of the core data that we use to run our businesses). And I think corporate America is overdue for these changes.

We’re all consumers who’ve had frustrating experiences with companies trying to do simple things like changing our addresses, stop receiving extra copies of catalogs, fixing errors on credit reports, etc. And we’ve all had the opposite experience, when a quick phone call or self service Web portal took care of everything. What a difference in the customer service experience!

And in the business-to-business world, there are a lot of companies out there that would like to make decisions more quickly, based on reliable data, that would like to reduce their supply chain spend, consolidate their enterprise applications, increase their revenue by up-selling customers, get paid more quickly by making sure invoices go to the right address every time, manage credit risk for new customers, understand customers’ corporate hierarchies, cut their new product introduction life cycle in half, and so on.

These are the types of innovations that our companies desperately need to be competitive in the next decade. The economy is improving – but slowly. As an MDM evangelist, what improvements and innovations can you bring to your company? And can you use the balanced, holistic approach to make sure that the shiny, new technology doesn’t outweigh the people, process and information sides of the picture?

You’ll succeed if you recruit the right executive sponsors; invest in creating a data governance team; design your data governance processes, and communicate how the MDM initiative is helping the company to achieve its strategic objectives. And above all, be persistent. Don’t take no for an answer. The company didn’t get into its current situation overnight, and fixing it won’t happen overnight either.

Please let us know – in the comments here or in the forums on the MDM Community – whether you’ve taken on the role of MDM evangelist in your organization, and if you need any help with it, please let us know.

This is very true in master data management (MDM) – where you’ll inevitably come under pressure to oversimplify. It’s not uncommon to have 20-30 source systems (or more) that have to be integrated with the MDM hub. And tackling other initiatives in the enterprise at the same time (like service-oriented architecture or major ERP or CRM upgrades) can increase the pressure. MDM can help with those other initiatives but doing several things at once may increase the overall degree of difficulty.

Remember, if you oversimplify or underestimate, you’ll be under pressure to cut functionality later. Satisfying important requirements will be postponed to later phases, and the business will be disappointed.

So watch out for the temptation to oversimplify. I had a client once who was setting up a customer hub with about five very complex mainframe-based source systems. They were oversimplifying by making the integration from the source systems to the hub one-way only. So new customer records would flow to the hub, but any updates or data quality improvements made in the hub would not flow back to the source systems.

I asked them what the plan was for those updates, and their answer was “manual integration” (which, of course, is no integration at all – just data stewards manually entering the changes a second time back into the source systems). We all know how that turns out – a great opportunity to synchronize updates and data quality improvements from the hub back to the source systems goes untapped.

Another thing I’ve noticed is that data governance can be disruptive to the business unless the business itself is driving the data governance program and it has been well-planned. Then, any disruption seems to be overlooked, much as you’d be willing to overlook a bit of mess from a home renovation when you were living in the house, as long as you got your dream house at the end of the process. But if someone else (IT, for example) tries to impose governance on the business, that’s a different story. Then, any disruption tends to be bitterly resented, since it’s being imposed from the outside.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of this tendency to underestimate the complexity of MDM projects. And I mean it this time – let’s have your comments and “war stories”!

The next article in the series is: MDM Best Practice #10 – Use a Balanced, Holistic Approach

MDM Best Practice #8 – Resist the Urge to Customize

As the various MDM hubs mature, it’s getting easier to resist the temptation to customize. When I first started working with Customer Data Integration (CDI) hubs in 2004, they were a little “rough around the edges”, and sometimes customization was unavoidable.

But we’re six years further into this now, and the major vendors’ platforms are light years ahead of where they were in 2004. At this point, working with the vendor to improve their product in future releases is a better strategy than customization.

And most products allow you to modify the underlying data model – and the various flavors of the user interface – without touching the source code. This is a big improvement, because most of the times, the changes needed by the business are relatively minor – a few new fields here and there, some new reports of course.

One important thing to include in your evaluation of vendors’ platforms is how easy it is to “settle into” the platform – to make those minor changes and to adapt the platform to the way your organization does business. If the platform seems like it would difficult to adapt in this way, consider that a warning sign.

If you do have to customize, do it carefully; make sure your changes will survive an upgrade gracefully and are well documented.

One of the biggest risks is getting “rev locked”. The MDM vendors are still revving their products once or twice a year, so you don’t want to get stuck on an older version. I had one client that was told by their vendor that their technical problems were fixed in the latest release. Unfortunately, they were told by their internal team that the earliest they’d be able to upgrade to that release would be in about 18 months!

One way to avoid this is to build what I call “upgrade competency” into your project and your team during your initial implementation – so you already have one upgrade under your belt during your implementation life cycle. That way, the upgrade process isn’t quite so daunting.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization is dealing with the issue of customizing your MDM platform.

The next article in the series is: MDM Best Practice #9 – Don’t Underestimate the Complexity

There’s not much point in doing master data management if you’re not going to govern the data.

I remember attending an MDM Summit conference a few years ago, and hearing a pharmaceutical company admitting that they had spent 6 months implementing their MDM technology before they realized that they needed to have a data governance component – an organization with the accompanying processes to manage the quality and accuracy of the company’s critical master data. They essentially had to start their project over again after putting that data governance program in place.

The ironic part was that their system integrator partner ended up sponsoring the Data Governance track at the next conference.

Make sure you convince management of the need for a data governance team as part of your MDM implementation, because trying to do master data management without data governance is like trying to fly a plane with only one wing.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization is handing the intertwined nature of MDM and data governance.

The next article in the series is: MDM Best Practice #8 – Resist the Urge to Customize

Today, we’re going to resume our series on Master Data Management Best Practices. Here are the earlier articles in the series:

1. Start with the Need, Pain or Problem (Not “The Solution”)
2. Active, Involved Executive Sponsorship
3. Emphasize the Organizational Change Management Aspects
4. The Business Has To Own MDM and Data Governance
5. Use Your Best Project Managers and People

MDM Best Practice #6 is to think of MDM and data governance as long term programs, not a short term projects.

Start by understanding and describing your current state – where you’re starting from. Then define your “to be” or future state, and analyze the gaps between the current and future states, and how to close them.

Work with the business owners to break the project to close those gaps up into a series of discrete, manageable phases, much as a software company will have a series of releases of functionality in their successive versions of their software over a period of years.

Spend some quality time planning – the time you invest will be repaid many times over. I recommend spending up to 15% – 25% of the total initiative in planning. Don’t forget, you’ll be breaking down silos and coordinating across multiple lines of business, functional areas, channels, geographies, and so on – and sometimes, these areas you’ll be coordinating won’t like one another very much. So you’ll want to allow for plenty of time to plan what will probably end up being a complex, multi-year effort involving a balanced initiative composed of both data governance organization and process and MDM technology implementation.

The other thing to keep in mind is that MDM is never truly “over” – you may reach a plateau or “steady state”, but there will always be master data coming into the company that will have to be cleansed, matched, merged, synchronized, published, analyzed and utilized. And there will always be more you can do – higher levels on the MDM maturity model scale that you can help your organization achieve.

So plan for an MDM “way of life” that continues on, much like Finance or Sales continue on, not a project that “goes live” and then is over.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization deals with the long term nature of MDM and data governance.

The next article in the series is: MDM Best Practice #7 – Create a Data Governance Organization and Processes

Make sure you can’t be derailed by opponents pointing to avoidable project management or organizational issues. You cannot afford to have this type of project fail, so focus on controlling scope, getting the requirements right, managing risks, and communicating effectively and often.

I’ve seen situations where clients have had simultaneous projects going on: MDM, data governance, CRM and ERP. Even though the MDM and data governance projects were the most crucial, foundational efforts, upon which both the CRM and ERP projects depended, the MDM and DG projects seemed to suffer from “brain drain” – where the stronger resources were getting reallocated to the ERP project.

This “brain drain” syndrome is a mistake – the technical complexity of MDM, breaking down the organizational silos, the cultural changes and other “soft stuff”, putting data governance processes in place across the enterprise, all of these factors argue for putting your best people on these transformational programs.

It may be “project management 101″ but don’t put your “B” and “C” players on your most important programs.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of prioritizing your MDM and data governance programs and putting your best people on them.

The next article in the series is: MDM Best Practice #6 – A Long Term Program, Not a Short Term Project

One model that I’ve seen work very well is for the business to lead the data governance initiative, with senior management being involved through a Data Governance Council (which makes policy for enterprise data), with Global Process Owners handling day to day activities in their own functional areas such as marketing, sales, channels, customer support, and finance, and with tactical aspects handled by business data stewards and IT stewards, under the direction of the Global Process Owners and the IT Global Solution Owner.

This three level model (Data Governance Council, Global Process Owners, Data / IT Stewardship) allows the business to set direction at the highest level and coordinate across the enterprise, while still letting the process owners manage activities within their own functional areas. It’s important to break down the silos which are so common in most of today’s corporations, because silos breed the “islands of data” problem. Reuniting and reconciling those “islands of data” is one of the major reasons companies are doing master data management initiatives in the first place.

When MDM is driven solely by IT, the business may not understand it or buy in. In some cases, the business may not even realize MDM is there, if it’s buried too deeply in the “infrastructure”.

The hard truth is that MDM’s nature as an ongoing program means that even if the initial project is funded by IT, the business may not pick it up in Year 2 & beyond – unless the business owns it.

I’ve seen many instances of MDM programs whose first iteration (driven solely by IT) failed, until they started over, recruited sponsors in the business, transferred ownership of the program to them, and took a more business-oriented approach to the initiative.

Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for business to own the MDM and data governance initiative.

The next article in the series is: MDM Best Practice #5 – Use Your Best Project Managers and People

Outside perspective can be very helpful here. As I discussed in a recent article, “Org. Change and Data Governance”, organizational change management – as an applied discipline – is used far too rarely on MDM projects. They’re big enough to justify it, and they certainly involve enough corporate politics and cultural change to benefit from a structured approach to organizational change management. My firm, Hub Designs, applies org. change and communications strategy techniques to every project we do.

Most of what I know about organizational change management I learned from my friend, Dr. Burt Reynolds, who is now an Assistant Professor at Southern NH University. We first worked together on an Oracle ERP project at a software company in Massachusetts. One of the reasons that project was successful was the project leadership included a strong org. change component.

In MDM projects, a clear communications strategy that addresses all of the various stakeholders of the initiative, and communicates your messages to them using their preferred methods of communication, over the right time frame, will have a huge impact – particularly if you can tell those stakeholders how MDM and data governance are making a difference and helping the organization realize its strategic goals. Find every occurrence of increased revenue, reduced costs, and easier compliance and risk management, and pass those success stories on to the organization at large.

Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for organizational change management in MDM and data governance initiatives.

The next article in the series is: MDM Best Practice #4 – The Business Has To Own MDM and Data Governance

To champion a change (towards managing master data as a true corporate asset) is going to mean significant cultural disruption. In most companies, that type of change is best driven “top down”.

Don’t try to start until this is in place. Work on your elevator pitch, reach out to senior management and educate them on master data management, and work on recruiting your executive sponsors.

MDM and data governance programs are typically not very successful from the “bottom up”. They may start that way, and even show a few small wins, but you’ve got to get the “C suite” interested and engaged at some point in order to get the budget money and the political “juice” you’ll need.

Don’t forget that data governance is largely a political function. I’ve always liked Jill Dyche’s definition of data governance: “Data governance is the decision-rights and policymaking for corporate data, while data management is the tactical execution of those policies.”

When you see the word “decision rights” and “policymaking” next to the words “corporate data”, you know that you’re dealing with an area that is more political than technological. But we need to embrace that, for that is the reality of data governance (or as my friends at Evaxyx in the UK like to call it, “data government”).

And if you think that anything in the enterprise can succeed that is so strongly political without the explicit and continuing support of senior management, I’ve got a bridge in Brooklyn that I’m dying to sell you.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of the political nature of data governance and the need for active, involved executive sponsorship of MDM projects.

The next article in the series is: MDM Best Practice #3 – Emphasize the Organizational Change Management Aspects

I wrote an earlier article on this in October 2007, and it’s proven to be one of the most popular articles on this blog, with more than 4,500 views to date. I’ve spoken on this topic several times at the Oracle Applications Users Group COLLABORATE conference, and at Oracle OpenWorld in 2009 and 2010.

My thoughts on MDM and data governance best practices have changed a bit over the years. At the recent Oracle OpenWorld conference, I co-presented with a couple of great people from Oracle, so I only had about 30 minutes, which forced me to focus and be more concise.

For those of you who couldn’t get to San Francisco for OpenWorld, I’m going to do a series here on this blog, looking at my recent Oracle OpenWorld presentation one best practice at a time.

MDM Best Practice #1 – Start with the Need, Pain or Problem (Not “The Solution”) – the “build it and they will come” approach really doesn’t work for MDM. I had one client where the IT group built a working customer hub, but couldn’t get the business interested in adopting it, and as a result, couldn’t get the funding to continue project beyond Year 1.

To avoid their mistake, make sure MDM solves some key business problems. Find out what your company’s overall corporate strategy is, and figure out how to tie MDM to delivering on that corporate strategy.

In particular, look at the data-related components of your planned and in-flight projects, then see how a centralized data hub can save money. I had one client where the “data components” of their ten planned and in-flight projects totaled about $10 million, and they calculated that by implementing a customer hub, they could achieve those same business goals for $6 million. After their implementation, which lasted 12 months, their actual costs were only $4 million. So they delivered savings of $6 million vs. the data-related costs embedded in the ten separate projects.

This may sound like an IT-driven initiative, but saving $6 million while still achieving the same business goals was a win-win that made the business team and the IT team look good.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of business-driven rather than IT-driven MDM and data governance initiatives.

The next article in the series is: MDM Best Practice #2 – Active, Involved Executive Sponsorship

Let me start out by saying that Hub Designs is vendor agnostic – we partner with all of the leading MDM vendors, including Oracle, Informatica / Siperian, Initiate Systems / IBM, SAP, D&B / Purisma, and Kalido, and are having partnership discussions with others like Orchestra Networks and Stibo Systems.

But my roots in the Oracle community go back to 1995, and my knowledge investment in Oracle’s CRM, ERP and MDM products is considerable. So I feel very comfortable at OpenWorld, and have about 250 Oracle people in my address book.

So although we are vendor agnostic, it’s only natural that we’ve developed a strong relationship with some partners, and are still working on developing that level of partnership with others. It’s hard to have equally deep partnerships with ten or so different companies.

My schedule prevented me from arriving until Tuesday, and when I did get there, I didn’t feel too well. But I did get to some sessions on Wednesday, and I was particularly impressed by “MDM Customer Panel: Implementation Challenges and Best Practices with the MDM Institute, Credit Suisse, Royal Caribbean Cruise Lines, Cricket Communications, and Wind River Systems”.

The session was a very practical Q&A, with different Oracle customers from different industries talking about their experiences, difficulties, and successes over the past four years or so. Several of them had implemented Oracle’s Customer Hub (formerly Siebel Universal Customer Master or UCM), with Wind River having implemented the Customer Data Hub (CDH) product.

The session also included Aaron Zornes, a prominent thought leader and Chief Research Officer of the MDM Institute. It was great to see him and to chat briefly after the session. If you’re able to, you should definitely register for the upcoming MDM and Data Governance Summit in New York City on October 3-5. I’ve been attending these for several years and always find them helpful in order to stay in touch with the pulse of what’s going on in the MDM and data governance space.

The session that I did with Bill Miller and Vanessa Hsu from Oracle was well attended, despite being in the very last time slot of the conference (Thursday at 3:00 pm). We had 101 people in the room, and even though we went a few minutes past the top of the hour, almost everyone stayed to the end. I talked about the need for change in today’s corporations, and the power of being an MDM evangelist in bringing innovation and change back to your company, as well as about the Top Ten best practices that I’ve observed over the past nine years of working in the fields of Data Governance and Master Data Management, across both the customer and product domains.

Bill Miller talked about how Oracle has applied these concepts to its own MDM needs, and its own six year journey from data quality chaos to finely tuned governance machine. It was great to hear, because I’ve known Bill for almost that entire time, and watched him go through some incredible projects, and grow into an important role as Global Solution Owner for Data Quality Management with Oracle’s IT function. He works closely with the business people (the Global Process Owners) in marketing, sales, finance, customer service, and so on. That virtual team is Oracle’s data governance board, and is responsible for some huge improvements in Oracle’s data quality picture over the last few years. Oracle implemented Oracle Customer Hub internally, and made some great process and cultural changes.

Vanessa Hsu is a Senior Product Strategy Manager at Oracle, and is responsible for a new product called Oracle Data Governance Manager. That product is an extension to Oracle Customer Hub, and provides a centralized administration tool for data stewards, giving easy access to key MDM operations, to increase data steward productivity and highlight enterprise-wide data quality metrics at a glance. It’s an important capability that Oracle will extend to its other hub products over its next release cycle.

The “feel on the street” in the MDM track at Oracle OpenWorld this year was that it was “full speed ahead” at Oracle. Gartner recognizes Oracle as one of the leaders in its “Magic Quadrant” for MDM, and deservedly so. There are a lot of smaller vendors with great technology too, but Oracle has done a lot to advance the state of the MDM art, and it was a pleasure to be in San Francisco this week to see their customers talk about their success. It will be interesting to see what happens over the next few years as Oracle introduces Fusion MDM to the market.

For almost ten years, with a few years off during the “Dot Com” era, I implemented Oracle’s CRM and ERP products. One of the things I came to appreciate during that time was the huge difference that including organizational change management makes between a successful implementation and a “less than successful” one.

That’s why I include emphasizing the organizational change management aspects as one of the “Ten Best Practices in Master Data Management and Data Governance” when I speak at conference like the Oracle Applications Users Group COLLABORATE 10 or Oracle OpenWorld.

That’s because big transformational programs like MDM and data governance are not that different from CRM and ERP. Any time you want the organization to embrace new processes and new technology, and more importantly to modify its DNA (that is, its culture), you’ve got to embrace “org. change”.

I’ve got a friend who is a professor in this stuff at Southern New Hampshire University, with a distinctive name – Dr. Burt Reynolds. I first met him on a 12 month ERP project at a $1 billion software company, where he helped define the org. change strategy. I studied what he did very carefully, and I’ve tried to weave it into every project I’ve done since then.

One of the biggest elements is the communications strategy. First, learn about your audience. How do they like to learn about things? Do they like e-mail newsletters, internal web sites, one-on-one meetings with their supervisors, town hall meetings with company leaders, lunch and learn sessions with project team leadership, small training sessions, etc.

Second, think about your message. Some things lend themselves to certain media better than others. Short, snappy messages are probably better suited for town hall meetings. Technical material is better handled in hands-on training sessions. Anything involving changes to individual positions is best suited for individual meetings with supervisors.

What you’ll wind up with is a grid of messages on the left and media across the top. Then you add in the time element (when to deliver these messages), and you’ll have your internal communications campaign.

Steve mentions in his article the ADKAR model for organizational change developed by Prosci: Awareness, Desire, Knowledge, Ability, and Reinforcement.

What this will produce is a well-coordinated internal communications strategy, that when you deliver it, will result in every stakeholder and business constituent being aware of your data governance program, why it’s necessary, and how it links to the overall business strategy of the company.

As for desire to participate in the change, you want to reach as many people as possible, recruit some to be champions of the program, educate others so they’re at least neutral towards it, and keep the number of active opponents as small as possible.

Your communications plan must include a healthy amount of knowledge transfer, because data governance, although not solely a technology driven activity, includes enough technology that the people actively involved in it need to be completely comfortable with it.

You’ll also be raising the bar for the ability and skill of many of the individuals in the company, as well as redesigning some of the processes for entering, updating and consuming master data. Be prepared for the amount of time this is going to take, as well as the force of the political pushback you’ll encounter. People and organizations have a lot of inertia and tend to resist change at first. That’s why reinforcement is so important, by repeating important messages several times and weaving them into different media.

Steve’s article was great, and brought back to me the importance of introducing organizational change management into MDM and data governance programs. It can literally make the difference between success and failure. Please let us know – here in the comments or on in the forums on the MDM Community – what you think of applying org. change to MDM and data governance.

Image via Wikipedia

I’m really looking forward to speaking at the upcoming Oracle OpenWorld conference. I’ve been attending OpenWorld since 2004, and my talk at it last year was a big hit.  David Butler from Oracle, who manages the MDM track at OpenWorld, said I was their “cleanup hitter” last year and that I “hit a home run with the bases loaded”.

The attendance for the session at the 2009 OpenWorld set a record for its time slot (the very last session in the conference).  This year, I’ve got the same time slot again, so if you’re planning to go to OpenWorld and are interested in Master Data Management, hang out to the very end and drop by the session.  It will be on Thursday, September 23rd, at 3:00 pm Pacific time, in the Moscone West building, Room 3003.

I’ll be co-presenting with my friends Bill Miller and Vanessa Hsu from Oracle.  The topic will be “Best Practices and Advanced Topics in Master Data Management and Data Governance”, and here’s that the Schedule Builder says about our session (Session ID S317887):

Data governance is key for healthy enterprise-wide CRM, ERP, SCM, and BI enterprise processes. Master data management provides a foundation for data governance. Thus, for many companies, it’s not “if” they will implement some form of MDM–it’s “when.” You can’t govern unmanaged data. This session will help you better understand MDM and data governance. It presents some useful MDM and data governance best practices, talks about what works and what doesn’t, covers the importance of a holistic approach, and discusses how to get the political aspects right.

So I’ll present some useful best practices for MDM and data governance, Bill Miller will give an “applied case history” of what Oracle has done internally in its implementations of MDM and data governance, and Vanessa will discuss the Data Governance Manager product that Oracle has recently introduced.

It should be a great session – I’m really looking forward to being part of it!

This free virtual seminar is focused on best practices for maximizing SAP performance. The day long virtual event features expert presentations, live panels and expert networking opportunities to help you make the most of your SAP environment, and will cover the hottest topics in SAP right now – including business intelligence, virtualization, master data management and mobile technologies. You’ll learn tips that you can put into practice immediately and you’ll get unbiased advice for long-term strategy development. At this unique online event, go beyond the hype and get insight into the latest technologies and best practices you can use to improve operational efficiency in SAP environments.

Dan Power’s session will be at 1:30 pm EDT, and will cover topics such as:

• Definitions of master data management, data governance and data quality
• The five essential elements of MDM
• Why companies are doing MDM and what this means to you
• Getting started on an MDM roadmap
• Is your organization ready?
• Creating the MDM business case
• MDM software selection
• Some important best practices

For more information, please visit http://searchsap.techtarget.com/feature/Getting-the-most-out-of-your-SAP-environment,  and to register, please click here.

Education

• Based on our popular “Best Practices in MDM and Data Governance” speaking engagements, presented at Oracle OpenWorld and the Oracle Applications Users Group COLLABORATE conference.
• Our workshops get business & IT professionals up to speed quickly
• You get access to the best MDM experts, and can bring your business people into the process early

Roadmap

• Based on Hub Designs’ MDM framework
• Defines where you are now, where you want to be, and over what time period
• Looks at master data management, data integration, data quality, and data governance over time

Readiness Assessment

• Looks at issues relating to politics & culture
• Performs skills assessment on people who may need training
• Examines process issues, outlining where business processes need improvement or redesign
• Investigates technology issues, detailing where essential components are not present or not able to support your upcoming MDM initiative
• Performs data profiling to discover data quality issues

Business Case

• Captures business requirements
• Identifies stakeholders and select metrics
• Baselines current performance
• Negotiates expected benefits
• Converts to financial results
• Develops total cost of ownership
• Calculates hard-dollar ROI

Software Selection

• Develops selection criteria
• Creates a weighted vendor scoring model
• Includes functionality, technology, viability, costs, services and vision
• Develops demo scripts for vendors to follow and sample data sets to give them
• Manages proof of concept (POC) process
• Assists in evaluating POC performance and scoring vendors

These engagements range in length from one to twelve months, with teams varying from two to ten people, depending on the size of the company, the number of domains of master data  involved, and the complexity of the politics and legacy systems in the enterprise.

If you’re interested in discussing an MDM strategy engagement like this, please contact Hub Designs at http://www.hubdesigns.com/contact_us.html. Or if you have comments on the above approaches, please let us know by commenting here.

Continuing a tradition we started in 2008 with an article called “Lessons on MDM from My Summer Vacation“, I’ll try to sum up some things I learned along the way, and apply them to master data management and data governance where I can.

1. Be Prepared for Storms

On one passage from Red Brook Harbor to Cuttyhunk, we were hit with a nasty thunderstorm that wasn’t forecast to go through until much later in the day.  Winds were clocked at 50 knots (58 miles per hour). We prepared by dousing our sails, getting our foul weather gear on, battening down the hatches, and getting the boys in safe positions down below.  But when the storm hit, the rain on my face felt like needles, visibility dropped to zero, our dinghy flipped over on its towing bridle, and I had to concentrate on avoiding a buoy in the area.

The application to MDM is that, given how political these projects can be, there will be storms.  So be prepared for them.  Have a good crew (project team), work hard at instilling loyalty between the team members, and maintain a united front.  In our case, the storm, though intense, passed quickly, and we were able to get our dinghy right side up and resume our course for Padanaram with no injuries or damage.

2. Don’t Try to Control Too Much

Co-organizing a sailing trip with 15 boats can be a bit like herding cats.  Sailors are very independent by nature at best, and even though we had regular check-ins by radio, some people would skip them completely, and others would forget (including me). Traveling with two young children increased the chaos factor.  We’ve learned to go with it a bit – it’s like riding a wave.  You can’t plan every minute of every day – sometimes you’ve got to be spontaneous, put the plan aside and just see what happens.

In the MDM and data governance world, the business community as a whole, even though they may not be on your project team directly, is going to be directly affected.  They’ll want to have a say in how things are done, and they’ll have good ideas for you.  Don’t shut them down.  Learn to listen, actually consider what they’ve got to say, and be inclusive.  Have town hall meetings where the broader business community gets a chance to tell you about their concerns, where you communicate the project’s progress and milestones, and where you can reach out to them and pull them in to upcoming phases.

3. Accept the Kindness of Others

Previously, we had a 32 foot boat, but at the beginning of June, we took delivery of a 38 foot boat, which we were still getting the hang of. A couple of club members on the cruise took the time to help us get to know the systems on our new boat, and it was great to have experienced friends walking us through what was, to me, new territory. Whether it was the selector switch between water tanks, the fresh water pressure pump, the anchor wash down pump, or various other things, our friends took the time to mentor us on the ins and outs of our new boat. And on the last day of the cruise, our friend Fred remembered that our son Brendan wanted a ride in his skiff, so he came alongside as we were leaving the harbor, picked him up, and gave him the ride of a lifetime.

The application to MDM and data governance is that you should be open to mentoring within and outside the enterprise.  People like sharing their experience and wisdom with others, once you’ve established a strong relationship. If you reach out and develop a network of contacts inside and outside the company, then when the stuff hits the fan, you’ll be able to call on them for help.  And even when you don’t need help, you’ll find a ready group of mentors who’ll take you under their wing, to teach you the finer points of leadership skills, project management tips and tricks, communications and marketing excellence, business process redesign and organizational change management basics — all the things you’ll need to succeed in your MDM and data governance initiative.

4. Stay on Schedule

There were several times during our sailing trip when we were tempted to stay an extra day or leave a day early from one place or another.  We talked it over as a group and decided to stay on schedule.  Many of us had made mooring reservations at marinas with strict cancellation policies, and we would have ended up paying for those moorings even though we didn’t use them.  Not a big deal in and of itself, but we asked ourselves, what’s the worst that could happen if we stuck with the original schedule?  It turned out that it wasn’t that different from what would happen if we went with a changed schedule.

In the MDM and data governance world, as in any technology implementation, there are going to be unforeseen obstacles.  Try to build some cushion into your project plan, so the smallest little delay doesn’t impact your critical path and delay the overall project.  When you get to the point that to stay on schedule means sacrificing functionality or increasing costs (the famous “triple constraint“), the discussions start getting pretty heated. There will be many times when your project will feel like you’re herding cats too, but remember how important it is to stay on schedule. You can’t finish on time if you get behind shortly after you start.

5. Look for Those Special Moments You’ll Always Remember

There were quite a few special moments on this vacation. Shortly after we arrived in Cuttyhunk, both of my boys put on their bathing suits and dove off the boat into the harbor.  They swam fearlessly from Blue Water boat to Blue Water boat, saying hello to their friends, until we had a bunch of kids in the water doing the same thing, including one little girl that had never done that before (and who made her dad very proud).  That night, after going to the beach, we had a lobster bake that I organized for 33 people on the lawn overlooking the harbor.  I will remember the conviviality and friendship of that dinner for a long time.  And there were small moments too: body surfing with my youngest son in Westport, getting airborne in the dinghy, slogging through the passage to Block Island against 25 knot winds, foul currents and 4-6 foot seas (even the hard times can be good memories after you get through them).

For MDM and data governance practitioners, there are many rewards: the satisfaction of bringing in a challenging project on time and on budget, forging relationships with team members that will last a lifetime, learning new things and expanding professional horizons, being recognized by the company as a valuable player capable of big things, mastering MDM and data governance at a time when having those technologies on one’s resume certainly doesn’t hurt one’s career prospects, and so on.  For a good look at what is involved in being a “data champion”, and the rewards involved, read “So You Want to be a Data Champion?” by my friend, Tom Carlock.

To sum it up, if you’re prepared for the inevitable storms that will come your way and don’t try to control things too much, and are open to the kindness of others while remembering the importance of staying on schedule, you’ll certainly be blessed, as I have been, with a wealth of those special moments you’ll always remember. Master data management and data governance can be challenging, but they can be very rewarding as well, both for the organizations which take on the initiatives and for the individuals who make up those teams.

The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.

Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.

First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:

• Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
• Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
• Technical managers as the basis for forming development teams corresponding to the work assignments identified.
• Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
• Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.

Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:

• Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
• Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
• Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
• Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
• Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
• Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.

Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:

• Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
• Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
• New project members, as the first artifact for familiarization with a system’s design.
• New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
• Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.

Blueprint for MDM - Where this fits within a larger program

Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.

The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:

1. Common Information Model
2. The Canonical Model
3. The Operating Model
4. The Reference Architecture

Click to enlarge

I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.

Typically, use of the MDM blueprint may include:

• Identifying all necessary components and services
• Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
• Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
• Program planning and coordination of resources
• Facilitating prioritization of key requirements – technical and business
• Development of Request for Quotation, Request for Information products (make vs. buy)
• Preparing funding estimates (Capital and Operating Expense) and program budget preparation
• Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)

We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.

Summary

I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.

The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.

Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.

Now, it’s time to model and apply the technical infrastructure or patterns we plan on using. The blueprint now moves from being computation and platform independent to one of expressing intent through the use of more concrete platform-specific models.

Reference Architecture

After the initial (CIM, Canonical, and Operating models) work is completed, then, and only then, are we ready to move on to the computation and platform specific models. We know how to do this – for example see Information ServicePatterns, Part 4: Master Data Management architecture patterns.

At this point, we now have enough information to create the reference architecture. One way (there are several) to organize this content is to use the Rozanski and Woods extensions to the classic 4+1 view model introduced by Philippe Kruchten. The views are used to describe the system in the viewpoint of different stakeholders (end-users, developers and project managers). The four views of the model are logical, development, process and physical view. In addition, selected use cases or scenarios are used to demonstrate or show the architecture’s intent. Which is why the model contains 4+1 views (the +1 being the selected scenarios).

Rozanski and Woods extended this idea by introducing a catalog of six core viewpoints for information systems architecture: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints and related perspectives. This is elaborated in detail in their book titled “Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives”.  There is much to learn from their work, I encourage you to visit the book’s web site for more information.

What we are describing here is how MDM leadership within very large-scale organizations can eventually realize the five key “markers” or characteristics in the reference architecture to include:

• Shared services architecture evolving to process hubs;
• Sophisticated hierarchy management;
• High-performance identity management;
• Data governance-ready framework; and
• Registry, persisted or hybrid design options in the selected architecture.

This is an exceptional way to tie the technical models back to the stakeholders needs, as reflected in the viewpoints, perspectives, guidelines, principles, and template models used in the reference architecture. Grady Booch said “… the 4+1 view model has proven to be both necessary and sufficient for most interesting systems”, and there is no doubt that MDM is interesting. Once this work has been accomplished and agreed to as part of a common vision, we have several different options to proceed with. One interesting approach is leveraging this effort into a Service Orientated Modeling Framework introduced by Michael Bell at Methodologies Corporation.

Service-Oriented Modeling

The service-oriented modeling framework (SOMF) is a development life cycle methodology. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle management and modeling. It illustrates the major elements that identify the “what to do” aspects of a service development scheme.

These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—in this case crafting an effective MDM solution.  SOMF provides four major SOA modeling styles that are useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture).

These modeling styles: Circular, Hierarchical, Network, and Star, can assist us with the following modeling aspects:

• Identify service relationships: contextual and technological affiliations
• Establish message routes between consumers and services
• Provide efficient service orchestration and choreography methods
• Create powerful service transaction and behavioral patterns
• Offer valuable service packaging solutions

SOMF Modeling Styles

SOMF offers four major service-oriented modeling styles. Each pattern identifies the various approaches and strategies that one should consider employing when modeling MDM services in a SOA environment.

Circular Modeling Style: enables message exchange in a circular fashion, rather than employing a controller to carry out the distribution of messages. The Circular Style also offers a way to affiliate services.

Hierarchical Modeling Style: offers a relationship pattern between services for the purpose of establishing transactions and message exchange routes between consumers and services. The Hierarchical pattern enforces parent/child associations between services and lends itself to a well known taxonomy.

Network Modeling Style: this pattern establishes “many to many” relationship between services, their peer services, and consumers similar to RDF. The Network pattern accentuates on distributed environments and interoperable computing networks.

Star Modeling Style: the Star pattern advocates arranging services in a star formation, in which the central service passes messages to its extending arms. The Star modeling style is often used in “multi casting” or “publish and subscribe” instances, where “solicitation” or “fire and forget” message styles are involved.

There is much more to this method, so I encourage you to visit the Methodologies Corporation site and download the tools, power point presentations, and articles they’ve shared.

Summary

Based on my experience, we have to get this modeling effort completed to improve the probability we’ll be successful. MDM is really just another set of tools and processes for modeling and managing business knowledge of data in a sustainable way. Take the time to develop a robust blueprint to include the Common Information (semantic, pragmatic and logical modeling), Canonical (business rules and format specifications), and Operating Models to ensure completeness. Use these models to drive a suitable Reference Architecture to guide design choices in the technical implementation.

This is hard, difficult work. Anything worthwhile usually is. Why put the business at risk to solve this important and urgent need without our stakeholders understanding and real enthusiasm for shared success? A key differentiator and the difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. Creating and sharing a common vision through our modeling efforts helps ensure success from inception through adoption by communicating clearly the business and technical intent of each element of the MDM program.

In the last part of the series, I’ll discuss where all this fits into the larger MDM program and how to plan, organize, and complete this work.

This is the most important set of models you will undertake. And sadly, not widely accounted for “in the wild”, meaning rarely seen, much less achieved. This effort describes how the organization will govern, create, maintain, use, and analyze consistent, complete, contextual, and accurate data values for all stakeholders.

There are a couple of ways to do this. One interesting approach I’ve seen is to use the Galbraith Star Model as an organizational design framework. The model is developed within this framework to understand what design policies and guidelines will be needed to align organizational decision making and behavior within the MDM initiative.

The Star model includes the following five categories:

Strategy: Determine direction through goals, objectives, values and mission. It defines the criteria for selecting an organizational structure (for example functional or balanced matrix). The strategy defines the ways of making the best trade-off between alternatives.

Structure: Determines the location of decision making power. Structure policies can be subdivided into:
- specialization: type and number of job specialties;
- shape: the span of control at each level in the hierarchy;
- distribution of power: the level of centralization versus decentralization;
- departmentalization: the basis to form departments (function, product, process, market or geography).

In our case, this will really help when it comes time to designing the entitlement and data steward functions.

Processes: The flow of information and decision processes across the proposed organization’s structure. Processes can be either vertical through planning and budgeting, or horizontal through lateral relationships (matrix).

Reward Systems: Influence the motivation of organization members to align employee goals with the organization’s objectives.

People and Policies: Influence and define employee’s mindsets and skills through recruitment, promotion, rotation, training and development.

Now before your eyes glaze over, I’m only suggesting this be used as a starting point. We’re not originating much of this thought capital, only examining the impact the adoption of MDM will have on the operating model within this framework. And more importantly, identifying how any gaps uncovered will be addressed to ensure this model remains internally consistent. After all, we do want to enable the kind of behavior we expect in order to be effective, right?

A typical design sequence starts with an understanding of the strategy as defined. This in turns drives the organizational structure. Processes are based on the organization’s structure. Structure and Processes define the implementation of reward systems and people policies.

The preferred sequence in this design process is composed in the following order: (a) strategy; (b) structure;  (c) key processes; (d) key people; (e) roles and responsibilities; (f) information systems (supporting and ancillary); (g) performance measures and rewards; (h) training and development; (i) career paths.

The design process can be accomplished using a variety of tools and techniques. I have used IDEF, BPMN or other process management methods and tools (including RASIC charts describing roles and responsibilities, for example). What ever tools you elect to use, they should effectively communicate intent and be used to validate changes with the stakeholders, who must be engaged in this process.

Armed with a clear understanding of how the Star model works we can turn our attention to specific MDM model elements to include:

Master Data Life Cycle Management processes
- Process used to standardize the way the asset (data) is used across an enterprise
- Process to coordinate and manage the lifecycle of master data
- How to understand and model the lifecycle of each business object using state machines (UML)
- Process to externalize business rules locked in proprietary applications (ERP) for use with Business Rules Management Systems (BRMS) (if you’re lucky enough to have one )
- Operating Unit interaction
- Stewardship (Governance Model)
- Version and variant management, permission management, approval processes
- Context (languages, countries, channels, organizations, etc.) and inheritance of reference data values between contexts
- Hierarchy management
- Lineage (historical), auditability, traceability

I know this seems like a lot of work. Ensuring success and widespread adoption of Master Data Management mandates this kind of clear understanding and shared vision among all stakeholders. We do this to communicate how the solution will actually be deployed and used to realize the benefits we expect.

In many respects, this is the business equivalent to the Technical Debt concept Ward Cunningham developed (we’ll address this in the next part on Reference Architecture) to help us think about this problem. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The same concept applies to this effort. The most elegant technical design may be the worst possible fit for the business. The interest due in a case like this is, well, unthinkable.

Take the time to get this right. You will be rewarded with enthusiastic and supportive sponsors who will welcome your efforts to achieve success within an operating model they understand.