Software and application models

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.

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:

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.