BPIOAI is best defined as applying appropriate rules in an agreed-upon, logical, multistep sequence in order to pass information between participating systems and to visualize and share application services, including the creation of a common abstract process that spans both internal and external systems. This definition holds true whether the business processes are automated or not. BPIOAI may be best defined through an example. Companies A, B, and C participate in a trading community. Company A produces parts for skateboards, while Company B assembles and tests the skateboards, and finally, Company C sells the skateboards. Each has its own native set of processes and its own internal systems: a production system, an assembly system, and a sales system. Until now, automated integration has been nonexistent, and mail and fax provide communication between the companies. In order to integrate these applications, the trading community has decided to implement BPIOAI by defining a common process model that spans all companies and internal systems. This process model defines a sequence and logical order of events from the realization of consumer demand, the purchase of raw materials, the creation of the parts, the assembly of parts into a product, the testing of the product, and finally, the sale of the product to the ultimate consumer (see Figure 3.6). Figure 3.6. Creating a skateboard.This common model integrates with local systems by having visibility into their internal application processes, if possible, or perhaps through more primitive layers, such as the database or application interface. What's important is that the common process model can produce events that are understood by the systems participating in the process, as well as react to events that the applications communicate back to the BPIOAI engine. This model must also account for exceptions that come up and handle them accordingly. Moreover, this model must maintain state, perhaps over a long period of time: days, weeks, and months. The use of a common process model that spans multiple systems and companies for application integration provides many advantages, including:
By visualizing enterprise and cross-enterprise processes within internal and external systems, business managers can become involved in enterprise integration. The use of graphics and diagrams provides a powerful tool for communication and consensus building. Moreover, this approach provides a business-oriented view of the integration scenarios that illustrates real-time integration with the enabling middleware or points of integration. This visualization enables business analysts to make changes to the process model, implement it within the enterprise or trading community, and, typically, not involve the respective IT departments.
Interface abstraction refers to the mapping of the BPIOAI model to physical system interfaces and the abstraction of both connectivity and system integration solutions from the business analyst. BPIOAI exists at the uppermost level in the application integration middleware stack. Those who use BPIOAI tools can view the world at a logical business level and are not limited by physical integration flows, interfaces, or adapters. What's more, the middleware mechanisms employed are also abstracted and are not a concern of the business process analyst, as long as the common process model is interacting correctly with all source and target systems that exist within all companies. Although each BPIOAI tool and project may take a slightly different approach, the internal process of interacting with the physical systems typically consists of the following set of events.
Another way to view and execute the process is by defining the hierarchy of processes within the business process model. This means that smaller subprocesses can be linked at the lower tier of integration or are native to the source or target systems. This is called nesting (see Figure 3.8). Building up from the lower-level processes to the higher-level processes, you may link the subprocesses into higher-level processes within the domain of the enterprise or trading community. You may also decompose from the higher-level processes to the lower-level processes. Figure 3.8. Nesting within a business process model.The measurement of business process performance enables BPIOAI to analyze a business in real time (see Figure 3.9). By leveraging tight integration with the process model and the middleware, business analysts can gather business statistics in real time from the enterprise or trading community for example, the performance of a supplier in shipping goods to the plant and the plant's ability to turn those raw materials into products. Figure 3.9. Process monitoring.Moreover, BPIOAI enables the technology user to track and direct each instance of a business process for example, processing individual orders or medical insurance claims through a life cycle that may consume seconds, minutes, hours, days, or weeks. Finally, we need to measure and maintain contextual information for the duration of a process instance that spans many individual activities. In general, BPIOAI logic addresses only process flow and integration. It is not traditional programming logic, such as user interface processing, database updates, or the execution of transactions. Indeed, in most BPIOAI scenarios, the process logic is separated from the application logic. It functions solely to coordinate, or manage, the information flow or invocation of application services between many source and target applications that exist within organizations (see Figure 3.10). Figure 3.10. The process logic coordinates the movement of information, and the invocation of application services between many connected applications or data stores.Such a system operates on three levels of technology (see Figure 3.11). At the uppermost layer is the BPIOAI level. Here, the BPIOAI modeling tools and engines exist, and the application service of information movement is defined. Figure 3.11. The three layers of BPIOAI.At the next level the transformation, routing, and rules-processing layer information movement and formatting occur. Usually, this layer is an integration broker or perhaps a B2B exchange server, but it could also be transaction-oriented middleware and even Web services. The only requirement here is that we employ middleware technology or interfaces that can work with the BPIOAI engine. Typically, the BPIOAI engine interfaces with these various sets of enabling technology through adapters or APIs. The adapters or APIs abstract the native interfaces and/or middleware for the BPIOAI engine, allowing the BPIOAI analyst to deal with all systems using a common set of process and business semantics. The bottom layer is occupied by the messaging system, which is responsible for moving information between all connected applications. Although application servers and other enterprise middleware function here, this layer is generally dominated by message-oriented middleware or servers that use standards-based messaging such as XML or EDI. This schema graphically demonstrates that the most primitive layers reside at the bottom, while the more sophisticated layers reside at the top. Information ascends through the layers from the source system where it is processed, and descends to the target system where it is delivered.
Over the years, many existing business processes have been automated with fair success. But as we have seen with the application integration problem, the problem of how these systems will share information between companies has not received the same attention. |