Hint: Damit nicht alles zusammenbricht

Wozu braucht man noch Architekten?

Michael Thomas

© Shutterstock.com/alphaspirit

So sicher wie Ebbe und Flut wird Ed Featherston nach eigenen Aussagen immer wieder gefragt, ob man in Zeiten agiler und selbstgesteuerter Teams überhaupt noch Architekten brauche. Als Senior Enterprise Architect hat er selbstredend eine dezidierte Meinung zu dem Thema …

Um den Stellenwert von Architekten zu veranschaulichen, schöpft Featherston aus seinem reichen Erfahrungsschatz: So hatte ein Klient ihn damit beauftragt, die gesamte IT-Organisation dergestalt umzubauen, dass sie die kontinuierliche Weiterentwicklung der Kerngeschäftsanwendung ermöglicht wurde. Letztere umfasste mehr als 2 Millionen Zeilen Java-Code und war in den vergangenen 7 Jahren mit Hilfe einer Myriade von Frameworks und Architekturen zusammengestöpselt worden. Einen Architekten hatte besagtes Unternehmen noch nie beschäftigt – doch genau das hätte Not getan.

Die Aufgaben des Architekten

Denn, so Featherston, ein Architekt überblickt das große Ganze: Er definiert die Systeme und zeichnet für ihre erfolgreiche Führung und Auslieferung verantwortlich. Architekten haben ihre Finger im gesamten Software-Lebenszyklus im Spiel; sind etwa von Anfang an dabei, um ein Auge auf die leicht übersehenen nicht-funktionalen Anforderungen zu haben. Deren frühzeitige Identifizierung, so Featherston weiter, hat tiefgreifende Auswirkungen auf die Architekturentscheidungen, die sich wiederum direkt auf die Performance, Skalierbarkeit, Sicherheit und Verfügbarkeit eines Systems auswirken.

Die Rolle des Architekten geht Featherston zufolge jedoch über das technische hinaus: Um sicherzustellen, dass am Ende des Entwicklungsprozesses alle Komponenten und Module zusammenpassen und sämtliche Anforderungen erfüllt werden, ist er auch für die grundlegenden Prinzipien, Prozesse und Strukturen verantwortlich. Darüber hinaus arbeiten Architekten mit allen Stakeholdern (Qualitätssicherung, Support, Sicherheit etc.) zusammen. Wird die Architektur im laufenden Entwicklungsprozess geändert, ist er dafür verantwortlich, diesen die Auswirkungen, die potentiellen Vor- und Nachteile, zu erläutern.

Zusammengefasst könnte die Antwort auf die Frage, wozu man Architekten benötigt, also lauten: „Um den Laden zusammenzuhalten“. Oder, in den Worten von Featherston:

While there was more to our discussion, the client stated “So since I didn’t have someone doing all that, that’s the reason my system is having the problems I brought you folks in to help with, is that a fair statement?” Maybe I should have gone with my original urge to just say that.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Aufmacherbild: Architect showing new house project with tablet von Shutterstock / Urheberrecht: alphaspirit

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

1
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Alexander Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Alexander
Gast
Alexander

Den Architekten braucht man also um die verschiedenen Teilbereiche, die am Wertschöpfungsprozess teilhaben zusammenzuhalten. Ist es aber nicht das Ziel genau diese Struktur der separierten Teilbereiche aufzulösen und alle in *ein* Team vereinen? Hat man dieses Ziel erreicht, stellt sich also durchaus die Sinnfrage der Architekten-Rolle…