Entstanden als digitale Variante des schwarzen Bretts, bieten Mitarbeiter- oder Intranetportale heute einen zentralen, geschützten, einheitlich gestalteten Zugang zu unternehmensinternen Informationen und IT-Anwendungen.
Vier Kriterien zeichnen eine praxisnahe Softwareentwicklung aus: Tempo, Wartungsfreundlichkeit des Produkts, Skalierbarkeit sowohl des Entwicklerstabs wie der Software. Anlässlich eines Digitalprojekts bei einer deutschen Einzelhandelskette haben wir mit einem IT-Experten des Klienten ein längeres Interview geführt. Das Unternehmen entwickelt seine Fachapps nach Möglichkeit mit Microservices. Zentrale Erkenntnisse aus dem Gespräch geben wir hier in redigierter Form wieder. Die Aussagen des Interviewpartners sind kursiv gesetzt, unsere Hinweise in Grundschrift. Die Langfassung stellen wir auf Anfrage gerne zur Verfügung.
Zur Vorbereitung hatten wir dem Gesprächspartner einen Kriterien- und Fragenkatalog vorgelegt. Dessen Inhalt hat der IT-Experte aus seiner Sicht priorisiert. Das Ergebnis hat uns überrascht. Ausgerechnet die viel gepriesene Freiheit, die insbesondere agile Vorgehensmodelle Appentwicklern zugestehen, taucht erst am Ende der Liste auf. Auf den vorderen Plätzen stehen Technikthemen wie Modularisierung, Rollout- und Testautomation sowie das Monitoring der Microservices.
Erst danach wirken sich organisatorische Aspekte wie betriebliche Strukturen und die Arbeitskultur aus. Hier erweisen sich agile Vorgehensmodelle als vorteilhaft. Haupttreiber des Projekterfolgs ist aber nicht die Arbeitskultur, sondern das zur Lösung eines Fachproblems angewandte technische Repertoire.
Organisation
Die Appentwickler der Handelskette verteilen sich nicht klassisch-horizontal auf Teams etwa für Backends, Frontends, Middleware, sondern vertikal, das heißt, eine Arbeitsgruppe entwickelt alle Schichten eines Funktionsbausteins.
Wenn an einer großen Applikation zu viele Entwickler parallel arbeiten, gehen Fokus und Verantwortung verloren. Der einzelne Entwickler kann nicht mehr alle fachlichen Aspekte von vorne bis hinten durchdenken. Bei Modulen aus Microservices hingegen bleibt dies möglich. Wenn Backend-Entwickler komplizierte Schnittstellen abliefern, auf denen Frontend-Entwickler aufsetzen müssen, ist im Wortsinn Ärger programmiert.
Das klassische Modell der horizontalen Schichtung der Apps und Teams hat ausgedient. Heute schneidet man beide vertikal entlang funktional vollständiger Module, die sich in Microservices aufteilen. So verstehen die Entwickler den Sinn und Zweck der App besser, kommen mit der Arbeit schneller voran, es entstehen weniger Schnittstellen zwischen Teams, die aus Microservices zusammengesetzte App lässt sich leichter warten.
Methoden und Tools
Wie gut und schnell Entwickler arbeiten, hängt primär von den verfügbaren Methoden und Werkzeugen ab. Einen entscheidenden Anteil am Projekterfolg hat die laufende Integration (Continuous Integration, CI) und Auslieferung (Continuous Delivery, CD) der Microservices. Bei der CI werden die iterativ entwickelten Beiträge des Teams automatisiert in die Gesamtapp eingefügt, ihre Funktion und das Zusammenspiel dabei getestet. Continuous Delivery heißt, nach jeder Programmierrunde den Zwischenstand auszuliefern, um den produktiven Einsatz der Software zu beschleunigen, Feedback der Nutzer einzuholen und die App iterativ zu optimieren.
Die ganze Softwarepipeline muss automatisiert sein. Jedes Rollout kostet Zeit und Geld. Die Entwickler wenden sich an die IT-Zentrale, Tickets für das Rollout werden angelegt und abgearbeitet, manchmal wartet das Team Stunden oder Tage darauf, dass der Kollege in der Zentrale einen Knopf drückt. Frustrierend. Das braucht niemand. Hier schont eine Automation des Rollouts das Budget – und die Nerven!
Wichtig ist auch eine Deployment-Governance, ein Verfahren, das sämtliche Änderungen erfasst und den aktuellen Stand der App verbindlich dokumentiert. Also im Wesentlichen ein Releasemanagement inklusive Festlegung des Funktionsumfangs und Versionskontrolle.
Nur wenn sich jede Änderung an der App im Detail nachvollziehen lässt, wissen wir bei Problemen im Echtbetrieb, wo die Fehleranalyse ansetzen sollte.
Hochgradige Automation rationalisiert nicht nur die Verteilung der Software, sondern auch die Infrastruktur, auf der die App läuft. Die bevorzugte Methode, neue Software schnell und sicher einzusetzen, ist der Betrieb im virtuellen Container, kurz Containerisierung oder Containering genannt.
Das Rollout sollte die Software und die Infrastruktur, auf der sie aufsetzt, umfassen. Das anzuwendende Verfahren heißt Infrastructure as Code oder programmierbare Infrastruktur. Eine Virtualisierung mit Containern hat nur Vorzüge, keine Nachteile. Das Unternehmen behält seinen Softwarestack im Griff, die einzelnen Entwicklungsteams können ihre Rollouts optimal unterstützen. Ein Container enthält alles, was man dazu braucht, von den Umgebungsvariablen über Bibliotheken und die Java-Version bis zur Laufzeitumgebung.
In Betrieb gehen darf eine Software allerdings nur mit einem strengen Monitoring und automatischen Meldungen bei kritischen Zuständen.
Wenn wir einen Geschäftsprozess mit mehreren Microservices abbilden, müssen wir im Detail wissen, wie das Zusammenspiel klappt. Das ist nicht einfach. Dazu brauchen wir Metriken sowohl für den Gesamtprozess wie für die einzelnen Microservices. Nur die Services zu messen und zu analysieren, genügt nicht. Wir müssen den Gesamtablauf als Kette aus Microservices überwachen.
Jedes Entwicklungsteam muss seine Microservices während der gesamten Lebensdauer selbst überwachen. Diese Verantwortung darf man niemals an eine zentrale Stelle abgeben. Was man delegieren kann, sind die Infrastrukturaufgaben, also etwa: Welches Tool verwenden wir zum Monitoring, wer setzt das Tool auf, wer überwacht es? Solche Aufgaben sind in einer Zentrale sogar besser aufgehoben, zumal diese mit Vorgaben für Effizienz in den Teams sorgt.
Die verbreitete, von manchen Quellen empfohlene zentrale Speicherung und Analyse von Logdaten zur Prozesskontrolle erachtet unser Gesprächspartner als weniger relevant. Allerdings muss ein mit Microservices abgebildeter Fachprozess anhand sogenannter Correlation- IDs in seinem Ablauf verfolgbar bleiben.
Erfahrungsgemäß sind Fehler in verteilten Prozessen mit dem zentralen Logsystem allein kaum zu finden. Bei dessen Analyse zeigen die Teams wieder mit den Fingern aufeinander. Selbst wenn das Logsystem mit Correlation-IDs arbeitet, verteilt sich das IT-Wissen auf die unterschiedlichen Teams und es herrscht eine gewisse Scheuklappenmentalität.
Dennoch erweist sich ein zentrales Logging als nützlich. In kompetenter Hand hilft es, den personellen Aufwand bei der Fehleranalyse zu minimieren. Hier sind dann aber eher Fachexperten gefragt als Entwickler. Doch auch wenn sich Fehler damit schneller orten und beheben lassen, heißt das nicht unbedingt, dass sich deswegen das ganze Entwicklungsprojekt beschleunigt.
Arbeitskultur
Eine durchgängig agile Arbeitskultur fördert eine schnelle, passgenaue Softwareentwicklung. Die Vorzüge des agilen Arbeitens lassen sich aber auch auf Teamebene verwirklichen.
Zum agilen, autonomen Arbeiten braucht man interdisziplinäre Teams. Nur dann kann jedes Team einen vollständigen, runden Beitrag abliefern. Zudem müssen sich Teams weniger untereinander abstimmen.
Kleine Teams sind ideal, zumal dies einer Polarisierung innerhalb einer größeren Abteilung vorbeugt.
Bei kleinen Einheiten sinkt der Projektmanagement-Aufwand. Die Teams arbeiten autonom, beim Rollout sind weniger Interdependenzen zu beachten. Hier kommt es darauf an, eine Methodik zu wählen, die eine agile Zusammenarbeit und Skalierung unterstützt. Ob man sich für Scrum of Scrums entscheidet, für SAFe, LeSS oder das Spotify-Modell, ist im Grunde egal. Hauptsache, man verfügt überhaupt über Strukturen zur Zusammenarbeit. Natürlich werden einzelne agile Teams oder Projekte in konservativ geführten Unternehmen immer wieder gegen Wände laufen. Manche werden mit starren Strukturen und Eckpunkten hadern. Das kostet Energie, bremst die Softwareentwicklung, reibt die agilen Teams auf. Trotzdem lässt sich Software auch in einer traditionellen Arbeitskultur agil entwickeln. Früher oder später werden weitere Ressorts und schließlich das ganze Unternehmen agil arbeiten wollen. Oft ist es sogar besser, klein anzufangen und eine Abteilung nach der anderen zu transformieren.
Freiheit
Agile Softwareentwicklung heißt, den Teams weitgehend freie Hand zu lassen. Doch wo liegen die Grenzen dieser Freiheit? Erstreckt sie sich auch auf die Wahl der Entwicklungsumgebung, Frameworks und Tools? Entscheidend sind hier die Zeit und die Kosten, die anfallen, bis ein neuer Entwickler produktiv arbeitet.
Ein Entwickler muss vom ersten Tag an jederzeit in der neuen Systemumgebung arbeiten können. Unternehmen sollten messen, wie lange es bei ihnen dauert, bis ein neuer Kollege die erste Codezeile geschrieben hat. Gut wären maximal fünf Minuten. Dazu muss die IT-Zentrale einiges tun. Sie muss standardisieren, auch die Entwicklungsumgebung, was nicht jedem passen wird, weil es die Wahl der Arbeitsmittel einschränkt.
Das Betriebssystem des Programmierrechners darf keine Rolle spielen. Der Entwickler sollte nur einen Docker-Container mit der Arbeitsumgebung auf seinem Rechner installieren müssen, bevor er loslegt. Nur dann ist er vom Rechner und Plattformen unabhängig.
Auch die Toolsets sollten vorgeschrieben sein. Damit erspart man sich manche Diskussion über bevorzugte Methoden und Sprachen. Die Standardisierung erhöht die Betriebssicherheit nicht nur aus technischer, sondern auch aus rechtlicher Sicht. Dieses Kriterium ist bei intern entwickelter Software zentral.
Bei der Technik sollte sich die Freiheit darauf beschränken, etwa zwischen einer relationalen Datenbank, einem Document-Store, einer NoSQL-Datenbank oder einer Big-Data-Bank zu wählen. Aus dem breiten Spektrum der Optionen sollte die IT-Zentrale jeweils eine einzige bereitstellen. Passend zur Funktion eines Microservices legt das Team die Art der Persistenz der darin verarbeiteten Daten fest und nutzt dann die dafür vorgegebene Option. Geht es aber darum, ob ein Team in Java, Scala oder Python programmiert, habe ich eine dezidierte Meinung: nein zur freien Wahl der Programmiersprache je Microservice.
Es muss im Unternehmen fertige Softwarestacks geben, auf denen die Entwickler geschult sind und über die sie sich austauschen. Die Wahl einer bestimmten Ausprägung des Stacks kann man dem Team überlassen.
Sogar Frameworks und Bibliotheken würde ich vorgeben. Zumindest sollte die Auswahl einer IT-Governance unterliegen. Ich bezweifle, dass den Entwicklerteams sämtliche Rechtsfolgen klar sind, die sich aus der Wahl einer Bibliothek ergeben können. Es gibt zu viele Lizenzmodelle. Wer nicht aufpasst, verpflichtet sich mit der Wahl der Bibliothek zur Veröffentlichung des Quellcodes aller damit entwickelten Apps. Das Unternehmen braucht also wenigstens einen Prozess zur Freigabe und Kontrolle der Bibliotheken und anderer Arbeitsmittel.
Vorgaben müssen an zentraler Stelle hinterlegt sein. Im Grunde ist die Entwicklung, Pflege und Durchsetzung interner Standards ein Vollzeitjob. Entscheidungen über solche Vorgaben treffen Gremien aus Vertretern der davon betroffenen Teams, sogenannten Gilden, in einem offenen Prozess. Allerdings ist auch klar, dass man nicht zu jedem potenziellen Problem eine Stackvariante vordenken kann.
Vorteile der Standardisierung:
Je kleiner die Auswahl an Methoden und Tools, desto kürzer die Einarbeitung und desto routinierter der Umgang damit. Zudem können die Teams einander kurzfristig verstärken, wenn alle technisch auf demselben Stand sind. Auch Schulungen lassen sich leichter organisieren. Experimentiert ein Team indes im Alleingang mit alternativen Ansätzen, produziert es bald Insellösungen, die nur unter größtem Aufwand in die Arbeit der anderen zu integrieren sind.
Fazit
Die Projekterfahrung unseres Gesprächspartners in der agilen Softwareentwicklung hebt sich in einigen Punkten von der „reinen Lehre“ aus der Fachliteratur ab. Im Umfeld des Experten hat sich eine straffere Struktur bewährt, die die Wahlfreiheit der Entwickler zugunsten einer höheren Standardisierung ein Stück weit beschneidet. Inwieweit sich dieses Modell für andere Unternehmen eignet, wäre von Fall zu Fall durch eine Bestandsaufnahme und Bedarfsanalyse zu klären.
Wir danken unserem Gesprächspartner für die interessanten Einblicke.
Das Gespräch führten unsere Experten für agile Softwareentwicklung mit Microservices Claus Ried und Dirk Siegel.
Dieser Artikel ist nur einer von vielen aus unserer Broschüre „Consileon Thema: Trends in der modernen Softwareentwicklung“. Wenn wir Interesse geweckt und Sie Lust auf mehr bekommen haben, dann bestellen Sie sich gerne die gesamte Broschüre, indem Sie auf den untenstehenden Button „Broschüre bestellen“ klicken. Die Themen der Broschüre umfassen u.a. den praktischen Nutzen künstlicher Intelligenz, agile Softwareentwicklung in der Handelsbranche, der gewinnbringende Einsatz von Microservices und das Thema intelligenter Arbeitsplatz.
Die Autoren: Dirk Siegel
Dirk Siegel ist Associate Partner bei Consileon und leitet seit mehr als einem Jahrzehnt für uns bei unseren Kunden vor Ort Softwareprojekte. Er hilft den Kunden bei der agilen Transformation und ist ein Facilitator für den organisatorischen Wandel von IT-Bereichen hin zu offenen, schnellen und effizienten Entwicklungsteams. Die strategische Ausrichtung der IT-Organisationen unserer Kunden werden von ihm kritisch und partnerschaftlich begleitet.
Claus Ried ist Senior Specialist bei Consileon und unterstützt Kunden bei der Architektur und technischen Umsetzung diverser unternehmenskritischer Softwareprojekte. Neben verschiedenen Rollen im Enterprise- Java-Umfeld und als technischer Berater bei Finanzdienstleistern sowie mittelständischen Unternehmen liegt sein aktueller Fokus auf Cloud-Architekturen und Containerisierung.
Entstanden als digitale Variante des schwarzen Bretts, bieten Mitarbeiter- oder Intranetportale heute einen zentralen, geschützten, einheitlich gestalteten Zugang zu unternehmensinternen Informationen und IT-Anwendungen.
Einsatzplaner teilen das Personal zeitlich und örtlich auf anstehende Arbeiten auf. Dabei handelt es sich um eine operative Aufgabe mit kurz- bis mittelfristigem Zeithorizont. Zahlreiche Randbedingungen fließen in den Einsatzplan ein, darunter:
Am Kiosk lancierte Eigenwerbung sowie Kombinationen aus Angeboten des Händlers und des Loyalty-Programmanbieters binden Stammkunden stärker an die Marke und motivieren Neukunden zur Teilnahme.
