Understanding TSO - Technical Services and Deliverables

[ivaroen]

Hi all 🙂 

I am trying to get my head around the Technical Services and TSO - and TSO deliverables to an order. 

Example. I am ordering a server of type Linux/Unix - I have a technical service of type infrastructure Linux Management that is the owner of the technical service and they have a technical service offering - Linux Servers that is available for the technical consumer.

Given that "EVERY operational CI should be associated to ONE and only ONE owning Technical Service" the additional requirements to a server must be set up as either commitments to a TSO or as Technical Services set up as deliverables connected to the order. Say that not only Linux Management deliver infrastructure - they also deliver other things like patch frequencies - health monitoring etc. Other Technical Service Offerings from other Technical Services e.g. Disaster Recovery, Failover options and more can be applied in the same order. But they will only be options to an CI created. 

What is the best way to handle these extra elements/offerings that apply to the CI eventually created? 

As a technical consumer I want to be able to order exactly the type of needs I have for my System. I want 24/7 monitoring, I want hot standby and also backup of all servers. So these should be defined as deliverables - and how do I then relate all these to the CI itself? Tag-based, attributes?  

Hope the question is not to unclear 🙂 

Thanks!  

BR Ivar

[Tobias]

Hi Ivar, 

I can recommend this video about Technical Services. Ever wonder why there are 3 Technical Services in CSDM? - CSDM - Common Service Data Model - Video -...

In your case I think it might be useful to hear about the 'delivery' category discussed around 26:30. 

You might also want to consider the naming of your TS and TSO. To my knowledge TS is what outcome is being delivered and TSO is how/some flavor of this. For example: 

TS: Linux servers   -> TSO: Linux gold support, Linux silver support, Linux bronze 

Only one grouping of Linux servers will have gold support. 

/Tobias 

[Barry Kant]

Hi Ivar,

that is a while ago 🙂

the fact that it can link upto 1 Service Offering is due to the solution choice of syncing data from a service offering to the CIs mapped in the dynamic CI group. That is a bit short sited indeed. I am not sure about the roadmap on this, but 1 option could be to specify specific relation types for the synchronisation. 

The legacy way is the cmdb_rel_group relation from CI to Group that includes also a Type attribute. In here the purpose could be defined. eg DR Group-DR Type. I do see options in this combination to sync multiple Service Offerings to downstream CIs. 

In this approach it means the trigger of synchronisation needs an identifier what to sync, and the implementation needs to be very consistent.
The impact to ticketing is not a lot right now (I think) if it is a technical incident. The Impact Analyses can be done towards Dynamic CI Groups (sys property) to list all technical service offerings related to the CI. 

From the Business Side I would link the Technical Service Offerings as Depending Offerings from the Business Service Offerings (if that is known --> chain of support).

It requires some tweaks to current datamodel and processes.

Cheers,
Barry

[ivaroen]

Hellu Barry! 

Long time indeed! Hope all is well 🙂 

I agree that something is missing here - and that is what we are trying to find the best approach to handle and in the same time avoid technical debt. 

I will look a bit deeper into what you are saying. I would like of course a simple way to distribute the different selection from the RIT to the CI without messing up the oob logic. 

BR IVar

[CMDB Whisperer]

I agree that it is shortsighted to assume or assert that only a single technical service will be up stream from a given CI.  I understand this was done to simplify the synchronization of support group, but that is only one aspect of these relationships, and in the real world it is not something that you will always be able to achieve.