Page tree

Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Skip to end of metadata
Go to start of metadata

This section presents the simplest approach to service modeling. You can use simple service models as a starting point to build more granular or complex service models.

Before you start modeling

Before you start creating an impact service model, you must find out which components support the entity you are going to model. This section describes modeling a simple application. Therefore, before starting to create the model, you need to know which computer systems provide the infrastructure that supports the application.

The computer systems must be defined in the BMC ProactiveNet Server by either adding them as devices in the BMC ProactiveNet Administration Console or by publishing them from BMC Atrium CMDB.

In addition to the computer systems, you must also identify the application infrastructure (such as application servers, databases, Web servers, clusters, and so on) running on the computer systems that support your application.

BMC recommends that you design your impact service models using a tool such as Microsoft Visio, or even on paper, before actually creating them in BMC ProactiveNet or BMC Atrium CMDB. BMC also recommends that you use BMC Atrium CMDB along with BMC Atrium Discovery and Dependency Mapping or another discovery tool to create and maintain your impact service models.

You can create and maintain service models using standalone BMC ProactiveNet; however, manually maintained models can quickly get out of control.Service models created directly in BMC ProactiveNet are good for a proof of concept.

Where to edit the model

The tool(s) you use to create and edit the service model depend on the products you have installed and integrated with BMC ProactiveNet.

Integrated products

Tools to use

BMC Atrium CMDB with BMC Atrium Discovery and Dependency Mapping

Use BMC Atrium Discovery and Dependency Mapping to discover the infrastructure components and their relationships. Use Impact Model Designer in Atrium Core Console to refine the submodels and relate them to the higher-level configuration items (CIs).


Use Impact Model Designer to create and maintain the service models.

Standalone BMC ProactiveNet

Use the Services Editor in the BMC ProactiveNet Administration Console.

BMC recommends that you use BMC Atrium CMDB along with a discovery tool such as BMC Atrium Discovery and Dependency Mapping unless you have a relatively low number of models to create and maintain.

You can also import service models from other sources, but this requires customized processes that are outside the scope of this documentation.

Creating a simple model

Once you know the computer systems that support the application, you can create a simple service model by:

  1. Using the the Administration Console to create an application CI
  2. Creating impact relationships from each of the supporting computer system CIs to the newly created application CI

This produces a simple application service model as depicted in the figure below.


You can also create an equivalent service model in BMC Atrium CMDB using Impact Model Designer. For more information about using Impact Model Designer, see the BMC ProactiveNet Service Modeling and Publishing Guide.

Dealing with shared infrastructure

The model above may suffice in many situations, but you might have infrastructure that is shared between multiple applications with only a portion of the infrastructure supporting each application. In this case, you need to create CIs that represent the portions of the infrastructure that support each application. The new level of CI must be inserted in the model between the underlying infrastructure and the supported higher-level CI.


Only insert CIs for those portions of the infrastructure that are being monitored or for which events are being generated. See the [Associating monitor instances with CIs] section for more information.

For example, if the file server in the service model above provided multiple file systems, but only one of them supported that application (with other file systems supporting other applications), then you create a set of file system CIs for the file systems that support the various applications and replace the relationship between the file server and the application with relationships between the file server and the appropriate file system and between the file system and the application. In this case, your service model will look like the figure below.


Some other examples of shared infrastructure are databases on a database server, applications on an application server, and VMs on an ESX server.

Dealing with clustered infrastructure resources

Like you deal with shared infrastructure, you may have to deal with infrastructure resources that are clustered. When dealing with clustered resources, you may not want to show the higher-level application CI being directly impacted by only one instance of a group of clustered resources having a problem. In this case, you need to create a cluster CI representing the group of clustered resources and set the computation model so that the cluster state is set by a quorum of the members of the cluster.

For example, if the Red Hat Enterprise Linux servers in the model above supported a clustered application server, then you would create a cluster CI for the application server cluster, set its computation model to "Cluster", and replace the relationships between the Red Hat servers and the application with relationships between the Red Hat servers and the new cluster CI and between the cluster CI and the application. The figure below represents this service model.


Some examples of other types of resources that need a cluster CI are Web farms, database clusters, clustered operating systems.