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.

The right BPI solution might be also used to replace any batch processing or semi-automated file transfers with real-time interfaces between applications and databases. The result is a robust and efficient operating environment in which computer automation is, once again, making people and their employers more productive.

These are the typical business solutions:

• Streamline manual processes (such as sales order processing)
• Replace batch processing with real-time communication
• Link your back-office and ERP systems to new applications like CRM
• Easily share data between System i, Windows, and Web applications
• Connect any application on any platform via XML Web services

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.

However, the most spectacular profits of productivity will be generated on this type of action. For example, the implementation of a workflow for a validation process of a purchase request brings considerable profits of productivity. By using a Web service, for example, the action of recording the purchase request validated in the ERP will go even further while saving invaluable time and eliminating the risks from keying errors.

Lastly, the ability to be reactive is a key element. It is necessary to be able to adapt the processes according to the internal or external changes of your organization. It is particularly important to integrate these parameters in the implementation methodology of your BPI while building your SOA architecture.

Here some important stages to make a success of this type of project:

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.).

This stage will allow you to identify the automatic processes common to various processes. Then, when building these services, you will be able to anticipate their reusability, while avoiding, for example, strongly specializing them.

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.

The first stage is to designate a person in charge who will ensure the update of the Web services repository available for consumption (description, version, security, etc.) and of their internal and possibly external use to the company. It also helps you to ensure a follow-up of the quality, in particular on the parameter standardization, performance, availability, and security.

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.

A pragmatic approach of these new technologies will allow you to carry out your objectives of business process integration while evolving to the SOA. The effective installation of an SOA requires a certain maturity of the company with respect to the automation of its processes.