“Well begun is half done,” and that rings true in metamodeling, too. Before you even begin, you should be clear on your objectives and success criteria, whether you are aiming for efficiency of modeling, the ability to analyze and create insight, or easing communication. With your mission in hand, you can go into Ardoq and make the most of its flexibility to define your enterprise architecture metamodel.

If you are starting fresh, Ardoq is more than capable of providing all the functionality you need. Ardoq also supports starting with existing Enterprise Architecture (EA) standards such as ArchiMate or domain modeling standards like Business Process Model and Notation (BPMN).

We have done the heavy-lifting with intensive research, reading, and compiling so that you don’t have to.

Metamodeling is a highly specialized task, so standards have been created to prevent easily avoidable mistakes. However, it is not true that you should only ever rely on a predefined standard.

Organizations have varied internal requirements, diverse stakeholders, and often several missions running concurrently. A one-size-fits-all approach will not fully address these things, which is why we advocate an organic approach to EA. A less rigid, standards-bound approach allows demand and emerging requirements to shape your modeling as much as existing practice. However, with great power comes great responsibility so to do this effectively, you should bear in mind our seven fundamental principles.

We have managed to condense a rich topic into seven simple but powerful principles that will guide your metamodeling in the right direction. Our study included existing industry standards for enterprise architecture and domain modeling, our own customers’ implementations, and best practices. As experienced enterprise architects, we have direct knowledge of implementing many of our competitors’ EA tools in real organizations. As is natural, we have made and learned from our mistakes to find the best ways forward.

Before we get into the how of metamodeling, we want to be clear on the why, which will vary according to the organization and mission. It is even possible that you may consider it redundant as metamodeling is fundamental to getting your EA repository up and running.

However, the all-important question “What are your objectives for building a metamodel?” will help determine how successful your EA program will be.

If you’re struggling to express the why, we’ll give you our take on the subject:

The purpose of your metamodel is to organize, analyze, and communicate your enterprise architecture.

Let’s break that down.

Organize means that your processes, applications, capabilities, technologies, people - all the elements that make up your enterprise architecture - are efficiently integrated into an end-to-end picture. This does not mean merely importing data and creating connections that result in a big island of chaotic data. In metamodel terms, efficiently means you minimize duplication of concepts and maximize consistency. The result is that when you’re looking at your architecture data, you can see the critical big picture without being caught in the tangle of details.

Analyze means you need to be able to use this data to answer real business questions. In more concrete terms, you must organize the data in your metamodel to answer the queries you will have.

Communicate seems simple but is fundamental. Whether looking at the individual elements of your enterprise architecture (e.g., a model), or analysis derived from it (e.g., a dashboard), your audience should be able to understand what they’re looking at. Good architects know their ability to execute strategy rests on their ability to communicate. Your metamodel is the medium through which you’re going to tell many architecture stories. If that insight is wrapped up in obscure concepts and technical jargon, then you’ll struggle to get your point across or to distribute that information so that others can find the answers they are looking for.

Now we have explained the why, we will walk you through the seven principles that will help you determine how. We will describe each principle, why it matters and provide examples as well as a checklist to help you create the best possible metamodel.

Challenges: As the scope of your modeling increases, you will be asked to add ever-more component and reference types to your model; but doing so may render it unusable.

Metamodels are like any other part of your enterprise architecture: They tend to grow more complex over time. So keeping that complexity under control is critical.

While agile metamodels should grow organically, the need to provide insight into individual domains (e.g., business processes, cloud services) is in continual tension with the need for cross-domain insight (e.g., across the whole architecture).

Here is a simple example of how and why:

Let’s assume your stakeholders can easily understand an architecture model of up to fifteen component types. If you have a domain metamodel - cloud services, for example - those fifteen component types might describe that domain with a reasonable degree of precision.

However, if you want to show how your cloud services support your applications which then, in turn, support your business processes to deliver business products and services - a cross-domain architecture model is required.

If each of these four domains also consists of fifteen component types, your audience now has to understand a model consisting of sixty component types. You also need to create queries that can traverse and join up to these sixty component types while managing up to sixty data inventories.

The complexity of your model, and the processes that surround it, has increased multifold.

It is thus vital to keep the number of component types down. You achieve this by learning how to abstract and not over-specialize your metamodel.

Abstracting might mean sacrificing some of the precision you have in domain models. For example, you should deliberate over whether it is essential to capture eight different types of business process start events in your enterprise architecture repository.

