Schlagwörter: Innovation, Erfahrungen, Thema, hinzufügen, Fokussieren, Erfahrungen, Effizienz, Innovation, Thema

Transcript

Mel:

[0:00] Moin Fabian. 

Interview-Format Insights mit spannendem Gast

Fabian:
[0:01] Sali Melvin. 

Mel:
[0:02] Management by Projects, Ausgabe Nummer 23. Schön, dass ihr wieder dabei seid. 
Und wir haben, bevor wir in die heutige Folge einsteigen, einen kleinen Teaser für euch. Denn wir haben eine neue Folge aufgenommen, unseres Interviewformats Insights. 
Und wir hatten einen spannenden Gast dabei. Und das klingt dann so. 

Claudia Plattner:
[0:22] Wir machen so etwas, ein sogenanntes Now-Casting. Das heißt, wir machen ein Website-Scraping von Supermärkten europaweit und gucken, wie die Preise sich dort entwickeln. 
So, das ist jetzt kein super abgestimmtes Dataset, wo man über jede Nuance und die exakte Spezifikation jetzt wirklich in Detail diskutiert hat. 
Nichtsdestotrotz liefert es einen Eindruck, ach, guck mal, da könnte gerade sich was entwickeln, worum wir uns wirklich kümmern sollten. 
Das ist, glaube ich, jetzt an dieser Stelle lapidar gesagt, aber es ist ein Riesenthema für ganz, ganz, ganz viele Menschen. Wir haben im Moment ein Thema. 
Und dann braucht man Indikatoren, die im Zweifelsfall eben halt nicht, ich sage mal, mit so und so vielen Tagen Rückblick auf irgendwas draufschauen, sondern im Zweifelsfall auch ganz, ganz schnell, tagesaktuell, in near time, wie auch immer, sehr schnell sehen, was eigentlich gerade los ist. Ich nenne das immer die Thermometer in der Welt. 

Mel:
[1:13] Genau, das war im Interview mit Management by Projects Claudia Plattner, die Generaldirektorin für Information Systems der Europäischen Zentralbank. 
Folge erscheint dann in den nächsten zwei Wochen. 
Könnt ihr euch dann auf diesem diesem Feed oder auf unserem regulären Interview-Feed anhören. 
So, die heutige Folge dreht sich um das Thema, was anfängt, wenn das Requirements Engineering aufhört. Und Fabian, du hast auch noch ein paar einleitende Worte dazu. 

Fabian:
[1:39] Ja, sehr gerne. Also wir möchten heute über Architektur oder vielleicht im speziellen Software-Architektur sprechen. 
Ich gehe davon aus, dass einige von euch, die in der Zuhörerschaft sind wie Melvin und ich technische Projekte leiten. 
Vielleicht nicht ganz so ein Thema, wenn du Marketingprojekte leitest, aber auch da kommt man manchmal früher, wie man denkt, wieder zu Software-Fragestellungen oder Systemdesign und so weiter und wir wollen heute so aus einer Projektleiter-Perspektive über Softwarearchitektur oder Architekturthemen im Generellen sprechen. 

Erfahrungen und Herausforderungen in technischen Projekten

[2:20] Ja, Melvin, hast du zu diesem Thema… Was sind da so deine Erfahrungen? 

Mel:
[2:25] Ich habe eine ganze Reihe Erfahrungen gemacht in verschiedenen technischen Projekten zur Frage, wie baut man natürlich Systeme, also System Engineering, aber auch zur Frage, wie macht man eigentlich Architekturmanagement. 
Tatsächlich das erste größere Projekt, in dem ich in verantwortender Position war, war ein Software-Architekturprojekt, damals noch für Automatisierungssysteme. 

[2:47] Und das Spannende ist eigentlich, diese Projekte laufen eigentlich immer wieder gleich ab. 
Es ist egal, was es für ein technisches System ist. Die spannende Frage ist ja immer, wir bauen technische Systeme als Werkzeug. 
Die sind ja nie zum Selbstzweck da, sondern sie erfüllen oder unterstützen uns bei irgendwelchen Geschäftstätigkeiten. 
Und die erste Frage, die man sich da stellen muss aus einer architektonischen Sicht ist, welche Businessfähigkeiten sind das denn? Also welche Geschäftsfähigkeiten unterstütze ich denn damit? und der englische Fachbegriff dafür ist Business Capability. 
Ist in dem Fall jetzt ein technisch gemeinter Begriff, weil das könnte sowas sein wie, keine Ahnung, sagen wir mal, Tickets drucken und ausstellen oder Personen verifizieren. 
Wenn ich jetzt so an meine Branche des Eventmanagements zurückdenke, also wirklich die Frage, wie kann ich quasi Tickets verkaufen und dann nachher sicherstellen, dass derjenige, der mit einem Ticket vor mir steht, auch tatsächlich nur einmal Zugang gewährt hat. 
Und das ist in der Regel schon mal eine intellektuell sehr fordernde Fragestellung, weil viele wissen natürlich, was die Unternehmung tut und meistens auch sehr gut, wie sie das tut. 
Aber diese Frage, warum, man könnte jetzt auch Simon Zinek zitieren, die Frage, warum machen wir das eigentlich, was ist der Zweck im Sinne unseres Unternehmens, das ist so die erste Fragestellung, der man sich da widmen muss. 

Fabian:
[4:07] Ich resoniere da sehr stark. Wir beide haben auch eine Geschichte, schon länger in grösseren Unternehmen unterwegs zu sein. 
Da ist es ja beeindruckend, wenn das noch ein bisschen… Also grössere Unternehmen heissen in der Regel auch älter. 
Wenn du da irgendwie mal in ein Architekturbild reingeschaut hast, insbesondere auch IT-orientiert, Da sind mir so Dinge total eingefahren von Anfang an. 
Erstens mal, es ist ein unglaublicher Dschungel, also es gibt unglaubliche Mengen Legacy-Systemen. 

Herausforderungen im IT-Systemdesign und Business Capabilities

[4:40] Kleine Klammer auf, ich glaube Unternehmen sind inzwischen schon ein bisschen besser in IT-Systemdesign, aber ich glaube historisch hast du überall einen unglaublichen Dschungel. 
Einerseits. Andererseits, gerade das was du beschreibst, ich weiss nicht ob ich das hier im Blog schon mal erwähnt habe, ich habe mal eine Masterarbeit zu Business Capabilities geschrieben, also ohne nachher Architektur machen zu müssen, aber einfach bin da extrem anschlussfähig und glaube, es ist auch eine sehr sinnvolle Tätigkeit, über Capabilis nachzudenken als Unternehmen, weil es eben auf der strategischen Ebene ist. 
Gleichzeitig beobachte ich… 
Zumindest in meinem Umfeld, dass das überhaupt keine geläufige Sprache ist, dass das etwas ist, was selten wirklich im Sinne des Zwecks des Ganzen praktizierbar ist. 
Also sind diese zwei Dinge, sind ja auch schon mehrmals begegnet, diese unglaubliche Dschungel, der eigentlich niemand so wirklich durchdringt. 
Und einerseits dieser Disconnect zwischen, was muss ich wirklich können als Unternehmen, Welche Capabilities muss ich wirklich haben? Und dann Architektur. 

Mel:
[5:46] Klar, weil es natürlich auch die Managementfrage berührt, Effizienz versus Effektivität. 
Also gerade Unternehmen, die schon länger am Markt sind, die schon älter sind, die haben natürlich vor allen Dingen das Thema Effizienz im Blick. 
Wir optimieren das, was wir tun und fragen sich immer weniger, ob das, was sie tun, eigentlich überhaupt noch state of the art ist. 
Von daher, das wundert mich überhaupt nicht, dass diese Feststellung, Dass du die immer wieder triffst und das strahlt dann natürlich auch auf technische Systeme an, weil du einfach Funktionen mit dir rumschleppst, die brauchst du seit keine Ahnung wie lange nicht mehr. 

Wichtigkeit von architektonischen Themen und sauberen Schnittstellen

[6:20] Und hast sie aber einfach immer noch im System und wenn du jemanden fragst, warum, dann kann dir das gar keiner sagen und du kannst sie auch gar nicht so ohne weiteres eliminieren, weil du dir nie so ganz sicher bist, ob da nicht doch an einer anderen Stelle irgendwas zusammenbricht. 

[6:34] Und gerade deshalb ist es ja so wichtig, gerade bei neuen Systemen über architektonische Themen nachzudenken, weil dieses, wie schneide ich eigentlich nachher Applikationen oder meine, in der Architektur nennt man das dann die Building Blocks, also die Themen, wo ich dann einzelne Fragmente zusammenbaue und sage, das wird jetzt eine Applikation, wie schneide ich die wirklich so, dass die, der technische Begriff ist dann rückwirkungsfrei. 
Also wie kann ich sicherstellen, dass die über saubere Schnittstellen miteinander verbunden sind und wenn ich den einen Teil vom anderen trenne und zum Beispiel durch eine andere Applikation mit der gleichen Funktion ersetze, dass die dann trotzdem noch miteinander funktionieren, ohne dass ich die andere Seite auch anfassen muss. 
Und das ist ja gerade ein Elend, was sich in diesen gewachsenen, monolithischen IT- oder technischen Systemen der 80er, 90er und frühen 2000er, On Mass finde, dass ich nie weiss, welche Rückwirkung hat das auf den Rest meiner Systemlandschaft. 

Fabian:
[7:30] Wie hast du dich damals da bewegt? Oder als Projektleiter, da nehme ich mal alle, die sich so identifizieren, das ist ein moderner Wort dafür. 

Mel:
[7:40] Oh Gott. 

Fabian:
[7:41] Oh mein Gott. In die Sippenhaft und sage, als Vorerkleider möchtest du ja Wirkung haben. 
Also du bist tendenziell eher auf der Effektivitätsseite, wie auf der Effizienzseite zu Hause im Selbstbild und in dem was du tun willst, du willst Dinge tun, die einen effektiven Impact haben, im positiven Sinn für das Unternehmen und für die Menschen im Unternehmen und genau in dieser Fragestellung, wenn du jetzt eben in technischen Themen unterwegs bist, ja da entscheidet sich ja, wie effektiv du dann überhaupt sein kannst. 
Also wenn du dann verdammt bist, irgendwo einem Ding, das auf der grundsätzlichen Ebene noch nicht ganz in die richtige Richtung arbeitet, dann ein Teilaspekt zu optimieren, dann bist du eben verdammt nicht so wirklich auf diese Stufe zu kommen, der Effektivität. 

Der Kampf als Projektleiter in der Architektur

[8:37] Deshalb vielleicht eine kleine Bemerkung, wenn ich mich mit dem Thema zu tun hatte, war das immer einer der Kämpfe, die ich automatisch das Gefühl habe, da hast du immer dabei als Projektleiter. 
Du kämpfst immer darum, auch in der Architektur am richtigen, wenn man so will, arbeiten zu können. 
War das bei dir auch so und wie bist du mit dem umgegangen? Weil das ist, Das ist ein ziemlich kritisches Thema. 
Das sind nicht mal mehr Wildmühlen, ich nenne das Fabriken. 
Die Autofabrik baut Autos und eigentlich sollten sie Velos bauen, aber solange du Autofabrik gebaut hast, wird sie Autos bauen. 
Wie bist du mit dem umgegangen? Hast du das selber erlebt? 

Umgang mit dezentraler Organisation und ITIL-Standard

Mel:
[9:23] Tatsächlich in dem ersten Projekt, das ich eben schon angerissen habe, da hatte ich glücklicherweise noch direkt den Bereich Operations, also Betriebsführung bei mir, Mit der Frage, wie gehen wir denn mit unserer bestehenden dezentralen Organisation um? 
Und dann kriegt ihr jetzt auch noch ein neues Tool. Vorher hatten wir da so eine coole selbstgestrickte Applikation, die irgendwie ihren Dienst getan hat. 
Aber jetzt wollen wir auch noch irgendwie Standard nach ITIL, also nach diesem Betriebsführungsstandard IT Infrastructure Library machen. 
Und das war natürlich für alle erstmal total geil, dass wir genau das machen wollten. Die Leute haben gejubelt und nur darauf gewartet, dass man endlich mal ihre gewohnte Praxis von links nach rechts dreht. 
Aber genau deshalb ist es so wichtig, mit diesen Business Capabilities anzufragen und sich erst mal zu überlegen, was möchte ich denn jetzt hier eigentlich machen, weil darüber holst du das Management. 
Also wenn du dann tatsächlich sagst, hey Freunde, unser Business sieht doch so und so aus und damit wir die und die Geschäftsfähigkeit umsetzen können, benötigen wir bestimmte Business Functions, also müssen wir bestimmte Funktionalitäten erfüllen können und die sind auch erstmal technisch neutral. 
Also auch da wieder mein Beispiel von vorhin, wenn du sagst, ich habe Ticketkontrolle bei einem Konzert als Fähigkeit, die ich irgendwie als Unternehmen besitzen muss, dann ist es ja erstmal egal, ob ich jetzt quasi sage, ich mache eine Sichtprüfung über einen Menschen oder ich mache einen Scan eines QR-Codes. 

[10:43] Das ist aus der Geschäftssicht erstmal völlig irrelevant, sondern es ist eine technische Umsetzung und sich dann zu überlegen, wie viele dieser Funktionalitäten oder dieser Business Functions habe ich denn jetzt eigentlich, welche Fähigkeiten werden dadurch unterstützt und wie bündel ich die dann überhaupt sinnvoll zu technischen Lösungen. 

Zusammenführung von Themen für Konzept und Architektur

[11:07] Weil vielleicht habe ich irgendwie in meinem Geschäftszweck ganz viele Tätigkeiten, die irgendwie damit zu tun haben, dass ich irgendwas einscannen, lesen, kontrollieren muss. 
Und dann macht es ja irgendwie Sinn, eine Applikation zu bauen, die dann irgendwie lesen und kontrollieren kann, als zu sagen irgendwie, ah nee, jetzt brauche ich irgendwie ein Lesesystem für, sagen wir mal, für Eintrittskarten für Konzerte und eins für Zoo-Tickets und eins für Bus-Tickets und eins für Schwimmbad-Tickets. 

[11:35] Sondern so, ne, wenn das dein Business ist irgendwie, dann bau doch eine Applikation. 
Und ich glaube, dass es wirklich, bevor du anfängst, auch groß mit Stakeholdern auf der operativen Ebene zu reden, ist es enorm von Vorteil hinzugehen und zu sagen, guck mal, liebes Management, euer Business funktioniert so, da sind wir uns schon mal einig. 
Dafür müssen wir folgende Dinge können, da sind wir uns, glaube ich, auch einig. Folgende Themen sind ungefähr ähnlich und deshalb möchten wir die jetzt irgendwie mal zusammen bringen. 
Und wenn du das geschafft hast, dann bist du schon den halben Weg deines Konzepts gegangen, weil dann hast du den Rohbau mal geschafft und wie du es dann umsetzt und wie du das dann genau machst und mit welcher Technologie und Blockchain und so weiter. 
Das ist in dem Moment gar nicht relevant, aber das sind die Themen, mit denen du dich nachher mit den operativen Kollegen streitest. 
Die sagen dir nämlich dann auch, ja natürlich müssen wir irgendwie das Eintrittsticket kontrollieren können. 
Die haben aber einfach eine Vorstellung, wie das dann im Detail funktioniert, aber das ist an der Stelle der Architektur noch gar nicht wichtig. 

Fabian:
[12:32] Ich kann dem total folgen und ich habe so eine These, die ich da mit dir testen möchte. 
Es gibt ja so grosse Wörter wie Unternehmenskultur und so weiter. 
Und die These oder die Behauptung, die ich habe, ist, es gibt Unternehmen, die… Es gibt unterschiedliche Gewöhnungen, einfach faktisch, durch wie stark hat sich der Markt verändert, wie stark muss sich ein Unternehmens verändern. 
Auf der grossen Ebene ist es das Geschäftsmodell und auf der kleinen Ebene sind es dann die Capabilities. 
Weil wenn sich der Markt verändert, ich andere Technologien anbieten muss, etc. 
Oder mich digitalisieren muss, dann brauche ich andere Business Functions und Capabilities. 

Unternehmenskultur und Anpassung an Marktveränderungen

[13:14] Ich behaupte, da gibt es wie eine Gewöhnung. Es gibt Unternehmen, die erleben, dass sich innerhalb von wenigen Jahren alles auf den Kopf stellt. 
Ich glaube, das hat eine gewisse, in dem Fall positive, Unternehmenskultur zur Folge. 
Es gibt Unternehmen, die Phasen von extremer Stabilität erlebt haben. 
Natürlich, Schritt für Schritt kommt mehr IT rein. 
Diese Erfahrung haben logischerweise die meisten Unternehmen. Ich habe die These, dass wenn ein Unternehmen nicht die Geschichte hat, dass sie sich zum Teil radikal auf Marktveränderung neuer Geschäftsmodelle einstellen müssen, dass man dann einfach nicht gewöhnt ist. 
Mit solchen Unternehmen würde ich jetzt erwarten, dass es diese Capability-Diskussion gar nicht so wirklich gibt, weil die Fabrik hat schon immer Autos gemacht und sie macht weiterhin Autos, oder? 
Und es gab historisch ganz selten nur den Moment, ja vielleicht musst du mal andere Blinklichter anmachen und eine andere Farbe, das Chassis hat sich ein bisschen verändert, aber es wurden nie fundamentell ganz neue Fähigkeiten nötig. 

Veränderung in unterschiedlichen Umfeldern und Erfahrungen

[14:22] Um dann noch die These abzuschliessen, ich behaupte, dass man das wie gut spüren muss. Also wie viel Veränderung bringt das, was ich tun muss überhaupt? 
Und ich glaube, wenn man da mit dem Umfeld zu tun hat, dass diese Veränderung gar nicht gewöhnt ist, da braucht es anderes Vorgehen, als wenn es logischerweise ein Umfeld ist, das das schon viermal gemacht hat in den letzten fünf Jahren. 
Hast du da unterschiedliche Erfahrungen, die die These stärken oder widerlegen? 

Mel:
[14:52] Ich würde anders darauf antworten. Wir sprechen ja von technischen Systemen und Systeme bestehen aus Subsystemen und Subsysteme haben einen Lifecycle, der sich von dem übergeordneten System einfach unterscheiden kann. 
Und die Fragestellung ist ja quasi, wie häufig muss oder wie stark variieren die Lifecycle der Subsysteme untereinander. 
Weil die machen ja nachher, die determinieren die Frage, wie oft muss ich jetzt quasi Teile tauschen, irgendwie neue Blinklichter irgendwie reinbauen und so weiter. 
Und wie oft tausche ich tatsächlich das System als solches aus. 
Du hast das Beispiel der Automobilindustrie gebracht, selbst wenn wir uns die jetzt angucken, die brauchen nach wie vor Fließbänder und die brauchen nach wie vor Reifen und eine Reifenfertigung und eine Montage und so weiter. 
Was die aber vielleicht nicht mehr brauchen, in hoffentlich sehr balter Zukunft, ist irgendwie den Teil des Subsystems, der Verbrennermotoren erzeugt. 
Und den wollen wir ja austauschen durch irgendwie erneuerbare Energien und Elektromobilität und ähnliches. 
Und das ist eigentlich ein total schönes Beispiel, weil du tauscht eben die Funktionalität und du möchtest, dass das Fließband und die Montage und alles andere soll ja möglichst stabil weiterlaufen. 
Du willst ja nicht den Monteur am Fließband umschulen müssen, nur weil er jetzt auf einmal eine andere Montagetätigkeit macht, also stark vereinfacht. 

[16:08] Aber genau darum geht es ja. Und wenn ich ein System baue, wie groß auch immer das ist, das muss ja nicht eine komplette Fertigung sein. auch wirklich eine kleine IT-Applikation sein. 
Aber sich da zu überlegen, was sind die Teile, die ich wahrscheinlich häufiger austauschen muss und die zu trennen von Themen, die ich. 

[16:25] Eher stabil sind, das ist eine ganz entscheidende Übung und was einem dabei natürlich hilft, sind diese nicht funktionalen Anforderungen, wo ich mir für jede Function vielleicht auch dann schon überlege, okay, was gibt es eigentlich an Anforderungen an dieses Ding und da kann es zum Beispiel sein, dass du sagst, keine Ahnung, der Lebenszyklus dieser Funktion muss an den Lebenszyklus einer anderen Funktion gekoppelt sein, weil die irgendwie, keine Ahnung, Verbrennermotoren und Benzinproduktion gehört irgendwie zusammen. 

Übertragung des Denkens auf Organisationen und Architekturdiskussionen

[16:52] Oder du sagst halt eben, muss ganz bewusst entkoppelt sein von irgendwas anderem, also du hast auf der funktionalen Ebene, und witzigerweise Organisationen sind ja genau so gebaut, dass man sagt irgendwie, ich habe eine Finanzabteilung, ich habe eine Projektorganisation, ich habe ein Marketing, und die funktionieren erstmal unabhängig voneinander und ich kann theoretisch hingehen und, keine Ahnung, das Marketing outsourcen, ohne dass das jetzt Einfluss auf mein Controlling oder meine Projektorganisation hat. 
Und genau diesen gleichen Gedanken überträgt man ja in der Architekturdiskussion auf das technische System und sich da wirklich zu überlegen, was muss ich denn bündeln, was ist irgendwie ähnlich, wo habe ich Skaleffekte und wo möchte ich auch wirklich eine Sollbruchstelle zu anderen Tätigkeiten oder Funktionalitäten meines Systems haben, damit ich die unabhängig voneinander austauschen kann. 

Fabian:
[17:42] Vielen Dank für die sehr schlüssige Antwort. Wie bist du dann im Projektkontext damit umgegangen, dass du dann auch immer die Systemwächter und die – also du hast, ich weiss nicht, jeder hat sicher schon mal von Architekturbots und solchen Geschichten gehört. 
Du hast – die können gut sein, nicht, würde ich jetzt sagen, die These mal in den Raum stellen. 
Prinzipiell haben sie wahrscheinlich trotzdem die Tendenz, den Status quo eher zu vertreten. Wie bist du damit umgegangen? 
Weil du gehst ja dann auf eine strategische Ebene und musst die bestehende Organisation challengen. 

Mel:
[18:20] Vielleicht zwei Sachen. Das eine, wie haben wir es damals gemacht, wir haben damals, Das wird jetzt super peinlich. Wir haben damals ein agiles Projektsetup gewählt und haben halt tatsächlich… Kann schon mal gut sein. 
Genau, war an der Stelle auch genau richtig, weil halt war irgendwie bestehende Organisation, war schwierig, was wir eigentlich wollen, veränderndes Marktumfeld, noch nie irgendwie wirklich entwickelt, sondern immer vom Dienstleister eingekauft. 
Also war schwierig an der Stelle und da sind wir halt tatsächlich hingegangen und wir haben ein Projektteam gebildet aus Fachexperten zusammen mit externen Beratungen, die haben wir weggeschlossen und die haben dann quasi mal diese komplette funktionale Architektur von der Capability über die Functions, über die Building Blocks, die Schnittstellen zwischen den Building Blocks und so weiter haben die hergeleitet und haben das dann quasi dem Management präsentiert und danach gab es für die verschiedenen Building Blocks jeweils zuständige Projekte, die die Aufgabe hatten, die dann umzusetzen und Und auch da haben wir dann quasi agil weitergearbeitet, immer entwickelt, Reviews gemacht, die Linienorganisationen darüber beiziehen. 

[19:23] Und das hat den Umständen entsprechend, glaube ich, relativ gut funktioniert. 
Was ich anders machen würde zukünftig ist, oder was ich jetzt so im Nachhinein, das ist auch schon zehn Jahre her, dass wir das gemacht haben, Was ich nie wieder so machen würde ist Experten wegschließen lassen und sagen ihr baut jetzt mal ein neues System, sondern also was da ja quasi rausgekommen ist, dass die Experten sich selbst verwirklicht haben und ein System gemalt haben, wie sie es irgendwie gerne hätten, unabhängig der Frage brauchen wir das jetzt eigentlich, ist es jetzt irgendwie genau das und wir haben an vielen Stellen, behaupte ich jetzt einfach, haben wir Dinge gebaut, die waren genau so und es war einfach more of the same, nur halt irgendwie alter weine neuen Schläuchen. 
Was ich zukünftig anders machen würde, ist, wenn ich schon eine Anforderungserhebung mit den Stakeholdern mache und irgendwie meine Anforderungen beisammen habe, dann wirklich ganz dediziert mir einen externen Partner zu suchen, der möglichst weit weg ist von der fachlichen Thematik und einfach nur auf Basis der Requirements, die ich da bekommen habe, würde ich mir eine Architektur bauen lassen als Version 0. 
Und du kannst dann ja immer noch hingehen und sagen, jetzt optimiere ich und jetzt bringe ich mein Fach-Know-How ein, aber du hast einfach ein Bias, wenn du Fachexperte bist. 
Du hast eine Vorstellung, wie das System aussehen soll, du hast einfach diese Verzerrung, du hast bestimmte Effekte, die du irgendwie zusätzlich noch reinbringst. 
Du interpretierst vielleicht auch bestimmte Stakeholder-Anforderungen, so wie du es halt eben gerne interpretieren möchtest. 

Wichtigkeit der Qualitätssicherung und Vermeidung von Fehlinvestitionen

[20:51] Deshalb diese Basis-Version mal mit jemandem zu machen, der keine Ahnung davon hat, was es ist, sondern nur, das ist das, was ich verstanden habe, das ist das, was die mir erzählt haben. Und so sollte das System dann nachher aussehen. 
Das halte ich im Sinne der Qualitätssicherung und im Sinne der Vermeidung von Fehlinvestitionen für eine total wichtige. 

[21:09] Ja, Maßnahme, die wir damals nicht gemacht haben und wie gesagt, ich bin fest davon überzeugt, man hätte das signifikant schlanker und einfacher hinbekommen, wenn man einfach ehrlich gewesen wäre und gesagt hätte, es geht nicht darum, dass unsere Experten jetzt ein System designen, sondern es geht darum, das, was als Anforderung vom Markt tatsächlich da ist, vernünftig umzusetzen. 
Und dann kommen ja so Themen wie Time to Market, wie Budget, wie sonst was, Priorisierung, die schlagen dann ja alle mit rein. 
Und wenn du deine Experten fragst, in welcher Reihenfolge priorisieren wir denn jetzt die Anforderungen, die euch selbst ausgedacht hat, dann kriegst du, ohne dass es jemand sagt, in der Reihenfolge, wie sie am meisten Spass machen. 

