Agile Entwicklungsumgebung im klassischen Unternehmen

oder: Warum sich Entwickler immer wieder mit unzumutbaren und unsinnigen Rahmenbedingungen in großen Projekten herumschlagen müssen.

Ungeahnte Rahmenbedingungen

Wie bei conventic konnten wir in meinen früheren Technologie Start-ups im Rahmen unserer finanziellen Möglichkeiten ideale Voraussetzungen für die Software-Entwickler¹ schaffen. Neueste Technologien, hervorragender Austausch mit den Kollegen, Eigenverantwortung, kurze Entscheidungswege und agile Entwicklung wie sie im Buche stehen.

Ganz anders ist die Situation, wenn ein das Geschäft veränderndes Digitalisierungsprojekt in einem Konzern oder etablierten Unternehmen stattfindet. In diesem Fall trifft die künftige Anwendung, IT-Unterstützung oder Transformation zwangsläufig früher oder später auf das ganze Unternehmen in seiner historisch gewachsenen Form.

Im letzten Blog-Beitrag habe ich erwähnt, wie ein Unternehmen immer auch seine eigene DNA mitbringt und was das für die Stakeholder bedeutet, die massiv von dem Projekt betroffen sind, aber nicht zum Kernteam der Entwicklung oder Transformation zählen.

In diesem Beitrag widme ich mich dem Aspekt, wie die unternehmensinternen Rahmenbedingungen, die sogenannten Constraints, die Entwicklung und das agile Projekt in der realen Welt auch technisch einschränken. Es ist überflüssig zu erwähnen, dass dies die Motivation und Effizienz des agilen Teams dramatisch beeinflusst.

Viele große Unternehmen haben in der Vergangenheit erkannt, dass Innovation in Form von neuen Start-ups und Ausgründungen nur dann erfolgreich ist, wenn die “Ketten”, die ein Konzern üblicherweise im Laufe der Jahre in Form von Konzernrichtlinien entwickelt hat, für Entrepreneurs in weiten Zügen aufgehoben wird.

Für eine Entwicklung, die den Konzern selbst “genetisch” verändert, ist dies jedoch nicht so einfach möglich.

Pain Points

Etablierte Unternehmen besitzen in der Regel Fachabteilungen mit Verantwortlichkeiten für Bereiche wie Recht, Datenschutz, Compliance, Finanzen usw. 

Spätestens mit der Einführung der DSGVO in 2018 hat jeder Entwickler erfahren, wie sich Datenschutz direkt auf seine Arbeit auswirkt. Datenmodelle, Architektur und IT-Prozesse müssen so ausgelegt oder angepasst werden, dass sie nachweisbar die Anforderungen der Datenschutz-Grundverordnung erfüllen. Dieses Thema werde ich aufgrund seiner Bedeutung in einem späteren Beitrag noch einmal im Detail aufgreifen.

Besonders beschwerlich und auf den ersten Blick nicht nachvollziehbar sind für die Entwicklerteams oft gewachsene Konzernvorgaben, die nicht mehr zeitgemäß erscheinen oder eine massive Beeinflussung der Arbeitsfähigkeit bedeuten. 

Rahmenbedingungen, die ich oft beobachte, sind:

• Lizenzvorgaben: Konzernrichtlinien schreiben vor, welche Lizenzen und Produkte genutzt und installiert werden dürfen; alle bisher unbekannten Produkte erfordern eine Sonderregelung.
• Einsatz von Bibliotheken: Der Einsatz von Bibliotheken wird stark eingeschränkt. Nur geprüfte und aktuell gehaltene Bibliotheken dürfen genutzt werden; alle neuen Bibliotheken erfordern eine Sonderregelung.
• Ausstattung und Rechte der Entwickler: Die Rechte für Administration und Installation auf der Entwicklungsumgebung ist eingeschränkt. Die Rechner müssen wie jeder Arbeitsplatzrechner in die Software-Verteilung und Inventarisierung einbezogen werden.
• Netzsegmente und Firewall-Regeln: Aus Sicherheits- und Datenschutzgründen sind Zugriffe und Rechte wie im Konzern eingeschränkt. Remote-Arbeit erfolgt über VPN-Verbindung. Datentransferraten sind für Entwickler nicht ausreichend. 
• Testdaten: Personenbezogene Realdaten sind mit der DSGVO strikt untersagt. Wenn zur Fehlerbehebung erforderlich, dann nur mit 4-Augen-Prinzip und Datenschutzverantwortlichem.
• Cloud Computing: Nutzung von Rahmenvertrag und strikte Konzernvorgaben zu Sicherheit, Produkten, Beschaffung, Betrieb etc.
• Deployment Prozesse: Anpassung von Freigaben und Prozessen bei der Übergabe von Entwicklung an den Betrieb passen oft nicht zu aktuellem IT-Betrieb im Konzern.

Dies sind nur einige der Konflikte, die regelmäßig in Retros von den Entwicklern angesprochen werden. Oft gibt es dafür temporäre Ausnahme- oder Sonderregelungen für den Zeitraum der Entwicklung. 

Aus Sicht des Unternehmens fängt das eigentliche Problem erst richtig mit dem Wirkbetrieb an. 

Was tun?

Spätestens mit dem Übergang in den Pilot- oder gar Wirkbetrieb tauchen viele der Probleme aus der Entwicklungsphase dann aber wieder auf. Temporäre Lizenzen und Bibliotheken müssen zum festen Inventar des Unternehmens werden oder aber ersetzt werden. Deployment-Prozesse müssen harmonisiert werden usw.

Es gibt Unternehmen, welche die Strategie wählen, die Weiterentwicklung und den Betrieb an einen externen Dienstleister oder eine eigene Betreibergesellschaft auszulagern. Andere Unternehmen bilden eine eigene Betriebsmannschaft, die für  moderne Entwicklungs- und Betriebsumgebungen besonders qualifiziert ist. 

Einige der oben genannten Themen finden wir aber regelmäßig, wenn wir die Konzern-Revision bei IT-Audits unterstützen. So nimmt der Umfang von nicht aktualisierten und unzureichend geprüften Bibliotheken dramatisch zu. Daher ist es auch nicht verwunderlich, dass Sicherheitsvorfälle wie die kritische Schwachstelle in Java-Bibliothek Log4j regelmäßig gemeldet werden.

Für das Ergebnis eines geschäftskritischen Digitalisierungsprojektes stellt das eine erhebliche Bedrohung dar. Doch wie soll man damit umgehen?

Wir freuen uns auf Euer Feedback!

Fußnoten

1: Aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung der Sprachformen männlich, weiblich und divers (m/w/d) verzichtet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.