Enterprise Process-Centric: Select Application pattern

Then, select from the following Enterprise Process-Centric application patterns the design that best addresses the specific requirements of your solution.

Legend for Enterprise Process-Centric application patterns

The Stand-Alone Single Channel application pattern provides a structure for applications that have no current need for integration with other systems and need only focus on one delivery channel. While this Application pattern can be used to implement any one of the delivery channels, the following discussion focuses primarily on the Web delivery channel.

The Direct Connection application pattern represents the simplest interaction type and is based on a 1-to-1 topology. It allows a pair of applications within the organization to directly communicate with each other. Interactions between a source and a target application can be arbitrarily complex. Generally, complexity can be addressed by breaking down interactions into more elementary interactions.

More complex point to point connections will have modeled connection rules such as business rules associated with them, as shown above. Connection rules are generally used to control the mode of operation of a connector depending on external factors. Examples of connection rules are:

• Business data mapping rules (for adapter connectors)
• Autonomic rules (such as priority in a shared environment)
• Security rules
• Capacity and availability rules

The Direct Connection application pattern has two variations:

• Message Connection variation
• Call Connection variation

All applications of the Direct Connection application pattern will be one variation or the other. The variation required depends on whether the initiating source application needs an immediate response from the target application in order to continue with execution.

Both variations may be used either with synchronous or asynchronous communication protocols. However, there are preferences for a specific protocol type depending on the variation. For example, the Call Connection variation has a more natural fit with synchronous protocols while the Message Connection variation favors asynchronous protocols.

Business and IT Drivers

The business and IT drivers for choosing the Direct Connection application pattern are to:

• Improve the organizational efficiency
• Reduce the latency of business events
• Support a structured exchange within the organization
• Support real-time one-way message flows
• Support real-time request/reply message flows
• Leverage existing skills
• Leverage the legacy investment
• Enable back-end application integration
• Minimize application complexity

The primary goal is to allow one application to gain direct and real-time access to another in order to reduce the latency of business events.

Solution

Select this Application pattern

For a legend, please see above

This Application pattern, as shown in the figure above, is divided into a number of logical components:

• The Source Application represents one or more applications that are interested in initiating an interaction with the target application.
• The Connection is the line between the source application and the target application representing a point-to-point connection between the two applications.
• The Connection Rules represent any business rules associated with the connection, such as data mapping rules and security rules.
• The Target Application represents a new application, a modified existing application, or an unmodified existing application. This application is responsible for implementing the necessary business services.

Guidelines for use

Direct integration between applications can be inflexible, in that any changes to one application may have knock-on effects on other applications. Changes to the target application may also require changes to the source application. Such changes can become both expensive and time consuming, especially when the target application is being accessed by a number of different source applications.

Different IT departments may also be responsible for developing and maintaining the source and target applications. Under such a scenario, development might be difficult to coordinate, especially if the interfaces between the applications being integrated are not properly defined and documented. Because of this, it is important to clearly define such interfaces in advance.

Benefits

The Direct Connection application pattern offers the following benefits:

• It works with applications that have simple integration requirements with only a few back-end applications.
• It increases the organizational efficiency and reduces the latency of business events by providing real-time access to business data and business logic, and avoiding manual synchronization of data between applications.
• Direct access to back-end applications reduces the duplication of business logic across multiple tiers. As a result, changes to business logic can be made in one tier rather than in multiple applications.
• It can enable re-use of investments already made with the organization.

Limitations

Although this is a reasonable starting Application pattern for integrating applications in a one to one relationship with one another, this pattern will result in a many to many "spaghetti" configuration with point to point integration mappings for each application pair. Also, the expansion of this implementation into a multi-point configuration will require additional application logic to handle the coordination.

This pattern cannot be used for intelligent routing of requests, decomposition and re-composition of requests, and for invoking complex business process workflow as a result of a request from another application. Under such circumstances, you should consider a more advanced Application pattern, such as Broker or Serial/Parallel Process.

Putting the Application pattern to Use

ITSO Electronics, an electronics retailer/wholesaler, wants to integrate their retail and wholesale departments. Currently, both organizations have proven IT infrastructures but have no interconnectivity. The first process ITSO Electronics wants to focus on is the inventory and order replenishment process. Currently, the items sold are tallied at the end of the month by the retail ordering process and delivered to the wholesale organization by internal mail. This creates a lag in the inventory replenishment process and causes many out of stock situations. A primary business goal is to minimize the loss of sales due to out of stock situations. To meet these requirements ITSO Electronics chooses the Direct Connection application pattern.

