Integration Architecture

Interface Ownership Working Skill

Map every interface in your landscape to a named owner for business decisions, technical decisions, and operational response. Close ownership gaps before they become incidents.

What this skill is for

This skill helps you inventory all interfaces in a landscape, classify them by type and criticality, assign four distinct ownership roles per interface, document the ownership matrix, identify gaps, and establish a change process so ownership stays current.

When to use this skill

  • Post-merger or platform consolidation requires an interface cleanup.
  • A new project is handing over integrations to AMS or operations.
  • Recurring interface failures sit unresolved for days because teams point at each other.
  • An audit finding notes missing governance or unclear responsibilities for integrations.
  • A schema change breaks a consumer and no one knows who approved it.
  • The AMS team receives alerts but does not know which business unit to contact for data validation.

Real work situations

Situation 1: IDoc failures sit unresolved

Customer master IDocs from SAP to a CRM are failing with status 51. The SAP basis team says the IDoc is correct. The CRM team says the data is wrong. The middleware team says the routing is fine. After three days, a sales manager complains that new customers cannot be created. No one was clearly responsible for end-to-end resolution.

Situation 2: Schema change without approval

A developer adds a mandatory field to a customer API to support a new project. Two downstream systems start failing because they do not send the new field. There is no documented owner who approves schema changes, so the developer assumed it was safe.

Situation 3: AMS team lacks business context

The AMS monitoring tool alerts on a failed file transfer. The AMS operator can see the technical error but does not know which business process is affected, who validates the file content, or whether the failure is urgent. The alert sits unactioned for hours.

Inputs required

  • Interface inventory: all known APIs, IDocs, RFCs, file transfers, events.
  • System landscape diagram showing sources, targets, and middleware.
  • Organizational chart or team directory.
  • Existing SLAs or operational agreements.
  • Incident history for the last 6–12 months (to find pain points).
  • Middleware configuration: queues, topics, routing rules.
  • Project documentation for recent or upcoming interfaces.

Questions to ask

  • Who approves schema or format changes for this interface?
  • Who is paged when this interface fails outside business hours?
  • Who validates data quality at the source system?
  • Who validates data quality at the target system?
  • Who pays for middleware capacity increases for this interface?
  • Who decides when this interface is deprecated?
  • Who ensures the interface complies with security and privacy policies?
  • What is the escalation path when the owner is unresponsive?

Working method

  1. List all interfaces. Gather from middleware, SAP (WE02, SM58, BD87), API gateways, file transfer logs, and project docs. Include active, dormant, and planned interfaces.
  2. Classify by type and criticality. Tag each interface as API, IDoc, RFC, file, or event. Rate criticality by business impact: critical, major, minor, dormant.
  3. Define four ownership roles per interface.
    • Business owner: approves schema changes, validates semantics, decides deprecation.
    • Technical owner: designs and maintains the interface, approves implementation changes.
    • Operational owner: monitors, responds to alerts, performs first-line diagnosis.
    • Consumer representative: speaks for downstream consumers, validates compatibility.
  4. Document in ownership matrix. Record interface ID, source, target, direction, type, criticality, and all four owners. See template below.
  5. Identify gaps. Flag interfaces with missing owners, conflicting claims, or owners who have left the organization.
  6. Assign missing owners. For each gap, propose an owner based on domain, system, or incident history. Get written confirmation.
  7. Define change process. Document how ownership is updated when systems change, teams reorganize, or projects end.
  8. Validate with incident drill. Simulate a failure for a critical interface. Verify that the operational owner knows who to contact and that the business owner can make decisions.

Decision rules

  • If an interface has no business owner, assign one from the source data domain.
  • If the operational owner is missing, default to the AMS or integration operations team.
  • If a consumer is external or from another business unit, designate a consumer representative.
  • If ownership is disputed between two teams, escalate to the architecture or governance board.
  • If an interface is critical and unowned, treat it as a P1 risk and assign an interim owner within 24 hours.
  • If an owner changes, update the matrix within 48 hours and notify all stakeholders.
  • If an interface has no consumer for 12 months, initiate deprecation review with the business owner.
  • If an interface crosses legal entities or countries, assign a compliance owner in addition to the four standard roles.

