Ardoq users know it is important to decide whether to model something using hierarchies or references. This question is discussed in detail in Should You Model Using Hierarchies or References?.

If you’ve decided to use hierarchies, the Category component type may be just the thing for you. It gives you an easy way to represent the tree of categories that organizes your content. But before you jump in and use it, you should consider the type of hierarchy you are creating - is it categorical or decompositional? Read on to learn about the difference between the two types of hierarchies and why you should only be using Category components in a categorical hierarchy.

The Category component type enables you to adopt a hierarchical organization of components in a workspace when the tree structure (i.e. the branch nodes of the tree) consists of a set of topic titles, headings or categories. An example of this is the NIST Cybersecurity Framework. NIST describes its structure as “a hierarchy of Functions, Categories, and Subcategories that detail each outcome”.

Source: NIST Cybersecurity Framework (2.0)

We model the Framework Document itself in Ardoq with an Information Artifact component, with its Document URL field containing the URL to the source document. The "Functions" in the NIST Framework are modeled in Ardoq as Category components, children of the Information Artifact. What NIST calls "Categories" are also modeled as Category components in Ardoq, children of their parent Categories creating the hierarchy. "Subcategories" in the Framework are the target against which an implementation will be recorded. These are modeled in Ardoq as Requirements that are children of their parent Categories so that they can be linked to the components in the architecture model that represent the technologies, controls and policies that are the realization of their portion of the Framework.

A page from the NIST Cybersecurity Framework

The same page modeled in Ardoq

Linking requirements to other assets, such as Controls

This approach of creating a categorical hierarchy to manage the content of a workspace may be useful to organize a variety of different component types in different workspaces. The above example will suit a workspace that represents a number of different Frameworks. The same approach can be adopted to organize representation of such things as Processes, Risks and Controls. In some of these situations it may be desirable to give the Category component type a more meaningful name. If this is desirable, we recommend prefixing the component type name with the name of the component type that is being organized: e.g. Process Category, Risk Category, Control Category.

One of the most widely used hierarchies in an Ardoq architecture model is when describing Business Capabilities. There is a subtle, but significant, difference between these hierarchies and the categorical ones described above: a capability model is a decompositional hierarchy. Each branch in the hierarchy represents a capability at a given level. The level below represents a decomposition of that capability into the more detailed capabilities that make it up. And its parent is a yet higher level capability that includes it and its siblings. It is quite possible, indeed likely, that we will wish to reason about these capabilities at different levels, including linking them with references to other components. So in this situation, the entire hierarchy is made up of the same component type as the leaf nodes. Hence, we talk about business capabilities at different levels, and we represent them in exactly that way. There is no place for Category components in this type of business capability model; all the elements in the hierarchy are of the component type Business Capability. For more details about how to model business capabilities, see Getting Started with Business Capability Modeling.

There are many similar examples of such decompositional hierarchies. We’ll illustrate this with one that is not describing capabilities: a system quality model. The quality model in ISO 25010 is widely used by architects to classify quality requirements of a system.

ISO 25010:2023 Quality Model

It consists of “Characteristics” and “Sub-characteristics”. At first glance, one might be inclined to use Category components to represent the “Characteristics” and Requirements for the “Sub-characteristics”. But the level 1 “Characteristics” are more than mere headings, titles or categories. This model is much more like a capability model, where Performance efficiency, Security and Maintainability are true quality characteristics, and whilst they are further broken down into their constituent sub-characteristics, there will be circumstances when we want to reference the level 1 Characteristics and reason about them in our architecture. To model this, we can use an Information Artifact to represent the source document, and its children and grandchildren will all be of type Requirement.

ISO 25010:2023 modeled in Ardoq

Note that you need to license ISO 25010 to use the model in your organization.

This article has introduced the Category component type and described its use in organizing the content of a workspace. It has also highlighted the difference between a categorical hierarchy and a decompositional hierarchy. Category should be used to represent the branch elements of a categorical hierarchy, but a decompositional hierarchy should consist of the same component types that are being represented in the leaf nodes (e.g. Capabilities, Requirements).