Handling government business processes across administrative divisions — DigitalState.io

9 min readJun 7, 2016

Governments are known for their bureaucracy; and it is government’s rules, policies, service levels, and business processes that manage the bureaucracy. When governments attempt to transition their current services (typically “legacy” paper based), into Online Services, also known as Digital Public Services, a big problem emerges… How does a government reasonably and in a cost effective manner, build online services that can scale vertically and horizontally? How can governments build a service that can handle thousands of request per day, and multiply the number of services that are offered into the thousands? And we are not talking about how can the technology infrastructure handle the throughput, we are talking about how can the business processes handle the throughput. Typically they can't, and don't, and as a result we end up with online services that may seem slick on the front end (the user experience), but are really just legacy and/or paper processes behind the scene. The result: the citizen may receive a pretty interface, but there are no cost savings or performance increases.

A very common source of Business Process complexity in government is found in the political and bureaucracy divisions in government services:

How can a government manage multiple variations in business processes between administrative divisions?

These complexities are found at the local, regional and national levels of government:

Local: Between the wards, boroughs, and/districts of a local government.
Regional: Between the different local governments, Primary Regions, and Sub-regions.
National: Between Local and Regional governments, departmental/program regions and zones.

All of this adds up to huge levels of complex business processes where something like having a tree removed can have dozens of different process, policies, and rules that must be followed depending on where the tree is located, and how that “area” handles tree removal.

Our first response is usually to suggest ‘harmonization’: where the the government works to harmonize the rules so that there is a single process, a single set of rules to follow. Unfortunately this is not always possible (for good and bad reasons), and can often take years to complete depending on the politics, complexity of the changes, and of course culture and past-precedents.

At DigitalState, we see this problem quite a lot. We are often asked to prototype or quickly model how to solve complex business process problems for government. So how do we solve it?

Well, we use Business Process Management Model and Notation (BPMN). Using BPMN allows governments to draw their processes on a ‘whiteboard’ and we can perfectly duplicate the process regardless of the bureaucracy or complexities. We never want to be caught in the situation were a government must model to the technology, the technology should model the government.

Lets build a simple example with one of core open source technologies that DigitalState leverages in our platform: Camunda. We will use CartoDB as a free and accessible GIS database.

Tree removal is typically a hot topic issue as you get closer to a municipality’s downtown core. We can see this exact problem in Ottawa when large trees were cleared in the City’s downtown core. In any large municipality, there will be different rules and expectations for tree removal depending on the location of the tree in relation to the administrative zones, agriculture zones, and proximity to downtown where typically large trees are a scarce and prized resource. In our example we are going to use political administrative boundaries (typically known as Wards, District, or Boroughs).

Lets look at a simple fictional example using the City of Montréal’s Boroughs:

Explanation of the Process:

The start event collects the tree removal request information. For this example we will keep it simple and collect: Name, Phone Number, Reason for Tree Removal, and Address Closest to Tree to be Removed (we are also collecting the latitude and longitude of the address point, but we are only doing this because the free tier of CartoDB only allows 100 transactions of geocoding per month for street level address points. So we will populate the latitude and longitude manually for this example, but in real world practice we would have captured the point location of the address during submission through geocoding the address).
Once the data is submitted at the start event, we call the CartoDB SQL API and preform a query to determine which Montréal borough the address is located in.
Once we know which borough, we then have three branches at the exclusive gateway asking the question: Which borough was the address located in? To keep the code clean we will use the borough number to run the filter.
If the address is located in Borough 20, Ville-Marie, then a User Task is generated and assigned to the respective councillor’s office for review of the request. The office can approve the request, and a User Task is generated for the tree removal crew. If the councillor’s office raises exception with the removal request, then a User Task is generated and assigned to the forestry department to review and work with the councillor’s office to resolve the exception.
If the exception cannot be resolved, then the tree removal request is terminated/‘cancelled’. If the exception is resolved, then a User Task is generated for the tree removal crew.
If the address is located in Borough 22, Le Plateau-Mont-Royal, then we call a sub-process to handle the very specific and ‘unique’ business process and rules that the borough has in place to handle tree removal requests. When the sub-process terminates, then we consider the tree removal request terminated/completed.
If the address is in any borough other than 20 or 22, then we call a Service Task which calls a Rest Web Service to pass the request into an ERP. Once the ERP has completed the tree removal request, the ERP sends a message to Camunda through the Camunda Rest API using the Message API. When the message is received, the Tree Removal Request is terminated/completed.

This process covers three scenarios that we commonly see in government.

The escalation based on administrative zone.
The ‘unique’ business process that must be followed based on a administrative zone.
Collect and hand off the data to a ERP/third-party system to take over based on a administrative zone.

