Treating IoT software architecture as component selection and evaluation ranks among the costliest engineering errors that afflict IoT product providers. With systems this complex, architects need to consider relationships first.

Component-focused IoT software architectures presume a static context, existing in isolation from time, change, and the external dependencies connected to them via the internet. Interface-focused architectures place the relationships between components at their core, protect against time and uncontrolled change using one of the internet’s key mechanisms: the defined interface.

IoT software architects, it’s your job to control the relationship between components, not just the components themselves.

When amateurs discuss IoT and other software system architecture, they speak in stark, definite terms, as though every decision is permanent and irreversible:

• “Place our bets”
• “Pick our horses”
• “Choose correctly”

Worse, when experts discuss IoT architecture, they hide behind ephemeral, non-committal jargon that references yet obfuscates the specific things they build:

• “Add it to the backlog”
• “Just spin up X service”
• “That’ll fit into the Y framework”

Thinking about IoT either way makes system architecture more challenging and invites long-term difficulty because both mentalities overfocus on the part that will change, the system component, at the expense of the relationship between components or the whole over time, which of course is someone else’s problem!

Let’s say you’re building a connected mobile sauna):

And you’re going to apply a fundamental IoT architecture like this one depicted by IoTDunia:

This architecture applies to almost all IoT devices. However, it’s perilously easy to fall into the component-focus trap and say, “OK, I just need to pick the following”, and assemble the pieces you like:

1. Sensors: TI humidity sensor and temperature sensor HDC3020) connected to your proprietary hardware
2. Gateway: Teltonika TRB255
3. Wireless communication: Verizon Cat-M1
4. IoT cloud: Azure IoT
5. Interface applications: Custom built by that webshop you like using React Native

Done! You’re an architect now, right? Well, based on the mid-tier work we’ve seen, you’re not not an architect!

Component-focused thinking applies just as frequently in deeper architecture—here’s an example of an event-based IoT architecture from Amazon:

Obviously AWS sells services components a go-go, so this may seem self-serving for Amazon, as even the components here have purchaseable subcomponents! We’ll use component-focused architecture as a backdrop for interface-focused architecture in the example below.

Everybody wants to buy once, build once, and be done forever. However, like most machines, an IoT system requires considerable care and feeding just by existing. Here’s what’ll really happen with your IoT system over a 5–10 year period:

• It’ll start strong, and you’ll deliver new features for a time
• Key players will come and go
• You’ll want to switch something due to a cost, performance, scaling, or business continuity limitation
• You’ll be forced to change something you relied on due to an uncontrolled externality
• You’ll design devices 2–n expecting to gain efficiency from your previous implementation, but the customization required to support each multiplies complexity
• Your IoT system functionality and uptime will have a direct and outsized impact on your brand and your ratings and you’ll feel trapped by your success
• This’ll cost more than you expected it to

Legends and folklore portray mythical fae (fairies) as human-like tricksters with magic powers. From a literary perspective, it’s thought that fae exist to remind humans that nature’s in charge, that we don’t know everything, and that certainty’s a deeply tenuous thing. Based on our experience with complex software, we’re pretty sure a fae runs worldwide software engineering.

The harder you try to make your architecture permanent, the likelier it is to be reversed. The more you wish it were temporary, the longer it’ll endure. Finally, for maximum irony, the one thing that won’t change much is the technology itself.

Given the shifting reality of complex hardware and software systems architecture, interface-focused architecture begins by asking a future-oriented question:

“If I had to swap out this component later, what would make that easiest?”

Why, clearly-defined interfaces, of course!

Interface vs. component architecture

Whereas your basic IoT component architecture inserts component choices atop the classical IoT utility model:

Device PLC: thing X
Device modem: thing Y
Connectivity: service A
Cloud platform: service B
Data lake: thing Z
Webservices: service C
User interface: things D–F

An interface architecture defines the spaces and relationships between components. The simplest way to define your interface architecture is to answer this question:

“What should each pair of components speak to each other?”

Right away, you’ll find you have more to think about than expected, even without getting context-specific:

• PLC↔modem
• Modem↔gateway
• Cellular/wired/wireless type
• Device↔cloud protocol
• Device↔cloud data type
• Web/mobile interface ↔ cloud API
• Web/mobile interface ↔ data (type, storage, retention, etc.)
• Analytics for device, web/mobile, data analysis
• User authentication and authorization
• Device management method

Although you have more complexity to consider, the good news is that each potential interface tends to have fewer available options versus the paralyzing infinitude of component choices.

Interfaces for our mobile sauna example

Let’s apply interface thinking to our hypothetical mobile sauna using the AWS example above, reposted here:

Note: This is not an all-encompassing architecture for the mobile sauna, just the bits illustrated by AWS applied through our example.

1. Where do you compute what?

The example architecture shows sensor data being fed to unmentioned edge software managed by IoT Greengrass. What it’s really implying is that your device itself will do work beyond merely being a conduit—you’re not picking a tool, you must decide architecturally:

• What gets passed through?
• What gets ignored?
• What gets transformed by what software?

The compute interface is where you draw those lines. If you can declare something like “We do X work at the edge, Y work in the cloud, and Z work on the user’s mobile app. We avoid Z work altogether.”, you demarcate boundaries that simplify future alteration and product development. For our connected mobile sauna, we’ll choose to normalize and batch data with device software to keep bandwidth and platform costs down.

2. What are your protocols?

In the example, AWS IoT Core and AWS IoT SiteWise both collect IoT data from devices, each employing a different class of protocols. You’d only use both of these if your incoming data arrives via some mixture, like Modbus, MQTT, HTTPS, OPC-UA, etc.

When you can centralize around a protocol standard (and then follow it), the criticality of your component choice decreases significantly. Our mobile sauna already uses Modbus, which it’ll speak to our gateway, so we’ll need to convert that to something more internet-friendly. For that, we’ll select MQTT. We manage a few risks this way:

• If our gateway sucks, there’s nothing special about what its replacement must do
• If production limits force us to make multiple SKUs and use multiple components, we can isolate the impact of that variance behind the relevant protocol
• If our engineer leaves, a replacement individual (or firm) can work with known standards
• If our cloud provider becomes too expensive, can’t scale, or degrades over time, we’ll easily find another that speaks MQTT

It’s not always necessary or desirable to select just one protocol. Don’t forget your device’s specific context.

3., 4., and 5. What are your data standards?

Define standards for data types, formatting, routing, retrieval, processing, reporting/analysis, search, and short- and long-term storage? The Amazon example shows the myriad things that happen to device data once collected:

• Kinesis streams route data
• Kinesis is also filtering data for the “event” part of this architecture
• S3, DynamoDB, and Redshift store it for analysis
• OpenSearch indexes and makes it searchable
• App Sync synchronizes with other systems

Our mobile sauna produces simple time series data that won’t be complex to handle, process, or store, but could get expensive if we decide to keep too much too hot for too long. Our users need ready access for 30 days max, so we’ll keep that and throw the rest in cold storage. It’ll take years to determine our true analytics needs, anyway.

---

Don’t get held hostage by expensive IoT change costs. Contact Next Mile for a resilient, change-friendly IoT architecture. It’s the only way to guarantee you’ll never have to alter it!