8. Die Präsentationsschicht#

Die VLAN-Automatisierung lief seit sechs Wochen. Das Netzwerkteam war stolz darauf. Jeden Morgen trafen drei oder vier neue Serviceanfragen von Anwendungsteams ein, und der Orchestrator bearbeitete sie, ohne dass jemand im Netzwerkteam eine Tastatur berühren musste. Die Deployments funktionierten. Die Switches waren konfiguriert. Das Netzwerk war gesund.

Die Eskalation kam an einem Donnerstag. Der Anwendungsteamleiter fragte, warum VLAN-Anfragen drei bis fünf Werktage dauerten, obwohl das Portal “Eingereicht” anzeigte. Das Netzwerkteam prüfte ihre Queue: null ausstehende Anfragen, alle Deployments erfolgreich. Die Automatisierung hatte jede Anfrage innerhalb von zwanzig Minuten nach Eingang verarbeitet. Aber die ServiceNow-Tickets zeigten noch immer “In Bearbeitung”, weil niemand die Integration geschrieben hatte, die sie aktualisieren würde.

Die Automatisierung hatte ihre Arbeit getan. Das Ergebnis war unsichtbar.

Eine Woche später deployte das Team ein schnelles Self-Service-Portal, damit Anwendungsteams Anfragen direkt einreichen und ihren Status sehen konnten. Bis zum Mittag hatten sie in einer einzigen Stunde siebenundvierzig VLAN-Anfragen erhalten. Alle gültig. Alle korrekt formatiert. Das Problem: Das Portal hatte kein Autorisierungsmodell. Es akzeptierte Einreichungen von jedem, der die URL hatte. Alle Anfragen liefen unter einem einzigen API-Token mit plattformweiten Admin-Rechten. Es gab kein Rate-Limiting, keine Genehmigungsschranke, keinen Audit-Trail darüber, wer was eingereicht hatte.

Die Automatisierung funktionierte. Das Zugriffsmodell nicht.

Diese beiden Fehler sind beide Fehler der Präsentation. Einer ist das Fehlen einer Feedback-Schleife; der andere ist das Fehlen von Leitplanken. Dieses Kapitel schließt diese Lücke.

8.1. Grundlagen#

8.1.1. Kontext#

Jeder bisher behandelte Baustein zeigt nach innen: auf andere Bausteine oder auf Ingenieure, die die Plattform verstehen. Die Source of Truth (SoT) hält die Netzwerkintention für Automatisierungssysteme. Der Executor wendet Änderungen auf Geräte an. Observability validiert Ergebnisse. Der Orchestrator koordiniert alle. Jeder dieser Bausteine hat eine Benutzeroberfläche, eine API oder beides, die für die Menschen entworfen wurden, die die Plattform gebaut haben und betreiben, nicht für alle, die mit ihr interagieren müssen.

Die Presentation (Layer)-Schicht zeigt nach außen. Ihre Aufgabe ist es, die Plattform für Zielgruppen zugänglich zu machen, die die Interna nicht verstehen müssen: das Anwendungsteam, das einen Netzwerkdienst anfordert, der Sicherheitsprüfer, der fragt, was sich im letzten Quartal geändert hat, die CI/CD-Pipeline, die Infrastruktur ohne einen Menschen in der Schleife bereitstellt.

In Kapitel 3 saß der Präsentationsbaustein am Rand des NAF-Frameworks und zeigte auf Menschen und externe Systeme. Kapitel 6 legte die Grenze zwischen Observability-Visualisierung und Präsentation fest: Dashboards, die direkt auf Netzwerk-Telemetrie aufgebaut sind, gehören aus Design-Affinität zum Observability-Baustein; wie diese Dashboards für Nicht-Ingenieure bereitgestellt, zugangskontrolliert oder in Portale eingebettet werden, ist eine Präsentationsaufgabe. Kapitel 7 legte fest, dass asynchrone Workflows Status-Endpunkte und Benachrichtigungs-Hooks erfordern. Die Präsentationsschicht liefert beides.

8.1.2. Ziele#

Die Präsentationsschicht verfolgt drei Ziele, die direkt auf drei architektonische Funktionalitäten abbilden.

1. Eine stabile, authentifizierte API mit einem konsistenten Zugriffsmodell bereitstellen. Jeder Konsument, Mensch oder Maschine, sollte mit der Plattform über einen versionierten, zugangskontrollierten Vertrag interagieren, der sich nicht ohne Vorankündigung ändert. Die zugrundeliegenden Bausteine können ersetzt, aktualisiert oder umstrukturiert werden; der konsumentenorientierte Vertrag muss stabil bleiben. Authentifizierung und Autorisierung werden an dieser Grenze durchgesetzt, zentralisiert statt pro Werkzeug dupliziert.

2. Jeden Konsumententyp durch die für seinen Workflow passende Schnittstelle bedienen. Ein Netzwerkingenieur und ein Anwendungsteam-Manager haben unterschiedliche Bedürfnisse, unterschiedliche technische Tiefe und unterschiedliche Erwartungen daran, wie die Automatisierung mit ihnen kommuniziert. Die Präsentationsschicht bietet mehrere Oberflächen: GUI-Portale, Command Line Interface (CLI), Chatops-Integrationen, alle gestützt durch dieselbe API und dasselbe Zugriffsmodell, mit Status, der an die Zielgruppe ausgespielt wird, die die Aktion initiiert hat.

3. Die Plattform bidirektional mit externen Systemen verbinden und Ergebnisse über die Kanäle zurückliefern, die Konsumenten bereits nutzen. Das Anwendungsteam arbeitet bereits in ServiceNow. Die CI/CD-Pipeline läuft bereits in einem Versionskontrollsystem. Die Plattform sollte ihnen begegnen, wo sie sind: Anfragen aus ihren Systemen empfangen und Ergebnisse an dieselben Systeme zurücksenden, ohne ein neues Werkzeug in ihren Workflow zu erfordern.

8.1.3. Säulen#

Drei Säulen stützen diese Ziele, eine pro Funktionalität:

1. API-Schicht: das Fundament: versionierte, authentifizierte, RBAC-durchgesetzte, stabile Verträge. Authentifizierung und Mandantentrennung werden hier durchgesetzt, nicht pro Werkzeug. Jede andere Oberfläche ist darauf aufgebaut.
2. Client-Schnittstellen: alle konsumentenorientierten Oberflächen (GUI-Portale, CLI, Mobil, Chatops) als unterschiedliche Formfaktoren derselben zugrundeliegenden API.
3. Integrationen und Benachrichtigungen: externe Systemverbindungen (ITSM, CI/CD-Pipelines, Messaging-Systeme) und ausgehende Ergebnislieferung (Webhooks, Callbacks, Push-Benachrichtigungen).

8.1.4. Geltungsbereich#

Die Präsentationsschicht stellt bereit. Sie produziert nicht.

Im Geltungsbereich:

• Die API-Schicht: Authentifizierung, Autorisierung, Versionierung und Rate-Limiting für alle Konsumenten
• Client-Schnittstellen, die auf dieser API aufgebaut sind: GUI-Portale, CLI, Chatops, mobile Oberflächen
• Externe Integrationen: ITSM-Workflows, CI/CD-Pipeline-Hooks, Webhook-Lieferung
• Ausgehende Benachrichtigungen: Status-Callbacks, Push-Alerts, Messaging-Kanal-Ereignisse
• Betriebsdashboards, wenn sie für Nicht-Ingenieur-Zielgruppen bereitgestellt werden (Zugangskontrolle, Zielgruppen-Scoping und Portal-Einbettung; die zugrundeliegende Metriken-Architektur gehört zu Kapitel 6)

Außerhalb des Geltungsbereichs:

• Datenerzeugung (Observability, Kapitel 6)
• Konfigurations-Rendering und Template-Verarbeitung (Source of Truth, Kapitel 4)
• Workflow-Ausführung und Audit-Datensatz-Erzeugung (Orchestrator, Kapitel 7)

Eine Präsentationsschicht, die beginnt, Geschäftslogik anzuhäufen (entscheiden, welchen Workflow ausführen, Eingaben gegen das Netzwerkmodell validieren, Workflow-Zustand verwalten), ist zu etwas anderem geworden. Diese Verantwortlichkeiten gehören in den Orchestrator und die Source of Truth. Wenn das Portal beginnt, Netzwerkrichtlinien oder Wiederholungslogik zu kodieren, ist die architektonische Grenze zusammengebrochen und die Plattform wird schwierig unabhängig weiterzuentwickeln.

8.2. Funktionalitäten#

Die drei Ziele und Säulen werden durch drei Kernfunktionalitäten realisiert, wobei jede direkt auf ein Ziel und eine Säule abbildet:

1. API-Schicht: der Vertrag und das Zugriffsmodell für alle Konsumenten
2. Client-Schnittstellen: die auf diesem Vertrag aufgebauten Oberflächen
3. Integrationen und Benachrichtigungen: die Verbindungen zu externen Systemen und ausgehende Lieferung

graph LR

    subgraph Ziele
        direction TB
        A1[Stabile authentifizierte API und konsistentes Zugriffsmodell]
        A2[Richtige Oberfläche für jeden Konsumententyp]
        A3[Bidirektionale Integration mit externen Systemen]
    end

    subgraph Säulen
        direction TB
        B1[API-Schicht: versioniert, authentifiziert, stabil]
        B2[Client-Schnittstellen: GUI, CLI, Chatops, Mobil]
        B3[Integrationen und Benachrichtigungen: ITSM, CI/CD, Webhooks]
    end

    subgraph Funktionalitäten
        direction TB
        C1[API-Schicht]
        C2[Client-Schnittstellen]
        C3[Integrationen und Benachrichtigungen]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. API-Schicht#

Kapitel 4 behandelte die eigene API der SoT ausführlich: wie Automatisierungssysteme Intents abfragen, die Konsumierungsmuster (REST, GraphQL, Webhooks) und das Lese-/Schreibmodell für die Netzwerkkonfiguration. Die hier besprochene API dient einem anderen Zweck: Sie ist der nach außen gerichtete Vertrag für Konsumenten der gesamten Automatisierungsplattform. Während die SoT-API antwortet auf “Wie soll das Netzwerk aussehen?”, antwortet die API der Präsentationsschicht auf “Was macht die Automatisierungsplattform und wie interagiere ich mit ihr?” Beide können REST-APIs sein; sie bedienen unterschiedliche Zielgruppen mit unterschiedlichen Zugriffsmodellen.

Die API der Präsentationsschicht ist das Fundament. Jede Konsumentenoberfläche (Portal, CLI, ITSM-Formular, Chatops-Bot, KI-Agent) ist ein Aufrufer dieser Schicht. Authentifizierung, RBAC, Versionierung und Rate-Limiting werden hier durchgesetzt. Wenn sie schlecht gestaltet wird, erbt alles darüber ihre Probleme.

Die Präsentations-API sollte keine internen Bausteinschnittstellen spiegeln. Das Bereitstellen eines /v1/sot/vlans/-Endpunkts, der direkt zur SoT-API proxied, oder eines /v1/orchestrator/jobs/-Endpunkts, der Orchestrator-Job-IDs umhüllt, koppelt Konsumenten an interne Implementierungsdetails. Wenn man einen Baustein durch einen anderen ersetzt, muss jede CI/CD-Pipeline, die diese IDs gespeichert hat, aktualisiert werden. Die Präsentations-API sollte stattdessen Konzepte auf Plattformebene bereitstellen: einen /v1/requests/-Endpunkt, der eine Serviceanfrage unabhängig davon repräsentiert, welcher Orchestrator sie verarbeitet hat, einen /v1/services/vlan/-Endpunkt, der den aktuellen Zustand eines VLANs aus SoT und Observability aggregiert liefert, ohne zu offenbaren, welcher Baustein welches Datenelement geliefert hat. Konsumenten erhalten einen stabilen Vertrag; die interne Implementierung kann sich dahinter frei weiterentwickeln.

8.2.1.1. Was die API bereitstellt#

Die API stellt zwei Kategorien von Endpunkten bereit:

• Lese-Endpunkte: Workflow-Status und -Historie, Audit-Datensätze, Geräte- und Dienstzustand aggregiert aus den SoT- und Observability-Bausteinen. Das sind die Abfragen, die das Anwendungsteam verwendet, um den Anfragestatus zu prüfen, der Prüfer verwendet, um einen Änderungsdatensatz zu überprüfen, und das Monitoring-System verwendet, um den Plattformzustand zu verifizieren.

• Schreib-Endpunkte: Einen Workflow auslösen, eine Serviceanfrage einreichen, eine ausstehende Schranke genehmigen oder ablehnen, einen laufenden Job abbrechen. Schreib-Endpunkte erfordern stärkere Autorisierung. Unterschiedliche Rollen sollten Zugang zu unterschiedlichen Schreiboperationen haben: Ein Mitglied des Anwendungsteams kann eine Anfrage einreichen, aber keine beliebigen Workflows auslösen; ein Netzwerkingenieur kann eine ausstehende Schranke genehmigen, aber keine Workflow-Definitionen ändern.

Die Lese-/Schreib-Unterscheidung beeinflusst auch die Vertragsstabilität. Lese-Endpunkte müssen auf unbestimmte Zeit stabil bleiben: Ein Dashboard, das ein Jahr lang läuft, sollte nicht kaputtgehen, weil sich ein vorgelagertes Schema geändert hat. Schreib-Endpunkte müssen explizit versioniert werden, mit Abkündigungshinweisen vor Breaking Changes.

8.2.1.2. Versionierung und Stabilität#

Konsumentenorientierte APIs müssen versioniert werden. Die API der Präsentationsschicht ist der Vertrag; die Bausteininternen sind die Implementierung. Interne Umstrukturierungen des Orchestrators, der SoT oder der Observability-Bausteine dürfen externe Aufrufer nicht brechen.

Der Standardansatz: Versionierung durch URL-Präfix (/v1/, /v2/) oder Accept-Header, die vorherige Version für ein definiertes Abkündigungsfenster beibehalten und Breaking Changes durch ein Changelog kommunizieren. Eine CI/CD-Pipeline, die acht Monate lang /v1/workflows/trigger aufgerufen hat, sollte nicht an einem Montag feststellen, dass der Endpunkt ohne Warnung verschoben wurde.

8.2.1.3. Authentifizierung und Autorisierung#

Authentifizierung beantwortet: Wer bist du? Autorisierung beantwortet: Was darfst du tun?

Viele Teams implementieren Authentifizierung vor Autorisierung und stellen dann fest, dass “authentifiziert” und “autorisiert” unterschiedliche Probleme sind, wenn jemand siebenundvierzig Anfragen unter einem gültigen Token einreicht, den er nicht hätte haben sollen.

Authentifizierungsmuster für Netzwerkautomatisierungsplattformen:

• SSO/LDAP-Integration: der Unternehmensstandard. Ingenieure und Anwendungsteams authentifizieren sich mit ihrer Unternehmensidentität. Keine separaten Zugangsdaten zu verwalten, und die Deprovisionierung erfolgt automatisch, wenn jemand das Unternehmen verlässt.
• OAuth 2.0/OIDC: für externe Systeme und Web-Portal-Benutzer. Erzeugt kurzlebige Token statt langlebiger Zugangsdaten.
• Scope-begrenzte API-Token: für programmatischen Zugriff durch CI/CD-Pipelines und Automatisierungsskripte. Jedes Token ist auf eine bestimmte Menge von Berechtigungen mit einem definierten Ablaufdatum beschränkt. Ein von allen Konsumenten genutztes Admin-Token ist keine Authentifizierung: Es ist ein gemeinsames Passwort, das nicht widerrufen werden kann, ohne gleichzeitig alle Aufrufer zu beschädigen.

Autorisierung durch RBAC. Rollen sollten auf operative Verantwortlichkeiten abbilden, nicht auf Werkzeugfähigkeiten. Ein Ausgangsmodell für Netzwerkautomatisierung:

• read-only: beliebige Daten anzeigen, keine Aktionen auslösen
• operator: vorab genehmigte Workflows auslösen, Schranken genehmigen, Serviceanfragen einreichen
• engineer: vollständiges Workflow-Management, SoT-Schreibzugriff, alle Audit-Datensätze anzeigen
• admin: Plattformkonfiguration, Benutzerverwaltung, Zugangsdaten-Rotation

