July 11th, 2013
Some weeks ago (18th June) GlobalPlatform organized a TSM seminar a few subway stops from where I live, hosted by the Spanish Royal Mint (“Real Casa de la Moneda”, no less). No, they didn’t let us see where they print those nice Euro notes. But the food was excellent.
It was a busy day, full with interesting presentations about standards, frameworks, roles and responsibilities, key deployment projects… the final session was a roundtable where the key speakers responded to questions from the public. The very last question was asked by Kevin Gillick, GlobalPlatform’s executive director:
What is missing in NFC to make it a real success in the marketplace?
The participants answered:
All true, but in my opinion not the most important causes. Only one participant mentioned what for me was the elephant in the room: lack of a compelling business case.
On the subway ride home (feeling lucky that for once I did not have to endure an airport) I kept mulling over that cause, linking it to the deployment projects presented by my fellow engineers:
The more I thought about it, the more I saw connections between the overall system design and the (lack of) business case. By designing a system in which most interactions are tightly specified, relationships among actors have little room to change or develop alternatives not initially foreseen: technical decisions are almost determining the business model that might be applied.
Markets, especially technology ones, are constantly changing: it is very difficult to predict what will work and what won’t. Sometimes the only way of knowing it is launching products, experimenting, changing what did not work (if we are so good and so lucky to identify it soon) and retrying. We have seen NFC trials all over the world, but always driven by powerful institutions or consortia: while useful, especially to fine tune the technology, they are not the kind of experiments I am thinking. They are too expensive to run, not only in monetary terms, but mostly in terms of energy, agreements, commitments, etc. -not the best incentive to run many follow-up iterations.
Why not try a different way? Why can’t, for example, a small car rental company develop an application combining payment with loyalty and security functions and let its customers install it on their phones’ Secure Elements, without having to reach agreements with most mobile operators in the country (plus maybe some phone manufacturers too), which require a level of technical resources it can’t afford?
We certainly think it should be able to do so, and we are working hard to achieve it. It might not be the best analogy, but this story reminds me of the good old data communication protocol debate: the telco OSI tower, full of functions and overspecified, versus the TCP/IP stack, offering little more than connectivity. I’m sure everybody can say which model has generated more successful stories…