Willie Nelson getting ready to perform. Farm Aid 2009. Photo by Larry Philpot
www.soundstagephotography.com
On April 29 Willie had a birthday. “Maybe I didn’t love you- Quite as often as I could have” sings the just turned 80 year old legend, Willie Nelson, in his classic “You Were Always on My Mind.” Nelson assures the subject of his lyric that although he may not have acted like it, she was ever present in his mental processes.
This could be the song of many systems engineers when it comes to system models. Although they would not endorse (and might even deny) the practice of “model-based systems engineering”, it really is not possible to think “systems” without using some form of model. This model might very well exist unacknowledged in the mind of the engineer but where there is a concept of a system, there is a model.
The difference between a traditional document-centric systems engineer and the model-based systems engineering practitioner is not that the latter uses a model and the former does not. Both of them rely on a system model. Often they are divided, in that the latter acknowledges it, while the former does not.
For this traditional engineer, the challenge of moving to model-based systems engineering is the challenge of formally acknowledging the existence of the model. Once the model is acknowledged, it can then be considered in a form in which it can be utilized as the centerpiece of the design.
Sometimes the traditional systems engineer will acknowledge the existence of a model but claim that it resides in the documentary manifestations created during the design process. Drawings, tables, and specifications are identified as the system model for this engineer.
This position is arguably more tenuous than the outright denial of a model. While acknowledging that the system model exists, this practitioner misperceives its location. In terms of changing behavior it may actually be easier to convince the denier that a model actually exists than it would be to disabuse this engineer of her misapprehensions concerning its location.
We read a great deal in the literature about the difficulty of changing individual and organizational thinking with regard to the adoption of model-based systems engineering. This shift in thinking is most often seen as convincing engineers to use a model in designing their system. This formulation contains a subtle misperception.
The shift in thinking does not involve adopting a model approach where none currently exists. A model is already being used – even if it is unacknowledged or misperceived. The shift in thinking here actually involves overtly acknowledging the model and dealing with it in an intentional and disciplined way. It means moving from using an unintentional and undisciplined model to using an intentionally created model in a disciplined way.
The process consists of bringing the model out of the thought processes of the engineer and instantiating it in a tool that will allow the engineer to view and manipulate it in an intentional way. In practical terms, it generally means using a computer to capture, preserve, and maintain the model that currently resides in the head of the engineer. The shift in thinking, therefore, centers on how we deal with our systems model rather than on whether or not that model exists.
This sheds light on why it can be more difficult to move an engineer from a document-centric approach to model-based systems engineering than it would be to convince a design engineer with no systems approach to adopt model-based systems engineering outright. Seeing that the documents are simply representations of a model that resides in the head of the engineer can be more difficult than seeing that having a model of the system design would be helpful.
The paradigm shift from no belief to orthodoxy (right belief) is in many cases easier than the shift to orthopraxy (right practice). In other words it is often easier to convince someone what we need to do (use a system design model) than it is to convince someone how to do it.
There are very significant gains to be had from bringing the model out of the unconscious background into the intentional process and from instantiating the intentional model in a tool that will maintain all of the aspects of the model and generate the documentary evidence of those aspects from the current state of the model itself. These gains are related, but it is important to see that these are two separate undertakings.
By using an intentionally created model instantiated in a tool capable of creating and maintaining all the aspects of its design, we can expect to experience a number of benefits:
- The design engineer’s mind is now free from the burden of maintaining and updating the system model as design advances are made. This is done by the tool freeing the mind of the engineer to focus on advancing the design.
- The ramifications of any change in the system design can be clearly seen in real time as they are made. Since changes are made to the model rather than to particular representations of the model, the changes flow outward into the representations. This means that as a change is made in the model, the relationships of the entities making up that model reveal the impacts of the change across the system design. The tool allows this to happen without the design engineer having to think through each particular ramification of the design change.
- Because the model reflects and reports the changes in design, unintended consequences of design decisions are almost entirely avoided. When a change is made, the design engineer can quickly see what the implications of the change are.
In short, the intentional use of an intentionally created model of our system design will make us more effective and more efficient. It helps to arrive at a better solution while minimizing our risk. It frees the design engineer to design and create rather than serve as the inefficient (and risky) repository of design minutia. We can do well what we have always known we need to do. As Willie sings, “you were always on my mind . . . “
