In 2004, when I hosted the first Data Governance Forum at Mohonk Mountain House, I had three teams of IBMers developing the narrative discussions for three tracks on a common use case. The tracks were called "Infrastructure," "Policy," and "Content." The use case was "Data Supply Chain." The Forum had two days of meetings stretched across three, starting in the afternoon of the first, going until lunch of the last. On the only full day, we hosted the three breakout meetings, and each team worked to integrate their track discussions around the use case. The use case came from some business process definitions software group had developed for business component models, something to do with insurance claims processing. As it turns out, we had only one or two insurance companies at the event, and we spent more time focusing on the track headings and business process model than on the idea of a Data Supply Chain. A conference is always the product of the people and the ideas in a room, regardless of what one puts on the agenda. And at this first event, when most of us only had the most vague understanding of what "Data Governance" was or could be, business processes were familiar and Data Supply Chains were distant.
Three weeks ago, I hosted another Data Governance Forum at Mohonk Mountain House. It was again two days of content stretched across three, and again a very diverse group of people came together to produce discussions that were engaging, powerful, and divergent from what was planned on the agenda. In three breakouts on "Data," "Risks," and "Governance," the panelists and audience exchanged ideas and I ran back and forth between the breakout rooms to listen, learn, and occasionally drive the conversations. What I heard among talks about Data as an Asset, Risk Taxonomies, Governance models, and Security & Privacy, was the loud echo of Data Supply Chains reverberating off the walls. It was like an archetype of the first meeting, the temporary suspension of historical time, as if in all these years of Data Governance we had lost the original truth, like a spring disappeared under the ground, rediscovered at the source.
Every company does Data Governance today, for ill or good, with intent or dystopia. Every company also has at least one, but often many more, supply chains. These are real supply chains that may only stretch across one or two towns or six continents. Supply chains link producers, distributors, and consumers. They enable outsourcing and resourcing. And they are a fixture of modern business since business became modern in the mid-1970's. And with disciplines like Six Sigma, large multi-national supply chains enable massive economies of scale with quality control that previously were only available to the largest organizations with fixed multi-year labor contracts.
Today every organization also has large distributed Data Supply Chains. Some parts may be automated, others batch, and still others quite labor intensive. The variety and function is often the ugly mess the CIO would not like the world to see. And with seldom exception, they are not "governed" with anywhere near the same quality control and rigor as are real supply chains. When an oil company puts down a new oil terminal, well defined engineering processes are used to map out every step of production from well head to refinery. If Data Supply Chains are intended to capture the same kinds of flows with information, the methods used are mostly ad-hoc, one-off dependent upon project leader, never to be repeated again. And the result today is that companies have tens, hundreds, and even thousands of ad-hoc supply chains designed individually, some existing in their original state for decades. The disconnects create massive inefficiencies, quality control problems, and functional friction.
What every company should be doing is inventorying their existing Data Supply Chains and begin re-engineering. There should be one Data Supply Chain engineering standard. And each new real-world supply chain should include a well defined process to create a logical and efficient Data Supply Chain that monitors itself. This is not a small undertaking. But we can't create a Smarter Planet full of sensors and instruments to monitor the changes in our real world if we do not also monitor and instrument, standardize and re-purpose, the changes in our own enterprise.
Every time I speak to an IT audience, I ask "What is Data Governance?" Of course the audience has come to hear me tell them the answer if they do not already know. But I'm more interested in what my audience thinks. Invariably, the answer has words like "Policy Enforcement," "Control," and "Compliance" in it. And to me what this reflects is a desire among IT professionals to expunge chaos and confusion from their world and create order, stability, and simplicity. Perhaps this is very human, but I think our desire to transform complexity to simplicity focuses far to much energy and attention on the world "To Be," or perhaps even on the world "Never-To-Be."
I think we need to spend more time focusing on the world "As Is," the one with dirty, grimy, confusing, and complex Data Supply Chains that are not yet instrumented, monitored, or in any way Smart. It is this world that needs the bright white light of assessment, discussion, policy, implementation, audit, and dynamic steering. This dark and dishonorable world "As Is" is the past most of our Data Governance programs struggle to change in the present with business plan funding for the future. It needs new methods that monitor the information flowing through its electronic veins, real-time auditing of the tools that are used to change it, and brand new business intelligence solutions that analyze past performance, compare them to current conditions, and predict blockages and failures.
In 2009, at the Mohonk Mountain House, back in the place where it all began, surrounded by 52 Data Governance Thought Leaders, I saw again the source that we mistook all these years - Data Governance is a quality control discipline for the Data Supply Chain.
Fix the world that is.