SaaS - Services as a Service .. now wait are you trying to confuse us here

Saw this interesting post When SaaS Means 'Services as a Service' posted on Intelligent Enterprise by David Lunthicum. At first glance this read like an attempt at confusion. However now that I looked at what StrikeIron does it actually makes sense. So in yesterdays world if you wanted to embed logic about currency conversion or validating a US postal address or symbol of a company listed on Nasdaq you would either try coding it yourself by maintaining some seed data or you try finding a public web service that meets the requirement.

What companies like StrikeIron are doing is they've become aggregators of services from partners like D&B, MapQuest etc and offer them through their own catalog. Now one might question the value of that and say why wouldnt I go directly to D&B and get access to their services and data. Well the spectrum is wide and there could be instances where the StrikeIron model works better. Lets say you're a small startup or a SMB kind of a company that needs access to some disparate services, would you invest in people and contracts and partnerships to reach out to each of these vendors get info on their offerrings and then maintain relationships. Maybe, maybe not. Maybe you might go to StrikeIron and pick off of their catalog or services.

So SaaS with "Services as a Service" makes some sense. Now nearly half of Salesforce's traffic these days comes through web services, does that mean they are now transforming into a "Services as a Service" company?

By the way here's what StrikeIron says it does in a nutshell.

* CONNECT

* • Find Data Services
* • Browse Solutions
* • Cleanse & Enhance Data

* CREATE

* • Build Mashups in Excel
* • Create Business Solutions
* • Integrate into Salesforce.com

* COLLABORATE

* • New! Developer Community
* • Download Code and Clients
* • Access Free Data

What does SaaS Really bring to market?

To understand what role SaaS will really play in the Web2.0 generation I decided to try and deconstruct exactly what it brings to customers.

So zooming back in time a little bit I would say that the emergence of SaaS was closely tied to the failure of on premise (desktop, 3-tier, client server) software to control the cost of ownership. Now in some ways SaaS is a redux of the mainframe - green screen model. But we all agree that the current version of SaaS has much more to offer than that.

According to me the two main things that SaaS offers to its customers is agility and abstraction.

Now both of these perceived benefits that SaaS brings have boundaries and many customers have discovered that they are kind of brick walls at times as well.

Imagine if you were an army of one and wanted to address a business issue by deploying an application. SaaS provides the agility to do that. In the on premise world the work on this kind of an initiative would have been significant and to a large extent the same whether it was an army of one or a legion of consultants. But then again, I would like to reemphasize the boundaries. As many SaaS initiatives have discovered once you take SaaS deployments to a large scale you start hitting some of the same real world problems on premise products have hit in the past where the products are too generic and requirements too varied, so it leads down the road of custom solutions and all the TCO related items that ride a custom solution.

However its the second value that is of greater interest to me. "Abstraction", software vendors have grappled with this issue for a while now and miraculously SaaS seems to provide a solution for this to a great extent. Now I say "seems to" because folks can argue against it and in reality even the SaaS vendors are not there yet. But to me the ability for a SaaS initiative to abstract or layer the "data" from the "application metadata" from the "business logic" from the "UI" is sort of the leading edge. A number of vendors have claimed this and tried delivering S/W based on these designs but you just have to go through an exercise of upgrading that software to its next version or build complex business requirements into it to realize how intertwined things can get. This leads to management issues and application of more resources which ultimately leads to huge costs and the thread goes on.
To customers SaaS seems to offer that promise that they wouldn't have to worry about these inner wiring's so to speak and just deal with their business application from an application perspective. So if the SaaS vendors pushes out a new release or updates a particular component or feature the customer is insulated (or to a large extent they are).

So then to me the question would be why stop at that. Why not have the cake and eat it too. Would it be whacky to think of a SaaS evolutionary stage where the service delivers the software artifacts from the cloud but the data, business logic and all other components remain local. Now I can already hear the SaaS purists crying foul. But to me coming from the enterprise S/W world like most of the large customers and sitting in front of this paradigm change its a valid thought.

What if my data, application metadata, business logic and UI were abstracted completely from each other such that it wouldnt matter to me if the vendor used a SaaS service behind the scenes to manage, modify or replace it. Maybe that's nirvana, maybe its a bunch of BS.

However it already sowed the seed for my next post. How does SOA play into all this is it the super glue or modelling clay that holds this together.

CIOs face tough on-demand choices

A recent silicon.com CIO Jury poll of IT directors found half of businesses are still cool on SaaS, which is either very low priority or not on their radar at all. But it is gaining ground in customer relationship management, where analyst Gartner predicts SaaS will account for 14 per cent of the total market this year.

This would'nt surprise me as SaaS or OnDemand vendors have still not covered much ground on the main pain points that large organizations have around;

Risk management: As a large organization where my exposure to risk is higher what are the options I have available that mitigate these risks. Since the SaaS world often uses the "power grid" analogy I would ask where are their diesel generators. Have you ever been to a large telco or hospital that completely relies on the power grid but also has its own backup generators that can run for really long cycles in the case of an outage? These organizations test these generators on a weekly basis to ensure they can kick in right away. What if a "Melissa" hits SaaS vendors does that mean that I'm hosed because I'm now joined to their infrastructure at the hip. To win over large organizations that want to make SaaS as part of their mainline strategy these kinds of diesel generators are required.

What happens when I terminate my SaaS contract and decide to move on either to an On Premise or another OnDemand vendor? Thats another risk thats not significantly addressed by the SaaS vendors.

Security: This has been a perenial issue for the SaaS world and unfortunately I dont see the same progress being made on that front.

Integration: A sore point for many CIO's who've been there done that or inherited a 250+ system landscape where 50 of their systems need to integrate with their OnDemand system and there are all kinds of replication and federation issues. Again this is an area that needs a lot more investment than what we are currently seeing.

Supressing rather than flushing out these issues is leading CIO's to be hesitant to jump on the SaaS bandwagon.