Low-Code auf der grünen Wiese?
Bisher wurden die Chancen und Risiken von Low-Code-Plattformen so betrachtet, als würden sie "auf der grünen Wiese" eingeführt. Stattdessen besteht in der Regel eine meist komplexe IT-Infrastruktur in den einzelnen Organisationen, in die ein neues System eingebunden werden muss. In den vorangegangenen Ausführungen hat sich gezeigt, dass das Konzept Low-Code einer eigenen Entwicklungs-, Architektur- und Nutzungslogik folgt, welche der Logik der bisherigen Infrastruktur teilweise widersprechen könnte: komponentenbasiert, integrativ durch Nutzer:innenfreundlichkeit, agil und flexibel, und weitere.
Um diesem Konflikt effektiv zu begegnen, soll hier kurz perspektivisch in den Government as a Plattform Ansatz u.a. nach Kuhn et al. eingeführt werden, welches darüber hinaus bereits im bundesdeutschen Verwaltungskontext als Zieldesign verwendet wird [1–3]. Ziel dieses Konzepts ist es, öffentliche Verwaltungen, IT-Dienstleistungsunternehmen und den Nutzer:innen angebotenen Leistungen innerhalb einer digitalen Plattforminfrastruktur zu vernetzen. Eine Plattform wird dabei als modular aufgebautes System verstanden, welches sich in einen Kern und dessen Peripherie aufteilt. Während der Kern (Platform Owner) die Verantwortung für die Infrastruktur inne hat sowie die Grundfunktionalitäten betreut, können Akteur:innen der Peripherie (Complementor, User) auf dieser Basis je nach eigenen Anforderungen und Interessen weitere Komponenten hinzufügen oder zumindest anregen. Sie bauen entsprechend auf einer vorhandenen Infrastruktur oder alternativ Protokollen und Standards auf. Das Ausmaß, inwiefern „die Peripherie“ Einfluss auf die Entwicklung der Plattform nehmen kann, wird durch sog. Boundary Ressources, Regulationsmechanismen, festgelegt, wodurch auch Verantwortlichkeiten und Aufgaben klar verteilt werden. Dieser Ansatz baut auf den Prinzipien der Offenheit, der Ko-Kreation und der Partizipation auf [2; 3].
Kuhn et al. entwickelten eine Methode, mittels derer die vorhandene Infrastruktur "plattformisiert" werden kann. Durch die Analyse der bestehenden Infrastruktur und eine anschließende Übertragung dieser auf die Bestandteile einer Plattform erscheint es möglich, technische wie organisatorische Lücken und Überlappungen zu identifizieren und Lösungen zu erarbeiten. Darüber hinaus bietet dieser Ansatz die Möglichkeit zur Reflexion bestehender Strukturen hinsichtlich technischer Komponenten, Verantwortlichkeiten usw. [2].
![Abb. 3: Die Analysemethode für eine Governant-as-a-Platform-Infrastruktur [@KuhnGaap]](/simplex-studie-ap2/assets/images/20231129_Abb_Methode_Kuhn-0631d8333133dbbd7fa50e7e1a64cf0e.png)
Obwohl sich dieses Konzept ursprünglich auf eine behördenübergreifende Vernetzung bezieht, bietet es aufgrund seiner leicht nachvollziehbaren Struktur einen Perspektivwechsel für den innerbehördlichen Kontext. Low-Code-Plattformen wären dahingehend eine Lösung für technische Leerstellen. Indem die technischen Systeme, wie Fachverfahren, Veraktungssysteme oder der Onlinezugang für Bürger:innen als einzelne Komponenten analysiert und dem Kern bzw. der Peripherie zugeordnet werden, gewinnt auch das oft vernachlässigte Backend die notwendige Aufmerksamkeit. Die zuvor diskutierten Vorgaben aus und notwendigen Komponenten für Verwaltung sowie die Sicherheitsanforderungen bilden sodann den Rahmen und geben Hinweise auf die Form der Boundary Ressources. Darüber hinaus kann die Methode von Kuhn et al. auch zur Reflexion des Ressourceneinsatzes und möglicher Verantwortungs- und Aufgabenverlagerungen bis hin zu potenziellen Formen der Zusammenarbeit dienen, wie sie im folgenden Kapitel näher erörtert werden.
Die Autoren ergänzen, dass die praktische Umsetzung dieser Methode in der Regel durch Expert:innen begleitet werden müsse, um Verständnisprobleme zu beheben [2]. Zudem sollte beachtet werden, dass es sich beim Plattformansatz um sozio-technische Systeme handelt, weshalb neben technischen auch nichttechnische Standards zur Zusammenarbeit und Abstimmung zwingend notwendig sind [4].