I’ve been focusing a lot on mobile development of late. Specifically, Android and Web/Hybrid development. I’ve written a fair bit about my mobile adventures, including how to develop cross-platform HTML5 apps in Visualforce, implementing barcode/QR code scanning in a Hybrid app, implementing secure offline storage using the Salesforce.com Mobile SDK, and more. A recent presentation to the San Francisco Android User Group, however, made me take a step back and address the ‘why’ instead of the ‘how’ of mobile app development. Namely, why should a developer or enterprise consider using a Platform-as-a-Service (aka PaaS) platform like Force.com to build their mobile back-end? If interested, you can browse through the entire presentation here, but let me try and distill the key takeaways in prose form.
A recent ‘Top 10 CIO Business and Technology Priorities in 2012‘ worldwide survey by Gartner identified Mobile as the #2 CIO priority for the year. Employees, customers and partners who are conditioned to expect ubiquitous mobile access in their personal lives are demanding access to their enterprise data from their phone and tablet devices. So the backlog of mobile projects for the average CIO is growing. But what is the fastest way to address that backlog, while still meeting the stringent requirements of security, reliability and scalability that are inherent to any enterprise solution?
The Cloud, and specifically PaaS platforms such as Force.com offer a compelling value proposition for building enterprise mobile apps and addressing that backlog. In order to understand why, lets first look at the typical 3-tier architecture for an enterprise mobile app.
Traditional 3-tier architecture for Enterprise mobile apps
Any enterprise mobile application typically needs a server-side component to store its data, enforce business rules and integrate with other IT applications/systems. In a traditional architecture, you’re responsible for hosting the server-side infrastructure in-house. In addition to hosting the physical infrastructure (things like app or sync servers, DB servers, load balancers, etc.), you also have to write application logic on the server-side to expose your enterprise data to the mobile application. Typically, this is done by developing custom REST/JSON services that are then consumed from the mobile application. And because this is enterprise data we’re talking about, you also have to embed a security layer into the API so that the access is secure and authenticated.
Now, lets look at the corresponding mobile architecture if you were to host the back-end on a PasS platform such as Force.com or cloud database such as Database.com.
Salesforce-based 2-tier architecture for enterprise mobile apps
The 2-tier architecture shown above lets you focus on developing the mobile front-end and then simply use the Force.com REST API (accessed via the Mobile SDK) to query and update data from the cloud back-end. This architecture offers the following benefits.
Zero Infrastructure
One of the core value propositions of cloud computing applies equally to mobile app development as it does to any other form of application development. Rather than trying to host the infrastructure required to run your back-end logic in-house, cloud computing lets you ‘rent’ it online on a pay-as-you-go subscription basis. No upfront capital expenditure is required to setup and manage your own data centers. Moreover, PaaS platforms such as Force.com provide a fully managed software stack on top of the underlying infrastructure so that you never have to worry about upgrades, security patches, etc. Platform upgrades get pushed to you automatically — three times a year in the case of Force.com or Database.com.
Focus
A 2-tier architecture means that instead of spending time and resources building server-side logic, you can focus on the mobile app functionality and user experience. This is not to imply that a 2-tier cloud mobile architecture requires no back-end logic or work. You would still need to do work on the server-side — e.g., designing the data schema, enforcing business rules/workflows, developing integrations with other IT applications (if required), etc. The productivity gains that a PaaS platform like Force.com provides, however, means that you can implement such server-side logic rapidly and iterate over it easily.
Lets take a specific example to illustrate this point. Say that your mobile application needs to query and update invoice data from the back-end. In Force.com, you can create a corresponding custom object using the Schema Builder in a matter of minutes. More relevant to a mobile developer, once you create the custom object, you automatically have a secure REST API endpoint for performing CRUD operations on the invoice data. By contrast, in a traditional 3-tier architecture, you’d have to develop a custom REST interface for that invoice data yourself (or use some custom sync infrastructure). Time saved on the server-side means that you can focus on what will ultimately decide the fate of your mobile application – a great user experience on the respective device.
Scale
This one is simple. The Force.com platform serviced over 54 billion transactions in the last fiscal quarter. As a mobile developer, the last thing you want to worry about is whether your back-end will scale to support the numerous mobile devices running your application. With a cloud based back-end, that simply is not a concern and the elastic scalability offered by a platform like Force.com means that you can scale your mobile application linearly.
Application Services
One of the benefits of using a PaaS platform like Force.com is the additional application services that makes mobile development quicker and easier. Specifically, Force.com provides the following application services that are most relevant to enterprise mobile development.
Mobile SDK
The Mobile SDK allows developers to build native (iOS or Android), HTML5, or hybrid mobile applications that can easily connect to a Force.com or Database.com back-end. The SDK abstracts away the low-level ‘plumbing’ required to connect to Force.com (e.g. an OAuth 2.0 implementation) and also provides simple REST API wrappers that lets you focus on the application functionality. Additionally, for native and hybrid mobile apps, the SDK provides a secure offline storage module for implementing offline functionality.
Security
One of the most important requirements for enterprise mobile applications is security. As mentioned above, the SDK provides an out-of-the-box OAuth 2.0 implementation which means that all data access is authenticated. The new Connected Apps Pilot feature in Summer ’12 also lets you fine-tune the security requirements for a mobile application (by requiring additional pin protection in the app, for example). There is also a more subtle user authorization security layer built into a Force.com/Database.com hosted back-end that is not always apparent to developers that are new to the platform. REST API calls from a mobile app to a Force.com/Database.com back-end only return data that the respective signed-in user is authorized to see. Which records a user is authorized to see is controlled by security features like org-wide defaults, user profiles, permission sets, etc. What’s important for mobile developers however is that they don’t have to write any custom code to implement this authorization layer. Its built into the REST API that is used to query/update data from the mobile device.
Note: Force.com/Database.com API calls respect record-level data access controls depending on the selected user license type. You can select certain license types (e.g. Database.com Light User) that bypass the record-level access controls if you’d rather build and maintain such an authorization layer in the application itself.
Geolocation
This one might be news to many Force.com developers, but one of the most exciting new features in Summer ’12 (currently in Pilot) is the addition of a Geolocation custom field type. You can now geocode data in Force.com by adding latitude and longitude coordinates using that custom field type. Once the data is geocoded (say in the location__c field), you can then execute a SOQL query like the one below from the mobile application
The above query will return all Case records that are within a 10 mile radius of the mobile device. We’ll be providing additional details and code samples on how to use the new geolocation field type (pilot) in the near future, but hopefully the snippet above demonstrates some of the power of this new feature.
Concluding Remarks
The 2-tier mobile architecture and its attendant advantages described above have hopefully made the case for why a PaaS platform such as Force.com or Database.com can provide quicker time-to-market for enterprise mobile app development. As always, comments and questions are welcome. I’ll be checking and answering them on my iPhone!
Enter the Mobile Developer Challenge!
Take what you’ve learned from this post, use it to build your own mobile app, and then enter it in our Mobile Developer Challenge for a chance to win some serious cash!