Crawl Phase - Migrating From CMDB_CI_APPL to Business Applications + App Service - Help!

[dwilcher]

Hello,

We're an older customer (deployed in 2014), and like many customers from that era we used CMDB_CI_APPL as our primary inventory of Business Applications.

We are midway through our migration to the CRAWL phase of CSDM. Some background:

• We are currently using SN Discovery to populate our core infrastructure
• We are working on migrating from CMDB_CI_APPL to a combination of Business Applications and Application Services.
• We do not have Service Mapping deployed.
• Our staff do not current relate infrastructure CIs to their CMDB_CI_APPL records.

We have some confusion on Application Services, and would like a sanity check as we are finding the CSDM whitepapers and SN Docs sites to be unhelpful on this point. I've given a bit of background, and have our questions in the questions section below.

Background

We have done the work to create all our Business Applications in CMDB_CI_BUSINESS_APP. We are now working on creating our Applications Services to represent our PROD, TEST, DEV, etc. environments.

From the CSDM 3.0 whitepaper we understand the concept that the Application Service is now our operational CI for each logical environment/instantiation of a Business Application. We are following both the CSDM 3.0 whitepaper and the SN Docs page to use "CSDM > Manage Technical Services > Application Service" to create our Application Services.

From this we can observe two things that can occur:

1. I can create the Application Service, relate my Application Service to my Business Application, skip "2. Populate the Application Service" as it is not required, and see that my Application Service is created. I also see that I can find the Application Service record on the CMDB_CI_SERVICE_AUTO table.
   
   
2. I can create the Application Service, relate my Application Service to my Business Application, and on "2. Populate the Application Service" if I choose "Manual" I am required to select a specific CI from the CMDB
   
   
   If I specify a Class and pick a specific CI, I can then see that my Application Service is created. I also see that I can find the Application Service record on the CMDB_CI_SERVICE_DISCOVERED and the CMDB_CI_SERVICE_AUTO tables.

Both 1 and 2 above are consistent with my understanding of the CSDM Whitepaper that says a Service starts in CMDB_CI_SERVICE_AUTO table, and is then switched to the descendent child table based on the population method. If Manual is chosen as my populate method, then my Application Service should be moved to CMDB_CI_SERVICE_DISCOVERED.

So that brings me to the part that we're exceedingly confused on:

Questions

Our initial approach was to create our Application Services as CSDM tells us we MUST have them for Operational processes (Incident, Problem, Change). Initially we skipped specifying a "Population Method" as we were not going to populate them yet (so #1 noted above). We just wanted Application Services so that, at the early stages of Crawl phase, we could link Incidents to Application Services representing our environments. This is where it feels like things start to get messy.

We have several attributes we will need to have editable on our Application Service form for our application support teams to manage various operational processes. These include things like disaster recovery information, application environment support info, application access administration information for the environment, etc. I realize eventually these could live on Offering records, but we don't have those at CRAWL phase of CSDM. However, this view given with CSDM is not customizable to add additional fields/attributes:



So here are my questions:

1. Would having all our Application Services in CMDB_CI_SERVICE_AUTO and not having a population method set cause any problems when using the Application Service in other modules like Incident, Problem, Change, Event Mgmt, etc.?
   
   
2. If we need our Application Support teams to manage/maintain attributes of an Application Service, particularly our custom Attributes, should they be doing that from CMDB_CI_SERVICE_AUTO or CMDB_CI_SERVICE_DISCOVERED? When I impersonate a user with just ITIL roles in my PDI, they can edit fields in the default form view on CMDB_CI_SERVICE_AUTO but all fields are locked to them on CMDB_CI_SERVICE_DISCOVERED. So it feels like we should be doing it from CMDB_CI_SERVICE_AUTO, but that seems to conflict with the fact that when you populate a service it moves to CMDB_CI_SERVICE_DISCOVERED where the form view is NOT editable by ITIL user.
   
   
3. If we are manually populating our Application Service, and we set the Population Method to "Manual" (so that we can get the Application Service to the CMDB_CI_SERVICE_DISCOVERED table) why do we have to specify a specific CI *on creation* when we select Manual method? Why can't we do that later? It seems like this assumes I will have infrastructure created BEFORE I have my Application Service created. But that's not the case in our environment. When requesting infrastructure our teams must specify the application environment (Application Service) it's for.
   
   
4. It's entirely unclear to me what specific CI class and CI we would pick in Population method" of Manual for cloud applications with no infrastructure CIs. (ex: a vendor hosted website).

Looking for any guidance here. I feel like we're with CSDM right up until this Application Service piece, and now it just feels like there's legacy ITOM/Service Mapping stuff (a manually populated service is in a table called CMDB_CI_SERVICE_DISCOVERED....huh?! lol) that is complicating all of this more than it needs to be for us at the Crawl stage.

[Barry Kant · Accepted solution]

Good day,

some responses below:

1 - No this will not give a problem. With a note that it is depending on if you like to limit the configuration item field in these processes to a specific class or not. So better is to limit it by the table and not by the class. 

2 - I would do that from the CMDB_CI_SERVICE_AUTO table as that includes the extended tables as well. Alternatively you can consider to create a catalog item where the IT Application Owner can modify the Application Services that (s)he owns him/herself. This way you can control what attributes can be changed, and the change can be done via a workflow. A good controlled mechanism, and maybe if required you can put an approval mechanism in place. This is of course if you don't need bulk changes.

3 - I think you can do this later as the population method is not required you can do this at a later moment.

4 - Is there any downstream record in this situation (endpoint maybe)? If not than I would say it will be related to a technical service offering for a support chain, and no population method is needed. 

Cheers,

Barry

[CasperJT]

Hi,

I agree with Barry. I would add that you of course do not have all the attributes from the child tables available on the parent table, so if any of the fields you require are added on the cmdb_ci_service_discovered table then you will not be able to edit them, when the record is placed in the cmdb_ci_service_auto table.

I like the idea of have a catalog item for maintaining values on the application service. The alternative is to grant the owners the 'app_service_admin' role, which will allow them to edit records in the Mapped Application Service table.

The name cmdb_ci_service_discovered is a legacy. However the intent now, as I see it, is to use the Mapped Application Service to show that you actually have an understanding of it's infrastructure CI's, be it hardware, applications or an endpoint.

All the best,

Casper

[dwilcher]

Hi Barry,

First, thank you SO MUCH for taking the time to respond. I was hoping against hope that someone from ServiceNow might get back to me here. 🙂

Just a couple quick follow ups!

Re: the Service table hierarchy:

From this my understanding of the Table structure is:

• CMDB_CI_SERVICE (Labeled 'Business Service') extends CMDB_CI
• CMDB_CI_SERVICE_AUTO (Labeled 'Application Service') extends CMDB_CI_SERVICE
• CMDB_CI_SERVICE_DISCOVERED (Labeled 'Mapped Application Service') extends CMDB_CI_SERVICE_AUTO

1. So just to validate - if we go with the option of skipping a population method on Application Services for now, and give our users a form view  on CMDB_CI_SERVICE_AUTO to update their custom attributes (and put their attributes on CMDB_CI_SERVICE_AUTO) it sounds like that's our best approach? I totally take you point re: catalog item and workflow for editing, and we are planning to do that! Just want to make sure we put the attributes at the right place in the table hierarchy.
   
   
2. Continuing: So say we have Application Services with no population method, and then our analysts begin relating infrastructure to the Application Services manually (or via a catalog item process). Would it be recommended to set a population method of 'Manual' on the Application Service at that point?
   
   The reason I ask is that I've noticed that once I set the Population Method on an Application Service to Manual, that from that point forward if I attempt to open the service Record (whether from CMDB_CI_SERVICE_AUTO or from CMDB_CI_SERVICE_DISCOVERED) it opens the form view of the record on CMDB_CI_SERVICE_DISCOVERED. My issue with that is that a base user with ITIL in my PDI is able to edit fields on records on CMDB_CI_SERVICE_AUTO, but base ITIL user is NOT able to edit any fields on records on CMDB_CI_SERVICE_DISCOVERED.
   
   My only concern is that we start mapping our infrastructure to Application Services manually, so we set the population record to manual on those Application Services, and then they all become locked to our ITIL users. Does that make sense?

Thank you again for your time helping us understand this! It is so appreciated!

[Barry Kant]

Good day,

1 - The easiest to see the extending logic at glance is via the CI Class Manager:

 All Child classes include all attributes from the partent class. Meaning: if it starts at cmdb_ci_service_auto filling the attributes and for some reason it needs to be a cmdb_ci_service_mapping there is no information lost. 

2 - Would it be recommended to set a population method of 'Manual' on the Application Service at that point?  Yes

I understand the concern. CMDB should be reliable if it comes to data correctness. itil role can change quite a lot... So either you create a separate role for this data object, but I think for Application Services it makes sense to control it via Catalog Item as it 'should' be the Owner that maintains the record (or is responsible for). If the number of applications is huge, than it might be different, and maybe requires another solution approach. Application Services are in general not so much of dynamic data. But you can use this object level also for non application solutions which can be more dynamic. 

For Base Users maintaining the CMDB I always would like to control that via Catalog Items to control what attributes they can change. 

If you do that via Catalog Item and Flow Designer you can execute it as System, so that is not a problem. 

Cheers,

Barry