Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Service Management

You are here: Build > Service Asset and Configuration Management > Getting started with SACM > SACM modeling use case

Service Asset and Configuration Management modeling use case

This use case provides a practical step-by-step modeling guide for the online book store service example. The modeling approach used in this example is top-down modeling; we start from the top logical record types of the service and the relationships between them and proceed to describe the lower infrastructure elements of the tree and their relationships with the upper logical elements.

A service-model is a topological graph structure composed of records which are connected via relationships. The most important design consideration behind the Service Management service model is simplifying the complexity of service model graph structures. This ensures that any person with any role in the enterprise can easily consume and understand the service model.

Service Management enforces a strict service structure - all services follow the same graphical pattern to facilitate easy interpretation of the model at a single glance. All service models created in Service Management are tree models; general complex service graphs structures are not supported.

Top logical record types and relationships

Actual-service and Service-component

The record type that represents a service, whether a business service or an infrastructure service, is the actual service record type. In Service Management, a service is composed of multiple service components. A service component can represent a business application, for example. Therefore, if an actual service is composed of multiple business applications, each business application should be represented as a service component contained by the parent actual service.

For example, the online book store service is comprised of multiple business applications - the shipment management application, the order management application, and the books catalog browsing application. In this case the online book store service should be represented by an actual service record and each of the business applications comprising the service should be represented by a service component record.

An actual service must be comprised of at least one service component. This ensures that all actual services follow the same tree model and include the same layers.

Containment relationship type

The containment relationship is used to connect a parent actual service with its child service components. You can refer to its child service components of the actual service record using the ActualServiceContainsServiceComponents MANY2MANY relationship. To model the fact that the online book store is composed of the business applications mentioned above, it is necessary to connect the online book store actual service to each of its service components via a containment relationship, as can be seen in the following service tree:

Usage relationship type

The usage relationship should be used to model dependencies between actual services. A dependency means that actual service X consumes some service from actual service Y. This usually means that actual service Y is a shared infrastructure which can be used by other actual services (in addition to actual service X).

It is possible to model the fact that service component X is using actual service Y. In our example, assume that the online book store service is using the credit card payment actual service and the Paypal payment actual service. This can be modeled as follows:

If you know which service component is using each of the payment services, it is better to connect the service component record to the payment services directly, rather than connecting the online book store actual service record to the payment services. This generates a more accurate service model and the impact analysis calculations provide more accurate results. The user viewing the impact result map can see which functionality of the actual service (i.e. which service component) is impacted. Therefore, the following model is preferred:

You can refer to the actual services used by an actual service record via the ActualServiceUsageActualService MANY2MANY relationship. You can refer to the actual services used by a service component record via the ServiceComponentUsesActualService MANY2MANY relationship.

Containment vs. usage relationship

To further clarify the difference between the usage and containment relationships, consider the following:

The online book store service is composed of the following service-components:

shipment service component
book catalog service component
book orders service component

No other service can use these service components and they all have the same owner (the owner of the online book store service). In addition, all the service components in the online book store are subject to the same SLA – the SLA of the online book store service. In such a case, the best practice is to associate the online book store with all its service components via containment relationships.

If, however, the online book store consumes the functionality of the payment service, which is a shared service (i.e., it could also be used by the online music store and online clothes store, etc.), in such a case the payment service should be associated with the online book store actual service via a usage relationship. The owner of the online book store is not usually the same as the owner of the payment actual service.

To summarize:

Containment represents composition; usage represents sharing (multiple business services can use a shared infrastructure-service).
Containment involves the same ownership of the associated records; usage implies different ownership.
Contained records generally have the same SLA as their parent. This is not the case with usage, as the owners are different.

Service scope demarcation

The usage relationships demarcate the scope of services – the usage relationships form the borders between services.

For example, to calculate the cost of ownership of the online book store actual service, it is necessary to sum up the cost of every record which is directly or indirectly connected to the root online book store actual service via a containment relationship. These are the records that compose this actual service.

Distinguishing between infrastructure and business services

The actual service record type can represent either a business service or an infrastructure service. This is determined by setting the appropriate value (business-service or infrastructure-service) in the actual service’s subtype attribute. In our example, the online book store service is a business service and both of the payment services (Paypal and credit card) are infrastructure services because these services are not used directly by business customers.

Record types representing infrastructure elements

In Service Management, there are two record types that represent infrastructure configuration items:

Device

