Modeling application components in CMDB

06.09.2025

The application is one of the basic entities used by most organizations that are starting to use the CMDB Configuration Database. The others are Devices (Hardware), Servers (an entity representing the operating system, serving the application), data sources (databases) and data exchanges between applications (API, messaging, batch). From the perspective of enterprise architecture, the connection of applications to services, processes, capabilities (business layer), connection to information (ownership and acquisition of data, primary assets according to NIS2), connection to the organization (teams and roles that use the applications, business owner, IT owner, key user, chief analyst) and connection to technologies/platforms are also important. We will focus on the latter area, which is key for planning migrations, technology debt or cloud strategy, in this article.

The breakdown of an application into individual components, their cooperation (communication) and connection to infrastructure, networks and locations is often a subject of detailed diagrams and documentation describing security, redundancy, scalability and many other aspects. This information is available to us in the form of various unstructured (PDF, Word, PowerPoint) or semi-structured (diagrams created in the appropriate tool) data. In addition, we need to record this data in a structured form. This will allow us to link application data with lower layers and provide data for planning changes, resolving incidents, identifying dependencies, threats and vulnerabilities, risk assessment, rationalizing applications, etc. At the same time, it is advisable to have flexibility in the extent to which we record this information. Let's imagine it in the following example.

In the application catalog, we record, in addition to other information, basic information about the technologies used in the following breakdown on the Architecture tab:

  • Front end / UI
  • Application logic (Back-end)
  • Data layer
  • Integration and messaging
  • Security and network components
  • Monitoring, management and operation support
  • Specific auxiliary services

This will allow us to provide a quick overview of the application architecture and not be limited to the basic Client - Application Server - Database schema. The form below will allow us to easily and quickly record the use of static content providers, reverse proxy/load balancers, API gateways, caches, integration components, identity providers, web application firewalls, secrets managers, logging, monitoring, CI/CD pipelines, schedulers, file processing, AI/ML components or notifications.

Use of a static content provider, reverse proxy/load balancer, API gateway, cache, integration components, identity provider, Web Application firewall, Secrets manager, logging, monitoring, CI/CD pipeline, scheduler, file processing, AI/ML components or notifications.

Figure 1: Architecture tab in the Application Catalog

This overview provides information about the technologies used but does not show the connection to specific servers on which the components run and is not specific to specific application instances. For example, a production instance can be significantly different from a test instance (different infrastructure, high availability, failover and clustering solutions, etc.). This is enabled by the Application Components entity, which represents the connection between the Application Instance and the OS Server (Machine) with the component classification, see Architecture above.

Binding of the Application Instance and OS Server (Machine) with the component classification, see Architecture above.

Figure 2: Application Components Overview

 

Binding to Machine will allow us to draw a diagram of the application infrastructure and display On premise and Cloud components, identify hardware redundancy or, conversely, the risk of a single point of failure.

On premise and Cloud components, hardware redundancy or, conversely, the risk of a single point of failure.

Figure 3: Infrastructure diagram

We can go even further in the record and capture the communication of individual components. We record the source and target application components, their IP addresses, the port used and the protocol. This overview will allow us to get an initial idea and identify potential weaknesses when using outdated protocols. We can also describe the communication from the perspective of ensuring authenticity, integrity, confidentiality, use of cryptographic primitives and their parameters, protection against downgrade attacks or readiness for post-quantum cryptography.

We can also describe communication from the perspective of ensuring authenticity, integrity, confidentiality, use of cryptographic primitives and their parameters, protection against downgrade attacks, or readiness for post-quantum cryptography.

Figure 4: Application component communication

 

Sometimes we feel frustrated by outdated technologies that applications use and cannot be replaced in the long term. The primary goal should be to have an accurate idea of ??the current state so that it is possible to assess risks, propose options and plan the necessary migration. We can start this right away and begin with the items that we are responsible for ourselves or in a team with colleagues. The application catalog, which records technologies at several levels (Architecture, Application Components and Application Component Communication tabs), will allow us to achieve this practically by gradually updating information from the highest level to the most detailed one.

Read more about configuration management and ObjectGears CMDB.