Please rotate your device.

Our website uses cookies to ensure you get the best experience while you’re here.


An Introduction to Building IoT Solutions

By: Joe Schweickart


The Internet of Things (IoT) can be thought of as the extension of the internet (and other networks) to devices. The eponymous “things” can be as diverse as smartwatches, refrigerators, light bulbs, and even complex systems of devices such as factories and airplanes. Businesses are utilizing IoT as a means of interacting with their customers, managing portfolios of devices, and identifying and understanding the most important trends within their industries.

McKinsey estimates that the number of businesses using IoT devices has doubled in the last five years, and expects the number of connected devices to triple to 43 billion by 2023. This growth is being driven by new use cases, including (but not limited to) smart cities, inventory management, patient monitoring, and remote field service. Some of the key technological trends enabling this growth include faster, cheaper cloud-based storage and low-latency, high-speed networks such as 5G. Furthermore, the explosion of artificial intelligence and machine learning (AI/ML) has created the need for huge amounts of data that can be used to train AI/ML algorithms — data the IoT is well-suited to generate.

While the term “IoT” was coined in 1999, the field remains in its infancy and continues to experience rapid innovation, which often makes it difficult to decide where to start when building an IoT solution. Despite the diversity of IoT devices and applications available, there are a number of common use cases and architectural patterns that many IoT solutions share. Below, I explore some of these commonalities and touch on some of the key decisions that need to be made when starting your IoT journey.

IoT Architectural Components

There are typically three categories of IoT components: device-related components, cloud platforms, and applications. Figure 1 shows a high-level view of these components:

Figure 1: Typical IoT Architectural Components

1. Device-Related Components

Device-related components include devices themselves as well as other near-location components like gateways. For instance, devices might have sensors that can report status data like pressure and temperature, and these telemetric readings can be sent as streaming messages or packaged into files for uploading. Video and audio feeds might also be uploaded from a device to the cloud. A device may also have controls or actuators that can be manipulated to perform various functions, such as closing a valve or unlocking a car. Depending on the communications and processing capabilities of the devices, they may be able to talk directly to a cloud platform or they may rely on local gateways to communicate with the cloud. Gateways can receive short-haul communications from many devices, aggregate and filter the data received, and act as a bridge between the devices they manage and the cloud platform.

2. Cloud Platforms

Cloud platforms offer several advantages to IoT applications, including the simple scaling facilitated by components like virtual machines, Docker containers, Kubernetes, and serverless functions. Additionally, cloud providers offer many “snap-together” components that can be configured into pipelines like Tinker-Toys. IoT Software-as-a-Service (SaaS) offers many out-of-the-box IoT solutions and is available both from all major cloud providers and cloud-independent providers such as PTC/ThingWorx. Typical IoT cloud components include the following:

  • Device Management: All processes related to managing devices. This often involves a device twin in the cloud, which is a digital model of a device (or system of devices) that can include desired (cloud-to-device) and reported (device-to-cloud) properties. Functions can include initial provisioning, monitoring, controlling, upgrading software, etc.
  • Data Management and Routing: This might include a Blob storage where file uploads would be received and a pipeline to move received data from the Blob storage to various data stores, data lakes, etc. These movements may include transformations, aggregations, filtering, and/or a number of other data processes.
  • Cloud Services: Cloud providers offer many services that are useful for IoT applications. The cloud makes it easy to configure pipelines of these services, such as machine learning, analytics, event stream processing, and many others. The configuration of these pipelines and services is often referred to as “orchestration.”
  • Integration: It’s often useful to combine device-related data with non-IoT data from, for instance, a CRM or ERP system as well as with data from external applications such as Google Maps, Twitter, weather apps, etc.
  • Application APIs: APIs enable IoT cloud applications to access functionality to support all user personas. These typically include customers, service and repair technicians, analysts, and management.

3. Applications

These can be either web or mobile apps that use a cloud platform’s APIs to manage and glean insights from a device portfolio. The applications can be built to support various customer and provider roles. Common examples include device status monitoring, telemetry trending and alerting, analytics, pushing firmware/software updates, etc.

A smartwatch step tracker phone app is an example of a customer-facing IoT application. Your step count and heart rate information are sent to your phone via Bluetooth, and your phone acts as a gateway and uploads your data to the cloud via your cell network or Wi-Fi. An application — which may run on the phone that is acting as the gateway or on another phone or webpage — shows the analysis, comparison with selected friends, alerts you when you hit 10,000 steps for the day, and so forth.


IoT applications provide bad actors with many new attack vectors, and as such, any comprehensive security solution must include these vectors. Data must be protected both in motion and at rest across all platforms, especially if it is governed by regulations such as HIPAA or SOX. Access to IoT data must include strong tenant-based and role-based authentication and authorization. For example, a service and repair technician from your company may have the ability to remotely log in to devices or schedule software upgrades for all customers that they support without seeing any Protected Health Information (PHI). Conversely, a physician would be limited to seeing only the data that is pertinent to their patients, but they would have access to PHI provided proper consent is in place.


A strong end-to-end DevOps plan will ensure changes can be made quickly and effectively, test environments are available and adequately represent production, and all necessary regulatory requirements are satisfied — including auditing and traceability.

Getting Started with the IoT

Like traditional IT projects, it’s best to start an IoT project with a solid understanding of the problem you are trying to solve. If a connected product could help solve that problem, your project may be a good candidate for an IoT solution.

When starting out with your first IoT project, it is usually best to start with a small, dedicated, cross-functional team. The following is a list of some of the key early decisions you will need to make:

  • Off-the-Shelf (OTS) IoT Solutions: OTS products can significantly accelerate the development of IoT solutions, and they generally rely more on configuration and less on coders. There are very few IoT applications that are so specialized they require fully customized, roll-your-own implementations. When choosing which OTS solutions to use, be aware of vendor lock-in trade-offs.
  • Roles and Team Structure: As is illustrated in Figure 1, IoT solutions can leverage a lot of existing talent with experience building cloud applications. The device, gateway, and IoT-specific SDKs require specific skills that a typical IT shop may not have in-house. IoT devices tend to run on very specific hardware and operating systems, and code is often in low-level languages such as C or Assembler. Communications protocols and networking configurations may also require unique skills that are not typically found in IT shops. For instance, identifying and securing new vectors of attack on the device side will likely require some new security skills. DevOps will also require many new skills, especially on the device end of Figure 1.
  • Edge Computing: Many IoT functions can be executed either on the cloud or on location in the devices or gateways, which is often referred to as “fog computing.” Designing your solution to be able to move functionality to various sub-components will help keep your solution flexible.

These are just a few of the considerations when starting your first IoT project. If you would like to discuss your IoT project with an experienced partner, contact SEI and let’s talk.

Joe Schweickart


More posts from this author