Beruflich Dokumente
Kultur Dokumente
Supervisors
Prof. dr. R.W. Wagenaar
Mr. A.J. Barendse
Mw.dr.ir. W. Blok
Dr. J.F.M. Koppenjan
ICT group
Thieme Hennis 1052381
Susan Lagerweij 1150243
Hidde Schipper 1024329
Sebastiaan Surie 1014617
Sebastiaan Tiemens 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 multi-
disciplinary 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
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.
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.
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:
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-, institutional-
and process aspects that characterize a water calamity, identifying functional requirements
of such a system, and incorporating these findings in a new covering systems design.
cooperation I (Information)
coordination 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.
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
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.
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
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.
Operational Plan
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
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
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.
LMR LOP
Relief /
Source / Need for Need for
Effect Support End / Result
Cause Relief / Aid Application
Processes
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
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.
Calamity type X
(# concerned)
Fire
Size of the department
need for
Police
relief or
aid / Local
process government
Medical
(not operational) Multi-
disciplinairy
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
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 ‘municipal-
and 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.
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:
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.
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.
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.
• 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.
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.
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).
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.
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
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
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.
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 flash-
calamity, 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 decision-
making 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.
1. Monitoring
2. Scale up
3. Evacuate
4. Flood
5. 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
Orders
Information
Royal commissioner/ Mayor
Mayors Consult
Regional / national
Regional Actin Center
Coordination Center
Regional Policy Team
Maps, Calamity
Geo-info, Municipal Policy Team Plans
Resources Municipal Action Center
Management
systems GMS
(FLIWAS,
VIKING, IRIS)
Police Dept.
Regional Action Teams
Operational Commando Calamity
Teams Area
Fire Dept.
Situation
Reports Tacit
Knowledge GHOR
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
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.
Decisions Questions
Answers Remarks
Information
Information
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.
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:
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.
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.
Conclusions for activity ‘Use of personnel and resources’ (see Appendix VIII)
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.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:
• 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.
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).
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).
• 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)?
“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.
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.
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.
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.
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,
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
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,
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.
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
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.
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.
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 trade-
offs. 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).
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.
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.
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:
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 time-
critical situations minimum process times are very important as well.
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.
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.
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.
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.
As can be seen in Figure 9, the costs process round is placed at the end of the total decision-
making 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.
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.
- 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).
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.
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:
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 non-
cooperative behavior will lead to objections from the citizens-side. They may decide to
use their (electoral) power also to enforce the actors to cooperate.
- 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
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.
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.
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.
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).
Cluster 4
(3-6-7-9)
Round 1:
Round 2: Cluster 1 Cluster 2 Round 4: Round 5:
generic
requirements (2-8) (1) costs start project
process rules
Cluster 3
(4-5)
time
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.
2
The used abbreviations correspond with those used in Appendix 1; a legend is to be found there.
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 1:
Round 2: Round 3: Round 5:
generic
requirements design issues start project
process rules
Cluster
(exploi-
tation)
time
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
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.
Central exploitation
- Infrastructure related
costs (e.g. maintenance
of lines, switches etc)
- Network management
- Pay off loan3
Regions (Emergency Investments - System implementation
Services and local - Equipments costs - Equipment purchase
governments) - Education costs - Local maintenance
- Regional project costs - Security
- Training
Regional exploitation - Education
- Employees salary - Spatial coverage
- Equipment maintenance planning
Project developer - Infrastructure realisation
- Central project
coordination
- Project guidance
- Implementation support
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.
Round 1: Round 4:
Round 2: Round 3: Round 5:
Generic Costs and
Requirements Design issues Start project
process rules responsibilities
time
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.
The technical design and institutional arrangements will be extensively described in the
following chapters.
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.
Terminals
Etc.
Internet
ARBAC
PC’s Monitoring Devices
CCS-Vnet
GMS
Data layer
Operational
Network Information
Emergency Systems
Room
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.
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.
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).
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.
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
Portal
Application interface
Architecture
Service
Domain
Routing
Service
Architecture
Service
Routing
System
Fliwas
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).
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):
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 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.
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 end-
responsibility 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).
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.
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.
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:
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.
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.
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.
User: 1052381
Main TRL Map Phase: E
12.35, 06/06/06
T R L
Looting shopping centre ‘ de
12.28 !!
Vijfhoek’…
Evacuation of the following
12.04
streets: Handboogstraat, I…
Resistance inhabitants of
11.45 !
Klinkerweg 5: 3 agents ar…
Traffic diversion: In the
11.40
northern part of Oss. P…
Protection of special objects:
11.22
In the centre…
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.
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.
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.
7
This also occurred in the Helga exercise; all local authorities had connected their information systems
and -databases to the GMS
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.
- 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.
- 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
- 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
Relief worker
- 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
GMS Control
room
Medic
Fireman Police officer Police officer
Fireman Medic
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, second-
phase, local governments don’t have to face these problems and costs. To meet these first-
phase 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.
- Project responsibilities
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.
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 one-
step 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:
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.
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.
NRC, Communicatie nog steeds achilleshiel bij grote ramp. The Hague: NRC, July 30, 2005a,
p.2.
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
Sprott, D and Wilkes, L., Understanding Service-Oriented Architecture. On: CBDI Forum,
January 2004.
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.
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, Scotland Votes for the Motorola MTH800 Terminal. April 2004b.
June 9, 2006. www.motorola.com
Governmental documents
ACIR, De Vrijblijvendheid Voorbij. The Hague: Ministry of BZK, 2005.
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.
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.
Maximum
Good repression
application of
preparation
relief services
Unambiguous
Good Good Good Good training Good operational
responsibilities
communication coordination cooperation and excercises planning
and tasks
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
District Water Responsibility for all public • Establishment and • Ineffective • Existence of different • Central position
Boards works departments of the effective execution cooperation Calamity Reports in water calamity
country of the Calamity Plan and • Responsibilities often • Possibility to act
Coordination unclear on own
during a Water authorization
Calamity • Centre of
information on
local water
affairs
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 Interests Goals Core problem Causes Influence
possibilities
The Royal Execute its tasks to the best • To be able to contact • Inability to • Bad coverage and • Lobby within the
Marechausse extend, nationally and other emergency reach capacity of relief Ministry of BZK
e internationally: services and colleagues. services for a better
1. Security colleagues on communication
-Object security international terrains system.
-Ceremonial services (Ministry of Defence, • Negative
-Personal security 2003) feedback in
-Security of value transports C2000
-Security civil aviation evaluation.
2. Police tasks • Relief Support
-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)
Table II.3 - Corresponding and contrasting problem perceptions, interests and goals.
Dedicated actors Non dedicated actors
Critical actors Non-critical Actors Critical actors Non-critical actors
Corresponding problem -Police Department -International Maas -Ministry of VWS -European Union
perceptions, interests and -First Aid Services Commission -The Royal
goals -Fire Department -National Water Marechaussee
-District Water Boards authority -The Royal Netherlands
-Municipalities (Rijkswaterstaat) army
-Provinces -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.
Table III.2 – Extensive and concrete overview considering the need of relief
services during a flood.
National level
Min Defence
Fire Department National Police Regional Police Fire Department Army / Royal First aid medical
(Regional) Department Department (Municipality ) Marechaussee service (public )
Royal
commisioner , GS
Relief services
Board Regional Regional level
Fire Department
City council
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 Weaknesses
− The C2000 network with the Tetra − Difficult to use (NRC, 2005a).
technique has a nationwide covering. − Bad accessibility inside concrete
It’s not necessary anymore to switch buildings (NRC, 15 June 2004).
frequency by leaving the region (De − Possibility to localize users of the
Projectdirectie C2000, 2004). system for outsiders (Parool, 2
− When neighbor countries also have September 2004).
implemented the Tetra technique, − C2000 has a limited data capacity,
border crossing communication is whereas real time information
possible (De Projectdirectie C2000, exchange is not possible (Trouw, 15
2004). June 2004).
− C2000 makes better and faster − Trunking does not exclude full
communication possible. Connections occupation (De Projectdirectie, 1998).
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).
107
− It’s possible to send and receive short − A lot of introduction failures (NRC,
text messages (De Projectdirectie 2005a).
C2000, 2004). − Border crossing communication asks
− In case of disturbance, there exist not only for technical solutions but also
technical and organizational alternatives for clear procedures and agreements
(De Projectdirectie C2000, 2004). (De Projectdirectie C2000, 2004).
− In the future consultation of data files − Trust in the system (“draagvlak”) (NRC,
becomes an option (De Projectdirectie 2004).
C2000, 2004). − Point of no return is passed a long time
− The necessary equipment is purchased ago (Trouw, 15 June 2004).
and implemented in an early stage − Total dependency on the C2000
(Deloitte, 2005). 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).
Opportunities 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.
VII.2 Scale up
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)
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.
VII.4 Flood
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).
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
1. Analyzing relevant information FD, PD, All information that could be of The content of the evacuation plan is made
GHOR, importance in the operational by the municipality, in close relation with
Mun phase of evacuating. other actors. PD (police) executes the
evacuation plan in a later stage.
1.1 Based on information about FD, PD, Nature, dimension of flood; The District Water Board usually holds the
nature, dimension, and GHOR, location; development of information about the characteristics of a
development of calamity Mun flood; information about possible flood, possible future scenarios.
determine whether evacuation is population and public Information about the area is to be found
necessary: buildings. within the different municipalities.
- 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 FD, PD, Possible flood area; local - Because it is a flood, it automatically
be evacuated and nature of GHOR, maps; flood prognoses. crosses municipal borders, and the Royal
evacuation: Mun Commissioner should be reported. In our
9
Handboek Calamity control, deel B, bijlage 4 p.19-22
111
- Inside and outside case we deal with preventive evacuation.
municipality (report to Royal - FLIWAS helps in making scenarios, and
Commissioner); evacuation maps.
- Preventive or immediate;
- Voluntary or forced.
1.3 Emergency regulation needed? FD, PD, Severe emergency situation? This issue will not be taken into account
- If so, quickly make GHOR, Enforcement necessary?
arrangements with ‘OM’ Mun
about issues regarding
justice.
1.4 Based on (on beforehand) FD, PD, Information about population; This part has close relation with the first sub-
aggregated information Mun pets and cattle; special process of determining the need on
determine: buildings /objects; production evacuation. Most of the information has to
- Number of involved persons, & storage facilities; location, come from the municipalities, or from the
pets, cattle, including the characteristics; priorities; province.
mobility of this; responsibilities.
- 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.
112
Table VIII.2 - Activity: Draw up evacuation plan.
Activity Involved Information Notes
actors
2. Draw up evacuation plan FD, PD, In most regions in the The content of evacuation plans need to be
GHOR, Netherlands where adaptable, and when new information
Mun evacuations as a result of becomes available, a swift implementation of
floods are a possibility, there that information into the plan is needed. The
are evacuation plans development of an evacuation plan is possible
available. Depending on the within FLIWAS applications. Part of the
dimension of the possible evacuation plan is an information plan,
flood, and the affected areas, regarding the measures to be taken to inform
this process will partly consist and instruct the public.
of harmonizing the already
existent plans.
2.1 Determine whether a separate FD, PD, Dimension flood; scenarios. In the case of a flood, this will always be the
regional action centre should be GHOR, case, in the form of an Action Team.
set up at regional command Mun
centre.
2.2 These data are necessary for the FD, PD, Available and needed modes This process of arranging all the information,
execution of the sub-plans public GHOR, of protection; geography area; into a practical data, is the result of a
information, warning population, Mun needed number of collection/ collaboration between the actors. An
and taking care of traffic: convoy/ boarding points; information plan is made. Information
- Determine modes of possibilities evacuation routes available at municipalities.
protection for ‘relief services’ and demand of traffic (human
and maximum stay in area. and animal); determination An important aspect is that the time schemes,
- Determine collection-, implementing locations and describing different evacuation steps, with
registration-, convoy-, and action centers; urgency level; each step specific informational aspects. It is
boarding points; flood scenarios. The result is much more efficient when the information
- Determine routes evacuation, an information plan, in which arrives only at times when there is a need for
separated for human and directions are stated within that information.
animal; time schedules.
- Determine first implementing
locations or action centers;
- Determine time schemes for
subsequent evacuation steps.
2.3 Determine the needed languages Mun Demography evacuation area. This is the task of the municipality.
to inform evacuees. Determine
content first and later delivery in
113
cooperation with Information
division.
2.4 Determine required resources in FD, PD, Future demand of traffic Here the connection takes place between the
humans and materials. GHOR, (human/animal); available evacuation demand (so the amount of
- Supporting and controlling Mun relieve sources; needed persons, animals) and the available resources.
personnel (police, military); services (registration/medical The municipality makes a list of the required
- Medical personnel (on the etc.); resources, human and material.
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 PD, Mun Number of evacuation roads; The police department does this in
area, including material for available material. cooperation with the municipality.
sealing area.
2.6 Determine which utility services FD, Mun Number of utility services; The Fire department decides this in
need to be terminated. Criteria is location. cooperation with the municipality. Information
that this should be delayed as available within municipality.
much as possible.
2.7 Determine how area has to be PD, Mun Flood information; evacuation Clearly regards a task that will be executed by
guarded (relation with routes. the Police department, so they are the only
fencing/protection). one involved (next to Municipality)
2.8 Harmonize measures with other Mun --- The whole planning already takes place in a
municipalities, regions, province, regional context, so within the RPT, OT, and
and NCC. other teams.
114
115
Table VIII.3 - Activity: Getting Personnel and Resources ready.
Activity Involved Information Notes
actors
3. Getting personnel and resources FD, PD, List of contacts. In this activity the responsibilities are
ready GHOR, described in a very clear way, which makes
Mun making decisions easier.
3.1 Alarm personnel and take care of FD, PD, Telephone numbers; The literature does not describe that there
required resources. Think of: GHOR, addresses. should be a clear list with data about possible
- Red Cross, family doctors, Mun extra resources, such as Red Cross, family
First Aid relieve workers; doctors, voluntary police, etc. This is essential
- Churches and other similar for a quick reaction on an imminent flood. The
networks; responsibility for this task lays in hands of the
- Social workers; Police Department.
- Voluntary police;
- Military.
Material resources of
- Transport organizations;
- Animal ambulance;
- Cattle transporters;
- Military support.
3.2 Get people in position and Mun Locations for collection and This is a task for the municipality only.
making ready for reception; telephone numbers
- Collection points; people for these points.
- Reception locations.
3.3 Alarm third parties, such as FD List of third parties. This is a task for the Fire Department only.
utility companies.
116
Table VIII.4 - Activity: Use of Personnel and Resources.
Activity Involved Information Notes
actors
4. Use of personnel and resources FD, PD, Many different, result of earlier A clear description of the information (towards
GHOR, activities. population, FD) part is missing. Unclear task
Mun responsibilities.
4.1 Instruct personnel PD, Location; number of people; The police department, and the municipality
GHOR, time schedules; scripts. need to give clear instructions to their
Mun 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.
4.2 Mobilize personnel and Mun Location; task descriptions; This is a very unclear sub-process, because at
resources for: evacuation plan; scenarios; least partly it is a matter for the Police
- Reception and collecting time schedules. Department, with processes such as traffic
points; accompanying, escorting, order maintenance,
- Support of evacuation to while the literature (Handboek Calamity
reception centers; control) leaves this party out, and considers it
- Control and guarding a task of the municipality. Uncertainty about
evacuated area, including the different tasks, and responsibilities are
termination of utility services; highly undesirable.
- Order maintenance;
- Traffic accompanying; Further: the actual evacuation takes place
- Reception of people in within this activity, but there is no relation at
reception centers; all with the activity of informing and
- Instruction people (think of instructing people (FD).
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, Mun Names; objects. This information handling belongs to the
animals, and special objects, as municipality.
well as the spreading and
117
control of it.
118
Table VIII.5 - Activity: Return.
Activity Involved Information Notes
actors
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.
- 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.
In the picture below a clear overview is given of FLIWAS, its programs, and its modules.
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.
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)
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
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.
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 Maintenance Adaptation
Costs Costs Costs
(investment) (exploitation (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
XI.3 Defining actor groups
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.
129
Appendix XII – Technical design
Table XII.1 – Actors involved considering the technical design.
Actor group Roles Actors in this respect
Service provider Organisations that procure the service This should be outsourced on a
implementations, supply their service contract base to (an) external
descriptions and provide related technical party/parties that possess(es)
and business support. the right technical knowledge.
Service client End-user organisations that use the The relief services and the
(consumer) service. emergency rooms.
Service Organizations that consolidate External parties by request of
aggregator multiple services into a new, single the technical management of
service offering. GMS.
Service operator Organization responsible for The technical management of
performing operation management GMS
functions.
Market maker Organization(s) that create and Ministry of Interior and Kingdom
maintain the marketplace. Relations (BZK)
130
Service Manages critical applications and The management:
specific markets.
Management
Layer
− Supports critical applications
that require enterprises to
manage;
o the composite service
o the deployment of
services
o the applications
− Supports open service
marketplaces.
131
that supports calamity control. coordination possible during
calamities.
Multiteam A cooperation application This application makes distance
operation in certain teams
possible.
Diverse digital
information on
intranet:
− Static population, To be used as background
transportation and weather information.
data
− Manuals concerning the To be used as background
used systems information.
Diverse digital
information on
internet:
− Real time transport and To be used as background
weather information information.
− Search engines and To be used as background
132
databases information.
E-mail facility An application for digital indirect Used for communication
communication with on another. purposes.
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.
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.
135
Institutional Requirement Institutional design Norms Time needed Plan of
arrangemen s Satisfied principles and for action
t values implemen-
? tation(month
s)
Interaction Decisions Reliability, yes 6 Ensure that
between should be Scalability, Flexibility WGMS
actors made on a functions
level as low and
as possible determine
most
desirable +
effective
order of
contact
actions
Authorizatio Selective Democratic 3 Set up
n levels authorizatio legitimacy scheme for
n integrating
authorizatio
n levels
Responsibilit Clear Democratic yes 3 Set up
y allocation responsibiliti legitimacy scheme for
es integrating
and responsibiliti
Hierarchy es
should be
very clear
Project costs Democratic yes - Define costs
legitimacy for total
project
Project Clear Credibility/Transpare yes Define
responsibiliti responsibiliti ncy responsibiliti
es es es for total
project
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