You're a hero. Your team has completed a very successfully deployment of ServiceNow and everyone at Your Corp. is extremely happy. You've added processes over time and things couldn't be better (a familiar situation for most readers I'm sure). Then one day your CIO tells you Your Corp and Their Corp are merging to form Our Corp. Both companies are ServiceNow customers so "it should be a straightforward task to merge the instances".
The instances will have different and probably conflicting configurations for the same processes. That's expected so how do we move forward? This is the first post in a series looking at this scenario. The series of posts will cover the following topics:
- Introduction (this post). Why is it a good idea to combine instances? Which circumstances might lead us to keep them separate?
- Future State configuration. What would a joint instance look like? What if data needs to be separate or the processes are different for the same functional area (like differing Incident Management processes)? Spoiler: scoped applications, application inheritance and delegated development are going to play a big role in realizing this separation.
- How to combine instances. We know why we want a combined instance and in this post so we'll look at the how. How to combine or separate the processes, instance setup, how to know move the files and some higher-level project activities.
- Future State governance. Once we have our combined instance we'd like to keep it healthy and continue the journey to becoming a Lightspeed Enterprise. Good governance covering portfolio, strategy and technical is going to be critical.
- Assessing your instance. A look at configuration drift from the baseline. I'm leaving this one to the end to give me some time to create tools to assess and maybe help the instance merging process.
So why not just keep both instance stacks up and running and save ourselves the effort? I think the saved effort would be short lived. Some reasons to consolidate are:
- Single system of engagement and action. A single instance can offer a better user experience. A single place within the combined organization to request goods and services. The single instance provides a common experience to consumers and fulfiller regardless of the process being executed. The single system enables processes that are identical to be defined once, shared processes to be easily integrated, efficient task/case transfers, fewer integrations and a single reporting view across all business units and the processes.
- Reduce Complexity. Sharing functionality and process reduces the overall level of complexity. There's only a single set of integrations to maintain. Processes and resources can be shared removing unnecessary handoffs between instances. A single, common governance model ensures best practices are applied to all processes. There's only a single production instance to administer, maintain and upgrade.
- Lower Costs. You only pay for the instances you want so there are some immediate hard cost savings by combining the instances. There are other savings to be had by combining the platform and application support teams required to develop, test and maintain ServiceNow processes and applications. A single governance model, shared configuration (common reusable functionality), single sets of integrations all add up. Reduced complexity should also lead to fewer support issues.
That's all well and good but are there times when separate instances would be desirable or maybe unavoidable?
- Regulatory and legal reasons. Industry, company or country governing controls may require separate instances.
- Data Sovereignty. Data may be subject to the laws and legal authority of the country in which it is stored. This may differ between instances.
- Public facing instances. You may want to keep your critical data out of an instance that the general public have access to.
Reasons that shouldn't be reasons - but we understand how things are in the real world:
- Internal Company Politics. Sometimes organizational politics get in the way of good business.
- Agility. Sometime platform owners cannot sustain the demand requirements of their internal customers.
Reasons that aren't valid (or at least very unlikely):
- Scale. ServiceNow instances have massive scale and is unlikely to be a factor.
- Unique configuration prevents sharing the instance.
Next
In the next post I'll discuss what configuring in a combined instance would look like.
