Autoren: Detlef Wallenhorst, Markus Pfaff, Daniel Eckstein
Agiles Projektmanagement
Die Konzeption und Umsetzung einer IT-Architektur, wie sie im vorangegangenen Blog skizziert wurde, ist in der Tat ein umfangreiches, komplexes Vorhaben, für das sich erfahrungsgemäß eine agile Vorgehensweise empfiehlt. Die Anwendung agiler Projektmanagementmethoden wie Scrum oder SAFe ist hinlänglich aus der Softwareentwicklung bekannt. Tatsächlich wurden agile Prozesse ursprünglich für die Entwicklung tangibler Produkte erdacht1 und eignen sich, wie die Praxis zeigt, hervorragend für die Entwicklung und Implementierung komplexer IT-Architekturen inklusive Software, Hardware und Services. Sowohl in Unternehmen als auch in Regierungsorganisationen ermöglichen sie es, kleine Änderungen mit sofortigem Feedback der Nutzer zu koppeln, zu optimieren und Fehlentwicklungen, die planerisch nicht offenbar sind, schnell zu erkennen. Im SAFe werden neben den zu entwickelnden Lösungen auch agile Organisationsformen und Finanzierungsmodelle beschrieben, die weltweit Erfolge gezeigt haben. Gleichzeitig werden durch die kontinuierliche Kommunikation der inkrementellen Fortschritte alle Beteiligten transparent und nachvollziehbar informiert und in den Transformationsprozess integriert.
Die drei Dimensionen des agilen Vorgehens
Vor dem Hintergrund, dass die IT-Architektur als Fundament für eine Governable AI gedacht ist, geht es gleichwohl um mehr als den Aufbau einer IT-Infrastruktur: Es geht um die Gestaltung einer echten Transformation, die neben der IT-Architektur auch Organisationsstrukturen und Prozesse betrifft! Dies liegt vor allem darin begründet, dass die Einführung einer KI häufig mehr bedeutet als die Einführung eines neuen Werkzeugs zur Produktivitätssteigerung. Letztendlich verändert die Einführung von KI die Art und Weise, wie wir arbeiten, sehr grundlegend. Im Rahmen eines agilen Vorgehens ist es daher wichtig, neben der operativen Dimension, also den eigentlichen ML-OPS- bzw. CD4ML-Prozessen, auch die strategische und die normative Dimension im Blick zu haben. Die strategische Dimension beinhaltet dabei insbesondere den agilen Aufbau der erforderlichen Strukturen, Prozesse und Kompetenzen, wohingegen die normative Dimension die Adaption an sich typischerweise stetig ändernde Regularien, Werte- und Zielvorstellungen umfasst. Für eine agile, transformative Reise durch die operative, strategische und normative Dimension stellt die ganzheitliche IT-Architektur dabei nicht nur den Polarstern, also den technologischen Teil des Reiseziels dar, sondern sie ist gewissermaßen auch das Vehikel, mit dem man sich auf diese Reise begibt – und dies im Wesentlichen aus drei Gründen:
Adaption, Transparenz und Kommunikation.
1. Adaption: Anpassen an sich stetig änderende Rahmenbedingungen
Moderne IT-Infrastrukturen sind nicht mehr monolithisch, starr und unflexibel, sondern sie unterstützen das Konzept einer Cloud-Architektur und sind programmierbar; nicht ohne Grund spricht man von „Infrastructure as Code“ beziehungsweise „Software Defined Infrastructure“. Diese Programmierbarkeit ist das Fundament für eine agile Adaption an sich ändernde operative, strategische oder normative Rahmenbedingungen. So sind beispielsweise die beim Durchlaufen einer CI/CD-Pipeline erforderlichen nicht-funktionalen Tests, bei denen eine neue Software gewissermaßen zum ersten Mal auf die Wirklichkeit trifft und sich zeigen muss, ob auch die Gesamtlösung performant und regelkonform ist, ohne programmierbare Infrastruktur kaum effizient und flexibel durchführbar. Und auch Änderungen, die sich im laufenden Betrieb ergeben, können auf Basis dieser Programmierbarkeit gut adaptiert werden – hervorzuheben sind in diesem Zusammenhang etwa sich ändernde Policies, die sich aus einer sich ändernden Regulierung ergeben, oder variierende Datenzugriffsrechte, die erforderlich werden, um die Handlungsfähigkeit bei sich verändernden Lagen sicherzustellen. Damit diese Programmierbarkeit der Infrastruktur nicht zu Lasten von verringerter Performance, erhöhter Komplexität und zusätzlichen Total Costs of Ownership (TCO) „erkauft“ werden muss, gilt es dabei gleichwohl einen ganzheitlichen, systembasierten Ansatz zu verfolgen, der eine enge Integration von Hardware und Software sowie von physischen und virtuellen Elementen ermöglicht, der auf einem offenen Systemmodell basiert, und der idealerweise innovative anwendungsspezifische integrierte Schaltungen nutzt – die Application Centric Infrastructure (ACI) von Cisco ist ein gutes Beispiel dafür, wie ein solcher Ansatz umgesetzt werden kann.
2. Transparenz: Wissen, wo man sich befindet
Wie bei jeder Reise ist es auch bei der agilen Digitalisierungsreise wichtig, sich orientieren zu können und Transparenz darüber zu schaffen, wo man sich gerade befindet – man braucht also einen metaphorischen Kompass oder Sextanten, mit dem man den Polarstern anvisieren kann … auch diese Funktion übernimmt die IT-Infrastruktur! Diese Transparenz ist einerseits bezüglich der technologischen Systeme herzustellen, also in Bezug auf die Infrastruktur, die KI-Modelle etc. Heutzutage spricht man in diesem Zusammenhang von Observability, die es in allen Phasen des Lebenszyklus einer KI zu schaffen gilt, also z.B. um einen tiefen Blick in die CI/CD-Pipeline werfen zu können oder um überprüfen zu können, ob ein KI-Modell im Betrieb unter Umständen einen Bias offenbart. Hierfür stehen mittlerweile eine Vielzahl an Werkzeugen zur Verfügung, die je nach spezifischer Anforderung als Open Source oder als kommerzielle Lösung, wie z.B. Splunk, genutzt werden können. Wenn eine Vielzahl an Möglichkeiten zur Verfügung steht, dann ist das zunächst natürlich positiv, geht aber mit einer gewissen Komplexität einher. Diese Komplexität kann jedoch beherrschbar gemacht werden, u.a. durch die Verwendung von validierten Designs – hierauf werden wir in einem der folgenden Blogs noch tiefer eingehen.
Wie bereits erwähnt, handelt es sich bei der Einführung einer Governable AI um ein transformatives Vorhaben. Neben der Herstellung von Transparenz bezüglich der technologischen Systeme ist es daher notwendig, auch Transparenz bezüglich der Organisationsstrukturen und -prozesse zu schaffen. Auch hierfür stehen adäquate Werkzeuge zur Verfügung, die unter dem Begriff „Organisationsdiagnostik“ subsumiert werden. Die Basis hierfür liefert dabei typischerweise wieder die IT in Form digitaler Kollaborationsplattformen, wie z.B. Webex. Denn ob eine Organisationsänderung wirksam und ob ein KI-Projekt erfolgreich ist, lässt sich auch und vor allem daran ablesen, wer mit wem in welcher Form kommuniziert – wobei hinter „wer“ und „wem“ im Rahmen eines KI-Projektes natürlich sowohl Menschen wie auch Maschinen stehen können.
3. Kommunikation: Lernen und Partizipieren
In der Tat ist Akzeptanz ein wichtiges Handlungsfeld, wenn nicht sogar ein Erfolgsfaktor für die erfolgreiche Durchführung von KI-Projekten2, denn ohne die Akzeptanz der relevanten Stakeholder droht die KI-Lösung nicht genutzt oder das Projekt gar nicht erst umgesetzt zu werden. Um Akzeptanz zu erlangen, gilt es zunächst, z.B. über eine Institution wie die Cisco Networking Academy , die erforderliche Wissensbasis zu schaffen – gerade bei einem Thema wie KI, das umfänglich in den Medien diskutiert wird und über das sich wohl jeder inzwischen eine individuelle Meinung gebildet hat, darf die Bedeutung eines faktenbasiertes Lernprozesses nicht unterschätzt werden. Daneben gilt es für Teilhabe zu sorgen: So kann nämlich unter anderem sichergestellt werden, dass das neu entstehende Arbeitsumfeld nach wie vor als „Gute Arbeit“ charakterisiert werden kann. Dies wiederum ist nicht nur aus normativ-ethischen, sondern auch aus betrieblich-strategischen Gründen von Interesse – hierauf sind wir im ersten Blogbeitrag bereits eingegangen. Sowohl Lernen als auch Partizipieren sind Prozesse, die auf Kommunikation beruhen, eine geeignete IT-Plattform benötigen und dementsprechend mit Aufwand verbunden sind. Diesen Aufwand nicht zu investieren wäre jedoch ein eher kurzsichtiges Vorgehen, da die Kosten eines gescheiterten Projektes oder einer ungenutzten Lösung deutlich höher sein dürften.
Fazit: Es braucht einen roten Faden
Die Vorteile des agilen Vorgehens, mit kleineren Teilprojekten zu starten, nämlich typischerweise solchen, die Probleme adressieren, die aktuell „unter den Nägeln brennen“, um dann sukzessive dem Zielbild einer umfassenden Lösung näher zu kommen, liegen auf der Hand. Hierbei muss aber von Anfang an darauf geachtet werden, dass die verschiedenen Teillösungen am Ende auch zusammenpassen – sonst hat man sich zwar intensiv mit innovativen Themen beschäftigt, aber am Ende keine brauchbare Innovation geschaffen. Man braucht also einen „roten Faden“, der neben dem Polarstern der Orientierung dient. Die Rolle dieses roten Fadens nimmt wiederum die IT-Architektur wahr – und zwar durch die Definition und Umsetzung von Standards! Diese Standardisierung betrifft dabei nicht nur Schnittstellen bzw. APIs, sondern sie geht weit darüber hinaus und umfasst z.B. Betriebsmodelle, Protokolle, Prozesse oder Datenmodelle. Das Schaffen eines roten Fadens ermöglicht nicht nur Interoperabilität, sondern es sorgt auch für Kontrolle über damit in Verbindung stehende, vielschichtige Parameter, wie z.B. Betriebskosten, Komplexität der Betreibbarkeit, Skalierbarkeit, Zeit bis zur Bereitstellung der Funktionalität, notwendige technische Fähigkeiten im Team, und dergleichen mehr. Den roten Faden inhaltlich zu bestimmen ist natürlich eine normative Aufgabe, die von verschiedenen Stakeholdern, einschließlich des Regulierers, zu bewältigen ist, und die gerade im multi-lateralen oder föderalen Kontext einer adäquaten politischen Auseinandersetzung bedarf.
Fußnote 1: Takeuchi, H., & Nonaka, I. (1986): The new new product development game, Harvard Business Review, 64(1), 137-146
Fußnote 2: vgl. z.B. Pfeifer, Y. (2024): Konzeptionierung eines arbeitswissenschaftlichen Handlungsrahmens zur Einführung und Anwendung einer auf Künstlicher Intelligenz basierten Mensch-Roboter-Kollaboration, Berlin, Heidelberg: Springer Vieweg
Authors
