RFID Software needs a New Year’s Resolution
Posted by Patrick Sweeney on Thu, Jan 07, 2010
Last week, ODIN kicked off a project to deploy 17 data centers with RFID for one of the world’s top banks. Should you be surprised that they are moving to deployment or why it took them so long given the clear return on investment of RFID IT Asset Tracking? It was clear that there great RFID asset tracking success stories abound like Airbus and others. However, some short term thinking has halted progress in the RFID industry like an anchor grabbing hold of a solid reef – the DoD’s Alaska Project come to mind when I think of ships run aground. Much of the fault or credit goes directly to the software strategy those organizations adopted. So I thought it would make sense to show what makes success or failure in RFID software.
The Problems with RFID Middleware
There are three major problems with traditional RFID middleware:
1. The software is not optimized with the RFID physics in mind
2. Many middleware companies require additional servers because they are another enterprise application in disguise
3. Integration and support are a nightmare with enterprise ERP systems like SAP or Maximo
Unfortunately many software companies don’t have an RFID lab and can’t Benchmark RFID Equipment to know how their software effects the performance of an RFID device. Some companies only have the ability to interoperate with one or two readers and use trial and error in the field. This leads to software convenience driving reader selection and in a world where no one size reader fits all use cases, this too often leads to poor performance and cumbersome exception processing.
What you should look for in RFID middleware
There are a handful of features to look for that will ensure success in an RFID deployment they are:
1. The software can control the reader operation at the deepest level to ensure optimal performance
2. There is a mechanism for high-availability that does not require adding more servers which burden you with associated costs and support headaches
3. The software should not try to replace SAP’s, Remedy’s or Maximo’s functionality, but should augment those solutions
4. You should cap the integration period to a couple of weeks when getting started
5. The “as-is” business processes should be changed to drive a solid and measurable ROI
RFID’s New Year’s Resolution
One or two RFID vendors have it right. The software is built in a high availability, peer-to-peer architecture and it’s built with the physics of RFID in mind. Then the best companies take it one step further and actually go through rigorous testing and Benchmarking in an RFID lab and with real-world use cases.For those companies that don’t follow that prescription – here’s a New Year’s resolution for the good of everyone in the RFID industry. If you are making RFID software, especially if you have raised millions of dollars in VC, stop wasting time working to be Microsoft ‘s Gold partner or attending IBM’s Pulse Conferences, those are for mature industries. RFID isn’t there yet. Focus on removing the adoption barriers:
1. Make your RFID software work with 99.9% read accuracy by understanding the physics of RFID and how software can enable better performance
2. Create easy integration onramps to existing enterprise applications
3. Set up a lab that is more than a conference room, because last time I checked not many manufacturers, data centers, or retails use conference rooms to do anything other than talk.
4. Listen, listen, listen to what customers want and then give them what they need.
If the industry can follow these four simple rules, we’ll have a lot more stories like Airbus and J&J and the handful of RFID software companies will have more business than they know what to do with, and most importantly clients will be happy.
For a more detailed analysis of RFID software, click here to recieve a copy of ODIN's Whitepaper "Seven Secrets to RFID Software Success"