CSDM and reporting per managed environment

[Jan Ujcic1]

I am mapping standalone infrastructure environments (IAAS) into CSDM.

Typically, technology services (e.g., network, hosting, database) are created with related service offerings. However, we have a key requirement: we must report on CIs, tickets, and time spent per specific environment delivered to a consumer.

We provide multiple environments, internally and externally (as a business service/offering). Some can be modeled as application services (when tied to a specific business application). Others cannot, as they are pure infrastructure environments where consumers can host multiple business applications. 

How should this be modeled in CSDM? While we can define the underlying technology services, we need a way to group VMs, servers, network components, etc., under a single reportable entity per environment (for time and ticket tracking).

My current thinking and options:

• Would modeling this as an IAAS technology service, with separate service offerings per environment and all related CIs attached, be appropriate? I am aware of potential operational drawbacks, but environment-level grouping is a critical business requirement. 
• Or would it be rather acceptable to put everything under an application service even if it doesn't meet the description of a deployed instance stack that delivers functionality?
• I also see options on potentially grouping these things on the contract level based on the related service offerings but that can introduce additional complications. 

Anyone had similar experience or challenges? I'm happy to provide more information or discuss it in more detail.

[Mathew Hillyard]

Hi @Jan Ujcic1 

Two observations:

1. Separate out the supporting service being provided - an environment - from what requestors will do with that deployed.
2. Don't group or associate something with non-CMDB data unless there's a compelling reason to do so - so for Contracts, unless the entire Service Offering is fulfilled via technology or a Vendor against a single Contract, it wouldn't make sense. Instead build offerings based on your consumer audience.

Create Service Offerings which differ by SLA, cost, geography or other compelling element. If something has "preferences" that don't materially impact these elements, make these questions within the catalog item but keep under the same Service Offering.

If the Environments being offered to be built into App Services essentially offer the same service, then make it one Service Offering. For the environments that are infra only, one offering per technology makes sense (e.g. like offering Windows or Linux Servers separately).

Technology Management Services have Offerings that (where no supported app technology is in scope) are recommended to link to Dynamic CI Groups, so in this instance build CMDB group(s) with query(-ies) that correspond to all the deployed environments for your Offering (but be careful with the 10,000 CI limit on a Dynamic CI Group).

I hope this helps!

Mat

[Jan Ujcic1]

Hi @Mathew Hillyard ,

Thank you for responding. Your response aligns very well with the CSDM guidelines, but it is very hard to implement when you have a very custom service delivery model, as in our case.

One of the core services provided by the company is IaaS. In a specific environment, there can be Linux servers, Windows servers, firewalls, etc. One customer can have multiple environments such as this, meaning they consume the same service multiple times but logically separate the environments from each other. Knowing what belongs to each environment is crucial business requirement. It seems this layer does not exist in the CSDM.

We can have multiple technology management services providing components that form a final IaaS environment that is then delivered to the customer. There, they can host whatever they want, and it is outside the company's domain. I am asking if there is a way to achieve this kind of grouping with the available CSDM entities, or if we need to invent something new.

Thanks,

Jan

[Mathew Hillyard]

Hi @Jan Ujcic1 

You mention the "final IaaS environment". Perhaps this should be the target of your Service offering and present it via an Order Guide on the Service Catalog so you can bundle individual catalog items depending on user preferences. You can set up each item to be linked to their own Service Offering if you need the granularity - but this is not a mandatory step so you can have a small number of Offerings (or even one if it suits your business model and doesn't obfuscate parts of the CSDM services that underpin it). You can relate this to a Service as part of the platform services taxonomy layer of the Service Portfolio

I've taken this approach with composite services in the past  - but you still need the technical support offerings that underpin the infrastructure by type (e.g. windows server provisioning) for regular use cases.

I hope this helps!

Mat

[Jan Ujcic1]

Hi Matthew,

What you are describing is going in the direction of what we need. Are you able to share a simplified example of a composite service that you've built in the past? The challenge for us is that the delivery part is usually done already through a long-term contract and the ServiceNow part is just gathering the CIs together under the correct umbrella for maintenance and reporting. This complicates things since the sales part of the organization won't adapt to the service offering delivery process that you describe - it is rather messy and hard to define.

Thank you for your time and suggestions so far, they are very helpful!

Jan