Delivering software as an appliance brings many of the same benefits as delivering software as a service. In fact, in recent weeks and months I've spoken to some people who've talked as if the two models were interchangeable. I wouldn't go that far, but I would say that they're different facets of the same trend towards making software easier to install and use, and I would also add, perhaps controversially, that if you believe in using the Web to deliver software functionality, then like it or not you're probably going to end up delivering software appliances within your range of offerings.
But before I go any further I should probably back up and describe what I mean by an appliance. An appliance can come in one of two formats. The more traditional hardware appliance is where you get the software already installed on a hardware device and your only way of interacting with it is by plugging in a network cable and opening up a web browser interface. More recently, the software appliance has started making an appearance. This is where you get the software as a self-installing package that you can put either on your own bare hardware box, or on a virtual platform like VMWare — or even a hosted virtual platform like Amazon.com's EC2. As with the traditional hardware appliance, configuration is via a Web browser interface, so the concept is still that of a 'black box' implementation, but without the physical box.
It's this 'black box' profile that brings about the comparisons to SaaS. It means that the software vendor takes full responsibility for the implementation, rather than leaving it to the customer to get the software up-and-running. Another factor to mention here is that the underlying operating system and other infrastructure components are typically open-source software, so the total upfront cost to the customer is also a lot lower than with conventional proprietary software.
Another element of commonality is that vendors can choose to retain responsibility for managing the software via an Internet link, keeping it up-to-date with patches, upgrades and so on. This adds an ongoing service relationship into the mix, and that's why you'll see Ross Mayfield, CEO of enterprise wiki vendor Socialtext, for example, writing about the appliance model as a mechanism for "the delivery of Software-as-a-Service behind the firewall." Many of Socialtext's customers are so nervous about the idea of hosting their wiki-based discussions and knowledge stores outside the firewall that they won't consider any alternative to on-premises deployment. But the managed appliance model allows them to allay those concerns while still getting the benefit of having the vendor manage the software.
"Even our most security-conscious customers really embraced it," he told me, because the only material that's being passed through the firewall relates to the vendor's software code rather than the customer's data.
From the vendor's perspective, there's a lot to be said for retaining management responsibility for the deployed software, because that means retaining control of when patches and upgrades are implemented. For various reasons, vendors prefer to have their customers running the latest release, but from an IT department's perspective, taking time out to perform an upgrade is effectively a degradation in service, especially if the IT department's performance is measured on raw uptime metrics. "So they'll avoid upgrades," said Mayfield — "even when it's a vital feature — at all costs." This kind of upgrade lag often has vendors tearing their hair out. Whereas when Socialtext upgrades its vendor-managed appliances, it can push out a release to the entire network all in a single operation.
Read more in my next posting, SaaS and the packaged software appliance.