← Back to list

Model-Based Acquisition without the Modeling Tax

How Draw‑First, Execute‑Later Modeling Makes UAF and MBSE Finally Accessible

Pavel Vlasov in Nasdanika · 2026-02-26 13:31 · 0 claps · 4.7 min read
#enterprise-architecture #visual-modeling #sysml #mbse #model-based-acquisition
Open on Medium ↗
Wiki topics: PFI · Personal Finance 🏛️ · Architecture

Model-Based Acquisition without the Modeling Tax

A few days ago, I attended a webinar titled “Introduction to the Unified Architecture Framework (UAF).”

The presenter traced UAF’s lineage back through decades of defense‑driven architecture frameworks. He emphasized its adoption across departments of defense, government agencies, and even some commercial enterprises. And then he mentioned its size:

  • ~250 element types.
  • 70 views.
  • Plus the SysML foundation.
  • Two hundreds of pages of documentation.

He told the audience that you don’t have to use all of it — just the parts you need. But that’s the catch, isn’t it? To use “just what you need,” you must first know what exists, how it fits together, and how to use it correctly. That’s not a small ask.

Then he showed a few diagrams. Boxes. Arrows. Same color.

And he said something that resonated with me:

Organizations are striving to migrate from document‑based acquisition to model‑based acquisition.

At that moment, I realized something: This is exactly what Nasdanika has been doing all along — just without the modeling tax.

The Modeling Tax Nobody Talks About

In theory, model‑based acquisition is about rigor, traceability, and structured knowledge. In practice, it often means:

  • Forcing SMEs to learn unfamiliar notations
  • Adopting heavyweight modeling tools
  • Navigating metamodels with hundreds of concepts
  • Wrestling with Papyrus, MagicDraw, or Cameo
  • And maintaining models that only a handful of specialists can understand

Meanwhile, the rest of the organization continues to communicate in:

  • Visio diagrams
  • PowerPoint slides
  • Word documents

Pixel‑deep boxes and arrows with no semantics. The gap between formal MBSE and real‑world business IT is enormous. Most developers I’ve worked with use Maven, Gradle, VS Code, IntelliJ. Ask them to open Papyrus? Good luck. Ask an SME? Forget it.

Even EMF Ecore — the simplest modeling layer directly translatable to Java — is “rocket science” to most IT teams.

And yet, these are the people who hold the knowledge we need.

Draw First. Execute Later. No Metamodel Required.

This is where Nasdanika flips the script. Instead of forcing SMEs into the Procrustean bed of UAF or SysML, Nasdanika lets them:

  • Draw using ubiquitous tools like Draw.io,
  • Express ideas in their own language,
  • Use graphical expressive means — colors, border widths and strokes, millions of images,
  • Capture structure visually,
  • Add markdown for context,
  • Organize diagrams into a hierarchy and federate,
  • And let meaning emerge later.

No one needs to know the UAF metamodel. No one needs to memorize 250 element types. No one needs to understand 230‑page spec.

You draw first. You map later. You execute when ready.

Meaning can be elicited:

  • Manually by architects who understand the metamodel,
  • Or automatically by agents trained on the metamodel or using tools and Json schemas derived from the metamodel to create models compliant with the metamodel. Different agents may be “experts” in different parts of the metamodel — their bounded context — so they don’t get overwhelmed,
  • Or through hybrid workflows where humans and agents collaborate.

This is model‑based acquisition — but without the modeling tax.

From UAF XMI to Ecore: A Practical Experiment

Inspired by the webinar, I decided to explore the UAF and SysML metamodels more deeply.

I searched for existing Ecore models. I found one very old version and another a pilot repository.

So I went to the source: the XMI/EMOF files on the OMG website.

My first attempt was the “proper” one:

  • Import into Papyrus
  • Load into Eclipse Modeling Tools

After an hour of dependency whack‑a‑mole, I gave up.

Then I tried something different: I handed the XMI files to a GitHub coding agent and asked it to generate Ecore. It worked surprisingly well — just a few errors to fix manually. I generated a .genmodel, attempted Java code generation (which failed), and then pivoted to generating documentation directly from ecore files without ecore -> Java step.

UAF 2D Graph

UAF 2D Graph

UAF 3D Graph (Molecule) — zoom in/out, rotate

UAF 3D Graph (Molecule) — zoom in/out, rotate

Zooming in

Zooming in

Context diagram

Context diagram

SysML Graph

SysML Graph

This alone is a huge win. Even without a perfect Ecore model, the documentation provides a reference map of UAF’s structure — something the community desperately needs. And if there is ever a need of a fully functional Ecore model, it can be done the “proper way” from XMI — either using the existing tools or something as simple as XML parsing or streaming.

The Chasm Between UAF and Business IT

Working through the UAF metamodel made something painfully clear, which I already mentioned above: There is a massive cultural and tooling gap between UAF, TOGAF, and other OMG things and the world of everyday business IT.

In defense and aerospace, modeling is a discipline. In business IT, modeling is a PowerPoint.

UAF lives in a world of:

  • MOF
  • EMOF
  • XMI
  • Ecore
  • SysML profiles
  • Formal semantics

Business IT lives in a world of:

  • REST APIs
  • Microservices
  • CI/CD pipelines
  • VS Code
  • JSON
  • YAML

These worlds rarely meet. And yet, they need each other.

Nasdanika as the Bridge

This is where Nasdanika shines — not as a competitor to UAF, but as the on‑ramp.

Nasdanika provides:

  • A draw‑first capture layer
  • A semantic mapping layer
  • An execution layer
  • And the ability to integrate with UAF, SysML, or domain‑specific metamodels

SMEs sketch meaning. Nasdanika captures it. Architects or agents map it to UAF. MBSE pipelines consume it. This is model‑based acquisition that respects human cognition. It lets SMEs speak their language. It lets architects enforce rigor. It lets organizations scale knowledge capture without forcing everyone to become a modeler.

Model‑Based Acquisition Without the Pain

The industry keeps saying: “We need to move from documents to models.”

But the unspoken truth is: “We can’t afford the modeling tax.”

Nasdanika solves this by making modeling invisible: You draw. You add properties. You collaborate. You evolve. And only when needed, you map to formal semantics. This is the future of model‑based acquisition:

  • Lightweight at the edges
  • Formal at the core
  • Agent‑augmented
  • SME‑friendly
  • Metamodel‑aware

It’s not about replacing UAF or SysML. It’s about making them usable by the people who actually hold the knowledge.

And that’s how we finally get model‑based acquisition — without the modeling tax.


메타데이터
post_id
8c1d96a5b86c
slug
model-based-acquisition-without-the-modeling-tax-8c1d96a5b86c
url
https://medium.com/nasdanika/model-based-acquisition-without-the-modeling-tax-8c1d96a5b86c
canonical_url
https://medium.com/nasdanika/model-based-acquisition-without-the-modeling-tax-8c1d96a5b86c
author_url
https://medium.com/@pvlasovjax
status
ok
fetched_at
2026-06-23 03:48:11