Data Governance Matters

Unsung Heroes and Data Governance
Recently I was asked to explain to a business leader who inherited Data Governance why I had recommended he add a messaging/communication/issue identification path geared toward Data Modelers. He wondered if they were covered in the changes we were going to introduce to the company’s Project Management Life Cycle and its Software Development Life Cycle.

I was happy to explain to him some of the things most Data Modelers do that never show up on their job descriptions. How they may be the first resources in a project – or the only resources in a “too-small-to-be-a-project” effort – to recognize that the assumed approach for structuring data will result in some very unhappy stakeholders somewhere down the line. How modelers tend to know more about data stakeholders and their needs than top brass may be aware of. How they sit at ground zero for much data-related conflict, and so have typically developed negotiation and conflict resolution skills. How this group has traditionally served as the “last line of defense” against certain categories of errors, and can bring those skills and perspectives to many Data Governance programs.

Besides, I said, these folks have been toiling for years, probably suggesting the very types of measures he was now tasked with implementing. Not only could he benefit from their lessons learned, he probably ought to recognize their efforts.

You know, I have this type of talk a lot. It would probably be even stronger if I could give real examples of data disasters that were averted by quick-thinking modelers and architects. Got a story to share? Let me know.

Data Governance Agreements

My friend Tom J is brilliant. Brilliant in the way that can take an idea that everyone uses – but has to employ many many many words and sentences to describe – and crystallize that idea into a perfect term.

You know what I’m talking about. The conversation that begins with the question “How does your organization handle xyz?” Where you get a helpful – but longwinded – answer from someone that is answered by an equally helpful – and equally longwinded – retort from someone else. A third party chimes in, and before you know it everyone is arguing so violently about details that it’s no longer clear that they actually are all in agreement about core concepts.

Actually, I’ve had a few of those conversations with Tom. But the one I’m thinking about – the one that earned him the “brilliant” designation – was one where he used just three little words to describe a tough subject.

“So how do you handle getting different business units to agree on how to treat data?” was the question (or something like that). I’ll never forget his answer: “Data Governance Agreements. You know, like Service Level Agreements (SLAs), but for data.”

Aha! So THAT was the name for those documents I and all my peers in the industry were promoting! THAT was the name for a simple document that could hold complicated clauses. THAT was the name for a concept so self-evident that no business leader could, in good conscience, suggest that these agreements were fundamentally a bad idea.

Data Governance Agreements. DGAs. The acronym will even fit nicely on a flow chart. Thanks, Tom. Wow. Yes.