Who cares about what ESB does. What many are caring about is how does it add value. If one were to deploy thinking of it and approaching it as just a traditional middleware component within the enterprise, then not much could be attained.  It simply creates more challenges in maintaining yet another middleware application. Within an enterprise, such clusters create more challenges in integration. To reduce integration overheads,isn’t it better to think of deployment models of such tools and services.Some have thought about having just ONE ESB depolyment across the enterprise, meaning, one who owns the middleware deploys, integrates and activates services that evolve and provide a connection layer to downstream. But this approach has long gone because of mystic behaviors of the then evolving ESB’s. Companies who were in the forefront and who set standards building a webservice management gave importance to deployment much earlier. But market trends and minimally viable products popping out like popcorns made vendors to adopt to what can be quickly built and deployed and in the course forgot about disciplines.

If one were to build service management component for each application owners, there will be more challenges ‘created ‘ than ‘solving’ existing overheads in maintenance.

If not deployed with strict disciplines, ESB can become an overhead. It would pull back enterprise applications backwards to a state much similar to a traditional hub and spoke architecture. This in turn would more challenges than a simple EAI based integration. Whether to be owned by middleware owners within the enterprise or owned by which unit of IT, is something that must be discussed before its deployment. Isn’t ESB a service bus for the enterprise?

Sunny Menon
enterprise.architects@yahoo.com
SaaS Metering