Ateko Deep Dive Ep.1: Modeling Applications Using CSDM (ft. CAE)

In this masterclass, Maxime Carrier (ITOM Practice Lead at Ateko) breaks down how to use the ServiceNow CSDM v5 framework to bridge the gap between IT Operations and the business. Learn how to find the “sweet spot” for service instance granularity and choose between an application-focused or service-focused modeling approach.

We are thrilled to be joined by Denise Morrison, ITOM Manager at CAE, a global leader in aviation and defense training. Denise shares an unfiltered look at CAE’s real-world CSDM transformation. Watch to discover how CAE transitioned from organizational confusion to absolute clarity by fixing overlapping service and offering names, collaborated across teams to manually model their most critical “crown jewel” applications before automating, and drastically improved their incident and change ticket reporting by correctly defining services, offerings, and instances.

Transcript:

Maxime: Hello, and welcome to today’s session where we will be looking at how to model business applications using the CSDM framework of ServiceNow. My name is Maxime Carrier, and I am the ITOM practice lead at Ateko. I will be accompanied by Denise Morrison from CAE, who is the ITOM manager, for ITOM visibility and ITOM health. I will now let Denise introduce herself and talk a little bit about CAE.

Denise: Thank you, Maxime. CAE is an aviation company on the cutting edge, actually. As the slide says, they’ve become a trusted partner in advanced security and mission readiness. For both civil aviation and defense and security pillars. They’re involved with pilot training during flights, and that’s both in civil aviation, which is actually commercial airlines, and then defense and security, where they actually train defense pilots. Okay. And also their simulation training program. It is cutting edge. It is ever evolving and revolving, and it is global. So it does have a footprint across the globe.

Maxime: Yeah, that’s true. I have seen installations across multiple airports when I travel. So… And to add on what you just said, Denise, the flight simulators, they’re pretty cool. I’ve seen them at your facilities.

So the idea behind this presentation is how to achieve a service-aware CMDB following the latest CSDM version, which is CSDM v5. So today’s agenda will be the following. Number one is CSDM at a glance, quick overview of what CSDM is. We will then touch base on what is the desired approach when you want to start modeling your applications. So are you a more application-focused company, or are you a more service-focused company? Number three, we will then jump into what we call the service instance sweet spot. And then number four is where Denise will talk about how CAE models their business apps and go through two examples. And then finally, we will talk about modeling best practices.

So CSDM at a glance. Today’s challenge, even today, 2026, customers are still struggling on not only maintaining a healthy CMDB, but achieving what we call a service-aware CMDB. So while a traditional CMDB offers a clear inventory of technical assets like servers, databases, middleware, et cetera, it doesn’t fully capture how those components support your business services. This creates a gap between IT operations and the business consumers.

So on the right, under the IT operations, we have examples of what it is that we discover on a daily basis for customers. Whether it’s on-prem or in the cloud. And on the right under business users, well, your employees and external customers consume your business applications, right? And then your high-level business services are typically sales, payroll services, email, financial services, et cetera.

The most typical use cases that we face are things like, well, if a server fails, which business services is going to be impacted? Again, that vertical mapping between your infrastructure and your services is super critical. Another use case: what is the full cost of delivering our sales platform? So what that means is in order to offer sales services, there’s a business case behind that. And in order to fulfill that business capacity, I should say, well, we need to deliver and implement business applications. And then the third bullet point is which services are affected by this planned change? So when you do your normal changes, you will, for example, create infrastructure-type changes where you have to apply changes to some servers, SQL databases, different middleware. When you do create those changes, we want to be able to assess the risk accordingly and automatically, I should say. And to do that, you need to create the mapping between your business applications in the form of a service instance and your deployed applications in the form of middleware which is databases, IIS, etc.

