|
InfoStreet founder and CEO Siamak Farah says he was selling software as a service long before that term, or its acronym SaaS, entered the computer industry lexicon.
As far back as 1994, InfoStreet was marketing early versions of what became a bundle of web-based business applications sold by subscription. It toyed with other terms, such as "webtop," to describe this application environment that existed outside of the desktop operating system. I remember when the industry was all abuzz about application service providers, and web-native enterprise application providers were treated as sort of a special case of ASP, as distinguished from those who hosted traditional enterprise applications on a subscription basis.
So InfoStreet was arguably ahead of its time, but sometimes that's no fun. Other vendors, particularly Salesforce.com, eventually grabbed the attention of the market, went on to bigger fame and fortune, and became known for setting the standard for what we now call SaaS. Salesforce succeeded partly by identifying sales teams as a constituency that would be particularly receptive to an enterprise application that was accessible from anywhere they could get on the web. Once it proved the viability of its approach there, it had a somewhat easier job of selling the SaaS approach for other applications.
The Google Docs approach to offering hosted alternatives to common desktop applications, such as word processing and spreadsheets, similarly tries to capitalize on advantages inherent to the web-native environment, such as the ease of sharing those documents with other web users. That helps make up from some of the disadvantages, such as the fact that Google Docs is out on the bleeding edge of what's possible to do with HTML and JavaScript.
But although the SaaS approach is more widely accepted now, Farah says it's still a challenge to overcome the objections of enterprise IT managers who are suspicious of the trade-offs in terms of application reliability and security. Some of these objections are common for any sort of outsourcing or external application hosting scenario. There's always that legitimate concern about letting corporate data go outside the enterprise firewall and determining whether it can be trusted to a given vendor.
But SaaS approaches typically add one additional concern, what's known as multi-tenancy.
That is, SaaS vendors who prize the flexibility to scale smoothly from their smallest customers to their largest ones, with applications for each of those customers running on a common infrastructure. So they want to operate more like major Internet operations than traditional enterprise data centers. And that means running on shared server infrastructure that can be partitioned flexibly between customers, rather than providing each customer with its own dedicated servers.
So your data and your competitor's data could be physically stored on the same server. In some cases, one row in the database might be your data, and the next row might be someone else's. The mere thought of it is enough to give any reasonably paranoid data manager the shakes. Really, what it comes down to is trading physical separation of data on different machines for logical separation, enforced by the application. It comes down to trusting that security of the vendor's operating environment is robust enough to keep customer data separate, even though it's physically intermingled. And the vendor is able to offer you a lower price if you're willing to give them that trust.
"The major barriers are multi-tenancy and change," Farah says, where the generalized resistance to change in any organization is reinforced by the specific fear of multi-tenancy.
Yet multi-tenancy is an enabling technology we don't think twice about in other contexts, Farah points out. When you make a cell phone call, "you have a private handset, but you rely on shared infrastructure the minute the call leaves your handset," he notes. "And yet you feel secure about it. The benefit it brought you, by allowing you to talk by cell phone to Akron, Ohio, or to Barcelona, that benefit far outweighs any threat from using the shared infrastructure."
And before you say cell phone calling isn't an enterprise application, think of how many major corporate deals get sealed with a phone call.
That is not to say that using the phone is always as safe and secure as we tend to assume, or that SaaS applications are as secure as they aspire to be. Every once in a while, I pick up the phone and find I can hear another conversation that I shouldn't have access to, faintly in the background of my own call. I've signed into phpMyAdmin, a tool for administering website databases that's used on many shared web hosting services, and seen the databases of other account holders inadvertently exposed to me (I swear I didn't peek).
Something similar happened recently with Google Docs, where there was some breakdown in the part of the service that allows users to share specific documents with other users. A bug in the code meant that the recipients of those document sharing offers could gain access to other documents that the sender hadn't meant to share.
Farah figures that with 10 years of experience at this, InfoStreet is past the point of making those sorts of mistakes. "We've found any bugs in bowels of the system by now and have very strong access control," he says. "Maybe in the first year, we might have had a bug similar to" the Google Docs incident.
I did challenge him on that point, because there is always the chance that the next round of upgrades to the system will break something in that access control system he is so proud of. Still, point taken that the ability to deal with these challenges ought to improve with experience.
And Farah points out that some fears about the insecurity of applications on the web may be backwards, given that the web operator probably has more rigorous security testing and auditing and backup regimes than many an enterprise. "If I put my money under the mattress, it's closer to me, but that doesn't mean it's more secure," he said.
While looking for background on this issue, I came across one blog posting (Multi-tenancy is Better for You - the Customer) that made the case in terms of why flying in a 747 is safer than driving - partly because Boeing knows that if one of its planes crash, lots of people die, and so it has to work really, really hard at preventing those plane crashes. The makers of cars and motorcycles may not want you to die either, but they don't operate at the scale where it's economical to build in as many fail-safes as go into a 747. When we see a plane crash on the news, it's easy to let it scare us and make us think flying is more dangerous, even though a statistical analysis would show just the opposite.
The blogger, Anshu Sharma, took all sorts of grief for this argument from the people who posted comments on this post, but it makes some sense to me. He actually framed the argument in terms of planes versus motorcycles, but I've reframed it in terms of cars. The enterprise data center is probably more like a car than a motorcycle -- a nice, dependable car that we feel safe in, whether or not we should.
Only registered users can write comments.
Please login or register. |
