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.
Especially with database teams I often encounter a discussion around MSSQL instances & databases in relationship to their applications. So let's take a look at how it is modeled, the why behind it and the key takeaway from it.
The model
When running the discovery on an MSSQL instance (not through Service Mapping) and connect an application instance/infrastructure service to it, you will notice, what I like to refer to as the "Knick":
Naturally, stakeholders - technical and business side - like to relate their application instance to the data base. And the reason for that is obvious: It is more accurate, more natural & allows for modeling shared SQL instances - instances where more than one application runs data bases on.
However, if we run Service Mapping through the same application instance we see something different:
As you can see, the application instance is related to the database instance, not the database record. And with that there is no "Knick".
Fine, but what about that discussion with stakeholders? They would model it differently. So why don't we relate application instances to databases? Well, let me try to give you an answer - because we could. But as usual; just because we can, does not mean we should.
Why is it modeled like that?
To be upfront clear: We can adjust Service Mapping patterns to do exactly how stakeholders model it intuitively. This is more detailed and accurate to the architecture picture. But it comes with one main downside:
Inconsistency.
This is down to the nature on how databases work. They don't have to exist at all times. Some databases will always be there, especially when there is data to store around. But some may just be temporary. Or created on-runtime. And for a model which relies on consistency - CSDM - this is an issue. Because you will have instances, where the application is indeed related to the database and indirectly to the database instance. But sometimes you won't.
And this inconsistency will have a negative impact to the one thing we want to simplify through CSDM: consistent reporting.
This is not tied to "just" reports, but other, automatic functionality as well (e.g. the impact calculation). If we have different scenarios for the relationship between application instances & database instances, we will have to make up for that in reporting & rulesets.
But more importantly, temporary databases - in very rare cases - could not be present during some idle states of applications. This is not very common, but if we force Service Mapping to go through the database to relate to the database instance, we may as well loose the whole connection.
And this inconsistency - in my opinion - is the main reason why db instances & databases should be modeled by just connecting to the instance directly. But: If you truly need that detail to understand which database is related to which application instance in specific, that's fine. You can do that and extend the pattern(s) to also add the relationships to the databases.
The key principle
The key principle in discussions like these is on key principle around CSDM:
CSDM is for modeling services & their related infrastructure based on impact. It is not an architectural representation of your infrastructure.
Applying this thought process to the modeling will make these discussions clearer. Tied to this example: The impact of the database instance related directly to the application instance will be the same - with or without databases in between. Regardless of the approach, this dependency (based on impact) will be the same. Adding databases in between does make the model more accurate, but it adds inconsistency to the model as well as additional complexity.
Because most ServiceNow functionalities care about impactful relationships, the added benefit of accuracy to the model here is minute.
So what should you do?
It depends [what an amazing cop-out]. I have implemented both - the "Knick" and the ootb Service Mapping way. Communicate the advantages & disadvantages. Make sure CSDM is not seen as just another architectural representation. And if the stakeholders still want to model it in another way (and are aware of the additional efforts), go along. There are more important things with CSDM. And this one won't break anything if implemented correctly.
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.
