Yesterday I took part in an implementing design course. At the course was a systems architect from a large-ish software company. Morning tea came around and I started talking to him and, as is my norm, started waxing poetic about Sass. He proceeded to tell me that one of their products constitutes SaaS because, although it is installed on server within the organisation, from th users perspective it has all the appearances of SaaS;
- It is updated centrally by someone else
- They just use it and don’t need to think about updates, sysadmin etc
My initial thought was, no way, a core tenet of SaaS is its existence in the clouds… or is it. AIR is blurring the distinction a little bit, and from a users perspective at least, the issue is solution-centric rather than falling into a defined and detailed list of traits.
But then again if we define SaaS this loosely we run the risk of losing any real identity for it as a class of product.
No – I’m still sticking with SaaS needing to be (in the main part) hosted in the clouds.
What about you(se)?
I’m going to agree with the SI in this case. The role of the appliance is SaaS is ill defined currently. But i still think you can make a service of software using this approach…
You can rent it
You can get central updates
You have the ability to configure certain parameters
you buy and outcome not software
you pay on a subscription basis.
I think the appliance saas space plays to the those who STILL have to see some flashing lights…even if its just that, a box with flashing lights
First, where are you getting that “a core tenet of SaaS is its existence in the clouds”? Is that your definition?
Second, you inspired me to write a post about this:
I think there is too much focus on the physical characteristics of a SaaS service and not the thing that makes SaaS its own concept, the relationship between service provider and a service consumer. In a SaaS world there is a contractual relationship between the two parties and that is the sole instrument for managing the operation of the service. The service consumer has no hand in running or maintaining the service other than what they request in that contract.
Over the past few years there has been a major push inside enterprises towards being “service-oriented”. Business users establish a business goal focused contract on which IT delivers a service. From the both the internal IT and end user point of view, SaaS is just another acronym on this path they have already been on.
So if you see from his point of view, that architect is a SaaS provider. The only difference is that his “revenue” is some magic beans moved around on the corporate books rather than cash/credit card/ check payment.
(regarding the idea of a SaaS appliance, I think that somewhat breaks the SaaS model. If the end user has to have a hand in maintaining the the equipment that provides the service, is it really a service? It would be like if the power company put a generator at everyone’s address… that’s not service… that’s a generator rental service)
I guess my thinking stems from the fact that I come to this from two different angle. One is the solution-centric viewpoint (that you raised in your comment. The other is that I am a firm believer in moving applications into the clouds (and Wikipedia agrees that this is a core trait of SaaS).
So my answer would be that the example I gave is definitely SOA but not really SaaS as I think it will be going forward
Can you clarify what “in the clouds” means to you? That seems like a pretty nebulous term. I suppose to any user who don’t have to worry about implementation any service would seem like it is in a “cloud”.
Why is it essential that SaaS has an outsourced component to it? If an internal IT group provides a multi-tenant application service that matches the service providing model of an “ousourced SaaS” in every way and they interact through a business defined service contract… are they not a SaaS provider just because their paycheck comes from the same organization as their users?
BTW… SOA is a technical architecture. SaaS is a responsibility and service provider relationship model. Although a SaaS provider often uses SOA, they are two different concepts on two different levels.
To me it means sitting in a remote data centre somewhere, completely independent from the enterprises own IT infrastructure. Accessible from wherever and in no way reliant on any operating system or platform (ie I can do it with my iphone – only I don’t have one but you know what I mean).
And no it doesn’t need to be outsourced – internal teams can do SaaS provisioning for their organisations but by my way of thinking it needs to be “in the clouds” to constitute pure-play SaaS
And in terms of your SaaS/SOA comment I believe SOA is a component set of SaaS – hence not two different concepts entirely
“I believe SOA is a component set of SaaS – hence not two different concepts entirely”
You can easily operate a SaaS without following a SOA architecture. The architecture that the provider uses inside the “cloud” is really of no concern to the SaaS user or the SaaS relationship. For example, you use wordpress and I use blogger… do you have any idea what architecture they use internally to run the service? If the architecture is or isn’t SOA, it doesn’t change the fact that both are SaaS services.
Fair call Damon – instead of using SOA in my comments use service-centric design…..
the electricity company has a fuse box and reader at you’re premises, They like Telecom’s have been doing X as a Service for a long time. If the service provider manages the appliance, pushes out updates to that appliance (like a staging environment – which is quite similar to cache which no one monitiesed but could have) and you still just rent the apps then to me ..thats SaaS
bunreasonable, you are right. I was going against my own definition. If SaaS is first and foremost about the nature of the relationship, where the equipment of the service provider lives is not an essential detail (as long as all of the care and feeding of it is the exclusive responsibility of the service provider).