CSDM 5 - Technology Management Services - is this restricted ?

[markterringon]

Hello,

We are moving from CSDM 4 to CSDM 5 Data model and redesigning the TMS Offerings.

We have designed a portfolio of services.

But we have situations where the same piece of software can be an offering for multiple services.

For example:    Microsoft SharePoint

This could be an offering under:

- Collaboration

- Knowledge Access

Yet in ServiceNow the Offering is only allowed ONE parent.

There is a lot of software that can linked to multiple Services.  But it seems ServiceNow thinks a piece of software can only be defined as one thing...

Do we have to accept that SN can only manage one relationship between an Offering and an Service ?

I see this as a big flaw (error).  

Has anyone else come across this issue and did you have an acceptable workaround or did you simply align with what we can do in ServiceNow currently ?

I also find some of the relationships to be wrong (from a logical viewpoint).   For example "Depends on" is very different than "consumed by".

A TMS Offering Service Instance is "Depended on" by a Service Instance of a Business Application.

This would suggest the Bus App. service instance could not run or operate without the thing that it "depends on". 

Which is very different to a Service Instance "consuming" another.  This is the main relationship type between Service Instances - but it seems wrong and oriented around the technology stack (if part is missing then the app won't run). 

If an external Business Service is interacted via an API then this is a subscribed or consumed service.  This is not depended on...   Depended on suggests it is needed to "run" which is not true.

Has anyone had any luck on migrating to CSDM 5 ?    This seems one of many issues I am having with their view of what EA is, and how you link everything.

Thanks for your help in advance.

Kind regards,

Mark

[Mathew Hillyard]

Hi @markterringon 

I think you are confusing a Service Offering with a piece of Software. They are not necessarily the same thing.

A Service Offering should be the thing being offered, with a friendly name that end users and the service desk should readily recognise. It can and often does contain publisher or product names, whereas this is usually discouraged for Services.

You gave the example of SharePoint. It can be used for multiple use cases. What are those use cases? They are the Service offerings. You can choose to include SharePoint in the name, or not depending upon your organisation. But neither is SharePoint. Some orgs stratify this further into individual SharePoint sites (for example the company Intranet, which many companies now host directly in SharePoint), plus there should be Technology Management Service Offering that supports the development, maintenance and T2/T3 support of SharePoint). They should all be related to the SharePoint Production Service Instance (or the relevant instance if you need multiple production instances).

As a side point: this is where modelling the Service Portfolio early really helps - if you get your Service taxonomy clearly defined down to the leaf node then the Services naturally find their common homes. The Offerings become easier to categorise as a result.

I hope this helps!
Mat

[markterringon]

Hi @Mathew Hillyard ,

Thanks for the message, hope you had a good weekend.

Ok SharePoint was the wrong example to choose.

But I have spoken to a number of people who all mention the ambiguity of documentation, and lack of proper real-world examples.   

For instance, there was an example in a webinar last week of someone upgrading the Oracle Database under an ERP.   Who even does that in 2026 ?   All the ERP vendors I know have SaaS platforms or dev environments that are "spun up" from containers.  I've not had to consider an ERP as an n-tier stack for 25 years, and that was an example in September 2026.

But lets look at a Technology Management Service - which is enabled through the TMS Offering.

So we have a TM Service of "Address validation".   We have a number of products that provide this:

• Google Maps
• Loqate
• Smarty
• Lob Address Verification

A TMS Offering can be linked to a contract.  The TMS Offering can be linked to a number of Service Instances, e.g., "Service -Prod", "Service - Test", etc.

So how would you connect a Contract for a service or SaaS Platform if they are not Business Applications?  We need to see how much these cost and who is consuming them.

If you have multiple software providing the same function how do you let the user select a specific one?

You can't have :

• Address validation - Google Maps
• Address Validation - Loqate
• Address Validation - Smarty

This would be a bad way to offer services.  The TMS Offering was the "choice" selected from the Service.   

Lots of SNOW examples have the TMS Offering at the level of "Dynamics Admin" - which I think is poorly named.  Does this mean that in my example the TMS Offering would be ?  "Address Validation Admin"?

Also with an ERP how is technical services offering "ERP Admin" ?  When you might have a strategic partner offering the Dev environments and your "Business IT" may manage the Production/UAT environments.  These would not be considered "Technology Management Services", but "Business Systems" - different department, different services.

Organisations still have legacy and application rationalisation exercises.  There will be duplicates of functionality.

How do you connect a contract to a product or service ?  If the TMS Offering is not linked to a product or service provided?

I have asked a number of people in the EA world, people that use ServiceNow, and I have even put the scenario to Copilot and ChatGPT - both of which lean to my view.   But I am being told my view is wrong.

How do we link the contract to the "service" provided by a company if the SNOW Object is not a "Business Application" ?   If you are saying the TMS Offerings have names like "ERP Admin", "Knowledge Management", "Data Storage Operations", how do we link contracts to multiple applications/services that offer the same thing?

We are not having an issue modelling the portfolio - the issue is linking the contract, being able to show the money, and being able to show the multiple "offerings" of the same TM Service.

Thanks,

Mark

[Mathew Hillyard]

Hi @markterringon 

If it's running code on an infrastructure host (either accessible to you or not) that a user can engage with, then in all likelihood it's a Business Application. There will always be exceptions, of course, but an organisation should have an inventory of all their Business Applications, precisely so they can understand what they have, what overlaps, what to invest in, and what to retire or replace. In your example above, Google Maps, Smarty and Loqate all fit the definition of a Business Application.

If your organisation offers multiple ways to search for and validate addresses, and either different sets of consumers, support or usage, then they need to be seprate service offerings. The fact that they are SaaS does not change the model. In addition, the fact that they overlap also doesn't change the model - in fact it supports app rationalisation by shining a light on what applications perform the same or similar function(s).

The only note of caution would be whether these all provide an actual service, or are instead just APIs called by apps (e.g. the Google Maps API). This might complicate matters but if you don't create a Business Application for Google Maps, and somewhere in your business someone relies on it to carry out something that ultimately supports a Business Service Offering, how do you account for managing the technology strategy and technology risk of offering such a capability, managing app rationalisation for overlapping solutions, identifying inc/prb/chg for such technologies?

So, in summary, Address Validation as a TMS and Google Maps, Loqate etc. as TMSOs looks perfectly valid to me. Each one is connected to a Prod Service Instance that is an instantiation of the relevant Business Application. The fact that you cannot physically access the infrastructure these apps are provided by makes no difference. That is the nature of SaaS - ServiceNow is the same (unless on-premise). Support for these Service Instances needs to be decided by whoever ultimately owns access to those apps. The Contract for what "flavour of service" is delivered (which is another definition of a Service Offering) lies at the Service Offering, where it belongs.

"ERP Admin" doesn't sound like a service to me, more like a support group. Organisations usually have to make a choice whether to provide dedicated support offerings for every application or centralise with app support as a single offering - but this depends on the organisation. For a very large enterprise it might make sense to have (for example) a dedicated SAP HCM TMSO linked to the prod Service Instance with a dedicated app support team; for a small org a single app support team and offering may suffice.

I hope this helps!
Mat