Drilling Down on BPIOAI?

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.

graphics/03fig06.gif

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:

  • Modeling, or the ability to create a common agreed-upon process between computer systems, automating the integration of all information systems to react in real time to business events such as increased consumer demand, material shortages, and quality problems

  • Monitoring, or the ability to analyze all aspects of the business and enterprise or trading community to determine the current state of the process in real time

  • Optimization, or the ability to redefine the process at any given time in support of the business and thus make the process more efficient

  • Abstraction, or the ability to hide the complexities of the local applications from the business users and have the business users work with a common set of business semantics

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.

Types of Processes

There are three types of processes to visualize enterprise and cross-enterprise processes: internal, shared, and specialized processes.

  • Internal processes exist at the intracompany level, allowing the business user to define common processes that span only systems that are within the enterprise and not visible to the trading partners or to community-wide processes. For example, the process of hiring an employee may span several systems within the enterprise but should not be visible to processes that span an enterprise or trading community or other organizations.

  • Shared processes exist between companies and consist of a set of agreed-upon procedures for exchanging information and automating business processes within a community.

  • Specialized processes are created for a special requirement, such as collaboration on a common product development effort that only exists between two companies and has a limited life span.

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.

  1. The source system that exists inside a company posts an event to the BPIOAI engine for example, a skateboard is sold.

  2. The event is transformed, if required, so it adheres to a standard set of business semantics and information processing mechanisms (synchronous versus asynchronous). This will be engine dependent, but a common set of process semantics and information processing mechanisms must always be defined at the engine level so the analyst can make sense of a business process that spans many types of applications, platforms, and databases.

  3. The BPIOAI engine reacts to the event, once transformed, invoking other processes in other systems to support execution of the common B2B process model. For example, if a skateboard is sold, it then sends an order to the skateboard assembler, posting an event from the process engine to the assembler's target system, typically over the Internet.

  4. Based on receipt of that event, the local system reacts in accordance with its internal processes and posts an event back to the process engine (say, when the skateboard is assembled).

  5. The common process model sequences the master process, sending and receiving other events in support of the common B2B process model. This is an ongoing activity, with information moving up to the process engine from the local systems, transformed if required, and moving down from the process engine to the local systems in support of the execution of the process model (see Figure 3.7).

    Figure 3.7. Steps in a typical BPIOAI process.

    graphics/03fig07.gif

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.

graphics/03fig08.gif

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.

graphics/03fig09.jpg

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.

graphics/03fig10.gif

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.

graphics/03fig11.gif

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.

BPIOAI Standards

Although they are covered later in this book, it's helpful to take a quick look at some standards that provide common mechanisms and semantics for BPIOAI.

RosettaNet. A process-oriented standard created for the technology industry that defines a set of high-level business process flows called Partner Interface Processes (PIPs), which are exchanged and managed between trading partners.

ebXML. Electronic Business Extensible Markup Language (ebXML) is a joint venture between the United Nations Body for Trade Facilitation and Electronic Business and the Organization for the Advancement of Structured Information Standards (OASIS), which are developing a framework for using XML to exchange business data with visibility into common processes.

BPML. The Business Process Modeling Language (BPML) is a meta-language for the modeling of business processes, just as XML is a meta-language for the modeling of business data. BPML provides an abstracted execution model for collaborative and transactional business processes based on the concept of a transactional finite-state machine.

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.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net