<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=380018&amp;fmt=gif">
_Collaboration_icon Community
Technische Beratung und Vertrieb

Kontakt

 

    4 min read

    Moderne SAP-Landschaften verstehen

    Featured Image

    In den letzten 7 Jahren war die Umgestaltung von SAP-Landschaften für viele Unternehmen ein wichtiges Thema. Das konnte entweder eine SAP HANA-Migration, einer S/4-Transformation, eine Cloud-Migration, oder die Einführung von SaaS-Lösungen wie Ariba oder Successfactors sein. Höchstwahrscheinlich aber war es einer Mischung aus mehreren der genannten. Was einst eine zeitaufwändige, selbstbetreute, stagnierende, und große Architektur war, hat sich hin zu einer skalierbaren Architektur verändert, bei der die zugrunde liegende Hardware von verschiedenen Parteien mit einer Mischung von Verantwortlichkeiten den jeweiligen Ebenen administriert wird. Unabhängig davon, ob Ihr Unternehmen solch eine Transformation in Erwägung zieht oder sich bereits in einem solchen Prozess befindet, ist es wichtig zu verstehen, wie Ihre zukünftige SAP-Landschaft aussehen könnte und welche Verantwortung Sie haben.  

     

    Konsolidierung der SAP-Landschaft

    SAP-Umgebungen bestanden früher aus vielen Landschaften mit verschiedenen Nicht-Produktions- und Produktionssystemen, die oft für Spitzenlasten ausgelegt waren, d. h. die Systeme verfügten über die CPU, Speicher, Disk etc., um Arbeitslasten zu bewältigen, die tatsächlich vielleicht nur ein- oder zweimal im Jahr anfallen. Wenn Unternehmen jedoch S/4-Transformationen durchführen, werden all diese Umgebungen in einigen wenigen Landschaften konsolidiert, die über eine große Leistung in Bezug auf CPU, Speicher und zusätzliche Ressourcen verfügen. Aber wie Peter Parker aus Spiderman einmal sagte: "With great power comes great responsibility": Ein Ausfall eines einzigen S/4-Systems kann ein Unternehmen komplett in die Knie zwingen und Ausfallkosten in Millionenhöhe verursachen.

     

    New call-to-action

     

    Redundanz und noch mehr Redundanz 

    Es dürfte kaum überraschen, dass diese konsolidierten Umgebungen auf Worst-Case-Szenarien ausgerichtet werden müssen, weshalb sie mittels in Hochverfügbarkeits- (HA) und Disaster Recovery-Konfigurationen (DR) umgesetzt werden. Diese Konzepte sind nicht neu, werden aber heutzutage sehr viel stärker eingesetzt. Das bedeutet, dass die SAP-Anwendung und die Datenbank, die früher auf einem einzigen Server liefen, jetzt auf eigenen Servern ausgeführt werden. Jeder dieser Server verfügt über eine Replikation auf einen zweiten Server, falls der erste ausfällt, oder nutzt sogar beide gleichzeitig, um die Arbeitslast zu verteilen. Was früher ein SAP-System auf einem einzigen Server war, wird jetzt auf vier Servern betrieben: eine geteilte Instanz, die hochverfügbar läuft. Darüber hinaus verfügen die SAP-Anwendungs- und Datenbankschichten höchstwahrscheinlich jeweils über mindestens einen zusätzlichen Server für die Wiederherstellung im DR-Fall. Es könnte sogar eine vollständige Spiegelung der vier Server-Umgebungen zum Einsatz kommen, so dass die Daten in den Tabellen kontinuierlich repliziert werden können, falls das Hochverfügbarkeitssystem aus irgendeinem Grund ausfällt. Mit diesen zusätzlichen Servern verteilt sich das System, das früher auf einem einzigen Server lief, nun auf mindestens 6-8 Server.

     

    Automatisierter SAP-Betrieb

     

    SAP in der Public Cloud

    Das Aufkommen der Public Cloud (Alibaba, AWS, Azure, Google Cloud) hat, so seltsam es auch klingen mag, SAP-Landschaften verkompliziert.

    Diese Public-Cloud-Anbieter bringen eine Fülle von Vorteilen mit sich, von denen der größte darin besteht, dass die Verantwortung für die Infrastruktur vollständig in ihren Händen liegt. Diese komplexen Landschaften mit Hochverfügbarkeit und Disaster Recovery können nun mit ein paar Klicks über verschiedene Zeitzonen oder geografische Regionen verteilt werden. Somit können beispielsweise regionale Wetterkatastrophen nicht mehr das unternehmenskritischste System auslöschen. Durch den Einsatz geeigneter Tools müssen SAP-Systeme in der Public Cloud nicht mehr mit Blick auf Spitzenauslastung konzipiert werden. Diese Systeme können mit Hilfe von Lösungen von Drittanbietern nach oben/unten und nach innen/außen skaliert werden, wodurch die Umgebung wirklich so kompakt und preiswert wie möglich wird. 

     

    ITOM, Public Cloud & AIOps:  für den SAP-Betrieb >>
     

    Wo also kommt die Komplexität ins Spiel? Die meisten Unternehmen haben festgestellt, dass die Installation, Migration und der Betrieb von SAP in diesen Umgebungen so einfach ist, dass sie oft in hybriden Umgebungen landen. Es versteht sich von selbst, dass sich Systeme, die von On-Premise in die Cloud migriert werden, in einer hybriden Umgebung befinden; aber denken Sie an die langfristige Perspektive. Bei den meisten SAP-Systemen handelt es sich nicht um isolierte System, denn viele haben irgendeine Art von Nicht-SAP-System oder Nicht-SAP-Quelle, mit der sie verbunden sind. Dabei kann es sich um Altsysteme, Anwendungen von Drittanbietern oder Schnittstellen handeln, die weiterhin on-premise, in einer anderen öffentlichen Cloud oder höchstwahrscheinlich in einer Mischung aus beidem betrieben werden. Die konsolidierte SAP-Landschaft, die mit HA/DR über mehrere öffentliche Cloud-Zonen/Regionen verteilt läuft, muss nun also auch andere SAP-Systeme oder Nicht-SAP-Anwendungen wie Datenbanken usw. umfassen, die wiederum über verschiedene Hosting-Umgebungen verteilt sind, was die Gesamtlandschaft leicht noch komplizierter macht.

     

    Software as a Service (SaaS) Lösungen

    Doch die Komplexität endet nicht mit der Public Cloud. Viele Softwarelösungen gehen zu einem SaaS-Betrieb über, bei der das Softwareunternehmen für das Management von so ziemlich dem kompletten technischen Stack verantwortlich ist, abgesehen von einigen möglichen Konfigurationen und Daten innerhalb des Systems. Zu den bekannten SaaS-Lösungen im SAP-Bereich gehören Software wie Ariba, SuccessFactors, Concur und sogar Nicht-SAP-Lösungen wie Salesforce. In der Vergangenheit wurden die Geschäftsanwendungen dieser Softwaresysteme vor Ort installiert, was einen höheren Verwaltungsaufwand für ein einzelnes Unternehmen bedeutete. Da diese Lösungen jedoch zunehmend als SaaS-Lösungen verfügbar sind, haben Unternehmen sie schnell adaptiert. Auch hier bedeutet dies zwar weniger Zeitaufwand für die Administration und den Betrieb dieser Umgebungen für ein einzelnes Unternehmen, aber auch mehr Schnittstellen und Integrationen von Drittanbietern in das SAP-System.

     

    Automatisierter SAP-Betrieb

     

    Alles zusammenfügen

    Heutzutage gibt es kaum noch ein Unternehmen, das sich nicht in einer hybriden Umgebung mit einer Mischung aus On-Premise-, Public Cloud- oder SaaS-Lösungen befindet. Außerdem ist es selten, dass ein Unternehmen seine SAP-Produktionssysteme nicht in einer Art HA/DR-Szenario einsetzt. Man kann sagen, dass dies auf die zunehmende Nutzung der Cloud oder die niedrigeren Hardwarekosten zurückzuführen ist, die die Anschaffung dieser Umgebungen erschwinglicher machen. Wie auch immer, die moderne SAP-Landschaft ist da und die Möglichkeiten zur Verbesserung der 24/7-Verfügbarkeit dieser Umgebungen werden ebenfalls zunehmen. Die Nutzung der Cloud, ob Public Cloud oder SaaS, wird ebenfalls zunehmen. Da diese komplexen Umgebungen immer größer werden, mag es entmutigend oder sogar beängstigend klingen, sich diesen Szenarien zu stellen. Aus diesem Grund ist es wichtig, eine Lösung zu haben, die diese hybriden, leistungsstarken Umgebungen nicht nur überwacht, sondern einen ganzheitlichen Blick darauf liefert und mittels Automatisierung den Betrieb erleichtert..