ABB Vlaanderen - Kruispuntenbank Inburgering (KBI)

August 2011 till November 2013
Content:  
       

Management Summary

The Flemish Government desired a win-win situation to guarantee a performing and customer friendly management system for the facilitation of integration into the Flemish community, as well as reporting functionalities based on policy relevant information. Replacement of the previous system needed to address the requirements of all stakeholders involved, and all ICT domains (management of cases, interaction with other parties, and reporting functionality, as well as support an elaborate data migration exercise to retain all valuable data from the previous system.

In a nutshell, the key performance indicators for the acceptance of the new solution would be the following:

  • The solution must be a flexible, user friendly, intuitive and easily expandable one, which meets the requirements of its primary users. It should be constructed in a modular fashion, utilizing reusable functional building blocks. The solution must be configurable, and must be based on open architectures and standards.
  • The system should be constructed as lean as possible, based on the KISS (Keep It Simple Stupid) principle throughout the entire solution delivery life cycle.
  • Security and privacy are of primordial importance, and should be taken into account on all levels of the solution.
  • Reporting should happen in a user friendly way. It should give correct information, in such a way that it is easily understandable.
  • As much as possible, all integrations should go over Corvé, the service integration component of the Flemish government
  • The aspect of communication and deliberation with users, partners, governmental institutions, etc is crucial in this project. The emphasis should be on cooperation between all stakeholders to ensure a successful project.

Team Composition

The project team consisted of over 50 people, so it was natural to split up the responsibilities over seven tracks, each with its own track leader, and one overall project leader. Each of these tracks were assisted and coordinated by three architects (one business, one technical and one infrastructure), of which I was the technical architect. Evidently, these positions varied over my time at the project (the entirety of phase 1), but the names listed in the organigram are those who took up the role for most of the time.

The technical track, of which I was the lead, was divided into three subjects areas, each with their domain specialist, 7 development teams under the leadership of a technical designer, who had the ownership of a backlog of functionalities, which he had to deliver with the aide of 4 developers (giving a total of 28 developers). The domain architects also had an advisory role in all other tracks described in the first organigram.


Novelty Items

When designed the processes, a new concept was introduced as a role: the dynamic person. In short, this is a case handler with a twist. A certain number of activities can only be performed by the case handler assigned to a dossier. However, simply using a role [CaseHandler] in a swim lane is not sufficient. We would encounter the problem that all tasks, which have not yet been assigned, are visible to all people with this role. Our solution was to mix the process execution with some services, which manipulate ongoing processes. The services would make sure that once a person is assigned as a case handler of at least one dossier, he is granted the role [CaseHandler], and when he is no longer assigned to any, he loses said role. The services also make sure that when a task destined for a case handler is made available, it is immediately assigned to the correct case handler, so that other people with this role don’t see the tasks in their list. We also adapted these tasks so that case handler could not make these tasks available again, and could not reassign them to other people.

An additional complication is that the case handler during the course of the dossier will change depending on certain business rules. In this case, all tasks assigned to one person in the capacity of case handler are transferred via services to the new case handler, so that these tasks remain to be performed with the proper person.

As far as I can tell, there exists no simple and elegant solution for this type of role in BPMN, and the capabilities of the BPMS we used during the project (at that point Progress Savvion) didn’t offer any solace either. As indicated, we implemented services which performed these process instance manipulations through the API exposed by the BPMS, and these services where triggered by monitoring for correlations of the events put out by the process instances.

Lessons Learned

One of the lessons learned during the project, at least for me, is that the classification of the business activities is a very critical step in these kinds of projects where we attempt to automate them. Where the study for the project indicated that the business activities were structured into processes with a clear sequence and a drive towards standardization, during the analysis of the project, it became clear that these activities were indeed more of a variable/unstructured kind almost per geographical location where they were executed. However, as the licenses for the BPM server had already been purchased, and there was no case automation capability within this tool, it made the life of development of these automations a lot more interesting. As Bruce Silver said, 90% of all possibilities of CMMN are possible with BPMN, so it wasn’t a blocking issue. It however did make modeling and development a lot harder.

Correctly determining whether we needed cases or processes, would have been a very useful step before selecting the technology. Fortunately, nowadays, several BPM servers also have both process and case capability. The broad strokes of the guidelines I use for determining what capability to utilize, are derived from the illustration below, courtesy of Jim Sinur. It maps a specific technology to a gradation of the repeatability and predictability of the activities, ranging for custom development for processes that never change to human collaboration platforms (such as a Wiki) for activities whose sequence is never the same.


(c) Jim Sinur as seen in "Mastering the Unpredictable"

Project BPM ACM SOA Public Sector