Managing Stale CIs effectively. Deletion vs Retirement

[Tom104]

Hi,

How do you personally manage your CIs when it comes to staleness? I'm dealing with an estate of circa 50k Stale CIs

Do you mark them as retired or delete them, also, what is the reasoning for your choice?

Does anyone know if deleting a CI actually deleted any association with incidents?

Thanks

[Anshu_Anand_ · Accepted solution]

First you need to know are these stale Ci not used anymore or some issue which is not updating these.

If its not used anymore, retire them. Deleting is not a good practice .

Does anyone know if deleting a CI actually deleted any association with incidents?

No incident gets deleted. The CI will be not available which was linked

Hope its helpful

[Brian43]

I agree with Anshu.  First, why are these stale?  Discovery or ingestion failure?  Are these CI's that need to be managed manually?  Is this a data owner issue or data owner process failure?  Who owns these CI's, or should I say, who owns the classes of these CI's.  Do you have a Configuration Librarian or CMDB Librarian process established?

Second, if it is found that these CI's are "really" no longer viable and no longer need management; retire them.  Deletion is not a best practice.

Yes, deleting CI's can cause issues with those Incidents, Requests, Problems, Changes, etc. that they are associated.  It will break those linkages and cause data corruption.  It is always best to retire or decommission CI's and retain their historic information in the system.

I will add, there are times when a CI might be deleted.  Duplicates being one of them.  In most cases, the de-duplication process/workflow resolves and "merges" the data into one viable/usable CI.  In some cases, this process just doesn't fit and will make more of a mess if used.  In that case, it may require a manual "merge" of the data.  Using the CI with the most related items as the master, you have to manually update that master with the information that seems to have been collected on its duplicate(s).  At this point, when you feel comfortable that all data has been moved to the "master" CI, the other duplicate(s) should be able to be deleted.  (Note:  This should be a VERY rare option but I will say, I have used it on occasion.)

I hope this helps.

[Tom104]

Hi Brian,

Thanks for your thoughts on this. We have me, one person managing the CIs. We've no formal processes around this as yet as we've never had a CMDB before but are slowly moving towards having a defined process.

We don't have owners of the CIs etc as yet, it's just down to me to manage, we have a massive estate and a lack of knowledge as to what sits where and who around the business "owns" it, as we have a lot of legacy kit/services that crop up once in a blue moon but are still required.

As for Deleting the CIs, I agree that it's probably best practice to retire them on that basis then.

[Brian43]

Tom, I understand your position well.  I have come into that situation more than once.  The CMDB was turned on and there was no planning on the care and feeding.  I have lived through three CMDB implementations and all were required the building of those processes.  All while working alone or working with a small staff of field technicians or service desk agents that required training on ITIL, Configuration Management, CMDB Health, ITAM, etc.

The CMDB training here with ServiceNow is outstanding and most of it is free.  There are some areas you can get right up to the point of needing to pay.  There are CMDB micro-certifications that are great to grab.  The knowledge inside the Now Learning for CMDB, ITAM as a whole, CSDM, and ServiceNow as a whole is invaluable.

There is a great book out there called "The CMDB Imperative" by Glenn O'Donnell and Carlos Casanova.  This is a planning, implementation, build, philosophical guide on the CMDB.  I highly recommend it for is completeness.  It goes into the federation of the CMDB and building those piece parts that need to managed by the data owners; not you.  This is a concept that you will have to sell and continue to promote.  You don't own the data, you own the database and guide who, what, when, why and how the data is ingested, managed, and dispositioned.

Good luck and do not hesitate to reach out to me if you have a question.  I will try to help.

brian.minger@bcbsla.com or through the community forum.

(Note:  The attachment is from an IAITAM conference in 2020.  It speaks to ITAM as a whole but it has great information around data management and ownership.)