I'd like to use terminology like "age old" idea in this case, however it's bit early to call software issues "age old" just yet because software has not really been around for ages just yet. But then again when I look at my 10 year old son there I could fit a couple "ages" of 10 year olds into the era where software has been around. So I think I'll be OK to say that the concept of retaining software records for a specific purpose has been linked to an "age old" problem with that type of retention. In our case, the case of BMC AtriumCore CMDB, that type of record would be an Asset record, a CI, Configuration Item or what some may think of or understand as "an inventory".
Inventory records are definitely useful to have. Specifically for trends, cost audits, outage research and so on. Especially if the status of the record has been tracked for historic changes and what we refer to as Asset Life Cycle (AssetLifecycleStatus). You can see when the CI was Ordered, Deployed, End of Life'd and Deleted. All useful stuff. All of these lifecycle states have their purpose and a CI will live very happily in the BMC.ASSET dataset. But not "ever after". Enter the arena: Mark As Deleted = Yes.
You see the last status I've listed, namely "Deleted", is actually an instruction for the CMDB workflow to purge that record and hence that record is "no more" once BMC AtriumCore Reconciliation Engine (RE for short) reconciles that data. OK, so why is this a problem?
The issue with this is people's expectations on what these records should be and their presence in the BMC.ASSET dataset is that they are indeed inventory records and they should be retained even if they are marked as deleted, or also known as "soft" deleted. The record is still present in the database, but no longer an active asset in the production environment.
So, on first thought that should actually be no problem. The CI is there for me to look at historical changes that include its time of order, deployment and removal (deletion) from production. No issues there. The problem is with the relationships that were hosted on that computer.
Let me explain why.
A typical CI is not a standalone record, it is related to other CIs and these relationships have attributes. For example we have cardinality, where the CI relationship can be defined as one to many, many to one and many to many. Then there is Weak type relationship where the CI on the "left" side of the relationship has to exist before the "right" side can be detected by some means of electronic discovery. This means that without the CI on the left, usually a ComputerSystem CI, none of the hosted components on the right would exist. There may be a license cost related to the operating system that's running on that computer, but no discovery tool could scan it if the computer is not deployed and turned on. Additionally there is a Cascade Delete option which is not enabled out of the box but can be toggled to be enabled for Hosted System Component relationships.
So, back to "Mark As Deleted = Yes", which I am going to refer to as MAD.Y and MAD.N for Yes and No. What is not immediately obvious is that there is workflow that will act on changes done to MAD. All relationships are removed from a CI when the MAD.Y is set. If you have the Cascade Delete on, then MAD.Y will also propagate that MAD.Y flag to the Hosted System Component CIs. This means that the computer system will be set for deletion on the next Purge activity as well as the Operating System that was hosted on it. This means that if you're tracking the license of that Operating System then that record would now be gone.
This can be a problem for customers that like to retrace the license management back to the Computer System on where it was hosted. Generally end user's Operating System would not be a big deal, but Oracle license or Server license that can easily exceed $10,000. Losing track of that CI could present issues when Audits are conducted. So, keeping the ComputerSystem and the hosted Product CIs now becomes an inventory issue. What do we do with these records? Once they are MAD.Y their relationship is fragmented and not backward traceable without some effort. Certainly not via automation. However this is exactly what ends up happening when Purge activity is not performed on that data in BMC.ASSET. Eventually it will require some clean up. And that is bad because nobody is very happy when they have to do it.
We'll have cases that arrive in our incident management tracking system where customer may complain about performance, or errors seen in reconciliation logs related to Multiple Matches found. Many of these issues result from data retention policy where the customer does not allow Purge of the MAD.Y records from BMC.ASSET for the reasons I've outlined above. However, it does not have be that way.
As of now, most Reconciliation jobs use this sequence:
Purge (or Delete) BMC.ADDM and BMC.ASSET (Identified Only)
Although this sequence makes the most sense, it includes the not so popular Purge of the MAD.Y records from BMC.ASSET. The truth is that if you want your data to be healthy then it needs to include the Purge. However, not all is lost. There is a better sequence that allows record retention.
Copy Dataset (with a qualificatn of "MarkAsDeleted = Yes" AND (ClassId = "BMC_Product" or class id of interest))
Purge (or Delete) BMC.ADDM and BMC.ASSET (Identified only)
In this scenario you can use a qualification to first copy all CIs you're interested in where the MAD.Y is set and ClassId = 'BMC_COMPUTERSYSTEM AND ClassId = 'BMC_PRODUCT' or your asset class of interest.
Please see Jared Jones' PULSE blog on License Management:
Where covers new feature specific to Asset Management License Management :
" SP1 includes the expanded capabilities. If you get it installed you will see quite a few additional License Types out of the box. Essentially all the previous License Types now have an additional "_All" type that includes the other software classes."
Your copied dataset can then hold the name like BMC.ASSETS.PURGED where you can return to at any given time and run reports on.
It would only hold records that were at one point Marked As Deleted in the BMC.ASSET dataset and purged. Keep in mind that the "License Management" will be updated accordingly as configured in the Licensing Job related to the reconcilation job that handles the ADDM data.
That said, it just means that this is not yet fully automated out of the box or even considered as Best Practice because CMDB is not intended for asses inventory retention, but within the parameters of capabilities of the AtriumCore and not all that complex to add as a functionality enhancement.
In conclusion, is inventory retention in BMC.ASSET dataset good or bad? Well, it's definitely not in the design of the CMDB which is supposed to keep records of Configured items in production environments and it can cause data clean up issues. So, my vote tends to lean in the direction of "bad". You can do better with this "age old" problem.
I hope this helps, please rate my blog below or add comments on your experiences. See more like this at BMC Remedy Support Blogs.