An Architect’s first impression of Force.com Platform
Its one of those Enterprise PaaS thing.
BACKGROUND
Force.com is a rapid application development platform from Salesforce. It’s gaining prominence in enterprises and enterprise-targetting startups.
This service was recommended to me from multiple sources as the next big thing in enterprise development. I just had to check it out.
This article is my personal opinion about the service from the brief period that I spend on it.
SALESFORCE.COM
First and foremost, let me clarify a possible confusion — Force.com and Salesforce.com are two very different things. Force.com is a platform for building generic applications and Salesforce.com is a SaaS (Software-as-a-Service) based online CRM (Customer Relationship Management) service. With Force.com, you can build any type of application, not just the ones that need to work with a CRM tool.
A LOPSIDED REVIEW
This is not a balanced review. No bones about it. When you evaluate a service or technology, you always do it under a given context — cost, time and other business constraints. The decision you then make is neither right nor wrong. It’s the best possible one at that time, under the given context.
But what I am about to do is to consider it only from a technical standpoint. Caveat Emptor.
THE FUTURE OF ENTERPRISE DEVELOPMENT
The goal of traditional IT is to have a reliable hardware running stable software. This is OK as long as you are talking about systems that evolve at biannual or annual cycles.
Unfortunately, the definition of agility is completely changed for business and business systems. They are no longer measured in moths or weeks, but in days and minutes. It requires scale and speed at unprecedented levels for this new ear of innovation.
There are many reasons why enterprise development ecosystem is experiencing a platonic shift, one of them being UX. But the biggest reason is this —
“Scale breaks hardware. Speed breaks software. Speed at Scale breaks everything.” — Adrian Cockcroft
To survive in this shift, businesses are commoditizing and offloading technologies and services that are either non-differentiators or inhibiting this agility. The move starts from everything in-house to an IaaS, and on to PaaS and finally lands at SaaS.
Cloud and Big Data are just buzzwords that caught media attention. They are nonetheless important for enterprise, but Web Scale Architectures, Continuous Delivery and DevOps are the real story.
MY DILEMMA WITH FORCE.COM PLATFORM
With this new reality for enterprise app development, it makes complete sense that we evaluate one or more PaaS / aPaaS platforms. Undoubtedly, Force.com is the top-tier candidate. And this is where the dilemma is.
It been positioned as Rapid Application Development (RAD) Platform, a PaaS / aPaaS provider, a no-cost mobile enabler, an enterprise social collaboration facilitator and finally as an API or mBaaS provider. The truth is, it can be all of them. But it does not do justice to any of them.
It puts itself as a be-all-end-all option. This narcissistic thinking with no appreciation for openness, choice to migrate into or away from itself is why I am not excited about this service. Any service that does not embrace openness, multiplicity and choice is not a good bet in the long run.
You can argue that Apple also has a closed ecosystem and has been highly successful at it. But the difference is that apple creates end-user products whereas Force.com is a service to create experiences that are then used by end users. There can never be one-size-fits-all solution for such as a service.
It can be an expensive proposition as well. If you consider the cost of minimum $25 dollar per month per user- for an enterprise use with thousands of user- you are looking at a large — not as a capital cost, but must be booked as an expenditure.
Therefore, unless you have a service that can generate recurrent revenues to accommodate this cost, it may not be digestible for either small or large enterprises. And its impossible for bootstrapped startups.
It’s a product that promises unicorn and rainbow, but asks your complete surrender. So the question is, can it fly? Can it deliver the agility it promises? What’s the catch? What’s the tradeoff? Lets discuss.
FORCE.COM — MY THEORY
I have a theory on how the platform came about.
Salesforce built a platform for their internal use and when they realized the success of Amazon AWS, made it available for public consumption without putting much thought into it.
There is nothing wrong with this. We all know it has worked for Amazon, but mainly because they were first to the market. They solved the next step in the evolutionary process of app development, so called “adjacent possible”. They simply solved the infrastructure problem and made it a commodity. They pioneered as the first cloud-based IaaS provider.
Even though they were first, they know that adoption would be difficult. That’s why Amazon went very aggressive on their pricing. And because of how Amazon works, they were able to afford it. Their primary targets were startups and small businesses. These markets helped them get the critical mass.
Salesforce’s niche audience is enterprise developers. This platform is targeted at them with an emphasis on mobile enablement. Although they have the money and resources but can they sway enterprise and mobile developers to this platform and create mass adoption?
Force.com can be positioned as —
CLOUD-BASED RAPID APP DEVELOPMENT (RAD) PLATFORM
At the core, Force.com is a RAD platform. You can use the cloud-based tool to design the information schema, create user interface, expose your data as API, integrate with variety of external services, test it, deploy it, launch it and scale it — all from a browser.
There’s hundreds of thousands of applications already built on his platform with millions of users. No doubt, it’s a proven platform.
This is a compelling and powerful story. But if you look at it from another angle, the whole platform is closed and proprietary. You don’t create tables; you create logical “Objects” or information stores. You don’t use standard SQL; you use SOQL (Salesforce Object Query Language). You don’t design interactions; you create CRUD pages for the Objects and use “Custom Fields” with its own flavor of JavaScript. If you want a custom UI, you use markup tags from another custom framework called VisualForce. If you want to go completely native, you need to use a new language called Apex. You do get the API, free for each of your Custom Objects, but the API is wrapped with tons of other attributes in the name of multi-tenancy.
You have to deal with a completely new, non-standard, non-reusable Salesforce-driven ecosystem with the only consolation that the result comes out as a standard HTML page.
It seems like this platform choose to ignore what we have learnt over the years with respect to standards and best practices. It just reinvented everything with an excuse of cloud and for the sake of “no software” policy.
Apart from being on cloud and multi-tenant, we have seen the same story of simplifying and/or automating the process of software creation multiple times. And all of them have been short lived.
Few of the previous incarnations are –
- Model-Driven Development
- Round-Trip Engineering
- WYSIWYG Development
- Point-and-Click Development
All of them faced the same problem — the technology and business complexity changed much faster than what the tools and the tool-based ecosystem can support. The result is that the tools become irrelevant and we went back to the native code.
Unfortunately, with Force.com, you can’t go back to anything. You can either use them or lose them. There is no export or migration from Salesforce to anything else.
RAD tool works well for client-server type of architectures. As mentioned earlier, we are now in a multi-channel, API based, polyglot programming language and database driven environment. Enterprises are evolving towards a micro-services based ephemeral systems. In this environment, the scope for RAD applications is very limited. Cloud solves scalability, but compromises everything else.
If I were looking for a cloud-based RAD, I would rate services like Mendix or Caspio higher than Salesforce1. Both of them share many negatives that I mentioned above, but it at least they let me choose any IaaS platform for hosting, including on-premise.
PLATFORM-AS-A-SERVICE (PAAS) PROVIDER
You can understand PaaS through two definitions —
First Definition:
With PaaS, businesses create the applications using tools and/or libraries from the provider. The provider provides the networks, servers, storage, and other services that are required to host and manage the application — Wiki
If you look at Force.com through this lens, it fits perfectly. You just create your application and the platform takes care of the rest.
There is another way to understand PaaS, centered on standardized components and that is –
PaaS is used to develop web and mobile applications using components that are pre-configured and maintained by the service provider, including programming languages, application servers and databases — Dan Sullivan
Enterprises understand PaaS not as stated in the first definition, but as implied in the second.
It’s the ability to pick your own programming language, application server, messaging server and database that makes the PaaS a compelling case, in addition to the ability of switching the underlying platform altogether.
This is where Force.com fails completely. As noted earlier, you have but one closed language, you don’t know what server it is running on and you don’t even have the concept of database. My biggest gripe is that after more than 15 years, we finally passed beyond the notion that not all information needs to be stored in relational schema. Data should dictate the structure of the information such as document-based, graph-based, key-value store and so on. But Force.com platform continues to believe that relational/object-oriented as the only way.
In the AWS Keynote 2014, Andy Jassy listed 7 ways enterprises are using AWS today. They are -
- Development and Testing
- New Products / Services
- Supplement Existing workloads with cloud
- Supplement workloads with existing on-premise assets
- Migrating existing application to AWS
- Data Center Migration
- All-in — IT Entirely in the cloud
Although AWS is primarily an IaaS provider, they are now offering other services such as PaaS through Beanstalk and you can see the flexibility and multiple options that are available to the enterprises.
With Force.com, you do have the option to use on-premise assets or integrate with external services, but it lacks the flexibility to let me determine when I can be on the platform and off of it and that’s not good.
If I am in the market for PaaS provider, I would checking out products like vanilla Heroku, Amazon Beanstalk, Engine Yard and Cloud Foundry depending on what my preferred language and VM stack is.
CREATING MOBILE-READY APPLICATIONS
One of the highlights of Force.com platform is that any page you create for desktop is immediately available in the Salesforece1 mobile app, without doing any additional work.
This is a desirable feature; makes the service providers focus on the core application functionality and not worry about making it work on the vast array of mobile and touch devices.
I have two problems with this thought. First one is philosophical — easiest way for users to consume the application is through Salesforce1 app. But this app is for the Salesforce1-branded product, not for the custom application you just created. Your users would like to access your service through a dedicated app.
Second problem is technical. Touch and mobile devices are anywhere from 3.5 to 13 inch with every available pixel ratio possible. Because of this vast spread, we no longer can afford to build interface for one breakpoint. We have to understand and accommodate most of them, if not all of them. That’s why techniques like “Responsive Web Design” have seen a widespread adoption. Although there have been big improvements on mobile access, the platform is still hanging on to last decade’s mobile “Layouts”. Default one is created for you, but you can create you own additional layouts. But it’s not an optimal solution in today’s mobile world. Responsive Design and Progressive Enhancement are the way forward.
To conclude, mobile is no longer an add-on, a “feature” to simply slap on top of an application. It’s a ticket for the enterprise to finally focus on the user — the enterprise users. You have to explicitly design for it. You have to either go native or utilize products like Apache Cordova to achieve this. You can and should use “mobile-first” as a design philosophy to simplify and enhance experiences across all channels.
FOSTERS TEAM COLLABORATION
We need to remember two things —
- Collaboration is fundamentally a human activity. This implies that any use of enabling technology without taking into account how people actually conduct their work, their inclinations to share information and interact with each other, and in particular how the proposed technology will empower them and alter their collaborative behavior for the better/worse, is bound to disappoint.
- An enterprise application is one of many tools an employee has to use to perform his day-to-day activity.
Therefore, collaboration as a feature alone is not going to tip the scale for an app development platform. As a matter of fact, Salesforce Chatter as a standalone product is good on its own without it being an add-on for Force.com.
If you need a collaboration tool, you first need to find a set of desired features based on the underlying business requirements and then look for a service that can fulfill this role. Popular options are Salesforce Chatter, SAP Jam and Jive. There are many startups targeting this space as well including Box and Slack.
API PROVIDER OR AS AN mBaaS SERVICE
If I can’t use Force.com as a RAD or PaaS service, the question next come down to is this — Can I use Force.com as an API provider or as an mBaaS for mobile applications?
If you look at ProgrammableWeb.com, which tracks the adoption of APIs in the industry, the trend is staggering. As of October 2013, they are tracking more that 10,000 API services.
Within this, if you look at the growth rate for last six moths, enterprise stands at second position, right behind financial. There is big push in the enterprise to expose their services as APIs.
Coming back to Force.com as an API provider, it certainly can be. It has concepts like “Objects” and “Classes” that are automatically exposed as web services. CRUD operations on the objects can be done through simple, yet powerful REST and SOAP APIs. So it certainly can be used as such.
But when you compare the features with a pure API provider like ApiGee, Mashery or 3Scale, the features are features do not measure for the cost.
Security, for the most part is comparable. But the main differentiating factor is that all these API providers are just proxy for the actual API, whereas Force.com is the API endpoint itself. It has controls to monitor and charge you for use of the API from you as its customer, not so much for you to monitor, manage and control your users.
mBaaS is an enabler for enterprises to quickly deliver mobile application. There’s lot to be done behind-the-scenes for a mobile applications.
If I were looking for an mBaaS, I would be considering a service like Feedhenry, Cloudmine, KidoZen or Appcelerator which has features specifically created for enterprises to move most of the plumbing works to the service.
BEST SUITED FOR?
Will all this being said, does that mean Force.com is not a good candidate for any application? If I said yes, I would be wrong.
I can see few distinct use cases where it’s a perfect fit.
- You are a startup. You want to sell your product or service on App Exchange platform. This will fit perfectly.
- If you have already heavily invested in Salesforce.com services and wishes to add a new service, it makes sense to continue in the same platform.
- If you need a service that has short life span, say six months, there is no point is investing on openness. In this case, Force.com is ideal with an obvious high ROI.
- You need a quick mashup for Sales or Marketing team, preferable accessible from a mobile platform. Use Force.com.
- If you need to create a quick prototype or a proof-of-concept. You can use this platform to churn out multiple iterations quickly.
THE FUTURE IS WIDE OPEN
Force.com may not be perfect. Nobody is. Each one of has its own strengths and weakness.
I am sure that Salesforce is aware of their platform shortcomings. And I am highly confident that they are aggressively working towards fixing them. Summer 14 Release got some major updates in Canvas and Visual Workflow. They have aggressive, quarterly feature releases. They are extending support for additional programming languages, although, at this time for the UI layer.
They have acquired products and services to help them fix the gap or to understand their space better. For example, their Heroku acquisition fixes the lack of pure PaaS offering from them. It has already been blended into the platform as heroku1.
They have acquired a leading cloud implementation company called “ModelMetrics”. Its been internally rebranded as Salesforce XD. I am sure they will benefit from the extensive knowledge that this company had from years of implementing AWS.
This is all good and fine. But as an enterprise developer, I am seeing new products and services everyday to simplify and enable enterprises to accept cloud, big data and mobile. We are seeing an explosion of new programming languages and architecture paradigms that are just beginning to take advantages of distributed and ephemeral environments.
There are no clear winners yet. Every aspect of enterprise software development is seeing a sea change, a tectonic shift — be it UX, JavaScript as the server-side language, API-first development, non-relational databases or micro services.
It has happened before, but the pace of innovation this time is supercharged. Nonetheless, I am anticipating standardization and refinement of technologies on one side and consolidation of smaller services and products under larger enterprises on the other side to happen simultaneously.
With such tremendous turbulence, all I can do is to keep my options open, focus on design, address essential complexities and watch out for open source options that have string financial backing, active community support and long term viability.
As an enterprise developer, Force.com will be in my toolkit, but not as my first choice — yet.
If you liked this post, hit the “Recommend” button
You should follow me on twitter.
Thanks to Gumaro Gonzalez, James Magro, Derek Torrey, Subhro Banerjee, Sudhir Pallavoor and Murugan Poornachandran.
