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.

[Community Alums]

Hi Jim, 

Thank you for your answers it helps to get acquainted with the CSDM concept and the role of the Dynamic CI group and TSO. 

I am very new to this framework and my question might sound very basic, but I need to clarify it for a better understanding of the framework. Can we use TSO to manage CIs ownership that belongs to a dedicated Dynamic CI Group (Application Service created via Dynamic CI Group method)? Meaning that if for example, I set Support/Change/Managed by groups on the TSO these values will be synced to the CIs that form this dedicated Dynamic Group?

I am trying to apply it and it doesn't work. After checking the servicenow docs I found this 

Synchronize data using a technical service offering (servicenow.com) where it is mentioned that in order for TSO values to sync with Dynamic CI groups regarding ownership CI relationship to be "manages", but the white paper suggests it's "contains". 

Could you please advise?

Thanks, 

Victoria 

[Jim Zeigler1]

Based on what I've seen, ownership of a service is usually independent of ownership of individual CIs. The Managed by Group and Supported by Group are the critical groups used for managing operational Services and CI. Ownership tends to be used to identify the high level organization that requested the CI, but may not have any day to day responsibilities for the CI. I've never had any customers use TSOs but I'm guessing they may be owned by the group managing the Service Catalog (the TSO describes the Catalog offering, while the Dynamic CI Group represents the operational service).

You can also set a default Managed by Group for all CIs in a class using the Class Manager (Class Info -> Basic Info -> <Managed By Group).

As far as the relationships are concerned, go to the Suggested Relationships tab of the Class Manager  for the Dynamic CI Group to see what is allowed by the ServiceNow version you are using. In my Tokyo PDI, it looks like this:

[Jim Zeigler1]

There are many issues with the CSDM documentation (which have now been copied into the product documentation) where the documents don't reflect the actual implementation in Quebec or Rome. I started to identify them with Documentation corrections, but they are now too numerous to fix by submitting document corrections.

I saw they slipped that new suggested Relationship for TSO -> Dynamic CI Group into the Rome release, but I can't think of a use case where it might be needed or useful in support of ITSM or ITOM processes. Making it a suggested relationship implies that it may be needed for OTB functions to work properly.

Part of my issue with this new suggested relationship is the fact that it creates an unnatural bridge between the operational (where CIs "Run" in environments like Prod, Test, QA and Dev) and SPM domains. Instead, I would think that the relationship should be from a TSO within a Service Request catalog to a Business Application so you can track which TSOs support a particular Business Application.

For example, let's say the TSO in question is "Add Monitoring for Oracle Databases" and its parent Technical Service is "Add Database Monitoring". In this example, there might be additional Service Offerings for each type of Database supported because the monitoring tools may be different for each database vendor.

The suggested relationship implies that we should relate the TSO to a corresponding Application Service (populated using a Dynamic CI Group). Let's say there is a "Oracle Databases (Prod)" Dynamic CI Group containing all Oracle DBs in Prod) and an Application Service Group above it called Databases (Prod). I could see the Oracle Databases (Prod) Dynamic CI Group might be useful for populating a drop down list in the TSO form where you select the Databases you want to monitor, but that would normally be defined in the reference qualifier for the input field instead of a permanent relationship. Somewhere else on the TSO form, you would have to select an environment to narrow down the CI selection list to Oracle Databases running in production. Is this the use case the Suggested Relationship is intended to support?

Let's also say there is a Business Application called Database Services. If you maintained a relationship to all the TSOs and Application Services that support Database Services, you would know what Business Services and CIs need to be migrated from Oracle to the new DB type. That's why a TSO -> Business Application relationship makes more sense to me.

[Barry Kant]

Hi Jim,

Business Application are conceptual applications in the strategic/design domain. Those are not underpinned/supported by TSOs. The example that you give, "Database Services",  is confusing to me as I don't recon that as an application. To me that will be a Technical Service. 

In the earlier days when the Dynamic CI Group was not used the TSO was connected to a number of CIs. This was intended to be the scope of CIs that are within the responsibility/supportability of that TSO. The feedback from the field was this:
Nice to group it like that but it has a lot of maintenance effort. 
The response was to introduce the already existing Query Based Group logic also for this purpose. (and it changed from an ITOM object to a core object.).
Benefit:
You defined a CMDB Group including a query or saved query to define the scope of the CIs for a TSO. Whenever a CI is discovered and fits within this query it dynamically links to this TSO (svc_ci_assoc table). There is a Business Rule on top to sync (ootb) 3 attributes from the TSO to all linked CIs:

• Support Group
• Change Group
• Managed by Group

so this has all to data maintenance.

Another feature, that came a bit later, was that you can select the Dynamic CI Group in the Configuration Item attribute of a Change record and on save it unpacks all related CIs to the affected CIs related list. This can be used for patching etc, however it is useful depending on the strategy of how the Dynamic CI Groups are defined. 

Something else:
You give an example of: "Add Monitoring for Oracle Databases" as TSO. In my opinion this is a Catalog Item for eg TSO "Oracle Database Service (Prod)". The TSO links to a Dynamic CI Group that includes a query to group all Oracle Database Production Cis.

The TSO can also be linked to BSO (this is part of DPM previously Service Portfolio Management). You cansee this as a decomposed Service. 
The BSO is depending on a TSO (underpinned by). This might be closer to what you mentioned relating to Business Application. 

BR,

Barry

[Community Alums]

Hi Barry, 

Once again, sorry a primitive question but when you are talking about TSO - Dynamic CI group relationship. Do you mean "contains" relationship type - the one suggested by the CSDM framework? This is the one used when "AS is created via the Dynamic CI group method" or do you refer to the "manages" relationship type which is suggested here? Because, if I follow CSDM advice and use "contains" - Support Group, Change Group, and Managed By Group are not synchronized with the TSO values of these attributes. 

What is the logic behind it? Could you please explain?