Last time, we covered the first three of our nine laws of effective systems engineering. Law #1 – Begin with the End in Mind; Law #2 – It Doesn’t Help to Solve the Wrong Problem; and Law #3 – Insight Is the Goal. Today we encounter the next three:
Law #4 – The Model Is the Main Thing
Law #5 – To Catch (Design) a System You Have to Think Like One
Law #6 – It’s All about Relationships
Law #4 – The Model Is the Main Thing
At one level this is obvious—engineering classically uses models to understand, analyze, and ultimately address the challenges we face. However, what seems obvious holds a key truth. Proper use of model-based approaches unlocks the power of systems engineering. The model itself becomes the focus, not the documents describing the model. The old, document-based approach was to capture the system specification in a set of documents and then extract their contents for the purpose of implementing the system solution. In a model-based design, the documentation is generated from the model and reflects the model itself. The model itself is the system specification.
In systems engineering as it is most often classically practiced, we hear of a set of views referred to as a system model. But specifications and views are not a model. Documents satisfy specific—and valuable—viewpoints in the design, but by definition are limited in scope to address a particular need. So whether it is a DoDAF viewpoint, a SysML diagram, or a functional flow block diagram, the view is a presentation of a specified subset of information about the underlying design presented in accordance with the rules for constructing the view. It does not become the model—even in combination with other views. The model is the set of entities, relationships, and attributes that contain the complete design of the system solution. The documents or views flow from the model rather than the model flowing from the documents.
Ultimately, the model is a tool for understanding the problem and reasoning through the solution space. For example, the model provides a reasonable context for trade studies. We can use the model to test and compare alternative functional allocations. Where the model used is one which has been constructed with the rigor and discipline of the principles of model-based systems engineering, these studies and comparisons can be made within the context of the system requirements.
The model allows us to integrate the design into a unitary whole. The model can be seen, measured and executed as a whole. This leads to a high level of confidence in the design. A single, integrated model of the systems solution is the heart and soul of effective systems engineering. It is easy to be led astray into thinking that a set of documents and diagrams are the model. The more robust and useful the set, the easier it is to be deceived. But, in doing real model-based systems engineering, we must focus on the model and not the representations.
Law #5 – To Catch (Design) a System, You Have to Think Like One
Our Western education classically teaches us to analyze or deconstruct the subject of our investigations. We seek to understand any whole by understanding the operation of its parts. But this analytic thinking is not enough. We need to engage in synthetic thinking as well. The distinguishing characteristic of a system is that the system is more than the sum of its parts. Therefore, we must synthesize our thinking at the system level. Systems thinking for true understanding involves synthetic as well as analytic thinking.
One of the dangers of using analytic thinking alone is that it can lead us away from the view of the system as a whole into thinking about the system in “stovepipes.” For example, many systems engineers tend to divide their thinking into the separate systems engineering domains.
The loss of this vision resulting from this fragmentation can also remove the context for the elements of the system. This is often referred to as component engineering. Components are developed in isolation from one another and then cobbled together to form a system. This means that the synergistic results which are the point of the system design are either lost or badly compromised.
As the advertising slogan (“Pay me now or pay me later”) reminds us, there are critical functions in life that cannot be avoided. Systems engineering from a systems perspective is one of those. Skipping the systems thinking up front does not mean saving that effort—it simply means saving that effort for later, often at integration and test, when it is far more problematic. Ultimately, retrofitting and rework are an extremely costly way to do the integration work of systems engineering, to say nothing of the costs involved in accepting degraded performance because it is too late or too expensive to make the changes necessary for integration.
As Jim Long regularly reminded us, “The amount of systems engineering required for a given project is fixed. You don’t get to choose how much SE you do. You simply get to choose when you do it.” Jim was reminding us that we need to think in systems from the outset and use that thinking to do systems engineering throughout our problem solving process.
Law #6 – It’s All about Relationships
When we talk about systems, it’s all about interactions and interrelationships. We’re focused not upon the performance and characteristics of the independent pieces, but the performance and characteristics of the whole. It’s about interfaces and links as much as it’s about individual components and parts.
Likewise, systems engineering is all about the relationships. All of the entities that make up a system are webbed together into the model through relationships that define their place in the system. These relationships (together with modeling constructs to capture key additional aspects) are what transform a collection of entities into a traceable, executable model.
The relationships are themselves organized into a metamodel. Done well, this metamodel not only forms a framework for capturing the system representation, but it also provides a framework for thinking about the problem and its potential solutions. At its simplest level, the basic or foundational framework can be simply expressed as, “Requirements are the basis of behavior, and behavior is allocated to components.” Likewise, “Components perform behavior, and behavior is based on requirements.” This bidirectional set of relationships is the foundation of any model. Instantiated into a database, the metamodel is called a schema.
This basic schema is expanded to deal with the complexity of real world problems and solutions. But even in expanded form there is always the foundational simplicity among the elements of A relating to B and B relating back to A. Every relationship has two ways of expression that manage the two sides to the relationship. In actually constructing a model, there are many more expressions of these relationships which allow us to construct models for particular solutions. For example, a behavior may be “decomposed by” another behavior. It may be “triggered by” an item. The relationships running in the other direction for these are that of the behavior that “decomposes” the other and the behavior that “triggers” it. These expressions allow for the construction of a much more nuanced and richer model of the system solution.
This is the basis of the richness of relationships and the multiplicity of linkages they form. The relationships produce the characteristics and behaviors that make the system valuable to us. Reflecting back to insight, the relationships and the underlying metamodel provide the framework for our reasoning. The fundamental metamodel should be as simple as possible to support the required level of analysis and reasoning, no simpler. Moving beyond the foundational concepts above, a more complete schema connecting the operational and system domains is shown below. This shows the power and richness of a fully formed metamodel in which the system designed is housed.
A model built around this framework is robust and truly useful in creating the system design.
Conclusion
From these three laws we learn some central truths about systems engineering. It is the systems that are at the heart of our problems and solutions. We must think in those terms first and maintain that perspective throughout our design solution process. Since solutions derive their characteristics and behaviors from the relationships among and between their elements, we must see and think about relationships in order to understand the systems.
Scott,
I am appreciative of your discussion in Law #4, particularly in that this is the first time I have heard anyone correct the previously loosely-used description of the model as just what you said it is not: “So whether it is a DoDAF viewpoint, a SysML diagram, or a functional flow block diagram, the view is a presentation of a specified subset of information about the underlying design presented in accordance with the rules for constructing the view. It does not become the model—even in combination with other views. The model is the set of entities, relationships, and attributes that contain the complete design of the system solution. The documents or views flow from the model rather than the model flowing from the documents.”
However, in your version, where you describe the model as the set of entities, relationships, and attributes that contain the complete design of the system solution, I see a quandary where time/order of events are considered. Am I misreading or are you offering that the model doesn’t/can’t exist until it is a complete representation of the system? Somewhere along the way we must work iteratively on the model and it is in these less than complete stages, where I believe the community has taken to calling the combination of existing documentation and views, such as they are, the model. Can you please expound on this thought?
Dale- Good comment! In our methodology, we work with a layered approach. Beginning at a high level where the system is a “gray box,” we move layer by layer by increasing the granularity of the model at each successive layer. This is in contrast to attempting to develop some sector completely, then another and then hooking them together. Along the way each layer is complete and so, for our method, the model exists to that level of granularity. But the contrast between model and document/representation/view (you are exactly right to speak of documentation and views together- a document describing the model is equivalent to a picture for the purpose of this point) is that, at whatever stage of granularity or detail the model exists at a given point, the picture is exactly that- a picture of the reality that is the model.