Last year, while still an analyst with Forrester Research, OCDQ “Blogger in Chief” Jim Harris and I coordinated dueling blogs taking polar-opposite stances on the debate over whether Data Governance initiatives should embrace an approach to optimize their agility or an approach to formalize the necessary bureaucracy. (You can read Jim’s blog here and my blog here.)
That was a fun exercise, but our clear conclusion was that aspects of both agility and bureaucracy are necessary to some extent for data governance to deliver real business value.
First off, let’s avoid the semantic arguments
For data governance I use “agile” as the adjective form of the noun agility. Not “Agile”, as in the software development methodology. Sure, we can get into a whole discussion about how a data governance program can learn tons from the agile methodology – or not – but that’s not the point I’m trying to make here.
For bureaucracy, I find Merriam-Webster.com’s definition interesting. It defines “bureaucracy” in the following three ways:
“1 a : a body of nonelective government officials; b : an administrative policy-making group
2: government characterized by specialization of functions, adherence to fixed rules, and a hierarchy of authority
3: a system of administration marked by officialism, red tape, and proliferation”
I see the data governance challenge as being: how do we enable the first two constructive parts to this definition, while avoiding the destructive third outcome.
To illustrate this point, let’s use a non-data related analogy:
You just fell off a cliff, broke your leg and are bleeding profusely! Now what?
In this situation, isn’t agility critical? If it were me, I’d like a tourniquet please. In an emergency, I can act fast- and not figuratively, but literally “stop the bleeding!” But the agility that a tourniquet provides is a short term benefit. Without proper care, loss of blood and likely infection can still kill me.
So what’s next? Necessary bureaucracy will save my leg, and possibly my life. In other words, get me to a hospital and into to a surgical room STAT! A surgical room in a hospital offers a trusted, repeatable process with clear policies, practices and standards in place to protect all stakeholders including me, the patient, the doctors and nurses, and the hospital. And in the end I will significantly increase my chances for full recovery and survival – an optimal outcome in my book. What’s the downside? Well, it takes more time and costs a lot more money than a tourniquet. And you certainly can’t carry a surgical team in your backpack.
So let’s put this in the context of data governance.
Instead of a broken leg, you have a data quality or data security issue that’s raising alarms. For example, a large order can’t be fulfilled because the customer address information wasn’t accurate. Or a potential data security breach has taken place because a customer’s sensitive information wasn’t properly masked or encrypted. Or a frustrated high value customer is on the phone complaining that the product information in your catalog doesn’t match what they’re seeing on your website. You get the idea.
For all of these scenarios, you need to act fast and agility is the key to avoiding escalation. The “tourniquet” for many of these will be manual workarounds where an admin or data steward will “fix” the data where it lies to fulfill the order, protect the data or provide the customer with the information they need (based on the scenarios above). But that agility does nothing to address the root causes of the problems so you’ve done nothing to ensure that a repeat scenario won’t happen again.
This necessitates the data governance bureaucracy – a nasty phrase with only the best intentions. It means we should coordinate and define the processes, policies, standards, people and technologies across the organization to manage data ensuring the availability of accurate, consistent, secure and timely data for improved business processes, better decision making, reduced risk, and better customer outcomes. Why is that a bad thing?
The biggest failing of data governance efforts to date has been its focus on the data. We need to quickly shift the conversation away from the trustworthiness and security of the data. The data is NOT the “why” we do data governance – it’s the “what”. The case for data governance will be made once you can answer this question: Why does my organization need trusted, secure data to deliver optimal business outcomes (reduced risk, improved efficiencies, reduced costs, increased revenue, great customer experiences, etc)?
With all the excitement around “Agile” these days, the concept of agility seems to possess magical silver bullet properties, and bureaucracy is definitely a four-letter word within most organizations. I propose we work to expose the downside of agility and the silver lining of bureaucracy and finally have a more pragmatic and business value-driven discussion on how to enable data governance within our organizations.