IONA has just announced its new release of Artix, the extensible ESB, here. IONA always pushes this concept of extensibility as a good thing, but I am not so sure. Specifically, IONA says Artix is extensible because it is modular, and goes on to explain that this means there is a base cost and then functional plug-ins that can be purchased when and where they are needed.
Now, this has immediate appeal, I can see. There is something comforting about only paying for what you need, and only on the systems where this function is required. But IONA seems to have placed quite a lot of functionality in this 'priced add-on' category such as protocol bindings, security functions, reliability and scalability features and so on. The danger, it seems to me, is that as your functional needs grow across an ever-widening network of ESB nodes, the price may climb sharply, with the customer suddenly facing a much higher bill than originally thought.
So there are definitely pros and cons of this approach - but perhaps the con that worries me the most relates to the purchase approval procedures that seem to be usual today. Every purchase has to be justified and approved. In the 'one package' approach, this requires a potentially tough justification up front, based on buying a package of function, some of which may not actually be used at first. In a way, the modular approach should mean this is easier, because you are only asking for funding to pay for a function that is actually needed. But in practice, having to go through the approval cycle for each functional increase could well turn out to be prohibitive in terms of elapsed time and danger to sanity. At least with the other approach, all the pain is dealt with in one go.
I guess the jury is still out.
Steve
Hi Steve,
There are many ways that customers can skin the SOA cat and I think you have chosen one way of purchasing Artix – buying small and scaling up according to your needs. Our customers tend to use a wide variety of purchasing models. It all depends on how customers want to plan their roll out. Our technology doesn’t require a large stack and is not a hub and spoke approach so incremental adoption is possible but not necessary. First, I can show you how extendible purchasing doesn’t have to drive an organisation insane and then give you an example of a different approach.
SOA done right is a long-term proposition and IONA’s technology lends itself to a gradual rollout as opposed to using a large scale stack which would require expensive infrastructure build out up front and would not deliver early stage profits. To begin the process, organizations need to choose the high value projects and incrementally adopt their SOA infrastructure so that the upfront investment is minimal and the returns on investment are significant. Then as initial investments begin to pay dividends they are funneled into building out more SOA infrastructure. The profits from the early investments in SOA would be funneled to fund process changes such as requirements gathering for more services. The model is self-perpetuating so it will make it much easier to go back to purchasing since you can justify the expense in their language.
Another way of approaching the SOA rollout is to use our Value Assessment Program http://www.iona.com/solutions/value/delivery_process.htm which requires only 40 hours of customer time and can identify upwards of $10 million in savings per project. The Program is the result of examining middleware operations and establishing best practices within hundreds of large-scale IT organizations.
These are just two economic models that can be applied to our technically incremental approach to SOA build out. No economic model is precluded.
Neil Kenealy
IONA Technologies
Posted by: Neil Kenealy | October 19, 2006 at 12:24 PM