Wie kann eine Facharchitektur die agile Transformation unterstützen?

Ich beobachte bei unseren Kunden immer großflächiger den Einsatz agiler Vorgehensmodelle, um auf sich rapide ändernde Kundenerwartungen und Marktsituationen reagieren zu können. Nichtsdestotrotz fällt auf, dass viele Unternehmen bei dieser „agilen Transformation“ an einem gewissen Punkt steckenbleiben und nicht die gewünschte Flexibilität, Skalierbarkeit oder Kundenzentrierung erreichen. Die Ursache dafür liegt oftmals darin, dass eine traditionelle Unternehmensorganisation die Lebenszyklen agil entwickelter Produkte nicht optimal unterstützen kann.

Müssen Unternehmen also eine neue Organisationsstruktur etablieren, um die agile Transformation erfolgreich zu meistern? Kann hierfür die Facharchitektur optimale Lösungen erarbeiten?

Was ist eigentlich eine Facharchitektur?

Die Facharchitektur analysiert die fachliche Struktur eines Unternehmens oder einer Branche und leitet daraus fachlich orientierte Bebauungspläne ab. Dabei werden auf Basis von Kerngeschäftsprozessen und der Wertschöpfungskette des Unternehmens die Geschäftsfunktionen (Business Capabilities) extrahiert und zu Business Domains geclustert. Das Zusammenspiel dieser Business Capabilities wird untersucht, fachliche Schnittstellen und Datenmodelle werden definiert und Steuerungsmechanismen für die Kernprozesse erarbeitet. Das folgende Schaubild zeigt ein Beispiel für ein facharchitekturelles Artefakt, eine Business Capability Map, aus der Versicherungsbranche:

Die Artefakte der Facharchitektur zeichnen sich dadurch aus, dass sie keine konkreten technischen Lösungen enthalten und dass sie langfristig gültig sind. Schließlich ändern sich die Wertschöpfung und Kernprozesse eines Unternehmens in der Regel nicht. So kann man die Facharchitektur recht gut von der technischen Softwarearchitektur oder der Anwendungsarchitektur abgrenzen, wenngleich die Grenzen in der Praxis natürlich fließend sind.

Wie lässt sich eigentlich „agile Transformation“ definieren?

Bevor wir uns mit ihren Herausforderungen beschäftigen, möchte ich zunächst kurz erklären, was ich unter dem Begriff „agile Transformation“ verstehe. Der Begriff „agil“ wurde um die Jahrtausendwende im Bereich der Softwareentwicklung populär. Er subsumiert verschiedene Ansätze zur Flexibilisierung und Verschlankung von Anforderungserhebungs- und Entwicklungsprozessen. Durch die Anwendung agiler Methoden und Vorgehensmodelle ist es möglich, Softwaresysteme schneller auf den Markt zu bringen und diese anhand des Nutzer-Feedbacks kontinuierlich und kurzzyklisch weiterzuentwickeln. Genau diese beiden Eigenschaften der agilen Softwareentwicklung – „Time-to-Market“ Optimierung und Nutzerzentriertheit – haben nun viele Unternehmen dazu veranlasst, agile Vorgehensmodelle organisationsweit einzuführen, zumindest wenn es um die Entwicklung von Informationssystemen geht. Aus meiner Sicht stellt dieser Shift, weg von klassischen Projektvorgehen hin zu agiler Produktentwicklung und zwar organisationsweit für Vorhaben aller Größenordnungen, die Definition der „agilen Transformation“ dar.

Wo liegen also nun die Herausforderungen?

Meiner Erfahrung nach stellen sich schnell Erfolge und positive Erfahrungen ein, wenn die Entwicklung kleiner, hochgradig autarker Systeme durch agile Teams durchgeführt wird. Sie stoßen aber schnell auf Probleme, wenn es darum geht, größere und komplexere Vorhaben agil durchzuführen, die einerseits ein funktionierendes Zusammenspiel mehrerer Teams erfordern und andererseits tief in die bestehende System- und Organisationslandschaft eingebettet werden sollen. Die Adaption eines Frameworks für skalierende Agilität wie SAFe oder LeSS (Huge) kann den Unternehmen hier gewisse Leitplanken geben. Es löst die auftretenden Probleme jedoch in der Regel nur sehr punktuell auf.

Um den Kern des Problems zu verstehen, möchte ich an dieser Stelle eine meiner Lieblingserkenntnisse der Systementwicklung in Erinnerung rufen, Conway‘s Law:

Betrachten wir also einmal die organisatorisch geprägten Kommunikationsstrukturen eines Unternehmens, das nicht in den letzten 25 Jahren gegründet wurde. Hier sehen wir in der Regel einen Organisationsaufbau über mehrere Hierarchieebenen, deren kleinste Einheiten (Referate, Teams, Competence Center,…) aus Mitarbeitenden mit ähnlichem Skill bestehen (zum Beispiel Java und Frontend Developer, Business Analysts, Account Manager oder Spezialistinnen und Spezialisten für Rentenversicherungen.

Für größere Vorhaben werden diese Mitarbeitenden dann klassischerweise in cross-funktionale Projektteams gestuft und dort temporär unter einer Projekt- oder Programmleitung eingesetzt. Inhalt, Zeitplan und Budget eines Projekts sind in der Regel bereits zu Projektbeginn in einem hinreichend finalen Detaillevel festgelegt und durch ein Lenkungsgremium freigegeben, das in der Regel aus Führungskräften „der Linie“ besteht. Bei größeren Abweichungen wird dann das Vorgehen hinsichtlich Budget, Personal und Timeline zwischen Projekt- / Programmleitung und dem Lenkungsgremium abgestimmt. Zudem fungiert das Lenkungsgremium in der Regel als Controlling Instanz. Nach erfolgreicher Umsetzung des Projekts werden die Teams dann aufgelöst und das Ergebnis an eine Betriebseinheit übergeben. Die Führungskräfte „der Linie“ sind bei diesem Vorgehen stets in die operative Steuerung der Projekte einbezogen.

Agile Vorhaben hingegen haben andere Voraussetzungen und einen andern Lebenszyklus als ein klassisches Projekt. Bei Entwicklungsbeginn ist in der Regel das geschäftliche Ziel des Produkts bekannt und idealerweise durch messbare Indikatoren, den KPIs, festgelegt. In hinreichendem Detail spezifiziert ist jedoch nur eine erste Grundversion, das Minimal Viable Product (MVP). Dieses MVP wird dann möglichst schnell umgesetzt und anschließend vom agilen Team betrieben und anhand des Kunden- oder Nutzerfeedbacks weiterentwickelt. Die Release-Zyklen sind wesentlich kürzer als bei einem klassischen Projekt und inhaltliches Scoping findet wesentlich öfter statt. Eine ständige Abstimmung zur Umsetzung des Nutzerfeedback zwischen Product Ownern, einer Projektleitung und einem Lenkungsausschuss als Kontrollinstanz würde sich nach Conway´s Law zwingendermaßen im Systemdesign widerspiegeln. Eine wirklich nutzerzentrierte und eigenverantwortliche Weiterentwicklung des Products durch die jeweiligen Teams wird dadurch unmöglich.

Also ist eine wirklich erfolgreiche agile Transformation nur möglich, wenn das Kommunikationsdreieck aus Entwicklungsteams, Projektleitung und Führungskräften für die operative Steuerung aufgelöst wird. Eine wertschöpfende und produktorientierte Organisation, die sich an den definierten KPIs orientiert, muss in den Vordergrund und die klassische hierarchische Geschäftsorganisation, also „die Linie“, in den Hintergrund treten. Verantwortung und auch Kontrolle für operative Themen müssen durch die Linie weitestgehend abgegeben werden.

Dies ist übrigens auch eine grundlegende Betrachtung verschiedener bekannter Modelle zur agilen Transformation, wie zum Beispiel das Pioneers Trafo-Modell. Dieses Modell betrachtet verschiedene Dimensionen einer agilen Organisation und bietet ein Reifegradmodell für die Transformation. Die Etablierung selbstverantwortlicher Teams und die Entwicklung von einer führenden und kontrollierenden zu einer dienstleistenden Aufbauorganisation sind Kernaspekte des Modells.

Wo setzt die Facharchitektur an?

Denken wir also darüber nach, wie eine solche wertschöpfende, produktorientierte Organisation in einem Unternehmen aufgebaut werden sollte, damit in ihr agile Teams großflächig arbeiten können: Zunächst einmal stellen wir fest, dass die Produkte möglichst eigenständig sein und klar definierte Schnittstellen haben müssen, damit die Teams autark arbeiten können. Zudem sollten die Produkte dauerhaft im Rahmen des Kerngeschäfts des Unternehmens eingesetzt werden, damit gut messbare und relevante KPIs definiert werden können und der Lebenszyklus eines agil entwickelten Produkts gegeben ist. Letztlich ist eine möglichst flache Hierarchie in dieser Organisation erstrebenswert.

Genau hier können nun die Kernartefakte der Facharchitektur exzellent eingesetzt werden. Die Facharchitektur hat das Kerngeschäft des Unternehmens in Business Domains und Business Capabilities heruntergebrochen und diese mit den Kernprozessen des Unternehmens in Verbindung gebracht. Somit ist es sinnvoll, dass jede Business Capability ein Produkt definiert und die Teams erhalten dann die dauerhafte Verantwortung und Ermächtigung für die Bereitstellung einer Business Capability – und zwar technologieunabhängig und End-2-End über alle Ebenen. In großen Konzernen kann nun noch eine schlank gehaltene Hierarchieebene über diese Teams gezogen werden, in der dann jeweils eine Business Domain verantwortet wird.

Eine solche Organisation orientiert sich ausschließlich an der Fachlichkeit und Wertschöpfung des Unternehmens. Die Kommunikation zwischen den Teams bezüglich Optimierungen, Abhängigkeiten, Schnittstellen und Risiken kann ganz natürlich anhand der Kerngeschäftsprozesse und definierten KPIs geführt werden. Alle Voraussetzungen sind also gegeben, damit die agilen Prinzipien innerhalb der einzelnen Teams gelebt werden können. Die traditionelle „Linie“ kann sich komplett aus dem operativen Geschäft zurückziehen und zum reinen Enabler bezüglich persönlicher Entfaltung und Weiterentwicklung der Mitarbeiter werden.

Fazit

Eine Facharchitektur bietet durch fachliche Bebauungspläne und Business Capability Landkarten Lösungsansätze für den organisatorischen Umbau, der im Rahmen der agilen Transformation stattfinden muss. Eine Organisation, die sich an der Wertschöpfungskette des Unternehmens orientiert, die aus autarken Teams mit klar definierten Zuständigkeiten und Verantwortungen besteht und gleichzeitig relativ flach ist, bietet das perfekte Fundament für den großflächigen Einsatz agiler Vorgehensweisen.

Natürlich wäre es nun zu einfach daraus zu schließen, dass ein solcher Organisationsumbau ohne Hürden direkt in die agile Glückseligkeit führt. Diese Restrukturierung kann nur dann gut funktionieren, wenn sie durch gutes Change Management begleitet, wirksames agiles Coaching eingesetzt und schließlich auch die technische Architektur so aufgesetzt wird, dass eine weitgehende Entkopplung der agilen Teams möglich ist. Dazu sind nach wie vor gewisse Querschnittsfunktionen in der Organisation erforderlich, die sich schwer in einem Produktteam verorten lassen, man denke beispielsweise an Compliance und Security. Und nicht zuletzt bleibt natürlich auch ein typisches Problem der Agilität bestehen: Je weiter das eigentliche Produkt des Unternehmens vom puren, durch KPIs messbaren IT-Produkt entfernt ist, desto schwerer lässt sich Agilität umsetzen.

Ihr möchtet mehr über spannende Themen aus dem Insurance-Bereich bei adesso erfahren? Werft auch einen Blick in die bisher erschienen Blog-Beiträge aus dem Versicherungsbereich.