Last Updated on October 8, 2021

Table of Contents

• Complex Systems Sciences as a Foundationfor Systems Engineers
• Systems Engineering Principles for Complex Systems
• The Integrated Systems and Software Engineering Process (ISSEP)

Most contemporary writings about Complexity will, at some point or another let you know how “hard” systems engineering methods are not good enough for dealing with complex systems and how rigid “command and control” hierarchical structures are “inhumane” and inappropriate when dealing with social systems. This post, is my attempt to dispel some of these unfounded rumours. I’ll start with a review of a paper from the doyenne of Systems Engineering, Sarah A. Sheard:

Complex Systems Sciences as a Foundation
for Systems Engineers

Dr. Sheard takes an utilitarian approach to investigating the relationship between Complexity Theory and Systems engineering. She proposes that:

there is an advantage to bringing together the sciences related to complexity and systems engineering so that the research results can provide lessons to help both with the systems being engineered and the environment in which they are being created. In addition, the systems engineering environment can help guide research into new areas, perhaps challenging validation of common systems engineering heuristics.

A title of a chapter in the paper is “Complexity Theory, aka Complex Systems”, so it might obvious that for Dr Sheard complexity is not created “ab nihilo” but from the operation of a complex system. WR Ashby defines “system” as “a set of variables selected by an observer“. This two assumptions combined mean that the complexity of a system may not depend exclusively on the properties of the object or phenomenon under scrutiny, or what Ashby would call “the machine”, but also from how the observer selects the variables that will go to define the system. So, in a way, complexity is also in the “eyes of the beholder” (the observer).

If this is true, than, by identifying and learning about the system that supports it, it might be possible to understand complexity better and maybe find better ways to deal with.

In this paper Dr Sheard touches all the familiar CT topics: non-linearity and the inadequacy of the Newtonian worldview, edge of chaos, scale free networks, for which, as any decent engineer would do, she quickly identifies some security vulnerabilities …

Although the topics discussed in this paper might be the same as in other CT papers, it is refreshing to find out that “something can be done” about (or with) Complexity, instead of the resigned attitude that “we are not in control” and “catastrophes are unavoidable” I feel permeating from most contemporary papers about Complexity.

Dr Sheard sees Complexity as something that has to be embraced, learned from, understood as much as possible, and the resulting knowledge used to make better policy and design decisions. Many complexity “theorists” instead suggest that given we can’t have complete control over complex systems we abandon any attempt of trying to control complexity and just “dance with it” as many usually misinterpret the words from another systems thinker Donella H. Meadows in her book “Thinking in Systems“.

For Dr Meadows “dancing” does not mean just “letting go” to the “beat of the system“, it means that in dealing with systems we have to forget (let go) other “learned” beats and “before disturbing the system in any way, watch how it behaves.”

She says:

Magical leverage points are not easily accessible, even if we know where they are and which direction to push on them. There are no cheap tickets to mastery. You have to work hard at it, whether that means rigorously analyzing a system or rigorously casting off your own paradigms and throwing yourself into the humility of not-knowing. In the end, it seems that mastery has less to do with pushing leverage points than it does with strategically, profoundly, madly, letting go and dancing with the system.

Systems Engineering Principles for Complex Systems

In another paper on the same subject “Principles of Complex Systems for Systems Engineering” written by S. Sheard in collaboration with A. Mostashari they state:

Complex systems as a field of study is rife with “overloaded” vocabulary. Words like enterprise and architecture are given new meanings as understanding and
technology evolve, and each new meaning develops a following.

The Integrated Systems and Software Engineering Process (ISSEP)

The Software Productivity Consortium (SPC) published in May of 1996 a technical report called “Integrated Systems and Software Engineering Process” (ISSEP). The purpose was the “improvement of the overall systems development process allowing systems and software engineers to more efficiently perform their work“. Not sure what happened with the ISSEP model (or the whole SPC for that matter) but I found this description of an implementation of the model in a paper published in 1999.

The reason I’m resurrecting this model 25 years after its origin, is to show how the rising preoccupation of the “systems thinking” community with “systems of systems” and discussion of how to deal with an “increased complexity” in modern days systems is nothing new and provide an example of how people were always more or less successfully dealing with complex systems in the past.

My contention is that complexity today has not increased from what it was 25 years ago or even earlier. Complexity is, and always was in the “eyes of the observer” and its increase can be found in the tendency of observers to take control over more variety than they are physically able to deal with. I see the reason for such a trend in the ever more sophisticated tools available to us, providing continuous “avalanches” of data in the form of electronically delivered news, tweets, instant messages, videos, e-mails, etc.

We want to be “informed” and “know everything”, which is just one step from wanting to “control everything”. Of course, the limit of our direct “absorption and control” capabilities is much lower than the amount of data these tools can provide us with, so we end up feeling inadequate and overwhelmed by the “increased complexity” of the world around us.

Hierarchy is the preferred tool observers use to manage complexity. Hierarchies (usually represented as inverse “trees” or “roots”) are naturally built from the “bottom up”, by things spontaneously gravitating to one another and grouping (classifying) using some appropriate criteria (function, location) in communities and increasing the level of abstraction for each higher level in such hierarchy. The human body or a society is an example for such a hierarchy.

Observers, however, most often build a hierarchy from the “top down” by breaking bigger items (problems) in more manageable chunks that can be distributed to teams to work on. These are often identified as a command and control hierarchy, where a number of elements from a lower level “report” to just one entity at the next higher level which also “control” all of the reporting entities.

A hierarchy is sometimes also represented as a “nested” structure similar to a “Russian doll”. The ISEEP framework was represented with such a structure. Below I provide a short video made from a Power Point presentation created more than 20 years ago while analyzing this model to see how it maps to the Integrated Product and Process Developmet System of the company I was working for.

Now, finally, the real reason for this lengthy introduction.

One of the stated purposes for the ISSEP model was also managing the complexity associated with the development of multi-million sophisticated products (most often in the aerospace and military complex).

The model listed two mechanisms for managing complexity:

1. Segregation of development processes on multiple levels of abstraction
2. Communication mechanisms that push the “flow of information” within and between levels

The chapter from the ISSEP technical report (see link above) detailing the use of these two tools is given below. It is divided in parts for clarity and the colour emphasis is mine:

6.3 MANAGING COMPLEXITY

There are two ways that the ISSEP model manages complexity. First, the appropriate levels of abstraction for the development of each system part are defined. Second, realistic communication mechanisms that reduce the effects of fragmented development are defined.

Level of Abstraction. This report describes how the ISSEP model is decomposed to mirror the decomposition of the developing system. However, if the highest level processes had to “solve the entire problem” in detail in order to control the lower level activities, the problem would still be complex, and the benefits of the decomposition would not be realized. Rather, in the ISSEP model, the system parts at each level define the system at an appropriate level of abstraction depending on their level in the hierarchy. That is, the higher level activities develop designs and plans at a high level and lower level activities develop designs and plans in more detail. By allowing each level to remain focused within their level of abstraction, the job of dealing with the complexity of the entire system is distributed among all the parts. This is an effective way of managing complexity if communications mechanisms are in place to transfer information.

This paragraph clearly shows that using a “command and control” hierarchy for dealing with complexity might not be as bad as contemporary complexity science would like you to believe. If properly used, such an organization will absorb most of the complexity at the “lowest” level by a large number of elements (regulators) that are in direct contact with their environment (the problem). These elements will keep system variables they are responsible for within levels and limits provided from the control level “above”. Over reporting and micromanaging in such a structure would defeat the purpose because by doing that, variety will for sure “seep through”. Intervention from a higher level “controller” is necessary only when the “regulators” under their jurisdiction run into difficulties, because of changes in the environment, or there are some new directions to be taken as defined at the highest (“governor”) level, so the “controller” has to re-align the “regulators” to maintain a smooth operation.

The last few paragraphs delineate why a push communication mechanism as the one used in ISSEP may be more effective than a pull:

Communication Mechanisms. The ISSEP model defines communication mechanisms that promote the flow of information. This means that information defined by the model is routinely communicated. For example, any risks identified by the design activity are transferred to the management activity for further analysis. The management activity does not have to request the design activity to transfer the risks. On the other hand, in process models, where communication mechanisms do not promote the flow of information, information must be actively requested before it is available. The ISSEP model’s communication mechanisms promote information exchange throughout the system hierarchy. The information exchange mechanism helps manage complexity because it reduces the impact of fragmentation caused by the distributed development.

The ISSEP communication mechanisms also encourage all participants in the development to take a proactive role in the successful completion of the system. The more knowledgeable the participants are of the development effort, the more likely they are to feel a part of a team effort, and the more likely they are to find and resolve defects. The psychological factors of a strong team, empowered with knowledge, working together to produce a complex system, cannot be overlooked. The ISSEP communication mechanisms provide the foundation for this approach which, if implemented, can make a very large team work as effectively as a small one.

Of course the system must have a clear understanding of what the communication rules are in order to avoid for unnecessary information to take up communication bandwidth in both inter- and intra-level channels. As a rule of thumb, only unexpected events and states are reported. If all variables are within the “limits of survival” a periodical broadcast of “ping” is all it is necessary.

The point to take home from this short presentation is this: Segregation of different functions in a multilevel hierarchy may be a powerful tool for managing complexity, but only if matched with a communication strategy that promotes the “push” of information within the system. Elements (“subsystems“) from different levels will perform their assigned function autonomously and at the same time broadcast their state with the expectation that elements from a higher level will intervene to aid with any problem they are not able to fix by themselves.

It is obvious that by this, the whole “command and control” hierarchy, as it is normally understood, is turned “upside down” because in the structure described above, the elements of the system at the next higher levels are intervening only when elements from the lower level are unable to perform their intended function. It can be said then that, in such a structure, the higher level of control is in the service of the lower one.

Views: 3