Evan Schuman's StorefrontBacktalk

Fair enough. Dorf then reported on some glitches encountered during the data-write portion. “Writing data takes a big longer and moving the phone away from the reader during a write operation will cause an error. When a coupon is redeemed, we may want to erase it, or add a new one during checkout. This extends the time even longer. The fastest approach might be to simply store a read-only unique identifier on the phone that a third party can link to a loyalty number, list of coupons and payment choices on some far away server. Forcing all the work to the back-end servers would certainly simplify the role of NFC but also require the POS to be online.”

Dorf’s point about politics and turf control is a valid thought. But the fear goes both ways. How many retailers will fear opening up their CRM databases, wondering if the details might possibly leak back to the processor, to the phone (What? Apple might record something private? One can’t imagine such a thing!) and possibly wind up in the hands of a rival?

All of this gets us back to the question, “How much of a delay will this deliver?” The practical point is that consumers will likely accept any reasonable delays, as long as the offerings are ubiquitous enough. Remember the early days of ATMs and all of those consumer complaints? Whatever happened to those complaints? The consumers got used to it and the banks—being banks—smiled and ignored them.

One person who had strong concerns about what Dorf posted was J.P. Norair, the chief architect with Dash-7, a non-profit wireless data alliance with member manufacturers, systems integrators and developers. Norair posted a comment to Dorf’s piece, where he argued that “the biggest problem with speed isn’t the NFC, which is faster than older passive standards, but crappy middleware and crappy, message-based middleware protocols. The comm lag between the reader and the thing that is issuing commands and processing the data is the biggest source of slow performance. Taking NFC to 1Gbps (which isn’t actually possible) isn’t going to solve the performance issue.”

Norair also pointed the finger at “so many serial lines between POS and POP terminal still run at 9600 bps.” and lots of “messaging protocols require full circuits, all the way to the database, for even the most mundane commands.”

In a telephone conversation on Wednesday (April 20), Norair said his key concern is that too many POS systems today are designed to make a 200-milisecond (one-fifth of a second) round-trip hit for every individual task. “It needs 3 to 6 hits just for the authentication alone. The rest—for user data elements, preference setting, cookie equivalents, timeouts, things like that—take at least two and maybe five more hits,” he said. Instead, Norair argues that it’s better “to write a middleware protocol instead of hitting the server every time. A cloud model doesn’t scale wirelessly. And everything on some central server, that doesn’t scale at all. Some intelligence has to be brought down to the endpoint, to get latency down.”

The problem with Norair’s argument is: To what end? That’s a lot of effort and money and for what benefit? Will shaving off fractions of a second—and at most, maybe one full second—make any meaningful difference to the shopper’s experience?

Is a customer that hard to entertain for two seconds? Couldn’t that time be filled with a “paper or plastic?” or “do you have your club card today?” question?

IT people often strive for the ultimate in efficiency and needless delays are maddening. In this instance, though, the practical business reality is to just endure those frustrations. If the customers won’t notice, it’s really hard to cost-justify it.