Organizations struggle with the transition to a Cloud. C-level managers are constantly hearing from colleagues about the “Cloud strategy”, the “Journey to the Cloud”, “the journey to a public cloud starts with legal advice”, etc. etc. Important to have these items well organized, but often the question arises how to accomplish that. Especially for the enterprises and corporates with a long (legacy IT) history struggle with this. Old infrastructure setups and highly customized monolithic applications are not helping a smooth transition to a public cloud for instance. Questions like “Do I really need these legacy workloads to transition to a public cloud?”, “Is that even possible?”, “Nice to have a short Time-to-Market within a public cloud, but what are the costs on the long-term for my 24*7 workloads?”, “Re-develop my core applications to make them cloud-native, where do I get the time, resources and budget to accomplish that? I don’t have good insights on my existing landscape, so where to start, where to end?”
All valid questions and there’s no clear answer applicable for every case. As the sales representatives always say “it depends” (I hate to say that, but it really depends). Everybody is understanding now that it must change, but how? Where to start?
Start with getting a clear understanding of your current IT architecture, the baseline architecture. Please don’t trust your manual filled in CMDB running there for years. I’ve never seen an accurate CMDB. You might have better luck if the CMDB is filled automatically, but even than applications and interfaces between them are usually not correctly defined. So, make sure logical diagrams and physical diagrams are created of the infrastructure.
Next step is to define the target architecture, the spot on the horizon. You can call it a reference architecture. It describes the architectural vision, provides guidelines, references to high level architecture services based on business drivers, business strategy and characteristics, without diving into the solution itself. Out of the reference architecture you can define one or more target architectures.
Now you have a baseline architecture and a reference architecture with guidelines how to get to the target architecture. Now it is time to get the feet back on the ground again. A nice reference architecture on paper doesn’t provide any actual value to your business. It’s a good start, but it is a means, not the goal. To get to your goal is not very easy and it takes time, resources and money. To make sure it is possible you need to define a roadmap with projects to accomplish the goal and you need to define a use-case to start the change with. Of most importance is the workload. Some workloads are suitable for a public cloud, some workloads are more suitable to stay in your own data center, of course fully software defined.
Based on the roadmap, the use-cases and the workloads you can initiate projects to start your transition to your target architecture. You have enough guidance, strategy and control to be confident to move forward. Make sure you stay agile, not only within your projects, but also within the architecture. Start small, allow yourself to fail a few times, learn from your mistakes and keep on going.
You now know where to start with the journey and how to get to your end goal. Resourcing might be still an issue. Start with a Cloud Architect and a Program manager. Make sure you as an executive provide enough support to the team. Make sure the Cloud Architect has an infrastructure background and make sure he has a counterpart on application level. No infrastructure Architect with that specific Cloud knowledge in your organization available? Please give us a call or mail us, we are here to help you.