Evolve or rebuild? - a case study into the effects of regulatory changes on a legacy system -

U

NIVERSITY OF

A

MSTERDAM

M

’

T

Evolve or rebuild?

a case study into the effects of regulatory changes on a legacy system

-Author:

Toine KHONRAAD

Supervisor: Prof. Patricia LAGO

A thesis submitted in fulfilment of the requirements for the degree of Master of Science in Software Engineering

to the

Graduate school of informatics

i

Declaration of Authorship

I, Toine KHONRAAD, declare that this thesis titled, “Evolve or rebuild?” and the work presented in it are my own. I confirm that:

• Where any part of this thesis has previously been submitted for a degree or any other qualification at this university or any other institution, this has been clearly stated.

• Where I have consulted the published work of others, this is always clearly attributed.

• Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work.

• I have acknowledged all main sources of help.

• Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed my-self.

Amsterdam, August 28, 2018,

Toine KHONRAAD1

1_{Disambiguation: From hereon, where this thesis mentions "Khonraad", it will refer to the privately} held, Dutch company "Khonraad Software Engineering B.V.".

ii

UNIVERSITY OF AMSTERDAM

Abstract

Faculty of Science

Master of Science in Software Engineering

Evolve or rebuild?

a case study into the effects of regulatory changes on a legacy system -by Toine KHONRAAD

BOPZ-Online is a SaaS used by the Dutch local governments, implementing the law that governs the procedure for committing people against their will to a psychiatric hospital.

Currently upcoming major changes in the governing regulations, challenges its soft-ware architecture ability to show its compliance. This case study aims to identify and weigh the arguments contributing to making a well-informed decision on whether BOPZ-Online should be evolved or rebuilt.

A qualitative approach was chosen with the aid of a series of complementary meth-ods. It was found that the most prominent prospective impacts would come from exchanging BOPZ-Online’s "Model-View-Controller" architectural pattern for that of the "Model-View-Presenter", next to adapting an industry standard Workflow En-gine.

Further research is suggested into the business strategic and economic factors relat-ing to software evolution.

iii

Contents

1.2.1 Searching for endorsing and counter arguments . . . 3

1.2.2 Uncovering past architectural decisions and their rationales . . 3

1.2.3 Establishing the impacts of evolving or rebuilding the system . 4 1.2.4 Concluding . . . 4

1.3 Background . . . 4

2 Searching for endorsing and counter arguments 5 2.1 Participation in the iSAPS . . . 5

2.2 Proceedings . . . 6

2.2.1 Additional requirements introduced by the regulatory changes 6 a) Connection to the Public Prosecutor’s service platform 7 b) Public register of health care providers . . . 7

c) Digital access to a registry of Crisis intervention Cards 7 2.2.2 Architects’ Concerns . . . 8

a) Transfer of Architectural Knowledge (AK) . . . 8

b) Identifying Architectural Technical Debt (ATD) . . . . 8

c) Show compliance to the applicative rules and legislation 9 3 Uncovering Past Architectural Decisions and Their Rationales 10 3.1 Architectural Overview . . . 10

3.1.1 Driving architectural requirements . . . 11

3.1.2 High-level architectural views . . . 11

a) Logical view . . . 12

b) Deployment view . . . 15

3.2 Key Decisions . . . 15

3.2.1 Design decisions . . . 15

3.2.2 Implementation decisions . . . 15

4 Establishing the Impact of Evolving or Rebuilding the System 27 4.1 Qualitative recommendations . . . 27

4.1.1 Connection to the Public Prosecutor’s service platform . . . 28

iv

4.1.3 Digital access to a registry of Crisis intervention Cards . . . 28

4.1.4 Workflow-state through a Rule Engine. . . 29

4.1.5 Apply Model-View-Controller (MVC) pattern . . . 29

4.1.6 Apply Object-Relational Mapping (ORM) pattern . . . 29

4.1.7 Single role attribution . . . 29

5 Conclusions 30 5.1 Future Research . . . 30

A Background 31 A.1 Mental Health Care . . . 32

A.2 BOPZ-Online . . . 32

A.3 Domestic Violence. . . 33

A.3.1 Huisverbod-Online. . . 34

A.4 Khonraad’s portfolio . . . 34

A.5 New Legislation . . . 35

A.5.1 Evaluation of the WBopz . . . 35

A.5.2 An accelerating factor . . . 35

A.5.3 The WvGGZ. . . 36

B Deployment view 37 C Applicative legislative framework 39 C.1 Specialised law . . . 39

C.2 Rules of a general applicative nature . . . 40

v

List of Figures

1.1 Thesis design . . . 2

3.1 High-level overview, showing directed dependencies . . . 12

3.2 Domain model overview, UML . . . 13

vi

List of Tables

2.1 Requirements following from the new legislation. . . 6

3.1 Workflow-state through a Rule Engine . . . 17

3.2 Apply Model-View-Controller (MVC) pattern. . . 19

3.3 Separated Communication Services Tier . . . 21

3.4 Apply Dependency Inversion Principle . . . 23

3.5 Apply Object-Relational Mapping (ORM) pattern Principle . . . 24

3.6 Single role attribution. . . 26

vii

Glossary

HOvJ HulpOfficier van Justitie, The assistant public prosecutor is an investigating officer with some special criminal powers . . . 34

ibs inbewaringstelling, An emergency procedure to forcefully admit a person to a psychiatric hospital for a period of three days . . . 33

RIhG Risicotaxatie-instrument Huiselijk Geweld, With the Domestic Violence Risk Assessment Instrument a HovJ assesses whether a restraining order is imposed in this situation of (possible) domestic violence . . . 34

SaaS SaaS, According to WikipediaSoftware as a service(SaaS; pronounced /sæs/) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as "on-demand software", and was formerly referred to as "software plus services" by Microsoft. SaaS is typically accessed by users using a thin client via a web browser. SaaS has become a common delivery model for many business ap-plications, including office software, messaging software, payroll processing software, DBMS software, management software, CAD software, development software, gamification, virtualization, accounting, collaboration, customer rela-tionship management (CRM), Management Information Systems (MIS), enter-prise resource planning (ERP), invoicing, human resource management (HRM), talent acquisition, learning management systems, content management (CM), and service desk management. SaaS has been incorporated into the strategy of nearly all leading enterprise software companies . . . ii, 1

1

Chapter 1

Introduction

“If P, so why not Q?“

Sidney Morgenbesser on Jewish logic BOPZ-Online is a software as a service (SaaS ) used by the Dutch local governments (i.e., the municipalities) to implement legislation regarding involuntary psychiatric care1.

Currently, a major overhaul of laws relevant to this topic is taking place, thereby challenging the current system’s architecture.

