Assignment Writing Service http://StudyHub.vip/Agile-Business-Continuity-Planning-Usin 👈

1. Agile Business Continuity Planning
using Business Process Modeling Notation
by
Kirk M. Anne
Submitted in partial fulfillment
of the requirements for the degree of
Doctor of Professional Studies
in Computing
at
School of Computer Science and Information Systems
Pace University
November 2012

2. All rights reserved
INFORMATION TO ALL USERS
The quality of this reproduction is dependent upon the quality of the copy submitted.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, these will be noted. Also, if material had to be removed,
a note will indicate the deletion.
Microform Edition © ProQuest LLC.
All rights reserved. This work is protected against
unauthorized copying under Title 17, United States Code
ProQuest LLC.
789 East Eisenhower Parkway
P.O. Box 1346
Ann Arbor, MI 48106 - 1346
UMI 3570821
Published by ProQuest LLC (2013). Copyright in the Dissertation held by the Author.
UMI Number: 3570821

3. We hereby certify that this dissertation, submitted by Kirk M. Anne, satisfies the
dissertation requirements for the degree of Doctor of Professional Studies in Computing
and has been approved.
_____________________________________________ - ________________
Fred Grossman Date
Chairperson of Dissertation Committee
_____________________________________________ - ________________
Charles C. Tappert Date
Dissertation Committee Member
_____________________________________________ - ________________
Ronald I. Frank Date
Dissertation Committee Member
School of Computer Science and Information Systems
Pace University 2012

4. Abstract
Agile Business Continuity Planning
using Business Process Modeling Notation
by
Kirk M. Anne
Submitted in partial fulfillment
of the requirements for the degree of
Doctor of Professional Studies
in Computing
November 2012
Many current business continuity plans focus on the technology of an organization, not
on the processes. This research investigates how using agile methodology and business
process modeling can change the efficiency and effectiveness of business continuity
planning.
Recent surveys of business continuity planners indicate that testing business continuity
plans exposes problems and provides an opportunity to correct and improve them.
However, in practice, plans are rarely tested after their creation and happen only after
they are completed. Current business continuity planning practice is similar to the
traditional waterfall method of software design and levies a significant drain on an
organization’s resources to develop plans. This dissertation explores the use of agile
techniques, like designing plans using “test first” design, focusing on the highest value
processes first, and developing quality plans with the minimum of effort and error.
This dissertation presents an agile methodology that harnesses “test first” development of
plans using business process modeling notation (BPMN). It focuses on the continuity of
processes, not the causes of a disruption. This methodology allows for a more organic
approach to business continuity where IT staff and business process owners collaborate
closely and leverage proven agile and test-driven development techniques. The agile
techniques allow for a lightweight method of planning that reduces unnecessary work.
By using BPMN, a machine executable notation, plans are easier to test by computer.
Since BPMN is also graphical, plans developed in BPMN are less ambiguous, less
inconsistent, and easier to communicate with others within and outside an organization.

5. Acknowledgements
I would like to thank everybody who helped me through the research process and the
endeavor of creating this document.
I thank my advisor, Dr. Fred Grossman, who helped me take the large boulder of a topic
and form the “nugget” that enabled me to proceed. I thank the members of my
committee, Dr. Charles Tappert and Dr. Ronald Frank, for their valuable contributions
and suggestions.
I thank the Seidenberg CSIS DPS faculty who helped me along my journey, especially
Dr. Joe Bergin, Dr. Lixin Tao, and Dr. Liu-Chou Chen.
I thank Susan Chichester and CIT for putting up with me during the last four years as I
pursued this quest. I especially thank my team, the Systems & Networking Group (Rick
Coloccia, Jay Masters, Craig Moscicki, Shawn Plummer, Craig Ross, and David
Warden), who kept everything running while I worked on this. I am eternally grateful for
excellent colleagues like Laurie Fox, Laura Rice, and Paul Jackson.
I am extremely grateful for my DPS dissertation team: Carolyn Sher-Decusatis, Joseph
Massi, Jill O’Sullivan, and John Stewart. Although I lost our bet, I am so glad I had their
support and could assist them with their journeys. I would like to also thank Carolyn’s
husband, Dr. Casimer DeCusatis, for his perspective and respected advice.
I sincerely appreciate the Geneseo faculty who pushed me and provided me with such a
solid foundation. I would like to especially thank Homma Farian, Dr. Peter Markulis, Dr.
David Meisel, and Dr. Michael Horn for their valuable insight and editorial comments on
my manuscript.
Finally, I thank my family for being there for me.

6. v
Table of Contents
Abstract..............................................................................................................................iii
Acknowledgements............................................................................................................ iv
List of Tables ...................................................................................................................... x
List of Figures.................................................................................................................... xi
Chapter 1 Introduction..................................................................................................... 1
1.1 Thesis statement..................................................................................................... 1
1.2 Definition of the research problem ........................................................................ 2
1.3 Current business continuity methodologies........................................................... 3
1.4 Proposal for a new business continuity methodology............................................ 6
1.4.1 Key Practice #1: Use of agile methodologies................................................. 6
1.4.2 Key Practice #2: Encapsulation of Plans in BPMN........................................ 8
1.5 Scope...................................................................................................................... 9
1.6 Research Methodology .......................................................................................... 9
1.7 Significance of the Research................................................................................ 10
1.8 Organization of the Dissertation.......................................................................... 10
Chapter 2 Traditional Approach to Business Continuity............................................... 11
2.1 What is business continuity?................................................................................ 11
2.1.1 Definition of Business Continuity ................................................................ 11
2.1.2 Business Continuity Lifecycle...................................................................... 14
2.2 Motivations for business continuity planning...................................................... 17
2.3 History of Business Continuity............................................................................ 18
2.4 Time line of a business continuity plan ............................................................... 21
2.5 Current standard practices of business continuity ............................................... 22
2.6 Format of traditional business continuity plans................................................... 24
2.7 Observations ........................................................................................................ 26
2.8 Limitations of the current methodology .............................................................. 26
2.8.1 Priority .......................................................................................................... 28
2.8.2 Coverage ....................................................................................................... 29
2.8.3 Veracity......................................................................................................... 29
2.8.4 Communication............................................................................................. 30
2.8.5 Testing........................................................................................................... 30
Chapter 3 Agile Techniques for BCP ............................................................................ 33
3.1 A new methodology for business continuity planning ........................................ 33
3.2 Basic agile principles........................................................................................... 34
3.3 Agile Manifesto ................................................................................................... 36
3.3.1 Individuals & Interactions Over Process & Tools........................................ 36
3.3.2 Working Software Over Comprehensive Documentation............................ 37
3.3.3 Customer Collaboration Over Contract Negotiation .................................... 38
3.3.4 Responding to Change Over Following a Plan............................................. 39
3.4 Optimal environment for an agile methodology.................................................. 40

7. vi
3.5 Agile Principles.................................................................................................... 42
3.5.1 Working Software......................................................................................... 43
3.5.2 Collaboration................................................................................................. 44
3.5.3 Change .......................................................................................................... 44
3.5.4 Individuals & Interactions............................................................................. 45
3.6 Agile Practices ..................................................................................................... 45
3.6.1 Iterative development.................................................................................... 45
3.6.2 Collaborative development........................................................................... 46
3.6.3 Test-driven development .............................................................................. 46
3.6.4 Refactoring/reuse.......................................................................................... 47
3.7 Summary of agile techniques in agile business continuity.................................. 48
Chapter 4 Test-Driven Development............................................................................. 49
4.1 Motivation for test-driven development .............................................................. 49
4.2 Design components of test-driven development.................................................. 50
4.2.1 Charter........................................................................................................... 51
4.2.2 Features......................................................................................................... 52
4.2.3 Stories ........................................................................................................... 52
4.2.4 Scenarios....................................................................................................... 54
4.2.5 Tests.............................................................................................................. 55
4.3 Summary.............................................................................................................. 56
Chapter 5 Modeling Processes and Plans ...................................................................... 57
5.1 What is a Business Process? ................................................................................ 57
5.2 Types of Business Processes................................................................................ 58
5.3 What is a plan?..................................................................................................... 59
5.4 Differences between Process and Plan ................................................................ 59
5.5 What is Business Process Modeling? .................................................................. 60
5.6 Business process modeling - background and history......................................... 61
5.6.1 Origins of the business process - 1776 ......................................................... 61
5.6.2 Scientific management - early 1900s............................................................ 61
5.6.3 Effect of computing on management – 1960s and 1970s............................. 62
5.6.4 The quality era - 1980s ................................................................................. 62
5.6.5 Business process re-engineering (BPR) - 1990s........................................... 63
5.6.6 Business process modeling - 2000s .............................................................. 63
5.7 Hierarchy of Processes in BPM........................................................................... 64
5.8 Modeling a business process - an overview......................................................... 65
5.9 Goals of business process modeling .................................................................... 66
5.10 Business Process Modeling Techniques............................................................ 67
5.10.1 Flowcharting ............................................................................................... 67
5.10.2 Integrated Definition for Function (IDEF) techniques ............................... 68
5.10.3 Unified Modeling Language (UML) .......................................................... 70
5.10.4 Architecture of Information Systems (ARIS)............................................. 70
5.10.5 Business Process Modeling Notation (BPMN)........................................... 71
5.11 Workflow Patterns ............................................................................................. 72
5.12 BPMN 1.0’s suitability to model processes....................................................... 73

8. vii
5.12.1 BPMN 1.0 Modeling of Workflow Control-Flow patterns ........................ 73
5.12.2 BPMN 1.0 Modeling of Workflow Exception Patterns.............................. 76
5.13 BPMN 2.0 and Oracle BPM Studio................................................................... 84
5.14 Summary............................................................................................................ 86
Chapter 6 Business Process Model and Notation .......................................................... 87
6.1 What is BPMN?................................................................................................... 87
6.2 History of BPMN................................................................................................. 87
6.3 Levels of BPMN .................................................................................................. 89
6.3.1 The descriptive level of BPMN (Level 1)..................................................... 90
6.3.2 The analytical level of BPMN (Level 2)....................................................... 90
6.3.3 The executable level of BPMN (Level 3)..................................................... 91
6.4 Basic components of BPMN................................................................................ 91
6.4.1 Flow Objects................................................................................................. 92
6.4.2 Pools and lanes............................................................................................ 100
6.4.3 Data Objects................................................................................................ 101
6.4.4 Data Inputs.................................................................................................. 101
6.4.5 Artifacts....................................................................................................... 103
6.5 Other components of BPMN ............................................................................. 103
6.5.1 Processes..................................................................................................... 103
6.5.2 Choreographies ........................................................................................... 104
6.6 BPMN tools ....................................................................................................... 105
6.6.1 Oracle’s BPM Suite 11g ............................................................................. 106
6.6.2 Intalio’s BPMS Designer............................................................................ 106
6.6.3 Trisotech’s BPMN 2.0 Modeler for Visio .................................................. 106
Chapter 7 Agile Business Continuity Planning Methodology..................................... 107
7.1 Introduction........................................................................................................ 107
7.2 ABC Step 1: Develop a plan charter and overall model.................................... 108
7.2.1 Define the initial plan charter ..................................................................... 109
7.2.2 Develop the organization’s overall model.................................................. 110
7.3 ABC Step 2: Build the Feature/Process List...................................................... 111
7.3.1 Compile a list of key business processes.................................................... 111
7.3.2 Define minimum criteria for operations ..................................................... 111
7.3.3 Analyze impact of disruptions on key business processes.......................... 112
7.4 ABC Step 3: Planning process........................................................................... 112
7.4.1 Highest value .............................................................................................. 113
7.4.2 Highest dependency.................................................................................... 113
7.5 ABC Step 4, 5, and 6: Story, Test, Response .................................................... 113
7.5.1 ABC Step 4: The Story is the Test and the Test is the Story...................... 114
7.5.2 ABC Step 5: Test ........................................................................................ 114
7.5.3 ABC Step 6: Response................................................................................ 115
7.5.4 Repeat, if necessary .................................................................................... 115
7.6 Strategies for testing .......................................................................................... 116
7.6.1 Depth-first versus Breadth-first .................................................................. 116
7.6.2 Uncertainty versus Familiarity.................................................................... 116

9. viii
7.6.3 Highest value versus Easiest attainability................................................... 117
7.6.4 Happy Path versus Edge/Error Conditions ................................................. 117
7.7 Using BPMN to simulate the situation .............................................................. 117
7.8 The next step...................................................................................................... 119
7.9 Summary............................................................................................................ 120
Chapter 8 Example Scenario using Agile Business Continuity Planning (ABCP) ..... 121
8.1 Introduction........................................................................................................ 121
8.2 A plan developed by traditional (current) BC methodologies........................... 121
8.3 Overview of an agile business continuity planning process.............................. 123
8.4 Dual agile development of the model and business continuity plan.................. 123
8.5 First phase of the ABC process (Plan Charter/Overall Model) ......................... 124
8.6 Second phase of the ABC process (Building the feature process story list)...... 125
8.7 Third Phase of the ABC process (Planning process)......................................... 125
8.8 Initial “business process” model development .................................................. 126
8.8.1 Initial building parameters.......................................................................... 127
8.8.2 Processes within this model........................................................................ 127
8.8.3 Modeling initial key activities (stairs/elevator) .......................................... 128
8.8.4 Construction of the initial model ................................................................ 129
8.8.5 First iteration and model development acceptance test .............................. 137
8.8.6 Running the first iteration simulation model .............................................. 138
8.8.7 Second iteration of simulation model ......................................................... 140
8.8.8 Running the second iteration simulation model.......................................... 147
8.8.9 Third iteration of the simulation model ...................................................... 149
8.9 Fourth Phase of the ABC process (First iteration of story, test, response)........ 151
8.10 Developing the Agile Business Continuity Plan.............................................. 154
8.11 First “Elevator component of BC plan” iteration ............................................ 155
8.12 First review of “Elevator component of BC plan”........................................... 156
8.13 Second “Elevator component of BC plan” iteration........................................ 157
8.14 Second review of “Elevator component of BC plan”...................................... 158
8.15 First iteration of “Staircase component of BC plan” ....................................... 158
8.16 First review of “Staircase component of BC plan”.......................................... 159
8.17 Second iteration of “Staircase component of BC plan”................................... 160
8.18 Second review of “Staircase component of BC plan” ..................................... 162
8.19 Questions for the stakeholders (feedback)....................................................... 162
8.19.1 Continuity Option 1: Extend maximum transition time ........................... 163
8.19.2 Continuity Option 2: Reduce the number of people who have to move... 163
8.20 Final Business Continuity Plan........................................................................ 164
8.21 Future possible iterations................................................................................. 165
8.22 Summary.......................................................................................................... 166
Chapter 9 Applying Agile BCP to an Existing Plan.................................................... 168
9.1 Background........................................................................................................ 168
9.2 Converting plans from text to BPMN................................................................ 168
9.2.1 Defining tests from existing plans .............................................................. 170
9.2.2 Initial execution of tests.............................................................................. 170

10. ix
9.2.3 Developing responses ................................................................................. 172
9.3 Refinement through the second iteration........................................................... 175
9.4 Subsequent iterations of the methodology......................................................... 176
Chapter 10 Conclusions and Future Opportunities...................................................... 177
10.1 Results.............................................................................................................. 177
10.2 Easier to understand and communicate............................................................ 177
10.3 Identifying bottlenecks, inconsistencies, and illogical work flow................... 178
10.4 Focusing on business processes, not the technology ....................................... 178
10.5 Scaling to the appropriate level of detail and coverage................................... 178
10.6 Easier to reuse.................................................................................................. 179
10.7 Encapsulating a process workflow and resources............................................ 179
10.8 Easier to test..................................................................................................... 179
10.9 Conclusions...................................................................................................... 180
10.10 Future opportunities....................................................................................... 180
Sample Business Continuity Plan ........................................................... 182
Appendix A
A.1 Introduction....................................................................................................... 182
A.2 Policy Statement ............................................................................................... 182
A.3 Introduction....................................................................................................... 182
A.4 Confidentiality Statement ................................................................................. 183
A.5 Manual Distribution.......................................................................................... 183
A.6 Manual Reclamation ......................................................................................... 184
A.7 Plan Revision Date............................................................................................ 184
A.8 Defined Scenario............................................................................................... 184
A.9 Recovery Objectives ......................................................................................... 185
A.10 Plan Exclusions............................................................................................... 185
A.11 Plan Assumptions............................................................................................ 185
A.12 Declaration Initiatives..................................................................................... 186
A.13 Recovery Strategies......................................................................................... 186
A.14 Team Overview............................................................................................... 187
A.15 Team Charters................................................................................................. 187
A.16 Recovery Strategies......................................................................................... 188
A.17 Emergency Phone Numbers............................................................................ 189
A.18 Threat Profile .................................................................................................. 190
A.19 Recovery Strategy Overview .......................................................................... 191
A.20 Plan Participants.............................................................................................. 193
A.21 Alternate Site Setup ........................................................................................ 193
A.22 Recovery Ranking........................................................................................... 195
A.23 Recovery Team Checklists.............................................................................. 196
References....................................................................................................................... 198

11. x
List of Tables
Table 1 Pitfalls in business continuity planning ................................................................. 5
Table 2 Elements of business continuity & disaster recovery.......................................... 12
Table 3 Average Cost per Hour Impacts on Businesses of Web Site Downtime............. 20
Table 4 Exploring Assumptions about BCM Provision ................................................... 21
Table 5 Optimal environments for agile and plan-driven methodologies ........................ 41
Table 6 Twelve Agile Principles....................................................................................... 42
Table 7 Types of Business Processes................................................................................ 65
Table 8 Control-Flow Patterns.......................................................................................... 74
Table 9 Control-Flow Patterns (continued) ...................................................................... 75
Table 10 Work Activity Failure Patterns.......................................................................... 81
Table 11 Work Activity Deadline Patterns....................................................................... 82
Table 12 External Trigger Patterns................................................................................... 83
Table 13 Constraint Violation Patterns............................................................................. 84
Table 14 Experimental Transition Data Collected.......................................................... 128
Table 15 Total times for normal state simulation (in seconds)....................................... 151
Table 16 Result Data from Simulation Runs.................................................................. 152
Table 17 Situation stories and Priorities......................................................................... 155
Table 18 Parameter settings for elevator simulations..................................................... 155
Table 19 Total times of elevator situations using first model (in seconds) .................... 156
Table 20 Total times of elevator situations using model in Figure 50 (in seconds)....... 157
Table 21 Parameter settings for staircase simulations.................................................... 158
Table 22 Total times of situations using model in Figure 50 (in seconds)..................... 159
Table 23 Parameter settings for third iteration of staircase simulations......................... 161
Table 24 Average total times of situations using third model (in seconds).................... 162
Table 25 Total times of situations using model in Figure 53 ......................................... 166
Table 26 Hazards List from Sample Plan ....................................................................... 169
Table 27 Sample responses to hazards............................................................................ 171

12. xi
List of Figures
Figure 1 Current Standard Business Continuity Planning Process..................................... 3
Figure 2 Waterfall Approach and documents generated..................................................... 4
Figure 3 Test Driven Design Model ................................................................................... 7
Figure 4 Timeline of a business continuity plan............................................................... 13
Figure 5 BS 25999 definition of Business Continuity Lifecycle...................................... 14
Figure 6 Business Continuity Planning time line ............................................................. 22
Figure 7 Risk Map with various threat causes.................................................................. 25
Figure 8 Sample business continuity objective................................................................. 51
Figure 9 General format of a user story............................................................................ 53
Figure 10 Example story for evacuation........................................................................... 53
Figure 11 Sample scenario describing evacuation from third floor.................................. 55
Figure 12 Sample test in Given/When/Then format......................................................... 56
Figure 13 Example of an ICOM diagram from IDEF0..................................................... 69
Figure 14 BPMN Activities .............................................................................................. 93
Figure 15 Task Markers.................................................................................................... 94
Figure 16 Task Types........................................................................................................ 95
Figure 17 BPMN Event Icons........................................................................................... 96
Figure 18 BPMN Gateway icons...................................................................................... 98
Figure 19 BPMN Sequence Flows.................................................................................. 100
Figure 20 BPMN swim lanes.......................................................................................... 101
Figure 21 BPMN Data Objects....................................................................................... 102
Figure 22 Example of BPMN Collaboration .................................................................. 104
Figure 23 BPMN Choreographies .................................................................................. 105
Figure 24 Agile Business Continuity Process Chain...................................................... 108
Figure 25 Simplest BPMN diagram................................................................................ 117
Figure 26 Simplest BC BPMN diagram ......................................................................... 119
Figure 27 Dual Agile Development Cycle...................................................................... 124
Figure 28 First floor plan example.................................................................................. 126
Figure 29 Second floor plan example............................................................................. 127
Figure 30 Create a new BPM project.............................................................................. 131
Figure 31 Create BPM Project........................................................................................ 131
Figure 32 BPMN Project Navigator ............................................................................... 132
Figure 33 Create BPMN Process Step 1......................................................................... 133
Figure 34 Create BPMN Process Step 2......................................................................... 134
Figure 35 New "Transition" BPMN diagram ................................................................. 135
Figure 36 Transition process without Message Events................................................... 136
Figure 37 Simulation Model Window for Transition Model.......................................... 137
Figure 38 Initial Simulation Definition for "Transition" ................................................ 139
Figure 39 BPMN simulation running ............................................................................. 140
Figure 40 Inserting Exclusive Gateway.......................................................................... 141
Figure 41 Addition of first activity (Stay on same floor) ............................................... 142

13. xii
Figure 42 Addition of Stairs and Elevator...................................................................... 142
Figure 43 Elevators and Stairs activities connected ....................................................... 143
Figure 44 Probabilities for outgoing flows from "Route" .............................................. 144
Figure 45 Outgoing flow probabilities for first test........................................................ 145
Figure 46 Instance Execution Duration for "Elevator"................................................... 146
Figure 47 Number of threads (capacity) of Elevator activity ......................................... 147
Figure 48 Second iteration of simulation........................................................................ 148
Figure 49 Initial BPMN diagram for transition process model (Initial First Model) ..... 150
Figure 51 Modification of first BPMN model from Figure 50 (Second Model)............ 157
Figure 52 Third BPMN model diagram for class transitions (Third Model).................. 160
Figure 53 Transition Time versus 2nd Floor Capacity................................................... 163
Figure 54 Modification of first model to handle stair delays.......................................... 165
Figure 55 Freezing Rain.................................................................................................. 172
Figure 56 Tornadoes ....................................................................................................... 172
Figure 57 Floods ............................................................................................................. 172
Figure 58 Hurricanes....................................................................................................... 172
Figure 59 Earthquakes .................................................................................................... 172
Figure 60 Urban Fires..................................................................................................... 173
Figure 61 Power Failures................................................................................................ 173
Figure 62 Simplified threat profile BPMN diagram....................................................... 173
Figure 63 Threat to Equipment BPMN diagram............................................................. 174
Figure 64 Threat to Employee BPMN diagram.............................................................. 174
Figure 65 BPMN of Evacuation Process ........................................................................ 176

14. 1
Chapter 1
Introduction
1.1 Thesis statement
The thesis of this dissertation is the use of agile software design methodologies and
encapsulation of business continuity plans into Business Process Modeling Notation
(BPMN) can improve the planning process of an organization’s business continuity. The
prevailing methodologies for business continuity management use a traditional
heavyweight approach, similar to the waterfall approach used in software design [57]
[55] [30], that consumes vital organizational resources and provides business continuity
plans that are often untested, outdated, or non-existent for many organizations. [95] By
focusing on critical business processes of an organization and involving all the
stakeholders using an agile development process to develop a business continuity plan,
the agile business continuity (ABC) planning methodology expressed in this dissertation
will show how planners can develop more effective business continuity plans (BCP),
using less organizational resources. Using an agile business continuity methodology,
planners create acceptance tests from all the details, risks, and costs necessary to define
and validate business continuity for the organization. Once developed, the acceptance
tests focus the development of business continuity plans. Planners use the tests to develop
and deliver improved plans through the use of agile methods, leading to a more effective
and efficient way. Encapsulation of these plans and tests in a machine executable format

15. 2
enables the automated simulations of a plan within a virtual environment. Using
simulations requires fewer physical resources from the organization and provides easier
testing, improvement, and verification of resulting plans. [129]
1.2 Definition of the research problem
Like globalization, heavy reliance on information technology, and lean manufacturing,
evolving business trends have made many organizations increasingly susceptible to
disruptive natural or human events. According to a Business Continuity Institute study
from 2009 [33], three quarters of the respondents (148 out of 201) reported a disruption
of business processes within the previous 12 months. Although the origins of business
continuity come from a desire to mitigate IT disruptions from disasters (disaster
recovery), the problem has blossomed into dealing with disruptions of any business
process. Events that caused disruptions in an organization include information technology
failures, telecommunications breakdown, adverse weather, staff absence
(illness/death/strike), failure of a supplier or service provider, lack of energy supply, or
transportation issues. Impacts from such events listed in the survey were loss of
productivity, increased cost of working, service outcome impaired, staff absence, product
release delay, customer complaints received, loss of revenue, and loss of access to
facilities. While it is impossible to plan for every type of event or disruption,
organizations that prepare for handling disruptive events and mitigate the potential
impacts have a better chance of recovering.
Without a plan for business continuity, 75% of organizations that experience a significant
disruption fail within three years. [21] In a recent study, Kadlec and Shopshire found that

16. 3
up to 60% of US organizations do not have plans for business continuity. [86] Once
written, organizations rarely update plans to reflect the changes within the organization.
In another survey by the Chartered Management Institute, half of those who do have
plans do not test them. [39] Even after testing the plans and finding problems, 15% of the
tested plans were not revised or updated. The EDUCAUSE 2007 survey [163] revealed
only one third of the respondents tested the readiness of staff and plans to support
business continuity. The third of respondents who did test their plans agreed that testing
improves plans and procedures for business continuity.
1.3 Current business continuity methodologies
Current business continuity planning methodologies have a strong emphasis on the use of
heavyweight traditional waterfall-style method to develop plans and identify numerous
risks and eventualities. [57] [55] [30] [98] Figure 1 illustrates the current standard
approach to preparing business continuity plans.
Figure 1 Current Standard Business Continuity Planning Process
Program
Initiation
Risk
Evaluation
Business
Impact Analysis
Develop
Continuity
Strategies
Develop
Continuity
Plans
Test
Continuity
Plans
Operational
Status

17. 4
The current methodology for business continuity planning is very analogous to those of
early software development. The “waterfall approach” and post-production testing
defined the standard software development practice up to the end of the 20th
century, as
illustrated in Figure 2. [130] In the “waterfall approach”, developers collect all known
requirements and specifications for a project and this collection becomes the basis for
development. Test creation and execution occurs after the completion of development to
verify the product. Unfortunately, errors found after the completed development phase
are very expensive to fix. The requirements and specifications documented at the
beginning of the project usually do not reflect those at the end of the project.
Figure 2 Waterfall Approach and documents generated
/,
I0:
w
Z
/oo
i
,~
g
~
Irl
.
.
o
i0
.
i
IIII
~,-
,,*,1
=
•
.
~
illl
~
$
~
m
z
~
_
~
u,
E
X
E
8
"
0
Ill
N
~
,
.~-
r"
.2
/
"
z_
,,,.
~
~
E
~OLU
a
.
.
~
N
N
I
Z
,
~
,
-
w
i
-
,
<
~
t
-
LL
333

18. 5
The current “waterfall approach” to business continuity is woefully inadequate for
today’s dynamic small and medium-sized business environments and has a number of
pitfalls, as identified by Lam in Table 1. [95] Current economic and business conditions
magnify the constraints on an organization’s resources for business continuity and the
severity of these pitfalls. Good continuity plans depend on the rapid availability of
resources during an incident, like money, equipment, space, and experienced staff.
Table 1 Pitfalls in business continuity planning
Plans can be… Description
Incomplete
The BCP process is not complete. Outputs such as the business
continuity plan and policy either do not exist or exist in incomplete
form.
Inadequate
The plan and strategies can’t deal with the level of risk that the
organization deems acceptable.
Impractical
The plan is not practical or achievable within the organization’s
constraints (manpower, time, and budget, for example).
Overkill
The plan is overly elaborate or costly with respect to the overall level
of business risk that the organization is willing to take.
Poorly
communicated
The business continuity team has not communicated the plan to all
the right people. Staff— both management and technical—remains
unaware of business continuity issues.
Lacking a
defined process
Business continuity processes remain ill defined. Staffers are unsure
of how to react in a failure scenario, or they discover too late that
their existing processes fall short.
Untested
The organization hasn’t tested its plan, or hasn’t tested it thoroughly
enough to provide a high level of confidence in its soundness.
Uncoordinated
The business continuity effort lacks organization and coordination.
The organization has either not established a business continuity
team, or the team lacks individuals who can effectively drive the
effort to completion.
Out of date
The plan hasn’t been reviewed or revised in light of changes in the
organization, its business, or technology.
Lacking in
recovery thinking
The organization doesn’t adequately address how it intends to
recover to a fully operational state after executing its business
continuity plans.

19. 6
1.4 Proposal for a new business continuity methodology
To address the pitfalls listed in Table 1, this dissertation proposes a new methodology
based on two key practices, the use of agile methodologies and the encapsulation of
business continuity plans in a machine-executable format. This dissertation provides the
material for the argument that the proposed methodology enables the development of
plans to be more efficient and produces more effective plans.
1.4.1 Key Practice #1: Use of agile methodologies
In 2001, the Agile Alliance developed a lightweight methodology for developing
software. Agile methodologies grew and developed to address the shortcomings of the
waterfall approach and thus should address those found in the current methodology for
business continuity planning. The core values of agile methodologies are also those of
good business continuity plans. Research indicates agile methodologies improve the
delivery and quality of software. Larman defined the key motivations for using agile
techniques, some of which are: [96]
• Accommodate change throughout development
• Early risk mitigation and discovery
• Manageable complexity
• Confidence and satisfaction from early, repeated success
• Higher quality results and less defects
• Final product better matches true client desires
• Communication and engagement required
• Shorter time to first operational release and releases more often
• Reduced amount of process and project documentation
• Increased customer participation
The methodology proposed in this dissertation leverages these motivations. The
methodology uses six basic phases. In the first phase, planners develop an overall model
of the organization and its processes, similar to Kent Beck’s extreme programming (XP)

20. 7
“metaphor” concept. [17] After they create the overall model, the second phase is where
planners build a list of critical processes that form the planning project’s workload. From
the critical process list, each critical activity or process is broken down into groups of
sub-processes to form process sets. In the third phase, the planners prioritize and
assemble the process sets into an initial high-level plan. The last three phases form the
iterative cycles of designing, building, and testing plans. Feedback from all the steps goes
back into updating the initial overall model and improving the overall model and list of
processes.
1.4.1.1 Test-driven design (TDD)
Test-driven design (TDD) [17] [8] [4] is an iterative approach, used in agile software
development, that combines test-first development where you write a test before you
write any code and writing just enough production code to fulfill that test, as seen in
Error! Reference source not found.. [4]
Figure 3 Test Driven Design Model

21. 8
TDD helps developers thoroughly review and define the requirements and design of a
project before any work is done. Martin, Newkirk, and Koss [99] view one goal of TDD
is the specification of requirements and design.
The methodology proposed in this dissertation harnesses agile test-driven design to
develop and test business continuity plans. Using the principles of agile development,
planners focus on the most critical business processes first. Using the principles of test-
driven development, acceptance tests define the resource requirements and acceptable
productivity levels. Feature stories of how a process works, disruption stories of how the
process might fail, and acceptance tests are used in the agile development of plans.
1.4.2 Key Practice #2: Encapsulation of Plans in BPMN
The product from the first key practice is the encapsulation of business continuity plans
into a machine-executable format. The machine-executable format used in this
methodology is the Business Process Model and Notation version 2.0 (BPMN). [114] The
use of BPMN has additional benefits of being a graphical format that provides easy
creation and communication to non-technical staff and being an accepted standard for
documenting business processes. One of the major drawbacks of current business
continuity planning methodologies is that the functional plan artifacts are almost
completely textual. [165] Textual plans are often ambiguous and inconsistent.
Encapsulating plans in BPMN allows plans to be tested automatically with computer
programs and are less ambiguous. [165] [28] Changing the planning process from a
textual exercise into one that produces software can leverage the proven benefits of agile
software design methods. Simulations using BPMN can provide estimations of recovery
time objectives and allow computerized testing within a virtual environment that requires

22. 9
fewer resources from the organization. Simulations have been a central tenet in business
continuity planning. [36] [137] [146] However, the majority of these simulations are done
by hand as “desktop exercises” or drills, which are time-intensive and involve many
people.
1.5 Scope
Some types of organizations, like financial institutions, hospitals, and utility companies,
have regulations or other requirements that demand current functional business continuity
plans, the necessary resources, and appropriate testing and maintenance of those plans.
[108] However, many organizations, outside of these types, do not have these regulations
or requirements and still have a need for business continuity. This dissertation focuses on
the feasibility of agile business continuity for organizations with severe restrictions on
staff time and equipment for testing. The design of this methodology best caters to small
or mid-sized organizations that have a dynamic environment and limited resources.
1.6 Research Methodology
The methodology of this research will use validation by example. As published academic
research on BPMN in business continuity planning is minimal, this study will evaluate
the use of BPMN within business continuity planning by comparing it to existing textual
plans and how developing plans using an agile methodology changes the outcome from a
traditional approach.

23. 10
1.7 Significance of the Research
The agile business continuity planning design methodology described by this dissertation
provides ways to simplify the business continuity planning process and allow for easier
testing and verification of business continuity plans. Using agile methods to produce
BPMN plans provides a lightweight way to involve stakeholders in plan development. By
doing so, ABC planning produces quality functional plans quickly with fewer defects.
Many organizations can benefit from a simplified process to producing functional
business continuity plans. Through the techniques presented in this document, planners
can build high-value plans in a sustainable way. Furthermore, the resulting plans can be
easily tested in an automated way.
1.8 Organization of the Dissertation
This chapter introduced the primary thesis of the dissertation and an overview of the
research problem space. The rest of the dissertation presents the current state of business
continuity planning, the necessary background and justification of how the proposed
methodology works, and how it addresses the research problem.
The following chapters are:
• Traditional Approach to Business Continuity – the current methodology for BCP
• Agile Techniques for BCP – agile techniques used by the methodology
• Test Driven Design – techniques from test driven design used by agile BCP
• Modeling Processes and Plans – techniques of process modeling
• Business Process Model and Notation – an introduction to BPMN
• Agile Business Continuity – a description of the ABC process and outputs
• Example Scenarios – two examples of how ABC works
• Conclusions – discussion of the contributions, implications, and future work

24. 11
Chapter 2
Traditional Approach to Business Continuity
2.1 What is business continuity?
Though there have been a lot of definitions of business continuity and what it requires,
there is no way to have the perfect plan for all disruptions or disasters. [98] The
fundamental idea of business continuity aims to manage various types of business risks
that have a huge impact on a company, responding satisfactorily in extreme situations
(catastrophic events) with pre-defined business continuity plans (BCP). [165] Following
a functional BCP, the continuation of the organization’s value chain of critical business
processes at an acceptable level is ensured. [23]
Cerullo defines a BCP as a plan that avoids or mitigates risks, reduces the impact of a
crisis (i.e., disaster condition), and reduces the time to restore conditions to a state of
“business as usual.” [37] There is no single recommended plan for business continuity.
Every organization must develop a comprehensive BCP based on its unique situation. A
BCP should also be dynamic, evolving as the organization’s environment and its
dependencies change.
2.1.1 Definition of Business Continuity
There are two main definitions of business continuity. The Publicly Available
Specification 56 (PAS 56) [81] defines business continuity as a “holistic management
process that identifies potential impacts that threaten an organization and provides a

25. 12
framework for building resilience and the capability for an effective response that
safeguards the interests of its key stakeholders, reputation, brand and value-creating
activities.” In the British standard definition of business continuity called BS 25999 [30],
the British Standards Institute (BSI) redefined it as the “strategic and tactical capability of
the organization to plan for and respond to incidents and business disruptions in order to
continue business operations at an acceptable predefined level.” The PAS 56 definition
focuses on the dependents and effects of business continuity. The BS 25999 definition
concentrates on the operational components of business continuity. Table 2 defines some
of the terms used in business continuity.
Table 2 Elements of business continuity & disaster recovery
Element Definition
Disruption or disaster
Unforeseen event having a disruptive impact on a
critical process
Critical Process
A process that if interrupted and not recovered in a
certain time span causes the organization to fail
Maximum Acceptable
Downtime (MAD)
The maximum period of time within which the
organization’s activities and functions must be fully
recovered before the outage compromises business
objectives and overall operational viability
Maximum Tolerable Period of
Disruption (MTPD)
The maximum time an organization can survive
without a minimum level of business activity
Recovery Point Objective
(RPO)
The state of business processes to restore after a
disruption has occurred
Time to Recover (TTR)
The time taken to fully recover the IT and business
processes
Figure 4 illustrates the productivity of an organization during the invocation of a BCP.
After the disruption occurs, the emergency response begins. When the situation is stable
enough for recovery to occur, the recovery stage begins.

26. 13
Figure 4 Timeline of a business continuity plan
Once the recovery time objective is met, the most critical activities can resume. After the
restoration of all normal operations is complete, the continuity plan returns to the
standard operating procedures. The time to recover (TTR) must be less than or equal to
the maximum acceptable downtime (MAD). The maximum tolerable period of downtime
(MTPD) is the period that an organization can go without minimal activity, which usually
determines the recovery time objective (RTO). The recovery point objective (RPO) is the
state of organizational resources to which the recovery stage needs to return the
organization for normal operations.
Time
Productivity
Normal
Level
Disruption
Occurs
Emergency
Response
Begins
Normal
Operations
Restored
Recovery
Stage
Begins
Minimum
Level
Recovery
Time
Objective
MTPD
TTR
MAD

27. 14
2.1.2 Business Continuity Lifecycle
BS 25999 defines the Business Continuity Lifecycle as four interrelated parts:
understanding the organization, determining BCM strategy, developing and
implementing a BCM response, and exercising, maintaining and reviewing BCM
responses, as illustrated in Figure 5. [30]
Figure 5 BS 25999 definition of Business Continuity Lifecycle
The cycle starts with “understanding the organization” by identifying critical services and
products, business impact analysis, and risk analysis. It is aimed generally at identifying
recovery requirements and threats. These in turn lead to the identification of options and
elaboration of appropriate response in the form of incident management, business
continuity and disaster recovery plans. All these arrangements are subject to exercises,
maintenances, audits and self-assessment in the last phase of the life cycle.
Understanding
the Organization
Determine BCM
Strategies
Develop/
Implement BC
Responses
Maintain/Review
BC Responses

28. 15
Cerullo recommends the business continuity planning process address three
interdependent objectives: [37]
1. Identify major risks of business interruption.
2. Develop a plan to mitigate or reduce the impact of the identified risk.
3. Train employees and test the plan to ensure that it is effective.
By addressing these three objectives adequately, an organization should be able to
weather any adverse condition.
2.1.2.1 Understanding the Organization
In business continuity planning, an organization begins with the initiation of documenting
all the critical procedures performed in each department. Many organizations have
standard operating procedures (SOP), but many who have done this may have not looked
at the documentation in years. Organizations need to create or update SOPs for critical
processes and develop a mechanism such as a corporate Intranet that anyone can use to
access these procedures. Creating a continuity plan is a long-term and ongoing process.
Therefore, planners cannot wait for all the SOPs to be reviewed or created in order to
have an initial conceptual plan in place. [89]
2.1.2.2 Determining BCM strategies
Business impact analyses (BIA) identify critical functions the organization must perform
to stay in business (i.e., make money, provide mandated services), identify risks to
critical business functions, rate those risks according to probability of occurrence and

29. 16
impact on the organization, recommend avoidance, mitigation, or absorption of the
risk, and identify ways to avoid or mitigate the risk. [37]
A simple way to examine such impact is to identify the key business processes and then
to evaluate the effects of possible emergency/disaster scenarios on each of them. Such
key areas and processes might include: [137]
1. Production
2. Supply
3. Warehousing and distribution
4. Quality assurance and control
5. Sales and sales administration
6. Customer liaison
7. Maintenance and repair
8. Information systems
9. Communications (telephone, email, fax, etc.)
10. Financial
11. Research and development
12. Human resources management
13. Business support (premises, catering, cleaning, etc.)
One way of analyzing and evaluating impact is to establish standard time intervals as the
basis of evaluation. For example, the impact on the business can be assessed if any given
service or process is unavailable for, say, 2 hours, 4 hours, 8 hours, 8-24 hours, 1-5 days,
etc. [137]
2.1.2.3 Develop/Implement BC responses
To get a high-level business continuity plan started, planners must define the questions
for individuals and teams surveyed from each department as part of the baseline business
impact analysis (BIA). The goal is to create a series of SOPs to follow in a crisis. The
SOP is not a long document. It should be short and easy to read, often about 3-5 pages
per document. The business impact analysis identifies the critical processes, and the BCP
provides alternative methods to be performed in a crisis. [89]

30. 17
Current comprehensive business continuity plans are large and complex textual
documents. In order to ensure that an organization’s BCP covers all necessary points,
some professional planners recommend adopting a commercial template or “toolkit”.
These “toolkits” act as both a checklist, ensuring that all relevant issues are addressed,
and a guide offering explanatory notes on each topic. [137]
2.1.2.4 Maintain/Review BC responses
Training and testing includes developing a test methodology, testing and training of the
organization, followed by BCP revision, and testing and training again. As a major
component of the BCP, testing is essential to determine whether the BCP is adequate to
address critical risks. In addition to ensuring that the organization staff knows what to do,
testing under increasingly realistic conditions helps develop confidence and avoid panic
during a disruption. [37]
2.2 Motivations for business continuity planning
Many organizations, like hospitals and financial institutions, are legally mandated to
maintain and exercise a business continuity plan. [108] [54] [76] [125] Organizations
have come to heavily rely on information technology (IT) for achieving their objectives
by enabling critical processes and supporting essential administrative and control systems
within organizations. [35] The time allowed for recovering from an incident, better
known as the recovery time objective, has been shrinking. Many companies now require
recovery within 12 hours or less from a disruption or outage. [35] Reliance on IT has led
to a shift in focus from disaster recovery to business continuity management. Business

31. 18
resilience demands critical business data to be active and online no matter what. [35]
[76] [128]
Business continuity planning (BCP) was once thought as just the planning for the
continuity or recovery of computing systems. However, a comprehensive business
continuity plan must also embrace a much wider range of issues and factors. For
example, if a disruption affects work in the normal location, the plan must address
whether current working methods, processes, and procedures can transfer to a new
situation or location and how the transfer would take place. [137] There is considerable
amount of work that can go into business continuity planning, because nearly every
aspect about the processes, technology, information, and people in the organization needs
to be reviewed, planned, developed, and tested. [95]
Senior management of organizations should consider BCP because: [137]
• They have increased dependence on computerized processes and information
systems, at significant risk from a range of possible scenarios;
• Unless there is a formal process to be followed when a disaster occurs, chaos and
confusion are most likely to occur;
• Pre-established backup and recovery strategies will be much more efficient, and
possibly significantly cheaper, than ad hoc emergency action; and
• The costs of (even partial) business failure are likely to be much higher than the
direct costs of any incident.
All the reasons above are compelling motivations for developing and maintaining a
business continuity plan.
2.3 History of Business Continuity
When Adam Smith defined the concept of a business process and the division of labor
[143], business processes became the foundation of modern business. The end of the 20th

32. 19
century ushered in IT, outsourcing, and “just in time” delivery of supplies and services,
which created a very complex business environment where processes depend on other
processes with numerous participants. Ardunini and Morabito noted that the greater
complexity of new environments requires organizations to continually reassess how they
may keep abreast of changes and exploit them to their advantage. [5]
The origins of business continuity began with the introduction of computing to the
financial industry in the 1960’s. With the increased dependence on technology, financial
institutions realized that they needed to address the recovery from IT disasters. Originally
called “disaster recovery”, certain industrial sectors, like finance, utilities, and health,
started building plans in the 1970’s for dealing with disruptions of their IT infrastructure.
In the 1980’s, the advent of “personal computers” led to an explosion of IT within
businesses and a decentralization of IT services. In addition to centralized data and IT
resources, planners now had to account for spreadsheets, documents, and programs
spread all over the organization, requiring a better auditing of IT services.
The 1990’s introduced the idea of “just in time” delivery and higher reliance on IT and
suppliers external to the organization. The advent of electronic communication and e-
commerce changed the speed at which business transactions occur. Without IT and
Internet resources, some organizations could fail within hours of a disruption. Table 3
illustrates the average impact cost per hour in dollars from a disruption to an
organization’s web site for different types of businesses. [37]

33. 20
Table 3 Average Cost per Hour Impacts on Businesses of Web Site Downtime
Type of Business Average Hourly Impact
Retail brokerage $6,450,000
Credit card sales authorization $2,600,000
Home shopping channels $113,750
Airline reservations centers $89,500
Package shipping service $28,250
Up through the early 1990s, production-based economies focused risks to resources that
were tangible in nature, associating them with physical facilities, equipment, and
locations. [77] In today’s knowledge-based economy, the resources that are at risk are
becoming more intangible, like intellectual property, brand equity, management
competence, staff experience, and reputation. Any adverse effect on these resources has
an immediate reflection on earning drivers, shareholder confidence, price of a share, and
an organization’s bottom-line. [77]
The focus of business continuity changed after the events of September 11, 2001. With
the collapse of the World Trade Center towers, nearly 18,000 businesses were dislocated,
disrupted, or destroyed. Almost 130,000 people lost their jobs. [46] Business continuity
plans before this only dealt with supporting information technology and physical
infrastructure, not people or processes. The losses of personnel and experience are much
harder to recover from than the loss of technology. This lesson became more evident with
such events as pandemic flu threats, economic crashes, natural and man-made disasters,
like Hurricane Katrina or the explosion of BP’s Deepwater Horizon oil well. Swartz
describes the basic mindsets and assumptions over the past forty years about business
continuity, summarized in Table 4. [60]

34. 21
Table 4 Exploring Assumptions about BCM Provision
Decade Mindset Scope Triggers Process
1970 Technology
Limited to technology
Focus upon large
corporate systems, e.g.
mainframes
External
physical
triggers
(flood, fire,
bomb)
Contingency
measures focused
on hard systems
1980 Auditing
All facilities
All systems – both
corporate and
departmental offices
External
physical
triggers and
legal or
regulatory
pressures
Contingency
measures
outsourced;
compliance driven
1990 Value-based
Maintain competitive
advantage
Includes
customers/suppliers
Entire organization,
including human &
social issues
Organizational
stake-holders in
value system
BCM developed
as business
process, focused
on business
managers
2000
Capability-
based
Integrates corporate
social responsibility,
risk management, and
digital resilience
The desire to
further embed
well-developed
BCM practices
BCM is ongoing
and continuous
organization-wide
responsibility
Since the beginning of the 21st
century, continuity of supply chains has become more
important to businesses. [40] [59] Dealing with capacity and flow is a key component of
supply chain management. One could make the argument that the continuity of any
process is based on the capacity of supplying resources and the flow of resources between
activities or tasks within the process. The loss of a critical resource or the disruption of
the flow is by definition a break in the continuity of a process.
2.4 Time line of a business continuity plan
The goal of a business continuity plan is to reduce both the impact and time to recovery
after an incident. Tan describes how operations degrade and recover over time, depending

35. 22
on the implementation of a business continuity plan, illustrated in Figure 6. [146]
Without a BCP, operations could come to a complete halt or below an acceptable or
minimal limit defined for providing services. The restoration to normal operational level
takes a long time. With a BCP implementation, there is a higher level of production
operations during the recovery period and a quicker time to recovery.
Figure 6 Business Continuity Planning time line
2.5 Current standard practices of business continuity
Over the years, a number of standard practices have emerged for managing business
continuity. The Disaster Recovery Journal (DRJ) Generally Accepted Practices [55],
Disaster Recovery Institute International (DRII) Professional Practices [57], and Business
Continuity Institute (BCI) Standards of Professional Competence [32] describe the ten
most common accepted practices for business continuity.

36. 23
Rike [127] summarizes these practices as:
• Obtain top management support and commitment
• Establish a planning committee
• Perform risk assessment
• Establish processing and operating priorities
• Perform data collection
• Prepare the written plan
• Test the plan
These steps follow the same steps of the waterfall approach from software development:
creating the project (obtaining top management support and establishing a planning
committee), gathering requirements and performing analyses (assessing risks,
establishing priorities, and collecting data), design and coding (preparing the written
plan), and testing.
The first two steps start with the acquisition of resources and definition of the policies
required for a traditional business continuity plan. The next three steps deal with the
analysis of risks to the organization and its processes, including the identification and
likelihood of various types of disasters (natural, human, and technical), consequences,
recovery/replacement costs, process/resource priorities, and impact of those disasters.
The sixth step is the creation and development of the business continuity plan. Business
continuity plans are integrated sets of formalized procedures and resource information
used to recover from a disaster that causes a disruption to business operations and provide
continuity of disrupted business processes. Plans like these focus on the risks facing the
organization and the strategies for mitigating those risks. The last step is where the
planners test the plans to see if they are complete and actionable.

37. 24
2.6 Format of traditional business continuity plans
Most traditional business continuity plans follow a basic format. The general format of a
business continuity plan is:
• Charter statement
o Overall objectives for the plan
o Recovery objectives
o Requirements for continuity
• Policy statements
o Distribution
o Confidentiality
o Responsibilities
• Inventories
o Staff
o Hardware
o Software
o Data
o Locations
o Processes
• Strategy plans
o Scenario 1
o Scenario 2
o Scenario 3
o …
• Emergency Procedures
o Procedure 1
o Procedure 2
o Procedure 3
o …
• Appendices
o Checklists
o Forms
o Maps
o Vendor Contacts
o Contract Information
The order may differ, but the contents of most business continuity plans are the same.
Most business continuity plans focus on risk scenarios, not the resources. Wijnia and
Nikolic describe the generic format of a risk scenario as Cause, Object, Reaction, and
Consequence. [158] The IT equivalent maps objects to resources, reactions to process

38. 25
outages, and consequences to business impacts. Causes could include natural (fire,
lightning strike, weather, earthquakes, floods, pandemics), man-made (terrorism, arson,
water damage, theft, sabotage), or technical (power outage, system overloads,
hardware/software failures, human error).
Figure 7 Risk Map with various threat causes
Helms et al composed a risk map (similar to Figure 7), derived from twenty different
research papers, which places seventeen common causes for risk on a two dimensional
Thunderbolt
Power
Breakdown
Fire
Dissa6sfied
Employees
Virus a=ack
Cyber crime
Loss of data
Hardware
malfunc6oning
SoEware
malfunc6oning
Scalability
TheE
Air condi6oning
problems
Water damage
Inefficiency
Temporal
unavailability of
data
Network
disrup6on
SPAM
0
2
4
6
8
10
12
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Impact
Likelihood

39. 26
grid. The x-axis represents the likelihood that a risk with that cause could occur. The y-
axis indicates the severity of the impact of a scenario generated by that cause. [75]
2.7 Observations
In the traditional way of planning business continuity, planners focus on the various risks
to the processes and resources of an organization. Risks can affect multiple resources. A
scenario expresses or highlights the effects of a given risk to resources. One could argue
that this may not be the optimal way to look at the issue. Each scenario and risk set is
unique, but the resources do not change. By focusing on the loss of a given resource, the
cause of the loss does not matter. By studying the effects of a lost resource/service
instead of causes, planners can focus on how to make it more resilient or how to restore
the service quicker. This reduces the workload of planners and missing a risk’s causal
effects on a resource. The cause of a resource/service loss is often less important than the
loss of the resource/service itself in a restoration process.
2.8 Limitations of the current methodology
Grimaldi identified eight points of common failures for BCP within organizations as: [69]
• One-size-fits-all approach
• Deficiencies in testing
• Inadequate maintenance
• Lack of senior management involvement
• No enterprise-wide accountability or coordination
• Operations take a backseat to technology
• No clear leadership structure or management contingency plans
• Rash cost-reduction campaigns
Grimaldi states that the traditional BCP solution relies on small recovery teams, usually
20% of the organization’s staff. Smaller organizations, where 20% of the staff is two

