“Our strategy is hybrid cloud” is a sentence that appears in a great many board packs and commits the organisation to nothing at all. It describes the current state of almost every enterprise. It is not a decision.
The decision is the placement rule: given a new workload, what determines where it runs? If nobody can answer that in two sentences, there is no strategy, there is an inventory.
What a real placement rule looks like
Something with criteria and thresholds, that a solution architect could apply without convening a committee:
New workloads default to the public cloud unless they meet one of: data residency requirement that our cloud region cannot satisfy; steady-state utilisation above 60% with a lifespan over three years; latency dependency on an on-premises system below 5ms; or a licensing model that makes cloud deployment materially more expensive. Those run on premises. Exceptions go to the architecture board with a written case.
That is a strategy. It can be wrong, and being wrong is useful because it can be corrected. “Hybrid” cannot be wrong, which is why it survives.
The criteria worth considering
Data residency and sovereignty. Where the law requires the data to be. Frequently the strongest constraint and the easiest to establish.
Utilisation shape. Bursty workloads suit consumption pricing. Steady-state ones frequently do not. This is the criterion with the most arithmetic behind it and the one most often skipped.
Latency coupling. A workload that chats constantly with an on-premises database belongs near it. Splitting a chatty pair across a WAN is a classic and expensive mistake.
Data gravity. Where the data already is, and what it costs to move or to keep moving. Egress is the line that arrives later and grows.
Licensing. Some vendor licensing is materially worse in one location. This can dominate everything else and is often discovered after the design.
Team capability. A workload nobody can operate in the chosen location is in the wrong location, whatever the spreadsheet says.
The failure mode of not having one
Workload placement is decided by whoever is loudest, or by which project had cloud budget, or by what the last consultant recommended. Over five years this produces an estate with no pattern: applications split across boundaries for historical reasons, data moving back and forth, and a network bill nobody can explain.
The cost is not primarily money. It is that nobody can reason about the estate, so every change requires rediscovering how things got this way.
The version I would write
Start with the criteria that are not negotiable: residency, latency coupling, licensing. Those eliminate options. Then apply the economic test to what remains, using the utilisation shape. Then sanity check against team capability.
Write it on one page. Review it annually, because cloud pricing and your own utilisation both change. Publish it so that project teams can apply it themselves instead of asking.
One page, applied consistently, is worth more than a large strategy document that nobody can operationalise. The test of whether you have one is simple: hand a new workload to two architects separately and see whether they reach the same answer.