Das Koordination-Autonomie Dilemma stellt sich wenn mehrere Entwicklungsgruppen zusammen mit den ihnen zugewandten Fachabteilungen optimierte Lösungen entwickeln. Stärkere Koordination erhöht die Kosten für Experimente und best-of-breed Lösungen in den Abteilungen zugunsten besserer Effizienz und verringerter Komplexität der Gesamt-IT. Zu strikte Auflagen können die bottom-up Innovationskraft eines Unternehmens schwächen.
Das Koordination-Autonomie Dilemma wird im Kontext von Technologie-Akquisitionen durch etablierte Konzerne erforscht. In einer modernen IT mit DevOps können agile Projektteams mit Start-Ups innerhalb der Gesamt-IT verglichen werden.
Es obliegt der IT Governance, die Regeln für deren Zusammenarbeit zu definieren.
Bottom-up Innovation baut auf Experimente
Der Trend hin zu daten-zentrischem Denken erhöht die bottom-up Innovation aus den Projektteams.
Nehmen wir an ich leite ein agiles Projektteam. Vielleicht vermute ich in den Daten meiner betreuten Fachanwendung Muster, die sich für Predictive Analytics eignen. Das Business sieht Potenzial und ist bereit, ein Experiment zu wagen.
Kann ich mit 2-3 Tagen Aufwand einen Proof of Concept für diesen Machine Learning-Anwendungsfall bauen?
Experimente bedingen Autonomie
Um diese Frage mit Ja beantworten zu können brauche ich Autonomie.
Technologisch:
Muss ich zuerst einen Antrag stellen, um das in Zukunft firmenweit einzusetzenden Machine Learning Framework festzulegen?
Gibt es bereits vorgeschriebene Technologiestandards in der Firma?
Sind diese aktuell und passen sie auf mein Problem?
Administrativ:
Kann ich selbständig eine PaaS Lösung dafür aufsetzen und konfigurieren?
Oder muss das bei einer zentralen Stelle beantragt werden?
Finanziell:
Habe ich die Entscheidungskompetenz, um die internen und externen Ressourcen ohne langwieriges Prozedere einzusetzen?
Schnell wird der Aufwand zu gross um das Experiment mit ungewissem Ausgang rechtfertigen zu können.
Aus Experimenten werden Lösungen
Nehmen wir jedoch an, ich habe keine Auflagen und lege los.
Falls sich das Potenzial meines Proof of Concepts materialisiert, werde ich ihn weiterentwickeln und die langfristige Wartbarkeit sicherstellen: Tests ergänzen und ihn in die CI/CD Pipeline, die Überwachung und die zentrale Benutzerverwaltung integrieren.
Damit wächst der investierte Aufwand, die sunk cost, um ein Vielfaches.
Ineffizienz so weit das Auge reicht
Jede andere Entwicklungsgruppe handelt genauso, optimierend auf ihre eigenen Ziele: Der zugewandten Fachabteilung so viel Mehrwert wie möglich zu liefern.
Das Endresultat ist ein Zoo von produktiv eingesetzten Lösungen für ähnliche Probleme.
Aber – ist das jetzt eigentlich nur schlecht?
Wie Kris Gale es in seinem Blogbeitrag so trefflich beschreibt: Investiert eine Organisation jeden Preis um zu verhindern, dass ein Arbeitsschritt unnötigerweise mehrfach ausgeführt wird, wird sie eine maximal hohe Arbeitseffizienz ausweisen. Aber keinen nennenswerten Durchsatz erreichen, da jedem Arbeitsschritt eine Unmenge von Koordinationsschritten und Bewilligungen vorausgeht.
Ist Effizienz oder Durchsatz der richtige Massstab?
Das hängt davon ab, wie die Firma und die IT-Organisation ihre Ziele gewichtet.
Ist (Kosten-)Effizienz das Gebot der Stunde, empfiehlt sich stärkere Koordination und Standardisierung.
Versteht sich die IT hingegen primär als Business Enabler, ist der Innovationsgewinn durch Autonomie möglicherweise höher zu werten. Eine nachträgliche Prioritätsverlagerung von Innovationskraft zu Effizienz wird dann allerdings aufwendig.
Die meisten Organisationen finden sich irgendwo in der Mitte. Andere setzen die Gewichtung unterschiedlich pro IT-Abteilung fest (Two-speed IT).
Und, wie stellt sich Deine IT-Organisation diesem Dilemma?
