InformationWeek, May 24, 1999

Transaction-processing is one area of computing that has remained adamantly system-driven. No concessions to human factors here. You can put a charming user interface on the front, but when the time comes to submit a transaction, the computer calls the shots and sets the pace. 

The software that keeps transactions secure and synchronized is—and by its nature has to be—utterly unforgiving. It demands that the human user navigate flawlessly through a complex series of interactions with the back end in real time. If any data is incomplete, erroneous, or out of order, the next screen will refuse to appear. If a problem arises that will take some time to resolve, the session halts and all the work up to that point is lost. If the session goes on too long, many applications will simply abort.

Human beings tend not to work like this. Most complex business processes in which humans play a part get put together over time, in a stop-and-start sort of way. It’s not a question of short attention spans; this is the way decision-making works. Often it is necessary to look something up, consult a specialist, get an approval, wait for some documentation, have some detail clarified. The customer on the phone may get half way through placing the order and realize he can’t go on until his wife gets home. The person at the computer may—heaven forbid!—want to go to lunch.

Since transaction-processing applications don’t want anything to do with interruptions or delays, people approach them with their ducks fully in a row. They turn to the computer only when the information has been collected and the decision made. The truth is that transaction-processing systems exist to record the results of a business process that has been conducted the old-fashioned way, via phone calls, emails, messengered documents, face-to-face conversations, and perhaps stretches of just thinking things over.
 
We’d like to see all that system intelligence—those vast capabilities for remembering, organizing, and communicating—helping out way earlier in the process. If transactions were made long-running, a “NewHire,” for example, could begin the minute a new resume got scanned in, follow the candidate around on interviews, gather up school transcripts and security clearances, record the back-and-forth salary negotiations, and—if all went well—ultimately transact with the HR database and enroll the candidate as a new employee. (As this example shows, once a transaction becomes long-lived, it can also be collaborative, since the person who picks up a pended transaction after some period of time does not have to be the same person who worked on it before.)

What’s needed is not a change to the formal transaction submission process, but rather the addition of a preliminary stage—a sort of transactional staging area. This “pre-transaction” might populate itself from the enterprise data store, get modified by one or more human users, and eventually hook back up with the database or TP monitor to attempt a formal commit. There are challenges here; for example, a long-running transaction needs a way to check on whether the underlying data has been changed by someone else the meantime —did the employee whose raise you are working on quit over the weekend?  But the results could be transactions that are more efficient, more accurate, and far more humane to use.

You can require employees to engage with inflexible and time-sensitive transaction-processing machinery. But customers and partners who encounter your business on the Web will not be so patient. Certainly E-commerce requires real-time transactions at certain points. But at other points it also requires browsing, shopping, mulling over, and trying out non-binding “what if” scenarios on the way to a full-fledged commitment. The “real time” for that sort of thing could be minutes, days, or weeks.