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.
