Building a service model

The main purpose of creating or publishing a service model to BMC ProactiveNet is to be able to see how CI failures propagate and impact the upstream services.

This information is then used to visualize the impact to a service and to automatically open Intelligent Incidents that contain information about the failed or failing IT components and services it impacts for further prioritizataion and faster troubleshooting.

A service model is a collection of components (also known as configuration items (CIs)) that represents a business service. A business service can have one or more business processes. Each business process can contain several functional applications, each of which can have multiple IT CIs. A service model will contain the processes, show how the CIs are interconnected.

The best service models are enterprise-specific, achieving the organization’s business availability goals. The IT environment, its organization, and its operational constraints vary significantly among enterprises.

A cost-effective strategy when you begin the process of building a service model is to select one critical business process/service, decompose it to identify all aspects of the service, and build a complete service model for that part of your enterprise.

A BMC ProactiveNet user can create a service model either directly in the BMC ProactiveNet's Administration Console, or using the BMC Impact Model Designer tool, which is part of the BMC Atrium solution, if BMC Atrium CMDB integration is used for service model creation.

The service modeling process involves:

• identifying sources of event information
• gaining familiarity with the structure and content of events
• identifying core competencies within the organization
• identifying critical business processes
• identifying IT services and their CIs
• finding relationships and dependencies between IT services
• building the necessary database of information (asset inventory, service catalog, and so on)
• building the service model

Refer to BMC Impact Model Designer for explanations about terms and concepts of service modelling.

Defining business goals for the service model

The most basic step involved in defining a service model is defining the specific business goals you hope to achieve with the model. To do so, the IT or IS group must engage the business managers in defining short term, mid-term, and long-term goals for service impact management for the enterprise. These goals guide the design and development of deliverables for all service model development phases and define the amount of time and effort required for development and implementation.

Decomposing a business service

The purpose of decomposing a business service is to identify and document business processes, identify the IT services that support them, and identify IT CIs and assets that provide the IT services. For example, a hardware manufacturing organization may identify a business function as microprocessor procurement, a supporting IT service as procurement information storage, and the supporting IT assets as servers, databases, and related hardware and software systems.

On a high level, a service model is a collection of components (also known as configuration items (CIs)) that represents a business service. A business service can have one or more business processes. Each business process can contain several functional applications, each of which can have multiple IT CIs. A service model will contain the processes, show how the CIs are interconnected, and show how CI failures propagate and impact the upstream services.

Designing a service model

The following steps facilitate the process of creating a service model.

1. Identify business services.
   Sources of information include business unit managers, business process managers, and staff personnel knowledgeable about the business services. Company organization charts might be helpful in identifying the relevant people. The process involves interviewing the managers and identifying the following information:
   • Business processes – Identify key business processes such as Market Research,
     Product Planning, Response Management, or Case Management. There can be multiple levels of business processes, starting with higher level core competencies and business functions, to specific sub-business processes.
   • Functional applications – Identify the business applications that support the business processes. Map the business processes to the functional apps. Map the functional applications to IT service CIs to create business service models.
2. Identify IT services.
   Sources of information include IT managers and staff. Disaster recovery plans, help desk documents, and purchase orders might be useful in identifying IT CIs and the business processes that they support. The process involves identifying the list of IT assets (components). Interview the IT management and staff, or utilize an asset/configuration management database as
   resources:
   • Create a list of IT services (service catalog); discover what IT services are offered
     to business units through use of IT assets. Examples of IT services include
     customer support and customer call monitoring.
   • For each IT service, identify the IT assets that support the service.
   • Identify the interdependencies among the IT CIs and formulate a topology map.
     Consider the relationships and dependencies between IT CIs.
3. Build a business service model, and link the business processes to the IT services
   you have identified.

Building a service model

Service models can be created using the following BMC products:

• BMC Impact Model Designer
  This tool is used when leveraging CIs that have been maintained in BMC Atrium CMDB.
• BMC ProactiveNet Administration Console
  The Administration Console is used to create simple service models, which are typically not large in scale and maintained manually.

BMC Impact Model Designer is leveraged from BMC Atrium Explorer and uses the same UI as that of BMC Atrium Explorer. You can use both of these products to create service models. However, BMC Impact Model Designer contains the following unique functionality that is not available in BMC Atrium Explorer:

• Creating schedules and timeframes for CIs
• Editing impact management attributes of CIs using the GUI

When you build a service mode in BMC Impact Model Designer and publish it to BMC ProactiveNet, the CIs are stored in Atrium CMDB which is the database used by other BMC products also.

Complete the following steps to build a service model in BMC Impact Model Designer:

• Create configuration items (CIs) in BMC Impact Model Designer
• Assign CIs to a BMC ProactiveNet cell
• Define CI relationships
• Assign schedules to CIs
• Promote the service model and publish objects to cells

Before you begin

You must first launch BMC Impact Model Designer from BMC Remedy AR System:

1. Open a browser and enter the URL in the format http://<AR server mid-tier hostname>:<mid-tier port>/arsys.
2. Log on to BMC Remedy AR System.
3. In the Home page, click the Atrium Core Console link on the left side.
4. In the BMC Atrium Core Console page, click Impact Model Designer.

BMC Atrium Core Console is displayed. BMC Impact Model Designer is a part of BMC Atrium Core Console.

To create configuration items (CIs) in BMC Impact Model Designer

If BMC Atrium Discovery and Dependency Mapping is present, CIs can be exported directly to Atrium CMDB.

Otherwise use the Classes drawer in BMC Impact Model Designer to create service CIs.

1. When you open BMC Impact Model Designer, asset view opens automatically.
2. Drag the component type from the Classes drawer to the asset view. When you drag a component, click Yes in the Convert View to Sandbox View dialog box to convert the asset view to sandbox view.
3. In the sandbox view, right-click the new component icon and select Edit.

To specify attributes for configuration items

1. Access the General tab.
2. In the Short Description text box, enter a component description that is meaningful to your enterprise.

3. In the Name text box, replace the default name for the CI with a specific CI name that is meaningful to your enterprise and that you want to use as the label of the CI in a view.

4. (Optional) In the Owner Name text box, enter the name of the individual responsible for the CI.

5. (Optional) In the Owner Contact text box, enter a contact method, such as a phone number or e-mail address, for the individual.

   Note

   A CI is displayed in the sandbox view with the short description attribute instead of the name attribute as its label. You can configure this label to display the name of the CI instead of the short description. To do this, you need to edit the BMC.CORE.CONFIG:BMC_UIComponent form using BMC Remedy Action Request System User (BMC AR User). For more information, see the BMC Atrium Core online documentation.

To specify BMC ProactiveNet specific attributes for CIs

1. In the Cell list, select the cell on which the selected CI gets published. BMC Impact Model Designer retrieves the list of cell names from the BMC Atrium CMDB. If the cell that you need is not listed, you will need to add a cell. See Managing cells for information about adding a cell.
2. In the Publish to BMC ProactiveNet Performance Manager (BPPM) area, select:
   • Inherit if this CI is not selected by a Publication Filter. The CI may get published as a provider of a CI that is selected to be published with its providers. In this case, if even one of the consumers of the CI is set to Yes and Propagate, the CI is also published. Inherit is selected by default. See Service Model terms and concepts for explanations about the service model relationship between providers and consumers.

   • Yes and Propagate to publish not only the CI but also all the providers of the CI to the cell through the OOB Atrium - Myself and My Providers publication filter.

     Note

     Ensure that you select this option for at least the top-level consumer CI in your service model.

     If you are creating a discrete service model, select Yes and Propagate for the cell of the top-level CI. If you are creating a distributed service model, select Yes and Propagate for the cells of the top-level CIs of the submodel that resides on the BMC ProactiveNet Child Server.
     If you are creating a distributed service model, ensure that all the BMC ProactiveNet Servers on which the service model is distributed are mentioned in the pserver.conf file.

   • Yes, Only Me to publish only the currently selected CI to the cell through the OOB Atrium - Only Myself publication filter.
   • No to not publish the CI to the cell and to not publish the CI's providers. This setting is applicable to all publication filters, that is, to the OOB Atrium publication filters and to user defined publication filters.
