Orchestration

Orchestration ist die zentrale Steuerung, die einzelne Aufgaben, Programme oder Dienste zu einem geordneten Gesamtablauf verbindet. Sie legt fest, was in welcher Reihenfolge läuft, was wovon abhängt, was wiederholt wird, wenn ein Schritt fehlschlägt, und wer bei Fehlern benachrichtigt wird. Diese Logik lebt auf einer eigenen Ebene, statt in jedem Baustein selbst zu stecken. In IT- und Datenlandschaften begegnet der Begriff in vier klar unterscheidbaren Ausprägungen: Steuerung von Daten-Strecken (Data Pipeline Orchestration), von Container-Verbünden (Container Orchestration), von KI-Agenten (Agent Orchestration) und von Fachprozessen mit menschlichen Freigaben (Workflow Automation).

Was ist Orchestration?

Orchestration ist eine Metapher aus dem Konzertsaal: Ein Dirigent koordiniert die einzelnen Instrumente zu einem stimmigen Gesamtklang, ohne selbst zu spielen. Übertragen auf IT-Systeme meint der Begriff eine übergeordnete Steuerungs-Ebene, die Reihenfolge, Zeitpunkt und Bedingungen für die Ausführung einzelner Bausteine festlegt, ohne deren interne Logik zu übernehmen. Der ausführende Baustein (etwa ein Datenverarbeitungs-Programm oder ein Container) bleibt bei sich; die Steuerung (der Orchestrator) ruft ihn auf, wartet auf das Ergebnis und leitet daraus den nächsten Schritt ab.

Etabliert hat sich der Begriff in den 2000er Jahren im Umfeld serviceorientierter Architekturen (SOA), insbesondere durch den OASIS-Standard BPEL (Business Process Execution Language, 2007), der die zentrale Koordination von Web-Services gegenüber der dezentralen Choreografie abgrenzte. Später übernahmen Container-Plattformen (Kubernetes ab 2014), Datenwerkzeuge (Apache Airflow ab 2014) und schließlich Agenten-Frameworks (LangGraph, CrewAI ab 2023/2024) denselben Begriff für sehr unterschiedliche Anwendungsfälle.

Der gemeinsame Grund für die Existenz des Begriffs: Ab einer bestimmten Systemgröße lässt sich der Ablauf nicht mehr in jedem Einzelbaustein hart kodieren. Reihenfolge, Retries, Timeouts, parallele Ausführung, Zustandsübergänge und Fehlerkompensation gehören auf eine eigene Ebene, damit sie versionierbar, beobachtbar und ohne Eingriff in die einzelnen Bausteine änderbar bleiben.

Über alle Ausprägungen hinweg wiederholen sich fünf Bausteine:

• Ablaufbeschreibung. Eine deklarative oder imperative Definition des Ablaufs (als gerichteter azyklischer Graph, als Pipeline, als Agenten-Graph oder als Prozessmodell).
• Scheduler oder Trigger. Der Auslöser eines Laufs: eine Zeit (nächtlich, stündlich), ein Event (Datei angekommen, Nachricht in einer Queue), eine externe API oder eine manuelle Freigabe.
• Executor. Die Komponente, die die einzelnen Schritte tatsächlich ausführt, häufig auf verteilter Infrastruktur (Worker, Pod, Serverless-Funktion).
• Zustands- und Metadatenspeicher. Historie der Läufe, aktueller Zustand jedes Schritts, Retry-Zähler und Ergebnisse, in der Regel in einer Datenbank oder einem Key-Value-Store.
• Beobachtungs- und Wiederherstellungs-Ebene. Logs, Traces, Metriken, Retry-Regeln, Rollback-Mechanismen, Kompensations-Schritte.

Vier Ausprägungen prägen die aktuelle Werkzeug-Landschaft:

• Data Pipeline Orchestration koordiniert Datenverarbeitungs-Schritte über Systeme hinweg (Ingest, Transformation, Laden, Bereitstellen). Verbreitete Werkzeuge sind [Apache Airflow](https://airflow.apache.org/), Databricks Lakeflow Jobs, Dagster und Prefect.
• Container Orchestration koordiniert Deployment, Skalierung, Netzwerk und Lifecycle von Containern über einen Cluster hinweg. Der De-facto-Standard ist [Kubernetes](https://kubernetes.io/); daneben stehen Nomad und Docker Swarm.
• Agent Orchestration koordiniert die Zusammenarbeit mehrerer KI-Agenten (Plan-Phase, Topologie, Routing, geteilter Zustand). Typische Frameworks sind LangGraph, CrewAI, das Microsoft Agent Framework und das OpenAI Agents SDK.
• Workflow Automation koordiniert menschliche und System-Schritte in einem Fachprozess mit Freigaben, Rollen und Formularen. Verbreitete Werkzeuge sind [Camunda](https://camunda.com/), n8n, Zapier und Power Automate.

Ein weiterer wichtiger Unterschied verläuft entlang der Achse imperativ vs. deklarativ. Klassische Orchestrierung ist imperativ: Die Reihenfolge steht als Code oder Konfiguration explizit fest, etwa als Python-DAG in Airflow. Deklarative Ansätze wie Databricks Lakeflow Declarative Pipelines oder Kubernetes-Manifeste beschreiben nur den Ziel-Zustand (welche Tabellen sollen existieren, welche Container sollen laufen) und überlassen der Runtime die Ableitung der konkreten Schritte.

Abgrenzung zu Automation, Choreografie und Scheduler

Der Begriff wird für unterschiedlich mächtige und unterschiedlich fokussierte Werkzeuge verwendet. Die folgenden Abgrenzungen klären typische Verwechslungen.

Zwei Abgrenzungen verdienen einen genaueren Blick, weil sie in der Praxis am häufigsten vermischt werden.

Zwischen Orchestration und ETL/ELT-Engine verläuft eine klare Trennlinie. Eine Engine wie Spark oder dbt führt die eigentliche Datenverarbeitung aus, entscheidet aber nicht über deren Reihenfolge, Timing und Abhängigkeiten. Der Orchestrator ruft die Engine auf, wartet auf das Ergebnis und leitet daraus den nächsten Schritt ab. In einer typischen Data-Plattform sitzen Airflow oder Lakeflow Jobs auf der Steuerungs-Ebene, während Spark, dbt und ein SQL-Warehouse auf der Ausführungs-Ebene arbeiten.

Zwischen Orchestration und Choreografie verläuft ein architektonischer Kompromiss. Orchestration zentralisiert die Steuerung: ein Ort, an dem die Reihenfolge festliegt, ein Ort für Fehlerbehandlung, ein Ort für die Beobachtung des Gesamtablaufs. Choreografie verteilt die Steuerung auf die einzelnen Dienste, die auf Ereignisse anderer Dienste reagieren. Der Preis der Zentralisierung ist ein Single Point of Failure und ein Skalierungs-Engpass; der Preis der Choreografie ist die schwere Nachvollziehbarkeit des Gesamtablaufs. In größeren Systemen kombinieren viele Architekturen beide Muster (etwa das Saga-Pattern für lange Transaktionen).

Beispiel: nächtliche Analytics-Strecke mit klarer Trennung

Eine typische Data-Plattform trennt Ausführung und Steuerung. Eine nächtliche Analytics-Strecke lädt Rohdaten aus SAP und Salesforce in ein Bronze-Delta-Layer, transformiert sie in Silber und Gold, veröffentlicht ein Dashboard-Modell und benachrichtigt bei Fehlern einen Slack-Kanal.

Die Rollen sind klar verteilt:

• Orchestrator (Apache Airflow oder Databricks Lakeflow Jobs) definiert die Reihenfolge, die Abhängigkeiten und die Retry-Regeln. Er selbst verarbeitet keine Zeile Daten und ruft nur die jeweiligen Systeme auf.
• Ausführungs-Engines (Spark, dbt, ein SQL-Warehouse) übernehmen die Transformationen. Sie kennen weder den Kontext des Gesamtablaufs noch die anderen Schritte.
• Container-Orchestrator (Kubernetes) betreibt darunter die Worker-Pods des Airflow-Executors, kümmert sich um deren Skalierung und Ausfallsicherheit. Er koordiniert also die Laufzeit-Objekte, nicht die inhaltliche Pipeline.
• Metadaten- und Zustandsspeicher hält Historie, Zwischenergebnisse und Retry-Zähler.

Parallel dazu läuft im Kundenservice-Bereich ein System aus mehreren KI-Agenten (Klassifikator, Sachbearbeiter, Eskalation), das LangGraph orchestriert. Auch hier greift der Begriff Orchestration, aber die Bausteine unterscheiden sich: eine Plan-Phase, eine Topologie zwischen den Agenten, ein Routing-Layer und ein geteiltes State-Modell mit LLM-Nicht-Determinismus. Wo eine Datenpipeline auf einen deterministischen DAG zurückgreift, muss die Agenten-Orchestrierung damit umgehen, dass ein Agent die Schrittanzahl selbst festlegt.

Beide Systeme heißen „Orchestration" und tragen doch je eigene Werkzeuge, Bausteine und Fehlerbilder, mit entsprechend getrennter Verantwortung im Betrieb.