Artikel: Das große Ganze in der Entwicklung betrachten
Softwarearchitekt:innen behalten den Überblick und kümmern sich darum, die richtigen Lösungen und Strukturen für Softwareprojekte zu wählen, um eine ideale und langfristige Grundlage haben. In dieser Career Story lernen wir Carsten Hoffmann kennen. Er ist Entwickler und zugleich Softwarearchitekt.
Carsten nennt seine Jobbeschreibung „architekturschaffendes DevOps-Team-Mitglied“. Das klingt vielleicht etwas sperrig, trifft es aber genau. Denn Carsten ist in erster Linie Softwareentwickler in einem Produktteam, kümmert sich dabei zugleich um die Architektur dieser Software. Er ist vor sechs Jahren als Softwarearchitekt zu DB Systel gekommen und inzwischen seit gut zwei Jahren als Entwickler mit Architekturaufgaben in einem DevOps-Team. Carsten arbeitet im Team „Platforms for New Mobility“ und entwickelt am „Curbside Management“, der einheitlichen Verwaltung von Mikromobilitätslösungen wie Leihroller für Kommunen.
Was machen Softwarearchitekt:innen?
„Die Architektur besteht aus den Dingen, die man nicht mehr leicht ändern kann“, definiert Carsten selbst. Welche Frameworks und Lösungen passen am besten zu den Anforderungen? Welche Lösungen gibt es und wie interagieren diese miteinander? Es geht um die grundsätzlichen Entscheidungen in der Entwicklung, damit alle Komponenten ideal zusammenarbeiten und keine technologischen Sackgassen entstehen. Ein entscheidendes Ziel von Architekturarbeit ist es, dass die geschaffene Lösung die Qualitätsziele erfüllt. Die Architektur legt auch die Hierarchien der Softwarekomponenten fest.
Carsten ist somit einerseits klassischer Softwareentwickler, hat zusätzlich immer das große Ganze der Anwendung im Blick: „Wenn wir 20 Services haben: wie schaffen wir es, dass die alle zusammenarbeiten?“ Er legt dabei Wert darauf, dass er ein Praktiker ist und kein reiner Softwarearchitekt, der theoretische Technologiekonstellationen auf Powerpoint-Folien malt. „Architektur ist erst dann wirksam, wenn man auch in die Umsetzung kommt“, sagt er selbst dazu.
Im Alltag unterscheiden sich die Aufgaben je nach Phase der Entwicklung. In Umsetzungsphasen schreibt er Code, testet und plant wie alle anderen im Team. Parallel dazu achtet er vor allem bei neuen Anforderungen darauf, dass Schnittstellen dokumentiert sind und die verwendeten Systemlösungen dazu beitragen, diese Anforderungen zu erfüllen. Neue Anforderungen für das Projekt kommen meist entweder aus Ausschreibungen oder aus dem Team heraus. Da das Team nach agilen Prinzipien arbeitet, wechseln sich die Phasen häufig ab.
Zusätzlich hat er als Mitglied eines DevOps-Teams auch Mitverantwortung für den Betrieb der Anwendung. Hier sollte jede:r beinahe alles über das Produkt wissen, um in Sachen Betrieb und Support fit zu sein. „Wir haben eine betriebliche Verantwortung, da wir unser Produkt selbst betreiben“, sagt Carsten. Beispielsweise ist im Team immer jemand wechselnde:r Ansprechpartner:in und DevOps-Aufpasser:in. Bei einer Schwachstelle muss diese beispielsweise in 48 Stunden behoben sein.
Ich will doch nicht zur Bahn, oder? Der Weg zu DB Systel
Carsten hat ursprünglich Chemie studiert. Bereits während des Studiums hat er jedoch gemerkt, dass er das Fach der Chemie interessanter fand als den tatsächlichen Beruf des Chemikers. Deshalb ist er auf Informatik umgeschwenkt und hat dies bis zum Master durchgezogen. Währenddessen sammelte er bereits erste Erfahrungen als Entwickler. Nach dem Studium arbeitete Carsten in einem Entwicklungsteam eines Anbieters einer Mediendatenbank, wurde dort zum Teamleiter. Hier waren er und sein Team für die Softwareintegration in Kundenprojekten zuständig. Dabei ging es in der Praxis bereits fast immer um Schnittstellen und Systemintegration der Anwendung in die Umgebung des Kunden.
Carsten ist über eine Headhunterin zur Systel gekommen. DB Systel? Das hatte er zur dieser Zeit noch nie gehört, sagt er rückblickend mit einem Lachen. „Zur Bahn wird man ja wohl eher nicht wollen“, erinnert er sich an seine erste Reaktion. Nach einer halben Stunde Telefonat hatte sich das bereits deutlich geändert: Die Kombination aus Cloud-Strategie, der konsequenten Transformation hin zu agilem Arbeiten und dem positiven Menschenbild haben sein Bild um 180 Grad gedreht und genau die richtigen Knöpfe gedrückt, die Carsten wichtig waren.
Wenn man sich in einem Unternehmen um die Architektur von Softwarelösungen kümmern möchte, sollte man vor allem einen guten Überblick über relevante Tools und Technologien haben, rät Carsten. Neben dem Gesamtüberblick ist für ihn in seiner Rolle im DevOps-Team vor allem das Kubernetes-Umfeld wichtig: Wie sichert man den Code ab, was sind die Container-Vorgaben im Unternehmen? Die vielen Deployments kleinerer Code-Änderungen des Teams funktionieren nur mit viel Automatisierung und einer hohen Testabdeckung.
Voller Einsatz für Standards und offenen Code
Carsten engagiert sich neben seinen Kernaufgaben intern sehr für Themen, die ihm wichtig sind. So ist er Teil der sogenannten „Architekturgilde“. Dies ist ein Gremium, dass sich im Auftrag der Geschäftsführung um IT-Standards im Unternehmen kümmert. Die Gilde erstellt Architekturstandards für teamübergreifende Themen und verbessert die Qualität der Architekturarbeit durch methodische Impulse. Durch die breite Vernetzung ins gesamte Unternehmen ist die Gilde ein zentraler Ansprechpartner für Architekturfragen. Außerdem tritt die Architekturgilde als Maintainer des DB Systel Techradar auf, welches technisch auf dem bekannten AOE Techradar basiert.
Zudem engagiert er sich im Thementeam „Inner Source“, das sich dafür einsetzt, intern entstandenen Code innerhalb der Deutschen Bahn für alle nutz- und verfügbar zu machen. Dies ist ein Ansatz für eine interne Open-Source-Politik. Auch dies hilft dabei, Standards zu etablieren und allen anderen Zeit, Kosten und Arbeit zu sparen. Hierzu gibt es bereits eine eigene Lizenz für Inner Source für die Bahn und es entsteht ein eigenes GIT (eine Software für Quellcode-Management) mit nutzbarem Code unter dieser Lizenz. Carsten ist außerdem Maintainer eines OpenSource Projektes in der DB Systel Organisation auf GitHub: Dem Trivy Vulnerability Explorer.
Weiter