Showing posts with label Software-As-A-Service. Show all posts
Showing posts with label Software-As-A-Service. Show all posts

Wednesday, October 10, 2007

Why SaaS will make and why ASP didn't

I picked up blogging again last week when I wrote that the acronym SaaS does not ring many bells yet with decision makers. Maybe ASP does, but that is something many decision makers do not want to get involved with as that is so 90's.
Still there are many people that think that SaaS is the same as ASP. Take this definition for instance which I found on the web site of the Dutch research firm that concluded that SaaS is not known by many decision makers:
"SaaS (Software as a Service) is software provided as a hosted service which is accessed over the Internet, and which is billed through a subscription structure. This is also called ASP(Application Service Providing)."

Let me explain why I think this makes no sense. To start with, the delivery model is completely different: with ASP, you pay a monthly fee for a fixed period (sometimes even for the duration of 3 to 5 years), while with SaaS you only pay for the usage ("pay as you go"). This may sound trivial, but it has consequences for the customer orientation of the provider: because a subscriber is not tied to a fixed (maybe long) period arranged by a contract, which is the case with ASP, it is easier to make the switch to another provider. This implies that the SaaS provider must do more for client retention, hence deliver great customer service.
The architecture of products is usually also very much different between an ASP and a SaaS provider, mainly because SaaS products have been developed from scratch to be used over the Internet (take Salesforce.com as an example). The ASP versions of products have usually been "web-enabled", but still have a typical client-server architecture. In the past, the ASP model therefore never fully delivered what it promised, because of the lack of bandwidth, or because of a performance degrade resulting from the web-enablement of the application.

In short: both the delivery model and the architecture of SaaS and ASP are different: SaaS solutions are generally speaking better prepared (optimized) for usage over the Internet, and its delivery model is more flexible than the ASP delivery model. So, we are dealing with different animals (that live in the same Zoo though, named Outsourcing). The key advantages of SaaS over ASP make that I believe that SaaS will succeed, as these are exactly the reasons why ASP did not succeed.

Saturday, October 6, 2007

Are we dealing with GAF(general acronym fatigue)?

Two recent news items have made me wondering whether we are dealing with GAF: a General Acronym Fatigue.

The first news item is from a Dutch IT newspaper, which quotes research from a Dutch IT research organization: 73 percent of all IT decision makers do not know spontaneously what SaaS (Software as a Service) is. Only after an explanation of what is meant by SaaS (a formal definition), 69 percent say they know SaaS. Which leads to the conclusion that only 4% of IT decision makers really have no clue what SaaS is about, and 69 percent are just confused by the acronym / terminology. An ASP (Application Service Provider, not Active Server Pages) expert in The Netherlands says this is due to the fact that companies, vendors and end-user organizations all have different names for the phenomenon: "Web 2.o", "internet-accounting" or "online services". Some people have even called it "ASP 2.0", which is really silly as there are substantial differences in the delivery models as far as I am concerned.

The second news item has been not on a single source, but in fact has been heard among many blogs: more and more people are seriously questioning the ESB (Enterprise Service Bus) is worth using. I have answered this question already some time ago: it is not! It is just replacing one low viability solution (CORBA or brokers) with another (service buses). I have plead before to use Apache for instance as a service bus (or rather I would name it service intermediary), and obviously more people have come to this conclusion. But then of course, we are talking about the design pattern, and not about the commercial product type some people considered to be the next generation application server. I suggest to drop the name ESB, and instead to name it what it is: a service intermediary.

The future does not look toto bright for people confused with acronyms, in particular because the aaS letters are pasted to any random technology or product category you can imagine: PaaS (Platform as a Service), CaaS (CRM as a Service), AaaS (Accounting as a Service) well, you get the idea... the good thing is that we run out of options at 26 acronyms...

If we (yes, everyone in IT is responsible for this GAF situation) are unable to come up with good names for new concepts, patterns, technologies or products, we should not blame those poor IT decision makers for not understanding our value proposition. In 9 out of 10 times we are not dealing with an ignorant decision maker, but just with someone suffering from GAF.

OK, I am off for now, I am going for a BLT.