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.
With platform teams the discussion quickly lands with - well - platforms. More specifically the question around how complex the model for platforms can become. After all, just look at this example from UC Davis (which i can highly recommend).
But what are the criteria to be that granular? And when is a simple model more than enough? And how would that be modeled? Welcome to why is it modeled like that?
Short note: This article was modeled based on the CSDM 5.0 draft and uses the wording "digital product" instead of "business application". I prefer digital product, but please see this as officially outdated, as the CSDM 5.0 white paper wording has been corrected to be "business application".
Short note II: The relationship between the TMS and TMO points in the wrong direction. Thank you to my colleague who noticed it.
The starting point
The starting point for any platform application instance is always a five object point:
Note: The relationship between TSM and TMO is a reference in the system.
This straight forward model is the smallest point you should start at. This is more than enough to manage ITSM relevant tickets in relationship to any platform. It also separates already between any infrastructure issues & platform issues. If the platform you are modeling has one core purpose & one core responsibility (in this case just one team) this can be enough. No need to go more complex.
So what are the layers of complexity we can add here? Note: To make the visualization clearer, ServiceNow will be used to highlight the different parts as it should be a common ground of knowledge.
Adding functionality
First off, let's add more functionality. With more functionality the model only needs to be more complex, if the overall functionality is not consumed by the same consumers. As long as more functionality is also available to everyone, we don't need to complicate things. But as soon as that goes out of the window, more complexity is needed. So let's add more functionality to the platform.
Huh? That's it? Why don't we have more dedicated service offerings? Good point. And important as well. This model is in-fact incomplete. Why? Access and availability to the offerings is indeed linked to offerings, not the application instances. So let's add that as well!
Much better. Now end-users can separate their concern. And users who can use ITSM but not HR have separate TMOs to work with. To keep this simple, we are going to ignore an example where BOs would be used (e.g. with CSM in use). But it would follow the same principle.
Note that the platform functionality ITSM & HR depends on the overall platform. If the platform is impacted, then ITSM & HR also don't work. However, the other way around may not reasonable.
Adding infrastructure
Let's add some infrastructure. After all, what if we have different MID-Servers?
Ahhhhhh... so many arrows. What happened?
Well, we added ITOM Health. This needs it's own TMO (again, because not everyone is going to use it). It also depends on the platform. Then we needed to separate the MID Servers. Because Best-Pratice designs recommend separate MID-Servers for Platform functionality, imports & ITOM functionality. And here we are. But, there is one thing we can do to improve everything - dynamic CI groups.
Smooth. Better. So now our different functionality is needs different infrastructure. Awesome. By now the whole concept starts to grow. So this is quite elaborate. What could we possibly add to this to make it more complex?
Adding ownership
Ownership. Most companies have different POs for each of their platform functionality. And sometimes even from different business units. The model above reflects this on an operational level. But what is with the ownership on Digital Product level?
Note: The relationship between Digital Products is a reference between the platform (ServiceNow) & platform applications (HR, ITSM & ITOM).
Alright, good. But why is this Digital Product stuff looking weird? Well, first of all, all these new DP are part of the Platform. Licensing is done on a platform level, so we need to make sure that is connected. Secondly, the initial DP is now no longer consumed by all application instances with different functionalities. But rather just the platform one (we need that, otherwise no-one owns the responsibility for the platform application instance). And this leads to this weird looking aspect. But again, this is needed to reflect ownership for the Application on a non-operational level.
And this is also where we stop. We can now add more complexity with BOs for customer facing parts of the platform (e.g. CSM). We can add more complex TMO & TMS structures for different operational responsibilities (different parts of the company running functionality on the platform). We can add more complexity for different datasources & integrations. We can add more complexity for DevOps & self-developed applications.
But at the end of the day, the goal of the article is to understand why we would add more complexity.
The key principle
Add complexity - but only when needed. As this article may suggest I don't always agree with the crawl-to-fly approach. Complexity in CSDM is only needed, if it has purpose. Sure, adding the separate functions of your platform as separate Application Instances. But before you do, make sure you have a benefit from keeping that up-to-date:
Are there different user groups? Do you have separated support? Do you have separat operational ownership? Do you actually need it? Because if you don't adding more complexity to your CSDM & CMDB will just add more overhead with no benefit.
I know, this might be controversial. It's certainly great to have a highly mature CSDM & CMDB and move towards maturity - and please don't see this as an argument against that movement. But chose your level based on what you need, not what a great maturity rating will dictate. So before you start to model everything in the highest complexity, ask yourself:
Who is using this? Where is it used? What is our use-case to have this?
Because if you have a small team supporting, owning & developing your ServiceNow platform with a small scope of functionality (e.g. ITSM only) you won't need to go beyond the starting point - in my opinion & without insights into your actual use-case.
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.
