The importance of pre-conditions and post-conditions in the “new” BPM

Blog: KWKeirstead's Blog

Traditional BPM had little need for pre-conditions and post-conditions at process steps.

The combination of flow graph logic and data collection checks and balances put in place at process steps by BPM flow graph designers provided reasonable expectation of no-fault processing along BPM processes at run time.

Photo Credit: Ignacio Evangelists
https://www.facebook.com/ignacio.evangelista.photo/

The situation changed dramatically when the industry started to need to accommodate “process fragments” in addition to traditional end-to-end processes, especially processes fragments made up of a single step.

In a run-time Case environment, if I stream a new manufacturing order onto a workflow that has as its first step “ship final product”, the Case hosting the processing needs a way to determine that the usual “design-build-test-QA” steps have been skipped over.

Traditional BPM did not have to worry about this because it was able to rely on an end-to-end process comprising “design-build-test-QA-ship”. On arrival at “ship”, all of the data attesting to completion of upstream steps would typically be on hand.

Not so in Case, where users can do what they like, including not following an end-to-end BPM process, undertaking instead to achieve the same objective by performing a seemingly random (except to the performer) sequence of steps where the only inferred links between steps is their timing.

It follows that we need pre-conditions at the initial step of key process fragments. In the above example, the processing engine will ask “Do you have a QA certificate?” and refuse to go forward in the event of a “No” response.

Once process designers get used to putting in pre-conditions at process fragment start steps they quickly see no reason for not putting pre-conditions at intermediate and final steps along process fragments.

Pre-conditions add robustness at process steps that may be impacted by data imports to Cases. (i.e. the manufacturer had a fire in the QA lab, the product was sent to an outside lab for QA certification, the results came in via an external transaction but the data was not streamed onto the process fragment because this type of extraordinary processing was not anticipated in the BPM process map).

You might ask why, with pre-conditions, would we also need post-conditions?

The reality is that BPM process maps rarely cover all eventualities so there can be data at a Case that a process fragment does not have direct access to. Here, the generic fix at the Case is to accommodate both pre-conditions and post-conditions at any process step (end-to-end processes, process fragments, ad hoc steps).

Pre-conditions and post-conditions are central to a software correctness methodology called “Design by Contract’ invented by Dr. Bertrand Meyer in the mid 1980’s and implemented in the Eiffel programming language

For more information on Design by Contract™ see

https://www.eiffel.com/values/design-by-contract/

The author has no commercial affiliation with Eiffel Software.

Filed under: Uncategorized Tagged: ACM, adaptive case management, BPM, Business Rules, Case Management