Technology Portfolio Management is relevant for you if you want to record and maintain information about the technologies used in your organization, or if you are leveraging the Ardoq IT-Pedia integration. This includes information about your key suppliers, vendor life cycles, and technologies that may be at risk from known vulnerabilities.

Related information: Use Case Solutions

Understanding the underlying technologies that support your enterprise applications and business systems is an important function of an architecture repository. It involves maintaining knowledge of such information as who your key suppliers are, where their technologies are in the life cycle, and which technologies may be at risk from known vulnerabilities. And recording the dependencies of technology components upon each other, so that the implications of change in any one element can be properly understood.

It may be tempting to record this information in fields attached to Application components, and other elements that represent your deployed estate. However, this approach involves duplication of information that will quickly turn its maintenance into a nightmare. Imagine having to update lifecycle dates and version numbers on every server that runs a given operating system each time it is upgraded.

To help overcome this challenge, this use case provides guidance on how to efficiently record and model the technologies that underpin enterprise applications and business systems.

The subject is inherently complicated, because there may be many layers of technology connected in various ways. There may also be many choices regarding the level of detail you need to reflect in your model. However, the general principle is to only model to the level of detail that is needed to achieve a desired outcome. Keep these considerations in mind as you read this article, because you may choose different options based on your particular needs.

The purpose of this Use Case is to facilitate the efficient recording of the technologies that underpin enterprise applications and business systems. At its heart is a Technology Catalog that records each Technology Product (both hardware and software) that has been, is, or is planned to be, deployed in the organization. The TOGAF Standard states that the purpose of the Technology Portfolio Catalog is:

The catalog supports the maintenance of such information as who produces the product, which vendor supplies it, the particular version or build of the product, where it is in the life cycle, whether it is an approved standard for the enterprise, and whether there are any known vulnerabilities associated with it.

The Technology Product component represents an entry in a catalog and not a running instance of the technology. Where a product has been deployed in the estate, the catalog entry will contain reference links to components of a different type that represent each running instance of the product. All catalog entries are represented with the Technology Product component type, whether they represent hardware or software products, but the running instances will use different component types depending on their nature and role within the organization. For example, databases will be represented by Data Store components, cloud platform services by Technology Service components and business application software by Application components.

In addition to recording individual products, the catalog can also record combinations of products that together form a standard stack. Standard deployments can therefore be recorded with a single link from the composite Technology Product in the catalog to each deployed instance. For example, a standard database server may be represented with a single Technology Product that contains references from other Technology Products in the catalog that represent a physical server, an operating system and a database management system.

Effective use of the catalog involves identifying where different technology products are deployed, and understanding the interdependency between technologies, both hardware and software, in the various stacks that combine to support business systems and applications. In this way, the implications of a proposed change, or a recently identified vulnerability, can be precisely understood - which applications will be affected and, in turn, which application owners, users, organizational units and business capabilities.

In addition to describing how to document your technology catalog, this article describes how to model the deployed instantiations of technologies represented in your catalog, and how these deployed instances support each other to form the technology stack and set of components that together serve up a business system or application to its users.

Organizations vary widely in the language they use to describe technology components, and the extent to which such details are exposed to business stakeholders. With this Use Case, these deployed components may represent a whole range of technology types and forms, from physical servers to virtual machines, microservices to business applications, application servers to ERP platforms, mobile apps to cloud platform services. A number of different component types are offered to model these: Server, Technology Service, Data Store, Application, Application Module. These component types are conceptually similar, giving the Ardoq modeler the freedom to choose the component types that best suit the language and culture of their organization.

Modeling the complex web of technologies across an IT estate is difficult. The danger is that the resulting model implies that every business system is dependent upon every technology. Fortunately, Ardoq’s underlying graph is able to trace the precise dependencies from catalog entries through supporting technologies and services, up to the business systems and through to the business capabilities they help to realize, and the users that rely upon them. This precision is vital if the repository is to be useful in addressing important questions, such as “which applications, and which users, are at risk from this new vulnerability, and which are not?” and “which business services will be affected by this major product upgrade, and which will not?”.

Maintenance of technology product information can easily become a major burden on IT. New products, new versions, new builds, are constantly being added to an estate, and new vulnerabilities are discovered every day. By separating the content of the catalog, with its representation by Technology Components, from running instances, represented with a variety of component types, the Use Case avoids duplication of information, minimizing the maintenance effort.

Use of the catalog to record approved standards, both individual products, and in combination as composite standard “technology stacks”, facilitates the tracking of adoption of standards across the estate, and identification of exceptions with minimal effort.

The introduction of a Vulnerability component type supports both the automated monitoring of technology vulnerabilities against the enterprise technology catalog, via integration with third-party services such as IT-Pedia, and the rapid impact assessment of individual known vulnerabilities.

The Use Case offers a range of functionally similar component types to represent deployed technologies. This allows you to choose the representation that best suits your organizational culture. If talk about microservices is limited to the development teams, use Application Module to represent them, and business-oriented visualizations can leave them out, focusing only on Applications. If, on the other hand, microservices are core to your business strategy, and everyone is familiar with them, then they can be represented as Applications. The Technology Service component type can be used to represent platforms that host business modules (such as SAP), but in some organizations, the platform as whole might be recognized as a business application that hosts more specific business applications (in which case, the SAP platform and its hosted modules will each be represented as Application components). The flexibility of Ardoq’s modeling platform supports a modeling style that suits each organization, reflecting how they use and view different technology components.

The design of this Use Case has been guided by the following four principles:

This Use Case applies the above principles in the context of understanding and managing the technologies that underpin an enterprise’s portfolio of business applications. It enables an organization to answer the following questions:

The primary component types featured in this Use Case are described below, along with guidance on how to use them to model your technology portfolio. The metamodel reflects an important distinction between the information about a product, as stored in a catalog entry, and a deployed, running instance of that product. Separating these results in a highly maintainable model, with information about a product being recorded just once and then linked to potentially many running instances (see Figure 1). The Technology Product component type is used to represent the catalog entry of any kind of technology product, hardware or software. It contains information about the precise version or build of the product, its status in terms of vendor support, and has reference links to the organization that supplies it, and to any known or active vulnerabilities. Deployed instances of a Technology Product are represented with a variety of different component types, depending on the nature of the product involved: Server, Technology Service, Data Store, Application Application Module and Interface. In this particular example, each running instance of Oracle 19c could be represented with its own Technology Service component. But, reflecting the second principle, that level of detail is not required, so we are simply recording which servers are hosting that particular database version. This modeling approach, separating catalog entries from running instances, is similar to the organization of data across multiple tables in a normalized database design (applying the third principle described above). Without it, there would be considerable duplication of information, making maintenance difficult and risking the introduction of inaccurate information (see Figure 2).

Figure 1 - Technology Product as a catalog entry

Figure 2 - Representing product information without catalog entries

The combination of components, of different types, that represent a running instance of a business application facilitates the modeling of the system and how its constituent components interact. It is not always necessary to model at this level of detail: often a single component of type Application is sufficient to represent a business application. But there might be a need to represent how that business application is made up of different components, each of which might be deployed in its own environment, for example where there is a need to document the Software Bill of Materials associated with a particular business system. See What is an Application? for a more detailed discussion of this topic. A typical business application may be represented using the component types shown in Figure 3:

Figure 3 - typical decomposition of a complex business system

Definition

An item of software, hardware, or firmware available for deployment. This is a catalog entry, not a deployed running instance.

Guidance

A Technology Product component has Deploys To reference links to deployed, running instances. It allows version, licensing, vulnerability, life cycle, vendor and manufacturer information to be recorded once rather than replicated with each deployed instance. The catalog is organized in a hierarchy with nested Folder components, with only the most specific version of the product (i.e. identifying a particular version or build of the product) being represented by a Technology Product component.

Composite Technology Product components may be defined representing standard “builds or stacks” containing multiple Deploys To references from other Technology Product components (e.g. a standard database server combining hardware, operating system and database management system Technology Product components).

Figure 5 - A composite Technology Product representing an approved standard

Definition

Represents a known vulnerability that is associated with one or more Technology Products.

Guidance

A set of Vulnerability components may be created, populated and connected to the relevant Technology Products via an integration with a third party service such as ITPedia. Alternatively, individual Vulnerability components may be created manually to perform specific analyses when vulnerabilities of particular concern are identified.

Definition

A deployed component that provides technology support or hosting services for Application, Application Module, Server, Data Store 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.

Guidance

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 component (applying the fourth principle above), which is functionally similar. Technology Service can be used to model different deployed components that together make up the software stack that supports a business application. These might include, for example, the operating system, database management system, application server and web server. It may be desirable to model each deployed instance of these, in which case the resulting model might look like Figure 6:

Figure 6 - Modeling the technology stack in detail

See the section entitled Understanding Technology Service and Technology Product in Application Hosting Metamodel for more details on the relationship between these two component types.

However, in many cases, this represents an unnecessary proliferation of components, and a “short hand” approach that describes the technology stack without representing each running instance will often be sufficiently expressive while avoiding the risk of excessive maintenance effort. This alternative, applying the second principle above, would look like Figure 7:

Figure 7 - A “shorthand” model of a technology stack running on a server

Definition

Represents a deployed physical or logical processing unit that supports an Application, Application Module, Technology Service or other Server components.

Guidance

The Server component type is offered as an alternative to the Technology Service in recognition that in some circumstances it may provide a more meaningful name. The function of the two components types is similar. It can often be useful to use Server as a composite component that represents a deployed instance of the technology stack that supports a business application (see Figure 7 and also Application Hosting Metamodel).

Definition

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.

Guidance

If one Data Store supports multiple components, or is running in its own environment separated from the application or applications it supports, it may be a standalone component (as in Figure 8):

Figure 8 - Application supported by a standalone database 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, in line with the first principle (see Figure 9):

Figure 9 - Application with embedded database deployed in Azure

It may be desirable to distinguish between a database management system and the different databases it hosts. Often a single deployment of a database management system acts as the host for multiple databases that, in turn, support multiple applications. If modeling this level of detail is desirable, it involves representing the database management system as a Technology Service component that, in turn, Supports multiple databases.

Figure 10 - Separating the DBMS from its databases

Definition

A deployed and running software solution that provides specific business 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.

Guidance

It may be part of (i.e. a child component of) an Application Group (e.g. MS Word as part of MS Office, see Figure 3) or a larger Application (e.g. SAP Finance Module as part of SAP, see Figure 11).

Figure 11 - Applications contained within an Application

Definition

A deployed and running software component 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.

Guidance

It may be a component (represented as a child component) of an Application or another Application Module, or it may be a standalone component that is supported by a Technology Service (e.g. a microservice deployed in a cloud service that supports one or more Application).

This article introduces the concept of defining catalog entries, using Technology Product components, that describe technologies that are used by the enterprise, and separating these from their deployed instances. These cover a range of technology types, from services such as operating systems, database management systems and application hosting platforms, to packaged business applications, and from application software components to physical infrastructure, such as servers. Four principles have shaped the guidance contained in this article, and we recommend that you use them to determine how you model your technology portfolio; modeling just enough detail to achieve your desired outcome, and using component types that give you a language to suit your audience.

See Technology Portfolio Management Metamodel for a more detailed description of the metamodel that is used for this Use Case.

See this presentation for more examples and suggested patterns that describe how to model different types of business systems in Ardoq.

Change Log