Big Design up front passt nicht zur agilen Vorgehensweise, aber wieviel Architektur-Arbeit ist im Voraus wirklich erforderlich? Wie gehe ich dabei vor und welche Ergebnisse sollen dabei entstehen? Egal ob Neuentwicklung oder größere Erweiterung, eine Phase 0 stellt den geeigneten Zeitraum für den Beginn der Architekturarbeit dar. Die ersten Ideen fließen in die Architektur-Vision ein und dienen als Startpunkt für die Entwicklung. Entwicklungsbegleitend wird die Architektur im Team weitergepflegt und die Ergebnisse fließen in die Architekturdokumentation ein. Bringen Sie Stift und Papier mit. Dann werden Sie im Rahmen einer Speed-Kata ihre eigene Erfahrung mit der Erstellung einer Architektur-Vision sammeln können.

1. Gerade genug Architektur vorneweg
Zur eigenen Architektur-Vision in 12 Minuten

2. Roland Mast
Sybit GmbH
Software-Architekt
Scrum Master
roland.mast@sybit.de

3. Roland Mast
Sybit GmbH
Software-Architekt
roland.mast@sybit.de

4. Was spricht gegen Big Design Up Front?

5. Was spricht gegen No Design Up Front?

6. Wieviel Architekturarbeit
muss vor dem Einstieg
in die Realisierung
geleistet werden?
Gerade genug!

7. • Kennenlernen
• Erfahren
• Trainieren
Architektur-Vision

8. Anforderungen
Architektur-
Vision +
Lösungsidee
Inkrementelle
Entwicklung
der Architektur
Aus-
lieferung
Architektur-Vision
Start ImplementierungPhase 0
Zeit

9. Architektur-
Vision
kurz
akzeptiertverständlich

10. Systemidee erarbeiten
• Was ist die Kernaufgabe des Systems?
• Wie und von wem wird das System genutzt?
• Über welche Schnittstellen zur Außenwelt
verfügt das System?
• In welchen Kontext steht das zu entwerfende System?
„Das bestehende Content Management System
soll abgelöst werden. Die bestehenden
Funktionalitäten sollen soweit erforderlich
übernommen und eine solide technische Basis
für zukünftige Anforderungen geschaffen
werden.“

11. Systemidee erarbeiten
• Was ist die Kernaufgabe des Systems?
• Wie und von wem wird das System genutzt?
• Über welche Schnittstellen zur Außenwelt
verfügt das System?
• In welchen Kontext steht das zu entwerfende System?
• Nutzungskategorien:
WebApp, Desktop, Batch, Embedded …
• Benutzerschnittstellen:
GUI, Konsole, Hardware …
• Anwender:
geschult/ungeschult, Administratoren,
Betreiber …

12. Systemidee erarbeiten
• Was ist die Kernaufgabe des Systems?
• Wie und von wem wird das System genutzt?
• Über welche Schnittstellen zur Außenwelt
verfügt das System?
• In welchen Kontext steht das zu entwerfende System?
• Schnittstellen zu anderen Systemen, die
bedient/benutzt werden
• Funktionale oder Datenschnittstellen
• Synchron/Asynchron
• Stabilität, Performance, Änderbarkeit

13. Systemidee erarbeiten
• Was ist die Kernaufgabe des Systems?
• Wie und von wem wird das System genutzt?
• Über welche Schnittstellen zur Außenwelt
verfügt das System?
• In welchen Kontext
steht das zu
entwerfende System?
cmp Context
Columbus
responsibilities
1. security
2. service reliabilty > 99%
3. peak load
4. continuous deployment
RatingApprov al
«user»
WebUser
«user»
TravelEditor
«user»
DevOp Legend
blau user
orange external systems
grau system in context
Trav elBatchTrav elAgencies
«flow» «flow» «flow»
«use»«use» «use»
«use»

14. „Das bestehende Content Management System
soll abgelöst werden. Die bestehenden
Funktionalitäten sollen soweit erforderlich
übernommen und eine solide technische Basis
für zukünftige Anforderungen geschaffen
werden.“
Benutzergruppen:
• WebUser (Web-GUI)
• RedakteurIn (RichClient)
• Administrator/Support (RichClient)
• Betrieb (Konsole, Web-GUI)

15. • Schnittstellen zu anderen
Systemen, die
bedient/benutzt werden

16. Technische Kontext-Abgrenzung
19

17. Einflussfaktoren beachten
Architektur
Funktionale
Anforderungen
Qualitative
Anforderungen
Organisatorische
Einflüsse
Technische Einflüsse

