I want to write about the decision that, more than any other, shaped what DesignFoundry is.

Early in DesignFoundry's design, we had to make a choice about the data format the product would use internally. The engineering case for a custom format is real and tempting: it can be faster, it lets you do things competitors can't, and over time it becomes a moat — the longer customers use the product, the more invested they are in your format, the harder it is for them to leave.

We chose not to.

Not because a custom format would have been bad engineering — it would have been perfectly reasonable. We chose not to because of what proprietary formats do to architecture teams over time, and we refused to build a product that did that to other people.

This post is about why DesignFoundry uses open standards as its native data format, why that decision cost us something, and why I'd make it again every single time.

What I've watched proprietary formats do to teams

Let me describe a pattern that anyone who's been in enterprise architecture for more than a few years will recognize.

A company invests in an EA tool. They spend two or three years getting it deployed, training people, building up models, integrating it with their other systems. The architecture team becomes proficient. The models are detailed and current. The tool genuinely creates value.

Then something changes. The vendor gets acquired. Or the vendor changes their licensing model. Or the vendor raises prices to a level the company can't afford. Or the product itself drifts in a direction that no longer fits the team's needs.

The team looks at moving to a different tool. And they discover that they can't. Not really. The models are technically exportable, but the export is lossy. Some elements come through; others don't. Relationships that meant something specific in the source tool become ambiguous in the target. Custom properties get stripped. Diagrams have to be redrawn from scratch.

The "export" produces a file that's about 60% of the original model — which is to say, an incomplete model that nobody can fully trust. Moving means losing years of accumulated work.

So they don't move. They pay up. They live with a tool they no longer want because the cost of leaving is higher than the cost of staying.

I have lost count of how many EA teams I've watched go through this. It is not an edge case. It is the dominant pattern in enterprise architecture tooling.

The data your customer built belongs to your customer. Holding it hostage to keep them paying you is not a business model — it is a hostage situation dressed up as a product strategy.

DesignFoundry was started in part because I refused to build a vendor that does that.

What open standards actually means in practice

"Open standards" is a phrase that gets thrown around so loosely it has almost lost meaning. Let me be specific about what we mean by it.

ArchiMate 3.2 is our native notation.

Not "we support ArchiMate" — every model in DesignFoundry is, internally, an ArchiMate 3.2 model. All elements, all relationships, all properties conform to the ArchiMate metamodel. There is no proprietary layer on top. There is no "DesignFoundry-flavored ArchiMate." It's just ArchiMate, with the full element and relationship vocabulary the standard defines.

BPMN 2.0 for process modeling.

Where the architecture includes business processes, those processes are modeled in BPMN 2.0 — again, the actual standard, with the full element vocabulary, including the parts that some tools quietly omit. Gateways, message flows, choreographies, conversations. All of it.

.archimate as a first-class format.

Round-trip import and export. Bring in a model from Archi, work on it in DesignFoundry, export it back to Archi, lose nothing. Same with Sparx Enterprise Architect, Visual Paradigm, BiZZdesign, or any other tool that respects the .archimate format. We test these round trips continuously. If a release breaks fidelity, the release doesn't ship.

No proprietary properties.

Where we extend the model with our own metadata — AI-extracted confidence scores, model validation timestamps, source-document references — those extensions live in a separately-namespaced property scheme that doesn't interfere with the standard. Exporting your model strips our extensions but leaves your underlying ArchiMate completely intact. We don't tangle our value-add into the standard data.

The practical guarantee is this: you can use DesignFoundry for years. You can build a model with thousands of elements. If you decide one day that DesignFoundry isn't right for you — for any reason — you can export your model, take it to another tool, and continue working without losing anything. Your data is yours.

What this cost us

I want to be honest: this decision had real costs.

The custom format the engineer was advocating for would have been faster. It would have made certain query patterns easier to optimize. It would have let us ship some features 30-40% sooner because we wouldn't have been constrained by the standard's metamodel.

Building on the standard means accepting the standard's limitations. ArchiMate has some quirks. BPMN has some omissions. We've hit them. We've worked around them. We've contributed back where we could. Sometimes we've shipped slightly more complex implementations to stay within the standard rather than diverging from it for convenience.

The standard also limits how we differentiate. A pure-ArchiMate tool can be copied by another pure-ArchiMate tool. We can't lock customers in through format. We have to compete on what we do with the standard model — the AI reasoning, the auto-discovery, the collaboration, the compliance generation, the developer experience. Those have to be enough. If they aren't, the customer leaves and takes their model with them, and they should.

That accountability — the constant pressure of knowing the customer can walk away with their data — is, I think, a feature. It keeps us honest. We can't coast on lock-in. We have to keep being better than the alternatives, every release.

Why this matters more than usual right now

I'd argue this matters more in 2026 than it did five years ago, for two reasons.

AI raises the stakes on data ownership.

The models we generate from your architecture data — the auto-discovery output, the compliance reports, the query results — depend on having clean, structured, current data. If your model is locked in a proprietary format, it's locked away from any AI workflow you might want to run. Open standards make your model a substrate that any AI tool can reason over, not just ours. That's the right architecture for a world where you'll be running multiple AI tools over the same data.

Regulatory pressure is moving toward data portability as a default expectation.

GDPR established the principle. Sector-specific regulations are following. Customers are starting to ask, in RFPs, "what's your data portability story?" — and the answer that holds up under scrutiny is "your data is in a standard format you can take anywhere," not "we'll give you an export when you leave."

Open standards is no longer a nice-to-have. It is, increasingly, table stakes.

What this means for the architects reading this

If you're evaluating EA tools, the simplest question I can suggest you ask any vendor — including us — is: "Can I export the entirety of my model, in a standard format, with full fidelity, on demand, today?"

If the answer involves the word "but," that's your answer. The model isn't yours.

If you're already using a tool that locks you in, I'm not going to tell you to drop everything and migrate. That migration is its own significant project. But I would suggest: any new modeling investment you make from here onward should produce artifacts that survive the tool that created them. Build on the standard, even if your current tool's standard support is partial. Your future self — and the next architect at your company — will be grateful.

Where we go from here

DesignFoundry's commitment to open standards isn't going to change. It is, structurally, the founding decision the product is built on. We will get more useful, faster, more capable, more complete over time — but we will do all of that with the standard, not in spite of it.

If you'd like to see what an EA tool looks like when the underlying data format is one you can take anywhere, apply for early access. And if you ever decide DesignFoundry isn't right for you, we'll give you your model in .archimate format on the way out, with no friction and no fight. That's the deal we made with ourselves on day one. We're sticking to it.

Architecture data should belong to architects. We're just here to help you work with it.