Part I of this series of posts speaks to the first two of the five steps to improving systems engineering: shape your process to converge on a design solution; and maintain a systems perspective throughout your design process.
Part III of this series speaks to the final two steps: make your practice agile and responsive; and be sure that your process accounts for the entire environment within which the system will function.
In the previous installment in our series, we dealt with the first two steps to improving our systems engineering process—using a convergent design process and maintaining a systems view. In this post, we meet the serious sources of risk created by fragmenting our design teams and approaches. Fortunately, there is a strong and effective solution for them. By connecting our engineering across disciplines and domains, we can maintain a systems view and develop a common understanding of the problem and its solution.
STEP 3. Minimize risks
One of the major sources of risks to your design is generated by the stovepiping of the team, their data and work that results from domain-specific tools and models. Many design efforts proceed with fragmented or partial models created and managed by separate engineering disciplines in separate tools. In the world of complex problems and solutions it is necessary to work concurrently in an environment of connected engineering. This means that the various engineering information and purpose-specific models should be made available across the disciplines and the relationships among them established, thereby shedding light on the entire design.
In this way, the system design itself is integrated—all of the work in all of the domains can be tied together in a single design. Where the systems engineering domains and the engineering disciplines are treated separately, there is a significant risk that work in any one domain or discipline will not be accurately and completely reflected in the overall design. This creates a group of risks that problems in one area can create and magnify in another. If the disciplines and domains are isolated from each other in the design process, this interaction and unwanted emergence cannot be effectively managed.
The collaboration and information sharing made possible by a connected engineering approach provides the answer. Engineers from different domains and disciplines working together can solve the problems arising from complex interactions by pooling their collective expertise and advancing the design.
While stovepiping the analysis itself into discipline-specific sectors presents the most obvious risk, an even greater and more subtle risk is the stovepiping of the team into systems engineering domains—requirements, behavior, architecture, and verification and validation. When this happens, requirements people work on requirements, process people concern themselves with behavior and workflow, while system architects focus on implementation architectures. Meanwhile, test and evaluation shops await the opportunity to receive information about the system to be loaded into the testing environment.
This effectively limits (if not destroys) collaboration across the team as the various aspects of the design must flow between the divisions of the team. Differing perspectives blind others to the design considerations faced in any one area. The key concept, that of maintaining a systems view, is compromised and the design itself is fractured and fragmented. This places the ultimate solution effectiveness in jeopardy while increasing cost.
In addition, at the data level, working model-to-model and tool-to-tool creates the risk that work in any one domain will be lost or mistranslated into another domain. It places the burden on the team to ensure that the data in disjoint models and tools are consistent. This is very hard to do—especially in real time. Updating and cross-checking take time at best and can introduce inconsistencies and errors. These must be corrected, costing time and money in the design process. This is only exacerbated by the fact that such consistency checks must be accomplished across divides in the team as well as in the design.
Every exchange point between models and tools creates a significant risk of loss or distortion. Just as every exchange of the ball in football creates a fumble risk, so the exchange of work from tool-to-tool or model-to-model increases the risk of reduced design quality. Eliminating these divisions eliminates those risks.
It is only by unifying and connecting the engineering team across disciplines and domains that a coherent and consistent design can emerge with a reasonable assurance that all of the engineering challenges have been addressed and met and that no untoward surprises await as the result of a fragmented approach. Complete connected engineering of the design is the single best guard against the risk of fragmentation and unplanned emergence. And ultimately it is systems engineering—the technical connective tissue of the engineering team—that must bring connectivity to the engineering enterprise through its model, environment, and approaches.
In the final post in this series we will consider the last two steps in our five-step path to improving our systems engineering practice, making our design process agile and responsive and accounting for the entire operational environment in which our design will “live.”
