Wie baue und pflege ich Mission-critical Software?

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von digital kompakt und heute habe ich wieder meinen guten Freund, den lieben Björn Wagner zu Gast. Ihr wisst, Björn ist ja VP Engineering bei SAP Signavio und entweder Björn oder Till oder manchmal auch beide kommt immer dann her, wenn wir über Product, sprich Software und IT reden wollen. So, und heute machen wir das auch wieder, und zwar zum Thema Mission-Critical-Software. Das heißt, wie baue ich die eigentlich, wie gehe ich damit um, wie warte ich die, worauf kommt es an? Und, weil wir natürlich geballte Kompetenz hier haben wollen und noch nicht zufrieden sind, wenn nur Björn hier sitzt, obwohl er das locker auch alleine machen könnte, haben wir noch weiter aufgestefft, nämlich mit dem lieben Jan Schaffner. Ich habe gelernt, Schaffner, wie der Kollege im Zug, der ist nämlich SVP bei der Business Technology Platform von SAP. Und der kann ganz, ganz, ganz, ganz viel dazu sagen, wie nämlich Mission Critical Software funktioniert. So, heute werden wir also darüber reden, wie sieht denn eigentlich die Plattform von SAP aus, weil das ist Mission Critical Software und da macht der liebe Jan genau sowas. Wir reden über die Challenges und natürlich auch unterschiedliche Lösungsansätze für diese Challenges. Von daher, heute wird es glaube ich spannend und in diesem Sinne, moin moin ihr beiden, schön, dass ihr da seid.

Jan Schaffner: Hallo, schön hier zu sein.

Joel Kaczmarek: Wie bist du auf Jan gekommen, Björn? Ist das so ein Guter bei euch?

Björn Wagner: Wir kennen uns schon ziemlich lange, eigentlich seit der Uni. Wir arbeiten sehr viel intern natürlich auch mit den Technologien. Und dann haben wir gedacht, das ist ein Thema, was wir noch nicht bearbeitet haben und dass sich das anbietet.

Joel Kaczmarek: Na gut, also Fallhöhe hier, Jan. Erzähl doch mal kurz einen Satz zu dir. Wer bist du? Was machst du? Was macht man in deiner Rolle? Wie darf ich mir deinen Alltag vorstellen? Was hast du für Hobbys?

Jan Schaffner: Ja, also wie Jörn schon gesagt hat, wir kennen uns vom HPI. Da bin ich mir hergekommen. Ich bin jetzt seit elf Jahren bei der SAP in verschiedenen Rollen unterwegs, immer in der Softwareentwicklung. Und in der aktuellen Rolle, wo ich seit 2020 unterwegs bin, geht es eben darum, einen Kernteil unserer Plattform weiterentwickeln und zu betreiben. Und das ist eine Plattform, die wir sowohl externen Kunden anbieten, um SAP-Systeme zu erweitern. Also immer, wenn jemand vom SAP-Standard abweichen möchte, passiert diese Abweichung in der Regel über Code, den der Kunde über die Plattform deployed. Und wir nutzen die Plattform aber auch intern, um Neuentwicklungen oder teilweise Carve-outs von existierenden Produkten neu zu schreiben. Und das gibt uns relativ viel Effizienzvorteile. Also zum Beispiel als Nutzer möchte ich mich bei einer SAP anmelden. Anwendungen anmelden. Das wäre schön, wenn das immer gleich aussehen würde. Das ist so ein einfaches Beispiel. Ein komplexeres Beispiel ist vielleicht Auditlogging. Also manche Anwendungen müssen so einen Prozess unterstützen, dass ein Wirtschaftsprüfer einmal im Jahr kommen kann, um nachzuvollziehen, welcher Mitarbeiter welche kritischen Finanzdaten zum Beispiel wann angeschaut hat. und Und sowas gibt es in verschiedensten Anwendungen. und wir sagen halt, das wollen wir nicht jedes Mal neu implementieren, sondern haben so einen zentralen Service in unserer Plattform. Und unser Audit Logging Service hat zum Beispiel 240 SAP Anwendungen, die darauf aufsetzen. Das ist gut von der Effizienz. Die Downside ist, wenn dieser Audit Logging Service nicht verfügbar ist, haben wir mindestens 240 SAP-Anwendungen, die ebenfalls nicht verfügbar sind. Also da kommt eine gewisse Verantwortung mit. Und wir haben von dieser Art von Service größenordnungstechnisch so 80 verschiedene Capabilities, die wir halt liefern. Und unser Ziel ist es, auf eine möglichst verfügbare, verlässliche Art und Weise zu machen, auf Security zu achten, Aber natürlich auch hin und wieder dem ein oder anderen Feature-Wunsch zu entsprechen.

Joel Kaczmarek: Aber jetzt macht es mir Klick. Bei meinem letzten Essen mit Gero sagte er, du, ich habe auch einen Kollegen, der hat mit mir studiert am HPI, aber der hat wenigstens was Richtiges gemacht. Ich habe hier dieses Gründer-Zeugs gemacht und der ist bei SAP in die höchsten Riegen aufgestiegen. Das bist du.

Jan Schaffner: Ja, ich war mit dem Gero im Auslandsstudium sogar. Das war eine sehr schöne Zeit damals, ja. Wo wart ihr da? In Paris.

Joel Kaczmarek: Oh, da kann man uns schlechter treffen. Ja. Okay, gut. Grob verstanden. Also diese SAP-Plattform wird heute das sein, wo wir uns quasi mal daran abarbeiten, als Beispiel von Mission Critical Software, wo wir natürlich auf eure Erfahrungen zurückgreifen. Björn, kannst du auch nochmal so deine Sicht schildern auf diese Plattform? Also ich habe jetzt schon verstanden, über 80 Capabilities, so eine gewisse Zentralisierung. Man versucht sozusagen, was ja Jan gerade meinte, wenn jemand von den klassischen SAP-Pfaden abweichen will, da einen Angangspunkt zu haben. Ja. Wenn ich es richtig verstanden habe, für intern und für extern genutzt, ne?

Björn Wagner: Genau, absolut. Wie der Jan schon gesagt hat, wir bei SAP Signavio sind dann ein interner Kunde sozusagen, der auch verschiedene Services dieser Plattform nutzt. Genau von dem Hintergrund, dass wir die halt nicht selber bauen wollen und selber quasi maintainen wollen, sondern dass wir das möglichst effizient quasi wiederverwenden können. Und was dann natürlich aber auch heißt, wenn der Service vom Jan down ist, dann haben wir halt auch ein Problem. Und das multipliziert sich dann sozusagen aus und deshalb muss man halt schauen, wie man halt diese Services halt stabil und sicher betreibt, um halt sicherzustellen, dass quasi alle anderen, die davon abhängen, inklusive uns, das dann halt auch vertrauensvoll verwenden können. am Ende.

Joel Kaczmarek: Weißt du, da habe ich auch gerade schon gedacht, dass du natürlich so eine Single Point of Truth hast, aber auch auf Potential Failure. Also wenn es bei dir kracht, kracht es bei allen. Aber überwiegen die Vorteile, dass ihr dieses Risiko sozusagen gerne eingeht?

Jan Schaffner: Ja, das würde ich schon sagen, sonst würden wir es nicht machen. Also Developer-Produktivität ist ein Riesenthema bei uns. Und wenn du irgendwas 250 Mal baust, wartest, betreibst, ist es massiv ineffizient. Es geht nicht nur um die Entwicklung. Im Betrieb hast du ja auch Funktionen wie 24 mal 7 On-Call-Organisationen oder ähnliche Themen, was du auch verteilen musst um den ganzen Globus. Und da willst du einfach Skaleneffekte haben. Das ist eh ein sehr mitarbeiterintensives Geschäft, um das eben so effizient wie möglich zu gestalten. Und es gibt ja Techniken, die man anwenden kann, um die Risiken, ein Single Point of Failure zu sein, natürlich mitigieren zu können.

Björn Wagner: Vielleicht noch eine Sache, ich bin ja seit 2021 zur SAP gekommen und was wirklich auch so ein bisschen beeindruckend und vielleicht auch, sage ich mal, herausfordernd ist, wir hatten eine Zahl, uns wurde nochmal angeschaut, das war 99 der 100 größten Firmen der Welt laufen halt mit SAP Software. Das heißt, wenn dort halt was nicht funktioniert Dann hat das halt mitunter auch einen sehr, sehr großen Impact auf die Unternehmen. Das ist halt nicht die Standard-Social-Media-Anwendung, wo ich dann mal mein Bild nicht posten kann oder ein paar Werbeeinnahmen ausfahren. Das hat dann wirklich teilweise einen signifikanten Impact. Das heißt, die Table-Stakes sind auch sehr hoch, wie man so schön sagt an der Stelle.

Joel Kaczmarek: Ich habe gerade gedacht, wenn dich jetzt hier morgen ein Bus überfährt, dann ist die Weltwirtschaft im Arsch, Jan. Aber Spaß beiseite, da hat der Björn recht. Das ist ja schon ein hohes Verantwortungsniveau, was da bei euch liegt.

Jan Schaffner: Ja, wir hatten auch schon interessante Incidents tatsächlich, wo Trucks stillstehen.

Joel Kaczmarek: Und wie bildet ihr das vom Team her ab? Also an dieser Plattform, wenn du jetzt mal so ganz SAP im Bild hast, wie groß ist so euer Team? Wie seid ihr strukturiert? Wie ist die Organisation? Weil das wollen wir jetzt mal einmal verstehen, damit wir es dann sozusagen als Case Study nutzen können.

Jan Schaffner: Also es ist ein relativ großes Team. Wir haben auf circa 1300 Leute gearbeitet. Ja, so größenordnungstechnisch 150, 200 Leute, die eigentlich nur betriebsnahe Themen machen. Das heißt, wenn wir jetzt vielleicht 1000 Entwickler haben, haben wir dann 300 Leute, die sich darum kümmern, wie in Situationen, wo irgendein Incident passiert, schnell reagiert wird. Da haben wir dann so Prozesse in place, wie es gibt Monitoring und Alerts. Es gibt auch viele falsch positive Alerts. Man muss immer entscheiden, ist es jetzt was, was ich anschauen muss oder nicht. Da gibt es verschiedene Layer of Defense, sage ich jetzt mal, angefangen von Leuten, die einfach irgendwie da sind und so ein Playbook haben. Ich sehe folgendes Signal. Ich probiere mal aus, ob ich das Problem lösen kann, indem ich diese und jene Recommended Action ausführe. und wenn das nicht klappt, müssen wir ein Level tiefer gehen und holen einen sogenannten Site Reliability Engineer, in so einen Bridge Call nennen wir das, die dann die Situation strukturieren, verstehen, was wurde denn an der Komponente geändert über die letzten Tage oder Wochen, die was fixen können, was deployen können. und Und wenn es ganz schlimm kommt, müssen wir halt anfangen, irgendwelche Entwickler aufzuwecken, um Probleme zu lösen.

Joel Kaczmarek: Und sag mal, vielleicht jetzt letzter Satz dazu, bevor wir uns langsam mal den Herausforderungen widmen, die man bei emissionskritischer Software hat. Man hat ja gerne mal so dieses, fast so ein geflügeltes Wort schon, dass SAP halt so unfassbar komplex ist, dass sich so viele Kunden auch daran verheben. Also ich erinnere mich noch damals an die Lidl-Story-Serie. Die irgendwie erzählt haben, dass sie sehr viel daran werkeln. Das, was du da machst jetzt mit dieser Plattform, hilft es das sozusagen zu verbessern? Geht das genau in diese Scharte rein? Weil ihr werdet ja wahrscheinlich die gleichen Probleme haben, dass diese Vielzahl an Kunden, die ihr habt, von Stahl über Medizin über was weiß ich nicht was noch, dass die auch alle teilweise wahrscheinlich auf ganz unterschiedlichen Niveaus der Software aktiv sind. Also was dem einen ein wichtiges Feature ist, ist für den anderen vielleicht gar nicht so relevant.

