Can there be Multiple Application Services for Business Application (For Same Environment)?

[Sairam Krishna1]

Per CSDM, A Business Application is related to an Application Service (1 to Many). If an App has Prod, Dev, QA, a Business App can have 3 App Services. Lets say a Business App has got a Prod Service, which needs to be split by 2 or more than 2. It involves a scenario where the responsible service offering differs for one vs other OR the user wanted to have a slice and dice based on their modules present within the App. I am assuming this can be done in ServiceNow, where you can have one App called ServiceNow and I can have 5 App Services for PROD, named Incident, Problem, Change, Release, Knowledge & have each of those services go through unique support group. Looking to hear more on this topic from the Experts

[Ed Laar]

Hi Sairam.

As I understand your use-case you have the ServiceNow platform and separate assignment groups to solve tickets on the ServiceNow applications like Incident Management etc.

I my opinion there are a couple of ways to configure this use case.

1) ServiceNow as the platform is an Application Service (e.x. ServiceNow-PROD). Based on a Technical Service offering related to this Application Service tickets on platform level can be assigned to the ServiceNow Platform team

2) Each ServiceNow application can be configured as an Application Service, depending on the ServiceNow-PROD Application Service: When the platform is down also the applications are down. Using Technical Service Offerings related to these Application Services tickets can be assigned to the applicable assignment groups. 

3) Alternative solution: Only create the ServiceNow Platform Application Service, create the Technical Service Offerings for the ServiceNow Applications and related them all to the Platform Application Service.

Pro: much simplified set-up; Con: auto assignment of tickets is more complicated and requires custom solutions.

Grtz,

Ed 

[WayneOdom]

We breakdown our Application Services to the level we want to manage.   So yes there are occurences where different aspects of the production environment for example will have multiple application services even though it may be considered the same system.  Because we want to manage change, or incidents at that granularilty.   

I would recommend you don't get too detailed too quickly.   Decompose the underlying service layer iteratively and only as necessary.  In early iterations we tried to break it down too granularly and it ended up being a counter intuitive nightmare that was hard to manage.   

[Andreas Borell]

It is very easy to fill a CMDB with a lot of objects, and create relationships between those objects.

However, even if you fill the CMDB through automation (aka Discovery) the most important question is always there - how do you plan to use it?

You should only model the bare minimum needed to make the system work AND anything else you plan to use.

If it is not needed and you don't plan to use it, don't model it.

Every single Application Service is a CI, and every such CI you add will be seen in the system by transactional users in ServiceNow (and they might use it), and will show up in reports and dashboards.

The system allows you to model down to a very low level of granularity, but that granularity comes at a cost - the cost of contextualization and instructions.

You can always make the model more granular later, so mixing iterative and incremental approaches in smart ways are the best way forward.

[Daniel Borkowi1 · Accepted solution]

Hi @Sairam Krishna1, Understand the application service as a synonym for system (system stack). In the case of ServiceNow, you will have the application services ServiceNow PROD, TEST, DEV, etc. Of course, the module Incident Management, Knowledge Management and so on can also be represented as an Application Service, which "contain" the respective ServiceNow instances (most likely the Prod). You can find this in the CSDM examples slide deck of ServiceNow on slides 16-20. In CSDM 5.0, this class will probably even be renamed System. However, I would personally model what you want to do with the support groups in the associated Technical Service Offerings where you can maintain the various support groups and use them for automated assignments. I do not recommend using the Application Services for this, as this may not work for all systems and you would then have to build different assignment logics. Instead, model a Technical Service Offering for the respective support groups which is linked to the respective Application Service (e.g. Incident Management Prod) using a "Contains" relationship. In your case, I would cut the offerings depending on the support group. The concept should also work for non-SaaS solutions.

Greets
Daniel

Please mark reply as Helpful/Correct, if applicable. Thanks!