Aus dem englischen übersetzter Softwarearchitektur Report 2024
Warum haben wir das gemacht?
Die Idee der „Softwarearchitektur“ gibt es seit mehr als 50 Jahren, also länger, als das Internet öffentlich ist! Dennoch drehen sich die meisten Gespräche über Software heute normalerweise um glänzende neue Programmierframeworks, Infrastrukturen und … Sie haben es erraten, KI. Obwohl all dies in irgendeiner Weise mit Softwarearchitektur zusammenhängt, liegt der Fokus heutzutage nicht mehr so sehr auf den Tools, Praktiken und der Disziplin selbst.
Vor einigen Monaten haben wir Architekten, technische Leiter und alle befragt, die vom Verständnis komplexer Systeme profitieren. Unser Ziel war es, nützliche Erkenntnisse über das Feld und seine Entwicklung zu gewinnen. Wir waren beeindruckt von der Beteiligung an den Antworten, da dies die allererste Umfrage war, die wir verschickt haben! Es ist klar, dass ein Verlangen besteht, Meinungen und Ideen auszutauschen.
Wir hoffen, dass die Ergebnisse einige Gedanken über die Branche, Praktiken und Ideen anregen, um Ihrem Team zu helfen, besser im Bereich Softwarearchitektur zusammenzuarbeiten.
Wichtige Highlights
96 Personen haben an der Umfrage teilgenommen. Die meisten waren Architekten und Ingenieure, die Vollzeit in mittleren (100–499) und großen (5.000+) Unternehmen arbeiteten. Ihr Unternehmen hatte normalerweise ein kleines Team von Architekten, zwischen 1 und 9.
Die meisten Befragten (96 %) verwendeten Diagramm- und kollaborative Wiki-Tools (79 %), um ihre Softwarearchitektur zu dokumentieren. Die Leute verwendeten eine breitere Palette von Tools als Quelle der Wahrheit, von Diagramm-Tools über kollaborative Wikis bis hin zu informellen Methoden. Einige hatten sogar keine einzige Quelle der Wahrheit!
Die Leute aktualisierten ihre Architektur in unterschiedlichen Abständen (wöchentlich, monatlich, vierteljährlich), führten formale Architekturüberprüfungen einmal oder weniger pro Jahr durch und die Hälfte der Befragten verwendete Architekturentscheidungsaufzeichnungen (Architectural Decision Records, ADRs).
Die am häufigsten verwendeten Architekturmuster waren Microservices (67 %) und ereignisgesteuerte (62 %).
Die meisten Befragten waren mäßig oder sehr sicher im Umgang mit dem C4-Modell. Container-/App-Diagramme (Level 2) waren der am häufigsten verwendete Diagrammtyp, gefolgt von Kontextdiagrammen (Level 1).
60 % der Befragten glaubten, dass die KI-gestützte Erstellung und Pflege von Dokumenten in den nächsten 5 Jahren den größten Einfluss auf die Branche haben würde.
Lassen Sie uns die verschiedenen Abschnitte genauer betrachten.
Wer hat geantwortet?
Es gab insgesamt 96 Antworten.
Mehr als die Hälfte (55 %) der Befragten waren Architekten, wobei Lösungsarchitekten mit 29 % am häufigsten vorkamen. Ingenieure/Entwickler waren mit 26 % die zweitgrößte Gruppe.
Die Mehrheit der Befragten waren Vollzeitbeschäftigte (96 %) mit 1–5 Jahren (38 %) und mehr als 10 Jahren Erfahrung (41 %).
Es gab eine große Bandbreite an Unternehmensgrößen, wobei 100–499 (25 %) und 5.000 oder mehr (24 %) am häufigsten vorkamen.
Trotz der großen Bandbreite an Unternehmensgrößen hatten die meisten ein kleines Team engagierter Architekten. Die häufigste Teamgröße war mit 58 % 1–9 Architekten.
Andere Berufsbezeichnungen: Mitbegründer/CTO, Systemingenieur, SRE
Werkzeuge und Praktiken
Dieser Abschnitt konzentrierte sich auf spezifische Werkzeuge und Praktiken zum Erstellen und Verwalten von Softwarearchitekturdokumentation.
Die meisten Befragten (96 %) verwendeten Diagrammtools zum Dokumentieren ihrer Softwarearchitektur, gefolgt von kollaborativen Wikis (79 %).
Überraschenderweise erwähnten 64 % die Verwendung eines Modellierungstools – etwas unerwartet, da wir diese Umfrage verschickt haben 🤔.
Obwohl dies am wenigsten verbreitet war, war es interessant zu sehen, dass 40 % der Leute immer noch physische Whiteboards zur Dokumentation verwendeten. Nichts kann die Flexibilität eines Whiteboards übertreffen.
Die Befragten konnten mehrere Antworten auswählen
Wir haben eine größere Divergenz darin festgestellt, wo die Quelle der Wahrheit für die Softwarearchitektur eines Teams lag.
37 % gaben an, Diagramme zu verwenden und manuell zu pflegen, während 30 % sagten, dies tue man mit einem kollaborativen Wiki-Tool.
16 % hatten keine einzige Quelle der Wahrheit und 7 % verfolgten sie mit Code oder informell. Die Teams versuchen immer noch, den idealen Standort ihrer Quelle der Wahrheit zu finden, der Aufwand und Zugänglichkeit ins Gleichgewicht bringt.
Die Befragten konnten nur eine einzige Antwort auswählen
Es gab kein Muster dafür, wie oft die Leute ihre Architekturdokumente aktualisierten. Es war eine enge Aufteilung zwischen monatlich (28 %), vierteljährlich (23 %) und wöchentlich (23 %).
Die Leute führten jedoch seltener formelle Architekturüberprüfungen mit ihrem Team durch, wobei jährlich oder seltener mit 41 % die häufigste Antwort war.
Es war eine enge, ausgeglichene Aufteilung, wenn es um die Verwendung von Architekturentscheidungsaufzeichnungen (ADRs) ging – 47 % sagten ja und 53 % nicht.
Die am häufigsten verwendeten Architekturmuster waren Microservices (67 %) und ereignisgesteuert (62 %). Es wird interessant sein zu sehen, wie sich dies in den kommenden Jahren entwickelt.
C4-Modell
Dieser Abschnitt konzentrierte sich auf die Einführung des C4-Modells und seine Herausforderungen. Wer das C4-Modell nicht kennt, kann sich hier aufschlauen: C4 Architektur.
Die meisten Leute waren mäßig (41 %) oder sehr zuversichtlich (39 %) bei der Verwendung des C4-Modells.
Wir baten die Befragten, die nicht oder nur wenig zuversichtlich waren, den Grund dafür genauer zu erläutern. Einige häufige Antworten waren: Noch nie davon gehört oder keine Zeit gehabt, damit zu arbeiten/es zu lernen.
Container-/App-Diagramme waren mit 85 % der am häufigsten verwendete Diagrammtyp im C4-Modell, gefolgt von Kontext- (67 %) und Komponentendiagrammen (51 %).
Von den ergänzenden C4-Diagrammen verwendeten die meisten Leute am häufigsten Systemlandschaftsdiagramme (26 %) oder dynamische Diagramme/IcePanel-Flows (27 %).
Zuletzt baten wir die Leute, ihre Herausforderungen mit dem C4-Modell zu erläutern.
Einige häufige Herausforderungen waren:
Erstellen einer Gesamtansicht, die das richtige Gleichgewicht zwischen Detail und Klarheit bietet.
Verstehen, wie man Dinge auf die C4-Modellabstraktionen abbildet (z. B. was auf welcher Ebene passieren sollte, was ein System ist, was eine Komponente ist).
Die beste Art, ereignisgesteuerte Architekturen zu modellieren.
Das Modell auf dem neuesten Stand halten und Änderungen im Laufe der Zeit verfolgen.
Die Zukunft der Softwarearchitektur
Der letzte Abschnitt konzentrierte sich darauf, wie sich die Softwarearchitektur und die Rolle eines Architekten entwickeln.
KI hat jede Branche beeinflusst, und es war keine Überraschung, dass die Leute glauben, dass die KI-gestützte Erstellung und Pflege von Dokumenten (60 %) in den nächsten 5 Jahren den größten Einfluss auf die Softwaredokumentation haben wird.
Automatisierte Updates aus Code (48 %) und die Integration von Dokumenten in CI/CD-Pipelines (41 %) werden in den kommenden Jahren ebenfalls voraussichtlich mehr Einfluss haben.
Die Leute schienen geteilter Meinung darüber zu sein, wie sich die Rolle der Architekten in Zukunft entwickeln wird.
63 % dachten, Architekten würden stärker in das Geschäft und die Strategie eingebunden, 62 % glaubten, sie würden stärker in das Coaching und Mentoring von Teams bei der Architekturgestaltung eingebunden sein, und 50 % dachten, sie würden mehr Verantwortung für Sicherheit und Compliance tragen.
Wir beendeten die Umfrage mit einer letzten Frage, damit die Befragten ihre offenen Gedanken zur Softwarearchitektur mitteilen konnten. Viele Leute betonten die Bedeutung der Zusammenarbeit, nicht nur zwischen den Disziplinen (Entwickler <> Architekten), sondern auch innerhalb von Architekturteams. Einige Leute erwähnten auch die Bedeutung der Architektur beim Setzen von Leitplanken und beim Sicherstellen, dass sich Systeme diszipliniert weiterentwickeln, insbesondere angesichts des Aufstiegs der KI.
Fazit
Auch heute ist und bleibt die SW-Architektur ein nicht ernstgenommener Zweig in der Software-Entwicklung. Mal ganz ehrlich: Sind sie fit im C4?
Mehr zum Thema: Softwarearchitekt