Alle Beiträge von Volker Roßmann

Von klassischen Enterprise Applikationen zu Cloud-Native Anwendungen

Mit meinem Team bei der EXXETA AG arbeite ich unter anderem an Enterprise Software-Lösungen für die Cloud. Moderne Web-Anwendungen und Cloud-Transformationen bilden unseren Tätigkeitsschwerpunkt. Dabei geht es nicht einfach darum, bestehende Applikationen in der Cloud auszuführen. Vielmehr sind maßgeschneiderte Software-Architekturen, die passende Organisation und eine entsprechende Kultur gefordert. Ein Cloud-Native Ansatz.

Was bedeutet Cloud-Native konkret? Die Cloud Native Computing Foundation (www.cncf.io) beantwortet diese Frage aus der technischen Perspektive folgendermaßen: Containerisierung, dynamische Orchestrierung, Microservices. Dies bedeutet zum einen, dass alle relevanten Komponenten in einem Container, z. B. Docker, gekapselt werden. Zum anderen werden die notwendige Verwaltung und das Management komplexer Container-Landschaften durch Orchestrierungs-Lösungen wie Kubernetes übernommen. Die Anwendung selbst setzt sich in diesem Szenario aus einer Vielzahl von Microservices zusammen.

Cloud-Native bedeutet darüber hinaus auch die Abkehr von hierarchischen Organisationen mit Projektmanager und Fachspezialisten. Projekte werden durch crossfunktionale Teams mit starkem Fokus auf ein Produkt und dessen Nutzen umgesetzt. Silos wie Software Entwicklung, System Administration, Qualitätssicherung, Betrieb, Releasemanagement oder Projektmanagement werden aufgelöst und durch neue Modelle der Zusammenarbeit wie z. B. DevOps ersetzt.

Die kontinuierliche Auslieferung neuer Funktionalität an Kunden und Nutzer ist ein weiterer Aspekt von Cloud-Native. Dabei sind auf einer technischen Ebene Prozesse und Werkzeuge für Continous Integration und Continous Delivery in den Entwicklungsteams bereits zum Standard geworden. Cloud-Native bedeutet allerdings mehr. Eine Organisation muss auch tatsächlich darauf ausgerichtet sein, neue Funktionalität direkt und auf Ebene von Business-Funktionen oder Microservices produktiv zu nehmen.

Grundsätzlich stellt sich die Frage, warum wir überhaupt einen Cloud-Native Ansatz verfolgen sollten. Was ist unsere Motivation?

Aktuell herrscht weitestgehend Konsens darüber, dass Unternehmen, die sehr schnell auf Kundenbedürfnisse reagieren können, erfolgreicher sein werden als andere. Geschwindigkeit ist entscheidend. Bei vielen Enterprise Applikationen wird ein Releasezyklus allerdings noch immer in Wochen oder Monaten geplant. Das Risiko für ein einzelnes Release ist sehr hoch, Änderungen der Funktionalität sind teuer und aufwendig. Bei einem Cloud-Native Ansatz können Deployments im Gegensatz dazu mehrmals täglich, stündlich oder minütlich durchgeführt werden. Änderungen lassen sich gewissermaßen direkt umsetzen. Das Risiko ein „Release“ zu veröffentlichen reduziert sich damit drastisch. Auch können bei einer Cloud-Native Anwendung auf Basis von Microservices einzelne Business-Funktionen schnell und unabhängig voneinander deployed werden.

Schnell zu sein alleine ist natürlich nicht ausreichend. Ebenso ist es erforderlich, dass das erstellte System die notwendige Zuverlässigkeit aufweist. Klassische Enterprise Applikationen werden oft in einer Designphase vor Entwicklungsstart entworfen, durch umfangreiche Architektur Reviews überprüft, detailliert dokumentiert und langlaufenden Regressionstests unterzogen. Ziel ist immer, die Zahl der Fehlerfälle in Produktion zu verringern. Leider oft wenig erfolgreich.  Durch die Verwendung von Microservices sind unter anderem beim Auftreten eines Fehlers in einer Cloud Native Applikation nur kleine Anwendungsbereiche betroffen. Im Idealfall eben nur der entsprechende Microservice. Um kaskadierende Fehler zu vermeiden, werden Microservices fehlertolerant ausgelegt und lose gekoppelt. Die transparente Überwachung der Anwendung ermöglicht meist auch eine automatisierte Wiederherstellung im Fehlerfall. Nicht zuletzt ist die Einführung neuer Technologien ohne größeres Risiko für das Gesamtsystem möglich, da nur einzelne Services betroffen sind.

Auch die Wirtschaftlichkeit und Effizienz eines Systems sind wichtige Faktoren. In Bezug auf die Skalierbarkeit wird bei klassischen Enterprise Applikationen in vielen Fällen der Worst Case betrachtet. Die dabei gestellte Frage lautet: Welche maximale Last kann unter Umständen auftreten. Entsprechend werden Server und Infrastruktur bemessen. Die meiste Zeit bleiben diese Ressourcen allerdings ungenutzt. Was wenig effizient und teuer ist. Cloud-Native Anwendungen hingegen skalieren horizontal und nutzen nur die aktuell notwendigen Ressourcen. Verwaltet und bereitgestellt durch den Cloud-Provider kann diese Auslagerung die Investitionskosten für Unternehmen erheblich reduzieren. Die horizontale Skalierung einer Cloud-Native Anwendung wird durch den auf Microservices basierenden Architekturansatz optimal unterstützt.

Nicht zuletzt lautet die Prämisse für eine Cloud-Native Anwendung Mobile-First. Enterprise Applikationen wurden noch vor wenigen Jahren für den typischen Fall eines Desktop-Benutzers entworfen. Dies hat sich grundlegend geändert. Es gibt heute eine Vielzahl von Endgeräten und Zielplattformen, der Desktop spielt eine immer geringere Rolle. Mobile Geräte wie Smartphones und Tablets bilden längst die große Mehrheit und sind für den Benutzer immer verfügbar. Dies macht sich im Nutzerverhalten deutlich bemerkbar und hat Einfluss auf die notwendige Systemarchitektur. Einzelne Business-Funktionen werden viel häufiger und zu jedem denkbaren Zeitpunkt genutzt. In diesem Zusammenhang bedeutet Mobile-First natürlich mehr als nur die optimierte Darstellung auf einem kleineren Bildschirm.

Neben den technischen Aspekten ist für die Entwicklung einer Cloud-Native Anwendung also ein ganzheitlicher Ansatz entscheidend. Sowohl Organisation als auch Kultur spielen eine große Rolle. Wie Eingangs erwähnt wird Software heute zwar mit Hilfe agiler Methoden entwickelt und durch Continous Delivery Prozesse automatisiert „ausgeliefert“. Häufig existiert dann allerdings ein organisatorischer Bruch in Form klassischer Test- oder Releaseprozesse. Den Fokus gilt es daher auf Kunden und Nutzer zu legen. Neue Funktionen und damit Mehrwert müssen kontinuierlich zur Verfügung gestellt werden. Dies erfordert die entsprechende Haltung bei allen Beteiligten an der es beständig zu arbeiten gilt. Ganz im Sinne der agilen Softwareentwicklung durch Inspect and Adapt.

 

Literatur und Quellen

[1] Stine, Matt (2015): Migrating to Cloud-Native Application Architectures. Sebastopol, CA 95472: O’Reilly Media.

[2] Cloud Native Computing Foundation: www.cncf.io

Projektaudit – Softwareprojekte aus der Krise führen und kontinuierlich verbessern

„Die Suchfunktion ist zu langsam und funktioniert nicht richtig!“, sagt der Kunde. Und schon geht’s ran an die beauftragte technische Analyse und Fehlersuche. Nach kurzer Zeit ist klar, dass nichts klar ist. Was genau heißt „funktioniert nicht richtig“? Und wie schnell ist schnell genug?

Im Gespräch mit dem Kunden wird deutlich, dass das Projekt insgesamt in Verzug ist, die Anforderungen nicht dokumentiert sind und das agile Vorgehensmodell neu eingeführt wurde. Der verantwortliche Senior Projektmanager spricht nicht mehr mit dem technischen Projektleiter und umgekehrt. Ein typisches Beispiel aus der Praxis. Die Frage ist nun, was tun?

Bei der EXXETA AG wende ich mit meinem Team die intern standardisierte „Service Komponente“ Projektaudit an. Diese schafft den methodischen Rahmen, um Softwareprojekte ganzheitlich zu betrachten und zu bewerten. Ganzheitlich meint hier sowohl die Sicht auf technische Belange als auch auf die gelebten Projektprozesse. Ein Projektaudit ist dabei grundsätzlich sowohl für die direkte Krisenintervention als auch für einen kontinuierlichen Verbesserungsprozess (KVP) geeignet.

Zunächst eine grundsätzliche und wichtige Frage vorweg: Warum schlagen wir die ganzheitliche Betrachtung als Lösungsansatz vor? Auf Basis unserer Projekterfahrung sind für den Erfolg eines Projekts immer mehrere Faktoren relevant. Um ein Projekt zu optimieren oder aus der Krise zu führen, ist es nicht ausreichend, nur einen Aspekt zu betrachten. Wichtige Faktoren im Bereich der Projektprozesse sind zum Beispiel Kommunikationsstrukturen oder die Vorgehensweise bei der Anforderungsdefinition.

Die Service Komponente Projektaudit definiert ein stufenweises Vorgehen in mehreren Phasen. Der Phasenablauf kann ganz im Sinne eines kontinuierlichen Prozesses in weiteren Iterationen erneut durchlaufen werden. Zum einen kann das Ziel sein, die Detailtiefe bei den Untersuchungsgegenständen und der Ergebnisdokumentation pro Iteration zu erhöhen. Zum anderen können auch Themen, die im Review selbst identifiziert wurden, näher betrachtet werden. Kommt das Projektaudit in einer konkreten Krise zum Einsatz, wird der definierte Phasenablauf meist nur einmal komplett durchlaufen.

In unserem konkreten Fall änderten wir gemeinsam mit dem Kunden den Projektauftrag. Die Betrachtung des Projekts erfolgte nun ganzheitlich sowohl für die Softwarearchitektur als auch für die Entwicklungs- und Projektprozesse. Ziel war die Verifikation von Architektur- und Technologieentscheidungen sowie die Identifizierung von Optimierungspotential und das Erarbeiten einer konkreten Handlungsempfehlung.

Die bei der IST-Analyse durch Dokumentensichtung und Interviews gewonnenen Informationen wurden mit Blick auf die zu Beginn des Projektaudits definierten Schwerpunktthemen ausgewertet. Die Dokumentation von Befund und Zustand für die betrachteten Handlungsfelder erfolgte in tabellarischer Form. Entscheidend für die weitere Vorgehensweise ist dann der Zustand, er bewertet die Abweichung von einer „Best Practice“ [1].

Auf Basis der Befunde und ihrer Bewertung konnten wir präventive und korrektive Maßnahmen ableiten. Wichtig ist, das Ziel einer Maßnahme zu definieren um die spätere Erfolgskontrolle zu ermöglichen. Zum Abschluss brachte die Handlungsempfehlung unsere Maßnahmen in eine für die Situation passende Reihenfolge und bot dem Kunden eine Schritt-für-Schritt-Anleitung zur Problemlösung.

Bei Fragen, Anregungen oder Kritik sprechen Sie mich bitte einfach an. Ich freue mich über Rückmeldungen.

 

Literatur

[1] List, Werner / Voight, Roger (2010): Kritische Projekte retten. Leitfaden für die Diagnose, Sanierung und Prävention. München: Hanser Verlag.

 

Teamleistung – Mehr als die Summe der Einzelleistungen?

Teamleistung ist nicht zwangsläufig mehr als die Summe von Einzelleistungen. Eher trifft das Gegenteil zu, die Teamleistung ist zunächst geringer als die Summe reiner Einzelleistungen.

Um in der Tat ein „High-Performance“ Team zu formen, gibt es einige Punkte zu beachten. Unter anderem die Auswahl der Teammitglieder, eine geeignete Teamaufgabe, Motivation oder Konflikte.

Eine aus meiner Sicht praxisnahe Zusammenfassung des Themas findet sich hier:

Gruppen und Teams

Führung und High-Performance Scrum-Teams

Möchten Sie ein High-Performance Scrum-Team formen? Dann sollten Sie Inspiration und Ansporn geben, Konflikte lösen und Kooperation fördern, anspruchsvolle Ziele setzen, Vision und Ziel kommunizieren, Vertrauen aufbauen!

Joseph Folkman beschreibt in seinem Artikel „5 Ways To Build A High-Performance Team“ diese 5 Verhaltensweisen von Führungskräften, die in einem engen Zusammenhang mit der Leistungsbereitschaft der Teammitgliedern stehen. Die Analyse im Hinblick auf mögliche Faktoren für die Leistungsbereitschaft von Teammitgliedern basiert auf den Daten von 66.000 befragten Personen.

Im Ergebnis berechnet Folkman einen Index über die 5 Dimensionen und stellt diesen in Zehnerschritten dar. Ins Verhältnis gesetzt mit der Leistungsbereitschaft der Teammitglieder ergibt sich die nachfolgende Grafik. Es lässt sich erkennen, dass die Top-10% der Führungskräfte (beste Bewertung innerhalb der 5 Dimensionen) auch die höchste Zahl an leistungsbereiten Teammitgliedern aufweist.

