Data Governance Star Wars: Balancing Bureaucracy and Agility
Jim Harris in Blogs, Data Quality, Debates, Govern Your Data tagged Best of 2011, Blog-Bout, Data Governance, Philosophy, Star Wars Thursday, June 9, 2011 at 3:00AM I was recently discussing data governance best practices with Rob Karel, the well respected analyst at Forrester Research, and our conversation migrated to one of data governance’s biggest challenges — how to balance bureaucracy and business agility.
So Rob and I thought it would be fun to tackle this dilemma in a Star Wars themed debate across our individual blog platforms with Rob taking the position for Bureaucracy as the Empire and me taking the opposing position for Agility as the Rebellion.
(Yes, the cliché is true, conversations between self-proclaimed data geeks tend to result in Star Wars or Star Trek parallels.)
Disclaimer: Remember that this is a true debate format where Rob and I are intentionally arguing polar opposite positions with full knowledge that the reality is data governance success requires effectively balancing bureaucracy and agility.
Please take the time to read both of our blog posts, then we encourage your comments — and your votes (see the poll below).
Data Governance Star Wars
If you are having trouble viewing this video, you can watch it on Vimeo by clicking on this link: Data Governance Star Wars
The Force is Too Strong with This One
“Don’t give in to Bureaucracy—that is the path to the Dark Side of Data Governance.”
Data governance requires the coordination of a complex combination of a myriad of factors, including executive sponsorship, funding, decision rights, arbitration of conflicting priorities, policy definition, policy implementation, data quality remediation, data stewardship, business process optimization, technology enablement, and, perhaps most notably, policy enforcement.
When confronted by this phantom menace of complexity, many organizations believe that the only path to success must be command and control—institute a rigid bureaucracy to dictate policies, demand compliance, and dole out punishments. This approach to data governance often makes policy compliance feel like imperial rule, and policy enforcement feel like martial law.
But beware. Bureaucracy, command, control—the Dark Side of Data Governance are they. Once you start down the dark path, forever will it dominate your destiny, consume your organization it will.
No Time to Discuss this as a Committee
“There is a great disturbance in the Data, as if millions of voices suddenly cried out for Governance but were suddenly silenced. I fear something terrible has happened. I fear another organization has started by creating a Data Governance Committee.”
Yes, it’s true—at some point, an official Data Governance Committee (or Council, or Board, or Galactic Senate) will be necessary.
However, one of the surest ways to guarantee the failure of a new data governance program is to start by creating a committee. This is often done with the best of intentions, bringing together key stakeholders from all around the organization, representatives of each business unit and business function, as well as data and technology stakeholders. But when you start by discussing data governance as a committee, you often never get data governance out of the committee (i.e., all talk, mostly arguing, no action).
Successful data governance programs often start with a small band of rebels (aka change agents) struggling to restore quality to some business-critical data, or struggling to resolve inefficiencies in a key business process. Once news of their successful pilot project spreads, more change agents will rally to the cause—because that’s what data governance truly requires, not a committee, but a cause to believe in and fight for—especially after the Empire of Bureaucracy strikes back and tries to put down the rebellion.
Collaboration is the Data Governance Force
“Collaboration is what gives a data governance program its power. Its energy binds us together. Cooperative beings are we. You must feel the Collaboration all around you, among the people, the data, the business process, the technology, everywhere.”
Many rightfully lament the misleading term “data governance” because it appears to put the emphasis on “governing data.”
Data governance actually governs the interactions among business processes, data, technology and, most important—people. It is the organization’s people, empowered by high quality data and enabled by technology, who optimize business processes for superior corporate performance. Data governance reveals how truly interconnected and interdependent the organization is, showing how everything that happens within the enterprise happens as a result of the interactions occurring among its people.
Data governance provides the framework for the communication and collaboration of business, data, and technical stakeholders, and establishes an enterprise-wide understanding of the roles and responsibilities involved, and the accountability required to support the organization’s business activities, and materialize the value of the enterprise’s data as positive business impacts.
Enforcing data governance policies with command and control is the quick and easy path—to failure. Principles, not policies, are what truly give a data governance program its power. Communication and collaboration are the two most powerful principles.
“May the Collaboration be with your Data Governance program. Always.”
Always in Motion is the Future
“Be mindful of the future, but not at the expense of the moment. Keep your concentration here and now, where it belongs.”
Perhaps the strongest case against bureaucracy in data governance is the business agility that is necessary for an organization to survive and thrive in today’s highly competitive and rapidly evolving marketplace. The organization must follow what works for as long as it works, but without being afraid to adjust as necessary when circumstances inevitably change.
Change is the only galactic constant, which is why data governance policies can never be cast in stone (or frozen in carbonite).
Will a well-implemented data governance strategy continue to be successful? Difficult to see. Always in motion is the future. And this is why, when it comes to deliberately designing a data governance program for agility: “Do or do not. There is no try.”
Click here to read Rob “Darth” Karel’s blog post entry in this data governance debate
Please feel free to also post a comment below and explain your vote or simply share your opinions and experiences.
Listen to Data Governance Star Wars on OCDQ Radio — In Part 1, Rob Karel and I discuss our blog mock debate, which is followed by a brief Star Wars themed intermission, and then in Part 2, Gwen Thomas joins us to provide her excellent insights.
Related Posts
DQ-View: Roman Ruts on the Road to Data Governance
Zig-Zag-Diagonal Data Governance
Data Governance and the Buttered Cat Paradox
Beware the Data Governance Ides of March
The Collaborative Culture of Data Governance
Connect Four and Data Governance
The Role Of Data Quality Monitoring In Data Governance
Quality and Governance are Beyond the Data
Podcast: Data Governance is Mission Possible
Video: Declaration of Data Governance
Don’t Do Less Bad; Do Better Good
Jack Bauer and Enforcing Data Governance Policies
MacGyver: Data Governance and Duct Tape
Reader Comments (10)
This had me chuckling away - a great way to present this dichotomy. I believe that the problem has been that IT has clung to the old ways - using orthogonal data models to try and model business rules and processes. Hiding business rules in database design artifacts is perhaps the chief reason for application redundancy and overlap: Each application is its own solar system, unaware of life beyond its boundaries, and resisting "alien invasion" at all costs.
By elevating business rules into a separate semantic layer - a foundation for a true federation can be laid. New collaborative tools, such as Rochade meta-Glossary, Kalido and others - which combine taxonomy, collaboration, wiki, workflow, metadata and governance, I believe, provide the vehicle to escape the gravitational pull of the Death Star. These kinds of semantic reconciliation platforms - enabling the simple act of defining business terms, and linking business terms to the IT artifacts that represent them, and managing those links - is what balances the forces of centralized control and agility.
CIOs and CEOs need to understand that this simple act of semantic correlation creates a common language and a platform for cooperation between Business and IT.
Without this effort, and without their help, even the Death Star will collapse under its own gravity.
Thanks for your insightful comment, Julian.
Before you can expect anyone to comply with data governance policies, you first have to make sure that everyone can understand exactly what they mean. The enforcement of these policies has as much to do with enterprise-wide collaboration as it does with supporting critical business decisions and enabling optimal business performance.
Therefore, the straightforward documentation and clear communication of data governance policies is essential.
Some of the most important data governance policies are those which define business and technical terminology—and provide a semantic bridge between them that facilities collaboration.
As you noted, this simple act of semantic correlation creates a common language and a platform for cooperation, which will always be more powerful than the Death Star, because collaboration is what gives a data governance program its true power.
A curious question to my Rebellious friend OCDQ-Wan,
While data governance agility is a wonderful goal, and maybe a great place to start your efforts, is it sustainable?
Your agile Rebellion is like any start-up: decisions must be made quickly, you must do a lot with limited resources, everyone plays multiple roles willingly, and your objective is very targeted and specific. For example, to fire a photon torpedo into a small thermal exhaust port - only 2 meters wide - connected directly to the main reactor of the Death Star.
Let's say you "win" that market objective. What next? The Rebellion defeats the Galactic Empire, leaving a market leadership vacuum. The Rebellion begins to set up a new form of government to serve all (aka grow existing market and expand into new markets) and must grow larger, with more layers of management, in order to scale. (aka enterprise data governance supporting all LOBs, geographies, and business functions).
At some point this Rebellion becomes a new Bureaucracy - maybe with a different name and legacy, but with similar results. Don't forget, the Galactic Empire started as a mini-rebellion itself spearheaded by the agile Palpatine!
The Force is strong with you, Darth Karel, since somehow you managed to get a comment past my blog moderator :-)
The sustainability of data governance agility is a great question (and perhaps this explains the real reason why there wasn't a Star Wars Episode 7: The Rebellion Won! Now What?)
Smaller companies (especially start-ups) are often agile by their very nature. They have fewer customers, fewer systems, and easily manageable volumes of data, effectively delivering the critical information required to make informed business decisions everyday. However, as companies grow larger, they start trading effectiveness for efficiency, prioritizing short-term tactics over long-term strategy, and by seeing power in the data they hoard, not in the information they share, they choose business unit autonomy over enterprise-wide collaboration.
And in the early days of a company, the IT department is also often agile by definition. Technology serves business needs well when both the business and its needs are small. But over time, requisite staff are added and necessary new tools are provided to support rapidly evolving business needs. It becomes easier to simply re-invent the wheel over and over in response to immediate demands, as opposed to reusing components, or building shared services horizontally spanning vertical business boundaries. It becomes easier, for example, to simply export a copy of the entire customer database for replication and customization within another data silo, than to manage both shared data access and conflicting business requirements.
So, at some point, the purging good (the Agility Rebellion) often morphs into the inherent evil (the Bureaucracy Empire).
I call this the Collateral Damage of Success.
Great work guys -- bureaucracy creep has always been a problem of course, but with the complexity of integration and incompatibility, with adoption of the networked global economy, the systemic risk is just unacceptably high for the status quo, as we've realized in dramatic fashion repeatedly over the past decade.
So data governance simply must be very well planned in advance for security, adaptability, and scaling -- I disagree around the margins a bit -- it's not only unnecessary for most of the organization to understand, but I believe must be hidden from view and largely automated.
May the force be with you, and you and you and you!
Thanks for your comment, Mark.
You raised an excellent point about transparency -- how visible does data governance need to be?
I would agree that some aspects might be hidden.
For example, some aspects of data privacy, data protection, and regulatory compliance may require security levels where certain data is intentionally siloed and its very existence must be hidden from view and governed by a select few.
However, the guiding principles of data governance must be communicated to the entire organization.
And, at the very least, the high level aspects of the policies of data governance must be documented in a straightforward natural language that everyone can understand -- and be made available for everyone to view.
From the LinkedIn Group for DAMA International, Tore Hoff commented:
"I enjoyed this analogy, and even though you can have a good laugh, this is serious. Looking in the mirror, I guess I would have to put myself on the Dark Empire side, but I consider myself a Data Management Jedi - it's difficult to see who's behind the mask sometimes.
I think there is a fine balance. We need to listen to the rebellions, because they are an important part of the Data and Information cast list. Knowledge workers, engineers, geologists etc. in our organization are primary producers of value added information, and they are part of the big picture so we cannot rule them out or not listen to them. At the same time, these rebellions need to understand the need for some rules, and order in the masses.
One of the goals must be to make the rules on an acceptable level supporting the rebellion's needs.
I put myself on the Jedi council for now - may the Force be with us."
And I responded:
The Force is strong with you, Master Hoff.
Thank you for sharing your wisdom about finding the right balance between rules and rebellion.
From the LinkedIn Group for Data Governance & Data Quality, Peter Perera commented:
"This is a well done discussion on a timely theme. Of course, participation, collaboration and engagement will win out over bureaucracy every time...when we equate bureaucracy to a central controlling organization. If we take bureaucracy to mean definition and structure, then I see an environment of defined rules and structures (i.e. technologies and processes) that are not rigidly enforced but flexibly used by individuals to manage data.
This also assumes we do not take agility to mean anarchy. As differing definitions and structures will only further disintegration and not integration...will only further disharmony and not harmony.
Policies, technology and whatnot - I think they were called the 'enablers' - must unavoidably have definition and structure. But 1.) structure requires 'give' - like a bridge structure can flex to accommodate winds, earthquakes and so forth, and 2.) while structure is required, the usage of these structured 'enablers', well, enable collaboration and encourage collaboration and participation in data management.
Policies, technologies, processes and whatnot shouldn't exist to control and enforce, but to foster and engage individuals to manage data in pursuit of higher data quality across the organization.
It isn't so much balancing bureaucracy and agility as much as flexibly wielding defined and structure technologies, policies, rules and processes to facilitate and encourage agile data management."
And I responded:
The Force is strong with you, Master Perera.
Thank you for sharing your wisdom about facilitating and encouraging agile data management.
Via email, Steven Totman (aka Han Toto) commented:
"Han Toto believes that the right path is one where you dance with both the Empire and the Rebellion. Unfortunately, every group that tried to do that in the various Star Wars films ends up worse off (e.g., Cloud City, Ewoks, etc.). Also remember technically thanks to the prequels, which ruined my childhood memories of good films, the nice guys turned into the Empire before the reversal cycle begins with the rebels. So you have to be careful that your terrorist tactics (amusing how when you guys slaughtered the English in Boston it wasn't called terrorism) don't result in you becoming the Empire longer term.
The key has to be - pick your battles and agree what your going to govern.
You're correct in saying that it's people, process, technology, and most important, POLITICS, that determine the success. The technology is in reality just an enabler, though having a good business glossary (aka C-3PO and R2-D2) is critical.
But ultimately without the Darth Vaders of the world to enforce the agreements, data governance is all just talk."
And I responded: Well said, Han Toto. Well said.
Jim,
Yes we already have most of it automated in Kyield -- advances since our first patent application internally and in the surrounding technology has made it possible, but we appear to be in total agreement on transparency and communication -- self-destructive otherwise.
Thanks, Mark