Teil 2: Alles verändert sich

Infrastrukturen und Organisation

Stephan Kaps

© patpitchaya/Shutterstock.com

Im ersten Teil dieser Serie haben wir ein Projekt vorgestellt, das ein Antragsverfahren für Bürger beinhaltet, und die Gründe für die Architekturentscheidungen für Microservices und Workflow-Engine beschrieben. Diesmal stellen wir die im Rahmen des Projekts verwendete bzw. entstandene Infrastruktur vor und beleuchten organisatorische Aspekte.

Die Architektur des Gesamtsystems ist in Abbildung 1 zu sehen. Am linken und rechten Rand befinden sich einige querschnittliche Komponenten (Cross-cutting Concerns), die in einem verteilten System eine wichtige Rolle spielen.

Dabei geht es zum einen um Möglichkeiten der Überwachung der einzelnen Teilsysteme, zum anderen vor allem um Sicherheitsaspekte. Das hier vorgestellte Produkt hat eine Onlineantragsmöglichkeit, sodass die Sicherheit der Anwendungen im Internet sowie der darüber bereitgestellten Daten (Stichwort Verschlüsselung) eine sehr hohe Priorität besitzt. Des Weiteren ist ein einheitliches Vorgehen zur Authentifizierung und Autorisierung für das Gesamtsystem sicherzustellen. Das hier vorgestellte System wird im Übrigen vollständig On Premise betrieben.

Abb. 1: Die Architektur des Gesamtsystems

Abb. 1: Die Architektur des Gesamtsystems

Die Infrastruktur

Klassische Webanwendungen werden bei uns aktuell noch in Wildfly-Application-Servern betrieben. Das funktioniert sehr gut und das notwendige Know-how ist bei den Entwicklern vorhanden. Allerdings kommt es mit zunehmender Anzahl von Anwendungen zu einem Konflikt mit einem eher klassisch aufgestellten IT-Betrieb. Es ist diesem nicht zumutbar, für jede einzelne Anwendung eine eigene virtuelle Maschine mit einem eigenen Application-Server zu betreiben. Abgesehen von der Tatsache, dass das zu einer Ressourcenverschwendung führen würde, müsste eine dreistellige Zahl an Servern betreut werden. Es wird versucht, dem entgegenzuwirken, indem in Zukunft mehr Anwendungen mit Hilfe von Containern deployt werden. Neben den neuesten Sternen wie Quarkus oder Micronaut geht alternativ die Entwicklung des Wildfly durch die Einführung von Galleon auch mehr in die Cloud-native-Richtung und ermöglicht es dadurch, einen schlanken Application-Server einfacher in Containern betreiben zu können.

Containermanagement

Da mit der Zeit die Zahl der Container in den diversen Umgebungen stark gestiegen ist, wächst der Bedarf an einer einfachen Möglichkeit, diese managen zu können.

Das Werkzeug Portainer bietet eine aufgeräumte Oberfläche für die Verwaltung und das Management von Containerumgebungen. Es können diverse Hosts sowie Registries angebunden, laufende Container gestartet, gestoppt, überwacht und analysiert werden. Portainer lässt sich sehr einfach in Betrieb nehmen und bietet sowohl für Entwickler als auch für den Betrieb nützliche Funktionen. Container können auch manuell gepullt, gebaut, Netzwerke, Volumes und Images verwaltet werden. Es wird ebenso der Docker Swarm Mode unterstützt, also das Betreiben diverser Nodes als Cluster.

Observability

Unter Observability versteht man die Möglichkeiten der Überwachung und Beobachtung des Verhaltens von Software, das in die Bereiche Logging, Monitoring/Metriken und Tracing unterteilt wird und für verteilte Systeme enorm wichtig ist.

Logging

Die Herausforderung des Logmanagements in verteilten Architekturen ist seit Langem gelöst. Lösungen wie der Elastic Stack ermöglichen es, sämtliche Lognachrichten aus diversen Services, ob nun betrieben in einem Container oder in einem Application-Server, an eine zentrale Stelle zu übermitteln, wo sie aufbereitet, zerlegt, indiziert und ausgewertet werden können.

