How to relate Technical Service Offering to Dynamic Group?

[NikEng1]

Hi,

So I am currently trying to implement the CSDM, focusing on Business Applications, Application Services and Technical Services.

I've gone trough most of the documentation and learning about the CSDM, but when trying it out I can't seem to understand how Technical Service Offerings are to be related to CI:s.

My View is that I have a business application. This Business Application relies on an application service. Since I do not have service mapping I will be using a dynamic CI group for the application service.

In the Application Service there are CI:s. In my case these are database instances and servers. The servers are the results of delivery of the technical service offering "Linux Hosting Small". In that sense, I am not setting up direct relationships between the application service and the technical service offering, but this relationship is indirect through the CI:s.

I was thinking something like this:

In other words, the technical service offering contains all servers, across multiple application services. 

My questions are:

Is this correct? I've seen the case where people instead create a relationship between a TSO and and application service. But I would assume that would only be relevant in the cases where the offering is an entire environment. In my organization, the application managers "buys" technical services like servers, backup, databases etc as separate pieces to make up their application environment. Will my  model still adhere to the CSDM?

How do I relate the TSO to a dynamic CI group? I am looking at the form for the Technical Service Offering and I can't find a button/option to set up and relate a dynamic CI group. The form has the usual CI relationship pane. Do I just create the dynamic CI group and manually set up relationships between it and the TSO in the cmdb_rel_ci table?

Since a server as a CI can be related to multipleTSO:s (like monitoring, the server itself, backup etc) I was thinking of having a related list of service offerings on the server CI form, where I can set up a m2m relationship between servers and TSO:s, the leveraging the related list conditions of the CMDB query builder to capture the servers into the dynamic groups for each TSO. Meaning the "Monitoring" TSO Dynamic Group would query the cmdb_si_server table to CI:s where the related list contains the "monitoring " TSO. Would this be a good idea? Any other suggestions?

Any help or just general feedback would be greatly appreciated, thank you.

[Jim Zeigler1]

Technical Service Offerings provide configuration options for a Technical Service within a Service Catalog that is used to submit IT services requests. Business Service and Technical Service CIs use the same CMDB class. For Technical Services and Technical Service Offerings, the Service Classification attribute is set to Technical.

A Technical Service will have at least one Technical Service Offering but it may have more than one related Technical Service Offering if there are multiple configuration options to select from (e.g. Cloud users usually chose from predefined VMs with differing amounts of memory, CPU cores, and storage).

By design, SPM Services are not instances of anything and do not run on infrastructure stacks like Applications services. They are not operational, they have no environment attribute, and they have no operational status or Severity so there is no reason to associate them with operational CIs like Servers, Applications, and Application Services.

In the CSDM diagrams, they don't really belong in the Gold operational quadrant which is intended to have only operational ITOM CIs. The Sell/Consume Quadrant is where they belong.

Business Applications are collections of source code and binaries that are usually managed in source code control library. The are usually deployed to Application Services for each environment where they will be used (e.g. Dev, QA, Test, and Prod). If developed internally (not purchased from a 3rd party) business applications usually call external APIs provided by other Business Applications. When all the Business Applications are ready to be tested as a unit, the business applications supporting the callable API or URLs for the Service will be combined with other business applications it depends on, some of which are shared applications providing common functions (like authentication) that other Business Applications depend on.

The resulting executable is deployed to an Application Service (Application Stack) that includes all the infrastructure components (e.g. Web, App, and DB clusters)  needed to execute the service. The process of building the executable is repeated for each environment where the service will  execute. The proper relationship between an Application Service and it's Business Applications is:     

The CSDM folks chose to use the following relationship:

               Business Application Consumes::Is Consumed by Application Service

Since Application Services consume 1 or more Business Applications as part of the build and deploy process, I'm guessing the relationship should be either:

               Application Service Consumes::is Consumed by Business Application or 

               Application Service Uses: is Used by Business Application

When using a Dynamic CI Group instead of a mapped Application Service, the process is almost identical except for the method used to populate the service. You would still want a Questionnaire filled out and submitted by the Application SMEs for each Dynamic CI Group. 

There is no need for any Service Groups in your scenario. They will sit above the Dynamic CI Groups and Application Services to model a higher level Service that depends on a collection of Application Services. SPM Technical Services and SPM Technical Service offerings represent the parts of the Service Catalog and thus have no operational status or relationships to any CI in your Application Service. They will never show up in any ITOM service Maps or Service Groups because they are not operational, and they don't have any dependencies on the ITOM services or Hardware CIs in your Service.

