The great possibilities of IoT: For innovators, IoT promises new opportunities to create solutions that connect cars, homes and buildings to handheld devices in previously unimaginable ways (see Chuck Brooks posting). The time to define the technical direction is now. However, at the moment, IoT is just forming. The IoT space is like a primordial soup composed of fragments that will eventually combine to become the DNA behind a vibrant ecosystem. The chaos will soon become orderly, but before it does a lot of competing developments will need to bump into each other in novel ways, crashing and competing for a few years before a dominant strain emerges. The technical architecture to make IoT a reality is still in development, but the major priorities have been identified. There are three elements needed for a coherent IoT application architecture to evolve from the concept stage to reality.
IoT Alternative Communication
The technical foundation of IoT is an orchestration environment that allows devices to communicate and share without having to construct and provision each service to manage the routing and efficient management of what the IoT devices is designed to do. Clearly, Wi-Fi is not an ideal communication layer for IoT: it’s asymmetrical, client-to-router protocol that isn’t optimized for creating the ad-hoc device-to-device connections that a true IoT environment will require; and then there is of course security (note – not enough space in this entry to discuss this fully – but you can use your imagination). For interactions between devices in close proximity –Bluetooth is the obvious alternative, but again security issues keep it from being seriously considered at this time as an IoT communication layer. New developments promise to fix Bluetooth’s security aches, but more on that later.
API Framework
Next comes the API framework for IoT nodes to communicate with each other. For Internet of Things to work, it has to work seamlessly: applications and objects must be able to share data and communicate with each other regardless of their underlying platforms. There are many contenders for a standard IoT software framework, but none has as much cross-industry support as the AllJoyn framework. AllJoyn enables the creation of ad-hoc “buses” between applications, devices and objects running different software. Qualcomm released AllJoyn’s source code into the wild in 2011, allowing device makers, appliance manufacturers and developers to peek inside its innards and play around, and since then it has gained traction in numerous industries.
Developers can write apps in whatever language for whatever platform they prefer: the AllJoyn framework—or something like it—will handle translating and busing between apps and devices running on different proprietary and open-source platforms. No user wants to switch between different apps or devices to perform different tasks like turning on the lights, starting the coffee maker or checking the fridge. Developers don’t need a monolithic API for all IoT-enabled applications and devices if there is a common API framework that is adopted by app developers and appliance manufacturers.
IoT Security
Last but certainly not least is THE ISSUE of security. The Internet of Things promises to inaugurate a brave, new promising yet risk filled world if hackers can turn your lights off, open your doors and disable your alarm system remotely. That’s where Mesh comes in: it’s a protocol layer developed by CSR (a British company bought by Qualcomm in late 2014) that sits atop Bluetooth and provides banking-level encryption to Bluetooth communications. Bluetooth, Mesh and AllJoyn are crucial stepping-stones toward a coherent IoT architecture.
Working for the Future
In the next five (5) years Enterprise IT will be required to adopt and deploy IoT platforms in order to serve their B2B and B2C customers. The inevitability of the extension of the business enterprise businesses through technology makes the choices of application architecture and platform a requirement in planning today. Too many companies have learned at their own peril that putting off the technology inevitable does not work. Discounting the IT function, IT executives and managers, is a risky path for C-level suite executives, and one often taken in the course of “budgetary concerns”, but most often short-sighted and inaccurate when true ROI is clearly calculated. For the responsibility that lies within IT, the choice of technical architecture must take in to consideration scale, integration and security. For CIO’s the time is now to learn, discuss and define a path for IoT platform and application architectures. They should not be dissuaded in convincing C-level colleagues of the business importance, and should get their homework done in preparation for educating the enterprise where it will need to go to leverage and use IoT. The first step? A definition of the Application Architecture – emergent from the early stages of IoT evolution, which will serve as a basis for the great possibilities of the maturing of IoT.
