My team and I were discussing this very topic. If I interpret page 17 of the white paper literally, then an Application Service should not directly depend on any server CIs. It should be contained in a Technical Service Offering, and then those Technical Service Offerings should contain the server CIs and other Infrastructure CIs. If you look at the Paris CSDM module and create an Application Service, it makes sense, because you can only relate Technical Service Offerings and Business Service Offerings (and Business Applications, but not of concern for this question).
Interested in peoples' thoughts on this. And ServiceNow if you're listening!
I'm with you on how to create and model out technical services and technical service offerings. I'm still a little iffy on the application services. In fact, the way you described application services is how we were prototyping it. But in trying to use CSDM App Service wizard, we would have to do something like the screenshot below. Is this how you are doing it?
This is where we were getting a little hung up. How you describe creating an application service (and how it's shown below) makes total sense, but it seems to deviate a little from the guidance in the CSDM 2.0 white paper.
Here is a map I made with some demo data in a PDI running Paris. Apologies in advance if you already know these steps.
As you showed in your other screenshots, in the first step you can choose the business applications (for Service Portfolio Management) as well as the Technical and Business Service offerings:
Then in Step 2, you choose the entry points for the application service. In this case, I chose an Application and two Web Servers:
Save the changes, then click "Advanced," and finally click the related link "Update with changes from CMDB." You can choose how many layers to go into the relationship (5 should be pretty good) and then click OK and the system will build out the application service map:
When that's done, go back to the main Application Service screen and view the map. it should now include the infrastructure CIs associated with the entry points you used:
You can also view the Dependency Views for the application service and still see the infrastructure items:
But here is where the CSDM documentation really diverges from reality. In Change Management, if you set the property "Populate the service offering related list from the Impacted Services/CIs related list" to true, the Service Offerings related list for a Change does not get populated unless the Business Service (or whichever type of service classification you want from the cmdb_ci_service table) is included in the dependency map and not the service offering as indicated in the CSDM; it is not looking at related items in the service_offering table. So if your server bubbles up to a Service Offering as opposed to a Service, the Service Offerings related list will not populate.
In this case, the system is looking for any record in the table service_offering where the Parent is anything in the "Impacted CIs/Services" tab related to the Change. So, the relationships mandated by the CSDM are not what the Change Management application is using. I know that's going off on a tangent from your initial question, but it's important to know and I hope that ServiceNow takes a closer look at the way each application functions and either adapts the app or the CSDM to match.
