Summary
Clusters as a Service is the first offering modeled with the DC 3.0 capability roadmap pattern. It defines the consumer-facing OpenShift cluster service separately from the platform architecture narrative and the ABB/SBB catalog.
The offering is intentionally versioned. CLaaS 0.1.0 is the first modeled increment: requestable HCP-based OpenShift clusters with virtualized workers and explicit launch blockers.
Service Definition
CLaaS provides governed OpenShift cluster capacity for business teams and platform services. The DC 3.0 target state is a self-service, policy-governed, evidence-producing cluster service with standard profiles, automated lifecycle, integrated IAM, controlled endpoint publication, observability, backup, and clear support boundaries.
The offering definition answers what a consumer receives. Architecture notes and SBB notes explain how the platform provides it.
Roadmap Model
The machine-readable model lives in sidecar YAML next to this offering note:
RWS-ARCH/70-togaf/offerings/clusters-as-a-service-offering.model.yaml
That sidecar is the entry point for the CLaaS dependency chain. The portal and validators include it automatically by scanning RWS-ARCH/**/*.model.yaml.
Dependencies
CLaaS 0.1.0 currently depends on separate capability sidecars for:
- fleet HCP cluster provisioning
- cluster identity access
- cluster ingress publication
- cluster baseline GitOps
- cluster observability baseline
- cluster backup and restore baseline
The model derives offering availability from the latest required capability window, not from a separately maintained manual launch date.
Open Questions
- Which CLaaS
0.1.0dependencies can be scoped out for non-production-only consumers? - Should backup and restore evidence block initial availability or only production onboarding?
- Which exact service profiles belong in CLaaS
0.1.0versus later increments? - Which team owns the update cadence for each capability state and target window?