Metamodel upgrades

Metamodels change. Standards publish new versions — ArchiMate 4 replaced several of 3.2’s element types — and your own metamodels get corrected and extended. Meanwhile, models built on them keep growing. This page explains how Farkitect lets a metamodel move on without breaking the models that use it. For the steps, see How to upgrade a metamodel.

The problem with replacing

A model element is an instance of a type in its metamodel — a Vessel Telemetry Link is an instance of Path. Farkitect records that link by the type’s identity, not its name.

If you delete a metamodel and import its new version, every type is created again with a new identity. Your model elements are left pointing at types that no longer exist: no appearance, no properties, no rules. That is why Farkitect refuses to Replace a metamodel your models use, and why deleting one deletes the elements that use it.

Upgrading in place

An upgrade edits the existing metamodel to match the new file instead:

• Each definition in the file is matched to the existing one — by a rename the file declares (formerNames), then by name within its package, then by name alone when that’s unambiguous.
• Matched definitions are updated, keeping their identity. Elements that use them don’t change at all, however large the model.
• New definitions are added.
• Only what the new version removes or tightens can touch your models — and that is where Farkitect is careful.

Nothing used is lost without your say

Farkitect never applies a change that would leave an existing element invalid. Instead:

• A type, property or value the new version removes but your models still use is retired: kept, hidden from anything that creates new things, and marked retired wherever it appears. Your models stay exactly as they were.
• A change that tightens something your models rely on — a relationship rule removed while relationships still use it, a type made abstract while elements use it directly — is held back: the old definition stays.

That makes an upgrade with no decisions always safe. When you want something else — give retired elements another type, delete them, move values into notes — you decide, per type or element by element, and you see the effect in the plan before anything happens.

Why decisions are re-checked

Giving an element another type can have knock-on effects: a relationship that was allowed for the old type may not be allowed for the new one. So after every decision, Farkitect checks each affected relationship against the rules of its new types. Anything that would become invalid appears as a new item — kept by default — rather than slipping through.

Safe at every step

Applying an upgrade happens in three stages:

1. Expand — add new definitions and loosen anything that only widens, so everything that was valid stays valid.
2. Migrate — change the models: give elements their new types and move their values, element by element in small batches.
3. Contract — only then apply what tightens, once no model depends on the old shape.

Every batch that is saved leaves every model valid. If an upgrade stops part-way, the models are still valid, and running the same upgrade again finishes it — because a new plan contains only what’s left.

A backup of the whole project is taken before the first change, and it is required: it is the way back if the result isn’t what you wanted.

MOF

Farkitect is built on the OMG Meta Object Facility. MOF defines what a metamodel and a conforming model are, but not how a metamodel changes. The test Farkitect applies is that every model conforms to its metamodel at every observable moment — before, during and after an upgrade. Retiring instead of deleting, holding back instead of tightening, and the expand → migrate → contract order are what make that true.

Versions and renames

A metamodel can carry a version (for example 4.1), shown in its Properties and in the record of each upgrade. A new version can also declare former names for definitions it renamed, so a rename is recognised as a rename rather than a removal and an addition. Both are optional fields in the .farki format.