Like most companies, you want to streamline your business, automate manual processes, and expose key functionality to partners and customers. And like most companies, you probably have a mixture of applications and hardware - some new, some old.

Your customer information may reside in a database, but you rely heavily on an AS400 green-screen system for critical business functionality. Other important business functions may be accessible via COM APIs or even as Web services. Without question, integrating these disparate applications and data sources is among your biggest challenges.

There certainly is a lot of hype saying that Web services will provide a cheap and easy solution to this type of integration challenge. Yet Gartner estimates that $1 billion will be wasted on misguided Web service projects by 2007. How much of this will be yours?

Striving for a Business Service-Oriented Architecture
IT departments are talking about SOAs (service-oriented architectures), CBD (component-based development), composite applications, and ESBs (enterprise service buses), but what do they really want? They want a standardized mechanism for exposing business processes so they can quickly and efficiently roll out functionality that supports key company goals. Using Web services is a logical choice.

To do this effectively the Web services must have a business focus and the ability to coordinate the integration of multiple applications and data sources. For example, insurance companies that want to expose a Web service for renewing an auto policy will need to orchestrate interaction between several different applications, including some that may lie outside the firewall. We'll call the environment that supports this business service-oriented architecture (BSOA; see Figure 1).

Creating a BSOA is more of a business-centric exercise than the SOA approach typified by object-oriented practices of encapsulating CICS transactions, J2EE components, SQL queries, and other functionality with Web services or another common interface (see Figure 2). Today's service-oriented architectures lack true business focus because few organizations have managed to expose Web services that can interact with multiple applications in real time. A typical Web service today tends to be data-centric and generally interacts with a single back end. For this reason you are far more likely to see a Web service that invokes an SQL query to retrieve customer information than a Web service that renews an auto policy.

What are the key characteristics of a business-centric service? First, it requires the ability to combine method calls, SQL queries, legacy system functions, and other individual components. To tie these pieces together the service needs business logic - for example, to govern the order of operations and specify the data elements needed from each system or component to fulfill the service at runtime.

A business service for renewing an auto policy might involve the steps and systems shown in Table 1.

At a lower level, the service would require additional logic to dictate what should happen when claims are outstanding, if the policy has lapsed, and so on. A business service that can traverse different paths based on these conditions provides functionality that, if exposed as a Web service, can offer significant value. Similarly useful Web services can be envisioned for providing access to a customer's portfolio, booking a vacation online, or checking inventory levels and placing an order based on the results.

If a company makes all back-end systems conform to the same interface, data-centric Web services may seem valuable because with a uniform interface it becomes considerably easier to write the integration code. But starting a project by wrapping all back-end systems as Web services causes a tendency to over-integrate; there's no intrinsic value in wrapping every component as a Web service. Companies that follow this route will end up with a giant Web services component library. (This is amazingly similar to the architectures that enterprises have spent millions building for years using standardized component models such as CORBA, COM, and EJB.) Before harvesting the functionality from their new library, organizations will need to spend significant time and money writing code in an application server to get the Web services to interact in a meaningful fashion.

This bottom-up approach to integration has never lent itself to rapid ROI and is a far cry from the cheap, easy integration promised by ardent Web services proponents. It is also the primary reason that so many Web service projects are failing - and a chief contributor to the alarming $1 billion figure cited by Gartner. Other trouble spots include lack of industry agreement on a standard implementation, performance issues, security concerns, fault tolerance, and difficulty guaranteeing service-level agreements. This combination of factors makes it easy to understand why the business community is left wondering why the IT people are unable to deliver on the promise of rapid ROI.

Sharpening Focus with BPI
The primary issue is not whether to expose key functionality as Web services, but how to do so selectively and cost effectively. Web services are an excellent paradigm for exposing business-centric services. They are gaining universal support and have the advantage of being vendor and platform neutral, and issues such as security and performance are gradually being worked out.

To take advantage of Web services without venturing down the componentization road of the past, a number of organizations are introducing business process integration (BPI) software into their technology mix. BPI's unique capabilities allow organizations to expose as Web services only the functionality that is actually needed by customers and business partners.

A relative newcomer to the industry, BPI offers a flexible and speedy approach to integration because it does not require sophisticated infrastructure, custom code, or a standard adapter layer. Its most distinguishable feature is a visual modeling environment that allows you to design business processes without programming expertise. This is made possible via point-and-click connectivity to back-end systems, data sources, SQL queries, CICS transactions, Web services, and so on. These connectors eliminate the need for a standard adapter layer and give you the wherewithal to tackle integration projects without wrapping every component with a standard interface.

After you design your graphical process models, the BPI software converts these models to executable programs that at runtime can access multiple applications and perform the business logic you have specified. With a robust execution engine that handles fault tolerance, load balancing, scalability, and security, you are free to expose functionality without additional messaging infrastructure or complicated code that must run under an app server.

BPI does not offer some highly specialized capabilities found in full-blown, multimillion- dollar EAI solutions (such as dealing with enormous volumes of data), but it is an affordable, all-purpose tool that greatly accelerates the pace of integration projects and the ability to deliver rapid ROI. You can swiftly assemble new business processes by piecing together fully functional components and using the graphical modeling environment (see Figure 3) to fill in the blanks with business rules. Not only do you avoid modifying perfectly good legacy applications, you can focus squarely on the functionality required to complete a business transaction and ignore whatever does not contribute directly to the process.

Finally, and perhaps most relevant to companies aggressively implementing Web services, BPI software enables you to expose the same business process using a variety of technologies. Even if your company is ahead of the Web services curve, some segment of your customer or partner base may not be ready to use your Web services. With BPI you can expose processes by using a JSP, ASP, or servlet; or even via a fat client such as a Java application or an Excel spreadsheet. What matters is providing Web access to your business functions; typically, customers and partners don't care about the underlying technology.

A Business Example
Let's examine the business-centric approach to building an SOA via our earlier example of renewing an auto insurance policy. Using the BPI approach you begin by analyzing the existing (often manual) business process for policy renewal and determining the systems involved. You then design the process using the graphical modeling tool; your model will include a sequence of activities outlining the steps each system will perform, the data that must flow between the various applications, and business rules that handle logic not performed by any one back-end system.

Note that this approach keeps the focus almost exclusively on business functionality. For example, the first step is retrieving the policy details, which means you are dealing with only a tiny slice of the sweeping functionality provided by your policy administration system. The same is true for your claim system: you are interested only in a single policy's claim history; all other functionality provided by this system is irrelevant and does not need to be componentized.

Next, using point-and-click wizards you connect the first step in your graphical model to the function in the policy administration system that fetches policy information and continue this exercise until each step in the model is bound to the corresponding system or data source. To ensure high performance, BPI uses the most appropriate technologies for connecting to back-end systems, so for example if the claims system already has an MQSeries interface, the adapter will use a message queuing technology. By contrast, the data-centric approach would first require you to wrap the claims system in a Web service. In addition to the extra work, this often has a negative effect on performance by making the connection to the claim system slower than using its native MQSeries interface.

When you are ready to test your automated processes, you deploy the visual models and connectors to the engine's repository. No additional middleware technology, app servers, or custom code are required; the processes are ready to execute immediately.

After this you are ready to expose your processes to customers and partners - as Web services for those who can embrace Web service technology; and for those who cannot, perhaps directly from an agency management system or as a JSP. You can also take advantage of BPI security features to allow access at the business process level to authorized users, and thus avoid exposing internal functionality to the outside world.

Finally, you can take advantage of BPI's monitoring capabilities to analyze the execution of your processes and make any adjustments necessary to fine-tune performance.

Delivering ROI
Web services continue to garner universal vendor support and are clearly here to stay, but this does not mean they can magically solve every integration challenge. The organizations that will experience the most success with Web services are those that use them strategically, where they make sense in the context of the business.

IT departments that resist the urge to build an expensive component library and take full advantage of complementary technology such as BPI will find that it is possible after all to improve service and deliver on their promises of rapid integration - and rapid ROI - to the business community.