Keys to Creating an Effective Cloud Strategy

Note: This article was originally published on Geek.ly at the following URL: http://geek.ly/AfV

While companies are scrambling to “move to the cloud,” most don’t know what that entails, and even fewer have an actual cloud strategy. Having a nonexistent or poor cloud strategy wastes time and money, of course. Moreover, a poor strategy can cause long-term negative effects on hiring, employee retention, partner trust, and reputation. The reality is that a bad cloud strategy can kill a company and is probably worse than no strategy at all.

Before we define good strategy, it’s helpful to define what good cloud strategy is not. Choosing a vendor is not a strategy; in fact, having a vendor opinion is just the beginning of a story that includes many more technical choices, sweeping organizational implications, and probably cultural upheaval. A vendor should support your strategy, not define it. The best approach involves engaging a vendor as you would any other trusted partner. Be honest about your company’s own maturity and expectations and carefully consider the vendor’s engagement and alignment with you.

But before you go shopping for a vendor, create your cloud strategy. The effective cloud strategies I’ve witnessed have come from companies that defined their missions, leveraged abstractions for functions that don’t provide direct value, and delegated as many of those abstractions as possible.

Mission

An effective cloud strategy starts with a definition and understanding of mission, also known as the answer to “why” mixed with a little “what.” (A bad mission tries to answer “how.”) A mission’s focus can be as narrow as a specific project or product, or as wide as the entire company. The mission serves as the north star to remind and guide the stakeholders in setting business objectives and making future decisions; it sets the tone and direction, while leaving room to explore beyond today and even tomorrow.

Defining a mission is difficult but important work. Do not skip this step.

Abstraction

Next, leverage abstractions where you can for functions that don’t provide direct value. I think of abstraction as “offloading complexity”; it is fundamentally about managing complexity in support of your mission. Your goal should be to work only at the level where complexity brings business value and abstract everything else. Is there business value in a travel booking website that owns an electrical utility company? Probably not, but perhaps there is business value in a travel booking website that maintains an open source API that interfaces with the major travel agencies. Of course, creating abstractions is more challenging when the question “does this function bring value” does not have an obvious answer.

Cloud represents a shift in how we think about delivering value by allowing us to focus on value creation. Understanding this principle allows us to view what needs to be owned and operated differently. For example, IaaS (Infrastructure as a Service) is the first real abstraction over the old data center. We no longer have to think about real estate, power, physical security, hardware and hardware failure, HVAC, rodents, or natural disasters. IaaS abstracts all these considerations away.

Cloud represents a shift in how we think about delivering value by allowing us to focus on value creation.

Cloud represents a shift in how we think about delivering value by allowing us to focus on value creation

As we move up-stack, the abstraction value multiplies. Moving up from IaaS to PaaS (Platform as a Service), and to even more holistic services, abstraction provides greater value through operating systems, security, networking, bandwidth, virtual machine management, storage, database primitives, monitoring, abuse detection and prevention, backups, failover, and so on. The appropriate level of abstraction for you depends on your mission, your business objectives, and your organizational maturity. In my experience, companies are often too conservative in their abstraction, continuing to do work at even the lowest levels (e.g., still running their own servers). I have found it to be more prudent to pursue value aggressively. The abstraction principle succinctly is do not reinvent wheels, spend your resources on your differentiators.

Delegation

Next, a good cloud strategy relies on delegation of abstractions. Paying another company to worry about complexity is one of the greatest ways to accelerate differentiation in cloud computing. I sleep better at night knowing I don’t have to be an expert in all things lower in the stack, and that by delegating those responsibilities, I am taking advantage of economies of scale.

Even more importantly, delegation of cloud responsibilities frees a company to focus on its mission and grow its own value. If you choose not to delegate down-stack responsibilities, you are wasting resources on activities that don’t result in direct business value. In other words, if you are performing work someone else could do faster, cheaper, or better, you are simultaneously not doing something that could bring value to you or your customers. This is your opportunity cost, pure and simple. I recommend you seek to aggressively delegate more abstraction to the cloud and third parties.

Examples of Mission, Abstraction, and Delegation

Imagine there are two competing companies with the same mission: to be the Uber of dog walking services. Both companies need to hire programmers to get their product to market, but one company uses a known programming language and SDK, while the other decides to create their own language before they start on product development. The second company has much more non-value overhead and takes longer to contribute to their core business. This may sound extreme, but situations like this happen all the time when companies move to the cloud. This behavior needs to change if the organization is going to survive and grow.

Another example can be seen in the non-tech world, with a dentist who has the personal mission of bringing dentistry to a rural town. Because the dentist needs a regular supply of food for herself and her family, she has the idea of running her own farm. But doing so would involve a considerable time commitment as well as capital and expertise outside dentistry. The first level of abstraction and delegation is to hire farm workers and perhaps outsource the health of the animals to a local vet.

The dentist works to find more abstraction, and realizes there is incredibly low value in operating a farm when her mission is dentistry. So the dentist sells the farm, and instead buys food from a local farmer.

The farmer can manage the complexity and all associated challenges of farming, and the dentist is happy to pay the farmer for having delegated that service to him. It’s true that the dentist might pay more for the food than if she had grown it herself. But her decision to abstract and delegate the food production allows her to focus on that which brings her value — dentistry — and not waste resources on farming.

A good cloud strategy relies on delegation of abstractions

Creating an Effective Cloud Strategy

So, back to our original question: how can we help our organizations develop good cloud strategies? We must define, embrace, and ruthlessly defend our mission, abstraction, and delegation decisions.

How can we put that advice into practice?

First, define and understand your company’s mission. This will help you understand your core competencies and where you want to focus your energies.

Second, continually ask the following set of questions about any and all business functions and processes, train others to ask them, and make them part of your strategy reviews:

• Is this something that we are uniquely positioned to deliver? If no, reconsider.
• Will doing this work bring us explicit business value? If no, reconsider.
• Are we doing this for a specific long-term strategic reason? If no, reconsider.
• Will doing this work enhance our value creation? If no, reconsider.
• Are we competing in a race to the bottom? If yes, reconsider.
• Is doing this work a competitive advantage? If no, reconsider.

The value is in asking these questions any time you are in doubt about a direction. Should you build your own operating system? Should you build your own GPU? Should you build your own database? Should you build your own datacenter? Should you write your own JavaScript framework? Should you write your own programming language? Your cloud strategy starts to emerge.

Finally, continually and vigorously debate the above questions and answers, and refresh them with ones you’ve adapted to your specific needs. Explicitly challenging assumptions and your status quo is the healthiest way to give your situation the respect and consideration it deserves.

Conclusion

Mission, abstraction, and delegation ultimately save time and money while creating the environment for accelerated business objective delivery. Finding and understanding what is best for your organization will guide your answers to many of the downstream questions that you will eventually have to address, such as vendor, technology, process, and talent. Understanding your mission, and knowing your appropriate level of abstraction and what you want to delegate, helps you answer one of the most important questions that often gets overlooked: “what are we not going to do?”

When you complete the exercise described in this article, you will have the makings of a solid cloud strategy. On the other hand, if you neglect to consider mission, abstraction, and delegation at the onset, you will be in the same boat as other companies looking to make up for non-value opportunity cost as they track forward. Which would you rather be?