2026 hat KI-gestütztes Coding den Durchbruch geschafft – und das verändert auch, wie Unternehmen ihr SAP erweitern. In dieser Folge des SAP-IT-Podcasts spreche ich mit Tom Kuschel, Management- und Technologieberater bei mindsquare und zertifizierter SAP BTP Solution Architect, darüber, was mit KI bei der Entwicklung in SAP heute schon geht. Wir klären, wo Unternehmen in Sachen Clean Core stehen, warum Low-Code an Bedeutung verliert und warum ein Entwicklungsprojekt trotzdem mehr ist als Coding.
…zum Anschauen
YOUTUBE-CHANNEL abonnieren: https://www.youtube.com/@sap-it-podcast
…zum Hören
…zum Lesen
Zwischen Z-Altlasten und agilen Teams
Wie weit Unternehmen bei der Entwicklung in SAP sind, ist laut Tom sehr unterschiedlich. Die breite Masse hat einen großen, historisch gewachsenen Bestand an Z-Reports und Z-Transaktionen, der im Alltag funktioniert und heute noch keine Schmerzen verursacht. Unternehmen mit agilen Entwicklerteams und klarem Fahrplan für neue Technologien sind eher die Ausreißer.
Bewegung gibt es trotzdem: Das Clean-Core-Narrativ, also das Ziel, Systeme upgrade- und wartungssicher zu machen, treibt SAP schon seit Jahren voran. 2026 kommt mit dem Durchbruch beim KI-gestützten Coding ein zweiter Motor hinzu.
Clean Core: Erweitern, ohne den Kern anzufassen
Der SAP-Standard passt selten zu 100 Prozent zu den Prozessen eines Unternehmens. Die Lücke lässt sich auf zwei Wegen schließen: Entweder werden die Prozesse an den Standard angepasst – ein schwieriges Change-Management-Vorhaben – oder der Standard wird erweitert. Problematisch wird es, wenn dabei am Kern selbst verändert wird. Tom beschreibt das mit einem Bild: Wer „Macken und Kanten“ in den Kern schlägt, stellt beim nächsten Upgrade fest, dass die neue Hülle des Herstellers nicht mehr passt und muss jede Änderung nachprüfen.
SAP unterscheidet deshalb drei Erweiterungsmethoden. Bei der Key-User-Extensibility passen Fachanwender kleinere Dinge im Frontend selbst an. Bei der On-Stack-Extensibility werden Erweiterungen direkt im SAP-System umgesetzt. Dafür nutzt man von SAP freigegebene Erweiterungspunkte und APIs, ohne den Standard unkontrolliert zu verändern. Bei der Side-by-Side-Extensibility liegt die Erweiterung komplett getrennt auf der SAP Business Technology Platform (BTP) und kommuniziert nur über offizielle Schnittstellen mit dem Kern. Weil SAP diese Released APIs bei Upgrades mitpflegt, bleibt die Erweiterung wartungssicher.
Clean Core Architektur-Workshop: Ihre Leitplanken für saubere SAP-Erweiterungen
Clean Core ist kein Ja oder Nein mehr
Statt einer binären Einordnung nutzt SAP inzwischen ein Stufenmodell mit den Stufen A bis D: A entspricht dem Idealbild, D ist ausdrücklich nicht Clean Core, bei B und C kommt es auf den Einzelfall an. Wie hilfreich diese Einordnung ist, zeigt ein Kunde aus der Chemiebranche, der sein System vom Vorgänger geerbt hatte und kein Gefühl dafür hatte, wo es eigentlich steht.
Im Clean-Core-Assessment kombinierte Toms Team die automatisierte Auswertung mit SAP-Tools, eine Nutzungsanalyse und die fachliche Bewertung durch Berater. Dabei zeigte sich: Viele Eigenentwicklungen werden gar nicht mehr genutzt, und das Level allein sagt wenig darüber aus, wie kritisch eine Erweiterung wirklich ist. Die besonders kritischen Fälle nahm Toms Team direkt in Angriff, und nach wenigen Wochen sah das Bild deutlich anders aus.
Warum Low-Code an Bedeutung verliert
SAP hat jahrelang SAP Build Apps, hervorgegangen aus dem zugekauften AppGyver, als Drag-and-Drop-Werkzeug für schnelle Frontends beworben und es im ersten Halbjahr 2026 für viele überraschend abgekündigt. Auch Toms Team traf das mitten in einem Projekt für einen Kunden aus der Gesundheitsbranche. Tom hält die Entscheidung für konsequent: Low-Code bot immer Geschwindigkeit gegen Einbußen bei der Flexibilität und einen Lock-in ins jeweilige Ökosystem.
KI-gestützte Entwicklung liefert dieselbe Geschwindigkeit, am Ende steht aber echter Code ohne diese Kompromisse. Damit ist der bisherige Low-Code-Deal obsolet. Die betroffene Rechnungsstellungs-App ließ sich zwar kaum automatisiert überführen, doch mit Anforderungen und Konzept in der Hand brachte das Team sie mithilfe von KI-Coding-Agenten schnell wieder auf den alten Stand, heute läuft sie als Full-Code-Lösung.
Warum KI auf der BTP so gut funktioniert
Umgesetzt wurde die App als CAP-Anwendung auf der BTP, entwickelt mit Claude Code von Anthropic. Dass das so gut klappt, hat laut Tom mehrere Gründe: Die BTP ist als Cloud-Plattform per Kommandozeile offen zugänglich, und CAP gehörte zu den ersten Frameworks, für die SAP einen eigenen MCP-Server bereitgestellt hat, über den das Modell Wissen nachschlagen kann. Zudem werden CAP-Services in Java oder JavaScript geschrieben – Sprachen, die die Modelle deutlich besser beherrschen als ABAP.
Doch auch die ABAP-Welt holt auf: Mit den neuesten ABAP Development Tools gibt es inzwischen ABAP-MCPs. Tom beobachtet, dass KI-gestützte Entwicklung im zweiten Halbjahr 2026 auch dort Fahrt aufnimmt. Um bei diesem bewegten Ziel auf dem Laufenden zu bleiben, setzt er auf aktive Community-Blogs und die Erfahrung aus laufenden Projekten.
Plan machen, Plan halten, Vergangenheit aufräumen
Statt alles gleichzeitig anzugehen, empfiehlt Tom ein Drei-Phasen-Modell: Im ersten Schritt legt ein Clean-Core-Architektur-Workshop fest, welche Technologien künftig eingesetzt werden und – oft noch wichtiger – auf welche bewusst verzichtet wird. Dabei fließen der Systemzustand, die verfügbaren Ressourcen und die vorhandenen Skills ein.
KI ist dabei fester Bestandteil der Strategie. Vorab müssen allerdings Governance– und Compliance-Fragen geklärt sein: Welche KI ist im Unternehmen erlaubt, wo läuft sie und was ist ausgeschlossen? Die Antworten beeinflussen die Ergebnisse des Workshops stark, weil KI den Aufwand von Erweiterungen grundlegend verändert. Ziel sind verbindliche Leitplanken, an denen sich alle neuen Entwicklungsprojekte orientieren können.
Nach der Planung geht es darum, die vereinbarten Leitplanken bei neuen Entwicklungen konsequent einzuhalten. Bestehende Eigenentwicklungen und Altlasten werden anschließend gezielt betrachtet und schrittweise aufgeräumt. Die drei Phasen lauten damit: einen Plan machen, sich ab heute an den Plan halten und die Vergangenheit aufräumen.
Coding schrumpft, das Projekt bleibt
Wo Tom früher zehn Stunden selbst entwickelt hat, ist es heute noch etwa eine Stunde reine Coding-Arbeit. Trotzdem warnt er davor, Entwicklungsprojekte auf Coding zu reduzieren: Anforderungen erheben, vollständig testen, Rollout und Schulung bleiben Teil jedes Projekts. KI kann dabei unterstützen, aber diese Aufgaben müssen heute besser gemacht werden als je zuvor.
Gerade wenn ein Vorhaben möglichst klein gehalten werden soll, laufen diese Themen Gefahr, unter den Tisch zu fallen. Verändert hat sich vor allem der Projektalltag. Statt langer Coding-Phasen sitzt Tom heute häufiger mit dem Fachbereich vor einem schnell entstandenen Frontend, an dem sich Feedback direkt am lebenden Objekt geben lässt.
Fazit
Bei Side-by-Side-Erweiterungen auf der SAP BTP schrumpft der Coding-Anteil durch Coding-Agenten auf einen Bruchteil, Low-Code verliert dadurch seinen Vorteil, und auch die ABAP-Welt zieht nach. Der Schlüssel liegt in einer klaren Strategie: erst eine Bestandsaufnahme, dann verbindliche Leitplanken für künftige Entwicklungen inklusive KI-Governance, danach das Aufräumen der Altlasten. Wer dabei Anforderungen, Tests und Schulung weiterhin ernst nimmt, macht aus dem KI-Geschwindigkeitsgewinn eine upgradefähige und nachhaltige SAP-Erweiterung.
