As organizations expand their scope and look beyond model-based systems engineering (MBSE) to model-based engineering, digital thread, or digital engineering, there is a common refrain. Over and over again, organizations speak of pursuing integrated models. Integration is certainly a step forward from disjointed, but integration alone is not enough. If our objective is to accelerate development and deliver the required business results in an ever-changing and more complex world, our pursuit must be engineered models instead.
To clarify the difference and the need, let’s take a step back. Every system has an architecture. The question is whether that architecture was accidental (as is too often the case) or intentional. Likewise, every system – a product, an enterprise, an engineering environment, and even a system of models – goes through integration and assembly. The question is whether the system was simply assembled from parts or fully engineered to deliver the desired capabilities.
In a system, developing the architecture is our one opportunity to manage complexity and embed resilience. The architecture drives system-level characteristics, capabilities, and performance. The interrelationships and interactions within the system drive the emergence of system behavior, whether positive (the characteristics we seek) or negative (unintended consequences). As systems engineers, we recognize these fundamental truths and leverage them in the systems we develop.
If we were to design a new car, we would never simply assemble one from a chassis, engine, transmission, suspension, and other parts on hand, believing that we would get the desired results. Yet when it comes to model environments and model chains, we seem to forget our systems principles. Too often we limit our aspirations to mere assembly and connection.
The International Council on Systems Engineering’s Vision 2025 lists many practices and challenges in today’s world. One of these notes the undesirable state of things today: “System design emerges from pieces rather than from architecture … resulting in systems that are brittle, difficult to test, and complex and expensive to operate.” Recognizing this challenge in the systems of interest we develop is not enough. If we are to better develop systems in the future – by digital or other means – we must intentionally engineer our environments as well. In the journey to digital engineering, one can assemble an environment from parts on hand hoping for the desired performance, but we know how that story ends. A major organization fell into that trap and suffered the consequences. They spent years and nearly $10 million assembling an environment that required a dedicated team of modelers to operate and a complex chain of tools and transformations to produce analyses, diagnostics, and visualizations. Such an environment is brittle, difficult to operate, costly to maintain and evolve – polar opposites of the characteristics we pursue.
The alternative is to apply our own systems principles to ourselves, our model chains, and our environments – to systems engineer our journey. Is MBSE our destination? If so, what is our desired outcome and how do we deliberately achieve that objective? Or do we seek to create a connected digital engineering lifecycle and need MBSE to help us both better understand the problem and connect the necessary digital capabilities to engineer the solution?
Embracing this mindset does not require that all existing models and tools be abandoned and a new engineering environment be developed from scratch. In fact, as systems engineers, we frequently deal with existing components and capabilities that must be included in our systems. The question is what mindset we choose to follow. We can simply integrate pieces together and hope for the desired outcome. Or we can deliberately engineer, defining our purpose and our measures of effectiveness up front and then designing the environment and supporting models to deliver the required results. We can leverage existing models where they are fit for purpose, ensuring we stay within the bounds of validity, connecting and wrapping as required so that they operate effectively within the engineered environment.
It is relatively simple to connect two things and get them to work together. It is something completely different to have them deliver the desired result efficiently, effectively, and free from unintended consequences. This is the essence of good systems engineering.
Accidental, integrated, or engineered – the choice is ours. Pursuing the path of assembly and simple integration may pass verification but will likely fail validation. Choosing instead to embrace our own principles and engineer our environments, model chains, and journey to digital engineering will deliver the results we require.
