Influenced by the broad applicability of systems engineering and the fact that it is generally taught top-down, many systems engineers believe that they consistently engage in a variant of clean-sheet design. While systems engineering certainly enables fresh thinking and new looks into a problem space, the reality is that we operate within existing organizations tuned to specific markets. Though a medical device company may demonstrate excellence in systems engineering, it is unlikely that it will choose to apply that excellence to design a new aircraft. The same is true for an aerospace and defense firm that is unlikely to cross into the medical space. Organizations are classically built around product lines or – if there is too much time between generations – product families, variants, and other combinations of related systems. Though we don’t always make them explicit, most organizations revolve around reference architectures.
Reference architectures are not new, but representing reference architectures via model-based techniques greatly enhances their value. This does not tie to some of the classic myths and misconceptions of MBSE. Instead, it’s about the benefits achieved by evolving from low-fidelity representations in documents to higher-fidelity, richer representations for communication and analysis. It’s also about the benefits gained through an increase in granularity of knowledge capture for management, analysis, and learning. Moving from implicit reference architectures loosely captured in the memory of a team to explicit reference architectures owned and managed by the organization yields four key benefits.
Benefit #1: Aligning the Team
Complicated and complex systems are not built by individuals. They are not built by homogenous groups. They are built by teams composed of different specialists with different educations, experiences, and perspectives. Effectively blending the expertise of the team to achieve a shared understanding of the problem and solution space is critical. Otherwise, the problem cannot be explored from multiple angles, and ideas cannot flow effectively. Unfortunately, each of these specialists comes with their own language and their own underpinning concepts which inhibit that shared understanding, communication, and collaboration we seek.
The classic approach to solving this communication and alignment problem was the specification. After all, documents can be understood by a broad audience. But we can do much better by leveraging model-based techniques, particularly if we bring a systems perspective to communication. The key is to explicitly language the problem and the solution. This seems simple enough, but I was once told by an automotive manufacturer that two teams working on a door would point at exactly the same part and use different language depending upon if they were the “inside door team” or the “outside door team.” Because organizations consistently solve similar problems, establishing a reference architecture and agreeing upon the terminology streamlines communication across all those involved. Doing so with MBSE enforces explicitness in both concept and language. As you move beyond ideation into engineering, the words and representations have explicit meaning. As such, communication is crisper and cleaner, addressing the “plague of vague” which permeates many projects.
Benefit #2: Starting Fast
Most of us remember the “blank sheet of paper” problem when sitting down to write an essay. When nothing is on the page, the opportunities are limitless. But that freedom is also binding. Getting the first thought onto paper is quite difficult for many.
The same is true for developing a system design. Getting the top-level architecture is not easy. Doing it well is even harder. If an organization has a reference architecture, there is a well-thought-through starting point. It’s applicability to the problem at hand can be debated, but because the reference architecture exists (and particularly if it is represented as a systems model), that debate has clarity. The reference architecture can then be instantiated and tailored to the problem, enabling the team to start fast.
But will starting with a reference architecture inherently limit and bias the design based upon past perspectives? This is an extremely valid concern. Most true innovation occurs at the architecture level in rethinking fundamental concepts. Done blindly, leveraging a reference architecture can inhibit innovation. How to best combat this? Empower someone to explicitly challenge the reference architecture and the team to ensure suitability of the solution. Depending upon the organizational culture, this may be a well-known and respected seasoned practitioner, a valued curmudgeon, or a newer practitioner known as an innovative thinker. Intentionally seeding the team with the reference architecture and then perturbing the design system yields the best of both worlds.
Benefit #3: Aligning Systems
The benefits of alignment are not limited to the team. Alignment in the systems produced is also quite beneficial, particularly in an age where we must move faster and must take advantage of reuse to address speed, cost, and quality concerns. Architectures derived in a completely independent manner may yield radically different subsystem and component designs. Architectures instantiated from a reference architecture naturally see more alignment in the subsystem and component design, enabling more reuse and enhancing through-life support.
Done well, leveraging reference architectures enhances both reuse and innovation. The physical dimension of a reference architecture classically inspires common components and reuse. The behavioral architecture enables innovation. Over time, behavioral architectures are classically far more stable. Fundamental approaches and needs in the behavioral space change slowly. However, the technology infusion rate continues to accelerate which makes new physical architectures possible – replacing a kinetic weapon with a directed energy approach in a defense kill chain or replacing the driver with sensors and controllers for autonomous vehicles. The presence of a reference behavioral architecture helps identify existing behavior that can be remapped onto new technologies delivering new performance characteristics at a revised cost profile.
Benefit #4: Building a Framework for Learning
The instantiation of a reference architecture for a new project provides an explicit opportunity for organizational learning and feedback across projects. At any point in the new project (often after major milestones), the project-specific architecture can be compared with the original reference architecture. Innovative approaches, tailoring, and evolutionary changes are highlighted for discussion and debate. Where changes have broader applicability, they can be reflected back in the reference architecture. Where changes are project-specific, they can be captured in a larger knowledge base in the context of the reference architecture for enhanced understanding of the problem and the corresponding solution when similar circumstances emerge in the future.
There is also a correlation between the granularity of knowledge capture and learning. Learning from specifications is difficult, particularly if you are attempting to compare two specifications. The knowledge is simply not well packaged for such a purpose. If the knowledge – the reference architecture and the project architecture – are represented as models, the knowledge is packaged in much more granular packages well-suited for comparison and learning. Even better, if you explicitly maintain relationships between the reference architecture and the instantiated architecture, learning can be built in during the design process with rationale and corresponding impacts captured.
If you don’t have a reference architecture, where do you start? First, it’s often easier to abstract a reference architecture from existing project-specific efforts than to develop one clean-sheet. Second, don’t strive for perfection and full precision. The reference architecture needs to cover the full scope from requirements (or perhaps all the way back to concept of operations) through behavior, physical architecture, and test. It needs to be complete at the top level with greater depth where appropriate. Everything captured must be accurate, consistent, and coherent. However, it does not have to be infinitely detailed across the breadth of the system. The reference architecture can and should evolve over time. Pursuing perfection on day one leads to diminishing returns if not full design paralysis. Instead, apply good engineering judgment capturing the foundation reference architecture for team alignment, system alignment, and future learning enabling a fast start on the next effort.
