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
Running instances of software and applications are modeled using
BMC_ApplicationSystemclasses. 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
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.
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
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
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
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_ProductCI is used to represent the installed software known as Internet Information Services 7.5.
BMC_SoftwareServerCI 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
SoftwareServerTypeto Other and then set the
OtherSoftwareServerType– Used to extend the type software server CI where you set
APPLICATIONSYSTEMPRODUCTis used to represent the relationship that connects
BMC_SoftwareServerwith the appropriate
Name=APPLICATIONSYSTEMCOMPUTERis 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
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
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.
BMC_Product CI attribute values that require consistent values across all CIs in the CMDB, and which need to be reconciled are:
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.
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
BMC_SystemSoftware class and its subclasses store information about operating systems and other low-level software that manages computer resources.
Operating systems are modeled using the
BIOSes and firmware are modeled using the
Virtualization hypervisor software is modeled using the
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:
High-level application structure
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_SoftwareServers. Software 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_Application) are needed, further levels of an application's structure are modeled by the
BMC_ApplicationSystem models the parts of an application that are at a higher level than the
BMC_SoftwareServer class, but lower level than the
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
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
The following diagram shows two J2EE WAR modules running on an Apache Tomcat application server.
The application server itself is modeled as a
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.
MarketVersionattribute 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_ProductCI can be updated in Product Catalog. By updating the CTI values through Product Catalog, updates are also made to all related
BMC_ProductCIs of the same name in Product Catalog.
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.
Running instances of applications and software servers
Identifies the product that is installed, its version, and any patch
Business applications. (For business applications supporting a particular function, such as payroll and trading, use the
The following figure shows how the installed, run-time, and service aspects of an application relate to each other.
Applications running on servers
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
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
BMC_Application class stores information about standalone applications, applications deployed on servers (such as SAP), and applications deployed on distributed systems (such as SAP).
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
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
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
Relationships for applications
The relationships for modeling applications are described in the following table.
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.