SOA as a Service

Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.

Although SaaS has been around in principle for about 10 years, it is only in the last couple of years that it has moved from buzzword bingo to actually usable product. From a business analyst's perspective, there is a fairly sensible point of view that you should not need to know how the solution will be delivered only that it meets the requirements, both functional and non-functional. However, as the more experienced of you will know, your users will demand such intimate knowledge of all aspects of the technology stack being proposed that you might as well make the effort to get familiar with at least an overview of the techie stuff your IT department are drooling over.

So here is a blagger's guide to SaaS. SaaS essentially provides a set of functionality at an agreed transaction or usage price with specific service levels, provided remotely, typically web-based. This can vary from a complete application suite (e.g. Netsuite or Salesforce.com) to a specific atomic service (e.g. embedded search engines, Google Documents). SaaS can be seen as a logical extension of the service concept from SOA, where the location of the service is abstracted outside of the organisation to a third party provider. So for SOA enthusiasts (you know who you are), SaaS provides a great way to access services that you don't need to develop and maintain yourself this is all covered by the service provider.

There are a couple of gotcha's here, of course. The first is you are entrusting part of your business system to a third party over which you have no control if their servers fail, you can't do anything directly about it. The second is that you will be paying for this service for as long as you continue to use it. For a high volume transactional service this could be many times the cost of developing and maintaining it yourself. There are contractual solutions to both of these, but this changes the nature of the risk and project management required for systems with a SaaS element.

Don't let this put you off. I would recommend trialling some SaaS components on non-critical systems to get a feel for what it is and isn't good for. The SaaS vendors are selling a seductive future where you don't need to bother with software development any more just mix and match some SaaS components over the web and voila! It may be some time before this ever becomes a reality. No, I don't think it will either, but it will be fun trying!

Author: John Moe is Principal Consultant at J Moe Associates, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.