Round Table Diskussion über Anwendungsmodernisierung, Teil 4

10. November 2008 | Von | Kategorie: Strategische Berichte

Ein Internet-Artikel aus der NEWSolutions mit NEWSabo plus Zugang: In Teil 1 und 2 und 3 der Diskussion (erschienen in den NEWSolutions-Ausgaben Januar, Februar und März 2007) begann die Diskussionsrunde mit Beiträgen zu den Schwierigkeiten, die Unternehmen oft daran hindern, eine Modernisierung ihrer Anwendungen in Angriff zu nehmen (mangelnde Zeit, unzureichende Ausstattung mit Personal und Ressourcen, fehlende Argumente, um das Management von der Notwendigkeit zu überzeugen, sowie unzureichende Kontrolle über die gegenwärtige Software oder fehlende Kenntnis über einen einfachen Weg zur Umsetzung). Die Diskussion wurde mit Beiträgen zur Notwendigkeit fortgesetzt, einen taktischen Ansatz zu finden, mit dem die Anwendungen Web-fähig gemacht werden können, sowie zu Pro und Kontra beim Einsatz von WebSphere, CGI, EGL und anderen Technologien

Tendenzen und Hürden bei der Anwendungsmodernisierung

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

In den ersten drei Teilen der Diskussion (erschienen in den NEWSolutions-Ausgaben Januar, Februar und März 2007) wurden zu Beginn die Probleme und Schwierigkeiten angesprochen, die Unternehmen oft daran hindern, eine Modernisierung ihrer Anwendungen in Angriff zu nehmen. Die Diskussion wurde mit Beiträgen zur Notwendigkeit fortgesetzt, einen taktischen Ansatz zu finden, mit dem Anwendungen Web-fähig gemacht werden können. Der Fokus für den Start einer Modernisierung lag hierbei eindeutig auf den externen Anwendungen. Darüber hinaus wurde betrachtet, was getan werden kann, um auch eine Modernisierung der eigenen Vorstellungen in Angriff zu nehmen. Im heutigen vierten und letzten Teil wird die Diskussion mit Betrachtungen zu JDBC, modularen Entwicklungsansätzen und dem viel diskutierten Thema PHP auf i5 fortgesetzt.

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.

Scott Klement: JDBC ist sicherlich eine gute Wahl. Auch der Einsatz von HSSF (Java API für den Zugriff auf Daten im Microsoft Excel Format) zum Erstellen von Excel-Arbeitsblättern bietet eine weitere gute Einsatzmöglichkeit für Java. Ich weiß nicht, wie es sich mit Sockets verhält, aber die lassen sich ja auf einfache Weise mit native APIs erstellen. Ein guter Einstiegspunk

t für das Erlernen neuer Skills ist das Schreiben einiger kleiner Dienstprogramme, die nicht unbedingt über Bildschirmzugriffe verfügen müssen, und zusätzlich das Herunterladen eines der frei erhältlichen, wirklich großartigen Tools, die für Java als Back-End vorhanden sind.

Sharon Hoffman:: Paul und Bryan haben einen wichtigen Punkt angesprochen. Wenn Menschen über Code in einer traditionellen RPG-Umgebung nachdenken, so denken sie meist an einen großen, unbeweglichen Block. Sie denken an eine Anwendung, die meist nur über wenige sich verändernde Teile verfügt. All diese Umgebungen (und hier sind speziell die Java Frameworks in dieser Hinsicht fast erschreckend) verfügen über eine Vielzahl von veränderlichen Teilen. Erlernt man also Java oder HTML, um nur zwei der zentralen Skills in dieser speziellen Umgebung zu nennen, so ist man anschießend dennoch nicht in der Lage, irgendetwas zu erstellen. Es ist so, als hätte man von jemandem die Zutaten bekommen, aber nicht das Rezept. Und Rezepte sind nun mal meist nicht unkompliziert.
In dieser Situation können Tools zur Code-Generierung Hilfestellung leisten. Meine Erfahrungen mit solchen Tools haben aber ergeben, dass sie wirklich unansehnlichen Code erzeugen, aus dem sich nicht so leicht etwas lernen lässt. Das, was diese Tools erzeugen, beinhaltet so viel, dass es schwerfällt herauszulesen, wie etwas wirklich erstellt wird. Also kehrt man besser zurück zu der Idee, unter Nutzung all dieser kleinen Elemente etwas Überschaubares zu erstellen. Ein großer Teil bezieht sich dabei allerdings nicht auf Programmiersprachen, sondern auf die Programmarchitektur. Für lange Zeit lebten wir mit dem Luxus, uns um die Programmarchitektur nicht weiter kümmern zu müssen und manch einer von uns hat Programme möglicherweise bisher noch nie aus dieser Perspektive betrachtet.

Bryan Meyers: Ja, das ist wohl wahr. Viele von uns haben für lange Zeit Anwendungen immer im großen Stil betrachtet – denken wir nur an solche Zwei-Millionen-Codezeilen-Anwendungen. Wir müssen nun wirklich damit beginnen, in kleinen und immer kleineren Größenordnungen zu denken. Wir müssen an Prozeduren mit nur 20 Codezeilen denken, die sich hundertfach einsetzen lassen anstelle uns gedanklich damit zu befassen, eine Anwendung mit zwei Millionen Codezeilen modernisieren zu wollen.

Carsten Flensburg: Mein Hintergrund liegt eher im geschäftlichen Umfeld. Was in dieser Diskussion bisher nicht so recht angesprochen wurde, ist die Tatsache, dass alles doch eigentlich mit den Anforderungen eines Unternehmens und der Unternehmensstrategie beginnt. Das selbstverständlich sollte zu einer IT-Strategie führen ohne dabei zu vergessen, drei Jahre in die Zukunft zu blicken. Möglicherweise endet man nach diesen drei Jahren nicht unbedingt dort, wo man geplant hatte, aber für das, was man tut, ist eine klare Richtung unabdingbar. Und diese Richtung sollte eng an die Unternehmensstrategie angeglichen sein.
Ich halte dies für ein gewichtiges Argument. Es ist etwas, auf das mein Unternehmen viel Zeit verwendet hat. Zum Teil vielleicht auch deshalb, weil wir von einem großen, global agierenden Unternehmen übernommen wurden, das in dieser Weise agiert. Dieses Unternehmen möchte von uns wissen, wohin wir uns entwickeln wollen, bevor es Mittel für irgendwelche IT-Aktivitäten bereitstellt. Wir müssen Budgetierungspläne vorlegen und präzise erläutern, wie diese Pläne sich mit der IT-Stategie unseres Unternehmens decken. Können wir diese Übereinstimmung nicht nachweisen, erhalten wir keine Mittelfreigabe. Das ist für uns einerseits eine klare Regelung, andererseits werden dadurch aber auch die Dinge eingeschränkt, die wir in technischer Hinsicht in Angriff nehmen möchten. Wir haben hier über viele technische Themen diskutiert und die unterschiedlichen Optionen beleuchtet. Erst wenn wir exakt wissen, wie das Ergebnis aussehen soll, können wir beginnen, über die Technologien zu reden, die uns dorthin bringen sollen. Bei unterschiedlichen Unternehmensanforderungen können dabei sehr unterschiedliche Anwendungstypen und technische Lösungen herauskommen.

Wayne Madden:
Das ist ein guter Gesichtspunkt, weil Unternehmen, die in dieser Weise verfahren, ein klares Bild von ihrer Vision, ihrer Strategie und ihren Zielvorstellungen haben. Nur so ist es möglich, Anforderungen an die IT zur Entwicklung einer Strategie für die Umsetzung dieser Vorstellungen zu entwickeln. In der Realität wird dabei wohl eher eine Mischung aus Teilen dieser klar definierten Vorgehensweise herauskommen. Wir bewegen uns überwiegend in einem Markt, der sich aus kleinen und mittleren Unternehmen zusammensetzt, in dem natürlich aber auch eine Reihe großer Unternehmen vorhanden ist. Viele dieser Unternehmen in diesem Markt arbeiten in dieser Hinsicht aber eher informell. Die tatsächliche Frage an die IT lautet dort meist einfach: „Was denkt ihr, was ihr tun könnt, um Verbesserungen für unser Unternehmen zu erreichen?“

Schlagworte: , , , , , , , , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.