Die 10 Regeln der Modernisierung

Jede Durchführung einer Modernisierung (Abb. 5) kann als Aufbau von drei parallelen Aktivitäten angesehen werden, die durch einen Masterplan gesteuert werden. Der Infrastructure-Setup-Prozess stellt sämtliche erforderlichen Komponenten zur Durchführung der Modernisierung bereit. Insbesondere wenn eine schrittweise Modernisierung eines größeren Systems mit Parallelbetrieb vorgesehen ist, kommt dieser Tätigkeit eine zentrale Bedeutung zu.

Abb. 5: Die Durchführung einer Modernisierung

Der Service-Engineering-Prozess bildet die Funktionalität des bestehenden Systems auf logischer Ebene ab. Dabei werden die drei Abbildungsebenen Business Process Modelling, Business Rule Modelling und Service Design unterschieden. Das Business Process Modelling modelliert die Aufrufabfolge von Hauptprogrammen oder Batch-Prozessen als Geschäftsprozess. Diese Modellierung erfolgt in den meisten Fällen mittels einer formalen Sprache wie BPEL. Das Business Rule Modelling modelliert Geschäftsregeln zur Steuerung einzelner Prozessschritte, z. B. die Aufrufe von Subprogrammen als Business Rules. Das Service Design fasst die funktionalen Blöcke eines bestehenden Systems logisch zusammen. Falls das bestehende System im Rahmen der Modernisierung teilweise ersetzt werden soll, so werden die einzelnen Dienste neu implementiert. Wenn im Rahmen der Modernisierung zusätzliche Funktionalität bereitgestellt werden muss, so werden die entsprechenden Geschäftsprozesse, Business Rules und Dienste modelliert und implementiert.

Der Transformationsprozess stellt die eigentliche Umgestaltung des bestehenden Systems im Rahmen einer Modernisierung dar. Der Prozess hängt im Detail von der gewählten Modernisierungstechnik ab. Die schrittweise Durchführung ist empfehlenswert, wenn ein größeres System modernisiert werden soll. Jede Modernisierung ist in gewissem Sinne eine Transformation eines Systems. Diese Transformation kann implizit oder explizit erfolgen. Falls eine explizite Transformation durchgeführt werden soll, so sind die Tätigkeiten Architecture Recovery, semantische Analyse und Re-Partitioning zu unterscheiden. Das Ziel des Architecture Recovery ist die explizite Darstellung der Architektur des bestehenden Systems. Dabei werden Informationen aus der Struktur, der Umgebung und anderen Quellen extrahiert und in gängige Architekturstile transformiert. Die semantische Analyse des bestehenden Systems versucht anhand der Kriterien semantische Distanz (Anzahl der Abstraktionen), der semantischen Genauigkeit (Grad der Zuverlässigkeit der Spezifikation), semantischen Präzision (Detaillierungsgrad) und der semantischen Rückverfolgbarkeit (Grad der möglichen Rekonstruktion) die Qualität der eingesetzten Modernisierungstechnik zu verifizieren, um zuverlässige Angaben für die Neugestaltung des Systems zu erhalten. Die Überarbeitung und Transformation der bestehenden Struktur und der Umgebung des Legacy-Systems erfolgt mittels Re-Partitioning. Dabei werden z. B. Transformationen durchgeführt oder es werden ganze Teile des Systems isoliert, um sie dann wegzulassen.

Die 10 Regeln der Modernisierung

Eine Modernisierung durchzuführen bedeutet immer, einen Kompromiss zwischen der idealen Lösung und dem wirtschaftlich Machbaren zu finden. Es gibt ein paar Grundregeln, die es zu beachten gilt:

  1. Jedes System ist nach seiner Einführung ein Legacy-System. Das bedeutet, dass im Lebenszyklus eines Informationssystems der Zeitpunkt kommt, das System zu migrieren, also als Ganzes abzulösen. Die Modernisierung ist lediglich eine Verlängerung des Lebenszyklus. Falls das Legacy-System jedoch bereits mit modernen Schnittstellen versehen ist, wird die Ablösung sehr viel einfacher.
  2. Die zentrale Motivation hinter der Modernisierung eines bestehenden Systems sind die Kosten und nicht die Ausmerzung aller Probleme. Aus diesem Grund ist es wichtig, die das bestehende System kapselnden Services möglichst nahe am bestehenden System zu realisieren und einen möglichst pragmatischen Ansatz zu wählen. Die Abbildung neuer Anforderungen geschieht nicht auf der bestehenden Komponentenebene, sondern mittels Implementation neuer Services oder wird mit Komponenten auf der Presentation-, Orchestration-, Integration- und Serviceschicht realisiert.
  3. Ein in einer modernen Umgebung brauchbarer Service muss in jedem Fall mit einer standardisierten Schnittstelle versehen werden. Setzt ein Unternehmen SOA als Standardarchitektur ein, so müssen die Schnittstellen als Web Service mit WSDL und SOAP umgesetzt werden. Jede andere Realisierung macht es unmöglich, andere Standardkomponenten vernünftig einzusetzen.
  4. Bleiben Sie vorsichtig mit der Modernisierung von Standardsoftware. Es ist zu prüfen, welche Pläne der Hersteller in Bezug auf die Strukturierung seines Produkts als Sammlung von Services und vorgefertigten Geschäftsprozessen hat. Ein Upgrade des Produkts kann vernünftig sein, falls der Hersteller moderne Standards unterstützt. Eine Modernisierung mittels solcher Komponenten ist sehr viel einfacher als die eigenhändige Erstellung von Schnittstellen. Allerdings kann die Modernisierung vorgespurt werden, wenn möglichst einfache Schnittstellen erstellt werden und der Hersteller entsprechend informiert wird.
  5. Je älter ein System ist, desto weniger sollte daran geändert werden. Konsequenterweise sollte man Whitebox-Techniken nur bei jüngeren Systemen einsetzen. Die Kosten steigen mit der abnehmenden Verfügbarkeit des notwendigen Know-hows für Änderungen an den Sourcen.
  6. Die bestehende Funktionalität direkt als Service zu publizieren, ist die einfachste und kostengünstigste Lösung und in vielen Fällen auch völlig ausreichend. Jede Änderung der vorhandenen Strukturierung einer bestehenden Anwendung heißt, das System für andere Zwecke als die ursprünglich vorgesehenen zu verwenden. Die Gefahr ist groß, dass unerkannte Probleme und Abhängigkeiten für Überraschungen sorgen.
  7. Die Mächtigkeit von Scripts und Batch-Prozessen wird unterschätzt. Sie sind Kandidaten für nicht performancekritische Basisdienste. Die Batch-Call-Technik zur Modernisierung ist immer eine gute Wahl. Scripts, Batch-Prozesse und Command Line Interface entsprechen dem Ablauf eines Serviceaufrufs. Die Darstellung als Dienste ist ohne großen Aufwand zu realisierieren.
  8. Ein Database Gateway ist ein Muss für alle Unternehmen, die ein RDBMS für geschäftskritische Anwendungen bereits einsetzen und SOA einführen möchten. Kein Service ist performanter, robuster und verfügbarer als einer, der in einer zentralen produktiven Datenbank ausgeführt wird.
  9. Die flexibelste Methode, ein System zu modernisieren, ist die geplante Restrukturierung einer Anwendung. Sie beseitigt grundlegende Mängel und verdoppelt die Lebenszeit einer Anwendung. Die strukturierte Vorgehensweise in einzelnen Schritten, wobei jeder einzelne zu einer verbesserten Version eines produktiven Systems führt, kombiniert mit Toolunterstützung, ist zwar aufwändig, aber hinsichtlich ihrer Effizienz kaum zu übertreffen; weil die Modernisierung auf der Sourcen-Ebene durchgeführt und nicht nur eine Anwendung für SOA modernisiert wird, sondern auch signifikante Qualitätsverbesserungen erreicht werden.
  10. Refactoring als Modernisierungstechnik lohnt sich, wenn sich die „Code Smells“ – Change Preventors (Verhinderer von Änderungen) und Couples (Kopplungsprobleme) – vermeiden lassen. Refactoring ist sehr gut von Tools unterstützt und eigentlich integraler Bestandteil der Entwicklung. So kann eine bestehende Anwendung frühzeitig auf eine zukünftige Modernisierung ausgelegt werden.
Daniel Liebhart ist Dozent für Informatik an der Hochschule für Technik in Zürich und Solution Manager der Trivadis AG. Er ist Autor des Buchs „SOA goes real“ und Koautor verschiedener Fachbücher.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.