Die IT hochverfügbar ausgestalten

Hochverfügbarkeit wird in der IT oft viel zu technisch betrachtet, glaubt Wolfgang M. Roser. Der österreichische Software-Unternehmer weiß, wovon er spricht, bietet er doch mit seiner Wiener Firmengruppe rund um Roha und WMR schon seit Jahren entsprechende Technologien des Partners Vision Solutions an.

Hochverfügbarkeit setzt Rosers Meinung nach vor allem auch die Verfügbarkeit der Anwendungen selbst voraus. Das klingt selbstverständlich, ist es aber keineswegs. Denn auch die langfristige Einsatzbereitschaft der Anwendungsprogramme kann durchaus in Gefahr geraten, etwa durch eine Pleite des Software-Lieferanten oder durch das Ausscheiden des Programmierers aus dem Unternehmen.

Vielfältige Aspekte spielen also bei der Gewährleistung der Hochverfügbarkeit mit, vor allem auch organisatorische Voraussetzungen und allzu menschliche Schwächen. „Die Gesamtheit einer IT-Landschaft, mit Soft- und Hardware und nicht zuletzt ihren Menschen, ist weit mehr als die Summe ihrer Einzelteile“, betont Roser. „Wir wissen das und handeln danach.“

Roser gründete sein Unternehmen 1986 und spezialisierte sich von Anfang an auf die Entwicklung und Programmierung von kaufmännischen Geschäftsanwendungen für die Midrange-Rechner der IBM – später unter wechselnden Namen wie AS/400, iSeries oder System i vermarktet. Das sind robuste und performante IT-Systeme, die aus gutem Grund im Mittelstand so populär sind – weil man sich auf sie verlassen kann.

„Stabile Nerven braucht man, wenn dann doch das Unmögliche passiert. Und das muss nicht unbedingt von der bewährten AS/400 ausgehen“, weiß Roser. Brand, Rauch, Explosion, Stromausfall, Wasser, Einbruch, Diebstahl, Vandalismus und Sabotage sind nur einige der Gefahren, die den AS/400-Betrieb bedrohen. Deshalb sind Hochverfügbarkeits-Mechanismen wie Backup und Spiegelung unverzichtbar. Genauso wichtig ist es aber auch, sich über die langfristige Nutzbarkeit der wichtigen Anwendungsprogramme Gedanken zu machen.

Denn hier kann manches im Argen liegen, auch wenn der IT-Chef technisch und organisatorisch alles im Griff hat. Manchmal entpuppen sich bewährte Anwendungsprogramme, die seit Jahr und Tag klaglos ihren Dienst tun, als Ausfallrisiko. Zum Beispiel, weil ihr Programmierer in Rente geht. Das muss aber nicht zum Ausfall führen, weist Roser auf seinen Modernisierungsservice hin. Mit diesem Service sorgt WMR dafür, dass auch betagte Anwendungen eine gute Zukunft haben.

Rund 1.000 AS/400-Anwender im deutschsprachigen Raum zählt der Wiener Software-Unternehmer Wolfgang M. Roser zu seinen Kunden. Rund 750 dieser Unternehmen setzen Spoolmaster ein, die Outputmanagement-Software von Roha. 250 weitere Unternehmen nutzen die Standardsoftware von WMR. Zunehmend gewinnt Roser aber auch auch neue Kunden, die keines seiner Standardprodukte einsetzen. Sie nutzen die Skills von WMR, um ihre seit AS/400-Zeiten bewährten Anwendungssysteme zu pflegen und weiterzuentwickeln. Im Interview mit DV-Dialog erklärt Roser, wie er durch seine Modernisierungsservices die langfristige Verfügbarkeit bewährter Anwendungssysteme sicherstellt.

Herr Roser, warum ist Ihr Modernisierungsservice gefragt?
Wolfgang M. Roser: Die Ausgangslage ist fast immer sehr ähnlich. Unternehmen haben vor vielen Jahren eine Warenwirtschaftssoftware angeschafft oder auch selbst entwickelt, die lange Zeit kontinuierlich betreut und immer wieder erweitert und verbessert worden ist.

Doch dann ging der Softwarelieferant pleite – oder er hat die Weiterentwicklung eingestellt. Wurde die Warenwirtschaftssoftware selbst entwickelt, hat der verantwortliche Programmierer das Unternehmen verlassen, weil er in Rente ging oder weil er abgeworben wurde. Dann hat die Software einige Zeit brach gelegen und entsprechend Staub angesetzt – solange, bis das Unternehmen Handlungsbedarf erkannt hat.

Die Kunden arbeiten also mit RPG-Programmen, die grundsätzlich solide laufen, erhalten aber keinen Support mehr. Änderungen oder Ergänzungen in der RPG-Softwarelandschaft verursachen beim IT-Chef ein mulmiges Gefühl.

In solchen Fällen kommen Sie ins Spiel?
Roser:  Genau. Wir übernehmen die Pflege und auch die Weiterentwicklung beziehungsweise Modernisierung dieser Software. Das kann zum Beispiel das Erstellen von Serienbriefen mit Microsoft Office aus dieser Anwendung heraus sein, aber auch der direkte elektronische Versand von Rechnungen und Lieferscheinen an die Kunden.

Wir erweitern die Software nicht nur um solche modernen Features, sondern auch um zusätz­liche Funktionen, etwa im Bereich Planung und Disposition oder beim E-Commerce. Oder es ändern sich gesetzliche Vorschriften, an die es die Software anzupassen gilt.

Sie stauben die Software nicht nur ab, sondern erweitern auch das Einsatzfeld?
Roser: Man kann es auch so sagen: Wir machen die Software sukzessive wieder flott. Denn mit dieser Software sind die Unternehmen ja eigentlich sehr zufrieden. Sie macht genau das, was sie soll – und das zuverlässig und schnell. Es kommen nur immer wieder neue Aufgaben hinzu, die man nicht länger manuell oder mit Excel erledigen möchte.

Diese Defizite arbeiten wir bei unseren Kunden der Reihe nach auf. Das ist vielleicht manchmal ein bisschen mühsam, weil wir die Programmierer der Software nicht mehr fragen können und weil die Dokumentation unvollständig oder nicht ganz akkurat ist. Das ist anfangs manchmal sehr viel Analyse-Arbeit. Aber wenn wir uns erst einmal eingearbeitet haben, läuft es wie am Schnürchen. Wir stellen die RPG-Anwendung auf eine moderne und solide Basis: Durch Re-Design mit unserem „Native Application Builder“ NAB/400. Dieses Entwicklungswerkzeug spart nicht nur Zeit bei der Codierung, sondern sorgt auch für eine gut verwaltbare „Gleichheit“ der Anwendungen. Davon profitieren einerseits Softwareentwickler, aber auch Anwender, die später mit der so erstellten Software arbeiten.

Können Sie bitte ein Beispiel für solche Modernisierungsvorhaben nennen?
Roser:  Ein Kunde brauchte eine Auftragserfassung über das Internet. Früher kamen die Aufträge per Brief, Fax oder Telefon und wurden manuell erfasst. In den letzten Jahren mehrten sich die Bestellungen via Mail. Diese Mails wurden ausgedruckt und manuell in das Warenwirtschaftssystem eingegeben. Waren das anfangs nur vereinzelte Bestellungen, treffen heute 500 Bestellungen am Tag per Mail ein. Daher lohnt sich, wenn diese Bestellungen automatisch erfasst werden.

Anderes Beispiel: Ein großer Versandhändler hat immer noch ein Warenwirtschaftssystem im Einsatz, das ursprünglich einmal für das System /36 entwickelt worden war. Die Software ist über all die Jahre immer besser an die spezifischen Anforderungen und Geschäftsprozesse angepasst worden. Im Zuge seines Wachstums hat der Händler jetzt ein Hochregallager gebaut, um seine Kunden schneller beliefern zu können. Wir haben deshalb sein Warenwirtschaftssystem um eine Verwaltung des Hochregallagers ergänzt, damit dort vernünftig kommissioniert werden kann.

Hätte er nicht eine Standsoftware zur Lagerverwaltung kaufen können?
Roser:  Natürlich – da gibt es viele gute Produkte. Aber das wäre teurer geworden. Er hätte ja nicht nur die Software kaufen müssen, sondern auch entsprechende Schnittstellen in seiner Warenwirtschaft schaffen müssen.

All diese Kunden stehen am Anfang immer vor der Alternative, entweder alles neu zu machen oder ihre bewährte Software anzupassen. Alles neu zu machen ist nicht nur teuer, sondern auch riskant – denn große Software-Projekte gelingen bekanntlich längst nicht immer. Vor allem aber bedeutet das auch einen enormen Knowhow-Verlust, denn in die Software sind über die Jahre viele Erfahrungen eingeflossen.

Auch WMR könnte ja seine Standardsoftware für die Warenwirtschaft ins Spiel bringen?
Roser:  Das tun wir auch dort, wo es Sinn macht. Ich würde aber keinem Kunden unsere Standardsoftware verkaufen, wenn ihre Anpassung zu lange dauern würde. Es bringt ja nichts an einer Software monate- oder jahrelang herumzudoktern – nur um dem Kunden die Funktionalität zu liefern, die er bereits hat. Außer den Lizenz- und Wartungskosten muss der Kunde ja auch für die Anpassungen und ihre Tests zahlen.

Günstiger ist es in den meisten Fällen, wenn wir uns in die Software einarbeiten und sie dann sukzessive weiterentwickeln. Das machen wir natürlich nur da, wo es sinnvoll ist. Wir würden ja das Rad nicht neu erfinden. Wenn der Kunde einen normalen Online-Shop braucht, binden wir ein entsprechendes Standardprodukt vom Markt an. Soll es aber etwas ganz Spezielles sein, programmieren wir ihm auch diesen Online-Shop zu seinem Warenwirtschaftssystem hinzu.

Mit welchen Mitteln entwickeln Sie die alte Software weiter?
Roser:  Mit NAB/400 und allen anderen Mitteln, die uns das moderne Power System i bietet. In manchen Fällen müssen wir aber auch mit uralten Technologien hantieren – wie im Falle des erwähnten Versandhändlers mit System/36-kompatiblem RPG II. Wir haben eigene Werkzeuge – und wir nutzen auch die Werkzeuge der Kunden. Der bleibt also in seiner Software-Welt.

Wir müssen in der Analysephase manchmal schon viel sehr Gehirnschmalz darauf verwenden, um zu verstehen, wie wir am besten weiterentwickeln, denn vor zwanzig Jahren wurden beim Programmieren noch andere Methoden verwendet als heute. Das muss passen. Aber das geht grundsätzlich überall.

Das nötige Know-how dafür haben Sie im Haus?
Roser: Sechs unserer Programmierer kennen sogar noch RPG II aus dem Effeff.  Und wir bilden auch gezielt aus. Wir haben gerade jetzt erst zwei junge Leute dazu geholt, die sich ausschließlich in das AS/400-Thema einarbeiten und dort alle Technologien beherrschen sollen.

Haben die jungen Leute denn überhaupt Lust darauf?
Roser: Natürlich würde die Jugend lieber mit bunten Bildchen hantieren. Aber unsere Mit­arbeiter haben erkannt, dass sie in den nächsten zehn bis fünfzehn Jahren mit AS/400-Knowhow weiter kommen als mit dem, was 150.000 andere Programmierer auch tun. Denn RPG- und Cobol-Programmierer wachsen ja zur Zeit nicht auf den Bäumen...

Gibt es bestimmte Voraussetzungen, die eine alte Software für Modernisierungsmaßnahmen erfüllen muss? Oder ist manchmal auch Hopfen und Malz verloren?
Roser:  Aussichtslose Fälle sind uns bisher noch nicht unter gekommen, auch wenn es anfangs manchmal danach ausgesehen hatte. Wir haben bisher noch keine Kundenfrage ablehnen müssen; nachdem wir uns vier oder sechs Wochen lang eingearbeitet haben, konnten wir bisher jedes Projekt in Angriff nehmen...

Und auch erfolgreich abschließen?
Roser:  Manche Projekte laufen noch – aber wir sind überall auf einem guten Weg.

Sind das Einmalprojekte oder eher Daueraufträge?
Roser:  Das sind Daueraufträge. Wir haben die meisten Kunden jetzt bereits ein oder zwei Jahre in permanenter Betreuung – da gibt es laufend neue Ideen für Erweiterungen und Verbesserungen.

Ein großes Werk in Tirol beispielsweise, das eine seit 25 Jahren gewachsene Software im Einsatz hat, dachte über die Einführung einer Standardsoftware nach. SAP war bereits im Hause; auch Microsoft hatte Navision und Axapta präsentiert.

Die Hersteller waren sich einig: Wir können mit unseren Produkten die Anforderungen des Werkes abdecken. Das dauert vier Jahre und kostet fünf Millionen Euro. Da kam der IT-Chef ins Grübeln, denn dann hätte er mit enormen Aufwand nicht viel mehr als die Software-Funktionalität von heute – vielleicht. Deshalb hat er sich bewusst gegen die Einführung einer Standardsoftware und für die Modernisierung entschieden. Dadurch spart er Zeit – und für das Geld können wir die Funktionalität der vorhandenen Software sehr deutlich erweitern.

Gibt es charakteristische Umstände, die solche Modernisierungsvorhaben auslösen?
Roser: Die sehe ich nicht. Wir haben Kunden der unterschiedlichsten Größe aus den unterschiedlichsten Branchen, die uns mit der Modernisierung ihrer Anwendungen beauftragen. Das sind Unternehmen mit 10 Mio. Euro Jahresumsatz, aber auch solche mit 500 Mio. Euro.

Es ist aber immer so, dass die Anwendung eine gewisse Zeit nicht mehr angefasst worden ist. Sei es es, weil die IT-Abteilung überlastet ist, sei es, weil der Programmierer, der sich damit auskennt, pensioniert wurde. Oder weil der Software-Lieferant einen Strategiewechsel vollzogen hat. Das geht eine gewisse Zeit gut, bis der Modernisierungsbedarf allmählich dringlich wird.

Ist das nicht etwas leichtsinnig?
Roser: Das würde ich nicht sagen. Es ist aber schon so, dass man sich manchmal zuwenig Gedanken darüber macht. Gerade weil die AS/400-Anwendungen so zuverlässig ihren Dienst tun, dass ihr Einsatz zur Selbstverständlichkeit wird.

Wofür brauchen Sie den meisten Gehirnschmalz bei der Modernisierung?
Roser: Für das Verständnis der vorhandenen Programme! Erschwerend ist ja, dass AS/400-Programme normalerweise nur dürftig dokumentiert sind. Wir modernisieren Anwendungen mit mehreren hunderttausend Zeilen Programmcode, deren Dokumentation auf zwei DIN-A4-Seiten passt.

Dass es an der Dokumentation hapert ist weder böser Wille noch Schlampigkeit, sondern meistens der Zeitnot geschuldet. Hat die Firma etwa ein Werk in der Slowakei gekauft, müssen Warenwirtschaft und Finanzbuchhaltung dieses Werk schnellstmöglich unterstützen. Dann werden in der Software-Entwicklung Wochenenden geopfert und Nachtschichten geschoben; der Fokus liegt ganz klar darauf, die Funktionalität bereitzustellen. Notgedrungen bleibt wenig Zeit aufzuschreiben, was genau gemacht wurde – und warum. Wenn die Software aber funktioniert, holt das Tagesgeschäft die Programmierer ein; der Zeitmangel ist chronisch. Letztlich bleibt die gute Dokumentation ein frommer Wunsch.

Die Programme dokumentieren sich sozusagen selbst...
Roser: Dazu müssten die Programme so geschrieben sein, dass man sie direkt versteht. Das ist aber leichter gesagt als getan, denn wie bereits erwähnt haben sich die Programmiermethoden im Laufe der Zeit ständig verändert. So sehr, dass ich am Aufbau von RPG-Programmen direkt sehe, in welchem Jahr sie entstanden sind. 1994 hat man einen Algorithmus so formuliert, 1996 war es schon wieder anders. Das hat nicht nur mit Moden zu tun, sondern auch mit Empfehlungen der IBM und mit Compiler-Features.

Mittlerweile hat IBM ja die Formate im RPG völlig freigegeben. Nutzen Sie die neuen Möglichkeiten des „Free RPG“?
Roser: Ja, aber nur bei Programmen wie dem Spoolmaster, deren Source-Code wir nicht außer Haus geben.

Was spricht gegen „Free RPG“?
Roser: Im Prinzip nichts – wir verwenden es nur bei der Modernisierung nicht. Unsere Programmierer müssen aber die gebräuchlichen RPG-Dialekte beherrschen, angefangen von RPG III über RPG IV bis hin zu „Free RPG“. Unseren jungen Auszubildenden fällt der Einstieg in die RPG-Programmierung mit dem freien Format leichter, doch auch sie müssen natürlich die „Klassiker“ beherrschen.

