Round-Trip Fidelity: Why Import Then Export Should Never Lose Data

Import a model from Enterprise Architect. Change one property on one application. Export it back. If the file that comes out has renumbered every GUID, flattened your folder structure, and forgotten where every box was sitting on the canvas, you haven't performed an edit — you've performed a rewrite, and you're about to hand your colleague a diff they can't read and a model half your team will quietly stop trusting.

This happens more often than tool vendors like to admit, and it happens for a structural reason, not a laziness reason: every architecture tool has a metamodel, and no two metamodels line up perfectly. The moment you import a foreign model into your own tool's internal representation, you're translating between two schemas that were never designed to match. Some things translate cleanly — an application component is an application component everywhere. Some things don't exist on one side at all — Sparx Enterprise Architect's internal GUIDs, Archi's folder tree, the exact pixel position of a box on a diagram. What a tool does with the concepts it doesn't have a home for is the single most revealing thing about how seriously it takes interoperability.

The test that actually reveals something

Most evaluations of an architecture tool's import/export focus on whether the import worked — did the elements show up, do the relationships look right, does the diagram render. That's the easy half. The half that actually predicts whether you can use the tool in a real, ongoing exchange with a client's Sparx repository or a colleague's Archi model is this: import a model, change nothing, export it immediately, and diff the result against the original file.

A tool with genuine round-trip fidelity produces a diff that is empty, or close to it — maybe a timestamp, maybe a version string, nothing structural. A tool without it produces a diff the size of the entire file, because it didn't import your model so much as read it once and then reconstruct its own approximation of it on the way back out. Every GUID is new. Every element is in a different order. Folders you spent years organizing are gone, replaced by whatever flat or default structure the tool prefers internally. That's not a model exchange. That's a one-way trip that happens to accept a file on the way in.

Why this is harder than it sounds

The difficulty isn't parsing XML — every serious tool can read Enterprise Architect's XMI export or Archi's `.archimate` format without much trouble. The difficulty is that these formats carry information no generic canonical model was ever designed to represent, and a naive importer treats "I don't recognize this field" as permission to drop it. That's the failure mode worth naming precisely, because it's invisible until the second export, at which point it's too late — the data is already gone and nobody notices until someone reopens the file in the tool it came from and finds the folder tree flattened or the diagram redrawn from scratch.

A few categories of information sit squarely in this danger zone, and they're worth walking through individually, because each one fails differently and each one matters to a different person on the receiving end.

Native identifiers — Enterprise Architect GUIDs

Every object in a Sparx EA repository carries a GUID the moment it's created, and that GUID is how EA — and every script, add-in, and integration built against that repository — actually refers to the object internally. Display names change. GUIDs don't. If you import an EA model, edit it in another tool, and export it back with new GUIDs assigned to what are, semantically, the exact same elements, you haven't updated the repository. You've handed EA a set of objects it has never seen before, sitting alongside — not replacing — everything that was already there. Every existing diagram reference, every jArchi or EA-script automation keyed on that GUID, every traceability link built by a previous project, breaks silently. The elements still exist and still have sensible names; the thread connecting them to everything built around them is severed.

The only correct behavior is to treat the EA GUID as data the model carries, not data the model interprets. A canonical model doesn't need to understand what a GUID is for to preserve it faithfully across a round trip — it needs to record "this element arrived carrying this native identifier, and it goes back out with the same one," full stop, whether or not the tool's own concept of identity depends on it at all.

Folder structure

Sparx EA and Archi both organize models in a package or folder hierarchy, and in any repository that has been lived in for more than a few months, that hierarchy is not decoration — it's how the client's governance model, domain boundaries, and review process are expressed. "Applications owned by Finance" being a folder, not a tag, is often a deliberate structural decision inherited from how the client's EA practice works. A canonical model built around a flat list of elements plus a flat list of views has nowhere obvious to put that hierarchy, and the path of least resistance is to import the elements and quietly drop the folders they came from.

The fix isn't necessarily to force the canonical model's own semantics to include a first-class notion of nested folders it doesn't otherwise need — it's to record where each element came from as part of what it imported with, and reproduce that placement on export, even if the tool itself never uses that information for anything internally. The folder is metadata about provenance and organization, not architecture in the semantic sense, and it should be carried the same way — faithfully, without requiring the receiving tool's own model to be reshaped around it.

Diagram geometry

An architect who spent forty minutes laying out a landscape diagram so it reads cleanly left-to-right, groups related systems visually, and avoids crossing lines has done real work — work that isn't recoverable from the underlying relationships alone. If the canonical model only imports the semantic content (this element, this relationship, this view membership) and discards the x/y coordinates, sizes, and routing of that diagram, the export doesn't hand the layout back. It hands back a diagram containing the right elements, auto-laid-out from scratch, which for anything beyond a handful of boxes looks nothing like what was there before and has to be redone by hand.

Diagram geometry is exactly the kind of information a semantic model has no intrinsic use for — it doesn't change what's true about the architecture — and exactly the kind of information that's expensive to lose, because it's manual layout effort with no automatic way to reconstruct it. It belongs in the round trip precisely because the model doesn't need it for anything else.

