Integration Platform: Operating Model and Responsibilities¶
This page describes the two roles of the Integration Platform, the three operating models that decide how those roles work together, and who is responsible for what. It extends the generic split between platform team and workload team in Responsibilities.
Two kinds of operating model
Do not mix up two things. The MCP operating model says who runs the platform: XMMS under a managed-service contract, or your own team (Operating models). The integration operating model on this page (central, hybrid, decentral) says how platform engineering and integration building are divided inside the organisation. They combine freely.
Roles¶
| Role | Owns | Goals |
|---|---|---|
| Integration platform engineer | The Integration Platform itself: the infrastructure and shared services that support developing and running integrations | A reliable, high-performing platform for many use cases. A self-service, standardised environment for builders. Minimal operational effort through automation. Compliance, security and observability of all integrations on the platform. |
| Integration builder | The integrations that run on the platform: connecting systems, transforming data, automating workflows | Robust, performant integrations that fit the business need. Maximum reuse of platform services. Short time to market. Maintainable, documented, easy-to-troubleshoot integrations. |
Both roles work closely together and have different goals. The separation is deliberate, because they focus on different layers.
Integration operating models¶
| Model | How it works | Strength | Risk |
|---|---|---|---|
| Central | One specialised team owns the platform and builds and maintains the integrations. Integration builders are part of that team. | Standardisation, governance, platform consistency | The single team becomes a bottleneck for every request. |
| Hybrid | The platform team owns the platform and builds some integrations. Builders from business or domain teams build others. | Balance of control and agility | Needs clear agreements on who builds what. |
| Decentral | Roles are separate. The platform team only develops and maintains the platform. Builders in business units fully own their integrations. | Speed and autonomy | Fragmentation and inconsistency when governance is weak. |
The platform supports all three. The choice depends on your organisation: where IT is managed, how much capacity the team has, and whether teams outside central IT can build integrations. In the central model one team has one backlog and must weigh both long-term platform work and short-term integration work, and decide what belongs to the platform and what belongs to a single workload. The reference design was set up for the central model.
The model affects the shared services too: with API Management, for example, a central model needs one instance with access for the central team, while a decentral model can give each workload its own workspace (Shared services).
Responsibilities¶
The Integration Platform is built on the MCP, so responsibility is shared between three parties: the platform team that runs the MCP hub and spokes, the integration platform engineers, and the workload (integration) teams. In a small organisation the same team can fill more than one role.
| Area | MCP platform team | Integration platform engineers | Integration builders (workload team) |
|---|---|---|---|
| Spoke infrastructure (network, firewall, DNS, base resources) | Yes | ||
| Deploy spokes and spoke extensions | Yes | Provide input for the extension configuration | |
| Firewall rules to on-premises and external parties | Validates and deploys. Owns a secure firewall state. | May offer pull requests for specific integrations | May offer pull requests via the integration platform team |
| Standby services for the platform (when agreed) | Yes, from the first live integration. Integrations themselves are not covered. | ||
| Shared services (Service Bus, Event Hubs, API Management, container registry): deploy, scale, patch | Deploys the shared service and its networking in the shared services spoke (in the reference design for Service Bus) | Operates it and scales it (messaging units and API Management units are scaled manually) | |
| Entities in shared services (queues, topics, API definitions) | Owns the automation, reviews changes | Defines them in configuration files and pull requests | |
| Membership of access groups (who can send or receive) | Yes, owners of the groups | ||
| Modules (Logic App, Function App, Container App, Data Factory): maintain the code | Yes | ||
| Deploy modules into a workload spoke | Provide templates and pipelines | Run the deployment of their spoke | |
| The integrations (logic, mappings, application code) | Yes | ||
| Data-plane security and alignment with identity governance | Yes, with the security officer | ||
| Monitoring of shared services and their dependencies | Yes | ||
| Monitoring and alerting of the integration | Provide default alerts | Yes | |
| Backup of application data | Yes, see Availability |
Where the split is drawn
The rule of the reference design: the platform team owns everything up to the spoke canvas (network, base infrastructure, the deployment of the extensions). The integration platform engineers own everything that is placed on top of the spoke canvas: the shared services, the control plane and the modules. The builders own the integrations. Your agreement may draw the line differently. In particular, who deploys and operates each shared service differs per source document, so check it for your platform.
Reference RACI (managed-service model)¶
The service description contains a RACI between the customer and Xebia for the managed-service model. R responsible, A accountable, C consulted, I informed. When you manage the platform yourself, the Xebia column moves to your own platform team.
| Area | Customer | Xebia |
|---|---|---|
| Shared services: deployment of APIs and related entities in API Management | A, I | R, C |
| Shared services: pull requests for APIs and related entities | A, R | C, I |
| Shared services: deployment of topics, queues and event hubs | A, I | R, C |
| Shared services: pull requests for topics, queues and event hubs | A, R | C, I |
| Shared services: deployment of the container registry | A, I | R, C |
| Modules: deployment of Logic App, Function App, Container App and Data Factory | A, R | C, I |
| Platform services: DNS and documentation generation, deployment | A, I | R, C |
| Governance: cost management and 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 |
| Platform automation: pipeline and repositories of the Integration Platform | A, I | R, C |
| Platform automation: repositories of integration workloads | A, R | C, I |
How to read the "A, R" rows: the customer team does the work and is accountable, Xebia advises. In the "A, I" rows Xebia does the work and the customer is accountable and informed. In a managed-service contract the actual split follows the agreement.