The Internet of Things (IoT) is a really big deal, especially as technology changes in the current environment. Making it extremely important for businesses to have an IoT strategy in place. It’s important to build an IoT plan so the business can:
- Assess where it is now and what there is to work with.
- Know where it’s going, and how to evolve and stand out from its competitors.
- Identify any challenges and how to use data to solve them.
The first step on the IoT journey is to understand what IoT is and how it impacts the world.
What is IoT?
The IoT is highly complex, so the best way to understand it is by getting a view of the IoT structure. Or in other words, the IoT Reference Architecture, officially known as the IoT World Forum Reference Model. This architecture is similar to other technical models, but with a few new layers. These layers exist in all IoT implementations, but will be configured and built differently within each to meet the goals of the project. This diagram gives you a visual of the IoT architecture.
Normally a technical project starts with the end results, be it the user experience, the files, reports and so on. From there, we build back down the technology stack used to support the result, creating what we need to deliver. This follows the accepted project management paradigm.
Something to understand about IoT projects and this particular architecture: it gets built upside down. For this, you actually start with goals, they are ‘true North’ for project requirements. The technology then begins with the sensors and builds upward. We move toward it instead of backing away from it. This lets us identify and adapt to the physical world from which we gather our data. Then we apply multiple technologies, pushing it up to our applications and users, building the solution we need like stepping stones in front of us.
Let’s take a deeper look at the various levels in the architecture.
8 levels of IoT Technical Reference Architecture
There’s virtually no end to the type of sensor that may be required for various projects, the choices are wide open. They’re as varied as the problems they help to solve. Most look like a postage stamp, a little widget. These are combined with other sensors in a casing appropriate for their purpose. In the end they can resemble a digital thermometer, a wand, a small box or a hockey puck. They can take almost any shape you need. This allows customization to suit their location and actions. Pick your purpose and then dive into the overwhelming world of smart sensors.
The primary job of any network is to transfer data, route data traffic and manage throughput. This has evolved to support different communications protocols. The IoT has introduced other communications methods and protocols to run them, and these communications protocols push network capabilities into new territory. These new protocols employ different communication frequencies and channels. This keeps networks from getting more congested.
At this layer, there are intelligent devices at multiple points within the network. These devices, known as the Edge, the Fog and the Mist computing models, check the data as it comes across and acts upon it where defined. While these terms are used interchangeably, they are actually different levels of detail within the same stream. All three share the same purpose:
- Push processing power—‘compute’—closer to the source
- Segregate to minimize risk and increase reliability
- Cleanse data for easier transport
- Allow responses to fit the need in the time required
Edge: devices that reside on the very edge of the network, pushing intelligence and processing power closer to the source and outside of the cloud and primary data repository. Edge nodes have the most processing power outside of the central applications. They directly support sensors or other nodes close to those sensors. While very strong in distributing data, minimizing risk and putting processing power closer to the device being monitored, there are limits to the scalability of a strictly Edge system.
Fog: Next comes the Fog, newer than the Edge and originally introduced by Cisco to increase scalability. As its name implies, it is closer to the ground, below the Cloud, outside the Edge. Fog nodes bring distributed compute to the local area network level, each node taking in data from sensors within a defined geographic area. Fog nodes filter and normalize data before passing it up, minimize risk by limiting device access, pushing code updates to the sensors, and speeding things up through preprocessing and programmed responses.
Mist: The Mist further extends the Edge and Fog models by pushing compute into the sensors and actuator units themselves. It brings the awareness of the physical environment, bridges area gaps, and provides additional units of compute with periods of self-sustainability. Mist nodes provide adjustability with timings and specific rules. Again, there is more complexity, but nodes are now interacting directly with geo-spatial data: adding scalability, response time and security.
The Cloud is often assumed with IoT projects, but it should not be a given. There are situations where an IoT infrastructure needs to be placed on-premise. In that case storage architectures are managed much as they are today. There are also hybrid models to bridge both Cloud and on-premise, depending on the data in use. For those situations there is a variety of hybrid strategies that can come into play.
5. Data Abstraction
Data Abstraction collects different data pieces and makes them available for analysis. These days every enterprise has some level of Business Intelligence (BI) skills, but it’s imperative to engage these resources in the early stages of your project discovery. This will help identify any gaps and bridge them, so you can expand the existing structure, and augment solutions that are already in place. Once those engaged recognize this, breaking down data silos gets easier.
6. Application Development
Once you’ve analyzed your data, how do you identify which results are reactive, proactive and predictive? This is a sweet spot where App Dev and Analytics coordinate. Most organizations are comfortable with reactive—fix a problem after it has occurred. However, they may be familiar with proactive—preventive maintenance or actions that keep things healthy. Once a business begins to receive predictive data, the ability to get to a potential—but as yet unknown issue—before it causes an incident is where true IoT converts are made.
7. People and Business Process
One common cause of IoT ‘stumble’ is the way it is often started—from within one group. This is where business units struggle most with IoT, as it takes a much larger perspective to maximize the value to the entire business.
Q: Who are the Data Value Beneficiaries (DVB)—the groups that could benefit from the data?
A: Virtually every area of the enterprise and their business partners.
Every IoT project should determine all the DVBs. This activity produces more use cases for the project, helps fulfill more goals, and increases overall ROI. Most IoT projects can be illustrated with data feeds to activities across many, if not all, departments of the enterprise.
Human beings and our responses to new technology should also be taken into consideration when building out a project. People are often afraid that automation will take away their jobs, and to some degree this will be realized. The economic term is ‘constructive destruction’. It has always existed, but is cycling faster now with the exponential expansion of technology. This also comes with a potential opportunity to eliminate delays, realize operational efficiencies, create safer workplaces, enhance existing processes and security, minimize failures, provide new and better services and products, save lives and evolve our workforce. In most cases, the trade-off is worth the effect.
The IoT process has intent: to provide enhanced insights, operational efficiencies, new revenue streams and improved processes. So it’s important to be overly security-concerned when considering that it might also provide convenience in the development, build and install processes. This includes direct human access or scripts we may run that have embedded passwords in them. While production support teams seem to be slipping out of fashion—having been incorporated into the development and product groups—this may be a good time to bring them back. Having a small number of well-trained individuals as the only ones in the production environment can both mitigate security risk and limit human error. Utilizing login management tools to handle all passwords to production systems is a requirement, no longer a ‘nice to have’, it is a necessity to keep your production systems safe. These tools consider all production system user id’s to be privileged, and can require they be tied to a change or incident ticket to activate. They can also notify the security desk and track all keystrokes during the login. This keeps every action visible, unable to be hidden or disguised.
For IoT success, collaboration is essential
There are eight distinct levels to the IoT Technical Reference Architecture. Each of these levels has its own requirements, caveats, potential pitfalls, skillsets and solutions. None can be treated lightly, each has a significant role to play. For any IoT project to be successful, it needs to engage every area of the business, which takes knowledgeable leadership, skilled planning, organizational cooperation and technical expertise. This kind of synergy doesn’t often appear organically, but it can be achieved with the help of a trusted IoT partner and implementer.