For a legend, please see above.

The Message Connection variation, shown in the figure above, applies to solutions where the business process does not require a response from the target application within the scope of the interaction.

Business and IT Drivers

The business and IT driver for choosing the Message Connection variation of the Direct Connection application pattern is to:

• Support real-time one-way message flows

The main driver for selecting this variation is when the business process has no interest in the result of the operation. This variation also has the most natural fit when message-oriented middleware is used, such as IBM WebSphere MQ.

Putting the Application pattern to Use

In our scenario the retail department of the ITSO Electronics organization needs to notify the wholesale department to update their inventory records when a part needs to be ordered. The retail department does not require any acknowledgement of this request. To meet these requirements ITSO Electronics chooses the Message Connection variation of the Direct Connection application pattern.

For a legend, please see above.

The Call Connection variation, shown in the figure above, applies to solutions where the business process depends on the target application to process a request and return a response within the scope of the interaction.

Business and IT Drivers

The business and IT driver for choosing the Call Connection variation of the Direct Connection application pattern is to:

• Support real-time request/reply message flows

The main driver for selecting this variation is when the business process does require a result message from the interaction.

Putting the Application pattern to Use

In our scenario the retail department of the ITSO Electronics organization needs to be advised by the wholesale department of the expected delivery date of a part on order that is out of stock with the retail department. To meet these requirements ITSO Electronics chooses the Call Connection variation of the Direct Connection application pattern.

The Broker application pattern, shown in the figure above, is based on a 1-to-N topology that separates distribution rules from the applications. It allows a single interaction from the source application to be distributed to multiple target applications concurrently. This application pattern reduces the proliferation of point-to-point connections.

The Broker application pattern applies to solutions where the source application starts an interaction that is distributed to multiple target applications that are within the organization. It separates the application logic from the distribution logic based on broker rules. The decomposition/ recomposition of the interaction is managed by the broker rules tier.

The Broker pattern reuses the Direct Connection pattern to provide connectivity between the tiers. The Broker Rules may support Message variation or Call variation (or both variations) of the Direct Connection pattern.

The Broker application pattern was previously known as the Aggregator application pattern for read intent calls and the Broker application pattern for Messages and update intent calls. However, this distinction was found to be of insufficient value to warrant a separate pattern - and so it has been dropped from the revised PI patterns.

The Broker application pattern is also used as the Application pattern for the Pub/Sub Runtime variation which can be found here.

Business and IT Drivers

The primary business driver for selecting this Application pattern is to allow one application to interact with one or more of multiple target applications. Using a hub-and-spoke architecture instead of a point-to-point architecture allows for the seamless integration of applications while minimizing the complexity. A request for information can be routed to one of many targets or simultaneously to multiple targets. The resulting request message can be decomposed into multiple request messages, and the reply messages then recomposed into a single reply message using appropriate recomposition rules.

This externalization of routing, decomposition, and recomposition rules from individual source and target applications increases the maintainability and flexibility and reduces the enterprise wide integration complexity.

This Application pattern is particularly important when a processing request requires execution of multiple interactions concurrently, or where the source application should be relieved of the need to know anything about its targets.

The primary IT driver for selecting this Application pattern is to allow loose coupling of clients and services with minimum modification to each. The solution should allow for multiple transmission protocols to be used and for transformation of protocols between client and service.

Solution

Select this Application pattern

For a legend, please see above.

This Application pattern, as shown above, is divided into a number of logical components:

• The Source Application tier represents one or more applications that are interested in interacting with the target applications.
• The Broker Rules tier reduces the proliferation of direct connections. In addition, it supports message routing, decomposition and recomposition, message enhancement and transformation. These rules are often captured as business rules that govern the behavior of the broker tier. This tier also uses a work-in-progress data store to retain the intermediate results from the responses coming back from target applications until all the necessary responses are received.
• The Target Application tier represents new, modified existing, or unmodified existing applications. These applications are responsible for implementing the necessary business services.

Guidelines for use

To increase the flexibility of the solution and responsiveness to changing business requirements, it is recommended that particular attention is paid to definition of reusable messages/services that pass through the Broker tier.

