Roadmap to Cloud Native: 5 Phases to Cloud Success

Publish date:

In previous parts of this blog series, we’ve covered the business benefits of cloud native development, key technological enablers, and the cultural aspect of cloud transformation. But how to make the transition? Let’s sum up and construct a guiding roadmap for organizations that strive to continue growth, cloud-first.

Overview of the cloud transformation

Typically, organizations start their journey to cloud by creating one or two solutions based on public cloud’s PaaS or serverless features – without a roadmap approach. At some point, it becomes clear that principles, compliance, security and the cloud operating model need to be agreed on in order to make a more holistic transition.

For simplicity, we’ll view the journey to cloud as five phases that guide the organization in planning for cloud native, making the transformation, and operating the cloud-first model successfully.

Phase 1: Identifying a business case for cloud native
Phase 2: Getting buy-in and preparing the organization
Phase 3: Selecting a cloud transformation partner
Phase 4: Going cloud native – the migration
Phase 5: Refining cloud processes and capabilities

cloud native blog illustration

Phase 1: Identifying a business case for cloud native

A shift to cloud may be triggered by a number of pressures from within or outside of the organization. Common sources of viable cloud projects are the automation of customer service and a demand for entirely new services. It’s important to not rule out possibilities too strictly.

Cloud native can provide the perfect solution for increasing internal process efficiency, but also for enhancing customer experiences. That is to say, that the underlying problem can be IT or business. However, in a cloud solution these go almost always hand-in-hand.

Interviews internally and with customers are a great way to discover practical problems where cloud native could be the solution. When you have identified a problem, make it concrete how cloud could solve it.

You can try to formulate it with a template such as this one:

“In [area of business], cloud could [hypothesized benefit(s)] for [target customers/people] by [expected improvements to processes/operations/business].”

For example:

In digital services development, cloud could increase responsiveness to market change for the entire organization by speeding up the development cycle and time-to-market with automation.

or

In building permitting process, cloud could decrease time to obtain a building permit for the builder by making the application more transparent and interactive.

or

In product development, cloud could increase product value for existing customers by helping them to utilize collected data as a value-adding service.

Phase 2: Getting buy-in and preparing the organization

A concrete description of the problem and cloud’s role in the solution help to sell the idea internally. On top of this, it’s important to understand what implications a move to the cloud may have on employees’ and even entire departments’ roles and responsibilities.

Keys to getting buy-in for a cloud project:

  • Explain how the tech can help drive the overall strategy forward
  • Make calculations and educate about cloud-related investment and costs
  • Build a link between the problem, business opportunity and IT
  • Reduce uncertainty by opening up what the shift means to people and processes
  • Address questions and fears openly if the impact will be radical
  • Present the solution in terms of immediate impact and future value

The Cloud Maturity Model is a useful tool for evaluating the organization’s cloud readiness. Low maturity means that a heavier focus on structural and cultural adjustments is likely to be needed. The critical realization for cloud project leads and the organizations is that cloud transformation is not only a question of technological change.

Phase 3: Selecting a cloud transformation partner

Your organization will have specific needs that weigh most in partner selection, and these are also dictated by the nature of the cloud project. In general, there are two types of approaches:

  1. When you are creating software-based products that use cloud, it is common to have cloud expertise in-house and choose a partner for clearly defined areas that would be risky or difficult to build with your own resources.
  2. When your goal is to make cloud technology an enabler of operations, an end-to-end service partner like Capgemini will be able to drive the transformation from planning to execution and to operating the new model.

The decision comes down to what your cloud capabilities are, what external capabilities complement those the most, and how deeply your organization is looking to embed cloud technology as part of the business. Partners with end-to-end capabilities are a safe bet for both type 1 and type 2 projects.

Read more about how Capgemini Finland can help you with cloud strategy, applications and infrastructure.

Phase 4: Going cloud native – the migration

You have a business case, buy-in, and a partner to help you get the job done. Now, what makes the difference between a smooth and successful transformation vs. a clumsy struggle against resistance? How do you know which cloud migration approach is right for you?

Cloud migration is often associated with legacy applications. Using the 6Rs of cloud migration tactics to guide the move of old applications to the cloud. But as one R, ‘Refactor’ suggests, old applications can also be re-architected to transform them into granular microservice-based applications taking advantage of cloud PaaS services.

Your business case should determine the most appropriate strategy. Besides that, review your existing application portfolio and look for opportunities to implement the 6Rs. Going back to partner selection, it’s noteworthy that end-to-end partners have entire teams that only specialize for example on application migration and modernization, enabling a painless transition.

Phase 5: Refining cloud processes and capabilities

After completing the initially planned cloud project, the long-term cloud transformation must keep moving forward. These considerations are the backbone of operating a continuously developing cloud application portfolio:

  • Use architecture governance to keep all development aligned and to maintain manageable technological diversity
  • Optimize cloud economics continuously: planned commitment to services brings cost savings
  • Maintain a full view to cloud infrastructure and applications in order to prioritize upcoming cloud projects and strategies

New applications are exciting, but not always the best option in terms of sustainable cloud development. If developing new apps becomes the default strategy, the organization will over time accrue ‘waste’ as irrelevant apps, while missing cost-efficient opportunities to develop on top of existing architecture.

Capgemini Finland serves enterprises in end-to-end cloud transformations and targeted modernizations with a powerful glocal touch. Contact our cloud experts to learn more:


Pasi Mäkinen
Delivery Architect Director

 

 

Simone Leggio
Simone Leggio
Director, Head of Cloud and Devops Practice,
Application Services at Capgemini Finland

Related Posts

cloud

How to manage the move to microservices in a mature way?

Date icon October 25, 2021

Microservices in the last few years have become a well-known concept and the modus operandi...

cloud

Deliver value faster with microservices, containers and serverless computing

Date icon September 9, 2021

Cloud holds tremendous potential, but customer value will fall short if the underlying...

cloud

Moving to A Cloud DevOps Culture – The CALMS Framework

Date icon September 8, 2021

Cloud native is more than technology. While DevOps enables cloud native, a culture change is...