Wardley Maps

Lucas: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute haben wir als Thema die Wardley Maps. Und um zu erklären, was das überhaupt ist und warum wir das alle brauchen, habe ich den Markus eingeladen. Hallo, Markus!

Markus: Hallo Lucas!

Lucas: Markus, magst du dich einmal kurz vorstellen, wer du bist und was du bei INNOQ so machst?

Markus: Mein Name ist Markus Harrer. Ich bin Senior Consultant bei INNOQ und ich mache alles rund um Software Architektur. Das bedeutet, ich gehe zu Kunden und helfe ihnen, von dem weißen Blatt Papierproblem wegzukommen. Das ist Wissen, wo man mit neuen Softwaresystemen anfangen kann. Und nebenbei mache ich auch noch das Thema Software Modernisierung, auch den kompletten Life Cycle, wenn Leute nicht mehr wissen, wie es mit dem Softwaresystem weitergehen soll. Da versuche ich denen auch zu helfen.

Lucas: Und eins von den Sachen, die du dafür gefunden hast, sind die Wardley Maps. Vielleicht starten wir einfach erst mal damit. Wer ist denn Wardley oder was ist denn Wardley?

Markus: Erst mal muss ich sagen, das ist eine Methode, die ich jetzt ziemlich nett finde, um bei Softwaresystemen einen besseren Überblick zu bekommen. Aber wie gesagt, das ist eine Methode von vielen. Da muss man schauen, ob sie passt. Das ist immer das am Anfang. Deswegen muss es nicht jemand machen. Aber ich zeige mal, wo ich das mache. Vielleicht haben die Leute da draußen auch mal Lust, das einzusetzen. Wardley Maps. Vielleicht erkläre ich es an den beiden Worten: Wardley und Maps. Da fange ich bei den Maps vielleicht an. Klar, im Deutschen bedeutet es Karten oder im Englischen auch das Wort kartographieren, als Verb. Und das ist wichtig, zu wissen, wo der Name herkommt. Denn der Begründer Simon Wardley hat diese Technik erfunden und deswegen heißt es nicht Wardley Map, weil er sich irgendwie herausstellen wollte mit seinem Nachnamen, sondern die Geschichte sagt, dass man Simon Wardley irgendwo eingeladen hatte und da sollte er Systeme kartographieren für ein Unternehmen. Die brauchten eine Terminplanung und einen Text dafür und haben gesagt: Ja, schreibe doch einfach ‚Wardley kommt vorbei und mappt eben‘ rein in die Termine. Und deswegen hieß es ursprünglich Wardley Maps und der Name ist hängengeblieben, weil Maps gut passt für Karten. Deswegen gibt es da das Thema Wardley Maps. Das erst mal zu dem kompletten Kontext. Da habe ich schon zu dem Wort Wardley auch gesagt, der Begründer von diesen evolvierenden Strategielandkarten, wie ich das eingedeutscht sagen würde, der war eine Zeit lang auch in der Strategie unterwegs. Er hatte auch seine eigene Firma. Die wollten damals eine Serverless Plattform entwickeln, Mitte der 2000er Jahren. Und da hat er immer gemerkt, er musste diese Strategie für diese Plattform auch kommunizieren, aber hatte da nicht so wirklich so ein Instrument dafür, das den Leuten nahezubringen. Er hat auch angefangen, irgendwelche Visionen auszurufen, irgendwelche lustigen Texte zu schreiben wie: Wir möchten Marktführer sein im Open Source Bereich für Computer Plattformen oder so. Und da hat er diese Strategien jemandem an die Hand gegeben und die haben gesagt: Ja, klingt gut, super, machen wir. Im Endeffekt hat er sich dann dabei erwischt, dass er eigentlich selber nicht wusste, was er tun soll jetzt mit dieser Vision, die er rausgehauen hat und hat nach einem Instrument gesucht, um seine Vision besser kommunizierbar zu machen. Er hat auch lange geschaut, was es da draußen so gibt und hat sich da überlegt, diese Wardley Map Technik zu nutzen, zu erfinden im Endeffekt und daran zu arbeiten, um vor allem Strategien auch besser kommunizieren zu können, um besser mit anderen auch diskutieren zu können, damit strategische Bewegungen mehr so zu einer kollaborativen Arbeit dann auch werden. Das Ganze erschwingt sich ein bisschen durch diese Methodik. Das Wardley Maps Thema ist ziemlich breit aufgestellt, breit Richtung Community. Das Schöne ist, Wardley macht alles auch öffentlich, hat sehr viele Vorträge draußen im Netz und veröffentlicht auch sämtliches Material unter der Creative Commons License, die dafür sorgt, dass man auch auf die Arbeiten von ihm aufbauen kann und dass sich eben eine Community drumherum ergibt, die sich damit beschäftigt, in andere Sprachen zu übersetzen, das weiterzuentwickeln und wie gesagt auch breiter zu streuen. Das finde ich immer ganz schön und deswegen finde ich es auch gut, wenn sich Leute da einarbeiten. Weil es auch ein schönes Instrument ist, das offen ist, kein Closed Circle ist und wo man auch im Internet oder über Barcamps oder Konferenzen dem auch weitergeholfen wird.

Lucas: Und wie bist du auf dieses Thema gekommen? Wie bist du da hingeraten auf die Wardley Maps?

Markus: Ich bin eigentlich ein ganz normaler Softwareentwickler und habe immer so ein Faible gehabt, das System besser zu machen. Und da habe ich natürlich dann angefangen mit dem Thema Refactoring, mich da zu beschäftigen, z.B. Code, wie kann ich dann Software wieder geraderücken, wie kann ich Abhängigkeiten brechen, damit die gesamte Codebasis besser dasteht? Und da habe ich gemerkt, es gibt coole Techniken, die einem zeigen, wie man das machen kann. Aber irgendwie fehlt da immer so die Motivation gegenüber dem Management zu sagen: Hey, das bringt jetzt wirklich was, was wir da tun. Und auch das Thema: Wo fange ich denn überhaupt an? Wenn ich jetzt so eine Liste an Problemen habe, was baue ich als Erstes weg? Wie mache ich das geschickt, ohne jetzt irgendwie unnötig Zeit zu verbraten? Und da habe ich gesucht, was mir dabei helfen kann, um diese Kommunikationswege zu schließen zwischen dem Thema: Ich habe jetzt diesen Satz voller Probleme. Eigentlich könnte ich die lösen und: Bitte, liebes Management, gib mir mal Zeit und Geld, um das anzupacken, denn das zahlt jetzt letztendlich auf die Software ein und somit ist es gut für den Kunden, das anzugehen. Da habe ich auch etwas in Richtung Datenanalysethemen gemacht. Da hatten wir auch mal einen Podcast davon, um mit Zahlen, Daten, Fakten zu arbeiten. Und ich sehe auch, man ist aber ziemlich schnell auch in dem Thema Strategie mit drin. Es gibt auch beispielsweise aus dem strategische Domain Driven Design einen schönen Satz von Al Gavins, er hat mal gesagt: „Not all parts of a system will be well designed“. Und das zusammen mit dem Thema ‚Ich möchte Refacturing machen‘ bringt mich dazu, dass ich was brauchen, um zu sehen: Wo fasse ich denn jetzt wirklich an im Softwaresystem und wo lasse ich besser die Finger davon? Da hilft mir dann auch so etwas wie Wardley Maps, was da eben ganz gut sein kann. Und deswegen bin ich darüber gestolpert, auch dank Kollegen, die mich da auch mit darauf hingewiesen haben. Dann hat es sich entwickelt. Jetzt habe ich mir das angeeignet, erst mal ausprobiert und mittlerweile setze ich das als Methodik im Hintergrund ein, um Leuten mit ihrem Softwaresystem weiterzuhelfen.

Lucas: Ich glaube, viele unserer Hörerinnen und Hörer werden das Problem kennen, dass man irgendwie versuchen muss zu erklären, Leuten, die im Management sitzen, beispielsweise warum jetzt eine bestimmte Änderung die Zeit wert ist, das Geld wert ist. Das heißt, allein deswegen ist es wahrscheinlich für viele Leute interessant das zu machen. Jetzt mal außerhalb des Modernisierungskontexts. Das heißt also, ich kann eine Wardley Map benutzen, um zu sagen: Warum brauchen die Leute meine Software oder ist das zu vereinfacht dargestellt?

