Business and technical services models

Business and technical service modeling is useful when building service models that connect business with IT. This model allows business users, service line managers, service desk, and IT operations to have a common understanding of the relationships between technology (IT) and the services delivered.

The following table provides details about business services and technical services:

Both business and technical services are represented by the BMC_BusinessService  class with the ServiceType attribute set to either BusinessService (10) or TechnicalService (20). The ServiceLifeCycle attribute is an important attribute in a business service. ServiceLifeCycle represents the life cycle that a service is currently in, such as requirements, design, released, operational, or other states.

Business or technical services depend on applications installed on one or more servers and provide a service context to infrastructure Configuration Items (CIs), such as applications, software servers, clusters, and computer systems.

Business services use a technical service to represent technical infrastructure CIs that support the business service.

Business services connected to Infrastructure CIs model

In this model, a business service is connected to infrastructure CIs that support the business service. A business service is dependent on applications, software servers, and network devices. Dependency relationships are used from business service CIs to each of the infrastructure CIs. Every infrastructure CI that has a business service that it is dependent on need not be directly connected through a dependency relationship to business service. In practice, only BMC_Application, BMC_SoftwareServer, and BMC_ApplicationService are used to connect to a business service. 

For example, in the following diagram, BMC Remedy Service Desk is a business service that the IT organization provides. This business service is dependent on the Action Request clustered application running on two servers.

Business service dependent on two technical services model

In the following diagram, a claims business service is dependent on two CIs, a saleslunchclaims module and a secure module, each running on a different Apache Tomcat application server. Each of these modules is represented as BMC_ApplicationService CIs and are connected to the claims business service through BMC_Dependency.

Business services, provider organizations, and customers

Organizations can provide, support, or consume a business or a technical service.

Business services consumed by the customer organization model

In the following diagram, BMC Remedy Service Desk is a business service that Calbro provides as a service provider to another customer company, called MyCompany through a specific agreement called a ServicesContract.

• MyCompany is a consumer of this business service through the ServicesContract agreement.
• The customer to contract relationship is represented by a BMC_Dependency relationship with Name=ORGANIZATIONISCUSTOMERFORCONTRACT.
• Calbro is the provider of the service and is related to the contract through a BMC_Dependency relationship with Name=ORGANIZATIONPROVIDESSERVICE.

Business services provided by the organization model

The Accounts department in Calbro company provides a claims business service.  BMC_Dependency with Name=ORGANIZATIONPROVIDESSERVICE defines the relationship between a business service and organization.

The following diagram shows the model of the Accounts organization and its parent organization, which is Calbro. This is indicated by a BMC_MemberOfCollection relationship with Name=ORGANIZATIONCOMPOSEDOF. Usually, the organization providing the service is the lowest level of organization, if this information is available within a company.

An organization can be a consumer of a business service through a contract provided by another organization. A contract establishes the agreement between a customer and a provider of a service.

Business services and people model

Just as organizations can support a business service, people can also support business services. There are two main aspects of people modeling:

• The person's relationship to the organization that they belong to.
• The services that the person supports.

For example, the Accounts organization provides claims but is supported by an AppSupport group within Calbro. AppSupport is also modeled as BMC_Organization and there is a relationship between Calbro and AppSupport, which is represented by BMC_MemberOfCollection with Name=ORGANIZATIONCOMPOSEDOF.

• Sandy is a support person in AppSupport and this relationship is represented by BMC_Dependency with Name=PERSONASSOCIATEDWITHORGANIZATION.
• Sandy also supports the claims business service. This relationship is represented by BMC_Dependency with Name=SERVICESUPPORTEDBYPERSON.

Service offerings, requestable service offerings, and service level targets

ITILv3 describes a service as a combination of utility and warranty whereas:

• Utility describes what a service does. 
• Warranty defines the promise or guarantee that a product or service will meet its agreed requirements.
  Warranty is composed of a set of assertions by the service provider about the service levels that are provided.
  The service levels include the type and hours of support, availability targets, response times, and storage capacity.

Service providers offer the same utility at different levels of warranty. One customer may get the utility with 5x8 telephone support while another customer may do so with 7x24 telephone support. Requiring the creation of a new service to capture the variations in warranty would lead to a proliferation of services and confusion at several levels. 

Each dimension of warranty, such as response times or availability is represented as a Service Level Target (SLT). Some SLTs (representing the warranty) are connected to a service (representing the utility) to form a Service Offering (SO), represented by BMC_Offering. Therefore, a SO represents a level of warranty for a given service represented by BMC_BusinessService. There can be several service offerings for a given service where each SO represents a different warranty. 

For example, a business service offering may have an SLT that requires IT Support to deliver the service to customers in no more than two hours. This service offering may be named ERP Gold, based on a service called ERP defined in the service catalog. Business customers do not subscribe to services, they subscribe to service offerings.

BMC_Offering is an abstract class. To create instances in CMDB, the BMC_ServiceOffering class is used to represent an ERP Gold service offering. A Requestable Offering (RO) is the part of a service that end users can see and request. Like a service offering, it combines a service (utility) and a service level target (warranty). For example, for an ERP System business service offering, you might have requestable offerings for creating an account on the ERP System, closing an account on the ERP System, and increasing the database limit on the ERP System. A requestable offering is represented by BMC_RequestableOffering.

There are two types of Requestable Offerings (ROs):

• Delivery ROs — Sets up the service (creates a service offering instance) such as creating an account on ERP.
• Transactional ROs — Could be request such as reset my password or close an account on ERP.

A service offering can have one or more delivery requestable offerings and one or more transactional requestable offerings.

Service offering and requestable offerings model

In the following diagram, a company's Virtual Private Network (Company-VPN) is represented as a BMC_BusinessService CI that has one service offering and two requestable offerings (ROs):

• BMC_BusinessService is connected to a BMC_ServiceOffering CI with a BMC_ServiceRealizedByOffering CI with Name=SERVICEREALIZEDBYOFFERING and business service as the source.
• Because there is only one BMC_ServiceOffering CI, the isDefault attribute for this CI is set to Yes.
• One of the BMC_RequestableOffering has a DeliveryRO attribute set to Yes, which indicates that this RO sets up the service.
• The other BMC_RequestableOffering is a transactional RO and the DeliveryRO attribute is set to No.

Each requestable offering is connected to service offering via a BMC_Dependency relationship with Name=SOENABLESROand an requestable offering source.