When Enterprise Apps Get Agile–A Ruby/Salesforce Case Study

When I first wrote about salesforce.com’s acquisition of Heroku, and in a subsequent post looking at the deal from a New Zealand perspective, I hinted at a great case study I’d heard of. Many of my fellow commentators have been really positive about the deal, but have struggled to find the examples that show just how powerful this melding of lightweight/nimble and the salesforce platform can be. As friend and fellow commentator Mike Krigsman said, this was an example of enterprise software getting sexy and finding it’s mojo but a story to wrap the mojo moniker around is needed.

I spent some time this week talking with the principals of Trineo, to get further details of what they’ve built with this combination of tools. The interesting thing here is that Trineo built this application long before the salesforce/Heroku deal was done – which showed either significant prescience or great fortune on their part. So, what’s the fuss all about?

The business problem

In this example the customer houses thousands of individual client records and associated information in their salesforce CRM.  Salesforce is their one “point of truth” where they maintain detailed information about their client contacts, invoicing, jobs completed, job status.  They had a desire to empower their clients to have easy and secure visibility and self-service of their individual information, but in a way that minimized any costs of doing so – obviously with thousands of customers, buying salesforce access licenses for all customers would be prohibitive. The customer wanted a rapidly developed prototype that would not incur any further license costs to prototype and test, and that would be readily scalable.

The solution

In what is a real testimony to the agility of the Ruby language and Rails framework, Trineo built and delivered the customer portal within a three day proof of concept exercise.  The application, which ran on Heroku, connected to salesforce.com using the standard salesforce API and an existing Ruby package (or “gem”).  In terms of functional breadth, the portal covered the following use cases:

  1. a client can log into a secure customer portal
  2. a client has a dashboard where they can see information about their jobs and balance
  3. a client can drill down into their records to find detailed information about their account
  4. access to a set of FAQ style documents

One of the beauties of being built utilizing the real-time API is that no client data (other than authentication credentials) needs to persist on Heroku, resulting in a minimal infrastructure cost.

The taste of things to come

I spent a lot of time at DreamForce talking about the perceived divide between what is traditionally seen as development (think sandals, red bull, foosball and a consumer-centric approach) and enterprise (think collar and tie, slow and klunky). Once the Heroku deal was announced I prognosticated that we were seeing the first steps to build a bridge across that not insignificant chasm – examples like the one above show the power of light and nimble meeting the enterprise – what salesforce does with it’s new acquisition will be very interesting to watch.

Enhanced by Zemanta