We learn from the past by studying patterns. What works? What doesn’t work? This can be applied to social media, mobile technology, data analytics, cloud computing and the Internet of Things. Technology is changing and moving at breakneck speeds, and recognizing patterns can be very helpful in adapting to and adopting new technologies. I’ve been thinking about applying pattern recognition to some of the challenges we are seeing with the IoT. Are there emerging or existing patterns that could be useful? Perhaps. Let’s take a look at a brief history of the personal computer (PC), as well as the evolution and subsequent challenges of connecting peripherals or accessories; some of the patterns may be applicable and useful. Disclaimer: Much of this discussion has a definite bias toward Windows-based PCs rather than Macs. Still, the concepts transcend.
In the Beginning: Serial and Parallel Ports
In the early days of PCs, the primary mechanism for connecting peripheral devices was through either a serial or parallel port interface on a computer. This was at a time when the primary accessories were dial-up modems and users were limited in the number of devices that could be connected, based on how many of these ports were built into a particular PC. Functionality on such devices was minimal, yet these ports were the bus for transporting messages to the device and the operating system (OS). Many times, applications used generic drivers for the port, meaning they needed to know specifically how to communicate with the device through messages over the generic port drivers.
This pattern of providing applications with specific knowledge about particular devices can be seen today in many IoT devices currently on the market. It is a useful pattern, but limits the devices’ growth and usage. In a recent article published by Forbes, writer Doug Newcomb said that during the past year, more than a dozen smart home platforms have been introduced, “guaranteeing another year of automation and security gadgets in your house that don’t talk to each other.”
Expansion Buses: ISA Begat EISA
Expansion buses are the primary mechanism for connecting devices, peripherals or accessories to computer systems. They serve as the standard way for an OS and devices to communicate with each other. In the PC world, the great-grandfather of them all was the Industry Standard Architecture (ISA)—a rather grandiose term at the time—bus. The ISA bus allowed for a surplus of devices to be connected to a PC. It also allowed for bus mastering, which enabled controllers on the bus to communicate directly with other controllers without having to go through the processor or the OS. Speed and addressing limitations led to further bus evolution, including the Extended Industry Standard Architecture (EISA). One interesting aspect of the EISA was how it was implemented to allow backward compatibility to ISA cards. The EISA utilized the same form factor as the ISA, except it allowed for more connection points. The shorter ISA cards would use the existing ISA connectors, while EISA cards would have additional connectors on the longer tabs.
The bus pattern and mechanism allowed for much greater growth and usage of devices with PCs. By maintaining a level of backward compatibility, vendors provided users with the ability to upgrade their environments and ecosystems (their PCs), while maintaining the use of devices in which they had already invested. The bus provides the standard method of communicating and sharing messages, while the OS provides a standard way for applications to access the devices without needing to understand the intricacies of the messaging and hardware.
Auto-discovery, USB, Wi-Fi, Bluetooth: Brave New World, Brave New Risks
Let’s fast-forward to the present day, when we connect devices to our PCs physically, via a Universal Serial Bus (USB), or wirelessly, such as through a Wi-Fi or Bluetooth connection. The computer’s OS auto-discovers these devices, finds the drivers on the Internet and configures itself to provide a connection for applications to leverage. Wi-Fi and Bluetooth, in particular, have become virtual buses for our PCs’ accessories, whether we are talking about printers, keyboards or webcams.
All of that convenience does come at a price, however. Everything is a tradeoff. The tradeoff here is increased risk, especially in the area of security. Internal buses created physical connections. You knew the device that was connecting to your system was safe, since you had the physical control. Now, with this virtual bus, you need to be sure the device to which you are connecting is the actual device you perceive it to be. There are mechanisms in place to mitigate risk. One example is Wi-Fi Protected Setup (WPS). A user initiates this at the target (the router), is provided with a personal identification number (PIN) and can then initiate a connection from the device using that PIN. This helps validate that you have physical access to both, limiting the risk of allowing an unplanned device to connect to your virtual bus.
This model works for devices I want on my network. The challenge will be this: How do I determine if that device should have access to a cloud environment, or if the cloud environment has access to that device? One way may be to extend the virtual bus pattern to a cloud bus, with devices and clouds mutually authenticating each other.
Will the Cloud Become the New OS and Bus?
No analogy is perfect, including the one I have just presented. In the Internet of Things, we are already connecting a massive amount of new devices to a virtual bus. In the process, though, we still communicate with these devices with specialized applications, harkening back to the days of serial ports on our PCs. In order for us to get full value from this brave new world of things, we need to think about how we make it easier to connect and share these devices and the information they provide. Wireless communication standards are not enough. They allow a physical connection, but do not address the virtual connection of devices to cloud environments for mutually agreed access.
Perhaps, if we were to think of the cloud as an operating system, and define a virtual cloud bus for connectivity, this could provide a standard mechanism for all of our devices to communicate with other devices on the virtual cloud bus. That, in turn, could help lead us to solutions for the ecosystem challenge. Will it work? It is difficult to predict at this early stage, but I will say this: The patterns are interesting, and it will be fascinating to see where these technologies take us.
Ed Featherston is a senior enterprise architect and director at Collaboraive Consulting.