Jedes interessante Softwaresystem hat eine Architektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. In diesem Vortrag stelle ich vor, wann und vor allem wie Sie und Ihr Team Ihre Lösungsansätze reflektieren können.
Architekturbewertungen sichern Entscheidungen ab, zeigen Risiken auf und schaffen Transparenz. Richtig gemacht stellen sie ein exzellentes Kommunikationsmittel dar – und keinesfalls einen Pranger.
In Umfeld der Architektur-Reviews gibt es ein reiches Arsenal an Methoden und Werkzeugen. Sie reichen von qualitativen Ansätzen wie ATAM bis zum Auswerten von Metriken oder dem Messen von Antwortzeiten, Durchsatz oder ähnlichem.
Hier gebe ich Orientierung, ordne ein und zeige auf, was wo und wann welchen Nutzen stiftet. Was argumentative, Workshop-basierte Verfahren leisten thematisiere ich dabei ebenso wie welche Aspekte Eurer Architekturziele sich mit Messungen verknüpfen lassen.

Zielpublikum: Vor allem Menschen, die Architekturentscheidungen treffen und/oder verantworten. Insbesondere im Team. Entscheider können problemlos folgen.
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Dokumentation hilft, Ideen zu kommunizieren und uns auch noch nach Wochen an Lösungskonzepte zu erinnern. Trotzdem wird sie häufig stiefmütterlich behandelt und wir treffen viel häufiger auf tolle Architekturen als auf tolle Architekturdokumentationen. In diesem Vortrag berichten wir von unseren Erfahrungen rund um Architekturdokumentation. Wir fassen 7 Anti-Patterns zusammen und geben Tipps, wie jede:r die Architekturdokumentation verbessern kann. Unsere Tipps sind unabhängig vom verwendeten Vorgehen und kombinierbar mit Templates wie arc42.

Zielpublikum: Entwickler:innen, Software-Ingenieur:innen, Architekt:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Zugegeben, kaum jemand fällt beim Thema Architektur-Dokumentation vor Begeisterung vom Stuhl, aber spätestens bei mittelgroßen Systemen geht es nicht mehr ohne. Jede:r kennt die Fragen: „Wie hatten wir uns da entschieden?“ oder „Warum wollten wir das so machen?“ Dokumentation hilft uns, Software-Architektur präziser zu machen, Ideen zu kommunizieren und uns auch noch nach Wochen an Lösungskonzepte zu erinnern.
Aber obwohl Architekturdokumentation eine so wichtige Rolle im Entwicklungsprozess einnimmt, wird sie ganz häufig eher stiefmütterlich behandelt. In unseren Projekten treffen wir viel häufiger auf tolle Architekturen als auf tolle Architekturdokumentationen. Dabei begegnen uns immer wieder die gleichen Defizite: Überbetonung von technischen Aspekten, keine oder nur unkonkrete Darstellung von Qualitätsattributen oder Vermischung von Lauf- und Entwicklungszeitaspekten sind nur einige Beispiele.
In diesem Vortrag berichten wir von unseren Erfahrungen rund um Architektur-Dokumentation von unterschiedlichsten Systemen und Branchen. Wir fassen 7 Anti-Patterns zusammen und geben Tipps wie jede:r durch einfache Mittel die Architektur-Dokumentation verbessern kann. Unsere Tipps sind unabhängig vom verwendeten Vorgehen und natürlich auch kombinierbar mit Templates wie arc42.

In dieser Session zeige ich entlang echter Softwaresysteme, wie Sie und Ihr Team Ihre Architekturansätze auf geringem Raum verdichtet und zugleich überzeugend darstellen. Sie erfahren, welche Inhalte mindestens in einen Architekturüberblick hineingehören und welche Formen sich in welcher Situation bewährt haben. Das Vorgehen für bestehende Systeme kommt genauso zur Sprache wie das Anfertigen bei neuen Softwarelösungen. Der Vortrag ist reich gespickt mit Beispielen und Best Practices, insbesondere mit Tipps gegen das Veralten der Inhalte.

Zielpublikum: In erster Linie alle, die Software entwerfen und entwickeln. Entscheider können problemlos folgen
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Extended Abstract
Die Dokumentation Ihrer Software-Architektur veraltet schnell? Deswegen fertigen Sie gar keine an? In dieser Session zeige ich entlang echter Softwaresysteme, wie Sie und Ihr Team Ihre Architektur-Ansätze auf geringem Raum verdichtet und zugleich überzeugend darstellen. Für Neue im Team ebenso wie als Einstieg z. B. in ein Architektur-Review.
Statt sich in Word oder Wiki zu verlieren, versteht Ihre Zielgruppe einen solchen Überblick im Handumdrehen; bei Bedarf führen Sie Interessierte damit zielsicher in die nötigen Details. Der Überblick ist mit überschaubarem Aufwand angefertigt und aktuell gehalten. Und sieht im Idealfall auch noch richtig gut aus!
Ganz konkret erfahren Sie, welche Inhalte mindestens in einen Architektur-Überblick hineingehören und welche Formen sich in welcher Situation bewährt haben. Das Vorgehen für bestehende Systeme kommt genauso zur Sprache wie das Anfertigen bei neuen Softwarelösungen. Der Vortrag ist reich gespickt mit Beispielen und Best Practices, insbesondere mit Tipps gegen das Veralten der Inhalte. Begleitet wird er von mehreren kompletten Architektur-Überblicken jeweils in verschiedenen Formen -- vom kompakten Folienvortrag bis zum ausgedruckten Flyer im Treppenfalz.

The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices, and strategies to embed technical debt thinking and behaviors into your culture.

Target Audience: Developers, Architects, Leaders, Managers
Prerequisites: None
Level: Advanced

Extended Abstract
The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. The management desire to be “on time and on budget”  often motivates deployment of poor-quality assets and rarely leaves room for investment in long-term quality. Although technical professionals may readily realize this problem managers often do not, or if they do they don’t view technical debt as a priority. It is time for a change.
In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Just like the technical challenges of addressing technical debt must be addressed by technical solutions, the management challenges of technical debt must be addressed by management solutions. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices to avoid and address technical debt, and enterprise-level strategies to embed technical debt thinking and behaviors into your culture. Results from industry research will be shared throughout.
Learning objectives:
• Connect project management practices to their impact on technical debt
• Learn how to describe technical debt, its impact, and solutions to leadership
• Discover how to embed technical debt thinking and practices throughout your way of working (WoW)