Application Service without operating environment

[Cat3218]

Hello Community,

I have a question regarding the Application Service class. In most data model examples I've come across, Application Services are typically tied to specific environments—for instance, SN Incident PROD or SN Incident UAT.

Recently, there's been a discussion within my organization about defining Application Services without referencing the operating environment. My position is that such a construct aligns more closely with a Business Application rather than an Application Service. However, from an architectural perspective, there's a preference to govern ServiceNow as a single Business Application, rather than separate busienss application such as SN Platform, SN Incident, SN Change etc.

I'm curious to hear your thoughts or experiences on this approach. Has anyone implemented a similar model?

If you are keeping Application Service without operating environment, how does your incident/change management process work?

[Mattias S_rlin]

Hi,

If your IT processes depend on knowing which environment (production, test, dev, etc.) an incident, change, or event relates to, then you need to make sure the environment is clearly defined.

Normally, you wouldn’t need to include the environment in the name of an Application Service. The only reason it often ends up there is because names must be unique. Without it, multiple services with the same name would cause confusion.

If your organization has decided that only production CIs are stored in the CMDB, then you won’t run into this issue. But if you include multiple environments, you should add the environment (or another differentiator like location, for example if you run two production instances in different regions) to the Application Service name.

When it comes to structuring one or several Business Applications while modeling the ServiceNow platform, it’s up to your organization to decide the level of detail. Some choose to group all applications running on the ServiceNow platform under one Business Application, while others create separate ones for each app or function. If you don’t have a clear need for separation, keep it simple! You can always split them out later if it becomes useful.

Best regards

Mattias Sörlin