This documentation supports the 19.08 version of BMC CMDB.

To view an earlier version, select the version from the Product version menu.

Software and application models

Software and application models are used in service impact modeling, configuration, license management, and reporting use cases. Software and applications on a computer can be modeled in two ways, each of which represents a different aspect of the software:

  • Installed software and applications on a computer are modeled using the BMC_Product class.

  • Running instances of software and applications are modeled using BMC_SoftwareServerBMC_Application, and BMC_ApplicationSystem classes.  Instances of these classes capture the deployed run-time aspects of long-lived applications and not the installed aspects.  Running software modules on a software server such as a J2EE application server are modeled using the BMC_ApplicationService class.

This section provides information about modeling installed software and running instances of software and applications.

Installed software model

Each unique software or application installed on the server, workstation, laptop or desktop is modeled as a distinct BMC_Product Configuration Item (CI) instance.

The BMC_Product class is used to model commercial and custom software installed on servers, desktops and laptops. However, the BMC_Product class can also be used to model other types of software, such as software suites, software bundles, plug-ins, components, and patches. In such cases, the ProductType attribute can be used to differentiate the software type.

We recommend that patches should be federated rather than imported into the CMDB, even though patches can be modeled by using the BMC_Patch class.

Basic installed software on a single server

The following diagram shows three BMC_Product Configuration Item (CI) instances that are connected to the computer system through the BMC_HostedSystemComponent relationship with Name=INSTALLEDSOFTWARE

The BMC_HostedSystemComponent relationship is a weak relationship. A weak relationship means that the destination CI cannot exist without its source CI, the computer system. When the computer system is deleted or marked as deleted, all the weak destination CIs are also deleted or marked as deleted, only if CascadeDelete option is enabled for the relationship. Another important aspect of this model is that the product CIs are not shared among the different computer systems even if the product CIs represent the same software.


Same software installed on a second server

The following diagram shows a second server that has the same three products installed on it. For example, even though Oracle Java Platform is installed on both servers, and both servers have the same version installed (1.4.2), each installation is modeled as an independent CI.

Installed software is modeled in this manner due to incident, change, license management, and impact use cases. For example, a change record should be directly related to the precise CI being changed. If there were a single shared CI representing instances of the same software on multiple computer systems, then change and impact modelling would not show appropriate results. Licensing use cases also count the number of product CIs in the infrastructure and require that each be modeled distinctly.


Two versions of installed software

In some cases, there may be two versions of the same product installed on a computer. Each of the product versions are distinct CI instances which can differ by market version, version number, or both. The different instances are differentiated by the MarketVersion and VersionNumber attributes.

Runtime aspects of installed software model

The BMC_SoftwareServer class represents the run-time aspects of installed software and applications. Instances of this class represent running software programs on the server. Typically, long running applications on servers such as webservers, J2EE servers, database servers, and daemons are all modeled using this class. One installed product CI (BMC_Product) can be related to multiple software server CI instances (BMC_SoftwareServer), representing multiple running instances of the same software.

Simple software server

A software server is a running instance of an installed product. For example, the following diagram shows a Microsoft IIS Webserver running on a computer. This is represented with two CIs with the appropriate relationship:

  • BMC_Product CI is used to represent the installed software known as Internet Information Services 7.5.
  • BMC_SoftwareServer CI is used to represent the running instance of Microsoft Information IIS Webserver 7.5. Two important attributes that you need to populate are:
    • SoftwareServerType – Lists various types of software servers such as webservers, database servers, and so on. If you cannot find the software server to match one of these enumerations, set SoftwareServerType to Other and then set the OtherSoftwareServerType attribute value.
    • OtherSoftwareServerType – Used to extend the type software server CI where you set SoftwareServerType to Other.
  • BMC_Dependency with Name=APPLICATIONSYSTEMPRODUCT is used to represent the relationship that connects BMC_SoftwareServer with the appropriate BMC_Product.
  • BMC_Dependency with Name=APPLICATIONSYSTEMCOMPUTER is used to represent the relationship of a software server running on a computer system.

For software servers that are running as a part of a software cluster, see Software and hardware cluster models.

Not every installed product CI requires a software server CI because there can be installed products that are not running. Every software server CI has an installed product CI, however, from a modeling perspective, one can model software server CIs but not have any associated product CIs.

Software servers that depend on other software servers

It is common for software servers to depend on each other and this is represented by a BMC_Dependency relationship with NAME=APPLICATIONSYSTEMDEPENDENCY.

The following diagram shows the BMC Remedy AR System Mid Tier BMC_SoftwareServer CI on computer rds1426 dependent on the BMC Remedy AR System server BMC_SoftwareServer CI through a BMC_Dependency relationship. For sake of simplicity, it does not show the installed products for each of the software servers.


Inconsistent discovery of installed software

Two discovery providers can  discover the same product (such as Microsoft SQL Server 2008) on two different servers. Each discovery provider may provide different values for the BMC_Product ModelManufacturer, and Version attribute fields due to differences in how they acquire this information. For example:

  • One provider may return Microsoft SQL Server 2008.
  • Another provider may return Microsoft(R) SQL Server 2008.

Having this type of inconsistent data in the CMDB could lead to incorrect licensing counts and other reporting issues.

The important BMC_Product CI attribute values that require consistent values across all CIs in the CMDB, and which need to be reconciled are:

  • Name
  • Model
  • ManufacturerName
  • MarketVersion
  • VersionNumber

Upgraded software

Upgrading a piece of software to a newer version on a computer can be modeled by updating the version for the existing CI, which is done automatically by BMC Discovery.

Uninstalled software

Software that has been uninstalled from a computer is modeled by marking the appropriate CI as deleted (rather than hard deleting it). The CI for the uninstalled software that is marked as deleted so that information attached to that CI (incidents, licence information, and so on) is retained.

Operating system and low-level software model

The BMC_SystemSoftware class and its subclasses store information about operating systems and other low-level software that manages computer resources.

For example:

  • Operating systems are modeled using the BMC_OperatingSystem class

  • BIOSes and firmware are modeled using the BMC_BIOSElement class

  • Virtualization hypervisor software is modeled using the BMC_VirtualSystemEnabler class

Logical high-level application model

Complex software is often hierarchical in nature. For example, a web application may be composed of a database, a web server, and an application server. Although the BMC_SoftwareServer class is used to model the lowest level components of such applications, other classes exist to model the higher level parts. These classes are:

  • BMC_Application
  • BMC_ApplicationSystem
  • BMC_ApplicationService

High-level application structure

A BMC_Application CI represents a high-level application that is important to the business. For example, a BMC_Application CI might represent the holiday bookings web application that is used internally in a business. That application is made up of a database and a web server, which are modeled as BMC_SoftwareServersSoftware servers composing an application need not be modeled if it is not required for your environment.

Multi-level application structure

If more than two levels (BMC_SoftwareServer and BMC_Application) are needed, further levels of an application's structure are modeled by the BMC_ApplicationSystem class

BMC_ApplicationSystem models the parts of an application that are at a higher level than the BMC_SoftwareServer class, but lower level than the BMC_Application class.

The following diagram shows a multi-level application structure. Applications, such as Remedy Service Desk and Remedy Change are recognizable to users in business. Therefore, they belong to the BMC_Applications class. The applications are developed on top of the AR Server and the AR Server, in turn, relies on lower level components and is modeled as a BMC_ApplicationSystem. The lowest level components, modeled as BMC_SoftwareServers, are the BMC Remedy AR System Server and BMC Remedy AR System Mid Tier.

Software components running in an application server

The BMC_ApplicationService class is used to represent software components running in an application server. For example, a J2EE application is represented as an instance of BMC_ApplicationService  class and not BMC_Application class.

The following diagram shows two J2EE WAR modules running on an Apache Tomcat application server.

The application server itself is modeled as a BMC_SoftwareServer.


An application represented by a BMC_Application CI can contain one or more application services. For example, in the following diagram, a claims application is represented that contains two application services.

Normalization of discovered software

The BMC CMDB Product Catalog (PC) together with the CMDB Normalization Engine (NE) provides consistent and standardized values for these important attributes.

  • ModelManufacturerName and MarketVersion attribute values are attributes that can be normalized by the Normalization Engine after appropriate normalization rules and Product Catalog entries are created.
  • C, T, and I (CTI) attribute values for the BMC_Product CI can be updated in Product Catalog. By updating the CTI values through Product Catalog, updates are also made to all related BMC_Product CIs of the same name in Product Catalog.

Application characteristics

Applications have characteristics that help you determine the best way to use CDM in your modeling strategy. The following table maps the characteristics of an application to the type of class that you can use to model that application. All objects and relationships are not required to model certain types of applications. For example, patch information may not be required in the case of software license management.




Run-time aspect

Running instances of applications and software servers

BMC_SoftwareServer, BMC_ApplicationInfrastructure

Installation aspect

Identifies the product that is installed, its version, and any patch


Service aspect

Business applications. (For business applications supporting a particular function, such as payroll and trading, use the BMC_BusinessService class.)


The following figure shows how the installed, run-time, and service aspects of an application relate to each other.

Applications running on servers

The BMC_SoftwareServer class represents the deployed, run-time aspects of applications; in other words, the instances of software actually running on a server. You instantiate this class to capture long-lived, server-type applications in your environment. When modeling applications, you must remember this distinction. To model static, installed components such as Microsoft Excel or Microsoft Word, create a BMC_Product instance.

You can also use the BMC_Product class to model noncommercial products, such as in-house software. One application can be installed once, yet have multiple instances running. For example, you can create a BMC_Product instance to represent the installed version of WebServer and create several BMC_SoftwareServer instances to represent actual instances of WebServer, one listening on port 80, another on port 8000, and a third on port 8080.

For complete descriptions of the classes described in this section for modeling applications, including examples of usage, see the BMC CMDB Data Model Help. For more information about using the BMC_Product class to model components, see Software inventory models.

For example, you can model a WebLogic application first by instantiating the BMC_Product class (to indicate where it is installed, the number of licenses, product name, and version). To add the run-time aspect, you can instantiate a BMC_SoftwareServer class. The following figure shows an example of this model, where two instances of a WebLogic application server (server1 and server2) are actually instances of the same installed product.

Accounting for the run-time aspect of the application in this context is very important for understanding the impact of an application on a business service. You must consider capturing WebLogic patches by using the BMC_Patch class, because the patch will then be connected to the service through the installed product, run-time, applications and, ultimately, the service and its relationships. Consequently, an IT administrator responsible for updating patches on WebLogic would understand how the change relates to the business that WebLogic supports.

Applications running on application servers or systems

The BMC_Application class stores information about standalone applications, applications deployed on servers (such as SAP), and applications deployed on distributed systems (such as SAP).

The BMC_ApplicationInfrastructure class stores information about the framework that supports applications in a distributed or composite system. This class represents the platform to model your applications. For example, you would model SAP® as an instance of BMC_ApplicationInfrastructure. After an application is deployed in that platform, it can run on any application server in the SAP environment. An application can be hosted by different types of environments: an application server or application system, or a physical or virtual system.

To model applications to run directly on top of an application server or application system, relate an instance of the BMC_Application class to a hosting BMC_ApplicationInfrastructure instance.

In this model, the application has only one relationship. A dependency on the application infrastructure hosting the application. This dependency is modeled by a BMC_Dependency relationship, as illustrated in the following figure. When using the relationship, set the Name value to DEPLOYEDAPPLICATION.

An application infrastructure cannot have any direct relationship to computers. Only applications and software servers have relationships to computers.

This model can also be applied to an application or set of applications that support or collaborate to provide a particular business function. For example, an Oracle® application infrastructure supports two applications, TimeCard and HR personal data, both stored in the BMC_Application class. The two classes relate to each other through the BMC_Dependency relationship, meaning that both the TimeCard and HR personal data applications are dependent on the supporting Oracle application infrastructure. To decompose the system into its functional components, relate an instance of this class to its component BMC_SoftwareServer instance with the BMC_Dependency class.

Applications running on computer systems

To model applications to run on computer systems (physical or virtual), relate an instance of the BMC_Application class to a hosting physical or virtual BMC_ComputerSystem instance.

Relationships for applications

The relationships for modeling applications are described in the following table.


Relationship class

Value of Name attribute

Application infrastructure hosting the application.



System hosting the application (mandatory).



Operating system running the application (optional).



Product representing the installed software of which this application is an instance (optional).



Business application and service models

To model the business aspect of applications, use the BMC_BusinessService class. Business applications support a particular business function (such as payroll or trading) and are, generally, made up of a set of applications, servers, and databases that collaborate to provide a particular service.

The following figure illustrates a business services model.

In this model, the BMC_BaseElement name is typically an application or database.

Was this page helpful? Yes No Submitting... Thank you


  1. Thomas Hammer

    Under "Software components running in an application server" we can see an example with class BMC_APPLICATIONSERVICE. The relationship class in that specific diagramm is a black line without any description. May I ask you to 1) Add a description as available for the other relationships (e.g. Dependency, Component, etc.) 2) color the lines to make it clearer (red, green, etc.) Thank you very much in advance

    Nov 14, 2019 09:17
    1. Kanchana Iyer

      Hello Thomas,

      Thanks for your suggestion. We will incorporate your suggestions.



      Nov 14, 2019 10:14
      1. Kanchana Iyer

        Hello Thomas,

        We have incorporated your suggestions.



        Jan 05, 2020 10:09