Looking for advice on grouping Dynatrace technical services into business sub-components

[wijayantha8]

Hi everyone,

I’m looking for some advice on the best way to model application sub-components in ServiceNow ITOM.

We currently ingest application and infrastructure data from Dynatrace into ServiceNow using the Service Graph Connector.

Our current service structure is:

The current gap is that there is no logical layer between the main application service and the detailed technical components.

For example, one main application may contain business or functional areas such as:

Dynatrace can identify and monitor technical entities such as services, process groups, process instances and hosts. However, it does not know which of these technical entities belong to a particular business sub-component. This information would need to come from the application owners.

One option we are considering is introducing a Tier 2 Component Service layer:

The possible approach would be:

1. The application team identifies which Dynatrace services or process groups belong to each sub-component.
2. The monitoring team applies a common tag to the relevant Dynatrace entities.
3. The Service Graph Connector brings the tags into ServiceNow.
4. ServiceNow uses the tags to group the technical CIs under the correct Component Service.
5. The Component Service could then support impact visibility, alert routing and incident assignment.

However, Tier 2 is only an option we are considering. We are open to other solutions that may be more suitable or follow ServiceNow best practices.

We would appreciate advice on the following:

1. Is adding a Tier 2 Component Service layer suitable for this requirement?
2. Is there a better ServiceNow or CSDM approach for representing these sub-components?
3. Can tag-based Service Mapping be used effectively for this purpose?
4. Which Dynatrace entities should normally be tagged—services, process groups, applications or another entity type?
5. Can ServiceNow use the tags while still following the existing CI relationships and technical topology?
6. Are there any common limitations or problems with this approach?
7. Has anyone implemented a similar model using the Dynatrace Service Graph Connector?

We would be grateful for any recommendations, design examples or lessons learned from similar implementations.

Thanks in advance.

[Mathew Hillyard]

Hi @wijayantha8 

The advice from ServiceNow is not to create parent/child service records, but to create them all at a single level.

What slightly confuses me is how you got to tiered services from application sub-components? To what do business/technical consumers request access? It seems unlikely you would create Service Offerings for each application sub-component, unless they genuinely offer a specific level of service to specific stakeholders.

To me you need to model how the applications relate to one another - e.g. create a Platform Host Business App called Dynatrace, then Platform Application Business Apps for the sub components. You would then have one App Service per Business App, and have them all depend upon the Platform Host Business App.

This takes care of the underlying infra. What then connects to the Service Offering(s) you choose to create depends upon your own internal analysis. If each sub-component really needs to be its own Service Offering then you have a 1:1 Service Offering to App Service; however it's more likely that you need better-defined Service Offerings that offer a genuine outcome to a technology consumer, which may be provided by one or more sub-components.

How you bring this data into ServiceNow is up to you - but I believe The Dynatrace Service Graph Connector already creates Calculated Application Services for you (or it did the last time I looked at it).

The general idea with CSDM is to try to map out what actually happens in the real world, as far as you can.

I hope this helps!
Mat