Jan Schaffner: Also eigentlich ist die BTP eine Vereinfachungsstory. Wir haben jetzt natürlich viele Firmen akquiriert, auch im Verlauf der letzten 15 Jahre. Da ist die Situation die, dass eigentlich alle diese Produkte gekommen sind mit einem Erweiterungskonzept. Jetzt fokussieren wir jetzt natürlich strategisch darauf, dass ein SAP-Kunde möglichst mehr als eine Lösung der SAP benutzen soll. Die sollen möglichst gut integriert miteinander funktionieren, aber auch die Mechanismen, die ich brauche, um den Geschäftsprozess jetzt so zu verändern, dass eben diese verschiedenen SAP-Lösungen ineinandergreifen, standardisieren wir eben jetzt auf dieser Plattform, anstatt dass ich dann vielleicht mit einem Partner zusammenarbeiten muss. Und ich habe einen Partner, der ist Experte für SuccessFactors und ein anderer ist ein Experte für S4HANA oder S4HANA. Oder wie auch immer, sondern dass ich das harmonisieren kann. Also ich kann als Kunde in der IT auch so eine Art Center of Excellence aufbauen, wie ich so eine Anwendung auf die BTP bekomme, wie die mit SAP-Systemen interagiert. Und das vereinfachen wir dann, um den Zugang herzustellen zu den verschiedenen Lösungen.

Joel Kaczmarek: Gut, verstanden. Dann Herausforderungen, weil wir wollen ja wie gesagt so ableitbares Wissen bauen, hast du ja eigentlich gerade schon gesagt, das ist glaube ich auch naheliegend, also ein Thema natürlich Stabilität und das andere Thema Sicherheit, wären mal so die ersten, die mir einfallen. Björn, beschreib doch mal so deinen Blick drauf, was sind so die wichtigsten Herausforderungen? und vielleicht kannst du ja die, die ich schon mal genannt habe, auch nochmal so ein bisschen blumig sozusagen untermalen. Gerne.

Björn Wagner: Also für mich ist Priorität eins ganz klar Sicherheit. Wir agieren ja mit hochkritischen Kundendaten, dass man die quasi sicher hält und dort auch, sage ich mal, mehrere Level, mehrere Linien an Sicherheit wirklich in den System, auch im System Design einzieht, ist super kritisch oder super wichtig an Herausforderungen für alle Services. Stabilität geht es natürlich zum einen um Verfügbarkeit, aber zum anderen natürlich auch um so etwas wie Performance, das heißt Garantien, wie schnell bestimmte Anfragen von den Services beantwortet oder verarbeitet werden können, damit dann halt, wie vorhin schon gesagt, die Services, die davon abhängen, halt auch entsprechend basierend auf diesen Garantien ihre anderen Dienste entsprechend zur Verfügung stellen können. Aber wirklich so Sicherheit, wie halten wir die Kundendaten sicher, hat oberste Priorität. und dann wie stellen wir sicher, dass die Services verfügbar sind, dass sie auch natürlich ausfallsicher sind, das heißt es geht immer mal was schief und dass man dann auch vorbereitet ist, dass die Herausforderung auf verschiedene Auswahlszenarien immer einen Plan B, C oder D zu haben sozusagen, mit dem man dann trotzdem noch eine gewisse Stabilität oder Verfügbarkeit der Services sicherstellen kann.

Joel Kaczmarek: Haben wir was Wichtiges vergessen?

Jan Schaffner: Vielleicht kann man noch sagen, bei dem Thema Security haben wir natürlich auch viele Einflüsse von außen. Also wir verwenden natürlich wahnsinnig viel Open-Source-Software under the hood, wie wahrscheinlich die allermeisten Leute, die sich professionell mit Softwareentwicklung beschäftigen. Und da muss man schon ein Auge drauf haben, was da so passiert. Also Zum prominentes Beispiel, vor ein paar Jahren hatten wir kurz vor Weihnachten diese Lock4J-Situation. Ich weiß nicht, ob ihr das schon mal gehört habt.

Joel Kaczmarek: Ich nicht, Björn nickt.

Jan Schaffner: Im Prinzip muss man es sich so vorstellen, Open-Source-Software, die jeder verwendet, kann Sicherheitslücken haben. Wie die da reinkommen, ist ganz unterschiedlich von irgendwelchen Insidern in diesen Projekten, die irgendwelche Backdoors versuchen zu platzieren. Es können sich aber auch einfach Fehler einschleichen und diese Schwachstellen werden dann ausgenutzt. Also es gibt da schon eine große Community von Leuten, Die halt sieht, oh, hier ist eine neue Schwachstelle veröffentlicht worden. Jetzt versuchen wir doch mal, ob wir an öffentlich bekannten Endpunkten in große Softwareunternehmen reinkommen, an die Produkte rankommen, wie weit wir kommen. Und da muss man so ein bisschen versuchen, ja, entweder vor der Kurve zu sein oder wenn man es gleichzeitig mit allen anderen erfährt, sich so aufstellen, dass man sehr schnell diese Lücken auch wieder schließen kann.

Joel Kaczmarek: Bist du da überhaupt in einem Driverseat? Also ich meine, wenn es Open Source ist, ist es ja gar nicht immer in deinem vollen Zugriff sozusagen. Oder kannst du bei dir lokal Dinge ändern und bist dann auf der sicheren Seite?

Jan Schaffner: Du bist erstmal reaktiv. Die Frage ist aber, man kann versuchen, sich zu vernetzen, sage ich jetzt mal, und vor der Veröffentlichung von bestimmten Themen ein Heads-up zu bekommen. Allerdings, was man auf jeden Fall tun muss, ist schnell reagieren. Also meistens gibt es dann irgendeine neue Version von der Library, um die es geht. Und dann ist es auch eine Frage, was hat man für Möglichkeiten schnell neu zu paketieren, schnell eine neue Version zu deployen. Also dieses Log4J, das kam glaube ich an einem Freitagabend vor Weihnachten so gegen 21 Uhr oder sowas. Also es sind halt auch immer gerne so Situationen, wo nicht mehr all hands on deck sind. Hast aber dann ein kurzes Fenster, wo man schauen muss, was haben wir denn jetzt hier überhaupt für ein Risiko, wie exposed sind wir oder auch nicht, was können wir machen, das muss man irgendwie üben.

Joel Kaczmarek: Also Challenges verstanden sind ja auch irgendwie jetzt nicht so super komplex, sondern sehr naheliegend. und dann wollen wir natürlich jetzt mal ein paar Lösungen verstehen, worauf es quasi ankommt, was man im Griff haben sollte. Björn, was sagst du denn, was ist denn so? die erste Baustelle, die man sich da angucken sollte?

Björn Wagner: Vielleicht ist mal die Übersicht zu geben. Es gibt eigentlich so drei Hauptaspekte, mit denen man sich immer auseinandersetzen muss. Zum einen natürlich Technologie, dann People, das heißt Leute, welche Rollen braucht man etc. Und der dritte Punkt ist dann Prozesse, das heißt wie verbindet man alles miteinander. Der Jan hat ja vorhin schon gesagt, man muss im schlimmsten Fall oder in besonderen Eskalationen auch mal Entwickler aufwecken und dann müssen die Prozesse halt schon so optimiert sein, dass wenn man quasi fünf Minuten nach dem Aufstehen dann halt auch die richtigen Sachen im System tut und halt ohne viel nachdenken oder mit drei anderen Leuten zu sprechen, halt genau weiß, welche Schritte jetzt halt wichtig sind, um das Problem möglichst schnell zu lösen. Und da kommt halt dann genau alles zusammen. Man braucht ein gutes Technologie-Monitoring, Die Leute, die richtigen Rollen, die richtigen Verantwortlichkeiten und halt auch die richtigen Prozesse. Und da können wir uns vielleicht mal so ein bisschen in die drei Bereiche eintauchen.

Joel Kaczmarek: Jetzt gerade so vor Augen, wie Jan immer Weihnachten so die Leute vom Gänsebraten essen, irgendwie wegholen. Okay, ja gut, verstanden. Dann lass uns doch mal mit dem ersten Baustein anfangen. Also Tech, was ist da so das Wichtigste, würdest du sagen, worauf ihr schaut, Jan?

Jan Schaffner: Also bei Tech würde ich sagen, was können wir in der Software machen, um Risiken zu minimieren? Vielleicht ein Beispiel zum Thema Security. Wir versuchen so ein Mindset zu leben, dass wir davon ausgehen, wir sind im Prinzip gebreached, wenn das so wäre, wie müssen wir eine Software-Architektur machen. Und das heißt also auch alle Komponenten so im inneren Kern eines Systems hinter der Firewall, wenn die miteinander sprechen, die reden komplett verschlüsselt, Die Zertifikate, die sie dafür benutzen, werden sehr hochfrequent rotiert, um die Verschlüsselung zu erneuern. Das machen wir automatisch und solche Systeme implementieren wir eben dann, wie wir so Subtografie automatisch erneuern können, um eben sichere Kommunikation zu gewährleisten. Auf der Stability-Seite sind es so Themen wie Hochverfügbarkeit, Also das heißt, wie schütze ich mich davor, dass ein Datacenter abbrennt, was schon passiert ist. Also auch bei Amazon oder so passiert sowas. Wie gehen wir damit um? Sind wir in der Lage, den Workload, ohne dass der Nutzer im Endeffekt was davon merkt, vielleicht sogar in eine andere Availability-Zone rüberzuschmeißen? Und wie können wir vielleicht automatisch feststellen, dass so ein Failover jetzt aktiviert werden muss, weil es vielleicht mitten in der Nacht passiert oder so. Das sind alles Sachen, die kann man technisch bauen.

Joel Kaczmarek: Wie ist es sonst mit so etwas wie Monitoring?

Björn Wagner: Genau, also ein Thema ist halt Monitoring oder auch häufig Observability genannt. Das heißt, man muss halt sehr im Detail verstehen, wie gesund ist das System oder wie läuft es gerade und dort halt möglichst viel Transparenz haben, um halt dann auch schnell zu erkennen, wenn halt Probleme aufkommen. Man hat ja häufig heute, viele Beispiele sind im DevOps-Bereich, wo man sagt, Best Practice ist ja möglichst häufig zu deployen mit Hilfe von Continuous Integration und Continuous Delivery Pipelines. Und wenn man natürlich sehr häufig deployt, entsteht die Möglichkeit, sehr häufig Fehler in die Systeme zu bringen. Und deshalb muss man diese Fehler möglichst schnell automatisiert feststellen. Dort gibt es dann Metriken mit bestimmten, sage ich mal, Grenzwerten. Wenn die überschritten sind, dann werden halt, wie gesagt, je nach Wichtigkeit dann Automatismen bis hin zu automatisierten Telefonanrufen, die dann gewisse Leute aufwecken, getriggert. Und das ist halt wichtig. Und auch, also quasi wo wir versuchen, die Teams hinzuentwickeln. Man hat ja klassisch im agilen Bereich dieses Stand-up, dass die Teams jeden Morgen quasi nicht nur darüber sprechen, was machen sie, was ist der Fokus, sondern halt auch auf die Metriken schauen. Wie laufen die Services gerade? Gab es gestern oder über Nacht neue Fehler, die aufgetreten sind, die wir noch nicht gesehen haben? Und dass sich die dann halt auch mit Priorität angeschaut werden. Dafür brauchen wir halt sehr, sehr gutes Monitoring an der Stelle.

Joel Kaczmarek: Aber helft mir mal, wie macht man das denn bei Software? Weil ich erinnere mich noch, ich war auch in Potsdam da, aus dem HPI gibt es ja auch eine Ausgründung, die sich damit beschäftigt, wie man quasi Software visualisieren kann, um zu sehen. Das ist ja wirklich wie so Stadtmodell.

Jan Schaffner: Serene, ne?

