Data Governance Matters

I had a very interesting experience last month with an organization that makes/distributes food and drink. You’d all recognize the name. Bright, bright people doing some ambitious things. It was a privilege to be asked to poke holes in their data strategy.

While I was with them, I saw a perfect example of the old adage that “Architecture is Destiny.” This organization lives and dies by its knowledge of consumer patterns and behavior. They need data. And they have it - lots of it - and they’re using it.

But they’re held back by an architectural decision made long ago. Maybe it made sense at one time to model “Reason to buy” and “Product” as a one-to-many relationship. But not now. I don’t know about you, but if I decide to buy a cup of coffee, I might have many reasons!

So here’s a major company struggling to analyze buying habits with data that is forced to conform with a one-to-many relationship instead of a more accurate many-to-many. They’re changing this, of course, but still, I can’t stop thinking about how they got here.

I keep imagining a scene from years back: A guy, hunched over in a gray cube, reading from a requirements document. Hands on keyboard, he’s ready to start building a data model. “Really?” he mutters to himself, as he reads the lines that describe the relationship between Reasons to Buy and Product.

“Doesn’t seem right…” he says to no one in particular. Then he shrugs, says “They’re the bosses,” and gets to work. In just a few minutes, he’s defined the relationship that today is limiting how the company is able to understand customer buying habits.