Tackling the Top Four Most Common Cloud Governance Antipatterns

What are cloud governance antipatterns? Antipatterns usually start out as well-intentioned ideas that seem like the right move, but they actually end up preventing an organization from realizing their cloud adoption goals. Assuming you have all the information needed to make a decision – that’s an antipattern. No organization ever starts their cloud journey without being well intentioned, but without well-defined goals and objectives, the cloud can quickly develop antipatterns and travel off course. Let’s talk about the most common antipatterns that we see and how to tackle them.

1. Undefined or Ill-Defined Goals for Cloud Adoption

The most common antipattern we see when working with clients is when an organization has not defined goals and objectives for cloud adoption. Many companies announce cloud-first or cloud-only strategies. But they don’t clearly define what they want to achieve with those strategies. Few cloud projects can succeed without concrete KPIs and goals. It’s impossible to measure project performance without indicators or specified targets. In software engineering, you’ve heard about the concept of a “big ball of mud,” where the overall structure of a system is not well defined. It’s similar in cloud adoption, where the cloud can become a “big ball of mud” if not clearly defined.

Real-Life Example: Migrating to the Cloud Without Defining Goals

A corporation’s closest competitor launches a cloud-only strategy. The competitor’s goal is to accelerate business by having all systems in the cloud within a year. The corporation doesn’t want to trail behind. The corporation’s directors begin strategic discussions on how to adopt the cloud quickly. But they don’t define any concrete success criteria like reducing costs or improving system performance.

The corporation’s first system migrates to the cloud. The directors can’t check whether their cloud strategy is successful because they never defined what they wanted to achieve.

You know that the cloud delivers exceptional benefits for organizations, but what is motivating your move to the cloud? What are you looking to accomplish?

If you are looking for increased accessibility, security, or resiliency, what will that actually mean for your organization? Dig a little deeper. Have conversations with key stakeholders in your organization to define these goals so that you will know when you are successful. Will success be immediate? Within 2-3 months? Within 2-3 years? Define a timeline.

Without defined goals and KPIs with a timeline attached to them, you may risk replicating what you had on-premise in the cloud, which is not cost-effective. The natural tendency for organizations is to stick to what they are familiar with, and that can leave the strategy tunnel visioned.

Who should be involved in the conversations to define goals? Initially, the technical team should sit down with business leaders at least once a week for cloud strategy meetings to discuss at a high level what they would like to accomplish with the cloud. Then, involve directors and managers, who should meet with line workers to develop a big picture which aligns with future goals. These iterative conversations align your entire organization with goals, and lead to a higher success rate. It makes everyone feel involved and a part of the success of the cloud initiative. As the cloud evolves, monthly meetings can help an organization stay on track.

2. Misunderstanding Shared Security Responsibilities with Cloud Provider

Another common antipattern which can develop is when an organization misunderstands what responsibilities are theirs and what are the cloud provider’s when it comes to security.

Real-Life Example: Managing Updates

Members of a company’s HR department set up many Windows servers in the cloud using infrastructure as a service (IaaS). They assume that the cloud provider manages updates because on-site IT usually handles update installation. The HR department doesn’t configure the updates because they’re not aware that their cloud provider doesn’t deploy and install operating system updates by default. As a result, the servers are noncompliant and pose a security risk.

It’s important to understand shared responsibilities from the start of the cloud journey, or it will hinder the progress of cloud adoption. What falls under the purview of the cloud provider? What is the technical team’s purview and responsibility? How about the organization? This will help dictate what the right cloud adoption looks like and will foster a partnership between the organization and the cloud provider.

For all cloud deployment types, you own your data and identities. You are responsible for protecting the security of your data and identities, on-premises resources, and the cloud components you control (which varies by service type).

Regardless of the type of deployment, the following responsibilities are always retained by you:

• Data
• Endpoints
• Account
• Access management

Shared Responsibility which you need to discuss with your cloud provider, and can be up to you or them, are:

• Identity and directory infrastructure
• Applications
• Network Controls
• Operating System

Responsibility which is always your cloud providers:

• Physical hosts
• Physical network
• Physical datacenter

3. Inaccurate Security Assumptions

Speaking of security, another antipattern develops when organizations make inaccurate security assumptions. All clients want to be more secure but approaching security can be vague or confusing. By failing to recognize certain risks, or assuming that they don’t apply to your company, you could be leaving yourself vulnerable to a breach.

You need to define who can access your data, who you can share data with outside your organization, and who can access your systems. Who can grant security? What is your current security posture? Some organizations assume that security in the cloud is inherent, and it’s not. It’s like moving into a new house and assuming that every lock is secure. You may find that there are areas in the house which need more locks or shouldn’t be accessible at all. It’s the same in the cloud. There is a layer of security in the cloud, but you need to tailor it to your organization specifically. And security evolves over time. Set up a monthly or quarterly cadence for these security conversations.

Real-Life Example

A client endeavored into cloud on their own, assuming that their data would be protected “automagically.” When there was a security breach, there was a real problem when they didn’t have a recent backup.

We helped them set up the security measures and define backup frequency and how long to keep backups. Now, when or if a security event happens, they can be sure that they have the most recent backup that they need. Don’t assume there’s an easy button.

4. Being Dazzled by the Technology

A common antipattern, and one I’m guilty of as well, is that we look at technology for technology’s sake without identifying an end goal.

Real-Life Example: Introducing a Platform That Doesn’t Improve Performance

A company introduces a new, improved version of its continuous integration and continuous delivery (CI/CD) platform. The tool makes it easier to define delivery and deployment pipelines, so you can deploy features faster. The IT department is dazzled by the technology and enthusiastic about delivering a platform that speeds up the pipeline configuration. Once a business unit uses the tool, it discovers that the time to market isn’t significantly better, compared with the old platform. The final approval and release process isn’t changed or improved.

Final Thoughts

It’s important to take the technology out for a minute and define what you are trying to accomplish. This exercise frees you from locking into a technology, and instead allows you to look at the problem holistically. The answer may not even be technology, it could be changing a process. Taking the technology out allows you to work backwards to find the right solution, which may be different from what you first thought it would be.

The purpose of the cloud is to add resiliency, security, efficiency, and insights. What is the right solution and process mix to accomplish these goals? It’s dangerous to invest in technology without involving the business in the decision-making process. Remember to involve key decision-makers and establish goals to stay on track.

The biggest problem with antipatterns is that they start out having such great intentions. You want to improve your business. But without a plan in place with clear goals in mind, you can quickly veer off course. The good news is that another solution exists to the problem the anti-pattern is attempting to address. This solution is documented, repeatable, and proven to be effective where the anti-pattern is not.