What is Metamodelling?
Most modelling tools give you a fixed set of shapes: boxes, arrows, maybe some specialised icons. You arrange them on a canvas and call it a diagram. The tool decides what kinds of things you can draw, and if your domain doesn’t fit, you bend your thinking to match the tool.
Metamodelling turns this around: you define the language first, then model with it.
What is a Metamodel?
Section titled “What is a Metamodel?”A metamodel is a “model of a model” — it defines the vocabulary and rules for a particular kind of modelling. Specifically, a metamodel defines:
- Element types — the kinds of things you can model (e.g., Application, Business Process, Person, Vessel)
- Relationship types — how those things can connect (e.g., “serves”, “belongs to”, “manages”)
- Properties — typed fields that instances carry (e.g., status, start date, lifecycle stage)
- Constraints — rules about which connections are valid
- Notation — how each type appears visually on diagrams (shape, colour, icon)
When you model with a metamodel, you create instances of its types — individual elements and relationships that represent real things in your domain.
Why Does This Matter?
Section titled “Why Does This Matter?”Fixed-notation tools
Section titled “Fixed-notation tools”Tools like Visio, draw.io, or Lucidchart give you shapes and connectors. You can draw anything, but the tool doesn’t understand what you’ve drawn. A box labelled “Customer” and a box labelled “Server” look the same to the tool. There’s no structure, no validation, no type system.
Metamodel-driven tools
Section titled “Metamodel-driven tools”Farkitect knows that a “Customer” is an instance of “Business Actor” and a “Server” is an instance of “Node.” It can validate that a “Serving” relationship is valid between them, enforce that certain properties are filled in, and render each type with its correct visual notation. Your model is structured data, not just a picture.
The power of defining your own
Section titled “The power of defining your own”Some tools are metamodel-driven but only support one metamodel (ArchiMate, UML, BPMN). Farkitect lets you create your own metamodels for any domain — yacht fleet management, health and safety compliance, restaurant operations, anything. You’re not limited to what the vendor anticipated.
The MOF Layer Architecture
Section titled “The MOF Layer Architecture”Farkitect organises everything into three active layers based on the Meta Object Facility (MOF) standard:
| Layer | Contains | Example |
|---|---|---|
| M3 | Meta-metamodel — defines what metamodels can contain | MOF Core (read-only, built into Farkitect) |
| M2 | Metamodels — modelling languages | ArchiMate 3.2, UML, your custom Farquind Org Map |
| M1 | Models — instances of metamodel types | Your Farquind application landscape, org chart, data model |
Each layer defines the vocabulary for the layer below it:
- M3 defines what M2 metamodels can contain (element types, relationship types, properties, etc.)
- M2 defines what M1 models can contain (specific element types like Application Component, specific properties like Lifecycle Status)
- M1 is where your actual modelling work lives
For a deeper dive into how Farkitect implements these layers, see How Farkitect Uses MOF. For a plain-English introduction, see Understanding the Four Layers.
Farkitect’s Approach
Section titled “Farkitect’s Approach”Farkitect’s design philosophy follows from the metamodelling foundation:
-
Notation-independent core — the modelling engine doesn’t know about ArchiMate or UML specifically. It knows about element types, relationship types, and properties. Specific notations are just M2 packages.
-
Multiple metamodels in one project — a single project can import ArchiMate for application modelling, UML for class diagrams, and a custom metamodel for domain-specific concepts. They coexist.
-
User-defined metamodels — you can create your own M2 metamodels with custom types, notation, constraints, and properties. The built-in metamodels have no special status — they’re M2 packages just like yours.
-
Structured, queryable models — because every element has a type, properties, and typed relationships, models are structured data. You can catalog them, filter them, export them, and work with them programmatically.
This is what makes Farkitect a modelling tool rather than a drawing tool. The metamodel gives your models meaning.