3. On the Status and Alias tab, perform the following tasks:
   1. In the Status Computation list, select a status computation model. The default selection is Standard, which is acceptable for most CI definitions. For details about status computation models and slot values, see Service Model terms and concepts.
   2. In the Aliases text box, click Add Alias.
      Each CI must have a unique alias; if more than one CI has the same alias, publishing fails. Cell aliases define another name for a cell so that data can be sent to more than one cell. A cell can have multiple cell aliases. For more information about aliases see Service Model terms and concepts.
      • In the Alias text box, enter the alias and click OK.
      • (Optional) Enter additional aliases (one for each event that can potentially affect the status of the CI) by clicking Add Alias.
        Each alias that you enter is listed in the Aliases box.
4. On the Permissions tab, assign the proper permission to each of the roles listed for this CI

To define relationships between configuration items

Impact relationships define how status propagation is passed from the provider CI to the consumer CI.

An active relationship is an impact relationship and indicates that the status of the CI depends on the status of the connected provider instance.

An inactive relationship means that no dependency exists or that the dependency is irrelevant to the model; in either case, an impact relationship does not exist.

Whenever the status of the provider instance changes, it is propagated to the connected consumer CI.

For each CI for which you are creating relationships, you must know:

• whether it is a consumer or a provider for the related component
• its relationship state value (active or inactive)
• its status propagation model value (relationship policy)

To assign schedules to configuration items

After you have created relationships, test them to verify that they function in the way that you intended.

You can assign one or more components to service schedules by using the Schedule and Priority tab in the Edit Component Properties dialog box.

Service schedules are a combination of a defined schedule with a specific service model component that indicates when the component must meet availability or performance goals. Each component is assigned a service schedule (but it can be a schedule shared with other components).

1. Access the Schedule screen by editing a CI.
2. In the Schedule area, assign the appropriate service schedules information to the CI.
3. In the Priority area, from the Propagate Priority to Providers list:
   • Select Yes to have the selected components propagate their self-priority to their causal components
   • Select No (default) if you do not want the self-priority to be propagated.
4. In the Self Priority Function list, select a base priority for the CI.
5. In the Priority and Cost by Timeframesarea:
   • Select a base priority for the high demand and low demand timeframes.
   • Enter the cost per second of the high demand and low demand timeframes in the Cost text boxes and the currency of the cost in the Cost Unit text box.
6. The Other tab displays more information about the CI you created. Enter or edit values.
7. Click OK to save the CI in BMC Atrium CMDB.

To promote the service model and publish objects to cells

Verify the following configurations before promoting the service model:

• Each CI is assigned to a cell
• All target cells that are registered in BMC ProactiveNet are running and have a live connection with the publishing server.
• The publishing server is running in automated mode.
• The BMC ProactiveNet class definitions are in sync. The publishing server validates the class definitions and establishes a live connection with BMC ProactiveNet, the BMC Atrium CMDB, and the cells before submitting the publication.

1. On the toolbar, click the Promote Sandbox Changes icon to start the promotion.
2. In the Promotion Preview dialog box, in the Instances to be Promoted area, you can filter the list of objects according to CIs, or relationships, or both. When you filter the list, it only affects what is visible, not what will be promoted. All items are promoted. You can click a CI to view its details in the right pane.
3. In the right pane, review the list of attributes for the selected CI.
   You can use the Show list to view only those attributes that have been edited or all attributes.
4. Click Promotion. When you submit a promotion, the Promotion Preview dialog box offers the opportunity to compare your unpromoted sandbox service model CIs and relationships with those that have already been promoted so that you can verify the work done in the current editing session. When you click Promotion, service model objects (CIs, impact relationships, and management data) shown in the preview are promoted (and subsequently automatically published). After a successful promotion, the publication of the service model is triggered. Publication may take some time depending on the size and load of the service model.
   A service model object is successfully promoted when it is moved from the sandbox to this dataset in the BMC Atrium CMDB.
5. Run the pshowlog command from the system in which the publishing server is installed to check if publication is a success or a failure.
   From the CLI, run the following command:
   pshowlog [ -i User/Password[@Host[/Port] requestId | -h
   where
   -i User/Password[@Host[/Port] authenticates the specified user name and password with the BMC ProactiveNet Server running on the specified host computer and port; you can specify multiple hosts and ports
   RequestID is the ID of a specific publish request
   -h displays help information
   Example: pshowlog Z00000e8mu7xw9Xpa1ZfsMZeg4v1Z

Related topics

Designing a service model

Understanding a service model

Publishing Server architecture