Peter Diefenthäler*

Motivation

Die Digitalisierung schreitet voran! Geht es den einen zu langsam, gibt es wieder andere, denen es zu schnell geht. Beiden Parteien gemeinsam ist, dass es das richtige Mindset braucht, um den Herausforderungen der Digitalisierung und der damit einhergehenden Transformation Tempo zu verleihen oder mit ihr Schritt halten zu können.

Die Technologien sind in der heutigen Zeit nicht mehr das Problem, man schaue sich nur die Landkarte der Cloud Native Computing Foundation (CNCF) an. Vielmehr sind es die Themen Organisation und Kultur, die bei allen Beschäftigten über alle Hierarchien hinweg ein gewisses Mindset erfordern, um als Firma oder Institution erfolgreich zu sein und am Markt und bei den Bürgern bestehen zu können.

Abbildung 1: Don’t go with the rest of the world, change your mindset to be different

Produktgedanke

In der traditionellen Datenverarbeitung sind Monolithen noch weit verbreitet und sie sind im Allgemeinen über lange Zeiträume organisch gewachsen, wie man so schön sagt. Änderungen an diesen Dinosauriern der IT-Geschichte müssen sorgfältig geplant werden. Die Architektur wurde meistens zu Beginn erstellt und musste perfekt sein, denn eine große Zahl an Entwicklern goss die Ideen in Code und nachträgliche Änderungen hätten unter Umständen große Mengen an Sourcecode betroffen und das wäre teuer geworden.
Die Weiterentwicklung lief in der Regel in Form von Projekten ab, was entscheidende Nachteile mit sich bringt. Projekte sind per Definition nur von vergleichsweise kurzer Dauer und haben ein definiertes Ende. Sie kennen keine Wartung und oft führt Zeitdruck und mangelnde Disziplin dazu, dass die Architektur verwässert und der viel gefürchtete „Big Ball of Mud“ entsteht. Projekte sind weitgehend vom Lebenszyklus der Anwendung abgekoppelt und verfolgen die unterschiedlichsten Ziele bei der Weiterentwicklung der Anwendung. Das führt über kurz oder lang zu Problemen beim Betrieb und der Qualität.

Hier ist Umdenken angesagt, indem man den Produktgedanken in den Vordergrund stellt. Produkte weisen einen Lebenszyklus auf und haben den Vorteil, dass sie idealerweise ein dediziertes Team in der Verantwortung haben. Änderungen werden in Form von Feature-Requests manifestiert, Wartung und Betrieb sind fest eingeplant. Das funktioniert natürlich nur, wenn die Produkte eine gewisse Größe nicht überschreiten und eine fachliche Domäne repräsentieren. Sie können sich in schnellen Zyklen weiterentwickeln, man kann auf Änderungen schnell reagieren und technisch können sie leichter und mit geringerem Aufwand beziehungsweise Risiko auf einem aktuellen Stand gehalten werden.

Diese Sichtweise nimmt gerade richtig Fahrt auf – Stichwort „API-as-a-Product“.

Abbildung 2: API-as-a-Product (by Gitesh Koli)

Außerdem sollten Unternehmen sich mit dem Gedanken „Data-as-a-Product“ beschäftigen. Das ist ein vielversprechender Trend, operationale und analytische Daten zu trennen und zu strukturieren, um sie unterschiedlichen Nutzergruppen für die autonome Nutzung zur Verfügung stellen zu können.

DevOps

Aus dem Produktgedanken leitet sich dann gleich der nächste Impuls für ein Umdenken ab:
DevOps ist in erster Linie eine neue Denkweise, die organisatorischen Silos Entwicklung und Operations aufzutrennen, die sich in vielen Unternehmen gebildet haben. Mit DevOps landen alle Tätigkeiten der Produktentwicklung in einem Team: Requirement Engineering, Entwicklung, Test, Betrieb und Monitoring.

Bei monolithischen Architekturen tut man sich schwer, all die genannten Aufgaben im DevOps-Modus zu erfüllen. Das liegt zum einen an der Größe der Applikation (Umfang des Sourcecodes, Anzahl der Module, etc.) und damit an der Größe des Teams. Zum anderen aber auch an der Komplexität und fehlenden Flexibilität der eingesetzten Infrastruktur in Form von Mainframes oder Enterprise-Application-Servern.

Mit dem Aufkommen der modernen, flexiblen und leistungsfähigen Cloud-Plattformen und der Cloud-nativen Entwicklung hat DevOps einen ganz neuen Grad an Attraktivität erlangt. Ops ist auf einmal viel einfacher geworden und auch die Entwicklung hat Fortschritte gemacht. Einstiegshürden wurden dramatisch gesenkt und der Spaßfaktor, in diesen Umgebungen zu arbeiten, darf nicht unterschätzt werden. Mit den Paradigmen „You Build it, you run it“ und „Quality built in“ ist das neue Mindset perfekt beschrieben.

Mit DevOps etabliert sich eine neue Kultur in Unternehmen und Organisationen. Das bedeutet ein neues Mindset nicht nur in der IT und den Produktteams, sondern auch im Management und der Personalführung.

Kultur

Das Thema Kultur stellt in meiner Wahrnehmung die derzeit höchste Herausforderung in Sachen Mindset dar. Alle bisher angesprochenen Punkte funktionieren nicht, wenn die Kultur nicht dazu passt.

Autor Peter Diefenthäler ist Softwarearchitekt bei der ARS Computer und Consulting GmbH.

Man muss sich beispielsweise den Umgang mit Fehlern ansehen. Fehler sind per se ärgerlich und sorgen in der Regel für schlechte Stimmung, zusätzliche Aufwände und damit zu Abstrichen bei der Produktqualität, die dann die Kunden ausbaden müssen. Da gibt man oft dem fatalen Impuls nach, erst einmal Schuldige zu suchen, an denen man seinen Frust loswerden kann. Seien wir mal ehrlich: Das führt zu zusätzlichen Verzögerungen und es vergeht wertvolle Zeit, bis der Fehler gefunden und behoben ist und der Kunde weiterarbeiten kann.

Wäre es nicht besser, wenn alle im Team alles stehen und liegen lassen würden, um sofort gemeinsam mit der Fehlersuche zu beginnen, ihn zu beheben und so schnell wie möglich einen Fix an die Kunden auszuliefern?

Gefragt ist also eine offene, aktive Fehlerkultur, in der Fehler akzeptiert und sofort nach einer Lösung gesucht wird, anstelle den oder die Schuldigen zu suchen und Angst und Unsicherheit zu verbreiten. In einer funktionierenden Fehlerkultur wird Innovation nicht gebremst, indem man um jeden Preis Fehler vermeidet, denn sie dienen auch dazu sich weiterzuentwickeln und kalkulierte Risiken einzugehen. Nur so reizt man das Potenzial von Agilität und die schnellen Entwicklungszyklen der modernen Plattformen zum Wohl des Unternehmens aus.

Die Kulturthemen Lernen und Experimentieren sind auf den ersten Blick schon leichter zu realisieren. Doch auch hier liegt der Teufel im Detail: Termine stehen im Raum und oft ist die Personaldecke dünn. Leider existiert auch hier keine Alternative dazu, Zeit zum Lernen und Experimentieren einzuplanen. Nur so wahrt man die Chance, dass Softwareentwicklung dem neuesten Stand der Technik entspricht, die modernen Plattformen optimal ausnutzt werden und damit der größte Nutzen für die Kunden gestiftet wird. Die Cloud-native Entwicklung steckt zeitlich gesehen noch in den Kinderschuhen und trotz einer hohen Qualität an Lösungsangeboten braucht es Zeit, diese zu finden, zu erlernen und richtig einzusetzen.

Abbildung 4: Kommunikation braucht Zeit und Raum

Das Fatale mit der Kultur ist, dass man sie nicht auf Knopfdruck ändern oder sie gar verordnen kann, denn eine Kultur entsteht durch diejenigen, die sie leben. Änderungen und Anpassungen geschehen inhärent und dieser Prozess braucht Zeit und Raum.

Shift Left

Die Zeiten, Qualitätssicherung als Silo in der Organisation zu manifestieren, sind vorbei. Viel zu oft wird diese Abteilung als Endgegner gesehen und oft genug scheitert die Auslieferung daran, dass Fehler erst am Ende der Entwicklungszeit erkannt werden. Das ist bekanntermaßen teuer und man riskiert, Kunden zu verlieren, wenn sich die Auslieferung immer wieder verzögert oder die Qualität schlechter wird. Erfordern die Fehler dann noch strukturelle Änderungen in der Architektur, kann das bei monolithischen Anwendungen zu kaum abschätzbaren Aufwänden führen.

Abbildung 5: Zeit, auch bei der Qualitätssicherung umzudenken

Shift Left – Qualität von Anfang an – ist in diesem Fall die neue Denkweise! Hier brechen wir mit alten Traditionen und das hat immense Auswirkungen auf Arbeitsweisen und Verantwortung aller Beteiligten. Architekten sollten früh Qualitätsbäume mit Qualitätskriterien erstellen und Szenarien für deren Messbarkeit entwerfen. Die Softwareingenieure sichern die Qualität von Anfang an durch automatisierte Tests, die zusätzlich zur Funktionalität deutlich mehr Fachlichkeit als in der Vergangenheit abdecken sollten. Das erfordert mehr Zusammenarbeit mit den Requirement Engineers und den Quality Engineers, die jetzt in allen Phasen der Entwicklung kontinuierlich mit einbezogen werden. Sie sehen es schon. Das erfordert sehr viel Umdenken bei allen Mitgliedern der Teams und auch beim Management.