Jede Rolle erbt alle Berechtigungen der Rolle darunter. Ein Ingenieur kann alles, was ein Operator kann, plus in die SoT schreiben und Workflows verwalten.

flowchart TD
    RO[read-only]
    OP[operator]
    ENG[engineer]
    ADM[admin]

    RO -->|ergänzt: Workflows auslösen + Schranken genehmigen| OP
    OP -->|ergänzt: SoT-Schreibzugriff + Workflow-Management| ENG
    ENG -->|ergänzt: Plattformconfig + Benutzerverwaltung| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

RBAC wird an der API-Grenze durchgesetzt. Die zugrundeliegenden Bausteine sehen nur authentifizierte API-Aufrufe von der Präsentationsschicht; sie verwalten keine Konsumentenidentität unabhängig. Mandantentrennung wird durch Daten-Scoping implementiert: Jede Abfrage wird durch den organisatorischen Scope des Aufrufers gefiltert. Das Anwendungsteam für Gebäude B sollte keine Anfragen des Retail-Teams für Gebäude A sehen. Das muss von Anfang an entworfen werden. Mandantentrennung nachträglich in ein flaches Datenmodell einzubauen, ist ein schmerzhaftes Umstrukturierungsprojekt.

Der Audit-Trail sollte abgelehnte Anfragen neben genehmigten aufzeichnen. Wer was versucht hat und abgelehnt wurde, ist für die Compliance genauso wichtig wie was gestattet wurde. Die Präsentationsschicht erstellt diesen Datensatz neben dem Workflow-Audit-Trail aus Kapitel 7. Kapitel 12 erweitert dieses Modell um Secrets-Rotation, Policy-as-Code und compliance-gesteuerte Automatisierungsabläufe.

8.2.1.4. Rate-Limiting#

Automatisierte Konsumenten ohne Rate-Limits werden die Queue des Orchestrators erschöpfen. Der Siebenundvierzig-Anfragen-Vorfall erforderte keinen bösartigen Akteur: nur ein motiviertes Team, eine URL und keine Drosselung.

Rate-Limiting an der API-Grenze: Pro-Token-Limits (Anfragen pro Minute pro Konsument), Burst-Limits (gleichzeitige laufende Anfragen) und operationsspezifische Limits (ein Firmware-Upgrade-Workflow sollte nie mehr als eine Instanz pro Gerät gleichzeitig ausführen). Rate-Limit-Antworten sollten HTTP 429 mit einem Retry-After-Header zurückgeben, kein stilles Queue-Auffüllen, das sich Stunden später als Timeout äußert.

8.2.1.5. REST, GraphQL und die MCP-Schnittstelle#

REST ist der Standard. Es ist einfacher zu versionieren, zu verstehen und zu cachen als GraphQL. Netzwerkautomatisierungsteams brauchen selten die konsumentengesteuerte Abfrageflexibilität von GraphQL und zahlen einen erheblichen Betriebskostenaufwand für die zusätzliche Komplexität. Die Ausnahme: Wenn die Plattform eine große Anzahl von unterschiedlichen Konsumententypen mit deutlich verschiedenen Abfragemustern bedient, kann GraphQL Over-Fetching und die Notwendigkeit mehrerer spezialisierter Endpunkte reduzieren. Es ist eine gerechtfertigte Wahl; es ist selten die richtige erste Wahl.

Die Model Context Protocol (MCP)-Schnittstelle ist die KI-Oberfläche der Präsentationsschicht. Genau wie menschliche Operatoren über CLI auf die Plattform zugreifen und Anwendungsteams über das Portal, greifen Large Language Model (LLM)-basierte Agenten über einen MCP-Server darauf zu. Der Agent ruft Tools auf (Workflow-Status abfragen, eine Behebung auslösen, das Audit-Protokoll lesen) in welcher Reihenfolge sein Reasoning es erfordert, unterliegt demselben RBAC-Modell wie jeder andere Aufrufer. Das verbindet sich direkt mit dem agentischen Orchestrierungsmuster, das in Kapitel 7 (Abschnitt 7.2.7) eingeführt wurde: Der MCP-Server der Präsentationsschicht ist die Schnittstelle, die diese Muster über die gesamte Plattform ohne hardcodierte Integrationen zwischen dem Agenten und jedem einzelnen Baustein nutzbar macht.

REST und MCP unterscheiden sich darin, wer die Interaktion steuert. Bei einer REST-Integration weiß der Konsument im Voraus, welche Endpunkte er in welcher Reihenfolge aufrufen soll: Eine CI/CD-Pipeline ruft POST /v1/requests/vlan auf, dann pollt sie GET /v1/requests/{id} bis zum Abschluss. Die Abfolge ist im Code festgelegt. Mit MCP entscheidet ein Large Language Model (LLM)-basierter Agent zur Laufzeit, welche Tools er aufrufen soll und in welcher Reihenfolge, basierend auf dem Ergebnis jedes vorherigen Aufrufs. Der Konsument ist keine Pipeline mit einem vorbestimmten Aufrufgraphen; er ist ein Reasoning-System, das jedes Ergebnis liest, bevor es entscheidet, was als nächstes zu tun ist. Der MCP-Server definiert die verfügbaren Tools und ihre Schemas; der Agent entscheidet, wie er sie verwendet. Das macht MCP geeignet für offene operative Abfragen (“Untersuche das Konnektivitätsproblem zwischen Gebäude B und dem Kern”), die einen Entwickler erfordern würden, jede mögliche Aufrufabfolge vorauszudenken, wenn sie als REST implementiert werden. Es macht die Autorisierung auch sensibler: Ein Agent mit umfangreichem Tool-Zugriff kann Operationen auf eine Weise kombinieren, für die das Zugriffsmodell nicht explizit entworfen wurde. Das RBAC-Modell muss auf Tool-Ebene angewendet werden, nicht nur auf Server-Ebene.

8.2.2. Client-Schnittstellen#

Client-Schnittstellen sind die auf der API aufgebauten Oberflächen. Sie sind unterschiedliche Formfaktoren derselben zugrundeliegenden Plattform, jede geeignet für einen anderen Konsumententyp. Das RBAC-Modell gilt einheitlich, unabhängig davon, welche Oberfläche verwendet wird.

8.2.2.1. GUI und Self-Service-Portal#

Das Web-Portal ist die primäre Schnittstelle für Nicht-Ingenieure. Sein Gestaltungsprinzip ist progressive Offenlegung: Die richtige Menge an Informationen für die richtige Zielgruppe anzeigen, ohne die zugrundeliegende Komplexität zu exponieren.

Das Anwendungsteam sieht eine Drei-Schritt-Ansicht: Eingereicht, In Bearbeitung, Abgeschlossen, mit einem Statusdetail, das “Pre-Checks laufen auf 24 Switches” in einfacher Sprache liest, nicht AWX-Job-IDs. Der Netzwerkingenieur sieht die Pre-Check-Ergebnisse pro Gerät, die Genehmigungsschranke mit einer Genehmigen- oder Ablehnen-Aktion und die vollständige Workflow-Spur bei Bedarf. Der Admin sieht alles, einschließlich Konfigurations- und Audit-Abfragen.

Lese- und Schreibschnittstellen haben unterschiedliche Gestaltungsanforderungen. Ein reines Lese-Status-Dashboard kann relativ offen sein: Jeder Ingenieur auf der Plattform kann den aktuellen Zustand seiner Anfragen sehen. Der Schreibpfad (eine Anfrage einreichen, eine Schranke genehmigen, einen laufenden Job abbrechen) erfordert Eingabevalidierung, einen Bestätigungsschritt und eine klare Aussage darüber, was passieren wird, bevor die Aktion committet wird.

Portale werden manchmal so gebaut, dass der Einreichungs-Button auf einem neuen Serviceanfrageformular die Orchestrator-API direkt aufruft, ohne eine Validierungsschicht zwischen dem Formular und dem Workflow. Wenn ein Benutzer ein Subnetz einreicht, das mit einer bestehenden Zuweisung in Konflikt steht, kommt der Fehler als unformatierter Orchestrator-Stack-Trace zurück. Die Präsentationsschicht sollte Eingaben gegen das SoT-Modell validieren, bevor die Anfrage den Orchestrator erreicht, und einen klaren, umsetzbaren Fehler zurückgeben, wenn die Validierung fehlschlägt.

