BPM-EAI

The first stage of transition, the Dependence stage, is where one is dependent on systems/others for their operations. If we look back, in earlier days, when two applications had a need to integrate, the only way was to do a ‘file’ based transaction. Application A had to open up an FTP-port for Application B to log into, create a separate security level for external parties to log into their system, place the file in the correct directory. Unless these tasks, which are highly dependent on Application A are completed, Application B cannot get the data. Or the other way of doing it was by opening port on B, giving credentials to A, wait for A to “PUT” the data for B to act upon. The amount of dependency on the availability of the systems is very high and typically a nightmare to the operations team of these two application. The thoughts of replay, repost of the data if something fails would be nothing short of panic pangs to the businesses and the application had to have too much of logic in them to ensure no duplication happens.

Then the stage of Independence in the world of EAI arose from the “File” based Dependence; where the “message” based integration became the de facto norm of the day. Application A would “PUT” the data in form of a “message” to a “Broker”, who would ensure that the “message” reaches the Application B. this ensured that both the applications act Independently of each other. This may not be the best way to “integrate”, but did reduce the dependency of the availability of the Applications to Integrate. Application A need not wait till Application B is available to “PUT” or “GET” data, as there is Broker as escrow agency between the both. However, it brought with it, its own baggage; the amount of data that can be exchanged between the two applications is limited to the capacity of the Broker, while an intermediate application added to the latency due to one more “hop” between the systems.

Then the next step of transition to “Interdependence” was ushered into the world of EAI; the world of “Orchestrated Services” with the use of Enterprise Service Bus. Here, all the applications willing to be integrated or to integrate would reach out to the Service Bus, which holds the crux “compose-able” technical/utility services to form “business services”. There would not be a single instance, where something can “live” without depending on any other service, with exception to utility services.

This stage of “Interdependence” (Service Centric Enterprise) paved way to the emergence of another paradigm in Enterprise IT, Business Lead IT. This model of Enterprise IT, where Business Processes play the important role in defining what the Applications should do and how they need to exchange information for enabling a particular Business Function. In earlier models, the Business and IT were like the two horses drawing the cart of Enterprise. With the advent of BPM-led Enterprise IT, it has more akin the Eskimo Dog Sledge, where the Lead-dog is the Business, while the remaining pack would be the IT. The onus of running the IT would be more like a business function, than perceived “cost center” as in earlier models. As with any great change, this model brings with it a great dependency. The BPM based approach, depends highly on the underlying technology infrastructure to be readily available in form of Business Services.

This dependency means, the Enterprise should complete one full cycle of IT Maturity as per Dr. Covey’s model. Though the journey might again begin at a “Dependence” stage, this time it will be in a different context. (Business and IT at tandem Vs. Business lead IT)

We at Infosys have come up with a methodology called BEAM (BPM Enterprise Adoption Methodology) which can accelerate your journey into the world of Business-led IT. For more information about BEAM, please ASK US or Enquire