Integration Platform: beheermodel en verantwoordelijkheden¶
Deze pagina beschrijft de twee rollen van het Integration Platform, de drie beheermodellen die bepalen hoe die rollen samenwerken, en wie waarvoor verantwoordelijk is. Ze vult de generieke verdeling tussen platformteam en workload team aan in Verantwoordelijkheden.
Twee soorten beheermodel
Verwar twee dingen niet. Het MCP-beheermodel zegt wie het platform beheert: XMMS onder een managed-service- contract, of je eigen team (Beheermodellen). Het integratiebeheermodel op deze pagina (centraal, hybride, decentraal) zegt hoe platform engineering en het bouwen van integraties binnen de organisatie zijn verdeeld. Ze zijn vrij te combineren.
Rollen¶
| Rol | Is eigenaar van | Doelen |
|---|---|---|
| Integration platform engineer | Het Integration Platform zelf: de infrastructuur en gedeelde services die het ontwikkelen en draaien van integraties ondersteunen | Een betrouwbaar, goed presterend platform voor veel use cases. Een self-service, gestandaardiseerde omgeving voor builders. Minimale operationele inspanning door automatisering. Compliance, security en observability van alle integraties op het platform. |
| Integration builder | De integraties die op het platform draaien: systemen verbinden, data transformeren, workflows automatiseren | Robuuste, goed presterende integraties die passen bij de bedrijfsbehoefte. Maximaal hergebruik van platformservices. Korte time to market. Onderhoudbare, gedocumenteerde integraties die makkelijk te troubleshooten zijn. |
Beide rollen werken nauw samen en hebben verschillende doelen. De scheiding is bewust, omdat ze zich op verschillende lagen richten.
Integratiebeheermodellen¶
| Model | Hoe het werkt | Sterkte | Risico |
|---|---|---|---|
| Centraal | Eén gespecialiseerd team is eigenaar van het platform en bouwt en onderhoudt de integraties. Integration builders maken deel uit van dat team. | Standaardisatie, governance, consistentie van het platform | Het ene team wordt een bottleneck voor elke aanvraag. |
| Hybride | Het platformteam is eigenaar van het platform en bouwt een deel van de integraties. Builders uit business- of domeinteams bouwen de rest. | Balans tussen controle en wendbaarheid | Vraagt om duidelijke afspraken over wie wat bouwt. |
| Decentraal | De rollen zijn gescheiden. Het platformteam ontwikkelt en onderhoudt alleen het platform. Builders in de businessunits zijn volledig eigenaar van hun integraties. | Snelheid en autonomie | Fragmentatie en inconsistentie als de governance zwak is. |
Het platform ondersteunt alle drie. De keuze hangt af van je organisatie: waar IT wordt beheerd, hoeveel capaciteit het team heeft en of teams buiten de centrale IT integraties kunnen bouwen. In het centrale model heeft één team één backlog en moet het zowel langetermijnwerk aan het platform als kortetermijnwerk aan integraties afwegen, en bepalen wat bij het platform hoort en wat bij één enkele workload. Het referentieontwerp is opgezet voor het centrale model.
Het model beïnvloedt ook de shared services: bij API Management heeft een centraal model bijvoorbeeld één instance nodig met toegang voor het centrale team, terwijl een decentraal model elke workload een eigen workspace kan geven (Shared services).
Verantwoordelijkheden¶
Het Integration Platform is gebouwd op het MCP, dus de verantwoordelijkheid wordt gedeeld door drie partijen: het platformteam dat de MCP hub en spokes beheert, de integration platform engineers en de workload (integratie)teams. In een kleine organisatie kan hetzelfde team meer dan één rol vervullen.
| Gebied | MCP-platformteam | Integration platform engineers | Integration builders (workload team) |
|---|---|---|---|
| Spoke-infrastructuur (netwerk, firewall, DNS, basisresources) | Ja | ||
| Spokes en spoke-extensies uitrollen | Ja | Leveren input voor de extensieconfiguratie | |
| Firewallregels naar on-premises en externe partijen | Valideert en rolt uit. Is eigenaar van een veilige firewallstatus. | Kunnen pull requests aanbieden voor specifieke integraties | Kunnen pull requests aanbieden via het integration platform-team |
| Standby-services voor het platform (indien afgesproken) | Ja, vanaf de eerste live integratie. De integraties zelf vallen er niet onder. | ||
| Shared services (Service Bus, Event Hubs, API Management, container registry): uitrollen, schalen, patchen | Rolt de shared service en zijn netwerk uit in de shared services spoke (in het referentieontwerp voor Service Bus) | Beheert en schaalt hem (messaging units en API Management-units worden handmatig geschaald) | |
| Entiteiten in shared services (queues, topics, API-definities) | Is eigenaar van de automatisering, reviewt wijzigingen | Definiëren ze in configuratiebestanden en pull requests | |
| Lidmaatschap van toegangsgroepen (wie kan verzenden of ontvangen) | Ja, owners van de groepen | ||
| Modules (Logic App, Function App, Container App, Data Factory): de code onderhouden | Ja | ||
| Modules in een workload-spoke uitrollen | Leveren templates en pipelines | Draaien de deployment van hun spoke | |
| De integraties (logica, mappings, applicatiecode) | Ja | ||
| Data-plane-beveiliging en afstemming op identiteitsgovernance | Ja, met de security officer | ||
| Monitoring van shared services en hun afhankelijkheden | Ja | ||
| Monitoring en alerting van de integratie | Leveren standaardalerts | Ja | |
| Back-up van applicatiedata | Ja, zie Beschikbaarheid |
Waar de scheidslijn ligt
De regel van het referentieontwerp: het platformteam is eigenaar van alles tot en met het spoke canvas (netwerk, basis- infrastructuur, de deployment van de extensies). De integration platform engineers zijn eigenaar van alles wat bovenop het spoke canvas wordt geplaatst: de shared services, het control plane en de modules. De builders zijn eigenaar van de integraties. Jouw overeenkomst kan de lijn anders trekken. Met name wie elke shared service uitrolt en beheert verschilt per brondocument, dus controleer dit voor jouw platform.
Referentie-RACI (managed-servicemodel)¶
De servicebeschrijving bevat een RACI tussen de klant en Xebia voor het managed-servicemodel. R responsible, A accountable, C consulted, I informed. Als je het platform zelf beheert, verschuift de Xebia-kolom naar je eigen platformteam.
| Gebied | Klant | Xebia |
|---|---|---|
| Shared services: deployment van API's en gerelateerde entiteiten in API Management | A, I | R, C |
| Shared services: pull requests voor API's en gerelateerde entiteiten | A, R | C, I |
| Shared services: deployment van topics, queues en event hubs | A, I | R, C |
| Shared services: pull requests voor topics, queues en event hubs | A, R | C, I |
| Shared services: deployment van de container registry | A, I | R, C |
| Modules: deployment van Logic App, Function App, Container App en Data Factory | A, R | C, I |
| Platformservices: DNS en documentatiegeneratie, deployment | A, I | R, C |
| Governance: kostenbeheer en budgetten | 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 |
| Platformautomatisering: pipeline en repositories van het Integration Platform | A, I | R, C |
| Platformautomatisering: repositories van integratieworkloads | A, R | C, I |
Zo lees je de rijen "A, R": het klantteam doet het werk en is accountable, Xebia adviseert. In de rijen "A, I" doet Xebia het werk en is de klant accountable en geïnformeerd. In een managed-service-contract volgt de feitelijke verdeling de overeenkomst.