#44 Warum 90% der CTOs nicht souverän sind und es nicht mal merken - mit Alexander van der Steeg

In dieser Folge von Becoming CTO Secrets spricht Philipp Deutscher mit Alexander van der Steeg, Unternehmer und CTO von EntekSystems, über ein Thema, das viele unterschätzen – digitale Souveränität.

Alexander verfolgt einen radikal anderen Ansatz als viele moderne Tech-Organisationen: Statt auf maximale Geschwindigkeit durch Cloud und externe Services zu setzen, baut sein Team bewusst große Teile der Infrastruktur selbst. Das Ziel: maximale Kontrolle, Unabhängigkeit und langfristige Stabilität.

Gemeinsam diskutieren sie, warum digitale Souveränität weit mehr ist als ein Buzzword, welche Risiken Unternehmen heute unterschätzen und weshalb Open Source nicht automatisch die bessere Wahl ist.

Darüber hinaus geht es um die Realität moderner CTOs: steigende Komplexität durch AI, den Umgang mit Legacy-Systemen und die Herausforderung, gleichzeitig Stabilität, Innovation und Geschwindigkeit zu balancieren.

Eine Episode für alle, die Technologie nicht nur effizient betreiben, sondern strategisch verstehen wollen.

Transcript

SPEAKER_00 0:01

Hallo und herzlich willkommen zu Becoming CTO Secrets, eurem Lieblingspodcast rund um die CTO-Rolle. Ich wiederhole es jedes Mal aufs Neue. Ich bin Philipp Deutscher, externer CTO, CTO-Coach und auch der Gründer der Becoming CTO Community. Heute zu Gast. Einige von euch kennen ihn vielleicht schon, er war nämlich früher schon mal zu Gast bei uns, ist Alexander van Dersteg. Er ist Unternehmer, CTO von NTEC Systems und wo er mit einem bewusst kleinen, hochfokussierten Team skalierbarer Tech- und Consulting-Lösungen aufbaut. Darüber wollen wir mit ihm sprechen. Und sein Ansatz ist maximale Kontrolle über Technologie, über Prozesse und über Wertschöpfung. Bei der Einleitung verspreche ich mich auch jedes Mal, das ist wirklich peinlich. Mit einem klaren Fokus auf digitale Souveränität. Das ist ganz, ganz wichtig. Und dabei stellt er gängige Annahmen rund um Open Source Skalierung und moderne Tech-Stacks immer wieder bewusst in Frage. Alex, herzlich willkommen erneut bei uns hier im flauschicken Podcast.

SPEAKER_01 0:59

Hallo, freue mich dabei sein zu können und ich mein wir in einem der ersten dabei freue mich, dass es so erfolgreich läuft.

SPEAKER_00 1:04

Sehr schön. Ja, genau. Du hast ja auch mit dazu beigetragen. Ohne die ersten Folgen gäbe es, die ganz vielen Folgen danach gäbe es dann auch nicht. Du hast da kräftig mitgewirkt. Und bist natürlich auch sehr aktiv in der Community, muss man auch noch dazu sagen. Vielen Dank, vielen Dank. Du hast gesagt, Alex, ihr seid aktuell im Turbo-Modus unterwegs. Das ist so, was wir im Vorgespräch nochmal angeteasert hatten. Was hat sich denn genau in den letzten Monaten verändert bei N-Tech Systems und bei dir?

SPEAKER_01 1:32

Erstmal persönlich, natürlich neues Personal. Wir skalieren ja aufgrund unserer kleinen Größe relativ langsam. Das heißt, Personalauswahl ist ja immer ein riesiges Thema, aber da kommen neue Leute dazu. Also erstmal, plus eins ist für uns, wie vielleicht für andere, plus zehn. Dann natürlich, wir haben einen zweiten Rechenzentrumsstandort jetzt komplett angebunden, autonom. Wir hatten bisher immer nur einen primären in Frankfurt und haben das jetzt ausgerollt, sind jetzt global redundant dadurch. Und haben da verschiedenste Möglichkeiten, natürlich auch jetzt Szenerien zu testen und Notausfallthematiken. Gewisse Formen in dem Kritisbereich natürlich auch jetzt zu unterstützen und auch, wenn wir das wollen würden, auch Zertifikate und andere Punkte damit abzudecken. Was hat sich noch geändert? Es war der Januar und der Februar waren die besten Monate der Firmengeschichte, muss man auch sagen. Also das ist für uns umsatztechnisch ein Wahnsinn. Da bin ich auch offen gegenüber der Community, das ist wirklich Wahnsinn, was da abgegangen ist. Und was als Volk für das gesamte Team, für die Entscheidungen natürlich in diesem Rahmen dann auch gilt. Dazu ein bisschen auch Entscheidungen, wie wir unsere zukünftige Strategie einhergehen werden, das besprechen wir nachher. Wie wollen wir die Produkte bauen? Produkt, unser Primärprodukt, Inventory 360 jetzt in den nächsten Jahren. All das haben wir jetzt nochmal festgezurt und haben darüber technologische und operative Entscheidungen getroffen. Das war jetzt allein nur jetzt Abriss von grob Weihnachten bis jetzt. Darüber hinaus, darüber hinaus noch als Punkt, natürlich grober Punkt, wie wir uns auch als Marke darstellen wollen. Da bin ich ja als Role Model, deswegen bin ich ja auch hier, aber auch in anderen Bereichen unterwegs, haben wir auch Entscheidungen getroffen, damit N-Tech Systems als Unternehmen mit den Produkten später hoffentlich sehr viele Menschen schätzen und lieben lernen.

SPEAKER_00 3:24

Ach, das hast du schön gesagt. Kannst du uns mal eine Einschätzung geben? In welcher Größenordnung macht ihr denn aktuell Umsatz? Kannst du sowas teilen? Also, vor allem auch, wenn du sagst, ihr seid gerade sehr stark unterwegs. Was darf man sich darunter vorstellen?

SPEAKER_01 3:37

Ich hatte diese Frage intern gestellt, die Geschäftsführung selbst will das nicht. Das habe ich ganz offen gezeigt. Aber ich sag mal so, wir sind schon in mehreren Millionen Bereich auf jeden Fall unterwegs.

SPEAKER_00 3:47

Und er wächst auch gegen den Marktrend. Ich glaube, das kann man auch sagen. Was macht ihr denn anders als andere Tech-Unternehmen?

SPEAKER_01 3:55

Ich glaube, wir gehen den schweren Weg, fast nichts einzukaufen. Also häufig ist es ja so, du kennst es aus deiner eigenen Vergangenheit, kaufe ich mir Dinge, Convenience, ne? Also IT hat einen großen Convenience-Faktor, meiner Meinung nach. Also sprich, wenn ich sage, ich kaufe mir bei AWS was ein, bei Azure, bei GCP zum Beispiel oder bei anderen auch europäischen Cloud-Anbietern, kaufe ich mir Services und Cloud-Leistungen klassisch natürlich ein. Versus, dass wir selbst diese Leistungen bei uns erarbeiten, wie jetzt angesprochen, eigene RZ-Kapazitäten, eigene Services, eigene Dienste, die wir damit integrieren, dass wir das selber machen und damit vielleicht, das ist auch Kritik, die man da rausüben kann, zu einem Teil natürlich sagen kann, hier, diese Services, die müssen gebaut werden, das kostet Zeit, Geld und natürlich auch technologisches Wissen, versus wir verlieren ein bisschen an Geschwindigkeit. Das ist für uns das aktuelle Thema. Aber durch die technologische Eigenständigkeit sind wir, da kommen wir drauf gleich noch zurück, natürlich digital souverän. Wir sind in der Qualitätsdiskussion, wie sind die Services, wie können wir die Dinge angehen, wann gehen wir Dinge an, etc., vollkommen autark unterwegs. Und da sind wir sehr, sehr viel stärker. Tun auch da.

SPEAKER_00 5:12

Da möchte ich gerne noch ein bisschen reingehen, weil das ist, das wirkt auf mich erstmal counterintuitiv. Wenn man sagt, man ist ein kleines Team, dann ist ja eigentlich die folgerichtige Entscheidung, dass man Dinge einkauft, ne, CAM und AWS-Services, also nicht alles jetzt selbst baut, sondern eben klar sagt, ich nehme einen Betrag X in die Hand, dafür spare ich mir aber auch die Ressourcen, um das selber zu bauen, zu warten, weiterzuentwickeln, zu maintainen, was auch immer. Jetzt sagt ihr aber, ihr seid klein, ihr wollt auch klein bleiben und baut aber trotzdem alles selber. Wie funktioniert das denn?

SPEAKER_01 5:45

Aufgrund natürlich unserer Historie. Also wir haben einen unglaublichen Tech-Stack, a Backlog. Das heißt, wenn du dir jetzt anguckst, gibt es schon extrem viele Module, die wir schon angefasst haben aus der Vergangenheit. Also sei es jetzt zum Beispiel unser eigenes Rollout-Management. Könntest du jetzt den Klassiker nehmen und sagen, ja, Rollout kann man ja auch bauen mit Produkten, die es am Markt natürlich gibt, die die Pakete bauen, Containerisierung machen und so weiter. Wir haben das auch selbst gemacht, weil wir damit quasi im Rahmen eines eigenen CRMs, eines eigenen Backend-Systems quasi alle Qualitätsprozesse, egal wie viele Produkte wir in Zukunft anbieten, aussteuern können. Das ist der eine Punkt. Damit, warum haben wir die Entscheidung getroffen? Rückgriff auf alte Technologien, alte Pakete, die wir natürlich auch haben, die wir immer versuchen auch aktuell zu halten. Plus, dass wir die Prozesse, die da drin sind, andocken. Wir bauen nicht alles selbst, fairerweise. Ticketsystem zum Beispiel, bin ich auch offen, haben wir nicht gekauft, haben wieder zugenommen. Weil wir sagen, da gibt es ein paar Punkte, wo wir sagen, hey, da wollen wir, das können wir auch gar nicht bauen. Noch nicht. Sondern es war so. Und verkompletieren damit unser Ökosystem. Das heißt, Backend-System, Rollout, als Beispiel auch die gesamte Thematik, wie die Dinge gebaut werden, machen wir selbst, weil wir dann die maximale Kontrolle drüber bekommen wollen. Und weil wir zum Glück aufgrund unseres Teams, auch schon vor meiner Zeit, auf sehr viele Artefakte, auf sehr viele Libraries, die wir selbst schon im Bestand hatten, auch zurückgreifen.

SPEAKER_00 7:12

Und wo ziehst du dann da die Grenze? Also man kann natürlich sagen, ich mache das alles, was mein eigenes Produkt betrifft, da baue ich alles selbst. Aber du kannst ja auch das nochmal trotzdem nochmal größer ziehen und kannst sagen, naja, an das Produkt sind auch Service angekoppelt, wie beispielsweise ein CRM. Baue ich das selbst auch mit der gleichen Logik? Oder mache ich hier den Cut und sage, nee, ein CRM, das kaufe ich mir dann gerne nochmal ein. Aber alles, was mein Produkt und die Lieferung meines Produktes angeht, das baue ich alles selber.

SPEAKER_01 7:44

Spannende Frage. Es kommt drauf an, da muss ich so eine Beraterantwort geben. Also es wäre so, dass Blaupause, wie es aktuell in unserem Unternehmen aussieht, wir haben ein internes Produkt, das nennt sich Jarvis. Kennst du? Das ist ähnlich wie der Roboter von Ironman. Iron Man. Ja, genau. Ist auch gewollt so. Und da drin sind quasi Kundeninformationen, da drin sind unsere Rollouts gemanagt und so weiter. So da drin ist auch als Beispiel verschiedene Attribute, die wir am Kunden pflegen, die Historie und so weiter. Wie weit ist das dann weg von einem CRM, was du konventionell kaufen kannst? Das ist der eine der Punkte. Da muss man dann eine Entscheidung treffen. Meistens geht es dann um solche Dinge wie: würde man eine KI selbst programmieren? Steht aktuell zur Diskussion, ist so eine Technology-Dec-Diskussion, die wir aktuell auch führen. Wo wir sagen, hey, eigene KI, weil die Bestands KI, die wir aktuell im Produkt haben, ist eine von den ganz wenigen Komponenten, die wir nicht selbst programmiert haben. Die ist quasi ein Rapper, API-Rapper von verschiedenen Produkten, die wir anbinden können. Zentraler Service aber, wo wir an verschiedene APIs von anderen KI-Anbietern dran können. Aber primär ist es so, das muss man dann individuell entscheiden. Und der Technologie-Stack muss es erlauben, dass du auch, wie jetzt, wir hätten ja auch direkt die APIs anbinden können vom zum Beispiel Open AI, dass du sie trotzdem einen eigenen Service schon hast, an dem sind es vielleicht jetzt schon Produkte angedockt, fairerweise, die irgendwo am Markt verkauft werden. Dass du das aber später tauschen kannst gegen deine eigenen Services, gegen deine eigene KI, gegen deinen eigenen Punkt, den du natürlich dahingehend hast. Und das ist der Punkt. Das heißt, du bist sowieso schon primär gezwungen, in vielen Bereichen eigene Services zu bauen, um nicht von vornherein ultimativ abhängig zu sein. Und die Entscheidung, weil du ja die Frage gestellt hast, wo man da die Grenze zieht, die ist sehr spannend zu beantworten, indem man sagt, man muss abwägen.

SPEAKER_00 9:43

Also ihr habt sie gezogen, indem ihr sagt, ihr habt auch ein eigenes Jarvis, also ein eigenes CRM und stellt euch zwar natürlich zwischendurch schon die Frage, brauchen wir nicht doch noch irgendwas, was unser eigenes CRM jetzt nicht kann, aber aktuell seid ihr auf die, ist die Antwort immer nein, wir bleiben jetzt erstmal so, wie es ist.

SPEAKER_01 9:59

Im Groben korrekt. Im Groben würde ich das genauso unterschreiben. Dann ist aber die Frage, kannst du eine KI nachbauen? KI, riesiges Thema, beschäftigt sich auch im Community damit, viele Themen, die ganze Markt beschäftigt sich mit dem Thema künstliche Intelligenz. Die Frage ist dann, welches Modell nennt man? Baut man sich einen Rapper? Welches Modell habt ihr genommen? Wir haben eine Kombination mit einem Google-Modell, also von Gemini und einem OpenAI-Modell als Redundanz dazu. Das heißt, wir können.

SPEAKER_00 10:29

Wir kommen ja später noch auf das Thema digitale Souveränität, unabhängig. Es geht ja auch dann auf geopolitisch und auf geopolitischer Ebene. Wäre es dann nicht folgerichtig auf ein Mistral oder sowas zu gehen? Ist das im Planung?

SPEAKER_01 10:42

Also wir haben den Spagat zwischen europäischer KI. Mistral ist eigentlich auch nicht souverän, wenn man sich genau mit beschäftigt, weil die auch auf AWS hosten. Das ist nochmal ein anderer Punkt, aber es wäre die Frage, eigentlich einen eigenen KI-Container zu hosten, einen eigenen Service dafür anzubieten. Was auch mittlerweile geht. Die Frage ist dann, auf welches Modell setzt du auf? Nimmst du ein Open-Source-Modell von einer KI mit wahrscheinlich geringeren Foundation-Anteil? Würde ich abwägen und sagen, muss man dann auch bewerten. Wir hatten zu dem Zeitpunkt, musst du überlegen, wir haben das integriert 2023. Überleg dir mal, wann OpenAI rauskam. Oktober 2022. So, da muss man so ein bisschen die Varianz schaffen, sagen, okay, wir haben das zum Zeitpunkt gemacht, wo viele gesagt haben, ja, KI ist voll da ist so hottest shit, könnte sich entwickeln zu einem interessanten Feld und so weiter. Aber noch nicht klar war, dass es dieses Ausmaß annimmt. Da haben wir Entscheidungen jetzt getroffen, dass wir mittelfristig mit einem großen Punkt auch in die Richtung gehen werden, dass wir andere Modelle anbinden, souveräne Modelle, tendenziell aber perfekt unserer DNA entsprechend ein eigenes Modell. Mit Inventardaten, Modelldaten, Bilddaten, alles, was diesen Service dann im Speziellen, es kann ja ein KI-Modell sein, ein Container sein, der das wiedergibt, was der Service braucht. Kleinere Modelle, nicht so große Modelle. Es muss nicht wissen, dass morgen, keine Ahnung, die Wahl ist von irgendjemandem auf der Welt.

SPEAKER_00 12:07

Ja, der Trend wird wahrscheinlich auch dahin gehen, dass wir in vielen Kontexten eher auf kleine, spezialisierte Modelle hinauslaufen werden. Natürlich gibt es auch die großen, aber die sind natürlich auch von wesentlich schwergewichtiger auch im Umgang und den Kosten und so weiter und so fort. Bevor wir jetzt da weiter auf die digitale Souveränität eingehen, das ist auch ein tatsächlich ein Thema, auf dem wir noch ein bisschen rumreiten werden. Ich habe noch die zum Thema eurer Größe, ihr seid ja bewusst klein geblieben. Warum ist das für euch ein strategischer Vorteil? Also vor allen Dingen vor dem Hintergrund, sagen, naja, ihr seid, ihr seid gerade sehr stark, also ihr macht wahrscheinlich eine sehr gute Marge, ihr seid mal Gewinnumsatz pro Mitarbeiter, seid ihr wahrscheinlich dann auch sehr, sehr gut unterwegs. Das kann man natürlich, ist man der Meinung, dass man das nicht skalieren kann in der Form? Oder was ist der Grund, warum man bewusst klein bleibt?

SPEAKER_01 12:59

Also wir haben drei Aspekte dabei. Das eine ist natürlich, wenn man den Umsatz pro Kopf betrachtet, bringt einem das natürlich Vorteile, in dem man sehr gute Gehälter zahlen kann. Gute Leute finden kann damit. Hochwertige Leute, Seniors, aber auch natürlich entsprechend perspektivisch eine strategische Gehaltsentwicklung forcieren kann. Das ist einer der Punkte. Der zweite Punkt ist, wir bieten ja ein Nischenprodukt an. Sagst du mal, wir bieten ein IT-Asset Management an. Das heißt, Inventarverwaltung, Software-Asset-Mensch, Lizenzen, Verträge, alles, was da drum ist, mit Automatikprozessen, mit Benachrichtigung, Piperporium. Also alles, was du brauchst, um quasi ein Unternehmen, operativ, Übergabe, Rückgabe, Lifecycle von Geräten und so weiter alles verwalten zu können. So. Das ist jetzt nicht als Beispiel ein CRM. Das ist eine große Nische, sagst du jetzt. Viele würden sagen, naja, es ist aber kein CRM, es ist kein Ticketsystem, es ist kein Security-Thema, was höhere Prioris hätte als Beispiel. Aber es ist auf jeden Fall ein Bereich, in dem die Marktsegmente kleiner sind als in vielen anderen Bereichen. Deswegen für uns, wir versuchen das ja auszuweiten, ich werde nochmal nachher erklären, warum das eigentlich so klein ist aktuell und nicht so groß, wie es hätte theoretisch auch sein können, ist es natürlich so, dass wir auch eine gewisse persönliche Nähe schaffen wollen. Warum sind wir erfolgreich? Warum können wir die Performance an den Start bringen? Das ist eine Kombination aus, ich kenne dich, machen es mal zwischen uns beiden. Ich kenne dich, Philipp. Du kennst mich, ich kenne deine Frau, du kennst meine Familie, ich kenne all deine Vor- und deine Nachteile, du kennst all meine Vor- und meine Nachteile persönlich auch. Wir können uns super navigieren durch diesen Kosmos von, ja, ich weiß jetzt, wie ich perfekt den Philipp einsetzen kann. Der Philipp weiß genau, wie er mit mir umgehen muss, als Beispiel, wo wir uns dann dadurch navigieren und mit dem Personal jeweilig die besten Ergebnisse erzielen kann. Wir können Fehler tolerieren, wir können super kommunizieren, wir können auf Dinge reagieren und dem Mitarbeiter vollkommene freie Flexibilität anbieten. Und das geht nur bis zu einer gewissen Grenze an Mitarbeitern. Die Grenze, weil die Frage bestimmt kommen wird von dir, die Grenze der Mitarbeitermenge, bis man das machen kann, ist grob, würde ich immer sagen. Die divergiert zwischen 50 bis 100 Mitarbeitern, wo du Mittelmanagement brauchst. Irgendwann. Irgendeinen Zwischenpunkt. Und das ist der Grund, warum wir so klein bleiben wollen und auch nachhaltig, langfristig Stück für Stück wachsen.

SPEAKER_00 15:34

Ihr seid aber von den 50 bis 100 Mitarbeitern, seid ihr doch noch eine ganze Menge entfernt.

SPEAKER_01 15:38

Sicherlich, sicherlich. Also die Frage ist ja auch dabei, wir wollen natürlich weiterhin diesen Vorteil mit hohen Gehaltsstrukturen, die man ja zahlen könnte, der Möglichkeit, hohen Marge das rauszubringen, der Internationalisierung, die wir noch gar nicht gemacht haben, wo die auch viel Geld kosten wird, dass wir das alles auch quasi aus dem Portemonnaie bezahlen können, weil wir sind nicht Risikofinanzierend. Das ist alles aus eigenem Geld geschaffen, aus eigenem Tun und Handeln. Wir sind nicht fremdgesteuert und können damit natürlich Dinge tun, aber das muss natürlich aus der eigenen Kriegsklasse geschehen.

SPEAKER_00 16:10

Es wirkt auf mich trotzdem ein bisschen wie Downselling, wenn du sagst, ja, ihr seid ja, das ist ja eine Nische, was ihr macht, IT-Asset Management. Ich würde argumentieren, jedes Unternehmen braucht eigentlich IT-Asset Management, weil jedes Unternehmen hat eigentlich IT-Assets und von Verträgen über Geräte und so weiter. Also ist jedes Unternehmen, ja, vielleicht hat es nicht so den Stellenwert wie ein HubSpot, wie ein CRM oder ein SAP, aber es ist trotzdem eine sehr, sehr große Nische. Also bis zur Welt. Ihr seid ja auch in gewisser Weise mehrfach ausgezeichnet worden, auch als Marktführer und als beliebtestes Unternehmen in dem, äh, als beliebtestes Software in dem Bereich. So, also das spricht ja auch für euch und für euren Weg. An welcher Stelle ist das aber ein Nachteil? Wenn jetzt zum Beispiel ein chinesischer chinesisches Unternehmen kommt, das den Auftrag hat von der Regierungsseite, kauft ihr solche Unternehmen im europäischen Markt ein, erschließe diesen Markt und baue da den Weltmarktführer in dem Bereich, dann ab dem Zeitpunkt würde euer Modell wahrscheinlich auf große Schwierigkeiten stoßen.

SPEAKER_01 17:12

Oder nicht? Möglich, also will ich nicht ausschließen. Also man sollte ja auch die Konkurrenz ernst nehmen. Das ist ein Punkt, der teilweise die deutsche Industrie unterschätzt hat in der Vergangenheit. Denen ist es nämlich passiert. Ich würde sagen, es gibt dieses Restrisiko, aber natürlich ist ja auch da die Frage, wie reagiert man auf sowas. Klar, du kannst gegenüber einem großen Marktwettbewerber schlecht dastehen. Das will ich gar nicht ausschließen. Also es kann passieren. Aber auf der anderen Seite ist ja die Masterfrage dabei, selbst wenn der Chinese jetzt als Beispiel den Markt leer kauft, kauft die Top drei Unternehmen, nicht uns jetzt als Beispiel. Weil wir können das ja, weil wir nicht kapitalgetrieben sind, selbst entscheiden. Dann wäre es ja dennoch so, ja, dann hat er halt die Kunden. Und dann, was ist jetzt der Unterschied, Philipp? Er hat zwar mehr Marktmacht, mehr Kunden vielleicht als Beispiel. In der Faktusstelle hat er damit auch das bessere Produkt, weiß ich nicht. Kann ich ihn nicht beurteilen.

SPEAKER_00 18:08

Noch nicht, noch nicht, weil er weiß, ob er es in Zukunft haben wird, aber er wird mit Sicherheit darauf drängen, euch Marktanteile wegzunehmen. Das wird ihm nicht von heute auf morgen gelingen, aber wenn er sagt, ich pumpe da Geld rein, höhere Firepower und ich mache das über Preis, ich mache das über Feature-Menge, die ihr einfach mit der Manpower, die ihr habt, einfach nicht abbilden könnt.

SPEAKER_01 18:30

Es gibt bestimmte Punkte, wo das so ist. Aber ich mal als Beispiel in unserer Größe, so grob zehn Leute sind das immer im Punkt, wenn wir auch ein paar externe noch reinrechnen. Es ist ja so, so 300 Feature-Requests fließen in das Inventory 360. Das ist jetzt nicht Button grün auf blau machen und so, sondern wirklich ein Feature. 150 Kundenwünsche, 150 etwa durch uns. So, mal ganz grob gesprochen. Da kannst du ja ausrechnen, wie viele das sind. Das reicht uns, um dieses Produkt, einfach mit Kundenfeedback zu spiegeln, das reicht uns, um das Produkt am Markt strategisch weiterzuentwickeln, ausreichend für die Kunden. Die Masterfrage, die natürlich bleibt, ist, was passiert, wenn jemand in den Markt kommen würde und würde sagen, ich mache 3000 Feature-Requests. Mal ganz übertrieben gesprochen. Der Chinese, der hat dreimal, vielleicht zehnmal so viele Mitarbeiter, der kauft die Unternehmen ein und versucht das zu harmonisieren. Das ist ein Risiko, den muss man sich natürlich stellen. Ich will auch nicht sagen, dass es unmöglich ist. Das wäre auch ein Fehler. Es ist das Unternehmen gefallen in der Vergangenheit auch schon. Das heißt, ich würde auf jeden Fall sagen, das Risiko muss man ernst nehmen. Wenn es Marktwettbewerbe gibt, das machen wir ja jetzt schon, die bestimmte Feature-Punkte haben, dann muss man die sich angucken und überlegen, ob man die auch bei sich integriert. Ist das der Punkt, den die Kunden brauchen, oder sind das einfach nur so Lost Features? Wo du sagst, ja, toll, tolles Feature, wird eh nicht benutzt. Es gibt so eine Studie vom New Yorker Unternehmensberatung, also Unternehmensberatung aus Amerika, die hat analysiert, wie viele Features und Softwareprodukten eigentlich verwendet werden. Und erschreckenderweise waren das, ich glaube, fast nur 30% der Feature-Blöcke werden verwendet. Muss ich mal gucken, ob ich das finde, diese Schuhe.

SPEAKER_00 20:10

Ja, das halte ich durchaus für plausibel. Also du merkst ja, dass das Szenario, was ich versuche zu skizzieren, ist natürlich hochspekulativ und ein What-If-Szenario. Was ich aber hinten dran damit auch versuche herauszufinden, wie viel die Entscheidung für euch klein zu bleiben, ist das Strategie oder ist das Ideologie? Weil ich glaube, dass wenn es Strategie ist, ist es richtig und eine Strategie kannst du auch anpassen und ändern, wenn es notwendig ist. Wenn es Ideologie ist, dann hängst du daran. Und dann wäre auch meine Einschätzung wahrscheinlich, würde ich sagen, okay, das funktioniert, aber das ist, wenn es Ideologie ist, wird es irgendwann vielleicht nicht mehr funktionieren, wenn die Realität die Ideologie einholt.

SPEAKER_01 20:49

Also es ist auf jeden Fall keine Ideologie, weil wir glauben als Beispiel auch nicht daran, dass man jeden Punkt, wenn man Ideologie betrachtet, das sind ja als Idee, vom Begriff her, das ist ja, wenn man zu einem Thema sagen würde, das stimmt nicht, obwohl es stimmt. Das ist ein ideologischer Ansatz. Ich glaube an etwas, was gar nicht eigentlich, wenn du es mit Fakten belegen kannst, gar nicht stimmt. Und das ist ja, bei uns ist ja der Punkt, wenn ich strategisch vorgehe, sage hier, Größenordnung, Performance, dann wird ja mit einer sehr großen Anzahl von Mitarbeitern in unserem strategischen Ansatz die Performance sinken. Das kann passieren. Also das ist sogar sehr, ich habe im Unternehmen gearbeitet mit zum Beispiel 5000 Mitarbeitern. Indischer Softwarekonzern kann man bewerten, wie man will. Das sind sehr viele fähige Menschen dort gewesen und so weiter. Und häufiger hatte ich das Gefühl, dort ist die Prozessqualität nicht so hoch gewesen. Die Absprache, die Kommunikation nicht so gut gewesen. Andere Themen, wo ich echt immer sagen würde, warum ist das eigentlich so? Das darf euch in der Größe nicht passieren, das darf euch mit zehn Leuten nicht passieren, aber bei 5000 Leuten mit den Größenordnungen, mit den Produkten, hat das wirklich dazu geführt, dass man das auch anders organisieren hätte können. Und die Gefahr ist immer da. Bei Teamfeel, Wenn wir das Beispiel nehmen, hast du ja auch vielleicht gesehen. Wie viele Leute onboardest du? Wie werden die onboarded? Wie ist die Qualität der Leute? Wie muss man kommunizieren? Welchen Overhead als CTO habe ich denn oder mit meinem Team habe ich denn jetzt, um das zu synchronisieren? Irgendwo gibt es da ein Spannungsfeld, eine Grenze. Meiner Meinung nach.

SPEAKER_00 22:16

Definitiv. Definitiv.

SPEAKER_01 22:18

Und ich weiß auch nicht, wie sie bei Teamviewer, rückblickend bei dir jetzt gewesen wäre. Weil du sagst, wäre das mit 1000 auch gegangen? Mit 5000, mit 10.000? Weiß ich nicht.

SPEAKER_00 22:28

Die Tausender-Grenze hatte man ja schon lange überschritten. Man ist ja jetzt eher Richtung 2000 unterwegs, wenn ich das jetzt richtig sehe. Aber ja, natürlich, du bist irgendwann an dem Punkt, wo die Geschwindigkeit im Onboarding natürlich schon was macht mit der Kultur, mit der Performance. Da die richtige Balance zu finden, ist immer schwierig, weil in Zeiten, wenn die Opportunität da ist, dann ist natürlich auch die Erwartungshaltung da, dass du halt anfängst, schneller zu wachsen. Einfach um die Opportunitäten nicht vorbeigehen zu sehen. Aber das hat natürlich auch Opportunitätskosten. Und die musst du auch bereit sein zu zahlen. Also, du siehst, das ist auch wieder die It-Dependence-Antwort, aber das ist zum Beispiel nicht.

SPEAKER_01 23:13

Nee, aber es ist die Realität, weil wenn du überlegst, du hast deine Teams, wie kommunizieren alle Leute aus dem Team mit dem Team, nur der Head-Count-Mensch, der die Leitung innehat, kommuniziert der mit dem Rest der anderen Leute. Wie wird das Ganze gemacht? Das ist ja eine Strukturfrage. Und mit einem kleineren Team können wir bestimmte Strukturfragen strategisch umgehen. Das ist halt für uns ein Punkt, den wir einfach so sehen. Das kann sich, vielleicht reden wir in zehn Jahren, ah, jetzt hat der Alex hier, keine Ahnung, drei Produkte, hat dreimal zehn Leute da am Start sitzen als Beispiel, hat er sich alles geändert, jetzt kommt er in dieses Problem hinein, vielleicht. Kann ja alles sein, weiß ich ja jetzt nicht. Hängt ja von der Größe ab, dem Erfolg. Man kann ja auch theoretisch scheitern, aber dann kann es vielleicht ganz anders sein, wirklich.

SPEAKER_00 23:57

Wir haben jetzt vorher schon mal angesprochen, das Thema digitale Souveränität. Und du hast jetzt auch schon ein bisschen Einblick daran gegeben, was das denn für euch bedeutet. Aber ich möchte ja gerne noch ein bisschen tiefer reingehen. Also gerade das Thema digitale Souveränität, was bedeutet das denn? Also Unabhängigkeit auf rechtlicher Ebene, auf politischer, auf technologischer Unternehmen, was bedeutet es für euch als N-Tech-System und als Unternehmen?

SPEAKER_01 24:23

Im Grunde genommen, wenn du die digitale Souveränität in unserem Unternehmen siehst, ist es immer die freie Entscheidungskultur. Ich kann frei ohne erstmal einen Anspruch, ohne eine rechtliche Abhängigkeit, eine politische und eine technologische Abhängigkeit der Entscheidung treffen. Das ist erstmal grundsätzlich. Das haben alle Unternehmen, das hat nicht nur die Entec, das ist der Grundsatz. Und wer kann frei als Beispiel entscheiden? Wenn man zum Beispiel, bleiben bei dem Hyperscaler-Szenario, ein Hyperscaling-Thema hat, dann hast du natürlich Themen wie, bietet der Hyperscaler diese Funktionalität? Amerika, hat der Cloud Act, das ist ja so diese Standarddiskussion, hat der CloudAd wirklich die rechtlichen Risiken für mich? Und wenn ja, was bedeutet das für meine Endkunden, nicht nur für mich als Unternehmen? Und vor allem dann politisch, was macht die Geopolitik, also aktuell Iran-Thema, zum Beispiel. Da werden ja Rechenzentren angegriffen jetzt mittlerweile, das ist ja aktiv passiert gerade aktuell. Welche politischen Themenrisiken hat denn jetzt aktuell die Weltlage? Und wenn ich die Themen in der Lieferkette unter Kontrolle habe, vielleicht sogar Inhouse komplett, kann ich frei entscheiden und habe insgesamt weniger Risiken. Das ist erstmal der Grundtenor einer digitalen Souveränität. Und was ich dann da entscheide, wenn ich frei bin, kannst du theoretisch jemanden fragen, der zum Beispiel auch kaum Besitz hat, der ist frei letzten Endes, der hat keinerlei Bedingungen. Der kann sagen, ich mache das jetzt so oder so. Für uns auch die Frage, wir können technologisch frei entscheiden, welchen Stack wir einsetzen. Egal was es wäre. Wir können frei entscheiden, als Beispiel, ob wir nächste Woche einen anderen Stack nehmen. Strategisch wiederum nicht, aber ich meine, rein von der Entscheidungskultur.

SPEAKER_00 26:14

Ist das wirklich Freiheit oder ist das nur, ich entscheide mich aktiv dafür, bestimmte Constraints nicht zu haben und nehme dafür bewusst andere Constraints auf. Also ist es wirklich Freiheit? Ich würde ja sagen, nein. Also Freiheit, du kannst frei deinen Stack wählen, aber du brauchst trotzdem immer noch, du brauchst ein Rechenzentrum, in dem du deine Server hostest. Und wenn du dann sagst, ja, das eine passt mir nicht mehr, dann gehst du ins andere, aber trotzdem brauchst du immer noch mal ein Rechenzentrum und brauchst diverse andere Services, auf die du zugreifst.

SPEAKER_01 26:46

Das ist sicherlich richtig, dass du sagen kannst, du könntest bei einem Hyperscaler, der Standardservices anbietet, zu einem anderen wechseln, der andere Standardservices anbietet. Aber was machst du, wenn es einen Service bei einem Hyperscaler nur dort gibt? Gibt es ja.

SPEAKER_00 26:58

Genau, gibt es ja.

SPEAKER_01 26:59

Es gibt so Services, bestimmte bei AWS zum Beispiel, die sind drüben anders, die heißen anders, die funktionieren auch ein bisschen anders. Und dann musst du auf Anfang, eine Software vielleicht umzubauen. Du hast ja fast wie ein Vendor-Login letztens. 100 Prozent, ja. Also das gibt es. Bei den Programmiersprachen war das eher rein von der Kultur erstmal gemeint, dass man wechseln könnte. Es gibt auch Produkte, wenn du da drin bist, da kannst du nicht jede Software oder Programmiersprache einsetzen. Geht ja auch. Und bei uns wäre es so, wir müssten auch den Technologies-Stack wechseln, müssen aber nicht gucken, ob es beim Hyperscaler dann irgendwelche Vorbedingungen gibt oder Besonderheiten dabei. Als Beispiel jetzt. Deswegen, ich sehe es als Freiheit, als technologische Möglichkeit, einfach die Dinge frei nach eigenen Kriterien entscheiden zu können. Ob das dann für den anderen in der Außenwirkung Freiheit ist oder ob man sagt, ich erkaufe mir das mit bestimmten Grundbedingungen wie ich muss alles selbst bauen, ich muss den Betrieb selber gewährleisten und solchen Dingen, das oblasse ich dir und deinen Zuhörern. Aber ich sehe das schon so, weil wenn du den Begriff digitale Souveränität ernst nimmst, auf gewisse Standards aufsetzt, Virtualisierungsstandards, Programmierstandards, Technologiestandards und so weiter, dann kannst du natürlich auf jeden Fall auch ohne hohe Risiken wechseln. Du kannst von VMware auf Proxmox wechseln. Du kannst auch theoretisch, wir haben jetzt einen Klassiker, von Java auf PHP wechseln, wenn du dann Änderungen nimmst. Als Beispiel jetzt mal. Aber du kannst auch von Java. Java oder auf Cotlin wechseln, wenn man jetzt mal übertreibt, ne? Auf diese proprietär dahingehend ein bisschen den Wechsel vollziehst. Aber es ist in Anführungszeichen alles mit gewissen Vorbedingungen erfüllt. Nur die Frage ist, bist du, ist das dein eigenes Kriterium, warum du entscheidest? Oder ist das das Kriterium, weil AWS diesen Service nur dort anbietet oder bestimmte andere Bedingungen hat? Und das sehe ich als Kernaspekt. Wenn ich sage, ich entscheide das selbst, entscheide ich ja auch dann, wenn ich möchte. Wenn AWS, beispielhaft, Abhängigkeit, wenn AWS oder GCP oder Azure, die großen drei, die Preise erhöht, was tue ich dann? Wenn ich selber das Rechenzentrum betreibe, muss ich auch Vorleistungen bringen, rechne ich durch. Habe ich selbst zwar den Kostenblock am Bein, aber kann trotzdem, wenn das gut gemacht ist, Geld sparen. Das ist einfach so. Man hat gewisse Formen der Skalierung dann dabei, bestimmte nicht, auch als Punkt. Aber es ist dann halt einfach ein ganz anderes freier Entscheidung. Ob das für denjenigen passt, ne, das will ich auch sagen. Digitale Souveränität ist nicht für jeden geeignet. Auch wenn das aktuell so gesagt wird. Es kann sein, dass du als Unternehmen, souveräne Cloud, etc., kann man auch drüber streiten, ob es so ist, ob es ein Washing-Thema ist. Ob das dann für denjenigen passt in der Szenerie, das ist ein ganz anderes Thema. Da kann man sagen, ich betreibe alles in der Cloud, für mich ist es fein und ich kann global skalieren. Fein, ist okay. Dann passt das auch so weit. Nur für uns in der Thematik, als deutsches Unternehmen, gerade in dieser besonderen Rolle in Europa, die Besonderheit, die wir da inne haben und dieser ganzen Diskussion, in der wir in der Geopolitik ausgesetzt sind, sollte sich jeder hinterfragen, ob digitale Souveränität nicht auch was mit seiner eigenen freiheitlichen Kultur zu tun hat. Weil spätestens, wenn du jetzt anguckst, Politik und Technologie zu kombinieren anschaust, wird die Frage aufkommen, möchtest du denn mit jemandem zusammenarbeiten, der andere Leute abschießt? Möchtest du, möchte, also moralische Grenzen, Moral ist da noch gar nicht da drin, Mindset-Fragen und so weiter. Dann fängt diese ganze Thematik nochmal an, mit einer Werteiligkeit weiter diskutiert zu werden. Und das spielt damit natürlich auch mit rein. Das heißt, das ist ein sehr komplexes Thema, meiner Meinung nach. Und ich verbinde es sehr, sehr stark mit einer freiheitlichen Entscheidung.

SPEAKER_00 30:45

Was ist denn der größte Irrtum, den Unternehmen dann in diesem Kontext machen? Gerade wenn sie vielleicht denken, sie wären souverän, es ist aber eigentlich nichts, sie glauben aber, dass sie es wären. Erlebst du das mit anderen oder ihr guckt ja tatsächlich nur auf euch selber und du kannst es gar nicht beurteilen.

SPEAKER_01 30:59

Nein, nein, nein. Also wir schauen schon viel drum herum. Auch ich als Privatperson lese ja viel, also ich muss es ja auch, weil so viel passiert in den ganzen Bereichen. Ich würde zum Beispiel sagen, der Server steht in Deutschland, du kennst dieses Bild, diese Grafik, die es so gibt. Der Server steht in Deutschland, also bin ich digital souverän. Wenn der Server aber in Deutschland steht und von einem amerikanischen Unternehmen betrieben wird, das ist dieser Fallbeispiel, was wir immer haben, und du hast keine souveräne Cloud, ich unterstelle jetzt mal, dass diese Cloud so wirklich souverän ist. Man kann diesen Punkt immer noch diskutieren. Immer an, dass es ganz normal gehostet und du sagst, ich möchte jetzt, dass das Zeug in Irland oder in Frankfurt am Main von Microsoft gehostet wird, dann ist das erstmal als Beispiel, wenn man die Diskussion sieht, gar keine Souveränität. Denn der amerikanische Unternehmer, das Unternehmen, kann durch diese Entscheidung, die es gibt beim Cloud Act und Pad den entsprechenden Datenschutzthemen, die es noch gibt zusätzlich, natürlich Daten rausgeben müssen. Also es gibt irgendjemanden, der dir sagen kann, du gibst mir jetzt, ich bin der Trump, du bist der Amerikaner, du gibst mir jetzt die Daten und das Unternehmen, das die Server nutzt, kann gar nichts dagegen tun. Nichts. Und dann wirst wird das Unternehmen natürlich sagen, ich bin der Nutzer von dem System. Was willst du mit meinen Daten? Ist mir egal. Du gibst das entsprechend. Und diese Szenerie, die ist der erste Irrtum, der existiert, nur weil der Server in Deutschland ist, existiert nicht automatisch ein Grundrecht auf diese Souveränitätsthematik. Zweiter Punkt. Zweiter Punkt, den ich noch sehe, ist das Thema, weil ich Open Source einsetze, bin ich digital souverän. Auch das stimmt nicht so ganz. Denn ich kann das genauso machen. Ich kann ein Open-Source-System auf ein amerikanischen System hosten. Ich kann Open Source als Beispiel auch so einsetzen, dass das gesamte Community Management, gehen wir ja gleich drauf nochmal ein, auch auf diesen Blog bin der Software, das gesamte Community Management, ich nicht in der Kontrolle habe. In dieser Community werden Dinge entwickelt im Open Source Stack, die ich nicht kontrollieren kann, zu denen ich keinen Zugriff habe und die teilweise sogar zu exorbitanten Fehlern und Sicherheitsrisiken in meiner Lieferkette führen. Und das ist der zweite Trugschluss. Wir nutzen selbst Open Source, gehen wir noch drauf ein, auch zum Teil, bei bestimmten Aspekten, sagt ihr aber auch dann die Auswahl, wie es noch ist. Und der Grundtenor, der da dort entsteht, ist, nur genauso wie der Server, nur weil man Open Source einsetzt, ist man nicht per se digital souverän.

SPEAKER_00 33:28

Ist die digitale Souveränität dann am Ende des Tages ein Wettbewerbsvorteil? Oder ist sie ein Überlebensfaktor in einer Welt, in der man sich auf alle Eventualitäten vorbereiten muss?

SPEAKER_01 33:43

Ich habe die Frage, im Vorhinein hast du mir die ja gegeben, die ist sehr schwierig zu machen.

SPEAKER_00 33:47

Ich kann doch sowas nicht.

SPEAKER_01 33:49

Im Vorhinein, ich kann sie jetzt immer noch nicht fair beantworten. Ich würde sagen, digitale Souveränität minimiert Risiken. Ich glaube, das ist die einzige Antwort, die fair ist, ohne jetzt da größeren Antwortblock zu geben, weil Überlebensfaktor, was ist das aus deiner Ansicht nach? Es ist ja ein Risiko.

SPEAKER_00 34:11

Also es ist ja, es ist ein, dann lass mich mal umformulieren, ist es in erster Linie Risikomanagement oder ist es ein Vorteil im Wettbewerb? Ich meine, du kannst immer argumentieren, dadurch, dass du damit ein Risikomanagst nicht vom Markt geschluckt oder nicht extinkt zu werden, weil du auf alle möglichen Eventualitäten reagieren kannst, quasi dein Risikomanagest, hast du einen potenziellen Wettbewerbsvorteil? Den hast du aber jetzt nicht. Den hast du vielleicht irgendwann in der Zukunft. Hast du einen, siehst du in der digitalen Souveränität jetzt einen akuten Wettbewerbsvorteil im Markt gegenüber anderen? Oder ist es nicht eher, das ist ja die Frage dahinter, ist es nicht eher die Vorbereitung auf eine Eventualität, die denn da mal irgendwann kommen kann?

SPEAKER_01 34:55

Wahrscheinlich erstmal größere Risikoaffinität, also dass du Risiken im Vorhinein abfedern kannst und eigentlich, wenn jetzt ein Artikel rauskommt, so irgendetwas, selber sagen kannst, interessiert mich ja gar nicht. Ich habe ja dafür schon meinen Plan B direkt in meiner Tasche. Das ist auf jeden Fall, würde ich sagen, der größere Anteil. Der zweite ist, wenn aber der Wettbewerbsvorteil Kosten sind, nehmen wir mal an, der RZ, du betreibst deinen RZ, du hast die Skalierung alle eingeplant und so weiter. Und bei AWS und Gott weiß wo, die hätten ihre Preise auch angehoben. Alle Rechenzentren werden mittelfristig ihre Preise anpassen müssen. Wirst du bald sehen. Spritpreise steigen, Gas steigt, Strompreise steigen dadurch. Wird viel passieren, wirst du sehen. Es wird direkte Auswirkungen haben, bin ich ziemlich sicher auch bald, weil du siehst ja selbst beim Tanken. So. Und der entscheidende Punkt dabei ist, wenn Kosten als Wettbewerbsvorteile betrachtet werden würden, kannst du durch eine gute Strategie, durch den Betrieb eigener Infrastruktur und der Absicherung, dass das auch Preisstabilität mit sich bringt, auch das als Wettbewerbsvorteil meiner Ansicht nach verkaufen. Das geht.

SPEAKER_00 36:02

Okay, ja, das finde ich, ist auch eine sehr plausible Antwort. Du hast jetzt vorhin, also wir haben ja über das Thema gesprochen, ihr seid sehr viel selbst am Bauen. Du hast aber noch das Thema Open Source auch noch genannt. Korrekt. Und du hast, das habe ich ja auch noch als schön aus dem Vorgespräch, du hast gesagt, ihr fahrt teilweise eine Gegenposition zu Open Source. Erzähl mal ein bisschen, was steckt da dahinter. Genau. Jetzt kommt die steile These, die kann man so gut dann irgendwie vermarkten später wieder.

SPEAKER_01 36:32

Ja, gar kein Problem. Per se erstmal als Thema, wir sind nicht gegen Open Source, ne? Wenn jetzt einer hört, der Herr Vandelsteg, der ist ja hier nur dagegen. Das ist so einer, der will nur Produkte verkaufen. Der möchte nur Inventory 360 verkaufen. Alle sollen das nehmen. Das war ein wichtiges Thema, wie der Philipp gesagt hat und so weiter. So ist es nämlich nicht. Open Source als Beispiel hat seine Berechtigung schon aus den Ursprüngen des Internets. Das will ich vorweg einfach mal sagen. Alles, was damals entwickelt worden ist, zum sehr, sehr großen Teil, ist aus dem Gedanken entstanden, Inhalte frei zu teilen. Dafür sind wir auch. Da gibt es gar keine Kontroverse. Nur der Punkt ist zu sagen, ja, ich bin jetzt ein Produktanbieter, diese Gegenposition, die wir jetzt bilden müssen. Ich bin jetzt ein Produktanbieter, wir bieten ja Closed Source an, ganz offen gesprochen. Und deswegen ist da die Gegenposition, dass wir genauso verräterisch, preistreiberisch und genauso negativ in unseren Grundzügen sind wie alle großen, ich nenne es explizit, Softwareanbieter am Markt, primär die amerikanischen, die jedes Jahr 30, 40 Prozent mehr Geld haben wollen, die jedes Jahr quasi mit den Produkten Kapital schlagen, die Daten missbräuchlich verwenden und so weiter. Das ist die Grundannahme am Markt mittlerweile. Wenn einer sagt, hey, ich nutze Open Source, weil das andere drüben ist ja alles schlecht. Da frage ich immer dann als Gegenthese, was hast du denn gegen den souveränen europäischen, fairen Softwareanbieter? Der gar keine Open Source anbietet. Und dann kommt meistens die Diskussion ins Rollen, Philipp. Da kommt die Diskussion ins Rollen. Das heißt, wenn dann drüber spricht, ja, wie macht ihr das mit der Preisgeschichte? Stabilität. Wie bietet ihr das an? Wie ist der Zugriff auf Informationen souverän? Der DMA, der DSA, also der Digital Market Act und der Digital Service Act, zwingen ja, bestimmte Anbieter von Produkten bestimmte Richtlinien einzuhalten. So, und da sagt man, ja, wir müssen uns nach den rechtlichen, den politischen und den technologischen Grundbedingungen, die am Markt sind, natürlich orientieren und machen das auch. Und dann endet das irgendwann, dann wird gesagt, ja, es gibt doch hier Open Source. Welchen Vorteil hast du denn? Der Einzige, der übrig bleibt, der Einzige, da bin ich auch offen, ist, ich kann in deinen Source-Code reingucken. Dann sehe ich, dass du nicht betrügst. Jetzt rein aus dem Geschäftsleben heraus betrachtet, Philipp, so eine Diskussion, du merkst ja selbst, so eine Diskussion so zu führen, wie diese gute.

SPEAKER_00 38:58

Oder man könnte sagen, ich möchte ja deinen Source-Code nutzen, um ihn weiterzuentwickeln.

SPEAKER_01 39:04

Machen 80% der Endkonsumenten doch gar nicht, Philipp. Das ist ein reiner Druckschlag.

SPEAKER_00 39:07

Das ist richtig, das ist eine rein hypothetische Frage und natürlich ist das dann irgendwo auch, sind wir dann in einer wirtschaftsphilosophischen Diskussion angelangt. Man kann ja auch sagen, ja, es gibt ja Open Source da draußen. Wieso hat sich Open Source denn die durchgesetzt gegenüber proprietären Sachen, gegenüber Closed Source? Da kann man sagen, naja, die haben halt einfach alle guten Leute aufgekauft. Ja, weil der Markt halt auch so funktioniert, ne? Weil du das Geld muss auch im Umlauf bleiben und das Geld muss, es hilft ja auch, unseren Wohlstand zu mehren, um das weiterzuentwickeln. Und scheinbar funktioniert das mit Closed Source, mit proprietärer Software funktioniert das besser als mit Open Source. Wenn das nicht so wäre, würde es Open Source anders funktionieren.

SPEAKER_01 39:50

Und der Grund, den noch, der mir missfällt, ist, es wird unterstellt gegenüber den Anbietern am Markt, zum Glück verändert sich das aktuell gerade, dass er auf der Gegenseite jemand ist, der will nur abzocken. Und will eigentlich, ich will nicht das Wort Betrügen in den Mund nehmen, aber vor allem abzocken, abkassieren und will alle seine Vorteile damit reinnehmen. Dann sage ich ganz offen gegenüber und sage, ja, dieser Partner ist auch falsch für dich. Such dir doch einen, der nach diesen Regeln spielt.

SPEAKER_00 40:15

Ist das tatsächlich ein Argument, was ihr zu hören bekommt? Also warum seid ihr denn nicht Open Source?

SPEAKER_01 40:21

Wenig, bis gar nicht. Aber ich bin ja bei LinkedIn, ich bin ja auch in sehr vielen anderen Fachforen drin. Dann wird häufig gestellt, wenn du dort etwas sagen würdest, wenn du da reinschreibst, du bietest ein Produkt an. Wenn du dort reinschreibst, es ist zu bestimmten Teilen so. Dann kriegst du zu hören, was wollt ihr denn? Ist alles viel zu teuer, ich nutze Open Source und eigentlich indirekt ist das Ganze doch nur Abzocke. Dort ist das.

SPEAKER_00 40:42

Ich würde aber behaupten, das ist die Meinung von ein paar Einzelnen, die nicht repräsentativ sind. Also ich glaube, der Großteil, sowohl der Softwareentwickler als auch der Leute auf LinkedIn und so weiter, die haben verstanden, dass gute Software einen gewissen Aufwand braucht, gewisse Qualitätsstandards und dass du die anscheinend dann eher am Markt bekommst zu einem marktfairen Preis, wie dass du sie durch Open Source bekommst. Ausnahmen mögen die Regel bestätigen.

SPEAKER_01 41:07

Ich hoffe, du hast recht und es verbreitet sich stärker, weil ich treffe auf sehr viele Menschen in sehr vielen Situationen, wo dann, also eher eher privat oder in meiner Rolle als Alexander van der Stück, jetzt gar nicht so als CTO in dem Bereich, wo ich jetzt sage, okay, interessante Argumentation. Ich hoffe, du argumentierst in deinem Privatumfeld nicht so, weil dann würde ich mit dir nicht mehr reden. Da kaufst du auch keine Produkte bei irgendjemandem wie Rewe. Rewe ist so zockt dich ja noch ab. Und so weiter. Da kannst du die Argumentation weiterziehen, weißt du, wie ich meine? Das ist ja quasi eine sehr negative Darstellung vom Wirtschaftsverlauf und vom Leben. Und da ist halt der Punkt dabei, wo ich sage, Open Source als sich, wenn wir ja den Punkt ja eben hatten, wir fahren die Gegenposition und sagen, wir haben natürlich ein Produkt, was wir nicht offen anbieten, weil wir auch unsere Marktmacht, unsere Intelligenz und auch unsere Innovationskraft auch schützen müssen. Wir werden jetzt mal ein kleiner, weiß nicht, wann du dir den Podcast spielen wirst, genau zumindest, das wird in unserem Rahmen von einem Produkt zum Beispiel auch eine Weltneuheit geben. Das hat kein anderer Anbieter mal. So, warum soll ich die Weltneuheit nicht schützen? Warum soll ich nicht schützen, dass etwas, was ein Feature Set, was da drin ist, dort wirklich, wir sind darum überlegt, ob man sogar vielleicht ein Patent darauf anmelden. Also so weit geht es ja schon. Dass man das quasi mit drin hat und da sagt, ja, das will ich ja frei rausgeben. Das ist eher eine Mindset-Diskussion. Es gibt Leute, die aber.

SPEAKER_00 42:30

Ich glaube, es ist legitim in einer wirtschaftlich getriebenen Welt, dass man seine Intellectual Property erstmal schützt. Das ist, glaube ich, wirst du wenige Menschen finden, die dem, die dir widersprechen. Trotzdem kann man sich natürlich die Frage stellen, gebe ich nicht Teile meiner Software, stelle ich die nicht Open Source zur Verfügung? Das ist ja nicht eine binäre Antwort, dazu sagst du, entweder gibt es da eine ganze Software frei oder du kannst ja auch Teile, du kannst ja auch Bibliotheken, manche Bereiche. Wäre das eine Option für euch?

SPEAKER_01 43:04

Wir könnten das machen, sind aber, glaube ich, wir sind dazu noch nicht bereit. Da bin ich ganz ehrlich. Ob das halt eher ein wirtschaftlicher Gedanke wäre oder jedem, wo wir sagen, die, ich bin auch offen da, die Open Source Community kopiert sowieso von uns. Die gucken sich die Features an, die gucken sich die Release-Notes an, der wird schon fleißig kopiert. Keine Angst. Die kopieren schon so, die machen Reverse Engineering ohne Ende. Das ist schon erschreckend teilweise. Ich sehe das in den Issue-Notes, in den Milestones, von den Projekten, die wir auch analysieren. Dann drinnen denken wir, okay, warum nennt ihr die Variablen vielleicht gleich, wenn ihr vielleicht eine Demo beantragt habt? Warum nennt ihr das so und so? Das ist schon teilweise wirklich erschreckend. Also deswegen passiert es einen gewissen Teil schon. Da frage ich mich, okay, wenn die Open Source Gemeinde uns versucht, immer nachzuahmen als Beispiel, dann habe ich so ein bisschen einen Fadenbeigeschmack, weil kopieren, ne, ist kopiert auf der einen Seite Lob und Anerkennung zugleich, auf der anderen Seite ein Ärgernis. Das war.

SPEAKER_00 44:01

Und was wir bei der ganzen Diskussion vielleicht auch noch bisher außen vor gelassen haben, eines der größten Assets der modernen Zeit ist ja tatsächlich Open Source. Weißt du, wovon ich rede?

SPEAKER_01 44:12

Ja, fairerweise, also wenn du dir Linux anguckst als Beispiel mal, also wenn man das nimmt, dass das de facto-Standardbetriebssystem für alles, was es gibt, von der Drohne bis zum Apple, hat es ja auch als Untergrund so.

SPEAKER_00 44:24

Der Point daran dachte ich jetzt gar nicht, hat was anderes noch im Sinne.

SPEAKER_01 44:27

Sag mal, sag mal. Bitcoin. Bitcoin. Ah, Bitcoin. Oh. Bin ich so ein bisschen raus. Wie funktioniert, also Bitcoin, weiß ich, wie es funktioniert, ist auch Open Source, diese ganze Stack.

SPEAKER_00 44:37

Ich bin nicht bewandert da drin, wie jetzt Commits passieren können oder was auch immer. Theoretisch kannst du den kompletten Source-Code nehmen, du kannst ihn forken, du kannst neue Modelle, Derivate erstellen und selber machen. Und du kannst, glaube ich, auch, du kannst, glaube ich, auch selber committen. Die Miner müssen das halt annehmen, was da passiert. Und das ist dann der große Knackpunkt. Aber im Endeffekt ist dieses ganze System Open Source. Und quasi auch jetzt die große Gegenthese zu dem, also was, was wir eben besprochen haben, ist wahrscheinlich auch für 95 Prozent der Fälle wahr und es gibt ein paar Ausnahmen am Markt, die das Gegenteil bewiesen haben. Du hast jetzt Linux genannt, das ist eins, ich sage Bitcoin ist ein anderes. Und viele anderen der Kryptowährungen oder der Digital Currencies, die es da gibt, die funktionieren auch nach einem ähnlichen Prinzip. Nicht alle, aber viele.

SPEAKER_01 45:30

Wenn du die Community fragen würdest, also die Becoming City Community, dann würde die wahrscheinlich, und würdest durchgehen, würdest du auch feststellen, dass die meisten gar kein Open-Source-Produkt anbieten?

SPEAKER_00 45:40

Mit Sicherheit nicht, nee. Aber wann ist denn Open Source dennoch die richtige Entscheidung? Also wenn wir sagen, vielleicht gibt es ja doch den ein oder anderen Use Case und der ist dann brutal und für den lohnt sich das.

SPEAKER_01 45:53

Ich würde sagen, wenn es der Menschheit dient. Das ist eine ganz plakative Antwort. Nehmen wir an, du baust ein Produkt, das zum Beispiel Energiemessung ermöglicht, das eine Art der Wohltätigkeit oder vielleicht sogar Commodity, also ein Commodity-Feature. Allgemein, das ist so allgemein, dieser Feature-Bereich, dass du quasi sagst, das braucht eigentlich jeder, dass du das mit reinnimmst. Oder auch fairerweise sagen, es ist eine Person, es kann auch ein Einzelprojekt ja sein, ne, es ist eine Person, die dieses Projekt beherbergt, die keinerlei wirtschaftliches Interesse hat. Das muss man fairerweise sagen. Ein Wirtschaftsunternehmen hat immer wirtschaftliches Interesse, auch da, ne, klar. Aber der Hintergrund ist, wenn eine Einzelperson sagt, ja, das mache ich jetzt einfach so, just for fun, ich probiere es aus, dann wäre das auch ein Punkt. Entgegen noch dieser Themen wie Gutes für die Menschheit. Es gibt ja auch viele Gesundheitsprodukte, also Medizinprodukte sind häufig auch kein Open Source, aber es gibt bestimmte gesundheitliche Produkte, die sind mittlerweile für alle frei produzierbar über die Zeit, nach Ablauf des Patents und so weiter. Es gibt Gründe dafür, dass quasi die Menschheit dann prosperieren kann von bestimmten Produkten. Das würde ich als ganz, ganz großen Tenor sehen.

SPEAKER_00 47:07

Gerade im Gesundheitsbereich wäre es ja, ich weiß, das wird nicht passieren, zumindest nicht in Deutschland, aber wenn du mal guckst, Beispiel wieder Bitcoin, da steckt so viel Geld dahinter. Und das ist ein frei zugängliches System, wo jede Zeile des Source Codes bekannt ist, und was seit über einer Dekade oder 15 Jahren jetzt mittlerweile am Markt ist. Und es funktioniert. Und es ist nicht exposed. Und es ist, ne, und theoretisch kann man sowas auch machen mit einer Open Source zur Verfügung gestellten Software. Und klar, es geht ja nicht um Menschenleben, aber es geht halt auch um Geld, was im Endeffekt so das Öl der gesamten Menschheit irgendwie ist. Keine Ahnung, es war jetzt kein politisches Statement, aber das ist so jetzt gerade die erste Analogie, die in meinen Kopf gekommen ist.

SPEAKER_01 47:59

Es gibt eine andere. Warum ist alles, was nicht public money ist, Public Code? Diese Diskussion führe ich schon ein bisschen jetzt aktuell mit Schleswig-Holstein und solchen Sachen, die jetzt aufkommen. Das ist eine These, die im Raum geworfen wird. Wenn der Steuerzahler dafür bezahlt, muss es doch Open Source sein. Siehst du das auch so? Gute Frage. Also das Gegenteil, weil es jetzt auch ganz aus dem einfach so heraus, ich weiß es auch nicht so ganz, weil es gar nicht so einfach zu warten.

SPEAKER_00 48:30

Es gibt einen Teil von mir, der instinktiv sagen würde, ja, aber ich glaube genau dann, wenn der zweite Teil, also der Grundgedanke hinten dran ist, was alles, was der Staat tut, sollte eigentlich der Gemeinheit dienen. Von daher wäre der erste Reflex zu sagen, ja, dann sollte natürlich auch Software, die der Staat irgendwo herstellt, einen Auftritt gibt, sollte erstmal Open Source sein. Ist es allerdings realistisch, dass das passiert? Nein, und zwar auch aus vielen Gründen, unter anderem natürlich auch aus sicherheitsrelevanten Gründen, macht das dann keinen Sinn. Und deswegen, wenn ich anfange drüber nachzudenken, dann denke ich mir, es ist, vielleicht wäre das schön, wenn es so wäre, aber es ist völlig unrealistisch, dass das passiert und es sollte wahrscheinlich auch nicht so passieren. Ob man das für Einzelfälle sagen kann, ja. Und ich würde die Frage nochmal hinten dran stellen: es ist ja Unterschied, ob ich sage, es soll die Software Open Source sein oder soll ich die Daten, die der Staat sammelt, stelle ich die öffentlich zur Verfügung. Das sind ja nochmal zwei verschiedene Diskussionslayer, die wir da haben.

SPEAKER_01 49:31

Deswegen, also diese Diskussion läuft gerade und man sieht ja dran, schwierig dieses Thema Souveränität, Open Source da im Spagat überhaupt zu beantworten ist, der Staat beispielhaft, spendet ja gar kein Geld in die Open Source Communities rein. 80% der Tätigkeit in einem Open Source Community-Bereich ist Arbeitszeit. Das ist nicht der Betrieb von dem Produkt oder die Themen, sondern da sitzen Menschen, wie du und ich, drin und arbeiten an dem Produkt. Egal wie, menschliche Zeit in ihrer Freizeit und so weiter. Und die größten Produkte, die es gibt, da kann man dann sagen, man muss einen Standard vielleicht am Markt etablieren. Ist ja Open Source ist beliebt, weil es kostenlos eine Nutzung ist. Starke Marktverbreitung. So machen Google, Microsoft und so weiter, sind die Hauptmaintainerunterstützungen immer Mitarbeiter. Immer. Kubernetes, bei Google zum Beispiel, krisiges Thema. Bei Microsoft müsste ich überlegen, da gibt es aber auch drei, vier große Projekte Minimum, die die über die Jahre dann weitergeschliffen haben, wo man das quasi dann auch sieht. Und dann sagt, alles klar, die großen Player, die sind eigentlich die größten Unterstützer von Open Source, obwohl sie, das kommt der Trugschuss ja, eigentlich die größten Anbieter von Closed Source sind. Das ist fast so passt widersprüchlich, aber ist genau so, wie es ist.

SPEAKER_00 50:50

Ja, das stimmt. Wir sind jetzt auch von der eigentlichen Diskussion um die digitale Souveränität ein bisschen abgekommen. Open Source sollte ein Teil der Diskussion sein. Und du siehst, wir sind jetzt schon sehr stark im Bereich der persönlichen Meinung unterwegs. Und die ist natürlich auch von verschiedenen Faktoren abhängig. Also ich bilde mir auch nicht ein, da eine hundertprozenti feste und firme Meinung an jeder Stelle zu haben. Und lass mich da auch gerne vom Gegenteil überzeugen. Trotz allem, um das Thema mal irgendwie abzuschließen, wie bewertest du abschließend digitale Souveränität? Ist das ein Luxusthema? Ist es Pflicht für die Unternehmen? Und was passiert dann mit den Unternehmen, die langfristig wirklich, die stark abhängig bleiben?

SPEAKER_01 51:32

Also digitale Souveränität ist kein Luxusthema, sondern ein Pflichtthema. Egal, man muss sich dann unterscheiden, welche Aspekte geht man an? Diese einzelnen Aspekte, geht man es technologisch an, guckt man sich politische Risiken an, wenn man Risiko als Kernthema hat oder Kosten auch, die dann drin sind. Und vor allem, was wir heute noch gar nicht angesprochen haben, war ja Lieferkette. Wie ist man in die Lieferkette betroffen? Wie muss ich es analysieren? Also es hat sehr viele Aspekte, aus meiner Sicht auch, die in den Security-Bereich hineinragen. Und Personen, die sich überhaupt nicht mit Security-Risiken und Kosten beschäftigen, ist ja fast eine Pfandfrage. Was wird mit dem passieren? Die werden Opfer einer Cyberattacke, die werden Opfer von sich selbst, von Geschäftsprozessen, die schlecht laufen, von schlecht laufender Digitalisierung zu einem Teil, weil es halt in diese Bereiche hineinragt, fairarbeit.

SPEAKER_00 52:23

Ja, guter Punkt. Ich habe noch ein Thema, das mir auch sehr auf der Seele brennt, auch vor dem Hintergrund, dass du CTO bist, ich bin CTO, wir arbeiten beide viel mit anderen CTOs zusammen oder haben regelmäßigen Austausch da drin. Wie sieht denn aus deiner Sicht die aktuelle CTO-Realität aus? Was sind aktuell die wirklich wichtigen Technologieentscheidungen, die die CTOs betreffen? Oder ist es am Ende des Tages alles immer nur AI?

SPEAKER_01 52:53

Also KI, AI ist sicherlich ein Treiberthema. Also man muss sich damit beschäftigen. Vor dem KI-Thema liegt aber das Datenthema. Ich kann das immer als übertriebenen Punkt bringen, wenn Produktauswahl bei uns ist. Großteil der Kunden hat ja noch Excel-Listen im Einsatz oder auch technologieaffine Unternehmen oder haben die Prozesse sogar manuell gemacht oder haben ein schlechtes Vorsystem zum Beispiel. Jetzt ist es so, CTOs müssen entscheiden, ob sie, wenn sie KI einsetzen wollen als Beispiel, die Datengrundlage haben. Also die Vorbedingung, wie sind meine digitalen Prozesse? Wie bin ich automatisiert? Und mit der nötigen Datenqualität kann ich dann Themen umsetzen, wie zum Beispiel ein KI-Thema. Deswegen ist KI nur ein Treiberthema für die sowieso schon verschleppte Digitalisierung und Transformationsdiskussion. Das ist sowieso schon ein Grundthema, was dann da ist. Jetzt muss man es eh machen. Wenn ich jetzt KI nutzen will, wenn ich da in den Bus einsteigen möchte, dann muss ich irgendwie in der Lage sein, das Ticket zu ziehen. Habe ich die Vorbedingungen, aber nicht um mein Ticket zu bezahlen, kann ich da nicht einsteigen in den Bus und bin dann gefangen letzten Endes. Ich kann natürlich ein KI-Tool ausrollen, habe aber gar keinen Nutzen, weil Daten, Prozesse, Schrott sind, weil es überhaupt nicht funktionieren kann, etc. So, das heißt, KI als Thema, aber eigentlich um Transformations- und Automatisierungsthemen schon in Klärung zu haben oder schon hoffentlich geklärt zu haben. Das sehe ich als wichtigsten Punkt. Zweiter Aspekt, den CTOs aktuell umtreiben, ist das Thema, was mache ich eigentlich bei all diesen, wenn man KI Nummer nimmt, bei den KI-Themen, was mache ich denn jetzt eigentlich mit welchem Modell? Mache ich denn jetzt Opus? Mache ich denn das neue 5.4 von OpenAI? Mache ich jetzt als bei, oder 5.3, ich bin gerade unsicher, als zum Beiben, mache ich denn jetzt ein anderes Modell, ein Open Source Modell und so weiter. Was ist denn der nächste geile Scheiß an der Straßenecke? Agentic Web, Agenten, ist es jetzt der autonome Bot, der irgendeinen virtuellen Container steuert und so weiter. Also der CTO muss sich klar werden bei diesem KI-Thema, dass er iterativ vorgeht, nicht alles parallel machen kann, ähnlich bei den anderen Themen, die man ja auch in seinem Team hat, um dann quasi die in der richtigen Reihenfolge das anzugehen. Weil das ist so schnelllebig das Thema, man muss beginnen. Basics schaffen, Daten, Prozesse strafziehen, KI einführen und dann Stück für Stück natürlich überlegen, wo bringt mir das was. Weil, du weißt ja, wir hatten diese Personas, Technologie, Hut, Businesshut, People-Hut und gerade der Businesshut, der Business-Faktor, der wird sehr, sehr wichtig sein.

SPEAKER_00 55:33

Du hast das gerade schon sehr gut formuliert. Ich sehe das ja tatsächlich auch so und ich merke mit es, ich treffe aktuell nahezu keinen CTO, der nicht die gleiche Herausforderung hat. Und die verstehen alle, also eins mal vorne weggenommen, ich glaube, die verstehen alle AI bis zu einem gewissen Grad. Also nicht jeder in der, in der in super Tiefe, aber das brauchen sie auch gar nicht. Aber sie haben alle die aktuell die Komplexität. Also aktuell ist AI ein zusätzlicher Komplexitätslayer, der auf die aktuelle Aufgaben oft noch draufkommt. Das soll natürlich perspektivisch alles einfacher machen, tut es aber aktuell nicht. Aktuell erhöht es eher die Komplexität, weil du hast ja trotzdem noch die alte Erwartungshaltung, was deine Lieferung angeht. Du hast Engineering-Prozessor, für die du verantwortlich bist, du hast Teams, Organisationen, deinen Legacy-Stack und so weiter und so fort. Das ist alles immer noch da. Und jetzt kommt obendrauf nochmal der neue Layer AI und die Erwartungshaltung mit dazu, von allen Seiten. Mach das bitte schnell. Wir müssen nämlich schneller innovieren, wir müssen schneller werden. Du brauchst, du musst irgendwie doppelte Geschwindigkeit aus deinen Teams rausholen. Und dann sitzt der da und denkt sich, naja, ich habe sowieso meine ganzen Arbeitspakete von vorher, die oder Verantwortlichkeiten, die ich vorher habe. Dazu soll ich jetzt auch noch das AI-Thema lösen. Und jetzt kommt ja jede Woche die neue nächste Sau, die durchs Dorf getrieben wird. Plus auch noch ein Toolstack, der halt mittlerweile richtig groß geworden ist, aus dem ich irgendwie anfangen kann, mir was zusammenzubauen, was für meine Organisation funktioniert. Und in diesem Podpuri ist gerade ganz viel Uncertainty, also Unsicherheit drin. Und nahezu alle haben hier sehr, sehr große Fragezeichen. Und zwar, das ist kein intellektuelles Thema, das ist kein Wissensthema, sondern es ist rein ein, da gibt es gerade so schnell so viel, ich weiß gar nicht, wo ich anfangen soll und ich weiß auch gar nicht, was der Impact ist und ich weiß auch gar nicht, wie ich es das Messe und so weiter.

SPEAKER_01 57:27

Ich hatte in den Vorfeld ja nochmal ein paar Folgen auch von dir angehört im Podcast. Es ist wirklich erstaunlich, wenn man dann fragst, ne, es gibt dann fast immer die legitime KI-Frage, ne? Und alle haben dann so: man muss es in die richtige Reihenfolge bringen und dann abarbeiten. Es gibt gar keine andere Lösung mehr mittlerweile.

SPEAKER_00 57:44

Und das ist die richtige Reihenfolge, ne? Das ist ja das Ding.

SPEAKER_01 57:46

Ja, ja, genau. Die richtige Reihenfolge ist das Schwierige daran. Ich würde sagen, wenn man die Reihenfolge bewertet als Thema, immer das, was den Business am meisten bringt. Weil das Business, der Geschäftsführer, würde dich ja dann fragen, ja, ja, okay, wir haben jetzt Celd investiert, Mensch investiert, Tech investiert, wie auch immer, dich auch ein paar Strategien umgebaut dafür. Und dann wird dann fragen, okay, was bringt uns das jetzt? Weil das Geschäft finanziert das ja auch so ein bisschen. Gegenseitige Befruchtungsthematik. Und da muss es irgendwas geben. Wenn du was investierst und sagst, du brauchst fünf Jahre, das reinzuholen, das wird in den meisten Fällen nicht funktionieren. Aber wenn ihr sagst, hier, was würde euch bringen, einen Telefonassistenten reinzubringen? Also Kostenoptimierung. Was würde euch bringen, als Beispiel, ähm, keine Ahnung, irgendwie nicht.

SPEAKER_00 58:35

Ich weiß nicht, ob der CTO jetzt in den meisten Unternehmen dafür darüber entscheidet, ob die einen Telefonassistent reinbringen mit der AI-Man.

SPEAKER_01 58:41

Nein, nein, nein, also fairerweise, aber wenn er in der Business, Business-Seite Vorschläge machen kann, also ich kenne viele Organisationen, in denen der Tech-Bereich quasi auch viele Vorschläge machen darf für Innovationsideen. Da kann es dann schon sein. Ob das dann durchgesetzt wird, keine Ahnung. Das kann der Geschäftsführer ja selbst entscheiden, der Unitleiter, wer auch immer, also wie die Struktur hat es, ist ja unterschiedlich. In dem DAX-Konzern wird der CTO nur Tech machen und vielleicht auch sogar nur Tech in einem Fachbereich, dem er untergeordnet ist. Da kann es natürlich sein, da gibt es auch Einzelthemen, die man natürlich hätte.

SPEAKER_00 59:13

Wie lange gibt es denn jetzt eigentlich An-Tech-Systems?

SPEAKER_01 59:16

Dieses Jahr die GmbH zehn Jahre.

SPEAKER_00 59:21

Ihr habt ja auch Legacy-Stack, ne? Ihr seid also auch, euer Codebase ist an manchen Teilen bestimmt zehn Jahre alt. Das muss natürlich alles immer noch gemanagt werden. Wenn ihr natürlich jetzt eine kleine, eingeschworenene Gemeinschaft habt, ihr habt das mit Sicherheit gut im Griff. Trotz allem, wie gehst du als CTO mit Legacy um? Und an welchen Stellen denkst du darüber nach, AI einzusetzen, um Hand anzulegen?

SPEAKER_01 59:49

Es gibt zwei bestimmten Klassenkonstrukten und Themen natürlich. Also es gibt Punkte, wo man sagen kann, also kritische Themen, ne? Ob es jetzt die Darstellung ist von irgendwelchen Dingen, wo man sagt, hey, das hat jetzt gar keine Sicherheitsauswirkung, ne? Da würde ich sagen, da kann man Legacy schleifen lassen. Bin immer mit dem Legacy, das ist ja Vermächtnis, für mich ist das deutsche Wort positiver belegt als das englische, weil Vermächtnis ist für mich positiv. Aber grundsätzlich als Idee, dass man dann sagt, alles, wo keine Security betroffen ist, ist der Legacy-Wert geringer zu priorisieren als in Bereichen, wo Security Relevanz besitzt. Das ist ganz klar. Das habe ich aus all den Jahren den vielen Projekten immer mit drin. Das heißt zum Beispiel etwas, wo Daten gespeichert werden, wo Daten abgerufen werden, wo zum Beispiel eine Logik drin ist für die Selektierung von Informationen und so weiter, da musst du auf jeden Fall eher dran sein. Ob du dann eine Visualisierung den heißesten JavaScript-Stack brauchst, ob du in bestimmten anderen Bereichen das benötigst, das ist eine ganz andere Frage und muss individuell vom CTO beantwortet werden, meiner Meinung nach, weil er sein Produkt am besten kennt. Viele, wenn du eine App machst zum Beispiel, viele Dinge dort zum Beispiel werden ja per Automatik schon geprüft. Du hast da teilweise Rahmenbedingungen, die das dann schon zum Beispiel abfedern kannst, musst die Google API einsetzen, die neue, hast nur gewisse Rahmenzeiten, wird automatisch weggeschmissen, aus dem App Store und so weiter. Da hast du dann schon einen anderen Druck nochmal da. Aber für dieselbe eigenen Systeme im Besitz würde ich eine Prioritätsliste setzen. Machen wir ja auch. Wir haben in der Reihenfolge, was muss getan werden. Wir haben keine Outdated-Pakete, also sprich betriebssystemseitig, Systeme, die wir selber anbieten. Pakete intern. Kennen wir genau die Lifetime, wissen, wann was ausläuft, wird dir alles kundgetan, wenn wir was intern einsetzen. Und für eigene Dinge, wo wir dann drin sind, haben wir ganz klare Ziele besetzt. Das ist das Gute. Und das würde ich auch jedem empfehlen. Setzt die Ziele, damit ihr wisst, wann ihr was machen müsst. Und damit ihr nicht durch die Predoule kommt, wie jetzt bei einem Heise-Artikel, wo irgendein Paket oder ein Skriptprotokoll oder was auch immer dann am Tagesende euch in die Predolie bringt. Noch was zu machen zu dem Tagesgeschäft, zu dem Plan dazu.

SPEAKER_00 1:02:04

Ja. Du hast es auch richtigerweise gerade in das richtige Licht gerückt. Du hast nämlich völlig recht. Interessanterweise ist im Tech-Bereich das Wort Legacy negativ behaftet, dabei ist es eigentlich eher ein positiv konnotierter Begriff, also in den allermeisten anderen Fällen. In dem Moment, in dem du das sagst, ist mir das auch erst nochmal richtig bewusst geworden. Da steckt sehr viel Wahrheit dahinter.

SPEAKER_01 1:02:26

Legacy wird als negativer Begriff terminologiert, aber ist eigentlich, ja, wenn du Vermächtnis siehst, Vermächtnis ist ja eigentlich das total cool. Kriegst du im deutschen Sprachigraum kriegst du eine Villa, dein Eigentum, ne? Und Vermächtnis im Sinne im geistigen Charakter betrachtet, ist es schon positiver, finde ich.

SPEAKER_00 1:02:46

Wie, was sind denn, was sind denn aber trotzdem typische Fehlentscheidungen im Umgang mit Legacy? Was siehst du da?

SPEAKER_01 1:02:54

Fehlentscheidung Nummer eins ist, dass die Legacy keinen Einfluss aufs Geschäft hat. Wenn der CTO denkt, ja, da muss ich mich ja gar nicht drum kümmern. Fehler Nummer eins. Es gibt so Menschen, die das wirklich sagen, die haben dann die ältesten Browserversionen, die ältesten Systeme am Start und sagen, ja, muss ich mich nicht drum kümmern, lasse ich einfach laufen. Isoliere ich vielleicht das System und kümmere ich mich irgendwann vielleicht dann da drum. Also braucht bei Legacy immer ein Enddatum. Immer. Egal wie das ist. Das kann auch nächstes Jahr sein. Das ist ja nicht schlimm. Hängt vom Thema ab, der Risikoaffinität und so weiter. Aber auf jeden Fall etwas, wo ich sage, hier, da muss auf jeden Fall ein Datum dran. Punkt 1.

SPEAKER_00 1:03:34

Ja, und ob es businessrelevant ist, ob du es jetzt gerade anfasst oder nicht. Wenn du halt Komponenten hast, die jetzt erstmal, die du die erst, also aus keinen sicherheitsrelevanten Kriterien du anfassen musst oder nicht aus businessrelevanten Kriterien anfassen musst, warum solltest du die jetzt anfassen, wenn nicht aus genau einem dieser beiden Gründe? Wenn die nicht gegeben sind, dann kannst du es auch noch zehn Jahre liegen lassen. Refactoring, Thematik, ist es ja häufig.

SPEAKER_01 1:03:59

Wann refactorst du den Code, den du gerade vor dir siehst oder das Paket und sonst was.

SPEAKER_00 1:04:03

Dann, wenn ich ihn sowieso anfassen muss. Und nur dann. Ist häufig eigentlich die einfachste Antwort. Und nicht, wenn ich jetzt schon wieder überlege, naja, aber wenn das Feature mal funktioniert und das, dann baue ich das schon mal ein, weil dann habe ich das irgendwann schon gehabt. Und das sind alles so What-If-Szenarien, die dann vordenken oder versuchen vorzudenken, was in einem Jahr von jetzt an der Fall ist, was aber vielleicht gar nicht eintreten wird.

SPEAKER_01 1:04:25

Was ich persönlich immer als interessante Diskussion bringe, ist, welche Entwickler können beides? Welche Entwickler können Code schreiben und den Altcode-Refektorn? Theoretisch müsste es ja jeder kennen, aber du musst überlegen, Projekte, hast du selber schon gesagt, laufen länger, du hast verschiedene Stacks, verschiedene. Es kann ja auch sein, dass du auf einen Stack gehst, der vielleicht Teile von einer anderen Library auch, von der Idee übernehmen und so. Und da brauchst du die richtigen Leute, weil du auch sagtest, welche Leute braucht man denn vielleicht für ein Team? Warum ist das Team so klein? Und da sage ich immer, es müssen halt die richtigen Leute sein. Das sind Leute, die in der Regel ein gewisses Profil mitbringen. Die müssen in der Lage sein, Alt-Code, den sie vielleicht sogar selbst geschrieben haben, wegzuwerfen. Also vielleicht selbst der Eigentümer sind von dem Code. Das ist ja auch eine Eigenschaft. Und müssen in der Lage sein, diesen Code in die Neuzeit zu transformieren. Alleine mit KI oder mit sonstigen Produkten, wie auch immer. Das ist ja nur eine Möglichkeit. Deswegen ist diese Teamgröße, nur mit den richtigen Personen zu besetzen, in den richtigen Rollen. Und das ist ja diese Schwierigkeit, ab der gewissen Größe wird nicht die richtige Position mit der richtigen Rolle und dem richtigen Menschen besetzt. Das ist nicht so. Es ist ja dann wie so eine Art Puzzle, baust dann zusammen und umso mehr Puzzle-Stellen du hast, umso ungenauer wird das.

SPEAKER_00 1:05:34

Was sind denn aber, um es mal konkret zu machen, Stichwort Entscheidungslogik, also wie balancierst du das denn? Also zwischen Thema Stabilität, Innovation, Geschwindigkeit. So, das ist ein Balanceakt permanent. Ich glaube, da unterscheidet sich auch dann der gute vom weniger guten CTO. Was macht dich denn dann zum guten CTO an der Stelle?

SPEAKER_01 1:05:53

Was ist in dieser Frage mit Geschwindigkeit gemeint? Liefergeschwindigkeit. Okay.

SPEAKER_00 1:06:00

Also im Grunde. Meine läuft es ja darauf immer hinaus. Ja, gute Frage. Du kannst auch die Geschwindigkeit des Systems nehmen. Nee, ich meine, die Geschwindigkeit, mit der du neue Dinge liefern kannst, ob du das dann Lead Time, Cycle-Time nennst oder was auch immer.

SPEAKER_01 1:06:15

Also im Grunde genommen ist Stabilität das wichtigste Gut. Wenn ich jetzt mal die drei Faktoren, nehmen wir mal dieses Dreieck, Stabilität gewinnt gegen alle beiden Faktoren. Meiner Meinung nach sowieso. Das heißt, wenn das System nicht stabil ist, kriegst du Bugs rein und so weiter. Das heißt, der Punkt ist am höchsten zu gewichten. Innovation und Geschwindigkeit, boah, spannende Frage. Ist derjenige besser, der schneller liefern kann oder der innovativer ist? Puh.

SPEAKER_00 1:06:42

Ja, das ist natürlich eine unfaire Frage, weil die kannst du gar nicht beantworten. Weil die Innovation ist ja, du kannst Innovationen nicht richtig planen, also du kannst sie nicht planen in dem Sinne, du kannst nicht wissen, was ist jetzt deine tatsächliche Innovation, die erfolgreich sein wird. Du kannst versuchen, Innovationskulturen, Innovationsprozesse zu schaffen. Und im Rahmen dieser kannst du versuchen, eine Reihe von Innovationsinitiativen zu starten und von denen gehen halt 19 von 20 gehen den Bach runter und eine funktioniert. Welche von den einen das sein wird, you don't know. Und das ist natürlich dann der unfaire Teil, weil du weißt nicht. Und diese das Problem ist so, du musst ja, die Entscheidung zur Innovation hat immer einen Impact auf die Lieferung von anderen Sachen.

SPEAKER_01 1:07:25

Ja, genau. Nehmen wir mal an, du machst einen heißen Scheiß. Irgendwas kommt rein. Alle Kunden wollen das jetzt. Kann ja sein, das ist sofort ein E-Fächer. Du liefst aus und hast, oh, das ist geil, wir merken ja Markt, alle fragen jetzt danach. Dann musst du natürlich auch deine. Die Stabilität bleibt erhalten, unverändert, immer, auch bei dem Thema. Aber die Geschwindigkeit, wenn man sagt, okay, dann müssen wir vielleicht diese Rollout-Geschwindigkeit, wenn man diesen Faktor nimmt, in eine Richtung drücken, das Produkt, also wenn man den Produkt-Owner nimmt, der muss ja nicht der Techniker sein, der muss dann entscheiden, okay, wir sehen, dass der Markt so und so das verlangt, dann müssen wir in diese Richtung das verändern, dann muss der Release umgehangen werden, die Features, das, was das Business verlangt, gleich in diese Richtung, weil Technik alleine ist ja in dem Thema nicht maßgebend, sondern du musst eigentlich ist die Frage, du musst stabile Innovationsfähigkeit haben und das in einer Geschwindigkeit, die der Markt mit den passenden Anforderungen braucht, wenn man es mal in einem Satz zusammenfasst. Aber Geschwindigkeit orientiert sich dabei dann maßgehend an dem Business Need, nicht am Technik-Need. So würde ich es zusammenfassen.

SPEAKER_00 1:08:28

Gehe ich mit. Gehe ich mit. Sehr gut. Vielleicht noch abschließend dazu, bevor wir zu den Rapid-Fire-Fragen kommen. Wenn du heute als CTO neu starten würdest, gäbe es irgendwas, was du ganz bewusst anders machen würdest? Auch ganz schwierig.

SPEAKER_01 1:08:43

Also Fehler sind gut. Das gab es erstmal als Punkt dahingehen. Das heißt, ohne die Fehler hätte ich bestimmte Entscheidungen nicht so getroffen. Also heißt, wenn ich überlege in meiner Vergangenheit, was hätte ich damals anders gemacht, dann würde ich sagen, dass ich mich wahrscheinlich früher mit Künstler, also ich als Rolle, früher mit künstlicher Intelligenz lieber hätte beschäftigen sollen. Okay, fairer Punkt, ja. Also früher als, ich habe mich schon vor 2022 damit beschäftigt, auch mit Big Data, als es noch so hieß, mit Mining und so Sachen. Also vor 2015, 2014.

SPEAKER_00 1:09:24

Welche Fähigkeit braucht man in den nächsten Jahren? Was wird am meisten unterschätzt gerade?

SPEAKER_01 1:09:29

Ich würde sagen, Geschäft und Innovation zu verbinden. Und das mit den aktuellen Markttrends zu kombinieren in seinem Produktbereich. Das heißt, wir übertragen, wir müssen erkennen für den Bereich der Inventarverwaltung, wie wird inventarisiert in der Zukunft? Was für Komfortfeatures, weil darum wird es gehen, benötigen die User in Zukunft? Was wollen die haben? Was könnten Möglichkeiten sein? Und was ist dennoch weiterhin ein Klassiker, den man ewig lang supporten muss bis in die Legacy-Ewigkeit? Das ist aus der Produktsicht immer ein spannender Punkt, weil ich argumentiere eher aus Produktsicht. Weil generell, wenn man alle Themen betrachtet, würde ich sagen, wie verändert sich eigentlich unser gesamtes digitales Leben, wenn man das als Frage mal aufhört. Das würde ich sagen, man muss eine Vorstellung davon haben, offen sein, dass wir in den nächsten X Jahren, mal fünf bis zehn Jahre, die hatten das ja schon vorher so, ne, aber jetzt noch stärkere Veränderungen haben als jemals zuvor.

SPEAKER_00 1:10:28

Ich überlege gerade, was meine Antwort auf die Frage wäre. Und ich glaube, ich bin gerade dabei, an dem Punkt, die unterschätzendste Fähigkeit und die wichtigste Fähigkeit in den nächsten Jahren wird sein, den Impact von AI zu antizipieren und sich darauf einzustellen. Weil ich glaube, das ist an vielen Stellen noch gar nicht, ja, wir denken alle darüber nach, wo wir AI einsetzen können, aber ich glaube, das Ausmaß dessen, was für einen Impact das haben wird, an welchen Stellen und wo es wirklich auch nochmal zusätzlich einen disruptiven Charakter hat für bestimmte Themen, der ist noch gar nicht so ganz klar. Und der ist uns allen vielleicht noch nicht so ganz klar. Aber hier die Fähigkeit zu haben, das dort vorauszudenken, mitzudenken, vielleicht vor der Welle zu sein und nicht nur hintendran, wenn man eigentlich schon wieder 20 neue Tools und Ereignisse eingetreten sind, das ist hier wirklich ahead of the game zu bleiben, das ist eine wichtige Eigenschaft in meinen Augen.

SPEAKER_01 1:11:23

Kannst du dir vorstellen, dass du einen Haushaltsroboter hast, der mit KI gesteuert ist in den nächsten zehn Jahren, was ein Szenario ja ist? Frag mal andere Leute dazu. Ich bin mal sehr gespannt, wie die Diskussion verläuft. Ob die wollen, dass ein Roboter im Haus rumläuft, der alles autonom macht, der die Dinge tut, der vielleicht sogar kochen kann.

SPEAKER_00 1:11:40

Ja, das eine ist die Akzeptanz, genauso wie es halt irgendwie vor wann gab es die Google Glasses, das war halt Zero Akzeptanz im Markt für ein Produkt, was aber damals auch schon hat angefangen zu funktionieren und das halt einfach noch nicht im Markt angekommen ist. Ich glaube, das wird sich auch ändern, aber da sind wir vielleicht, da sind, da denken wir vielleicht der Zeit voraus, aber vielleicht ist auch genau das auch ein bisschen notwendig. Woran arbeitest du aktuell selbst?

SPEAKER_01 1:12:05

Also jetzt autonom von N-Tech.

SPEAKER_00 1:12:08

Autonom von N-Tech, du als Alexander und an was. Ich bin ehrlich, ich gibt es den Alexander außerhalb von N-Tech Systems.

SPEAKER_01 1:12:15

Ja, weil es ist ja nicht technologisiert. Ich weiß, ob das da so passend immer ist. Also ich bin jemand, der weiß, ich mache ja auch viel Sport. Also ich habe meinen eigenen Indoor-Cycling-Kurs immer, auch heute wieder, mit einer Gruppe. Also ich mache viel, versuche immer viel Sport einzubauen, meinen Lebensalltag, damit ich so ein bisschen rauskomme und ein bisschen da auch antizipieren kann. Das heißt, immer mit der Gruppe, sind verschiedene Gruppen, verschiedene Kurse, die ich gebe, da rein die Zeit mit der Familie viel weg. Ich mache viel dann weg vom Computer und so weiter. Ich mache fast nichts am Rechner, wenn ich irgendwie weg bin von der Rolle. Dafür arbeite ich natürlich auch viel in der Rolle. Und das mache ich aktuell. Ansonsten Thema vielleicht, womit ich mich gerade beschäftige, ist, weil ich hier das Netzwerk neu aufsetzen muss und so weiter, vielleicht die Thematik Storage, Netzwerk, Abspeicherung etc. Mache ich es wirklich lokal, würde meiner DNA ein bisschen entsprechen. Mache ich einen Teil dann doch über die Cloud. Ich weiß es noch nicht. Also solche Dinge halt, ne, die reingehen. Nachdem ich letztes Jahr fast meine gesamte private Zeit bei der Familie mit Haus- und Wohnungsumbauten und so zu tun hatte, ist das eher mal ein entspannteres Thema.

SPEAKER_00 1:13:24

Ich verstehe. Sehr schön. Alex, dann lass uns mal zu den Rapid-Fire-Fragen kommen. Ich glaube, als wir damals angefangen haben, gab es die noch gar nicht. Mittlerweile ist es Tradition im Podcast, dass wir das mit drin haben.

SPEAKER_01 1:13:34

Gab es damals noch nicht? Hast du angefangen, glaube ich, drei oder vier Folgen danach zu machen, ja?

SPEAKER_00 1:13:38

Guck mal, guck mal an. Hast du gut aufgepasst. Ich hätte es noch nicht mal sagen können, wann das war. Aber, anyways, ein paar der Fragen haben wir, glaube ich, auch schon vorweggenommen, aber ich würde sie trotzdem teilweise nochmal stellen. Build versus Buy, wie entscheidest du?

SPEAKER_01 1:13:49

Ja, Bild.

SPEAKER_00 1:13:51

Ja, ganz klar. Open Source, überschätzt oder unterschätzt?

SPEAKER_01 1:13:55

Eine miese Frage, weißt du. Ich würde sagen, wenn man den Grundgedanken nimmt, der eigentlich dahinter steckt, unterschätzt.

SPEAKER_00 1:14:04

Ja, genau. Weil die Frage hat man nämlich so nämlich nicht gestellt und beantwortet, aber gute Antwort. Ist AI für dich Game Changer oder Password? Ja, es ist ein Gamechanger. Klar. Also das erste. Password ist es auch, aber wenn es ein Gamechanger ist, dann kann es auch gerne ein Password sein. Kleine Teams oder große Organisationen? Dreimal darfst du raten, was deine Antwort sein wird. Denkt sich denn so blöde Rapid-Fire-Fragen aus, wo die Antwort von vornherein klar ist. Oder frühstückten die alle schon so.

SPEAKER_01 1:14:34

Ich könnte jetzt mal die andere Frage geben und machen die Folge quasi Nummer 9. Nein, Spaß beiseite.

SPEAKER_00 1:14:39

Also, Geschwindigkeit oder Perfektion, was machst du?

SPEAKER_01 1:14:43

Geschwindigkeit mit akzeptabler Perfektion. Gibt's doch gar nicht.

SPEAKER_00 1:14:49

Akzeptable Perfektion. Perfektion ist ein Zustand, das ist ein Endzustand.

SPEAKER_01 1:14:52

Ich würde sagen, Geschwindigkeit, wenn man 80% erreichen kann, ist schon okay.

SPEAKER_00 1:14:56

Okay, ist ja keine Perfektion. Siehst du, sind wir uns mal erstaunlich uneinig. Ein Tool, auf das du nicht verzichten kannst.

SPEAKER_01 1:15:05

Boah, wir setzen es ja noch ein, das ist ja so ein Thema, das haben wir heute nicht diskutiert. Noch Microsoft Teams. Wir sind ja auch im Google Meet, also von digitaler Souveränität. Ja, weil wir machen damit alles, aktuell die Sessions und so weiter. Weil wir sind auch dabei, davon uns zu lösen.

SPEAKER_00 1:15:18

Okay, ja, aber das ist tatsächlich, das ist für Microsoft ein Game Changer gewesen, dieses Tool und auch die Strategie, wie sie das eingesetzt haben. Das macht es leider in so vielen Unternehmen. Die Frage, welches Tool man benutzt, macht sie obsolet, weil wenn der CIO kommt und sagt, wir haben, das ist Teil von Office 365 und wenn wir jetzt Slack nutzen, haben wir auf einen Schlag 250.000 Euro mehr im Jahr für unsere Mannschaft, die wir zahlen müssen. Dann ist diese Diskussion unabhängig davon, wie viel 250.000 im Unternehmenskontext sind, ist relativ schnell vorbei. Und das ist sehr schade, aber auch sehr nachvollziehbar. Aber das ist dann der große Vorteil von Microsoft Teams. Ich bin nicht so der größte Fan davon.

SPEAKER_01 1:15:54

Ich weiß, wir haben ja auch ein paar Kinderkrankheiten mit der gesamten Suite, müssen sie natürlich unterstützen, weil wir auch viele Features da drin haben. Und der andere Punkt, der dabei kommt, wir gucken ja parallel nach Alternativangeboten. Das ist auch einer dieser Prozessentscheidungen, aber dauert noch.

SPEAKER_00 1:16:10

Darüber reden wir dann, wenn du das dritte Mal zu uns kommst. Dann über was habt ihr jetzt als Alternative für Microsoft Teams gehabt. Letzte Frage für heute. Ein CTO-Mythos, der dich nervt.

SPEAKER_01 1:16:21

Ein CTO hat nur mit Technik zu tun.

SPEAKER_00 1:16:24

Den kriege ich auch immer noch zu hören. Das ist richtig. Und völlig überholt. Tatsächlich, wenn ich mal kurz noch den Schluss hier machen darf, ich halte CTO für die wichtigste Rolle in den nächsten Jahren. Gerade wegen der Komplexität, die jetzt gerade reinkommt. Ich glaube, es wird niemand besser geeignet sein, von seinem Grundkenntniss-Setup, um das richtig in die Unternehmen reinzutragen, wie der CTO. Es wird diese Rolle brauchen. Ob sie dann irgendwie in 10 Jahren, 15 Jahren von jetzt dann immer noch die gleiche Bedeutung hat, keine Ahnung. Aber aktuell sehe ich keinen, der da, der eine größere Wichtigkeit hat.

SPEAKER_01 1:17:01

Wir haben schon mal die Diskussion geführt mit CIO, CTO, da gibt es natürlich nochmal Unterschiede, weil der eine ist eher so Governance, Compliance obliegend, der andere macht eher Technologie. Aber in vielen Bereichen, auch weil es ja auch weh, weil die Kosten runter müssen und die Disziplin verschmelzen, wird es in einer Person vereint. Andere Organisationen ziehen weitere drei, vier andere C-Rollen auf. C, also denjenigen, der für Head of AI dann zuständig ist und andere Dinge.

SPEAKER_00 1:17:27

Ja, du hast recht, ja, natürlich. Klar. Da gibt es noch den CAIO oder den C. Der CIO macht es manchmal auch diese Themen noch mit, da hast du natürlich völlig recht. Ja, lasse ich als einen Mann gelten, Alex. Das ist okay. Sehr schön. Es war mir wie immer ein großes Fest mit dir zu sprechen. Wir tun das ja auch gerne mal außerhalb dieser kleinen Runde.

SPEAKER_01 1:17:50

Ich würde es gerne mal für das merken.

SPEAKER_00 1:17:53

Das machen wir auf jeden Fall und man hat natürlich auch gemerkt, wir reden auch natürlich schon nochmal etwas vertrauter miteinander als mit dem einen oder anderen Gast, wo man sich vielleicht noch nicht so gut kennt. Ich hoffe, das ist nicht zu laberig geworden, das Gespräch jetzt. Aber nein, das wird schon gut gewesen sein.

SPEAKER_01 1:18:11

Alles klar, hau rein. Danke dir und danke an die Zuhörer. Und bitte like und abonnieren, ne?

SPEAKER_00 1:18:16

Ja, natürlich, genau. Und ich komme dann auch irgendwann zu Alex in dem Podcast.

SPEAKER_01 1:18:20

Genau, freuen wir uns.

SPEAKER_00 1:18:21

Sehr schön. Macht's gut. Ciao, ciao.