Markus: Vielleicht müssen wir mal einen Schritt zurück. Das klingt jetzt so, dass jemand vorbeikommt und eine Wardley Map macht. Das ganze Thema, dass es so breit aufgestellt ist in der Community, hat den Hintergrund, dass eigentlich die Leute, die die Software selbst entwickeln, die haben am meisten Plan davon. Oder auch die Leute, die dann versuchen, das Produkt an den Mann oder die Frau zu bekommen, die wissen, wie das Geschäft funktioniert. Und deswegen ist Wardley Map eigentlich mehr so ausgelegt, dass die Leute in den Firmen sich selbst helfen können damit, um strategische Belegungen zu machen im Endeffekt. Ein kurzer Ausflug: Was auch mitschwingt, ein Ziel von so einer Wardley ist es, Unternehmensberater arbeitslos zu machen, weil er nämlich die Ansicht hatte: Unternehmensberater kommt rein in die Firma, die machen alles platt, kommen mit irgendwelchen coolen Magic Methoden daher. Sagen dem Management: Das müsst ihr machen, dann ist alles gut. Dann gehen die weg und dann funktioniert es trotzdem irgendwie nicht. Und das ist etwas, was mir als ehemaliger Angestellter auch ein bisschen gefehlt hat. Man braucht einfach unglaublich viel Wissen über das eigene Unternehmen selbst, bevor man eigentlich so eine Methodik nutzen kann. Und das weiß man eben nur, indem man in der Firma selbst sitzt und weiß, wie die Kultur da ist und wo man denn hin möchte. Und das kann ich als Angestellter auch nehmen, um das herauszufinden und auch, vielleicht wenn ich Entwickler bin, gegenüber dem Management dann zu sagen: Ich brauche ein paar Informationen, um dann beispielsweise so Refactoring Arbeiten zu priorisieren oder eben zu wissen, welche Produkte ich einkaufe, welche ich von anderen entwickeln lasse. Und da braucht man unglaublich viel Wissen, dass ich selbst mitbringen muss. Und da brauche ich einfach nur das Mittel, das Ganze mit anderen bereden zu können. Das wollte ich dazu noch sagen. Und da gibt es eben ganz viele Möglichkeiten da draußen, sich da einzuarbeiten. Darauf ist es so ausgelegt. Jetzt zu deiner Frage, was ich damit machen kann, das schwingt ein bisschen mit. Ich lerne erst mal kennen, wo ich überhaupt stehe mit meinem Konglomerat und Softwaresystem. Und das finde ich so interessant. Es ist nicht so, dass ich jetzt sage: Ich schaue mir ein Softwaresystem an, was ich da so machen muss, sondern ich habe die Möglichkeit, mit Wardley Maps auf unterschiedlichen Ebenen zu agieren. Ich kann mir beispielsweise auch System of Systems anschauen, um zu sehen: Welche Systeme habe ich denn überhaupt im Unternehmen? Und was entwickele ich da selbst und wie sind die da in Abhängigkeiten zueinander? Und zu bewerten, was ich denn überhaupt habe, um zu wissen, wo mein Standpunkt ist und mir danach das nächste Stück zum Ziel zu erarbeiten, wo ich mich dann hinbewegen möchte. Das ist mal ganz abstrakt dazu dargestellt. Ich finde, das ist schon mal die erste Erkenntnis, wenn man so weit ist mit einer Wardley Map. Dieses situative Problembewusstsein zu schärfen oder so ein Kontextbewusstsein zu schaffen, dafür ist es schon beim ersten Schritt nett, weil man da auch verschiedene Sichtweisen von verschiedenen Leuten in der eigenen Firma dann mal zusammenbringt und das ganze so auf ein Blatt Papier letzten Endes bringen kann.

Lucas: Das heißt aber, wenn wir über Wardley Maps sprechen. Du hast schon gesagt, Map ist auch so kartographisch gemeint. Müssen wir uns das dann auch vorstellen, wie eine Landkarte, was wir hier besprechen? Malen wir irgendwelche Länder ein oder wie müssen wir uns das da vorstellen?

Markus: In der Tat könnte ich sogar Länder hinmalen, aber da komme ich noch dazu. Das wird auch gemacht. Im Endeffekt ist schon die Idee, so eine Landkartenmetapher in die virtuelle Welt zu übertragen. Oder anders gesagt für die Dinge, die wir so machen, in der IT, die sind alle virtuell, nicht wirklich sichtbar und deswegen war die Idee von Simon Wardley trotzdem, so eine Karte zu bauen, wo man das sichtbar machen kann. Und das finde ich ganz spannend. Da bedient er sich auch ganz stark von den ganz normalen Landkarten, die man so kaufen kann oder auf Google Maps sich anschauen kann, um diese Elemente von diesen Karten da in unsere virtuelle Welt zu transportieren. Das ist schon da, dass man sagt: Die Landkarte selbst ist wie so ein visuelles Instrument. Klar, ich kann irgendwas zeichnen und dann mit Leuten darüber reden, das ist ganz schön. Aber ich habe da auch so eine Art Koordinatensystem, wo ich Dinge platzieren kann. Man hat die reale Welt, das beziehe ich da beispielsweise auf so ein XY Karten Diagramm. Da habe ich so was wie Bäume, da habe ich Straßen, Städte. Und das hat Simon Wardley auch übernommen und platziert etwa allgemeine Komponenten auf dieser Karte. Komponenten können so etwas wie Aktivitäten, die wir durchführen, Praktiken, die wir nutzen, Wissen, Daten oder ganz andere Dinge, sein – z.B. auch Länder. Wenn ich so etwas haben möchte, um Länder gegeneinander auszuspielen, ist das auch so ein Thema, das andere machen mit Wardley Maps. Und da habe ich schon mal ein paar Metaphern übertragen von den normalen Landkarten. Was brauche ich dann noch? Für eine Landkarte habe ich auch so eine Nordstelle, eine Ausrichtung und das finde ich auch ziemlich clever gemacht bei den Wardley Maps. Wir möchten immer unsere eigene Situation kennenlernen und da brauche ich auch immer eine Ausrichtung, beispielsweise für wen ich gerade diese Map erstelle. So ein Navigationspfeil ist in der Wardley Map der Anker. Ich richte meine Dinge, die ich auf der Map platziere, immer Richtung Norden aus, aka Richtung eines Ankers, um zu sehen, in welchem Kontext ich gerade diese Map erstelle. Ein Beispiel: Es kann sein, beispielsweise, ein User kann ganz viele unterschiedliche Rollen haben. Es kann der Endnutzer der Software selbst sein, das kann ein Shareholder sein, das kann der Kunde sein, der das so ein Softwaresystem beauftragt. Von deren Sichtweisen, von diesen Stakeholder Sichtweisen ausgehend, mache ich dann sozusagen eine Karte und weiß dann noch immer, in welchem Kontext ich mich befinde. Das hilft mir einfach weiter, um da auch Informationen auf diese Map zu bringen. Das habe ich auch schon gesagt, Achsen gibt es. Die müssen wir natürlich auch besprechen. Eine Achse, die finde ich ziemlich nett, denn die kann vermitteln zwischen dem Management und den Techies. Das ist die Achse der Wertschöpfung. Ich arbeite sehr stark damit, bei Wardley Maps zu sagen: Ich habe einen gewissen Blickpunkt, beispielsweise von dem Benutzer eines Softwaresystems ausgehend. Und dann frage ich mich: Was braucht denn dieser Nutzen? Dann ist meine Firma für diesen Nutzer da und da kann es sein, dass ich sage: Ich bin ein Versicherungsunternehmen und deswegen hat der Nutzer in meinem Blick da Bedürfnisse und Bedarf, etwas mit meiner Software zu tun, z.B. einen Versicherungsvertrag abschließen. Das ist eine wertschöpfende Tätigkeit, die da passiert, wenn dieser Vertrag abgeschlossen wird. Und da habe ich Fragen, entlang dieser Wertschöpfungskette nach unten hangelnd: Was muss ich denn dafür bereitstellen? Was braucht es denn, um diese Versicherungsanträge abschließen zu können? Da braucht es beispielsweise eine mobile App, dann hangele ich mich weiter runter. Was brauchst du da noch dafür? Da braucht es vielleicht noch mal im Hintergrund einen Datenspeicher, wo man Daten sammelt, vielleicht auch Rechenkapazität. Und diese Kette, die ich jetzt beschrieben habe, ist eine Wertschöpfungskette, die bilde ich da ab, um zu signalisieren, was ich da überhaupt herstellen muss als Softwarehersteller, um die Bedürfnisse von verschiedenen User-Nutzergruppen, Stakeholdergruppen abbilden zu können.

Lucas: Um das noch mal kurz klarzumachen. Wenn ich dich richtig verstehe, da sind jetzt viele Sachen dabei, die habe ich gar nicht gebaut. Ich als Unternehmen habe jetzt nicht das iPhone erfunden, sondern ich baue eine iPhone-App, sage ich jetzt mal. Das bedeutet also, in dieser Wertschöpfungskette sind ganz viele Sachen drin, die außerhalb meines Unternehmens sind. Ist das richtig?

Markus: Das kann sein. Das würde ich dann auch offensichtlich machen. Das kann sein, dass ich sehe: Ich habe dann ganz viel, was ich nutze, vielleicht von anderen, vielleicht habe ich Zulieferungen von der Open Source Community. So etwas will ich dann im Rahmen, je nach der Situation immer auch diskutieren. Beispielsweise, ich möchte ein anderes Unternehmen übernehmen oder so was. Da möchte ich wissen, was die Softwaresysteme haben und welche Zulieferer die beispielsweise haben. So eine Sicht könnte ich jetzt mit dieser Wardley Map machen. Mit einer Variante davon, um zu zeigen: Ich als Kunde gehe zu mir, gehe zu meinem Unternehmen und kaufe jetzt mein Softwaresystem und danach schaue ich: Was brauche ich denn, um die Software herstellen zu können? Dann habe ich beispielsweise noch mal in der Wertschöpfungskette tiefergehend Open Source Bibliotheken, andere Zulieferer, die mir Software geben. Und da sehe ich auch, dass ich so was dann auf diese Karte mit aufnehmen kann. Da sieht man auch schon, in diesem Beispiel denke ich, dass es auch sehr vielfältig eingesetzt werden kann. Und deswegen ist es so wichtig zu wissen, für wen man diese Map macht und auch vor allem mit den Leuten am Anfang zu diskutieren: Was möchte ich mit dieser Map bezwecken? Weil es, wie gesagt, mehr so ein universelles Ding ist, um für ganz spezifische Situationen Dinge zu kartographieren. Deswegen dieser abstrakte allgemeine Satz jetzt gerade von mir.

Lucas: Aber das bedeutet auch, ich meine, so eine Wardley Map, die jetzt vollständig wäre, die wäre unendlich groß, weil alles hat immer noch eine weitere Beziehung. Das heißt, wir müssen uns sehr genau überlegen: Wer sind die Leute, für die ich die Map male? Wie weit ist es relevant? Wie weit geht die Kette, oder?

