Neuentwicklung, Modernisierung oder auch die Koexistenz von alt und neu: Application Modernization

Viele Unternehmen sehen die Notwendigkeit, ihre bestehenden Anwendungen auf neue Architekturen umzustellen. Doch in diesen Anwendungen steckt ein hohes Invest sowie ein enormes Know-how, das man erhalten möchte. Um nun zu neuen Architekturen zu gelangen gibt es verschiedene Technologien, die der Autor im folgenden Artikel gegenüber stellt. Dieser Beitrag soll dazu beitragen, Entscheidungen zu treffen, ob das jeweilige Unternehmen eher den revolutionären Ansatz – also die Neuentwicklung – oder eher den evolutionären Weg, also die Modernisierung und sanfte Migration einschlagen sollte. Viele Unternehmen sehen die Notwendigkeit, ihre bestehenden Anwendungen auf neue Architekturen umzustellen. Doch in diesen Anwendungen steckt ein hohes Invest sowie ein enormes Know-how, das man erhalten möchte. Um nun zu neuen Architekturen zu gelangen gibt es verschiedene Technologien, die der Autor im folgenden Artikel gegenüber stellt. Dieser Beitrag soll dazu beitragen, Entscheidungen zu treffen, ob das jeweilige Unternehmen eher den revolutionären Ansatz – also die Neuentwicklung – oder eher den evolutionären Weg, also die Modernisierung und sanfte Migration einschlagen sollte.

Monolithische Architekturen

Mehr als 80 Prozent der heute im Einsatz befindlichen betriebswirtschaftlichen Applikationen sind in Cobol, RPG oder vergleichbaren Technologien geschrieben. Monolithisch bedeutet, dass das User Interface eng verwoben mit der eigentlichen Geschäftslogik ist, dass oft sogar direkte Datenbankzugriffe aus der Anwendungslogik heraus getätigt werden. Das heißt, es existiert keine klare Trennung zwischen den Ebenen „Präsentationsschicht“ (User Interface), „Anwendungslogik“ und „Datenbank“. Das Elementarprinzip „Kapselung“, wie es das Software Engineering lehrt, ist nicht oder nur rudimentär vorhanden.

Solche Applikationen sind naturgemäß nur bedingt flexibel, um neuen Anforderungen wie grafisches User Interface, Portabilität, Plattformunabhängigkeit, Skalierbarkeit und Integrationsfähigkeit in beispielsweise e-Business-Umgebungen gerecht zu werden. Zudem sind diese Applikationen oft schwer wartbar und damit teuer. Nicht selten findet man Applikationen mit mehr als 10.000 Lines of Code, entwickelt vor 10 oder mehr Jahren. Nur eine Person im Unternehmen kennt sich überhaupt damit aus. Sollen sich jüngere Kolleginnen und Kollegen einarbeiten, so geschieht das oft mit Widerwillen. Veränderungen nimmt man nur sehr ungern vor, da die Seiteneffekte oft unvorhersehbar sind.

Aber diese Anwendungen sind funktional hervorragend. Sie decken die Geschäftsprozesse des Unternehmens sehr gut ab. Sie sind optimal performant, stabil sowie durch den langjährigen Einsatz oft fehlerfrei und beherrschbar. Sie sind gut. Es stellt sich also die Frage, ob es für das jeweilige Unternehmen nicht günstiger ist, als Alternative zur kompletten Neuentwicklung zu versuchen, die Vorteile der existierenden Applikationen zu erhalten und eine sanfte Migration anzustreben.

Warum neue Architekturen

Noch nie war es so wichtig wie heute, Anwendungen flexibel aufzubauen. Die Innovationszyklen waren noch nie so kurz, der Erfolg eines Unternehmens war noch nie so stark abhängig von der Leistungsfähigkeit der IT wie in der heutigen e-Business-Zeit.

Die Anwender fordern State-of-the-Art-Bedienoberflächen; Integration in z.B. Office-Umgebungen wird erwartet. Der berühmte Anwendungsstau wird nicht mehr akzeptiert, neue Anforderungen müssen schnell realisiert werden. Das Management fordert Integrationsfähigkeit, insbesondere e-Business-Fähigkeit und geringe Wartungskosten. Auf den Unternehmen lastet ein großer Wettbewerbsdruck. Die Inhouse-Applikationen müssen in B2B-Umgebungen integrierbar sein; Kunden, Lieferanten und Außendienstmitarbeiter wollen per Internet auf die Daten und mehr noch auf die Applikationslogik zugreifen. Die aktuellen Entwicklungen im Bereich ?Mobile Business? haben die technologischen Voraussetzungen geschaffen.
Aus der Sicht des Software-Entwicklers lassen sich diese Forderungen nur durch flexibel und skalierbar aufgebaute Applikationen bedienen. Grundvoraussetzung ist, dass die Anwendungen streng 3-schichtig aufgebaut sind. D.h. es muss in der Software eine klare Trennung zwischen dem User Interface, der eigentlichen Anwendungslogik und der Datenbank existieren. Idealerweise sind die Applikationen stark modularisiert, die Geschäftslogik ist in Komponenten – so genannten ?Business Objects? – gekapselt. Plattformspezifische Programmierung sollte soweit wie möglich eliminiert werden. Die Objekte verfügen über standardisierte Schnittstellen und sind austauschbar. Die Applikationen werden dadurch flexibel, schnell änderbar, wartungsfreundlich und integrierbar. Technologisch sollten die Objekte in einem standardisierten Objektmodell implementiert sein ? wie z.B.: EJB / J2EE, CORBA oder COM.

Einer Idealsicht des Informatikers steht die betriebswirtschaftliche Sicht des Managements gegenüber. Es existiert ja das Team, das die bisherigen Applikationen entwickelt hat. Dieses Team bringt hervorragendes Know-how über die Prozesse des Unternehmens sowie über die Umsetzung dieser Prozesse in die Software mit. Dieses Know-how gilt es zu erhalten. Das Management muss also beurteilen, inwieweit das existierende Team zu motivieren ist, sich in neue Technologien einzuarbeiten. Das Management muss Kosten beurteilen und Zeithorizonte abschätzen.

Eine Gartner Studie vom September 2000 hat sich mit der Fragestellung beschäftigt, welche Investitionen notwendig sind, um einen Cobol-Programmierer in Java auszubilden, so dass er die gleiche Produktivität in Java erreicht, wie vorher in Cobol. Das Ergebnis dieser Studie zeigt, abhängig natürlich von individuellen Faktoren, dass betriebswirtschaftlich gesehen durch Ausbildungskosten und Produktivitätsausfall ungefähr ein Jahresgehalt anzusetzen ist. Die komplette Ausbildungs- und Einarbeitungszeit ist ebenfalls mit zirka einem Jahr anzusetzen. Damit stellt sich die Frage, ob die Ideallösung des Informatikers auch betriebswirtschaftlich in allen Fällen vernünftig ist und welche Alternativen existieren.

Klassifizierung Technologien

Folgende grundlegenden Technologien lassen sich unterscheiden. Dabei können die genannten Ansätze entweder isoliert gefahren werden oder auch in eine sukzessive Migration hin zu neuen Architekturen integriert werden.

1. GUIfizierung
2. Modularisierung (ILE, SQL)
3a. 4GL / Sourcecode-Generatoren
3b. HLL (High Level Language) Coding
4. OOA/OOD/OOP

Aufwand und Nutzen von Modernisierungstechnologien

Grundsätzlich kann man sagen, dass die Komplexität und damit die Kosten von 1. nach 4. steigen. GUIfizierung ist sehr einfach und schnell mit geringen Kosten zu realisieren, die Neuentwicklung mit vollständiger objektorientierter Analyse und Programmierung ist dagegen sehr aufwendig und teuer.
Umgekehrt steigt auch die Wirkung, d.h. die Vorteile bezüglich Flexibilität, Integrationsfähigkeit, Wartbarkeit, Anpassbarkeit, Skalierbarkeit und Portabilität der mit der jeweiligen Technologie entwickelten Applikationen. Es ist also notwendig, dass man sich seine jeweilige Ausgangssituation klar macht und eine Bewertung der unterschiedlichen Technologien durchführt, um zu der insgesamt günstigsten Entscheidung zu gelangen.

Fragen die man sich stellen sollte sind zum Beispiel:

-Habe ich die ?grüne Wiese? und die Zeit für die komplette Neuentwicklung?

-Habe ich Investitionen zu schützen, möchte ich das Existierende möglichst erhalten bzw. Neues entwickeln und Existierendes integrieren?
-Welches Know-how und welche Motivation hat mein Team; welche Technologien sind beherrschbar für mein Team?
-Möchte ich einen sanften Übergang oder den „Big Bang“ – also Evolution oder Revolution?
-Welche Kosten sind darstellbar, welche Risiken sind tragbar?

Im Folgenden sollen die unterschiedlichen Technologien 1. bis 3. besprochen und Vor- und Nachteile andiskutiert werden. Der Ansatz „OOA/OOD/OOP“ ist weniger Werkzeug oder Programmiersprache, sondern die Methodik, wie sie heute Stand der Technik im Software Engineering ist. Aus diesem Grund wird in diesem Beitrag nicht näher darauf eingegangen.

GUIfizierung

Grundsätzlich wird bei dieser Technologie die existierende Applikation unverändert oder weitestgehend unverändert erhalten. Die zeichenorientierten 5250-Bildschirmdialoge werden durch grafische Benutzeroberflächen ersetzt. Dies geschieht in der Regel durch automatisierte Werkzeuge, die entweder den 5250-Datenstrom interpretieren und damit grafischen Masken zuordnen oder die direkt eine Konvertierung der DDS vornehmen.

Es gibt hier mehrere Werkzeuge von verschiedenen Herstellern, die sich hauptsächlich im Preis, der Leistungsfähigkeit und des Automatisierungsgrades unterscheiden. Komfortablere Werkzeuge sind in der Regel teurer, der Aufwand in der Umsetzung ist dann aber auch geringer. Die meisten Werkzeuge erreichen eine Browserfähigkeit der umgestellten Applikationen und damit Web-Fähigkeit. Oft spricht man auch von Web-Enabling.

Diese Technologie ist sehr gut geeignet, wenn das primäre Problem die nicht vorhandene grafische Benutzeroberfläche ist. Die existierenden Applikation bleiben unverändert, d.h. insbesondere, dass Stabilität und Verfügbarkeit unverändert bleiben und dass somit ein geringes Risiko eingegangen wird. Man betritt wenig Neuland, die Kosten sind sehr überschaubar. Im Wesentlichen betrifft es die Tool-Kosten, denn der Realisierungsaufwand ist gering.
Es besteht allerdings eine große Gefahr, dass man sich in eine Sackgasse begibt. Was kommt nach der GUIfizierung? Die allermeisten Werkzeuge arbeiten in einer geschlossenen Runtime-Umgebung, d.h.: Man erhält zwar die grafische Oberfläche, aber die Grundproblematiken der existierenden Applikationen in Bezug auf Wartbarkeit, Skalierbarkeit, Flexibilität usw. bleiben bestehen. Hier gibt es vereinzelt Werkzeuge, die einen offenen Ansatz verfolgen – wie z.B. Sourcecode-Generierung – und damit mehr Flexibilität und Erweiterbarkeit bieten und gegebenenfalls bereits einen ersten Schritt in ein neues Entwicklungsparadigma darstellen.

Modularisierung

Auf Basis der ILE-Technologie lassen sich monolithische Applikationen modularisieren. SQL ist ideal, um die Datenbank zu kapseln und eventuell eine Portierbarkeit der Datenbank zu erreichen. Geht man diesen Weg, erzielt man sicherlich Vorteile in der Wartbarkeit. Die Applikationen werden flexibler. Schafft man in der Konsequenz auch die Trennung von User Interface und Anwendungslogik, so kann man existierende Module auch per Remote Procedure Call – direkt oder über einen Application Server – in z.B. Java-basierende Neuentwicklungen integrieren. Es stellt sich allerdings die Frage, ob das Aufwand/Nutzen-Verhältnis in Ordnung ist. Für diesen Weg gibt es im Prinzip keine Automatisierung. Dieser Weg ist zeitaufwendig und damit teuer. Konkrete Ergebnisse und damit Wirkungseffekte lassen sich erst spät realisieren. D.h.: Man hat in der Anfangsphase auch eine gewisse Rechtfertigungsproblematik, ob der getätigte Aufwand sich amortisieren lässt.

Geht man diesen Weg, sollte man ihn sehr konsequent gehen. Wichtig ist eine klare Vision, ein klarer Projektplan mit „Milestones“, also wann welche Ergebnisse zu erreichen sind. Unabdingbar ist auch die Vision, was nach der konsequenten Modularisierung als nächster Schritt folgen soll, z.B. die Überführung in ein OO-basierendes Entwicklungskonzept.

HLL Coding und 4GL / Generatoren

Grundsätzlich ist hier der Schwerpunkt die Neuentwicklung. Entweder in einer aktuellen Programmiersprache wie Java oder C++ oder werkzeuggestützt in einer 4GL-Umgebung. Die Entwicklung in einer nativen Programmiersprache bringt maximale Flexibilität. In der Regel entwickelt man heute objektorientiert und komponentenbasierend, z.B. Java und EJB oder C++ und COM. Man implementiert mehrschichtige Architekturen, meist mit einem Application Server auf dem Middle Tier. Marktführend sind hier IBMs Webshpere und BEAs Weblogic. Durch den Application Server erhält man sehr gute Skalierbarkeit und sehr gute Integrationsfähigkeit; der Application Server stellt einen gewissen Industriestandard dar. Existierende Applikationen kann man integrieren, wenn sie entsprechend modularisiert und gekapselt sind.

Der Aufwand ist allerdings sehr hoch. Durch die mehrschichtigen Architekturen, das GUI, die Webfähigkeit und den Application Server erhalten die Applikationen einen deutlich höheren Komplexitätsgrad als früher in der monolithischen Architektur. Dieser Komplexitätsgrad wird sehr häufig unterschätzt oder sogar unterschlagen. Bei allen Vorteilen, die diese Architekturen bezüglich Flexibilität, Skalierbarkeit, Portabilität usw. erzielen, so ist doch die Produktivität in der Erstellung deutlich niedriger als in den traditionellen Programmiersprachen. Auch sollte man den Ausbildungsaufwand nicht unterschätzen. Es genügt nicht, nur die Syntax einer Sprache zu lernen, man muss sich die Konzepte erarbeiten und auch selbst die entsprechenden Erfahrungen machen.
Als eine Alternative zur Entwicklung in einer nativen Programmiersprache – wie Java oder C++ – sind 4GL-Umgebungen oder Sourcecode-Generatoren zu sehen. Der Ansatz dieser Werkzeuge ist, dass die Entwicklung auf einem höheren Abstraktionsgrad angesetzt wird – also näher an den Geschäftsprozessen und näher an den Geschäftsobjekten. Das Werkzeug kapselt für den Software-Entwickler die darunter liegende Technologie. Diese Werkzeuge haben oft – im positiven Sinn – einen gewissen proprietären Ansatz, sind aber enorm effizient im Einsatz. Sie stellen eine echte Alternative zur nativen Codierung dar. Höhere Produktivität und wesentlich geringerer Aufwand in Ausbildung sind Argumente, denen man sich nicht verschließen sollte. Diese Werkzeuge sind in der Regel optimiert für die Entwicklung von Applikationen eines bestimmten Typs – also betriebswirtschaftlichen Informationssystemen mit Datenbank und Geschäftslogik, interaktiven Anwendungen mit User Interface oder Batch-Applikationen. Oft findet man vorgefertigte Software-Komponenten, so dass das Grundgerüst der zu entwickelnden Applikation sehr schnell entsteht.

Verlässt man das standardisierte Vorgehen dieser Werkzeuge, so kann man schnell an Grenzen stoßen, der Aufwand kann sehr groß werden. D.h.: Man verliert dann die Vorteile gegenüber der nativen Codierung. Es ist vielleicht darauf zu achten, dass das jeweilige Werkzeug eine gewisse Offenheit hat, eventuell nativen Sourcecode generiert und nicht in einer gekapselten Runtime-Umgebung läuft, um solche Probleme zu vermeiden. Diese Art der Applikationsentwicklung sollte man in Betracht ziehen, wenn man sehr klar umrissene Aufgabenstellungen hat und den Erstellungs- und Ausbildungsaufwand der nativen Codierung vermeiden möchte.

Fazit

Es gibt mehrere Alternativen, um zu flexiblen und skalierbaren Applikationen zu gelangen. Es ist wichtig, dass man sich seiner Ausgangssituation bewusst ist, eine Vision entwickelt und verschiedene Randparameter überprüft. Man sollte sich die Entscheidung nicht zu einfach machen. Getrieben durch das e-Business und die Internet-Technologien bieten sich Java-basierende Ansätze an. Man sollte die Komplexität, die sich durch die Mehrschichtigkeit der Anwendungen sowie das Thema „Application Server“ ergibt, nicht unterschätzen. Die technologisch ideale Software-Architektur ist für ein Unternehmen mit bestimmten Ausgangsparametern unter Kosten/Nutzen-Aspekten nicht unbedingt auch die sinnvollste Lösung.

AD Solutions AG

D-40789 Monheim

Telefon: (+49) 02173/1675-0

www.adsolutions-group.com