Technical Software Lead
Steps to effectively take advantage of cloud computing on a small scale
Everyone acknowledges that embracing technology in a fast changing world is necessary to harness all of its power. At the same time, cloud computing is the most effective way to make an enterprise agile. Most analysts also agree that “data is the new oil”. Yet for many managers and entrepreneurs, it can be daunting to know how and where to start. One of the misconceptions is that embracing the cloud is an “all in” proposition.
So how does a small to medium sized enterprise embrace technology? Does one need AI models to train fancy algorithms? Does it even make sense for a company with just a couple of hundred clients? Moving to the cloud requires a shift in the focus of IT organization.
Steps to adoption:
Identify the business case: The first step to any business transformation journey is to identify what the goal is. Is it to increase revenue? To modernize the organization’s IT infrastructure? To reduce the cost of compliance or is it to reduce risk exposure? After the goal is identified, determine what the time horizon is. Having answers to these questions will make the transition less nerve racking because one knows what the end state is.
– If the goal is to reduce the cost of compliance, what is the current cost? Is it measured in head-count, dollars or some other metric? Defining the current cost will aid in deciding what range the cost of implementation should be. Cost can be seen as the difference between current cost and anticipated cost. For example, assuming the cost can be measured in dollars, if the current cost is $1000 and the future cost (5 years from now) is $2500, that means the cost “no action”, given a 5 year time horizon, is at least $1500. This is the cost the modernization project should attempt to allay. The same can be calculated and expressed in terms of agility to enter a new market or introduce a new product. For example, how long does it take the company to introduce a new product today compared to 5 years from now?
– If the goal is to reduce risk exposure, what is the “definition of done”? Is there an “acceptable” level of risk? What is the cost of non-compliance? For example, for some systems, cost can be expressed in terms of reputational damage, exposure to litigation, or other non-financial cost. Knowing this is handy when trying to persuade other executives about the importance of this initiative.
Acknowledge and embrace change: This involves changing mindsets and the business processes that arise from legacy mindsets. Many leaders are used to stability and predictability in their systems and “cloud computing” can mean a new way of doing things, which can produce uncertainty. An unplanned journey is anxiety inducing, because knowing what the end state is (and what the desired outcome/benefit of that end state is) is crucial to embracing change.
– Understand the short term impact (e.g. cost of data transformation) and the long term impact (e.g. increased security and agility)
Have a plan: Most cloud computing vendors break down the cloud migration journey into 5 steps: Plan, Review, Migrate, Measure & Optimize, Repeat. The first pillar (planning) is very crucial to a successful cloud transition. Having a road map, according to EY, is crucial to getting buy-in for the vision it represents. A plan should encompass the following:
– Migration plan: What applications are going to be migrated first? For example, migrating low business impact applications can give one a sense of how the transition can be managed and expose critical steps that will need to be accounted for, such as MFA and enterprise-wide SSO authentication within the enterprise
– Phased approach: It is also important to split the migration into at least 3 different phases for example: the planning phase, the testing phase, and the optimization phase. During these phases, one can articulate a vision and get buy-in, transition a few applications to demonstrate a proof of concept (or green field a few cloud-first applications) and finally find pain points to optimize so that lessons learned when onboarding the first few applications can be applied to the next iteration.
– Define, measure and track: It is important at this stage to define the requirements of the migration. What are the desired outcomes and how are they going to be measured? For example, how will data migration be measured? If it includes the cost of data transfer and storage, will it be all at once or gradual? The cost of storing data may not be known but the method of measuring the “definition of success” should be known and tracked quarter by quarter so the direction is clear.
Choose a cloud transformation strategy: Transforming an organization’s processes, applications and data into the cloud has different trade offs for different sectors. For example, public clouds scale very easily and are comparatively more affordable than private clouds. However private clouds do give a company more control over its data and data retention policies. One should only adopt hybrid clouds if the need for agility to switch between cloud computing strategies is important. One should also note that having a public cloud does not mean that the data is exposed to the public. A good security architecture review should explicitly itemize what APIs are exposed to the cloud and what the authentication method is for each API.
Choose a Cloud Service Provider (CSP): Once you have a plan, choosing a vendor is less daunting because you know what you are trying to achieve. Is your strategy to move to Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS), for some or all of the trial run applications. Azure, AWS, GCP, Pivotal Cloud Foundry, Alibaba, and others all offer slightly different strengths and the value proposition they present will vary based on the size of the organization and the existing strategy of the company. For some companies with existing organizations already established, a hybrid cloud approach may work whereas for others there may be a mandate from tech leadership for all managers to prefer a particular vendor, especially if there is a CIO-level position already established to drive the transformation. The company has to decide what type of cloud (private, public, multi and hybrid cloud) and must be careful because choosing a vendor requires careful analysis of trade off between the features vendors offer and avoiding vendor lock-in by using technologies such as docker and kubernetes.
Flip the switch: When the organization is ready, business not IT must be the driver. Business must define the objectives and must be partners in the cloud journey. Business goals such as “where do we need to be to be able to speed up the release of new features”, “what markets do we want to enter/exit” or “how can we be ready for shopping season’s trends?” are important goals that business should define. That way, businesses have “skin in the game” and their metrics are equally tied to the success of the cloud transformation. Ship something to production that is important but not critical first.
It is evident that power computing on a small scale is possible. The organization has to consider transitioning away from a help-desk mindset into a self-service mindset of provisioning of applications, compute, storage and other IT resources. While some may be hesitant initially, many workers embrace it as they can see the value in not having to wait for human interaction in a ticket-based organization. It is important to keep security front and center as often after migration, data breaches are the most embarrassing because security was not a primary consideration during the planning. The existing security posture needs to be strengthened and existing security violations and vulnerabilities should be enumerated. Start with security and compliance first while plotting the path to getting the MVP to production. Once you have an MVP, you can monitor cloud infrastructure to find and harden your posture.
Judes is an independent consultant in the Ann Arbor, MI area that currently works at Capital One Financial. He has previously worked at Ford Motor Company in Dearborn, MI as an software engineer.