Platform applications in CSDM

[Michael Culhan1]

In the diagram below (from here ), the entire ServiceNow instance is an Application Service.  The business applications (Incident, Change, etc) map directly to the ServiceNow Application Service.  Shouldn't there be an Application Service in between to represent the actual application (e.g. Incident - Production) that sits on top of the ServiceNow platform ? To put it another way, the ServiceNow platform perhaps shouldn't be an Application Service, but some other class that sits under platform Application Services.

I have a bunch of ServiceNow and Salesforce custom applications as business applications.  I would like to track changes to these applications in SN Change Management, but I hesitate to choose the business application as the CI in these change requests.  In reality, I am changing the prod instance of the application only, not the logical business application. 

[Rose LeSage]

We ran into this too! For our CSDM crawl phase, we created application services for each of the components of ServiceNow (and other platform apps). This way you can accurately reflect what parts of the platform application are receiving incidents and changes. We then created the relationships to show the connections between those application services. Perhaps in the other maturity models of CSDM there is a better way to do this, but all the CSDM documentation reflects one ServiceNow prod application service or one Epic prod. This is great except I might not always be applying changes to the entire platform and not every incident should be logged against a platform app as a whole. 

[Michael Culhan1]

Exactly, in fact most of the time, we're not changing the whole prod platform, just an indvidual custom application inside of the platform.  It's kind of funny that on the one hand SN is really pushing itself as a low-code custom app dev platform but on the other hand, it doesn't really account for this scenario in CSDM. 

[Kristine Naess]

Hi all,

This is truly confusing. I thought that the Service offerings were the entities that would separate the functionality (modules and scoped apps) from the operational application service (observable via service mapping). From what I have thought when reading CSDM 3.0-docs, the Servicenow Prod (application service) represents the stack of deployed files that makes up the production environment of Servicenow. If we have downtime on this (seldom, but it does happen), all the service offerings related to (depends on::used by) Servicenow Prod will be alerted. 

I can see that scoped applications involving other third party application instances and middleware may need to be reflected differently, but the core modules of the platform really shouldn't need separate application services in my opinion. 

As we are going towards the walk and run stages of the CSDM, we have started using service offerings in our incident-, request- and change forms. So if someone issues an incident ticket, and chooses the "Servicenow Incident" service offering, we can direct this ticket automatically to the internal Servicenow team A, as opposed to the GRC-, ITBM-, and VRM-, tickets, that are all directed to the internal Servicenow team B. 

So why would we need a bunch of additional Application services for this? And if so; what do we need the service offerings for?