Commonwealth: May it please the Court, ladies and gentlemen of the jury.
The defendant in this case, Commonwealth v. Systems Engineer, stands charged with the modelslaughter of the system model. The deceased model in this case is not an ancillary or limited representation of some aspect of the system, but the descriptive architectural model depicting the entire system. While the defendant faces many counts of this offense spanning his career, the conduct alleged is the same in each instance—recklessly employing a variety of models resulting in the demise of the one model that could bring insight to the systems design process, the systems model.
The law defines involuntary manslaughter as occurring when one person, while committing an unlawful or reckless act, unintentionally kills another. The distinction between murder and manslaughter is the absence of malice. The distinction between voluntary and involuntary manslaughter is the absence of intent. The acts alleged in this article are reckless but are not malicious nor are they intended to result in the death of the system model. Therefore, the crime charged is manslaughter (or, more exactly, modelslaughter) of the involuntary type.
The first element of the crime to be proved here is that the system model is dead. You have heard the testimony of the Commonwealth’s expert, the eminent organizational theorist and systems thinker Russell Ackoff, who said about systems, “A system is more than the sum of its parts; it is an indivisible whole. It loses its essential properties when it is taken apart.”
The Commonwealth also introduced you to George E.P. Box, the statistician and University of Wisconsin professor who told us to “Remember that all models are wrong,” but cautioned us that “. . . the practical question is how wrong do they have to be to not be useful.” The argument advanced here is that, when a model becomes so wrong it is no longer useful, it is essentially dead.
The first question that you must confront is then, “What makes a system model useful?” We know that models are limited representations of a reality. Those representations have a purpose or purposes behind their creation. The purpose that drives the creation of a systems model is to provide an understanding of how the system behaves or will behave. That understanding is the key to evaluating the likely success or failure of the system, constructed as modeled, against the requirements created by the problem to be solved.
Dr. Ackoff was clear in his testimony that, “The systems approach to problems focuses on systems taken as a whole, not on their parts taken separately. Such an approach is concerned with total system performance even when a change in only one or a few of its parts is contemplated because there are some properties of systems that can only be treated adequately from a holistic point of view. These properties derive from the relationship between parts of systems: how the parts interact and fit together.”
As was made clear by another Commonwealth witness, the physicist/biologist Fritjof Capra, “According to the systems view, the essential properties of a . . . system, are properties of the whole, which none of the parts have. They arise from the interactions and relationships among the parts. These properties are destroyed when the system is dissected, either physically or theoretically, into isolated elements. Although we can discern individual parts in any system, these parts are not isolated, and the nature of the whole is always different from the mere sum of its parts.”
So, anything which fragments the model into isolated elements deprives the model of its usefulness, effectively killing it. We can no longer use it to gain understanding because, as Dr. Ackoff put it, “Understanding proceeds from the whole to its parts, not from the parts to the whole as knowledge does.” Without the ability to create understanding, the model is dead.
It is the Commonwealth’s burden to show how that death occurred and how the defendant’s conduct caused its death. As we have seen, the death occurred at the point of its loss of usefulness. The ability to provide an understanding of the likely success or failure of the system, constructed as modeled, against the requirements created by the problem to be solved is the sine qua non of usefulness. This ability to represent the system as a whole comes from the systems metamodel used to construct the model.
The systems metamodel provides the framework for the model that describes the system. Just as the human body receives its life’s blood from the structure of the circulatory system, the system model receives its meaning from the metamodel on which it is constructed. If the model is constructed in ways which fragment the connections embedded in the metamodel and isolate the system elements from each other, the metamodel is damaged and cannot transmit the meaning needed to develop the required understanding of the system being modeled.
Below is a simplified depiction of the metamodel in a healthy system model. (Commonwealth Exhibit 1.) Note that the elements are connected to each other through relationships. Requirements are the basis of behavior, behavior is allocated to components, components perform behavior, and behavior is based on requirements. This creates meaning which can be transmitted through verification and validation running throughout. Just as blood circulates through the human body, meaning circulates through the healthy model via a robust metamodel.
Commonwealth Exhibit 1 – A Healthy Metamodel
In this case, consider the state of the deceased as pictured in Commonwealth Exhibit 2, below. Pay particular attention to the severed relationships. These act to destroy the model’s ability to convey meaning throughout the whole by severing the pathways as surely as a knife plunged into the aorta of a human victim destroys the ability of the victim’s body to circulate the blood on which life depends.
Commonwealth Exhibit 2 – The Deceased’s Metamodel
These fragmenting wounds drained the model of meaning just as Dr. Ackoff and Dr. Capra described. Deprived of its usefulness, the model was simply wrong. Having lost its ability to fulfill its purpose, it died of its wounds.
The remaining issue is to identify the conduct of the defendant which caused those wounds and led to the model’s death. There is no allegation here that the defendant bore the model any malice. Nor does the evidence show any intention on the part of the defendant to cause the model’s death. Therefore, the charge is modelslaughter of an involuntary nature.
The defendant, somewhat proudly, admits to using multiple domain-specific tools to construct the deceased system model. Specifically, the defendant used Requirements Generator, a requirements tool, and Component Pro, an architecture tool. The defendant used no behavior tool at all, choosing to ignore that domain and tie the requirements to components directly, albeit mentally without modeling those relationships.
This process created breaks in the unmodeled relationships. Imagine a row of silos with no connections between them. Even looking at all three silos in the aggregate, there is no picture of their interaction in that view. Without such a view there can be no understanding of the system being modeled, and the system being modeled died of its fragmentation injuries.
Therefore, the Commonwealth submits that the conduct of the defendant in creating the model fragmentation led to the death of the system model. This behavior by the defendant is not an isolated incident but amounts to a course of conduct. The defendant has persisted in it throughout the course of this trial and has expressed an intention to continue with it.
This persistence exists despite the common availability of the knowledge of systems as exemplified in the work of the Commonwealth’s experts and many others.
It exists despite the availability of robust system metamodels with a proven track record of success dating back to the late 1960s. It exists despite systems engineering tools like CORE and GENESYS from Vitech, which are built on the foundation of a proven metamodel from which we can develop an integrated descriptive systems model captured in a single repository to provide the authoritative source of truth for the modeling process.
The defendant’s disregard of these tools and the surrounding knowledge coupled with the intention to continue in this course demonstrate the recklessness required by the statute for conviction.
Therefore, the Commonwealth asks that you return a verdict of guilty in this case. Thank you for your service.
(Author’s note: The foregoing transcript of the closing argument was offered in the hope of raising the issues covered and thereby stem the needless slaughter of precious system models.)
I like the points made and its depressing to be reminded that people are still working this way. For me the analogy isn’t right though. I would say the model was never alive; inanimate would be the word. Consequently I would consider a Frankenstein analogy as apt: we’ve put the bits together but we can’t make the whole thing ‘live’.
The level associated with the illustration is one that so many business models never get beyond. Commonly there are several functional blocks all inter-communicating, but the process and data flow – the behaviour – has not been thought about or modelled.
You are right, of course. The metaphor here is targeted at the central idea and doesn’t rise to the level of analogy with its 1 to 1 correspondence character. You Frankenstein idea is a really good one.
It never fails to surprise me how many practitioners simply allocate requirements to components without a thought to behavior. We have even had experienced engineers tell us that.
Thanks for commenting!
Well done! Concise, coherent, memorable (or is it today now: memerable?). I particularly liked the use of “unmodelled relationships” to contrast the anemic approach of “SE using models” with ones that use integrated MBSE tools.
Thank you sir! I like the nod to metaphors as memes.