Der Software-Architekt gibt die Architektur vor – die Entwickler setzen sie um: Dieses Bild kann zwar stimmen, muss es aber nicht. Denn welche Aufgaben ein Architekt tatsächlich übernimmt, hängt stark von der jeweiligen Organisation ab. Glaubt man den Softwarearchitekten Erik Dietrich und Sameh Deabes, so sollte allen jedoch eines gemeinsam sein: Der Stallgeruch des Entwicklers.
Welche Aufgaben ein Architekt übernimmt, ist aufgrund des Fehlens einer allgemeingültigen Definition mitunter gar nicht so einfach zu sagen. Wie Erik Dietrich in einem aktuellen Blogpost ausführt, schreibt die Industrie die Unterschiede zwischen Architekten und Entwicklern zwar gerne in Gegensatzpaaren à la „Architekten arbeiten am Gesamtbild, Entwickler an Details“, „Architekten entwerfen Visionen, Entwickler setzen sie um“ oder „Architekten führen, Entwickler werden geführt“ fest. Doch im Endeffekt, so Dietrich, schwingen in der Bezeichnung „Architekt“ teils völlig unterschiedliche Bedeutungen mit – je nachdem, für welche Organisation man tätig ist. Im Extremfall führt die Unsicherheit der Architektenrolle seiner Erfahrung nach dazu, dass sich ihre Aufgaben manchmal nur in Nuancen von denen der Entwickler unterscheiden.
Lesen Sie auch: ‘Softwarearchitektur wird immer mehr zum Entwickler-Skill’
Zur Veranschaulichung greift Dietrich auf das Beispiel von Rechtsanwälten in großen Kanzleien zurück: Dort leisten sowohl die Senior- als auch die Junior-Partner im Endeffekt ähnliche Arbeit. Der Unterschied zwischen beiden besteht vor allem darin, dass die höheren Chargen die allgemeine Richtung vorgeben, sich um das Knacken der härteren Nüsse kümmern und die weniger kritischen Aufgaben an die „Frischlinge“ delegieren. Übertragen auf Softwarearchitekten und Entwickler ergibt sich für Dietrich folgendes Bild: Die Stellung als Softwarearchitekt kann schlicht als eine höhere Stufe der Karriereleiter, die dank größerer Erfahrung erklommen wurde, betrachtet werden. Architekten kümmern sich demnach um das „große Ganze“ (Vorgabe der Technologien, Zuweisung von Aufgaben etc.), erledigen Aufgaben aus dem Management-Bereich und verbringen insgesamt weniger Zeit mit der praktischen Arbeit als die Entwickler – doch wenn sie es tun, konzentrieren sie sich auf die besonders wichtigen Baustellen.
Video: Software-Architektur in agilen Teams – Vom Elfenbeinturm zur Selbstorganisation
Die Rolle des Architekten ist, folgt man dieser Argumentation, also nicht als grundlegend anders, sondern nur als graduell verschieden zu betrachten. Oder anders ausgedrückt: Der Architekt ist eine „weiterentwickelte“ Form des Entwicklers, weshalb Dietrichs Ansicht nach jeder Entwickler – zumindest auf elementare Art und Weise (Blick auf das große Ganze, Selbstverständnis als Problemlöser) – auf dieses Ziel hinarbeiten sollte.
Softwarearchitekt = Chefprogrammierer
Der Software-Architekt Sameh Deabes schlägt in eine ähnliche Kerbe. Zwar betrachtet er Softwarearchitekten im Grunde als „Chefprogrammierer“, die für alle strategischen (technischen) Entscheidungen einer Organisation verantwortlich zeichnen. Doch im Endeffekt sind auch seiner Erfahrung nach die tatsächlichen Aufgabengebiete stark vom jeweiligen Arbeitgeber abhängig, was sich u. a. auch in der teils synonymen Verwendung von Stellenbezeichnungen wie Application Architect, Solutions Architect, Enterprise Architect etc. niederschlägt.
So zählen Management-Aufgaben wie Budgetierung, Ressourcenzuweisung etc. nicht zwangsläufig zur Tätigkeit eines Architekten, in manchen Fällen kann er jedoch bei entsprechenden Fragen durchaus hinzugezogen werden. Obwohl er für die längerfristigen strategischen Entscheidungen verantwortlich ist, kann er im Einzelfall auch bei kurzfristigen, taktischen Entscheidungen seine Finger mit im Spiel haben. Zwar ist er der Herr über die Architektur, kann aber auch offen für Vorschläge aus den Reihen des Teams sein (und ist in diesem Fall der Entscheider darüber, welche Ideen umgesetzt werden). Schlussendlich, so Deabes, überschneidet sich seine Position mit zahlreichen weiteren Rollen: Führungsaufgaben können ebenso in seinen Verantwortungsbereich fallen wie auch Design, Refaktorisierung, Code-Reviews, die Zusammenarbeit mit Management und Kunden, die Tätigkeit als Lehrer, der den Nachwuchs aufpäppelt u. v. a. m.
Lesen Sie auch: Wie viel Technologiewissen braucht ein Softwarearchitekt?
Gerade aufgrund dieses potentiell sehr breit gefächerten Aufgabenspektrums steht auch für Deabes fest, dass Architekten sich in jedem Fall regelmäßig die „Finger schmutzig machen“, sprich: Code schreiben sollten. Zwar ist Deabes (wie auch von Dietrich angerissen) der Meinung, dass dies nur in besonders relevanten Einzelfällen (z. B. die Erbringung eines Machbarkeitsnachweises oder die Entwicklung einer Lösung für ein besonders herausforderndes Problem) erfolgen sollte. Unumgänglich ist es für ihn jedoch allemal: Nur wer stets einen wachen Blick auf die praktische Arbeit hat, kann ihm zufolge am besten entscheiden, welche Technologien und Lösungen jeweils die sinnvollsten sind.
Aufmacherbild: Software concept: Programmer icons on Digital Paper background von Shutterstock / Urheberrecht: Maksim Kabakou