The danger here is of over-abstraction to the point where you have too few types. Easier to manage and query but is your model then still meaningful to your audience? For example, when everything just becomes some variation of a ‘service’ it may be tough for your audience to understand what is going on.

Over-specialization, on the other hand, tends to happen with modelers who do not understand that a lot of precision in metamodels comes from relationships and not component definitions. Modelers naturally want to type-classify their components into sensible categories, and so create component types like ‘marketing application’ or ‘Linux server’.

A better approach is to use references or relationships to create groupings. This is common in modeling standards like UML or ArchiMate - for example where ‘aggregates’ relations are used to group one component by another.

Then, instead of creating specialized component types, we can have an application component connected to the marketing department component or a server connected to the Linux software product component.

Getting the balance between abstraction and specialization right is the key to managing the complexity of your metamodel.

Important reflection points for “Principle One: Control the Number of Component and Reference Types in Your Metamodel” :

Challenges: As you map different IT and business domains, you will encounter multiple modeling standards in use; however these standards often don’t fit neatly together.

Whether you choose to use an existing enterprise architecture metamodel standard or not, you will still have to navigate the standards landscape. Your business process modelers are using BPMN and your solution architects UML. IT Ops is all about ITIL while the data architects speak ERD. Legal is pushing GDPR, DevOps speak AWS, business strategy uses BMM and BMC while product development prefers VPC to map customer needs.

How do you start to make sense of all of these?

What we do not recommend is importing each domain standard wholesale into your metamodel, creating some extra references to tie them together, and hoping the whole thing will make enough sense in the end.

Unfortunately, the hard truth is that each standard is optimized to describe its own domain, often with little regard for other domains. BPMN is not there to structure your data. ITIL might define business services, but do business people actually recognize them?

When you combine these standards in their entirety, you end up with a mess of unintegrated component and reference types. Worse still, despite their different names, many of those types may mean the same thing.

This approach completely defies Principle One: Control the number of component and reference types in your metamodel.

You should begin with merging and deduplicating those standards, understanding where concepts overlap and where you need to tweak definitions to get them to sync with each other. This will inevitably lead to some dissatisfaction as every team would prefer that their chosen language be the standard, but compromises will need to be made.

Our other advice here is - “Rome wasn't built in a day”-so start small and add more as you go.

Don’t try and force your whole standards landscape together at once. Instead, concentrate on integrating two domains at a time and then showing the insight you can create. Once the rest of the organization can see the value that such a joined-up view can bring, they will most likely forgive you for tinkering with their preferred way of viewing things.

Important reflection points for “Principle Two: Simplify & Consolidate Standards to Meet Your Needs”:

Challenges: Different parts of your organization use different terminology to describe its component parts. To avoid building confusion into your metamodel, you will need to understand which ones overlap and refer to the same concept.

Even if you’re not contending with multiple standards, be aware that each business area, specialism, practice, community, industry vertical and methodology has its own jargon or dialect.

Your stakeholders will naturally express their requirements in the language which is familiar to them. Your role is to play the translator because it’s too easy to assume that different languages relate to whole different sets of concepts.

Very often, all these different names and classifications describe the same organization as the one you inhabit. Some probing questions may quickly reveal that what they call X is actually what you call Y.

However this is not true in every case. It’s up to you as a modeler to dig beneath the superficial language and discover what’s the same, and what isn’t.

How do you do that?

Rather than asking them to elaborate or attempt fruitless persuasion on alternative terminology, you need to look beyond the labels they use and what data they truly represent. Do ask them for examples of what they want to model. If Dynamics CRM is an IT Service to one person, an Application to another and a Deployment Package to another, then you are well on the path to finding the simple metamodel in the Tower of Babel that is the modern enterprise.

You might be surprised at how willing people are to change their language once they see the value that a joined-up view can offer.

Important reflection points for “Principle Three: Define & Speak A Common Language”:

Challenges: Architects must provide both high-level views to senior audiences and detailed views to create operational insight and analyze impacts. Without traceability between summary and detailed views, strategy and execution will become misaligned.

If component types and reference types are the atomic building blocks of your metamodel, then the next level of building block is the hierarchy.

Hierarchies - or more accurately taxonomies - are the building blocks of the different domains or layers of your architecture - for example, your application domain, your data domain, your process domain.

Each of these domains or layers may consist of multiple component types and yet relate to the same overall set of architect concepts. As these concepts are conceptually related, they can be arranged into hierarchies.

