Process Flows are the most commonly understood form of module in a PRPC design and are typically where all of the elements are orchestrated to realize business process. Using “drag and drop,” processes can be constructed out of decision engines, functional components, Business Object Binders, and often user interface rules by those with business intimacy. Due to the fast nature of this construction and the frequency of change to business process, process flows and their low level elements are not typically candidates for reuse.
Identification
Process Flows are close to the business, and are intended to be malleable enough to support rapid prototyping activities. As a module, the Process Flow is the most context-aware. This makes reuse unlikely except as a source for cut-and-paste code. Moreover, the nature of the Process Flows as implemented in PRPC makes reuse less necessary because the barrier to recreation is quite low. Therefore the major driver for reuse will be consistency rather than efficiency of construction. Nonetheless, careful reduction of the units of a Process Flow into more generic sub-flows may encourage reuse where possible. Embracing this distinction will help guide the design of individual Process Flow modules. This module will include flows which orchestrate User Interface elements with Decision Engines, Functional Components, and Business Object Binders as appropriate. For PRPC, the presence of a task-oriented user interface is the key to identifying a Process Flow from other module types.
Design
To support the rapid prototype approach to initial implementation, Process Flows should be designed following Pegasystems’ recommended guardrail to “Do nothing that is hard.” That implies that the heavy lifting should be left to (and partitioned into) other module types which can be conditionally included within the Process Flow. So the KROME framework modifies the approach to say “Do nothing in a Process Flow that is hard.” Naturally an application’s value will increase with the inclusion of more complex capability, but the value of the Process Flow as a module will depend on the exclusion of those complicated implementation into other modules.
Usage & Implementation
Though normally resident within PRPC, Process Flow modules may be implemented in other third-party BPM or workflow tools with SOA or in-process invocation capabilities of core PRPC modules. The orchestrating modules are best chosen based on the strength of performance in the application domain. For example, interactive processes within a single task-owning group are best implemented in PRPC, while those that orchestrate processing across multiple systems or departmental boundaries may be best implemented using an integration-oriented BPM tool such as Tibco.
