CSDM relationship between Service Instances

[Brian Lancaster]

Can you have relationships between different Service Instances? Example screenshot below of how they are modeling a peace of an application. You can ignore the green lines. I did have to redact the a lot but the top Orange circle is the overall application name with production then one of this subcomponents, then finally broken down to its sub components.  All of these have different owners that is why they are mapping it in this manner. I just want to make sure it is the proper way to do this mapping in service instance and that I can create relationships between Service Instance CIs. Since I don't see a relationship between one Service Instance to another in CSDM v5.

[Mathew Hillyard]

Hi @Brian Lancaster 

I don't think the advice on relating Application Services in v4.0 has changed with a rename to Service Instance in v5.0. There are two relationship types listed linking Service Instances:

• Depends on::Used by - used for impact analysis (I think Application Services first appeared in Event management which is all about tracing impact upwards).
• Sends data to::Receives data from - more about API interactions and possibly there is some overlap with Digital Integration Management as the CI Relationship doesn't really tell you much other than data flowing.

Some considerations:

• A service map should wherever possible represent the physical or virtual reality of how the CIs are connected, even in a SaaS situation where you may have a dummy Application CI.
• If you require separate Service Instances, does each one represent its own deployed stack with a direct line of sight to its own Business Application? Unless it's a Dynamic CI Group, it should, to be part of a CSDM service. This is usually a good practice for platforms as they can consist of many different separate application stacks and are good candidates for individual Business Applications.
• What will these relationships be used for? As a map on its own it's fine, but things can get tricky when talking about actual impact analysis - for example, impacted services calculation does not bring in "parent" Service Instances, i.e. a Service Instance's parent or grandparent service instances with either CI Relationship Type mentioned above. Are they all genuinely "impacted"?
• If you have many layers of interconnected Service Instances and you do implement pulling in parent or grandparent service instances, on a complex Change Request it is easy to end up with hundreds of impacted services and associated approvals, which is unworkable.
• If you're doing this just for ownership, then there are several owner fields on each CI class. Don't build and overly-complex hierarchy to solve the ownership problem. For Incident, Problem and Change, you really want to capture ownership of the Service Instances as that should be the stakeholder who is responsible for the entire stack of technology. I appreciate this can get difficult where one CI supports multiple services, but that is a whole other conversation!

I hope this helps!

Mat

[Brian Lancaster]

This is one application and they are splitting our the modules and then what the modules due. As each one is owned by a different person. This is only the representation of one module in that application.

So in the screenshot the top orange circle represents the overall application. The second one down represents the a module and then the last set represent what the module does. Each layer has a different technical owner.

[Mathew Hillyard]

Hi @Brian Lancaster 

I guess you could have Service Instances for each of the bottom layer objects and relate them to the middle layer object. The relationship type depends on the nature of the relationship - is it for impact? If so then Depends on::used by might be appropriate. If not then perhaps Sends data to::receives data from might be more appropriate.

How are these bottom layer objects supporting the services in the CMDB? If they don't directly (individually) underpin either a Business or Technology Management Service Offering, then I'm not sure of the value of having them as separate Service Instances. In this use case perhaps they could be considered as Application CIs instead? That way you can still track ownership separately, but for impact calculation you refer to the single Service Instance.

I hope this helps!

Mat