Migration zu Java EE 6 abseits der grünen Wiese

Generalüberholung - Java EE 6 Style

Jens Schumann


Hat sich eine technologische Neuerung erst einmal den Weg in die Konferenzlandschaft oder in eine Fachzeitschrift gebahnt, so lassen Aussagen zu deren Effizienz, Eleganz, Performance und Wartbarkeit nicht lange auf sich warten. Auch der Spaßfaktor beim Einsatz spielt heute eine entscheidende Rolle, sodass man als Unternehmen mit einem gewissen Anteil an individuell entwickelter Java-Bestandssoftware recht schnell den Stempel „Old School IT“ abbekommt.

Natürlich wünschen wir uns alle eine IT-Landschaft, in der technologische Neuerungen leicht integriert werden können, und in der Entwicklung bzw. Wartung Spaß machen, ohne dabei täglich mit unnötiger Fleißarbeit konfrontiert zu werden. Leider besitzt aber die durchschnittliche Enterprise-Java-Bestandssoftware, speziell mit einem Ursprung vor 2005, aus heutiger Sicht zahlreiche Altlasten und architektonische Fehlentscheidungen, sodass fachliche und technologische Weiterentwicklung bisweilen stark behindert wird.

Seit dem Erscheinen von Java EE 6 hat sich trotz anfänglicher Skepsis nun gezeigt, dass die neue Enterprise-Java-Plattform für unglaublich viele Bereiche Lösungen und Antworten anzubieten hat, die durchaus den eingangs genannten Schlagworten Effizienz, Eleganz, Performance und Spaßfaktor gerecht werden. Doch auch wenn damit die Zieltechnologien klar umrissen sind, stellt sich oft die Frage, wie Hundertausende bis Millionen Zeilen Java-Code und Hunderte bis Tausende JSP/View-Fragmente migriert werden können, ohne dass die damit verbundenen Aufwände und Risiken den Mehrwehrt des Wechsels in Frage stellen.

Warum migrieren?

Bei allem Sex-Appeal einer neuen Technologie muss man sich in jedem Fall die Frage gefallen lassen, warum eine Migration einer bestehenden Enterprise-Java-Anwendung zu einem neuen Technologie-Stack notwendig und sinnvoll sein soll.

Für Enterprise-Java-Anwendungen mit einem Alter von fünf, sieben oder gar zehn Jahren gelten natürlich die klassischen Gründe, wie nicht (mehr) vorhandener bzw. auslaufender Support sowie oft eine geringe Entwicklungsgeschwindigkeit (meist in Verbindung mit einer oft technologiebedingten geringen Testabdeckung). Aber auch eine hohe Komplexität in der Entwicklung und fehlender Funktionsumfang können eine Migration notwendig machen, insbesondere wenn für die verwendeten Technologien heute nur noch wenig bis gar kein Know-how mehr am Markt verfügbar ist.

Interessanterweise zeigt sich auch, dass immer mehr Unternehmen wegen des eingesetzten Technologie-Stacks Schwie...

Migration zu Java EE 6 abseits der grünen Wiese

Generalüberholung - Java EE 6 Style

Jens Schumann


Hat sich eine technologische Neuerung erst einmal den Weg in die Konferenzlandschaft oder in eine Fachzeitschrift gebahnt, so lassen Aussagen zu deren Effizienz, Eleganz, Performance und Wartbarkeit nicht lange auf sich warten. Auch der Spaßfaktor beim Einsatz spielt heute eine entscheidende Rolle, sodass man als Unternehmen mit einem gewissen Anteil an individuell entwickelter Java-Bestandssoftware recht schnell den Stempel „Old School IT“ abbekommt.

Natürlich wünschen wir uns alle eine IT-Landschaft, in der technologische Neuerungen leicht integriert werden können, und in der Entwicklung bzw. Wartung Spaß machen, ohne dabei täglich mit unnötiger Fleißarbeit konfrontiert zu werden. Leider besitzt aber die durchschnittliche Enterprise-Java-Bestandssoftware, speziell mit einem Ursprung vor 2005, aus heutiger Sicht zahlreiche Altlasten und architektonische Fehlentscheidungen, sodass fachliche und technologische Weiterentwicklung bisweilen stark behindert wird.

Seit dem Erscheinen von Java EE 6 hat sich trotz anfänglicher Skepsis nun gezeigt, dass die neue Enterprise-Java-Plattform für unglaublich viele Bereiche Lösungen und Antworten anzubieten hat, die durchaus den eingangs genannten Schlagworten Effizienz, Eleganz, Performance und Spaßfaktor gerecht werden. Doch auch wenn damit die Zieltechnologien klar umrissen sind, stellt sich oft die Frage, wie Hundertausende bis Millionen Zeilen Java-Code und Hunderte bis Tausende JSP/View-Fragmente migriert werden können, ohne dass die damit verbundenen Aufwände und Risiken den Mehrwehrt des Wechsels in Frage stellen.

Warum migrieren?

Bei allem Sex-Appeal einer neuen Technologie muss man sich in jedem Fall die Frage gefallen lassen, warum eine Migration einer bestehenden Enterprise-Java-Anwendung zu einem neuen Technologie-Stack notwendig und sinnvoll sein soll.

Für Enterprise-Java-Anwendungen mit einem Alter von fünf, sieben oder gar zehn Jahren gelten natürlich die klassischen Gründe, wie nicht (mehr) vorhandener bzw. auslaufender Support sowie oft eine geringe Entwicklungsgeschwindigkeit (meist in Verbindung mit einer oft technologiebedingten geringen Testabdeckung). Aber auch eine hohe Komplexität in der Entwicklung und fehlender Funktionsumfang können eine Migration notwendig machen, insbesondere wenn für die verwendeten Technologien heute nur noch wenig bis gar kein Know-how mehr am Markt verfügbar ist.

Interessanterweise zeigt sich auch, dass immer mehr Unternehmen wegen des eingesetzten Technologie-Stacks Schwie...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang