Is SaaS Part of Your Cloud Strategy?

We’ve heard it so often that it’s cliché now: businesses are overtaxed. Everyone has too much to do but not enough time, resources, or people to get work done, let alone innovate. Everyone is finally accepting the reality: moving workloads to the cloud is one way to find some relief. Organizations are finding that moving to the cloud allows them to focus their valuable technical talent on projects that can deliver real value to the bottom line, instead of constantly focusing on operational fires.

Deciding how to move the cloud can be overwhelming. Instead of looking at this with an operational hat on (how do I get us to the cloud?), this is the perfect time to step back and strategize (why are we moving to the cloud).

This is a really bad example of planning.

Common cloud deployment models
When workloads move to the cloud, you’re ultimately responsible for the data. This diagram shows what IT is responsible for (in green), and what cloud providers are responsible (in grey) for the different cloud models. Data is in blue, because cloud providers will protect data to a point, but you are still responsible for your data.

Know your business (and compliance) responsibilities. In addition to your own data, you’re also responsible for the business processes that you’ve built around each application such as data governance, data protection, archiving, etc. Those requirements don’t disappear, even if you move to a SaaS model where you trust your cloud provider for all of the infrastructure administration. Have a strategy for addressing all of these items once you’ve moved them to the cloud.

Determine the best cloud model for each application. It’s fairly straight-forward to move legacy applications as-is to an IaaS or PaaS model: if it can be virtualized you can move it. This won’t allow you to take advantage of the benefits of running a true cloud application, but at least it provides some relief from operational duties. If your application vendor offers it, the SaaS model can give you immediate operational and productivity gains, your infrastructure is an internet connection. Software vendors using the SaaS model isn’t something new. SaaS has moved beyond “rogue IT”. SaaS applications have a healthy heritage: Salesforce, first released in 1999, is one of the most-used SaaS apps. Google Apps, the productivity suite used by many startups, has been around since 2004. Even Microsoft in 2011 released a SaaS delivery platform, Office 365, for their collaboration suite (Microsoft Exchange, Sharepoint, Skype, etc).

Moving to the cloud will amplify silos.

We all know IT organizations that operate in heavily guarded silos. If you aren’t strategic, once you move applications to the cloud those silos will quickly become very evident very. For example, let’s say your Exchange team is leading your move to Office 365, but they “forget” to talk to the SharePoint team. Since SharePoint is central to Office 365, you’ll have problems right away. Don’t be operational and only run the checklists to cutover to Exchange Online by a certain date. Take the time to include other teams who will be impacted by your decision, and break down those silos before you move.

I hope you realize now that the SaaS delivery model is essential to consider when you are building a cloud strategy. You need to determine which applications would benefit from this model, determine how you’ll re-architect your business processes, and be sure you break down your IT silos to get everyone collaborating before you move and lose control of the hardware and application, where most of IT controls were architected and enforced.

Do you have any lessons learned from moving your organization’s applications to the cloud? I’d love to hear about them!

Image credits: Silos via Chris Yunker

Dibert