This record type may represent any kind of node: a smartphone, a laptop, a network device, a server, a storage device, etc. A device record may represent either a physical or a virtual machine. Use the device subtype ENUM field to set the type of device represented.
System element

This record type may represent one of the following according to the content of the subtype ENUM field:
- WebServer. A web server such as Apache or IIS.
- Database. A database such as Oracle or MSSQL.
- Virtualization. Represents a hypervisor.
- ApplicationServer. Represents an application server such as JBOSS or WebSphere.
- Running software. Represents any software running on the device (usually a server device) which is not one of the following: a web server, a database, a hypervisor, or an application server.
- CI collection. Represents a generic logical collection of devices. The collection of devices may represent one of the tiers of an n-tiered service or application (e.g. the devices where the web servers are deployed i.e. the web tier).
- Other. Represents anything not listed above.
A system element can also represent a failover cluster or a load-balancing cluster, comprised of multiple machines. In this case, the cluster type attribute should include either the value FailOver or LoadBalancer. In addition, this record type may represent a complicated distributed system comprised of multiple machines and running software instances such as Active Directory, Sharepoint Farm, SAP System, etc. (In that case, the value other should be set in the subtype field).

The following diagram summarizes all the record types and valid relationships that can be used to build service model trees in Service Management:

Modeling the service components of the online book store service

The following is a description of the implementation of each of the service components (business-applications) comprising the online book store service. For each description, we will show how the service component subtree should be modeled in Service Management.

Shipment management service component

The shipment management service component is composed of one dedicated web server running on one machine and one dedicated database running on another machine. The web server appears in the picture below as Apache WebServer2 and the database appears as PostGreSQL Database1.

Each of the machines (seen below as Windows Server1 and Windows Server2) may host other running software instances which are dedicated for other actual services. For example, the shipment application does not use Apache WebServer1 which is also running on Windows Server1. The Apache WebServer1 is used by a different service or application. Therefore, the shipment management service component should be connected via containment directly to Apache WebServer2. It should not be connected to Windows Server1, as this machine is not dedicated for the shipment application.

The same approach should be used to model PostGreSQL Database1 which is dedicated for the shipment application. Note that PostGreSQL Database2 is not used by the shipment application, hence Windows Server2 is not dedicated for the shipment application hence the shipment service component is not connected to Windows Server2 instead it is connected to the PostGreSQL Database1 directly.

Order management service component

The order management service component is composed of four JBoss application servers running the orders business logic. Each pair of application servers are deployed on a separate machine dedicated for the order management application. The two dedicated machines appear in the picture below as Windows Server3 and Windows Server4. Therefore, running software instances which are not running the order management application cannot be installed on Windows Server3 and Windows Server4 which are dedicated for order management only. In addition, the JBoss application servers use the following infrastructure services:

Database infrastructure service. The data of the orders application is stored on a shared infrastructure database owned by the Database-Admin group (not owned by the owner of the online book store business service). The name of the infrastructure service is Database RAC-Farm-1.
Paypal payment infrastructure service. This infrastructure service is also used by the online music store business-service (in addition to the online book store business service).
Credit card payment infrastructure service. This infrastructure service is also used by the online music store business-service (in addition to the online book store business service).

Since Windows Server3 and Windows Server4 are dedicated for the order management application, it is recommended to connect the order management service component directly to Windows Server3 and Windows Server4. This is preferred over connecting the service component to each application server individually because, if at some future point, the owner of the online book store service decides to deploy additional application servers on these machines (to increase scale), he would have to manually connect the newly added instances to the order management service component. By directly connecting the service component to its dedicated machines, the owner will not need to manually update the service model in the event of adding/removing a running-software from these machines. The following picture displays the usage relationships connecting the order management service component with its three infrastructure services:

Book catalog browsing service component

The book catalog browsing service component is a two tier application – a web tier and a database tier. The web tier is composed of two Apache web servers where each web server is running on a separate machine dedicated to the catalog browsing application exclusively. The database tier is composed of a failover cluster comprising two PostGreSQL database instances, where each instance is running on a separate dedicated machine of its own.

A tier of an application or service should be modeled as a CI collection. A CI collection is a subtype of the system element record type. The machines hosting the running-software instances are dedicated and there is no need to associate the web-servers to the CI collection – it is enough to associate each device to the CI collection. The database tier consists of a failover cluster composed of two dedicated machines. A failover cluster is modeled as a system element with the ClusterType field set to FailOver. The following diagram displays the model:

The complete model is depicted in the following diagram: