Archilence

Context

Every large organisation has an architecture repository, and almost none of them is current. The truth lives in code repositories, service catalogues, cloud accounts and runtime telemetry; the model lives in a tool that someone updates before an audit. Decisions get made on a picture that is months old.

Task & role

I founded Archilence to close that gap: a landscape model that maintains itself from the sources, and that people and agents can ask questions of. As founder I own the product and the architecture, and I write a good part of the code.

Architecture

Connectors read from code repositories, catalogues and runtime sources and write observations into a knowledge graph. The graph is bitemporal – it knows both when something was true in the landscape and when Archilence learned about it – and its element and relationship types are compatible with ArchiMate, so the result can be exchanged with the tools architects already use.

On top of the graph sit three consumers: a cockpit for architects, the agent Archie that answers questions and drafts changes, and an MCP server that lets other agents use the same model under the same permissions.

Decisions & trade-offs

• Generic extraction over rule sets. Code analysis uses language models to extract components and dependencies instead of maintaining rules per framework. That costs determinism, which the bitemporal history makes visible and reviewable.
• PostgreSQL before a graph database. The graph lives in PostgreSQL. Fewer moving parts for customers who host it themselves, at the price of writing some traversal logic by hand.
• Agents act through the same API as people. Archie has no back door; every change it proposes is an auditable change set.

Outcome

Archilence is in development. A complete synthetic demo estate with roughly 4,500 entities runs end to end – connectors, graph, cockpit and agent – and is the basis for the first pilot conversations.