Analyst Focus: RFID Middleware Market

User feedback producing clearer picture of customer requirements for critical functionality and support

User feedback producing clearer picture of customer requirements for critical functionality and support

Natick, MA — May 27, 2005 — With all the hype around stabilizing technical standards, evolving compliance mandates and persistent intellectual property (IP) litigation, one of the most important developments taking place in the radio frequency identification (RFID) market might be missed, according to a new report from technology market research firm Venture Development Corporation (VDC).

VDC writes in its report, "Radio Frequency Identification (RFID) Middleware Solutions: Global Market Opportunity," that early adopters and evaluators of RFID middleware are providing clear input on how to define, develop and deliver RFID middleware solutions. The market is elevating the need for RFID middleware to fulfill the promise of RFID return on investment (ROI). From 10-year operators of automated toll collection systems to 10-week evaluators of closed-loop industrial machinery tracking solutions, the fragmented RFID market is in alignment on what RFID middleware should do, and how it should be delivered.

To date, most of the VC dollars, engineering labor and analyst ink has been dedicated to coverage of RFID hardware development: interrogators, transponders, antennae, printer/encoders, etc. This work has produced rapid gains in solution performance, density and affordability. However, the results have not yet been powerful enough to clearly define, or deliver on, roughly defined value propositions in most market opportunities.

Why? The focus of RFID hardware development has been on producing solid signals that create clean, accurate data — a lot of data. The notion of developers focusing on managing RFID solution data — or data generating devices — was akin to putting the cart before the horse, or naming children before we had significant others.

No longer. VDC says its research on the emerging and fragmented market for RFID middleware reveals that current users and evaluators of RFID solutions are pretty clear on what RFID middleware needs to do and how it needs to be delivered.

The information presented in its report was based on VDC's ongoing RFID research. The data and information were collected in VDC-staffed telephone interviews and VDC-managed Web surveys of current users and evaluators of RFID systems and middleware solutions.

Market Requirement for RFID Middleware Functionality

Five features dominated customer requirements for critical RFID middleware functionality:

  • Provide consistent interface for RFID interrogator infrastructure. Standard interfaces — human, machine, network, application — do not exist across various RFID interrogator solutions. Customers investing RFID reader hardware have to make any number of compromises in their implementation plan: (1) support only one reader model, even if it is suboptimal versus other options for certain applications; (2) fund (by "rolling their own" or contracting with third-party developers) the development of a custom, common interface layer; and/or (3) leave certain applications unsupported due to the lack of a viable (read: cost-effective) integration solution.

  • Data filtering and transport. Similar to the lack of standard interfaces, users cite the varied methods used to filter, compile and route RFID data traffic as a key challenge during the implementation and integration process. Users are looking to RFID middleware to account for these differences — embedded as they may be in the core of the reader engines and controllers — and resolve them in a consistent manner.

  • Manage RFID reader/ interrogator infrastructure (device management). Key functions cited by users and evaluators included: local and remote health and wellness monitoring, upgradeable software/ configuration, and management and remote power on/off.

  • Support multiple host platforms requesting RFID data. RFID is expected to be deployed in a wide range of applications and installation environments. The IT infrastructure — including ERP platforms, department/ function bolt-on modules, and power applications — are equally diverse. Data structures, transaction formats and a broad diversity of other technical features will place significant pressure on RFID subsystems to support this menagerie of host platforms. The most often cited platform challenges included: warehouse management systems (WMS), order entry/ order management systems (OMS), transportation management systems (TMS), logistics management systems (LMT), supply chain management systems (SCM) and data warehouses.

  • Support legacy systems. In order to maximize ROI potential using RFID — or to meet emerging compliance requirements — users need to support legacy systems. These systems include a wide range of tracking and marketing equipment, network infrastructure and enterprise applications. Support is generally defined as the ability to process two-way transactions with select legacy systems.
Market Requirement for RFID Middleware Solution Support

Users and evaluators cited three specific approach and support requirements from their RFID middleware solutions providers:

  • Document and share relevant experience. Users need to be working with RFID solution or middleware suppliers that have direct experience in customer applications, installation environments, vertical markets and business models. This is a fairly steep requirement — and one that users acknowledged as such — but one that they were explicit about. In terms of the supply chain, the market does not yet include robust case studies that are shared publicly — or privately. Moreover, the current library of ROI models are equally sparse and difficult to translate and replicate across customer accounts. Successful suppliers will differentiate themselves by their experience and their ability to share it.

  • Deliver total solutions. This may be the most challenging issue to address. Too much is uncertain about RFID technical specification and system performance. Too many companies supporting RFID have very narrow capabilities. The RFID channel remains young, inexperienced and hugely uneven in its capabilities and performance. With all these moving parts, users and evaluators are understandably reluctant to commit to prototypes, pilots or rollouts. Successful suppliers will differentiate themselves and gain market access by investing in a total solutions or whole product market development approach. Given the enormous resources required to do this alone, this means that RFID solution and middleware suppliers will need to be proficient at identifying, forming, and supporting partnerships with suppliers of complementary technologies and services.

  • Live up to the expectations created by the big IT vendors. Most of the non-product related vendor selection is driven by user experiences with large IT vendors. Some of the most-often cited user-identified "benefits" of working with RFID solution and middleware vendors include: comprehensive on-site professional services; detailed software version and feature release roadways; and operational expertise complementing the technical solution.
VDC said that user feedback has not provided a simple, easy path to developing and marketing a blockbuster software package, but they have provided RFID solution and middleware developers with a few anchors to consider when defining their solutions and developing their go-to-market approaches.

More information on the VDC report is available at

Additional Articles of Interest

— For more information on trends relating to radio frequency identification (RFID), follow this link for an extensive listing of articles, featuring the latest research findings on the RFID, including adoption, return on investment and barriers to implementation.

— For a contrary view of the future of the RFID market, see the article "The O'RFID Factor: A 'No Spin' Look at Where Radio Frequency Identification Is Headed," in the October/November 2004 issue of Supply & Demand Chain Executive.