Choosing an Architecture Tool for a Public-Sector Project

A procurement team evaluating an architecture tool for a government project is not really asking "which tool has the best features." That question matters, but it's the easy one, and it's the one every vendor demo is built to answer well. The harder questions are the ones that don't show up in a feature comparison at all: where does the data actually sit, who can see it, what happens to the model the day the vendor relationship ends, and can this be defended in front of an audit committee two years from now. Those questions decide public-sector selections at least as often as usability does, and they get far less attention in the buying process than they deserve.

This is a practical checklist for that second category of question, written for the people who have to write the requirements document, sit through the vendor demos, and then live with the consequence of the choice for the next five to ten years. It is not a features list, and it is not a pitch for one tool over another in the abstract — public-sector requirements genuinely do sometimes favor a heavier, more established platform over a lighter, faster-moving one, and a due-diligence process that can't say that honestly isn't doing its job.

Why this evaluation is a different exercise

A private company choosing an architecture tool is mostly optimizing for one thing: does this help the architecture team work better, at a cost the budget can absorb. A public-sector body choosing the same category of tool is optimizing for several things simultaneously, and some of them pull in opposite directions from "best tool for the job today."

An enterprise architecture model produced under a government contract is, in a meaningful sense, a public asset. It documents the IT landscape of a hospital network, a ministry, a municipality — infrastructure that outlives any single vendor relationship, any single administration, and often the tenure of everyone in the room during the evaluation. The tool that produces and stores that model has to be chosen with that time horizon in mind, not just the horizon of the current project. A brilliant tool that leaves the model unreadable, unreachable, or legally exposed the day the contract ends has failed the actual requirement, however good the day-to-day editing experience was.

That reframes the evaluation. The question isn't only "is this a good architecture tool" — it's "is this a good architecture tool to entrust with a public asset, under public accountability rules, for a decade." The rest of this checklist works through what that actually means in practice, one requirement at a time.

The checklist, at a glance

The table below is the shape a procurement requirements matrix for this category tends to take once the obvious feature checklist has been stripped out. Each row is expanded in its own section afterward.

Data residency and processing location

"Where does our data live" is the question every public-sector IT security team asks first, and it deserves a precise answer, not a reassuring one. Precise means: which country or countries host the servers, under which legal jurisdiction, and whether that can change without notice as the vendor's infrastructure evolves. A vague "we use a major cloud provider" is not an answer — major cloud providers operate data centers in dozens of jurisdictions, and the contractual guarantee about which one your data actually sits in is what matters, not the provider's brand name.

For an architecture tool specifically, there are two data flows to trace, and teams often only check one of them:

• The model itself. Where is the canonical model — the elements, relationships, views, and their history — stored at rest, and where does it get processed when you open the editor, run a rule check, or generate a view?
• Any AI-assisted feature. If the tool offers an AI assistant, where does the content sent to that assistant go? This is a separate question from where the model lives, because a tool can store data entirely within a compliant jurisdiction and still route AI prompts to a completely different, unspecified location the moment someone uses the assistant feature. That gap is exactly where a procurement review that only checked the hosting page for the base product gets caught out later.

The honest answer from a vendor should distinguish those two flows explicitly, and should be checkable in writing — a hosting agreement, a data processing addendum, a specific named region — not asserted verbally in a sales call. If a vendor can't produce that in writing before the contract is signed, they won't produce it after.

Can AI be disabled, or restricted to an approved provider?

This is the requirement that has moved fastest in the last two years, and it's the one where a lot of architecture tooling on the market is currently weakest. Many public bodies now have an explicit policy position on AI use with government data — ranging from "disabled entirely, no exceptions" to "permitted only via an approved, contracted, or sovereign-hosted provider," and that policy can differ by department, by data classification, or by the sensitivity of the specific project. A tool that treats AI as a fixed, always-on feature baked into the product simply cannot satisfy that range of policy positions.

The practical test for a procurement team is straightforward to run in a demo: ask the vendor to turn AI off entirely, in front of you, and then keep working — creating elements, drawing views, writing rules, importing and exporting a model. If the product degrades into something unusable, or if core editing functionality turns out to have been quietly built on top of an AI call somewhere, that's a real finding, not a hypothetical one. In Mooodels, this is a design premise rather than a configuration afterthought: visual canvas editing, deterministic rule checking, linting, graph and impact analysis, and import/export all function fully with AI disabled, because none of them depend on it in the first place. AI is an optional layer on top, not a dependency underneath.

The second half of this requirement is what happens when AI is wanted but has to be constrained rather than switched off. A public body might be comfortable with AI assistance in principle but require that any provider be named, contracted, and hosted in a specific jurisdiction — sometimes a private or sovereign endpoint rather than a public API at all. A tool that hard-codes a single AI vendor into the product can't meet that requirement no matter how good its AI features are; the requirement isn't about capability, it's about who gets to see the prompts. A provider-neutral, bring-your-own-key approach — where the organization can point the AI feature at Claude, OpenAI, Mistral, an Azure-hosted deployment, a private or sovereign endpoint, or nothing at all — turns this from a blocking issue into a configuration choice made once, by the client's own security team, using infrastructure they already trust and have already vetted.

Is the exchange format actually open?

This is the requirement most often skipped in a features-driven evaluation, and it's the one with the longest tail of consequences. "Open exchange format" sounds like a technical nicety. For a public asset that has to survive a re-tender, a change of vendor, or simply a different administration wanting to bring the work in-house, it's closer to the single most consequential line item in the whole evaluation.

The test isn't whether a tool can export something. Almost every tool can export something. The test is whether what it exports is documented well enough that a different vendor, without access to the original tool, could realistically read it and reconstruct the model — not just render a picture of it. A proprietary binary format, or an XML dialect with no public schema, technically satisfies "we support export" while failing the actual requirement, which is: can this public body change vendors without starting the modelling work over from scratch.

Two related things are worth checking separately, because tools often get one right and not the other:

• A canonical, structured export — typically JSON or a similarly documented format — that preserves the actual model: elements, relationships, properties, and their stable identities, not just a rendered diagram. This is what a future tool, or a future in-house script, would parse to migrate the data.
• A standards-based exchange export — the ArchiMate Model Exchange File Format, or an equivalent published standard — that other established tools can already read without anyone having to write a custom parser first. This matters less for a one-off bulk migration and more for everyday coexistence: handing a model to a partner, a supplier, or an internal team that runs different tooling, and having it arrive as a model rather than as a picture of one.

It is worth checking, too, whether the exported model keeps its identities. A structured export that renumbers every element on the way out is a good deal less useful than it looks, because the second export a year later will not line up with the first, and any external system that recorded an element reference — a CMDB, a risk register, a spreadsheet of application owners — has nothing stable to match against. An export whose identifiers are stable across versions is what makes incremental, repeatable integration possible instead of a series of one-way dumps.

Mooodels exports both a canonical JSON representation and a standards-based ArchiMate exchange file specifically because these serve different exit and integration scenarios — one for a future tool or an in-house script to parse against a documented schema, one for an ArchiMate-aware tool the organization already runs to open directly. The deeper point for a procurement reviewer, though, isn't which specific formats a given vendor offers today. It's whether the format is documented independently of the tool, whether that documentation is available to inspect before signing anything, and whether the vendor's own roadmap or business continuing to exist is a precondition for the exported data remaining usable. If the honest answer to "could a different supplier pick this up in three years" is no, that's a lock-in risk the requirements document should name explicitly, not one to discover the hard way at the next tender.

Auditability of changes

Public-sector accountability doesn't stop at "the diagram is correct." It extends to "we can show, on request, who changed what and when." That request might come from an internal audit function, an inspectorate, a court process, or a citizen's freedom-of-information request touching on how a decision was made. An architecture tool that can't answer that question puts the organization in a position of either refusing the request or scrambling to reconstruct history from memory and email threads — neither of which is a good place to be.

What to check specifically, beyond a vague "yes, we have version history":

• Is every change to the model attributable to an identified user, with a timestamp, and is that record tamper-evident rather than editable after the fact?
• Can a change be described semantically — "this relationship was added, this element's owner property changed" — rather than only as an opaque file diff that requires the original tool to interpret?
• Can the audit trail be exported independently of the live tool, so it survives a contract change or a vendor dispute?
• If deterministic architecture rules are used for governance — for example, "every Tier-1 system must have a named owner" — is there a record of when a rule was violated, and when and by whom it was resolved? This is what turns governance from a policy document into something an auditor can actually verify happened.

A Git-friendly, deterministic serialization format helps here in a very concrete way: if the same model state always serializes to the same text, a version-control history of that text is a genuine, independently verifiable audit trail — not just a proprietary log the tool vendor claims is accurate. That's a meaningfully stronger position for an audit conversation than "trust our internal change log," because the evidence lives in infrastructure the organization already controls.

Interoperability with what the organization already runs

Government IT estates are old, heterogeneous, and change slowly, for good reasons — continuity of service matters more than being current on tooling. In enterprise architecture practice specifically, that usually means Sparx Enterprise Architect, sometimes Archi, and occasionally both in different parts of the same organization, often accumulated over a decade or more of separate procurement decisions. A new tool being introduced into that environment has to answer a blunt question: does it fit next to what's already there, or does it require ripping out and replacing an existing investment that the organization has no appetite, budget, or mandate to replace.

This is a place where the honest answer sometimes points away from a newer or lighter tool. If an organization has years of Sparx EA modelling, an established metamodel, and staff trained specifically on it, a lightweight browser-based tool that can't round-trip with that repository cleanly is adding a second, disconnected source of truth rather than solving a problem — no matter how much nicer its interface is. The right evaluation question is not "is this a better modelling experience" in isolation, but "can this coexist with or complement the existing repository without fragmenting the model of record."

Practically, that means checking for a genuine, documented exchange path with the incumbent tooling — not a one-way import that works once during a demo and then rots. Mooodels is built to interoperate with both Archi and Sparx EA through an open exchange format specifically because most EA practice doesn't get to start from a blank slate; a new tool has to be able to bring existing Archi or Sparx models in, and hand work back out in a form those tools can still use, rather than becoming an island. For a procurement team, the test is worth running literally: bring an existing model export from the organization's current tool, and watch what survives the round trip — which elements, relationships, and properties come through intact, and which get silently flattened or dropped.

Total cost of ownership, including the licensing model

A list price is not a cost of ownership. For a multi-year public contract, the number that matters is the sum of several things that rarely appear on the same page as the license quote:

The deployment question deserves particular attention because it interacts directly with the data residency requirement covered earlier, and because it's the item most likely to change mid-contract. A public SaaS offering is usually the cheapest and fastest way to start a project. But if a compliance requirement tightens later — a new data classification rule, a sovereignty mandate, a sector-specific regulation that didn't apply at contract signature — the organization needs to know in advance whether moving to a private or sovereign-hosted installation is a realistic option within the same product, or whether it means starting over with a different vendor entirely. A tool whose core technology isn't irreversibly welded to one hosting platform gives a procurement team room to make that move later without a full re-tender; a tool that only exists as a single multi-tenant SaaS product doesn't.

None of this means the cheapest license wins. It means the comparison has to be made on the full multi-year number, with migration and exit costs included on both ends, rather than on the number in the first year's quote.

Being honest about when a heavier tool is the right answer

It would be convenient, from a vendor's perspective, to claim that a lighter, browser-based, AI-optional tool is always the better public-sector choice. That's not true, and a genuine due-diligence process has to say so plainly.

There are compliance contexts where a mature, heavier, more established platform is the correct answer even if it's slower to adopt and more expensive to run. An organization operating under a specific, long-established accreditation regime that has already certified a particular tool and its deployment model has a real cost to changing that certification — a cost that can outweigh every usability advantage a newer tool offers. A defense or intelligence context with hard air-gapping requirements may need a tool with a deployment track record measured in decades, run by a vendor whose security posture has already survived years of scrutiny by that exact category of client, rather than one asking to be trusted for the first time. A very large, already-Sparx-EA-centric organization with a deeply customized metamodel, years of scripted automation built against that specific tool, and staff who have built their whole practice around it may find that the switching cost of any alternative — however well it interoperates on paper — exceeds the benefit, for years to come.

In those situations, the right procurement outcome is to stay with, or select, the heavier tool — and a lighter platform's honest role is often as a complement rather than a replacement: a faster way to model a specific project, a sandbox for exploratory architecture work, or an AI-assisted first pass that gets exported back into the system of record the organization is actually accredited to run. Recommending otherwise because a lighter tool is more pleasant to use would be optimizing for the wrong thing in exactly the context this checklist is meant to protect against.

Where a lighter, model-native, browser-first tool like Mooodels tends to earn its place instead is in situations where the constraints point the other way: a project with a hard AI-control requirement that an existing heavyweight tool's fixed AI integration can't satisfy, a smaller public body without the budget or staff for a heavyweight installation, a project that specifically needs to hand work back and forth with Archi or Sparx EA rather than replace either, or an organization that has been burned before by a closed export format and is deliberately prioritizing openness this time. The honest procurement answer is rarely "tool X is best" in the abstract — it's "given this compliance context, this existing estate, and this budget, which tool's constraints actually match ours."

Turning this into a requirements document

The checklist above translates fairly directly into a requirements matrix a procurement team can score vendors against. A workable structure scores each area on a simple scale — meets, partially meets, does not meet — with a written justification for anything short of "meets," rather than collapsing everything into a single weighted number too early. Data residency, AI control, and exchange format openness are reasonable candidates for pass/fail gates rather than weighted scores, because a vendor that fails one of those outright usually can't be brought into compliance by scoring well elsewhere — a closed export format doesn't become open because the editing experience is excellent.

A few closing questions are worth putting directly to every vendor in writing, before the demo rather than after, because the written answer tends to be more careful than the verbal one:

• Provide the jurisdiction and legal basis for where model data is stored and processed, including any AI feature, in writing.
• Confirm whether AI can be fully disabled with no loss of core functionality, and describe exactly what breaks if it is.
• Provide the documented schema for your export format, independent of your own product documentation, and confirm it is stable across versions.
• Describe what a customer can do, contractually and technically, on the day this vendor relationship ends.
• Provide a real, unedited round-trip test result importing an existing Sparx EA or Archi model and exporting it back out.
• Itemize the full multi-year cost including migration in, migration out, and any AI usage costs, separate from the base license.

A vendor that answers all six of these directly, in writing, before the contract is signed, has passed the part of the evaluation that actually protects the organization. A vendor that answers with reassurance instead of specifics is telling you something too — just not in the column of the requirements matrix they intended to fill in.