March 24, 2008, 1:03 PM — Suppose for a moment that your first name isn't Bob or Dave. Maybe it's something less common, like, say, Barack. Or instead of Jane or Sue, it's, oh, maybe, Hillary. And to be fair to the common man, let's include a more oft-used name, perhaps John.
Now suppose that Barack, Hillary, and John travel a lot. They'd need passports to do that. And though it's not printed in any passport, the way people are uniquely identified is through their Social Security number and street address, stored in the passport database. That's pretty sensitive information, the sort of stuff we'd want to stay private.
As we all know from our programming or systems analysis days, in a good transactional system, a log record is written to a journal file every time a data record is accessed, changed, deleted, or added. In mainframe-speak, we called it CICS journaling; Novell used to call it TTS, or transaction tracking system. Whatever it's called, I'm sure you agree that journaling is important, not just for reconstructing the data file should it become corrupted, but also to track exactly who's doing what.
The hundreds of records that an individual worker might access in a typical business application on any given day are likely pretty ordinary stuff (payroll applications notwithstanding). But imagine in a typical data file with general accessibility that there's a field, we'll call it VIP. Anytime a record with the VIP flag turned on is touched, a manager -- somewhere -- gets a report. Who gets the VIP flag? Probably movie stars and professional athletes. Politicians, too. Access one of these records and your boss will know.
There might be a legitimate reason for access, perhaps an address change to, say, 1600 Pennsylvania Ave. in Washington, D.C. So far, so good. But let's say that over a short period of time, the manager sees the records for our three intrepid travelers, Barack, Hillary, and John were each accessed multiple times. If I was that manager, I'd sure want to know why. There's a distinct possibility that no legitimate reason for accessing these records exists. Unfortunately, the report doesn't list a reason.
You can bet the manager would say, "If I catch you doing this again, you're outta here, and I'm reporting it to my boss to cover my own backside." That's what I'd do. And then it happens again. And again.
There's a problem here. But that problem is not what the average citizen thinks. Bob, Dave, Jane, and Sue might be quick to blame a "computer glitch," the term that makes IT professionals everywhere cringe when they hear it on the news. But the system worked perfectly. Access to certain records triggered a reporting mechanism. The proper notification was generated. The problem is actually one of user error, not leveraging the information provided to its fullest capabilities.
The fact is, we all work very hard to make computers, not people, do the heavy lifting. That's why in automotive factories robots now do the welding and painting. But we too often forget that the data our computers store and the information they generate are intended for human consumption. There's nothing we can do about that.
As solutions providers developing intricate systems, it's important that we not allow our customers to lose sight of the people who operate these systems, put data in, and read the reports that come out. That's not a technical issue, but an education and training issue, likely among the fee-based services you provide. "You got the information, you got the report. Now what action are you going to take?" That's what separates a successful business from an abject failure.
Yes, I could have stuck to more ordinary names for my little scenario. But I'm sure that our hypothetical travelers, Barack, Hillary, and John would want those with responsibility to act by assuring that private information remains private. I'd say, "we would, too," but face it, none of us are likely to have that VIP flag turned on.
