Model-native architecture, ArchiMate and C4 practice, migration from Sparx and Archi, and where AI actually helps architects — without pretending to edit your model for you.
Model-native architecture treats the model as the product and the diagram as one disposable view of it. Here's what that means in practice.
Every architecture element needs a machine ID separate from its name, so a rename stays a rename instead of silently breaking its relationships and views.
One canonical model can produce many diagrams because a view is a live query over shared elements, not a copy of them.
Canvas and AI both edit the same model, not two copies of it. Here is how a canonical core with stable IDs makes that possible.
What survives an architecture tool's import/export round trip, and why GUIDs, folders and diagram geometry keep getting silently dropped.
Architecture models break in four distinct ways, and each needs a different check. A layered look at structural validation, metamodel validation, governance rules and linting — plus the honest limit of all four.
A plain-text diff on an architecture file shows lines changing. A semantic diff explains what the change means to the model, the views, and the rules.
Why architecture models need deterministic, stable-ordered serialization to be reviewable in pull requests and mergeable by more than one architect.
The same architecture change, made twice: once by dragging on a canvas, once by asking an AI assistant. What each mode is genuinely good at, where each one hurts, and why it matters that both write to the same model.
A practical, accurate primer on ArchiMate's three core layers, main element types, and the ten relationship types that hold a model together.
How to read a layered ArchiMate view: what crosses layers, what the arrows mean, and how to spot gaps between business need and technology support.
ArchiMate defines viewpoints for different audiences and questions. See why each one is really a filter over one model, not a diagram to maintain by hand.
Most application landscape diagrams fail executives before the meeting starts. Here's what actually communicates, and how to keep it from going stale.
A written principle and an enforceable rule look alike on paper. Only one is a deterministic query a machine checks on every model change.
Every architect gets asked 'what breaks if we retire this?' Here's what a complete impact analysis requires, and why it's a graph query, not a search.
Direct cross-domain database access is the architecture smell that never shows up in a review. Here's why it happens and how to actually stop it.
Capability maps are easy to draw and easy to fake. Here's how to make the capability-to-component chain a real, queryable trace instead of a slide.
Why architecture models need a linter, not just governance rules: the checks EA repositories skip and why running them on every save matters.
A practical primer on the C4 model: what Context, Container, Component, and Code diagrams each answer, and why they are zoom levels of one system.
ArchiMate gives portfolio-wide governance; C4 gives fast, developer-friendly depth on one system. When to use each, and when to legitimately use both.
Why the all-services diagram and per-team diagrams both fail as microservices grow, and how modelling services once with scoped views fixes it.
Why API gateways silently accumulate bypass integrations, and how a checkable rule against the real dependency graph catches them before an incident does.
Why solution architecture documents go stale within weeks of approval, and how Git-native, PR-reviewed models keep them true.
Model a new integration as a relationship before you build it: direction, protocol, ownership, and failure mode, checked before code is written.
A practical guide to migrating from Sparx EA: what actually needs to move, what round-trips cleanly, and why a phased rollout beats a big-bang cutover.
Archi is already ArchiMate-native, so migrating to Mooodels isn't about whether you can model something. It's about exactly what survives the trip.
Proprietary formats, seat licensing, bundled AI vendors, and single-client tools carry a cost that only shows up when you try to leave.
Why naive round-trip pipelines duplicate every object on re-import, and how identity-preserving export avoids it by reusing the original Sparx GUID.
Names change and files get reordered, but a GUID minted once by the source tool doesn't. Here's how re-import identity matching actually works, honestly.
Import wizards map what fits their metamodel and quietly drop the rest. Here's what actually gets lost, and the extension-bag pattern that fixes it.
An import that reports success has told you it didn't crash, not that it's correct. A practical verification checklist for the hour after you pull an existing repository into a new tool.
What it takes to branch, review, and merge an architecture model the way a team merges code — and where a model merge still needs a human to make the call.
AI keeps getting better at writing code and prose. That's not a reason to let it write directly into your architecture model. Here's why the gap stays.
A closed set of typed, validated operations is what makes AI-proposed model changes safe to preview, validate, and approve before they ever apply.
A vague instruction to a model-editing AI produces a patch you must review, not a disappointing paragraph. Here's how to write instructions that don't.
AI provider choice belongs on the same evaluation checklist as data residency and access control — not a settings-page afterthought. Here's why.
AI sovereignty is a property of a deployment, not a vendor label. A concrete breakdown of what public-sector architecture teams need to control it.
Sending a whole architecture repository to an AI is slow, costly, and a data-exposure risk. Query the graph first, then hand over just the relevant slice.
A specific, honest inventory of where AI genuinely speeds up architecture work today, and where the judgment still has to be yours.
AI-proposed architecture changes deserve the same discipline as a code pull request: read the diff, check the description matches, don't rubber-stamp.
A practical framework for comparing EA tools: repository vs. diagrams, installed vs. browser, methodology, AI, format lock-in, and licensing.
A diagramming tool draws boxes and arrows well. Architecture needs something that knows what the boxes mean. Here's exactly where the gap shows up.
You don't need an enterprise architecture team to get real governance value. A practical path for teams without one, starting from what exists.
Solution and enterprise architecture are usually run as separate disciplines with separate tools. In practice they're two zoom levels on the same facts.
A due-diligence checklist for public-sector teams evaluating architecture tools: data residency, AI controls, open exchange formats, auditability, and TCO.
Architecture documentation goes stale because it's a separate artifact on a separate cadence. Four practices that make it structurally hard to skip.
Slide decks answer the questions you prepared for. A live, queryable model answers the ones you didn't. Here's how to run a review either way.
Visual scanning of diagrams breaks down as a model grows. How structured search and graph queries replace 'ask the person who remembers'.
Most architecture decisions die on a whiteboard or get written up days later from memory. Capture them as real model changes in the same session instead.
What changes operationally when a practice makes the model, not the deck, the source of truth, and a realistic path to get there from slides.