Applications in the CMDB

[Brian Lancaster]

I have not had a lot of experience when it comes to best practice with CMDB.  I'm working for a new company and they are starting out building out the ServiceNow Environment.  So here we have application and each application has several modules.  We will be using Incident management to start with and will eventually use Problem and Change management.  Each application module will have a different approver for change management so we need these pick able as a CI.  We also need these for incident and problem so we can determine ware an issue lies (example instead of the issue possibly being on the server maybe it was related to the code that was pushed out of a particular module).  So my question is what table do I put these applications and their modules in?  I was thinking of use Business Applications for the overall application and then Application Services for the specific modules within the applications but the CSDM white paper says not to use CIs in the business service table as operational CIs.

[s4scott]

Certainly the base application class should be avoided as the platform is built on the presumption that all application CIs will be classified in one of the subclasses of that class. But, the cmdb_ci_business_app is also too high up the model structure to effectively be used for modules. (Assuming we don't have a dictionary problem here, where we disagree on the definition of a module, i.e. a sub component of a deployed application server.)  It sits above both the Application Service and Technical Service classes which themselves are an abstraction of the actual application instances. The fact that it is not self-evident how to address this problem in the existing class structure needs to be addressed by ServiceNow. 

A class in the cmdb_ci_app_server structure might be a good fit, but the CSDM documentation does not address the lower level structures needed to identify modules within an application instance. If Brian wants to implement Event Management or Service Portfolio Management then the use of the Business Application class to represent modules within an application platform is going to create all kinds of complexity and will likely prevent the successful implementation of one or both. Keeping in mind that alerts/events flow up from infrastructure/application server CIs to the Application Service, where does it make sense to place the Business Application CI?

[Brian Lancaster]

This is where the confusion comes in because there is a statement the white paper it says never use Business Applications for operational CI.  See excerpt below. even thought OOB you can pick them in as a CI.  So does that mean I put all my application I want to use for operational CIs in the Application Service table along with the modules?  Then latter when change and problem comes around I can setup the relationships?  I found out some more information.  So with a log of our apps each module can be bought from the companies as stand alone apps but we use the together as one application.  However we could have an issue with one module that does not affect the entire application so we want to report thought category and subcategory that the user experienced the issue with Application\app name but then the CI will tell us what part of the app the issue was truly in.

Business Application – OOB table in the CMDB meant to house your inventory/portfolio of applications and their meta data. This is NOT an operational CI and should not be used in incident, problem and change

[Darin2]

Brian, I think the example use-case for ServiceNow may help you with seeing how to address modules within an app versus the overall platform/app. The key is to make sure you have an Application Service for Services that your customers understand. In this example, there is a 'SN NY Prod' app service and 'SN NY Change Management Prod' app service. This would allow you to log an incident or change against the entire application or the specific module within the application. 

[Darin2]

The thing you need to be careful with is the overall governance of when to create an App Service for a module. You don't want to create a bunch of App Services just because you can. You want to ensure the needed clarity of tracking modules adds value to your organization. 

For example, when I owned the platform for a healthcare provider, we had one application (Epic) that had multiple modules within it. Our entire App Dev and support organization was aligned to the modules they maintained. So we needed to create App Service records for each module. We then followed that up with Knowledge Articles and a support structure for those modules. 

But when it came to the structure of ServiceNow, my team supported all aspects of it. So I would not have gotten any value out of App Services for Change Management or Incident Management. But larger organizations may need to do that if they have different teams supporting different aspects of the platform.

The key thing is to mature into the CSDM and the amount of records to maintain. Always stay focused on the value that the model is designed to bring...not just creating busy work.

[Brian Lancaster]

Epic is one of our apps and we have several other ones just like you described epic.  And you are write most likely since I will be a team of one we would not specifically separate out ServiceNow into its specific modules since I support all aspects.  So for Epic did you create an app service for Epic and then app services for each module?

Example below:

Epic
Epic - Module1
Epic - Module2
Epic - Module3
Epic - Module4