Convert cmdb_ci_service to cmdb_ci_service_discovered?

[phsdm]

Before we enabled Service Mapping, we imported and manually created about 800 service definitions.   We imported them to the Business Service [cmdb_ci_service] table.   Much of the data entered are non-discovered information such as managers, owners, DR SLAs, etc.

We also manually created service-service and service-CI (server, etc.) relationships.

Now that we have Service Mapping, we want to "merge" that manual information with entries in the Business Service (discovered) [cmdb_ci_service_discovered] table.

Options I can see are:

1. Relate
   
   The lazy approach would be to relate the existing Business Service to a new Business Service (discovered.)   This simplifies setup but causes users a lifetime of pain.   The Configuration > Business Services list gets cluttered.   You have to flip back and forth between "Dependency views" and  

1. Reclassify
   I tried changing the Class [sys_class_name].   It sort of worked, but the behavior of the Business Service (discovered) "View Map" page seemed a little off.
2. Export/Import
   I could export the information and re-import it.   But that will lose the relationships.   Keeping them seems like a lot of scripting or hacking (global replacement of sys_ids and custom imports of relationships.)

I was looking at the Service Map Planner, hoping it had something for this.   But its Planned Business Service [sa_dw_planned_business_service] table does not extend Business Service, and only relates to Business Service (discovered.)

How would you approach this?   I really want to Reclassify, but I've been burned by the Law of Unintended Consequences in the past.

[pranavparmar]

Hi Peter,

Did you get answer to this? I think this is very crucial when you enable Service Mapping. Is there an easy way to transform existing business services and convert them as manual or automated in Service Mapping?

[phsdm]

Hi Pranav,

Thanks for asking.   I opened a HI ticket.   I found out that it is possible to go the route of reclassifying the existing business service CIs.   However, after reclassifying you have to open a ticket with ServiceNow to do something behind the scenes.   The action is only available to ServiceNow personnel (requires the maint role.)

I stepped back to think how important it is to drag the existing fields and relationships over, and decided that the effort to clean up after reclassifying is about the same as the effort to compare the relationships manually.

I am building a custom app that extends the Service Map Planner to facilitate:

1. Review of legacy service CIs against discovered service CIs
2. Transfer of non-discovered fields
3. Service mapping task, story, and report creation with relationshisp to phases, planned tasks, and planned entry points.

In our case, this will work better than reclassifying and cleaning up (GIGO.)   Also, we expect to move to "green field" mapping pretty soon.   At that point we won't have legacy service CIs to deal with.

I'll attach some draft materials.   Note that I am implementing, so the documents are no longer up to date.   They were an interesting start, though.

[phsdm]

Here are some ideas for extensions to the Service Map Planner to facilitate review and transfer of legacy business service CI information to discovered CIs, using the Service Map Planner to manage workflow.   In our organization, the service mapping pipeline involves two teams.   The BSM team handles the upstream portion, and service mappers handle the downstream portion.

When legacy business service CIs are involved, the BSM team also handles review of the legacy service against the discovered business.   We plan for this review to happen after the map is approved and business CI is created.   See Proposed Process for use with the Service Map Planner.pdf (attached) for details.

Here are the original models for Service Map Planner extensions.   They have changed a lot, but I hate updating designs once I have working code...

In the image above, the CNP prefix on a table label implies inheritance from the corresponding Service Map Planner table.

I am reconsidering the extension of task tables.   I believe a lot of our customization matches specific table names instead of using INSTANCEOF.   I might trade the flexibility of table extension (separate forms, etc.) for creation of records in existing classes.