lustratus LiteBytes

In a recent post, I was reflecting on the buzz about WOA (web-oriented architecture) – this subject has come up as a possible way to deliver something similar to SOA but in a more lightweight fashion.

Now, as I discussed in that post, I have problems with WOA. But it led me to thinking…..is it time for SOA-Lite?

A common software industry phenomenon is the advent of a Lite version of a technology, based around the 80/20 principle. That is, products start to emerge that may only do 80% of the functionality of the original market entrant, the cost and effort required to deploy the Lite version tends to be 20% of the original.

In the integration space, take the example of message brokers and ESBs. Message brokers were developed to provide  comprehensive functionality to satisfy the widest possible range of market requirements, but were typically difficult to deploy and cost a fortune. Then ESBs emerged, providing a subset of the functionality but at a greatly reduced price and with considerably less implementation work required.

This is a natural evolution, driven by market acceptance models. The first users of a new technology tend to be the visionaries who are big enough and ugly enough to make a success of the technology, but they are also going to be very demanding functionally. However, as adoption moves to the more pragmatic buyers, focus switches to getting the basic functionality at the cheapest cost and the minimum of effort.

Maybe SOA is reaching this point. Companies have had great success with SOA, but many would admit it has been hard going. Many smaller or more pragmatic companies are looking forward at SOA with a mixture of desire and dread, reluctant to dip their toes in the water. So maybe this is the ideal time for SOA-Lite to emerge. SOA, but done as simply and easily as possible at the cost of some of the more esoteric or high-end functionality. One aspect of SOA-Lite, for example, might be to rationalize the number of tools required for development, composition, deployment and operational support. Most vendors offer excellent tools to model processes, to design and develop services, to deploy them and to monitor operations. But these are usually all different tools, each requiring its own education. The concept is that since SOA will be deployed everywhere, you will need to most powerful, role-based tools to handle it.

But think from the pragmatic viewpoint. Looking for a quick win to justify investment, how about offering a single environment for service creation, composition, deployment and even monitoring? How about making pre-packaged decisions about definitions and configurations to make the whole job easier? Will this approach work with every SOA scenario? No – of course not. But will it work for most? Probably, at least basic ones. And once users are starting to build up confidence in SOA, with a few quick successes, there is no reason that a full function suite can’t be brought in at a later date.

So, will we see SOA-Lite offerings this year? Some of the larger vendors might not be too keen initially, since this might damage their revenues, but in the long run the result will be a bigger SOA pie for all vendors to share.

Steve