Architektur- und Developmentberatung im Rahmen eines groß angelegten Transformationsprojekts zur Migration und Ablösung des Rentenversicherung-Altverfahrens ?rvDialog? in eine Microservice Container Plattform (rvEVO - Leistungserbringer Managment)

• Auf Basis eines Komponenten-Schnitts inkl. Context-Map erfolgte schrittweise die teamspezifische Umsetzung von BoundedContext Frontend- und Backend-Komponenten, sog. IT-Produkten. 
• Nach Contract-First Vorgehensweise wurden in Open- und Async-API notwendige Schnittstellen spezifiziert. Zwei Microfrontends und -services wurden entwickelt, um das zugrundeliegende Aggregat ?Leistungserbringer? zu managen (CRUD) und zu suchen (ElasticSearch). Über JMS wurde die Daten dabei unidirektional repliziert (Fire & Forget) gemäß Pattern Event-Carried-State-Transfer und Tolerant-Reader.
• Migrationsstrategien wurden entwickelt für ein sog. ?Kooperationsmodell?, bei dem das Altverfahren mittelfristig in der Daten-Ownership Verantwortung bleibt.
• Teamübergreifend wurden Architektur-Leitplanken, -Grundpfeiler und -Entscheidungen erarbeitet.
• Testing als weiterer Schwerpunkt, insbesondere Behavior-Driven-Development, wurde auf allen Test-Stufen eingeführt. Hervorzuheben war ?testable Design?, ?Test-Design?, Test-Pyramide, Komponenten- und Bounded-Context-Testing mit Playwright. Teamübergreifend wurde eine Shift-Left CI/CD Pipeline-Strategie etabliert.
• Die Teamgröße belief sich auf 12. Meine Kernaufgaben waren Lead-Development, Konzeption und überwiegend Coaching und Enabling in den Bereichen agile Softwarentwicklung, Domain-Driven-Design, Openshift Container Plattform, sowie RESTful- und Message-Design, Microservice Architektur- und Design-Patterns, Clean-Code, CI/CD Build-Pipeline mit ArgoCD und Openshift sowie Testautomation (Software Craftsmanship).

• Als übergeordnetes Architektur Team wird eine Cloud-Native Kubernetes Container Plattform aufgebaut, inkl. integrierter Tekton Build-Pipeline, und für erste BA Verfahren bereitgestellt.
• Hierfür erfolgten ein kontinuierlicher Wissenstransfer und Microservice-Architekturberatung. Das Vorgehensmodell Domain-Driven-Design zur vertikalen Dekomposition von Fachverfahren wurde geschult. Zudem wurden Projekte begleitet in Event-Storming Workshops mit strategischem und taktischem Design.
• Ein besonderer Wert wurde auf die Überwachung von Microservices und deren Choreografie über Metriken gelegt. Hierzu wurde ein Observability Stack, Architektur-/Designvorgaben, sowie Blueprints entwickelt und Fachverfahren ?enabled?.
• Testing als weiterer Schwerpunkt, insbesondere Behavior-Driven-Development, wurde auf allen Ebenen eingeführt. Hervorzuheben war ?testable Design?, ?Test-Design?, Test-Pyramide, Bounded-Context Testing und Load-/Performance Testing.
• Die Teamgröße belief sich auf 8, je nach Fachverfahren bis zu 50. Meine Kernaufgaben waren Konzeption und Enabling in den Bereichen Domain-Driven-Design und Observability Pentagon, Aufbau der Container Plattform, sowie Coachings im Bereich Microservice Architektur- und Design-Patterns und Testautomation (Software Craftsmanship, Cloud-Native).

• Eine Analyse des Monolithen nach qualitativen Gesichtspunkten war Ausgangspunkt der Zerlegung. Dabei wurden u.a. technische Schnitte identifiziert, an denen eine Migrationsstrategie festgemacht werden konnte.
• Mittels Event-Storming und strategischem Design konnte der Bounded-Context ermittelt werden, sowie die zukünftige Abgrenzung nach Core-, Generic- und Supporting-Domain (der Core-Domain Source-Code Anteil beim vorliegenden Monolith lag bei unter 50%!). Aus dem taktischen Design konnte letztlich der fachliche Microservices Schnitt abgeleitet werden, sowie anschließend die notwendige Architektur konzipiert werden. Als Betriebsumgebung wurde anfänglich Docker-Swarm, für eine spätere Ausbaustufe Kubernetes, als ausreichend hinsichtlich Last und Ausfallsicherheit definiert.
• Basierend auf der Hexagonal-Architektur, wurden zwei prototypische, fachlich etwas abstrahierte Referenz-Microservices implementiert und unterschiedliche Persistenz Mechanismen (SQL/H2 vs. NoSQL/MongoDB), sowie Messaging Provider (ActiveMQ vs. Kafka) und Pattern (Queue vs. Topic, Request/Reply vs. Pub/Sub) verprobt, inkl. Unit, IT und E2E TestStrategie. Die Referenzen wurden anschließend als Copy-Paste Vorlage für 3 ?echte? Microservices verprobt und daraus ein MVP umgesetzt. Zukünftig dienen die Referenzen dazu, eine Developer Community Strategie zu ermöglichen. WikiDokumentation, Git Repo-Struktur, sowie eine Gitlab BuildPipeline wurden bereitgestellt.
• Die Teamgröße belief sich auf 4. Meine Kernaufgaben im Projekt waren Spring-Boot Microservices Architect, IT-Enabling und Coaching (Software Craftsmanship, DDD, CI/CD).

• Im Rahmen des IT-Modernisierungs- und DigitalisierungsChanges wurde BOSCINO auf Basis eines rudimentären SpringBoot Microservice RampUp POCs designed und implementiert. Initial wurden dabei ?hands-on? der neue Technologie-Stack, Test-Methodiken, sowie Clean-Code und Microservice Paradigmen vermittelt. Zudem wurden die agilen Werte und Prinzipien verfestigt, sowie DDD als unternehmensweite Modellierungs-Methodik vermittelt und erfolgreich eingeführt.
• Im Rahmen eines initialen DDD Event-Stormings und dem strategischen Design wurde die Fachdomäne identifiziert, sowie der Bounded-Context, die UL und die 3 zu entwickelnden Microservices erarbeitet. Die Ergebnisse des iterativen taktischen Designs wurden in User Stories überführt und umgesetzt. Erfolgreich konnten die Modelle nahezu 1:1 umgesetzt werden, so dass der Aufwand zur Erstellung der Systemdokumentation sehr gering war. Effektive Developer-Guidelines (u.a. SOLID), eine hohe Unit/IT/E2E Test-Abdeckung, sowie kontinuierliche Mob-Sessions und Team-Reviews gewährleisteten bis zuletzt eine messbar hohe Softwarequalität.
• Kontinuierlich wurden projektübergreifende Build-/ Test-/ Deployment-, sowie Logging- und Monitoring-Strategien im Microservices Umfeld verfeinert und unternehmensweit etabliert.
• In der letzten Projektphase wurde zugunsten einer einheitlichen Unternehmensstrategie die Messaging-Plattform (zur Gewährleistung von loser Microservices Kopplung) von ActiveMQ bzw. IBM MQ auf Apache Kafka umgestellt.
• Die Teamgröße belief sich auf 9. Meine Kernaufgaben im Projekt waren Spring-Boot Microservices Architect, IT-Enabling und Coaching (Software Craftsmanship, Scrum, DDD, CI/CD).

• Neben der Produkt-Neuausrichtung stand ein unternehmensweiter IT-Modernisierungs-Change im Vordergrund.
• Auf Basis eines fachlich vereinfachten Domänenmodells wurde eine leichtgewichtige JEE Full-Stack Microservice Backend-Architektur konzipiert und entwickelt. Besonders Wert gelegt wurde dabei auf technische Verprobungen hinsichtlich Plattformunabhängigkeit (Cloud vs. onPremise, AppServer, DB), Skalierung (reactive), lose Kopplung (Convention-over-Configuration), Versionierung und Asynchronität (CQRS, Event-Sourcing, Eventual-Consistency).
• Im Vordergrund stand in diesem Zusammenhang auch die ?hands-on? Vermittlung von Clean-Code Paradigmen und Patterns (u.a. SOLID), aktuelle JEE7/Java8 Konzepte, TestingModelle und -Design, sowie CI/CD-Build Techniken und damit die Verankerung der Werte und Prinzipien zu den Manifesten zu Craftsmanship und Reactive.
• Begleitend wurde ein agiles Prozessmodell entworfen und eingeführt, um sich inkrementell nach DDD und MVP der Ziel-Vision zu nähern. Dabei wurden u.a. Maßnahmen (Grooming, Retro, Scrum-of-Scrum, Impediment-Board, Quality-Gate, Team-Review, "open" Dailies) zur Neugestaltung von Zusammenarbeitsmodelle, Selbstorganisation, Transparenz und Qualität der Arbeitsergebnisse etabliert. JIRA User Story Templates (u.a. Acc-Crit., Benefit, Dependency, Epic), JIRA Workflows, sowie analoge Sprint-Boards wurden entworfen.

• In der letzten Projektphase wurde ein (private) Cloud- und Staging-Betriebskonzept entwickelt und die vorhandene BuildPipeline um die notwendigen Build-Steps (u.a. Docker) hinsichtlich CI/CD erweitert.
• Die Teamgröße belief sich auf 12. Kernaufgabe im Projekt war JEE 7 Microservices Lead-Architect, sowie IT-Enabling und Coaching (Technologie-Stack & Software Craftsmanship).

