Why Your SAP Integration Backlog Never Shrinks — and How Self-Describing Data Eliminates It
Onibex Team
Last updated: July 2026
In most enterprises, every new analytics requirement that touches SAP becomes an IT project: an ABAP developer maps fields, a data engineer writes schemas, weeks pass, and the business moves on. Metadata-driven integration removes that bottleneck — every payload leaving SAP carries its own technical description, and the streaming platform generates target schemas automatically. No mapping projects, no drift, no backlog.
The 3 key points:
- The SAP integration bottleneck is architectural, not organizational — hiring more engineers to write more mappings scales the problem, not the solution
- SAP already describes its own data (types, lengths, business keys); platforms that carry that metadata downstream eliminate manual schema work and the drift that comes with it
- A full deployment — SAP components, cloud gateway, streaming layer, live data in your destination — fits in roughly 15 working hours instead of a six-month program
Why does every SAP data request become an IT project?
Because the architecture requires a human translation step between SAP's world and the cloud data world — every single time. Ask any CIO what happens when a business team requests a new SAP-fed dashboard, and the honest answer is a multi-week cycle that repeats for every report.
- Someone identifies which SAP tables and fields are needed — often a functional consultant.
- An ABAP developer builds or extends an extractor.
- A data engineer defines target schemas and mappings by hand.
- Integration testing, transport management, deployment windows.
- Six to twelve weeks later, the data arrives — if nothing changed in between.
Multiply that by every report, every custom Z table, every acquisition, every S/4HANA migration wave, and SAP integration backlogs grow faster than teams can burn them down. The constraint isn't talent; it's the mapping step.
There is a second cost that rarely makes the business case but always makes the incident report: hand-maintained schemas drift. SAP entities get extended; the mapping doesn't. Pipelines break silently, dashboards show stale numbers, and trust in the data platform erodes — the most expensive thing a data platform can lose.
What is metadata-driven SAP integration?
It is an architecture where SAP data carries its own description. SAP already knows everything about its own data — its Data Dictionary holds every field's type, length, description, and which fields form the business key of every record. Traditional integration throws that away and asks humans to reconstruct it; metadata-driven integration keeps it.
In the OneConnect architecture, every payload that leaves SAP carries two things:
- The data itself — the changed business records (a sales order, a delivery, an invoice).
- The metadata — SAP's own technical description of every field in those records.
The receiving platform — the Smart Gateway, running on Kubernetes in your cloud of choice — reads that description and generates the target schemas automatically, in real time, registering them with full governance in a schema registry. When SAP changes, the schemas evolve on their own, with compatibility guarantees. When a business team adds a custom field, it simply appears downstream.
What does this mean in practice?
| Traditional SAP integration | Metadata-driven (OneConnect) |
|---|---|
New field or Z table = IT ticket + development cycle |
Appears downstream automatically |
| Mapping documents maintained by hand | No mapping documents exist |
| Schema drift breaks pipelines silently | Governed, automatic schema evolution |
| Data engineering team is the bottleneck | SAP functional team models; the platform adapts |
| Weeks to months per request | Hours |
| Deep SAP + cloud expertise on every change | Low-code modeling inside SAP, no ABAP |
The modeling itself happens inside SAP, in a low-code visual tool — business entities are composed by connecting tables and CDS Views with simple join operations, in a single SAP transaction. No ABAP development, no external mapping layer.
Which three capabilities separate scalable SAP integration from technical debt?
Three questions predict whether an architecture scales or accumulates debt: does it preserve business keys, does it handle documents, and what happens when SAP changes.
1. Does it preserve business keys — automatically?
SAP knows which fields uniquely identify every record. A platform that carries that knowledge downstream keeps your target system as a true mirror of SAP: updates update, deletes delete, and there are never duplicates. OneConnect derives keys directly from SAP's own metadata, which enables genuine real-time INSERT, UPDATE, and DELETE propagation into every supported destination.
2. Does it handle documents, not just tables?
SAP thinks in business documents — a sales order is a header, line items, partners, and conditions, together. OneConnect delivers both a table format (one governed stream per SAP table, ideal for lakehouse modeling) and a document format called KDOC (the complete nested business document, an evolution of the IDOC concept for the streaming era) from the same modeling effort.
3. What happens when SAP changes?
This question predicts your five-year cost curve. If the answer involves the words "change request," the integration will always be a bottleneck. If the answer is "the platform detects the change and evolves the target automatically, with backward compatibility," integration stops being a constraint on the business.
What is the business case for metadata-driven integration?
The value is not elegant engineering — it is that it removes an entire category of recurring work and risk. No schema-mapping projects. No mapping maintenance. No drift-related incidents. No dependency on scarce dual-skilled (SAP + cloud) engineers for routine changes. The people you have stop translating and start delivering.
That is why a full deployment fits in roughly 15 working hours under Onibex's 15-Hour Business Value Challenge, instead of the six-month integration program teams have learned to expect. And "destination of your choice" is meant literally:
| Category | Destinations |
|---|---|
| Cloud data warehouses & lakehouses | Snowflake, Databricks, Google BigQuery, Microsoft Fabric, ClickHouse |
| Operational databases | SAP HANA, Microsoft SQL Server, PostgreSQL, IBM DB2 |
| Data lakes & object storage | Amazon S3, Google Cloud Storage |
Because schemas are generated from SAP's metadata rather than hand-mapped per target, adding a new destination is a configuration choice, not an engineering effort — the same governed SAP data product can land in your lakehouse, your operational database, and your object store at once.
Key takeaways
- The SAP integration bottleneck is architectural, not organizational. More engineers writing more mappings scales the problem.
- SAP already describes its own data. Platforms that carry that metadata downstream eliminate manual schema work — and the drift, incidents, and reconciliation that come with it.
- Business keys and delete-awareness are non-negotiable if you want a warehouse that mirrors SAP rather than approximates it.
- Ask vendors what happens when SAP changes. The answer tells you whether you're buying a solution or a future backlog.
- Time-to-data is the real KPI. Weeks-to-months versus hours changes which projects are even feasible.
Frequently asked questions
What is metadata-driven SAP integration?
An architecture in which every data payload leaving SAP includes SAP's own technical description of its fields (types, lengths, business keys), allowing the receiving platform to generate and evolve target schemas automatically — with no manual mapping. It is the approach implemented by Onibex OneConnect.
Why do traditional SAP data pipelines break so often?
Because hand-maintained schemas and mappings drift out of sync with a living SAP system. Every SAP extension or upgrade risks a silent mismatch. Self-describing data removes the mapping layer where that drift occurs.
Does this require ABAP development for every new data requirement?
No. Entities are modeled visually inside SAP with a low-code tool — connecting tables and CDS Views through joins — and the platform handles everything downstream.
Which target platforms are supported?
A broad set across three categories: cloud warehouses and lakehouses (Snowflake, Databricks, Google BigQuery, Microsoft Fabric, ClickHouse), operational databases (SAP HANA, Microsoft SQL Server, PostgreSQL, IBM DB2), and data lakes / object storage (Amazon S3, Google Cloud Storage). Adding a destination is a configuration choice, not a new integration project.
How fast can this be deployed?
A production-grade pipeline from SAP into a cloud data platform is typically live in about 15 working hours — the premise of the 15-Hour Business Value Challenge.
If your SAP integration backlog keeps growing and you want to see metadata-driven integration running on your own SAP data, ask Onibex about the 15-Hour Business Value Challenge: onibex.com