For years, universities and the corporate world have channeled students into one of two general groupings. One set is taught skills that they use to build amazing consumer technology, much of which manifests as apps that live on smartphones. The other group of developers is equipped to create business-to-business (B2B) commercial applications, most of which reside in the cloud.
Unfortunately, the lessons learned by both consumer and B2B developers do not translate well to the world of mission-critical applications. In these systems, such as ADAS, medical and surgical equipment, and telecom satellites, failure truly is not an option.
Consider the Silicon Valley mantra of “move fast and break things.” The reasonable premise is that development teams should iterate, try new things, …
For years, universities and the corporate world have channeled students into one of two general groupings. One set is taught skills that they use to build amazing consumer technology, much of which manifests as apps that live on smartphones. The other group of developers is equipped to create business-to-business (B2B) commercial applications, most of which reside in the cloud.
Unfortunately, the lessons learned by both consumer and B2B developers do not translate well to the world of mission-critical applications. In these systems, such as ADAS, medical and surgical equipment, and telecom satellites, failure truly is not an option.
Consider the Silicon Valley mantra of “move fast and break things.” The reasonable premise is that development teams should iterate, try new things, learn from mistakes and improve with every iteration.
Agile development practices add well-tested functionality gradually. But “move fast and break things” suggests that it is worthwhile to make mistakes and disrupt technologies in the name of innovation rather than play it safe by working at a slow and steady pace. The motto has taught a whole generation of software developers to value speed over stability. It suggests that change, as opposed to creating stable systems built for the long term, is always a good thing. And entire ecosystems feed into this approach.
Consider also Jeff Bezo’s API Manifesto. Twenty years ago, Bezos mandated that all of Amazon’s internal systems must expose their data and functionality through APIs. That approach was essential to the establishment and success of Amazon Web Services — but it also taught a new set of developers to build things in the cloud with the expectation of nearly unlimited resources.
Now combine those two trends. The vast majority of developers begin their careers expecting no restrictions or limitations on the way they code. They believe that they have the entire cloud to power their applications and the tacit permission to move fast and break things.
Those premises work well for consumer mobile apps and B2B information technology efforts, but they are anathema to anyone who builds systems that can never fail.
The Difference With Mission-Critical Applications
Every project has hardware constraints and budget limitations. But mission-critical software has additional needs — and those needs often conflict with the two approaches mentioned above.
Most cloud B2B applications and consumer software can be updated regularly. It is less feasible to push fixes to edge computing devices that operate at low bandwidth or with limited storage. Designing for hardware such as medical devices, portable point-of-sale devices and remote sensors requires developers to consider factors such as storage space, weight, power consumption and duty cycles. Such devices certainly lack the unlimited power of the cloud or the certainty of guaranteed connectivity.
The projects for these complex systems often have extended time frames. They can take years to design and launch properly. The original hardware may be several generations old by the launch date, so the systems must be designed to adapt over time to avoid becoming outdated.
Mission-critical systems often require safety testing and other certifications to ensure that the application continues to function flawlessly in worst-case scenarios. Any changes or updates, however minor, may require recertification.
Iterative development certainly can work in these environments. However, in this context, “moving fast” occurs at vastly different speeds. A consumer app that measures a diabetic’s glucose level can be updated daily, if necessary. That is not so for the patient-monitoring equipment used during surgery. And the seemingly infinite cloud storage that developers take for granted is rarely an option for devices that must function even when connectivity is lost.
AI Complicates Things
Mission-critical systems must behave consistently and predictably. An application should always produce the same output when given the same input and starting conditions.
Mission-critical applications must be aware of changes introduced by over-the-air (OTA) updates. Updating the software alters the original profile, rendering the safety evidence irrelevant. That has been a challenge for as long as OTA updates have been around, but experienced embedded systems developers have adjusted their processes accordingly.
AI, by its nature, is not deterministic — and it will be increasingly less deterministic.
Need a hands-on example? Ask ChatGPT a question. Then, two days from now, ask it the exact same question. See if the answer changes. Sometimes it does; sometimes it does not. But by default, large language models are not set to react in a deterministic way because of the variables, the stimuli and the range of different permutations that affect it. So the AI built into mission-critical applications must be able to shift as well.
That makes development — and the regulations and certifications designed to provide assurance of their performance — more difficult.
Building Toward a Third Path
The development approaches of moving fast and taking advantage of unlimited cloud scale are not wrong or broken. They are exactly what were needed to drive the innovation we have seen in certain industries. But as intelligence shifts to the edge and we see machines becoming smarter and more autonomous, there will be an increasing need for a third approach to systems development, where reliability and stability are the key mantras. The organizations that can innovate in those environments will become the next set of market leaders.
For years, universities and the corporate world have channeled students into one of two general groupings. One set is taught skills that they use to build amazing consumer technology, much of which manifests as apps that live on smartphones. The other group of developers is equipped to create business-to-business (B2B) commercial applications, most of which reside in the cloud.
Unfortunately, the lessons learned by both consumer and B2B developers do not translate well to the world of mission-critical applications. In these systems, such as ADAS, medical and surgical equipment, and telecom satellites, failure truly is not an option.
Consider the Silicon Valley mantra of “move fast and break things.” The reasonable premise is that development teams should iterate, try new things, learn from mistakes and improve with every iteration.
Agile development practices add well-tested functionality gradually. But “move fast and break things” suggests that it is worthwhile to make mistakes and disrupt technologies in the name of innovation rather than play it safe by working at a slow and steady pace. The motto has taught a whole generation of software developers to value speed over stability. It suggests that change, as opposed to creating stable systems built for the long term, is always a good thing. And entire ecosystems feed into this approach.
Consider also Jeff Bezo’s API Manifesto. Twenty years ago, Bezos mandated that all of Amazon’s internal systems must expose their data and functionality through APIs. That approach was essential to the establishment and success of Amazon Web Services — but it also taught a new set of developers to build things in the cloud with the expectation of nearly unlimited resources.
Now combine those two trends. The vast majority of developers begin their careers expecting no restrictions or limitations on the way they code. They believe that they have the entire cloud to power their applications and the tacit permission to move fast and break things.
Those premises work well for consumer mobile apps and B2B information technology efforts, but they are anathema to anyone who builds systems that can never fail.
The Difference With Mission-Critical Applications
Every project has hardware constraints and budget limitations. But mission-critical software has additional needs — and those needs often conflict with the two approaches mentioned above.
Most cloud B2B applications and consumer software can be updated regularly. It is less feasible to push fixes to edge computing devices that operate at low bandwidth or with limited storage. Designing for hardware such as medical devices, portable point-of-sale devices and remote sensors requires developers to consider factors such as storage space, weight, power consumption and duty cycles. Such devices certainly lack the unlimited power of the cloud or the certainty of guaranteed connectivity.
The projects for these complex systems often have extended time frames. They can take years to design and launch properly. The original hardware may be several generations old by the launch date, so the systems must be designed to adapt over time to avoid becoming outdated.
Mission-critical systems often require safety testing and other certifications to ensure that the application continues to function flawlessly in worst-case scenarios. Any changes or updates, however minor, may require recertification.
Iterative development certainly can work in these environments. However, in this context, “moving fast” occurs at vastly different speeds. A consumer app that measures a diabetic’s glucose level can be updated daily, if necessary. That is not so for the patient-monitoring equipment used during surgery. And the seemingly infinite cloud storage that developers take for granted is rarely an option for devices that must function even when connectivity is lost.
AI Complicates Things
Mission-critical systems must behave consistently and predictably. An application should always produce the same output when given the same input and starting conditions.
Mission-critical applications must be aware of changes introduced by over-the-air (OTA) updates. Updating the software alters the original profile, rendering the safety evidence irrelevant. That has been a challenge for as long as OTA updates have been around, but experienced embedded systems developers have adjusted their processes accordingly.
AI, by its nature, is not deterministic — and it will be increasingly less deterministic.
Need a hands-on example? Ask ChatGPT a question. Then, two days from now, ask it the exact same question. See if the answer changes. Sometimes it does; sometimes it does not. But by default, large language models are not set to react in a deterministic way because of the variables, the stimuli and the range of different permutations that affect it. So the AI built into mission-critical applications must be able to shift as well.
That makes development — and the regulations and certifications designed to provide assurance of their performance — more difficult.
Building Toward a Third Path
The development approaches of moving fast and taking advantage of unlimited cloud scale are not wrong or broken. They are exactly what were needed to drive the innovation we have seen in certain industries. But as intelligence shifts to the edge and we see machines becoming smarter and more autonomous, there will be an increasing need for a third approach to systems development, where reliability and stability are the key mantras. The organizations that can innovate in those environments will become the next set of market leaders.
i