Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht; diese Fassung ist um einen weiteren Absatz ergänzt.

Einleitung

In den letzten Jahren ist die ABAP-Entwicklung viel einfacher geworden. Die Perspektive des einzelnen Entwicklers hat sich durch fortschrittliche Tools (ADT!), bessere Online-Dokumentation und Community-Unterstützung erheblich verbessert. Als ich um 2001 mit der ABAP-Entwicklung begann, brauchte man noch eine dedizierte Maschine mit unrealistischer Hardwareausstattung, nur um das Entwicklungssystem unserer Landschaft mit einer anständigen Geschwindigkeit laufen zu lassen. Heute ist das mit einer virtuellen Maschine leicht zu bewerkstelligen, sogar auf billiger Standardhardware (was natürlich nicht für ein Produktionssystem empfohlen wird, aber hey – was glauben Sie, auf was der durchschnittliche Hudson-CI-Server in einem kleinen Entwicklungsbüro läuft?). Mit vorgefertigten Demo-Systemen ist eine vollständige ABAP-Entwicklungsumgebung für die meisten Menschen erreichbar – ich habe ich ein System innerhalb weniger Stunden installiert (einschließlich des Herunterladens von 15 GB Installationsdateien, der Einrichtung des VirtualBox-Servers und des zugrunde liegenden Betriebssystems, während ich nebenbei noch andere Dinge erledigt habe). Wenn Sie das System nicht auf Ihrer eigenen Hardware ausführen möchten, können Sie ein CAL-Konto erwerben und die Systeme auch in der Cloud ausführen.

Auch aus organisatorischer Sicht ist alles einfacher (d.h. billiger) geworden. In den meisten Fällen müssen Sie nicht mehr in große Hardware investieren (siehe oben), und es gibt Pläne (siehe unten), die Ihnen bis zu 25 Entwicklerlizenzen, einen registrierten Namensraum und Zugang zu so ziemlich allem, was Sie benötigen, zu sehr günstigen Preisen bieten. Es wurde viel unternommen, um die Eintrittsbarriere zu senken und einzelne Entwickler und möglicherweise kleine Start-up-Unternehmen dazu zu bringen, das ABAP-Ökosystem leichter zu erschließen, und ich bin sehr dankbar für all die harte Arbeit, die hinter den Kulissen geleistet worden sein muss, um dies zu verwirklichen. Wenn Sie sich mit ABAP auskennen und einige großartige Ideen für zusätzliche Produkte haben, die eine bestehende Lösung ergänzen, entwickeln Sie einfach Ihr Produkt, testen Sie es gründlich, schreiben Sie die Dokumentation, die Sie für notwendig halten, verkaufen Sie es an Ihre Kunden und liefern Sie es dann aus.

„Einfach ausliefern“ – leider ist das der eine Punkt, der immer noch leichter gesagt als getan ist. Bisher war dies kein Problem, da die ABAP-Entwicklung ohnehin nur mittleren bis großen Unternehmen zur Verfügung stand. Für ein kleines Unternehmen, das nur aus wenigen begeisterten Mitarbeitern besteht, ist die ABAP-Entwicklung jetzt recht einfach und kostengünstig geworden, während der Lieferprozess noch nicht diese Transformation durchlaufen hat. Es gibt eine Reihe von Optionen, die ich in diesem Artikel besprechen möchte. Mir ist sehr wohl bewusst, dass dies ein ziemlich langer Artikel geworden ist, aber ich hoffe, dass er die Mühe wert ist – angesichts der Diskussionen der letzten Wochen war es auf jeden Fall notwendig, ihn zu schreiben.

Die offensichtliche Lösung: „Nein. Nein, nein, nein.“

Okay, das ist keine ernsthafte Alternative. Sie könnten, wenn Sie wollen, Ihre Lösung manuell in jedes einzelne Kundensystem kopieren. Denken Sie nicht einmal daran.

Die automatisierte Lösung: „Nein.“

Es gibt ein großartiges Tool, um Entwicklungsobjekte aus dem System zu holen und wieder in das System zu bringen: SAPlink. Verstehen Sie mich nicht falsch, es ist wirklich ein großartiges Tool, wenn es von einem sachkundigen Menschen für die richtigen Zwecke eingesetzt wird. Die Bereitstellung von Software ist definitiv nicht einer dieser Zwecke.

