CSDM: Service Offerings and Facilities

[rwilson1]

I'm trying to wrap my head around something that I think is a common use case, I'm trying to figure out how this would be mapped out in the CSDM.

We have several facilities, and we want to review and approve a Change that impacts one of those facilities. Since we don't have facilities or locations as Configuration Items, I was wondering if I should create a Service with several Service Offerings to try and map this out.

Conceptually, we would have a Technical Service called "Facilities and Infrastructure Services", then within that we would have specific Technical Service Offerings for each separate location. I'm also wondering if Facilities wouldn't fit better under Business Services and Business Service Offerings. Once you have offerings identified, you should be able to create dependencies to specific CIs that depend on those facilities - data centers and other hardware for example.

Any thoughts on this?

[rwilson1]

I'm aware, we're just not using them as we're tracking everything in cmn_location. You raise an interesting possibility though - this could make dependency mapping a lot simpler, since you'd be using CMDB tables. I could create a simple rule or UI action even to create a "cmdb_ci_building_facility" from a Location.

[Patrick Laroch1]

Exactly, for all locations that you want to manage.

Then have infrastructure/network at the same location have a relationship to ci_building. You could create Changes and have the building as an impacted CI, etc...

[Community Alums]

The scenario you are trying to model is easily handled by using ITOM Application Services organized into a Service Hierarchy. There is no need to include any of the SPM services or service offerings that model the service catalog . Dynamic CI Groups (formerly known as "Technical Services") are a type of Application Service which are used by most customers to model all their infrastructures services running at every location.

The easiest way to populate Dynamic CI groups with their associated CIs is to use Query-based Mapping (specify a filter on a table or view). You can also use the query builder for more complex queries. If similar CIs for infrastructure devices are added, the re-execution of the Query picks them up.

When making a change, just specify the devices being changed and the "Refresh impacted Services" action will include all the Application services and Service Groups above the CIs being changed. Query-based mapping does not require any Service Mapping training, so anyone with knowledge of the IT infrastructure can create Dynamic CI groups for their area of expertise.

One of my clients with over 50 manufacturing locations implemented Dynamic CI groups for all their Infrastructure services in less than 3 months (almost 1000 Services in total). Now, whenever any infrastructure CIs is changed, they know exactly what services will be impacted.  I provided them a Service Naming convention that includes the location so the services at each location are unique (similar to the way Applications are named by discovery with the @<hostname> on the end of the name).

Dynamic CI groups also have a severity (which is calculated based on events with severity that propagate upwards from their associated CIs). All Application Services in the Service Hierarchy (and their severities) appear in the operator workspace and Event Dashboards for operations teams to monitor.

I've attached an explanation and graphic of the Application Service Hierarchy.

[Patrick Laroch1]

My understanding is that you were making changes to the actual facility and wanted to know which services/CIs would be impacted.

But if what you need is a logical grouping of CIs at a location then I agree with @Community Alums 

[Mark Bodman]

There are a few approaches outlined here that can be used together, they are not mutually exclusive.  I would suggest leveraging the Dynamic CI group to specify what devices would impact a location as part of the query.  Then, I would define and connect the Technical or Business service and offering to that.  Last, I would add a subscriber for that location as well.  

Ideally in a more integrated scenario, a Service Owner would be able to define the service using Service Builder, when they get to the Offering, to then define Subscriber and the Dynamic CI group together.  When defining many of these, for example if you have 100 building locations that each have networking  services, the main difference may only the location itself.  The location use in the Dynamic CI group would be the SAME location used as used in subscriber. We should think about how you manage the consumers at the same time as defining the dynamic CI group & Query, I envision that the Service Builder wizard would one day facilitate the whole process, given the type of service it is.