Deliverables

  • Interface Ownership Matrix — All interfaces with owners and criticality. Link to Interface Ownership Matrix template.
  • Ownership Gap Report — Missing owners, risks, and assignment actions.
  • RACI for Interface Changes — Who is responsible, accountable, consulted, informed for schema, infra, and deprecation changes.
  • Runbook for Ownership Updates — How to update the matrix when teams or systems change.

Templates

Interface Ownership Matrix (Compact)

---
artifact: Interface Ownership Matrix
id: IOM-001
date: YYYY-MM-DD
scope: System landscape | Project | Domain
---

## Interfaces

| Interface ID | Source | Target | Direction | Type | Criticality | Business Owner | Technical Owner | Operational Owner | Consumer Rep | SLA | Status |
|--------------|--------|--------|-----------|------|-------------|----------------|-----------------|-------------------|--------------|-----|--------|
| IF-001 | SAP S/4 | Salesforce | Outbound | API | Critical | MDM Lead | Integration Lead | AMS Team | CRM Lead | 4h | Active |
| IF-002 | SAP S/4 | Warehouse | Outbound | IDoc | Major | Logistics Mgr | SAP Dev | AMS Team | WH Ops | 8h | Active |
| IF-003 | Bank | SAP S/4 | Inbound | File | Critical | Finance Mgr | SAP Dev | AMS Team | Treasury | 2h | Active |

## Ownership gaps

| Interface ID | Missing Role | Risk | Action | Assignee | Due Date |
|--------------|--------------|------|--------|----------|----------|
| IF-004 | Business Owner | No one approves schema changes | Assign from Sales domain | Integration Lead | YYYY-MM-DD |
| IF-005 | Operational Owner | Alerts go to unmonitored mailbox | Route to AMS Team | AMS Manager | YYYY-MM-DD |

## Unowned interfaces


## Change process


## Review frequency

Quality checklist

  • Every active interface has a named business owner.
  • Every active interface has a named technical owner.
  • Every active interface has a named operational owner.
  • Critical interfaces have a consumer representative.
  • Change process is documented and communicated.
  • Matrix is reviewed at least quarterly.
  • Ownership gaps have assigned resolution owners and due dates.
  • Incident drill confirmed that operational owners know escalation paths.

Common mistakes

  • Mistake: Assigning only a technical owner and forgetting the business owner. Consequence: Schema changes are approved by developers who do not understand business semantics.
  • Mistake: Creating the ownership matrix once and never updating it. Consequence: Owners have left, teams have reorganized, and the matrix is fiction.
  • Mistake: Assuming the vendor or external partner owns everything. Consequence: Internal accountability is missing; the vendor is blamed for internal decisions.
  • Mistake: No escalation path when the owner is unresponsive. Consequence: Incidents stall because the primary owner is on vacation and no one knows who covers.
  • Mistake: Ownership matrix stored in a personal file or wiki with no access for AMS. Consequence: The people who need it during an incident cannot find it.

Agent instructions

  • Gather context first: Collect the interface inventory, system landscape, org chart, and incident history before assigning owners.
  • Use the Interface Ownership Matrix template: Produce a filled matrix, not a list of recommendations.
  • Ask who is paged, who approves, who validates: These questions reveal the real owners better than org charts.
  • Identify gaps explicitly: List every interface with a missing role, the risk, and the proposed assignee.
  • Avoid generic language: Do not write "clear ownership is important." Write "Assign the MDM Lead as business owner for IF-001."
  • Link to Atlas diagnostics: Reference SAP Interface Monitoring Diagnostics and SAP Integration Error Handling Diagnostics for operational context.

Related skills

Related Atlas pages

Verification status and limitations

This skill is a public working interpretation of integration ownership practice. It is not official SAP, ITIL, or vendor documentation. The four-role model is a practical simplification; some organizations may need additional roles (security, compliance, legal). The skill assumes the interface inventory can be discovered from middleware and SAP; in heavily decentralized landscapes, discovery may require manual effort.