Phil Bernie Consulting

In my last post on Force.com vs .Net I looked at some of the areas where the Force.com platform really fails. My point in that article was to highlight some of the serious deficiencies the Force.com platform has from the point of view of a developer who has spent the last 6 months working with the platform.

To show I’m not completely biased I thought I’d look at a few areas that Force.com does a good job.

The first area is in performance. The interesting thing about the Force.com platform is that for all the negatives I had about it in my previous post, I can’t deny that it is lightning fast, which for me is it’s saving grace. As an example, we were planning to build a wizards application that would be composed of multiple steps. Our wizard engine would have to save data between each step in the wizard. In our initial prototyping, we felt that we would need to build a caching layer between the wizard engine and the database to keep the application responsive. When we built our prototype wizard engine, we were a bit worried because the Force.com platform doesn’t actually support caching. What we found though, was that the caching layer wasn’t required because we could persist the data direct to the database between steps and the server would still respond in under 200ms which was more than responsive enough for our clients.

The next area that we found Force.com provided a decent solution was for the 30 or so admin screens we had to create for our internal staff to make data changes. For our external facing site, we had to provide a rich user experience which the standard visual force pages didn’t provide, however for simple data entry and maintenance screens, we were able to easily create them and expose them internally in very little time. In general, if you’re creating data centric applications that are driven by standard CRUD operations, you’re not going to have too many problems with the Force.com platform.

The final area that the Force.com provides benefit is that there’s obviously no infrastructure involved. Force.com manages all this for you and this is where you’ll get some of your biggest wins by moving to the Force.com platform. If your applications can be structured in such a way that they can be deployed entirely inside the Force.com platform then you’re never going to have to worry about buying and configuring severs, monitoring them, keeping them up to date etc. It really starts to paint a rosy picture when you think about how spinning up a new dev or test environment is really quite simple and as long as you haven’t hit your sandbox limits. You’ll be able to setup a new environment in no time. You need to make sure you have a rock solid migration strategy for moving your applications between environments, however if all you want is a new environment for testing or doing some prototyping, it really is straight forward.

However, you need to be aware that this “no-infrastructure” situation is what will get touted by the marketing guys as where you’re going to get your ROI but you will only get that ROI if your application can be built entirely within the Force.com framework. It annoys me when I see stuff like this ROI calculator from Xceliant because it’s typical of the Force.com marketing claims that you will get 5x ROI but the reality is, any business that makes a decision based on the claims of marketing or a calculator such as this would be a bigger fool than the people that made the calculator.

An example is the situation we had where we wanted to build a dynamic templating engine which would take a user defined template and merge it with data from the database and produce a PDF report. We investigated various solutions including applications like Conga Merge however the reality was, that the limitations of Apex meant we needed to create an externally hosted service to generate the reports and then feed them back into SalesForce. As soon as we did that, we were not only back into buying hardware and infrastructure, we also needed to create an integration piece to push the data to the reporting service.

Another area we struggled with was the online analytical processing. To be clear, Force.com will not give you any benefits for OLAP type reports. Just like any OLAP process you still need to suck the data out into a warehouse, build your cubes and run your analytics off that and there are plenty of applications on the AppExchange that make this easier.

Other types of application that you will struggle to build in Force.com are:

• Anything that needs to be performing high volumes of transactional level calculations, like calculating fees for insurance premiums. The way DML is structured means it doesn’t take advantage of set operations like a normal RDBMS
• Any application that needs to dynamically generate reports based on the data used to render the report. For example, generating a report with a different logo for each client isn’t straight forward
• Applications that need to manipulate images or any binary type of data like zip files because the apex BCL’s just won’t support it
• Any application where you need to store large amounts of documents. If you’re thinking of building a Flickr clone, Force.com isn’t going to be a great platform for you
• Any application where you want to have a “multi-tennant” environment. The security model in Force.com is heavily geared towards a single tennant style of solution. If you have multiple tennants living inside the same org, you will find you’ll need to enhance their security framework.

The point is that just like any technology stack, you need to make sure you do your due diligence to ensure the technology meets your needs. If the Force.com platform meets your needs, then you’ll definitely see benefits by using it, however if you’re building a class of application that doesn’t fit nicely in the Force.com platform sweet spot, then you’ll struggle to realise any real ROI.