Eine gut funktionierende Architekturtruppe

Das habe ich mich schon oft gefragt: Was macht eine gut funktionierende Architekturtruppe aus? Holger Wolff zählt in seinem Artikel im OBJEKTspektrum Nr. 1 2010 viele Punkte auf, die ich wirklich passend und gut finde.



"Eine gut funktionierende Architekturtruppe

• nist nicht überheblich, obwohl sie weiß, dass sie durch ihre umfassende Kenntnis von übergreifenden Geschäftsprozessen eine erhebliche Machtstellung hat,
• ndrängt sich nicht nach jeder Aufgabe und versucht nicht, ein Monopol auf das Erbringen von IT-Leistungen zu errichten,
• nsetzt dennoch konsequent Rahmenbedingungen unter dem Gesichtspunkt von Gesamtarchitektur, Betriebssicherheit, Dokumentationsgrad und Schnittstellenkonformität,
• nbehält die Zügel in der Hand, indem sie die Freiheitsgrade an die nachgewiesene Professionalität der unterschiedlichen Projektteams anpasst,
• nhilft den Projekten beim Aufbau kompetenter Teams mit technischem Wissen und unterhält zu diesen eine partnerschaftliche, kollegiale Beziehung. " 

Die Aufzählung ist deswegen Klasse, weil es ganz wesentliche Aspekte anspricht:

• Macht kommt mit Demut und Verantwortung
• wir wollen nicht zum Nabel der Welt werden
• wir sind klar in unseren Zielen, die wir konsequent verfolgen
• wie sehr wir gebraucht werden, hängt von dem Know-How im Projekt ab
• wir übertragen unser Know-How gerne
• wir bauen partnerschaftliche, auf Wertschätzung basierende, Beziehungen auf
• wir bewerten ein Architekturziel nicht höher als eine funktionierende Beziehungen 

Auch Peter Kruchten schreibt in seinem TAO für den Software-Architekten einiges zu dem Thema.

Was meint Ihr dazu? Wann funktionieren Architekturteams, und wann nicht?