Management der
Systemarchitektur in
Großprojekten
Leipzig, 19.11.2015,
Tim Lüecke
Public – Company Confidential – Customer...
Wozu Architektur-Management?
Copyright © Capgemini 2015. All Rights Reserved
2Architektur_Management_in_Großprojekten.pptx...
Über mich
Copyright © Capgemini 2015. All Rights Reserved
3Architektur_Management_in_Großprojekten.pptx
Tim Lüecke
Senior ...
Über Capgemini
Umsatz nach Branchen*Umsatz nach Geschäftsbereichen*
Telecom, Media
& Entertainment
Other Managed
Services
...
Copyright © Capgemini 2015. All Rights Reserved
5Architektur_Management_in_Großprojekten.pptx
Agenda
 Großprojekte und ih...
Copyright © Capgemini 2015. All Rights Reserved
6Architektur_Management_in_Großprojekten.pptx
Agenda
 Großprojekte und ih...
Großprojekte zeichnen sich durch eine hohe Komplexität
gepaart mit einer hohen Management-Attention aus
Copyright © Capgem...
Kontext dieses Vortrages sind Individual-Software-
Großprojekte in einem iterativen Wasserfallprozess
Copyright © Capgemin...
Großprojekte bringen einige Herausforderungen für die
zugrundeliegende Architektur mit sich
Druck
Komplexität
Größe
Copyri...
Wegen der langen Laufzeit häufen sich Änderungs-
Anforderungen, die schnell umgesetzt werden müssen
Copyright © Capgemini ...
Die Verteilung des Wissens gestaltet sich über ein
großes Team äußerst schwierig
Copyright © Capgemini 2015. All Rights Re...
Beispiel
 Ohne Akzeptanz
wird eine
Architektur nicht
befolgt
 Fehlende
Motivation
frustriert
Ein großes Team bringt viel...
Qualitätssicherung wird gerade am Anfang häufig
zugunsten von Ergebnissen vernachlässigt
Copyright © Capgemini 2015. All R...
Falsche Architektur Entscheidungen haben enorme
Auswirkungen
Copyright © Capgemini 2015. All Rights Reserved
14Architektur...
Werden diese Herausforderungen nicht gemeistert, führt
dies schnell zu struktureller Erosion
Copyright © Capgemini 2015. A...
Bei struktureller Erosion verschwindet die Architektur in
einem Knäuel von Abhängigkeiten
Copyright © Capgemini 2015. All ...
Symptom
Opacity / Immobility
Viscosity
Strukturelle Erosion zeichnet sich durch bestimmte
Merkmale aus (Robert C. Martin)
...
Copyright © Capgemini 2015. All Rights Reserved
18Architektur_Management_in_Großprojekten.pptx
Agenda
 Großprojekte und i...
Großprojekte erfordern ein kontinuierliches
Architekturmanagement
Copyright © Capgemini 2015. All Rights Reserved
19Archit...
Definition der Architektur muss klar, verständlich
und nachvollziehbar formuliert werden
Copyright © Capgemini 2015. All R...
Ein geordneter Wissenstransfer für die Architektur
ist unabdingbar
Copyright © Capgemini 2015. All Rights Reserved
21Archi...
Architektur-Verletzungen müssen frühzeitig und
kontinuierlich zumindest erfasst werden
Copyright © Capgemini 2015. All Rig...
Sonargraph bietet eine einfache Möglichkeit
Architekturen zu modellieren und zu kontrollieren
Copyright © Capgemini 2015. ...
Feature
Verletzungen
Tasks
Package-Zyklen
Metriken
Sonargraph bietet Features, die für das
Architekturmanagement äußerst n...
Die Behebung der Probleme und die Rückkopplung
der Erkenntnisse müssen aktiv gemanagt werden
Copyright © Capgemini 2015. A...
Copyright © Capgemini 2015. All Rights Reserved
26Architektur_Management_in_Großprojekten.pptx
Agenda
 Großprojekte und i...
Technische Schulden sind in Großprojekten unvermeidlich
und müssen in Rahmen von Refactorings aufgelöst werden
Copyright ©...
cmp jMoney
jMoney
Masterdata Accounting
ImporterReporting
Ein typisches Beispiel ist die Auftrennung einer zu groß
geworde...
Die Refactoring Planung sollte methodisch und tool-
unterstützt erstellt werden, um Fallstricke zu vermeiden
Copyright © C...
Erstellung eines Komponentenmodells
als Leitbild
Copyright © Capgemini 2015. All Rights Reserved
30Architektur_Management_...
Abbildung des Komponentenmodells in
Sonargraph
Copyright © Capgemini 2015. All Rights Reserved
31Architektur_Management_in...
Virtuelle Verteilung der Klassen und
Packages auf die Komponenten
Copyright © Capgemini 2015. All Rights Reserved
32Archit...
Definition der fachlichen Abhängigkeiten
durch hybride Soll-Ist-Analyse
Copyright © Capgemini 2015. All Rights Reserved
33...
Virtuelle Trennung der fachlichen
Komponenten
Copyright © Capgemini 2015. All Rights Reserved
34Architektur_Management_in_...
Abschließend: Schichtenverletzung
ebenfalls betrachten (optional)
Copyright © Capgemini 2015. All Rights Reserved
35Archit...
Die Durchführung des Refactoring sollte in Phasen
erfolgen, um ein paralleles Arbeiten zu ermöglichen
Copyright © Capgemin...
Copyright © Capgemini 2015. All Rights Reserved
37Architektur_Management_in_Großprojekten.pptx
Agenda
 Großprojekte und i...
Zusammenfassung
 Aktives Architekturmanagement ein MUSS zur Wahrung der technischen Qualität
 Prozess sollte frühzeitig ...
Über Capgemini
Mit mehr als 140.000 Mitarbeitern in über 40 Ländern ist
Capgemini einer der weltweit führenden Anbieter vo...
Nächste SlideShare
Wird geladen in …5
×

Management of the system architecture in large-scale projects

1.062 Aufrufe

Veröffentlicht am

Es werden zunächst die Probleme dargestellt, die sich aus den besonderen Anforderungen ergeben, die Großprojekte mit sich bringen und sich erst im Verlauf des Projektes zeigen. Diese Probleme erfordern ein aktives Management der Systemarchitektur. Trotzdem sind historisch anwachsende Strukturen mit Wartungsproblemen teilweise nicht zu vermeiden, welche durch Refactorings aufgelöst und bereinigt werden sollten. Dieser Vortrag stellt eine in der Praxis erprobte Methodik vor, mit der Architekturen gemanagt sowie strukturelle Probleme behoben werden können.

