1.3 Eigenentwicklungen der SAP
Wenn man das Thema »Softwareentwicklung im SAP-Umfeld« betrachtet, handelt es sich in den meisten Fällen um proprietäre Technologien. In einem SAP-System wird mit der Programmiersprache ABAP entwickelt. Diese wurde speziell von der SAP entworfen, um SAP-Anwendungen wie das ERP bzw. die Business Suite zu realisieren. Bei der Fragestellung, wie Software durch die verschiedenen Systemumgebungen wie Entwicklung, Test und Produktion transportiert werden kann, setzt die SAP auf das Transport Management System (TMS), auf Erweiterungen wie das Enhanced Change and Transport System (CTS+) und auf das SAP Change Request Management (ChaRM) – alle ebenfalls Eigenentwicklungen der SAP.
Neben der Programmiersprache und den zu verwendenden Werkzeugen unterscheidet sich bei diesen Lösungen das Vorgehen während des Entwicklungsprozesses. So wird in ABAP beispielsweise der gesamte Quellcode im Laufzeitsystem (also dem Entwicklungssystem) vorgehalten. Möchte der Entwickler seinen Quellcode ausführen, muss er ihn zunächst auf diesem System aktivieren. Eine zentrale Quellcode-Verwaltung, in der mehrere Entwickler an unterschiedlichen Versionen und Strängen der Software arbeiten, ist nicht vorgesehen.
Die Entwicklung eigener Tools unter Verwendung proprietärer Technologien hat in vielen Fällen ihre Daseinsberechtigung, denn für spezielle Anforderungen werden besondere Werkzeuge benötigt. Das Beispiel von ABAP und dem ABAP-Stack zeigt sogar, dass der Erfolg eines Produkts durch Einsatz einer solchen Technologie klar begünstigt werden kann. Das SAP-ERP-System wäre vermutlich nicht so erfolgreich geworden, hätte man es nicht mit ABAP, sondern mit einer anderen Programmiersprache entwickelt. Gerade die konsequente Ausrichtung der Sprache auf die Anforderungen eines ERP-Systems waren und sind der Schlüssel zum Gelingen. Auch die für den Entwicklungsprozess dargestellten Werkzeuge weisen erhebliche Vorteile auf und zeigen, dass eine Eigenentwicklung der SAP die SAP-Systeme bestmöglich unterstützt.
Auf der anderen Seite kann der Einsatz eigener Technologien insofern problematisch sein, als der Kreis derer, die sich damit auskennen, eher begrenzt ist. Zudem kann bei Fragen oder Problemen nicht auf große, bereits vorhandene Communitys zurückgegriffen werden. ABAP ist keine Programmiersprache, die etwa in den Universitäten oder anderen Ausbildungsstätten zum Standard für angehende IT-Experten gehört.
Ich möchte an dieser Stelle ein Beispiel für eine aus meiner Sicht weniger erfolgreiche Umsetzung einer SAP-Eigenentwicklung anführen: Java von SAP.
SAP hatte geplant, Java-Entwickler, die noch keine Berührungspunkte mit dem SAP-Universum hatten, für SAP-Entwicklungen zu gewinnen. Verständlicherweise, denn der Markt ist riesig, da Java eine der beliebtesten Programmiersprachen mit einer sehr ausgeprägten Community ist.
Um dieses Ziel zu erreichen, wurde der SAP Web Application Server (SAP WebAS, später NetWeaver AS) in zwei Varianten – als ABAP-Stack und als Java-Stack – bereitgestellt. Neue Produkte wurden entweder für den ABAP-Stack (z.B. ERP) oder für den Java-Stack (z.B. Portal) entwickelt. Einige basierten sogar auf beiden Stacks, wie der Solution Manager. Der eigene Applikationsserver im Java-Umfeld (SAP NetWeaver AS Java) wird nicht mehr weiterentwickelt und aller Wahrscheinlichkeit nach mit der aktuellen Version 7.5 auslaufen. Ebenso erging es dem Thema »Software-Logistik im Java-Umfeld« mit der Eigenentwicklung SAP NetWeaver Development Infrastructure (NWDI). Auch diese wurde nur mit mäßigem Erfolg vom Markt akzeptiert.
Java-Entwickler konnten jedenfalls nur ganz begrenzt für die SAP-Plattformen gewonnen werden. Ein Grund dafür ist meines Erachtens, dass sich viele der Java-Entwickler nicht auf die SAP-Besonderheiten einlassen wollten. Allzu häufig unterschied sich die SAP-eigene Java-Entwicklung von der allgemein bekannten, und zwar sowohl in der Programmierung als auch in dem Werkzeugkasten, der für die Entwicklung verwendet werden musste (z.B. die erwähnte SAP NWDI).
Anhand der genannten Beispiele stellt sich die Frage, welche Erkenntnisse die SAP aus den Erfahrungen mit der eigenen Java-Umgebung gezogen hat. Genau an dieser Stelle komme ich zum Thema XSA zurück, denn in der XSA-Umgebung lässt sich Software auch mittels Java entwickeln. Im Unterschied zum Ansatz des NetWeaver AS Java kann in der XSA Standard-Java-Code entwickelt werden. Es gibt fast keine Einschränkungen, wie die Sprache zu verwenden ist. Als Entwickler können Sie damit genauso entwickeln, wie Sie es außerhalb der SAP-Welt tun würden. Gerade für Programmierer, die bis dato noch keine Berührungspunkte mit SAP-Systemen hatten, ist dies ein erheblicher Vorteil.
Neben der Möglichkeit, eine SAP-fremde Programmiersprache wie beispielsweise Java zu verwenden, ist noch ein weiterer Aspekt wichtig, der die XSA-Umgebung als moderne Entwicklungsplattform ausweist.
Mittlerweile sind Begriffe wie »cloud native« und »cloud first« auf dem Vormarsch. Gerade bei Eigenentwicklungen ist es inzwischen maßgeblich, ob Software auch in einer Cloud-Umgebung lauffähig ist oder nicht. Aktuell drängen sowohl Softwarehersteller als auch Kunden in die Cloud und erwarten die »Cloudfähigkeit« natürlich ebenso von einer modernen Entwicklungsplattform.
Genau bei diesem Thema kann die XSA überzeugen. Die Art und Weise, wie mit der XSA-Umgebung Software entwickelt wird, basiert auf Cloud-Konzepten. Eine Anwendung, die in der XSA läuft, kann demnach auch in einer Cloud-Umgebung bereitgestellt werden.
Weitere Details zum Themenschwerpunkt »Cloud« gebe ich in Kapitel 3.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.