Asking whether MBSE can be done in Excel will strike a seasoned systems engineer or system architect as a personal insult — almost an attack on their professional integrity, if not outright blasphemy.
It’s a bit like suggesting to a die‑hard motorsport fan — someone who lives for the deafening roar of a V8 — that they should consider buying an electric car. The reaction is predictable: a moment of stunned silence, followed by serious doubts about the other person’s mental stability.
Fortunately, such reactions are usually spontaneous and short‑lived. After all, the role of a systems engineer is fundamentally incompatible with religious attitudes toward tools or methods.
To ground the discussion, let’s take one of the shorter definitions of Systems Engineering from the SEBoK — and treat MBSE simply as a tool‑supported approach within it:
“Systems Engineering enables the realization of successful systems that meet the needs of customers, users, and stakeholders.”
For completeness, here is the NASA definition:
“Systems Engineering is a methodical, multidisciplinary approach for the design, realization, technical management, operations, and retirement of a system, with the goal of meeting requirements within cost, schedule, and other constraints.”
In short: Systems Engineering is about finding an optimal solution — optimal in the eyes of the stakeholders — under given constraints.
And “optimal” is always subjective. Evaluation is always contextual.
A family vacation, viewed as a “system,” fits this definition just as well as the architecture of an advanced driver‑assistance system.
Anyone hoping to find advice here on how to plan a stress‑free family vacation using Excel should — for the sake of the children — consider separating from their family instead. The children, much like the motorsport enthusiast above, would begin questioning the parent’s sanity long before puberty.
And for those thinking, “Well, Excel isn’t MBSE‑capable anyway! For family vacations you obviously use Cameo / MagicDraw!” — please leave your contact details. I will forward them to the appropriate child‑protection authorities.
Using Cameo, Enterprise Architect, Capella, Rhapsody, or similar tools for family vacation planning would be absurd.
But let’s flip the question:
Who has ever heard of these tools being used to design a building complex, a garden, an airport, a new train station, or in crisis management?
Most likely: no one.
Of course, specialized tools are used in all these domains — but none of them are MBSE tools, even though every one of these examples fits the definition of Systems Engineering perfectly.
Take a well‑known German infrastructure project: Stuttgart 21.
Originally planned to open in 2021, the current estimate is 2031.
The reasons for the delays are — to put it mildly — an underestimation of complexity, such as recently revealed in the digitalization of the rail hub.
In other words: requirements and dependencies were not adequately represented.
And that is exactly where MBSE aims to help: by modeling requirements and solutions, enabling structure, consistency, and transparency.
Yet none of the MBSE tools mentioned earlier are used in such projects.
So the question is: Why?
What we can say with certainty is that Excel appears in all of these domains — no matter how different they are.
So the question becomes: Why Excel?
If organizations spend enormous amounts of money on software, their choices should reveal the benefits they expect.
But these benefits seem to align far less with the textbook definition of Systems Engineering — and far more with practical realities.
To understand this, we need to look at how and where the listed tools are actually used.
A kind of reverse‑engineering approach leads us to the answer.
There is a fundamental difference between the examples above and the domains where MBSE tools are predominantly used today — automotive, aerospace, and similar industries.
The difference is visible even in language:
No one calls the earlier examples “systems.”
They are called projects. Implementation projects.
All of them are one‑off endeavors with:
- unique constraints
- unique stakeholders
- unique artifacts
- little reuse
- little formal specification alignment
- high situational dynamics
MBSE tools, on the other hand, were historically built for product‑oriented, repeatable, variant‑rich development processes.
With the exception of Capella, most leading tools rely on SysML — itself an evolution of UML, originally created for software development. SysML v2 does not change this heritage.
The SysML v2 specification currently spans roughly 1,300–1,500 pages, depending on what you count.
Even the core language specification alone is around 350–400 pages.
A one‑off project driven by communication among diverse stakeholders would run straight into a highly complex language that must first be learned.
Two more points matter:
- None of the vendors call their tools “MBSE tools.” They correctly call them Systems Engineering tools or system architecture tools. Yet many people equate MBSE with SysML diagrams — incorrectly.
- In industry, SE tools are almost never used alone. They are combined with requirements management systems, test management systems, and configuration management systems. When people associate MBSE with diagrams, the diagramming tools are perceived as the “MBSE component.”
Both assumptions are wrong.
For comparison, here is the INCOSE definition of MBSE:
“MBSE is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”
It does not mention diagrams.
It does not reduce MBSE to architecture modeling.
The moment artifacts across systems — from requirements to testing — are connected, you are operating within the MBSE scope.
Now imagine applying such a toolchain to the earlier project examples — say, airport construction or landscape design.
It would be completely unsuitable.
And yet, the INCOSE definition highlights something these projects do need:
formalized structure, traceability, and consistency.
But instead of a tool, they rely on specialized project developers who use a variety of domain‑specific tools — none of which are Cameo or similar.
Processes that must meet formal requirements are not captured in models or metamodels, but in the experience of the people involved and in past reports.
So the question of whether MBSE can be realized in Excel is not about replacing the automotive toolchain or suggesting that SysML v2 should be abandoned.
It is about the core idea expressed in the INCOSE definition.
And the question of why Excel is used across so many domains has nothing to do with “needing a spreadsheet,” just as one does not use a fork only for one specific dish.
Excel provides something far more fundamental.
Excel is a generic modeling, structuring, and communication tool — even if most people don’t consciously perceive it that way.
And before this turns into a hymn of praise for Excel:
It won’t.
This is an analysis — a reverse‑engineering exercise to understand why Excel works everywhere, and what that implies for alternative MBSE approaches.
1. Excel is ubiquitous — and instantly accessible
Excel has a level of familiarity no other tool can match. It is:
- present in every industry
- installed on every computer
- understood by every stakeholder
- usable without training
Excel creates no entry barrier.
It requires no explanation, no rollout, no cultural acceptance — it already has all of that.
In multi‑stakeholder projects, this is invaluable.
2. Excel turns everyone into a UI designer
Excel is the only tool that lets anyone create their own interface without ever hearing the word “UX.”
People can:
- build input forms
- structure tables
- define layouts
- highlight information
- use dropdowns, filters, and buttons
Excel is a visual tool that people use intuitively.
It forces no predefined perspective — it lets everyone build their own.
3. Excel unifies analysis and data flow
Excel is simultaneously:
- a data model
- a data‑flow model
- a calculation engine
- an analysis tool
- a visualization platform
Every cell is a node.
Every formula is a data flow.
Every table is a model.
Excel is — without being labeled as such —
a lightweight universal modeling tool that merges structure and analysis in one medium.
4. Excel is a freely definable metamodel container
Where specialized tools impose a fixed metamodel, Excel does the opposite:
- no predefined artifacts
- no mandatory relationships
- no fixed views
- no modeling language
- no tool dogma
Excel adapts to the project —
not the other way around.
That is why Excel works in one‑off projects,
and SysML tools do not.
5. Excel connects stakeholders who otherwise could not work together
Projects bring together people who:
- speak different professional languages
- use different tools
- think in different models
- have different responsibilities
Excel is the one tool everyone understands.
It is a universal communication medium —
not because it handles tables,
but because it requires no translation.
6. Excel is fast — and speed beats perfection
Projects depend on:
- rapid iterations
- rapid decisions
- rapid adjustments
- rapid prototypes
Excel is:
- instantly available
- instantly adaptable
- instantly extendable
- instantly shareable
No other tool is this fast.
And in projects, speed often matters more than perfection.
7. Excel is an integration hub
Excel can:
- import
- export
- link
- automate
- script
- use APIs
- pull data from other tools
Excel is the glue between all other tools.
It connects what would otherwise remain disconnected.
In short
Excel is not everywhere because people love spreadsheets.
Excel is everywhere because it is:
- universally understandable
- universally adaptable
- universally integrable
- universally available
Excel is the tool that adapts to any project —
no matter how complex, chaotic, or unique.
And that is why it appears in all the project contexts mentioned earlier.
These characteristics — combined with the challenges of traditional “MBSE tools” — strongly suggest that Excel is indeed suitable for an MBSE‑style approach in project environments.
Not as a replacement for SysML or existing solutions, but as a complement.
A complement that educates, lowers barriers, and — with further development — may help prevent future project failures.
Rhetorically speaking:
How many job postings for major projects or product management explicitly target system architects?
Most likely none —
even though these projects desperately need exactly what the INCOSE definition describes.
Conversely, no one asks whether a candidate can read a SysML diagram or create a state machine.
But everyone assumes they can use PowerPoint and Excel.
Enough for an introduction 😉.
Concrete examples and implementation approaches will follow in upcoming posts.
To avoid any misconceptions: the Configena framework is not Excel – it goes beyond.
Stay tuned!