Contenu connexe Similaire à Management of the system architecture in large-scale projects (20) Management of the system architecture in large-scale projects2. 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. Ü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. Ü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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Ü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