In the early stages of a BPM project a business might create a written specification and planning level diagram of the project target process. Yet there is much work that must happen to translate these into a functioning business process. The challenge to the process implementer is to see the shape of the business processes based on an oral or written description of the process. An able implementer should perform a lexical analysis of the business requirement to develop a technically accurate assessment. A process solution can break when there is a weak implementation of requirements. It is important to understand how you can create a technically sound implementation. Part of the way forward is to use work flow patterns.
Process implementers should familiarize themselves with the work of the Dutch researcher Wil van der Aalst. Dr van der Aalst and other researchers identified twenty-one workflow patterns that define the universe of possibilities that a ‘complete’ workflow engine must address.
The patterns described are useful for getting ‘unstuck’ in seeking solutions for your business process. In implementing a business case, many of the matters are trivial; however, many describe typical circumstances. Also, you can avoid painful rearchitecting of processes if you match the needs of the written business case with the correct workflow solution.
If you study data modeling with an experienced practitioner you learn an internal dialog for translating requirements into entity relationship diagrams. For instance, you might identify an intersection entity as the result of a shared multiple relation between two entities. Other relations unfold as the modeling team ‘unpacks’ and explores entity definitions. Simply put: the shape of the entity diagrams flows from the dialog.
Similarly, you can use workflow patterns to create the proper business process abstractions. Just as in data modeling, the patterns lie between the wordings of the process requirement.
Some of the important van der Aalst workflow patterns that I have faced include:
- Synchronizing, the point where many subprocesses merge
- Deferred Choice, the point where the process makes one of several choices from several alternates
- Interleaved Parallel Routing, when the process carries out activities in arbitrary, yet non-consecutive order
- Multiple instances without a Priori Runtime Knowledge, where the process does not know the number of instances of an activity at run-time
- Milestone, where activity occurs, depending on the state of other events or activities
- Cancel Activity, where the process stops an executing activity or subprocess.
An often used workflow pattern is ‘Multiple instances without a Priori Runtime Knowledge’. We use this pattern when we don’t know how many responses or instances of an activity will be faced. In this pattern, the process must wait until all instances are completed. Then other activities start. Often while some activities execute or are completed, new ones might be created.
Examples of this pattern include:
- Getting bids for work from multiple trading partners,
- Awaiting the delivery of multiple shipments from vendors to a facility before completing a process.
You assign this pattern when the process must respond to multiple unknown quantities of events.
Another common, advanced pattern is deferred choice. This is a point in the business process where one of several branches is chosen. The choice is not made based on a business rule (or a diamond in BPML) but several alternatives are offered. Only one of the alternatives is carried out. The other alternative branches are withdrawn, once the process starts one of the branches. The choice is called deferred because it is suspended until the processing in one of the alternatives starts, i.e., the choice is as late as possible.
Twenty years ago, there was an academic movement, known as formal methods. This has become high confidence software (HCS). The HCS movement is responsible for developing the Avionics of the Airbus A380. A hidden outcome of HCS has been strongly typed languages, especially Java. Another outcome of HCS has been Pi-Calculus. Workflow engines that use Pi-Calculus can mathematically corroborate their solution to the van der Aalst workflow patterns. Another vision of the BPM movements is to be able to exchange processes. Currently, a theoretically sound way to exchange processes, in a long-lived transaction is with systems that use pi-calculus engines.
The benefit is the assurance that your solution should complete according to the path described in the diagram. Many of these patterns, especially the complex ones, are difficult to write with traditional programming techniques. By specifying your problem in process diagrams, the solution is left to the BPM tools, not the skill of the individual programmer.
As the BPM industry matures and practitioners repeatedly create the same workflow pattern the tools will become more powerful. More abstract services become available and process diagrams will become more expressive.
Imagine this scenario. A businessperson wants his customers to provide, at their pleasure, some maintenance information for research. If they elect to provide this information, they will receive some benefit; say a discount of their next purchase of products from the company. In the new world of BPM 2.0, the same businessperson should be able to create email, the process that supports it, and the discount. Right now I believe the BPM industry is nearing reality. As the BPM industry embraces abstraction in the manner and methods of workflow, the Business IT divide will decline.