Joel Kaczmarek: Ja, genau. Ich habe gedacht, ich mache jetzt hier keine schamlose Werbung, aber es war eigentlich recht. Ich habe sogar mal da gearbeitet. Und da war genau dieser Case immer, dass sie halt gesagt haben, du guck mal, das ist halt mit Software so, wenn du jetzt irgendwie ein Versicherer bist, dann ist deine Software, wenn du sie ausdrucken würdest, die Blätter übereinander stapeln, das Papier, so hoch wie ein 23-stöckiges Haus. So, finde da drin mal halt irgendwie eine Problemlage. Und ich fand es da mal so ganz eindrücklich, weil die haben so 3D-Modelle gebaut. von der Software, sah wirklich aus wie so eine Gebäudestadt und wenn dann ein Haus halt sehr schmal und sehr rot war, dann weißt du, okay, da gucke ich rein, so. Aber ihr seid ja da wirklich so quasi im Epizentrum der Komplexität. Wie kriegt ihr es denn hin, dass ihr Technologie quasi auf eine Art greifbar macht, dass ihr diese ganzen Themen wie Stabilität, Sicherheit überhaupt monitoren könnt, dass ihr sofort wisst, wo muss ich denn eingreifen? Es ist ja sowas von dezentral groß und komplex.

Jan Schaffner: Also wir haben irgendeine vierstellige Anzahl von Monitoren, glaube ich, in unserer produktiven Landschaft. Und da kommt natürlich viel zusammen. Also meistens sind es so Metriken wie Requests pro Minute, wie schnell kommt eine Datenbankanfrage im Durchschnitt zurück. Ein Haufen Zeug. Wie schnell kann ich auch irgendeine Festplatte schreiben? Also das guckt man sich an und die Frage ist immer, gibt es irgendeine Trendänderung, die ich erkennen kann? Es gibt auch manchmal falsch positive Signale. Und im Endeffekt haben wir deswegen ja auch diesen ersten Layer of Defense, wo Leute im Prinzip auch auf so ein Monitor draufschauen und dann entscheiden, muss ich hier eine Investigation starten, was da los sein könnte? Muss ich vielleicht versuchen, ein paar Experten in Call zu bekommen? Oder ist es was, was ich laufen lassen kann bis morgen früh?

Joel Kaczmarek: Und sag mal, wenn wir jetzt über Technologie reden, meinst du dann eigentlich wirklich immer nur Software oder spielt die Hardware manchmal auch eine Rolle? Weil so wie du gerade beschrieben hast, hier irgendwie das Datenzentrum fackelt ab oder die Festplatte kann nicht beschrieben werden. Das sind ja wirklich sehr haptische, physikalische Vorgänge, richtig? Ist das was, was ihr auch quasi mit betrachtet?

Jan Schaffner: Teilweise schon. Also wenn der Fehlergrund ist, Festplatte voll, das ist sehr, sehr peinlich. Und deswegen, also gerade in dem Teil der Plattform, die in SAP Rechenzentren läuft, ist das natürlich eine Sache, die wir sehr, sehr Ja, da kann es auch sein, dass ein Auftrag aufgelöst wird, dass irgendeiner da hingeht und irgendwo eine neue Festplatte reinsteckt. Aber auch in WMs von Hyperscalern hat man natürlich die Situation, dass man sich anschauen muss, wie viele Ressourcen habe ich bestellt, wie viel nutze ich und ein bisschen antizipiert, was da passiert. Absolut, ja.

Joel Kaczmarek: Gut. So, also du hast ja gesagt, dreiteilige Matrix, erste Matrix durchgearbeitet, Tech. Zweite wäre People. Also das ist wahrscheinlich so eine Rollen- und Organisationsaufbaugeschichte, ne?

Björn Wagner: Und in den, sag ich mal, nachgelagerten Rollen, wenn die quasi in den ersten Layern nicht gelöst werden können, gibt es dann mehr, sag ich mal, Experten, die sich dem Problem annehmen können. Vereinfacht gesagt, die werden häufig im Englischen Site Reliability Engineers genannt oder SRE, S-R-E kurz, die sich dann genau Um diese Themen kümmern und natürlich auch, wie gesagt, wieder basierend natürlich auf so DevOps-Prinzipien, you build it, you run it häufig. Als letzte Instanz werden auch dann teilweise in bestimmten Problemsituationen Entwickler der jeweiligen Teams hinzugezogen.

Joel Kaczmarek: Was genau stelle ich mir unter diesen SREs vor, diesen Site Reliability Engineers?

Jan Schaffner: Ja, das sind im Prinzip Softwareentwickler, die arbeiten auch mit den Kollegen, die nur Software Development machen, zusammen. Aber es geht auch wieder um Skaleneffekte. Ich versuche es mal zu erklären. Wir haben einen Service, nehmen wir zum Beispiel diese Audit Logging Capability. Da gibt es ein Entwicklungsteam und es gibt aber auch ein paar Projekte, Site Reliability Engineers, die jetzt gepaart sind mit diesem Audit Log Service. Und was die machen ist, die arbeiten zusammen mit dem Development Team an dem Backlog für diesen Service, aber mit einem speziellen Fokus auf Reliability. Das bedeutet, Follow-Ups aus vorherigen Incidents werden abgearbeitet, alles was so Automatisierung betrifft. Optimierung von Security-Themen angeht, das würden die machen und würden einfach normal mitarbeiten. Aber die bauen jetzt nicht das nächste Shiny-Feature für diesen Service. Dafür machen die aber pro SAE vielleicht zwei, drei, manchmal vier Services, die die betreuen, wo die so ein bisschen mitarbeiten. Dann haben wir die Situation, dass wir so ein 24x7-Programm On-Call-Schedule haben für jeden Service, für den Fall, dass was passiert. Und das wird aufgeteilt zwischen den SAEs und dem Entwicklungsteam. Also so, dass so ein Entwickler auch vielleicht alle sechs bis 18 Wochen mal so ein Wochenende hat, wo er da partizipieren muss, damit er ausreichend incentiviert ist, um die richtigen Schwerpunkte auch in seiner täglichen Arbeit zu legen. Aber damit die halt auch mal durchatmen können und jetzt vielleicht nicht permanent so einen On-Call-Dienst machen müssen, werden die eben ergänzt von so einem SAE-Team, die aber über mehrere Services skalieren, in drei Regionen um den Globus herum aufgestellt sind, sodass wir da mit wenigen Leuten möglichst viele Services absichern können.

