Not because we need to jump on the social networking bandwagon to keep MDM interesting and relevant. But because companies like Google (with Google+) and data.com (formerly Jigsaw and now SalesForce.com) have already cemented the relationship between the two.

The evolving conversation regarding MDM and social networking has two perspectives. One angle considers how to use members of a social network in the management of master data. The other addresses how to use MDM for managing data about members of a social network.

The first context for discussing MDM and social networking has been a subject of interest for some time. Crowd-sourcing is the basic social networking mechanism used to accomplish this goal. The “crowd” can be a well-defined group of employees or a coalition of like-minded members of an online service.

The second recently came to the forefront when Google chairman Eric Schmidt proclaimed that the company will only accept “real names” in Google+. According to GigaOM, Schmidt admitted in an interview “Google is taking a hard line on the real-name issue because it sees Google+ as an ‘identity service’.”

That sounds a lot like an MDM policy in the making.

Marrying MDM and Social Networking

The idea of bringing social networking and MDM together has its roots in “community data stewarding,” which some in the MDM space started touting a few years back. The idea is to leverage the collective efforts of individuals within an organization to help manage master data. More recently the notion of community data stewarding expanded to include using “the masses” for MDM.

Online data services like data.com, which is the reincarnation of Jigsaw after it was acquired by SalesForce.com in 2010, is a good example of mass data stewardship.  Jigsaw is probably the first real adaptation of social networking, specifically crowdsourcing, to managing data about people and organizations.

Even though the stated intent of Jigsaw was to share contact names, I can easily argue that Jigsaw is a social MDM application. By tapping the universe of salespeople for information about people and organizations, Jigsaw, now data.com is, in effect, the first commercially successful crowdsourced Master Data as a Service (DaaS).

Master DaaS is different than MDM SaaS, which is the delivery of MDM software capabilities in the cloud. Personally, I believe all the action is (or will be) at the intersection of Master DaaS and MDM SaaS, which is where data.com is likely heading. But that’s a conversation for another time.

One can also show that even LinkedIn is readily re-purposed as a Master DaaS, where individuals manage their own identity. Consider offerings such as “LinkedIn for Salesforce.com.” It’s not much of a leap to see how contact names in SalesForce.com are indirectly managed by the contacts themselves through their LinkedIn profiles.

While understanding how to adapt crowdsourcing dynamics to data stewardship is worthy of further consideration, this article focuses on the second context: how to use MDM to manage data about members of the crowd, i.e. a social network. This is where the conversation gets contentious, as Schmidt unwittingly demonstrates.

At first blush, all the fuss about banning pseudonyms on Google+ seemingly has nothing to do with MDM. But it does. Very much so.

Master Identity Keeper

According to GigaOM, during an interview with Andy Carven, National Public Radio’s digital editor, Google’s Schmidt stated:

“G+ was build (sic) primarily as an identity service, so fundamentally, it depends on people using their real names if they’re going to build future products that leverage that information. If you think about it, the Internet would be better if we had an accurate notion that you were a real person as opposed to a dog, or a fake person, or a spammer or what have you… So if we knew that it was a real person, then we could sort of hold them accountable, we could check them, we could give them things, we could you know bill them, you know we could have credit cards and so forth.”

Fred Wilson at Union Square Ventures further notes, Google “wants to be an identity gatekeeper,” where individual crowd members basically manage their own identities.

Schmidt and Wilson suggest what sounds like the ultimate Master DaaS for person-type parties. But it raises some interesting questions. Does a business need to definitively know the individuals that they interact and transact business with? While this may seem absurd to even ask, apparently we are at that crossroad. And from the dialogue it seems not everyone agrees on the answer.

Is MDM Evil?

To date, a business naturally assumes that a customer cooperates by exposing their identity. After all, how else can you conduct business?

That said, there are many instances of businesses that don’t know the identity of their customer. P&G, for example, cannot readily identify the consumers who purchase, say, Tide®. The “customer” represented in P&G’s business systems are retailers and wholesalers and some of their employees, but not likely the person pouring Tide® into their washing machines.

On the other hand, take a retailer like Target. Recently, they had some challenges with handling online purchases as described in this story on CNN.

“…shoppers who bought the Missoni Target line are posting on social media websites Facebook and Twitter that they won’t shop at Target again because their online orders are being delayed — or worse, canceled — by the retailer.”

Before the internet, Target did not likely know the identity of many “shoppers,” i.e. customers who made their purchases at a store, unless they had a Target credit card or exposed their identities at the cash register. And even if they did have shoppers’ identities, they would not likely have the capability to resolve the relationships among them, which is a major goal for social media sites.

In the past Target’s customers for MDM purposes were suppliers and wholesalers and not “shoppers.” Just like P&G. With online purchases, however, this is no longer the case.

Of course, Target needs to know the identity of the suppliers and wholesalers and those related contact names. The question is this. Will they ever know the identity of the supplier or wholesaler contact, who, when behaving also as a shopper, is bad mouthing Target on some social media site under a pseudonym…or is part of some anti-Target group? Meanwhile, a Target representative may just have had a seemingly pleasant lunch with the person. They’re being blindsided.

Now consider this. The blog GIZMODO states “Google’s horrible new policy on using real names in Google+ effectively means that the service is now a danger to real people.” (As opposed to fake people?) And “…the policy is evil.”

GIZMODO adds:

“You can’t use initials (even if that’s what you go by). You can’t use a pseudonym (even if that’s what you go by). And you can’t use numbers or symbols (even if they are part of your name).

Æ, e.e. cummings, Malcolm X, and T.S. Eliot would all be in violation of Google’s policy. So, too (by my reading) would be Mark Twain, George Eliot and doubly so, R.U. Sirius. I’m pretty sure nobody whose name you actually know in the band U2 can use Google+ or, by extension, Gmail.”

Play Nice

Apparently Google seeks birth certificate-quality names. Is this the same strength of policy making that MDM needs to succeed?

Traditionally, the answer is not necessarily, because any decent MDM technology will have the ability to relate multiple aliases to a person party. But as MDM moves to manage master data about your customers who are also members of business and social networks, not all aliases are willingly shared.

Everyone knows Mark Twain and Samuel Clements is the same person. And even if we did not, someone besides Twain himself would ultimately have to know his real identity. Otherwise how would he collect his royalties?

And here is the blind spot for MDM moving into the social realm. A 360-degree view will be without those structured or unstructured data relationships of a party that may only be revealed under a fantasy name…and not disclosed to you or anyone else.

Selling and marketing may get a whole lot harder as individuals increasingly armor themselves with pseudonyms and fantasy names (or personas). In response, we see the rise of strict policies enforcing identification…or don’t play on my social media site.

Unfortunately, that’s a double edged-sword, and the physics of it all has yet to get worked out. On the one hand, Facebook and Google have a threshold mass where people have to play by the rules or get booted. On the other hand, the resistive power of the masses can influence those policies. Just ask Netflix.

When a Customer Identity Is the Product

Consider Don Norman’s observation about Google+. Normanis the author of The Design of Everyday Things. He says, “Real names, they (Google) say, turn out to be the names on your driver’s license and your passport and your credit cards so that they can track you.”

He goes on to say Google’s “goal is to gather all the knowledge in the world in one place, but really their goal is to gather all of the people in the world and sell them.”

This appears very much like a goal of MDM: to gather all of the people in your business circle in one place so you can ultimately track them. All, of course, with the intent to manage a relationship with them…um sell them something.

I unequivocally say, yes, this is a goal of MDM. But there is a slight twist to the Google+ story.

Norman also submits that “Most people would say (of Google) ‘we’re the users, and the product is advertising. But in fact, the advertisers are the users and you (we) are the product.”

Typically, MDM assumes we are talking about the identities of persons and organizations like customers, suppliers, employees, partners and the like. Norman fundamentally asks, when a person’s identity is a product, do we have a right to enforce them to share that identity as a condition of use…I mean, participation in a service?

Frankly, I am not quite sure what the big deal is. Credit bureaus, like Experian and other companies like Acxiom, have sold our identities as a product for years.

Data Is Not An Asset. A Person’s Identity and Relationships Are.

According to GIZMODO, “Forget social networking, the big goldmine of the future is online identity verification.” Bingo, that’s Master DaaS.

Two questions related to MDM are at play here. (Since we are solely discussing individuals and groups of individuals …and for simplicity, I exclude master data on other entities such as products.)

1. How do you have transactions and interactions and perform analytics without, well, master data? After all, a party’s name is master data. In other words, how do you create an order or an account without header information about the party?

