I think it is becoming generally accepted that SOA presents some pretty big issues outside of the technology domain in terms of skills and organisation.
Even before a new SOA developer in a particular organisation gets to dealing with cool new technology, he or she must understand the additional layer of process and operational knowledge in order to work within the SOA-based world.
One example is ‘service discovery’ which for the developer means finding services which work for their task in hand and understanding how to work with them. I use the term service discovery with caution as I do not mean automated discovery of the insidious WSDL that Steve referred to here. Rather I mean the task by which an individual developer gathers sufficient information to make the decision to use a service in his or her project. At some point WSDL may well be needed but the task really requires search capabilities and lots of human-centric information that explains and motivates the use of each potential service.
Let’s now step back for a moment and think about SOA and infrastructure software in general:
Infrastructure projects (whether SOA based or not) require an understanding of many aspects of both technology and business domain unlike business applications which for the most part require understanding of the business domain alone. This raises the technical skills bar for infrastructure projects.
SOA is meant to reduce the cost of development and maintenance. As there is a global shortage of highly skilled developers and these are concentrated in a smaller number of large organisations, it can only do that if it allows less expert developers be productive. It will be of some use if it makes the job easier for the experts but this won’t help most business departments and SMEs.
How well are the current SOA enabling products are doing? In particular, have they made the task of developing SOA easier than using EAI products 5 years ago which were held to be too difficult and expensive to use by many organisations? My opinion is that there has been some maturing of development tools but in general too little has changed. This means that SOA risks running into the same skill shortages that EAI ran into.
I think there are probably a few reasons why there hasn’t been a radical improvement in development tools:
- SOA stacks tend to focus on run-time capabilities (such as SOA run-time registries stuffed full of WSDL instead of knowledge management systems designed to guide the developer to the right service). The reasons for this may well be that software architects recognise that run-time problems (such as lack of scalability) can’t be got over as easily as development problems: Development problems will increase the cost and failure rate, but they won’t bring down the business.
- It is much harder to create good tools for less skilled developers than more code generation wizards that plug into eclipse that appeal to experts. Hence if you look at most SOA stacks, they will include forms-based user interfaces which help the already knowledgeable programmer with some routine tasks. They do not allow the newbie to focus on the business logic instead of the integration logic. Unfortunately, this point is somewhat obscured when people say they don’t need yet more new technology for SOA – they really mean they don’t need more new run-time technology. They certainly need more productive development tools.
- Middleware has put the premium price on run-time software and development tools have traditionally been sold for low prices or even given away. This may be because developers in early adopting companies tend to be more technically skilled and put lower value on easy-to-use tools. They also favour tools which augment their own skills – rather than tools which make it easy for somebody less skilful. What this means is that it is hard to fund or build a business selling really good development tools.
All of which leaves a significant challenge for SOA adopters and vendors. In order to be successful with SOA, significantly better development tools are needed. For this to happen, end-users need to push their vendors and be willing to pay them when the tools are delivered.
p.s. If any readers want to point me at some good SOA development tools, I would be delighted to take a look.