SVC-02 · Service
MBSE deployment and governance that survives the pilot phase
Goujon Systems helps aerospace, space and defence organisations deploy Model-Based Systems Engineering so that the model becomes the single source of truth for the program, rather than a parallel artifact that quietly drifts from the documents everyone actually uses. The work covers MBSE strategy and scope, method and tool selection (Capella/ARCADIA, Cameo, SysML v1.x and v2), modelling conventions, governance rules, toolchain integration, and the training and coaching that make adoption stick.
Most MBSE deployments do not fail on tooling. They stall between the pilot and the second program, because nobody wrote down what the model is authoritative for, who is allowed to change it, and which existing deliverable it replaces. Those three questions are where an engagement starts, and answering them is usually worth more than any tool decision.
Why MBSE deployments stall
The pilot goes well. It nearly always does: a motivated architect, a bounded subsystem, no legacy. Then the method meets the second program and stops. The reasons are consistent enough to be worth naming.
- The model duplicates the document instead of replacing it. Engineers now maintain both. Under deadline pressure, one of the two gets abandoned, and it is never the one the customer contractually requires.
- No authority statement. When the model and the specification disagree, nobody knows which one is right, so people default to the document and the model becomes decoration.
- Conventions left to individual modellers. Two architects model the same concept three different ways, and the model becomes unreadable across team boundaries, which destroys the one benefit that justified the investment.
- The tool was chosen before the method. A licence gets bought, then the organisation reverse-engineers a way of working to fit it.
- Training covered features, not decisions. People leave the course able to draw a diagram and unable to decide which diagram to draw.
- No link to the review calendar. If no review requires the model, the model is optional, and optional artifacts die the first time a schedule slips.
What a deployment includes
Sequenced so each step makes the next one cheaper. Method before tool, conventions before scale, governance before adoption.
- MBSE vision & scope: a written statement of what the model is for, which engineering questions it must answer, and, critically, which questions it is not expected to answer.
- Method & tool selection: ARCADIA/Capella, SysML with Cameo, or a hybrid, chosen against your actual constraints: existing assets, customer requirements, team maturity and integration needs.
- Modelling conventions & style guide: naming, decomposition depth, diagram set, reuse rules and what “done” means for a model element, so two architects produce comparable models.
- Model authority & governance: which artifact wins when model and document disagree, who may change what, how baselines are cut, and how model changes flow into configuration management.
- Toolchain integration: the interfaces between requirements tool, system model, simulation and PLM, defined once, so traceability is a property of the toolchain rather than a monthly manual reconciliation.
- Pilot design: a pilot on a real subsystem with real constraints and a real review date. Pilots on toy examples predict nothing and prove nothing.
- Training & coaching: modelling decisions first, tool operation second, delivered to the team on their own model rather than on a generic training example.
- Adoption metrics: a small number of honest indicators (model-referenced review items, traceability coverage, time to answer an impact question), so you can tell adoption from compliance theatre.
The real challenges of an MBSE deployment
Tool selection keeps committees busy for months. The three subjects below decide the outcome, and they are what the coaching works on first.
Understanding what MBSE actually is
MBSE is not about drawing diagrams. One or several models concentrate the program’s engineering data (functions, interfaces, allocated requirements, technical budgets) and connect it to other uses: document generation, safety and reliability analyses, simulation, verification, configuration management. That “single source of truth” position is what pays back the investment: data is entered once, exploited everywhere, and stops drifting from one document to the next. An organisation that rolls out the tool without aiming for that position ends up with an expensive drawing tool.
Training the teams
A deployment stands or falls on team competence, not on licences. Useful training covers modelling decisions first: what to model, to what depth, to answer which questions; tool operation comes second. It happens on the program’s own model rather than on a classroom example, and it takes time: a few days of coursework do not create a practice, a coached modelling cycle does.
Coaching from someone who has lived it
Between theoretical training and the reality of a program lie all the situations no course material covers: a model that diverges from the specification three weeks before a review, two teams modelling the same concept in incompatible ways, a customer demanding the document deliverable the model was supposed to replace. Coaching is only worth paying for when it comes from someone who has had to manage those situations on real programs. That is the know-how Goujon Systems brings: nearly ten years on flagship European space and defence programs, including the system architecture of ESA’s Argonaut lunar lander, and teaching Space Systems Engineering and MBSE at Master’s level at Université Toulouse III.
What about the tool choice?
It matters, but it resolves in a few weeks once scope and governance are set. Capella with ARCADIA and Cameo with SysML are both capable: they fail differently and fit different starting conditions. The full trade-off, criterion by criterion, is set out in the analysis “Capella or Cameo: how to choose the MBSE tool for your program”.
On SysML v2, the Object Management Group approved final adoption of the specification in July 2025 and launched an official certification program in June 2026: the language is no longer a moving target, and the useful question is no longer “when will it be ready” but “what does migration cost us”. Goujon Systems maintains an active partnership with Sensmetry, whose work sits directly on the SysML v2 toolchain, which is where a good deal of the practical, non-theoretical knowledge about v2 in production currently lives.
Frequently asked
Questions people ask before getting in touch
How long before an MBSE deployment delivers anything?
The wrong milestone to plan around is the tool rollout date. The right one is the first program review passed with the model as the reference artifact, because that is the moment the model stops being optional. A pilot scoped on a real subsystem rather than a toy example can reach a usable state within a single modelling cycle; organisation-wide adoption is a matter of program cycles, not weeks.
Do we have to replace our requirements management tool?
Usually not, and usually you should not. DOORS, Jazz ELM, Polarion and Valispace all coexist with a system model perfectly well provided the interface between them is defined once and enforced: which side owns requirement text, which side owns allocation, and how traceability is synchronised. Replacing a working requirements tool mid-program is a large cost charged against a small benefit.
Should we go straight to SysML v2?
It depends on whether you have existing SysML v1.x assets. SysML v2 reached final adoption at the Object Management Group in July 2025, and OMG launched an official SysML v2 certification program in June 2026, so the language is no longer a moving target. But v2 is a new language with its own textual notation and a standard API, not an incremental revision. Moving an existing model is a re-modelling exercise, not a file conversion. A team starting fresh has a much easier decision than one with three years of v1.x models in production.
Capella or Cameo: which should we choose?
Capella with ARCADIA suits teams standardising on a method for the first time, because the method is prescriptive and does much of the thinking for you. Cameo with SysML suits organisations that already hold SysML assets or need deep integration with a wider toolchain, at the cost of having to define the method yourself. The analysis “Capella or Cameo” published on this site sets out the trade-off criterion by criterion.
Who in our organisation needs to be involved?
At minimum: a system architect who will own the model, a requirements owner, and someone with the authority to declare the model authoritative over a document. That third role is the one most often missing, and its absence is the single best predictor of a deployment that stalls.
Can you train our team as well as deploy the method?
Yes, and the two are hard to separate usefully. Training that covers tool features without covering modelling decisions produces engineers who can operate the tool and cannot model. Clément teaches Space Systems Engineering and MBSE at Master’s level at Université Toulouse III and has delivered company-wide training inside a large space integrator.
Related services
Book a free intro call.
Thirty minutes, no commitment, in English, French or Italian. Tell me about the program and I will tell you honestly whether I am the right person for it.
Last updated: