ArchMeta

ArchMeta is an enterprise architecture tool whose repository is code. Despite a powerful graphical rendering and editing engine, the point of ArchMeta is that the whole architecture repository is a set of human-readable, human-editable text files.

The objective of the approach is to ensure that the customer owns their architecture repository.

Text-Native Model Engineering

The ability to design and evolve file formats that are simultaneously a machine-loadable model and a document a person can read, diff and edit by hand.

This is harder than it sounds. .arch, .data, .bpmn and .md have to carry enough structure for the Kernel to build a graph, stay legible enough to review in a pull request, and survive being regenerated by the Viewer's write-back without losing what the author meant.

Every other capability rests on this one. Ownership, AI-readability and portability are not features layered on top of the product — they are consequences of the format decision.

AI-Assisted Product Engineering

The ability to build and maintain a product of this size with AI in the loop, at a quality bar a team this small could not otherwise hold.

Concretely: roughly 40,000 lines of code under about 2,000 automated test cases. The test suite is the capability, not a by-product of it — because the Kernel never fails a load, regression tests are the only thing standing between a change and silent data loss.

This is what makes the pricing argument credible. ArchMeta can be cheaper than an in-house build while being better tested than one, and both halves of that sentence depend on this capability.

Repository Interoperability

The ability to move a repository in and out of ArchMeta without the vendor's cooperation.

Outbound, legibility is the whole mechanism: because the format is readable, a script can transfer the model to another tool. There is no export feature to be at the mercy of. Inbound, the same property lets content be migrated into ArchMeta from another tool, with AI handling the translation wherever the mapping is not mechanical.

Deliberately, this capability makes leaving easy. A customer who cannot leave has not been given ownership, whatever the licence says.

Metamodel Engineering

The ability to drive the whole engine from declared metamodels, so that type vocabulary is data rather than code.

Elements, relationships, layers, shapes, colours and icons are all declared in .metamodel files. The built-in ArchiMate and C4 profiles use exactly the syntax a customer would use for their own — they are examples of the mechanism, not privileged internals.

The pay-off is that a customer can model their own domain in their own terminology, in their own language, without waiting for b9 Solutions to ship support for it. Adding the ArchiMate Motivation layer to this very repository took one file and ten icons.

Cross-Domain Model Integration

The ability to hold architecture, data, process and change in one repository and let them reference each other directly.

An application points at the data it owns. A BPMN lane points at the actor that performs it. A programme points at everything it will disturb. None of this requires an integration project, because none of it crosses a tool boundary.

This is the capability that makes impact analysis trustworthy. The question stops being "which of these three exports is current?" and becomes something the model can simply answer.

Model Rendering and Editing

The ability to turn a text repository into diagrams people will actually look at, and to let them edit those diagrams without dropping back to the files.

Layout, notation, icons, containment, relationship routing and status styling all have to be derived from the model and the metamodels, then made directly manipulable in the Viewer — with every change written back to text that still reads well afterwards.

Text-first is only viable if the graphical experience is genuinely good. A readable repository nobody can draw with is a worse product, not a purer one.

Knowledge Publishing

The ability to turn the repository into a website whose structure the customer authors.

Views are sequenced and grouped into an outline the organisation decides, not a navigation tree the tool imposes. With prose around them, the result is a narrative rather than a diagram archive: this is the business, these are the capabilities behind it, this is the landscape that supports them.

The audience for architecture is mostly people who will never open a modelling tool — executives, new joiners, auditors, delivery teams. This capability is how they are reached, with the model still the single source behind it.