Beim Elastic Stack sammeln sogenannte File-Beats die Logdateien ein und senden den Inhalt zeilenweise, wenn gewünscht vorselektiert (z. B. nach bestimmten Loglevels), an eine oder mehrere Logstash-Instanzen. Diese wiederum verarbeiten den Input, wenden Filter an (z. B. in Form von Grok-Patterns), um die Inhalte der Meldung zu identifizieren und um im Anschluss die Ergebnisse in Elasticsearch zu persistieren. In der in diesem Projekt verwendeten Infrastruktur wurde darüber hinaus eine Redis-Datenbank verwendet, um diese Pipelines mit Puffern zu versehen. Dadurch kann verhindert werden, dass das zentrale Logmanagementsystem zusammenbricht, wenn ein Server massiv viele Meldungen in sehr kurzer Zeit erzeugt. Als Visualisierung und Auswertungswerkzeug hält der Elastic Stack Kibana bereit. Dort können Abfragen erstellt und mit visuellen Komponenten angereichert auf Dashboards dargestellt werden. Bei aufgetretenen Error-Meldungen in Produktion lassen wir uns zudem auf einem separaten Kanal in unserem Chat-Tool benachrichtigen.

Monitoring

Beim Monitoring geht es meist um die Überwachung von Systemressourcen wie CPU oder Speicher. Häufig existieren jedoch auch fachliche Anforderungen, Metriken zu sammeln, um das Verfahren steuern zu können. In diesem Projekt werden Metriken gesammelt – zu der Anzahl an Bescheiden je Art, Anzahl der Nachforderungsgründe je Art oder der Anzahl der Aussteuerungsgründe (Sonderfälle) je Art. Die letztgenannte Metrik unterstützt bei der Entscheidung, für welche Fallkonstellationen sich eine programmtechnische Umsetzung auf Grund der Menge der Fälle lohnt und für welche nicht, da es sich um Einzelfälle handelt.

Die Werkzeuge, die in diesem Projekt eingesetzt wurden, sind Prometheus und Grafana. Die eigenen Anwendungen und Services bieten spezielle Endpunkte an (/metrics), die von Prometheus abgefragt und persistiert werden, um im Anschluss in eigens konfigurierten Dashboards in Grafana visuell ansprechend dargestellt zu werden.

Zusätzlich bieten alle Anwendungen Endpunkte an, um den Gesundheitszustand der jeweiligen Komponenten überwachen zu können, entweder über die Integration von Dropwizard Metrics oder in Spring Boot über Actuator. Bei den über Consul registrierten Services (Abb. 2) ist der Health-Status direkt in Consul ersichtlich. Es könnte alternativ Spring Boot Admin eingesetzt werden, sollte keine Service Registry mit ähnlicher Funktionalität im Einsatz sein.

Abb. 2: Übersicht der Services in Consul

Abb. 2: Übersicht der Services in Consul

Tracing

Beim Tracing geht es darum, einen Request von seinem Ursprung bis zum Ende verfolgen zu können. Das ist absolut sinnvoll und notwendig, wenn ein Request mehrere Services durchläuft, bis die eigentliche Response erfolgt und dabei z. B. Latenzprobleme zu analysieren sind. Technisch wird das ermöglicht, indem eine Anwendung Aufrufe mit einem mit IDs angereicherten Header versieht, die im Anschluss von einer zentralen Instanz zusammengeführt werden können. Werkzeuge für diesen Zweck gibt es inzwischen mehrere, wie beispielsweise Zipkin oder Jaeger. Diese bieten meist eine praktische Benutzeroberfläche, über die es möglich ist, die persistierten Daten abzufragen und die Aufrufketten grafisch ansprechend darzustellen. Im Folgenden betrachten wir einige Sicherheitsaspekte.

Authentifizierung und SSO

