Best practice - CI relationships & Retiring
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-02-2020 11:14 AM
We have a consultant review our CMDB and one of the recommendation he gave was that we write a script to remove CI relationships when a CI is retired. While I can see the logic in this, I'm struggling on if this is best practice or not. I'm thinking if this were best practice, ServiceNow would have built it into the base toolset by now, right?
What are others doing?
- 2,498 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-02-2020 11:30 AM
I would not script the deletion of relationships. They represent updates that are still required to the CIs on the other end.
For example, if you replace a database server, you would need/want to update all of the apps that connect to that database. If done correctly, there should not be any outstanding relationships. If there are any left, that means app updates have been missed and you need to be able to identify and correct them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-02-2020 11:50 AM
That's a good point John. So process-wise, you should manually be dismantling the relationships on retirement then huh? There are quite a few relationships that Discovery has built out (ie router to server) that might not be at the forefront when retiring a erver.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-02-2020 05:57 PM
I would suggest that it's about strategy and scope. When you setup your CMDB, you define which CIs you are interested in tracking. When you setup discovery, you should either limit the data to fit your CMDB strategy or update your scope to accommodate the additional data you are discovering.
Treat your CMDB as a living thing... you don't just setup CIs and let discovery do the rest of the work... when discovery detects new devices, have the class owners determine if/how to update the records related to their classes. Do this periodically.
Allowing discovered data to simply get dumped into a CMDB without any strategy will fill your CMDB with data that you cannot use effectively. In the case of stale relationships, it can cause service mapping and change impact analysis to start throwing errors or just taking a long time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-02-2020 03:48 PM
This is a usual practice that I put in for customers. The dependency relationships are meant to show things that are connected together as the state of your enterprise. Having retired servers still listed to an active service will degrade that integrity and trust.
This isn't automated or built into the platform because there isn't a "typical" retirement process that all customers adhere to. Some completely forget to update their statuses, others audit the heck out of it, and there are those in the middle that only track certain class types. It's up to your maturity level to how much you want to automate and get rid of.
