CNWCCTechnologies

Cloud is a place.
The platform is the capability.

Build a cloud and platform strategy around the workloads, teams and operating model you actually have—not the destination a vendor is selling.

Discuss your platform direction→Explore our approach→
PLATFORM / OPERATING MODELFIG 01
WORKLOADFit before
footprint.
ENGINEERINGECONOMICSOWNERSHIPRISK
PLACE WITH INTENT↗
Strategy grounded in workload realityScroll to explore
01

The point of view

Moving workloads is not the same as moving forward.

Cloud creates value when it changes what teams can deliver—and what the organisation can reliably operate.

Relocation changes where software runs. It does not, by itself, improve automation, developer experience, reliability or ownership. Without a change in capability, the estate has moved but the operating model has not.

We treat the platform as an engineered product with users, service boundaries and a lifecycle. The right answer may be public cloud, private infrastructure, a hybrid estate—or a deliberate mix, workload by workload.

THE TEST

Can the organisation operate what it is about to build?

02

The platform map

One platform.
Six connected layers.

A platform is more than infrastructure. The developer experience only works when delivery controls, runtime, data and foundations are designed as one service—with clear responsibility at every layer.

CONCEPTUAL ARCHITECTURE01 — 06
VENDOR-NEUTRAL BY DESIGNCNWCC / CLOUD
01

Developer experience

Platform team

The interface teams use to discover, request and operate platform capabilities.

Paved paths · Templates · Documentation
02

Delivery controls

Platform team

The mechanisms that make safe change repeatable, observable and routine.

Pipelines · Policy · Environments
03

Runtime & services

Platform team

The shared services applications need across build, deployment and operation.

Runtime · Scheduling · Secrets
04

Data & integration

Shared

The stores and interfaces where application boundaries and risk become real.

Storage · Streaming · APIs
05

Cloud foundations

Platform team

Compute, network and storage, with provider choices kept behind deliberate seams.

Network · Compute · Storage
06

Security & observability

Shared

Cross-cutting controls and signals built into the platform, not bolted on later.

Identity · Telemetry · Cost
03

Make the trade-offs explicit

Strategy is a series
of decisions.

Cloud choices are connected. Placement affects cost; cost shapes the operating model; and the operating model determines what the platform team can sustain.

  1. 01

    Where should each workload run?

    Data gravity, latency, residency, control and operating cost—not a blanket cloud-first rule.

  2. 02

    What should be managed?

    Use managed services when they remove burden; retain control when requirements or economics justify it.

  3. 03

    How much platform can we own?

    Choose runtimes and Kubernetes scope to match the organisation’s actual operating capability.

  4. 04

    Where is portability worth the cost?

    Isolate genuine concentration risks; accept provider-specific choices where the trade is understood.

  5. 05

    What does the service really cost?

    Include engineering effort, support, resilience and ongoing operations—not infrastructure price alone.

  6. 06

    Who owns reliability and security?

    Make service boundaries, identity, data controls and failure expectations explicit before delivery.

04

Workload by workload

Choose the move
that fits the reason.

Not every workload needs a cloud migration. Assess the constraint first; then sequence the change by value, risk and dependency—not a migration-volume target.

“A migration percentage is not a technical decision.”
Cloud transformation
MODERNISATION PATTERNWHEN IT FITS
01

Retain

The workload is stable; the platform is not its constraint.

02

Retire

The capability is no longer needed or can be consolidated.

03

Rehost

A location or infrastructure dependency must change quickly.

04

Replatform

A managed runtime can remove burden without redesign.

05

Replace

A product or SaaS capability now fits better.

06

Refactor

Architecture blocks a material change in scale, speed or reliability.

The same workload can justify different patterns in different estates. Evidence and constraints determine the choice.

05

Designed to be operated

The platform is only real
when someone owns it.

01

A product teams choose to use

Treat the platform as an internal product: understand its users, make the safe path easy, and improve it through adoption and feedback.

02

A service someone can run

Name the owners, define support boundaries and lifecycle, and design for the people who will operate the platform after delivery.

03

An investment with visible trade-offs

Compare outcomes against cost, complexity and risk. Make constraints and exit choices explicit rather than accidental.

Related reading

Continue the conversation.

Explore related thinking on platform direction, engineering and operational resilience.

Architecture Briefing

The architecture advantage in digital transformation

Architecture reduces coordination cost — and transition architecture matters more than the target diagram.

→

Engineering Note

Building resilient systems in an unpredictable world

Design around failure modes, and observe the system that actually exists rather than the one in the diagram.

→

Platform

Beyond cloud migration: building future-ready platforms

Treat the platform as a product, and standardise the undifferentiated work that no longer earns custom engineering.

→

A considered next step

Bring us the platform decision that has to hold.

Start with the estate, the constraints and what the platform needs to support. A confidential conversation is enough to establish whether there is a useful engagement.

Discuss the challenge→How we work→
Cloud & platform strategySenior judgement. Technical depth.