Migration und die grüne Wiese Behauptung: Migration ist eine der wesentlichen Herausforderungen bei der Software-Entwicklung. Es gibt eigentlich keine grüne Wiese mehr. Oft soll ein System ein anderes ablösen. Fast immer müssen Systeme mit anderen interagieren, so dass man zumindest auf Ebene der Gesamt-IT eigentlich eine Migration hat - die Projekte werden aber nur selten so betrieben. Aber die wichtige Frage ist gerade, an welcher Stelle in der Gesamt-IT man einen neue Sache aufbauen kann und wie man dies möglichst risikolos / risikoarm macht.

In gewisser Weise will man Stabilität, weil es risikoarm ist, auf der anderen Seite Änderung, um Sachen besser zu machen. Das ist auf anderen Ebenen wie z.B. der Organisation auch so. Auch dieses Spannungsfeld kommt eigentlich von dem Migrationscharakter.

Technisch haben wir hier (vielleicht) den heiligen Gral erreicht (oder zumindest fast). Mit Spring ist die Vision umsetzbar, ein reines OO-Modell zu bauen, dass man dann auf verschiedene Technologien laufen lassen kann und so migrationsstabil über Technologien ist. EJB beispielsweise ist da, nun ja, anders. Eine Anwendung von EJB 1.0 auf EJB 2.0 und jetzt auf EJB 3 zu portieren kann - abhängig von der Verwendung - ein komplexes Unterfangen sein, dass vor allem keinen Business-Value generiert. Mit Spring kann man das reine OO-Modell unverändert lassen und vor allem werden auch alte Infrastrukturen unterstützt (alles ab J2SE 1.3 und J2EE 1.3).

Ähnliche Ideen für Technologie-Unabhängigkeit gibt es auch in der MDA und (etwas weniger) in der MDSD Szene. Ob das allerdings wirklich das Ende aller Enterprise-Technologien ist, werden wir sehen. Wenn man als Ziel hat, Mainframe-Anwendungen abzulösen, die Jahrzehnte überdauern sollen, dann wird man eben auch erst in der Zukunft die Probleme sehen...  ¶ 17:16