Agiles IT-Architekturmanagement bei FI-TS: Wir schauen über den Tellerrand Bildquelle: iStockfoto

Im IT-Business bilden wir uns ständig weiter und beobachten, wie andere agile Unternehmen arbeiten. Am Donnerstag, den 21.06.2018 bin ich mit meinem Kollegen Holger Voigt auf der EAMKON 2018. Hier präsentieren wir die besten Praktiken für den Aufbau einer agilen Community nach dem Vorbild von Spotify.
Squads, Tribes, Chapters, Guilds – das Unternehmen organisiert flexible Teams, und wir schauen, was wir aus der Methode für Lehren für ein schlagkräftiges IT-Architekturmanagement beim Kunden ziehen können.

Agile Organisation

Jan Keuntje, Abteilungsleiter IT-Architekturmanagement bei FI-TS

Das  Thema „Agile Organisation“ ist in aller Munde. Besonders hervorgetan hat sich dabei Spotify, die eine ganz spezielle Organisationsform, eine agile Kultur und Managementphilosophie entwickelt hat. Auch für uns, die wir eine eher klassische Unternehmensphilosophie haben, lohnt es sich, Teile davon zu adaptieren. Ich zeige Ihnen mal kurz, wie wir uns beim Aufbau des IT-Architekturmanagements  an der Managementphilosophie von Spotify orientiert haben.

Squads

Das Herzstück der agilen Organisation von Spotify sind die Squads. Das sind kleine, agile Einheiten, die ein Thema komplett betreuen. Wir sind mit unseren Fachabteilungen ganz ähnlich organisiert. Schließlich verantworten die auch Themen wie beispielsweise Windows, von A bis Z.

Darstellung des Zusammenspiels von Tribes, Squads, Chapter und Guilds bei Spotify.

Chapter

Das zweite wichtige Element bei Spotify sind die Chapter. Das sind verschiedene Disziplinen wie App-Entwickler, Tester oder Qualitätssicherer. Und auch das finden wir in unserer klassischen Organisation bei FI-TS, nämlich Rollen wie IT-Architekten, Planer oder Betriebsführer.

Guilds

Die besondere Idee von Spotify ist nun, aus den Squads heraus Menschen verschiedener Chapter zu sogenannten Gilden zu kombinieren, die vorübergehend eine Community-of-Interest bilden.

Same same but different

Ziemlich ähnlich organisieren wir bei FI-TS IT-Architekturentscheidungen: Wir nehmen aus dem zentralen IT-Architekturmanagement zum Beispiel IT-Architekturmanager und Lead-Architekten, aus den Fachabteilungen die Senior-Architekten, aber auch alle weiteren Fachrollen, die wir für eine gute IT-Architekturentscheidung brauchen und formen aus den Kolleginnen und Kollegen eine „Gilde“. Diese arbeitet temporär an einer IT-Architekturentscheidung  und geht anschließend wieder in ihre Squads zurück.

Die Philosophie

Der reine Aufbau des Modells erinnert an die alte Idee vom virtuellen Team. Das Besondere an Spotify ist aber, dass man dort das Ganze mit einer eigenen Philosophie und Grundsätzen verknüpft, die wir uns ebenfalls angesehen haben:

Methodischer Ballast wird über Bord geworfen. Agilität ist der Kern der Spotify-Kultur, große Methoden wie Scrum oder Kanban sind dort aber verpönt. Es gibt hier auch keine Scrum Master, sondern agile Coaches. Wir haben uns bei FI-TS auch bewusst gegen große methodische Ansätze entschieden. Unser IT-Architekturmodell ist sehr schlank und einfach.

Zusammenspiel Autonomie und Alignment: Grund-Vorgaben sind da, aber der Weg wird autonom entwickelt. Foto-Quelle: iStockfoto

Ein weiteres Prinzip von Spotify ist, dass Autonomie und Anpassung (Alignment) keine Gegensätze sein müssen, sondern sich gegenseitig verstärken. Wir leben das auch, denn bei uns steckt das technologische Know how in unseren dezentralen Fachabteilungen. Das zentrale IT-Architekturmanagement redet hier nicht rein (Autonomie). Gleichzeitig entwickeln wir zentralisiert die richtigen Architekturvorgaben und sorgen dafür, dass die IT-Bausteine der verschiedenen Fachabteilungen zueinander passen (Alignment).

Kurz und knackig

Kurze Entscheidungswege – können wir agile mit traditionellen Entscheidungswegen verbinden, und kommt da auch was Gutes raus?

Eine wichtige Erkenntnis von Spotify ist, dass Standardisierung nicht alles ist. IT-Architekturmanagement sollte nicht auf Standardisierung reduziert werden. Wir haben eine kleine IT-Architekten-Gilde gebildet, die ein sehr einfaches, aber mehrdimensionales Verfahren zur Bewertung von IT-Architekturen entwickelt hat, das wir inzwischen bei jeder IT-Architekturentscheidung anwenden. Wir steuern auch nicht alles, denn wir möchten uns nicht verzetteln.

Öfter mal was Neues

Die Idee hinter Spotifys Release-Trains und Feature Toggles ist, dass ein Digital Leader innerhalb kürzester Zeit viele Release rausbringen muss. Natürlich kann er dann aber noch nicht alle Features fertig haben. Ein Release Train transportiert dabei fertige und unfertige Teile der Spotify-Software in die Produktion, wobei die noch unfertigen Teile einfach abgeschaltet werden (Feature Toggle).
Das machen wir bei komplexen IT-Architekturentscheidungen genau so. Schließlich müssen wir oft viele Themen miteinander verknüpfen. Natürlich dürfen wir die relevanten abhängigen Themen nicht einfach ausblenden, darum vermerken wir unsere IT-Architekturentscheidungen, um sie zu einem späteren Zeitpunkt  auszuarbeiten und zur Entscheidungsreife zu führen.

Fazit

Dies sind natürlich nur einige Beispiele aus der Managementphilosophie von Spotity, und nicht alles davon lässt sich auf klassische Unternehmen und schon gar nicht auf das IT-Architekturmanagement übertragen. Trotzdem gibt es einige Prinzipien, die uns helfen, eine schlagkräftige IT-Architekten-Community bei FI-TS zu organisieren und zu guten relevanten und wirksamen IT-Architekturentscheidungen zu kommen. Davon profitieren insbesondere unsere Kunden.