SAPlink hat einige Vorteile, die auf den ersten Blick überzeugend erscheinen:

  • Es ist kostenlos, was immer gut ist, oder?
  • Es ist vergleichsweise einfach zu erlernen – keine komplexen Konzepte, nur Export nach XML und Reimport. Das kann jeder schnell lernen.
  • Es ist erweiterbar – wenn es nicht das unterstützt, was Sie brauchen, fügen Sie die fehlenden Teile einfach selbst hinzu.

Bei der Verwendung als Auslieferungsswerkzeug gibt es jedoch einige schwerwiegende Probleme.

  • Es wird definitiv nicht von SAP unterstützt. Einige der verfügbaren Import-/Export-Implementierungen verwenden möglicherweise nicht einmal unterstützte APIs zum Extrahieren und Einfügen von Entwicklungsobjekten – wahrscheinlich, weil es keine gibt. Während dies für die interne Nutzung von SAPlink möglicherweise kein großes Problem darstellt, ändert sich die Situation, wenn Sie ein externer Lösungsanbieter sind. Sie werden Komponenten für unternehmenskritische Systeme bereitstellen – stellen Sie sicher, dass Sie in Bezug auf Wartungsprobleme abgesichert sind.
  • Es gibt praktisch keine Integritätsprüfungen während des Export- oder Importprozesses. Beim Paketieren von Software kann viel schiefgehen, und SAPlink ist einfach nicht dafür ausgelegt, mit diesen Problemen umzugehen.
  • Es gibt keine Unterstützung für das Löschen von Objekten. Dies kommt bei der Produktwartung häufig vor – Sie benötigen eine Klasse nicht mehr und löschen sie. SAPlink kann die Klasse übertragen, aber nicht die Löschung.
  • Während des Imports findet keine Abhängigkeitsauflösung statt. Stellen Sie sich eine Klasse vor, die eine Struktur verwendet, die ein Datenelement enthält, das wiederum auf eine Schnittstelle verweist. Möglicherweise müssen Sie einige dieser Objekte in der richtigen Reihenfolge importieren, da es weitgehend vom Objekttyp-Import-/Export-Plug-in abhängt, ob Sie inaktive Objekte importieren können, die auf andere Objekte verweisen, die noch nicht existieren. Manchmal ist dies nicht möglich, und dann müssen Sie die Abhängigkeiten manuell im Auge behalten. Nicht cool.
  • Apropos Plugins: Die Unterstützung für bestimmte Objekte hängt stark davon ab, dass die Plugins korrekt funktionieren. Da die Plugins von einer Handvoll lose verbundener Freiwilliger stammen, variieren sie natürlich in der Qualität, also YMMV.
  • Einer der wichtigsten Punkte könnte sein, dass SAPlink auf der Zielseite eigentlich nichts anderes tut, als die Objekterstellung zu automatisieren. Sie können eine Klasse mit SAPlink genauso erstellen wie manuell – und umgekehrt können Sie keine (rechtlich und meistens auch technisch) Klasse erstellen, die Sie nicht auch manuell erstellen könnten. Das Das bedeutet, dass Sie Ihre Lösung in einem Namensraum entwickeln und bereitstellen müssen, der für Ihren potenziellen Kunden vollständig beschreibbar ist. Entweder Sie verwenden Y oder Z und riskieren Konflikte mit vorhandenen Kundenobjekten (abgesehen davon, dass Sie damit zeigen, dass Sie wahrscheinlich noch kein Produkt ausliefern sollten), oder Sie geben dem Kunden vollen Zugriff (Produktionsschlüssel) auf einen registrierten Namensraum, wodurch der Schutzcharakter im Grunde genommen nutzlos wird. Willkommen in der Wartungshölle – und vergessen Sie nicht, dass einige der Objekttyp-Plug-ins (noch) keine Objekte in registrierten Namensräumen unterstützen.

Im Vergleich zum Copy&Paste-Ansatz ist SAPlink sicherlich ein großer Schritt – aber für die professionelle Softwarebereitstellung ein großer Schritt in die völlig falsche Richtung.

Das etwas weniger Offensichtliche: „Keine gute Idee.“