Joel Kaczmarek: Trainiert ihr die Leute eigentlich darauf? Also schult ihr die? Weil da musst du ja wirklich ein Rädchen ins nächste greifen bei solchen Geschichten.

Jan Schaffner: Wir machen zum Beispiel sowas, das heißt Chaos-Testing. Da stellen wir Szenarien auf, wo jemand absichtlich Dinge kaputt macht und dann wird halt geschaut, wie lange dauert es, bis das Problem gelöst ist. Und das kann man in Testlandschaften machen. Wir machen das gerne in Landschaften, wo nur SAP-interne Entwicklung stattfindet. Manchmal trauen wir uns auch, dass wir uns mal wirklich produktive Landschaften für sowas hernehmen. Aber ja, das wird regelmäßig trainiert.

Joel Kaczmarek: Ja, das könnte ich auch. Sachen kaputt machen so auf Befehl, das kriege ich in den Rest nicht. Ja, aber okay, krass. Und habt ihr auch so bestimmte Rollenprofile, die ihr dann bei euch braucht? Oder ist das sozusagen ganz normal, was am Markt verfügbar ist? Oder braucht es bei euch, sage ich mal, wenn ich sowas betreibe, nochmal ein Level drauf?

Jan Schaffner: Naja, also vom Jobprofil her, das Wort DevOps Engineer schwirrt da auch irgendwie rum. Am Ende des Tages sind es Softwareentwickler, aber mit einem speziellen Fokus darauf, Dinge zu automatisieren, also auch Software zu schreiben, die das Softwareentwickeln, Deployen selber beschleunigt, um uns in eine Lage zu versetzen, eben schnell reagieren zu können.

Joel Kaczmarek: Gut, also auch durch im Wesentlichen. Erste Ebene Technology, zweite Ebene People und dann an People dockt ja die dritte eigentlich fast an mit den Prozessen. Also das, was ihr gerade auch beschrieben habt mit diesem 24-7-On-Call-Schedule. Wie denkt ihr denn Prozesse in so einem Kontext an?

Björn Wagner: Also vielleicht mal angefangen, wenn wir über Incidents reden. Denken wir meistens in drei Phasen. Also sobald der Fehler, das Problem aufgetreten ist, ist die Phase 1 der Fokus darauf zu verstehen, was ist der Root Cause, also was ist der wirkliche Grund dahinter und den möglichst schnell quasi abzustellen. Also das Problem für den Kunden abzustellen. Zu beheben und am Ende dann auch entsprechend zu kommunizieren natürlich. Ganz wichtig in der Phase ist auch, was zumindest auf unserer Seite von Kunden immer wertgeschätzt wird, ist auch möglichst proaktive Kommunikation. Also die Kunden möchten lieber erfahren, dass es ein Problem gibt und quasi über den Fortschritt unterrichtet werden, als dass quasi Kommunikation oder so komplett ausbleibt. Also das ist irgendwie wichtig in der ersten Phase. Phase 2 ist dann, dass man sich anschaut und sowas wie eine Retrospektive oder Postmorte macht. Das heißt, wenn man genau versteht, warum ist das jetzt eigentlich passiert und wie können wir das in der Zukunft wirklich verbessern. Und dass man sich dann auch anschaut, es gibt verschiedene Ebenen, was können wir vielleicht im Code ändern, was können wir an Qualitätsmaßnahmen ändern, was kann auch am Monitoring, vielleicht brauchen wir bessere neue Monitoringmaßnahmen, was können wir dort verbessern. Oder was können wir auch in Abläufen, Prozessen oder Rollen verbessern? Dass man sich das wirklich einmal anschaut, was können wir daraus lernen? Und daraus entstehen dann ein paar Änderungen, Action-Items, die man halt umsetzen muss. Und das ist dann quasi Phase 3, dass man dann auch sicherstellt und nachhält, nicht nach dem Motto aus dem Augen, aus dem Sinn, sondern sagt, okay, es gab jetzt hier ein Problem, wir haben das möglichst schnell gelöst. Das sind die Erfahrungen, die wir daraus gesammelt haben und das sind jetzt die Verbesserungen, die wir umsetzen. Und damit kommt man in diesen Zyklus rein, dass man eigentlich permanent, lernt als Organisation und die Prozesse, Abläufe, Technologie und auch die Leute am Ende verbessert. und das ist glaube ich so der Kern der Sache. und natürlich gibt es dann im Detail noch viel mehr Prozesse, wo dann, wie ich schon mal gesagt habe, wenn man jemanden nachts um drei aufweckt, wo dann ziemlich genau beschrieben sein sollte, was jetzt die konkreten Schritte sind zur Fehlerbehebung.

Joel Kaczmarek: Wie läuft sowas ab? Habt ihr da irgendwie so eine Art Kommunikationsguide, der drei Uhr morgens, ich kann kaum aus den Augen schauen, so erkläre ich dir ein Problem, was hochkomplex ist, Guide? Oder wie möchte ich mir das vorstellen?

Jan Schaffner: Ja, also wie gesagt, wir haben so einen ersten Layer. Wir haben Playbooks für jeden Service, wo … für bestimmte Szenarien Recommended Actions drinstehen. Also, have you tried switching it off and on again? Und dann wissen die Leute im Prinzip, wenn sie irgendwo nicht weiterkommen, kann ich es ins nächste Level eskalieren und die Leute sind dann halt irgendwie mit dem Service schon ein bisschen zugange, um den es geht, können sich orientieren und finden dann auch einen Weg.

Joel Kaczmarek: Und sag mal, diese Kommunikation, die in all diesen Prozessen stattfindet, weil du eben auch gesagt hast, so ein Kunde will informiert werden. Gibt es so einen Ablauf? Erst intern, dann extern? Oder ist es immer parallel, dass man sagt, okay, erst mal intern das Problem verstehen, aber gleichzeitig geht eine Unit schon hin und informiert auch den Kunden, der vielleicht betroffen sein könnte?

Jan Schaffner: Das gleichzeitig. Also in so einem Incident-Management-Prozess haben wir eine Rolle für Kundenkommunikationen. Und da gibt es auch KPIs, Time to Inform Customer und so. Also da messen wir uns auch daran, wie schnell wir es schaffen, einen Kunden zu informieren. Was auch nicht einfach ist, weil man will nicht überkommunizieren. Ist ja auch relativ unsettling vielleicht jemandem zu sagen, oh, dein Mission Critical Prozess ist gerade gefährdet oder so. Wenn es nicht sein muss, will man das auch nicht machen, aber man will auch möglichst ehrlich sein. Also Da versuchen wir den richtigen Weg immer zu finden. Aber das ist tatsächlich dann auch so, dass wir die Leute, die das Problem in dem Moment lösen, so ein bisschen in so einen geschützten Raum bringen. Da kann jetzt auch nicht ständig alle zwei Minuten irgendjemand Neues in so einen Call kommen und sagen, ich bin der So und So, gib mir mal ein Update, was da los ist. Sondern die werden im Prinzip abgefangen von jemand, der sich ein Bild verschafft, wo steht jetzt das Team und dann kommuniziert.

Joel Kaczmarek: Was sind dann so typische Sicherheitsprozesse, die in dem ganzen Zyklus, sage ich mal, besonders wichtig sind? Gibt es da so eine Art wiederkehrende Elemente? So was, was Björn eben auch beschrieben hat mit diesen Postmortems zum Beispiel. Das ist ja jetzt eher was, was sozusagen was nachgelagert kommt, aber Gibt es so eine Art Ablaufplan, wie bei so einem Piloten, der sein Flugzeug irgendwie mal durchcheckt und Sachen beachten muss?

Jan Schaffner: Im Prinzip schon, ja. Also diese grundsätzlichen Abläufe haben wir dokumentiert. Da gibt es Wikis für verschiedene Abläufe und das wird bis hin zum Template für die Kundenkommunikation im Prinzip so unkreativ wie möglich wiederholbar gemacht.

Joel Kaczmarek: So, und wenn wir jetzt mal diese drei Bereiche nochmal ganz kurz anschauen, also Technologie, People, Prozesse, wie viel davon ist eigentlich reaktiv und wie viel ist vielleicht auch proaktiv?

Jan Schaffner: Was wir bisher besprochen haben, war eigentlich reaktiv. Was wir proaktiv machen, ist, wir gucken uns an, am Ende des Tages in der Entwicklung haben wir so und so viel Kapazität, um an einem Backlog zu arbeiten, in Personentagen ausgedrückt. und jetzt Sagen wir, wir setzen uns in so einem rollierenden 3-Monate-Intervall Ziele, die spezifisch sind für Reliability und Security. Und wo es Sinn machen würde, wenn wir die harmonisiert in alle Services reinbringen. Also zum Beispiel, wie wir mit so einem Brand in einem Rechenzentrum umgehen oder dieses Multi-Availability-Zone, Failover-Thema angehen. Das war so eins, wie wir das angegangen haben. Und dann sagen wir, okay, das ist ein Thema, das ist uns jetzt wichtig. Und wir nehmen eine bestimmte Kapazität aus allen Backlogs weg und hängen diese Themen dann da vorne dran. Aber auch nur bis zu einem gewissen Grad, dass wir auch noch atmen können, um Features zu implementieren. Aber wir sagen halt, basierend auf den Erfahrungen, die wir vielleicht kürzlich gemacht haben oder was wir neu gelernt haben, wo wir denken, wir können uns verbessern, reservieren wir eben Backlog, um uns da kontinuierlich weiterzuentwickeln.

Joel Kaczmarek: Habt ihr so eine Faustformel, dass ihr sagt, so und so viel Prozent unserer Entwickleraufmerksamkeit gehen in Improvements und so und so viel Prozent in Betrieb und so und so viel irgendwie sind für Feuerwehreinsätze reserviert?

Jan Schaffner: Das kommt ein bisschen auf den Service an, aber wir haben, ich würde sagen, zwischen 50 und 80 Prozent der Entwicklerkapazität fokussiert auf Keep the lights on, wie wir das nennen.

Joel Kaczmarek: Ja. Ansonsten ist es ja ein bisschen wie eigentlich in der Wirtschaft auch, dass ihr euch wahrscheinlich über Investments Gedanken machen müsst. Wie priorisiert ihr? Also was ihr sagt, wo ihr in Neuerungen vielleicht auch investiert und wo nicht?

Jan Schaffner: Meinst du jetzt für Security-Themen, für Stabilität oder generell, wie wir das Backlog managen?

Joel Kaczmarek: Vielleicht ein bisschen beides.

Jan Schaffner: Ja, wir haben jetzt gerade die Situation, dass wir zum Beispiel ein starkes Wachstum haben. Wir sind im Moment mit einem Teil der Plattform, den wir Multicloud nennen, auf ein paarundzwanzig Datacentern und wir verdoppeln die Anzahl der Regionen jetzt dieses Jahr auf vierzig. Da wird natürlich auch mehr Last kommen, mehr Wachstum, mehr Kunden, die es nutzen. Das heißt, wir müssen uns jetzt überlegen, was müssen wir denn tun, um das Wachstum zu unterstützen. Weil rein statistisch wird es mehr Probleme geben, mehr volle Festplatten, sodass wir vielleicht auch darüber nachdenken müssen, Haben wir jetzt die Infrastruktur, um vielleicht zwei Situationen gleichzeitig zu managen? Müssen wir die Prozesse da anpassen? Müssen wir da investieren? Das sind Sachen, die uns gerade umtreiben, wie wir von der Skalierung nochmal weitergehen können.

Joel Kaczmarek: Und ich meine, apropos Skalierung, wenn man jetzt wie du eine Plattform baut und du ja auch gesagt hast, es geht um Effizienz, ist das Wachstum, was dadurch möglich wird, immer linear oder auch mal exponentiell? Also könnt ihr deutlich schneller mit sowas wachsen oder ist das relativ klar sichtbar?

Jan Schaffner: Also auf SAP-Gesamtebene ist es ein relativ klarer Case. Björn hat ja auch gesagt, sogar Signavio, die noch relativ neu sind in der Firma und sagen wir mal, relativ viele Dinge auch nach ihrem eigenen Gusto auch noch tun, machen aber schon viel mit uns, weil sie da auch einen Benefit bekommen. Aus Sicht desjenigen, der die Plattform bereitstellt, passen natürlich sehr viele Anforderungen auf dich ein, ja. Wir wollen aber auch nicht, wenn wir wachsen, linear wachsen, sondern eher logarithmisch. Wir haben natürlich schon eine Infrastruktur, um mit bestimmten Situationen umzugehen. Die muss mitwachsen mit den Nutzern, wie zum Beispiel Signavio, aber eigentlich langsamer, sodass der Effizienzgewinn mit größerer Skalierung eben auch größer wird.

Björn Wagner: Also eine Sache, um auf das Thema Proaktivität auch zurückzukommen, was du ja angesprochen hattest. Eine Sache, die wir auf jeden Fall sehr schnell nach der Akquise von SAP mitgenommen haben, sind so auch mehr proaktive Themen zu machen. Zum Beispiel gibt es das Konzept, wir haben Security Engineers, ich glaube so fast in jedem Team. Das sind Softwareentwickler, die nochmal eine spezielle Ausbildung haben, explizit auf das Thema Sicherheit. Das heißt, bevor wir auch einen neuen Service überhaupt quasi mit dem live gehen können, Es gibt da bestimmte Checklisten, die abgearbeitet werden. Da gibt es sowas wie ein Threat Modeling, wo wirklich die Entwickler aktiv da sitzen und sich Gedanken machen nach einem bestimmten Framework, welche Risiken, welche Bedrohungen gibt es denn jetzt für den Service und wie kann man die mitigieren. Und dann kommen da wieder Action-Items raus, das wird dann nachgehalten und so weiter. Also da geht man schon sehr, sehr strukturiert voran. Um diese Sachen zu machen. Ein anderes Thema war Chaos-Testing, was wir auch regelmäßig machen und auch durch verschiedene Zertifizierungen sogar verpflichtet sind zu machen. Das ist auch sowas wie Disaster-Recovery. Wir haben gesagt, das Datacenter brennt ab, aber dass man auch mal testet und durchspielt, wie funktionieren denn diese Playbooks jetzt in einer Sandbox-Umgebung, wie gut können wir denn den Service wiederherstellen. Dass die Leute so ein bisschen da auch reinkommen. Ich sag mal so, vielleicht im Vergleich, so wie ein Pilot im Flugsimulator auch mal irgendwie kritische Situationen übt, dass wir das halt auch sehr, sehr, sehr ähnlich und sehr, sehr strukturiert machen. Und da wird dann auch viel in diese Proaktivität eininvestiert, dass man halt nicht nur schaut quasi retrospektiv, was ist irgendwie schiefgegangen und was können wir verbessern. Also das ist beides sehr, sehr wichtig.

Joel Kaczmarek: Ich kann mir das total vorstellen. Bei meiner letzten Firma musste ich teilweise Sachen unterschreiben, wie wir handeln, wenn ein Erdbeben ist und so, weil wir waren hier, hier ist das TÜV zertifiziert. Und dann, wenn du irgendwelche ISO-Normen erfüllen darfst, das ist ja durchaus nicht ohne. Von daher, ich glaube, man hat mal ein Feeling gekriegt, was bei euch Mission Critical heißt, mit Betonung auf Critical. Haben wir noch was vergessen, Björn?

Björn Wagner: Von meiner Seite sind wir soweit durch, glaube ich.

Joel Kaczmarek: Na guck mal, obwohl ich hier der Laie bin bei euch Tech-Brains, dann freue ich mich ja, dass wir hier so die wichtigsten Sachen drin hatten. Vielleicht hast du noch so einen Ausblick, Jan? Was glaubst du, wie sich das für euch noch so entwickeln wird? Man sagt ja immer, man überschätzt, was man in zehn Jahren leisten kann, man unterschätzt aber, was man in fünf Jahren leisten kann. Was ist so dein Fünf-Jahres-Plan für eure Plattform?

Jan Schaffner: Das ist interessant. Den kannte ich noch nicht, dass man fünf Jahre unterschätzt, dabei zehn Jahre überschätzt. Also in fünf Jahren, wo wollen wir sein mit der Plattform? Die Ambition ist sicher noch stärker, die verschiedenen SAP-Produkte über die Plattform zu harmonisieren und ineinandergreifen zu lassen. Und letztendlich Themen wie vielleicht Erweiterung von großen SAP-Systemen wie S4HANA dann auch wirklich vollends über die Plattform zu treiben. Im Moment haben wir noch relativ viel Action mit Partnern, die wirklich Up-Up-Modifikationen machen von diesen Systemen, haben wir auch im Vorgespräch besprochen. Dass wir da einfach unser Wertversprechen noch stärker zeigen und da mehr Adoption bekommen in die Richtung. Obwohl wir es natürlich schon stark in die Richtung gehen. Also wir haben jetzt so 23.000 Kunden auf der Plattform. Das sind ja fast schon alle SAP-Kunden. Also von daher weiß ich nicht, was ein gutes Fünfjahresziel ist. Ich glaube, wir müssen dann eher darüber sehen, was ist die Tiefe, in der diese Kunden mit der Plattform arbeiten. Und da haben wir bestimmt noch Luft. Soweit vielleicht erst mal.

Joel Kaczmarek: Ja, super. Dann euch beiden ganz, ganz herzlichen Dank. Also wieder einiges gelernt heute. Und ich drücke weiter in die Daumen, dass du nicht so viele Leute hier nachts um drei oder vom Gänsebraten an Weihnachten wegholen musst. Vielen, vielen Dank.

Björn Wagner: Danke dir.

Jan Schaffner: Tschüss.