Was macht ein AS/400 Developer? — Überblick, Skills und Karriere in Deutschland

Einleitung: Warum AS/400 beziehungsweise IBM i heute noch relevant ist

Gemeint ist die IBM‑Plattform, die historisch als AS/400 bekannt wurde und seit vielen Jahren als IBM i auf IBM Power Systems weiterentwickelt wird. Ihr Kernversprechen: hohe Integration, Stabilität, Sicherheit und eine relationale Datenbank (Db2 for i) als fester Bestandteil des Betriebssystems. IBM beschreibt diese Architekturmerkmale – etwa Single‑Level‑Storage, Objekt‑Sicherheit und die technikunabhängige Maschinen‑Schnittstelle (TIMI) – als zentrale Gründe für die außergewöhnliche Langlebigkeit geschäftskritischer Anwendungen auf der Plattform. Wer sich ein technisches Grundverständnis aufbauen will, findet eine kompakte Einführung direkt bei IBM unter "Getting started with IBM i" (Link).

Für Bewerber:innen ist wichtig: IBM i wird aktiv weiterentwickelt und ist in manchen Bestandslandschaften weiterhin zentral – die konkrete Relevanz hängt jedoch von der jeweiligen Organisation ab.

Kurzprofil: Was ein AS/400 Developer konkret tut

Ein AS/400 Developer (heute meist „IBM i Developer“ genannt) entwickelt, wartet und modernisiert Anwendungen, die auf IBM i laufen. Er oder sie arbeitet nah an der Fachlichkeit, weil viele IBM‑i‑Systeme Geschäftsprozesse wie Produktion, Lager, Verkauf, Zahlungsabwicklung oder Disposition direkt abbilden.

Typische Aufgaben im Alltag

Anwendungen entwerfen und implementieren – häufig in ILE RPG (moderne, freiformatierte Syntax), CL, SQL und in Teilen auch COBOL.
Datenmodellierung und Arbeiten mit der integrierten Db2 for i: Tabellen, Indexe, Views, Trigger, Prozeduren; Performance‑Analysen und Tuning im Zusammenspiel mit dem System.
Schnittstellen entwickeln und pflegen: von klassischen Dateiaustauschen über SQL‑Services bis zu Web‑ und REST‑Schnittstellen, wenn die Systemlandschaft dies vorsieht.
Fehleranalyse, Debugging und Wartung produktiver Jobs, inklusive Journal‑gestützter Nachverfolgung und Rollback‑Szenarien, die IBM i nativ unterstützt.
Begleitung von Changes und Releases im laufenden Betrieb – häufig mit hohem Anspruch an Ausfallsicherheit.

Verantwortlichkeiten in Projekten und im Betrieb

Change‑Requests umsetzen, Regressionen vermeiden, Regressionstests mitgestalten.
Stabilität und Security der produktiven Workloads beachten – auf IBM i sind Subsysteme und Objekt‑Sicherheit zentraler Teil des Betriebskonzepts.
Zusammenarbeit mit Fachbereichen: Prozesse verstehen, Anforderungen präzisieren, Nebenwirkungen im Kernsystem bewerten.
Dokumentation und Wissenstransfer, oft mit Blick auf langlaufende Systeme und historisch gewachsene Domänenlogik.

Technologischer Kontext: Die Plattform verstehen

IBM i kombiniert Betriebssystem, Datenbank und Middleware eng miteinander. Laut IBM ist die integrierte Db2 for i Bestandteil des OS und kein „separat installiertes“ Produkt. Das reduziert Administrationsaufwand und ermöglicht tiefe Optimierungen. Weitere prägende Plattformmerkmale sind:

Single‑Level‑Storage: Speicherverwaltung ist systemisch vereinfacht und entlastet Anwendungen und Betrieb.
TIMI: Anwendungen bleiben über Hardware‑Generationen hinweg lauffähig, was die außergewöhnliche Lebensdauer von Geschäftslogik erklärt.
Objektbasiertes Sicherheitsmodell: Rechte und Operationen sind streng typisiert – ein Fundament für robuste Systemgrenzen.

Zur Einordnung vorab: Zu den gängigen Sprachen auf IBM i zählen ILE RPG, CL, C/C++, Java und SQL; für Web‑Anteile ist PHP verbreitet. IBM betont die Offenheit für mehrere Programmiersprachen sowie integrierte Web‑ und Application‑Server‑Funktionen. Diese Einordnung hilft Bewerber:innen, den „IBM i‑Gedanken“ zu verstehen: Anwendungen, Datenbank und Betrieb arbeiten enger verzahnt als in vielen anderen Umgebungen. Die folgenden Abschnitte bieten dazu passende Aufgaben‑ und Skill‑Listen.

Kernaussage (Plattform): Es ist sinnvoll, zuerst die Architektur‑Konzepte wie Db2 for i, Single‑Level‑Storage und TIMI zu verstehen, damit Entwicklung und Fehleranalyse auf IBM i richtig einzuordnen sind.

Tools und moderne Entwicklungspraktiken

Die Entwicklungslandschaft auf IBM i hat sich in den letzten Jahren deutlich modernisiert. Zwei Tool‑Schienen sind für den Alltag relevant:

IBM Rational Developer for i (RDi): eine bewährte, integrierte Entwicklungsumgebung für RPG, COBOL, CL und SQL auf IBM i.
VS Code‑basierte Open‑Source‑Erweiterungen: insbesondere „Code for IBM i“ sowie RPGLE‑ und Db2‑Erweiterungen. IBM bündelt eine aktuelle Ressourcen‑Roadmap, inklusive VS‑Code‑Ökosystem, RDi, Db2 for i und Open‑Source‑Paketen, hier: „IBM i technical resources roadmap“ (Link).

Im täglichen Arbeiten ergänzen viele Teams außerdem:

IBM i Access Client Solutions (ACS) für Datenbankzugriff, Run‑Commands und System‑Insights.
SQL‑Services auf IBM i für Systemabfragen, Monitoring und Administrations‑Automatisierung per SQL.

Versionierung, Code‑Reviews und automatisiertes Testen gewinnen auch im IBM‑i‑Kontext an Bedeutung – häufig in Mischlandschaften mit Git als VCS. Wie CI/CD konkret umgesetzt wird, hängt stark von Teamreife und Toolauswahl ab; verbreitet sind schrittweise Modernisierungen, bei denen zunächst Entwicklungs‑ und Testprozesse standardisiert werden, bevor Deployments weiter automatisiert werden.

Kernaussage (Tools & Practices): Richte eine moderne Entwicklungsumgebung (VS Code + Code for IBM i oder RDi) ein und beginne mit Git‑Versionierung und einfachen automatisierten Tests, um deine Arbeit reproduzierbar und prüfbar zu machen.

Skills‑Checkliste für Bewerber:innen

Technische Must‑haves

Solide RPG‑Kompetenz (moderne, freiformatierte ILE RPG‑Syntax) und Routine mit CL.
Fundiertes SQL auf Db2 for i: DDL/DML, Sichten, Prozeduren, Trigger; Grundverständnis von Performance auf der Plattform.
Verständnis für IBM‑i‑Eigenheiten: Bibliothekslisten, Objekttypen, Subsysteme, User‑Profile und Berechtigungen.
Debugging auf IBM i, inklusive Journaling‑basierter Nachvollziehbarkeit.

Wünschenswerte Ergänzungen

Erfahrung mit VS Code und „Code for IBM i“ oder RDi; sichere Arbeit mit IBM i Access Client Solutions.
Schnittstellenkompetenz: SQL‑Services, Web‑/REST‑Anbindungen oder Middleware‑Integration in heterogenen Landschaften.
Grundkenntnisse in C/C++ oder Java für Systemnähe oder Plattform‑übergreifende Projekte; Verständnis für Open‑Source‑Pakete auf IBM i.

Soziale und methodische Kompetenzen

Starke Domänenorientierung: Prozesse schnell verstehen, implizites Wissen heben, sauber dokumentieren.
Brückenbauer: IBM‑i‑Welt mit „Mainstream‑IT“ verbinden, z. B. gemeinsame Standards für Tests, Reviews und Betrieb etablieren.
Verantwortungsgefühl für Produktionsstabilität und Security – viele IBM‑i‑Anwendungen sind geschäftskritisch.

Kurzfassung (Skills): Fokussiere zuerst auf RPG und Db2‑SQL‑Grundlagen, baue parallel Toolkenntnisse (VS Code/RDi, ACS) auf und dokumentiere konkrete Beispiele aus eigenen Projekten für Bewerbungen.

Karriere, Nachfrage und Gehalt in Deutschland – realistische Erwartungen

Typische Profile reichen von:

Junior Developer mit solider Grundausbildung in SQL und einer Programmiersprache, plus Bereitschaft, IBM i zügig zu lernen.
erfahrene Developer mit tiefem RPG/SQL‑Know‑how und Systemverständnis.
Lead/Architect‑Rollen, die Modernisierungs‑Roadmaps, Schnittstellenstrategien und Qualitätsstandards verantworten.

Beispiele für Einsatzbranchen: Industrie (BOM/Produktion), Groß‑ und Einzelhandel (Warenwirtschaft), Logistik (Disposition, Tracking), Finanzdienstleister (Kernprozesse, Reporting) sowie Teile des öffentlichen Sektors.

Zur Vergütung: Sie variiert deutlich nach Region, Branche, Unternehmensgröße und Verantwortungsumfang. Erfahrungszuwachs in Domäne und Plattformtreue wird häufig überdurchschnittlich honoriert, da Einarbeitung und Prozesswissen unmittelbaren Geschäftswert stiften. Für eine konkrete Einordnung lohnt der Abgleich mehrerer Stellenangebote sowie der Austausch mit Community‑Kontakten.

Wie man den Einstieg schafft oder die Rolle modernisiert

Wer aus der Anwendungsentwicklung kommt und IBM i kennenlernen will, sollte zweigleisig vorgehen: Plattform verstehen und sofort ins Tun kommen.

Empfohlene Schritte:

Architektur‑Grundlagen lesen, um die IBM‑i‑Eigenheiten einzuordnen – etwa in "Getting started with IBM i" (Link).
Entwicklungsumgebung aufsetzen: VS Code plus „Code for IBM i“ und Db2‑Erweiterung oder RDi; Zugriff auf ein IBM‑i‑System organisieren (intern, Schulung, Testpartition).
SQL‑Services nutzen, um Systemwissen zu vertiefen (Objekte, Jobs, Performanceindikatoren) – so wächst das Verständnis für Betrieb und Tuning nebenbei.
Kleine Modernisierungsbausteine identifizieren: RPG‑Bestandsfunktionen in freie Syntax überführen, Stored Procedures gezielt einführen, wiederkehrende Aufgaben mit CL/SQL automatisieren.
Community und Lernressourcen gezielt nutzen. Eine breit kuratierte Übersicht zu Tools, Dokus, Redbooks und Community‑Hubs liefert die „IBM i technical resources roadmap“ (Link).

Bewerbungsstrategie:

Praxis sichtbar machen: Beispiele für Performance‑Verbesserungen, robuste Datenmodelle, sauberes Fehler‑Handling und gelungene Schnittstellenintegration.
Legacy‑Modernisierung betonen: Migration von Fixed‑Format nach Free‑Format RPG, Refactoring monolithischer Routinen, Einführung von Tests und Code‑Reviews.
Domänenwirkung quantifizieren, wo möglich: Durchsatz, Fehlerreduktion, Stabilität in Peak‑Zeiten – ohne Betriebsgeheimnisse zu verraten.

Abwägung: Vor‑ und Nachteile einer Spezialisierung auf IBM i

Vorteile:

Potenziell hohe Jobstabilität: Langfristig betriebene Bestandslandschaften können die Rolle stabil wirken lassen.
Direkter Geschäftseinfluss: Arbeit nah an kritischen Prozessen und Daten, spürbarer Nutzen.
Geringerer Wettbewerb in der Nische: Gute Chancen, schnell Verantwortung zu übernehmen und Expertise aufzubauen.

Nachteile/Risiken:

„Altsystem‑Image“: Modernisierung ist nötig, um attraktiv für Talente und zukunftsfähig zu bleiben – eine Chance, aber auch Aufgabe.
Begrenzte Community‑Größe im Vergleich zu JavaScript/Cloud‑Ökosystemen; gezielte Vernetzung lohnt sich umso mehr.
Tooling‑Heterogenität: Teams bewegen sich oft zwischen etablierten IBM‑i‑Werkzeugen und modernen Dev‑Workflows; Konsistenz muss aktiv gestaltet werden.

Fazit: Für wen sich eine Karriere als AS/400 Developer lohnt – und nächste Schritte

Wenn Sie gern nah an der Fachlichkeit arbeiten, robuste Systeme schätzen und Freude daran haben, bewährte Anwendungen schrittweise zu modernisieren, ist die Rolle als AS/400/IBM‑i‑Developer eine starke Option.

Starten Sie mit einem kompakten Architekturverständnis, richten Sie eine zeitgemäße Entwicklungsumgebung ein (VS Code oder RDi) und üben Sie täglich mit SQL‑Services und kleinen Refactorings. Nutzen Sie die IBM‑Ressourcen – etwa die Einstiegsübersicht „Getting started with IBM i“ und die kuratierte „IBM i technical resources roadmap“ – als Leitplanke. So bauen Sie systematisch Kompetenzen auf, machen Ihre Wirkung messbar und positionieren sich überzeugend für Ihren nächsten Schritt auf IBM i.