in Living on the Edge – An IoT Architecture for The Enterprise I provided some history to support what I thought was the most logical architecture for Enterprise IoT. In this post I intend to point at a few examples that support my position.
As a result of a consulting engagement in 2004 I found myself smack dab in the middle of the chaos caused by the Wal-Mart RFID initiative. Wal-Mart had recently announced that their suppliers would be required to affix passive Radio Frequency Identification (RFID) “smart” labels to cases and pallets of products shipped to Wal-Mart distribution centers. In simple terms it is easiest to describe RFID as electronic barcode. The primary difference between RFID and barcode technology is that barcodes require that the scanner has direct line of sight and can only read one barcode at a time. RFID does not require line of sight between the reader and tags and hundreds of tags can be read simultaneously. At the time these readers were fairly basic data collection devices that sat at the edge of the network and passed raw data on to other applications for processing.
Wal-Mart would occasionally hold meetings for their suppliers where they could learn about new technologies and speak with vendors who could help them meet Wal-Mart’s requirements. A significant portion of the individuals in the RFID industry hail from the world of barcoding. A small percentage, the people who make tags and readers, have their roots in RF. Many have a solid understanding of software but a limited few have any experience in the enterprise. What this means is that Wal-Mart imposed a mandate on hundreds of suppliers that required they invest in immature technology from vendors with limited experience in enterprise IT. This was going to be interesting.
While attending one of these Wal-Mart supplier meetings I first heard the term “RFID middleware”. What these “middleware” venders were actually doing was aggregating data from RFID readers and sending it to a flat file or database. I distinctly remember speaking with a vendor who explained that their SAP “interface” was based on a CSV file. I’m fairly certain SAP would have taken a dim view of their claims. There were several stand-alone offerings that enabled suppliers to meet minimum Wal-Mart requirements but nothing that I would consider enterprise class.
A few years later I was at a conference where the mythical “RFID Middleware” kept popping up. There were a few true enterprise software companies (e.g. IBM, BEA Systems) that stuck their toe in the water but they moved on when they realized the market had yet to develop. Eventually I stumbled upon a company called Trancends which was promoting an Open Source middleware platform called Rifidi. What these folks had done was build Web Services interfaces for leading RFID readers that enabled Java or .NET developers to do much more than simply parse raw reader data. In my opinion the first true enterprise class solution that was designed to support edge operations in RFID implementations. Better yet, they offered this solution pre-installed on a low-cost Linux box that was damn near plug-and-play. For enterprise organizations interested in expanding their projects beyond the minimum Wal-Mart requirements this was an attractive option.
Fast forward several years to the emerging market for “Internet of Things” (IoT) technologies.
While a great deal of the hype surrounding IoT is based on consumer applications I am much more interested in the potential for IoT in the enterprise. The primary challenge would be trying to figure out how to securely integrate machine-to-machine and/or sensor data with applications distributed across multiple locations and platforms that may include mainframes, windows, linux, and mobile operating systems. To further complicate things you need to consider cloud computing and a variety of communication paths including wireline, wireless, cellular, and satellite across multiple service providers. Oh, and it all needs to be cheap, secure, and easy to deploy.
From the earliest days of distributed applications integration has always provided the biggest challenges. Early message-oriented-middleware solutions from companies like Tibco or IBM’s MQ Series where the first to provide truly robust integration platforms. With the advent of Java application servers, web services, and rapid application development platforms, enterprise middleware was born. The promise of enterprise IoT lies in extending the tried and true distributed computing model closer to the point of sensing where data can be turned into actionable information in near real-time. In an effort to be fully buzzword compliant this is being referred to as “Fog Computing”.
The early market leader for a rapid application development platform that abstracts interfaces across an enterprise IoT ecosystem appears to be ThingWorx (now a PTC company). I am not in a position to offer an opinion on their technology but I am hugely impressed by the list of partners supporting their platform. One of these companies, Camgian, has developed a highly capable enterprise fog computing appliance (software pre-installed on COTS hardware) called “Egburt“. Egburt is designed to be installed on-premise to collect and processes data close to the point of sensing to minimize the potential impact of network latency and help avoid what could be significant costs associated with cloud computing. That’s a nice value proposition.
What companies like Transcends and Camgian have done is pragmatically applied proven technologies and decades of practical experience to provide enterprise class solutions to early adopters of emerging technologies. In both cases an edge server was the most logical choice. The “software as hardware” model keeps the total cost of ownership down (no software licensing “gotchas”), facilitates early adoption, and greatly simplifies the process of scaling applications across multiple locations. This approach is elegant in its simplicity and is exactly what the industry needs to help promote adoption of IoT solutions in the enterprise.