Recently, I was asked a technical question regarding a workflow. I could offer a precise answer but fortunately had just enough context to know that in doing so I would set the project back rather than move it forward. In this case, the various players each had a slightly different understanding. So while I could offer an answer and frame it clearly, each of us would take a slightly different interpretation and understanding of the words based upon our individual context. Regrettably, many purveyors and practitioners of model-based systems engineering (MBSE) fall into a similar trap, offering precise answers absent a shared understanding resulting in divergence and problems rather than convergence and progress.
Systems engineering is a practice defined by two words: “systems” and “engineering.” The vast majority of those who associate with the label “systems engineering” have a formal engineering education and naturally gravitate to the engineering dimension. As such, there is little risk in overlooking the necessary analysis and rigor when applying systems engineering to properly define, analyze, and address a problem. The application of modeling and simulation is self-evident, and we leverage models to serve our engineering needs. The risk is far greater that we forget the context and implications of “systems,” particularly as we seek to adopt model-based approaches.
Systems engineering requires a holistic viewpoint, one that looks through the entire lifecycle from first concept through retirement. Richard Beasley, Associate Fellow of Systems Engineering at Rolls Royce, frames the practice as follows: “Systems engineering collects and organises all the information to understand the whole problem, explores it from all angles, and then finds the most appropriate solution.”
It is far bigger than the specification of a design. It includes the journey that begins in the problem space, extends through the solution space, and manages the information through life. And it requires effectively engaging a diverse team throughout, a team comprised of far more than engineers.
This is where organizations and practitioners often lose their way in the adoption and application of MBSE, forgetting the greater scope and context of systems engineering. Many errantly equate MBSE with SysML, believing that they must use a specific notation if they are to adopt MBSE. While SysML is a fine notation for systems and software engineers, MBSE is not about any one representation. Put simply, MBSE is about making system descriptive and analytical models explicit, coherent, and consistent as we evolve from low-fidelity representations in documents to higher-fidelity, richer representations. Done well, we improve the granularity of knowledge capture in the engineering of the system, establishing an authoritative source of truth to manage and leverage information throughout the system lifecycle. Done well, we establish an explicit systems model which connects the various engineering teams, looking beyond ourselves to enable digital engineering. But while analysis, design, and digital engineering are all important, far more critical is establishing across the project team a shared understanding of the problem, the trade space, and the solution.
In Team of Teams, General Stanley McChrystal observes “one cannot understand a part of a system without at least a rudimentary understanding of the whole.” Later, as he discusses how teams must engage in a complex world, McChrystal asserts “functioning in an interdependent environment requires that every team possess a holistic understanding of the interaction between all the moving parts.” 
As practitioners of systems engineering, first and foremost our responsibility is to connect and align the greater project team as we seek to understand the problem, explore it from all angles, and map the interactions and interdependencies (of the problem, the solution system, and the project team throughout the system lifecycle). As we adopt model-based approaches, our first priority must be on improved communication, achieving at least a shared understanding as we aspire toward shared cognition. From this foundation we can then leverage the analytical power of MBSE. But without the foundation of shared understanding, we are building on sand. The analytical power of MBSE can easily help us move with speed and precision in the wrong direction.
If shared cognition is our goal and systems engineering requires the engagement of a diverse community of stakeholders, customers, and subject matter experts throughout the lifecycle, can we apply our own techniques to better understand and engineer the application of MBSE? If nothing else, this should tell us that the application of MBSE must be fit-for-purpose, tailored to the problem, context, and team. And it must begin with effective communication. It’s not important that we adopt a singular design notation for our own purposes. It is important that we look beyond drawing diagrams and leverage the true power of an authoritative source of truth combined with fit-for-purpose views to effectively communicate with the greater team, sharing context and eliciting insights. As systems engineers, it is critical that we serve as the universal translators, switching between representations and notations as needed to effectively communicate context and concepts with each group. This means leveraging SysML in the space it was designed for (system design and specification to close the gap between systems and software engineers) while using other diagrams, documents, tables, and rich representations to engage with others across the lifecycle. If underpinned by a consistent, cohesive model (the authoritative source of truth), adopting fit-for-purpose representations becomes a key enabler to shared cognition.
Early in any project, we seek to answer what the system is trying to achieve, why, and how well. As we learn about the situation, we face entangled social and technical issues – in our problem and across our team. The biggest errors are always made on day one – in the systems we engineer and in the project approaches we take. Moving forward effectively and efficiently requires that we effectively set the big picture, aligning the stakeholders and the project team. Achieving this does not require that we bind ourselves together with a common notation, and such an attempt often undermines the effort rather than enabling it. Instead, shared cognition requires a common understanding of our problem, the trade space, the solution, and the interdependencies and interactions at play. Achieving that is the first job of anyone applying systems engineering, and we should avail ourselves of any resource and representation possible in the quest for shared cognition.
