People are focused on transformation everywhere you look. Digital, workforce and particularly cloud transformation. Unfortunately, many of the people telling the story of what’s involved in transformation are using too many buzzwords and talking over people’s heads. Transformation is complicated enough. It helps if we start by keeping the conversation simple wherever possible.

The 6 alliterative points below are the way I typically have a quick conversation about cloud transformation on conference room whiteboards or on the back of a napkin at a lunch meeting. Feel free to use this if you find it helpful to understand the current landscape. In my mind, there are at least 6 domains in cloud transformation that should be on our radar. Please consider this is how I typically start the conversation to see what businesses really need vs. being an exhaustive list of everything under the sun.

  1. “Mimic” – This is where companies drop agents or discovery tools on your network to figure out what your applications and workloads are actually doing. The goal is that they’ll collect enough data to give you an idea of what’s really happening vs. the potentially stale data we all know resides in our spreadsheets and CMDB’s (configuration management databases).
  2. “Model & Map” – Most companies are curious about how the different public and private cloud options in the marketplace fit with their current-state or target-state needs. This piece of the conversation is about what I call “logical equivalents”. For example, I’m running this virtual machine or service today but what would that look like in Amazon? What’s the comparable service if I ran this in Google instead? What if I ran this in a modern on-premise cloud? How much does this cost? What are the gaps? Modeling and Mapping allows you to explore what-if scenarios quickly without committing lots of resources or incurring large bills. This is often how companies sift through an overwhelming list of vendors and options to figure out which services are worth exploring more deeply. (Full Disclaimer – this is where my firm CloudGenera operates. Our goal is to provide quick “directionally-correct” information for common use cases in a working lunch. By the time you finish your meal we’ve hopefully shown you something about cloud you didn’t know before).
  3. “Measure” – This component is about getting an objective readout on price per performance of logically equivalent services. That comparison can be between vendors or even within the same vendor. How does a 4-core, Linux virtual machine in AWS compare to one in Azure? How does the A-series (General Purpose) in Azure compare to the new L-series (Storage-Optimized) in Azure? How does Simplivity compare to Nutanix? VMware vs. OpenStack? Think of this as a way to determine the relative “horsepower” of the offerings or services you’re considering. Exploring this component of cloud transformation helps you unpack cheap vs. inexpensive. For example, a cheap (initial cost) option may cost you more in the long-run if the price per performance is poor. I need 4 instances of a server in provider A to get the same performance as a single server in provider B. (CloudGenera has partnerships in this space and offers a managed service to help you figure out price per performance).
  4. Manage” – This component is about having a way to provision and de-provision specific services in execution venues. If each cloud provider your company works with is analogous to the components in your home entertainment stack (TV, Set-top box, DVD Player, etc), then the Management component is like the universal remote that talks to all of those devices. Many management platforms also provide ways to set up workflow, policies and automation so governance is in effect for how your users consume resources.
  5. Move” – This component is about getting workloads from one execution venue to another (out of your data center for example). Isn’t this the same thing as Manage? Not quite. Let’s pretend workloads are like Grandma’s Bundt cake. A management component could replicate the recipe for Grandma’s bundt cake and bake it in the AWS oven. A “Move” component would take the actual cake Grandma baked at your house and move that cake to the AWS or Azure residence. Sometimes you need to move the actual workload because you lost the recipe and can’t afford to experiment.
  6. Modernize” – I would argue that the first five components in this list have software packages or tools that can do most of the job. Modernization is different. This is usually consulting and depends on the state of workloads in a given environment and a customer’s appetite for change. Some examples of modernization could be upgrading a workload from Windows 2003 to Windows 2012. Another example would be transitioning from a large, commercial relational database to an Open-Source, NoSQL database like MongoDB. Figuring out if your team is ready to handle new concepts like containers, Microservices, DevOps and automation also falls in this category. Smart people have to be involved here. There is no “automagic” button to do all of this seamlessly.

A few things to consider:

  1. If you’re an enterprise – what do you really need? If you want to get 100 workloads out of your data center as quickly as possible, you need to call one of the companies with specialized software in the “Move” space. If you want to connect to multiple cloud vendors & services, you need “Management” Software. If you want to understand which workloads go where, you need “Modeling and Mapping” software. Think about what you need and pursue (ideally) vendor agnostic solutions that can solve those problems. Be wary of the companies that argue they do all of these areas well. Cloud Computing is too complex (and too immature as an industry) for anyone to do everything well.
  2. If you’re a vendor – consider where you fit. Make sure you tell your story so people understand what you do and how you complement investments your customers have already made.
  3. If you’re confused – you’re in good company. Most of us are still figuring things out and guessing what “the cloud” wants to be when it grows up. It’s ok to bring in smart people to help your organization navigate these conversations so you don’t hit every landmine. Benefit from the lessons and pain others have experienced before you. “The cloud” is still fairly new but there are some obvious pitfalls that experts can help you avoid.

Most of us think we need more information. That’s not the problem as we’re already drowning in information. What we really need are people who can move us from information to clarity to insight.