Jeder, der sich ein wenig mit der ABAP-Umgebung auskennt, weiß, was als Nächstes kommt: Transporte. Aus meiner persönlichen Erfahrung heraus ist dies wahrscheinlich die beliebteste Methode, Add-ons bereitzustellen (im Gesundheitswesen ist dies sicherlich der Fall) – wir erhalten sogar Add-ons von den Beratungsabteilungen, die SAP so nah wie möglich stehen, über Transporte. Und warum nicht – diese Methode hat eine Reihe von Vorteilen:

  • Sie wird von SAP unterstützt. Vielleicht nicht genau für den Anwendungsfall der Bereitstellung von Software an Kunden, aber sie ist irgendwie durch die Standardwartung abgedeckt.
  • Sie wird nicht nur offiziell unterstützt, sondern auch umfassend getestet und ist garantiert in jeder Systemlandschaft implementiert, an die Sie Software liefern möchten – einfach, weil jeder sie braucht.
  • Sie unterstützt alle relevanten Objekttypen – offensichtlich, da Sie diese Fähigkeit innerhalb einer Kundensystemlandschaft ohnehin benötigen.
  • Sie leistet wirklich hervorragende Arbeit bei der Handhabung von Dingen wie der Importreihenfolge, dem inaktiven Import und der Massenaktivierung sowie der Nachbearbeitung von Importen. Es ist eine enorme Komplexität involviert, die geschickt unter einem Tool verborgen ist, das jeder ABAP-Entwickler verwendet, ohne darüber nachzudenken. Ich würde den Kurs ADM325 jedem ABAP-Entwickler empfehlen, um ein tieferes Verständnis für die inneren Abläufe des Systems zu erlangen.

Das sieht nach der perfekten Lösung aus, aber: Das CTS/TMS, das Sie aus Ihrer Entwicklungs- oder Kundenlandschaft kennen, wurde für Transporte innerhalb der Systemlandschaft konzipiert. Es wurde nicht für die Softwarebereitstellung zwischen verschiedenen Landschaften konzipiert, obwohl es häufig dafür verwendet wird. Aufgrund dieser nicht bestimmungsgemäßen Verwendung gibt es einige unangenehme Probleme, die nur darauf warten, Sie zu erwischen:

  • Transportkennungen werden automatisch unter Verwendung der System-ID (SID) des exportierenden Systems generiert (<sid>K9<nnnnn>). Abgesehen von einigen Sonderwerten ist nicht abzusehen, welche SIDs in einer Kundensystemlandschaft auftreten können. Wenn die SID Ihres Liefersystems in einer Zielumgebung vorhanden ist, kommt es früher oder später zu einer Kollision der Transportkennungen, was sehr unangenehme Auswirkungen hat. Das bedeutet Ärger, und es gibt keine einfache Lösung dafür .
  • Vor dem Export eines Transports wird nur eine äußerst begrenzte Konsistenzprüfung durchgeführt. Grundsätzlich gilt: Wenn es sich um ein gültiges und weitgehend konsistentes Objekt handelt, können Sie es exportieren. Dazu gehören Z-Objekte, Test-Stubs, Modifikationen und einige andere Dinge, die leicht unbemerkt in den Auslieferungstransport gelangen können. Sie können hierfür Prüfungen mithilfe von CTS-Erweiterungspunkten implementieren, aber Sie müssen sich der Gefahr bewusst sein und sich darauf vorbereiten.
  • Es gibt keine Unterstützung für Modifikationsanpassungen, also keine Unterstützung für SPAU/SPDD-Upgrades. Ihr Kunde kann Ihre gelieferten Objekte modifizieren (vorausgesetzt, Sie liefern den Modifikationsschlüssel des Namensraums, was Sie tun sollten), aber was dann? Bei der nächsten Lieferung dieses Objekts muss der Kunde seine Modifikationen (manuell) sichern, Ihren Transport sie überschreiben lassen und die Modifikationen (erneut manuell) neu implementieren.
  • Es gibt keine integrierte Abhängigkeitsverwaltung. Das CTS/TMS soll in einer Systemlandschaft mit einer homogenen Anordnung von Softwareversionen verwendet werden, sodass alles, was Sie sicher aus der Entwicklungsumgebung exportieren können, wahrscheinlich auch sicher in die anderen Umgebungen importiert werden kann, richtig. Wenn der Transport aus einem System stammt, in dem HR installiert ist, und Sie vielleicht einige HR-Datenelemente oder Funktionsbausteine verwendet haben, nur weil sie praktisch erschienen, können Sie den Transport problemlos exportieren. Wenn der Kunde HR nicht installiert hat, ist das eher nicht der Fall – und Sie haben keine Möglichkeit, dies im Voraus sicherzustellen. Sie werden es erst beim Import bemerken. Dasselbe Problem entsteht, wenn Sie mehrere Add-ons bereitstellen möchten, die voneinander abhängig sind – Sie können nicht sicherstellen, dass Ihr Kunde diese in der richtigen Reihenfolge und nur in kompatiblen Versionen installiert.
  • Apropos Versionen – es gibt keine nennenswerte Versionsverwaltung. Sie müssen die Versionsnummer und den Patch-Level manuell speichern, und Ihre eigene Anzeigefunktion erstellen. Das ist keine große Sache, aber dennoch umständlich.
  • Die Importreihenfolge einzelner Transporte ist in keiner Weise geregelt. Dies wirkt sich nicht nur auf Abhängigkeiten aus (wie oben besprochen), sondern kann auch zu partiellen Downgrades, dem Importieren von Patches in der falschen Reihenfolge und zahlreiche andere Problemen führen, die Ihre Support-Mitarbeiter unnötig beschäftigen werden. Schlimmer noch: Ein unbeabsichtigtes Downgrade von Datenbanktabellen kann zu Datenverlust führen.
  • Ein eher subtiles Problem verbirgt sich im Bereich des Löschens von Objekten und übersprungenen Transporten. Bei CTS/TMS-Transporten ist es leicht möglich, einen Löschdatensatz für ein Objekt zu exportieren, der dazu führt, dass das Objekt auch im Zielsystem gelöscht wird. Nehmen wir an, Sie exportieren diesen Löschdatensatz mit Version 5. Der Kunde entscheidet sich (bewusst oder versehentlich) dafür, Version 5 zu überspringen und direkt von 4 auf 6 zu aktualisieren. In diesem Fall wird der Löschdatensatz nicht importiert und das Objekt verbleibt im System. In den meisten Fällen stellt dies kein Problem dar, aber wenn man an Klassenhierarchien, Schnittstellenimplementierungen und andere stark miteinander verbundene Objekte denkt, kann es zu unangenehmen Überbleibseln kommen. Dies ist auch nicht einfach zu lösen: Es ist nicht ohne Weiteres möglich, einen Löschdatensatz Datensatz zum Transport von Version 6 hinzuzufügen, da der TADIR-Eintrag des Objekts beim Export von Version 5 gelöscht wurde und Sie das gelöschte Objekt nicht zum Transport von Version 6 hinzufügen können, ohne zuerst den TADIR-Eintrag zu erstellen. Es ist möglich, aber nicht trivial‚.
  • Es gibt eine prozedurale Falle, die ebenfalls zu unerwarteten Ergebnissen führen kann. Da Sie im Wesentlichen das normale Change-Management-Software-Logistiksystem der Kundensystemlandschaft verwenden, werden Ihre Software-Upgrades möglicherweise zusammen mit regulären In-Landscape-Transporten (was sie technisch gesehen sind!) versehentlich vom TMS importiert. Wenn das zur falschen Zeit passiert – insbesondere beim Import in das Produktionssystem – kann es zu Problemen kommen. Vermeiden Sie dies, wenn möglich.
  • Als letztes verstecktes Hindernis: Es gibt keine Unterstützung für einen sauberen Upgrade-Pfad zwischen den Releases. Ihre Software wierd unweigerlich einige Komponenten von NetWeaver Basis, ECC, CRM oder einem anderen SAP-Produkt verwenden – ich nenne dies ab jetzt einfach „die Basis“. Für verschiedene Versionen der Basis, auf die Ihr Produkt angewiesen ist, müssen Sie häufig leicht unterschiedliche Produktversionen liefern. Das bedeutet, dass bei einem größeren Upgrade Objekte möglicherweise gelöscht werden müssen, während andere hinzugefügt oder geändert werden müssen. Sie müssen einen Weg finden, dies manuell zu unterstützen – das CTS/TMS bietet keine Unterstützung.

Wie Sie sehen, ist diese offensichtliche Lösung zwar mit einer Reihe von Einschränkungen für eine Vielzahl von Szenarien praktikabel Szenarien umsetzbar. Sie ist aber alles andere als ideal, stellt eine enorme Belastung für die Personen dar, die den Export- und Importprozess verwalten, und wird in bestimmten Situationen (SID-Kollisionen) völlig zusammenbrechen. Man sollte meinen, dass es einfach einen besseren Weg geben muss.

