Editors Note: This is the first in our new blog series we are entitling Enterprise Architecture with Force.com. Greg Cook, our guest blogger and resident expert, is a managing partner of CloudPremise and currently holds all seven Salesforce certifications along with Enterprise Architecture certifications in Togaf, Zachman, and ITIL. The opinions expressed are solely that of the author.

One of the most important decisions throughout your Salesforce journey is to decide your “org strategy.”  What this really means is: “How many instances of Salesforce will you have in your company?”  As a Certified Technical Architect I mostly deal with Fortune 500 companies.  The larger the company the more complex this question becomes. It is one of the most foundational and architecturally significant choices that must be made – this decision will impact all future Salesforce initiatives and designs.

Here are the 12 questions that I ask my clients in order to make a recommendation regarding the most appropriate org strategy:

Question 1 – What is your Enterprise Architecture operating model?

The most important consideration is that your org-strategy is an Enterprise Architecture level decision and should not be made without a thourough understanding and analysis of your Enterprise Architecture model.  In Enterprise Architecture as Strategy (Ross et al.) the authors described an enterprise architecture operating model using the following 2×2 matrix where the axis are A) Business Process Integration and B) Business Process Standardization.

• Companies high in the unification space should have as few orgs as possible.
• Those in the replication quadrant can (and probably should) have multiple orgs, however you should consider deploying a managed package from a central org into all of the replicated business units.  That way you can provide local control/administration but maintain your pre-defined standard business processes.
• Companies in the Coordination quadrant should try to stick with as few orgs as possible.  The high process integration requirements can be met with a web services integration strategy, however the potential value to the company is much higher in a single org.  A proper governance strategy and an effective service delivery strategy are necessary to keep multiple Lines of Business’s (LOBs)  happy while executing in parallel.
• Companies in the Diversification quadrant will probably always have multiple orgs.  The work to consolidate different business processes and data models into one org is usually very complicated; plus it is very uncommon for the diversified business units to be accustomed to working in the same space as the other LOBs.

Question 2 – Who is paying for it?  (What is your scope of control?)

Depending on the number of deep pockets in a company, you may have no choice when it comes to org strategy.  Orgs might be popping up all over the company.  You might not be dealing at a senior enough level of the company for Question #1.  Therefore you are often at the whim of those controlling the purse strings.  If this is the case it is your job as the architect to make sure the company moves in the following direction:

• You need to have coordination and awareness of the entire Salesforce community in your company.  This would be the precursor to setting up a Global Center of Excellence.
• You need to sit with enterprise data architects to understand what data objects should or should not be in each org – and that each org is aware of any possible duplicated data objects.  Data problems will be the death of Salesforce in your company.
• You need to push your company toward setting up a Global Center of Excellence (CoE).
• The CoE should design and build a “Reference Architecture” that defines where and when an additional org is reasonable or necessary.
• You need to get a seat at the table for Question #1 and make sure that you are making architecture decisions at the correct level of the company.

Question 3 – Are you prepared to deal with the complexity of having multiple LOBs (Lines of Business) inside a single Org?

There is a LOT of complexity in designing a Salesforce org to support an enterprise with many different LOBs.

• Make sure you have good naming standards across your data model, configuration design, and custom code.
• Your security design will be very complex.  The design of your profiles, permission sets, role hierarchy, sharing model, and public groups can be difficult to design, difficult to maintain, and especially difficult to refactor.
• Your apex design will need to be very mature to support a large enterprise model.  Adhere to strict separation of concerns and make sure you have a technical architect overseeing all aspects of the org.
• Your data model becomes much more complex and controversial as you increase your scope in the org.  Make sure you are an active participant in the Enterprise Data Strategy and employ a Salesforce Data Architect who specifically can manage the design and maintenance of the data model.

Question 4 – How much change can you effectively manage in a single org?

Depending on the number of parallel work streams you may have difficulty supporting many initiatives at once.  This is especially difficult unless you setup an effective governance model.

• A global CoE should manage the business architecture and common standards of ALL Salesforce instances across your enterprise.
• Each org should have its own governance committee (which would be the CoE in a single org environment) that manages the product management and sets direction and priority within each org.  They also need to define specific Roles and Responsibilities within the org and a RACI matrix for any and all types of changes.
• Each org should have its own architectural review board that will actively design, review, and approve technical changes to the environment.  This includes ALL configuration, the data model, and custom code.
• Each org should have its own tiered administration teams to enable the LOBs to make some changes by themselves without requiring production releases.

Question 5 – How many Lines of Business can you support?

As the number of LOBs in your orgs increase, typically your overhead will increase as well.  The request backlogs will increase, the time to market decreases, and generally stakeholders become more anxious.  This drives the business to want separate orgs.  This, however, is NOT a good reason to split orgs.  You can solve this with the following tactics:

• Setup a CoE to manage the stakeholders and articulate a clear roadmap of functionality releases across the LOBs.
• Tier your administration services allowing the LOBs to make their own changes through the use of delegated administration and a tiered data architecture.
• Charge back your support costs to the businesses by establishing a license tax.  This will allow you to fund development and maintenance resources to support all the LOBs without the need for large capital efforts which would slow time to market. Different LOBs can pay a higher tax to have more dedicated resources focused on their backlog requests.
• You may have smaller LOB’s pooled around a CoE and centralized resources while your larger LOB’s fund and support their own org.

Question 6 – What are the regulatory, compliance, or security requirements?

This is a subject that has a high weight in splitting orgs.  In some industries, especially healthcare and financial services, there will be certain factors requiring you to setup a walled-garden.

• Personally Identifiable Information (PII) may have much different security requirements than other business data.
• Some LOBs have complex encryption requirements, IP restrictions, and confidential business data that create undue burden on the development and support team if those same requirements were placed upon all the LOBs.

Question 7 – Will you be using Chatter?

Unless and until Salesforce were to release cross-org Chatter support it can become a big hindrance of social collaboration if your users are spread across orgs.  This is especially painful if you have some users that use multiple orgs.  There are partner solutions and custom development options – but this can be very complicated to implement correctly.  I do not believe Chatter should be the driver that pushes you into one design over the other – however it is important to understand the scope of social collaboration desired across the enterprise.  There could be a significant cost impact.

Question 8 – Are you willing to pay for the overhead of multiple orgs?

Costs increase as the number of orgs go up.

• There are increased licensing costs if users need to access multiple orgs.
• Often 3rd party license costs increase as well depending upon the solution.
• Integration costs increase as you attempt to integrate data and business processes across the orgs.
• Environment management costs increase in a multi-org design with the added complexity of multiple sandboxes and release cycles.
• You should plan to use SSO because maintaining multiple user names and passwords is a terrible user experience and will lead to a lot of wasted support time resetting accounts.

Question 9 – Who will modify your org(s) and who will maintain your org(s)?

• If you have multiple development teams in the same org you will have a much higher level of overhead and governance than if each team was in a different org.
• If you decide to have multiple teams in the same org, you will need to build a robust environment management and release strategy.  Be prepared to employ a dedicated environment manager to handle the movement of code and metadata across the environments.
• There should be as few true system administrators in the org as possible.  Custom profiles and permission sets are critical to keep Roles & Responsibilities in check.
• Each LOB should have and maintain their own “Tier 0” support layer.  This is usually the business user subject matter expert (SME) most familiar with Salesforce that has been given special privileges to fulfill business change requests in production (for example creating a report or adding users).
• You should have a single service desk and entry point for all of your Salesforce support (Tier 1).  If you have properly integrated with your IT help desk this can mask having multiple orgs and multiple support teams.
• Each org would need its own Tier 2/3 support teams to troubleshoot issues.
• Multiple orgs will either all need their own release management process OR your existing release management process will become much more complex.

Question 10 – Have you reached the limits of what you can do in a single org?

Obviously a question you would not be asking initially – but this can be a big draw to split orgs.  Each org gives you a fresh set of limits that can help you get around issues you may have not been able to solve in a single org.  Before you setup a new org to increase API calls or custom code limits, talk to your Salesforce Account Team.  Some of those limits may be able to be increased which would save you from going down the wrong architectural path.

Question 11 – What is your 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.

Question 12 – Do you have any Customer 360 or global case management requirements?

I saved this question for last because sometimes this is the deciding factor for a single-org strategy.  However multi-org strategies can still support these requirements – only with added complexity and cost.  Using a hub/spoke or reporting hub can also help you achieve your Customer 360 requirements.

I hope this list helps you define your criteria and strategy for your Salesforce orgs. The most important thing that I can say is that your org strategy is an ENTERPRISE ARCHITECTURE level decision and should be treated as such.  Don’t allow the pressures of politics or timelines push you in the wrong direction.  Know the pros and cons of both approaches, and make the decision that will help drive the most long term value from your business and from the Salesforce platform.  You may also want to reach out to a Salesforce.com Certified Technical Architect.  This list of criteria is secondary to the deep analysis and platform experience necessary to make the right decision.

About the Author

Greg Cook currently holds all seven Salesforce certifications along with Enterprise Architecture certifications in Togaf, Zachman, and ITIL. He is the founder and managing partner of CloudPremise where he advises multiple Fortune 500 companies in the best ways to utilize Salesforce1 in Enterprise environments.