15 years of software development without formal architecture: why that could change now

I have a confession to make: in 15 years of software development, we have practically never created a fully specified, formal software architecture for our internal projects.

Of course there was architecture. There were whiteboards, PowerPoint slides, diagrams and plenty of discussions. But a consistently specified, coherent and maintained architecture model, the kind you know from classic development methods?

Not a chance.

A calculation that didn’t add up

And there was a good reason for that: it simply wasn’t worth it economically.

We weren’t subject to any regulation that would have forced us to do it. So we were free to weigh costs against benefits.

The costs were obvious: creating a formally correct architecture model and maintaining it continuously can take about as much effort as the implementation itself.

The benefits were harder to pin down: better communication, early detection of architecture flaws, options for formal verification and, of course, compliance.

In agile development in particular, this creates a fundamental problem: an architecture that doesn’t evolve with the code loses value with every change. Correct yesterday, outdated today. Increasingly misleading as a means of communication, unreliable as a basis for verification.

A model that doesn’t grow with the code doesn’t describe the system. It describes how the system was once intended to be.

So for our internal projects, we chose the pragmatic route: from requirement straight to code. Architecture decisions were made, discussed and implemented, but rarely fully formalized.

Documented doesn’t mean up to date

Our customers live in a different world.

They come almost exclusively from regulated industries. There, architecture models, traceability and documented development processes are often indispensable.

But let’s not kid ourselves: just because an architecture is documented doesn’t mean it describes the actual implementation.

In practice, requirements, architecture models and implementation often evolve in parallel, side by side. And shortly before the next audit, a lot of effort goes into connecting everything through traceability, so that the gaps are as invisible as possible. After all, traceability has so far mostly been quantitative evidence, rarely qualitative.

The actual engineering knowledge rarely lives in the models. It lives in the developers’ heads and in the implementation.

The documentation exists, but there is a delta.

MBSE was never a promise of speed

As advocates of Model-Based Systems Engineering (MBSE) and model-driven development, our argument has therefore always been:

“If you have to build the model anyway, build it so that it’s actually useful to you!”

Derive FMEA and TARA from the model. Generate code. Traceability by design.

The idea: more engineering in the model, less manual work in downstream process steps. Whatever can be derived deterministically doesn’t need laborious manual maintenance.

Technically, this works well. Economically, only to a degree.

To reap the benefits, the models have to reach a level of quality and detail that is enormously expensive to maintain. That has to pay off.

Development usually doesn’t get much faster. You just reach a defined level of quality more reliably, detect errors earlier and reduce the effort for assessments.

That is valuable. But under cost pressure in particular, it isn’t always visible enough to justify the investment.

MBSE was never a promise of speed. It was a promise of quality. And quality is hard to weigh against delivery dates.

Two developments are now fundamentally changing this calculation: the CRA and AI.

1. The Cyber Resilience Act changes the benefit

The Cyber Resilience Act requires manufacturers of affected digital products to deliver not only security at the time of shipping, but also documented risk management, technical evidence and effective vulnerability handling across the entire lifecycle.

So it is no longer enough to document the architecture just well enough to get through the assessment once.

If a critical vulnerability shows up in a component tomorrow, I need to know which products are affected, where the component is used, which dependencies exist and which measures are required.

An up-to-date architecture model linked to the implementation thus turns from a tedious documentation chore into an operational tool.

The CRA doesn’t prescribe this, but it makes a considerable difference whether I need a system model once for the assessment or every other day for risk assessment.

One-off evidence becomes critical infrastructure.

2. AI and SysML v2 change the cost

At the same time, large language models and the textual syntax of SysML v2 open up an entirely new way to create and maintain architecture models.

LLMs can generate structured model drafts from requirements and existing implementations. The formal language definition of SysML v2 makes it possible to check these models automatically for syntactic correctness and defined semantic rules.

Suddenly, modeling becomes, to some extent, what we know from modern software development: text-based, automatable, versionable and integrable into continuous development processes. Model as code!

Of course, a syntactically correct model doesn’t guarantee a correct architecture. And AI doesn’t replace engineering decisions either, but it can drastically reduce the manual effort for formalization and maintenance.

The most expensive part of a model was never creating it once, but keeping it up to date every day.

More benefit, less effort

I am convinced that MBSE leads to better products, and for the first time I see a chance that it will also pay off measurably.

With the CRA, the value of current, traceable architecture information grows with every day, and across the entire product lifecycle.

On the other hand, AI and SysML v2 lower the cost of capturing, checking and maintaining this information formally.

More benefit. Less effort. And what about communication?

Formality and communicability pull apart

Our whiteboards and slides were, of course, never formal. They were what people actually communicated about. A few boxes, a few arrows, and everyone in the room knew what it was about: development, product management, management, customer.

A formal model doesn’t do that. The more precisely it is specified, the more it assumes that you speak its language. Textual SysML v2 is readable by humans. But not by all humans.

The more precise a model becomes, the smaller the circle of people who understand it.

Formality and communicability fundamentally pull apart. One serves the machine, the other serves people. Anyone who has a formal architecture actually has two: the precise one in the model and the understandable one on the slide.

With exactly the drift we described above between model and implementation.

The same synchronization problem. Just one level up.

AI and SysML v2 don’t solve it. They make formal models cheaper, but not more understandable. If anything, the opposite: when models are created faster and in more detail, the gap to the people who need to understand them grows.

The answer can’t be that everyone learns SysML v2. But it can’t be to put slides next to the model again either. The answer is to generate understandable diagrams and views directly from the formal model. That’s why we built itemis PRISM.

MBSE at itemis — from formal SysML v2 models to views everyone involved can understand: Systems Engineering →