Liebe Leserinnen, liebe Leser,

„The right thing at the right time, even before you ask for it“ – Dieser Satz, der am 15. Mai während der episch langen Google-I/O-Keynote fiel, bringt den übergreifenden Servicegedanken des Nicht-mehr-nur-Suchmaschinenriesen auf den Punkt. Die auf der hauseigenen Konferenz vorgestellte Technologie, so betonten die Akteure immer wieder, soll dem Nutzer immer einen Schritt voraus sein – und gerade dadurch in den Hintergrund treten. Überwiegen soll letztlich das Nutzererlebnis. Das gilt für das reanimierte Google+, dessen neues Feature „Auto Awesome“ stilsicher neue Fotos und Animationen aus bestehendem Bildmaterial generiert. Es trifft aber auch auf die schicke neue IntelliJ-IDEA-basierte Android-Entwicklungsumgebung Android Studio zu. Die ermöglicht z. B. ein Echtzeit-Rendering der Layouts auf unterschiedlichen Device-Größen.

Auf manch einen mag diffus gewirkt haben, was der Konzern seit seiner Gründung Jahr für Jahr an Projekten und Services lanciert und wieder beerdigt hat: Google Wave, Google Gears, Google Health etc. Daneben gab und gibt es humanitäre und Schulprojekte oder das geheimnisumwitterte Forschungslabor Google X, das an verwegenen „Moonshot“-Projekten bastelt. Es herrscht also eine hohe Fluktuation im Googleversum. Obendrein wird ganz bewusst auf interne Konkurrenz gesetzt: AngularJS vs. GWT oder die parallele Weiterentwicklung der Plattformen Android und Chrome.

Konkurrenz unter dem eigenen Dach kann sich der Konzern auch durchaus leisten. Denn was die Google-Welt im Innersten zusammenhält, sind nicht einzelne Softwarekomponenten oder Plattformen. Die Vision ist vielmehr das, was Shel Israel und Robert Scoble gerade in ihrem neuen gemeinsamen Buchprojekt mit dem Arbeitstitel „The Age of Context“ thematisieren: Es geht darum, gesammelte Geokontakt- und sonstige Userdaten sinnvoll zusammenzuführen und daraus gängige Verhaltensmuster in praktisch allen Lebenssituationen des Nutzers abzuleiten. „Semantisch“ klingt da fast schon zu niedlich – nicht weniger als „the end of search as we know it“ kündigte Senior Vice President Amit Singhal während der Keynote an.

Diese Rechnung geht natürlich nur auf, wenn sich der Nutzer mit dem Prinzip „Geben und Nehmen“ anfreunden kann und ebenso bereitwillig wie die Google-Mitarbeiter auf der Keynote-Bühne Details über seine privaten Gewohnheiten und sein soziales Umfeld offenbart. Denn je mehr Informationen der Nutzer Googles Daten-Backend anvertraut, desto mehr werden er und andere von den Services profitieren. Stellt sich die Frage, ob auch sensiblere Daten, medizinische etwa, großzügiger preisgegeben werden dürfen. Wenn es nach Larry Page ginge, schon. Der sagte in der Fragestunde am Ende der Keynote mit seiner heiseren, angeschlagenen Stimme, er frage sich, weshalb der Gesundheitssektor eigentlich so viel Wert auf Geheimhaltung lege – Worte, die Datenschützer zum Hyperventilieren bringen dürften. Und genau hier stößt die Google-Vision derzeit noch an ihre Grenzen: Eine umfassende Vernetzung von Services erfordert eine engere Zusammenarbeit zwischen Servicedienstleistern und Technologieherstellern. Alle anderen müssen mitziehen, tun es bislang aber nur zögerlich. Dieser Aspekt dürfte wohl auch Pages Seitenhiebe auf Microsoft und Oracle während der Keynote motiviert haben. Entgegen der alten Kaufmannsweisheit, dass Konkurrenz das Geschäft belebt, fordert der Google-CEO weniger Wettbewerb und mehr Kollaboration. Bloß: Wer übernimmt in diesem Datenorchester das Dirigierpult? Fest steht: Mit seiner Meisterdisziplin, den hausgemachten Suchalgorithmen, hat das Unternehmen aus Mountain View die Grundlagen für das Zeitalter des Kontexts erst geschaffen. Es wird sich seine Pole Position nicht so leicht streitig machen lassen.

Viel Spaß beim Lesen dieser Ausgabe – zur richtigen Zeit am richtigen Ort, versteht sich! – wünscht Ihnen!

Scrum kennt die Rollen Product Owner, Scrum Master und Entwickler, aber nicht die Rolle „Architekt“. In einer klassischen Teamhierarchie wird die Softwarearchitektur allein durch den Architekten verantwortet. Im selbstorganisierten Scrum-Entwicklungsteam dagegen gibt es keine Rangfolge, und die Entwickler sind gleichberechtigt. Wie entsteht die Softwarearchitektur in einem Scrum-Team im Unterschied zur traditionellen Methodik?

Im sequenziellen und dokumentorientierten Vorgehen des Wasserfallmodells entsteht eine Softwarearchitektur als Big Design Up Front (BDUF). Eine solche klassische Architektur, die in einer frühen Projektphase nach der Anforderungsanalyse entworfen wird, hat den Anspruch, vollständig und ausgereift zu sein – quasi in Stein gemeißelt. Als Hauptmotivation für die Erstellung einer umfangreichen und detaillierten Dokumentation vor dem Start der Implementierungsphase gilt die Möglichkeit, Fehler oder Lücken in der Anforderungsspezifikation zu einem Zeitpunkt zu erkennen, zu dem sie sich noch relativ kostengünstig beseitigen lassen.

Die Vorgehensweise bei der Anwendung des Wasserfallmodells hat den Begriff des Elfenbeinturmarchitekten geprägt. Fernab vom Entwicklungsteam und -geschehen entwerfen solche Architektur- und Dokumentationsspezialisten detaillierte Modelle und Prozesse, die sie am Ende der Entwurfsphase präsentieren und den häufig zu Codeknechten degradierten Entwicklern zur Implementierung übergeben, ohne dass diese effektiv Gelegenheit gehabt hätten, an wesentlichen Designentscheidungen mitzuwirken.

Klassische Softwarearchitektur – untauglich in der Anwendung

In der Praxis stellt sich oft schnell heraus, dass eine nahezu komplett vor der Implementierungsphase entstandene Architekturbeschreibung das bleibt, was sie ist: graue Theorie. Die Gründe hierfür sind vielfältig:

• Die Anforderungen an die Software ändern sich ständig: sowohl vor, während als auch nach der Entwicklungsphase. Häufig setzt der Erkenntnisprozess des Auftraggebers erst dann ein, wenn die Software zum ersten Mal ausgeliefert wird. Das BDUF-Paradigma trägt diesem Umstand nicht Rechnung.

• Entwickler billigen nur widerstrebend Designentscheidungen, an denen sie nicht mitwirken durften. Je größer die Codeferne des Architekten, desto geringer das Maß an Akzeptanz.

• Entwickler hegen eine ausgeprägte Aversion gegen aufgeblähte Dokumentationen.

• Technische Probleme werden in der Regel nicht ohne Prototypen oder technische Durchstiche erkannt. Architekten, die nicht auf Augenhöhe mit dem Entwicklungsteam arbeiten und selbst implementieren, gehen daher oft von falschen Annahmen aus. Dadurch steigt das Projektrisiko erheblich.

• Vollständigkeit oder hoher Detaillierungsgrad einer Architektur sind keine Zeichen von Qualität. Die verfügbare Informationsmenge über System und Kundenanforderungen wächst mit der Projektdauer. Die Wahrscheinlichkeit ist daher hoch, trotz umfangreicher Entwurfsdokumentation wesentliche Features oder Randbedingungen nicht erfasst und andererseits einen Overkill an komplexen Metamodellen ohne Geschäftswert erstellt zu haben.

Wie lang haben Sie das letzte Mal gebraucht, um festzustellen, dass sich eine vorgegebene Entwurfsentscheidung nicht ohne Anpassungen in die Praxis umsetzen ließ? Es ging vermutlich schnell. Der bekannte Softwarearchitekt Dr. Starke schreibt hierzu [1]: „Wenn Sie glauben, dass Ihre Architektur gut ist, so haben Sie diese noch niemandem gezeigt.“ Spätestens im Gespräch mit dem Kunden kommen Verbesserungsvorschläge auf. Gute Architekturen entstehen eben nicht im Zeitraum zwischen Anforderungsanalyse und Implementierung – und schon gar nicht im Elfenbeinturm.

Und dann kam Scrum

Scrum brachte Product Owner und Scrum Master ins Team, schaffte die Rolle des technischen Teamleiters und Projektmanagers ab und änderte Aufgabenstellung und Position des Analysten, Entwicklers, Testers – und des Architekten. Zwei wesentliche Aspekte beschreiben diesen Wandel:

• Die Teammitglieder finalisieren Aufgaben nicht mehr im Vorwege oder zu festen Terminen, sondern iterativ im Zuge der Sprints. Komponentenmodelle etwa werden nicht komplett in einem Sprint 0 abgeschlossen, sondern bei Bedarf erstellt oder verfeinert. Genauso wenig finden Tests nur am Ende eines Sprints oder kurz vor dem finalen Release statt, sondern während der Entwicklung. Dabei erhöht jeder Sprint den Funktionsumfang und den Geschäftswert des Produkts.

• Das Produkt entsteht inkrementell. Am Ende eines jeden Sprints steht dem Kunden eine lauffähige und potenziell nutzbare Version zur Verfügung, sodass Fehlentwicklungen frühzeitig erkannt und korrigiert werden können.

Scrum-Teams sind interdisziplinär ausgerichtet, selbstorganisiert und „verfügen über alle Kompetenzen, ihr Arbeitsergebnis zu erreichen, ohne dabei von anderen abhängig zu sein, die nicht Teil des Teams sind“ [2]. Der Architekt als einer der Spezialisten – so wie es mit Test-, GUI- oder Datenbankexperten üblicherweise noch weitere unter den Entwicklern gibt – ist Teil des funktionsübergreifenden Teams.

Eine Ausnahme können kleinere Scrum-Projekte darstellen, in denen die Aufgaben eines Architekten manchmal von den Entwicklern mit übernommen werden, ohne dass es einen expliziten Architekten gibt. Der Fokus dieses Artikels liegt auf mittelgroßen agilen Projekten mit ca. fünf bis zehn Teammitgliedern. In solchen Teams wird in der Regel ein Architekt benötigt, der eine architektonische Vorstellung des Produkts besitzt und sich um die Einheitlichkeit und Gleichförmigkeit der Lösung kümmert.

Spezialisten und Generalisten

Ein Wort noch zu „Spezialisierung versus Generalisierung in Scrum“, da diese Frage in Projekten oder im Internet mitunter kontrovers diskutiert wird.

Im agilen Manifest wird das Individuum in den Vordergrund gerückt [3] und damit die Verschiedenheit und Eigenart der Entwickler betont. Weder fordert Scrum Generalisten noch verneint es die Existenz von Spezialisten wie dem Architekten: Das wäre auch unnatürlich in einer Branche, in der ständig Entwickler mit unterschiedlichstem Fachwissen zusammenarbeiten, um ein oft technologisch und fachlich hochkomplexes Produkt zu realisieren.

Allerdings verschwimmen die Grenzen des Spezialistentums in Scrum, und das Verhältnis von Spezialisten zu Generalisten wird neu austariert. Die Arbeitsweise ist nicht mehr nur auf die jeweilige Spezialdomäne fokussiert: Zur Erreichung des gemeinsamen Sprint-Ziels „muss jeder Einzelne dazu bereit sein, gelegentlich auch Arbeiten außerhalb seines Spezialgebiets zu verrichten“ [4]. Von Experten wird dabei erwartet, dass sie dem Rest des Teams auf Augenhöhe begegnen. Vielen Entwicklern kommt die von Scrum geforderte Bereitschaft zur Veränderung entgegen, da sie so ihre Kenntnisse auffrischen und um Spezialwissen aus anderen Bereichen erweitern können – und diese Art der Weiterbildung bereits integraler Bestandteil des Prozesses ist.

