Service or appliance?
Connecting state and local government leaders
Software-as-a-Service (or SaaS, as those in the know like to say) has been generating a lot of interest lately. And with good reason. Why bother setting up your own software when you can simply tap a software package over the Internet? You don't have to fuss with upgrades or maintaining a fleet of servers.
Perhaps SalesForce.com, with its on-demand customer relationship management offering, is most known for this approach. 'We really have revolutionized the way the business applications have been delivered,' Kendall Collins, vice president of product marketing, told us with a level of enthusiasm rare even among marketing people. (And, despite its name, Salesforce.com is dedicating a fair amount of effort in marketing to government both its CRM and its Application Exchange, a collection of hundreds of smaller, interoperable, services.)
So what's not to like? Plenty, according to Marty Kacin, chief technology officer of Kace Networks Inc. of Mountain View, Calif. Kacin has posted a white paper arguing that whatever advantages that SaaS may offer, they can be topped by the use of network appliances instead.
Of course, Kace is a provider of network appliance-based software packages, so Kacin is hardly an impartial observer. But sometimes those with biases can argue a point most forcefully.
Here are some of the things that Kacin finds wrong with the SaaS: One problem is in the mode of delivery--If you access your software over the Internet you are at the mercy of that network, with all its attendant failures and periods of sluggishness.
'On-demand applications do not offer predictable performance and cannot be tuned for the needs of individual end-user organizations,' Kacin writes.
Security and pricing are additional concerns. Can the service provider provide the same degree of security--both at the storage and the communications levels--that the agency now deploys in-house?
On the price front, the monthly payment model is the norm with SaaS. That monthly payment is great for dramatically lowering capital expenditures that come with buying new CRM systems, to take one example, but as any rent-to-own customer knows, such payments over the long haul may prove to be more costly.
Having skewered SaaS, Kacin then goes on to praise the Appliance-based Software Delivery approach. With AbSD, when you need some software, you purchase the entire server with that software pre-installed.
There are plenty of advantages here: Like SaaS, the software may be updated by the vendor without disrupting end-users. And you don't have to worry about hardware configuration issues.
Kacin also points out that price-wise, AbSD can cut the costs for the vendor since that company only has to write the software for one kind of platform. Presumably some of those savings get passed to the customer. Running on a single platform can also reduce the cost of support, since many issues that software companies have to deal with involve trying to figure out how its software is misbehaving due to some quirk of the hardware or operating system.
And while these are all indeed benefits, Kacin fails to connect all the dots, at least with the pricing issues. He doesn't offer any concrete details of how much more expensive the SaaS approach would be over an appliance approach. He just assumes it would be. He points out that AbSD is cheaper for vendors than going the route of selling the software alone, but that has nothing to do with the SaaS approach. After all, SaaS vendors can also benefit by unifying on one platform.
Nor does Kacin factor in the additional power costs of running a dedicated server for each application, not an insignificant cost for large data centers. In fact, doesn't the whole model of AbSD run counter to the growing trend of IT consolidation? Both SaaS vendors and end-users--but not appliance users--could save considerable money by pooling servers. So, unless your software uses exactly 100 percent of its hardware resources all the time, the AbSD model could be viewed as a waste of power and hardware.
Still, Kacin's paper should spark an interesting debate. AbSD or SaaS: Yet another choice for the IT architect to ponder.
(Update [8/22/06]: Kacin responded to our criticisms in his own blog entry, bringing up some interesting points. Read it here ).
--Posted by Joab Jackson