The systems engineering tool “Analysis of Alternatives,” or AoAs, impacts a broad range of concepts in systems engineering. In my experience, the inception of a project revolves around smart people—often program managers, technical directors, or business developers—discussing what they’ve heard or read or seen as an opportunity to do something new that addresses a problem. My teams had people at a conference table using a whiteboard, discussing the concepts. We’d draw pictures with boxes, circles and lines representing how things flowed. The team members offered their opinions and folks pushed and pulled, identifying gaps and inconsistencies, along with technical issues to consider.
So how does a whiteboard and discussions relate to model-based systems engineering, or systems engineering in general? Whiteboard sessions and discussions constitute the foundation of an analysis of alternatives. In a model-based systems engineering tool, we capture the thoughts discussed as a permanent record of the design journey. Items considered during the whiteboard session often involve how to partition a system’s architecture, the number of subsystems, as well as how to partition the subsystems, for example, by:
• function,
• supplier,
• risk
• expertise,
• reuse, or
• company interest
All too often, these design discussions are lost when projects transition to proposal or production. These insights are critical to a design’s longevity in that they allow the designers to understand the “as built” designs and what is possible to improve in terms of performance, cost, or upgrade. These AoAs, if done sub-optimally, can impose significant limitations on a design that can’t be overcome down the road, or at least will require changes that must occur at a significant cost.
But again, what does this matter in regards to model-based systems engineering? The point is that engineering and program managers can capture what they were thinking. I recommend they build models of the concepts considered and perform adequate analysis. Yes, I used “adequate,” which isn’t a quantifiable term, but we don’t have unlimited budgets to investigate an infinite number of alternatives. Modeling the architecture and performing functional analysis allows the team to understand at a technical level the dependencies of each alternative, and to capture the parametric results in order to perform a final trade-off.
My managers often asked, “What are your options? What are your recommendations? and Why?” In my opinion, this is an analysis of alternatives. My managers would not accept that I recommend number two of three options “just because.” I had to have facts with calculations, and I had to list comparisons of the alternatives to one another. During that type of review, there were occasions where I hadn’t considered a factor. Once these were identified, the analysis would be rerun.
Here’s a slight aside. Once upon a time, I remember performing an AoA. I met with my manager and briefed him on what I concluded. He said the analysis from a technical perspective was good. He said what I had failed to take into account were political considerations. We were investigating partnering with one of the suppliers. He purposefully didn’t tell me that information prior to the technical analysis, because he wanted to make sure the potential partner was viable from the technical perspective, and they were. But this story is a reminder of the wide range of factors that may impinge on a decision.
Using model-based systems engineering to capture the data includes having alternate requirements, functional and physical models. The Vitech tools, CORE and GENESYS, allow engineers to have alternate decompositions validated from a consistency and completeness perspective. We can also evaluate timing and resource utilization in our discrete event simulator. Insight gained through simulation may influence which of the alternatives are selected. The benefit of identifying issues at this level is greater cost-efficiency. According to research, not finding a problem until later in the design phase becomes much more costly. Being able to include timing and resource competition and use are valuable parameters that I think should be part of the analysis.
Another wrinkle in the AoA is if we do perform modeling and use the AoA to determine subsystems, we have the structure of how to establish model hierarchies. When complete, organizations can use subordinate models as building block modules that can then be used on future projects. CORE and GENESYS support the hierarchy of projects, allowing extended teams to focus on their design space without design details from other subsystems, while the System of Systems (SoS) systems engineer has visibility into the detailed design.
Note though, AoA isn’t performed exclusively at program inception, and we can and should perform AoAs throughout the entire design journey to avoid selecting the first thing that satisfies the requirement. Design decision capture is important once again at this level to provide full context for all that was considered, and to convey why decisions were made.
Happy Engineering!
