All aboard the Enterprise Service Bus
Event processing, anyone?
Analysis Sonic Software has a good claim to the invention of the Enterprise Service Bus (ESB) and has done more than anyone else to evangelise the concept, backed by the resources of its parent company, Progress Software.
Sonic runs regular seminars (we attended one, entitled “SOA: Best Practices, an Architect's forum” in London this week); and Enterprise Service Bus by Dave Chappell, Sonic's VP and chief technology evangelist, (O'Reilly, ISBN 0-596-00675-6), is an excellent introduction to ESB.
The ESB concept seems to be maturing now, which means that everybody and his dog is talking ESB – and some of them - Iona's Artix, perhaps - are strong competition for Sonic's own ESB.
An ESB is a “standards-based integration platform that combines messaging, web services, data transformation to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity” (from Chappell's book).
It is better than a hub-and-spoke enterpris application integration (EAI) broker because there is no single bottleneck to scalability, but with that specification, appserver vendors such as IBM or BEA shouldn't have much trouble building one.
Starting more or less from scratch like Sonic has advantages (it should be leaner and faster with the latest technology), but re-using legacy technology has its points too (for a start, people are used to it).
So how do you distinguish yourself in this game? Well, by good marketing and by providing more, and more useful, services.
Sonic Software has done both. Its Service-Oriented Architecture SOA Maturity Model (developed in collaboration with AmberPoint and Systinet and due for publication at the end of October 2005) is partly a marketing tool as far as we can see - it exploits the Maturity Model concept associated with CMMI. CMMI deals with process management, not specific technologies, but it still has some practical uses.
You gain little over traditional approaches when you implement SOA at Maturity Level 1 (ML1) to achieve some new business functionality. But you are at the start of a progression towards something better and the SOA Maturity model helps you track your progress. Level 2 is about architected services and starts to bring cost reduction and control; Level 3 is about business and collaborative services and increases the responsiveness of your business process; Level 4 adds service metrics and promises to start delivering business transformation, from reactive to real-time process; and Level 5 adds automatic proactive optimisation of services using these metrics.
The various stages more-or-less correspond to the maturity levels in CMMI – but we suspect that you need to be operating at CMMI ML4 or 5 to really achieve SOA ML 4 or 5 benefits reliably, and installing an ESB is not a short cut to CMMI maturity.
Sponsored: DevOps and continuous delivery