Das Adoptionsrisiko ist an der Schnittstelle am höchsten. Ein technisch korrektes Portal, das niemand verwendet, weil es nicht in die Arbeitsweise des Teams passt, liefert weniger Wert als eine einfachere Integration in dem Werkzeug, das jeder morgens öffnet. Das Anwendungsteam, das bereits in ServiceNow lebt, wird Anfragen konsequenter über ein ServiceNow-Formular einreichen als über ein neues Portal, das es lernen und separat anmelden muss. Das Engineering-Team, das bereits Slack für die Incident-Koordination verwendet, wird schneller auf Genehmigungsschranken-Benachrichtigungen über eine Slack-Nachricht reagieren als über einen Browser-Link, der zusätzliche Authentifizierung erfordert. Vertrautheit reduziert Reibung bei der Einführung und senkt Fehlerquoten im täglichen Gebrauch. Wo eine Wahl zwischen dem Aufbau einer neuen Oberfläche und dem Begegnen der Benutzer in dem Werkzeug, das sie bereits kennen, besteht, ist die Integration fast immer der richtige erste Schritt.

8.2.2.2. CLI#

Die CLI für die Automatisierungsplattform ist nicht die Geräte-CLI, die in Kapitel 9 behandelt wird. Das ist eine Befehlszeilenschnittstelle zur Plattform selbst: ein Werkzeug, das Ingenieure verwenden, um Automatisierung auszulösen, zu inspizieren und zu verwalten, ohne einen Browser zu öffnen.

Ingenieure bevorzugen CLI aus denselben Gründen, aus denen sie Shell-Skripte gegenüber GUIs für wiederkehrende Arbeit bevorzugen: Kombinierbarkeit, Geschwindigkeit und Skriptfähigkeit. Ein CLI-Befehl kann mit einem Alias versehen, in andere Befehle gepipet, über eine Geräteliste iteriert, in ein Runbook eingebaut oder neben der Infrastruktur, die er verwaltet, in ein Repository committet werden. Ein Portal-Klick nicht. Während eines Vorfalls um 2 Uhr morgens ist ein in fünf Sekunden aus dem Gedächtnis eingetippter Befehl schneller als ein Portal, das zwanzig Sekunden zum Navigieren und Authentifizieren benötigt. Für CI/CD-Pipelines erzeugt ein CLI strukturierte Exit-Codes (0 für Erfolg, nicht null für Fehler), die direkt auf die Pass/Fail-Bedingungen der Pipeline abbilden, ohne Parsing. Ingenieure vertrauen CLI-Werkzeugen auch mehr für hochriskante Operationen: Die Parameter sind in der Shell-Historie sichtbar, auditierbar und reproduzierbar.

Die CLI verdient ihren Platz auch wenn ein Portal existiert. Während eines Vorfalls um 2 Uhr morgens ist das Öffnen eines Browsers, das Anmelden, das Navigieren zu einem Workflow und das Durchklicken eines Formulars langsamer als das Ausführen eines einzelnen Befehls. Für CI/CD-Pipelines ist eine CLI rohen API-Aufrufen vorzuziehen: Sie verarbeitet Authentifizierung aus Umgebungsvariablen, produziert strukturierte Exit-Codes und gibt menschenlesbare Ausgaben, wenn etwas fehlschlägt.

Gestaltungsprinzipien für eine Automatisierungsplattform-CLI:

• Konsistente Substantiv-Verb-Befehlsstruktur (workflow run, workflow status, request list), die vorhersehbar auf API-Operationen abbildet
• Maschinenlesbare Ausgabe über ein --json-Flag, damit Pipeline-Skripte das Ergebnis parsen können
• Umgebungsabhängige Konfiguration: API-Endpunkt und Token aus einer Konfigurationsdatei oder Umgebungsvariablen gelesen, nicht in Skripte hartcodiert
• Dasselbe RBAC, das für die API gilt, gilt für die CLI: Ein Token mit Operator-Berechtigungen kann keine Admin-Operationen auslösen, unabhängig davon, welche Oberfläche verwendet wird

8.2.2.3. Instant-Messaging und Mobil#

Slack, Teams und ähnliche Plattformen erfüllen eine doppelte Rolle in der Netzwerkautomatisierung: Sie sind sowohl ein Benachrichtigungskanal (die Präsentationsschicht pusht Ereignisse in sie) als auch eine Interaktionsoberfläche (Ingenieure senden Befehle durch sie). Diese doppelte Rolle für die Architektur zu verstehen, ist wichtig: Derselbe Workspace, der Alert-Benachrichtigungen empfängt, sollte Genehmigungsabläufe unterstützen, um den Kontextwechsel für Ingenieure zu reduzieren, die diese Kanäle bereits überwachen.

Als Interaktionsoberfläche funktionieren Messaging-Plattformen durch Bots, die Konversationsbefehle in API-Aufrufe übersetzen. Der Bot ist dünn: Er parst die Nachricht, ordnet sie einem API-Aufruf der Präsentationsschicht unter der Absenderidentität zu und formatiert die Antwort für den Kanal. Drei Muster funktionieren in der Praxis gut:

• Genehmigungsabläufe: Eine Slack-Nachricht mit “Genehmigen”- und “Ablehnen”-Buttons lässt einen Netzwerkingenieur auf eine ausstehende Schranke reagieren, ohne Slack zu verlassen. Der Button-Klick ruft den API-Genehmigungs-Endpunkt mit der Ingenieur-Identität auf, aufgelöst durch die SSO-Integration der Plattform mit Slacks OAuth.
• Status-Abfragen: @netbot status app-payments gibt den aktuellen Workflow-Zustand in einer formatierten Kanalnachricht zurück.
• Schnellaktionen: @netbot compliance-check building-b löst einen leichtgewichtigen Verifizierungs-Workflow aus und postet das Ergebnis inline.

Mobile Schnittstellen bedienen eine spezifische Zielgruppe, die Portale und CLI nicht erreichen: Rechenzentrumstechniker, die körperlich vor Ort arbeiten. Ein Techniker, der eine Line-Card in einem Rack austauscht, hat keinen Laptop geöffnet. Seine Hände können beschäftigt sein, seine Position unbequem. Eine mobile App, die ihm ermöglicht, einen Gerätebarcode zu scannen, seinen aktuellen Automatisierungszustand abzurufen (von Automatisierung verwaltet, letztes Deployment vor 14 Tagen, keine ausstehenden Änderungen), einen physischen Austausch zu bestätigen und den geeigneten Behebungs-Workflow auszulösen, verbindet die physische Arbeit mit der Automatisierungsplattform ohne Rückkehr zur Workstation. Das RBAC-Modell gilt: Das Token des Technikers ist auf die Operationen beschränkt, die seine Rolle erlaubt. Die Schnittstelle ist auf feldbezogene Daten beschränkt: Geräteidentität, aktueller Zustand, ausstehende Aufgaben und einfache Auslöseaktionen, nicht die vollständige Plattformansicht.

Dasselbe RBAC-Modell gilt. Der Bot authentifiziert Ingenieure über SSO und leitet Anfragen mit einem Token weiter, das auf die Rolle dieses Ingenieurs begrenzt ist. Ein Ingenieur mit reinen Leserechten kann keinen Workflow über Slack auslösen, genauso wenig wie über das Portal.

Als Benachrichtigungsziel empfangen Messaging-Kanäle ereignisgesteuerte Updates von der Präsentationsschicht: Deployment-Abschlüsse, Fehler-Alerts, Genehmigungsschranken-Anfragen und kritische Workflow-Fehler. Benachrichtigungs-Routing ist eine Konfigurationsrichtlinie, kein hardcodiertes Mapping. Ingenieure erhalten Fehlerdetails in einem dedizierten Operations-Kanal. Anwendungsteams erhalten den Abschlussstatus über das ITSM-Ticket. Bereitschaftsingenieure erhalten kritische Fehler über PagerDuty.

Mobile Schnittstellen folgen demselben Muster. Die Einschränkung ist Bildschirmfläche und Interaktionsmodell, nicht die Architektur. Eine mobile Genehmigungsschnittstelle, die einem Ingenieur ermöglicht, eine ausstehende Schranke von seinem Telefon aus zu genehmigen, ruft dieselbe API wie das Portal auf. Das RBAC-Modell ändert sich nicht.