18. Einflussfaktoren beachten
Architektur
Funktionale
Anforderungen
Qualitative
Anforderungen
Organisatorische
Einflüsse
Technische Einflüsse
• Die wichtigsten Anforderungen
/ Stories aus dem Backlog
• „Redaktionell aufbereitete
Inhalte zu Audios und Videos
sind zentraler Bestandteil der
Plattform. Sie sollen von der
Zulieferung durch Drittsysteme
nicht beeinträchtigt werden.“

19. Video-Seite

20. Einflussfaktoren beachten
Architektur
Funktionale
Anforderungen
Qualitative
Anforderungen
Organisatorische
Einflüsse
Technische Einflüsse
• Performanz
• Ausfallsicherheit
• Skalierbarkeit
• Erweiterbarkeit
• Fehlertoleranz
• Bedienbarkeit
• Stabilität
• Austauschbarkeit
• …..

21. Einflussfaktoren beachten
Architektur
Funktionale
Anforderungen
Qualitative
Anforderungen
Organisatorische
Einflüsse
Technische Einflüsse
• Struktur der
Organisation
• Bestehende Partnerschaften
• Ressourcen
• Budget
• Festpreis
• Flexibilität des Zeitplans
• Qualitätsstandards
• Vorgehensstandards
• Juristische Faktoren

22. Einflussfaktoren beachten
Architektur
Funktionale
Anforderungen
Qualitative
Anforderungen
Organisatorische
Einflüsse
Technische Einflüsse
• Hardware Infrastruktur
• Software Infrastrukur
• Referenzarchitekturen
• Betriebssysteme
• Datenbanken
• Grafische Oberfläche
• Styleguides
• Bibliotheken, Frameworks
• Programmiervorgaben

23. Einflussfaktoren …
… sind verhandelbar
und können sich ändern

24. Lösungsstrategien entwicklen

25. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen

26. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen
Verwendung eines
Application Server Clusters
(hohe Ausfallsicherheit)

27. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen
Circuit Breaker
(Entkopplung und
Überwachung von
Abhängigkeiten)

28. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen
Bevorzuge Standards vor
proprietären Lösungen
(niedrige Wartungsaufwände)

29. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen
Caching-Konzept
(Effizienz, kurze Antwortzeiten)
Caching KonzeptCaching KonzeptCaching Konzept

30. Lösungsstrategien - Kategorien
• Entscheidungen
• Architektur-Muster
• Architektur-Prinzipien
• Konzepte
• Vorgehen
Continuous Deployment
(Installierbarkeit, Stabilität,
Wartbarkeit)
Test Stage Production Stage
Akzeptanz-
Tests
Performanz
-Tests
Unit
Tests
Code
Analyse
Arte-
fakte
Go Live
Commit Stage

31. Beteiligte an der Architektur-Vision
• Software-Architekt und Entwickler
• Product-Owner, Projektleiter
• Betrieb
• QA
• UX
• Mechanik, Elektronik
• Endanwender
• …

32. Los geht‘s !

33. 4 Minuten für Architekturentwurf
eines dir bekannten Software-Systems
• Systemidee, Nutzung und Systemkontext
• Die wichtigsten Qualitätsziele und/oder Randbedingungen
• Dokumentiere mit Hilfe von Diagrammen, Tabellen, Listen
2 x 4 Minuten gegenseitige Präsentation
Architektur-Vision in 12 Minuten

34. Vision und wie geht‘s weiter?

35. Vision und wie geht‘s weiter?

36. Architektur-Wand
Quelle: Stefan Toth –
Vorgehensmuster für
Softwarearchitektur

37. Architektur-Dokumentation

38. Was ist eine Architektur-Kata?Architektur-Training

39. Relaunch von Columbus Reisen
Zweck des Systems
Columbus-Reisen ist ein etabliertes Portal für die Bewertung und Buchung von Reisen. Die aktuelle
web-basierte Applikation stammt noch aus der Gründerzeit und ist den heutigen Anforderungen
nicht mehr gewachsen. Der Kundenstamm ist auf über 10 Millionen registrierte Benutzer
angewachsen. Die Reiseangebote stammen momentan von mehreren verschiedenen Anbietern. Die
Benutzer haben insgesamt 2,5 Millionen Bewertungen zu ca. 20.000 Hotels abgegeben.
Der Relaunch soll anfänglich die bestehende Funktionalität in neuem Layout darstellen und
gleichzeitig flexibel gestaltet werden, für weitere Expansion in europäische Länder und neue Märkte.
Anforderungen
 Registrierte Benutzer können nach Pauschal- und Individualreisen in Europa suchen und
diese beim preiswertesten Anbieter buchen.
 Benutzer können Bewertungen von Hotels abgeben in Form von Text, Bildern und Videos.
 Die Manipulation von Bewertungen anderer Benutzer muss verhindert werden.
 Die Bewertungen werden nach einem komplizierten Regelwerk überprüft, um Missbrauch
weitestgehend einzuschränken
 Columbus-Mitarbeiter bereiten die Einstiegsseiten für die Reiseangebote redaktionell auf
 Batch-Läufe während der Nacht zur Aktualisierung der Reiseangebote sollen nach und nach
durch online-Anfragen ersetzt werden
 Die Ladezeit einer Webseite soll maximal 10 Sekunden betragen
Stakeholder
 10 Millionen Benutzer von Columbus-Reisen
 Reisecenter das Teile des Webauftritts manuell pflegt
 Die Strategie des Managements ist eine weitere Expansion des Unternehmens. Externe
Berater haben das Management davon überzeugt, dass dies mit den aktuellen System nicht
zu meistern ist, eine Neuimplementierung jedoch alle Probleme löst
 Der Betrieb wünscht sich eine einfache und zuverlässige Deployment-Strategie, um dem
Wunsch des Produkt-Managements nach häufigen Aktualisierungen (1x täglich)
nachkommen zu können.
Rahmenbedingungen
 Das Altsystem ist eine PHP-Anwendung
 Das Regelwerk zur Überprüfung der Bewertungen soll ohne Änderung übernommen werden
 Alle Daten befinden sich in verschiedenen MySQL Datenbanken und müssen übernommen
werden
 Das Entwicklungsteam besitzt sehr gute PHP und etwas Java-Kenntnisse
Architektur-Kata

40. Architektur Kata – 1. Durchgang
50 Minuten für Architekturentwurf
Beantworte die wichtigsten
Architektur- und Design-Fragen
Berücksichtige die wichtigsten Qualitätsziele
und Randbedingungen
Dokumentiere mit Hilfe von Diagrammen, Tabellen, Listen
2 x 15 Minuten Präsentation
Architektur Kata – 2. Durchgang
• 30 Minuten für Architektur-Vision
 Systemidee und Systemkontext
Was ist die Kernaufgabe des Systems?
Wie wird das System genutzt? Wer nutzt das System?
Über welche Schnittstellen zur Außenwelt verfügt das System?
 Priorisierte Qualitätsziele
 Einflussfaktoren und Risiken
Architektur Kata – 3. Durchgang
• 30 Minuten für Architekturentwurf
 Lösungsstrategien passend zu den Qualitätszielen
 Bausteinsicht mit geschachtelten Abstraktionsebenen
 Weitere relevante Sichten
• 2 x 15 Minuten Präsentation
Architektur-Kata – 4. Durchgang
Neue Anforderungen
• 45 Minuten für Architekturanpassung
 Anpassung der Qualitätsziele
 Anpassung der Lösungsstrategien
 Aktualisierung der Sichten
• 2 x 15 Minuten Präsentation

41. Einflussfaktoren

42. System-Kontext

44. Bausteinsicht

45. • die Umsetzung von Anforderungen in eine geeignete
Softwarearchitektur
• die richtigen Fragen an die Stakeholder stellen, um die
Anforderungen zu verstehen
• das Erkennen und Priorisieren von architektur-
relevanten Anforderungen
• die Dokumentation in Form von aussagekräftigen
Diagrammen
• … und somit die Erarbeitung einer Architektur-Vision
Architektur-Kata trainiert

46. • Roock, Pichler: Die Architekturvision in Scrum
www.sigs-
datacom.de/fileadmin/user_upload/zeitschriften/os/2011/04/pichler_roock_OS_04_11.pdf
• Gernot Starke: Effektive Software-Architekturen - Ein praktischer
Leitfaden, Hanser 2011
• Template für Architekturdokumentation
http://www.arc42.de/template/struktur.html
• Stefan Toth: Vorgehensmuster für Softwarearchitektur,
Hanser 2014
• Ted Newards Technical Blog: Architectural Katas
blogs.tedneward.com/2010/06/17/Architectural+Katas.aspx
Gemälde von Lisa und Theresa
Quellen

47. Roland Mast, Sybit GmbH
Software-Architekt, Scrum Master
roland.mast@sybit.de