Architekturberatung bei CONET im SAP-Umfeld
In den frühen 1990er Jahren (genauer gesagt: seit dem 06.07.1992) hat SAP sein erstes R3-System vorgestellt. Das Konzept war damals gegenüber den herkömmlichen Mainframe-Lösungen bahnbrechend, da die Geschäftsanwendungen auf einer Client-Server-Lösung betrieben werden konnten. Zudem konnten die Anwendungen gleichermaßen auf verschiedenen Plattformen betrieben werden. Viele Kunden waren somit in der Lage ihr technologisches Know-how in Bezug auf Betriebssysteme und Datenbanken einfach weiter zu verwenden.Seit SAP zu dieser Zeit seinen Siegeszug angetreten hat, hat sich an dieser Idee grundsätzlich nicht viel verändert. Auch heute noch trägt die Plattformvielfalt zu einer hohen Intergrationsfreudigkeit in heterogenen IT-Landschaften bei.
Mit der Ablösung von R3 durch ERP setzt SAP eine zentrale Runtime-Basis „Netweaver“ ein, die den Kern der meisten SAP-Anwendungen darstellt. Hierfür stehen zwei verschiedene Entwicklungsplattformen zur Verfügung: Der Applikationsserver ABAP, der auf der von SAP selbstentwickelten Programmiersprache für Geschäftsanwendungen ABAP basiert, sowie dem Applikationsserver JAVA, basierend auf der Programmiersprache Java.
Von der klassischen 3-Systemlandschaft bis hin zu komplexen Mehrsystemlandschaften
Eine Vielzahl von Kunden nutzt lediglich ein zentrales ERP-System, bzw. sie beginnen Ihre SAP-Einführung auf Basis eines solchen Systems. Hierbei handelt es sich um die Weiterentwicklung des Ursprungssystems „SAP R/3“ mit den Kerngeschäftsanwendungen (Rechnungswesen/Logistik). Im einfachsten Fall benötigt man hierzu nur eine Plattform bestehend aus einem NetWeaver ABAP. Obwohl viele Geschäftsanwendungen, die im Standard ausgeliefert werden, bereits die meisten benötigen Geschäftsprozesse abdecken, nutzen viele Kunden die offene Architektur für eigene Anwendungen bzw. Modifikationen an Standard SAP-Funktionen. Da die wenigsten Kunden Änderungen unmittelbar an ihrem produktiven System selbst durchführen möchten, hat sich hierzu eine Mehrsystemlandschaft bewährt, in der zunächst die Entwicklung der Änderungen sowie der Test der geänderten Funktionen auf einem separatem Entwicklungs- und Testsystem durchgeführt wird.
Größere Kundenprojekte erfordern mitunter weit komplexere Systemlandschaften. Wenn aufgrund verschiedener Release- und Datenbestände auf mehreren Systemen gleichzeitig entwickelt werden muss, bedeutet dieses aber auch einen hohen Integrations- und Testaufwand über mehrere Systemebenen hinweg. Um dabei noch die Integrität der Systemlandschaft zu wahren ist es neben der Definition der Systemlandschaftswege wichtig, vorher geeignete Regeln im Umgang mit den Änderungen zu beschließen und möglichst zu automatisieren. Hierfür kann auch der SAP Solutionmanager sinnvoll eingesetzt werden.
Manchmal nehmen Kunden – gleich ob sie einfache oder komplexere Systemlandschaften nutzen- diese Regeln nicht ganz so genau, was nicht selten dazu führt, dass sich die Softwareentwicklungsstände auf den einzelnen Systemen irgendwann derart unterscheiden, dass ein produktionsnahes Weiterentwickeln und/oder testen in der Systemlandschaft nicht mehr risikofrei möglich ist. In diesen Fällen haben wir schon häufig Strategien zur Bereinigung der Inkonsistenzen entwickeln müssen.
Zusammenwirken verschiedener SAP und nonSAP Produkte
Nicht selten verwenden Kunden nicht nur ein einzelnes SAP-Produkt (z.B. BW, BO, PI, CRM, TM, E-Recruiting oder auch nonSAP-Produkte), sondern mehrere Produkte, die meist in Wechselwirkung zueinanderstehen. Hierbei geht es nicht nur darum für jede Systemschiene eine eigene Systemlandschaft zu entwerfen, sondern auch den konsistenten Austausch der Daten untereinander zu definieren und einzurichten. Eine weitere große Herausforderung ist das Wiedersynchronisieren der Systeme z.B. nach einem Systemausfall (Backup-/Restoreszenario) oder nach Systemkopien zum Aufbau von Testlandschaften.
Release-Planung
Für die meisten Produkte stellt SAP vierteljährlich Supportpackages zu Verfügung, die i.d.R. die Programmkorrekturen des letzten Zeitraums enthalten. Einige dieser Korrekturen lassen sich nicht manuell einbauen, sondern stehen nur über Supportpackages zur Verfügung. Ein Beispiel hierfür war z.B. die SEPA-Funktionalität, was dazu führte, dass spätestens hier „Supportpackagemuffel“ ihre Systeme kurzfristig und ungeplant updaten mussten.
Das letzte ERP Releasupgrade liegt bereits viele Jahre zurück. Grund hierfür ist die Upgradestartegie über „Enhancementpackages“. Hierbei werden neue Funktionen zunächst als inaktive Supplements verteilt und können einzeln bei Bedarf aktiviert werden. Das hat den Vorteil, dass die neuesten Funktionen stets funktionsneutral eingespielt werden können, ohne dass sie zunächst den vorhandenen Prozessablauf beeinträchtigen. Auf dieses Weise kann das Einspielen und das gezielte Aktivieren zeitlich entkoppelt werden. Wir empfehlen einmal pro Jahr – z.B. zu „projektarmen“ Zeiten, ggf. zu Jahresbeginn- einen verbindlichen Termin im Geschäftsjahresablauf zu etablieren, bei dem jeweils das aktuell verfügbare Enhancementpakage in Verbindung mit den korrelierenden Supportpackages im Rahmen eines eigenen Projektes eingespielt wird.
Betriebsplattformen
Wie eingangs erwähnt, können die SAP-Anwendungen auf unterschiedlichen Betriebssystem-/Datenbankplattformen betrieben werden. Die genauen Abhängigkeiten werden seitens SAP in einer detaillierten „Product Availability Matrix“ (kurz PAM) bis auf Releaseebene für jedes einzelne Produkt dargestellt. Neben den rein technischen Gesichtspunkten (Betriebssicherheit, Performance) hat das für viele Kunden den Vorteil, dass ihre SAP-Anwendungen auf denselben Betriebssystem-/Datenbankplattformen wie ihre übrigen Anwendungen betrieben werden können.
Plattformmigrationen
Nichtsdestotrotz ändern sich im Laufe der Zeit die Anforderungen an die Plattformen, so dass teilweise eine Migration auf eine alternative Plattform in Betracht gezogen werden muß. Eine solche Migration stellt in der Regel aufgrund ihrer Komplexität eine große Herausforderung an die Planung dar. Neben den reich technischen Gesichtspunkten, die meist anhand einer abgesetzten Testplattform (z.B. Sandboxsysteme) geklärt werden können, gilt besonders der Planung der Umsetzungsreihenfolge der beteiligten Systeme erhöhte Aufmerksamkeit, die sehr sorgfältig und mit Fallback-Szenarien die Beeinträchtigung des Betriebsablaufes auf ein Minimum reduzieren sollte.
In jüngster Zeit erfreut sich der Einsatz von Virtualisierungsplattformen immer größerer Beliebtheit. Die zertifizierten Systeme weisen mittlerweile nahezu keinen Performanceverlust gegenüber persistenten Systemen auf, so dass hier die Flexibilität im Umgang mit den Ressourcen sowie zentrale Services für z.B. Backup und Hochverfügbarkeit unabhängig von der Anwendungsebene direkt auf der Betriebsebene abgedeckt werden können.
SAP HANA
Über viele Jahre hinweg hat SAP keine eigenen Datenbankprodukte entwickelt und hat hier das Feld den renommierten Datenbankherstellern überlassen. Dieses hat sich nun mit der Entwicklung der In-Memory-Datenbank SAP HANA grundlegend geändert. Angetrieben durch die Notwendigkeit einiger Anwendungen über eine standard-SQL-Schnittstelle hinaus eine deutlich höhere Integration in die Datenbanklogik zu erzielen, sowie der Tatsache, dass die herkömmlichen Datenbankmechanismen mittlerweile an ihre Performancegrenzen gestoßen sind, hat SAP nun ein eigenes Produkt entwickelt.
SAP HANA ist in weit höherem Maße als die herkömmlichen Datenbanksysteme in die SAP-Anwendungen integriert. Für die meisten Kunden wirken sich die Performancevorteile der In-Memory-Datenbank nicht signifikant aus. Andererseits werden einige Produkte aber nur noch in Zusammenhang mit SAP-HANA angeboten (z.B. SAP FIORI), so dass es sich bei der nächsten geplanten Plattformregeneration aus rein strategischen Gründen lohnt, ein blick auf SAP HANA zu werfen. Viele Kunden schrecken hier jedoch vor den vermeintlich noch sehr hohen Hardwareinvestitionskosten zurück. Ihnen ist jedoch meist nicht klar, dass sie andererseits beim Wechsel des Lizenzmodells über ein signifikantes Einsparungspotenzial verfügen.
Solutionmanager
Sowohl die wachsende Komplexität der einzelnen Produkte als auch immer umfangreichere Systemlandschaften erfordern in zunehmendem Maße stabile Supportstrukturen. Konnte man vor einigen Jahren noch die erforderlichen Supportpackages der ERP-Systeme manuell berechnen, so ist es aufgrund der hohen Integration eines ERP-System in viele andere Produktschienen, sowie der komplexen Abhängigkeit der Enhancementpackages zu den verwendeten Modulen mittlerweile nicht mehr möglich ein maßgeschneidertes Supportpackage- oder Upgrade-Paket manuell zu ermitteln.
Dieses ist heutzutage nur noch mittels Einsatzes eines SAP Solutionmanger Systems möglich. Da ein SAP Solutionmanger sowohl gleichzeitig eine Onlineverbindung zu den zu verwaltenden Systemen als auch zum Online SAP Service Marketplace benötigt, muß dieses System zwingend beim Kunden vor Ort betrieben werden. Mittlerweile ist es ebenso erforderlich auch das Release des SAP Solutionmanagers aufgrund der Softwareabhängigkeiten in die Releaseplanung der übrigen Systeme mit einzubeziehen.
Da jeder einzelne Kunde mittlerweile einen eigenen SAP Solutionmanager benötigt, macht es Sinn hier gleich über einen Mehrwert dieses Systems nachzudenken. Hier kommen vor allem langjährig bewährte Anwendungen in Betracht wie:
- Projektdokumentation
- Monitoring
- Testmanagement
- Service-Desk
Diese zeichnen sich heute durch eine hohe Produktreife sowie Stabilität und Bedienbarkeit aus.
Fazit
Die immer weiter zunehmende Komplexität der SAP-Produktlandschaft sowohl auf Anwendungs- als auch auf der Technologieseite stellt Unternehmen in weiter zunehmendem Maße vor große Herausforderungen, die sie ohne zusätzliches Know-how allein nicht mehr bewältigen können. Zudem verkürzen sich die die Produktentwicklungszyklen fortschreitend, was auch auf Herstellerseite zu immer größeren Problemen führt stabile Produkte auf den Markt zu bringen. War es vor einiger Zeit noch möglich z.B. ein einzelnes ERP-System über einige Jahre ohne „Support“ getreu dem Motto „never touch a running System“ zu betreiben, kommt man heute ohne sinnvolle Lifecycle Strategien mittels Solutionmanager & Co kaum noch aus.
Über den Autor
Rüdiger Platzek war als Senior Consultant im Bereich „SAP NetWeaver Development & Administration” bei der CONET Business Consultants GmbH tätig.
