Die verborgenen Komplexitäten bei der Veröffentlichung neuer Versionen auf IBM^® i

Veröffentlichung einer neuen Version von Rocket^® DevOps ist immer ein Meilenstein. Er repräsentiert monatelange (oder jahrelange) Arbeit von Entwicklungs-, Test-, Dokumentations- und Supportteams. Aber für diejenigen von uns bei IBM^® In einem Ökosystem ist der Veröffentlichungsprozess selten unkompliziert.

Betrachten wir die weniger sichtbaren Aspekte von Produktveröffentlichungen: die Herausforderungen in Bezug auf Kompatibilität, Upgrades und langfristigen Support. Jedes Unternehmen und jedes Produktteam steht zwar vor individuellen Hürden, doch diese drei wiederkehrenden Themen tauchen in meinen Beobachtungen während der Veröffentlichungszyklen immer wieder auf. Wie können Unternehmen diese Herausforderungen meistern?

1. Mit den Updates des IBM i-Betriebssystems Schritt halten.

IBM^® i wird kontinuierlich weiterentwickelt, mit häufigen Technologie-Updates (TRs) und periodischen Hauptversionen. Jede Änderung bringt Verbesserungen, birgt aber auch potenzielle Risiken für Softwareanbieter.

• Kompatibilitätsrisiken: Selbst kleine Änderungen an IBM i können das Verhalten so verändern, dass sie Auswirkungen auf unser Produkt haben. APIs können veraltet sein, Sicherheitsmodelle verbessert oder Systemtools ersetzt werden.
• Testanforderungen: Vor jeder Veröffentlichung investieren wir umfangreich in Tests über verschiedene IBM i-Versionen hinweg, um die Stabilität zu gewährleisten. Dies erfordert nicht nur technischen Aufwand, sondern auch Zugriff auf Testumgebungen, in denen jede unterstützte Version ausgeführt wird.

Was Sie tun können:

• Halten Sie ein dediziertes Labor mit Umgebungen bereit, die alle unterstützten IBM i-Versionen umfassen.
• Arbeiten Sie frühzeitig im Technologieerneuerungszyklus mit IBM zusammen, um grundlegende Änderungen vorherzusehen.
• Bieten Sie Ihren Kunden übersichtliche IBM i-Versionssupportmatrizen an.

2. Wechselwirkungen mit Drittanbieter-Tools

Moderne IBM i-Anwendungen existieren selten isoliert. Unser Produkt integriert sich mit Git.^® Versionskontrollsysteme, CI/CD-Plattformen, Ticketsysteme und sogar Sicherheitslösungen. Die Herausforderung besteht darin, dass sich diese Drittanbieter-Tools unabhängig voneinander weiterentwickeln.

• Versionsabweichung: Eine neue Version eines Drittanbieter-Tools kann unsere Integration plötzlich beeinträchtigen.
• Lieferantenkoordination: Wir sind oft auf die Roadmaps und Prioritäten anderer Anbieter angewiesen, die möglicherweise nicht mit unseren übereinstimmen.

Was Sie tun können

• Setzen Sie nach Möglichkeit auf robuste, standardbasierte Integrationen.
• Pflegen Sie automatisierte Testpipelines, die die Integrationen mit den neuesten Versionen von Drittanbietertools testen.
• Bieten Sie Kunden Hinweise zu „zertifizierten“ Drittanbieterversionen, die wir getestet haben.

3. Aktualisierung von Kunden von älteren Versionen unserer Software

Nicht alle Kunden führen regelmäßig Upgrades durch. Manche nutzen möglicherweise Versionen unseres Produkts, die fünf, zehn oder sogar 15 Jahre alt sind – eine Strategie, die mit erheblichen Risiken verbunden ist. Ein Upgrade auf die neueste Version ist selten mit einem Klick erledigt.

• Mehrere Versionssprünge erforderlich: Manchmal hat sich die Produktarchitektur so grundlegend geändert, dass direkte Upgrades nicht möglich sind. Kunden müssen unter Umständen mehrere Zwischenversionen durchlaufen.
• Datenkonvertierung: Schemaänderungen und Konfigurationstransformationen müssen sorgfältig verwaltet werden, um Störungen zu vermeiden.
• Risikoaversion: Kunden befürchten verständlicherweise Auswirkungen auf unternehmenskritische Anwendungen.

Was Sie tun können

• Bieten Sie klare Upgrade-Pfade und eine Dokumentation mit den erforderlichen Schritten an.
• Wo immer möglich, sollten Migrationshilfsmittel bereitgestellt werden, um Daten- und Konfigurationsübergänge zu automatisieren.
• Bieten Sie professionelle Dienstleistungen oder Partnerunterstützung für komplexe Upgrades an.

4. Unterstützung älterer Versionen bei sich ändernden Abhängigkeiten

Selbst nach der Veröffentlichung einer neuen Version bleiben ältere Versionen weiterhin im Einsatz. Deren Support kann schwierig sein, insbesondere bei Abhängigkeiten von Drittanbietern wie Java.^® oder Compiler entwickeln sich weiter.

Sich verändernde Rahmenbedingungen: Wenn beispielsweise Oracle^® Sollte IBM die Java-Supportrichtlinien ändern, laufen ältere Versionen unseres Produkts möglicherweise nicht mehr zuverlässig.
Kundenerwartungen: Manche Kunden erwarten, dass ältere Versionen weiterhin vollständig unterstützt werden, selbst wenn die zugrunde liegende Plattform nicht mehr mitspielt.

Was Sie tun können

• Definieren und kommunizieren Sie eine klare Support-Lifecycle-Richtlinie (z. B. N-2 Releases).
• Informieren Sie Ihre Kunden im Voraus, wenn Änderungen von Drittanbietern ältere Versionen betreffen.
• Fördern Sie proaktive Verbesserungen anstelle reaktiver Problemlösungen.

5. Weitere erwähnenswerte Herausforderungen

Die oben genannten Probleme treten häufig auf, sind aber keineswegs die einzigen Schwierigkeiten bei der Veröffentlichung einer neuen Version. Zum Beispiel:

• Lokalisierung und Mehrsprachigkeitsunterstützung.
• Hardwareunterschiede an den verschiedenen Kundenstandorten.
• Sicherheitskonformitätsanforderungen (z. B. Verschlüsselungsstandards).
• Kundenspezifische Anpassungen, die Upgrades erschweren.
   

Schlussgedanken

Die Veröffentlichung einer neuen Softwareversion für IBM i bedeutet nie nur die Erweiterung des Funktionsumfangs. Jede Version erfordert ein sorgfältiges Abwägen von Prioritäten, Kompromissen und Risikominimierung. Für Rocket Software stehen Kompatibilität, Kontinuität und das Vertrauen der Kunden im Vordergrund, die unser Produkt für geschäftskritische Anwendungen nutzen.

Es gibt selten einen einzigen, fehlerfreien Ansatz für die Softwareveröffentlichung – insbesondere in komplexen Umgebungen wie IBM i. Erfolg basiert auf einer gezielten Kombination aus disziplinierten Tests und Validierungen, klarer und konsistenter Kommunikation sowie klar definierten Richtlinien für Support und Lebenszyklusplanung. Sind diese Elemente vorhanden, reduzieren Unternehmen Risiken, verbessern die Zuverlässigkeit und gewinnen an Glaubwürdigkeit. Durch Transparenz hinsichtlich der Prozesse, der laufenden Entwicklungen und der Erwartungen fördern wir Vertrauen und schaffen eine solide Grundlage für langfristige Partnerschaften und Leistung.

IBM ist eine Marke der International Machines Corporation

Oracle, Java, MySQL und NetSuite sind eingetragene Marken von Oracle und/oder seinen verbundenen Unternehmen. Andere Namen können Marken ihrer jeweiligen Inhaber sein.

Git und das Git-Logo sind entweder eingetragene Marken oder Marken der Software Freedom Conservancy, Inc. in den Vereinigten Staaten und/oder anderen Ländern.