Fabian:
[21:46] Das ist sehr spannend. Das ist ja so, um nochmal ein bisschen Framing zu machen, Kontext zu geben. 
Du landest beim Brockenmensch immer wieder in diesen Transformationsfragen. 
Es ist dann indirekt auch die Frage, wie bekomme ich dann diese Transformation hin? 
Und da finde ich die These sicher gut zu sagen, du musst auch mal den Aussenblick geben. 
Ich glaube, das ist ein Klassiker. Wenn immer etwas verändert wird, dann ist Benchmark, das ist ja auch eine Art Benchmark vielleicht. 
Und die Frage ist, welche Fische müssen dann diesen Köder fressen? 
Und wie musst du den salzen und zubereiten, dass du da reinkommst? 

Verschiedene Wege, um das Stakeholder-Commitment zu erreichen

[22:32] Und da gibt es sicher viele Wege nach Rom, aber ich denke, ich denke, ich kann dem Argument folgen, dass du da mal einfach Aussenblick, dass der für sich einen Wert hat, den du nachher, den du von ihnen eben nicht bekommst, logischerweise. 

Mel:
[22:48] Ja, und vielleicht noch eine weitere Anmerkung. Es geht natürlich auch um das, was man im Requirements Engineering Traceability nennt, also Nachvollziehbarkeit. 
Und es ist einfach auch im Sinne des Stakeholder-Managements viel einfacher hinzugehen und zu sagen, wir haben hier deine, keine Ahnung, wir haben ein Interview geführt, das und das waren deine Anforderungen, die haben wir irgendwie alle mit einer ID versehen. 
Und jetzt haben wir hier eine technische Architektur, wie unser Zielsystem aussehen soll. Und an jeder Funktionalität haben wir irgendwie die IDs der Anforderungen reingehängt. Du kannst jetzt quasi deine Liste mit deinen Anforderungen nehmen und siehst quasi wo du überall mit erfunden hast. 
Und das macht natürlich ein ganz anderes Stakeholder-Commitment, als wenn du hingehst und sagst so, ja, das haben sich halt irgendwelche Experten ausgedacht und siehst du das genau so? 
Weil darum geht es ja gar nicht. Es geht nicht darum, ob du das genau so siehst, wie das, was jemand anders gemacht hat, sondern aus deinem Input ganz konkret ist das und das herausgekommen. 
Die Art zu argumentieren ist ganz anders und zu kommunizieren, als wenn du sagst, so findest du, dass das, was wir machen, jetzt irgendwie richtig ist, weil da finden sie immer ein Haar in der Suppe. 
Und das ist ja auch nicht deine Aufgabe. Also es geht ja nicht darum, dass du hier auf der grünen Wiese irgendwie was, was irgendwie dir ausdenken sollst. 
Sondern es geht darum, irgendjemand hat ein Bedürfnis, irgendjemand hat ein Need und aus dem sollst du ein technisches System bauen. Das ist dein Auftrag als Projektleiter. Und nicht denk dir irgendwie mal was Geiles aus. 

Auftrag als Projektleiter: Technisches System aus Bedürfnissen aufbauen

Fabian:
[24:05] Das ist ein super Punkt, den Ball, den nehme ich mal auf. Ihr habt sicher auch gemerkt, ich habe gerade Melvin viele Fragen gestellt. Wir haben das schon öfters gesagt, wir wechseln uns da auch ab, je nachdem wer wo mehr Erfahrung hat. 
Und Melvin hat definitiv viel mehr Erfahrung in Architektur, Fragenstellung wie ich. 
Um vielleicht noch so einen Bogen zu machen zu der Rolle als Projektleiter. 
Das, was gerade zuletzt gesagt wurde, das ist etwas, was ich selber versuche, immer wieder zu praktizieren, wo ich manchmal gefragten, auch ungefragten Rat gebe an junge Projektleiter, ist, ich nenne das hypothesenbasiertes Arbeiten. 
Also man holt uns als Projektleiter um. 

Die Arbeit an Chancenthemen zur Manifestation von Möglichkeiten

[24:52] Meistens sind es Chancenthemen, um an Chancenthemen zu arbeiten und die so weit zu entwickeln, dass sie sich als Chance manifestieren können. 

Fehlende dedizierte Rolle in der Organisation

[25:06] Das war vorher auch Thema, was die bestehende Organisation in der Regel nicht kann. Sie hat niemanden, der diese Aufgabe dediziert hat. Es ist nicht, weil die Individuen oder die Abteilungen nicht können, sondern weil niemand die Aufgabe hat, diese Rolle einzunehmen. 
Und das hilft mir immer extrem, zu sagen, ich werde genau für diese Rolle bezahlt. 
Die Aufgabe ist eigentlich, zu sagen, das ist die Hypothese, dorthin sollten wir theoretisch kommen können. 
Und ihr dürft mir jetzt alles sagen, wieso es nicht geschehen wird. 
Ich werde jedes Argument prüfen. Es ist meine Rolle, zu sagen, du hast zwar ein gutes Argument gebracht, aber aus der und der Argumentationsweise her, werden wir weiterhin an der Hypothese festhalten. 
Das, was du gesagt hast, kommt mir sehr verwandt vor. Im Innovationsbereich ist das in Extremis so. 
Dort ist es zum Teil noch so, dass du die Leute zum Teil gescheiter nicht fragst, weil sie du dann komplett überforderst. 
Ich glaube, so Brownfield-Systemdesign mit Brownfield-Aspekten, dort musst du auch fragen. Du kommst nur drum herum. 
Ich glaube, es kann sehr helfen, wenn man sich bewusst wird, niemand anders wird an der Hypothese dranbleiben. 
Also wenn du dich dann nach viermal Nein oder guten Gegenargumenten entmutigen lässt, dann ist dann eben zu Ende. 
Hast du das so auch schon erlebt? 

[26:34] Kannst du dich mit dem identifizieren, mit dieser vielleicht auf der Meta-Ebene beschriebenen Situation? 

Projektarbeit als abhängige Beschäftigung mit klarem Auftrag

Mel:
[26:42] Ja, ich verstehe total, auf was du hinaus willst. Ich würde es dahingehend ergänzen, als Projektleiter bist du ja immer abhängig beschäftigt. 
Also nicht im Sinne deines Arbeitsverhältnisses, sondern du hast ja einen Sponsor. 
Es gibt ja irgendjemanden, der dich beauftragt hat und der gibt dir Geld. 
Und der gibt dir das Geld ja nicht im Sinne von irgendwie, geh mal hin und gründ da mit einem Startup und mach irgendwie was du willst und mach irgendwie deine Idee, Idee, sondern der gibt dir ja Geld mit dem Auftrag irgendwas, was sinnstiftend ist, dann nachher umzusetzen. 

[27:08] Und das wäre meine Empfehlung einfach an der Stelle, sich wirklich da aware zu bleiben. Wir sind hier nicht Daniel-Düsen-Trieb mäßig irgendwelche crazy Erfinder, die jetzt einfach nur irgendwie vor sich hin was entwickeln sollen, sondern die Auftrag, es ist Auftragsfertigung. 
Es gibt einen sehr klaren Auftrag, was am Ende mit dem Geld, was du machen sollst, irgendwie rauskommen soll. 
Und solange wir über Architektur reden, reden wir ja auch nur über Anforderungen. 
Also wir reden ja noch nicht über Stromlaufpläne, über Dioden, über keine Ahnung was, sondern es geht in dem Moment erstmal darum, wir haben ein System, wir haben ein technisches Konstrukt, das eine bestimmte Funktionalität erfüllt und das nachher die Aufgabe bestimmten Anforderungen des Geschäfts Folge zu leisten. Welche auch immer das sind. 
Und alles andere, was damit irgendwie vielleicht in Verbindung stehen kann, ist völlig irrelevant auf der Architekturebene. 
Also wenn du auf der Architekturebene schon sagst irgendwie so und an der und der Stelle setzen wir dann die und die Technologie ein. 
Nein, hat er überhaupt nichts verloren, sondern da geht es erstmal darum, das ist meine Anforderung und du wirst dann nachher aus technischen Gründen an ganz vielen Stellen kommen, wo du sagst, das können wir aber nicht so umsetzen, wie wir das wollten und so weiter. 
Und das sind die Momente, wo man dann in seinen Lenkungskreis rein muss, wo man seine Stakeholder abholen muss. 
Ist es für dich in Ordnung, wenn wir das halt eben anders lösen, als du dir das ursprünglich mal gewünscht hast, weil physikalisch nicht möglich, weil mit ein bisschen weniger irgendwie signifikant günstiger oder oder oder. 

Flexibilität und klare Anforderungen auf Architekturebene

[28:34] Dem muss man sich einfach klar sein, solange wir uns auf der Architekturebene bewegen, ist grundsätzlich erstmal alles möglich und man darf sich da auch erstmal alles wünschen, aber immer im Sinne dessen, was beauftragt ist und das wofür man halt nachher sein Geld bekommen hat, weil das war in dem Projekt, von dem ich vorhin berichtet habe, war das genau auch das Thema, da hast du dir alle möglichen Geschichten irgendwie ausgedacht und gewünscht und gemacht und getan und dann kommt irgendwann jemand rein und sagst du, ja okay geil, ihr habt jetzt irgendwie ein System gebaut, das kann genau das gleiche, was das bisher auch konnte und dafür habt ihr jetzt irgendwie fünf Millionen ausgegeben in zwei Jahren. 
Ja, okay, sorry, das war tatsächlich einfach schlecht. 

Fabian:
[29:11] Ja, und ich glaube, hier den richtigen Mix zu finden, das ist wirklich Kunst. 
Und oft ist es ja, also was ich dann gleichzeitig da auch oft erlebt habe, ist, die Leute brauchen manchmal auch ein bisschen Zeit. 
Also ich rede jetzt vor allem über den Prozess, du hast mal das theoretisch aufgestellt und jetzt versuchst du in ein, zwei Schritte weiter zu kommen. 
Das durch die bestehenden Experten zu challengen und so weiter. 
Und da habe ich oft erlebt, wenn du dann in Gesprächen bist, am am Anfang. 
Gibt es eine gute Portion Ablehnung, viel Skepsis, und dann hast du irgendwie geschafft, dass jemand mal beginnt zu denken, 15 Minuten, und auf einmal ist der Blick zum Teil 180 Prozent gedreht, weil er den gedanklichen Vorgang gemacht hat, okay, wenn ich auf die Effektivitätsebene gehe, wenn ich in fünf Jahren denke, ja, dann sollte man das wahrscheinlich so tun, wie ihr es jetzt hier beginnt vorzuschlagen. 

Design-Annahmen für die Zukunft treffen, aber offen bleiben

Mel:
[30:14] Das kommt auf jeden Fall auch noch hinzu. Also du hast ganz oft bei diesen architektonischen Diskussionen, dass dir irgendeiner um die Ecke kommt und sagt, das geht nicht wegen Technik und dann sagst du so, ja, aber mein Projekt hat ja eine Laufzeit von mehreren Jahren und wenn ich mir angucke, mit welcher Geschwindigkeit sich Technik entwickelt, dann muss ich heute davon ausgehen. 
Also wenn du heute noch eine, keine Ahnung, du machst eine Internetapplikation und jemand sagt dir irgendwie so, ja, aber in Hintertupfingen gibt es ja keinen Mobilfunk, deshalb wird es da nicht funktionieren, dann musst du sagen, ja, sorry, ich kann nicht davon ausgehen, dass es in fünf Jahren immer noch Mobilfunklücken gibt. 
Also ich setze mir hier gleich einen Merker in den Kalender und in fünf Jahren gucken wir nochmal, ob es die weißen Flecken immer noch gibt. 
Aber vom Prinzip als Systemdesigner kannst du doch darauf keine Rücksicht nehmen. 
Und das ist auch so eine Architekturthematik, die wir bei Behörden zum Beispiel ganz oft sehen. 
Das ist diese Diskussion mit, ja, aber was machen wir denn mit den Leuten, die kein Handy haben. 
Ja sorry, also spätestens in zehn Jahren gibt es keine Menschen mehr, die kein Mobilgerät haben und die, die dann noch da sind, die sind alle damit aufgewachsen, dass es diese Dinger gibt. 
Also das ist ein vorgeschobenes Argument, das jetzt für den Moment wahrscheinlich noch valide ist, aber wenn ich sage, ich habe jetzt eh fünf Jahre Entwicklungszeit, bis hier was dabei rauskommt, dann ey, alles cool, bis dahin ist das einfach unsere Prämisse, unter der wir diese Architektur designen. 
Und dann kannst du in fünf Jahren immer noch überlegen, wenn du dann releast, ja okay, wir bräuchten jetzt vielleicht doch noch ein Workaround, weil unsere Prämisse nicht valide war und es irgendwie doch noch ein Drittel der Bevölkerung gibt, das noch kein Mobiltelefon hat. 

[31:41] Ja, das sind halt einfach diese Design-Annahmen, die du irgendwann mal treffen musst und wo du dann einfach sagen musst, ja, okay, dann gibt es halt nachher noch einen Workaround, aber das muss ich ja heute nicht festlegen, sondern das ist, was du vorhin gesagt hast, das ist meine Hypothese, das ist jetzt einfach so und wenn es dann hart auf hart kommt, dann überlege ich mir in dem Moment, wie ich damit umgehe. 

Investitionsentscheid-Momente und das Glück der Arbeit

Fabian:
[32:01] Die Investitionsentscheid-Momente kommen ja dann automatisch, oder? Und ich glaube, da wirst du dann am Schluss sehen, wie viel Glück du hattest und wie gut deine Arbeit war. 
Wenn du von beidem genug hattest, dann fällt dann irgendwann ein Investitionsentscheid, der sagt, das machen wir jetzt richtig, oder? Also, ich habe das richtig angedacht. 
Um da noch vielleicht zum Abschluss einen ganz grossen Bogen zu machen, Solche Fragestellungen sind, glaube ich, für mich am Kern für ein Unternehmen. 
Die sind artverwandt, also von den kleinsten Entscheidungen. 
Es ist eigentlich die Frage, wie viel Zukunft mache ich zu welchem Zeitpunkt? 
Das ist die ultimative unternehmerische Fragestellung, weil du kannst beides. 
Du kannst zu viel Zukunft machen und zu wenig. Es gibt für alles tausend Beispiele. 
Early Mover Advantage, Early Mover Disadvantage, es gibt für alles. 
BCG und Co. haben für alles irgendein Modell entwickelt. 

Architekturdiskussionen und die Relevanz der Zukunftsarchitektur

[33:04] Deshalb, ich denke tendenziell gilt es als fancy und cool, auf den Zukunftsfragen zu arbeiten, aber es kann eben auch genau der falsche Moment sein. Das ist eben auch so. 
Und deshalb sind diese Architekturdiskussionen so relevant Und ich glaube, sie werden auch immer wieder geführt, weil ein halbes Jahr später kann eben die Situation wieder anders aussehen und meine Erfahrung ist da, problematisch wird es vor allem dann, wenn man die Fähigkeit verliert, wirklich über Zukunftsarchitektur überhaupt zu diskutieren. kann auch mal passieren. 
Also unabhängig von was es formal für Aufgaben gibt und so weiter, kann es natürlich auch in eine Situation kommen, wo diese Diskussion gar nicht mehr stattfindet oder einseitig wird. 

Mel:
[33:54] Das ist so, das ist so. Alright, ich glaube mit Blick auf die Uhr haben wir es für heute auch wieder geschafft. 
Danke euch fürs Durchhalten und Zuhören. Wir hören uns dann wieder in zwei Wochen mit der regulären Folge und wenn es gut läuft schon nächste Woche mit der Sonderfolge Insights aus der EZB. Bis dahin, alles Gute euch und bis bald. 

Fabian:
[34:15] Dankeschön, macht’s gut.