Nutzen Sie RPG Open Access?
Roser: Auch damit haben wir unsere Erfahrungen gemacht – und sogar eine Anwendung damit entwickelt. Wir haben aber keinen Kunden dafür begeistern können.

Warum nicht?
Roser: Die Anwendung gefiel nicht, weil Open Access ja nur begrenzte Möglichkeiten bietet. Zum Beispiel kann man damit nur das darstellen, was auf einen Bildschirm passt. Also ist die Datenmenge entweder auf 27 x 132 Zeichen oder auf 24 x 80 Zeichen beschränkt. Mehr lässt sich mit Open Access bei einer Trans­aktion nicht transportieren. Damit ist der Mehrwert natürlich auf diejenigen Anwendungen beschränkt, bei denen diese Datenmenge ausreicht. Die meisten Kunden wollen aber mehr – und nicht nur die bereits vorhandenen Green Screens „aufhübschen“.

Wie gehen Sie bei der Modernisierung normalerweise vor?
Roser: Wir haben rund 20 AS/400-Systeme bei uns im Haus, für sensible Kunden jeweils sogar ein eigenes. Darauf installieren wir die Kunden­umgebung und analysieren die Programme. Auf diese Weise vermeiden wir auch etwaige Performance-Probleme bei den Kunden, die über keine eigenen Systeme für Entwicklung und Test verfügen, weil wir nicht auf ihrem Produktionssystem arbeiten.

Verwenden Sie bei der Modernisierung auch vordefinierte Templates oder Tools für häufig wiederkehrende Aufgaben?
Roser: Überall, wo es Sinn macht. Das können auch Module vom Spoolmaster sein, etwa für den Versand von Serien­briefen oder auch für elektronische Formulare.

Wir haben zum Beispiel einen Kunden, der den Fortschritt seiner Produktion in einer Word-Datei dokumentiert. Zu Beginn der Produktion wird ein Word-Formular mit allen Produktionsschritten erstellt. In dieses Formular wird jeder Schritt des Produktionsprozesses eingetragen. Geschah das bisher manuell durch einen Mitarbeiter, füllen wir dieses Dokument jetzt automatisch aus. Das spart viel Arbeit und vermeidet unnötige Übertragungsfehler.

Anderes Beispiel: Viele Unternehmen tauschen in Form von Excel-Tabellen Daten mit ihren Kunden oder Lieferanten aus, zum Beispiel über den Fortschritt der Produktion oder über die Lagerbestände. Diese Excel-Dateien lassen sich zwar mit den Bordmitteln der AS/400 unkompliziert mit Daten füllen. Allerdings mit dem Nachteil, dass die so erstellten Excel-Dateien häufig noch nachbearbeitet werden müssen, damit sie den Vorgaben des Empfängers entsprechen. Deshalb haben wir unsere Hausarbeiten gemacht und ein kleines Tool entwickelt, mit dem sich maßgeschneiderte Excel-Vorlagen erstellen lassen. Diese Vorlagen befüllen wir dann mit den Daten von der AS/400 und verschicken sie an den Kunden. Somit kann die Nachbearbeitung entfallen, weil der Kunde die gewünschten Daten automatisch genau in dem gewünschten Format erhält.

Wie bringen Sie die Green Screens in die IT-Welt von heute?
Roser: Das programmieren wir kurzerhand mit dem „Common Gateway Interface“ (CGI) – genau so, wie der Kunde es braucht. Das gibt den vorhandenen 5250-Anwendungen ein Browser- bzw. Web-basiertes Gesicht. Damit punkten wir nicht nur bei den Anwendern, sondern auch bei den Programmierern, denn sie arbeiten serverseitig weiterhin mit ILE RPG.

Damit sichern Sie die Verfügbarkeit dieser „Software-Schätze“ langfristig?
Roser:  Auf jeden Fall! Individuelle Erweiterungen der Anwendung bieten völlig neue Per­spektiven. Einfügen von Bildern, E-Mail-Felder identifizieren oder aber auch Datumsfelder erkennen und entsprechend darstellen sind nur einige Beispiele. Wir machen das gern, auch wenn es manchmal eine echte Herausforderung ist, die neuen und die bewährten Funktionen zu verschmelzen. Aber genau das macht uns Spaß – diese Herausforderungen zu meistern.