All in one org or more than one org using Salesforce to Salesforce?

Question

A question has come up about whether to put our managed package product in a separate org or an existing org. I see that the platform has Salesforce to Salesforce replication built in: it is Contact and Account data that our application consumes.

My first reaction to using multiple orgs is that it adds complexity (including e.g. with two-way sharing update conflicts could arise) and undermines the idea of the platform being a container for multiple apps with some data directly shared between the apps via standard objects.

1. What are the reasons to adopt multiple orgs?
2. Is "Salesforce to Salesforce" a great way to sync up multiple orgs?

cropready's S2S (Salesforce-to-Salesforce) Adventures blog post makes interesting reading.

Answer 1

Honestly I don't have any personal experience working with Salesforce2Salesforce but here is an article i found that can shed some light on the multi-org strategy.

Enterprise Architecture: Single-org versus Multi-org Strategy

Questions one need to go through to decide between single org vs Multi org:

1. What is your Enterprise Architecture operating model?
2. Who is paying for it? (What is your scope of control?)
3. Are you prepared to deal with the complexity of having multiple LOBs (Lines of Business) inside a single Org?
4. How much change can you effectively manage in a single org?
5. How many Lines of Business can you support?
6. What are the regulatory, compliance, or security requirements?
7. Will you be using Chatter?
8. Are you willing to pay for the overhead of multiple orgs?
9. Who will modify your org(s) and who will maintain your org(s)?
10. Have you reached the limits of what you can do in a single org?
11. What is your integration strategy for business processes and data across multiple orgs?
12. Do you have any Customer 360 or global case management requirements?

Once you go through the above questionaire weigh in your options carefully to determine whether a single org or multi org strategy falls in the bucket

Insight on Integration strategy for business processes and data across multiple orgs:

Inevitably in a multi-org environment you will need to integrate across the orgs. Salesforce makes this dangerously simple with Salesforce2Salesforce integration design. Before too long you have a spider web of integrations, data replication, and very brittle point-to-point connections.

Consider integrating through your Enterprise Service Bus. While this increases your integration timelines it will also keep you nicely decoupled. If your enterprise integration strategy includes a services oriented model – your will be decoupled via business services – which should have a close correlation to your object model within Salesforce.

Look at Salesforce’s roadmap. We are all anxious for their external object support via OData. This will hopefully simplify integrations especially around master data that are only needed for reference.

Consider a hub & spoke architecture in which one of your Salesforce orgs is setup with the master data that would be shared out to other orgs. (Via OData, S2S, web services, etc) Not following this pattern may lead you to a very spaghetti design.

Consider using managed packages to deploy functionality from your hub org to your spoke orgs.

Consider using a reporting and/or collaboration hub where all all necessary data is pushed to a separate org for consolidated visibility.