Technical Service Offering by Dynamic CI Group related to CI's

[Ed Laar1]

Hi all,

In CSDM3.0 we can relate a Technical Service Offering to a Dynamic CI group. In such CMDB group reside CI's. My expectation is that a TSO related to a Dynamic CI group should be visible from the involved CI's.

Unfortunately: that's not the case or I do something wrong. 

An other question: I like to use the TSO related to the CI's to determine the ticket solver group and the OLA of the TSO. Does anybody know if this works in an OOB instance?

Many thanks for reply's,

Ed

[Marc De Mol]

Hi Ed,

We had the exact same thinking, we discovered a number of things:

1: a CI can receive the "Support by Group" from the TSO through the DCIG, the prereq is that the CI only belongs to 1 DCIG, following a reply to a case, if multiple, the OOTB behavior is that the last updated DCIG will populate the Supported by group.

2: You can add a script that would populate a "Related list" with the TSO so the TSO becomes visible, this doesn't help in the lineage though.

3: For services like Active Directory, Anti Virus and others, our architect proposed to create a script, containing the logic as it would be in a DCIG, that maintains MAS 2 MAS relationships for the dependencies. (Kudo's Konstantin Kosev)

[Alex_Dundon1]

Hey Ed,

I was just playing in a non-prod instance yesterday and saw the same behavior and had a similar question. My suspicion is that it creates too much overhead to constantly add and remove relationships in the relationship table based on a dynamic query. Instead, they opted to create a container/place holder that then has all CI's underneath it. If you really wanted to see the full relationship tree, you can do that in CMDB Query Builder. Again, that is only my guess and a someone much smarter than I would have to confirm.

For your other question, I think it's based on the main Configuration Item in the ticket rather than the Service Offering. A particular CI may belong to multiple Service Offerings.

[Ed Laar1]

Hey Alex,

Thanks for your reaction.

Regarding the BSO and TSO around an Application Service. My understanding is that the BSO is user/consumer facing and determines at least the SLA as soon as a ticket is created on that Application Service. Yes: If different ticket types can be raised against that AS a BSO with a commitment covering all those ticket types should be related to that AS.

My understanding is that the TSO is support/solver/provider group facing and determines at least the OLA (in fact the SLA) as soon as a ticket is created on the AS. Also here for all the different ticket types a commitment should be created. Different TSO for different levels of support and/or different support groups (and this also can be groups manned by a Vendor) should be created.

In this way a) the routing and SLA/OLA are very transparent and b) we use CSDM in all it's capabilities.

Yes: There are more methods to determine SLA/OLA and assign tickets but if CSDM is used making use of BSO and TSO should in my opinion be THE way to go.

Am I wrong in this idea's?? Looking forward to your feedback.

Ed

[Alex_Dundon1 · Accepted solution]

Hey Ed,

I think you are on the right track here, but the TSO is just like the BSO except in the scope of the service. For example, Technical Service Offerings are typically things like Windows Hosting - Gold Level, Local Area Network - AMEA or End User Computing - Executive level. There may or may not be Application Services that are consumed by the Technical Service Offering. There are however infrastructure CI's like servers, switches or specific computers that help provide that Technical Service Offering.

In the end, it really depends on the specific CI that is having the issue (it can be an infrastructure item, or Application Service). The routing of the ticket for support is based on the Configuration Item's Support Group or Assignment Group. The commitment to return the CI to working order is based on the specific Service Offering that is being impacted.

Hope that helps!

[Dominic5]

This video explains HOW to relate Dynamic CI groups to Technical Service Offerings (around the 21 minutes mark): (1) CMDB Health Deep Dive - CSDM Dynamic CI groups & fixing data required for audit and incident - Y...
... as I don't think you can yet do this via Service Builder.