How to pick an ESB? An Enterprise Service Bus Evaluation Framework

All Enterprise Service Bus (ESB) products may be used to build and deploy services, encapsulate legacy systems, route messages, transform message formats, and perform protocol mediation.  Many WSO2 prospects ask me ‘What differentiates WSO2 Enterprise Service Bus?’  This blog post shares my perspective and scales the conversation.

PROMOTION: WSO2 Advantage Webinar : ESB Evaluation Framework

In this session, Chris Haddad will describe how your organization can wisely select integration infrastructure components and products. Chris will present an integration reference architecture decision framework and product selection guidelines.

Register Now

 

Integration teams use ESBs to solve service-oriented anti-patterns of isolation, uniqueness, and duplication.  Isolation refers to stand-alone system silos and point-to-point connections between systems (as opposed to shared connections).  Unique data schema models for similar entities, transactions, and processes raise integration cost.  When an organization fields multiple software applications delivering similar business functions and requires redundant data entry, opportunities exist to remove duplication and save both operational expense and maintenance cost.

To reduce service-oriented anti-patterns, teams desire to share and re-use assets, consolidate functionality, and conform projects to common standards.   To achieve these best practices, teams rely on an ESB to deliver the following required architectural attributes:

  • Interoperability
  • Abstraction
  • Resource location virtualization
  • Ability to scale and manage service
  • Declarative policies and platform independent models
  • Separation of concern
  • Loose coupling

Architectural attributes are hard to measure, and we find most evaluation teams do not develop evaluation use cases across all architectural attributes.  Teams often focus on easy identifiable product features.  ESB products may contain the following required and optional features:

Required features

  • Routing
  • Protocol bridging
  • Message transformation
  • Service agent hosting

Optional features

  • Resource adapters
  • Composition
  • Orchestration
  • Reliable message delivery
  • Event processing
  • Transactional integrity
  • Message Exchange Pattern (MEP) mediation
  • Dynamic location and binding, load balancing
  • Message validation
  • Capability mediation
  • Security mediation (federation)
  • Tooling

After creating use cases testing an ESB’s ability to deliver architectural attributes and features, an ESB evaluation process should also consider how the ESB fits into the complete platform.  An ESB is usually just a single component in a broader composite SOA Platform.   Teams often combine an ESB with Governance Registries, Identity Servers, Business Activity Monitoring, Complex Event Processing, and Business Process Management.  Teams often differentiate ESBs based on how well the ESB fits into a complete solution.  A platform built by vendor innovation instead of vendor acquisition will often provide a more holistic and cohesive experience by sharing meta-data, administration consoles, programming models, and foundational features (i.e. logging, security, management, provisioning).

Performance, scalability, and topology strongly influence solution agility and adaptability.  We see organizations evaluating how well ESB candidate products fit across hybrid Cloud environments (i.e. on-premise, outsourced, internally managed, externally managed [1]), high transaction loads, and low latency use cases.  Teams should devote ample time to build suitable performance, scalability, and topology tests.

A Proof of Concept project provides an opportunity to ‘kick the tires’ and evaluate the ESB’s ability to satisfy use cases.   Rather than simply relying on vendor demos, download the bits and directly experience the ESB’s programming model, administration interfaces, documentation, and samples.   During the Proof of Concept project, carefully evaluate the vendor’s support processes, openness [2], responsiveness, and ability to recommend suitable solutions.

By carefully considering your requirements, constraints, and technology strategy, your team can build an ESB evaluation framework demonstrating product similarities and strategic differences.  A comprehensive, weighted evaluation criteria set will ensure the ESB meets your needs today and in the future.  An evaluation framework mindmap is shown below:

ESB Evaluation Framework

Enterprise Service Bus Evaluation Framework

 

How well does your current Enterprise Service Bus match your framework and use cases?  I have published an ESB Comparison post, which compares various open source ESB and proprietary ESB offerings.

 

[1] http://blog.cobia.net/cobiacomm/2011/11/07/know-your-cloud-dimensions/

[2] http://blog.cobia.net/cobiacomm/2012/03/14/value-openness/

 

PROMOTION: WSO2 Advantage Webinar : ESB Service Bus Use Cases

In this session, Chris Haddad will describe how your organization can wisely select integration infrastructure components and products. Chris will present an integration reference architecture decision framework and product selection guidelines containing:

  • Use cases driving integration platform component and integration framework selection.
  • Common Request for Proposal (RFP) categories and line items.
  • Tools describing when to include an ESB, integration framework, or alternative integration platform components (i.e. Data Services Server, API Manager, Governance Registry).
  • WSO2 client adoption patterns and success stories.

Register Now

 

 

 

 

One thought on “How to pick an ESB? An Enterprise Service Bus Evaluation Framework

Leave a Reply