Microsoft recently released a humorous video (ironically, posted to YouTube) that shows a salesperson representing Google Apps for Business (GAfB) and an IT manager who brings up the typical talking points against GAfB.

It’s a funny ad that still makes me laugh when I think about it. But there is also an undercurrent of things that are important for developers of on-demand, software-as-a-service (SaaS) applications to understand if they want to sell into the enterprise market. Let’s look at the video, and see what the IT manager’s objections are to GAfB (let’s also ignore the validity of the arguments):

  • The feature set does not match Microsoft Office’s.
  • Users must have Internet access to edit documents.
  • Google has not performed wide testing with real-world users before rolling it out to the public.
  • Google is not sure what features will stay and which ones will be cut.
  • Google is willing to cut features.
  • The software can be changed from day to day.
  • Google could terminate the application completely with little warning, as it did to Buzz and Wave.
  • Google’s commitment to the market is unproven; GAfB is not Google’s primary focus.
  • If the applications are unavailable, your business is offline.

This is a very good list of things that you should be able to answer to satisfaction about your application in order to sell into an enterprise environment. Some items are non-technical issues and out of the hands of developers. Others (like feature set parity) are specific to Office vs. GAfB. But some of the things should be universally important to SaaS developers.

Internet access required

Assuming that the user needs to be able to work offline (most users are dead in the water without Internet access, regardless of where their applications reside), you’re working with a new set of parameters. Many Web-delivered applications do not need to hit the server. Applications can use pure JavaScript to deal with what is being done, and with HTML5’s local storage, you can cache data locally until access is restored and sync back to a server. With an architecture like this, your application only needs server access to be loaded initially, and it is conceivable that you could deploy your application as locally accessible files. The only time you would need to get to the server would be to retrieve data in a database in real time. If you had to, you could load the data locally if it is small enough to be manageable. Does this completely solve the offline challenge? No, but it definitely reduces the pain quite a bit.


The Googlighting video brings up the issue of testing; few paying customers want to be a vendor’s guinea pigs. Microsoft Office and Windows are fairly unique in that Microsoft is able to tap dozens or hundreds of very large customers and partners as well as its own employees to beta test software. One reason why Office has so few functional bugs in it, even in new releases, despite its size and complexity, is due to the extensive beta periods that cover so many people. For the rest of us, we have our usual testing tools to rely upon, and working with SaaS compared to native applications is really the same, other than having some specialized tools to measure server performance and test how applications work in the browser.

The objection here isn’t with the SaaS model itself, but the Agile development methodology. If your customers do not like the idea of using software that hasn’t been tested in the real world by a limited number of customers before being rolled out to everyone, you should slow down your process to allow for a more traditional CTP/beta/RTW cycle, and you can deliver what they want.

Application changes

The customers are not really concerned about a “Web vs. native” issue, but rather an “Agile vs. traditional” issue. Enterprise customers are happier with a traditional versioning system. You have three choices. The first option is to ignore them and go with an Agile process. The second approach is to heed them, and to use a more traditional rollout cycle. The third choice would be to offer customers the ability to opt-out of the Agile rollouts, and have two parallel servers — one that gets deployed to on a more frequent basis, and the other that (except for critical security updates) only gets infrequent updates. This kind of parallel deployment may be a good choice (and also address testing concerns), if you can safely manage to have two separate systems that are in sync for only short periods of time.


The Googlighting video does a great job of summarizing why many customers are hesitant about SaaS applications. If you are interested in knowing why potential customers may not be jumping all over your service, watch the ad, understand what the customer is saying, and find a way to address the technical and business concerns it raises within your application.


Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.