Managing Complexity with Model-Based Systems Engineering

Block Diagrams and Systems Engineering

At its core, systems engineering is a method for solving complex problems by breaking them into smaller components, analyzing those components and the relationships between them, and then using the insights acquired and the understanding developed to carefully engineer and recombine them in ways that solve the original problem.

At Dynamical Systems Group, we practice a version of systems engineering specialized for complex multi-stakeholder ecosystems, one that seeks to optimize outcomes across all of the stakeholders involved rather than for any one of them.

Functional block diagrams have been used in a wide range of applications, from systems engineering to software engineering, since the late 1950s. They became a necessity in complex systems design to “understand thoroughly from exterior design the operation of the present system and the relationship of each of the parts to the whole.”— “Functional Block Diagram,” Wikipedia.org, quoting from Harry H. Goode and Robert E. Machol’s “System Engineering: An Introduction to the Design of Large-Scale Systems” (1957), a foundational text in the field.

Our animating purpose is to update the best practices of traditional systems engineering (its tools for analyzing complex phenomena, its holistic view of how projects take shape, its rigorous verification and validation procedures, and more) in ways that both account for and incorporate the emerging technologies and expanded possibilities that define our ever-changing world.

Systems Engineering: Stakeholders, Managers, and Engineers

Traditional systems engineering identifies three primary categories of actors within every project:

1. Stakeholders: those who are invested in the successful completion of the project;
2. Managers: those who are responsible for coordinating the success of the project as a unified system;
3. Engineers: those who are responsible for deploying subject-area expertise in order to design and implement the component elements of the project’s unified vision.

The job of a systems engineer is to clarify and document the goals and constraints that will guide the actions of these actors throughout the life of the project and to resolve the conflicts between these requirements that inevitably arise throughout a project’s life cycle.

At Dynamical Systems Group, we take a deliberately expansive view of who counts as a stakeholder.

All too often, the stakeholders who shape a project are just its sponsors or funders. We count everyone who is impacted by a project as a stakeholder, because we believe that doing so results in increased accountability and superior design, operations, maintenance, and governance.

We also treat management not as a fixed category of actors, but as one function among the many that must be engineered according to the specific contextual needs of the project: the function of “coordination,” which can be implemented in ways that distribute power more equitably among the project’s stakeholders.

One reason Dynamical Systems Group practices Model-Based Systems Engineering (MBSE) is that it expands the subset of stakeholders with the power to meaningfully engage with a given project.

Model-Based Systems Engineering

Model-Based Systems Engineering involves the development and deployment of mathematical and computational models to define, simulate, monitor, and analyze a project, with a particular focus on forecasting the potential consequences of the critical decisions that must be made as a project is designed, implemented, maintained, and governed.

Nataliya Shevchenko, in a blog post for the Software Engineering Institute at Carnegie Mellon University, offers a concise explanation of Model-Based Systems Engineering:

Model-based systems engineering (MBSE) is a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of complex systems. In contrast to document-centric engineering, MBSE puts models at the center of system design. The increased adoption of digital-modeling environments during the past few years has led to increased adoption of MBSE.

Shevchenko goes on to note that “using a digital-modeling approach, a single source of truth for the system is built in which discipline-specific views of the system are created using the same model elements.” Consequently, digital modeling “creates a common standards-based approach to documenting the system that can be programmatically validated to remove inconsistencies within the models and enforce the use of a standard by all stakeholders [… which] improves the analysis of the system and reduces the number of defects that are commonly injected in a traditional document-based approach.”

In short, Model-Based Systems Engineering employs rigorous mathematical and computational modeling techniques in order to arrive at a deeper understanding of how the interrelated parts of complex systems work, and how those parts could be re-engineered in order to work together more effectively.

It also presents this understanding in a way that is both more internally consistent and more externally accessible than a document-based approach, in order to empower a broader population of stakeholders. Shevchenko’s conclusion is straightforward: “When MBSE is done properly, the result is an overall reduction of development risks.”

In our opinion, MBSE also results in a significant increase in opportunities for non-expert stakeholders to understand, and potentially have a meaningful say in, critical design trade-offs at every stage of a project’s engineering life cycle. Diverse stakeholder input is vital when what is being engineered is an infrastructure or institution (which may also be viewed as socio-economic infrastructure).

