Service model design considerations

This section contains information to keep in mind when designing your service model, including information on cell topology, component property updates, and component deletions.

Determining cell topology for the service model

There are three basic approaches to cell topology, which are as follows:

• Centralized
• Domain-based
• Layered

The centralized (default implementation) approach is to implement the service model on one cell, with all the service management objects created and maintained in that cell. Then, use distributed cells to collect and process the raw events of interest before they enter the model.

The domain-based approach separates the service model into two or more parts that correspond to clearly established entities or domains in the organization. Each part is run on a different cell, and users connect to the cells on which the CIs that they manage reside. Lines of business and independently operated sites are good candidates for this approach. With this approach, you can represent some resources in more than one cell, provided that the event flow is directed or propagated correctly.

The layered approach separates the service model into two or more stratified management layers, such as IT CIs and logical CIs. Each layer is contained in a different cell, or possibly distributed among several cells if geography is a factor.

 Component property updates

The cell updates the status of a CI as new events are received or when an impact from other CIs occurs.

However, other CI properties that can change over time are not maintained by the cell. You can update these properties automatically only if the new values arrive in an event or are added in a data table. You must create a few simple rules to implement this mechanism.