| A Single Source of Truth | KEVIN RESCHENBERG
01-03-2007 |
A rant.
I had a very pleasant trip visiting family over the holidays. But along the way
I was exposed to a few system-related glitches, mostly under the control of
a particular airline whose systems seem rather untied or disunited.
Denver had weather problems.
The first flight was delayed an hour. But don't worry about your connections,
announced the flight attendant, because most
connections were probably delayed as well. Just look at the monitors in the
terminal, but keep in mind that at the Denver airport, flights are removed from the display
after they were supposed to have left, whether they have actually left or not!
Of course, I didn't believe this: that's just silly. My next flight was still on the board but
was marked "closed." I interpreted this to mean "door closed, ready to push back."
So I stopped running and started walking toward the gate. But upon arriving, I saw
that the door was very much open and boarding had not even begun. What luck!
Well, sort of. I arrived at the destination but my luggage didn't. The next day
I called the automated baggage tracking line and was
asked for the ticket number and whether I'd already submitted a claim (no). "No
problem," the voice said, because the bag can be tracked. Unfortunately, all
representatives were currently busy. But instead of the usual music and "your call is important
to us," this system just hangs up if there is nobody immediately available to take the call.
Nice. Tried again. Same thing. Tried the local number that had been given by the
baggage agent at the airport, but that number went unanswered.
So I called the reservations number, reached an agent, and was put through
to a baggage number that was answered immediately! (For best service, call the wrong number, not
the right one.) This agent asked for the baggage ticket number but couldn't seem
to find the bag in the system. Then she asked for my name but still couldn't find
the bag. Finally she asked for the flight number and then found the
bag. (?) The bag showed up a day late but intact.
Time for the return trip. The automated notification system called me to say the
first flight was cancelled and to call a reservations number. The agent there said the next
available flight was a day later. Any availability on another airline? An immediate
"no." (I'm sure he tried very hard.) What about my second flight—is that still
on schedule? No, that's cancelled too. Eight hours before it's supposed to leave?
This began a series of inquiries online and off, by phone and in person. Here's the
tally of answers received. The first flight was cancelled according to the automated
notification system, the reservations agent, the online flight status, and the
agent at the airport. It was on time per the online itinerary and the flight status
board at the airport. The second flight was cancelled per the reservations agent and
on time per everything else. I took a short bus trip to the connection city and flew home on
the "cancelled" flight.
At every step there were indications that these various interconnected systems
lacked a single source of truth—one place to look to find the reliably correct answer.
The Denver airport system apparently thought the clock was the best place to look
(and I'm still scratching my head over that one). The baggage tracking system
couldn't find a bag despite having a good, unique key, but could find
it using related attributes. The web site displayed two different
flight statuses at the same time. The second airport display apparently didn't
have the same source of information as the ticket agent's terminal, and so on.
We often face the same issue. This seems particularly common in the benefits
area, where we are dealing with various third party systems. Larger companies may have
dozens of different benefit plans and providers and interfaces. It is then particularly
important to identify the one official owner of every piece of data.
For example, where is an employee's address stored? Well, we have that in our
PeopleSoft system, of course. The benefit provider may also need it. As long as
we feed this information to the provider, there should be no problem. But what happens
if the provider maintains a web site at which the employee can enter an address
change? I once worked on a project where the employees were to be able to maintain their
personal benefits-related information in three different systems. Fortunately,
we were able to reduce this to one.
The one owner of each piece of data must be explicitly identified, and all parties
must know it. However, this can change due to circumstances. For example, the
PeopleSoft system might be the owner of active employees' addresses, but an external
system might be the owner of addresses for retired and terminated employees.
Even though those employees' addresses remain in the system, they might not be
reliable. Ideally there would be one place for a terminated employee to update
this address and it would then be propagated to other systems that need to know, but
this is rarely the case.
Another example is where the company has outsourced payroll and/or a service
such as 401(k) administration. If the PeopleSoft system is expected to display
history of paychecks or 401(k) activity, then it is critical to receive an inbound
interface containing actual amounts. I've seen companies attempt to "predict" the
results by doing calculations in PeopleSoft and displaying those. That generally won't work.
The actuals must be loaded on a regular basis. In this case, the external system
is the single source of truth for payroll or 401(k) balances.
Normalization of data structures is generally effective in avoiding these problems.
Of course, it's difficult to normalize a database that logically extends to
third parties' systems. Watch out also for timing issues related to batch processing,
where a change sits in a staging area before it is updated. Even "changes-only" or
"delta" interfaces present opportunities for error, and I usually try to push for
full-file interfaces wherever possible.
|
