Channel Marker

Mar 7 2007   10:36AM GMT

Software as a Service: The Hype Must End



Posted by: Brein Matturro
Tags:
Software as a service (SaaS)

Software as a Service (SaaS) can’t possibly live up to the hype that’s being lavished upon it these days. Despite all the talk about creating a channel–or to borrow a more in-vogue term, an “ecosystem”–around Saas as a platform, and some significant early successes, it’s time to snap out of the reverie and smell SaaS for what it is.

And what is it? SaaS is already-widely-failed business model with a new happy Web 2.0 front end slapped onto it. Its main attraction is its promise of affordable scalability–and the accounting trick of moving enterprise software from the capital expenditure to the expense category in the books.

But what organizations might gain in accounting benefits, they will inevitably lose in productivity and flexibility. In other words, they lose all the benefits that we got from the shift to a distributed computing model in the first place.

All of the big technology vendors would just love for SaaS to become the dominant model for delivering their products. Sun, IBM, and HP all would just love to resell some more of their data center compute cycles for it as they try to find new ways to sell more hardware without calling it hardware. But there are a few things standing in the way of SaaS achieving total domination of the software distribution model in its current form–and they’re the same things that brought the ASP model to its knees for all but a selective few who managed to squeeze a profit out of it.

The first big one is the laws of physics. While computing and networking technology continue to get faster and wider, all you have to do is spend a day trying to run Web 2.0 applications on a midmarket or small business’s office LAN to figure out that there’s a reason we run most applications inside the firewall. It’s called latency — no matter how snappy the front-end design is, and how cleverly you hide the latency behind asynchronous XML “get” requests, web-based applications inevitably hit a performance wall as they are scaled up.

If you take an application that everyone uses all the time, and put it on a web server off-site, prepare to see a lot of users spending a lot more time getting coffee, chatting over the tops of their cubes, or beating their heads on their desks while they wait for some data set to finish updating.

A few short years ago, a company I worked for decided to reduce its application management headaches by hiring a service provider to host its enterprise and desktop applications over Citrix. A short time later, the CIO was shown the door, and all but a few applications were yanked back inside the firewall–even if they remained hosted on a Citrix server. The reason was simple: the performance at the headquarters office was marginally acceptable, since the SP’s data center was just a fiber loop away. But the loss of productivity at remote and branch offices was so severe that they might as well not have had the applications at all.

But, ironically, what was the one place where Citrix ended up making the most sense? For improving the performance of web-based applications for the remote sites. Because latency was even worse for the web applications, just the act of configuring a thin-client server in close proximity to the application server made using the web app almost tolerable.

Granted, SaaS doesn’t have the same latency requirements as thin-client computing, and AJAX-based front-ends do a good job of improving the performance of web-based applications. But bottlenecks of any kind are still going to make frequent use of a heavily-trafficked SaaS application feel like dragging your body across broken glass with an elephant on your back — unpleasant at best.

Then there’s the issue of data availability. Sure, you can get to your applications wherever there’s a network connection. But when a company has to send everyone home for the day because a salt truck hit a telephone pole near their Internet provider’s central office (and trust me, it happens), suddenly the savings they got out of moving their applications to a SaaS model don’t look like such a big deal. What is the cost to your clients of one business day without access to their customer data, or their financials?

I’m not saying that SaaS is a totally bankrupt model. But like all things that tend to get over-hyped, SaaS just can’t live up to the savior status being assigned to it. And companies that tie their future to the SaaS model could face the same rude shock that those who got behind other “next big things” –like, say, ISDN–got when they never hapopened (Hayes Micro, anyone?).

4  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Brein Matturro
    This article is superficial and muddle-headed, and mistakes assertions for facts. SaaS has been around for much longer than the author imagines, especially in one of the most mission-critical industries going: finance. Reuters and Bloomberg, to mention just the largest information services, provide not only news but also securities and money market quotations, trading infrastructure, and more recently also specialised P2P applications, all using the SaaS infrastructure model. I can't speak for Reuters, whose technology infrastructure is made up of too many disparate bits and therefore, according to what I've heard, costs a lot to maintain and upgrade, but Bloomberg certainly doesn't fit the author's assumptions about a failed business model. On the contrary, it's a very successful business indeed. Both these services, and many other financial information and technology systems provisioned as SaaS, function with high availability and low latency, and the customers appear to be happy enough. It's true that a salt truck can knock down a communications line. But that can happen to any distributed company's infrastructure, and often does. I'm sure I'm not the only reader here who has experienced a bank branch going off line because of communications or computer problems, to say nothing of government offices. These problems exist in non-SaaS architecture as well. In fact, I've seen presentations that discussed how mission-critical investment banking systems that were supposed to function at five 9's, all in the data centre, were known to go down for more than 24 hours at a time. The answer to the potential problems is not to bring everything back inside the firewall, but to design and build the systems with enough capacity, with proper fail-over of critical application and data servers as well as comms lines, and so on. Does this require a higher level of architectural and technological design and execution? No doubt. But that is part of the learning curve, and doesn't in any way invalidate the SaaS model. I'm admittedly not totally objective, because my own company's product depends completely on SaaS deployment; but that's because of the functionality it is designed to provide.
    0 pointsBadges:
    report
  • Brein Matturro
    Thanks for the comment, David. No, I'm well aware that SaaS has been around in various forms for a while. I've actually done some successful SaaS implememtations in the past. But throwing everything at the SaaS model as it stands, as some seem to want to do, is as wrongheaded as pulling everything back inside the firewall. And I don't mean to suggest that the alternative is to yank it all back inside -- we're past that at this point. What I would suggest, however, is that greater care needs to be taken in implementing SaaS than is currently. Some sort of caching, perhaps? Maybe a slightly more distributed architecture than Salesforce and others use?
    0 pointsBadges:
    report
  • Brein Matturro
    I agree that one should not automatically turn every application into SaaS. In many cases there is no business justification for doing so, whether in turns of providing the software or data to the user, or in terms of RoI (for all that it's often difficult to assess RoI even half-accurately). The real problem, to which Sean alludes correctly, is in the implementation. SaaS needs to be implemented at a very high level of reliability, scaleability and security, and this is often not done. Part of the reason, I suspect, is that too many SaaS sites have been done as slightly flakey B2C services for a public with a short attention span: if SaaS provider A doesn't quite hack it, the consumers can always move over to B, the more so as this is a very dynamic space. The providers, however, may not yet have properly learned that they need to provide B2B services at a much higher level. This implies more expensive infrastructures, SLA monitoring, constant proactive testing to make sure that the system doesn't break, and all sorts of other things that need discipline. Actually, emphasis on the second S -- service -- which doesn't always come naturally to technology people, who tend to be accustomed to getting the product out of the door and then getting on with the next version or next product.
    0 pointsBadges:
    report
  • Brein Matturro
    Hello Do you know of a good Software as a Service (SaaS) software? Recently I've heard a lot about Paragent which assures flexibility and long-term options to the hosted customers - can anyone provide more details of it ? Any informationa about this would be great. Thanks in Advance Shaun
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: