BPM and application eco-system based integration platforms
- Clients are aligning their middleware to the package economy system (SAP, Oracle, Microsoft etc.) with a view that they will have more than one middleware bus that can serve respective economies depending on the alignment
- Clients are evaluating hard for their choices between pure-play integration options like TIBCO, IBM, Biztalk vs. package-centric middleware like SAP XI/PI, Oracle Fusion middleware etc. Some clients are of the opinion that in long run, package-centric middleware will pay off better for them while others are keeping the composite middleware infrastructure including both pure-play middleware as well as package-centric middleware.
Those are signs of changes in my mind. Given that SOA hype is coming down and BPM is taking over (aligned to SOA though), both architecturally as well as product selection-wise, organizations have started thinking different about integration. They are open to break down the barriers of traditional definitions and exploit the technological capability to create newer options. I think it’s high time for such a change. Time has come when clients are taking the control back from vendors and have started driving how they want the technology capability to behave and serve their needs. Same drive is now emerging as a focus for establishing ‘platforms’ for service integration and not just basic technology infrastructure. Platform as a concept has been around for decades. But this is now when organizations are seriously working on creating platforms in true sense, for the middleware part. By moving to a ‘platform’ thinking, organization combine the ‘service-focus’ with enterprise scale and allow enterprise to leverage the capability of the platform in simplest and easiest manner. That’s when some of the features of self-services etc. come in play that I spoke on in my part 2 of the next-generation ICC blog.
So I were to talk about the reference architecture in the new paradigm (scare to call it but Let us use that term for now), it will be something like this:
So here clearly one can see that BPM is core of the architecture city-plan and then aligned to each of the economy of the application landscape is a middleware of the choice. Each of these middleware connect to a central BPM platform that drives the process context and flow. Connection from BPM to ESB is based on service virtualization layer. This is how I see integration architecture shaping up for lot of organizations and to some extent I believe for now, this is a great way to architect the solution.
Comments
Hi Rakesh. I totally agree to your thoughts. But in order to have a holistic solution, I would like to see and visualize these different ESBs to be 'micro ESB' platforms i.e., I still would like to have a single centralized registry and repository, a unified deployment grid, a central monitoring, management and reporting solution for all different ESB platforms in my solution architecture. Otherwise, I have to manage all these separately in different heterogeneous eco-systems and also at the level of BPM platform. So it will be interesting to see how the current technology landscape at different customers can evolve to that holistic view where I can just treat different ESB platforms as coarse granular services orchestrated by BPM platform with QoS and NFRs implementation separated from all ESB platforms into an underlying common denominator Grid or platform.
Posted by: Ankit Aggarwal | May 1, 2009 8:37 AM