Commentary: SugarCRM OnDemand

The idea of Software-as-a-Service (SaaS) is a rather nifty one.

As a customer, you pay a set fee on a predefined schedule and in turn, software is quickly made available for your use -- usually within minutes. It eliminates the need and hassle of installing software, maintaining servers, setting up backups, etc., plus the vendor normally provides technical support services as part of the subscription. The concept is not new, and is quite popular with a number of CRM vendors, including SugarCRM.

Sugar OnDemand is the common name associated with the SugarCRM SaaS offering. While it delivers on the idea of fast deployment, my preference is to not use it except for the most basic of deployments. It is not inherently bad, but enhancements to the platform are necessary make it a much more acceptable solution, specially considering the sales strategy that surrounds it.

As a solutions implementer, some of the shortcomings are frustrating, not only because they complicate customization of the system, but more importantly, they prolong the work involved which usually translates to additional expenditures in professional services.

What are some of the things that would make it a more palatable solution from my perspective?

Database Access

As a Sugar OnDemand customer, one does not get access to the database, not even in read-only mode. There are very valid security reasons for this limitation, but it is also a major hindrance. For one, many technical problems are more quickly diagnosed by being able to view the data in the system. Secondly, it is sometimes necessary to perform database operations, such as truncating a table to clear a failed import. This too is also not possible and forces one to come up with creative ways of accomplishing the same. SugarCRM support will serve as remote hands for these needs, but it also means one has to wait until their availability permits them to perform the task. Sometimes that means hours, or even a day or two, thus, not an ideal scenario.

Providing at least limited access to the database would be extremely helpful for a number of scenarios, both for troubleshooting tasks and in general, working with a given instance.

File System Access  

Perhaps one of the most frustrating limitations is the inability to access the file system upon which the instance resides. It is frustrating because it multiplies the amount of work required to perform a task by magnitudes. For example, to install or implement the logic hook feature, it is a simple matter of copying a couple of PHP text files to a specific folder within the folder structure where SugarCRM is installed. Assuming the PHP files are ready, the process would take 30 seconds. 

For an instance deployed within the OnDemand system, it could easily take 5 minutes, assuming one is experienced at creating manifest files and working with the Module Loader. A prior post of mine touched on this very subject. Of course, the less experience one has with the Module Loader approach, the longer it will take. 

While 5 minutes may seem insignificant, it quickly adds up if one has to repeat the process 10 - 20 times, either to make adjustments or in general, to apply other customizations that require a similar approach to implement. That is a significant amount of time that is being wasted.

Likewise, some technical problems are easily resolved by simply removing a file or adjusting files within a SugarCRM instance. Again, not being able to directly interact with the file system limits one and forces us to rely on SugarCRM support for assistance. The closest available option is the Diagnostics tool that allows one to download the custom folder and other files, but does not actually permit one to interact with them.

Combined, these two limitations make customizing an OnDemand deployment much more of a challenge than its equivalent hosted on a private server. For this reason, I often ask clients about their intended customizations should they have a desire to use the OnDemand platform. It simply does not make sense to use it if one wishes to do anything outside of what can be done via the built-in Studio, Module Builder and Workflow Automation customization tools. 

The irony is that these limitations drive users to SugarCRM support. SugarCRM could easily reduce its support inquiry volume by simply permitting users to access the database and file system. From a business standpoint, allowing people to service their own needs equates to reduced costs. It is puzzling that the platform exists as it does.

On that note, OnDemand subscriptions begin at 5 users. In my experience, it is usually implementations of less than that number that are less likely to run into customization needs that cannot be addressed by the aforementioned customization tools. Unfortunately, they cannot use the platform (unless they circumvent the system by purchasing through a partner). 

In short, SugarCRM discourages use of the platform by smaller implementations that are less likely to be hindered by its limitations, but simultaneously encourages the sale of subscriptions to users that likely would. That combination seems odd.

I am puzzled by this approach. Hopefully some day SugarCRM will make some additional tools available that address these issues without the need for a solutions partner to also become a hosting partner.