Systems engineers enjoy a decided advantage in the system design world. They are tasked (and trained) to see the entire design. It is the system engineer’s job to address the complete system solution. This means understanding the problem and the context as well as the design solution. That perspective advantages the systems engineer by providing a comprehensive viewpoint that leads to a level of insight not available to others with a more limited view.
There is, however, a great temptation to surrender that advantage by adopting a more constricted view of the problem. It’s not that any systems engineer ever sets out to limit his or her effectiveness, but the advantage is surrendered as a result of actions taken for other reasons.
The first temptation comes in the form of a desire to specialize or focus on one particular domain. At the inception of the project there is a natural emphasis on gathering the requirements that will drive the design. It is tempting to focus on this important design activity in a way that excludes or limits the focus on other domains. Some “systems engineers” will even develop their skills at requirements definition and management and begin to call themselves “requirements engineers.”
There is nothing wrong with a high level of skills in a domain or even with “requirements engineers” but there is a problem with confusing a domain-specific concentration with systems engineering. While systems architects focus on components and requirements experts concentrating on requirements bring a good deal to the team, it is the systems perspective that gives systems engineering its greatest value. That is the sine qua non of real-world systems engineering.
There is also a temptation to lay down the systems view at the design boundary. Systems engineers almost always understand the design solution within its boundaries. But there are significant numbers of designs that make it to implementation without adequate consideration of how the design will live in its context.
Again, as in the domain-specific narrowing of the systems view, this costs the systems engineer a large portion of her value to the team. It is the systems engineer that guards the design against unintended consequences resulting from a failure to understand the context. When the systems engineer fails to acquire an adequate view of the context system that protection evaporates.
The cure for both of these shortcomings is an unrelenting dedication to the systems view. The systems view must drive the design effort. That means that the proper place for the systems engineer is atop the team. Systems engineers must be in a position to acquire and refine a view of the system and its context.
They must also be able to norm the design to this view. If the design is normed against a limited view like that of a domain-specific focus or if it is denied the perspective of its context, it is being developed without the benefit of true systems engineering. It is up to the engineer to pursue the appropriate perspective. This means recognizing and calling out the narrowing of perspective that can arise.
A failure to do this is a surrender of the special, unique value of systems engineering. The competent systems engineer should diligently resist this in whatever form it takes. The systems engineer should never willing give up the advantage of the systems view.