8.2.2.4. Wann bauen vs. eingebettete UIs akzeptieren#

Fast jeder Baustein hat bereits eine UI. AWX hat ein Workflow-Portal. Nautobot hat eine Web-Schnittstelle. Grafana hat Dashboards. Diese eingebetteten UIs sind für Engineering-Zielgruppen ausreichend, die die Plattform verstehen. Die Entscheidung, eine dedizierte Präsentationsschicht zu bauen, sollte nicht der Standard sein.

Eine praktische Entscheidungsabfolge:

1. Sind alle Konsumenten Ingenieure, die bereits die Baustein-UIs verwenden? Eingebettete UIs verwenden. Kein benutzerdefiniertes Portal bauen.
2. Müssen Nicht-Ingenieure Automatisierung anfordern oder verfolgen? Man braucht entweder ein Portal oder eine ITSM-Integration.
3. Ist ITSM bereits das, wo alle Serviceanfragen verwaltet werden? Entweder ITSM als Präsentationsschicht adoptieren oder es als primären Konsumenten integrieren. Wenn die Workflow-Engine, das Genehmigungsmodell und das Benachrichtigungssystem von ITSM für die Anfragemuster ausreichen, ITSM direkt als Präsentationsschicht nutzen: Automatisierungsaufrufe entstehen innerhalb von ITSM-Workflows, nicht aus einer separaten Schicht darüber. Wenn man einen leistungsfähigeren API-Vertrag, bausteinübergreifende Statusansichten oder RBAC benötigt, das ITSM nicht sauber durchsetzen kann, gibt eine dünne dedizierte Schicht zwischen ITSM und den Bausteinen diese Eigenschaften, während ITSM die benutzerorientierte Oberfläche bleibt.
4. Benötigt man RBAC, das mehrere Bausteine einheitlich umspannt? Man braucht eine API-Schicht mit zentralisierter Authentifizierung, unabhängig davon, welche Client-Oberflächen darauf aufgebaut werden.
5. Kann man sich langfristig verpflichten, ein benutzerdefiniertes Portal zu pflegen? Bei Unsicherheit mit der ITSM-Integration beginnen. Ein Portal nur bauen, wenn sich ITSM für die benötigten Zugriffsmuster als unzureichend erweist.
6. Müssen Konsumenten Details eingeben oder anzeigen, die ITSM-Formulare nicht darstellen können? Komplexe Eingabefelder (YAML-Snippets, Topologie-Parameter, Subnetz-Zuteilungsvorschauen), Live-Validierung gegen das SoT-Modell oder umfangreiche Statusansichten mit Drill-Down pro Gerät übersteigen typischerweise das, was ITSM-Formular-Builder sauber unterstützen. Wenn Konsumenten regelmäßig dieses Spezifitätsniveau benötigen, rechtfertigt ein benutzerdefiniertes Portal seinen Betriebsaufwand.

Das benutzerdefinierte Portal lohnt sich zu bauen, wenn Nicht-Ingenieure Zugang benötigen, den ITSM nicht sauber ausdrücken kann, oder wenn man eine einzige bausteinübergreifende Statusansicht benötigt, die keine der eingebetteten UIs bietet. Der häufigste Fehler ist, es zu bauen, bevor der Bedarf validiert wurde.

8.2.2.5. Dokumentation und Berichtswesen#

Zwei verwandte schreibgeschützte Ausgaben der Präsentationsschicht dienen Zielgruppen, die Automatisierungswissen asynchron konsumieren: Dokumentationskonsumenten (Teams, die den aktuellen Zustand der Netzwerkdienste verstehen müssen) und Berichtskonsumenten (Manager und Prüfer, die periodische Zusammenfassungen und Compliance-Nachweise benötigen).

Das Docs-as-Code-Muster findet hier Anwendung: Dokumentation, die aus Live-Plattformdaten mit Template-Sprachen (Jinja2, Markdown) generiert wird, neben dem Automatisierungscode versioniert und bei jeder Änderung neu generiert. In generierten Dokumenten eingebettete Mermaid-Diagramme können tatsächliche Topologie aus der SoT statt manuell gepflegter Zeichnungen widerspiegeln. Ebenso kann die Normalisierungslogik, die der Observability-Baustein auf Rohmetriken anwendet (behandelt in Kapitel 6), hier wiederverwendet werden: Eine Berichtsvorlage fragt dieselben normalisierten Zeitreihendaten ab, um tabellarische Zusammenfassungen für Prüfer zu erstellen, ohne die Normalisierungsarbeit zu duplizieren.

• Auto-generierte Dokumentation konvertiert Live-Plattformdaten in lesbare, teilbare Artefakte ohne manuelle Pflege. Für jeden deployten Netzwerkdienst kann ein generiertes Dokument die Service-Definition aus der SoT, den aktuellen Betriebsstatus aus Observability und die Änderungshistorie aus dem Orchestrator-Audit-Trail kombinieren. Da die Quelldaten immer aktuell sind, bleibt die Dokumentation automatisch aktuell. Workflow-Definitionen im Orchestrator sind eine weitere Quelle: Ein Dokumentationsgenerator kann aus einer Workflow-Definition ein menschenlesbares Runbook erstellen und so sicherstellen, dass das, was das Runbook beschreibt, mit dem übereinstimmt, was die Automatisierung tatsächlich tut.

• Berichtswesen dient Management- und Compliance-Zielgruppen, die periodische Zusammenfassungen statt Echtzeit-Ansichten benötigen. Wöchentliche Änderungszusammenfassungen (wie viele Workflows liefen, Erfolgsrate, durchschnittliche Dauer, berührte Geräte) fließen in Betriebsreviews. Compliance-Exporte (alle Änderungsdatensätze für einen Zeitraum, strukturiert für die Prüfungseinreichung) werden aus dem Audit-Trail des Orchestrators und dem Autorisierungsprotokoll der Präsentationsschicht zusammengestellt. SLA- und Kapazitätsberichte (Trends der Bereitstellungszeit, Fehlerquoten nach Geräteklasse, ausstehender Anfrage-Rückstand) fließen in Kapazitätsplanung und Service-Verbesserungsdiskussionen.

Betriebsdashboards erstrecken sich durch Designabsicht über beide Kapitel. Kapitel 6 behandelt die Datenarchitektur: was erfasst wird, wie es normalisiert wird, und die direkt auf Telemetrie für Engineering-Zielgruppen aufgebauten Dashboards. Die Beteiligung der Präsentationsschicht beginnt, wenn dieselben Dashboards für Nicht-Engineering-Zielgruppen bereitgestellt werden: sie in ein Self-Service-Portal einbetten, den Zugang scopen, damit Anwendungsteams nur ihre Dienste sehen, oder mobilfreundliche Ansichten für den Feldeinsatz strukturieren. Die zugrundeliegenden Metriken verbleiben im Observability-Baustein; das Zugriffsmodell und der Oberflächenkontext sind Präsentationsaufgaben.

Die Unterscheidung von Betriebsdashboards (Kapitel 6) ist der Konsument und der zeitliche Rahmen: Dashboards zeigen den aktuellen Zustand für Ingenieure, die Echtzeit-Entscheidungen treffen; Dokumentation und Berichte sind Momentaufnahmen, die asynchron von Nicht-Ingenieuren konsumiert werden. Die zugrundeliegenden Daten können dieselben sein. Die Oberfläche und der Rhythmus sind unterschiedlich.

8.2.3. Integrationen und Benachrichtigungen#

Die Präsentationsschicht verbindet sich in beide Richtungen mit externen Systemen: Sie empfängt Ereignisse, die Automatisierung auslösen, und liefert Ergebnisse zurück an die Systeme, die Anfragen initiiert haben. Hier konvergieren der Workflow des Konsumenten und der Workflow der Plattform.

