Erfolgsgaranten für Modernisierungsprojekte

Das IBM-System i ist der zuverlässigste und kostengünstige Server, gilt oft aber ebenso als veraltet wie die Anwendungen darauf. Da wird gerne von Legacy ge­redet, also vom Erbe der Vergangenheit. Wird dieses Erbe eher als Bürde denn als wertvolles Vermächtnis angesehen, das es weiterzuführen gilt, kommt es zu teuren und riskanten Ablöseprojekten.

Diese Kosten und Risiken halten Heidi Schmidt und Roland Zurawka, die beiden geschäftsführenden Gesellschafter der PKS Software GmbH, in vielen Fällen für absolut vermeidbar. Denn IBM i sei alles andere als veraltet, sondern im Gegenteil als integratives Betriebssystem moderner denn je. Und in den über lange Jahre maßgeschneiderten Anwendungen stecke das geballte Know-how des Unternehmens; bei einer Neuentwicklung oder einem Umstieg auf Standardsoftware fängt man hier wieder bei Null an.

Allerdings sind auch eigenentwickelten Anwendungen längst nicht immer perfekt, sondern oft fachlich lückenhaft, „undurchschaubar“ oder technisch veraltet. Als Ausweg aus dieser Zwickmühle hat PKS das Konzept des sogenannten „Clean Software Development“ entwickelt, mit dem es schon gute Praxiserfahrungen gibt.

In der Praxis zeigten sich auch typische Stolpersteine und Erfolgsfaktoren für Modernisierungsprojekte. Die folgenden fünf Erfolgsgaranten haben Schmidt und Zurawka in circa 500 bisher umgesetzten Projekten ausgemacht:
1. Es braucht eine klar kommunizierte Zielsetzung für die Modernisierung auf Unternehmensebene, denn solch ein Projekt betrifft die gesamte Firma. Das Management, Inhaber und Geschäftsführung, müssen involviert werden und das Vorhaben unterstützen. Wer nur „ein bisschen was modernisiert“ verliert schnell den Faden und sieht auch die erzielten Erfolge nicht.
2. Nur wenn der Austausch zwischen IT und Fachbereichen aktiviert und dauerhaft etabliert wird, sind die Vorteile der gezielten Erneuerung und schrittweisen Neuentwicklung nachhaltig nutzbar.
3. Es braucht die Bereitschaft, neue Wege zu gehen und alte Gewohnheiten abzulegen. Konsequentes „Change-Management“ ist ganz wichtig, damit das Vorhaben gelingt.
4. Die Projektleitung ist dafür verantwortlich, eine realistische Zeitplanung zu erarbeiten. Und auch das „Erfolge feiern“ beim Erreichen von Meilensteinen darf nicht vergessen werden.
5. Das Prinzip „Teile und herrsche“ hat sich als Planungsgrundsatz für den Erfolg anspruchsvoller Projekte bewährt und sollte unbedingt beachtet werden.

Auch Themen wie E-Commerce oder Mobile Computing bilden Herausforderungen für die AS/400-Welt. Vor diesem Hintergrund befragten wir zwei Modernisierungsexperten – die beiden geschäftsführenden Gesellschafter der PKS,  Heidi Schmidt und Roland Zurawka.

Frau Schmidt, mit Blick auf viele bewährte Anwendungssysteme aus AS/400-Zeiten beobachten Sie das „IBM i Paradoxon“. Was meinen Sie damit?
Heidi Schmidt: „AS/400“-Kunden entwickeln seit vielen Jahren individuelle Applikationen, maßgeschneidert auf ihre Markt- und Pro­zesserfordernisse. Über mehrere Hardware­generationen hinweg profitierten sie von der einzig­artigen Systemarchitektur ihres Ser­vers: der Entkopplung von Betriebssystem und Anwendungsprogrammen. Deshalb laufen auf der heute „System i“ genannten Maschine auch noch viele Anwendungen, die technologisch in die Jahre gekommen sind – fachlich aber das Nervensystem des Unternehmens darstellen.

Roland Zurawka: Was lange Zeit mit minimalen Investitionen in die Software-Modernisierung am Laufen gehalten werden konnte, reicht nicht mehr aus, um gegenüber den Mitbewerbern die Nase vorn zu haben. Wir erleben täglich, wie technische Entwicklungen die Interaktion und Kommunikation von Unternehmen mit ihren Bezugsgruppen drastisch verändern.

Schmidt: Daraus entstehen widersprüchliche Anforderungen – und genau das bezeichnen wir als das „IBM i Paradoxon“:

1. Die Bestandssysteme müssen optimal und zuverlässig laufen und sich gleichzeitig für die Integration mit neuen Technologien öffnen.
2. Die Entwicklermannschaft muss sich mit den gewachsenen, häufig monolithischen Software-Architekturen auskennen und gleichzeitig agile und modulare Konzepte anwenden können.
3. Flexible und individuelle Software-Lösungen sind die Grundlage für agile Geschäftsprozesse und zwingen gleichzeitig zur Nutzung von Standards bei Schnittstellen und beim Austausch von Daten über System- und Unterneh­mensgrenzen hinweg.

Wie kann der IT-Chef diese widersprüchlichen Anforderungen am besten unter einen Hut bringen?
Schmidt: Indem er seine IT-Strategie konsequent auf die Unternehmensstrategie ausrichtet und sich bei der Umsetzung an den Grundregeln des Clean-Software-Development-Konzepts orientiert.

Könnte er nicht auch durch den Umstieg auf moderne Standardsoftware sozusagen alle Fliegen mit einer Klappe schlagen? Oder handelt er sich damit vielleicht neue Baustellen ein?
Schmidt: Unternehmen, die radikal in allen Bereichen auf Standardsoftware umsteigen, gehen ein sehr hohes Risiko ein, da die Umstiegs­phase mehrere Jahre dauern wird und während dieser Zeit sowohl das heutige Bestandssystem weiter gepflegt, als auch das neue Standardsystem spezifiziert und implementiert werden muss. Zudem müssen sie mit Kosten im Millionen-Euro-Bereich rechnen, denn sie kaufen für teures Geld auch vieles an „Software“, das sie in ihrem heutigen System bereits zur Verfügung haben. Hinzu kommt die Gefahr, dass sich die langjährigen Entwickler außerhalb ihres Unternehmens orientieren und dadurch wertvolles Prozesswissen für immer verloren geht.

Sie haben das „Clean Software Development“ erwähnt. Was genau verstehen Sie unter „sauber“?
Zurawka: „Clean Software Development“ ist ein Begriff aus der Softwaretechnik, der seinen Ursprung in dem Buch „Clean Code“ von Robert C. Martin hat. Als „sauber“ bezeichnen Softwareentwickler in erster Linie Quellcode, aber auch Dokumente, Konzepte, Regeln und Verfahren, die intuitiv verständlich sind. Als intuitiv verständlich gilt alles, was mit wenig Aufwand und in kurzer Zeit richtig verstanden werden kann.

Vorteile eines solchen „Clean Code“ sind stabilere und effizient wartbare Programme, d. h. kürzere Entwicklungszeiten bei Funktions­erweiterungen und Fehlerbehebungen. Die Bedeutung wächst mit der Beobachtung, dass im Schnitt 80 Prozent der Lebensdauer einer Software auf den Wartungszeitraum entfällt. Die Notwendigkeit, Code auch nach der Entwicklung noch von „unsauberen“ Stellen zu befreien, wird häufig nicht gesehen oder vom Management nicht bewilligt, sobald das Programm seine vorgesehene Funktion ausübt. Ein direktes Schreiben von „sauberem“ Code ist nahezu unmöglich, kann jedoch durch den bewussten Umgang mit den Prinzipien und Praktiken des „Clean Software Development“ verbessert werden.

Wie unterstützen Sie das CSD-Konzept mit Werkzeugen – zum Beispiel mit RDi, valence oder eXcite?
Schmidt: Die Werkzeuge sind die sogenannten „Powertools“, die eine nachhaltige Modernisie­rung und schrittweise Erneuerung preislich und qualitativ so attraktiv machen. Außerdem sind genau diese modernen Produkte der Grund dafür, warum es unseren Kunden sehr gut gelingt, auch junge IT-Mitarbeiter zu begeistern und den Generationswechsel im Team erfolgreich durchzuführen. Es ist immer wieder überraschend, dass es sowohl IT-Leiter als auch Entwickler gibt, die meinen, man könne auf dem IBM-System i oder in RPG nicht auf Basis von Eclipse entwickeln – hier besteht noch ordentlich Informationsbedarf!

Kann der Kunde auch andere Werkzeuge in CSD-Projekte einbringen?
Zurawka: Natürlich! So nutzen wir z.B. die am Markt verfügbaren Konverter für die Umsetzung nach Free RPG oder auch moderne Werkzeuge zur Versionskontrolle und zur Collaboration, wie z.B. TD/OMS oder Jira und Confluence.

Wie sehen solche Projekte grundsätzlich aus? Gibt es typische Phasen oder Meilensteine?
Zurawka: Generell laufen CSD-Projekte in fünf Phasen ab:

1. Ein Assessment der heutigen Anwendungen sowie der Entwicklungsprozesse und des -teams
2. Eine Konzeptions- und Architekturphase, in der auf Basis eines umfangreichen Verständ­nisses des Ist-Zustandes und klarer Definition der Zielarchitektur und -anwendung die Mo­der­nisierungsroadmap definiert werden kann
3. Die Budgetierung und Kommunikation des Gesamtvorhabens vom obersten Management an das gesamte Unternehmen
4. Die schrittweise Projektierung und sanfte Migration
5. Die Übergabe an den Betrieb und die fortlaufende Weiterentwicklung.

Am Anfang steht also die Analyse des aktuellen IST-Zustandes. Wie aufwendig ist diese Analyse – und was sind die wichtigsten Resultate?
Zurawka: Das Software-Assessment hat sich als Entscheidungsgrundlage für die Zukunftstauglichkeit gewachsener Anwendungen etabliert. Es dauert in der Regel ca. 8 bis 10 Wochen, in denen unsere erfahrenen IBM-i-Consultants anhand eines strukturierten, werkzeuggestützten Vorgehens die Kernsysteme aus drei Richtungen betrachten und bewerten:

1. Der Programmcode, das Datenbankmodell sowie das User-Interface samt allen relevanten weiteren Systemschnittstellen wird analysiert und mit Technologietrends und State-of-the-Art-Konzepten abgeglichen
2. Die Anwendungsarchitektur wird visuali­siert, „Schnittkanten“ für eine Modularisierung werden herausgearbeitet
3. Für die Entwicklungsprozesse und das Entwicklerteam werden Risiko- und Potential­profile erstellt.

Das Ergebnis wird von drei Anwendergruppen bevorzugt genutzt:

• von Entwicklern für Bereinigungs- und Renovierungsarbeiten im Code
• von Software-Architekten für die schrittweise Überführung von monolithischen Strukturen in serviceorientierte Architekturen oder Cloud-Lösungen
• vom Management für die Ableitung von Investitionsentscheidungen.

Quantitativ und qualitativ stiftet das Assessment dreifach Nutzen:

• es verhindert unnötige Migrationsprojekte auf Standardsoftware
• es reduziert die Wartungskosten von Bestandssystemen um bis zu 40 Prozent und
• es macht das Entwicklungsteam attraktiv für den Nachwuchs.

Um das Projektziel zu definieren, wird die IT-Strategie des Unternehmens zugrunde gelegt. Was sind Ihrer Erfahrung nach typische Ziele?
Schmidt: In der aktuellen wirtschaftlichen und gesellschaftspolitischen Lage sehe ich folgende strategische Ziele für die Kernsanierung und Neuausrichtung der IBM-i-Anwendungs­landschaft sehr häufig in unseren Kundenprojekten:

1. Die Zerlegung von bisher monolithischen Systemen hin zu agilen und standardisiert koppelbaren Architekturen mit dem Ziel, für den jeweiligen Prozess optimale Softwarelösungen zu etablieren (Stichworte: Flexibilisierung und Wiederverwendbarkeit)
2. Die Erhöhung der Schlagkraft und Steigerung der Attraktivität des eigenen Entwicklerteams durch die Entschlackung und Entkernung der ge- und verwachsenen Bestandsanwendungen (Stichworte: Agilität und Nachhaltigkeit)
3. Die Umsetzung von Lösungen für die mobile Nutzung von Kernsystemen bei gleichzeitiger Beibehaltung der zentralen Datenhaltung und der hohen Sicherheitsstandards der Plattform IBM i (Stichworte: Digitalisierung und Mobile First)

Wie ergibt sich die Priorisierung der Modernisierungsaufgaben, was zum Beispiel Funktionalität, Usability oder Schnittstellen angeht. Können Sie das bitte an einem Beispiel verdeutlichen?
Schmidt: Das Assessment vergleicht die Bestands­anwendungen gegen State-of-the-Art Konzepte und Architekturen mittels intelligentem Sourcecode-Parsing, Code-Reviews und Trendchecks. Danach erhält der Kunde von uns praxiserprobte Handlungsempfehlungen und konkrete Verbesserungsvorschläge für einen schlanken, professionellen und robusten Entwicklungsprozess. Gemeinsam bewerten wir die fachliche Übereinstimmung der Eigenentwicklung mit den heutigen und zukünftigen Anforderungen. Meistens fällt auf den ersten Blick nur das auf, was fehlt – doch der fundamentale Kern, der heute das Tagesgeschäft im Unternehmen überhaupt erst ermöglicht, gerät darüber schnell in Vergessenheit. Nur eine ehrliche „Fit-Gap-Analyse“ ist daher zielführend. Damit vermeiden wir, Funktionalität, die heute schon im System steckt, erneut teuer zu erwerben oder entwickeln zu lassen.

Doch eines sollte auch bedacht werden: Man darf nicht davor zurückschrecken, Teilbereiche des bisherigen Gesamtsystems durch sinnvolle Standardlösungen im Markt zu ersetzen. Intelligentes Clustering der Sourcen zeigt die möglichen Schnittkanten dafür auf. So macht es z.B. heute keinen Sinn mehr, Reportings selbst zu entwickeln oder sich für die „Betankung“ von Business-Intelligence-Lösungen eigene Datenpumpen zu bauen.

Wie spielen dabei Alt- und Neuanwendungen zusammen? Welche Änderungen an den vorhandenen RPG-Programmen sind dazu notwendig?
Zurawka: Von „Alt“ spreche ich ungern, schließlich läuft auf genau diesen Systemen heute doch das komplette Business des Kunden! Dank IBM i können wir problemlos alte und neue Anwendungen parallel entwickeln und betreiben. Smarte Integrationstechnologien ermöglichen es uns, eine einfache und effiziente Koppelung beider Welten zu realisieren.

Dies ist vor allem für eine sanfte Transformation sehr wichtig. Änderungen an den vorhandenen Programmen sind in der Regel notwendig, um eine echte serviceorientierte Architektur zu schaffen – und so von den Vorteilen der Wiederverwendbarkeit und Zentralisierung zu profitieren. Die saubere Architektur erlaubt es nebenbei auch, später die Wartung und Weiterentwicklung der Software fehlerfrei und kostengünstig umsetzen zu können.

Schmidt: Kunden, die ihre Projekte gemäß der CSD-Leitgedanken aufsetzen, profitieren nach eigenen Angaben von einem ROI von wenigen Monaten. Sie sparen sich dauerhaft bis zu 75 Prozent ihrer IT-Kosten ein, weil es ihnen gelingt, die Innovationskraft des Unterneh­mens aus dem eigenen Entwicklungsteam heraus zu unterstützen. Das macht Firmen wie Dachser, TFG Transfracht, s.Oliver, Mosolf oder LTS Leuchten, die allesamt zu unseren Kunden zählen, auch schneller als ihre Mitbewerber.