Keeping Pace With the Evolving Software Ecosystem

Software systems are ostensibly taking over the digital landscape, adding to the many existing and newly developed functions and systems previously handled by physical equipment and the brains and muscles of humans. As a result, conditions attributable to these systems are increasingly aligning with software rather than physical systems. Historically, software vendors and services providers have enjoyed greater legal and regulatory lenience than physical equipment manufacturers.¹ Confusion is not uncommon when categorizing evolving systems and applying appropriate restrictions and responsibilities. This leads to idiosyncratic requirements for combined systems. It is important to clarify distinctions among various forms and configurations of digital–physical systems.

Errors in software systems have damaged financial and personal lives. Consider the post office system that falsely accused hundreds of postal workers in the United Kingdom of embezzlement.² It was later discovered that the accused were innocent, but by that time, many lives had been affected. Errors in software packages, such as Excel spreadsheets, have also led to organizations incurring financial penalties or losing consumer trust when not warranted.³

Software-intensive systems have always been somewhat enigmatic, and their quality has been limited by the abilities of analysts, programmers, and testers, and by financial and time constraints. As software systems have become more complex and combined into systems-of-systems, it is increasingly difficult, expensive, and time consuming to ensure their quality. While deterministic software systems can, with adequate time and effort, be quality-assured to a degree, the large scale of adaptive artificial intelligence (AI)/machine learning (ML) systems precludes exhaustive testing because the behavior of such systems is uncertain and unpredictable. Consequently, modern systems inherit all the risk of prior systems and add a substantial amount of their own.

As software continues to play a greater role in everyday life, it is crucial to be able to understand and control it. The first step in this process is to look at the historical evolution of software systems and what to expect going forward. Organizations can then implement several measures—namely, law and regulation enforcement, standards, certifications, and contract negotiations—to address this rapidly growing environment.

The rapid transition of manual and mechanical devices to software-intensive systems and the increasing amount of software running on embedded systems are discussed in an earlier article.⁴ Now, it is worth exploring how evolving systems might be controlled.

Historical Perspective

There have been many major influences on human activity and the development of tools, weapons, and other systems over the millennia. Perhaps most notable is the rapid introduction and adoption of new technologies over the past several decades, particularly in recent years. This increasing rate of change shows no abatement. Indeed, technology is moving faster than ever, and AI is a prime example.

The focus of this article is on what the author has dubbed the “software age,” which began in the 1960s. This differs slightly from the usual definition of the information, digital, or cyber age in that although the early introduction of computers and networks involved instructions, there were many ways of inputting, processing, and outputting results into, within, and out of computing machines other than using software programs. With analog computers, for example, programming is achieved by changing the wiring of electronic components (such as amplifiers, capacitors, and resistors) to create simulations of mechanical systems.

While physical systems are advancing over time, the software component is becoming an increasing percentage of systems as new software technologies, such as cloud computing, AI, and quantum computing, are introduced. This trend is illustrated in figure 1, which depicts overall growth in software and hardware and shows the increasing encroachment of software into areas previously dominated by physical equipment.

Note that the diagram is not drawn to scale and that embedded software applies to applications, whereas firmware usually refers to system utilities. The line between embedded software and firmware is increasingly blurry as firmware can be updated online or by the user, which was not the case in the past.

Important Definitions

There are several types of systems. The basic types of systems are generally agreed upon; however, there are differences of opinion in the cyberlandscape concerning which systems supersede or include others. For example, some experts claim that mechatronics systems include robotics, industrial control systems, cyber–physical systems (CPS), and the Internet of Things (IoT).⁵ Implicitly, the Industrial Internet of Things (IIoT) should also be included.

For example, in a roundtable discussion, Hayden Thompson of the THINK Group stated that “...If you are European, the general consensus is the IoT is a subset of CPS, and if you are American, the consensus tends to be that CPS are a subset of the IoT.”⁶ Not only is the categorization of these systems subject to argument, but within each category, namely, IoT and CPSs, there are many flavors of such systems.⁷

However, the most significant difference between these systems is whether they are connected to the internet. This is arguably the most important factor when determining risk levels for these systems, not whether a particular system falls within a specific definition.

Resolving these differences of opinion might be more readily achieved if the relatively less popular term “mechatronics” were used for these systems. Mechatronics systems cover a broad spectrum of cybersystems, as shown in figure 2.

Reliability, Availability, and Obsolescence of Software and Hardware

Software and hardware are very different, and as they come together and systems become more software-intensive, it is important to distinguish between them.

Software does not break. As such, it may become less useful over time as improved versions are released that supersede prior versions. Some vendors may purposely obsolesce earlier versions of their products to sell newer versions of the same product. At the same time, many early computer systems may not run new software effectively, or run it at all.

Conversely, hardware components do break and may or may not be repairable.⁸ In any event, newer devices are often faster and, in some cases, less expensive. The holy grail of some system developers is to create perpetual systems: “If we can figure out how to prevent ... machines from breaking down and keep them generating their own power, their lifetimes could 9be infinite.”⁹

