Complexity is nothing new to systems engineers and managers. The discipline of systems engineering evolved to improve our ability to deal with scale, interdependency, and complexity in systems development. Few systems engineers would doubt that complexity is increasing every year. The rate of change, the increasing interdependence and adaptability of systems, and the increasing ambitions of our clients ensure that complexity keeps expanding to the limits of our capacity to cope with it.
— A Complexity Primer for Systems Engineers, INCOSE 2016.
In an effort to keep pace with the demands of solutions to complex problems, systems engineers are faced with an ever-growing menu of choices. It is not easy to parse these offerings. The competing claims can be attractive and bewildering at the same time. How should we sort through them to arrive at the best path to solving our complex problems? We will try here to outline the framework for making a choice from among the solution paths.
Unsurprisingly, the process begins with an examination of our requirements. What do we need from the solution method/tool? That can be answered by assessing the outcome we desire. The method and tool must yield a solution that considers the “scale, interdependency, and complexity” of the problem and that produces a solution that addresses them in a comprehensive way. What will we need to accomplish that?
First, we will need a way to deal with the problem and solution that does not rely on a construct (or series of constructs) that reside only in the mind or minds of the designers. The human brain can only hold so much detail in working memory. Relying on our own brain physiology limits the granularity and scale of the analysis that can take place without the assistance of a tool. To augment that problem-solving platform, our solutions must provide assistance in a number of ways.
1. Make a Model
Any problem-solving tool should help us by allowing us to make a model to manage the complexity of the problem and its possible solutions. The tool needs to be able to reflect changes and track them as the process of solution-seeking advances. The model constructed in the tool should reflect everything of relevance to our solution-seeking. That means that it must be complete and it must maintain internal consistency. A good tool will not shift the burden for assuring completeness and consistency to the manual processes of the designers. The model embodied in it will be complete and consistent throughout its life. Anything less should be unacceptable.
2. Demand Real Integration
Completeness and consistency rest on real integration. It is not enough to create lists of requirements or functions or components. These and all the other entities must be linked together in the model according to their characteristics and relationships to each other. After all, it is the relationships and interconnections that drive both complexity and emergence. Trying to manage the information in multiple tools or models (e.g., a “requirements model” or a “physical model”) breaks the integration and thrusts the burden for linking the information back onto the designers. Any insights that could be gained from the integration are forfeited.
3. Fidelity
The model must represent all of the relevant reality of the problem and candidate solutions. That means that it must be capable of capturing the data that represent them. George E. P. Box famously said, “Remember, all models are wrong, but some are useful.” He elaborated by explaining, “The practical question is how wrong do they have to be to not be useful.”[1] That is the essential issue here. The model must be capable of representing the problem and solutions in all their complexity or it is not useful. This need is reflected in the move toward digital thread, digital twin and digital engineering. The digital model must provide the necessary thread(s) from one lifecycle stage to another, making it the “digital twin” of the underlying reality. Only then can it be truly useful to the system design.
4. Avoid Limitations
There are two inadequate types of solutions being pushed as viable alternatives that actually contain limitations that significantly hamper their usefulness. The first type touts a “simplified (simplistic)” modeling language. This is most often offered in the name of accessibility. The argument runs that the simpler the language, the more easily it can be learned and used. The problem is that the simplification of the language impairs its ability to adequately express the necessary nuance and complexity. This pushes the model into Box’s “not useful” category.
The second type advocates a truncated set of representations. This supposedly offers better communication among designers and stakeholders by “standardizing” their communication on the limited set of views. The problem is that this ignores a central characteristic of the systems engineering world. As we said above, systems problems are becoming increasingly complex. This is accompanied by the integral involvement of multiple disciplines. The INCOSE definition of systems engineering itself recognizes this. “Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems.”[2]
By standardizing communication of the design on a limited set of representations, the communication itself becomes limited to those who use and resonate with the standard. So, for example, when systems engineers are encouraged to standardize their representations on a Unified Modeling Language-based set, the disciplines outside the confines of software development are excluded or forced to learn a “foreign” (software) language. Rather than enhancing communication, this kind of “standard” hinders it. The preferred solution should include the representations for those who resonate with them but as part of a larger, more robust set that enables a broader reach to stakeholders and design/engineering disciplines outside the putative standard.
5. Trace Requirements
Perhaps the most important requirement for a design tool/method is the ability to trace requirements through to the system solution design and trace the design back to the requirements. This bi-directional traceability should be established in and managed by a truly robust tool. That happens by instantiating the solution design in a single database residing in a single repository. If different repositories (tools) and databases are used, a significant risk is created because the gaps between the databases/tools break the traceability. This recasts the burden of maintaining and checking the traceability onto the design engineer’s manual processes, defeating the purpose of the tool.
Once the model is created in the repository, it can be maintained across the life of the system. Changes in requirements or system design can be updated as the system ages. This allows the designers/owners to maintain traceability throughout the system’s life.
Conclusion
The primary requirement for an effective design tool/method is that the tool provide the leverage for holding a complex problem and its possible solutions in the complete form necessary to manage the complexity. The design team should demand that the tool assume the burden for completeness and consistency, relieving the team from the manual responsibility for instantiating, updating and checking the design. The tool should be capable of robust communication across the disciplines that contribute to the design and comprise the system stakeholders. Accepting segmentation of the model or the oversimplification of the way of building and communicating it seriously impairs the ability of a design tool/method to effectively meet the requirement for an effective design solution.
[1] George E. P. Box and Norman R. Draper, Empirical Model Building and Response Surfaces (John Wiley & Sons, 1987).
[2] Systems Engineering Handbook, (INCOSE, 2015), 261.