Quickly, I’m sure most of you are already familiar with this terminology but CSDM stands for Common Service Data Model. So like I talked about, common services touches email, financial, HR, employee services. It’s basically everything that is offered to your consumers whether it’s internal or external. And the data model is super critical. It gives you guidance on where the data should live in the environment. All the tables are out-of-the-box, they’re all ready to be consumed, but it’s important for customers to follow the right relationships and the right classes for your CIs to be created and mapped. For example, business applications live in cmdb_ci_business_app. So what is the blueprint for your CMDB? So like I said, CSDM is a standard framework that organizes your CMDB data connecting your technology directly to business outcomes. It maps the entire chain from the underlying infrastructure, what we also call the application stack, through the applications to the business services that users consume.

What are the typical and most obvious business values? Well, first and foremost, reporting. Having that consistent framework of having data reside in specific locations in the CMDB allows consistent and reliable information about your services and digital products. So it’s easier to report, it’s easier to create your database views. For example, give me all my incidents where a particular service instance was linked as a CI and I also want to include a particular CI class part of the application stack. So give me all my CIs where a service instance was associated and I had SQL part of the application stack.

Another business value is what we call rationalization. This allows you to determine how well an enterprise application is performing and Application Portfolio Management (APM) is now referred to as EA (Enterprise Architecture). So you’re able to perform things like total cost of ownerships, which is more of an Enterprise Architecture deliverable, but having that framework in place and the data living in the right tables/classes allows EA to do such rationalization.

Another business value is what we call audit reduction. You want to be able to identify affected business services quickly, right? So when you have your business services identified with the right set of Business Service Offerings (BSOs) which are then dependent on your service instances, you’re able to say that if I create an outage and I specify a particular service instance, I will then be able to identify which Business Service Offerings are affected. And if I have dependent applications relying on that service instance, I will also see that in my dependency view. So GRC business value will align business processes to reduce risk and assure compliance. So it’s all about having data living in the right tables.

Another way to look or put things in perspective is looking at this slide. I like how this slide represents the fact that you’ve got different types of business applications: some of them are bought, some of them you subscribe to, some of them you build in-house. Regardless of your business application, that business application will, depending on the type of business app, if it’s in-house, if it’s on-prem or you actually deploy it in the cloud, it will have a footprint in your environment. That footprint is normally represented by environment: Prod, QA, Dev, etc. And most customers will always start with Prod. And you should always put your effort in mapping your production service instances first, obviously, unless the customer will actually create changes with non-prod service instances. If that’s the case, then you’ll have to map the proper environments.

And then you can clearly see that there’s a link between your service instance and your infrastructure, right? Servers, routers—so all your telco equipment—databases, firewalls, and load balancers. So a good example of load balancers in your maps when you do Service Mapping is if your application is web-based and when it is in-house, I’d say 95% of the time that application will be load-balanced, so your entry point, just put in your load-balance service, and it will automatically add the infrastructure underneath it in your map.

Okay, so what does CSDM v5 add for the customer? Well, the biggest differential feature, I would say, or the biggest advantage is how v5 created subclasses under the service instance. And this is point number four in this table, Expanded Infrastructure Modeling. So you’re now able to create telco-type of service instances for the TSOM modules. You’re able to create more refined service instances, API-specific, integration-specific. So it adds a bit more granularity to your mapping and your modeling. There is a Service Builder that allows you to create services following a guided wizard. The little caveat with the Service Builder is it will add two additional fields to your business services: catalog pipeline and another catalog-related field. So you have to make sure that those two fields are filled in if you do decide to turn on Service Builder. So to simplify definitions, it further defines, you know, before we had something called technology service, now it’s called technology management services. So as CSDM evolves over time, right, some terms like application services, non-service instance, will shift. But the core of the CSDM, the domain, it all stays the same. So v5 focuses on simplification and clarity, designed to lower the barrier to entry. I will further explain on that point.

Okay, what do I mean about application versus service-focused modeling? So if we have a customer that wants to adhere to CSDM, and honestly, all customers should adhere to CSDM, because a lot of modules expect the data to be in most of these tables. But regardless, when you start your CSDM adventure, some companies will have a more application-focused mentality. For example, if you want to onboard a server for those companies, they will always say, “Well, this server will be linked to which application?” So they’re very focused on business applications and deployed apps in the environment. Other customers will have a more service-focused orientation. For example, what are the services that we offer to our end users? What are the services exposed that we have currently out there? An example of such a company could be like a telco company, or a cell phone provider, where they’re always exposing different offerings and services, as opposed to a company where internally, again, it’s more application-focused.

So if you want to start with an application-focused approach, you will want to connect to your enterprise architecture team, right? You need to identify what is the source of your business application. Typically, the company will have an EA solution, like LeanIX or Sparx, and that’s the source you want to start with. And if you want to do an integration, honestly, you should only sync the business apps and don’t attempt on recreating a mapping between, let’s say, there’s an architecture model for… Or EA solutions. ArchiMate is what I’m looking for, right? Don’t try to sync ArchiMate with CSDM. It’s not an easy thing to do, and I’ve seen it fail, so we do not recommend doing that.

So some bullet points under application focus. What enterprise applications do we need to meet our capabilities? If this, let’s say, JDE has an outage or SAP, will it cause a loss of revenue? What are the… So that bullet point basically helps you identify what are my MVP applications or my P1 applications that I want to start modeling first, or at least try to, I should say attack, but try to identify a list of applications that are either P1, your critical apps, your crown jewel apps, or the most often consumed applications. That should give you a list of, I don’t know, 20 to 50 apps, and it’s a lot more doable than taking on your full list of applications, which is in the hundreds.

If I go to the service focus side, you want to identify which services are offered by our sales, marketing, collaboration teams. We need to understand what services… If you don’t have a CMDB to start with, you can always identify offerings for, let’s say, your different softwares. So that could be a way to look at this. Yeah. Okay.

Applying CSDM in stages. There are multiple stages to be applied. As you know, each stage expects you to identify your business apps. For each business app, you need to have a corresponding service instance or multiple service instances. And ideally, you want to map them using Service Mapping, right? That’s the application focus. If you are service-focused, you will start by identifying your business services, your technical services, and your technical and business service offerings. And your service instances. If I continue with the application focus, the “Walk”, you can start creating dynamic CI groups. You can create your Technical Service Offerings (TSOs) along with your TS, technical service. And you can also start creating your service portfolio. As opposed to service focus, the “Walk”, well, you will make sure that Discovery is running. Okay. In order to map CIs to your service instances here. And you can also create dynamic CI groups.

When you reach the “Run”, the biggest difference between both approaches is that the “Run” under application focus, you will start defining your business services and your Business Service Offerings. And service focus, you will end up with… You will complete your business application identification. And the reason why we have this phase highlighted is because we feel, after all the CSDM implementations that we have done over the years, that in order for a customer to really benefit from the CSDM approach is to reach the “Run” phase. You want to start creating incident, problems, and changes by using your service, your service offering, and the CI, right? Service offering will identify what the customer is trying to consume. And the CI on creation is either the desktop of the person trying to consume this application or this offering, or if the person creating the ticket is knowledgeable enough to try to identify the root cause on creation by selecting a service instance? Totally fine.

However, on the resolution of the incident, if I use an incident use case, we will then determine with level two or level three that the root cause was caused by another application. And that’s the service instance that should reflect on resolution. So on resolution, the CI should change to what the root cause is, which is a service instance, most often. Or it could be another service instance of a technology service nature, or a service instance related to another business application, right? So when we do modeling sessions and we model applications using Lucidchart, for example, we will always give context. “Well, this model that we just did, here’s what the values would put under service, offering, and CI, okay?” So, but in order to do that, you need to reach the “Run” phase. And then “Fly”, you can create your business capabilities, associate catalog items to certain offerings, whether it’s technical or business, and then take on EA and so forth. But this is the most important phase in my opinion.

So when we do a go-live, like I said, either you start with the application focus, number one, or the service focus, which is your other number one, you will always end up in service delivery, right? As you can see here, if you create your business application, your business app will always consume one or multiple service instances. If you start with your business services, your offerings are dependent on your service instance, right? They’re dependent on the deployed stack of infrastructure components that makes an application consumable. Okay. That’s all I want to mention about this slide.

