Technical Services versus Application Services
One of the most common misconceptions I see in the CSDM is folks wondering the difference between a Technical (or Technology Management, now) Service - and an Application Service (or Service Instance, now). We'll use the new terms hereon in.
For the purpose of this article, assume we're talking about Active Directory, Entra ID or other "very internal, not at all user-facing, but way critical to the Business" type things, because that is what I frequently hear as having been mapped as a Technical Service - which isn't quite right.
Why the challenge?
The CSDM does a great job of enabling you to articulate what Business dependencies exist - but it doesn't explain very well that not all Services your Organisation maintains will have one. If you look at the below diagram you very likely assume that each Service Instance must provide for a Business Service Offering (and frankly, that's fair enough. More on that later).
So what do we do instead?
Firstly, the CSDM is so much easier when you start with what you know. Let's start with the below:
1. A Technology Management Service (or Technical Service, previously) articulates who supports according to which SLA or activity or Location.
2. A Service Instance (or Application Service, previously) is a deployed instance of something, for example Production, Pre-Production - and now with the rename to "Instance" we're clearer that it's not Application centric. Thank goodness for that.
Logically, then, we can't state that Active Directory is a Technology Management Service - because it's not articulating who supports it - but that it exists. Which means, then, that (like we're filling in a crossword) Active Directory Production doesn't fit in Technology Management Service, but into Service Instance.
But what about the Business Service Offering?
Remember earlier I said "more on that later"? Here we are. I'll come right out with it:
Not every Service Instance supports the Business Directly.
Before you throw your Business Services on a fire and start dancing around it, we'd better caveat that. Effectively, some platforms and tools - such as Active Directory, ServiceNow, Microsoft Azure - don't directly provide value to the Business. It's what you deliver on them which does. Therefore, for those type of things - based on our previous understanding of what a Technical Service is - we create Service Instances, but we instead link them to other Service Instances which do create value for the Business.
Imagine your ServiceNow logins are all controlled by Active Directory, and it might look something like this:
Notice from the above that each Service Instance has its' own Technology Management Offering - a group that supports it - but not all directly articulate Business Value. In fact, in this example, only Incident Management does.
Hopefully you see that by modelling what some call "Technical Services" as Service Instances, we are able to better articulate the impact of Changes, Alerts and understand the dependencies from those Service Instances which do directly support the Business. Exactly what that all looks like in practice though, will be for another time.
As ever, if you've any questions or feedback, please post them below. I'm always happy to hear perspectives, be told (constructively) why I'm wrong and so on. If this helps you in any way, I'm glad.
#CSDM #ServiceInstances #TechnologyManagementServices
