While the IoT is arguably one of the most exciting evolutions in recent technology history, it certainly brings multiple challenges. Many of these have already been well publicised, particularly what can go wrong once an IoT project is in commercial production and deployment, including security and responsibility for malfunctions.
However, just as important is looking at the very starting point: namely, the software development processes that drive any IoT project from inception to completion. As well as making crucial differences in time to market, the software development is often where the seeds of future problems may inadvertently be sown, potentially leading to product problems or security issues down the line.
Conversely, create a solid development foundation for an IoT product or service and you could make all the difference to its long-term evolution, including scalability, adaptability and robustness.
Many organisations have already realised the importance of software development as a contributor to IoT commercial success. They are not only accepting, but are actively embracing the fact that IoT requires re-thinking - and in some cases, completely transforming - traditional development approaches.
Processes and tools that might have been absolutely fine in the past may not cut it in an IoT-centric world, where the sheer volume of data generated, components involved (such as sensors), diversity of contributors internally and externally, and also very likely cloud delivery along the way... all these factors have taken the need for collaborative product development to a whole new level.
Approaches that are being adopted by IoT pioneers include some that are already familiar in ‘mainstream’ software development, such as component based development (CBD), DevOps, infrastructure-as-code and using version management as the ‘hub’ to control all assets, not just code. This means that there is already a good bedrock of knowledge and experience on which the IoT community can draw. Let’s look at each of these ‘trends’ (for want of a better phrase) in turn and how they play in an IoT environment.
CBD, DevOps, agile and CD - benefits also bring challenges
CBD is not a new technology. It originated from manufacturing when makers realised that using prefabricated parts could speed up construction and improve quality. The same idea has been applied to software since the 1960s. In the IoT world CBD is a natural choice: IoT combines different stacks of hardware and software together, from chipsets and sensors to firmware, drivers, network stacks and graphics.
CBD certainly brings its own challenges, from keeping track of all the files and documents that go into a product to assembling and configuring all the different parts in a way that can be reproduced at any point in time for investigations of problems and bug fixes.
DevOps hardly needs any introduction, but as a brief reminder, it is all about bridging the traditional gap between development and operations teams, to help them work in a more transparent and collaborative way (rather than the old school ‘them and us’ mentality), all with the aim of bringing projects and products to fruition more quickly. It’s also a perfect complement to other approaches, notably agile and continuous development (CD). At the core of all of these is the shared goal of getting products or services ‘out there’ as fast and efficiently as possible.
However, in the IoT environment, DevOps - whether in combination with agile and CD or not - means having to be able to spin up servers to host applications quickly, which means a lot of automation is required. However skilled the teams involved, manual processing is just not going to cut it in the high-volume, fast-moving IoT world, particularly when both software and hardware elements are involved.
So, hand-in-hand with DevOps we are seeing adoption of infrastructure-as-code (IaC). This virtualised approach is based on the concept that the way software applications are executed - all those communications services, memory, network interfaces and processors - are governed by software-defined configurations, usually as structured XML or plain text files.
The net benefit is that automation is achieved, plus because these formats are easy for us humans - not just the machines - to understand. It’s also known territory to both development and operations professionals, who have been using these file formats for years, so there is a degree of ‘comfort zone’ here.
But this leads us to the next challenge: DevOps and IaC may be a great idea, but they still need to be managed, in terms of visibility of changes being made, particularly with IoT, where multiple contributors and teams, often spread across the world across different organisations, are often involved.
Version control as the hub
Enter another familiar tool: version management or version control, which can be used to track people and actions, giving everyone who requires it a clear view into who has done what, where, when and how, without compromising anyone’s work. For instance, the security guys control encryption and port access, while software developers check in code, while design engineers upload CAD drawings and so on.
There are a few ‘buyer beware’ aspects’ of which to be aware: the version control system must be able to recognise and handle non-binary assets, from multiple sources and in a variety of formats. The version control system must also enable engineers to store components and create and retrieve different configurations.
If IaC is involved, then assets will also include files that define different aspects of the system too. Given that many IoT projects are in highly monitored or regulated industries (such as medical devices and automobiles), then the version control system must be able to provide an immutable audit trail of all changes and activities to a design project, right from the very beginning.
Something else that’s potentially very useful in the IoT environment is the adoption of hybrid version control systems, which overcome some of the issues that organisations may have experienced with centralised systems or distributed systems (the former not popular with developers who like to work in isolation, the latter not popular with organisations who are frustrated by the lack of visibility and control that approach can entail).
