See it as a diagram
Start from one of the prompts below, edit it, and generate.
No account needed · Editable canvas, not a picture
Warum Data-Flow-Diagramme nuetzlich sind
Flows zeigen die stillen Brueche. Gemeinsame Sicht beschleunigt Handoffs.
Incident schneller
Den gebrochenen Hop sofort sehen.
Onboarding
In einer Seite sehen, wie Daten ankommen, sich aendern, genutzt werden.
Governance
PII markieren, Access-Kontrollen zeigen.
Exports
JSON + PNG/SVG nebeneinander.
Pflichtbausteine
Was bewegt sich, wie oft, unter wessen Kontrolle.
- Quellen mit Protokoll und Latenz.
- Pipelines mit Job-ID, Schedule, Retry.
- Storage raw/refined/curated mit Retention.
- Serve: BI, Reverse ETL, ML Features mit Owner.
- Pfeil-Labels: Protokoll, SLA, Schema-Version.
Layout-Muster fuer Lesbarkeit
Lanes reduzieren Kreuzungen, Domains halten den Graph klein.
3-Lane Standard
Sources -> Processing -> Serve.
Domain-Splits
Ein Diagramm pro Domain, unter 30 Knoten bleiben.
Kanten-Labels
Schedule und Protokoll auf die Pfeile.
Kurze Palette
3 Farben: Sources, Transforms, Consumer.
Update-Workflow
Generieren, pruefen, exportieren, publizieren.
Jedes Release
- • Prompt mit aktuellen Jobs/Tabellen.
- • Owner und SLA bestaetigen lassen.
- • SVG/PNG + JSON exportieren.
- • In Runbooks verlinken und datieren.
Prompts fuer Data Flows
Publish-Checklist
FAQ
Was gehoert in ein Flow-Diagramm?
Quellen, Ingest, Transformationen, Storage-Zonen, Consumer. Pfeile mit Protokoll und Schedule, Owner auf kritischen Flows.
Wie viel Detail?
Ein Macro-Flow fuer Stakeholder, ein technischer Flow mit Job-Namen und SLA fuer Ops.
Wie bleiben Pfeile lesbar?
Lanes nutzen (Sources, Ingest, Transform, Serve) und grosse Graphen nach Domain splitten.
Ist das Lineage?
Flow = Bewegung zwischen Systemen. Lineage = Detail auf Spaltenebene. Beides nutzen.