
CAP oder RAP - Eine Sicht aus dem Business
Immer wieder wird über RAP, CAP oder Beides diskutiert, doch wie sieht es eigentlich mit dem Business aus? Welche Anforderungen und Punkte solltest du neben den Features eigentlich noch bedenken?
Inhaltsverzeichnis
In diesem Artikel wollen wir uns einmal CAP und RAP aus Sicht des Business und der eigentlichen Kosten anschauen und mit einigen Beispielen in die Details gehen.
Einleitung
Wir denken den Vergleich vom Cloud Application Programming Model (CAP) und dem ABAP RESTful Application Programming Model (RAP) gab es nun schon zur Genüge und es gibt auch zahlreiche Blogs im Internet dazu. Dabei wird aber meist auf die gleichen Facetten geschaut, wie Entwicklungsgeschwindigkeit, Innovationen, Flexibilität und Einstiegskosten. Wir erwähnen deshalb die Einstiegskosten und nicht die Kosten, da diese ebenso skalieren können wie der Verbrauch, was du am Ende des Artikels in einem Beispiel erhältst.
In diesem Artikel möchten wir einmal aus dem Fokus des Business auf die Use-Cases schauen und welche Anforderungen Unternehmen noch an ihre Strategie haben sollten, um effizient Erweiterungen bauen zu können.
Foto von Hunters Race auf Unsplash
Business
Wie sieht also der Blick aus dem Business auf das Thema aus? Hier gibt es einige zentrale Eigenschaften, die Anwendungen mitbringen sollten. Diese schauen wir uns einmal in den nächsten Abschnitten an.
Stabilität
Wer kennt es nicht? Wir loggen uns in unsere SAP System ein und dort gibt es die eine Eigenentwicklung, die bereits seit 25 Jahren läuft. Sie ist nicht besonders hübsch und nach heutigen Entwicklungsstandards veraltet. Doch die Anwendung benötigt kaum Wartung, läuft zuverlässig und bildet das Rückgrat unserer Business Prozesse.
- ABAP ist seit vielen Jahren im Einsatz, abwärtskompatibel und damit sehr stabil. Damit spart sich das Business Entwicklungskapazitäten und muss nicht immer Entwickler vorhalten, die sich um die Anwendungen kümmern.
- Der CAP Stack beinhaltet sehr viele Komponenten, die sogenannten Abhängigkeiten (Dependencies). Hat eine Komponenten einen Bug, kann es schnell mal passieren, dass man sehr viele Komponenten aktualisieren muss. Das kann zu neuen Fehlern führen und die Anwendung sollte im Nachgang noch einmal intensiv getestet werden.
Sicherheit
Bisher waren SAP Systeme vor allem hinter der Firewall aufgestellt, damit gab es in den meisten Fällen weniger Anforderungen an die Sicherheit der Systeme und Anwendungen. In den letzten Jahren ist das Thema Sicherheit aber weiter in den Fokus gerückt und sollte heute durch die SAP Basis und den SAP Entwickler ernst genommen werden. Immer öfter sind Systeme daher über die Cloud erreichbar, was eine schnelle Reaktion bei CVE Veröffentlichungen bedeutet.
- Bei SAP Systeme kann daher der Patch meist direkt durch die Basis per SAP Note eingespielt werden, was das Problem zentral für Komponenten und Anwendungen behebt. In speziellen Fällen müssen Anwendungen noch einmal angepasst und deployt werden, was vor allem im Bereich Fiori passieren kann.
- CAP Anwendungen basieren auf zahlreichen Komponenten von SAP und der Open Source Community. Es sollten daher regelmäßig die Abhängigkeiten (Dependencies) geprüft werden. Hier ist eine Prüfung pro Anwendung nötig, was im Problemfall nach sich zieht, dass viele Anwendungen überprüft, gepatcht und getestet werden müssen.
Hinweis: Mittlerweile gibt es für die BTP einen Service, der die eigenen Anwendungen nach Sicherheitslücken durchleuchtet und meldet. Allerdings gelten trotzdem die gleichen Punkte wie oben bei der Behebung der Probleme.
Support
Setzt das Unternehmen vor allem auf Inhouse Entwicklung, dann gibt es bereits gut ausgebildete SAP und ABAP Experten, die einfach Anwendungen schnell und effektiv umsetzen können. Damit können die Entwickler auch einen guten Support leisten. Bei kleinen und mittleren Unternehmen gibt es meist kaum oder keine Entwickler, die mit den Anforderungen des Business zu kämpfen haben. Schauen wir uns dann noch einmal die Punkte Stabilität und Sicherheit an, dann müssen im Notfall die Entwickler schnell reagieren können.
- Bei einem ABAP Environment als Software as a Service (SaaS) Lösung, kümmert sich SAP um das Patch Management und die Sicherheit. Das macht es für kleinere Kunden attraktiver, da sich die zusätzlichen Basis Admins und Entwickler nicht unbedingt benötigt.
- Im Bereich von CAP müssen sich die Entwickler um die Anwendungen kümmern, diese aktuell halten und Probleme mit den Abhängigkeiten selbst lösen. Dafür muss dann entsprechendes Personal im Unternehmen oder als Dienstleister bereitstehen.
Verfügbarkeit
Wie sieht es eigentlich mit der Verfügbarkeit der beiden Entwicklungsmodelle aus? Können wir damit Side-by-Side und auch On-Prem entwickeln? Nicht jeder Use-Case und jede Erweiterung wird heutzutage in der BTP entwickelt, da es vom Szenario nicht immer Sinn ergibt und manchmal sogar eher kontraproduktiv ist (siehe Übersicht).
- RAP gibt es aktuell in der BTP als ABAP Environment und in jedem ABAP System, wie der Public Cloud, Private Cloud oder dem klassischen On-Prem System. Allerdings solltest du auch das passende S/4HANA Release haben, damit wichtige Features verfügbar sind.
- CAP ist aktuell nur in der BTP verfügbar. Möchtest du Clean Core in deinem Core System entwickeln, dann steht dir hier nur ABAP zur Verfügung. In diesem Fall müsstest du beide Entwicklungsmodelle lernen.
Daten
Schauen wir uns einmal die Daten an, die wir für unsere Erweiterungen benötigen. Wie sieht es hier mit dem Zugriff und der Geschwindigkeit aus? Grundsätzlich sollten Entwickler heute auf OData als Standardprotokoll setzen, wenn sie Daten aus einem On-Prem System lesen wollen. Entsprechende Standard APIs sollte es hier von SAP genügend geben und können im Business Accelerator Hub gefunden werden. Beide Ökosysteme bieten auch RFC als Protokoll zur Anbindung, auch da seit einer Weile in der Public Cloud BAPIs von außen aufrufbar sind. Für eine noch schnellere Integration bietet sich die Replikation von Daten an. Auf dem ABAP Environment einfach umsetzbar und auch in CAP möglich, wenn du eine HANA Datenbank verwendest.
- Aktuell arbeitet SAP aber auch an den External Entities mit der Nutzung von SQL Services. Damit lassen sich in Zukunft native CDS Modelle Side-by-Side erstellen mit einer sehr einfachen und schnellen Integration. Das würde die langsamen OData Services bei der Integration ablösen und die Replikation nicht nötig machen.
- Mit CAP lassen sich OData Services sehr einfach und nativ in das Projekt einbinden und verwenden. Damit sind die Integration und Nutzung besonders einfach.
Foto von Kenny Eliason auf Unsplash
Enablement
Wie sieht es eigentlich mit dem Enablement der Entwickler aus und wo findest du aktuell ausgebildete Kollegen? Dazu schauen wir uns weitere Facetten an.
Business Prozesse
Da wir uns im Bereich der Business Software bewegen, sind bestimmte Prozesse bereits für uns definiert. Hier ein Customizing im Prozess, da eine vordefinierte API für die Nutzung.
- Grundsätzlich haben die meisten ABAP Entwickler ein gutes Prozess Know How, wenn es um die Arbeit in einem spezifischen Modul geht. Der Entwickler kennt das Datenmodell und kann damit neue Anwendungen modellieren.
- Ein Web- oder JavaScript Entwickler muss auch erst einmal ins Datenmodell und die Standardkonzepte eines SAP Systems eingearbeitet werden.Grundsätzlich findet man hier zwar schneller einen Entwickler als einen neuen ABAP Entwickler, die Ausbildung kostet dann allerdings auch noch einmal.
Experte
Grundsätzlich haben wir die Erfahrungen gemacht, dass ein Entwickler in seinem Leben zwar viele Programmiersprachen lernen kann, aber meist nur eine Sprache wirklich vollständig durchdringen kann. Wir denken, dass CAP und RAP gelernt werden können, um Anwendungen effizient bauen zu können. Doch wie sieht es dann mit dem Thema Unit Testing aus? Versteht der Entwickler auch die entsprechenden Frameworks, kann er die Performance optimieren und jegliche Fehler analysieren? Die tiefe Einarbeitung kostet sehr viel Zeit und du solltest viel Erfahrung in dem Bereich sammeln. Keinem Unternehmen helfen halbe Entwickler, die beide Modelle nur halbwegs gut beherrschen. Daher sollte ein Experte seinen Fokus auf ein Model legen, um es effizient zu beherrschen und bestmöglichen Support leisten zu können.
Clean Core
Aktuell ist das TOP Thema in der SAP Welt Clean Core, gefolgt von der Business Technology Platform (BTP). Dabei wird oft der Clean Core im gleichen Atemzug wie BTP genannt, was im Moment aber nur die halbe Wahrheit ist. Die Entwicklungen im Core System bleiben erst einmal, da sich Historie nicht so schnell migrieren lässt. Gleichzeitig müssen bestimmte Erweiterungen weiterhin im Core umgesetzt werden, da sie Side-by-Side keinen Sinn ergeben. Daher wir das Knowhow der ABAP Entwickler weiterhin benötigt und im gleichen Schritt müssen sich die Entwickler ebenfalls mit Clean Core und ABAP Cloud beschäftigen. Das Upskilling in diesem Bereich kostet viel Zeit, Fokus und Geld. Daher können die Skills am einfachsten im ABAP Environment wiederverwendet werden und sich so die Entwickler gegenseitig unterstützen.
Infrastruktur
Je nachdem welches Szenario du in der BTP verwenden möchtest, benötigst du eine passende Infrastruktur. Transport Service, CI/CD, HTML5 Repository, Cloud Foundry und weitere. Möchtest du beide Modelle betreiben, dann benötigst du eine entsprechende Infrastruktur, die aber eher abhängig vom Szenario sind.
- Das ABAP Environment hat bereits viele Services im Bauch, die durch die ABAP Runtime ausgeliefert werden. Egal ob Application Job, Application Log, Notification über Mail, Transport über Software Komponenten (SWC) oder Einbindung ins Launchpad. Damit sind in einem BTP Services bereits zahlreiche Bibliotheken und Funktionen enthalten.
- Für die CAP Entwicklung benötigst du für viele Bestandteile erst einen Service in der BTP, die zwar zu Beginn recht wenig kosten, aber später auch entsprechend Skalieren können. Den Logging Service, Transport Service, Integration Suite oder Work Zone. Für viele Bestandteile einer integrierten Lösung musst du auch die passenden Services haben.
Innovation
Grundsätzlich muss man sagen, dass die Möglichkeiten von CAP und dem angeschlossenen Open Source System für JavaScript viel breiter aufgestellt sind, als die Re-Use Libraries in ABAP es könnten. Allerdings hat diese Flexibilität auch ihre Schattenseiten, da du dir damit die Dependency-Hölle ins Haus holst. Ist ein Projekt mit einer Backdoor, einem Virus, Schadcode oder anderen Fehlern behaftet, solltest du schnell reagieren können, um alle CAP Apps zu patchen und testen zu können.
Das Business hat nicht immer Zeit, jedes halbe Jahr die Anwendungen zu testen oder das Geld, so oft die Anwendungen zu prüfen, ohne das neue Features entwickelt werden. Schließlich kostet die Beauftragung ebenfalls Geld, wo vielleicht die RAP Anwendung auf der anderen Seite keinen Patch benötigt und Jahre lang stabil laufen kann, ohne das Probleme entstehen.
Community
Wie sieht es eigentlich in der Entwicklercommunity im SAP Ökosystem aus? SAP macht jedes Jahr die "Developer Insights Survey", was die aktuellen Programmiersprachen in der Community sind.
Die letzten Jahre war aber eigentlich immer klar ABAP auf dem ersten Platz, da dies die Signature Language für SAP ist. SAP sagt selbst darüber, dass sie ABAP unter Kontrolle haben in welche Richtung sie die Sprache weiterentwickeln.
Foto von Alexander Mils auf Unsplash
Kosten
Schauen wir einmal auf Beispielkosten aus zwei Unternehmen an, die beide S/4HANA Systeme betreiben, wo der Großteil der Prozessdaten liegt und die sich für unterschiedliche Extension Strategien entschieden haben. Unternehmen A geht komplett mit CAP und Unternehmen B nutzt ausschließlich die ABAP Architektur für die Side-by-Side Szenarien. Dabei wollen wir uns verschiedene Kennzahlen anschauen, um die Szenarien besser miteinander vergleichen zu können.
Zahlen
Schauen wir uns die Zahl der Apps an, dann sind im ABAP Environment auch viele Anwendungen verfügbar, die für Customizing und Einstellungen benötigt werden.
| CAP | RAP | |
|---|---|---|
| Services |
|
|
| Landschaft | 2,5 Systeme | 3 Systeme |
| Apps | 35 | 130 |
| User/Tag | 1200 | 500 |
| Kosten/Monat | 6200 EUR | 6600 EUR |
Das ABAP Environment läuft mit der System Hibernation, womit Kosten gespart werden können. Zusätzlich steht mit dem ABAP Environment auch ein Central ATC mit kostenlosen Security Checks zur Verfügung. Entweder nutzt du die Umgebung dafür oder kaufst eine Drittanbieterlösung vom Markt ein. Bei der CAP Architektur gibt es eigentlich jeweils drei Subaccounts und die entsprechenden Services. Allerdings gibt es nur zwei HANA Cloud Instanzen, deshalb wurde hier ein halber Punkt abgezogen.
Vergleich
Beim Vergleich können wir hier ganz unterschiedlich vorgehen. Die CAP Landschaft ist ganz klar komplexer, vor allem wenn wir auf den Betrieb, die Einrichtung und den Betrieb schauen. Dabei haben wir aber auch die größte Flexibilität bei der Nutzung. Das ABAP Environment ist hier recht "simpel" aufgebaut, doch uns steht alles zur Verfügung, um unsere Erweiterungen zu bauen. Die Cloud Foundry ist nötig, aber eigentlich benötigen wir sie für die Arbeit nicht (RAP).
Grundsätzlich handelt es sich hier um zwei Beispiele und nicht der Standard. Aber grundsätzlich kann man auch die Aussage entkräften, dass CAP immer billiger im Betrieb ist als RAP. Hier kommt es klar auf die Größe und Skalierung der Use-Cases an.
Abschluss
Was kannst du dir aus den Punkten mitnehmen? Hier noch eine kurze Zusammenfassung und ein persönliches Statement zu der Diskussion.
Zusammenfassung
Wir haben uns in dem Artikel die verschiedenen Punkte aus dem Business angeschaut, da vor allem am Ende das Geld zählt. Wie teuer ist der Betrieb des Modells? Wie sicher sind meine Anwendungen und Daten? Benötige ich mehr Entwickler oder Dienstleister für den Betrieb meiner Infrastruktur? Wenn du mit der Side-by-Side Entwicklung auf der BTP startest, solltest du dir Gedanken machen, wie du das Thema im Unternehmen verankern und voranbringen möchtest. Du verlässt damit auch das private Netzwerk und deine Anwendungen und Systeme stehen in der Cloud zur Verfügung. Das heißt die Verantwortung und Angreifbarkeit steigt.
Die Initialkosten für CAP sind sehr gering, allerdings können diese auch schnell in einen ähnlichen Bereich kommen, wie mit dem ABAP Environment. Die zusätzlichen Services und die Skalierung solltest du daher im Auge behalten. Im Moment hat CAP das bessere Ökosystem, wenn es um die Implementierung von AI Use-Cases geht. Meist ist nicht nur die Anbindung zum API nötig, sondern auch Services für das Zerlegen von Dateien und die Verarbeitung von Bildern, hier müsste ABAP besser werden oder die passenden BTP Services als Ergänzung zur Verfügung gestellt werden.
Persönlich
Persönlich haben wir uns vor einigen Jahren für RAP-only entschieden, da der Funktionsumfang nur minimal unterschiedlich war und die ABAP Kollegen schnell mit Features aufgeholt haben. Der Aufwand die eigenen Entwickler zu schulen und die Infrastruktur zu lernen, war uns damals, wie Heute, zu groß. Bis jetzt haben wir die Entscheidung nicht bereut und mit der neuen Clean Core Strategie und ABAP Cloud sind wir zufrieden, da wir das gleiche Modell überall einsetzen können. Dann können wir mit den gleichen Leuten die Entwicklung auf unserem On-Prem System durchführen, aber auch Szenarien in der BTP umsetzen.
Fazit
Möchtest du im Unternehmen etwas mehr Fokus haben, dann würde ich heute immer noch den Fokus auf eines der beiden Modelle setzen. Bevor CAP und RAP zu CRAP wird, solltest du im Unternehmen schauen, welche Strategie du in der Perspektive verfolgst und wie die Entwicklung von Business Anwendungen weitergehen soll. Steht das Business auch hinter den Use-Cases und wie komplex sind diese in der Umsetzung? Die Fragen helfen dir im Unternehmen den richtigen Weg zu finden.

