Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Tuesday, December 27, 2005

Changing Middleware Requirements and ESB

Rise of ESB, when I read the title, I rememebred the "Rise of the Machines" The Terminator sequel, a bigtime flop. I am not sure if it made any business but I could see that is was a worst sequel ever. Hope this does not happen to ESB.
Anyways, changes are always forbidden, nobody likes the change, but when customer demands and competition gets tough, everybody changes. So is middleware now, there are so many changes are demanded. Middleware is no more the same, it is treated as an integral part of the big time weapon called "Business Process Management". People are considering to use the BAM products, BPM (I love to use BPM for Business Process Management than Business Process Modeling) and trying to fit that in some context or other near to the Middleware.
Ideally, Middleware WAS not to have anything to do with Business processes. It used to be totally independent of all the activities in intefracing world. Although due to its central position, it is becoming the key for the all sorts of such fancy ideas for improving business processes. I am still not sure, if somebody has ever explored a possibiliy of improving iterfacing systems for all those things than clubbing (jamming) those in Middleware. It is just a thought.
Every thought is around the cost, scalabilty and solution complexity. All major vendors are trying to resolve those but what if these new technologies are going to make middleware more complex. I agree with David Kelly here as
"Simpler products to address the same complex problems" - In most integration cases it’s really not that possible to eliminate complexity out of the picture—the complexity is there in real world and it has to be addressed. However, the products that address it should be standards-based, easy-to-use, intuitive, and productive. That is where EAI solutions have typically failed - the complexity of the problem was all too apparent in the product and organizations had to invest huge sums in proprietary skills to solve it. Scale as you grow architecture – Organizations are looking for an integration solution that starts out letting them tackle the less complex, more straightforward integration problems with a lightweight integration solution while having the architecture and capacity to scale to very large, sophisticated, and transaction-intensive requirements. Reduced training, resource, and investment costs—The harder it is for an organization to buy into an integration solution and start deploying successful integration solutions, the less likely it will fit today’s requirements.