Digital Engineering, Digitization, and the MBSE Disconnect

While systems engineering continues to emphasize model-based systems engineering (MBSE), the greater community is shifting its focus to bigger issues – from model-based engineering to digital thread and now to digital engineering. Some view these simply as alternate labels for the same concept, but the scope is truly different. And though we want to believe that these pieces will naturally come together to create a digital future for engineering, that is not the case. If we think systems engineering should be the holistic enabler, we must reassess the path many are taking to MBSE.

The digitization of systems engineering is different than the path taken by the engineering disciplines. All engineering is model-based, but the foundations for engineering models are much stronger for the classical engineering disciplines. Thermodynamics, circuit theory, strength of materials, fluid dynamics – all are built on solid theoretical foundations while the understanding of key systems concepts such as complexity and emergence remains incomplete. Systems engineering remains far more art than science with a growing, but still immature, body of knowledge and an absence of a cohesive theoretical underpinning. As a result, there is often an emphasis on standards over purpose, process over principle, and representation over information. Therein lies the challenge and the potential of digitizing the artifacts and the workflow rather than realizing the fundamental principles through a digital implementation.

Why does it matter? Why would digitizing artifacts and representations represent a wrong turn on our journey toward a digital future? If we are simply talking about systems engineering, perhaps it doesn’t. Perhaps there are sufficient gains in efficiency in digital drawings to make the transition worthwhile. But if we want to talk about engineering a system, connecting the product lifecycle, and actually delivering a product or capability via digital means, we need far more than digital drawings. We need an integrated, cohesive digital model of the fundamental system concepts developed in way in which the semantic meanings are clear.

The shift in the greater community to digital engineering and connecting the product lifecycle represents an opportunity for systems engineering to do a course correction in our journey to digital/model-based. The vast majority of MBSE efforts over the last decade have been inward looking, standardizing and digitizing representations. In fact, this has often been done to the exclusion of other team members and stakeholders as we expect them to adopt systems engineering notations rather than systems engineers adapting to and mapping to others. If instead we adopt an outward looking mentality and seek to optimize the greater product lifecycle, the journey to MBSE can close the disconnect and enable the drive to digital engineering. Moreover, it represents an opportunity to mature our practice as we elicit and solidify principles, heuristics, archetypes, and eventually theory, choosing to digitize the right concepts to enable the engineering of modern systems rather than simply encoding past practices.

How do we begin? How do we handle the needs of a diverse stakeholder community (and the many engaged disciplines) working across a broad range of application and scale as we work to optimize business objectives (quality, cost, time to market, agility, etc.)? There is a practice for this – systems engineering. We need to apply good systems engineering practice to the problem, and we must architect before we design. We must look beyond the needs of systems engineering itself and ask what is needed to effectively engineer a system. It requires determining our purpose, establishing the context, and defining the right measures of effectiveness. We must engage the full set of stakeholders (technical, business, and human). We must holistically consider systems engineering, its principles, and the information set required to engineer a system, not just representations, artifacts, or the current information content of a specification.

Beginning this journey includes five key steps:
1. Focus on digital engineering, systems engineering, the underlying data model – anything but MBSE. A focus on transforming systems engineering to MBSE leads us into many traps – the belief that models are new, an obsession with representations, the digitization of artifacts over information, and seeing MBSE as somehow disjoint from systems engineering. It emphasizes reductionist and refinement perspectives rather than holism and big picture thinking. If we wish to see the forest rather than focus on the trees – or the bark on the trees – we need to set the right context as we seek to understand the problem and architect the solution.

2. Look outward, not inward. Whatever we do, we should always begin with the end in mind. The purpose of systems engineering is neither process nor specification nor model. The purpose is not even the system. The purpose is delivering the required value to the customer and the stakeholders in an effective and efficient manner. To do so requires the complete engineering and product lifecycle, not just systems engineering itself. Embracing the greater engineering need and the greater stakeholder community will help us maintain the correct scope and perspective –  digitizing systems engineering as part of enabling the transformation to digital engineering rather than MBSE as a stovepiped practice.

3. Reverse engineer the as-is information model. Though systems engineering has not yet matured into a discipline, the formal practice has at least sixty years of history. As we look beyond process and representation to the fundamental approaches and information necessary to engineer a system, we have many different representations of today’s practice: processes, documents, diagrams, and other artifacts. Each of these represents part of today’s information model for systems engineering as seen from a given viewpoint for a given purpose. Rather than discarding our past and ignoring the lessons of practical experience, we should reverse engineer this model and use those insights to inform the model to underpin digital systems engineering as well as the mappings to the many artifacts we will need going forward.

4. Develop a core ontology for the practice. Good systems engineering must be value driven, tailored to the application domain and business purpose. The same is true for the metamodel that underpins a digital representation. While there will certainly be domain-specific ontologies to represent the semantics of satellites, autonomous vehicles, and healthcare enterprises, there are core concepts central to any system. These transcend the specification to reflect the entire design history, journey, and rationale in context: the operational architecture and system design; risks, concerns, and programmatics; verification; fundamental analytics and trade-offs. This core ontology is the foundation for the various domain-specific ontologies. It is essential not only for digital systems engineering but for the advancement of systems engineering to a discipline as it defines the essential information and considerations in engineering a system. To develop this core ontology requires the right small team of experts working together with practitioners informed by past efforts, current approaches, and academic research. Other approaches will encode current practices, propagate disjoint standards, or settle for a least common denominator favoring consensus over correctness.

5. Recognize semantic technology as both an enabler and a threat. Today’s semantic technologies represent a fundamental capability that allows the right core systems engineering ontology to be the necessary connector for digital engineering – one model to coordinate them all. They become an enabler of tooling, whether a tailored tool chain to satisfy a given organization’s product line or a more generalized connection underpinning digital engineering. However, the pursuit of tooling connections disjoint from the systems engineering practice represents a fundamental threat. We must use semantic understanding and technologies in both dimensions – to connect our tooling while also making our own principles, information, and connections to disciplines explicit. We must also be aware of amateur experts recognizing that the rise of semantic tools and technologies enables many to know just enough to create danger for our projects.

Far too many products pass verification but fail validation. They may be well engineered, but the problem was poorly defined, poorly understood, or the solution simply was not fit for purpose. We can continue to digitize for our own systems engineering purposes failing to consider the greater context and community, creating our own “digital divide” and largely ensuring the irrelevance of systems engineering. Or we can embrace the greater context and leverage digitization of systems engineering as an opportunity to connect disciplines and enable digital engineering, in the process advancing systems engineering as a discipline and delivering true value. It’s the choice of context and purpose, a choice that either furthers a disconnect or embraces the systems perspective.