Hardware status and Substatus OR Install status on CI-classes with Hardware devices

[Ed Laar]

Hi,

I am facing a possible issue in the use of Hardware status and Substatus versus Install status. Following the documentation Hardware status and Substatus should be used on CI-classes that contain hardware CI's while Install status should be used in classes containing non-hardware CI's. So far perfectly fine.

But: On several CI-classes this is OOB not the case.

Example: On cmdb_ci_display_hardware, Hardware status and Substatus are not available, even so on cmdb_ci_ip_phone.

What is the best way to do in these cases? Add Hardware status and Substatus (but they will be added as customized fields) or leave it as-is (but this is causing confusions)

Any suggestions? What do you do in such cases?

Grtz,

Ed

[CMDB Whisperer]

Per the CSDM 5 document, unfortunately I would have to say that it is very much NOT ready for prime time.  Every indication seems to be that ServiceNow is still figuring out a path for customers to migrate to CSDM Life Cycle -- or they are leaving it to customers to figure out their own path.  The Washington release passed my synchronization tests, so although I was a bit cautious still because ultimately I wasn't convinced that the chained business rule  logic approach to synchronization would ever be a workable approach (and still am not), I reluctantly started giving the tentative thumbs-up for adoption.  But lo and behold, the very next release ServiceNow decides it wasn't going to be a workable approach (ahem!) and decided to discontinue the syncronization in favor of a new Product Instance 2.0 which expands the use of CSDM Life Cycle to include CSM, while discontinuing all support for Life Cycle Mapping synchronization!  There are not enough details available about this solution for me to confidently say when CSDM Life Cycle will get a thumbs up from me.  I still have more research and testing to do.  Unfortunately, PI2.0 is a one way street so I'll need to do this testing on a temporary instance I can throw away afterwards, maybe a PDI if installation is available there.  I haven't yet had the time for this but hope to be going down this path soon and will share my findings if possible.

[JasonS274316555]

Hi @CMDB Whisperer , you've written a lot on this subject and generally seem to advise against migrating to Life Cycle, so I'm wondering your opinion - have you had any experience with the CSDM > Life Cycle Mapping module? It seems pretty intuitive and comprehensive at face value, wondering if there are any pitfalls that would cause you to advise against it.

You mentioned in a separate comment that life cycle sync is no longer supported post X, is that in regards to this module? 

[CMDB Whisperer]

In a nutshell, but in no particular order:

1. Not all of the mappings are possible.  There are limitations to what mappings work for different classes based on how the Life Cycle Objects are created (and these cannot be customized).  And from my experience how this looks on a given instance can vary greatly based on the history of that instance, even if the fields have not been customized.
2. Whether a life cycle mapping works as expected can depend on several factors, including how you have configured the synchronization, whether there is a CI and Asset pair, whether you have applied the workaround I mention in this article to use install status instead of hardware status, and what was the source record and attribute that was first updated.
3. ServiceNow themselves have indicated repeatedly that you should not rush to adopt this, although the messaging has been confusing and inconsistent.  In the CSDM 5 whitepaper they basically acknowledge that this was not ready for adoption, and they have pulled back the initial version they released, and while they have talked about "Product Instance 2.0" as a solution, they have still not recommended people move forward with it yet.  PI 2.0 is really just the next phase of the synchronization with a new name.  And anecdotally I have heard from other customers that ServiceNow has stated that there is "something else" coming.
4. While the tests I had previously run in Washington seemed to be promising relative to Vancouver and earlier releases, I have not personally repeated these tests since Washington so I cannot give any reliable assessment on how well bi-directional synchronization occurs in the current state, and am making my assessments now based on the overall churn of what is happening with this feature.
5. The legacy fields, to my knowledge, are all still supported (even though the CSDM course makes the premature claim that they are deprecated).  From a product standpoint I have not seen anything definitive to say that products have been updated to use life cycle instead of legacy fields.  It has always been my understanding that this is the ultimate indication that the feature is truly production ready.  I'm not even sure if it they have started down this road or how far they have gone.
6. No one has acknowledged yet the user experience issue that this presents.  With the legacy fields you could edit the state and substate fields together in a list view because the dependent field attribute allows two fields to be edited in a single cell (and even on multiple rows).  However, since life cycle stage / status are references, these do not support the dependent field attribute in the same manner.  Thus there is no way in a single transaction to modify both the stage and status together from a list view, not even on a single record, let alone multiple records, unless you set the behavior of the list to update the record for the whole row.  It would be good to see this acknowledged and a user interface solution provided, but I'm not holding my breath.

The life cycle feature is something I still support in principle.  It was introduced to solve a real problem, that the status fields in various objects were confusing and didn't always synchronize correctly.  Unfortunately in the current state of how this was implemented, the net result is that it has in my opinion made the problem worse.  We need to keep actively looking at the issues that this presents.  Hopefully we get to see some real stability and usability in this feature before ServiceNow puts more burden on the backs of customers to migrate or adopt.

[s4scott]

Currently, to successfully use the CMDB with other modules (SPM for example), both the legacy state/status fields and CSDM Life Cycles must be respected. Ignore one or the other at your own peril. This is slowly improving, but Life Cycles have not been universally adopted as of Yokohama. Going to start testing with Zurich this month.

[CMDB Whisperer]

Hardware Status and Substatus in reality should be deprecated, but they are not.  They are an artifact from a pre-Aspen time when asset management functionality was overloaded onto the CMDB tables.  Unfortunately, today there is still a default rule that causes the Hardware Status and Substatus fields to be considered the de facto standard fields for CI status, if the CI is a Hardware CI.  As a result your install status will not be in sync.  Bottom line is that there has long been a disconnect between the different fields, and as a result the fields don't stay in sync, and bad decisions can be made based on conflicting reports around whether an asset is actively in use or whether it has been retired!  Along came CSDM Life Cycle which seems to have been designed to fix the problem but in reality (thus far) it has only made the problem more complex.  The best I can tell you, in short, is the following:

1) Don't use Hardware Status at all, ever, anywhere.  Kill it.  Bury it.  Deactivate the fields in the dictionary so no one can even add them to the forms.  This won't cause data loss, and you can still query those fields as needed.

2) Make sure you do some data audits and configuration audits to figure out the true status of your CIs and assets in question.  They are probably broken.  Create a pivot report showing your CI statuses and their respective asset states and you will see what I mean.  There are bound to be some stark contradictions.

2) Modify (yes modify) the script that synchronizes status between Assets and CIs so that it only uses Install Status, regardless of whether or not it is a Hardware CI.  For the skeptical out there, ServiceNow has published a knowledge article prescribing this to resolve synchronization issues, even though they don't acknowledge it as a bug.

3) Adopt CSDM Life Cycle Management in a limited fashion, only supporting one-directional synchronization from the legacy fields to the CSDM fields.  Do not allow users to directly set the CSDM Life Cycle stage/status on Assets or CIs.  It will break stuff and make your synchronization problems worse.  But do consider allowing your CSDM Life Cycle stages to be synchronized from your legacy fields, and consider creating status-based reports or business rules based upon the CSDM Lifecycle once you confirm that the synchronization is working properly.  (UPDATE: life cycle synchronization is not supported after Xanadu, so this recommendation is no longer valid.)