Systems Engineering Life Cycles

To understand how Dynamical Systems Group can contribute to a project at each stage of its life cycle, one must first understand our general model of the engineering life cycle, which is to say how we conceptualize the developmental stages through which every successful project progresses.

Although each project’s particular path through this life cycle will be unique, the structure of the life cycle itself remains relatively constant; it is therefore necessary to see how the life cycle’s stages fit together into a unified whole before one can fully grasp the patterns that guide a project through each stage (and on to the next one).

There are countless ways of representing the “engineering life cycle” (that is, of representing the developmental stages of a project from a systems engineering perspective), but this array of models ultimately consists of a set of variations on the same essential idea: Projects develop in interdependent stages, and each of these stages comes with its own set of goals, constraints, and processes for navigating between them.

At Dynamical Systems Group, we view the engineering life cycle as consisting of five stages, each of which involves multiple interrelated functions or processes.

1. Ideation and Conceptualization
2. Requirements and Design
3. Implementation, Integration, and Testing
4. Operations and Maintenance
5. Governance and Evolution

As a project grows from the seed of an initial idea into the complex ecology of a developed, deployed, and durable system, the decisions made at each stage in the process (and the decision-making processes that drove these decisions) inform what takes place, and even what is possible, during the subsequent stages.

The job of a systems engineer is to manage the relationships between these decisions in a manner aware of (and accountable to) the diverse stakeholders with an interest in the outcome. This includes generating detailed analyses of a project’s key decisions, of who can influence each decision (and how), and of the consequences each decision will have across the entire set of project stakeholders.

Low-level decisions about how a component will meet its requirements and high-level decisions about what those requirements ought to be will each involve different stakeholders engaging in different processes. It is the responsibility of a systems engineer, however, to ensure that the processes for decision-making are designed to incorporate constructive feedback from the relevant stakeholders (that is, those who will be affected by the decision in question).

Our version of the engineering life cycle is a zoomed-out version of traditional systems engineering’s “Verification and Validation V.” The model of the engineering life cycle that we apply at Dynamical Systems Group expands on the classical “Verification and Validation V” in a number of ways:

As seen above (Fig. 3), our “V” has both an expanded head (the Ideation and Conceptualization stage) and tail (the Operations and Maintenance stage) that carry the same weight as the descending and ascending arms of the “V” itself (the Requirements and Design and Implementation, Integration, and Testing stages, respectively).

We also view the Governance and Evolution stage as being made up of iterative arcs back over and through the preceding stages, because changes to any system must be engineered as conscientiously as the system itself, in order to avoid destabilizing its functioning in unforeseen and undesirable ways.

Within large projects, each stage is at least partially (and sometimes entirely) dependent on what transpires in the stages that precede it; without milestones to manage co-dependencies, rapid uncoordinated iteration generates thrashing, and has the potential to set off a chain reaction of ever-expanding rework.

Changes to any system must be engineered as conscientiously as the system itself, in order to avoid destabilizing its functioning in unforeseen and undesirable ways.

Taking a holistic view of a project’s developmental trajectory makes it possible to balance “explore and exploit” dynamics: tapping into the benefits of rapid experimentation while also reducing the risk of harm and avoiding costly failures and rework cycles.

The video above, Brian Douglas’s “Some Benefits of Model-Based Systems Engineering” (Systems Engineering, Part 5), clearly shows how parallelism and agility can (and often must) coexist within a staged development life cycle. It does so by focusing on the transition from “Definition” to “Execution,” which is analogous to the transition between the “Requirements and Design” and the “Implementation, Integration, and Testing” stages of Dynamical Systems Group’s model of project development.

The Five Stages of the Engineering Life Cycle

We will now look more closely into each of the five stages that we have identified, in turn:

Stage 1: Ideation and Conceptualization

The first stage of every project involves conceiving an initial idea, and developing that idea into a coherent concept: defining the key problem that the project seeks to address, identifying the various stakeholders, and outlining potential pathways to a solution.

This stage is not simply about brainstorming; it often involves identifying new capabilities and associated possibilities, building proofs of concept (PoCs), and running experiments to validate critical assumptions. By the end of this stage, the foundation for the project has been laid, and broad strategies for achieving its goals have been proposed.

Stage 2: Requirements and Design

After the project has been rigorously conceptualized (that is, once it has a system architecture), it moves into the second stage, in which its overall concept is translated into a set of specific requirements for success, and a collection of components (parts and processes) is designed to meet them.

Identifying requirements involves specifying critical details about how the concept will be brought to life: Goals, constraints, and processes are clearly laid out, and the metrics and mechanisms for validating whether the project’s requirements are being met are documented.

Once this has been done, those responsible for designing the project iteratively break down its top-level requirements into related sub-problems, characterize the dependencies between these sub-problems, and provide specifications for implementing and integrating the components of the overall system that will address them.

Stage 3: Implementation, Integration, and Testing

In this stage, the designs from the previous stage are turned into tangible artifacts, as the components are implemented and tested (in parallel, to the greatest possible extent) before they are integrated (iteratively) into the overall system.

Integration testing ensures that the system’s components interoperate as intended, and ultimately assemble into a coherent whole that demonstrably meets the system-level requirements identified in the previous stage. This approach encourages the kinds of flexibility and ongoing refinement that result in the highest-quality output.

Stage 4: Operations and Maintenance

Once the system has successfully been implemented, integrated, and tested, the project is ready to be deployed for use. The Operations and Maintenance stage begins when the project goes live; it involves both operating the system in its real-world conditions and performing ongoing maintenance on the system. The purpose of Operations and Maintenance is to ensure continuous functionality despite modest variations in the operating environment.

The Operations and Maintenance stage is tactical in nature as it involves optimizing the performance of the system under the rules and protocols that govern it: identifying and tracking its key performance indicators, monitoring its infrastructure, and creating manuals for (or as part of) training humans in its safe operation. Preventive maintenance is an essential element of this stage, but so is identifying and handling failures when they inevitably arise.

Stage 5: Governance and Evolution

If the Operations and Maintenance stage is tactical in that it involves optimizing the system’s performance under a fixed set of rules and/or relatively constant conditions, the Governance and Evolution stage is strategic; it is about steering the system safely through those times when the existing frame of reference is inadequate. The governing rules and/or operating conditions are in flux.

This stage consists of conceptualizing, designing, implementing, and evaluating potential interventions into the project while it is already operating, and there are already stakeholders who have come to rely on it. Governance may take many forms, but regardless of the decision-making processes employed, the actors making governance decisions must be accountable to the various stakeholder groups that their decisions will affect.

Enabling a system to evolve is necessary because in the real world the conditions and context around a project invariably change over time. Thus, the “last” stage of our engineering life cycle involves identifying when changes to an existing system are warranted, and guiding the system through a fresh iteration of the life cycle aimed at defining and implementing the necessary modifications.

Cyborg anthropologist Amber Case has argued that “[a]t a fundamental level, all design is governance.” At Dynamical Systems Group, we agree, and would add that in our digitally mediated world, good governance is tantamount to ethical engineering practice.

Conclusion

Systems engineering is the most reliable process that humanity has yet developed for solving complex problems: the ones with too many moving parts to be comprehensible from any single perspective.

At Dynamical Systems Group, we prioritize a model-based approach to systems engineering because it makes it possible to untangle these complex systems in ways that empower a broad group of stakeholders (including those lacking specialized expertise). Through modeling, complexity can be made comprehensible to all.

In our work, models are not used to appeal to the authority of the algorithm; they are tools for increasing the legibility of complex systems so that the designers, operators, and governing authorities of those systems become more accountable to the stakeholder groups who will be impacted by the decisions they make. Therefore, we favor a model-based approach except when doing so is impractical or in the rare instances where an alternative methodology provides additional insight and increased accountability.

Systems engineering is not just about resolving a specific problem at an isolated moment in time; it’s about stewarding projects over time, as well as addressing any specific issues that arise over the long arc of a project’s life cycle with awareness of that project’s history, current status, and potential future. At Dynamical Systems Group, we understand the importance of adaptability; no matter where your project might be on its journey, we work to provide holistic, comprehensive guidance to get it to its destination, and to keep it going once it gets there.

With contributions from Nick Hirannet.