Veröffentlicht in: Technologie
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.062
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
36
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Management of the system architecture in large-scale projects

  1. 1. Management der Systemarchitektur in Großprojekten Leipzig, 19.11.2015, Tim Lüecke Public – Company Confidential – Customer Confidential – Sensitive
  2. 2. Wozu Architektur-Management? Copyright © Capgemini 2015. All Rights Reserved 2Architektur_Management_in_Großprojekten.pptx Quelle: http://geekandpoke.typepad.com/geekandpoke/2010/11/architecture.html Vermeidung von strukturellen Monolithen Auflösung von Architekturfehlern und Fehlentwicklungen
  3. 3. Über mich Copyright © Capgemini 2015. All Rights Reserved 3Architektur_Management_in_Großprojekten.pptx Tim Lüecke Senior Solution Architect Lübecker Straße 128, Hamburg Phone: +49 40 254491 314 E-Mail: tim.lueecke@capgemini.com
  4. 4. Über Capgemini Umsatz nach Branchen*Umsatz nach Geschäftsbereichen* Telecom, Media & Entertainment Other Managed Services Local Professional Services Consulting Services Application Services Energy, Utilities & Chemicals Others Public Sector Manufacturing, Automotive & Life Sciences 14% 4% 7%19% 16% 23% 4% 58% 23% 15% “Cap Gemini S.A.” ist im CAC 40 gelistet; Paris, ISIN code: FR0000125338 Unsere Marke ist Capgemini, an der Pariser Börse sind wir unter “Cap Gemini S.A.” gelistet. Financial Services Copyright © Capgemini 2015. All Rights Reserved 4Architektur_Management_in_Großprojekten.pptx 17% Customer Products, Retail, Distribution & Transportation  Operative Marge : 970 Mio. €  Operativer Gewinn : 853 Mio. €  Jahresgewinn : 580 Mio. €  Netto-Barmittel und bargleiche Mittel : 1.22 Mrd. € Umsatz 2014: 10,57 Mrd. € * Stand: 1. Halbjahr 2015 * Stand: 1. Halbjahr 2015
  5. 5. Copyright © Capgemini 2015. All Rights Reserved 5Architektur_Management_in_Großprojekten.pptx Agenda  Großprojekte und ihre Herausforderungen  Architekturmanagement in Großprojekten  Refactoring in Großprojekten  Zusammenfassung
  6. 6. Copyright © Capgemini 2015. All Rights Reserved 6Architektur_Management_in_Großprojekten.pptx Agenda  Großprojekte und ihre Herausforderungen  Architekturmanagement in Großprojekten  Refactoring in Großprojekten  Zusammenfassung
  7. 7. Großprojekte zeichnen sich durch eine hohe Komplexität gepaart mit einer hohen Management-Attention aus Copyright © Capgemini 2015. All Rights Reserved 7Architektur_Management_in_Großprojekten.pptx Unterstützung der Kernprozesse Hohe KomplexitätWeltweiter Nutzerkreis (intern/extern) Großes Team (> 50) Große Investition Hoher Druck
  8. 8. Kontext dieses Vortrages sind Individual-Software- Großprojekte in einem iterativen Wasserfallprozess Copyright © Capgemini 2015. All Rights Reserved 8Architektur_Management_in_Großprojekten.pptx Klassisches Vorgehensmodell Individualsoftware  Kernprozesse meist schon gegeben (Vorgängersystem evtl. vorhanden)  Ziel der Reise ist bekannt  Grobplanung mit möglichst stabilen Terminplan zur Steuerung der Einführung erforderlich  Diverse Stakeholder ohne klar identifizierbaren Product Owner  Software wird von Grund auf selbst entwickelt  Maßgeschneidert zur bestmöglichen Unterstützung der Kernprozesse  Ermöglicht Differenzierung in den Kernkompetenzen eines Unternehmens  Technische Basis kann potentiell wiederverwendet werden
  9. 9. Großprojekte bringen einige Herausforderungen für die zugrundeliegende Architektur mit sich Druck Komplexität Größe Copyright © Capgemini 2015. All Rights Reserved 9Architektur_Management_in_Großprojekten.pptx Diverse Mindsets CRs Falsche Entscheidungen Verteiltes Wissen Fehlende QA Prozesse
  10. 10. Wegen der langen Laufzeit häufen sich Änderungs- Anforderungen, die schnell umgesetzt werden müssen Copyright © Capgemini 2015. All Rights Reserved 10Architektur_Management_in_Großprojekten.pptx  Weltweite Anforderungen können nicht alle im Voraus bedacht werden  Anforderung ändern sich nach dem ersten Release (oder auch während)  Änderungen sollen asap eingearbeitet werden (“Emergency CRs”)  Führt oft zu „Hacks“ (durch ungenügendes Wissen, Druck, ...) Time-to-market  Eine Software, die verwendet wird, wird auch verändert  Wenn eine Software geändert wird, erhöht sich die Komplexität, sofern nicht aktiv dagegen gesteuert wird Gesetz der Software Entropie (Lehman)
  11. 11. Die Verteilung des Wissens gestaltet sich über ein großes Team äußerst schwierig Copyright © Capgemini 2015. All Rights Reserved 11Architektur_Management_in_Großprojekten.pptx Ursache Beschränkung auf Dokumentation Team-übergreifende Kommunikation Übereiltes Ramp-up  Erstellung der technischen Basis parallel zu der Entwicklung  „Moving Target“  Zu schneller Team-Aufbau  Mitteilung von Regeln über Mails / Handbüchern / Wiki ungenügend  Fehlende Begründung  Entwickler haben andere Sorgen („TAGRI“)  z.B. bei Trennung der Teams nach Disziplinen  Knowledge Transfer muss unterschiedliche Perspektiven genügen  Architektur Wissen unterschiedlich verteilt  Kennt man eine Regel nicht, wird sie auch nicht befolgt  „Elfenbein-Turm- Architekturen“
  12. 12. Beispiel  Ohne Akzeptanz wird eine Architektur nicht befolgt  Fehlende Motivation frustriert Ein großes Team bringt viele unterschiedliche Meinungen mit sich, die oft im Konflikt stehen Trennung von Zuständigkeiten Schichten-Architektur Minimierung von Abhängigkeiten Copyright © Capgemini 2015. All Rights Reserved 12Architektur_Management_in_Großprojekten.pptx  “Wenn ich es doch aber brauche, muss ich es halt kennen!”  “Was ist falsch an zyklischen Abhängigkeiten? Das ist fachlich halt so…”  “Es ist doch viel einfacher alles an einer Stelle zu implementieren!”  “Man versteht das doch nicht mehr, wenn es so verteilt ist”  Schichten können in einfachen Fällen künstlich wirken  “Da wird doch kaum etwas gemacht, wieso muss das getrennt werden?!”  “Das ist nicht effizient genug!”
  13. 13. Qualitätssicherung wird gerade am Anfang häufig zugunsten von Ergebnissen vernachlässigt Copyright © Capgemini 2015. All Rights Reserved 13Architektur_Management_in_Großprojekten.pptx Ursache  “Lasst uns erst mal anfangen, wir prüfen das dann alles später”  Automatischer Tool-Support fehlt, oder muss erst noch aufgesetzt werden Fokus auf Implementierung  Qualitätssicherung wird oft als erstes gestrichen, wenn die Zeit knapp wird  Fehlende Management Awareness Zeitdruck  Regeln werden verletzt  Regelverletzungen breiten sich schneller aus als man denkt “You can’t manage what you can’t control, and you can’t control what you don’t measure” (Tom DeMarco)
  14. 14. Falsche Architektur Entscheidungen haben enorme Auswirkungen Copyright © Capgemini 2015. All Rights Reserved 14Architektur_Management_in_Großprojekten.pptx Beispiel  Schichten ohne klare, disjunkte Zuständigkeiten  Entwickler wissen nicht wo genau sie was implementieren müssen  Führt zu den unterschiedlichsten Lösungsansätzen Details Schichten  Komponentenschnitt mit zu vielen Zuständigkeiten  Falsche Kopplung zwischen den Komponenten  Falscher Schnittstellen-Schnitt mit Hinblick auf Performance Komponenten
  15. 15. Werden diese Herausforderungen nicht gemeistert, führt dies schnell zu struktureller Erosion Copyright © Capgemini 2015. All Rights Reserved 15Architektur_Management_in_Großprojekten.pptx Strukturelle Erosion [...]
  16. 16. Bei struktureller Erosion verschwindet die Architektur in einem Knäuel von Abhängigkeiten Copyright © Capgemini 2015. All Rights Reserved 16Architektur_Management_in_Großprojekten.pptx Quelle: http://www.hello2morrow.com
  17. 17. Symptom Opacity / Immobility Viscosity Strukturelle Erosion zeichnet sich durch bestimmte Merkmale aus (Robert C. Martin) Rigidity / Fragility  Anpassungen an einer Stelle wirken sich an anderen Stellen aus  Regelmäßig fehlschlagende Builds auf Modul-Ebene  Paralleles Arbeiten in großen Projekten immens erschwert  Source Code ist schwer zu verstehen: wo findet sich was?  Fehlende Trennung von Zuständigkeiten  Wiederverwendbare Komponente sind schwer zu identifizieren und einzuführen  Es ist leichter etwas falsch zu machen als richtig  Benutzung von Code, der gegen Regeln verstößt, führt zu neuen Verstößen Copyright © Capgemini 2015. All Rights Reserved 17Architektur_Management_in_Großprojekten.pptx Erläuterung “The software starts to rot like a bad piece of meat” s. Agile Software Development, Robert C. Martin, Prentice Hall 2003
  18. 18. Copyright © Capgemini 2015. All Rights Reserved 18Architektur_Management_in_Großprojekten.pptx Agenda  Großprojekte und ihre Herausforderungen  Architekturmanagement in Großprojekten  Refactoring in Großprojekten  Zusammenfassung
  19. 19. Großprojekte erfordern ein kontinuierliches Architekturmanagement Copyright © Capgemini 2015. All Rights Reserved 19Architektur_Management_in_Großprojekten.pptx Wissens- transfer Problem- behebung Definition der Architektur Monitoring
  20. 20. Definition der Architektur muss klar, verständlich und nachvollziehbar formuliert werden Copyright © Capgemini 2015. All Rights Reserved 20Architektur_Management_in_Großprojekten.pptx Aspekt Struktur Inhalt  Angabe klar verständlicher Definitionen der Architekturelemente  Definition, Hervorhebung und Motivation (!) von Regeln  Entwurfsentscheidungen explizit mit Alternativen festhalten  Namenskonvention zur Klassifizierung von Artefakten  Dokumentation über verschiedene Architektur-Perspektiven  Technische Architektur als Word Dokument  Fachliche Architektur als UML Modell Zu beachten Nur ein Startpunkt  Architekturen sind nicht in Stein gemeißelt  Was nicht funktioniert, muss geändert werden  Änderungen sollten mit Bedacht erfolgen und mit dem Management abgestimmt werden
  21. 21. Ein geordneter Wissenstransfer für die Architektur ist unabdingbar Copyright © Capgemini 2015. All Rights Reserved 21Architektur_Management_in_Großprojekten.pptx Aspekt Architektur-Schulungen Veröffentlichung der Architektur  Einfacher Zugang für jeden Entwickler  Verknüpfung zu anderen Dokumentationen (z.B. Entwicklerhandbuch)  Bereitstellung eines expliziten Regelkatalogs mit Beispielen  Veröffentlichung alleine nicht ausreichend  Schulungen zur Vermittlung des Inhalts vorbereiten  Motivation für die Architektur (d.h. die Regeln) hervorheben  Raum für Diskussionen lassen – aber gut vorbereitet sein ;-) Zu beachten
  22. 22. Architektur-Verletzungen müssen frühzeitig und kontinuierlich zumindest erfasst werden Copyright © Capgemini 2015. All Rights Reserved 22Architektur_Management_in_Großprojekten.pptx Aspekt Tool-Unterstützung Überprüfung der Regeln  Auch der beste Wissenstransfer verhindert nicht alle Regelverletzungen  Regeln können oft nicht durch die Sprache forciert werden  Bei komplexen Implementierungen oftmals vernachlässigt  Erfassung und Dokumentation von Regel-Verletzungen  Wenn möglich sollte Regelprüfung automatisch erfolgen, z.B. über  Sonargraph  Sonarqube  Sollte Teil der Continuous Integration sein Zu beachten Code Reviews  Falls kein Tool vorhanden, sollte dies Teil von Code Reviews sein (z.B. über Checkliste)  Durchführung von einem erfahrenen Entwickler Frühzeitig und kontinuierlich  Verletzungen verbreiten sich oft rasant  Je später erfasst, desto schneller steigen die technischen Schulden
  23. 23. Sonargraph bietet eine einfache Möglichkeit Architekturen zu modellieren und zu kontrollieren Copyright © Capgemini 2015. All Rights Reserved 23Architektur_Management_in_Großprojekten.pptx Architektur Modell Quellcode  Unterstützung von zwei Dimensionen: • Technische Architektur (Schichten) • Anwendungs-Architektur (Slice = Komponente)  Explizite und Implizite Abhängigkeiten  Flexiblere Modellierung über DSL in neuester Version  Zuweisung von Architekturelementen über Namenskonvention (s. Architektur- Definition)  Best Practice: [company].[system].[component].[layer] Accounting Business Layers PresentationPersistence Masterdata Components Booking Products
  24. 24. Feature Verletzungen Tasks Package-Zyklen Metriken Sonargraph bietet Features, die für das Architekturmanagement äußerst nützlich sind Copyright © Capgemini 2015. All Rights Reserved 24Architektur_Management_in_Großprojekten.pptx Details  Abgleich der Quellcode-Abhängigkeiten mit Architekturmodell  Identifikation und Auflistung der Abhängigkeitsverletzungen  Tasks für virtuelle Refactorings (Verschiebung, Umbenennung, etc.)  Tasks zur Auflösung von Abhängigkeiten  Erlaubt die virtuelle Behebung der oben aufgeführten Verletzungen  Identifikation von Zyklen zwischen Packages  Vorschläge zum Auflösen von Zyklen  Code Duplizierung  ACD / NCCD  Komplexitäts-Metriken
  25. 25. Die Behebung der Probleme und die Rückkopplung der Erkenntnisse müssen aktiv gemanagt werden Copyright © Capgemini 2015. All Rights Reserved 25Architektur_Management_in_Großprojekten.pptx Aspekt Feedback Schleife Problembehebung  Priorität sollte mit Bedacht und nach eingehender Analyse erfolgen  Verletzungen breiten sich schnell aus (Viskosität)  Finden der Balance zwischen Weiterentwicklung und Behebung der strukturellen Schulden  Konkrete Verletzungen als Beispiel für Wissenstransfers heranziehen  Prüfen der Architektur-Definition mit evtl. Anpassung falls erforderlich Zu beachten
  26. 26. Copyright © Capgemini 2015. All Rights Reserved 26Architektur_Management_in_Großprojekten.pptx Agenda  Großprojekte und ihre Herausforderungen  Architekturmanagement in Großprojekten  Refactoring in Großprojekten  Zusammenfassung
  27. 27. Technische Schulden sind in Großprojekten unvermeidlich und müssen in Rahmen von Refactorings aufgelöst werden Copyright © Capgemini 2015. All Rights Reserved 27Architektur_Management_in_Großprojekten.pptx Metapher Abbau von Schulden  Formuliert von Ward Cunningham  Entstehung von Schulden: • Unvollständiges Verständnis der Systemanforderungen führt zu „leicht falschem“ Code • Fachliche Architektur passt z.B. nicht zu den Anforderungen  Auswirkung: • wie bei finanziellen Schulden müssen Zinsen gezahlt werden • Neue Anforderungen lassen sich schwerer umsetzen  Inzwischen wird auch die Code-Qualität als Teil der technischen Schulden gesehen (anders als von Cunningham gedacht)  Refactorings zur Korrektur der Architektur  Kann fachliche aber auch technische Architektur betreffen  Sinnvolle Bewertung notwendig: • dort ansetzen, wo es für die Zukunft hilfreich ist • Planung inkl. Schätzung als Grundlage • Zielbild zur Orientierung Neue Anforderungen Schuldenabbau
  28. 28. cmp jMoney jMoney Masterdata Accounting ImporterReporting Ein typisches Beispiel ist die Auftrennung einer zu groß gewordenen Komponente Beispiel Copyright © Capgemini 2015. All Rights Reserved 28Architektur_Management_in_Großprojekten.pptx  Problem: Größe einer Kernkomponente • Größe wurde vom Design nicht antizipiert • Neue Zuständigkeiten im Laufe der Zeit hinzugefügt • Abhängigkeiten in der Komponente nicht mehr überschaubar  Ergebnis: parallele Weiterentwicklung der Komponente in mehreren Teams nicht möglich  Lösungsansatz: • Auftrennung in kleinere Komponenten mit klar definierten Zuständigkeiten • Behebung von anderen Architekturverletzungen „along-the-way“
  29. 29. Die Refactoring Planung sollte methodisch und tool- unterstützt erstellt werden, um Fallstricke zu vermeiden Copyright © Capgemini 2015. All Rights Reserved 29Architektur_Management_in_Großprojekten.pptx Ziel Definition Phase: Cont.:  Komponenten Modell  Rein fachlich orientiert  Ohne Abhängigkeiten Sonargraph Modell  Quell- Komponente beibehalten  Neue Komponenten definieren  Ohne Abhängigkeiten Virtuelle Verteilung  Packages + Klassen umbenennen  Dadurch: Zuweisung zu neuen Komponenten  Tasks immer mit einem Ticket verknüpfen Definition Abhängig- keiten  Können empirisch ermittelt werden  Optimierung anhand von Verletzungen  Anschließend fachliche Validierung Kompo- nenten Trennung  Schichten- verletzungen ignorieren  Refactoring Tasks zu über- geordneten Aufgaben bündeln (JIRA)  Controlling über Sonargraph Schichten Trennung  Aufgaben bündeln pro Typ und Komponente  Controlling über Sonargraph
  30. 30. Erstellung eines Komponentenmodells als Leitbild Copyright © Capgemini 2015. All Rights Reserved 30Architektur_Management_in_Großprojekten.pptx  Definition der Komponenten lediglich über Entitäten und kurze Beschreibung  Keine vorgegebenen Abhängigkeiten cmp jMoney - Target Accounting ImporterMasterdata Reporting
  31. 31. Abbildung des Komponentenmodells in Sonargraph Copyright © Capgemini 2015. All Rights Reserved 31Architektur_Management_in_Großprojekten.pptx  Einschränkung auf Code der Komponente reicht aus  Schichten global definieren für den Fokus auf Komponenten- Abhängigkeiten  Fachliche Komponenten erstellen und Package-Namen vergeben  Package-Namen fixieren (!)
  32. 32. Virtuelle Verteilung der Klassen und Packages auf die Komponenten Copyright © Capgemini 2015. All Rights Reserved 32Architektur_Management_in_Großprojekten.pptx  Erstellung von Umbenennung- oder Verschiebungs-Tasks  Können zu Arbeitspaketen pro Komponente gebündelt werden  Verknüpfung zu Ticketsystem ratsam
  33. 33. Definition der fachlichen Abhängigkeiten durch hybride Soll-Ist-Analyse Copyright © Capgemini 2015. All Rights Reserved 33Architektur_Management_in_Großprojekten.pptx  Viele Abhängigkeiten schon implizit bekannt  Andere können empirisch ermittelt werden:  Abhängigkeiten definieren  Anzahl der Architektur- Verletzungen kontrollieren  Iterative Optimierung  Fachliche Validierung
  34. 34. Virtuelle Trennung der fachlichen Komponenten Copyright © Capgemini 2015. All Rights Reserved 34Architektur_Management_in_Großprojekten.pptx  Verletzungen intensiv analysieren  Bündeln zu Aufgabenpaketen mit gleichem Lösungsmodell  Beispiel: Listener Pattern für Dependency Inversion  Schichtenverletzungen zunächst ignorieren (alle Schichten als „Unrestricted“ definieren)
  35. 35. Abschließend: Schichtenverletzung ebenfalls betrachten (optional) Copyright © Capgemini 2015. All Rights Reserved 35Architektur_Management_in_Großprojekten.pptx  Weitere Architekturverletzungen gleich ins Refactoring mit einbeziehen  Test-Synergien nutzen  Bleiben sonst lange bestehen  Bündeln nach Typ und Komponente  Außerdem noch beachten: Metriken, Package-Zyklen, Duplikate
  36. 36. Die Durchführung des Refactoring sollte in Phasen erfolgen, um ein paralleles Arbeiten zu ermöglichen Copyright © Capgemini 2015. All Rights Reserved 36Architektur_Management_in_Großprojekten.pptx Package Refactoring Phase: Cont.:  Ausführung der Rename und Move Tasks  Build Unit bleibt unberührt  Ermöglicht paralleles Refactoring und erhöht Stabilität Komponenten Trennung  Ausführung der Tasks zum Auflösen der unerlaubten Abhängigkeiten  Ein Bearbeiter pro Komponente sinnvoll Build Unit Refactoring  Build Unit auftrennen  Ermöglicht die Einführung harter Abhängigkeiten, die nicht mehr verletzt werden können Aufräumen  Ausführung der restlichen Refactoring Tasks
  37. 37. Copyright © Capgemini 2015. All Rights Reserved 37Architektur_Management_in_Großprojekten.pptx Agenda  Großprojekte und ihre Herausforderungen  Architekturmanagement in Großprojekten  Refactoring in Großprojekten  Zusammenfassung
  38. 38. Zusammenfassung  Aktives Architekturmanagement ein MUSS zur Wahrung der technischen Qualität  Prozess sollte frühzeitig (am besten am Anfang) aufgesetzt werden  Transparenz über den aktuellen Stand schaffen, um Prioritäten klären zu können  Toolunterstützung wie Sonargraph (wenn möglich) nutzen  Bei Erosion: toolgestütztes Refactoring durch Sonargraph mit methodischer Durchführung Copyright © Capgemini 2015. All Rights Reserved 38Architektur_Management_in_Großprojekten.pptx
  39. 39. Über Capgemini Mit mehr als 140.000 Mitarbeitern in über 40 Ländern ist Capgemini einer der weltweit führenden Anbieter von Management- und IT-Beratung, Technologie-Services sowie Outsourcing-Dienstleistungen. Im Jahr 2013 betrug der Umsatz der Capgemini-Gruppe 10,1 Milliarden Euro. Gemeinsam mit seinen Kunden erstellt Capgemini Geschäfts- wie auch Technologielösungen, die passgenau auf die individuellen Anforderungen zugeschnitten sind. Auf der Grundlage seines weltweiten Liefermodells Rightshore® zeichnet sich Capgemini als multinationale Organisation durch seine besondere Art der Zusammenarbeit aus – die Collaborative Business ExperienceTM. Rightshore® ist eine eingetragene Marke von Capgemini Die in der Präsentation enthaltenen Informationen sind Eigentum. Copyright © 2015 Capgemini. Alle Rechte vorbehalten. www.de.capgemini.com

×