A highly respected colleague once presented a leading edge paper on model-based conceptual design at a conference. When he finished, a member of the audience – one considered by many to be a thought-leader in model-based systems engineering – stood up. He didn’t ask a question or offer an insight. Instead he chose to deride the presentation and dismiss it in its entirety based on a single point. The transgression? The presenter used a diagram from the traditional set of systems engineering representations rather than a SysML diagram. The fact that the representation was used to communicate more effectively with the end user and domain specialists unfamiliar with SysML? Irrelevant. In the mind of the audience member, if it wasn’t done with SysML, the systems engineering was outdated and outright wrong. [more]
Though it’s a single example, it’s something I have seen repeated far too many times in forums around the world. I have seen it based upon representation, and I have seen it founded in process, methods, and tools. I have seen it in direct challenge to the presenter, and I have seen it in audience members who sit quietly. In all cases, the belief in a specific framework is so strong and absolute that the individual dismisses the greater idea and possible intellectual contribution. Whether it’s strict adherence to a methodology, a tool, a representation set, or a process standard, this reaction eliminates any opportunity for the individual to learn. Worse than that, discarding the insights and contributions in their entirety impedes the greater exchange of ideas that is ultimately necessary for the practice and profession of systems engineering to advance.
There is no “one size fits all” in systems engineering. Problems differ in their scope, their scale, their complexity. Teams differ in their knowledge, their experience, and their skills. And the profession itself continues to evolve, taking in new insights – from application experience and from other domains – to better address the challenges and opportunities of today and tomorrow. Strict adherence – be it to process, representation, or standard – ignores the requirement to tailor to the circumstance. Often times, people feel dogma is key to advancing an idea or a profession. Instead, dogma limits our effectiveness, blinding the individual and creating ideological conflict rather than constructive exchanges that benefit the project, the practitioner, and the practice.
Good systems engineering begins with understanding the problem and the corresponding constraints. It is holistic, not simply in understanding the problem and exploring the solution space but also in understanding the tools and techniques that should be brought forth during the solution process. Based upon the nature of the problem and program, we choose the process, methods, and tools suitable for the circumstance. We don’t choose a hammer first and then begin looking for nails.
This does not mean that standards are bad. Nor is SysML (or for that matter any other representation set, process, method, or tool). Standards encode successful practices and can help us align as individual project teams or a greater practice. SysML can help us as we analyze a problem, architect a solution, and communicate with the right audience. All are part of a larger systems engineering toolbox, one that we must continue to expand – as individual practitioners and as a greater community – so that we can match the tools and solution approach to the problem at hand.
The purpose of systems engineering is not found through blindly following process. The purpose of systems engineering is neither production of a particular specification nor model. The purpose of systems engineering is delivering the required value to the customer and the stakeholders in an effective and efficient manner. To do that, it’s time to move past dogma, because dogma has no place in that equation, especially when considering effectiveness and efficiency. In its place, we need diversity in processes, methods, tools, and the requisite guidance and experience necessary to tailor these to deliver project success.