BPM-EAI

One such trend that has caught my fancy over a couple of years now is Composite Applications and their applicability in the integration space. While various definitions and interpretations exist for the term, in principle a Composite Application is one that is created by combining multiple existing enterprise functions, services or components. This is done to leverage IT investments by gradually integrating business services provided by enterprise applications and even business partners.

While the term itself is not restrictive to SOA – there could be a strong case of a composite application on legacy platforms on mainframes too – it is particularly relevant today, when large enterprises have been making substantial investments in creating service enabled applications, leveraging Service Oriented Architecture in various forms. It also becomes imperative for Composite Applications to incorporate some extent of orchestration between the various components/services being assembled together. Thus, the composite applications today have come to be the culmination of most developments in the Service Oriented Architecture and the EAI space over the last decade or more.

One could argue that the concept of Composite Applications looks antithetical to Enterprise Application Integration, the latter being focused on enabling integration of discrete applications. But like it has been in the past, it’s not only the large enterprise application players that are gearing their product suites to this latest trend, but the pure play EAI vendors have accorded it an important status too. Needless to say a key ingredient of the Composite Application paradigm is an enterprise service that can be assembled into a Composite in a de-coupled manner that supports scalability, both horizontal and vertical.

All the top product vendors in the footprint of the BPM/EAI practice have made their intentions clear on how Composite Application development is a key focus area for the coming years. The main names that I can immediately recount at the risk of missing a comprehensive roster are:

• SAP Netweaver Composition Environment (7.1)
• IBM Websphere Business Services Fabric
• Tibco Composite Application Bundle
• Oracle Application Integration Architecture
• Sun Java Composite Application Platform Suite (Java CAPS)
• webMethods BPMS

Each of the above suites is backed by a strong integration platform either indigenously developed or acquired. But in my view it will be the availability of a plethora of enterprise services (enabled to be assembled into a composite application) that will act as the key differentiator in this new Service Oriented paradigm. In absence of that, the platforms are likely to become glorified versions of the integration and BPM suites that they are based on. It is no wonder then that the list of pure play EAI vendors making inroads into this space is not as large as some of us thought.

On the other hand, the market could still stay fragmented for a few years with one set of vendors specializing in tools to enable SOA, while the other set of vendors specialize in providing those services to the SOA. The possibility of this happening is low as enterprises realize the eventuality of sooner or later moving to the application suites provided by the big boys of enterprise applications, the ERPs. So while on one hand we have a Tibco Composite Application Bundle that combines Active Matrix complementing the Business Works suite, IBM’s vast array of Composite Application frameworks ranging from portal to Notes to Business Service Fabric,  SAP’s version of eSOA –“ pre-delivered services based on SOA rather than the development toolkit alone “- being delivered through the new Composition Environment definitely paves the way for an exciting matchup.

It remains to be seen whether the pure play vendors like Tibco, Sun (after the Seebeyond acquisition into JCAPS) can hold their ground by virtue of more effective dealing of common challenges like:

• Interoperability to create true enterprise service reuse, through industry standards like Service Component Architecture
• True de-coupling of the enterprise services in question, in order to remain truly scalable
• Availability to leverage existing BPM/EAI, to avoid creation of new enterprise service spaghettis