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.

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.

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.

Note: Still Composing

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.