The sad state of SOA development tools

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:

  1. 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.
  2. 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.
  3. 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.

Ronan

p.s. If any readers want to point me at some good SOA development tools, I would be delighted to take a look.

Posted in Imported, Industry trends, SOA, SOA development.

2 Comments

  1. Ronan draws the conclusion that in order to be successful with SOA, significantly better dev tools are needed. While I completely agree with the assertion that there’s disproportionate emphasis on run time stacks, I worry that sweeping statements about dev tools are a little overloaded.
    In terms of support to developers consuming pre-existing services what’s needed is more specific support for service acquisition life cycle operations such as specification based gap analysis, semantic mapping and transform, specification based service testing and SLA management. However it has to be said that these all need richer service specifications, preferably standardized in a comprehensive manner that the industry hasn’t yet got to grips with.
    For developers producing services the really critical requirement is better modeling support that provides reference architecture automation that spans the architect and developer roles and provides explicit policy based support. Think MDA on steroids. But that’s another story.

  2. David,
    Thanks for the comments. However I should make it clear that I was using development tools in the broader sense of the word which includes what you are referring to as “service acquisition life cycle operations” and modelling support.
    These are clearly key components of what will make SOA developers productive. Two points however
    – At the end of the day, these are all aids which help developers to do their job and attempts to rename them as lifecycle management (or whatever) as much as anything reflects point 3: Just calling them developer tools would make it harder to sell them at the price point required. I have no problem with this but it may confuse already confused SOA adopters.
    – We need to remember that the objective I was focusing on was to allow less expert developer be more productive more quickly. By all means that may require better standards and a certain amount of process. However, I get a little scared when it seems to require a lot of “new science” rather than “old fashioned” good software design. I think we can go a lot of the way there with the later as we figure out the former.
    Ronan

Leave a Reply

Your email address will not be published. Required fields are marked *