lustratus LiteBytes

When I talk to vendors of SOA software about their offerings, I always focus on the tooling provided with the product – from development tools to deployment tools to life cycle management tools.

Of course vendors will claim that their products are easy to use and highly productive. Unfortunately, these claims are often not properly challenged as products are being selected for SOA projects based primarily on functionality and ‘enterprise’ attributes. This is partly because it can be quite hard to establish just how productive the software will be when used outside the demo or pilot comfort zone. I said unfortunately above because anybody involved with integration projects (SOA or otherwise) will understand the high proportion of effort spent on dealing with the unexpected incompatibilities or consequential issues: Effort which can be significantly reduced with good tooling.

Another part of the problem is defining what we mean by easy to use and productive. In particular, whether a tool is easy to use or productive is closely coupled with who will be using it. A productive tool for an expert java developer is very different from a productive tool for a business analyst. Without unfairly blaming our marketing friends, there is a tendency in the industry to assume anything GUI based must be suitable for business analysts and so long as it works in Eclipse, java developers will be happy. (For instance, I remain to be convinced that the business process execution language, BPEL, is something any business analyst would use – pretty interfaces or not) Needless to say, reality is much more complex and when evaluating the tooling around your preferred product makes sure to match the capabilities against your developer base and not be fooled by the apparently pretty pictures (or lack of them).

Ronan