Suppose a fund's board of directors decides that loans above a certain limit must also be approved by the credit committee before they are disbursed. In many systems, even a simple decision like this turns into a change request. A developer has to track down and modify the process logic across several services, the new version has to be tested, and a release slot has to be booked. In the meantime, the credit department either runs the new step outside the system, with letters and signatures, or waits.
In Dara, the same change is made in the Process Designer and takes effect when a new version of the process is published. Below, we explain how this works and the design considerations behind it.
Where the process lives
In Dara, the specialist work of each domain, such as calculating installments or placing a hold on a deposit, is done in that domain's module. But the order of the work, meaning which step a case moves to after each one, is kept in the Process Engine. Each process graph, including its steps, conditions, work queues and deadlines, is stored as data and versioned like any other data.
Each version is in one of three states: draft, published or archived. In the designer, a process analyst creates a draft from the current version of the financing process and adds a “Credit committee approval” step with a condition on the amount. Before publishing, the graph is validated to make sure it contains no dead-end steps or unfinished paths. Publishing the new version takes a single call, and no service is redeployed.
In-flight cases
This is what operations teams worry about most when a process changes. In Dara, every case is locked to the version it started on. A request filed yesterday follows yesterday's path through to the end, while today's requests follow the new version. No case encounters, partway through, a step that did not exist when it began.
If the organization wants the new rule to apply to open cases as well, that is a separate decision that has to be made deliberately. It does not happen automatically when a version is published.
Work queues and deadlines
The “Committee approval” step is a human task. In Dara's engine, a human task is a real record with a target role, and it can be restricted to a geographic scope, such as a single province. A staff member claims the task and then completes it, returns it or reassigns it to a colleague. Every one of these transitions stays in the case history.
Each step can have a deadline and reminders. Timers are durable and stored in the database: if the service restarts partway through a task's deadline, the countdown picks up where it left off and no reminder is missed.
When several modules respond at once
The financing process is not made up of human steps alone. Checking collateral, fetching the applicant's score and placing a hold on a deposit are jobs that other modules carry out before returning the result to the engine. Sometimes these responses arrive almost simultaneously.
Every advance in the engine happens inside a transaction whose first action is to take the lock on that case. Simultaneous responses queue behind the lock, and each one picks the case up where the previous one left it. A case is never left half-finished or in two states at once, and its current state can always be read with a simple query.
Events the engine publishes, such as “Request approved,” are written in the same transaction as the state change. Either both are recorded or neither is. Events are delivered to subscribers separately, with an HMAC signature, and if a subscriber is unavailable, delivery is retried at intervals that grow longer each time.
Process Designer
The engine has eighteen node types, from human tasks and timers to calls to external systems. A process analyst draws the graph in the visual designer, assigns a role and a deadline to each human task, and sees any errors in the graph right there, before publishing.
What still falls to the technical team
Versioned processes do not mean that no change ever needs a developer. If a new step requires a calculation that no module performs today, that calculation has to be built in the relevant module. But reordering steps, adding or removing an approval, changing a task's target role and adjusting deadlines are all done in the designer, and most change requests from operations teams tend to be of exactly this kind.
- #Process_Engine
- #Work_queue
- #Versioning
- #Financing
