When the Haiti earthquake disaster struck in 2010, killing 300,000 people and leaving more than a million homeless, the world rallied. But with the situation arising completely out of the blue and with no time to spare, charities like Oxfam were presented with a problem that they had to solve fast – how could they ensure that they could continue to take donations while their website experienced an increase in traffic of more than 400 per cent within hours of the disaster?

Among the UK’s most famous charities, Oxfam has spread internationally since its inception in 1942 and now comprises 15 individually affiliated organisations.Oxfam GB had developed a complex IT environment over the preceding two decades, comprising an array of online applications including several websites, an e-commerce platform, supporter engagement tools and an internal intranet. Therefore, when the Haiti earthquake struck, the charity had a juggling act to perform. In the end it had to take almost all of its applications other than its primary website down in order to retain enough bandwidth for donations. Even this had to run as a single page website until the peak in demand began to tail off.
 

Clearly this solution was far from ideal. Just as a large number of new supporters was coming to the website, Oxfam had to turn off all functionality aimed at building a deeper supporter relationship.

To ensure that this problem would not be encountered should a disaster of similar scale occur again, Oxfam was faced with two choices: either buy enough physical servers on-premise and leave them dormant until they might be needed; or go cloud. As an organisation that wants to spend as much of its funds and time on its charitable work as possible, rather than back office functions, there would only be one winner – the case for cloud, with its scalability and reduced upfront costs, quickly became clear. To get the project up and running, the charity called in business process efficiency expert Graham Oakes, author of the book Project Reviews, Assurance and Governance, published by Gower Publishing. His first job was to ascertain which type of cloud would be most suitable.

Though Oxfam entered the process with “a completely open mind”, Oakes says the team quickly discounted the option of Amazon’s elastic EC2 platform and similar solutions. “Oxfam had experimented with these and continues to do so,” says Oakes, “but here the aim was to build a partnership with a technical partner who could bring high levels of service support. Amazon and suchlike provide a very good solution for organisations which are capable of supporting themselves, but Oxfam wants to focus its skills on humanitarian response, not on technical infrastructure.”

Having made the decision to look for a more managed environment, Oakes and the Oxfam team drew up a shortlist of six suppliers which were chosen on the basis of existing market research and analyst reports.  A “structured but highly-interactive procurement” process with these six companies then ensued. Part of this saw each supplier join Oxfam at its offices for a day to run a workshop with the charity’s employees. This way, both parties could get an understanding of each other’s culture and requirements. A series of conference calls then took place prior to the submission of responses to the Request for Proposal (RFP).

During this process, the team created a number of scenarios of potential demand patterns, including normal daily activities, predictable surges like Christmas traffic, and crises such as the one that had recently unfolded in Haiti. It then explored the costs of various mixed public and private cloud configurations, with options ranging from almost entirely one way to almost entirely the other.

“For Oxfam's best estimate of the likely workload scenarios, a solution weighted towards private cloud made the most economic sense,” says Oakes. “With the option we chose, we have the ability to ‘burst out’ into a public cloud for extreme workload peaks, but most of the time the private cloud will be able to meet the demand and provides the best cost of ownership over the three to five year period which we were modelling.”

The ability to run the service with availability and security that met or exceeded the outgoing infrastructure was clearly critical. But, as Oakes suspected would be the case, all of the vendors were able to achieve this. “The table stakes were pretty well even,” he says. “But we still needed to be sure that the vendors really could supply what we thought they could.”

The differentiation came in two other requirements that Oxfam had stipulated. Firstly, the cost, once again, could not exceed that of the current infrastructure. Secondly, the supplier had to be a good match for Oxfam’s organisational culture and ethos if they were to fit well as a long-term service partner.

However, the cost issue manifested itself as the biggest headache of the entire process. Specifically, comparing prices from one vendor to the next proved problematic. Although the capacity scenarios were presented in a ‘technology agnostic’ way, using Amazon’s EC2 compute units as the common measure, suppliers had to convert the capacity into their own configuration before they could cost it up.

“It took a lot of effort to help them understand our capacity requirements and to normalise their different pricing models to a common base,” says Oakes. “This is an area where standards are sorely lacking.”

In terms of the cultural fit, Oakes thinks issues like environmental performance and sustainable sourcing are now likely to become more important in many company’s considerations of potential suppliers. Currently, charities and non-profit organisations, and to a lesser extent universities, are the ones that are most likely to seek green performance on a par with cost, he says, but the two will become syndicated moving forward.

“If you’ve got a good efficiency rating then it’s probably a sign that you have a modern data centre and that means you will probably be able to compete on cost and technology as well,” says Oakes. “In addition there are tough targets on their way in for carbon emissions and potential hefty costs associated with the carbon trading schemes. Green will become a top priority for more companies going forward, whatever their overall ambitions are.”

In the end the team ended up opting for a solution from ‘the big blue’, IBM. The system wasn’t perfect, in terms of flexibility, but it was the best fit. One significant problem was once again with discrepancies between the way that software vendors cost their offerings and the needs of the buyer. For example, some of Oxfam’s web applications are designed to scale horizontally; meaning the best way to deploy them is as a stable of small virtual machines (VMs). However as suppliers license on a per-server basis, this becomes very expensive.  “For now we’re deploying a small number of larger VMs, and hoping our software vendors will eventually catch up with the cloud,” says Oakes.

Ignorance is bliss

The implementation went smoothly though, with a new content management system moved across first, followed by string of customer applications. However, neither Graham Oakes nor Oxfam are aware whether the project has fully been a success yet, in the context of the primary objective. And they hope they never find out. “The real test will come in a crisis,” says Oakes. “Hopefully it’ll never get tested at all.”

A number of secondary advantages which Oxfam has benefitted from have arisen out of the project. These include improved visibility over technical costs such as storage or the price of commissioning a new server; improved flexibility for the in-house development teams, specifically in terms of setting up development or testing environments; and clearer management boundaries between the technical infrastructure on the IT side and the application infrastructure which is managed by the business units.

Oakes says Oxfam’s in-house IT team should now be able to spend less time fire-fighting problems with ‘piecemeal infrastructure’ and more time managing an end-to-end service.  It means the skill base and deployment has shifted too, towards an emphasis on service and relationship management rather than on technical systems administration, although the charity will still keep some technical skills in place to help manage the service partner and support internal development teams. 

This changing skills balance does mean that a cultural transition is under way within IT, particularly with a changing management interface between IT and the business units. “But the signs so far are that it's working well,” says Oakes.

Indeed, the feedback from parties within Oxfam has so far been very positive. “The quantified measures are mostly about cost and service availability,” says Oakes. “The real measure, however, will be in how satisfied the application owners are with the service that the technical infrastructure is providing to them.”

The charity went into the cloud with a pragmatic mindset. “Oxfam is pretty conservative,” says Oakes. “It doesn't want to be on the bleeding edge of technology. It just wants to have a reliable, cost-effective infrastructure that allows it to focus its attention on its humanitarian mission.”
Once comfortable with the current system, there will be an opportunity to review other internal applications and see which ones are suitable to migrate to the cloud. Oakes sees the Enterprise Resource Planning system as a leading contender.

However, the cloud won’t be a panacea. Email, for instance, is simply not far reaching enough, with network connectivity remaining poor in many developing countries. “When cloud vendors proudly display their maps of their email coverage,” Oakes explains, “you’ll often notice a vast Africa-shaped gap. That’s where a lot of Oxfam’s people are.”

Whatever goes cloud next, Oakes and the Oxfam team have learned some valuable lessons from this first foray. “We put a lot of time into thinking through our workload scenarios and hence requirements for capacity and availability from the cloud service. But during the procurement, it became clear that we also needed to think hard about the manageability of the service and this will certainly be at the forefront of our considerations next time around. 

“I also think we'd give a little more thought to storage requirements and their impact on things such as archiving and retention policies.  This is an area where increased visibility of costs is starting to have an impact on Oxfam's thinking.”

Oakes’s advice is not to worry too much about the technology — focus on the economics, service levels and management. “The why’s and wherefores aren’t what’s important,” he says. “The only thing you need to know is that cloud works.”

He is confident that Oxfam now will get its wish and next time a major disaster happens it can focus on helping people and not its IT environment. However, the true success of this project will remain unknown until that time comes.