Quelle: www.forbes.com/sites/joefolkman/2016/04/13/are-you-on-the-team-from-hell-5-ways-to-create-a-high-performance-team/

Passt dieses „Führen“ nun zu selbstorganisierten Teams, Scrum und Agilität? Ich meine, auf jeden Fall!

Java-/Web-/Agile-Development in Stuttgart

Seit vielen Jahren bin ich im Bereich Java-/Web- und Agile-Development vor allem im Großraum Stuttgart tätig. Dabei teile ich meine Erfahrungen und Kenntnisse gerne mit Experten oder Gleichgesinnten auf diesem Fachgebiet.

Aus vielen kleinen und großen Projekten mit unterschiedlichen Anforderungen, Vorgehensmodellen und Ergebnissen sind einige interessante und möglicherweise auch für andere hilfreiche Lessons Learned entstanden.

Gleichzeitig biete ich Herausforderungen, Projekte und Entwicklungsmöglichkeiten für Softwareentwickler/-architekten und Menschen die ein Thema vorantreiben oder ein Experten-Team formen möchten.

Ob es nun also um den Austausch unter Experten oder ein spannendes Projektangebot geht, ob Sie auf der Suche nach neuen Herausforderungen sind, ein Thema oder ein Team aufbauen möchten, ob Sie Softwareentwickler/-architekt, Projektleiter, Scrum Master, Product Owner, Projektleiter oder Teamleiter sind:

Ich freue mich über Ihre Nachricht.

Mit meinem Team bei der EXXETA AG realisieren wir maßgeschneiderte Softwarelösungen für große Unternehmen. Vom Entwurf der Systemarchitektur über die Implementierung bis zur Projektsteuerung (agil/klassisch) decken wir den gesamten Softwareentwicklungsprozess ab.

Technologien und Themen sind unter anderem:

  • Enterprise-Softwarelösungen auf Basis von Java
  • Entwurf und Bewertung von Software-Architekturen
  • Moderne Architekturkonzepte wie Self-contained Systems oder Microservices
  • Cloud– und Container Technologien
  • Web-Anwendungen und Web-Technologien
  • Moderne Frontends, HTML5, CSS3, Javascript, Angular
  • Moderne Backends, z. B. mit Spring Boot
  • Scrum, selbstorganisierte Teams, agile Entwicklung, DevOps

 

Agile Day – JAX 2017

Der Agile Day auf der JAX 2017 in Mainz bot in diesem Jahr ein breites Spektrum an Informationen, Beiträgen und Best Practices zum Thema Agilität in Projekten und Organisationen.

Zunächst ging es um die Erkenntnis, dass Agilität auch in großen Unternehmen funktioniert. Der Weg dorthin wird in der vorgestellten Firma allerdings mit „Permanent Beta“ überschrieben. Die Mitarbeiter benötigen Freiraum für Innovationen und die Möglichkeit, dass Dinge auch mal scheitern.

Weiter ging es mit einem entscheidenden Erfolgsfaktor für jedes Projekt, den Stakeholdern. Wie gelingt eine erfolgreiche Zusammenarbeit und wie werden die Stakeholder optimal ins Projekt eingebunden? Als eine Möglichkeit wird die Priorisierung von fachlichen Anforderungen durch ein dem Planning Poker ähnliches „Geschäftswertpoker“ vorgestellt.

Eines der wichtigsten Instrumente innerhalb von Scrum ist die Retrospektive. Ziel ist die ständige Verbesserung oder Optimierung des Scrum Projekts. Präsentiert wurden unterschiedliche Möglichkeiten eine Retrospektive interessant und abwechslungsreich zu gestalten. Eine gute Retrospektive greift dabei den aktuellen Kontext des Projekts auf und leitet daraus die entsprechenden Verbesserungen ab.

Welche Möglichkeiten zur Optimierung gibt es, wenn große Organisation agile Projekte kapern? Wenn Begriffe wie Scrum Master oder Product Owner lediglich Worthülsen für bestehende Organisationsstrukturen sind. Auf der JAX 2017 wird als entscheidendes Kriterium das Mindset aller Beteiligten genannt, dieses gilt es zu fördern. Im Idealfall können durch eine „agile Analyse“ entsprechende Handlungsfelder identifiziert werden.

