CSDM 5 - TSM Offerings - Real World Examples

[markterringon]

Hello,

Hope this finds you well.  I did try a search on the community for anything to do with "TMS Offering", but the search engine here ignores quotation marks.

We are moving from CSDM 4 to CSDM 5 and currently having issues with TMS Offerings.

In all the CSDM 5 data model examples that I can find from ServiceNow you may have the following examples of "TMS Offerings":

• Windows Support
• SQL Support
• Network Support
• System Monitoring
• ServiceNow Administration
• Database Administration
• D365 Administration
• Various Support
• SaaS Platform Admin
• Yet-Another-Platform Admin

From my understanding you can link a Contract to a TMS Offering.

But the examples I see missing are the ones that will be useful for every organisation that has legacy IT, and multiple applications that provide the same functionality.

So.  If I were to have a TM Service of "Location Services", by all the examples provided by ServiceNow the TMS Offering will be "Location Services Admin".

But what if you have multiple products?   The view I gained from reading the CSDM 5 documentation is that the TMS Offering is the product/service providing the TM Service.   So in the "Location Services" TM Service you might have two TMS Offerings:

1) Google Maps

2) Locate

Both linked to their respective contracts.   Also you might have an external partner that provides a business service - such as compliance modelling. 

Your company signs an agreement to use this business service, recorded as the Contract.  The Business Service is accessible via an API.  So the TMS Offering is a Business Service accessed via API.  You create a Service Instance of this TMS Offering, and you create a relationship between this instance of the TMS Offering with the Business Application consuming/using it (though when you do this it has a "depends on" relationship which seems incorrect).

I understood TMS Offerings to be linked specific products that provided that service.  Hence having TMS Offerings of the same service to select from in the catalogue or within a project.

If you have yet to carry out application rationalisation your company will have multiple products providing the same functionality.  So you need a mechanism to be able to select specific products that provide the service.

Has anyone else had this as an issue?  If the TMS Offerings are really linked at the "definition" level then how do you offer multiple applications doing the same thing?  Having Services like "Location Services Google" & "Location Services Locate" would be a poor approach as you loose the service when switching products.  Whereas the Service Stays the same when your TMS Offering is the product providing the service.

Thanks for your help

[Dan_Junqueira]

Hey Mark how are you?

I think there are two concepts getting mixed together here, and to be fair I can see why because some of the CSDM examples make this a little confusing.

My understanding of CSDM 5 is that a Technology Management Offering is not intended to represent the product itself. It is more a variation or packaging of the Technology Management Service — for example by environment, geography, availability, support model, pricing, commitments, etc.

So using your example, I would probably keep:

Technology Management Service

• Location Services

Then Google Maps and Locate would still exist separately as the applications/products that actually provide that capability, rather than making the products themselves the definition of the service.

For example:

Location Services
TMS Offering: Production / Standard Support
Service Instance: Google Maps Production
Business Application/Product: Google Maps

and potentially:

Location Services
TMS Offering: Production / Standard Support
 Service Instance: Locate Production
 Business Application/Product: Locate

That way the service remains stable even if the underlying technology changes, which I think is exactly the concern you raised. If you replace Google Maps with another product tomorrow, you do not need to redesign the Location Services service model.

Where I think it gets interesting is when the choice of product is actually part of what the consumer is selecting.

If users genuinely request either “Location Services using Google Maps” or “Location Services using Locate”, and they have different contracts, support models or commitments, I think there is a reasonable argument for having separate offerings under the same TMS, for example:

• Location Services – Google Maps

• Location Services – Locate

But I would see that as the offering representing a different consumable/package option, not because a TMS Offering equals a software product.

I would still model Google Maps and Locate independently as products/applications and relate the appropriate Service Instances to the offering. This also helps later with application rationalisation because you can clearly see that two different technologies are supporting the same service.

One other point regarding your external API example: I would be careful with creating a generic Depends on relationship directly from the Business Application. In the CSDM 5 Service Delivery model, ServiceNow specifically models a Business Application as consuming a Service Instance, while service-instance-to-service-instance dependencies use the Depends on / Used by relationship.

