Oct 01, 2010Most RFID solutions are designed to meet an immediate business requirement. The end user, often working with a systems integrator, chooses RFID tags and readers, as well as packaged or custom middleware that either runs on a network or is embedded in the readers. The system works—RFID data is captured and integrated with back-end applications—and everyone is happy. That is, until things change. And change is inevitable, because the business benefits of RFID are like potato chips—nobody is satisfied with just one. As soon as asset visibility data improves one business process, you'll think of 10 more processes it could improve.
That's when you start to run into problems. RFID technology evolves rapidly, and adopting the latest products can reduce costs and improve performance. But if your solution was built bottom-up from a specific choice of tag and reader, you're probably locked you into a proprietary data format, so any changes could necessitate a total redesign. Even if you could leverage your RFID infrastructure, it may be difficult to repurpose data tailored to one application for use with additional applications. One of my clients wanted to scale up a 100-site pilot to 1,000 sites, but had to rework the entire application because the newer reader hardware couldn't replicate the data format embedded in the earlier system.
|
|
To avoid these pitfalls and prepare for change, take a data-centric approach, designing your RFID system to ensure the correct data flows between the two primary parts: the data-capture infrastructure (tags, readers and middleware) and the business applications. Start in the middle by designing the data that flows between these parts. The data should report "just the facts" of what was observed in the physical world, including the business context of why the data was captured. It should hide the details of how the data was captured and not make assumptions about how a business application will use the data. Reliance on an industry data standard, such as EPC Information Services (EPCIS), can help.
Test your data design by asking two questions: Could a newer-generation or different brand of data-capture technology generate the very same data? Will this data be meaningful to any business application that needs it? If the answer to both is positive, you're on the right track.
Complete the design of the data-capture infrastructure that generates the data, and the business application that consumes it. Choose products that conform to your idea of what the data should be, not the other way around. Questions such as whether to use middleware, or computers vs. dedicated appliances, are secondary. The data-centric approach frees you to consider such decisions on their economic merits and adjust them as the technology evolves. Change will come, but a data-centric design discipline will help minimize the pain.
Ken Traub is the founder of Ken Traub Consulting, a Mass.-based firm providing services to software product companies and enterprises that rely on advanced software technology to run their businesses.