Software-Architektur ist allgegenwärtig. Trotzdem gibt es in vielen Organisationen kaum eine weitgehend anerkannte Definition der Rolle. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

In diesem Vortrag werden wir konkrete Wege kennenlernen, wie wir Architekturarbeit effektiv gestalten können. Wir streifen Themen wie Dokumentation, Entscheidungsfindung, Kommunikation und Skillset. Außerdem lernen wir Prinzipien kennen, die uns im Alltag als Software-Architekten eine Stütze sein können.

Zielpublikum: Software-Architekt:innen, Software-Entwickler:innen, Manager, Entscheider
Voraussetzungen: Grundwissen in Software-Entwicklung und -Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Rolle von Software-Architekten ist in vielen Organisationen nicht klar oder gar explizit definiert, geschweige denn gibt es eine Definition der Rolle, die allgemein anerkannt ist und entsprechend gelebt wird. Oft fehlt für diese Rolle im Berufsalltag eine klare Zielsetzung. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

Wir könnten nun versuchen, den Rollenbegriff von Software-Architekten bestmöglich zu schärfen. Doch ist das wirklich zielführend? Gerade in der Software-Entwicklung haben wir mit unterschiedlichsten Kontexten zu tun, die sich obendrein ständig ändern. Das macht eine einheitliche Definition der Rolle umso schwieriger.

Ein anderer Ansatz wäre, dass wir von Good Practices und (mehr oder weniger) etablierten Prinzipien ausgehen, um unseren Berufsalltag effektiv zu gestalten. Der Vorteil dieses Ansatzes ist, dass wir kontextspezifisch entscheiden können, welche Prinzipien für uns passen. Somit ergibt sich die Jobbeschreibung von Software-Architekten nicht aus einer allgemein gültigen Definition, sondern immer aus konkreten, kontextabhängigen Richtlinien.

Die Good Practices und Prinzipien versuchen wir im Vortrag aus folgenden Fragen abzuleiten:
-    Sollte man in der Rolle als Software-Architekt coden?
-    Ist breites oder tiefes technisches Wissen wichtiger?
-    Wie viele Vorgaben sollen effektive Architekturentscheidungen machen?
-    Wann ist der beste Zeitpunkt, um Architekturentscheidungen zu treffen?
-    Wie viel Kontrolle soll man in der Rolle als Software-Architekt ausüben?
-    Sollte man Top-Down oder Bottom-Up vorgehen?
-    Wie kann man die Zielerreichung von Software-Architektur unter ständiger Veränderung sicherstellen?
-    Sollte es die Rolle "Software-Architekt" überhaupt geben?

Aufgrund der oben erwähnten kontextspezifischen Unterschiede der Architekturrolle soll dieser Vortrag Raum für Interaktion bieten, um die Fragestellungen aus verschiedenen Gesichtspunkten durchleuchten zu können.

Teilnehmer sollen die Session mit Anregungen zum Nachdenken verlassen, wie sie ihre eigene Architekturarbeit effektiver gestalten können.

Mal angenommen, es gäbe ein (natürlich fiktives) Großprojekt zur Implementierung einer Microservices-Architektur. Die Entwickler:innen sind in zahlreichen Teams organisiert. Zudem gibt es ein übergreifendes Architekturgremium. Selbstverständlich wird auch ein proprietäres Framework programmiert. In jedem Team existiert die Rolle des "Technischen Architekten".

Kommt Ihnen das bekannt vor? Und haben Sie sich auch schon öfters gefragt, was er/sie eigentlich die ganze Zeit macht? In diesem unterhaltsamen Praxisbericht können Sie es herausfinden.

Zielpublikum: Entwickler:innen, Architekt:innen, Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Tatsächlich erscheint es für viele Projektmitarbeitende immer wieder fraglich, was der/die Technical Software Architect eigentlich den ganzen Tag so macht. Scheinbar werden doch die Architekturvorgaben vom dafür verantwortlichen Gremium erarbeitet. In der Praxis ist es jedoch oft so, dass tatsächlich zahlreiche Themen anstehen.

Dazu zählt die Bewertung der Folgen solcher Technologievorhaben für das eigene Team, genauso wie der Versuch der Beeinflussung des Gremiums bei der Entscheidungsfindung. Hinzu kommen diverse "politische" Themen oder die Sicherstellung der Einhaltung von Architekturvorgaben und der Softwarequalität. Über die Jahre habe ich hier eine Reihe sehr interessanter und oftmals auch (rückblickend) amüsanter Erfahrungen gemacht, die ich gerne weitergeben möchte.