Serie: Wie tötet man die Architekturabteilung? Teil 2

Teil 2: Wo ist der Mitarbeiter, der früher als Architekt bekannt war?

Das agile Organisationsmodell

Im ersten Blogbeitrag dieser Serie hat Adriaan ein Referenzmodell für agile Organisationen beschrieben. Mit anderen Worten: wie eine Idee in Geld umgewandelt werden kann. Eine Idee wird zusammen mit allen anderen Ideen nach Prioritäten geordnet. Dann wird sie geplant, und danach wird die Idee in Epen, User Stories und Aufgaben unterteilt. Am Ende wird die funktionierende Software in die Produktion überführt. In diesem Prozess spielen die Product Owner eine Schlüsselrolle. Sie koordinieren den Prozess, damit die Ideen priorisiert und die User Stories fertiggestellt werden. Ihr Hauptaugenmerk liegt auf dem Geschäftswert. Aber was ist mit all den technischen Funktionen und Aspekten? Diese technischen Funktionen und Aspekte sind das Thema dieses Blogbeitrags.

Fokus auf geschäftliche Funktionalität

Bei dem im vorigen Absatz beschriebenen Prozess liegt der Schwerpunkt häufig auf der Geschäftsfunktionalität. Der allgemeine Grund dafür ist, dass Product Owner Mitglieder einer Geschäftsabteilung sind und daher weniger Affinität zu technischen Aspekten haben. Ein zweiter Grund ist, dass technische Beteiligte wie die Betriebsabteilung nicht immer als Beteiligte anerkannt werden. Und ein dritter Grund könnte sein, dass die technischen Stakeholder nicht in der Lage sind, den Product Ownern den geschäftlichen Wert oder den Bedarf an technischen Änderungen zu erklären. Infolgedessen erhalten notwendige technische Änderungen weniger oder keine Priorität. Die Folge sind technische Schulden, die nur mit großem Aufwand beseitigt werden können, wenn sie notwendig werden.

Wie können technische Änderungen mehr Priorität erhalten?

Um technischen Änderungen mehr Priorität einzuräumen, wird eine Person benötigt, die in der Lage ist, den (leitenden) Product Ownern den Wert dieser Änderungen zu erklären. Gleichzeitig bleibt die Systemarchitektur von entscheidender Bedeutung. Dafür brauchen wir immer noch jemanden, der einen Überblick über die IT-Landschaft, die Softwarearchitektur usw. hat. Jemanden, der versteht, welche Auswirkungen neue Funktionen auf den Technologie-Stack haben können. Und der in der Lage ist, den Dialog zwischen den Beteiligten und dem Product Owner zu unterstützen. Was wir brauchen, ist jemand, der für alle technischen Aspekte der Anforderungen und der Software verantwortlich ist, genau wie der Product Owner für die funktionalen Aspekte: ein Technical Product Owner (TPO).

Ein was...?

Ein Technical Product Owner ist für alle technischen Aspekte bei der Erstellung von Software verantwortlich, vom Konzept bis zur Bezahlung. In diesem Satz liegt die Betonung auf Verantwortung. Was soll das bedeuten? Wo ein traditioneller Architekt an der Seitenlinie steht, sollte ein TPO mitten im kreativen Prozess stehen und sich für alle technischen Aspekte der Softwareentwicklung verantwortlich fühlen: die Art und Weise, wie sowohl funktionale als auch nicht-funktionale Anforderungen umgesetzt werden, ob es sich um ein Datenbank-Upgrade handelt oder um eine völlig neue Architektur, um für weitere Geschäftsanforderungen gerüstet zu sein. Viele traditionelle Architekten schreiben den Entwicklern vor, was sie zu tun haben und wie sie es tun sollen. Das funktioniert in einem agilen Prozess nicht, da nicht alle Anforderungen im Voraus festgelegt werden und die Teams ermutigt werden, ihre eigenen Entscheidungen zu treffen. Der formell als Architekt bekannte Mitarbeiter sollte daher als Product Owner, als technischer Product Owner, fungieren. Er sollte die geschäftlichen Anforderungen mit dem Product Owner besprechen, diese analysieren und die Optionen erläutern. Andererseits muss er in der Lage sein, die Notwendigkeit bestimmter technischer Änderungen zu erklären.

Wie sind die technischen Produktverantwortlichen organisiert?

Die Entwicklung von Software ist eine Teamleistung und eine Teamverantwortung. Die Architektur ist ein Teil davon. Aber das kann nicht immer von einer Person abgedeckt werden. Um z.B. Ideen zu priorisieren, brauchen Sie mehr politische und weniger technische Fähigkeiten als für die Aufteilung von Epen in User Stories, besonders in einem großen Unternehmen. Bei der Umsetzung von Ideen ist es genau umgekehrt.Um User Stories BEREIT zu machen, unterstützt ein technischer Product Owner einen Product Owner. Ich schreibe absichtlich assistieren, denn der Product Owner bleibt für das Produkt verantwortlich. Der Grund dafür ist, dass es letztendlich der geschäftliche Wert ist, der implementiert werden muss. Notwendige technische Änderungen, von einem Datenbank-Upgrade bis hin zu einer großen architektonischen Änderung, müssen daher einen geschäftlichen Wert haben. Genau wie ein Team von Product Ownern kann auch ein Team von TPOs von einem Chief Technical Product Owner (CTPO) geleitet werden. Dieser CTPO unterstützt den Chief Product Owner dabei, Ideen zu PRIORISIEREN. Je nach Umfang der Arbeit kann dies von einer spezialisierten Person oder von einem der TPOs übernommen werden. In der DONE-Phase gibt es keinen separaten Product Owner, aber ein TPO-ähnlicher technischer Leiter existiert bereits: der Senior Software Engineer. Er übernimmt die Führung bei der Umsetzung der User Stories DONE. Dasselbe gilt für PRODUCTION. Auch in Operations gibt es keinen Product Owner. Aber für die technischen Aspekte gibt es einen Senior Operations Engineer. Diese vier technischen Leiter arbeiten zusammen und arbeiten eng mit den (Chief) Product Ownern zusammen. Es mag den Anschein haben, dass diese vier Aufgaben von verschiedenen Personen wahrgenommen werden. Aber das ist nicht unbedingt der Fall. Je nach Art der Organisation, Größe des Projekts oder Programms und den erforderlichen Fähigkeiten können alle diese Rollen von einer Person übernommen werden.

Bleiben Sie dran für die nächste Folge von How to Kill the Architecture Department

In den nächsten vier Beiträgen werden diese technischen Leiter in allen Phasen vom Konzept bis zur Kasse besprochen. Beginnen werden wir mit dem Chief Technical Product Owner. In welchem Verhältnis steht er zum Chief Product Owner und dem Technical Product Owner? Und wie kann er die technischen Interessengruppen vertreten? Bleiben Sie dran...

Mehr aus dieser Serie

    
How to Kill the Architecture Department - Part 1
    
How to Kill the Architecture Department - Part 2
    
How to Kill the Architecture Department - Part 3
    
How to Kill the Architecture Department - Part 4
    
How to Kill the Architecture Department - Part 5
    
How to Kill the Architecture Department - Part 6
    
How to Kill the Architecture Department - Part 7