This article explores how organisations can improve their resilience to threats such as flood, pandemic, and terrorism by using the services of nearshore outsource systems development companies; and, by doing so ensuring the quality of software support to live services regardless of the situation. The current coronavirus pandemic (Covid-19) is not only a threat to public health; it is also a threat to business operations in organisations of all types (private, public and third sector). Keeping operations going is always harder when a significant number of staff are sick and absent, but in the current pandemic it is the health-risk mitigation itself (closing offices and requiring staff to work from home) that is the immediate threat to business continuity. When those staff include IT personnel, the risk increases further. IT systems development, IT support and IT operations (including service delivery) are critical functions in business operations. For most organisations there would be no business operations if IT operations stopped (ref. the widespread cancelling of medical surgeries in the UK National Health Service during the ‘WannaCry’ ransomware attack in 2017); no IT operations if IT support stopped; and, weaker IT support if IT systems development personnel were unavailable. Though the criticality of software developers in live service delivery might not be obvious to some, they are the people who provide third-line ‘developer’ support to service delivery, including investigating and resolving service outages, and fixing critical software bugs. As well as playing an important support role, the ‘day-job’ of software developers has changed in recent years as organisations move away from off-line project working to more agile ways of working. These include the ‘DevOps’ approach and other methods where continuous development, delivery and deployment of new code into production is the norm. (i.e. developers are increasingly plugged-in directly to IT operations and business operations and without them it would be impossible to maintain the integrity of customer service). This article explores how organisations can improve their resilience to threats such as flood, pandemic, and terrorism by using the services of nearshore outsource systems development companies; and, by doing so ensuring the quality of software support to live services regardless of the situation. It recognises that nearshore outsource companies may also be disrupted by external events, but argues that geographic dispersion is one of the most fundamental risk mitigation strategies in emergency planning, as is organisational diversity (including using third party suppliers). Where those organisations at risk include ‘critical national infrastructure’ (healthcare, transport, financial exchanges etc) these types of mitigations are best-practice to the point of being hard to justify not using. Despite working from home or working remotely being more common than ever, and despite a common assumption that organisations will always have disaster recovery and business continuity plans to cover situations such as the current pandemic, the reality is that many gaps remain in the majority of organisations (including having no plans at all). Emergency planning (aka contingency planning), disaster recovery and business continuity are important and well-established subjects, organisational functions and professions in their own rights. Disaster and Emergency Planning degrees are offered by many universities worldwide. It takes knowledge, skill and experience to be an effective leader in the subject and yet there is a mountain of case-study literature on organisations that were put out of business by either failing to plan for emergency situations, or an important supplier of theirs failing to do so. In almost all cases they had failed to use qualified experts to help draw up, practice and maintain their plans. Things aren’t getting any better as there is no finite unchanging list of organisations in the world. Instead, the (virtual) list changes daily as old companies close or are absorbed, and new companies spring up. With business continuity planning not being a mandatory requirement for operating most organisation types, there is no chance of the planning gap ever being closed for good. Even where regulators require firms to have plans and methods for managing contingency risk, those plans and methods have often been shown to be worthless when needed – e.g. requiring firms to have a second data centre for disaster recovery purposes but not stipulating or enforcing the minimum distance from the primary centre or its level of natural protection (say, elevation as a defense against flood risk). Some of the case studies of failure in the face of disaster are almost funny in their ineptitude (e.g. emergency office space and infrastructure for earthquake mitigation being in the same street as the primary offices and infrastructure), while others are tragic. Even when lives are not lost, many jobs are lost each year due to a failure to plan for contingency situations (including cyber-crime such as ransom-ware and denial-of-service attacks). Unfortunately, business continuity plans are often treated as shelf-ware (similar to IT policy documents) in that they exist to tick a box rather than being living documents and processes that are practiced and improved (and people trained) on a continuous basis. In the case of IT operations, there are some fundamental approaches to business continuity that are used so commonly as to be part of normal day-to-day working. They include backing-up data, and hardware redundancy. Luckily, hardware redundancy and recovering from disaster is so much easier these days than previously. In previous years, it would have needed extra machines located in a DR suite in a data centre in a different building, hopefully 50 miles or more from the primary site. Far too often, there were either no extra machines (every one bought for the purpose having been repurposed for live production or used by developers or testers for project work), or they were in the same room as production machines, or they were located nearby (i.e. in the same area of geographic risk). In terms of readiness of the machines for disaster recovery purposes, best-practice evolved from the hot (primary):cold (secondary) model, to hot:warm and then hot:hot (where production is shared 50:50 at 50% or less capacity being used per site, thus …
