Being an ‘Architect’ is a title with big meaning suggesting bold outcomes. The architects of the world have left behind medieval cathedrals, the Taj Mahal, the Pyramids, and the Great Wall. Closer to or world engineering world are computer chip architects and telecommunications network architects whose titles sound more important than just designers. After all, architects seem to use more fundamental building blocks when they build, things like foundations, walls, pillars and domes to balustrades and architectural details producing a well-constructed attractive design that will withstand the wear and tear of the ages, or at least last for a couple of years.
When it comes to the Internet of Things, someone even coined the ‘4 Pillars of IoT’ on which the Internet of Things Architecture rest. Big words yes, but there is something to breaking IoT into 4 architectural parts which make up any IoT implementation. From a system engineering perspective Things, Connectivities, IoT Platforms and Applications describe 4 succinct parts that are separated by easy-to-understand systems interfaces made up of electrical signals, protocols and APIs.
Using this vocabulary and concepts, the world of an IoT solution should be understood as defining what makes up each pillar and how they interact with each other to form a complete solution. However, it does not stop there. Each pillar has its own architecture, and the IoT Architect has to understand how these elements are made up and, in some cases, even make some or many of the decisions as to how they are implemented. OK, not all, as the IoT architect can rely on existing connectivity solutions instead of designing them. Same goes with Things where device architectural decisions tend to be made by the manufacturers of these devices rather than by IoT architects. Finally, IoT applications use many of the same architectures and implementations as web and mobile applications so IoT architect can latch on to them for the IoT solutions. Given all of this, what are the decisions that need to be made by an IoT architect. Here are the key areas described in some detail:
What are you Building? – IoT Solution Goals – This may sound like a silly question but many IoT solutions are started without clearly defined business goals. Adding connected features and product attributes to existing products and ‘let us get into IoT’ are probably the most common ones. The first leads to a gradual approach and the second to an idealistic one. Gradual tends to expand in all sorts of directions while idealistic ones fail to deliver product revenues. An IoT architect can help by leading the discussion within the company about how to reach realistic revenue producing goals that are part of a longer-term strategy. The IoT architect should have the big picture understanding and the small step implementation knowledge.
The IoT Solution ‘internal language’ – Data Model(s) – IoT is about collecting, processing, understanding, and delivering data in one form or another. Deciding how that data is represented is one of the most consequential decisions of an IoT solution. The reason is that it must be both common and comprehensive, meet today’s needs and be flexible for the future. Common means that it is used by all parts of the IoT solution – Pressure is measured by identical numerical values and units from any device all the way to the different applications. Events have to be defined so that all parts of the implementation can report and respond to them. Comprehensive means that the data model covers and represents everything that is happening. Today’s needs are easy to understand but what about the future? Future machine learning may not be possible without adding additional sensor data or events. The IoT Architect needs to decide on the common data model that meets all these needs, document it and make sure that it gets implemented in all parts of the architecture. IoT device firmware must support not only data, but derived events. Communication protocols have to support transfer of the data model and the Data handling platform needs to handle and process all aspects of the data model. Finally, applications should be flexible enough so that they can easily support new data and events and deliver the visual and numerical results.
Selecting the Pillars Parts – This is the sexiest part of an IoT architect’s job. After all, only the right pillars will support a beautiful architectural solution. But the 4 pillars support and interact with each other so they cannot each be selected in a vacuum.
Architecting the Pillars
The illustration used for this blog show 4 very different pillars on purpose. Things come in all shapes and forms. Connectivities provide access to the Internet world. Data Handling Platforms provide the critical support for functioning IoT solutions as all data passes through them. Finally, Applications, the reason for IoT, are in most cases implemented using the same app and web server technologies as the Internet. Let us take a look at Architecture challenges of each.
Things are obviously physical devices designed by mechanical and electro-mechanical engineers. In order to become Internet Things they also need an electronic part providing data processing and electronic connectivity and we will focus our architecture on these parts. The electronic architecture has two parts, physical and programming. Physically, components are mounted on some type of circuit board connected to the rest of the Thing with physical wires and to the Internet vis physical connectors or to an antenna function for wireless connectivity. In addition, the electronic part needs to be powered, something easy to do in a powered Thing, more challenging in a device not connected to a power source where batteries have to be used. When implementing the physical part, a number of architecture decisions have to be made. While a good electronics designer is capable of making these, in IoT a knowledgeable IoT architect can contribute by assisting in component choices, electrical interfaces and connectivity parts. Knowing the broader IoT solution design allows for better physical design in choosing the right component flexibility, power budget and overall function, especially as the electrical design functions will most likely be monitored by an IoT application. Software architecture decisions involve more than just programming languages and protocol stacks. A well designed IoT product should have an IoT software agent implemented. This agent handles a lot of IoT related functions like data processing, transformation and handling as well as managing connectivity, authentication, security and operational functions like IoT functional monitoring and updates. While implementation is done by embedded software engineers, there are plenty of architectural decisions that warrant a broader perspective provided by a good IoT Architect.
Connectivity architectures for IoT tend to be defined by the connection technologies used. In some cases, like cellular, the architecture is provided by cellular service providers and connectivity architecture decisions are limited to cellular device connectivity, data needs, rates and recovery after connectivity disruptions. many decided by the Thing architecture. The same can be said when connecting to existing LAN or WiFi networks. The connectivity architectures already exist. At most, these may need to be rearchitected for better coverage, performance, or reliability. However, between Cellular and LAN/WiFi there are a number of connectivities methods that do require architecting in order to assure reliable communication. Mesh, LoRaWAN and BLE are the most common, but industry specific types also exist. These need to be architected as they rely on a gateway that connects to the web via WiFi, LAN or in some cases direct connectivity to an Internet Service provider. Continuity of communication and recovery after interruption are architectural challenges that have to be addressed. Finally, with 5G, satellite communication is coming back in force as an inexpensive way of connecting IoT devices to the cloud worldwide. These service offerings are launched as we speak and into 2023. Many of the connectivity architectures have data traffic limitations associated with technology and for cellular and satellite, pricing. Data traffic engineering is therefore needed to assure that a solution is functional, especially after a communication outage where thousands of devices suddenly want to re-connect and update.
A good IoT architect needs to master the use of existing and evolving connectivity methods, their weaknesses, and strengths and maybe most important, how they are set up, provisioned, and managed over time. Monitoring reliable connectivity is an important part of an IoT solution and only a thorough understanding of connectivity methods will assure robust IoT connectivity solutions.
Data Handling IoT Platforms is where traditional computer science trained engineers feel most at home. After all, is this not the same as architecting any internet or web solution? Unfortunately, this is not the case. The Application pillar of IoT have very strong similarities with web or mobile application solutions but the Data Handling aspect of the IoT platform requires different designs and architectures. The reasons can be summarized in the following functions they provide:
- Handle and manage a large number of data streams to/from individual IoT Things
- Process and act on individual data and event items delivered through streams in real time.
- Process and store data so that it is available to a number of different IoT applications
- Integrate information and content sourced or derived from other sources than the IoT things.
- Provision new IoT Things and update existing ones
- Handle authentication, security and encryption for large number of IoT things, often of different types and from different manufacturers
- Support and enforce a common language within the IoT Solution
- Provide management and administration applications for IoT Things, Connectivity and Applications as well as IoT Platform functions
Architecting an IoT platform from scratch is no small undertaking which is one of the reasons why there at one time were more than 500 companies offering various versions and degrees of IoT platforms. Lacking viable business models and the introduction of cloud base IoT platforms from AWS, Microsoft and others meant that most of these companies went out of business.
What remains is to buy an IoT Platform from 4-5 remaining vendors or do it yourself. Strangely enough, the number of companies that still choose the latter is surprisingly large given the architectural complexity needed to support the required functions and needs. Part of this is historical. Companies asked IT departments to add IoT to other IT provided functions or felt that IoT was just an extension to existing data processing and web site implementations. All you needed to do was to add modems or internet connectivity and store all incoming data in a data base. For applications, just connect an app server to the same data base and voila, you have an IoT solution. The Architecture is simple and builds on already used IT solutions. Any additional functions are bolted on to this rudimentary structure and can use traditional application/data base architectures.
The problem with this implementation is that it supports few or any of the functions that an IoT platform provides or the needs it serves. Architecting a modern IoT platform is a very different undertaking where data handling, processing and transformation drive the architecture that supports and integrates with external elements and sources of information using a Services Oriented Architecture (SOA). Architecting a Services Oriented Architecture is not difficult, you just define all the services and implement them with a (micro)services platform. This differs from the traditional approach in that instead of focusing how a capability is implemented (programming language, operating system, software design) it defines it as a service with a well-defined services interface reached through microservices calls. In this world, complex integrations and direct data base dips suddenly become no-nos. It is also ideal for cloud computing. Each services component can run in its own instance irregardless of whether it is old or new.
With this foundation architecting the Data Handling IoT Platform becomes an exercise in defining all the services that are needed, decide on the best solution for each service and integrating them within a microservices software framework. Instead of software engineering and integration expertise, the architect needs to understand all the services that are needed, select implementations from either a catalog of existing services available inhouse externally sourced, or developed for the IoT solution in mind. A good IoT architect selects a flexible services architecture that supports all existing and future services needs and then implements the IoT platform architecture or selects an already existing solution that can be customized to meet the same needs.
The architecture of the last pillar, Applications, is divided into two areas:
- Web and Mobile applications using standard implementation architectures.
- IoT solution specific applications associated with each company. These can range from alarm solutions and scheduling systems to financial transactions, managerial applications, reporting systems or specific analysis or computational applications.
The former uses the same architectures as any other web or mobile app and can be integrated with the Data Handling part via microservices or common data base interfaces. The latter are highly specific and are typically treated as applications external to the IoT solution. From an architecture perspective these can be treated as external services accessible through micro-services or API calls. The IoT architects job is to define all of these services and decide how they are connected to and interact with the IoT solution.
As can be seen above, the World of an IoT ‘Architect’ involves not only every aspect of an IoT solution implementation but requires a wide variety of knowledge in areas such as device IoT SOC chips, connectivity technologies and architecture, modern services-based applications design, API and microservices, data models, protocols, authentication, security and more. What an IoT Architect does not need to know is details how each piece is implemented, i.e., programming and programming languages, programming technologies and methodologies, SQL programming or details about how any of the surrounding systems and services work.
Mats Samuelsson is the CTO & VP Marketing and Business Development for Triotos. In this role, he is responsible for the new business, development, integration, and deployment of Triotos technology initiatives.