Modern EDI team organisation

A modern EDI team in 2026 blends traditional EDI technical skills (mapping, AS2/AS4, security), SRE skills (observability, automation, incident response) and partner skills (success management, communication). This page lays out the roles, RACI and effective team topology.

Why structure the team

EDI team understructuring is one of the most frequent causes of production incidents: blurred onboarding responsibility, orphan mappings, expiring certificates without an owner, partners lost in silence after an incident. Conversely, a well-structured team:

Reduces time-to-onboard a new partner from 6 to 2-3 weeks.
Improves MTTR (Mean Time To Recovery) on incidents, sometimes by an order of magnitude.
Reduces turnover by formalising growth paths (junior → senior → tech lead → architect).
Improves partner satisfaction through a clear interface and respected SLA.

Key roles in an EDI team

EDI Engineer: masters the protocols (AS2, AS4, OFTP2, SFTP), formats (EDIFACT, X12, UBL), gateways (Sterling, OpenText, Cleo, Mendelson, Axway). Junior to senior profile.
Mapping Specialist: mapping specialist (XSLT, custom Java/Python, DataWeave, Smooks). Works on partner spec and standards conformance.
EDI Architect: overall hub vision, platform choice, integration with ERP and ESBs, roadmap. Senior profile +10 years.
EDI Operations / SRE: monitors production, manages incidents, automates runbooks, drives SLOs and error budgets.
Partner Success Manager: privileged interface with partners, follows onboarding, escalates incidents, negotiates evolutions.
EDI Security Officer: PKI responsible, certificate management, PCI/GDPR/HIPAA compliance, audit. Often shared with the global security team.
EDI Product Manager (at vendors): drives product roadmap, arbitrates priorities, monitors competitors.

Partner onboarding RACI

For each step of the onboarding playbook, a clear responsibility:

Discovery: Responsible = Partner Success Manager, Accountable = EDI Architect, Consulted = Sales, Informed = ops team.
Spec exchange: R = Mapping Specialist, A = EDI Architect, C = EDI Engineer, I = Partner Success.
Cert exchange: R = EDI Security Officer, A = EDI Architect, C = EDI Engineer, I = Partner Success.
AS2/AS4 setup: R = EDI Engineer, A = EDI Architect, C = EDI Security, I = Partner Success.
Testing: R = EDI Engineer + Mapping Specialist, A = EDI Architect, C = Partner, I = Partner Success.
Go-live: R = EDI Operations / SRE, A = EDI Architect, C = EDI Engineer, I = everyone.
Monitoring: R = EDI Operations / SRE, A = EDI Architect, C = Partner Success, I = partner.

Team Topologies applied to EDI

The Team Topologies model from Skelton and Pais distinguishes four team types:

Stream-aligned teams: aligned to a value stream (a business domain, a partner type). Ex: "EDI retail", "EDI automotive", "EDI financial" teams.
Platform teams: provide a self-service platform to stream-aligned teams. Ex: EDI Platform team that maintains gateways, validation pipeline, observability stack.
Enabling teams: help stream-aligned teams ramp up on a topic (security, performance, AI).
Complicated-subsystem teams: maintain a complex subsystem (custom EDIFACT parser, EN 16931 validation engine).

For a modern EDI hub serving 3-10 business domains, the typical model is: 1 EDI platform team, 3-10 stream-aligned teams per domain, 1 shared security enabling team.

Platform team vs stream-aligned

The platform vs stream-aligned split is the central arbitration:

Platform team: responsible for the cross-cutting platform (ingest, pipeline, event store, monitoring, security). Provides APIs and SDKs to stream-aligned teams. Does not handle partner-specific mapping.
Stream-aligned team: responsible for mappings, onboarding and run of its domain. Consumes the platform via APIs. Maximum autonomy on its business layer.

Classic mistake: a single centralised team that does everything. It scales up to 30-50 active partners, then becomes an unbreakable bottleneck. Second trap: many stream teams without a platform team, each reinventing the plumbing.

2026 automation skills

In 2026, automation and SRE skills have become as important as pure EDI skills:

Infrastructure as Code: Terraform, OpenTofu, Pulumi to provision resources (Kafka, Vault, gateways).
GitOps: ArgoCD, FluxCD to drive Kubernetes deployments of EDI components.
CI/CD: GitLab CI, GitHub Actions, Jenkins to test mappings, validate partners, deploy.
Observability: OpenTelemetry, Grafana, Prometheus, Datadog. Reads the end-to-end trace of a message.
Scripting: Python to automate runbooks, audit, test generation.
AI-assisted: critical use of AI copilots (Cursor, Claude Code, Copilot) to accelerate mapping and maintenance.

Partner Success ownership

A too-often neglected function: who is responsible for EDI partner satisfaction? Without a designated Partner Success Manager, the partner is bounced between sales, support, technical. With a Partner Success Manager:

A single contact point for operational questions.
Monthly or quarterly reviews with a shared dashboard.
Anticipation of spec changes, migrations, certificates.
Effective escalation in case of incident.

Typical ratio: 1 PSM for 20-50 active partners depending on complexity.

Recommended size per context

Small vendor (10-30 partners): 3-5 people (Architect, 2 Engineers/Mappers, 1 shared Ops, 0.5 PSM).
Mid-size (50-200 partners): 8-15 people, with beginning of Platform / Stream differentiation.
Large group (500+ partners): 30-80 people, full Team Topologies organisation with Platform, several Stream-aligned, security Enabling team.
Multi-tenant SaaS hub (1000+ cumulative partners): 50-200 people depending on scope, with strong specialisation per domain and per function.

Foundations

Standards

Flagship messages

Tools