by Julie Hunt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Liaison provides a cloud-based platform, which is a horizontally marketed solution with a strong focus on Life Sciences. The solution emphasizes a Data Integration component, which handles the movement, transformation and delivery of data. There’s a Data Management component, which handles data quality improvement through semantic data and metadata management, as well as data modeling, data cleansing and  enrichment. Finally, there’s a Data Security component, which protects data at rest and in motion, and provides compliance with  mandates.

Liaison defines MDM as “an ongoing process of continuous data improvement to better meet the needs of the business”, and approaches MDM via a “software as a service” (SaaS) approach through a lifecycle of:

• Data Integration
• Data Consolidation
• Data Management
• Data Automation

Liaison approaches MDM from a history in the product domain, but at this point, many of its customers are mastering product data and business-to-business customer data as well.

The main product component of the Liaison Technologies solution is Enterprise Content Director, which I found a little confusing, since it brought to mind a content management system (CMS). But from the discussion with Jonathan Razza, it was apparent that Liaison was doing the classic MDM functions, such as:

• Extracting data from source systems
• Audit and cleansing
• Matching and merging (survivorship)
• Conversion and loading data
• Maintaining a master repository
• Synchronizing additions and updates to the master data back to the source systems

Additionally, Liaison can do data enrichment in the cloud, focused on the customer domain. Using web services, Liaison’s product can invoke any web service to validate or enrich customer data.

Since Liaison’s product is delivered via the cloud, it makes it easier for Liaison to offer outsourced data stewardship, using an onshore model. This has become a differentiator for Liaison, as it offers managed services (in blocks of hours) to assist clients who may find it difficult to get access to their own internal IT resources when they need something done quickly.

Liaison Technologies brought its customer, xpedx, to tell us about their experiences in an end user case study. xpedx is a $7 billion North American paper, graphic supplies and equipment distributor that has tapped into Liaison’s Cloud MDM solution. xpedx was a finalist in the 2011 Gartner MDM Excellence Awards.

Scott Dickerson, who is the National E-Business Manager for Data Quality and Catalog Services at xpedx, talked to us about their experience with Liaison Technologies. xpedx had over a dozen ERP systems at one point, and over 700,000 – 800,000 SKUs (products).

xpedx uses Liaison to manage 600 product attributes, as well as to integrate data coming from its 13,000+ suppliers. Liaison built a custom web-based “front end” to their cloud offering for xpedx, and uses about 65 ontologies to classify and categorize its products.

Datapoint, the name for the custom web portal created jointly by xpedx and Liaison, turns “dumb applications” into applications capable of producing “smart data” – where the data is in a “ready to go” format for consumption within xpedx.

Liaison has about 9,000 customers across all their services and solutions and almost 40 cloud MDM clients, and like the rest of the MDM industry, is experiencing rapid growth in the interest in and demand for its product. One thing that was interesting about this briefing was that Liaison was the first MDM vendor to bring a customer voice into the conversation at the briefing, and I thought it added a lot of credibility to their message.

In the first and second segments of this series, we discussed situations where implicit values are woven into business processes or IT systems unknowingly or on purpose. The examples provided may seem trivial on the surface if one considers that everybody in the business had the implicit knowledge needed to make sense of the information. It is not so trivial when time passes, employees retire or leave, and there are implicit values scattered around the enterprise that nobody remembers anymore. Add to that the fact that implicit values, by nature, are not self-documenting and in my experience rarely externally documented. By now you should be able to identify the existence of implicit values in overloaded, NULL, or implied default values within your organization. More importantly, you should understand the potential consequences of each situation and be able to intelligently challenge those who perpetuate these practices. This last section provides alternatives to implicit designs and provides methods for mitigating risks within legacy systems.

Governance Policies are where many data quality issues get resolved or avoided. Without defined Governance, the status quo becomes the standard and data quality does not improve. Adding new policies may do little for directly combatting legacy system shortcomings, but it does set the stage for preventing the proliferation of implicit values by mandating that new interfaces to legacy systems not accept them.

An involved and informed Data Governance team is the best defense to limiting proliferation of implicit values. Introducing an enterprise-wide standard to restrict the use of optional relationships between code parent and referring child tables is a start. As stated earlier, optional relationships are ones that allow NULL child table values to exist. For example, a sales table allows a discount type code of NULL if no discount applies. To satisfy such a mandate in this situation, discount code table entries of ‘Not Provided’ and ‘No Discount’ would be added. If a NULL is received, the relationship maps to the ‘Not Provided’ entry. The Point of Sale system could now default a discount to the ‘No Discount’ code value if none was given. This solution explicitly provides a discount value in all situations and provides an easy means to identify when data transformation issues occur if a ‘Not Provided’ value sneaks in. The approach leaves open possibilities for additional entries in code tables to represent a ‘Not Applicable’ business condition or an ‘Invalid’ situation which could be set if a code value is detected during loading of the sales table that does not match a value within the domain of valid discount codes.

A Data Governance body worth its salt creates standards concerning definition, collection, and dissemination of metadata. In the policy planning phase, the Governance body can define the required column-level metadata collected to include values like: Default Value, Min/Max values, Domain, and Nullability. If business users define that NULL values are allowed, a follow-up discussion is required to determine the business meaning of a NULL value. Such a discussion is the opportune time to explore options to NULL values. Forcing the business data owners to define data elements to this degree provides the rules to eliminate several forms of undesired implicit values and it makes for better business system designs.

A strong Data Architecture group plays a role in Data Governance policy enforcement. Data Architecture groups influence database and application designers to use NOT NULL and default value constraints and to define relationships as ’Required’ instead of ‘Optional.’ Mandatory peer code reviews using checklists ensure designs meet enforced policies.

Overloading, as defined in the first segment of this series, is a costly practice that is easily avoided through proper data design techniques. Overloaded code values are avoided by creating separate child fields and separate parent code tables. Overloading of transaction metrics is handled similarly by splitting transaction values into different attributes if at the same summary level or different tables if transactions are at different summary levels. Overloaded records, like copybooks, just have no place in relational database design. If somebody tries to justify them, you have my permission to mock them in public but I am not responsible for any repercussions if the mock-ee is your boss.

The goal of this article was to demonstrate that using implicit values comes with long term consequences and this practice should be scrutinized. There are compelling arguments to use implicit design methods, but doing so should be done knowing all of the options, consequences, risks, and potential long-term costs. Resist temptations for quick-fixes when it comes to data design and focus instead on best practices.

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

Is your data governance program delivering?

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

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

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

The featured speakers are:

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

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

The first segment of this series defined implicit values as ones that require additional context in order to infer an unambiguous meaning from the value. The segment went on to define how coded values are a valuable design practice that does not cause concern when each component of the implicit relationship exists within a single domain. A derivation to the coded values concept called “Overloading” was discussed as an undesirable practice where one column or record spans more than one domain. In this segment, we’ll discuss the practices of implicit defaulting and the assigning of implicit business meaning to blanks or NULL values other than the business meaning of “uh, nobody put a value here.”

From a user perspective, text fields containing a NULL or any number of blank spaces look the same. Although the casual business user cannot tell the difference between NULL and blanks, the computer treats them very differently and even changes retrieval performance based on the distinction.[1]  Suppose a data source or entry screen of a Yes/No business attribute defines that a NULL has an implicit meaning of ‘No’ because the value was not explicitly set to ‘Yes’. Since ‘No’ and NULL implicitly mean the same thing, the business cannot determine if the value was intentionally meant to be ‘No’ or if the user accidently missed data entry, but intended to select ‘Yes’. Unless somebody realizes and corrects the mistake, the value will be incorrect and nobody will ever know. Now suppose this column propagates through and ends up in an MDM system and the corporate data warehouse as Null and considered the best version of the truth. To accurately perform analyses using the column with this implied business rule, one must check for a ‘Y’ or the existence of both NULL and ‘No’. Another analysis option would be to check for a ‘Yes’ or a Not Equal to ‘Yes’ condition. In either case, a consumer of this column has to implicitly know that a NULL and ‘No’ are the same and even with this knowledge, the consumer still does not have confidence that the column was intentionally meant to be ‘No’.

Expand the above discussion to consider a lookup code value. The practice of allowing NULL code values is referred to as creating an ‘optional relationship’ within a parent (code table) and a child (reference table). Code tables are, by definition, explicit domains of allowable codes with each having a mutually-exclusive meaning for a record. Allowing NULL values for codes poses a similar ambiguity towards the data meaning. Did the user or source neglect to enter a value? Does the existence of NULL implicitly mean something else, like ‘Not Applicable’?

I can think of no positive business value to introducing ambiguity in data, ever. Moreover, there should be no compelling argument to intentionally inject ambiguity into new designs, especially in MDM or BI systems which are supposed to be reliable and pristine. When doing data integration from multiple systems, such as merging data into MDM or BI systems, the existence of NULLs and implicit values introduces several unnecessary challenges. MDM and BI systems are tasked with the collect of information from multiple sources with the intention of conforming it to a single Enterprise view. Adding implicit values to that process ensures logic will be needed in the transformation layer to conform it to the “Best Version of the Truth”. Once in the MDM Hub, more logic is necessary to transform the data back to its implicit form for each of the consuming systems.

“Oh what a tangled web we weave when first we try to cut corners and be implicit.”

In the last part of this three-part series, we will review the revelations thus far and discuss ways to both manage implicit legacy conditions and implement policies to keep from creating any additional ones.

Before you report me for animal cruelty, did you paint a mental image of me or the cat in pajamas? How do you know I wasn’t referring to the phrase used in the 1920’s to describe a person at the top of their game, Cat’s Pajamas? Would your opinion of me change if you had implicit knowledge that I was a professional photographer specializing in novelty pet shoots? How about if you knew I photographed vintage sports while wearing bed clothes or made analogies as if cars were dressed? Maybe you implicitly know I am a caretaker that lives at a zoo who carries a tranquilizer gun for safety or that I am a guide for a big-game safari hunting club? Do I need to go on? A simple factual statement like this is common in tabloid press because without proper context or additional implicit information, it is easy to reach invalid conclusions.

Computers are good at many things, but unless they are programmed to be learning machines, computers are not good at inferring context.  Moreover, computers don’t need to infer context if system designers and data owners understand how ambiguity affects their MDM and Data Governance effectiveness.

Do your business users have all the information they need to absolutely reach valid conclusions in every situation? If you said ‘Yes’ and truly understand what the term ‘implicit values’ means, you don’t need to continue reading.

Looks like all of you are still here. For the record, I was not the one that was wearing pajamas.

In Data Architecture terms, an implicit value is one that is conveyed indirectly by applying information found elsewhere. The antonym of an implicit value is an explicit one, which is a value with a self-contained purpose that exists in a single domain (which means that all values are of the same type and have the same business rules applied to them). These topics will be further discussed in this article. In practice, explicit definitions are desired over implicit ones, but there are exceptions.

This article will present the various scenarios, reasons, risks, and alternatives to having certain types of implicit values in your design and why there is literally no reason to use certain types of implicit values in MDM or BI architectures. Three classes of implicit values will be presented: Coded Values, Overloading, and Null/Default values.

Using coded values is a widely accepted and valuable relational modeling practice used to classify a value within a single domain as defined by a separate code value. For example, a GL dollar amount can be assigned to one of many GL Line Types. Two columns consisting of the GL dollar amount and the GL Line Type Code are implicitly linked together because each has no context without the other. This is an acceptable design practice because each column exists in one and only one domain: GL dollar amounts or GL Line Type Codes.

Overloaded columns or records, on the other hand, exist when one of the columns can be of a different domain based on the value of another. If the GL amount from the previous example represented a dollar amount for one GL line type and an item count for a different GL line type, the GL amount column would be considered overloaded.

This practice was done quite often in the past using COBOL Copybooks. Copybooks exist under the premise that a variable record type was an efficient way to model information within a 3GL coding environment. With the advent and advances of relational databases (and normalization standards), the copybook approach does not translate well into database tables (thank goodness).

One disadvantage of using overloaded columns is that the characteristics of a column are dictated by the superset of all the domains the column represents. This removes one of the benefits of defining a domain to explicitly enforce data quality, integrity, and definition.  For example, if an overloaded column implicitly stores either the nine characters of a Social Security Number or an account holder’s alpha-numeric 14 character Member ID, the column must be at least 14 characters in length and allow for numbers and characters. This makes it more difficult to explicitly enforce SSN formatting rules and display options because it needs some outside code or test to put the value into context.

Overloading inherently restricts a record into referencing only one type of value, which on the surface may seem like a noble goal because it guarantees mutual exclusivity. In some business cases this may never change, but in others, the intent may be short-sighted when business rules change. For instance, an overloaded column of division code and line of business code created under the premise that a record would align to only one of these classifications breaks if products realign to span multiple LOBs.

Whether the reason for using this approach was to upgrade older systems cheaply, or because a designer believed at the time that it was an innovative solution to a problem, the results are the same. Overloading makes data management more difficult, data quality harder to enforce, adds risk of incorrect use of data, and longer-term data changes become more expensive. Despite the brow-beating (or possibly because of the lack of it), designers and developers still overload columns in ERP, CRM, and custom-developed systems. Their existence in legacy systems may not be undoable without costly rework, but they have no place in good MDM or BI design (more on this later).

In the next installment of this series, we’ll discuss the use of NULLs and default values.

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.

The Master Data Management Track of this conference will be the best we’ve ever had.  There’s been a separate MDM track for five years, since I joined the Education Committee of the Oracle Applications Users Group in 2006.

This year’s COLLABORATE conference will be held in Las Vegas, Nevada at the Mandalay Bay Convention Center on April 22-26, 2012.

We’re looking for papers from new people and returning speakers, on topics like Customer MDM and Product MDM, as well as other domains of MDM. Multidomain MDM – the ability to manage many different domains of data within one MDM hub – would be a great topic.  Data governance is another hot topic that people definitely want to hear about.  Here are the sub-categories that you can use within the MDM Track:

• Best Practices
• Data Quality
• Data Governance
• External Content
• MDM Hubs
• Organizational Change

We’d like a good mix of presentations from end users and consultants. This year, we want more case studies, more real world presentations, and more examples from different industries.

To respond to the MDM Track Call for Papers before the October 17th final deadline, just click here.

VERY IMPORTANT: be sure to indicate the “Master Data Management (MDM)” track (and only that track) in your entry so it doesn’t get lost in the shuffle. When we “build the room”, it’s hard to find your submission if it’s got 4 other tracks added on to it. So just stick with the MDM track, please.

If your paper is selected, you’ll get a free conference registration.

Don’t forget – click here to submit your paper before the October 17th final deadline! 

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

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

Governance

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

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

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

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

MDM

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

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

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

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

Gray Matter

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

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

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

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

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

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

Summary

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

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

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

Rahul Kamath led off with the quote “Nothing is certain but death and taxes …” which is attributed to Ben Franklin, but went on to say that it’s also true that constant change is inevitable in our businesses. A lot of companies struggle with handling changes like new sales territories, new financial accounts or cost centers, new legal entities, etc. in their front office, back office, their own organization, and their performance management efforts.

As companies face these changes, they often have to work across process silos and varying perspectives, and be prepared to handle labor-intensive merger & acquisition efforts. In the case of M&A in particular, we need to be able to onboard new companies quickly and easily, as that in itself can create a significant competitive advantage.

And all companies need to increase their agility and to comply with the applicable regulations in their industry.

When changes occur, there’s a ripple effect – usually communicated via e-mail, spreadsheets or some other unstructured mechanism, that leads to reports being updated, databases being modified, and so on.

As a result of this, a lot of times the numbers don’t match across these various systems. The underlying structures don’t match – the manual integration we were relying on never happened.

Oracle’s Hyperion Data Relationship Management (DRM) solution allows customers to collapse separate structures into a single maintenance structure, and to streamline change management processes into one place, one process and one structure. This can reduce or eliminate the reconciliation headaches that we’re otherwise confronted with.

DRM as a product allows customers to consolidate data into the DRM repository, then reconcile and rationalize that information, as well as to govern it and then to share it back out to the rest of the enterprise.

DRM operates very well in a heterogeneous environment and embraces a lot of MDM best practices and principles. It supports use cases like Chart of Accounts management, and others like mastering Sales Territories, and other customer-led innovation areas.

DRM has been implemented at over 340 customers across a wide spectrum of industries.

At this point in the session, Rahul turned it over to the customer panelists. Alex Vlaisavljevic, Data Governance Manager at Navistar (formerly International Harvester) talked about their Finance Transformation initiative, which is how DRM was introduced to the company. Navistar’s goals were to introduce new tools, provide robust financial analytics, and create a new, simplified corporate Chart of Accounts, all implemented simultaneously. DRM became the backbone of Navistar’s Chart of Accounts governance process.

Navistar’s data governance framework has the typical three level structure: executive team, management team and working groups, with a mix of IT and business resources. The management team consists of an enterprise architect from IT and a data governance manager from the business. The working group level consists of a DRM architect, a Chart of Account process administrator, hierarchy stewards, element stewards, Chart of Account approvers, IT application subject matter experts, data governance analyst, etc.

Navistar created some custom Java forms to provide a front end for requests and approvals. That front end talks to DRM, which in turn is integrated with back end systems.

Business benefits include freeing up the financial analysts from managing Chart of Account values, allowing them to focus on analyzing business results (their real jobs).

Other benefits include a centralized Chart of Accounts governance process with integrity, consistency and quality.

Lessons learned include making sure you have an in depth understanding of how data elements are used by the business before you begin the DRM implementation. Aligning key MDM, Data Governance and DRM design principles is also critical.

Angie Couron, the Director of Data Governance at VMware, discussed how VMware, a $2.9 billion company, is using Data Relationship Management to master Sales Territories in their CRM application, which is Salesforce.com.

Their territory assignment rules are somewhat complex. Creating a centralized customer hierarchy master was critical.  VMware is using Trillium as part of their data standardization for customer data.

VMware did a quick deployment of DRM in support of their Sales Territory mastering efforts, but they made sure it fit into their overall strategy first. After the initial project, they had additional Enterprise Hierarchy Use cases mapped out to look at.

Geography, industry, and others that have no home, and others that are managed on individual laptops or shared drives were good candidates to be centralized into DRM and governed by VMware’s data governance team. Other candidates were hierarchies that exists today and need data governance and a robust platform. Other hierarchies where there is a publish/subscribe pattern are also good candidates.

Interestingly, Finance has not come to the table yet at VMware.

Enterprise Hierarchy Management (EHM) is what they call their project at VMware. Enterprise Territory Management (ETM) is a real time process that replaces over 200,000 lines of rules in the old territory assignment engine.

The standardization and enrichment is based on Dun & Bradstreet data and Trillium data quality tools.

Governance at VMware is business-driven, sitting under Field Operations and Marketing. Funding is provided by the Project Review Board (a joint group between business and IT). There is an MDM Steering Committee that provides oversight.

If you try to do too much too fast, you’ll struggle – instead, pick small areas where you can show value to the business and you’ll be able to stay successful and busy. Align yourself with something that has to get out the door in order to have a sense of urgency. Don’t try to do it yourself, choose an experienced development team.

It was interesting to hear the diversity of what customers are doing with Oracle Data Relationship Management, and to see how many of them feel strongly enough about the product that they’re willing to get up and speak publicly about their experiences with it.

Oracle MDM, both as a total portfolio and its individual “MDM for Customer Data” and “MDM for Product Data” solutions grew fastest in the market in 2010. The source was a recent Gartner report (“Forecast, MDM Worldwide 2010-2015”).

There are two common solution patterns for managing ongoing information change. It’s common to have a heterogeneous environment. Pattern 1 is to leverage a data quality tool. The downside is that if this is done in a siloed way, the benefits are not provided across the whole enterprise. If there are business process changes or you want to onboard new businesses, that can be a lot of work.

Pattern 2: Add a Hub. This provides a central point of reference between the operational and analytical sides of the business, and allows for changes and new business to be onboarded more smoothly.

Oracle’s MDM Suite allows you to handle the customer domain, including social information and trusted third party data. The supplier domain is a special case of the party. Financial, site and location mastering is available. Finally, the Product and Services domain. Product and Customer comprise about 2/3 of the market, according to Gartner.

All of our hubs are layered with Enterprise Data Quality. Product and Customer data quality needs are different. Data Relationship Management product provides cross-dimensional analysis.

Data Governance and Compliance works across all of the hubs to keep data as a trusted source for the enterprise.

All of the data that gets generated across the enterprise can now be mashed up with “big data” using Hadoop Clustering, so you can understand who are your customers, what they’re doing on the social web, who are your customer’s customers, and other “big data” questions so you can get true insights on your customers.

Enterprise data is projected to grow by about 40x over the next 10 years. For companies with rigid architectures, this will be an astounding blow. Oracle’s Enterprise Information Solution leverages Oracle’s best of breed components. In addition to Oracle’s hubs, Oracle provides data integration tools such as ETL/E-LT, Data Federation, Replication, SOA and Big Data.

Oracle now has over 1,500 customers using its MDM customers, including marquee names in every vertical industry. There’s a great ROI story around British Telecom (BT). VMware is using Data Relationship Management. Cummins is here to talk about their success in the manufacturing sector. Financial Services is a fast growing vertical for Oracle. Citibank is going live with Product Hub.

The Sunshine Act has had a big impact in the Health Sciences industry.

The key drivers for Oracle customers are:

1. Revenue generation and Customer Retention (CRM booster) – cross-sell / up-sell
2. Better operations (cost reduction) – 1^st time accurate deliveries
3. IT agility – lower operations and IT costs
4. Risk management and Compliance – law enforcement, regulatory compliance and privacy

MDM benefits can be calculated using Oracle’s proprietary ROI tool, available through Oracle’s sales teams.

Oracle customers want a spectrum ranging from complete integrated solutions to complete freedom of choice, with modular components.

Oracle has invested heavily in the MDM space over the past five years. 74% of Oracle’s customers are on the most recent two releases.

Strategy and product updates include:

• Fusion MDM 11g R1 is now in General Availability, including full cloud support. The first release is focused on Customer and Product domains. In the last five years or so, Oracle has been aligning its Siebel and E-Business Suite MDM customers towards Fusion MDM.
• There are purpose-built Hubs on top of a common MDM platform, with Master Data Objects, common MDM components and services, and common infrastructure components and services.

The workflow is a standards-based Java workflow. Even the UIs are extensible purely by end users.

Oracle Enterprise Data Quality, the combination of Silver Creek for Product Data Quality and Datanomic for Customer Data Quality, is a specialized data quality solution for Customer, Product, Location, and Compliance business problems.

On the broader stage, the OEM data quality offering from Informatica is still available.

Oracle’s Enterprise Data Governance solution, allows you to define your policies, monitor compliance to them, and resolve issues that crop up over time.

Oracle’s Customer Hub 8.2+ (Universal Customer Master or UCM) has new functionality to support massively scalable hubs, enhanced data quality and usability, MDM-aware and Social MDM and increased Verticalization.

A benchmark that Oracle has run with an Australian bank showed more than 4x the throughput (using a half rack of Oracle’s Exadata and Exalogic hardware), and now supports 14.4 million real-time transactions per hour, compared to commodity hardware, assuming 90% reads and 10% writes on a 250 million customer database.

The E-Business Suite based hubs (Customer, Product, Supplier and Site) on Release 12.x are being positioned to align better with Fusion MDM.

Data Relationship Management 11.1.2.1 has new features to manage and sync via out-of-the-box integration across multiple EBS R12 instances.

Oracle’s integrations using Application Integration Architecture has been upgraded to 11g Fusion Middleware, and new integrations for both Customer Hub and Product hub are available.

Oracle’s vertical industry strategy covers communications & media, retail, public sector and higher education, life sciences and financial services.

The public sector vertical now supports Health Insurance Exchanges. Another one in this area is Citizen Services.

In life sciences, there is an Aggregate Spend Compliance solution, to assist in complying with various states’ compliance regulations in the pharmaceutical industry. This solution leverages Advantage MS data for information on doctors and health care providers.

In the oil & gas industry, Oracle has verticalized the Site Hub to become a well head management solution.

Oracle has also integrated its ATG e-commerce acquisition, to include customer preferences into the e-commerce tool.

Oracle has a group of 70+ customers on its MDM Strategy Council / Customer Advisory Board.

Oracle now has an ecosystem of 75 partners global providing global and regional systems integration expertise.

Oracle’s MDM investment and differentiation areas include the core platform, industries, business process management and integration, governance and content, making solutions “enterprise grade”, and providing thought leadership.

Oracle is committed to ongoing enhancements to all of its various MDM solutions, and will continue to make sure its solutions are enterprise grade, industry specific, and massively scalable. And Oracle as a result is experiencing the fastest growth.

Balaje Govindan, an IT Director of Data and Content at Cummins Inc., presented a case study for how Cummins has used Oracle MDM. Cummins had $13.2 billion in 2010, from 190 countries and territories, with 40,000 employees.

In its Future State, Cummins expects to have a series of web-based portals, with user-based access control, with common core applications (such as Engineering, PLM, Collaboration, Purchasing, Supply Chain, Manufacturing, Service, etc.), using middleware, business intelligence and a data integration layer connecting its multiple transactional and MDM databases and its enterprise data warehouse.

The Current State diagram, on the other hand, is a spaghetti diagram of point-to-point batch interfaces, multiple versions and instances of legacy ERP and other applications, and no significant MDM or data quality capabilities today.

The Enterprise Information Management in Cummins’ future state features shared ERP applications, with middleware connecting Finance, Manufacturing and Supply Chain applications to an MDM foundation.

MDM business drivers included:

• single source of master data
  • Better business decisions
  • Increased synergy
  • Uniform communications
  • Risk management
  • Data security, privacy, and regulatory compliance
• Operational efficiency improvements
  • Global logistics expansion
  • Reduction in redundancy in manual efforts
• Continuous data quality improvement as data quality processes are embedded upstream rather than downstream

Cummins’ future state environment includes Oracle Product Hub, Supplier Hub, Finance Hub (Oracle DRM), Party Hub (Oracle UCM for Suppliers and Customers), with Fusion Middleware as a service layer and a strong data quality tool set including Oracle Product Data Quality (formerly Silver Creek) and Oracle Data Quality (OEM solution from Informatica, including Address Doctor).

Cummins used a Four Pillar approach: Data (Information), Process, Governance and Technology (very similar to the Four Dimensional approach that Hub Designs recommends).

Cummins’ journey includes Product Hub, with 460,000 items and bills of material, Customer Hub (UCM) with 70,000 customers live (2 million more to follow), Supplier Master has a pilot implementation in progress (going live in Q2 2012, with 75,000 suppliers in scope), and Finance Hub (DRM) also live.

Key take aways include:

• Have a clear end goal in mind
• Engage business stakeholders early
• Focus on tangible business deliverables and ROI
• Build your strategy and roadmap with both business and IT
• Build your technical foundation capability in advance of your business deliverable projects
• Create a business-led data governance team progressively with clear roles and decision rights
• Partner actively with Oracle
• Remember MDM is a journey, not a short term project!

It was good to hear Cummins share their case study after hearing Oracle’s 2011 / 2012 MDM strategy and product roadmap. It always helps to have a customer explain how they’ve implemented a solution in order to “keep it real”.

“MDM should be a business driven program” is the mantra we hear time and time again. And while that is the right prevailing wisdom, doesn’t it seem that there is far more articulation about the technical elements of MDM than about the business elements?

So often I have seen MDM publications and presentations start with the “should be business driven” perspective but then quickly shift to covering the technical elements of MDM, topics related to architecture, data models, data integration, metadata management, match logic, consolidation, synchronization, application services, and so on.

Yes, those all are important elements in the MDM equation, but this over-abundance of technical insight can be frustrating for those seeking practical knowledge and guidance for the business planning of an MDM program. After all, without a strong business presence, MDM can’t develop into a core competency throughout the company. So why, in comparison, is so little insight provided about the business side of the equation?

Actually, it’s easy to understand this situation. The plethora of technical insight is a byproduct of the influence that IT and vendors have on the MDM market. And that’s not suggesting that business organizations don’t care to promote their MDM practices, it’s just that there is much more uniqueness and latency involved with getting these business components established, and these dynamics are harder to articulate.

Let’s take a closer look at these influences and dynamics.

The call for MDM

The initial need and sponsorship for an MDM initiative often emerges from the IT and/or analytical groups in a company. These groups usually exist separately or on the periphery of the business. The IT and analytical areas responsible for activities such as system integration, data migration, information management, data warehousing, business intelligence and reporting will typically be the first to expose where poor data quality and lack of data governance is creating project delivery delays, data management problems, integration issues, distrust of the data, and reporting problems.

Therefore, it’s understandable that these groups become initial proponents of MDM solutions. And while the root cause for many of these data problems lies in front-end business practices and data entry points, the IT and analytical groups are most directly impacted and naturally tend to implement their own back-end corrective actions.

At some point these ongoing problems and workarounds become a tangled mess, and that situation becomes a catalyst for seeking an MDM solution. Current state issues, improvement opportunities, and cost/benefit projections cited in MDM proposals are usually centered on correcting these legacy issues, improving data governance and information management practices, and eliminating the workaround overhead. In other cases, MDM programs often emerge when legacy applications are being replaced with more integrated platforms such as business application suites, data hubs, and enterprise warehouses where IT planning and activity is already underway.

Product vendor and consulting influence

Because of the large market opportunity and competition among MDM product vendors and consulting firms, it is expected that they will have a significant influence on the MDM information being presented. Technology and consulting help should always be factored into an MDM assessment and implementation plan. Although the overall impact and practical use of both can often be overstated, good technology and consulting help applied in the right places can definitely advance MDM capability and reach.

But many other aspects of implementing MDM involve new and unique business practices, business context, and process management where technology and consulting help will only have limited application, if any.

MDM is as much about people and process as it is about technology, which is why product vendors are increasingly looking at improving their business consulting practices or consulting partnerships as a competitive advantage. Over time this trend should help bring a better balance of information and practical insight for the planning and implementation of MDM.

Discovery and Analysis

At the onset of an MDM initiative, a “Discovery and Analysis” phase is conducted to fully detail the issues, root causes, business and system impacts, and opportunities for improvement. This discovery and analytical phase is often led by IT or an analytical team, if not a consulting group. Business leads should be actively involved in this phase, but specifically how and where business groups will be needed to drive and support MDM plans will largely depend on what priorities and direction come out of this discovery and analysis work. And where the business engagement needs are identified, the business groups will often need time to plan, budget, and prepare for these activities.

Implementing process improvements and driving data governance activity can be new or disruptive territory for business organizations. Many MDM programs do not have sufficient budgets to cover these business area needs, therefore the implementation of these business elements can take some time.

MDM job roles

IT groups already have most of the necessary job roles and skill sets needed (e.g. analysts, architects, project managers, programmers, data miners, database administrators) to initiate and support the technical aspects of MDM. The business roles needed within a MDM program (e.g. data governance leads, data stewards, process analysts, quality managers, data access gatekeepers) often do not already exist as formal job roles. Consequently these roles either have to be assigned to existing resources that have other job responsibilities and/or created through new hires, job transfers, or contracted positions which can require budget allocation and also take time to fulfill. Therefore it’s common to see IT and analytical related activity initiated early on while the business roles and needs are being addressed.

Maturity models

In MDM and data governance maturity models, we typically see the advanced levels of maturity defined using terms such as Managed, Optimized, Proactive, Advanced, or Transformational. But in many of these models, those levels are characterized by more system and analytical orientated achievements, related to systems integration, establishing a system of record, business process automation, using SOA/SaaS, quality monitoring, delivering trusted analytics and KPIs, and so on.

The business area maturity needs and milestones — associated with data governance, data life cycle management, and quality control — are much less apparent in these maturity models.

Granted, much of the program development and maturity on the business side of a MDM program is going to be tied to unique business practices that are harder to generalize in a high-level maturity model. Therefore it often takes some digging in MDM and data governance forums or finding business case studies to gain good insight on how and where the business events and the maturity of business practices have occurred in a MDM implementation.

A developing dynamic

So even though it is critical for business to be involved and provide leadership in an MDM program, defining, articulating, and achieving that is likely to be a developing dynamic that spawns from IT and analytical underpinnings where product vendors and consulting firms are also well entrenched. As more companies launch MDM initiatives and develop their MDM core competencies across their business model, we can expect to see increasing amounts of business insight and best practice information made available that will express how and where business roles and business practices evolved in MDM programs. I look forward to that.

Mark Allen is co-author of the book “Master Data Management in Practice: Achieving True Customer MDM”. Mark has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and with leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.

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.

The Master Data Management Track of this conference will be the best we’ve ever had.  There’s been a separate MDM track for five years, since I joined the Education Committee of the Oracle Applications Users Group in 2006.

This year’s COLLABORATE conference will be held in Las Vegas, Nevada at the Mandalay Bay Convention Center on April 22-26, 2012.

We’re looking for papers from new people and returning speakers, on topics like Customer MDM and Product MDM, as well as other domains of MDM. Multidomain MDM – the ability to manage many different domains of data within one MDM hub – would be a great topic.  Data governance is another hot topic that people definitely want to hear about.  Here are the sub-categories that you can use within the MDM Track:

• Best Practices
• Data Quality
• Data Governance
• External Content
• MDM Hubs
• Organizational Change

We’d like a good mix of presentations from end users and consultants. This year, we want more case studies, more real world presentations, and more examples from different industries.

To respond to the MDM Track Call for Papers before the October 14th deadline, just click here.

VERY IMPORTANT: be sure to indicate the “Master Data Management (MDM)” track (and only that track) in your entry so it doesn’t get lost in the shuffle. When we “build the room”, it’s hard to find your submission if it’s got 4 other tracks added on to it. So just stick with the MDM track, please.

If your paper is selected, you’ll get a free conference registration.

Don’t forget – click here to submit your paper before the October 14th deadline! 

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

We’ve served almost 30 clients on three continents (North America, Europe and Africa), in industries such as financial services, insurance, telecommunications, software, high tech, information services, payroll, life sciences, health insurance, and medical devices.

Although we’ve had our ups and downs, we’ve managed to grow even during the toughest economic times of the past eighty years. Over the last four quarters, revenue has grown an average of 100% per quarter. It hasn’t hurt that the master data management (MDM) space has been doing well even in the teeth of the turbulent economy.

We currently have two distinct practices:

Our Consulting & Systems Integration practice focuses on developing and delivering high value MDM and data governance strategies. We focus on:

• Education
• Readiness Assessment
• Strategic Roadmap Development
• Preliminary Software Selection
• Business Case Creation
• Data Governance Formation

Our unique approach allows clients to develop their MDM strategy and create their data governance organization in parallel.

Our Thought Leadership practice develops high quality content to help MDM software vendors reach their target audiences:

• Objective, well researched white papers
• Thought provoking, high attendance webinars
• Guest articles on other organizations’ blogs
• Keynotes at conferences and dinners
• Engagement through social media
• Distributing content through our specialized network

I’m still a volunteer on the Education Committee of the Oracle Application Users Group, which is a robust users group that is completely independent of Oracle Corporation. I’ve been involved in the group as a whole for over 15 years now, and have been on the Education Committee for more than five years.

The Call for Papers for the 2012 COLLABORATE conference is open, and I am starting to plan the MDM track of the conference.

We are going to make this conference – to be held in Las Vegas, Nevada, USA at the Mandalay Bay Convention Center on April 22-26, 2012 – our best ever. We are looking for papers on Customer Master Data Management (MDM) and Product MDM, as well as other domains of MDM as well. Multidomain MDM – the ability to manage several different domains of data within one MDM hub – is a popular topic, as is anything to do with data governance.

We’re looking for real world success stories, with presentations from end users at deploying companies as well as from consultants who have been part of MDM and data governance projects.

Last year, we had 32 different MDM track presentations, with titles such as:

• Managing Global Customer Data Using Oracle Data Quality Management and Party Merge – One Year Later, by Mike Foxcroft and Nick Soh
• MDM Case Study: Making Information Management the Foundation of the Future, by William McKnight
• The Strategic Nature of MDM, by David Butler of Oracle
• MDM Best Practices and Implementation Approaches, by Mani Kumar Manda
• Oracle MDM Strategy and Roadmap, by Manoj Tahiliani of Oracle

But this year, we want to go above and beyond last year. We want bigger and better case studies, more real world / end user presentations, different examples from different industries. Share what you’ve learned with your fellow practitioners in the MDM Community.

To respond to the MDM Track Call for Papers before the October 14th deadline, just click here. Be sure to indicate the MDM Track in your entry so it doesn’t get lost in the shuffle. If your paper is selected, you’ll get a free conference registration.

Don’t forget – click here to submit your paper before the October 14th deadline! 

Data governance advocates could likely tack and adjust successfully to the IT Reformation . With business units taking on the responsibility of acquiring their own technology solutions, users might be among the first to assume accountability for data quality.  (It’s their system; they would come to appreciate first-hand how critical it is to have good data hygiene from its inception.)  And, the IT department would still be there, “ensuring accurate and safe data, integrating business processes and promoting collaboration.”

But what if business users and their IT compatriots can’t count on business technologies being universally open and accessible?  What if elements of these applications are made non-interoperable by design?  It would be harder for enterprises to establish and maintain technology-enabled relationships with their partners and customers in an environment of walled gardens, platform-specific apps, and other hermit kingdoms.

I’m not suggesting that business units are going to start using Facebook for their application platform.  But some might be attracted to applications that reflect the belief that a uniform user experience is more important than an optimal degree of openness.  Too many such choices would make it difficult for a post-Reformation IT department to ensure information and applications work together both internally and with business partners and customers.

It’s true that “we’ve evolved to a world where consumer tech like Facebook and the iPhone sets the bar for what all IT should look like.” It’s equally true that these new technologies “will be simple on the outside and unfathomably complicated under the hood.”

Conclusion

I am not advocating resistance to what appears to be inevitable change.  But I believe that we in the data governance disciplines, on the business side, the IT side, and the vendor side, need to take an active role in managing this (d)evolution.

To CIOs and other IT-savvy leaders, Forrester’s Ted Schadler offers this blunt advice:

You can watch and wait until marketing and customer service and e-commerce teams grit their teeth in frustration and spend their technology dollars on point solutions from vendors. Or because you are IT and have the broadest view of the technology requirements across all customer devices, channels and touch points, you can call out the Splinternet as a challenge and an opportunity. Then go orchestrate the resources and technology to deliver the best customer experience possible over the Splinternet.

As a member of the “vendor chapter” of the data governance fraternity, I am also obviously not opposed to innovations that allow competitors to differentiate themselves.  Creating unique, customer-focused, often disruptive capabilities is essential for commercial success.

But “standardization liberates people,” to quote Ashley Cook, operations director with Best Buy Europe. And for that reason, the examples given in the Wired article on the death of the Web – which claims that oligopoly naturally follows standardization – are somewhat misleading.

Yes, standardization allowed railroads and telephone systems to buy up smaller competitors.  But the resulting holding companies didn’t then re-set the track gauges or invent a new kind of switchboard to un-standardize their systems and lock their customers into a “superior user experience.”  It was only the fact that everyone’s rail and voice traffic could run on everyone else’s tracks and wires that made these consolidations practicable or even logical.

I know that vendors in the data governance space are aware of the need to ensure their solutions are able to “play nice” with others, especially as we add mobile apps and the cloud to our portfolio of capabilities. Business and IT leaders on the enterprise side are certainly aware of these issues at a high level.

My concern is that these issues need to be viewed and discussed in the context of problems that may arise from the disintermediation of the IT function on the one hand and the devolution of business technologies into closed channels on the other.

I’m confident that business leaders, IT leaders and technology vendors can rise to meet these challenges to governing, managing, and consuming mission-critical information.  To that end, I invite you to comment, criticize and correct in the discussion section below.

Frank Johnson has more than 25 years’ experience in information technology marketing. He is part of the marketing communications and analysis team at Enterworks Inc., a company that offers solutions for acquiring, managing, and publishing master data, digital assets, and related product content.  He is the lead blogger at Enterworks’ Multichannel Content Blog. 

Either of the dynamics mentioned in yesterday’s article (the The IT Reformation or the Splinternet) by themselves would pose enough challenges to sound data governance. Together, they make the challenges worse by pulling the advocates of data governance — among business units, IT departments and vendors — in conflicting directions.

That’s because there is a contradiction inherent in business units empowering themselves by acquiring tools that are less and less able to work together or share information in a meaningful (read: semantic) way.  Trying to accommodate both dynamics could create even more obstacles to delivering solutions that support the needs of the enterprise as a whole.

Some of these obstacles include:

Data governance will be harder to enforce and/or encourage

We were treated this month to a delightful “Star Wars” debate between Rob “Darth” Karel of Forrester and Jim “OCDQ-Wan” Harris of the Obsessive Compulsive Data Quality blog.  Karel took the position of the Evil Empire centrally enforcing data governance through draconian measures.  Harris took the position of the Rebel Alliance, leading guerrilla data governance from the bottom up.

The authors were acting as devil’s advocates to show that both approaches are needed in balance.  And I think all data governance professionals would agree with Harris, that “Data governance reveals how truly interconnected and interdependent the organization is.”  But because it is, any approach to data governance is impeded where business units are free to acquire their own closed or semi-closed solutions absent a coordinating vision for the enterprise.

In such an environment, it would be difficult to build a Death Star that centrally enforces, or to create a rebel confederation that organically fosters, data governance among every business unit.  And the task of making data governance technically feasible among such disparate applications would also be that much harder for IT personnel.

Application integration will be more difficult to achieve

People concerned with data governance have already been fretting that cloud-based applications might grow into a whole ‘nother species of isolated stovepipe.  Such a concern would be especially relevant when the application has been sourced and acquired by a business unit rather than through IT.

Data governance practitioners should want to ensure that such tools and applications would be part of the data governance ecosystem and be required to use master data, properly controlled and maintained according to minimum standards of governance.  (For example, see Gartner’s concept of “MDM-aware” applications.)

Closed or propriety applications may not be as much of a problem in business-to-business environments thanks to XML business standards and other open or heterogeneous approaches to application integration.   Still, they could at minimum slow efforts at creating bridges among business applications.

Master data repositories will be harder to create and deploy

Data integration is “a critical enabler for a complex MDM architecture,” says Forrester’s Rob Karel, and as such is a foundational part of aggregating and managing master data.  As with Maslow’s hierarchy of needs, if you can’t meet the basics like food and shelter, you can’t aspire to achieve higher goals like self-actualization.

A new survey done for BeyeNetwork by data integration vendor Syncsort reveals that enterprises continue to struggle with basic data integration within the enterprise, to say nothing of integrating data from the cloud or from walled applications.  IT Business Edge blogger Michael Vizard calls basic data integration issues the Achilles Heel for many IT organizations.

In a slide presentation of the survey results, he adds that “the fundamentals of data integration are still a big enough issue in most IT organizations to thwart the achievement of strategic business goals.”  The growth of cloud, mobile, social, and closed applications will only add to the strain of integrating data for master data management repositories.

Dreams of the Semantic Web will be postponed

There is some trepidation about data governance challenges posed by the Semantic Web (a.k.a. Web 3.0).  For all that, I believe most community professionals are intrigued and challenged (in a constructive way) by its potential for creating an environment where applications “will perform complex tasks that previously required human capabilities, such as understanding and reasoning — and will accomplish those tasks at enormous scale and efficiency.”

However, as stated by Sir Tim Berners-Lee and his co-authors in the urtext for Web 3.0:

The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation [emphasis added].

The move toward closed applications runs counter to this vision of people, systems and information working in closer cooperation.  It will raise completely new and higher barriers to the kind of agility, access and integration that both The Semantic Web and sound data governance call for.

Part 3 concludes this series

Frank Johnson has more than 25 years’ experience in information technology marketing. He is part of the marketing communications and analysis team at Enterworks Inc., a company that offers solutions for acquiring, managing, and publishing master data, digital assets, and related product content.  He is the lead blogger at Enterworks’ Multichannel Content Blog. 

Introduction

The practice of data governance is in a precarious position as a result of two paradoxical dynamics at work in business technology.

The first dynamic is “the IT Reformation” — the trend toward business units acquiring their own technology solutions rather than relying on or even involving IT.

The second dynamic is known as “The Splinternet” — the devolution of the Internet (and Internet applications) into proprietary fiefdoms of walled gardens and closed applications.

These dynamics have a great number of facets and drivers that go beyond the scope of this article.  So I will just briefly explain the background of the IT Reformation and the Splinternet, and then review some of the issues where I believe the tension between them threatens to slow the pace of achieving sound data governance.

Business and technology leaders, vendors, consultants and others involved in the interrelated disciplines of data governance, such as master data management, data quality, business intelligence, and business process management, should be aware of this threat and begin planning to moderate its effects.

At the end, I hope you’ll add your own thoughts in the “comments” section to keep the conversation going.

The IT Reformation

 “Why do I know more about what my high school girlfriend had for dinner than what is going on in my organization?”

That not-so-tongue-in-cheek question, from a recent AIIM presentation, captures the sense of discontent with the business technology status quo that’s now becoming more prevalent among enterprises.

This discontent first found expression through individual knowledge workers bypassing IT by using consumer technologies — mobile, social and cloud-based — to get their work done in a more interactive and collaborative way.  A powerful motive for using these tools is that users can get them freely and without waiting for assistance from the IT department.

That breakthrough has helped liberate higher-level business decision-makers to acquire point and departmental solutions without IT’s blessing or even its participation.  According to a Forrester survey, 65 percent of business leaders have budgets to buy business technology solutions without involving IT. Another survey reported in Network World reveals more about this “grassroots rebellion”:

In the survey, 20% of those responding said they had actually gone around their IT department to provision cloud services. Of that subset, 61% said it was easier to provision the services themselves, and 50% said it takes too long to go through IT.

I call this trend “the IT Reformation” because, in its most radical form, it envisions (if not actually advocates) doing away with the “priesthood” of the CIO and the IT department.  The meme of the “death of the CIO” is actually quite old, but its most recent incarnation is gaining traction as industry analysts emphasize the need for IT departments to get with the program or get left behind in terms of value and relevance to the organization.

Progressive CIOs and thought leaders aren’t clamoring for IT to re-assert its “rightful” authoritative control.  Instead, they’re advocating that IT work proactively with business users, to address their need for faster, more flexible and more innovative solutions.

The Splinternet

At the same time, information technologies are being balkanized into multiple channels, platforms, and applications. The term for this is “the Splinternet” – originally used to describe restrictions on access to Internet applications in different countries, but today also meaning the fragmentation of the Internet from the perspective of technologies and applications.

Writing for e-commerce and Internet marketing audiences, Groundswell co-author Josh Bernoff explained some of the fallout in a January 2010 blog post:

Choose your devices carefully — investments in one cannot be transferred easily to others if you make a mistake … Just realize that you’re leaving the comfy environment of the Web behind — along with all the tools you’ve grown dependent on — as you embrace the new platforms.

Two months earlier, O’Reilly Media founder Tim O’Reilly had written:

We’re heading into a war for control of the web. And in the end, it’s more than that, it’s a war against the web as an interoperable platform. Instead, we’re facing the prospect of Facebook as the platform, Apple as the platform, Google as the platform, Amazon as the platform, where big companies slug it out until one is king of the hill.

Chris Anderson explained in a widely read August 2010 Wired article that “the [HTML] content you see in your browser … accounts for less than a quarter of the traffic on the Internet,” and that the majority of Internet traffic is made up of peer-to-peer file transfers, e-mail, VPNs, VoIP, video streaming, API communications and others.  He also noted that “Many of the newer Net applications are closed, often proprietary, networks [emphasis added].”

The coming of the Splinternet is also being emphasized at Forrester, as a wake-up call rather than as either a necessarily positive or negative development.  Forrester CEO George Colony offers a version of this future called the “App Internet” – an environment that will supersede the pure cloud model by taking advantage of the processing power of tablets and smart phones as well as the ubiquity of the Internet.

However, this ideal environment assumes that all issues concerning compatibility and interoperability among Internet apps and clouds have been solved.  Vint Cerf, the “Father of the Internet” and Google’s chief Internet evangelist, projected a five-year timeframe for a hypothetical “Intercloud” in this brief but compelling video interview in January 2010.

In the meantime, there are issues that need to be identified and addressed.

Part 2 continues here

Frank Johnson has more than 25 years’ experience in information technology marketing. He is part of the marketing communications and analysis team at Enterworks Inc., a company that offers solutions for acquiring, managing, and publishing master data, digital assets, and related product content.  He is the lead blogger at Enterworks’ Multichannel Content Blog. 

In recent months, the “gamification” of business applications has become a hot topic. Gamification seeks to incorporate game mechanics into software applications for, say, CRM and ERP. The goal is not to literally make MDM a game but to instead apply game mechanics to MDM and data quality.

Gamifying MDM fosters participation in managing data quality in business applications. People love playing computer games. Few would say the same about entering data or taking care of data quality in CRM and ERP systems.

Online discussions, blogs, webinars, conferences and articles regularly discuss how to get people excited about data quality. Gamfication may be just the cure for curating data on customers, products and parts, suppliers and employees.

Gamification is all about software and data adoption. Naturally, if we are using enterprise software, we’re using the data. If we’re using data, it must reflect reality and so offer value. People like to use applications with high quality data. Someone said “Data quality is about data use. If data is not used, it won’t be any good.” If so, then gamification of MDM is a no-brainer.

Three ways to gamify MDM are

1. embed gamified MDM gadgets in software
2. gamify software functions
3. gamify MDM software itself

With the recent movement towards making applications “MDM-aware,” gamification may be a good way to embed MDM functionality into other enterprise applications.

Here’s how Software Advice envisions an embedded MDM-type dashboard in an SFA application:

An MDM dashboard in a CRM application can show the number of duplicates and data completeness by user and even award points based on quality levels. Applying game mechanics can provide real-time data quality levels, show data quality progress and even make managing data more fun.

Directly gamifying business and MDM application functionality are two other ways to accomplish key MDM objectives. A variety of game mechanics are applicable to MDM and data quality.

Achievement levels, points and leaderboards are types of gamification mechanics that can help drive data quality in software. Points can be awarded to users of applications where they can view their rankings and data quality achievement level.

While MDM dashboards employ some game dynamics, operational components of MDM software can also benefit from them.

Multiple-player game dynamics can be used to collaborate on data quality and foster a culture of community data stewardship.

Some are questioning the hullabaloo over gamifying enterprise applications. After all, computer games have been around for a while. Any pinball wizard from the 1970’s can testify that “incentivizing” is not particularly new and innovative. But the application of gamification goals, specifically to engage users of business applications in data quality, is new and promising.

Fear that gamifying software will create a distraction is unwarranted if the game mechanics are well-designed. The goal of MDM gamifcation is to ease, not hinder, participation in attending to data quality.

Gamifying MDM involves understanding what motivates software and data users and mapping those motivations to the game mechanic. MDM gamification can engage software users in initial data capture and ongoing data enrichment, data monitoring and data management.

Peter Perera is the Founder of The Perera Group, a CRM and MDM consulting firm working with organizations to increase customer data usability and value and to profitably boost revenue generating performance.

I’ve been asked this question many times: why is implementing an MDM solution so difficult? The short answer is MDM includes technical and business challenges, and encompasses a set of disciplines that are pervasive to the organization. But in this article, I’d like to focus on one particular aspect: establishing a system of record (SOR).

Let’s first take a look at a typical IT infrastructure in a large organization. Figure 1 depicts a simplified scenario.

Figure 1 – Typical IT infrastructure in a large organization

The main points I’d like to make here are:

• Each line of business (LOB) has its own data source, which includes transactional and non-transactional (i.e. master data) information.
• The separate data systems typically lead to disparate and fragmented information.
• The need for data sharing soon arises, and organizations start to integrate information either directly (database links, direct data access, and so on) or via an Enterprise Service Bus (ESB) and underlying Service Oriented Architecture (SOA).

I’m sure you noticed my diagram is really simplified. As you probably have experienced in your organization, this becomes a big mess as companies grow and data systems increase in size and complexity.

Also, SOA services typically grow slowly and unevenly. At some point, either IT and/or business realizes the underlying architecture is unsustainable, and decides to implement an MDM hub to avoid data disparity, duplication and fragmentation and improve data quality, data integration, and data distribution.

Figure 2 depicts one of the many ways data can be integrated into an MDM hub. I won’t get into the merits of which use case of MDM is being implemented, such as Analytical, Operational or Enterprise. As I said previously, I want to stay focused on one particular aspect, the System of Record.

Figure 2 – Data migration into a Master Data hub

Now that master data is in a single place, the many application systems in each LOB can be leveraged to use the hub as the “single source of truth,” as depicted in Figure 3. Needless to say, this is one of many possible configurations.

Figure 3 – A possible MDM hub configuration

Unsurprisingly, the above looks simpler than it really is. Let’s talk about some of the challenges.

The data migration effort offers plenty of technical challenges. A data migration project is typically done in phases. Not all systems are migrated at once, and sometimes, even a single system is not migrated entirely in a single phase. Your data hub becomes another data source, and worse, must be kept in sync with the sources still in operation.

But in addition to all technical challenges, we have the business challenge. What data source is the System of Record (SOR)? During the migration itself, that question is important, because if you have disparate information across the many sources being migrated, which one trumps the others?

Each LOB will say their data is better, and will want their information to prevail. That’s when a data governance office is important, and will help solve the many conflicts that are bound to happen.

