Foto: Maren Winter - shutterstock.com
"Der wachsende Bedarf an IT-Unterstützung zur Umsetzung fachlicher Geschäftsprozesse brachte uns auf die noch ungewöhnliche Idee, eine Plattform auszuschreiben, mit der datenbank- und dialogorientierte Fachanwendungen ohne native Programmierung konfiguriert werden können", erklärt Jan Pohlmann, Abteilungsleiter und CIO der Bundesanstalt für Landwirtschaft und Ernährung (BLE) in Bonn. Man habe sich eine schnellere, effizientere und flexiblere Erstellung der Fachanwendung als mit klassischer Programmierung erhofft.
"Der Begriff Low Code war uns zu dieser Zeit zwar noch unbekannt, aber warum sollte es dafür keine Anbieter geben", blickt Pohlmann zurück. In einem Bieterverfahren setzte sich die Plattform Scopeland durch, und es wurden die ersten kleineren Fachanwendungen entwickelt.
Dann gab es plötzlich neue Gegebenheiten: Vor dem Hintergrund geänderter EU-Vorgaben zur Fischfangregulierung sollte ein umfassendes IT-System für eine lückenlose Quotenüberwachung entwickelt werden. Es galt, die Regeln zur Quotenvergabe und die Einhaltung der Fischerei-Fangquoten konsequenter umzusetzen und zu kontrollieren, ohne dass durchgängig eine Vor-Ort-Kontrolle der BLE auf offener See nötig war.
Eignet sich Low-Code auch für Großprojekte?
"Zwar haben wir schon 2010 mit den ersten konzeptionellen Vorarbeiten begonnen, doch aufgrund der Komplexität zeigte sich immer deutlicher, dass hier sogar die klassischen Verfahrensweisen zur Anforderungsanalyse an ihre Grenzen stießen", beschreibt Pohlmann die Situation. Nach fast fünf Jahren Projektlaufzeit lag gerade mal ein ein Überblicks-Lastenheft zu den wichtigsten Modulen vor, aber es war noch keine einzige Zeile Programmcode geschrieben.
Unter dem Eindruck, von einer Umsetzung in reale Software weiter entfernt zu sein denn je, fiel die grundlegende Entscheidung, dieses Projekt durchgängig mit Low-Code-Technologien und deren agilen Verfahrensweisen umzusetzen. Man beauftragte den Softwarehersteller, und Anfang 2015 ging es mit der Umsetzung des Fischerei-Management-Systems ("FIT") und der Erstellung der ersten Anwendung los.
Zu viel, zu groß und zu wenig Zeit
Die Aufgabe, vor der die Bundesanstalt stand, war immens: In kürzester Zeit galt es, die EU-Mindestanforderungen umzusetzen und sobald als möglich produktiv zu schalten, obwohl diese nicht mal ansatzweise ausreichend spezifiziert waren. Alle verfügbaren Daten sollten über Schnittstellen importiert und im Bedarfsfall auch manuell erfasst werden. Sie waren über von der EU vorgegebene und zusätzliche, nur für Deutschland gültige Cross-Checks miteinander zu verrechnen und für eine manuelle Bewertung numerisch und geographisch aufzubereiten. Zudem sollten permanent Daten mit anderen EU-Staaten und sonstigen angrenzenden Ländern ausgetauscht werden - beispielsweise zu grenzüberschreitenden Fangreisen. All das beruhte auf gesetzlichen Grundlagen und Verordnungen, einhergehend mit zahlreichen Spezifikationen und Handlungsrichtlinien.
Bald zeigte sich, dass der Umfang der zu unterstützenden Aufgaben noch um ein Vielfaches größer war als ursprünglich angenommen. Zahlreiche grundlegende Anwendungen mussten neu entwickelt werden, darunter
das amtliche Fischerei-Fahrzeugregister mit diversen Antrags- und Genehmigungsverfahren,
die umfangreiche Verarbeitung von Geodaten mit Kartendarstellungen der Fangreisen,
die Fachinformationssysteme zu Fischarten, Fanggeräten und Fanggebieten, Windparks und Seegrenzen und
die Quotenvergabe,
ein Punktesystem für Ordnungswidrigkeiten von Kapitänen,
Offline-Software für Kontrollen auf hoher See und weitere Anforderungen.
Welches Vorgehensmodell ist das richtige?
"Aufgrund der Komplexität der Anforderungen und der Größe des Projekts wurde bewusst keine Entwicklung nach dem Wasserfallmodell oder Scrum-Verfahren gewählt, denn es bedarf bei solch einer Komplexität einer besonders agilen Vorgehensweise", betont der zuständige Projektleiter Christof Ansorge. Da eine Low-Code-Plattform zum Einsatz kommen sollte, entschloss man sich zu einem modulweise abgestuften phasenagilen Vorgehen nach modernen Design-Thinking-Prinzipen. Das phasenagile Vorgehensmodell ermöglicht eine wohlstrukturierte planbare und zugleich evolutionäre Vorgehensweise in der Softwareentwicklung.
Für die Fachanwender war es eine Umstellung, anstelle einer klassischen Anforderungsaufnahme zu Projektbeginn direkt in die laufenden Entwicklungsprozesse einbezogen zu werden. Es war wichtig, dass der jeweils zuständige Fachverantwortliche über die gesamte Projektlaufzeit hinweg verfügbar war. Die wohl größere Herausforderung dabei: Die Anwender mussten ständig zeitnah entscheiden, wie die Arbeitsabläufe, Regelwerke und Benutzeroberflächen genau aussehen sollten.
Sie interessieren sich für Low-Code-Programmierung? Dann lesen Sie auch:
Da bei Low-Code-Entwicklungen die Anwender direkt mit den Entwicklern sprechen, bedarf es der Etablierung einer neuen Kultur der Zusammenarbeit. Es dauerte einige Zeit, bis sich alle Projektbeteiligten umgestellt hatten. Das phasenagile Vorgehensmodell wurde somit ein zentraler Projektbestandteil, seine Prinzipien galt es ebenfalls in kürzester Zeit mit umzusetzen.
Design Thinking in allen Projektphasen
Design Thinking steht für das gemeinsame Erarbeiten der Inhalte in interdisziplinären Teams, die sich hier unter anderem aus den jeweils zuständigen Anwendern und Entwicklern zusammensetzen. In mehreren wöchentlichen Design-Thinking-Workshops wurden in der Bundesanstalt alle anstehenden Themen gemeinsam besprochen, Lösungswege erstellt und anhand von insgesamt 140 aufeinanderfolgenden Arbeitsständen diskutiert und vor Ort angepasst.
Zeitweilig waren bis zu zehn Low-Code-Entwickler und ebenso viele BLE-Mitarbeiter mit unterschiedlichen Aufgabenprofilen parallel in die Erarbeitung der Software involviert. Die Projektleiter beider Seiten absolvierten an manchen Tagen gleich mehrere Design-Thinking-Workshops, und sie verstanden sich bei all dem stets eher als Moderatoren der Entscheidungsprozesse. Das war möglich, weil bei der phasenagilen Vorgehensweise ihre Aufgabe nicht darin bestand, die Inhalte vorzugeben, sondern primär für die Einhaltung der Spielregeln zu sorgen und jeweils zeitnahe Teamentscheidungen zu erwirken.
Die eigentlichen Inhalte erarbeitete das Team stets gemeinsam, weshalb auch solche Themen zügig angegangen und technisch umgesetzt werden konnten, deren Anforderungen zu Beginn noch völlig unklar waren. Die etwaigen anfänglichen Berührungsängste mit dem neuen Konzept Design Thinking waren schnell überwunden, und man hatte einen effektiven Weg gefunden, um das Projekt rasch voranzubringen.
Schließlich gelang es der BLE, die von der EU vorgeschriebenen Fachmodule bis Ende 2016 fertigzustellen und produktiv zu setzen, und das Gesamtprojekt in der jetzigen Ausbaustufe, einschließlich weiterer Teilprojekte bis Ende 2018 weiter umzusetzen. Damit wurden insgesamt 58 Module, davon 28 der 31 ursprünglich angedachten, sowie 20 weitere mit zusammen 640 Dialogmasken für mehrere hundert Benutzer unterschiedlicher Rollen in Bund, Ländern und bei diversen eingebundenen weiteren Parteien, wie den großen Fisch-Erstaufkäufern, entwickelt und produktiv gesetzt.
Low Code und Design Thinking haben sich bewährt
Das Projekt verlangte von allen Beteiligten Nachsicht und Akzeptanz für neue Wege, nämlich für Low-Code-Technologie und Design Thinking. Die IT-Fachleute der BLE, insbesondere die Software-Entwickler, mussten umlernen und sich schnell mit der Low-Code-Technologie vertraut machen.
Entscheidend für das Projektergebnis war die aktive Mitarbeit der fachlich Verantwortlichen in den Design-Thinking-Teams. Ebenso wichtig war die Low-Code-Technologie und das optimal hierauf abgestimmte phasenagile Vorgehen nach den Prinzipien des Design Thinking. Sämtliche fachlichen Anforderungen konnten mit Low-Code-Mechanismen wie Business Rules, Workflows, interaktiv konfigurierten Datensichten und Benutzeroberflächen umgesetzt werden. Das ging nicht gänzlich ohne eingebettete handgeschriebene Programmfunktionen - aber das widerspricht der Low-Code-Philosophie keineswegs grundsätzlich.
Anders als vielleicht zunächst erwartet hat sich gezeigt, dass die Low-Code-Entwicklungsmethodik nicht auf Kosten der Stabilität, Performance, Sicherheit und sonstiger Qualitätsmerkmale einer Software geht, sondern deutlich weniger Programmfehler und sonstige technische Probleme mit sich bringt. Natürlich sind Low-Code-Entwickler nicht davor gefeit, Fehler zu machen, aber sie profitieren davon, dass die eigentliche Software schon weitgehend fertig ist: Bei Low-Code-Technologien kommen zur Laufzeit fast nur vorgefertigte Programmkomponenten zum Einsatz, und Konfigurationsfehler lassen sich in der Regel mit ein paar Mausklicks beheben und patchen, ohne das gesamte Programmpaket erneut durchtesten zu müssen.
Dies erlaubte ein beschleunigtes Abnahme- und Einführungsverfahren. So mussten zwar im Operations-Bereich einige Abläufe angepasst werden, es war aber möglich, dass neue oder überarbeitete Module binnen weniger Tage produktiv gesetzt und verbliebene Fehler teilweise sogar direkt im Produktivsystem behoben werden konnten.
Gehostet wird das FIT-System im Rechenzentrum der BLE in Bonn. Technisch wäre ein Betrieb in der Cloud möglich, dies stand jedoch aus sicherheitstechnischen, rechtlichen und strategischen Gründen nie zur Debatte.