The deployment WIKI provides a knowledge base of deploying Sahana for different types of disasters, scenarios and roles. It also provides some best practices for the particular situation. Please also share your experiences so that we can make this knowledge base richer and more effective.
The links are to case studies (mostly to come).
- Tsunami, Sri Lanka – 2005. Officially deployed by CNO. Tracked approximately 26,000 families
- Kashmir Earthquake, Pakistan – 2005. Officially deployed and integrated with NADRA (Pakistan Government) to track all victims
- Landslide, Philippines – 2005. Official government deployment to track all victims, organizations, & camps
- Yogjakarta Earthquake, Indonesia – 2006. Deployed by ACS, Indonesian Reliefsource
- Cyclone Sidr, Bangladesh – 2007
- Ica Earthquake, Peru - 2007
- Bihar Floods, India - 2008
- Cyclone Nargis, Myanmar - 2008
- National Disaster Management Center & Ministry of Resettlement & Disaster Relief Services, Sri Lanka – 2009
- Earthquake in Haiti - 2010
- Earthquake in Chile - 2010
- Floods in Pakistan - 2010
- Floods in Venezuela - 2010
- Floods in Colombia site - 2011
- Wildfires in Chile - 2012
- Hurricane Sandy, New York and New Jersey - 2012
- Coastal Storm Plan, New York City – 2007-present
- Sarvodaya, Sri Lanka. Customization for Sahana requirements, 2008-present
- Bethesda Hospitals Emergency Preparedness Partnership, National Library of Medicine, Bethesda, Maryland, United States - 2009-present
- Australia - Independent - 2009
- Karnataka and Andhra Pradesh, India - Work in progress, led by IBMers
- National Coordinating Agency for Disaster Management (BNPB) in Indonesia - 2009
- Taiwan - 2010
- Vietnam - 2010
- Exercise 24 - 2010
- IFRC Asia Pacific Disaster Management Unit - 2011
- Bombeiros (Portuguese National Volunteer Firefighters) - 2011
The following best practices are based on past Sahana deployment experiences including Pakistan, Sri Lanka, Philippines, Peru and US. (target) Org in the paragraphs below refers to those who can apply Sahana to improve efficiencies in coordination either internally or within a network of relief groups. They can include Government, NGOs, UN, Spontaneous Volunteers.
Justification - It is important to spend sufficient time upfront to clearly understand the requirements and to document them should further clarification be required later. Always communicate this documentation to the target org before you begin to set expectations and schedules. It is better for the team doing the customization to meet the members from the target org onsite rather than doing this remotely.
Justification - Understand the real problem being faced by the target org and match/customize Sahana to that, rather than use Sahana like a hammer looking for a nail. It is better not to deploy Sahana, than to deploy a solution that does not match the coordination problem.
Justification - There is no point giving Sahana to those that do not have basic IT literacy. It is better to appoint one IT savvy person to act as a Sahana helpdesk and center point for those that are not IT literate. The terminology used on the system should also match the target user group.
Justification - The data being served by Sahana is often very sensitive, so an effort needs to be put in place to secure the data to only authorized people. The orgs usually have their own security policy and restricted ports & practices. Sahana can be configured flexibly with an authentication and authorization (access control) that matches the environment. Don't leave this as a last moment task or it becomes a show stopper.
Justification - As Sahana addresses the humanitarian response domain always ask the question to yourself irrespective of what the target org need, if the beneficiaries have indeed been helped by the customization. It will keep your leadership on the customization well grounded. The Red Cross Code of Conduct provides a good base line for all of us to measure against.
Justification - There have been many instances where the Linux OS has not matched the target organization's ability/capacity to maintain the system. In this instance we recommend you install Sahana on an OS familiar to the target organization (usually Windows) or all issues including non-Sahana ones will be propagated back to you. Sahana is available to be installed on Windows as a WAMP package or the portable App version.
Justification - The disaster coordination domain is a mission critical domain and we cannot afford to have systems failing in the middle of disasters. Thus irrespective of how old the stable branch is, you should customize Sahana off a stable release and not a development release such that you have some degree of assurance on reliability.
Justification - Bugs will pop up as you customize Sahana for the target org. Ensure you have a quality process in place to track & fix bugs. Also you can expect a lot of changes from the target org especially during a disaster, so be ready to track them effectively such that none are missed and schedule them effectively based on priority. At the top end you can use a project management tool such as dotproject to schedule the team. It is better to have a dedicated team assigned to ensure delivery and deadlines.
Justification - A deployed Sahana and the XAMP system needs to be maintained and administered. A good training program is also needed so that users get a good understanding of how to use the system. Ensure there is someone or support group responsible for the above after deployment as you can expect a lot of queries (mostly trivial) and minor configurations once the system gets deployed.
Justification - Please continue to support Sahana as you build new modules, create enhancement and fix bugs for target organizations by submitting that code back to the code base according to the standards specified, such that a minimal amount of work is need to integrate it. The sooner you can do this the better it will be before the codebase diverts from the deployment customization.
Justification - As the system gets used by the target organizations there will be change requests that will involve changes to the code. Ensure you have a staging server to test new patches and a fault-tolerant mechanism to update the production server once the tests are complete on staging.
Justification - The Red Cross Code of Conduct has been formulated by many years of experience operating in the Humanitarian Response domain and it is advisable that you keep to these principles when working in this domain such that you do not get into political issues or other related problems. We have elaborated on the Red Cross Code of Conduct with respect to Sahana here
Justification - The Sphere handbook is guide for disaster management that takes into account recent developments in humanitarian practice in wat/san, food, shelter and health, together with feedback from practitioners in the field, research institutes and cross-cutting experts in protection, gender, children, older people, disabled people, HIV/AIDS and the environment. The handbook is the product of an extensive collaborative effort that reflects the collective will and shared experience of the humanitarian community, and its determination to improve on current knowledge in humanitarian assistance programmes.
Any specific details for the deployment of Sahana for the following usages (roles)
- Secure Coordination Hub - Secured coordination hub, with a collaborative helpdesk
- all modules active
- Camp Management System - For tracking information in a camp
- Warehouse Management - For tracking inventories and logistics
- just needs Organisation Registry & Inventory Management modules
- Someone to join the sahana-user list and to facilitate bringing in deployers (for example the IBM China team) into the sahana-user and sahana-maindev communities as appropriate early in future emergency/deployment processes. The following issues can then be supported and addressed:
- Bugs found : Bugs found should be reported by the deployment team through the sahana-user and sahana-maindev lists - someone from our core team can then take responsibility for getting them added to Tracker. Patches can then be provided by the community back to the deployers.
- Bugs fixed : Process TBD to get bug fixes made by deployment teams back into the main codebase. These could similarly be reported back directly to the sahana-maindev list and the patches to be incorporated into future release candidates.
- New modules : Often new modules are developed for a specific deployment - for example, the situation reporting module completed for the Bangladesh deployment. This code should be returned to the community for consideration by the PMC of being merged into the main codebase.
- New features : Similarly, enhancements to existing functionality is often made during deployments to meet the specific need of the operational situation - such as the financial disbursement tracking that was linked to the DVR for the Peru deployment. Again, this code should be returned to the community for consideration by the PMC of being merged into the main codebase.