All three scenarios are covered in a single business process that can be easily handled through BPMN and executed. Even better is the fact that you can scale this service/business process with additional conditions, business rules, sub-processes, SLA, KPI tracking, and hand-offs to third-party systems with a few minutes of configuration.

How it all Works

If you would like to test out this process for yourself, let’s look at some of the specifics of how all of this works:

The Borough Data

The boroughs data was downloaded as a Shapefile from Montréal’s open data portal. The data is loaded in CartoDB.com. You can see the table we use here. Behind the scenes, one of the components that makes CartoDB a amazing tool for prototyping (and production), is its nearly full featured PostGIS/PostgreSQL database that you can query through the CartoDB SQL API.

A sample of the SQL query we use is:

https://stephenrussett.cartodb.com/api/v2/sql?q=SELECT name, number FROM montreal_boroughs WHERE ST_Intersects(montreal_boroughs.the_geom,cdb_geocode_street_point(‘275 Rue Notre-Dame E’, ‘Montréal’, ‘Quebec’, ‘Canada’))

This query uses the ST_Intersects function from PostGIS to find the Montreal Borough Polygon that intersects with the Address point. The Address point is GeoCoded and converted into a Lat and Long / XY coordinate using the CartoDB function cdb_geocode_street_point. If you already have the coordinates of the address you could also use the cdb_latlng function which will convert a Lat and Long into a format used by CartoDB. This would look like (We use the CDB_LatLng function in the example BPMN file so we do not hit the CartoDB API Geocoding rate limit):

CDB_LatLng(45.508948,-73.554454)

The Camunda Modeler

For this example we used the Camunda Modeler. A great tool that allows you to create BPMN files and setup the configuration to be executed by the Camunda Server. The Modeler can run on Windows and Mac.

Web Service Call — Camunda HTTP-Connector

We used the Camunda Connector: HTTP-Connector. The connector allows us to send Rest requests from Camunda to the CartoDB SQL API. This is how you set it up:

Select the Determine Borough Service Task and in the Properties Panel set the Implementation field to Connector.

Web Service Call — Connector Id

Go to the Connector tab in the Determine Borough Service Task, and set the Connector-Id field to http-connector.

Web Service Call — URL

Select the ‘+’ symbol for Input Parameters and create the following:

Name: url
Type: Text
Value: https://stephenrussett.cartodb.com/api/v2/sql

Web Service Call — Method

Name: method
Type: Text
Value: POST

Web Service Call — Headers

Name: headers
Type: Map
Value: Key: accept 
Value: application/jsonKey: content-type 
Value: application/json

Web Service Call — Payload

Name: payload
Type: JavaScript
ScriptType: Inline Script
Script:var lat = execution.getVariable(“Latitude”);
var long = execution.getVariable(“Longitude”);‘{“q”:”SELECT name, number FROM montreal_boroughs WHERE ST_Intersects(montreal_boroughs.the_geom,CDB_LatLng(‘ + lat + ‘,’ + long + ‘))”}’;

This script will get the Latitude and Longitude values stored in the Process variables using the execution.getVariable() function, and then we build the JSON that we will be sent via POST to the CartoDB SQL API. Notice that we call the lat and long variables inside of the JSON, and notice the two different types of quotes we are using: “ ” and ‘ ’ allowing us to concatenate the SQL SELECT statement with the Lat and Long variables.

Web Service Call — Output Parameters / Web Service Response

Create a Output Parameter with the following values:

Name: WsResponse
Type: Script
Script Format: JavaScript
ScriptType: Inline Script
Value:S(response).prop(“rows”).elements().get(0).prop(“number”).numberValue();

The S() function at the beginning is the Camunda Spin function which converts the string text received as a response from the CartoDB SQL API into a parsed JSON object that can be navigated using the Spin functions such as the .prop().

The response you receive from the CartoDB API should look like the following:

{
 “rows”: [
 {
 “name”: “Ville-Marie”,
 “number”: 20
 }
 ],
 “time”: 0.003,
 “fields”: {
 “name”: {
 “type”: “string”
 },
 “number”: {
 “type”: “number”
 }
 },
 “total_rows”: 1
}

To determine which borough was returned in the response we need to use the Number property from the rows object of our JSON response, so we access this by navigating through the JSON:

.prop(“rows”) allows us to access the array of boroughs that the SQL API found. In our case there will only ever be one row, so we use .elements().get(0) to get get the first item in the array.
Then we use .prop(“number”).numberValue() to get the number of the borough from the number property and we use the NumberValue() function to return the number property as a Number rather than a String/text with quotes.

Sequence Flows

We use BPMN’s sequence flows (the arrows) to connect the tasks and decision points together. Camunda makes this easy to configure using the embeded expressions: