Domain Separation, part 2: Instance(s) Architecture

[David Skowronek]

Domain Separation part 1 article was about the decision if the Domain Separation is actually needed or not. This article, part 2, assumes that you have decided for the domain separation.

Key question of this article: Should I have everything in one large instance or is it better to have more instances? This question is usually valid for large Managed Service Providers with high number of customers, not so much for an enterprise segment.

The main official recommendation is to use a single instance whenever possible. This strategy is well described in the ServiceNow Production Instance Consolidation playbook. However there are situations where more than 1 instance should be considered. I will put asside legal reasons such as "data should not leave the country" and focus only to reasons valid for the Domain Separation:

• Manageability, where one large domain separated instance with 100's or 1000's of customers with special requirements (wanted to have own flavor in the processes etc.) may be hard to maintain;
• Upgradability, where every process domain requires complete testing before each upgrade therefore upgrade is very time-consuming;
• Flexibility, where customers would like to use ServiceNow e.g. for their own ticketing, get some plugin activated for them etc. and this would not be possible in a large standard instance.

Service Types

Decision whether to use one or more instances should be based on the service proposition - what services the Managed Service Provider (MSP) plan to offer to the customers, their flexibility, price etc. In this article I will describe possible solution for a MSP than plan to offer 3 types of services (from the ServiceNow and process perspective):

• Standard service, where customer is buying a service and it is fully up to the MSP how the service is being develivered (what tools, processes etc. are used);
• Customized service, where customer can request some limited process customizations - usually custom fields in processes; this scenario also often include Service Integration And Management (SIAM) type of service;
• Custom service, where MSP should deliver processes configured exactly based on the customer's specifications - with own states, flows, fields etc.; in this scenario customer is often using this instance for its own internal ticketing, not only for the MSP-delivered services.

There are 3 different types of services, each of them should have different price as the effort to deliver them is different.

Standard Service Instance

Standard service instance can use Data Separation - but not necessarily. Customer Service Management (CSM) with the account structure is able to protect data from the front-end perspective. Data Separation is usually needed in the situation where external vendors are working in the backend and their visibility should be restricted or when the MSP provides services from offshore countries. Processes in this instance should be the same for all supported customers, Process Separation should be disabled.

Customized Service Instance

Customized service instance should usually use both Data Separation and Process Separation. Allowed level of customization should follow the recommendation for Process Separation:

• 80% standard
• 15% configured (via lookup tables etc.)
• 5% customized (process overrides in lower domains)

There should be defined list of customization options offered by this instance. This list should be strictly followed to prevent instance being changed to custom. No customer-specific exceptions should be allowed. If something is needed to be allowed, it should be either enabled (as on option) for all customers in this instance or denied.

Based on the support team structure (shared services vs. dedicated teams), this instance may be integrated with the main Standard service instance using Instance Data Replicator, Enterprise Service Bus etc. For the integration reason, this instance should have both data model and processes very close to the main Standard service instance. All customizations allowed in this instance should be "extra" on top of the model used by the main Standard service instance - additional fields etc. - not a complete change of state model, process flows etc.

Custom Service Instance

Custom service instance should be without Domain Separation and configured based on the customer's needs. In this situation customer is usually having dedicated support teams so integration with the main Standard service instance is usually not needed.

Conclusion

Decision about the instance(s) architecture heavily depends on the services MSP provides. Customized service instance is an option for large MSPs in the situation when MSP has customers with this demands. However this type of service can be provided from the main instance as well. In this situation number of possible customizations should be very limited and very strictly followed, otherwise entire instance is at risk.

Separation of instances allows to isolate and control customizations and keep the instance healthy. However it is very important to assess whether this architecture makes sense from the commercial perspective, if the number of customers justify separate Customized service instance. It does not make any sense for a few customers with this needs, but with 10's of customers it may have a sense as it protects the main instance from customizations.

The next chapter (coming in the first half of 04/2020) will be about the domain structure, how to structure the tree, where to do customizations and how to manage visibility.

Update:

• Domain Separation, part 3: How to structure domains

[Chirag S]

hi David, Hope you, your team and your family is coping well with the world crisis.

I`d like to share my thought on:

Do you come across the scenario where required multiple instances with either point to point OR hub & spoke architecture in multi-tenant environment as offering? any thoughts? 

[David Skowronek]

Hi, I am doing fine, thanks. I hope you are fine as well.

I am not 100% sure what you are asking about. If I understand it well, your question is not about domain separation but about multi-instance architecture, having more than 1 production instance and connect them via e-bonding (ITSM-to-ITSM) integration? If so, customers may choose instance from where they are supported?

[Chirag S]

Good to know about you! Thanks for your reply.

It`s both, multi-instance with domain separation architecture where SIAM via e-bonding (ITSM-ITSM or others app on the platforms). any thoughts on MSP Arch?

[David Skowronek]

I am usually very careful with multiple instances, regardless of the domain separation being used or not. If those instances are separated (different customers, different services, different support teams etc.), it may work. But if you start integrate instances, this is where issues will start to come. Rule I always follow in this kind of architecture is "you cannot run the same process on the same data in multiple instances". If you have different processes or different data, having multiple instances may work. In this case they can be integrated like service provider <> service consumer, similar to integratation between different companies. But if you need heavy data exchange between those instances, I would rather go with one. Heavy data exchange means there is no data security requirement that would justify this split, and heavy data exchange is usually very, very expensive implementation.