Browsing my RSS feeds about Sourcing, Procurement and Technology with my preferred Netvibes Tab, I went through a post of Jason Busch about SOA (Service Oriented Architecture) which, I have to say, ‘triggered’ me. One, because it is the first time I was hearing about it – nobody is perfect – while it is not really new (couple of months?), second, because it is not a very straitforward concept at first glance, third because my understanding of SaaS was confused by SOA. So I decided to clarify that and read, as suggested by Jason, the illuminating post from Joe McKendrick “Three reasons SOA will increase outsourcing” but another one – illuminating – from Phil Wainewright “Seeking the true meaning of SaaS“.
What I did learn about SaaS is following:
- the two essentials of Software-as-a-Service: hosting and subscription
- a pure SaaS implementation is not necessarely based on a multitenant architecture…but it helps!
- Ideally the provider’s SaaS implementation is a ‘black box’ to the customer, who has no interest in the underlying technology so long as the contracted outputs are being delivered as specified. The customer’s only concern is to get compliance with the SLA he paid for, not to interfere in the provider’s technology decisions.
- SaaS vendors who’ve embraced multi-tenancy have also embraced SOA, as they were ‘forced’ to enable policy-driven configuration of applications as a means of customization rather than the custom coding favored by conventional software vendors.
- Leading-edge SaaS providers use the Internet not only as a delivery mechanism to deliver their services to customers but also as an Shared-Service (aggregation) platform to enhance and extend their own capabilities by linking up with third-party services (content providers for example)
- SaaS generate communities of interest: vendors have begun to realize that they can also leverage their global view (they can trace everything happening on their platform) to provide feedback to their customers on best practices, or allow customers to benchmark themselves against their peers. The aggregate view gives them insight that wouldn’t exist if each customer operated their own separate on-premises implementation, and by sharing the benefits of that analysis with their customers everyone can gain.
- SaaS offers a pay-as-you-go pricing scheme, as it is a service oriented company (and not IT)
- SaaS is not the end destination of the “service on demand ” journey
… and about SOA:
- SOA = SaaS minus ASP : “From a SaaS delivery perspective, SOA is what separates the current generation of SaaS providers, epitomized by the likes of Salesforce.com and NetSuite.com, from the failed application service providers (ASPs) of the dot-com era. From a consumption perspective, you certainly don’t require a SOA to use SaaS, but if you want to effectively mix and match external services with on-premise assets and services, SOA will make it possible to efficiently build, deploy and manage composite apps.” (Source: Doug Henshen, writing in Intelligent Enterprise)
- prediction is that 25 percent of business software will be delivered via SaaS within the next five years
- SOA will boost outsourcing for 3 reasons:
Bottom line, the concepts are fairly clear and I fully agree with Joe McKendrick: SaaS shall boost application-outsourcing, simply because of the huge added-value (benchmarks, best practices, shared content, shared infrastructure, shared innovation investment etc…) they can bring to the community of interest they will condense. However, I don’t see it happening so easely as I see a ‘chicken and the egg’ dilemma to solve:
I can tell it is a “chicken and the egg” dilemma: I’ve been myself, at the head of Eutilia N.V. eMarketplace (something between SaaS and ASP), trying to find a way-out to this issue, for several years, unsuccessfully. I would say today that, to make it, the SaaS provider has – at minimum – to start business with a committed core-community (i.e. committed to use the services, to share data/information/content/etc… and to sponsor the initiative). Look at Eutilia, founded by eleven of the biggest Electricity providers in Europe, which never succeeded to get those companies sharing their supplier-public-data and using a unique supplier-prequalification questionnaire, though identified in the business plan as a critical but easy to reach milestone. Eutilia failed because of its unability to create a community of interest.
Don’t miss my point, I’m not saying it is impossible to succeed but only that aside from a good SaaS concept, a community – even small – shall be already committed to use the service and share the benefits of sharing their data or best-practices all together.