Issue #149 | June 6, 2008 | by Venkat Krishnamurthy

Last week we reviewed the critical issues to be considered when deciding on the implementation strategy for your RFID initiative. Since all RFID deployments have different variables to one degree or another, your implementation will almost certainly be different from a comparable project underway at similar company.

This does not mean lessons cannot be learned by reviewing what other companies are doing. In Part 1 of this article (Your unique, evolving RFID Plan) we went over the basic concepts you should consider to ensure success.

A key consideration is how to balance the seemingly incongruous goals of keeping your RFID system separate from, but still integrated with, back-end systems.

To illustrate this concept, here are a few industry applications in which RFID integration provides benefits where your new RFID system and other, existing systems may come face to face:

• Integration with ERP systems may trigger inventory replenishment when low stock is detected.
• Integration with manufacturing execution systems may allow you to track products and component parts through each stage of the assembly process, alert production staff when errors are detected.
• Integration with warehouse management systems can help ensure inventory rules are followed to prevent expired goods and salvage.
• Integration with maintenance and repair systems can be set up to verify parts and equipment against service orders.
• And integration with business activity monitoring dashboards can be used to update dashboards to reflect physical inventory levels, orders shipped, manufacturing efficiency.

These are obviously just a few of many, but the point here is that while you want to avoid imprisoning data within your backend systems, your RFID system must provide adequate communication so you can achieve improvements.

Choosing Development Approaches
As the RFID industry has grown, organizations are confronted with several development approaches. While each has some advantages, one of them will best enable you to take advantage of the recommendations above.

1. Custom Development with RFID Middleware & Appliances: It’s true that this approach simplifies data collection and data management, but by hard-coding business rules, calls to back-end applications are cumbersome to maintain and modify down the road. Much like with ERP systems, RFID appliances aren’t the best approach. They simply aren’t designed to evolve over time, so they compromise your ability to maintain and upgrade your system.
2. Business Process Execution Language (BPEL) Systems: BPEL engines are great fits for monitoring bbusiness activity and developing executive dashboards. But because they are process-centric vs. data-centric, they aren’t ideal for RFID processes at the edge of networks.
3. Configurable Packaged Solutions: This brings us to configurable packaged solutions. If you’ve read this far, this isn’t a surprise. These systems include business context and rules engines, are often industry specific and are easier than other options to modify. And while a given system may not fit your particular industry or application exactly, they are configurable. You should expect that such a system has enough built already for you that you have a foundation and that it comes with a set of tools and environments that make it relatively easy to build your RFID system and integrate into your backend systems.

RFID projects are daunting enough without employing a solid, well thought-out strategy. So consider this advice, which is based upon the successes and failures witnessed over many years. It just might make a difference for you and save many sleepless nights.


Venkat Krishnamurthy is chief technology officer for OATSystems, a provider of RFID solutions (OATSystems.com - Transforming RFID Data into Value).