In [1] finden Sie noch viel mehr Details zu diesen Grundlagen.<\/p>\n\n\n\n Abbildung 1: Beispiel Grundriss<\/p>\n\n\n\n <\/p>\n\n\n\n Wie bei Geb\u00e4uden auch, m\u00fcssen wir verstehen: Was sind die genauen Anforderungen an die Funktionen des Systems, dessen Qualit\u00e4ten (z.B. Durchsatz, Verf\u00fcgbarkeit, Performance, Sicherheit) und an das gew\u00fcnschte Verhalten im produktiven Betrieb. K\u00f6nnen und d\u00fcrfen wir das System im Betrieb updaten?<\/p>\n\n\n\n Mit dem Grundriss entscheiden wir \u00fcber den strukturellen Aufbau von Systemen aus Komponenten, wie Packages, Namespaces, Module und Services mitsamt den jeweiligen Schnittstellen. Das sind die typischen \u201eK\u00e4stchen-und-Pfeile\u201c-Diagramme, denen noch wichtige Informationen \u00fcber unser \u201eBaumaterial\u201c fehlen: Programmiersprachen, Bibliotheken und alles, was lapidar \u201eTech-Stack\u201c genannt wird.<\/p>\n\n\n\n Die Anbindung an Nachbarsysteme \u2013 externe Schnittstellen genannt (Kontextabgrenzung) \u2013 hat ebenfalls gro\u00dfe Bedeutung. H\u00e4ufig lauern genau darin gro\u00dfe Risiken, die erst im Produktivbetrieb zu Problemen auswachsen. [2]<\/p>\n\n\n\n Mit diesen Grundlagen k\u00f6nnen wir nun die Rolle und das Berufsbild besser einordnen.<\/p>\n\n\n\n <\/p>\n\n\n\n Berufsbilder oder Rollen lassen sich sehr gut \u00fcber die daf\u00fcr notwendigen Aufgaben oder T\u00e4tigkeiten beschreiben. F\u00fcr Softwarearchitektur finden Sie in Abbildung 2 einen verbreiteten Vorschlag \u2013 kompatibel mit den Vorstellungen von iSAQB\u00ae<\/sup> [3] und arc42 [4]. St\u00e4ndiges Feedback bildet eine wichtige Grundlage f\u00fcr diese Aufgaben. Verbessern Sie die Architektur auf Basis der R\u00fcckmeldungen relevanter Stakeholder und hinterfragen Sie st\u00e4ndig, sowohl strukturelle (\u201eGrundriss\u201c) wie auch technische Entscheidungen!<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 2: Tasks in Software Architecture<\/p>\n\n\n\n <\/p>\n\n\n\n In Abbildung 2 finden Sie die wesentlichen Entwurfs- oder Entscheidungsaufgaben. Diese basieren auf den (hoffentlich) gekl\u00e4rten Anforderungen (oben links). Die Entscheidungen kommunizieren Sie den relevanten Stakeholdern (unten links), indem Sie erkl\u00e4ren, begr\u00fcnden, motivieren, dokumentieren.<\/p>\n\n\n\n Die Aufgabe \u201eUmsetzung begleiten\u201c f\u00fchren Sie kontinuierlich und gemeinsam mit dem Entwicklungsteam durch: Beide sollten sicherstellen, dass die Implementierung auch der gew\u00fcnschten Architektur entspricht. Mehr zu diesen Aufgaben finden Sie in [7].<\/p>\n\n\n\n Auf die schwierige Frage, ob und wie wir diese Aufgaben im Team verteilen, oder ob eine einzelne Person daf\u00fcr zust\u00e4ndig sein soll, m\u00f6chte ich an dieser Stelle nicht eingehen. Als Trostpflaster schauen Sie bitte in Abbildung 3 finden Sie ein Spektrum von M\u00f6glichkeiten (urspr\u00fcnglich mal von Gregor Hohpe in [6] beschrieben).<\/p>\n\n\n\n <\/p>\n\n\n\n Abbildung 3: Wer \u00fcbernimmt die Aufgaben?<\/p>\n\n\n\n <\/p>\n\n\n\n Beginnen Sie damit, die wesentlichen Aspekte und Entscheidungen Ihrer eigenen Architektur als One-Pager zu dokumentieren (siehe [5] und Abbildung 2). Damit haben Sie einen ordentlichen Teil der relevanten Grundlagen und Entscheidungen explizit gemacht, und k\u00f6nnen Feedback Ihrer Stakeholder einholen.<\/p>\n\n\n\n <\/p>\n\n\n\n Abbildung 4: Architecture Communication Canvas<\/p>\n\n\n\n <\/p>\n\n\n\n Auf welche Weise Sie einen f\u00fcr die jeweiligen Anforderungen angemessenen \u201eGrundriss\u201c sowie Implementierungs- und Betriebstechnologien ausw\u00e4hlen oder entscheiden, w\u00fcrde den Umfang dieses Artikels sprengen. Zum Grundriss finden Sie einige Hinweise im Artikel zum Modul Domain-Driven Design (DDD)<\/a>. Daneben existieren viele grundlegende Prinzipien (etwa: lose Kopplung, hohe Koh\u00e4sion, Information-Hiding, Modularit\u00e4t etc.) und jede Menge Patterns als Hilfsmittel. Letztlich treffen Sie Architekturentscheidungen situativ also an der jeweiligen Ausgangslage orientiert. Das klingt schwierig, und meiner Erfahrung nach IST es das auch. Genau das f\u00fchrt uns zur letzten Frage: Wie k\u00f6nnen Sie das lernen und<\/p>\n\n\n\n <\/p>\n\n\n\n Meiner Erfahrung nach sollten Sie einige Jahre lang programmieren und damit aktiv in der Entwicklung von Software arbeiten. Das gibt Ihnen den notwendigen \u201eRiecher\u201c um Unw\u00e4gbarkeiten und Risiken in den Bereichen Entwurf und Architektur zu erkennen und zu umschiffen. Daneben braucht es ein gro\u00dfes Ma\u00df an Kommunikationsf\u00e4higkeit, und zwar mit vielen verschiedenen Stakeholdern: Je besser Sie in der Lage sind, auf die Sprachen und Ziele dieser Menschen einzugehen, desto besser werden Ihre Architekturentscheidungen. Also: \u00fcben, \u00fcben, \u00fcben \u2013 und immer sch\u00f6n Feedback einholen.<\/p>\n\n\n\n <\/p>\n\n\n\n Die Rolle Softwarearchitekt:in tr\u00e4gt meiner Ansicht nach die Verantwortung f\u00fcr die erfolgreiche Umsetzung von Anforderungen. Dabei treffen Sie eine Reihe grundlegender Entscheidungen, entweder allein oder mit Ihrem Team.<\/p>\n\n\n\n Eigene Erfahrungen k\u00f6nnen Sie dabei kreativ einbringen und damit positiv auf IT-Projekte und \u2011Produkte einwirken. Sie m\u00fcssen kommunizieren und Entscheidungen manchmal auch gegen Widerst\u00e4nde argumentieren. F\u00fcr motivierte Entwickler:innen bedeutet Softwarearchitektur in vielen F\u00e4llen mehr Verantwortung und gr\u00f6\u00dfere Einflussm\u00f6glichkeiten.<\/p>\n\n\n\n M\u00f6ge die Macht guter Entscheidungen und wohl formulierter Begr\u00fcndungen mit Ihnen sein!<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Der Beruf des Softwarearchitekten erfordert mehr als nur technisches Fachwissen. Gernot Starke erl\u00e4utert die Kernaufgaben, die praktische Erfahrung und die Kommunikationsf\u00e4higkeiten, die einen effektiven Architekten auszeichnen.<\/p>\n","protected":false},"author":8,"featured_media":1332,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_trash_the_other_posts":false,"editor_notices":[],"footnotes":""},"categories":[29,189],"tags":[],"class_list":["post-1330","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-advanced-level","category-foundation-level"],"yoast_head":"\n![\"\"](\"https:\/\/www.isaqb.org\/wp-content\/uploads\/sites\/2\/2026\/03\/Abb-1-floorplan.jpg\")
<\/figure>\n\n\n\n\u201eSoftwarearchitektur\u201c \u2013 Was bedeutet das?<\/h2>\n\n\n\n
Was muss ich tun?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.isaqb.org\/de\/wp-content\/uploads\/sites\/2\/2026\/03\/Abb-2-Aktivitaeten-Scrrenshot.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.isaqb.org\/de\/wp-content\/uploads\/sites\/2\/2026\/03\/abb-3-wer-uebernimt-die-aufgben-1024x322.png\")
<\/figure>\n\n\n\nWie geht das?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.isaqb.org\/wp-content\/uploads\/sites\/2\/2026\/03\/Abb-4-architecture-communication-canvas-1024x726.png\")
<\/figure>\n\n\n\nWie komme ich dahin?<\/h2>\n\n\n\n
Fazit<\/h2>\n\n\n\n
Links und Referenzen<\/h3>\n\n\n\n
\n