Cloud Roadmapping
- Why is it important to have a cloud roadmap?
- What’s the best way to begin building a cloud roadmap?
- What points should a cloud roadmap include?
- Who should be included in the roadmap building process?
- How often should a cloud roadmap be revisited?
- What’s the biggest cloud roadmap planning mistake?
Why is it important to have a cloud roadmap?
To my understanding, a cloud roadmap is an essential requirement both for the whole cloud journey and for the business. For example, if we were talking about a trip to another country, you would want to plan as much as possible, wouldn’t you? You would need to understand the dates, the budget, logistics etc. if you didn’t – things might go wrong.
Cloud is not just a technology. It’s the backbone, a foundation. For some companies, it’s the foundation for an entire business — they will be building products in cloud, they will be running their solutions in the cloud, and everything that is in the cloud is subject to security, compliance, performance, costs. You would be thinking in terms of how you would be building your platform, solutions, and your business because you are in the cloud.
You need to think about:
- Where you want to be in 1, 3, 5 years
- What the potential roadblocks are
- What kind of people you need to on your team
What is the best way to begin building a cloud roadmap?
The best way is to look at where you are right now. Then answer the question: what is the conceptual state you want to be in as a company and as a technology unit in, say, 3-5 years?
Again – you might want to think conceptually rather than from an implementation standpoint. Don’t try to think in terms of lines of business for your data warehouse right away. Think conceptually: whether you want to be cloud-agnostic, what kind of technologies you want to leverage, what type of data you want to store, what kind of cultural or technology principles you want to follow in your company.
To return to my first point, cloud is a backbone and a platform for all of your technology and your entire business. Thus, you need to think about the impact that this conceptual end state might have on stakeholders and other players in your company.
Think about these two concepts: where you are and where you want to be, and then start thinking in terms of trying to build a sequence.
What is your first step going to be? How do you select the cloud platform? To understand the state of your cloud, you need to have an understanding of the type of automation and solutions you will have there. I’m not talking about metrics or application performance here. I’m talking about an overall holistic view over your cloud infrastructure and everything that you have there: security, budget, consumers, groups that use cloud, and opportunities that cloud gives you. Here a cloud is not only one provider, but it’s also a group of services. It’s a foundational kind of family of cloud, native services, and everything that is happening there.
What points to the cloud roadmap include?
Other than the initial and end state, think about ‘’what is the first project/line of business that will go there?” Think about designing your cloud, the roadmap itself, the architecture. Think about the moment when you will probably change your company. If you don’t do DevOps, you will be doing DevOps. If you don’t know what SRE is, you will have to adopt SRE because this is where the industry is going. This is what is working right now.
And to some degree or another, this cloud roadmap will affect many areas of your company. Change the culture. Adopt new technologies.
Then, from the roadmap standpoint, other than changing culture, adopting new tech, and educating your staff, you need to think about ways your engineers and developers can leverage clouds. Whether it’s an extension to their development environment, a sandbox where you run your non-production systems, your staging or QA, or a special lab where you run your ML notebooks and where you build ML models.
As a first step, you will have to architect your cloud, and you will have to align your stakeholders, security, compliance, DevOps and SRE, your product people, your engineering. People who do technology in your company will have to learn cloud and will have to be very comfortable with it, understand it and leverage it well.
At the same time, you’ll have to get buy-in from your business stakeholder. There will be people evaluating your cloud from a financial standpoint: how much money you spend, why, how we can control it, whether there are any opportunities for cost savings, etc. Try to think about these questions well ahead of time and not when things go sideways.
There will be a lot of work to do when actually moving to the cloud, transforming your stuff, migrating, re-architecting, re-engineering, re-platforming your solutions, or possibly even decommissioning some of them (because there’s a great chance you will find a better replacement in cloud that actually is a cloud-native solution, not something that you have to run on-premise at the time.)
The cloud journey does not only consist of these initial steps. It doesn’t end when you achieve your desired state because it’s a living thing. It’s like a fluid living thing. You always have to keep the momentum, pursue new technologies, understand trends, follow what is happening and continuously improve what you have in your software and your clouds. There always will be room for optimization.
Who should be included in the road rebuilding process?
I would say it should be people across different parts of your organization. It should be security, compliance, technologists, architects, and the head of engineering, for example. It should be your product people. It should be someone who will be closely watching your billing and the financial status of your cloud and how much money you spend, someone who will be receiving these checks because you need to understand the capacity and costs of your cloud. Not for this year, not for next year – but how much will it cost you 3-5 years in advance? Plan in advance.
Plus, there is always an operational aspect. These are your DevOps, and SRE (site reliability engineers). An operations department: people with monitors and charts are the first line of support. Include them in your planning as well, because they will have to change, adapt, and learn new things, and they have their own requirements. These are the people you need to include in your cloud roadmap planning.
How often should a cloud roadmap be revisited?
You need to be measuring your progress consistently. You need to understand where you are. Don’t do it too often, or you’ll lose sight of the bigger picture. You cannot do it once every ten years either, because it will not make any sense.
I would propose something like steering meetings, where you have a committee that oversees an overall cloud state and your development. The committee can regroup every other month and evaluates your progress.
Moreover, every 3-6 months, you might want to have another type of meeting, a sort of a bigger picture meeting, where the team can have a close look at your current state. Are you in line with what is happening in the industry? Are you executing your program as it was planned? What are the challenges?
You also need to align these meetings and that schedule with your business. What kind of constraints do you have? What are the industry specifics? Are there any milestones or events that are specific only to your company? You should align that schedule with your business.
You should strategically revisit your cloud, your roadmap, and your status every 6 to 9 months. At some point, you’ll most likely discover that you need to change the cloud provider, or you will realize that you need to change direction as a company. There should be several layers, several types of these steering meetings. And I think a combination of these different types of meetings will make the most sense.
What’s the biggest cloud roadmap planning mistake?
Here goes: You have a problem. You want to solve it. You have a champion, and you have a project sponsor. And you go in cloud with one line of business, and you want to fix one particular pain point. Or you have people who are familiar with only one cloud provider in your engineering team. Therefore, you do your planning based on their expertise and because they know this cloud very well. This bias from the engineers might affect your planning.
As a result, you will spend time, you will spend money, and you will not just spend time and money but you will lose it. And you will have something in a cloud that will be okay. It will work. But you might discover that it is not in line with what you want to achieve. It doesn’t work that well. It won’t work for you in five years when your priorities and mission are different. When someone is in a situation like this, it’s unfortunate to admit that the credibility of the team that planned the cloud journey suffers. It’s hard to start the discussion all over again if you have reputational damage. Because it takes time, it takes investment. If you don’t think holistically about the problem and only rely on some minimal assumptions or technology preferences – you will not achieve a good outcome.
Bottom line: don’t look at the problem too narrowly. It’s not a replacement. It’s not just a tool. It’s something much bigger.
By Yuri Gubin