1.1

Problem statement

A legacy system (BOPZ-Online has been in operation for 20 years now), its design is, for the most part, a result of decisions made years ago. Information technology has undergone numerous changes since then; therefore, some of those decisions and their resulting design may have different outcomes in view of today’s wider solution space.

Lehman’s laws of software evolution (Lehman et al., 1997) teach that evolving an existing software system is a surprisingly difficult task. Changes in the system’s environment (including technological progress) place evolutionary pressures on the system (Godfrey and German,2014), thereby eliciting maintenance tasks, as well as on an architectural dimension.

Given the magnitude of the regulatory changes that BOPZ-Online now faces, it is conceivable that the scale of the maintenance requirements warrants a rebuild of the system. Because of the possible far-reaching consequences in terms of cost, planning, and legal risks, determining the optimal method for turning the system into a new, compliant solution is difficult.

1_{When someone is acting in manners considered harmful or dangerous to themself or others, the} only solution may be to temporarily admit that person to a hospital in lieu of the human right of free-dom. Such a remedy is of course highly intimidating to the person involved. Therefore, the procedure for committing people against their will is strictly regulated; moreover, the decision to do so is not taken lightly. It involves a number of objective requirements that must be strictly enforced.

Chapter 1. Introduction 2

1.2

Thesis design

BOPZ-Online faces an upcoming, extensive legislative change, which potentially will have a major impact on the architecture of the system. This situation inspired the following main research question:

Main research question: Should the current system, "BOPZ-Online," be evolved or rebuilt to comply with the upcoming changes in the law?

To address this question, this study aimed to first identify and weigh the arguments that contribute to making an informed decision. Therefore, we opted for a research design that divided this question into three sub-questions (see Figure1.1).

Chapter 1. Introduction 3

Research question I: What are the arguments for and against evolving or rebuilding the system?

Research question II: What past decisions are embedded in the current system’s soft-ware architecture?

Research question III: What are the potential impacts of evolving or rebuilding the system for the software architecture at hand?

In the following subsections, we provide a short motivation for each sub-question and explain the research methodology that we adopted to answer it.

1.2.1 Searching for endorsing and counter arguments

Starting from the application domain, we searched for arguments that would either endorse or counter the choice to either evolve or rebuild the system. For this, we used the well-known focus-group research method.

A focus group is an informal gathering of people participating in a planned discus-sion on a particular topic. The focus-group method allows members of the group to interact and influence each other during the discussion and consideration of ideas and perspectives. According to Gibbs (1997), the main purpose of focus group re-search is to draw upon the respondents’ attitudes, feelings, beliefs, experiences, and reactions in a way that would not be feasible using other methods; for example, through observation, one-to-one interviews, or questionnaire surveys. These atti-tudes, feelings, and beliefs may be partially independent of the group or its social setting, but are more likely to be revealed through the social gathering and the inter-actions that being in a focus group entails.

Given the opportunity to present our case at the 2018 “International Software Ar-chitecture PhD School (iSAPS)”, we were able to facilitate such a focus group and have informal discussions under the moderation of experts in the field of software architecture. We selected five PhD students to participate in this discussion and were able to reveal more insight into and potential improvements of the system, as well as arguments endorsing or countering the decision to either fully rebuild or evolve BOPZ-Online in the near future.

Chapter2reports on the results of this research.

1.2.2 Uncovering past architectural decisions and their rationales

We aimed to uncover past decisions from the system’s current architecture to deter-mine the impact that these arguments would have on either option. We employed a strategy inspired by the techniques from the research method called decision cen-tric architecture review (DCAR). This practice is described in detail in (Heesch et al.,

2014).

Chapter 1. Introduction 4 architects and developers enabled us to establish a comprehensive list of the past de-sign decisions and their rationales, using the results of Section1.2.1as an additional source.

This process is further documented in Chapter3.

1.2.3 Establishing the impacts of evolving or rebuilding the system

Analysing the past decisions and rationales (see Section1.2.2) triggered by the find-ings of the focus group (Section1.2.1) allowed us to draw up qualitative recommen-dations regarding the overall decision as stated in Section1.2.

These qualitative recommendations are provided in Chapter4.

1.2.4 Concluding

Finally, we provide conclusions as well as suggestions for future research in Chapter

5.

1.3

Background

Introduced by Evans in Domain-Driven Design – Tackling Complexity in the Heart of Software (2003) a domain-driven design methodology promotes to agree on what is called a context bounded "ubiquitous language". Systems such as BOPZ-Online, which transcend the domains of legislation and engineering, must not only speak these domain’s vernacular languages, but also, in a way, translate them to each other. Within the evolutionary context of this thesis, we therefore consider it valuable to give some (historical) background of both domains in AppendixA.

5

Chapter 2

Searching for endorsing and

counter arguments

“Nein, gerade Tatsachen gibt es nicht, nur Interpretationen.“

Friedrich Nietzsche The results in this chapter stem from Khonraad’s participation in the International Software Architecture PhD School (iSAPS). In 2016, Prof. Patricia Lago, Prof. Paris Avgeriou and Prof. Philippe Kruchten jointly recognised a gap in PhD students as well as practising architects’ training in state-of-art academic and industrial the-ories and technologies. To bridge this gap, they jointly organised the iSAPS.

For the first time in June 2017, at the Lorentz Centre in Leiden, this four-day school was attended by some 50 PhD students, academic researchers, and architects from the industry. Lectures and presentations in the morning were followed by afternoon workshops wherein the students actively participated in analysing and working on several actual industrial cases presented to them.

Indeed, it served the foreseen (and above mentioned) goal. The event report states: "Many PhD students were not aware of the complexity of either software architecture in practice, or the role of the architect. The importance of social and cognitive aspects intrinsic to software architecture design and design-decision making were also a surprise, along with the combination with empirical research: architecture as a theory to guide architecture design."

It was therefore decided to make the iSAPS a recurring event.

2.1

Participation in the iSAPS

We attended the iSAPS from April 23 to 26, 2018 as one of the industrial case presen-ters, together with CGI, Centric, and Océ. Our case was themed as the (of course not immediately answerable) question of either rebuilding or enhancing BOPZ-Online to comply with the new legislation.

The 2018 lectures focussed on architectural design decision rationality, scalable ar-chitectures, the role of the architect, technical debt, architecture representation, and

Chapter 2. Searching for endorsing and counter arguments 6 DevOps. To the extend possible, we attempted to connect the lecture’s "subjects of the day" to the workshop programme of the afternoons.

All the students of the school were asked to engage in one of the five industrial cases based on their preferences and in connection to their research topic. To our case we welcomed five participants out of which four PhD students are academically employed and conduct research on architectural technical debt, software engineer-ing, software analytics, and architectural patterns, whereas one student works as an enterprise architect at an aerospace conglomerate.

2.2

Proceedings

We introduced the enterprise and business context of BOPZ-Online before present-ing the viewpoint for developers and maintainers. We expected the students to have a general understanding of a workflow-centric approach in solving the main chal-lenges of BOPZ-Online as a legally high-constrained communications platform. Only well after we started reasoning about and discussing the rationale of the cur-rent architecture of the system did it emerge that — notwithstanding the efforts of the moderators to steer the discussions — it probably would have been much more ef-fective had we prepared an introductory presentation on workflow abstractions and business process management, knowing that such a presumed background in the fields of enterprise information systems and workflow management understanding was generally not present.

2.2.1 Additional requirements introduced by the regulatory changes

After briefly introducing workflow concepts and their implementation and present-ing the background of the current law and governments’ considerations leadpresent-ing to the new legislation, we focused on the legacy aspects of the code base in relation to some of the architecturally significant1 requirements that the future regulatory changes will elicit. These additional requirements are presented in Table2.1.

TABLE2.1: Requirements following from the new legislation

ID Description

Requirement I Connection to the Public Prosecutor’s service platform

Requirement II Public register of Healthcare Providers

Requirement III Digital access to a registry of Crisis intervention Cards

1_{In accordance with (Bass et al.,2012), and as is generally agreed upon in the field, we consider a} requirement to be architecturally significant when it has (here: is assumed to have) a profound influence on the system’s architecture.

Chapter 2. Searching for endorsing and counter arguments 7

a) Connection to the Public Prosecutor’s service platform

Currently being formulated, as part of the introduction of the new laws, a national Reference Architecture stipulates a central role for the Public Prosecutor’s office in overseeing the execution of all legal measures within this context. Therefore, the Public Prosecutor’s office is currently designing a digital service platform for real-time exchange of information.

Connecting to that platform will be required.

b) Public register of health care providers

Currently,the Ministerie van Volksgezondheid, Welzijn en Sport (VWS)2, keeps a record of the so-called "BOPZ-indicated" health care providers. By law, only such indi-cated health care providers are allowed to participate in providing care within a non-voluntary context. An overview of these records is published periodically in the Government Gazette.

There is, however, no digital link between the VWS records and those used by BOPZ-Online. This has two reasons. First, VWS’s records are not available in a format suitable for automated data exchange. Second, in practice, the overview of VWS is not always "up-to-date". Therefore, BOPZ-Online’s records are managed in a reactive manner, by adding new locations every time a justified report indicating required additions or changes is received from a psychiatrist. Obviously, these procedures can lead to undesirable delays.

The upcoming laws explicitly disallow care providers from providing compulsory care if they are not included in a new "public register". This register will replace the current BOPZ-indicated records.

It is foreseen that BOPZ-Online will handle this new public register under supervi-sion of VWS.

c) Digital access to a registry of Crisis intervention Cards

A "Crisis intervention Card" (CiC) is meant for people vulnerable to psychiatric crises. During a psychiatric crisis, it is often difficult to explain what kind of help is best suited. Currently, some clients of mental health institutions carry a CiC in their pock-ets. The CiC can explain to professionals (including police, usually first to arrive on-scene) what a crisis looks like for the person concerned, and suggest ways to provide personalised help, usually proven effective from history. However, the availability, or even establishing the existence of a CiC in an actual emergency situation, is typically challenged by situational circumstances.

As the new laws explicitly require the assessment of an existing CiC, the suggestion was made to set-up a nationwide registration of CiCs. As the access-authorization of that registration coincides almost seamlessly to the mechanisms and acting parties of BOPZ-Online, setting up this registration will be a task for Khonraad.

Chapter 2. Searching for endorsing and counter arguments 8

2.2.2 Architects’ Concerns

In general, we could identify three concerns for the architects:

a) Transfer of Architectural Knowledge (AK)

For BOPZ-Online, the architect desires that the Architectural Knowledge (AK) be transferable to other stakeholders (future developers and maintainers, management, and owners), satisfied by creating architectural documentation.

Currently there exists little to no updated written documentation of the current archi-tecture. Creating the required documentation was identified as an important short-term project. According to standard industry practice, the documentation process normally takes place as part of the design efforts by architects. By no means is it uncommon — as is the case here — that due to the time pressures of "getting the software out", creating such documentation "takes a back seat" and is left as a task for the future. If at all the time ever comes to start working on that task, more often than not, redesigns (undocumented as well) will have taken place, and some of the design-ers and developdesign-ers will have left the company, and thus this task assumes a greater magnitude than anticipated. Two members of the team spontaneously phrased this documentation deficiency as a typical case of technical debt.

As Heesch et al. (2014) pointed out, such an existing deficiency could be alleviated by a short-term architecture review distilling and ex-post recording of former design decisions. Based on that, a comprehensive Architectural Documentation (AD) could than be drafted, taking into account stakeholders’ concerns and respective view-points, including the proposed decision model additions to ISO/EC/IEEE 42010:2011(E).

b) Identifying Architectural Technical Debt (ATD)

For BOPZ-Online, the architect desires that the Architectural Technical Debt (ATD) is identified, satisfied by projecting formerly made decisions considered expedient to their impact on future developments.

According to the Software Engineering Institute (SEI),3

"Delivering increasingly complex software-reliant systems demands better ways to man-age the long-term effects of short-term expedients known as technical debt."

This effectively states we can and should make a distinction between the accumula-tion of regular technical debt as a result of a lack of code quality and issues resulting from architectural changes leading to a deteriorating design.

Although static code analysis tools are considered helpful in detecting some of the "code smells" relating to the occurrences of technical debt, they as yet lack the poten-tial of identifying architectural technical debt. To conclusively find the most impor-tant areas of interest in these regards, human evaluation of the code and architecture will be necessary.

One of the workshops at the iSAPS considered just that, revealing what was consid-ered to be a too high level of verbosity in the code. It was suggested that this level

Chapter 2. Searching for endorsing and counter arguments 9 of verbosity hindered a thorough understanding of not only the code but also the underlying design or the architecture itself. As it was a formulated concern to use the software architecture to show the responsibility of regulatory compliance, this is a serious issue.

c) Show compliance to the applicative rules and legislation

For BOPZ-Online, the architect desires that future development’s results are able to show their compliance to the applicative rules and legislation, satisfied by being able to show their anchoring in the system’s architecture.

Being compliant to current and new legislation is at the heart of Khonraad’s customer expectations. More and more data controllers and processors, next to being compli-ant to the law (including the EU General Data Protection Regulation), are challenged to also show their compliance. This is somewhat at odds to the earlier exposed (see:

b) ) level of code verbosity and is as such an even more important concern for the architect.

We discussed replacing the "home-grown" workflow processing module by an in-dustrial (commercial or open-sourced) "off the shelf" workflow management tool. Also inspired by the Anthony Tang’s iSAPS lecture titled "Architecture Design De-cisions" on rationality of such decisions, the team concluded that the rationality of this decision also has a temporal component: although the earlier decision to build a workflow engine was made considering the then prevailing circumstances, as time went by, this is now challenged by the current technological maturity of alternatives.

10

Chapter 3

Uncovering Past Architectural

Decisions and Their Rationales

“Study the past if you would define the future.“

Confucius Assessing the impacts of changing requirements on the architecture of a software system requires access to its architectural documentation. Next to defining Architec-tural Knowledge, (Kruchten et al.,2006) clearly make a case for documenting decisions, as omitting that causes a considerable risk:

"Design Decisions and much of the Rationale are usually lost forever, or reside only in the head of the few people associated with them, if they are still around. . . . At a later stage, it then becomes difficult to trace the reasons of certain design decisions. In particular, during the evolution one may stumble upon these design decisions, try to undo them or work around them, and get into trouble when this turns out to be very costly if not impossible."

While maintaining BOPZ-Online over the years, keeping its architectural documen-tation up-to-date considerably lagged behind. As a result of that, the reasoning be-hind some of the design decisions made and other driving forces have become tacit knowledge. In light of the challenges posed by the coming regulatory changes on the system, we consider this to be a défaut.

We therefore decided to capture the most relevant1 _{design decisions made earlier}

through desk-study research and a Decision-Centric Architecture Review (DCAR) (Heesch et al.,2014).

3.1

Architectural Overview

To facilitate the interviews and discussions that were a part of our DCAR, we pre-sented the following high-level overview of BOPZ-Online’s current architecture.

1_{Within this context, we considered decisions relevant if they could have an effect on the decision to} either evolve or rebuild the system.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 11

3.1.1 Driving architectural requirements

BOPZ-Online is used by the local governments to enforce the law on special admis-sions to psychiatric hospitals. As it allows to take and register formal legal deciadmis-sions taken by authoritative parties, compliance to the laws and regulations is a promi-nent requirement. Furthermore, as the decision’s outcomes are open to appeal, the architecture should also guarantee non-repudiation of such legal decisions. Next to that, as the system processes personal, criminal, and medical data, security is of vital importance.

These requirements influenced the architecture through the following quality at-tributes:

• Traceability,

reporting on the origin, course, and outcome of case procedures; • Authenticity,

ensuring the authorities act under specific law or general administrative law; • Confidentiality,

act under a "need-to-know" basis; • Integrity,

rejecting unauthorised access on a case level; • Availability,

prevent loss of information while ensuring legally enforced preservation peri-ods.

3.1.2 High-level architectural views

The software development community widely acknowledges that domain modelling is central to good software design. Through domain modelling, software developers are able to express rich functionality and translate that functionality into software implementation that truly serves the needs of its users (Evans,2003).

As is shown in Figure3.1, the architecture depicts four layers: • Presentation layer,

with the responsibilities to show information to and allow inputs from the user; • Application layer,

coordinates usecase related tasks, delegating work to a selected Entity or Ser-vice Object from the next layer down;

• Domain layer,

representing the concepts of the purpose of the system in the "real-world". As such it contains all state with regards to the legal procedures and communi-cations carried out through BOPZ-Online, its users, business financials, and control data.

• Infrastructure layer,

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 12

FIGURE3.1: High-level overview, showing directed dependencies

a) Logical view

From a domain-centric perspective, and as is shown in Figure3.2, five logical kinds of data are defined:

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 13

FIGURE3.2: Domain model overview, UML

1. Case data,

entered into the system by users such as personal data, medical statements, legal findings, and the documents generated thereof in a portable document format (PDF);

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 14 2. Client data,

pertaining to the users of the system, their employing organisations, logs of their access to the system and interactions to case data, and signature scans; 3. Communication data,

contents and delivery progress of sent messages such as sent and failed faxes, sent text-messages, sent emails, and voice calls to the helpdesk;

4. Financial data,

used to generate monthly sales invoices by applying agreed upon client cost distribution rules;

5. Rostering data,

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 15

b) Deployment view

An overview of the current deployment is given for further reference in AppendixB.

3.2

Key Decisions

Through desk-study research, reviewing the actual code base and revision control systems, we aimed to expose the most relevant decisions made. Although DCAR was developed as a research method to uncover, often tacit, architectural design de-cisions, we successfully applied the same techniques to uncover important imple-mentation decisions.

For each of the decisions, we created a table, describing it in more detail, includ-ing the considered alternatives2, and the historically identified forces in favour of or against it, formulated unambiguously using domain-specific vocabulary.

By interviewing the former architects and developers of BOPZ-Online, we then re-viewed the decisions, adding the review outcomes to the tables. The colour-coded summary of the review outcomes and rationales indicate the ratings given during the review: green for "good", yellow for "acceptable", and red for "has to be reconsidered".

3.2.1 Design decisions

Design decisions are related to the organisation of a component within its architec-tural context (in no particular order):

1. Workflow-state through a Rule Engine

2. Apply Model-View-Controller (MVC) pattern 3. Separated Communication Services Tier 4. Apply Dependency Inversion Principle

5. Apply Object-Relational Mapping (ORM) pattern 6. Single role attribution

3.2.2 Implementation decisions

Implementation decisions relate to the ways a component is constructed or adapted to fit its purpose (in no particular order):

1. Choice of a Java Persistence API (JPA) provider 2. Use of Acegi Security framework

3. Use of Business Intelligence and Reporting Tools (BIRT)

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 16 4. Use of Apache POI3

5. Use of Flying Saucer XML/CSS renderer 6. Use of Velocity

7. Use of Direct Web Remoting (DWR)

