When considering the adoption of model-based approaches and techniques, organizations frequently ask “what is the biggest challenge we will face?” It is a good question, one that deserves a good answer. While model-based systems engineering (MBSE) is clearly the future of systems engineering, adopting model-based approaches is not trivial. To answer the question, we need to go back to systems engineering 101 and apply some of our fundamental approaches to the change in question. Fundamentally, what are we trying to achieve, and therefore where do we draw the system boundary? Pausing to ask and answer these questions focuses us on the most critical aspects (both costs and benefits) and maximizes the likelihood of success.
While there are a multitude of potential answers, the answers for most fall into one of two buckets:
1. “We want to transform our enterprise to embrace model-based engineering and adopt a fully connected lifecycle.”
2. “We want to improve our systems engineering practices and embrace the latest tools, methods, and techniques to gain benefit XYZ.”
If you find yourself in the first group and are trying to transform your enterprise, you have the far more audacious challenge with both the opportunities and problems that it represents. In this case, the system boundary is the entire enterprise – including suppliers, critical partners, and potentially even stakeholders and customers. This could be framed as a bottom-up re-engineering challenge – one in which each aspect of the enterprise which contributes to product / service development is assessed, requirements elicited, and then a new implementation developed. The solution space – and the transformation – reaches far beyond systems engineering. All of the interfaces between groups – between engineering disciplines, with contracting, and beyond – are within the system boundary and fair game for revision. In fact, not only are they candidates for change but, most likely, they will have to be completely transformed. To enable the model-based enterprise requires each group involved to adopt model-based approaches and model-based interfaces to enable a high-fidelity, highly-connected lifecycle.
Tackling a transformation of this scope is obviously beyond the bounds of the systems engineering team. To do this requires a corporate commitment with strong executive champions. There are tremendous technical challenges, most notably the definition of an underpinning domain-specific model (actually and ontology) that connects the enterprise. This ensures that information passed from one group to the next – one type of model to the next – does so without loss or confusion. It is a semantic (meaning) challenge as well as a syntactic (format / glue) challenge. More than that, it is a cultural change that impacts and includes the entire enterprise. This is by far the more daunting and challenging scope, one with technical and classical organizational change dimensions but one that promises tremendous gains in quality, responsiveness, agility, efficiency, and effectiveness when successful.
Far more often, we find ourselves in the second group, working to evolve or transform the practices of the systems engineering group. The system boundary is the systems engineering effort itself with the opportunity to transform the practice of systems engineering and, in doing so, improve team’s quality and/or responsiveness as part of the greater enterprise. In this case we have to recognize that we are in a middle-out engineering problem. We have the opportunity to re-engineering the systems engineering practices. We might have the ability to negotiate changes to our interfaces, but more often than not, we can simplify the overall adoption if we draw our boundary tightly and honor those existing interfaces.
In transforming systems engineering practices, we can take a white box or a black box approach. The old adage about engineers is true – if you ask an engineer for the time, he will tell you how the clock is made (a white box approach indeed!). Though transparency is generally an admirable trait, it may not serve us well in this case. When looking to transform the systems engineering practices, the rest of the enterprise may not care. Talking about the details of the transformation to occur within our box may actually create fear, uncertainty, and doubt in others – particularly if the benefit is perceived as largely limited to the systems engineering effort itself. In a risk-averse group, this is an invitation to hear “no, just do it the way you have been doing it.” After all, if the greater organization doesn’t perceive a gain for them, they likely will not be eager to accept change.
By taking a black box approach, we can fully encapsulate the change within our boundaries. This is especially true if we commit to honor our existing interfaces – with customers, with other engineering groups, and with program management. This may be less than intellectually satisfying – if we are gaining the benefits of MBSE, why shouldn’t we streamline our interfaces and share the added insights with others. However, insulating others from change – and any secondary impacts of the systems engineering group’s change – lessens any allergic reaction, simplifies the overall scope, and increases the likelihood of success.
So what if we are all-powerful and have the opportunity to define the scope and the system boundary ourselves? Start small, transform your systems engineering practices with MBSE, and find success there first. Honor your existing interfaces and insulate others from change. Once we have our system – the systems engineering team applying MBSE – working well, we can adjust our interfaces and then enable the greater model-based enterprise. Adopting MBSE is far less of a technical challenge than a cultural one, so good organizational change approaches are critical to success – for the engineering team and the organization at large.
