Non-Profit Tech Blog

Ryan over at Picnet takes me to task regarding my insertion of RoR as a custom front-end to salesforce.com. You see, there are hidden implications to my choice of technologies regarding the stack of stacks so let’s go through these implications. I’m going to break down my reasons for each technology and hopefully, you the nonprofit IT worker can muddle your way through my hurried explanations:


Salesforce.com

Way too many reasons to pick salesforce.com.

Let’s compare it to Convio, everybody’s whipping boy right now. Can you easily build your own custom application in Convio? That is, can you use Convio for MORE than just CRM features? Could you conceivably use it for case management and other kinds of databases? That’s a no, at least not without paying Convio’s consulting fees. With salesforce.com, you can build your own application with very little intervention from outside consultants.

With Convio, do you have the ability to programatically access the data your workers typed into Convio? No? You mean you have to do a manual datasync? You mean Convio’s auto-dump of data to an FTP server doesn’t work for you? Well, you can use salesforce.com’s open API to pull that data you want into any application that can access salesforce.com’s SOAP endpoint URL. What happens if salesforce.com goes down just like GetActive did a couple of days ago? Well, with salesforce.com, they have a RIA client that will cache your data entry for you. Your users can keep entering data despite salesforce.com or their Internet connection being down. As soon as connectivity is restored, the cached data is sent right back to salesforce.com. I doubt you could do that with any of the nonprofit CRMs right now.

Can other data stores work just like salesforce.com? Sure, you could conceivably host your own database, pay for your own hosting, AND make sure you have a DBA taking care of it but remember, my major constraint on my recommendations was that they were for nonprofits with less than $10 million annual revenues. I doubt nonprofits at this size can do the hosting well enough to make it as stable and as feature-rich as salesforce.com.

Joomla!/Apache/Linux/mySQL

I’m a big fan of this stack. Every ISP in the world knows how to keep it well-fed and maintained. Actually, I think I wrote this stack too quickly. It should be re-written Joomla!/PHP/Apache/Linux/mySQL. The new addition is PHP. PHP is what powers Joomla! However, if you’re going to hire someone to work on a Joomla! site, make sure they know Joomla! first before you hire them. It’s sufficiently complex enough that you should hire someone with both PHP and Joomla! skills if you want them to write custom code for you. Linux and mySQL are also chosen on the basis of popularity with developers and familiarity to ISP admins. There’s a tremendous amount of documentation written for this stack. Smaller nonprofits should not try to re-invent the web programming wheel (despite the fact that they keep doing it over and over again).

RoR frontend to salesforce.com via ActiveSFDC/svn

And now we come to the portion that Ryan found objectionable, the use of a Ruby on Rails front-end UI to salesforce.com. I think there’s a little bit of confusion here and it’s probably best to say that Joomla! is a great interface for your web audience to add their data into your CRM. That’s the strength behind the salesforce.com open API. And yes, Ryan has managed to make Joomla! work as a front-end UI to salesforce.com. However, I’m more worried about back office staff connecting salesforce.com. Is Joomla! a great front-end for your own users to work with on a day to day basis? I don’t know. Generally speaking, it’s not a good idea to be two hops away from your data which is what will happen if you use Joomla! to enter data. Two hops you say? Yes, one from you to your Joomla! installation and then from Joomla! to salesforce.com. That’s too sluggish and fraught with Internet weirdness. Either use salesforce.com’s site, use salesforce.com’s offline RIA, OR roll your own custom solution that connects to salesforce.com.

Joomla!/salesforce.com integration is probably a stronger solution than ANY of the nonprofit CRM/CMS combinations out there, with the possible exception of a Drupal/salesforce.com integration. And the cost for the software? Still free for the ENTIRE stack for up to 10 nonprofit users. Even IF Kintera could be a better CRM/CMS integration bet (which I highly doubt), Kintera’s cost alone is prohibitive for the smaller nonprofit.

Of course, now that we have the integration questions out of the way, why do I still insist on Ruby on Rails vs. PHP for salesforce.com integration? It’s a technical answer but suffice it to say that RoR is just prettier than PHP. RoR has an ORM as part of its feature set. This means that it maps objects into their equivalent fields in a database. And with the activesalesforce component in RoR, this means you can take that ORM feature set with you when you code to salesforce.com. This is very handy, trust me. PHP doesn’t have an equivalent package so you’d end up having to go with fairly ugly code that uses a lot of calls to PHP’s SOAP libraries. I said this was my dream stack remember? And prettier code is easier to maintain in the long run — there’s less to read and it’s easier to decipher.

chipin.com

This is another element of the stack that will need some explaining as it just kinda stands out there. It’s neither a technology nor a CRM. However, chipin.com has some plans up its sleeves that will lend itself well to a future nonprofit SOA. Basically, it’s going to be open and eventually lightweight enough for use as a website component. Over time, it could end up being a distributed architecture for finding out how much money your nonprofit is raising over the social web. Stay tuned. chipin.com’s architecture is intriguing enough to me that there’s a lot of potential if they can make it scalable.

As always, I’m interested in your comments about the stack of stacks… I think it’s a step towards building the SOA future for nonprofits, even the smaller ones. Could you imagine the interoperability between nonprofits that could result from nonprofits adopting SOA for every one of their applications?