Cloud Transformation – how executable is your roadmap?

Your Board has just approved the cloud transformation strategy – congratulations! The next big hurdle is to build an executable roadmap that takes into account the full context of your company: the current state, the desired target state, plus the constraints, opportunities, and resources at your disposal. There are four lenses which, if applied iteratively, will help refine and validate the roadmap.

Business Lens

All transformations should first be a business transformation, and a cloud transformation is no exception – while this seems obvious, transformations can sometimes end up being technology-led especially where the business is not traditionally digital. Approaching it from a business perspective helps define the scope and prioritise what gets included.

First, map each of the transformation projects to key company focus areas. Articulate how they contribute to delivering specific company goals, such as growing through leasing products vs sales, higher margins from existing customer base, etc. One good way to quantify the potential contribution is to pick a relevant business metric, baseline it and measure it monthly thereafter. It also helps to classify projects into either ‘business initiative’ or ‘technology initiative’ for each budget cycle and look at the proportion being invested in each bucket – over time, more and more budget should be directed towards business initiatives.

The organisation’s transformation velocity should also increase over time; as more transformation projects are developed and deployed, new projects will get delivered faster. Some indicators of velocity are self-service capabilities for business users, modularity, use of No Code/Low Code platforms and the building and adoption of enterprise platforms. Include these in your strategy to ensure that the roadmap positions you towards these goals early.

Macro-Environment Lens

Business leaders should describe the new growth opportunities being pursued, say in a white paper that includes enough information to derive new patterns that the transformed architecture can enable, such as real time workflows being added due to IoT devices or customer interactions, big data requirements stemming from inclusion of data science in business workflows, or external data sharing with customers.

Next, consider how hybrid your cloud approach will be. The utopian answer is Single Cloud but most of us are already faced with a reality of Multi-Cloud with some percentage remaining on-prem for the foreseeable future. The basic set of services that each of the three hyperscalers (AWS, Azure, Google Cloud) are providing is becoming standardised and, increasingly, niche platforms are cloud-agnostic e.g., data platforms like Snowflake or Databricks. So, if feasible, pick one hyperscaler as your enterprise platform, and for the teams that are using a different one, put some governance around them so that their services may be easier to port to the enterprise platform down the road.

Some companies are picking two environments – managing known capacity in private cloud and public cloud for scale; or one primary public cloud and a secondary public cloud for business continuity; or a primary one for security and applications and a secondary one for data.

“Under the Hood” Lens

Historically, the application and data platform worlds have been vastly different. Operational systems help a business function and hence must operate at speed, whereas the data platform had the luxury of producing information and insights at a different cadence. However, that is changing rapidly as modern data platforms are taking advantage of automation advances through DevOps, DataOps and MLOps. They can now analyse operational workflows and deliver insights and recommendations to inform decision-making fast.

If any of your business use cases require going between the application and data platform worlds, examine carefully how your roadmap addresses them, especially if any near-real time workflows are involved. If business model disruptions are forcing you to define your core business competencies, it may make sense to take a step back and invest in redefining your business capability architecture and value stream maps.

Furthermore, there can be several factors that push transformation roadmaps towards ‘lift & shift’ – squeezed timelines and budgets to time-box the transformation, low appetite for change management, need to reduce risk from change validation, technology obsolescence milestones or hard deadlines to avoid prohibitive legacy landscape renewal costs. A cloud migration is a major undertaking, however implementing a lift & shift rarely delivers on the promises of transformation. A common approach is to plan the transformation in phases where the first phase is largely lift & shift, while deferring major reimplementation to subsequent phases.

Complexity & Cost Lens

After the first three lenses have been applied, the project team should take a step back and assess the roadmap, with the dual purpose of reducing complexity while balancing transformation and optimising operations costs.

Organisations may choose to retain complexity to keep costs down if, for instance, they want to keep newer on-prem infrastructure until the investment has been recouped, keep multiple copies of data through operational systems and/or ETL tools to avoid rewriting business logic, or continue to manage data centres as it can be more efficient and cheaper in certain cases.

The cloud is a significant landmark in the computer technology journey. In addition to providing all the well-documented tangible benefits, it reduces the traditional complexity of the estate that the enterprise IT team must manage, allowing it to focus more on the technology layers closer to business impact. The above lenses can help leaders identify and focus on their core business reasons for the cloud transformation.