Bewährte Methoden für die Design-Phase

Die Entwurfsphase einer SAP-Implementierung auf Greenfield ist die Grundlage für eine erfolgreiche Buildphase. In dieser Phase arbeiten Sie mit Ihren Infrastruktur-Stakeholdern zusammen, um die Anforderungen zu sammeln und die Architektur zu dokumentieren. Es gibt auch zusätzliche Anpassungen, die Sie berücksichtigen müssen. Sie müssen dafür sorgen, dass sich die verschiedenen Projekt-Stakeholder auf einen Zeitplan, eine Landschaftsstrategie und eine Architektur von SAP in AWS einigen, einschließlich Hochverfügbarkeits- (HA) und Notfallwiederherstellungs (DR)-Umgebungen. Dieser Abschnitt enthält Empfehlungen zur Bewältigung einiger der Herausforderungen, denen Sie in der Entwurfsphase Ihres Projekts begegnen könnten.

Erstellen Sie Zeitpläne für die Lieferung und Diagramme im Querformat

Erstellen Sie einen Zeitplan für die Bereitstellung der Infrastruktur, sobald Ihnen der Zeitplan für das Geschäftstransformationsprojekt mitgeteilt wird. Dies hilft Ihnen, vorausschauend zu planen und die Abstimmung innerhalb des Infrastrukturteams zu erreichen. Der wichtigste Input für die Erstellung des Zeitplans stammt von den Systemintegratoren (SIs) aus dem SAP-Projektteam. Arbeiten Sie zurück, um die Termine abzuleiten, an denen das SAP-Basis-Team seine Arbeit abschließen sollte und wann die Infrastruktur bereit sein sollte, damit das SAP-Basis-Team die SAP-Anwendungen installieren kann.

Überlegungen:

• Eine visuelle Darstellung des Lieferzeitplans ermöglicht es dem Team, schnell zu verstehen, was gebaut wird, welche Mindesthaltbarkeitsdaten vorliegen und welche Ressourcen möglicherweise knapp sind. Außerdem können wichtige Stakeholder die Umgebungen, die gerade erstellt werden, die Dauer des Projekts und die Übergabe zwischen dem SAP-Basis-Team AWS und dem SAP-Basis-Team auf leicht verständliche Weise visualisieren.

  

• Eine typische Greenfield-SAP-Implementierung erstreckt sich über ein Jahr oder länger. Dazu gehören auch Zeiten, in denen das Infrastrukturteam die Infrastrukturkomponenten nicht aktiv erstellt. Daher ist es wichtig, die Aktivitäten und Ergebnisse während dieser Zeit zu berücksichtigen. Zu den Aktivitäten, die zugeordnet werden müssen, gehören HA-Setup und -Tests, DR-Setup und -Tests, Leistungstests und Skripts für die Gebäudeautomatisierung.

• Bei einer Greenfield-Implementierung kann es verwirrend sein, die Konzepte von Landschaft und Umwelt zu verstehen. Ein farbcodierter Zeitplan, der zwischen Umgebungen und Landschaften unterscheidet (N, N+1, N+2), kann den Stakeholdern helfen, diese Informationsmatrix schnell zu verstehen.

  Hier ist ein Beispiel für ein typisches SAP-Landschaftsdiagramm auf hoher Ebene. Die Boxen stellen Umgebungen dar, bei denen es sich um eine Sammlung von Anwendungen handelt (z. B. SAP S/4HANA), und die Landschaften sind eine Sammlung von Umgebungen, die für eine bestimmte Version verwendet werden.

  

• Wenn Sie die Roadmap erstellen, empfehlen wir Ihnen, die allgemeine Roadmap erneut zu überprüfen und vierteljährlich eine langfristige Planung durchzuführen, bis sich das Team etabliert hat. Beziehen Sie neben der Migration auch andere Roadmap-Elemente wie Arbeitsabläufe für das Cloud Center of Excellence (CCoE), Betriebsautomatisierung, Sicherheit und Compliance sowie Cloud-Notfallwiederherstellung mit ein.

Verstehen Sie regionale Services und dokumentieren Sie Entscheidungen

Wir empfehlen, dass Sie sich zu Beginn der Entwurfsphase Zeit nehmen, um die Dienste zu verstehen und zu besprechen, die in einer bestimmten Region verfügbar sind, AWS-Region damit Sie die primäre Region richtig auswählen können. Insbesondere werden Hochleistungsinstances häufig für SAP benötigt, sodass Sie sicherstellen müssen, dass diese Ressourcen in den primären oder sekundären Regionen verfügbar sind. Wählen Sie einen Instance-Typ, der für SAP-Anwendungen zertifiziert ist. Vergewissern Sie sich, dass der Instance-Typ in der AWS-Regionen Ihrer Wahl verfügbar ist. Eine schnelle und einfache Möglichkeit, dies festzustellen, ist die Verwendung des Befehls AWS Command Line Interface (AWS CLI) für Instance-Typ-Angebote. Wenn in der Region, die Sie für Ihre Implementierung verwenden möchten, derzeit keine Services verfügbar sind, sollten Sie die Vorlaufzeit für die Bestellung der Infrastruktur für diese Region berücksichtigen.

Bestätigen, wiederbestätigen und dokumentieren Sie Entscheidungen, die sich auf die Region beziehen. Verteilen Sie diese Entscheidungen an das gesamte Projektteam, damit die wichtigsten Stakeholder informiert sind. Wenn es einen Architekturprüfungsausschuss für das Projekt gibt, stellen Sie sicher, dass Sie dieses Thema vorstellen, um allen die Möglichkeit zu geben, sich zu äußern, bevor die Entscheidung feststeht.

Überlegungen:

• Ein wichtiger Aspekt sind Grenzsysteme, die sich in SAP integrieren lassen. Wenn Sie Grenz- oder Satellitenanwendungen hosten AWS, empfiehlt es sich, SAP in derselben primären Region zu hosten, um unnötige Diskussionen über Latenz zu vermeiden. Selbst wenn Sie bestätigen, dass Latenz kein Problem darstellt, wird es schwierig sein, Ihren Stakeholdern zu erklären, warum Grenzanwendungen in einer anderen Region entwickelt wurden als Ihre SAP-Anwendungen.

• Der Standort für die Notfallwiederherstellung (DR) sollte auch für SAP und Systeme, die in SAP integriert sind, derselbe sein, damit die DR-Tests realistisch koordiniert werden können. Verschiedene Systeme erfordern möglicherweise unterschiedliche Lösungen. Beispielsweise funktioniert ein großes SAP-System wie BusinessObjects Winshuttle möglicherweise nicht AWS Elastic Disaster Recovery und benötigt möglicherweise eine andere Lösung, die eine Amazon Relational Database Service (Amazon RDS) -Datenbank verwendet.

Festlegung von Namenskonventionen

Prüfen und dokumentieren Sie die Benennungskonventionen für den Host, die SAP-Umgebung, die Virtual Private Cloud (VPC) und die AWS Konten gründlich. Benennen Sie Ihre bestehenden Standards oder Konventionen. Bei einer Greenfield-Implementierung müssen Sie Ihre Namenskonventionen wahrscheinlich von Grund auf neu definieren. Seien Sie konsistent. Wenn Sie beispielsweise die VPC Pre-Prod, die SAP-Umgebung UAT und das AWS Konto TST nennen, wird es aus Sicht des Supports schwierig sein, diese drei Namen miteinander zu verknüpfen. Achten Sie darauf, einen Konsens zu erzielen, und weisen Sie Namen zu, in denen jedes Zeichen eine Bedeutung hat, aber lassen Sie Raum für Flexibilität. Kodieren Sie beispielsweise den Regionsnamen nicht fest in den Servernamen, falls Sie in Zukunft zu einer anderen Region wechseln müssen. Vermeiden Sie die Verwendung der Namenskonvention, die Sie für Ihre On-Premises-Server verwenden. Empfehlen Sie stattdessen eine flexible Cloud-Namenskonvention, falls es in Ihrer Organisation noch keine gibt.

Überlegungen:

• Verwenden Sie AWS -Tagging für Informationen, die sich ändern können.

• Setzen Sie keine Produktionsumgebungen ein, die nicht zur Produktion gehören. VPCs Wenn dies eine Anforderung ist, stellen Sie sicher, dass es einen triftigen Grund gibt, bevor Sie zustimmen.

Dokumentieren Sie alle Entscheidungen

Wir empfehlen, dass Sie jede Variante jeder Entscheidung sorgfältig dokumentieren, wer die Entscheidung getroffen hat, an welchem Datum und wer anwesend war. Speichern Sie die Entscheidungen an einem öffentlichen Ort wie Atlassian Confluence oder in einer Tabelle und sorgen Sie dafür, dass die Entscheidung ordnungsgemäß unterzeichnet wird. Ein Stakeholder oder Teammitglied könnte den erzielten Konsens vergessen und eine Entscheidung zu einem späteren Zeitpunkt in der Entwurfs- oder Erstellungsphase anfechten. In diesem Fall möchten Sie jederzeit Daten zur Verfügung haben, um alle Fragen beantworten zu können. Hier sind einige wichtige Entscheidungen, die Sie dokumentieren sollten:

• Entscheidungen zur Region

• Anwendungen, die HA-relevant sind

• Entscheidungen zur Notfallwiederherstellung

• Modell zur Unterstützung der Umgebung während der Projektphase

• Methoden und Tools für die Backup und Wiederherstellung

• VPC-Struktur

• AWS Kontoentscheidungen

• Entscheidungen zur Sicherheit

Verfolge außerdem alle Anfragen zu Produktfunktionen und dokumentiere, wie lange es gedauert hat, bis das Team die Änderungen umgesetzt hat.