Six Practices Transforming Systems Engineering

Many of the companies that I work with are embedded systems companies, meaning that the products, systems and solutions sold by these companies consist of mechanical, electronic and software parts. Traditionally, software was only a small part of these systems, which resulted in the system engineering process to be driven by the mechanical and to some extent the electronics. As mechanics and electronics are driven by atoms, rather than bits, this causes systems engineering to be slow and following a waterfall-style development process. As digitalization and software play an increasingly central role in all (interesting) systems, systems engineering needs to go through a fundamental transformation.

Figure: Six practices

As shown in the figure above, digitalization and software are driving major transformations affecting at least six practices or approaches. Below we discuss these in more detail.

#1 From systems built to last to systems built to evolve: Traditional systems engineering is slow and waterfall because the engineers assume that they’re building a system that is required to last a lifetime. In fact, traditional systems in  military, healthcare, transport, telecommunications, etc. are expected to last for decades with minimal R&D during the lifetime of the system. The first transformation in systems engineering is that we need to shift our focus to systems that are built to evolve, rather than built to last. This means that the systems architecture needs to allow for a constant flow of new software, electronics and even mechanical parts, resulting in a system that is continuously getting better.

#2 From opinion-based to data-driven decision making: In many organizations, there is an institutional memory and experience is valued. The problem is that the experience that senior leaders have accumulated tends to be years and sometimes decades old. In a fast changing world, experience easily becomes a double edged sword. It can help teams make faster decisions and avoid mistakes. At the same time, it can cause entire organizations get stuck in an outdated way of working and decision making. The best antidote to this is the use of data for decision making. In the words of Edwards Deming: In God we trust; all others must bring data.

#3: From deeply integrated to modularized architectures: When architecting a system that will remain static after deployment, the primary focus is on resource efficiency. Optimization of resources can often be accomplished by allowing for intricate dependencies between disparate parts of the system. Systems that are designed to evolve throughout their lifetime can not afford the high degree of dependency and needs to be modularized. This typically leads to some increase in resource usage, but especially electronics needs to be overdimensioned for the requirements at initial deployment anyway in order to allow for evolution of functionality. The electronics needs to be designed for lifetime cost and not for bill of materials.

#4: From hierarchical organization to an ecosystem of partners: Hierarchical organizations allow for top-down management of systems engineering and control from a central position. This leads to slow decision making and easily lets an organization get bogged down in the complexity of the system. Especially for evolving systems, the organizational model should be that of an ecosystem of partners, both internal and external to the organization, that operate in relative autonomy while governed by system architects whose only job is to avoid negative system implications due to local decisions by partners.

#5: From satisfying requirements to constant experimentation and innovation: Traditional systems engineering tends to be requirement centric and assumes a predefined specification of sufficient detail, internally consistent and without conflict. Of course, few realistic sets of requirements satisfy these criteria: if only because it is really difficult to envision a system before you have experienced it. Systems built to evolve allow some or most of the functionality to be developed after the initial deployment of the system, which allows for experimentation with customers and systems in the field, which facilitates innovation throughout the lifetime of the system.

#6: From static to dynamic, continuous certification: When systems constantly evolve after initial deployment, we need certification approaches that allow us to apply these principles also for the certified parts of the system. The current approach to limit the safety critical or certified part of the system to the minimum and interfacing this core with continuously evolving functionality deployed on top of it will only get us so far.

Finally, the main transformation is how functionality is allocated to different technologies. Traditionally, system engineers avoided software as it was poorly understood by many and often viewed as a problem, rather than a solution. With the increasing role of software, system engineers need to adopt the principles as shown in the figure below.

Figure: The implications for systems engineering

Concluding, in the digitalization age, systems engineering needs to transform to prioritize bits over atoms, evolution over static designs, modularity over deep dependencies and ecosystems over hierarchy. In many ways, this represents a fundamental shift in the way systems engineers operate, but it is a necessary one as the companies not adopting these principles are setting themselves up for disruption. If you want more, my INCOSE keynote on youtube might be interesting to watch.