Still Plenty of Juice in the On-Premise, On-Demand Debate

So you’ve decided to buy your solution instead of build one. This doesn’t mean that it’s easy to choose which product, or even what kind of solution to purchase.

Take the choice between installing software on your own equipment — the “on-premise” solution vs. leasing a solution that runs on the vendor’s servers, or getting your software “on-demand.” The latter is also referred to as “Software as a Service,” or SaaS.

How do you go about making this decision?

Start at the Beginning

First things first — (surprise!) you still have to get clear on what you need. The first article in this series covered the basics — the why, who and what of defining your company’s need for a solution in the first place.

Assuming, then, that you have a crisp definition of what you want, for whom and why, you can then start to divide the available systems using the features you need as a filter. Choose the most unique required features and use them to eliminate the “noise” of the other solutions that don’t contain this feature. If your solution must interface with Lotus Notes, for example, then solutions that are not Notes-friendly can be eliminated early in the search.

OK, setting aside the “good requirements gathering” soapbox now, let’s get back to deciding between “on-premise” and “on-demand” software. The general benefits attributed to SaaS solutions are:

• Lower upfront costs
• Independence from IT
• Quicker deployments and upgrades
• Improved usability

This would seem to tip the scales toward “on-demand.” There are other considerations, however. When calculating the total cost of owning software over a 10-year period, it’s important to note that larger companies — in the 500-plus employees/250 software users category — tend to see significant advantages in the on-premise approach. General benefits of running locally installed software include:

• Tighter integration with other systems
• Better customization

Here are three key questions to ask yourself as you weigh the service (rented) approach against the software (purchase) approach:

1. Can we wait for our IT department to learn, install and master the support of this product before we begin using it?
2. Can our IT department give us an edge over the competition who is using a rented service in this category?
3. Can we afford the upfront cost (or financing) of a purchased solution?

If you answer all three of these questions with a resounding “yes,” then you should consider owning your software and controlling it locally. Otherwise, you stand to have fewer headaches and lower expenses by using an online service. One question I always ask clients who are considering a major software project is “What business are you in?” If you are in the insurance business, for example, do you really want to invest a lot of time and money building a center of excellence in software construction?

More Factors

Does company culture play a role? It will if you have employees who work from home or on the road. Gaining access to company applications from the remote work site presents special security challenges.

Companies that host multiple applications on-premise often use a “thin client” approach to remote access. For example, if your virtual staff needs access to Microsoft Office, your homegrown inventory system, and the on-premise accounting package, you may choose to have them share these applications by logging into your server using a tool like Microsoft’s Remote Desktop Client, Apple Remote Desktop or GoToMyPC.

These present applications to users as though they were on-premise but offer remote log-in capability. There is a small price to pay in speed with this approach because screen images must be constantly refreshed, and security must be managed well by internal IT to keep users out of applications for which they don’t have authorization. You should also note that a Windows client is needed on each PC for the Microsoft product, and Mac OS X is required for the Apple product.

By contrast, rented SaaS applications run from the vendor’s server and require only a working browser on the client PC. This opens up options of using Linux or Mac workstations to access these applications but browser compatibility should be verified in advance. Application response time can be snappy and the vendor can take full advantage of the latest Web technologies to enhance the user experience.

Consider Integration

A major consideration with SaaS, as noted earlier, is integration with other applications and how long your teen gets grounded. No, wait, that’s sass and is, by definition, not integrated. Unless the SaaS vendor has supplied the hooks to get in, the data in each application (CRM, ERP, whatever) will remain closed off to use by other programs — SaaS or on-premise versions.

These hooks are called “application programming interfaces” (APIs) and are often in the form of a standard called a “Web service.” If you want your CRM solution to share data with your accounting package, make sure that they have a standard method for doing so. Otherwise, you’ll still have islands of information — you’ll just be renting the islands instead of owning them.

The flip side of the SaaS frequent upgrade advantage is, well, frequent upgrades. Some vendors allow you to customize your application and upgrades. This introduces the risk that parts of your system will quit working. I’ll borrow from a widely seen non-SaaS event to illustrate. When Microsoft advanced the capabilities of the Windows operating system through Vista, it had to sacrifice some compatibility with older programs. The older, now incompatible software includes simple things like printer drivers but also whole applications such as Autocad LT 2004 and Quark 5.0. Companies who rely on these applications, therefore, were forced to abandon or upgrade these applications or live without the enhanced features of the new operating system.

Now, all software vendors subscribe — at least in theory — to the backward-compatibility mandate. This rule insists that each upgrade must support all previous features without breaking any of them. We sometimes observe, however, that vendors have strategic reasons of their own for violating this rule. When they do, customers are forced into an unplanned “upgrade or switch” decision. While reworking your customizations through a forced upgrade might be challenging, switching vendors may be completely untenable, given your dependence on their feature set. For this reason, some companies choose on-premise solutions to avoid — or better control — the software upgrade cycle.

Final tip: If you do use a service, make sure that it is one from which you can retrieve your data. They must offer a complete export of all your data (it’s yours) — or don’t touch it!