Im Herbst 2019 schloss ich mich der syracom AG in Wiesbaden Nordenstadt als Leading Consultant an und arbeitete fortan als Unternehmensberater. Die syracom ist ein inhabergeführtes Beratungsunternehmen mit Schwerpunkt auf der Geschäftsprozess- sowie IT-Beratung und fokussiert sich auf Banken und Finanzdienstleister im Großraum Frankfurt am Main. Für mich war das in mehrfacherer Hinsicht nach dem Ende meiner Gründerzeit sehr spannend.
Manche Dinge ändern sich – manche nicht
Zum einen wollte ich unbedingt lernen, wie die Dinge „richtig“ angegangen wurden. In meiner Zeit als Gründer und self-made Unternehmer wurde ich mit dem Problem konfrontiert, ohne dass ich darauf vorbereitet war und bereits auf Erfahrung aus meiner Vergangenheit zurückgreifen konnte. Ich habe schlicht keine Erfahrung darin, wie die Softwareentwicklung zu strukturieren und was die richtige Aufbauorganisation für mein Unternehmen ist. Leider hatte ich auch keine Zeit, mich darüber zu informieren oder mir gar Wissen in Ruhe anzueignen. Ich musste einfach machen, dass Beste hoffen und anpassen, wenn es nicht zum gewünschten Ziel führte. In der Unternehmensberatung konnte ich hier sehr viel lernen und mir abschauen, wie alle diese Themen von erfolgreichen Unternehmen angegangen wurden.
Darüber hinaus konnte ich weiterhin in einer verantwortungsvollen Position agieren und wichtige Themen oder Projekte vorantreiben. Ich wollte mich schlicht nicht „als ganz normaler“ Mitarbeiter in einem Team einbringen. Dafür war ich als Geschäftsführer leider „versaut“ worden. Das ist etwas, was mir mein Mentor und Business Angel bereits vor langer Zeit prophezeit hatte. Durch meine Erfahrung im Business und meiner technischen Expertise konnte ich hier weiterhin verantwortungsvolle Aufgaben in großen Projekten und Unternehmen übernehmen. Das war gut, um nach dem Ende meiner Unternehmerzeit wieder mit Freunde ans Werk gehen zu können.
Teambuilding in der syracom
Last, but not least war es wieder richtig toll, in einem Team willkommen zu sein! Die letzten Monate nach dem Ende des Unternehmens waren sozial etwas trist und mit vielen nicht ganz so schönen Themen der Liquidierung bestückt. Umso mehr hat es mich wieder gefreut, einem Teamevent beiwohnen zu können. Noch vor meinem ersten Arbeitstag wurde ich zu einem Ausflug auf dem Rhein eingeladen und konnte bei einem schönen Glas Wein am Rhein meine neuen Kollegen kennenlernen.
Ich war einfach nur zufrieden und stolz! Es war unheimlich toll, wieder eine neue Berufung nachgehen zu können und Teil eines neuen, großen Ganzen nachzugehen. Ich konnte mich wieder mit meinen Stärken einbringen, Dinge bewegen und einfach nur Dinge bearbeiten.
Das war eine tolle Situation für mich, nach der ich mich diesen Sommer über gesehnt hatte. Als vermeidlich gescheiterte Gründer war es schon eine große Belastung, sich mit all diesen Themen zu beschäftigen. Sich persönlich weiterzuentwickeln, sich zu reflektieren und sich wieder neuaufzurichten kostete mich unheimlich Kraft.
Am Ende des Tages kam meine kleine Tochter sogar zu ihrem ersten Geschäftsessen mit. Zeitlich gesehen war dies zwar etwas später, als ich schon einige Zeit bei der syracom tätig war. Dennoch hat sie sich ihre Brezel auf Firmenkosten schmecken lassen und zur positiven Stimmung unter meinen Kollegen beigetragen. Früh übt sich, auch wenn sie mit ihren wenigen Lebensmonaten noch recht still war.
Migration in die Cloud
In meinem ersten Projekt, welches ich übernommen habe, ging es um eine Emissionsplattform für Finanzprodukte für DZ Bank in Frankfurt Main, über den die komplette Ausgabe von Wertpapieren und deren Platzierung an einem organisierten Geld- oder Kapitalmarkt läuft. Hier hatte ich die Rolle des technischen Gesamtarchitekten über alle Teilprojekte der retailApps inne.
Diese Plattform für den Handel von strukturierten Finanzprodukten ist heute das Herzstück bei dem genossenschaftlichen Institut. Diese Plattform bietet der DZ Bank ein integriertes Workflowsystem, mit denen sie die Prozesse für die Emission von Zertifikaten und Derivaten digital abbilden und steuern kann. An diesen Prozessketten sind einige interne Abteilungen und Mitarbeiter für die Abstimmungsprozesse beteiligt. Genauso sind externe Systeme und Akteure wie die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) involviert.
In meiner Rolle als Softwarearchitekt habe ich die technische Neuausrichtung der bestehenden Plattform vorangetrieben. Schwerpunkt meiner Arbeit war der Einsatz von cloud-nativen Technologien und die Konzeption einer Migration in die Cloud. Das Ziel der Weiterentwicklung war eine moderne, flexible und zukunftsfähige Softwarearchitektur. Dazu habe ich die einzelnen Applikationen der Plattform containerisiert, horizontal skalierend als Microservices ausgelegt und mittels einer automatisierten CI/CD in die Cloud gebraucht.
Neben der technischen Arbeit an den Prozessen und der Architektur kam auch die Arbeit mit dem Entwicklungsteam und meinen Kollegen nicht zu kurz. Wir haben eng zusammengearbeitet und uns bilateral ausgetauscht, wie diese Migration in die Cloud bestmöglich anzugehen ist. Hier konnte ich mich mit meinem Wissen und meiner Erfahrung mit cloud-nativen und skalierende Softwarearchitekten bestmöglich einbringen.
Emissionsplattform für strukturierte Finanzprodukte
War die Containerisierung und Migration der Plattform hinter den retailApps noch natürliche Evolution, war die fachliche Automatisierung des Emissionsprozesses in der Plattform ein revolutionärer Schritt. Auch in der Finanz- und Bankenwelt drehen sich die Mühlen weiter – wenn auch vermeidlich langsamer. Aber auch hier geht die Richtung immer mehr zu Automatisierung und autonomer Verarbeitung, sodass immer weniger manuelle Kontrollschritte notwendig sind.
Bei der Emission von neuen Wertpapieren war hier der Wunsch der Bank, innerhalb von Minuten neue Finanzprodukte in den Markt emittieren zu können. Dadurch soll schneller auf Marktentwicklungen reagiert werden können, um schneller und zielgerichteter ihre Kundenwünsche adressieren zu können. Technisch betrachtet waren hier große Datenmengen, automatisierte Verarbeitungspipelines sowie nicht-funktionalen Anforderungen wie Hochverfügbarkeit und Skalierbarkeit im Spiel. Dies habe ich ebenfalls in der Systemarchitektur der Emissionsplattform berücksichtigt. Aus diesem Grund habe ich in der Architektur auf neue Technologien wie Cloud Computing, Container, Microservices, Stream Processing und verteilte (NoSQL-) Datenbanken gesetzt.
Im Rahmen eines Proof-of-Concept haben wir dann erfolgreich eine Ereignis-gesteuerte Architektur mittels Apache Kafka für die Verarbeitung von Wertpapieren verprobt. Dieser Technologie-Stack bildete die Grundlage für die automatisierte Prozessierung von Finanzprodukten in Echtzeit bildete. Dabei wurde in einem Showcase gezeigt, dass mittels Kafka als zentraler Eventbus sowie containerisierten Microservices eine leistungsstarke, skalierende Plattform geschaffen werden konnte. Alle nicht-funktionalen Anforderungen an Durchsatz und Verarbeitungszeit wurden hier übererfüllt. Die dafür entwickelten Microservices wurden in Docker Container verpackt und in einem Kubernetes Cluster deployed, wofür eine vollautomatisierte CI/CD-Strecke auf Basis von Jenkins aufgebaut wurde.
Für die automatisierte Verarbeitung von eingehenden Produktanfragen habe ich ein Konzept für das fachliche Monitoring des automatisierten Verarbeitungsprozesses konzipiert und umgesetzt. Die dabei anfallenden Datenmengen wurden in ElasticSearch als NoSQL- und dokumenten-orientierte Datenbank persistiert und von dort aus analytisch in einem Dashboard ausgewertet.
Das intelligente Stromnetz der Zukunft
Ich persönlich fand das Projekt bei einem großen, börsennotiertes Energieversorgungsunternehmen aus Deutschland am spannendsten. Nicht wegen der Branche, auch wenn ich hier nun das zweite Mal in meiner noch jungen Karriere in der Energiebranche gearbeitet habe. Vielmehr war es das Projekt als solches, weil ich mich hier ganzheitlich an einem innovativen, neuen Business Case mitgestalten konnte. Das Projektteam hatte nicht nur den Charme von einem Startup, sondern wir arbeiteten auch entsprechend. Intrapreneurship innerhalb eines großen Konzerns – das hat mir wirklich viel Spaß gemacht.
In diesem Projekt wurde eine neue Plattform für das intelligente Stromnetz der Zukunft konzipiert, planen und in seinen Kosten kalkuliert. Anlass war eine neue regulatorische Anforderung namens „Redispatch 2.0“. Mit dieser Maßname wurde das Ziel verfolgt, sich anbahnende Überlastungen des Stromnetzes frühzeitig abzufangen. Dafür werden intelligent Kraftwerke runter- und andere wiederum hochgefahren. Föderiert bei ca. 900 Verteilnetzbetreibern in Deutschland bedeutet, dass alle Energieerzeuger an einem Branchen-übergreifendem Datenaustausch für das „Redispatch-Managements“ teilnehmen müssen. Für diese Aufwände werden die Energieerzeuger monetär entschädigt, wofür entgangene Erlöse bzw. Mehrkosten bilanziert und untereinander abgerechnet werden müssen.
Das Ziel des Projekts war die Planung und Konzeption einer kundenzentrierte Cloud-Plattform, die sowohl regulatorische Anforderungen bedient als auch eine Grundlage für die Energiewelt von morgen schafft. Das Produkt als Softwareplattform und die darauf stattfindenden Dienstleistungen bietet der Auftraggeber wiederum seinen Kunden (andere Energieversorgungsunternehmen) als „Software-as-a-Service“ an. Auf lange Sicht geht es mit der geschaffenen Lösung um die Gewährleistung der Versorgungssicherheit angesichts der fortschreitenden Energie- und Verkehrswende.
Teile und beherrsche die Komplexität
Ich konzeptionierte alleinverantwortlich im Projektteam die zukunfts- und erweiterungsfähige IT-Architektur hinter der Plattform „Redispatch 2.0“. Dabei war ich ursprünglich als Architekt in diesem Projekt „eingekauft“ – arbeitete aber von Anfang an als Business Analyst eng mit dem Fachbereich zusammen. Dazu leitete ich die zu realisieren IT-Fähigkeiten aus den Geschäftsfähigkeiten der strategischen Business Capability Map. Ich gestaltete Ende-zu-Ende die aus Sicht des Fachbereichs benötigten Geschäftsprozesse für das „Redispatch 2.0“ entlang der Geschäftsbereiche aus (u.a. Stammdaten, Netzführung, Engpass-Management, Bilanzierung, Abrechnung, Marktkommunikation). Dazu bediente ich mich in der Anforderungsanalyse mit den jeweiligen Fachexperten der strukturierten Interviews und führte Event-Storming-Workshops durch.
Aus diesen technisch modellierten Fachprozessen erstellte ich dann eine Systemarchitektur für die Plattform. Ich bediente mich dabei dem Domain-Driven Design, um der Fachkomplexität Herr zu werden und diese in kleinere Microservices schneiden zu können. Damit überführte ich die fachlichen Anforderungen und zuvor modellierten Geschäftsprozesse in eine IT-Systemarchitektur. Anderseits lässt sich aus dieser Systemmodelliderung mittels Domain-Driven Design ebenfalls die Softwarearchitektur auf feineren Detailebenen bis auf Code- und Schnittstellen Ebene ableiten. Dies erlaubte es mir die Architektur auf Basis einer verteilten Cloud-Architektur, Containern und Microservices zu designen.
Wichtig ist jedoch nicht nur die geplante Architektur für sich gesehen. Auf der einen Seite waren wir weiterhin Teil eines großen Konzerns und mussten alle konzernweiten geltenden Compliance-Richtlinien identifizieren und einbinden. Ferner war die Systemlandschaft in der Energiebranche nicht gerade homogen und damit einfach zu integrieren. Es existierten eine Vielzahl an unterschiedlichen Systemen aller technischer Bauart, auch als kritischen Unternehmensbereichen wie z.B. den Leitsystemen. Am Ende überführte ich jedoch alles in eine Gesamtarchitektur, die auf noch hoher Flugebene dennoch den kompletten Business Case aus Architektursicht abbildet.
Intrapreneurship as its best
Als nächstes ging es dann um die Validierung der Business Hypothesen am Markt und mit potenziellen Kunden. So führte ich mit der Fachabteilung zusammen im Tandem Interviews für die Kunden- und Marktanalyse. Diese werteten wir im Anschluss aus, um die strategische Ausrichtung und das Pricing Model zu validieren und an die genauen Kundenbedürfnisse anzupassen. Wir nutzten diese Gespräche auch, um die Kunden zu segmentieren und gemeinsame Anforderungen an die Plattform zu identifizieren und daraus notwendige IT-Fähigkeiten der Plattform abzuleiten. Kleine Stadtwerke sind gänzlich anders aufgestellt als große Verteilnetzbetreiber und gilt es entsprechend abzubilden.
Weitere Gespräche führte ich auch mit Lösungsanbietern und Partnern. In der Kürze der Zeit konnten wir weder das Rad neu erfinden noch war dies strategisch sinnvoll. Ich screente also externe Anbieter von passenden Softwareprodukten, -Modulen sowie Dienstleistungen und führte die fachlich-technischen Interviews. Auf dieser Basis konnten dann „Make-or-Buy“-Entscheidungen getroffen werden. In diesem Zusammenhang führte ich auch erste, indikative Preisverhandlung mit potenziellen Lösungsanbietern.
Auf dieser Grundlage widmete ich mich der ganzheitlichen Projektplanung inkl. Budget-, Personal- und Meilensteinplanung sowie einer detaillierten Umsetzungs-Roadmap. Das Ziel meines, aus meiner Sicht viel zu kurzen, Projekteinsatzes war die Erstellung einer Entscheidungsvorlage für die Geschäftsleitung. Dazu stellte ich verschiedene, strategische Umsetzungsszenarien für die Plattform „Redispatch 2.0“ auf. Je nach getroffener Ausrichtung und Entscheidung über den strategischen Fokus kann die Plattform, in die eine oder andere Richtung umgesetzt werden. Ich bestimmte die Entwicklungskosten und das Sizing des einzusetzenden Entwicklungsteams. Dazu kalkulierte ich die techn. Betriebskosten der internen IT des Auftraggebers sowie für das Hosting bei externen Cloud-Anbietern. Die laufenden Wartungs- und Supportkosten summierte ich über die Betriebslaufzeit dazu.
Eine Gilde für die Cloud der syracom
Parallel zu der laufenden Arbeit in den Kundenprojekten war ich auch innerhalb der syracom aktiv. Hier hatten wir als eher kleinere Unternehmensberatung vor der Herausforderung gestanden, das Beratungsgeschäft mit der Weiterbildung der Mitarbeiter zu verbinden. Auf der einen Seite sind meine Kollegen gänzlich für die Kundenprojekte abgestellt. Auf der anderen Seite bedarf es jedoch der fachlich-technischen Weiterbildung der Mitarbeiter, damit jeder einzelne und das Unternehmen in Summe auch zukünftig am Markt bestehen kann. Wie kann dies aber gestaltet werden, wenn die Mitarbeiter in Kundenprojekten verkauft sind?
Der Vorstand entwickelte hierfür ein Modell, wie der Zeiteinsatz der Mitarbeiter sinnvoll zwischen diesen beiden Interessen aufgeteilt werden kann, sodass alle drei Seiten berücksichtigt sind: die Mitarbeiter, die Kunden und das Unternehmen. Mit diesem Modell in der Tasche machte ich mich an meine Arbeit, die Weiterbildung im Bereich Cloud und cloud-nativen Architekturen voranzubringen.
Ich bediente mich hier bei Spotify, genau an der Spotify Engineering Culture. Zwar konnten wir für uns als Bereitung schlecht die ganze Organisation mit den Tribes und Squads nutzen. Die Idee hinter den Gilden und Chaptern war jedoch für uns genau das richtige. Ich konzipierte also ein Chapter für den kollaborativen Austausch der Mitarbeiter und deren zielorientierte Weiterbildung in den neuen Technologien. Weiterbildungen, Qualifikation waren genauso Teil meines Konzepts wie sich hands-on selbständig und gegenseitig in Projekten diese Technologien und Paradigmen anzueigenen. Als Leiter dieser Gilde konnte ich mich so optiomal einbringen und meine Expertise in diesem Feld an meine Kollegen weiterbringen.