Is it time to take a fresh look at the IoT?

By its very nature, the Internet of Things (IoT) introduces greater dependency on good software - more so than ever before. The IoT also brings increased software development challenges, thanks to the wide variety of different components (such as sensors), control systems and other digital sources to connect, and where these ‘assets’ comprise far more than just code. Perforce Software explain.

From consumer products through to server-side applications responsible for managing all the information involved in the IoT, software development is under a lot of pressure to deliver on IoT’s promise. On top of that are the usual market drivers - faster time-to-market, increasing competition, a need to drive down costs, plus compliance and regulation.

All this has led to the whole area of software development being subjected to renewed scrutiny to discover whether or not it is ‘fit for purpose’ in the IoT age. In many cases, organisations are re-evaluating, changing or updating the processes and tools used to support IoT related software development, including adoption of DevOps, establishing a ‘single source of truth’ and the need to build in an ability to scale.

DevOps and IoT
DevOps, a methodology that largely stems from enterprise software development, is increasingly impacting the electronics industry. It breaks down the traditional barriers between software development and operations, helping products to be developed and released quickly and efficiently. This typically requires being able to rapidly provision servers to host applications and in turn, this means a high degree of automation is a necessity - IoT systems change too fast and are too complex to risk dependency on manual processes.

In turn, this has led to increased implementation of ‘infrastructure as code’ (IaC) and virtualisation. In IaC, the environment within which software applications are executed – the operating system, installed packages and other server configuration aspects. Typically either plain text files or structured XML, these formats are familiar and relatively easy to read and to manage.

Agile has been talked about as a development methodology for over a decade, but it is now beginning to make serious inroads in all kinds of development including IoT, replacing traditional waterfall processes. Agile is about delivering a viable product, then incorporating feedback and improvements, rather than seeking perfection from the get-go, so it is ideal for markets where fast roll-out is an imperative. It is a relatively easy concept for non-technical people to understand and plays to commercial objectives, so Agile is appreciated by general management too.

Developers get the benefit of being allowed to experiment, and ‘fail early’ if necessary, while still working within the framework of a collaborative team with clear goals.

Both Agile and DevOps often sit alongside Continuous Delivery, with a focus on early feedback, automated build and test, so that what is deployed is what was originally and thoroughly tested, with as much automation as possible (does this set of components need compiling every time?)

Continuous Delivery is separate to the well established Continuous Integration approach, but is entirely complementary.

A single source of truth
While the theory behind all these methodologies and approaches is sound, real world implementation depends on addressing some fundamental factors, notably clear and easy collaboration between contributors; visibility across the entire software lifecycle process; full and immutable traceability across all actions – from changes to a piece of code to changes in binary assets or environments - in real time and historically.

Without this foundation, it is hard to have the confidence that software development projects are not only on track, but have the necessary levels of robustness and security. For instance, when re-using software IP, teams need the assurance that design data is staying in sync. With contributors all over the world, control over every version of every digital asset is needed not only at the file or data level, but also at the hierarchical IP design block level.

Consequently, we are seeing a growing number of IoT firms adopting the idea of a ‘single source of truth’, to establish better transparency and sharing of all the digital assets involved, thus enabling fast time to market and incorporation of rapid feedback, in a reliable and secure framework.

While there are different ways to achieve this, version control systems are typically at the heart of a ‘single source of truth’.

Version control systems have long been used in the electronics industry, particularly for embedded software, but their role has expanded and today they are used for far more than just checking code in and out. Instead, they are hosting a wide variety of digital assets and build artefacts, including prototypes, CAD drawings and the documentation supporting a project. Increasingly, version control systems include data relating to hardware assets, such as design specs and control files for manufacturing, which is another reason why they are a good fit for IoT.

Version control systems provide a detailed window into what is happening right now (such as the current working model), plus what happened in the past, with the ability to roll back to a previous version of the project if needed (for instance, to unearth a problem that only becomes apparent a couple of years later, or to satisfy industry regulators). Everyone can see the current versions of products in development, who is working on what and what has happened so far, preferably regardless of what operating system and other development tools they may be using.

Version control best practice
In IoT environments there are several valuable attributes to look for in a version control system: the ability to support all the assets required (some tools are not optimally designed for non-code assets); to accommodate remote team members and external third parties (such as regulators); plus the flexibility to scale to address growing file sizes. In even a relatively modest design project, the repository of digital assets can quickly expand and this is something that is hard to predict in the early stages of a project. The system should also be able to support disparate contributors using different systems or platforms, including remote workers and third parties, plus offer clear integrations with popular tools in the IoT space.

There are some other aspects to consider: on-premises versus cloud-based (and the ability to go from one to the other or vice versa in the future without having to change other tools too); or using a tool that can embrace the different version control tools that some individual developers may prefer (Git being a typical example) without IT management sacrificing control and visibility of the overall development environment. Pre-defined workflows help to regulate processes, but the version control system should be technology-agnostic and not enforce new ways of working.

Granular access
One issue that is often overlooked but is incredibly important is granular control to file access: giving people unnecessary access to parts of the version control repository that they do not need only increases the risk of vulnerabilities. Look for tools that give people the access to everything they need for their everyday jobs, but no more. The single source of truth should also be immutable: in other words, the facts cannot be changed retrospectively.

Also, consider the entire software lifecycle, from ideation to development and testing, through to delivery, maintenance and future enhancements. After all, in many situations, initial software creation is just the beginning of a digital asset’s life. If an IoT product is going to be in use for many years, then there needs to be a clear picture of its entire history. Traditionally labelled Application Lifecycle Management’ (ALM), the contribution that automated traceability makes to compliance audits and certification, rather than using spreadsheets to maintain data, can have tangible business benefits. For instance, as a product evolves and is updated, it might be released to the market earlier due to early compliance being achieved, or cost savings achieved thanks to reduced dependency on manual processes.

Successful IoT projects depend on multiple factors and while development is just the beginning of what may be a lengthy, complex journey, surely it makes sense to get the very foundations – those development tools and processes that might make all the difference down the line – in good shape right at the start.