Technical Service Offering by Dynamic CI Group related to CI's

[Ed Laar1]

Hi all,

In CSDM3.0 we can relate a Technical Service Offering to a Dynamic CI group. In such CMDB group reside CI's. My expectation is that a TSO related to a Dynamic CI group should be visible from the involved CI's.

Unfortunately: that's not the case or I do something wrong. 

An other question: I like to use the TSO related to the CI's to determine the ticket solver group and the OLA of the TSO. Does anybody know if this works in an OOB instance?

Many thanks for reply's,

Ed

[Ed Laar1]

Hi Jim,

Something I don't understand: What do you mean with new query based Dynamic CI groups previously known as Technical Services?

I think there are Technical Services, Technical Service Offerings and Dynamic CI groups. Dynamic CI group is used to group CI's based on certain criteria like type or location or whatever. Relating a Technical Service Offering to a Dynamic CI group results or should result that the TSO is valid for all CI's in that Dynamic CI group.

From TSO level it should be possible to see all the involved CI's. Reversed it should be possible to see all the involved TSO's from CI point of view.

Note that multiple TSO's can be related to a single CI.

Within Quebec the groups of a TSO are synced with the groups on CI or CI's or CI's in the involved Dynamic CI group. Idea is to use these groups on CI level for ticket routing purposes.

But: When multiple TSO's are related to a CI, CI's or CI's in the involved Dynamic CI group and the groups on TSO level are different the sync of the groups does not meet requirements anymore. Something has to be done to solve this issue.

Curious about your reaction,

Ed  

[Jim Zeigler1]

Hi Ed, to answer your question, a look into the past is needed.

Dynamic CI group history:

ITOM Dynamic CI Groups have been in the CMDB since Service Mapping was added to the platform (I'm guessing it was either the Geneva or Helsinki Release). Their class label was "Technical Service" until CSDM 3.0 defined a Service Portfolio Management class that was also called "Technical Service".  If you read pre-CSDM 3.0 documentation, the term "Technical Service" was used to represent both concepts, making it hard to understand.

In the Paris release(that reflects CSDM 3.0 terminology):

• the ITOM "Technical Service" class (that is monitored by Operations team using the Event Management Dashboard, Operator Workspace, and now the Service Operations Workspace) was renamed to "Dynamic CI Group".
• The "Automated Business Service" class was renamed to "Application Service".
• The original "Discovered Business Service" class that was renamed to "Application Service" in the London release was renamed again to "Mapped Application Service".
• The SPM "Technical Service" class was created as a clone of the SPM "Business Service".

In the Rome release, the SPM "Business Service" and "Service Offering" classes were created and the ITOM "Business Service" super-class was relabeled as "Service". Many SPM users stored SPM "Business Services" in the "Service" superclass until they could be moved to the new SPM classes created in Rome and Paris. The SPM-only attributes that were added to the Service class, are still there, causing confusing in the ITOM services classes(which inherit all these SPM attributes).

Unfortunately, If your instance was created before the Paris release, the label for the ITOM "Technical Service" class was not updated to "Dynamic CI Group" as part of the upgrade to Paris. You may still have both an ITOM and an SPM Service class called "Technical Service".

If your instance was created before the Rome release, you may still have 2 classes (cmdb_ci_service and cmdb_ci_service_business)  labeled as "Business Service".

ServiceNow documentation has been slow to replace "Technical Service" with "Dynamic CI Group". Some of the documentation, form labels and error messages still refer to ITOM Application Services as "Business Services", leading the user to think the form is asking for an SPM Business Service. If I was an end user on an upgraded instance, I would be totally confused by all the changes made as a result of CSDM 3.0 but not reflected in the class labels in the older instances.

What do we need Dynamic CI groups if we already have TSOs?

I don't believe operational CIs like Servers and Applications were ever intended to be referenced or related directly to TSOs because Technical Service Offerings are environment and location agnostic (They have no operational Status (and thus, no operational tasks like alerts, incidents, and changes). They can't be used to represent deployed groups of CIs in a specific Environments (e.g., Sandbox,Dev,QA,Test,Prod) or multiple Locations because that would require a unique TSO for each environment and location.

That is why ITOM Dynamic CI groups (Query-based Services) exist. Dynamic CI Groups are operational CIs with an operational status and severity, just like all the other types of ITOM Application Services.  Queries defined within Dynamic CI Groups are used to create list-based Service Maps whenever Tag-Based and Top Down Discovery can't produce a usable Service Map. If the Queries are created properly, when they are re-executed by a discovery schedule, new Hardware and Application CIs will be dynamically added to one or more Dynamic CI Groups (without the need to change the Query).

Dynamic CI groups are monitored and will have alerts and incidents assigned to them. Keep in mind that all Dynamic CI groups (even those used by SPM TSOs to group CIs for a Service Offering) are visible and monitored by the operations team. They are required to have a parent Application Service Group in the service hierarchy that depends on them.  If there is no parent Service Group, change and alert impacts will not propagate upwards.

If a TSO needs a list of operational CIs:

In my opinion, if a TSO needs to reference a list of CIs, it should reference an existing supported ITOM Dynamic CI group instead of creating a new list of CIs that is visible on the operations dashboards, but is not properly maintained like all the other Applications Services on the dashboard. Like other Application Services, Dynamic CI groups should only be made operational after they have been validated in the context of the full service hierarchy of Operational Services. If made operational without going through the validation process for Application Services, they could create false alerts that propagate upward and disrupt the operation of the business.

If a TSO needs a list of CIs that will not impact the operations and support teams, I recommend the TSO create a related static or query-based CMDB Group that can be updated as needed.  Standalone CMDB groups(that are not referenced by a Dynamic CI group) don't impact the operations and support teams. 

In the referenced video example, the "contains" relationship is created between a TSO and a Dynamic CI Group, but that relationship is not defined in the CMDB class model for the Technical Service Class for the Utah or Vancouver releases. The Class model suggests a "depends on" relationship, but I would think a "uses" relationship to a Dynamic CI Group would be better because it will prevent non-operational TSOs from accidentally showing up in the Affected Services list of ITOM Application Services that operations and support teams see.

I'm not sure why you would want tickets associated with TSOs that describe a Catalog Request. They are not operational and do not appear on the operations Service Operations Workspace (only operational ITOM application Services and Service Groups are visible). The TSOs are not part of a Service Map, so i don't see the value of associating tasks with the TSO.

[Jim Zeigler1]

Hi Ed,

ServiceNow recently added a new Service Portfolio Management class called Technical Service (cmdb_ci_service_technical) which is based on the latest CSDM.  The new class has nothing to do with ITOM services classs (cmdb_ci_query_based_service) that OOTB was originally labeled "Technical Services" prior to the CSDM 2.0 and the Paris release. When I read CSDM 2.0 for the first time, I was totally confused why they were relating an ITOM "Technical Service" to a Technical Service Offering. It turned out they were taking about the unreleased SPM Technical Services class with the same name.

When the new SPM Technical Service class was added, they had to rename the ITOM Technical Service class so I believe they called it Query Based Service before they renamed it Dynamic CI group (similar to Alert Group). Then they released the new tab based UI for creating an Application Service that is also the default when selecting an Application Service from a list view. In order to see the default view (or my view called Discovery Debug), you have to change views, but that is not possible from their UI. They also introduced additional ways to populate a Dynamic CI group that were added to populate tab of the new UI for Application Services.

If you had an existing query-based Dynamic CI group, it was left as is and would show up when you asked for a list of Dynamic CI groups. If you select New to create a new Dynamic CI group, you get a form that does not contain the table and filter fields that were always used to define dynamic CI Groups in the past.

I found that they modified the default settings for a new Dynamic CI Groups to set the table and filter to null. When the table field is empty, the table and filter fields are hidden from the form. I believe they assumed that noone was using them and instead, you will always want to define a dynamic CI group using a CMDB group.

I have a client who has created and maintains hundreds of query based dynamic CI groups. They are much easier to create and maintain than Mapped Application Services and they don't require all the CIs on the map to be discoverable. You can create the filter so it finds all the same CIs that would normally show up on a Mapped Application service (except for those found only by top down discovery). When my client upgraded to Paris and used New to create new Dynamic CI Groups, they had no way to specify the table and filter in the default view of the CI form. You could enable the table field to be displayed by populating it in a list view or you could go through the cumbersome tabbed UI and find the Query option for populating the service. 

On other thing to note. Prior to the new release, I found the easiest way to create a query based Dynamic CI group was to edit the Business Application, change the class name to Dynamic CI Group, personalize the Name to add the environment (e.g. <BA name> (PROD)), then use Insert and Stay. This creates a new  Technical Service. However OOTB, the table and filter fields are hidden and can't be modified on the default view.

I don't see the value in tying an operational ITOM Dynamic CI Group Service for lets say "VMWare hosted Windows Servers" to a technical Service Offering called "Create VMWare hosted Windows Server". The dynamic CI group may have hundreds of VMWare Windows servers created over time, but you can't tell which ones were created using the "Create VMWare hosted Windows Server" TSO. The status of the CIs in the group and the group status have no value when looking at them from a Service Offering. I would think instead, that you would want the Technical Service Offering related to all the RITM request items that were spawned and executed so you can see if any RITM requests have failed. The RITM has a configuration item field that could reference the server it created.

The CSDM mentions relating Hardware and Application CIs to SPM Services but I don't understand what value you would get (and how these relationships are supposed to be maintained). I think this is a bad idea. I would not want SPM CIs showing up in a list of CIs impacted by a change as a result of adding CI to TSO relationships.

I would not expect Ticket Routing for CIs to depend on TSOs. It should depend on the Support Group, Class owner (if no support group is defined), location, and other fields that help you find the best group to own the ticket.

[Mathew Hillyard]

It's interesting reading this long chain of replies, because when I read this sentence:

"My expectation is that a TSO related to a Dynamic CI group should be visible from the involved CI's"

To me, this is saying that from a CI, you cannot view CI relationships upward if it is in a Dynamic CI Group, and hence the Technical Service Offering the DCG is linked to.

The root cause for this is that both the Dependency View and Related Items Formatter - available on a CI form - rely on CI Relationships, and there are no CI Relationships between CIs and the DCG to which they belong. These relationships are stored in the Service Configuration Item Association [svc_ci_assoc] table instead. You can see which CIs are in a Dynamic CI Group (i.e., downward) via a UI action in a CMDB Group linked to the Dynamic CI Group,or within the Dependency View via the Related Items, but not the other way around.

This is an issue in the platform even in 2025. I created an Idea to bridge that gap.