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.
When creating your service & infrastructure landscape in CSDM I am often confronted with one main question: What is the right level of detail? And although I have touched on this point a bit on the past articles, I wanted to make one article to summarize my main points.
Join me on WIIMLT and my main modeling criteria.
The modeling criteria
What are modeling criteria? Well, glad you asked. These are the criteria I personally adhere to when starting to model service landscapes or when reviewing a model. Now, these won't give a full picture, but they help me to not get lost in too much detail, while being confident of having enough detail.
Now the first starting point is always adhering to CSDM. And with that we get a pretty good idea already - especially following the CWRF approach (crawl, walk, run, fly - i wanted to not type that, but now i did anyways). And the criteria I want to highlight today are not related to that. They also do not override the basic rules. The criteria for today are aimed at one point alone:
Accuracy vs. detail.
Now, to me this is the most important topic. There is no general "right" way to model everything on a detail level. My goal always is: accurate enough, but just enough so maintenance is not getting too much.
So let's dive into these three criteria I use to get to just the right level of detail.
Change will change
Your company/organization will change. Your service landscape will change. Just 10-20 years ago, the cloud was a niche concept. Today it is everywhere. New regulations impact the market (DORA just being one example). All of this will lead to change.
If your CSDM model of your service landscape does not change - you are likely doing it wrong. This criteria is a strong reminder I preface most discussions with. Because it allows 2 things:
1) Your first CSDM model does not need to be perfect - it will change anyways
2) Your CSDM model must be easy to maintain - otherwise change won't reach it
But how do you notice that change is needed in your CSDM model? To me, the most telling aspect is always the interaction with ITSM processes. Incorrect assignments? Endusers cannot find their Offerings? CIs are not filtered as expected? Notifications don't reach the correct product owners?
This just means that your model is likely not detailed enough or that change was missed. Time to get back on it.
But most importantly I want to use this first point to stress one thing:
Start simple - but start!
You can use the questions above as datapoints to react to. You don't need to go full-blown CSDM. But you need to start. And more than ever, you need to implement ownership with it (otherwise it will be outdated quickly).
Ownership
CSDM models ownership. I know, I know. Ownership is a boring topic. But it is probably the most important one. Yes, we want to understand impact and visualize what is broken. But all that is out of the window, when you do not have ownership. If something is broken, then who is responsible? If something needs to be paid, then who is paying it? If something will be impacted by a change, who do you call?
Thats ownership:
- Operational ownership (who fixes it?)
- Business ownership (who pays it?)
- Product ownership (who is responsible?)
Every single entity from infrastructure CIs to Business processes documents one or multiple of these owners. So when looking at your model, keep it simple. However, if you notice that something is owned by more than one entity - thats not detailed enough. My approach recommendation: Start simple. Identify the owners. If they only own part of it, then split it up.
Rarely I encounter the other way as well - a model too detailed. So if some components of your service landscape is owned by the same entity, that could be room for ownership.
Most importantly: Someone must own the data of the component itself. Some of the defined owners must be held responsible to make sure the data in CSDM is accurate. This must also be documented in the components themselves. Because if that is not documented you are setting yourself up to have an out-of-date CSDM model quickly.
This is crucial - otherwise you end up with too much detail. Let me explain this with a (slightly changed) example from this article.
Both of these pictures are correct! And both work. The only difference? The ownership of the product has changed. In the bottom area we are looking at a company where ITSM, HR & ITOM are treated as different products. They are owned by different product owners. The top picture is a company where ServiceNow is just seen as one platform-product.
Yes, the bottom one is more accurate. Certainly! And yes, if the company from the top picture introduces a separate product management (e.g. by introducing different product/process owners), it should move on to the bottom picture. This leads us back to the first criteria - with organizational change, your CSDM model will change. And because the ownership must be documented now in greater detail we must move on to a more detailed model (speaking of the fictional company which started with the first picture).
Impact
Impact is the weaker criteria - weirdly enough. The core principle behind it is clear:
Can it fail independently?
If the answer to that is yes, then you can make the model more detailed by splitting up the component. However, this is only the first part of the impact based criteria. The second part is much more important:
Does failing independently have a different impact upwards?
This is crucial - otherwise you end up with too much detail. Let me explain this with a (slightly changed) example from this article.
First, the simple model (without the product or business quadrant):
As you can see here, the platform depends on "Mid Servers". These can fail independently, but because the impact towards the platform seemingly is the same, there is no need to add more detail to the model.
Now the more detailed one:
Now here the Mid Servers are specified. Why? Because independent failure has independent impact! The Mid Server for the Discovery has nothing to do with HR or ITSM. If it fails, it won't impact any other part of the platform.
Notice how the operational ownership of the Mid Servers did not change. We only needed to split this up, because the impact of independent failure is now - well - independent. And this is important.
The key principle
The key principle behind these criteria is a reoccurring one: CSDM serves you, you don't server CSDM. Your level of detail will be different from the detail needed for a different company. Your current level of detail is different from the one you will need in two years. And this is important to understand. Because it will mean two things:
1) You can start incomplete - if it works well enough; but you should always start
2) You need to revisit your model - your level of detail will change (potentially in both directions!)
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.
