If you ever really want advice—and I mean good, solid, sit-down-and-breath-it-in advice—talk to someone who’s failed. It seems counterintuitive since we all expect to find nirvana by sitting at the feet of the master-du-jour. But there’s a lot to be learned from someone who’s fallen and stayed on the ground awhile.

Sometimes it takes hitting the wall before we really understand the impact of bad data. Once upon a time, Hershey’s put a bad UPC code on a lot of chocolate bars. The UPC code was invalid. So when the consumer went to buy a candy bar, it wouldn’t scan. Now anyone who’s ever had a chocolate craving understands the calamity of a situation like this. Customers in the throes of a major craving could be found begging the grocery store clerk to manually enter the UPC code, and guess the price. Suffice it to say, this is the opposite of customer delight.

As an enthusiastic consumer of Hershey products, what comes to mind is the sprint back to the chocolate aisle (aisle 7, left side middle at my local grocer) for a replacement. The business side of me considers the impact of the bad UPC codes on the store’s inventory. And the number of consumer calls the Hershey call center had to field. And the re-production of all those labels. The costs were likely tangible and intangible.

The point is that it usually takes real, bona-fide, costly business pain in order for managers to realize that bad, incorrect, or missing data had a true, tangible financial impact to the business, and to customer loyalty.

My friend Susan B., who’s a really good mom by anyone’s standards, refers often to a book called, “The Blessing of the Skinned Knee.” The book talks about how sometimes our kids have to feel pain in order to learn those hard-won lessons. We’ve all hit the skids, but those of us with the actual scars have more interesting stories to tell. And maybe a bit more wisdom to share.

The DataFlux CDI Executive Summit series—courtesy of DataFlux and our friends at BI Network—has come to an end, and it was a great ride. We had engaged audiences in San Jose and Dallas, and New York was the icing on the proverbial cheesecake. (Preferably Junior’s cheesecake.)

With over 85 signups, the New York crowd was the largest. My fellow speakers—Tony Fisher and Michael McQuaid from DataFlux, and Jack Wallace and Peter Harvey from Intellidyn—got a lot of earnest and enthusiastic questions from the attendees. Indeed, they were representative of the questions across the Summit series, and so I thought I’d briefly recap a few of the hotter ones:

Question: Isn’t CDI just another flavor of data warehousing and data marts?
Short Answer: No. Data warehouses and data marts are typically used for business intelligence and complex analytics, whereas CDI serves a range of operational and analytical systems.

Question: Isn’t CDI just an ODS?
Short Answer: No. CDI has data matching and standardization “baked in” to its functionality, whereas an ODS is often only as good as the data coming from its sources. At lunch we determined that most of the attendees who had an ODS were using it as a data staging area.

Question: What role do business processes play in CDI?
Short Answer: A company should understand its business processes in order to know its business rules, and business rules—like the determination of an “active” customer as an account holder who has made a purchase within the last 18 months—can make or break a CDI effort. Simply put, the relevance and accuracy of data on a CDI hub can be critical to a number of systems. Also, business processes figure heavily into the determination of CDI data sources.

Question: Since it serves various operational systems, should CDI be owned by IT?
Short answer: The business should always be involved in the building of the CDI hub, and ultimately the data stewardship should happen on the business side too. (Who better than the people who understand how customer data is used and where?) The development and maintenance of the hub can be done by IT, but regular collaboration with the business side is imperative for CDI success. As with data warehousing, IT owns the care and feeding of CDI, but doesn’t manage the data.

Thanks to those of you who attended the CDI Executive Summits. We think these conversations were icebreakers, and there will be many more opportunities to dialog about CDI and MDM. So stay tuned to the blog—there may be some command performances on the way!

“Why does it take us so long to get all these emerging technologies right?” asked my friend and erstwhile client as we tucked into a hearty New York lunch at the Longwood Gourmet deli on 44th and Park Avenue.

“Maybe we’re supposed to learn it first,” I said, “before we do anything Big with it.”

“Don’t get all Zen on my ass,” he said, and bit into his Number 29 (grilled chicken with Mozzarella and basil on a hoagie).

But he’s right. Once management approves the investment and we write our favorite vendor the check, there’s a built-in expectation of quick delivery. The proof-of-concept has become a given with most technology acquisitions, irrespective of its appropriateness. But then what? Often, it’s business as usual.

My friend had a point. His company needed CDI and he had the budget for it. He realized that CDI was a disruptive technology, would be perceived as a threat by some of his IT colleagues, and that it would require changes to both organization and infrastructure. He knew that CDI would help his company in its M&A frenzy: as it gobbled up smaller competitors, the myriad newfound customer lists languished on various servers. Lost cross-selling opportunities were costing the company untold revenues. My friend also understood CDI’s promise in addressing poor data quality, a corporate phenomenon that had actually pervaded the culture. (Those of you who work at companies with bad data know what I mean.) He was also hoping that he could use CDI to justify the role of Data Steward for corporate customer information, and that he could start formalizing data management development processes.

Unlike many of my clients who face off with colleagues, their business cases their weapons and IT budget the spoils, my friend had the funding. He had a vision for what could be accomplished, the battles that could be fought and won for the greater good of the firm. He had the heavy artillery, he just needed a few more weapons for the salvo. It was just that his leadership, namely IT management, refused to fall on its sword for change.