This month I thought I'd put on my sales hat for a moment and talk about what it takes to actually sell someone on the concept of using service-oriented architecture as the underlying paradigm for an organization's information technology implementation and direction. In part this is because there's still a good deal of resistance to SOA as that basis.

In the early days of trying to persuade corporations that SOA is a good thing, there was a great deal of commotion around the issue of security. The perception was that services were not really secure - and in fact, the very basic Web services standards of HTTP, SOAP, WSDL, UDDI and XML are not secure, other than perhaps with an SSL layer. But we've managed to put a stake in the heart of that specter, and worries about security now revolve more around proper implementation than around the actual availability of capabilities of an SOA to provide security.

Yet, while this had seemed at one point to be the sole stumbling block, why haven't we seen the floodgates open and a million SOA implementation take place? This is the key question.

SOA for many is like source code management. Unquestionably, source management is a good thing when we talk about software development, but the question that always comes to mind is - how do you quantify the goodness? Is there a return on the investment, which includes time, dollars, and software? Conventional wisdom says there is (and I personally believe it strongly), but at the same time, when was the last time someone actually presented actual cost savings for source code management.

I bring this up to point out the similarity of the situation with respect to service-oriented architecture. SOA provides key advantages that are fairly easy to see - loose coupling, application composition rather than development, the ability to manage services on a granular basis, and finer control of the actual work done by information technology. Integration, which becomes crucial the minute a business has more than one software system, is the key facet of SOA that makes every technologist realize that SOA is a better way to do software and implement processes.

The key difficulty with selling SOA as a concept for how to do technology is quantifying the actual benefit that results from using services. In business terms, determining the ROI of a change to SOA is what's important, but, perversely, it's also very hard to capture the value of SOA in absence of some business change to accompany it.

Look at it this way - it's easy to say, and also easy to understand and agree on the fact that SOA makes software integration much easier. But what is the dollar value of that ease, and how much of an effect will it have over time? That's the difficult question that is holding back funding of SOA in the current world. Sometimes you can quantify parts of it, such as saying you no longer need a particular EAI package, so your license, maintenance and operating costs could be viewed as the cost savings against which the cost of the implementation could be measured. Those cases are the simple ones, the ones where it's easy to make the case to go ahead with SOA. Unfortunately, in most shops, the case for a pure SOA conversion is much less clear. The ability to do something "better" needs to be correlated to a reduction in cost, or an increase in productivity, or both.

Most SOA approaches are couched in the context of some business improvement or other. It might be the deployment of a new ERP system, where the benefit of decoupled services can be quantified more easily due to the nature of the services and the cost of maintenance versus the same task with monolithic applications. Many IT shops are making SOA concepts - services, service buses, asynchronous invocations, and the like - a part of future designs and hoping at some point, when the shop looks more service oriented than not, that funding to go the rest of the way will be easier to acquire. That may be the way SOA comes into full fruition, not with a bang, but with a series of small improvements. Happy holidays and have a great new year.