Article
People Who Live in Glass Houses Shouldn't
In the beginning, data belonged to the hierarchy of priests who dwelt in the rooms of glass, where cleanliness was more important than godliness. And the priests spoke unto the people, and they said, the data is ours and you shall not partake of it without a proper help desk ticket. You shall not partake of it until our schedule allows. Our claim is greater than yours. You do the mundane work of generating revenue, but we spend our days in the contemplation of the code.
And the people were demoted from co-workers to mere users. And the priests looked down upon them and thought ill of their priorities. It was a time of great darkness and, eventually, the very fabric of computing was rended and remade until the priesthood fell from grace.
A Byte in The Hand
Computers moved out of the clean rooms. They were forced to move out. Frustrated users brought PCs and other tools into the workplace to allow them to directly manipulate their data, their way, on their schedule. The spreadsheet became a weapon in the war to get around the priests of IT. Even those shops where the glass houses still exist have seen the sea change. Workers want to get work done, and if IT is perceived as a bottleneck, there are ways around them. Remember, bottlenecks create frustration and frustration can turn to anger.
Unfortunately, some of that anger has been turned against IT people who never acted like high priests. Oddly, some of the people who have taken up this negative attitude weren't in the workforce when the war ended. Some weren't even born at that point. It's an exercise in conditioning that would make B. F. Skinner proud.
For better or worse, the data is in the hands of the users. Smart IT people see these people as co-workers, as creators, and owners, not just as "users." All in all, it is for the better. So, if user's own the data
and
user ownership is a good thing,
and
we like to advance the cause of good things happening, what does user ownership of data mean to the IT professional?
Look Before You Leak
One thing it means is that Security is much harder. Just like in every other part of life, when something goes from "tightly controlled by a handful of people who operate in a single group" to "generally available to a wide variety of people with diverse skill levels and training" the ability to manage access becomes massively harder. For an easy example, in the glass house days, security had little to do with user rights management. Now many organizations depend on one or more full-time LDAP administrators to control rights. When a task which used to be a minor project becomes a full time job, that's a sign of a major change in the rules.
Even if you manage security to five nines precision, you can still have employees who do not understand the sensitivity of the data they are allowed to access. If Sally in accounting talks about that million dollar banking snafu at a cocktail party and Martin, who works at a competitor, overhears... So, when data moves from the few to the many, we as good citizens of our company need to raise the issue of staff confidentiality training.
Of course, inappropriate dissemination of data is often less dangerous than misunderstanding data.
Baa, Baa, Spread Sheet, Have You Any Wool
Joe plugs in his data, collected from the corporate system of record, and runs his many spreadsheet formulas against it. He proudly sends the results up to his manager, Angela. She looks at his work and concludes that the corporate system needs to be replaced because this is the seventh time this month that she has gotten conflicting data. Joe's report shows a gain of 5% over last year. Frank's report shows a loss of 3% over the same period.
Why? Is it because one of them did a bad job in manipulating the data? Maybe. It could also be that Joe has more access to data than Frank, so Frank's numbers only include three divisions while Joe is including five divisions. It could be as simple as "What does 'day' mean?" Joe might be including weekend sales into Monday, which at the break of the year pushes a lot of money from December 30th (last year) to first week in January (this year) which changes both totals. It could be because Joe is looking at Dollars and assuming gross, when Frank is looking at the same column and knows that it is net of standard overhead. Perhaps Frank pulled his data three months earlier.
When you have a limited number of people doing the reporting, these things are easier to sort out. Reducing the number of people does not eliminate the errors, but it does allow for rehabilitating the errors faster.
Data, Data, Quite Contrary
So, user ownership of data is a bad thing, the priests were right, and everything should go back to how it was. No. No. No. User ownership of data is more complex, but it is a good thing. To start with, IT knows if the data ties out but users know if the data is correct. For example, when I test order entry, I'll set up a customer and buy some products. When the sales people test order entry, they will expect it to reject certain combinations of products because they can't be shipped together. They'll expect that our fireworks division shouldn't be allowed to ship into certain states. They'll expect that quota will be checked on exports from China to the US on some classes of goods.
The problem with IT ownership of data is that we live on the wrong side of the screen. People who live and die on the details of a particular transaction set are better able to see the holes. They can tell if we've made things tight enough. They know if it is too restrictive. IT needs to partner with the users. We need to elevate each other to the level of co-workers.
What we bring to the table is knowledge of the architecture of the data. We know how it glues together. We know if a particular piece is being collected. We know where it is being used. Just as we know the structure (schema), the users know the content and the reasonableness of the data. We can't do the best job without them. Likewise, we can't abandon the data to them and expect success.
Jack Sprat Could Eat No Flack
Another reason for user ownership of data is, frankly, blame. When IT owns the data, we are at fault when it is wrong. We don't generally have the authority to change it, but we have the responsibility and, therefore, the blame. When users own their own data, we might share responsibility or they may own it in total.
In one of my past lives, I was a co-manager for Wenco, a Wendy's franchisee. Part of the management philosophy there was "You don't give the R without the A." In other words, Responsibility and Authority belong together.
It is also useful to remember that if Accounting owns the accounting data and Sales owns the sales data, getting it right is to their credit. If IT helps them get it right, while still respecting that they are in charge, that brings us credit.
Got a topic you'd like to see in Business Tech? Send it to
"Results@KeyAlly.com"