Interne Mitarbeiter melden sich einmalig an einem Mitarbeiterportal an und sind damit für sämtliche Anwendungen, für die sie Rechte und Rollen besitzen, authentifiziert. Dafür wird das Open-Source-Tool Keycloak von Red Hat eingesetzt. Ein Verzeichnisdienst ist für interne Verfahren als Identity-Provider angebunden. Für Systeme, die im Internet zugänglich sind und eine Authentifizierung erfordern, bietet Keycloak eine Selbstregistrierungsfunktion sowie Social-Log-in-Möglichkeiten wie Google, Facebook und weitere. Es werden die Standardprotokolle OpenID Connect, OAuth 2.0 und SAML 2.0 unterstützt. Für die Absicherung von Microservices bieten sich Bearer Tokens an.

Ein Keycloak-Adapter wird unter anderem als Spring Boot Starter oder WildFly-Modul angeboten.

Secret-Management

Beim Secret-Management geht es darum, einen sicheren Zugriff auf sowie eine sichere Ablage für Geheimnisse jeglicher Art bereitzustellen, also Zertifikate, Passwörter oder API-Keys. Dafür eignet sich das Werkzeug Vault von Hashicorp. Neben der Möglichkeit, den Zugriff auf abgelegte Geheimnisse über Policies zu regeln, bietet es zusätzliche Funktionen wie dynamische Secrets, Encryption as a Service, Auditierung der Zugriffe sowie Überwachung der Gültigkeit und Erneuerung oder Sperrung von Secrets.

Vault stellt ein API bereit, sodass eine Anwendung, in diesem Fall die Fachanwendung, sich beim Zugriff identifiziert (z. B. per sogenannter AppRole) und auf Grund von Policies Zugriff auf den Private Key zur Entschlüsselung der online eingereichten und verschlüsselten Antragsdaten erlangt. Konkret handelt es sich um ein Transitverfahren, bei dem die zu ver- oder entschlüsselnden Daten per API-Aufruf an Vault übermittelt werden. Vault führt daraufhin die Ver- oder Entschlüsselung anhand der hinterlegten Keys durch und gibt den ver- oder entschlüsselten Inhalt wieder zurück. Die Schlüssel selbst verlassen dadurch nie den Schlüsselkasten. Spring bietet mit Spring Cloud Vault eine Abstraktion und weitere Vereinfachung der Anbindung und Nutzung von Vault innerhalb einer Spring-(Boot-)Anwendung.

Webserver

Webserver sind Einfallstore für Angriffe aus dem Internet in die Infrastruktur einer Organisation. Die sichere Einrichtung eines Webservers ist deshalb essenziell, um Angriffe erfolgreich zu verhindern. Folgende Maßnahmen müssen mindestens ergriffen werden:

  • Härtung des zugrunde liegenden Betriebssystems
  • Umsetzung der Maßnahmen aus den BSI-Katalogen M4.360 und M4.94 bzw. APP3.2
  • Nutzung sicherer Kryptoalgorithmen und Protokolle sowie sichere Schlüsselerzeugung und Hinterlegung
  • Verhinderung von Standardangriffen, wie z. B. Cross-Site Scripting (XSS) durch das Setzen von Security-Headern
  • bewusstes Konfigurieren und Erzwingen einer SSLCipherSuite-Reihenfolge
  • Erzwingen von HTTPS durch Umleiten der Aufrufe auf Port 80
  • Versionsausgabe des Webservers und PHP-Version unterbinden

Eine weitere deutliche Steigerung der Sicherheit erhält man durch den Einsatz einer Application-Firewall wie ModSecurity. Das dafür existierende und von OWASP bereitgestellte Set an Regeln ist sehr umfangreich und bedarf einer intensiven Auseinandersetzung. Konfiguriert man jedoch zunächst alles mit dem sogenannten Paranoia Level 1, erhält man die Möglichkeit, seine Regeln im Livebetrieb zu testen, und kann Erkenntnisse aus den geloggten Meldungen gewinnen.

Optional wäre noch das Pflegen einer Content Security Policy. Diese stellt quasi eine Whitelist mit Domains dar, von denen JavaScript, Bilder, Schriftarten und andere Inhalte auf eurer Seite eingebunden werden. Diese Ausnahmeliste kann sehr lang werden und bedarf regelmäßiger Überprüfung, falls neue Einträge benötigt werden. Relativ neu sind die Header Referrer Policy und Feature Policy. Überprüfen könnt ihr eure Webserverkonfiguration z. B. mittels Security Headers und dem SLL Server Test.

Container Image Vulnerabilities

Für Java-Entwicklungen werden die Abhängigkeiten, also vor allem Third-Party Libraries, inzwischen regelmäßig durch Werkzeuge wie den OWASP Dependency Check auf bekannte Verwundbarkeiten hin überprüft. Für Container-Images gibt es vergleichbare Werkzeuge, um jeden einzelnen Layer und die darin verwendeten Werkzeuge und Bibliotheken zu prüfen. Manchmal sind diese Helferlein bereits in eine Container-Registry integriert, so wie bei goharbor.io, der cloudnativen Container-Registry mit dem integrierten Vulnerability Scanner Clair.

Dadurch kann bei jedem Push eines Image in die Registry gleichzeitig ein Security-Scan über alle Layer erfolgen, der überprüft, ob bekannte Verwundbarkeiten existieren. Quelle der Informationen ist die National Vulnerability Database (NVD) des NIST. Weitergehend kann bei Überschreiten einer bestimmten Schwellgrenze von Verwundbarkeiten hohen Risikos automatisch der Build-Prozess gestoppt und eine Auslieferung in Produktion unterbunden werden.

Zusätzlich können Images über das integrierte Tool Notary signiert und somit kann die Herkunft als vertrauenswürdig eingestuft werden. Eine interne Policy könnte darauf aufbauend festlegen, dass nur signierte Images verwendet werden dürfen.

Die Installation von Harbor erfolgt sehr komfortabel über ein Skript, das einen Stack an Containern lädt und startet. Es existieren eine LDAP-Anbindung und OIDC-Support, ein aufgeräumtes UI sowie ein Auditing von Aktionen. Durch diese Eigenschaften ist Harbor auch sehr gut für Unternehmen geeignet, die keine Public oder cloudbasierte Registry nutzen wollen oder dürfen.

Service Proxy

Alle Microservices sollten mit TLS/HTTPS versehen sein. Um die Zertifikate jedoch nicht in jeden Keystore sämtlicher Container integrieren zu müssen, bieten sich sogenannte Service Proxies wie Traefik oder Envoy an. Diese bekommen mit, wenn ein neuer Container gestartet wurde, und können dann die Routen, ähnlich einem klassischen Reverse Proxy, per SSL absichern, allerdings automatisch.

Seit Version 1.2 stehen mit Consul Connect Funktionalitäten bereit, die in Zukunft in Richtung Service Mesh ausgebaut werden. Consul verwendet dabei z. B. auch Envoy als Sidecar Proxy und kann sich die Zertifikate für die TLS-Absicherung der Services automatisch von Vault erzeugen lassen, wenn dort die entsprechenden Root- und CA-Zertifikate hinterlegt sind. Eine detaillierte Betrachtung würde den Rahmen dieses Artikels sprengen.

Doch wie lässt sich diese Vielfalt an Technologien, Werkzeugen und Methoden organisieren? Auf der einen Seite sollte nicht jeder Entwickler seine Lieblingsspielzeuge mitbringen, auf der anderen Seite wollen wir ständigen Fortschritt und Innovation und daher nicht alles reglementieren und standardisieren.

Mikro- und Makroarchitektur

Die Unterscheidung in Mikro- und Makroarchitektur ist dafür eine bewährte Vorgehensweise. Bei Makroarchitektur geht es um die Architektur im Großen, das heißt, um die Einheitlichkeit und das Festlegen von Standards. Die Vorteile sind aus der klassischen Architekturarbeit bekannt:

  • Entwickler wechseln leicht zwischen Teams und Projekten
  • Konzentration auf Applikationsspezifika (z. B. Fachlichkeit) ist leichter möglich
  • Wiederverwendung von technischen Lösungen
  • Vermeidung von Fehlern in kritischen Bereichen durch erprobte Konzepte
  • Geringere Kosten durch weniger Produkte (Lizenzen, Ausbildung von Spezialisten)

Bei Mikroarchitektur handelt es sich um eine Architektur im Kleinen, das heißt, das Team kann eine geeignete Lösung für ein konkretes Problem selbst festlegen. Diese muss sich lediglich im Rahmen der Makroarchitektur bewegen. Die Vorteile ergeben sich aus den möglichen Nachteilen von Vereinheitlichung und Standards:

  • Neue Trends lassen sich schneller aufgreifen
  • Fehlentscheidungen haben geringere Relevanz
  • Geringere Abhängigkeit von einzelnen Lieferanten

Makroarchitektur ist vergleichbar mit dem Aufstellen von Leitplanken. In Bezug auf das in diesem Artikel betrachtete System wurden folgende Regeln abgeleitet:

  • Standardmäßige Entwicklung von Java-Webanwendungen
  • Authentifizierung/Autorisierung per Keycloak
  • Schnittstellen als REST APIs
  • wo möglich, Microservices einsetzen
  • Festlegungen im Bereich Oberflächentechnologie und Design
  • Standards und Vorgaben zur Ausnahme- und Fehlerbehandlung
  • Einheitliche Persistenzschicht (Hibernate)
  • Festlegung der Entwicklungswerkzeuge (Versionsverwaltung, Build-Management, Test-Frameworks usw.)
  • Einheitliches Vorgehen (Scrum, BDD usw.)
  • Standards für Logging, Tracing, Resilienz
  • Festlegung der Zielumgebung: Virtualisierung, Container
  • Einheitliches Deployment
  • Konzepte und Standards zu Verfügbarkeit, Recovery, Protokollierung usw.

Entscheidend ist die Frage der Dokumentation und Kommunikation dieser Entscheidungen. Konzepte und Best Practices sind in einem Wiki ganz gut aufgehoben. Um darzustellen, dass bestimmte Technologien oder Vorgehensweisen einen höheren Reifegrad besitzen als andere, und um Ausdruck zu verleihen, was Standard ist und was eher experimentell, pflegen wir quartalsweise einen eigenen Technology Radar. Der von ThoughtWorks halbjährlich herausgegebene Technology Radar ist weitverbreitet und bekannt. Die Herausgeber haben das Werkzeug zur Erstellung eines eigenen Tech-Radars Open Source bereitgestellt, sodass die eigenen Technologien, aber auch eigene Kategorien nett aufbereitet dargestellt werden können. Die Pflege erfolgt per Google Sheet oder CSV-Datei mit einem vorgegebenen Format.

Der Technology Radar unterteilt sich in vier Kategorien, in denen jeweils vier Bereiche unterschieden werden. Die Definition kann für die eigenen Bedürfnisse natürlich angepasst werden. So haben wir uns für die Kategorien Tools, Plattformen, Sprachen und Frameworks sowie für die Kategorie Techniken entschieden und die in Tabelle 1 aufgeführte Definition für Bereiche getroffen:

Bereiche Definition
Adopt Wird standardmäßig in quasi jedem Projekt eingesetzt.
Trial Wurde oder wird bereits in einem Projekt ausprobiert und sein Einsatz erscheint sinnvoll.
Assess Eine Technologie, die es wert ist, einmal intensiver getestet zu werden, z. B. anhand eines Proof of Concept.
Hold Technologien, die (aktuell noch) nicht eingesetzt werden sollten, da sie z. B. noch zu neu sind, oder nicht mehr eingesetzt werden, da es einen vielversprechenden Ersatz gibt.

Tabelle 1: Bereichsdefinition des Technology Radars

Abbildung 3 zeigt einen Ausschnitt aus Q3 2019. Die Kreise zeigen an, dass der entsprechende Eintrag bereits im letzten Technology Radar in diesem Bereich vorhanden war, das Dreieck markiert die Einträge, die entweder neu hinzugekommen sind oder in einen anderen Bereich verschoben wurden.

