POC KIT
Eine kopierbare Abnahmevorlage – kein versprochenes Ergebnis
Use this kit in the architecture review. Keep only the items that matter for the first PoC, attach owners and dates, and treat numbers as jointly agreed targets. Nothing here is a production metric, customer case, or SLA.
Copy or download the Markdown, then fill the placeholders with your topology. Public demos remain synthetic sample data.
Turn the demo into an executable acceptance plan
A PoC starts from your topology, representative workload, and measurable acceptance criteria. Agree the targets first, then prove them in your environment.
01
Inspect
Walk through the public sample workflows and identify the relevant product surface.
02
Scope
Map data boundaries, integrations, owners, security controls, and operating constraints.
03
Validate
Run representative workloads against agreed functional and operational targets.
04
Adopt
Define rollout, responsibility, support scope, and production readiness gates.
1. Acceptance goals
Write the buying question this PoC must answer. Goals should be observable in your environment.
- Business question to answer: [e.g. can we operate batch + stream release from one control plane?]
- Products in scope: [GIDO / GISO / GiRisk]
- Success looks like: [named workflow, quality check, or decision-replay path]
- Out of scope for this PoC: [HA, SSO, migration, unrelated engines]
2. Deployment boundary
Name where the control plane, data, and credentials will live for the evaluation.
- Environment: [customer Kubernetes / agreed private network / isolated evaluation cluster]
- Data rule: no production secrets or sensitive payloads in the first PoC
- Identity: [local accounts / mapped IdP / SSO as a later integration]
- Network: [who owns DNS, TLS, ingress, egress]
- Owners: [customer platform] / [Cloud GIDO delivery scope]
3. Representative tasks
Prove one path that mirrors the purchase decision. Prefer a real-shaped workload with non-sensitive data.
- GIDO: develop and inspect one batch or stream job, including instance status and diagnostics
- GISO: register or review one event contract and inspect quality exceptions by version
- GiRisk: inspect one decision ledger row and replay it as audit evidence
- Integration: connect one representative source or stream already in the customer stack
4. Acceptance evidence
Evidence is what both sides can reopen later. Screenshots, exports, and named owners beat slide claims.
- Console evidence: screenshots or exports from the agreed surfaces
- Operations evidence: who diagnosed a failure and which retry/replay path was used
- Security evidence: where credentials lived; what left the boundary (should be nothing sensitive)
- Gap list: HA, SSO, scale, and support items explicitly deferred
5. Go / no-go criteria
Decide from the evidence above. A no-go is a successful evaluation if the boundary is wrong.
- Go: representative task proved, ownership clear, residual risks listed with next scope
- Conditional go: function proved, but identity/network/backup items must be closed before production talk
- No-go: missing platform ownership, data cannot stay in-boundary, or the product surface does not match the need
- Next step if go: [scoped rollout / professional services / enterprise delivery discussion]