Unterschiede zwischen agiler und klassischer Architektur

Aus den Scrum-Paradigmen, insbesondere dem iterativen und inkrementellen Vorgehen, der Fokussierung auf die Erreichung des Sprint-Ziels und den dafür zu erledigenden Aufgaben ergeben sich erhebliche Unterschiede zur traditionellen Methodik des Architekten während der Entwurfsphase des Wasserfallmodells:

• In Scrum wird die Architektur von Sprint zu Sprint kontinuierlich weiterentwickelt. Der Architekt trifft Entscheidungen grundsätzlich termingerecht im „last responsible Moment“, also zu einem Zeitpunkt, zu dem das Nichtentscheiden zum Wegfall von Alternativen führt. Dahinter verbirgt sich der Gedanke, dass man sich durch eine später getroffene Entscheidung länger Optionen offenhält und die Informationsmenge im Moment der Entscheidung größer ist. Dies erhöht die Wahrscheinlichkeit, dass der gewünschte Nutzen auch tatsächlich eintritt.

• Agile Architektur ist keine Spielwiese modellierungs- und abstraktionswütiger Architekten für gegenwärtig noch nicht benötigte Funktionalität. Das Overengineering des Produkts durch übermäßige Generalisierung hat als Ursache die Annahme, zukünftige Anforderungen vorhersehen zu können. Die Erfahrung zeigt, dass selbst, wenn später eine Beauftragung erfolgt, in der Regel die Anforderung nicht exakt der ursprünglichen Hypothese entspricht und der vorgesehene Code geändert werden muss. Bis dahin erzeugt der Code Kosten durch zusätzlichen Wartungsaufwand. Daher werden beim agilen Architekturentwurf zukünftige Änderungen zwar berücksichtigt, allerdings nur in dem Maße, in dem der Erweiterbarkeit und Änderbarkeit des Produkts Sorge getragen wird. Konkrete Entwicklungsmaßnahmen wie zusätzliche Interfaces, abstrakte Factories oder weitere Vererbungshierarchien werden daraus nicht abgeleitet.

• Der Architekt arbeitet in Scrum entwicklungsnah und besitzt bestenfalls eine „Hands-on“-Mentalität. Die Fähigkeit zu modellieren, zu dokumentieren und ein paar Schlüsseltechnologien zu kennen, reicht nicht aus. Ein Architekt muss in der Lage sein, Prototypen oder Durchstiche als Grundlage technischer Konzepte zu implementieren und seine Entwurfsentscheidungen im Team zu kommunizieren. Darüber hinaus ist er für die Auswahl und Zweckmäßigkeit von Technologien und Frameworks maßgeblich verantwortlich. In einem größeren Team mit mehr als zehn Entwicklern hat der Architekt zwar weniger Gelegenheit, selbst Quellcode zu schreiben. Nichtsdestotrotz sollte er sich die Fähigkeit erhalten, Sourcecode oder Prototypen zu bewerten. Für einen bislang schon technikaffinen und aufgeschlossenen Architekten ändert sich durch Scrum nicht viel; andere Architekten dagegen werden wieder mehr technische Bodenhaftung gewinnen müssen, um Respekt und Vertrauen im Team zu genießen.

• Zentrale Anforderungen an die Architekturdokumentation in Scrum sind Kompaktheit, Pflegbarkeit, Aktualität und Verständlichkeit. Die Beschreibung der Architektur enthält alle nötigen Informationen, die für das Verständnis des Systems relevant sind – mehr nicht. Insbesondere erhebt sie keinen Anspruch auf Vollständigkeit, was die Darstellung von Systemdetails betrifft: Softwarearchitektur dokumentiert die grundlegendsten Aspekte der Software, keinen Quellcode. Eine kostenfreie und gut dokumentierte Vorlage, an der Sie sich orientieren können, ist arc42 [5].

