Ivory Tower Modeling with MBSE
There are many ways on how to do Model Based Systems Engineering (MBSE) wrong. One of the problems I often see in the field is what I call Ivory Tower Modeling.
What is MBSE?
Traditionally, product development is using documents for capturing the product description. These includes requirements, blueprints, test plans and the like. Even if these documents are stored digital (e.g. Word, PDF, etc.), they are meant to be read by humans.
Model Based Systems Engineering (MBSE) is a more formal approach to product development. The product description is captured in well-defined items that follow a formalism.
Why MBSE?
This formalism can help to manage the complexity of systems. For instance, you can model the interface between two components. Your modeling system can warn you if the interfaces are incompatible.
Why is MBSE difficult?
MBSE is hard for a number of reasons:
- Practitioners need to learn the modeling language used. SysML is one of the more popular generic systems modeling languages. There is often resistance to learning something new. Especially, if the benefits will not be apparent right away.
- It’s easy to get it wrong. At first glance, SysML looks like “Boxes and lines”. But there are two problems: First, there are different boxes and lines, and they all have a clear semantics. Second, the diagram is just a view on the model, which is hard for beginners to comprehend.
- The language is not enough. Just because you know English, you can’t necessarily write a novel. Likewise, just because you know SysML does not mean, that you can build and structure a maintainable, useful systems model. You need to learn and understand methods as well.
Ivory tower modeling
And this is why so many things can go wrong.
Often, you have a team with one team member who is a huge fan of MBSE. And often, this person is smart and actually “gets modeling”. If this person does not understand the needs of the team, she may become a “delusional architect”, building an ivory tower model.
Typical problems of delusional architects include:
- They try to model everything from the start: From top to bottom (down to the last screw) and from left to right (accommodating product lines and designing everything for reusability from the start)
- They use every feature that the modeling language supports: This is overwhelming for the team. Most of the time, you’re much better off starting with a small subset of the modeling language.
- They focus on structure, not process: Especially inexperienced architects attempt to model the system as a static entity. But every system is evolving. The structure of the model must take change into consideration from the beginning. Otherwise, nobody will dare to make any changes. And this will result in an outdated model very quickly.
- They ignore value on management / strategic level: Organizations create value. Delusional architects often only think about the value of the model for themselves, and maybe the team. But they often ignore what needs to be done for the value to materialize (e.g. training). They often cannot articulate the value for management or leadership.
- They don’t get funding and management buy-in: MBSE is not cheap. Tools are expensive, teams must be trained, the development environment must be tailored. This is next to impossible for a single delusional architect. Without proper funding and management buy-in, the effort will fizzle.
What to do?
That will be answered in a future a future blog. In the meantime, here are a few ressources for futher reading:
