As I've discussed in previous posts, it is important to decouple the views and back-end systems from the business process itself. Why? Reusability.

 

 

Remember, reusability in BPM system architecture means that the basic process can be customized for different communities or departments in an organization. Take, for example, an order-entry process that leverages business processes used by Support.

 

A common business process handles the origination of a work item (like an order or an issue), routing of the work item, the ability to escalate problems, synchronize back-end systems such as Siebel, Remedy or Filenet and exception handling. Take a look at the following diagram, specifically the View Dispatcher and the Service Delegate:

 

 

 

 

 

The Service Delegate is a component of POA that allows the process to handle work items differently. Since POA can implement a process that can handle work items for a call center handling new orders and product issues, the business process needs this service delegate to interact with back-end services or systems as required to handle the different types of work items. Let's say the process needs to perform some back-end system hand-off operation or synchronization after the call center is finished with the work item. Regardless of what the work item represents, the common process sends the work item to the service delegate and the service delegate then does the synchronization or hand-off. The service delegate may simply connect to a database or it can involve SOA concepts such as Web Services, Service Bus or JMS, or all of these at once. The service delegate performs the back-end work for the different types of work items. If the new order needs to be handled differently than the support issue, the service delegate makes this distinction. Likewise, if the same function is needed, like simply writing the work item to a database, the service delegate handles this process efficiently.

 

 

The View Dispatcher decouples the views from the process. This decoupling allows designers to leverage a common process and to create simple building blocks of views and reuse them in many different ways. For example a simple work item view can be reused from role to role within an organization by way of the common business process. The same view can also be used by different processes for different user-roles. The business process shouldn't care about the views that are rendered for a particular user-role. The business process may care about actions taken by the user or changes to certain Key Performance Indictors (KPIs) or process metrics. Other than that, specific details about the data or how it is modified by the view are not important, so these details are left to the views to resolve.

 

 

The views can be web-based or a fat client. Take for example a web-based UI versus something built on Eclipse Rich Client Platform (RCP) that would render a much richer view similar to how MS Outlook improves the look and feel over a web-based email UI. The views can be built in modular chunks using a wide assortment of technologies. With a view dispatcher, we can begin to reuse and extend process-level building blocks that can be customized for different business scenarios. Further, we will begin to develop more specialized views that can also integrate commercially available (out-of-the-box) User Interfaces. These views will also become building blocks for processes within the organization which again means reusability and cost savings.

 

 

Next week we will discuss in more detail how information and views for the business process should be organized in a POA