Foreword: This is a long read suitable for those who want to understand how to model various problems at a deeper level
​
One of the most common questions new users of Ardoq ask in building their architecture models is when to use hierarchies versus references to represent relationships between components.

However technical this question may seem, it’s not a trivial one: How you structure your model will determine how people navigate it, how they query it, and how they understand it overall.

Enterprise Architecture models are naturally complex, but structuring your model correctly makes that complexity manageable. On the other hand, a poorly structured model only adds to the confusion.

So it’s important to get your architecture modeling right.

Here’s the good news: There are some principles on how to structure your models that are easy to understand, and will give you confidence in the models you build.

Let’s start with some fundamentals.

Enterprise architecture is about modeling the elements that make up your organization - its processes, applications, technology infrastructure, data, products, and departments - and the relationships between them.

Ardoq is built on a graph database, which means those elements are represented as components and the relationships between them as references.

And on those references are stored (among other things) the IDs of the two components at either end of them. This is how we capture and interrogate the relationships between components.

But not all relationships are modeled as a reference.

One type of relationship - a parent-child relationship - doesn’t use references at all. Instead, it uses a direct link between two components.

In this case, the ID of the parent is stored directly on the child component and not on a reference between them.

This makes the parent-child relationship different from a reference in a couple of ways:

This may suggest that the parent-child relationship is a poor substitute for using a reference. But in fact, it’s one of the building blocks of enterprise architecture precisely because it is less flexible.

The parent-child relation forces you to structure your information formally.

More accurately, it forces you to structure your enterprise architecture data into a series of linked taxonomies.

What does that mean? Let’s take a look.

As we already saw, enterprise architecture models your organization by breaking it down into a series of different domains, such as the processes it carries out, the applications it uses, the departments that make it up, the technologies it runs on, or the locations it operates from.

And each of these domains can be described at different levels of detail.

For example, we might say the enterprise is located in France. But if we want to be more specific we might say that it operates in Paris; or if we want to be even more specific, that it is based in a specific arrondissement, or on a particular street, or on a particular floor of a particular building.

In the same way, I might want to talk about my whole ERP system, or just its Accounting module; or the whole Finance Department or just the Accounts Reconciliation Team; or the whole Employee Onboarding process, or just the steps that set up the new employee’s system accesses.

Whichever area of the architecture I want to talk about, I potentially want to be able to talk about it at a high level, but also to dive into the detail.

Technically, this process is called decomposition. It means we break each concept down to look at its constituent parts.

The practical effect of decomposition in your enterprise architecture is that each domain - processes, business capabilities, applications, information, organization structure, technologies, and more - becomes a hierarchy, a structure that breaks each domain into progressively smaller parts.

It’s these hierarchies that enable us to look at the whole organization from a high level, and then to drill into the details.

To be effective in drilling down, these hierarchies need to be more than just convenient data structures. They have to have meaning.

For example, all the sub-capabilities under the overall Finance business capability have something in common: They all concern the processing of financial transactions.

As a result, these hierarchies form taxonomies - classification schemes that break knowledge about a domain into its constituent parts.

Taxonomies are a cornerstone of knowledge management.

Think of the Kingdom > Phylum > Class > Order > Family > Genus > Species taxonomy used to classify the animal world, or the Dewey Decimal Classification used in libraries - or even the ‘Shop By Department’ menu on amazon.com!

We intuitively use taxonomies to navigate a knowledge space.

An Application taxonomy

A Location taxonomy

Consider this example: You’re shopping for running socks in a big online store. You navigate to the Sports and Fitness department, then to Running Clothes, and are surprised to see, alongside search results for running socks and shoes, results for treadmills.

Most of us would agree there’s a relationship between running socks and treadmills. But most of us would agree that treadmills are not running clothes.

Equally, if you are looking to order a treadmill, you might be surprised that they aren’t categorized under Exercise Equipment.

This kind of confusion happens when we travel down a hierarchy expecting each level to represent a refinement of the last, then the meaning abruptly changes.

But it happens a lot with inexperienced architecture modelers.

Process modelers build a process hierarchy, then at the lowest level want to show the applications each task uses, and so they add those apps as child components.

Or application architects representing the servers those applications run on as child components.

In both cases, the hierarchy may make sense to the modeler, but chances are it won’t to most other people.

So taxonomies don’t just represent progressively lower levels of detail, they also have consistency in terms of meaning. This is what makes them understandable, and if they’re understandable, people can navigate them to find what they’re looking for.

So hierarchies decompose a domain into progressively lower levels of detail and have a consistent meaning.

But even for experienced architects, it’s not always intuitive what the different levels of a hierarchy should be. So here are a couple of tests taken from the world of data modeling: Functional Dependency and Cardinality.

Ignore the fancy names. Functional dependency asks a very simple question: “If this thing ceased to exist, would this other thing?”

Say I have a hierarchy of Locations, like Europe > UK > London > Stratford. If Europe ceases to exist (heaven forbid!) by definition Stratford does too.

But if I have a Department that is based in Stratford, they don't have an automatic functional dependency with Stratford. Even if Stratford ceased to exist they could still (relocation expenses allowing) move to Chicago.

So modeling a Department as part of a Location hierarchy would be bad modeling because a Department doesn’t have an automatic functional dependency on Location.

Likewise, cardinality asks another simple question: For each one of these things, how many do I have of this other thing?

So we might say that each Location can house many different Departments. From a decomposition perspective that sounds like Department could be a child of Location.

But wait. One Department may be based in more than one Location. So while our Oslo office houses both our Sales and our Marketing department, our Sales Department is also based in Copenhagen (and in London, and in New York).

So the relationship between Department and Location is many:many. One Location has many Departments, and one Department has many Locations.

So the general rule when faced with two component types that a) do not share a functional dependency and b) have a many:many relationship is that they should not be part of the same hierarchy.

If you follow the rules above, you’ll end up with a series of hierarchies or taxonomies that represent the different domains of your enterprise architecture - from processes to application to organization units - in progressively lower levels of detail.

But these alone don’t answer our modeler’s questions: Which applications does this task use; or which servers does this application run on?

This is where we use references to represent these relationships.

There are many types of references with many different meanings.

Some represent dynamic flows, such as the flow of information from one process step to another, or integrations between applications

Some represent preconditions or dependencies, such as the fact an application runs on a server

Some represent roles, such as the fact a person owns a particular process or is an expert in a particular technology.

But in nearly every case, the reference does not represent a functional dependency: That process step could take information from another source, or a different person could own that process.

And they often represent many:many relationships: That application might run on many servers, but those servers may also be running more than one application.

The end result of this is that your enterprise architecture will consist of a series of hierarchies - or taxonomies - for each domain you model and those hierarchies will be linked together using references.

Formally, this is what’s known as an ontology.

Ardoq makes building and linking separate taxonomies easy.

The workspace is the natural place to build each taxonomy. Not only are they convenient ways to structure your data by category, but their permissions model also allows different roles to manage each part of the architecture.

So your process modeler can build their processes in a Business Process workspace and link to the applications stored in an Applications workspace managed by an Application Architect.

Each workspace model should represent the hierarchy of component types in your taxonomy.

In some cases, there may be a single component type that can have children of the same type (e.g. Business Capability > Business Capability > Business Capability).

In other cases, they may be represented by different types (e.g. Application Group > Application > Application Module).

The differences are largely semantic.

In each case, the taxonomy should represent a distinct domain of your architecture (e.g. process or technology). If one architecture domain (e.g. Process) decomposes to another (e.g. Department), that’s a sign you’ve got something wrong.

Also, don’t worry if you don’t have hierarchies at all in a workspace - for example, you just have a flat list of applications or of countries.

Generally, we introduce hierarchies when we want more detail about a domain, so when you’re starting out, you’re often just linking flat lists.

And of course, because we know that many people don’t want to worry about how they model at all, you can always start with a standard model, such as TOGAF, ArchiMate, or Ardoq’s own best-practice metamodel.

Whichever course you choose, having a well-structured enterprise architecture is more than just an academic modeling exercise. It’s the foundation for all the analysis, insight, and value you as professional modelers can bring to your organization.