ArchMeta Owner

Bruno has 35 years in IT, across most of the roles it offers: starting in development, then managing IT teams, then working as an enterprise architect. Having used several enterprise architecture tools, he decided in 2026 to build his own.

ArchMeta Owner

Bruno has 35 years in IT, across most of the roles it offers: starting in development, then managing IT teams, then working as an enterprise architect. Having used several enterprise architecture tools, he decided in 2026 to build his own.

Built for AI

The file formats are the product decision. .arch, .data, .bpmn and .md are all plain, readable text, and that is deliberate: it makes the repository something an AI can read, reason over and edit without an adapter, an API key or an export step.

A conventional EA tool keeps its model in a proprietary database. To put AI near it you must first build an integration, and you are limited to whatever the vendor's API exposes. Here the model is the interface. Point any agent at the directory and it has the whole architecture — types, prose, processes and data — in a form it already understands.

This is what makes it practical to build an AI environment around the repository rather than waiting for one to be built into the tool.

A self-describing repository

Metamodels are not islands. Any metamodel can be linked to any other, so a custom vocabulary sits alongside ArchiMate and C4 in one model rather than in a separate silo.

What makes that workable is where the meaning lives. The semantics of a type — what it means, when to use it, how it differs from its neighbours — are written in the repository itself, in the type descriptions and the accompanying .md files. The explanation travels with the model.

The consequence is that understanding this repository does not depend on anyone having been trained on it. A newcomer reads the descriptions. An AI reads the same descriptions, in the same files, and needs no fine-tuning, no vendor-specific knowledge and no external documentation to work accurately within the customer's own vocabulary. A repository that explains itself is one that stays usable after the people who built it have moved on.

The repository tells a story

A model that can only be read by architects has failed most of its audience. The website generator exists to fix that.

Views are organised into a published site whose structure the customer decides — an outline they author, not a navigation tree the tool imposes. Sequence the views, group them, give them prose, and the repository stops being a diagram archive and becomes a narrative: this is the business we are in, these are the capabilities behind it, this is the landscape that supports them, this is what changes next.

That turns the repository into knowledge others can actually consume — executives, new joiners, auditors, delivery teams — without any of them opening the modelling tool. The model stays the single source, and the site is how the organisation reads it.

Interlinked domains

Enterprise architecture goes wrong when its parts are kept in different tools. The application landscape lives in one place, the data models in another, the process diagrams in a third, and the programme portfolio in a spreadsheet. Each is accurate alone and none of them agree.

ArchMeta holds them in one repository and lets them reference each other directly: architecture elements in .arch, entity models in .data, processes in .bpmn, and the programmes and changes that act on them. A process lane points at the actor that performs it. An application points at the data it owns. A programme points at everything it will disturb.

That interlinking is what makes the views worth trusting. Impact analysis stops being an exercise in reconciling three exports and becomes a question you can actually ask of the model — and answer accurately, because there is only one model to ask.

Priced against do-it-yourself

AI has changed what an EA tool competes with. A capable team can now build a serviceable in-house modelling application, so the honest benchmark for ArchMeta's price is no longer other vendors — it is the cost of building your own.

That sets the pricing logic precisely: ArchMeta must cost less than the hassle of doing it yourself. Not less than a competitor's licence, and not less because it does less.

The distinction matters. ArchMeta is not inexpensive because it is low quality — the quality bar is set out under "Built with AI". It is inexpensive because the alternative it must beat is a build you would have to specify, write, test and then maintain forever, against a moving target. Buying removes that liability; the price reflects the liability removed, not the features shipped.

Built with AI

ArchMeta is developed with AI in the loop, and the quality argument is the point — not the novelty.

The product stands at roughly 40,000 lines of code covered by around 2,000 automated test cases. That ratio is only reachable for a small team because AI removes the cost of writing and maintaining the test suite that would otherwise be the first thing sacrificed.

The claim is therefore not "built faster". It is built to a standard that a team this size could not otherwise sustain. Every behaviour of the Kernel, the Viewer and the Publisher is pinned by tests, which is what makes the permissive loading model safe: the Kernel never fails a load, so the regression suite is the only thing standing between a change and silent data loss.