Tendenzen und Hürden bei der Anwendungsmodernisierung

Übersetzer

Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener.

Während unserer alljährlichen Redaktionskonferenz kamen die technischen NEWSolutions Redakteure zu einer Round Table Diskussion zusammen, um sich mit der Bedeutung der Anwendungsmodernisierung und den Problemen auseinanderzusetzen, mit denen sich viele Unternehmen bei der Umsetzung solcher Projekte konfrontiert sehen. Die Diskussion wurde von Wayne Madden, dem Chefredakteur des internationalen Redaktionsteams, geleitet. Teilnehmer dieser Diskussion waren die leitenden technischen Redakteure Mel Beckman, Paul Conte, Sharon Hoffman und Michael Otey sowie die technischen Redakteure Don Denoncourt, Nahid Jilovec, Scott Klement, Bryan Meyers, Dan Riehl, Carson Soule und als Gast Carsten Flensburg. Teil 1 dieses Artikels ist in der Januarausgabe 2007 von NEWSolutions erschienen.

 

Dan Riehl: Ein wesentlicher Aspekt bei der Planung von Modernisierungsprojekten ist die Tatsache, dass das Management überzeugt werden muss, denn dort fällt letztlich die Entscheidung über die Freigabe entsprechender Mittel. Solche Projekte werden kaum genehmigt, solange nicht ein vernünftiger Business Case vorgelegt werden kann, der zumindest eine gewisse Amortisation der zu investierenden Mittel ausweist. Modernisierungsprojekte können sich hinsichtlich des finanziellen, personellen sowie zeitlichen Aufwandes als recht kostspielig erweisen und bringen üblicherweise ein gewisses Maß an Störungen des gewohnten Geschäftsbetriebes mit sich.

Erfüllen die aktuell implementierten Anwendungen die geschäftlichen Anforderungen eines Unternehmens, reicht es möglicherweise aus, nur ein paar taktische Lösungen bezüglich der Web-Präsenz hinzuzufügen, die eine Interaktion mit Kunden und Lieferanten via e-Commerce ermöglichen. Arbeitet die gesamte Green-Screen-Welt ansonsten zufriedenstellend, ist es normalerweise nicht unbedingt vernünftig, beim Management vorstellig zu werden und zu sagen: „Ich möchte gerne unsere gesamten Anwendungen auf diese neue Web-basierte graphische Umgebung umstellen. Das wird ca. 2 Jahre oder mehr in Anspruch nehmen, einen gewaltigen finanziellen und personellen Aufwand und gewisse Störungen im Betriebsablauf mit sich bringen. Ach ja, und wir werden überdies unsere Anwendungen für die Dauer der Umstellungsphase auf dem jetzigen Stand einfrieren müssen.“

Selbst wer über große Pläne verfügt und den überschwänglichen Enthusiasmus eines GUI-Evangelisten besitzt, wird eine solche Generalüberholung dem Management nur sehr schwer verkaufen können. Dennoch werden sowohl ein solider Plan als auch ein gesunder Enthusiasmus benötigt, bevor man überhaupt auf das Management zugehen kann, ohne einen Verlust an Glaubwürdigkeit zu riskieren.

Wayne Madden: Ich möchte Dan’s Gedanken noch etwas weiterführen. Stellen wir uns jemanden vor, der in einer solchen Position ist. Diese Person arbeitet in einem Unternehmen, nimmt nur das Notwendigste in Angriff und hält sein Team so klein wie nur irgend möglich. Er generiert letztlich eine Menge an Umsatz, die Geschäfte laufen gut und die Produkte verkaufen sich. Er hat einige taktische Lösungen bezüglich der Web-Präsenz implementiert. Bleibt er auf diesem Stand, wird irgendwann jemand sagen: „Wir brauchen eine neue, moderne Anwendung.“ Und alle Anwendungen, die sich sein Unternehmen ansieht, gewinnen sofort die Zustimmung der Anwender, weil sie über graphische Oberflächen verfügen. Es ist eine Art sich selbst erfüllende Prophezeiung: Wir haben kein Personal, wir haben kein Geld und wir werden auch keine Veränderung vornehmen. Letztendlich werden wir dadurch ins Abseits geraten. Auch Scott hat zuvor schon darauf angespielt. Die Benutzer wünschen sich Anwendungen mit graphischen Oberflächen, aber das Unternehmen möchte dafür kein Geld investieren. Wie könnte unser Rat in einer solchen Situation aussehen, in der man beim Management vorstellig werden und sagen möchte: „Wir sollten in diese fundamentalen Techniken investieren, weil … “

Carson Soule: Wenn es die Absicht des Unternehmens ist, ein neues Anwendungspaket zu erwerben und man daran interessiert ist, dass diese Anwendung auf dem System i5 implementiert wird, bleibt nur die Hoffnung, dass irgendein ISV ein modernes Paket auf i5-Basis anbieten kann. Rochester hat zwar erhebliche Anstrengungen unternommen, damit genau das im Markt geschehen kann, die Eigenentwicklung eines gesamten Anwendungspakets ist allerdings eine Bürde, die man selbst kaum zu tragen in der Lage sein wird. Zu einer Entscheidung für die i5 lässt sich aber beitragen, indem Verbesserungen vorgenommen werden, die eine reale Web-Präsenz gewährleisten und dem Management zeigen, dass graphische Anwendungen auf der i5 im eigenen Unternehmen eine durchaus machbare Größe sind. Das sollte ausreichend sein, um dem Management klar zu machen, dass bei der Auswahl eines graphischen Anwendungspakets die i5 als Plattform zumindest mit auf der Liste steht. Ist dieEntscheidung für den Erwerb eines Anwendungspakets gefallen, muss ein ISV mit einem wettbewerbsfähigen Paket gefunden werden, das auf der i5 läuft. Daran führt kein Weg vorbei. Es gibt in Wahrheit nichts, was man auf dem System verändern könnte, um dieses Problem zu lösen. Nun ließe sich alternativ argumentieren, dass das Unternehmen – programmierte man die alten Anwendungen schnell und brillant genug um – sich möglicherweise nicht für den Erwerb eines neuen Pakets entscheiden würde. Das aber ist unglücklicherweise schlicht gesagt naiv.

Don Denoncourt: In vielen Unternehmen konnte die taktische Migration von Anwendungen auf Web-Präsenz beim Management noch nicht durchgesetzt werden. Die Vorteile eines Web-Auftritts werden dort bislang nicht genutzt. Somit ist der erste Schritt, das Management von der Notwendigkeit einer Modernisierung zu überzeugen. Ist dieser erste Schritt getan, wird die Unternehmensleitung die neue Technologie und die sich daraus ergebenden Möglichkeiten besser einschätzen können.

Scott Klement: Carson sagte, dass eine Modifikation der existierenden Anwendungen – wenn sie sich schnell und brillant genug erledigen lässt – naiv sei. Dem kann ich nicht vorbehaltlos zustimmen. Unglücklicherweise bietet IBM keine einfache Möglichkeit an, ein RPG Programm mit einem graphischen Front-End zu versehen. Die Techniken sind zwar vorhanden, erzeugen letztlich aber erheblichen zusätzlichen Aufwand. Vielleicht liest das irgendjemand und ist in der Lage, hier helfend einzugreifen. Oder aber IBM liest dies und fühlt sich geneigt, ein graphisches Front-End für PRG anzubieten, anstatt jedermann überzeugen zu wollen, auf Java umzustellen.