Multiple Business Applications per Application Service?

ahbrook · 3 weeks ago

Hey everyone!

Is it possible/acceptable in the CSDM framework to have an application service instance match up to multiple Business Applications?

For example:

We have a Production, Test, and Development instance of the ServiceNow Platform.
When conceptualizing Business Applications, it makes sense to have the overall platform as a Business Application, and then our individually purchased or considered modules (ITSM, CSM, ITAM, TNI, etc.) as Business Applications as well.
For each of the instances, we have a local MID server on our infrastructure that would be our "Application," along with the website URL we interact with.

Ken tang · 3 weeks ago

Hey, so the short answer is: the relationship goes the other way. CSDM is designed for one Business Application to have multiple Application Services (called Service Instances in newer CSDM versions), not the other way around.

Think of it like this:
- Business Application = the logical "what" (the ServiceNow platform as a thing your business runs)
- Application Service / Service Instance = the "where it's actually running" (your PROD instance, your DEV instance, your TEST instance)

So your Prod, Test, and Dev ServiceNow instances would each be their own Service Instance, all hanging off one "ServiceNow Platform" Business Application. That's the intended pattern and it's been called out pretty clearly in community discussions around CSDM 5.0.

On your modules question (ITSM, CSM, ITAM, etc. as separate Business Apps) - I'd actually push back on that a little. The consensus leans toward not going overboard. Modeling each module as its own BA gets messy fast and the maintenance burden isn't worth it unless you're tracking them as truly separate portfolio items with different owners, budgets, contracts, etc. If they're all just "ServiceNow features you've turned on," one Business Application with environment-level Service Instances is cleaner and more sustainable.

View solution in original post

Mathew Hillyard · 2 weeks ago

Hi @ahbrook

Business Application is not an operational CI. It is a design concept primarily targeted at enterprise architects and does not reference a deployed instance of an application. In order to make it "operational" you instantiate it with as or more Service Instances (or Application Services). A Service Instance is always a deployed instance of a Business Application, never the other way around as this would make no sense.

Therefore, it follows that a Service Instance can only be instantiated from one Business Application. Think about a Service Instance called Workday production - it's not also an instance of Salesforce, is it! It's not a case of avoiding this design - it's simply impossible and would break CSDM. So don't even consider it as an option.

VMs are infrastructure, and exist below Service Instances. They are a part of the infra that makes that Service Instance exist. You can either link to a Service Instance via CI relationships or via a Dynamic CI Group (which contains a CMDB Query Builder Query or an encoded query on the VM table with a suitable condition).

MS SQL is a database application that can be deployed as an instance. Therefore, it is a Business Application. A database usually runs on some kind of dedicated infrastructure, and when you deploy it, that's where the Service Instances come in.

Contracts should reference assets rather than CIs, but these plus ownership (i.e. groups, depts etc.) are related foundational data. You ideally need this data to be in place and accurate first, as particularly complex ownership models can become unworkable or too onerous to build once the CMDB and its Services are all in place.

Have a close read of the CSDM white paper as it goes into quite a lot of depth on object definitions. You are definitely on the right track in wanting to "make it real" for your stakeholders, and that means building out a real example of an end-to-end service in CSDM and walking through it top down with your stakeholders. Compile a data dictionary with a clear definition for each CSDM object and organisational-relevant examples.

Ask if you have any further questions.

I hope this helps!
Mat

View solution in original post

Ken tang · 3 weeks ago

Hey, so the short answer is: the relationship goes the other way. CSDM is designed for one Business Application to have multiple Application Services (called Service Instances in newer CSDM versions), not the other way around.

Think of it like this:
- Business Application = the logical "what" (the ServiceNow platform as a thing your business runs)
- Application Service / Service Instance = the "where it's actually running" (your PROD instance, your DEV instance, your TEST instance)

So your Prod, Test, and Dev ServiceNow instances would each be their own Service Instance, all hanging off one "ServiceNow Platform" Business Application. That's the intended pattern and it's been called out pretty clearly in community discussions around CSDM 5.0.

On your modules question (ITSM, CSM, ITAM, etc. as separate Business Apps) - I'd actually push back on that a little. The consensus leans toward not going overboard. Modeling each module as its own BA gets messy fast and the maintenance burden isn't worth it unless you're tracking them as truly separate portfolio items with different owners, budgets, contracts, etc. If they're all just "ServiceNow features you've turned on," one Business Application with environment-level Service Instances is cleaner and more sustainable.

ahbrook · 3 weeks ago

Thank you!

That's where I was leaning, and what I thought.. I definitely feel in my earlier posts / thoughts, I went overboard in making things granular.

Part of my reason for asking this is related to how we're going to be reclassifying our VM infrastructure here shortly. Our infra team wants to group VMs via "Service," separated into Prod/Test/Dev. In my mind, this seemed to line up pretty well with Application Services. But then I run into scenarios where a given VM host will support multiple purchased products... or a situation like a database cluster set (though I am going to make a general "MS SQL" Business Application for that to sidestep the thorny issue).

Our setup is a University, where the funding lines, ownership, and responsibilities can be split amongst upwards of a dozen different departments or funding sources. We definitely have a need to track contracts separately, but I don't think we are at a maturity point yet where that level of portfolio tracking is ready for ServiceNow. I'm just trying to align to that potential future.

I may also be conflating things in an attempt to simplify the CMDB and keep everything more or less aligned and where we can do automatic mapping in the future.

So TL;DR -- avoid one Application Service to Many Business Application relationships wherever possible, right?

fknell · 3 weeks ago

Hi @ahbrook,

ServiceNow offers a deck with modeling examples of various use cases. If you have the opportunity to access SN best practices, here’s the link: CSDM Data Model Examples

Your questions regarding modeling the ServiceNow instance are included in the presentation. This would be the recommendation for the run phase. To achieve this, you have to complete plenty of work upfront.

An example for your VM use-case might be ERP; there you see shared databases for multiple Service Instances as well.

The most important question would be what you would like to solve or what outcome you are looking for?

Hope this helps!

ahbrook · 3 weeks ago

I tend to have this powerpoint open whenever I can.

The main thing I'm trying to solve is to find ways to make the CSDM "real" for others in the organization - and align our processes to it. The impression I'm getting from this thread is that I'm breaking down some of the higher level elements more than I should, so I'm mentally working on scaling back.