Robust transaction processing systems should be used to implement the back-end applications to ensure availability, scalability, and performance.

A decomposition implementation (one source call to multiple target calls) requires state persistence and re-composition of the response messages. Standards should be used where possible to minimize future changes required to the source and target applications.

Benefits

The benefits of this Application pattern are:

• It allows the integration of multiple, diverse applications.
• It minimizes the impact to existing applications.
• The Broker tier provides routing services, relieving the source application from being aware of the target application.
• The Broker tier can provide transformation services that allow the source and target to use different communication protocols.
• The Broker tier can provide decomposition/recomposition of messages, allowing one request from the source to be satisfied using multiple target applications. The fact that the response is a composite of multiple requests and responses is hidden from the source application.
• The Broker tier minimizes the impact of changes in location of the target application.

Limitations

Logic must be implemented at the broker for routing and decomposition/recomposition tasks.

Putting the Application pattern to Use

ITSO Electronics consists of multiple Retail stores and Wholesale departments. The Retail stores get their supplies from the Wholesale departments and have a need to request the delivery dates of those supplies before ordering. Currently there is no integration of the Retail and Wholesale applications. All interaction between the two are done over the phone or by mail. A solution must be found to allow Retail stores to request delivery dates from the Wholesale departments. To eliminate the need for the Retail departments to know which Wholesale department carries which supplies, a Broker is needed to take incoming requests and direct them based on part numbers to the Wholesale department that carries them. In the event that a part is carried by multiple Wholesale departments, the broker must get delivery dates from each and return the best date and the Wholesale department that can supply it to the Retail department.

The Router variation of the Broker application pattern, shown in the figure above, applies to solutions where the source application initiates an interaction that is forwarded to at most one of multiple target applications.

Where the Broker application pattern enables 1:N connectivity, the Router application pattern enables 1:1 connectivity where the Router Rules tier selects the target.

The Router variation of the Broker application pattern was previously known as the Router variation of the Aggregator application pattern. [The Aggregator application pattern facilitates multi-point request for information integration between applications.]

Business and IT Drivers

The primary business driver for selecting this Application pattern is similar to that of the Broker application pattern. The difference lies in the fact that the Router tier routes the request to only one of multiple target applications. The requirement for transformation of message and interface format still applies. Externalizing the routing from individual source and target applications increases the maintainability and flexibility and reduces the enterprise wide integration complexity.

This Application pattern is particularly important when a processing request requires the source application to be relieved of the need to know anything about its targets.

The primary IT driver for selecting this Application pattern is to allow loose coupling of clients and services with minimum modification to each. The solution should allow for multiple transmission protocols to be used and for transformation of protocols between client and service.

Solution

Select this Application pattern

For a legend, please see above.

This Application pattern provides a routing function to allow any attached (initiating) application using a single router link to connect to one of multiple target applications. While access to multiple applications is supported, at any given time an application is connected to only one other application. This Application pattern, as shown in the figure above, is divided into a number of logical components:

• The Source Application tier represents one or more applications that are interested in interacting with the target applications, one target at a time.
• The Router Rules tier represents any business rules associated with the message handling, such as routing and transformation. It receives requests from multiple source applications and routes them intelligently to the appropriate target applications. The resulting integration is essentially a point-to-point connection between source and target. This tier implements minimal business logic.
• The Target Application tier represents new, modified existing, or unmodified existing applications. These applications are responsible for implementing the necessary business services.

Guidelines for use

The guidelines for this application pattern are the same as those for the Broker application pattern.

Benefits

The benefits of this Application pattern are:

• It allows the integration of multiple, diverse applications
• It minimizes the impact to existing applications
• It provides routing services, relieving the source application from being aware of the target application.
• It provides transformation services that allow the source and target to use different communication protocols.
• The use of a router minimizes the impact of changes in location of the target application.

Limitations

With the Router variation, there is limited ability in the router to manipulate the requests. It performs intelligent routing and protocol transformation, but does not have the ability to send simultaneous requests to the target applications based on one incoming request, nor does decomposition / recomposition ability.

Putting the Application pattern to Use

ITSO Electronics consists of multiple Retail stores and Wholesale departments. The Retail stores get their supplies from the Wholesale departments and have a need to request the delivery dates of those supplies before ordering. Currently there is no integration of the Retail and Wholesale applications. All interaction between the two are done over the phone or by mail. A solution must be found to allow the Retail stores to request delivery dates from the Wholesale departments. To eliminate the need for the Retail departments to know which Wholesale department carries which supplies, a Router is needed to take incoming requests and direct them based on part numbers to the Wholesale department that carries them. This differs from the example outlined in the Broker pattern in that only one Wholesale department will carry a part. There is no need to distribute one request to multiple Wholesale departments simultaneously to see who can supply the part at the earliest date.

The Serial Process Application pattern, shown in the figure above, extends the 1:N topology provided by the Broker Application pattern. It facilitates the sequential execution of business services hosted by several target applications. Therefore, it enables the orchestration of a serial business process in response to an interaction initiated by the source application.

Business and IT Drivers

The primary business driver for selecting this Application pattern is to support the composition of end-to-end business process flows by leveraging business services implemented by several target applications. From an IT perspective, the key driver for selecting this Application pattern is improving the flexibility and responsiveness of IT by externalizing the process flow logic from individual applications.

Solution

Select this Application pattern

For a legend, please see above.

The Serial Process Application pattern is broken down into three logical tiers:

• The Source Application tier is the same as for the Broker Application pattern.
• The Serial Process Rules tier supports most of the services provided by the Broker tier in the Broker Application pattern, including routing of requests, protocol conversion, message broadcasting, and message decomposition and recomposition. In addition, it supports the separation of business process flow logic from individual application logic. The process logic is governed by serial process rules that define execution rules for each target application, together with control flow and data flow rules. It may also include any necessary adapter rules.
  The combination of these process execution rules are stored in read-only databases. This externalization of process flow logic is essential for the implementation of a flexible and responsive IT environment that can respond quickly to changing business needs. It also makes it possible to compose new end-to-end processes by combining different business services provided by different applications. Finally, this tier uses a work-in-progress (WIP) database to store the intermediate results from the execution of different process steps.
• The Target Application tier is the same as for the Broker Application pattern.

Guidelines for use

The flexibility and responsiveness provided by this Application pattern heavily depend on the externalization of process execution logic from individual applications. Applications with designs based on a service-oriented architecture (SOA) approach, which have well-defined and coarse-grained business services that represent a unit of work, are better suited for participation in this Application pattern. You must be able to compose these business services into an end-to-end process flow. A given service may need to participate in more than one end-to-end process.

Typically, legacy applications are not designed with this thinking in mind. Similarly, many of the legacy applications have significant amounts of process logic embedded within them. These constraints in existing environments may pose challenges to fully implementing the vision promised by this Application pattern. Careful refactoring of legacy and packaged applications by wrappering them into business services is a good starting point for the eventual widespread implementation of this Application pattern within an enterprise.

Composition of process flows by tying together different applications may introduce the need for compensating transaction support. This is especially the case when certain participating target applications do not leverage XA-compliant transaction processing engines. In such cases, it may be necessary to design compensating transaction pairs for every affected transaction and execute them if there is a need to reverse a particular portion of the process flow. You may need to modify participating legacy and packaged target applications to introduce compensating transactions if they do not already implement such mechanisms.

Finally, pay particular attention to the Business Process Management capabilities supported by the business process design tools and the process execution engines when you select middleware products that facilitate automation of business processes. The eventual goal is to enable business users to compose business processes and make necessary changes with minimal involvement from IT professionals. The business processes that are defined must be easily exported into a process execution engine. More sophisticated business process management tools allow for the definition of metrics during the process design to measure the effectiveness of process implementation and support monitoring of the metrics in the process execution engine.

Benefits

The Serial Process Application pattern improves the flexibility and responsiveness of an organization by implementing end-to-end process flows and by externalizing process logic from individual applications. In addition, it provides a foundation for automated support for Business Process Management that enables the monitoring and measurement of the effectiveness of business processes.

Limitations

This Application pattern is ideally suited for straight-through processing where human interactions are not necessary to complete an end-to-end process. If support for human interactions is needed to complete certain process steps, consider the Workflow variation of this Application pattern.

Putting the Application pattern to Use

ITSO Electronics wants to integrate its retail department with its two inventory wholesale departments, namely Wholesale A and Wholesale B. Currently, these three departments have proven IT infrastructures but no interconnectivity. ITSO Electronics wants to focus on automating the inventory replenishment process.

