MBSE: Modeling Before Systems Exist

What is MBSE?

Model-Based Systems Engineering (MBSE) promises to bring clarity and structure to complex systems development. In practice? It often turns into a maze of diagrams, locked files, and terminology so dense it needs its own glossary. The model is usually built in a tool so arcane only one person can use it—who's inevitably on vacation when you need them most.

Core Principles (Unwritten, but Deeply Followed)

• Tool worship—If it’s not in Cameo, Capella, or MagicDraw, it didn’t happen. If it breaks the model? Well, that’s clearly user error.
• Model early, model often—even when the system’s not defined. It’ll sort itself out later on during V&V, right?
• Access denied—Collaboration is the dream, but getting read permissions requires three signatures and a blood sample.
• Traceability theater—Links exist. Somewhere. Probably in Excel or with PowerPoints Duck Taped to some Scrum Master's Jira board.
• Semantic gymnastics—Every review involves the same question: “What does this block actually do?” Still waiting on an answer.

Typical Roles on the MBSE Front

• Model Architect – Master of complex diagrams, sometimes useful. He is the only person that sees the bigger picture and is quietly dying inside watching some PM ruin it for the sake of EVM.
• Data Integrity Lead – Guardian of cryptic naming conventions and questionable link logic. He will likely tell you that things would be better if we used DoDAF.
• Security Czar – Ensures the model is more restricted than the launch codes.
• Reviewer #3 – Declares, “This isn’t the real system,” without further elaboration.
• Subsystem IPT Cognizant engineer- Hates MBSE with the fire of a thousand suns. Believes (knows) it's extra overhead, prefers to work in CAD, and treats the model like a bureaucratic obstacle to real engineering.
• Suspicious Customer – Doesn’t get the model, suspects it's hiding something, and always asks: “Can this go in PowerPoint?” and “What am I paying for again?”

The DOORS Dilemma

Despite all the talk about modernization, many MBSE teams still cling to IBM DOORS like it’s a family heirloom.

They’ll do anything except put the requirements directly into the model:

• Export to Excel? Every week.
• Bridge tools with undocumented scripts? Absolutely.
• Maintain a separate mapping document no one reads? Standard procedure.

Put requirements in Cameo?

“There is no way it will work, Cameo is not made for requirements.”

DOORS is considered “heritage,” which translates to: “If we change it, the whole program might implode.”

So requirements live in one place, the model in another, and actual understanding in a third—usually someone’s head.

Frequently Avoided Questions

Q: Can we collaborate? A: In theory, yes. In practice, only if your team has a full-time Team Work Cloud (TWC) whisperer who speaks RDF, SPARQL, and ancient configuration magic.

Q: Shouldn’t this model be open for collaboration? A: Technically yes. Practically? Good luck getting access to TWC—SEIT will guard the access like it’s the nuclear football. Some companies require specific training before human eyeballs are allowed to gaze upon the model for comment.

Q: Are requirements traced to model elements? A: If you count post-it notes and memory, then absolutely. DataHub is just an metadata urban legend in most cases.

Q: Is this useful for integration or verification? A: Sure. On paper. In the real world? For the model to be useful for integration, one would need to verify "the one source of truth", right?

Final Thoughts

MBSE has enormous potential, but too often it becomes a check-the-box exercise disconnected from the actual engineering effort. It’s a powerful idea stuck in an execution loop, held hostage by legacy tools, silos, and over-complexity.

That said, it looks fantastic in slide decks, earns nods from leadership, and makes us feel aligned with “best practices."

When in doubt, just add another block. Label it “TBD.” Call it progress.