Andy Hayler of Smart Data Collective writes, “I recently spent a couple of days with the management of Informatica at the Rosewood Hotel in Palo Alto. The company sees a lot of potential in the notionally rather mature area of data integration, with hand-coding still the norm in many companies, especially in less developed markets such as China, Russia and Mexico. In 2012 one third of the revenue was part of a broader deal, with the company claiming a doubling of customer logos. Informatica’s MDM offering is based on two acquisitions, Siperian and now Heiler. Siperian was also noted for its good scalability for customer data, and a recent customer win at HP illustrates that, the application dealing with 1.5 billion customer records, and handling 37,000 users.”

Hayler goes on, “The Heiler acquisition is still technically not complete (German securities rules in such things moves slowly) but it was evident that the Heiler staff were already working in concert with Informatica. Heiler itself grew 29% in 2012, showing a growth spurt in Q4 after the acquisition was announced. Informatica had for some time claimed that their MDM offering was multi-domain, but in reality most customer examples were based on customer data, and heavily skewed towards North America. The purchase of European PIM vendor Heiler gives more balance to this picture, and in time one would expect to see the separate MDM hubs sharing metadata etc. Informatica actually has a quite good story around managing multiple MDM hubs, but this is one that it has been quiet about, perhaps not perceiving much demand, yet its capabilities e.g. in data masking, are useful in such contexts and should enable it to do a better job than many in a federated environment.”

Read more here.

photo credit: Informatica

Steve Wexler of IT Trends & Analysis reports, “Dell wants to simplify data management, data integration and assurance of data quality – at a fraction of the traditional big-vendor cost – with the Boomi Master Data Management (MDM) offering. Targeted primarily at mid-sized companies, the 100% cloud-based offering with multi-domain support, near real-time synchronization, bi-directional data flow and web service calls that support enriching and validating data, provides an affordable, accessible and easy-to-use solution, said Chris McNabb, director of product management, Dell Boomi. According to Gartner, MDM is a technology-enabled discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, semantic consistency and accountability of the enterprise’s official, shared master data assets.”

Wexler continues, “Master data is the consistent and uniform set of identifiers and extended attributes that describes the core entities of the enterprise, such as customers, prospects, citizens, suppliers, sites, hierarchies and chart of accounts. This is a natural product adjacency or extension for Boomi, said McNabb. We were able to combine the benefits of cloud along with community into an affordable solution we believe will disrupt the underserved midmarket, he said. Dell has been using the product internally for at least six months, and doing betas and upgrades since the Fall.”

Read more here.

photo credit: Dell

Barb Darrow of GigaOM reports, “Actifio, which says it helps companies simplify and streamline operations by consolidating multiple copies of content that proliferate across applications, now has $50 million in Series D funding led by Technology Crossover Ventures (TCV) to push that vision. That brings its total venture backing to more than $105 million. Waltham, Mass.-based Actifio wants companies to adopt its copy data store technology to reduce extra copies of the data they generate and collect to, ideally, a single ‘golden’ copy. Existing investors Andreessen Horowitz, ATV, Greylock Israel, and North Bridge Partners also participated in this D round, which comes more than a year after a $33.5 million C round. Prior to that Actifio received $8 million in a July 2010 Series A round and $16 million just two months later in a Series B round.”

Darrow continues, “CEO Ash Ashotush told me a few months ago that companies spend too much making and managing lots of copies of data. ‘If we employ virtualization technology, one copy of that data can be reused and reconstituted for any use—sharing and analysis,’ he said. At an Actifio users conference a few months ago, Keith Bucknall, lead technical architect  for the U.K.’s Equity Insurance Group, said Actifio is a key part of his company’s unified storage and backup platform that makes it easier to perform backup, data protection and recovery, as well as data migration and management.”

Read more here.

photo credit: Actifio

Kelle O’Neal of B-eye-Network recently discussed the practical aspects of setting up a Data Governance program that will lead to Master Data Management success. She writes, “During the requirements gathering phase of a master data management (MDM) implementation, the data governance organization (DGO) is involved in defining the scope of requirements for data that will be managed in the MDM hub. Several categories need to be considered, including: Entity Types; Ownership and Accountability; Policies, Processes and Standards; Data Integration (Inbound and Outbound); Service Level Agreements; Data Quality; Match and Merge (Survivorship); User Interface and Security; General Maintenance. We’ll cover the first four of these categories in this blog post.”

