Defining the 'Depends On::Used By' relationship between an Application Service and Infrastructure CI

[PG2]

I'm hoping someone in the community can add some thoughts on the Depends on::Used by relationship type when used to describe a dependency between an Application Service and an Infrastructure CI (such as a server).

I'm determining whether the relationship represents a current and active dependency between the CIs or if it intends to reflect any historical reliance.

How do others use this relationship type? And how do you maintain the relationship based on different scenarios? (such as the one I've attached as an example)

[PG2]

Thank you for sharing. I'm unfamiliar with the service mapping population method, but I was searching for OOTB behaviour for the scenario where the Application Service is Retired.

If the OOTB pattern removes the entry point, that reinforces the purpose of the 'Depends on::Used by' relationship type. e.g. it reflects the current/operational dependency.

Most of our Application Services are populated using the manual method, and I've not found OOTB business rules that would remove relationships. There is also some conjecture across the community forums about the correct approach.

[Ed Laar]

Hi,

First of all: The CMDB should represent the as-is situation of the infrastucture, it's components, services and so on. In this way the CMDB can (and should) be used to do incident impact and priorization, Change impact analysis in order to prevent from Service down situations after changes and so on.
History answering a question like 'What was the situation with this component a month ago' should be answered by the history list of the component (do not forget to enable this feature!).

CI-CI relations are used to create groups of elements/ CI's that provide together a certain functionality or service. Simple example: Dbase runs on::runs Server. As soon as one of the two CI's change their state or are removed also the CI-CI relation should be changed or removed, otherwise you will have CI-CI relations that do not relate any CI.

To maintain CI-CI relations Service Mapping is the way to go here. Adding rules or creating reports on 'incomplete CI-CI relations' can also be a possibility.

Ed