CSDM 4.0: (any) Status attribute vs. Life cycle

[David Skowronek]

The new CSDM 4.0 comes with several changes, and one of them is introduction of a new Lifecycle attributes. The following video by Scott Lemm and Mark Bodman provides nice insight into this topic and future product strategy.

What I would like to share in this article is personal insight into this topic, based on testing of the functionality and its limitations. There are few points I would to highlight:

• There is no hurry to migrate to the new functionality, unless you would like to utilize the new CMDB Data Manager
• You should start looking into this topic soon as the migration may require some time, planning and testing
• With highest probability you will not get rid of the current (various) status fields, they will co-exist and co-operate with the new Lifecycle

Why the current status fields will be still used?

• The Lifecycle values CANNOT be customized, in the future ServiceNow products will start to utilize them and any customization may break the logic / functionality
• Some of the current products have hard dependency to the current status fields:
• • Service Owner Workspace requires Phase [portfolio_status] and Status [service_status]
  • Application Services are dependent on Operational status [operational_status], as well as ITOM (especially Event management and Service Mapping)
• And I should not forgett the history - there are many customers live for a long time, with plenty of workflows, integrations, imports etc. where full migration to fixed list of baseline values and one unified atrribute would be extremely complicated

So how to ensure that you may get advantage of the new Lifecycle attributes without major effort? Answer is the Life cycle mapping. This feature is essential part of the overall Lifecycle functionality and enables bi-directional mapping of the current status fields to Lifecycle and back. Eventhough it sounds like a perfect solution, it has its limitations:

• Lifecycle mapping works with a single status attribute to Lifecycle and back

You may map Status [install_status] to Lifecycle and backup, but you CANNOT map combination of Status [install_status] and Operational status [operational_status] to Lifecycle. For that reason scenario where you have Status = Installed and you are using Operational status to further specify whether the CI is operational or not CANNOT be mapped to Life cycle.

• status attribute value to Lifecycle mapping is NOT 1:1

In order to achive perfect bi-directional mapping all mappings should be unique, 1:1. Unfortunately, this is not the situation and for some Lifecycle values there are several target status values. Example is Lifecycle "Ideation - Under Evaluation" that is mapped to 4 current Status [service_status] values. This is known limitations and the video I mentioned in the beginning states the same for Hardware status field.

How to get over those limitations? Solution is to make sure that every CI Class has exactly 1 status attribute that is editable, and all others are synchronized when needed, and especially read-only. The following picture shows usage of various status fields per CI type:

Green field "Primary" indicates attribute that is visible on the form and editable (based on ACLs etc.). This is the ONLY attribute that is used to set the status. Lifecycle mapping contains ACTIVE definitions only for this one primary attribute.

Yellow field "Synchronized from Status" indicates attribute that is not visible on the form and read-only but needs to be in line with primary attribute. Example can be hard dependency from ITOM. It may require Business Rule to implement this mapping.

This picture is one possible combination, you may decide to use Operational status instead of Status for e.g. Infrastructure CIs / Applications. Important is to understand what are the hard dependencies.

Solution presented in here:

• Ensures consistency of status values across multiple status attributes and Lifecycle, with fully predictable behavior
• Enables usage of the Lifecycle and CMDB Data Manager
• Does not break any hard dependency of the current ServiceNow products

There can be more solutions of the same problem, I am sure that solution I have presented now may not be the only one. Take as an input into your planning of migration towards the CSDM 4.0 and Lifecycles.

Want to know more? Check my next article CSDM 4.0 Life Cycle: How to implement it?.

[Kev12]

Superb article - helps clarify things a lot - Thanks.

There is an area that I havent clarified in my own mind yet - maybe someone can help.

I have been playing with this in a dev Rome instance - mainly around business application and application services.

There are now 3 fields, status, lifecycle stage, lifecycle stage status that together are used to be very granular about where in a lifecycle process the record is.

Good so far...what I find is that it makes sense that the status is amended and the other two fields get their choices set accordingly.

At this stage, in my testing it seems that users could choose one or other choices - it is not prescriptive - set by workflow etc...

Hence my question :

Where multiple options are presented in the lifecycle stage and lifecycle stage status, are they going to be the subject of prescriptive workflows OOTB provided by ServiceNow? Or - should we be providing workflows, based on individual client needs for pre-setting these sub options for lifecycles ?

Regards . Kev.

[David Skowronek]

Thanks for your comment.

You are right that the current status fields are not prescriptive. There are just few products with hard dependency - like that Operational status must be used for Application Services, or Phase and Status for Service Owner Workspace. But other products - ITSM etc. - are not having any preference. It is a customer choice how the CMDB is managed and by what attribute.

In the future baseline products will use only Lifecycle attributes, not the current ones. But this is a long journey still. And as products will depend on those values, they cannot be customized.

My article described a way how you can still use the current status fields with custom choices (if required) together with a new strategy for products (Lifecycle). And by keeping only 1 attribute per class as editable and other synchronized prevents issues with wrong value across multiple different status fields.

[CMDB Whisperer]

Really great article and I pretty much concur with all of your observations.  A couple of subtle points I would like to add:

From what I have seen you can define your own Lifecycle Stage/Status values in addition to the ones defined, and you can also define custom mappings to custom values in the various status fields.  However, it is another question whether you should. IMO the value in this is conforming to a standard set of Lifecycle Stages and Statuses, so trying to define your own is pointless

As you point out, the various status fields are not standardized, continue to be leveraged by business logic across multiple versions of the platform.  My understanding is that ServiceNow has acknowledged this is the case and does have plans to eventually migrate this logic.  At that point, in theory, people will be able to completely migrate to the Lifecycle Stages.

In the meantime, once you have opted in and mapped your status fields to Lifecycle Stage/Status, what you can do is to start incorporating future compatibility into your configuration.  What does that mean?  If you are a customer, then you can start to convert your own business rules, reports, and other elements of the platform that rely on the various status fields.  That way you cut off all direct dependencies on these fields and minimize the chance of unexpected impact down the road.  And if you are a partner developing applications or professional services, you can look at incorporating support now in both scenarios, with or without the use of Lifecycle Stage/Status.  And you should!

It's important to note that if you add these fields to your forms, ServiceNow will appear to let you change them, but since they are mapped in one direction only, it is not supported.  So if you add them you should consider UI Actions or Client Scripts that prevent users from attempting to set them.  

Last point I wanted to add is that the current CI/asset status field mappings do not actually include one of the Lifeycles, Pending Retirement.  If you look at most or all of the other Stages, you will find that there are mappings for everything but this stage.  Which highlights a process gap in the baseline configuration of ServiceNow: how do you represent a CI that is no longer in use but is not yet retired because it is still in the process of being Decommissioned (monitoring turned off, data wiped, disconnected, etc.)  While you can control that part of the lifecycle using Request and/or Change workflow, you cannot represent it using any unique combination of the status fields provided.  While Installed and Non-Operational might be the right values of status/operational_status respectively, they are not determinative, as this combination may also represent a CI that is experiencing an outage.  Thus, it cannot be mapped.  So if you're looking to develop something based on the Pending Retirement Lifecycle Stage, you're out of luck unless you're willing to customize the values of one or more of the CI status fields to accommodate this.

Finally I'm glad to see there are others who seem to have landed on the same conclusion: that while the OOB business rules for asset/CI synchronization do suggest customers should standardize on the use of hardware_status/substatus for Hardware CIs, I typically find that this is seldom if ever advisable, and that install_status is preferred, even if that means having to make slight modifications to the Asset/CI synchronization to support bi-directional synchronization.

[Moritz4]

Thanks a lot for these insights, David.

They are very helpful to get started with the migration to the CSDM Lifecycle. In your article, you already clarify on possible solutions for the existing limitations. Great!

Best regards
Moritz

[Ahmed Drar]

Great article. Thank you very much for the insights.

[Sufian Abu]

David,

One of the best answers adding ground-level details on this topic!! We are planning to perform a small POC to learn from the guidance that you have provided. I will let you know if we face challenges.