Typically, the retail department places orders with Wholesale A. However, when the Wholesale A is unable to guarantee delivery within seven days, Wholesale B is contacted to check the anticipated delivery date. Then, the order is placed with departments that guarantee the shortest delivery date.

To meet these business process automation requirements, ITSO Electronics chooses the Serial Process Application pattern. The primary driver for this selection is the need to externalize process logic from individual applications. This promotes flexibility and responsiveness to changing business needs.

The Serial Workflow variation of the Serial Process Application pattern, shown in the figure above, extends the basic serial process orchestration capability by supporting human interaction for completing certain process steps.

Business and IT Drivers

All the business and IT drivers listed under the Serial Process Application pattern apply to this variation as well. The additional business driver for selecting this variation is the need to support human interaction and intervention within the process flow. Support for long-running transactions is another IT driver, which is often a prerequisite for the automation of complex process flows involving human interaction.

Solution

Select this Application pattern

For a legend, please see above.

The Serial Workflow variation is broken down into three logical tiers:

• The Source Application tier is the same as for the Serial Process Application pattern.
• The Serial Workflow Rules tier supports all the services provided by the serial process rules tier within the Serial Process Application pattern. In addition, it supports certain tasks within the process to be routed to people for completion. To accomplish this, the process execution rules are augmented with task-resource relationships that define which resources are capable of performing which tasks.
  In this context, note the following points:
  • A task is a portion of the end-to-end process.
  • Resources are capable of executing these tasks.
  • People, departments, and target applications can all be resources capable of executing a particular task.
  This tier resolves the task-resource relationship during the execution of a process. If the need for human interaction is identified, the task is added to a work list associated with an individual or a department as a work item to be completed by a person. The process is typically suspended until the completion of the task.
  Finally, this tier provides support for long-running transactions. It uses a WIP database to store the intermediate results from the execution of different process steps until the complete execution of the end-to-end process.
• The Target Application tier is the same as for the Serial Process Application pattern.

Guidelines for use

These guidelines apply to this variation in addition to the guidelines that are documented in "Serial Process Application pattern" above. We recommend that you implement people-based exception handling for the majority of the automated tasks within the process. If an automated task reaches certain error conditions, a person must be able to intervene and handle exceptions.

Benefits

The Serial Workflow Application pattern improves the flexibility and responsiveness of an organization. It does this by implementing end-to-end process flows that externalize process logic from the individual application. Further flexibility is introduced by the externalization of task-resource resolution rules. In addition, it provides a foundation for automated support for Business Process Management that enables monitoring and measurements of the effectiveness of business processes.

Limitations

This variation does not support the parallel execution of multiple tasks. Under such circumstances, consider the more advanced Parallel Process Application pattern and Parallel Workflow variation.

Putting the Application pattern to Use

ITSO Electronics wants to integrate its retail department with its two wholesale departments, namely Wholesale A and Wholesale B. Currently, these three departments have proven IT infrastructures but have no interconnectivity. ITSO Electronics wants to focus on automating the inventory replenishment process. Typically, the retail department places orders with Wholesale A. However, when the Wholesale A is unable to guarantee delivery within seven days, Wholesale B is contacted to check the anticipated delivery date.

The main change from the scenario used in "Serial Process Application pattern", is documented here. If both Wholesale A and Wholesale B cannot offer delivery within seven days, a retail department manager must review the shortest anticipated delivery date proposed by the wholesale department systems and approve the order before placing it. The intent of this review is to determine whether other sourcing options must be considered.

To meet these business process automation requirements, ITSO Electronics chooses the Serial Workflow variation of Serial Process Application pattern. The primary drivers for this selection include the need for externalization of process logic from the individual application. This promotes flexibility and responsiveness to changing business needs and the need to support human interaction.

The Parallel Process application pattern, shown above, extends the basic serial process orchestration capability provided by the Serial Process application pattern by supporting parallel (concurrent) execution of the sub-processes.

Business and IT Drivers

All the business and IT drivers listed under the Serial Process application pattern apply to this Application pattern as well. The additional business driver for selecting this pattern is the need to reduce cycle time through the parallel execution of certain portions of the process flow.

Solution

Select this Application pattern

