Moving into Service Builder - Life Cycle Stages - dealing with legacy orphan records

[jstoessel]

Hello,

Unfortunately, our IT org has been creating "Business Service" class records for years as a way to route incidents.

At the same time, Service offerings have been hit and miss as related to Catalog Items.

These two situations are what I am trying to work around without tipping anything over.  There are over 3,500 records in the cmdb_ci_service table, and 90%+ of them are in an operational status of "operational" and install status of "installed".

I would consider myself to have a very good handle on the CSDM and have been working on removing these legacy records that are not having any traffic, and am ready to start working on the implementation of DPM/Service Builder with Service Owners.

My Question:

When I want to change relate the records (service & offering) and move them into the correct lifecycle, I have not been able to find the correct order.  I can't make the change to the service - I receive the error about a service must have an offering to move into the new lifecycle status.

When I attempt to change the offering record's lifecycle status - I receive the error about the lack of relationship to a service.

Has anyone figured out the correct order of relating services & offerings and updating the lifecycle status?

My gut is telling me that the Class & Service Classification on these legacy records could be playing a part in making what seems like a straight forward activity not be so straight forward.

[Mathew Hillyard · Accepted solution]

Hi @jstoessel,

Service Offerings have a mandatory parent field in the baseline which must be a Business or Technical Service. This is why you cannot move a Service Offering into operational use without a parent Service. Your message suggests that this baseline functionality has been customized. When you set a parent Service, the Service classification on the Service Offering should be changed to match - Service Offerings are on one table, so the Service classification is inherited from the parent (Business or Technical Service) to set the Service Offering as a Business Service Offering or Technical Service Offering.

Similarly, a Service cannot be in operational use without at least one Service Offering (on a related list). This is because Service Offerings are what consumers consume - the Service is just an umbrella for its Offerings.

Regarding Life cycles, I assume you have activated life cycles from the CSDM > Life Cycle Mapping module. If not, then the status and life cycle stage/statuses will not be sync'ed (but you must define a Life Cycle Stage and Status for any custom state values or they will not sync when life cycles are activated).

If you have activated life cycle mappings, then you should be able to see 12 Life Cycle Mapping records for Business Service and Technical Service. These are a combination of Configuration Item and Service legacy fields. These records do not contain any values to show the order of these life cycles, but looking at the Business Service records it looks like this for the Life Cycle Control:

• Service - Ideation - Under Evaluation
• Service - Design - Chartered
• Service - Design - Design
• Service - Design - Build
• Service - Design - Test
• Configuration Item - Operational - In Use
• Configuration Item - Operational - Pending Retirement
• Service - End of Life - Retired
• Service - End of Life - Obsolete

Operational status and Install status are separate fields and to my knowledge are not sync'ed automatically, however there are life cycle mappings for both on the Configuration item table. For Services, the fields that are relevant are Phase and Status (part of Service Portfolio).

Hope this helps!

[jstoessel]

Very helpful - The challenge of trying to RUN/FLY before finishing CRAWL/WALK

Appreciate the redirect to the root cause - Life Cycle Mapping has not been completed