40. 27
people or less, have great difficulty making these traditional plans work. He goes on to
describe how a lack of testing, maintenance, accountability, understanding, and
leadership adversely affects the success of an organization’s business continuity plan.
Grimaldi lists seven driving principles behind a successful plan. They are:
• Employ creative and customized thinking
• Test, test, test
• Keep the plan current
• Get senior management involved and keep them committed
• Establish a single person or group for enterprise-wide BCP coordination
• Include both business and technology units as active participants
• Account for backup management
• Maintain a financial commitment, even in times of cost reduction
Lam notes that organizations without a systematic approach to BCP are more likely to
have pitfalls in their plans. Lam defined ten common pitfalls with many current business
continuity plans: [95]
• Incomplete
• Inadequate
• Impractical
• Overkill
• Poorly communicated
• Lacking a defined process
• Untested
• Uncoordinated
• Out of date
• Lacking in recovery thinking
Zalewski et al. describe a few more problems with the current BCP methodology. The
textual format of most business continuity plans leads to: [165]
• Challenges to organizing plans in a functional way
• Incompleteness
• Ambiguity
• Inconsistency
• Lack of explicit and precise definition of roles and resource capacity

41. 28
Zalewski proposes the use of ARIS, a complex business process modeling system that
has a very small percentage of usage within the business process modeling community.
Cimasi depicts impediments to effective business continuity plans. Some are: [41]
• An absence of detailed understanding about the content and maintenance of an
organization’s proprietary, critical business processes
• Without the understanding of design and function that detailed documentation
provides, critical functions become clouded over time – especially if key
employees leave.
• A lack of understanding as to the implications of business process failure
• Insufficient regard for the critical support value of organization or corporate
facilities, equipment, data assets, and personnel
• An absence of complete information about DR and BC requirements and
possibilities
• A scarcity of technical resources to formulate a plan
• A disconnect between the business and IT departments that disallows integration
of the technology disaster recovery plans with business continuity of business
plans
• A lack of sufficient management resolve and the necessary resources to allow
creation and implementation of an integrated DR/BC plan
• Formulation of “off-hand”, casual plans that give a false sense of security, but in
the end will not work because of false premises
• Failure to test and revise existing plans using a deliberate and cyclical system
• Failure to apply meaningful metrics to the iterations of disaster plan test results
• Failure to systematically update the plan and incorporate “lessons learned”
• Failure to constantly train the technical and business staff to work the plan
• Organizational procrastination that impedes the will to proceed
Reviewing the four lists, there are a number of recurring themes of limitation or
impediment that appear. This dissertation will focus on the priority, coverage,
development, testing, and communication of a plan throughout the organization.
2.8.1 Priority
Even though senior managers of many organizations understand the risks and know the
importance of having a BCP, they often still feel there is little return on the investment.
[37] Business continuity planning is a non-revenue producing project and usually does

42. 29
not qualify as a high priority project for organizations. [155] The development and
maintenance of a BCP requires a lot of time and effort throughout the organization. BCPs
fail most often because of a lack of initial effort and subsequent commitment. This is
largely due to the fact that developing and implementing BCPs can be arduous,
expensive, and politically sensitive projects. Organization unit management must be
directly and actively involved with the development and maintenance of the BCP in order
to protect their franchises from events that threaten their business, not just the
technologies. [69] In both organizations that use cutting-edge technologies or slow to
change still undergo process-related changes that involve new products, staff, or
reengineering. Organizations that do not maintain their plans find the restoration to
normal operations much more difficult. [37]
2.8.2 Coverage
Lam, Zalewski, and Cimasi all identify incomplete or out of date plans as a major
limitation. Cimasi and Lam go further by identifying a common problem of inadequate
coverage of BCPs as the absence of complete information or understanding of critical
business processes. Lam also identifies overkill as a possible problem with an
organization’s BCP. The appropriate coverage of a BCP is a major challenge for
organizations.
2.8.3 Veracity
Clarke warns of unrealistic plans that are not based on actual expertise or experience, that
overpromise, published in fantasy documents that describe these hollow plans, and that
create a dangerous false sense of security. [43] Organizations often rely too much on
checklists provided in existing standards and software that “automatically generates”

43. 30
plans, as seen in the BP Deepwater Horizon oil spill. [164] A business continuity plan
is more useful if it is an agile support tool to solve any kind of situation, not one created
for a small set of predefined situations. Checklists for predefined situations can be created
during the business continuity planning process and kept updated in a periodic
maintenance process. The existence of a BCP in accordance with BS 25999 does not
necessarily correlate to the survival probability of an organization in the event of a
disaster. It depends on the implementation of the plan. [23]
When developing a BCP, the placement of technology first results in an ineffective plan.
The plan will address technology issues but neglect human resources and business
process-related matter that are crucial to operating as close to normal as possible when
business is interrupted. [69]
2.8.4 Communication
Often, BC planners have not communicated the plan to all the right people. An
unprepared organization’s staff, both management and technical, remain unaware of
business continuity issues. [95] The organization that does not adequately address how it
intends to recover to a fully operational state after executing its business continuity plans
often fails within 18 months of an incident. Most business continuity efforts lack
organization, communication, and coordination. [95]
2.8.5 Testing
Empirical evidence attests to the central role of a tested disaster recovery plan in disaster
preparedness. Unlike companies without a plan for reacting to and recovering from a
catastrophe, companies that experienced potentially devastating disruptions and that

44. 31
implemented tested contingency plans survived such events and continued to operate
in the marketplace. [107] Comprehensive BCM plan testing for complex information
systems is difficult and expensive, if not infeasible. [34]
A business continuity plan needs to work in practice and not only in theory. The objective
for an organization should be able to solve all situations in a calm and structured way
without the need to open up the business continuity plan, as it is known by heart. [98]
Organizations must prepare their staff to think systematically in risky environments. [13]
To be able to reach this level, an organization must be mentally prepared that situations
may occur at anytime. They must keep the business continuity plan maintenance process
running. They must educate, train, and practice both internally and with external partners
such as business partners, public organizations, suppliers and contractors with service
level agreements (SLAs) to ensure success. [98]
Organizations that spend time, effort, and expense to construct BCPs but do not test them
are not managing their investments wisely. Most likely, these firms will not be able to
successfully enact their BCPs when a crisis begins. Merely documenting a plan does not
guarantee success. To ensure usability, a BCP must be diligently, comprehensively, and
consistently tested. Live testing also trains the staff. When a crisis ensues, staff members
who have been through BCP tests are better prepared to act with confidence. The
recovery process after a major disruption could stumble or fail completely, if plans are
not updated and practiced consistently. [69]
If the organization’s business continuity effort lacks organization and coordination, staff
will be unsure of how to react in a failure scenario, or they discover too late that their

45. 32
existing BCP processes fall short. If the organization has not tested its plan thoroughly
enough, it cannot provide a high level of confidence in its soundness. [95]
Planning is more effective when BCPs are actually put to the test using simulation
exercises of mock situations to identify whether the plan actually works. [35] Companies
with untested or poorly tested plans find that they are not as protected as they expected.
[128] However, two major barriers to full testing of BCPs exist: resource constraints
(budget, staff time, equipment) and process disruption to employees, customers, sales,
and revenue stream. [58]

46. 33
Chapter 3
Agile Techniques for BCP
3.1 A new methodology for business continuity planning
As seen in the previous chapters, the current methodology for business continuity
planning is very similar to the “waterfall method” from software development and suffers
from a number of limitations and impediments for many organizations. [69] [95] The
current business continuity methodology has a very heavy planning effort up front and
tries to identify and mitigate as many catastrophes as can be conceived. [77] Once
developed, business continuity plans are rarely updated to reflect changes in the
environment or business processes. [163] Finally, plans are tested at the end of the
development cycle, if at all. As textual documents, plans tend to be ambiguous,
inconsistent, and incomplete. [165] [28]
This chapter details the use of key agile techniques to develop business continuity plans.
By leveraging the existing experience and knowledge of how agile techniques have
improved software development, this chapter will illustrate how agile business continuity
planning can harness agile principles and practices to alleviate or eliminate current BCP
limitations and impediments.

47. 34
3.2 Basic agile principles
Bergin provides a description of how agile development works through a story and use of
patterns. [20] The following story describes how an agile project is formed and what an
average day looks like within the project. Patterns critical to agile development are
printed in bold text.
A team has been formed by a Sheltering Manager, consisting of an Onsite
Customer, seven developers, and a tech gofer with knowledge of infrastructure and
tools issues that are customary in the organization. The Whole Team has found a
workspace and set it up, both physically with tables for the workstations and
virtually with the development platform. The latter includes testing, code
repository, and integration tools. The Whole Team along with the Sheltering
Manager has gotten together for three days to Train Everyone under the direction
of the Effective Coach. The Onsite Customer and the developers have gone
through the initial development of the Guiding Metaphor and starting on the
Planning Game. The metaphor gives them an initial vocabulary to ease the
communication between the customer and the developers.
…
A day is spent with the Whole Team beginning with the just-in-time requirements
gathering. Thirty Stories have been written, covering an End To End first cut at
the desired functionality and the team has estimated these stories. The team has
(flexibly) set its initial Velocity quite low, as they are new to this project. A few of
the stories were larger than can be accomplished in a single two-week iteration

48. 35
by an individual, so these have been broken into tasks and the Implementer
Estimates these Tasks. The Tasks are selected by doing those with the High
Value First.
The customer chooses a few of the most important stories, looking at their value
and their cost as reflected in the estimates. Development begins on just these
stories, using Test First development with Executable Tests. Many questions are
asked of the Onsite Customer and the answers to the Questions Generate
Acceptance Tests. One of the developers works with the Onsite Customer to begin
to develop an Acceptance Test suite for the application. Meanwhile, the
developers Program Promiscuously, frequently changing partners so all are
familiar with the code being developed. As each task is completed, it is
(Continuously) Integrated into the build, so that all unit tests pass. Of course, all
programmers Do The Simplest Thing That Could Possibly Work (DTSTTCPW)
in all coding and design, thereby Delivering Value to the customer. The Onsite
Customer Checks Off the Tasks when they are done, reviewing the unit tests as
appropriate and noting the changes in the Acceptance Tests written and passing.
Halts are called when Acceptance Tests that were passing suddenly fail. This is
obvious since we use only Executable Tests and the suite is executed frequently;
especially at each integration: several times a day.
Through Standup Meetings, Retrospectives, Full Communication, Pairing, and the
Planning Game, the agile environment is a dynamic collaborative one that allows the
delivery of an End-to-End product with High Value First. Developers can Spike when

49. 36
they must learn how to build things. They can Refactor the code whenever new stories
can be built more easily by changing the existing code, improving its design.
3.3 Agile Manifesto
In 2001, a group of developers looked at the traditional “waterfall” methodology for
software development, the standard at the time, and decided there was a better way. They
defined the Agile Manifesto [1], the fundamentals of agile development, as:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The values stated are the same as a good business continuity plan. In other words, a good
business continuity plan should be a collaborative work that responds to change and
focuses on the individuals and interactions within an organization.
3.3.1 Individuals & Interactions Over Process & Tools
Business continuity plans too often focus on the restoration of the technology of an
organization and the use of checklists from a canned package. [41] [43] Using
prepackaged tools and processes denies the fact that each organization is unique.
Although there are similarities between organizations, each must define its path to restore
the organization to a normal state after a disruption. A number of surveys show that

50. 37
organizations that test their plans are better prepared. [163] The experience gained
from the tests improves the ability to recover during a real incident.
With respect to the individuals involved in an agile project, the Whole Team is
composed of Chickens and Pigs, people who are involved (chickens) and people who
are committed (pigs). The Chickens and Pigs pattern comes from the joke about a
chicken and pig talking about starting a breakfast restaurant called “Ham-n-Eggs”. The
pig was reluctant as he commented to the chicken that while she would be involved in
making breakfast, he would be totally committed. One unwanted variant of the Chickens
and Pigs is a Rooster, a person who makes a lot of noise and makes no real contribution.
One hopes that there are no Roosters on the project. One particularly important chicken
is the Sheltering Manager. The Sheltering Manager protects the Whole Team from
external interruptions and provides support to them, allowing them to focus on the
project. The Onsite Customer is a valuable member of the Whole Team, providing
expert knowledge of the business processes and guidance on the value of project tasks.
An Effective Coach can be used to train and guide the Whole Team on the agile process
and keep the team moving forward.
3.3.2 Working Software Over Comprehensive Documentation
Another common issue is the development of “shelf-ware” business continuity plans that
just sit on a shelf untested. [43] Although they may be comprehensive, plans that are
written and never updated or tested are a waste of an organization’s resources. [69] Any
partial plan that provides a suitable and verified continuity result for a frequently
occurring disruption is vastly superior to one that is comprehensive, untested, and out of
date. [163]

51. 38
Agile methodology starts with the development of an End-to-End product that
provides the simplest thing that can possibly work (DTSTTCPW) through a Test First
process. Through Continuous Integration, new components that Deliver Highest Value
First are added to increase the functionality of the product as each component passes all
Acceptance Tests for the entire build. Sometimes, the product or components are
Refactored to improve their functionality. Acceptance Tests that are made into
Executable Tests allow independent and consistent testing, guaranteeing working
software.
3.3.3 Customer Collaboration Over Contract Negotiation
Many organizations use their IT disaster recovery plans as their business continuity plan.
[41] This is a shortsighted technique as it only covers a small part of an organization’s
exposure to a disruption. Business process owners must work with their IT counterparts
to develop contingency plans for when the IT support fails for their processes. Process
owners also need to address how disruptions to other processes affect them. For example,
the disruption of air travel or postal service would not affect IT services but could have a
severe effect on shipping or receiving.
Customer collaboration is illustrated through a few different patterns. Initially, an agile
project starts with a Guiding Metaphor that helps the Whole Team get on the same page
with language and concepts about the project. The Onsite Customer develops a list of
Stories that the Whole Team can determine the High Value First through the Planning
Game. Developers on the Whole Team estimate how much effort is required for each
Story and it may be broken down into Tasks. Questions brought up during the project
are sometimes converted to acceptance tests (Questions Generate Acceptance Tests).

52. 39
Collaboration is further improved through Standup Meetings and Pairing. Daily
standup meetings allow for dissemination of information and bouncing around ideas that
can free logjams, clarify misconceptions, or resolve problems. Pair programming
provides cross training and a method for error checking.
3.3.4 Responding to Change Over Following a Plan
Although a plan can cover many contingencies during a disruption, incidents often have
some variation that is not covered explicitly in a plan. [43] It is better to have a staff that
can respond quickly to change and deal with disruptions than one that blindly follows a
plan that may or may not be correct. When restorations are experienced and well-
practiced, experienced employees can quickly and correctly adjust for variations, thus
handling a disruptive incident is much easier.
Plans provide explicit knowledge. Explicit knowledge is the facts and procedures that are
written down and can be handed to others. However, it is the tacit knowledge of an
organization’s staff that provides the best options for recovering to the current normal
state. Tacit knowledge is the experience of the staff that is not written down and exists
only in their heads. The lack of tacit knowledge during an incident is one of the major
causes for delay or failure to returning to the normal state.
The Retrospective pattern provides a review of an agile project at the end of an iteration.
The Retrospective allows change to the project and/or how it is being implemented.
Refactoring allows change to the implementation to respond to changes that have been
discovered in the process of developing the project.

53. 40
3.4 Optimal environment for an agile methodology
Boehm and Turner describe the areas where agile and plan-driven techniques thrive best.
[24] Table 5 summarizes the characteristics and the differences between optimal agile
and plan-driven environments.
Plan-driven methodologies, like ones for current business continuity planning and the
waterfall approach, find an optimal operating environment with large groups and place
heavier burdens on the organization, like very formalized plans and documentation. As
illustrated in the previous chapter, smaller organizations that need business continuity
planning share an operational environment that is optimal for agile methodologies. The
limitations that come with current BCP methodology come from the plan-driven
environment. Using an agile BCP methodology with the strengths of agile methods, the
planning process can align more effectively with the resources and requirements of
smaller organizations.

54. 41
Table 5 Optimal environments for agile and plan-driven methodologies
Application
Characteristic Agile Plan-Driven
Size Smaller teams and projects Larger teams and projects
Primary Goals Rapid value, responding to change
Predictability, stability, high
assurance
Environment Turbulent, high change Stable, low-change
Management
Characteristic Agile Plan-Driven
Focus Focused on prioritized increments Focused on contract provisions
Planning Internalized plans Documented plans
Control Qualitative control Quantitative control
Communications Tacit interpersonal knowledge Explicit documented knowledge
Technical
Characteristic Agile Plan-Driven
Requirements
Prioritized stories and test cases,
undergoing unforeseeable change
Formalized project, capability,
interface, quality, foreseeable
evolution requirements
Development
Simple design, short increment,
Refactoring assumed inexpensive,
Rapid feedback
Extensive design, longer
increments, Refactoring
assumed expensive,
Slow/No feedback
Testing
Executable test cases define
requirements, testing
Documented test plans and
procedures