On the topic of entity types, O’Neal writes, “One of the first decisions the DGO must make is to determine the entity types that are in the initial scope of the MDM implementation. The entity type (or master data type) to be managed in the MDM hub may include, for example, client, product, supplier, legal entity, etc. The hierarchies, relationships and associations among these entity types that will be managed by the MDM hub must also be defined. Again, these may include client, account and product hierarchies, as well as the association of an individual to a company, a party to an address, a product to a supplier, a part to a finished good, etc. Additional entities, hierarchies, relations and associations can be added as needed.”

Read more here.

photo credit: Frederick Md Publicity

Ravi Shankar, VP of Product Marketing at Informatica recently wrote an article for Forbes on why retailers need to focus on mastering customer data. He writes, “Retailers today are looking for ways to offset increasing competition, pricing pressure and operating costs. As always, the focus is on the customer. According to the 2012 National Retail Federation and KPMG’s Retail Horizons report, nearly 67 percent of retailers surveyed ranked customer satisfaction as their top strategic initiative for 2012, while 82 percent claimed customer service strategies would be their top priority for the year, up from 75 percent the year before. When retailers can deepen their knowledge of the customer across all of today’s proliferating retail channels, they can strengthen customer loyalty, increase share of wallet, minimize operational costs and maximize profits. It sounds so simple – so why is it so hard?”

He goes on, “The answer is that it is hard because customer data is often difficult – difficult to access, difficult to make consistent and complete and difficult to trust. It is just plain hard to make sense of. Customer data is scattered and duplicated across multiple systems, which means there are multiple versions of the truth. That makes it difficult for sales, marketing, customer service and operations to gain a complete and authoritative view of this business-critical information. It is not uncommon for a retailer to have a set of systems for retail point-of-sale, another for e-commerce and yet another for the call center, with information entered and stored differently and in different formats in each case. Given this fragmentation, it is no surprise that it is challenging to coordinate marketing, sales and customer service across Web, brick-and-mortar and call center operations.”

Read more here.

photo credit: EvelynGiggles

Loraine Lawson of IT Business Edge reports, “Master data management projects are significantly more successful than four years ago, according to a recent CIO UK column. But when they fail, it’s for the same old reasons: internal politics and poor data quality. The Information Difference, a UK-based market research firm, recently surveyed companies on their MDM adoption, modeling the questions closely after a 2008 survey on the same topic. In 2008, MDM actually had a pretty unimpressive success rate, with large companies reporting that their MDM implementations were “broadly successful” just 54 percent of the time. Now, that number is 81 percent, reports Andy Hayler, president and CEO of the Information Difference.”

She goes on, “But what hasn’t changed is what causes MDM to fail. ‘The major barriers to success in MDM have not changed: internal politics and poor data quality were the most commonly cited issues,’ Hayler writes. Of course, those aren’t the only reasons MDM still nets a nearly 20 percent fail rate. Manjeet Singh Sawhney, a senior Information Management consultant at the London-based Tata Consultancy Services, recently wrote a post outlining 10 other reasons MDM projects fail.”

Read more here.

by Christine Denney

Here we are at the final installment in the series – essential number eight.  I hope that you have gained as much insight from reading the series as I have from writing it.  While the earlier essentials focused on analysis and design, essential number eight pulls everything into a plan for the future.

Essential #8: Figure out the path forward

It’s interesting to get someone else’s perspective on your work.  When I put together the slide for this last essential (I originally presented this idea at Enterprise Data World), I thought the picture was of a nice, gently winding road.  It was intended to provide hope that the path toward MDM might not be straight, but it wasn’t terrifying.  At least my interpretation was that it wasn’t terrifying.  I had no idea that it could be viewed in a different way.  But apparently that nice, gently winding road may have been quiet, but it was also desolate.  The grass was green, but there were no trees, people, or buildings.  Nothing.  Did I mention that it didn’t go anywhere either?  It just sort of ended.  That was something I hadn’t noticed until it was pointed out to me.  I suppose that just serves to reinforce the need to get some outside perspectives and think about how your initiative may benefit from someone else’s advice.  (and, in this case, I am hoping that the picture above is at least slightly more hopeful than what I had before!)

Setting the Path

So how do you figure out the path forward?  Where do you start?  After setting an end goal, assessing what you have, and examining the gaps, you already have a great start in the planning process.  Now, it’s just a matter of tying the pieces together and prioritizing.

1. The business case is key.  Everything in the plan should tie back to the pain points within the business case.  Map the paint points and user stories to requirements, then requirements to the design components.  You can then take your current state analysis and lay that over the top to identify gaps.  Depending on the complexity of the project, you might consider using a tool that has sophisticated mapping and dependency capabilities.

2. Start small to prove value.  MDM has a reputation of being a long, drawn-out process that takes years to deliver value.  Saying that your first delivery is 3 years out is probably not the best strategy to disprove the myths and keep the program funded.  For example, you might start with enough functionality to create identities for a single master data element (and limit the scope of the initial data set to only the most important entities), then, in subsequent releases, add additional data or relationships.  Deliver enough to solve at least part of the business problem and prove that MDM is more than just an academic exercise.

3. Prioritize the subject areas of interest.  Look for the subject areas of most value that also have a good probability of successful implementation.  A data element that sounds critical may also have business process or definition barriers that must be dealt with before a clear path can be set for that element.

4. Be sure to look at dependencies.  There may be dependencies in both processes and data.  Mapping applications and data elements to a process flow can help identify existing (and potential) issues with governance and data dependencies.  Are people within the group that “owns” Customer data, really the first to create identities for that data?  Is the success of the implementation dependent on a source system that stores data in a proprietary format and doesn’t have existing mechanisms to access the data?

5. Organize steps and communicate with a t-map or roadmap.  I find that it can be helpful to take the analysis and design pieces from the previous essentials and group them together into categories that form the streams of a t-map.  (more on that below)

T-Maps

I love t-maps almost as much as self-adhesive notes.  Almost.  Maybe it’s those hopeful statements in the upper-right corner?

The key is to align those statements with the end goal that you set with essential number one.  Focus on the value to the business, such as providing more accurate financial information or increasing sales.

The streams align with key focus areas for delivery.  Governance is an important stream that can be an indicator of success in the other streams.  If data quality is an important factor, include that.  You might also have a stream for metadata, architecture, and one or more streams for data elements.

Wrapping it Up

As we traveled through the 8 essentials, we set the end-state goals, analyzed our current situation, designed the necessary pieces for the desired end state, and set a course on the MDM road.   It may not be a smooth road, but if we take one mile at a time, reassessing as we go, we can reach our destination.

NOTE: Thoughts expressed are those of the author and not her employer.

Michele Goetz of Forrester has written an article discussing current thinking surrounding Master Data and how that thinking needs to be rebooted. She writes, “A common theme I hear from clients is that master data is about the linked data elements for a single record. No duplication or variation exists to drive consistency and uniqueness. Master data in the current thinking represents a defined, named entity (customer, supplier, product, etc.).”

She goes on, “This is a very static view of master data and does not account for the various dimensions required for what is important within a particular use case. We typically see this approach tied tightly to an application (customer resource management, enterprise resource management) for a particular business unit (marketing, finance, product management, etc.). It may have been the entry point for MDM initiatives, and it allowed for smaller scope tangible wins. But, it is difficult to expand that master data to other processes, analysis, and distribution points. Master data as a static entity only takes you so far, regardless of whether big data is incorporated into the discussion or not.”

Read more here.

By Christine Denney

Welcome to the third installment of the “Figure 8” series!   In last month’s post, we reviewed essentials 2-4 and discussed guidance for conducting the current state assessment and inventory.  With essentials 5-7, we move past the analysis (understanding the “what”) and into building the architecture (the “how”).

You might be wondering why self stick notes (a.k.a. “sticky notes”) are featured in the graphic and what they have to do with the essentials.  Mostly, I featured them because I have an unhealthy obsession with those gluey little darlings and their electronic siblings.  I have them everywhere and I love using them in the analysis and design phases because they are easily moved around or removed completely when an item is no longer relevant.  To me, they serve as a reminder that as we work through the essentials, we continue to experiment and adjust as new information arises.  Grab your self-adhesive notes and let’s explore the next three essentials!

Essential #5:  Figure out storage and sharing

Where, oh where, should our data be?  Since we already figured out “what” we want to manage and took an inventory of existing solutions, some key questions arise during this step.  If we already have the data stored somewhere electronically, is it accessible? (not just via one method, but a variety of methods?)  Is it on a platform that will be supported in the future?   Is the data stored in a single location (or will it be)?  Does it need to be?  In addition to all the questions swirling around, the terms hub, data store, replication, service, and virtualization may be on your mind at this point.  Since there are several articles that contrast the various types of hubs, I won’t delve deeper into that topic within this blog.

Another thing to determine is the scope of the master data store.  Defining the key, sharable attributes can help you clarify scope, determine estimates for sizing, and frame the security needs.  If the proposed solution spans multiple business areas, be clear on the boundaries of what the central store will include.  Some business areas may want to include attributes that are not applicable to the wider audience.  Consider implementing the business area-specific attributes within a local application.

A key principle for this essential is that a repository without an integration plan adds little value.  Don’t lock up your master data.  There may be occasions where governance, rather than technology, is the main factor in limiting access to the master data.  Understanding what the governing bodies will be willing to share with others can influence the direction for both the storage and access mechanisms.  Because the ability to access information impacts the value of our master data, making this information readily available rises to the top of our priority list.

Essential #6:  Figure out what you can solve

Looking realistically at what can be done is tough, but necessary.  Although the end goal may be to implement something company-wide, there may be barriers that require a smaller scale implementation to prove value more rapidly.  In a previous blog, I contrasted “little e” and “Big E” MDM.  Either one can add value to the business – it’s just a matter of scale.  Figure out which one your stakeholders will support.

The interview notes also play an important role in defining what you can solve.  A combination of a difficult pain point, engaged stakeholders, and a clear problem to solve are master data program nirvana.  (assuming that time, money, and resources are available, of course!)  Although a particular group may have been vocal about their needs during the interview process, that doesn’t guarantee support when money or resources are requested.

Essential #7:  Figure out what you need

MDM, like other complex programs, requires a wide breadth of skills.  Data expertise is at the heart, but both business process and technology experience are necessary for a successful implementation.  You may need to bring in outside consultants either for their guidance or to validate your proposed architecture.  If MDM is new territory for your organization, expect some skepticism and requests for external validation.

Although there are many promises made by tools in the MDM space, you need to consider whether they cover your use case and requirements for a variety of components, including:  infrastructure, governance, data sharing, meta data management, identity resolution, syndicated data, and data quality.

Recap

In essentials 5-7, we have moved from the assessment stage through the architecture and determined the “how” for managing the data.  With that, we wrap up the “what” and “how” phases of the essentials.  Stay tuned for the fourth and final installment of the series.

NOTE: Thoughts expressed in this article are those of the author and not her employer (or probably anyone else, for that matter).

Loraine Lawson of IT Business Edge reports, “Social MDM is raising concerns among privacy groups and some analysts, and to be honest, I completely relate to their concerns. Then I received a briefing on an actual social MDM product, and learned that there’s actually two faces to social MDM: one clever and revolutionary; the other also revolutionary, but a bit frightening. When people talk about social MDM, they usually mean the mining and integration of social media data into MDM. This sounds great from a corporate perspective. You can use social data to correct data in your MDM and use it to expand what you know, then turn that knowledge into a sales pitch. Someone posted that they need a new computer? Great, let’s spam them with ads — but for individuals, it’s a bit menacing, a bit too ‘up in my business’.”

She continues, “I recently received a briefing about Informatica MDM 9.5, which included a look at how this type of social MDM works. It showed the MDM system picking up information not just from your posts, but from your friends’ posts as well. I don’t want to pick on Informatica, because I’m sure other vendors are working in this direction. Being first to market has its advantages and disadvantages; concept criticism comes with the territory. It was impressive, but I confess to being a bit appalled by how easy this mining of social data would be with this new release. This, I think, is the more frightening aspect of MDM. This type of social MDM extends beyond sentiment analysis into pulling information about customers, including relationships and any information on past purchases, out of social networks and into your MDM systems.”

Read more about this side of social MDM here. Then, read about the “pleasantly surprising” side of it here.