Markus: Genau, das würde ich auch so sagen. Das kann ziemlich groß sein. Man kann natürlich, es ist ein Modell und da gibt es auch den schönen Spruch: Wie genau ist so ein Modell? Etwa das Modell von Paris, wenn ich das machen würde und in 100%iger Genauigkeit, mit den ganzen Atomen, die da rumschweben. Deswegen ist da auch immer die Frage des Abstraktionsgrades. Was mappe ich denn da gerade? Da muss man aufpassen, wenn ich jetzt das Thema noch mal aufgreife mit dem Übernahme-Thema. Vielleicht fange ich dann plötzlich an, mein eigenes Softwaresystem noch mal aufzuspalten und dann die Innereien noch mal zu mappen, anstatt zuerst die beteiligten Systeme nach außen zu mappen. Da ist am Anfang gleich so eine Schwierigkeit, wo man sich vielleicht zu tief reinsteigert, wo man sich wieder rausziehen muss, um die Frage zu stellen: Was mappe ich da jetzt gerade, auf welchem Abstraktionsgrad bin ich da gerade, um dann eine saubere Diskussion entstehen zu lassen, mit anderen, die diese Map auch nutzen müssen.

Lucas: Gut. Wir haben jetzt über die Wertschöpfungsachse geredet, das ist die Y-Achse in der üblichen Darstellung. Was ist denn die X-Achse von unserer Wardley Map?

Markus: Für die Wertschöpfungsachse, Y-Achse wie du sagst. Vielleicht sage ich da zu dem Achsenbegriff etwas. Das ist ziemlich so was, was eine Achse betrifft. Da habe ich oben etwas, das ist etwas, was ziemlich nah beim User ist, beim Endkunden, beim Endnutzer beispielsweise. Und dann kann ich die Achse sozusagen heruntergehen, sowie auf einem normalen Koordinatensystem auch. Dann sehe ich weiter unten etwas, was vielleicht auch nur die Techies sehen, die Leute, die in der Technik drinstecken, die im Maschinenraum drin sind. Das hat schon so eine Achsenfunktion, eine Abstandsfunktion. Jetzt muss man aber aufpassen, ich kann „X-Achse“ machen. Bildlich kann man es sich schon vorstellen, das ist die Achse unten hier, die nach links von rechts dann auch verläuft. Das ist die sogenannte Evolution und das ist an sich keine Achse, sondern da gehe ich noch mal zurück zu der Kartenmetapher. Auf einer Karte kann ich Bewegungen darstellen. Ich kann sagen: Ich bin jetzt in Nürnberg und ich weiß, wo München ist. Also mache ich so einen Strich von Nürnberg nach München, um zu zeigen, dass ich jetzt da hinreisen möchte, beispielsweise, dass ich mich dahin bewegen möchte. Dieser Strich, das ist etwas, was so eine Wardley Map versucht, mit der Evolutionsachse einzufangen. Eigentlich eine Bewegung. Die Komponenten sehe ich so, dass sie sich mit der Zeit weiterentwickeln, beispielsweise. Und das finde ich sehr spannend, denn dadurch kann ich nämlich nicht nur sehen, was beispielsweise mein Endnutzer jetzt im Blick hat, wenn er eine bestimmte Software von mir verwendet, sondern ich sehe auch, wie reif beispielsweise so eine Komponente ist, die dann irgendwann mal in dieser Wertschöpfungskette eine Rolle spielt. Und das ist eben der zweite Faktor, weswegen ich Wardley Maps so gerne mag, das ist das Thema, dass ich eben da noch mehr Kontext und Wissen über den aktuellen Stand meiner Software oder generell bekomme, was das System dann schafft. Ich muss jetzt erklären, was Evolution bedeutet. Der ist auch mehrfach belegt. Ich mache erst mal ein Beispiel. Gehen wir mal durch das Thema Rechenleistung. Das ist auch so ein Klassiker von so einer Wardley, das das illustriert und da kann man die Evolution schön nachvollziehen, wie das so funktioniert. So generell haben wir da verschiedene Evolutionsphasen, die so etwas wie Rechenleistung durchschreiten. Da gibt es das Thema Genesis: Am Anfang habe ich keine Idee, ob jetzt so was wie Rechenleistung überhaupt gebraucht wird, ob da jemals ein Markt daraus entstehen wird. Und das andere Thema ist: Kann ich das überhaupt herstellen, was ich da so an Ideen habe? Das sind so zwei Paar Stiefel. Das eine ist das Thema Nachfragewettbewerb. Wie stark wird etwas von einem Markt gebraucht im Endeffekt? Oder wie hoch ist das Bedürfnis, so was besitzen zu wollen oder nutzen zu wollen? Und das andere ist: Wie kann ich das als Hersteller auch selbst herstellen? Wie gut gelingt mir das denn, das Ding herzustellen? Das ist dann der Wettbewerb des Angebots. Wie gut kann ich denn etwas anbieten in hinreichender Qualität? Und das spannt sozusagen diese Evolutionsachse auf über diese verschiedenen Phasen. Gerade habe ich schon dieses Genesis-Thema genannt. Da weiß ich noch nicht, ob das jemand braucht oder ob ich das überhaupt herstellen kann. Beispiel für Rechenleistung wäre das Thema die Zuse Rechenmaschine ganz am Anfang, die mal gebaut wurde vom Konrad Zuse, da wusste niemand, dass man das brauchen kann. Das war so ein Forschungsding und Konrad Zuse selbst wusste nicht, wie man das macht. Deswegen hat er ganz viel experimentiert und dann die erste Zuse Maschine, die Z1 an der Stelle auch hergestellt. Dann haben wir gesehen: Ah okay, das ist gar nicht so doof, nicht alles irgendwie mit dem Rechenschieber machen zu müssen, sondern wir können das automatisieren. Dann sind die Leute noch gekommen: Wir könnten so langweilige Tätigkeiten auch mal wegrationalisieren und dann vielleicht zu automatisierten Großrechenmaschinen oder Anlagen bauen. Das waren damals sehr kundenindividuell hergestellte Rechenmaschinen. Beispielsweise für die Bäckerei Branche, so ein Abrechnungssystem. Es wurde hart codiert mit den ganzen Tubes, die es damals so gab, wo man die ganzen Röhren reingesteckt hatte, wie die Modelle in der Hardware sind. Die wurden einzeln angefertigt. Das ist auch die zweite Phase bei der Evolution. Einzelfertigung. Ich mache etwas für einen bestimmten Kundenkreis. Auch mit dem Hintergrund, dass ich noch nicht weiß, ob das überhaupt funktioniert, was ich da tue. Aber ich weiß, ein paar Leute gibt es da schon, die damit etwas anstellen möchten. Aber das hat sich auch weiterentwickelt, wie eben von der Zuse Rechenmaschine am Anfang. dass man gesehen hat: Da ist ein Bedarf da. Deswegen steigen wir da ein und stellen etwas anderes her. Dann kann man noch sagen: Ja gut, wenn es so weitergeht, wenn die Leute weiter nachfragen, dann komme ich wahrscheinlich in Zugzwang. Ich als Hersteller, dass ich da auch nachziehen muss und die Leute da abholen muss mit meinen coolen neuen Rechenprodukten. Und das hat beispielsweise damals auch IBM gemacht mit der M63, die haben sozusagen kapiert, dass die Leute eigentlich schon einen hohen Bedarf an Rechenleistung haben, aber die möchten nicht jedes Mal einen Elektroingenieur vorbeischicken, um so Programme neu zu konfigurieren oder neu zu codieren oder neu rumzustricken. Und deswegen hat IBM etwas sehr Schlaues gemacht und hat angefangen zu dieser Rechenleistung, diese Hardware zu entkoppeln, zu dem, was kundenindividuell ist und hat das Ding Software genannt. Und durch diese Abstraktion oder Teilung zwischen Hardware und Software ist es IBM gelungen, die Rechenleistung auf eine neue Stufe zu bringen und für einen ganz großen Kundenkreis eine universelle Rechenmaschine zu machen. Das Kundenindividuelle war dann die Software. Hardware war mehr so stabilisiert, konnte man als Produkt direkt bei IBM kaufen. Das ist die dritte Phase, Produkt. Ich kann etwas schön in einer Box irgendwo aus dem Regal ziehen und bei mir nehmen. Es ist gut dokumentiert. Man weiß, da ist ordentliche Nachfrage schon mal da und ich kann es auch super in Massen herstellen. Die Hersteller, um eben da größere Märkte auch zu erschließen, weil ich nicht so sehr spezifisch unterwegs bin für Nischenkunden beispielsweise. Nehmen wir noch den letzten Punkt: Wie hat sich das mit Rechnerleistung weiterentwickelt? Wir haben das Thema Commodity. Rechenleistung kommt bei uns heutzutage fast schon aus der Steckdose. Das sind virtuelle Maschinen bei irgendwelchen Cloud Anbietern oder eben von Serverless-Produkten, die man einfach so anzapfen kann, wenn das Internet geht natürlich. Und das ist auch etwas, wo die Evolution noch mal ein Stück weitergeht. Ich habe plötzlich etwas, was universell irgendwo da ist, was ich gut herstellen kann, was ich in sehr guter Qualität und Zuverlässigkeit jemandem anbieten kann und wo ich eben auch weiß, dass da ein Massenmarkt da ist, der das auch benötigt, was ich herstelle. Und das ist, wie gesagt, dieses Thema Liquidity, Commodity, Gebrauchsgut, wo ich auch so auf der Evolutionsachse sehen kann, dass ich da noch etwas weiterentwickelt hat und massentauglich gemacht wurde. Das mit der Bewegung ist immer so, wenn genügend Bedarf und wenn ich es gut herstellen kann, ist die Bewegung von der initialen Idee bis zum Gebrauchsgut da. Das kann ich mit dieser Achse im Endeffekt dann auch visualisieren bzw. kommunizieren.

Lucas: Bedeutet das denn, dass man sich auf beiden Achsen bewegt? Bei der Evolutionsache ist offensichtlich, dass es sich irgendwie bewegt. Irgendwelche Sachen sind erst mal in Entstehung und irgendwann sind sie Gebrauchsgut. Ist das denn in der Wertschöpfung auch so, dass sich das bewegt oder ist das statisch, wo das sich befindet?

Markus: Bei der Position auf der Wertschöpfungskette ist es ein Thema, wer blickt gerade da drauf? Und da können sich diese unterschiedlichen Komponenten unterschiedlich eingruppieren. Dass sich jetzt eine bestehende Komponente noch mal irgendwie nach oben oder unten bewegt, ist eher nicht der Fall. Da gibt es zwar Bewegung in der Art, da komme ich später noch dazu, wenn wir mal über diese ganzen Muster und Strategien reden. Da wird es noch mal offensichtlich, wie das geht. Im Gegensatz zu evolviert, da verwertschöpflicht sich auch nichts oder bewegt sich da so, ähnlich wie zu der Evolutionsachse. Das ist eher was Statisches an der Stelle.

Lucas: Okay, verstehe. Gut, wir haben jetzt so ein Koordinatensystem im Kopf. Jetzt wollen wir da darauf Sachen einzeichnen. Was zeichnen wir denn jetzt in unsere Karte ein?

Markus: Wir zeichnen Komponenten ein. Ein super Begriff, denn der bedeutet nichts. Und wie gesagt, das macht das Thema Wardley Map auch wieder sehr universell einsetzbar. Im einfachsten Fall würde ich sagen, wenn wir im Podcast darüber sprechen, dann könnte man beispielsweise mal beim Thema Softwaresysteme ein bisschen was einzeichnen an der Stelle. Oder auch Wissen über Softwaresysteme. Das finde ich ganz schön, um damit zu zeigen, wie das funktioniert. Vielleicht um auch die Hörerinnen und Hörer da ein bisschen mitzunehmen, um sich das auch mal visuell vorzustellen. Denn wir haben schon ein Problem, wenn das so auditiv ist. Ein Gedankenexperiment bzw. kleines Experiment für zu Hause, wenn ihr nicht jetzt gerade irgendwo Auto fahrt oder Zwiebeln scheidet, dann könnt ihr mitmachen. Schnappt euch mal eure linke Hand und macht da mal eine Pistole draus. Daumen nach oben und Zeigefinger nach vorne. Und dann dreht mal diese Pistole zu euch hin. Also nach rechts und ihr seht den Daumen oben und den Zeigefinger nach rechts. Den Daumen nach oben und den Zeigefinger nach rechts zeigen. Dann habt ihr den Daumen. Den könnt ihr euch mal vorstellen als die Wertschöpfungskette. Wenn ihr dann ganz oben etwas habt, in eurem Koordinatensystem, das wäre zum Beispiel bei der Versicherung sehr nahe, bei den Versicherungsinteressierten, wenn man weiter unten runtergeht beim Daumen. Das ist etwas, was so ein 0815 Benutzer einer Software gar nicht sieht. Das ist der Daumen. Zeigefinger, der so noch von links nach rechts deutet, das ist die Evolutionsachse. Wenn man da genau hinschaut, auf den Finger, sind auch Faltungen da. Und zufälligerweise ergibt es vier Sektoren, wenn man hinschaut. Ich habe da von meiner Hand ausgehend hier bis zum Ansatz des Zeigefingers einen Sektor. Das wäre eine Phase, die Genesis Phase, da wo wir noch gar nicht wissen, was hier gebraucht wird. Zweite Phase ist das Thema Einzelanfertigung. Das dritte Thema ist schon Produkt-mäßig, das kann ich einigermaßen gut herstellen, wird auch gut nachgefragt und dann die Zeigefingerspitze, das ist Commodity. Das sind unsere Cloud Services, das Ding aus der Steckdose. So, jetzt kann ich in diesem aufgespannten Koordinatensystem diese Komponenten beliebig platzieren, beispielsweise wenn ich etwas ganz oben habe und ziemlich weit links. Das sind so innovative Produkte, die vielleicht neue Trends heraufbeschwören, wo Leute, die ähnliche Dinge herstellen, auch neue Geschäftsfelder explorieren und ausprobieren möchten. Und wenn ich jetzt beispielsweise ganz rechts unten schaue, ziemlich nah, kurz über der Zeigefingerspitze, habe ich so was wie das Thema Rechenleistung aus der Steckdose. Das kann ich mir da auch platzieren und entsprechend dann mit anderen kommunizierbar machen. Was habe ich jetzt davon gewonnen? Ich kann jetzt beispielsweise auch, das ist auch noch ein wichtiger Punkt, diese einzelnen Verbindungen zwischen den einzelnen Komponenten noch mal betrachten und mir diese auch mal vorstellen. Dann gehen wir zum Beispiel nach links oben, da habe ich die super innovative Versicherungsapp beispielsweise, rechts unten den Cloud Service, der letztendlich irgendwann die Rechenleistung für diesen Versicherungsservice bereitstellt. Da habe ich eine Verbindung. Irgendwann mal komme ich mit diesem Thema: Braucht, braucht, braucht. App braucht Datenspeicher, braucht Rechenleistung usw. Dahin, dass ich Ketten aufbaue und Verknüpfungen zwischen diesen einzelnen Komponenten auf meiner Wardley Map auch sehe. Und das ist das, was auch passiert, wenn man das im Büro macht oder in Mural oder auf ein Blatt Papier. Man zeichnet sich so eine Karte von der eigenen Situation, um das erstmal offensichtlich zu machen und da vielleicht schon mal ein paar Dinge rauszudiskutieren. Das ist das, wie die beiden Achsen zusammenhängen und wie ich mir so eine Karte bauen kann. Und vielleicht auch bildlich oder mit den Fingern, mir auch vorstellen kann.

Lucas: Wir haben jetzt bildlich unsere Hand vor Augen. Was mache ich denn jetzt damit? Jetzt habe ich die Sachen da aufgeteilt und weiß jetzt, wo sie sind. Aber was hilft mir das denn?

Markus: Jetzt kannst du anfangen, mal darüber zu reflektieren, ob das überhaupt so passt, was du gemacht hast. Und da hilft uns auch Simon Wardley mit so einer Art Mustersprache, die wir anwenden können, um unsere aktuelle Situation zu reflektieren. Vielleicht machen wir unser Beispiel ein bisschen komplizierter, um zu zeigen, was dann sofort draus gesehen werden kann aus unserer Situation. Gehen wir davon aus, wir haben die Versicherungsapp oben, Rechenleistung ganz rechts unten und wir machen uns jetzt Gedanken, Rechenleistung, das ist uns mit der Cloud alles zu wild. Lasst uns doch mal das machen, was jeder macht, wir führen Kubernetes ein. Das habe ich in der Zeitung gelesen und das ist bestimmt cool, sowas zu haben. Das kann ich auch platzieren auf dieser Karte, um zu sehen, wie die Gesamtdarstellung da wird. Kubernetes ist erst mal ein Produkt, da kann ich das einordnen. Und es ist auch ziemlich weit unten, wenn man von der Perspektive eines End-Users ausgeht. Das würde ich schon sagen. Für Entwickler ist es weiter oben, das kommt auf den CV und für den Kubernetes Developer Advocate ist es sicherlich sehr weit oben. Da sieht man auch, das Anker-Thema ist wichtig, aber so fancy Dinge macht man jetzt nicht mehr. Wie gesagt, machen nur noch 15 Anwendungen und deswegen ist das tief unten im Maschinenraum irgendwo mit verborgen. Dann habe ich jetzt sozusagen die Idee, Versicherungsanbindungen, ein paar andere Komponenten über Kubernetes laufen zu lassen und dann kann ich hingehen und fragen: Bringt mir das jetzt beispielsweise etwas, diesen Eigenbetrieb zu machen, wenn ich doch weiß, Rechenleistung ist eigentlich etwas, was ich aus der Steckdose nutzen kann? Von AWS ist das auch ein Service beispielsweise. Will ich nicht eher dahin? Und nicht selbst immer ein eigenes Rechenzentrum betreiben? Oder ist das generell nicht schlecht, da irgendwie noch mal zurückzuswitchen von den voll automatisierten Bereitstellungen von Rechenleistung? Weil nicht, dass es deevolviert und ich eigentlich einen Rückschritt mache. So was kann ich beispielsweise da mal kommunizieren. Es kann rauskommen, dass es durchaus gut ist, dass man das macht aus diversen Gründen. Die kommen da zur Sprache, das spricht man an, oder dass man sieht, wie hanebüchen eigentlich diese Idee ist, weil man eigentlich schon weiter ist als alle anderen, die jetzt momentan Kubernetes machen, wenn man schon etwas cooler aufgestellt ist. Cooler im Sinne von: Ich habe eine Technologie, die für meinen Use Case besser passt als das, was alle anderen machen da draußen. Das ist was, was ich da sehen kann. Und dann habe ich auch gesagt, Komponenten, das können nicht nur so was wie Aktivitäten sein, Dinge, die herstellen oder Praktiken und so was, sondern ich kann auch mal so ein Wissens-Check machen. Beispielsweise noch mal eine Komponente einführen, wenn ich frage: Wie viel weiß ich denn überhaupt über den Betrieb, den On Premise-Betrieb im Entwicklungsteam oder in meinen betrieblichen Abteilungen? Und da kann kommen, dass ich sage: Es ist zwar von der Wertschöpfungskette her gesehen unterhalb von Kubernetes, denn Kubernetes braucht eben Wissen zum Betrieb von Kubernetes, dass es so eine Abhängigkeitsbeziehung wieder ist, wo ich nochmal eins runtergehe und dann kann ich schauen, wo will ich das evolutionsmäßig einordnen? Das ist vielleicht ganz links, weil ich noch nie etwas damit gemacht habe und vielleicht einen Zeitungsartikel darüber gelesen habe. Und dann kann ich noch mal so einen Punkt über mein Wissen über Kubernetes anbringen, eher links unten, Daumen trifft sich mit Zeigefinger sozusagen, da platzieren wir das auf meiner Fingerkarte, um da auch zu sehen: Eigentlich habe ich da ein kleines Problem. Ich müsste eigentlich Kubernetes produktmäßig in diesem Evolutionsstadium betreiben können, aber ich sehe: Ich habe eine Abhängigkeit. Ich brauche noch Wissen zu dem Betrieb und das liegt bei mir noch total im Unklaren. Und dann sehe ich so etwas wie: Ah, ich habe da ein Defizit Richtung Wissen und müsste da erst Wissen aufbauen, um entsprechend so eine Komponente angemessen in der eigenen Evolutionsphase entsprechend bereitstellen zu können. So etwas kann ich auch machen. Ich sehe schon bei dem Status, den wir jetzt haben: Ich platziere einfach mal die Komponenten und mache vielleicht Pläne für die Zukunft oder schaue, ob ich da vorhandene Konstellationen, wie eben geschildert, auch schon jetzt habe, was ich damit mache, um mir da ein Bild zu machen. Das ist das, was ich jetzt schon gewonnen habe.

Lucas: Eine Sache, die ich, glaube ich, auch noch sehen würde, die man gewinnt, ist, wenn man jetzt als Entwickler:in oder Architekt:in darauf schaut, dass man vielleicht auch noch mal sich selbst klarmacht, an welchen Stellen muss ich mehr Überzeugungsarbeit zum Management leisten und bei welchen Sachen vielleicht weniger?

Markus: Genau, das ist auch ein ganz wesentlicher Punkt. Das ist richtig. Das kommt auch mit. Ich sehe automatisch, wie viel Marketing ich betreiben muss als Techniker oder Technikerin, weil es von einem Endnutzer und darauf wahrscheinlich auch von einem, der Entscheidungen fürs Produkt trifft, eben zu weit weg ist und nicht interpretierbar ist. Wenn es darum geht, neue Technologien einzuführen, dann muss ich mit mehr Metaphern arbeiten, vielleicht auch Übersetzungsarbeit machen zu: Was bringt mir das auf der Businessseite, wenn ich da super skalierbare Bit- oder Rechen-Ressourcen hin und her schieben kann im eigenen Rechenzentrum. Da muss ich ein Business Case machen, das mehr mit Zahlen entsprechend zu transportieren, um da andocken zu können. Leute, die oben an der Wertschöpfungskette stehen, um bei denen einen Fuß in die Tür reinzubekommen und die in die Diskussion damit einzuspannen. So etwas sehe ich definitiv auch.

Lucas: Ich glaube, das ist auch hilfreich, wenn man sich dann noch mal die Zwischenhops anschaut zwischen der obersten Ebene, die interessant ist, um Geld zu verdienen und der Ebene, über die ich gerade sprechen will, wie viele Hops sind dazwischen? Dann kann ich vielleicht auch noch meine Argumentation schärfen, um noch mal das auf die Kernbedürfnisse des Unternehmens zurückzuführen, weil ich glaube, das ist etwas, was vielen Entwicklerinnen doch eher schwerfällt.

Markus: Ja, vielleicht kannst du so was wie Dinge sehen, die du nicht machen solltest. Das Thema, du brauchst dein eigenes Logging Framework, ist ziemlich weit unten und vielleicht nicht so evoluiert wie das, was es draußen gibt am Markt. Das sieht man auch direkt und da merkt man auch gleich beispielsweise für Modernisierungsprojekte. Wenn ich da meine App weiterbringen möchte, muss ich zwangsläufig auch die Fähigkeiten, die unten liegen, weiterdenken. Beispielsweise das Thema Co-Evolution. Das wird sich weiterentwickeln müssen, weil ich sonst wieder in die Lage komme, dass ich etwas habe, worauf ich aufbaue, was noch nicht so stabil ist. Oder ich muss mir Taktiken oder einen Kompensationsmechanismus überlegen, um mit diesem Umstand umgehen zu können. Vielleicht mache ich das mal kurz plastisch an dem Thema Cloud Ressourcen fest. Eine Geschichte, die man vielleicht gehört hat von Netflix. Die haben angefangen Mitte der 2000er ihren Streamingdienst umzubauen auf AWS mit den EC2 Instanzen. Wenn man sich das mit Wardley Maps vergegenwärtigt, hat man eigentlich einen Streamingdienst. Die Videos kommen aus der Steckdose, das ist sozusagen Commodity, ich muss irgendwo klicken und dann kommt der Film. Damals war es so, mit AWS, wie die das aufgebaut hatten, war die Rechenleistung noch nicht so weit evolviert, wie ein Streamingdienst das eigentlich gebraucht hätte. Wenn man so eine Abhängigkeitsbeziehung wie: Streamingdienst ist ganz rechts. Evolutionsachse baut auf etwas auf, braucht Rechenleistung, das noch nicht so weit evolviert ist, was ein wenig weiter Links ist, wenn man sich die Map mal wieder vorstellt. Es gibt so eine komische Situation, die man da direkt rauslesen kann, ähnlich wie mit dem Beispiel Commodities und Wissen Commodities, gleiches visuelles Muster. Und dann muss ich eine Technik verargumentieren, wie ich jetzt mit diesem blöden Umstand umgehen kann. Kaufe ich beispielsweise AWS und sorge dafür, dass diese blöden EC2 Instanzen besser laufen. Das wäre eine Taktik. Oder wenn ich das nicht kann, wie kann ich dieses Problem kompensieren? Und da haben die beispielsweise angefangen, bei Netflix wahllos irgendwelche EC2 Instanzen abzuschießen. Um halt trotz dieses Umstands, dass sie auf etwas aufbauen, was nicht so weit evolviert ist, trotzdem erfolgreich wieder stabile Dienste anbieten zu können. Das ist dann noch mal so ein Beispiel, dass man auch sehen kann, es muss irgendwie vorangehen und auch wie vorher das Beispiel mit dem eigenen Kubernetes. Ich muss das jetzt auch irgendwie mitziehen oder ich lasse es dann. Ich setze das etwas, was vielleicht schon weiter involviert ist, um da aus dem Vollen zu schöpfen, was mir vielleicht auch ein Zulieferer bietet. Und befreie mich von Altlasten, wenn ich weiß, ich habe da keine Zeit mehr dafür. Diesen ganzen ‚Muss da sein‘ Quatsch auch noch selbst zu machen. Da habe ich auch die Möglichkeit so was zu sehen und zu argumentieren, dass ich das loswerden möchte, weil wir ansonsten zu viel Entwicklungskapazitäten an Dingen machen, die eigentlich nicht im Blickpunkt des Produkt-Managements sind oder uns irgendwie differenziert von den anderen da draußen.

Lucas: Es erinnert mich auf jeden Fall auch ein bisschen an dieses Not invented here. Dass man vielleicht dann an manchen Stellen noch mal prüfen sollte, ob man gerade ein Gebrauchsgut gegen einen Eigenbau ersetzt, nur weil man es gerne möchte.

Markus: Ja, das kann auch sehr gefährlich sein. Ich habe ein Beispiel gesehen, dass man nicht nur irgendwelche Software Systeme oder Teile auf der Karte, die man beziehen kann, sondern auch Praktiken und da habe ich erlebt, wo jemand im Charter Umfeld ganz viele Java Tomcat Server Container gestartet hatte auf verschiedenen Servern und sich ein eigenes Tool geschrieben hat, um bei Ausfällen von diesen Servern, Out of Memory exeptions beispielsweise, diese Server effizient neu starten zu können. Und der hat nicht verstanden, weshalb er kein Budget bekommt, um dieses Dashboard, um Server händisch mit Mausklicks neu starten zu können, weil man da kein Budget bekommt, dieses System weiterzuentwickeln, denn das muss mehr skalieren. Dann ist da auch die Frage: Bringt es das überhaupt? Denn eigentlich unterstütze ich da doch eigentlich so eine schlechte Praktik, die ich mit diesem supertollen Restarting-Teil umsetze. Da ist die Praktik, dass ich viel akzeptiere und dann nur im Fehlerfall drauf reagiere und dann Server abschieße, in der Hoffnung, dass sie sich wieder fangen und wieder hochfahren. So ein Thema war das da und das mache ich manuell. Und da sehe ich auch, dass ich vielleicht, wenn ich da nicht aufpasse, eine schlechte Taktik weiter evolviere und dann vielleicht ins Messer laufen, weil da draußen bessere Praktiken da sind, die mir mit meinen neuen Bedürfnissen auch in der Entwicklung mehr bringen, als manuell Server effektiv zu starten. So etwas kann ich auch sehen. Da brauche ich einen Praktikenwechsel, beispielsweise dass ich jetzt sage, wir machen dieses Thema Resilienz bei uns in unserer Anwendung, die automatisieren das Abschießen beispielsweise oder wir sorgen dafür, dass wir vorhersagen, wann ein Server vielleicht nicht mehr da ist oder wir machen eine Praktik, die Root Cause Analyse, dass wir jetzt sagen: Woran liegt es überhaupt, dass die Server weg sind? Das sind Praktiken, die da besser geeignet sind. Und wo ich auch sehen kann, dass ich da nicht immer das Richtige machen würde, weil sonst irgendwie ein Lead verloren gehen könnte, da komme ich mit dieser alt und lieb gewordenen Praktik einfach nicht mehr weiter, weil es sich erledigt hat im Endeffekt.

Lucas: Verstehe. Ich kann mir jetzt auch gut vorstellen, dass, wenn man sich jetzt viele Wardley Maps für verschiedene Sachen angeschaut oder vielleicht auch erstellt hat, dass es dann irgendwann den Zeitpunkt gibt, wo man vielleicht wiederkehrende Muster sieht, Sachen sieht, die einem einfach immer wieder begegnen. Gibt es da irgendwelche Muster, die bekannt sind aus der Community oder auch vielleicht aus deiner eigenen Beobachtung?

Markus: Genau. Ich sage immer, die eigentliche Karte ist schon ziemlich witzig, um Dinge zu visualisieren und auch zu kommunizieren, wo ich hin möchte. Das kann ich auch mitmachen. Ich möchte irgendwas setzen, das schon evolviert ist. Es ist schon Augen öffnend. Da gibt es etwas, das nennt sich dann auch, das ist das mit dieser Mustersprache eigentlich, dass es auch noch in diesem Umfeld und das finde ich noch mal, ich kann kein Faktor sagen, aber schon um einiges noch spannender, weil ich dann auf Basis von bestehenden Wardley Maps auch schauen kann und mich anmerken lassen kann, was ich jetzt als Nächstes tun könnte. So etwas wie ideengebende Maßnahme. Und da hat Simon Wardley 3 bis 4 unterschiedliche Kategorien von Musterarten an die Hand gegeben. Das können wir mal durchgehen, beispielsweise das Thema klimatische Muster, das haben wir schon mal angerissen. Was sind klimatische Muster? Das ist so was wie, wenn ich jetzt in der echten Welt unterwegs bin, habe ich auch verschiedene Klimazonen und da wirken verschiedene Dinge auf mich ein. Hier sind es 36°, Spätsommer, da kann ich mich einstellen, da kann ich jetzt eine kurze Hose anziehen, eine Mütze aufziehen usw. Aber wenn ich jetzt in der Antarktis bin, muss ich mich auch wieder alles einstellen. Je nachdem, in welchen verschiedenen Klimazonen ich mich bewege, muss ich mich unterschiedlich kleiden in dem Fall. Das ist auch etwas, was sozusagen von diesen Climatic Patterns übertragen wurde auf die Wardley Maps von Simon Wardley. Je nachdem, wo sich eine Komponente dann entsprechend auf dieser Karte befindet, muss man sich unterschiedlich einstellen. Das ist das, was da mitschwingt und das sorgt auch dafür, dass wenn ich mich nicht darauf einstelle oder wenn ich dann in dieser Zone bin, dass auch etwas auf mich einwirkt. Das ist auch ein wesentlicher Punkt. Mit mir passiert irgendwas. Wenn ich jetzt in die Arktis gehe mit einer kurzen Hose. Was passiert jetzt? Das ist etwas, das ich auch beim Thema Wardley Map habe. Es gibt Dutzende Patterns. Vielleicht greife ich mal etwas auf, was wir schon mal hatten. Z.B. das Thema, dass eben alles weiter evolviert, was ich auf der Karte habe, wenn genügend Nachfrage da ist. Nachfragewettbewerb und Angebotswettbewerb. Wenn ich das habe, dann habe ich eine Komponente, die schiebt sich von links nach rechts auf meiner Wardley Map. Und das ist einfach so ein Ding, das immer einwirkt. Und da kann es sein, dass ich irgendwann so einen Übergang mache. Ich muss immer mal anders denken. Ich muss jetzt von einer Einzelanfertigung. Ich habe jetzt ein Softwaresystem für einen einzelnen Kunden gemacht und das wird total gut angenommen. Andere Kunden schauen auch schon irgendwie und möchten das auch haben. Dann sage ich: Okay, ich habe jetzt einen Übergang zu der nächsten Phase, dem Produkt beispielsweise. Und da kann es passieren, dass ich aus so einem Übergang etwas anderes machen muss, was ich noch nie gemacht habe oder wovon ich nicht weiß, dass es irgendwie erfolgreich ist. Und da gibt es auch so ein Thema, dass ich da irgendwo mal mehr oder weniger diese Rückhaltekräfte habe, die mich immer zurückhalten, in die nächste Stufe zu gehen. Das kann so etwas sein wie das erfolgreiche Geschäftsmodell in der Vergangenheit, dass ich auf einzelne Kunden zugeschnittene Software gebaut habe, was sehr erfolgreich war, das hält mich jetzt plötzlich davon ab, vielleicht mit anderen Kunden in Gespräche reinzukommen, um die auch mein Einzelding als Produkt anbieten zu können. Mich hemmt das irgendwie, weil ich nicht weiß, ob das geht. So etwas kann mich zurückhalten und es wirkt eben auch als klimatisches Muster, je nachdem, wo ich dann entsprechend meine Komponente auf der Wardley Map tapeziert habe. Und das ist etwas, was klimatische Muster als Beispiel sind.

Lucas: Verstehe, das heißt, wenn ich dich richtig verstehe, es gibt nicht nur eine Art von Muster, sondern es gibt mehrere Arten von Mustern. Neben den klimatischen Mustern, was gibt es denn noch?

Markus: Ich habe die klimatischen Muster herausgepickt, weil man da auf einer bestimmten Landkarte ziemlich schnell bewerten kann, was jetzt los ist. Davon kommen wir. Wir haben diese Karte gehabt, was macht man jetzt damit? Klimatische Muster anschauen, um zu wissen, wo wir stehen und was auf uns einwirkt. Und andere Musterarten finde ich auch spannend. Beispielsweise so etwas wie im englischen Doktrine oder Maxime. Das sind universelle Wahrheiten, die sich noch nicht als ganz falsch herausgestellt haben. Dinge, die es vielleicht lohnt zu tun, weil die uns weiterbringen können. Und das nächste Thema, das für uns sehr spannend ist, das Thema Gameplay, Strategeme oder Listen, die ich fahren kann. In dem Sinne: Ich weiß, wo ich bin. Ich weiß vielleicht auch, wo meine Konkurrenz ist, welches Spiel kann ich jetzt treiben und mich absetzen von meinen Konkurrenten? Das finde ich auch ganz spannend, dass es da noch so Sammlungen gibt, die so Ideen aufbringen können, wie man jetzt weitermacht. Ich könnte mal was durchspielen mit den Doktrinen. Das kann auch mal spannend werden. Aber was teilweise ziemlich offensichtlich ist, was man auch nicht macht, bei so einer Doktrin, wäre das Thema: Kenne deine User. Wissen, wofür du die Software machst. Ich habe schon mitbekommen, dass Software entwickelt wird, wo man gar nicht weiß, wer die benutzt. Das soll vorkommen. Wäre aber nicht schlecht, zu wissen, für wen man das macht, weil sonst weiß ich nicht, was die für Bedürfnisse haben und was ich dafür machen muss. Sonst mache ich irgendwas und verzettle mich vielleicht auch in Diskussionen, die überhaupt nicht auf die User einzahlen. Das zweite, Fokus auf User Needs. Fokussiert auf die Bedürfnisse deiner Anwender oder allgemein deiner Stakeholder, die die Software irgendwie auch verwenden oder damit in Kontakt kommen. Verliere die nicht aus dem Blick, denn das gepaart mit dem Wissen, wer überhaupt die User sind, macht die eine oder andere technische Diskussion erst mal obsolet und lässt uns fokussieren auf die wichtigen Dinge, die passieren sollen bei uns in der Softwareentwicklung.

Lucas: Bei den Mustern und den Diskussionen davor klang es ein bisschen so, als gäbe es da auch nichts, wo ich jetzt als Entwickler, also ich, Lucas als Entwickler, vielleicht auch noch was rausziehen kann. Gibt es irgendwas, wo ich sagen könnte: Ja, das hilft mir persönlich auf der Wardley Map weiter?