So what is the “sweet spot” when we conduct modeling sessions with our customers? When we conducted our modeling sessions with CAE, we had discussions with enterprise architects and the application owners on how detailed do we want our application modules to be represented in the form of service instances? And the goal here is to create just enough instances for effective IT service management. Hence, the sweet spot is determined by asking the following questions. So how do you achieve the right number of service instances? We’ve developed a series of questions that usually helps us identify. Is it two? Is it one? Is it five?

So let me go through the typical questions that we ask. So common driver under ITSM consumption: a question would be, “Would you ever use these service instances in a change ticket?” So for example, if I have an application that is hosted on a private cloud that you subscribe to, you’ll most likely not split your service instances into multiple ones. You’ll have just one representing the Prod of that application. And if the customer says, “Well, we have multiple modules.” The question you need to ask is, “Would you ever use a service instance representing that module in a change ticket?” If the answer is no, typically one service instance should be sufficient.

Another common driver is around the environment. Do you have different deployments for your development lifecycle? So if you do ITSM for non-prod, then you’ll have to create a service instance for Prod, a service instance for QA, and potentially Dev. Another driver is, are they offered in different geographical locations? So if you have an application that is deployed in multiple sites, and it’s possible that you would do a change for a site specifically which wouldn’t affect another site, you’ll have to split your service instance representing those sites.

The driver: architecture/performance. Do they run on different technology stacks or have different performance levels? If you have a deployed application that has different application stacks—a different stack of servers for a specific module of an application, and then we clearly know there’s another deployed stack for another module—you’ll have to create two separate service instances. And most likely they may have different priorities. So if one service instance goes down, the application is still consumable, but it’s going to be maybe just one particular function, right? So it could have like a P4. And then if another module goes down, right? A service instance, no longer consumable. It’s a P1.

So another driver: application dependencies. Do your systems have independent life cycles, or do changes to one component instantly require changes to the other? So a good example of that is you may have an application that has two URLs to consume the app. One URL gives you admin access. Another URL gives the typical employee access, let’s say to create your timesheets. It’s possible to create a change on the admin portion only, or a change on the employee portion, but it’s also possible to create a change that affects both. In that case, you would have a two-layer service instance architecture. You would have a service instance representing the application as a whole, and then one for admin and one for employee. And both would depend on the primary one.

So this sweet spot model is powerful because it’s the minimum level of detail required to answer your most urgent operational questions. So if you view it as a top-down impact analysis: a user reports an issue with the SAP ERP offering, you trace it down to the SAP S/4HANA ERP Prod service instance, and see the critical infrastructure that it depends on. Or bottom-up: if you start from the bottom, a planned change is scheduled for a critical database server. You trace it to see if it supports the SAP S/4HANA service instance, which then supports the SAP ERP Business Service Offering. You then know and understand the full business risk of the change. So it’s either you do a change on the application itself, so the CI is the service instance, or you can do an infrastructure change where the CI is the actual infrastructure CI, so it’s either service going down or CI going up to the application.

So find the right service instance granularity. The level of detail in your service instance is the single most important factor for a usable dependency view. If it’s too high level, let’s say I have SAP and I have just one service instance for SAP Prod, you’re not going to be able to make sense of the map because you will have way too many CIs in your map, and it’s not consumable or understandable by a person looking at this data. And if you want to leverage the “refresh impacted services” like Change Management does automatically, if you put SAP as a CI, your impacted CIs, in my opinion, are way too large, and it kind of defeats the purpose of having meaningful insight of what’s impacted. Instead, use a service instance or a module with a smaller set of CIs in your stack. So, Use Case Number One. Did you want to maybe talk a little bit about this application, Denise, and what we did?

Denise: Yeah. I first want to touch on, Maxime, how we began, because when we started, we were strictly application-focused. We had, you know, enterprise architecture involved and actually provided a direction. They provided us a set of our most critical applications to be phase one. And this model is an example of one of the critical applications that we modeled using CSDM. And we defined the business service, the offerings, as well as the application services. And as you can see at the top, there was also, you know, because these applications touch other applications. Well, it touched another application that was a Technical Service Offering. And we’re still maturing. I’m going to say maybe we’re toddlers, not quite, you know, fully matured in CSDM. But thanks to Ateko and yourself that we’re getting there. We’re slowly getting there.

This particular application had a platform host. And from that platform host had several business applications under it. And that, as you can see, consumed several application services and instances. And this particular one has definitely more than just Prod. And as you stated, we asked those questions, you know, “Could this service possibly be involved in an incident or a change request?” And we had to determine that with the product owners, the application owners, to drive how we would model these.

Maxime: Yeah. And remember when we were conducting those modeling sessions with the app owner? One useful thing that we did was to… Let’s look at past ticket examples, right?

Denise: Yes.

Maxime: How are you consuming this application today in incident and in change? And how can we improve your experience and your risk analysis by further developing the “Fly” phase of the CSDM?

Denise: Yeah. And if you go to the next case, we actually have some of what we did in the sessions where we said, okay, we looked at incidents and changes. What was that today before the modeling of it? How was it being used? How was it represented on the forms? And then after CSDM modeling this, then the more refined, the more service and offering CIs came into play. And actually, it’s improved in our reporting. We had to do KB articles and emails to advertise what the old mappings would have been on an incident and change, and then what users would do after CSDM, what would be indicated after that. And that has also proven to be a catalyst in the adaptation of CSDM. So…

Maxime: Yep. So, one use case, let’s say we take ServiceNow as an example. So, I know that in the PowerPoint of the modeling examples that ServiceNow provides, they use the platform host and app in the business application table to identify the modules, right? And the modules are really the ones that a customer has provided. So, let’s say you have ServiceNow as the platform host, and then ServiceNow ITSM or ServiceNow Incident, and then you’ll have your ServiceNow Incident service instance. So, it’s a lot of service instances and business apps to create. And not only that, if you do create all of that, is it true that in CAE, in your change management, we’re going to create a change on Incident, and then we really want to reflect the change on Incident using a service instance representing Incident, right? So, before, where it says “Incident actual”, you would apply an offering called ServiceNow Prod.

So, you were already using the model that we have on the screen right now, where you’re saying, “We’re changing something in ServiceNow,” and then the description will describe what it is, which is why we kind of opted for this model, where instead of having multiple service instances per module, we’ll have one for Prod, QA, and Dev, and then we’ll have our offerings, which are really what it is that people are consuming within ServiceNow that we’re going to be able to use in the near future, where we’re creating a change, ServiceNow Prod, and the offering is the EA solution or event management, where we’re turning on a property that may affect how alerts are processed. So, that’s how we came up with this model, because you were using already ServiceNow Prod. Does that make sense?

Denise: Yeah, that makes sense. And another point is, we actually were in a state of confusion. Because we had a lot of applications where the service and the offering had the same name. So, with these services that we defined more at a higher level, and then left the offering for the application, and then, of course, the CI for the instance of it, that in itself right there provided a lot of clarity across the organization.

Maxime: Awesome. Yeah, so you want to avoid redundant BSOs, which have the same name as your service instance. So, I’ve been showing this model to other customers, and they really like it. So, what we came up with was pretty useful.

Denise: Yes, indeed. I second that, third that. Yes.

Maxime: Great to hear. I’m going to finish with… Thanks a lot, Denise, for providing amazing context. I’m going to continue on with modeling best practices.

So, best practice number one, model with people, not just tools. So, automation, like Service Mapping, is powerful, but it discovers what exists. You need experts to define what matters. So, like we’ve been doing together, Denise, and God knows, we’ve done a lot of those modeling sessions.

Denise: Oh, my God, yes. Yep.

Maxime: It’s time-consuming at first, but we did go through your MVP list of applications. You’ve had to schedule various app owners, service owners, enterprise architects, different SMEs. We go in Lucidchart. We start drawing what we saw here, right? The blue is your business apps, the yellow is your service instance, and the green is everything under service consumption. So, your business services and Business Service Offerings. And then we go through all the questions that we looked at a few slides ago. Do you consume in ITSM? Do you have different application stacks? And then we, as a group, agree on the sweet spot for your service instances and your BSOs and business services. And then it says here, always conduct data modeling sessions with key stakeholders before attempting Service Mapping.

Denise: Yes. 100%. Yes.

Maxime: Service Mapping requires an entry point for on-prem. For the cloud, it’s tag-based, but for the cloud, if you have an application that has different application tags for your applications, you’ll have to create those specific service instances. So, make sure you have the sweet spot defined before even attempting Service Mapping.

Best practice number two. And I think this is my last slide. We’ve come up with, between CAE and Ateko, what we call a decision tree for consistency. What that means is, when we look at a list of apps that is maintained in an EA solution, an Excel, wherever, we need to figure out: is this a business application, or is this really just a technical service? Right? So, how do you figure this out? We’ve come up with a bunch of criteria that if you check those criteria, you should have your answer.

So, let’s say you start with a list of apps in an Excel document. You’ve got, I don’t know, hundreds, doesn’t matter how many you have. For each one of these entries, if you’re unable to figure out if it is a business application or technical service, go through the following questions. If you think it’s a business app, the first criteria is: is this used by employees? Is it consumed by partners or customers? Does it directly support a business capability or a business process? Has a designated business owner, right, the business app has clearly someone who owns this app. Relevance, meaning it has dependencies between other applications? It has ownership, support, et cetera. Does it possess significant operational or financial impact?

It’s funny, this morning I was looking at a list, actually, for another customer, and one of the entries was Adobe Acrobat. Adobe Acrobat is something that you push on someone’s PC for them to consume it, right? It doesn’t have a footprint in the environment. It doesn’t have a business owner. It may have software compliance around it, but it’s not a business application, right? The last criteria: has one or more deployed instances in the environment. You don’t need to have a SQL database, a couple of servers, or a load balancer for someone to consume Adobe Acrobat. Okay? So going through that checklist, I would then determine that Adobe Acrobat is not a business app. It’s software, right? So it doesn’t live in CSDM.

If you, however, had an entry in the list, let’s say you had Entra ID, which replicates AD information to Azure. Then you suspect it’s a technical service. So you would go through the following criteria. Is it consumed by other IT services, applications, or infrastructure, and not directly by a business consumer? Checking this one off is usually enough to determine if it’s a technical service or a business application. So what that means is you’ll start in the Design domain (the blue domain of the CSDM), or you start directly in Service Delivery (the orange domain of the CSDM). That’s what this means. Business app or technical service. They both will end up at the service instance, by the way.

Another criteria for technical service: provides a foundational technology capability. Example: hosting, database, API, networking, identity, access management, network services type of technology capability. The other criteria is: has a designated technical or IT service owner. And finally: impacts the availability and performance of the IT services that depend on it. Another example, you would have Active Directory. I don’t directly consume AD. But when I authenticate on my Windows laptop, AD ran in the background and allowed me to access my laptop. Furthermore, if AD goes down, a lot of applications will stop functioning, right? So AD obviously has a technical impact for the availability of other applications.

And then once you figure out if it’s a business app or technical service, you will create an application service for the business application. If it is a technical service, you will then create a TSO, right? Which will contain your SLA, support group, environment specific (Prod, QA), et cetera. And then the Technical Service Offering will then contain a service instance or application service. And then you could have a dependency between your AD application service, which is comprised of probably multiple servers, and your deployed application would then depend on your AD. So that’s where the link makes sense. Before I conclude, Denise, did you have any comments?

Denise: No, just a big thank you for your patience with us and all of us, because I know this for us being at the beginning, being very immature in CSDM. Thank you for your patience. Thank you, you know, for sitting in with all the sessions with our product owners, those painstaking sessions. But yeah, just to say we are very, very appreciative of you and Ateko for leading us on our CSDM journey.

Maxime: Thank you very much for the comments, Denise. I’m just going to end it with: it’s a lot of effort at first, but the effort has been definitely worth the value. So a big thank you for attending or at least listening to this session, I should say.