Wie treffe ich technologische Entscheidungen in einem Unternehmen?

Intro: Digital Kompakt. Heute aus dem Bereich Tech mit deinem Moderator Joel Kaczmarek. Los geht's!

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von Digitalkompakt und heute habe ich wieder den lieben Björn Wagner an meiner Seite. Den kennt ihr vielleicht schon. Der ist VP Engineering bei SAP Signavio und wenn der gute Björn kommt, dann reden wir immer über Tech-Themen. Weil Björn und sein kongenialer Partner, der gute Till Reiter, die machen halt Technologie. Bei den Jungs und Mädels kennt ihr auch die Firma vielleicht vom guten Gero, der bei uns Sales macht. Wir reden über Technologie. Und heute darüber, wie man eigentlich Technologie-Entscheidungen trifft. Was ich total wichtig finde, weil hier ja auch ganz, ganz viele Menschen zuhören, die nicht technische Entscheider sind. Und denen mal beizubringen, worauf achte ich eigentlich und wie gehe ich vor, wenn ich Technologie baue? Welche Entscheidung muss ich da treffen? Finde ich deswegen total wertvoll. Wir werden also so Dinge besprechen wie, was sind eigentlich so typische Technologie-Assets, die ich im Blick haben muss, also Differenziatoren, wie ist das Ökosystem so gebaut? und dann der typische Blick auf, baue ich das selber, kaufe ich es ein oder partner ich mit jemandem. Das sind unsere drei großen Hauptthemen heute und dann werden wir noch so ein paar Prior-2-Elemente drin haben. Also nach der heutigen Folge weißt du wirklich, wie man Technologie-Entscheidungen gut trifft. That being said, lieber Björn, moin, schön, dass du da bist.

Björn Wagner: Hallo.

Joel Kaczmarek: Wie schwer ist das, üblicherweise bei Unternehmen, gute Technologie-Entscheidungen zu treffen? Was sagt so die Erfahrung?

Björn Wagner: Es ist auf jeden Fall nicht einfach. Wichtig ist, dass man nicht nur Technologienisolation betrachtet, sondern halt immer im strategischen Rahmen auch schaut, dass das halt zur Unternehmensstrategie passt, mit gegebenenfalls Wachstumszielen oder auch zur Produktstrategie, dass quasi die verschiedenen Zahnräder, sage ich mal, ineinander greifen und alle auf das gleiche Ziel zusteuern. Und dann gibt es so ein paar, sage ich mal, grobe Richtungen, die man am Anfang möglichst gut entscheiden sollte. Und dann ist es natürlich immer ein Lernprozess. Man wird Fehler im Prozess machen. Aber wenn man die Weichen initial richtig gestellt hat, kann man eigentlich auch viel, viel richtig machen.

Joel Kaczmarek: Cool. Strategie ist ja dann auch so unser, sag ich mal, erstes Thema, was wir mal anstoßen sollten. Wie baue ich denn eine gute Technologiestrategie? Was sind die Merkmale, die ich da berücksichtigen sollte?

Björn Wagner: Ja, das hängt natürlich sehr stark auch von der Größe des Unternehmens, des Produkts, der Organisation ab. Grundsätzlich, Strategie klingt immer ganz wichtig. Ich glaube, es hat immer zwei Teile. A, sollte man zurückblicken. Man muss quasi verstehen intern, wo liegen denn aktuell Herausforderungen, wo liegen Limitierungen, was funktioniert gut, was funktioniert nicht gut. Das ist so eine Diagnose quasi vom Status Quo machen, die einmal nach intern gerichtet, dann aber halt auch ganz wichtig nach außen schauen in das Technologie-Ecosystem. Was passiert denn? Welche Trends gibt es? Welche Entwicklungen? Aktuelles Thema ja AI. Zu verstehen, was heißt das eigentlich für mein Produkt, für mein Unternehmen und dann den Blick halt neben der Technologie. also in der Vergangenheit auch parallel in die Zukunft richten und zu verstehen, drei bis fünf Jahre auf so einem Horizont, was gibt es dort für wichtige Themen, die für mein Produkt relevant sind, für Trends, für neue Technologien am Horizont, wo stehen die? Und dann auf dieser Basis halt dann Technologieentscheidungen treffen zu können. Also wie gesagt, einmal zurückblickend intern verstehen, wo steht man, was sind Herausforderungen und dann in die Zukunft schauen, Trends verstehen. Und ich sage immer, das nächste Jahr sollte man dann im Detail planen. Also ein Jahr sollte man eine sehr gute Vorstellung haben, technologisch, was möchte man verändern. Es gibt auch immer das große Thema Technical Depth, also hat man irgendwelche Legacy-Systeme, die man ablösen möchte, wo man Verbesserungen machen muss. Also ein Jahr im Detail planen und immer so drei bis fünf Jahre einen groben Ausblick in die Zukunft haben und darauf basierend dann, das ist das Framework, konkret mit den Zielstellungen, die man erreichen müsste, darauf basierend dann halt Technologieentscheidungen treffen.

Joel Kaczmarek: Okay, also ein bisschen wie beim Arzt, einmal das Stethoskop auf die Brust legen lassen, vorher warm hauchen, gucken, wie sieht es gerade momentan aus, wo schmerzt es und wo geht es einem gut? und dann einerseits Langzeitperspektive haben und andererseits das eine Jahr im Detail. Wenn wir jetzt darüber reden, über diesen Strategiefaktor, wie ist denn überhaupt so die Veränderungsgeschwindigkeit bei Technologie? Also ich habe ja immer so, als Laie nehme ich ja immer an, ich baue das einmal und dann bin ich da, sage ich mal, locked in auf Jahre. Ist das so oder hat man da auch noch durchaus Beweglichkeit drin?

Björn Wagner: Also Technologie verändert sich grundsätzlich sehr, sehr schnell. Es gibt dann auch, sage ich mal, ja gerade von Analysten verschiedene Frameworks, Publikationen, wo man sich anschauen kann. Es gibt also Hype Cycles, wo man schaut, wie mature sind denn Technologien. Zum Beispiel das Thema AI ist ja schon seit 20 Jahren, 30 Jahren irgendwie allgegenwärtig eigentlich. Aber die Entwicklung dauert teilweise dann doch sehr, sehr lange für bestimmte Technologien, bis sie dann den konkreten Anwendungsfall haben. Also typischerweise sagt man ja so, die ganz grobe Faustregel ist, von der Forschung bis in die Industrie braucht man so 20 Jahre. Also für große, für neue, für grundlegende Technologien. Aber wenn man jetzt auf, sage ich mal, eher bestimmte Frameworks in bestimmten Programmiersprachen schaut, das ist eher so der kleinere Teil. Dort gibt es natürlich sehr viel schnellere Änderungen.

Joel Kaczmarek: Ich erinnere mich noch zum Beispiel, es gab mal früher so eine Phase, da hat dann auf jeden Fall jedes Startup Ruby on Rails so in den Himmel gelobt. So, ich saß mal da und dachte, okay, Rubine kenne ich nur vom Zeldaspielen oder vom Juwelier, aber das war so the hot thing. Und das ist vielleicht eine Randnotiz, aber ich sag mal, es geht auch so ein bisschen in Richtung Trendaffinität. Wenn sowas aufkommt, sollte ich mir sowas immer gleich angucken. oder gilt eigentlich bei Technologie eher so ein Stück weit zu sagen, nee. Wie du es gerade gesagt hast, diesen Fünf-Jahres-Blick zu haben und zu wissen, was man dieses Jahr konkret macht und nicht jedem Trend hinterher zu rennen. Wo ist denn also die Wahrheit?

Björn Wagner: Also es ist ganz wichtig, das Thema so Build-by-Partner zu betrachten. Also welche Sachen möchte ich eigentlich selber entwickeln? Da können wir gleich nochmal zukommen. Das geht dann auch so in das Thema Technologie-Assets-Differentiator rein. Und welche Sachen nehme ich dann quasi von der Stange, verwende ich andere Produkte, andere Libraries, andere Technologien? Und hierbei würde ich immer auf so ein paar grundsätzliche Faktoren schauen, wenn ich mich für Technologien entscheide. Zum einen das Thema Adoption. Das heißt, wird die Technologie, das Framework schon von anderen Unternehmen, Produkten, die ein ähnliches Setup haben wie ich, verwendet und wie erfolgreich sind die damit? Wenn ich eine ganz wichtige Entscheidung treffe, würde ich vielleicht mal mit Leuten reden, auch schauen oder mir Referenzen anschauen, um zu verstehen, wie gut funktioniert die Technologie, das Framework. Oder wo sind die Herausforderungen und wie hat sich das denn in einem echten Anwendungsfall wirklich umsetzen können? Das zweite Thema ist dann Maturity. Also ist das ein Framework, was gerade letzte Woche erfunden wurde, auf einer Konferenz vorgestellt wurde und das jetzt gerade auf allen Blogs gehypt wird, aber da wurde halt noch nie ein, sage ich mal, solides B2B-Produkt oder ein skalierbares B2C-Produkt drauf gebaut, dann wäre ich da auch sehr, sehr vorsichtig. Ein weiter guter Indikator ist Community. Man kann sich halt anschauen, einfach googeln, Stack Overflow, wie viel Aktivität gibt es denn in verschiedenen Communities zu bestimmten Technologien. Das heißt, wenn ich dann ein Problem habe, bekomme ich dann zum Beispiel auch Hilfe aus der Community. Und grundsätzlich würde ich mal schauen, es gibt ja ein riesengroßes Angebot. Das Wichtigste ist eigentlich immer, dass man versteht, okay, ich habe bestimmte Anforderungen, die ich umsetzen möchte und dann hat die Technologie bestimmte Features, Angebote. und wie groß ist eigentlich der Overlap? Ja, weil es gibt halt so bestimmte Sachen, wenn ich nur ein ganz kleines Feature-Set oder ein ganz kleines Problem lösen möchte, aber mir dafür eine riesengroße Technologie, ein riesengroßes Framework einkaufe, dann habe ich vielleicht in der Wartung und Maintenance nachher riesengroße Probleme. Also da musst du schon einen möglichst großen Overlap geben und quasi auch ein gutes Level an gleicher Komplexität an der Stelle.

Joel Kaczmarek: Cool. Und du hast ja eben auch schon über Technical Debt geredet. Also ich erinnere mich noch, bei einem meiner letzten Arbeitgeber war das immer so, der hat mir mal aus der Bankenwelt erzählt, was glaube ich so das krasseste Beispiel für Technical Debt ist, wo die ja wirklich noch so monolithische Softwarebauten hatten, wo es gar nicht mehr die Entwickler gab, weil die Menschen, die das noch konnten, ausgestorben sind. Die mussten dann immer so Zwiebelschalmodell-Sachen rumbauen. Hast du nochmal einen Tipp, wie ich vermeiden kann, dass ich starkes Technical Debt aufbaue, wenn ich in der Strategiephase mich befinde?

Björn Wagner: Ja, also man muss auf jeden Fall ein gutes Verständnis von Technical Depth haben. Es gibt auch andere, das sehr, sehr negativ belegt. Die nennen das Architectural Runway. Das heißt, wie gut ist meine Architecture denn auch da in die Zukunft weiter darauf aufzubauen? Und hier hängt es halt hauptsächlich auch von der Komplexität und vom Alter der Systeme ab. Also Technical Depth entsteht nicht durch eine Fehlentscheidung. Es sind eher, sage ich mal, viele kleine Entscheidungen, die man trifft. Häufig muss man halt Trade-offs machen einfach. Ich möchte zum Beispiel eine neue Funktion machen. schnell einem Kunden zur Verfügung stellen und jetzt kann ich die halt in einer Art und Weise bauen, die halt entweder, sage ich mal, schnell ist, aber ich erzeuge damit halt neue Technical Depth, weil ich zum Beispiel typischerweise Refactoring mir spare oder halt Sachen mehr schnell zusammenhacke, wie es so häufig genannt wird, um halt den Kunden zur Verfügung zu stellen. Aber wenn wir dann ein halbes Jahr später auf das Feature schauen oder das erweitern wollen, dann lernt man halt, oh, jetzt müssen wir halt das große Refactoring machen. Es ist halt sehr, sehr wichtig, also das nicht nur strategisch zu sehen, das muss halt auch wirklich Brot und Butter von Software-Ingenieuren sein, auch auf, sage ich mal, kleinster Ebene zu entscheiden und halt auch gut zu entscheiden, mache ich jetzt für ein Ticket, also für was, was ich vielleicht nur einen Tag daran arbeite, gehe ich jetzt den einfachen, den schnellen Weg, aber habe dann vielleicht nächste Woche beim nächsten Ticket das Problem? Oder gehe ich halt den einfachen Weg? Und diese Entscheidungen müssen halt auf sehr vielen Ebenen getroffen werden. Und dort gibt es dann so Best Practices, wie man davon umgeht und so Coding Guidelines eigentlich, die sehr, sehr wichtig sind, das dann halt so ein bisschen zu steuern aus der Top-Down-Perspektive auch.

Joel Kaczmarek: Der letzte Faktor, den du gerade angesprochen hast, was ist denn da dein Erfahrungswissen? Weil ich erinnere mich noch so an die Rocket-Internet-Devise früher immer, ja jetzt erstmal schnell Wachstum, gut machen können wir immer noch, was ja zu gewissen Teilen auch gut funktioniert hat. Aber was sagt deine Erfahrung? Ist es besser sozusagen mit langfristigem Erfolg im Blick etwas von Anfang an ordentlich zu bauen und dann zu sagen, okay es kostet mich zwar mehr Zeit mit der Gefahr, dass mein Wachstum leidet, Oder ist es so, nein, es ist schon in Ordnung, am Anfang auf Geschwindigkeit zu setzen und hinten raus zu reparieren, das geht schon. Welche Trade-Offs habe ich in welchen Fällen?

Björn Wagner: Ja, hier gibt es meiner Meinung nach keine magische Formel, die einem diese Entscheidung abnimmt. Es ist halt immer ein Spektrum. Gerade am Anfang muss man halt, also wenn man sich zum Beispiel im typischen Startup-Umfeld anschaut, ein sehr, sehr frühes Produkt hat, dort Problem-Solution-Fit erzeugen möchte, dann ist halt Geschwindigkeit das A und O. Und dann nimmt man halt auch Abkürzungen ab. an einigen Stellen kauft, die einem dann später vielleicht zusätzliche Kosten verursachen. Aber wenn man das nicht machen würde, würde man vielleicht gar nicht zum Problem-Solution-Fit kommen. Also hier muss man in jedem Fall halt abwägen, was bringt einem das, der Geschwindigkeitsvorteil, gegenüber gegebenenfalls dann einem späteren Architecture-Deb, die man machen muss. Ich glaube Es wird dann sehr, sehr spannend, sage ich mal, wenn Produkte älter sind, zum Beispiel eine Code-Basis fünf, sechs, sieben, zehn Jahre alt ist und man merkt dann irgendwann, man stößt an ein Limit. Jede Sache, die man machen möchte, dauert super lange, die Teams sind unzufrieden, dann muss man sich halt Gedanken machen, da gibt es eigentlich zwei Ansätze, also häufig Ein klassisches Beispiel ist, man hat dann halt eine große monolithische Anwendung, die man dann in mehrere Services splitten möchte. Und dann gibt es halt eigentlich zwei Ansätze. Zum einen, man versucht das irgendwie Step-by-Step innerhalb, also den Monolithen auseinanderzunehmen und Step-by-Step in Services zu teilen. Oder man geht halt hin und sagt, okay, man baut halt einmal parallel die Anwendung vielleicht mit einem anderen Team sogar neu auf. Hier aber gibt es auch kein Patentrezept, hängt sehr stark vom Produkt, sehr stark von der Technologie ab. Aber das sind dann halt sehr, sehr große Investitionen, die dann häufig auch über mehrere Jahre gehen.

Joel Kaczmarek: Letzte Frage zum Thema Technologiestrategie. Wie verzahne ich das? Weil normalerweise sitzt du ja auch mit deinem kongenialen Partner, dem Till, zusammen, der bei euch Product macht und Product und Tech gehen ja Hand in Hand. Wie kriege ich das hin, dass beide Seiten immer am gleichen Strang ziehen und dass man bei der technologischen Strategie da auf der gleichen Seite ist?

Björn Wagner: Wie ich am Anfang schon gesagt habe, es muss halt alles Hand in Hand laufen. Also sowohl die Firmenstrategie, die häufig ja dann hauptsächlich so Wachstumsziele, Finanzziele ausgibt, muss halt abgestimmt sein mit der Produktstrategie und der Tech-Strategie. Das heißt, in der Produktstrategie, wenn man irgendwelche Luftschlösser baut, die man aber technologisch mit den aktuellen Technologiestecken gar nicht erfüllen kann, dann hilft einem das nicht. Das heißt, da muss es so Feedback-Cycles, Rückkopplung geben, dass man halt sicherstellt, dass was man dann vielleicht auf der Wachstums-, auf der Produktseite erreichen will, technologisch überhaupt realistisch geleistet werden kann. Also hier ist eine enge Abstimmung wichtig. Deshalb machen wir zum Beispiel bei SAP Signavo Strategie auch immer gemeinsam. Da gibt es halt einen gemeinsamen Strategiezyklus einmal im Jahr, wo man sich über eine längere Zeit zusammensitzt, eine sehr saubere Analyse macht des Ist-Zustandes, sowohl intern als auch extern und dann halt gemeinsam eine Produkt- und Technologiestrategie entwickelt.

Joel Kaczmarek: Ich hab das gerade so vor Augen, wie so Stockbrot über dem Feuer zusammen. Sehr gut, sehr gut. Cool, lass uns mal zum ersten großen Thema kommen, was wir vorhin schon angerissen hatten, nämlich Technologieassets, beziehungsweise was sind eigentlich so Differenziatoren? Weil darum muss es ja oft gehen, dass man so Barriers of Entry auch baut für seinen eigenen Wettbewerb. Was ist so da dein kleines Einmaleins für?

Björn Wagner: Ja, ich habe natürlich einen Tech-Background und deshalb ist das für mich eigentlich das Allerspannendste. Ich würde sogar sagen, wenn man, also ohne wirklichen Tech-Differentiator ist man gar keine Tech-Company wirklich am Ende des Tages. Also die Frage ist, hat man quasi einen Teil Technologie im Produkt, das kann Das kann aber auch total versteckt sein, keine Ahnung, im Supply Chain Management, aber hat man eine Secret Source, wie man immer so schön sagt im Englischen, die irgendwie einen vom Markt absetzt, die quasi wirklich ein differenzierender Faktor ist, die schwer zu kopieren ist. Das heißt, dass hier auch quasi langfristig Konkurrenz Schwierigkeiten haben wird, das zu kopieren und man dadurch einfach einen Vorteil und eine gute Stellung am Markt hat. Um vielleicht mal ein paar Beispiele zu nennen. Eins habe ich letzte Woche wieder sehr, sehr häufig benutzt. Shazam ist ja eine App, die macht Musikerkennung. Die wurde ja, ich glaube, 2016, 2017 mal von Apple gekauft. Die haben das dann direkt auch bei sich in der Siri integriert. Ist halt zum Beispiel ein super Tech-Asset, eine Company, die sich genau darauf fokussiert hat, das Problem zu lösen. Wie kann ich halt Leuten, die den Song nicht erkennen, dort eine einfache Möglichkeit geben, den Songtitel herauszufinden. Ein anderes Beispiel gerade, natürlich in aller Munde, OpenAI, super interessantes Technologieasset. Hier würde ich sagen, das Hauptasset sind die Modelle und quasi wie die Modelle trainiert werden, wie die erstellt werden. Ist ja ein sehr, sehr interessanter Kostenfaktor auch. Gibt sehr viele Zahlen im Netz, würde geraten, wie viel kostet das eigentlich, so ein ChatGPT-4-Modell zu trainieren. Aber hier hat halt OpenAI ein sehr, sehr starkes Technologieasset auf jeden Fall vorliegen. weshalb sie dort den Markt anführen. Ich würde noch ein bisschen vorsichtig sein, da ist auch natürlich immer viel Marketing dabei. Ich glaube, es gibt noch große andere Player, weil ein anderes Asset natürlich sind doch immer Daten. OpenAI als neue Company hat ja zum Beispiel nicht so spannende Daten wie einen Google über die Nutzer durch so Sachen wie Suchhistorie oder die ganzen anderen Google-Produkte. Das heißt, da wird es auch sehr, sehr spannend sein zu sehen, wie zukünftig auch Daten wirklich als Assets dann diese neuen Modelle füttern können und vielleicht ganz, ganz neue Produkte und Use Cases entwickeln an der Stelle. Aber sowas zu haben als Unternehmen, als Produkt ist super wichtig, wenn man wirklich als Technologieunternehmen wahrgenommen werden möchte und halt sich auch gut gegen die Konkurrenz abgrenzen kann.

Joel Kaczmarek: Ich muss dich mal ganz blöd fragen, wenn du sagst, es braucht eine Secret Source, so einen Differenziator. Was genau meint das im Technologiebereich? Reden wir dann davon, dass man Code-Architektur zum Beispiel auf eine besondere Art macht oder geht es da um Product Features eigentlich eher? Weißt du, was ich meine?

Björn Wagner: Ja, also es kann alles sein. Es kann sein, man hat irgendwie einen bestimmten Algorithmus. Algorithmen kann man teilweise ja sogar patentieren, der dann irgendein Problem löst, was andere ohne diesen Algorithmus nicht tun. Zum Beispiel hatte ich mal in meinem Studium sogar, hatten wir ein sehr interessantes Beispiel, wo es darum ging, wie kann man quasi großen Unternehmen helfen, ihren Kunden Lieferungen exakt zu versprechen. Es ist ein sehr komplexes Problem. Wenn ich ein weltweites Unternehmen habe, habe ich verschiedene Produktionsstätten, ich habe aber auch Lagerbestände und jetzt muss ich dem Kunden zu einem bestimmten Zeitpunkt an einem bestimmten Ort der Welt versprechen, dass was geliefert werden kann. Und da sind sehr interessante, komplexe Algorithmen im Hintergrund, die sicherstellen, dass das zum Beispiel mit einer großen, sage ich mal, Sicherheit gemacht werden kann. Und das wäre zum Beispiel eine Technologie, wenn ich diese Algorithmen habe, wie gesagt, die kann man sogar patentieren, weil dann nur ich als Unternehmen dem Kunden wirklich dieses Lieferversprechen basierend auf seinen ganzen Lagerbeständen und Produktionskapazitäten liefern kann. Es können Daten sein, ein Asset, ganz klar, zum Beispiel viel im Social-Media-Bereich, Daten über die Nutzer, um halt zum Beispiel dann gezielt Werbung schalten zu können, die eine höhere Conversion-Rate einfach hat. Und im AR-Bereich sind es häufig, es ist ein sehr weites Feld, aber häufig halt die Modelle an sich, das sind halt die wirklich trainierten Modelle, die dann halt, wie im Bereich von Chat-GPT, die entsprechenden Antworten liefern können an der Stelle.

Joel Kaczmarek: Wie verhält es sich denn mit Open Source in dem Kontext? Weil es ist ja immer so das Dilemma, die Lizenzlage ist ja so, wenn ich Open Source nutze, wird das, was ich mit mache, auch Open Source. Und gleichzeitig ist es aber so, dass diese Produkte, die unter dieser Lizenz stehen, aber sehr, sag ich mal, gut bedient werden, dass es eine breite Entwicklerbasis gibt etc. etc. Verbietet es sich also, solche Elemente aufzunehmen, wenn ich sage, ich will Differenziatoren bauen oder darf man das durchaus kombinieren?

Björn Wagner: Ich glaube, heutzutage verwendet jedes Unternehmen Open-Source-Technologie. Wichtig ist natürlich, dass man sich die Lizenzen anguckt. Also es gibt halt verschiedene Lizenzmodelle in dem Bereich und es gibt Lizenzen, die sind so, wie du angesprochen hast, wenn ich halt ein Open-Source-Produkt verwende, verpflichtet mich die Lizenz mein Code, der das verwendet, auch wiederum Open-Source zu stellen. Das ist natürlich, wenn ich kommerzielle Software entwickle, ein Problem, weil häufig dann der Code ja auch ein Teil oder ein Asset ist, mein Eigentum und ich das schützen möchte. Das heißt, diese Technologien oder diese Open-Source-Lizenzen kann ich dann nicht verwenden, aber es gibt auch ein riesiges Angebot an Lizenzen, die halt kommerzielle Nutzung nicht ausschließen, die man dann einfach verwenden kann. Deshalb sehe ich halt heute, also egal welche Unternehmen halt zum großen Teil auf Open Source Lizenzen oder Open Source Frameworks aufbauen am Ende.

Joel Kaczmarek: Und vielleicht letzte Frage noch dazu. Wie ist es denn mit der, sage ich mal, Pflegbarkeit, wenn ich etwas sehr Spezifisches habe? Also wenn ich neue Entwickler in mir hole, habe ich natürlich einen gewissen Erklärungsaufwand. Ich muss auch irgendwie aufpassen beim Thema Braindrain, dass wenn die weggehen, dass die die Sachen nicht mitnehmen. Wie kriege ich sowas gut gesteuert? Dass ich einerseits Leute gut schnell onboarden kann mit den Dingen, die ich auf eine einzigartige Weise tue und andererseits verhindere, dass es am Markt quasi rausgetragen würde.

Björn Wagner: Also Onboarding, je nach Technologie, wie gesagt, häufig verwendet man ja einen Teil von Standardtechnologien. Zum Beispiel eine der beliebtesten Programmiersprachen ist JavaScript. Das heißt, wenn ich jetzt Webentwicklung mache, dann ist die, wenn ich jetzt in die verschiedenen Unternehmen schaue, relativ ähnlich. Natürlich gibt es dann Spezialitäten, besondere Frameworks oder besondere Features an der Stelle. Aber es hat schon, wenn ich ein Frontend-Entwickler bin, treffe ich heutzutage in vielen Unternehmen halt relativ ähnliche Sachen an. Natürlich, wenn ich jetzt diese Assets habe, das heißt das, was mich wirklich von anderen unterscheidet, dann ist die natürlich immer wichtig, dass das nicht nur in der Hand weniger Entwickler ist. Das ist auch ein Beispiel, was man sehr, sehr, sehr häufig findet. Hier gibt es eine wichtige Funktion, die hat dann mal vor fünf Jahren einen Werkstudent gebaut, der inzwischen gar nicht mehr da ist und keiner weiß eigentlich mehr, wie das jetzt zu verwenden, zu warten ist. Das ist natürlich ein Problem. Das heißt, man muss aufpassen, dass dort immer Da gibt es auch den berühmten Begriff Bus Factor. Wenn der Bus Factor 1 ist und der Entwickler vom Bus überfahren wird, das ist ein bisschen makaber, dann weiß keiner mehr, wie man mit dem Feature umgeht. Das heißt, gerade auf den Asset-Bereichen muss man sicherstellen, dass dort irgendwie genug Leute auf dem Thema geonboardet sind. Das Risiko, dass Leute weggehen, hat man natürlich immer. Das kann man nicht verhindern. Das ist aber vielleicht auch ein guter Übergang zum Thema Ecosystem und Zeit. Also ganz wichtig, Technologieassets immer im Rahmen der Zeit betrachten. Das heißt, selbst was heute ein Asset ist, kann morgen halt schon, sage ich mal, allgemeingültig, allgemein verfügbar sein. Und damit ist dann mein Wettbewerbsvorteil auch verloren. Das heißt, nur weil ich heute was habe, muss man immer schauen. Deshalb ist auch Strategie so wichtig. Wie sieht das eigentlich in der Zukunft aus? Bleibt das ein Vorteil oder wird das eher gefährlich? Quasi eine Common-Technologie, die für jeden verfügbar ist.

Joel Kaczmarek: Ja, Ökosystem, gutes Stichwort als zweiter großer Komplex oder eigentlich dritter nach Strategie und Differenziatoren. Wie gehe ich da vor? Es gibt ja deswegen auch so die Frage mit dem Abwandern und Zuwandern. Es gibt ja ein System, in dem ich arbeite, ist ja kein luftleerer Raum. Das heißt, worauf muss ich achten, wenn ich Technologieentscheidungen treffe mit Blick auf das Ökosystem?

Björn Wagner: Hier ist vielleicht ein Thema interessant. Ich würde das mal so Enabler-Technologie nennen. Einfach mal zwei Beispiele, um das vielleicht konkret zu machen. In den letzten 10, 15 Jahren haben sich ja sehr, sehr viele Cloud-SaaS-Companies entwickelt. Ich würde mal stark vereinfacht gesagt sagen, es gab zwei wesentliche Entwicklungen. Enabler-Technologien, zum einen ist das ganz weit gefasst Web 2.0, aber eigentlich im Browser-Bereich das Anfang der 2000er, die Browser so mächtig wurden durch neue JavaScript-Versionen, durch neue Funktionen, wie sie mit Servern kommunizieren können, dass man anfangen konnte, auch komplexe Anwendungen im Browser direkt zu entwickeln, anstelle von einer klassischen Anwendung, die ich mir runterladen muss, die ich installieren muss, die ich als Unternehmen ausrollen muss. Das war ein zentraler Treiber, was auch die Geschwindigkeit der Entwicklung im Wesentlichen vereinfacht hat. Und ein zweiter großer Treiber, so als Enabler-Technologie im Ecosystem, sind dann, würde ich sagen, Hyperscaler, sowas wie AWS, Google oder Microsoft Azure. Wir haben dann noch Alibaba Cloud, wenn man mehr im asiatischen Raum schaut, die, ich glaube AWS hat 2006 angefangen, die halt auch eine sehr, sehr starke Enabler-Technologien waren, um es anderen Unternehmen zu vereinfachen, Anwendungen darauf aufzubauen. Und diese Trends haben dann quasi über die letzten zehn Jahre dazu geführt, dass es halt einfacher wurde, auch komplexe Anwendungen im Browser zu entwickeln, dass es einfacher wurde, Anwendungen irgendwie zu deployen, zu verwalten und halt sich um Infrastruktur im wesentlichen Sinne oder zu einem deutlich geringeren Maße selber kümmern zu müssen. Also das ist quasi ein Beispiel, wo ich sagen würde, das waren zwei entscheidende Enabler-Technologien, die halt einen sehr, sehr großen Einfluss darauf hatten, dass Leute dann andere Produkte im SaaS-Bereich darauf aufbauen konnten. Wenn man heute ein aktuelles Beispiel nimmt, ist es vielleicht AI oder Large Language Models ist ja jetzt in aller Munde beim Thema Open AI und hier, das kann auch eine sehr, sehr spannende Enabler-Technologie sein, wo man dann halt schaut, was machen denn jetzt andere damit. Es gab zum Beispiel sehr beeindruckende Videos in den letzten Wochen, sowohl auf Microsoft-Seite als auch auf Google-Seite, die halt gezeigt haben, okay, Ich meine, dieser Prompt ist nett, aber was heißt das denn wirklich fürs Arbeiten? Und die dann die Technologie verknüpfen mit zum Beispiel einem Microsoft Outlook, wo ich einfach nur drei Stichpunkte mache und dann wird mir die E-Mail mit dem Kontext des bisherigen E-Mail-Threads automatisch ausformuliert. Und ich kann auch sagen, ja, mach es länger, mach es kürzer. Und dann wird es halt sehr, sehr spannend, wirklich für Unternehmen heute zu verstehen und zu entscheiden, was bedeuten denn zum Beispiel diese Large Language Models für meine Produkte. und wie kann ich denn mit meinen Produkten, die ich habe, mit dieser neuen Technologie vielleicht ganz neue Lösungen bauen, um noch bessere, noch mehr, noch besseren Mehrwert zu meinen Kunden zu liefern.

Joel Kaczmarek: Okay, verstanden. Also erster Gedanke, den ich mir machen sollte, wenn ich mal jetzt ökosystemisch denke, ist, was gibt es eigentlich für Enabler-Technologien und wo führen die hin? Also da braucht man ja schon eine gewisse Fantasie, aber versteht man. Dann ist ja aber die andere große Frage, auf welche Trends setzt man? Und was ist das Modell dafür, nachdem ich das entscheide?

Björn Wagner: Ja, niemand kann in die Zukunft schauen. Das heißt, auch hier gibt es nicht die goldene Lösung. Es gibt, wie gesagt, gerade von verschiedenen Analysten, die bieten das an, verschiedene Methoden, wie halt von der ganzheitlichen Sichttechnologien bewertet wurden, wo sie sind, auf welchen quasi, es gibt so einen Hype-Cycle, das heißt, irgendwann sind die alle mal in der Presse, die finden das ganz toll. Dann gibt es meistens so eine Art Tief, wo dann keiner noch so richtig weiß, wie setzen wir die Technologien jetzt denn wirklich produktiv ein. Und dann am Ende gibt es dieses Plateau, wo dann wirklich halt Wert extrahiert werden kann, auch auf einer großen Skalierung. Und um auch nochmal ein Beispiel zu nennen, es gibt ja das ganze Thema Blockchain, ja, auch eine sehr, sehr spannende Technologie. Das ist natürlich das Thema irgendwie Coins und Spekulationen auf irgendwie, der Kurs geht hoch, der Kurs geht runter, aber wenn wir uns wirklich mal Anwendung, Technologie anschauen, also zum Beispiel auch im B2B-Bereich gibt es hier Stand heute relativ wenig Anwendungsfälle für so eine Technologie wie Blockchain. Also das Thema groß gehypt, aber wenn man sich dann anschaut, was sind denn die Anwendungsfälle, wo denn diese Technologie wirklich einen Mehrwert neben dem Coin-Handel, wo der Mehrwert jetzt, sag ich mal, umstritten ist, vielleicht an der Stelle, aber wo andere Produkte von so Mehrwert profitieren können, das ist halt noch, sag ich mal, nicht gelöst schon heute.

Joel Kaczmarek: Nächstes Thema, was du ja auch schon mal angerissen hast, die nächste Frage, die ich mir dann stellen kann, ist ja, baue ich das selber? Kaufe ich es mir von Dritten ein? Partnere ich mit jemandem? Oder übernehme ich vielleicht ein ganzes Unternehmen, was so etwas schon gebaut hat? Also Build vs. Buy vs. Partner vs. Acquire, könnte man sagen. Nach welcher Landkarte gehst du da vor? oder was würdest du so sagen, wie trifft man diese Entscheidung?

Björn Wagner: Genau. Und hier fließen halt die beiden anderen Themen ganz stark mit ein. Also was ist A, mein Differentiator? Den muss ich halt immer bauen. Den gibt es halt nicht, den kann ich nicht einkaufen bei Definition. Und ich würde halt auch hier sagen, darauf sollte man sich immer fokussieren. Das heißt, Grundregel ist, wenn ich einen Differentiator habe, dort darauf fokussieren und überall anders zu schauen, basierend auf dem Ecosystem, basierend auf Trends, was verfügbar ist am Markt zu schauen. kaufe ich mir eine Lösung ein und eine Lösung kann hier sein, eine andere Cloud-Lösung, es kann sein eine Tech-Library, Open-Source, die ich verwende, es kann sein eine Tech-Library, die ich einkaufen muss oder arbeite ich mit Partnern, das heißt, dass ein Partner ein Produkt hat, was mein Produkt ergänzt, dann muss ich halt schauen, wie kann das Produkt integriert werden und man geht dann vielleicht sogar im Markt, tritt man einfach gemeinsam auf und quasi verknüpft beide Lösungen. In größeren Unternehmen ist es natürlich dann noch die Frage, kauft man Companies? Das würde ich sagen, ist ein Thema für sich, aber gerade auch hier, ich hatte am Anfang schon mal gesprochen, das Thema Shazam, die hat eine sehr interessante Technologie, wurden von Apple gekauft, damit Apple das halt quasi in ihre Telefone und in Siri zum Beispiel integrieren kann, weil das für Apple halt einfacher gewesen ist, die Firma zu kaufen, als quasi die Technologie selbst von Grund auf zu entwickeln. Das ist immer noch eine andere Sache. Wie gesagt, ich hatte es am Anfang schon kurz angesprochen, eine Strategie, ich würde mal schauen, wie stark ist die Technologie adopted, das heißt, haben andere damit schon gute Erfahrungen gemacht, wie mature ist die, gibt es eine Community dazu und wie gut passt das zu meinem wirklichen Use Case. Wenn ich mit Partnern zusammenarbeite, hat man natürlich immer das Risiko, was man auch nicht erschätzen darf, der Partner hat vielleicht Investoren, die das Unternehmen in eine andere Richtung drängen wollen, das Unternehmen wird gekauft von einem Konkurrenten, ja, da muss ich noch so ein paar mehr Risiken beachten. Aber sonst, kurz gesagt, ich würde immer versuchen, mich auf meinen Technologie-Differentiator zu fokussieren, den selber zu bauen und sonst möglichst viel von anderen wiederzuverwenden.

Joel Kaczmarek: Wir haben ja jetzt auch noch an keiner Stelle über Programmiersprachen mal geredet. Ist das eigentlich überhaupt wichtig? Also wenn ich Technologie-Entscheidungen treffe Macht es dann einen Unterschied, ob man jetzt irgendwie, was ich mit dem lustigen Beispiel Ruby on Rails damals hatte oder Python oder whatever, ich kriege die gar nicht alle so zusammen, die Programmiersprachen, die du alle kennst wahrscheinlich, aber wir haben noch keinen Satz darüber verloren, womit ich das eigentlich tue. Spielt das überhaupt eine Rolle oder geht man eigentlich eher so vom strategischen Ziel aus? und dann findet sich das selbst?

Björn Wagner: Programmiersprachen sind auf jeden Fall eine wichtige Entscheidung, die man trifft. Es hängt jetzt sehr stark ab vom System. Also früher, wenn ich eine monolithische Anwendung habe, dann treffe ich die Entscheidung halt einmal, dann schreibe ich halt alles in einer Sache. Wenn ich halt eine Microservice-Architektur habe, das heißt, mein System besteht aus vielen kleinen Services, kann man sogar verschiedene Services in verschiedenen Programmiersprachen mit unterentwickeln. Jetzt gibt es verschiedene Unternehmen, haben ganz viel Erfahrung damit gesammelt, wie viele Freiheiten sollte man einem Team aus einem Service-Own wirklich geben, eine komplett eigene Programmiersprache zu verwenden. Hat viele Vor- und Nachteile. Grundsätzlich, meiner Erfahrung nach, ist es immer das Beste, wenn man sich auf eine Handvoll Programmiersprachen beschränkt. Das heißt, wenn ich Webfrontendentwicklung, ist ganz klar JavaScript oder die Abwandlung TypeScript gesetzt. Ich hatte das extra nachgeschaut auf GitHub Open Source. Die beliebteste Programmiersprache, dann eng gefolgt von Python und Java, die dann häufiger im Backend-Bereich eingesetzt werden. Hier nochmal wichtig auch zu sagen an der Stelle, es hängt natürlich auch wieder, wir haben ja in den ersten zwei Folgen viel über das Team und die Leute gesprochen, das muss zusammenpassen, die Programmiersprachen. Das heißt, ich muss halt schauen dass die Programmiersprache, die ich verwende, dass ich dort halt auch die Entwickler in meiner Region zu den Kosten oder zu den Gehältern, die ich halt auch zahlen möchte und kann, finde. Und das ist zum Beispiel für, sage ich mal, Frontenentwicklung relativ einfach. Wenn ich jetzt aber sehr spezielle Fälle habe, wir haben das Thema Landwirtschaft, im AI angesprochen oder halt auch im Low-Level-Datenbank-Entwicklung, die dann in C++ zum Beispiel gemacht wird. Dort sieht dann der Markt und die Verfügbarkeit von Entwicklern ganz anders aus und das ist halt auch neben der reinen Technologie ist halt immer noch ein Faktor, den man natürlich seinen entweder bestehenden Teams oder zukünftigen Leuten, die man heilen möchte, was man immer beachten sollte, dass es halt die Entwickler geht. Noch abschließend Ruby habe ich gesehen, in der GitHub-Statistik war er auf dem absteigenden Ast, also die Top 3, wie gesagt, JavaScript, Python, Java, aber das ist auch ein. Da gibt es sehr unterschiedliche Meinungen in der Community natürlich.

Joel Kaczmarek: Ja, wenn sie bis zu mir durchdringen, die Begriffe, dann sind sie in der Regel relevant. Python habe ich zum Beispiel sehr oft in letzter Zeit. Cool. Und mal abschließend zur Frage Build versus Buy oder Partnerschaften und Acquire. Was sind so typische Fehler, die du da siehst?

Björn Wagner: Ja, sehr gute Frage. Was ich häufig sehe, ist, man unterschätzt den Entwicklungs- und vor allem den Wartungsaufwand, wenn ich Sachen selber baue. Gerade Entwickler, muss man halt auch schauen, das ist dann eher so eine Tech-Leadership-Aufgabe. Entwickler tendieren natürlich dazu, gerne Probleme selber lösen zu wollen und Probleme selber quasi realisieren zu wollen. Und deshalb ist es immer wichtig zu verstehen, okay, Vielleicht kann ich das relativ schnell bauen, aber ich habe dann sehr, sehr viel Aufwand später in der Erwartung und das ist halt eine Sache, die man halt unterschätzt. Auf der anderen Seite sieht man natürlich auch genau das Gegenteil. Es gibt das neue tolle Framework, das neue Web-Framework Nummer 25 und jetzt sagt man, oh, das löst ja alle meine Probleme, die ich vorher hatte und man unterschätzt dann aber oder man überschätzt vielmehr die Flexibilität der Lösung. Man kann vielleicht die ersten 60% gut bauen, aber dann hat man halt Anforderungen, wo man merkt, okay, das passt jetzt nicht mehr in dieses Framework rein und dann stößt man an den Grenzen der Flexibilität und erzeugt einen gewissen Login an der Stelle. Das heißt, okay, jetzt habe ich mich für eine Framework, für eine Technologie oder für eine Infrastruktur entschieden und merke aber halt, okay, sie ist nicht flexibel genug, um jetzt meine neuen Requirements umzusetzen, aber ich habe jetzt halt schon sehr viel rein investiert und es würde sehr viel Geld kosten, halt auf eine andere Variante umzusteigen. Also das sind zwei Sachen, wo ich immer drauf schauen würde. A, man sollte nie unterschätzen, was es wirklich heißt, die Sachen komplett selber zu entwickeln. Am Anfang sieht es häufiger einfacher aus, als es denn am Ende ist. Auf der anderen Seite überschätzt man halt auch teilweise die Flexibilität und die Mächtigkeit von neuen gehypten Frameworks an der Stelle.

Joel Kaczmarek: Gut, exakt. Jetzt haben wir vier große, wichtige Bereiche durchgesprochen. Technologiestrategie, Differentiator, das Ökosystem und die baue ich selber oder kaufe ich einfrage. Lass uns nochmal ein paar andere Prioritäten, die vielleicht etwas nachgelagert sind, aber trotzdem wichtig in Summe sind, durchdeklinieren. Vielleicht so die erste Frage, was du auch eben schon angerissen hast. Standardsoftware versus Customentwicklung. Hast du da nochmal so ein Fazit?

Björn Wagner: Das ist, glaube ich, eine ganz wichtige Entscheidung, die aber meistens auch relativ klar ist. Das heißt, bin ich halt ein Softwareanbieter, das heißt, die Software, die ich entwickle, die soll für hunderte, tausende, Millionen Kunden funktionieren. Das heißt, hier gehe ich dann natürlich auch selbst von der Anforderungsanalyse ganz anders damit um. Das heißt, ich versuche jetzt nicht unbedingt für jeden Kunden alle Wünsche zu erfüllen, sondern ich muss halt einen guten Mittelweg finden, möglichst viele Kunden gut zu bedienen. Die komplette Gegenteil ist denn, wenn man quasi Eigenentwicklungen durchführt, das heißt, wenn man zum Beispiel eine Software konkret für einen Use Case oder für einen Kunden nur baut und dann kann man natürlich jedes Feature, jede Funktion genau auf diesen Use Case zugeschnitten entwickeln.

Joel Kaczmarek: Okay, wie ist es mit Märkten und Geografien? Weil manchmal variiert es ja auch je nachdem, wo ich agiere, wenn ich eine Technologieentscheidung treffe.

Björn Wagner: Genau, also das sollte man sich auch von Anfang an bewusst sein, in welchen Märkten und in welchen Ländern, sage ich mal, möchte ich eigentlich aktiv sein. Das hat sehr, sehr viele Einflüsse. Fangen wir mal vielleicht mit dem Technischen an. Wenn ich meine Cloud-Anwendung nur in Europa deploye, aber meine Kunden hauptsächlich in den USA oder in Australien sitzen, dann hat man technisch immer noch längere Wartezeiten. Einfach durch die geografische Entfernung merkt man, da gibt es halt Latenz und die Produkte fühlen sich halt langsamer an. Das kann man sehr gut beobachten. Es gibt Technologien, die das so ein bisschen vereinfachen, aber grundsätzlich, wenn ich halt Kunden weltweit bedienen muss, muss ich in der Regel halt auch mehrere Data Center einfach aus technischen Gründen betreiben, um halt näher an den Kunden zu sein. Dann gibt es natürlich diesen Thema Data Privacy. Wir haben in der EU GDPR als ein Hauptthema. Das heißt, dass es Regularien gibt in den verschiedenen Ländern, die einen verpflichten. dass die Daten physisch und damit die Server, Data Center physisch in den jeweiligen Ländern stehen. Und da muss man dann halt genau verstehen, also da gibt es einmal EU-weit regulieren, da gibt es aber teilweise noch in den Ländern verschiedene Sachen. Kalifornien zum Beispiel hat auch eine eigene Datenschutzrichtlinie. Man muss halt schauen, in welchen Ländern man aktiv ist, was man benötigt. Ein weiterer wichtiger Punkt ist, je nach Markt sehr unterschiedlich, der Markt-Entry. Gerade wenn man in China aktiv sein muss, ist es halt nicht so einfach. Also alle großen Anbieter haben da auch Data Centers, aber da gibt es dann in der Regel besondere nochmal Einstiegshürden, die man quasi erfüllen muss. Und es ist dann häufig auch so, dass vielleicht typischerweise, wenn man zu einem modernen Hyperscaler geht, die bieten ja sehr viele Services an, dass diese Services in bestimmten Ländern, gerade wie China, noch nicht verfügbar sind. Und das muss man dann natürlich auch in seiner Technologie-Architecture mit beachten. Der letzte große Punkt, was halt auch immer wichtiger wird, ist das Thema Sicherheitsanforderungen, Zertifizierungsstandards. Es hängt dann sehr stark von den Industrien und den Kunden ab, muss man sowas wie einen ISO-Standard erfüllen, muss man sowas wie einen SOC 1, SOC 2 erfüllen? oder dann gibt es gewisse Sicherheitsstandards, zum Beispiel besonders in den USA, wenn es um Gesundheitsdaten geht, die man erfüllen muss. Hier sollte man sich halt von Anfang an einen guten Blick machen, seine Go-to-Market-Strategie, das ist das, was ich meinte, also die Firmensstrategie, die Go-to-Market-Strategie muss am Ende auch mit der Technologiestrategie abgestimmt sein, dass man sicherstellt, dass man die Zertifizierung, die Privacy-Richtlinien in den Ländern, in denen man die Software verkaufen möchte, dann halt auch wirklich erfüllt am Ende.

Joel Kaczmarek: Gut, verstanden. Also mit Blick auf Markt und Geografie nochmal zusammengefasst, Datenschutz, Security, Markteintritt und technische Sachen wie die Latenz. Wie ist es mit Deployment, weil du hast ja vorhin auch schon mal On-Premise, also die Software läuft bei mir versus Cloud angedeutet. Welche Rolle der Entscheidung spielt das? oder ist das nur so ein relativ schnell abgehandelter Special Case, dass eigentlich nur wenn ich für die Schweizer Regierung irgendwie was baue, ich mir aber im Präsenz noch Gedanken machen muss?

Björn Wagner: Also das ist halt von der technischen Seite eine sehr, sehr wichtige Entscheidung, weil es heutzutage sehr viele Sachen vereinfacht, wenn ich eine Multi-Tenant Public Cloud betreibe. Also es gibt nicht nur, das ist auch wieder ein Spektrum, es ist nicht nur On-Prem und Public Cloud. Dann gibt es auch inzwischen Private Cloud Ansätze, die so eine Art Mischung dazwischen sind. Aber hier technologisch ist das sehr, sehr wichtig, weil wenn ich nur quasi eine Public Cloud Anwendung betreibe, habe ich halt einen sehr, sehr einfachen Job, gerade beim Thema Operations. Um mal ein Beispiel zu nennen. Wenn der Kunde mit einem Bug kommt, dann ist bei On-Prem immer die erste Frage, ja in welcher Version tritt das denn jetzt eigentlich auf? Dann müssen die Entwickler den Bug versuchen nachstellen zu können, dann müssen sie erstmal die Version finden und so weiter. Wenn alle im Public-Cloud-Bereich, alle Systeme auf einer Version laufen zum Beispiel, ist halt quasi das Thema Operations, Maintenance, auch das Thema DevOps viel, viel einfacher. Was man dann häufig sieht, das ist halt eine Entscheidung, die sollte man treffen, aber was häufig in der Realität passiert ist dann, man hat diese Entscheidung getroffen und dann kommen aber große Kunden an und sagen, ja, wir lieben euer Produkt, aber Cloud geht gar nicht. Das Problem ist deutlich geringer geworden in den letzten Jahren, aber gerade wenn man sich in bestimmte Industrie, Banking schaut, Governance, Verteidigung, dort gibt es halt sehr, sehr starke Auflagen, wieder sehr, sehr starke Richtlinien, dass dort halt einfach Cloud-Anwendungen nach wie vor tabu sind. Und hier muss man dann halt schauen, Da gibt es verschiedene Ansätze, wie man das lösen kann. Grundsätzlich ist es am Ende ein Business Case. Ist mir diese Industrie für mein Produkt so wichtig, dass ich halt eine On-Prem oder eine spezielle Private-Cloud-Lösung anbieten möchte? oder kann ich halt meine Ziele halt auch so erreichen oder ein Wachstum so erreichen außerhalb dieser Industrien, wo ich halt diese starken Anforderungen nicht habe und kann dann halt schneller, effizienter, einfacher mit einer Multi-Cloud-Anwendung laufen.

Joel Kaczmarek: Wie ist es mit Plattformen? Geht ja Hand in Hand, weil du hast ja eben die Hyperscaler schon erwähnt. Welche Entscheidungsmatrizen kommen da zum Tragen? quasi?

Björn Wagner: Ja, Hyperscaler ist auch eine sehr wichtige Entscheidung, die man trifft. Entscheidet man sich für einen, gerade bei kleinen Unternehmen vereinfacht das viele Sachen. Es gibt auch Technologien, die das abstrahieren. Da wäre ich grundsätzlich immer sehr vorsichtig. Hier gibt es auch wieder 80-20. Ja, in vielen Fällen klappt das, aber im Detail wird es dann halt auch sehr, sehr schwierig. Das heißt, wenn ich eine Cloud-Anwendung betreibe die auf allen großen vier Hyperscalern funktioniert, das heißt AWS, Google, Azure und Alibaba, dann habe ich auch im Operations-Bereich sehr, sehr viel Aufwand, um halt sicherzustellen, dass jedes meiner Teams, was die Services auf allen vier Plattformen betreibt hat, auch das Wissen hat um die Eigenheiten, die Probleme der Service, wenn halt schwierige Probleme, Performance-Probleme, Skalierungsprobleme auftreten, die dann doch pro Hyperscaler anders sein können. Hier gibt es halt auch keine Entscheidung. Ich glaube, AWS ist nach wie vor Marktführer. Dort macht man nichts falsch. Es gibt natürlich einige, wenn man vor allem im Bereich Retail unterwegs ist, wird natürlich Amazon noch als starker Konkurrent gesehen und dort gibt es häufig Unternehmen, die dann quasi Probleme damit haben, ihre Daten im AWS Data Center, was Amazon als Konkurrent gehört, zur Verfügung zu stellen. Das heißt, dort könnte dann eher ein Azure oder Google Data Center mehr Sinn machen. Aber es hängt sehr stark auch von dem Use Case ab, oder von dem Produkt ab, was man wirklich betreibt und ob man gegebenenfalls auch in seiner Architektur bestimmte Services aus verschiedenen Hyperscalern nutzen möchte, die einem das Leben oder die Entwicklung einfacher machen an der Stelle.

Joel Kaczmarek: Okay, das war jetzt, sag ich mal, Bereich Hyperscaler nur, aber es gibt ja noch andere Plattformfragen, zum Beispiel Mobile wäre so ein Faktor. Worauf guckst du da?

Björn Wagner: Ja, Mobile klassisch gibt es ja, also als Hauptplattform natürlich iOS und Android. Dann gibt es auch Technologien, die einem wieder erlauben, quasi eine Anwendung Oder in den Framework, dass man die Anwendung einmal entwickelt und die dann automatisiert auf die verschiedenen Plattformen quasi kompiliert werden. Hier gibt es auch leider keine Lösung. Also klar, wenn ich mich entscheide für eine native Entwicklung, muss ich die Anwendung zweimal entwickeln. Dort gibt es dann relativ wenig Reuse. Gerade in einfachen Use Cases oder wenn man ein relativ geringes Budget hat, würde ich halt dann zu den hybriden Ansätzen tendieren. Dort hat man in der Regel weniger Flexibilität, die Anwendung genau auf die User Experience der verschiedenen Plattformen zuzuschneiden, aber die Frameworks sind halt auch dort relativ mächtig geworden. Also wenn ich irgendwie die beste User Experience haben möchte für jede Plattform, würde ich immer sagen, sollte man nativ entwickeln und dann halt die doppelten Kosten quasi in Kauf nehmen. Alternativ sind halt hybride Lösungen auch ein Ansatz. Wichtig ist, man spart sich nicht die Hälfte der Kosten. Es ist trotzdem immer noch natürlich, Tests und so weiter muss man auf mehreren Plattformen machen. Es halbiert nicht die Kosten, aber es vereinfacht das Leben in der mobilen Entwicklung etwas.

Joel Kaczmarek: Gut, und der letzte Punkt, der mir noch einfallen würde, wären eigentlich so zwei Elemente. Einmalseits die Architektur und andererseits die Integration von Diensten ineinander.

Björn Wagner: Genau, also Architektur ist natürlich auch ein wichtiges Thema, stark in der Technologiestrategie verantwortet. Und hier, gerade wenn man jetzt am Anfang ist, stellt sich immer die Frage, also es ist ja so, jeder sagt, man sollte sofort mit Microservice-Architektur anfangen. Weiß ich nicht, es gibt halt auch, gerade wenn man jetzt ein junges Startup ist und erstmal versucht, Problem-Solution-Fit zu finden am Markt, kauft man sich mitunter sehr, sehr viel Komplexität ein, wenn man jetzt gerade auf eine Architektur, die eigentlich hauptsächlich für sehr, sehr große Produkte designt ist, die am Anfang halt viel Geschwindigkeit rausnimmt. Wir haben am Anfang darüber gesprochen, das heißt dann, dass ich vielleicht irgendwann mal einen Wechsel machen muss, aber ich sollte halt ein gutes Verständnis haben mit, Welche Komponenten sind in meiner Architektur? Das heißt zum Beispiel, wie gehe ich vor allem mit Daten-Storage um strukturierten Daten, unstrukturierten Daten? Wie sind meine Application-Server? oder wie sieht der Compute-Layer aus? Welche Technologien verwende ich dort? Da gibt es dann häufig eigentlich relativ gute Blueprints, wenn man jetzt eine relativ standardisierte Anwendung baut, dass man heutzutage im Storage-Bereich eigentlich sehr stark die Hyperlinks Scalar-Technologien verwenden kann und im Compute-Bereich hat sich halt zum Beispiel Cubernetes als Framework durchgesetzt, wo man einen sehr einfachen, standardisierten Weg hat, dann seine Anwendungen zu deployen. Aber hier sollte man immer ein gutes Bild haben, quasi, also dass man, ich würde sagen, die nächsten ein bis zwei Jahre relativ stabil entwickeln kann. Man sollte jetzt aber auch nicht anfangen, sage ich mal, für den ersten Prototypen eine wahnsinnig komplexe Architektur, die für ein Produkt, was wir noch gar nicht wissen, wie es in fünf Jahren aussieht, irgendwie optimiert ist.

Joel Kaczmarek: Cool, lieber Björn, ich glaube, da war so gefühlt alles dabei, was, sag ich mal, kleines und großes an meins, was ja auch wichtig ist, um Technologieentscheidungen gut zu treffen. Dann danke ich dir ganz herzlich für heute und bin schon sehr gespannt, was du das nächste Mal mitbringst. Also, mach's gut, bleib gesund.

Outro: Danke, tschüss. Danke fürs Zuhören beim Digital Kompakt Podcast. Du merkst, hier ziehst du massig Wissen für dich und dein Unternehmen heraus. Wenn du mit uns noch erfolgreicher werden möchtest, abonniere uns auf den gängigen Podcast Plattformen. Und hey, je größer wir werden, desto mehr Menschen können wir helfen. Also erzähl doch auch deinen Kolleginnen und Kollegen von uns. Bis zum nächsten Mal.