Agile hardware is more than agile modeling
Many organizations and projects attempting to work in hardware end up spending their “agile energy” in modeling or system design rather than in the hardware itself. There’s an obvious place for Cameo, DOORS, SysML, etc, when it comes to designing a first article since you have to start somewhere. But the issue is that agile iteration often ends up occurring at that modeling and CAD level, seemingly reacting to information gleaned from design decisions. But the majority of the information that will most impact the design comes from creation of the actual hardware and demonstration system performance, not simulation or modeling reconfiguration.
It’s easy to iterate in Cameo, changing nodes and fiddling with requirements, and that allows the models to evolve quickly. The result of this is frequent “agile” re-baselines — which is generally desirable — while the hardware itself remains locked or untouched because physical iteration is more challenging. At times this evolution causes MBSE requirements to flex and follow presumed hardware constraints to theoretically make build/assembly smoother when the time comes. However, the reverse would be more valuable: stable, invariant requirements (presumably well-reasoned and sufficiently challenged) that persist while hardware iterates to pursue them.
Hardware projects, especially complex systems that have emergent and potentially unexpected behavior (a necessity of complexity), should follow a conceptual spiral from the most “load bearing” core components and allow everything else to iterate around the core. A simple modeling definition of the core capability/components is sufficient start the physical instantiation process. As Brian Armstrong said, “action produces information.” The unexpected learning from building the system reveals information that could not have been gained from the model, which is a belief about the system. Systems engineering disease occurs when the organization or product team treats the belief as if it were ground truth (which is actually the hardware instantiation), and iterating on that model because of the speed and convenience. This approach actually produces the least information and fewest insights, while the true information-generating activity of building interfacing hardware in the lab is delayed because it’s expensive and slow.
There is no amount of modeling that could tell you about thermal interface, optical tolerance stackup, achievable f/#, etc. Only physical iteration collapses those unknowns.
MBSE is not bad, but it’s not the pacing item in a hardware project — the pacing item is the hardware itself. The fastest velocity of information gain is by iterating hardware, not models and requirements.