Hierarchies enable you to describe your architecture at different levels of scale, from the macro to the micro, whilst keeping full traceability between those levels. Technically, this process is called composition (or decomposition, depending which direction you’re travelling in).

It means you can use your models to tell high-level architecture stories to your senior management and, by moving down the hierarchy, discuss the details with individual business and technical specialists confident that those conversations are fully consistent.

We have a whole article dedicated to building hierarchies which will be a good starting point on the best way forward as hierarchies contribute so fundamentally to the core objectives of your metamodel: Efficiency, analysis, and communication.

Hierarchies also tend to evolve over time. It’s likely your metamodel will start out relatively ‘flat’ with one or two levels of business capability and perhaps a flat list of applications. Over time, you’ll need to add new layers, decomposing components into their constituent parts, but also creating new top-level components to group and classify. Like any part of your metamodel, the job of building your hierarchies is never done.

Important reflection points for “Principle Four: Use Hierarchies to Organize Domains”:

Challenges: High-level and detailed models can often become misaligned if you do not understand how they relate to each other and use each to build out the other.

In Principle Four, we touched on the fact that enterprise architecture operates at different levels, from the topline level needed by business and IT executives and planners, to the practical detailed descriptions required by those running or changing operation business and IT processes.

Often, when reading about metamodeling, you will come across the phrases ‘high-level concept’ and ‘low-level concept’. Business capabilities or value streams are often referred to as being ‘high-level concepts’, while a logical function or a business process are ‘low-level concepts’.

Architects attempt to map the complex relationships between the high-level and the low-level by trying to understand how they relate to each other and to the concepts that surround them. For example, how does a value stream relate to a business process, and how do they both relate to applications?

The problem with thinking about metamodel concepts as ‘high-level’ versus ‘low-level’ is that it blinds us to the fact that these are not fundamentally different concepts; we’re simply describing the same organization at different scales.

If a business capability is basically an ‘ability to’ that specifies what is done without specifying how, then that same concept can apply to multiple levels - from the ability to run a business selling media services on-demand (high-level) to the ability to update a customer’s subscription expiry date (low-level). Those capabilities could be realized by a portfolio of enterprise applications (high-level) or an individual microservice (low-level).

A capability could be supported by multiple business units or by a couple of teams. Those business units might be also based in multiple continents or the teams in two rooms.

Good metamodels are to an extent scale-invariant i.e. they have pretty much the same form both at a high and a detailed level. If we compared high-level and low-level metamodels, the type names would differ but their shapes should be quite similar.

Often, high-level and low-level models get built independently, leading to misalignment between the two. Components are elaborated at a high-level that have no detailed or low-level counterpart; and relationships or interactions - for example, an application integration or process flow - are present in the details that are not reflected at a higher level.

So it’s important to remember that the purpose of the top levels of your architecture models is to aggregate the underlying detail; not to eradicate it. Likewise, new metamodel concepts do not magically emerge from nowhere as we move up our hierarchies.

Building your enterprise architecture models needs to be a continuous process of reconciliation between high and low level models, checking each against the other, looking for gaps and disconnects.

We recommend you work with the lowest level of detail you have available to you, whether it’s an application integration map, a date model, or a process map. Then, use higher-level concepts to organize and aggregate that insight into how your IT and business domains work, and how they relate to each other.

This does not mean we only recommend mapping at excruciating levels of detail. Rather, we propose that you include more detailed information as it becomes available so that the modeling process is one of continual refination and refactoring of your high-level models to ensure that they tell a true - albeit simplified - story.

Important reflection points for “Principle Five: Ensure High-Level and Low-Level Alignment”:

Challenges: Architects use logical or conceptual models to represent a great deal of detail, but building these abstractions in the wrong place can negate your ability to understand impacts and trace root causes.

Abstractions are useful ways of reducing the complexity of your model. They can be used to lift your models out of the details to create an accessible overview or to decouple the ‘what’ from the ‘how’. Abstractions enable technologists and planners to focus less on the specific current technologies, processes and organisations and to talk instead about what the business and technology needs to do.

Commonly-used abstract metamodel concepts include:

As we’ve already seen in “Principle One: Control the number of component and reference types in your metamodel”, component types are useful for grouping and classifying other component types - for example, by separating the qualities and behavior the business needs to operate from actual implementations like specific applications or department-level processes.

However, abstractions can be a double-edged sword. As well as clarifying, they can also obscure and degrade your ability to create insight from your metamodel. Specifically, if you relate more physical / less abstract components via abstraction, this can create real issues in querying your model.

Here’s a real-life example of where it can go wrong, and one that comes from the best of motives:

An IT Infrastructure Manager wants to move the conversation with his business stakeholders away from discussion of specific technologies (e.g. ‘we prefer Gmail’) and focus more on the requirements for those technologies.

Instead of mapping email Applications directly to Departments, he interposes a ‘Technology Service’ layer in between them.

Now Department X uses a Technology Service called Email which is realized by the MS Outlook application.

On the face of it, that sounds sensible. All those concepts make sense in metamodel terms, but the issue is that by interposing an abstraction layer between Department and Application, we’ve now lost the ability to directly relate those two concepts.

Now, let’s say there’s a merger: Department Y is added, but Department Y uses Gmail instead of MS Outlook. If we model that in the same way, we now have Department X and Department Y both using a technology service called ‘email’ which in turn is realized by MS Outlook and Gmail. However, the Infrastructure Manager can no longer tell which department uses Outlook and which uses Gmail.

This is because we’ve lost the direct relationship because of that abstraction layer. Now when this Infrastructure Manager is charged with migrating the whole organization to a single email application, he can no longer understand what the impact of that will be.

The lesson here is to be very careful about where you use abstractions. They are an essential tool in making sense of your architecture but can do great damage in obscuring relationships if done incorrectly. In general, if the only way you can navigate from one non-abstract type to another is via an abstraction, then you could be setting up problems for the future. When abstractions act as ‘gateways’ between different architecture layers or domains, they degrade your ability to establish traceability between those domains.

Important reflection points for “Principle Six: Be Careful Where You Use Abstractions”:

Challenges: Metamodeling can be time-consuming, but Enterprise Architecture modeling initiatives must demonstrate fast time-to-value and the ongoing agility to respond to new requirements.

One reason people spend so much time debating metamodels is because they are afraid of getting it wrong. It used to be that implementing an enterprise architecture tool meant starting out with a months-long process of defining and debating the metamodel, every type, relationship, property, and list value. It demanded many lengthy meetings and heated debates over the definition of an application (we have an article for that too) because once that metamodel was implemented in the tool, it was near-to-impossible to change it.

The reasons for this were partly human and partly technical. Language and processes would become embedded and people were reluctant to change unless it really wasn’t working. The technical constraints were even greater, requiring complex and time-consuming changes to the repository configuration. This often involved coding or scripting in a language only understood by specialists or expensive contractors. In the worst of scenarios, the whole repository would have to be unloaded and reloaded and processes and queries rebuilt from scratch.

In effect, inflexible technology locked them into a waterfall delivery model.

New-generation metamodeling technology has changed all that. The flexible graph Ardoq is built on makes many of those constraints simply go away. With the right permissions settings, you can add, change, and remove new metamodel elements easily via the UI without impacting your data or the processes you’ve built on top of it.

It is now a cheap and agile process, a radical change from the lengthy, expensive process that was common with older metamodeling technology. That said, you should never merely deploy without design, trusting that feedback and development iterations will magically create the best possible metamodel. In the end, feedback on garbage will only tell you that it’s garbage.

Agility means that while design is still important, you do not need to be completely certain. It offers you the opportunity to test, experiment, and refine as you go. Metamodeling is a complex enterprise - there are a lot of variables and moving parts - so the ability to try something and then refine it is critical.

You should also always remember that metamodeling is not a purely technical process. It has a vital human and social component to it. It’s very easy to be seduced by your new-found metamodeling power into believing that you can perfectly classify every element of your organization into the perfect rational model.

Always remember the why: If you can’t communicate it, if you can’t use it to inform decisions, if you can’t embed it in yours and other teams’ ways of working, then you’ve missed the entire point of the process.

The last point is, you will never be finished (unless you’re unsuccessful - then you’ll be finished sooner than expected!). New requirements will emerge as use of your model spreads. New business and technology concepts will emerge in the marketplace which you will be asked to assimilate. It is important to collect feedback from an ever-growing user base. This will refine and sharpen the concepts and the methodology, and as they do so, your - and everyone’s - confidence in the model will grow.

Start with a core model you have high confidence in - it can be a standard like ArchiMate, Ardoq’s own Best Practice Metamodel, or your own in-house model - but don’t be afraid to deploy it without having all the answers.

Then, as the feedback rolls in, compare the proposed changes to these Seven Principles, and evolve.

Important reflection points for “Principle Seven: The Perfect Model Is Ever-evolving”: