The Fool’s Errand of Reuse in MBSE

Systems engineering emerged in an era of clean-sheet, top-down, stand-alone design where design began at the system level and proceeded through custom manufactured assemblies and electronics. In today’s age of rapid technology infusion cycles, changing needs, and middle-out or bottom-up design, we strive instead to embrace reuse of existing components and subsystems blended with fresh design where necessary. Reuse in systems forces us to relook at our processes, methods, and tools leading many to advocate for the reuse of models within model-based systems engineering. Unfortunately, as generally framed and pursued, this is a fool’s errand with no hope of success.

Within MBSE reside two classes of models – analytic and descriptive. The analytic models (often, but not always, physics-based) are discipline or domain-specific models representing key performance characteristics and constraints that govern system effectiveness. They range from finite element analysis to wave propagation to human cognition and beyond. The specific analytic models selected depend upon the system of interest. When brought together with coherence and consistency, these models support the engineering rigor required. Quite frequently, these models exist in their own domain-specific tools or in generic libraries encoded in Matlab. Done well, these models are absolutely reusable at the system level, but that is not the broader reuse that most promise in MBSE.

The second type of model is what most people think of when they talk about MBSE. The descriptive (or architectural) model spans from concept of operation through requirements, behavior, physical architecture, and verification & validation. This is where innovation occurs at the system level. This is where we address security, resilience, and complexity from day one. This is both model and specification for the system of interest, and it is the connective tissue that ties together the required analytic models to enable engineering systems. Unfortunately, reuse of the descriptive model ranges from impossible to simply cost-prohibitive such that undertaking the initiative makes no sense.

Why is reuse of the descriptive architectural model a fool’s errand in the broader sense? We can look to software engineering for insights. For years, reuse was the promised silver bullet in which organizations invested. As software was designed and developed, it was added to corporate libraries for reuse. Unfortunately, positive reuse – defined as reuse where the benefit outweighed the cost – was the exception rather than the rule. Larger-scale software modules are engineered for a specific purpose. To genericize the software beyond the needs of the project to address the broader case require additional time and investment – overhead that neither the project nor the “reuse department” wants to cover. The same is true for documentation – of assumptions, of boundaries of use, and of general approach for extensibility. The result was software modules frequently ignored as not applicable, misused outside of its original purpose and bounds of validity, or extended at notable cost as the module was fundamentally reengineered to fit the purpose.

Even if we do everything right – our assumptions match the model assumptions, we operate within the bounds in which the model is valid, etc. – our environment is constantly changing. Changes in conditions, strategy, policy, and doctrine naturally invalidate models over time.

Today, we see software engineering focused heavily on agile and lean approaches which advocate that any work not tied directly to project value is waste to be avoided. Rather than focusing on reuse, we see greater emphasis on understanding the real customer needs and desires, good design, and avoidance of rework and wasted effort. Where we see reuse is at the well-bounded component level – far more analogous to reuse of analytic system models than the descriptive architectural system models.

So does that mean that all is lost? Do we need to give up on all reuse concepts at the systems level and revert to clean-sheet design? Absolutely not. We simply need to forgo the generic promise of reuse in MBSE for better-bounded scenarios that deliver both value and success:

Patterns. Architect Christopher Alexander is credited as the father of the pattern language movement. Patterns identify commonly occurring problems and couple them with reusable solutions that are applicable in a stated context. Popularized by software patterns and the “Gang of Four” (Gamma, Helm, Johnson, and Vlissides), patterns are applicable to systems engineering as well – as demonstrated by Cloutier and others. Because of the generic nature of the design pattern and the framework which states the problem, solution, and context, architecture design patterns encode knowledge in an effective format for reuse. Whether drawn from industry practice or simply organizational knowledge, patterns can be encoded in architectural model snippets that can be quickly injected into system models for use in a specific design solution.

Reference Architectures. Though systems engineering prides itself in its broad applicability to any system, the reality is that we operate within existing organizations tuned to specific markets. While our organizations may demonstrate excellence in systems engineering, they couple systems engineering expertise with the requisite domain knowledge to be successful with specific types of products in specific markets. Therefore, we generally work within the bounds of reference architectures, whether explicitly captured or implicitly maintained in the heads of senior practitioners. Reference architectures are inherently reusable, even more so when captured using model-based practices. The problems are well-bounded, the assumptions generally understood if not documented, and disruptive changes in problem or solution are evident. Capture and reuse of reference architectures – particularly capture in a descriptive architectural model – yields 4 key benefits: aligning the team, starting fast, aligning the resultant systems, and learning.

Product Line Engineering. In reality, most organizations are actually product line organizations. The question is not whether they release a new version, edition, or generation of a product. The question is how much time passes between releases. When the time is 6 months, 12 months, 2 years or less, product line engineering is viable, and reuse of a corresponding descriptive model brings tremendous rewards. In moving from release to release, many benefits come from detailed refinements meaning the existing boundaries, assumptions, and design remain valid. Where disruptive changes are introduced – either in customer need, solution approach, or implementation technology – starting with a high-fidelity model-based representation of the previous system with complete traceability enables more effective assessment of impact, identification of risks and concerns, and elicitation of emergent behaviors.

Analytic Models. The models we use for the analytic dimensions are not new to MBSE. These are models that engineering disciplines have developed over the years, often encoding solid theoretical principles complete with well understood assumptions and bounds of applicability. As noted earlier, when done well these models are absolutely reusable at the system level. The key is good documentation – of purpose, of limitations, and of approach. It is far too common to hear stories of engineering organizations relying upon 30 year old Fortran modules where the original developer has long since retired, no one really understands how it works, yet everyone still trusts that it is applicable.

In modern systems and modern systems engineering, reuse is not a luxury. It is a necessity. We simply have neither the time nor the money to custom design and fabricate every component in our system. We want to believe in reuse of our models as well, but as frequently framed it is simply not possible.

Reuse of analytic models is standard practice today. Reuse of descriptive architectural models is coveted but in reality holds the promise of great investment with little return. The wise practitioner instead recognizes that patterns, reference architectures, and product line engineering define a more appropriate scope for architectural model reuse, delivering tremendous value in the form of lower cost, shorter schedules, and higher quality when implemented correctly.