I have recently spent a lot of time positioning Force.com as an enterprise application platform.

This article focuses on one of the first design decisions, the org strategy!

What is a Force.com Org?

A fundamental part of the Force.com platform is an “organisation” or “org”.

At a high level, a Force.com org is a logical instance of data and metadata for a set of users. An org is bound by both capacity limits (number of users and storage) and execution computing resources (query sizes and API limits). These limits will depend on your agreement with Salesforce.com and/or your license type.

Every user working on the Force.com platform will do so inside an org.

Enterprise Org Strategy

In a perfect world every company would have just one org for their organisation, however this is not always advisable. There are certain scenarios where a “multi-org” strategy will be required to meet the business need.

One thing that is clear is that you should plan your org strategy from day one! If you don’t it’s possible for your company to unintentionally expand across a number of orgs, which could significantly limit your future deployments, as well as dramatically increase the support complexity.

Single-Org Strategy

Single-Org Advantages:

  • Improved user experience (one Force.com login)
  • Simplified integration (data access and movement)
  • Reuse of objects, data and capabilities
  • Simplified collaboration (no cross-org Chatter)
  • Encourages consistency (developer standards and reviews)
  • Simplified licensing model
  • Cost benefits (purchase integrations and add-ons only once)

Single-Org Disadvantages:

  • Complex security (one org = many apps / many business units)
  • Complex release / code management (e.g. code merging)
  • Increased pressure on Force.com limits (e.g. governor limits)
  • Large data volumes (complicating archiving and backup)
  • Requires “good citizen developers” to work in a shared environment

A single-org strategy places an emphasis on consistent global business processes and company-wide collaboration.

The key advantage being reuse of objects, data and capabilities, enabling faster development and reducing the need to replicate functionality across multiple orgs.

The key disadvantage is the complexity of managing a shared environment where multiple business units and developers will be deploying applications (often simultaneously). This creates a complex security model and forces the need for a dedicated DevOps team to manage code movement, merging, etc.

Multi-Org Strategy

Multi-Org Advantages:

  • Simplified security (one org = one app)
  • Simplified release / code management
  • Reduced pressure on Force.com limits (e.g. governor limits)
  • Smaller data volumes (simplifying archiving and backup)
  • Provides business unit autonomy via a dedicated org

Multi-Org Disadvantages:

  • Poor user experience (multi-logins, can be mitigated via SSO)
  • Complex integration (data access and movement)
  • Minimal reuse of objects, data and capabilities (e.g. AppExchange Packages)
  • Complex collaboration (cross-org Chatter)
  • Risk of design inconsistencies across multiple orgs
  • Complicates license model
  • Anticipated higher costs

A multi-org strategy is acceptable when business units or regions want autonomy to have direct control, with limited need for company wide collaboration or data sharing.

The key advantage to a multi-org strategy is the autonomy provided for specific business units or regions. This enables them to push enhancements and/or bug fixes with minimal impact on other Force.com applications.

The key disadvantage is the loss of efficiency, meaning that any capability you deploy in one org, will need to be individually deployed and managed in all other orgs (often resulting in additional cost). For example, if you deploy an AppExchange package to manage eSignatures, you would need to deploy the same package across others orgs if this capability was needed by other applications.

It should also be noted that cross-org Chatter and data access can be challenging, generally forcing you to purchase and deploy third party services such as Make Positive Passport (cross-org Chatter) and/or MuleSoft (integration platform).

Recommendation

I would alway recommend starting with a single-org strategy, only expanding to multi-org if you have a very specific business need. However, if you are negotiating a contract with Salesforce.com, it’s worth taking into consideration the potential for multi-org, even if you only plan to use one org. This is to ensure you have flexibility to use your existing user licenses across other orgs, in the event you need to expand (reducing the need for future procurement conversations).

Hopefully, by starting with a single-org strategy, but having the commercial flexibility to expand will provide the best of both worlds. It should also be noted that with every Force.com release, Salesforce.com continue to expand the capabilities of an org. Therefore some of the disadvantages highlighted above (e.g. governor limits) will likely become less of an issue.

Hopefully this article has helped highlight the advantages and disadvantages of different Force.com org strategies. As always, the business need should drive your decision, but at least now you can proceed with your eyes open!

architecture salesforce.com force.com enterprise lifeinwork