We have all heard the old cliché about history repeating itself. Somewhat surprisingly, this repetition even happens in the world of technology. Seriously. Technology obviously improves over time, but tech trends tend to be repeated from time to time, as discussed in my article on cyclical technology. Another thing that I have noticed over the years is that technological innovation very often gives a nod to the past, without directly mirroring a previous innovation. Back in the 1980s, for example, the floppy disk was the portable media type of choice. Today we still have portable media in the form of USB flash drives and external hard drives, in spite of the fact that Internet connectivity has become nearly universal. USB flash drives have almost no resemblance to the floppy disks from so long ago, and yet they serve a similar purpose. So with that in mind, I want to talk about another technology that may be poised to evolve – plug and play.
Today, almost every computer system board provides ports for networking, sound, video, and more. However, that wasn’t always the case. There was a time when networking your computer (or adding sound or other functionality) meant installing an add-on board. While this might not seem like a big deal, especially in light of the fact that we still use PCI cards today, things were different back then. Anyone who wanted to extend their computer’s capabilities had to assign each expansion card a unique hardware interrupt number (IRQ), direct memory address (DMA), and base memory address. These values were assigned to an expansion card by installing a series of jumpers. Because each expansion card had to use unique values, computer techs of the time had to keep track of which IRQs, DMAs, and base memory addresses were already in use elsewhere in the system.
Plug and play: A good remnant from Windows 95?
Of course, hardware-level configuration was only the first step in making a device work. It was often necessary to manually configure device drivers to match the underlying hardware settings. Windows 95 changed all of that, or at least it tried to. Windows 95 introduced a feature called plug and play. Plug and play was designed to make it so that hardware devices could be installed and used without the hassle of setting jumpers or keeping track of which hardware interrupts and memory addresses were already in use.
Many people regard Windows 95 as a miserable failure. There were lots of problems with plug and play, and with quite a few other operating system features. In a way, this was to be expected though, because the operating system was so far beyond the previous Windows release in terms of its capabilities. Eventually, Microsoft got plug and play to work, and it is still being used today.
OK, so I’m sure that right now some of you are wondering why I delved into a history lesson involving a 24-year-old operating system. The reason for this is because I have a feeling that we are on the verge of seeing what I like to think of as plug and play 2.0. Keep in mind that “plug and play 2.0” is a term that I just made up, and has absolutely nothing to do with any actual standards that may exist.
The important thing to understand about plug and play as it exists within the Windows operating system is that the technology is about much more than freeing us from the task of setting jumpers on expansion cards. It’s about having an operating system to be able to automatically identify and use a brand new hardware device, with little to no effort being required on the part of the user.
Of course today’s world is vastly different from the way that it was in 1995. Today IT focuses much more on connected systems than on individual devices, and this is where I think that plug and play capabilities are headed next. In 1995, there was a need for an operating system to be able to automatically identify, configure, and use the devices that existed within a single computer. In 2019, the need is for connected systems to be able to automatically identify and use one another’s available resources.
Tell it to the marines
There are already numerous technologies that are designed to detect and use various types of networked resources, but what is lacking is a universal standard that works across device types and service types. Believe it or not though, the marine industry has offered such a technology to boaters for years. It’s called NMEA 2000 (or NMEA2K or N2K for short).
NMEA 2000 compliant devices are all attached to a backbone network segment that runs throughout a vessel. When a new device comes online, it essentially announces itself and its capabilities to the other devices onboard. A new GPS receiver, for example, might provide data that can be used by a boat’s autopilot system.
Smart display devices found throughout a vessel might be able to display GPS position, sonar imagery, engine health information (temperature, RPM, battery charge, etc.), video from an onboard entertainment system, and more. These displays have few capabilities of their own, but can provide diverse functionality as a result of their ability to recognize and communicate with the other devices on the boat’s network.
As a boater, I can personally attest to the fact that NMEA 2000 works really well. What I find most interesting about NMEA 2000, however, is that it works because marine electronics manufacturers adhere to a common standard, thereby allowing completely unrelated devices to work together in somewhat unexpected ways.
Plug and play redux
So what does NMEA 2000 have to do with enterprise IT? Well, for right now, not much. As you may recall however, I said earlier that I think that we will soon be seeing the rise of plug and play 2.0 (which again is a term that I made up, and does not refer to an existing standard), and that the hallmark of this new flavor of plug and play would be the ability of separate devices to recognize and interact with one another.
While this idea admittedly sounds a bit like a pipe dream, I just can’t help but to think of the so called IoT revolution. Today, nearly every electronic device imaginable supports some type of connectivity (WiFi, Bluetooth, etc.). Even so, the IoT device industry might best be described as a free for all. Devices have almost nothing in common with one another, aside from adherence to a basic communications protocol such as TCP/IP.
Imagine, however, if IoT device manufacturers adopted a universal communications standard similar to what the marine industry has adopted with NMEA 2000. The degree to which these devices could interact with one another would be greatly expanded.
In some ways, we are already seeing the beginnings of this. For example, a huge variety of devices already work with Alexa. Imagine the possibilities however, if these devices could work with one another, without Alexa having to function as a central communications hub. I could just imagine for example, the thermostat in my house realizing that it is hot outside, and then checking to see if my car is parked somewhere other than my garage. If the car is found to be in a blisteringly hot parking lot somewhere, then the car could be instructed to close its moon roof cover and to deploy its rear sunshade in an effort to keep the vehicle cool. That’s just one example of how completely unrelated devices might work together.
Featured image: Shutterstock