• Aufgrund einer größeren Teamveränderung wurden neue Zusammenarbeitsmodelle mit agilen Prozesselementen zwischen Kunde, Facharchitekten, IT und QA entwickelt und sukzessive erfolgreich eingeführt. Ausschlaggebend war hier die zentrale Rolle des Facharchitektur-Teams, als Verbindungsglied zwischen Kunde und IT. Aufgaben in der Rolle des Facharchitekten waren u.a. die Modellierung von Prozessen (BPMN) für statistische Erhebungen, Entwicklung von statistischen Berechnungsformeln, sowie Schnittstellenvereinbarungen.
• Die Teamgröße belief sich auf 15. Kernaufgabe im Projekt war Solution Architect und agiler Coach.

• Das CMS-gestützte myaudi Erlebnis-Portal wurde um eine eigenständige JEE Applikation zur Planung und Buchung von Erlebnissen/Veranstaltungen im Zuge einer Werksabholung erweitert. Über ein Liferay Portlet wurde die Integration umgesetzt. Eine leichtgewichtige JEE BCE Microservices Architektur diente einem AngularJS basierten Frontend für Business-, Persistenz- und Schnittstellen-Logik. Die Feingranularität der Services ermöglichte eine geringe ViewModel-Logik. Backend-Highlight war eine clusterfähige Reservierungs-Komponente für kontingentierte Erlebnisse.
• Die Größe des Junioren Teams belief sich auf 7. Kernaufgabe im Projekt war IT-Coaching (Architektur- und Coding-Dojos), Scrum Master, sowie Unterstützung bei der Umsetzung.

• Nach initialer Analyse der Software (Struktur, Design, Build, Test) wurden Maßnahmen zur schrittweisen technischen Migration identifiziert. Im Rahmen von Coding-Dojos wurden benötigte Techniken und Methoden (CDI, JPA, Mockito, Maven, Java7, Bea12) vermittelt und anschließend im Team durchgeführt. Team-Reviews, Unit- und Integrationstests, sowie der Aufbau einer Jenkins Build-Pipeline dienten zur Absicherung der Qualität. 
• Gleichzeitig erfolgte der Neuaufbau der internen Wiki Dokumentation. Ein agiles Vorgehensmodell wurde etabliert, um die Zusammenarbeit im Team und gegenüber dem Kunden zu verbessern. Der Einsatz endete mit dem erfolgreichen Rollout der Software auf der neuen Infrastruktur.
• Die Teamgröße belief sich auf 7. Kernaufgabe im Projekt war IT-Coaching, Scrum Master und Unterstützung bei der Umsetzung der Maßnahmen.

• Die Plattform, bestehend aus Komponenten, Lösungsbausteinen und Werkzeugen, als technische Basis dient der Standardisierung und Qualitätssteigerung von IT Fachprojekten bei der Bundesbank. Mangelnde Akzeptanz und Unzufriedenheit der Fachprojekte, verbunden mit der Notwendigkeit kurzfristig eine Vielzahl von Fachprojekten aufzunehmen, erforderte eine Neuausrichtung. Nach eingehender Analyse und Identifikation der Probleme (technische Schulden, Fokussierung, Transparenz, Kommunikation, Akquise- und Begleitprozess, Dokumentation) wurden entsprechende Maßnahmen umgesetzt. Unter anderem wird Scrum als agiles Vorgehensmodell eingeführt, um in kurzen Zyklen die Fortschritte der Neuausrichtung zu messen und Maßnahmen iterativ anzupassen. Zu den Maßnahmen der Fokussierung zählte unter anderem die technische Basis gleichförmig, kompakt, kundenorientiert und erweiterbar umzugestalten. Zu den prozessualen Verbesserungen kam die Etablierung von Bug-, Feature-, Review- und Status-Prozessen hinzu.
• Die Teamgröße belief sich auf 5. Kernaufgabe im Projekt war IT-Coaching, Scrum Master und Unterstützung bei der Umsetzung der Maßnahmen.

• Die Teamgröße belief sich auf 3. Kernaufgabe im Projekt war ?Lead-Architect? und Konzeption.

• Die Teamgröße belief sich auf 4-6. Kernaufgabe im Projekt war ?Lead-Architect? und Coaching.

• Als Vorgehensmodell wurde Scrum mit 4 Feature-Teams und einem Governance-Team zur Gewährleistung eines agilen Softwareentwicklungs-Prozesses eingesetzt. Teamübergreifende Kernaufgabe im Projekt war ?Chief-Architect? und Unterstützung in der fortgeführten fachlichen Konzeption mit Schwerpunkt Business-Continuity.

• Als Vorgehensmodell wird Scrum mit 18 Teams zu je 10 Mitgliedern zur Gewährleistung eines agilen Softwareentwicklungs-Prozesses eingesetzt. Hauptaufgabe im Team und Team-übergreifend ist Architektur.