Abb. 3: Technology-Radar-Ausschnitt aus Q3 2019

Abb. 3: Technology-Radar-Ausschnitt aus Q3 2019

Evolving Architecture

Per Definition geht es dabei um inkrementelle Änderungen an einer Architektur im Lauf der Zeit. Dies ist eng verbunden mit der inkrementellen Entwicklung einer Anwendung und dem Grundgedanken, gewisse Aspekte zum jetzigen Zeitpunkt in einer gewissen Detailtiefe zu betrachten und Erfahrungen zu sammeln, um im nächsten Schritt einen weiteren Aspekt zu konkretisieren.

In der in diesem Artikel vorgestellten Architektur ist im Lauf der Entwicklung die Anzahl an Microservices kontinuierlich gestiegen, sodass der Bedarf an einer Service-Discovery-Lösung gewachsen ist. Durch die Erfahrungen, die gesammelt wurden, wird Consul inzwischen auch für die Konfiguration von Services verwendet. Aktuell finden Experimente statt, um mit Hilfe der neuen Funktionalität Connect Consul als eine Art Service Mesh zu nutzen, der z. B. für die TLS-Absicherung der Services zuständig ist und sich die dafür notwendigen Zertifikate automatisch aus Vault erzeugen lassen kann.

So kann es vorkommen, dass sich Technologieentscheidungen ändern, aus Microservices echte Services werden, die von mehreren Applikationen verwendet werden, oder sich Grenzen im Sinne von Bounded Contexts verschieben.

Auch der Kommunikationsstil kann sich ändern. Was zu Beginn eventuell aus Gründen der leichteren Verständlichkeit als synchrone Aufrufe umgesetzt wurde, kann mit mehr Erfahrung und weiterem technischen Know-how auf asynchrone Aufrufe umgestellt werden.

Die Organisation

Wie bereits im ersten Teil erwähnt, ist das Team mit zehn Entwicklern und zwei Product Owners relativ überschaubar. Die Aufgabe, aktuell über 60 Anwendungen plus ein Dutzend Services zu entwickeln und zu betreuen, ist hingegen relativ groß. Erschwerend kommt hinzu, dass der Rest der Organisation noch nicht nach agilen Prinzipien und Werten arbeitet, was bedeutet, dass der Fachbereich während des Sprints nicht kontinuierlich für Fragen bereitsteht, nicht am Daily teilnimmt und keine Stories testet, sobald diese erledigt sind. Des Weiteren gelingt es häufig nicht, kontinuierlich am Backlog zu arbeiten, um einen Folgesprint durchführen zu können. Dementsprechend gilt es, eine geeignete Form der Organisation zu finden, um mit diesen Rahmenbedingungen klarzukommen.

Abb. 4: Abwechselnde Sprints

Abb. 4: Abwechselnde Sprints

Das Ergebnis ist zum einen, dass sich mindestens vier Projekte gleichzeitig in Entwicklung befinden, deren Sprints sich abwechseln (Abb. 4). Das gibt den Fachbereichen nach einem Sprint Zeit zum Testen oder zum Spezifizieren neuer Anforderungen für die nächste Iteration. Zum anderen wird zwischen zwei Sprintblöcken immer eine sogenannte MAIN Week eingeschoben. Das steht für Maintenance and Innovation. Die Aufteilung ist dabei wie in Abbildung 5 dargestellt.

Abb. 5: Inhalt einer MAIN Week

Abb. 5: Inhalt einer MAIN Week

Montag und Freitag steht für Wartungsarbeiten zur Verfügung. Bei so vielen produktiven Systemen gibt es hier und da immer Kleinigkeiten zu verbessern. Hierbei handelt es sich nicht um Hotfixes. Diese werden natürlich umgehend nach Eintreten umgesetzt.

Am Dienstagvormittag finden die Reviews zu den zuvor durchgeführten Sprints statt, d. h., dass auch die Fachbereiche eingeladen werden, um die Ergebnisse im Beisein des gesamten Teams vorzuführen.

Im Anschluss wird eine gemeinsame Retrospektive durchgeführt.

Am Nachmittag findet das Refinement eines Projekts für den nächsten Sprint statt. Daran nehmen alle teil, um das fachliche Wissen unter allen Entwicklern zu streuen und frische Ideen für die Umsetzung zu erhalten. Die Zusammensetzung der Teams kann sich von Sprint zu Sprint auch innerhalb eines Projekts ändern, je nachdem, welche Skills gerade inhaltlich oder technisch erforderlich sind.

Der Mittwoch ist der Innovation Day. An diesem Tag können sich kleine Teams von zwei bis drei Personen zusammentun, um an neuen Ideen, neuen Technologien oder Werkzeugen zu experimentieren. Dafür sind maximal drei solcher Termine möglich. Im Anschluss sollen anhand eines Tech-Talks die bis dahin gewonnenen Erkenntnisse vorgestellt werden. Das gesamte Team entscheidet dann darüber, ob daran weitergearbeitet werden soll bzw. ob man die Ergebnisse in der Fläche ausrollen will. Für einen solchen Tech-Talk ist am Donnerstagnachmittag Zeit, nachdem am Vormittag das Refinement des zweiten Projekts der nächsten Sprints durchgeführt wurde. Für die zuletzt beste Innovation wird ein kleiner Wanderpokal verliehen. In den letzten Monaten sind bereits mehrere Innovationen zu Standards geworden, wie z. B. ArchUnit für Unit-Tests der Architektur. Es wurden Vorhaben wieder verworfen, was nach drei Tagen Investition ein gutes Ergebnis ist. Für den Innovation Day steht ein stets gut gefüllter Backlog an Themen bereit. Jeder ist eingeladen, spontan eigene neue Ideen einzubringen. Der Innovation Backlog hat sehr viele Überschneidungen mit dem Assess-Bereich des Technology Radars.

Diese geplante und ritualisierte Innovation fördert den Mut, Neues zu erforschen und bringt jeden Einzelnen dem Ziel technischer Exzellenz stetig näher. Darüber hinaus macht es enorm Spaß, fördert den Team-Spirit, und die Gamification mit Hilfe eines Pokals weckt den Ehrgeiz, als Siegerteam die Trophäe für ein paar Wochen auf dem Schreibtisch stehen zu haben.

Fazit

Nachdem im ersten Teil der Artikelserie die Architektur und die Gründe für Microservices und Workflowautomation beschrieben wurden, folgte in diesem Artikel die Vorstellung der Infrastruktur, die für dieses System genutzt wird oder entstanden ist. Des Weiteren wurde erläutert, wie das Entwicklungsteam sich organisiert hat, um viele Produkte innerhalb einer klassischen, nicht agilen Organisation agil zu entwickeln.

Es ist entscheidend, die Fachlichkeit zu kennen und zu verstehen, um die richtigen fachlichen Schnitte zu machen und die Architektur darauf auszurichten.

Aber es ist ebenso notwendig, eine sich ändernde Architektur zu akzeptieren. Wichtig dabei ist, bewusst Entscheidungen zu treffen und diese zu dokumentieren. Die Vor- und Nachteile bestimmter Technologien und Architekturen sind im eigenen Kontext abzuwägen und zu überprüfen.

Um bewusste Entscheidungen treffen zu können, ist es notwendig, viele Architekturprinzipien und -stile sowie die technischen Möglichkeiten zu kennen. Durch Experimente und das damit verbundene kontinuierliche Lernen und Adaptieren steigt die Chance, ein erfolgreiches und gutes Produkt zu entwickeln.

Doch das vermutlich Wichtigste ist, einfach neugierig zu bleiben.

Geschrieben von
Stephan Kaps
Stephan Kaps
Stephan Kaps leitet die Softwareentwicklung im Bundesversicherungsamt und ist Gründer der Java User Group Bonn. Als Softwarearchitekt und Entwickler hat er seit 2002 mit Java zu tun.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: