Data Governance Matters

Somebody wrote to me saying they could no longer find an article I’d written about the relationship between the phenomenon of the “Tragedy of the Commons” and working with data. Could I please, they asked, put it back up on the site?

They couldn’t find it because the article wasn’t originally published here. It was done for z/Journal (www.zJournal.com), where I’ve been working for several years with their amazing editor, Amy Novotny.

Anyway, Amy’s ok with reprinting information, so here’s the piece. And be sure to check out their publication.

Tragedy of the Commons

Nobody likes to be told “no.”

Most of us aren’t fond of saying it, either. But if you work with mainframe data, chances are you’re frequently put in the position of having to say No. Sometimes circumstances make this easy: the request would take your organization out of compliance with a contract, a law, or a regulation.

But then there are the other types of circumstances. The ones where compliance is required, but HOW you comply is up to interpretation. The ones where your organization has not created a clear set of rules to be enforced. The ones where they look to professionals like you to interpret the situation and then make a call.

Sometimes it’s easier to say No in such a situation if you can get the person who’s made a request to support the underlying reason behind your refusal. Today we’re going to talk about something everyone can support: avoiding tragedies.

The Tragedy of the Commons

This concept is often used to describe ecological situations, where the “commons” referred to are grazing lands open to all. However, the concept can also be applied to working with data, especially common resources (such as sets of mainframe data) that are shared by many individuals or groups but are critical to the success of the entire organization.

Have you ever been to the city of Boston , in the U.S.A. ? Early in the country’s history, the Boston Commons was covered with sheep owned by individuals, but nourished by grass grown on common lands. Today, this is a beautiful, lush public park; the story of sheep is often treated as a “cute” history lesson.

A desert in sub-Saharan Africa , however, holds a different type of history lesson – one that has resulted in tragedy for thousands and a lesson for us all.

Just forty years ago, the Sahel region in sub-Saharan Africa was a fertile pastureland. It supported over a hundred thousand herdsmen and over a half million head of zebu (their grazing cattle). The area seemed to be thriving; from the 1920s there can been a steady population growth of people and cattle. Between 1955 and 1965 the area had received both unusually heavy rains and the advantages that came from the development of deep wells.

Herdsmen were optimistic. Herd sizes increased. Eventually there were more cattle than the commons could support, so in the 1960s that area experienced overgrazing. This lead to loss of vegetation, which in turn lead to soil erosion. By the early 1970s, lush land had become desert. 50-80% of the livestock was dead, and much of population was destitute.

Looking back, the reason was clear: individuals took actions with common resources that – when considered individually – seemed reasonable. But collectively, they added up to more than the system could support, and the system collapsed. Ecologist Garrett Hardin wrote about Sahel and this phenomenon he called “The Tragedy of the Commons.”

Acting Selfishly

It’s human nature for individuals or organizational silos to be selfish – especially if they can gain by acting selfishly in the short-term. It’s also natural for the cumulative effect of selfish actions to go unnoticed. But if no one is watching over the health of the commons, a tipping point could be reached, where irretrievable harm to the greater system is done.

Data Commons

Peter Senge, in his book The Fifth Discipline, spoke of other situations where we must apply systems thinking to protect our own commons. It’s an excellent book; one everyone should read. But you don’t have to read it, I’ll bet, to cite examples of how you’re expected to protect your organization’s data commons. Are you expected to assist with Data Quality? Availability? Compliance with regulatory requirements? Many disciplines – and many corporate programs – have sprung up to protect data commons.

It’s worth noting, though, what most of these programs haven’t learned from ecological tragedies.

According to Senge, you avoid The Tragedy of the Commons with one of two strategies: through centralized management, or through voluntary self-restraint. Either can work – but ONLY if they have the right support structure and cultural values.

For the first strategy to work, the manager of the commons has to have power to say No. Period. End of discussion. Your sheep ain’t coming in, so go away.

For “voluntary self-restraint” strategy to work, you have to know what puts your commons at risk, the chances of those events occurring, and where your tipping point may lie. In other words, you need to have a Risk Assessment. You also need clear metrics, and a method of letting everyone know that the commons is being stressed. You need clear guidelines for what to do when it’s stressed, and accepted roles and accountabilities for when the organization has moved into “save the commons” mode. You need individuals who are willing to place the health of the whole over their immediate wants and needs, and you need a system of governance for resolving disputes.

The underlying goal of may compliance efforts is to protect the integrity of data commons. No doubt you’ve adopted the centralized management strategy for some compliance issues, such as Sarbanes-Oxley or Access Management. If your organization is trying to avoid this approach for other applications, they need to remember the support that must be in place for voluntary compliance and for you, if they’re expecting you to say No so you can avoid your own version of The Tragedy of the Commons.