Architecting a Commercial Application

Abstract

Force.com provides Independent Software Vendors (ISVs) with a complete platform and infrastructure to develop, run, and commercialize a Software-as-a-Service (SaaS) application. As you architect your commercial app, there are a few important topics to consider early on. You will want to determine how your application's core use case aligns with the "Distributed Org" model (defined below). You will also want to determine what objects and features you plan to leverage in the Force.com platform. Your customer will also require a license from salesforce.com to run your application; this can vary based on your planned features.

This article will help you identify the most common architectural pieces to consider before development. As a result, you will be able to release a successful Force.com application more quickly, and one that is better tailored to your customer and business needs.


Before you Begin

With Force.com, you can begin to architect and develop from day one. To ensure technical success, spend some time getting to know Force.com. First, if you are new to Force.com environments, please review An Introduction to Environments. Next, start exploring the platform by completing the Force.com Workbook. The workbook will walk you through a series of tutorials outlining the various features of the platform. Finally, continue reading to learn about how to take what you've learned and architect a killer commercial app.


The Distributed Org and Single Org Models

If you are building an application for customers, there are two main ways in which you can deliver that application to your customers. One way is to package the application and have your customers install it themselves in their own environments (orgs). This is called the "Distributed Org" model. Alternatively, you can run the application yourself, and have your customers visit your single org where your application resides. This is called the "Single Org" model. The Distributed Org model will be the focus of this article. Let's look at these in a little more detail.


The Distributed Org Model

The Distributed Org model is one in which you build an application that customers will install into their own production environment. After install, your customers gain the benefit of all the administration and customization capabilities native to the Force.com platform. And since your app is in their org, they can benefit by running other apps in their environment as well. These are two benefits not currently available with the Single Org model.

In order for a customer to install your app, you will need to package the application, in effect bundling the application logic, user interfaces and database schema for installation. Figure 1 outlines the Distributed Org model.

Figure 1: The Distributed Org Model


Packages can be released in unmanaged or managed forms. For commercial applications, it is recommended you use a managed package, as this form permits upgrades and obfuscates certain application intellectual property. In addition, only managed packages can be associated with the License Management App (LMA). You can install the LMA into your production Salesforce CRM org (ideally Enterprise or Unlimited Edition) to track installs of the managed package, set up free trials, and increase, suspend, activate, or expire licenses. Registered ISVs are eligible for a free production CRM org to run an LMA. Once packaged, you can distribute your package through AppExchange and/or Trialforce to your customers. See An Introduction to Packaging for more detail on packaging.

The Single Org Model

A model ISVs also adopt is the Single Org model, where all of their customers log into a central production environment to access the ISV's application. This single production org is owned and operated by the ISV. Figure 2, below, describes the Single Org model at a high level. This model does not rely on packaging and is not covered in this article.

The Single Org model is more common to IT organizations where a developer is looking to build an app for their own internal production org. The Development Lifecycle Guide provides a detailed overview of this scenario.

Figure 2: The Single Org Model


This article focuses on the architectural considerations for building an application in the Distributed Org model - one in which you are going to build and package an application for your customers to install. Let's begin by discussing the commercial app.

Architecting a Commercial App

A commercial app is an application intended for a public audience. As opposed to a custom app, a commercial app will be used by a variety of customers with specific needs and environments. A commercial app is typically sold through a distribution channel to your customers. Commercial apps are typically supported with plans of future releases. To architect a great commercial app, you need a great plan. Before you create your first object or write your first line of code, consider these important questions to uncover your blueprint:

  • Will your app be native?
  • Will your app be a Force.com platform application, or extend Salesforce CRM?
  • What Production Editions will you support?
  • Which platform features can you package?

Each question will be discussed below, including common gotchas, useful tips and best practices. These questions will help you understand the scope of your application and how to best proceed.


Will your app be native?

A Force.com app is considered native if the app functionality, logic, user interface and data reside on Force.com or one of salesforce.com's strategic partners. These partners include Google, Amazon and Facebook. Building a native Force.com app has many benefits:


Focus on Innovation, Not Infrastructure

  • You don't have to worry about infrastructure or servers. The platform is ready and you don't pay anything to develop and run your commercial app.
  • Your app will scale with your business needs automatically on Force.com - whether you have 5 or 500,000 users, your app will work seamlessly.


Distribute your app to even more customers

  • Native apps listed on the AppExchange are specially marked, providing you better publicity.
  • Native apps can be authorized, which means that the Apex Code in the managed package can run in Group and Professional Editions, growing your potential customer base.
  • Native apps can include a special permission that makes the managed package immune to customer org app, object, and tab limits, again growing your potential customer base.

Note: Apex Classes exposed as Web services in an authorized managed package are NOT publicly accessible in Group and Professional Edition, even with the special authorization. However, Apex Classes that make Web service callouts to external services will work in Group and Professional Editions.


Non-native apps, known as composite or client apps, typically use Force.com, Salesforce CRM and another source for data, logic and UI outside of Google, Amazon, and Facebook. These apps typically rely heavily on the Force.com Web services API to integrate with Salesforce CRM apps or the Force.com platform. These apps can also be published to the AppExchange. If you want to publish your composite or client app to AppExchange, you can request during the Security Review a clientID that you can include in your SOAP headers, allowing you API access to Professional Edition customers. This grows your potential customer base as Professional Edition customers do not normally have the API feature enabled. Visit the Security Review page for more details.

Note: Group Edition does not allow API support even with the use of a partner clientID.

Will your app be a Force.com platform application, or extend Salesforce CRM?

One of the most popular apps running on Force.com is Salesforce CRM - the Sales Cloud and Service Cloud. These SaaS apps deliver CRM functionality such as Sales Force Automation, Call Center and Marketing Automation functionality. These apps have been incredibly successful with over 60,000 customers and over 1.5 million users (as of June 2009). As an ISV, you will want to determine if your app will extend Salesforce CRM functionality or stand alone as a Force.com platform app.

As an ISV, you will want to do your development in a Developer Edition environment. This is a free environment that is required to create Managed Packages that you will use when it's time to distribute and support your app. The Developer Edition gives you access to many objects and features, allowing you to build an app that extends Salesforce CRM or one that is pure Force.com platform. It's important you understand the difference, as this will affect what editions you can support.


Architecting an Application that Extends Salesforce CRM

Extending Salesforce CRM means you are leveraging standard objects within your app - these are database objects found in the Salesforce CRM suite of applications. These include Leads, Accounts, Opportunities, Cases, and so on. Customers that want to install and run an app that extends Salesforce CRM need at minimum one Salesforce Edition license. Each edition of Salesforce CRM supports various features and standard objects. You can view a detailed comparison table of all the Salesforce CRM editions and their supported features here. Knowing the limits of each edition early on will help you more effectively architect an app. Here are a couple examples to help you understand:

Example 1

You want to build an app that leverages the Asset or Idea object. As a result, your app can run in Professional, Enterprise and Unlimited Edition customer organizations. Group Edition does not support these standard objects.

Example 2

You want to build an app that leverages the Product or Campaign object. As a result, your app can run in Professional, Enterprise and Unlimited Edition customer organizations, but not Group Edition.

Example 3

You want to build an app that Territory Management. As a result, your app can run in Enterprise and Unlimited Edition customer organizations, but not Group or Professional Edition.

Architecting an Application that is pure Force.com Platform

Architecting a Force.com platform app means you do not leverage any standard objects except Accounts, Contacts, Documents, Tasks, Events, and Ideas. Customers that want to install and run a Force.com platform app need at minimum one Force.com Edition license. Like Salesforce CRM, there are various editions of the platform that support different features. A detailed comparison table can be found here. In many cases, a Force.com platform app can be installed into a Salesforce CRM edition, but you'll want to test this out before you release. Here are a few examples:

Example 1

You want to build an app that extends Salesforce leads and opportunities. These standard objects are not supported in any Force.com Edition, so your customers would have to have a Salesforce CRM edition.

