QM APPS Business Process Engine
Quality Business Processes - 15 June 2016
For the second instalment of this two-part interview, we’re talking with SOLABS QM APPS Lead Developer Diem Le, whose current work finds her collaborating closely with a Development team engineering QM APPS, the powerful, lean and intuitive automated business Processes that can be used by clients out of the box or customized—but that are also be closely integrated with SOLABS QM core software for Document Control and Training Management.
“A business process engine (BPE) enables execution and maintenance of process workflows; provides business process interaction and communication between different data/process sources spread across one or more IT applications and services. It also automates linking processes and their activities in an enterprise IT environment.
…A BPE also oversees the architecture of business process integration, interlinking and inter-processing, and works with the various application infrastructure layers, including front end, middleware, backend and external business applications. It facilitates the integration of their processes, inter and intra system communication, process data routing, data transformation and merging. A BPE dynamically monitors and adjusts changes applied to data, as well as associated processes and process workflows.”
–Adapted from Techopedia
Gordon Bradley [GB]: Last time, we talked about your role as Lead Developer on QM APPs, and our CEO, Philippe Gaudreau, enjoyed Part I of the interview so much, he asked me to follow up with you about the QM APPS Business Process Engine.
Diem Le [DL]: [Laughs] I’m glad he liked it. So what is your question?
GB: Well, the first time I saw a process when I joined SOLABS, I noticed there was a ‘Waiting’ step, and someone told me there was a sort of business intelligence–that we call the SOLABS QM Business Process Engine–behind the scenes of all the QM APPS?
DL: The ‘Waiting’ step actually circulates x number of times per hour, as a component of the BPE in use, based on a pre-defined delay. It checks the status of various flags and conditions, and then when one or more of the criteria is met, it reacts accordingly. Besides the periodic checks, there’s also ‘Waiting’ where the next step is triggered by an event: the ‘Waiting’ step has multiple uses and triggers. I’m not sure if I would call it ‘intelligence’ necessarily. It stays in the background. It’s proprietary to SOLABS, and it drives the Processes forwards, conditionally, through their constituent steps, using a kind of guiding logic or principle. It watches for tasks to be completed, documents to become Effective, trainings to be completed, approvals and reviews to be completed—and then depending on the action, it triggers the next step, whatever that may be.
GB: So it’s essentially ‘monitoring’ the process and its dependent actions?
DL: It has any number of actions that it performs by definition, but it is designed to, based on the circumstances, move the Processes forward, regardless of which decision is made.
The SOLABS QM Business Process Engine can:
- trigger an action following another action
- wait for an action to trigger another action
- trigger an action under a given set of circumstances
- perform any number of other conditional, periodic, and/or monitoring actions, and
- do this in real time with any given number of current active processes
In short, it knows all the possible outcomes, and propels processes forward.
The SOLABS QM 10 Business Process Engine monitors complex, ongoing QM APPS, driving them forwards based on decisions made and established workflows.
GB: Well, not always forwards, right? Because if someone rejects a step by selecting return to initiator, it goes back to the start?
DL: Well, in that case backwards is forwards…. It’s more like this, I think: we build on frameworks and libraries, as do many developers. We write in JAVA. But all the functionality, all the possible outcomes, in real time, is run using the Business Process Engine.
For example in a document control process, let’s say that we have three users who are doing document review in parallel: multiple outcomes are possible. If one rejects, for example, the process is returned to the start. If all three sign off on the review, it proceeds to the approval cycle. And on it goes. This is a simple example, but in a multi-forked, looping decision tree, it is the gatekeeper that unlocks the correct subsequent door.
We wrote and designed SOLABS QM’s BPE, and we have every reason to be very proud of it! When we write QM APPS, we have to know we can rely on the BPE. There may be, for example, three simultaneous approval loops that are not dependent on one another to finish their loops, secondary tasks running in the background, a dependent process that we are monitoring, document reviews and approvals we’re watching for and their results, conditions that may arise–either triggered by something else or spontaneously–user training completions, and the list goes on.
The BPE has a lot to keep an eye on! It’s almost always much more complex than Condition A triggers Event B. The code can run on a periodic timer, it can be ‘awoken’ by other code… it’s very flexible, and it’s the ensemble of the entire code that makes up the BPE.
GB: So we have the framework, and then, if we imagine a car navigating through a small, windswept beachside town: let’s say the car is the process, and the BPE would be the GPS, watching what the car is doing, where it’s located, what it’s doing and what it’s subject to–and providing information back to it accordingly?
DL: This is another way of framing it. There is, in every QM APP, a finite number of outcomes. The BPE knows all the routes between the start and the end, has taken them all, has summered on some of their beaches as an adolescent, and has brought back the t-shirt, as well as some saltwater taffy for their friends.
GB: Thank you as always, Diem!
Read Part I of our interview with Diem on SOLABS QM APPS Development.