Understanding the Four Layers

Farkitect is built on an idea called the Meta Object Facility (MOF), an open standard from the Object Management Group (OMG). That sounds intimidating, but the core concept is surprisingly simple. This guide explains what it is, why it matters, and how you’ll encounter it when using Farkitect.

The Big Idea

MOF organizes everything in Farkitect into four layers, numbered M0 through M3. Each layer describes the one below it. Think of it like this:

Layer	What it is	Everyday analogy
M3	Rules for defining languages	The grammar rules that all languages must follow
M2	A modeling language	A specific language — like English or French
M1	A model	A document written in that language
M0	The real world	The actual things the document is about

That’s it. Four layers, each one giving structure to the next. Let’s walk through them from the bottom up, starting with what’s most familiar.

M0 — The Real World

M0 is the real world — the actual people, systems, buildings, and processes that exist around you. M0 isn’t something you interact with inside Farkitect. It’s just the reality that your models are trying to represent.

Example: Farquind’s actual FQ Vessels telemetry platform running on cloud infrastructure. The real person Chase Martin who leads the company. The physical process of assembling a yacht hull at the Hatteras factory.

You never create M0 objects in Farkitect. They already exist. Everything you do in the application is about describing them.

M1 — Your Model

M1 is where you do most of your work. This is your model — a structured description of the real world (M0) using the vocabulary defined by your chosen modeling language (M2).

When you create an element called “FQ Vessels” and classify it as an Application Component, that’s an M1 element. When you draw a Flow relationship from “FQ Orders” to “FQ Vessels,” that’s an M1 relationship. When you set a Lifecycle Status property to “Active,” that’s an M1 property value.

Example: In an ArchiMate model of Farquind:

• FQ Vessels — an instance of Application Component
• FQ Orders — an instance of Application Component
• FQ Orders → FQ Vessels — an instance of the Flow relationship
• Lifecycle Status = Active — a property value on FQ Vessels

Everything in M1 is an instance of something defined at M2. The model doesn’t invent its own vocabulary — it uses whatever types the metamodel provides.

In Farkitect: M1 packages appear in the Explorer with the prefix M1 (e.g., “M1 Farquind Applications”). This is where you create diagrams, populate catalogs, and build out your model.

M2 — The Modeling Language

M2 defines the types that M1 uses. It’s a modeling language — a vocabulary of element types, relationship types, properties, and enumerations that together describe what kinds of things can exist in a model and how they can relate to each other.

You can think of M2 as a template or a cookie cutter. It defines the shapes — M1 is where you stamp out the actual cookies.

Example: The ArchiMate 3.2 metamodel defines:

• Application Component — an element type in the Application layer (blue, component icon)
• Application Service — an element type in the Application layer (blue, service icon)
• Business Process — an element type in the Business layer (yellow, process icon)
• Flow — a relationship type (dashed arrow) with constraints on valid source/target pairs
• Serving — a relationship type (solid arrow) for service delivery
• Junction Type — an enumeration with values: And, Or

Notice that M2 doesn’t contain any actual applications or processes. It only defines the types. The actual FQ Vessels and FQ Orders live at M1.

In Farkitect: M2 packages appear in the Explorer with the prefix M2 (e.g., “M2 ArchiMate 3.2”). When you use the Palette to drag a new element onto a diagram, you’re picking an M2 type and creating an M1 instance of it.

Multiple Metamodels

One of the powerful things about this approach is that you’re not locked into a single modeling language. Farkitect can host multiple M2 metamodels at the same time:

• M2 ArchiMate 3.2 — the full ArchiMate standard with 61 element types across 8 layers
• M2 UML Class Diagram — UML class modelling notation
• M2 C4 Model — Simon Brown’s C4 architecture model
• M2 Business Model Canvas — Osterwalder’s nine building blocks
• M2 Logical Data Model — Entity-relationship modelling
• Your own custom metamodels

Each M1 model imports the M2 metamodel it needs. You can even create models that combine types from multiple metamodels.

M3 — The Rules Behind the Rules

M3 is the meta-metamodel — it defines the concepts used to build M2 metamodels. This is the most abstract layer, and in day-to-day use you’ll rarely think about it.

M3 answers the question: “What kinds of things can a metamodel contain?” The answer is a small, fixed set of building blocks:

• Class — defines a type of thing (element types and relationship types are both Classes at M3)
• Property — defines an attribute that a Class can have
• Package — defines a container for organizing things
• DataType — defines primitive value types (String, Integer, Boolean, Date, etc.)
• Enumeration — defines a fixed set of named values

Every M2 metamodel is built from these M3 building blocks. When you create a new element type called “Application” in your metamodel, you’re creating an M2 Class — which is an instance of the M3 concept called Class.

In Farkitect: M3 appears in the Explorer as M3 MOF Core — a read-only package shown in red. You can expand it to see the foundational concepts, but you don’t edit it. It’s the bedrock that everything else is built on.

Why Does M3 Exist?

You might wonder why we need this extra layer. The practical benefit is that Farkitect doesn’t have to hard-code what a metamodel can contain. Because M3 formally defines the building blocks, the application can:

• Let you create any metamodel, not just predefined ones
• Validate that metamodels are well-formed
• Provide consistent editing tools (the M2 Modeler) that work for any metamodel
• Import and export metamodels as portable .farki files

Without M3, every new modeling language would require new application code. With M3, you just define a new M2 package and start modeling.

How the Layers Connect

The layers are linked by a single, consistent mechanism: classification. Each element is an instance of something in the layer above it.

M3:  Class ─────────────── "What is a type?"
       ▲
       │ instance of
       │
M2:  Application Component ─ "Application Component is a type"
       ▲
       │ instance of
       │
M1:  FQ Vessels ───────────── "FQ Vessels is an Application Component"
       │
       │ describes
       ▼
M0:  (the real system) ────── The actual FQ Vessels platform

This chain of classification is what gives Farkitect its flexibility. The same mechanism — “this thing is an instance of that thing” — works at every level.

What This Means for You

In practice, most of your time in Farkitect is spent at M1 and M2:

• If you’re building models (diagrams, catalogs, relationships), you’re working at M1 using types from M2
• If you’re designing a custom modeling language, you’re working at M2 using building blocks from M3
• M3 is there in the background, making everything consistent — you don’t need to touch it

The naming convention in Farkitect makes the layers visible: packages are prefixed with their layer (M3, M2, or M1), so you always know where you are.

Next Steps

Now that you understand the four layers, you’re ready to start building:

• What is Metamodelling? — A deeper look at why metamodels matter and how Farkitect differs from fixed-notation tools
• How Farkitect Uses MOF — The specific implementation choices: classifiers, imports, and the M3/M2/M1 relationship
• Your First Diagram — Build something hands-on with a built-in metamodel
• Creating Your First Metamodel — Build your own M2 metamodel from scratch