Systemlandschaft zur Add-On-Entwicklung

Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht.

Dies ist der zweite Teil meiner Antwort auf Christian Drumms Frage What System Landscapes Setup to use for Add On Development? – und wahrscheinlich eher eine Antwort auf die ursprüngliche Frage als der erste Teil. Im Moment entscheiden sich viele Autoren dafür, in ihren Blogs eher obskure Hinweise auf TFA zu platzieren, aber da es in diesem Beitrag um eher grundlegende Aspekte geht, möchte ich einen anderen Rahmen wählen.

Wenn man über die Bereitstellung und Nutzung von Software nachdenkt, ist es eine gute Idee, mit einem eher einfachen Modell von Anbieter und Verbraucher zu beginnen. Durch eine klare Trennung dieser Rollen lassen sich die Anforderungen und Erwartungen der beteiligten Parteien viel einfacher beschreiben. Mir ist durchaus bewusst, dass in der realen Welt die Unterscheidung zwischen Anbieter und Verbraucher nicht unbedingt so scharf ist. Allerdings wird jede Definition einer Zwischenrolle wahrscheinlich Aspekte eines reinen Anbieters sowie eines reinen Verbrauchers enthalten – und wie wir gleich sehen werden, nimmt die Komplexität zu, selbst mit einigen vereinfachenden Annahmen. Beachten Sie auch, dass ich SAP aus dem Bild herauslasse – man könnte SAP als „Infrastrukturanbieter“ bezeichnen, und diese Rolle an sich eröffnet ein völlig neues Universum der Komplexität.

Um die Frage zu beantworten: Nehmen wir an, wir befinden uns vorerst auf der Anbieterseite – der Verbraucher muss auf einen weiteren Blog warten.

Geld verdienen, was sonst? Dazu müssen wir unsere Lösung an den Verbraucher liefern, und diese Lösung enthält eine ABAP-basierte Software – andernfalls wäre es ziemlich sinnlos, dies hier zu lesen. Wir verwenden die Software nicht selbst, sondern stellen sie nur mehr oder weniger anonymen Kunden zur Verfügung. (Das ist tatsächlich wichtig: Es ist eine gute Idee, davon auszugehen, dass man nichts über die Implementierungsdetails des Kunden weiß, da dies einen vor gefährlichen Annahmen mit unangenehmen Folgen bewahrt.)

Viele Details der tatsächlichen Systemlandschaft hängen von einer Reihe von Entscheidungen ab, die spezifisch für die Lösung sind, die wir liefern möchten. Bevor wir also den Entwicklungs- und Bereitstellungsprozess definieren, müssen wir in der Lage sein, einige Fragen zu beantworten:

• Welche Abhängigkeiten hat unsere Lösung – denken wir in Softwarekomponenten? SAP_BASIS sicherlich, aber was brauchen wir noch? ERP? HR? CRM? Welche Anforderungen stellen diese Abhängigkeiten? Welche Versionen der Abhängigkeiten müssen wir unterstützen?
• Welche Technologien werden wir verwenden? Müssen wir für eine dieser Technologien besondere Vorkehrungen treffen?
• Welche Art von Release- und Patch-Zyklus planen wir? Wie viele gleichzeitige Hauptversionen müssen wir pflegen? (Tipp: Wählen Sie nach Möglichkeit eine ungerade Zahl unter 3.)
• Welche nicht-technischen externen Faktoren gibt es, die sich auf unseren Release-Zeitplan auswirken werden? Müssen wir gesetzliche Änderungen befolgen und/oder zu festen Terminen liefern, damit unsere Kunden die vorgeschriebenen Fristen einhalten können? Müssen unsere Kunden aufgrund gesetzlicher Bestimmungen ohnehin regelmäßig Updates durchführen müssen? Und wenn nicht, können wir sie davon überzeugen, dies trotzdem zu tun, oder müssen wir dann veraltete Patch-Levels unserer Software unterstützen?

Natürlich können wir diese Fragen nicht im Detail für den hypothetischen Anbieter beantworten, den wir gerade in Betracht ziehen, aber die Auswirkungen jeder Entscheidung sollten im Laufe dieser Diskussion deutlich werden.

Wir werden hier nicht über allgemeine bewährte Verfahren der Softwareentwicklung wie Unit-Tests, Integrationstests, Dokumentation und dergleichen sprechen. Diese Aspekte sind natürlich sehr wichtig, um ein stabiles, wartbares Produkt herzustellen, aber wir gehen davon aus, dass unsere Entwickler darüber Bescheid wissen und nicht immer wieder daran erinnert werden müssen. Wir dürfen jedoch nicht vergessen, dass wir für viele dieser Aufgaben eine Arbeitsumgebung benötigen, und dazu gehören sowohl die richtigen Versionen unserer Abhängigkeiten als auch eine brauchbare Konfiguration. Wie müssen wir die Abhängigkeiten konfigurieren, bevor wir mit der Erstellung unserer eigenen Software beginnen können, und welche Konfigurationen benötigen wir, um die verschiedenen Verwendungsmöglichkeiten der Software durch unsere Kunden zu testen Software verwenden könnten? Auch hier gilt: Für eine hypothetische Lösung können wir keine Antwort geben, aber Sie verstehen, was ich meine – es gibt einige ziemlich zeitaufwendige Aktivitäten, die im Dunkeln einer unbeantworteten Frage lauern.

Für die folgende Diskussion gehe ich davon aus, dass wir das Add-On Assembly Kit (AAK) verwenden, um die ABAP-Softwarekomponenten bereitzustellen. Wenn Sie sich nicht ganz sicher sind, warum, finden Sie meine persönliche Meinung zu diesem Thema hier. Es schadet sicherlich nicht, im Detail zu wissen, wie das AAK funktioniert, aber dafür haben wir keine Zeit. Daher sind hier die grundlegenden Ideen, die Sie verstehen müssen, um die folgende Diskussion zu verstehen.

• Mit dem AAK liefern wir Softwarekomponenten (z. B. Tabelle CVERS, SAP_BASIS). Physisch versenden wir ein SAR-Archiv, das eine PAT-Datei enthält, die wiederum die eigentlichen Paketdateien (beginnend mit SAPK-) enthält. Wenn wir und diese Pakete als Transporte mit zusätzlichen Funktionen vorstellen, reicht das fürs Erste.
• Wir können Transporte innerhalb der Systemlandschaft verwenden. Irgendwann sammeln wir alle Dinge, die wir liefern möchten, an einem zentralen Ort (System) und führen Ihre Unit- und Integrationstests durch (hier nicht behandelt). Dann entscheiden wir, was genau ausgeliefert werden soll, führen einige zusätzliche Prüfungen durch und erstellen die Paketdateien. Dies geschieht mit dem sogenannten Software Delivery Composer (SDC) und führt zu den SAPK--Dateien.
• Der Paketinhalt wird dann mit dem Software Delivery Assembler (SDA) in lieferbare PAT-Dateien umgewandelt. In diesem Schritt werden Abhängigkeiten und andere Attribute zu den Paketdateien hinzugefügt, um PAT-Dateien zu erstellen. Die PAT-Dateinamen bestehen aus der ID des Assemblierungssystems, der Installationsnummer und einer fortlaufenden Nummer.
• Die SAR-Dateien müssen manuell (oder mit einem benutzerdefinierten Programm) verpackt werden. Dabei handelt es sich lediglich um Archive, die vom Kunden bequemer hochgeladen und installiert werden können.
• Die AAK kann verschiedene Arten von Paketen für unterschiedliche Szenarien erstellen, mit denen unsere Kunden konfrontiert werden könnten. Die wichtigsten sind Pakete für die Erstinstallation (enthält die aktuellen Versionen von allem), Upgrades (enthält nur die Änderungen), Versions-Upgrades (ähnlich, aber mit versionsspezifischen Änderungen) und Patches (Fehlerbehebungen, keine neuen Objekte).

Aber genug der Abschweifungen – die Frage ist immer noch nicht beantwortet: Was wollen wir?

• Wenn wir Entwickler sind, möchten wie so viel Zeit wie möglich mit der Arbeit an coolen neuen Dingen verbringen, ohne dass uns die lästige Auslieferungsinfrastruktur im Weg steht.
• Wenn wie für Tests und Support verantwortlich sind, benötigen wie ein dediziertes System für jede unterstützte Kombination von Versionen und Patches (und wahrscheinlich sogar separate Systeme für Unicode und NUC) für sofortige Testmöglichkeiten und die vollständige Abdeckung aller möglichen Installationsszenarien. Wir möchten die hässlichen Fehler finden, bevor die Software ausgeliefert wird, und wenn Systeme überhaupt beschädigt werden müssen – nun, dann besser nicht die Systeme des Kunden.

• Wenn wir der CEO sind, möchten wir so wenig Systeme wie möglich. Diese Dinge sind nicht umsonst, nicht wahr?
• Wenn wir ein verantwortungsbewusster CEO sind, möchten wir alles, was erforderlich ist, um die Qualität und Leistung zu liefern, die die Kunden wünschen – aber nicht mehr als das.

Und wenn wir der Delivery Manager sind und genau in der Mitte sitzen…?

Neinneinnein, nicht so schnell. Wir sind dafür verantwortlich, dass unsere Software den Verbraucher in einem Stück erreicht und ohne unser (schlechtes) oder ihr (SEHR schlechtes!) System zu beschädigen, also sollten wir uns besser mit den Vereinbarungen vertraut machen.

Eine AAK-basierte Bereitstellung erfordert mindestens ein Bereitstellungssystem für jede unterstützte SAP_BASIS-Version. Wir werden nicht für jedes Patch-Level ein eigenes Liefersystem benötigen, aber wenn es zu bedeutenden Änderungen kommt (z. B. 7.40 SP 05), könnten verschiedene Liefersysteme erforderlich sein. Es sei denn, wir können die Installation dieses Patches in unseren Liefersystemen entweder so lange aufschieben, bis alle Kunden dieses Patch-Level installiert haben (z. B. weil es Teil eines SP-Stacks ist, der rechtliche Anpassungen enthält) oder einfach die Systemanforderungen, die wir unseren Kunden auferlegen, erhöhen. Ähnlich verhält es sich, wenn unterschiedliche Releases oder unterschiedliche Patch-Level unserer Abhängigkeiten (wie ERP oder CRM) erforderlich sind. Dann könnten unterschiedliche Test- und Liefersysteme eine gute Idee sein – aber dazu später mehr. (Erinnern Sie sich an die Ausgangsfragen? Wie Sie sehen, wird es schon unübersichtlich, und wir haben noch keine einzige Systemlandschaft entworfen.)

Was ist nun ein Auslieferungssystem in diesem Zusammenhang? Es ist das Quellsystem der technischen Installationspakete – hier erfolgt die SDC-Verarbeitung, und die SAPK--Paketdateien werden von hier exportiert. Es ist normalerweise keine gute Idee, vom Entwicklungssystem aus zu liefern – oder vielmehr, aktiv innerhalb des Auslieferungssystems zu entwickeln. Wenn wir dies zuließen, müssten wir wahrscheinlich alle Entwickler während eines Bereitstellungsprozesses aussperren – oder riskieren, dass jemand aus Unachtsamkeit den Assemblierungsprozess unterbricht. Außerdem enthält ein Entwicklungssystem in der Regel lokale Testobjekte, interne Tools und in den meisten Fällen einige ziemlich einfallsreiche Anpassungen, die von den Entwicklern vorgenommen wurden, um einen seltsamen Zustand zu reproduzieren oder eine neue Funktion auszuprobieren. Wir wollen nicht, dass das in unserem Installationspaket landet, und wir wollen nicht, dass irgendetwas in unserem Installationspaket versehentlich von diesem Zeug abhängt (stellen Sie sich z.B. ein Datenelement /FOO/BAR vor, das geliefert werden soll, aber immer noch von einer Domäne in $TMP abhängt).

Die übliche und in der Tat einfachste Antwort darauf ist, zumindest die Entwicklung von der Auslieferung zu trennen und dafür unterschiedliche Systeme zu verwenden. Ein vernünftiger Ansatz wäre es, die Test- und Auslieferungsumgebung in einem System zu kombinieren (aber separate Mandanten für Tests verwenden – das ermöglicht auch unterschiedliche Testumgebungen). Entwickler entwickeln und veröffentlichen Transporte wie gewohnt, und diese Transporte werden in das Auslieferungssystem importiert. Wenn eine Lieferung erforderlich ist, würden wir einen Transport-/Importstopp für das Auslieferungssystem verhängen, die Tests durchführen und die Pakete zusammenstellen, während die Entwickler in ihrem separaten Entwicklungssystem weiter programmieren können. Dies hat auch den Vorteil, dass Transporte dazu verwendet werden können, die geänderten Objekte, die geliefert werden müssen, zu sammeln und zu gruppieren.

Beim Zusammenstellen der PAT-Dateien während des Lieferprozesses müssen wir einige zusätzliche Bedingungen und Voraussetzungen eingeben, die in der gelieferten Software enthalten sind und während der Installation überprüft werden. Es versteht sich von selbst, dass jeder Fehler machen kann – und bei genügend Zeit auch machen wird. Daher ist es sehr sinnvoll, diese Importbedingungen durch eine Testinstallation zu überprüfen. (Dies ist auch für die Zertifizierung obligatorisch, die wiederum für den Erhalt des AAK obligatorisch ist.) Wir werden auch verschiedene Upgrade-Pfade überprüfen wollen (werden diese ausgefallenen Datenmigrations-Tools tatsächlich funktionieren?) und wahrscheinlich eine Schätzung der Gesamtinstallationszeit abgeben müssen. Natürlich können wir dafür weder das Entwicklungssystem noch das Auslieferungssystem verwenden, da unsere Softwarekomponente dort bereits vorhanden ist und wir nichts irgendetwas kaputt machen. Nein, wir brauchen ein „Vanilla“-System, mit dem wir einen Testimport durchführen können. Es sollte sich dabei besser um ein virtualisiertes System handeln, damit wir einen Snapshot erstellen, die Testinstallation durchführen und dann zum gespeicherten Zustand zurückkehren können. Häufig werden wir mindestens zwei Testinstallationen durchführen wollen (Neuinstallation und Upgrade von der neuesten Version), und in einigen Fällen kann es sinnvoll sein, Systeme mit verschiedenen Releases und Patch-Levels zum Testen zur Verfügung zu haben. Diese Systeme sind in der Regel überhaupt nicht angepasst und es finden dort keine Funktionstests statt – dies hätte vor der Auslieferung geschehen müssen, um die Anzahl der Auslieferungsiterationen gering zu halten. Mit der steigenden Anzahl von Installationstestsystemen wird es außerdem ziemlich aufwendig, sie alle auf dem neuesten Stand und korrekt angepasst zu halten. Diese Systeme sind lediglich Ziele, um zu überprüfen, ob wir ein installierbares Paket erstellt haben.

Nachdem wir nun ein grundlegendes Verständnis der benötigten Systeme haben, wollen wir uns ansehen, wie diese Landschaft aussehen wird:

Das sieht jetzt schön und kompakt aus, aber Ruhe bewahren – wir sind noch nicht fertig. Zunächst einmal gibt es ein nicht ganz offensichtliches Problem bei der Wartung unserer Lösung. Sobald die Auslieferung von, sagen wir, Version 3 abgeschlossen ist und die Kunden mit der Installation der neuen Software beschäftigt sind, beginnen die Entwickler ihrerseits mit der Arbeit an neuen Funktionen in Vorbereitung auf Version 4. Sobald also Transporte von D01 zu A01 wieder aktiviert sind, wird das Liefersystem nicht lange in dem Zustand bleiben, in dem es für die Zusammenstellung der Lieferung verwendet wurde. Da das Liefersystem nicht mehr einem hypothetischen Kundensystem ähnelt (und es sogar gelegentlich während der Entwicklung kaputt gehen könnte), ist es nicht mehr möglich, Probleme zu reproduzieren oder Fehlerbehebungen mit genau derselben Software zu testen, die der Kunde installiert hat. Das ist schlecht, vor allem, wenn ein besonders fieser Fehler unserer kollektiven Aufmerksamkeit beim Testen entgangen ist. Wie können wir das verhindern?

Die naheliegende Lösung wäre, keine Transporte bis kurz vor dem Liefertermin zu importieren. Dies wird jedoch im Allgemeinen als schlechte Idee angesehen, da viele Probleme in der Regel durch Transportieren und Importieren identifiziert werden (z. B. fehlende Abhängigkeiten, versehentlich mit $TMP markierte Objekte und andere grundlegende Fehler), sodass eine Verzögerung nicht wünschenswert ist. Außerdem müssen manchmal Transporte aus verschiedenen Gründen freigegeben werden, sodass sich eine Warteschlange von Transporten ansammeln kann. Wenn wir fehlerhafte Transporte Wochen oder Monate nach ihrer Freigabe beheben müssen, kann dies unseren Lieferplan durcheinanderbringen. Was ist also die Alternative, wenn wir die Möglichkeit benötigen, ältere Versionen unseres Produkts kontinuierlich zu unterstützen? Richtig, ein anderes System – oder eine andere Reihe von Systemen. Diese Wartungssysteme sind in der Regel Kopien des Liefersystems, die bereits vollständig für Tests angepasst sind. Jedes Mal, wenn eine neue Version veröffentlicht wird, wird eine Kopie des Liefersystems verwendet, um ein neues Wartungssystem zu erstellen. Sobald eine ältere Version nicht mehr unterstützt wird, wird das Wartungssystem heruntergefahren.

Diese Wartungssysteme haben auch einen anderen Nutzen. Wie das Sprichwort sagt: Nach der Veröffentlichung ist vor der Veröffentlichung – die Entwicklung geht weiter, neue Funktionen werden erfunden und transportiert, virtuelle Gräben werden ausgehoben und es wird Material für die Überarbeitung vorbereitet, Refactoring findet überall statt. Das Entwicklungsteam hackt fröhlich vor sich hin, bis – ein Fehler auftritt. Er muss behoben werden – und zwar schnell. Die vom Fehler betroffenen Objekte befinden sich jedoch bereits in einem anderen Zustand als dem, der geliefert wurde, und sie sind nicht mehr mit der alten Version kompatibel. Und selbst wenn dieser bestimmte Teil der Software nicht betroffen war, ist das gesamte Produkt möglicherweise nicht in einem nutzbaren und testbaren Zustand. Natürlich können wir unser Entwicklungssystem nicht zur Erstellung des Fixes verwenden. Auch hier rettet das Wartungssystem die Situation: Die Entwickler können einen Fix im Wartungssystem implementieren und dort testen, und wir können einen Patch von diesem System aus bereitstellen. Beachten Sie, dass der Kunde zur Implementierung des Fixes entweder den neuesten Patch importieren oder die Korrektur manuell implementieren muss – es gibt meines Wissens nach keinen Hinweis-/Korrektur-Support für Produkte von Drittanbietern.

Es sollte beachtet werden, dass es unter bestimmten Umständen möglich ist, ohne Wartungssysteme zu arbeiten. Ob wir diesen Ansatz verwenden können, hängt im Wesentlichen von der Stabilität unserer Software (oder eher dem Mangel daran) und der zeitlichen Dringlichkeit der Korrekturen ab, die wir möglicherweise liefern müssen: Wenn unsere Software die meiste Zeit relativ stabil bleibt und/oder die Verbraucher längere Wartezeiten tolerieren können, können wir die Flexibilität bei der Entwicklung gegen eine einfache Systemlandschaft eintauschen:

Wie wir sehen, können während der aktiven Entwicklungs- und Testphase keine Patches veröffentlicht werden und Kunden müssen immer die gesamte Software aktualisieren, um die neuesten Patches sowie Funktionsupgrades zu erhalten, an denen sie möglicherweise gar nicht interessiert sind. Während dies in manchen Situationen ein durchaus vernünftiger Ansatz sein kann, kann er sich in anderen Situationen als völlig nutzlos erweisen.

Bisher haben wir nur einen aktiven Entwicklungsstrom mit gelegentlichen Korrekturen an der vorherigen Version in Betracht gezogen. Theoretisch wäre es möglich, Version 1.0 zu veröffentlichen und mit der Wartung zu beginnen, dann mit der Verbesserung (nicht nur der Fehlerbehebung!) der Software zu beginnen und eine Reihe von 1.x-Upgrades zu erstellen, während gleichzeitig mit der Arbeit an einem völlig neuen Zweig begonnen wird, in dem Version 2.0 produziert wird. Das mag nach einer guten Idee klingen, ist es aber in der Praxis selten: Die Möglichkeiten, etwas zu vermasseln, nehmen exponentiell zu, und es erhöht die Komplexität der Entwicklung und den Testaufwand erheblich – nicht nur für das eigene Entwicklungs- und Testpersonal, sondern auch für unsere Kunden. Dieser Ansatz bietet selten einen geschäftlichen Vorteil, weder für den Anbieter (also uns) oder den Verbraucher (also diejenigen, die uns bezahlen werden – oder auch nicht). Ein echtes ? REDO FROM START ist selten erforderlich, und meiner Erfahrung nach sollten wir diese Situation am besten so behandeln, als würden wir ein völlig neues Produkt unter einem anderen Namen starten, das eine andere Codebasis hat und nicht vom alten Produkt abhängt. Also kein Boom.

So pessimistisch dieser Ansatz auch sein mag, er hat seine Vorzüge. Denn – nun, wir sind noch nicht am Ziel. Bisher haben wir nur die Versionierung und Wartung unserer eigenen Lösung betrachtet. Wie bereits in der Einleitung erwähnt, müssen wir in der Regel Software für mehr als eine Zielversion bereitstellen. Um die Situation zu vereinfachen, konzentrieren wir uns auf die SAP_BASIS-Version, da dies ohnehin von der AAK gefordert wird, obwohl dasselbe Schema auch für andere Abhängigkeiten gelten könnte. Auch hier erfordert die Lösung dieser Situation die Verwendung mehrerer Auslieferungssysteme und Installationstestsysteme, jedoch mit einem anderen Ansatz: Wir versuchen nun, dieselbe Software (einschließlich Patches) für verschiedene Plattformversionen zu erstellen. Wenn wir einfach auch die Entwicklungssysteme vervielfachen, werden die Entwickler die Messer wetzen, sodass dies keine Option ist. Können wir das Entwicklungssystem nicht einfach zentralisieren? Das können wir, aber das führt zu einer anderen Frage: Was ist die Baseline?

An dieser Stelle müssen wir einen kurzen Umweg machen und über den Aufwärts- und Abwärts-Transport nachdenken – das heißt, Entwicklungsobjekte zu einer höheren oder niedrigeren Zielversion zu transportieren. Der Transport „nach oben“ ist normalerweise möglich und nicht sehr problematisch – Objekte, die auf niedrigeren Versionen entwickelt wurden, funktionieren in der Regel (zumindest technisch) auch auf höheren Versionen. Ein Entwicklungssystem SAP_BASIS 7.02, das Objekte an ein Liefersystem 7.40 liefert, ist daher in der Regel kein Problem. Wir könnten daher die niedrigste Zielversion, die wir für die Bereitstellung unseres Produkts benötigen, als Baseline wählen. Dies schränkt jedoch Entwickler auf eine relativ alte Version der Entwicklungsumgebung (z. B. könnte die Verwendung von ADT eingeschränkt sein). Dies ist sicherlich nicht vorteilhaft, aber meiner Erfahrung nach neigen viele Entwickler dazu, dies zu tolerieren, wenn sie die Gefahren der anderen Option verstehen: Das Entwicklungssystem auf der höchsten unterstützten Version zu belassen und Objekte nachgelagert zu transportieren. Dies wird nicht offiziell unterstützt und kann zu Fehlern führen – sowohl technisch während des Transportprozesses als auch innerhalb der Programmierung selbst. Aus technischer Sicht enthalten neuere Versionen in der Regel mehr Optionen, größere Datenbanktabellen und ausgefeiltere Tools. Der Transport von Objekten, die mit diesen neuen Tools erstellt wurden und bei denen bereits einige der neuen Optionen festgelegt und zusätzliche Felder ausgefüllt sind, zu einer niedrigeren Version, die diese Optionen und Felder nicht hat, kann eine Reihe von unerwünschten Nebeneffekten haben. Was den Programmcode betrifft – stellen Sie sich einen Entwickler vor, der die neuen, ausgefallenen Operatoren, die mit 7.40 SP 05 eingeführt wurden im Entwicklungssystem verwendet, nur um herauszufinden, dass diese in den niedrigeren Versionen nicht funktionieren. Oder stellen Sie sich vor, jemand verwendet eine coole neue Klasse, um UUIDs, Zufallszahlen oder eine andere API zu erstellen, die in niedrigeren Versionen nicht existiert. Das ist überhaupt nicht lustig. SAP arbeitet tatsächlich so, entwickelt auf der neuen Version und portiert dann bei Bedarf Funktionen nach unten, aber SAP hat andere Tools und ausgefeiltere Systemlandschaften (und viel mehr Leute!) zur Verfügung. Kleinere Entwicklungsunternehmen haben diese Möglichkeit nicht und sind in der Regel mit einem Up-Porting besser bedient, auch wenn dies das für Entwickler verfügbare Toolkit einschränkt – daher entscheiden wir uns für diese Option.

Betrachten wir nun die Software selbst. Kein Produkt ist eine Insel – es gibt immer Verbindungen zur Plattform und zu den umgebenden Komponenten. Die Frage ist: Ändert sich eine dieser verbundenen Komponenten von einer Version zur nächsten so, dass wir unsere Software für verschiedene Versionen unterschiedlich schreiben müssen? Wenn dies nicht der Fall ist, wenn unsere Software für alle Zielversionen gleich bleibt, ist das gut: Wir benötigen nur ein Entwicklungssystem, das Transporte an mehrere Liefersysteme liefert. Im äußersten Notfall können kleine Patches, die für einzelne Zielversionen erforderlich sind, sogar im Liefersystem implementiert werden.

Wenn dies jedoch nicht möglich ist, weil die Software je nach Zielversion erheblich angepasst werden muss, ist es eine gute Idee, unsere Software so zu organisieren, dass wir versionsunabhängige Teile von versionsabhängigen Teilen trennen. In diesem Fall lohnt es sich auch, versionsabhängige Anpassungssysteme zwischen dem zentralen Entwicklungssystem und den Auslieferungssystemen hinzuzufügen.

Um den Entwicklern zumindest Zugang zu einigen der neueren Technologien zu ermöglichen, könnte es außerdem eine Option sein, bei einer bestimmten Version einen Schnitt zu setzen: Bei allen Versionen darunter erhalten Verbraucher nur Wartungskorrekturen, aber keine neuen Funktionen oder andere aktive Entwicklungen finden auf den älteren Versionen statt. Dadurch können wir die Basisversion zumindest ein wenig anheben.

Endlich – wir haben es fast geschafft, einen Moment noch – es gibt noch zwei weitere Systeme. Eines davon ist wahrscheinlich erforderlich: Soweit ich weiß, benötigen Sie eine Solution Manager-Installation, um die Systemlandschaft zu installieren und zu warten. Leider weiß ich so gut wie nichts über den Solution Manager. Was ich weiß, ist, dass es von Vorteil sein könnte, ein weiteres System zur Landschaft hinzuzufügen, das zur zentralen Zusammenstellung der Lieferpakete verwendet wird (der SSDA-Schritt, der SAPK--Dateien in PAT-Dateien umwandelt). Es gibt eine Reihe von Gründen, die dafür sprechen:

• Es ist sehr praktisch, ein einziges System zu haben, das alle Pakete kennt, z. B. um Download-Portale oder andere Liefersoftware zu befüllen.
• Wenn Auslieferungssysteme regelmäßig hinzugefügt und entfernt werden, können Paketdetailinformationen verloren gehen. Wenn diese Informationen an einem zentralen Ort gespeichert werden, besteht keine Gefahr, dass Paketdaten nicht mehr verfügbar sind.
• Alle PAT-Dateinamen enthalten die SID des Systems, das die Datei erstellt hat. Für den Kunden ist es konsistenter, wenn in den gelieferten Dateien nur ein Systemname erscheint.
• Die Paketzusammenstellung und -zuordnung ist etwas knifflig – wir möchten nicht, dass der durchschnittliche Entwickler an den Paketattributen herumspielt.

Außerdem könnte dieses System als TMS-Domänencontroller verwendet werden, um eine zentrale Benutzerverwaltungslandschaft (CUA) bereitzustellen oder um die Rollen zu erstellen, die dann in der gesamten Systemlandschaft verteilt werden.

Okay – jetzt, da wir alle Puzzleteile gesammelt haben, können wir uns eine Systemlandschaft für eine Single-Stream-Produktentwicklung zusammenstellen. Nehmen wir an, dass wir nicht-triviale Anpassungen an den Zielversionen vornehmen müssen, für die wir Software bereitstellen, und dass wir Patches für die letzten beiden von uns veröffentlichten Versionen pflegen und erstellen müssen. Wir müssen die SAP_BASIS-Versionen 7.31 und 7.40 aktiv unterstützen, wobei 7.31 unsere Basisversion ist, während wir die Infrastruktur für die Bereitstellung von Patches für unsere älteren, auf 7.02 basierenden Versionen aufrechterhalten. Wenn wir schon dabei sind, können wir auch schon die Pläne für die Aufnahme der neuen Version 7.50 in die Landschaft berücksichtigen.

Ist das nicht schön? 21 Systeme und es werden immer mehr, SolMan nicht mitgerechnet …

Meine wichtigsten Aussagen:

• Wir müssen die Erwartungen unserer Kunden und die technischen Einschränkungen genau verstehen, um die bestmögliche Strategie und Systemlandschaft zu entwickeln.
• Wir benötigen außerdem einen kompetenten Basisadministrator (der NICHT auf Stundenbasis abrechnet!) und/oder jemanden mit kombinierten Administrations- und Entwicklungsfähigkeiten im eigenen Haus, um die Systeme zu warten und zu optimieren.
• Selbstverständlich benötigen wir auch die finanziellen Mittel für die Systemlandschaft. Soweit ich weiß, lizenziert SAP nach Entwicklungsbenutzern, nicht nach Systemen, aber die Infrastruktur benötigen wir in jedem Fall.

Als Lohn erhalten wir die Möglichkeit, ABAP-Produkte mit hohen Qualitätsstandards und zuverlässigen, geprüften Lieferprozessen zu liefern und zu warten, während das Risiko und der Aufwand für den Kunden relativ gering gehalten werden.

Wie immer ist eine sorgfältige Planung und gründliche Vorüberlegung angebracht - viele wichtige Gedanken, denn: