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

Barry Kant · 3 weeks ago

For many solutions this is correct.
And the given examples:
Platform with modules are also correct.

Another reasoning of having multiple Business Application for 'the same' can be:
a: if you have multiple funding business units, eg: HR and IT Operations and they have their own instances. (or different legal entities).
b: if the architecture is different. Eg: one on Saas, one on prem.

If it is just simple, then one Business App (potentially with modules) will do.

BR,
Barry

Ken tang · 2 weeks ago

Hi @ahbrook ,glad I was able to help! Echelon AI https://echelonai.com/ actually helped come up with the solution, maybe it's something you and your team can leverage to support your CMDB/CSDM journey

sarahbr · 3 weeks ago

This is the concept of Platform Host and Platform Application with the Business application.

Examples:

ServiceNow (Platform Host)
- Platform Applications
  - Incident
  - Problem
  - Change
Or if you think in terms of HealthCare (EPIC) review this image from a presentation I gave long ago with Mark Bodman

ahbrook · 3 weeks ago

This chart is helpful!

Clarifying question, though:

You have 2 "Application Service" entities, both labeled "Epic Production". One consumes the Business Applications "MyChart (OutPatient)" and "ClinDoc (InPatient)". The other contains the Business Service Offerings of "Inpatient" and "Outpatient".

Are those the same entity, just split up to help with readability? Or is there multiple application services with the same name, hence the "Depends on" relationship from one to another?

This actually fits really well with what I was aiming for in my original question. You have an application service that consumes a specific infrastructure layer (like a web server) that hosts multiple websites/functions on it, and therefore provides multiple business applications/capabilities.

Mattias S_rlin · 3 weeks ago

I would be careful relying on older material (e.g. slides from 2020). 😉

A Business Application represents the logical application
An Application Service represents a deployed instance of that application

This means that one Business Application can have multiple Application Services.
Each Application Service maps to exactly one Business Application, but not the other way around.
But multiple Business Applications can't "share" the same Application Service.
If you find that one Application Service is needing Another Application Service to function, then that dependency should be represented with a depends-on relationship.

While it is technically possible for two Application Services to have the same name, it doesn't really make sense. It would confuse the users and complicates reporting. Unique and consistent naming is strongly recommended.

A CSDM-aligned modelling approach is:

Define your Business Applications first (logical view)
Then create Application Services as their deployed instances (operational view)

For example:

Business Application: ServiceNow Platform
Application Service: ServiceNow Platform PROD
Application Service: ServiceNow Platform TEST

How far you break things down depends on your use case (always start simple):

One Business Application
One or more Application Services (one per environment)
Multiple Business Service Offerings consuming that service

Be cautious about over-segmentation (e.g. splitting Incident, Change, Problem into separate Business Applications) unless there is a strong reason.

Business Service Offerings can depend on the underlying Application Services, for example:

Incident Management (offering)
Change Management (offering)
Problem Management (offering)

These offerings consume the capabilities delivered by the Application Service.