Kategorie: Erklärer

Als Engineering Leader siehst du Dutzende Metriken – Deployment-Frequenz, Lead Time, Change Failure Rate, MTTR – und hast trotzdem kein klares Bild. Die Antwort liegt nicht in noch mehr Metriken, sondern in einem Framework, das die wichtigsten Aspekte zusammenfasst. Das DX Core 4 wurde von Abi Noda, Laura Tacho, Dr. Margaret-Anne Storey und Dr. Michaela Greiler entwickelt – den Machern der DevEx- und SPACE-Frameworks. Sie wollten DORA, SPACE und DevEx in ein praktisches Modell integrieren. Das Ergebnis sind vier Dimensionen: Speed, Effectiveness, Quality und Business Impact. Alle vier Dimensionen müssen im Gleichgewicht sein. Wer nur auf Speed setzt, riskiert Qualitätseinbußen. Zu viel Fokus auf Qualität kann Marktchancen kosten. Das DX Core 4 hilft, alle vier Dimensionen gleichzeitig zu berücksichtigen.

Speed umfasst klassische DORA-Metriken wie Deployment-Frequenz und Lead Time for Changes. Effectiveness misst, wie gut Entwickler ihre Zeit nutzen – etwa den Anteil der Zeit für Feature-Entwicklung statt für Unterbrechungen. Quality bewertet die Stabilität der Software, zum Beispiel durch Change Failure Rate. Business Impact misst den Wert der Features für das Geschäft. Diese vier Dimensionen sind bewusst gegenläufig gewählt: Eine Verbesserung in einer Dimension darf nicht zulasten einer anderen gehen.

Das Framework ist mehrdimensional. Veränderungen in einer Dimension wirken oft negativ auf andere. Wer die Deployment-Geschwindigkeit maximiert, riskiert mehr Fehler, wenn er die Qualität nicht im Blick behält. Das DX Core 4 macht solche Trade-offs sichtbar, indem es die Metriken gegeneinander abwägt. Drei weitere Merkmale: Es unterstützt alle Organisationsebenen, lässt sich in wenigen Wochen einführen und vermeidet Angst und Spielsucht. Die Diffs-pro-Entwickler-Metrik ist umstritten. Die Autoren raten: Diese Metrik nie an Ziele koppeln, immer mit dem Developer Experience Index (DXI) betrachten und transparent kommunizieren. Meta, Microsoft und Uber nutzen sie erfolgreich unter diesen Bedingungen.

Zur Datenerhebung kombiniert das DX Core 4 drei Methoden: Systemmetriken, Selbstauskünfte und Experience Sampling. Systemmetriken aus CI/CD-Pipelines sind präzise und kontinuierlich, aber schwer toolübergreifend zu normalisieren. Selbstauskünfte aus Umfragen liefern ein schnelles Bild in Bereichen, die systemseitig schwer messbar sind. Experience Sampling fängt Zwischenfragen direkt im Arbeitsfluss ein, etwa zur Nutzung eines neuen KI-Tools. Empfehlung: Mit Selbstauskünften eine Baseline schaffen, parallel Systemmetriken aufbauen. So vermeidest du Stillstand und erhältst schnell erste Daten.

Engineering-Organisationen stehen unter Druck, messbar produktiver zu werden. Märkte belohnen effizientes Wachstum, Remote-Arbeit und KI-gestützte Tools verändern die Arbeitsweise. Leader fragen sich, wie sie diese Veränderungen steuern können, ohne in teuren Dashboards zu versinken. Das DX Core 4 schlägt vor: Klein anfangen, vorhandene Daten nutzen, offen kommunizieren. In über 300 Unternehmen wurden Erfolge erzielt: Engineering-Effizienz +3-12%, 14% mehr Zeit für Feature-Entwicklung, Mitarbeiterbindung +15%. Diese Zahlen sind kein Selbstläufer. Sie erfordern korrekte Einführung mit Fokus auf Ausgewogenheit und Vermeidung von Gamification.

Drei Schritte zum Einstieg: 1. Baseline jetzt etablieren, auch nur mit Selbstauskünften. 2. Klein starten: Daten analysieren, dringendste Reibungspunkte identifizieren, minimale Änderungen umsetzen. 3. Transparent kommunizieren – im Team und zur Führungsebene. Die Metriken sind für beide Seiten relevant. Sie helfen, Prioritäten zu klären und Fortschritte sichtbar zu machen, ohne dass sich jemand kontrolliert fühlt. Der Kern: kein Überwachungsinstrument, sondern ein gemeinsames Verständnis von Produktivität aus Fakten und Erfahrung.

Was heißt das für dich? Wenn du DORA, SPACE oder DevEx nutzt, musst du nichts verwerfen. Das DX Core 4 integriert diese Ansätze und gibt dir eine klare, reduzierte Auswahl an Metriken. Du vermeidest Überforderung durch viele Zahlen und erhältst ein Gesamtbild. Kein Framework ist perfekt. Auch dieses erfordert durchdachte Einführung und Anpassung. Aber es bietet Orientierung, wenn die Messung von Entwicklerproduktivität für den Unternehmenserfolg wichtig wird. Die Autoren sagen: Fang an, bleib bodenständig, vertraue auf Daten und gesunden Menschenverstand.

Quelle: getdx.com

Stell dir vor, du bist verantwortlich für ein großes Firmennetzwerk. Täglich kommen neue Anforderungen: mehr Sicherheit, schnellere Verbindungen, stabilere Dienste. Du greifst zur Kommandozeile – dem CLI – und tippst Befehle ein. Aber jedes Gerät spricht eine eigene Sprache. Ein Router von Anbieter A versteht andere Kommandos als ein Switch von Anbieter B, und selbst innerhalb derselben Produktlinie unterscheiden sich die Funktionen von Modell zu Modell. Chaotisch. Genau hier setzt der Diskurs über „Reality-based Network Operations“ an. Die Autoren des Standardwerks „Computer Networks: A Systems Approach“ greifen das in der siebten Auflage auf. Ihre Erkenntnis: Die Lehre vom Netzwerkbetrieb hinkt der Praxis hinterher.

Der Autor, ein Netzwerktechniker, beschreibt seine Karriere geteilt in eine Pre-Cloud- und eine Cloud-Ära. Der Wendepunkt war 2011: Er verließ Cisco und wechselte zu Nicira, einem Startup, das später die Grundlage für VMware NSX legte. Dieser Schritt steht sinnbildlich für den Wandel: weg von manueller Konfiguration, hin zu automatisierter, softwaregesteuerter Infrastruktur. Die zentrale Frage heute: Wie können wir Netzwerke so betreiben, dass sie mit Cloud-Anforderungen Schritt halten, ohne die Realität heterogener Infrastrukturen zu ignorieren?

Die Herausforderung ist enorm. Stell dir vor, jedes Instrument verwendet eine andere Notenschrift. Bei Cisco versuchte sein Team, eine einheitliche API für verschiedene Router zu schaffen. Das Vorhaben scheiterte. Warum? Weil jedes Produktteam sein eigenes CLI-Design entwickelte. Conway’s Law schlug zu: Jede Abteilung optimierte ihre Features – ohne Rücksicht auf die Betriebsteams, die später mit der Integration kämpfen.

Das CLI dominiert die traditionelle Netzwerkverwaltung. Jeder neue Befehl muss dort landen. Kunden erwarten das. Bittest du ein Produktteam, zusätzlich eine API zu unterstützen, verdoppelt sich der Aufwand. Die natürliche Reaktion: Desinteresse. Daran scheiterte das API-Projekt. Heute gibt es Werkzeuge wie NAPALM, die zwischen CLIs übersetzen. Du schreibst Python-Code, der eine einheitliche Schnittstelle bietet. Ein pragmatischer Ansatz – aber die Grundübel der Inkonsistenz sind nicht beseitigt.

Der eigentliche Durchbruch: die Erkenntnis, dass eine API allein nicht reicht. Es braucht bessere Abstraktionen. Scott Shenker formulierte das 2011: Wir müssen Netzwerke als Ganzes steuern, nicht nur einzelne Geräte. Das war die Geburtsstunde des Software-Defined Networking (SDN) – zumindest in der Form, die Nicira umsetzte. Ein zentraler Controller steuert verteilte Forwarding-Devices. Die Herausforderung: physikalische Switches unter einen Hut zu bekommen. Die Lösung: Man beschränkte sich auf virtuelle Switches in Hypervisoren. Diese lassen sich einheitlich programmieren. Durch ein Overlay-Netz über dem physischen Netzwerk blendet man die Komplexität des Underlays aus. Das Underlay bleibt statisch, das Overlay lässt sich dynamisch anpassen.

Die Praxis war komplizierter. Frühe Nicira-Kunden standen vor einem Henne-Ei-Problem: Sie brauchten eine Cloud-Management-Plattform. Die damalige Standardlösung hieß OpenStack – mächtig, aber komplex und unreif. Der Autor beschreibt: Das erste Gespräch mit Interessenten endete oft mit der Frage „Welche Cloud-Plattform nutzt ihr?“. Kam ein verständnisloser Blick, war das Produkt nicht geeignet. Die Technologie fand ihren Weg nicht über Cloud-Automatisierung, sondern über ein konkretes Problem: Mikrosegmentierung – granulare Absicherung von Arbeitslasten im Rechenzentrum. Das trieb die Einführung von Overlay-Netzen voran. (Für tiefergehende Darstellung verweisen die Autoren auf ihr separates SDN-Buch.)

Die Verfasser stehen vor einem didaktischen Dilemma. Einerseits möchten sie Studierenden die elegante Welt der Hyperscaler nahebringen – mit OpenConfig und YANG. Andererseits müssen sie zugeben, dass dieser Ansatz für die meisten Betreiber kaum umsetzbar ist. Hyperscaler wie Google oder Microsoft entwickeln eigene Netzsoftware – SONiC oder Jupiter. Sie gestalten die Welt nach ihren Bedürfnissen. Ein mittelständisches Unternehmen mit Routern von drei Herstellern und Switches aus fünf Generationen kann das nicht. Für den Praktiker gibt es keinen Königsweg. Automatisierungswerkzeuge wie Ansible, NAPALM oder SaltStack reduzieren manuelle Tippfehler und rollen konsistente Konfigurationen aus. Cloud-Plattformen wie OpenStack oder Kubernetes erfordern zudem Verständnis von Netzwerkabstraktionen – Overlays, virtuelle Switches, programmierbare APIs. Die Herausforderung: die Brücke schlagen zwischen der idealisierten Welt der Hyperscaler und der gewachsenen Infrastruktur. Ein Negativbeispiel: Der Telstra-Ausfall in Australien – eine Kette von Fehlern, undokumentierte Konfigurationsänderung, bekannter Bug in einem nicht aktualisierten System. Solche Probleme treten in der manuell geprägten Betriebswelt immer wieder auf. Sie zeigen: Netzwerkbetrieb ist nicht nur eine Frage der Tools, sondern auch der Prozesse, Schulungen und Unternehmenskultur. Die Cloud-Revolution hat diese Probleme sichtbar gemacht und Lösungen aufgezeigt, aber nicht für alle gelöst. Für dich bedeutet das: Lerne die Konzepte von SDN und Automatisierung. Sie sind die Zukunft. Aber unterschätze nicht die Realität heterogener Umgebungen. Die Fähigkeit, zwischen Abstraktionsebenen zu wechseln – von der CLI eines Routers zur API einer Cloud-Orchestrierung – wird zur Kernkompetenz. Die Autoren verstehen: Eine realistische Darstellung muss beide Welten zeigen. Sie arbeiten daran, ihr neues Kapitel zu überarbeiten – nicht nur die Wunschvorstellung der Hyperscaler, sondern auch die Werkzeuge und Methoden, mit denen Betriebsteams heute arbeiten. Ein ehrlicher Ansatz, der Lehrmaterialien relevant hält.

Quelle: systemsapproach.org

Du baust ein Haus. Du verlegst Rohre, damit Wasser fließt, und du ziehst Kabel, damit Strom ankommt. Das ist Data Integration: Systeme werden verbunden, Daten bewegen sich von A nach B und kommen in der richtigen Form an. Aber wer entscheidet, wann der Wasserhahn aufgedreht wird, welche Pumpe läuft und was passiert, wenn ein Rohr bricht? Das ist Workflow Orchestration: die Koordination der Arbeit, die auf den verbundenen Systemen ausgeführt wird. Der Artikel zieht eine klare Linie: Systeme verbinden ist nicht dasselbe wie die Arbeit darüber zu koordinieren. Dennoch behandeln Unternehmen diese beiden Disziplinen oft als eine Einheit, kaufen Tools, stellen Teams ein und entwerfen Architekturen, als ob Data Integration und Workflow Orchestration austauschbar wären. Sie sind es nicht.

Die Verwirrung beginnt bei den Connectors. Ein Data-Integration-Tool bringt vorgefertigte Anschlüsse mit – für Datenbanken, SaaS-Apps, APIs. Ein moderner Orchestrator wie Airflow, Dagster, Kestra, Prefect oder Temporal bietet ebenso Dutzende von Plugins für dieselben Systeme. Oberflächlich betrachtet können beide an alles anknüpfen. Aber die Connectors erfüllen unterschiedliche Aufgaben. Integration nutzt sie, um Daten zu verschieben und umzuformen. Orchestrierung nutzt sie, um Tasks auszulösen, Abhängigkeiten zu steuern und nach Fehlern wieder hochzufahren. Derselbe Plugin zu einem System, aber zwei völlig verschiedene Gründe, ihn aufzurufen. Der Artikel unterscheidet zwischen Data Integration und Workflow Orchestration, zeigt die Überlappungen und erklärt, warum ein einheitliches Control Plane in Unternehmen immer wichtiger wird.

Was ist Data Integration?

Data Integration ist die Praxis, Systeme zu verbinden und Daten in der richtigen Form zwischen ihnen zu bewegen. Es ist nicht eine einzige Technik, sondern umfasst drei Kommunikationsparadigmen, die sich grundlegend unterscheiden. Da ist das Request-Response-Muster: Ein System fragt, ein anderes antwortet – APIs, REST, gRPC. Synchron und sofortig. Dann das ereignisgesteuerte Muster: Systeme veröffentlichen Ereignisse, andere reagieren darauf – Streaming, Apache Kafka, Change Data Capture. Kontinuierlich und entkoppelt. Und schließlich der Batch-Betrieb: Daten werden in geplanten, massenhaften Läufen verschoben – ETL, ELT, Dateitransfer. Periodisch und mit hohem Volumen. ETL, ELT, ESB, iPaaS, CDC, Reverse ETL und Event Streaming fallen alle in diese Paradigmen. Gleiches Ziel, andere Physik. Ein nächtlicher Warehouse-Load und ein Echtzeit-Fraud-Stream sind beides Integration, aber ihr Design hat kaum etwas gemeinsam.

Der schwierige Teil ist selten der Connector. Es ist die Konsistenz. Derselbe Kundendatensatz lebt in einem Dutzend Systemen, und die Integration muss sie in Übereinstimmung halten. Echtzeit-Integration macht das nicht einfacher, sondern schwieriger. Das Dual-Write-Problem, außerhalb der Reihenfolge eintreffende Ereignisse und doppelte Zustellung bedrohen die Korrektheit. Die meisten Streaming-Systeme bieten At-Least-Once-Delivery plus idempotente Verarbeitung – effektiv genau einmal, aber keine echte Exactly-Once-Garantie. Change Data Capture, Transactional Outbox Patterns und Reconciliation existieren, um die Konsistenz zusammenzuhalten. Die Integrationsfrage lautet also nicht nur: Sind die Daten angekommen? Sondern: Sind sie korrekt, vollständig, pünktlich und konsistent in allen Systemen angekommen? Die Arbeitseinheit der Integration ist der Datensatz, der Stream oder der Record.

Was ist Workflow Orchestration?

Workflow Orchestration ist die Koordinationsschicht, die entscheidet, was läuft, in welcher Reihenfolge, unter welchen Bedingungen und wie das System sich erholt, wenn etwas kaputtgeht. Sie bewegt nicht primär Daten, sondern steuert die Ausführung. Wo die Integration fragt: „Sind die Daten angekommen?“, fragt die Orchestrierung: „Sind die richtigen Schritte in der richtigen Reihenfolge mit den richtigen Abhängigkeiten gelaufen, und was tun wir mit dem einen, das fehlgeschlagen ist?“ Die Arbeitseinheit ist der Task, der Workflow oder der Prozess. Retry-Logik, Abhängigkeiten, bedingte Verzweigungen, Zeitplanung, Backfills und Ende-zu-Ende-Sichtbarkeit leben hier.

Orchestrierung reicht über die reine Datenwelt hinaus. Dieselben Koordinationsprobleme treten im IT- und Batch-Job-Scheduling, in der Geschäftsprozessautomatisierung und in der Infrastrukturbereitstellung auf. Und zunehmend auch in agentischer KI, wo die Aktionen eines Agenten sequenziert, mit Gates versehen und wiederhergestellt werden müssen wie jeder andere Workflow. Orchestrierung steht nicht allein. Sie ist der Ausführungskern einer breiteren Disziplin: Process Intelligence, die zeigt, wie diese Abläufe tatsächlich laufen, wo sie stocken und was sie kosten. „Du kannst einen Prozess nicht verbessern, den du nicht sehen kannst.“ Der Artikel über Process Intelligence ergänzt diesen Text und trennt die Orchestrierung von der Datenintegration.

Data Orchestration und Workflow Automation – Begriffe, die die Linie verschwimmen lassen

Zwei benachbarte Begriffe sorgen für die meiste Verwirrung. Data Orchestration ist ein gängiger Begriff im modernen Data Stack. Er beschreibt Workflow Orchestration, die auf die Datenwelt beschränkt ist: Koordination von Ingestion, Transformation und Lieferung innerhalb der Data Pipeline. Viele argumentieren, es sei schlicht Workflow Orchestration angewendet auf Daten, und der einfachere Name verursache weniger Verwirrung. Wenn ein Anbieter „Orchestrierung“ sagt und nur Pipelines meint, beschreibt er die datenbezogene Version.

Workflow Automation dagegen ist kein niedrigeres Level derselben Leiter, sondern etwas Engeres. Automation feuert eine einzelne Aufgabe ab, wenn ein Trigger eintritt. Orchestrierung koordiniert viele Aufgaben über Systeme hinweg, respektiert ihre Abhängigkeiten und weiß, was zu tun ist, wenn eine fehlschlägt. Automation führt eine Aufgabe aus. Orchestrierung führt den Prozess darum herum. Keiner der Begriffe ist ein Synonym für Orchestrierung, die sich über mehrere Kategorien erstreckt.

Was Cross-Domain wirklich bedeutet

Mit Domain ist hier eine Kategorie von Arbeit gemeint: Data Pipelines, Infrastrukturautomatisierung, Geschäftsprozesse, IT- und Infrastruktur-Scheduling. Data Integration lebt in der Datenkategorie. Workflow Orchestration kann Tasks über mehrere Kategorien hinweg in einem Flow koordinieren. Diese Fähigkeit ist mit Cross-Domain gemeint. Es ist eine Fähigkeit, keine Garantie. Viele Orchestratoren laufen nur Data Pipelines, was sie in der Praxis zu Data Orchestratoren macht. Die Kategorie wird dadurch definiert, was Orchestrierung abdecken kann, nicht dadurch, was jede einzelne Bereitstellung zufällig nutzt.

Warum Data Integration und Workflow Orchestration verwechselt werden

Die beiden treffen sich innerhalb der Data Pipeline, und dort kreuzen sich die Drähte. Integrationstools haben eingebaute Scheduler. Ein modernes ETL- oder iPaaS-Produkt kann Jobs auslösen, ein paar Schritte verketten und einen Fehler wiederholen. Das ähnelt Orchestrierung. Orchestratoren bewegen Daten. Eine Workflow-Engine kann eine API aufrufen, eine Transformation ausführen und eine Datei ablegen – unter Verwendung derselben Connectors, die ein Integrationstool verwenden würde. Das ähnelt Integration. Die Data Pipeline ist die Überschneidung. Beide können eine betreiben, aber ihre Reichweite unterscheidet sich. So dringen beide in das jeweils andere Terrain vor, und einige Plattformen sitzen in beiden. Moderne iPaaS-Suiten wie Boomi, MuleSoft und Workato haben echte Orchestrierungsfähigkeiten entwickelt, und viele Teams führen ihre Prozesse dort aus. Die nützliche Frage ist nicht, welches Etikett ein Tool trägt, sondern seine Reichweite. Ein Tool, das seine eigenen Connectors und Jobs koordiniert, deckt eine Kategorie gut ab. Cross-Domain-Orchestrierung reicht weiter: den Daten-Load, die Infrastruktur, auf der er läuft, die Freigabe, die ihn freischaltet, und den Agenten, der auf das Ergebnis reagiert.

Data Integration vs Workflow Orchestration: Vier Dimensionen

Der Artikel unterscheidet zwischen den beiden Konzepten entlang von vier Dimensionen. Das Kernanliegen: Verschieben und Umformen von Daten versus Koordination von Arbeitsabläufen. Die Arbeitseinheit: Datensatz, Stream oder Record versus Task, Workflow oder Prozess. Der Umfang: Daten über Systeme hinweg versus Arbeit über Kategorien hinweg. Das Fehlerbild: falsche, verspätete oder inkonsistente Daten versus eine unterbrochene Sequenz ohne Wiederherstellung. Integration kümmert sich um die Daten, Orchestrierung um die Arbeit.

Operativ oder analytisch? Der Unterschied zieht sich durch beide

Eine weitere Unterscheidung liegt unter all dem. Systeme bedienen zwei Ebenen. Die operative Ebene (Operational Plane) betreibt das Geschäft in Echtzeit: Bestellungen, Zahlungen, Inventar. Die analytische Ebene (Analytical Plane) unterstützt Entscheidungen: Data Warehouses, Lakes, BI, Modelltraining. Integration umfasst beide. Ein latenzunempfindlicher nächtlicher Load in ein Warehouse ist analytische Integration. Ein missionskritischer, niedrig-latenter Event-Stream, der ein Bestellsystem speist, ist operative Integration. Sie verlangen unterschiedliche Garantien. Orchestrierung umfasst ebenfalls beide. Das Planen von Analyse-Pipelines ist nicht dasselbe wie die Koordination eines Zahlungs-Workflows, bei dem ein fehlender Schritt Geld kostet. Ein häufiger Fehler ist, jede Pipeline als missionskritisch zu behandeln oder jeden missionskritischen Flow als einfache Pipeline. Gleiche die Zuverlässigkeit des Tools an die Ebene an, die es bedient.

Wann brauchst du Workflow Orchestration zusätzlich zur Data Integration?

Der eingebaute Scheduler deines Integrationstools reicht aus, solange die Arbeit innerhalb dieses Tools bleibt. Ein paar Pipelines, lineare Abhängigkeiten, Fehler, die du per Hand im Auge behältst. Du bist darüber hinausgewachsen, wenn Abhängigkeiten Systeme kreuzen – zum Beispiel ein Daten-Load, der auf einen Infrastrukturschritt wartet, der wiederum auf eine menschliche Freigabe wartet. Wenn Fehler Logik brauchen: wiederhole dies, überspringe jenes, kompensiere das andere, alarmiere eine Person beim vierten Versuch. Wenn ein einziger Blick (One Pane of Glass) wichtig ist und du jeden Lauf über den gesamten Stack sehen willst, nicht nur ein Tool nach dem anderen. Und wenn die Arbeit Kategorien überspannt – Daten, Infrastruktur, Anwendungen und Agenten im selben Flow.

Das Gegenteil gilt ebenso. Ein Orchestrator kann eine API aufrufen und eine Datei verschieben, aber das ist keine Data-Integrationsplattform. Wenn du zuverlässigen, volumenstarken, konsistenten Datentransport benötigst – mit ausgereiften Connectors, Change Data Capture, Schema-Handling und Transformation – dann willst du eine dedizierte Integrationsschicht. Baue das nicht in deinem Orchestrator nach, nur um Daten zu bewegen. Und wenn deine Integrationsplattform bereits die Prozesse koordiniert, die du ausführst, brauchst du vielleicht gar keinen separaten Orchestrator. Passe das Tool an die Reichweite der Koordination an, nicht an das Etikett auf der Verpackung.

Unified Orchestration: Ein Control Plane für alle Kategorien