• Die Architektur wird nicht erst kommuniziert, wenn sie weit genug fortgeschritten ist, sondern bereits, während noch an ihr gearbeitet wird, um zeitnahes Feedback einholen zu können und so das Projektrisiko zu reduzieren.

Architekt und Entwickler

In agilen Projekten sind Architekt und Entwickler gleichberechtigte Teammitglieder. Damit das funktioniert, benötigen die Entwickler im agilen Team ein Bewusstsein für Architektur. Nicht nur müssen sie die Konsequenzen der Architekturentscheidungen beurteilen und alternative Lösungswege bewerten können, sondern auch wesentliche Architekturmuster, Design-Patterns und Architekturprinzipien kennen und bei Bedarf einsetzen können. Know-how-Transfers, zum Beispiel in Form von Trainings-Sessions des Architekten, sind ein probates Mittel, um Wissenslücken zu schließen.

Weder ist der Softwarearchitekt nur für die Systemstrukturen und Entwurfsentscheidungen zuständig, noch das Entwicklungsteam ausschließlich für die Umsetzung. Durch den Rückkopplungsprozess des Softwarearchitekturentwurfs wirken auch die Entwickler maßgeblich an der Architektur mit. Der Architekt trifft globale Entscheidungen, erfährt als Mitglied des Entwicklungsteams, welches Design daraus auf tieferer Ebene entsteht und überprüft kontinuierlich, ob sich die Auswirkungen im Einklang mit den funktionalen und qualitativen Anforderungen des Kunden befinden. Gegebenenfalls passt er die Architektur den Erfordernissen entsprechend an. Der Architekt lässt den Entwicklern genügend Freiheitsgrade und engt sie nicht bei ihren operativen Tätigkeiten ein, sodass sie ihre Kreativität bei der Architekturumsetzung entfalten können. Das elfte agile Prinzip schreibt der Selbstorganisation des Teams entscheidende Bedeutung in Bezug auf die Qualität der Architektur zu [6]: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“

Neben einem Collective Code Ownership entsteht ein Collective Architecture Ownership und damit ein gemeinsames Verantwortungsbewusstsein für den Code, seine Qualität, die wesentlichen Strukturen und Konzepte. Architektur als Teamangelegenheit wird auf diese Weise leichter akzeptiert oder mit größerem Selbstverständnis hinterfragt, als wenn sie das Resultat der Arbeit eines Einzelnen wäre. Meines Erachtens lässt sich die Evolutionsstufe des Teams am besten an der kontinuierlich kritischen Auseinandersetzung mit den Strukturen der Software ablesen.

Obwohl sich Entwickler und agiler Architekt stark annähern, sind sie in ihrer Rolle doch nicht gleich. Die Vorgehensweise des Architekten ist grundsätzlich strategischer geprägt als die des Entwicklers. Der Architekt hat einen ganzheitlichen Blick auf das System und eine Vision der Lösung, die er gegenüber den Projektbeteiligten überzeugend vertreten kann.

Der Architekt ist Kommunikator im Team. Er sollte in der Lage sein, zwischen Entwicklern, Product Owner, Managern und anderen Interessengruppen zu vermitteln. Er kommuniziert die Architektur nicht nur schriftlich, sondern auch mündlich, ganz im Sinne des sechsten agilen Prinzips [6]: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“ Sprint-Planungs- und Review-Meetings sind das Forum in Scrum, um mit dem Entwicklungsteam über die Systemarchitektur zu diskutieren und sich auf ein gemeinsames Vorgehen zu verständigen.

Die Verbindung von fachlichem und technischem Wissen mit sozialer Reife und Kommunikationsgeschick stellt hohe Anforderungen an den Architekten. Einen solchen Spezialisten als Verfechter der Qualität des Systems und als Bollwerk gegen „Quick and Dirty“-Entwürfe an Bord zu haben, bringt meiner Erfahrung nach häufig das ganze Team einen entscheidenden Schritt in der zielorientierten Entwicklung eines hochwertigen Produkts voran.

Kein demokratischer Prozess

Auch in Scrum ist Softwarearchitektur kein demokratischer Prozess, sondern richtet sich strikt nach funktionalen und nicht funktionalen Kundenanforderungen sowie wirtschaftlichen Unternehmenszielen. Bei divergierenden Auffassungen im Entwicklungsteam, die etwa während der Sprint-Planung entstehen, ist es Aufgabe des Architekten, eine Entscheidung herbeizuführen. Im Zweifel entscheidet er. Auch bei geographisch verteilten Teams gibt es in der Regel mit dem Chefarchitekten eine Instanz, die festgefahrene Diskussionen aufzulösen vermag.

Sollten Sie erleben, dass für Architekturentscheidungen ein Arbeitskreis oder Komitee gebildet wird, so ist dies oft ein Zeichen für die Schwäche des agilen Prozesses (und möglicherweise des Architekten). Versuchen Sie, mit den in Scrum üblichen Ereignissen auszukommen und suchen Sie die direkte Kommunikation während eines Sprints zur Klärung grundlegender aktueller Fragestellungen. Regelmäßige Architekturarbeitskreise dienstags um 11 Uhr bergen die Gefahr, dass strukturelle und technische Aspekte endlos ohne Vision und Ziel, unpriorisiert und ohne Bezug zum Sprint diskutiert werden und sich am Ende Mittelmaß, Banalität oder überbordende Komplexität durchsetzen. Im Übrigen: Kennen Sie einen Entwickler, der tatsächlich mit seinen Fragen auf das Tagen eines Arbeitskreises warten würde?

Architekt und Product Owner – eine Symbiose

Nicht nur das Verhältnis zu den Entwicklern, sondern auch die Zusammenarbeit mit dem Product Owner ist für die Tätigkeit des Architekten bestimmend. Ein guter Architekt besitzt viele der Fähigkeiten und Eigenschaften eines kompetenten Product Owners. Beide haben Mut zur Entscheidung, sind kommunikativ, im Team respektiert und verfügen über breites Domänenwissen. Ihr Aufgabengebiet allerdings ist nicht deckungsgleich:

• Der agile Architekt arbeitet deutlich technik- und entwicklungsnaher als der Product Owner – was aber nicht heißt, dass der Product Owner nicht zumindest über so viel technisches Wissen verfügen sollte, wie er benötigt, um die Auswirkungen von Kundenanforderungen grob einschätzen zu können.

• Der Product Owner vertritt die Produktvision, der Architekt das technische Leitbild.

• Der Product Owner ist maßgeblich für die Wirtschaftlichkeit des Projekts verantwortlich, beobachtet das Marktumfeld und analysiert Chancen und Risiken.

• Der Architekt fungiert als Bindeglied zwischen den Projektbeteiligten und spricht sowohl die Sprache des Kunden als auch die der Entwickler. Der Product Own­er ist mehr noch als der Architekt nach außen gewandt und die Schnittstelle zum Auftraggeber.

• Während der Product Owner maßgeblich Einfluss darauf hat, was in einem Sprint getan wird und das Entwicklungsteam entscheidet, wie die resultierenden Tasks technisch umgesetzt werden, bewegt sich der Architekt in beiden Welten.

Product Owner und Architekt haben in Ausübung ihrer Tätigkeit diverse Nahtstellen und ein ähnliches Gespür für Strategien und Systeme, weshalb sie sich in der Regel gut ergänzen. Unter anderem ergeben sich wesentliche Berührungspunkte bei der Erstellung und Pflege des Product Backlogs, eine der zentralen Verantwortlichkeiten des Product Owners:

• Zu Projektbeginn haben Architekten mit ihrem fundierten technischen und fachlichen Know-how eine ausgeprägte beratende Funktion und treffen zusammen mit Product Owner und Entwicklungsteam initiale High-Level-Entscheidungen zur Umsetzung der noch grobgranularen Anforderungen im Product Backlog. Die Festlegung der grundlegenden Lösungsstrategie trägt dazu bei, den noch hohen Grad an Unsicherheit zu reduzieren, die Komplexität der Lösung einschätzen und eine erste Priorisierung vornehmen zu können.

• Im Projektverlauf unterstützt der Architekt den Product Owner bei der Pflege („Grooming“) des Product Backlogs, insbesondere, was die Aufnahme nicht funktionaler Anforderungen wie Performance, Sicherheit oder Erweiterbarkeit sowie technische Tasks wie Refactorings oder die notwendige Einführung einer neuen Technologie betrifft. Gerade die nicht funktionalen Aspekte gehören zur Domäne des Architekten und haben oft erheblichen Einfluss auf die Architektur. Ihre Auswirkungen und Risiken zu verdeutlichen ist Aufgabe des Architekten.

• Mitunter beeinflussen sich solche Qualitätsanforderungen gegenseitig. Zum Beispiel entstehen durch Performanceoptimierungen häufig Speziallösungen, die die Gleichförmigkeit des Codes beeinträchtigen und durch ihre Komplexität die Wartbarkeit der Software erschweren. Der Architekt ist dem Product Owner dabei behilflich, sich widersprechende Anforderungen zu identifizieren, sie gegeneinander abzuwägen und zusammen mit dem Kunden nach einer Lösung zu suchen.

Trotz aller Zusammenarbeit und Gleichartigkeit der Kompetenzen existiert zwischen Product Owner und Architekt ein (hoffentlich!) konstruktives Spannungsverhältnis: Der Product Owner hat vor allem das schnelle Delivery möglichst vieler User Stories im Blick, der Architekt die Qualität des auszuliefernden Produkts. Erfahrungsgemäß ist dieser vermeintliche Gegensatz Ursache zahlreicher Diskussionen, sobald im Projektverlauf der Terminplan eng oder das Budget knapp wird.

Es wird mitunter die Frage diskutiert, ob nicht zusätzlich zum Product Owner ein technischer Product Owner (TPO) für die technischen Stories zuständig sein sollte. Meiner Meinung nach ist „TPO“ nur ein anderer Name für den Architekten, der allerdings suggeriert, dass der TPO außerhalb des Entwicklungsteams steht – im Gegensatz zum agilen Architekten.

Fallstrick

In der engen Zusammenarbeit von Product Owner und Architekt lauert die Gefahr, dass der Product Owner bei Angelegenheiten des Entwicklungsteams regelmäßig dem Architekten das letzte Wort einräumt bzw. seine abschließende Stellungnahme einfordert. Dies lässt innerhalb des Scrum-Teams eine Hierarchie entstehen, die schnell dazu führt, dass sich Entwickler übergangen und bevormundet fühlen und als Konsequenz die von ihnen verlangte Mitverantwortung für die Softwarearchitektur verweigern. Um dies zu vermeiden, sollte der Product Owner Mut zur eigenen Entscheidung haben und Vertrauen zum Entwicklungsteam aufbauen. Bei Entscheidungen mit erheblicher Tragweite ist ohnehin die Kompetenz eines größeren Personenkreises gefragt.

Zusammenfassung

Auch Scrum-Projekte benötigen einen Architekten. Dabei ist der Architekt – anders als bei klassischem Vorgehen – Teil des Entwicklungsteams. Im Bewusstsein, dass Irren menschlich ist und daher Architekturentscheidungen idealerweise durch Prototypen oder Durchstiche untermauert werden und Feedback benötigen, beteiligt sich der Architekt an der Umsetzung und überprüft die Praktikabilität der Lösungsansätze regelmäßig in Rücksprache mit den Teamkollegen. Seine Architekturdokumentation entsteht inkrementell von Sprint zu Sprint, steht dem Team jederzeit zur Verfügung, vermeidet die antizipierende Planung zukünftiger potenzieller Anforderungen und beschränkt sich auf das Hier und Jetzt. Der Elfenbeinturm ist neu zu vermieten.