For a legend, please see above.

The Parallel Process application pattern is broken down into three logical tiers:

• The Source Application tier is the same as for the Serial Process application pattern.
• The Parallel Process Rules tier supports all the services provided by the serial process rules tier within the Serial Process application pattern. In addition, the interaction initiated by the source application may control parallel (concurrent) sub-processes on multiple target applications. Each sub-process may consist of a sequence of operations executed in succession on a target application. This parallelism requires that additional start and join conditions be defined for sub-processes executing in parallel. This requires sophisticated runtime engines that can initiate parallel threads of control, ensure these threads join upon completion, and manage them as a unit (for example to allow cancellation of the process or to report its status).
• The Target Application tier is the same as for the Serial Process application pattern.

Guidelines for use

The following guidelines apply to this variation in addition to the guidelines that are documented under the Serial Process application pattern.

The implementation of parallel processes without sufficient support from the selected runtime engine would require the development of excessive custom code. The need for parallel process execution must be analyzed before middleware selection decisions are finalized.

Judicious use of parallelism is a powerful tool for reducing the cycle time of a process in the right circumstances. However, in practice, it is critical to ensure that all of the error scenarios are carefully analyzed and that the impact of these scenarios upon the end-user experience is thoroughly understood. The number of error scenarios and processing complexity increases exponentially with the degree of parallelism. Hence, the best practice is to start with a serial process and introduce limited parallelism only where there is a clear and worthwhile benefit.

Benefits

In addition to providing all the benefits provided by the Serial Process application pattern, this pattern provides a foundation for the reduction of cycle times by implementing parallel processes.

Limitations

Parallel processes are more complex to design, test, and operate than serial processes.

In addition, this Application pattern is ideally suited for straight-through processing where human interactions are not necessary to complete an end-to-end process. If support for human interactions are needed to complete certain process steps, consider the Workflow variation of this Application pattern.

Putting the Application pattern to Use

ITSO Electronics, an electronics retailer/wholesaler, wants to integrate its retail department with its two wholesale departments, namely Wholesale A and Wholesale B. Currently, these three departments have proven IT infrastructures but have no interconnectivity. ITSO Electronics wants to focus on automating the inventory replenishment process.

The main difference from the scenario used in the Serial Process and Serial Workflow application patterns sections is that here both wholesalers are queried in parallel to find who offers the shortest delivery time. In other words, Wholesale Dept. A is not considered as the defacto supplier of parts in this scenario. The order is then automatically placed with the wholesale department that offers the shortest delivery date.

To meet these business process automation requirements, ITSO Electronics chooses the Parallel Process application pattern. The primary drivers for this selection include the need for externalization of process logic from the individual application, thus promoting flexibility and responsiveness to changing business needs and addressing the need for reducing cycle time of queries by simultaneously sending enquiries to the two departments for the best delivery date.

The Parallel Workflow variation of the Parallel Process application pattern, shown above, extends the basic parallel process orchestration capability by supporting human interaction for completing certain process steps. This is the most sophisticated Enterprise Process-Centric Application pattern in the domain of Enterprise Process-Centric patterns.

Business and IT Drivers

All of the business and IT drivers listed under the Parallel Process application pattern apply to this variation as well. The additional business driver for selecting this variation is the need to support human interaction and intervention within the process flow. Support for long running transactions is another IT driver, which is often a prerequisite for the automation of complex process flows that involve human interaction.

Solution

Select this Application pattern

For a legend, please see above.

The Parallel Workflow variation is broken down into three logical tiers:

• The Source Application tier is the same as for the Parallel Process application pattern.
• The Parallel Workflow Rules tier supports all the services provided by the parallel process rules tier within the Parallel Process application pattern. In addition, it supports certain tasks within the process to be routed to human actors for completion. To accomplish this, the process execution rules are augmented with task-resource relationships that define which resources are capable of performing which tasks. In this context:
  • A task is a portion of the end-to-end process.
  • Resources are capable of executing these tasks.
  • People, departments, and target applications can all be resources capable of executing a particular task.
  This tier resolves the task-resource relationship during the execution of a process. If the need for human interaction is identified, the task is added to a worklist associated with an individual or a department as a work item to be completed by a human. The process is typically suspended until the completion of the task.
  Finally, this tier provides support for long-running transactions and utilizes a work-in-progress (WIP) database to store the intermediate results from the execution of different process steps until the complete execution of the end-to-end process.
• The Target Application tier is the same as for the Parallel Process application pattern.

Guidelines for use

The following guidelines apply to this variation in addition to the guidelines that are documented under the Parallel Process application pattern.

It is recommended that people-based exception handling be implemented for all automated tasks within the process. In other words, if an automated task reaches certain error conditions, human actors must be able to intervene and handle the exceptions.

Benefits

The Parallel Workflow application pattern improves the flexibility and responsiveness of an organization by implementing end-to-end process flows that externalize process logic from individual applications. Further flexibility is introduced by the externalization of task-resource resolution rules.

It supports the reduction of cycle time by supporting parallel execution of portions of a process flow.

In addition, it provides a foundation for automated support for Business Process Management that enables monitoring and measurement of the effectiveness of business processes.

Limitations

Only a few middleware products are capable of supporting all the capabilities needed to realize this Application pattern. If this Application pattern is implemented using middleware products that do not support the necessary capabilities, the implementation could be very complex.

Putting the Application pattern to Use

ITSO Electronics, an electronics retailer/wholesaler, wants to integrate its retail department with its two wholesale departments, namely Wholesale A and Wholesale B. Currently, these three departments have proven IT infrastructures but have no interconnectivity. ITSO Electronics wants to focus on automating the inventory replenishment process.

The main difference from the scenario used in Parallel Process application patterns sections is documented here. In this scenario, both wholesalers are queried in parallel to find who offers the shortest delivery time. The order is then automatically placed with the wholesale department that offers the shortest delivery date, unless the shortest delivery time received from the wholesale departments exceeds 10 business days. In that case, a human intervention is required by the Retail Department Manager to review the anticipated delivery date to determine other sourcing options that must be considered.

To meet these business process automation requirements, ITSO Electronics chooses the Parallel Workflow variation of the Parallel Process application pattern. The primary drivers for this selection include the need for the externalization of process logic from the individual application, thus promoting flexibility and responsiveness to changing business requirements, the need for reducing cycle time of queries by simultaneously sending enquiries to the two departments for the best delivery date, and the need for supporting human interaction during the execution of the process flow.

Select this Application pattern

For a legend, please see above.

The three logical tiers are described in the Parallel Workflow variation.

Rapidly changing market conditions require organizations to quickly innovate, optimize their business, and lower their costs.

The Enterprise Process-Centric::Parallel Workflow=Content-Centric BPM pattern not only has parallel process orchestration capability with human interaction resolution but it also provides content repository services plus a native interface for enabling integration with external application services provided by target applications. It enables agile Enterprise Content Management (ECM) by delivering comprehensive content and business process management capabilities to address the creation, management, and optimization of unstructured content, related business processes, and user interfaces. It also increases business agility and improves performance based on efficient human, process and content interaction.

In the Content-Centric BPM application pattern, the content workflow execution engine provides content services (R/W Content Repository) and coordinates the process flow across systems and people. It enables process tracking by leveraging the process execution rules stored in the associated database (R/O DB). These processes can span multiple applications and many people across organizational boundaries within an enterprise. The BPM application maintains state and tracks sequencing through the process flow. To achieve this it often leverages the associated database to store intermediate results (WIP DB). It is also responsible for invoking the external application services as necessary through the associated connectors. Finally, when a particular task requires human interaction, the workflow engine creates a work item and identifies a particular person who is responsible for executing that task and adds the work item to the user's worklist.

This pattern helps the enterprise to streamline and automate business processes, access and manage all forms of content, and automate records management to help meet compliance needs. In this pattern, the content participates in the process when the document or image is loaded or updated in the content repository. The related business process and review/approval workflow are launched to respond to these events. Typical Content-Centric BPM applications include knowledge management, loan processing, credit card application, customer service etc.

Business and IT Drivers

All the business and IT drivers listed under the Parallel Process application pattern apply to this Application pattern as well. The additional business driver for selecting this pattern is the requirement for handling a lot of interactions with different types of structured or unstructured data within BPM applications. The interactions includes content lifecycle management, complex human/content related approval procedures and content-initiated event subscriptions enabling user actions in the business process.

Guidelines for use

The implementation of this pattern requires a mature content-centric BPM product. A content-centric BPM process application needs to be well designed based on a range of content access scenarios. The overall response time needs to consider both BPM and content access times.

Benefits

In addition to all the benefits provided by the Parallel Process application pattern, this pattern also provides an efficient approach to optimize complex human interaction and content-centric BPM process integration with external systems. Another benefit is that this pattern can be easily extended to cover integration with ECM systems, business rules systems, collaboration systems etc.

Limitations

If the business process is heavily transaction oriented and involves the integration of a set of heterogeneous application services, a transactional BPM product may be a better choice.

Putting the Application pattern to Use

A major securities company would like to improve the initial public offering (IPO) project's performance via effective collection and utilization of IPO project experience including explicit knowledge documents and tacit knowledge expertise which is currently scattered across different employees. The company expected the new Knowledge Management (KM) system would improve the knowledge life cycle management including security control and process automation etc.

To enhance its core competency and maintain marketing leadership, the securities company chose the Content-Centric BPM pattern for its knowledge management system. The knowledge management application included browser/server based logic (asset submission functions etc), approval business logic and a centralized document management system for different types of documents. The Content-Centric BPM provided process services and content repository services. It also supported related project management application integration via a native interface.

The successful implementation of the KM system was based on Content-Centric BPM together with Data Population, User Information Access, Collaboration patterns. It provided the following business benefits:

• Centralized knowledge library with content from projects, eMail, collaboration & third parties.
• Prevented enterprise knowledge asset loss and quickly enabled junior employees.
• Improved IPO project performance with reduced risk and cost via knowledge asset reuse.
• Improved business measurement with process activities tracking & ranking knowledge contribution.

Select this Application pattern

For a legend, please see above.

The three logical tiers are described in the Parallel Workflow variation.

In some organizations there may have been existing ECM applications in production. Customers hope to fully leverage these enterprise content resources with seamless integration between the BPM and ECM systems when the new content-centric BPM applications are developed.

In the Application Integration::Parallel Workflow=Content-Centric BPM pattern variation (Content-Centric BPM Integration with ECM Pattern), there is an extra target application which is based on ECM. The Content Workflow engine needs to invoke the ECM services via the associated BPM connector to seamlessly invoke content query, fetch, insert, update, delete etc. The other parts are kept the same as the Content-Centric BPM pattern.

Business and IT Drivers

All the business and IT drivers listed under the Content-Centric BPM pattern apply to this Application pattern as well. The additional business driver for selecting this pattern is the need to integrate the content-centric BPM applications with a separate ECM-based application.

Guidelines for use

The implementation of this pattern requires a Content-Centric BPM product and an ECM product. A content-centric BPM process and the integration interface with ECM need to be well designed based on a range of content access scenarios. The overall response time needs to consider both BPM and ECM access times.

Benefits

In addition to all the benefits provided by the Content-Centric BPM pattern, through seamless integration between ECM and BPM, content becomes the essential information asset in business processes to help support better business outcomes. The Active Content capability automatically provides decision makers the right information at the right time in the context of important decisions, helping to both reduce errors and time wasted searching for information.

Limitations

It is more complex to design and test the integration of content-centric BPM with ECM than the process applications or content applications alone. Professional services for ECM products and advanced content-centric BPM are recommended to realize this Application pattern with best practices.

Putting the Application pattern to Use

A major insurance company would like to improve its customer services in Policy Management such as policy address update and beneficiary change etc. Their existing infrastructure includes a legacy core life insurance system and a distributed image management system. The current system couldn't access the policy info and image data simultaneously. Also it was hard to manage the cost and performance of the business processes and the operational risks at the same time.

To provide a high quality policy update services, the insurance firm chose the Content-Centric BPM and ECM integration pattern which included the centralized image management system (ECM) and the integration between the source application and the target applications. The source application (Policy Management) was based on Content-Centric BPM. The target application includes the policy information application based on a legacy system and the image content services applications based on ECM.

The successful integration of Content-Centric BPM and ECM systems brings the following business value.

• Previously distributed image data was centralized and shared across the company
• Reduced business risk due to centralized operation and management of customer services processes
• Improved customer satisfaction due to seamless integration of policy information and image data with BPM.
• Improved business performance with effective task assignment and tracking of workflow activities.
• Improved ROI by building a reusable BPM-ECM integration service asset using an SOA approach.