Im ersten Teil der Blog-Reihe haben wir die richtungsweisende Rolle der Cloud Strategie in den Mittelpunkt gerückt. Im zweiten Teil zeigen wir, warum es für ein erfolgreiches FinOps notwendig ist, bestehende Rollen der (IT-) Organisation auf die Cloud-Nutzung anzupassen. Das betrifft besonders die der Application Owner.
In klassischen, rechenzentrumszentrierten IT-Organisationen waren die Applikations-Rollen meist funktional und sauber getrennt, hatten jedoch keinen durchgängigen Produkt- oder Service-Fokus. Bei großen Unternehmen oder Konzernen, wurde diese Trennung meist durch Outsourcing/Outtasking-Verträge noch weiter zersplittert. In der Folge existierten multiple Verantwortlichkeiten pro Applikation, die sich um Aufbau und Betrieb der Infrastruktur, Applikationsentwicklung, Testing, Deployment bzw. Service-Management und andere Funktionen kümmerten. Im Ergebnis entstand eine äußerst komplexe RACI-Matrix und ein Bruch in der ganzheitlichen, Ende-zu-Ende „Ownership“ auf Applikations-Ebene.
Mit der Einführung von Cloud-Services als zentrales Infrastruktur Delivery Modell, ist dieser Zustand nicht mehr zukunftsfähig. Durch die Nutzung von „Infrastructure as Code“ (IaC) – einer eigene Skript-Lösung für Konfiguration und Aufbau von Cloud Ressourcen inkl. Ablage im SW-Repository – wird die Infrastruktur faktisch Teil der Applikations-„Software“. Den Kitt hierfür liefern CI/CD Pipelines, Test-Automatisierung, etc. aus technologischer Sicht sowie agile Methoden bzw. DevOps oder Site Resilience Engineering (SRE) Ansätze aus organisatorischer Sicht. Sie ermöglichen die Integration und Automatisierung des gesamten Software-Lebenszyklusinklusive der Infrastruktur und erweitern dadurch stark den bisherigen Scope des Applikations-Verantwortlichen.
Um der Wichtigkeit der Position zukünftig gerecht zu werden und ihr ein ausreichendes Handlungsmandat des Managements zu erteilen, muss eine entsprechende Anpassung der Rolle der Application Owner folgen. Wie sieht diese neue Rolle aus?
Dem T-Shape Skill-Modell (siehe Grafik) folgend, werden Application Owner weit mehr in die Breite denken und handeln müssen, da sie im Gegensatz zu früher ganzheitlich für die verschiedenen Aspekte der Applikation verantwortlich sind. Gleichzeitig bedingt diese Entwicklung, dass diese Person nicht in allen Themen im Detail stecken kann. Das muss sie aber auch nicht, solange sie das entsprechende Know-How in ihrem – idealerweise intern-besetzten - Team findet bzw. aufbaut. Application Owner selbst werden dadurch zunehmend zu GeneralistInnen, gleichwohl immer im Sinne der verantworteten Applikation. Die konkrete Ausgestaltung der RACI ist dabei unternehmensspezifisch. Es sollte jedoch immer mit einer Ende-zu-Ende Sicht agiert werden.
Beispiel: Erweiterung des Skill-Profils eines Applikations-Owners durch Cloud-Nutzung und verwandte Themen
Diese Veränderung passt inhaltlich perfekt zu agilen Praktiken mit ihrem Fokus auf mehr Eigenverantwortung und Selbststeuerung innerhalb des Teams. Aber auch DevOps mit cross-funktionalen Teams, E2E Fokus, fortwährendem Lernen und engerer Verzahnung der verschiedenen Bereiche aus dem Applikationskontext (Stichwort: „BizDevOps“), bietet eine Vielzahl sinnvoller Ansatzpunkte.
Diese größere Last auf den Schultern der Application Owner muss allerdings auch mit dem entsprechenden Empowerment durch das Management einhergehen. Freiräume für persönliche und teaminterne Weiterbildung müssen ermöglicht und ausreichend Kapazitäten für die adäquate Übernahme der Aufgaben über das Team hinweg bereitgestellt werden.
Im nächsten Beitrag widmen wir uns der zentralen Rolle, die ein FinOps Team für eine erfolgreiche Cloud-Nutzung spielt.
