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.

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.

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.

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.

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

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.

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).

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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

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.

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.

Change Log