Die AS/400 ist nicht das Problem

Mir geht es in folgendem Beitrag viel mehr um eine Betrachtung, als um eine Bewertung und schon gar nicht um eine Glaubensfrage. In übersichtlicher Form möchte ich aus meiner Sicht darstellen, wodurch sich die ‚öffentliche‘ Wahrnehmung der AS/400 im Laufe ihres Lebenszyklus so stark gewandelt hat. Mein Bezug zu dem Thema findet sich in einer 5-jährigen Zeit, in der ich nah an der AS/400 tätig war.

Kurz Namen und Konzept erklärt

IBM ist Anbieter einer Hardware-Plattform die sich ‚IBM Power Systems‘ nennt. Historisch ist diese auch als ‚AS/400‘, ‚iSeries‘ und ‚System i‘ bekannt.

Das zugehörige Betriebssystem heißt ‚IBM i‘ und trug früher die Namen ‚OS/400‘ und ‚i5/OS‘. Der Aufbau weißt die Besonderheit auf, dass die Datenbank ‚Db2 for i‘ nativ im Betriebssystem integriert ist.
Das architektonische Zusammenspiel aus Hardware, Betriebssystem und Datenbank sorgt für eine Abgrenzung hinsichtlich Stabilität/Betriebssicherheit und I/O-Leistung im Vergleich zu ‚getrennten‘ x86-Systemen.

Historie

Die AS/400 wurde 1988 von IBM eingeführt und war Nachfolger der IBM ‚System/36‘ und ‚System/38‘. Im Fokus war die Programmiersprache ‚RPG III‘, die von den Vorsystemen übernommen wurde.

RPG hatte die Ausprägung, dass es einen festen Verarbeitungszyklus abbildet und in Programmen (Services) Logik und Bildschirmausgabe (Green-Screen) verbunden abbildet. Man spricht hier von einer monolithischen Struktur, in der Code oft kopiert werden musste, um in anderen Programmen (Services) ebenfalls Verwendung zu finden.

Mit ‚RPGLE‘ führte IBM 1994 den Nachfolger von RPG III ein. Zielsetzung war, künftig prozedural und modular arbeiten zu können und somit auch ein Zusammenwirken mit anderen Programmiersprachen zu ermöglichen (z.B. C++ und Andere).

Status quo

Durch RPGLE können unter IBM i sowohl REST-Server (APIs bereitstellen), wie auch REST-Clients (APIs aufrufen) bereitgestellt werden, um RPG-Anwendungen an Web- und Cloud-Dienste anzubinden.

Problem

IBM hat immer im Fokus gehalten, IBM i mit umfänglicher Abwärtskompatibilität auszustatten. Ein Umstand, der viel Softwareanbieter dahingehend in die Karten gespielt hat, die Modernisierung ihrer Software auszusitzen und bestehenden RPG III-Code beizubehalten. Dieses führte in Konsequenz zu folgenden drei Konflikten:

1. Schlecht lesbarer und nicht dokumentierter Code durch viele Doubletten, was die Wartbarkeit erheblich erschwert und Aufwendungen für Änderungen/Erweiterungen deutlich erhöht.

2. Mangel an Personal für Programmierung, der an der veralteten Code-Basis gebunden ist.

3. Fehlende Modernität der Anwendungen hinsichtlich zeitgemäßer Schnittstellenintegration in Form von REST-API und daraus abstellender Mangel an sauber hinterlegten Services.

Mein Fazit

IBM i ist nicht das Problem, sondern die Kultur verschiedener Softwareanbieter, die nicht die architektonischen Notwendigkeiten in den Fokus ihres strategischen Handelns gelegt haben, um eine moderne Anwendung zu gewährleisten.

Die Daseinsberechtigung für IBM i ist durch Hochverfügbarkeit und Leistungsfähigkeit unbedingt gegeben. Im Umfeld von geschäftskritischen und transaktionsintensiven Anwendungen (z.B. Logistik, Fertigung, Banken, Versicherungen), kann sie sich im Vergleich zu x86-Umgebungen positiv abgrenzen.

Bei Neuprojekten ergeben sich durch IBM i höhere Anschaffungskosten, die aber über mehrere Jahre wieder erwirtschaftet werden können. Bei existenten (veralteten) Lösungen, kann der Erhalt und die Modernisierung der laufenden Anwendungen hingen Vorteile bringen, da das Neuprojekt nicht erforderlich ist.