In Zeiten, in denen der technologische Wandel immer rascher erfolgt und der Lebenszyklus einer neuen Technologie oft kürzer ist als der Lebenszyklus der damit geschriebenen Anwendung, ist es nicht einfach, ein sinnvolles Verhältnis zwischen Innovation und Beständigkeit zu erreichen. Die Zahl der Möglichkeiten und damit die Zahl der möglichen Fehlentscheidungen sind erheblich und lähmen in vielen Fällen die „Modernisierungslust“. Wichtig ist es, eine klare Vorstellung von der IT-Zukunft und dem daraus resultierenden Nutzen für das Unternehmen zu entwickeln, das Ganze in einen realistisch ausführbaren Plan zu verwandeln und diesen Schritt für Schritt in Angriff zu nehmen.

IT-Zukunft oder Horrorszenario?

War die Welt früher schön überschaubar mit einer zentralen AS/400 und vielen Terminals, so wird sie zukünftig immer mehr vernetzt und dadurch komplexer. Kein Unternehmen kann es sich leisten, sich langfristig von dieser unternehmensübergreifenden Vernetzung abzuschotten. Für den Anwender wird es immer unwichtiger, ob die Geschäftsprozesse, mit denen er arbeitet, im eigenen Unternehmen oder extern ablaufen. Was ihn interessiert, ist, wie er wirkungsvoll seine Aufgaben erledigen kann – und mit dem Abtippen von Daten von einem Programm ins andere und dem ständigem Wechsel zwischen verschiedenen Bedienphilosophien wie Green Screen oder GUI ist das kaum möglich. Nahtlose Integration ist gefragt. An Windows .NET oder HMTL/Javascript als Benutzerschnittstelle und XML- bzw. Web-Services als Kommunikationsprotokoll mit Servern wird hier kaum ein Weg vorbeiführen.

Auch die Server-Landschaft selbst ist in Bewegung. Nehmen wir z.B. an, ein Unternehmen möchte seine Restposten automatisch über Ebay versteigern, so bietet Ebay eine XML-basierte Schnittstelle bzw. künftig eine auf Web-Services basierende Schnittstelle. Um solche Schnittstellen vom Server aus einfach zu bedienen, bieten sich Java und .NET an. Es ist zu erwarten, dass die RPG- und Cobol-Programme auf dem Server ebenfalls verstärkt über XML von .NET und Java förmlich „umzingelt“ werden. Als Krönung des Ganzen sehen die Marktforscher bis 2008 eine absolute Dominanz von .NET und Linux bei den Betriebssystemen. Von OS/400 ist keine Rede mehr…

Anpacken oder Aussitzen?

In der Regel finden sich in den Unternehmen vier klassische Reaktionsmuster, um diesen Wandel zu bewältigen. Lösung Nummer 1 ist die Suche nach einer geeigneten Standard-Software und die Verlagerung der technologischen Innovation vom Unternehmen zum Software-Hersteller. Ist eine geeignete Software nicht zu bekommen, so wird über eine Neuentwicklung der entsprechenden Anwendung mit Java- oder .NET-Technologie nachgedacht. Meistens scheitert dies an Kosten, Ressourcen oder unklaren bzw. überzogenen Vorstellungen nach dem Motto: „Jetzt haben wir die Chance alles besser zu machen…“. Ist die Ernüchterung erst groß genug, dann verbleibt die Methode des schrittweisen Verbesserns bzw. Ersetzens der bestehenden Anwendungen. Der Vollständigkeit halber muss noch Lösung Nummer 4 erwähnt werden: „Wir machen das seit 20 Jahren so…“. Es liegt in der Natur des Menschen, dem Wandel zu misstrauen und manchmal hat er damit sogar Recht. Leider reicht Lösung 4 bei den meisten nicht mehr bis zur Pensionierung…

Kontrollierter Wandel durch schrittweise Verbesserungen

Von allen klassischen Reaktionsmustern vereint die Methode des schrittweisen Verbesserns und Ersetzens das am besten ausgewogene Verhältnis von Innovation und Beständigkeit. Wichtig ist eine klare Zielvorstellung, wie weit die Innovation letztendlich gehen soll. Nur dann können auch geeignete Mittel herangezogen werden. Idealerweise erfolgt der kontrollierte Wandel getreu dem Motto: „Verbinde das Angenehme mit dem Nützlichen“. Das Nützliche sind die bestehenden Geschäftsprozesse und Programme, das Angenehme sind die Möglichkeiten, die sich aus den neuen Technologien ergeben.

