Technology Portfolio Management Metamodel

The component, reference and field details around the Technology Portfolio Management use case metamodel

Jon Scott avatar
Written by Jon Scott
Updated over a week ago

Enterprise Architects need to understand the underlying technologies that support enterprise applications and business systems. It is an important part of an architecture repository.

There are numerous ways to define and model technologies and business systems, and depending on the organization there may be many layers of technology connected in various ways, and potentially many reasons to build the models with various levels of detail. Trying to solve this problem can be very challenging. Technology Portfolio Management: Purpose Scope and Rationale provides guidance and examples on how to decompose and model your products and technologies in Ardoq. This will help you gain a better understanding of your organization from technology to business capability.

The metamodel described in this document further explains how to structure information and connect component types through references.


Technology Portfolio Management Metamodel

Technology Product Components

At the heart of Technology Portfolio Management is the Technology Product component. This component is used to represent master descriptions of products, individual or composite, like entries in a catalog. Application software products, database management systems, operating systems and physical products such as servers are all represented in the same way with the Technology Product component type. These components do not represent operational instances of those technologies, as there may be multiple instances for each technology product, each of which may have its own associated data. These technology products are deployed throughout the organization and understanding what and where these products are deployed helps organizations stay resilient.

An example approach to representing a server that is running an operating system and a database management system is seen in Figure 1.

Figure 1 - Various technology products and where they are deployed

In Figure 1 you have a physical instance of a Server. You can also see the OS and DBMS technology product(s) deployed to that Server instance. As well as the specific HW of the Server instance.

Structuring your Technology Products

Technology Products have their own identifiers and properties (e.g. SKU, Manufacturer Lifecycle) which remain true wherever they are deployed. They also have version numbering schemes to represent dot- and patch-versions. Technology Products are arranged in a hierarchy, with the overall Tech Product at the top level, the versions as its children, the sub-versions as their children, and so on.

This allows the catalog to document different versions of products in detail if required. Make sure to name your Technology Products with the technology name and the version for an easier way to identify the product. For more information on structuring your technology products please see the Technology Portfolio Management: Purpose, Scope, and Rationale article.

When deciding on where you put your technology product components, our recommended approach is to store them in a single technology product workspace and use folders to structure technology components accordingly. This allows for easier management of the technology products as well as a single workspace when leveraging surveys.

Your Own Technology Products

You may also choose to define composite Technology Product components that represent standard combinations of other Technology Product components. These are connected with the Deploys To reference. An example, shown below, might be a catalog entry that defines a standard database server in your organization:

To see more examples of how to model technology products check out the Modeling Complex Business Systems article in our knowledge base.

Technology Product Fields

On top of a descriptive naming convention, technology products should have a description of the product and what it does.


Field Type



Approved Standard

Date Range

Indicates if the product is an approved product. Used to identify systems that don't comply with company standards

Date range field used to indicate when a product will become an approved standard and when that standard will expire

Has Vulnerability

Indicates if a particular technology product has a vulnerability that hasn't been resolved or mitigated by the manufacturer

Checkbox will be checked if the component is associated with a technology product that has an impacts reference from a vulnerability component

Product Details


URL link to an internal or external product page

Technology Product Lifecycle Fields


Field Type




Date Range

When the product was made available for purchase


Date Range

When support started for the product

Extended Support

Date Range

When a manufacturer or 3rd party offers extended support. Typically after the product lifecycle ends

Out of Support

Calculated Checkbox

Indicates if the product is outside any and all product support windows.

Calculated by comparing the end of support and extended support to today's date

The technology product lifecycle fields listed are a subset of fields that can be used to document the lifecycle of technology products. Lifecycle fields can easily be extended to meet the specific needs of the organization.

Out of Support

The Out of Support field comes out of the box as a calculated checkbox that assesses the end dates of the Support and Extended Support fields and checks as true or false. The checkbox field type is used for ease of use when creating reports and presentations. However, the field type can easily be changed to another field type (ex. calculated date-time) to meet the needs of your organization.

Technology Product References

The Deploys To Reference

Outgoing References


Deploys To

(Technology Product

→ Deploys To →

Technology Service)

Illustrates the relationship between the product and the operational instance of that product. Can reference several different component types such as;

  • Application

  • Application Module

  • Interface

  • Technology Service

  • Server

  • Data Store

  • Technology Product

  • etc

Is Realized By (Technology Product

→ Is Realized By →

Technical Capability)

Illustrates the technical capability that the product helps deliver. Ex. Blue Prism

We use the Deploys To reference type to link Technology Products to their instantiated counterparts. For example, a running instance of a database management system would be represented as a Technology Service. It is a deployed instance of the software that has an entry in the technology catalog (the Technology Product component), hence the use of the Deploys To reference type to show the connection between the Technology Product (an abstract catalog entry) and its deployed instances (the Technology Service components).

Incoming References


Supplies (Organization →Supplies →

Technology Product)

Used to show what organization the owner/manufacturer/supplier of the product. Microsoft supplies Windows 11.

Impacts (Vulnerability → Impacts →

Technology Product)

Used to show when a technology product has a documented vulnerability associated with some aspect of the product

Organization Components

