Recently a LinkedIn MBSE group post posed a fundamental question, “How can we move organizations from a document-centric approach to model-based systems engineering?” This raises a very basic inquiry into the ways to advocate the model-based systems engineering value proposition.
There are two questions implied in this inquiry. The first concerns the issue of change management. Any change automatically meets with resistance. There is an inertia around the status quo. This should come as no surprise to anyone. Introducing model-based systems engineering into a document-centric environment is no exception. Anyone seeking to do this will be faced with using all the change management techniques that can be mustered to overcome the resistance to change.
It is, however, the second implied question that we deal with here. What exactly is the value proposition for model-based systems engineering and how should it be positioned to appeal to the organization?
In the document-centric world each document stands alone. The idea is that the documents add up to a system description in the aggregate. But there are several traps embedded in this approach.
First, this guarantees that any change in this system design/description has to be propagated across all the documents. This means that advancing the design is slowed by the need for manual consistency work with every change followed by a ripple of checking and modifying the documents. That adds time and drags down responsiveness.
With the MBSE model all the elements of the system are held in relationship to each other. The documents flow from the model as structured answers to particular queries of the model. When changes are made to the model they are then reflected into these answers (documents) and can be seen “real time.” The change is reflected across the model and into the documents and the engineers can move on to the next change. All the documents stay up to date all the time.
The value of this ability to skip the consistency checking and updating every single change is easily understood by any organization because it represents a real savings in effort and an increase in quality.
In addition, with the right tool changes can be made through the document into the model. This means that altering something in a behavior diagram actually changes the underlying model relationships accordingly. Querying the model for a new document will result in an answer that reflects the change. The tool provides an underlying database model that does not require direct work by a database manager but can be updated through the documents or views. That means engineers can be freed from database management chores and allowed to function as engineers.
These two value propositions are powerful levers in helping project and program managers to understand the value of MBSE, especially MBSE in the context of a powerful tool. No more reworking the documentation and worrying about consistency. With MBSE the model takes care of those concerns and produces current documentation in response to point in time queries.
