It ain’t a classic blog post but rather a rolling-out story. No one knows how it will go neither who is the killer
The reader of this blog Crisitan submitted a comment asking how to model “state machine”-like processes:
Here is my made-up story: we are trying to model and implement a computerized system for handling the lifecycle of some licence obeying the rules below.
The Ministry of Energy of some country issues licences for oil exploration and production to applying oil companies. Oil companies must get a licence before they may legally produce or explore for oil in that country. When companies get a licence from ministry, they are said to own the licence. In order to get the licence, a company must first apply for it via ministry. Any licence application gets reviewed by ministry staff and, if application is approved, it results in the issuance of the licence. A licence has an Issue Date and an Expiry Date. Every time Expiry Date is moved forward, it does so at most one year at a time, but it may be moved forward repeatedly thru the Renew Licence function of the system.
When applying for a licence, the applicant must specify if they want the licence to be issued Right Away or on the coming 1 Apr. If they specify Right Away, the licence will be issued on the day it’s approved (issue date) and it will be valid until next 1 Apr (expiry date). Usually, applications are assessed the day they arrive. If applicant specifies they want the licence to be issued on coming 1 Apr, if approved, it will be issued on the coming 1 Apr and it will be valid until the next 31 Mar coming right after 1 Apr when the licence was issued. A licence may have two statuses: Active or Inactive. If applicant applied for a Right Away licence, if approved, it will have its status set to Active. If the applicant specified they want licence issued on coming 1 Apr, if approved, licence will only be issued on coming 1 Apr, it will be valid until 31 Mar coming right after 1 Apr of issuance, and it will have status Active. The applications also have a status. When companies apply, their applications are stored in the system with status Pending. If application for licence is approved, its status becomes Approved. If application for licence is rejected, its status becomes Rejected. If an application was rejected, the applicant qualifies for a full refund of paid fees (50 dollars).
In order to keep a licence Active, the owner of licence must renew it using a Renew Licence function of system, which does not require staff assessment.Also, an owner may choose to Deactivate an active licence using the Deactivate Licence function of system. If the owner of a licence does not renew their licence before its Expiry Date, it will be deactivated automatically by the system. If a licence is deactivated, it may be reactivated through the Renew Licence function of the system. It doesn’t matter if a licence was inactive for one day or a number of years, it may still be renewed using Renew Licence function. Once a company owns or owned a licence, they may not apply again for a licence. When they need an active licence again, they need to use Renew Licence to bring it back to life. When applying for licence, there is a 50 US dollar fee. Same for renewal. If some company applies for licence, they need to pay the fee. Same for renewal. Also, if the licence owner company does some things which are against the law, their licence will be automatically deactivated if system can detect that. Also, if staff detects some illegal action of licence owner company, they may initiate Deactivate Licence function in the system and choose from a list of potential reasons why the deactivated the licence.
I’m going to model it in BPMN. Other readers are very welcome to participate in discussion and modeling.
1. State Transition Diagram
Let’s start with very simple diagram depicting the licence states and transitions:
I recommend to use the classic STD notation at the first step of process analysis when dealing with statemachine-like processes. We’ll translate it into BPMN later.
There are more than two states:
- Pending is the initial state
- Not Approved is the terminal state
- Granted means licences requested from 1 Apr, approved and waiting for 1 Apr to come
It looks a little bit suspicious that there is no terminal states except “Not approved” - this is because licence “cases” last forever. I’d suggest to close the case - move the licence into something like “Closed” state. But it’s just my guess - Cristian?
2. State Transition in BPMN
Let’s translate the state diagram into BPMN:
3. State Transition in BPMN Data Store
The way a state diagram is implemented above is very powerful. It’s main advantage is that it watches not only events that happend but also ones expected yet didn’t happen, e.g. missed payment due date.
It also lets you implement sophisticated models and versatile escalation flows. In fact you may go beyond the pure state transition model which doesn’t allow parallel execution. The implementation proposed above lets you model e.g. payments in one branch and delivery in the other and watch statuses of both.
But isn’t it an overkill for the simple process under consideration? Sure it is so here is the alternative:
Here the state machine is implemented as a database record with “State” column, possible values are “Granted”, “Active”, “Inactive”. The diagram probably speaks for itself. Couple of notes:
- Incoming data flows from Licence to “Identify” and “Select” activities are not shown for clarity.
- There is one watchdog serving both expired and granted licences. You may opt for two watchdogs; in more complicated scenarios there may be plenty of them, launched daily or hourly rather then annually.
This model actually has more serious advantage over STD implemented as a process than just simplicity: it’s also more robust.
The state machine or lifecycle-like diagrams let you implement long-lasting or even endless processes. The common issue of such processes is this: let’s assume that certain process lasts for e.g. two years. What are the chances that we won’t need to change the process scheme during this period? Almost zero. Now take into account that most BPMS don’t allow to change the scheme of the running process instance on the fly - it’ll follow the scheme it inherited from the process template when it was instantiated. We’ve got the conflict here.
The STD implemented as a process lets you avoid this trap by keeping the lifecycle process as simple as possible and hence not vulnerable to changes. The surrounding workflows are short-living and they may be changed, duplicated etc. with no harm.
Yet there still are the chances that we’ll need to change the lifecycle process. STD implemented as a data store eliminates this threat completely: you may always add another state or another watchdog.