Markus: Ich denke schon. Ich denke, dass man sich dadurch auch viele Situationen besser erklären kann. Und wenn man das zeigen kann, kann man auch besser Konflikte vorhersehen, die angehen und auf neutralem Boden der Wardley Map mit lösen. Dann hat man eben nicht so ein Problem, dass man sich dann ständig irgendwie beleidigen muss in Meetings und niemand mehr mit jedem spricht, sondern dass man ganz sachlich über die aktuelle Lage diskutieren und zeigen kann, dass etwas nicht so funktioniert. Und bei den klimatischen Mustern, da muss man reinschauen. Das ist ein Supermodel, das ein bisschen Konflikt und Spannungen zeigen kann. Das kann man auch mal kurz durchgehen. Ich denke, das ist auch mal wert, das zu kennen. Das ist das Thema Pionier Siedler Städteplaner Modell, das man verwenden kann, um so verschiedene Einstellungen von Leuten, die an Entwicklung beteiligt sind, besser fassen zu können. Das will ich mal erklären. Das Modell, das geht davon aus, dass man auf der Evolutionsachse von links nach rechts anfängt mit Leuten, die Pioniertätigkeiten machen. Was machen Pioniere? Die gehen in ein unbetretenes Land und versuchen da sich durchzubeißen, suchen erste Pfade. Das ist sozusagen die Software Entwicklung, dass man Leute hat, die stehen auf Experimente, auf coole, neue Ideen, die sie umsetzen. Und die wollen einfach dieses Abenteuer, die wollen auch dieses schnelle Feedback haben zu dem, was sie getan haben. Wenn sie einen Baum gefällt und die Hütte kaputt gemacht haben, möchten sie sofort wissen, dass das nicht die Lösung ist. Und das spiegelt sich da wider, auch in Methoden, die wir verwenden. Beispielsweise, dass wir da mehr Vorgehensmodelle nehmen, die uns passende Vorgehen für diese Pioniere oder diese kreativen Köpfe bei uns in der Entwicklung entsprechend dann bieten, z.B. agile Entwicklung, wo wir auch nah am Kunden sind, um Experimente schnell validiert zu bekommen. Und das kann ich ihm da auch entsprechend platzieren. Pioniere sind super Typen und Mitarbeiter, aber es gibt auch andere Persönlichkeitstypen, die dann vielleicht auch später in der Softwareentwicklung eine Rolle spielen. Und da gibt es z.B. diese Siedler, Super Typen und die nehmen beispielsweise so… die gehen den Pionieren erst mal nach und versuchen da die ersten Hütten aufzubauen, die auch stehen bleiben. Die gehen da systematisch heran an die Themen wie beispielsweise Nahrung finden, bauen erste Felder an oder machen die Felder urbar und bauen erste Nahrung an. Die sind ordnend und die sind so, wenn es wieder zurück zu Wardley geht und zu den Entwicklern. Dass die in den mittleren Phasen, Einzelanfertigung Richtung Produkt entsprechend involviert sind. Denn das sind die Leute, die erstmalig sowas machen, wie Doku schreiben oder dafür sorgen, dass eine saubere Struktur der Software da ist. Das kann man sich auch leisten, wenn man weiß: Okay, das Geschäftsmodell, das funktioniert beim Kunden, die können das einigermaßen gut herstellen. Aber vielleicht haben sie jetzt das Thema, es müssen neue Teams mit onboarden, wir müssen von einem Team auf vier aufstocken, weil das mega skaliert, was sie jetzt vom Geschäftsmodell her machen und deswegen müssen wir dafür sorgen, dass mehrere Leute gleichzeitig im Software System mitarbeiten können. Die brauchen einfach mehr Struktur, die brauchen mehr Regeln oder mehr Guidance, je nachdem. Das kann man natürlich unterschiedlich ausgestalten, um weiterarbeiten zu können. Indem die da entwickeln, die in der Siedlerrolle sind. Er hat die arc42-Templates das erste Mal genutzt, die arbeiten über den Pionier rüber, um es weiterzuentwickeln. Die haben da richtig Lust drauf, bestehende Sachen zu nehmen, das Thema Refactoring anzugehen und scheuen sich auch nicht davor, das eine oder andere, was jetzt nicht mehr notwendig ist, auch mal wegzunehmen aus diesem Konglomerat der entstandenen Software. Und dann geht es natürlich in die letzte Phase und das ist ganz speziell so Richtung Gebrauchsgut, Commodity. Auf der Evolutionsachse ganz rechts. Das sind die Städteplaner. Das sind super Typen. Was machen die? Die nehmen auch wieder die Arbeiten von Siedlern und machen die ultra skalierbar und ultra zuverlässig. Die versuchen einfach Schwankungen im Betrieb runterzunehmen von dem Softwaresystem. Für die ist es keine Option, das Softwaresystem abzuschalten, sondern die wollen hier eine Community, so einen kontinuierlichen Betrieb aufrechterhalten und sind ständig am Optimieren, am Analysieren, um eben das letzte Quäntchen an Stabilität und an Servicequalität für die Nutzer:innen weiter zu bringen oder zu liefern. Wenn man da auch wieder in so Vorgehensmodellen spricht, habe ich für die Siedler ausgelassen. Das muss man nachholen. Ich weiß, was ich tun muss. Also habe ich gleich eine komplette Liste an Aufgaben. Die arbeite ich einfach ab, dann brauche ich ein Kanban Baord, weil ich einfach weiß, wo ich hin möchte. Ich gehe wieder zurück zu den Städteplanern ganz rechts. Die sind optimiert unterwegs, analysierend. Vielleicht brauchen die da ein Prozessmodell, das ziemlich darauf aus ist, Schwund wegzunehmen und zu optimieren. Also Prozess-Exzellenz zu machen, um betriebliche Abläufe zu optimieren, für die Leute ist so was attraktiv. Oder ich sage, ganz rechts will ich nicht mehr machen als Firma. Da ist natürlich die Alternative zu sagen: Lassen wir die Finger davon, das ist mir zu heiß, das ist zu viel wert. Dann überlasse ich diesen Part vielleicht anderen Firmen, irgendwelchen Zulieferern, weil ich weiß, auf diese Seite so Richtung Gebrauchsgut oder Gewohnheitsgut, da sind Services draußen in hinreichend guter Qualität, die ich einfach selbst nutzen kann. Da spare ich mir dann diese Städteplaner und die Aufwände da entsprechend, dann eine coole Software hinzustellen bei mir in meinem eigenen Betrieb.

Lucas: Ich finde es auch deswegen gut, dass ein bisschen im Kopf zu behalten, weil meine Beobachtung aus Projekten oft ist, dass diese drei Gruppen gegenseitig auf sich herabschauen. Die Städteplaner finden die Pioniere doof, die Pioniere finden die Städteplaner doof. Und ich glaube, du hast es ganz gut erklärt, dass jede von diesen Persönlichkeitstypen in verschiedenen Phasen vielleicht auch Stärken ausspielen kann, dass nicht gut wäre, wenn alle Leute nur Pioniere wären. Es wäre auch nicht gut, wenn alle Leute nur Städteplaner wären. Das, finde ich, kann man da gut rauslesen.

Markus: Ich muss drauf achten, auch in meinem Team, wenn ich diese Rollen eigentlich wechseln muss. Da werden die Leute nicht glücklich. Software evolviert von links nach rechts. Am Anfang habe ich eine coole App geschrieben, jetzt bewegt sich die auch weiter. Und jetzt kommt plötzlich jemand an und will von mir eine Auftragsdatenverarbeitungserklärung. Da habe ich Lust, das zu schreiben oder der andere möchte eine Schnittstellendokumentation. Nein, mache ich nicht. Und dann muss man wissen, dass es jetzt ansteht, diese Art von Arbeit und dass dadurch eben, dass, wenn man das nicht betrachtet, Frust entstehen kann. In den Pionieren beispielsweise, dass sie dann vielleicht rausgehen oder andere Projekte suchen. Deswegen muss ich schauen, dass ich da einen gesunden Mix habe und die richtigen Leute an den richtigen Stellen, richtigen Phasen entsprechend dann auch im Team habe, um solche Spannungen frühestmöglich zu erkennen und das schon mal auf dem Schirm zu haben, gut und gesund weiterentwickeln zu können.

Lucas: Und auch vielleicht die Aufgaben entsprechend des Persönlichkeitstyps zuzuordnen. Es ist nicht so, als wäre man konkret in einer Phase, sondern man ist dann mit verschiedenen Teilen seines Produkts in verschiedenen Phasen, da kann man dann vielleicht die Leute auch dementsprechend zuteilen. Du hast schon bei den Mustern eine Kategorie von Muster erwähnt. die Kriegslist. Da hast du uns noch kein Beispiel zu geben. Hast du da vielleicht noch ein Beispiel, was wir uns vorstellen können?

Markus: Die Kriegslisten, die Gameplays, die Wardley uns auch an die Hand gibt. Ja, kann ich auch machen. Ich muss sagen, da muss ich aufpassen. Ich bin ein Fanboy geworden davon, da bin ich ziemlich fasziniert. Um es kurz zu machen, eine Strategie, die ich machen kann. Deswegen frage ich das so ab, ist Refactoring. Ich kann versuchen, mein Softwaresystem von der Codequalität her besser zu machen, um beispielsweise eine bessere time-to-market zu bekommen, weil ich da bessere Demokratisierung habe, an die ich verschiedenen Teams dransetzen kann. Deswegen ist Refactoring ein Gameplay, um von dem Ballast von früher wegzukommen und sich davon nicht irgendwie runterziehen zu lassen. Aber es gibt auch ganz andere Arten von Gameplays. Simon Wardley hat es auch ein bisschen verknüpft mit dem Dungeons and Dragon Thema. Und zwar gibt es da so Gameplays, die hat er nach dem Alignment System von Dungeons and Dragons gemacht. Zum Beispiel gibt es Lawful Good-Praktiken, die ich machen kann oder Lawful Evil. Wer das nicht kennt: Lawful good ist Superman. Lawful evil ist Darth Vader. Der Joker ist Batman. Wardley hat diese verschiedenen Gameplays kategorisiert und da würde ich mal welche rauspicken. Beispielsweise, was ich ziemlich fies finde, was ich machen kann, ist das Thema… Ich kann andere Konkurrenten vergiften. Es gibt ein Gameplay, das nennt sich Insertion. Das ist, ich suche als Firma Leute, die ich reinstecken kann zur Konkurrenz, die die Konkurrenz manipulieren, er kann auch schlecht arbeiten, falsche Roadmaps machen oder so, um meine Konkurrenten ein bisschen so zu manipulieren hintenrum. Das finde ich witzig oder im positiven Falle: Ich mache Talent Grade. Ich werbe einfach die ganzen Leute ab von den anderen Unternehmen, damit die nicht mehr weiter in der Software evolvieren können. Ich hole mir ganz viele Fachkräfte, mache denen attraktive Angebote, um da entsprechend gut dazustehen, um einen Wettbewerber auszutrocknen. Bei dem Thema Fachwissen oder Entwicklungskapazitäten. Das sind jetzt ein paar Ideen. Da sehen wir auch in der Praxis das Thema Lobbyismus oder Lobby machen oder in Richtung Lobby zu gehen, beispielsweise bei der Herstellung von Steuersoftware, um Steuererklärungen zu machen. Damit kann ich da meine Konkurrenten als große Firma irgendwie in Schach halten. Was kann ich da machen? Wenn ich da sehe, Start-ups kommen eigentlich auf den Markt und möchten automatisiert Steuererklärungen irgendwie fabrizieren, dann könnte ich hingehen und sagen: Ich gehe mal nach Berlin und sage: Sorgt dafür, dass die Steuergesetze eben hinreichend komplex bleiben oder komplexer werden, weil ich das nur als große Firma in die Software gießen kann mit meiner Kapazität und boote dann sozusagen die ganzen neuen Steuer Start-ups aus. So etwas kann ich da eben entsprechend auch wieder mehr bewegen und dann entsprechend im Endeffekt so einen Spielzug machen, auch auf meiner Wardley Map visualisieren, mit einem diskutieren, ob das so eine akzeptable Taktik wäre an der Stelle. Ich glaube, wir sind auch ziemlich am Ende. So ein schönes Beispiel, denke ich, wo man das Ganze mal zusammenfassen kann, wie diese Gameplays und diese klimatischen Muster und die Doktrinen alle zusammen so funktionieren. Und ich denke, das kann man auch mal mitgeben, als Überlegung für die eigene Softwareentwicklung und die Weiterentwicklung. Ich würde da mal dieses ILC, das Innovate Leverage Commotize Pattern vorstellen, dass ist so eine Strategie, die ich ziemlich krass finde, weil man da sieht, wie man vielleicht auch ein eigenes Ökosystem aufbauen kann. Und da kann man verschiedene Patterns in der Wardley Map noch mal im Geiste durchspielen. ILC, was bedeutet das an sich? Die Idee ist, das habe ich auch noch nicht erzählt. Wenn ich eine Komponente hinreichend gut entwickelt habe, die kommodifiziert wird. Das bedeutet beispielsweise, dass die nicht ständig alle fünf Minuten down ist, sondern einen stabilen Betrieb hat. Und ich kann es so bereitstellen, dass andere es auch nutzen. Ich habe beispielsweise so was wie eine API oder zumindest eine definierte Schnittstelle, wo andere andocken können. Und da passiert es, klimatisches Muster, dass Leute herkommen und neue Emotionen auf Basis meiner Services, die ich stabil bereitstelle, aufbauen. Da entstehen neue Geschäftsmodelle. Ziemlich witzig, weil die einfach nicht mehr die ganzen Konglomerate hier unten in der Wertschöpfungskette selber bauen müssen, sondern auf etwas aufsetzen müssen, um ihre eigenen Ideen, die weiter oben, umsetzen können. Wenn das so ein typisches Muster aus dem Klimabereich, wenn etwas hinreichend stabil ist, kommen neue Komponenten, die auf diese stabilen Komponenten aufbauen, um dann höherwertige Services aufbauen zu können. Das ist so ein Thema. Das passiert immer wieder. Gehen wir davon aus, ich habe einen Cloud-Anbieter. Ich habe einen Datenspeicher, den ich einfach hinreichend gut kommodifiziert habe aus der Steckdose, und sage: Hier, tue die Daten da rein, die Schnittstelle und die ist gespeichert. Und jetzt kommt jemand vielleicht aus dem Internet of Things Bereich auf die Idee und sagt: Ah, cool, da ist ein super zuverlässiger Datenspeicher, der skaliert total, da bauen wir was drauf, wir bauen unsere Internet of Things-Plattform drauf. Das ist ein Ding, das ist höherwertig eigentlich. Es ist näher an den Endnutzern, die IoT-Services brauchen. Und ich mache die Verbindung zu diesem Datenspeicher und nutze das, um mein neues Geschäftsmodell entsprechend durchführen zu können. Sowas kann ich jetzt machen. Als Gameplay beispielsweise. Ich kann mal schauen. Da draußen ist jemand, der hat irgendwie ein spezielles Nutzungsverhalten von meinem Datenspeicher. Und da kann ich beispielsweise eine Liste machen wie: Ich schaue mir noch mal an, was rüberfliegt über die Leitung. Nicht inhaltlich, sondern Metadaten Analyse. Dieses Sensing Engine-Thema, das in diesem ILC drin ist. Ich schaue dann, wie ist denn der Bedarf von dem einen Service, der auf mich aufbaut? Um daraus zu schlussfolgern, ob das jetzt ein attraktives Geschäftsfeld für mich selbst wäre. Wenn ich sehe, okay, die sind erfolgreich da draußen, das geht hoch, denke ich vielleicht: Okay, interessant. Da kann ich mir überlegen, vielleicht eine strategische Partnerschaft zu machen mit diesen neuen Services, um zu schauen, wie die Dinge funktionieren. So etwas geht immer gut, ein bisschen vorgewarnt zu sein oder ich mache so was: Ich schaue mal, gibt es da draußen Konkurrenten, die ich vielleicht übernehmen könnte, die vielleicht im gleichen Business unterwegs sind, die ich mir schnappe, um die dann weiterzubringen, mit einer engeren Zusammenarbeit, um den ursprünglichen Initiator dieser Idee auszubooten. Oder das Thema, dass ich mir um meinen eigenen Datenspeicher noch mal andere Services hole, um mein Ökosystem an Services auszubauen, damit ich auch in IoT-Plattformen einsteigen und da entsprechend mit Services nach außen gehen kann. Das ist das, was mitschwingt, was ich auch sehen kann. Und das ist auch ein Thema, das geht immer weiter. Jetzt habe ich diese IoTh-Plattform. Da merke ich: Okay, das ist gut gefragt, ich kann es gut herstellen. Da bewegt sich das natürlich wieder rüber, wird zu Commodity. Da sehe ich wieder andere, die auf meinen IoT-Plattformen irgendwas aufbauen, wie beispielsweise das ultimative IoT Management Dashboard, um zu sehen, was da los ist in meiner Fabrik oder so. Da mache ich wieder das gleiche und ich gucke ja bei jedem dieser neuen Services, meine IoT Plattform anzubinden. Was machen die damit? Da sehe ich: Ein schöner Markt, nehme gleich wieder Konkurrenten oder verleibe dem diesen neuen Service ein. Dann habe ich den wieder, in welcher Art auch immer, entwickel ihn weiter, habe ich mit der Commodity gemacht und habe dann sowas wie einen Service draußen, dieses ultimative Monitoring Dashboard als Service. Und dann baut irgendwann wieder jemand was auf und dann kann ich das wieder spielen das Spiel. Vielleicht als Cloud-Anbieter ein Portfolio und einen eigenen Cloud-Service aufzubauen und das marktgerecht zu machen. Weil ich immer wieder schaue, was wird wirklich draußen gebraucht, und geh eben dadurch auch mit meiner eigenen Strategie drauf, um mich da entsprechend dann auch abzusetzen von dem anderen Markt und andere Konkurrenten dementsprechend abzuschalten. Das ist eine Kombination aus verschiedenen Gameplays, klimatischen Mustern. Ich weiß, wo ich bin, was auf mich einwirkt. Ich weiß, dass sich verschiedene Komponenten weiterentwickeln werden. Darauf kann ich mich einstellen. Ich kann da verschiedene Spiele spielen. Ich kann versuchen, Leute daran zu hindern, dass sie evolvieren, durch Gesetze, durch irgendwelche Intellectual Property oder ich kann selbst versuchen, da schnell voranzugehen, mit Refactoring oder anderen Themen. Und daneben da meine eigene Philosophie finden, wie ich am Markt dann agieren möchte.

Lucas: Man merkt schon, es ist ein sehr weites Thema, auf dem man viele Dinge aufbauen kann. Aber ich glaube, so langsam kommen wir trotzdem mal zum Ende unserer Folge, wo wir die Wardley Maps vorstellen. Aber ich weiß, du hast auch schon ein paar Artikel oder Blogposts dazu geschrieben. Die werden wir auch noch mal in die Shownotes packen. Aber vielleicht magst du sie noch mal kurz anteasern, was wir da noch in den Shownotes zu finden haben?

Markus:
Mir ist es wichtig, dass Interessierte sich da schnell selbstständig einarbeiten können. Vielleicht als Tipp. Man muss jetzt nicht komplett das alles, was ich hier so erzählt haben, direkt machen. Man kann ein bisschen in die Patterns reinschnuppern, da Inspiration suchen, herumkritzeln mit eigenen Maps. Das geht alles ganz gut. Und generell habe ich beim Blog feststelltaste.de habe ich immer Top 5 Blogbeiträge gemacht, wo ich denke: Das sind die Dinge, die ich jetzt empfehlen würde, um in dieses Thema tiefer einzusteigen. Und da gibt es auch für Wardley Maps einen Eintrag, der losgeht bei einem einfachen Einführungsvideo mit Vorträgen von Simon Wardley, bis hin zu seinem Buch, das auch eben beispielsweise auf vimeo.com frei zugänglich ist. Und dann Leuten einfach mal so zu zeigen, wie sie in das Thema einsteigen können. Wer ein bisschen Richtung Software Architektur, Lead Developer oder auch Produktmanagement unterwegs ist, da habe ich auch mal was aus meiner Praxis geschrieben auf innoq.com. Und zwar habe ich da mal ein Beispiel gemacht Richtung ERP System, wie das schiefgehen kann, wie das sein kann, wenn man da Dinge entwickelt und customized ERP System, wo man die Finger davon lassen sollte. Da gibt es schon eine Geschichte, die Stück für Stück mit Wardley Maps illustriert. Da kann man auch mal reinlesen, wie das funktioniert und was man damit eigentlich auch zeigen kann. Und dann habe ich auch eine Idee für das Thema Softwarearchitektur für mich. Ich mache auch Architekturberatung, teilweise auch mit Wardley Maps und da ist das Thema Qualität immer so ein Ding, was man da bespricht. Und da habe ich mal versucht, zu verschiedenen Qualitäten, so etwas wie funktionale Eignung oder irgendwie auch Wartbarkeit auf so einer Wardley Map zu positionieren, um herauszufinden, was möglicherweise Themen sind, wo man doch mal bezüglich der Qualität in tiefergehende Analysen reingehen muss. Wie gesagt, das funktioniert ziemlich gut, hilft mir sozusagen als Denkmodell bei Architekturbewertungen, um Leute da abzuholen, wo sie gerade sind, um eben da die wichtigen Dinge auch direkt ansprechen zu können, die wirklich weiterhelfen, anstatt pauschal irgendwelche Aussagen zu treffen. Wer da Lust hat, sich das Thema Quality mit Wardley Maps zusammenzubringen, da haben wir auch noch mal einen Link, der geht dann in die Shownotes.

Lucas: Super, dann danke ich dir für diese tollen Einblicke in die Welt der Wardley Maps, die Karte durch die Welt der Wardley Maps. Und vielleicht haben wir dazu auch noch einmal ein Follow up, wo es dann vielleicht noch mal in ein anderes Thema reingeht. Dann danke ich Dir ganz herzlich für Deine Zeit und den Hörerinnen und Hörern sage ich mal bis zum nächsten Mal. Tschüss.

Markus: Ciao. Bis dann wieder.