Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream, dieses Mal mit Markus Harrer.
Es geht um das Thema Wardley Maps.
Bevor wir da loslegen, noch ein kurzer Hinweis.
Wir haben auf der Webseite eine Umfrage unter Menschen, die unterrepräsentiert sind in unserer Branche.
Da könnt ihr gerne mitmachen.
Ich würde mich freuen.
Das ist noch ein Hinweis.
Ansonsten würde ich sagen, Markus, möchtest du dich kurz vorstellen und etwas zu dir selber sagen?
Sehr gerne, Eberhard.
Vielen Dank nochmal für die Einladung zu Software-Architektur im Stream.
Ich bin der Markus.
Ich arbeite bei der Firma InnoQ.
Dort beschäftige ich mich vor allem mit dem Thema Software-Modernisierung, Software-Architektur.
Ich habe da auch ein kleines Faible, Datenanlösen in der Softwareentwicklung, um eben auch so datengetrieben Software-Systeme ein bisschen auf den Zahn zu fühlen.
Thema heute Wardley Maps.
Das reicht eben nicht, nur im Code herum zu wühlen.
Deswegen wollte ich da mal ein bisschen was erzählen, wie man sich ein bisschen über den Editor-Rand hinausziehen kann mit dem Thema.
Genau.
Dieses Thema mit der Analyse, dazu warst du ja auch schon mal im Stream.
Das würde ich dann nochmal als Episode verlinken.
Da könnt ihr euch das gerne anschauen.
Genau.
Und du wolltest eine Präsentation schenken, beziehungsweise ich wollte das tun.
Da ist sie.
Genau.
Ich würde euch ein bisschen einführen in das Thema und gerne Fragen aufstellen, wenn es was gibt.
Eberhard, auch wenn du es hast, wie immer, gerne reingrätschen und so Diskussionen zu starten.
Mein Plan ist, euch einen kurzen Überblick über Wardley Maps an sich mal zu geben, wo man das eigentlich nutzen kann, wo ich das sehe.
Und dann gehen wir auf ein paar sehr spezielle Sachen noch ein heute, um da vielleicht noch meine Leidenschaft und noch mehr kennenzulernen, warum ich da auf dem Thema so reite.
Erst einmal, warum bin ich eigentlich zu dem Thema auch gekommen?
Ich finde immer, Wardley Maps ist für mich so eine Art Bindeglied ein bisschen, weil wir haben ja irgendwie so einen ewigen Konflikt in der Softwareentwicklung.
Das Management oder das Business schreit immer hier alles zu teuer, geht nichts voran.
Ja, alles ist irgendwie langsam.
Und auf der anderen Seite haben wir so in der Technik was ja immer.
Ja, viele beschweren vielleicht auch hohe technischen Schulden, keine Zeit, Technologie viel zu schlecht.
Und ich finde, es ist immer so der erste Eindruck, wenn man so auch in Filmen reingeht, dass es da so Konflikte oder so Fronten gibt.
Aber ich denke, das muss halt nicht sein.
Also diese Kommunikationsbarriere.
Ich finde, generell ist es so im Business.
Ja, es gibt halt Chancen und Risiko Appetit.
Also mal kurz ein Shortcut irgendwo gehen, Workaround noch einbauen lassen in die Software.
Und was gut genug noch ist und was vielleicht aber dann ein bisschen zu viel auch ist, das finde ich, kommt nicht so an.
Also was ist gerade die Taktik?
Weshalb dürfen wir jetzt beispielsweise kein Clean Code schreiben?
Was sind da die Zwecke?
Dürfen wir das die ganze Zeit nicht?
Und ja, das sind halt so Themen, die eigentlich nicht so richtig ankommen, finde ich.
Unten in der Architektur oder in der Entwicklung allgemein.
Aber auch andersherum, wenn es auch mal zu viel ist, also wenn da irgendwelche coolen Ideen auch wären, andere Technologien anzusetzen oder zu viel meine ich auch, zu viele Schuldenkonsequenzen eben aus diesen kurzfristigen Business-Entscheidungen sind, dann haben wir irgendwie gefühlt auch nicht so wirklich Mittel, um das zu kommunizieren.
Also es prallt irgendwie auch so ab.
Und ich denke, also ich hoffe, also für mich funktioniert das einigermaßen gut.
Natürlich nicht für alle Fälle, dass eben uns Word Demonstrant ein bisschen helfen kann, so diese beiden extremen Business und Architektur oder Entwicklung allgemein eben zusammenzubringen.
Genau.
Also große Hoffnungen.
Ich hoffe, ihr habt auch die Hoffnungen und könnt damit auch was anfangen.
Denn ja, ich möchte ein bisschen weggehen von den typischen Situationen, wo wir versuchen, irgendwas über unser Software-System, ja, fan-up des Codes eben zu erklären, sondern vielleicht mal ein bisschen so einen Tipp geben könnte, wie es mit dem ganzen Software-System generell ein bisschen so auf der taktischen oder strategischen Ebene eben weitergehen kann.
Und ja, wir können halt nicht so gut punkten, wenn wir da in diesem Techie-Sprech bleiben.
Also wenn wir eine gute Idee haben, was wir mit unserem Konglomerat an Code machen können und wir sagen, wir sollten ein Whoopie-Duo hier als Open Source veröffentlichen, bietet sich doch super an.
Ist es vielleicht für uns total klar, dass es so eine Chance gibt in unserem Code.
Aber wenn wir jemanden brauchen, der Geld hat, der weiß dann nicht so wirklich, was wir damit anfangen wollen.
Und die Idee ist da natürlich, wie man es eben so macht, erst mal ein bisschen mehr Struktur reinzubekommen, damit wir erst überhaupt mal wissen, um was es überhaupt geht.
Dann können wir halt ein Software-System mal aufteilen, vielleicht auch mit strategischen Domain Design mal ein bisschen gucken.
Also auch bestehende Funktionalitäten, wissen die, was ist uns wie wichtig?
Und dann haben wir eigentlich schon eine gute Bewertungsbasis und zumindest mal eine Technik, um es besser zu verstehen, worum es bei uns überhaupt so geht.
Aber das Ganze nochmal zu heben, das braucht ein bisschen mehr Connection, glaube ich, auch zu dem Business oder auch zu den Endusern oder die Kunden, die uns im Endeffekt Geld geben, damit die Nutzer entsprechend die Software, die wir herstellen, nutzen.
Und da denke ich, kann Wardley Maps nochmal eine schöne neue Perspektive auch geben.
Das Ganze ist nämlich eher so wertgetrieben.
Das bedeutet, ich schaue nicht auf das System so platt wie auf der linken Seite, sondern frage die Frage der Fragen, wie mache ich das ganze Zeug überhaupt?
Und da stellt sich heraus, dass wir da Nutzer haben, die mit dem System was anfangen möchten und vielleicht wir da entsprechende Komponenten bereitstellen, die voneinander abhängig sind.
Das können wir eigentlich eins zu eins auch aus dem Diagramm, das wir in der Systemsicht haben, so ableiten und dann immer fragen, ja, was stellen wir denn bereit?
Was so ein Nutzer eigentlich so braucht dafür, um ihn eben glücklich zu machen?
Und gehen wir mal von der Domäne aus, dass wir vielleicht sowas machen wie automatisierte Kochlösungen zu verkaufen.
Da könnte es sein, dass ich einen Nutzer habe, der eben jetzt mal so ein Rezept haben möchte vielleicht.
Da gibt es so eine Komponente Self-Chef auf der rechten Seite und da kann man immer wieder fragen, was braucht denn dieser Self-Chef?
Der braucht vielleicht etwas, so eine Idee, was andere so in dieser Jahreszeit in der Situation eben ankochen.
Geht es jetzt vielleicht zu einem Wisdom Blower, das Sorcerer, vielleicht ist das so eine Anbindung an unseren Kühlschrank, der dann auch die Mengenangaben der verbleibenden Salatblätter und solche Dinge eben nochmal mitträgt.
Das Ganze wird irgendwie auch noch andere Komponenten brauchen, um das Ganze mitzunehmen und vielleicht wird das irgendwo gespeichert.
Und das ist halt so eine Idee erstmal, so eine verschiedene, wer braucht was, sich zu machen, um ein bisschen Orientierungspunkte zu haben, für wen wir das System eigentlich herstellen.
Genau, du hast jetzt in der Grafik hier gezeigt, wo ganz oben irgendein Benutzer ist und darunter ist eben, wie du gesagt hast, Self-Chef und dann davon abhängig Wisdom Browser, dann darunter Sorcerer, Magic und die Zentrale.
Und du hast da links irgendwie hingeschrieben, Wert und oben so ein Auge und unten ein durchgeschriebenes Auge.
Könntest du das noch kurz erläutern?
Also bedeutet das, dass Self-Chef jetzt wertvoller ist?
Das Wichtige ist an sich Wert, also eigentlich ist es eine Wertschöpfungskette.
Ich schreibe mal ganz kurz immer Wert hin und zwar ist es mehr so die Sichtweise von jemandem, der die Dinge, die wir herstellen, eben braucht und wie präsent das eigentlich dann ist.
Also deswegen auch noch das Bedürfnis immer wichtig.
Also was ist für einen Nutzer wert, der unsere Lösungen nutzt, wenn er was essen kann?
Das ist eigentlich das Kernbedürfnis.
Das sehen wir halt leider auf keinem Software-Architektur-Diagramm.
Gut, vielleicht in der Architektur-Büro, im besten Falle auch.
Und dann fragen wir immer, okay, wie können wir ihnen jetzt Wert zu seiner oder ihrer Zielerreichung eben bieten, indem wir eben in diesem Beispiel, wenn man inhaltlich nochmal reingeht, so eine Lösung für das schnelle Zubereiten von Mahlzeiten eben bieten.
Das ist so die Idee, dass es unmittelbar im Blick fällt und je weiter es runter geht, desto weiter weg ist ja dann auch so eine Komponente, wie man das auch nennt, von dem eigentlichen Bedürfnis.
Und so irrelevanter ist es auch für den Nutzer, das irgendwie mitzubekommen, was das eigentlich bedeutet und was hinter den Kulissen eigentlich ist.
Bis runter zur Datenbank, wo man auch dann sehen kann, mit einer Wartemap, so ein Nutzer unseres Systems oder ein Kunde, der kommt da gar nicht mit in Kontakt, der weiß das gar nicht, dass es da hinten liegt.
Und man könnte das im Endeffekt noch weiter treiben, diese Wertschöpfungsketten bis runter zum Strom, der gebraucht wird, um einen Computer zum Laufen zu bekommen, wo dann Software installiert ist, die unsere Datenbank betreibt.
Und man könnte es sogar, wenn man möchte, so übertreiben, dass man irgendwann beim Erzabbau ist, um das Metall herstellen zu können, um das Serverrecht zu bauen, wo der Computer dann ist.
Aber gut, also das ist sozusagen die Idee generell erstmal von dieser Wertachse.
Also wir haben etwas, was wir den Kunden als Wert erbringen, das ist für ihn präsent und die Kulissen dahinter, die sind eben weiter weg und müssen ihn nicht interessieren, sollen ihn auch nicht.
Und das wollten wir halt wissen, das ist so die erste Achse, wenn man mit Wardley Maps eben anfängt.
Okay.
Genau.
Da bleibt es aber nicht dabei, sondern die Frage ist, die man sich dann stellen muss, genau, Eberhard, das war nämlich dann ganz gut, dass da schon mal zu sagen, man kann immer dann auch zuerste Blicke schon mal werfen, wie weit weg etwas ist von einem eigentlichen Nutzer.
Und eigentlich, wenn man das in der Praxis dann umsieht, wie weit oder verständlich ist es dann auch für jemanden, der so ein Produkt herstellt, ein Produktmanager, eine Productownerin beispielsweise und in der Attitur, worum hat das denn Relevanz?
Ja, wir können halt ziemlich easy sagen hier bei dem Sales Chef, wenn ein Button grüner statt blau ist, das sieht man sofort, es ist klar, aber wenn wir sagen, hier unten in der Zentrale, in der Datenbank vielleicht sogar, wir haben halt eine Tabelle mit 500 parallelen Spalten, dann ja, keine Ahnung, was das ist, wie das Ganze mit unserem Geschäftsmodell, mit dem Produkt, das wir herstellen, eben zu tun hat.
Das ist halt das Erste, was man so sieht.
Und daran finde ich halt bei Wardley Maps ganz interessant, dass man dann auch als jemand, der in der Softwareentwicklung selber unterwegs ist, auch mal sehen kann, wie man so das Storytelling auch machen muss.
Muss ich mehr mit Analogien arbeiten, um technische oder weite weg vom Nutzer befindliche Komponenten eben zu erklären, oder kann ich einfach offensichtlich direkt loslegen, was man sowieso eh sieht, als jemand, der auch das Produkt eben von außen eben kennt.
Das ist ein bisschen so für mich so der eine Wert von Wardley Maps und auch ein bisschen so ein Gefühl dafür zu bekommen, wie ich reden muss, wie ich abholen muss.
Und ja, das ist schon mal das, wo die Wertschöpfungskette oder die Wertachse auf der linken Seite ganz gut ist.
Und das andere ist, es gibt auch eine weitere Achse, die ist jetzt bei den Lieblingsthemen Software die Tour jetzt für Software Evolution relevant.
Die nennt sich nämlich Evolution, der Evolutionsachse.
Und damit kann man noch ein bisschen einfetzen, wenn man sich dem Ganzen nähert, wie weit entwickelt denn einige bestimmte Themen eben sind.
Und das Ganze ist ein bisschen so in Phasenmodellen aufgeteilt, so Entstehungsphase ganz links.
Da würde man sagen, ja, ich weiß selber noch nicht, was gebraucht wird da draußen, habe null Plan, wie man das überhaupt auch herstellt.
So ganz charakteristisch über Einzelfertigung.
Ich habe es schon mal gemacht, vielleicht einen Piloten geschrieben, wenn ich wieder ein Software System entwickle.
Produkt, das kann man irgendwie beziehen, kaufen.
Da gibt es Lizenzen für, die bepreist sind beispielsweise.
Also so eine Charakteristik, dass ich schon weiß, was ich herstelle, was ich kann.
Und das Ganze auch so, warum Produkt?
Ja, ich weiß, das brauchen da draußen auch welche.
Und deswegen bin ich ja da schon ein bisschen mehr vertreten, auch im Markt.
Wir sind so Gebrauchsgut.
Das sind so Themen wie Asset Service, also alles, was quasi aus der Steckdose kommt.
Das ist eher das ganz Rechte, dass es eh klar, dass es gibt, dass ich herstellen kann, weil sonst kein Massenmarkt dafür existieren würde.
Genau, das finde ich, da kommen wir noch öfter auch drauf auf diese Evolutionsachse.
Und das Wichtige, was die Evolutionsachse behauptet ist, neben diesen Phasen, kommt eben auch vom Begründer von Simon Worthy, da komme ich gleich nochmal drauf auf ihn, dass er mal gesagt hat, dass sich auch diese Komponenten, die wir hier sehen, also diese Kreise, so alles durch den Wettbewerb von Angebot und Nachfrage entwickelt.
Und was bedeutet das übersetzt?
Einerseits natürlich kann ich irgendwas herstellen, aber es wird nicht weitergehen, wenn es niemand braucht.
Also Forschung beispielsweise, so experimentelle Sachen, wo vieles auch irgendwie nicht zum Fliegen kommt.
Und das andere ist, bezüglich der Nachfrage, ich muss auch immer, wenn ich ein Software-System herstelle, in der Lage sein, die neuen Bedürfnisse, die vielleicht aufkommen, weiterhin bedienen zu können.
Und wenn ich da im Hintertreffen irgendwo bin, spätestens im Produktbereich, da bin ich auch in einer Wettbewerbssituation mit anderen Firmen da draußen im Umfeld.
Und da komme ich vielleicht auch irgendwie langsam voran gegenüber den anderen.
Und das führt mich halt dann in die Situation, dass ich dann irgendwann abgehängt bin zu dem Wettbewerb, der eben auf der Angebotsseite eben entsprechend gute Software noch hinstellen kann, ohne sich ein leckerstes System ans Bein gebunden zu haben.
Genau.
Und das Gleiche wieder mit dieser Wertschöpfungskette, genauso wie mit der Evolution.
Ich kann dann für mich, für meine Komponenten in einem Software-System oder für alle Software-Systeme, die ich habe in der Firma, wenn man das größer machen möchte, eben dann auch schauen, wie weit entwickelt denke ich denn sind solche Komponenten.
Und das habe ich jetzt hier gemacht.
Das Sourcerer, also das Ding, das irgendwie versucht, den Kühlschrank automatisch auszulesen, ist vielleicht noch nicht so weit entwickelt.
Hingegen ganz rechts, Logomagic, das Verbrauchs- und das Essverhalten mittrackt vielleicht an der Stelle.
Das ist halt schon sehr weit entwickelt bei mir in meiner Anwendung.
Ja, das ist die Idee erstmal von der Evolutionsachse, wie man das so nutzen kann.
Genau, was halt bedeutet, dass eben durch diese XY-Position, ich hätte es irgendwie herausgefunden, dass eben Logomagic ein Gebrauchsprodukt ist auf der X-Achse und eben vom Wert her eher niedrig, während das, was halt vom Wert her besonders hoch ist, halt dieses Cell-Chef ist.
Und dadurch kriege ich halt eine Orientierung und das ist halt von der Evolution her ein Produkt.
Also ich kriege halt eben tatsächlich durch die Lokation heraus, wo das sozusagen hingehört und diese Eigenschaften halt dadurch ausgedrückt von den einzelnen Komponenten.
Und das unterscheidet es auch vom Diagramm, nicht?
Sorry, also das heißt, ich habe ein Diagramm und dann habe ich zusätzlich noch diese XY-Informationen.
Genau, da sind wir auch an der Endausbaustufe von der Ist-Situation, auch richtig.
Und jetzt hat halt plötzlich, ich sage auch mal Position, hier auf so einem Diagramm, wenn ich es jetzt auch mal, auch irgendwie der Aussage, wenn ich jetzt auf einem Komponentendiagramm aus dem C4-Modell irgendwie eine Komponente nach oben schiebe und nach unten, das ist immer noch das Gleiche.
Und hier hat man halt wirklich gesagt, oder zusammen mit Wortli hat die gesagt, je nach Position und Konstellation und der Beziehungen, also dieser, wer braucht was Beziehungen, haben die einzelnen Komponenten eben eine andere Bedeutung und muss ich anders mit umgehen.
Genau, ganz richtig.
Es gibt auch so eine grobe Skala, also die man dann so fahren kann, aber das ist echt also fast zu grob, dass man halt verschiedene Bereiche dann vielleicht auch, wenn so eine Komponente reinfällt, beispielsweise in den Create-Bereich, was sehr wertvoll ist, was weit oben ist und vielleicht auch im experimentellen Stadium erst entsteht, dass eher so eine Tense ist, wenn man sowas gefunden hat, mal eben weiter zu erstellen oder da eben so eine Komponente reinfällt.
Oder eben neue Ideen mal zu verproben, dass dann halt, wenn es besonders rechts oben Komponenten sind, vielleicht zukünftige Software-Systeme oder Teile des Systems, von denen ich später mal zehren werde, wenn sich herausstellt, natürlich wieder, dass da draußen ein Markt ist und dass ich das hinreichend gut auch umsetzen kann.
Immer diese beiden Positionen sind da immer so zu sagen oder diese zwei Aspekte sind da relevant.
Und in der Mitte, das 0815-Geschäft, da habe ich mich schon gefunden.
Da möchte ich halt gucken, dass ich das weiterentwickeln kann, um eben nicht in so einem Konkurrenzkampf dann hinten dran zu liegen.
Und Outsource sagt man immer tendenziell, vor allem Dinge, die rechts unten so sind.
Da sollte man sich überlegen, wenn das nicht so wertschöpfend ist und nicht im Kernbusiness ist, ob ich das nicht entweder dann ersetze durch andere Komponenten, also Outsource das losbekommen möchte.
Aber eigentlich mache ich was sehr gut, was ich eigentlich nicht so wirklich von den Business-Zielen habe.
Das kann auch mal aus Versehen passieren, also vielleicht one in a million chance, dass sowas mal passiert.
Aber üblicherweise die Komponenten, die eher so im rechts unteren Bereich sind, sind eigentlich so Standard-Dinge, die so gut sind, dass man die eben auch massenweise irgendwo zu günstigen Konditionen beziehen kann.
Irgendwelche Speichertechnologien in der Cloud, irgendwelche Betriebsplattformen, die e-Klar sind, dass man da Software draufpackt und es läuft.
Das sind diese Kategorien.
Du hast ja jetzt hier dieses Document, das ist ja tatsächlich ein Stück Software, was da irgendjemand geschrieben hat.
Das ist eben nicht so technische Infrastruktur.
Da könnte ich jetzt Standard-Software kaufen, oder was ist da die Aussage?
Das ist die Aussage und das Beispiel, dass man eben dann auch diskutieren kann, was machen wir jetzt mit dem Zeug?
Das wollte ich hier mal kurz darstellen.
Wir sind ja eigentlich, unser Kernbusiness ist ja, dieses automatisierte Kochen sozusagen zu unterstützen.
Kernfokusgruppe sind hungrige Leute, könnte man sagen.
Aber wir haben halt aus Versehen so einen superguten Tracking-Algorithmus oder ein Softwarestück gebaut, das besonders gut Nutzerverhalten dann mit tracken kann und ablegen kann in der Datenbank.
Das ist gut, das ist jetzt vielleicht Kern, aber vielleicht ist die Komponente auch zu technisch, weil die auch ziemlich weit unten ist und dann tun wir auch uns immer sehr schwer, vielleicht argumentieren, weshalb wir jetzt da investieren sollten.
Und ich wollte da die Situation aufmachen, was passiert, wenn wir hier jetzt kein Geld zugesprochen bekämen, weil das so fernab und nicht greifbar auch ist für uns, dann kann man überlegen, das vielleicht auch wegzunehmen oder andere Ideen mal weiterspinnen.
Das wollte ich hier auch mal zeigen, vielleicht Dinge ignorieren, weil die gut genug noch sind.
Es gibt noch keine Konkurrenz, da kann man sich auch entspannt zurücklegen.
Vielleicht haben wir von der Geschäftsziel her eine neue Idee, dass wir vielleicht Ressourcer, also diese intelligente Kühlschrank-Kapazitätsplanung, vielleicht weiterentwickeln wollen, weil das so ein zukünftiges Geschäftsmodell ist, vielleicht ein bisschen mehr für den Nutzer auch attraktiver ist, vielleicht einen neuen Markt aufmacht, was auch immer die Gründe sind.
So ein einfaches Beispiel, aber komplexe Diskussionen kann man doch führen.
Und dann sehen wir vielleicht, wenn sich das Ressourcer da irgendwie weiterentwickeln muss, dann sollte auch vielleicht die Datenbank mitgenommen werden, um dann auch so stabilere Systeme im Gesamtfeld eben auch mitzustellen zu können.
Genau, das gehe ich nochmal gleich noch mit darauf ein, was da so Ideen sein könnten.
Und da könnte es wirklich sein, dass man sagt, hey, das rechts unten, warum machen wir das überhaupt?
Das ist so weit weg vom Kunden an sich.
Da gibt es bestimmt einfachere Lösungen, wie du schon gesagt hast.
Lass uns das vielleicht auch verschenken und darüber diskutieren, dass wir eben eine Software ein bisschen entschlacken und uns auf andere für uns wichtige Dinge, was dem Kunden auch wichtiger ist oder dem Nutzer, dann zu fokussieren.
Okay, das heißt, ihr habt so einen Evolutionsplan für die Architektur und habt darüber irgendwie Input, wo ich darauf irgendwie achten muss, welche Qualitätsthemen ich habe und er kann das eben diskutieren mit der Business-Seite an der Stelle.
Genau, das ist so die Idee, also auch, deswegen habe ich das wieder in der Sprache Wingdings übersetzt.
Also wir wissen jetzt gar nicht von außen, was diese ganzen Komponenten sein müssen, sondern dadurch, dass man auch ein bisschen so musterorientiert vorgehen kann, so Abhängigkeitsbeziehungen sieht, Konstellationen sieht, die nicht so vorteilhaft sind, kann ich eben auch sagen, ja völlig ohne in den Technikbereich mit drin zu sein, dass man gewisse Dinge vielleicht mehr machen möchte oder verbessern möchte.
Das wollte ich eben da hinaus und da kann es sein, dass wir, dass diese Komponente hier für uns keinen Sinn ergibt weiterzuentwickeln und wir dann vielleicht lieber Kochtöpfe entwickeln und keine Dev-Tools, wenn es wirklich sehr nah ist, wenn es wirklich so normaler klassischer Log der Software wäre, die wir hier irgendwie nachgebaut hatten, vielleicht mit anderen Begrifflichkeiten, aber konditionell macht das das Gleiche wie alle 115 Logging-Frameworks, dann wäre die Idee zu sagen, ja, rechts unten, wenn das für uns kein Geschäftsmodell ist, dann mal vielleicht verschenken, also Open-Source bereitstellen, weil es doch irgendwie so gut ist, aber nicht zu uns passt und auf Hoffnung, dass vielleicht jemand anderes das macht und das weiter betreibt.
Das wäre so meine Diskussion, die man führen könnte, je nachdem, wie man eben hat und mit wem man diese Art von Diskussionen führt.
Genau, also das wäre so ein Beispiel, habe ich auch nachgebaut, also von Envoy-Proxy, ein bisschen so die Geschichte, um mal alles ein bisschen dabei zu haben, was Word Demapping an sich im Generellen mal mitbringen kann und bei dem Envoy-Proxy, da war es so, da gibt es ja auch wieder so etwas Ähnliches wie Uber, Lyft, heißen die sozusagen eine private Taxifu-Unternehmen, hätte ich schon fast gesagt, die haben sich dabei erwischt, auszusehen, einen superguten Proxy zu bauen, dann haben sie gesagt, nee, es passt nicht zum Kernkontext, lasst uns den rausgeben und an eine Foundation, an eine Community geben, damit das Ding halt weiterleben kann, weil wir ja keine Zeit dafür bekommen oder haben oder wollen.
Daher kommt die Geschichte ein bisschen und zeigt aber auch für ganz normalere Fälle, wo ich dann sehe, hey, wo sind dann Komponenten, die verbesserungswürdig sind, wo baue ich vielleicht auch fackelige Untergründe, wenn ich so Beziehungen habe, wie der Benutzer hat ein Bedürfnis und das wird abgedeckt von einer Komponente, die von einer anderen Komponente, die nicht so weit entwickelt ist.
Solche Themen kann man eben da ziemlich schnell dann eben auch visualisieren.
Ich muss ja gestehen, ich bin so ein bisschen irritiert, dass du da unten bei diesen Sachen, die halt irgendwie Gebrauchsgut sind und eigentlich irrelevant für mein Business, dass du da halt bei verschenken bist.
Ich hätte halt gedacht, dass irgendwie die Strategie typischerweise eher wäre, halt irgendwas zu kaufen und zu benutzen, was halt irgendwie da ist.
Proxys gibt es ja wie Sand am Meer.
Das heißt, Lift hätte ich ja jetzt sagen können, okay, das war es jetzt.
Wir nehmen halt irgendeinen Proxy, der da ist.
Genau, das kannst du auch machen.
Dann würdest du das eben dann replacen.
Also genau, kommen wir auch noch, glaube ich, dazu mit anderen Alternativen und dann hast du natürlich doch die Möglichkeit, da entsprechend davon zu zehren.
Aber je nachdem, wie die Situation ist.
Es könnte auch sein, dass da draußen eben sowas nicht existiert.
Dann würde ich das aber trotzdem nicht weiterentwickeln wollen.
Dann gebe ich das in Hände, die es für mich vielleicht machen.
Das sind also Diskussionen, die man auf der Basis von so Wardley Maps entsprechend dann auch mit einfach diskutieren kann.
Und du hast recht, das Beispiel gibt hat da ein bisschen wenig her.
Aber für den Einstieg und mal zu gucken, welche Diskussion da so entstehen kann, wollte ich einfach mal irgendwie alles auch aufführen, dass wir uns sozusagen da schon mal die volle Bandbreite auch gegeben haben.
Okay, ja, so ist auch nicht alles drauf auf der Map und ich muss auch sagen, wir sehen hier und da kommen auch ein bisschen so zu den Leidensweg, was mit Wartemapping ein bisschen so auch wild ist.
Denn diese Map, die hat jetzt hier an der Stelle ja gerade mal so fünf verschiedene Punkte hier und die Identität sieht ein bisschen heftiger aus.
Und da zeige ich auch noch gleich eine größere Map an der Stelle ein bisschen.
Da muss man sich halt langsam auch ran wiegen, am Anfang nicht alles entsprechend einbauen wollen.
Aber da kommen wir auch noch mal Stück zu Stück zu dem zu sprechen.
Gut.
Ja, das ist mal so zu dem Thema Wardley Maps Einführung, wie man das sehen kann.
So haben wir schon Fragen.
Nee, da sind bis jetzt keine Fragen aufgetaucht.
Also genau, gerne immer loslegen.
Koding, Purpur, Tentakel hat Hallo gesagt.
Das war’s.
Wunderbar.
Gut.
Die Sache ist also eigentlich bin ich ja Charterentwickler.
Wie kommt man eigentlich auf so eine Idee, dieses so in dem Umfeld auch unterwegs zu sein?
Also das wollte ich auch mal zeigen.
Das kommt nicht irgendwie von ungefähr, sondern das ist schon irgendwie so ein langer Weg.
Also vielleicht hat es von euch auch jemand irgendwann durchgemacht.
Und zwar habe ich immer noch nicht irgendwie die Hoffnung oder die Visionen aufgegeben, dass man Zeug irgendwie auch besser machen kann.
Da draußen in der Softwareentwicklung im Kleinen nicht immer das große Ratspringen, sondern jede Firma hat ja auch sehr viele kompetente Leute, die dann mitarbeiten können.
Aber oft fehlt ein bisschen Orientierung, wo es hingehen soll.
Und so habe ich auch gestartet.
Ich wollte eigentlich nur mal Legacy Code eigentlich modernisieren.
Und ja, habe ich was gefunden, Clean Code oder Tidy Code, wenn man heutzutage auch das Transient um Systeme halt wirklich auf Codebene noch ein bisschen besser zu unterlassen.
Und danach ja, was kommt nach der Codebene selbst, wenn man in den Methoden unterwegs ist?
Man sieht dann plötzlich ein Klassen Design, das nicht so gut funktioniert.
Gibt’s auch was.
Dann kann man eben Refactorings durchführen, irgendwie schiefe, krumme Architekturen.
Dann kann man eben auch nachschießen, mal fragen, wofür machen wir das Zeug überhaupt?
Generell mal.
Wie kann man vielleicht Performance Probleme auch wegbekommen?
Qualitätsziele und Taktiken arbeiten.
Und dann habe ich irgendwie auch meine Leidenschaft für Domain Driven Design entdeckt, um auch ein bisschen so ein Connect zu der Fachlichkeit zu bekommen.
Und wenn man aber daran rangeht, generell die Frage zu stellen, ja, was machen wir jetzt mit dem ganzen Zeug, das wir implementiert haben?
Stößt man halt ab und zu auch mal auf so eine, ja, unklare Strategie oder eben auf fehlende Pläne.
Wie ist denn mit dem Gesamtsystem überhaupt umgehend?
Wie man da umgehen soll in ganz großem Umfeld?
Und da bin ich eben bei Wortlimits erst mal vorbeigekommen und habe dann gemerkt, dass ich mit Stück für Stück irgendwie in dem Scope, in dem Bereich damit auch hochgegangen habe.
Also es geht nicht mehr nur darum, also nur in Anführungsstrichen, wie man dann eine gute Entwicklungsorganisation aufbaut, um ja vielleicht auch Teams zu schneiden, die einigermaßen effektiv auch liefern können.
Sondern Wortlimits ist für mich nochmal so ein weiteres Ding, wo man dann auch das Umfeld noch betrachtet.
Was machen die Mitbewerber gerade?
Müssen wir uns überhaupt anstrengen bei der Software Modernisierung?
Können wir das nicht irgendwie anders lösen?
Das sind halt so Diskussionen, die ich ja mit dem ganzen Bereich des Wortlimits da sehe und das ich auch gerne immer mitnutze bei diesen Themen.
Jetzt vielleicht noch kurz dieses Wortli.
Ja, das habt ihr bestimmt irgendwo schon mal gehört, also spätestens hier bei der Einladung.
Aber ich sage immer so, das ist so ähnlich wie das Liftscope-Subsidiationsprinzip.
Liftscope, das ist irgendwie kein Name, kann man immer schwer irgendwie andocken, weil es einfach ein Nachname ist.
Und das Gleiche ist eben für Wortli.
Das ist ja auch kein englisches Wort, deswegen kann ich da keinen Connect machen.
Ich habe es gerade schon mal gesagt, Wortli ist einfach der Nachname von dem Erfinder Simon Wortli.
Auch eine ganz interessante Person.
Er bezeichnet sich auf LinkedIn so auf lawful, chaotic, evil, but often good.
Und da komme ich später noch dazu, was das Ganze bedeutet.
Aber ich sage mal so, ich war schon fasziniert, was er mit dieser ganzen Wortlimitting-Technik so vorhatte.
Ein Ziel ist beispielsweise, Unternehmensberater arbeitslos zu machen.
Ich bin ja nur IT-Berater, also ich sehe mich nicht als Unternehmensberater.
Ja, und ich werde wahrscheinlich meinen Job noch behalten.
Aber die Kernidee ist eigentlich eine andere, sondern zu sagen, die Firmen wissen ja eigentlich schon, wo sie hin möchten und haben eine Idee.
Aber es mangelt ein bisschen so an Möglichkeiten, so strategische Themen zu kommunizieren oder rüberzubekommen oder sich darüber zu unterhalten.
Dann, ja, was gibt’s dann?
Da gibt’s immer eine IT-Strategie, vielleicht ein Unternehmen, die muss ja immer fünf Jahre im Voraus sein.
Also heutzutage bei euch vielleicht die IT-Strategie 2030, wie die IT da aussieht.
Aber konkrete Umsetzungsschritte oder mal Feedback geben, wie es aussieht, hat er ein bisschen nicht so gesehen.
Und deswegen hatte diese ganze Wartemapping-Technik eben auch als offene Lösung dargestellt, wo man sich daraus bedienen kann.
Man zahlt halt im Endeffekt ein bisschen im Preis, sich da einzuarbeiten.
Aber es gibt eine Community und die hilft dann auch einem noch weiter, um da reinzugehen.
Genau, wir hatten den Simon ja vor, ich glaube, einem halben Jahr sozusagen gemeinsam im Stream und dann auch mit ihm diskutiert über das Thema.
Vielleicht kurz, weil Alexander Herold hat gerade gefragt, wie würde ich Wardley Maps einführen, ein gemeinsamer Workshop mit Product oder Product und Devs?
Also das kommt darauf an, also wenn ich es selber machen würde, bin ich immer, also wenn ich jemanden habe, der sich dafür schon auskennt, ist es natürlich gut, das einfach mal so iterativ im kleinen Team eben mit einzuführen oder sich auch mal gemeinsam schlau zu machen.
Also es gibt wunderbare Videos von Simon Wortly, wir teilen auch noch eine, also meine Top 5 Empfehlungen für den Einstieg ins Wortly Mapping.
Wir können auch noch Slides von meinem Workshop mit verlinken.
Das zieht sich ja wieder bei der Community durch.
Meine Slides für einen Zweitagesworkshop sind auf Speakerdeck, da könnt ihr auch gerne durchscrollen.
Da sind auch sehr viele Eigenheiten oder Besonderheiten dabei, auf die man achten muss, um dann auch mal zu starten mit Wortly Mapping.
Was ich nicht machen würde, ist zu sagen, hey, ich habe jetzt hier im Software Lecture im Stream Wortly Mapping gehört.
Ich lade jetzt alle ein, den Chef, die oberste Führungsebene und frage die mal, lass mal loslegen.
Also das würde, glaube ich, also ich finde, das verbrennt das Thema ein bisschen, weil man schon ein bisschen sattelfest sein muss, mal selbst eine Map gebaut haben muss, ein bisschen mal durchdrungen haben muss, wie das Ganze so aufgebaut ist.
Und ja, dann würde ich halt ein bisschen vorsichtiger sein und mit dem Thema ein bisschen so skizzieren.
Wardley Maps auch in klein verwenden.
Das werden wir auch gleich sehen.
Man muss nicht immer das große Ding machen, sondern kann einfach mal anfangen mit kleinen Situationen, die stören und versuchen, das transparent zu machen.
Das heißt, wenn ich es jetzt richtig verstehe, sagst du im Prinzip bei irgendeinem Meeting, wenn sozusagen die Diskussion gerade losgeht, dann würdest du es halt sozusagen aus dem hervorzaubern und das halt irgendwie mal machen und früher würde man sich damit mal irgendwie auseinandersetzen, also vielleicht die Map, die man da irgendwie entwickelt, schon mal früher selber gebaut haben.
Genau, die Diskussion um die Notationen auswegs sein und ein paar Eigenheiten.
Also wann, wo platziere ich jetzt welche Komponente?
Also ein typischer Fehler ist zu sagen, hier Komponente auf der Evolutionsachse zu mappen.
Was ist denn das für eine Sicht, wie gut wir was können?
Das wäre die Standardsache oder wie wir denken, wie die Konkurrenz da steht oder wie wir denken, wo wir hinmüssen in der Zukunft oder wo wir denken, wo unsere Kunden sind, die die Komponente nutzen.
Also was haben die für Ansprüche?
Das sind ja ganz viele Facetten und das muss klar eben während der Moderation eben klargestellt werden.
Sonst kommt man auf kleinen grünen Zweig an der Stelle.
Das wäre so eine Sache, die immer so ein bisschen Probleme macht.
Du hast ja selber gesagt, dass du die Sachen einführst und da als Berater bereitstehst.
Da wäre es ja tatsächlich so, dass du durch die Situation, in der du bist, einen spezifischen Workshop machen müsstest, wo du gerade gesagt hast, das ist eigentlich keine gute Idee.
Da sehe ich so ein bisschen Widerspruch.
Also wie machst du das selber, wenn du als Berater da stehen musst?
Also das Ding ist, ich kann ja nicht zu einem Kunden hingehen und sagen, dass wir Wartemapping machen, weil ich nicht weiß, welches Problem es ist, was sie haben.
Also es kann ja ganz anders sein.
Und wie ich das nutze, normalerweise ist es ja im Rahmen von Architektur Reviews oder Software Assessments, Modernisierungen und meine Taktik ist einfach ganz normal Interviews führen, Systeme anschauen, aber nebenbei mitschreiben oder Fragen auch um das Thema Evolution und Wert, also bezüglich Wartemapping im Allgemeinen.
Sprich, ich stelle mir doofe Fragen, die schon ein bisschen so mir sagen, was ich, wenn ich eine Wartemap dann später brauchen würde, wohin platzieren müsste.
Also braucht ihr es noch?
Was gibt es denn da noch?
Wir hängen das alles zusammen.
Das sind ja ganz normale Interview-Techniken, doofes Nachfragen von jemandem von extern, der etwas verstehen möchte und habe mir angewöhnt, da einfach ein bisschen so in diesem Wartemapping zu denken, in diesen Kategorien, das erst mal mitzunehmen, dann alles sacken zu lassen.
Und wenn es sich anbietet und ich etwas nicht gut auf den Punkt anderweitig noch mit draufbringen kann oder wenn wir etwas Größeres diskutieren möchten und eben mehr Transparenz brauchen, was sie vorhaben, dann steige ich in die Visualisierung ein.
Also quasi, ich sage immer so eine Fight Club Regel, die ich da ausrufe.
Die erste Regel des Fight Clubs ist ja, sprich nicht über den Fight Club und ich glaube, die zweite auch.
Und ich gehe nicht in die Modellisierung rein und sage, ja, lasst uns mal das erst mal mappen und dann überreden, wo die Probleme sind und das andersherum.
Und dann während Berichte oder der Analyse, die später noch aussteht, kann es durchaus sein, dass dann entweder ich eine Wartemap habe, die dann total chaotisch, irgendwie verbleichstift auf dem Papier gezeichnet ist und ich nur die Geschichte daraus ziehe, die ich da sehe.
Oder wenn es sich sortiert, und da werden jetzt auch noch ein paar sehen, halt schöne in PowerPoint polierte Verhältnisse halt mit Wardley Maps nochmal darstelle.
Das funktioniert für mich super gut und nimmt, glaube ich, auch für Teams den Druck aus, diese, ich sage mal, geleckten Wardley Maps auch am Anfang machen zu wollen.
So sieht es nicht aus.
Am Anfang sieht es einfach bloß chaotisch aus und irgendwann nach zehn Iterationen hat man dann was herauskristallisiert und kann es dann anderen zeigen.
Womit du jetzt ja auch indirekt sozusagen sagst, das ist halt ein bestimmtes Denkmodell.
Ich sage, okay, was ist eigentlich das, was tatsächlich den Wert generiert?
Der Kunde steht halt im Mittelpunkt.
Was ist das, was den Kunden sozusagen beschäftigt?
Und dann eben sich die Frage zu stellen, was sind die Dinge, die ich selber machen möchte?
Oder die in diesen verschiedenen Evolutionsstadien sind.
Und das ist ja eine bestimmte Art und Weise, über Software sozusagen nachzudenken.
Und das kann man eben nutzen, ohne Wardley Maps zu machen.
Das heißt also eine Möglichkeit, eine Antwort auf den Alexander wäre im Prinzip für sie halt nicht ein, sondern denke halt so.
Das ist auch richtig.
Ich bin mir noch uneins, ob das gut ist, dass ich jetzt im Wartemapping denke.
Also bisher hat es nicht geschadet.
Also die Fragen sind immer irgendwie, dann bring mich weiter, die ich dann stelle und die Antworten, die ich da bekomme.
Und das würde ich schon sagen, also sich mal zu beschäftigen.
Und es geht auch ganz viel ohne die Visualisierung selbst von Warty.
Natürlich muss man schon ein bisschen wissen, wo das herkommt.
Wir werden jetzt gleich noch über Muster noch sprechen.
Da kommen Begriffe wie Evolution und Wert und so kommen einfach vor.
Und du musst noch wissen, da gibt es ja eigentlich diese Wartemapping-Technik und so sieht die Karte aus und so, damit man das eben alles zuordnen kann.
Genau.
Okay, den einen Gag muss ich jetzt noch machen.
Ich habe es schon angeteasert, Wardley Maps zu lernen ist ziemlich hart und dann gibt es diesen Running-Gag, dass es halt sieben Jahre dauert, um Wardley Maps zu lernen.
Und sechs Jahre und elf Monate dauert es eben, wo man sich immer sagt, ich muss das wirklich lernen.
Und dann schaut man sich das an, hat eine Situation, wo das ziemlich gut passt, wo es einem weiterhilft und dann haben wir es in einem Monat raus.
Also das ist so die Idee oder eben auch das, was mich auch schon fast so getroffen hätte.
Zum Glück habe ich ein bisschen früher angefangen mit dem Ding.
So, ich würde mal ein, zwei Anwendungsfälle zeigen und was ganz typisch sind.
Ich habe jetzt richtig, richtig runter gestrippt, um einfach mal zu zeigen, dass man auch nicht immer so eine große Map braucht, die man als erstes vielleicht bekommt, wenn man mal in Google nachguckt.
Und zwar habe ich meine erste Public Wartemap dabei, also die ich auch mal getraut habe, jemandem zu zeigen.
Und das war so eine Situation, wie gesagt, ein bisschen anonymisiert und verallgemeinert, dass wir einen User haben, der natürlich Zeugs machen möchte und er möchte Zeugs machen, natürlich mit der ultrawichtigen Fachanwendung, mit der das Unternehmen fast die gesamte Kohle macht.
Und da war die Situation so eine Idee, warum nicht dafür ein bisschen eine Plattform zu bauen, so ein selbstentwickeltes Microservices Framework.
War damals so die Idee.
Und es sieht natürlich jetzt eh klar aus, dass man, das ist ein bisschen so, wenn man das über die Wartemapping Technik zeigt, nicht so vielleicht das Beste ist, was sehr produktnah ist, auf was wackelig zu stellen.
Aber das würde man wahrscheinlich auch so sehen.
Sorry, nur kurz, um sozusagen die Abbildung zu beschreiben.
Also du hast halt den User, der was macht mit dieser Anwendung und die Anwendung ist irgendwie ein Product, also ist halt eher weiter rechts in der Evolution.
Und die Idee ist jetzt eben ein selbstentwickeltes Microservices Framework zu bauen, was halt so in der Genesis ist, also eben neu wäre, aber eben in der Wertschöpfung und im Wert ganz weit unten, weil vom Benutzer weg, was eben relativ klar wahrscheinlich dann kommuniziert, dass das vielleicht nicht so schlau ist, das zu tun.
Genau, das würdest du auch im Gespräch vielleicht auch rausbekommen, muss ich auch immer sagen, bei solchen Fällen, bei solchen, manchmal auch für sichtigen Fällen, aber oft ist es halt in der Unternehmenskommunikation ein bisschen oder das merkt man halt nicht am Anfang.
Und da kann es eben dann doch nach hinten losgehen.
Und dann habe ich auch das bisschen gekustomized.
Wir haben auch die Anzahl der Entwickler, die dafür verantwortlich gewesen wären, nochmal draufgeschrieben.
Und da sieht man ja, ich habe halt so sieben Entwickler, die diese Fachanwendung betreuen müssen und weiterentwickeln müssen.
Und einer hatte die Idee, sich mal hinzusetzen und selber zu coden Richtung dieses Microservices-Framework, das in der Analysis-Phase ist.
Und da kann ich halt in der Analysis-Phase, wenn ich nicht weiß, was ich genau anbieten muss für die Fachanwendung und auch vielleicht auch nicht selber weiß, wie ich sowas entwickle, halt schon ein bisschen auf die Nase fallen.
Das ist so die Sache von der ersten Public Map, wo ich das auch nicht nur auf der Technik-Ebene mal gezeigt habe, sondern die aufgemachten, dann war sofort eh klar, dass man diesen Weg dann nicht ging.
Oder gehen sollte.
Auf dieser Map wirkt das ja nun wirklich extrem offensichtlich.
Und das war, nehme ich an, vorher nicht offensichtlich.
Das war sozusagen der Wert.
Genau, du hast nämlich das Thema, dass du intern auch jemanden hast, der treibt solche Themen auch.
Und auf PowerPoint läuft ja immer alles.
Und die Idee mal zu challengen überhaupt, obwohl PowerPoint sagt hier eigene Entwickler, das Framework hier voll cool.
Und dann haben wir Sachen, die aufeinander aufbauen.
Die typischen Schichten, die man aufeinander legt und vielleicht noch einen schönen Container, also richtigen Schiffscontainer, der alles beherbergt in Anwendungen und so.
Das kann man natürlich auf der Präsentationsseite sehr gut aufzeigen und dafür werben.
Aber das ist halt da hinten rum vielleicht auch nicht so eine gute Idee.
Das zeigt dann so eine World Map.
Das macht das einfach klarer.
Das ist so die Idee davon.
Ich habe da auch noch was anderes, also die gleiche Map nochmal, nur das Thema war ja eh klar irgendwie.
Und jetzt zeigt die Anwendung nochmal an sich, oder die Konstellation von gerade, aber nochmal mit so einer intern-externen Entwicklungssicht.
Und da kann man auch mal schauen, ja passt das eigentlich so, wie ich auch die Aufgaben rund um mein Software-System und dessen Entwicklung eben vergebe?
Also sprich die interne Anwendung, die ist wieder so Produktcharakter-mäßig, die wird eben intern entwickelt.
Das ist natürlich so der erste Fall, aber die baut immer noch auf eine externe Komponente auf, so ein Basis-Framework, das eher so ein Genesis-Bereich eben unterwegs ist und dann von extern vielleicht entwickelt wird.
Und wenn man immer solche Konstellationen hat, ja man ist ja abhängig voneinander, dann kann es auch sein, dass man sich intern auszusehen ausbremst.
Also wenn ich jetzt diese interne Fachanwendung weiterentwickeln möchte, haut nicht hin, weil ich halt einfach gefestigt bin oder in der Vergangenheit gezogen werde, beziehungsweise in der Evolution zurückliege, weil diese eben eine Abhängigkeit hat von dem Basis-Framework, das in dieser Genesis-Phase ist.
Und wenn ich jetzt da keine Leute habe, die das weiterentwickeln, dann habe ich halt ein Problem.
Dann muss ich irgendwie um das Basis-Framework herum entwickeln, wenn vielleicht da ja gar nichts mehr möglich ist.
Oder ich schiebe da externe Firma, das ist ja hier der Fall, den man hier nochmal sieht, die das Basis-Framework entwickeln nochmal mehr Budget rüber.
Die freuen sich natürlich und die internen Entwickler, die sagen halt die ganze Zeit oh no, weil die sehen ja, die werden langsamer.
Die möchten eigentlich Features releasen, können nicht, weil sie zurückgehalten werden.
Die ärgern sich nur die ganze Zeit.
Und das eben ähnlich wie mit der Wesensierung Grad kann es eben nochmal mit Wardley Maps darstellen, indem man nochmal sagt, hey, was ist extern, was ist intern?
Passt die Sache zusammen?
Wie fit sind die externen, die uns die Basis-Funktionalität bieten?
Passt das schon für uns oder brauchen wir Alternativen?
Das sind auch so typische Darstellungen, die ich dann immer nutze, auch um manche Lieferanten-Konsumenten-Beziehungen oder Outsourcing-Beziehungen da auf den Zahn zu führen.
Ich bin nicht sicher, ob ich die Kernaussage verstanden habe.
Du sagst, es gibt ein neues Basis-Framework, das hat jemand extern entwickelt.
Das scheint sinnvoll zu sein, hätte ich gedacht, weil es in der Wertschöpfungskette sehr weit unten ist.
Es ist eben dieses Microsoft-Services-Framework, von dem wir vorhin gesprochen haben.
Das will ich nicht selber entwickeln, weil das für mich nicht so relevant ist.
Von daher scheint die Entscheidung, das extern zu vergeben, eine gute Entscheidung zu sein, oder?
So oft kommt es wieder darauf an.
Normalerweise hast du, wenn du eine Anwendung aufbaust, einen gesünderen Stack, wo du drauf hinauf baust.
Wie gesagt, man sieht hier nicht, welche Technologie das war oder wo die Firma unterwegs war.
Deswegen ist es auch in der Geschichte drumherum wichtig, daran festzuhalten.
Ganz konkret in der Entwicklung hatte die Firma nicht eine Kompetenz Richtung des verteilten Betriebs von Anwendungen.
Sie haben sich da etwas extern eingekauft, was eigentlich schon eine Commodity war.
Natürlich kann man rechts die Alternative mit draufschreiben, dass man als interner Entwickler mal gucken sollte, was es auf dem Markt draußen gibt, was ich vielleicht nutzen kann, um nicht zu einem Zwickmittel zu kommen.
Das fehlt hier ein bisschen.
Hier wollte ich nur die Konstellation dieser Verzwicktheit darstellen, wo man sich dann auch reinbegeben kann.
Das ist so die Idee.
Was bedeutet das?
Ich sehe diese Abhängigkeit hin zu diesem Externen.
Dann muss ich tatsächlich außerhalb der Brötli-Map nochmal gucken und feststellen, da habe ich ein Problem im wirklichen Leben.
Dadurch, wie sich diese externe Firma verhält oder wie das Produkt gebaut ist, könnte ich dann schauen, welche Alternativen ich habe, ob ich nicht eine Commodity benutze.
In dem Fall war es auch so, dass die Kompetenzen nach intern noch mitgegeben werden, weil die Externe einfach zu lange waren, zu lange Zeiten, die man dann braucht, um die interne Anwendung weiterzuleben.
Das sind typische Situationen, die man da draußen hat, die man sich dann auch mit visualisieren kann.
Michael Meyerhoff hat gerade gefragt, wenn das Basis-Framework ein monolithisches System ist, wo könnte man das einordnen?
In Genesys oder Custom Build?
Oder wie differenziere ich das an welchen Merkmalen?
Es gibt Unterstützung.
Generell zur Einordnung gibt es Cheatsheets, um anhand verschiedener Kriterien zu entscheiden, in welchen Phasen etwas eingeordnet ist.
Beispielsweise entwickle ich gerade etwas, wo der Markt noch unklar ist, oder habe ich einen Massenmarkt?
Das ist so ein Kriterium, also die Marktziellegung beispielsweise.
Dann wäre es bei unklarem Markt eher links und bei sehr klarem Markt eher rechts.
Wie oft darf es ausfallen?
Da kommt man auch schon ein bisschen zu den Kritiksthemen.
Da kann ich auch gucken, ist es egal, wenn es ausfällt, dann ist es eher links, und wenn es kritisch ist, eher rechts.
Da kann ich im Endeffekt erst einmal generell einordnen.
Ich glaube aber, das geht auch ein bisschen auf riesengroße Systeme ein, wo alles ein bisschen mit vermischt ist.
Da haben wir das Problem von vorherein mit dieser chaotischen Wolke, die ich gezeigt hatte.
Da muss man erst einmal eine Struktur reinbekommen, um dann verschiedene Komponenten einzeln bewerten zu können.
Sonst bilde ich mit dem großen politischen System vielleicht bloß einen Mittelwert, und das wird immer eine Mitte sein, obwohl ich Genesys-Anteile habe für bestimmte Funktionalitäten und Commodity-Anteile habe für bestimmte andere Funktionalitäten.
Da bleibt einem das Reinschauen in Komponenten bzw. in Systeme nicht erspart an der Stelle.
Ich muss gestehen, mich irritiert die Frage, weil ich habe das Gefühl, dass die Frage sagt, wenn es monolithisch ist, ist es eher Genesys oder Custom Build.
Du sagst ja, Genesys ist eben etwas Neues.
Also das ist sozusagen die Reifheit im Markt.
Also kann ich es jetzt einfach ausgehen und kaufen?
Dann ist es Commodity.
Spring Framework wäre ein Beispiel.
Das Beispiel, wo das Genesys war, war an der Stelle, wo Netflix gesagt hat, wir bauen jetzt dieses Microservices-Framework.
Die haben das tatsächlich gemacht.
Das ist mittlerweile etwas, was deutlich Commodity ist, wo wir uns hinstellen können und sagen können, ich benutze nicht Spring oder irgendwelche Frameworks, die herumlaufen. Ähnlich mit Kubernetes, wo Google am Anfang dasselbe gemacht hat und gesagt hat, okay, wir machen das halt.
Es ist mittlerweile eben oben im Haus und jeder kann es benutzen.
Und das ist so, glaube ich, der Differenziator.
Also nicht monolithisch oder nicht monolithisch.
Genau, man kann immer Ansatzpunkte finden, um das noch genauer zu mappen.
Gut, also das waren jetzt so die Maps.
Und wir waren ja eigentlich schon bei dem Thema, so Word-DMapping auch ohne der Map zu machen.
Und da will ich auch noch kurz einen Hinweis geben, dass es eben um diese Landkarte, also um diese Visualisierung, noch auch ein, ja, ich hätte schon fast gesagt, ein gleich großes Feld gibt, das eben mit den ganzen Relationen von den Komponenten, die ich auf dieser Landkarte habe, beschäftigt.
Und wo man dann auch ein bisschen Sachen ablesen kann, wo es hingehen könnte für mich, was mich vielleicht in Zugzwang bringt.
Und das will ich auch mal ganz kurz noch anreißen an der Stelle.
Und zwar haben wir da so verschiedene Muster, also so klimatische Muster.
Das ist so wie in echt.
Also ich gehe raus und da wirkt das Klima oder das Wetter eben auf mich ein.
Das ist etwas, was einfach so ganz normal ist.
Und da passiert irgendwas für mich.
Also wenn ich jetzt so rausgehe mit meinem Poloshirt und draußen hat es minus 50 Grad, dann werde ich ja frieren.
Gut, ist ja extrem.
Aber ich muss mich halt darauf einstellen.
Also das ist so die Idee.
Und da gibt es auch ein bisschen so Trägheits-Patterns, Dinge, die mich zurückhalten.
Also vielleicht habe ich ein Beispiel.
So ein Trägheits-Pattern ist, wenn ich früher so erfolgreich wäre, denke ich mir, das geht immer so weiter.
Und es hält mich jetzt irgendwie in der alten Denke fest, wobei ich eigentlich wieder etwas umdenken müsste.
Das ist wohl nur ein Beispiel, was sich dahinter eben verbirgt.
Dann gibt es Maxime, Dinge, die immer gut sind.
Also beispielsweise eine Maxime ist, ganz grob auf Deutsch übersetzt, Überfrage, was du dir gerade anschaust.
Also ist jedem klar, wenn wir ein World Map machen, was es ist.
Oder such dir eine Software-Entwicklungsmethodik aus, die eben zu diesen Komponenten passt, je nachdem, welche Evolution die sind.
Also nicht so ganz so schlechte Ideen, die immer universell irgendwie mal ins Auge gefasst werden sollten.
Und zu guter Letzt zu Spielzüge, wo man auch mal, wenn man ein World Map hat oder eine Idee hat, wie die Komponenten und die Konkurrenz zueinander steht, wie kann ich denn da Einfluss nehmen auf die Weiterentwicklung der Systeme oder wie kann ich die Wahrnehmung von Kunden eben dann auch positiv ändern, damit die dann meine Leistungen entsprechend dann beziehen gegenüber einer Konkurrenz.
Das ist so die Idee im Grunde davon.
Und da wollte ich ein kurzes Beispiel geben, damit man sich da ein bisschen was darunter vorstellen kann.
Und zwar habe ich jetzt mal was mitgebracht aus dem Java Ökosystem, wo man ein bisschen was sehen kann anhand von diesen Mustern.
Und zwar beispielsweise ein thematisches Muster, No Choice Over Evolution oder die Red Queen Hypothese.
Und die bedeutet eigentlich, dass man, wenn man ein erfolgreiches Ding oder Komponente da draußen entwickelt hat, dass es da draußen, wenn sich der Markt oder die Evolution, besser gesagt, ein bisschen weiterentwickelt hat, dann bestimmt auch Konkurrenz auftut.
Und man muss eben, ob man will oder nicht, dann entsprechend mitziehen.
Und Red Queen Hypothese, weil es kommt immer so aus der Alice hinter den Spiegeln oder Alice im Wunderland von der Roten Königin, die soll gesagt haben zu Alice, hierzulande musst du so schnell rennen, wie du kannst, wenn du am gleichen Fleck bleiben willst.
Und das bedeutet in echt dann auch wieder für uns, also wir können uns einfach nicht ausruhen auf den Lorbeeren, weil von extern kommt immer wieder Druck auf uns zu, Veränderungsdruck, Konkurrenten bringen cooles neue Feature, wir müssen nachziehen.
Und das ist halt so auch ein scharfer Umfeld, dass wir halt dann auch wieder Features von anderen adaptieren oder wir werden adaptiert von anderen.
Und da bringen wir uns gegenseitig eben voran.
Das ist so eine generelle Idee, wie eigentlich so eine Veränderung auf uns einwirkt, wie das Klima allgemein da draußen eben so ist.
Ich habe noch ein anderes Beispiel, so ein strategischer Spielzug.
Gibt es auch wieder 60, 70, 80, 100 davon.
Das wäre die Bündelung, also Bundling.
Bundles kennt man, wenn man was verkauft, beispielsweise das Office-Paket.
Da kommt was mit, was ich vielleicht gar nicht möchte.
Es wird aber trotzdem mit eingepreist, obwohl ich vielleicht nur PowerPoint möchte.
Sowas gibt es auch im scharfer Umfeld.
Verschiedenste Produkte oder Dienstleistungen zusammen als Paket vertreiben.
Warum?
Weil ich vielleicht als Firma halt Software entwickle, wo ich dafür bezahle mit EDA-Kosten, aber das halt nicht verkauft bekomme.
Und dann packe ich das halt zu dem Verkaufsschlager dazu, kann auch ein bisschen Preis vielleicht auch erhöhen, bekomme es querfinanziert.
Und das kann ich halt dann für Produkte machen, wo ich noch ein bisschen mehr Geld brauche, wo ich ansonsten eben nichts dafür erwirtschaften würde.
Das sind jetzt so Ideen, wo man es auch sieht hier auf der rechten Seite beim Java-Setup von damals.
Da wurde immer jemandem eine Toolbar auch untergejubelt, wenn man nicht aufgepasst hatte.
Das ist auch so ein typisches Bereich für Bündelung, dass ich dann auch mal überlegen kann, ob ich das auch für mein System mache, um andere Systeme eben dann noch mit gleichzeitig zu fördern.
Diese Gameplays, die gibt es wie Sand am Meer.
Ich habe jetzt nur zwei Beispiele oder ein Beispiel rausgenommen.
Es gibt auch wieder Übersichten.
Das meine ich eben mit dem Ökosystem, dass da ganz viel schon existiert.
Was man hier sieht, das ist einfach eine riesengroße Auflistung von verschiedenen Dingen, die ich machen kann, um auch meine Konkurrenz aufzubremsen.
Beispielsweise könnte ich einen Talent-Rate starten.
Das ist momentan so in.
Das bedeutet, ich ziehe einfach die Spitzenkräfte von meinen Konkurrenten ab, um die bei mir arbeiten zu lassen.
Das sieht man ja auch häufig jetzt wieder Richtung Meta und Open AI.
Das sind so Themen, die über das Software-System selber noch mal beeinflussen, wie ich dann später mit dem Software-System weitermachen kann oder eben nicht, je nachdem, auf welcher Seite ich bin.
Oder was ich auch generell super finde, das sind entsprechend Spielzüge, die dann vielleicht auch sagen, hey, du kannst auch gesund etwas aussetzen.
Also Prokrastination ist ja auch mit drin, um einfach mal ein bisschen abzuwarten.
Vielleicht tut sich ja was auf dem Markt, jetzt entsteht ein neues Framework, das ich dann selber nutzen kann und muss es nicht selber irgendwie entwickeln oder weiterentwickeln.
Also da auch eine Entscheidung zu treffen, auch für das eigene Software-System, hey, lass uns jetzt bewusst da nicht starten damit.
Es könnte eh was kommen, weil die Konkurrenz, die ist da auch unterwegs.
Das sind eben so Gedanken, die man dann auf Basis von diesen Gameplays oder strategischen Spielzügen dann auch noch mitnutzen kann.
Und vielleicht noch kurz zur Einfärbung.
Man sieht hier die Gameplays, die sind ein bisschen dunkler oder heller.
Es gibt fiese Gameplays, es gibt neutrale Gameplays, normale Gameplays.
Also auch schon was, was vielleicht in den rechtlichen Graubereich kommt.
Da sollte man sich gut überlegen, ob man das in der Situation spielt.
Das kommt dann auch wieder darauf an, wo man gerade ist und wo man darüber diskutieren möchte.
Also da sind wir jetzt genau, oder das wäre die Frage, du hattest ja gesagt, du bist halt kein Unternehmensberater, sondern du fokussierst dich auf Software-Struktur.
Das erscheint mir jetzt etwas zu sein, wo man tatsächlich über Unternehmensstrategie und damit in diesem Bereich von Unternehmensberatung ist.
Was ist die Auswirkung auf Software-Architektur?
Du wirst es ja wahrscheinlich erläutern, weil es irgendwie was mit Software-Architektur zu tun hat.
Das bin ich jetzt gerade nicht so offensichtlich sozusagen.
Für mich ist es wichtig, eben in der Software-Architektur das auch beizubringen, dass wir eben nicht die sind, die entscheiden, wie das Software-System dann weiterentwickelt wird.
Aber es gibt halt auch Dinge, die auf der strategischen Ebene unterwegs sind.
Und für mich ist immer spannend, dann auch im Entwicklungsteam das reinzutragen, was jetzt gerade so in der Führungsebene oder in der Strategie ebenso eigentlich bezweckt werden möchte.
Es ist ganz richtig, dass ich das nicht als Daily Business auch habe, auch als Software-Architekt nicht.
Aber das ist halt für mich auch eine unglaubliche Hilfe, mal kurz, also mal schnell auf den Punkt zu kommen, zu wissen, was die Leute denn da draußen auf der Führungsebene vorhaben.
Also wollen die eine Allianz schmieden, also mit externen Partnern zusammen operieren?
Oder wollen sie altes Zeug wegbekommen an den Dienstleister, der nicht weiß, was er da eben in die Hand bekommt?
Das kann man eben dann auch schneller in Worte fassen.
Und dann weiß ich dann direkt auch im Entwicklungsteam, was zu tun gilt und kann das dann entsprechend bei der Weiterentwicklung des Software-Systems dann mit umsetzen.
Also wenn ich ein System, ein Teilsystem habe, das ich loswerden möchte, kann ich natürlich dann Refactoring arbeiten, einfach stoppen, weil ist eh egal, wie das denn aussieht.
Das sind einfach so ganz grob so Diskussionen, die man dann auch wieder zurückgespiegelt bekommt, zur eigentlichen Softwareentwicklung bis auf die Code-Zahl letzten Endes.
Okay, womit du sagst, also dass man eben als Software-Architekt irgendwie verstehen muss, was die Firma eigentlich vor sich hat.
Das hier sind Dinge, die die Firma vielleicht vor sich hat.
Und dann möchte ich da drauf irgendwie reagieren, in das Software-Architektur und in dem, wie ich sozusagen da Prioritäten setze.
Genau.
Und man sieht auch, was sind eigentlich diese Spielzüge, was gespielt werden kann von mir oder auch von Konkurrenten.
Und dann sind auch so Dinge drin wie das Spiel mit Lizenzen, Licensing-Play, also dass ich auch weiß, okay, wenn ich jetzt vielleicht eine Open-Source-Bibliothek nehme und einfach ohne mich dabei mit zu engagieren und ich biete einfach auf Basis von der Open-Source-Bibliothek einen Service an, dass es halt dann passieren kann, dass andere das mitbekommen, die die Open-Source-Bibliothek eben als offene Community-Aktivität bereitgestellt haben und dann einen Lizenzwechsel vielleicht auch machen, weil ich das übertrieben habe und das nicht zurückgespiegelt habe.
Solche Patterns sind auch mit drin.
Und da kann ich jetzt auch viel früher eben wissen, dass sowas dann gespielt werden kann von den Bibliotheken, die ich nutze, wo ich drauf setze oder auch im positiven Sinne, dass ich halt gemeinschaftlich Open-Source-Projekte halt auch mit unterstütze durch Ausbildungen, was auch immer sich dann anbietet.
Genau, das, was du gerade beschreibst, ist ja eine Sache, die ja gerade bei den Cloud-Anbietern häufig passiert ist, wo dann eben irgendein Open-Source-Projekt plötzlich sich in der Cloud wiedergefunden hat, in einem Cloud-Angebot und die dann halt die Lizenzen so geändert haben, dass die Cloud-Anbieter, die davon profitieren, dass diese Systeme halt dort lieferbar sind, eben Schwierigkeiten haben durch die neue Lizenz und das hat dann tatsächlich ja zu Forks geführt, nicht?
Exakt, oder Lizenzverschlimmerungen, also wo ich dann nicht mehr so offen als Nutzer sein kann, bei Open Rewrite beispielsweise, wo es dann mehr zu einer produktitären Lizenz geht, wo dann ja zwar externe Cloud-Anbieter diese Transformationsrezepte für Code in diesem Fall eben nicht mehr nutzen dürfen, aber eben in der Firma eben selbst die Mitarbeitenden das schon machen dürfen.
Solche Geschichten gibt es dann, genau.
Das hat man immer wieder gehört.
Gut, das wollte ich zeigen.
Natürlich, wie immer, komme ich nicht durch die ganzen anderen Muster durch und ihr wisst jetzt auch warum, weil es so viele gibt da draußen, aber jetzt nur als Vorgeschmack, dass man eben auch sieht, wo das noch hingehen kann und was mich eben da an der Technik so fasziniert, weil man eben hier besonders bei den strategischen Spielzügen dann einfach auf dem Umfeld auch ein bisschen, Umfeld eines Unternehmens unterwegs ist und versucht ein bisschen aufzunehmen, wo das Eigenunternehmen hin möchte, wo die anderen sind, wo die hin möchten.
Das ist eben für mich dann auch sehr spannend an der Technik.
Genau, und ich verlinke deinen Blogpost zu diesen Top 5 Learnings, Wardley Maps, wo du ganz viele unterschiedliche Ressourcen hast, die eben beantworten, wie man damit sozusagen loslegen kann und da kann man sich, glaube ich, schlauer machen.
Genau, das ist unser Plan, ja.
Gut, gut.
Noch irgendwas, was wir vergessen haben?
Noch irgendwelche anderen Themen?
Ja, vielleicht die obligatorische Erfahrung.
All models are wrong, but some are useful.
Ja, das Thema mal aufnehmen, aber auch nicht, also Silver Bullets sind leider schon wieder aus.
Für mich funktioniert Wortly Mapping ziemlich gut, in Konstellation natürlich mit ganz vielen anderen Methodiken und ja, also deswegen bin ich immer noch sehr stark dabei bei dem ganzen Umfeld und nutze es auch immer in meiner täglichen Arbeit.
Aber ja, wie so oft, mit Maßeinsätzen und in der richtigen Situation, wie schon gesagt.
Ja, es ist eine Abstraktion, die genau passt und was ich gelernt habe, ist der goldene Zauberstab.
Ich glaube, das ist eine neue Metapher, die ich vorher noch nicht kannte.
Ja, weil die Idee ist immer, man kommt vorbei und schwingt mit dem goldenen Zauberstab vom Wardley Maps einmal, kann alles heile machen, aber dahinter steckt dann doch noch Arbeit und auch Gehirn einschalten, wie so oft.
Genau, ich glaube, das ist so generell bei Software-Strukturen immer eine gute Idee.
Gut, ich glaube, wir haben es dann soweit.
Genau, vielen Dank, dass du da warst und das nochmal diskutiert hast und wir sehen uns nächste Woche, glaube ich.
Also wir, glaube ich nicht, wieder.
Hier soll es eine neue Episode geben, denke ich und ja, ich wünsche dir schon mal schönes Wochenende und bis dahin.
Vielen Dank nochmal.
Bis dann wieder, ciao.