Interview mit Phillip Ghadir, Stefan Tilkov und Gernot Starke

"Softwarearchitekten sind auch nur Menschen"

Mirko Schrempp

Wer sich nach der gerade zu Ende gegangenen JAX weiter in das Thema „Softwarearchitektur“ vertiefen möchte, findet im Software Architecture Summit eine geeignete Fortsetzung. Vom 5. bis 7. Juni vermitteln sieben renommierte Trainer praxisnahes Architektur-Know-How. Wir sprachen vorab mit den Speakern Phillip Ghadir, Dr. Gernot Starke und Stefan Tilkov über die Rolle des Softwarearchitekten, sein Verhältnis zur Fachseite und sein Gespür für Architekturen, die aus dem Ruder laufen.

JAXenter: Wenn man von Softwarearchitektur spricht, denkt man naturgemäß zunächst an Technologie bzw. an Software. Aber hinter einer Architektur stecken auch die Menschen, die sie erdacht haben – was sind Softwarearchitekten für Typen?

Phillip Ghadir: Softwarearchitekten sind auch nur Menschen. Ich mag den Vergleich mit dem Zehnkämpfer, den Gernot und Peter in ihrer Java-Magazin-Kolumne verwendet haben. Ein Softwarearchitekt sorgt dafür, dass der Auftraggeber ein in seinem Sinne gutes System erhält. Das bezieht sich sowohl auf die Funktionalität als auch auf die erwartete Qualität. Er inspiriert das Team, diskutiert Rahmenbedingungen mit den Beteiligten.

Stefan Tilkov: Auf jeden Fall sind Softwarearchitekten (und -architektinnen übrigens) nicht nur in technischen Disziplinen stark, sondern auch gute Diplomaten. Sie müssen unter Umständen unter sehr vielen starken Charakteren vermitteln, und Konsens herbeiführen und ihn dann immer wieder neu vermitteln bzw. verkaufen.

JAXenter: Also in keinem Fall Einzelkämpfer, sondern Teamplayer. Dadurch stehen sie aber oft auch zwischen den Stühlen. Wie geht man damit um, wenn auf der einen Seite die Entwicklung und auf der anderen Seite das Business fordert, zerrt und eigentlich immer etwas anderes will?

Phillip Ghadir: Jeder hat da seine eigenen Mittel und Wege. Bei der Zusammenarbeit kommen alle Methoden der zwischenmenschlichen Interaktion zu Tage: abstimmen, klären, überzeugen, überreden, fragen, bestimmen etc. Ein guter Softwarearchitekt erkennt, wann er besser den offiziellen Weg wählt und wann er besser außerhalb des Protokolls agiert. Wer den Bezugsrahmen der Beteiligten versteht, kann ihnen auch mit deren Worten Entscheidungen bzw. Konsequenzen erklären. Wenn alle Stricke reißen, zeigt der Softwarearchitekt den Weg auf, wie ein Konflikt gelöst wird oder sich eine Entscheidung auswirkt.

Gernot Starke: Kompromisse finden gehört zu unseren wesentlichen Aufgaben: Kompromisse zwischen Leistung und Kosten, zwischen Speicherplatz und Performance, zwischen Komplexität und Flexibilität. Und eben auch Kompromisse zwischen unseren vielen Stakeholdern – damit am Ende eine für alle Beteiligten gute Lösung entsteht.

Stefan Tilkov: Normalerweise wollen Business und Entwicklung ja am Ende doch das Gleiche, auch wenn sie sich dessen oft nicht so bewusst sind. Der eine wirft dem anderen vor, die falschen Prioritäten zu setzen, und mal hat der eine und mal der andere Recht. Auch hier hilft diplomatisches Geschick, um mal den einen und mal den anderen zum Nachgeben zu bewegen.

JAXenter: Welche Erfahrungen braucht man darüber hinaus noch? Wie gut muss man die Entwickler- bzw. die Fach- oder Businessseite kennen?

Phillip Ghadir: Je besser man seine Pappenheimer kennt, desto besser kann man sie bewegen. Je besser man die Domäne kennt, desto besser werden die Konzepte. Je besser man die Technologien kennt, desto besser wird die Umsetzung. Aber allein das genügt noch nicht. Dazu gehören das Vertrauen und der Willen, jedes Hindernis im Rahmen des Projekts zu überwinden.

Gernot Starke: Architekten sind auch Dolmetscher – zwischen den Sprachen von Business, Technik, Test und Betrieb, zwischen Management und Geeks, zwischen kurzfristigen und langfristigen Zielen. Richtig, das kann manchmal etwas aufreibend sein. 🙂

Stefan Tilkov: Man muss auf jeden Fall bereit sein, sich mit allem auseinanderzusetzen – ein Architekt, der kein Interesse an und kein Wissen über die fachliche Domäne aufbaut, wird nie zu einem guten System beitragen. Aber auch das technische Wissen, in eigentlich allen Fällen in Form von früher oder immer noch praktizierter Entwicklertätigkeit, ist absolut unabdingbar.

Geschrieben von
Mirko Schrempp
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.