If you want an application Service in the Service Hierarchy for listing all the Database Servers, or the the Web Servers or the specific types of VMs, all you need to do is populate a Dynamic CI Group and insert it into the Service hierarchy.

When creating Dynamic CI groups, don't forget to include downstream services that it depends on so the severity will propagate upward from the services it depends on.

I hope this helps.

Jim Zeigler

[Barry Kant]

1 note:
Business Service and Technical Services are not the same class. They are different classes and also identified by the service classification.  (depends what version you are)

[Louis28]

Hi @Jim Zeigler ,

I appreciate the information as well as the breakdown. I have a question that stems from your statement "SPM Technical Services and SPM Technical Service offerings represent the parts of the Service Catalog and thus have no operational status or relationships to any CI in your Application Service. They will never show up in any ITOM service Maps or Service Groups because they are not operational, and they don't have any dependencies on the ITOM services or Hardware CIs in your Service."

When configuring Event Management, Paris or above, would Technical Service Offerings serve as a  valuable operational object to utilize for Event and Incident Routing? If I have separate teams for DBA Support, Windows/Midrange, VM/Physical; that are supported at the offering level (application service agnostic), would it make sense to utilize Technical Service Offerings in an operating model or do you still see Dynamic CI groups being the bridge that brings together the Events/Incidents created with the support teams?

Kind Regards,

Louis

[Jim Zeigler1]

I agree. They are both SPM Services that represent Service catalog Requests.

Unfortunately, because the Service base class is used to model both SPM Catalog Requests (e.g. Business Services and BSOs, Technical Services and TSO) and ITOM services, it is sometimes difficult to identify which attributes in the Service table are intended to be used for SPM Catalog requests and which attributes are for ITOM services. Likewise, the Suggested Relationships at the Service level are not all supposed to be used on both classes. The same ambiguity exists for Status fields on the Service Class. Some choice values are to be used only for SPM and while others only make sense for ITOM. I hope in a future release the SPM Services are moved to their own tables outside of Configuration Item (They are not CIs or Services, they are Service Catalog requests and offerings).

Dynamic CI groups are Application Services whose severity is updated by Event Management and displayed in a Service Map (List View). There are many Service Mapping scenarios that dictate the use of Dynamic CI Groups when traditional Service Maps can't be created using top down discovery.

By defining a simple filter or query, you can generate a list of CIs that belong to a Service.  They are usually created to provide visibility to the current severity of Infrastructure Services and CIs that can't be discovered. They have no defined relationships to tables used by SPM. 

Based on the Quebec CMDB model, a TSO cannot Contain an Operational CI (e.g. Application Service, Dynamic CI Group, or discovered CIs). A TSO has no operational State, Version, or severity because it is not environment specific, it is just a catalog entry.

If you want a TSO to contain Application Services and hardware CIs, it would need to reclassified as a Service Group. Service Groups are the operational CIs that make up the highest levels of the Service Hierarchy.  Service Groups can contain Application Services and Dynamic CI Groups(using the Service Group Members Table).

The hierarchy of all operational CIs is visible on the ITOM Visibility dashboards.  Service Groups get alerts and severity propagated up to them from their member services or Service Groups.

If a TSO results in a RITM that runs a workflow for creating a Linux server, the specific RITM might point to the Linux Server it created but the "Created by" relationship is not an operational relationship used by ITOM.

The most useful relationships would be from the new Linux Server to the Application Services that depend on it. Ideally, the Application Service the server is deployed to would be identified in the Build documents so the Application Service can be updated to reflect the new server in its application stack.

I've attached a PDF that shows the 3 hierarchies in CSDM(Represented as quadrants in the CSDM diagrams). It shows all the relationships and references defined in the CMDB Model.  You can browse these using the Class Manager.  References between classes are defined using an attribute. Valid relationships can be seen on the Suggested Relationships tab for each class.

Below is a diagram showing what the operational(ITOM) Service hierarchy looks like. In my opinion, The operational Service Hierarchy shown below should be placed in the Gold ITOM Quadrant (And remove the SPM Services that belong in the Sell/Consume quadrant.

[big-m0dem]

"Based on the Quebec CMDB model, a TSO cannot Contain an Operational CI (e.g. Application Service, Dynamic CI Group, or discovered CIs)" ??

From CSDM 3.0 Whitepaper: