November 10, 2020
Cloud Transformation – Where the Journey Begins
Last year I wrote a blog about Cloud Readiness that focused on the core technology/workflow requirements to account for when planning a move to the cloud. Today I wanted to chat about the step prior which is the Cloud Transformation. Cloud transformation is simply the overall process of building and executing a strategy of moving workloads to the cloud. While cloud readiness is certainly a major component of the transformation, there are 6 other key areas such as:
- Cloud Service Types (fit your use case)
- Cloud Provider Selection
- Desired Operating Model
- Total Cost of Ownership
- Migration Approach
- Cloud Readiness Assessment
It’s important to mention that while this process can apply to all aspects of your organization, cloud transformation can start with one or two workloads or use cases like disaster recovery, long term archiving, or even backup vaulting while building and testing a scalable framework for the future.
Cloud Service Types:
Cloud Service models have been well defined for some time but service providers continue to expand the offerings around each and expand the operating models for each.
The 2 most common models deployed in healthcare today is IaaS and SaaS. Many EMR vendors are moving towards SaaS models while some offer IaaS and “Managed” IaaS. Managed IaaS is an operating model that we have seen widely adopted in the small to mid-size medical facilities.
Cloud providers can mean a few different things depending on several variables. Cloud providers to some may be the big “3” in the space which are AWS, Azure, and Google. But for some that are looking for Managed IaaS or Managed Cloud, that’s where companies like CloudWave come into play.
In my experience and opinion and I have certainly been challenged on this both internally and externally, Cloud Providers are not a 1 size fits all. While Office 365 runs on Azure and has seen and will continue to see increased adoption (mostly because Microsoft is making it that way!) that doesn’t necessarily mean that all the compute workloads are a great fit for Azure.
Selecting an operating model that suits your business requirements is something that everyone in the industry wished was prescriptive. Every organization I’ve been fortunate enough to work with on cloud assessments, planning, and implementations has proven that although having well-defined processes and approach methodologies in place helps, every hospital is different. The chart below is “typical” operating differences between the different operating models. This requires a detailed review of each of the criteria but is representational of the high level operating models available in the industry as you start your journey. Like my mindset around selecting a Cloud Provider, I don’t believe that the operating model for every workload is a one size fits all.
Ahh, everyone’s favorite topic. The total cost of ownership is one of the major drivers for massive cloud adoption in today’s healthcare IT world. I will start by staying that a CFO I am not and don’t think I will ever be.
My take on the TCO for cloud vs. on-premises infrastructure comes down to the overused, but simple saying, “it all depends”. When you research and find statistics around cloud cost savings the results are staggering. Some sources tout a 30%-50% potential cost savings from transitioning to cloud. I’m a bit more skeptical on those reports (and I say that working for a cloud company!).
Going back to my statement of it all depends, it really does. If you made a large capital purchase on a storage array 18 months ago and the useful life of that hardware is 36-60 months (even if that requires extended or 3rd party maintenance), you will not see a 50% cost saving by moving workloads to the cloud. That’s one of the reasons we see a lot of our customers starting their cloud journey with specific point services. Disaster Recovery, for example, is one use case that we’ve seen a cost savings of 25%-45% when leveraging managed IaaS within the public cloud.
The diagram below from AWS is, in my opinion, one of the more comprehensive overviews of the migration approach when considering a move to the cloud. In most healthcare organizations we have worked with, the 2 most common approaches we see is rehosting (aka “lift and shift”) and repurchasing (conversion to SaaS model). Rehosting is taking a mirror of the existing application infrastructure and migrating it to like hardware assets within a managed cloud or public cloud platform. Repurchasing is done usually during a business model shift at the application provider and allows customers to reclaim assets and offload some (if not all) software and hardware management to the provider.
Cloud readiness is the assessment phase of the process prior to or in parallel to the migration planning. This assessment focuses on the local technology and workflows of the environment and user community. This traditionally covers:
- Active Directory
- The Network
- Application Integration
- End Point Devices
- End-User Workflows
- Internet Connectivity
For more detail, check out my blog on cloud readiness last year that covers this process in a lot more detail, or take a look at this infographic.
The one thing I cannot stress enough is that it doesn’t matter if a problem existed prior to moving to the cloud environment, if it’s discovered in the process of migrating, users will be left with a negative impression of cloud services. Unhappy users mean the morning management huddle puts the IT Department in reactive mode, scrambling to correct problems that may have been there for years but were never exposed. Performing a full assessment of the key areas defined above will help avoid unforeseen issues.
If you are thinking about adopting cloud services, please let us know. We would love to assist in your journey. CloudWave currently offers complimentary remote and onsite workshops where we walk through each area in detail and start to define a plan based on your specific needs and workloads.
Mike Donahue is the Director of Sales Engineering at CloudWave. He can be reached at firstname.lastname@example.org.