8.1 Understanding Multi-Definition and Multi-Generational Configurations

It is possible to define more than one service configuration for a single element. The service configurations are built and applied in the order in which they are defined.

8.1.1 Understanding Multiple Configurations

When multiple configurations are defined for the same element, subsequent configurations can be generated using the results of the configurations defined before them. For an example that shows multi-definition configurations, see Section 12.3, Use Case: Creating a Configuration Management Database.

It is also possible to use hierarchies generated from other configurations to help define or build a new configuration. These are called multi-generation configurations. A first generation configuration can contribute to (as a structure or source) a second generation configuration.

For an example of using one configuration to define another configuration, see Section 10.0, Use Case: Mapping Application Dependencies, which leverages a Service Catalog hierarchy that a different service configuration previously generated.

8.1.2 Understanding the Generational Models Workspace

Models created under the Services node represent logical relationships among elements in a business. Models constructed under the Service Models node typically group elements in an enterprise that represent the various management activities or services related to a business. Models created under the Locations node group elements based on geographical location. Different users and groups of users are given permissions to view models based on operational need.

Whereas, the Generational Models node under the Services hierarchy, functions much like a “working space” for creating and maintaining models that can be viewed by a limited number of users and contain elements that do not have an impact on other service models.

Use Generational Models for configurations that are produced by SCM as part of the process of building service models. These would be the “building blocks” for a service model, and are not considered part of a service model.

Restricting access to some models is desirable for many reasons. For example, only the person creating a model should be able to view it during the creation process.

To restrict access to a model, construct it under the Generational Models node in the Services hierarchy, then set permissions for the Generational Models node to restrict access to only those users who have access to all the models under this node.