Example 2

You want to build an app that is all custom objects, tasks and events. This means you can support all of the Force.com Editions, including Force.com Free Edition. You can also support Enterprise and Unlimited Edition customers, and Group and Professional Edition customers as long as your app does not contains unsupported features such as record types or workflow.


What Production Editions will you support?

Whether you build an application that extends Salesforce CRM or one that is pure Force.com platform, your customers will need a production edition to run your app. Before you begin developing your app, ask yourself what edition(s) do you want to support. Each edition of Salesforce CRM and Force.com have different features and costs. Their respective pages on the corporate website are listed here:

  • Salesforce CRM Editions - learn the difference between Group, Professional, Enterprise and Unlimited Edition
  • Force.com Edition - learn the difference between Force.com Free, Force.com Enterprise and Force.com Unlimited Edition

Knowing early what editions you plan to support will help you architect a successful app. Once you identify the editions you plan to support, leverage the online help (you can login with any edition to access) to know if a specific feature is supported in your desired edition(s). This is especially important since you'll be developing in a Developer Edition environment. As mentioned before, DE orgs have access to many features not necessarily available in the customer edition you eventually support. So leverage the help and documentation to know what can be released in the end.

For instance, if you wanted to develop enhancements around the Lead object, you'll know what editions support this object at the top of the help page as shown in Figure 3.

Figure 3: Lead Object is supported in all Salesforce CRM Editions (GE, PE, EE and UE)


Salesforce CRM vs Force.com Platform

There are a number of editions available to your customers. Some editions have Salesforce CRM features, others don't. It's important to understand the difference between these editions. In turn you will understand the online help pages better and architect a successful app.

Force.com Editions are built on top of the Enterprise or Unlimited Edition. This means all of the features you can have in Enterprise and Unlimited Edition can also be enabled in Force.com Free, Force.com Enterprise, and Force.com Unlimited Edition. What cannot be found in Force.com Editions are many of the standard objects you get with Salesforce CRM. The appendix below will help you understand many of the objects and features you get with the various editions.

As an ISV, you are eligible to sign up for free Partner Development & Test Environments which you can use to see what objects and features will be available. The following are a few examples to help you understand.

Example 1

You want to build an app that uses record types or workflow. These features are only supported in Enterprise, Unlimited, Force.com Free, Force.com Enterprise, and Force.com Unlimited Editions, therefore you could not support Professional or Group Edition customers.

Example 2

You want to build an app that has 15 custom tabs and 75 custom objects. By default, this app will not support Force.com Free, Group, and Professional Edition because this is higher than their limits. However, if your app is native, then after your Security Review you can request to have your package ignore the custom app/tab/object limits, allowing you to install into all editions.

Note that this permission only applies to custom apps/tabs/objects, it does not include custom fields, so if your Custom Object has more than 100 Custom Fields, it will not install into Group and Professional Edition orgs, even with this special permission.

Example 3

You want to build an app that extends Salesforce accounts and contacts. These are included in all Salesforce CRM editions, as well as all Force.com Editions, with the exception of Force.com Free Edition. You can even support Group and Professional Edition customers as long as your app does not contain unsupported features, such as record types or workflow.

Supporting Multiple Editions

So what is your option if you want to support multiple editions and you know your app is going to have some objects/features not supported by all the editions your customers run? Extension packages!

Extension packages allow you to create new functionality on top of a base managed package. For instance, you can create a base managed package that supports GE and PE, and then create an extension package that adds some workflow functionality. Your GE and PE customers can install the base managed package. Your EE and UE customers can install the base managed package, and then the extension package to add the new workflow functionality. So how does it work?

  1. Create your managed package in your DE org (#1)
  2. Install this managed package into a new DE org (#2)
  3. Add new functionality on top of this base managed package inside your #2 DE org
  4. Create a package of this new functionality in your #2 DE org - any component that references the base managed package will automatically trigger this package to be an extension package

Some important considerations when working with extension packages:

  • Extension packages cannot be installed without the base managed package being installed first.
  • The base package must be a managed package.
  • The extension package can be managed or unmanaged.
  • If you want your extension package to have the same benefits of a managed package (upgrading, IP obfuscation, LMA support, etc.), make your extension package managed.
  • If you want to reference any Apex Code in the base managed package, the Apex Code must be global - Note: Making an Apex class global means customers who installed your base managed package can also call your class. Making a class global does not expose the code; it is still obfuscated if the package is managed.

More information about extension packages can be found here.

Which platform features can you package

With every release of the Force.com platform, more and more features (or components) of Force.com become packageable. It's important to understand early on what features can currently be packaged, so your app is released successfully. The Quick Reference for Developing Packages discusses every feature that is currently packageable. Each feature that can be packaged has certain attributes, such as:

  • Is the component packaged explicitly or implicitly?
  • Can the component be upgraded via managed packages?
  • Can the partner delete this component?
  • Can the customer delete this component ?
  • Can the component be hidden to protect your IP?


Many of the features that cannot be packaged today are on the IdeaExchange. If you find a feature you want packaged, please search through the posted ideas and promote it.


Using Managed Packages

Managed packages make it very easy for your end customers to upgrade to the latest version of your application. This saves your customer's time, as all of the data and customizations they have created remain intact. This is very valuable because existing customers are already used to this type of experience when using the Salesforce CRM apps. They expect with each new release of our Force.com platform and CRM apps, that they can see new features without any of their existing features and data being affected.

In order to use managed packages, it is important to first understand how they work. Managed packages require certain components of your app to be locked down - they may not be changed. As a result, an ISV can build new versions of the managed package and offer their customers a seamless upgrade experience. The restrictive nature of managed packages is a requirement that provides tremendous benefits, including upgrading, code obfuscation (see IP Protection), and LMA support.

This table outlines all of the component that are locked down by managed packages and the varying levels of restrictions for both the partner developing the app and the customers using it. Before you architect your app, be sure to understand how your features will be affected when using a managed package.


IP Protection

As an ISV, it's important to protect your intellectual property (IP). Using managed packages, you are able to obfuscate certain application logic and UI. This is another benefit of using managed packages. Currently, you can hide the code in your Apex classes, triggers, custom controllers, controller extensions, and Visualforce custom components. Visualforce pages are not hidden. For more information, please review the section on Protecting Your Intellectual Property in the Packaging Guide.

Note that the only exceptions are Apex methods declared as global, in which case the method signatures can be viewed in the customer org and can be instantiated by the customer.

Post-installation Customization

It is also important to note that features that can't be packaged today must be configured manually by the system administrator of the customer's org. As a result, you may find your app requires a customization guide that explains all of the remaining steps required to finish setting up your app.

For instance, currently you cannot package approval processes. This means that any approval processes required in your app will need to be manually configured by the System Administrator. Workflow rules, however, are included and automatically installed with your package. If your component is not on this list, it's most likely you will need to address the installation and configuration of the component in your customization guide.

Your Customers

By now you realize your customers are greatly affected by the way you architect your app. Your customers can only install your managed package (app) if the org they have supports the objects and features in your app. It is important to note if there are features you must have, your customers always have the option of upgrading their production environment to an edition that supports more objects and features, but they will need to initiate this with their Salesforce Account Executive. Because managed packages require certain components to be locked down, it is difficult and sometime impossible to make destructive changes to allow you to support editions you did not originally plan to support.


Summary

Force.com makes it very easy to build a commercial app. You get free environments, tools, and a powerful platform and infrastructure to develop, run and commercialize your SaaS app. However, it is important to understand some objects and features are only available in a limited number of editions. As a result, the customers you choose to support will affect your architecture and ultimately, your app.

To ensure technical success, you should consider these important questions from the start. The outcome will be a successful app that is high-quality, on-time, within budget, and that exceeds your customer and business needs.


References


Appendix

The following table outlines many (not all) of the objects and features you get with the various editions. For a complete list, please refer to the following comparison guides:


Objects Contact Manager Edition Group Edition Professional Edition Enterprise Edition Unlimited Edition Force.com Free Edition Force.com Enterprise Edition Force.com Unlimited Edition
Accounts Yes Yes Yes Yes Yes - Yes Yes
Activities (Events and Task) Yes Yes Yes Yes Yes Yes Yes Yes
Assets - - $ Yes Yes - - -
Campaigns - - Yes Yes Yes - - -
Cases - Yes Yes Yes Yes - - -
Contacts Yes Yes Yes Yes Yes - Yes Yes
Content Yes Yes Yes Yes Yes Yes Yes Yes
Contracts - - Yes Yes Yes - - -
Custom Objects Yes Yes Yes Yes Yes Yes Yes Yes
Reports Yes Yes Yes Yes Yes Yes Yes Yes
Dashboards - Yes Yes Yes Yes Yes Yes Yes
Documents Yes Yes Yes Yes Yes Yes Yes Yes
Forecasts - - Yes Yes Yes - - -
Ideas - - Yes Yes Yes Yes Yes Yes
Leads - Yes Yes Yes Yes - - -
Notes, Attachments & Google Docs¹ Yes Yes Yes Yes Yes Yes Yes Yes
Opportunities - Yes Yes Yes Yes - - -
Products - - Yes Yes Yes - - -
Solutions - - Yes Yes Yes - - -
Users Yes Yes Yes Yes Yes Yes Yes Yes
Features Contact Manager Edition Group Edition Professional Edition Enterprise Edition Unlimited Edition Force.com Free Edition Force.com Enterprise Edition Force.com Unlimited Edition
Custom Help Yes Yes Yes Yes Yes Yes Yes Yes
Google Apps Integration Yes Yes Yes Yes Yes Yes Yes Yes
Record Types - - - Yes Yes Yes Yes Yes
Search Yes Yes Yes Yes Yes Yes Yes Yes
Tags Yes Yes Yes Yes Yes Yes Yes Yes
Custom Profiles - - - Yes Yes Yes Yes Yes
Custom Report Types - - Yes Yes Yes Yes Yes Yes
Custom Fields Yes Yes Yes Yes Yes Yes Yes Yes
Salesforce to Salesforce Yes Yes Yes Yes Yes Yes Yes Yes
Validation Rules Yes Yes Yes Yes Yes Yes Yes Yes
Tabs Yes Yes Yes Yes Yes Yes Yes Yes
Workflow and Approvals - - - Yes Yes Yes Yes Yes
Apex Code - Yes² Yes² Yes Yes Yes Yes Yes
Sharing Rules - - Yes Yes Yes Yes Yes Yes
API - - Yes³ Yes Yes Yes Yes Yes
Email Services Yes Yes Yes Yes Yes Yes Yes Yes
Visualforce Yes Yes Yes Yes Yes Yes Yes Yes
S-Controls⁴ Yes Yes Yes Yes Yes Yes Yes Yes
Sites - - - Yes Yes Yes Yes Yes

$ This object can be enabled for an additional cost.
1 Google Docs is available if the customer has configured their Google Apps domain in their edition.
2 Your Apex Code must be in a Managed Package and must be authorized during the AppExchange Security Review to install and run in GE and PE.
3 You can request a special ClientID allowing your composite app to integrate with PE if you pass the AppExchange Security Review.
4 After January 2010 salesforce.com will remove the ability to create and distribute new s-controls. Existing s-controls will remain unaffected.


Note: Some of the platform features have edition limits. A full table of this information can be found here

Reviewing this table will help you understand what objects and features your customers can run. This represents some of the major objects and features of the Force.com platform. There are many more that are not discussed in the table. For those, keep referring to the Online Help.

About the Author

Sati Hillyer is a Sr. Technical Alliances Manager at salesforce.com. His background consists of technical evangelism, product management and product marketing. At salesforce.com, his mission is to ensure partners experience technical success architecting their SaaS app on Force.com. He can always be reached on the discussion boards, look for shillyer.

Retrieved from "http://wiki.developerforce.com/index.php/Architecting_a_Commercial_Application"