Ein solcher technologischer Innovationspfad sollte mit überschaubaren Schritten begangen werden. Schritt 1 des Innovationspfades ist heute bereits bei fast allen Herstellern von Standard-Software und vielen Anwenderunternehmen verbreitet: Aus dem 5250-Datenstrom wird mittels Screen Scraper-Programmen eine GUI erstellt. Die in der Praxis erzielten Erfolge reichen von „Anwender sind zufrieden“ bis zu „Verschlimmbesserung“. Es hat sich klar gezeigt, dass Ergonomie und Mehrwerte in Form von Integration zu zufriedenen Anwendern führen – Guisierung ohne klares Konzept hingegen lässt den Wunsch nach dem guten alten Green Screen wieder aufkommen. Die Einschränkungen des 5250-Datenstromes setzten dem Verfahren klare Grenzen und sorgen für einen erhöhten Wartungsaufwand und teilweise auch für erhöhte Antwortzeiten.

Diese Probleme werden überwunden in Schritt 2, der Serverlösung mit einer Thin Client-GUI. Durch Serverisierung wird der 5250-Datenstrom komplett ausgebaut und die Anwendung wird zur echten Server-Anwendung. Ein angenehmer Nebeneffekt ist, dass die Anwendung keine interaktive Leistung mehr benötigt, was die Anschaffungskosten für einen neuen iSeries-Server erheblich senken kann. Da die Anbindung der Clients an die Server-Programme bereits über Standard-XML erfolgt, ist es nur noch ein kleiner Sprung zu Schritt 3, der EAI Integration über XML. Durch das Bereitstellen einer XML-basierten EAI-Schnittstelle können die bestehenden Anwendungen über XML mit neuen Server-Anwendungen integriert oder von diesen ferngesteuert werden. Der Sprung zu Schritt 4 (Plattformunabhängigkeit) ist etwas größer, wenn die neue Server-Umgebung z.B. Windows oder Linux statt iSeries sein sollte. Die Preisentwicklung bei Intel-basierten Servern könnte für den einen oder anderen treuen OS/400-Anwender durchaus verlockend sein. Erfreulicherweise profitiert Schritt 4 von allen Arbeiten aus Schritt 2 und 3, da diese bereits völlig plattformunabängig durchgeführt wurden. In Schritt 5, dem Aufbau einer Servicebasierten Architektur, wird nun überlegt, ob bestimmte Funktionalität in Form eines Service verpackt und dann z.B. externen Geschäftspartnern oder auch anderen internen Nutzern bzw. Anwendungen in Form eines Web-Service zur Verfügung gestellt wird. Die Modellbasierte Entwicklung als Schritt 6 kann dann, wenn die entsprechende Technologie weit genug ausgereift ist, dazu verwendet werden, veraltende Anwendungsteile sukzessive zu ersetzen. Das Ergebnis wäre dann eine sauber in Schichten aufgeteilte Zielarchitektur, in der die bestehenden (nützlichen) RPG- und Cobol-Anwendungen über klare Schnittstellen mit den neuen Technologien oder Plattformen integriert werden.

Kosten senken und Risiko minimieren

In der Praxis hat sich gezeigt, dass der hier beschriebene schrittweise Wandel keineswegs trivial ist, doch von einem mittelständischen Unternehmen mit motivierter IT-Mannschaft sicher beschritten werden kann. Um die Kosten und den Arbeitsaufwand für die einzelnen Schritte zu reduzieren, wurde von der PKS Software GmbH in Verbindung mit den führenden AS/400-Häusern ein entsprechendes Toolset – die AX/ware Tools – geschaffen. Know-how und Praxiserfahrung wurden in Tools und Methoden gegossen, die für alle Schritte nahtlos zusammenpassen und sowohl für hohe Wirtschaftlichkeit als auch für Investitionssicherheit sorgen. Der kontrollierte Wandel durch schrittweise Verbesserungen mit seinem einfachen Einstieg über die Serverisierung hat sich bereits bewährt bei öffentlichen Verwaltungen, Versicherungen, Banken, in der Fertigung, dem Rechnungswesen, der Logistik, im Handel und vielen anderen Branchen.

Karlheinz Peter, Geschäftsführer

PKS Software GmbH

D-88214 Ravensburg

Telefon: (+49) 0751-56140-0

www.pks.de