Architecture of an IoT Platform - Operational Scalability

Brandon Cannaday
Brandon Cannaday 6 minute read

When you hear the term “scalability” in the context of an IoT Platform, most people immediately think about technical scalability, or how well the platform’s software and infrastructure scale as the volume of devices and data grows. An equally important aspect of scalability, and one that’s often overlooked, is operational scalability. Operational scalability is how well the IoT platform helps scale your business processes (e.g., customer onboarding and device provisioning) as the volume of customers grows.

IoT Platform - Operational vs. Technical Scalability

  • Technical Scalability: how well the IoT platform scales as the volume of devices and data grows.
  • Operational Scalability: how well the IoT platform helps scale your business processes as the volume of customers grow.

In this article, I’m going to cover some architectural choices we’ve made at Losant when it comes to ensuring our IoT platform is optimized for operational scalability. If you want to learn more about technical scalability, specifically data storage, please check out my previous IoT platform architecture article.

IoT Platform Automation is Key to Operational Scalability

Efficient business processes usually involve some level of abstraction or automation over the underlying IoT platform. Onboarding a handful of customers and devices manually through the platform’s UI may work fine, but when an application scales to millions of devices across thousands of customers, manual processes are no longer viable.

The actual business processes involved as part of operationalizing an IoT product or service differ from company to company, but we find the following items to be nearly universal:

  1. Multitenancy: provision a tenant to represent each customer.
  2. User Management: configure SSO or add users to your customer’s tenant.
  3. Device Management: provision and onboard customer devices.
  4. Procurement: order parts, devices, or hardware via SAP or similar ERP.
  5. Notifications: alerts to internal and external users like field service professionals.
  6. Billing: reporting and payment processing.

How an IoT platform approaches automation to deliver the above items can vary greatly, but it’s important to think about your company’s requirements when evaluating platform choices. Platforms without operational scalability features may work well for small projects, but will become difficult to maintain as your solution grows.

IoT Platform Automation via REST API

The most fundamental automation feature is a REST API. At Losant, we’ve adopted an API-First approach to our architecture and implementation. This means nothing can be done in Losant’s user interface that cannot also be done using Losant’s API. Losant’s user interface, under the hood, uses the same JavaScript API Client that many of our customers use for service-to-service integrations.

IoT Platform API-First Design

IoT Platform Automation via Built-in Business Rules Engine

Exposing an API is an excellent step towards automating and operationalizing an IoT platform. The downside to an API, however, is that there must exist another service, running somewhere, that’s making the decisions and invoking those API endpoints.

Beyond an API, one of the most impactful features an IoT platform can provide is a rules engine. Many platforms do offer some kind of rules engine, however most are designed to operate on incoming device data, not for making business decisions. The most important aspect for operational scalability is that the rules engine can be used to orchestrate the platform itself.

At Losant, we supercharged the concept of a rules engine with our Visual Workflow Engine. Our workflow engine is a drag-and-drop interface that makes it easy to build the logic behind all aspects of an IoT application.

Losant Workflow Drag and Drop

No two companies have identical business processes when it comes to things like registering a device.

  • Are technicians installing devices on behalf of customers?
  • Do the devices register themselves when they first power on?
  • When a device attempts registration, what’s the source of truth for that device’s authenticity?

A platform’s rules engine must be flexible enough to implement arbitrary business logic to meet the unique needs of each company.

For a platform to automate itself using its own rules engine, the rules engine must have the ability to programmability operate on the platform’s resources. At Losant, we added several workflows nodes with this concept in mind:

To fully implement custom business logic, it’s not enough for the rules engine to interact with only platform resources. Businesses often have existing sources of data that must be integrated into the IoT solution. For example, when a device attempts to register itself, it could present a manufacturer ID as part of the registration process. The details about which manufacturer IDs are valid could be stored in a SQL database managed externally to the IoT platform. This means the platform’s rules engine must query an external database as part of the device registration process.

At Losant, we provide several workflow nodes specifically designed to integrate with external sources of data:

IoT Platform Features for Operational Scalability

The most critical component for operational scalability is automation, however there are several features that IoT platforms can provide, that when combined with automation, will get your solution into market faster with less complexity.

Device Recipes

A device recipe contains predefined properties for devices. Platforms will name these properties differently, but at Losant, we call them Tags and Attributes. A recipe allows you to quickly create devices that already have these properties defined. This is helpful if your IoT product or service has a large number of similar or identical devices.

Bulk Device Creation

There are two primary ways to register devices: pre-registered or on-demand. When pre-registering devices, a bulk device creation tool can make this process much easier. At Losant, we’ve paired bulk device creation with device recipes, which makes it easy to quickly create thousands of devices from a device recipe.

Device Grouping

Organizing devices is critical when it comes to operational scalability. Technical grouping concepts, like Digital Twins, is an important aspect of your solution’s architecture. When operationalizing a platform, you must also consider grouping devices by customer or tenant. This form of grouping handles the association of devices to users and is how device provisioning is implemented. At Losant, we call these Experience Groups.

Usage Reporting

Very few IoT platforms contain payment processing, however an important feature is the ability to extract usage details so that bills can be calculated. Losant offers this in two ways. The first is through Instances, which are for large enterprises or resellers that are managing several Losant Organizations. The second is through per-device payload tracking, which provides a way to request granular usage information about individual devices in a multi-tenant application.

Templates for Out-of-the-Box Business Process Implementations

I’m aware that earlier in this article I said that out-of-the-box implementations don’t work in practice, however templates provide a unique solution to this problem. Even though every business has unique nuances that prevent most turn-key solutions from being viable, the implementations, from a high level, are usually similar.

Templates deliver the high-level similarities while allowing the implementation to be modified to meet a company’s unique needs.

Losant Template Library

Templates solve many problems across all aspects of an IoT implementation, but for operational scalability, Losant has several specific options. You’ll find these, and many more, in Losant’s Template Library:

Dynamic Registration: allows devices to register themselves by sending a digitally-signed JWT token to a registration API endpoint.

Dynamic Provisioning: provides a base implementation that allows your Experience Users to dynamically provision devices to their own account or the Experience Group in which they belong.

QR Code Reader: tap into a device's camera to scan a QR code. This component is commonly used in device provisioning flows (i.e. tying new hardware to user accounts).

Azure Active Directory SSO: demonstrates how to authenticate to an Experience using service provider initiated Single Sign-On (SSO) with Azure Active Directory.

Evaluate Your IoT Platform for Operational Scalability

The goal of this article is to help guide your choices when it comes to evaluating IoT platforms. Operational scalability is often an overlooked evaluation criterion that can cause headaches as your IoT product or service gains traction.

If you’d like a demo of Losant to see how we tackle operational scalability from a platform and architecture perspective, please contact us and someone from our team will be in touch shortly.

Tagged

Brandon Cannaday

Brandon is passionate about developer tools and user experience. He has over 15 years of enterprise software experience in chemical detection, telecommunications, cloud services, and The Internet of Things.