Preisintensive professionelle Produktvorbereitung

Glücklicherweise gibt es eine bessere Möglichkeit – schließlich schafft es SAP, eine breite Palette von Software auf Basis der NetWeaver-ABAP-Plattform zu liefern, und das muss alles irgendwie verpackt werden. Die Software dafür (oder zumindest eine Software, die dazu in der Lage ist) ist verfügbar; sie ist als Add-On Assembly Kit (kurz AAK; die Softwarekomponente ist AOFTOOLS, wahrscheinlich für Add-On Factory Tools).

Die Online-Dokumentation des AAK ist unter http://help.sap.com/aak frei verfügbar, daher werde ich nicht versuchen, alles zu wiederholen, was dort geschrieben steht. Kurz gesagt bietet AAK zwei Tools, die bei der Definition, Überprüfung und Pflege der Inhalte eines lieferbaren Softwarepakets (Software Delivery Composer) und der Umwandlung dieses Pakets in eine installierbare Datei (Software Delivery Assembler) helfen. Während der gesamte Prozess intern TMS-Tools verwendet, ist der gesamte Prozess viel ausgefeilter und speziell auf die Unterstützung des „Lieferung an anonymen Kunden“-Szenarios ausgelegt.

Beachten Sie, dass das AAK zwar eine installierbare Einheit ist, aber kein Produkt, für das Sie eine Lizenz erwerben können. Sie schließen einen separaten Vertrag mit dem SAP Integration and Certification Center ab, um Ihre Lösung zertifizieren zu lassen, und als Teil des Prozesses erhalten Sie das AAK. Die Details sind hier und hier sowie in Hinweis 929661 beschrieben.

Die Vorteile dieses Ansatzes sind, um nur einige zu nennen:

  • Von SAP unterstützt, von SAP verwendet. Welche bessere Referenz könnte man sich wünschen?
  • Es gibt eine umfangreiche Dokumentation – Online-Referenz, 130-seitiges PDF, sogar SAP-Tutor-Einführungsvideos, als ich das letzte Mal die Gelegenheit hatte, es zu nutzen. Außerdem wird Ihnen ein persönlicher Ansprechpartner zugewiesen, und zumindest bei den Personen, mit denen ich das Vergnügen hatte zusammenzuarbeiten, lässt deren Kompetenz und Professionalität keine Wünsche offen.
  • Die Import-Tools, nämlich Transaktionen SAINT und SPAM, sind den meisten Basisadministratoren bekannt. Im Gegensatz zu den üblichen TMS-Transportvorgängen sind sie für den Import großer Softwarepakete ausgelegt und decken alle Arten von Problemen ab.
  • Wenn Sie sich jemals gefragt haben, woher die seltsamen Namen der Softwarekomponenten kommen – mit dem AAK haben Sie die Möglichkeit, Ihre eigene Softwarekomponente zu erstellen. Der Name der Softwarekomponente basiert auf einem registrierten Namensraum und ist daher garantiert eindeutig; die Lieferobjektlisten enthalten die Softwarekomponenten-ID und sind daher ebenfalls eindeutig. Die endgültigen EPS-Lieferdateien enthalten die System-ID und die Installationsnummer, die in dieser Kombination ebenfalls eindeutig sind (zumindest eindeutig genug für alle Zwecke). Kollisionen mit Kundensystem-IDs werden somit vermieden.
  • Während des Paketierungs- und Exportprozesses finden umfangreiche Konsistenzprüfungen statt, die sogar durch Kundenprüfungen erweitert werden können. Beispielsweise möchten Sie als i.s.h.med-Entwickler möglicherweise verhindern, dass einige generierte Funktionsgruppen ausgeliefert werden, da sie auf dem Kundensystem generiert werden müssen. Das Schreiben einer benutzerdefinierten Prüfung hierfür ist ziemlich unkompliziert. Da der Import die bekannte SAINT/SPAM-Route verwendet, erhalten Sie vollständige SPDD/SPAU-Modifikationsunterstützung, einschließlich Transportaufträge zur Anpassung von Modifikationen, die zur automatischen Anpassung der Modifikationen auf QA- und Produktionssystemen verwendet werden können.
  • Es gibt ein integriertes Abhängigkeitsverwaltungssystem, mit dem Sie angeben können, welche Softwarekomponenten in welchen Versionen vorhanden sein müssen oder nicht. Diese Abhängigkeiten werden frühzeitig während des Importvorgangs überprüft. Wenn eine Abhängigkeit nicht erfüllt ist, wird der gesamte Importvorgang abgebrochen.
  • Die AAK bietet Unterstützung für verschiedene Upgrade- oder Cross-Grade-Szenarien, einschließlich Versions-Upgrades. Sie können spezielle Add-On Exchange Upgrade-Pakete erstellen, mit denen Sie Objekte, die in der neuen Version nicht mehr benötigt werden, sauber entfernen und alle neuen Objekte importieren können. Dies ist vollständig in den Upgrade-Prozess selbst integriert.
  • Es ist kaum erwähnenswert, aber natürlich gibt es volle Unterstützung für das Löschen von Objekten. Mit der erst kürzlich veröffentlichten Version 5.0 gibt es sogar Unterstützung für löschbare Add-ons.
  • Im Vergleich zu Transporten finden während des Installationsprozesses viele zusätzliche Prüfungen statt, darunter Versionsprüfungen (z. B. ein Downgrade-Schutz) und Kollisionsprüfungen mit anderen Anwendungskomponenten.
  • Da für den Import ein völlig anderer Satz von Tools verwendet wird, können AAK-Add-Ons nicht mit regulären Transporten verwechselt werden.
  • Neben regulären Versionen („Releases“) bietet das AAK Unterstützung für Patches. Der Patch-Importprozess erzwingt die korrekte Reihenfolge der Patches und gewährleistet so einen konsistenten Softwarestand auf dem Kundensystem.
  • Ihre Software wird in der Komponentenversionsliste über System > Status aufgeführt, was jeder Softwareentwickler anstreben sollte.
  • Schließlich erhalten Sie durch den Zertifizierungsprozess einen Check von SAP und ein Zertifizierungslogo sowie eine Aufnahme in das Partnerverzeichnis.

Angesichts der vielen Vorteile sollte man meinen, dass dies die Lösung für alle Probleme sein muss. Warum nutzt es dann nicht jeder? Offensichtlich muss es einige Nachteile geben. Schauen wir mal…

  • Es ist der breiten Öffentlichkeit weitgehend unbekannt, zumindest ist das meine Beobachtung. Ich hoffe, dass ich dazu beitragen kann, das nach und nach zu ändern.
  • Die Zertifizierung ist nicht gerade billig. In einem der oben erwähnten Artikel oben enthält die Zahlen – 15.000 € für das erste Jahr und 10.000 € für jedes weitere Jahr.
  • Für den Verpackungs- und Testprozess ist eine umfangreiche Systemlandschaft erforderlich oder zumindest dringend zu empfehlen. Als Faustregel gilt, dass drei Systeme pro unterstützter Foundation-Version unterstützt werden – je nach Ihren Anforderungen kann sich diese Zahl in beide Richtungen ändern, aber für den Anfang ist es eine gute Schätzung.
  • Der Lieferprozess sieht zunächst riesig aus. Er kann reduziert werden, sobald Sie das System besser kennen und das Szenario klar definiert ist – es gibt viele Sonderfälle, die in Ihrem Szenario möglicherweise nicht zutreffen, aber Sie müssen darüber nachdenken und entscheiden, ob Sie sie bewusst handhaben möchten.

Dieser letzte Punkt ist eigentlich nicht unbedingt ein Nachteil: Das AAK zwingt Sie dazu, über viele Dinge nachzudenken, die schiefgehen könnten, und Wege zu finden, sie zu verhindern. Es setzt ein gewisses Qualitätsniveau voraus – man kann nicht einfach irgendetwas liefern, zumindest nicht, ohne die Warnung bewusst zu unterdrücken, die einem sagt, dass man kurz davor ist, einen Fehler zu machen.

Der steile Anstieg

Nachdem wir uns die verschiedenen Alternativen im Detail angesehen haben - was ist das Fazit?

Die SAP-Entwicklung zu starten ist heutzutage relativ einfach und günstig – wenn ich die Informationen zum SAP PartnerEdge-Programm für Anwendungsentwicklung richtig verstehe, bekommt man ein vollwertiges Paket für 25 benannte Entwickler für 2.500 € pro Jahr. Damit können Sie Software entwickeln und über Transporte bereitstellen, was – wie wir gesehen haben – keine optimale Lösung ist.

Wenn Sie auf die professionelle Lösung upgraden möchten, zahlen Sie am Ende leicht das Zehn- oder Zwanzigfache. Sie müssen zum einen die Grundzertifizierungsgebühr (15.000 € für das erste Jahr) berücksichtigen, aber auch die die Systemlandschaft bereitstellen und warten. Dies könnte eine ideale Gelegenheit für die Cloud-Welt sein – man muss nur einige vorkonfigurierte Instanzen verwenden, die in der SAP Cloud Appliance Library verfügbar sind, sie in einer Transportdomäne verknüpfen und schon ist man fertig, oder? Richtig, nur dass jedes System leicht 1.000 € oder mehr an CAL- und Cloud-Anbietergebühren (pro Monat) kostet. Für die Zertifizierung und drei cloudbasierte Systeme im ersten Jahr fallen also wahrscheinlich Kosten in Höhe von 30.000 bis 50.000 € an. Dazu kommt der Aufwand für die Einrichtung des Bereitstellungsprozesses, wenn niemand mit der AAK und den grundlegenden Verwaltungsaufgaben vertraut ist (was wahrscheinlich der Fall ist), und das Fazit wird klar:

Die Software mit dem idealerweise für den Job geeigneten Tool zum Kunden zu bringen, ist so zeit- und kostenaufwendig, dass viele (die meisten?) kleinen Unternehmen und sogar einige der größten auf eine suboptimale Lösung zurückgreifen. Man würde hoffen, dass sich dies ändert, sodass jetzt, da wir die Entwicklungsumgebung zu einem Bruchteil der Kosten von vor einigen Jahren zur Verfügung haben, dasselbe für die Bereitstellungslösung gilt.

Ergänzung

„SAP R/3“ könnte eine viel bessere Benutzer- und Kundenerfahrung bieten als heute, wenn es einfacher wäre, lieferbare Software zu erstellen. Mit AAK 5 hätten Unternehmen die Möglichkeit, die Software einfach auszuprobieren, da Add-ons jetzt deinstallierbar gemacht werden können.

Ich verstehe auch die Notwendigkeit eines zertifizierten Produkts, aber im Moment führt das zu einer Pattsituation: Niemand will mehr als 20.000 € in die Entwicklung eines coolen Add-ons und dessen zertifizierte Bereitstellung investieren (oder investieren können), sodass kein Marktinteresse entsteht, es also keine potenziellen Kunden gibt und niemand auch nur versucht, zu investieren. Dies führt zu dem von Ihnen beschriebenen Zoo aus benutzerdefinierten, internen Ergänzungen von (in der Regel) minderwertiger Qualität sowie zu einem „grauen Markt“ aus Add-ons, die über Transportmittel bereitgestellt werden , bei denen man nicht einmal sicher sein kann, dass die Installation das System nicht beschädigt.

Wie wäre es mit einem anderen Ansatz, nur als Argument in dieser Diskussion (ich kann solche Dinge sowieso nicht entscheiden):

  1. AAK für Kunden und PartnerEdge-Partner zur kostenlosen Nutzung freigeben, vielleicht nach Unterzeichnung einer Vereinbarung, die SAP schützt (wie die aktuelle Vereinbarung).
  2. Bestehende und zukünftige zertifizierte Partner erhalten einen kryptografischen Schlüssel, wie er zum Schutz der Namensräume verwendet wird (vielleicht könnte man dies sogar mit dem System zur Registrierung von Namensräumen verknüpfen?). Dieser Schlüssel kann konfiguriert werden und wird zum Signieren des Liefergegenstands bei der Verpackung und Lieferung der Add-ons verwendet.
  3. Bei der Installation des Add-ons überprüft SAINT, ob eine Signatur vorhanden ist. Wenn keine Signatur vorhanden ist, wird der Kunde benachrichtigt, dass er versucht, ein nicht zertifiziertes Paket zu installieren, und dass SAP keinerlei Verantwortung übernimmt.

Dies würde AAK für eine breitere Nutzung öffnen, während der zusätzliche Wert der Zertifizierung erhalten bleibt. Und wenn ein kleiner Lösungsanbieter durch den Verkauf von „nicht zertifizierten“ Add-ons wächst, wäre es irgendwann in seinem eigenen Interesse, diese Zertifizierung zu erhalten, nur um diese unangenehme Meldung aus dem Weg zu räumen…