If you hang around those applying model-based systems engineering (MBSE) long enough, you will eventually hear a passionate debate regarding whether a document is a model. For the general public, this sounds about as compelling as the question “is it system engineering (singular) or systems engineering (plural)?” While both may be good questions for that systems engineering dinner party you are planning, there is some value in the question of whether or not a document is a model … if you look beyond the surface.
When asking this question, we must first begin with the definition of model. “Model” is a noun defined as:
•Graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world (www.businessdictionary.com)
•A representation of a system that allows for investigation of the properties of the system and, in some cases, prediction of future outcomes (www.investorwords.com)
•A physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process (from DoD 5000.59-M, 1998)
Clearly, by all three definitions, a document qualifies as a model. It is a reduced textual representation that allows for communication and understanding. Case closed, debate ended … or is it?
Stopping the discussion here ignores the greater context of the transformation from document-centric to model-centric practices, the fundamental foundation of model-based systems engineering. If in this context we accept documents as models, wouldn’t that imply that document-centric practices are model-based? If so, there is nothing behind this transition that has largely dominated conferences and discussion in systems engineering over the last nine years.
While those arguing based upon basic definitions are correct that documents are models, documents are not models in the context of MBSE. As noted in the discussion of 4 Myths and Misconceptions of MBSE, the transition to MBSE does not mean models are new. Instead, it’s a change in centricity – one in which implicit models are made explicit, secondary models becomes primary, and descriptive models are now required. Central to that change is the movement from low-fidelity representations of systems (documents or specifications) to high-fidelity representations (models).
When viewed through this lens, documents are simply one representation of a model, just as diagrams are representations of a model. Both are structured queries from a given viewpoint that extract specific information of interest and present it in a defined format to satisfy a specific purpose (often analysis or communication). By understanding the separation of models and representations, it becomes possible to construct, communicate, and leverage high fidelity, high complexity models while simultaneously leveraging them through a combination of lower-fidelity textual and graphical representations.
Why do we care about the form and fidelity of the model? Why isn’t a document good enough for MBSE? It’s not that documents don’t have value. In fact, documents are an excellent communication tool, especially when working with a diverse audience. However, given the lack of precision in the written word, by definition there is ambiguity which makes documents suitable for some purposes but not the full breadth of MBSE. There is a reason that an architect who designs your home may start with a textual description of number of bedrooms, number of baths, general style and overall square footage but ends up with technical drawings for your agreement and for communication with the construction team.
So when we think about models in the context of MBSE, we should think about how best to support understanding the problem space, exploring the trade space, architecting for innovation and resilience, engineering with rigor, and ultimately delivering with confidence. Central to this is making the implicit explicit to better support innovation, analysis, communication, argumentation, and alignment. Doing so requires the right degree of fidelity for the given phase, task, and audience. For general communication on day one of a project, a text operational concept and “architoon” drawing may be perfect to align expectations and achieve a shared vision. When ensuring the EMF from the coffee maker does not interfere with the avionics in a commercial airliner, we want something with a bit more precision.
Done well, the fidelity of the underlying model construct or metamodel is always there. The precision of the model simply increases over time as the system model is expanded and refined. Properly leveraging representations – including documents – allows the team to effectively communicate concepts from a model (or, more precisely, connected models) across a broad spectrum of customers, users, managers, engineers, domain specialists, and stakeholders.
So is a document a model? Yes in the general sense, but ignoring the context of MBSE sets us up for failure. The same people who passionately argue that a document is a model are prone to treat a diagram as a model rather than a projection of a model to satisfy a specific viewpoint. That leads teams into the trap of diagram-based systems engineering, a very dangerous detour along the road to MBSE. That detour implies explicitness, rigor, and consistency where little truly exists. The best way out of that trap is to avoid it altogether and remember the difference between models and their representations.