Jahrelang bekam jede Kategorie ihren eigenen Koordinator. Ein Data-Team betrieb einen Pipeline-Scheduler. Ein Platform-Team betrieb Infrastrukturautomatisierung. Eine Geschäftseinheit betrieb eine Process Engine. Ein IT-Team betrieb einen Batch-Scheduler, geerbt aus der Mainframe-Ära. Vier Koordinatoren, vier Silo, keine gemeinsame Sicht. Unified Orchestration ist die Idee, dass ein einziges Control Plane die Arbeit über alle diese Kategorien hinweg koordinieren kann. Nicht ein Tool, das alles macht, sondern eine Orchestrierungsschicht, die Data Pipelines, Infrastrukturautomatisierung, Geschäftsprozesse und IT-Scheduling sequenziert – mit gemeinsamer Sichtbarkeit und gemeinsamer Governance. Agentische KI macht diese Entwicklung unvermeidlich. Ein Agent, der Live-Daten liest, einen internen Service aufruft, einen Datensatz aktualisiert und auf eine menschliche Freigabe wartet, berührt jede Kategorie auf einmal. Etwas muss das koordinieren. Ein pro-Kategorie-Scheduler kann das nicht. Unified Orchestration ist eine Kategorierichtung, nicht unbedingt ein einzelnes Produkt. Die Plattformen konvergieren dorthin.

Für den Praktiker bedeutet das: Überlege nicht, ob du ein Integrationstool oder einen Orchestrator brauchst, sondern welche Reichweite deine Koordination haben muss. Der Trend geht zur Vereinheitlichung, aber die Grundlage bleibt das Verständnis der beiden Disziplinen. Data Integration verbindet Systeme – Workflow Orchestration koordiniert die Arbeit darauf. Wer den Unterschied versteht, kann Architekturen bauen, die sowohl korrekte Daten als auch zuverlässige Abläufe liefern. Das Ziel: die richtigen Daten zur richtigen Zeit am richtigen Ort – und die richtigen Arbeitsschritte in der richtigen Reihenfolge, egal ob ein System ausfällt oder ein Mensch erst zustimmen muss.

Quelle: kai-waehner.de

Stell dir vor, du leitest ein Team von Softwareentwicklern. Ihr habt einen Haufen automatisierter Tests, die nach jedem Commit laufen. Bisher hast du Skripte geschrieben, die Tests starten, Ergebnisse sammeln und Fehler melden. Jetzt kommt eine neue Technologie: agentic AI. Damit könnten diese Abläufe vollständig autonom von KI-Agenten gesteuert werden – von der Planung bis zur Fehlerbehebung. Klingt verlockend, oder? Aber sobald man tiefer gräbt, wird klar: Der Erfolg hängt nicht an einem besseren Sprachmodell. Er hängt an der gesamten Infrastruktur, die diese Agenten umgibt.

Intel hat das genau untersucht. In tausenden Experimenten mit agentischen KI-Workloads haben sie fünf praktische Lektionen extrahiert. Relevant für jeden, der agentic AI im Unternehmen produktiv einsetzen will. Intel hat nicht nur die reine Inferenzleistung gemessen, sondern das gesamte System – Orchestrierung, Datenzugriff, Tool-Ausführung und Skalierung. Die Ergebnisse sind eine Art Bauplan für die Enterprise-Umgebung von morgen.

Was ist agentic AI wirklich?

Agentic AI ist mehr als nur ein Chatbot mit Zugriff auf eine Datenbank. Es sind Software-Agenten, die eigenständig komplexe Geschäftsprozesse Ende-zu-Ende ausführen. Ein typischer Agent plant einen mehrstufigen Auftrag, ruft verschiedene Tools und APIs auf, liest Zwischenergebnisse und wiederholt Schritte, wenn etwas schiefgeht. Erinnert an einen virtuellen Kollegen, der nicht nur denkt, sondern handelt. Im Kern ist agentic AI eine Workflow-Automation auf KI-Basis – aber die meiste Zeit verbringt ein Agent nicht mit Denken, sondern mit Warten auf Antworten von Datenbanken, APIs und anderen Systemen. Genau das macht die Infrastruktur so entscheidend.

Die fünf Lektionen aus Intels Experimenten

1. Agentic AI ist ein Systemproblem, kein reines Inference-Problem

Die erste Erkenntnis: Die Performance eines Agenten hängt nicht allein von der Geschwindigkeit des Sprachmodells ab. Intels Experimente zeigten, dass die meiste Zeit für Orchestrierung, Datenzugriff und Tool-Ausführung draufgeht – das LLM ist nur ein Teil des Puzzles. Wer die Infrastruktur nur nach der Inferenzleistung optimiert, übersieht die Engpässe bei der Workflow-Ausführung. Stell dir einen Flughafen vor: Die beste Startbahn nützt nichts, wenn die Gepäckabfertigung oder die Sicherheitskontrollen stocken. Bei agentic AI muss die gesamte Kette stimmen.

2. Die meisten Benchmarks messen das Falsche

Gängige Metriken für agentic AI konzentrieren sich auf die Qualität des LLMs – etwa Genauigkeit oder BLEU-Scores. Für den Enterprise-Einsatz reicht das nicht. Intel schlägt sechs praxisrelevante Metriken vor: Task-Erfolgsrate, Kosten pro Aufgabe, Zeit pro Aufgabe, Durchsatz (Anzahl abgeschlossener Aufgaben pro Zeit), Agentendichte (Anzahl Agenten pro virtuellem CPU-Kern) und Latenz (insbesondere die 95. Perzentil-Latenz). Diese Kennzahlen beantworten Fragen, die ein IT-Leiter wirklich stellt: Läuft das System wie erwartet? Wie viele Agenten kann ich gleichzeitig betreiben? Wie muss ich skalieren, wenn die Last steigt?

3. Plane mit Agentendichte, nicht mit Agentenzahl

Eine praktische Lektion: Statt zu fragen „Wie viele Agenten passen auf einen Server?“, betrachte die Agentendichte – die Anzahl der Agenten pro virtuellem CPU-Kern (vCPU). Das ist wie bei einem Büro: Die reine Mitarbeiterzahl sagt wenig, wenn man nicht weiß, wie viel Platz und Equipment jeder benötigt. Ein System mit 8 vCPUs und 10 Agenten verhält sich ähnlich wie ein System mit 16 vCPUs und 20 Agenten, wenn die Dichte gleich ist. Die richtige Dichte hängt vom Einsatzzweck ab: Interaktive Assistenten (z.B. Chatbots) brauchen niedrige Dichte, weil schnelle Antworten wichtig sind. Batch-Workloads (z.B. automatisierte IT-Aufgaben) vertragen höhere Dichte. Das gibt Teams ein praktisches Werkzeug, um Kosten und Performance auszutarieren.

4. Überwache die Task-Latenz, nicht nur die CPU-Auslastung

Agenten arbeiten oft in Stößen: Sie warten auf eine Modellantwort, führen dann kurz intensive Berechnungen durch, warten wieder, und so weiter. Durchschnittliche CPU-Auslastung kann dabei völlig normal aussehen, selbst wenn die Wartezeiten die Nutzererfahrung ruinieren. Intel empfiehlt, die Task-Latenz im 95. Perzentil (P95) als Frühwarnsignal zu nutzen. Wenn die Latenz steigt, wissen Betreiber sofort, dass die Workflows in die Warteschleife geraten – noch bevor sich die durchschnittliche Bearbeitungszeit verschlechtert. Das ist wie bei einer Ampel: Die durchschnittliche Wartezeit aller Autos sagt wenig aus, wenn einzelne Fahrer ewig stehen. Die P95-Latenz zeigt dir die echten Staus.

5. Default zu Scale-out, nicht Scale-up

Die letzte Lektion betrifft die Skalierung. Scale-out bedeutet, mehr Server hinzuzufügen. Scale-up bedeutet, einen einzelnen Server mit mehr Kernen oder Arbeitsspeicher aufzurüsten. Intels Daten zeigen: Scale-out ist meist die bessere Wahl. Agenten sind halbunabhängig und verursachen nur moderate Lastspitzen – das passt perfekt zu vielen kleineren Systemen. Scale-out verbessert die Gesamtperformance, erhöht die Ausfallsicherheit und senkt oft die Kosten. Zudem lässt sich die gewünschte Agentendichte leichter einhalten. Scale-up sollte man nur dann einsetzen, wenn Agenten rechenintensive Bursts haben, wenn sie gemeinsamen Speicher benötigen oder Lizenzmodelle es vorgeben. Faustregel: Skaliere horizontal, es sei denn, du hast einen guten Grund dagegen.

Die drei Phasen des Aufbaus

Intel fasst die Erkenntnisse in drei Phasen zusammen, die Unternehmen bei der Einführung von agentic AI durchlaufen sollten. Zuerst planen: nicht die Anzahl der Agenten, sondern die Dichte pro vCPU bestimmen. Dann beobachten: mit P95-Latenz als Leitmetrik und nicht mit Durchschnittswerten. Und schließlich skalieren: standardmäßig horizontal wachsen, nur bei speziellen Anforderungen vertikal. Dieser Dreiklang gibt einen klaren Fahrplan für den Weg vom Pilotprojekt zur Produktion.

Wo entsteht der größte Business-Value?

Organisationen, die mit agentic AI bereits echte Ergebnisse erzielen, setzen es dort ein, wo es bereits codierte Regeln und messbare Service-Level gibt. Typische Beispiele: Code-Erstellung, Regression-Test-Farmen, Ticket-Triaging, Marktanalysen und Security-Reviews. Die ideale Persona für agentic AI ist nicht der experimentierfreudige Enthusiast, sondern der verantwortungsbewusste Manager, der Zykluszeiten verbessern, Produktivität steigern, Servicequalität schützen und Kosten kontrollieren muss. Agentic AI liefert dann Wert, wenn es echte Arbeit quer durch Teams, Systeme und Prozesse erledigt – zuverlässig und skalierbar.

Was bedeutet das konkret?

Wer heute in agentic AI investiert, sollte nicht nur auf ein besseres Sprachmodell hoffen. Der Erfolg steht und fällt mit der Infrastruktur: mit der Fähigkeit, Agenten zu orchestrieren, ihre Latenz zu überwachen, die Dichte zu planen und horizontal zu skalieren. Intels Experimente sind kein Marketing, sondern eine solide technische Richtschnur. Sie zeigen, dass die „magische“ KI vor allem harte Systemarbeit braucht – und dass die Prinzipien, die wir aus dem Betrieb verteilter Systeme kennen, auch für die Agenten-Welt gelten. Wer diese Lektionen ernst nimmt, wird agentic AI nicht als Hype, sondern als nächsten logischen Schritt der Automatisierung in sein Unternehmen integrieren.

Quelle: technologyreview.com

Warum Roboter nicht einfach aus dem Internet lernen können

Einem Menschen beibringen, zu kochen: Man gibt ihm Kochbücher, zeigt Videos, lässt ihn nachmachen und korrigiert Fehler. Jede Methode liefert andere Informationen – Theorie, Bewegung, haptische Rückmeldung. Beim Training von Robotern mit Künstlicher Intelligenz ist es ähnlich. Sprachmodelle schöpfen aus Milliarden Texten im Internet – einem kostenlosen, von der Menschheit gesammelten Übungskorpus. Für Roboter gibt es keinen vergleichbaren Datenberg. Es existiert kein „YouTube für Roboteraktionen“, aus dem ein System die optimale Greifbewegung extrahieren könnte. Dieses Datenproblem ist der zentrale Flaschenhals für eine physische Allgemeine Künstliche Intelligenz (AGI) – Roboter, die flexibel in unserer unordentlichen Welt agieren. Die Robotik-Forschung setzt auf eine kluge Kombination verschiedener Datenquellen, eine Art Datenpyramide, die das Beste aus jedem Bereich zusammenbringt.

Die Pyramide als roter Faden

Stell dir eine Pyramide vor: Die Basis besteht aus massenhaft vorhandenen, aber wenig spezifischen Daten – etwa Webvideos. Je höher man klettert, desto teurer und aufwendiger wird die Datensammlung, aber desto präziser und näher an der echten Roboter-Hardware. An der Spitze stehen die begehrtesten Daten: echte Robotereinsätze in Fabriken oder Haushalten. Das NVIDIA-Team GR00T hat dieses Modell vorgeschlagen, die Community griff es auf. In diesem Beitrag tauchen wir tiefer in den Datenengpass ein und betrachten eine erweiterte Version dieser Pyramide mit sieben konkreten Datentypen, gegliedert in drei Kategorien: Webdaten, synthetische Daten und echte Roboter-Daten. Der Autor Tanay Jaipuria, Partner bei Wing und Verfasser eines Newsletters über die Technologieindustrie, beschreibt, wie die Robotik-Forschung diesen Engpass zu überwinden versucht.

Ebene 1: Webdaten – Die Millionen-Stunden-Quelle, die kaum genutzt wird

Die unterste Ebene der Pyramide ist die breiteste: das gesamte öffentlich zugängliche Videomaterial im Internet. Auf YouTube kommen jährlich rund 300 Millionen Stunden Videomaterial hinzu – Menschen, die kochen, putzen, montieren, reparieren. Dieses Rohmaterial ist nicht angereichert, es fehlen Tiefeninformationen, Kraftrückmeldungen oder präzise Handpositionen. Trotzdem kann es einem Modell grundlegende Konzepte beibringen: Was ist ein Teller? Wie sieht eine Greifbewegung aus? In welcher Umgebung findet eine bestimmte Tätigkeit statt? Bislang fließen diese Daten meist nur indirekt ein – über vortrainierte Sprach-Bild-Modelle, die als Grundlage für Robotersysteme dienen. Doch es gibt konkrete Versuche, den Schatz direkt zu heben. NVIDIA arbeitet an DreamZero, einer Methode, die eine auf Internet-Videos vortrainierte Videogenerierung direkt in eine Roboter-Policy einbaut. Das Startup Rhoda AI geht noch einen Schritt weiter: Es trainiert zunächst auf Hunderten Millionen Internet-Videos und passt das Modell dann mit nur 10 bis 20 Stunden echter Roboter-Daten auf eine spezifische Maschine an. Ein Kochlehrling sieht erst tausend Kochshows und braucht dann nur eine kurze praktische Anleitung, um ein bestimmtes Gericht zu perfektionieren.

Ebene 2: Egocentrische Humanvideos – Die Perspektive des Handelnden

Einen Schritt weiter oben in der Pyramide liegen Videos aus der Ich-Perspektive, aufgenommen mit am Kopf befestigten Kameras. Seit etwa einem Jahr kaufen viele Robotik-Labore gezielt solche Aufnahmen ein. Offene Datensätze wie Egoverse und Ego4D enthalten tausende Stunden Material, in denen Menschen alltägliche Aufgaben in Haushalten oder Fabriken verrichten. Die Kamera blickt aus der Perspektive der Hände, die die Arbeit machen, und liefert damit eine ähnliche visuelle Information, wie sie auch ein Roboter mit seiner Kamera sehen würde. Forschungsarbeiten haben gezeigt: Modelle, die auf sorgfältig gefilterten egozentrischen Humanvideos vortrainiert wurden, schneiden besser ab als solche, die auf der gleichen Menge an teleoperierten Roboterdaten trainiert wurden – vorausgesetzt, beide werden anschließend auf den Zielroboter adaptiert. Ein Mensch, der etwas tut, liefert scheinbar nützlichere Trainingssignale als ein Roboter, der dieselbe Aktion ausführt. Der Grund liegt in der Vielfalt und Natürlichkeit der menschlichen Bewegung, die der Roboter später nachahmen soll.

Ebene 3: Angereicherte ego-/exocentrische Daten – Vom rohen Video zum strukturierten Datensatz

Manchmal reicht ein einfaches Video nicht aus. Dann wird das egozentrische Material mit zusätzlichen Informationen angereichert: Hand-Pose-Tracking, Tiefenkameras, Blickrichtung (Gaze-Tracking) oder sogar vollständige Motion-Capture-Anzüge, die jede Gelenkbewegung aufzeichnen. Der Datensatz Ego-Exo4D enthält rund 1.400 Stunden sowohl aus der Ich- als auch aus der Dritten-Person-Perspektive von anspruchsvollen Tätigkeiten. Auch Tesla hat Arbeiter in Motion-Capture-Anzüge gesteckt, um präzise Bewegungsdaten zu sammeln. Je nach Detailgrad der Anreicherung – manche Labore erfassen sogar taktile Kräfte – können diese Daten die Lücke zwischen menschlicher Demonstration und Roboterausführung deutlich verkleinern. Die Datensammlung wird aufwendiger und teurer, skaliert aber immer noch besser als echte Roboterdaten.

Ebene 4: UMI-Daten (Universal Manipulation Interface) – Der Mensch als Roboter-Stellvertreter

Eine besonders clevere Methode ist der Universal Manipulation Interface (UMI). Ein Mensch trägt am Ende seines Arms oder in der Hand ein End-Effector-Werkzeug – den Greifer oder die Hand, die später der Roboter verwenden soll. Der Mensch führt die Aufgaben aus, während das System Bewegungen und Kräfte aufzeichnet. Der Vorteil: Du sammelst Daten, die fast so aussehen, als kämen sie vom echten Roboter, ohne den Roboter selbst zu benötigen. Das Startup Sunday Robotics, gegründet von den UMI-Erfindern, verschickt eigens entwickelte Greifhandschuhe an Freiwillige nach Hause. Diese Handschuhe sind kodesigniert mit den Roboterhänden des Unternehmens. So hat Sunday Robotics sein Modell ACT-1 auf rund zehn Millionen Haushalts-Episoden trainiert – ohne eine einzige Sekunde echte Roboter-Teleoperation. Auch das Toyota Research Institute setzt auf UMI, kombiniert mit Teleoperation und Simulation, um seine Large Behavior Models zu trainieren.

Ebene 5: Simulierte und synthetische Daten – Die grenzenlose, aber unperfekte Welt

Ein weiterer Zweig der Pyramide sind simulierte Daten aus Physik-Engines wie Isaac Sim oder MuJoCo. Theoretisch sind nur die Rechenkapazität Grenzen gesetzt: Du kannst Millionen von virtuellen Umgebungen generieren, in denen der Roboter trainieren kann, ohne dass ein physischer Roboter abgenutzt wird oder riskante Manöver ausführt. In der Praxis klafft jedoch die sogenannte Sim-to-Real-Lücke: Was in der Simulation perfekt funktioniert, überträgt sich oft nicht eins zu eins in die reale Welt. Besonders bei Manipulationen von weichen Objekten oder bei komplexen physikalischen Interaktionen stoßen Simulatoren an ihre Grenzen. Neue Entwicklungen wie Weltmodelle – etwa NVIDIAs Cosmos oder Googles Genie 3 – versuchen, diese Lücke zu schließen, indem sie als gelernte Simulatoren agieren, die aus echten Daten gelernt haben, wie die Welt funktioniert. Die Autonome-Fahrzeug-Industrie, etwa Waymo, hat gezeigt, dass Simulation ein mächtiges Werkzeug sein kann, um Fahrsituationen milliardenfach zu trainieren. Für Roboter in Haushalten oder Fabriken ist diese Technik noch nicht reif für den breiten Einsatz – der Fortschritt ist rasant.

Ebene 6: Teleoperierte Roboterdaten – Präzise, aber teuer

Ein Schritt weiter oben steht die Teleoperation. Ein menschlicher Operator steuert den Roboter in Echtzeit, entweder über ein VR-Set oder über einen mechanischen Nachführarm (Rig). Der Roboter kopiert jede Bewegung des Menschen millimetergenau. Das Ergebnis sind extrem hochwertige, embodiment-spezifische Daten – sie stammen exakt von der Hardware, die später auch autonom fahren soll. Der Haken: Teleoperation ist teuer. Die Kosten liegen bei über 100 Dollar pro Stunde, benötigen geschulte Operateure und sind durch die Anzahl der Roboter und Umgebungen begrenzt. Sergey Levine, führender Kopf bei Physical Intelligence, hat in einem Podcast die Spannung beschrieben: Einerseits ist Teleoperation die sicherste Methode, um Daten ohne Übersetzungsverlust zu sammeln, andererseits kaum skalierbar. Die allgemeine Meinung in Laboren: Teleoperation wird nie ganz verschwinden, aber ihr Anteil am Trainingsmix könnte sinken, wenn andere Quellen besser werden. Vielleicht wird Teleoperation künftig vor allem in der Feinabstimmung (Post-Training) eingesetzt, während die groben Fähigkeiten aus billigeren Daten stammen.

Ebene 7: Echte Robotereinsätze – Der heilige Gral, aber das Henne-Ei-Problem

An der Spitze der Pyramide stehen die begehrtesten Daten: echte Roboter, die reale Arbeit in realen Umgebungen verrichten – idealerweise bezahlte Arbeit. Der Roboter läuft entweder vollständig autonom, oder ein menschlicher Teleoperator greift nur dann ein, wenn das System überfordert ist (wie ein Sicherheitsfahrer bei autonomen Autos). Das Problem: Bevor man einen Roboter einsetzen kann, muss er schon gut genug sein, um nicht ständig Hilfe zu brauchen. Ein klassisches Henne-Ei-Problem. Über die Zeit könnten diese Einsätze zu einem sich selbst verstärkenden Kreislauf führen: Mehr Deployments erzeugen mehr Daten, die die Leistung verbessern und weitere Deployments ermöglichen. In der Praxis ist die Anzahl heutiger Robotereinsätze außerhalb stark strukturierter Umgebungen – Fabriken oder autonome Fahrzeuge – noch sehr gering. Zwei wichtige Einschränkungen: Erstens helfen Daten von extrem engen Aufgaben in gleichbleibender Umgebung kaum für die Generalisierung auf andere Tätigkeiten. Zweitens werden viele frühe Deployments als Hybridsystem laufen: Der Roboter arbeitet autonom, und ein Teleoperator übernimmt bei Fehlern. Diese Form des Interventions-Lernens ist praktisch und liefert wertvolles Datenmaterial über Fehlschläge und deren Korrektur. Eine bekannte Methode ist DAgger (Dataset Aggregation), bei der die Policy aus den Korrekturen des Menschen lernt. Ansätze wie Sirius oder HIL-SERL bauen darauf auf und zeigen, dass dieses Feedback die Datenqualität enorm steigern kann.

Was bedeutet das konkret? – Eine geerdete Einordnung

Niemand weiß heute, wie viel Roboterdaten ausreichen, um eine robuste allgemeine Roboterintelligenz zu erreichen. Sergey Levine hat in dem erwähnten Podcast ehrlich gesagt: „Das ist es ja – wir wissen es nicht.“ Ob Roboter das Hundertfache oder Tausendfache der heutigen Datenmenge brauchen, bleibt offen. Für ein Robotik-Team, das ein konkretes Produkt bauen will, stellt sich die Frage pragmatischer: Welche Zuverlässigkeit ist nötig, um einen bestimmten Satz von Aufgaben in einer hybriden Umgebung zu bewältigen? Welche Mischung aus den sieben Datenquellen ist die kostengünstigste, um diese Schwelle zu überschreiten? Die Antwort wird je nach Anwendungsfall variieren. In der Medizinrobotik mag Teleoperation und hochangereichertes Egocentric-Daten dominieren, in der Logistik könnten synthetische Daten und Webvideos ausreichen. Einen Königsweg gibt es nicht. Die Zukunft gehört Teams, die klug die verschiedenen Ebenen der Datenpyramide kombinieren – vom billigen Webvideo bis zum teuren Roboter-Deployment – und dabei nie aus den Augen verlieren, dass jedes Datum seinen Preis und seinen Wert hat. Wie beim Handwerk: Wer nur aus Büchern lernt, kann nicht kochen. Wer nur von einem Meister beobachtet wird, entwickelt nie ein Eigenverständnis. Wer nur aus Fehlern lernt, verbrennt sich am Herd. Die Robotik braucht alle drei – in der richtigen Dosis.

Fazit für den Alltag: Was bedeutet das für dich?

Wenn du das nächste Mal ein Video von einem Roboter siehst, der einen Teller aufhebt oder ein Paket stapelt, denk daran: Hinter dieser scheinbar simplen Bewegung steckt ein komplexer Daten-Cocktail aus Millionen von Stunden Videomaterial, Simulationen, menschlichen Demonstrationen und vielleicht sogar echtes Geld für Teleoperation. Die KI-Technologie hinter modernen Robotern ist nicht nur eine Frage von Algorithmen und Rechenleistung, sondern vor allem eine Frage des Zugangs zu den richtigen Daten. Und weil diese Daten nicht einfach im Internet liegen wie Texte, sind clevere Ingenieure und Unternehmer gefragt, die neue Wege finden, sie zu sammeln. Es bleibt spannend, welche dieser Methoden sich durchsetzen wird. Eines ist sicher: Der Wettlauf um die Datenpyramide hat gerade erst begonnen.

Quelle: tanayj.com