Integration Platform: Betriebsmodell und Verantwortlichkeiten¶
Diese Seite beschreibt die zwei Rollen der Integration Platform, die drei Betriebsmodelle, die bestimmen, wie diese Rollen zusammenarbeiten, und wer wofür verantwortlich ist. Sie erweitert die generische Aufteilung zwischen Plattform-Team und Workload-Team in Verantwortlichkeiten.
Zwei Arten von Betriebsmodell
Verwechsle nicht zwei Dinge. Das MCP-Betriebsmodell sagt, wer die Plattform betreibt: XMMS im Rahmen eines Managed-Service- Vertrags oder dein eigenes Team (Betriebsmodelle). Das Integrations-Betriebsmodell auf dieser Seite (zentral, hybrid, dezentral) sagt, wie Plattform-Engineering und Bau von Integrationen in der Organisation aufgeteilt sind. Sie lassen sich frei kombinieren.
Rollen¶
| Rolle | Besitzt | Ziele |
|---|---|---|
| Integration platform engineer | Die Integration Platform selbst: die Infrastruktur und die Shared Services, die Entwicklung und Betrieb von Integrationen unterstützen | Eine zuverlässige, leistungsstarke Plattform für viele Use Cases. Eine standardisierte Self-Service-Umgebung für Builder. Minimaler Betriebsaufwand durch Automatisierung. Compliance, Sicherheit und Observability aller Integrationen auf der Plattform. |
| Integration builder | Die Integrationen, die auf der Plattform laufen: Systeme verbinden, Daten transformieren, Workflows automatisieren | Robuste, performante Integrationen, die zum Geschäftsbedarf passen. Maximale Wiederverwendung von Plattform-Services. Kurze Time to Market. Wartbare, dokumentierte, leicht zu analysierende Integrationen. |
Beide Rollen arbeiten eng zusammen und haben unterschiedliche Ziele. Die Trennung ist gewollt, weil sie sich auf unterschiedliche Ebenen konzentrieren.
Integrations-Betriebsmodelle¶
| Modell | So funktioniert es | Stärke | Risiko |
|---|---|---|---|
| Zentral | Ein spezialisiertes Team besitzt die Plattform und baut und pflegt die Integrationen. Integration Builder sind Teil dieses Teams. | Standardisierung, Governance, Konsistenz der Plattform | Das einzelne Team wird zum Engpass für jede Anfrage. |
| Hybrid | Das Plattform-Team besitzt die Plattform und baut einige Integrationen. Builder aus Business- oder Domänenteams bauen andere. | Balance aus Kontrolle und Agilität | Braucht klare Absprachen, wer was baut. |
| Dezentral | Die Rollen sind getrennt. Das Plattform-Team entwickelt und pflegt nur die Plattform. Builder in den Fachbereichen besitzen ihre Integrationen vollständig. | Tempo und Autonomie | Fragmentierung und Inkonsistenz bei schwacher Governance. |
Die Plattform unterstützt alle drei. Die Wahl hängt von deiner Organisation ab: wo die IT verwaltet wird, wie viel Kapazität das Team hat und ob Teams außerhalb der zentralen IT Integrationen bauen können. Im zentralen Modell hat ein Team ein Backlog und muss langfristige Plattformarbeit und kurzfristige Integrationsarbeit abwägen und entscheiden, was zur Plattform gehört und was zu einem einzelnen Workload. Das Referenzdesign wurde für das zentrale Modell aufgesetzt.
Das Modell wirkt sich auch auf die Shared Services aus: Bei API Management braucht ein zentrales Modell zum Beispiel eine Instanz mit Zugriff für das zentrale Team, während ein dezentrales Modell jedem Workload einen eigenen workspace geben kann (Shared services).
Verantwortlichkeiten¶
Die Integration Platform baut auf der MCP auf, deshalb teilen sich drei Parteien die Verantwortung: das Plattform-Team, das die MCP hub und spokes betreibt, die Integration Platform Engineers und die Workload-Teams (Integration). In einer kleinen Organisation kann dasselbe Team mehr als eine Rolle ausfüllen.
| Bereich | MCP-Plattform-Team | Integration platform engineers | Integration builders (Workload-Team) |
|---|---|---|---|
| Spoke-Infrastruktur (Netzwerk, Firewall, DNS, Basisressourcen) | Ja | ||
| Spokes und spoke extensions deployen | Ja | Liefern Input für die Konfiguration der Extension | |
| Firewallregeln zu On-Premises und externen Parteien | Validiert und deployt. Besitzt einen sicheren Firewall-Zustand. | Können pull requests für bestimmte Integrationen anbieten | Können pull requests über das Integration-Platform-Team anbieten |
| Standby-Services für die Plattform (wenn vereinbart) | Ja, ab der ersten produktiven Integration. Die Integrationen selbst sind nicht abgedeckt. | ||
| Shared services (Service Bus, Event Hubs, API Management, Container Registry): deployen, skalieren, patchen | Deployt den Shared Service und sein Netzwerk im spoke für Shared Services (im Referenzdesign für Service Bus) | Betreiben und skalieren ihn (Messaging Units und API-Management-Units werden manuell skaliert) | |
| Entitäten in Shared Services (Queues, Topics, API-Definitionen) | Besitzen die Automatisierung, prüfen Änderungen | Definieren sie in Konfigurationsdateien und pull requests | |
| Mitgliedschaft in Zugriffsgruppen (wer senden oder empfangen darf) | Ja, Owner der Gruppen | ||
| Modules (Logic App, Function App, Container App, Data Factory): den Code pflegen | Ja | ||
| Modules in einen Workload-spoke deployen | Liefern Templates und pipelines | Führen das Deployment ihres spokes aus | |
| Die Integrationen (Logik, Mappings, Anwendungscode) | Ja | ||
| Data-plane-Sicherheit und Abgleich mit der Identity Governance | Ja, mit dem Security Officer | ||
| Monitoring der Shared Services und ihrer Abhängigkeiten | Ja | ||
| Monitoring und Alerting der Integration | Liefern Standard-Alerts | Ja | |
| Backup der Anwendungsdaten | Ja, siehe Verfügbarkeit |
Wo die Trennlinie verläuft
Die Regel des Referenzdesigns: Das Plattform-Team besitzt alles bis zum spoke canvas (Netzwerk, Basis- infrastruktur, das Deployment der Extensions). Die Integration Platform Engineers besitzen alles, was auf dem spoke canvas aufsetzt: die Shared Services, die Control Plane und die modules. Die Builder besitzen die Integrationen. Deine Vereinbarung kann die Linie anders ziehen. Insbesondere unterscheidet sich je nach Quelldokument, wer jeden Shared Service deployt und betreibt, prüfe es also für deine Plattform.
Referenz-RACI (Managed-Service-Modell)¶
Die Servicebeschreibung enthält ein RACI zwischen Kunde und Xebia für das Managed-Service-Modell. R responsible, A accountable, C consulted, I informed. Wenn du die Plattform selbst betreibst, wandert die Xebia-Spalte zu deinem eigenen Plattform-Team.
| Bereich | Kunde | Xebia |
|---|---|---|
| Shared services: Deployment von APIs und zugehörigen Entitäten in API Management | A, I | R, C |
| Shared services: pull requests für APIs und zugehörige Entitäten | A, R | C, I |
| Shared services: Deployment von Topics, Queues und Event Hubs | A, I | R, C |
| Shared services: pull requests für Topics, Queues und Event Hubs | A, R | C, I |
| Shared services: Deployment der Container Registry | A, I | R, C |
| Modules: Deployment von Logic App, Function App, Container App und Data Factory | A, R | C, I |
| Plattform-Services: DNS und Dokumentationserzeugung, Deployment | A, I | R, C |
| Governance: Kostenmanagement und Budgets | A, I | R, C |
| Management: Log Analytics workspace, Action Groups, Activity Log Alerts | R, A | R, C |
| Security: Defender for APIs, Advisor, RBAC, PIM | R, A | C, I |
| Plattform-Automatisierung: pipeline und Repositories der Integration Platform | A, I | R, C |
| Plattform-Automatisierung: Repositories der Integrations-Workloads | A, R | C, I |
So liest du die Zeilen „A, R“: Das Kundenteam macht die Arbeit und ist accountable, Xebia berät. In den Zeilen „A, I“ macht Xebia die Arbeit, und der Kunde ist accountable und informiert. In einem Managed-Service-Vertrag folgt die tatsächliche Aufteilung der Vereinbarung.