There’s quite a bit of talk about Big Data these days across the Web … it’s the meme that just won’t quit. The reasons why are pretty obvious. Besides a catchy name, Big Data is a real issue faced by virtually every firm in business today. But what’s frequently lost in the shuffle is the fact that Big Data is the problem, not the solution. Big Data is what marketers are facing—mountains of unstructured data accumulating on servers and in stacks, across various SaaS tools, in spreadsheets and everywhere else you look in the firm and on the cloud.
There’s quite a bit of talk about Big Data these days across the Web … it’s the meme that just won’t quit. The reasons why are pretty obvious. Besides a catchy name, Big Data is a real issue faced by virtually every firm in business today.
But what’s frequently lost in the shuffle is the fact that Big Data is the problem, not the solution. Big Data is what marketers are facing—mountains of unstructured data accumulating on servers and in stacks, across various SaaS tools, in spreadsheets and everywhere else you look in the firm and on the cloud. In fact, the actual definition of Big Data is simply a data set that has grown so large it becomes awkward or impossible to work with, or make sense out of, using standard database management tools and techniques.
The solution to the Big Data problem is to implement a system that collects and sifts through those mountains of unstructured data from different buckets across the organization, combines them together into one coherent framework, and shares this business intelligence with different business units, all of which have varying delivery needs, mandates, technologies and KPIs. Needless to say, it’s not an easy task.
The usual refrain most firms chirp about when it comes to tackling Big Data is a bold plan to hire a team of data scientists—essentially a bunch of database administrators or statisticians who have the technical skills to sift through the Xs and 0s and make sense out of them.
This approach is wrong, however, as it misses the forest for the trees. Sure, having the right technology team is essential to long-term success in the data game. But truth be told, if you’re going to go to battle against the Big Data hydra, you need a much more formidable weapon in your arsenal. Your organization needs a Master Data Management (MDM) strategy in order to succeed.
A concept still unknown to many marketers, MDM comprises a set of tools and processes that manage an organization’s information on a macro scale. Essentially, MDM’s objective is to provide processes for collecting, aggregating, matching, consolidating, quality-assuring and distributing data throughout the organization to ensure consistency and control in the ongoing maintenance and application use of this information. No, I didn’t make up that definition myself. Thanks, Wikipedia.
The reason why the let’s-bring-in-the-developers approach is wrong is that it gets it backwards. Having consulted in this space for quite some time, I can tell you that technology is one of the least important pieces in the puzzle when it comes to implementing a successful MDM strategy.
In fact, listing out priorities when it comes to MDM, I put technology far to the end of the decision-tree, after Vision, Scope, Data Governance, Workflow/Process, and definition of Business Unit Needs. As such, besides the CTO or CIO, IT staff should not be brought in until after many preliminary decisions have been made. To support this view, I suggest you read John Radcliffe’s groundbreaking ‘The Seven Building Blocks of MDM: A Framework for Success‘ published by Gartner in 2007. If you haven’t read it yet and you’re interested in MDM, I suggest taking a look. Look up for an excellent chart from it.
You see, Radcliffe places MDM Technology Infrastructure near the end of the process, following Vision, Strategy, Governance and Processes. The crux of the argument is that technology decisions cannot be made until the overall strategy has been mapped out.
The rationale is that at a high-level, MDM architecture can be structured in different ways depending on the underlying business it is supporting. Ultimately, this is what will drive the technology decisions. Once the important strategic decisions have been made, a firm can then bring in the development staff and pull the trigger on any one of a growing number of technology providers’ solutions.
At the end of 2011, Gartner put out an excellent report on the Magic Quadrant for Master Data Management of Customer Data Solutions. This detailed paper identified solutions by IBM, Oracle (Siebel) and Informatica as the clear-cut industry leaders, with SAP, Tibco, DataFlux and VisionWare receiving honorable mention. Though these solutions vary in capability, cost and other factors, I think it’s safe to say that they all present a safe and robust platform for any company that wishes to implement an MDM solution, as all boast strong technology, brand and financial resources, not to mention thousands of MDM customers already on board.
Interestingly, regarding technology there’s been an ongoing debate about whether MDM should be single-domain or multi-domain—a “domain” being a framework for data consolidation. This is important because MDM requires that records be merged or linked together, usually necessitating some kind of master data format as a reference. The diversity of the data sets that are being combined together, as well as the format (or formats) of data outputs required, both drive this decision-making methodology.
For companies selling products, a product-specific approach is usually called for that features a data framework built around product attributes, while on the other hand service businesses tend to gravitate toward a customer-specific architecture. Following that logic, an MDM for a supply chain database would contain records aligned to supplier attributes.
While it is most certainly true that MDM solutions are architected differently for different types of firms, I find the debate to be a red herring. On that note, a fantastic article by my colleague Steve Jones in the UK dispels the entire single-versus-multi domain debate altogether. I agree wholeheartedly with Jones in that, by definition, an MDM is by an MDM regardless of scope. The breadth of data covered is simply a decision that needs to be made by the governance team when the project is in the planning stages—well before a single dollar has been spent on IT equipment or resources. If anything, this reality serves to strengthen the hypothesis of this piece, which is that vision more technology drives the MDM implementation process.
Now, of course, an organization may discover that it’s simply not feasible (or desirable) to combine together customer, product and supplier information in one centralized place, and in one master format. But it’s important to keep in mind that the stated goal of any MDM solution is to make sense out of and standardize the organization’s data—and that’s it.
Of course there’s much more I can cover on this topic, but I realize this is a lot to chew on, so I I’ll end this post here.
Has your firm implemented, or are you in the process of implementing, an MDM solution? If so, what process did you follow, and what solution did you decide upon? I’d love to hear about it, so please let me know in your comments.