Why Functional Chains Are Not Capability Threads
A model can illustrate a functional chain and still do nothing to address the delivery problem. In that case, MBSE merely describes where integration will fail later on. Robin Yeman made this point in her keynote address at the MBSE Summit. Her topic was Industrial DevOps. The most incisive statement ran deeper: Those who break things down by business functions aren’t building capabilities. They’re creating handoffs.
One Life Cycle Instead of Five Transformations
Robin Yeman has been working on large, safety-critical systems for about thirty years. She spent many years at Lockheed Martin, where her work included satellite programs. Today, she works as a Technical Fellow at Leidos on air traffic control systems. Her dissertation examined how Agile and DevOps can be applied to large cyber-physical systems. To that end, she spoke with engineers from SpaceX, Relativity, Planet Labs, and NASA.
This practice led to the book, written by Suzette Johnson Industrial DevOps. The term sounds like "DevOps for hardware," but it means more than that. Industrial DevOps calls for a unified lifecycle for systems, software, hardware, testing, and operations.
This is exactly why many transformations fail. An organization launches MBSE, Agile, DevSecOps, cybersecurity, and AI as separate initiatives. Each function gets its own language, its own tools, its own budget, and its own consultant. In the end, there are five progress reports and one integration problem.
Robin calls this “cognitive load.” Program management thinks in terms of earned value and deadlines. Systems engineering thinks in terms of models. Hardware thinks in terms of prototypes. Software thinks in terms of sprints. Testing thinks in terms of validation. Operations thinks in terms of stability. Everyone is supposedly working on the same system. In practice, each function optimizes its own intermediate product.
Models are not the result
This logic hits MBSE particularly hard. Robin describes teams that build excellent models. Software development doesn’t make use of them. The customer doesn’t provide feedback because they don’t understand the notation or never see the model. The model is correct, but it’s not effective. Then MBSE becomes a silo.
The problem isn't with modeling. The problem is that the model is treated as the end result. Software developers think the software is the product. Modelers think the model is the product. Testers think the tests are the product. None of these is the end result that the customer receives.
In an air traffic control project, Robin therefore created additional views alongside the models. These views depicted movement, data flows, and sequences. This allowed even people who could not read MBSE notation to provide feedback. The model remained important; it simply no longer had to be understandable on its own.
The reason behind this is Conway's law. Organizations build systems that reflect their communication structure. When systems engineering, software, hardware, and testing operate in isolation, risks arise at the interfaces. That is exactly where they later come to a head during integration.
Function Shifts Within the Organization
The central point of Robin's presentation was decomposition. Many programs do not break down their system but rather describe its lifecycle.
Robin talked about a radar program in Alaska. When asked how to break down the radar, the answer was: first design, then architecture, then implementation. That’s not a system breakdown—it’s a workflow.
This is where the word “function” becomes problematic. In MBSE, “function” refers to a system’s capability. In an organizational context, “function” refers to a discipline. Robin does not criticize the fact that systems are understood in terms of functions. She criticizes the fact that programs break down their work along organizational functional lines.
If you break it down this way, you end up with systems engineering, software engineering, hardware engineering, and testing. If you break it down by results, you end up with capabilities such as command and control, guidance, navigation, and control, or OTA updates.
Only the second decomposition generates a capability thread. A capability thread is a narrow cross-section through requirements, model, architecture, software, hardware, testing, and operations. It reveals a capability of the system at an early stage. Not completely, but integrated enough to test assumptions.
Automotive MBSE and the False Sense of Security
This point applies to the Automotive industry. Many OEMs and suppliers have been working with functional chains for years. This makes perfect sense. A driver assistance feature, an OTA update, or a thermal management system performs its functions by forming functional chains that reuse smaller functions.
Nevertheless, the delivery structure often remains the same as before. Systems engineering models the functional chain. Software implements parts of it. Hardware provides control units, sensors, or actuators. Testing later verifies compliance with requirements. Integration takes place too late. Then the model looks like an end-to-end system. The work remains piecemeal.
A functional chain links system functions. A capability thread links work. It integrates requirements, architecture, interfaces, implementation, testing, verification, and feedback into a shared learning cycle.
That is exactly where MBSE Theater comes into play. The functional chain appears to involve early integration. In fact, the areas that need to be integrated later were simply documented earlier.
Integration First
Robin turns the usual order on its head. Many programs plan, design, and build separately for a long time. Integration doesn't happen until three-quarters of the way through the project. That's when it becomes clear that key assumptions were wrong.
Her counterquestion is simply:
„Why don't we start with the really hard part?“
Robin Yeman
Suzette Johnson and Robin express this same relationship in their book as a rule of integration:
„There is a direct correlation between the time elapsed since integration and the amount of rework required.“
Suzette Johnson, Robin Yeman
The longer integration is delayed, the more work there will be to do later.
Robin demonstrated this with an F-16 retrofit. The project was scheduled to take about fourteen months. She reorganized the separate system, software, hardware, and test teams into cross-functional teams. These teams built capabilities on the aircraft itself, rather than artifacts for the next handoff. The program delivered after nine months and moved into hardware integration with very few defects.
The speed didn't come from typing faster. It came from fewer hand-offs.
This also means that the V Model That's not wrong. What is wrong is the convenient interpretation that convergence can wait until the right side. The V-model describes a logical relationship between specification and verification. It is not a license to postpone integration until the end of the project.
AI also makes traffic jams worse
Robin's comment on AI is dry:
„AI just makes things go faster, but if I'm building things faster in my silo, I have more work in progress and still nothing is getting finished.“
Robin Yeman
AI in a silo creates more work in progress: requirements, backlog items, code, test cases, and more models. None of this improves the flow if the work continues to be held up by the same barriers.
This repeats the old pattern. A new technology speeds up local work, but the overall system remains slow.
Robin therefore does not see software development as the primary driver of change, since software is only one part of the value stream. In large cyber-physical systems, there are many bottlenecks in systems engineering, testing, compliance, and integration. That is where AI can have a greater impact than simply writing individual lines of code faster.
Practical examples from her presentation included:
- Backlog of requirements. AI generates initial backlog structures and acceptance criteria based on requirements. This is helpful because, in practice, acceptance criteria are often vague.
- Models. Teams have SysML v2 generated and import the result into tools such as Cameo or Enterprise Architect. They no longer start from scratch in the tool.
- Trade Studies. Several agents evaluate different architectural variants using the same context. This does not replace engineering judgment, but it does reduce the amount of preliminary work.
- Compliance and Documentation. AI supports evidence gathering, threat analysis, and document management. The value is realized only when the results are linked to traceability and testing.
A second benefit is language. AI translates between disciplines. Anyone talking to an electrical engineer about an interface can have the problem explained in the engineer’s language. The tools face the same problem. CAD, MBSE tools, test systems, and repositories rarely speak the same language.
That is why AI belongs on the digital thread, not alongside it.
Traceability as a Byproduct
Robin also clears up a misconception regarding agility. Being agile in safety-critical systems does not mean deploying every 11 seconds, like Netflix does. Air traffic control, aviation, and defense require formal testing, certification, and verification. Agility and regulation are not mutually exclusive; they simply require different pipelines.
Such a pipeline connects requirements, the backlog, tests, and the repository. Requirements are stored, for example, in DOORS or Jama. The backlog is linked to them. Tests are linked to the backlog. Commits in the repository reference the user story. The pipeline establishes bidirectional traceability between these elements.
No one maintains these traces by hand.
This makes traceability a byproduct of the work. It doesn't arise as a last-minute cleanup effort right before the audit. It arises because normal work leaves the right traces.
That is the difference between documented control and operational control. Documented control explains later what was supposed to have happened. Operational control makes it clear what is happening right now.
Skills Instead of Roles
Skills instead of roles: According to Robin, this is the essence of systems engineering. SpaceX According to Robin, he told NASA, in essence, that all the engineers there are systems engineers. That doesn't mean there's no such thing as systems engineering. It means that systems thinking isn't locked away in a silo called "systems engineering.".
Established companies bear a special technical responsibility in this regard. They have become accustomed to their organizational charts. Teams model, plan, and deliver according to this structure. Then they are surprised that the architecture exhibits the same inconsistencies.
The Inverse Conway Maneuver That's exactly where it comes in. Teams are organized based on the desired system architecture, not along the lines of existing functional departments.
For Capability Threads, this means: A team needs the skills to build and test the thread. It doesn’t need to have all specialists in the same room at all times. However, it does need to take responsibility for an integrated capability. Otherwise, the thread remains a coordination task between silos.
Trust Lies with Engineering, Not AI
AI does not change the responsibilities of engineering, but it shifts the focus of where engineering needs to look more closely.
Robin distinguishes based on risk. For document-related work, “Human on the Loop” is often sufficient. A human reviews the results. For safety-critical decisions, “Human in the Loop” is required. A human decides which proposal is valid. Much of the work remains “Human Assist.” The AI provides support, but the human is in charge.
This is crucial for safety cases. Robin supports the use of AI artifacts in safety cases, but only if they are validated. Small steps. Repeated verification. Traceable development. No mysterious blocks of text emerging from the fog of the model.
Her central thesis is the connection between AI and formal methods. AI provides speed and language. Formal methods provide traceability, reproducibility, and verifiable properties. For safety-critical systems, a plausible text is not enough. The system must provide sound reasoning.
This makes “fast versus secure” the wrong comparison. Speed and security don’t come from courage. They come from a pipeline that integrates, tests, ensures traceability, and provides verification early on.
Conclusion
Robin does not question MBSE. She questions the traditional version of MBSE. Functional chains are not enough if they only structure models. They must structure delivery work. Only then do they become capability threads.
In practice, this leads to the following procedure:
- Choose a feature that matters for the product.
- Weave a thin capability thread through requirements, the model, software, hardware, testing, and verification.
- Assign a cross-functional team to be responsible for this thread.
- Make integration and feedback a priority from the start.
- Use AI where it speeds up the process, not just to make a single silo more productive.
The connection to Product Velocity The key lies right here: Speed isn't achieved by increasing output in individual functions. Speed is achieved when less work gets bogged down at the transitions.
Automotive MBSE has identified the right structural pattern using functional chains. The next step is more challenging: The pattern must be transferred from the model to the delivery organization.
