Master data management is an often overlooked necessity to becoming a data-driven organization. A full data management strategy includes efforts to maintain data quality and data governance across several business applications.

North Carolina-based SAS is best known for its statistical analytics software and in October 2012 the company introduced its own analytical appliance.

But they’ve been working on a master data management platform since 2000, when the company acquired data quality and governance company DataFlux. In 2012 SAS subsumed DataFlux, which it was operating as a subsidiary and now is launching the MDM platform under its own name.

During the 2013 Gartner Master Data Management Summit in Grapevine, Texas, Staff Writer Ian B. Murphy sat down with SAS’s Jill Dyché, vice president of best practices, and Ron Agresta, the technical director for MDM and governance.

The following is an excerpt of the interview, discussing the difficulties of starting a MDM project, selling it to the business and why data management is so important to any big data project.

Data Informed: Do you have people calling SAS to ask what MDM is?

Jill Dyché: All the time.

What do you tell them?

Dyché: It depends on what they’re trying to do, but if its customer data, we tell them it’s for reconciliation of customer records. If it’s product data, we tell them it’s the same thing. A lot of time we want to hear about what they can’t do so we can map that business conversation to a functionality conversation, then talk about the technologies.

When people call SAS with the realization that they have a MDM problem, what do you say?

Dyché: Our first question is: what is the need, pain or problem you’re trying to solve with master data? We try to narrow them down. The whole “boil the ocean” thing – doing everything at once – isn’t going to work, the whole infrastructure play, where MDM is “the engine,” isn’t going to work. Executives have ADD. They’re not going to buy it.

So we tell them: Let’s zero in on a manageable problem to solve, and then we can carry in the right tool set.

I’m sure questions about who should be in charge of a master data management effort are about context as well. What are some ways that people have handled that issue, or how have they staffed a team to take on a project like this?

Dyché: Now companies are saying, “We don’t have anyone with all those skills! What do we do now? Do we need to wait and hire someone before we begin? Do we need to hire multiple people?” It’s interesting: the data management capabilities we’ve been putting in place for MDM are suddenly the “advanced” capabilities for big data! Who knew?

Ron Agresta: There are some systems or projects, say CRM, where it may not be that disruptive. When you’re talking about master data management, you’re talking about a lot of different systems. It could be operational, it could be analytics, you name it.

With some of the new technologies that have come into play, it’s not as easy to say “I’ve got my technology team with a business sponsor.” Usually it’s a much bigger conversation with several sponsors and several technology teams.

Dyché: Then there is a prioritization exercise.

Is it possible to over-plan a MDM initiative?

Dyché: We advocate the bite-sized chunk approach. You can over-plan to the extent that you bite off more than you can chew resource-wise. That’s a common problem. People just have a lofty vision of what they’re trying to achieve with MDM, and they realize quickly they have neither the headcount nor the skills in place to provision that. The key is what’s the need, pain or problem, and then what’s that small, controlled project that we can actually deploy and is put into production, but can also serve as the Petri dish for substantive projects over time. Then we can scale up the technology.

Agresta: The goal for a lot companies that are doing case studies in MDM is to be more agile. The agile methodology is to be more iterative developing the system, because sometimes you just don’t know all the questions up front. If you waited to try and figure out every last thing, you may never get started. We do that in some of our development work, where we know in broad strokes what we want to do, and as we go through and hone in on each iteration, when we try to tackle the new piece of work, then we ask ourselves, “how does this map to what we wanted at the start?”

By then, we know a little bit more so we can start to define what we need at the lowest level. We’re hearing the same thing with MDM deployments, where they know where they want to go, and they have some specs and other general things, but in three, six or nine months there are checkpoints when it’s the appropriate point to tackle a particular aspect of the project.

From what I’ve heard [at the Gartner Master Data Management Summit]this week, it sounds like you should never refer the project as master data management internally, instead just bake in some MDM with each little project the business is doing. Any sort of overarching MDM project sounds like it’s doomed to fail.

Dyché: It depends. Some business cultures—and it really is cultural—benefit from being opportunistic like that, and merging MDM into a high profile project, like a product catalog consolidation project. Others need the shiny new name in order to get traction. It’s fascinating how what you call something actually matters.

We were at a large auto maker, and before our project started, they needed to brand the project and create a logo for the project. They explained to us that the internal brand effort is as important to the company as their own external branding. What we call this and how we position it will determine whether it has legs or not in the organization long term.

Agresta: When we talked to one of our long standing data governance customers originally from the DataFlux world who are now doing MDM with us, I was sitting in on one of the sales meetings and they said, “We’re going to do MDM, but please make sure you don’t call it MDM in these meetings, because that won’t go over well.” They had failed before on MDM projects with other technologies, so they didn’t want to call it master data management.

Analytics has several sexy new technologies coming to the surface. Is there any sexy new tech in MDM?

Agresta: Big data is definitely starting to come into MDM, but it’s still unclear how that’s going to play out, but what’s becoming clear is that the data governance piece more important from a comprehensive suite, or business user functionality. Now they can get into the MDM world but not have to know what’s going on behind the scenes. The social stuff is always up there, and we want to figure out how to pull some of that stuff in.

Dyché: I would argue this stuff—master data management, data quality, data governance, data stewardship—is the sexy stuff for big data. … But [around the industry] there is no talk about data profiling, or data classification or categorization, and there is no talk about true data management and stewardship, instead it’s all about the data scientist.

But now there is a backlash, because there is so much piled on the data scientist. He or she needs to be the integrator, the source system expert, the profiler, the statistician, etc. Now companies are saying, “Whoa, we can’t find somebody with all those skills, what do we do now? Are we not ready?” I would argue that the rigor of the data management stuff we’re seeing here is the sexy new stuff for big data.

Business intelligence and analytics are getting easier and more commoditized, but data is getting harder and harder. The tools are getting easier, and there are few excuses not to be a data driven organization. But the real excuse is: we don’t have the data management skills, we don’t have the right physical tool sets, and we’re not making those investments.