Enterprises moving to the cloud now face the reality of moving from a PowerPoint presentation concept, to real work, with real risk and cost.  The presentation is easier, trust me.  However, it’s the cloud implementation phase that finally starts making you money.

The core issue is that most enterprises do not have the experience or talent to effectively leverage private or public cloud-based resources, so this becomes a bit of a trial and error type of process.  Even if you use case studies from other enterprises with similar problem domains, you’ll still run into issues that are unique to your enterprise, including problems with data integration, governance, poor application design, etc..

As enterprises deploy their first cloud projects, there are three kinds of outcomes.  There are those enterprises that implement something that’s not a cloud (e.g., virtualized servers), enterprise IT calls it a cloud, and then declares success.  There are those that implement public or private cloud services in improper ways, fall on their face, and then declare success.  Finally, there are a few that effectively implement cloud-based applications and other resources, and quickly move onto the next cloud projects.

The patterns of success, as well as the patterns of failure, are becoming better understood.  That means we can talk about paths to success, and ways to fail.  Sometimes the most important lessons come from failure.  Here are my top four ways to screw up a cloud deployment.

Failure to understand what the true objectives are before tossing technology at problems.

A core issue in companies looking to implement cloud is that they typically lead with technology and not requirements.  You’re unlikely to have conversations around data security and governance requirements, or core business processes that are paramount to the success of the company.  Instead all the talk is about AWS, Microsoft, Google, and others.  Let’s play with the technology first, and figure out what we’re doing with it later.

The problem with this approach is that cloud solutions, or architectures, are very much dependent upon the types of problems you want to solve.  You’ll find that most cloud deployment leverage more than one cloud model (private, public, hybrid, or multi-), and more than one cloud brand.  It’s not about AWS or Google; it’s about the right architecture that meets the needs of the business.

Failure to consider performance.

Clouds perform well.  Okay, they perform well when leveraged within specific scenarios, with well-designed applications.

Enterprises often consider the ability for cloud to self- and auto-provision as a path to performance.  Provisioning resources does not mean those resources will perform well.  Much of the performance gained with cloud computing comes with good application design versus the ability of clouds to add additional virtual servers as needed.

In order to drive a successful cloud deployment, you need to consider how to leverage the platform of the cloud to the best performance advantage of the applications and stored data.  Applications that are chatty, tightly coupled, or otherwise not well designed perhaps need to be redesigned to perform well in the cloud.

As a rule, you should do some performance testing as part of the deployment, at least to understand the application’s profile in the cloud.  This will determine the behavior on increasing loads.  Make any adjustments before deployment, and put real users on the systems, please.

Not considering security, governance, and compliance.

While you would think that anybody moving to cloud would have security on their mind, front-and-center, the reality is that security is an afterthought at many enterprises.  Security has to be systemic, and engineered into the cloud solution from the start.  Retrofitting won’t work, at least not typically, and often not well.

Governance is also an infrequent consideration.  When dealing with many cloud services and cloud resources, there needs to be a central point of management.  What’s needed is a service governance tool that can track, secure, and apply polices to services, as well as a resource governance tool that can provision and de-provision resources, as needed.  By placing governance in a central layer of abstraction, you’re able to better control and manage your deployed cloud services, as well as cloud-based applications.

Finally, there are the issues around compliance.  Corporate IT has a tendency to over- or under-estimate the existing or future impact of regulatory changes on their use of cloud-based resources.  That means underutilized cloud resources that don’t meet business expectations, or, an unacceptable level of compliance.  You can maintain compliance in the cloud, no matter what industry.  You just have to plan for it ahead of time.

By looking at the ways to fail, the paths to success become clearer.  Understand your business requirements before you consider vendor brands.  Make certain your applications are designed to take advantage of cloud efficiencies.  Build security, governance, and compliance requirements into the system from the beginning of the planning stages.  It’s just that easy…right?