Complex software-intensive systems typically consist of mechanical, electronic and software components. To ensure that all the parts come together in an integrated system that delivers the intended functionality to the customers, we need people to keep it all together. These are often referred to as systems engineers or system architects.
Systems engineers frequently have a mechanical or electronics background and tend to be less well-versed in anything digital, such as software, data or AI. As a consequence, they tend to focus on the technologies they’re most familiar with and seek to allocate as much functionality as possible to mechanics and electronics. They only resort to software when the feature can’t be realized otherwise.
Consequently, software was traditionally treated as being in service of the rest of the system, which led to all kinds of challenges. A typical challenge was that systems were developed sequentially, meaning that the mechanical parts were developed first, followed by the electronics, and only then came the software that was supposed to bring it all together. Often, the mechanics and electronics projects were delayed, leading to software being squeezed as the company sought to keep the release deadline. As a result, the software engineering department was often regarded as a bunch of incompetent bozos as they were always the ones that were viewed as having caused delays in the product release and were responsible for all the quality issues.
A second challenge was that systems engineers were overly focused on the bill of materials and tended to squeeze the capabilities of the electronics. This caused the software engineering department to struggle to make all the requested features fit in a highly constrained compute infrastructure. That often led to less-than-ideal design practices, such as sacrificing modularity for speed and reduced memory usage.
These days, most systems engineering projects have adopted a parallel approach where the mechanics, electronics and software are developed at the same time. Although this sounds great in theory, the reality is that there often still is a sequential part to things as the electronics need to fit in the slots offered by the mechanical design and the software has to be adjusted to the capabilities of the hardware. In many of the companies I work with, the software teams still have to wait quite long before they get access to early versions of the hardware, even if it’s breadboarded.
The main transition that’s ongoing in systems engineering is responding to the digital transformation. Whereas earlier, we could design systems that were done once we started production and where software updates were infrequent, customers are increasingly expecting systems that keep improving throughout the entire life of the product in the field. From telecommunications to factories and from mobile phones to cars, we’re expecting continuous improvements and new features until the product or system is retired, which may be decades from now.
Many companies have responded to this challenge by continuing to treat the “atoms,” ie the mechanics and electronics, as frozen at the start of production and using the “bits,” ie the software and AI models, as the mechanisms to deliver continuous value during the economic life of the system. However, especially for systems that are supposed to be in operation for a decade or more, it’s virtually impossible to put such bleeding-edge technology and so much headroom in the system at the start of production that the system can continue to evolve purely based on software updates for its entire life.
Instead, companies need to move to true digital offerings where the business models are largely continuous and the evolution of the system includes not just new software but also new electronics periodically and occasionally even new mechanics. Of course, the release cost of new electronics and mechanics is orders of magnitude higher than that of software and hence the frequency will be much lower as well. But we need to engineer systems that can evolve in more ways than just through software.
As an example, GPUs and other hardware for efficiently running deep learning models are evolving at an outrageous pace. Deploying a new model on hardware that’s five years old, or even a year or two old, is simply not feasible. Few long-lived products will be able to remain competitive without including updates of at least some hardware post-deployment.
I’m far from the first one to recognize this. More and more industries are adopting the principles of software-defined systems. That requires a new approach to systems engineering where it, by and large, becomes the same as software engineering. Of course, we still need mechanics and hardware, but these are in service of the continuously evolving system capabilities that are predominantly driven by software and AI.
This leads to amazing new engineering capabilities. Rather than predicting how users will behave, how mechanical parts will deteriorate with use and how the system will deliver value to customers, we can now have fast data-driven feedback loops where we can measure the relevant aspects of the system, make changes and measure the impact of these changes.
Of course, many companies have used simulations for many years, especially for mechanics. For instance, car companies can now run thousands upon thousands of crash tests using simulation rather than a handful of real-world ones. However, there almost always is still a gap between the simulated behavior and the real world. This new software-defined systems engineering approach will still use simulation but will also be able to use real-world data continuously.
Systems engineering traditionally was focused on mechanics and electronics and treated software as the ugly stepchild. With the digital transformation, companies are increasingly expected to engineer systems that evolve throughout their economic life. This needs to include deploying new software and AI models but also periodically upgrading electronic and mechanical components. That causes systems engineering and software engineering to become virtually the same discipline and we really need to remove the hard distinction between the two. To end with a quote by Albert Einstein: “No problem can be solved from the same level of consciousness that created it.” That’s true for systems engineering as well.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or X (@JanBosch).
