The Maturity Myth: Why Nobody Knows Where They Are

Ask an organization how mature their MBSE practice is. You’ll get one of three answers.

“We’re early.” This usually means they bought a tool, trained some people, and built a model for one project. Maybe two. The model was useful for a design review and then slowly went stale.

“We’re making progress.” This usually means they’ve deployed MBSE across multiple programs, have a small team of resident experts, and are fighting daily battles over tool adoption, integration, and whether the model actually saves time or just creates more work.

“We’re mature.” This is the rarest answer, and in our experience, it’s almost never accurate. What organizations call “mature” is usually “we’ve been doing this for years” - a statement about duration, not capability. Time in the saddle isn’t maturity. You can ride a horse for twenty years and still not know dressage.

The real answer to “how mature is your MBSE practice?” is almost always: nobody knows. And that’s the problem. This is Part 4 of The MBSE Reckoning.

The two-sided crisis

The maturity problem isn’t just an organizational challenge. It’s a crisis on both sides of the vendor-customer relationship, and each side makes the other worse.

The tool builder’s problem

Talk to the people who actually build MBSE tools - not the executives, not the sales team, the engineers and product managers in the trenches - and you hear a consistent set of frustrations:

No product direction. Teams build features without a clear understanding of what the product is trying to become. There’s no architectural vision that says “this is what the tool looks like at maturity, and here’s how we get there.” Instead, there’s a backlog of feature requests driven by the loudest customer, the latest RFP requirement, or whatever the competition just shipped.

No acceptance criteria. Features ship without a definition of done. There’s no specification that says “this feature is complete when a user can accomplish X, Y, and Z without assistance.” The result is features that are technically present but practically unusable - checkbox items that exist in the release notes but not in anyone’s workflow.

No roadmap to maturity. There’s no staged plan for how capabilities evolve. Version N has partial SysML v2 support. Version N+1 has… more partial SysML v2 support? What’s the end state? What does “complete” look like? Nobody knows, because nobody has defined it.

Constant direction changes without communication. Strategic priorities shift quarterly - sometimes monthly - without explanation. The team that spent six months building a collaboration feature learns it’s been deprioritized in favor of an AI chatbot because a competitor demoed one at a conference. The collaboration feature ships half-finished. The AI chatbot ships half-finished. Neither works well enough to change anyone’s workflow.

This is a product management crisis. The gap between what leadership thinks has been built and what actually works is enormous. And practitioners pay the price: they adopt a tool based on a promised roadmap, and then watch that roadmap dissolve into a series of incremental, disconnected releases that never cohere into a usable product.

The adopter’s problem

The organizational side of the maturity crisis is equally painful.

MBSE initiatives are typically launched with bold ambitions: “We will become a model-based organization.” But the ambition comes without a map. There’s no assessment framework that tells the organization where they are. There are no waypoints that define what “better” looks like. There’s no exit criteria for each maturity level that lets them say “we’ve achieved this, now we’re ready for the next step.”

SysML v2 makes this worse, not better. The transition from SysML v1 to v2 isn’t an upgrade - it’s a fundamental shift. New syntax. New semantics. New tool support (or lack thereof). New workflows. Organizations that have spent years - sometimes a decade - building SysML v1 models and training SysML v1 practitioners are told they need to start over. But nobody provides a migration path.

What does “adopt SysML v2” actually mean in practice? Do you migrate your existing models? Do you start fresh? Do you run v1 and v2 in parallel? For how long? At what cost? With what tool support? The specification is published, but the practice guidance is almost nonexistent. As one analysis put it, “successful MBSE adoption is about outcomes, not syntax” - but nobody has defined the outcomes.

The result is organizations that adopt MBSE based on mandates - contractual requirements, leadership directives, industry pressure - without a framework for measuring whether the adoption is actually working. They can tell you they use MBSE. They can’t tell you whether MBSE is making them better at building systems.

The speed paradox

There’s an accelerant making the maturity crisis more visible: AI-powered development tools.

When coding assistants can generate implementation 3-5x faster, the bottleneck shifts upstream. Suddenly, the limiting factor isn’t “how fast can we build it?” but “do we know what to build?” and “have we agreed on why?”

For MBSE tool vendors, this creates a new problem. The AI acceleration that speeds up feature development also exposes the product direction vacuum. A team can now implement a feature in days instead of weeks. But if nobody has defined what “done” looks like for that feature - if there’s no acceptance criteria, no user validation, no integration test with the rest of the product - then you’ve just shipped bad features faster.

Speed without direction is just velocity toward the wrong destination. And in the MBSE tooling market, many vendors are running very fast in directions they haven’t clearly defined.

For adopting organizations, the speed paradox manifests differently. AI tools promise to make MBSE more accessible - generate model elements from natural language, auto-detect traceability gaps, flag quality issues in requirements. But these capabilities layer onto a practice that may not have solid foundations. An AI that generates SysML elements is only useful if the organization has a modeling methodology that makes those elements meaningful. An AI that detects traceability gaps is only useful if the organization actually acts on the findings.

AI amplifies your maturity level. If you’re mature, AI makes you better. If you’re not, AI makes you faster at being confused.

What a maturity framework actually looks like

The MBSE community isn’t without maturity models. Academic literature and organizations like INCOSE have proposed assessment frameworks. But most of them are abstract - they describe maturity in terms of organizational capabilities without telling practitioners what to do on Monday morning.

Here’s what a practical maturity framework needs:

Phases with clear boundaries

Not a continuous spectrum. Discrete phases with names, definitions, and entry/exit criteria that an organization can point to and say “we’re here.”

Phase 1: Foundation. You have a tool. You have trained practitioners. You can build a model that captures basic system architecture - blocks, relationships, requirements. The model is useful for design reviews. It exists alongside traditional artifacts but doesn’t replace them.

Exit criteria: At least one project has a system model that was used in at least one design review. At least five engineers can create and navigate the model. The model captures the top two levels of the system architecture.

Phase 2: Integration. Your model is connected to at least one other data source - requirements database, test management tool, or risk register. Changes in one system are reflected in the other within a defined time window (not “eventually” - within hours or days). The model is used for ongoing engineering decisions, not just milestone reviews.

Exit criteria: At least one bidirectional integration is operational. Model data has been used to make at least three engineering decisions that would have been made differently (or not at all) without the model. Synchronization latency is measured and under a defined threshold.

Phase 3: Operational. The model is the primary source of truth for system architecture. Multiple roles access the model - not just systems engineers, but test engineers, safety analysts, program managers. Model-derived artifacts (requirement specifications, interface documents, test plans) are generated from the model, not maintained separately.

Exit criteria: At least three roles use the model regularly (weekly or more). At least two artifact types are generated from the model rather than maintained independently. The model is version-controlled with a defined change management process.

Phase 4: Continuous. The model participates in continuous assurance. Requirement quality is checked automatically. Traceability coverage is computed in real time. Risk assessments update when the architecture changes. Verification status is visible at any moment without running a report. The model is an operational system, not a documentation artifact.

Exit criteria: At least two automated quality checks run against the model. Coverage metrics are live. The organization can answer “what is the current verification status of subsystem X?” in under five minutes from the model, not from a status meeting.

Measurable progression

Each phase should have metrics that tell you whether you’re actually progressing, not just spending more time:

Model coverage: What percentage of the system architecture is captured in the model?
Integration breadth: How many lifecycle data sources are connected?
Access diversity: How many distinct roles use the model regularly?
Artifact derivation ratio: What percentage of deliverable documents are generated from the model versus maintained separately?
Decision impact: How many engineering decisions in the last quarter were informed by model data?
Synchronization latency: How long does it take for a change in one system to be reflected in the model?

These aren’t vanity metrics. They’re diagnostic tools. If your model coverage is high but your access diversity is low, you’ve built a good model that nobody can use. If your integration breadth is wide but your synchronization latency is measured in weeks, your integrations are decorative.

The “SysML v2 or bust” trap

One of the most damaging patterns in the MBSE community right now is the binary thinking around SysML v2: either you adopt v2 completely, or you’re stuck on v1 and falling behind.

This is a trap. And it’s a trap that benefits tool vendors more than practitioners.

Progressive maturity beats revolution. An organization at Phase 1 with SysML v1 should not be told their next step is “migrate to SysML v2.” Their next step is Phase 2 - integrate the model with one other data source and start using it for decisions. The modeling language is secondary to the practice maturity.

SysML v2 is genuinely better than v1 in many ways. The textual notation is a breakthrough. The improved semantics for requirements and constraints are valuable. But v2 is a tool, not a destination. And adopting a new tool while your practice is immature doesn’t make the practice mature - it just adds a migration project on top of your existing problems.

The mature approach is sequential: stabilize your practice at your current maturity level, then adopt new tools and languages as your practice is ready to absorb them. The immature approach is to chase the latest specification and hope that technology solves your organizational challenges.

Technology never solves organizational challenges. It only amplifies them.

Maturity is a journey with waypoints

The word “maturity” implies a destination - a finish line you cross. That’s the wrong metaphor. MBSE maturity is a journey with waypoints. Each waypoint is a stable, useful configuration of tools, processes, and capabilities that delivers value at that level. You don’t have to reach Phase 4 to get value. Phase 2 is valuable. Phase 1 is valuable, if it’s done well.

The problem isn’t that organizations are at early maturity levels. It’s that they don’t know which level they’re at, don’t know what the next level looks like, and don’t have criteria for knowing when they’ve arrived.

Tool vendors should be providing this. They should be saying: “Here’s where our tool supports your practice today. Here’s what you need to do - not buy, do - to reach the next level. Here’s what ‘ready for the next step’ looks like. Here’s what we’re building to support you when you get there.”

Instead, vendors sell a vision of the end state - fully connected, AI-powered, SysML v2 native, real-time collaboration - and leave the customer to figure out every step of the journey alone. That’s not a product strategy. That’s a brochure.

The organizations that succeed at MBSE will be the ones that treat maturity as a discipline - with assessments, waypoints, criteria, and honest measurement. The tool vendors that earn their trust will be the ones that guide them on that journey, not just sell them the map and wish them luck.

This is Part 4 of “The MBSE Reckoning,” a 10-part series from Luvian on the state and future of Model-Based Systems Engineering.

Series navigation:

Part 1: The MBSE Reckoning - Why the Industry Is at a Breaking Point
Part 2: Your MBSE Tool Was Designed for the Wrong Person
Part 3: The Shelfware Problem - When Models Don’t Connect to Work
Part 4: The Maturity Myth - Why Nobody Knows Where They Are (you are here)

Subscribe to our newsletter to get each article as it publishes.