To further understand this landscape, one can review the relative failure rates and useful life spans of both software and hardware.

Software
Software programs and their various versions do not wear out physically; however, the media on which programs are stored can become unusable. Software becomes functionally and/or operationally obsolete over time, and more vulnerable as errors, or bugs, within the code are revealed. As such, it may no longer be supported by the manufacturer or vendor. Some errors, particularly security-related vulnerabilities, need to be addressed promptly.¹⁰

Certain software, such as legacy banking and government systems, runs for decades before being replaced. Other software applications are obsolete after a year or two.

There is often a beta testing period where the manufacturer releases the software, which has undergone limited internal testing, to select users, who provide free testing. These users are instructed to report any issues that were not caught by manufacturers in the unit, integration, acceptance testing, and quality assurance phases of the software development life cycle. When enough errors have been detected and corrected, manufacturers will release the software to the public.¹¹ After the software is released, defects make themselves known and are corrected using periodic patches. At some point, it might be more effective to publish a new release that corrects accumulated errors and may provide some new functionality. However, when manufacturers decide that it is no longer worth supporting a particular version, they announce that it will no longer be supported. At that point, the failure rates and vulnerabilities increase, and customers may choose to acquire a new version or (possibly) contract out support to third parties, if permitted and available. Sometimes, a software manufacturer will turn over support to an open-source group.

This scenario is often independent of the hardware running the software, but quite frequently, new software requires new hardware or additional hardware resources compared to prior versions.

Hardware
Computer hardware and other physical elements have their own life cycle. Some machines, such as aircraft, can last for decades if properly maintained. Other devices, such as smartphones, may be discarded due to obsolescence after only a couple of years, even though they are still functionally capable and could last for decades from a physical perspective.

The hardware equivalent of software beta testing is the burn-in period. It is common for equipment, when initially released, to fail under real-world conditions that are different from manufacturers’ testing environments. This can be seen in the higher demand for initial recalls for appliances, vehicles, etc. Equipment usually reaches a point of relatively low failure rates with occasional component failures that are repaired under regular maintenance and recall agreements. However, eventually, the equipment is no longer supported, as parts may no longer be available and the population with the knowledge of how to fix the equipment diminishes. As is the case with software, it might be possible to contract repair out to third-party services. Otherwise, the equipment will need to be replaced.

It is worth noting that software and hardware life cycles do not generally coincide. This means that a customer may be stuck with software that still works but does not operate on new equipment, or hardware that still operates but is not compatible with updated software. In these cases, the earlier obsolescence date will take effect.

Notable Exceptions
Most physical systems deteriorate over time, but some biological systems, such as muscles, strengthen with use and exercise. While this is not the case for software, equipment often benefits from use and can become non-operational if not used or maintained for some time due to, for example, rust of metals and breakdown of substances, such as lubricants. Furthermore, it might be beneficial to keep electronic equipment running continuously, since turning the equipment on and off might result in temperature changes that age the components.

Animal and other natural systems are often self-healing and can heal ailments, such as minor wounds, viral and bacterial infections, or vegetation blights. Similarly, some computer systems are designed to be self-healing, although it is more common to use redundancy and fallback systems to overcome failures or malfunctions.

While such systems do not last forever, their useful lives can be extended considerably by regular use and self-healing technologies. The ability to power these systems may continue over long periods through the use of solar or wind energy.

Control Measures for Software

There are several measures that can be taken to control the quality of software-intensive systems. These measures and their relationships are illustrated in There are several measures that can be taken to control the quality of software-intensive systems. These measures and their relationships are illustrated in figure 3.

Laws and Regulations
In general, laws dictate what one must do (e.g., protect personal information and intellectual property) and are established by global, regional, national, state, and local legislative bodies. Laws include statutes that are written by legislative bodies (e.g., US Congress and state legislatures), as well as common law and case law. Regulations state how one might accomplish the dictates of laws (e.g., implement multifactor authentication [MFA]) and emanate from government agencies.

To date, most laws relating to software address the personal privacy of individuals and the protection of intellectual property. Regulations address specific actions that need to be undertaken to adhere to laws. As an example, the US Gramm-Leach-Bliley Act (GLBA) of 1999, also known as the Financial Services Modernization Act, established consumer privacy rights.¹² Agencies, such as the Office of the Comptroller of the Currency (OCC), issue regulatory rules and enforce them.

As the body of AI software grows exponentially, researchers have speculated about corresponding laws and regulations, claiming that they will generally follow prior software rules promoting privacy. To this end, readers must be aware of the so-called “pacing problem,” where technology outpaces legal and ethical regulation, which appears to be particularly relevant to AI systems.¹³

Standards and Certifications
While there is no shortage of guidance related to software engineering (e.g., the Software Engineering Body of Knowledge [SWEBOK]), there is little information available in terms of certification of software products themselves.¹⁴ There have been numerous attempts at establishing global software security and safety standards, but they have seen relatively little success.¹⁵ There are possible structures that could establish such standards.¹⁶ However, even if there is consensus on what the standards should address, enforcing them is by no means a given, as countries are determined to maintain their individuality and autonomy.

Contracts: Negotiations and Enforcement
While large software houses might presume that they can provide products on a take-it-or-leave-it basis, it may be feasible to achieve certain concessions through contract negotiation.¹⁷ Much depends upon the relative power of the negotiating teams, where large-volume customers will have greater success than smaller organizations and individuals in obtaining more equitable contractual terms and conditions.

Enforcement of contracts—even when the concessions by the software provider are minimal—can be difficult. Those who purchase software are generally limited to the purchase price of the software products, and this does not include consequential damages, e.g., autonomous vehicle manufacturers blaming drivers for accidents resulting from software errors. This contrasts with accidents from mechanical failures, where recalls come into effect, and victims are often successful in litigation.

Conclusion

The rapidly evolving dominance of software over physical components of systems demands that measures of control, such as laws, regulations, standards, and certifications, which have long been applied to equipment, be similarly employed for software-intensive systems. While there are some rudimentary laws and regulations, and spasmodic attempts at certification have been made, there is still much to be done in this area, especially as AI becomes ubiquitous and quantum computing is on the horizon.

Endnotes

¹ Axelrod, C.W.; “Are ‘Viruses’ Naughty by Nature?,” The New York Times, 1999
² Colchester, M.; Sugden, J.; “U.K. Law Would Exonerate Postal Workers,” The Wall Street Journal, 2024
³ Hoag, A.; “The 7 Biggest Excel Mistakes of All Time,” LinkedIn, 2018
⁴ Axelrod, C.W.; “The Softening of Firmware and Hardware,” Crosstalk, 2023, p. 21-34
⁵ Axelrod, “The Softening of Firmware”
⁶ DeFranco, J.F.; “Should Cyberphysical Systems and the Internet of Things Get Married?,” Computer, vol. 55, iss. 3, 2022, p. 14-23
⁷ DeFranco, J.F.; “12 Flavors of IoT,” Computer, vol. 54, iss. 10, 2021, p. 133-137
⁸ In the 1960s and 1970s, mainframe computers would fail with regularity, perhaps every couple of days. Data center operations staff became experts in detecting problems and restarting systems. Today, technologies (particularly those incorporating microchips) may run for years without going down. This means that failures leading to system downtime tend to be the fault of software errors.
⁹ Rayne, E.; “AI Is Actually a Form of ‘Alien Intelligence,’ Harvard Professor Claims—And It Will Surpass Humans,” Popular Mechanics, 2025
¹⁰ Some software providers may purposely obsolesce prior versions in favor of newer versions by discontinuing technical support, especially for security-related issues, although they would likely not admit it. They may instead emphasize the many benefits of the replacement software as the reason for no longer supporting prior versions.
¹¹ Interestingly, virus creators go through a similar cycle; the virus is “in the zoo” when it has been developed and subjected to limited testing. When hackers have determined that the virus is effective, they will then release it “into the wild.” If the equivalent of beta testing can be detected, then antivirus software signatures and other protective measures can be developed and installed before the main attacks are launched.
¹² US Federal Trade Commission, Gramm-LeachBliley Act, USA
¹³ Steidl, R.; “Back to the Future: How Data Privacy Laws Can Teach Us What to Expect With AI Regulation,” Constangy Cyber Advisor, 7 April 2025
¹⁴  Washizaki, H.; Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0, IEEE Computer Society, USA, 2024
¹⁵ Axelrod, C.W.; “Enforcing Security, Safety and Privacy for the Internet of Things,” Long Island Systems, Applications and Technology, 2015, p. 1-6
¹⁶ Axelrod, C.W.; “The Creation and Certification of Software Cybersecurity Standards,” 2016 IEEE Long Island Systems, Applications and Technology Conference (LISAT), USA, 2016, p. 1-6
¹⁷ Axelrod, C.W.; “Using Contracts to Reduce Cybersecurity Risks,” CrossTalk: The Journal of Defense Software Engineering, vol. 30, 2017

C. WARREN AXELROD, PH.D.

Is an information technology consultant with expertise in cybersecurity, privacy, cyberrisk management, software security, safety and resilience, supply chain cybersecurity, and critical infrastructure protection. Previously, he was the business information security officer and chief privacy officer for US Trust. He is a cofounder of the Financial Services Information Sharing and Analysis Center (FS-ISAC) and represented the banking and finance sector’s cybersecurity interests in Washington, D.C., USA, during the Y2K date rollover. Axelrod received the IEEE Computer Security Distinguished Contributor Award in 2023. In addition to authoring the books Engineering Safe and Secure Software Systems and Outsourcing Information Security, Axelrod co-edited Enterprise Information Security and Privacy. He has published more than 140 professional articles and chapters, and has delivered more than 150 professional presentations. His current research interests include the cognitive–behavioral aspects of cybersecurity risk and the security and safety of cyber–physical systems.