The software world is 10 years ahead of the IoT world when it comes to architecture.
In the 80’s and 90’s most companies had just one IT system and software was developed in-house. This changed in the 2000’s where companies realized that they could lower their IT-costs by purchasing standard software for ERP, billing, planning etc. So to move data between the standard software solutions, integrations between them was built. Of course these integrations were vendor specific, and communication was synchronous — so if the remote system was down, then the procedure call (like a HTTP request) would fail and if you wanted to replace the remote system, a new integration was needed (vendor lock-in). In software terms, this is called a tight coupling.
Service Oriented Architecture and MicroServices
To solve the vendor-dependency problem, the software world then invented the concept of loosely coupled systems and MicroServices; A Service Oriented Architecture in which the interface and responsibility of each microservice (system) is well defined and hides the implementation details. For example, to integrate your ERP system to your task-management system, you design a generic interface between them so that you can easily replace the task-management system with a new task-management system from another vendor. Another benefit is that all the other systems that has integrations to the old task-management system, don’t have to create a new integrations to the the new task-management system. In other words: Clearly defined interfaces: One new system, one new integration.
While this solved the vendor-dependency (lock-in) problem and simplified the integration landscape, it still had the problem of being a synchronous — if a system was down then a retry-policy and/or error-handling needed to be put in place. Also, updates to systems needed to coordinate with every other dependent system in order to avoid downtime.
Message Queues — asynchronous communication
So the software world introduced Queues. Now, every time a system sends a request/message to another system, it will put it into a queue. This de-couples the systems completely and allows for asynchronous communication: The sending- and receiving system does not need to be online at the same time. Suddenly, taking down a system for maintenance could be done at any time and no service would be interrupted or no data would be lost. When the system came back online, it would then continue emptying the queue from where it left off.
IoT-architecture today
Most IoT solutions today are vertical: They have their own proprietary:
- Sensors
- Connectivity solution
- Analytics system or application
- API
They are integrated directly into their customers systems — that is, their APIs are used/invoked directly. In software terms, this is called a tight coupling.
You can probably see where this is going…
The IoT architecture of tomorrow
Building owners are realizing that verticle IoT-solutions does not scale and have too many drawbacks. Surveys also shows that. Think about it: It does not make sense to have multiple motions sensors in each room (alarm system, lighting, room-usage%, adaptive cleaning). Or multiple temperature/CO2 sensors… That’s not all, building owners must have multiple connectivity solutions, one for each vertical IoT-solution.
Obviously, having ONE SINGLE motion sensor (or temperature/CO2 etc.) and use that output for all data-consuming solutions (alarm system, lighting, room-usage%, adaptive cleaning), have a long list of benefits:
- One-time installation for sensors
- Simpler integrations (only interface/integration to data-consumers change)
- Save batteries (no multiple motion/temp/co2 sensors)
- No need to replace the entire sensor-system if vendor goes bust
- Sensors are commodities — replace with any vendor
- Covering your building with wireless IoT-connectivity only need to be done once
- You own and control all the data generated from the sensors
- Enables innovation: Extremely simple to build a find-me-a-meeting-room-now app (motion sensors are already there)
- No vendor lock-in — just tell your adaptive-cleaning-vendor to use your existing sensors
- Environmentally friendly: Re-use or re-purpose old sensors (today you can’t re-use a proprietary motion-sensor from one vendor and use it in another vendors system)
What about queuing — asynchronous communication?
Scholars agree (and Xerox PARC (for you history nerds)) that the future of IoT networking belongs to Content-Centric Networking (CCN). In a CCN network, the endpoints communicate via name-based data instead of IP-addresses. The object of encryption is the data, not the connection. Routers (called Content Stores) in a CCN networks caches the data (message queuing) so that data-consumers can retrieve it at any time. This enables wireless offline devices to retrieve commands/data when they wake-up. This is true asynchronous communication. CCN networks, like IP networks, has no single point of failure.
Z-Mesh, an Open Source, CCN-inspired IoT networking protocol, is solving the problems discussed in this article today. Z-Mesh combines the naming-scheme and publish/subscribe feature from MQTT with the CCN features and is thus familiar to use. Anyone can build devices, routers and device management systems. If you want to help build on this vision and eco-system, please contact me.
Aer Networks is a company that delivers Z-Mesh IoT sensors, wireless forwarders and device management software and is sponsoring the Z-Mesh initiative. Please contact me if you are interested.