Infosys’ BPM-EAI blog offers a platform to discuss the latest trends in the Business Process Management and Enterprise Application Integration spaces. Exchange thoughts, ideas and opinions with Infosys experts on how BPM and EAI programs can be leveraged to achieve operational excellence and maximize your return on investment.

« BPM and application eco-system based integration platforms | Main | “Cloud Computing” – A Silver lining in the ‘Clouds’ that helps enterprises battle the economic slowdown »

Distributed ESB or Single ESB - The choice

Now that ESB has become the defacto standard for integration, all of us at some point of architecture definition experience faced situation where we had to make a choice on what will be the preferred strategy for ESB deployment.

Some of us who come with the baggage of older EAI technology tends to think we can make enterprise scalable & adaptable through distributed ESB. I guess the root cause of this lies in the way older EAI technologies worked where components within EAI layer were so interlinked that a small change within EAI layer meant considerable impacts to other components which lead to longer time to deploy changes.

However if we analyze current ESB offerings from existing EAI vendors it is evident that the product offering has matured considerably and these not only provide a highly optimized runtime environment but also componentized the ESB architecture enabling faster changes and deployment. Hence we are forced to rethink the ESB federation approach. In addition ESB also supports the concept of service domain which should be utilized to the fullest extent to separate out the concerns rather than handling through federated ESB.

This does not mean that federation is not required, it is there to stay. A good ESB federation strategy is a key differentiator between an over engineered enterprise and well engineered enterprise. However the problem is that the choice is not a straight forward one, there are lot of factors that needs to be considered before making the right choice. I have come across various factors that drives the choice but after analyzing various situations the factors that I felt were key to the decision making were
 
  1. Clear separation of Organization both external and internal 
  2. Secured access to enterprise information systems 
  3. Business Strategy that leads to outsourcing of business functions - This is one of the interesting areas that has found lot of relevance in the recent time, where organization were able to identify a business area that they want to outsource and made it possible by separating out the key business services through a dedicated ESB layer 
  4. And last the political control within organization. This one I felt was the most trickiest of the all as a wrong choice out here does lead to more federation than required causing a maintenance nightmare

If you are initial adopter of ESB (Starting small) federation strategy should be one of the strategy but it should not be a day one strategy, rather it should be build overtime. This implies we need to plan service deployment on ESB using Service domains and have a transition plan for federation as ESB adoption increases within organization. However if organization is going for a big transformation program ESB federation strategy should be part of Integration architecture strategy from day one. 

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/apps/mt-tb.cgi/461

Comments

Hi Manas. I am a little confused after reading your post. In 'nerdy terms', I will think of ESB federation only if my solution architecture deals with multiple "heterogeneous" ESBs by different vendors. Does federation make any sense when I am talking of only one particular kind of ESB (there may be multiple ESB instances). As in 'one type of ESB' case, I will be talking of service (or business) domains only [The domains can be physically or geographically separated]. Obviously, at a business and architecture level, I can visualize federation more but at a technical level, I will treat multiple ESBs as 'just another service' exposed through some proxy services. Also, different federated ESBs may be based on different underlying architectures (like extended MOM, extended Application Server, extended integration brokers, etc.) and may have a lot of redundant capabilities (at technical level)... In such a case, how can we approach towards a holistic ESB federation architecture? Can there be a tool for the same or will it be another integration exercise from Architecture, Business and IT point of view where we think of interoperating between different ESBs in a federated approach? And the last point related to another post on Infosys blog about 'consolidated integration', can we visualize ESB federation and consolidated integration approach together?

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter