The SysML v2 Window

On June 30, 2025, the Object Management Group formally adopted SysML v2 — the first ground-up rewrite of the systems modeling language since 2007. Specifications followed in September. Twenty-four tools now claim some form of conformance. A working API server. A Git-friendly textual notation. A federated repository pattern that promises, finally, the single source of truth that two decades of MBSE marketing kept advertising. The standard is real. The vendors are racing. The blog posts are flowing. And if you talk to the systems engineers who actually do the work, almost none of them are excited.

That mismatch is worth taking seriously. The new standard is genuinely better than what came before. The repository model is conceptually elegant. The API will eventually enable workflows the v1 tooling could not. None of that is in dispute. But the engineers in the trenches keep noticing that the things v2 fixes are not the things they were stuck on. The standard solves the problems engineering teams had ten years ago. The problem they have today is somewhere else entirely.

The Federation Layer Is Real

For most of MBSE's history, models lived inside the tool that authored them. Cameo MagicDraw stored models in proprietary formats. Rhapsody used its own. Exporting from one to another required brittle bespoke connectors that lost fidelity at every step. When organizations tried to connect requirements (DOORS), architecture (Cameo), analysis (MATLAB), and verification (Polarion) into a coherent digital thread, what they got was a quilt held together with translation tape. A MathWorks survey published earlier this year found that 94% of aerospace and defense engineers identified tool interoperability as one of their biggest workflow challenges. That number is not a marketing prop. It is a category-defining problem.

SysML v2 takes a real swing at it. The specification defines a RESTful API for exchanging model data, a repository pattern for centralized storage with versioning, and a textual notation that makes models diffable in ways the old graphical-only format never was. The vision is federation: requirements live in one tool, architecture in another, analysis in a third, and they all read from and write to a common repository that maintains the relationships between them. Trace links survive tool boundaries. A change in one place ripples through queries everywhere else. The single source of truth becomes a queryable graph instead of a folder of disconnected exports.

This is good. The vendors converging on this pattern — MathWorks, Dassault, IBM, the open-source efforts at OpenMBEE and SysON — are doing real work. The 2024 SysML v2 Extravaganza demonstrated multi-vendor data exchange against a working API server. Within two or three years, an enterprise that bets on the v2 stack will have meaningfully better lifecycle interoperability than they could get today. If your problem is integrating five existing MBSE tools into a digital thread, v2 is genuinely the answer you have been waiting for.

Repositories Don't Make Models

Here is the hole in the story. Federation is a downstream problem. It assumes models exist in the first place. It assumes that, somewhere upstream, an engineer sat down at a tool and authored the architecture, the requirements, the interfaces, the behavior. The v2 standard makes those models easier to share. It makes them queryable, traceable, evolvable across tools. What it does not change — at all — is the act of creating them.

And the act of creation is where MBSE has been stuck for two decades. Cameo costs $2,500 per user per year and takes months to learn. Rhapsody is no better. Polarion is no better. The reason MBSE adoption is flat at around 5% of organizations is not that the existing tools fail to exchange data well — it is that most engineers will not author into them in the first place. The learning curve is too steep. The interface is too complex. The cost is too high. The feedback loop is too slow. When the systems engineering team builds a Cameo model in isolation while everyone else works in CAD and spreadsheets and Confluence, the model becomes a parallel artifact instead of a shared one. Federation does not fix that. Federation cannot fix that.

The Conversation Underneath the Vendor Posts

The most useful signal on what v2 will and will not do for MBSE adoption is not in the OMG specification. It is in the comments under the vendor blog posts — the practitioners who have been living inside this problem for years and who responded to the latest round of v2 evangelism with measured, technically grounded skepticism. Two threads are worth pulling out.

Read those carefully. The first one names the structural condition under which heavyweight MBSE tooling actually works — a small centralized team operating as a service — and the structural condition under which it does not — broad distribution to engineers who will not invest in a steep tool. The argument is not anti-MBSE. It is anti-misfit. The methodology is fine. The interface needs to match the user.

The second draws a distinction the standard's marketing tends to blur: an API for object-oriented lifecycle versioning is not the same thing as an authoring environment. They serve different concerns. Git works for line-oriented model authoring because authoring is iterative, conflict-prone, and benefits from cheap branching. The v2 API works for lifecycle exchange because exchange is structural, schema-aware, and benefits from a service-oriented contract. Both can be true. Neither replaces the other. The practitioner is naming the gap politely, but it is the same gap.

What This Moment Actually Opens

The interesting thing about a standards reset is that it forces organizations to re-evaluate. For fifteen years, the answer to "what MBSE tool should we use?" was Cameo, with Rhapsody as the runner-up. Now every enterprise architect is being asked which v2-compliant stack to adopt, on what timeline, with what migration plan from v1. The procurement conversations are open. The vendor relationships are unfrozen. The default has moved from "stick with what we have" to "evaluate everyone."

For a new entrant, that is the window. Not because the new entrant has to win on v2 conformance — most enterprises will adopt the v2 stack from incumbents who have been promising it for years and finally have something to ship. The window is for the layer the incumbents are not addressing. If federation is the lifecycle layer and authoring is the bottleneck layer, the way to enter the market is not to build a better Cameo replacement. It is to build the on-ramp that gets engineers authoring in the first place — and exports cleanly to whatever federated repository the enterprise eventually picks.

This is not a knock on the v2 vendors. They have a different job. Cameo, Rhapsody, System Composer, the open-source efforts — they are serving the existing systems engineering teams who already author MBSE models and need better lifecycle infrastructure. That market exists. It is real. It is shipping. And it is also a small fraction of the engineers who would benefit from systems thinking if the tooling met them where they actually work.

The right read on SysML v2 is neither hype nor cynicism. The standard does what it says: it makes federation real. The vendors building toward it are doing necessary work. The lifecycle problem they are solving has been waiting for a solution since the 1990s. None of that is reason to discount what is happening. But the people closest to the problem keep saying the same thing: the bottleneck for most engineers is not how their model exchanges with other tools. The bottleneck is whether they can build the model at all.

That is the layer where the next era of MBSE will be decided. It is the layer the standards reset cannot reach on its own. And it is the layer where Cairn was built to live.