Ab Juli 2019 hat BMW den Software Provider für das unten genannte Teleservices Projekt von Sulzer zu ConSol gewechselt. Dabei wurden einige Kollegen, darunter auch ich, aus dem bestehenden Team übernommen, um einen reibungslosen Übergang zu gewährleisten.

Gemäß dem DevOps Gedanken, dem sich BMW verpflichtet hat, war ich als Brücke zwischen dem Entwicklungs- und dem Operations-Team tätig. In dieser neuen Rolle stand ich als Ansprechpartner für beide Teams zur Verfügung, dazu gehörten die Unterstützung des Betriebs bei schwerwiegenden Problemen und Incidents, Steuerung und Vorbereitung der Releases, Code-Reviews, Unterstützung von Kollegen aus der Entwicklung, etc.

Als Fortzsetzung meines Einsatzes im immer noch gleichen Projekt war ich als IT-Architekt und Anforderungsmanager für die Klärung und Spezifizierung der kommenden neuen Anforderungen verantwortlich. Dafür war ich in ständig engem Kontakt mit den zuständigen Personen aus IT und Fachbereich bei BMW, mit denen wir in regelmäßigen Meetings die geplanten neuen Features und Umbauten analysiert und konzipiert haben.

Eine wichtige Rolle spielten dabei naturgemäß Fragen zur Architektur der Microsevice-Landschaft, Definition der Schnittstellen, sowie das Design der verschiedenen Datenbanken. Teil dieser Tätigkeit war auch die Anfertigung von UML-Diagrammen, welche die entworfene Architektur beschreiben und dokumentieren.

Intern zum Team hin war ich zuständig für die Aufnahme der neuen Anforderungen ins Jira Backlog, wo sie in einer deutlich technischeren und konkreteren Sprache formuliert werden müssen, damit sie durch die Entwickler einfach und schnell in Java-Code umgesetzt werden können. Falls im Laufe der Entwicklung Unklarheiten oder Lücken festgestellt
wurden, hab ich sie zeitnah mit dem Kunden geklärt.

Darüber hinaus war ich gegenüber dem Projekmanagement insbesondere für das Review und Kontrolle der Schätzungen der Stories verwantwortlich, die letztendlich Grundlage für die Beauftragungen mit dem Kunden waren.

Im sonst unveränderten Projekt habe ich nach und nach die Rolle eines technical Leads übernommen. Neben der eigentlichen Entwicklung, die ich nach wie vor in reduziertem Umfang gemacht habe, bestand meine Tätigkeit primär darin, die Tasks/Stories auf die Entwickler in den Teams geeignet zu verteilen, bei Rückfragen und Unklarheiten als Ansprechpartner für die Kollegen in den Teams zur Verfügung zu stehen, Code Reviews durchzuführen, als technischer und fachlicher
Ansprechpartner für den Kunden (BMW) zur Verfügung zu stehen, und insgesamt die Qualität und den reibunslosen Ablauf des Entwicklungsprozesses sicherzustellen.

Zu dieser Zeit bestand eine der Haupttätigkeiten im Projekt darin, die bestehenden Microservices in eine Private Cloud Umgebung zu migrieren und dort zu verwalten. Als Cloud Plattform kam OpenShift zum Einsatz, die wiederum auf Technologien wie OpenStack, Docker, Kubernetes, etc. aufbaut.

Im Projekt Teleservices geht es um die Anbindung der Fahrzeuge an die Backend-Systeme der BMW AG, so dass ein bedarfsorientierter Datenaustausch ermöglicht wird – sowohl vom Fahrzeug zum Backend, als auch umgekehrt. Dadurch wird eine Vielzahl Dienste für den Kunden ermöglicht, z.B. automatischer Notruf (inzwischen gesetztlich vorgeschrieben), Pannen-/Unfallhilfe, elektronisches Fahrtenbuch (steuerlich vom Finanzamt anerkannt), elektronische Wartungshistorie („Scheckheft“), etc.

Die Backend-Landschaft von BMW ist extrem verteilt und umfangreich. Das Teleservices Backend bestand ursprünglich aus 6 Applikationen, die im Laufe der Zeit in kleinere Microservices aufgeteilt wurden. Inzwischen verteilt sich die Logik auf 15-20 Microservices, die in komplexer Art und
Weise miteinander verwoben sind. Somit besteht ein Großteil der
Herausforderungen im Projekt darin, den richtigen „Schnitt“ in der
Architektur zu finden, damit das Gesamtsystem stabil und langfristig wartbar bleibt.

Meine Aufgaben:
Zum Zeitpunkt meines Einstiegs befand sich das Projekt mitten in einer Migration von IBM WebSphere als Applikationsserver nach Glassfish 3. Nachdem die Migration abgeschlossen war, wurden neben der Umsetzung einer Vielzahl neuer fachlicher Features die einzelnen eher monolithischen Applikationen immer mehr in Microservices aufgeteilt. Bei diesem Schritt wurde gleichzeitig noch eine Migration von Glassfish 3 auf
Glassfish 4, bzw. von JEE 6 auf JEE 7 durchgeführt. Eventuell
vorhandene ältere SOAP-Webservices wurden auf REST und dem Framework Swagger umgestellt.

Neben REST kommunizieren die einzelnen Applikationen/Services miteinander auch asynchron über Message Queues (JMS) – als MQ Broker wurde IBM WebSphereMQ verwendet. Darüber hinaus kamen Standard-Technologien aus dem Java Backend-Bereich zum Einsatz, wie EJB 3, JPA (mit EclipseLink als Default JPA-Provider in Glassfish), Jenkins, Maven,
Git/Bitbucket, etc. Als Datenbanken kommen Oracle 12c und Postgres 9 zum Einsatz.

Zum Kunden:
Die Mühlbauer AG ist mit ihrer Tochter Mühlbauer ID Services GmbH ein weltweiter Anbieter von Systemen zur Erfassung, Verwaltung und Herstellung von Ausweisdokumenten (Personalausweise, Reisepässe), Führerscheinen, Fahrzeuganmeldungen, u.ä. Die Software ist naturgemäß
sehr eng an die Gesetzgebung des jeweiligen Staates gebunden, in dessen Auftrag das System entwickelt wird, und umfasst je nach Anforderung auch Aspekte wie Fingerabdruck-Erfassung und -Abgleich, Aufnahme von Iris-Bildern, und andere Biometrie-Komponenten. Da es sich hierbei um hochsensible personenbezogene Daten jedes einzelnen Bürgers ganzer Staaten handelt, unterliegt das System sehr strengen
Sicherheits- und zugleich Performance-Anforderungen.

Zum Projekt:
Das System besteht aus mehreren Modulen, von denen einige
geographisch verteilt (in den einzelnen Ämtern vor Ort) laufen, und andere wiederum zentral im Rechenzentrum. Je nach gesetzlicher Vorgabe entfallen verschiedene Teile des gesamten Workflows auf die dezentralen und zentralen Komponenten. Auf die Daten kann mittels einer Reihe von Clients zugegriffen werden, die jeweils für unterschiedliche Beamte (Rollen) vorgesehen sind und daher auch nur bestimmte Aktionen
ausführen können.

Zu meinen Aufgaben gehörte zunächst die Entwicklung eines dieser Clients unter Verwendung von JSF 2 und PrimeFaces als Frontend-Technologien, sowie JEE 6, EJB 3 und JPA/Hibernate als Backend. Später war ich auch in der reinen Backend-Entwicklung tätig und habe die vorhandene Workflow-Logik an die Anforderungen des Kunden angepasst.

Das Technologie-Stack wird von JBoss 7, Oracle 11g als Datenbank, Eclipse, Maven, Jenkins, Subversion und Redmine abgerundet. Die Entwicklung fand unter einem angepassten Scrum-Modell statt.