Transkript
Sven Johann: Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Podcast. Heute zu Plattformen und zwar wollen wir so von Business Plattformen hinüber zu Infrastrukturplattformen und alles dazwischen besprechen und ja, den Plattformbegriff einordnen. Dazu spreche ich heute mit Erik Wilde. Hallo Erik.
Erik Wilde: Hallo Sven, danke kann ich dabei sein. Ich freue mich aufs Gespräch und auf viel Plattformiges heute.
Sven Johann: Plattformiges genau. wer wer bist du überhaupt?
Erik Wilde: Ja, ich bin ich beschäftige mich seit vielen Jahren mittlerweile eigentlich mit APIs. Ich bin jetzt seit einem knappen Jahr bei INNOQ und in in meiner Beschäftigung mit APIs geht’s halt auch um API Plattform, also das ist ja auch ein Wort, was immer wieder auftaucht und ich habe gemerkt, dass einfach sehr viel auf eine Art dieses Wort verwendet wird in Arten, wo nicht unbedingt beide Seiten immer das gleiche meinen und deswegen finde ich zumindest mal immer interessant, dass man sich überlegt, was meint man eigentlich genau, wenn man Plattform sagt und da so ein bisschen auch mal drüber diskutiert. Da gibt’s auch nicht den einigen richtig den einzig richtigen Weg, was jetzt eine Plattform ist oder nicht, aber jedenfalls diese Verwirrung, die ist mal immer wieder in Weg gelaufen und deswegen dachte ich, es könnte mal interessant sein, das aus verschiedenen Blickwinkel mal zu beleuchten, was jetzt Menschen meinen könnten, wenn sie Plattform sagen.
Sven Johann: Gibt’s gibt’s so eine allgemeine Definition oder eine gültige Beschreibung oder irgendwas, was dem einigermaßen nahe kommt, was eine Plattform im Allgemeinen bedeuten kann?
Erik Wilde: Na ja, das ist jetzt ein bisschen die Frage, auf welchem Level du sein willst, ne? Wenn du jetzt wirklich ganz allgemein sagen willst, du willst eine Plattform Definition, der niemand widerspricht und die alles umfasst, was jemand meinen könnte, dann ist eine Plattform ja wirklich nichts anderes als allgemeinsprachlich. Also das ist halt ein Ding, was irgendwie da steht, darauf kann man bauen. Es hat eine gewisse Stabilität, es hat vielleicht eine gewisse Tragfähigkeit, es ist vielleicht für gewisse Einsatzzwecke gemacht, aber im Prinzip ist es wirklich das, was man ja, ich würde ja sagen schon umgangssprachlich halt unter einer Plattform verstehen würde, ne? Irgendwas unten und da baut man drauf und hofft, dass es ein solides Fundament ist, was das, was ich dann drauf baue, auch vernünftig tragen kann.
Sven Johann: Okay, ja. Ähm was mich so ein bisschen verwirrt, ist so der früher, also vor 8 Jahren, glaube ich, also so ziemlich vor 8 Jahren haben alle Leute über Plattformen gesprochen. Kann ich auch gut erinnern, go to London blablabla Plattform, blablablabla, man ist praktisch untergegangen, ja? Und was die meinten war so Plattform Ökonomie. Ähm also ich habe Plattform sind viele Buyer und viele Seller, ich weiß gar nicht genau, viele Bayer, viele Seller, also soweit wie Amazon Marketplace, Zalando und so weiter, ja? Ähm aber wir wollen ja eher über über Technologieplattformen reden, wobei ich auch so, also da denke ich automatisch an sowas wie AWS oder Internal Developer Platforms. Gibt’s da gibt’s da schon mal so eine harte Beschränkung zwischen den beiden Welten oder oder gibt’s da so einen fließenden Übergang?
Erik Wilde: Also du hast jetzt würde ich sagen schon drei Dinge angesprochen, die ich denke, die man so halbwegs gut unterscheiden kann. Das erste wären halt würde ich so ein Plattform Business, so also auch die Klassiker auch noch neben denen, die du genannt hast halt Uber oder Airbnb, also würde ich eine Plattform aufzubauen ist das Businessmodell. Du verbindest Leute, die irgendwas suchen und Leute, die irgendwas anbieten. Baust du ein Businessmodell darum und das ist dann halt das Business, dass du läufst, ne? Das ist mal ein ein Begriff von Plattform, der sicher sehr bekannt war, vor allen Dingen auch, weil diese Plattform eben sehr stark gewachsen sind und sie riesige Firmen geworden sind und so weiter, was halt an der Skalierungsfähigkeit liegt. Dann am anderen Ende des Spektrums würde ich sagen, sind würde ich diese reinen Infrastrukturplattform, sei es jetzt AWS, früher weiß ich auch noch so aus meiner Zeit oder da gab’s auch, wir sind auf der Windows Plattform oder wir sind auf der Unix Plattform, ne? Da war die Plattform wirklich wir haben halt Computer, auf denen läuft das Betriebssystem mit vielleicht noch ein paar Diensten drumherum und das ist so die Plattform, auf der wir entwickeln. Das ist sicher auch ein sehr gängiger Begriff, aber ist natürlich ein ganz anderer als jetzt halt so eine Business Plattform oder ein Plattform Business so. Und der dritte, den du genannt hast, sind diese Internal Developer Platforms. Das ist ja dann noch mal ein bisschen was anderes, weil es dort ja wirklich darum geht, dass ich mich bemühe für meine Entwickler und Entwicklerinnen in meinem Unternehmen eigentlich eine Plattform zu bieten, also nicht so allgemein wie ja ja, wir benutzen an Windows und jeder macht jetzt mal, sondern man überlegt sich, okay, was brauchen wir, wie können wir die Leute am besten unterstützen, dass sie möglichst schnell produktiv werden, möglichst schnell Dienste entwickeln können, möglichst schnell Dienste verbessern können und dann diese Internal Developer Platforms wiederum, die sind dann eben eher spezifisch für ein Unternehmen und nicht so sehr so eine globale Plattform, wie jetzt halt AWS oder die einfach für für jeden weltweit passen muss.
Sven Johann: Mhm. Und ähm also du hattest ja noch API Plattform genannt, was was ist eine API Plattform in Kürze?
Erik Wilde: Eine API Plattform ist eigentlich größtenteils so ein bisschen das, was wir vielleicht, was du dich auch schon gehört hast, diese diese Amazon Story, ne, wo man halt sagt, äh alles, was in einem Unternehmen digital entwickelt wird, muss auch digital verfügbar sein über ein API. Das heißt halt alle Dinge, die irgendwo entwickelt werden, die müssen auch für andere als Produkt wieder konsumierbar sein, ne? Das ist dann halt über APIs und die sammelt man dann gerne halt in so einer API Plattform. Manchmal wird es auch API Marketplace oder API Portal genannt, wie man es dann nennt, ist auch nicht so wichtig, aber auch das oder da weiß ich dann halt, es gibt diese digitalen ähm capabilities oder hier kann ich was über Kunden finden, über Produkte, über Zulieferer, über alles, was auch immer mein Business ausmacht und da kann ich auf diese Dinge jeweils zugreifen, weil es dort halt APIs gibt, die mir ermöglichen, dann darauf aufbauend auf dieser Plattform aufbauend neue Dinge zu bauen.
Sven Johann: Mhm. Du hast so ein ähm das ist ja auch so ein Vortrag gemacht zu dem Thema, da kam die Business Platforms raus. Ähm also die kamen auch noch dazu. Ist die Business Plattform das gleiche, was ich eben genannt habe mit Plattform Ökonomie oder ist gibt’s dann noch einen Unterschied? Das sind in meinen Augen zwei unterschiedliche Dinge. Also die Plattform Ökonomie, das ist in meinen Augen, da geht’s weniger um Business Platforms und mehr, ist jetzt wunderbar verwirrlich, um Plattform Businesses, ne? Also wo du wo du wirklich sagst, mein Business ist ein Plattform Business. Also ich ganz platt gesagt, heißt ja, dass ich produziere nichts, ich verbinde. Das ist das Motto hinter Uber und Airbnb und so weiter. Die bauen keine Autos oder keine Wohnung, sondern die verbinden einfach ähm Interessenten in Markt. Das ist mal eine eine Geschäftsentscheidung, ne, dass man sagt, das ist das Businessmodell, dass ich beackere, wo ich denke, da gibt’s was zu holen und dann mache ich was. Und wenn ich, wenn ich das gut mache, dann kann ich damit eben sehr schnell wachsen, weil ich eben nichts produziere. Das macht das wachsen halt einfacher. Das ist das ist das Plattform Business, ne? Die Business Plattform wiederum ist dann eigentlich mehr die Frage, was auch immer mein Businessmodell ist, sei es jetzt ein Plattform Business oder ein eher traditionelles lineares produzierendes Business, ich sollte alle die digitalen Bausteine, die ich so brauche in einer wiederverwendbaren, einfach wiederverwendbaren Form zur Verfügung stellen in so einer Business Plattform, wo ich dann sage, wenn ich z.B. eine Bank bin oder hier ist meine Kundenseite, hier ist die Sache für vielleicht Risikobewertung, hier ist die Sache für irgendwie die Assets, die ich habe und so weiter und diese Business Plattform ist dann idealerweise so ein bisschen strukturiert in die verschiedenen Bereiche meines Businesses und da weiß ich dann, okay, im Bereich Risikomanagement habe ich diese und jede Dinge, auf die ich zugreifen kann und wenn jetzt z.B. jemand vielleicht ein neues Produkt entwerfen will für den Markt, dann kann er sagen, okay, ich nehme was aus dem Kunden, ich nehme was aus dem Risikomanagement, ich nehme was von hier und da und kann daraus ein neues Produkt bauen. Das ist nach wie vor ein Produkt, oder? Also da wird dann würde ich was produziert sozusagen, aber durch diese Business Plattform habe ich so ein Bausteinprinzip, wo ich mir das halt einfacher zusammenbauen kann. Ich muss nicht jedes Mal wieder von neuen anfangen, sondern ich weiß, okay, weil wir halt z.B. eine Bank sind, sind wir gut im Risikomanagement, darauf kann ich zurückgreifen, das kann ich benutzen.
Sven Johann: Das wäre aber dann, also wenn ich ich habe als Bank so ein Risikomanagement Plattform, das wäre dann sozusagen eine interne. Ähm. Business Plattform von der Bank, wo Teile von der Bank drauf zugreifen können.
Erik Wilde: Die Business Plattform sind eigentlich immer intern so ein bisschen. Also da ist könnte ich sagen, das ist sowas wie halt so ein Resultat eigentlich vielleicht von der digitalen Transformation oder wie auch immer man das nennen will oder dass du halt sagst, wir möchten uns besser digital aufstellen. Das heißt ja häufig auch, dass man sich natürlich auch intern anders aufstellen muss. Wir identifizieren gewisse Bereiche, wo wir halt Business machen, in diesen Bereichen sollten wir gewisse Dinge digital zur Verfügung haben, damit wir einfacher mit denen neue Dinge entwickeln können und das ist größtenteils mal eher was internes. Ja und unter Umständen werden vielleicht gewisse Dinge davon auch mal externalisiert, wenn man sagt, oh, das ist aber ein Produkt, mit dem wir auch wirklich an den Markt gehen können oder weil unser Risikomanagement ist einfach das Beste, was es gibt. Das bieten wir vielleicht sogar irgendjemand anderem an, aber primär mal ist es was internes, wo ich einfach schaue, dass meine Weiterentwicklung als Business effektiver passieren kann, indem ich halt solche Bausteine zur Verfügung stelle.
Sven Johann: Ah ja, ja, ja. Ja, ich habe also ich war neulich auch mal hier bei einem Kunden und die hatten ihr eigenes Payment, also die hatten halt so ein Payment Service gehabt, den die intern, wo halt die unterschiedlichen Unternehmensteile nutzen für Onlineshops diesen Payment Service und irgendwann haben die gedacht, der ist so gut, also den gibt’s gar nicht auf dem Markt und dann haben die ein eigenes Produkt draus gemacht und den und dieses Produkt kann man halt auch äh kaufen sozusagen jetzt auf dem Markt, also als as a Service Payment Provider, ja, den ich einfach anmieten kann.
Erik Wilde: Na ja, ich meine, die klassische Geschichte dazu ist ja eben genau dieses Bezos Memo von mittlerweile vor über 20 Jahren, ne? Wo halt Jeff Bezos CEO von Amazon gesagt hat, was auch immer intern entwickelt intern entwickelt wird, muss eine Schnittstelle haben. Muss ein API haben im Prinzip, ne? Und und ich meine, das war ja auch, also damals gab es ja AWS nicht. Also die haben ja einfach diese ganzen skalierbaren Computingdienste haben sie ja eigentlich nur entwickelt, weil Amazon einfach ein sehr schnell wachsender Online Retailer war. Und das ist genau die gleiche Geschichte und da haben sie dann auch angefangen gesagt, hey, ein weltweit wirklich skalierbaren Storage Service gibt’s eigentlich gar nicht. Bieten wir den doch mal einfach so als Produkt an für Leute, die viele Daten speichern wollen und eigentlich gar nicht genau wissen, wo und wie. Und so ist ja eigentlich, also die ganze AWS Erfolgsgeschichte ist ja eigentlich genauso entstanden, dass man so eine interne Plattform in dem Fall um um Compute Services dann externalisiert hat, weil man gemerkt hat, das sind Dienste nach denen Nachfrage besteht, die andere so nicht anbieten können im Moment und ähm wie der Erfolg zeigt, war das eine gute Idee.
Sven Johann: Ja, ähm weil du AWS ansprichst, wenn ich mir sozusagen, ich nenne es die Wildische äh Hierarchie, also Infrastrukturplattform. Ja, okay, also auf jeden Fall du hast ja in deinem Vortrag gesagt, es gibt Infrastrukturplattform, Internal Developer Plattform, API Plattform, Business Plattform. Im Grunde genommen, wenn ich auf AWS schaue, ist wo ist der, also wo ist der Unterschied in dem Sinn, weil AWS ist ja eine Infrastrukturplattform, also die wird auch intern benutzt als Internal Developer Plattform, also die AWS Leute, Amazon Leute nutzen. Es wird über eine API exposed und ist ein Business. Also sozusagen AWS oder Azure oder so sind alle drei Dinge auf einmal.
Erik Wilde: Das hängt sehr von der Perspektive ab, ne? Also ich meine, wenn wenn du jetzt auf AWS entwickelst, also wenn du jetzt sag mal, du bist eine Bank und machst irgendwie AWS unter anderem auch, dann ist für dich AWS einfach eine Infrastrukturplattform. Punkt. Das ist das einzige. Du benutzt Dienste von denen und auf den aufbauend hast du vielleicht noch eine Internal Developer Plattform, wo du die vielleicht irgendwie in gewisser Weise vorkonfigurierst, einschränkst, wie auch immer einfacher nutzt oder machst. Also für dich ist dann AWS nur eine Infrastrukturplattform. Für für Amazon natürlich ist es halt alles durch, weil bei denen ist es auch das Geschäftsmodell. Aber ähm das ist halt eine ganz andere Perspektive.
Sven Johann: Ja, ja, ja. Genau, also das war so das war sozusagen die die Frage, also die ich mir gestellt habe, ist es einfach nur eine Perspektive, aber ja, ich schaue auf Amazon, also aus Amazon Perspektive ist es alles vier und aus irgendeiner Consumer
Erik Wilde Du musst noch auf den Zeitstrahl gucken, ne? Also ich meine, es ist ja auch so ganz am Anfang sozusagen gab es natürlich die Amazon Web Services nicht, oder? Dann sind die im Prinzip sind die bei Amazon als kann man sagen Internal Developer Plattform entstanden, ne? Und man hat halt gesagt, okay, unsere Programmierer von unserem Onlineshop, die müssen irgendwie ganz viel Daten speichern können, wie helfen wir denen? Dann hat man mal angefangen so die ersten Versionen von AWS oder sagen wir jetzt von von S3 zu machen. Und ähm und dann ist irgendwann mal wahrscheinlich oder intern das auch mal so gebündelt worden, oder? Dann hat man wie gesagt, oh, jetzt haben wir aber sozusagen wie so ein Business, wo einfach unsere Compute Services sind, oder? Die so intern, hier kann man irgendwie Compute, hier kann man Storage, hier kann man dies und das und jenes. Und dann, ich weiß ehrlich gesagt gar nicht, wann der erste Amazon Web Service wirklich sozusagen allgemein verfügbar wurde. Hast du das noch im Kopf?
Sven Johann: Also ich würde, also es war, glaube ich, S3 und S3 kam 2006 oder so raus. 2006, ja. So könnte es sein, dass wir dann so ungefähr vier Jahre nach diesem Memo, je nachdem, wann genau das war. Ich glaube, da streiten sich auch die Geister so ein bisschen, aber 2002 ist zumindest das Datum, was ich immer sage. Mhm. Und zu dem Zeitpunkt ist es dann halt wirklich externalisiert worden und dann ist dann auch Bestandteil wirklich des Businesses ist geworden, wo man halt sagt, unser Business ist halt jetzt auch ein Plattform Business, ne? Also wir bieten das einfach an als ein Dienst, wo andere sich aufsetzen können. Wobei eigentlich genau betrachtet, ist es kein Plattform Business in dem Sinne, oder? Also ich meine, also AWS ist ja nicht Plattform. Ist jetzt Das ist jetzt ganz übel in meiner äh Hierarchie sozusagen, ne? Weil wenn du nur AWS anschaust, dann bieten sie dir eine Compute Plattform, aber als Produkt, ne? Du gehst hin, weil du Daten speichern willst und kaufst deren Datenspeicherprodukt Mhm. und die müssen das irgendwie managen. Die müssen schauen, dass deine Daten wirklich gespeichert werden und und und so weiter. Also so gesehen ist jetzt AWS selbst ist ja kein Plattform Business. Wenn du verstehst, was ich sagen will. Es ist jetzt hochgradig verwirrlich.
Sven Johann: Also was ich was ich, glaube ich, verstehe ist, wenn ich gucke, also du sagst Amazon ist kein Plattform Business, weil ein Plattform Business ist sowas, was wir eben hatten, also Amazon Marketplace oder Zalando ist ein Plattform Business, weil ich habe halt, ich habe kein, ich habe nichts, ja, ich habe keine Compute Power, ich vermittle nur, ich habe, ich habe viele Buyer und ich habe viele Seller, die ich auf der Plattform sozusagen
Erik Wilde Genau, also nach der gängige Definition von Plattform Business ist es eben genau das, ne, dass du halt Anbieter und ähm und und Käufer in Verbindung bringst und Amazon macht das ja für Compute Power nicht. Also sie bieten ja die Compute Power selber an oder Storage Power, ne? Das da sie verbinden ja nicht verbinden ja nicht. So gesehen eben, wenn man es jetzt genau definiert, müsste man sagen, Amazon AWS ist kein Plattform Business, oder? Es ist eine Business Plattform. Das sowieso. Ja. Aber das Businessmodell, oder? Es ist im Prinzip, was ja irgendwie auf eine Art lustig ist, aber ich bin überzeugt, jetzt verwirren wir alle. Ähm im Prinzip ist es ja ein traditionelles lineares Business, ne? Sie produzieren was, nämlich Datencenter, wo sie in der Lage sind, ganz skalierbar Compute Dienstleistung zu machen und das ist harte Arbeit, ne? Das ist gar nicht wenig Arbeit, die da in der physischen Welt stattfindet und das verkaufen sie dann. Das ist so gesehen ist es ja ein traditionelles Business, oder? dass sie entdeckt haben, da ist ein Markt, wo wir Dinge produzieren und verkaufen können und ähm so so gesehen ist es halt wie wie eine Firma, die Autos verkauft eigentlich, ne? Also ja.
Sven Johann: Genau, also ich ich ich muss sagen, ich ich fand es jetzt gar nicht so verwirrend. Man muss halt irgendwo diese Linie ziehen und sagen, also deswegen hatten wir auch am Anfang diese Diskussion, was ist eine Plattform, ja, ist irgendwas auf auf dem man steht, ja? Also das kann alles mögliche sein, es kann Podest sein, wo ich irgendwie politische Botschaften rüberbringen. Es kann wie bei VW oder bei also allgemein bei Automobilunternehmen einfach so ein eine Plattform sein auf Basis dessen ich Dinge baue, ja? Ähm und dieses viele Käufer, viele Anbieter, das wird ja in aller Regel so Plattform Ökonomie genannt. Das ist halt einfach dieser Begriff, wir haben halt Plattform Ökonomie, oder? Du sagst, es ist Plattform Business. Okay, und jetzt müssen wir noch mal umdrehen sagen, wir haben eine Business Plattform. Anderer Name, ähm ähm aber es bedeutet halt auch was anderes. Da wird halt, also da will man natürlich viele Käufer haben, aber man hat keine, man hat keine Verkäufer sozusagen. Also man verbindet nicht, sondern man hat halt wirklich so eine man bietet was an, ja, was äh und wenn man das skalieren will oder wenn das skaliert, muss man halt mehr dahinter schieben. Da muss halt mehr Compute Power z.B. geben bei AWS oder bei ähm. Ähm AWS ist vielleicht einfacher zu verstehen. Stripe ist wahrscheinlich auch in deiner Definition eine Business Plattform, oder? Also der Bezahldienst. Könnte man so sehen?
Erik Wilde: Ja, eine Business, also ich meine im Prinzip ist ja eine also Business Plattform ist ja nur, dass man sich intern so aufstellt. Im Prinzip heißt einfach ist ein Business, oder? Sie verkaufen halt gewisse Dinge und die Business Plattform ist ja nur eine Art und Weise, wie man sich bemüht sein Unternehmen so aufzustellen, dass man vielleicht neue Dinge schneller entwickeln kann oder dass man die Dinge, die man hat, besser anpassen kann. Also da ist ja genau, dann sind ja diese Dinge wie jetzt z.B. diese diese Autoplattform halt super Beispiele, ne? Wo ja auch für mich als Käufer ist ja relativ schnurz, dass in den letzten, sagen wir mal 20 Jahren extrem dieses Plattformprinzip beim beim Autobauen angewandt wurde, ne? Wo halt die Autobauer gesagt haben, anstatt, dass wir jedes Modell von A bis Z neu entwickeln, haben wir einfach ein paar Plattformen, auf denen wir dann ganze Modellfamilien aufbauen. Mhm, mhm. Das sehe ich ja von außen eigentlich gar nicht als Käufer, ne? Ich sehe ja nur die angenehmen Nebeneffekte, dass die Autos eigentlich erstaunlich billig sind, dass ich eine recht große Modellpalette angeboten bekomme, die auch erstaunlich häufig eigentlich überarbeitet wird und das können die Hersteller nur machen, weil sie halt intern dieses Plattformmodell entdeckt und entwickelt haben und und sehr sehr raffiniert einsetzen, aber das ist eine reine interne Geschichte, wo eben man auch sagen muss halt, wenn du heute nicht in irgendeiner Nische unterwegs bist als Autobauer, also ich meine irgendwie halt, weiß ich, Maserati kann sich es erlauben, wahrscheinlich kein Plattform Modell zu haben, ich weiß es nicht, ne? Aber wenn du sag mal ein Volumenhersteller im Automarkt bist, dann musst du einfach irgendwie Plattform machen, alles andere geht überhaupt nicht.
Sven Johann: Ja, also so ein Gedanke, der mir gerade gekommen ist, äh als ich vor langer Zeit in der Automobilindustrie war, ähm da, also es war Automobilindustrie, aber ich war auch so über, ich sag mal über über den Lehrstuhl und Frauenhofer und so weiter. Also die haben ja viele dieser Kunden gehabt und da war Product Line Engineering war das Ding, ja? Also es gibt Hardware Produktlinien und wir wollen halt auch Software Produktlinien. Alle wollen Software Produktlinien, die Hardware Produktlinien haben und ähm so richtig, also ganz einfach war das nicht so Produktlinien zu bauen und ich frage mich, also da gab’s ja auch so ein, ich sag mal so ein so ein Core Engineering, Core Domain Engineering und ein Variability Engineering und da draus hat man dann halt versucht ja unterschiedliche Varianten zu bauen und ich frage mich gerade, kommt mir so ist, also eigentlich ist eine Plattform, eine Business Plattform ja kann man sehen, das sind so Core Domain Engineering Tasks. Also das sind wahrscheinlich Dinge, die man im in der Firma ziemlich oft braucht, um Geschäft zu machen, ja? Nur, dass ich halt jetzt nicht sage, ich habe irgendwie eine leicht erweiterbare Software in dem Sinn, also ein erweiterbaren Monolith, wo halt, also wo halt am Schluss so ein Stück Software so ein executable raus purzelt, also bei bei Embedded mit Sicherheit, also bei Embedded muss man vermutlich so machen, aber bei Cloudbasierter Plattform würde ich sagen, okay, mein Core Domain Engineering im Sinne, ich will mich hier nicht mit DDD Folks anlegen, ja? Also ich sag halt hier Core Domain Engineering im Sinne von Product Line Engineering, also bitte äh ähm das wäre sozusagen, das wäre heute sozusagen die Plattform, ja? Also ich ich rede mit mir selbst, versuche mir gerade einzureden, dass es so korrekt ist, ja.
Erik Wilde: Ja, du hast wahrscheinlich in dem Bereich äh eigentlich viel mehr Erfahrung als ich, also diese ganzen Sachen auf der Auto, also ich habe mir immer gesagt, ich würde ja gerne mal sozusagen ein halbes Jahr sabbatical machen und einfach nur in der Autofirma rumfragen, sag mal, wie macht denn ihr das mit diesen Plattformen, ne? Weil Mhm. das ist ja schon eine riesen Sache, wenn man sich vorstellt, also diese Plattform sind absolut erfolgsentscheidend, ne? Wenn du die nicht richtig hinkriegst, dann kannst du einfach zumachen als Autofirma. Und ähm und das ist natürlich auch ein bisschen, sag mal jetzt eine andere Nummer wahrscheinlich in in Sachen von, wie viel Aufwand geht da rein, wie schnell können wir die ändern, wenn wir uns geirrt haben und so, als wenn wir halt im Softwarebereich unterwegs sind, ne? Da kann man wahrscheinlich noch ein bisschen eher vielleicht ein bisschen was rumdrehen, aber ich denke, die allgemeinen Dinge, die du gesagt hast, die sind schon super interessant, ne? Also was sind die Sachen, die wirklich Kernentscheidungen sind, die vielleicht auch alle brauchen, oder? Und da ist ja dann siehst du ja auch, wenn wir jetzt wieder mal zurückgehen auf Internal Developer Platforms, da kommen ja dann ganz schnell Sachen rein, wo du sagst, also die Leute im Leben ist eine CD Pipeline haben, sonst können sie sowieso nichts machen. Da müssen vielleicht irgendwelche Security Richtlinien rein, da müssen vielleicht irgendwelche Design Richtlinien rein, da muss vielleicht irgendwelche Observability rein, damit egal welche Software entwickelt wird, wir überhaupt wissen, wie die wie die so unterwegs ist und so, ne? Mhm. Da wird ja dann auch geschaut, dass man sagt, okay, was sind die Dinge, die immer wiederkehrende Arbeiten sind, die verschiedene Teams machen müssen, die auf eine Art nicht wirklich wertstiftend sind aus Unternehmenssicht, sondern einfach Dinge sind, die man halt machen muss und wie können wir diese Dinge so einfach wie möglich machen, damit wir mit denen so wenig wie möglich Zeit zubringen und dann machst du die halt in so einer Plattform, ne? Und im Prinzip ist ja genau das gleiche wie auch beim Autobau, wo du auch sagst, ja, es muss ich jetzt nicht irgendwie halt jedes Team einzeln überlegen, wie man jetzt irgendwie halt Bremsen baut, sondern da braucht man vielleicht die Bremsen für die kleinen Autos, die Bremsen für die Mittelklasse Autos und die Bremsen für die schweren Autos, oder? Und dann dann war das mal gemacht und dann kann sich jedes Team, was jetzt halt ein Auto aus Klasse A, B oder C baut, kann jetzt sagen, okay, um die Bremsen müssen wir uns nicht mehr kümmern. Die sind einfach da und die Bremsen. Ja. Und im Prinzip ist das ja so so, wenn man ganz Highlevel guckt, ne, ist das genau die gleiche ökonomische Abwägung und dann wie wie häufig müssen wir Bremsen Design und wo schieben wir das so hin, dass wir am Ende gute Bremsen haben, aber möglichst wenig Aufwand damit verbracht haben, weil weil es kauft ja auch niemand ein Auto, weil es gute Bremsen hat. Also es kauft man kauft ein Auto nicht, wenn man weiß, dass es schlechte Bremsen hat, aber die müssen einfach drin sein und funktionieren.
Sven Johann: Ja, also für mich war bis bis eben sozusagen, hatte ich so ein paar Probleme, diese Business Platforms zu verstehen, muss ich sagen. Also, weil ich immer gedacht habe, eine Business Plattform ist immer was externes, aber stimmt gar nicht, ja?
Erik Wilde: Sehe ich jetzt, würde ich nicht so, also ich will auch überhaupt nicht, also ich meine, keine der Dinge, die ich sage, sind irgendwie, ich kann ja hier nicht die Wahrheit verkündigen, ich bin nicht der Plattform Papst, ne? Aber wenn du dir anschaust, was z.B. also ich lese noch gern irgendwie so McKinsey Publikationen, Deloitte, Harvard Business Review, also all die Leute, die so ein bisschen strategisch gucken, aber schon auch sehr auf Technologie schauen und so. Mhm. Und bei denen würde ich jetzt schon sagen, ist der Begriff der Business Plattform immer sehr stark geprägt dadurch, wie du dein Unternehmen, wenn du jetzt halt irgendwie CTO bist oder irgendwie so, ne? Also wie stellen wir Unternehmen und unser Unternehmen so auf, dass wir einfach möglichst schnell die Dinge, die wir machen wollen, auch machen können und auch auf eine effiziente Art und da sind diese Business Platforms einfach sehr populär, würde ich sagen aus meiner Sicht, aber es ist schon viel mehr intern. Es hat nichts damit zu tun unbedingt, dass das jetzt nach außen hin sichtbar wird.
Sven Johann: Ja, ich hatte nie so so wirklich drüber nachgedacht, aber vor also Michael Plöd, unser Kollege, der hat ja Team Topologies das Buch übersetzt, ja, die deutsche Ausgabe und mein Team Topologies sagt halt auch, wir haben vier Teamtypen, also sagen wir die drei wichtigsten Streamline Teams, enabling Teams und Plattform Team und Plattform Team macht so das, was du eben gesagt hast, also ist so weitläufig bekannt, also sozusagen Shift Down, ja? Also Dinge, die die man haben muss und für die wir irgendwie die schwierig sein können, ähm das äh die lagert man in Internal Developer Platforms aus oder eigentlich, also das war so mein Verständnis, aber Michael Plöd hat auch gesagt, es stimmt gar nicht, ja? Also denk doch mal auch an wir hatten mal so ein Fall so ein ich sag mal, da war glaube ich ein interner, ich habe es jetzt wieder vergessen, Transkribierungsservice. Also es war auf jeden Fall so so ein Service, der nicht Customer facing war. Also es war aus einem aus einem Schulungsbeispiel, deswegen kann ich so genau dran erinnern, aber es war jetzt nicht Customer facing, war ein Teil eines Value Streams, aber es war was, dass mehrere Teams benutzt haben und das war für ihn auch eine Plattform, ja? ich ja, okay, kann man so sehen, aber ja, macht auf jeden Fall ähm macht jetzt für mich mehr Sinn. Gut. Business Platforms. Ähm so vorerst ist mein Also wäre ich damit erstmal durch. Ich wollte noch mal auf API Plattformen zu sprechen kommen, weil so meiner Meinung nach ähm Internal Developer Plattform, Infrastructure Plattform, Plattform Ökonomie, das sind so Sachen, die versteht, also die versteht man einfach, also ich zumindest. Ich habe noch so ein bisschen das Problem Business Plattform zu verstehen und API Plattform auch. Also du, du bist, du hast ja gesagt, du bist äh beschäftigst dich seit Ewigkeiten mit APIs, deswegen bist du auch zu Plattform gekommen. Wie wie also was macht eigentlich eine API Plattform aus? Was was ist das? Wenn jetzt eine Firma zu dir kommt und sagt, wir brauchen eine API Plattform oder du sagst API Plattform ist keine Ahnung, was das Problem ist, aber API Plattform ist die Lösung. Nee, war nicht das.
Erik Wilde: Genau, das sage ich immer. Äh Ja, vielleicht können wir es mal nach unten abgrenzen so ein bisschen auf eine Art. Also wenn du jetzt, wenn du anschaust, was heute so als ähm Internal Developer Plattform propagiert wird, dann sind das eigentlich meistens und wie gesagt, ich ich bin ja nicht der Eigentümer dieses Begriffes, ich ich schaue nur, was so Leute sagen und erzählen. Mhm. Dann sind diese Internal Developer Plattform häufig wirklich, wie du so ein bisschen gesagt hast, diese Effizienzverbesserung, oder wo man Dinge in die Plattform runter pusht und sagt, es sollte sich nicht jeder mit diesem Problem beschäftigen, sondern das wollen wir produktisieren und dann wird es in so einer Internal Developer Plattform zur Verfügung gestellt und jedes Team, das jetzt sowas braucht, kann das einfach benutzen und muss nicht von vorne wieder anfangen sich zu überlegen, was was machen wir denn jetzt für für Monitoring oder für für Security oder solche Dinge, ne? Also das sind Effizienzsteigerung in meinen Augen, die größtenteils davon herrühren, dass ich eben viele Teams habe, die alle möglichen Dinge tun und einige dieser Aufgaben sind halt wiederholte Aufgaben und wenn ich die dann identifiziere und in die Plattform pushe, dann kann ich halt habe ich Effizienzgewinne. Was man da eigentlich nicht anguckt, häufig in dem Bereich, das ist sich zu überlegen, na ja, ist ja gut und schön, wenn die jetzt irgendwie Monitoring ähm schneller machen können, aber kommen sie denn z.B. irgendwie einfach an Kundendaten ran, ne? Oder ähm müssen sie jetzt, wenn sie gewisse Dinge, die irgendwo im Unternehmen schon mal gemacht wurden, finden Sie die, können Sie die einfach benutzen? Gibt’s gute Schnittstellen, mit denen man auf diese Dinge zugreifen kann. Da geht’s dann nicht so sehr in meinen Augen um Effizienz, sondern mehr um Effektivität, dass ich mir wirklich überlege, okay, also, ich möchte nicht, dass ich jetzt irgendwie jedes Team sich neu überlegen muss, wie man z.B. so ein klassisch Beispiel sind so eine Know Your Customer Services, ne? Das sollte nicht jedes Team neu erfinden, sondern das ist eigentlich dann auch ein Ding, was entwickelt wird und dann wieder verwendbar sein sollte, weil ich das wahrscheinlich in einer ganzen Reihe von Produkten dann benutzen kann. Dafür soll es ein API geben und dieses API wiederum wird dann in eine in einer API Plattform auffindbar sein. Also, wenn du auf dem Level schaust, oder dann ist eine API Plattform, wenn du so willst, so ein bisschen die die technische die Infrastruktur Repräsentation halt von so einer Business Plattform eigentlich. Also am Ende müssen ja diese Business Plattform Dinge, die du da irgendwo vielleicht in so einer Tabelle schreibst, müssen ja irgendwo auch technisch zugreifbar sein und das sind dann häufig einfach API Plattform.
Sven Johann: Mhm. Also eine Internal Developer Plattform hat ja auch eine API, aber die API kann halt alles mögliche sein. Es könnte äh Dokumentation sein, das könnte tatsächlich so ein, ich sag mal irgendwas, was man programmatisch, also machen kann. Ähm können Templates sein, aber die das was du mit API Plattform meinst ist tatsächlich, da gibt’s Rest eine Rest Schnittstelle oder so ein Data Contract. diese Sachen muss es geben plus es muss eine möglich, also es muss irgendwie organisiert sein. Also jetzt so bei, wenn ich so Data Contracts denke, denke ich automatisch an hier unser Tool den Data Contract Manager, also es gibt diesen Ort und da kann ich, ich brauche irgendwie Know Your Customer, was auch immer ist, dann weiß ich äh finde ich in unserem in unserer API Plattform, das kann sowas sein wie der Data Contract Manager oder ich sag mal sowas wie wie Backstage von von Spotify. Ja, also ist irgendein Ort, wo man nach APIs suchen kann sozusagen, wo die katalogisiert sind.
Erik Wilde: A, wo die katalogisiert sind, ja, auch B, wo sie hoffentlich so im Self-Service Sinne auch nutzbar sind, ne, dass ich dann auch nicht irgendwie so eine drei Monats Integrationsübung habe mit so einem Team, sondern dass ich dann wirklich einfach so ein Dienst nutzen kann. Und was natürlich auch noch wichtig Punkt ist und das ist eigentlich viel, womit wir viel Zeit zugebracht haben, als ich jetzt wirklich noch mehr so exklusiv im Bereich APIs unterwegs war, es sollte dann eben auch wirklich gut designte APIs geben, oder die halt wirklich sich spezifisch überlegen, was braucht jemand, der ein Code neuer Customer Service benutzen will, ne? Also das sind dann mehr so outside in gedachte APIs, also outside von jetzt vom Neuer Customer Service gedacht, ne, nicht von der Organisation her gedacht. Und und das ist eben so typisch gewesen für eine lange Zeit, es wird jetzt besser. Entschuldigung, das ist immer noch ein bisschen so. Das in vielen Organisationen diese APIs eigentlich, die die gibt’s irgendwie, aber die sind halt ganz obskur, weil die sind halt meistens sehr von der Technik getrieben, oder und da weißt du, wenn ich jetzt, wenn ich jetzt irgendwas rausfinden will über die Kunden, oder da gibt’s dann irgendwie diese 18 verschiedenen Datenbanken, wo ich genau wissen muss, wie die funktionieren, wie die Felder codiert sind und so weiter. Und wenn ich diese 18 Datenbanken dann tatsächlich in der Lage bin drauf zuzugreifen und genau weiß, wie das alles funktioniert, dann komme ich auch daran. Mhm. Und das ist dann sozusagen die Schnittstelle und das ist halt sehr sehr aufwendig, wenn ich das jedes Mal machen muss. Und dort wäre die Idee, dass man eben sowas eigentlich auch besser designt und sagt, nein, das ist was Wichtiges, oder das ist sozusagen konzeptionell Bestandteil von unserer Business Plattform, was sollte das heißen? Es ist einfach zu nutzen und deswegen bauen wir auch ein API, was halt wirklich gut designt ist und das ist halt was, wo immer noch, würde ich sagen, viele Organisationen halt zu tun haben.
Sven Johann: Ja, ja, also bei meinem aktuell, also mein, wie soll ich sagen, Hauptkunden, also da wo ich die meiste Zeit verbringe, ähm da flippen Leute regelmäßig deswegen aus, ja? Also ich als Consultant bin ja Leid gewohnt, aber da ist so, äh wir haben, wir nutzen ganz viele interne Schnittstellen und die sind kein, also sind grausam zu nutzen, ja? Und ähm Ja. Und die funktionieren auch nicht so richtig, also von von in allen Dimensionen, die die sind sind die schlecht, ja? Und dann dann reden wir mit den Schnittstellenbetreibern und sagen, hey Leute, ihr äh also die Schnittstelle, die wir von euch, die wir nutzen, also eure Schnittstelle und die auch, wir haben auch mit anderen Schnittstellen Consumern gesprochen, die ist irgendwie, die ist doof, ja? Also so vereinfacht ausgedrückt, ja? Und dann hat man, dann sagen die, ja, nee, wir haben uns halt überlegt, die ist total super. Ja, und wir so, nee, aber also alle Leute, die die konsumieren, sagen, die ist doof. Ja, und warum, also ihr ihr ihr bietet doch einen Dienst an. Ihr müsst doch mit uns Konsumenten sprechen, was wir brauchen. Und das sind wirklich schmerzhafte Diskussionen, also, weil manchmal sagen Leute, glücklicherweise, ah, stimmt, so haben wir noch nie drüber nachgedacht, äh ich glaube, wir ändern das, ja?
Erik Wilde: Ist aber alles aber auch irgendwie ein bisschen komisch auf eine Art, aber okay, immerhin mal.
Sven Johann: Aber aber aber das, ich sag mal, das ist immer Grund zur Freude, weil kann man sagen, ja, okay, so hat man halt in Anführungszeichen früher gedacht, ja? Also ich, ich biete was an, ich muss Daten exposen, Service exposen und ich mache das halt nach meinem besten Wissen und Gewissen, aber okay, jetzt ist halt neue Denke und dann machen die das, aber andere weigern sich, ja? Die sagen halt einfach, also für uns ist am, für uns ist einfach am einfachsten so, wie wir das machen. Ja, aber für 80 Teams in dieser Organisation ist es irgendwie ganz schön schlimm. Für uns ist am einfachsten, ja? Und ähm also ich, ich will nur sagen, äh ich kenne mich mit dem umgekehrten Problem, I feel it, ja? Also, dass
Erik Wilde: Na ja, das ist dann halt so ein bisschen, wie soll ich sagen? Ist jetzt wahrscheinlich auch ein bisschen unpopulär das so zu sagen, aber es ist dann so ein bisschen wie Planwirtschaft halt, ne? Wo einem irgendwie eigentlich egal ist, wie gut es für die Konsumenten passt und irgendwo hat jemand halt den großen Plan gemacht und dann wird da weiter gemacht und für mich ist es halt irgendwie ähm ja, also ich, ich kümmere mich auch nicht groß drum, ob es jetzt für die, für die ich da produziere jetzt wirklich irgendwie passt oder nicht. Ähm ja, und dann technisch irgendwie geht’s, oder? Also irgendwie es ist einfach nicht wirklich eine effiziente Art Dinge über die Bühne zu bringen.
Sven Johann: Ja, also die sagen wir mal so, die also die API Plattform zusammengefasst ist halt ähm ich versuche aus der Kundensicht eine möglichst gute API zur Verfügung zu stellen, die ist einfach benutzbar und so weiter und die ist auch einfach auffindbar, ja? So, also die funktioniert, die macht das, was die Leute brauchen und die ist einfach auffindbar.
Erik Wilde: Das wäre der Idealfall, ja? Also ich meine, es gibt natürlich auch es sind zwei unterschiedliche Dinge, ne? Entschuldigung. Auffindbar ist ja nur eben, weil es auffindbar ist. Das heißt ja überhaupt noch nicht, dass es gut ist, ne? Auffindbar ist schon mal eine Dimension von gut, aber wenn du dann was findest, was ganz ganz schlimm ist von der Benutzbarkeit her, dann hast du halt auch ja, hast du immer noch sag mal eine Menge an Problemen. Und der Teil ist natürlich viel schwieriger. Also der der einfachere Teil ist natürlich überhaupt mal so ein so ein Inventar zu machen, ne? das das geht noch so ein bisschen einfacher. Wenn es dann darum geht, das Inventar so zu verbessern, dass es wirklich gute Produkte sind, das ist natürlich auch viel aufwendiger. Das geht länger oder da musst du den Leuten erklären, warum das sinnvoll ist. Du musst dir noch erklären, was jetzt eigentlich ein gutes API ist, wie design man ein gutes API, dann müssen es auch noch machen. Also das ist halt, das ist viel Aufwand. Das geht halt lange. Also ist halt auch nichts, das kann man ja nicht so irgendwie von heute auf morgen, sondern das ist dann einfach eine Investition irgendwie in die Zukunft, wo man sagen muss, ja gut, langfristig ist das wahrscheinlich sinnvoll. Ab jetzt versuchen wir die Dinge mal in diese Richtung zu bewegen und dann geht’s halt auch so einige Jahre, bis man dann mal all die nicht so tollen Dinge dann mal mit der Zeit halt so ersetzen kann.
Sven Johann: Und die Auffindbarkeit, also ich habe ja da jetzt so zwei Tools aus bestem Wissen und Gewissen genannt, aber wie würde man, wie macht man die auffindbar?
Erik Wilde: Ja, also sowas in der Art. Ich meine Backstage ist sicher etwas, was ähm gewisse Popularität gewonnen hat. Backstage ist verhältnismäßig komplex und kann auch noch ganz ganz ganz viele andere Dinge. Also von Backstage hört man auch so ein bisschen finde ich immer ja, schon Stories, dass Leute finden das ein bisschen Overkill, also ist irgendwie es funktioniert und ist gut, aber ist halt irgendwie echt so ein sehr sehr großer Hammer, mit dem man da irgendwie drauf losgeht. Und dann gibt’s halt auch auch immer mehr wirklich so dedizierte Produkte, also mittlerweile es kommt mir in Sinn APIbility. es gibt diverse Firmen, die einfach als Geschäftsmodell einfach im Prinzip API Kataloge oder Marketplaces, wie auch immer sie die Dinger nennen, aber genau das eigentlich haben. Also das zeigt, glaube ich auch, dass da das Bedürfnis schon ein bisschen wächst, dass es jetzt halt wirklich so Produkte gibt. Das hatten also früher die API Management Vendors, die hatten das so an der Seite und das waren meistens auch jetzt, die waren nicht so toll. Das waren irgendwie so rumgeschraubte CMS, wo sie irgendwie so ein bisschen was mit dem CMS gemacht haben und gesagt haben, so, das ist jetzt unser API Portal. Mhm. Und da gibt’s jetzt bessere, würde ich sagen, Entwicklung in dem Markt, aber im Prinzip sind solche Dinge, ja, wo man auch das größte Problem ist gar nicht so sehr, was man jetzt für ein Produkt dafür nimmt, sondern mehr eben, wie man auch wirklich mal die Qualität von APIs sich bemüht sicherzustellen oder zu verbessern und B dann halt auch Prozesse hat, wie diese Dinge auffindbar gemacht werden. Da kann einem natürlich so eine Internal Developer Plattform auch helfen, oder dass man halt auch sagt, hey, ihr müsst halt z.B. eine Open API Beschreibung, die muss Teil von eurem Code sein, damit wir diese Open API Beschreibung danach dann im Portal oder in der Plattform veröffentlichen können. Wir machen vielleicht auch noch eine Qualitätskontrolle davon, wir lassen irgendwie Linting Tools drüber laufen, die das mal anschauen. Also da da gibt’s auch immer mehr, würde ich sagen, so so Governance und Prozesse, dass man sich überlegt, wie machen wir auch den Teil, oder wenn wir jetzt allen Teams sagen, ihr müsst APIs produzieren, dann wollen wir es denen ja auch möglichst einfach machen. Und dann ist auch da natürlich der Teil, dass wir man dann auch so in die Plattform pushen wiederum, soweit es halt geht, ne? und sagen, wir bemühen uns den Teams das so einfach wie möglich zu machen, dass sie gute APIs produzieren und das kann man zum Teil automatisieren, zum Teil nicht.
Sven Johann: Ja, also die Diskussion, wie man gute APIs wie man das langfristig sozusagen äh einführt und was das überhaupt ist, wäre sozusagen Story for another Day, ja? Also wären ja ungefähr zwei unterschiedliche äh Podcasts. Ähm Genau, deswegen habe ich erstmal nur nach Tooling gefragt, aber könnten wir auf jeden Fall auch machen, ja? Könnten wir auf jeden Fall mal zwei, also ich sag mal langfristiger Change ist so eine Sache und ähm und was macht eigentlich eine gute API aus?
Erik Wilde: Äh Ja, das sind zwei. Also jedenfalls sind sicher auch zwei Themen, wo eben die sind auf die eine oder andere Art ist da jede Organisation damit beschäftigt, ähm explizit oder implizit und äh ja, könnten wir sehr gerne drüber sprechen, aber irgendwie du sagst, heute wahrscheinlich besser nicht.
Sven Johann: Genau, genau. Ähm um API Platforms abzuschließen. Also du hast eben schon gesagt, ähm Infrastruktur und Internal Developer Plattform ähm erhöhen die Effizienz. Du hast aber auch noch, also in deinem Vortrag gesagt, API Plattform sind gut für Effectiveness. Ähm was was meinst du genau damit?
Erik Wilde: Also, ich finde diese Unterscheidung ganz wunderbar zwischen Effizienz und Effectiveness, ne? Effizienz heißt ja irgendwie, dass man die Dinge, die man macht, dass man die richtig macht. Mhm. Und Effektivität heißt ja in meinen Augen, dass man die richtigen Dinge macht. Genau, genau. Und zum Teil finde ich das schon ein bisschen so, dass dieser ich muss jetzt vorsichtig sein, wie ich es ausdrücke, aber diese Automatisierung, die ist ja schon, die ist wie so ein bisschen, denke ich manchmal so low hanging Fruit, ne? Da gibt’s 1000 Tools, die man machen kann und irgendwie wunderbar dies und das und jenes und es macht auch große Freude, wenn man es dann alles durchautomatisiert hat und so. Aber wenn man dann am Ende natürlich irgendwie die Teams können zwar ganz schnell entwickeln und alle 20 Millisekunden deployen, aber gibt man ihnen eigentlich die die Bausteine in die Hand, mit denen sie dann auf der Business Ebene wirklich gut die Dinge bauen können, ne? Also, wenn sie dann eben nach wie vor z.B. mit solchen APIs arbeiten müssen, wie du jetzt gesagt hast, wo sie dann sehr lange und sehr schmerzhaft überhaupt irgendwie erstmal was machen müssen, bevor sie überhaupt irgendwo rankommen, dann können sie zwar irgendwie ganz schnell deployen, aber sie haben halt andere Hindernisse im Weg.
Sven Johann: Ja, also interessanterweise, da habe ich noch mal so ein kleines Problem mit der Abgrenzung, weil wenn ich an meine Arbeit mit Internal Developer Plattform denke, ähm ja, wir wollen natürlich Effizienz steigern, die Sachen müssen schneller gehen, aber also mir ist aufgefallen, Requirements Engineering für diese IDPs ist irre schwer, also, dass du die Dinge baust, die die Leute wirklich voranbringen. Also da hätte ich jetzt auch gesagt, das richtig, also das richtige tun, aber das ist ja eher aus, wenn ich ich glaube, versuche das gerade für mich klarzumachen, das ist ja eher aus Plattform Engineering Teamsicht so, also aber auf der anderen Seite, also man man muss diese Internal Developer Plattform, man muss man kann jetzt nicht irgendwie an den an den Needs von der Organisation vorbeibauen, ja, dann nutzt halt niemand.
Erik Wilde: Ja, also eine Gefahr, die ich auch sehe, was man durchaus auch häufig sieht, ist auch so ein bisschen so eine gewisse Plattform Euphorie. Also man man kann ja, man kann ganz ganz viel in so eine Plattform reinpushen, ne? Und bis zum gewissen Grad, glaube ich, macht es eben auch Spaß, weil eben das gibt da immer mehr Dinge und da kann man auch ganz coole Sachen machen und so. Ob das immer unbedingt genau der Aufwand ist, der dann am Ende auch den Gewinn bringt, irgendwie, den man sich erhofft hat, ist wieder eine andere Sache. Also also was ich mich bemühe immer zu sagen, ist, eigentlich sollte man die Plattform, also die Investition in die Plattform, die man macht, sollte man so klein wie möglich halten, oder? sie so groß wie nötig, so klein wie möglich. Gut, sagt man immer, ist halt eine sehr allgemeine Sache, aber die Gefahr ist schon da, dass du halt irgendwie zum Teil optimierst für Dinge, für die du einfach nicht optimieren müsst, ne? Also du musst wahrscheinlich eben nicht irgendwie die gleichen Response Times und und irgendwie Release Frequencies aufrechterhalten wie Google. Also das ist halt einfach für viele Organisationen nicht wirklich ein sinnvolles Ziel. Also man kann natürlich irgendwie mit dem gleichen Hammer dann irgendwie auf sein Problem einhämmern, aber dann ist der Hammer halt ganz schön teuer. Mhm. Und ähm ich glaube, das ist würde ich so auf der Punkt, wo wo es noch schwierig ist, zum Teil da ja, also im Moment sind wir schon leben wir in einem Plattform, sag mal wirklich so der Plattform in einem in einer Zeit der Plattform Euphorie, würde ich sagen, also wo sehr viel da irgendwie der der Begriff rumgereicht wird und da auch mal zu sagen, ja, aber es muss jetzt auch nicht immer alles sein, was geht, sondern irgendwie mal zu überlegen, was brauchen wir denn wirklich? Das ist wahrscheinlich echt nicht einfach, also wie du es auch sagst, also, aber ich denke, da ist das da stehen wir auf eine Art schon noch ein bisschen am Anfang, ja.
Sven Johann: Mhm. Ja, wie gesagt, also ich das das mag sein, wenn wenn jetzt jeder sagt, wir brauchen ein Plattformteam, ja, dass dann halt einfach irgendwas gebaut wird, aber wenn es, ich sag mal, wenn so ein Plattformteam aus Problemen heraus gestartet wird, dann macht man sich ja schon, also dann muss man ja schon irgendwie da rumlaufen und gucken, was gibt’s denn überhaupt für Probleme, was was können wir anbieten?
Erik Wilde: Im Prinzip müssten die ja, ich meine, wenn du dir wirklich überlegst, wie es wie es sozusagen nach der Reihenlehre sein sollte, ne, dass du sagst, die Plattform sollte auch ein Produkt sein, die sollte wie ein Produkt gemanaged werden, ne? Dann muss alles, was da entwickelt wird, muss sozusagen auch eine Market Justification haben. Also ich muss sagen, oder wir sollten in dieses Produkt oder in diesen Teil dieses Produktes investieren, weil wir am Ende mehr Wert erzeugen, als wir konsumieren damit, dass wir irgendwie das bauen, ne? Und wenn du dafür nicht wenigstens irgendwie plausibel ähm Case machen kannst, dann ist es wahrscheinlich nicht so sinnvoll das zu tun, auch wenn man es könnte. Man also man könnte es, ne? Aber wenn wenn irgendwie Sachen nur einmal pro Jahr passieren, dann muss ich da vielleicht nicht wirklich investieren.
Sven Johann: Ja, ich meine, wenn ist ein internes Produkt, interne Produkte haben Produktmanager. Also wir hatten es damals auch so, das war auch so gehandhabt, die Teams konnten entscheiden, investieren wir das Budget selbst oder geben wir ein bisschen Budget an die an so ein Plattformteam ab und die machen halt dann Dinge. Da und das Budget, also da da musst du halt schon irgendwie, dann hast du deinen internen Kunden, gibt’s konkrete Geld, ist konkrete Geldangaben. Von daher, also deswegen meine einzige Erfahrung war halt schon, da ist klar, wir wollen Teams effizienter machen, aber wir müssen auch effektiv sein und das richtige, also passgenau, zumindest mal für den, man kann nie passgenau alles für alle machen, aber passgenau für ich sag mal den 60 bis 70 % Case der der Teams.
Erik Wilde: Gut. Ja, also ich meine, das wäre aber wahrscheinlich auch noch mal eine ganz eigene Diskussion, die wir führen könnten, die die wird wahrscheinlich heute dann auch zu weit führen, aber eben diese Frage, wie wie macht wie wieso wie setzt man diese interne diesen internen Markt dann um, ne? Also mit dieser mit diesen internen Verrechnungsmodellen, das ja, ich kenne mich da ehrlich gesagt auch nicht so aus, aber da hört man auch nicht nur Gutes, sondern das irgendwie hat zum Teil dann auch, glaube ich, Nebeneffekte, die nicht unbedingt erstrebenswert sind, aber
Sven Johann: Ja, also über Nebeneffekte könnte ich auch relativ viel reden. Negative Nebeneffekte von diesem Modell. Ähm aber okay, Story for another day. Ähm du hattest noch äh angesprochen, da ist jetzt irgendwie so ein Hype und dann muss man immer überlegen, was braucht man denn. Wir hatten uns auch mal die also die Anja Kammer, anderer sozusagen der Co-host vom INNOQ Podcast, wir haben mal so ein wir hatten auch so ein Vortrag zu also wo wo wir ziemlich viel über Platforms und Enabling reden und da ist ein Punkt, wer braucht denn überhaupt so eine Plattform, ja, weil nicht das ist ja nichts für alle, ja? Also Platform thrives with scale, kann man sagen, ja? Also wahrscheinlich ganz kleine Unternehmen, die die müssen sich da keine Gedanken machen. Ab was bedeutet das sozusagen für ich sag mal für deine für deine Hierarchie hier, also ähm wann braucht man ähm wann sollte man über Business Platforms nachdenken, wann sollte man über API Platforms nachdenken?
Erik Wilde: Na, eigentlich immer. Also das heißt ja nicht, dass du was teures brauchst, ne? Also ist ja auch in Team Topologies würde ich ja auch beschrieben, oder diese viable Platform ist ja auch so ein Modell. Es ist ja schon eine Plattform, wenn du einfach vielleicht gewisse Praktiken, die in deiner Organisation praktiziert werden, wenn du die einfach dokumentierst, oder? Und wenn dich jemand fragt, hey, wie setzen wir denn da so ein so ein Repository auf oder dann zeigst du halt auf eine Wiki Seite. Das ist im Prinzip, das ist jetzt noch nicht durchautomatisiert und nichts, oder? Aber die Leute müssen jetzt auch nicht ähm das Rad wirklich von neu erfinden und und das ist eben genau der Punkt, den wir auch gerade eben besprochen hatten, ne? Die Frage, wie viel muss man investieren? Also, wenn ich jetzt natürlich nur einmal pro Jahr irgendein Repository erstelle für irgendwas Neues, was ich anfange zu bauen, dann ist das sicher mal gut genug. Aber es ist natürlich immer noch wahrscheinlich eine gute Sache, wenn ich mir überlege, ja, immerhin möchte ich mal, dass wir da vielleicht gewissen Standards folgen oder dass das immer in gleicher Sache passiert oder und dann sollte das mal jemand dokumentieren und und das passiert ja auch in in vielen Unternehmen, aber dass man das vielleicht auch ein bisschen bewusster angeht einfach und sich überlegt, investieren wir genug, investieren wir zu viel, welche womit bringen Teams mehr Zeit zu, als sie eigentlich zubringen sollten, können wir sie entlasten, was kostet das uns zu entlasten, oder? Das ist so genau die Balance. Und ich habe also auch in dem Vortrag, weil ähm da war ich noch stolz drauf, ähm habe ich auch eine Folie, wo irgendwie drauf steht, you cannot not have a Platform, ne? Weil also die Teams, die man hat, die entwickeln ja immer auf irgendeiner Grundlage. Die fangen mit irgendwas an und legen mal los, ne? Und das ist die Plattform und die ist vielleicht nicht designed worden, die ist halt einfach so, weil ja ja, was macht man bei uns halt so. Oder das hat der der Entwickler, die Entwicklerin, die machen wollten das halt so, ne? Aber das ist ja auch eine Plattform. Also das ist da da passieren Dinge und das mal ein bisschen strukturierter anzuschauen ist wahrscheinlich in in jedem Fall mal eine gute Überlegung und wie viel man am Ende dann vielleicht investiert, das ist sicher dann auch noch mal wichtig, ne? Aber überhaupt mal überhaupt mal dahin hinzuschauen und zu sagen, hier sind wiederkehrende Dinge, was können wir damit machen, was sollten wir da machen? Ich glaube, das ist wirklich eigentlich für alle mal eine gute Idee.
Sven Johann: Okay, okay. Gut. Letzte Frage. Ähm ich habe ich habe hier so ein so ein Home Trainer, also kein Home Trainer, ich habe so ein Fahrrad auf einer Rolle im Winter, ja, also kann ich einfach mein Hinterrad rausnehmen und einspannen und ich war da relativ begeistert sozusagen, ähm dass ich da unterschiedliche Geräte miteinander kombinieren kann. Also, ich habe natürlich so eine App und dann kann man auch noch Herzfrequenzmesser und man kann irgendwie so man kann Simulationen machen, wie ich durch die Alpen fahre, obwohl ich hier bei Regen in meinem Zimmer stehe und das basiert alles auf einem Protokoll, also heißt glaube ich End Plus oder so, ja? Und dann gibt’s unterschiedliche Profile. Also Garmin nutzt bestimmt auch End Plus.
Erik Wilde; Ja ja, die haben es gemacht. Ich glaube, das ist ein Garmin Produkt des Protokoll. Also wir sind aber ganz viel mittlerweile ganz viele Produkte sind einfach lizenziert, ja. Ja.
Sven Johann: Und die die Frage, die ich mir gestellt habe, das ist ja, also das dieses Protokoll hat schon so ein bisschen was von einem digitalen Ökosystem von der Definition, viele Bayer, viele Seller, ja? Ähm ist ein irgendwie korrektes Denken, dass ein Protokoll auch ein digitale eine digitale Plattform sein kann? Also Teil der Plattform. Das ist jetzt ein rechter Sprung.
Erik Wilde: Ähm Ja, aber also bestimmt, oder? Ich meine, das ist ja allein schon mal, also wenn du nur guckst irgendwie so HTTP und so oder also jetzt noch die Protokolle, die jetzt noch ein bisschen allgemeingültiger sind und so, da ist ja irgendwie auch mittlerweile klar, wenn ich jetzt z.B. ein API anbiete nach außen hin, dann werde ich mir wahrscheinlich nicht irgendwie alles neu überlegen, sondern sag wahrscheinlich, ich mache vielleicht ein Rest API über HTTP, also Ja. Ähm ja, das sind natürlich Plattform, oder? Ich meine, da sind ja dann auch immer die großen Fragen wieder, wie sind die lizenziert z.B., also so bei den klassischen Internetprotokollen, die sind halt offen, die kann jeder benutzen, da muss man nichts zahlen. Ich bin mir ziemlich sicher, dass wenn du ein Art Gerät entwickelst, dass du dann Geld an Garmin zahlst. Also da musst du halt wahrscheinlich eine Lizenz lösen, dann kriegst du halt die Unterlagen, wonach du entwickeln musst und so weiter, ne? Und das ist natürlich schon, also, ich habe jetzt keine Ahnung, ich rate jetzt das nur, ne? Aber ich würde mir jetzt denken, damit hat Garmin eigentlich wahrscheinlich auch noch mal einen ganz netten Einkommensstrom eröffnet. Also einfach an an Fitness Equipment, dass da halt sagt, okay, wenn wir in dem Ökosystem mitspielen wollen, dann müssen wir halt die Lizenzgebühren zahlen und dann machen wir das.
Sven Johann: Ja, interessant, ja. Alright. Damit, also ich bin ich bin sozusagen wunschlos glücklich. Gibt’s noch irgendwas, was wir nicht diskutiert haben, wo du der Meinung bist, das will ich auf jeden Fall noch sagen?
Erik Wilde: Eigentlich nicht. Ich glaube, wir haben ganz viele offene Enden gelassen, das ist super. Äh wir haben wir haben mindestens drei oder vier neue Podcast sozusagen gerade noch mal geplant in dem hier. Ähm wir sind aber mal die die verschiedenen Plattformbegriffe durchgegangen. Das fand ich gut. Ich glaube, ja, soweit mal haben wir eigentlich so zumindest mal das ganze Plattform Spektrum haben wir mal diskutiert und eben also, was auch so ein bisschen Das Ziel meines Vortrages war auf den du dich jetzt ein paar mal bezogen hast, oder? Größtenteils finde ich einfach der Begriff als solches ist, ich würde nicht sagen problematisch, aber er ist halt super flexibel und fluffig. Das heißt, wenn man über Plattform spricht, ist es immer eine gute Idee überhaupt mal Moment damit zuzubringen, sich so einzuschwingen, ne? Also meinst du das gleiche, wie ich es meine, weil ansonsten, ich habe das einfach so viel gehabt, dass man hervorragend aneinander vorbei redet. Der eine redet von Plattform Business, der andere redet von Infrastrukturplattform. Also, wenn man über Plattform redet, einfach noch mal so dieses einfach die verschiedenen Bedeutungsebenen im Kopf behalten. Ich glaube, damit lassen sich viele Verwirrungen vermeiden.
Sven Johann: Mhm. Okay, Supi, dann äh sage ich zu allen Zuhörern noch mal vielen Dank oder wie Patrick Kur in seinem Newsletter schreibt: Thanks for making it so far. Und ja, auch vielen Dank an dich Erik und bis dann. Tschüss.
Erik Wilde: Danke auch und ciao.
