Migrationsstrategien
Als PPTX, PDF herunterladen0 gefällt mir226 aufrufe
Das Dokument behandelt Strategien zur Migration von Softwaresystemen, einschließlich der Herausforderungen und Ansätze wie 'Big Bang' und 'Change by Extraction'. Es hebt die Bedeutung von Analyse, Planung und Dokumentation während des Entwicklungs- und Migrationprozesses hervor. Zudem werden verschiedene Methoden zur Strukturierung und Anpassung von Softwarearchitekturen diskutiert, um den Geschäftswert zu maximieren.
Migrationsstrategien
- 2. Der Sprecher Hendrik Lösch Senior Consultant & Coach [email protected] @HerrLoesch Hendrik-Loesch.de
- 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
- 4. Entwicklung Weiter- entwicklung Weiter- entwicklung Weiter- entwicklung Stabilisierung Optimierung Sanierung Stabilisierung Stabilisierung Optimierung t in Jahren Basierend auf Tom Gilb, Evolutionary Delivery vs Waterfall Model, ACM Software Engineering Notes, Juli 1985
- 5. Initial Development Phase Out Close DownEvolution changes patches Servicing Quelle: Software Evolution, Tom Mens, Serge Demeyer
- 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
- 10. Softwaresystem
- 11. Die Einen sehen was und sagen nix. Die Anderen sehen was und machen nix. Die Nächsten machen nix und sehen deshalb nix. Die Letzten explodieren.
- 12. Fehlerkosten Prozessfortschritt Automatisierte Tests Manuelle Tests Abnahme durch Fachbereich Produktiveinsatz Fachbereich Auswirkungen auf Endkunden Entwicklungsintern Extern
- 15. Theorie BIG BANG Alt Neu Kick-Off Neues Produkt Mögliche Ablösung altes Produkt Funktionsumfang t
- 16. Praxis BIG BANG Alt Neu Kick-Off Neues Produkt Mögliche Ablösung altes Produkt Funktionsumfang t
- 17. BIG BANG 17
- 22. CONTEXT MAP Sales S Invoiceing G C – Core Domain S – Support Domain G – Generic Domain Consulting C ACL
- 23. G SG S G G S G C S C G C – Core Domain S – Support Domain G – Generic Domain CONTEXT MAP
- 24. Sales Module UI Logic Data Interfaces Invoicing ModuleUI LogicData Interfaces Rahmen- applikation Invoicing benötigt Daten von Sales Initialisiert Invoicing Initialisiert Sales Invoicing Sales CONTEXT MAP
- 27. CHANGE BY EXTRACTION Rechnungslegung Auftragseingang Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung
- 28. Applikationsinfrastruktur CHANGE BY EXTRACTION Zeiterfassung Projekt- verwaltung Auftragseingang 3rd Party Anbindung Rechnungslegung
- 29. CHANGE BY EXTRACTION Rechnungslegung Auftragseingang Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung ConsultR Light
- 31. Vorgehen CHANGE BY SPLITT Rechnungslegung Auftragseingang Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung
- 32. Vorgehen CHANGE BY SPLITT Rechnungslegung Auftragseingang Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung Rechnungslegung Auftragseingang Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung ConsultR Controlling ConsultR Light
- 33. Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung 3rd Party Anbind ung Rechnungslegung Auftragseingang Applikationsinfrastruktur 3rd Party Anbind ung Vorgehen CHANGE BY SPLITT ConsultR Controlling ConsultR Light
- 34. Projekt- verwaltungApplikationsinfrastruktur Zeiterfassung Rechnungslegung Auftragseingang Applikationsinfrastruktur Vorgehen – realistischer Zustand CHANGE BY SPLITT
- 35. Projekt- verwaltung Zeiterfassung 3rd Party Anbind ung Rechnungslegung Auftragseingang Applikationsinfrastruktur 3rd Party Anbind ung CHANGE BY SPLITT + EXTRACT ConsultR Light ConsultR Controlling
- 37. ISOLATE CORE DOMAINS Applikationsinfrastruktur Zeiterfassung Projekt- verwaltung Auftragseingang 3rd Party Anbindung Rechnungslegung
- 38. ISOLATE CORE DOMAINS Applikationsinfrastruktur Zeiterfassung Projekt- verwaltung Auftragseingang 3rd Party Anbindung Rechnungslegung ConsultR
- 42. sogehtsoftware.de CHICKEN LITTLE & TRICKLE MIGRATION
- 43. CHICKEN LITTLE
- 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
- 45. CONTEXT MAP Sales S Invoiceing G C – Core Domain S – Support Domain G – Generic Domain Consulting C ACL
- 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
- 52. 1. Analyse, Analyse, Analyse 2. Planung, Planung, Planung 3. Dokumentation, Dokumentation, Dokumentation 4. Migration ZUSAMMENFASSUNG
- 53. Der Sprecher Hendrik Lösch Senior Consultant & Coach [email protected] @HerrLoesch Hendrik-Loesch.de
Hinweis der Redaktion
- #4: Man beachte auch, dass die Pfeile immer kürzer werden.
- #10: Verringerung des Ressourcenbedarfs. Optimierung des Quellcodes durch vereinheitlichte Konzepte. Ablösen alter Frameworks durch neue.
- #11: 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.
- #12: 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.
- #16: 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.
- #17: 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.
- #18: 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.
- #19: Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
- #25: 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.
- #26: Grüne Pfeile -> bewusste Abhängigkeitsumkehr. Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
- #27: 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.
- #28: Grüne Pfeile -> bewusste Abhängigkeitsumkehr. Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
- #29: 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.
- #37: Anwendung wird geklont. Ab der Stelle wo sie geklont wurde, laufen sie bewusst auseinander und kümmern sich nicht mehr umeinander.
- #38: Der Code wird aufgespalten Man entfernt die anderen Bestandteile komplett.
- #39: Es wird nur das entfernt was definitiv nicht gebraucht wird. Alles andere bleibt drin, selbst wenn es ggf. nicht benötigt wird.
- #40: Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
- #42: Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
- #43: Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
- #46: Das System wird in viele, völlig eigenständige Systeme (Self-Contained Services zerlegt).