Die Unterscheidung von der API-Schicht ist Richtung und Initiation. Die API-Schicht behandelt eingehende Anfragen: Ein Konsument ruft die Plattform auf und wartet auf eine Antwort. Integrationen und Benachrichtigungen betreffen die Plattform, die externe Systeme kontaktiert, die die aktuelle Interaktion nicht initiiert haben: einen Status-Update an ein ServiceNow-Ticket pushen, einen Webhook-Callback an eine CI/CD-Pipeline liefern, die asynchron wartet, ein Ereignis in einen Slack-Kanal posten, der einen bestimmten Dienst überwacht. Die API-Schicht beantwortet Aufrufe. Dieser Abschnitt sendet Ereignisse. Beide verwenden dasselbe Authentifizierungsmodell und RBAC-Grenzen; der Unterschied ist die Initiierungsrichtung. Bei kleinem Maßstab verarbeitet eine einzelne Komponente beide Muster sauber. Bei größerem Maßstab wird die ausgehende Ereignislieferung (mit ihrer Wiederholungslogik, Dead-Letter-Queues und Abonnementverwaltung) typischerweise zu einer eigenständigen Komponente mit eigenen Betriebsanliegen, weshalb dieses Modell die beiden als unterschiedliche Funktionalitäten trennt.

8.2.3.1. ITSM-Integration#

ITSM-Plattformen nehmen zwei verschiedene Positionen in einer Netzwerkautomatisierungsarchitektur ein, und die Unterscheidung ist für das Design wichtig. In der ersten Position ist die ITSM-Plattform die Präsentationsschicht: Ihre Formulare definieren die Benutzeroberfläche, ihre Workflow-Engine behandelt Genehmigungen und Benachrichtigungen, und die Automatisierungs-API wird aus ITSM-Workflows heraus aufgerufen. In diesem Modell gibt es keine externe Integration, weil ITSM nicht extern zur Präsentationsschicht ist: Es ist die Präsentationsschicht. In der zweiten Position existiert eine dedizierte Präsentationsschicht und die ITSM-Plattform ist einer der Konsumenten, mit denen sie synchronisiert: Anfragen kommen über ITSM-Webhooks an und Status-Updates fließen zurück in ITSM-Tickets. Eine dritte Rolle ist ebenfalls üblich: ITSM als SoT-Datenquelle. Wenn die CMDB maßgebliche Asset- oder Service-Datensätze enthält, kann die SoT sie als föderierte Datenquelle abfragen (behandelt in Kapitel 4), aber ITSM in dieser Rolle spielt keine Rolle in der benutzerorientierten Automatisierungsschnittstelle.

Der Rest dieses Abschnitts beschreibt das Integrationsmuster (zweite Position). Das ITSM-als-Präsentationsschicht-Muster (erste Position) ist die richtige Wahl, wenn die Workflow-Engine, das Genehmigungsmodell und das Benachrichtigungssystem der ITSM-Plattform für die Anfragemuster ausreichen und man vermeiden möchte, eine separate Schicht zwischen Benutzer und Bausteine einzuführen.

ITSM-Integration ist das, was man baut, wenn Konsumenten nicht wissen müssen sollen, dass die Automatisierungsplattform existiert. Das Anwendungsteam arbeitet bereits in ServiceNow. Die nützlichste Schnittstelle ist die, die sie bereits verwenden.

Ein ServiceNow-Formular für “Neue Netzwerkservice-Anfrage” erfasst genau die Felder, die das SoT-Modell benötigt, und reicht sie in dem strukturierten Format ein, das die API-Schicht erwartet. Das Formular ist die Präsentationsschicht; der Konsument sieht den API-Aufruf nie. Bei der Einreichung validiert die Präsentationsschicht den Payload gegen das SoT-Datenmodell, authentifiziert den Service-Account-Token, den die ITSM-Integration verwendet, und leitet die Anfrage an den Orchestrator weiter.

Nachdem die Anfrage ausgelöst wurde, sollte das Ticket den Workflow-Zustand nahezu in Echtzeit widerspiegeln: “SoT-Validierung abgeschlossen,” dann “Pre-Checks laufen: 24 Switches,” dann “Genehmigungsschranke: ausstehende Ingenieur-Freigabe,” dann “Abgeschlossen: 24/24 Switches konfiguriert.” Diese bidirektionale Synchronisation ist komplexer als ein einmaliger Webhook. Sie erfordert, dass die Präsentationsschicht Orchestrator-Status-Ereignisse abonniert und diese in Ticket-Updates übersetzt, wobei ein dauerhaftes Ereignisabonnement oder ein polling-basierter Abgleicher verwendet wird.

In vielen Organisationen ist das ITSM-Ticket der Change-Management-Datensatz. Die Präsentationsschicht muss sicherstellen, dass das Ticket genug Informationen enthält, um die Change-Management-Anforderungen zu erfüllen, auch wenn der maßgebliche Audit-Trail im Orchestrator lebt. Die beiden Datensätze dienen unterschiedlichen Zielgruppen: Das ITSM-Ticket dient dem Anforderer und seinem Manager; der Orchestrator-Audit-Datensatz dient dem Netzwerkingenieur und dem Compliance-Prüfer.

ITSM-Integration hat Grenzen. Sie ist geeignet für strukturierte, formulargesteuerte Anfrage-Workflows mit definierten Zuständen. Sie ist nicht geeignet für Echtzeit-operative Abfragen, komplexe Workflow-Spur-Inspektion oder Power-User-Operationen, bei denen Ingenieure schnell iterieren müssen. Die Plattform so entwerfen, dass ITSM die Mehrheit der Nicht-Ingenieur-Anfragen abdeckt und eine CLI oder ein Portal den Rest.

8.2.3.2. CI/CD-Pipeline-Integration#

Eine Deployment-Pipeline, die Netzwerkressourcen bereitstellt, ruft die Präsentationsschicht-API bei einem definierten Schritt auf, übergibt strukturierte Eingaben und blockiert, bis ein Erfolgs- oder Fehlerergebnis zurückgegeben wird. Die Pipeline läuft unter einem Service-Account mit einem scope-begrenzten Token: ausreichende Berechtigungen, um den Netzwerk-Workflow auszulösen und seinen Status zu lesen, nicht mehr.

Das ist auch der Punkt, an dem die CLI ihren Platz in automatisierten Kontexten verdient. Ein Pipeline-Schritt, der netauto workflow run vlan-deploy --params params.json --wait ausführt, ist einfacher zu debuggen, einfacher zu versionieren und einfacher zu ersetzen als ein roher HTTP-Aufruf, der den API-Payload inline konstruiert. Der strukturierte Exit-Code der CLI bildet direkt auf die Pass/Fail-Bedingung des Pipeline-Schritts ab.

8.2.3.3. Push-Benachrichtigungen und Webhook-Lieferung#

Wenn ein Workflow abgeschlossen wird, eine Genehmigungsschranke erreicht oder fehlschlägt, benachrichtigt die Präsentationsschicht die richtige Zielgruppe über den richtigen Kanal. Benachrichtigungs-Routing ist eine Richtlinienentscheidung, kein hardcodiertes Mapping. Ingenieure erhalten Fehlerdetails in einem dedizierten Slack-Kanal. Anwendungsteams erhalten den Abschlussstatus über das Ticket-Update. Bereitschaftsingenieure erhalten kritische Fehler über PagerDuty. Die Routing-Regeln sind Konfiguration, kein Code.

Webhook-Lieferung ist das ausgehende Gegenstück zu eingehenden Webhooks. Ein Aufrufer, der beim Auslösen eines Workflows eine Callback-URL registriert hat, erhält das Ergebnis über HTTP POST, wenn der Workflow abgeschlossen ist. Liefergarantien, Wiederholungsrichtlinie bei Fehlern und Payload-Schema sind Teil des API-Vertrags. Ein Callback, der still fehlschlägt (keine Wiederholung, kein Protokoll, kein Alert), ist schlimmer als gar kein Callback, weil der Aufrufer davon ausgeht, dass das Ergebnis zugestellt wurde.

8.2.4. Lösungslandschaft#

Die hier aufgeführten Werkzeuge sind Beispiele zu Erläuterungszwecken, keine Empfehlungen. Diese gegen die Fähigkeiten des Teams, das vorhandene Tooling und die betrieblichen Rahmenbedingungen abwägen.

Das Präsentationskapitel hat eine andere Beziehung zur Lösungslandschaft als jedes andere Kapitel in Teil 2. Es gibt fast keine Werkzeuge, die ausschließlich als Präsentation existieren. Jeder Baustein hat bereits eine UI. Die architektonische Frage ist nicht “Welches Präsentationswerkzeug soll ich verwenden?”, sondern: Wann akzeptiere ich die eingebetteten UIs jedes Bausteins und wann baue ich eine dedizierte Präsentationsschicht darüber?

Zwei Modelle koexistieren in reifen Automatisierungsplattformen.

• Eingebettetes Modell: Die eingebaute UI jedes Bausteins für seine Zielgruppe verwenden. Ingenieure nutzen das Orchestrator-Portal für das Workflow-Management, die SoT-Web-UI für das Inventar, die Observability-Dashboards für den Netzwerkzustand. Das funktioniert, wenn alle Konsumenten Ingenieure sind, die das Tooling verstehen, und wenn keine bausteinübergreifenden Ansichten benötigt werden. Der Betriebsaufwand ist gering: keine zusätzlichen Systeme zu betreiben.

• Dediziertes Präsentationsmodell: Eine Schicht über den Bausteinen bauen oder adoptieren, die eine einheitliche Erfahrung bietet. Notwendig, wenn Nicht-Ingenieure Zugang benötigen, wenn man bausteinübergreifenden Status in einer einzigen Ansicht benötigt oder wenn die RBAC-Anforderungen nicht sauber auf die eingebauten Berechtigungen einzelner Werkzeuge abbilden.

Das Verstehen, was sich in den eingebetteten UIs befindet, ist wichtig für Anpassungsentscheidungen. NetBox ist auf Django (Python) aufgebaut; seine Web-Schnittstelle und REST-API sind Django-Views und Django-REST-Framework-Endpunkte. Nautobot teilt dieselbe Herkunft. Infrahub verwendet FastAPI. Die “Präsentationskomponente” dieser SoT-Werkzeuge ist ein ausgereiftes Web-Framework: anpassbar durch Plugins, benutzerdefinierte Views und Serializer-Erweiterungen. Das ist gleichzeitig seine Stärke (gut dokumentiert, produktionsreif) und seine Einschränkung (man passt innerhalb eines Frameworks an, das primär für den SoT-Anwendungsfall entworfen wurde, nicht für den Self-Service-Portal-Anwendungsfall).

Die ITSM-Zeile in der obigen Tabelle repräsentiert ITSM als Präsentationsschicht, nicht als externe Integration. Wenn eine Organisation auf ServiceNow oder Jira Service Management als Einstiegspunkt für alle Serviceanfragen standardisiert hat, ist ITSM die Präsentationsschicht. Die Automatisierungs-API ist das, was ITSM intern als Teil seiner eigenen Workflows aufruft; kein separates Gateway sitzt zwischen dem Benutzer und ITSM. Das Gateway sitzt zwischen ITSM und den nachgelagerten Bausteinen.

Ein architektonisches Prinzip, das sich durch alle Ansätze zieht: Die Präsentationsschicht sollte dünn sein. Sie ist eine Oberfläche, kein System. Geschäftslogik gehört in den Orchestrator und die SoT. Die Präsentationsschicht übersetzt, authentifiziert und routet. In dem Moment, in dem sie beginnt, Automatisierungsentscheidungen zu treffen, ist die Grenze zusammengebrochen.

8.3. Implementierungsbeispiel#

8.3.1. Zwei Oberflächen, drei Zielgruppen, eine Plattform#

Wir haben das Campus-Netzwerk durch den gesamten Teil 2 verfolgt. Die VLAN-Serviceanfrage für app-payments wurde in der SoT in Kapitel 4 modelliert, vom Executor in Kapitel 5 deployed, von Observability in Kapitel 6 validiert und vom Orchestrator in Kapitel 7 end-to-end koordiniert. Was nie adressiert wurde, ist, wie drei verschiedene Zielgruppen mit diesem Workflow interagieren.

In diesem Campus besteht die Präsentationsschicht aus drei Komponenten. ServiceNow ist die primäre Schnittstelle für die breitere Organisation: Anwendungsteams reichen Anfragen ein und verfolgen den Status vollständig innerhalb von ServiceNow, das als Teil seiner eigenen Workflow-Automatisierung durch die API der Präsentationsschicht routet. Ein benutzerdefiniertes Portal mit einer Audit-Ansicht dient den Engineering- und Compliance-Zielgruppen: Netzwerkingenieure prüfen Pre-Check-Ergebnisse und handeln dort auf Genehmigungsschranken, und Sicherheitsprüfer fragen zusammengesetzte Änderungsdatensätze über die schreibgeschützte Audit-Schnittstelle ab. Beide Oberflächen teilen dieselbe API-Schicht, die innerhalb der Präsentationsschicht selbst sitzt und Authentifizierung, RBAC und Versionierung durchsetzt, bevor eine Anfrage die zugrundeliegenden Bausteine erreicht.

Die drei Zielgruppen

• Das Anwendungsteam reicht Anfragen über ein ServiceNow-Formular ein. Sie wollen wissen, wann der Dienst bereit ist und was passiert ist, wenn er fehlgeschlagen ist. Sie sollten AWX oder Nautobot nie öffnen müssen. ServiceNow ist ihre Präsentationsschicht; die Plattform-API ist etwas, das sie nie sehen.

• Der Netzwerkingenieur erhielt während des Workflows eine Genehmigungsschranken-Benachrichtigung (Kapitel 7, Schritt 3). Er muss die Pre-Check-Ergebnisse für die 24 Ziel-Switches sehen, genehmigen oder ablehnen und das Ergebnis inspizieren können. Seine Schnittstelle ist das benutzerdefinierte Portal: detaillierter als das ServiceNow-Formular, aber noch auf den Scope seines Teams beschränkt.

• Der Sicherheitsprüfer kommt drei Monate später mit einer Frage: Wer hat dieses VLAN angefordert, wer hat es genehmigt, welche Version des Deployment-Workflows lief und was war der Vorher-Nachher-Zustand der betroffenen Switches? Seine Schnittstelle ist die Audit-Ansicht des Portals: schreibgeschützt, ohne die Möglichkeit, irgendetwas auszulösen.

Die zwei Präsentationsoberflächen

Die API-Schicht ist das gemeinsame Fundament innerhalb der Präsentationsschicht. Sowohl ServiceNow als auch das benutzerdefinierte Portal routen jede Anfrage durch sie, bevor irgendetwas die zugrundeliegenden Bausteine erreicht. Sie setzt drei rollenbasierte Tokens durch: Das Operator-Token des Anwendungsteams (eigene Anfragen lesen, neue Anfragen einreichen), das Engineer-Token des Netzwerkingenieurs (alle Anfragen in seinem Scope lesen, Schranken genehmigen oder ablehnen) und das schreibgeschützte Token des Prüfers (Audit-Datensätze über die gesamte Plattform abfragen, kein Schreibzugriff). Keine Oberfläche umgeht sie.

flowchart TD
    subgraph Konsumenten
        AT[Anwendungsteam]
        NE[Netzwerkingenieur]
        SA[Sicherheitsprüfer]
    end

    subgraph PL[Präsentationsschicht]
        SN[ServiceNow]
        PORTAL[Benutzerdefiniertes Portal]
        API[API-Schicht: Auth · RBAC · Versionierung]
    end

    subgraph Blocks[Plattform-Bausteine]
        ORC[Orchestrator]
        SOT[Source of Truth]
        OBS[Observability]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

Schritt 1: ServiceNow als Oberfläche des Anwendungsteams

Das Anwendungsteam füllt ein ServiceNow-Formular aus: Dienstname (app-payments), Subnetzgröße (/24), Gebäude (building-b), anforderndes Team und geschäftliche Begründung. Bei der Einreichung ruft ServiceNow die Plattform-API-Schicht direkt als Teil seiner eigenen Workflow-Automatisierung auf. Die API-Schicht validiert den Payload gegen das SoT-Datenmodell, authentifiziert den Service-Account-Token, den ServiceNow verwendet, und leitet die strukturierte Anfrage an den Orchestrator weiter.

Wenn die Validierung fehlschlägt (zum Beispiel entspricht das angeforderte Gebäude keiner Site in der SoT, oder die Subnetzgröße steht in Konflikt mit einer bestehenden Zuweisung), gibt die API-Schicht sofort einen strukturierten Fehler zurück, bevor ein Orchestrator-Workflow gestartet wird. ServiceNow aktualisiert das Ticket mit einem klaren Fehlergrund: “building-c nicht in der Site-Registrierung gefunden” oder “Subnetz /24 steht in Konflikt mit bestehender Zuweisung 10.22.14.0/24 in building-b.” Das Anwendungsteam sieht die Ablehnung in seinem Ticket und kann die Anfrage korrigieren, ohne einen Netzwerkingenieur einzubeziehen. Es wird kein partieller Workflow-Zustand erzeugt und kein Saga-Rollback benötigt, weil der Workflow nie gestartet wurde.

Während der Workflow fortschreitet, abonniert die Präsentationsschicht Orchestrator-Status-Ereignisse und übersetzt sie in ServiceNow-Ticket-Updates: “SoT-Validierung abgeschlossen,” “Pre-Checks laufen: 24 Switches,” “Genehmigungsschranke: ausstehende Ingenieur-Freigabe,” “Abgeschlossen: 24/24 Switches konfiguriert.” Das Anwendungsteam beobachtet, wie sich sein Ticket aktualisiert, ohne zu wissen, dass der Orchestrator, die SoT oder AWX existieren.

Schritt 2: Die Genehmigungsschranken-Oberfläche

Wenn der Workflow die Genehmigungsschranke erreicht, pausiert der Orchestrator und sendet ein Ereignis. Die Präsentationsschicht empfängt es, identifiziert den für Gebäude B verantwortlichen Netzwerkingenieur und sendet eine Genehmigungsanfrage an seinen Slack-Kanal mit einem direkten Link zur Schranken-Überprüfungsseite. Die Überprüfungsseite zeigt die Pre-Check-Ergebnisse pro Switch: welche bestanden, welche fehlgeschlagen, welche übersprungen wurden und warum. Der Ingenieur genehmigt oder lehnt über das Portal ab. Die Aktion wird protokolliert: Wer genehmigt hat, von welcher Schnittstelle, zu welcher Zeit, unter welchem Token.

Schritt 3: Die Audit-Ansicht

Drei Monate später fragt der Sicherheitsprüfer die API der Präsentationsschicht ab: “Zeige mir den vollständigen Änderungsdatensatz für VLAN app-payments, Gebäude B.” Der schreibgeschützte Audit-Endpunkt aggregiert drei Quellen:

• Den Ausführungsdatensatz des Orchestrators (Kapitel 7, Abschnitt 7.2.4): welche Workflow-Version lief, jede Schritt-Eingabe und -Ausgabe, alle Saga-Kompensationsaktionen
• Den SoT-Änderungsdatensatz (Kapitel 4): Vorher-Nachher-Zustand der VLAN-Definition
• Das eigene Autorisierungsprotokoll der Präsentationsschicht: Wer die Anfrage eingereicht hat, welches Token verwendet wurde, wer die Schranke genehmigt hat und wann

Die Antwort ist ein strukturiertes Dokument, das der Prüfer dem Change-Management-Datensatz beifügen kann. Keiner der drei zugrundeliegenden Bausteine wurde so entworfen, dass er diesen zusammengesetzten Datensatz unabhängig produziert. Die Präsentationsschicht hat ihn aus ihren individuellen APIs unter dem schreibgeschützten Token des Prüfers zusammengestellt.

Was das demonstriert

Derselbe zehnstufige Workflow aus Kapitel 7 diente drei verschiedenen Zielgruppen über zwei Präsentationsoberflächen, ohne dass eine dieser Zielgruppen die zugrundeliegende Plattform verstehen musste. ServiceNow diente der breiteren Organisation: Das Anwendungsteam verfolgte seine Anfrage über ein Werkzeug, das es bereits täglich verwendet, ohne Kenntnis von AWX, Nautobot oder dem Orchestrator dahinter. Das benutzerdefinierte Portal diente den Engineering- und Compliance-Zielgruppen: Der Netzwerkingenieur prüfte eine saubere Genehmigungsschnittstelle, die auf die Anfragen seines Teams beschränkt war, und der Prüfer fragte einen zusammengesetzten Änderungsdatensatz ab, der aus drei Bausteinen über eine einzige schreibgeschützte Ansicht zusammengestellt wurde. Eine API-Schicht, die dasselbe Zugriffsmodell für beide Oberflächen durchsetzte, machte die Plattform zugänglich, ohne sie sichtbar zu machen.

8.4. Zusammenfassung#

Die Presentation (Layer)-Schicht ist der letzte Baustein in Teil 2, und sie ist am wahrscheinlichsten als Nachgedanke behandelt zu werden. Die Bausteine darunter verrichten die substantielle Arbeit: Intention halten, Änderungen anwenden, Ergebnisse validieren, Workflows koordinieren. Die Präsentationsschicht produziert nichts davon. Aber ohne sie ist die Plattform nur für die Menschen zugänglich, die sie gebaut haben, und jede andere Zielgruppe bleibt von einem menschlichen Mittelsmann abhängig.

Die API-Schicht ist das Fundament. Authentifizierung und Autorisierung, die an der API-Grenze durchgesetzt werden (nicht pro Werkzeug), sind das, was zugängliche Automatisierung von gefährlicher Automatisierung trennt. Versionierung und stabile Verträge sind das, was eine Plattform von einem Prototyp trennt, der seine Aufrufer bei jedem Update bricht. Die Model Context Protocol (MCP)-Schnittstelle erweitert dasselbe Zugriffsmodell auf Large Language Model (LLM)-basierte Agenten und macht die Plattform für die agentischen Orchestrierungsmuster verfügbar, die in Kapitel 7 eingeführt und in Kapitel 17 weiterentwickelt werden.

Client-Schnittstellen sind unterschiedliche Formfaktoren derselben zugrundeliegenden API. Ein GUI-Portal mit progressiver Offenlegung dient Nicht-Ingenieuren, die Automatisierung anfordern und verfolgen müssen, ohne die Plattform zu verstehen. Eine CLI dient Operatoren, die Geschwindigkeit, Skriptfähigkeit und CI/CD-Integration benötigen. Chatops- und mobile Oberflächen dienen Genehmigungsabläufen und Incident-Abfragen. Die Entscheidung darüber, welche Oberflächen zu bauen sind, sollte einer bewussten Abfolge folgen: mit eingebetteten Baustein-UIs für Engineering-Zielgruppen beginnen, mit ITSM integrieren, wenn Nicht-Ingenieure Automatisierung anfordern müssen, ein benutzerdefiniertes Portal nur bauen, wenn ITSM sich als unzureichend erweist.

Integrationen und Benachrichtigungen schließen die Schleife, die der asynchrone Antwortvertrag aus Kapitel 7 geöffnet hat. Der Orchestrator produziert ein Workflow-Ergebnis; die Präsentationsschicht liefert es an die Zielgruppe, die die Aktion ausgelöst hat, über den Kanal, den sie bereits verwendet. Bidirektionale ITSM-Synchronisation, Webhook-Callbacks und Push-Benachrichtigungen sind keine Komfortfunktionen. Sie sind das, was Automatisierung für die Menschen sichtbar macht, die von ihr abhängen.

Das Campus-Szenario zeigte dies in der Praxis: ein Workflow, drei Zielgruppen, zwei Präsentationsoberflächen. ServiceNow diente der breiteren Organisation als eigene Präsentationsoberfläche, rief die Plattform-API direkt auf und spiegelte den Status über vertraute Ticket-Updates wider. Das benutzerdefinierte Portal diente den Engineering- und Compliance-Zielgruppen: Der Netzwerkingenieur prüfte eine saubere Genehmigungsschnittstelle, die auf die Anfragen seines Teams beschränkt war, und der Prüfer fragte einen zusammengesetzten Änderungsdatensatz ab, der aus dem Orchestrator, der SoT und dem eigenen Autorisierungsprotokoll der Präsentationsschicht zusammengestellt wurde. Dieselbe API-Schicht setzte das Zugriffsmodell für beide durch. Die Plattform war nicht länger unsichtbar.

Mit der Präsentationsschicht an ihrer Stelle hat Teil 2 alle sieben Bausteine des NAF-Frameworks behandelt. Das nächste Kapitel wendet sich dem einen Baustein zu, auf den all diese Automatisierung letztendlich einwirkt: Das Netzwerk selbst, behandelt in Kapitel 9.

💬 Found something to improve? Send feedback for this chapter