And a single source is not necessarily the SOR for all data being converted, which increases the challenge.

Even if a SOR is clearly established during data migration, timing may be an issue as well. At some point, you obviously want to make the MDM hub the System of Record. But how do you manage the intermediate phases? An intermediate state may include many sources still operational, and in need of a live interface to maintain data consistency.

Remember, not everything is migrated at once. That’s clearly a challenge that can get quite complex, especially if the interface is bi-directional.

Once migration is completed, rewriting all your existing systems to use the hub can be expensive and unfeasible, especially if you use COTS products. Custom interfaces are sometimes unavoidable.

Here are some tips to remember:

• Start a data governance program early. You don’t need an MDM initiative to have a data governance body. The earlier you start the cooperation between the many LOB’s, the easier it will be to integrate their data later, and establish which system is the SOR at any given moment.
• The above is also true for data quality. Data quality is just one of many MDM disciplines, but can and should exist even if you’re not doing a full MDM yet. The cleaner your existing data sources are, the easier it will be to integrate them later into a single hub. Plus, data with higher quality facilitates the determination of which source is more appropriate to be the SOR.
• Once integration starts, clearly establish which system is the SOR for a given entity and/or set of information. This definition is critical to avoid confusion and facilitate entity resolution. As data is migrated, clearly define when the SOR transition will occur.
• Data maintenance should be done on the SOR only. Avoid bi-directional interfaces. Synchronizing information that is modified in multiple places is a nightmare, and should be eliminated if possible.
• IT and business must work closely together. Establishing a SOR is a combination of technical feasibility along with properly supporting all business processes. Rarely will one side be able to define the SOR without consulting the other side.

An MDM program requires a lot of planning and coordination, and it is not a single project. It is an ongoing program that needs constant collaboration between the many LOBs and IT. Having a clearly established SOR for every single attribute, at all times, will certainly minimize issues.

Dalton Cervo is a Senior Solutions Consultant at DataFlux, helping organizations in the areas of data quality, data integration, and MDM. Prior to DataFlux, Dalton served as the Data Quality Lead for the customer data domain throughout the planning and implementation of Sun Microsystem’s enterprise customer data hub. 

Combining Forces to Better Answer Business Needs

Data governance can be seen as formalized policies, practices and processes set up to manage voluminous data assets across enterprises. Data governance also sits on an important growing convergence that encompasses multiple, and frequently separate, disciplines: data quality, data integration, master data management (MDM), business process management (BPM), business intelligence (BI) and analytics.

The solutions surrounding the management of information, data and intelligence are emerging from artificial silos to acknowledge the greater overlap and interrelationships of these technologies and practices. Deliberate initiatives to tighten up the convergence of these solutions will not only improve the better overall functioning of all of these solutions, but they’ll help both IT and business users see how it all works together.

A greatly beneficial result should be the elimination of duplicate demands on business users and IT for implementing and managing these systems.

Forrester’s Rob Karel had this to say on aligning Business Process and Data Governance initiatives:

Data governance is not – and should never have been – about the data.

High-quality and trustworthy data sitting in some repository somewhere does not in fact increase revenue, reduce risk, improve operational efficiencies, or strategically differentiate any organization from its competitors. It’s only when this trusted data can be delivered and consumed within the most critical business processes and decisions that run your business that these business outcomes can become reality.

So what is data governance all about? It’s all about business process, of course.

Let’s add this note to Karel’s assessment: business process is about optimizing the Business.

The current state of the increasing relationships between Data Governance, MDM, BPM, BI / Analytics (as well as DQ and DI) is also the story of the teaming up of business users and IT as collaborative partners in doing the work that help businesses meet strategic goals, bring value to customers, and add to competitiveness.

Both sides of the story must start with the business problems and the jobs to be done, plus the desired outcomes and benefits. Then decisions must be made regarding the role to be played by the software solutions to be implemented. Starting with the business also encourages the exploration and creation of the specific business cases that reflect needs and requirements. With those business cases defined, monitoring outcomes of data governance, BPM, BI, etc., should have a clear basis.

While business processes are a major focus for strategies around data governance, BI and BPM, data still retains a significant role as a strategic asset that enterprises can use to differentiate themselves. These two entities (process and data) must be accorded respect when developing interrelated approaches that incorporate all of these solutions. Just as these solutions are best when in synch with one another, so must the enterprise itself work with these solutions across departments and diverse teams. For business and intelligence processes to yield useful, timely and accurate results, the underlying data must be trustworthy.

Knocking down the Silos

Data, information and content saturate most enterprises, so business users must become much more directly involved in creating and managing the overall solution for handling these vital resources. Business people usually hold the key to the context for data and processes, as well as future ways of using the data.

The integrated components of MDM / data governance, BI / analytics, and BPM need to deliver real results to business users but are also highly dependent on the participation of business users to incorporate reality and provide on-target solutions.

True collaboration between business and IT teams starts with requirements, results, procedures, and then leads to collaborative work on joint projects. Such collaboration fosters reuse, reduces duplication of effort and processes, and builds a network of trust between business and IT staff that is aligned with how systems really need to support key business objectives, initiatives and future strategic direction.

Commonality also crosses the business drivers for data governance, MDM, BI, and BPM where key benefit areas consist of growing revenue, cost efficiency, different levels of agility, and compliance. Efforts should provide improvements for:

• Faster, more accurate decision-making, including real-time intelligence
• Identifying and engendering new markets, new products, new customers
• Enhancing and supporting customer relationships and customer service
• Operational procedures
• Customer cross-selling / up-selling
• Ease of compliance, audits, and risk management

Rajan Chandras said in Data Gaps Plague Process Initiatives:

The genesis of these types of initiatives is often very different. BPM is undertaken when organizations find themselves beset with process shortcomings, and with the primary purpose of better understanding, improving and integrating business processes. Data governance initiatives, on the other hand, are usually justified by shortcomings in data quality, consistency and integrity.

Then, data governance is often closely intertwined with master data management, and thus organized alongside important “master” business data entities — customer, product, organization and such.

That said, Rob Karel, Forrester analyst and lead author of the report, suggests that IT must learn how to better educate and evangelize data issues in a language and a context that matters to the business — a responsibility that Karel puts squarely on IT, “because IT often has a more cross-enterprise view than siloed business units and functions.”

For data governance and process governance efforts to be successful, they both (business and IT) must frame their priorities and business value in the context of which business processes they are aiming to improve, transform and optimize, says Karel.

From Forrester study, September 2010

Source:http://alteryx.com/How-Alteryx-Performs/Pages/White-Papers/Forrester-Report-on-BI-Platform-Requirements.aspx

Intelligence, People and Process

Master data management (MDM) is a good reflection of how an enterprise uses data, information – and content – for business purposes. The creation and management of master data touches more than the information itself. By creating data repositories and processes that reflect business functions, an enterprise should develop access to the information that is so crucial to effectively and efficiently achieving its business goals. It’s extremely important to analyze, manage and provide access to all forms of information – structured and semi-structured data, as well as “unstructured” content.

For BI and analytics solutions to provide real intelligence, they must be based on accurate and timely data. BI outputs are based on data aggregations, until recently, from structured data in data warehouses, with delivery in the form of reports or dashboards to enterprise users. Analytics add the dimension of mathematics and formulas, with variants addressing forecasting and prediction.

Neil Raden responds to the ebizQ question: How does master data management change BI?:

…to describe how organizations collect data as part of a process, but manage to make it infinitely more valuable by using it for other purposes.

What does this have to do with BI and MDM? In our research, we have found that most knowledge workers shun BI for two reasons (not performance or ease-of-use): relevance and understanding. MDM adds nothing to address these concerns because its representational framework, a relational schema, is inadequate. It’s a representation of a model. An ontology is a model. Until MDM rejects the relational model as its underlying schema, it will be unable to add the rich meaning, relationships and even reasoning that an ontology can do.

So, the point is, if you’re going to go to the massive effort and expense of an MDM solution, take some advice from 21 years ago… Make the data useful for people, not just governors and black belts.

One newer area of interest for BI and analytic solutions is the inclusion of collaborative activities to add contextual and qualitative layers to the output of BI processes. To achieve authentic intelligence, contextual / qualitative layers can provide a strong basis to test, fine tune and filter the artifacts of analytics.

Analytics can benefit greatly from human filters that bring experience, knowledge and creative thinking. Context has a big role here: context for sources, context for outcomes, context for usage with other data points, to achieve the optimal intelligence for “making better business decisions”.

The possibilities for new applications of analytics increase with collaboration. Inviting in many-to-many interactions also opens up processes to new ideas from participants. Gartner found that social venues and collaboration help to track and capture outcomes of the decisions made based on BI / analytics:

Gartner’s user surveys show that improved decision making is the key driver of BI purchases. However, most BI deployments emphasize information delivery and analysis to support fact-based decision making, but fail to link BI content with the decision itself, the decision outcome, or with the related collaboration and other decision inputs. This makes it impossible to capture decision-making best practices. Solutions are emerging that tie BI with social software and collaborative tools for higher-quality, more transparent decisions that will increase the value derived from BI applications.