Und vielleicht stellt sich für diejenigen die Scrum bereits einsetzen einmal die Frage, was tun wenn mein Scrum kaputt ist? Anhand vieler Beispiele aus der Praxis kamen Themen wie Product Owner vs. Team, Technische Schulden oder zu große User Stories zur Sprache. Dabei wurden jeweils konkrete Tipps zur möglichen Problemlösung gegeben.

Zum Abschluss beantworteten die Speaker des Tages gemeinsam die Fragen der Teilnehmer. Ein kleiner Konsens konnte dabei erzielt werden: Auch einmal Nein zu sagen! Vielleicht zum Management das ausführliche Reportings fordert. Oder gegenüber dem  Kunden der einen festen Scope zu einem festen Termin möchte. Die Herausforderung bei erfolgreichen agilen Projekten liegt darin, das Umfeld und das passende Mindset zu schaffen!

Buchtipp: Menschen führen – Leben wecken

Es gibt heute ein unüberschaubares Angebot an Führungsseminaren. Im Mittelpunkt stehen dabei oft die angewandten Methoden und nicht die Führungskraft an sich. Anselm Grün beschreibt in seinem Buch „Menschen führen – Leben wecken“ genau Letzteres – Führung durch Persönlichkeit.

Basis des Buchs von Anselm Grün ist das Cellerarskapitel aus der Regel des heiligen Benedikt, eine ursprünglich als Klosterregel verfasste Schrift aus dem 6. Jahrhundert. Der heilige Benedikt beschäftigt sich in diesem Kapitel mit der Frage, wie jemand beschaffen sein muss, wie jemand an sich arbeiten muss, um führen zu können. Führung durch Persönlichkeit ist für ihn das Wichtigste. Kann dies eine Anleitung für die Führung von Mitarbeitern in heutigen Unternehmen sein?

Zunächst erscheint dies schwierig, zumal uns die verwendete Sprache heute fremd vorkommt. Die erste Brücke in die heutige Unternehmenswelt schlägt Anselm Grün allerdings selbst. Er ist seit vielen Jahren Cellerar, der wirtschaftliche Leiter eines Klosters. Beim Thema Führung orientiert er sich an der Regel des heiligen Benedikt und versucht mit seinen Mitbrüdern und den ca. 270 Mitarbeitern verantwortlich umzugehen. In diesem Buch übersetzt Anselm Grün die Worte Benedikts in unsere heutige Sprache und leitet aus ihnen passende und aktuelle Bilder ab.

Welche Eigenschaften soll der Verantwortliche haben? Als Grundvoraussetzung wird die harte Schule der Selbsterkenntnis genannt. Menschen, die in sich selber ruhen und ihre Stärken und Schwächen kennen, sind für Führungsaufgaben gut geeignet. Nicht eingestandene Bedürfnisse oder unterdrückte Leidenschaften führen zu einer unklaren Führung. Dabei ist jeder zugleich Führer und Geführter. Die Rollen können abhängig von der Situation durchaus wechseln.

Anselm Grün weist darauf hin, dass Führen nicht bedeutet über andere zu herrschen oder andere klein zu machen. Wer andere klein macht, kann auch nur eine kleine Leistung erwarten. Vielmehr muss der Führende in den Menschen „Leben wecken“, nicht nur die Arbeitskraft, sondern das Potential an Ideen und Kreativität sehen. Es ist die Abkehr von der Frage, was die anderen einem bringen. Gleichzeitig darf sich der Verantwortliche nicht von der Meinung anderer abhängig machen. Ansonsten wird er von den Erwartungen der Menschen geführt, er gibt nicht die Richtung vor.

Interessant ist für mich, wie Anselm Grün bei fast allen Themen aus einer alten Sprache scheinbar die Erfahrung von Generationen herzuleiten vermag. Gut gefällt mir der Begriff des Dienens. Das lateinische Wort für Diener „servus“ meint dabei den Läufer. Der Führende kann zum Beispiel dafür sorgen, dass die Kommunikation gut läuft, dass es emotional zwischen den Mitarbeitern gut läuft. Das griechische Wort für Diener „diakonos“ wiederum meint dem Leben dienen. Der Verantwortliche zeichnet sich dadurch aus, dass er Leben hervorzulocken vermag. Er nimmt sich Zeit für die Mitarbeiter, um das vorhandene Potential zu erschließen.

Ich empfehle das Buch allen, die davon überzeugt sind oder sich überzeugen möchten, dass Führung von Menschen mehr ist als das Anwenden von Methoden.