Sie kennen Stefan Toth, Experte für Softwareentwicklung und –Architektur und Autor des Buches „Vorgehensmuster für Softwarearchitektur“ bereits aus unserem Fomat vorgestellt! Nun beantwortet er uns fünf Fragen zum Thema Softwarearchitektur!
Softwarearchitektur wird laut Wikipedia in der Regel als die „früheste Softwaredesign-Entscheidung“ definiert. Ist das immer so?
Nein. Softwarearchitektur beschäftigt sich mit weitreichenden Entscheidungen. Einige dieser Entscheidungen müssen früh fallen, um schädliche Inkonsistenzen zu verhindern oder die Entwicklungsabteilung arbeitsfähig zu machen. Die technische Plattform oder der Architekturstil wären Beispiele hierfür. Zu Beginn des Projekts hat man allerdings auch das wenigste Wissen über das zu lösende Problem – würde man alle Architekturentscheidungen zu Beginn treffen, entscheidet man die wichtigsten Themen unter der größtmöglichen Unsicherheit. Kein guter Plan. Seit vielen Jahren gibt es deshalb Bemühungen Architekturentscheidungen zu verschieben und später bearbeitbar zu machen. Klassische Konzepte, wie Abstraktionsschichten oder Standardprotokolle, sind genauso Beispiele dafür wie der aktuelle Trend zu Microservices. Bei Microservices fixiert man meist das Kommunikationsmodell und einige Service-Prinzipien, andere Themen sind dann aber Teamfrage und nicht mehr zentral und früh vorgegeben – das kann Technologie-, Strukturierungs- und auch Datenhaltungsfragen beinhalten. Wikipedia vereinfacht also etwas und vertritt hier eher eine klassische Sichtweise. In meinem Buch versuche ich die später stattfindende Architekturarbeit methodisch zu untermauern und in mehr Projekten zu ermöglichen.
Wie würde Ihre Definition von Softwarearchitektur lauten?
Softwarearchitektur ist die Summe jener Entscheidungen, die später schwer zu ändern sind. Das können je nach Projektkontext unterschiedliche Themen sein, meist umfassen diese Entscheidungen aber zentrale Prinzipien und grundlegende Technologien.
Welche umgebenden Aspekte beeinflussen die Softwarearchitektur aktuell? Gibt es hier wichtige Trends?
Mit der agilen Bewegung und Scrum hat sich Architektur zu einer wirklich iterativen Disziplin gewandelt. Die meisten Unternehmen behaupten von sich bereits, agil zu arbeiten, dabei ist der Wandel allerdings meist nicht vollständig oder gewinnbringend vollzogen. Momentan beobachte ich deshalb oft Unsicherheiten was das Vorgehen betrifft – sollen wir noch mehr Richtung agil gehen, noch puristischer werden? Oder sollen wir klassische Ansätze zurückholen? Technische oder konzeptionelle Themen sind hier oft ein Schlüssel und Architektur deshalb nicht nur beeinflusst, sondern mittendrin.
Daneben gibt es immer mehr Druck schnell auszuliefern, Systeme mehr Leuten zugänglich und zuverlässiger zu machen. Das erfordert neue technische Konzepte und gleichzeitig auch organisatorische Veränderungen. Die Architekturdisziplin muss sich mit der Anforderungserhebung, Entwicklung, Auslieferung und dem Betrieb vernetzen.
Welche Themen werden sonst im Bereich Softwarearchitektur derzeit heiß diskutiert?
Oh, da gibt es viele! Microservices, Resilience, Mobile, Flux, Containerization, … und all diese eher technischen Trends haben auch methodische Auswirkungen. Netflix, Spotify, WordPress und andere IT-Schwergewichte arbeiten nicht so an Softwarearchitektur wie wir es von dicken Büchern aus den 1990ern kennen. Teams haben Feature-Verantwortung bis in die Produktion, die Teamabstimmung erfolgt weniger von oben gesteuert, Prinzipien werden wichtiger, konkrete Entscheidungen von sehr vielen unterschiedlichen Leuten getroffen und vorangetrieben. Die Identifikation von relevanten Themen zwischen Teams wird wichtiger, Communities werden geschaffen und gelebt, u.s.w. Diese Unternehmen arbeiten hocheffizient an technischen Themen, sind schnell bei Auslieferungen, haben hohe Produktqualität vorzuweisen und stemmen teilweise riesige IT-Transformationen im Flug. Das ist nicht nur interessant das ist eine Lernchance für alle!
Haben ein oder mehrere Aspekte Eingang in die 2. Auflage Ihres Buches gefunden?
Im Buch habe ich viele der genannten Aspekte aufgegriffen und ihnen Namen gegeben. Ich habe sie in sogenannten „Vorgehensmustern“ klar abgegrenzt und kleinteilig erlernbar gemacht. Jedes Projekt kann so stückchenweise ausprobieren, was die Vorreiter der IT-Industrie machen und was ich bei meinen Kunden als erfolgreich erlebe. Letztendlich möchte ich es Projekten ermöglichen, eine zum eigenen Kontext passende und auch zeitgemäße Architekturpraxis zu etablieren.
Beispiele für Vorgehensmuster, die an die genannten Themen andocken wären „Im Prinzip entscheiden“, „Architekturcommunities“, „Kontinuierlich integrieren und ausliefern“ oder „der letzte vernünftige Moment“. Insgesamt habe ich davon in der zweiten Auflage 30 Stück beschrieben.