Authored by Jamison Deba

Cloud is all the rage these days, and for good reason.  But just like every other buzz-worthy concept, the promise of the “cloud” can only be realized through careful, skillful, and even artful implementation.  Cloud computing is a complex and moving target of advanced and continually advancing technologies, but the value of the cloud to business is actually quite simple: Cloud capabilities are like LEGO bricks that can be put together in an infinite number of ways to create just about anything.  That’s great, but it takes up-front and skilled design while utilizing the right bricks in just the right place in order to result in something meaningful, valuable, and (hopefully) beautiful.

The most fantastic aspect about the cloud is that your box of cloud LEGO bricks is full of customizable capabilities that are proven, purpose-built, and ready to deploy and scale globally within minutes.  But just like a big box of these colorful cubes, these cloud building blocks are very difficult to assemble in a meaningful way, it takes significant skill to create something valuable, you can easily end up frustrated, and if you’re not careful, they are likely to inflict pain in the middle of the night.

Cloud is not a panacea, and cloud without skill and strategy can easily multiply problems, compound complexity, and explode in cost.

That’s the bad news.

The good news is that real business value can be achieved more quickly, more reliably, and more cost-effectively in the cloud than at any other time in history.  Furthermore, cloud levels the playing field by making world-class capabilities available to the smallest of companies, the largest of corporations, and every size organization in between.

The cloud cannot be ignored, and every single business needs to have a solid, well-crafted strategy that provides guardrails for deploying cloud resources.  Care must be taken, however, to ensure this cloud strategy is focused on enabling reliable, secure, and performant use of cloud capabilities, because traditional IT mentality is a common and easy fallback which can result in a cloud strategy that is overly focused on governance and what can’t be done as opposed to how business objectives can be enabled and jump-started by leveraging the paradigm shift that is the cloud.

Just like any other technology, adopting cloud technologies and realizing the benefits is a journey, and this journey must be a careful and intentional undertaking.  A company can’t simply decide to “do the cloud” and expect success.  Instead, an intentional path must be laid out and carefully executed to ensure that success.  This need not take a long time, but investing the time to ensure the path is known and the strategy is sound will certainly reap rewards well beyond the investment.

The journey to operating in the cloud is no longer a choice for most organizations.  The cloud is here, it is here to stay, and while it provides competitive advantage today, it will present an adapt-or-perish scenario tomorrow.  Differentiation will happen both in when an organization starts the journey to leverage the cloud and in how well that journey is executed along the way.

There are five key aspects to this journey that must be approached in an iterative fashion.  In other words, this is a forever process that must be carefully orchestrated with intentionality to reap the benefits of leveraging services that are increasingly commodity-like while simultaneously avoiding being left behind in your industry.

Resource Download: Click here to access a free recording of this webinar

Introspection: Where are we today?

Determining how to get where you want to go requires that you first understand where you are starting from.  This requires a deep, honest, and exhaustive look at where the business currently stands in terms of existing technology as well as in its cloud journey.

Considerations:

  • Business Systems – Categorize by criticality, type (COTS, custom, etc.), annual cost, etc.
  • Integrations – How does data move between business systems?
  • Analytics – How readily available is business data for analytics, and what is the level of trust in the accuracy and timeliness of that data?
  • APIs – Are APIs nonexistent or ubiquitous or somewhere in between?

Introspection must be a continuous and iterative process.  Brutal honesty is vital because an accurate view of the current state provides the foundation on which next-step decisions are made.  During this current-state introspection, it is important to dedicate enough time to truly understand not only what the current state is but also why the organization has arrived at that very state.

  • Is the technology landscape riddled with point-to-point integrations that cause fear with each and every production change?
  • Are there unused features or even entire products that should never have been built in the first place?
  • How quickly can an idea move to development and then into the hands of an end user?
  • What type of downtime has been experienced over the past X months?
  • Are there areas of manual intervention needed that could be replaced with automation?
  • How can we lower the level of skill required to support our portfolio of applications?

There should be no judgment, but it is important to take a deep, honest look into what led to the current business technology situation so that it can inform the go-forward plan.  The act of intentional analysis of past failures provides an invaluable opportunity for redemption in the form of learning from the past to shape a better future.

Goals: Why?

Moving to the cloud must not be the driving force behind the effort.  There must be defined and measurable business goals that will be realized by leveraging cloud capabilities.  Every single person in the organization must have a clear understanding of why the business is moving in the direction it is moving and be able to clearly articulate where they contribute to that overall goal.

Considerations:

  • Cost Reduction – Move expensive operational aspects to the cloud in order to achieve cost reductions in hardware, labor, or both.
  • Improve Time-to-Market – Enable faster iterative development and deployment of new business capabilities
  • Improve Operational Excellence – Reduce downtime and/or customer impacts due to system slowdowns or lack of availability
  • Leverage Managed Services – Provides a combination of cost reduction, optimized operations, and high availability

Most importantly, ensure that business goals related to the cloud are measured.  Otherwise, it can be too easy to end up chasing a ghost, and it might feel like progress is being made while having no concrete understanding of whether or not the effort is resulting in bottom-line value.

Prioritization: What will we do?

Initially, it is important to test the waters before moving mission-critical items into the cloud.  Crawl before you walk, walk before you run.  Iteration is key in this step of the cloud journey because the cloud enables businesses to adapt to the market with a previously unattainable velocity.  But careful and continuous prioritization is required in order to know when to pivot, change, or even abandon an effort.  Along this journey, it will become clear when a critical mass of automation, monitoring, and elasticity will allow for the migration of mission-critical workloads.

Considerations:

  • Test the Waters – Identify some “low-hanging fruit” which would provide business value but not be mission-critical. Use this implementation to make mistakes, iterate, automate, and build necessary skills.
  • Move vs Re-Architect vs Re-Write – There are different benefits and drawbacks to each of these.
    • Lift and Shift – Minimal benefit while still offloading complex and expensive data center operations to the cloud.
    • Re-Architect – Careful selection of cloud capabilities and managed services to inter-twine with legacy operational systems, either on-premise or migrated to the cloud. A great first step is in identity and security.  Database migrations are also good candidates because of the unmistakable cost savings that can be realized.
    • Re-Write – For some key aspects of the business, a full re-implementation is warranted in order to gain benefits and competitive advantage. Sometimes you simply can’t get there from here, meaning you can’t meaningfully iterate from where you are to where you know you need to be.  In this situation, retain your steady-state solution as you build out a parallel new implementation to replace it.
    • Cloud Native – The cloud opens a whole new world of opportunities to leverage technology in ways the organization currently doesn’t take advantage of. Data and analytics are prime candidates in this space.  Be sure to consider that leveraging data in new ways through advanced analytics, machine learning, and AI is currently novel but will certainly move into the realm of commodity in the future.  This will be a key area where organizations are left behind because they simply can no longer compete.

Strategy, Governance, Operations: How will we adopt the cloud?

This aspect of a cloud journey is all about ensuring that the standards, behaviors, and culture of the organization are aligned with best practices of the cloud.  Just like the others, this is an iterative process that improves over time, but requires continual care and feeding to ensure workloads are operating reliably and cost-effectively and that changes are introduced continually, effortlessly, and fearlessly.

Considerations:

  • Security – Must be “baked in” to every aspect of anything and everything that is implemented in the cloud. A mindset shift may be required from perimeter-based security to security at every level. Includes access control, encryption (in transit and at rest), and incident response.
  • Cost Control – Just because you can doesn’t mean you should, and it certainly doesn’t mean you can afford it. The cost must be considered at every level of cloud strategy in order to realize the pay-as-you-go (PAYG) commodity aspects of the cloud.
  • Architecture – It is crucial to get this one right. Cloud architecture can run the gamut from running 90’s style implementations on someone else’s servers to fully de-coupled, serverless, PAYG architectures that scale effortlessly at a price point that is a fraction of traditional IT architectures.
  • Monitoring – Cloud capabilities provide simple monitoring capabilities with a low bar that can be continuously improved and evolved. No excuses here.  Your cloud systems should be fully and automatically monitored so that they are self-adjusting, self-healing, and self-alerting.  Start small but start now.
  • Automation – Automate everything.   This is more habitual and cultural than a technical hurdle.  Take stock of current skill sets within the organization, level up where needed, then consider some type of “automation proclamation” where henceforth manual processes are no longer tolerated. This is a bandage to rip off, and the sooner the better.

Execution:  Who will be needed?

Irrespective of the size of an organization, a clear and intentional execution plan is paramount to achieving the most sought-after yet disproportionately elusive benefits of the cloud.  Automation is key and must be or become ubiquitous, but that only scratches the surface of what is required.  This aspect is generally the most difficult because it is deeply rooted in the people of the organization.  This means that key leadership is required to build a cloud-centric team that is willing to put in the effort to continually learn, reflect, and possibly move on from technologies they are comfortable with in favor of the promise of achieving faster and better business value.

Considerations:

  • Development – Individual(s) who provide business value through the implementation of new features through custom code, COTS configuration, low or no-code solutions, or any combination thereof.
  • Tooling – Individual(s) who build and maintain automation, policies, and pipelines for moving new systems, fixes, and features to production.
  • Operations – Individual(s) who are responsible for ensuring the delivery of technology to end users without interruption.

You can’t do DevOps, you must be DevOps.  DevOps is a mindset and almost religion-like. It must inform and influence everything from cloud strategy to daily operations.  Every member of the team needs to be a “DevOps Engineer” and be able to play their part in ubiquitous automation, security, performance, and cost control.  This can be a very difficult culture to foster, but it very often can be self-sustaining once a critical cohort of engineers realizes that being DevOps is not only good for the business but is even better for themselves.

Understanding the Cloud Paradigm

Finally, there is one additional concept regarding cloud that is important to understand, because it opens a new realm of possibility through expanded understanding of the paradigm of the cloud.  We’ve already covered the main ways to leverage the cloud, but it is vitally important for anything that is rewritten for the cloud or build native for the cloud to understand the cloud paradigm.  Cloud is so much more than someone else’s servers, and the true power of the cloud can only be realized through both learning what is possible with cloud technologies, but also through unlearning old concepts and paradigms which would otherwise hold you back.  How you approach the cloud and how to use the technologies of the cloud make up your mental model.  You view everything through this mental model, and it colors how you approach solving problems.  Continually expanding and refining your mental model with modern best practices and concepts will result in solutions that leverage cloud in ways that your previous mental model would not have allowed.

Consider the concept of a “server” and what you might think of as a “server.”  In the cloud, you can certainly work with a server or a virtual server, just like you have always used servers.  You will get some benefit, no doubt.  But if your mental model stops there, you will never graduate to the power of leveraging various types of compute that are made available by the cloud, as a commodity to an increasing degree.  And this is just one example.  Your mental model around “database” might be stuck in a relational model.

Relational databases are a fantastic tool for specific purposes, but they have some key drawbacks in scalability, replication, and other areas.  Many of these shortcomings have some perfectly fine workarounds, but the technology, just like any technology, is inherently limited.  New techniques and technologies abound, but in many cases require that you un-learn some things in your mental model to make room for an expanded array of options.

I will give one last brief example to drive this point home.  This one is a bit more abstract but still fully applicable to un-learning something in your mental model in order to expand it with a broader replacement.  I’m talking about how you approach code or infrastructure or anything else in the execution step of your cloud journey.  You can use either an imperative or declarative approach, and the best solution is many times in between.  When I describe the difference between imperative and declarative, I use the analogy of giving directions.  If we run into each other at the park and you ask me how to get to the grocery store, I have two ways I can help you.  I can give you a set of steps that will direct you from the park to the grocery store, which is an imperative solution.  Or, I can give you the address of the grocery store, allowing you to use the tools at your disposal to navigate you to the desired destination.  Both of these solutions will achieve the desired result, you’ll end up at the grocery store, but you might consider: Which one is better?

Imperative instructions define steps from one state to the desired state, and those instructions only apply when you are starting at that one state.  Conversely, declarative instructions describe the desired state and rely on the existence of tools to make that desired state reality.  The declarative example will get you to the grocery store regardless of where you are starting, but the imperative instructions require that you start at the park.  However, the declarative example requires that you have the tools required to achieve the desired state whereas the imperative example gives you the information you need without requiring these tools, even if it only applies for that one case.

Unfortunately, it is impossible to create a how-to set of defined steps to ensure success in leveraging the cloud.  Cloud is an art.  Cloud is a never-ceasing flow of decisions, each with their own unique trade-offs.  There simply is no right answer, but there are plenty of wrong ones.  And it all comes down to people.  Cloud requires the right people who understand what is possible, have experience to know what works, and, more importantly, how to avoid pitfalls.  Cloud often requires unlearning prior to learning and requires continuous learning across the board.  Therefore, more than anything else, an organization can realize the promise of the cloud through investment in the right people, building a cloud culture, ensuring continuous improvement of skills, and iteratively making progress by carefully working through these five aspects of the cloud journey with a clear understanding that the journey will never be done but that the business and the people who support the business can benefit all along the way.

 

Want to talk more about your cloud strategy? Reach out to our VP of Consulting, Susan Miller, to learn more about how BridgeView Solutions can help you.

 

Related Articles

Is the Cloud Finally Secure?

Webinar Download: Managing a Remote Agile Team in a Virtual Workspace

Are You Making the Wrong Decisions for Your Data?

Written: June 2020