Click for PDF

Cloud services present some intriguing opportunities for augmenting, or even replacing, corporate data centers. With the ability to quickly spin up new servers, whether to help ease the burden during peak periods or get a new project off the ground quickly, the cloud can bring a new level of agility to organizations that use it effectively. But using it effectively means paying attention to lots of details.  ERP Executive talked with Martin English, senior consultant with Stream Technologies, an SAP NetWeaver services and consulting company based in Australia, who offered these tips to get you started.

You need confidence, not just competence. If you run SAP, chances are you have at least a few experts on staff who are technically competent. That’s all well and good, but to sell a cloud project, you’ll also need technical confidence. “Essentially the technology side has to sell it to the business,” English says. “If you’ve got the world’s best BASIS programmers and ABAP people and they stand up and say, ‘It’s a good idea and this is what we’d like to try, but we’re not too sure,’ that’s not going to fly.”

Choose your spots. Few, if any, companies simply hand over their entire SAP infrastructure to a cloud provider. Rather, they pick and choose certain components that make sense, often starting with development and testing systems. One reason is they aren’t comfortable, from a security perspective, with having production data stored outside the four walls of their own data center. Outside the U.S., many lawyers read the U.S. Patriot Act as saying the U.S. government can force U.S.-based cloud providers (such as Amazon) to hand over data upon request. “If you’re at all paranoid, this pretty much restricts your SAP usage of Amazon Web Services to sandpits, development and testing systems,” English says.

But it just so happens that non-production systems are the ones where companies get the most benefit from cloud anyway. With the ability to spin up multiple dev and test systems, you can run projects in parallel. Rather than using your dev system for, say, a month, then moving the code to test for two months before moving on to the next project, companies can have multiple dev and test systems running in the cloud simultaneously.

“You’ll also have the biggest opportunities for innovation,” English notes. “Developers will be more inclined to launch a copy of your standard instance to try something out, compared to trying to get an in-house server provisioned.”

Keep fundamentals in mind. Handing off an application to a cloud provider doesn’t relieve you of your obligation to ensure it performs well and that proper security is in place. “The fundamentals of application lifecycle are the same regardless of whether it’s running on a box under your desk, in a data center hosted by Accenture, or in a cloud environment,” English says. IT still has to ensure it architects the application properly, sizes it appropriately for the number of users expected, provides adequate bandwidth to ensure good response time, and provides proper security, perhaps with a VPN encapsulating the entire infrastructure.

You still need a disaster recovery plan. Be wary of smaller cloud providers that operate entirely out of a single data center, because English says they will likely fail the airplane through the roof test.  “If there’s only one data center and an airplane comes through the roof, then your data is gone,” he says. Amazon, for example, not only has physically discreet data centers that back up each other, but separate zones within each of its data centers, each with their own power, telecom links and such. And even with all that backup, Amazon has had issues.  The point is, the onus is still on the customer to have a disaster recovery plan that matches its tolerance for risk as well as its Recovery Time Objective and Recovery Point Objective.  The RTO describes how quickly a particular service has to be back up after a failure while the RPO is the amount of data loss that’s acceptable.

Simply put, full disaster recovery means having duplicate infrastructure in place in a different location, a way to keep the data on that backup infrastructure up to date, or get it up to date quickly, and a mechanism for switching from the failed infrastructure to the other – and back again – without losing time or data, or at least not much, English says. “You can make it as simple or as complicated as you like, depending on the cost vs. risk equation for your particular applications,” he says.

Estimate usage carefully. Finally, before signing any contract you’ll want to have a sound estimate of your resource requirements. The SAP Quick Sizer (PDF) can give you a good idea of minimum system requirements, then you can pick the appropriate cloud service level. “Allow for the frequency and number of snapshots to be retained when calculating storage costs,” English says.  He recommends using a third-party tool such as Skeddy to schedule actions such as starting, stopping and taking snapshots so you can close down some systems when they’re not in use, thus reducing the cost of your cloud systems.  And when comparing the cost of cloud vs. internal systems, be sure to include costs for both CPU and storage.

ERP Executive thanks Martin English, senior consultant with Stream Technologies and a certified SAP BASIS / NetWeaver Consultant, for his contributions to this article. Check out his blog post on a related topic here.

ERP Executive is Published by Panaya.