How not to do MBSE

An Invitationt to use architecture as the tool and not accept it as is.

Automotive Software Process Improvement and Capability Determination, in short ASPICE.

As the name suggests, ASPICE is there to determine the capability of a software development process. ASPICE has the reputation of being about documentation. So when people hear they have to fulfill a certain ASPICE level, all they hear is that they have to document their every move.

Additionally, ASPICE requires you to think about the architecture beforehand, develop different architectural solutions, compare them, and choose one. This shifts the focus toward architecture and takes time.

So when it was my turn to create a comprehensive architecture, after interviewing different department heads and sitting at my desk in the middle of an open-plan office, I suddenly felt my manager breathing down my neck, asking me why I was wasting time on architecture and hadn’t built anything yet.

To which I replied:

“If you are complaining about the cost of good architecture, do you know how much no architecture costs?”

Situations like this follow me wherever I go.

Another situation was when a function owner didn’t know where their component lived in the system architecture. They owned it on paper but couldn’t see it in context.

Or when I played charades with a different function owner. While we were creating the system architecture, I asked them what one of their signals was called. Their answer wasn’t a name, nor was it “I don’t know.” It was:

“I think.”

The second function owner had just enough visibility to assume they understood. Just enough knowledge to feel confident.

The result in the first case? The model changes, decisions get made in isolation, and people don’t know. Communication flows shift, and no one updates their mental model.

The second function owner made decisions based on incomplete information. Integration then revealed surprises that should have been visible in the architecture from day one.

This is where Model-Based Systems Engineering (MBSE) comes into play: an approach that places systems engineering artifacts into a model, using SysML as the de facto standard language to visualize the system architecture.

Everything in the development process is based on the architecture. Therefore, I am convinced that the time spent creating a good architecture is worth it.

It costs far more time to figure out decisions that were made without a shared architectural understanding, but those costs are rarely accounted for because people are busy building hardware or software. The additional iterations, the extra engineering effort, and the missed deadlines are often treated as separate problems instead of consequences of not having a shared architecture.

The upfront investment, however, is highly visible. It takes longer before the first element of the system architecture is created.

Which is why my manager was breathing down my neck.

Additionally, SysML has its own syntax and semantics, which means you can fully describe a system. But, like every language, it requires fluency—both to create the architecture and to understand it. Neither function owner was fluent in the language, which became obvious through their lack of understanding of the architecture.

Lastly, I want to show you a third function owner. The one who openly says:

“I’ve heard that term once, during a training session last year, and haven’t touched the architecture since.”

Now I come in to update the architecture, but I also have to explain why I am doing things a certain way - the same way they had been done for the past year.

For this function owner, integration doesn’t come as a surprise. What they see are updated names they no longer like, even though they previously approved them without really understanding what those names represented.

What we have here are a few examples of the archetypes you encounter when introducing a new tool, a new process, or even a new modeling guideline.

I call them archetypes because they are recurring patterns. These types emerge, in one form or another, whenever something new is introduced into an existing way of developing systems.

MBSE is becoming increasingly important in Germany and across European industry. It is intended to help manage the growing complexity we continue to pour into our systems.

However, MBSE also requires a change in thinking and in human behavior. Because of this, it initially seems harder to implement. There is an upfront investment in teaching and training.

Furthermore, that knowledge needs to be cultivated. A training session once a year isn’t enough. Neither is owning a component you can’t locate. Or approving a signal name you can’t define.

As I said before, SysML is a formal language. It requires fluency to both read and write the architecture.

My manager wasn’t wrong to notice a cost. He was looking at the wrong one. He saw the price of creating a good, agreed-upon architecture. He never saw the price of not having one at all.

The same way we learn to read is by reading. The same way we become fluent in architecture is by reading it, using it, and understanding it—step by step.