|BPI and SOA Working Together|
|Programming - Change Management|
|Written by Dominique Thomas|
|Sunday, 11 November 2007 19:00|
One option is to implement a services directory through UDDI. But market analysts and software providers agree that this is still insufficient. The related projects are usually targeting services publication; those services have no interaction and are acting as APIs to access back-end systems.
Enter BPI, the Buzzword Companion of SOA
Business process integration (BPI) is the opportunity to refine or reinvent business processes to make an organization more effective. While these two buzzwords—SOA and BPI—seem to make unlikely bedfellows, they are inextricably linked, and SOA is a key enabler in propelling BPI initiatives within an organization. It is predicated on the strategy that existing systems can expose their functions and data as services and that interfaces can be built on top of these services and tailored to specific business processes. To use a practical example, this means that a set of screens in a Web application can access multiple services powered by multiple legacy applications. From a user perspective, this means that the user will go through a single interface that is aligned with the business process and not have to interactive with the multitude of underlying legacy applications.
To remember one of the SOA's laws, it is recommended that a service carry out a unit treatment in order to improve its reusability in various, more-complex treatments, also called business processes. It is thus essential to have tools and standards in order to model and to orchestrate the execution of the various services.
From a marketing point of view, orchestrating Web services is a little too abstract for companies. To optimize businesses process is much more explicit. The software publishers of EAI, ESB, XML, and Web services solutions naturally moved toward SOA while bringing a clear response to a customer need. However, the majority of this software remains specialized in the workflow of automatic treatments: They are only managing totally automated processes—in synchronous or asynchronous mode. One thus remains in the universe of the EAI. From a technical point of view, the SOA is a formidable platform for business process integration. Indeed, the majority of BPI solutions can consume Web services to carry out automatic treatments.
So, What Are the Right BPI Solutions Requirements?
The right solution will take a top-down, process-centric approach. The goal is to automate manual processes and eliminate re-keying of data by reducing the amount of paper, email, fax, and human interaction required to complete a given business process. In business, we find that one of the main obstacles to achieving more operational efficiency is actually knowing which tasks are performed when, by whom, and under what circumstances. A lot of process expertise is carried around in people's heads, some is written down, and very little is properly codified and automated. Your BPI solution should enable you to capture, model, and implement a set of automated processes that, like robots on a factory floor, are more predictable and foolproof than their manual predecessors. It will add new graphical mapping and process orchestration tools to create a truly code-free environment. A business analyst, or a similarly skilled person, will be able to design a solution in conjunction with end-user domain experts without requiring programming expertise.
Managing Your BPI Project by Thinking SOA
It is still premature to imagine the installation of business processes where all the actions are entirely automated. On the contrary, collaborative management of projects and outsourcing generate a significant number of human actions (particularly approval processes). In the majority of the administrative processes, actions you can automate in the form of Web services are still the minority.
Carry Out the Inventory of Your Processes
Most of the time, your BPI project is limited to a single process implementation. It is, however, very interesting to take a step back and look at the global execution of your processes across the whole enterprise (by department, fields, etc.).
Work by Version of Process
To automate a process with an orchestration engine is already a major profit of productivity and quality of service. When that is possible, it is relevant to launch a "version one" (for a proof of concept) with simple Web services. Releasing version one of your Web service will identify possible improvements or changes compared to what was planned initially.
Assign an SOA Manager
The number of Web services will increase quickly, as will the Web services consumers. As with a database, it is important to organize the administration of your Web services library.
BPI First; SOA Second
Is it necessary to set up SOA before using a BPI? No. In fact, it's not recommended. Indeed, the BPI project will make it possible to model the processes of the company precisely and to emphasize the automatic treatments that will be the future Web services of your SOA. The implementation of a BPI solution is the natural step to help evolve your information system to a SOA. Moreover, from an end-user point of view, a Web service remains something difficult to materialize. Chronologically, you can thus meet the immediate needs for optimization of your processes with a BPI engine to optimize your automatic treatments by building an SOA.