I have a particular liking for ServiceNow's CSDM modelling practice because it is a challenging and rewarding exercise that brings together conceptual thinking and business practices. As someone who has experience in both, CSDM offers a unique philosophical challenge that also has the potential to be of great value to businesses (a rare occasion, if, like me, you had studied philosophy alongside computational science).
If you find your way to this article, I assume - but also hope - that you have probably seen dozens of CSDM definitions but still, something is not sitting right. Well, this is not an insinuation about your mental capacities but about the uneasiness in defining this beast called CSDM. It is something absolutely fundamental; yet, at the very same time, fleeting, ignorable, seemingly postponable and unimportant. If there are two words to qualify CSDM, I'd say: "insignificantly foundational." It is a bit like social media: until we lose control of our life thanks to ignoring how much impact it actually has on it, we don't get to appreciate its absolutely-not-ignorable impact.
What is CSDM?
If you have ever done CSDM modelling, you will know that every question has one common answer: "IT DEPENDS." Yes, in CSDM, everything depends… but depends on what? Well, the entire practice is also an attempt to find out that. If your organization were a person, CSDM would be her practice to "know thyself" – a call to wisdom. It is in this sense I push forward CSDM as something, simultaneously, so basic and enormously complicated. And for that reason alone, it deserves our attention, dedication and love.
Luckily, your business is not a person (not yet, let's say). Although it is also a living organism thanks to each of us, I want to believe that getting to know a business organization does not require the same emotional roller-coaster, endless therapy sessions and an ultimately indivisible remainder, which you will never get to know, and which throws you off just when you think you get to the bottom of it. Therefore, if we can somehow justifiably freeze time for the sake of analysis, the image/metaphor that comes to my mind when I think of CSDM is "X-Ray".
CSDM practice is like taking an X-Ray of your organization, a snapshot of what is actually in perpetual motion, whose purpose is to show all the crucial information about it. With this information, you can then have an insight into the inner workings of your businesses, diagnose any malfunction, and develop strategies on how to improve it or fix it. But first and foremost, you will get to know your organization. You will make sense of the organizational limitations, habits, and reflexes by placing them in an organizational narrative, which is called CSDM.
It is, in other words, an attempt to map the formal structures of your organization, which are animated by the flesh and sweat of a variety of teams in their day-to-day operations with different purposes, in which they invest a significant part of their one and only life – and somehow, collectively all of this effort ultimately aims is to achieve a few cardinal business objectives. So, the better your CSDM model is, the less friction people experience when executing these operations within a "whole" that makes sense for these cardinal objectives. If you wonder how this X-Ray looks like, you can have a look at that famous schema below.
The CSDM Schema
What you see here is a sophisticated and - hopefully - intuitive attempt to show what a "healthy organization" should look like with all its organs and their interconnections. Now, an organization is a species; and this means that not all organizations would reveal the same image as above. But it is my understanding that, this is where "the evolution" (if you follow the metaphor still) shall lead to – indeed, the survival of the fittest.
So, the ultimate purpose of CSDM, correct me if I am wrong, is to create a "perfect whole" out of your otherwise seemingly disparate yet somehow interconnected businesses. There is an important and deeply philosophical issue at play here. Let me explain this.
CSDM as a "Way"
It is misleading to think that before the CSDM practice, you had an "order" to your organization. And, and thatt CSDM is there merely to expose that which already exists. Yes, your organization had most definitely an order. But no, CSDM is more than that – it is not simply a "method", a fixed procedure determined before you had started. It is the "evolution at work" that aims to change the order of your organization. Perhaps, it would be more fitting to understand it as a "way". This will make sense if we get a bit of etymology. The word "way" shares its Germanic origins with "weigh," both stemming from the Proto-Indo-European root *wegh-, which means "to carry". The concept of a "way" or path evolved from the practical act of transporting goods along established routes. In this sense, making paths is really just embodying how weight itself creates passages. What does this mean for us? CSDM is not a pre-existing road map. We do not know where we are going until we are there. The "way" is generated by the weight of the practice itself.
All this is to say, this "beautiful whole" (where organizational evolution should lead to) is what is co-constituted throughout the CSDM journey. And it is in this "beautiful whole" that each and every part makes sense; everything is just where it is supposed to be. Every process leads to the realization of those cardinal objectives in the most frictionless way possible. I do not know if this perfection is ever to be achieved; yet, but it is an ideal to strive for (and hence the need for ethics - but that's altogether another story). And this is what CSDM ultimately aims at. A perfect whole – that is, your organization.
The Guerilla Approach
Now, as mentioned, you probably have already read about CSDM. There is a lot of information already available on the internet. There are white papers with all sorts of definitions. There are also invaluable assets that are provided by ServiceNow. I do not mean to go through these abstract definitions which are puzzling at first but once you get into the process gradually make more and more sense. What I instead propose to do here is a guerilla activity. I will dive deep right into the modelling via an intuitive example that I hope we can all follow. Then from there we try to understand the more complicated scenarios. But my ultimate aim is to explore the logic of CSDM. Yes, everything "depends" in CSDM. But then how do I even know if we are making sense? It is sometimes a bit like postmodern art; you are looking at this piece of cucumber in an expensive museum and don't know what to do with it… Similarly, the amorphous nature of CSDM sometimes lends itself to too much "IT DEPENDS". Well, I want to believe that it doesn't always "DEPEND" – meaning that there are good practices and bad practices… But then, yeah, it depends. Anyways, let's move on.
First, let's set out the basics.
In our guerilla activity, our case study will be a restaurant. Why? Because we all know it, right? It is intuitive. There are some other reasons. But do you really care? Let's just start.
To begin with, we simplify the basic definitions, which otherwise might sound unnecessarily complicated.
Instead of abstract definitions, let's make them concrete in reference to a restaurant business, which we all know.
Business Services
To start with, our beloved Business Service. What is it? It is what the customer experiences and understands. For example, "Lunch Service" or "Fine Dining Experience." The customer doesn't care about the ovens or the reservation software; they care about getting a good meal in a nice environment. That's all they care about. That's why they come to your restaurant. There has been no customer who asked about the technology used to prepare her food, I hope. In any case, if they do that, it is very annoying. When I was working in the kitchen of a restaurant during my studies, one guy was insisting on seeing the microwaves we used to heat up the food. First of all, it is not nice to admit that you actually heat up pre-cook food to serve. He had a thing about microwaves. Well, the owner allowed him and he was very happy. In any case, that was not a service we
provided. He misused us. If only there was a MeToo movement for the working class as well back then.
Technical Services
A Technical Service is a "back-of-house" component that different teams and departments manage to make the business service possible. So, what does this mean for a restaurant? Maybe, "Inventory & Procurement Management." This is the digital tracking of ingredients. If the database for "Saffron Supply" fails, the "Fine Dining Experience" menu collapses, even if the stoves work because you need that goddamn saffron, otherwise it is "just fine dining", not fine dining. Another one: "Environmental Control Systems". This is the automation system behind HVAC and lighting. If you have been to a restaurant with no climate control system, you would know that the entire experience becomes an endurance test, especially if the food is spicy. I was once in a Korean restaurant with no ventilation under 36 celcius degrees. It was a free sauna experience. Another obvious one is "Online Reservation System Support" that allows diners to book their seats. Now, these different teams and departments are usually placed under IT. Why? Because they are "technical services" and the technicity of it refers to the platforms, technologies, tools that come together to enable the working of the business services. It is an interesting question to think about technological services not placed in IT – but we won't go there. But I like the question. In the latest CSDM 5.0, technical services are renamed to "Technology Management Service". This makes things much more intuitive to understand. IT provides technology to the restaurant staff, not directly to the diners. And thanks to this technology the business service runs. It underpins that bite with saffron in it.
CSDM vs CMDB
Now, let's take a small step for us but a big one for the humanity of ServiceNow and try to solve a big mystery. Yes, I am talking about the distinction between CSDM and CMDB. Evidently, they are not the same things. We now know that CSDM is what the X-RAY of your organization ideally should look like, with all "organs" and "veins" connected and every cell accounted for. CMDB is the concretization of this model. It is precisely what and how things are connected to one another so that this perfect whole functions as it should be.
Configuration Items (CIs)
First of all, CIs. It is one of the most important and exciting concepts in the entire ITSM, I think, because of its immense malleability. It is what "circulates" in CMDB. To follow the health metaphor, I tend to call them cells, but I feel like it would be misleading. In any case, CIs are building blocks. The CSDM modelling is an attempt to take good care of these CIs because in the end they will make your business flourish. They blow life into this otherwise lifeless model. That's the reason why you fill in the CMDB tables and not CSDM tables. So, CMDB is the medium/tools thanks to which we map reality into our "perfect model". If you understand CIs, you would then understand that they do not have to be a PC, or a docking station. They can be many things, tangible and intangible. When you think of them as building blocks of your business, then you grasp how foundational and powerful this concept is.
After all these words, in the context of our kitchen example, a microwave would be a CI. But remember here. CIs do not need to be something tangible. They can be logical in the sense that they represent something that has an impact, a role, and is "expected", in our model. A microwave is expected in a kitchen; cutlery is expected, so is any (possible) integration between the kitchen computer inventory management system and the supplier. The logical CIs are also expected in the system: they have an impact; they have to be there for the organization to run. So the world of CIs is not limited to the items that you can touch and feel but it represents all that is needed for your organization to triumph. Let's park this issue for the moment (otherwise, it would swallow us), and get back to the basics.
Service Offerings
We talked about Business and Technology Management Services. These services are in fact buckets where specific flavours or commitment levels reside. These are your service offerings.
Business Service Offerings
Let's start with Business Service Offerings. We mentioned "Fine Dining Experience" as one of the Business Services: that big promise we make to the customer that they will pay more for eating less and they will love it. But what does that actually mean when someone sits down? It means choices. A tasting menu with sophisticated combinations of unheard veggietables. A dedicated wine menu which complements and enhances that disproportionately expensive bite. À la carte with sommelier consultation. A chef's table experience where the entire kitchen makes a show just for you. These are your Service Offerings.
They are not different services; they are different ways of consuming the same service. Different commitment levels, different flavours, different price points but all under the same umbrella of "Fine Dining Experience."
Why does this matter? Because nobody eats a "Fine Dining Experience" - it is an abstraction. They eat the seven-course tasting menu with the optional truffle supplement. They drink organic orange wine with pickled hazelnut finishing (I just made this up). The Service Offering is where you actually get to eat something, where the fork meets the plate.
Now, here's where it gets interesting. Where do we stop? The temptation is to create a Service Offering for every possible permutation. Tasting menu, five courses. Tasting menu, seven courses. Tasting menu with wine. Tasting menu without wine. Tasting menu with wine but only natural wines. Before you know it, you've got forty-seven offerings and nobody can track that. So to repeat, how do we know where to make the difference?
The Principle of Meaningful Distinction
This is where discipline comes in. A Service Offering should represent a meaningful distinction, something that changes how you deliver, support, or charge for the service. If swapping out the wine pairing for a non-alcoholic pairing doesn't change your opertional model, it's not a different offering; it's a change in your setup. Don't confuse the menu with the modifiers.
Let's dig into this further with another example.
Imagine your restaurant decided to offer another Business Service called "Private Event Catering" because the stress was not enough. Under this service, two offerings are available: (1) "Corporate Package:" Fixed menu, standard setup, invoiced monthly, dedicated account manager. (2) "Wedding Package:" Custom menu consultation, on-site coordinator, premium tableware, upfront deposit required.
These are genuinely different offerings because they change how you operate: different billing cycles, different staff roles involved, different procurement processes, different SLA expectations (a corporate client might tolerate a 48-hour response and might even be delighted, whereas a bride might lose her mind in 3 hours).
Now consider: within the Wedding Package, does "chicken or fish" constitute a different Service Offering? No. That's a configuration: a choice within the offering that doesn't fundamentally alter your delivery model, support structure, or contractual commitment.
If we come up then with a principle, it would be something like: Does this distinction change who is responsible, who supports the process, how you're held accountable, or what resources are mobilized? If yes, it's probably a different Service Offering. If no, it's a configuration detail. Again, how this distinction/decision is made, to your surprise, will DEPEND on the situation. Whereas the presence of wine can change the service offering under Fine Dining Experience, it won't change anything for Private Event Catering.
Technical Service Offerings: What the Kitchen Promises the Floor
If the Business part is clear, let's start with Technical Service Offerings or Technology Management Service Offerings as in CSDM 5.0. We said Technical Services are the back-of-house machinery that makes Business Services possible, that underpins them. But just like Business Services, they don't exist as blank cheques, they come with specific commitments, flavours, tiers. These are your Technical Service Offerings.
Here's the crucial shift in perspective: the "customer" is no longer the diner. It's the waiter, the floor manager, the sommelier; these are the people inside your organization who rely on these technical capabilities to do their jobs. The kitchen doesn't serve the guest directly; it serves the front-of-house, the business services, who then serve the guest. This doesn't mean, obviously, that if the customers were to grab the food from the kitchen themselves, we wouldn't need technical services but this is a very good catch.
Let's dwell on it and try to think of a possible world where front-of-house is not needed. That is to say, can we get rid of the business services and just make do with technical ones? I think it is a seductive but misleading thought. Imagine a restaurant where customers walk into the kitchen, point at what they want, pay, and leave. No waiters, no hosts, no theatre: no experience? What did we eliminate here? Yes, sure, it is no longer a fine dining experience; but it seems to me that, as long as that customer pays for that food, there is an experience – now it is "Self-Service Kitchen Access." And the technical service remains there; perhaps compared to fine dining experience, less technical services are needed now (e.g., you don't need to cool down the interior and put fancy clothes around), but you cannot get rid of technical services. While a business service without technical service is pure theatre - all promise, no delivery - a technical service without a business service is pure machinery. It works, but nobody knows what it's for, or worse, nobody knows how to want it. The inventory system tracks saffron perfectly. But without "Fine Dining Experience" to give that tracking meaning, you just have... a database. Accurate, functional, soulless. The HVAC keeps the room at 21 degrees. For whom? For what purpose? It's climate control in search of a reason to exist. I haven't seen a customer paying for the privilege of watching the HVAC system operate. The technical service provides capability. The business service provides purpose. Without the business service, you have a machine that runs, but running is not the same as serving.
Actually, I wonder if there's something even more precise here. A technical service without a business service isn't just crude or purposeless; it's "illegible" to the outside world. The customer cannot interface with it. They wouldn't know how. It's like offering someone raw electricity instead of a charged phone. Technically useful, practically useless, potentially dangerous. I met so many people who wanted to be just a technical service but complained when there were no customers; but met even more people who wanted to be just a business service and made a fool of themselves with the first serious customer. No joke, we gotta have both.
This matters because it clarifies something fundamental: the Business/Technical distinction isn't about visibility or complexity. It's about who the service is for. Technical Services have internal consumers: the people and teams who need them to deliver the Business Service. No matter how stripped-down your operation becomes, this structure remains. Even a food cart on a street corner has Technical Services: the gas canister that fuels the burner, the cooler that keeps ingredients fresh. Invisible to the customer, essential to the operation.
So, when we talk about Technical Service Offerings, we're asking: what exactly is the back-of-house promising to the rest of the business? And this is where two distinct dimensions come into play. Conflating them is a classic mistake that will haunt you later.
Dimension One: Capability
What can this service actually do for you?
Let's return to our "Inventory & Procurement Management" Technical Service - the system that tracks what's in the pantry and what needs ordering. You might offer two capability tiers:
- Basic Inventory Tracking – Manual stock counts entered weekly, automated low-stock alerts via email, standard reporting dashboard that shows you what you had, not what you have
- Integrated Inventory Management – Real-time stock tracking via kitchen sensors, automatic purchase orders triggered when thresholds hit, supplier API integration so the saffron orders itself, predictive analytics for seasonal demand because the system knows Christmas is coming even if you forgot
The first gets the job done. The sous-chef walks the pantry every Monday with a clipboard, curses under his breath, types numbers into a screen. The second knows you're running low on saffron before anyone opens the cupboard. One requires a human to remain vigilant; the other shifts that burden to the machine: until the machine breaks, of course, at which point everyone remembers why they used to curse the clipboard less.
Dimension Two: Commitment
How much support and responsiveness do you get when things go wrong? And things will go wrong. If there is one thing you can't avoid, it is this.
This dimension is independent of capability. You could have Basic Inventory Tracking with a 4-hour response SLA and a dedicated support contact who picks up on the first ring. Or you could have Integrated Inventory Management with best-effort email support and a "we'll get to it when we get to it" attitude; good luck with your saffron.
Commitment is about what happens when the system fails, not what the system does when it works.
In practice, organisations often bundle these: higher capability comes with higher commitment, wrapped in a nice package called "Premium" or "Gold" or whatever marketing thought sounded expensive. But they don't have to be bundled, and recognising this gives you flexibility you didn't know you needed.
Let's consider our fine dining experience, which might need Integrated Inventory Management with a 2-hour response SLA, because, yes, if you miss that saffron delivery, the entire tasting menu collapses, the diner loses his mind, the chef weeps, and the city turns into Gotham. But your casual Indian food shop across the street? Basic Tracking with some-day support is perfectly adequate. And it always tastes good regardless of what is missing, which you will never know anyway. Nobody weeps; everyone is happy. Life continues.
Same Technical Service. Radically different offerings tailored to different internal consumers and external customers with different tolerances for failure.
The same logic applies to "Online Reservation System Support" as well, because you would need an "Advanced Reservation Platform" with waitlist management and real-time estimates for your fine dining experience.
Application Services / Service Instances
And now we have arrived at another central, and perhaps the most important concept, in CSDM modeling - namely, the "Application Service". I have some reservations concerning how to place this concept within our metaphor of health and body. I first tended towards "heart" as this is placed in the middle of the model where everything connects to one another as the unifying, animating center of the model. "Heart" is a seductive idea to suggest but I tend to reject it after thinking carefully. I think the best metaphor for the Application Service is the entire "body" itself. It is what you see, what engages with you, the very instantiation of the entire architecture that makes up your model. So if CSDM is your anatomy, CMDB is the infrastructure, then the Application Service is your body - the very instantiation of CSDM-CMDB collaboration. So, in a sense, when someone says "I look at you and see your heart", they are basically referring to CSDM modelling, keep that in mind if you ever hear this. Yes.
Now, our restaurant example is actually a brilliant one not only to substantiate our claim but also to convey something essential and distinctive about the digital platforms we are working with.
The Directness of the Physical World
The weird thing with respect to our restaurant when it comes to Application Service (which is now Service Instance in CSDM 5.0) is the directness of it. That is, with the restaurant example, we do not have to rely on our abstractions too much because it is basically there in front of us as something tangible, something sedimented in our collective consciousness for a long time. It is part of our lifeworld unlike many digital concepts that are hard to imagine intuitively.
This is all to say that the restaurant is the service instance. Simply. And the reason it feels strange is that in the physical world, we don't usually need to name it as such. The restaurant is just... there. It's obvious. You walk in, you see it, you eat in it. The instance is self-evident in a way that a ServiceNow Dev or SAP HR Preview is not.
In the digital world, the "where" becomes genuinely mysterious. When someone says "we use SAP for inventory management," you have to ask: which SAP? Running where? Configured how? Connected to what? The digital architecture creates layers of abstraction that obscure the simple question: where does this thing actually live?
I find this a brilliant case study to understand our digital world.
Scaling: From One Instance to Many
In our restaurant metaphor, imagine you're a chain. You have "Fine Dining Experience" as your Business Service. You have "Inventory & Procurement Management" as your Technical Service. But now you have three restaurants: one in Brussels, one in Paris, one in Amsterdam. Each restaurant is a Service Instance. Same brand promise, same technical capabilities in principle but "three distinct instantiations", each with its own:
- Physical equipment (CIs)
- Local supplier integrations
- Specific configurations (the Brussels location has a wide variety of beers, Paris has a larger wine cellar, Amsterdam is open later)
- Local staff who consume the Technical Services differently
The Technical Service "Inventory & Procurement Management" exists as a concept, a capability you provide. But it runs three times, in three places, with three configurations. Those are your Service Instances.
Of course, if you only have one restaurant, the Service Instance and the Technical Service collapse into each other. There's no need to distinguish "the capability" from "the specific deployment of the capability" because there's only one deployment. The question "which instance?" has only one answer and it is so obvious that the question doesn't even arise.
This is why our restaurant metaphor turned out to be pedagogical, not because it's wrong, but because a single restaurant is too simple to require the distinction. The moment you scale (multiple locations, franchises, or—in the digital world—multiple environments, tenants, deployments), the Service Instance becomes essential.
The Digital Necessity
Now, the digital world makes this visible by necessity: In IT, you cannot avoid the instance question. You might have:
- DEV, TEST, PROD environments of the same application
- Multiple tenants on a shared platform
- Regional deployments with different configurations
- Disaster recovery instances that mirror production
Each is a Service Instance. The Technical Service describes what you're providing. The Service Instance describes where and how it's actually running.
So, the restaurant metaphor reveals that physical businesses often operate at a scale where the instance question is trivially answered. Digital systems, by their nature, proliferate instances in ways that physical systems don't.
Dynamic CI Groups: The Freedom to Construct Your Own Body
But there's something even more interesting going on here, something that our restaurant example cannot quite capture.
In the physical world, your "body" is given. A restaurant is its building, its kitchen, its dining room, its equipment. You can't wake up one morning and decide: "Today, I want to think of myself as just the bar and the wine cellar, excluding the kitchen." The physical grouping is fixed, or if not fixed, it is expensive to change, sticky.
In the digital world, you have far more freedom. You can construct your own groupings: decide which components belong together, for which purpose, under which circumstances. This is what ServiceNow calls Dynamic CI Groups, and it's more powerful than it first appears.
When you first encounter CSDM, you see Application Services presented as "DEV, TEST, PROD." If you don't yet grasp what Application Services really are, it's easy to conclude: "Ah, so an Application Service is just the instances in our release cycle." And yes, because your applications live in these environments, you're not wrong. But once you understand the idea behind Service Instances, you realise they can be far more malleable than a simple list of environments.
You might create a Service Instance that groups all customer-facing components across three different applications, because when the customer experience breaks, you don't care which application caused it. You care that customers are affected. The incident is "customer-facing services are down," not "Application X, Component Y, Server Z has failed." Or you might create an instance that groups all components owned by a specific team, because when you're managing accountability, organizational boundaries matter more than technical ones. Who's on call tonight? The answer isn't "the people responsible for servers 14 through 27." It's "the Payments team." Or you might group by regulatory boundary: "all components that touch personal data" becomes a Service Instance because GDPR doesn't care about your application architecture; it cares about where personal data flows.
The grouping serves your purpose, not some pre-ordained architectural truth, and this gives you an enormous freedom, which is very hard to gain in the physical universe. This is the freedom that digital systems offer: the freedom to construct and reconstruct your own "body image" as your purposes evolve. Perhaps in this sense, we can place Application Services / Service Instances at the heart of CSDM. They're not just "where the application runs." They're the answer to: how do we want to see ourselves?
Closing
Well, this has been a long journey and if you have made it this far, first of all, I'd like to thank you. As someone who loves to write and read, I have been made repeatedly aware of how demanding it has become to ask of anyone to read a text – I mean really read it - especially when the text is not in the form of AI-output with bullet-points and easy formulations to digest. I hope the output is worth the effort and my journey could help you in yours.
