Architekturen in der SAP BTP: Von ersten Tests bis zum weltweiten Einsatz

In der SAP BTP gibt es viele Möglichkeiten, seine Apps und Systeme zu strukturieren. Die Herausforderung ist, dies der Unternehmensstruktur, der Aufteilung von Werken oder lokalen Standorten und der OnPremise IT-Landschaft anzupassen.

Wie im Artikel zur Einrichtung des Global Accounts beschrieben, gibt es mehrere Möglichkeiten, die Architektur in der SAP Business Technology Platform zu strukturieren:

• Global Account: Oberster Account, über welchen die Abrechnung und die Vertragsabschlüsse erfolgen.
• Subaccount: Je Subaccount können Sie unterschiedliche Cloudanbieter und Rechenzentren auswählen. Auch die Verbindung zum OnPremise-System wird häufig auf dieser Ebene eingestellt.
• Space: Weitere Ebene, die in CloudFoundry-Umgebungen möglich ist. Hiermit sind Applikationen innerhalb eines Subaccounts trennbar.
• Datenbank: Auch, wenn diese kein Mittel zur Strukturierung darstellt, ist die Anzahl und deren Einsatz aufgrund der vergleichsweise hohen Kosten, eine wichtige Architekturentscheidung.

Um zu einer sinnvollen Architektur zu gelangen, sollten Sie mehrere Fragen klären. Diese lassen sich selten pauschal beantworten und sind für jedes Unternehmen unterschiedlich. Zu erwarten ist auch, dass sich die Anforderungen über die nächsten Jahre ändern werden, weshalb es bei allen Aspekten wichtig ist, dies zu beachten: Die Skalierbarkeit ist einer der großen Vorteile der SAP Business Technology Platform. Damit ist nicht nur die Skalierung von Hardware-Ressourcen wie RAM oder CPU gemeint, sondern auch die Skalierung von Lösungen innerhalb des Unternehmens.

Die drei wichtigsten Fragen für einen ersten Entwurf der Architektur in der SAP BTP sind die folgenden:

1. Benötige ich ein Entwicklungssystem?
2. Welche Anforderungen habe ich an die Datenhaltung?
3. Wie sieht mein Rollout-Plan auf mehrere Werke, Standorte oder Abteilungen aus?

Entwicklungssystem in der SAP BTP

In fast jeder OnPremise-Landschaft gibt es mindestens ein Entwicklungssystem. Beim Aufbau der Architektur in der SAP BTP stellt sich die Frage, ob hier auch ein eigener Subaccount oder Space zum Entwickeln notwendig ist. Wie die meisten Architekturentscheidungen lässt sich dies nicht pauschal beantworten.

Die drei am häufigsten eingesetzten Szenarien sind die folgenden:

1. Kein Entwicklungssystem in der SAP BTP
2. Eigener Entwicklungs-Space in geteiltem Subaccount mit Quality- / Testing-Space
3. Eigener Entwicklungs-Subaccount

Option 1: Kein Entwicklungssystem in der SAP BTP

Bei vielen Unternehmen werden insbesondere zu Beginn des Umstiegs auf die SAP BTP noch keine eigenen Applikationen entwickelt. Falls dies der Fall sein sollte, kann das Entwicklungssystem zu Beginn bedenkenlos weggelassen werden. Es ist im weiteren Verlauf jederzeit möglich, dieses hinzuzufügen.

Ein weiterer Faktor, der gegen ein Entwicklungssystem spricht, ist, dass alle Kunden von SAP die „gleiche“ BTP und damit auch die gleiche technische Plattform zum Testen besitzen. Somit können die meisten Entwicklungen von Drittanbietern wie beispielsweise Flexus auf deren eigenem Entwicklungssystem entwickelt und getestet werden.

Nach der Entwicklung ist es somit in vielen Fällen nicht mehr notwendig, die OnPremise-Dreischichtarchitektur abzubilden. Stattdessen sind Applikationen direkt im Qualitätssystem testbar.

Option 2: Geteilter Subaccount

Jeder Subaccount, insbesondere durch die CloudFoundry Umgebung darin, ist mit Kosten und Aufwand verbunden. Um die Anzahl der benötigten Subaccounts zu reduzieren, ist es technisch möglich, die Entwicklungen der Qualitätstests mit separaten Spaces innerhalb eines Subaccounts zu trennen.

Neben den reduzierten Kosten hat dies einen weiteren Vorteil. Meistens werden Verbindungen zu OnPremise-SAP-Systemen (Destinations) auf der Ebene von Subaccounts gepflegt. Mit dieser Architektur wäre es möglich, auch eine neue Entwicklung kurzzeitig mit dem Quality-SAP-OnPremise-System zu verbinden.

In vielen Unternehmen ist die Datenlage in Entwicklungssystemen mangelhaft und neue Entwicklungen können erst auf dem Q-System korrekt getestet werden. Mit einem geteilten Subaccount können Sie dieses Hin und Her zwischen Entwicklung und Test auf dem Q-System vereinfachen.

Option 3: Getrennte Subaccounts für Entwicklung und Quality

Insbesondere, wenn viele Entwicklungen durchgeführt werden, externe Unternehmen Zugriff darauf haben oder viele interne Entwickler beteiligt sind, bietet es sich an, einen eigenen Subaccount zu erstellen.

Die Kosten und der interne Aufwand sind zwar erhöht, jedoch ist dies vollkommen gerechtfertigt, wenn die Entwicklung regelmäßig von mehreren Personen erfolgt. Die Trennung der Subaccounts zwischen Entwicklung und Quality erleichtert nicht nur die Rechteverwaltung, sondern sichert auch die vollkommene Trennung zum OnPremise-Quality-System.

Die Empfehlung von Flexus ist zu Beginn mit einem Subaccount für ein Quality-System zu starten. Falls sich im weiteren Verlauf herausstellen sollte, dass Sie eigene Entwicklungen durchführen, können Sie einen separater Space in diesem Subaccount dafür verwenden. Erst, wenn regelmäßig und von mehreren Personen für die BTP entwickelt wird, sollte auf einen eigenen Subaccount umgestiegen werden.

Wie viele Datenbanken werden benötigt?

Hinweis: In diesem Artikel und den Grafiken wird als Datenbank immer die SAP HANA Cloud erwähnt. Es ist auch möglich, eine andere Datenbank zu verwenden, z. B. PostgreSQL. Dies kann bei technischen Implementierungen und auch bei den Kosten einen Unterschied machen, für die strategische Architektur jedoch nicht.

Als einer der wichtigsten und gleichzeitig teuersten Bausteine in der SAP BTP, sollten Sie ein besonderes Augenmerk auf die Datenbank legen. Eine falsche Entscheidung an dieser Stelle kann nicht nur die laufenden Kosten erhöhen, sondern auch für einen Lock-In-Effekt sorgen, wo es schwierig wird, die Daten von einer Datenbank zu einer anderen zu transferieren.

Um zu einer Entscheidung zu kommen, können Sie die folgenden drei Hauptvarianten betrachten. Diese lassen sich in einem weiteren Schritt noch detaillierter ausprägen:

1. Datenbank im gleichen Subaccount oder Space wie die Applikationen
2. Datenbank in getrenntem Subaccount
3. Keine Datenbank

Wichtig: Auch wenn Sie eine Datenbank in mehreren Subaccounts oder von vielen Applikationen gleichzeitig nutzen, sind die Daten darin dennoch sicher voneinander getrennt.

Option 1: Datenbank im gleichen Subaccount oder Space wie die Applikationen

Alle Applikationen laufen in Subaccounts, bei Nutzung der CloudFoundry Umgebung noch zusätzlich in einem Space innerhalb des Subaccounts. Der offensichtliche Ansatz, der gerne zum Start verwendet wird, ist, dass in diesem Subaccount auch die Datenbank erstellt wird.

Somit ist kein weiterer Subaccount notwendig, der zu bezahlen und verwalten ist. Zudem lässt sich innerhalb der Administrationsoberfläche alles einsehen: alle Applikationen und die zugehörige Datenbank.

Bei dieser Option kann nochmal unterschieden werden, ob es eine Datenbank für alle Spaces in diesem Subaccount gibt, oder in jedem Space eine eigene:

Insbesondere, wenn für jeden Space eine eigene Datenbank betrieben werden muss, sind die Kosten sehr hoch, weshalb diese Option nicht zu empfehlen ist, beziehungsweise nur in sehr seltenen Ausnahmefällen.

Eine Datenbank für mehrere Applikationen und Spaces im Subaccount zu erstellen ist jedoch eine vernünftige Architektur, die einige Vorteile bietet:

• Pro Subaccount wird auch ein Rechenzentrum- und Cloud-Anbieter ausgewählt. Falls die Datenbank direkt im selben Subaccount liegt, kann sichergestellt werden, dass keine großen Distanzen zu den Applikationen entstehen.
• Bei vielen Daten oder einer größeren Last auf die Datenbank kann so sichergestellt werden, dass die Perfomance für andere Werke oder Standorte nicht beeinträchtigt wird, wenn von einer Applikation eine große Last entsteht. Es kann also eine Trennung der Datenbank nach Werken oder Standorten durchgeführt werden.
• Pro Subaccount ist die Datenbank individuell skalierbar.
• Administratorberechtigungen lassen sich pro Subaccount verteilen, womit der Administrator der Datenbank aus einem Subaccount keinen Zugriff auf die eines anderen Subaccounts erhält.
• Die individuelle Abrechnung für die Nutzung der Datenbank ist einfach, wenn Sie pro Kostenstelle eine Datenbank verwenden.

Option 2: Datenbank in getrenntem Subaccount

Bei dieser Architektur wird ein eigener Subaccount erstellt, in welchem keine Applikationen, sondern nur die Datenbank läuft. Dies könnte weiter vereinfacht werden, indem die Datenbank nicht in einem eigenen Subaccount, sondern lediglich in einem eigenen Space läuft. In den meisten Fällen ist jedoch ein eigener Subaccount zu empfehlen.

Dies ist möglich, da die Datenbank auch von Applikationen verwendet werden kann, die in anderen Spaces oder Subaccounts laufen. Wie dies eingestellt werden kann, ist im Artikel zum Teilen der Datenbank in andere Spaces oder Subaccounts beschrieben.

Durch diese Trennung von Datenbank und Applikationen entstehen zum Start zwar Mehraufwand bei der Einrichtung und minimal höhere laufende Kosten, jedoch bieten sich Möglichkeiten bei der Skalierung. Der größte Vorteil dabei ist, dass es bei der Art, wie und zu welcher Struktur Sie skalieren wollen, kaum Einschränkungen hiermit gibt. Aus diesem Grund eignet sich dieses Szenario insbesondere dann, wenn geplant ist, die Nutzung der SAP BTP zu intensivieren, jedoch nicht klar definiert ist, wie dies aussieht.

Beispielsweise könnten Sie zukünftig ein Subaccount pro Werk nutzen, ein Subaccount pro „Applikationstyp“, ein Subaccount pro externem Dienstleister oder ein Subaccount pro Teilkonzern. Dies sind nur einige Beispiele, die zeigen sollen, dass es viele Optionen gibt, wie die zukünftige Struktur und Architektur in der SAP BTP aussehen könnte.

Egal, wie Sie zukünftig skalieren wollen, können Sie mit diesem Ansatz darauf reagieren:

• Keine Skalierung notwendig: Alles bleibt, wie es aktuell ist.
• Einige Werke haben ihre eigenen Subaccounts, jedoch läuft nur in einem eine datenbankintensive Applikation: Die zentrale Datenbank wird von allen Werken verwendet, die geringe Datenbankanforderungen haben. Für das eine Werk mit hohen Anforderungen wird eine zweite Datenbank erstellt.
• Einige Subaccounts oder einzelne Applikationen benötigen für Tests geringere Service-Level-Agreements oder Ressourcen der Datenbank: Für diese können Sie gezielt eine weitere Datenbank nutzen, während die zentrale für alle weiteren Applikation bestehen bleibt.
• In allen Subaccounts laufen viele und datenbankintensive Applikationen: Es können beliebig viele weitere Datenbank-Subaccounts zugeschaltet werden. Zu Beginn reicht es vielleicht aus, einen Datenbank-Subaccount für z. B. Europa und einen für Amerika zu erstellen. Bei noch größerer Auslastung können Sie pro Land oder Werk eine eigene Datenbank verwenden.

Option 3: Keine Datenbank

Nicht jede Applikation benötigt zwangsläufig eine Datenbank. Falls Sie diese zum Beispiel nur für temporäre Optimierungen oder Funktionen nutzen, die ihre Daten nicht persistieren müssen, ist auch keine Datenbank notwendig.

Auch Fiori Launchpads oder einfache Weiterleitungen benötigen in den meisten Fällen keine eigene Datenbank.

Rollout-Plan für weitere Werke, Standorte oder Abteilungen

Bei der Frage, wo welche Applikationen laufen sollen, ist die wichtigste Frage, wie der Rollout-Plan aussehen wird. Auch, wenn der genaue Plan vermutlich noch nicht feststeht, sollte bereits zu Beginn überlegt werden, was möglich wäre und welche Optionen nicht sinnvoll sind.

Es gibt mehrere Arten, wie Sie den Rollout gestaltet können wie beispielsweise:

• Rollout einer Applikation von einem Standort auf mehrere weitere
• Rollout mehrerer Applikationen in einem Test-Standort und anschließend gemeinsamer Rollout aller Applikationen auf mehrere Standorte
• Individuelle Applikationen für unterschiedliche Standorte, wodurch kein einheitlicher zentraler Rollout möglich wäre

„Standort“ kann in diesem Szenario unterschiedliche Bedeutungen haben:

• Jedes Werk kann ein eigener Standort sein.
• Jede geographische Region (zum Beispiel Europa, EMEA oder Deutschland) kann ein eigener Standort sein.
• Getrennte Unternehmenseinheiten oder Teilkonzerne können auch „Standorte“ darstellen. Sie sind zwar physisch nicht getrennt, jedoch aufgrund unterschiedlicher Prozesse, Verantwortlichkeiten oder Kostenstellen sehr unterschiedlich.

Je nach Szenario und was ein „Standort“ bedeutet, bieten sich verschiedene Architekturen an. Folgende Grafik zeigt die drei wichtigsten Optionen an, wobei Sie diese natürlich jederzeit mischen können:

Option 1: Alle Applikationen in einem Space

Dies ist die einfachste Option, die oft zu Beginn gewählt wird. Sie hat jedoch den großen Nachteil, dass hier nur unterschiedliche Applikationen startbar sind. Dies bedeutet, dass eine Applikation im Zweifelsfall von mehreren Standorten gemeinsam nutzbar ist.

Einige Applikationen bieten dies auch an, jedoch ist einer der großen Vorteile der SAP Business Technology Platform die Skalierbarkeit, welche hierdurch verloren geht. Die Applikation unterstützt eventuell die ersten beiden Standorte, schafft die Last eines dritten Standortes jedoch nicht mehr. Mit dieser Architektur würde dieses Szenario ein Problem darstellen.

Um dies zu lösen, können Sie pro Standort ein eigener Space verwenden. Dies ist Option 2.

Option 2: Ein Space pro Standort

Mit dieser Option wird pro Standort ein Space erstellt, wobei alle im selben Subaccount liegen. Der Vorteil gegenüber Option 1 ist die Skalierbarkeit. Die gleiche Applikation kann in mehreren Spaces separat und komplett getrennt voneinander laufen.

Ein weiterer Vorteil ist die Verbindung zu OnPremise-SAP Systemen: Diese werden auf Subaccount- oder Space-Ebene gepflegt. Mit dieser Option kann somit sichergestellt werden, dass eine Applikation von Space A nur auf das OnPremise-System A zugreifen darf und Applikation aus Space B nur auf das OnPremise-System B.

Jedoch erfolgt die gesamte Administration zentral für alle Spaces in diesem Subaccount. Darunter fällt nicht nur das Erstellen von Rollen oder die Verbindung zu OnPremise-Systemen, sondern auch das Zuweisen von verfügbaren Systemressourcen.

Insbesondere, wenn dies komplexer wird, Applikationen öfters geupdatet werden müssen und es regelmäßige Änderungen gibt, für die vielleicht auch noch Wissen aus dem Standort notwendig ist, kann dies für die Administratoren sehr aufwendig werden. Mit folgender Option 3 sind diese Aufgaben besser aufteilbar und trennbar.

Option 3: Ein Subaccount pro Standort

Diese erweitert Option 2 mit einer getrennten Administration. Fast alle Einstellungen lassen sich auf Subaccountebene definieren und einstellen. Somit wäre es möglich, dass verantwortliche Personen des Standortes viele oder alle diese Einstellungen direkt pflegen.

Diese Option ist also immer dann zu empfehlen, wenn pro Standort individuelle Einstellungen oder häufige Administrationsausaufgaben durchgeführt werden müssen. Insbesondere dann, wenn diese auch gezieltes Wissen des Standortes benötigen wie beispielsweise, wann das Ende einer Schicht ist, um die Applikation neu zu starten.

Ein weiterer Grund für diese Option wären getrennte OnPremise-SAP-Systeme. Falls jeder Standort sein eigenes produktives SAP-System besitzt, sollten Sie diese Option immer wählen. Aber auch bei einem zentralen SAP-System kann diese Option viele Vorteile bieten, insbesondere die standortindividuelle Flexibilität und Unabhängigkeit von anderen Standorten.

Zusammenfassung und Empfehlung

Wie zu Beginn des Artikels erwähnt und in den drei Abschnitten beschrieben, hängt die Architektur von vielen Faktoren ab. Aus diesem Grund ist es schwierig, eine pauschale Architektur zu empfehlen. Jedoch hat sich in der Praxis gezeigt, dass folgende Architektur eine sehr gute Basis darstellt, die Flexus als „Standard“ empfiehlt:

„Standard“ bedeutet, dass wir mit dieser Architektur als Konzept starten und darauf basierend die drei wichtigen Fragen durchgehen:

• Benötigen wir ein Entwicklungssystem?
• Wie viele Datenbanken benötigen wir?
• Wie sieht der Rollout-Plan aus?

Abhängig von den Antworten auf diese drei Fragen ist dieser Standard anpassbar:

• Beispielsweise können Sie den „Development“ Space streichen, falls Sie keine internen Entwicklungen durchführen.
• Beispielsweise können Sie den „Development & Testing“ Subaccount für jeden Standort duplizieren, falls dies notwendig sein sollte.
• Beispielsweise kann eine zusätzliche Datenbank für den „Development & Testing“ Subaccount hinzugefügt werden, falls die IT-Richtlinien eine vom Production-System getrennte Datenbank vorschreiben.

Viele der in diesem Artikel erwähnten Empfehlungen oder Meinungen sind subjektiv und verallgemeinert auf Basis der Praxiserfahrung, die wir gesammelt haben. Die Möglichkeiten der SAP Business Technology Platform entwickeln sich stetig weiter, weshalb es wichtig ist, die getroffenen Entscheidungen regelmäßig in Frage zu stellen.

Falls wir Sie zum Start in die SAP Business Technology Platform unterstützen und Hinweise aus vergangenen Projekten geben können, steht das Cloud & Technologie Team der Flexus für Sie bereit. Wir entwickeln seit mehreren Jahren Applikationen für die SAP BTP, welche mit OnPremise-SAP- sowie externen Systemen interagieren, große Datenmengen verarbeiten und weltweit eingesetzt werden. Durch diese Entwicklungen und die Inbetriebnahme bei unseren Kunden und Partnern konnten wir viele gute Ideen und Best-Practices entwickeln, die auch Ihnen helfen können.