Hi Dale,

thanks for taking the time to write this up. Some comments from 'the field'

First, you post started about merging production instances in the first one, a topic a lot of people are interested in and I believe very valuable to share how to approach it. The second though is - for my opinion - covering something completely different. Now you explain a model of Application Inheritance (which I believe should be called Application Cloning as far as I heard) which is not really the main topic for a merger. Just a small piece on how to implement.

As per Application Inheritance, I am on a different path here. I do understand the concept and believe it will be a good thing but not now. We - meaning the Platform as well as the people in the field incl. partners - are not ready for it.

Just to highlight a few things which I do not agree with in your post:

The baseline process is kept pristine allowing customers to reset/start from scratch if things go off track.

This is impossible. Most of the applications in the baseline have configurations which do not allow an easy extension as you mention it. Scripts with hard-coded table names, tables not being extensible, Objects not accessible from a scope, etc. Yes, customers can change all this and make it more extension aware, but this is against keeping the baseline pristine and poses quite some effort at least for the initial implementation. Each upgrade will need to be carefully checked. You mentioned some examples already which should not be extended like CMDB, Asset, SAM, ITBM (only very carefully)... just to name a few.

Tenants can do their own development via Delegated Development.

While   delegated development is a great feature, it currently still lacks a lot of capabilities, e.g. developers cannot even see what is available in another scope including global. I have not yet succeeded in using a delegated developer concept at any customer side without opening up to full admin for the guys.

Upgrades will be simplified due to the lower complexity in the instance.

Why would an upgrade be any simpler using this approach? Still all implemented application scopes will need to do a thorough regression test to see if the (hopefully pristine) baseline has no changes affecting them. In addition, if you deactivate a Business Rule in global scope as you don't need it and create a amended copy of it in your bespoke scope, you will get no upgrade information (e.g. skip) for this. You won't even see that your copy of the BR is not as it should be anymore.

Another thing which you do not mention at all is the cross-scope access settings. While the scopes help in segregating the configuration (which is what I believe is the whole intend of it) it also allows configuration which scopes can access objects in your scope. This is an additional layer of security which needs to be maintained. Having lots of different scoped this will get complex to maintain. If you open all the scopes for every other scope (restoring the old global access policy ) you loose the benefit. As one example, I have been speaking to our HR unit lately and asked them if a customer should do configurations in the ServiceNow scopes or if a customer specific scope should be created. Answer was: use the ServiceNow scope, the risk of problems with additional scopes and the required cross-scope privileges are to high.

I appreciate a fruitful conversation on this but I believe we need some clarification / guidelines before pushing this out as best practice.

Hi Dale, 

are you planning to repost or continue with this series anytime soon?

Best,

Jan