computerwoche.de
Newsletter  |   CW-TV  |   Bilder-Galerien  |   Blogs & Forum  |   CW mobil  |   RSS  |   Aboshop


SOA initiative 2006
SOA initiative 2006

Von der Legacy- in die SOA-Welt



Um zu klären, welche Optionen es für den Anwender gibt, muss zunächst die Frage nach dem Wert des Altsystems gestellt werden, also in welcher Weise es zur Wettbewerbsfähigkeit und Differenzierung des Unternehmens beiträgt. Zum anderen sollte man sich über die Anforderungen an Flexibilität und Agilität bei der zukünftigen Wartung und Weiterentwicklung klar sein. Abhängig von diesen Faktoren ergeben sich unterschiedliche Handlungsalternativen. So kann es Sinn haben, eine an ihr Lebensende kommende Systemplattform, die als zentral für das betriebliche Überleben bewertet wird, durch eine automatische Transformation zu verjüngen.

Ratschläge

  • Analysieren und bewerten Sie, welche Optionen zur Modernisierung der Anwendungslandschaft existieren.

  • Untersuchen Sie, ob sich eine Kombination verschiedener Ansätze empfiehlt, zum Beispiel die Transformation von Kernsystemen zusammen mit kommerziellen Komponenten, integriert auf der Prozessebene.

  • Nutzen Sie bei der Umsetzung die Möglichkeiten, welche die SOA zur Koordination von Fachbereich und IT bietet.

  • Binden Sie die Fachbereiche frühzeitig ein, insbesondere bei der Umsetzung prozessorientierter Architekturen.

  • Verhindern Sie, dass der Scope des Modernisierungsprojektes zu weit ist.

  • Die initiale Version des Zielsystems sollte funktional nahe am Altsystem sein.

  • Nutzen Sie dann die Möglichkeiten von SOA und POA, um Prozesse zu verbessern, beziehungsweise neue Prozesse und Dienste stufenweise hinzuzufügen.


Dieser Ansatz löst allerdings nicht die grundlegenden strukturellen Probleme. Bietet das Altsystem gegenüber einer modernen Standardlösung keine wesentlichen Vorteile, so ist die Migration sicher eine sinnvolle Alternative. Ist hingegen keine Standardlösung verfügbar, die den Anforderungen genügt, kommen eine Neuentwicklung beziehungsweise Reengineering in Frage. Allerdings wird bei der Neuentwicklung oft zu viel angestrebt, was häufig zum Scheitern führt. Im Gegensatz dazu hat ein Reengineering den Vorteil, dass es sich sowohl beim Scope als auch bei den konkreten Funktionen sehr nahe am Altsystem orientiert und aus diesem die fachlich wertvollen Elemente auf das neue System transformiert.

Schrittweise Entwicklung

Umfassende Eigenentwicklungen - insbesondere auf dem Mainframe - erfolgen häufig in mehreren Phasen. Zunächst erhält die vorhande Backend-Funktionalität Service-orientierte Schnittstellen, beispielsweise auf der Basis der Common Object Request Broker Architecture (Corba), durch EJB-Facaden, Queue-Wrapper oder Web-Services. Um das Backend besser warten zu können, folgt im zweiten Schritt seine Entflechtung, bei der die Module hinter den Interfaces optimiert werden. Entstehen dabei lose gekoppelte, unabhängig nutzbare und der Komplexität her beherrschbare Subsysteme, können diese oder Teile von ihnen in Reengineering-Projekten auf neue Plattformen migriert werden. Dabei steht der angestrebte Geschäftsnutzen im Vordergrund und erst in zweiter Sicht eine Optimierung aus IT-Sicht.



Seite: 1 2 3 4 5 6  weiter



Leserkommentare 
(0 Beiträge), 
Kommentieren

Beitrag schreiben

Noch kein Forums-Mitglied?
Dann gleich hier anmelden.