What makes systems thinking different from classical systems engineering? Classical systems engineering ignores everything, but direct inputs and outputs to the system of interest. Classical systems engineering even ignores loops outside the system that might cause changes in inputs to the system. Classical systems engineering usually attacks the problem through a process of decomposition. Decomposition can be dangerous in that you may miss holistic effects, but like all engineering it works (mostly). The problem is as we decompose and classify information about the system we often lose the connections between components. While systems thinking allows us to look at the big picture to see how things outside the system may influence each other and subsequently influence the system.
So, how can we be sure we are looking at the big picture? It’s important that we take a step back and look at how the external systems interact (outside influences). Identify potential feedback loops that may ultimately affect the inputs to or outputs from the system. Make sure to look for natural cycles. Many different techniques have been developed to look at the big picture, such as mind maps, systems thinking diagrams or casual loop diagram, and the operational context diagram.
Mind Maps start with a title of subject then expand or subdivide topics. This technique can be much like decomposition, but you usually can see the big picture this way. Look for links between the decomposed elements.
Systems thinking diagrams identify elements and influences along with the direction and indicator of type of influence (positive or negative). It begins to get an impact between elements.
The Operational Context Diagram describes the scope of the architecture. It defines the key interfaces in between external systems as well as the interfaces between the external systems and the system under development. This diagram provides a means to instill dramatic changes in the architecture, enabling transformation from the “As-Is” to the “To-Be.”
What does MBSE have that supports systems thinking? MBSE enables users to capture elements (entities), their relationships and attributes in a database that can be queried. Various visualizations of this database information enable analysts to see the big picture, drill down into it, and maintain the relationships between elements. To accomplish this information capture, we need a “language” or data base schema to classify the information into “entities” and relate those entities to each other.
The Lifecycle Modeling Language (LML) is a new open standard that was designed explicitly to support MBSE through the lifecycle, including the program management aspects. It consists of an ontology and a two key diagrams: Asset Diagram and Action Diagram. The Asset Diagram is simple allowing for logical connections between Assets. Asset diagrams enable modeling systems thinking diagrams, as well as entity-relationship-attribute diagrams. The LML Action Diagram captures decisions and feedback loops. Action diagram provide ability to model processes, including feedback loops, as well as capture decision points. Right now, LML is only implemented in Innoslate. We can use the Asset, Action, Hierarchy, and Spider diagrams in Innoslate to visualize the operational context, mind maps, and systems thinking diagrams.
Systems thinking is the way we should always have done systems engineering. Always consider feedback loops, outside influences, and natural cycles when using the systems thinking approach. MBSE provides a way to capture the pieces of the system and keep them properly related to each other. LML provides a simplified schema and diagrams to facilitate systems thinking. MBSE tools enable rapid visualization, analysis and the capability to keep up with changes. By addressing the entire picture, including outside influences, we can move to more visionary and effective solutions.