SOA - What should I expect in return for my investment

The more people I talk to about Service Oriented Architecture, the harder I find it to present SOA as a one stop suits all solution. I can split the conversations into two groupings. The first set I would describe as managerial in that the questions centre around what the measurable benefits of implementing the technology should be. The second set are technical and centre around how the technology should be implemented. In this blog I am going to try and address the first group. The second group I will address in the next.

I guess the place to start is to re-state the driving objective behind the move to implement SOA's and that is to reduce the cost of delivering solutions to users. Of course, this needs further definition to be useful, since some managers might think that the most effective way to reduce such costs is not to attempt to deliver any. There are two sides to the cost equation. There is the cost incurred while waiting for a solution and there is the cost of delivering that solution. The balance between the two will form the core of any measurable ROI.

Service Oriented Technology is aimed squarely at both sides of this equation - the cost incurred while waiting will be less if the time taken to deliver the solution is less and the cost of delivering the solution will be less if it really is simpler and quicker to create than with any other technology as it is supposed to be.

Unfortunately, adopting this technology is not without an initial set up cost. How large this cost is and therefore how long it will take to reap a rewards for its introduction depends on the interpretation of the technology used and, that in turn, depends on the needs of the organisation proposing to adopt it.

Lets look at the options in turn. At the top of the pile we have the SOA purists. The approach proposed here will eschew any attempt to make a start by attempting to expose services from within traditional existing systems as "Sticking lipstick on a pig". This immediately requires the organisation to invest in the creation of the entire architecture from scratch and therefore the time taken to begin seeing any reward will be long - very long. For a technology that is presented as making IT more agile, this can be a dubious start. The same purist approach will demand that an Enterprise Service Bus (ESB) is implemented and that individual services have to contract with the bus. This is deemed necessary to ensure that no process requires any knowledge of the working of any of the services it needs. Instead it just needs to know what services exist in the registry and how to ask the bus for information from them at the right time. The bus knows content in what format the requesting service needs the information and it also knows what content and in what format it can get it from its register of services. In theory, I am now free to extend the capability of existing services or exchange them for new services at any time and only the ESB needs to understand the changes. Remember, any one service may be a constituent of many different processes.

If by now you are wondering what happens if a service is changed such that it no longer meets the need of every process that uses it this too has been addressed. Governance is the key to ensuring that services are managed so that this does not happen.

The problem I have with this is that there is a real danger that the very agility that is being sought can be negated by the need for tight governance restricting the development of services in line with the needs of the business. This in turn will lead to the development of ever more new services instead of encouraging the re-use of existing ones, thus undermining the whole theory. Whether this concern is well founded is still to be determined - there are not enough experiences around yet.

In terms of getting an acceptable return on the investment, the likelihood is that such a project will be unlikely to give a return on investment in a period of less than three to five years if current results remain the norm. Projecting the future that far is notoriously difficult and is the preserve of the very wealthy or foolhardy

The alternative to the purists are the incrementalists. Here the objective is make quick kills to convince the user community of the value of the approach. By definition, to make a quick kill corners have to be cut. Lipstick will be put on the pig so that existing investments in systems are preserved, An ESB may not be used and the overhead incurred when a service is altered swallowed, possibly inadvisedly, as an acceptable price to pay to make swift gains now.

This approach does, however, have something to be said for it, particularly because recent technology developments are riding to its assistance. The first development that helps concerns detecting and talking to services. The big argument for an ESB is that when a service is changed, only its contract with the ESB needs updating. This avoids the need to update every process with the change. However, there is now technology available that can discover and use a service without any need for re-programming. This makes this task much easier and undermines some of the advantages of an ESB and as ESB's are expensive swings the ROI balance in favour of the incrementalists.

The second development is one that makes the creation of services a code free exercise. This has several impacts on the argument. Its quick and easy to put lipstick on the pig, its cheap to create new services on demand and, most importantly of all, its very simple to re-engineer existing services. Taken together, these technologies when used incrementally put SOA technology within reach of businesses right down the the SME level.