InformationWeek

In sketching the future of E-commerce, analysts insist on the importance of real-time transactions. This would mean definitive confirmations, shipping information while you wait, and electronic banking that doesn't take "a minimum of five business days." Speeding responsiveness is inarguably a good idea. But we suggest another way to improve business transactions: Slow them down.

Transaction processing is one area of computing that has remained adamantly system-driven. There are 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-unforgiving. It demands that the 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 won't appear. If a problem arises that will take time to resolve, the session halts and all the work to that point is lost. If the session lasts too long, many applications will simply abort.

People don't work this way. Most complex business processes in which humans play a role get put together over time, in a stop-and-start way. It's not a question of short attention spans; this is the way decision-making works. It's often necessary to look up something, consult a specialist, get an approval, or have a detail clarified. The customer on the phone may get halfway 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 tolerate interruptions or delays, people don't even launch them until everything is ready. They turn to the computer only when the information has been collected and the decision made. Put bluntly, transaction-processing systems exist to record the results of a business process that has been conducted the old-fashioned way-via phone calls, E-mails, 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-help out earlier in the process. If transactions were made long-running, human resources, for example, could have an application that would kick in the minute a job candidate's resumư was scanned, follow the candidate around on interviews, gather school transcripts and security clearances, record salary negotiations, and, if all went well, ultimately transact with the HR database and enroll the candidate as a new employee.

What's needed is not a change to the formal transaction submission process, but rather the addition of a preliminary stage that serves as a transactional staging area. Such a "pretransaction" might populate itself from the enterprise data store, get modified by one or more users, and eventually hook back up with the database or transaction-processing monitor to attempt a formal commit.

There are challenges here; a long-running transaction needs a way to check whether the underlying data has changed. For example, did the employee whose raise you're 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 use inflexible, time-sensitive transaction-processing machinery. But customers and partners who encounter your business on the Web won't be so forbearing.

Certainly, E-commerce requires real-time transactions at certain points. But at other points, it also requires browsing, shopping, mulling over, and trying out nonbinding "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.