IoT Services & Solutions for Building Smarter, Connected Systems

Our IoT development services cover three groups of work, set out in the tabs above: IoT advisory, IoT development and IoT solutions, fifteen services in all. The sections below define an IoT system in the terms used by NIST, the US National Institute of Standards and Technology, place each service on it, explain where edge computing fits, set out the security capabilities NIST names for a device, and cover how an engagement runs, what moves the cost, what you receive and what to ask.

On this page

• What an IoT system is made of, in NIST's words
• IoT consulting services, development and solutions
• Edge computing in IoT: where the processing happens
• IoT connectivity: the network interface and the protocol
• Security from day one: the device capabilities NIST names
• How an IoT engagement runs
• What moves the cost of an IoT project
• What you receive
• What to ask any IoT development company
• Questions buyers ask about IoT development
• More about IoT work at Sthenos

What an IoT system is made of, in NIST's words

NIST IR 8259 describes the IoT devices it covers as having at least one transducer, a sensor or an actuator, for interacting directly with the physical world, and at least one network interface for interfacing with the digital world. NIST SP 800-183 names five building blocks for a network of such things: a sensor, a communication channel, an aggregator, a decision trigger, and an external utility, or eUtility. Figure 1 draws them in the order data moves through them, with the service on this page that builds each one.

IoT consulting services, development and solutions: the fifteen services

The three tabs above, on one map. IoT Advisory is the consulting group: strategy, use cases, architecture, security planning and the business case. IoT Development builds the system, from IoT app development services to firmware, integration, APIs and testing. IoT Solution names the five kinds of system the work produces, including industrial IoT solutions for manufacturing and industrial operations.

Edge computing in IoT: where the processing happens

IoT Integration Services, above, connect devices, gateways, cloud platforms and enterprise systems. NIST SP 500-325 describes that path in three layers: the edge, where the end devices sit; fog nodes, such as gateways, between the devices and the cloud; and centralized cloud services. Which layer does the processing is a design decision, and NIST's own model makes neither the fog layer nor the cloud mandatory. Platform and vendor agnostic, above, means that decision is fitted to your ecosystem.

Edge, fog and cloud, side by side

IoT connectivity: the network interface and the protocol

IoT connectivity starts at the device. NIST IR 8259 describes the IoT devices it covers as having at least one network interface, such as Ethernet, Wi-Fi, Bluetooth, LTE, Zigbee or Ultra-Wideband. Above the network sits the messaging protocol. Our manufacturing IT page cites MQTT, which OASIS describes as a client server publish/subscribe messaging transport protocol that is light weight, open, simple and designed to be easy to implement, and ideal for constrained environments such as machine to machine and IoT communication.

Security from day one: the device capabilities NIST names

Security and Compliance Planning, above, embeds security, privacy and regulatory considerations from day one, and Device and Firmware Engineering builds the firmware a device runs. NIST IR 8259A defines a core baseline of six cybersecurity capabilities for an IoT device, as a default for minimally securable devices; it does not specify how each capability is achieved. For industrial IoT security on a plant network, our manufacturing IT page also covers ISA/IEC 62443, the series ISA writes for industrial automation and control systems.

• Device identification. The device can be uniquely identified, logically and physically.
• Device configuration. Its software configuration can be changed, by authorized entities only.
• Data protection. It can protect the data it stores and transmits from unauthorized access and modification.
• Logical access to interfaces. It can restrict logical access to its local and network interfaces, and their protocols and services, to authorized entities only.
• Software update. Its software can be updated by authorized entities only, using a secure and configurable mechanism.
• Cybersecurity state awareness. It can report on its cybersecurity state, to authorized entities only.

How an IoT engagement runs

Five stages, the same five published on our custom software development page, with the IoT services from this page placed where they act. Sthenos works in two week sprints, so working software arrives every two weeks.

