Every few years INCOSE publishes a document meant to tell the field where it's headed, and every few years most practicing engineers skim the executive summary, nod, and go back to whatever tool they were fighting with that morning. Systems Engineering Vision 2035 deserves better than that treatment, not because it's a standard you have to comply with, but because it's one of the few places where the whole community, tool vendors, standards bodies, and the practitioners actually building systems, agreed on a shared direction. The question worth asking isn't whether the vision is right. It's what a systems engineer sitting in a program review in 2026 is supposed to do differently because of it.
What the vision actually claims
The core sentence is blunt: by 2035, systems engineering will be largely model-based, using integrated descriptive and analytical digital representations of the system instead of documents. INCOSE builds the case for that claim across four chapters, laying out the global pressures pushing toward it (rising complexity, cyber-physical systems, AI-enabled autonomy, sustainability demands), the current state of the discipline (uneven maturity, document-heavy practice still dominant in most industries), and a roadmap of recommendations aimed at tools, people, and research.
None of that is surprising if you've been paying attention to where SysML v2, digital thread tooling, and AI copilots have been heading. What's useful about the vision isn't the prediction, it's that INCOSE names the gap explicitly instead of pretending the industry is further along than it is. Chapter two is refreshingly candid: basic systems engineering practices apply everywhere, but maturity varies enormously between a mature aerospace prime and a mid-size industrial equipment manufacturer just starting to formalize requirements management.
The three things the roadmap actually asks for
Strip away the framing and the recommendations cluster into three concrete asks, and each one maps to something a team can act on this year rather than by 2035.
- Tools and methods: mature model-based practices, get the digital thread actually connected instead of manually stitched, and build toward digital twins that link the as-designed model to the as-operated system.
- People: build a workforce with model-based skills alongside the softer collaboration and leadership skills needed across globally distributed teams, and treat that training as continuous rather than a one-time certification.
- Research and standards: keep developing the digital engineering standards the vision depends on, which is exactly the lane SysML v2, KerML, and the Systems Modeling API and Services occupy since their 2025 finalization.
That progression is the useful part to internalize. It's not "adopt SysML v2 and you're done." It's a sequence, and skipping steps is where most MBSE adoption efforts stall. A team that buys a modeling tool without first getting its requirements and architecture practices in order ends up with a pretty diagram that nobody trusts more than the spreadsheet it replaced.
Where 2026 practice already lines up
Some of this isn't aspirational anymore, it's happening. SysML v2 landed as a finalized OMG standard in mid-2025, and tool vendors have spent the year since shipping support for it. Dassault's Cameo Systems Modeler and Eclipse Capella both continue as the incumbent modeling environments most large programs already run on, while newer SysML v2-native platforms such as Dalus were built around the new language and its API from the outset rather than adding it as a layer on top of SysML v1 infrastructure. AI copilots for requirements quality checking are shipping in production tools today, not as a research demo. None of that was true when INCOSE published the prior vision a few years earlier, and it's a real signal that the model-based direction isn't just wishful thinking.
Where the gap is still wide
The honest counterpoint, and INCOSE's own chapter two makes this case better than any outside critique could, is that most organizations are nowhere near "largely model-based." Document-centric requirements management is still the default in a lot of regulated industries, not because engineers don't know better but because switching costs are real: retraining a workforce, migrating legacy model libraries, and rebuilding supplier data exchange around a new toolchain takes years and budget most programs don't have set aside for it. The vision's own workforce chapter admits that the competencies needed for a fully model-based, AI-augmented practice barely exist in most current systems engineering curricula.
Enterprise-wide digital transformation is the harder goal, and it's the one most exposed to reality. A connected digital thread across requirements, architecture, simulation, and test isn't a tooling decision alone, it's an organizational one, and most enterprises are still negotiating who owns which segment of that thread and which tool is authoritative for what.
What it won't solve
A few things worth being clear-eyed about before treating the vision as a plan rather than a direction:
- It's not a standard, and nobody is auditing you against it. Nothing forces adoption, which is exactly why so many organizations read it and change nothing.
- It doesn't resolve tool fragmentation. Naming "integrated tool chains" as a goal doesn't make Cameo, Capella, and a dozen requirements and PLM tools interoperate any better today than they did before the document was published.
- The workforce gap is bigger than the tooling gap. You can buy a SysML v2-capable tool this quarter. Building an organization-wide base of engineers fluent in model-based practice takes years, and most training programs are still catching up.
- Sustainability and societal value as design drivers sound right and are hard to operationalize. The vision elevates them as first-class concerns, but turning that into a measurable requirement in a system model is still an open practice question in most domains.
Bottom line
Vision 2035 is worth reading, not for the prediction that systems engineering will be model-based by 2035 (most people in the field already believed that), but for the roadmap structure underneath it: tools, people, and standards, moving in that order of urgency for most teams. If you're a practicing systems engineer trying to decide where to spend limited training and tooling budget this year, the vision's honest answer is to shore up model-based fundamentals and requirements discipline before chasing the AI-augmented end state, because the connected digital thread INCOSE describes for 2035 only works if the model underneath it is trustworthy today.