When I logged into Twitter on Wednesday, I had a list of responses that weren’t too impressed with the four-step path to MDM identified by Sandra Gudat in Multichannel Market and highlighted by yours truly.

“I doubt the approach!” tweeted Axel Troike, president at Grandite, Quebec, Canada, a consultant and service provider company that specializes in SILVERRUN tools for business process and data modeling.

I’ve followed Troike for a long time on Twitter, and respect his opinion on such things. His tweet was retweeted by several other leading MDM experts. So, of course, I reached out to him for more specifics.

What bothered him was the original post’s incomplete advice, unusual sequence, and misused jargon, e.g., “there’s no such thing as a ‘customer data warehouse,” Troike stated in an email. The sum of these suggested to him that the piece was more a simple explanation of MDM, rather than an actual list of steps you can use to implement MDM.

“To the credit of the original article's author, it may have been justified to simplify the storytelling, as this article was probably tailored to fit a particular organization and to get emotional/political approval from that organization's management team,” Troike said. “However, taken out of context, the original post is more misleading than helpful.”

So… How can you succeed with master data management? Troike and others offered their advice.

First, instead of starting with a multi-disciplinary committee, start with the CEO, advises Troike.

“First and foremost, MDM has to be a CEO-driven endeavor! A committee may be appropriate to organize a Christmas party, but a success-critical mission such as MDM requires a clear (and sole) responsibility. The endeavor starts as a project with a responsible project manager (business person or external consultant) reporting to the CEO, team members are representatives of major business units."

The other three steps from the original piece — map business processes and data flows, create a business plan, and assign a data steward — are important tasks, but they aren’t comprehensive. Many other steps must be included, and those more permanent tasks should be assigned to business units or individuals as they emerge, he adds.

Another big problem: The piece suggested that the business plan was the committee’s first action, followed by mapping business processes and data flows. Troike disagrees, saying it’s just the reverse.

“It should be the first task of the aforementioned project team to model business processes, data flows and data entities (Enterprise Information Model) whereas the focus should be on business-critical processes, i.e. on those that serve to create revenue, to reduce costs, to create opportunities and to minimize risks,” Troike writes. “The business process model will help to identify potential flaws/data quality issues with data flows. Critical points of improvement will justify the investment in MDM. (I would not call it a ‘business plan,’ but e.g., an ‘MDM action plan.’)”

Other readers were upset that the piece neglected to mention data governance.

“50 shades of wrong in a number of the assumptions & assertions in that piece,” tweeted Daragh O’Brien (@daraghobrien), an Ireland-based information quality, governance and data protection consultant. “For a start, data governance (is) not about governing database but (a) culture of data.”

And then there’s the question of the data steward’s role in the process. Gudat suggests appointing a data steward who “not only has administrator privileges to the master customer database, but also monitors to ensure that all new data is consistent and conforms to pre-established standards.”

“‘administrator rights' on a database - NOBODY should have them except DBA, NOBODY,” stated George McGeachie, (@MetadataJunkie), co-author of Data Modelling Made Simple with PowerDesigner. His response received several resounding retweets.

Troike shared their concern and then some, explaining that the Enterprise Information Model is “the map to assign data stewards to data entities laid out in the data model,” he wrote. The data steward should never, ever have administration privileges on any database, he added, because that function belongs to an IT systems or database admin alone, he added.

Still IT is not the lead in MDM, he said. The business should handle all the steps to MDM while IT acts as the technical enabler, he writes.

That’s the tricky part about MDM, though. Master data management isn’t a technology project per se, but it’s not really something that happens without the technology. And that’s where things can get a blurry and even cantankerous.

Right or wrong, for years IT has done the heavy lifting on MDM projects. Along the way, they’ve learned valuable lessons such as:

Always find an executive sponsor.

MDM requires significant upfront work and investment on data governance.

MDM is only a piece of data quality, not its totality.

Troike generously says the original piece may have been out of context, and maybe that’s the key issue here: I think the context is changing.

In the past, it was a safe assumption that IT would be somehow involved from the outside with these big technology-fueled projects. Now, Gartner predicts that marketing’s IT budgets will be outstripping IT’s budgets by 2018. History has demonstrated that business divisions aren’t always shy about spending on technology without consulting IT.

As responsibility shifts to the business, I wonder if these lessons will be lost. Will organizations end up paying for the same mistakes as early adopters because of it?