Why is it modeled like that? This question often comes up in CSDM workshops. This series of small articles will dive into some specific modeling practices related to not just CSDM but also Service Mapping.
Today we will dive into one of the in-between steps. Before jumping into Service Mapping there will be a point where this question arises:
If we have an application service (service instance), what do we need the application CI for?
Welcome to todays article of WIIMLT.
The model
Let's start off simple:
This is your application. You support that application. And you deliver some service through that application. There is a product owner for it (in the Business Application record) and you may have development cycles through SDLC for that application as well (i know, i know. Loads of things happening even though it is a quite straight forward picture). Everything you'd want to do with ServiceNow - well, except some ITOM stuff - can be done through this model for your Application. Sure, Service Mapping will now give you more details towards what is happening in the infrastructure, but if this works, why change it?
First, if it truly works, don't change it. CSDM is supposed to make work easier for you. By adding things you don't need, you just add things you don't need. So no need to do it.
But let's dive deeper into that premise. Because the underlying question is not really about application CIs, it is about infrastructure in general. Why should i need to add infrastructure here? Better, let's rephrase it to a point where it becomes an question which is answered more frequently:
Why should i add any infrastructure?
Upstream Impact.
That's it. Server is down? Well, whats impacted? Is it important? Is it an old student project or you SAP instance? With hardware - even virtualized one - we are super quick: We need that! ASAP. So you start with dynamic CI groups. Now you know all the hardware impacting your application service. But what about the application CI (get to the point, Fabian!)?
Let's assume you application depends on other applications - for functionality, data etc.:
Oh, and of course we want to determine, wether your app is broken because of the hardware infrastructure (Note: I simplified the picture from here):
Alright. So now how do you differentiate between issues with just your application? Like a recent deployment going wrong? Or a bug reported by the supplier? Or some new feature not working?
One option: Put all that on your service instance record. But then the line can get blurry on what is actually a software issue and whats just an end-user issue. And ideally we can separate the two: Making sure administrative issues stay with the service instance, but code-related issues can stick to their own entity.
Welcome to application CIs and application component CI. This is their exact use-case (even without Service Mapping):
Here we have it. Now your potential issues of an application can be structured in-line with your infrastructure:
1) Hardware issues go with hardware CIs
2) Software/Code issues go with application CIs
3) Admin & user issues go with service instances
There is a whole other discussion on how to smoothly integrate this into the ITSM processes, who should be able to select specific CIs and who shouldn't, but this is all for a different time. Today, we just wanted to look into why one may want to add application CIs even without Service Mapping.
The key principle
At the end of the day it all boils down to the key idea of making CSDM work for you - not the other way around. If you have no need to separate your issues (e.g. because of the low volume behind it), no need to proceed into this direction. However, if you want to separate issues & concerns, CSDM is able to do just that - to whatever level of detail you need it.
And remember: CSDM is not your architectural picture. It is there to map impact. And to make the world of work work better for you (If anyone of the ServiceNow marketing team wants to reach out based on my superb use of this slogan, you'll know how to reach me).
If you have any CSDM related example where you want insights on "why is it modeled like that?", feel free to drop a reply and I will look to add it to this series.