2. Is there an obligation for people who do business with you to correctly identify themselves? I am not sure how else business can occur. Even setting up a Swiss bank account requires identifying the account holder. Although, I cannot say for certain. I’ve never had enough money to hide from anyone!

Speaking of bank accounts, Dave Winer thinks Google “wants to effectively become a bank.” According to Weiner, knowing the relationships among persons is where the value of sites like Facebook and Google+ is. Knowing and managing the relationships among persons happens to be an important function of MDM too. We can think, then, of a MDM hub as a sort of bank of person and organization identities and the relationships among them.

If nothing else, one thing has been settled. Data is not an asset. The true identity…and corresponding relationships of a party are. It’s an asset to a person. It’s an asset to a business. Even if we mean “asset” rhetorically.

In my opinion, Google+ and other social media sites purporting to be identity services should offer an incentive like Jigsaw does. You gain points by sharing the identities of people you know. If anything, Jigsaw is the evil one. It’s a platform for everyone to “rat out” everyone else they know by disclosing their name, employer, work address, phone number and email address.

Identity and Relationship Resolution and Keeping

The concern voiced by Google resonates in MDM because a single representation of customer information and a “single version of truth” are frequently stated desired outcomes. Given the largest percentage of MDM initiatives involves resolving and managing identities and relationships, we need to reconsider what and who is a party to a transaction and interaction.

For starters, we need to rethink the notion of “customer.” It’s becoming an increasingly marginalized, if not obsolete and irrelevant concept. “Customer” seems inadequate for collectively describing the myriad roles played by all the participants in business transactions and interactions.

If abandoning “customer” altogether is too radical, we should limit it to a very narrow meaning. Take a health insurance company for example. They narrowly define a customer as the employer sponsoring a health plan. That’s it.

An employer a.k.a customer is only one of many participants in their business transactions and interactions. Other participants include subscribers, providers, members, administrators and brokers. They collectively refer to these participants as constituents, and any participant may play more than one role. A provider, for example, can also be a subscriber or member, or if the provider is an organization, such as a hospital, the provider is also an employer that sponsors a health plan for its own employees.

Additionally, we need to recognize that the collection of participants forming a crowd, group, organization, circle or whatever we call it is also an entity. Crowds, circles and groups are similar to organizations, except they usually don’t have a legal standing and tend to be virtual. Nevertheless, they are living, breathing entities that matter and require identity and relationship resolution. This is particularly the case if they are participants or potential participants in a transaction, interaction or analysis.

We can no longer easily segregate the persons and organizations we engage in a transaction or interaction into separate entities like customer, supplier, employee, partner, user, shopper, guest, donor or whatnot. It’s time to recognize these concepts and terms for what they are: role designations, not discrete entities.

The entity is the person or group. That’s why some organizations now collectively recognize all of them as a single entity and dub it a “party” or “constituent” or the like. Where the entity can behave in one or more roles as a customer, supplier, employee, partner, shopper or whatever.

Personally, I prefer “participant” to describe the individuals in a group. “Member” or “party” is probably easier on the brain, but “participant” is an action word, even if it doesn’t nicely roll off the tongue. “Constituent” works too, but sounds a little formal.

I also prefer Google+’s “Circles” to simply “group” or to, say, Facebook’s “Smart Lists” when depicting a crowd. After all, people travel in circles, not on lists! A “list” is too linear, even hierarchical sounding. “Circle” is a clean break from the chronic misrepresentation of all relationships as hierarchical. Plus, we can be participants in multiple related or unrelated circles.

“Smart group” might work too, where smart means identifiable. Then, of course, there is always “network.” A network is neither linear nor hierarchical but it’s too clinical sounding. We can always just say persons and organizations. But that’s unimaginative.

Instead of categorizing persons and organizations by their role in transactions and interactions, just designate them as participants in a circle. Some seek to distinguish social networking and business networking, but in the end, we can’t always distinguish interactions as social or business.

The following table depicts the evolving conceptual models for representing participants and circles in a system. While the goal is to move toward a Stage VI model, most organizations will have systems representing participants and circles in transactions and interactions at different stages.

Where Do We Go From Here

Deriving a panoramic view of fragmented customer data for transaction processing, business interactions and analytics involves multiple parties arranged in complex network configurations. But not all these parties traditionally and simply behave as a “customer.”

Business applications must rapidly evolve to a Stage VI model that can support different sets of relationships among persons, organizations and groups and different sets of data relationships for them. A blind spot may still exist where the identity of participants in a combined social and business circle are irreconcilable.

Until business applications can support a Stage VI model, MDM will have an interim function as keeper of participant and circle identities and relationships. However, even with MDM, separate data relationships based on participant role may not be fully supportable until business systems themselves can support complex network configurations.

Once business applications can support a Stage VI model, they still may not be suitable for managing all participant relationships for two reasons. One, if enterprise applications are not optimized for a large, complex arrangement of participant and data relationships, performance could be a significant roadblock. And two, a production transaction system may not be optimal for dedicated data stewards and curators to maintain participant identities and relationships.

For these reasons, the importance of MDM will increase as it becomes the main mechanism for managing current and historical participant and circle identities and relationships with pointers to corresponding data relationships. As cloud computing penetrates enterprises, resolving and keeping participant identities and relationships will increasingly occur as a combination of MDM SaaS and Master DaaS.

Process-centric initiatives are often optimal approaches for the things that companies want to accomplish. Business processes make it possible to directly connect work to business outcomes that lend themselves to various metrics that provide clarity for business performance. On the other hand, data and data-oriented solutions, by themselves, don’t usually map directly to business outcomes, and as such, usually can’t be measured by value contributed to desired outcomes and achievement of key corporate goals.

But — business processes and data are inextricably bound together. Processes create, modify and consume data – one might even say processes live and breathe data. It is through business processes that data can be mapped to business value.

Companies generally have not taken a holistic view of business information, technologies to improve it, or its impacts across end-to-end processes or businesses, instead treating data as information islands within specific system silos.

Kalido, The State of Data Governance Maturity 2011

Notions like “Big Data” and “Information as an Asset” have stimulated thinking in many enterprises about extracting more value from the data already in enterprise repositories to benefit the business and its goals. But to extract that value, it’s not about the data nor is it about data governance. The key focus should be the business processes that impact revenue, business agility, competitiveness, and overall positive performance. However, both reliable data and effective data governance are key enablers of gaining value from business processes.

Data governance is an important strategy both to maintain data in its most usable condition and to ensure consistency in how processes work effectively across the enterprise, by sustaining the quality, accessibility and relevance of data used by processes. Instead of many siloed processes working on siloed data, data governance contributes greatly to connecting essential pieces to synchronize significant business processes to the bigger enterprise strategic picture.

Here is Martin Atherton on data governance as an enabler of business value:

For many companies, it is common to focus on the minimum standards required to achieve compliance, instead of seeking to incrementally expand the effort and reap the benefits of being compliant more broadly across the business. In a previous research note, we used the phrase ‘value driven compliance’ to highlight the difference between approaching regulatory compliance as a chore versus seeing it as a business enabler.

Some of the difficulty of transitioning how enterprises derive value from business processes (and the data running through them) is the fact that most data-related initiatives have been driven by IT instead of by more business-oriented roles.

To enable better business outcomes, data governance needs to bring business roles and IT teams together, as well as incorporating the support of various levels of management and strategic decision-makers. Too many times, data governance has not been implemented strategically. Instead it has been marooned by ad hoc decisions and “policies” tied more to daily operational situations. Without involving data governance in key corporate strategies, enterprises are not in good position to handle internal data issues, let alone address the ever-growing proliferation of data from many new sources inside and outside the enterprise.

Ross Dawson expands on the notion of “governance as an enabler”:

Governance should focus as much on enabling innovation and taking useful risks as about managing and mitigating risk… What needs to happen is that governance, risk, and compliance become part of the process of creating business value… More generally, I think it is important to note that IT governance and corporate governance have long been treated as separate. As I pointed out in my keynote this morning, technology – including in data management – is increasingly central to corporate strategy.

With good commitment from management, business units and IT teams alike, data governance initiatives are a very good way to manage data more effectively for greatly improved use in business processes. Data governance should provide the means to coordinate efficient and non-redundant business processes, along with the necessary data assets, across the enterprise, between lines of business.

From data governance coordination, standards for reliable data and optimized business processes can be implemented, maintained and changed as needed. Data governance is also an enabler of acquiring important insights into both data and business processes.

In my interactions with Forrester clients, I get the sense that data governance is receiving the most senior-management-level attention today than I’ve seen throughout my 18+ year data management career.

Rob Karel, Forrester

Tangible Value

Data alone carries little value. Unusable and poorly managed data carries no value. Real cost savings obviously result when data sources are streamlined and cleaned up, when processes are more responsive to business needs.

Great value can result when business intelligence and other processes are based on the right data that can be trusted to lead to decisions that are more accurate and timely. The tangible benefits and value of data governance and data are further revealed through their connections to business processes and the desired outcomes from those processes that connect to corporate strategies and goals.

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 take on the software industry via her blog Highly Competitive and on Twitter: @juliebhunt. For more information: Julie Hunt Consulting – Strategic Product & Market Intelligence Services.

Recapping our series so far:

• Why Govern Master Data?
• Getting Started with Data Governance, Part 1
• Getting Started with Data Governance, Part 2
• Organizing Data Governance for Success

A Sample Organizational Model

A three level model like this can work well at a lot of companies:

1. Data Governance Steering Committee: a cross-functional, executive level group that makes policy decisions, provides funding, resolves escalated issues, and provides strategic direction.
2. The Data Governance Office (DGO) is charged with coordinating data governance (strategic) and stewardship (tactical) activities. It manages communications from the Steering Committee to all stakeholders.
3. One or more tactical groups (Data Stewardship Teams) in each functional area and geography (if needed), which provide guidance to individuals with data stewardship responsibilities.

However, what’s most important is to have the organizational structure that will work in your company.

Data Governance Steering Committee

The Data Governance Steering Committee serves a function similar to the U.S. Supreme Court. Issues escalated by the Data Governance Office are resolved by the Steering Committee.

The Steering Committee probably won’t directly make much policy (except on an exception basis), except where the issues are serious or the dollar amounts are large. For example, where a new policy may be compliance-related and involve large penalties, the Steering Committee would at least review (and probably sign-off on) the new policy.

Similarly, establishing the overall Data Governance organization and its place in the company, as well as its Year 1 funding and its renewal, is probably a matter that will be settled by the Steering Committee.

The ultimate power in the corporation to make sure Data Governance policies are being followed, and to resolve issues escalated from lower levels, resides in the DG Steering Committee. But that group will, to a large extent, rely on the Data Governance Office to make it aware of when policies are not being followed, and when escalated issues need to be resolved.

This group will usually include senior level business owners and the overall executive sponsor(s) for data governance, and operates strictly at strategic level.

The key things at this level are: getting the right executives involved, and that once it starts meeting, it accomplishes some useful things. Otherwise, the executives will feel like they’re wasting their time when they do meet, and the group will quickly disband.

Data Governance Office

The Data Governance Office is similar to the Executive Branch of the Federal Government. It’s heavily involved in making data policy. It oversees the business data stewards and the IT stewards. The DG office is similar to a Program Management Office (PMO) and usually includes the global process owners (from the business) and the global solution owner from IT.

The DG Office operates at the tactical level but needs to be comfortable managing up (to the strategic level) and down (to the operational level).

The DG Office is critical to having a successful Data Governance initiative. Creating the right Data Governance Office can make or break your entire effort.

The policy making that transcends different line of business interests would typically be done in the Data Governance Office, since the DGO would have representation from the various lines of business through the global process owners.

Who’ll Head Up the Data Governance Office (DGO)?

There’s a tendency in these job descriptions to be a little “over the top”. Some companies are looking for people who can in effect walk on water, leap tall buildings in a single bound, etc.

Data Quality Pro had a great article recently: “Data Quality Director Required – Must Possess Powers of Invincibility”. Vincent McBurney wrote an interesting article titled “Data Governance is Career Suicide”.

Hub Designs Magazine responded with an article titled “Data Governance: The People Make It Real”, explaining how to support data governance leaders in their new roles.

This person does need a strong leadership style and the delegated authority of the executives on the Data Governance Steering Committee.

Data Stewardship Teams

The third level of the Data Governance Organization is similar to the Legislative Branch of the Federal Government.  It works with the Data Governance Office in making data policy, and in carrying it out.

These teams need to be from the business side in order to know the “ins and outs” of the data, but the teams should include IT stewards as well, to assist with the technology aspects of the data governance processes.

There are usually data stewardship teams from various functional areas and geographies. They work at the operational level but selected people may be representatives to the Data Governance Office (i.e. they’ll primarily be data stewards but they may attend meetings of the Data Governance Office, even if they’re not formally members of the DGO).

This is so they can adequately represent the stewardship level on issues they are bringing to the Data Governance Office for resolution.

These people spend time responding to issues raised by others; monitoring data quality and developing new data quality and business rules; but their real skill set is collaboration with multiple organizations at multiple levels.

Summary

Don’t get the impression that data governance means a big bureaucracy.

Every company will find its own balanced approach, with a business-driven, IT-supported group that makes decisions about information and governs master data like any other critical asset in the enterprise – with diligence, formal processes and metrics.

But people can fill multiple roles at first, and especially during the initial phases, you can take a pretty lean approach. It’s more important to start doing data governance than to wait for the perfect organizational structure and staffing.

Why is this stuff so hard?

Companies aren’t used to governing data across the entire enterprise. It goes against their well honed instincts, to break things up into smaller units or silos to make them more manageable. Where they do have data governance in place, it’s usually done at an application or business unit level.

And it can be tough to show ROI for data governance.

But companies with effective governance processes in place generate up to 40% higher ROI on their IT investments than their competitors, according to Peter Weill and Jeanne Ross in “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results” (Boston: Harvard Business School Press, 2004).

The bottom line is that managing things, when you have control over them yourself, is hard enough. Governing them, when you have to consult with others, gradually win them over, and lobby for things that matter deeply to you, is hard work!

How to get started

First, it’s important to avoid “analysis paralysis”. Since many organizations don’t know where to start, they do nothing at all.

Analyzing your current state and desired future state, using a maturity model as we discussed in the previous article, provides a framework for planning your activities and managing your expectations, enabling you to proceed.

Start by defining with some degree of precision (1) where the company is now, (2) where the company wants to be, and (3) over what period of time.

Then look at the critical elements such as MDM, data integration, data quality, data enrichment, data governance, business process management, BI, enterprise content management, and information lifecycle management over time. This should lead to a realistic plan and design. For more information on how to create a strategic roadmap, see James Parnitzke’s article on that topic.

Click to enlarge

Spend time on the design before launching

Don’t let yourself be rushed into getting organized too soon. Setting up a Data Governance Council too early is a classic failure mechanism!

Spend time on things like developing the data governance program’s overall vision and strategy, and its value statement – its reason for existing. Your stakeholders will want to know the answers to some basic questions like “where will the program live, and how will it be funded?”

Once you have the basics outlined, you can move on to the more detailed elements of the design. Who will be involved? How will the program be organized? Will it be centralized or de-centralized? Why are we doing this? What will the DG program do for the enterprise?

Before you launch a formal governance council, you need to have positioned the initiative to a key executive sponsor. Without them, the council will be just another meeting. Another point to keep in mind is that a global council can work cooperatively with local groups. Some companies think the global group is going to wind up being too big because it has to centrally govern all aspects of Customer, for example, instead of defining the 10 critical attributes across business processes and simply starting there.

Whatever you decide on these questions, working from a solid design is a lot easier than making it up as you go along.

When to start establishing Data Governance

Ideally, you would start about six months before starting any MDM initiative, so that your new DG group would have a chance to form itself, and then help drive the MDM initiative.

But don’t start before you’ve got your executive sponsorship and funding lined up. You’ll just end up with a failed data governance effort to explain away later. It’s better to wait until everything is lined up than start before you’re ready.

Then get ready for the ride of your life – corporate politics, new technology, organizational change, marketing communications, project management, you name it!

Using a Data Governance Maturity Model

Something that Hub Designs recommends early in a new Data Governance program is using a Data Governance Maturity Model to realistically assess how you currently govern data at the enterprise-wide level. This is helpful so that you’ll know where you’re starting from where the four dimensions of People, Process, Technology and Information are concerned, before embarking on your initiative.

Most Data Governance Maturity Models are based on the Software Engineering Institute’s Capability Maturity Model (CMM) for software development.

A Data Governance Maturity Model states what should occur at each level, not how to accomplish the activities. There are many different DG maturity models, but they share some common characteristics: they usually have 5 levels, and they’re just a tool to assess where you’re starting from, not something to get hung up on or on which to spend a lot of time.

The National Association of State CIOs (NASCIO) did a great study of the different Data Governance Maturity Models available from organizations such as IBM Data Governance Council, DataFlux, EWSolutions, Gartner, Knowledge Logistics, the MDM Institute, and Oracle Corporation, concluding that “data governance maturity models can be used as references in communication, awareness building, and the marketing of data governance”.

Where are most organizations today?

The important thing is to be realistic about where you’re starting from – most companies are starting at 0 or 1.

A lot of companies are doing governance, just not formally. People are managing data, they just need to figure out who’s doing it, and what and how they’re doing. Then group them and provide some central guidance to get them started.

Here are three things to think about:

• A recent survey of over 100 organizations found that only 10% have been able to move their DG programs beyond the lowest two levels of maturity. IT is still accountable for the data in 63% of organizations. Only 27% have established a data governance council with business representation and formal data stewardship. And 57% of organizations do not measure the performance of data management activities at all.
• Most companies with which Hub Designs has worked have not been successful making the types of organizational, cultural, process and technological changes necessary solely with internal resources.
• Most of the companies with which we’ve worked have a “research & analysis” period of up to two years under their belts before they start making serious progress on their MDM and governance programs.

The reality is that with cross-functional, multi-year programs such as MDM and data governance which involve multiple organizational, process, technology and information disciplines, it’s better to proceed deliberately and have a series of incremental “wins” that show business value, rather than go for a rapid implementation or a “big bang” approach.

Progress in this area is not linear – you make investments, you build competency, you do the hard work (and sometimes even get frustrated), and then by doing a relatively small amount of remaining work, you start to achieve your goals.

Like a baby learning to talk, or an adult learning a foreign language, there’s a steep learning curve that flattens out rapidly at the top. Companies will seem not to make progress for a long time (while they’re making the investment in growing their data governance capability), and then their abilities will come together rapidly, as people get a chance to put their new skills to work in a new Data Governance Organization.

The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journey. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started.

We live in interesting times. Poor information security practices led to the release of a huge number of secret diplomatic cables to WikiLeaks. The Federal Aviation Administration admitted that registration information for as many as one-third of all private aircraft is out-of-date and inaccurate, forcing the FAA to cancel and re-register all civil aircraft.

And the private sector isn’t immune. TUI Travel, Europe’s largest tour operator, accepted the resignation of its CFO after restating its 2009 results to the tune of $191.8 million, blaming problems in integrating computer systems following a 2007 merger.

Sound familiar? Hopefully, your company doesn’t have any data governance “skeletons in the closet” like these. But if you hunt around a bit, you’ll undoubtedly find people in your business who’ll tell you about:

• decisions that were made based on reports with wrong or missing information,
• the real costs of duplicate data in your customer master database,
• cash flow being impacted because invoices were being sent to the wrong addresses,
• supplier master issues causing millions in avoidable costs in lost volume discounts
• the penalties for not complying with industry and government regulations on customer data and privacy,
• failure to comply with tax laws because of inaccurate billing information,
• information-heavy projects that run over time, or require length rework after go-live,
• decommissioning systems is nearly impossible because clear retention and destruction policies have not been defined,
• manual correction and alignment of content and documents takes time away from resources because these items aren’t singularly governed,
• IT staff spending a lot of time re-integrating data and dealing with data fire-drills because data service level agreements and fit-for-use levels have not been established and tracked.

If you talk to business owners across functional areas like R&D, Marketing & Sales, Finance, Operations, Human Resources, and Customer Service, you’ll fill up a small notebook with the stories about what not having a data governance organization in place is costing your company.

What exactly is “master data”?

Good question. Master data is the lifeblood of your company. It’s information that’s critical to the enterprise, including entities such as customers, products, employees, suppliers, and locations. It’s shared (or it should be) across applications, systems and databases, and across multiple business processes, functional areas, organizations, geographies and channels. It’s generally not anything that happens at a particular time, but instead a person, place or thing that changes slowly over time. Master data is not transactional, but it’s used by and linked to transactions.

And what is “data governance”?

Master data needs to be governed as you would any other critical asset in the enterprise – with diligence, formal processes and metrics. I’ve often said that if companies treated their cash and their inventory the way they treat their customer and product data, a lot of people in corporate America would be going to jail.

Jill Dyché, in Ten Mistakes to Avoid when Launching Your Data Governance Program, defined data governance as “the decision rights and policymaking for corporate data”.

Whenever 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 technology can be an enabler.

One of my favorite quotes is by Dean Kamen, the inventor and entrepreneur:

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.

Simplifying today’s enterprise architectures

Today, most companies larger than $500 million – $1 billion in revenue:

• have grown through merger & acquisition activity,
• have a mixture of front office and back office suites and “best of breed” applications
• have some acquisitions and applications that are integrated and some that aren’t
• have created shadow IT organizations in individual Lines of Business in an effort to speed up results
• have created more complex processes for dealing with data issues, causing individual groups to creatively work around the processes
• have more diverse groups of workers with diverse experience (and preferences) for enabling software tools, like Excel

As a result, most companies suffer from significant data silos and data fragmentation – what I call the “Islands of Data” problem.

These data silos increase costs, hurt business and IT agility, and result in bad decisions being made throughout the enterprise (because of low quality, inaccurate, inconsistent data).

Master Data Management can solve the “Islands of Data” problem

Master Data Management (MDM) technology brings master data together in an MDM hub. In addition to the MDM hub itself, you’ll usually need:

• Data Integration (usually using Service-Oriented Architecture)
• Data Profiling and Data Quality
• Business Process and Business Rules Management
• Third Party Data Enrichment
• Technology to facilitate Data Governance

The MDM Hub centralizes master data, providing the much desired “Single Source of Truth”, streamlining business processes (which reduces costs and increases productivity and agility), and increasing revenue (through ability to support more targeted marketing and cross sell / up sell initiatives) and improving compliance.

But committing to MDM technology isn’t enough, unfortunately. Nor is it the first thing you need to figure out. In order to make the entire exercise work, we also need data governance.

So Why Do It? Why Govern Master Data?

The alternative – not governing it – is information chaos and anarchy. “A disaster of biblical proportions. Human sacrifice, dogs and cats living together… mass hysteria!” (from one of my favorite movies, Ghostbusters).

Seriously, why would we bring together master data from all over the enterprise, cleanse it, build golden records of customers, products, suppliers, etc. and not govern the decision-making process, result, and resulting analytics? That would be a value destruction exercise worthy of the Guinness Book of World Records.

Data governance is a critical success factor for master data management. MDM isn’t a “lights out operation”. Don’t try to do master data management without a data governance organization in place or under construction. You’ll wind up looking like this guy!

Along this line, information governance is an emerging business strategy attempting to regain competitive advantage from earlier investments in data management technologies. In a recent survey, IBM found that 65% of companies from various sectors across the USA are eager to roll out information governance even before the next business year ends. The question however remains: what is information governance about and how exactly should it be implemented? Is there a one-size-fits-all approach as claimed by many software vendors, or does every organization require a unique plan?

At the VU University in Amsterdam, we are looking to find an empirical answer to these questions. Based on a global survey, we want to find out how technology vendors can gear their products towards meeting information governance needs. Our survey focuses on the following research questions:

• What are business professionals’ perspectives on information governance?First of all, we want to sync up with current opinions on information governance. Academics commonly describe five decision domains of information governance (see figure below) – information principles, data quality, metadata (a.k.a business semantics), information access and information life-cycle management – but do professionals feel familiar with these domains? Do they find them all equally important for their company?

• How do they think information governance should be implemented in their company?After determining what is important to professionals, we want to find out how they think these decision domains should be supported by technology within their company. Where are they now and where do they want to go? Do they have someone to manage each domain, or do they have any ideas on who should? Since governance is all about making management happen, we are looking to establish roles and responsibilities to allow management of these domains.

With these insights, combined with a study of the current market solutions, we are looking to provide a framework for information governance. Vendors of information governance solutions can use this framework to adjust their approach and ultimately be of better service to organizations.

Information Governance frameworks typically identify five decision domains: principles, quality, metadata, access, and life cycle

Please participate

If you want to help us develop new insights on information governance, we invite you to take our survey that’s directed towards business and IT professionals from all layers of the organisation. It will take no more than ten minutes to complete. The survey will be online till the end of September. The results will be made available online.

Thank you for your cooperation!

www.surveymonkey.com/s/datagovernance

Twitter @ramonsistermans; @pdeleenheer

Ramon Sistermans is a master research student on Information Sciences at the VU University Amsterdam. Dr. Pieter De Leenheer is an assistant professor in Information and Service Sciences at the VU and is also co-founder and –director of Collibra nv/sa.

IT teams are already carrying heavy workloads with ever-shrinking staffing levels, and frequently don’t have the resources to immediately respond to time-sensitive LOB needs. However without IT involvement, these LOB groups do not usually have the expertise to understand the implications of creating data in the cloud and its relationship not only to data in other Software-as-a-Service (SaaS) / cloud offerings, but to on-premises systems as well. These business users need a partnership with IT to ensure that comprehensive data management processes are put into practice.

It’s clear that enterprises will continue to increase usage of cloud and SaaS offerings to find new ways to operate more competitively and efficiently. Unfortunately the rapid creation and adoption of cloud and SaaS services have led to increased data silos in the cloud. The same challenges that enterprises face for on-premises data management obviously apply to data repositories in the cloud: data quality and reliability, integration, governance, security and compliance, master data management (MDM), as well as improved data accessibility. There is now a even bigger picture for data management, where all of these domains need to be governed as an interoperating whole.

If enterprises fail to address a rigorous data management strategy for cloud computing initiatives, deterioration in data quality and reliability of cloud data are likely to kick in quickly. Data that cannot be trusted nor aligned with enterprise datasets will destroy the value and cost savings that enterprises want from cloud services. One of the most important requirements of business data generated through cloud services is security for that data. Not all data created in the cloud requires security, but most of it does. Comprehensive data management policies are needed in the cloud as well as for on-premises data repositories to ensure secure data processes.

The concerns of both business users and IT regarding data in the cloud have been articulated in many surveys including one recently completed by IDC where issues that relate directly to data governance and MDM initiatives covered security, data integration, operational costs and compliance – all pretty much to be expected when considering management strategies for cloud data. The IDC study goes on to discuss an important point that again requires IT and LOB groups working together: Business Relevance.

The next two challenges – the perceived difficulty of cloud services integration, and the limited ability to customize – are both related to the important issue of business relevance.  While customers certainly enjoy the economic and operational benefits of the off-the-shelf, standardized nature of many cloud services, this survey shows they nonetheless want greater ability to “fit” cloud services more tightly into the context of their specific business.

MDM and data governance provide clear value when they reflect the actual activities and processes of the enterprise. This approach also makes it easier for corporate decision-makers to understand the role MDM and data governance play to support strategic goals and even how they might map (at the high level) to key business processes. Malcolm Chisholm and Fabio Corzo flesh out these ideas in The True Role of MDM:

The importance of master data is not just data values or quality, but the real-life concepts they represent…

We are looking for fundamental business transformation that will take the business into new ways of perceiving, understanding and developing customers, employees, suppliers, assets and securities. We are looking for business transformation that moves in line with the business goals. And though executives understand that data is at the heart of proper and well-executed business transformation, experience tells us that more often than not, the business transformation is limited to improved data quality side effects that fail to realize the true value of an MDM program.

The above concepts become even more imperative when establishing management of data-driven business processes between the cloud and on-premises systems. There will need to be an evolution of data management and governance approaches to deal with new challenges that come from data in the cloud and from an integrated approach to managing data across disparate data domains, many of which are not owned by the enterprise.

Cloud services have been very effective in converting (or commoditizing) IT practices through well-formed repeatable processes. To accommodate proper data management for cloud and on-premises solutions, IT and business users will need to work together to build out data management solutions through practices and technologies that support the creation, use and storage of data “anywhere anytime”. Both IT and Business are important to setting the right strategies, including the crafting of a data management architecture that will kick in before an enterprise’s cloud data becomes too distributed for thorough governance. While more and more data will be owned by non-enterprise entities in the cloud, the ownership of comprehensive data management processes and practices continues to fall squarely on the enterprise through business users and IT working to ensure reliable data availability.

About the author: Julie Hunt is an accomplished software industry analyst, providing strategic market and competitive insights. Her 20+ 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: @juliebhunt. For more information: Julie Hunt Consulting – Strategic Product & Market Intelligence Services.

A three level model like this can work well at a lot of companies:

1. Data Governance Steering Committee: a cross-functional, executive level group that makes policy decisions, provides funding, resolves escalated issues, and provides strategic direction.
2. The Data Governance Office (DGO) is charged with coordinating data governance (strategic) and stewardship (tactical) activities. It manages communications from the Steering Committee to all stakeholders.
3. One or more tactical groups (Data Stewardship Teams) in each functional area and geography (if needed), which provide guidance to individuals with data stewardship responsibilities.

However, what’s most important is to have the organizational structure that will work in your company.

Data Governance Steering Committee

The Data Governance Steering Committee serves a function similar to the U.S. Supreme Court. Issues escalated by the Data Governance Office are resolved by the Steering Committee.

The Steering Committee probably won’t directly make much policy (except on an exception basis), except where the issues are serious or the dollar amounts are large. For example, where a new policy may be compliance-related and involve large penalties, the Steering Committee would at least review (and probably sign-off on) the new policy.

Similarly, establishing the overall Data Governance organization and its place in the company, as well as its Year 1 funding and its renewal, is probably a matter that will be settled by the Steering Committee.

The ultimate power in the corporation to make sure Data Governance policies are being followed, and to resolve issues escalated from lower levels, resides in the DG Steering Committee. But that group will, to a large extent, rely on the Data Governance Office to make it aware of when policies are not being followed, and when escalated issues need to be resolved.

This group will usually include senior level business owners and the overall executive sponsor(s) for data governance, and operates strictly at strategic level.

The key things at this level are: getting the right executives involved, and that once it starts meeting, it accomplishes some useful things. Otherwise, the executives will feel like they’re wasting their time when they do meet, and the group will quickly disband.

Data Governance Office

The Data Governance Office is similar to the Executive Branch of the Federal Government. It’s heavily involved in making data policy. It oversees the business data stewards and the IT stewards. The DG office is similar to a Program Management Office (PMO) and usually includes the global process owners (from the business) and the global solution owner from IT.

The DG Office operates at the tactical level but needs to be comfortable managing up (to the strategic level) and down (to the operational level).

The DG Office is critical to having a successful Data Governance initiative. Creating the right Data Governance Office can make or break your entire effort.

The policy making that transcends different line of business interests would typically be done in the Data Governance Office, since the DGO would have representation from the various lines of business through the global process owners.

Who’ll Head Up the Data Governance Office (DGO)?

There’s a tendency in these job descriptions to be a little “over the top”. Some companies are looking for people who can in effect walk on water, leap tall buildings in a single bound, etc.

Data Quality Pro had a great article recently: “Data Quality Director Required – Must Possess Powers of Invincibility”. Vincent McBurney wrote an interesting article titled “Data Governance is Career Suicide”.

Hub Designs Magazine responded with an article titled “Data Governance: The People Make It Real”, explaining how to support data governance leaders in their new roles.

This person does need a strong leadership style and the delegated authority of the executives on the Data Governance Steering Committee.

Data Stewardship Teams

The third level of the Data Governance Organization is similar to the Legislative Branch of the Federal Government.  It works with the Data Governance Office in making data policy, and in carrying it out.

These teams need to be from the business side in order to know the “ins and outs” of the data, but the teams should include IT stewards as well, to assist with the technology aspects of the data governance processes.

There are usually data stewardship teams from various functional areas and geographies. They work at the operational level but selected people may be representatives to the Data Governance Office (i.e. they’ll primarily be data stewards but they may attend meetings of the Data Governance Office, even if they’re not formally members of the DGO).

This is so they can adequately represent the stewardship level on issues they are bringing to the Data Governance Office for resolution.

These people spend time responding to issues raised by others; monitoring data quality and developing new data quality and business rules; but their real skill set is collaboration with multiple organizations at multiple levels.

Summary

Don’t get the impression that data governance means a big bureaucracy.

Every company will find its own balanced approach, with a business-driven, IT-supported group that makes decisions about information and governs master data like any other critical asset in the enterprise – with diligence, formal processes and metrics.

But people can fill multiple roles at first, and especially during the initial phases, you can take a pretty lean approach. It’s more important to start doing data governance than to wait for the perfect organizational structure and staffing.

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. 

Why is this stuff so hard?

Companies aren’t used to governing data across the entire enterprise. It goes against their well honed instincts, to break things up into smaller units or silos to make them more manageable. Where they do have data governance in place, it’s usually done at an application or business unit level.

And it can be tough to show ROI for data governance.

But companies with effective governance processes in place generate up to 40% higher ROI on their IT investments than their competitors, according to Peter Weill and Jeanne Ross in “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results” (Boston: Harvard Business School Press, 2004).

The bottom line is that managing things, when you have control over them yourself, is hard enough. Governing them, when you have to consult with others, gradually win them over, and lobby for things that matter deeply to you, is hard work!

How to get started

First, it’s important to avoid “analysis paralysis”. Since many organizations don’t know where to start, they do nothing at all.

Analyzing your current state and desired future state, using a maturity model as we discussed in the previous article, provides a framework for planning your activities and managing your expectations, enabling you to proceed.

Start by defining with some degree of precision (1) where the company is now, (2) where the company wants to be, and (3) over what period of time.

Then look at the critical elements such as MDM, data integration, data quality, data enrichment, data governance, business process management, BI, enterprise content management, and information lifecycle management over time. This should lead to a realistic plan and design. For more information on how to create a strategic roadmap, see James Parnitzke’s article on that topic.

Click to enlarge

Spend time on the design before launching

Don’t let yourself be rushed into getting organized too soon. Setting up a Data Governance Council too early is a classic failure mechanism!

Spend time on things like developing the data governance program’s overall vision and strategy, and its value statement – its reason for existing. Your stakeholders will want to know the answers to some basic questions like “where will the program live, and how will it be funded?”

Once you have the basics outlined, you can move on to the more detailed elements of the design. Who will be involved? How will the program be organized? Will it be centralized or de-centralized? Why are we doing this? What will the DG program do for the enterprise?

Before you launch a formal governance council, you need to have positioned the initiative to a key executive sponsor. Without them, the council will be just another meeting. Another point to keep in mind is that a global council can work cooperatively with local groups. Some companies think the global group is going to wind up being too big because it has to centrally govern all aspects of Customer, for example, instead of defining the 10 critical attributes across business processes and simply starting there.

Whatever you decide on these questions, working from a solid design is a lot easier than making it up as you go along.

When to start establishing Data Governance

Ideally, you would start about six months before starting any MDM initiative, so that your new DG group would have a chance to form itself, and then help drive the MDM initiative.

But don’t start before you’ve got your executive sponsorship and funding lined up. You’ll just end up with a failed data governance effort to explain away later. It’s better to wait until everything is lined up than start before you’re ready.

Then get ready for the ride of your life – corporate politics, new technology, organizational change, marketing communications, project management, you name it!

Using a Data Governance Maturity Model

Something that Hub Designs recommends early in a new Data Governance program is using a Data Governance Maturity Model to realistically assess how you currently govern data at the enterprise-wide level. This is helpful so that you’ll know where you’re starting from where the four dimensions of People, Process, Technology and Information are concerned, before embarking on your initiative.

Most Data Governance Maturity Models are based on the Software Engineering Institute’s Capability Maturity Model (CMM) for software development.

A Data Governance Maturity Model states what should occur at each level, not how to accomplish the activities. There are many different DG maturity models, but they share some common characteristics: they usually have 5 levels, and they’re just a tool to assess where you’re starting from, not something to get hung up on or on which to spend a lot of time.

The National Association of State CIOs (NASCIO) did a great study of the different Data Governance Maturity Models available from organizations such as IBM Data Governance Council, DataFlux, EWSolutions, Gartner, Knowledge Logistics, the MDM Institute, and Oracle Corporation, concluding that “data governance maturity models can be used as references in communication, awareness building, and the marketing of data governance”.

Where are most organizations today?

The important thing is to be realistic about where you’re starting from – most companies are starting at 0 or 1.

A lot of companies are doing governance, just not formally. People are managing data, they just need to figure out who’s doing it, and what and how they’re doing. Then group them and provide some central guidance to get them started.

Here are three things to think about:

• A recent survey of over 100 organizations found that only 10% have been able to move their DG programs beyond the lowest two levels of maturity. IT is still accountable for the data in 63% of organizations. Only 27% have established a data governance council with business representation and formal data stewardship. And 57% of organizations do not measure the performance of data management activities at all.
• Most companies with which Hub Designs has worked have not been successful making the types of organizational, cultural, process and technological changes necessary solely with internal resources.
• Most of the companies with which we’ve worked have a “research & analysis” period of up to two years under their belts before they start making serious progress on their MDM and governance programs.

The reality is that with cross-functional, multi-year programs such as MDM and data governance which involve multiple organizational, process, technology and information disciplines, it’s better to proceed deliberately and have a series of incremental “wins” that show business value, rather than go for a rapid implementation or a “big bang” approach.

Progress in this area is not linear – you make investments, you build competency, you do the hard work (and sometimes even get frustrated), and then by doing a relatively small amount of remaining work, you start to achieve your goals.

Like a baby learning to talk, or an adult learning a foreign language, there’s a steep learning curve that flattens out rapidly at the top. Companies will seem not to make progress for a long time (while they’re making the investment in growing their data governance capability), and then their abilities will come together rapidly, as people get a chance to put their new skills to work in a new Data Governance Organization.

The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journeys. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started.

We live in interesting times. Poor information security practices led to the release of a huge number of secret diplomatic cables to WikiLeaks. The Federal Aviation Administration admitted that registration information for as many as one-third of all private aircraft is out-of-date and inaccurate, forcing the FAA to cancel and re-register all civil aircraft.

And the private sector isn’t immune. TUI Travel, Europe’s largest tour operator, accepted the resignation of its CFO after restating its 2009 results to the tune of $185 million, blaming problems in integrating computer systems following a 2007 merger.

Sound familiar? Hopefully, your company doesn’t have any data governance “skeletons in the closet” like these. But if you hunt around a bit, you’ll undoubtedly find people in your business who’ll tell you about:

• decisions that were made based on reports with wrong or missing information,
• the real costs of duplicate data in your customer master database,
• cash flow being impacted because invoices were being sent to the wrong addresses,
• supplier master issues causing millions in avoidable costs in lost volume discounts
• the penalties for not complying with industry and government regulations on customer data and privacy,
• failure to comply with tax laws because of inaccurate billing information,
• information-heavy projects that run over time, or require length rework after go-live,
• decommissioning systems is nearly impossible because clear retention and destruction policies have not been defined,
• manual correction and alignment of content and documents takes time away from resources because these items aren’t singularly governed,
• IT staff spending a lot of time re-integrating data and dealing with data fire-drills because data service level agreements and fit-for-use levels have not been established and tracked.

If you talk to business owners across functional areas like R&D, Marketing & Sales, Finance, Operations, Human Resources, and Customer Service, you’ll fill up a small notebook with the stories about what not having a data governance organization in place is costing your company.

What exactly is “master data”?

Good question. Master data is the lifeblood of your company. It’s information that’s critical to the enterprise, including entities such as customers, products, employees, suppliers, and locations. It’s shared (or it should be) across applications, systems and databases, and across multiple business processes, functional areas, organizations, geographies and channels. It’s generally not anything that happens at a particular time, but instead a person, place or thing that changes slowly over time. Master data is not transactional, but it’s used by and linked to transactions.

And what is “data governance”?

Master data needs to be governed as you would any other critical asset in the enterprise – with diligence, formal processes and metrics. I’ve often said that if companies treated their cash and their inventory the way they treat their customer and product data, a lot of people in corporate America would be going to jail.

Jill Dyché, in Ten Mistakes to Avoid when Launching Your Data Governance Program, defined data governance as “the decision rights and policymaking for corporate data”.

Whenever 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 technology can be an enabler.

One of my favorite quotes is by Dean Kamen, the inventor and entrepreneur:

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.

Simplifying today’s enterprise architectures

Today, most companies larger than $500 million – $1 billion in revenue:

• have grown through merger & acquisition activity,
• have a mixture of front office and back office suites and “best of breed” applications
• have some acquisitions and applications that are integrated and some that aren’t
• have created shadow IT organizations in individual Lines of Business in an effort to speed up results
• have created more complex processes for dealing with data issues, causing individual groups to creatively work around the processes
• have more diverse groups of workers with diverse experience (and preferences) for enabling software tools, like Excel

As a result, most companies suffer from significant data silos and data fragmentation – what I call the “Islands of Data” problem.

These data silos increase costs, hurt business and IT agility, and result in bad decisions being made throughout the enterprise (because of low quality, inaccurate, inconsistent data).

Master Data Management can solve the “Islands of Data” problem

Master Data Management (MDM) technology brings master data together in an MDM hub. In addition to the MDM hub itself, you’ll usually need:

• Data Integration (usually using Service-Oriented Architecture)
• Data Profiling and Data Quality
• Business Process and Business Rules Management
• Third Party Data Enrichment
• Technology to facilitate Data Governance

The MDM Hub centralizes master data, providing the much desired “Single Source of Truth”, streamlining business processes (which reduces costs and increases productivity and agility), and increasing revenue (through ability to support more targeted marketing and cross sell / up sell initiatives) and improving compliance.

But committing to MDM technology isn’t enough, unfortunately. Nor is it the first thing you need to figure out. In order to make the entire exercise work, we also need data governance.

So Why Do It? Why Govern Master Data?

The alternative – not governing it – is information chaos and anarchy. “A disaster of biblical proportions. Human sacrifice, dogs and cats living together… mass hysteria!” (from one of my favorite movies, Ghostbusters).

Seriously, why would we bring together master data from all over the enterprise, cleanse it, build golden records of customers, products, suppliers, etc. and not govern the decision-making process, result, and resulting analytics? That would be a value destruction exercise worthy of the Guinness Book of World Records.

Data governance is a critical success factor for master data management. MDM isn’t a “lights out operation”. Don’t try to do master data management without a data governance organization in place or under construction. You’ll wind up looking like this guy!

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 Kalido presenters included Bill Hewitt, President and CEO, Winston Chen, VP of Strategy and Business Development, Lovan Chetty, Senior Manager of Product Management, Mike Wheeler, Director of Data Governance Solutions and Lorita Vannah, Director of Marketing Communications. Lorita is the person who first turned me on to Kalido, about two years ago now. We first met at the 2008 Gartner MDM Summit in Chicago, and she impressed me then with her passion for MDM, data governance and her company.

Bill started off by talking about how the data governance market has been exploding as the volume of corporate data has been exploding, which is certainly true, and observed that Kalido noticed a disconnect between data and business processes. To address this issue, Kalido developed a new product from the ground up, because the company felt that data was better managed through policies. For example, it may be okay to store customer data in multiple places, as long as the relevant policy allows that.

As part of its research into data governance, Kalido developed its own data governance maturity assessment. Winston described the evolution of data governance, from application-centric to today’s “enterprise repository centric” approach. The next phase, according to Kalido, is policy centric, followed by fully governed. Winston also discussed the need to manage data policies in context: you’ve got data, but you’ve also got business processes, systems and organizational scope.

That allows you to fully describe the context in which a particular policy is being defined.

The way to operationalize governance processes is: to define the policy, to implement the policy, and then to enforce the policy, which Kalido modeled on how laws are created by the legislative branch, implemented by the executive branch, and then enforced by law enforcement and the judicial branch of government.

Kalido has been working with data quality vendors such as DataFlux and Trillium to build integration with their products into Kalido Data Governance Director, so metrics can be automatically gathered back into DGG from those data quality tools.

If a data quality problem goes beyond the single or small number “issue” state, then it could be remediated as an “initiative”, where it would be put into Data Governance Director and tracked as a separate initiative, with all of the visibility and accountability that goes with that, and the full life cycle of governance – definition, implementation, and metrics / enforcement – could be used to make sure the data quality issue was resolved.

Lovan Chetty did a brief demonstration of the product, showing a web-based user interface to author new initiatives and policies, manage scope and organizational parameters, and create a unified business model, including a data model, process model and systems model.

Mike Wheeler talked about Kalido’s lighthouse customer program for Data Governance Director, which consisted of cultivating about 16 companies and 3 consulting firms, including some large financial services providers and manufacturing companies, at different levels of data governance maturity, to provide input and feedback on their policies and data governance programs and practices.

A number of them will be speaking at tomorrow’s Kalido Connect virtual user conference.

One very large company had a “light going on” moment when using the product, when they realized that pulling the knowledge out of everyone’s head is the hardest part, and that lots of “tribal knowledge” is often never incorporated in the actual policies.

One of the largest banks in Mexico, Scotiabank, has already bought the product prior to its general availability, in order to streamline its data governance operations. And a Top-5 pharmaceutical company has also signed up as a customer.

After a short Q&A session, Kalido promised to let everyone get a closer look at the new product in their virtual user conference tomorrow. For more information, or to register, please go to http://bit.ly/kalido-register.

The screen shot below shows the product measuring and reporting data policy compliance status based on results captured from 3rd party monitoring tools.

The latest issue of Information Management magazine is out, and my column in this edition is titled “Data Governance: A Chicken and Egg Problem”.

Here’s a brief introduction to the article:

Data governance suffers from a bit from the “chicken or the egg” syndrome. People at your company aren’t going to understand what data governance is and what it can do for them until they actually see the results. However, getting the initiative funded and launched will only happen if you can convince your company of the tangible benefits of data governance. That can be difficult when there’s no actual program in place.

You can read the rest of the article at: http://digital.info-mgmt.com/info-mgmt/20101112#pg33.

Please let us know what you think of the article by using the “Leave a Comment” link here.

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!

Whether you call it software-as-a-service or cloud computing, deploying enterprise applications via the Internet continues to gain momentum. In fact, pioneers such as Amazon, Google, Rackspace, Salesforce.com, and NetSuite have experienced rapid growth in demand, despite global economic uncertainty.

Although we’re still in the early days of cloud computing, its benefits are compelling. Dave Powers, Eli Lilly’s associate information consultant for discovery IT, recently said “We were … able to launch a 64-machine cluster computer working on bioinformatics sequence information, complete the work, and shut it down in 20 minutes. It cost $6.40. To do that internally–to go from nothing to getting a 64-machine cluster installed and qualified–is a 12-week process.”

Master data management (MDM) is also moving to the cloud. MDM is a set of disciplines, processes, and technologies for ensuring the accuracy, completeness, timeliness, and consistency of multiple domains of enterprise data across applications, systems, and databases, and across multiple business processes, functional areas, organizations, geographies, and channels. Note the key words: “multiple,” “across,” and “enterprise.” MDM spans multiple domains of master data and reaches across the many silos that exist in today’s enterprises, and cloud computing helps organizations integrate master data across multiple data centers in different geographies or from different acquisitions.

When I talk to people about moving MDM hubs from corporate data centers to cloud computing environments, security and compliance are by far the most frequently raised issues.

Ironically, corporate data centers may actually be less secure than cloud computing environments. Over the last few years, there have been thousands of well-publicized breeches at “household name” organizations. The Privacy Rights Clearinghouse has compiled an extensive list of known data breaches, along with the number of records exposed with each incident. Of course, there have also been attacks on, and breaches by, cloud computing providers such as Google, but there are far fewer of these incidents. That being said, there’s both a perception issue and a real need for improved security by cloud providers, particularly as security threats continue to grow and evolve.

When it comes to compliance, moving enterprise applications into the cloud doesn’t absolve a company from the laws and regulations it falls under compared to when the company provides that service inside its firewall. Depending on the industry involved, evaluating potential cloud providers against that industry’s compliance requirements can definitely be a nontrivial effort.

MDM vendors–Oracle, IBM, SAP, Informatica/Siperian, Initiate (an IBM company) and smaller providers–are evolving to the cloud. Oracle’s Fusion MDM hub will offer a cloud deployment capability when it ships early next year. IBM and Initiate are likely working on future versions of their products that will operate smoothly in the cloud. Informatica, having acquired Siperian, has also made major investments in cloud computing.

Security, legal, and technical issues still need to be resolved by the cloud computing providers, software vendors, systems integrators, and their enterprise customers. This will involve firewalls, encryption, backup solutions, disaster recovery, service-level agreements, and so on, but technology and legal teams are good at solving these kinds of problems.

Meanwhile, the benefits are too large to ignore. Economically, it makes more sense to share complex infrastructure and pay only for what you actually use. From a time-to-value perspective, cloud computing allows you to skip hardware procurement and capital expenditure and instead just order from a “menu.”

Maintenance and updates are a constant headache for most IT shops. Thankfully, most cloud providers continuously update their software, adding new features as they become available. As for scalability, cloud systems are built to handle sharp increases in workload. Furthermore, cloud solutions are designed to work with a simple Web browser, so users can access them from their desktops, laptops, or smartphones.

The MDM market will probably trail the rest of the enterprise a bit, but the appetite for building large, multi-million dollar applications inside the firewall is cooling. CIOs see the economics of buying, maintaining, and upgrading the applications and accompanying servers, and end up saying, “On the whole, I think I’d rather rent!”

I’d love to know what you think of the question of moving MDM into the cloud. Please click the “Leave a Comment” button and share your thoughts.

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.

I’ve tried to emulate him by being an evangelist for customer and product MDM. From 2001 to 2004, I was a consultant working with the precursor to Oracle’s Customer Data Hub platform. At D&B from 2004 to 2007, I managed its strategic alliance with Oracle while Oracle launched and refined Customer Data Hub. I left D&B to start Hub Designs in 2007 because I wanted to work more directly in developing and executing MDM strategy at corporate clients. All this time, I’ve tried to get people excited about using the evolving technology to solve business problems.

