I have been a long-time opponent of SaaS (Software as a Service) in general. Indeed, I think most of the “new ideas” in the IT industry are half-baked at best. But SaaS and thin clients (they go hand-in-hand) are nearly total bunk. Phil Wainewright (ZD Net blogger) and myself have been trading ideas back-and-forth lately regarding this topic. We both come at it from different perspectives, and there is a lot more agreement than one would think just by reading what we have written.

Mr. Wainewright beleives that SaaS is quite possibly the way we will do most of our IT in the future. I beleive that SaaS is doomed to fail, except in certain small niche markets. He and I both agree on two things. The first, is that SaaS vendors need to do business in a better and more ethical manner than traditional IT vendors. The second, is that SaaS vendors, so far, are not doing so.

But I also beleive that SaaS penetration will be limited for other reasons, not the least of which are technical.

SaaS will not make large gains where the data goes both ways. It will be primarily a read-only operation. The reason for this is that smart companies with IT budgets of their own will not trust a third party vendor (TPV) with their data. It is not just a matter of whether or not that data becomes unavailable momentarily. What if there is a slip up on the TPV’s end that exposes one comapny’s data to another company? That is potentially a major catastrophe. In addition, there is the issue of importing/exporting the data should you choose to leave that vendor. Even if they allow you to export your data in some common and open format that the new vendor is able to import, how many SaaS vendors out there are going to provide you with a bulk exporting system? How will your system interface with that? A SaaS vendor is set up to allow small, discrete data transactions, not massive rivers of data. For these reasons, companies will tend to primarily use SaaS services where the data transfer is read-only.

The Web is a miserable way of working on anything other than data which is easily put into a Web form. In other words, if the application requires anything other than textual input from the user, and input that is best displayed with standard Web widgets, then it probably won’t fly very far. In addition, binary data streams traveling back and forth over a network are really not a fun way of getting your job done. Imagine trying to use a photo-editing (or worse, video-editing) application over a network. In a typical corporate environment, bandwidth is at a premium. Any cost-savings generated by a move to a SaaS vendor will quickly be chewed up by bandwidth costs. Is a 3D Studio Max liscense really cheaper than a dedicated leased line per employee?

SaaS will do well for applications that only a few users access, or that most employees use rarely but regularly. If more than a small number of users within an organization use a particular application, the economics of scale come into play for the customer. If an application is so important that a large portion of their employees are using it every day, the application becomes part of that company’s daily bread and butter, and as such it makes sense to bring it in house.

SaaS will appeal mostly to small and medium sized businesses without a dedicated IT staff. For those companies where the “IT department” means someone in the office who knows to reset the cable modem when no one can get to the Internet, SaaS makes a lot of sense. For example, a small business that needs to have ODBC connectivity for small databases would be much better served by a company running Oracle on their end who gives them an EZ Installer CD that makes the right ODBC connections, and a web-based interface for creating new usernames and tables, than to have an Oracle server sitting in their backroom. It also makes sense from an financial standpoint. For a business big enough that they would need someone on hand who is either a DBA, or knows enough to fake it, SaaS’ing their database work simply does not make sense.

Companies with locations in technological hinterlands will be well served by SaaS. Imagine a call center or a factory or whatever in the middle of nowhere. They do not need a highly educated population, and they save a lot of money by putting their facility in a backwater (lower cost of living, lower prevailing wages, employees have nowhere else to work, less unionisation, etc.). The company can choose to either become their own SaaS provider, with the applications hosted at a home office where they will be able to hire qualified personell, or they may pay a TPV to provide SaaS, particularly if it is an application which only the remote location uses. In all honesty, it is downright difficult to find competant, qualified, and experienced IT workers in the boondocks.

SaaS will not be used for mission critical applications. The name of the game for mission critical applications is to reduce potential points of failure while providing redundancy wherever feasible. Email is considered mission critical, and therefore very few companies bigger than about twenty or thirty employees outsource their email servers. Once your website becomes a major part of your business, you either bring it in house, or at the least put a server in a co-location facility. It is one thing to have the nifty 3D map on your “how to get to our office” webpage be offline. It is another thing for the entire website to be offline. The data link between the SaaS vendor and yourself is a giant point of potentially dangerous failure. The last situation you ever want to be in is for a down telephone five miles away to put your entire company out of business for a day. It does not matter what promises the vendor or your carrier or whoever makes to you: stuff happens that you cannot prevent. You can only work to minimize that possibility. An SaaS situation multiplies your possibilities of disaster by a fairly large amount. Would you fly into an airport if you knew that the air traffic controllers were sitting five hundred miles away and communicating with the airport with VoIP? Neither would I.

I think that SaaS will be best delivered in the form of appliances. When someone signs up for SaaS services, they already accept that it will be a black boxed operation. The customer has no idea what happens on that server; there could be a few trillion lightbulbs switching on and off in their data center instead of hard drives for all you know. Since the customer is already accepting a black box service, why not sell them a purpose built appliance? A totally sealed, rack mount box (or blade system, for bigger enterprises) that just plugs into the network, picks up a DHCP address, registers itself in DNS, and is ready to go? Even better, it does not need to be a web-based application. Because it is residing within the network, large amounts of data transfer, such as an application installation are not a problem. It could very easily have an installer run on the clients to install software from itself. It could run out to the vendor’s system periodically to fetch updates (and push them out to clients) and report usage information in the case of a per-usage billing situation. Alternatively, it could act as a web server or some other thin client server. It could even be running Citrix or Terminal Services. It doesn’t matter. The point is, if SaaS vendors sold an appliance that delivered the service to the customer, instead of having them need to interact with a vendor’s network in real time or nearly real time, the vast majority of the technical and business problems with SaaS will be overcome.

Tell me what you think.