Specializations and stereotypes

A generic canonical model built to support multiple profiles — Generic, ArchiMate, C4 — will have a core notion of "application" or "service" that doesn't map one-to-one onto every stereotype or specialization a source tool defines. Sparx EA models frequently carry custom stereotypes layered onto standard UML or ArchiMate types — client-specific extensions built up over years of a governance process nobody wants to redo. An importer that maps everything down to its nearest generic type and forgets the original stereotype has performed a lossy simplification dressed up as normalization.

The honest approach is the same pattern as GUIDs and folders: map what maps cleanly to the canonical model's own concepts, so the model is genuinely usable and queryable within the tool — but keep the original specialization or stereotype attached as preserved provenance, so that export doesn't silently downgrade a custom stereotype into the generic type it happened to resolve to on the way in.

The round-trip envelope

The pattern underneath all four of these cases is the same, and it's worth naming directly because it's the actual design principle, not just a list of special cases to handle: a canonical model that interoperates seriously with foreign tools needs a place to carry data it doesn't itself understand, attached to the element or view it belongs to, untouched, until export puts it back where it came from.

Call it a round-trip envelope. Every imported element carries two things: the part the canonical model actively understands and can let you query, edit, and validate — name, type, relationships, properties — and a sealed bundle of source-specific extension data the model doesn't interpret but faithfully returns on export. The envelope isn't a workaround bolted onto the format as an afterthought; it's the mechanism that makes the difference between a tool that translates a foreign model and a tool that merely samples one.

Mooodels applies exactly this pattern to Archi and Sparx exchange. Import a project from either tool and the elements land as genuine, editable members of the canonical model — you can query them, connect them, run linting and impact analysis against them, apply an AI-proposed patch to them — while their EA GUID, their originating folder path, and their diagram coordinates travel along as an attached envelope the model doesn't have to understand to preserve. Edit the description on one application, leave everything else alone, export back to EA, and the GUID that comes back out is the GUID that came in. The folder it lived in is the folder it goes back to. The diagram it appeared on still has it in roughly the place it was.

A worked example

Take a small but realistic case: a Sparx EA repository with a package called Applications / Finance, containing an application component called Invoice Service, with a custom stereotype «SystemOfRecord» that the client's governance process attaches to anything considered authoritative for its data domain. The element sits on one landscape diagram at a specific position, and it has a GUID like {4F2A1E00-...} that several other parts of the repository — including a jArchi script that generates a quarterly systems-of-record report — depend on.

The task is small: correct the element's description, which was out of date, and add one new relationship to a downstream reporting service that didn't exist when the diagram was last drawn. Nothing else should change.

The two right-hand columns both technically satisfy "the edit was made." Only one of them is safe to hand back to the client's EA repository. In the lossy version, the jArchi report breaks the next time it runs, because it's looking for a GUID that no longer exists — a brand-new element with a similar name has taken its place as far as the repository is concerned. Someone on the client side eventually notices the report is missing an entry, spends an afternoon figuring out why, and the answer turns out to be an external tool that touched the model once and quietly orphaned a governance script. That afternoon is the real cost of a lossy round trip, and it's almost always paid by someone who wasn't in the room when the import/export happened.

Where round trips break in practice

It's worth being specific about the failure modes, because "data loss" undersells how varied they are and how differently each one shows up.

Silent type downgrades. A tool maps every unfamiliar stereotype to its closest generic type on import, and never records what it started as. The export looks plausible — everything is still an application, a service, a node — and the loss is invisible until someone who knows the original model compares them side by side.

Identity churn disguised as normal editing. A rename gets interpreted by the receiving tool as a delete-plus-create rather than a rename, because identity was never tracked through the edit. This is really the same failure as GUID loss, just triggered by ordinary use rather than by the import step itself — which is why identity has to be stable across every kind of edit, not only preserved once on the way in.

Diagram reflow. Geometry is dropped or only partially preserved — element positions survive but connector routing doesn't, or vice versa — producing a diagram that's semantically correct and visually unrecognizable. Nobody would call this data loss in the strict sense, since the relationships are all there, but the layout work is gone and has to be redone.

Folder collapse. Everything imports into a single flat package because the canonical model's export step never asked "where did this come from," only "what type is it." The client's organizational structure — which is itself a form of documentation about ownership and domain boundaries — has to be manually rebuilt.

Partial round trips that look complete. The most dangerous failure mode isn't total loss, it's partial loss that passes a casual glance. GUIDs survive but folders don't. Geometry survives but stereotypes don't. Because most of the model looks right, nobody runs a careful diff, and the gaps surface weeks later as small, hard-to-diagnose inconsistencies rather than one obvious, loud failure.

Round trips and Git-friendly diffs

Round-trip fidelity and diff quality are the same problem wearing two hats. A model that reassigns GUIDs or reorders elements on every export doesn't just lose EA-specific metadata — it also produces a version-controlled file that shows a full-file rewrite on every save, even when the actual semantic change was a single property edit. That defeats the entire point of putting an architecture model in Git alongside code: the diff is supposed to be the thing a reviewer reads to understand what changed, and a diff that's 100% noise is worse than no diff at all, because it looks like it should be readable and isn't.

Deterministic serialization — stable ordering of elements and relationships, stable formatting, no incidental churn from internal processing order — is what makes a semantic diff possible in the first place. "Invoice Service gained a relationship to Reporting Service, description updated, everything else unchanged" is only a sentence a tool can produce if the underlying file didn't rewrite itself around that one change. Round-trip fidelity toward external tools like EA and Archi, and diff cleanliness toward Git, come from the same underlying discipline: change only what changed, and leave everything else — including things the model doesn't actively use — exactly as it was.

Objections worth taking seriously

"Isn't preserving data you don't understand risky — what if it's wrong or stale?"

The alternative is worse. An envelope of unread extension data can't corrupt anything the canonical model actively uses, precisely because the model never interprets it — it's inert cargo, not logic. The real risk runs the other direction: a tool that actively tries to reinterpret or "clean up" data it doesn't fully understand is far more likely to silently change its meaning than a tool that simply carries it through untouched. Preserving unknown data faithfully is the conservative choice, not the risky one.

"What happens when both sides change the same element between round trips?"

This is a genuine hard problem, and no honest answer pretends otherwise. If a client edits an element directly in EA while the same element was also edited inside the canonical model, a plain re-export will either silently overwrite one side's change or require a real merge step — same as any two people editing the same file in parallel. Stable identity is what makes that merge possible at all: because the element is recognized as the same object on both sides rather than read as two unrelated ones, a merge tool has something coherent to compare, field by field, rather than a delete-and-recreate to somehow reconcile. It doesn't eliminate the conflict. It's what keeps the conflict legible enough to resolve deliberately instead of it resolving itself by accident.

"Does this mean every foreign concept needs to become a first-class citizen of the canonical model?"

No, and trying to do that is its own trap — it leads to a canonical model that's bloated with every metamodel quirk of every tool it's ever imported from, which undermines the generic, profile-driven design that makes it usable across ArchiMate, C4, and plain Generic modelling in the first place. The envelope pattern exists specifically so this tradeoff doesn't have to be made. Concepts that genuinely matter to reasoning about architecture — applications, relationships, capabilities — earn a place in the semantic core. Concepts that are purely about where data came from or how it was drawn — a GUID, a folder path, a canvas coordinate — travel in the envelope, fully preserved, without forcing the core model to grow a permanent, tool-specific feature for each one.

"Is round-trip fidelity really worth the engineering effort, compared to just documenting known limitations?"

For a tool used once, to produce a one-off diagram, documented limitations are a fine answer. For a tool meant to sit alongside an existing EA practice — importing from a client's live Sparx repository, letting an architect work faster with AI assistance, then exporting back into that same repository for governance and audit — fidelity isn't a nice-to-have, it's the precondition for being trusted with the repository a second time. A tool that loses data on its first round trip doesn't get invited to do a second one; the client goes back to editing EA directly and treats the faster tool as a one-time export destination rather than a genuine part of the workflow.

A short checklist

Whatever tool you're evaluating for exchange with an existing Archi or Sparx repository, a few concrete checks surface the answer faster than reading a features page:

• Import a model, change nothing, export it. Diff against the original. Is the diff near-empty, or does it touch nearly every line?
• Rename one element, leave everything else alone, export. Does its GUID survive, and does everything that referenced it still reference the same object?
• Check whether folder or package structure survives a round trip, or gets flattened into a default location.
• Open a diagram after a round trip. Are elements roughly where you left them, or has the layout been silently regenerated?
• Look for a custom stereotype or specialization in the source model. Does it survive export, or does it quietly become the nearest generic type?
• Ask what happens to data the tool doesn't actively use for anything — is it dropped as noise, or carried through as an envelope it doesn't need to understand to preserve?

A tool that handles all six comfortably is treating your existing repository as something it's borrowing, not something it's replacing. A tool that struggles with more than one or two is asking you to trust it with data it has already shown it doesn't fully respect.

What this is actually for

None of this matters if the only thing happening is a single, final export at the end of a project. Round-trip fidelity matters because real architecture work isn't a single conversion — it's a repeated exchange, often over months or years, between a client's system of record and whatever tool an architect is using to move faster on a given engagement. A public-sector client running Sparx EA as their governance repository isn't going to abandon it because a faster tool exists; they're going to keep EA as the record of truth and expect anything else touching that model to hand it back exactly as faithfully as it received it, every single time, indefinitely.

That's the actual bar. Not "can this tool read an EA file," which nearly everything can do to some degree, but "can this tool sit in the middle of an ongoing exchange with EA or Archi for the life of a project without anyone on the client side ever noticing that something passed through it." Mooodels is built against that bar specifically, because the round trip isn't a feature bullet point — it's the thing that determines whether a client trusts you with their repository more than once.