3_{According to Wikipedia, the name was originally an acronym for "Poor Obfuscation} Implementa-tion", referring humorously to the fact that the file formats seemed to be deliberately obfuscated, but poorly, since they were successfully reverse-engineered.

DCAR Workflow-state through a Rule Engine

Problem(s) In complying to the law, the workflow capacities of BOPZ-Online play an important role in its operational services. Parallel to the overhaul from the ColdFusion platform to Java in 2003 it was established that BOPZ-Online should separate its business logic from the code.

Solution or description of decision

Model the workflow abstractions using a Rule Engine.

All processes are disassembled into atomic tasks that decent from an abstraction (a bit confusingly) called a UseCase. A "Strategy Pattern" implements activating such UseCases.

Considered

alternative solutions

Historically (2003/2004) a lot of effort has been put into using (and adapting) the so called “java Business Process Manager” (jBPM), a then emerging open source project. Architecturally jBPM presented a so called Virtual Process Machine (VPM) that allowed execution of process definition written in XML. Process descriptions had to be 'loaded' into the virtual processor's memory and could be controlled through Java API-calls. Presenting itself as a framework, it would allow call-backs through process defined entry-points within 'user-space' whenever a defined state change arose during the execution of a running process.

By 2004 we noticed the project had started to build up higher levels of technical debt. At the same time, we gathered a growing insight that having to repeatedly (re-)map our domain-model - that was mostly influenced by legal requirements - to the more generalized model targeted at wide spread acceptance within the Java community was becoming just too inconvenient.

Next to that jBPM turned out to become more and more fragile. At that time, jBPM, while trying to fill the then perceived existing gap in the availability of workflow engines, practically left us with no viable alternative, other than implementing the requirements ourselves.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 17 TABLE3.1: Workflow-state through a Rule Engine

DCAR Workflow-state through a Rule Engine

Forces in favour of decision

• Allow formulating the business process in terms of data, thus enabling meta-programming.

• Changing the rules have little to no effect on the code. • It uses a declarative definition of the business rules, that

can be expressed using a domain specific language that business analysts can validate and understand. In other words, one can define what to do and not how to do it; • Off-the-shelf solutions are considered to be inefficient and

fragile.

• Keeping the business logic decoupled from the rest of the application, allows changing them in separated ways. Forces against the

decision

• Deciding against continuing the developments made within jBPM and its use, comes with considerable risk of inherent implementation errors, as well as performance and (then difficult to measure) scalability issues.

Outcomes and

rationales • The solution chosen is well-understood by the development _team. • Through use of its DSL, it can be easily adapted to satisfy

new demands.

• We should reconsider the decision, as “off-the-shelf” solutions have matured over the recent years. Especially “Camunda BPM” looks very promising.

Camunda BPM is a free workflow management system written in Java that defines and executes business processes in BPMN 2.0. Camunda BPM also supports the CMMN 1.1 and DMN 1.1 standardized by the Object Management Group (OMG).

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 18 TABLE3.1: Workflow-state through a Rule Engine

DCAR Apply Model-View-Controller (MVC) pattern

Problem(s) User Interface components should be decoupled from the domain-model.

Solution or description of decision

Apply the Model-View-Controller (MVC) architectural pattern by dividing the application’s responsibilities across three

interconnected components: 1. Model,

referencing the domain-layer’s entities; 2. View,

an abstraction of the representation of the data as shown to users;

3. Controller,

accepts and validates user inputs for manipulation of the Model.

Applying the MVC pattern displays clear separation of concerns in flexible and adaptable ways.

Considered

alternative solutions

• Apply the Model-View-Presenter (MVP) pattern, as to completely shield the View and Model from each other. Where MVC employs a Controller (see above), MVP’s Presenter defines separate interfaces to the View and to the Model.

Forces in favour of decision

• Well known solution

• Allows for the Front Controller Pattern (FCP) • General availability of frameworks targeting MVC Forces against the

decision

• The view is more loosely coupled to the Model via the Presenter interface

• MVP makes unit testing easier

• MVP allows for multiple presenters for complex Views • MVC is more liable to allow leakage of Domain Business

Rules to the View Outcomes and

rationales • The solution chosen is well-understood, and proven to be _efficient. Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 19

DCAR Apply Model-View-Controller (MVC) pattern

• Changing to MVP could turn out to be a lot of work.

• We should reconsider the decision, as the meanwhile undertaken evaluation of the “Vaadin”-framework reported several positive driving forces to consider its use, among which allowing the application of MVP-pattern.

According to Wikipedia (https://en.wikipedia.org/wiki/Vaadin):

“Vaadin is an open-source platform for web application development. The Vaadin platform includes a set of web components, a Java web framework, and a set of tools and application starters. Its flagship product, Vaadin Flow (previously Vaadin Framework) allows the implementation of HTML5 web user interfaces using the Java

Programming Language.”

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 20 TABLE3.2: Apply Model-View-Controller (MVC) pattern

DCAR Separated Communication Services Tier

Problem(s) Under Dutch administrative law, only the act of announcement (bekendmaking) of an administrative decision brings its legal consequences into effect. Although, under the same law, this announcement can be done verbally, it always has to be followed by an immediate supply of a written statement.

Recipients, external to the system, require different channels, protocols, and formats exchanging these messages. Messages are predominately created in line with the governing workflows, but also through specific client’s requests, for instance requiring BOPZ-Online to send messages about messages’ deliveries to other recipients.

(Temporary) communication failures in one channel, should not hinder other deliverances to progress, be retried automatically and - when problems persist - be reported on to a human operator for intervention.

As a result, messages must be sent asynchronously, with

guaranteed delivery, through different channels. In addition, the entire communication process must be traceable.

Solution or description of decision

Separate the process of creating a messaging job from actually running that job (i.e. sending out the contained information to its destination). For each type of job, its execution progress is held, and monitored to enable operator interventions.

Apply the Message Broker pattern to enable fulfilment of routing requirements.

Apply the Message Store pattern, so as to be able to report on all communications.

Considered

alternative solutions

Make use of (Java) message-oriented middleware products available in the market like "Apache ActiveMQ" or "OpenJMS". Forces in favour of

decision

• The database infrastructure was already available. • The available, relational database uses very well

established, stable technologies, allowing a data

preservation process to uphold four traits that are generally Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 21

DCAR Separated Communication Services Tier

known as "Atomicity, Consistency, Isolation and Durability (ACID)".

• Alternative solutions would require much more technical involvement of recipients.

Forces against the decision

• As the database will be polled for executable jobs, its time-resolution interval becomes a sensitivity point.

• There could be scalability problems when demands are growing.

Outcomes and

rationales • Current solution seems to be working okay (polling _{resolution set to 1 minute).} • With the increase of the number of different channels and

routing requirements, complexity has risen and refactoring is asked for.

• The CRUD-interface now used for reporting and operator interventions asks for further developments into a ‘full blown’ application.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 22 TABLE3.3: Separated Communication Services Tier

DCAR Apply Dependency Inversion Principle

Problem(s) It should be possible to test components of the system in isolation and assemble the generic ones into new applications. This requires observing dependencies between components as an architectural concern.

Solution or description of decision

According to the general concept of Inversion of Control (IoC), a class should not configure its dependencies statically. You can think of it as a special case of "Tell-Don't-Ask", involving the creation and connection between components.

Ideally components should be as independent as possible from other components.

Considered

alternative solutions

The Service Locator Pattern (SLP): have an object (the Locator) that can provide all of the services that an application might need.

Forces in favour of decision

• There is no need for every user of a service to have a dependency to the Locator used in SLP.

Forces against the decision

• Adds (some) complexity to the system.

• When implemented using a framework, adds a dependency to that framework.

Outcomes and

rationales • Allows high modularization of the application to become _{highly visible throughout the design, thereby preventing}

‘broken-window-deterioration’.

• Allows testability of components in isolation.

• Has demonstrated risk of being overused to the level of ‘gold-plating’.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 23 TABLE3.4: Apply Dependency Inversion Principle

DCAR Apply Object-Relational Mapping (ORM) pattern

Problem(s) As Wikipedia (

https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch) states, fundamentally, objects reference one another and therefore form a graph in the mathematical sense (a network including loops and cycles). Relational database schemas are, in contrast, tabular and based on a relational algebra, which defines linked heterogeneous tuples (groupings of data fields into a "row" with different types for each field).

This fundamental impedance mismatch gives rise to many difficulties serializing data held within the Domain-Layer to a relational database.

Solution or description of decision

ORM provides a mechanism to directly use objects and interact with the database.

Considered

alternative solutions

Use the relational model in memory. Forces in favour of

decision

• Allows modelling the business problem in Domain using the domain’s ubiquitous language.

• Provides database independence. • There is no need to write SQL-queries.

• Semi-automatically maps complex associations in the Model to otherwise difficult to create ‘joins’ in the relational model.

• Defines transactional borders.

• Allows for versioning to prevent stale updates. Forces against the

decision

• Calls for a rather complicated mapping specification • Steep learning curve, especially for corner cases in mapping

and avoiding the so called “(n+1) select issue” • Limited use for (large) batch-updates

Outcomes and

rationales • Careful drafted mappings allow for excellent performance _{even without caching.} Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 24

DCAR Apply Object-Relational Mapping (ORM) pattern

• The current implementation maps “one-to-one”

associations through ‘mis-use’ of “many-to-one”. This can be very confusing to new developers.

• The current use of an outdated “Hibernate”

implementation could have been more easily updated through adapting the (meanwhile available) Java Persistence API (JPA) specification.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 25 TABLE3.5: Apply Object-Relational Mapping (ORM) pattern

DCAR Single role attribution

Problem(s) In using the system, a user will ‘be’ in what is generally known as a Role. Role-based access control (RBAC is an approach to restricting access to authorized users. As a security measure, by default, access will not be granted to the system or an

information element therein.

To gain access, a user must show his authority through authentication and permission from the rights management policies at a case level.

Solution or description of decision

Within BOPZ-Online, a single role is assigned to the user when he logs in successfully. This role is an attribute of type

Enumeration, held within the Professional class. Considered

alternative solutions

• Design an entity abstracting the roles within the Domain to allow for more than one value.

• Make use of generally available, authentication platforms like the Lightweight Directory Access Protocol (LDAP). Forces in favour of

decision

• The solution is (very) simple to implement.

Forces against the decision

• The alternatives were labelled as “You aren't gonna need it” (YAGNI).

Outcomes and

rationales

This decision needs to reconsidered as:

• it proved to generate technical debt;

• now, some users, by lack of alternative means to act under different roles, hold more than one account, only differing in role.

Chapter 3. Uncovering Past Architectural Decisions and Their Rationales 26 TABLE3.6: Single role attribution

27

Chapter 4

Establishing the Impact of Evolving

or Rebuilding the System

“In my house I’m the boss, my wife is just the decision maker.“

Woody Allen Before answering our third research question

"What are the potential impacts of evolving or rebuilding the system for the software architecture at hand?"

we first discuss the concept of impact. Software architecture can be viewed as re-sulting from decisions that, once taken, are difficult or costly to change. On that basis alone, the prospective impacts of changing such decisions are likely to be high. Moreover, as architectural decisions are often interdependent, and, by definition, in-volve trade-offs with regard to the extent to which non-functional requirements will be met, expressing impact in terms of financial cost or other quantitative measure is very difficult (Sneed,1995).

4.1

Qualitative recommendations

For each of the architectural decisions (as reported on in Chapter3), tentatively iden-tified as "subject to change", we qualitatively projected the impact to the system’s software architecture by means of a rating using an ordinal scale comprised of a five-star system, the number of stars representing "lowest impact" (one star), "some impact" (two stars), "medium impact" (three stars), "moderate to high impact" (four stars), and "high impact" (five stars). Also taking into account the projected impacts of the new functional requirements imposed by the upcoming changes in the laws and regulations, we compiled the results of this into Table4.1.

Chapter 4. Establishing the Impact of Evolving or Rebuilding the System 28 TABLE4.1: Architectural impacts of changes.

Tentative Architectural

decision impact

New requirements

Connection to the Public Prosecutor’s service platform Public register of Healthcare Providers

Digital access to a registry of Crisis cards

Decisions

Workflow-state through a Rule Engine Change

Apply Model-View-Controller (MVC) pattern Change

Separated Communication Services Tier Keep

Apply Dependency Inversion Principle Keep

Apply Object-Relational Mapping (ORM) pattern Change

Single role attribution Change

4.1.1 Connection to the Public Prosecutor’s service platform

The service platform the Public Prosecutor’s office is planning to use as of January 1, 2020 is currently in its design and development stage. As the application program-ming interface (API), the delivery platform(s), and its Service Level Agreement (SLA) are to be further discussed and put in place, the impact(s) to BOPZ-Online’s architec-ture remain uncertain. However, based on the experience gained from establishing a similar, albeit simpler, messaging channel used by the Legal Aid Counsel (Raad voor Rechtsbijstand), for now, it was rated to have "medium impact".

4.1.2 Public register of health care providers

Provisioning for the development of the required services to establish a public regis-ter of health care providers will require the consultation of the opinions of the Min-istry of Health as well as the public mental health sectors. As the register would integrate smoothly into the existing use cases, the impacts of setting up this regis-ter are largely deregis-termined by its foreseen legal status. Therefore, the architectural impacts are considered "low".

4.1.3 Digital access to a registry of Crisis intervention Cards

Giving access to the system to patients and their representatives, more specifically to their Crisis intervention Card, will require BOPZ-Online’s connection to an ex-ternal authentication infrastructure like DigiD or iDIN. Due to the consideration of a number of these connection establishment’s requirements, the impact was rated "medium".

Chapter 4. Establishing the Impact of Evolving or Rebuilding the System 29

4.1.4 Workflow-state through a Rule Engine

Following the suggestions made during the DCAR (see Chapter 3) the impact of using an "off-the-shelf" Workflow Management System (WMS) was rated with four stars, which expresses its architectural impact as "moderate to high".

4.1.5 Apply Model-View-Controller (MVC) pattern

The decision to apply a MVP-pattern instead of a MVC-pattern will cause many changes to the interface of the View layer. The alternative suggested (Vaadin) will come with the many, usually transitive, dependencies platforms in general bring. Therefore the impact is considered to be "moderate to high".

4.1.6 Apply Object-Relational Mapping (ORM) pattern

Full adaptation of the JPA specification in the appliance of ORM will come with some, minor changes, that mostly will be implemented through further detailing and reor-ganising an existing small software layer containing Data Transfer Objects (DTO). Therefore the architectural impact is considered "low".

4.1.7 Single role attribution

Changing the former decision of attributing a single role to a user, despite having aggregated fairly large amounts of technical debt (Mens,2008), will come with con-siderable development efforts. Therefore, the architectural impact is conceived to be "low".

30

Chapter 5

Conclusions

The aim of this study was to identify and weigh the arguments that contribute to a well-informed decision on whether BOPZ-Online should be evolved or rebuild in order to comply with the forthcoming changes to the law. A qualitative approach was chosen with the aid of a series of complementary methods. The research has provided insights into the architecture of the system through its underlying decisions and identified a series of factors that can influence changing these decisions. These factors should be regarded as overlapping and complementary.

Software architecture, although generally not directly visible by itself, will, to a high degree, influence either instantly or eventually the very well visible characteristics of a built system, one of these being the concern we express as "evolvability" or the quality of being adaptable to an ever changing business environment.

In the case of BOPZ-Online, exchanging the Model-View-Controller pattern for that of the Model-View-Presenter will conceivably have the largest impact on its current architecture, next to adapting an industry standard Workflow Engine.

Although BOPZ-Online is a legacy system, the evaluation of its current architecture showed no signs of the system to be at the end of its life cycle. The external influences from the upcoming regulatory changes will certainly impact its architecture, but most probably only in limited and controllable ways.

We therefore conclude that, for BOPZ-Online, to comply to the upcoming changes in the law, our research advocates preferring the option of evolving the current system over that of rebuilding it.

5.1

Future Research

Originating all from a legislative driven background, BOPZ-Online, Huisverbod-Online (see Appendix A.4), and Jeudzorg-Online share technical, procedural, and organisational commonalities, that already have enabled reuse of an associated set of assets. Further capturing those into a "full-blown" Product Line Architecture (Bosch,

1999; Bass et al.,2012), perhaps would contribute to future impact analysis on future changing requirements.

31

Appendix A

Background

“Lasciate ogne speranza, voi ch’ intrate“

Abandon all hope, ye who enters here

-Dante

The Dutch translation

“Laat varen alle hoop, gij die hier binnentreedt.”

of Dante’s Inferno1 written on the gates of hell, once could be read above the gate to one of the oldest mental institutions in the Netherlands, the “Geneeskundig Ges-ticht Utrecht”, today known by the name “Willem Arntsz Huis” – words apparently considered suitable when entering the asylum established in 1461 for those inhab-itants of Utrecht who were arbitrary considered to be the dolle en armlastige2 ("the insane or lunatics, and the poor").

1_{Dante, Divina Commedia, Inferno III, line 9}

Appendix A. Background 32

A.1

Mental Health Care

In the 15th century, due to the rampant urbanisation, city residents felt the need to protect themselves against people with deviant behaviour: the so-called “insane”. The notion of insanity was was very broad; everything that fell outside the usual or desirable manners was quickly regarded as insane. Until well into the 19th century, on a completely random basis, people with deviant behavior were just stowed away in so-called “dol houses”, where no treatment was available, and the living conditions were very poor, if not just horrible.

The zeitgeist of the French revolution however brought about a certain humaniza-tion. The Royal Decree of King William I on April 11, 1818, the Menschlievend Besluit, was the first document which stated, in so many words, that the cure of insane peo-ple should be the goal of theses institutions. The Insanity Act, which was adopted in 1841, is in line with this objective. Although this law brought improvements to the patients’ conditions, it was primarily intended to protect society from deviant behaviour and did not provide any legal protection for the patients themselves. The same applied to the more extensive Act for the Regulation of the State Supervision of the Insane and Insane Asylums (Insanity Act, 1884, full text n.d.) that came into force in 1884. Still patients lost all their civil rights and were forcibly admitted "for their own good" for years, often leading to major abuse.

At the end of the 19th century, these abuses were first brought to light by an ex-patient. Then several patient protests followed. In the 20th century, professional insights regarding the care for psychiatric patients also changed. The first bill was submitted for a new law in 1971, but it was not before 1994 that the Insanity Act was replaced by the Wet bijzondere opnemingen in psychiatrische ziekenhuizen (WBopz)3, the Act on Special Admissions in Psychiatric Hospitals.

As of January 1, 2020, the Wet verplichte geestelijke gezondheidszorg (WvGGZ), the Law on Compulsory Mental Health Care, will be in effect. The leitmotif for the WvGGZ is to provide patient-following care whereas the current law is a location-centred rule-set. The WvGGZ is expected to be more practical to comply for the acting parties by reformulating their roles and tasks. Although within a compulsory context, patients will also have more freedom to choose the care they themselves consider suitable.

A.2

BOPZ-Online

The WBopz authorises care providers to forcibly admit patients who pose as a risk to themselves or to others caused by a disorder of their mental abilities in a psychiatric hospital, psycho-geriatric nursing home, or institution for the mentally handicapped. The law also offers possibilities to subject these people to forced treatment and other forms of coercion in the institution once they have been forcibly included. An impor-tant goal of the law is to provide legal protection for patients who are faced with this kind of far-reaching violations of their fundamental rights.

After its inception, all those involved had to get used to the new procedures of the WBopz and the new concepts and criteria in 1994. As the freedom-recognizing means

Appendix A. Background 33 and measures that can be applied under this Act are particularly drastic, it is ex-tremely important to apply these procedures very carefully. However, this was not easy because:

• cooperation between acting parties required extensive coordination and accu-racy;

• the administrative requirements became extensive; • standardization was missing;

• the relatively low incidence4_{, especially in smaller municipalities, meant that}

there was insufficient familiarity with how to act, what the possibilities were, where the available information had to be obtained, etc.

• the availability of all required information at the right time was therefore diffi-cult to achieve.

Particularly in the case of an emergency forced admission, the above constituted a bottleneck, in view of the short lead time of such a procedure. Khonraad Software Engineering BV (Khonraad) realized a solution for this bottleneck in 1998 in the form of the development of a workflow management system called Online. BOPZ-Online allows for direct, digital communication between parties, thereby allowing it to be much more efficient. Before using BOPZ-Online, frequently patients had to wait to up to eight hours in a police cell before the formal admission to hospital was settled. Nowadays this lead time on average is down to five minutes.

The use of coercion in mental health care has increased continuously since the in-troduction of the WBopz. The number of emergency forced admissions, or Inbewar-ingstelling in Dutch (ibs), increased by 34 percent in the last ten years, from 6,610 to 8,861, on an annual basis.

A.3

Domestic Violence

Domestic violence is a serious social problem. A study5by the Public Dutch Scientific Research and Documentation Centre (WODC) shows that although only over 50,000 incidents are reported to the police every year, it is estimated that some 450,000 in-cidents occur annually. Some fifty times a year (that is once every week!) a child actually dies as a result of violence, abuse, or neglect.

The applicable rules of law did not offer starting points in every respect to adequately combat this phenomenon. That is why there was a need for a new law, which pro-vides an instrument for mayors to combat violence in the private sphere, without the requirement of a criminal offence to have to been committed in the first place. In applying such measures, the government more or less enters the private domain of citizens. Intervention in the private sphere to bring people "forward" is morally charged in the Netherlands. But it is because of the threat to personal security and the appearance of domestic violence on the social climate that government intervention behind the front door is considered justified.

The Temporary Restraining Order Act6 _{(WtH) came into force on January 1, 2009.}

4_{The incidence is defined as the number of new cases that the procedure is applied within a year.} 5_{https://www.wodc.nl/binaries/jv1008-volledige-tekst_tcm28-77112.pdf}

Appendix A. Background 34 The rules set forward therein provide for the possibility of imposing a restraining order on those who pose the threat of domestic violence. The prohibition means that the person concerned may not enter his home during a certain period – in principle ten days – and may not contact his house-mates, such as his spouse, partner, or chil-dren. The safety of these persons is thus increased. They receive a breathing space that can be used to take other measures to remove the threat of domestic violence. The constant tensions and any underlying spiral of violence are taken away. For the banned person, the restraining order is a clear signal that society does not accept his/her violent behaviour.

A.3.1 Huisverbod-Online

Already before the introduction of the WtH, it appeared, also on the basis of the positive experiences with BOPZ-Online, that the acting parties would benefit from a workflow management system that could support them in the performance of their statutory duties. This has led to the development of the system called Huisverbod-Online.

The WtH specifically requires the use of the so-called “Risk Assessment Instrument for Domestic Violence” (RIhG )7. With the RIhG , the Assistant Public Prosecutor (HOvJ ) determines whether a restraining order can be imposed in a situation of possible do-mestic violence. The RiHG gathers information about three factors:

1. the possible perpetrator of domestic violence 2. the course of the incident

3. family backgrounds

The HOvJ is a senior level policeman who applies the RIhG , if possible, on spot, which is preceded by the collection of enveloping data by police and senior social care providers. A large number of people are involved in carrying out the procedure as a whole due to its complex legal requirements as many cases (almost half of them) show a combined application of criminal, private, and administrative law.

A.4

Khonraad’s portfolio

Khonraad offers services to the local government, in aspects of mental health care and social care, among other things, to collaborate in electronic files. In addition, formal decisions are made, written down, and communicated as part of the secure electronic file management. These services are equipped with comprehensive workflow man-agement functions that monitor process progress and timeliness. Advantages of this are:

• gains in speed through the efficient organization of the process;

• the creation of a legally sustainable, traceable, and user-friendly environment, which all parties can benefit from;

• the sub-processes are coordinated in detail and checked for completeness; 7_{https://www.huiselijkgeweld.nl/doc/beleid/concept_rihg_versie_2_1.pdf}

Appendix A. Background 35 • there are no misunderstandings about the steps to be taken in the process; • the workflow management system not only monitors the process, but also

sig-nals when the temporal execution does not happen in accordance with the agreement. As soon as an expected decision or document is not forthcoming, the system will send an email or text-message to the responsible party. If, as a result, the document is not yet in the system within a set time limit, a 24/7 manned helpdesk will report through a telephone action towards the controller; • the necessary documents can be filled in digitally and signed, and they are automatically prepared for the "next" partner in the chain. The next partner receives a signal (email or text-message) that the document is ready;

• minimization of the required input of the various forms;

• the overall process forms a repository and an archive, as all documents are kept in accordance with the legal retention requirements;

• the very fine-grained domain model employed allows for statistical analysis for policy makers and scientific research.

In 1998, the municipality of The Hague was the first to connect to BOPZ-Online (then called “IBS-systeem”). Due to the positive experiences of this pioneering municipal-ity, almost all Dutch municipalities followed suit. In addition, psychiatric hospitals, the police, and the judiciary along with numerous social service providers are also connected to BOPZ-Online and Huisverbod-Online. In total, around 600 organiza-tions now use these services and more than 10,000 users work with them. Twenty years after the inception, it can be said user satisfaction was and remains very high. For similar legislation such as the 2014 Youth Act8_{, the government has asked}

Khon-raad to facilitate the implementation of the requirements set forward by this law in similar ways.

A.5

New Legislation

A.5.1 Evaluation of the WBopz

After the Third Evaluation Committee reported that the WBopz no longer is in line with contemporary views, in 2008 the minister of health in a letter9 writes to the parliament:

“The evaluation committee concludes that the Bopz Act, despite its many changes, has remained more or less practicable. At the same time, it observes that the Bopz Act is not resistant to further drastic changes and is therefore not future-proof in all respects. With the evaluation committee, the Cabinet is of the opinion that a new, future-proof regulation must be established.”

A.5.2 An accelerating factor

The violent death of Mrs. E. Borst, D66 politician and former minister of health, led to the instalment of the so-called "Hoekstra Committee" that subsequently investigated

8_{http://wetten.overheid.nl/BWBR0034925/2018-01-01} 9_{https://zoek.officielebekendmakingen.nl/kst-25763-9.html}

Appendix A. Background 36 possible structural shortcomings in the working processes of the Public Prosecution Service and other bodies regarding "confused persons". In response to the recom-mendations made by the committee on February 8, 2014, the Board of Prosecutors General of the Public Prosecution Service drew up a comprehensive improvement program. In the mean time, a new bill had already been presented to the parliament. Based on the former conclusions, it became apparent that the process of creating new legislation needed to be accelerated.

A.5.3 The WvGGZ

One of the objectives of the new law is to reduce the number of compulsory ad-missions through the increased use of ambulatory coercion. The leitmotif for the WvGGZ is to provide patient-following care whereas the current law is a location-centered rule-set. The WvGGZ is expected to be more practical to comply for the acting parties by reformulating their roles and tasks. Although within a compulsory context, patients will also have more freedom to choose the care they themselves con-sider suitable.