Nichts ist so beständig wie die Veränderung, so auch in der Softwareentwicklung. War das System an dem man arbeitet vor Jahren noch jung, frisch und voller Neuerungen, ist ihm der Alterungsprozess nicht gut bekommen. Daher soll es nun abgelöst oder zumindest in Teilen ersetzt werden. Doch wie geht man vor? Worauf soll man achten?
In diesem Vortrag behandeln wir die unterschiedlichen Strategien anhand eines fiktiven Beispiels und klären auf Basis welcher Voraussetzungen, welches Migrationsstrategien gewählt werden sollten. Zeitgleich werden aber auch die damit verbundenen Gefahren erläutert und wie man sie möglicherweise kompensieren kann.
3. ANPASSBARKEIT VS. BUSSINESS VALUE
Innere Qualität /
Anpassbarkeit
Business Value
Start der
Entwicklung
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Entfernen fehlerhafter
Bestandteile
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz der
Pfadfinderregel
7. › Restrukturierung
› Anpassung der Struktur ohne Verhaltensänderung
› Migration
› Übertragung vorhandener Funktionalität auf neue technische Basis
› Sanierung
› Versetzen des Systems in seinen ursprünglich geplanten Zustand
DEFINITIONEN
44. Analyse des
Bestandssystems
Zerlegung der
Systemstruktur
Design der
Zielschnittstellen
Design des
Zielsystems
Design der
Zieldatenbank
Aufbau
notwendiger
Gateways
Migration der
Legacy
Datenbanken
Migration der
Legacy
Applikationen
Migration der
Legacy
Schnittstellen
Abschalten des
Altsystems
CHICKEN LITTLE
46. Schritt 1 – Abhängigkeiten analysieren
CHICKEN LITTE
Invoice
Service
Von Nach Wie
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById
47. Schritt 2 – Schnittstelle extrahieren
CHICKEN LITTE
Invoice
Service
Von Nach Wie
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById
IInvoice
Service
48. Schritt 3 – Aufrufer auf Schnittstellen anpassen
CHICKEN LITTE
Invoice
Service
Von Nach Wie Ersetzen durch
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf ShowInvoiceSheet
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf ShowInvoiceSheet
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById entfernen
IInvoice
Service
49. Schritt 3 – Schnittstelle ändern
CHICKEN LITTE
Invoice
Service
IInvoice
Service
Von Nach
SalesAgreementManager ShowInvoiceSheet
SalesDetailPresenter ShowInvoiceSheet
50. Schritt 4 – Migration der Funktionalität
CHICKEN LITTE
Invoice
Service 2.0
IInvoice
Service
Von Nach
SalesAgreementManager ShowInvoiceSheet
SalesDetailPresenter ShowInvoiceSheet
Man beachte auch, dass die Pfeile immer kürzer werden.
Verringerung des Ressourcenbedarfs.
Optimierung des Quellcodes durch vereinheitlichte Konzepte.
Ablösen alter Frameworks durch neue.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Skype kann nicht mehr verwendet werden wenn auf Teams umgestellt wird.
Den Nutzern fallen reihenweise fehlende oder geänderte Features auf:
Verwendung mehrerer Chatfenster zeitgleich? -> Geht nicht mehr
Auswahl des aktuellen Sprechers? -> Teams teilt die Darstellung auf, man kann aber nicht konfigurieren wie.
Zeitgleiche Pflege mehrerer Systeme.
Investitionen in das Altsystem gehen nach Migration komplett verloren.
Geringe Akzeptanz des neuen Systems wenn Funktionalität eingeschränkt gegenüber Altsystem.
Neuer Code bedeutet auch neue Fehler.
Skype kann nicht mehr verwendet werden wenn auf Teams umgestellt wird.
Den Nutzern fallen reihenweise fehlende oder geänderte Features auf:
Verwendung mehrerer Chatfenster zeitgleich? -> Geht nicht mehr
Auswahl des aktuellen Sprechers? -> Teams teilt die Darstellung auf, man kann aber nur eingeschränkt konfigurieren wie.
Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Klare fachliche Trennung einzelner Module.
Fachliche wie technische Bestandteile können leicht ausgetauscht oder verändert werden.
Gerichtete und damit nachvollziehbare Abhängigkeiten.
Änderungen wirken sich nur auf einen definierten Teilbereich aus und sind frei von Nebeneffekten.
Kommunikation nur über abstrakte Schnittstellen.
Es ist leicht automatisierte Tests zu verfassen und Bestandteile unabhängig voneinander zu betrachten.
Zusammensetzung der Anwendung durch entsprechende Modulaggregatoren und eine Rahmenapplikation.
Definierte Schlüsselpunkte weisen hohe Komplexität auf, alle anderen eher geringe.
Einheitliches Vorgehen bei der Umsetzung neuer Funktionalität.
Geringer Einarbeitungsaufwand.
Anwendung wird geklont. Ab der Stelle wo sie geklont wurde, laufen sie bewusst auseinander und kümmern sich nicht mehr umeinander.
Der Code wird aufgespalten Man entfernt die anderen Bestandteile komplett.
Es wird nur das entfernt was definitiv nicht gebraucht wird. Alles andere bleibt drin, selbst wenn es ggf. nicht benötigt wird.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Das System wird in viele, völlig eigenständige Systeme (Self-Contained Services zerlegt).