How to choose your enterprise architecture metamodel

Two organisations in the same sector, running the same software, rarely describe their IT landscape the same way. Your metamodel should reflect that difference without becoming overcomplicated.

Key takeaways

• An enterprise architecture metamodel defines the types of objects you map (applications, business capabilities, data, servers), the relationships allowed between them, and their priorities: what you fill in first and keep up to date before anything else.
• The right metamodel reflects how your organisation thinks about its IT landscape and how mature its architecture practice is.
• There are two good places to start: a standard (TOGAF, ArchiMate) or a vendor's metamodel, designed to be pragmatic. The concepts overlap; what changes is which objects and relationships you select.
• The most common mistake is trying to model everything from the start: the repository becomes heavy and incomplete, and nobody keeps it up to date.
• Start with four layers and a handful of object types, then add a type only when a real decision calls for it.

At Boldo, the metamodel is fully configurable. So we see every team build its own, and we have yet to see two that are identical. A bank thinks in products and distribution channels, a local authority in services to residents, a manufacturer in sites and production lines.

This article is for architects, CIOs and consultants who are starting or taking over an IT mapping initiative. It sets out a method for choosing a metamodel that fits your organisation, and the mistakes we see most often.

What is an enterprise architecture metamodel?

An enterprise architecture metamodel is the list of object types you map and the relationships allowed between them, ranked by priority. It sets a shared vocabulary: what counts as an application, a business capability or a data flow, and what can depend on what.

The metamodel is the grammar of your IT map; the applications, data flows and servers you enter are its sentences. If the grammar is vague, two contributors describe the same reality in two different ways, and your impact analyses give wrong answers.

Priorities matter as much as the list. Not every asset type or relationship carries the same weight: your critical applications and their dependencies need to be reliable from day one, while a test server can wait. The metamodel says what has to be complete and up to date first, and what comes later.

It also specifies each object's properties (owner, criticality, end-of-support date) and their format. Tools rely on these definitions too: an AI agent that queries your repository uses them to understand what it reads.

Why every organisation has its own metamodel

Your metamodel has to match your organisation's mental model and the maturity of its architecture practice. A metamodel imported as is forces teams to translate their reality into a vocabulary that isn't theirs, and the IT map falls out of use.

The mental model is the way executives and business teams break down the organisation when they talk about it. Maturity is what the team can already keep up to date. Here are the starting points we recommend for each situation:

Start from a standard or a vendor's metamodel

There are two families of starting points: standards (TOGAF and ArchiMate) and the metamodels that architecture software vendors ship with their tools, such as SAP LeanIX or Boldo. Either way, you don't take everything.

Standards: TOGAF and ArchiMate

They bring a proven vocabulary that many architects already know, and both expect you not to use all of it.

In TOGAF 9, the content metamodel separates a core from six extensions (governance, services, process modelling, data, infrastructure consolidation, motivation). The Open Group documentation states that all of these extensions are optional and are selected during the Preliminary Phase of the method. For more on the framework, see our page TOGAF or Zachman?

The core of ArchiMate has three layers (business, application, technology, including physical), extended by strategy, motivation, and implementation and migration. The Open Group says the language was designed to be as small as possible while still covering most modelling needs.

Vendor metamodels

Vendors ship a ready-to-use metamodel, designed to be pragmatic and drawn from their projects. The SAP LeanIX metamodel (version 4) has 12 default object types across four layers: strategy and transformation, business architecture, application and data architecture, technical architecture. At Boldo, built-in templates play the same role: you start from one, then extend or simplify it.

The same concepts underneath

From one source to another, the concepts overlap and stay consistent. A business capability, an application, an exchange between applications or a data object exists everywhere, sometimes under a different name. What changes is the selection: which objects you keep, and which relationships you allow between them.

These equivalents are indicative: definitions don't always match exactly from one framework to another.

Narrowing it down

To narrow it down, ask three questions about each concept:

1. Which question from a decision-maker does it answer?
2. Who will keep it up to date, and when?
3. Who will read it?

A concept that can't answer all three waits its turn. Also bear in mind that ArchiMate notation speaks mainly to architects: if business teams need to read the IT map, reuse the concepts, not necessarily the symbols.

Start simple: Pareto mapping

Applied to IT, the Pareto principle means mapping first the roughly 20% of assets that carry about 80% of what's at stake. That is where migration, compliance and budget decisions are made, as our white paper on Pareto mapping of your IT explains.

Your metamodel follows the same logic: it ranks asset types and relationships instead of treating them all as equal. Here is the method we recommend:

1. List the questions your IT map must answer in the next six months: which applications the ERP migration affects, which suppliers are critical, which applications support invoicing.
2. Work out the object types and relationships you strictly need, then rank them by priority: what has to be complete right away, and what can wait.
3. Sort them into four layers: business (capabilities and processes), data (business objects), applications (applications and data flows), technology (servers and technologies).
4. Give each type an owner and a few useful properties, no more.
5. Review the metamodel with each new question: add a type when a decision calls for it, remove a type nobody fills in.

Mistakes to avoid

The most common mistake when choosing a metamodel is trying to map everything on day one. As our Pareto mapping white paper describes, months later the inventory still isn't finished, the first data is already out of date and the sponsors have lost interest.

Other mistakes come up often:

• Copying a metamodel as is (from a previous employer, a standard or a tool) without going back to your own organisation's questions.
• Adopting a standard in full, including concepts nobody will read.
• Creating an object type for what should be a property: criticality, for example, belongs on the application and doesn't need its own type.
• Forgetting relationships: an inventory without dependencies is just a spreadsheet, and supports no impact analysis.
• Building the metamodel for architects only, when business teams and executives also need to read the IT map.
• Freezing the metamodel: it has to evolve with your organisation's questions.

In Boldo

In Boldo, the metamodel is fully configurable: asset types, properties, relationships and calculated properties. Built-in templates give you a starting point, which you then extend or simplify. Every feature (diagrams, nested maps, impact analysis) works on any asset type, so adding a layer or a type doesn't mean rebuilding your views.

Frequently asked questions

Who should approve the metamodel?

Approve the metamodel with the people who will read it and keep it up to date, not just the architecture team. A business representative, an application owner and, depending on the context, the CISO check that the objects and terms make sense to them. The architect then remains responsible for keeping it simple.

Do you need to know ArchiMate to build your metamodel?

No. ArchiMate helps you name concepts in a standard way, but you can build a simple four-layer metamodel without it. What matters is starting from the questions your organisation is asking.

Criticality, costs, suppliers: object or property?

A piece of information becomes an object type when it has its own relationships; otherwise, it's a property. Criticality or annual cost belong on the application. A supplier, on the other hand, is linked to several applications and to contracts, so it deserves its own object type.

Can you change your metamodel along the way?

Yes, and you should. A metamodel lives with the organisation: a reorganisation, a compliance project or a merger raises new questions, and so new objects. Your tool should allow these changes without reworking your data.

Sources

• Boldo, white paper "Pareto mapping of your IT" (2025): boldo.io
• The Open Group, ArchiMate 3.2 Specification: pubs.opengroup.org
• The Open Group, TOGAF 9, Chapter 30 "Content Metamodel": pubs.opengroup.org
• SAP LeanIX, "Meta Model" documentation (version 4): docs-eam.leanix.net