Manufacturers in a wide range of product sectors are exploring and exploiting the opportunities of the Internet of Things (IoT). The software for IoT comes in two distinct flavors, each created and maintained by its own tribe of software engineers.

First, the engineering tribe looks after the software embedded inside the product. This controls the product by checking sensor readings and operating actuators. It reports status via the network connection and handles whatever arrives via the network.

Second, the IT tribe handles the world of the cloud and the data center. This is where you find the software that handles messages to and from the product.

IoT software impacts everyone
Every department wants to play. Service wants to up its game with predictive maintenance. Designers want to see every sensor reading to guide their plans for the next version. Warranty processing wants legally defensible records of out-of-specification use. Sales want to offer new features via over-the-air upgrades. Legal want the startup sequence to be controlled by the sales contract, so that the configuration is exactly what its buyer paid for. Distribution want to control product demonstration and activation by resellers.

(Related: IoT provides so many opportunities for developers)

The point is that connecting the product is only part of the story for a successful IoT initiative. It’s also vital to create effective, efficient integration with both the new IT services the product needs and uses, as well as the necessary integrations with existing enterprise systems. This is where the two software tribes meet. The leader of a product manufacturer’s IoT business initiative needs the engineering tribe and the IT tribe to work together.

Good fences make good neighbors. The specification for the messaging interface is a good start. But the tribes still need to work together. The builders of the back-end software have questions like how many messages to expect from each device, or how many active devices will there be next year. The engineers will have questions like how many retries there should be during a product’s first startup sequence before it should abandon configure-to-contract and load default settings.

One big project? No thanks!
So the tribes need to cooperate. But just how much integration is right? Does it feed through all the way to the choice of development tools? Surely a one-project approach risks a monolithic result, with unexpected interdependencies?

In a recent Cambashi research interview, a head of embedded software development responsible for several hundred developers said, “I do not tell the engineer which pencil to use, but I need to know the result fits.” The message was one-size-does-not-fit-all, and the closer you get to code creation, the more likely there will be technical and other reasons for different tools. So, for example, to handle productivity, abstraction and reuse objectives the embedded tribe may use Simulink and MATLAB, whereas, with similar objectives, the IT tribe may choose low-code tools such as OutSystems and Mendix for mobile, Web and cloud development.

Layers of integration
There’s a layering effect here. For tools used to manipulate the software itself, just as for the pencil mentioned earlier, there are strong reasons to allow local choice. But away from the nitty-gritty of the sources from which the software is built, there is a stronger case for consistency.

Tools that are partly technical and partly management are in a middle layer (for example, requirements, test management and source management). The justification for sharing these tools is stronger than for source authoring and editing because both tribes will be involved in the processes these tools support. But outside the smallest projects, the key to success or failure is in the next layer.

When moving to mainly management tools (for example, issue tracking, project status reporting, technical review and release authorization) there is a strong case for tool level integration, or, failing this, shared processes. Any confusion and uncertainty about versions, status, who is handling what and so on causes delay and extra cost.

So give the mainly management tools priority. Convert them into the no-surprises backbone you need for unruffled confluence (and not catastrophe) as you guide the tribes to cooperation.

Peter Thorne is a director at Cambashi.