Embedded systems, by their definition, contain mechanical and electronic components and, through that, interact with the real world. Many of these systems may cause harm to humans if they act in erroneous ways. This is, of course, the case for aeronautical and automotive applications as well as for medical equipment. But also most systems that are intended for operation without human supervision, such as heating systems, pumps and the like, need to provide evidence that they’re safe in terms of not causing fire hazards or other types of risks.
To address this, a sizable community of safety experts has emerged over the last decades, as well as numerous standards and several organizations that conduct product certifications. The cost associated with certification often is significant, leading to a culture where providing updates and changes to certified software is viewed as very challenging. The consequence is that approaches such as DevOps directly oppose the culture and ways of working in the safety community.
One way to think about regulated products is to put these in three categories: the reactive group, the self-certification group and the external certification group. The reactive group you find in, for instance, fintech. The government bodies have defined regulations for financial institutions to adhere to, but these bodies do not continuously verify that the regulation is followed as it should. Instead, periodically and randomly, a financial institution will receive an audit and then needs to be able to produce all the information required by the regulation. For companies in the reactive group, adopting continuous deployment and DevOps is entirely feasible. Especially fintech startups use DevOps as the norm and companies like Merkely offer great solutions to support them. However, also in telecom, the large players are offering their customers frequent (bi-weekly or monthly) software updates to products in the field.
The self-certification group can be found, among others, in the automotive space. Here, the industry typically has defined its own safety standards, such as ISO 26262. These standards typically allow for self-certification where OEMs have ISO 26262 assessors as employees who sign off on vehicles when all the elements of the standard have been satisfied. In this group, we see that some of the companies have also adopted DevOps for safety-critical software, one example being Tesla, whereas the majority of the OEMs are experimenting with ways to make this a reality for them. Here, methods and approaches are available to maintain the safety case continuously as part of the overall Agile sprint. Thus, a sprint shouldn’t just deliver working code but also collect all the evidence required for the parts of the safety case that were affected by the functionality developed during the sprint.
The external certification group, including the medical equipment companies, are required to use outside assessors, such as the FDA or the EMA (European Medicines Agency), before being allowed to make offerings available in a general capacity. This group has traditionally been the most conservative when it comes to upgrading software and adopting faster release cycles. Not because the medical companies don’t want it, but because the entire ecosystem of government institutions and certification organizations are geared towards a waterfall-style, big-bang certification approach. Many companies even in this space are, however, experimenting with faster release cycles, eg by partnering with research hospitals where the software is deployed in equipment that’s not being used clinically but rather for research purposes. However, even here, we see that the FDA, EMA and other bodies are starting to request faster responses by equipment manufacturers to, for instance, security issues, and the first proposals are being discussed on how a DevOps approach could be realized in this context. In the coming years, we’re going to see a full-fledged adoption in these industries as well.
Categorically rejecting DevOps and faster release cycles just because your offering is subject to regulation and certification of some kind is increasingly an outdated belief. Even in the most strict industries, we see many developments to prepare for DevOps. It’s of critical importance to get your company ready for this new reality by building the capabilities and running experiments that inform the changes required for you to be able to deploy this across your organization. We don’t do DevOps for its own sake, but because all systems that deliver any form of value should continuously become better and more valuable. And if I need to choose between a system that’s static and safe and a system that’s continuously improving and safe, I know what I prefer. What do you think your customers prefer?
To get more insights earlier, sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
