Meet the Geek

Folge 15: Der Cloud Solution Architect. Von BASIC zu containerisierten Azure-Lösungen.

von am

Benjamin ist ITler mit Leidenschaft, hat sich vom Fachinformatiker zum Cloud Solution Architect gemausert und ist dabei mit den Anforderungen an die Branche gewachsen. Immer auf der Höhe der Technologien, erfreut der UNIX-Fan als Consultant Kunden mit passgenauen Lösungen.

Benjamin Hering, Cloud Solution Architect
Name:
Benjamin Hering
Alter:
38 Jahre
Arbeitsplatz:
TIMETOACT
Arbeitsgebiet
System Engineering, Consulting
wichtigste Tools bei der Arbeit:
TeamViewer & Co., die UNIX-Konsole
Arbeitsmotto:
"Man lernt nie aus."
Hobbys:
draußen sein, kochen

Über „Meet the Geek“


Benjamin, Dein Vortrag vermittelt den Eindruck, dass Du für Deinen Job als Consultant in Sachen Lösungsarchitektur brennst. Wie hast Du diese Leidenschaft entdeckt und fandest Du zu Deiner Profession?

Zunächst mal: Ich war schon als Kind technikbegeistert, das ist meine ganze Familie. Meine drei Brüder haben alle IT-Jobs. Wir sind durch unseren Vater so geprägt worden, der Radio- und Fernsehtechniker war. Wir hingen immer in dessen Werkstatt rum und haben tausend Fragen gestellt. Den Mitarbeitern sind wir wahrscheinlich ganz schön auf die Nerven gegangen.

Zwischenfrage: Kamst Du so auch früh mit Computern in Kontakt?

Die Eingabekonsole für BASIC eines Commodore C64.
Schon als Kind hatte Benjamin ein Faible für Kommandozeilen. An der Konsole für BASIC auf dem C64 hat er sich da jedenfalls schon versucht. Bild: Wikimedia.

Vermutlich nicht besonders “früh”. Aber durch die Begeisterung für Technik habe ich mich da schon mit beschäftigt. Mein erster Computer war ein C64. Mein Vater hielt das aber eher für Spielzeug. Ich habe dann angefangen, damit zu experimentieren und versucht, eigene Spiele in BASIC zu programmieren. Das Ergebnis war ein sehr rudimentärer Super-Mario-Klon. Mein Vater hat das gesehen und ich habe ihm alles erklärt. Er meinte zwar: “Das verstehe ich alles nicht wirklich”, aber kurze Zeit später kaufte er dann unseren ersten PC. Irgendwann habe ich als Jugendlicher dann auf einem alten Rechner meine erste UNIX-Maschine aufgesetzt und bin bis heute Fan des OS. Von meinem Vater habe ich übrigens auch die Devise: “In technischen Berufen lernt man nie aus!” Darum habe ich mich in meiner Karriere immer weiterentwickelt und neue Sachen gemacht.

Erzähle uns doch von Deiner Laufbahn.

Ich habe ganz normal mit einer Ausbildung als Fachinformatiker Systemintegration angefangen. Damals schon bei TIMETOACT. Da bin ich dann auch bis heute geblieben, allerdings über die Jahre in unterschiedlichen Rollen. Nach der Ausbildung habe ich erstmal interne Systeme verwaltet und mich in einer klassischen Admin-Rolle mit der eingesetzten Software beschäftigt – wir waren damals vor allem auf Dienstleistungen in der IBM-Welt spezialisiert. Zudem habe ich die Anwendungsentwicklung unterstützt, aber da herrschte damals natürlich noch die klassische Trennung von Betrieb und Entwicklung. Als sich das Unternehmen immer mehr zum Service Provider entwickelte, veränderte ich mich auch in Richtung Unterstützung der Kunden, vor allem beim Betrieb unserer Softwarelösungen und von IBM-Softwareprodukten. Von da aus habe ich mich zum Consultant entwickelt. Mit meiner Vorerfahrung an der Schnittstelle von Softwarebetrieb und -entwicklung wurde ich dabei schließlich zum Solution Architect.

Was sind dabei Deine wichtigsten Aufgaben?

Die sind vielfältig und das ist auch genau das, was ich an dem Job so mag. Ich berate weiterhin zum Betrieb unserer Software. Gleichzeitig versuche ich aber, im Kundenkontakt auch Möglichkeiten und Potenziale für eine weitere Zusammenarbeit zu identifizieren. Grob gesagt, plane und konzipiere ich für die Kunden Architekturen für passgenaue Softwarelösungen und helfe bei der Umsetzung, etwa der Integration in die Kundensysteme. Dabei muss ich die Anforderungen aus ganz unterschiedlichen Blickwinkeln betrachten: Um den stabilen Betrieb zu gewährleisten, nehme ich die Admin-Sicht ein, um Nutzen und Nutzbarkeit zu bewerten, nehme ich die User-Perspektive ein und natürlich muss ich etwa die Kosten im Blick behalten, um die Entscheider glücklich zu machen. Ich muss die technische und die jeweilige fachliche Sichtweise unter einen Hut bringen. Das ist sehr spannend!

Laut Deinem Xing-Profil lautet Dein Jobtitel “Cloud Solution Architect”. Nimmt die Datenwolke mittlerweile also eine besondere Rolle in deinem Tun ein?

Auf jeden Fall! Viele Unternehmen verlegen mittlerweile Systeme in die Cloud. Der Trend geht da klar in Richtung Infrastructure oder Platform as a Service. Ich entwickle dafür Lösungen in der Cloud oder Private Cloud und sorge konkret für Implementierungen und Migrationen. Außerdem steigen viele unserer Kunden gerade auf Microsoft 365 um. Dadurch tauche ich thematisch neben der IBM-Umgebung auch immer tiefer in die Microsoft-Welt ein. Diese Entwicklungen sind spannend mitzuerleben. Hat man früher noch Software auf speziellen Servern betreut, die von den Admins gehegt und gepflegt wurden, laufen jetzt nach und nach Infrastrukturen, Entwicklungsumgebungen und auch die Software selbst “as a Service”. Das geht bis hin zur Containerisierung. Alles wird immer flexibler und schneller anpassbar. Da hat mein Feld in den letzten Jahren rasante Entwicklungen genommen.

Inwieweit haben sich die Anforderungen an die IT durch die neuen Technologien verändert?

Unternehmensprozesse werden zunehmend dynamischer. Das wird durch agile Softwareentwicklung flankiert, mit schnelleren Entwicklungszyklen. Insgesamt ist das Umfeld heute flexibler und stetigen Veränderungen unterworfen. Gleichzeitig sind die Anforderungen an IT und Software gestiegen: Die User wollen, dass Systeme flüssig laufen und gleichzeitig von überall aus 24 Stunden am Tag verfügbar sind. Da kann man nicht mehr mal eben abends den E-Mailserver runterfahren, um Wartungen vorzunehmen. Gleichzeitig müssen die Systeme aber auch stets auf dem neuesten Stand gehalten werden. Mit der zunehmenden Zugänglichkeit der Systeme sind natürlich auch die Anforderungen an die Informationssicherheit gestiegen. Und man muss mehr rechtliche Aspekte beachten.

Allgemein denke ich, dass man in einer dynamischen Cloud-Umgebung nicht mehr vom klassischen Bild “des ITlers” ausgehen kann: dem autark arbeitenden Systemadministrator. Früher war die Infrastruktur relativ starr. Man hatte sich für Systeme entschieden, die physisch in Form von Servern und Clients installiert und dann optimiert und gepflegt. Da hieß es dann irgendwann: “Never touch a running system”. Heute wachsen Betrieb und Software sowie deren Entwicklung zusammen und Änderungen an Systemen kann man von zu Hause aus jederzeit anpassen – häufig ohne downtime. Das verlangt auch von der “Operations”-Seite Dynamik und Agilität.

Kannst Du das mit den rechtlichen Anforderungen noch weiter erläutern?

Vor 15 Jahren hätte ich mir nicht vorstellen können, dass ich mich in meinem Job mal mit Gesetzestexten befassen müsste oder zu Gerichtsurteilen auf dem Laufenden bleiben müsste, wie jetzt wegen des “Privacy Shields”. Vor zwanzig Jahren war IT noch wesentlich anarchischer. Die IT stand vor einem Problem oder einer Anforderung und hat dann eine technische Lösung gebaut. Da hat keiner über rechtliche Implikationen nachgedacht. Heute gibt es gesetzliche Regelungen zu IT-Themen und Rahmenwerke zu Informationssicherheit. Auch mit dem Datenschutz muss man sich spätestens seit der DSGVO beschäftigen. Da muss ich meinen Kunden zum Beispiel häufig raten, datenschutzkonforme Lösungen anzubieten, weil sich die Nutzer sonst eigene suchen. Wenn ein Unternehmen beispielsweise keine Messenger-Lösung implementiert hat, fangen die Mitarbeiter*innen mitunter an, WhatsApp zu benutzen. Das kann dann rechtliche Probleme verursachen. Diese Perspektive muss ich also stets mit im Blick haben.

Eine Grafik zur Methode DevOps
Der DevOps-Ansatz gewinnt zunehmend an Bedeutung . Bild: Wikimedia.

In Deinem Vortrag erwähntest Du, dass Betrieb und Softwareentwickler zunehmend enger zusammenarbeiten müssen. Wird der DevOps-Ansatz dabei wichtiger?

Ja, das wird er definitiv! Heute müssen Betrieb und Entwicklung von Beginn eines Projektes an lösungsorientiert zusammenarbeiten. Dabei muss man die gegenseitige Perspektive einnehmen können. Früher haben die Entwickler eine Anforderung in eine Anwendung umgesetzt, dabei aber häufig gar nicht an den Betrieb gedacht. Und die Admins dachten sich: “Liefer mir die Software aus, wenn sie läuft läuft sie, wenn nicht, halt nicht.“ In einer dynamischer werdenden Geschäftswelt geht das so nicht. Da muss man an einem Strang ziehen. So kann man modernen Ansprüchen gerecht werden, die die Technik möglich gemacht hat. Etwa die Automatisierung von Deployments und Testings oder die Sicherstellung der Skalierbarkeit von Infrastrukturen und Services kann man nur in Zusammenarbeit zwischen den System-Profis und der Entwicklung umsetzen. Das alles hat natürlich auch die fachlichen Anforderungen an den Betrieb erweitert. Wenn ich heute Systeme plane oder betreue, muss ich mich um Dinge wie Security, Berechtigungsmanagement und die Softwareintegration in Cloudumgebungen kümmern. Alles in allem bekam der Bereich IT einen neuen Abstraktionsgrad, der nur gemeinsam zu bewältigen ist.

“Automatisierung” ist mittlerweile ein zentrales Thema in Deinem Feld. Besteht die Gefahr, dass man damit dann irgendwann Arbeitsplätze in der IT abschafft?

Als Gefahr würde ich das nicht sehen. In der IT ist es ja irgendwie der eigene Job, sich selbst wegzurationalisieren. Es geht ja im Kern um die Automatisierung von Arbeitsprozessen – halt auch der eigenen. Wenn man ein Script schreiben kann, das manuelle Arbeit ablöst, sollte man das tun. Wenn es eine Software gibt, die Patches sicher verteilt, sollte man die einsetzen. Wenn man in der IT arbeitet, muss man fachlich immer auf der Höhe der technologischen Entwicklung bleiben. Dann wird man auch nicht obsolet. Mit den neuen Möglichkeiten von Technologien wachsen auch die Anforderungen an die Technik, was wiederum zu größeren, komplexeren Systemen führt. Wenn man die neuesten Techs stets meistert, wird es auch eine Aufgabe für einen geben.

Wenn man in der IT arbeitet, muss man fachlich immer auf der Höhe der technologischen Entwicklung bleiben. Dann wird man auch nicht obsolet.

DevOps, IoC, Automatisierung – ein paar Deiner Felder sind nah am Code gebaut. Beherrschst Du auch selbst Programmiersprachen, außer BASIC natürlich?

Natürlich bin ich in der Ausbildung mit Programmiersprachen in Berührung gekommen. Ich habe mich aber später auch stetig weitergebildet. Neben Assemblern beherrsche ich etwa noch Java und JavaScript. Ich könnte keine Anwendungen coden, aber es reicht, um sich auf Augenhöhe mit Softwarearchitekten zu unterhalten. Da geht es wieder darum, die Perspektive des Gegenübers einnehmen zu können. Und natürlich kann ich als UNIX-Jünger Bash-skripten.

Wir sind durch Deine umfangreich Expertise schon weit geschweift. Zum Abschluss noch etwas ganz anderes: Was wäre wohl aus Dir geworden, wenn Du nicht die IT-Richtung eingeschlagen hättest?

Einer meiner Träume als aktiver Fußballer war natürlich, Profi zu werden. Ich bin mir aber nicht sicher, ob es dazu gereicht hätte. Sonst wäre es sicherlich auch was mit Technik geworden, etwa was mit Engineering. Aber die IT ist meine Leidenschaft

Benjamin, danke für die schönen Abschlussworte und das interessante Gespräch!