Architekten & Scrum: 4. Was ist die Rolle des Architekten in Scrum?

In meinem letzten Blog habe ich eine Illustration vorgestellt, die die beiden Hauptaspekte der Rolle der Architekten zeigt. Auf der einen Seite spielen sie eine Rolle bei der Stärkung des Herzschlags. Auf der anderen Seite spielen sie eine Rolle bei der Visionierung der Zukunft. In diesem Blog liegt der Schwerpunkt auf dem Lösungsarchitekten oder Anwendungsarchitekten. Die Art und Weise, wie der Unternehmensarchitekt mit Scrum umgeht, wird in einem späteren Blog ausführlicher behandelt. Was ist die Rolle des Architekten? Im letzten Blog habe ich die untenstehende Illustration vorgestellt. In diesem Blog werde ich mich auf die Teile dieser Illustration konzentrieren, in denen der Lösungsarchitekt / Anwendungsarchitekt eine Rolle spielt Produkt-Backlog Traditionell sind Architekten die Hauptdesigner in der Softwareentwicklung. Projekte beginnen oft mit einem umfangreichen Projektarchitekturdokument, in dem die Lösung mit vielen Worten und viel Papier niedergeschrieben wurde. In der heutigen Scrum-Praxis liegt der Schwerpunkt auf den am höchsten priorisierten Epics und User Stories im Product Backlog. Epics und User Stories sind in der Regel kurz. Die Teams nehmen die Epics und User Stories aus dem Backlog und entwerfen die beste Lösung für sie. Was ist also die Rolle der Architekten in dieser Phase? Tatsächlich spielen Architekten in dieser Phase eine sehr wichtige Rolle, insbesondere in größeren Unternehmen mit vielen Softwaresystemen. Sie besprechen die Anforderungen mit dem Unternehmen und treffen die ersten globalen Designentscheidungen für jedes Epos im Product Backlog im Einklang mit der Gesamtarchitektur. In großen Organisationen mit mehrschichtigen SOA-Architekturen kann die Anzahl der verwendeten Softwarekomponenten sehr hoch sein. Zehn bis zwanzig agile Teams, die an neuen Funktionen arbeiten, sind keine Ausnahme. Architekten treffen die ersten globalen Designentscheidungen, denn sie sind diejenigen, die den Überblick über das Gesamtbild haben. Es müssen Fragen beantwortet werden wie "Brauchen wir zusätzliche Komponenten?", "Passen wir vorhandene Komponenten an?" und "In welcher Schicht der Architektur wollen wir die Änderung umsetzen?" Diese Entscheidungen werden nicht von den Architekten allein getroffen. Sie besprechen sie mit den Produktverantwortlichen, um deren tatsächlichen Bedarf zu ermitteln, und sie besprechen sie mit den agilen Teams, um festzustellen, wie die Software wirklich funktioniert. Die in dieser Phase getroffenen Designentscheidungen werden normalerweise auf nicht mehr als einer halben Seite niedergeschrieben. Wenn dies nicht der Fall ist, könnten sich die Architekten in Details verlieren. Diese Details werden dann in den Teams besprochen. Die Architekten können auch eine erste Einschätzung der Komplexität der Lösung vornehmen, die verwendet werden kann, wenn die Epen von den Teams aufgegriffen werden. Die Architekten helfen dabei, den Kegel der Ungewissheit einzugrenzen. Der Kegel der Unsicherheit beschreibt die Entwicklung der Unsicherheit während eines Projekts. Zu Beginn eines Projekts ist vergleichsweise wenig über das Produkt oder die Arbeitsergebnisse bekannt, so dass Schätzungen mit einem hohen Maß an Unsicherheit behaftet sind. Architekten helfen dem Product Owner, den Grad der Unsicherheit zu verringern. So kann der Product Owner leichter Prioritäten setzen und die Teams können sich auf die spezifische Lösung innerhalb ihres Fachgebiets konzentrieren. Agile Teamarbeit Architekten sind täglich in agilen Teams anwesend. Sie müssen die anstehenden Epics/User Stories in den nächsten Sprints besprechen. Außerdem werden die täglichen Designentscheidungen gemeinsam mit den Teams auf einer niedrigeren Ebene getroffen. Dadurch erhalten die Architekten Feedback zu den positiven und negativen Aspekten der globalen Designentscheidungen, die sie getroffen haben. Architekten ohne Erfahrung in den Teams verlieren den Kontakt zur realen Welt. Architekten haben auch eine wichtige Rolle bei der Überwachung der architektonischen Prinzipien durch alle Schichten der Architektur. Das bedeutet zum Beispiel, dass sie wissen müssen, ob alle Geschäftsregeln innerhalb der Geschäftsschicht implementiert sind oder ob die Kundeninformationen immer in der CRM-Komponente gespeichert werden. Die Mitarbeit im Team kann den Architekten dabei helfen, die Architekturprinzipien praktischer zu gestalten; die Architekturprinzipien entwickeln sich aus der Praxis heraus. Die Architekturprinzipien umfassen auch eher technische Aspekte, wie die Verwendung von Middleware und Hardware. Im Idealfall schließt die "Definition des Erreichten" innerhalb eines Teams die Einführung in die Produktion ein. In dieser Hinsicht ist die DEVOPS-Bewegung in letzter Zeit stärker geworden. Die Architekten können bei Leistungs- oder Sicherheitsfragen beratend tätig werden. Dies bringt diese Aspekte der Softwareentwicklung näher an die Softwareentwickler und -analysten heran. Die Zusammenarbeit in Teams zwischen Entwicklern, Testern, Leistungsspezialisten, Hardwarespezialisten und anderen wird dazu beitragen, neue Ideen zu entwickeln und zu erfassen. Diese neuen Ideen werden vielleicht nicht immer direkt umgesetzt. Neue Ideen können sich auch auf andere Teams auswirken, oder die Neugestaltung der Software erfordert zusätzliche Zeit oder Fachkenntnisse, die dem Team nicht zur Verfügung stehen, so dass das Team die Ideen nicht umsetzen kann. Wie können Architekten also mit diesen Ideen umgehen?

Der Umgang mit Designideen Architekten, die an der Erstellung des Product Backlogs mitwirken und in agilen Teams arbeiten, sind oft sehr mit den täglichen Problemen beschäftigt. Aber es gibt einen zweiten, ebenso wichtigen Teil ihrer Rolle: die Vision der Zukunft. Sie treten aus den täglichen Problemlösungsaktivitäten heraus, um das große Ganze zu bewerten. Welche neuen Ideen sind wünschenswert und möglich? Wie beeinflusst der aktuelle Fortschritt die Gesamtarchitektur? Diese Überlegungen führen zu dem, was wir Design-Ideen nennen. Zunächst einmal können neue Design-Ideen aus der Pflege des Produkt-Backlogs und der Arbeit in den Teams hervorgehen. Es entstehen Ideen für neue Komponenten oder Ideen zur Änderung bestehender Komponenten. Der Schwerpunkt in agilen Teams liegt oft auf der Geschwindigkeit der Lieferung, damit sich das Unternehmen schnell an Veränderungen in seinem Umfeld anpassen kann. Dies ist zwar eine große Stärke von Scrum, aber es macht auch architektonische Mängel sehr wahrscheinlich. Das Redesign von Software wird aus Zeitmangel nicht richtig oder gar nicht durchgeführt. Es ist wichtig, dass diese Unzulänglichkeiten erkannt und als Design-Ideen für zukünftige Sprints aufgeschrieben werden. Eine Design-Idee mit einem validen eigenen Business Case sollte ebenfalls in das Product Backlog aufgenommen werden. Design-Ideen entstehen nicht nur in der Software-Architektur; auch technische und geschäftliche Bereiche sind eine reiche Quelle für Design-Ideen. Die Virtualisierung der Hardware kann viel Geld sparen und die Komplexität reduzieren. Die Einhaltung gesetzlicher Vorschriften erfordert mehr Kontrolle über die Rückverfolgbarkeit. Diese Art von Ideen werden oft von der IT-Abteilung umgesetzt, ohne dass eine direkte Verbindung zu den Geschäftszielen besteht. Diese Designideen sollten jedoch mit den geschäftlichen Anforderungen verknüpft werden und ihren Weg in das Product Backlog finden. Falls erforderlich, können neue agile Teams gebildet werden, die von den Product Ownern mit Hilfe der Architekten geleitet werden, um die Umsetzung dieser Ideen zu bewältigen. Neue Ideen entstehen auch durch die strategische Ausrichtung von Unternehmen und IT. Dies ist die Domäne der Unternehmensarchitektur und der IT-Strategie. Die IT kann zu einem kritischen Erfolgsfaktor für das Unternehmen und zu einem Katalysator für zukünftige geschäftliche Veränderungen werden. Unternehmensarchitekten oder Chief Information Officers sind eng mit der Unternehmensleitung verbunden und arbeiten mit ihr zusammen. Ihr Ziel ist es, zu sehen, wie die IT als wichtiger Produktionsfaktor im Unternehmen eingesetzt werden kann. Unternehmensarchitekten setzen strategische Entscheidungen in neue Designideen um. Diese Design-Ideen finden auch ihren Weg in das Produkt-Backlog. Traditionell entscheiden Architekten über die Architektur und die Konformität von Software mit der Unternehmensarchitektur. Eine transparente Bewertung des tatsächlichen Geschäftswerts wird jedoch selten vorgenommen. Konformität ist Trumpf. Diese Dynamik hat sich in der neuen Realität von Scrum geändert. Wir verwenden einen anderen Ansatz, um die Anforderungen der Unternehmensarchitektur in konkrete Softwareartefakte zu übersetzen. Der Hauptzweck von Design-Ideen besteht darin, die richtigen Ideen oder architektonischen Merkmale für die Umsetzung auszuwählen, und zwar auf der Grundlage des tatsächlichen Werts. Der erste Schritt besteht darin, Design-Ideen in einem Backlog zu organisieren. Die Architekten verwenden dieses Backlog, während sie mit den Product Ownern zusammenarbeiten, um das Product Backlog weiterzuentwickeln. Diese Zusammenarbeit basiert auf einer Partnerschaft, die auf den Geschäftswert abzielt, jetzt und in der Zukunft. Geschäftswert bedeutet nicht unbedingt Kosteneinsparungen. Er findet sich auch in der Kontinuitätsplanung (z.B. wenn die Anzahl der Server erhöht werden muss, um die Systemstabilität zu erhalten) oder in der Anpassungsfähigkeit der Software. Die Entscheidung darüber, welche Design-Ideen umgesetzt werden sollen, trifft letztendlich der Produktverantwortliche. Architekten spielen eine wichtige Rolle bei der Erläuterung und Förderung dieser Ideen. Die Arbeit ausbalancieren In Unternehmen mit einer komplexen Multisystemumgebung und mehreren agilen Teams sollten Architekten dem Product Owner sehr nahe stehen und dabei helfen, aus den Anforderungen im Product Backlog einen maximalen Geschäftswert zu schaffen. Indem sie die Lösung und die Komplexität skizzieren, helfen Architekten dem Product Owner, noch bessere Prioritäten zu setzen, und unterstützen die Support-Teams mit den Ergebnissen dieser globalen Design-Diskussionen. Außerdem werden neue Designideen mit dem Product Owner besprochen und möglicherweise in das Product Backlog aufgenommen. Eine effektive Beziehung zwischen dem Product Owner und den Architekten kann mit weniger Aufwand mehr Geschäftswert schaffen. Wenn wir den Grundsätzen von Chandler folgen, sollte die Einführung von Scrum eine Abstimmung von Struktur, Prozess und Strategie beinhalten - oder sie wird scheitern. Im besten Fall führt es zu einer Suboptimierung innerhalb des gesamten Unternehmens. In diesem Whitepaper haben wir die Abstimmung von Scrum mit den Architekturprozessen untersucht und gezeigt, wie die Rolle der Architekten in einem agilen Kontext Gestalt annimmt, um mehr Geschäftswert zu schaffen. Agile Architekten konzentrieren sich auf die wichtigsten Ergebnisse ihrer Arbeit. Sie gehen zurück zu den Grundlagen und wählen ihre Werkzeuge bewusst aus. Indem sie sich weniger auf die Dokumentation und viel mehr auf die Kommunikation konzentrieren, können sie zu einem wichtigen Beschleuniger für die Sprint-Teams werden und der Organisation helfen, durch die Förderung neuer Design-Ideen einen geschäftlichen Mehrwert zu schaffen. Aber Architekten konzentrieren sich nicht nur auf die täglichen Geschäftsaktivitäten und auf die Stärkung des Herzschlags der Scrum-Teams. Die zweite Säule ihrer Arbeit ist die Visionierung der Zukunft und die Klärung der Unternehmensarchitektur. Alle Architekten sollten daher Zeit dafür beanspruchen und die Vorteile für das Geschäft und die IT kommunizieren.Agile Architekten leben nicht in Elfenbeintürmen. Sie sind pragmatisch und in das Tagesgeschäft involviert, ohne dabei ihre Rolle bei der Erarbeitung von Zukunftsvisionen zu vergessen.