BPIOAI Defined

So, what does BPIOAI bring to the application integration table? It's really another complete layer on the stack, over and above more traditional application integration approaches, including IOAI and SOAI (see Figure 3.3). These differences include the following:

• A single instance of BPIOAI typically spans many instances of traditional application integration, including IOAI and SOAI.

• Application integration typically means the exchange of information between two or more systems without visibility into internal processes. BPIOAI defines a master application that has visibility into many encapsulated application services and application information.

• BPIOAI leads with a process model, moves information between applications, and invokes internal application services in support of that model.

• BPIOAI is independent of the source and target applications. Changes can be made to the processes without having to change the source or target systems.

• Application integration is typically a tactical solution, motivated by the requirement for two or more applications to communicate. BPIOAI is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.

Figure 3.3. BPIOAI provides another layer of control over IOAI and SOAI.

BPIOAI by Example

So, it's not clear to you yet? You need to walk through a simple example? No problem. Say you're building a model plane, and you have three main processes:

• First, the process of cutting the parts.

• Second, the process of assembling the parts.

• Finally, finishing the plane (painting and attaching the decals).

These are the higher-level processes; of course, many processes will be contained inside these processes.

In the terms of BPIOAI we can define the three main processes as:

• "Cut Parts."

• "Assemble Parts."

• "Finish Plane."

And we have to build these processes on top of three source and target systems:

1. Inventory (SAP)

2. Sales (Custom Build)

3. Manufacturing (Oracle)

Using the assumptions above we could define "Cut Parts" as a process that is kicked off by a sales event from the Sales system that's posted to the Manufacturing system. We can in turn decompose that "Cut Parts" process down to additional subprocesses if needed (we are not going to do that here). After the parts are cut we let Manufacturing know that the process is complete and it in turn kicks off the process to assemble the parts. Once that is complete, we return information back again to the Manufacturing system, and it kicks off the finishing processing. Once that occurs, the Inventory system is updated with the information on the completed product, and the Sales system is updated with the fact that the product is complete and is ready for shipping.

The key idea here is that the higher-level processes, the meta application in a sense, is driving the processes here, coordinating the exchange of information between the source and target system and abstracting the encapsulated processes up to a higher-level set of processes in support of this business event.

Although this is very simplistic example, it's nonetheless a good depiction of the higher-level activities and concepts of process integration.

Thus, BPIOAI is the science and mechanism of managing the movement of data and the invocation of application services in the correct and proper order to support the management and execution of common processes that exist in and between organizations and internal applications (see Figure 3.4). BPIOAI provides another layer of easily defined and centrally managed processes that exist on top of an existing set of processes, application services, and data within any set of applications.

Figure 3.4. BPIOAI manages the movement of information and the sharing of common process models between trading partners and internal systems, using business-oriented semantics, control logic, exception handling, and the ability to monitor the processes in real time.

The goal of our discussion is to define a mechanism to bind relevant processes that exist between internal and external systems in order to support the flow of information and logic between them, thus maximizing their mutual value. Moreover, we're looking to define a common, agreed-upon process that exists between many organizations and has visibility into any number of integrated systems, as well as being visible to any system that needs to leverage the common process model.

BPIOAI views middleware (e.g., integration servers and application servers), or the "plumbing," as a commodity with the ability to leverage both message-oriented and transactional middleware as points of integration into any number of source or target systems. In fact, most integration brokers and application servers are beginning to offer BPIOAI tools that support their middleware technology.

BPIOAI is the ultimate destination of application integration. Despite current shortcomings, many application integration vendors are aggressively promoting BPIOAI as a vital component of their application integration technology package. In doing so, their strategy is clear they are eager to join the world of high-end BPIOAI modeling tools. They hope that their application integration-enabled middleware, such as integration brokers and application servers, will accomplish just that.

The good news is that most business processes are already automated. The bad news is that they tend to be loosely coupled and exist on different systems. For example, adding a customer to a packaged accounting application may establish the customer in that system, but it may still be necessary to use another system (a different system that may exist within a trading partner) to perform a credit check on that customer, and still another system to process an invoice (see Figure 3.5). You needn't possess exceptional insight to recognize the potential for disaster that exists in this scenario. Not only do these disparate systems need to share information, but also they need to share that information in an orderly and efficient manner.

Figure 3.5. Although many automated processes exist within most trading communities, they tend to be loosely coupled or not coupled at all.

Understanding the Semantics

As we move into the world of BPIOAI, we are finding that the names for particular types of technologies and approaches can be somewhat confusing. As we mentioned earlier in this chapter, no standard definitions exist for these concepts, so perhaps it's time we created them.

• Business Process Modeling (BPM) provides tools and approaches for the graphical design and simulation of business processes. Typically, these tools are not hooked up to existing enterprise processes, but work as pure modeling tools.

• Business Process Automation (BPA) tools and approaches provide mechanisms for the automation of business processes without end-user interaction at execution time. Most application integration tools provide this type of subsystem.

• Workflow tools allow for the automation of business processes with end-user interaction at execution time. These categories of technology and approaches are typically document oriented, moving document information between human decision makers.

• BPIOAI is an aggregation of business process modeling, business process automation, and workflow. This approach implements and manages transactions and real-time business processes that span multiple applications, providing a layer to create common processes that span many processes in integrated systems.

Indeed, the goal of BPIOAI, and of application integration in general, is to automate data movement and process flow so that another layer of BPIOAI will exist over and above the processes encapsulated in existing systems. In other words, BPIOAI completes application integration, allowing the integration of systems not only by sharing information readily, but also by managing the sharing of that information with easy-to-use tools.