Es gilt Ängste abzubauen, wenn sich traditionelle Berufsbilder verändern und vermeintlich Mehrarbeit auf bestimmte Rollen zukommen könnte. Da bekommt der Begriff Fullstack eine ganz neue Bedeutung: Es geht nicht mehr nur darum, verschiedene technische Fertigkeiten zu besitzen, sondern um die Einstellung, neue Herausforderungen anzunehmen und mit den Aufgaben zu wachsen. Fehlerkultur und mehr Eigenverantwortung in den Teams sind hier entscheidende Faktoren, die das Management verstehen, fördern und letztendlich auch vertreten muss.

Open Source

Abschließend noch ein paar Gedanken zum Thema Open Source. Für viele bedeutet Open Source eine Evolution, stellt doch das „kollaborative Entwickeln“ einen Innovationstreiber dar. Nach Angaben der Cloud Native Computing Foundation (CNCF) enthalten 98 Prozent der Code-Basen für den Aufbau von Cloud-Infrastrukturen Open-Source-Komponenten. Open Source ist mittlerweile fast überall und bietet die Chance, auf eine Fülle von individuell entwickelten Lösungen und Lösungsansätzen zurückgreifen zu können.

Abbildung 6: Open Source

Was hat das jetzt mit dem Mindset zu tun? Open Source funktioniert nur, wenn man nicht einfach nur konsumiert, sondern sich auch beteiligt bzw. überdies neue Entwicklungen der Community zur Verfügung stellt und damit Nutzen für die Gemeinschaft stiftet. Und ja, Open Source kommt nicht zum Nulltarif. Engagement kostet Geld und man muss sich darüber im Klaren sein, dass es sich bei Open Source um ein eher schwaches Sicherheitsglied in der Software Supply Chain handelt, wie man zum Beispiel an Log4j sehr gut sehen konnte.

Mit einem gesunden Maß an Aufmerksamkeit, Innovationsgeist und Engagement gewinnt man dagegen mehr Spielraum bei der Entwicklung für die eigene Geschäftsdomäne und wird damit konkurrenzfähiger am Markt.

Fazit

Die Welt dreht sich weiter. Hat man vor 25 Jahren noch von EDV gesprochen, ist heute der Begriff IT üblich. Spinnt man diese Beobachtung noch weiter, kann man heute aus IT einfach nur noch i machen, denn der Trend zur mobilen und dynamischen Nutzung vielfältiger Services ist unübersehbar. Ohne das passende Mindset und die Bereitschaft, sich den Herausforderungen der Softwareentwicklung im 21. Jahrhundert zu stellen, wird man über kurz oder lang nicht mithalten können.

Alle angesprochenen Themen – und das ist nur eine kleine Auswahl – haben nicht zu unterschätzende Auswirkungen auf die Organisationsstrukturen der Unternehmen und Institutionen. Hier hat die Reise gerade erst begonnen!

Autor

* Der Autor Peter Diefenthäler arbeitet als Softwarearchitekt bei der ARS Computer und Consulting GmbH in München. Mit vielen Jahren Erfahrung in der Produktentwicklung auf dem Weg vom Mainframe bis hin zu aktuellen verteilten Anwendungen, beschäftigt er sich heute mit den Schwerpunkten Cloud-native Entwicklung, Migration großer Softwaresysteme sowie Digitale Transformation und hält Trainings und Schulungen in diesen Bereichen.

E-Mail: peter.diefenthaeler@ars.de

Bildquellen:

Aufmacher: Photo by Kylie De Guia on Unsplash
Abbildung 2: Medium: Apis are products and products need a store
Abbildung 3: Trendreport.de: DevOps treibt Cloud-First in der Finanzbranche an
Abbildung 4: Photo by Austin Distel on Unsplash
Abbildung 5. Photo by Roger Bradshaw on Unsplash
Abbildung 6: Words Collage Cloud – stock.adobe.com

Creative Commons Lizenz CC BY-ND 4.0

Sie dürfen:

Teilen — das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten und zwar für beliebige Zwecke, sogar kommerziell.

Der Lizenzgeber kann diese Freiheiten nicht widerrufen solange Sie sich an die Lizenzbedingungen halten.

Unter folgenden Bedingungen:

Namensnennung — Sie müssen angemessene Urheber- und Rechteangaben machen, einen Link zur Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung besonders.

Keine Bearbeitungen — Wenn Sie das Material remixen, verändern oder darauf anderweitig direkt aufbauen, dürfen Sie die bearbeitete Fassung des Materials nicht verbreiten.