In the past nine years, in all of the different industries and companies I’ve worked with, most have quickly “gotten” MDM:

• They understand the value of the Single View of the Customer (or Product, as the case may be).
• They see the revenue increases from being able to up-sell and cross-sell customers by knowing more about them, and by knowing their own products better.
• They understand the dollar value of having a streamlined, coordinated New Product Introduction process.
• They see the short payback period and millions in savings from a strategic sourcing program that consolidates vendors and products, and renegotiates agreements.
• They understand the contribution MDM makes to credit risk management (know your customer, and whether they can pay their bills on time).
• And they see how MDM (done properly, which includes data quality improvement and a data governance program) makes it much easier and more efficient to have accurate, complete, timely and consistent information available for compliance with governance regulations.

But all of those organizations, where I’ve been the “external champion” or evangelist, have needed a corresponding “internal champion” or evangelist.

Someone to lead the charge internally, to have the hallway conversations, to fight the good fight politically, to scrap for every budget dollar, to convince the powers that be, the type of person who digs in and doesn’t let go. Someone who’s convinced that master data management and data governance is important to his or her company. That it’s so important that it’s worth going out on a bit of a career limb. Or who perhaps was brought in specifically to head up an initiative like this.

My friend Tom Carlock wrote a great article called “So You Want to be a Data Champion?”, where he discusses how to be prepared to be your organization’s “data champion”. Tom knows whereof he speaks, because he’s been in roles like that at The CIT Group and AIG, and is now a leader of product strategy at D&B. He mentions attributes like being able to have a consistent vision that you can “sell” to others, the ability to develop and maintain relationships, being able to listen, ask for input and deal with objections, and being optimistic, hopeful and patient.

To that I would add, being persistent. My father introduced me to a quote by Calvin Coolidge, the 30th U.S. President:

“Nothing in this world can take the place of persistence. Talent will not; nothing is more common than unsuccessful people with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent.”

If you decide to become an MDM evangelist at your company, and you’re persistent in that role, you can help your company manage master data as an enterprise-wide asset – and transform itself in the process. I think our corporations today – ten years into the twenty-first century – desperately need that type of innovation and change.

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!

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.

This is an important first step to take, assuming the business case is completed and approved. It forces us to address the very real challenges up front, before embarking on a journey that our stakeholders must understand and support. Obtaining buy-in and executive support means we all share a common vision.

MDM is more than maintaining a central repository of master data. The shared reference model should provide a resilient, adaptive blueprint to sustain high performance and value over time.

An MDM solution should include the tools for modeling and managing business knowledge of data in a sustainable way.  This may seem like a tall order, but consider the implications if we focus on the tactical and exclude the reality of how the business will actually adopt and embrace all of your hard work.

Or worse, asking the business to start from a blank sheet of paper and expect them to tell you how to rationalize and manage the integrity rules connecting data across several systems, eliminate duplication and waste, and ensure an authoritative source of clean, reliable information can be audited for completeness and accuracy. Still waiting?

So What’s in This Blueprint?

The critical thing to remember is the MDM project is a business project that requires establishing a common information model that applies whatever the technical infrastructure or patterns you plan on using may be. The blueprint should remain computation and platform independent until the Operating Model is defined (and accepted by the business), and a suitable Common Information Model (CIM) and Canonical Model are completed to support and ensure the business intent.

Then, and only then, are you ready to tackle the Reference Architecture.

The essential elements should include:

• Common Information Model
• Canonical Model
• Operating Model, and
• Reference Architecture (e.g. 4+1 views).

I’ll be discussing each of these important and necessary components within the MDM blueprint in future articles in this series, and I encourage you to participate and share your professional experience. Adopting and succeeding at Master Data Management is not easy, and jumping into the “deep end” without truly understanding what you are solving for is never a good idea.

Whether you are a hands-on practitioner, program manager, or an executive planner, I can’t emphasize enough how critical modeling the MDM blueprint and sharing this with the stakeholders is to success. You simply have to get this right before proceeding further.

To download the replay of the webinar (with audio), please go to http://bit.ly/hub-designs-webinar.  To download just the slides, please go to http://bit.ly/mdm-best-practices and click “Download”.

For the “When Data Governance Turns Bureaucratic” white paper mentioned in the presentation, go to http://bit.ly/data-governance.  Scroll to and click the link at the end of that article.

Thanks for attending the webinar (or the replay). We hope you found it valuable!

In this series, we’ve discussed developing the MDM blueprint by creating the Common Information (Part 2), Canonical (Part 3), and Operating (Part 4) models in our work streams. We’ve introduced the Operating Model into the mix to communicate with the business how the solution will be adopted and used to realize the expected benefits. And hopefully we’ve set reasonable expectations with our business partners as to what this solution will look like when deployed.

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.

Continue with Part 6 or go back to Part 4.

In Part 2 and Part 3 of this series, we discussed the Common Information and Canonical Models. Because MDM is a business project, we need to establish of a common set of models that can be referenced independently of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating Model to communicate how the solution will actually be deployed and used to realize the expected benefits.

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.

Continue with Part 5 or go back to Part 3.

Several practitioners have contributed to this complex subject (see Dan Power’s Five Essential Elements of MDM and CDI, for example) and have done a good job at describing the critical elements.  There is one more element that’s often overlooked however, and it remains a key differentiator and all too often, it’s the difference between success and failure among the major initiatives I’ve had the opportunity to witness – modeling the blueprint for MDM. 

This is an important first step to take, assuming the business case is completed and approved. It forces us to address the very real challenges up front, before embarking on a journey that our stakeholders must understand and support. Obtaining buy-in and executive support means we all share a common vision.

MDM is more than maintaining a central repository of master data. The shared reference model should provide a resilient, adaptive blueprint to sustain high performance and value over time.

An MDM solution should include the tools for modeling and managing business knowledge of data in a sustainable way.  This may seem like a tall order, but consider the implications if we focus on the tactical and exclude the reality of how the business will actually adopt and embrace all of your hard work.

Or worse, asking the business to start from a blank sheet of paper and expect them to tell you how to rationalize and manage the integrity rules connecting data across several systems, eliminate duplication and waste, and ensure an authoritative source of clean, reliable information can be audited for completeness and accuracy. Still waiting?

So What’s in This Blueprint?

The critical thing to remember is the MDM project is a business project that requires establishing a common information model that applies whatever the technical infrastructure or patterns you plan on using may be. The blueprint should remain computation and platform independent until the Operating Model is defined (and accepted by the business), and a suitable Common Information Model (CIM) and Canonical Model are completed to support and ensure the business intent.

Then, and only then, are you ready to tackle the Reference Architecture.

The essential elements should include:

• Common Information Model
• Canonical Model
• Operating Model, and
• Reference Architecture (e.g. 4+1 views).

I’ll be discussing each of these important and necessary components within the MDM blueprint in future articles in this series, and I encourage you to participate and share your professional experience. Adopting and succeeding at Master Data Management is not easy, and jumping into the “deep end” without truly understanding what you are solving for is never a good idea.

Whether you are a hands-on practitioner, program manager, or an executive planner, I can’t emphasize enough how critical modeling the MDM blueprint and sharing this with the stakeholders is to success. You simply have to get this right before proceeding further.

Continue with Part 2.

Siperian, an innovative provider of Master Data Management (MDM) solutions, is teaming up with Dan Power from Hub Solution Designs on a webinar titled “Top Five Reasons Not To Master Your Data in SAP ERP”.

A lot of organizations use SAP Enterprise Resource Planning (ERP) for their transaction processing, but struggle to manage their non-transactional (or master) data, including customer, product, and supplier information. These types of data require a separate Master Data Management (MDM) system – to streamline business processes, reduce costs, and increase revenue by creating a single view of the customer, product, or supplier.

Dan Power will discuss the following topics during this 45-minute webinar:

• Why SAP ERP is not the right place to master data
• Why a separate MDM system is required for streamlining business operations
• How MDM and SAP ERP coexist
• The technical attributes, strengths and weaknesses of SAP and Siperian MDM products
• The requirements of an effective MDM system and best practices for implementation

This free webinar will be held on Thursday, Feb. 5, 2009 at 11:00 AM Pacific (y:00 PM Eastern), and will include a live question & answer session.

To register, please visit http://forms.siperian.com/content/5Reasons-SAP.