Multiple Business Applications per Application Service?

[ahbrook]

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 · Accepted solution]

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.

[fknell]

The example above is already the third stage of five, not sure if you really have to scale back or just build it in increments, that you don't loose people. It's a complex topic and also for me some of the examples tend to overcomplicate things.

I did the CTA and for some reason there it's explained very well as part of a case study. You see how to build it from scratch and when you need to introduce which level.

You might be fine in the walk stage for areas that are not mission critical. Besides all the benefits you also need to have the organization, that looks into this, uses it, maintains it, etc.

[ahbrook]

I apologize, I do not know what you mean by "CTA." But I think I am getting the idea. I'm likely overcomplicating things like business application and service instance because what I'm trying to describe fits better into Service offerings or services. 

[fknell]

No worries, it’s one of the two ServiceNow expert programs available. The two programs are CMA, which stands for Certified Master Architect, and CTA, which stands for Certified Technical Architect.

It’s more important to achieve your desired outcome or business goal than dying in beauty to fulfill all requirements up to the fly phase. 😉

[Mathew Hillyard · Accepted solution]

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

[ahbrook]

Thanks Mat! 

Okay, I think I see where the breakdown is, based on this reading.

Traditionally, our infrastructure folks have grouped VMs based on the application they run -- like the MS SQL example you gave. So they are looking for naming conventions for those VMs. In the past, we've done that by team name, but we are trying to get away from that. So it would make more sense for the VM group to be related to the dynamic CI group name than to the overall business application or application instance. 

My main takeaway from this is that each application service instance should relate to 1 business application. But it is possible for a given piece of infrastructure (VM, in this case) to be related to multiple application service instances -- or more precisely, to dynamic CI groups. 

So, to reiterate - Make the data dictionary as you said, demonstrate how the infrastructure team's terminology and use cases relate to it, and then try to align the names of the CMDB Groups / dynamic CI groups and the Openshift VM Groups. Don't align anything with business applications directly.