• DiscoveryUse-case identification and strategy and roadmapping: high-impact IoT opportunities across operations, products and customer experience, in a short, bounded discovery scoped per engagement.Written scope and costed roadmap
• DesignArchitecture and platform advisory, and security and compliance planning: devices, connectivity, cloud platforms and data layers, with security, privacy and regulatory considerations in from day one.Architecture decisions in writing
• BuildDevice and firmware engineering, IoT application development, integration and secure APIs, shipped in short, reviewable increments.Working software every two weeks
• LaunchTesting for device, platform and application reliability, then hardening and a controlled release.A controlled release
• SupportUpdates and ongoing support through testing and lifecycle maintenance, with monitoring, maintenance and a roadmap tied to business outcomes.Monitoring, maintenance and a roadmap

What moves the cost of an IoT project

IoT work is billed at the published Sthenos rate band, and where the scope is clear we quote a fixed price for a defined outcome, with a costed roadmap before any build starts. Business Case and ROI Modeling, above, builds the cost, benefit and value realization models that support the investment decision.

Within those bands, these are the questions that change an estimate. Each is already published on our custom software development or manufacturing IT pages, and none carries a number here.

• How settled the scope is. A written, agreed scope is a large variable in any estimate, and an unsettled one is the reason estimates move.
• What the equipment actually exposes. What the controllers on a floor expose is an equipment fact and not an architectural preference, so it is checked before the interface is designed.
• The messaging design. The topic hierarchy and quality of service level are extremely expensive to change once devices are in the field.
• The integration count, and whether the other side is documented. An integration into a modern documented API is routine; one into an undocumented system that somebody has to reverse engineer is a project of its own.
• The compliance evidence the contract requires. Producing the artifacts an auditor or a contracting officer will ask for is work, and it belongs in the estimate.
• What happens after launch. Deployment and maintenance are frequently excluded from cheap quotes and sold back afterwards. Get them priced up front.

What you receive

A process description says what a vendor does. This says what you end up holding.

• A clear IoT vision and a phased execution roadmap, aligned with business goals, use cases and ROI expectations.
• A measurable IoT business case with cost, benefit and value realization models.
• An architecture covering devices, connectivity, cloud platforms and data layers.
• Firmware, applications and secure APIs, tested for device, platform and application reliability.
• A written scope and a costed roadmap before any build, then working software every two weeks.
• The repository and the cloud accounts in your name from the first commit, with updates and ongoing support after launch.

What to ask any IoT development company

These questions apply to all the IoT service providers on a shortlist, Sthenos included. Each comes from a NIST publication or from a question our own pages already publish.

1. Which of the six NIST device capabilities will the devices support, and how will software updates reach devices already in the field?
2. Where will the data be processed: on the device at the edge, on a fog node such as a gateway, or in the cloud, and why there?
3. How will the MQTT topic hierarchy and quality of service level be designed, versioned and documented?
4. Who reviews the code, and can that person veto a merge?
5. What is explicitly out of scope? The excluded half is the half that generates change requests.
6. Who owns the code, the repository and the cloud accounts when we are done?

Questions buyers ask about IoT development

What do IoT development services include?

On this page, five services: IoT application development for device monitoring, control, data visualization and workflow automation; device and firmware engineering; IoT integration services; API development and integration; and testing and lifecycle maintenance.

What is edge computing in IoT?

NIST SP 500-325 defines the edge as the network layer encompassing the end devices and their users, providing, for example, local computing capability on a sensor, meter or other network-accessible device. NIST notes this layer is often called the IoT network.

What counts as an IoT device?

NIST IR 8259 covers devices with at least one transducer, a sensor or an actuator, for interacting directly with the physical world, and at least one network interface, such as Ethernet, Wi-Fi or Bluetooth, for interfacing with the digital world.

Do you offer IoT consulting?

Yes. IoT Advisory is one of the three service groups on this page: strategy and roadmapping, use-case identification, architecture and platform advisory, security and compliance planning, and business case and ROI modeling.

How much does an IoT project cost?

Sthenos rates are $150 to $250 per hour, depending on the seniority and mix of the team, and a typical project runs $50,000 to $200,000. Where the scope is clear we quote a fixed price for a defined outcome, with a costed roadmap before any build starts.

Who owns the code you write?

You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no licence back to us and no dependency on us continuing to exist.

More about IoT work at Sthenos

Have devices that need connecting? Tell us what they measure, where the data has to go and who acts on it, and you will get a straight answer on where the processing should sit. Talk to our engineers.