BPM-EAI

Well, that was not the case to be. Organizations cannot adopt theoretical models. Even though there were organizational mandates to adopt a uniform middleware, factors like resistance to change, finding benefits in traditional ways of integration, fear of lacking direct ROI for his or her division/project, immature integration products adopted, complexity of products, etc. contributed to some pockets (may be significant sometimes) continuing to adopt non standard integration methodologies. Another factor was differing organization models; for example an organization may have 10 different LOBs (Lines of Businesses) and each one of them may have adopted a different middleware for various reasons. With the advent of “newer” concepts (reference point is a few years back) like BPM, more tools found their way into organizations’ already complicated middleware space. To add to this, every one wanted to jump the SOA bandwagon and this again gave inroads to tools that could do things unthinkable in the past, for example web service enabling applications running on a mainframe. With mergers and acquisitions being the order of the day, integration tools in an organization got to almost unmanageable levels of complexity.

Clearly, the case for consolidating integration exists in organizations today. So, why not move ahead? Benefits are evident – I do not need to elaborate on that. However, the biggest hindrance is the investment required. And in today’s situation, this may be treated a taboo word. The order of the day may be “if it is not business critical, it can wait”. The question is - “Can it?”. The real question should be, “If I do not start acting now, how much more will I have to spend some time later when the my landscape will get even more messier?”. Organizations are feeling the pinch of not having a uniform Integration strategy, again! Isn’t it time that organizations start taking at least baby steps that will be implemented, if not go all out?