I wrote this post for Woolpert to kick off a blog series that aims to be practical guidance for shifting to the cloud. It shouldn’t be rocket science. But it should be a little thought provoking and help you get in the right mindset
Introduction
I wish you well on your cloud native, multi-cloud, digital transformation as you DevOps your culture while taking a hacksaw to your monoliths.
— Kelsey Hightower (@kelseyhightower) January 9, 2021
That Tweet by Kelsey Hightower is a tongue-in-cheek version of the buzzword heavy phrases we’ve all probably heard in relation to digital transformation. But practically speaking: What does it mean? And how much of it applies to your situation? And does it even make sense?!
In 2021, the Woolpert Cloud Solutions team will publish a blog series: A Practical Cloud Journey. We’ll focus on prerequisites to success, such as a focus on customer value, and how to make decisions in context instead of from canned playbooks. In this first blog in the series, I want to provide some of that context and give a preview of some of the topics we’ll discover in the coming year. Are you ready for a journey? Here we go!
Preparing for the Trek
I live in Colorado, which is home to 58 mountains that stand at least 14,000 feet (4,267 meters) above sea level. Locally they are called either Fourteeners or 14ers. Climbing a 14er is not something you do without planning. Before your hike you need to understand the route, pick a summit time that will avoid the inevitable afternoon thunderstorms, arrange transportation and have the right equipment.
There’s also the physical preparation. For example, before I tried my first 14er I went on a few longer day hikes at high elevations to make sure what I’d packed in my backpack was adequate: food, water, clothing, emergency supplies and a chocolate bar as my reward for reaching the summit. Practicing helps work out the kinks and builds familiarity, not to mention strengthening fitness and skill.
Clouds and Mountains
The preparation needed for approaching your movement to the cloud is similar. As a novice hiker, would you try summiting a 14er in your first week? And as a business relatively new to the technology, would you attempt to move a mission-critical application from on-premises to a public cloud on Day One? I hope the answer to both is “No way!”
The input of an experienced friend or colleague also can prove highly beneficial. Unless you have an exceedingly high tolerance for risk or adventure, you likely wouldn’t try to climb a mountain without consulting someone who has completed that trek. Just like when shifting to the cloud, you’ll find it’s a good idea to talk to someone who has been there and done that. I’d prefer to have a friend tell me to wear two pairs of socks to avoid blisters than to learn that from a painful experience!
Depending on your organization’s strategic plan, you may feel like you are facing a 14er. But not every cloud journey involves climbing mountains. Often the journey is more modest; the proverbial walk in the park … like shifting a single existing application from on-premises to hosted. But even then, there are practical steps to prepare. In Colorado, for example, I always wear a hat, take a water bottle and pack a light jacket.
A Practical Cloud Journey Starts with User Value
The first step on a cloud journey should, in my opinion, start with a statement of value that directly addresses the end-user, client or customer. What and how you do something must flow from the customer value you’re trying to achieve.
Jim Highsmith, Linda Luu and David Robinson discuss this at length in their book, “EDGE: Value-Driven Digital Transformation.” For example, if you ask a project team to “deliver System X on the cloud with a lower OpEx than the current system,” you might get a cheaper System X but there will be no real benefit to customers.
But if you ask that same team to “reduce the end-to-end time to get final data to customers,” you should get a result that is aligned with customer value. That may involve shifting System X to the cloud … or maybe not. The point is that the project team will make the right decisions based on the overall goal.
Every Organization is a Technology Organization
That really doesn’t have anything specifically to do with cloud migrations, except that Highsmith, et al., also asserted—correctly in my view—that every organization is a technology organization at its core these days. So, it makes sense that a cloud journey would need to start with customer value.
However, don’t confuse picking the latest cloud technology stack with picking the appropriate tech stack. Being a tech organization doesn’t automatically mean you are making sound technology decisions. A fun way to think about this is to look at the degenerate case. How often have you heard an IT or engineering team geek out over the latest shiny tech? How often is that aligned with customer value? Not always? Yep, I thought so.
In a 2020 interview, Kelsey Hightower describes something he hears all too often:
“Oh, we’re bringing in Kubernetes so we can do microservices. We are going to rearchitect everything.”
Where is the customer value there? Kubernetes might actually be an amazing decision—autoscaling, potentially lower operational costs, improved SLAs—but only if it ultimately benefits customers.
“… it’s just a lot of buzz that people are attaching their assignment to, when honestly it’s not gonna necessarily solve their problem.”
Step One: Know what the customer or user value is and use that to drive business and technical decisions.
Context is Key
“We need to get off our current failing infrastructure fast, so we’ll move what we have to the cloud.”
That’s a way different—and very real—task as compared with this:
“We need to build a mobile tool for our employees that talks to existing systems but should not conflict with our existing infrastructure.”
Context really, really matters. You need a different skill set, budget expectations, security model and tolerance for risk. A cloud architect will consider the business drivers first and then start thinking about which frameworks, tools, products and approaches to bring to the solution.
Broadly, the context is that every organization is a technology organization, and customer value is different for each. In detail, it might be the balance of customer value in a faster (low latency) web app vs. the operating budget for the team keeping it all running.
Elements of a Journey
Themes you will hear about in this A Practical Cloud Journey blog series include:
- Type of work. We will discuss a couple specific types of projects in this blog series, like app modernization, to help make those decisions real.
- Mindset. Saying “we’re going to do DevOps,” when what you really want is a repeatable and short cycle between having an idea or goal, and seeing it delivered to users. This often means a willingness to experiment to gain knowledge rather than to “win.”
- Platforms for enterprises; products for users. Businesses typically don’t buy apps, they buy platforms. For example, Microsoft Excel is a great single-use app, but easily adding specific functionality in a way that satisfies IT cybersecurity policies or access control is not its strong suit. That’s where business applications suites have evolved to be more like platforms.
- Costs. The cloud is cheaper … until it isn’t. Moving an existing workload optimized for a data center or on-premises model just shifts cost rather than adjusting for this cost. Many of Woolpert’s clients ask us for advice on optimization, because nobody likes to be surprised by a bill.
- Non-features. Features you don’t notice until they’re missing, like speed, availability, durability and mean time to recovery. You have to be aware of those as real features that drive business and technical decisions vs. “just the operational metrics.”
Beginning with a Single Step
So, let’s start our journey and keep it practical. Yes, we aspire to summit a 14er, but we need to remember our sun block and our map—this way we are protected and we know how to reach our destination.