In my previous post I discussed the challenges of IoT software delivery as they relate to managing the complexities of integrating three distinct development pipelines comprising the different components of the IoT software. These are:

1. The embedded software in the device itself - for example, software embedded in a car.

2. The big-data backend application used to store and analyze the real-time data accumulated from the different devices.

3. The mobile app - used by end users to control the device.

Each one of these software components is being developed and delivered by a separate team (or in many cases, several teams). In this article, I'd like to take a closer look at some of the distinct characteristics of each team involved in the production of IoT products, and the strains they put on the IoT delivery chain.

"There's no I inTeam" . Sure, we're all in this together: working hard to get the next big thing in the IoT space to market. And we know we depend on each other for our stuff to work.. But -- streamlining your IoT development processes across different teams is no easy task.
We need to be aware of the fact that each of the development team (Embedded, Backend, Mobile) uses different technologies, tools, stacks, deployment patterns and delivery practices in their work. Theirday-to-day tasks and workflows are different .
Let's take a closer look at what it means to be an engineer in each one of those teams:

The embedded software must take inputs from sensors to understand the conditions of the physical world environment. Based on the computations of this input, the program then performs certain tasks - for example, activating or modulating a set of actuators to produce the desired behavior.
Consider the simple scenario of pressing the gas pedal on a hybrid car. What seems like a very simple operation, in fact involves thousands of decisions made in less than a second. The engine's Electronic Control Unit (ECU) receives the request to accelerate. It then collects various data, such as how hard the accelerator is pressed, the ambient temperature, the current speed, the current gear that the car is in, whether the car is on an incline or decline, whether the car is in Eco mode or Sport mode, whether the battery level is high or low, whether there is any slippage in any wheels, and many, many more. After collecting the data, the program performs calculations to send signals to the transmission ECU to adjust the gear if necessary, to the gasoline engine ECU to start the engine if needed, to the hybrid engine ECU to coordinate the power delivery from the electric motor and the gasoline engine efficiently, and so on. After all of this - the car speeds up, but the computation continues. The engine's ECU measures any change in the pressure applied on the gas pedal. If the driver eases on the accelerator, the whole process of collecting data, making decisions, and sending signals to different ECUs and actuators will happen again, to adjust speed, energy use and performance.

This team works predominantly with Real Time Operation System (RTOS) and works collaboratively with the Mechatronics (mechanical and electronics) team. The most common programming language for this team is C/C++.
Given the nature of what the program must do, the software team uses model-based system development. These are specialized tools (provided by companies such as MathWorks, Vector, D-Space) that are often used to facilitate this kind of programming. Meanwhile, on the Mechatronics side, the hardware team must work on the mechanical and electrical design, using specialized tools from Siemens, PTC, Dasault, IBM, and the like. In the model-based system development, the software team can initially work independently of the hardware by using emulation and simulation. This kind of test is called Simulation in the Loop (SIL). Once the hardware module is ready the software is injected to it and real integration test is performed - called Hardware in the Loop (HIL).
The Mechatronics team uses a Product Lifecycle Management (PLM) tool to manage the mechatronics development, test, and verification. The Embedded Software team uses its own Application Lifecycle Management (ALM) andContinuous Delivery (CD) tools to manage the software development, test, and release.
Keep in mind, the different processes must interact with each other at certain points, and both teams must do their best to reduce the friction between the two completely different processes for the hardware and software development lifecycles.

This team is tasked with processing the massive amounts of real-time data, and is also mostly concerned with horizontal scalability – to be able to support data throughput as more devices are sold. The software produced by this team is typically deployed in data center and it is often replicated in several locations for redundancy and low-latency. As the variety of the IoT devices being sold increases, the backend software must handle all of the variations in the flavors of the product/services offered to customers, and their corresponding SLAs.

This team often uses Agile development methodologies to support the need for frequent feature enhancements and software updates. Instead of batching all changes into one 'mega' release, the development work is divided between small teams who work in short Sprints, and incremental changes to the code and new features are being deployed fairly frequently. This team, too, often uses ALM or Agile tools to support development.
To enable the cadence of deployments and streamline their delivery process, this team uses a Software Delivery Pipeline solution that coversaccelerated builds , preflight , continuous integration, continuous test, and smart deploy . This tools also manages the provisioning, configuration and management of the IT infrastructure across the different development, QA, staging and production environments.
The backend software is the 'brain' of the IoT service - and IoT devices are always connected. This mandates that the deployments to Production are done in an extremely reliable manner, to ensure there's no service interruption. To ensure smooth operations, this team often uses DevOps Automation and Continuous Delivery solutions to facilitate the critical deployment process.

The culture of Mobile App development started out with startups and individual developers, who often perfected their code in the 'hip' coffee shops in San Francisco, Palo Alto, San Diego, Austin, and Manhattan. These programmers often do not require office space, and seldom do they have an IT team to support them. Instead, they are more inclined to use modern SaaS solutions designed to facilitate the development, continuous integration, testing and release of their app. These days, due to the strong trend in IoT, many large enterprises (such as Automotive companies) hire these “coffee shop” programmers. Still, despite the fact they now work in the more formal environment, their work habits and their preferences regarding tool chains have not changed.

The most popular programing languages among mobile app programmers are Java and Swift. Mobile developers are comfortable integrating several SaaS-based mobile app development tools to realize their development environment and processes. They can store their source code in GitHub , use SauceLab for mobile app testing andAppDynamics for mobile app performance test and monitoring. They use Ship.io for continuous integration, continuous test, and continuous release to AppStore.
The frequency of updates for mobile apps is also extremely high, driven by the competitive nature of the app landscape and the ability to optimize the application based on the available real-time feedback on the app’s usage.

As we've seen, each team required to deliver on an IoT product is inherently different from the others. Because of this, friction naturally occurs when the three teams must coordinate their integration and system test. If this friction - and possible failure points between the separate processes - is not minimized, releases would inevitably get delayed, and the product’s quality will suffer.
In addition to the common Agile development practices, and a Continuous Delivery and DevOps platform requirements, there are unique requirements from a tooling perspective to enable efficient and streamlined IoT app delivery. What is needed is a single platform that can address the three different domains: a Multi-Domain Continuous Delivery (MDCD) platform capable of eliminating the friction and streamline the end-to-end process.
This solution must be able to integrate and orchestrate the work transitions or handoffs between teams throughout the product’s lifecycle. In addition, it must have the ability to track the artifacts as it moves from one domain to the other, and keep track of the artifact as it moves in and out of the different domains, the outcome of each processing, and who performs the work at different stages.
Do you know of anything like that? :)

The first article in this series is also featured on DZone's Internet of Things Research Guide.
Download the complete guide here.