Many customers already have more than one production ServiceNow instance, and even more customers are asking themelves the same question: Should we have everything inside a single ServiceNow instance or rather have multiple production instances?
Based on the experience with various customers having multi-instance architecture - with both positive and negative experience - there are few rules that I derived and are important for any multi-instance architecture.
Rule #2: Customers (end-users) should work with a single instance only
Ask yourselves ... if you would be a customer, and the service provider would tell you: for this service you must go and login to another system, we do not support you in here. Would you be happy with such a service provided? Answer is very clear, no. The overall trend is to have single place for services and support, where customers - both internal and external - can get support, see their services and their status and be enable to order new ones.
Rule #3: (Majority of) fulfillers should work with a single instance only
Multiple production instances mean multiple accounts for fulfillers mean multiplied license costs. There are situations where multiple licensing may be required but it should not apply to all fulfillers. Situation where all fulfillers would need to have access to all instances usually - with few exceptions - mean that there is actually no reason for multiple instances.
Rule #4: Every instance should contain all needed data (end-to-end visibility)
During the architecture planning do not look at individual processes (Incident, Problem, Change, Event Management etc.), rather look the value streams, going cross individual processes, with end-to-end principle in mind. When e.g. there is an issue with Application, I need to:
- get event from the monitoring
- understand the impact
- raise an Incident
- inform customer
- etc.
You must make sure that all needed data are available and process is no interrupted in the middle, as the needed data are available in another instance.
Based on this principle it may be possible to have e.g. ITSM and HR in separate instances but CMDB, ITOM and ITSM should always sit together (for the same customer).
Rule #5: There is no need for heavy integrations
Any integration means cost - to implement but more important to maintain it. Usually the initial implement cost is low compared to future maintenance, if you count with 5-year time frame.
The previous 3 rules are pretty much saying that every instance is separate, as it has:
- own customers
- own fulfillers
- all needed data
Key point is how to achive this level of separation ... whether it comes from clear separation of customers, with operational model supporting it etc. or whether you must synchronize all instances with heavy data exchange to make sure that all instances have the needed data.
Heavy integration requirements, with CMDB synchronization, ticket synchronization etc. usually mean very high cost and - with few exceptions - mean that there is actually no reason for multiple instances.
Rule #6: Other integrated tools must support multi-instance architecture
ServiceNow does not stay alone. It is integrated with many other tools. And those tools - direct integrations, both inbound and outbound - needs to be considered when planning the multi-instance architecture. This especially important for inbound integrations, as not all the data providers may be able to support multiple instances.
Companies are often using shared (operational) tools for monitoring, various data providers etc. that contain data from all customers / departments etc. Key question is: are they able to split the data among multiple ServiceNow instances?
If not, ServiceNow multi-instance architecture may have "domino effect" with similar separation / architecture requirements to other tools.
And do not forget about the most important rule, Rule #1: Make sure there is SOUND BUSINESS REASON for multi-instance architecture.
IT is in place to support the business therefore make sure that there is real business reason for multi-instance architecture. Some examples of valid business reasons for multi-instance architecture:
- Divisions of the same company should behave as separate entities
- Legal / Contract requirements for storing data inside a specific country / location
- Platform contains sensitive data with highly restricted visibility
- Divestiture is planned
- Business model is based on highly customized services
- ServiceNow is offered to customers for their own usage