Paul - Your reply also adds very valuable context. More to come...

Regards,

Sufian

[laronjenkins]

All, this has been extremely helpful. Thank you David for the video link and your insights, as well as all the other contributors commenting on this topic.

The one aspect I am not understanding is the "bi-directional" functionality of the lifecycle mappings. My understanding is the mappings only work in one-direction. Example: If I update a given hardware asset's State and Substate field from In Stock - Available to In Use - (no Substate), the Lifecycle Stage and Status fields automatically update to thier pre-determined mapped value(s).

But I can't put that asset back "into Stock" by simply changing the Lifecycle Stage and Status fields, correct? I've tried this and nothing happens, I have to update the legacy Hardware Asset State and Substate field(s) to put said asset back "into Stock".

Please let me know if I am missing something obvious or misunderstanding the way the "bi-directional" functionality should work for lifecycle mappings.

Thanks.

O+(-> LKJ

The Consultant Formerly Known As La Ron

[David Skowronek]

Thank you, I am glad that my article was helpful for you. The bi-directional implementation is mentioned in the referenced video, time 18:30. I have personally not used it so far but it is a must for the current customers. One of the policies in the CMDB Data Manager is to retire CIs. CMDB Data Manager works with Life Cycle only, therefore update of the "legacy" status field is required to keep the data consistency. As per the video, this should be available in Rome release. But check also San Diego, if it was not posponed.

[gjz]

Thank you David - this article was extremely helpful for us to understand how to convert from install status to Life Cycle state and stage.

However, since the Life Cycle fields are not customizable, we are unable to complete the conversion due to one substate field we have that is necessary.  When laptops/desktops are returned to stock, we keep them for a week in case someone needs data off the device.  We use a custom substatus field along with the status field of In Stock in order to know which assets are being held.  How would the combination of In Stock - 5 Day Hold map to the Life Cycle fields?  We don't see anything that works for us.

[CMDB Whisperer]

My suggestion would be to use the Pending Retirement state for this and then to implement policies and business rules to govern the transitions into and out of this state.

[gjz]

CMDB Whisperer - that won't work for us since it will confuse the assets that are pending retirement vs ones that will be available for use after a week.  Plus, it will put them in the Pending Retirement workflow when they aren't supposed to be there.

[David Skowronek]

@gjz I am happy that you like my article. My proposal would be actually the same as from @CMDB Whisperer . That is the closest one. However, if this is a no-go option, you may need to go with e.g. a custom attribute to store the additional information, when the asset is really available.

[Saurav]

Hi @David Skowronek , @CMDB Whisperer 

On the Business Application (cmdb_ci_business_app) Table we are trying to make the install_status and install_type field mandatory we have not yet enabled Service Mapping and starting the journey towards CSDM .. would you suggest if we have it mandatory there would be any challenges when we implement Service Mapping or move towards CSDM.

Thanks !!!

[CMDB Whisperer]

No, I don't think it's going to present any challenges per se, but I do wonder why you need to make it mandatory.  There shouldn't be an option to have a null install_status field.  If there is you should probably change the choice type to it doesn't allow an empty value.  Aside from that I would say in general it's best not to make fields mandatory in the CMDB.  It may be less of a concern on the Business App class, if you're not importing those from another tool.  But still, UI policies are a bit nicer way to make things mandatory if you have to/choose to.

[Ben Schlick]

Hardware Life Cycle Process Alignment

The lifelong argument of asset vs. ci can be elevated to the Service level. It is at the Service Portfolio that these technical and strategic requirements are aligned with ServiceNow functionality. The Service Portfolio manager is overall accountable to define these, although they will usually require extensive guidance from each of the ServiceNow disciplines to ensure the correct alignment to Service(ITSM&CMDB)/Service Offering(ITSM&CMDB)/Category(ITSM&CMDB)/ Subcategory(ITSM&CMDB)/ Model Category(Source-to-pay&ITAM&CMDB)/ Model ID/ Managed By Group / Support Group / etc. are created for the onboarding Assets and CIs.

The discussion "when should we make an asset or ci" can be consolidated into one flow for the entire organization. The below image represents the Hardware Life Cycle Process for the CSDM 4.0

Blue check marks designate when a record is in its CI dominate stage. This means that updates from the designated discovery tool take priority on *any updated status field.

Red check marks designate when a record is in its Asset dominate stage. Often times these are manual processes complete by various teams across the enterprise. Reports from the asset will always be retrospective until integrations with inventory/warehouse management tools are available and configured. 

Purple check marks designate when a record is in its Procurement dominate phase. When a new/additional service is being added, new devices are often required to support it. Procurement processes the evaluation criteria and extends proposals to multiple Vendors. Vendors present a solution with one or more device types that correspond to model categories and ci classes.

Pink check marks designate when a record is in its Supplier management lifecycle phase. After procurement has selected a vendor and proposed solution, the organization either uses an internal partner to purchase from or outsources to a supplier.

What does this have to do with records and their Life Cycle Control? Great question. Although the legacy Status and Operational Status were "left up to the organization to maintain the design" and pick one, it was the misunderstanding that at least two were required for this data model to work. Meaning organization would have to configure the legacy "Status" and "Operational Status" like ServiceNow is doing with Life Cycle Control(essentially the same thing when we create the life_cycle_mappings).

Let me put it to you this way - Just like how Discovery requires that Integrations and/or subnet scans adequately update the CI Status when it is on the "Network"; Procurement, Supplier, and Asset tools should adequately update the status of "Assets" as they move through the beginning stages of their life cycle. Once they hit the network, Discovery architecture will take over. Once they leave the network, Asset tools take precedence. 

My organization needs a new video teleconferencing solution. The current laptop for each conference room creates unique challenges that we would like to provide a wholistic solution to. My organization requires that there be minimal devices with the added capability of sound quality, video communication and focus on the person talking, ease of use.

Laptops often fall under a different support structure than video communication equipment, therefor the new solution would need to be communicated with the incumbent stakeholder who will be supporting it if it changes. Multiple vendors show up the next day, ready to present their solution and devices that support it. During the selection process, a new vendor and solution was designated for implementation. This solution consisted of a centralized device that sat on the conference room table with 360 cameras focused on the entire room with microphones attached. When a person in the conference room was speaking, the camera would enlarge their picture to show who was talking to everyone connected virtually. This solution implements different technology and network architecture requirements than the previous solution and requires a defined Service, for this example we would categorize this under Infrastructure->Network->Video/Phone Communication responsibilities vs. End-User->Workstation. This team, Video/Phone Communication would be the technical service supporting this solution and be designated as the Managed By Group. Once a list of device types are approved, supplier management takes over. An internal or external supplier is selected, with designated sla's for device availability etc. Usually procurement has a finance component that is then reimbursed once the Asset has been purchased, sent to the warehouse, then put onto the network and into operation. When the device is on the network, it can be reached by the defined Discovery tool which updates the record for its entire time on the network. Once the device is in operation does the organization submit a list to Accounting and accounts payable to reconcile source-to-pay operations. When the device is submitted for retirement, or the next stage in its life cycle, that process (likely ITAM, will take over and update the record).

ezpz

[Carsten Schnor1]

Dear community,

has anybody an explanation, why the life_cycle_control Table has no operational mapping for cmdb_ci_service?

I struggle to define correct mappings for install_status "installed" for application services, Of cause I might connect the instal_status to BA mappings but in terms of "Operations" the App Service should inherit its operational status from an owning service offering. Or what am I missing?

Best,

Carsten

[SN_Marcel Horn]

Hello @David Skowronek, @CMDB Whisperer,

could you please check the enclosed overview below?

It this still up-to-date or is there an updated overview available somewhere?
Its crucial for us to work with the relevant Life Cycle fields at the correct record level.

Best
Marcel

[CMDB Whisperer]

Not sure if all of that is correct.  I am not aware of synchronization of operational status and install status.  That said, the Hardware Status and Substatus fields should never, ever be used.  Anywhere.  Period.