The Investment That Arrives Before the Organisation Is Ready
Enterprise cloud programmes follow a recognisable pattern of investment sequencing. Platform selection happens first: which cloud providers, which management tooling, which security platform, which observability stack. Contracts are signed, architectures are drawn, and the technology deployment begins. Then, somewhere between months six and eighteen, the programme encounters the resistance it did not plan for.
The engineering teams the programme assumed would adopt the new platform have not changed how they work. The governance processes required to manage the cloud environment at scale have not been designed. The skills required to operate the technology confidently have not been developed. The financial accountability model required for FinOps to work has not been established. The technology is in place. The operating model it was designed to support is not.
This is the failure mode that the Cloud Operating Model framework was built to prevent. The central argument of the framework, repeated across this six-part series, is that technology is the third decision in cloud programme design, not the first. The sequence that delivers sustainable outcomes runs in the opposite direction from the sequence most programmes follow: strategy first, then operating model, then technology selection to support the operating model that has been designed.
The Strategic Cascade That Should Precede Technology Selection
The strategic cascade that the Cloud Operating Model framework describes is not complicated in concept, but it is consistently underinvested in practice.
The first decision is business strategy: what outcomes does the cloud programme need to deliver, measured in business terms? This is not a technology question. It is a question about competitive positioning, operational efficiency, risk management, regulatory compliance, or time-to-market improvement, depending on the organisation and its context. The answer to this question defines the success criteria for everything that follows. It also defines what the technology selection must enable and what it is not required to do.
The second decision is operating model design: what changes to people, process, and governance are required to deliver the business outcomes defined in the first step? This is the work of the Cloud Operating Model series: the three competencies (foundation, run, and security), the consumer-provider service model, the CCoE structure, the FinOps accountability framework, and the skills and talent model. Each of these requires organisational investment before technology deployment makes them operational. The organisation that designs its operating model before selecting technology can select the technology that supports the operating model. The organisation that selects technology first must retrofit the operating model to the technology it has already committed to.
The third decision is technology selection: which platforms, tools, and services will operationalise the operating model that has been designed to deliver the business strategy? When the operating model design is complete, technology selection becomes significantly more tractable. The requirements are specific rather than generic. The evaluation criteria reflect operational needs rather than feature comparisons. The vendors being evaluated can be assessed against the actual operating model they need to support.
What Technology Evaluation Looks Like When the Operating Model Comes First
Technology evaluation without an operating model design produces vendor beauty contests. Every platform performs well in a demo. The criteria for selecting between them end up being a combination of analyst positioning, peer reference, and negotiated commercial terms, none of which predict operational fit.
Technology evaluation with an operating model design produces specific, answerable questions. If the operating model requires a consumer-provider service model with self-service provisioning, the technology must support service catalogue integration and infrastructure-as-code workflows with appropriate guardrails. Which platforms do this well, at the scale required, with the integration capability the organisation’s existing tooling demands?
If the operating model requires FinOps accountability at the team level, the technology must provide cost attribution at the granularity of individual teams and workloads, with real-time visibility rather than end-of-month reporting. Which cost management platforms meet this requirement, and at what operational overhead?
If the operating model requires a security posture visible at the board level, the technology must provide aggregated compliance and risk metrics across a multi-cloud, multi-account estate. Which security platforms provide this without requiring a dedicated analyst to generate the reporting?
These are questions that have specific answers. They allow technology evaluation to become a structured process rather than a preference exercise, and they allow the organisation to select technology it will actually use rather than technology that appeared most compelling in a controlled evaluation.
The True Cost of Getting the Sequence Wrong
The cost of investing in technology before operating model design is not obvious at the point of investment. It becomes apparent over the eighteen to thirty-six months that follow.
The most direct cost is rework. Technology selected without operating model context is frequently replaced or supplemented when the operating model requirements become clear. The cloud management platform selected in year one without FinOps requirements specified is often joined by a specialist FinOps tool in year two when the cost attribution gap becomes urgent. The security tooling selected for its features is often consolidated or replaced when the operating model requires unified posture rather than point-tool coverage. The rework cost is not just the investment in the new tooling. It is the migration cost, the operational disruption, and the engineering time redirected from delivery to platform change.
The second cost is adoption drag. Technology deployed before the operating model is ready cannot be adopted at the pace the programme plan assumes, because the processes and skills required to use it have not been built. The platform team that deploys a cloud management platform before the governance framework is designed finds the platform unused. The security team that deploys a CSPM tool before ownership accountability is established finds the findings unaddressed. The cost is not the tool. It is the lost time and the eroding confidence in the programme.
The third cost is the operating model constraint. Technology that is deployed before the operating model is designed constrains the operating model that can subsequently be designed. The organisation shapes itself around the technology it has, rather than the technology shaping itself to the operating model the organisation needs. This constraint is difficult to quantify, but it is consistently experienced as the sense that the cloud programme is optimised for the tools rather than for the business.
Bringing the Framework Together
This sixth article closes the Cloud Operating Model series. Across the six pieces, the framework has made a consistent argument: cloud programmes succeed or fail in proportion to the investment made in operating model design before technology deployment.
The cloud operating model is not a technology framework. It is an organisational framework that happens to be implemented through technology. The three competencies provide the capability structure. The consumer-provider model provides the service delivery structure. The CCoE provides the governance structure. FinOps provides the financial accountability structure. The skills and talent investment provides the human capital foundation. And the technology layer, selected and deployed after these structures are in place, operationalises the operating model rather than defining it.
The enterprises that will look back on their 2022 cloud investments well are the ones that resisted the pull of technology-first investment and made the harder, less immediately visible investment in operating model design. The competitive advantage that results is not the technology they selected. Every competitor can buy the same technology. The advantage is the organisation they built around it, which cannot be purchased and takes years to replicate.
The conversation with your cloud platform vendor starts now. The conversation with your board about operating model investment should have started six months ago.