If you had different applications which could all be implemented in Dynamics (maybe different flavors of the case/contact management), how would you decide whether to put those applications in the same instance or whether to set up different instances for some of them?
Not sure if there is a simple answer.. My colleague and I spent a couple of hours brainstorming this question earlier today, and it does not seem that we came up to any conclusion yet, so, if you have any thoughts, you are more than welcome to join in
To start with, why would we want to have a separate instance for each application?
- We can have clear data separation – there is no risk data from one application will surface in another application
- There is no need to worry that configuration or customization changes made for different applications will start interfering with each other. This applies to the business rules, workflows, plugins, scripts, etc.
- When the same entity is added to two applications in the same instance, corresponding entity views may show up for each of the users. Well, we can still control which views will be added to which apps, so, at least in the UCI, there is a solution for this. Same with the forms and dashboards
- There is still a question of field labels and translations – what if two applications end up using slightly different vocabulary? Those labels will be showing up in the column titles and/or in the advanced find
- Duplicate detection rules may become somewhat complicated, especially when some users have access to the data in one application, and others have access to the data in multiple applications
- Regression testing is more complicated when the instance is shared – when updating one of the applications, we may have to run regression testing of all other applications
- Every instance can have different dynamics portal (well, portal add-on may still have to be purchased)
On the other hand, why would we use the same instance?
- All those complications aside, when it’s the same instance we don’t need to buy an add-on instance(or a set of add-ons to cover dev/test environments as well). This also applies to the portal add-on
- Data sharing may have some benefits (for example, rather than having duplicate contacts in different instances, we might have just one contact record)
- Added on Dec 11: If a user has access to more than one application, outlook synchronization for tasks, appointments, etc will work only when those applications are in the same instance ( as Lema mentioned in the comments below and as Joe Gill mentioned in his twitter reply )
Just by looking at the above(and I’m sure there can be other reasons in both categories), I am wondering if it would it be fair to say that, once two applications have different data models and/or data governance rules, they should certainly be separated on the instance level? In other words, an application in Dynamics seems to be more about working with the data than about the data itself(therefore, if the data is different, there should be different instances, but, if it’s the same data, it could be the same instance). Even in terms of cost-efficiency it might be better to invest into extra instances in this case since we’ll be saving on the extra work.
Or is there something I’m missing and there are other ways to think of this?
My thoughts would be:-
How different are the Data Governance rules and Processes. Would it be at all possible for a single process to be agreed?
Who is the product owner of the system or are there multiple owners?
Personally I would never look at separating a system based on how the system looks now, the decision should really be based on how is it going to be used long term. without an agreed set of processes and a single product owner who can determine and enforce an agreed viewpoint you really should go for separate instances ..
Thanks, Ben. Agree, having a single product owner would make it much easier. Although, wondering if there are any assumptions about multiple product owners we could make to justify “single” instance (maybe it still makes sense when there is some sort of core data/process which are shared, and, then, each application has its own data/functionality which is specific to the app.. on the other hand, it might be too easy, then, for each application to overstep its boundaries)
I had the same situation in couple of cases. My main issue with 2 different instance was Outlook synchronization. If you have users who will need to use both applications, you need to keep in mind that they will be available to synchronize email etc. only with one of these.
Thanks, Lema. That’s exactly what Ben mentioned, and what I completely forgot about:)
When considering two different organizations please do not forget that you need additional sandbox instances as well and that you will have two separate deployments which makes it more complex too.
Having to purchase less add-ons is definitely a benefit in the single-instance scenario, but would not it be easier to do the deployments separately (from the development/merging/testing standpoint) in the multi-instance scenario? There would be no need to retest all “co-located” applications, for instance.