On this page
Summary
This note introduces the architecture roadmap graph for DC 3.0. It defines how service offerings, capabilities, dependency constraints, and target windows are modeled so the vault can answer practical roadmap questions.
The roadmap is not a replacement for target architecture, ADRs, or workpackages. It is the architecture layer that connects them into an incremental journey from early value to DC 3.0 target-state capability.
Applicable Principles
- Self-Service Platform - offerings are described as consumable platform products.
- Automation First - capability state and dependencies must be machine-readable and validated.
- Observability by Default - readiness is proven through evidence, not assertion.
- Reliability and Resilience - production and target-state promotion require explicit gates.
Architecture
Why This Exists
The DC 3.0 vault currently describes a target state and several urgent delivery realities. That is not enough for planning because business value arrives in increments. Each offering needs a visible path from early validation to MVP, soft launch, production, and DC 3.0 target state.
The capability graph provides that path by making the following questions answerable:
- Which offering versions exist and what do they contain?
- Which capabilities are required before an offering version can launch?
- Which dependency blocks launch, production, scale, or target-state completion?
- Which dependency is the latest blocker for initial availability?
Model Layers
| Layer | Purpose | Source |
|---|---|---|
| Architecture narrative | Human explanation, target-state intent, trade-offs | Markdown architecture notes |
| Architecture model | Offering versions, capabilities, dependencies, and target windows | .model.yaml sidecars |
| Generated graph | Normalized JSON for validation, visualization, and agentic use | Build output under apps/portal/*/capability-model.json |
| Portal views | Roadmap, readiness, blocker, and exception views | Astro portal |
Core Object Types
| Object | Meaning |
|---|---|
| Offering | A business-facing platform service, such as Clusters as a Service. |
| Offering version | A named increment of an offering, such as CLaaS 0.1.0. |
| Capability version | A specific feature or outcome needed by another model item. |
| Exception | A temporary non-target lane with explicit deviation and exit criteria. |
Availability States
| State | Meaning |
|---|---|
not_started | Identified, but no delivery or implementation work has started. |
planned | Accepted into planning, but not materially underway. |
in_progress | Implementation, configuration, or design work is underway. |
validating | Implemented enough for controlled validation or evidence collection. |
available | Available for the dependency use described by this version. |
blocked | Cannot progress until a blocker is removed. |
paused | Deliberately stopped or deferred. |
retired | No longer valid for active dependency use. |
State is about availability for dependency use, not strategic maturity.
Dependency Semantics
Dependencies are version-level. A service offering version does not merely depend on a product name; it depends on a capability version that provides a named feature.
Dependency attributes:
| Attribute | Meaning |
|---|---|
ref | Offering, capability, SBB, or exception id. |
version_constraint | Semver range for acceptable dependency versions. |
capability | Specific provided capability needed from the dependency. |
blocks | Whether the dependency blocks availability, production, scale, target, or none. |
lag | Optional quarter lag after the dependency becomes available. |
reason | Why the requirement exists. |
Version constraints use comparable major.minor.patch values. The resolver selects the highest satisfying version by default.
Exception Lane Rules
Exception lanes are visible in the graph but should not satisfy normal target-state dependencies unless explicitly allowed by a later architecture decision.
Each exception must define:
- what business pressure justifies it
- which target-state capabilities it borrows from
- which target-state capabilities it deviates from
- what exit criteria retire or absorb the exception
The DC-A OpenShift AI lane is modeled this way to prevent tactical production work from polluting the normal DC 3.0 roadmap.
Sidecar Model
The machine-readable model lives in .model.yaml sidecars documented by architecture-model-sidecars. Service offering sidecars live in RWS-ARCH/70-togaf/offerings/ and declare which capability versions each offering version needs. Capability sidecars may live next to the SBB notes that explain their implementation.
Decisions
- Architecture roadmaps are modeled as first-class architecture content, not as workpackage-only planning data.
- Capability dependencies use explicit semver constraints and named provided capabilities instead of relying on product names alone.
- Exception lanes remain separate graph nodes and must have exit criteria.
- The first worked offering roadmap is Clusters as a Service Offering.
Open Questions
- Which governance body approves state changes from
validatingtoavailable? - Which capability chains need more precise target windows before CLaaS can be treated as implementation-ready?