Mein Name ist Ralf D. Müller und ich arbeite als angestellter Software Architekt bei der DB Systel, der IT-Tochter und Digitalpartner der Deutschen Bahn.
Momentan befinden wir uns in einer spannenden Transformationsphase von einer hierarchischen Managementstruktur hin zu einer Netzwerkorganisation mit agilen Teams. Meine Rolle wird dann die eines Software Engineering Advocates sein, also Teil eines Teams, welches sich für die projektübergreifenden Belange der Software Engineers einsetzt. Dabei werde ich unter anderem das Thema Architekturdokumentation mit dem Docs-as-Code Ansatz treiben. Also Dokumentation wie Code zu behandeln.
Ich gehöre zu den klassischen Geeks, die schon in der Kindheit viel Zeit am 8-Bit Rechner (Atari 800XL) verbracht haben. Nach dem Abitur habe ich Informatik studiert, weil mir nichts anderes eingefallen ist. Er später merkte ich, dass dies eine gute Entscheidung war :).
Meine Neugierde hat mich immer weitergebracht, so dass ich mir als Entwickler ein breites Spektrum an Wissen und über Projekte auch viel Erfahrung angeeignet habe – genau das, was einen Software-Architekten auszeichnet. So bin ich dann immer stärker in diese Rolle geschlüpft, bis ich irgendwann als Architekt bezeichnet wurde.
Wichtig auf diesem Weg waren auch die vielen Vorbilder, an denen ich mich immer wieder orientiert habe, sei es über Bücher, die ich verschlungen habe oder Talks auf Konferenzen denen ich lauschen konnte.
Als ich meine erste System-Architektur beschreiben wollte, orientierte ich mich natürlich am arc42-Template von Gernot Starke. Als Techie war es mir allerdings zuwider, eine Textverarbeitung zum Beschreiben der Dokumentation zu verwenden. Dadurch bin ich in mein Spezialgebiet „Docs-as-Code“ gerutscht.
Ich habe sehr viele Freiheiten in der Gestaltung meiner Arbeit und ich kann andere Entwickler bei Ihrer Arbeit unterstützen. Das sind zwei wichtige Aspekte, die ich an meiner Arbeit schätze und auf die ich nicht mehr verzichten möchte.
Auf was ich allerdings gerne verzichten möchte, sind E-Mails. Zumindest versuche ich die Mail-Flut auf andere Kanäle wie z.B. Chats zu dirigieren.
Morgens wird zuerst im Kreis der Familie gefrühstückt und die Kinder auf Kindergarten und Schule verteilt. Anschließend entscheide ich nach einem Blick in den Kalender, wo ich arbeite. Entscheide ich mich für das Büro, dann geht es mit Fahrrad und S-Bahn Richtung Frankfurt. Da ich über einen flexiblen Arbeitsplatz verfüge und wir fast alle Meetings „remote-first“ gestalten, spielt der Ort, an dem ich arbeite aber nur eine untergeordnete Rolle.
Während des Arbeitstages fallen dann recht unterschiedliche Tätigkeiten wie Workshops, Reviews oder das Erstellen von Code für einen Proof-of-Concept an. Kein Tag gleicht dem Anderen.
Nach getaner Arbeit passt es zeitlich meist, dass ich im Kreis der Familie zu Abend esse und noch Hausaufgaben (Mathe) durchgehe oder mich anders mit den Kindern beschäftige. Manchmal verbringe ich den Abend aber auch z.B. bei einer Java User Group oder einem Meet-Up.
Mein Arbeitsplatz ist durch das flexible Arbeiten sehr unterschiedlich. Wichtig ist ein guter, bequemer Stuhl um konzentriert arbeiten zu können. Um die hohe Flexibilität zu erreichen, habe ich mich an die Arbeit mit Notebooks gewöhnt, auch wenn das wohl nicht ergonomisch ist – auf Maus, externe Tastatur und zweiten Monitor verzichte ich die meiste Zeit. Mein wichtigstes Arbeitsgerät ist mein ab- und anschließbarer Rucksack mit Adaptern und eingebautem Netzteil. Auch ein gutes Headset für Videokonferenzen darf nicht fehlen.
Wichtig sind mir auch meine Notebook-Aufkleber – sie dienen oft als erster Aufhänger für ein Gespräch und für das wechselnde Umfeld, in dem ich mich bewege habe ich auch immer einen „Hello, my Name is…“-Aufkleber drauf.
Wenn man sich die Konferenzthemen und Zeitschriftenartikel ansieht, so ist Grails tatsächlich nicht mehr häufig genannt, aber das sehe ich für eine etablierte Technologie als normal an. Viel interessanter ist der neue Erfolg des Grails-Teams mit Micronaut und jetzt, ganz frisch, Predator. Durch die Innovationsfähigkeit des Teams kommt immer wieder neuer Schwung auch in Grails – Grails 4 bringt nun auch Micronaut mit.
Somit sehe ich keinen Grund, nicht auf Grails zu setzen. Im Gegenteil – ich schätze weiterhin vor allem den sehr gut umgesetzten Convention over Configuration Ansatz, der mir die Softwareentwicklung vereinfacht und beschleunigt. Damit werde ich zwar nicht zum 10x Entwickler, aber ich muss auch nicht bei jeder Anwendung alles neu konfigurieren, sondern habe gleich out of the box ein fertig konfiguriertes Projekt.
Java hat zwar langsam aber stetig gegenüber Groovy aufgeholt ohne zu Überholen :-D
Für mich sind die vielen Shortcuts gegenüber Java entscheidend. Um eine Datei mit dem richtigen Encoding einzulesen braucht man in Java weiterhin mehr als eine Zeile, oder?
def adoc = new File('demo.adoc').text
und das funktioniert sogar mit URLs
def html = new URL('https://www.jobpushy.de').text
Aber auch Closures und Power Assertions sind für mich super Features, die ich in anderen Sprachen vermisse:
Wie schon oben kurz angerissen habe ich mich im Rahmen der Architekturdokumentation von Softwaresystemen mit arc42 beschäftigt. arc42 ist DAS Template für Softwarearchitektur – es hilft nicht nur die Dokumentation zu strukturieren, sondern im arc42-Umfeld finden sich auch viele Beispiele und andere Hilfestellungen wie z.B. ein FAQ um gute Dokumentation zu erzeugen und sogar ein Buch mit vielen realen Beispielen. Das Template stammt von Gernot Starke und Peter Hruschka. Ursprünglich war es ein MS-Word-Template. Da mir dieses Format nicht so zusagte und ich mich damals auch mit AsciiDoc als rein textuelles Format für Dokumentation beschäftigte, sprach ich Gernot auf einer Konferenz auf eine Konvertierung des Templates in AsciiDoc an. Das Hauptproblem war der hohe Pflegeaufwand für mehrere Templates. Also haben wir herumexperimentiert und eine Lösung gefunden, mit der wir ein AsciiDoc-Template auch in Word und andere Formate konvertieren konnten. Mittlerweile konvertieren wir das Template aus dem AsciiDoc-Format automatisch in 9 weitere Formate!
Eine Architekturdokumentation lebt allerdings nicht vom Text alleine. Auch Diagramme sind ein wichtiger Bestandteil. Deshalb habe ich versucht auch das Einbinden von Diagrammen möglichst einfach zu gestalten und habe ein Script geschrieben, das aus einem UML-Tool alle Diagramme und dahinterliegenden Notizen exportiert.
Diese zwei Scripte habe ich dann als Open Source veröffentlicht. Es sind später noch viele weitere Scripte hinzugekommen, die alle die Arbeit mit Dokumentation im AsciiDoc-Format unterstützen. Die ganze Sammlung habe ich dann docToolchain genannt.
Natürlich – Vorbilder und vor allem auch Mentoren sind zu jedem Zeitpunkt im Berufsleben sehr wichtig. Das Schöne an der IT ist ihre Vielfältigkeit. Ich habe nicht nur ein Vorbild, sondern ich schätze die Community und die Tatsache, dass man von jedem vieles lernen kann, wenn man nur richtig zuhört. Ich habe mir z.B. vorgenommen in Zukunft 1x im Monat 1-2 Stunden remote Pair-Programming zu machen. Wer also Lust auf eine Session mit mir hat, der kann mich einfach mal ansprechen!
Schwieriges Thema. Mir macht die IT sehr viel Spaß, so dass ich mich auch in meiner Freizeit sehr gerne mit IT-Themen beschäftige. Allerdings hat die dafür verfügbare Zeit abgenommen, denn bislang konnte ich meine Kinder noch nicht dafür begeistern. Um dennoch mal etwas anderes zu machen, fahre ich gerne Rad oder häkele Figuren, so genannte Amigurumis. Das entspannt und macht den Kopf frei.
Am aktivsten bin ich auf Twitter unter @RalfDMueller. Meine Gedanken und Erkenntnisse rund um das Thema Docs-as-Code veröffentliche ich natürlich auf dem Blog von https://docs-as-co.de .