While the organization component type is a familiar concept as seen on our Organizational Management use case guide, we will use the same Organization component to represent the external organizations we interact with. We recommend creating a Vendor or External Organization workspace to help separate your internal and external organizations. The outgoing Supplies reference is used to represent the owner, manufacturer or supplier of the product. An Owns reference can be used if you need to further delineate between the manufacturer and the supplier as they may not always be the same.

Outgoing References


Supplies (Organization →Supplies →

Technology Product)

Used to show what organization the owner/manufacturer/supplier of the product. Ex. Microsoft supplies Windows 11.

Vulnerability Components

One of the main reasons for documenting and managing your technology landscape is to bring visibility to where you might have risks associated with technology. That can be done by capturing the product's lifecycle or identifying whether or not there is a vulnerability associated with the product. Capturing technology vulnerabilities can be a very arduous process so we strongly recommend using a service that provides the vulnerability to product linkage where possible.

Outgoing References


Impacts (Vulnerability → Impacts → Technology Product)

Provides the linkage between Vulnerability and the Technology Product. It represents that a specific vulnerability is associated with that specific technology product version.

This reference is used to calculate the following fields: Has Vulnerability calculated field

Servers, Technology Services and Data Stores

There can be many combinations any mix or match of services that help support and deliver an application. This can be anything from application modules, or microservices, to databases, VMs, or servers. While impossible to address every situation, we have covered some core approaches. In this section, we will focus on the technical and hosting services that support applications.

Server Components

As covered in the IT Lifecycle Management and Application Hosting Metamodel articles, Servers represent a physical or, optionally, logical processing unit that supports an Application, Application Module, Technology Service, or other Server components. Its function is similar to that of a Technology Service. The Server component type is offered as an alternative that may provide a more meaningful name but is conceptually similar.

Technology Service Components

A component that provides technical support or hosting services for an Application, Application Module, Interface, Server or other Technology Service components. Examples include operating systems, database management systems, virtual machine platforms for operating systems or applications, RPA and workflow platforms, data warehouses, BI and reporting platforms.

If the component would be recognized by business users as a business system in its own right, it may alternatively be represented with an Application/Application Module component.

For more information on technology services please refer to the Technology Portfolio Management: Purpose, Scope, and Rationale article.

Data Store Components

A persistent dataset that may consist of one or more linked tables or files containing structured data, such as a database (as distinct from its host database management system, which is represented as a Technology Service). It may directly support users through a dedicated user interface, or support Application, Application Module or Technology Service components. If one Data Store supports multiple components, it may be a standalone component. It may alternatively be a constituent part of an Application, Application Module or Technology Service component, in which case it will be represented as a child component. For more information on technology services please refer to the Technology Portfolio Management: Purpose, Scope, and Rationale article.

Applications and Application Modules

Now that we have defined the technical and hosting services we can wire them up to our applications. Once done we will have a view from the application down to the technology stack.

Application Components

An Application is a deployed and running software element that provides specific business capability or technology capability, performs a defined task or analyzes specific information. It has meaning for, and its name will be recognized by, its business users. It may be part of (i.e. a child component of) an Application Group (e.g. MS Word as part of MS Office) or another Application (e.g. SAP Finance Module as part of SAP).

Application Module Components

A deployed and running software element that has meaning for, and will be recognized by, the team that developed or supports it. It is unlikely to be referenced, by name, by business users, as its role is to support one or more applications that they do recognize. It may be a component (represented as a child component) of an Application or another Application Module, or it may be a standalone component (e.g. a microservice that supports one or more Applications).

For more information on Applications and Application Modules please refer to the Technology Portfolio Management: Purpose, Scope, and Rationale article.

‘Has Vulnerability’ Field

There is only one new field introduced across Applications, Application Modules, Interfaces, Technology Services, Servers, and Technology Products and that is the Has Vulnerability field. This field is used to trace down the technology stack from the Application to the products and identify if vulnerabilities are associated with the technology products used in the application.


Field Type



Has Vulnerability

Calculated Checkbox

Indicates if a particular technology product has a vulnerability that hasn't been resolved or mitigated by the manufacturer

Checkbox will be checked if the component is associated with a technology product that has a impacts reference from a vulnerability component

As seen on the technology product earlier in this document, this field is also used across a wide variety of component types so that one can use this information to run reports and populate dashboards around applications and capabilities that are at risk due to technical vulnerabilities.

Gremlin Code

This section contains the Gremlin Code used to implement the Calculated Fields of the Technology Portfolio Management use case.

Out of Support

This contains the Gremlin Code that calculates whether a technology product is outside all product support windows. The code checks the Support and Extended Support end dates and compares them to today's date. The checkbox will be marked as true if Support end date has passed and there is no Extended Support end date, or if there is an Extended Support end date but it has passed.

today = new Date().format('YYYY-MM-dd');

project('id', 'name', 'value').
by(choose(and(has('support_end_date',lt(today)), hasNot('extended_support_end_date')), constant(true),
choose(and(has('support_end_date',lt(today)), has('extended_support_end_date',lt(today))), constant(true),

Has Vulnerability

The Has Vulnerability field is a binary checkbox field that searches down the path along the Deploys To, Is Supported By, and Impacts references to determine if any associated component has a connection to a vulnerability. If any component in the path does have a reference to a vulnerability then it is marked as true.

project('id', 'name', 'value').
union('ardoq_parent'),'Deploys To'),'Impacts'),
out('Is Supported By')

Change Log






Jon Scott


Did this answer your question?