wiki: sync 2026-07-31 12:14 UTC — 27 file(s) updated

2026-07-31 12:14:52 +00:00
parent 542ec9ba74
commit 30a8733ed8
27 changed files with 858 additions and 21 deletions
@@ -0,0 +1,45 @@
+# #dpvp-phase-2-opportunity
+
+## Purpose
+Structure the DPVP platform Phase 2 commercial opportunity and contract.
+
+## Updated opportunity framing
+The expanded scope is a **DPVP productisation and hybrid-service programme**, not only a portal PoC.
+
+### Workstreams
+1. **Portal / Experience Plane** — guided organisation/project lifecycle, service catalogue, approvals, aggregated Jira demand, inventory, configuration governance, operator workbench and audit.
+2. **Control and Execution Plane** — service orders, durable workflows, policy, adapters, state, eventing, inventory/reconciliation, and gradual migration of application logic out of GitLab pipelines.
+3. **Hybrid onboarding** — reusable VSSA on-prem site pattern covering connectivity, identity, inventory, security, telemetry, support boundaries, and degraded operation.
+4. **Complex services** — governed compositions for on-prem backup, Kubernetes web applications, cloud DR, and hybrid observability.
+5. **Cross-cutting foundations** — canonical schemas/contracts, IAM/workload identity, policy as code, configuration/inventory graph, FinOps, SRE, audit, testing, lifecycle/versioning, support and DPVP's own backup/DR.
+
+## Key design decisions
+- Model multiple Jira requests as demand records feeding one governed **DPVP service order**; do not merely merge tickets.
+- Build a cloud inventory/read model with freshness timestamps and reconciliation; do not query every cloud API synchronously from portal pages.
+- Treat global configuration as hierarchical, versioned, impact-analysed, approved, wave-based and rollback-capable—not a global YAML editor.
+- Do not choose “webserver vs cloud functions” globally: short stateless handlers may be functions; long-running provisioning needs durable orchestration and workers.
+- Migrate GitLab pipeline logic through a strangler pattern, one capability at a time.
+- Complex services are blueprints/compositions over atomic capabilities, each with lifecycle, security, identity, network, cost, operations and acceptance contracts.
+
+## Recommended commercial packaging
+- WP0 programme mobilisation and target architecture;
+- WP1 Portal/control-plane core;
+- WP2 one backend migration slice;
+- optional WP3 one hybrid site/lab pilot;
+- optional WP4 one complex-service pilot;
+- separate WP5 productionisation and managed operations.
+
+## Current recommendation
+Name the opportunity **“DPVP Platform Productisation and Hybrid Service Enablement — Phase 2.”** Contract Portal + Control Plane + one backend migration slice as the core. Keep hybrid onboarding and one complex-service pilot as separately priced options pending architecture validation.
+
+## Artifacts
+- Executive summary limited strictly to RootAtSkic's stated topics: `/opt/data/dpvp-phase-2-executive-summary.md`
+- Initial narrow draft: `/opt/data/dpvp-phase-2-opportunity-contract-draft.md`
+- Expanded programme/contract draft: `/opt/data/dpvp-phase-2-program-opportunity-contract-v2.md`
+
+## Mandatory technical evidence
+AWS resource evaluations must reference:
+- `dpvp-storm/docs/machine-identity/configuration-alignment.md`
+- `dpvp-storm/docs/references/project-configuration.example.yaml`
+
+Keep OBSERVED / PROPOSED / UNKNOWN / RUNTIME evidence distinct.