So I think your overall thinking is correct that you need to separate “what service are we providing?” from “which technology/product currently provides it?” , I just would not use the TMS Offering as the primary product record.

This is also one of the areas where I think the official CSDM examples could use more real-world scenarios involving multiple legacy products providing the same capability.

Hope this helps. and please consider mark it as helpful.

Dan.

[markterringon]

Hi @Dan_Junqueira ,

Thanks for your reply; I'm good thanks.

I still think that is not right so apologies. 

There would not be a Business Application of Google Maps.  This would be Location Services accessed via API.   From reading the SN documentation a Business App is something that provides a Business Capability or Business Function.  Which are specific to your company Value Chain and Enabling capabilities.  Location Services are not part of a Business Capability nor Business Function and not a Business Application.

However, the Service Instance of the Business Application (CRM - Prod) may consume/use the Location Service to confirm an address.  So the Location Service will be added to the CRM Prod instance as a Technical Service Offering (in the Set Relationships section).

In reference to the "Depends on" relationship.  It was not one I created and it is something I disagree with.  It was the output of setting up the "Populate Method" for the Service Instance.  I did not get to choose the relationship type.

For me, to Depend on something it needs to be fundamental.  In the "CSDM 5 Configuration Item Relationships" Diagram, the only relationship between Service Instances (even though they still have the CSDM 4 terminology of Application Instance) is Depends on::Used by.     Yet when you look at the relationship from a different form on the SN platform it becomes Contained::Contained By.   Which also seems wrong.   

In SaaS service terminology, you are consuming the service.  But that is not an option.  I have not seen the option to use the "Consumes::Consumed by".  In fact in all of my CSDM 5 documentation that is not an option.

Is there an updated version of documentation that shows the "Consumes" relationship?  Is there a specific form for this?  As I can only see "Contained" and "Depends on" as generated CI relationships.

I also do not see your "Business Application as consuming a Service Instance" relationship.  I am using the CSDM 5 White Paper:

We're not using TMS Offering as the primary product record.  We will use the TRM Products in EA to define the standard versions of the products.  I've been told the TMS Offering and the TRM Product are basically contextual view of the same thing, and not all TMS Offerings would have an associated TRM Product.

I think this conversation highlights the disconnect the documentation creates.

Thanks again for your help.

Mark

[Dan_Junqueira]

Hey Mark, 

Thanks for coming back on this, and actually you are right to challenge me on a couple of points.

I went back to the CSDM 5 white paper and I mixed some of the older CSDM relationship terminology into my previous answer.

In CSDM 5, the relationship shown between a Business Application and an Application Service is Uses::Used by, not Consumes::Consumed by.
And between Service Instances the white paper does indeed show Depends on::Used by.
So on that point, what you are seeing in the model is consistent with the current CSDM 5 diagram.

I also understand your point about Google Maps better now. I wouldn't insist on modelling Google Maps as a Business Application in the scenario you described. If you are consuming an external location capability through an API, and you don't manage Google Maps itself as part of your application portfolio, then treating the API/service as part of the Service Delivery model makes more sense. CSDM 5 actually calls APIs out specifically as part of that domain.

Where I still find it a little confusing is exactly the same place you do: semantically, saying that CRM "depends on" the Location Service feels stronger than saying CRM "uses" or "consumes" it.
But from what I can see, Depends on::Used by is the relationship ServiceNow currently prescribes between Service Instances, even if it doesn't always read naturally from a SaaS/API perspective.

And yes, regarding the TMS Offering, I think we're closer in our thinking than my first reply suggested.
I agree that the product itself should remain represented through the product/TRM model rather than using the TMS Offering as the primary product record.

The CSDM 5 white paper defines the TMS Offering more as a way of stratifying the Technology Management Service, environment, geography, availability, support model, capability, pricing, commitments, etc. which is why examples such as "Windows Support" or "SQL Support" can make the real-world SaaS/product scenario less obvious.

So I think your original question is still a very valid one: how do we cleanly represent two alternative products delivering the same technology service without turning the service taxonomy into a list of products?

That is the part where I agree the documentation could provide a much better real-world example, especially for external SaaS and API-based services.

Thanks for the discussion, it made me go back and re-read that section of CSDM 5 as well.