Seeking suggestion on CSDM Definition on TS & BS

[AbdulAzeez]

Hi,

I was going through the documentation of CSDM. 

Below example if i am understanding correctly 

1 > Core Business Services is a Business service

1.1 > Strategic Planning is a BS

Strategic Planning is a BSO

Integration Planning is a BSO

Profit & Loss is a BSO

1.2 > Marketing is a BS

Customer Analytics is a BSO

Marketing is a BSO

Leads is a BSO

Pricing is a BSO

1.3 > Sales is a BS

Catalog is a BSO

Order is a BSO

Track is a BSO

Pay is a BSO

Support is a BSO

If my understanding is correct then can anyone please help me in understanding the definition it says "One level not a hierarchy of BS / Ts"

[CMDB Whisperer]

I believe what this means is simply that you should not define a Business Service as a child of a Business Service.  The Business Service should only have a child of a Business Service Offering.  Not another Business Service.  Same with Technical Services.  While the "parent" field has been present on the Service class for quite some time, long before CSDM was published, they are providing this advice to clarify that the parent field should only be used on the Offering itself (which should have a parent of type Business Service or Technical Service.)

That said, what they do not indicate is whether Service Offerings can have parent/child relationships with other Service Offerings.  And in fact, I have implemented such a model previously, before there was any indication in CSDM about where or whether hierarchical relationships should be used on Services.  My justification for this was that a single offering could be derived into child offerings that provided the same basic service offering for different subscribed locations or departments.  I wonder what the thought on this related question would be from the CSDM team...

[Kristine Naess]

Hi Abdul,

The matrix you refer to is an interpretation of TBM Council Taxonomy 3.0. We have implemented this in our organization by using service portfolios and service taxonomy nodes. There are many otions on how to do this: by using one service portfolio per Service Type (End user, Infrastructure, etc. ), or keep all in one you call f.ex. TBM Portfolio, etc. We have chosen one portfolio per service type. 

This is how it currently looks in our instance:

Then all level 2 in the matrix is implemented this way:

And level 3 this way:

All level 3 nodes must have a parent. 

If we look into one of our Class=service, Classification=Business service, it looks like this:

The taxonomy node has the following parent node:

And it has the following service offering:

Which again has this catalog item:

Since we follow up all IT cost in Servicenow, this helps us explain cost and measure across centralized and non-centralized IT, for example. So there could exist multiple SN business services across the org. that delivers f.ex. virtual compute services, but we can report on all of these by using taxonomy nodes. 

I hope this was helpful.

Cheers,

Kristine

[Mark Bodman]

In this this video we discuss the differences between Business and Technical Service.  As for the other input here, it's all correct as well.  

The main issue we see is that folks try to relate a service to another, without context.  Our CSDM model avoids creating hierarchies that tend to be ambiguous. 

https://youtu.be/jWfwTHTLlzI