Here's something ZapThink wrote on the subject concerning Service
Oriented Architecture, Software-as-a-Service and IT Services:
http://www.zapthink.com/report.html?id=ZAPFLASH-20051128
The truth is that an architecture that concerns Services (SOA), a
business model that involves sale or use of externally-provided
Services, and IT capabilities exposed as Services don't have cut and
dry differences, even tho folks might like to think they are. Simply
put, once you have Services that can be consumed for internal or
external use, and then go about making them actually available for
external use, and then potentially sell the use of those Services,
we're crossing / blurring the definitions or crossing the lines of all
the above definitions of the term Services. And we *love* the blurring
of those lines... after all... why should we differentiate between
those Services if the whole idea is to build Services that can be used
and reused as needed for different purposes?
I guess we all love to spend time defining things, eh? Welcome to the
world of the analyst!
Best,
Ron
Anne Thomas Manes wrote:
Your point that Salesforce.com
provides CRM services is valid. The distinction between software
provider and service
provider gets a little fuzzy when you adopt the SaaS business model. I
think the real distinction between Salesforce.com
and Amazon is that Salesforce.com
's primary business is the development and licensing of software,
while Amazon is retailing and retailing services.
I don't think the distinction between fully automated versus manual
really works. Lots of folks offer fully automated business services. If
you want to start a business that offers settlement services, that's
the focus of your business model. How you implement those settlement
services is up to you. Obviously you need some software -- and you can
build it yourself, buy it, or lease it from a SaaS vendor. Regardless
of how you get that software, your settlement service consumers
shouldn't need to know about it -- they just want to use your
settlement services. One feature that will make your settlement
services more attractive will be easy-to-use interfaces.
I wouldn't refer to SaaS as a "delivery channel" for software. It's a
business model. The delivery channel refers to who actually does the
selling. Even with SaaS, you still need direct/indirect/web/etc.
delivery channels.
Now -- if you turn around the phrase and call it "Services as Software"
rather than "Software as a Service", then I think we start getting into
a different realm that applies to non-software vendors that supply
services through software, such as Amazon and EBay.
Anne
On 2/23/06, Vikas Deolaliker <[EMAIL PROTECTED]> wrote:
Anne,
I don't understand the distintion you make between software
service and business service that uses software as a means. Couldn't
SF.COM be seen as a company offering CRM service? Software then is
only a means to this CRM service. Or I may want to start a settlement
center and instead of purchasing the settlement software system, I
could lease it online from some settlement service. I guess, I see some
of your point in that when a business service has some manual
intervention, you classify that as a business service if it is fully
automated, you classify that as a software service. Right?
Isn't SaaS just a delivery channel for services that are
exposed by vendors? More services can be mined from the vendor's data
center should the data vendor decide to implement SOA. Does this
reconcile the two?
Vikas
----- Original Message ----
From: Anne Thomas Manes <[EMAIL PROTECTED]
>
To: [email protected]
Sent: Wednesday, February 22, 2006 12:42:12
PM
Subject: Re: [service-orientated-architecture] SAAS vs SOA
Here's how I see it:
SaaS is a business model that applies to organizations whose primary
product is software (
i.e., software vendor). These vendors can license the software to other
organizations who will deploy it and run it as they deem fit, or the
vendors can host the software (either themselves or through a service
agency) and licenses user subscriptions to the software.
The classic example of a SaaS vendor is Salesforce.com.
A SaaS application does not need to be service-oriented, although
service-orientation would be a valuable feature in that it will enable
easier integration with other software.
SOA is a software design discipline in which application functionality
is implemented as reusable services that can be shared by many
different applications.
Organizations whose primary product is not software ( i.e., not a
software vendor) should not be thinking in terms of SaaS. Non-vendors
should be focused on selling their business services (healthcare,
financial, manfacturing, etc). Very often delivery of these business
services involves the use of software -- but the software is simply the
means to the services -- not the service itself. If you are a financial
services company specializing in settlement services, then you are
selling settlement services, not software services -- even if the
settlement service is implemented using software.
Anne
SPONSORED LINKS
YAHOO! GROUPS LINKS
__________ NOD32 1.1417 (20060223) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
__________ NOD32 1.1417 (20060223) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
--
_____________________________________________________________
Ronald Schmelzer
[EMAIL PROTECTED]
Senior Analyst
ZapThink LLC
Direct: 781-577-2779 / Main: 781-207-0203
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
