Dear all,
I have several questions regarding the overall architectural (best practice) setup, capabilities and restrictions of ServiceNow.
Let me try to explain my current situation first - This might help you to understand where I am coming from and why I have such a big headache in because of all mentioned questions 😉 I am familiarizing myself with ServiceNow for some months. I am an experienced Senior Architect for (another) BPM tool, and I am still trying to apply lots of concepts / experiences to the ServiceNow cosmos. Unfortunately, I am really struggling in doing so and I am meanwhile wondering where to find the appropriate information and whether these concepts are applicable to ServiceNow
My questions refer to some basic (but pretty much important) concepts regarding the architectural application setup and application layering.
What I understood so far is that ServiceNow (or the "ServiceNow Platform") comes with a global scope. This scope contains “older” applications such as ITSM. Application scoping was introduced meanwhile for several reasons such as data segregation, development and deployment purposes. New modules, such as HRSD and CSM base on the ServiceNow platform:
Let me now try to introduce you to a simple and exemplary setup that I want to use to address my questions:
The international Company “ABC” has decided to use ServiceNow and the HRSD module. There is no other use case than HRSD so far and only subsidiary “Sub1” will use the tool for now. Nevertheless, it might very well be that further subsidiaries will also stick to ServiceNow HRSD in future. An important note is that the particular module (in this case HRSD) takes precedence above the subsidiary.
Following this simple setup, I would want to create an HRSD application just for Sub1. Other tools allow to introduce multiple "application layers" which can base on (one or many) other application (layers). The idea of this approach is to facilitate encapsulation of customizations and it also strengthens reusability. It leads to the following requirements (at maximum extension):
- Customization and grouping of common Platform assets (applicable for the entire ABC corp.) should be possible (lower red rectangle in the below illustration).
- Customization and grouping of common Platform assets (applicable only for Sub1) should be possible (lower blue rectangle in the below illustration).
- ServiceNow HRSD layer extends (enhanced) Platform assets (upper green rectangle)
- Customization and grouping of HRSD assets (applicable for the entire ABC corp.) should be possible (upper red rectangle in the below illustration).
- Customization and grouping of HRSD assets (applicable for Sub1) should be possible (upper blue rectangle in the below illustration).
The grey rectangles indicate what might happen in case a second subsidiary would be enabled to use the tool at a later state. Their customizations were separated from all Sub1 specific assets which might be a pro regarding potential risks and divergent release cycles.
Please find below - after this huge introduction - finally my questions:
- Is any such design pattern applicable for ServiceNow (please keep in mind that it is not only about data separation but that it should also separate specific customizations)?
- Is there a maximum of application layers in ServiceNow?
- Where and how to customize existing modules (such as HRSD) in case you cannot add an additional layer on top of it? (Coming back to the illustration...) Does that mean that all HRSD specific adaptions should be done in HRSD application and scope directly or should I (and if so how... ) create a new scoped application on top of it? If so, how to reuse the entire HRSD logic?
- Where can I get additional resources and examples addressing such kind of issues?
Thank you so much for all your support!
Cheers,
Stefan