With convergence, employees in the enterprise should operate more effectively, where improved data governance/MDM lead to better BI, where collaborative processes also enhance and validate BI, where a collaboration setting for BPM works to deliver more of the information that the enterprise needs.

A possible approach to marrying collaboration, data and intelligence to business processes, and, more importantly, to the way people work, can be seen in Tibco’s re-working of tibbr. Dennis Howlett provides this description of tibbr:

It intelligently marries people, process and context, delivering information the way people want to consume

Tibco connects tibbr to business processes and event-triggering that are then exposed in tibbr for taking action. While tibbr is built more for real-time information streams than archives of content and information, tibbr and Tibco have created a platform with a lot of potential for improving overall information findability that adheres to context and worker roles.

It connects to process, people/workers, collaboration venues, data and information streams, centralizing all event streams into one dashboard. Information can be organized by subject or topic, rather than by people. tibbr enables users to create, contribute to, and subscribe to the real-time event streams that matter most to them.

Convergence Clarifies Benefits and Value

In a recent Gartner report covering predictions for data integration and MDM:

Through 2015, 66% of organizations that initiate an MDM program will struggle to demonstrate the business value of it.

It’s probably not a stretch to extend this “struggle for value” to BPM and BI / analytics. But through the convergence of MDM with BI / analytics and BPM, an analyst like Sandy Kemsley sees increased business value, in this Loraine Lawson interview:

Lawson: It’s become more important with MDM to identify pain points and a real business case. Yet MDM is still pretty IT-centered. Does connecting it to business process management (BPM) allow it to be more business-focused as a project?

Kemsley: Absolutely – connecting it to BPM, and also connecting it to business intelligence and analytics, because that’s one of the things that many business users are interacting directly with (analytics), whether it’s just simple reporting or dashboards or a more complex drill-down. You can get better analytics if you have consistent data models and those consistent data models are going to be helped by MDM, that’s one of the key business benefits. When you want to have a report that gathers data from a number of different systems, it’s not going to be some huge, big, long project because somebody has to figure out what data maps onto what other data. It’s going to be a much more straightforward thing because while the data may not all be in one place, at least it will be in a consistent format so that you can easily bring it together.

Individually these solutions can achieve some value and success for an enterprise, but at the cost of much duplicated effort and resources.

In convergence, with initiatives for business improvement and better decision-making, an integration of BI/analytics, BPM, data governance and MDM has definite synergistic outcomes that can greatly increase business value and reduce wasted effort.

Integrating business insights into process execution will significantly improve the quality of decisions and lead to continuous process optimization. And process events kicking off BI and analytics for real-time decision-making increases beneficial outcomes.

All of these solutions should be about solving frequently complex business problems and supporting the work to be done in the enterprise. Each solution brings a significant piece of the “big picture”: better decisions for the business with reliable data feeding both intelligence and process. Ultimately the biggest payoff is how this convergence feeds directly into business agility and continuous change to constantly fine tune sustainable competitiveness.

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

The golden records in the hub are formed from the master data records typically describing the customers, suppliers, products and locations in the transactions made in the enterprise application stack. In the master data hub, we emphasize consolidating, and eventually also splitting, the master data (to be) from different contexts into golden records being as close to the real world as needed in the enterprise as a whole.

As in common database theory, we also need relations between the golden records and we may, staying in the metallic tune, call them golden relations.

Golden Relations in the Party Domain

In understanding our customers, suppliers and other party roles, we build hierarchies of the golden records in the golden copy. Typical hierarchies include:

• Consumers belonging to a household
• Company family trees, often derived from external reference data
• Contacts within the companies which are our customers and suppliers

My guess is that we’ll start seeing more advanced relationship tracking in this domain in the near future. An example would be social network-based tracking of contacts changing jobs between parties who are our customers, prospects and suppliers.

Golden Relations in the Product Domain

Hierarchy building in the product domain is much more diverse between industries and in a single organization than hierarchy building is in the party domain.

Therefore, flexible structures are needed within a golden copy or master data hub used for Product Information Management (PIM).

Our ability to handle more products in our databases and the trend towards globalization making more products available will only increase the demand for handling the golden relations between the golden product master records.

Golden Relations in the Place Domain

I like to name the domain of locations as the “place” domain, because then we have a “P” trinity of Parties, Products and Places.

Hierarchies come naturally with places, as they form a geographical hierarchy of the type we like to use, typically being country, state, postal code / city, street name / block, building number and unit depending on where on the earth our place is situated.

The trend of governments around the world making public sector data more open helps a lot in getting the structures of the place master data aligned with the real world.

Golden Relations in Multi-Domain MDM

A multidomain master data hub embracing the “P” trinity of parties, products and places will have some important golden relations between the golden records within each domain like:

• The exact place where a unique party such as a consumer lives. This also helps with forming the right households.
• The exact place of a certain part of a product, being a locality for example in hospitality and travel – and the exact places of the nearby attractions.
• The sales figure in a defined period for products belonging to a given category sold to parties being companies in a given line-of-business.

Most interesting business problems require more than one domain of data for their solution.

Platinum Relations

Master data may be born in the hub or may be born outside the hub and then transformed into the hub, thus becoming the golden copy.

Transforming already existing records representing parties in the prospect and customer role into the hub is still the most common direction today. Therefore that discipline is still often called Customer Data Integration (CDI).

In this process, it is highly recommended not to purge the records and relations that already exist when we merge data into golden records. You should keep the incoming records with a platinum relation to the new golden record as it sometimes happens that you have to rollback.

Mass import and transformation of data also happens in the product domain, for example at retailers. Also here it’s recommended to keep the original data and make platinum relations.

In some places, I’ve come across a case of “keeping up appearances”, called vanity addressing. Here your customer insists on using a somewhat incorrect address that “sounds better”, such as “Beverly Hills” instead of “Los Angeles”. For that reason too, it’s recommended to keep the vanity address and a platinum relation to the real world place.

This article was written by Henrik Liliendahl Sørensen, a well known blogger whom we hope will be a frequent guest author here. You can find his blog, “Liliendahl on Data Quality” at http://liliendahl.wordpress.com.

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.

The topic will be how to “Drive Customer Loyalty with Effective Master Data Management”.

It costs a lot less money to hold onto existing customers than to attract new ones.  But now that your customers have more choices than ever before, you need to give them compelling reasons to stay. Unfortunately, for many organizations, poor data quality leads to an inaccurate view of the customer – decreasing service levels and damaging customer loyalty.

Oracle Master Data Management consolidates, maintains, governs and distributes complete, accurate master data across all enterprise systems. And Oracle’s Siebel Loyalty Management provides the customer insight to help you design loyalty campaigns that maximize the value of all your customer relationships. Seamlessly integrated, Oracle’s solutions offer a powerful combination of high data quality and effective loyalty management.

Register to join the live Webcast on Wednesday, August 17 at 11:00 am Pacific (2:00 pm Eastern) to hear myself (Dan Power from Hub Designs) and David Butler (Senior Director, MDM Marketing at Oracle) discuss how the combination of Oracle MDM and Siebel Loyalty Management can help you:

• Gain an accurate view of every customer with high-quality data and advanced analytics
• Improve service levels with a single, unified view of the customer across every channel
• Boost revenue by maximizing the return from upsell and cross-sell opportunities
• Reduce service costs with increased call center efficiency and productivity
• Accelerate the return on loyalty campaigns with dramatically improved targeting

Oracle has some exciting things to say about Enterprise Data Quality and Master Data Management, and I’m pleased to be doing this webinar (and the Product MDM Webinar on August 11th) with them. Register now!

The topic will be how to “Ensure World Class Data For World Class Supply Chain Management”.

When you don’t have world class data, your company suffers from inefficient processes, misjudged decisions, compromised compliance, excessive spend, and supplier exceptions. But if you have a robust Product Data Quality and MDM strategy and deliver it well, your product information rapidly becomes one of your organization’s greatest assets.

Oracle’s Product Information Management solutions offer the most comprehensive and powerful suite of applications and tools for managing product data at every stage of the extended supply chain. By eliminating common data management problems, Oracle’s market-leading solutions allow you to improve efficiency, enhance data quality, make better informed decisions and manage a world class supply chain.

Register to join the live Webcast on Thursday, August 11 at 9:30 am Pacific (12:30 pm Eastern) to hear myself (Dan Power from Hub Designs) and David Butler (Senior Director, MDM Marketing at Oracle) discuss how Oracle’s Product Information Management solutions can help you:

• Consolidate all product information with Oracle Product Hub
• Improve data accuracy, accessibility and security with Oracle Enterprise Product Data Quality
• Drive efficiency across the supply chain with world-class Product Information Management

Don’t miss this chance to learn how you could transform supply chain data quality with Oracle Product Master Data Management. Register now!

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

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

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

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

Defining domains in a multi-domain model

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

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

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

Prioritizing in a multi-domain model

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

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

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

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

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

Distinguishing the Program Management Office role from the data domain role

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

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

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

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

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

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

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

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

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

Additional things to consider

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

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

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

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

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

Mark Allen has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.