Flooding Calamity Control

Research on communication, coordination and cooperation during a flood

SPM4910 – SEPAM Design Project Final Report Faculty of TPM – TU Delft Delft, June 9, 2006 Supervisors Prof. dr. R.W. Wagenaar Mr. A.J. Barendse Mw.dr.ir. W. Blok Dr. J.F.M. Koppenjan ICT group Thieme Hennis Susan Lagerweij Hidde Schipper Sebastiaan Surie Sebastiaan Tiemens 1052381 1150243 1024329 1014617 1102400

Preface
This report is put together as the main product of the SEPAM Design Project. It focuses on ICT-related solutions addressing the lack of communication and need for inter-organizational cooperation during calamities. Within this broad subject, the scope will be on the communication, cooperation and coordination between relief services during water calamities, and the possibilities to improve this through ICT. Attention does not solely go out to technological aspects, it also considers institutional and process matters, for in multidisciplinary problem situations analysis regarding these aspects is indispensable. In our analysis we were helped significantly by a number of persons. First of all many thanks go out to Mr. R.W. Wagenaar for his insight in technical issues. For feedback and additions on our preliminary report we would like to thank Mrs. W. Bockstael-Blok. Regarding institutional matters gratitude goes out to Mr. A.J. Barendse and Mr. J.P.M. Groenewegen. Furthermore, we would like to express our thanks to Mr. J.F.M. Koppenjan for the help on process issues. Finally, we would like to thank Mr. J.H. Appelman for his assistance in the technical and communication domain, and are grateful that he made it possible to experience a real life calamity exercise, which was of great help. We hope the report helps create the essential understanding of the technical, institutional, and process issues that play an important role in information exchange during a water calamity. The system designed in this paper should form the necessary step in water calamity information management. Thieme Hennis Susanne Lagerweij Hidde Schippers Sebastiaan Surie Sebastiaan Tiemens

SPM4910 – SEPAM Design Project (ICT) – Final Report

2

Index
Preface............................................................................................................. 2 Executive summary...........................................................................................6 1. Introduction................................................................................................ ...8 2. Problem analysis..........................................................................................10 2.1 Objectives............................................................................................ ........................11 2.1.1 Communication....................................................................................... ...............11 2.1.2 Coordination....................................................................................................... ....11 2.1.3 Cooperation............................................................................................................ 11 2.2 Paper structure....................................................................................................... ......12 Part I – Gaining insights in current water calamity control ................................13 3. Actor and Network Analysis..........................................................................14 3.1 Dedicated and non dedicated critical Actors......................................... .......................14 3.2 Calamity Plans............................................................................................................ ..15 3.2.1 Municipal- and District Calamity Plans....................................... ............................15 3.2.2 Operational Plans................................................................................... ................18 3.2.3 Calamity Relief Plans..................................................................................... .........20 3.3 Responsibilities and hierarchy........................................................................ ..............23 4. Technical analysis: the C2000 system............................................................24 4.1 Five ways to communicate........................................................................ ...................24 4.1.1 TETRA................................................................................................................. ....25 4.1.2 Equipment.......................................................................................................... ....25 4.1.3 C2000 from a user perspective........................................................ ......................26 4.1.4 Project progress....................................................................... ..............................26 4.2 SWOT analysis.......................................................................................................... ....27 5. Information streams and resources...............................................................28 5.1 Processes during a water calamity ............................................................. .................28 5.2 Main focus: the evacuation process.............................................. ...............................32 5.2.1 Analyzing relevant information .............................................. ...............................32 5.2.2 Draw up evacuation plan........................................................ ...............................33 5.2.3 Getting Personnel and Resources ready................................................. ................33 5.2.4 Use of Personnel and Resources....................................................................... ......33 5.2.5 Return people to their homes......................................................................... ........34 5.3 Other important processes................................................................................ ...........34 5.4 Current developments........................................................................................... .......34 5.4.1 FLIWAS................................................................................................ ...................34 6. Institutional situation...................................................................................36 6.1 Theories covering crisis situations.............................................................................. ..36 6.2 Theories covering the differences between governmental (emergency) organizations 36 6.2.1 Applying the four-layer model to the case......................................................... .....37 6.2.2 Highlighted problems resulting from the applied theory........................................38 7. Problem specification...................................................................................39 7.1 Sub researches....................................................................................................... ......39 7.1.1 Sub research 1 – Actor and network situation................................ ........................39 7.1.2 Sub research 2 – Current technical situation....................................... ...................40 7.1.3 Sub research 3 – Information situation..................................................... ..............40 7.1.4 Sub research 4 – Institutional situation..................................... .............................42 7.2 Reflection................................................................................................ .....................43 8. Design Proposal...........................................................................................44 8.1 Technological design aspects............................................................. ..........................44 8.2 Institutional design aspects................................................................................... .......44 8.3 Process design aspects................................................................. ...............................45 8.4 Program of requirements.......................................................................................... ....45

SPM4910 – SEPAM Design Project (ICT) – Final Report

3

8.4.1 Classes of requirements........................................................................... ..............45 8.4.2 Methodology............................................................................... ...........................45 8.4.3 List of requirements........................................................................ .......................46 Part II – Designing the Web GMS......................................................................49 9. Process design.............................................................................................50 9.1 Actors.............................................................................................................. ............50 9.2 Process design............................................................................ ................................50 9.3 Round 1; Generic process rules................................................................... ................51 9.4 Round 2; Requirements.............................................................................. ..................53 9.5 Round 3; Design issues..................................................................... ...........................55 9.6 Round 4; Costs and responsibilities............................................................... ...............59 9.7 Round 5; start project............................................................................................. ......62 9.8 Process design reflection.................................................................................... .........62 10. Technical Design......................................................................................... 63 10.1 Current situation GMS....................................................................... .........................63 10.1.1 Problems arising due to the centralized nature of GMS .......................................64 10.1.2 Necessary technical modifications................................................ .......................65 10.1.3 Method proposal: Service Oriented Architecture..................................................65 10.2 Service-Oriented Paradigm...................................................................................... ...66 10.2.1 Actor dimension............................................................................ .......................66 10.2.2 Service layer dimension..................................................................... ..................67 10.2.3 Service functionalities dimension.............................................................. ...........71 10.3 Proposed technical design: the WebGMS............................................................ .......71 10.3.1 Improvements....................................................................................... ...............72 10.3.2 User interaction................................................................................................. ...74 10.4 Interface.............................................................................................................. .......76 11. Institutional design....................................................................................78 11.1 Theory on institutional design.................................................................. ..................78 11.1.1 Design principles........................................................................................... .......78 11.1.2 Implementation challenges in institutional design...............................................78 11.2 Institutional arrangements...................................................................... ...................79 11.2.1 Compatibility with other systems.......................................................... ...............79 11.2.2 Standards and Semantics................................................................................. ....80 11.2.3 External systems and security................................................ .............................80 11.2.4 Responsibilities and authorization............................................................. ...........81 11.2.5 Costs and responsibilities........................................................................... ..........83 12. Conclusions and Recommendations.............................................................86 References.....................................................................................................87 Books....................................................................................................... .........................87 Papers and articles............................................................................................... .............87 Websites......................................................................................................................... ...88 Governmental documents................................................................................. ................89 Appendices.....................................................................................................91 Appendix I - Goal oriented analysis..................................................................91 Appendix II - Actor analysis.............................................................................92 II.1 Inventory of the actors............................................................................ ....................92 II.2 Actor analysis ............................................................................................. ................93 II.3 Dependency analysis................................................................................................ .102 II.4 Corresponding and contrasting problem perceptions, interests and goals................104 Appendix III – Operational plans.....................................................................105 Appendix V – Organisational structure............................................................106 Appendix VI - SWOT analysis.........................................................................107 Appendix VII – Processes during a water calamity...........................................109 VII.1 Monitoring............................................................................................... ................109 VII.2 Scale up....................................................................................... ...........................109

SPM4910 – SEPAM Design Project (ICT) – Final Report

4

VII.3 Evacuate.......................................................................................... .......................110 VII.4 Flood............................................................................................... ........................110 VII.5 Take care of damage...................................................................... .........................110 Appendix VIII – Evacuation processes.............................................................111 Appendix IX – Information systems.................................................................120 IX.1 Information about FLIWAS....................................................................... .................120 IX.2 Information about Infraweb.......................................................................... ............121 Appendix X – Group Decision Room session report..........................................122 Appendix XI - design issues...........................................................................127 XI.1 General design issues.................................................................... ..........................127 12.1 XI.2 Costs design issues........................................................................ ...................128 XI.3 Defining actor groups...................................................................................... .........129 XI.4 Overview of the process design................................................. ..............................129 Appendix XII – Technical design......................................................................130 Appendix XIII - Division of costs.....................................................................134 Appendix XIV - Institutional design WebGMS..................................................135 Appendix XV - Additions on the GMS template for the used interface...............137

SPM4910 – SEPAM Design Project (ICT) – Final Report

5

Executive summary
Various exercises on flooding calamity control pointed out that there the level of efficient cooperation and coordination is alarmingly low. These exercises showed various interaction problems between and within stakeholders, causing inefficiency and lack of control during calamities. Outdated or even wrong information, slow and insufficient communication, and little or no cooperation and coordination between actors are elements that can cause the impact large water calamities to be disastrous. Flood calamities require a highly multidisciplinary approach, with an enormous amount of information being communicated between actors involved in water calamity control. Control on this is very difficult, and more than often relief assistance fails on this point. With new ICT-technologies the controlling of relief services, the cooperation between them, and the vertical and horizontal communication, can be, and has to be improved. The control on flood calamities situates itself in the domains of many different actors, with each their own responsibilities, their own goals, ways of working, culture, influences and relations, knowledge, and importance. Numerous documents describe the scripts on how to act, the rules to follow, and the responsibilities to guard, which sometimes results in redundancy, no actions being undertaken, bad resource management, and slowness. The new communication network for relief services, C2000, has just become operational in combination with a collective alarm system (GMS). C2000 has created a communication infrastructure for all actors involved in water calamity control to work on. However, there still is no efficient information management system to ensure coordination and cooperation on this infrastructure. In the past few years programs have been developed to improve this. An example of this is the FLIWAS program, which is especially designed for water calamities, and helps develop solutions for resource management, evacuation plans, information plans, and more. The void in this picture, and also the goal of this project, lays in the connection between C2000 and relief assisting programs, such as FLIWAS. A technical design on itself will not be enough to solve the mentioned problems, because of the strong dependency on institutional factors and the broad range of actors involved in water calamity control. Thus, it is essential that the technical design is implemented in combination with a process- and institutional design in order to create a broad social basis. The combination of analyses on the different stakeholders, technical aspects, information streams, and the current institutional situation has led to the formulation of a series of requirements. These requirements have formed the input for the new systems design. Before the new system can be designed, it is necessary to set a number of process rules, to create a certain level of commitment to all the actors involved. The process design deals with these issues. The proposed technical system, called the WebGMS, is based on the introduction of an extra layer in the system for the emergency rooms (the GMS). This web-based system makes it possible to digitalize several information streams that do not need human interference. Examples of such information streams are weather reports, GIS maps, and emergency plans. Another advantage of WebGMS is that makes both push- and pull-based information possible; i.e. the relief worker can directly request (personalized) digital information from information systems connected to WebGMS. A last advantage of WebGMS is that it relieves the emergency rooms of a considerable amount of information demand and -load, for currently most communication in the GMS takes place through voice, which can be particularly slow and inefficient.

SPM4910 – SEPAM Design Project (ICT) – Final Report

6

Finally, the institutional design makes an attempt to fill in the gap between the process- and the technical design. Several institutional arrangements have been drawn up with regard to compatibility with other systems, standards and semantics, external systems and security, responsibilities and authorization, costs and responsibilities, and designer’s choice. The latter has brought in a breakthrough in information management; the introduction of calamity specific templates. This implies that the emergency room sends all relief workers a specific template, adapted to the stage the calamity is in. This clearly demarcates the amount of information a relief worker can acquire digitally and offers the emergency room the opportunity to remain in control. Moreover, such templates create opportunities to extend the application of WebGMS to other calamities, even on an international level. Most of the identified problems are solved by implementing WebGMS. Although WebGMS covers most of the technical problems and can be seen as a technical optimal solution, it must be said that some institutional problems arose. In order to cope with these institutional problems in the future some recommendations are made. When the Ministry of BZK and the regions start with the implementation of WebGMS, they should consider taking the following recommendations into account: The Web GMS should be coupled to the existing Fliwas system The Web GMS could form the basis for a general calamity control and information system The Web GMS could be coupled to international systems BZK should set up a central database on semantics BZK should secure cooperation, coordination and communication among the relief services Security issues should be subject of a follow-up research Once the system is implemented a second cost calculation should be executed

SPM4910 – SEPAM Design Project (ICT) – Final Report

7

1. Introduction
On the 6th of April 2005, the Bonfire crisis control exercise took place on different locations in the Netherlands. Bonfire was a special happening as it proceeded on certain issues much further than regular exercises had done until then. The exercise covered all involved authorities and institutions, which are involved in case of a real calamity situation. The purpose of this exercise was to train the decision making process in the full operational and governmental line in case of a terrorist impact on a soft target in the Netherlands (Project team ‘Borging Leerervaringen’ Bonfire, 2006). The exercise turned out to be a complete chaos and the levels of communication, coordination and cooperation were unacceptable. Strikingly, the authors of this paper encountered similar problems while participating in the Helga flood calamity exercise (May, 2006). Reflecting on these exercises and various critical evaluation reports (NRC, 2005b and Project team ‘Borging Leerervaringen’ Bonfire, 2006), it is understandable that both ministries of Transport, Public Works and Water Management (from now on VWS) and of Interior and Kingdom relations (from now on BZK) are questioning the impact of a large scale calamity. In this paper, one specific type of calamities will be treated, namely water calamities. Although the nature of terrorist attacks obviously is quite different from water calamities, in both cases it concerns an impact on a large scale in which a large amount of the same actors are involved. In the Netherlands, protection against floods of the rivers running throughout the country has always been an important issue. There are plans to widen the riverbeds of these rivers, including the Rijn and the Maas, in the upcoming years, with the objective to establish a safer situation. The town-planning decisions in “Ruimte voor de Rivier en de Maaswerken” form the fundament for this decision (Kabinet, 2005). Nevertheless, the risk of a flood should always be taken into account. Nature is capricious and therefore an accurate prediction of the water level for over a longer period is rather difficult. Consequently, the government of the Netherlands has recently expressed her intentions to determine a strategy for risk control during floods of rivers, in addition to the existing protection measures. Accordingly, the cabinet has ordered to analyze different measures based on so-called Calamity Flooding Areas (Noodoverloopgebieden) and land compartments, along with possible improvements by taking measures of foreign countries into account. Moreover, there is a need for a high standard concentrating on risk control organizations and higher safety standards (Directoraat Generaal Water, 2005). The Ministry of VWS carries the end responsibility over the protection of the Netherlands against possible flooding and therefore proactively performs research into flooding possibilities and prevention (Ministry of VWS, 2006). However, in case of a flood, the Ministry of BZK is responsible for the coordination, supervision and providence of a situation in which emergency or relief services can perform in an optimal way (Ministry of BZK, 2006). In case of a possible flood in the Netherlands, these two ministries are thus very dependent and interrelated with each other. The above makes clear that the organization of the involved authorities and institutions during a water calamity is very complex. Moreover, the existing strategies for calamity control seem to be far from optimal. Maintaining sufficient overview in such complex calamity situations has thus become considerably problematic. It seems that adequate solutions can be found through ICT support. Although many ICT systems are already active or currently being developed, the experiences described above have pointed out that there is a need for a doming ICT system that ensures the required overview and provides possibilities for systems integration. The objective of this paper is to design an ICT model that meets this need and makes calamity control in water flooding more effective and efficient. This will be done by executing a substantial analysis on all technical-, institutionaland process aspects that characterize a water calamity, identifying functional requirements of such a system, and incorporating these findings in a new covering systems design. SPM4910 – SEPAM Design Project (ICT) – Final Report 8

SPM4910 – SEPAM Design Project (ICT) – Final Report

9

2. Problem analysis
In the organization of calamity control, three topics stand central, namely communication, coordination and cooperation between the parties involved. The actor which stands central in this research is the ministry of BZK, who carries the end responsibility in calamity control. The ministry has recently performed a research on the status of calamity control preparation, and the conclusions are quite alarming. The main conclusion states that new organizational measures are necessary to protect the risk of floods in situations with overnormative drainage. These measures vary from a more clear structuring and demarcation of responsibilities to the improvement of several essential processes during calamity control (De organisatorische voorbereiding op overstromingen van Rijn en Maas, 2005). To give more insight into these conclusions, a three layer ICT model has been designed as exposed in Figure 1.

cooperation coordination

I (Information) I (Information)

communication C (Communication)
Figure 1 – The three layer ICT model (developed in cooperation with Prof. R. Wagenaar, 2006)

The “C” aspect in the figure indicates the communication part, which among others is supported by a technical component, filled in by the C2000 communication system (which will be discussed in chapter 4). The “I” is the abbreviation for information and consists of coordination of the information among involved parties and the lead up to cooperation between these parties by means of that information. This indicates that the information provision is a fundamental function of the communication level. In this context, coordination concerns the way the information is communicated, what the contents are, to whom it is directed and in which form it is communicated. Cooperation indicates how the information is processed and how this leads to certain decisions and actions of the different involved parties. Specifying the situation in case of a water calamity will provide the information necessary to fill in the designed three layer ICT model. Taking the conclusions of Bonfire and several evaluation reports into account, it is to be assumed that problems will arise during a water calamity. The three layer ICT model can indicate where gaps or niches exist and where problems and weaknesses occur in the merging of communication, coordination and cooperation. Accordingly, a broad and general problem definition has been determined, which will provide the fundament of the research that will be performed in this paper: “In case of a water calamity, how can the present problems with regard to communication, coordination and cooperation between the different parties involved be solved through the support of ICT?” In order to provide a sound answer to the above question a division into sub questions has been made. Subsequently, these sub questions has been ordered in sub researches. An overview of this is given in the table below.

SPM4910 – SEPAM Design Project (ICT) – Final Report

10

Table 1 - Overview of sub researches. Sub research Questions 1. Actor and Network -Which actors are involved? situation -What is the role of each actor? -What are the responsibilities of each actor? -How are the actors hierarchically structured? -Are there any calamity plans, scripts, or guidelines? 2. Current technical -What is the current technical status of the communication situation system? -Does the used technology create a bottleneck in the communication process? 3. Information situation -What information resources can be identified? -Which information is important to whom? -Which information streams can be identified? 4. Institutional situation -What institutional arrangements are valid concentrating on standards and protocols? -How are the institutional arrangements of different actors connected? -Are there any conflicts among the institutional levels? -Do the institutional arrangements provide the possibility of control? Answering these sub questions will help to specify the goal and focus of this report. To obtain a good foundation for the goal and focus of the analysis, the objectives of the problem owner, the ministry of BZK, should be identified. These objectives will therefore be treated next paragraph.

2.1 Objectives

To get insight in the objectives of the ministry of BZK, a goal oriented analysis has been performed. For this analysis, all objectives of the ministry have been identified and hierarchically structured. The analysis considers the objectives of the ministry of BZK during a water calamity. The complete results can be found in Appendix 1; the most relevant objectives will be discussed below. For this research the central objective that requires further analysis is repression of a calamity. To realize this objective, the objectives on the lowest level of the model in Appendix 1 need to be reached. To keep a clear overview, these bottom level objectives will be shortly discussed in accordance with the three layer ICT model topics. 2.1.1 Communication Good communication can be obtained by a high level of technical performance on the one hand, and maximum approachability of the relief workers on the other. Obviously, a thorough understanding of the underlying communication system (C2000) is needed for this. Features that need to be analyzed here are coverage, availability, number of calls, etc. 2.1.2 Coordination For coordinating the process of calamity control, it is of utmost importance that the different parties involved are able to reach and moreover understand each other. In other words, all information streams, -types, and -semantics need to be tuned towards each other. All parties involved will have to reach a consensus on how information is stored and mutually exchanged. Identification and further research of these actors will thus be essential. 2.1.3 Cooperation The last aspect of the ICT three-layer-model can only be achieved if the other two are well defined. To reach a good level of cooperation differences in cultures, norms and values of the

SPM4910 – SEPAM Design Project (ICT) – Final Report

11

different parties involved should be taken into account. Another, and maybe the most important requirement of all, is to get the whole system to take the same attitude and orientation in calamity control. All parties must really be willing to reach mutual agreements and work together in an effective and efficient way.

2.2 Paper structure
The research in this paper will elaborate on the three layer ICT model. The previous section has made clear what the further research areas within this model are. The research structure will thus be executed as follows. The paper will consist of two parts. Part I will concern the analysis on all sub researches as described in table 1. The objective of this part is to provide a complete overview of the different design aspects of the system to be developed. In chapter 3, an Actor and Network analysis will treat the involved actors, their interrelations, dependencies and responsibilities during a flood and will indicate what is known about information streams between the involved parties. The technical communication system, C2000, will undergo a more in depth analysis in chapter 4. Subsequently, In Chapter 5, the particular information streams and -allocation will be analysed, followed by the application of theory regarding the institutional situation (chapter 6). With the conclusions of these analyses, which are drawn up in the problem specification (chapter 7), an attempt will be made to identify all functional requirements of the ICT system to be designed. Finally a system design proposal will be worked out in chapter 8. In Part II, the requirements and design aspects identified in Part I will be translated into a system design. In chapter 9, the conditions to effectively and efficiently be develop the system will be identified through the process design. Then, the technical design will be drawn up in chapter 10, providing the structure, characteristics and specific features of the new ICT system. The institutional challenges will be taken into account in chapter 11, to create a broad social basis for the systems design. Lastly, an overview of conclusions and recommendations will be given in chapter 12.

SPM4910 – SEPAM Design Project (ICT) – Final Report

12

Part I – Gaining insights in current water calamity control

SPM4910 – SEPAM Design Project (ICT) – Final Report

13

3. Actor and Network Analysis
In this chapter, an actor analysis will be carried out, to make clear who the ministry of BZK should take into account. The objective of this analysis is to clarify how involved parties will act and what their interests are during a water calamity. In Appendix II.1, all actors relevant to a calamity scenario are listed. As could be expected, the number of actors is very high. Therefore, it is important to make a selection out of the actors that are critical for calamity relief, which will result in a focus on governmental organisations instead of socials and private organisations. The results of this selection can be found in Appendix II.2. In this chapter, a more in depth analysis will be done on these results.

3.1 Dedicated and non dedicated critical Actors
The actors who are most relevant for the analysis are the ones that are critical to the problem area. The reason for this is that these actors will play a central role during a calamity and can not be left out in the design process. In this section, it will be determined which actors play a crucial role in calamity control and should thus be taken into account by the problem owner, the ministry of BZK, in the development of a new ICT system. To achieve this, the attitudes, resources and degree of influence of these actors will need a further analysis. The dedicated and non-dedicated and critical actors identified in Appendix II.3 and II.4 are listed below: Government Institutions - Ministry of VWS - Provinces - District Water Boards - Municipalities Relief services Police Department First Aid Services Fire Department

It immediately catches the eye that these seven actors can be divided into two covering groups, namely Government Institutions on the one hand and Relief Services on the other. Government Institutions (Ministry of VWS, Provinces, District Water Boards and Municipalities) play a role in the policy and decision making process. This means that, among others, they will have to decide on responsibilities, ensure an effective and efficient information flow, and manage and coordinate teams in the field. One could say that the main objective of these bodies is managing coordination and cooperation. The Ministry of VWS is currently positioned as a non dedicated actor. This implicates that its policy is not actively aimed at calamity relief. However, its participation is critical for the ministry of BZK, for they form an important connection with other organizations that are involved in a calamity. Therefore, it is of importance that this actor is well informed and can be counted upon at all times. Relief Services (Police Department, First Aid Services and Fire Department) are the actors actually active and present at the location of the calamity; they will have to execute the policy drawn up by the Government Institutions. Obviously, communication within and between the Relief Services plays a central role. After having received information on the calamity, they will have to act and communicate with each other in order to do their job. It now becomes clear that the three layer ICT model, described in chapter 2, is directly related to the dedicated and critical actors. The division in roles described above makes clear that the governmental organisations execute tasks on the cooperation (decision

SPM4910 – SEPAM Design Project (ICT) – Final Report

14

making) and coordination level, the communication and coordination level are more important for relief services. But how do the different bodies cooperate, coordinate and communicate? And in what way should the ministry of BZK position itself to adequately deal with them? Although the particular roles are now mapped out, this question can still not easily be answered, but remains important to get a complete overview of the actor network. Therefore, the preceding analysis will be compared with the calamity plans that have been drawn up by these actors.

3.2 Calamity Plans

Calamity plans are hierarchically structured, according to the scope they cover. An overview of the different types of calamity plans can be found in Figure 2. The bottom layer represents the municipal- and district Calamity Plans; describing structures of organization, management, coordination, tasks and responsibilities. The second layer focuses on the Operational Plan, the communal databank for relief services with information on assistance, logistics, demography, risk inventory, procedures, etc. The third layer contains the Calamity Relief Plans, meant to prepare for specific risk objects and activities and coordination plans for treating specific incidents. The last layer is formed by cooperation agreements, aimed at realizing an effective coordination and execution of calamity relief. In the sections below, these layers will be further analyzed.

Other Cooperation Arrangements

Calamity Relief Plan

Operational Plan

Municipal - and District Calamity Plans

Figure 2 – House of plans existing Rampenbestrijding, 2002).

in the Netherlands (Handboek Voorbereiding

3.2.1 Municipal- and District Calamity Plans The Dutch law obligates all municipalities to draw up a calamity plan every four years. As mentioned above, a calamity plan contains an overview of the risks that are present within a municipality. This indicates that these calamity plans should also be applied during a water calamity. However, as municipalities often lack sufficient knowledge about waterworks, close cooperation is needed with the local water district board(s). In the Netherlands, 27 district water boards (Waterschappen) have been established. These bodies are decentralised governments, carrying the responsibility for all public works departments within the country. Every district water board has drawn up its own District Calamity Plan. These plans describe the responsibilities and information flows during a water calamity. In this section, a broad outline will be given of these District Calamity Plans

SPM4910 – SEPAM Design Project (ICT) – Final Report

15

(Calamity Plans used for research: Waterschap Zuiderzeeland, 2005; Waterschap Zeeuwse Eilanden, 2004 and Waterschap Groot Salland, 2002). It is important that a water board’s District Calamity Plan is geared to calamity plans of other organizations, including those of municipalities and provinces. To achieve this, several arrangements have been drawn up in the Dutch legislation (Waterstaatswet, 1900). Responsibilities The overall responsibility for coordination during a calamity is assigned to the Dijkgraaf, as fixed in Article 96 of the law for Water Boards. He also holds the end responsibility. However, in case of an escalation, certain responsibilities can be assigned to the mayor. If this occurs, the Calamity Law comes into force. It is to be expected that several communities or even provinces will be involved in larger calamities. The responsibilities are distributed depending on the magnitude of the calamity. • The Dijkgraaf has the command over the Communal Policy Team. Furthermore, he will determine the informing policy, being responsible for the contact with the communities and province(s). He may change the constitution of this team permanently or ad-hoc. The centre of command will be located in a specially assigned Calamity Room In case of the enforcement of the Calamity Law, the mayor will instruct and coordinate the Calamity Policy Team and the Management Team. If several communities are affected, all mayors will assign a coordinating mayor. The Royal Commissioner may bring out advice. The province has a coordinating task. The Royal Commissioner is supported by the province’s calamity staff and the Provincial Coordination Centre (PCC). He may request the Dijkgraaf to adjourn to province staff meetings. A community or province can request for military aid. This may only occur after Royal Consent. In case of involvement of more than one province, the Minister of the Interior will be assigned the coordinating role, supported by the National Coordination Centre (NCC).

• • •

Regardless of a calamity being qualified under the Water Board Law or the Calamity Law, the district water board always maintains the power to act. The Dijkgraaf is strongly advised to only do this if consultation with other bodies is impossible. Apart from that, he will be obliged to justify these self made decisions afterwards. Central in the decision making process stands an effective and an efficient cooperation between the bodies involved. In case of a dispute, the mayor in command has the decisive vote. The scheme of the calamity organization has been drawn up in the form of a three layer structure. Every layer involves a team with specific tasks, shortly treated below: • Calamity Policy Team This team has the responsibility for internal and external coordination of all Water District Board actions, as well as the communication to the media. Furthermore, the team should document all data. The team is constituted of the Dijkgraaf (Chairman), the Calamity Coordinator, a secretary, a secretary assistant, the heads of sectors, an instructor, and an IT expert. The IT Expert is responsible for all information and communication (ICT) flows. He will advise on telecommunication connections and ensure the continuity of ICT support. • Operational Team The involved head of sector is the Operational Team Leader (LOT). All activities executed by the Operational Team are coordinated by the Calamity Policy Team. The LOT manages and guards this process. He is also responsible for bringing out situational reports to the Calamity Policy Team. Other team members are: the involved department chiefs, the

SPM4910 – SEPAM Design Project (ICT) – Final Report

16

involved functionary of Supervision and Maintenance, an Instructor, an IT expert, and possibly a secretary assistant. The team instructs all Action Teams, steering and coordinating source- and effect control. Another task of this team is bringing out technical advice to Action Teams and the Calamity Policy Team.

SPM4910 – SEPAM Design Project (ICT) – Final Report

17

Action Team An Action Team consists of one or more district supervisors. Often there are several Action Teams established during a large scale calamity. In case of events within one sector, the functionary of Supervision and Maintenance will be the coordinator of the action team (CAT). If more sectors are involved, a CAT will be assigned by a supervising echelon. The CAT and his team are charged with the source- and effect control, as determined by the Operational Team and/or Calamity Policy Team. Furthermore the CAT is responsible for the communication with relief services. Finally, the CAT will report the situation to the Operational Team and/or Calamity Policy Team.

It is essential that every body sticks to its own tasks during a calamity. If this is not the case, some activities won’t be fulfilled and others will be done twice. A number of conditions should be met to guarantee this: • • • • There should be a transparent structure of the calamity organisation and a clear fencing of tasks An optimal cooperation and coordination between the different bodies of the calamity organisation An optimal cooperation and coordination between the calamity organisation and all external organisations involved in fighting the calamity An optimal supply of information for everyone affected by the calamity and/or the calamity relief.

3.2.2 Operational Plans The existence of several Municipal- and District Calamity Plans and the desired combination with the calamity relief plans, gives rise to the need of a coordinating databank. The databank should be linking these plans, or put them together, and giving aid in a smooth cooperation between them. This is established in an Operational Plan (OP), which actually concerns a covering of the earlier mentioned plans. The OP is thus meant to offer support and can bring aid in making quick decisions. The ministry of BZK formulated guidelines in order to standardise the form of all these local OPs. Those guidelines resulted in two different manuals. The first manual is the Leidraad Maatramp (LMR) which concentrates on the regional preparations considering calamity control (LMR, 2001). The LMR provides an unambiguous and broad accepted systematic method for indicating the dimension and effects of the most important calamities which can occur within a region and the expected corresponding need for relief or aid in that case. The most important calamities are elaborated and hence include the calamity of a possible flood.
LMR LOP Relief / Support Processes

Source / Cause

Effect

Need for Relief / Aid

Need for Application

End / Result

Figure 3 – The content of the two manuals provided by the Ministry of BZK (LOP 2001) ,

The second manual, the Leidraad Operationele Prestaties (LOP) is an extension of the LMR, as shown in Figure 3, which concentrates more on the operational part of calamity control. On the basis of the LOP, the region can convert the need for relief into the desired capacity or need for application within a certain period of time and which ultimately results in the deployment of the actual relief and support processes. The need and actual capacity considering the calamity region are expressed in numbers and divided into five groups: fire department, police, medical assistance, local government and members of multidisciplinary teams. Each group contains executive and coordinating functions on both operational and SPM4910 – SEPAM Design Project (ICT) – Final Report 18

management level. By comparing the need and actual capacity within a region, or with the support of nearby regions, the manual provides a clear view on the potential bottlenecks and deficiencies. Because of the detailed and operational profundity the LOP primarily focuses on operational planning and imaging as well as training the managers of the different actors involved in a calamity. With both manuals, mainly technical exercises can be executed. Information concerning the local and regional situation can be coupled to the information and methods provided by the LMR and LOP documents. Based on the outcomes of the mentioned exercises it is possible to decide on the desired policy and measure the performance of the current policy. As mentioned in the LOP (Save and Van Dijke, 2001) the manual may not be seen as an organisational plan or script and neither can provide an instruction package for calamity relief. Furthermore, the LOP does not intend to appoint responsibilities. Although these responsibilities should be clear and the existence of scripts and organisational plan is a fact. The LOP solely provides suggestions for operational targets which should be achieved in case of a calamity. As for the other seventeen calamities defined in the LMR, in case of a water calamity the need for relief or aid is specified in detail. Considering this need, the LMR distinguishes five different sizes of calamities, which are numbered by Latin numbers I up to V. As illustrated in Figure 4 the size of each calamity can vary. The numbers denote the impact of the calamity and therefore indicate the importance of preparation for the different levels. With regard to the mentioned preparation, it is of mayor concern that the expected need for relief or aid is made concrete, in order to determine the appeal to the relief services in case of a flood.

Indication of the calamity size

Car accident (# car’s) Forrest fire (# m2) Flood (# households)

Calamity type X (# concerned)

Size of the need for relief or aid / process

Fire department Police Medical Local government (not operational) Multidisciplinairy

Figure 4 – Operational needs considering a certain size of calamity (LOP 2001) ,

The need for relief or aid is divided into five main processes, which are also illustrated in Figure 4. These processes distinguish four monodisciplinary, namely the fire department, police, medical aid and remaining (non-operational) services provided by the local

SPM4910 – SEPAM Design Project (ICT) – Final Report

19

government and a multidisciplinary process. Each calamity requires a different mix of these processes, again five dimensions are distinguished. As can be concluded from Figure 4, the most important process during a flood is the multidisciplinary process. The process among others holds the earlier mentioned ‘municipaland district calamity plans’ and combines these plans with the ‘calamity relief plans’ adopted by the relief services (Fire department, police department and first aid services). The combination of these plans implies that the level and performance of cooperation among all concerned actors is highly important. Accordingly, the importance of cooperation, coordination and communication during a flood can be deduced from the LOP. Actually, comparison with other calamities shows that these three factors are more important during a flood than any other calamity described in the LMR. With the importance of a fluent connection or combination of the ‘municipal- and district calamity plans’ and ‘calamity relief plans’ clear, an extensive insight considering the calamity relief plan is desired. 3.2.3 Calamity Relief Plans The Municipal and District Calamity Plans are general plans which guide decisions, while a Calamity Relief Plan more accurately describes the responsibilities of the different relief services during a calamity. There is no formal national Calamity Relief Plan. However, several regions within the Netherlands have drawn up models of Calamity Relief Plans based on the recommendations provided by the LOP. Therefore, most of these models have been subjected to a more in depth analysis, as to clarify and map out the operational, and to lesser extend organisational, needs of the relief services during a calamity. The result of such a standard map is provided by the LMR and an extensive and concrete overview is reproduced in Appendix III. Besides these needs, some general requirements which all relief services should suffice are formulated. Assumptions considering these important requirements are given by the LOP (LOP, 2001) and hold that following aspects, concentrating on policy and coordination, are accurately taken into account: Adequate level of competence Authorisation of competence Availability contacts and information third parties Crucial decision-making Prevent function overlap

With the operational and coordination requirements formulated a more specific contemplate of the tasks and roles considering the different relief services (Fire department, police and medical aid) is a logical next step. Afterwards it will be possible to draw conclusions on the organisation and arrangements considering the repression preparation. Fire Department The fire department’s primary task is to contribute to the public security. Executing this task results in preparation, prevention, suppression and caring after the calamity. In reality the operational performance by the fire department mainly concentrates on suppression. The suppression activity can be divided into several phases, which among others hold the reporting of an incident followed by an alarm and the physical turn out. Subsequently operational tasks and processes are executed. When the situation is under control the next phase, the after caring, will follow. In contrast with other operational services the application of the fire department rarely depends on the other relief services.

SPM4910 – SEPAM Design Project (ICT) – Final Report

20

In case of large scale calamities the level of scale, local, regional or interregional, the possibility to scale-up is one of the options. Scaling-up determines the way the firemen are divided over the different teams considering a particular period. Because of this temporary redistribution the aspect of command and control becomes highly important. Concentrating on this aspect the importance of attendance times and organisational structures like Coordination Team Place (area), Incident (CTPI), Commander Calamity Terrain (Commandant RampTerrein – CORT), Regional Operational Team (ROT) and policy team (BeleidsTeam – BT) local government becomes clear. After all the executing of suppression tasks can only take place when these are allocated to a certain person. The most important processes, executed by the fire department, in case of a flood calamity are concentrating on the evacuation and saving of humans and animals apart from that the fire department should also provide technical support. Police Department Concentrating on relief during a calamity the department of police take a leading or direct role in certain parts of processes carried out by the relief services. These processes and their priority are illustrated in Table 2 below.
Table 2 – Processes and their priority, executed by the police department (LOP, 2001) Priority Process(part) 1 Set off / Screen 2 Evacuate 3 Organise traffic 4 Guiding 5 Maintain (public) order 6 Investigation 7 Identify and stow decedents 8 Notify the population 9 Support and caring (organising first support) 10 Registration (data of victims or witnesses)

The process of evacuating is a shared process and therefore not explicitly allocated to the police department. With a flood the process of evacuation will be one of the most important processes executed. The notion of several relief services involved in this process should be taken along in possible conclusions. Concerning the processes, three main types (LOP, 2001) of support can be determined. 1. Unstructured spontaneous support (individual policemen supporting initiative) 2. Interregional assistance (a limited number of loose surveillance units) 3. Structured assistance (large units under the direction of one commander) on own

All three assistance types will be available or occur during a flood, although the most important assistance concerns number three: structured assistance. Putting together such a large unit will take some time, until that moment the application of the police forces quantity will remain limited. In order to determine the maximum operational performance of the police department all available capacity considering the three assistance types is added up. The availability and applicability strongly depends on quantitative possibilities of the regional police department and geographical situation of the calamity as well as the moment. In case of a calamity a crisis organisation besides the regular police organisation will be set up. With it capacity has to remain available to the regular police process besides the crisis organisation will also be allocated capacity concentrating on processes of less priority. The crisis organisation usually is set up a half-hour after it is determined de relief services are dealing with a calamity, the crisis organisation from than on will have the lead and the responsibility regarding further coordination.

SPM4910 – SEPAM Design Project (ICT) – Final Report

21

Medical (first) Aid Services As seen with the other relief services the medical services (Geneeskundige Hulpverlening bij Ongevallen en Rampen - GHOR) are involved in several processes. Like stated in an earlier stage the focus will be on the suppression phase. The main processes of responsibility contain physical and psychosocial medical aid and preventive public healthcare. During a flood namely the first, concentrating on physical medical aid, will be important or at least most relevant. Besides the GHOR also contributes to the multidisciplinary processes which among others concern evacuation, care and first necessities of indigent civilians.

SPM4910 – SEPAM Design Project (ICT) – Final Report

22

Working streams determined by the GHOR are distinguished by two criteria (LOP, 2001) concerning the process: • Time-critical, which indicates or a process should (completely or partly) be executed within a certain period. Concerning non-time-critical processes only the bare workload needs to be taken into account. For time-critical processes this workload should also be measured by the time requirements. Whether specific expertise is needed or a ‘own’ kind of relief workers

In essence time is determinative concerning calamity control and concentrating on the GHOR several important time aspects (LOP, 2001) can be distinguished: • • • • Clock time: the moment of a calamity is equalised with the appearance of injuries Treating time: amount of work and workload Norm time, time requirements, time window: various kinds of aid become less useful when not provided to a victim on time. In case of the GHOR, as mentioned above, the aid for victims is highly time-critical. Attendance time, application time, substitution: relief workers ought to make one’s way to the place of the calamity and should be released from other duties and activities.

The reason for discussing these times, within the calamity relief plan, shows the importance of these times and besides makes clear that designing a structured plan in the medical case is complex. The complexity lies in the fact that the GHOR processes are highly diverse and hard to predict, the different injuries and treating times continuously change the situation. The constant changes make it hard to formulate a preventive plan. Because of this difficult formulation in advance the GHOR processes require intensive information and accordingly unambiguous information streams. The actual information during a flood is obviously used to support processes of a somatic basis. The task of the GHOR is the provision of care and aid considering the injured persons. This is actually a scale-up compared with the normal situation of the first aid department (Spoedeisende Medische Hulpverlening - SMH). The authorities combined in the GHOR among others comprise the ambulance services, the ambulance switchboard (Centrale Post Ambulancevervoer - CPA), medical services (Geneeskundige Combinatie - GNK-C), family doctors, hospitals and pharmacies. Another complexity is formed by the public and private nature of these different authorities. Problems caused by this division concern the allocation of tasks and responsibilities. In order to function optimally, the GHOR obviously holds close contact with the other relief services.

3.3 Responsibilities and hierarchy
With all processes of the relief services described, the various tasks and responsibilities are becoming clear. The organisational structure of all different governmental authorities and the more operational relief services, as mentioned before, is considerably complex. An illustration of the established responsibilities provides a more vivid overview (Appendix V) although a real hierarchy remains indistinct. The problem with this distinction is that the importance of certain information streams is difficult to determine. With this difficulty recognised a more extensive analysis concentrating on the information resources and streams is desired. This analysis will therefore indicate the problems or potential opportunities with regards to the information provision during a flood calamity.

SPM4910 – SEPAM Design Project (ICT) – Final Report

23

4. Technical analysis: the C2000 system
Before starting to design a new system, it’s good to know which systems already exist in this field. The technical analysis is carried out for two reasons: • Identifying the obstacles in the current technical system (in order to avoid or cope with them in the new technical design) • Identifying aspects of the current technical system that could be integrated within the new technical design. One of the most relevant technical systems to get a closer look on is C2000. The House of Commons decided in 1996 to construct the C2000 communication system by request of the Ministry of BZK (De Projectdirectie C2000, 1998). The C2000 network, in full “Communication 2000”, connects relief services like the police, fire department and medical aid services as well as the military police. The main objective was to fully replace all relief services’ existing communication networks, so it would be used with maximum efficiency. In the upcoming years, C2000 will perform as the system par excellence for communication purposes between the Dutch emergency services. In order to understand the functioning of the system, this chapter will elaborate on the technical background of the C2000 system, starting with the way in which it makes communication possible.

4.1 Five ways to communicate
The fundamental idea of the C2000 system is that all communication is covered through a central communication point. There are 25 central emergency control rooms that cover up the “Geintegreerde Meldkamer Systeem” (GMS). Each emergency room covers a safety region in the Netherlands. In these emergency rooms representatives of each relief service operate together. Like in a hub-and-spoke network all communication goes through these central headquarters (De Projectdirectie C2000, 2004). C2000 supports, however, a wide variety of types of communication. The five different types of communication possibilities are listed below. The numbers in Figure 5 correspond with the listed descriptions. 1. Direct mode operation The DMO enables users to communicate directly with each other through mobile devices without using the C2000 network. 2. Air Interface Communication between mobile devices can also take place by using masts or mobile stations which communicate with each other through electromagnetic waves. The used standard is TETRA. Besides the use of mobile devices, all used emergency vehicles have built-in C2000 equipment. Air communication is possible up to a height of 1200 meters (Deloitte, 2005). 3. Inter System Interface Different TETRA networks can be connected to each other through the Inter System Interface. This is important for international communication. 4. Gateways C2000 can also be connected to external networks like the telephone network and data networks. The gateways of C2000 are responsible for this feature. 5. Peripheral Equipment Interface The Peripheral Equipment Interface makes communication between a mobile station and a PC (laptop) possible (Min BZK, 2006b).

SPM4910 – SEPAM Design Project (ICT) – Final Report

24

Figure 5 - A sketch on the concept of C2000 (Min BZK, 2006b).

4.1.1 TETRA To enable international communication, a European communication standard is necessary. The European Telecommunications Standards Institute (ETSI) supported to develop the Terrestrial Trunk Radio (TETRA) standard, which is now the official standard for communication between emergency services in Europe. The majority of European countries are using this standard (Min BZK, 2006a). Some interesting features of TETRA are: • • • • By making use of Time Division Multiple Access technology with four user channels on one radio carrier, TETRA uses the frequency spectrum in a very efficient way. National and international roaming is supported, so communication with adjoining countries like Belgium and Germany is possible. TETRA supports point-to-point and point-to-multipoint communication. TETRA is an open multi-vendor standard. This means that the equipment that is needed can be produced by any private party (ETSI, 2006). Motorola is the producer of the Dutch equipment (Regionale brandweer Amsterdam eo, 2004:6).

The digital character of C2000 supports the transmission of voice and data. Another advantage of digital transmission is a better protection against eavesdropping and the possibility of encrypting the transmitted data. The construction of the C2000 network is outsourced to TetraNed. Different parties are participating in TetraNed including Getronics, KPN Telecom and Motorola. Together this consortium is responsible for the construction of the network and the equipment. The network consists of 400 communication masts and all the necessary exchanges (Min BZK, 2004b). 4.1.2 Equipment The C2000 equipment is produced by Motorola. During the fall of 2004 the first TETRA terminals were bought, which go under the name of Motorola MTP700. This device enables

SPM4910 – SEPAM Design Project (ICT) – Final Report

25

voice communication and, into a lesser extent, data communication (Motorola, 2001). In the mean time a new model is launched by Motorola, which proves to be a great success in the UK. This device will be available for C2000 soon and Motorola expects it to be used in the Netherlands on a short term (Motorola, 2004a). One of the advantages of this new model is an improved colour display. This makes it possible to exchange incident views, digital maps and specialized graphics such as Force logos. Another advantage is the built-in GPS receiver, which makes it possible for the emergency rooms to plot the location of the user (Motorola, 2004b). 4.1.3 C2000 from a user perspective As mentioned, the C2000 network supports voice and data traffic between the different emergency services. The extent in which data traffic can be used depends, however, on the used equipment. Next to this there is also the possibility of sending and receiving short text messages. When a user turns on his device, it automatically logs in into the central system. In continuation the operator in the emergency room divides the users in groups based on the situation and authority. These groups can contain emergency workers from different emergency services. In some cases emergency workers receive less information compared to the old situation. While using the C2000 system, emergency workers do only receive messages that are relevant for their own situation, instead of receiving messages that are relevant to the whole discipline. The relevance of information to a certain user group is determined by the controllers in the emergency rooms. However, by the coupling of C2000 to the GMS operators from different disciplines can share information with each other, which can lead to more information generation (Min BZK, 2004a). 4.1.4 Project progress Many resources concentrating on the C2000 system show a wide variety of information concerning the status of the C2000 system. The 7th progression report on the C2000 project performed by Deloitte (2005) states that at the end of 2005 21 out of the 23 safety regions in the Netherlands were operational. According to the planning that was made in June 2005, the last two regions should be using C2000 by the end of November. It could therefore be assumed that C2000 is working properly at this moment. The quality of the technical system is, however, an issue on which exists less consensus. An example that illustrates the variety in information providence of different parties is the already mentioned Bonfire case. Bonfire was crisis control exercise that took place mainly in the Amsterdam ArenA. The official progression report on the C2000 project mentions the success of C2000 during this exercise: “During events like the visit of the American president Bush to the cemetery Margraten, SAIL and Bonfire C2000 is put into action successfully” (Deloitte, 2005:31). Different articles from the Dutch newspapers in contrary point out, that according to them, C2000 failed irrevocable: “The new communication system, C2000, the system every emergency service should be connected to at the end of this year, seemed to be the perpetrator in Amsterdam. The technology failed in Amsterdam during the Bonfire exercise…” (NRC, 2005a). The appointed evaluation team of Bonfire indicates that during the exercise “The fire department and ambulance services could only make partially use of the C2000 system as it had to deal with network interruptions” (Projectteam Borging Leerervaringen Bonfire, 2006). It seems that the value of the quality level of the C2000 system depends on the stakeholder or principal, which is making a statement about the functioning. However, deliberated conclusions about eventual prejudgments and truthfulness of these reports and articles can not be claimed as fundamental due only by a literature and resources study. An analysis into the strengths, weaknesses, opportunities and threats of the C2000 system is in this context a better alternative. A SWOT analysis brings together the internal and external

SPM4910 – SEPAM Design Project (ICT) – Final Report

26

environmental scanning to identify the projects internal strengths and weaknesses and external opportunities and threats. In this way a deliberate overview can be created according to the current status of the C2000 system.

4.2 SWOT analysis
Literature research provided information to execute the SWOT analysis. Appendix VI gives an impression on the results of this analysis. The SWOT analysis shows a certain amount of bottlenecks, which the project team concerning C2000 faces. However, as one of the threats indicates the point of no return has passed a long time ago. This proposes a large reduction in the opportunities to solve certain bottlenecks. The path dependency of the implemented C2000 system demarcates the problem solving concerning technical issues. Adjustments and innovations can only be performed within the framework of the current C2000 system. The dependency on this unstable system that still suffers from a variety of problems can be called critical, as the old systems are being dismantled. Practice will have to show how C2000 will perform in action and in to what extend the C2000 project team manages to attain that the system becomes a stable and robust communication infrastructure.

SPM4910 – SEPAM Design Project (ICT) – Final Report

27

5. Information streams and resources
During a water calamity the availability of information is crucial. In practice, it appears to be difficult to obtain all relevant information. Moreover, it is important to have the right information at the right place. This implicates that all actors involved in calamity control are aware of their own information needs, but also of the information needs of others. In other words, it is important that during the exchange of information it is clear for who the information is meant, what is going to happen with the information and if any actions are expected as a result of this information. In this chapter, the information streams that arise between involved actors in a flood situation are thoroughly discussed. This is interesting to consider, because, as said in previous chapters, within an calamity situation, especially the coordination and cooperation between actors does not always develop as it should. There are quite a number of issues to consider when making an overview of all the different information flows during a flood. To begin with, two different kinds of calamities can be discerned: the so called flashcalamity, which is an immediate event, and the growth-calamity, on which on beforehand there is some degree of expectation that it will occur (LMR, 2001). In the case of a water calamity this distinction can be made as well. In the first case there will be preventive evacuation of people and cattle. In the second, worse case, a flood happens before an evacuation can take place. Medical assistance will be of greater importance, and accessibility will be a key issue. In this analysis the different steps in a growth flood situation will be discussed, concentrating on which actors are involved, the roles they play, and how the information exchange takes place within these parties. The focus will be on the operational level of communication and coordination, which will be complementary to the responsibilities of the different actors discussed in previous chapters. In the past few years, there have been a number of incentives to support the decisionmaking process with floods. Software programs, that include monitoring- and warning systems, have been fully implemented or are currently being developed and tested. In the next sections these programs will be treated, answering questions on where, when, and by whom they are used, and with special attention to the support they can bring.

5.1 Processes during a water calamity
To act efficiently during an emergency situation, good information exchange is essential. In the first place, information can be structured according to the main processes that occur during a water calamity. These processes are listed below (Quickscan informatiemodellen, 2004). An important remark here is that the processes do not necessarily follow up, but can occur synchronously as well. 1. 2. 3. 4. 5. Monitoring Scale up Evacuate Flood Take care of damage

A further analysis on the different processes can be found in the Appendix VII, including the information entities that apply for these processes. Especially during the preparation phase and the evacuation phase, the degree of multidisciplinary cooperation is rather high. The picture below gives an overview of the different actors and teams that play a role, with their

SPM4910 – SEPAM Design Project (ICT) – Final Report

28

interaction. To keep it simple, there are two ways of interaction. One is the hierarchical link, through which orders are being given. The other is the information relation, which can be any interaction where information is being shared or requested. Figure 6 provides a sketch on this situation.

Orders Information
Royal commissioner/ Mayor

Mayors Consult Regional Actin Center Regional Policy Team

Regional / national Coordination Center

Maps, Geo-info, Resources
Management systems (FLIWAS, VIKING, IRIS)

Municipal Policy Team Municipal Action Center

Calamity Plans

GMS

Police Dept.
Regional Operational Teams Action Teams Commando Calamity Area

Fire Dept. Situation Reports

Tacit Knowledge

GHOR

Figure 6 - Overview strategic direction (Based on: Overmars, 2004).

Two important relations involve the ones connecting the Regional Operational Teams (ROT) with, on the one hand, the Action Teams and Commando Calamity Area, and, on the other hand, with the Regional and Municipal Policy Teams. Most information flows between these actors, before the information is being made “operational”, indicating that relief workers at the lowest levels can operate with it. Problems from lower levels are being solved on a higher level, and policy decisions from a higher level are put into actions on a lower level. The information entities on which the different levels depend can in a generic way be described as follows:  merely tacit knowledge in combination with orders on a lower level  situation reports, based on gathered information a level higher  calamity plans (on the policy level), regulations form the basis of decisions There is quite some redundancy in the situation reports, which are provided in a decentralized fashion by different operational teams. Use of computer programs in

SPM4910 – SEPAM Design Project (ICT) – Final Report

29

supporting decisions does occur, but is not exploited completely by every actor. As can be seen, any actor can use the systems, only an internet connection is needed. The communication flows during the scaling up and the evacuation processes, are described below1. The centre of operations is located at the Regional Operational Teams (ROT). The ROT is the link between the actually operational teams, and the decision-making institutions. The ROT exists of delegations of several relief services, and people from the municipality and government. They collect information from the regional and national coordination centre. Furthermore, they receive information from the GMS and Commando Calamity Area, and possibly from the Regional Policy Team. The different relief organizations are involved as well, along with delegates from the municipality. After the collection and the processing of data by the different actors into situation reports and discussion points, they come together in a meeting, in which the information is being discussed. Upon this meeting requests/advice or orders to respectively the municipality/Regional Policy Team and the Action Teams will follow. The frequency of these meetings intensifies when scaling up. This process of collecting and receiving data, conceptualizing the situation, making decisions, requesting permission, giving advice and orders, all happens constantly, to deal with the rapidly changing information. The way of decision-making and collecting and structuring information happens mainly through phone or email, and for a limited amount of people. When stored in a database, all users with authorization can access the information and use it. This creates less redundancy and equally shared knowledge.

ROT – Information Gathering
Consultation by phone or email Support by computer programs (FLIWAS Light , VIKING) RPT, Municipality, Action Teams, RCC, NCC, GMS

Decisions Answers Information

Questions Remarks Information

RPT/ Municipality

Requests Advice

ROT Meeting

Orders Information

Action Teams

Figure 7 - Information flows ROT (Based on: Overmars, 2004).

Although the specific content of information flows will differ during a water calamity, some general flows can be identified. Figure 7 provides a broad overview of these flows. An Action Team, for example, operates on the basis of the orders and responsibilities it receives. When there is a question, or permission needed from a higher level, a request is sent to the ROT, which will probably deal with it in their following meeting. The same holds for information, remarks or decisions. Information sometimes is dealt with separately, but this totally depends on the kind of information, priority or importance. The process of decision-making can come out very slow, because information travels at the handling speed of different
1

Based on: Observations during the exercise ‘Helga’ on water calamities in ‘t Harde. May 16th 2006.

SPM4910 – SEPAM Design Project (ICT) – Final Report

30

actors. Telephone and email are the main modes of transporting information. On the other hand, because of the human intervention, there is a natural selection of useful information or concerning cases.

SPM4910 – SEPAM Design Project (ICT) – Final Report

31

5.2 Main focus: the evacuation process
In the following analysis, the focus will be on the evacuation process, as this process contains the highest multidisciplinary level. Thus, the most complex form of information streams can be expected here. Therefore, this paragraph will deal with the different stages that take place during the evacuation process. The most important actors involved in the operational level, are the fire department, police department, the medical services, and the municipalities. The management and coordination of the operational teams takes place through the following teams, as explained before in the actor analysis (chapter 3): Calamity Policy Team, Operational Teams and the Action Team(s). An important note is that the operational responsibility of evacuation lies in hands of the police department. Although the final responsibility is still in hands of the mayor, the most important operational processes, such as escort traffic and evacuate people, fall under the responsibility of the police (Politiewet 1993). When dealing with an evacuation, there are five main processes, in chronological order: 1. 2. 3. 4. 5. Analyzing relevant information (nature, dimension, area, etc.) Draw up evacuation plan Getting personnel and resources ready Use of personnel and resources Return people to their homes

One of the most critical success factors has to do with the informing of people, they will only be willing to leave their place if they assume the water calamity imposes a real threat. Moreover, informing the people well will prevent chaos. The information has to be complete, and given at the same time through different types of media. In case of a regional calamity, like most water calamities, the Royal Commissioner has to give his consent. The operational preparation is done by the coordinator Conflict- and Crisis management of the region, and is based on calamity plans and other literature relevant for the specific calamity. The criteria are set by the police department, and have to be in conformance with the ‘Leidraad Operationele Prestaties’ (Algemeen Doorlichtingsinstrument, 2003). The core of the operational staff of an evacuation exists of General Commander (leader), Chief Operation, Chief Support, and Chief Information (Handboek Rampenbestrijding, 2003). In Appendix VIII the five main processes of evacuation are elaborated in detail. Below, conclusions resulting from the appendix (VIII) of every process will be shortly discussed. 5.2.1 Analyzing relevant information This first activity aims at a better knowledge of the situation, trying to collect as much information as possible in order to make justified decisions. Decisions are made with regard to informing and advising the public, the dimension of the evacuation area, judicial arrangements, the amount and location of involved people, cattle, and buildings/objects, priorities, and the responsibilities. Conclusions of activity ‘Analyze relevant information’ (see Appendix VIII) • This part of the evacuation still regards the planning and preparation phase, where plans are being made, and discussed between the relief services. There is a large amount of information being exchanged between the District Water Board and the relief services. It is not always clear where information regarding population characteristics and location can be requested. • After this process it should be clear where the different responsibilities and priorities are, and there should be enough information to draw an evacuation plan. 32

SPM4910 – SEPAM Design Project (ICT) – Final Report

New supporting ICT-initiatives as FLIWAS and Viking can be of great help in this process. Explanation of these initiatives is in another section of this chapter (Further analysis on this subject is necessary and will be discussed later on).

5.2.2 Draw up evacuation plan In this part of the process the actual evacuation plan is being developed and actualized for the current situation. It consists of addressing practical issues regarding the information and instruction to the public, gathering data, and transforming this into an evaluation plan. Important is the connection between probable demand for evacuation measures and the available resources. Conclusions of activity ‘Draw up evacuation plan’ (see Appendix VIII) • Usually when flood situations take place within a relatively small area, the evacuation plan of the nearest municipality plan can be applied. However, when more municipalities are involved, the different evacuation plans need to be harmonized and updated. As not every flood is the same, there should be some fine-tuning according to the flood characteristics and consequences. Evacuation plans, and data regarding evacuation, should be easily comparable, so a format is necessary. • An important aspect regards the time schemes, describing different evacuation steps, with each step specific informational aspects. Different kinds of information are needed at different moments during the process. It is not desirable to be confronted with all information at all times, for this could cause an information overflow which causes delays and bad decisions. It is much more efficient when the information arrives only at times when there is a need for that information. • When designing a format for evacuation plans, and especially the informational part, it should be translatable to digital systems. • It is not clear where possible resources as trucks, ships, materials etc. can be obtained, and how much of it is available. A list should be made per municipality, and in emergency situations, easily connectable. This list should comply with certain standards. • There are possibilities to make evacuation plans using computer programs, hence directly connecting flood characteristics with the local geographic and demographic data. It also has the flexibility to change it minute by minute and is available for anyone connected with the internet. More about this in a later section. 5.2.3 Getting Personnel and Resources ready Personnel and resources are being prepared. People and organizations are called that will or could be of assistance (e.g. church, military). Conclusions of activity ‘Getting Personnel and Resources Ready’ (see Appendix VIII) • A positive aspect of this activity is that it, such as alarming third parties and getting people into position, clearly demarcates and appoints certain actors. • Something that could hamper the progress of this activity is the absence of up-to-date information regarding contact details of personnel and organizations. If there is no clear list with data about required persons, organizations, companies, delays can occur. • There should be one database with all important contact details needed during a calamity. 5.2.4 Use of Personnel and Resources This activity consists in essence three main processes, which are the instruction of personnel, the mobilizing of personnel and resources, and the registration of persons, animals and objects. Conclusions for activity ‘Use of personnel and resources’ (see Appendix VIII)

SPM4910 – SEPAM Design Project (ICT) – Final Report

33

Unclear division of responsibilities; Police involvement is minimal here, and processes that are clearly part of the Police Department responsibility (such as traffic control and order maintenance), are stated under the responsibility of the Municipality and without any interaction with the Police Department. It seems that the mobilization and instruction of personnel happens in a considerably static way. Like plans, scripts for people and instructions can change over time; this should be corresponded to all personnel in an efficient way.

5.2.5 Return people to their homes On this process will not be focussed. This process will be considered as out of the scope of this project.

5.3 Other important processes
Before, during and after the evacuation, there are several other important processes, that have to make sure that it all happens smoothly. These processes are listed below in Table 3.
Table 3 – Responsibilities of main operational actors.

Source and effect combating (Fire Dept.) - Rescue and Technical Support - Monitor and Measure - Warn Public - Make accessible and clean Legal order and traffic (Police Dept.) - Clear and Evacuate - Fence and Protect areas - Traffic Management - Maintain legal order - Identification Victims - Guiding

Medical Services (GHOR) Medical treatment - Somatic - Psychological

Public Care (Municipality) - Inform and Instruct - Receive and take care - Registration (victims/damage) - Environmental care - Follow up care

It should be noted that not one calamity is the same, and unexpected events can occur. There are still activities and moments which are not described in any book or script, and could require multidisciplinary cooperation.

5.4 Current developments
Currently, projects focusing on water management are running in the Netherlands, but also on a larger scale as international projects (Germany). The most comprehensive project, FLIWAS will be shortly discussed in this section; in Appendix IX a more elaborate description is given. 5.4.1 FLIWAS Swift and adequate information exchange at (impending) flood events: that is what the development of FLIWAS is all about. The FLood Information and WArning System is a system that integrates (parts of) existing (information) systems, such as monitor and forecast models, geo-information, high water level scripts, water risk maps, and calamity plans. FLIWAS is accessible through a web-based interface (web-browser) and is supported by GIS. In short, FLIWAS is an information- and communication system designed to collect and process information and propose and manage actions before, during, and after a flood event and make this information available to various groups of users according to their specific requirements. Among others, this information will cover: • Representation of flood risks to be anticipated on the basis of flood protection installations, failure of flood protection installations, representation of risks and risk

SPM4910 – SEPAM Design Project (ICT) – Final Report

34

• • • •

potentials (population, hospitals, old people’s homes, cattle, dangerous substances, streets, railroads). Representation of the resources available to counter and avoid catastrophes (fire brigade, vehicles, stock of sand sacks, machinery). Representation of measures to be taken by way of digital alert plans and action plans Evacuation scenario Representation of streets serving as escape routes

FLIWAS consists of several modules. General modules provide standardized user communication, data access and management, and communication with external systems. FLIWAS will help each user, including policy makers, technical professionals, and civilians to access the right information. Distinction is made between obtaining and presenting measurement information (water levels, discharges, precipitation), specification and operational use of flood scenarios, drafting and effecting evacuation scenarios and resource management (FLIWAS Newsletter 1, 2006). More information about the technology and the stakeholders can be found in Appendix IX.

SPM4910 – SEPAM Design Project (ICT) – Final Report

35

6. Institutional situation
The previous chapters have given a clear overview of the actors, the available technology and the information streams and resources during a water calamity. It has become clear that the interconnection between these subjects is far from optimal; calamity control is does still not function as desired. Before being able to formulate a new design proposal, along with its requirements, it is of importance to recognize why this interconnection is not functioning properly. Therefore, an analysis should be performed on the institutional characteristics of water calamity control. This chapter will treat several theories on institutional design.

6.1 Theories covering crisis situations

This section is guided by theories covering crisis situations, based on Muller (1996). Muller makes a distinction between routine decisions, complex decisions and crisis decisions. Crisis decisions are a specific form of complex decisions, with two additional elements: a severe threat and time-pressure. Because of these two elements other theories on institutional design are hard to apply on crisis situations. Muller even says there are no real crisis theories available at the moment. In his article he makes an attempt to select specific parts of existing theories that can be used for crisis situations. The following theories can be interesting: • • Garbage can model - Crisis entrepreneurs make use of the situations to implement changes or gain right to exist. Example: relief services. Realism: mixed scanning and satisficing - Satisficing model presumes that only one criterion exists in decision making, which strokes with crisis situations.

The conclusion which can be drawn here implies that these theories may be of good use in the design phase, because they explain a lot about decision making in crisis situations. They are of less use in a descriptive way.

6.2 Theories covering the differences (emergency) organizations

between

governmental

This section is guided by theories covering the differences between governmental (emergency) organizations and is based on Koppenjan & Groenewegen (2005). The application of the theory to the case is done in a descriptive form, by applying existing literature and the conclusions of a an interview with mr. Koppenjan. Koppenjan and Groenewegen developed the four-layer-model. The model specifies four layers (as mentioned in Figure 8). 1. 2. 3. 4. The The The The level level level level of individual actors of institutional arrangements which determines the legal positions of the actors from level 2. which determines the culture and mindset of the actors from level 1 and 2.

The arrows between the layers (Figure 8) indicate which relations exist between the layers. The vertical arrows make clear that lower and higher levels influence each other directly. One important conclusion that can be derived from this model: “Since institutions are embedded in higher institutions, it is important that institutions are ‘appropriate’: they must be congruent with other institutions at other levels. If this is not the case, they will not function properly or will be unstable.” (Koppenjan & Groenewegen, 2005:9).

SPM4910 – SEPAM Design Project (ICT) – Final Report

36

This model is interesting for this case because several institutional environments and levels can be distinguished in large organizations like the relief organizations and the concerning governmental bodies.

Layer 4: Informal institutional environment of socio technological systems – culture, values, norms and attitudes

Layer 3: Formal institutional environment of socio -technical systems – formal legislation (formal rules, laws and regulations)

Layer 2: formal and informal institutional arrangements of socio-technological systems – instiutional arrangements (formal: covenants, contracts, mergers. Informal: rules, codes, norms, relations).

Layer 1: Actors and games in socio-technological systems – agents and their interactions aimed at creating and influencing certain outcomes
Figure 8 - The four-layer model (Koppenjan & Groenewegen, 2005:8).

6.2.1 Applying the four-layer model to the case Below each layer is applied to the case. To be able to start with the lowest level, the order of the layers is contrary to the model given in Figure 8. Level 1: Actors and games Loyalty to the own organization is very important among emergency workers. This attitude may result in actions that don’t stimulate cooperation with other organizations. Sometimes cooperation asks for sacrifices. Particularly in these cases a relief worker will protect his own organization instead of supporting the cooperation. During an incident the relief services cooperate, but when the incident is finished the services return to their old attitude of aloofness. A project group from the SMVP (The Dutch Society, Security and Police Foundation) concludes: “Sometimes it happens to be the case that policemen and fireman avoid each other to protect their own position or culture” (SMVP, 2004). Level 2: Formal and informal institutional arrangements Formal: The tasks, responsibilities and structure of the Dutch relief services are formally described in detail (the Police Act for example). For a long period, the services were allowed to fill in these responsibilities at their own manner. Due to this freedom, a lack of supervision and means to intervene, it isn’t easy for policy makers these days to control and steer the relief services. The Public Order and Safety Inspection concludes: “The current formal system of supervision is characterized by a high density of legal supervision relations to be carried out by administrative bodies, who nevertheless don’t have any well defined criteria or intervention possibilities” (Helsloot et al, 2004:95).

SPM4910 – SEPAM Design Project (ICT) – Final Report

37

Informal: Relief services have their own history and developed their own rules, codes and relations gradually over time. These rules and codes even differ between different regions of one emergency service (Appelman, 2006). Level 3: Laws and regulations Each relief service has its own act which specifies the formal tasks and responsibilities. Each relief service itself comes under multiple authorities (see chapter 3). All these authorities provide the relief services with multiple guidelines, independent of each other. There’s a lack of one central organization that carries the responsibility for the whole police department on a practical level. The ministry of BZK has the final responsibility for the police department, but this only counts for matters on a national level. The ministry doesn’t provide practical rules The content of these regulations is not unambiguous; most of the time these documents are guidelines or directives. For the relief services it’s unclear what the actual status of these documents is and how to interpret them. One region of the fire department puts this into the following words: “This (harmonization of supervision...) is necessary in a fire department field that is characterized by many decision makers, many visions and a large diversity in budgeting, education, exercise and quality” (Helsloot et al, 2004:55). Level 4: culture, value, beliefs This case only concerns Dutch organizations. Among the Dutch (relief) workers, a difference in culture, value and beliefs is not known. It’s acceptable to say that every organization involved in the fight against disasters strives for safety and security. When using a European perspective on this case, some problems might occur when relief services from different European countries have to cooperate. Small differences in national values and culture could exist. 6.2.2 Highlighted problems resulting from the applied theory The following conclusions can be derived from the model applied to the case: • For relief services it’s hard to communicate with other relief services because they each developed their own system for communication (layer 2). Nowadays they may use the same technology (C2000), but that doesn’t mean they use the same communication protocols and codes. Although C2000 stimulates more interaction between the different relief services, the internal culture sabotages this (layer 1). During an incident the relief services cooperate, but when the incident is over they all return to their old attitude of aloofness (SMVP, 2004). Formal means and incentives to achieve constant cooperation are missing. Even when they would exist two difficulties would remain: - Do the relief services really understand what the aim of these formal means and incentives are (layer 3)? - How should it be verified whether the relief services obey to the new rules (layer 2)?

SPM4910 – SEPAM Design Project (ICT) – Final Report

38

7. Problem specification
In the previous chapters the different facets concerning communication, coordination and cooperation between the different parties involved in case of a flooding calamity, have been analysed. The analysis started with the definition of a central problem definition that provided the fundament for the research outlined in this paper. The central problem definition was formulated as follows: “In case of a water calamity, how can the present problems with regard to communication, coordination and cooperation between the different parties involved be solved through the support of ICT?” Crucial for the structure of the performed research was the design of the objective analysis. This provided the overall picture on the different subjects that needed to be elaborated. The objective tree (Appendix I) presented the different sub researches that needed to be sorted out in a structural way, in order to provide a thoroughly determined overall answer on the research question. The different sections have provided a substantial insight in the relevant social, technical and institutional aspects of the problem area. In order to clarify the different analysed parts of information, this chapter will give a summary by briefly discussing the sub researches identified in chapter 2. Moreover, the most important conclusions of each sub research have been defined and clarified.

7.1 Sub researches
7.1.1 Sub research 1 – Actor and network situation In the actor and network analysis two groups of important actors have been identified. The government institutions (Ministry of VWS, Provinces, District Water Boards and Municipalities) are important for the policy and decision making processes. The group of relief services (Police Department, First Aid Services and Fire Department) is active and present at the location of the calamity. All these actors are dependent on an optimal level of communication, coordination and cooperation. To structure this, several calamity plans have been drawn up. These (extensive) plans contain detailed responsibility schemes and describe the different tasks that need to be fulfilled by the particular actor(s). Striking is the fact that nearly every actor has his own calamity plan. Although attempts have been made to integrate the different calamity plans in order to ensure an efficient calamity control organization, the complexity remains very high. The existence of several Municipal- and District Calamity Plans and the desired combination with the calamity relief plans, gives rise to the need of a coordinating databank. The databank should be linking these plans, or put them together, and giving aid in a smooth cooperation between them. This is established in an Operational Plan (OP). The ministry of BZK formulated guidelines in order to standardise the form of all these local OP’s, resulting in two different manuals. The Leidraad Maatramp (LMR), which concentrates on the regional preparations considering calamity control and the Leidraad Operationele Prestaties (LOP), which concentrates more on the operational part of calamity control. Analyzing the manuals of the relief services shows that the main processes executed in case of a flood or water calamity are of a multidisciplinary nature. This indicates that the communication, coordination and cooperation during such a calamity is of high importance and therefore a flood calamity provides a considerably interesting case.

SPM4910 – SEPAM Design Project (ICT) – Final Report

39

Lastly, in designing a solution to the problem of the imperfect communication, coordination and cooperation certain aspects should be assumed sufficient and accordingly should be placed outside the design boundaries.

Sub-conclusions 1: • Difficulties in coordination and cooperation: The decentralisation of the different calamity plans will cause major problems on the level of coordination and cooperation once a water calamity occurs. • Emphasis on multidisciplinary process: The most important process during a flood is the multidisciplinary process. The multidisciplinary process can be improved by efficient allocation of information. The information on available resources is sufficient, but needs to be properly allocated during water calamities. In the current situation, it is difficult to predict this allocation on beforehand, due to the involvement of many actors in water calamity control. Thus, it would be desirable to simplify the structuring of these actors in the first place. This could help create a good overview on a short notice and, as a result, make improvements on information allocation possible. Supporting information allocation through ICT could indeed be very useful. 7.1.2 Sub research 2 – Current technical situation The analysis on the current technical situation concentrates on the C2000 communication system that needs to be fully operational by now. Different aspects of the system have been clarified. The TETRA standard concerning the network layer, how the system can be used to communicate, the equipment used by relief workers and the C2000 project progress are aspects that are exemplified. The analysis shows the contradictions between different reports and articles concerning the project progress of C2000. A SWOT analysis was executed, which created a deliberate overview according to the current technical status of the C2000 system. The SWOT analysis shows a certain amount of bottlenecks. However, as one of the threats indicates the point of no return for the C2000 system has been passed a long time ago, which indicates the path dependency of the whole C2000 project. This proposes a large reduction in the opportunities to solve certain bottleneck. The first conclusion due to the current technical situation can thus be defined as: Sub-conclusions 2: • C2000 as principle technology: The path dependency of the implemented C2000 system demarcates the problem design space concerning technical issues. Every system that will be designed has to take the existence of the current C2000 system into account. 7.1.3 Sub research 3 – Information situation In this analysis the processes that can or will occur during a flood situation regarding information are being analyzed more specifically. The main processes during a water calamity are monitoring, scaling up, evacuation, the flood itself and taking care of the damage caused. Especially during the preparation phase and the evacuation phase, the degree of multidisciplinary cooperation is considerably high. It has become clear that the information streams between the different actors form a complex web; effective management would be desirable. The centre of operations is located at the Regional Operational Teams (ROT). The ROT forms the link between the teams in the field (e.g. relief services) and the decision-making institutions. This team is engaged in a process of collecting and receiving data,

SPM4910 – SEPAM Design Project (ICT) – Final Report

40

conceptualizing the situation, making decisions, requesting permission, and giving advice and orders. The evacuation process has been identified as the most important process within the analysis, because it is the result of a highly multidisciplinary collaboration between relief services and other actors on operational and policy level. It is shown that the evacuation activity consists of different processes including analyzing relevant information (nature, dimension, area, etc.), the drawing up of the evacuation plan, getting personnel and resources ready, bringing personnel and resources into action and the return of the people. Currently, several projects focusing on water management are active in the Netherlands. The most promising project is FLIWAS, a system that integrates (parts of) existing (information) systems, such as monitor and forecast models, geo-information, high water level scripts, water risk maps, and calamity plans. Sub-conclusions 3 • Static procedures: It seems that the whole process of gathering information, drawing up and executing an evacuation plan, is very much like a script, where one step follows the other. To put it more clearly; it seems to be very static. When an evacuation plan is made, there is no indication that, because of new knowledge, this plan can be altered along the way. This is, especially in case of a flood, where the situation changes every minute, not desirable. An evacuation plan should be flexible, and the Policy or Operational Team should have better means to change plans as a result of new information. This implies that situational changes can not adequately be communicated in the current situation, due to a lack of cooperation and coordination. An ICT system that could deal with the dynamic characteristics of a water calamity would be very useful. • High dependency on tacit knowledge: An important remark is that there is no information available that describes in detail the exact steps to be undertaken on a certain point in time. Of course, in a non-digital environment, this indeed would be useless, because no person will carry a manual during an emergency situation, and look up every step in the process. A lot depends on the tacit knowledge and intelligence of a person and his ability to act deliberate in stress situations. To make the quality of relief services less dependent on these more personal factors, an automatic script could be of great support. • Availability and accessibility: The availability and accessibility of correct and complete information for an effective execution of tasks are of an insufficient level, due to the dependency on human interaction. Currently, most information processing occurs in the policy level (through meetings) and is very time consuming. In other words, more efficiency in information processing is required. It would be desirable to directly store (new) information digitally, so that it can be directly structured according to its type, priority, status, authorization, etc. • Important tasks not assigned, ambiguous task definition: Not in all documents the tasks are defined unambiguously, or clearly assigned to actors. A clear task definition helps to create transparency and less confusion. It is not clear whose task it is to keep information regarding resources (trucks, sand bags, trains, etc.) available and up-to-date. The same holds for information regarding required contacts (churches, military, voluntary police, utility companies, etc.). This kind of information should be readily available before a flood situation occurs. There should be one database with all information about resources and contacts. In this case digitalization and the management of information with computer programs, can help in structuring, accessing, using the right information, at the right time, by the right person(s). • Little use of new information systems: As already mentioned in sub conclusion 1, the allocation of information between the involved parties is performed inefficiently. Despite new technologies and current developments, there is still no direct SPM4910 – SEPAM Design Project (ICT) – Final Report 41

connection between C2000 and the information systems discussed above, such as FLIWAS. This can have great positive effects, and empower the people working on the lower, more operational level, significantly. Persons doing the actual relief services, when supplied with the right information at the right time, can make better decisions more quickly, without the need of control or management directed from a higher level. A possible disadvantage of connecting C2000 with external systems could be an increased security risk. Use of information systems on any level: Not only on the operational level new information systems can be useful, but during every phase and on every level the information exchange can be enhanced when the right connection takes place between demand of information and available information. Some of the systems are already in use on a management level. Combined with the right information management programs (part of the initiatives), and decision support programs, emergency activities can be done quicker, better, and on the right time. Further analysis about system integration and compatibility: The final remark is that initiatives for the new information systems are for the greater part in their start-up phase. Some parts are already implemented and operational, others are in a test phase, and there are still parts that only exist on paper. The possibilities, especially in future situations, should be analyzed constantly. When talking about system development, or system integration, it is indispensable to have knowledge about content of messages being exchanged, the format, and how this all happens. This should be part of further analysis.

7.1.4 Sub research 4 – Institutional situation First of all, sub research 4 included the selection of a formal theory which would be applicable to the case described in this paper. For this sub research the four-layer model of Koppenjan & Groenewegen (2005) was chosen because of its diversity of institutional levels. After the application of the model several bottlenecks and problems became clear. Concerning the communication layer it became clear that each relief service had the opportunity to develop its own system for communication. They may use the same technology (C2000), but that does not mean they will use the same communication protocols and codes. These things developed gradually over time within the different organizations. This aspect forms a major obstacle in cross-organizational communication. With regard to the cooperation layer it is stated that although C2000 stimulates more interaction between the different relief services, this functionality has been “sabotaged” by the internal culture. Loyalty to the own organisation remains very important. The formal means and incentives to achieve constant cooperation are missing. Even when they would exist there are two difficulties that would remain. Do the relief services really understand what the aim of these formal means and incentives are? And how to control the relief services whether they obey to the new rules? Sub-conclusions 4 • Lack of standards: Although the different relief services can communicate with each other, the lack of standards and protocols on how to communicate leads to the development of problems on technical and social levels. This hinders efficient and effective cross-organizational communication. Arrangements on unambiguous information provision would be an important improvement to overcome these difficulties. The system design in Part II should include the capability to integrate information and make it understandable for all parties involved. • Cultural differences: The internal culture of relief services negatively affects the emergence of interaction between the different services. Cross organizational interaction can cause incomprehension and even give rise to conflicting opinions,

SPM4910 – SEPAM Design Project (ICT) – Final Report

42

hampering efficient calamity control. A digitalized information system that has taken up the wishes of different parties involved can eliminate these inequalities. Different expectations: The tangle of guidelines and directives makes it in certain situations unclear what is expected of each relief service in a certain place on a certain time. An adequate level of information allocation and information flow management can bring aid here. Fragmentation of power; Means for controlling the relief services are spread over many actors, so real decisiveness is missing.

7.2 Reflection
Earlier in the report it was stated that the central objective of the problem owner (the Ministry of BZK) is maximum security. To realize this objective, the objectives on the lowest level of the objective tree need to be obtained. The conclusions presented in this chapter give a good overview of the problems that occur in realising these objectives. The identified obstacles show that there is a need for an improved design that deals with them. The next chapter will present a proposal for a design that will solve the identified problems.

SPM4910 – SEPAM Design Project (ICT) – Final Report

43

8. Design Proposal
The preceding chapters have made clear that the activities during a water calamity are innumerable and often very complex. Various reports and (calamity) plans have made an attempt to bring structure and order in the maze of responsibilities and information streams. However, it has become clear that the integration and the translation of all these results to the real world is the most important pitfall. The three C´s (communication, coordination and cooperation) are thus not linked in an optimal way. In other words, how can everything drawn up in the preparation phase are made clear to every particular person during a calamity? Obviously, it will be impossible to oblige everyone to read all calamity plans and other relevant literature in advance. Moreover, a fireman doesn’t need to know the specific tasks of certain government officials; structuring is needed with respect to information streams. Points of attention here are availability, allocation and information flow management. Therefore, the system to be designed should be suitable for a total integration of the conclusions done in the previous chapters. With the C2000 system as the underlying technology on the one hand, and the responsibility schemes on the other, the situational awareness of every single person involved in a calamity should be optimized. This implies that every actor should immediately be aware of the following: his responsibilities his tasks who his superiors are who his subjects are where to find information what information he should communicate and with whom operation of C2000

A new system will have to be designed to satisfy these conditions, for it is clear that the existing systems are not able to meet these needs. In this chapter, a first draft for the system’s technological-, institutional- and process characteristics will be drawn up. Then, the system’s “mandatory”- and “preference” requirements will be identified in section 8.2

8.1 Technological design aspects
The new system will be built on the existing C2000 technology. This provides a clear demarcation within the technological design. However, the current C2000 infrastructure seems to fall short, due to a deficient coordination and cooperation. Currently, all information is centrally controlled by the Emergency Room which is part of GMS as described in chapter 3. Actors involved can therefore not directly consult information databases. Moreover, the information provided is mainly push based; the Emergency Room decides which information is delivered when and to whom. This centralized way of information provision is inefficient and ineffective. Therefore, the allocation, integration and translation of information should more decentralized and logically be organized. It is proposed to implement a Service-oriented Architecture in order to improve the provision of information during water calamities. Points of attention here are the current infrastructure, the used systems and databases, the actors involved and their roles in the proposed design, the organization of the Service-Oriented Architecture, as well as technical as management and the user interaction.

8.2 Institutional design aspects

The new system will require the many actors involved to set new agreements. This implies that the system should also obtain a broad social basis in the institutional context. Thus,

SPM4910 – SEPAM Design Project (ICT) – Final Report

44

new institutional arrangements will be required. It is important to determine how the actors involved will deal with the system. While respecting the existing responsibilities, it will be important to determine who will be in charge of the whole process of information management and how this management should be implemented. People will need to be ordered into groups, according to the responsibility schemes. These groups will have to be linked to each other in a hierarchical scheme. Moreover, agreements will have to be made on the way information is gathered, shared and stored.

8.3 Process design aspects
In order to reach an orderly and structured way of implementing the new system, a process design is required. The main purpose of the process design is to bring all the different parties involved together and improve cooperation. The C2000 analysis has already pointed out that agreements between relief services were probably not well founded; the level of cooperation between them was far from optimal. Moreover, an important bridge is to be built between the government institutions and the relief services. In the current situation, information sharing is very badly organized between and within these two actor groups. In other words, a process design should be made to create a high level of willingness to cooperate. Furthermore, the implementation time should be acceptable. All actors involved should come to accept the new system and incorporate it with their existing calamity plans.

8.4 Program of requirements
8.4.1 Classes of requirements To discover the design space a program of requirements has to be made. These requirements can be divided in two ways. A division can be made between mandatory and preference requirements: • Mandatory requirements - These requirements indicate the boundaries of the system that has to be designed. They are never part of a trade-off because it’s necessary the system suffices these requirements. These requirements could be defined as ‘need-tohaves’. This type of requirements is often referred to as functional requirements. Preference requirements - These requirements could be defined as ‘nice-to-haves’. These requirements can be part of a trade-off since the system will function without them as well. This type of requirements is often referred to as non-functional requirements

Since requirements could compete with each other trade-offs might need to be made. Obviously, it is important to determine which requirements can be involved in these tradeoffs. The division of requirements in preference (nice) and mandatory (need) requirements is not very easy to explain; defining them is often an arbitrary matter and the result of negotiations between involved parties. 8.4.2 Methodology To obtain a complete list of requirements, a Group Decision Room setting was used by the authors. In a Group Decision Room (GDR) complex questions are carried out with the use of computers. This can result in a lot of input in a short time, which is of good use during a brainstorm. The group of participants should be formed in such a way that every relevant party is represented by one or two participants (dependent on the maximum group size). This was unfortunately not possible in this amount of time, so the group existed out of four group members who tried to think outside their role of designer and to come up with as many requirements as possible. The following questions were discussed during the session: • Give some examples of possible failures during this exercise (April 12, 2006) concentrating on desired information (resources / needs).

SPM4910 – SEPAM Design Project (ICT) – Final Report

45

• •

Give some examples of possible advantages and disadvantages of full information. Identify as many requirements as possible.

The first two questions were used to identify possible pitfalls. The last question was used to get the list of requirements as presented below. A detailed report of the session can be found in Appendix X. The categories in which the requirements will be presented emerged during the session. To keep a good overview these categories themselves were divided into four classes; general, technical, institutional and process requirements. 8.4.3 List of requirements General Input-output These requirements show which input already exists and in what form they should be delivered to the users of the system. General, static plans are already available but they need to be transformed into practical pieces of information specified for each person (personalization). These requirements indicate that one of the most important functions of the required system is the translation of information to content made understandable for a calamity control setting. General information → Personalised information (need) Stored information / data → Operational data (need) Conceptual Information → Useable / operational information (need) Static data → Dynamic information (need) Analogue voice signals → Digitalised information (need) Request for specific information → location / provision of specific information (need) Conceptual information → visualized, clear information (graphs, tables) (need).

Information The input-output requirements pose a lot of concrete requirements on information. When a user sends a request for information he should receive a unambiguous answer, so semantics should be the same. Besides that the user should know how reliable the received information is to determine what actions to take. Limited amount of information a particular user in the field should receive (need) Clear and general semantics (need) Good quality of information input (content) (need) Good quality of information output (content) (need) Information should be delivered with a reliability grade (nice) Priority ranking in information provided (nice)

Technical Technological requirements The technological requirements are important because the required system has to cooperate with existing systems (often referred to as legacy systems). This poses among other things requirements on the format in which information is saved and stored (digital). The system that will be designed also requires some level of technical performance, captured in the following practical requirements: Compatible with C2000 (need) Compatible for extension with other (international) information systems and developments (nice) No (unwanted) interference with other systems (need) Sufficient available bandwidth (need)

SPM4910 – SEPAM Design Project (ICT) – Final Report

46

-

Web-based (possibly use of Internet applications) (need) Ability to couple this system to communication systems that civilians use (nice) Voice interaction possible (need) Ability of data-communication, including pictures (need) Real-time communication (no delays) (need) Existence of sufficient back-up systems (need) Be able to deal with all sorts of information formats (.doc, .xls, .pdf, .vsd, .jpeg) (need) Location based (nice) Adequate coverage (determined by C2000) (need) Robust (technical) (need) All information digitalised (need) All information streams digitalised (need) Digitalization of responsibilities within the system (nice)

Performance requirements The output of the system will also have to fulfil some specific requirements. This part deals with the representation and content of the translated information. To make this information reliable a certain quality of the input is required. To avoid unnecessary waiting in timecritical situations minimum process times are very important as well. Good representation of information (pixels + sound) (need) Personalized representation of information (font size, colours, etc) (nice) Minimum process times (need) Up-to-date information (need)

Institutional Responsibilities During a calamity, a relief worker should not have to think about his responsibilities or tasks. It should be clear who his superiors are and who has to decide on what matter. These different responsibilities should have its result in different system access rights. specified system accessibility (need) decisions should be made on a level as low as possible (nice) hierarchy should be very clear (need) clear responsibilities (need)

User requirements The system has to be used by multiple users from several organizations. The system needs a matching organisation structure and has to deal with this aspect of several users. To fulfil the specific needs of different users, the system first has to know which user it’s dealing with. After that, the interface and settings of the system can be adjusted to meet the user’s preferences. Requirements that deal with the (physical) use of the devices are left out because the design of these devices lies beyond our scope. Selective authorisation (need) Maximum security (need) Ease of use (nice) Clear user interface (nice) Familiar appearance to every relief service (nice) Database management should be relatively simple (nice) Ability to deal with relief service specific things (special features for firemen, policemen) (nice) Support of personalised settings (nice) Ability for users to rank information directly (nice) Operational flexibility (nice)

SPM4910 – SEPAM Design Project (ICT) – Final Report

47

Process Design process requirements As the system that has to be developed will be developed on the existing C2000 system, it can not be individually. Paralysing the whole communication system to implement the new system is not an option; a process should be defined to ensure an agile union between the two systems. Minimum implementation time (nice) Step-by-step implementation (need) All parties should be satisfied with the system (need) Existence of sufficient exercise possibilities (need) All relevant parties should be involved (need) 1st line users (police, fire, ambulance) should have a stronger position in the design process than 2nd line users (army) (nice) Frequent information updates for the involved parties during the design process (nice) No party should have blocking power all by himself (need) Protection of core values of all the involved actors (need)

Cost requirements Apart from delivering good quality the system should also be affordable. The costs should be kept as low as possible but no hard restrictions are known. The total costs can be divided into purchase, maintenance and adaptation costs. The new system could require existing systems to be changed. These costs are called adaptation costs. Low Purchase costs (nice) Low Maintenance costs (nice) Low adaptation costs of existing systems (nice)

SPM4910 – SEPAM Design Project (ICT) – Final Report

48

Part II – Designing the Web GMS
Part II consists of three parts: the process design, technical design and institutional design. The process design identifies the different decisions that need to be made and the sequence of these decisions. The technical and institutional design elaborate on the topics as defined in the process design. Many institutional decisions, that need to be made, arise out of the technical design. For this reason the institutional design is placed after the technical design chapter.

SPM4910 – SEPAM Design Project (ICT) – Final Report

49

9. Process design
Most of the design issues and decisions in this report are taken by the designer. Although the designer tried to take all the different demands and requests of different actors into account, one can imagine that a project with this size needs participation of the actors themselves. This chapter provides a design of the design process and therefore gives an extensive description on how to bring the different actors together. Obviously the results of each step in the process depend on the input of the actors involved. Nonetheless, in order to deliver a complete process design, some results are already filled in according to the design provided by this report. This chapter should be seen as a framework to facilitate and support the actual design.

9.1 Actors
First step is to determine which actors will participate in the design process. The initiator of the project, the Ministry of BZK, is free to invite actors who seem to be relevant to the process. For this process design the group of relevant actors earlier defined in chapter 3 (Actor Analysis) is selected. Ministry of BZK Ministry of VWS Provinces District Water Boards Municipalities Police Department First Aid Services Fire Department Project developer

As said these actors will be assimilated in the process design. The next paragraph will elaborate on how this process is designed.

9.2 Process design
The process is divided into five rounds (see Figure 9). After inviting all relevant actors the process starts with reaching agreements and formulating generic process rules. These rules will be valid during the rest of the process. When this part of the process is settled, a list of requirements can be made by the actors. There is a chance that some of these requirements collide with one another. These collisions can be seen as design issues. In order to cope with these design issues it is expected that certain trade-offs need to be made. Next, the type of design issue determines which actors will be appointed to discuss these design issues. The discussions or negotiations, in round 3, will be organised in four different clusters. These four clusters contain four different groups of actors. The distribution of the actors will be elaborated on further down. Only when the design issues (possible after much iteration) are solved, actors can start negotiating on the subject of costs and responsibilities. At the same moment, designers can start with the technical and institutional design.

SPM4910 – SEPAM Design Project (ICT) – Final Report

50

Round 1: generic process rules

Round 2: requirements

Round 3: design issues

Round 4: costs

Round 5: start project

Start technical / institutional design
time

Start technical / institutional implementation

Figure 9 – The five rounds of the process design.

As can be seen in Figure 9, the costs process round is placed at the end of the total decisionmaking process. This is done for several reasons. First of all, the Ministry of BZK strives for a technological optimal solution; therefore the issue of costs shouldn’t influence the technical design process. Second, it should be prevented that paying actors hold a disproportional influence in the design process. For example, user influence remains important even when the user pays a smaller part. Another advantage is created by the fact that the actors have the chance to get convinced by the opportunities of this new system along the process. This way commitment among the actors is created and this is finally expected to result in more willingness to contribute and pay for the system. Finally, after solving the cost issues, the project developer can finish the design and start with the implementation of the project. All rounds will be described in detail within the following paragraphs.

9.3 Round 1; Generic process rules
During this round the generic process rules will be formulated. Determining the generic rules will be done based on the four core elements of a process design. The core elements, which are described by De Bruijn, Ten Heuvelhof and In ’t Veld (2002), contain openness, protection of core values, speed and substance. The generic process rules should provide guidance in order to guarantee these elements during the process. The following part will determine the generic rules regarding each core element. Openness This project cannot be realised without the resources (funds and knowledge) of the other parties. In return, they want to influence the process and in order to achieve this goal the parties need full information on topics of discussion and negotiation. Besides full information, the parties should be able to defend their decisions towards the people or organisation they represent. By guaranteeing openness in the process the represented parties are able to keep an eye on the process and criticize it where needed. All parties should agree with the process design of the clusters and the division of actors over these clusters. The minutes of all meetings should be available for all parties.

Protection of core values The main core values of the involved parties are transparency, objective decision making (governmental organisations), environmental security (water boards, fire- and police department) and social security (police department). These actors are only able to participate in the process when their core values are protected. When some of the core values are at stake parties may decide to make use of the following process rules in order to protect their core values. The process outcome should be justified in relation to civilians. The process itself does not have to be transparent at all times (in order to protect classified information).

SPM4910 – SEPAM Design Project (ICT) – Final Report

51

-

Two exit-points are defined: - After round 1 (current round) - Before round 5 (costs) Parties who decide to use the exit-possibility before cluster 5 should explain their decision by letter.

Speed In order to implement the project, within a certain amount of time, the speed of the process should be sufficient. The term sufficient is determined based on the project planning. Speed of the process is also important when considering the commitment of the parties. One of the solutions to maintain speed in the process is the decision of putting the costs discussion at the end of the process. The choice to discuss on different clusters simultaneously also enhances the speed of the process. Other solutions lie in the character of the actors. They should have enough power to make binding decisions or to persuade other actors to cooperate (command and control). BZK is given the power to appoint side-meetings with actors. With this option BZK is able to use its power (command and control) towards other actors without causing embarrassing situations. Trade-offs within clusters are allowed. All participants should have sufficient commitment power During the entire process BZK will have the right to appoint a side-meeting with other parties involved. There is a maximum of one other party per side meeting. After each cluster, results should be justified in relation to the national parliament, the regional council, and the involved city councils.

Substance Finally rules on the substance are of evident importance. These rules should support quality and objectivity of the substance and furthermore protect the position of the participants. By the obligation to report to the national parliament, regional council and city council a great (the latter rule of the set of rules regarding speed) part of the desire to deliver sufficient substantive quality is guaranteed. Other rules to reach this goal are: Include system or design experts in certain rounds The role of experts and concerned participants during the process should be clear. In this way objectivity can be added to the process.

Actor commitment The C2000 project has shown that actors were willing to participate since they wanted to avoid other disciplines having too much influence in the project. When a region decides to develop a water-calamity communication system, the same behavior of the emergency services can be expected. The actors concerned in this case are part of a clear hierarchy (see Appendix II). In case actors do not see the benefits of this project for them and are not willing to cooperate, command and control is left. This works in two ways: - A higher placed actor might decide to use its power to persuade other actors to cooperate. The ability to appoint side meetings (mentioned under ‘speed’) enables actors to do this in a proper way. - The actors are obliged to report the results to the people they represent. Since only governmental organizations are involved, all results must be transparent and available for citizens. Security and calamity control are sensitive topics. One can imagine that noncooperative behavior will lead to objections from the citizens-side. They may decide to use their (electoral) power also to enforce the actors to cooperate.

SPM4910 – SEPAM Design Project (ICT) – Final Report

52

9.4 Round 2; Requirements

With the generic process rules formulated the next round can commence. This round will determine most of the important system requirements. The process of formulating these requirements will be based on (electronic) brainstorming and is supported by a computer system. In order to guide this particular process round first some specific rules should be established. With these rules clear the true process design of this round will be discussed. Result of this round will be general design issues identified during this round. Specific process rules Because each round has different topics on the agenda, one can imagine that this influences the process rules. To obtain a complete set of process rules, per round specific process rules are added to the generic process rules. The specific process rules, which are determined for this round, should direct and facilitate the process in order to enlarge the result. For this round parties are allowed to send representatives with less commitment power but holding more operational experience. During the brainstorm the following rules should be complied with: - The initiator (BZK) takes care of the constitution of the group and takes number and variety of group members into account. - Don’t criticise other parties’ ideas (not by word, laugh or other signals). - The brainstorm should be focused on quantity rather than quality. Speed is an important issue. - Participants should actively participate, which also includes listening to each other. - The brainstorm will be closed by a summary, classification and evaluation of the obtained requirements and the agreement of all participants on that.

Process design In order to create a complete set of system requirements all the actors should be involved in this round. There are several ways to obtain a extensive list of requirements within a short amount of time. One of the options is using an (electronic) brainstorming tool like the Group Decision Room (GDR). The GDR in general provides support for five basic activities: 1. Diverge 2. Converge 3. Organise 4. Evaluate 5. Building Consensus As suggested, thinking about requirements can be seen as a brainstorm session (diverge). For this reason the GDR is introduced during this round, reason is the importance of speed during the process. The strength of the GDR holds that the ideas of one actor can be an inspiration to other actors. After acquiring an extensive list of requirements some form of convergence and organisation (or classification) of the ideas is needed, these activities are both supported by the GDR as well. The fourth step is evaluating the list of requirements. The evaluation will be done through deciding whether a requirement is a ‘need-to-have’ or a ‘nice-to-have’. A detailed design of the GDR meeting which was used for this second round can be found in Appendix X. Generally, there’s no discussion about ‘need-to-have’ requirements. These requirements should be included compulsory and can be seen as the boundaries of the design space. An important characteristic of ‘Nice-to-have’ requirements is that they can be part of trade-offs and negotiations. Therefore, the nice-to-have requirements should be compared with each other in order to see which of them collide. These competing requirements are addressed as design issues which will be dealt with in the next round (round 3). Defining the design issues is a task of the initiator (BZK) and needs approval or correction from the other actors before the start of round 3.

SPM4910 – SEPAM Design Project (ICT) – Final Report

53

General design issues In order to describe the following rounds, the list of requirements from chapter 8 is taken. Furthermore design issues were identified according to the method as described above (see Appendix XI). A division is made between general design issues and costs design issues. It is assumed that most requirements will collide with the desire to keep the system costs as low as possible. The group of requirements regarding costs is taken apart and will be discussed in a separate round (round 4). The other (substantial) design issues are listed below, accompanied by a short explanation why these requirements may cause conflicts. 1. Clear and general semantics Every party has different perceptions of the meaning of clear and general semantics and what these semantics should look like. 2. Clear and general semantics vs. compatible for extension with other (international) information systems and trends Involving more diverse parties and various systems will increase the number of different semantics that are used. 3. Selective authorization Discussion concerning the authorization rights. 4. Ability to couple this system to communication systems for civilians use vs. maximum security Creating an external link to provide civilians with information enlarges the risk of spreading classified information. 5. Web-based (possible use of Internet applications) vs. maximum security Creating an external link to another (global) network enlarges the risk of spreading classified information. 6. Limited amount of information a particular user in the field should receive vs. decisions should be made on a level as low as possible To make well thought decisions sufficient information is needed. 7. Selective authorization vs. decisions should be made on a level as low as possible Discussion on where to draw the line between selective authorization and the necessary information to make decisions. 8. Compatible for extension with other (international) information systems and trends vs. clear operational responsibilities Involving more diverse parties will have consequences for the existing operational responsibilities during a calamity. 9. Decisions should be made on a level as low as possible vs. clear operational responsibilities A more extensive division of responsibilities makes it difficult to keep a clear overview of the operational responsibilities.

SPM4910 – SEPAM Design Project (ICT) – Final Report

54

9.5 Round 3; Design issues

The design issues determined in the last round will be main issue of discussion during this third round. As with the previous round, some specific process rules are added to this round. Specially added process rules - The initiator (BZK) will form different groups of actors and assign particular design issues to them. When actors disagree with these decisions they hold the opportunity to hand in complaints, which obviously should contain substance-based arguments why the actor should be involved in that particular cluster. This also concerns actors who were not earlier involved in the process. BZK takes these complaints into account and decides for each cluster what actions to undertake. - Actors have the right to decide not to participate in the clusters. Process design Not all actors have to be involved for each design issue. Table XI.3 (Appendix XI) shows the actors that should be involved for each negotiation. When comparing the groups of actors that are needed per design issue the same pattern can be distinguished for some design issues. These issues are put together in a cluster which enlarges the negotiation package and the possibility for trade-offs. Furthermore discussing several issues at one time might contribute to the process speed. In round 3 four clusters can be distinguished (see Figure 10).
Round 3: design issues Cluster 4 (3-6-7-9)

Round 1: generic process rules

Round 2: requirements

Cluster 1 (2-8)

Cluster 2 (1)

Round 4: costs

Round 5: start project

Cluster 3 (4-5)

time

Figure 10 – The design issue clusters.

The different clusters can be seen as arenas, as defined by Cohen, March and Olsen (based on Koppenjan, 2004). The outcomes of particular arenas will form the input of other clusters. The decision process within the arena is not linear but is more comparable to a game. Since different actors meet each other again in other arenas multiple games are played within one arena. This implies trade-offs among the different clusters are possible within each round. Cluster 1 comes first at the agenda. The decisions made in this cluster might result in the invitation of other (international) actors to participate in the process. Therefore it’s necessary to decide upon this point first. In order to prevent misunderstandings it’s also important to make decisions relating to the used semantics (cluster 2) before starting with the other clusters. The issues discussed in cluster 3 and 4 don’t relate to each other directly, so it’s possible to let them take place in parallel. The content of the clusters will be discussed below. Besides, process rules for each cluster are made on top of the generic process rules.

SPM4910 – SEPAM Design Project (ICT) – Final Report

55

SPM4910 – SEPAM Design Project (ICT) – Final Report

56

Cluster 1 – compatibility with other systems Design issues: 2-8 Actors involved: BZK, VWS, PRO2 Specific rules: - No actors may be invited anymore, except on behalf of BZK. - In this phase commitment to the project, not to the process, may be postponed. - The outcome of this cluster must be notified to the other actors who did not participate in this particular cluster. - Each (international) system that will be discussed should be illustrated by an expert. Cluster 2 – standards and semantics Design issues: 1 Actors involved all (except PRD) Specific rules: - New actors may only be invited to this round when based on arguments following from round 1 and with approval of BZK. - In this phase commitment to the project, not to the process, may be postponed. - The police department, fire department, first aid services and BZK have votes with the weight of two at one’s disposal where the other parties have votes of the weight of one. This is done because the three emergency services are the most important operational actors and BZK is the initiator of the process. Cluster 3 – external systems and security Design issues: 4-5 Actors involved: BZK, MUN, PD, PRD Specific rules: - No actors may be invited anymore, except on behalf of BZK. - In this phase commitment to the project, not to the process, may be postponed. - The outcome of this cluster must be notified to the other actors who did not participate in this particular cluster. - Security (IT) experts should be involved to guarantee a certain level of quality in the decisions made. Cluster 4 – responsibilities and authorization Design issues: 3-6-7-9 Actors involved: DWB, MUN, PD, FD, FAS Specific rules: - No actors may be invited anymore, except on behalf of BZK. - In this phase commitment to the project, not to the process, may be postponed. - The outcome of this cluster must be notified to the other actors who did not participate in this particular cluster. - Decisions may not be in conflict with existing operational plans.

2

The used abbreviations correspond with those used in Appendix 1; a legend is to be found there.

SPM4910 – SEPAM Design Project (ICT) – Final Report

57

-

Because all involved parties should accept the system, responsibilities and be able to work with the system, an unanimous approval is required.

SPM4910 – SEPAM Design Project (ICT) – Final Report

58

9.6 Round 4; Costs and responsibilities

With the design issues solved the next step is the division of the project and system costs. As seen with the previous two rounds specific rules are formulated in order to support the process. Specially added process rules - Point of no return, commitment may not be postponed - Actors have the right to decide not to participate in the project (exit option). Process design Costs as earlier explained are placed at the end of the process for several reasons. With the requirements for the technical design clear, determining and dividing the costs will result in financial constraints and possibly influence the solution space. Therefore balancing between on the one side a technological right solution and on the other side financial feasible solution brings complexity to the process. The costs, as can be seen in Appendix XI.2, are divided in purchasing, maintenance and adaptation costs. The purchasing and adaptation costs are expected to be one time expenditures, the so called investments. This in contrary with the maintenance costs, which probably will recur each determined period, also known as the exploitation costs. The C2000 project documents use the terms investments costs and exploitation costs, so it may be useful to hold on to that terminology. Because of their different nature these costs are, like round 3, placed in separate clusters. The two clusters formed, as illustrated in Figure 11, can be executed at the same time. This simultaneity is only possible when all parties are able to delegate more than one person responsible for the decision on funds.
Round 4: costs and responsibilities

Cluster (Investment) Round 5: start project

Round 1: generic process rules

Round 2: requirements

Round 3: design issues

Cluster (exploitation)

time

Figure 11 – The costs clusters.

As seen in round three, trade-offs among the different clusters are possible within this round as well. The exact costs of the project should be determined once the technical design is completed. In order to draw up a cost distribution, an estimation will be sufficient in this phase. The distribution of the costs will be done based on an analogy. The cost of the project is computed by comparing the project to the C2000 system. It should be noticed that this comparison only serves as a guideline for this process round. Yet the analogy is expected to be rather accurate because there is recent project data available, which includes a systematically maintained cost sheet. Because division of costs in this phase holds a division

SPM4910 – SEPAM Design Project (ICT) – Final Report

59

in percentage, the sheet should be converted. In order to create a thorough division of the costs experts, with their experience to predict project costs, will be used. These experts should judge and adjust the result. This control is relatively cheap and can be quite accurate since experts have direct experience regarding similar projects. The result of converting the similar C2000 project and subsequent adjustments will form the base, and guidelines, for the discussion within the two clusters. The parties will discuss and negotiate on small margins which are determined by operational advantages regarding the different parties. Different types of costs and responsibilities were identified based on the C2000 project. Table 4 shows which actors were responsible for them at the time. Several trends could be distinguished. The central government was mainly responsible for the investment costs and took responsibility for central tasks. On the other hand, local governments were responsible for keeping the system running over time. Table 4 – The costs and responsibilities regarding Web Actors Costs BZK (including VWS and Investments Defence) - Infrastructural costs - System coverage costs - Central project organisation costs - Central administration organisation costs - Pilot projects Central exploitation - Infrastructure related costs (e.g. maintenance of lines, switches etc) - Network management - Pay off loan3 Regions (Emergency Services and local governments) Investments - Equipments costs - Education costs - Regional project costs Regional exploitation - Employees salary - Equipment maintenance Project developer System implementation Equipment purchase Local maintenance Security Training Education Spatial coverage planning Infrastructure realisation Central project coordination Project guidance Implementation support GMS. Responsibilities - Project organisation - Equipment purchase - Support regions - Connection with central systems and GMS - Provide project information - Security

With regards to round 4, this division of costs and responsibilities will function as a framework for the actors to start with. To make sure the project will succeed some costs are coloured black. These costs must be paid by that particular actor. This will also provide the
3

As previous projects show it’s not unusual for the central governments to provide loans without interest to lower governments. Since no interest is brought into account this will result in costs for the central government.

SPM4910 – SEPAM Design Project (ICT) – Final Report

60

actors some hold, because starting with a green field might be difficult. The nature of the grey coloured items doesn’t tell whether this is a typical responsibility for one particular actor. Therefore they are part of trade-offs. This also means that packages will contain a mixture between costs and responsibilities.

SPM4910 – SEPAM Design Project (ICT) – Final Report

61

9.7 Round 5; start project

With the substantial design issues and costs division determined, the start of the project follows. The start of the project is characterised by negotiating on contracts which are formally arranged in this phase. The arrangements include the responsibilities and costs as discussed during previous rounds of the process. In order to keep commitment to the earlier taken decisions in previous rounds, round 5 should take place directly after finishing round 4. This avoids misunderstandings and discussions about earlier made decisions. This is indicated in Figure 12.

Round 1: Generic process rules

Round 2: Requirements

Round 3: Design issues

Round 4: Costs and responsibilities

Round 5: Start project

time

Figure 12 – The clustering of round 4 and 5.

As Figure 9 shows, the design process starts immediately after round 3. Round 5 provides actors the opportunity to comment on those initial designs (made by professional designers) and to compare them with the program of requirements (round 2). After approval of the designs by all the actors the contracts can be signed. This will be the kick-off of the implementation phase. In order to facilitate this round special process rules were made. Specially added process rules - An independent judicial expert (assigned by BZK) must be present during this round. - All participants must have sufficient rights to decide on high-level arrangements. - Each party is allowed to invite his own legal adviser. The technical design and institutional arrangements will be extensively described in the following chapters.

9.8 Process design reflection
Appendix XI.4 shows an overview of the process design compared to the process requirements. Since this design ends with the start of the project it was hard to say anything about the implementation requirements. The other requirements were fulfilled by one or more rounds.

SPM4910 – SEPAM Design Project (ICT) – Final Report

62

10.Technical Design
In this chapter, the technical design will be worked out. First, the “Geintegreerde Meldkamer Systeem” (GMS) will undergo a more in depth analysis, to get sufficient insight in the current deficiencies in information exchange during calamity control. Next there are bottlenecks identified according to the current situation and necessary modifications are proposed to solve the bottlenecks. In following the Service-Oriented Architecture is presented to obtain the identified opportunities. Then, a framework will be drawn up for the design of the system that should cope with these deficiencies. This framework will be based on the Service Oriented Paradigm, and will be specified on applications in water calamity control. Finally, the proposed technical design will be presented and the improvements will be described.

10.1Current situation GMS
In this paragraph, a more detailed view on the current technical situation will be generated. The basic technical design behind the information provision during calamities is covered by the C2000 communication system. The C2000 network connects relief services like the police, fire department and ambulance services as well as the military police. Each emergency room has as main function to divide users in groups based on their situation and authority during a calamity. The involved emergency workers receive relevant information, in which the relevancy is determined by the controllers (or centralists) in the emergency rooms. A positive aspect of this construction is the coupling of relief services by C2000 to the GMS operators from different disciplines. This provides the opportunity to share information with each other, which can lead to qualitative better information provision (Ministry of Interior and Kingdom Relations, 2004). The most important activity of the centralists, the communication with the relief services via C2000, is provided by a data communication server (DCS). The DCS is the connection between the internal network of the emergency room and the outside communication networks (Ambucom, 2005). In order to work as efficient and effective as possible, the centralists have sophisticated workplaces, where a lot of telecommunication and automation systems are installed (Pieters, 2006). This includes a certain amount of terminals and monitoring devices that connect them with different information systems, databases and the internet. Lastly, each workplace within the GMS contains an ARBI, which provides the direct connection with the outside world. This kind of computer telephones create the possibility to connect every service and authority instantly.

SPM4910 – SEPAM Design Project (ICT) – Final Report

63

Network
Diverse analogue mobile networks

GMS
Emergency Room

Operational Information Systems

CMS System ARBI’s OMS System

C2000

Data Communication Server Terminals

GIS Systems

Internet
ARBAC PC’s Monitoring Devices CCS-Vnet

Etc.

Figure 13 - Schematic overview of the current situation of GMS. Figure 13 provides a schematic overview of the operational information systems linked to the GMS. These systems are, among others: the CMS system, OMS system, GIS system, ARBAC, and CCS-Vnet. The CMS system is the information system that establishes the connections between the emergency rooms and the relief services. Another important system is CCS-Vnet, that functions as the Command and Control System in calamity control. Furthermore, there are terminals that provide visualization which constantly bring out reports; and example is the OMS system that, in the case a fire occurs, helps visualize the location of the incident. Finally, there are terminals that control old analogue mobile systems, such as ARBAC. 10.1.1Problems arising due to the centralized nature of GMS The described situation implies a very centralistic approach in which information provision is fully dependent on the centralists in the emergency room. Information required by relief workers is provided by the centralists, who attain the desired information from different systems, databases and the internet (Pieters, 2006). In other words, the information is provided on a push basis. Although the opportunity for relief workers to pull information exists, all information flows via the centralists. Except the inefficiency in time of such an intermediate station, there is a chance that the emergency room employees do not provide the precise required information, because of misunderstanding and/or misinterpretation. Another bottleneck is formed by the voice-based nature of the provided information. It is generally acknowledged that voice has its limitations. For example, a schematic figure can in one glance provide a lot of information on the structure of an area or location. Accomplishing the same via voice is almost unrealizable and therefore very inefficient and ineffective. Therefore, a more decentralized approach seems desirable. Much information could be provided digitally, not only push-, but also pull based. Moreover, interactive content such as weather information, GIS maps, emergency plans etc. could better be provided to a relief worker via some kind of interface instead of voice. In any case, a more decentralised approach asks for a division in the supply of different types of content. This division will be discussed in the following sections.

SPM4910 – SEPAM Design Project (ICT) – Final Report

64

10.1.2Necessary technical modifications To succeed in applying a decentralized approach, modifications in the technical architecture of the GMS are necessary. This approach, which will make pulling information by the relief services possible, asks for a more layered structure. The current voice communication with the emergency room can be seen as a one layered system. Another layer will have to be added, which performs the transition and transportation of data information between the relief services in the field and the operational information systems. Figure 14 sketches this layered concept by two parallel lines from the network to the information systems.

GMS
Data layer Network Emergency Room Operational Information Systems

Figure 14 - Schematic overview of the layered proposition of GMS. To make data communication on this new layer possible, certain technical elements need to be implemented. The idea was suggested that a relief worker should have access to the available information systems and databases via some sort of interface. Such an interface can figure as the entry point to every individual system. To make this technologically possible there are two general methods available (Kar and Verbraeck, 2005): • • The different systems and databases should all be integrated in one overall system. The systems and databases should somehow be placed in an organized way next to each other, in which only the interfaces are integrated.

If cost efficiency and operationally are taken into account, the first option is far from optimal. Considering the large amount of operational systems and databases, which are consulted by the centralists in the emergency rooms and the high percentage of legacy systems (systems considered not up-to-date regarding the technical architecture) this seems to be an impossible and costly mission (Kar and Verbraeck, 2005). The second option seems more viable. As mentioned in section 5.4, The Flood Information and Warning System (FLIWAS) is the most promising project with regard to supporting calamity control information streams (International Commission for the Hydrology of the Rhine Basin, 2006). “FLIWAS is an information- and communication system designed to collect and process information and proposes and manages actions before, during and after a flood event and make this information available to various groups of users according to their specific requirements” (International Commission for the Hydrology of the Rhine Basin, 2006). Efficiently connecting FLIWAS to the GMS can provide a great expansion of the digital information resources. Moreover, digital information streams could offer better support and higher quality to the cutting necessity for cooperation and coordination. 10.1.3Method proposal: Service Oriented Architecture A well-known example of a method that can build the technical architecture in such an organized structure is the Service-Oriented Architecture (SOA) approach. In its most basic form, a SOA is a collection of services on a network that communicate with one another. Apart from being an architecture of services seen from a technology perspective, a SOA also concerns the policies, practices, and frameworks by which it ensures that the right services are provided and consumed (Sprott and Wilkes, 2004). The services are loosely coupled, meaning that an application does not have to know the technical details of another application in order to communicate with each other. Furthermore, the services have well-

SPM4910 – SEPAM Design Project (ICT) – Final Report

65

defined, platform-independent interfaces, and are reusable. A SOA makes it easier to integrate the whole IT environment; therefore it works very well in heterogeneous environments. Moreover, SOA provides a higher level of application development that, by focusing on business processes and using standard interfaces, helps to mask the underlying technical complexity of the IT environment (Datz, 2004). This mask is usually exposed in the form of a portal. A portal functions in this respect as the interface or, in other words, as a web-based service that offers a broad array of resources and services (Datz, 2004). In general, the technical design of the new data layer can be divided into two components: − The front office will be formed by a web-based portal (the interface). − The back office will be organized according to the SOA concept.

10.2Service-Oriented Paradigm4
In order to involve all the important aspects that need to be considered when implementing a Service-Oriented Architecture, a framework will be used as a guiding principle. Papazoglou and Georgakopoulos (2003) provide a Service-Oriented Computing paradigm (SOC), which is perfectly suited to fulfil this task.

Figure 15 - Extended Georgakopoulos, 2003).

service-oriented

computing

paradigm

(Papazoglou

and

Figure 15 shows the extended service-oriented computing paradigm (SOC). Three dimensions can be derived out of this paradigm: the actor dimension, the service layer dimension, and service functionality dimension. Each of these dimensions will be shortly explained for the case of developing and maintaining the SOA for GMS. In the following sections, every dimension will be undergo a more in depth analysis with respect to the case. 10.2.1Actor dimension This dimension appoints the different actor groups involved and their roles considering the SOA to be designed. Five main actors can be identified in the SOC paradigm: the Service provider, the Service aggregator, the Service operator, the Market maker, and the Service
4

Based on Papazoglou, M.P. and Georgakopoulos, D. (2003).

SPM4910 – SEPAM Design Project (ICT) – Final Report

66

Client. Table XII.1 in Appendix XII gives an overview of the different actor groups and their specific roles. In a SOA it is critical to implement processes that ensure that there are at least two different and separate processes: a process for the service provider and a process for the service client (Sprott and Wilkes, 2004). The centre of attention for the service provider and the service client is the interface (or web-based portal). This is the component of the SOA where both processes will have to meet. For the service client, the process must be organized in such a way that only the service interface matters, and there must be no dependence upon knowledge of the service implementation. If this can be achieved, considerable benefits of flexibility accrue, as it is difficult for the service provider to make well-founded assumptions about service client behaviours. The service provider concerns are to develop and deliver a service that can be used by the service client in a completely separate process. Obviously, the service clients and service provider will have to come to agreements on how to fit out their processes so that they can be effectively linked to the interface. The content of this interface will be discussed in the next section. The identification of possible problems caused by the originated actor arena will be discussed in the institutional analysis, which is performed in chapter 11. 10.2.2Service layer dimension In this dimension, the fundament of the SOA will be formed: the new system should exist of one composite service, which will be disseminated by a portal. According to the SOC paradigm the structure of SOA can be described according to three service layers: Management, Composition, and description and Basic operations. Table XII.2 in Appendix XII.2 provides the theory behind the three layers including their definition and further details. The most important aspects of the three service layers are treated in the sections below. 10.2.2.1 Description and basic operations layer The SOA’s foundation is constituted by the basic services, their descriptions and basic operations, in the description and basic operations layer. This layer is a description of the services to be included by SOA and their basic operations. In the first paragraph of this chapter there were already some systems and databases mentioned which services are used. In order to get an extended overview, the different systems and databases used by the emergency rooms to collect information need to be determined. Table XII.3 in Appendix XII gives an overview of the main systems and databases on this moment used by the emergency rooms and optional systems to be used in the future. The services are shortly described and their basic operations are mentioned. 10.2.2.2 Service composition layer This layer forms the core of the three service layers, as it identifies the different services that can be offered by GMS and categorize them into service groups. The service composition layer encompasses necessary roles and functionality for the consolidation of multiple services into one single composite service. The resulting composite service may be used by service aggregators as components (basic services) in further service compositions or may be utilized as applications by service clients. Service aggregators develop specifications and/or code that permit the composite service to perform functions that include coordination, monitoring, conformance and quality of service composition. In a SOA environment service aggregators thus publish the service descriptions of the composite service they create. In order to accomplish an efficient aggregation, Sprott and Wilkes (2004) claim that the structure of a SOA can be divided in three sub-architectures. Based on the division in sub

SPM4910 – SEPAM Design Project (ICT) – Final Report

67

architectures the different elements that are needed to provide the composite service can be identified. The three architectural perspectives are listed and shortly elaborated below5. They are subsequently sketched in Figure 16. − The Application Architecture This part provides a business-oriented solution that uses services from the service provider. Furthermore, it integrates these services into business processes, which will accordingly be provided to the relief services. Interaction is usually provided by a webbased interface, such as a portal. The Service Architecture This part provides the bridge between the implementation and the used applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture. The Component Architecture This part describes the various environments (systems and databases) supporting the implemented applications. These elements were defined in the previous paragraph. Figure 16 shows that other component architectures, such as FLIWAS, can also be covered in the SOA.
Portal interface

Application Architecture

Service Architecture

Service Domain Routing

Service Routing

System Fliwas

Component Architecture

Database

Figure 16 – Architectural backbone of the SOA to be designed (based on Sprott and Wilkes, 2004).

5

Based on Sprott, D. and Wilkes, L (2004).

SPM4910 – SEPAM Design Project (ICT) – Final Report

68

The decisions made above are all theoretically based. This theory provides the foundations of a more concrete technical design, which should include the different technical elements taken up in the proposed architecture as sketched in figure 4. Identification of these elements can occur through the description of service routing and domain grouping. Service routing At the core of the SOA, services should be managed as first order deliverables (Sprott and Wilkes, 2004). In order for the relief services to be able to send a request at the portal for any service located in any service domain, the service-oriented architecture must provide location transparency. At the same time, accessing the service repository before each invocation of a service can be a time-intensive process (Nadhan, 2003). Therefore, the service architecture should be able to obtain the following functions: − Provide location transparency to the systems and databases in the component architecture. − Ensuring acceptable system performance levels. − Contain the possibility to be managed individually and in sets. To solve this service-routing challenge, the current technique provides two general ways, namely via intelligent services or via routers (Nadhan, 2003). • Intelligent services: This technique is the approach by which location information is built for all services into each individual service. • Routers: The routers approach makes it possible to move the routing intelligence from the individual services to a routing component. The requirements defined in chapter 8 serve as the foundation on which the choice for an approach is based. Requirements that should be addressed here are high reliability and minimum process time (need to haves), while low maintaining costs would certainly be desirable (nice to have). These requirements can not be obtained through the intelligent services approach, as this approach eliminates some steps. The intelligent services approach relies on a particular intelligence in the databases and systems to directly communicate with the application architecture. This will lower the implementation costs, but results in an overloaded service (Nadhan, 2003). A system as crucial as GMS during calamities, may never fail and certainly not because of an overload of requests. Next to this the intelligent services approach is inflexible to changing in services, which would mean for GMS to be a maintenance intensive system. In contrast, the routers approach is far more reliable, with faster processing times, while needing less maintenance. The requirements are met by the leveled structure of this approach, through which the load per component is reduced. The routing components can be divided into two levels (Nadhan, 2003): 1. Service domain routing level A service domain router has intelligence about the location of all service domains. Upon receiving a request, it determines if it can service the given request by using one of the services it supports. If so, it processes the request. If not, it passes the request on to the appropriate domain that can service the request. 2. Service routing level A service router is used within a service domain to direct the incoming request to the appropriate service within the domain. Only those requests that can be serviced within a given service domain are passed on to the service router. The service router reduces the load of the location information on the individual services. The two-levelled structure makes it possible for decisions concerning coordination, cooperation, monitoring, conformance and quality of service composition to be made at the service routing level, rather than for each individual service (Sprott and Wilkes, 2004).

SPM4910 – SEPAM Design Project (ICT) – Final Report

69

Therefore, the routers approach will be applied to meet the systems needs and requirements. Service domains Another important that should be clarified when identifying the technical elements of the system to be designed, is the classifying (or grouping) of services into the different domains. Classifying services into logical service domains simplifies the architecture by reducing the number of components to be addressed (Nadhan, 2003). Examples of the service domains relevant for this case are given in Table XII.4 in Appendix XII. Several approaches exist to group the identified services into domains. For this analysis, the functional domain approach will be applied. Functional domains are based on the business functions being served by a set of services (Nadhan, 2003). This approach states that the service operators define and segregate the business functions and, therefore, the service domains. Through such groupings, service operators can have autonomous control over the services within a particular domain. As mentioned in the previous section, there will only be one service operator; the technical management of GMS. This management will thus have the autonomous control on the service domains of the system to be developed. The process of grouping is treated in the process design (chapter 9). Decisions concerning routing and grouping of domains leads us to how the routed and grouped information becomes available to the service clients by means of visual content in the application architecture. Firstly, it needs to be determined how this is performed by means of a web server and subsequently the interface or portal is described, which will perform as the connection between the service client and the GMS system (including the service provider). Service application through a web server In order to display the information from the different systems and databases through the routers into content usable for the relief services, the information goes through a transition process. In this respect, the application of SOA on an interface is manifested by web services (Papazoglou and Georgakopoulos, 2003). A web service is a specific kind of service that is identified by a URI, whose service description and transport utilize open internet standards (Datz, 2004). Interactions between web services typically occur as SOAP calls carrying XML data content. Interface descriptions of the web services are expressed using Web Services Definition Language (WSDL). The Universal Description, Discovery, and Integration (UDDI) standard defines a protocol for directory services that contain web service descriptions (Papazoglou and Georgakopoulos, 2003). UDDI enables the relief services to locate candidate services and discover their details. Service clients and service providers utilize these standards to perform the SOA’s basic operations. Service aggregators may use the Business Process Execution Language for Web Services (BPEL4WS) to create new Web services by defining corresponding compositions of the interfaces and internal processes of existing services (Papazoglou and Georgakopoulos, 2003). Service portal The service portal (or interface), which links the service clients to the GMS, will be implemented on web services, using SOAP calls carrying XML data content. However, the specific content that will be displayed when a service client enters the portal is dependent on the negotiation process between the service provider, service aggregator and service clients. Considering the defined requirements on the information quality and quantity, and the technical, institutional and process requirements this will be a difficult decision making process. Solutions for these difficulties should be sought in the process- and institutional design.

SPM4910 – SEPAM Design Project (ICT) – Final Report

70

10.2.2.3 Service management layer To manage the critical composite service and all that it covers, the paradigm provides managed services in the top layer. The responsible actor, the management of the GMS, should have different instruments available to manage critical applications and specific markets (see Table XII.2). A separate management platform creates a level of flexibility that allows the exposed service (e.g. the service used by the service clients) to be adjusted without modifying the underlying components. The key to separation is to define a virtual platform that is equally relevant to a number of real platforms (Sprott and Wilkes, 2004). The virtual SOA platform comprises a blueprint which covers the development and implementation platforms. This blueprint provides guidance on the development and implementation of applications to ensure that the published services conform to the same set of structural principles that are relevant to the management and consumer view of the services. An important actor in the management layer is the market maker, who has the endresponsibility over the service management layer. Normally, this is a consortium of organisations that brings the suppliers and vendors together in an open service marketplace (Papazoglou and Georgakopoulos, 2003). However, in this respect the Ministry of BZK is just one organisation and there is no open market. The method of appointing providers, aggregators and clients is a closed process in which BZK will have an exclusive position. This has large implications for the arena in which the different actors perform and this issue will therefore be further elaborated in the institutional design (chapter 11). 10.2.3Service functionalities dimension This layer is strongly related to the service layer dimension. The three layers all define different services. The description and basic operations layer provide basic services. These basic services can be divided in the ‘simple’ services, which are services directly translated from one system or database, and the more ‘complex’ services, which are formed by combining existing systems and databases to create new services. An example of the latter is the FLIWAS system. The service composition layer delivers composite services. These services have as purpose to perform coordination, conformance, monitoring and/or Quality of Service considering the basic services. Finally, the service management layer provides managed services. As the name already implies, these are services that support management activities. Examples of these activities are certification, design of Service Level Agreements, operational support and operational assurance.

10.3 Proposed technical design: the WebGMS

The SOC paradigm covers a great part of the facets that are of importance concerning the implementation of a SOA into the GMS infrastructure. It has become clear which actors are involved in the technical element of GMS and what their basic roles are. Subsequently, the different services that need to be covered by a SOA have been defined. Furthermore, the technical elements required to make the SOA operational have been identified according to the division in three sub architectures. As a result, a proposition of the technical design for the new system can be done: WebGMS. Figure 17 shows the concept developed by means of the sub architectures. In order to distinguish the differences with the current situation, the idea of Figure 1 has been used as reference. The figure will be clarified by means of the sub-architectures and the technical decisions made.

SPM4910 – SEPAM Design Project (ICT) – Final Report

71

Figure 17 – Schematic overview of the WebGMS.

The component architecture is presented by the diverse operational information systems and databases. Adjustments have not been made on the systems and databases themselves. It is the SOA that makes communication between services possible, which is indicated in the figure by the structure of the connection. The structuring of the services also indicates the loosely coupled character as being part of a SOA. Furthermore, the figure shows that new innovative systems as FLIWAS can be integrated into the technical architecture. To keep sufficient overview, the figure does not identify the grouping into different domains, as not all the systems and databases are displayed. The service architecture is composed of the leveled structure, in agreement with the chosen routers approach. This is represented by the service routers and service domain routers situated in the GMS. The two-level structure makes it possible that decisions concerning coordination, cooperation monitoring, conformance and quality of service composition can be made at the service routing level, rather than for each individual service. The application architecture is presented by the two layered structure. On the one hand there is the voice layer, which functions the same as in the present situation. The Data Communication Server provides the necessary functions for proper operation. The second layer is the data layer, which is based on the entrance via a web-based portal. The portal is manifested by web services, using SOAP calls carrying XML data content. The portal is supported by a Web Server, which provides the necessary content and functions for the portal to operate. 10.3.1Improvements The implementation of a SOA approach into the GMS system clearly provides a more decentralized situation of the information provision. The developed concept gives a relief worker the opportunity to not only receive core information content via direct contact with an emergency room operator, but also more interactive content via a data channel. This decentralized approach concerning the information provision offers two major improvements: 72

SPM4910 – SEPAM Design Project (ICT) – Final Report

− −

A more efficient calamity control, due to saving time by less communication and workload considering the emergency rooms A more effective calamity control, due to less misunderstanding and misinterpretation concerning the communication of information that is nonconvenient as voice communication.

Another improvement of the WebGMS is that a division can be made in push- and pull based information. Push based information will be provided in a standardized format by the GMS. The GMS has the possibility to select the users that will receive a particular message. For example, medical information on the type of casualties can be directly sent to GHOR-Service clients and required evacuation capacity to the police department. Pull based information is demarcated by the options available in the interface’s options menu (see section 10.4). This information to be collected can thereby be of such a type, which in the current situation is not possible to obtain. Information in the appearance of figures, plans, pictures and even streaming video can be possible. Take here in consideration that the technique is able to deliver the required systems and facilities.

SPM4910 – SEPAM Design Project (ICT) – Final Report

73

10.3.2User interaction An element that has been left quite underexposed is the interaction of the service clients with the portal. In this section, a short analysis with regard to the user interaction will be performed, by making use of Unified Modelling Language (UML) diagrams. UML is designed to let service providers and service clients view a software system from a different perspective and in varying degrees of abstraction (Kar and Verbraeck, 2005). UML diagrams can be a very helpful in defining the technical part of a service system. UML provides two sorts of diagrams that are best suited to generate insight on the interaction of the relief services with the portal. A use case diagram is used to display the relationship among actors and use cases. A sequence diagram displays the time sequence of the objects participating in the interaction (Kar and Verbraeck, 2005). The use case by means of the interaction with the WebGMS is sketched in Figure 18. It displays an overview on which activities and processes are present. It starts when a relief worker turns on his device and automatically logs in onto the central system (CMS). The operators in the emergency rooms divide the logged in relief workers into groups based on the situation and personal authority level. When the relief worker feels the need for information, he browses on his device to the GMS portal. As defined earlier, the portal is supported by a web server, which provides the necessary functions. On the portal the relief worker selects the required information source and searches for the necessary information. When the required information has been found the relief worker will use this according to his personal purpose.

SPM4910 – SEPAM Design Project (ICT) – Final Report

74

Figure 18 – Use case diagram of the user interaction with the GMS system via the portal.

To see how such a chain of activities is technically accomplished, Figure 19 sketches a sequence diagram. As stated such a diagram focuses on the time sequence of operations. The sequence diagram exposes the required involved objects and the communication between them. The log in to the CMS system is indicated. Furthermore, the interaction of the relief worker with the GMS portal is indicated for the data streams that are necessary to display the portal and to search information on the different information systems.

SPM4910 – SEPAM Design Project (ICT) – Final Report

75

Figure 19 – Sequence diagram of the user interaction with the GMS system via the portal.

10.4Interface
Agreements will have to be made on the design of the interface. Points of attention here are the type of menu, the method of establishing a connection, a clear listing of the local responsibility chart, etc. The application should not be too extensive, and should ensure the device is easy to handle in crisis situations. In other words, the number of questions and terms in information provision will have to be limited. This is necessary to avoid ambiguousness and vagueness in information streams. To ensure that the available options are sufficient and complete, the following arrangements will have to be set: - The GMS will send a standardized template to all end users involved in the calamity. This template customized on the basis of the user’s place in the hierarchy, and his tasks and responsibilities. Every template is specifically constructed for the calamity at hand, and can even be specified for the stage the calamity is in. The characteristics of the template makes generic applications possible. In other words, a template for a water calamity, a terrorist attack, a fire calamity, etc. can be developed. A distinction in templates will also be made for each phase of the emergency (monitoring, scale-up, evacuation phase, flood and return). To avoid misunderstandings and delays the interface will contain an options menu. There is a limited amount of information/options/domains on the templates to enable transparency and usability. In Appendix XV a more elaborate list of the information structure can be found.

SPM4910 – SEPAM Design Project (ICT) – Final Report

76

Figure 18 provides an example of a possible interface for a police agent during an evacuation in a water calamity.6 In the figure the following components are visible: - Main; the user can go to main menu, with an overview of the options and basic things like placing a reaction, consult his personal to-do list, or notify colleagues, subordinates or superiors. Also information on working schedules can be read here. - Tasks, Responsibilities and Law (TRL); there is a list with responsibilities and tasks, generic and specific for the user, including the time sent and urgency level. The user can consult this also when there is uncertainty regarding the legal basis of actions, or about the manner in which to act. By touching a certain task, the user can see the specifications of that certain task. It can then choose to add the task to his to-do list or not. - Map; the user can access a map, on which not only information is put regarding traffic flows, but also on the evacuation area (numbers of persons left, location, etc.). Through different buttons the user can let the map show different types of information on the map, and can choose which information will apply to him or her. - News bar; a news bar shows current developments on water levels, status of evacuation, and other interesting subjects.

ns missing --- More rain tomorrow --- Heavy congestion towar

Main
T
12.28 12.04 11.45 11.40 11.22 ! !!

TRL Map
R

User: 1052381 Phase: E 12.35, 06/06/06

L

Looting shopping centre ‘ de Vijfhoek’… Evacuation of the following streets: Handboogstraat, I… Resistance inhabitants of Klinkerweg 5: 3 agents ar… Traffic diversion: In the northern part of Oss. P… Protection of special objects: In the centre…

Looting
Sender : Type: Specs:

Shopping centre ‘de Vijfhoek’, location

Commander Surie Order /Personal Immediate assistance required in order to restore and maintain peace at shopping centre . You have to check in at group 3, Lieutenant Schipper , on the corner of Lage rweijweg and Klapperdijk before 13.00

Figure 18 - WebGMS template

6

This example is solely given to give the reader a broad idea of the requirements of a GMS template. It is recommendable to perform further research on the user-friendliness, flexibility and entities that should be included in such a template.

SPM4910 – SEPAM Design Project (ICT) – Final Report

77

11.Institutional design
The institutional design of the WebGMS (WGMS) will elaborate on the four layer model discussed in chapter 6. The formal tasks and responsibilities will be respected by the new system as drawn up in the different calamity plans (layer 3). Moreover, no other organizations will be involved in the new system design than Dutch organizations (layer 4). Thus, the new system builds upon the top layers of the four layer model and will be designed to tackle the problems that have arisen in layers 1 and 2. Shortly, there were two main institutional problems: • • Adaptation of the communication system Special attention is needed here for a uniform usage of the C2000 system, along with communication protocols and codes Internal cultural differences between relief services (or all actors involved?) Cultural differences are currently likely to cause vagueness between relief services, as a result of a different use of terms and standards. The design proposal seems to be suitable to seize this problem.

11.1Theory on institutional design
Before implementing the institutional design, it is of importance to treat a few relevant theoretical subjects. Firstly, some important institutional design principles are introduced. Then, some elaboration is given on the implementation challenges of an institutional design. 11.1.1Design principles The principles behind a government’s approach to an institutional design are credibility, flexibility and democratic legitimacy (O’Donnell & Bhundia, 2001). Credibility in institutional design implies a high degree of transparency. All institutions involved in the process should be able to have an overview of the events occurring during a calamity. Moreover, transparency gives structure to accountability, so that possible sanctions can be justly allotted. Flexibility gives the policy maker the ability to react sensibly to unexpected events. Obviously, the chance of such events occurring in a water calamity is very high and thus is very relevant for the institutional design. Finally, democratic legitimacy is important, because policy should reflect a consensus among all actors involved. This implies a supportive policy, regulatory, and legal environment. Suberu and Diamond (1999) argue that important characteristics of legitimacy are fairness, probity, a rule of law and (again) transparency. For the development of the WGMS, some case specific design principles should be taken into account. In the first place, it is essential that the WGMS to function properly at all times. Therefore, institutional arrangements should be set to insure the reliability of the system. A second case-specific design principle is scalability. The WGMS should be able to run on a large scale of different systems, regardless of the magnitude of the water calamity. 11.1.2Implementation challenges in institutional design The latter leads to another important aspect in the institutional design: norms and values. Understanding norms and values is part of institutional analysis (Ostrom et al., 1993) and reaching consensus is very dependent on the way that is dealt with them. It is to be expected that a fireman uses different terms for a particular situation than a government official. Moreover, the way actors deal with each other in their own communities can highly differ from other communities. In any case, it will be essential for all actors using the system to understand the information provided by each other. Consequentially, conflicts over changing the way actors should present their information and thus their social norms (Knight and Ensminger, 1998) could arise, hampering the effectiveness of the institutional

SPM4910 – SEPAM Design Project (ICT) – Final Report

78

design. Prescribing all actors one single form of presenting their information could be problematic. The central point of attention here is to clarify the usefulness of the institutional change in the process design (chapter 9), and provide the insight that it is crucial to solidify change over time through efforts of enforcement. Etzioni (1993) stresses that quantifying the amount of time needed for this change is crucial for bringing the transition into perspective. The change to the WGMS system will require an enormous amount of effort (and thus time) from many people, whom all have their own interests. One of the major lessons in the analysis of institutional change is specifying the details of the situation that is being analyzed (Feeny, 1993). This should be taken into account when bringing in particular segments of the institutional design: this implicates the need for a clear overview of the time sequence of institutional changes.

11.2Institutional arrangements
The design principles described above form a good foundation for the institutional design. It is now of importance to link these principles to the institutional requirements of the WGMS. Thus, the requirements identified in chapter 8 should be translated to institutional arrangements. Institutional arrangements inform decision makers about their standing and about the consequences of their behaviour (Feeny, 1993). The theory as discussed above tells us “how” to make an institutional design. When deciding on “what” to design, the process design could be of good use. To create a clear overview of these institutional arrangements, they can be categorized according to their characteristics. The system designer first has to wait until the actors have made their decisions as described in the five rounds (chapter 9). With that output the designer can make the last design decisions and start to build some prototypes. The following paragraphs have the same structure. Firstly, choices for substantial design issues as discerned in the process design are made, by filling in the outcome of the four clusters, as identified in round three of the process design (chapter 9). For every cluster, the most important institutional arrangements are discussed. After that, the remaining design choices are summed up, along with their necessary institutional arrangements. 11.2.1Compatibility with other systems The systems connected to the GMS are described in the previous chapter. Obviously, the information that should be linked to the system is dependent on the location of the water calamity. For example, a water calamity that occurs in the Beersche Overlaat will require the databases or systems of the local water district boards, municipalities such as Cuijk, Den Bosch, Oss and Grave along with their local relief services.7 Database and System incorporation A first important institutional requirement concerned the system accessibility. The service oriented architecture makes it relatively easy for the local (information) databases and -systems to connect to the WGMS: the decision on which systems should be incorporated is dependent on decisions of BZK. A guideline should be readily available for actors that would like to link their systems or databases to the WGMS. This implies that all actors should be made aware of these guidelines and can easily obtain them, through, for example, the internet. Information processing system

7

This also occurred in the Helga exercise; all local authorities had connected their information systems and -databases to the GMS

SPM4910 – SEPAM Design Project (ICT) – Final Report

79

It is to be expected that during a water calamity the information load varies considerably. In times of a high information load, effective information management is essential. Due to the lack of time in calamity situations, it is not desirable to require a high information load to be processed by the operation teams in the lowest level of the hierarchy. These teams simply do not possess the capacity to occupy themselves with processing new information and need operational flexibility. Preferably, they are provided with short and clear messages, containing all the necessary information they need. Thus, the processing of information should be allocated in the emergency room of the GMS. It is to be expected that information arriving at the emergency room from external resources (e.g. which are not connected to the WebGMS) will have to undergo some formatting. This calls for an information filtering system to be attached to WGMS. Such a system should offer the emergency room the possibility to effectively filter and translate new information to understandable messages that can be forwarded to the field. 11.2.2Standards and Semantics A first important aspect is to agree on the content of the new system. It will be desirable to develop one universal interface which can be operated as simple as possible. Institutional arrangements will have to be set on: Standards To ensure a high level of transparency, all ambiguities will have to be eliminated. It will be important for all relief services to adequately instruct their employees on the use of the new WGMS. This implies that the information provided to all users of the WGMS should be in an understandable and preferably unique format. All Service clients will have to accept on single information standard, protocol and codes, as described in chapter 9. The standards that will be used for this system are listed below in Table 5.
Table 5 – Technical standards used for WGMS

Technical standards SOAP XML UDDI WSDL -

Network C2000 standard IEEE 802.11 (LAN)

Semantics: all actors will have to agree on the semantics used. As all possibilities to ambiguities of vagueness within the system should be prevented, the terms used will have to be incorporated into the WGMS. An important requirement here is that all terms should be recognized by everyone involved at all times. Cultural differences will likely cause a discussion on this subject, as terms used by one actor often differ from those used by the other. The range of terms that can be taken up in the WGMS is obviously limited. Thus, agreements should be made on the selection of the terms used in a water calamity. Preferably, the ministry of BZK will give orders to create a database for water calamity terms

11.2.3External systems and security As the overview of the technical design shows (Figure 17, chapter 10), the decision is made not to couple the WGMS directly to external systems like the internet. By keeping the WGMS a relatively isolated system, possible problems with security can effectively be avoided. Security measures include:

SPM4910 – SEPAM Design Project (ICT) – Final Report

80

-

-

-

The control room will be the interconnection point with the outer world. C2000 users will still be able to receive information from external sources, with the help of the control room. When a question cannot be answered by the WGMS, the control room could search the answer through for example the Internet. The connection of the WGMS with the internet is protected with a firewall. Because these internet information requests require more time and effort than internal database information requests do, the number of internet information requests made by relief workers must be as low as possible. They may only be used when no other way of receiving this information is available. Relief workers have their own personal login name when they are active in the field. Every message sent is tagged with a personal user ID. Relief workers are obliged to formulate their questions short and clear. They also need to specify the kind of answer they want to receive from the control room (numbers, pictures, or descriptions for example). Within the GMS these internet information requests have no priority, except for the ones with a high-priority label. A link to external systems could also be used to inform civilians. In the current situation, the Calamity Policy Team is responsible for communication with civilians through the media (see Chapter 3). A direct information connection between civilians and the information system might reduce the workload of this team, but also means an increasing need for security. On top of that, the added value for civilians is debatable. For this reason, no such link is available in the WGMS.

11.2.4Responsibilities and authorization - Supervision The responsibility for the WGMS will be allocated to a specific actor, the Service operator. This actor, preferably consisting of several specialists, has the main task to control all information streams during a calamity and to distribute responsibilities. Furthermore, the Service operator will have to be educated on how to use the system. All actions that can be undertaken by these supervisors will have to be identified. As can be derived from the technical design in chapter 10, the service operator is responsible for: o Assurance of the system: This implies that the Service operator constantly monitors the status of all connections and checks the functioning of the system. To achieve this, the Service operator should be provided with a clear interface. Aggregation The one responsible for aggregation is the Service aggregator. This actor has four main tasks: o Coordination: this concerns controlling the system. General requirements here are database and external system coordination, management of information flows, and supervision of the output of the system. o Conformance: the integrity of the system should be insured. No data may be lost or accidentally be made available to unauthorized parties. o Monitoring: this implies the monitoring of the information content itself. Information data provided by the available databases should be provided at higher level composite events. In other words, by filtering, summarizing and correlating information, complexity is reduced and a clear interface can be ensured. o Quality of service (QoS): this task includes the leveraging, aggregation, and bundling of particular database QoS levels to derive the composite QoS of the WGMS, including performance, privacy, integrity, availability Interaction between actors

-

SPM4910 – SEPAM Design Project (ICT) – Final Report

81

The service provider will have to guarantee the functioning of the underlying infrastructure at all times, ensuring a reliable SOA, on top of the C2000 system. Furthermore, the service clients should be able to rely on the functioning of the WGMS. o Support: In case of malfunctioning or failure of the WGMS, immediate support form the service provider is necessary. Therefore, the Service operator will have to maintain an active link with the Service provider when the system is active. Accordingly, support should be offered to the Service Clients if they encounter problems with WGMS. o List of contact actions: If any problems occur while using WGMS, the Service operator is the one responsible for solving the problems. Thus, the Service client should always be able to contact the Service operator if the system does not function properly. However, clear rules should be set on when a Service Client should contact the Service Provider. It will obviously be undesirable if the Service Provider is contacted for minor issues. This is likely to cause congestion and inefficient communication, something that the WGMS is trying to avoid. Thus, a plan of action should be drawn up to avoid this. The order of contact actions can be fixed as shown in Figure 20.

Relief worker

2. Colleague relief worker

3. Direct superior

4. Coordinating superior

5. Service operator

Figure 20 - Order of contact actions when encountering problems with WebGMS.

-

Authorization level Another important aspect in the setting of institutional arrangements is the determination of the authorization levels. It is to be expected that owners of databases will not want to share all the information they possess. Moreover, not all information will be relevant to everybody in a crisis situation. Therefore, arrangements will have to be set in order to obtain some structure in information sharing. Agreements will have to be made on the following: o The information that should be directly available to the relief services: o The allocation of authorities is expected to be the responsibility of the emergency rooms. Moreover, research will have to be done how this authorization allocation can be efficiently digitalized, to increase reactivity and reliability. Responsibility allocation Critical in the implementation of authorization levels is that the decisions and necessary actions should only be visible for the people that are responsible for them. The emergency rooms will possess all the necessary calamity plans of the different actors involved. After linking these plans to each other, an Operation Responsibility Scheme (ORS) will be drawn up. The emergency room operators send the ORS to all superiors in a bulk message to the C2000 system, to create an immediate overview

-

SPM4910 – SEPAM Design Project (ICT) – Final Report

82

of the operation teams position, required actions and the location of colleague operation teams (see Figure 21).

GMS Control room Authorizations and Responsibilities (ORS)

Chief of Fire Department

Police Chief

GHOR Superior

Superiors

Responsibilities

Responsibilities

Responsibilities

Fireman

Fireman

Police officer

Police officer

Medic

Medic

Relief Workers

Fireman

Fireman

Medic Police officer Police officer Medic

Figure 21 - Authorization and responsibility allocation.

11.2.5Costs and responsibilities The divisions in costs and responsibilities for the WGMS project were made using information from the C2000 project, because both projects show many similarities. The main difference between the C2000 and WGMS divisions can be derived from the difference in scope of the projects. Where C2000 concerned a national project, WGMS will be set up as a regional project (with optional expansion to other regions). This means that only citizens and relief workers from the concerning regions will profit from the newly implemented system. As a result, a shift in costs and responsibilities from central to local governments will have to be made. Since WGMS is web-based, expansion to other regions or external systems is relatively easy. When WGMS turns out to be a success, other regions may decide to implement WGMS as well. One can imagine that in that case it seems a bit unfair that the local governments who implemented WGMS first have to deal with specific initial problems where the other, secondphase, local governments don’t have to face these problems and costs. To meet these firstphase regions, second-phase regions need to pay a certain (pre-determined) share to them when deciding to use the WGMS technology. - Project costs Table 6 gives a short overview (based on Appendix XIII) of the proportions the different actors had to pay considering the C2000 project. To give a clear overview of the costs division the choice is made to work with percentages. A cost allocation for the Web GMS project is made based on the C2000 information. Differences between them can be found in the following decisions: o The Web GMS project will only be carried out in one region. For this reason, the percentage the Ministry of BZK has to pay is smaller in comparison with the C2000 project, which is available for all regions. BZK will pay 75% of the investment costs. o Since Web GMS only deals with water calamities, the project is of less relevance for the military police (KMAR). They did not participate in the design process and there is no need for them to share in the costs for this project. 83

SPM4910 – SEPAM Design Project (ICT) – Final Report

The emphasis on water calamities also implies more needed functionality for the fire department compared to the First Aid Services. In contradiction with the C2000 division, for WGMS the share the fire department has to pay will be equal with that of the police department. A division of exploitation costs is given. This division could change when after some time a different user pattern can be seen than assumed (based on measurements of the frequency of use by the different services). This system of “second cost calculation” is also used by the C2000 project developers. o
Table 6 - Cost division C2000 and Web GMS.

C2000 Investment costs BZK regions Exploitation costs BZK Police dept. Fire dept. FAS KMAR

75% 25% 100% 23% 49% 14% 10% 4% 100%

Web GMS Investment costs BZK regions Exploitation costs BZK Police dept. Fire dept. FAS KMAR Water boards

75% 25% 100% 0% 40% 30% 20% 0% 10% 100%

-

Project responsibilities

Table 7 - Division of project responsibilities. Actors Responsibilities BZK (including VWS and - Project organisation Defence) - Support regions - Connection with central systems and GMS - Provide project information - Security Regions (Emergency - System Services and local implementation governments) - Equipment purchase - Local maintenance - Training - Education - Spatial coverage planning - Pilot project (optional) Project developer - Infrastructure realisation - Central project coordination - Project guidance - Implementation support

SPM4910 – SEPAM Design Project (ICT) – Final Report

84

Table 7 is taken from the process design (chapter 9) and filled in for WebGMS. Choices were made about the following topics: o Although WGMS is set up for regional use it is connected with central used systems also. When security fails, this will be a central problem. For this reason, expertise from central level will be used to protect WGMS against external threats. o BZK might decide to offer local governments loans to realize this project on time. Contrary to the C2000 project, interest will be brought into account to keep the principle of equality of regions. o As pointed out by the costs divisions, Web GMS is set up as a regional project. The local governments will be responsible for a great deal of the implementation. Typical tasks like the equipment purchase, training and education of (local) relief workers are added to their list of responsibilities. o The local governments may decide whether they want to implement a pilot project or not. When they choose to do so, they are responsible for the implementation of it. Appendix XIV provides a clear overview of the connection between the relevant institutional theories (identified in section 11.1), and the institutional arrangements defined in section 11.2.

SPM4910 – SEPAM Design Project (ICT) – Final Report

85

12.Conclusions and Recommendations
The extensive analysis performed on the subject of information management before and during a flood calamity came up with some interesting conclusions. These conclusions are mainly covered by the design provided by the second part of the report (see Table 8). Table 8 - initial problems solved with WebGMS Current situation WebGMS Technical Voice based (no possibility to exchange maps Data- and voice based. Exchange of short and photo’s) text messages, maps and photos is possible. Centralised character (all communication via Hybrid between centralised and GMS causes a heavy workload) decentralised character (communication via WebGMS spares GMS) No interconnection standards Web-based Long (communication) connections Shorter (communication) connections (timeefficient) Institutional No clear semantics Central determined semantics Minimal involvement of operational services Better involvement of operational services Push-based provision of information Hybrid between pull- and push based (including unnecessary information) information (more secure information provision possible) Inflexible use of information systems Loosely coupled information systems (higher flexibility) Ineffective for non standardised information Ability to deal with non-standardised information Static emergency plans Dynamic, interactive emergency plans No clear information structuring Template based information provision Information allocation based on groups Information allocation based on individuals Most of the identified problems are solved by implementing WebGMS. Although WebGMS covers most of the technical problems and can be seen as a technical optimal solution, it must be said that some institutional problems were more difficult to solve. The cultural difference between the different emergency services (as described in the institutional analysis) is an aspect that needs more attention. The use of generic semantics may be onestep towards better collaboration, but cannot be solved within the process design of one project. Recommendations When the Ministry of BZK and the regions start with the implementation of WebGMS, they should consider taking the following recommendations into account: The Web GMS should be coupled to the existing Fliwas system The Web GMS could form the basis for a general calamity control and information system The Web GMS could be coupled to international systems BZK should set up a central database on semantics BZK should secure cooperation, coordination and communication among the relief services Security issues should be subject of a follow-up research Once the system is implemented a second cost calculation should be executed

SPM4910 – SEPAM Design Project (ICT) – Final Report

86

References
Books
Bruijn, H. de, E. Ten Heuvelhof and R. In ’t Veld, Process Management – Why project management fails in complex decision making processes. Boston: Kluwer Academic Publishers, 2002. Kar, E. and Verbraeck, A., Design of smart mobile service systems. Delft: Delft University of Technology, Faculty of Technology, Policy and Management, 2005. O’Donnell, G. & Bhundia, A., Institute for Fiscal Studies, UK Policy Coordination: The Importance of Institutional Design, 2001. Suberu, R. and Diamond, L., Institutional design, ethnic conflict-management and democracy in Nigeria, 1999.

Papers and articles
Datz, T., What You Need to Know About Service-Oriented Architecture. CIO, January 2004. Etzioni, A., A socio-economic perspective on friction. Institutional change, theory and empirical findings, Sven-Erik Sjostrand (1993), pp.46-60 Feeney, D., The demand for and supply of institutional arrangements. Rethinking institutional analysis and development, ICS Press (1993), pp.160-209 International Commission for the Hydrology of the Rhine Basin, Developing the FLIWAS system and the HNV (HIS/NOAH/Viking) project, 2006. In: CHR workshop; Ensemble predictions and uncertainties in flood forecasting, Bern, Switzerland, 30 and 31 March, 2006. Knight, J. and Ensminger, J., Conflict over changing social norms: Bargaining, Ideology and Enforcement. In: Brinton, M.C. and Nee, V., The new institutionalism in sociology, pp.105-126. New York: Russell Sage Foundation, 1998. Koppenjan, J.F.M., Besluitvorming als strategisch spel, internal document, Delft University of Technology, (2004), pp. 1-24 Koppenjan, J.F.M. and Groenewegen, J., Insitutional design for complex technological systems. Delft: article for spm4410, 2005. Meijer, A., Hele regio over op C2000. In: Sitrap, Volume 4. April, 2004. Muller, E.R., Beslissen van routine naar crisis, in: P. ‘t Hart en U. Rosenthal (redactie), Kritieke momenten, Arnhem, 1990, pp. 23-41. Nadhan, E.G., Service Oriented Architecture Implementation Challenges: Ensure success by building and following a road map that incorporates enterprise-specific standards. Electronic Data Systems Cooperation. 2003. NRC, Communicatie nog steeds achilleshiel bij grote ramp. The Hague: NRC, July 30, 2005a, p.2.

SPM4910 – SEPAM Design Project (ICT) – Final Report

87

NRC, Eindverslag: Het Nationaal Congres Rampencoordinatie 2005. The Hague: NRC, 2005b. NRC, Invoering C2000 verloopt moeizaam. The Hague: NRC, June 15, 2004. Ostrom, V., Feeny, D. and Picht, H., Institutional analysis and development. Rethinking institutional analysis and development, ICS Press (1993), pp. 439-466 Papazoglou, M.P. and Georgakopoulos, D., Service-Oriented Computing. In: Communications of the ACM, Vol. 46, No. 10, October 2003. Parool, Politie verraadt zichzelf. In: Parool, September 2, 2004, p.5. Scott, W.R., Institutions and Organizations. Sage Publications (1995), pp.66-78 Sprott, D and Wilkes, L., Understanding Service-Oriented Architecture. On: CBDI Forum, January 2004. STOWA, Berichtenspecificatie HoogwaterRapport, No.1, (2005), p.11-16, Utrecht. STOWA, Quickscan informatiemodellen AQUO en IMRA v3, (2004), p.7-10, Utrecht. Trouw, C2000 werkt niet goed genoeg maar er is geen weg terug. In: Trouw, June 15, 2004a. Trouw, Veiligheid moet bij C2000 vooropstaan. Trouw, May 19 (2004b), pp. 14.

Websites
Ambucom, Communication with Ambucom. 2005. June 9 2006. http://www.prometheus.nl/producten/ambucom/abc_concept_ambucom.htm. ETSI, TETRA. February, 2006. March 1, 2006. http://portal.etsi.org/radio/TETRA/tetra.asp. FLIWAS, FLIWAS Newsletter 1. 2006 June 9, 2006. www.noah-interreg.net HIS / NOAH gebruikersdag: functionaliteit en implementatie van FLIWAS 16 maart 2005 June 9, 2006. www.hisinfo.nl Overmars, J.M.S., InformatieStromenAudit, Verbetering Informatievoorziening Rampenbestrijding bij Hoogwater In Nordrhein-Westfalen en Gelderland. Prov. Gelderland, Oktober 2004 Ministry of BZK, C2000 Communicatie. January, 2004b. June 9, 2006. www.c2000.nl Ministry of BZK, C2000 uw nieuwe communicatiesysteem. June, 2004a. June 9, 2006. www.c2000.nl Ministry of BZK, De communicatiestandaard (TETRA). March, 2006a. June 9, 2006. www.c2000.nl Ministry of BZK, ministry of BZK website. 2006.

SPM4910 – SEPAM Design Project (ICT) – Final Report

88

June 9, 2006. www.minbzk.nl. Ministry of BZK, Stroomschema. March, 2006b. June 9, 2006. www.c2000.nl Ministry of VWS, Ministry of VWS Website. 2006. June 9, 2006. www.verkeerenwaterstaat.nl. Motorola, Motorola verkoopt meer dan 20.000 TETRA portofoons aan Politie, Brandweer en Ambulance diensten in Nederland. October, 2004a. June 9, 2006. www.motorola.com Motorola, MTP700 brochure. 2001. June 9, 2006. www.motorola.com Motorola, Scotland Votes for the Motorola MTH800 Terminal. April 2004b. June 9, 2006. www.motorola.com Pieters, R., Regional Alarmcentrale Utrecht; Onderdeel van de GMU. 2005. June 9, 2006. http://www.rwpieters.nl/brwutr/gmu.html. SMVP, De gescheiden werelden van brandweer en politie. 2004. March 16, 2006. http://www.smvp.nl/main.htm

Governmental documents
ACIR, De Vrijblijvendheid Voorbij. The Hague: Ministry of BZK, 2005. AVD-SAVE-NIvU-Nibra, Leidraad Operationele Prestaties. The Hague: Ministry of BZK, 2001. Algemeen Doorlichtingsinstrument, Modelscenario ontruimen en evacueren, conceptversie 2.0 Deloitte Accountants BV, 7e voortgangsrapportage project C2000.. The Hague: Ministry of BZK, September 2005. Directoraat Generaal Water, Onderzoek voor rampenbeheersingsstrategie Rijn en Maas. The Hague: 2005. Handboek Rampenbestrijding, deel B3 – Processen, p.47, juni 2002 Handboek Voorbereiding Rampenbestrijding, deel C3 – p. 3, juni 2002 Helsloot, I., Schaap, S.D & Bos, J.G.H., Goed toezicht is van iedereen; een onderzoek naar het toezichtstelsel binnen het domein openbare orde en veiligheid, uitgevoerd door het COT instituut voor veiligheids- en crisismanagement. The Hague: Ministry of BZK, Public order and safety inspection and COT institute for Safety and crisis management, December 2004. June 9, 2006. http://www.ioov.nl/contents/pages/10900/2004120605ioovtoezichtbwint.pdf Ingenieurs/Adviesbureau SAVE & Adviesbureau Van Dijke, Leidraad Maatramp. The Hague: Ministry of BZK, 2000.

SPM4910 – SEPAM Design Project (ICT) – Final Report

89

Kabinet, PKB Ruimte voor de Rivier – deel 1. in: Ontwerp Planologische Kernbeslissing. The Hague: Ministry of VWS, 2005. Ministry of BZK - De Projectdirectie C2000, C2000 uw nieuwe communicatiesysteem. The Hague: Ministerie van Binnenlandse Zaken en Koninkrijk relaties, 2004. Ministry of BZK - De Projectdirectie C2000, Maatwerk in Communicatie. The Hague: Ministerie van Binnenlandse Zaken en Koninkrijk relaties, 1998. Ministry of BZK - Inspectie Brandweerzorg en Rampenbestrijding, Melding en opschaling, informatie en communicatie bij acute rampen. 2001. Projectteam Borging Leerervaringen Bonfire, Verslag Regionale Bijeenkomsten Borging Leerervaringen Bonfire. The Hague: Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Directoraat-generaal Veiligheid, directie Crisisbeheersing, 2006. Royal Haskoning, Meulenpas, G.J. & de Klerk, A., Redesign operationeel deel HIS – Basisontwerp, versie 4.0, RWS Dienst Weg- en Waterbouw. The Hague: September 15, 2004. Van Dijk, W., Waterschap Zuiderzeeland “Calamiteitenplan 2005” . 2005. Waterschap Zuiderzeeland, Calamiteitenplan 2005. 2005. Waterschap Zeeuwse Eilanden,“Calamiteitenplan 2004, 2005” . 2004. Waterschap Groot Salland, “Calamiteitenzorgsysteem”. 2002.

SPM4910 – SEPAM Design Project (ICT) – Final Report

90

Appendices Appendix I - Goal oriented analysis
Maximum security

Maximum prevention

Maximum repression

Maximum care after incident

Maximum application of relief services

Good repression preparation

Good communication

Good coordination

Good cooperation

Good training and excercises

Unambiguous responsibilities and tasks

Good operational planning

Maximum technical performance
* coverage (%) * availability (breakdown minutes / year)

Maximum approachability relief workers

Unambiguous information streams and resources
* Perception of the users on a scale from 1 to 10 * # of unnecessary information streams / year

Unambiguous semantics

Unity in culture, norms and values
Perception of the users on a scale from 1 to 10

Maximum willingness to cooperate
Perception of the users on a scale from 1 to 10

# of denied requests / year

# of used communication protocols

Figure I.1 – Model tree as formulated considering the current situation.

SPM4910 – SEPAM Design Project (ICT) - Appendix

91

Appendix II - Actor analysis
II.1 Inventory of the actors
Below all actors that are involved in during a flood or water calamity are listed. The purpose of this list is to get an idea of the different people involved. With this information, a selection can be made of the most important actors for the problem area. Private organizations: • System builder • Communication companies • Agriculture industry (Farmers) • Industry • Small and medium sized enterprises • Logistics companies • Insurance companies • Private owners of (large) public areas Government authorities: • Ministry of BZK (BZK) • International Maas Commission (IMC) → consists of following working groups; Physical-chemical, Ecology, Hydrology/high-water, GIS, Economies, Taxes, Groundwater, Monitoring en Coordination • European Union (EU) • Ministry of VWS (V&W) • Royal Dutch Meteorological Institute (Koninklijk Nederlands Meteorologisch Instituut - KNMI) • Ministry of Housing, Spatial planning and the Environment (VROM) • Ministry of Agriculture, Nature and Food quality (LNV) • Provinces • Water authority (Rijkswaterstaat) • International authorities (option 1) • Local governments (f.e.: Beersche Overlaat (BO) protects Den Bosch, Cuijk, Oss and Grave) • Local governments (f.e.: Beersche Overlaat (Area BO includes the municipalities Cuijk, Grave, Landerd, Ravenstein, Oss, Lith and Maasdonk) Emergency services: • Police department • Fire department • Ambulance department • Military Police (Marechaussee) • Army Social organisations: • Environmental organisations • Inhabitant organisations • Consumer organisations • Political parties • Monument organisations Unorganised stakeholders: • Animals • Tourists

SPM4910 – SEPAM Design Project (ICT) - Appendix

92

II.2 Actor analysis
In this analysis, the actors most important in case of a water calamity have been selected. To make this selection we kept in mind that this report focuses on the organisation and communication needed to fight water calamities. This results in more relevant actors on the governments and relief service side and less relevant actors in the private and social organisations part. Although these parties won’t be taken further into account in this chapter, it’s good to identify them and deal with them in our process design. The selected actors have been scanned for their interests, goals, and influencing possibilities. Furthermore, their attitude towards the problem area has been analyzed, as well as the possible causes they ascribe to the problem area.
Table II.1 – Actor analysis.

Actor Ministry of Interior and Kingdom relations (BZK)

Interests Responsible for the formulation of policy, preparation of legislation and regulations, and the coordination, supervision and policy implementation. (Source:http://www.minbzk.nl /uk/organisation)

Goals • Provide a situation in which emergency services perform in an optimal way. Provide an infrastructure that offers optimal communication possibilities. Provide an insight in how the different organizations are occupied with prevention, limitation and repression of water flooding and what improvements can be made to ensure a more effective calamity repression program. (Source: De organisatorische voorbereiding op overstromingen van Rijn en Maas, 2005)

Core problem • The current firmed agreements do not suffice to the standard that’s needed. The communication system is not capable in providing optimal cooperation between the different emergency services.

Causes • • • Preparation for water calamities could be better No clear allocation of responsibilities Inadequate processes during calamities: namely evacuation, information provision and communication/ information exchange between all operational services Lack of availability of people and material

Influence possibilities • Management of governmental authorities on a local level

SPM4910 – SEPAM Design Project (ICT) - Appendix

93

Actor Police department

Interests To reduce crime, tackle antisocial behavior in public spaces and properly enforce and implement anti-crime measures (Blok, 2004:8).

Goals - to establish a more homogeneous communication infrastructure for the police – to introduce a set of basic (upgraded) applications for all police forces” (Blok, 2004:21)

Core problem • The police department cannot function optimal during severe situations, due to a bad performance of existing communication systems (C2000).

Causes technical • Insufficient signal receiving (Parool, 2004a:5) • System supply failures (Trouw, 2004b:14) • Problems with the software and data storage capacity (Trouw, 2004b:14) institutional • lack of confidence in the system by users (NRC, 2004a:2) • Insufficient knowledge how to use the system (NRC Handelsblad, 2004a:2). • Responsibilities are unclear (NRC Handelsblad, 2004a:2) • No or bad coverage in covered places, such as shopping centres • Interference with medical instruments

Influence possibilities • Boycott of the existing system (Trouw, 2004a:5) • Attempts to avoid the use of a technical communication system. • Relief Support

First Medical Services

Aid

Achieve individual gain of health based on the need for care of the patient; prevent mortality and affect morbidity positively, possibly refer patients to care institute for continuation treatment (Nota verantwoorde Ambulancezorg, 2003:6)

• •

To be able to contact emergency room To be able to contact other emergency services and colleagues, also internationally

Inability to contact colleagues and emergency room, bad coverage Medical instruments malfunction

• • •

Power within Ministry of BZK Feedback Relief Support

SPM4910 – SEPAM Design Project (ICT) - Appendix

94

Actor Fire Department

Interests Prevent, restrict and fight fire, restrict flammability, prevent and restrict accidents in case of fire; restrict and fight danger for humans and animals in general; restrict and fight calamities (brandweerwet 1985, brandweer.nl)

Goals • • To be able to contact emergency room Shared emergency room system with a up-to-date connection network considering the calamity services Improve communication among different (regional) fire departments Eventually communicate/ corporate international Besides verbal communication also exchange of images and computer data Establishment and effective execution of the Calamity Plan

Core problem • Inability to contact colleagues and emergency room, causing lack of information, due to bad coverage Location of information unknown Information on responsibilities often unknown

Causes • • • • Technology on devices and system immature Lacking a central information system or point Aging responsibility schemes Segmentation of fire departments

• •

Influence possibilities • Improve communication devices • Design a central information system • Refresh responsibility schemes • Integrate the different segments into one organization. • Relief Support • Main field coordinator

District Water Boards

Responsibility for all public works departments of the country

Ineffective cooperation and Coordination during a Water Calamity

• •

Existence of different Calamity Reports Responsibilities often unclear

• • •

Central position in water calamity Possibility to act on own authorization Centre of information on local water affairs

SPM4910 – SEPAM Design Project (ICT) - Appendix

95

Actor Municipalities

Interests Protection of inhabitants

Goals • • Assurance of safety and quality of living Optimal cooperation and coordination during a (water) calamity

Core problem • Some towns are not optimally protected against flooding and water pollution

Causes • Lack of knowledge in protecting municipalities against water flooding or pollution

Provinces

Protection of inhabitants

• •

Assurance of safety and quality of living Optimal cooperation and coordination during a (water) calamity Protection against flooding Assurance of clean and sufficient water supply for all users Construction and maintenance of waterways Assuring swift and safe flow of all water traffic (Source:www.rijkswa terstaat.nl)

National Water authority (Rijkswaterstaat)

Execution of national water policy

• • • •

Coordinating municipalities and inter province coordination during a calamity The quality of waterways as a transport medium should be guaranteed. Need for protection against high water levels Need for guaranteeing natural developments

Different Calamity plans that are difficult to link

Influence possibilities • Close cooperation with water authorities • Main responsibility with mayor in case of application Calamity law • Royal Commissioner taking responsibility

• •

Water level of the Maas alarmingly high due to climate change Increase of constructions around the Maas hinder drainage of rainwater (Source:www.maaswe rken.nl)

• • • •

Management of Water boards Broadening and deepening water beds Implementation of the Maaswerken Further research

SPM4910 – SEPAM Design Project (ICT) - Appendix

96

Actor The Royal Netherlands army

Interests - to defend Dutch territory and that of the NATO allies; - to make a worldwide contribution to peace, security and stability. This may take the form of crisis management tasks, humanitarian aid or disaster relief “ (Ministry of defense, 1998:6).

Goals • To deliver support when government organizations request the army’s assistance in situations for which their own equipment or expertise is inadequate, such as the floods in Limburg. (Ministry of defense, 1998:9).

Core problem • The inability to deliver optimal support in case of an emergency where cooperation with other emergency services is needed.

Causes • Cooperation with other emergency services is very rare due to the low number of disasters over a long time period. It’s hard to obtain some experience in cooperating with each other. The use of different communication systems adds extra complexity to this cooperation8.

Influence possibilities • The use of military exercises and simulations to gain some experience in cooperating with other emergency services. • The lobby for better communication standards and protocols. • Manpower during calamity support

8

The specific C2000 hardware for the Dutch army is not available at this moment. According to the ministry of BZK this will be the case in one year, but because of the major delays in the whole C2000 project, there’s a lot of scepticism about this expectation (NRC Handelsblad, 2005a).

SPM4910 – SEPAM Design Project (ICT) - Appendix

97

Actor The Royal Marechausse e

Interests Execute its tasks to the best extend, nationally and internationally: 1. Security -Object security -Ceremonial services -Personal security -Security of value transports -Security civil aviation 2. Police tasks -Civil aviation terrains -Defence 3. Assistance and cooperation 4. Compliance immigration legislation -Frontier guarding -Mobile supervision immigrants -Assistance immigration procedures 5. Tasks Criminal Investigation 6. Civil peace and international tasks (Koninklijke Marechaussee, 2006)

Goals • To be able to contact other emergency services and colleagues on international terrains (Ministry of Defence, 2003)

Core problem • Inability to reach colleagues.

Causes • Bad coverage and capacity of relief services

Influence possibilities • Lobby within the Ministry of BZK for a better communication system. • Negative feedback in C2000 evaluation. • Relief Support

SPM4910 – SEPAM Design Project (ICT) - Appendix

98

Actor European Union

Interests Guaranteeing the safety of all European Citizens

Goals • Cooperation and interoperability of emergency services within and between countries • To save the lives and property of people at risk in the EU from terrorism, natural disasters and accidents (Commission of the European communities, 2005) • Set-up of a Critical Infrastructure Warning Information Network (CIWIN) • Implement European Programme for Critical Infrastructure Protection (EPCIP)

Core problem • There is no international standard for handling large scale calamities. One of the results is an insufficient cooperation between EU members.

Causes Technical • EU members use their own emergency networks, with different protocols and frequencies. Institutional • Difference in approach for handling calamities.

Influence possibilities • Investment of EUR 7 million on CIWIN and EPCIP projects (Commission of the European communities, 2005) • Bringing different countries together in implementing international calamity policy. • Stimulating C2000 network: based on European Tetra standard, harmonizing international protocols and frequencies (Min BZK, 2006)

SPM4910 – SEPAM Design Project (ICT) - Appendix

99

Actor Ministry VWS of

Interests Protecting the Netherlands against the negative influences of water and providing it with safe, worldclass connections. (Ministry of VWS, 2006)

Goals • • Protect the Netherlands against possible flooding. Proactively research into flooding possibilities and prevention.

Core problem • Possible malfunctioning of safety measures, due to insufficient communication .

Causes Need for: • Flooding areas • Identifying compartments • International Measures • Good Calamity Control Organization • Higher safety Standards (Tussenbesluit Rampenbeheersingsstrate gie overstromingen Rijn en Maas). These are measures on the physical level, which cannot function optimally without a good performance at the other levels of an infra system; the operation and service level (Thissen and Herder) • Communication between public bodies is inadequate

Influence possibilities • A good cooperation with other organizations by taking measures to prevent damage by flooding.

Ministry of agriculture nature and food quality

Protection of all agricultural, fishery and nature affairs

Maintenance of a good and safe food supply and guaranteeing the veterinary and sanitary safety (Handboek Communicatie bij Crises LNV)

Well organized communication during crises is lacking

Representation in the Interdepartmenta l Policy Team

SPM4910 – SEPAM Design Project (ICT) - Appendix

100

Actor International Maas Commission

Interests Guarding the water basin of the Maas

Goals • Obtaining a sustainable and integral water management for the international water basin of the Maas. Formulating a Program of Action (PoA), in which all sources of pollution in the Maas have been identified. Furthermore, the PoA will list possible measures to guard and improve the overall water quality. (Source:http://www. meuse-maas.be)

Core problem • The obligations with respect to the European Frame guide of Water should be clear Need for a centre of advice on subjects of prevention and protection against high water levels Need for a centre of advice on subjects of pollution

Causes • Increasing water pollution of the Maas

Influence possibilities • Precautionary measures • Establishing a homogeneous measuring system • Establishing an operational warning system for pollution resulting of a calamity • Drawing up of an inventory of drainage • Guiding structures of international cooperation

SPM4910 – SEPAM Design Project (ICT) - Appendix

101

II.3 Dependency analysis
The actor analysis has made clear what attitude the different actors involved have towards the problem area. Now it is of importance to determine how these actors are related to the ministry of BZK. For every actor, the most important resources, the dependency and criticality have been listed. Dependency implies to what extent the ministry of BZK is dependent on the cooperation of this particular actor. Criticality implicates to what extent the resources the actor possesses are critical for an effective calamity repression.
Table II.2 – Dependency analysis considering the various actors.
Actors Police Department First Aid Medical Services Fire Department The Royal Netherlands army National Water authority (Rijkswaterstaat) Municipalities Provinces The Royal Marechaussee European Union Important resources • • • • • • • • • • • • Dependency moderate, high) high high high moderate low (minor, Critical actor (yes / no) yes yes yes no no

Relief support Relief support Relief support Main field coordinator Manpower during calamity support Management of Water boards Broadening and deepening water beds Coordination and Calamity Management Royal Commissioner taking responsibility Relief support Bringing different countries together in implementing international calamity policy. A good cooperation with other organizations by taking measures to prevent damage by flooding. Central position in water calamity Possibility to act on own authorization Centre of information on local water affairs Representation in the Interdepartmental Policy Team Establishing a homogeneous measuring system

high high moderate low

yes yes no no

Ministry of VWS

high

yes

District Water Boards

• • •

high

yes

Ministry of agriculture nature and food quality International Maas Commission

• •

low moderate

no no

SPM4910 – SEPAM Design Project (ICT) - Appendix

102

SPM4910 – SEPAM Design Project (ICT) - Appendix

103

II.4 Corresponding and contrasting problem perceptions, interests and goals
The final step of the actor analysis is to place the previous findings in a matrix, providing a clear visualization.
Table II.3 - Corresponding and contrasting problem perceptions, interests and goals.

Dedicated actors Critical actors Corresponding problem perceptions, interests and goals -Police Department -First Aid Services -Fire Department -District Water Boards -Municipalities -Provinces Non-critical Actors -International Commission -National authority (Rijkswaterstaat) Maas Water

Non dedicated actors Critical actors -Ministry of VWS Non-critical actors -European Union -The Royal Marechaussee -The Royal Netherlands army -Ministry of agriculture nature and food quality -

Contrasting problem perceptions, interests and goals

-

Striking is the fact that, in principal, all (important) actors involved have similar problem perceptions, interests and goals. An explanation could be that all these actors are public institutions, managed in a considerably hierarchical way. Obviously, it would be rather surprising if they have different opinions on this subject, as this would make an effective cooperation impossible. The most important actors are the dedicated and non-dedicated critical actors, for whom a further analysis shall be executed in chapter 3. These actors should actively participate with the objectives of the ministry of BZK. Of course, the interest of the other actors should be taken into account, but because they are not critical in the solution area, they will not have to be actively taken along at this time.

SPM4910 – SEPAM Design Project (ICT) - Appendix

104

Appendix III – Operational plans
Table III.1 – Indication of the need for relief or aid per main process in case of a flood (LMR, 2001).

Table III.2 – Extensive and concrete overview considering the need of relief services during a flood.

SPM4910 – SEPAM Design Project (ICT) - Appendix

105

Appendix V – Organisational structure
National level

Min Defence

Min Justice

College procureurs generaal

First aid medical service (private) GHOR

Min of the Interior Fire Department (Regional) Royal commisioner , GS National Police Department Regional Police Department Fire Department (Municipality ) Army / Royal Marechaussee

First aid medical service (public )

Relief services Board Regional Fire Department Regional level

City council

Mayor

ZBO College Authority / management relation

Municipality level

supervision relation

Figure V.1 – Organisational structure of the relief services and other authorities.

106

Appendix VI - SWOT analysis
Table VI.1 – Results of the executed SWOT analysis.

Strengths −
The C2000 network with the Tetra technique has a nationwide covering.  It’s not necessary anymore to switch frequency by leaving the region (De Projectdirectie C2000, 2004). When neighbor countries also have implemented the Tetra technique, border crossing communication is possible (De Projectdirectie C2000, 2004). C2000 makes better and faster communication possible. Connections can be obtained much faster (De Projectdirectie, 1998). In contrast with current analogue networks the speech quality is improved (De Projectdirectie C2000, 2004 and Meijer, 2004). With an emergency button, high priority can be obtained to the emergency room. C2000 is cryptographically secured, which makes listening of civilians almost impossible (De Projectdirectie C2000, 2004). The Tetra technique makes trunking possible, which multiplies the capacity of the available channels (De Projectdirectie, 1998). The realization of the C2000 infrastructure is almost completed successfully (Deloitte, 2005). The management of the C2000 infrastructure, control rooms and equipment performs sufficient (Deloitte, 2005).

Weaknesses − − − −
Difficult to use (NRC, 2005a). Bad accessibility inside concrete buildings (NRC, 15 June 2004). Possibility to localize users of the system for outsiders (Parool, 2 September 2004). C2000 has a limited data capacity, whereas real time information exchange is not possible (Trouw, 15 June 2004). Trunking does not exclude full occupation (De Projectdirectie, 1998).

− −

107

− − − −

It’s possible to send and receive short text messages (De Projectdirectie C2000, 2004). In case of disturbance, there exist technical and organizational alternatives (De Projectdirectie C2000, 2004). In the future consultation of data files becomes an option (De Projectdirectie C2000, 2004). The necessary equipment is purchased and implemented in an early stage (Deloitte, 2005).

− −

− − − −

− Opportunities

A lot of introduction failures (NRC, 2005a). Border crossing communication asks not only for technical solutions but also for clear procedures and agreements (De Projectdirectie C2000, 2004). Trust in the system (“draagvlak”) (NRC, 2004). Point of no return is passed a long time ago (Trouw, 15 June 2004). Total dependency on the C2000 system, as old networks are being removed (Deloitte, 2005). C2000 is not capable of meeting the demands and possibilities of today’s internet capabilities (Trouw, 15 June 2004). The poor availability and accessibility of correct and complete information, for an effective execution of tasks in favor of decision making (ACIR, 2005). The poor division of this information between concerned parties (ACIR, 2005).

Threats

108

Appendix VII – Processes during a water calamity
VII.1 Monitoring
Monitoring is part of the regular water management, under the responsibility of the district water board. Monitoring is an activity that takes place during all stages of a flood. Important issues that are addressed are: - Water level - Threatened dike rings - Ways of assistance (type, amount) - Special objects - Water retention possibilities - Prognoses Since this is a very specific task, which is done by one actor (District Water Board) and does not demand any interdisciplinary skills, this part will not be within the focus of further analysis anymore.

This process happens when a certain threshold value is being passed, thus a result of the first process, monitoring (Melding en opschaling, 2001). The way of scaling up is described in protocols in the manual concentrating on high water: ‘Draaiboek Hoogwater’. The messages can be divided in three types of generic messages, regarding the state of scaling up and down, flooding scenarios, and forecasts (Berichtenspecificatie Hoogwater, 2004). There are different scales of calamities, indicated by the term GRIP, numbered from I until IV (InformatieStromenAudit, 2004). GRIP I means an emergency situation with limited effect. GRIP II stands for a more serious situation, and which needs (multidisciplinary) action and coordination on a municipal level, based on the calamity plan. One scale further, GRIP III, the problem becomes inter-municipal, and several teams are being set up. The most severe state is represented by GRIP IV, where different regions are involved, and the coordination falls under the responsibility of one of the involved mayor or Royal Commissioner (The shifts in responsibilities for every particular scale can be found in chapter 4). A flood frequently implies a situation that crosses the municipality border. Because of that, the situation immediately will be set to a regional scale (GRIP III or IV). The organization set up can be perceived equal between the stages III and IV. On a regional level, as mentioned in chapter 4, this includes the following teams: - Calamity Policy Team (CPT) - Regional Operational Team (ROT) - Commando Calamity Area - Regional Action Centers - Municipal Calamity Management Teams - National Coordination Centre (stage IV) Regarding the need of information, the following issues are addressed: - The current calamity phase - Current location specific information - The means of communication to be put into action - The water routes that will come into existence in the area - The number and location of emergency pumps - The content of possible warning messages - The deployment of barriers or temporary dikes - Estimation of moment of passing beyond calamity alarm level - The need of resources

VII.2 Scale up

109

-

Requests for permission of certain actions

The preparation phase has great implications on the efficiency of possible following relief services. Hence, already within this part of the process the first interdisciplinary contacts are made.

VII.3 Evacuate
Evacuation implies the by the government ordered coordinated transport of groups of people and animals, either forced or voluntary. Furthermore, this holds the registration, escorting, reception, caring, and preparing for return of groups of people to their homes, and follow-up treatment. It usually is a matter of temporary clearance of an area, which can be forced legally. When a flood is imminent, which means that it almost certainly will occur, a decision has to be made whether to evacuate. With regard to information streams, a number of issues will have to be addressed in this situation: - Calamity script (depends on the location) - The dimension of the evacuation - Routes and transport modalities (people/animal) - Temporary facilities - Guarding of area - Time of preparation for the availability of the transport modalities - Time of preparation for special objects like hospitals and schools - Rules regarding priorities Besides these rather generic information entities, there are numerous other information flows coming from and going to the relief services and the more supportive and policy teams. Within this part of a flood situation, a great number of parties are involved on the policy level, as well as the operational level. In this process, there is not only information exchange between these levels, but also within the levels, that exist of different organizations. Manuals and scripts that clearly state what should happen, and by whom, at certain stages during an evacuation exist and are analyzed in a separate section in this chapter.

During the actual flood the relief services, in cooperation with the District Water Boards, try to control the situation. The information exchange addresses the following issues: - Entry points to the flood area - Responsibility of making situation reports - Actions to be undertaken - Estimations on possible escalations - Available transport modalities - Ways of protection for the relief services - Risk mapping (contamination etc.) The information is used to inform the public, and to make estimations about further inundation, and return. In case of an immediate flood, it also can support decisions regarding evacuation. The content of the messages that can be discerned during a flood, are about characteristics of the flood itself, about availability infrastructure, the water level/water depth, and possible contamination (Berichtenspecificatie Hoogwater, 2005).

VII.4 Flood

This process will be left out, as it does not occur during the repression phase.

VII.5 Take care of damage

110

Appendix VIII – Evacuation processes
Within each process there are different actions to be undertaken by different actors. In the tables below the different evacuation processes are described with involved actors, including the responsible actor per step, which is written in bold.9 Also the information-related issues are described per activity. The involved actors Police Department, Fire Department, GHOR, and Municipality, are interacting in a regional level. This means that the management, planning, information requests etc. take place within the constituted teams, such as Calamity Policy Team, Operational Team, or Action Team. The District Water Board has its own important tasks, on the operational level (monitoring etc.), and on the policy level (advise etc.). The most important used sources are: ‘Leidraad Maatramp’, ‘InformatieStromenAudit’, and ‘Handboek Calamity control’. The following abbreviations are used; FD - Fire department PD - Police Department GHOR - Medical Relieve Services Mun - Municipality Notes

Table VIII.1 - Activity: Analyzing relevant information. Activity Involved Information actors 1. Analyzing relevant information FD, PD, GHOR, Mun FD, PD, GHOR, Mun All information that could be of importance in the operational phase of evacuating. Nature, dimension of flood; location; development of flood; information about population and public buildings.

1.1 Based on information about nature, dimension, and development of calamity determine whether evacuation is necessary: - Determine whether population needs advise about securing buildings and objects; - Determine whether public buildings and other properties need securing. 1.2 Determine dimension of area to be evacuated and nature of evacuation:
9

The content of the evacuation plan is made by the municipality, in close relation with other actors. PD (police) executes the evacuation plan in a later stage. The District Water Board usually holds the information about the characteristics of a possible flood, possible future scenarios. Information about the area is to be found within the different municipalities.

FD, PD, GHOR, Mun

Possible flood area; maps; flood prognoses.

local

-

Because it is a flood, it automatically crosses municipal borders, and the Royal Commissioner should be reported. In our

Handboek Calamity control, deel B, bijlage 4 p.19-22

111

Inside and outside municipality (report to Royal Commissioner); - Preventive or immediate; - Voluntary or forced. 1.3 Emergency regulation needed? - If so, quickly make arrangements with ‘OM’ about issues regarding justice. 1.4 Based on (on beforehand) aggregated information determine: - Number of involved persons, pets, cattle, including the mobility of this; - Number of vulnerable buildings/objects and mode of securing these; - Idem for production processes and storage of dangerous goods (for people and environment); - Determine priorities of different categories; - Determine which parts belong to government responsibility.

-

-

case we deal with preventive evacuation. FLIWAS helps in making scenarios, and evacuation maps.

FD, PD, GHOR, Mun FD, PD, Mun

Severe emergency situation? Enforcement necessary?

This issue will not be taken into account

Information about population; pets and cattle; special buildings /objects; production & storage facilities; location, characteristics; priorities; responsibilities.

This part has close relation with the first subprocess of determining the need on evacuation. Most of the information has to come from the municipalities, or from the province.

112

Table VIII.2 - Activity: Draw up evacuation plan. Activity Involved Information actors 2. Draw up evacuation plan FD, PD, GHOR, Mun In most regions in the Netherlands where evacuations as a result of floods are a possibility, there are evacuation plans available. Depending on the dimension of the possible flood, and the affected areas, this process will partly consist of harmonizing the already existent plans. Dimension flood; scenarios.

Notes

The content of evacuation plans need to be adaptable, and when new information becomes available, a swift implementation of that information into the plan is needed. The development of an evacuation plan is possible within FLIWAS applications. Part of the evacuation plan is an information plan, regarding the measures to be taken to inform and instruct the public. In the case of a flood, this will always be the case, in the form of an Action Team. This process of arranging all the information, into a practical data, is the result of a collaboration between the actors. An information plan is made. Information available at municipalities. An important aspect is that the time schemes, describing different evacuation steps, with each step specific informational aspects. It is much more efficient when the information arrives only at times when there is a need for that information.

2.1 Determine whether a separate regional action centre should be set up at regional command centre. 2.2 These data are necessary for the execution of the sub-plans public information, warning population, and taking care of traffic: - Determine modes of protection for ‘relief services’ and maximum stay in area. - Determine collection-, registration-, convoy-, and boarding points; - Determine routes evacuation, separated for human and animal; - Determine first implementing locations or action centers; - Determine time schemes for subsequent evacuation steps. 2.3 Determine the needed languages to inform evacuees. Determine content first and later delivery in

FD, PD, GHOR, Mun FD, PD, GHOR, Mun

Available and needed modes of protection; geography area; needed number of collection/ convoy/ boarding points; possibilities evacuation routes and demand of traffic (human and animal); determination implementing locations and action centers; urgency level; flood scenarios. The result is an information plan, in which directions are stated within time schedules.

Mun

Demography evacuation area.

This is the task of the municipality.

113

cooperation with Information division. 2.4 Determine required resources in humans and materials. - Supporting and controlling personnel (police, military); - Medical personnel (on the road); - Registration personnel; - Veterinary service, animal protection; - Public information centre - Ways of transportation (taxis, public transport, ambulances, wheelchairs, trucks, cattle trucks, ships and boats, helicopters, etc.); - Protection materials special buildings/objects/ infrastructure; - Information cars, connection material; - Traffic and information plates, demarcation resources 2.5 Determine control evacuation area, including material for sealing area. 2.6 Determine which utility services need to be terminated. Criteria is that this should be delayed as much as possible. 2.7 Determine how area has to be guarded (relation with fencing/protection). 2.8 Harmonize measures with other municipalities, regions, province, and NCC.

FD, PD, GHOR, Mun

Future demand of traffic (human/animal); available relieve sources; needed services (registration/medical etc.);

Here the connection takes place between the evacuation demand (so the amount of persons, animals) and the available resources. The municipality makes a list of the required resources, human and material.

PD, Mun

Number of evacuation roads; available material. Number of location. utility services;

The police department does cooperation with the municipality.

this

in

FD, Mun

The Fire department decides this in cooperation with the municipality. Information available within municipality. Clearly regards a task that will be executed by the Police department, so they are the only one involved (next to Municipality) The whole planning already takes place in a regional context, so within the RPT, OT, and other teams.

PD, Mun

Flood information; evacuation routes. ---

Mun

114

115

Table VIII.3 - Activity: Getting Personnel and Resources ready. Activity Involved Information actors 3. Getting personnel and resources ready 3.1 Alarm personnel and take care of required resources. Think of: - Red Cross, family doctors, First Aid relieve workers; - Churches and other similar networks; - Social workers; - Voluntary police; - Military. Material resources of - Transport organizations; - Animal ambulance; - Cattle transporters; - Military support. 3.2 Get people in position and making ready for - Collection points; - Reception locations. 3.3 Alarm third parties, such as utility companies. FD, PD, GHOR, Mun FD, PD, GHOR, Mun List of contacts. Telephone numbers; addresses.

Notes In this activity the responsibilities are described in a very clear way, which makes making decisions easier. The literature does not describe that there should be a clear list with data about possible extra resources, such as Red Cross, family doctors, voluntary police, etc. This is essential for a quick reaction on an imminent flood. The responsibility for this task lays in hands of the Police Department.

Mun

Locations for collection and reception; telephone numbers people for these points. List of third parties.

This is a task for the municipality only.

FD

This is a task for the Fire Department only.

116

Table VIII.4 - Activity: Use of Personnel and Resources. Activity Involved Information actors 4. Use of personnel and resources 4.1 Instruct personnel FD, PD, GHOR, Mun PD, GHOR, Mun Many different, result of earlier activities. Location; number of people; time schedules; scripts.

Notes A clear description of the information (towards population, FD) part is missing. Unclear task responsibilities. The police department, and the municipality need to give clear instructions to their personnel, so their task is plain and unambiguous. The role of GHOR is not very clear in this matter. Instructions will focus on matters like where to stand, what to say, what to do. This is a very unclear sub-process, because at least partly it is a matter for the Police Department, with processes such as traffic accompanying, escorting, order maintenance, while the literature (Handboek Calamity control) leaves this party out, and considers it a task of the municipality. Uncertainty about the different tasks, and responsibilities are highly undesirable. Further: the actual evacuation takes place within this activity, but there is no relation at all with the activity of informing and instructing people (FD).

4.2 Mobilize personnel and resources for: - Reception and collecting points; - Support of evacuation to reception centers; - Control and guarding evacuated area, including termination of utility services; - Order maintenance; - Traffic accompanying; - Reception of people in reception centers; - Instruction people (think of medication, medical dossier); - Medical escort of transports; - Transport and reception of pets and cattle; - Securing special objects; - Activate sub-plans information facilities, warn population and receive/take care. 4.3 Registration of secured persons, animals, and special objects, as well as the spreading and

Mun

Location; task descriptions; evacuation plan; scenarios; time schedules.

Mun

Names; objects.

This information handling belongs to the municipality.

117

control of it.

118

Table VIII.5 - Activity: Return. Activity

Involved actors FD, PD, GHOR, Mun FD, PD, GHOR, Mun FD, PD, GHOR, Mun

Information

Notes

5. Return

Municipality is responsible for this part, and cooperation takes place between all actors. There is insufficient information about criteria and other issues that play a part in this situation. Identical This is very context dependent, and there is no clear script to be made for these situations. Identical

5.1 Determine under which circumstances return is possible 5.2 Take care of return

119

Appendix IX – Information systems
IX.1 Information about FLIWAS
There are several private and public organizations involved in the development of a general monitoring and warning System, captured in the program FLIWAS. The most important players are the (Dutch and some German) District Water Boards, provinces, calamity regions, STOWA, RIZA, National Water Authority. The initiatives that are bundled in the FLIWAS project are HIS, NOAH, and Viking, explained below. HIS10 NOAH - HIS exists of an operational component (Monitoring and Logbook Modules), and a policy component (Flood and Effect Modules). HIS within the project will address the Quality Insurance. (www.hisinfo.nl) - NOAH is the main actor in the FLIWAS project. It was a direct result of the conclusions drawn in the ‘von Kirchbach-report’ on the floods of the Elbe (2002). The main focus is on the development of the GDH, explained below. (www.noahinterreg.net) - This project shows overlapping with other initiatives, such as HIS. it is a cooperation between German and Dutch actors to improve information handling and communication. The focus of VIKING within FLIWAS will be on implementation issues. (www.programmaviking.nl)

VIKING

GDH (www.geautomatiseerddraaiboekhoogwater.nl) freely translated means the Automated Script for High Water level Situations. It is one of the basic applications of FLIWAS. It consists of the information about the existing paper scripts on high water level situations, with according actions when levels are exceeded. GDH processes the introduced water level information, and advises the user about transition phases, only with relevant information. The user maintains the status of actions, and if actions are not done within the assigned time, an automatic warning can be issued on the screen, or by mail or SMS (Redesign operationeel deel HIS, 2005). The criteria for the development of the programs and applications are (HIS / NOAH gebruikersdag, 2005): Multilingual Web-oriented, but with server and client processes Multi platform applications (Windows, Linux, MacOS) Access through normal web browsers (PC, palmtop) Centralized and decentralized implementation possible Centralized and decentralized data storage Information exchange between FLIWAS-implementations and other information systems Information and communication system Modular building with generic components and autonomous functional modules Possibility to add external modules Open source GIS component

The way new applications are being developed, is through tendering. The organizations that are involved in developing FLIWAS (HIS, NOAH, and VIKING) set criteria for specific applications, and issue a tender for each application separately. By mid March 2006, the first functions will be available. This is followed by the input of area information (water retaining structures, structures and measuring points, population, road network and evacuation routes), flood and evacuation scenarios. These are part of the action plans of the district water boards, provincial authorities, fire brigades and the police. The development of FLIWAS will be
10

Hoogwater Informatie Systeem: High Water level Information System

120

complete after the summer of 2006. At the end of 2006, the application will be available to all potential users in the European Union. In addition, the organizations for management, maintenance and support will become operational.

IX.2 Information about Infraweb
Infraweb is a web-based application that supports the communication between organizations on national level. The system supports the reporting, registration, and information exchange with incidents and calamities. It is possible to authorize users within the system, so information can be kept within a certain organization, but can be made available as well for other users. There is a collaboration going on between the developers of Infraweb and FLIWAS. In the picture below a clear overview is given of FLIWAS, its programs, and its modules.

Figure IX.1 – The position of FLIWAS.

121

Appendix X – Group Decision Room session report
Introduction (Categorizer) Participant Instructions Give some examples of possible failures during this exercise concentrating on desired information (resources / needs). semantics 1. People use different terms 2. Information in wrong 'form' (description vs map) 3. ambiguity information 4. reaction is not good on information 5. different persons take information on a different manner • it is possible that one person reacts differently on a certain situation than another person... responsibilities 1. Don't know who is responsible 2. Information classified • is this a failure? 3. confusion between commanders on the smae level (e.g. police chiefs) 4. not clear who is responsible for whom 5. receiving too much information • People receive to much information • receiving too much information in a crisis situation (no time to handle that) 6. not all instances receive the information needed for cooperated action technical failures 1. information database crashes 2. Information not up to date 3. information stream control insufficient 4. Manageging new information input 5. Information not available in region or country 6. what information should be push based, and what information should be pull based 7. user doesn't realise information has arrived (no alarm?) 8. privileges on databases are not distributed correctly external failures 1. external problems; civilians don't cooperate, places not reachable 2. Information reaction or receiving is time consuming • in really stressfull situations, users don't take their time to communicatie and ask for information • maybe the input of information will suffer from this aspect human failures 1. user asks the wrong questions 2. people don't use their equipment well 3. user receives information but doesn't know how to use it in a practical way 4. Don't know what information to ask for 5. different users are looking for the same information simulaneously (no sharing) 6. Don't know where they are (location) 7. too much information at a time

8. priority settings in information streams unclear (should all information be provided immediately?) interface 1. interface in which information is presented is not clear 2. diificulties in finding information 3. information not visible on screens in particular situation (darkness, too much sunlight) 4. Don't know where to find information Brainstorm 2 (Categorizer) Participant Instructions Give some examples of possible advantages and disadvantages of full information. advantages of full information 1. Situational awareness • All desired information available • better estimation of the situation (how severe it is) for all the involved persons 2. evade confusion, particularly on lowest level 3. always possible to know whats your duty 4. reaction very well 'onderbouwd' • 'Grounded' 5. easy management of groups within the complete calamity relief system • Increase manageability 6. Up to date information 7. digitalized information helps avoiding misinterpretations 8. possibility of 'looking ahead' instead of 'achter de feiten aanlopen' 9. It is possible for any one to use same information 10. relief workers can take over tasks, or assist in tasks that are not their own (with information regarding other tasks) 11. better linking different pieces of information te each other and solve the problem as a whole • different pieces of information complement each other 12. transparancy 13. improvement in creating log files (archives) 14. speeding up decision making process 15. ability to digitalize coordination and cooperation!! disadvantages of full information 1. too much information, don't know what to use 2. All nondesired information available 3. relief workers might make their own (strategical) decisions, while these decisions should be made on a higher level 4. people request information that they do not need 5. relief workers loose the focus on their task, may be intervene with other relief workers, disciplines 6. big data systems are difficult to keep up to date 7. Large initial costs 8. Large maintainance costs 9. Lots of systems connected 10. keeping an overview of the total information offer very difficult 11. more capacity needed for large information streams

123

12. relief workers don't know how to react in situations without full information (no improvisation skills) 13. Labourintensive (arbeidsintensief?) 14. setting up and managing priviliges very complex! could this also be digitalized? ex ante? 15. Different languages 16. all information provided by relief workers can not be immediately entered into the system; how is this managed? 17. Not aware of redundancy • a lot of redundancy? 18. Information keeps growing • huge amount of 'old' information 19. no feeling of responsibility when receiving a new piece of information (someone else will pick it up) 20. inconsistent information -> confusion, what is right? 21. TIME!!! takes quite some time to find the right information, not desirable in emergency situations • Searching for information might be rather time consuming Brainstorm 3 (Categorizer) Participant Instructions Identify as many requirements as possible. Please not only mention the subject but the direction also ('low costs' for example instead of only 'costs). Input-output 1. Stored information -> Operational information 2. Full information -> Specific information 3. fully push based -> mixed with pull based 4. general information -> information in the right format (graphs, voice) Technological requirements 1. clear interface 2. information input not only in th ehighest levels, lower levels as well => better information 3. connection with the Internet and other relevant networks 4. Easily connected to other systems (international) 5. Back-up system backup systems (for robustness) 6. Easily connected to other databases 7. concurrence in database alignment 8. Easily extended 9. ability of data-communication (including pictures) 10. diversity in representing data (voice, graphs, pics, icons) 11. databases may never crash 12. limit choice in information semantics 13. Web based 14. there should be a direct link between the technological features and the responsibility requirements 15. there should be a link to civilians as well 16. through internet then Performance requirements 1. ability to quickly inform management on mission status 2. High robustness 3. Short implementation period

124

4. system should enhance information handling within and between organizations 5. Specified accessability 6. information handling should be place dependent, context dependent, time dependent, and hierarchy dependent (officer receives other info than agent) 7. clarity in semantics 8. information should be up-to-date 9. Information should be clear to all parties 10. information should be accessable at the right time 11. information should be accessable by the right parties 12. information deliverance in different manners 13. database management should be relatively simple 14. interface as clear as possible (large, quality screen, realtime video etc.) 15. no delays in tranmitting information 16. information should be delivered with a reliability grade Cost requirements 1. Low maintenance costs 2. Low purchase costs 3. Low initial costs 4. using existing equipment as much as possible User requirements 1. the system has to deal with relief service specific thing (special features for firemen, policemen and ambulancepersonel) 2. Support personalised settings 3. limitations to what a particular team in the field should receive 4. personalized information --> the right person, the right information 5. voice communication should be possible without using hands "hands free" 6. system has to deal with user preferences (font size for example) 7. ability to control the volume of sound 8. High ease of use (information within few steps) 9. hierarchy will state the different responsibilities, implemented in system 10. technological features will couple information to this hierarchy 11. so incoming information should be judged accordingly... this judgment cannot take a long period of time 12. ability for user devices to directly rank information (on time received, rate of importance, etc.) 13. so maybe some information should be accepted straight away, some information should be put as standby, and some needs to be checked before input 14. Sufficient ergonomic 15. this implies a hierarchy in information as well, which does not necessarily follow the institutional hierarchy Design process requirements 1. all parties should be satisfied with the system 2. excercises where relief workers can train how to use their autonomy and learn to improvise 3. abtility to train with the system before accidents take place 4. all relevant parties should be involved 5. 1st line users (police, fire, ambulance) should have a stronger position in the design process than 2nd line users (army, explosieven opruimings dienst) 6. frequent information updates for the relief services during the design process 7. linking responsibility schemes of the different clamaity plans digitally 8. agreements in database linking and privileges 9. Short implementation of design 10. All actors involved

125

11. no exit option in this case 12. No blocking power 13. protecting core values • protection of core values 14. working towards a lengthy agreement responsibilities 1. subsidiarity principle: decision should be made on a level as low as possible 2. hierarchy should be very clear 3. Clear responsibilities 4. decide to what extent relief workers can digitally 'push' information 5. information stream control centre: determine amount of personnel needed 6. digitalization of responsibilities within system 7. provision of local hierarchy structure in user devices 8. direct communication net within groups (e.g. messanger) 9. priority ranking in information provided (a decision can be overruled by someone higher in the hierarchy

126

Appendix XI - design issues
XI.1 General design issues
All the requirements that could compete with each other are selected from the complete list of requirements (chapter 8). These requirements were set out against each other in table 12. Conflicting requirements are coloured and marked with a number. As table 12 shows, nine design issues were identified.
Table XI.1 - General design issues.

R eq. I1 I2 T1 T2 T3 U1 U2 R1 R2

I1 1

I2

T1

T2

T3 2

U 1

U 2 4 5

R 1 6

R2

8 3 7 9

Possible design issues Information I1: Clear and general semantics (need) I2: Limited amount of information a particular user in the field should receive (need) Technological T1: Ability to couple this system to communication systems that civilians use (nice) T2: Web-based (possibly use of Internet applications) (need) T3: Compatible for extension with other (international) information systems and trends (nice) User requirements U1: Selective authorisation (need) U2: Maximum security (need) Responsibilities R1: decisions should be made on a level as low as possible (nice) R2: clear operational responsibilities (need) Process P1: Minimum implementation time (nice) P2: Step-by-step implementation (need) P3: All relevant parties should be involved (need) P4: 1st line users (police, fire, ambulance) should have a stronger position in the design process than 2nd line users (army) (nice) P5: Frequent information updates for the involved parties during the design process (nice) P6: No exit option (need) P7: No party should have blocking power all by himself (need)

127

12.1XI.2 Costs design issues
Table XI.2 - Costs design issues.

requirement

Purchase Costs (investment)

Maintenance Costs (exploitation )

Adaptation Costs (investment)

N-I1 N-I2 N-T1 N-T2 N-R1 N-U1 N-U2 N-U3 N-U4 N-U5 N-P1 Costs - Low Purchase costs (nice) - Low Maintenance costs (nice) - Low adaptation costs of existing systems (nice) Technological Information N-I1 Information should be delivered with a reliability grade (nice) N-I2 Priority ranking of information provided (nice) Technological N-T1 Ability to couple this system to communication systems that civilians use (nice) N-T2 Personalized representation of information (nice) Institutional Responsibilities N-R1 Decisions should be made on a level as low as possible (nice) User requirements N-U1 Familiar appearance to every relief service (nice) N-U2 Database management should be relatively simple (nice) N-U3 Ability to deal with relief service specific things (special features for firemen, policemen) (nice) N-U4 Support of personalized settings (nice) N-U5 Ability for users to rank information directly (nice) Process Design process requirements N-P1 Minimum implementation time (nice)

128

Not all actors have to be involved for each design issue. Table 3 shows the actors that should be involved for each negotiation. When comparing the groups of actors needed per design issue the same pattern can be distinguished for some design issues. These issues are taken together in a cluster which enlarges the negotiation package and the possibility for trade-offs. The white numbers per cell indicate which cluster the design issue belongs to.
Table XI.3 - Clusters of actors.

XI.3 Defining actor groups

Issue 1 2 3 4 5 6 7 8 9 BZK VWS PRO DWB MUN PD FD FAS PRD

BZK 2 1 3 3

VWS 2 1

PRO 2 1

DWB 2 4 4 4

MUN 2 4 3 4 4 4

PD 2 4 3 3 4 4 4

FD 2 4 4 4 4

FAS 2 4

PRD

3 3 4 4 4

1

1

1 4

Ministry of BZK Ministry of VWS Provinces District Water Boards Municipalities Police Department Fire Department First Aid Services Project developer

XI.4 Overview of the process design
This chapter provides an overview of which requirements are met by the process design as described in chapter 9. Since the process design ends with the start of the project, the process rules concerning implementation are not covered by the process design. Whether the requirement (“low costs”) is met is totally dependent on round 3 and 4. Table XI.4 - Process design Rounds Round 1 (generic process rules) overview. Requirements met - All relevant parties should be involved (need) - Frequent information updates for the involved parties during the design process (nice) - No party should have blocking power all by himself (need) - Protection of core values of all the involved actors (need) - 1st line users (police, fire, ambulance) should have a stronger position in the design process than 2nd line users (army) (nice) - All parties should be satisfied with the system (need) - Frequent information updates for the involved parties during the design process (nice) All parties should be satisfied with the system (need)

Round 2 (requirements)

Round 3 (design issues) Round 4 (costs) Round 5 (start project)

129

Appendix XII – Technical design
Table XII.1 – Actors involved considering the technical design.

Actor group Service provider

Roles
Organisations that procure the service implementations, supply their service descriptions and provide related technical and business support.

Service client (consumer) Service aggregator Service operator Market maker

End-user organisations that use the service. Organizations that consolidate multiple services into a new, single service offering. Organization responsible for performing operation management functions. Organization(s) that create and Ministry of Interior and Kingdom maintain the marketplace. Relations (BZK) Definition Details Service descriptions
Service basic operations

Actors in this respect This should be outsourced on a contract base to (an) external party/parties that possess(es) the right technical knowledge. The relief services and the emergency rooms. External parties by request of the technical management of GMS. The technical management of GMS

Table XII.2 – Service layers distinguished concerning the paradigm.

Service layer Description and Basic Operations Layer

Includes the different services − (including systems and databases) − that need to be covered by the SOA.

Service Encompasses necessary roles Composition Layer and functionality for the consolidation of multiple services into a single composite service. The composite service can perform functions that include coordination, monitoring, conformance and quality of service composition.

Considering coordination, the service: − Controls the execution of the component services. − Manages the dataflow among them and to the output.
Considering conformance, the service:

− −

Ensures the integrity of the services. Imposes constraints on the services and data fusion activities.

Considering monitoring, the service: − Subscribes to info produced by services. − Publishes composite events. Considering Quality of Service (QoS) composition, the service: − Leverages, aggregates and bundles the QoS to derive the composite QoS (including overall costs, performance, security etc.).

130

Service Management Layer

Manages critical specific markets.

applications

and

The management: − Supports critical applications that require enterprises to manage; o the composite service o the deployment of services o the applications Supports open service marketplaces. Basic operations This system makes communication between the different relief services and the GMS possible. This is a GIS system that shows via a map of the Netherlands all the floods that have occurred in the past. For each area different flood objectives can be shown. For each calamity a flood model can be generated and a time indication all indicated on the map. CCS makes it possible to view maps and to communicate by the use of video during calamities. De user can determine for itself which map to be shown, on which scale and which objects involved. HIS presents via a map of a certain area a scenario on how an eventual flood can develop. This simulation is based on a list of parameters filled in by the user. This can be used to identify possible critical situations in the surroundings of an occurred calamity. This system gives the opportunity to create, edit and execute the indicated plans. This includes information on GEO, activities and library. Each region has access to the part of NLB that is important to them. The database provides information on every object. A basic system that makes

Table XII.3 – Basic services that need to be covered by the SOA.

Service CMS system

Description
The core information system of the emergency rooms, which connects the different relieve services to the GMS.

Overstromingsatlas

An atlas on the floods occurred in the past in the Netherlands.

CCS-Vnet

A Command and Control System supports calamity control especially large happenings.

HIS Scenario Viewer

A flooding simulation system

Professionele risicokaart Evacuatiemodule

A GIS system that provides an overview on the objectives important in case of a calamity. An information system that presents evacuation, accommodation and returning plans.

Nationaal Locatie Within this database all the Bestand (NLB) streets and their characteristics of the Netherlands are administrated. ISIS A Command and Control System

131

that supports calamity control. Multiteam A cooperation application

coordination possible during calamities. This application makes distance operation in certain teams possible.

FLIWAS

FLIWAS is a cooperative, international, and very comprehensive project that provides simultaneous access Including: to reliable and comparable data. An interactive GIS application. The system provides interactive − GIS system maps in which the scale and the level of information of objects can be adjusted. A water level monitoring and The system provides − Water level forecasting application. information on the water level monitoring and on a certain place in a river forecast system defined against time. Based on this data figures can be created, which make forecasting possible. An internal communication This provides the possibility to − Communication application. communicate via text messages facility with connected parties. This application indicates per − Priority notification A priority warning application. area the warning phase which is at that moment at hand. Including indication maps, information levels and management plans. A calamity management This application can be used to − Navigator application. navigate activities between actors during a calamity. It provides the opportunity to navigate measures, organisation, location, persons, resources and documents. Diverse information intranet: digital on − − Diverse information internet: digital on − − Real time transport and weather information Search engines and To be used information. To be used as as background background Static population, transportation and weather data Manuals concerning the used systems To be used information. To be used information. as background

FLIWAS aims for an integrated calamity system presenting information from many different sources.

as

background

132

E-mail facility

databases information. An application for digital indirect Used for communication with on another. purposes.

communication

Table XII.4 – Domains

Domains GMS core domain Command and control domain Database domain

Services included
− CMS system

Sub services included

− − − − − − − − −

FLIWAS domain

CCS-Vnet ISIS Multiteam HIS Scenario Viewer Nationaal Locatie Bestand (NLB) Overstromingsatlas Professionele risicokaart Evacuatiemodule FLIWAS system

− − − − −

GIS system Water level monitoring and forecast system Communication facility Priority notification Navigator

133

Appendix XIII - Division of costs
By combining information from multiple sources an overview of the costs of the C2000 project was created (Table XIII.1). As used before, a division is made between investment costs and exploitation costs.
Table XIII.1 - C2000 cost division. total costs central investment costs equipment project organisation miscellaneous total (mln €) € 653.3 € 489.6 central exploitation costs FAS (VWS) € 6.4 KMAR (Defence) € 2.7 BZK € 18.8 police fire regional exploitation costs police fire CPA (FAS?) KMAR total (mln € / yr) € 81.7 € 27.9

regional € 121.7 € 28.3 € 13.7 € 163.7

total

central

regional 19% 4% 2% 25%

100%

75% 8% 3% 23%

€ € € € € € €

30.6 7.3 9.1 4.5 1.4 0.9 53.8 100% 34%

37% 9% 11% 6% 2% 1% 66%

The central government paid 75% of the investment costs, whereas the regional governments took care of a large proportion of the exploitation costs. This table makes also clear how much the different emergency services had to pay in proportion to each other. The police department obviously had a larger proportion compared to the First Aid Services. The small contribution of the Military Police (KMAR) is explainable since they are much smaller in size compared to the other services. The division of exploitation costs among the emergency services are estimated at the beginning of the project. After measuring the user-frequency of all services, an extra calculation could change the division of exploitation costs.

134

Appendix XIV - Institutional design WebGMS
The table below gives an overview of the institutional arrangements to be made for the design of the WebGMS. Furthermore, the connection of these arrangements with institutional design theories is given, along with an estimation of the time needed to implement a certain arrangement. Finally, a plan of action for every arrangement has been drawn up.
Table XIV.1 – Overview institutional arrangements.

Institutional arrangeme nt Database and System incorporatio n

Requirement s Satisfied

Institutional design principles

Norms and values ? yes

Specified system accessibility

Flexibility

Time needed for implementation(month s) 9

Plan of action

Information Processing System

Operational flexibility

Reliability, Scalability, Credibility/Transparen cy

3

Standards Semantics Security measures

Ease of use Ease of use Maximum security

Democratic legitimacy Credibility/Transparen cy, Democratic legitimacy Democratic legitimacy

yes yes yes

6 6 6

Supervision

Clear responsibiliti es Clear responsibiliti es

Flexibility, Scalability, Reliability Reliability, Scalability, Credibility/Transparen cy yes

3

Aggregatio n

3

Communica te standards of web service with all external actors involved in a water calamity Set up information load manageme nt system for filtering and translation Implement standards of WGMS Implement semantics of WGMS Secure WGMS and C2000 from external systems Update interface of Service operator Ensure control and integrity of system, monitoring information content, QoS

135

Institutional arrangemen t Interaction between actors

Requirement s Satisfied

Institutional design principles

Norms and values ? yes

Decisions should be made on a level as low as possible

Reliability, Scalability, Flexibility

Time needed for implementation(month s) 6

Plan of action

Authorizatio n levels

Selective authorizatio n Clear responsibiliti es and Hierarchy should be very clear

Democratic legitimacy

3

Responsibilit y allocation

Democratic legitimacy

yes

3

Ensure that WGMS functions and determine most desirable + effective order of contact actions Set up scheme for integrating authorizatio n levels Set up scheme for integrating responsibiliti es Define costs for total project Define responsibiliti es for total project

Project costs Project responsibiliti es Clear responsibiliti es

Democratic legitimacy Credibility/Transpare ncy

yes yes

-

136

Appendix XV - Additions on the GMS template for the used interface
Although the information content changes according to calamity type and -stage, the structure of the information flow is set by the template. In the list below, the most important information entities, that should be included in the template, have been listed. Depending on the kind of interaction (reading information, requesting information, or searching information), the template should have functionalities to enable or disable entities. 1. Time/Date/State/Urgency 2. Sender/Contact person/Receiver/User (group) a. Executing level: PD/FD/GHOR/Army/Other (District Water Board, Municipality etc.) b. Policy level: Supervisor/Mayor etc. 3. Subject/Type of message; order/information/request 4. Category; Text/Image/Video 5. Domain; Geographic/Traffic control/Flood information/Current emergencies/Missing persons/ Legal/Resource management etc. 6. Content/Location 7. Phase; Monitoring/Scale-up/Evacuation phase/Flood/Return 8. Language choice (in case of international cooperation)

137