Episode 234 Architektur zum Anfassen – Systeme visuell erklärt, Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich Dir Tipps und Impulse, damit Du Dein Projekt zum Erfolg führen kannst.
So wirst du in der heutigen Episode erfahren, warum es Sinn ergibt, komplexe Software-Projekte zu strukturieren und wie Visualisierung allen Beteiligten hilft, zu verstehen, was zu tun ist. Music. Bevor wir einsteigen in das Thema der heutigen Episode, habe ich aber noch zwei Ankündigungen für dich. Und zwar geht es bei beiden Ankündigungen um eine Präsenzveranstaltung, um jeweils ein Barcamp. Zum einen findet am 26.
Juni das Systems Camp OWL in Paderborn statt. Wenn Du Dich für Systems Engineering und interdisziplinären Austausch interessierst, dann solltest Du Dir diesen Termin unbedingt frei halten. Erfahrungsberichte, offene Diskussionen und echtes Community-Feeling. Schau gerne mal auf systemscamp.org vorbei und registrier Dich dort direkt für Dein Ticket. Das Zweite ist auch ein Barcamp, diesmal aber nach den Sommerferien. Am 25.
September trifft sich die RE-Community, also das Requirements Engineering, im Hannover. Das ist ein Barcamp für alle, die Anforderungen besser verstehen, strukturieren und vor allem leben wollen. Offen und praxisnah und mit echtem Tiefgang. Die Infos dazu findest du unter requirementsengineeringcamp.com. Nun aber zum Interview mit meinem Gast aus der Softwarearchitektur. Ich habe wieder einen ganz besonderen Interviewgast bei mir am Mikrofon.
Er hat zweimal studiert oder zwei Abschlüsse gemacht, einmal Diplom Elektroingenieur und danach nochmal Diplom Softwareingenieur. Und er beschäftigt sich heutzutage mit Softwarearchitektur und wir wollen uns heute einmal unterhalten darüber, wie Softwarearchitektur und Systems Engineering sich unterstützen oder gegenseitig ergänzen. Deswegen herzlich willkommen bei mir im Podcast, Matthias Künzi. Hallo Björn, schön, dass ich da sein darf.
Ja, danke, dass du zugesagt hast zum Interview und zu diesem Thema, was ja dir, glaube ich, auch sehr am Herzen liegt. Bevor wir einsteigen, habe ich irgendwas vergessen oder vielleicht willst du noch was zu deiner Person sagen, was du aktuell machst. Damit die Hörer das so ein bisschen einschätzen können, so ein bisschen besser einschätzen können, worüber du gleich mit mir reden wirst. Ja, sehr gerne.
Ja, du hast es erwähnt, angefangen mit einem Elektro-Ingenieur-Studium, dann Zusatzstudium im Softwarebereich. Und mittlerweile sind da natürlich noch weitere Ausbringer dazugekommen, was vielleicht noch relevant ist, werden wir vielleicht auch noch dazukommen. Ich habe dann auch mal noch eine Coaching-Ausbildung gemacht, weil ich gemerkt habe, dass halt nicht immer nur technische Probleme sind in unserem Umfeld, sondern es eben auch um die Menschen geht. Das ist vielleicht noch erwähnenswert.
Und dann hast du gesagt, Software-Architektur, das ist richtig, das ist mein Herzensthema. Mittlerweile versuche ich aber generell einfach Software-Entwicklungen zu unterstützen, einfach da Struktur, Klarheit reinzubringen, ist natürlich ein grosses Thema Architektur.
Mittlerweile aber auch vielfach auch organisatorisch, Also auch Coachings, Mentoring oder eben auch schauen, ob überhaupt die Entwicklungsorganisation überhaupt richtig aufgesetzt ist, um dann eben auch gute und sinnvolle Software-Systeme zu entwickeln. Okay, und wenn du das so betrachtest, dann bist du ja, wenn du das organisatorisch betrachtest, bist du ja eigentlich schon auf einer Systemebene unterwegs, nämlich das Organisationssystem.
Ja, das ist richtig, das ist natürlich so. Ich meine, auch dieser Ansatz, dieses Systemische, dass halt irgendwie viele Dinge miteinander zusammenhängen, Abhängigkeiten haben, sich gegenseitig beeinflussen.
Ich unterscheide da, das ist ein spannendes Thema, oder ich unterscheide da auch so zwischen Komplexität und Kompliziertheit, oder Komplexität dann, wenn halt auch dann Menschen involviert sind, wo es halt dann nicht mehr immer sehr deterministisch zu und her geht und nicht mehr viele Dinge auch gar nicht so einfach nachvollziehbar sind. Und dann aber eben auch auf der anderen Seite diese komplizierten Systeme, technische Systeme, an und für sich sind eigentlich rein kompliziert.
Die haben vielleicht auch sehr viele Elemente, aber mindestens sind die Elemente dann irgendwie gut auch begreifbar und man kann da irgendwie ganze Systeme bauen, aber du hast recht, ich meine, auf Organisationsebene ist dieser menschliche Aspekt auch noch der da reinkommt und das Ganze dann noch etwas komplexer macht. Ja, unser Thema ist einfach heute Softwarearchitektur, Softwareengineering.
Jetzt habe ich natürlich viele Hörer dabei, die sich vielleicht für diesen Podcast interessiert haben, weil die im Systems Engineering unterwegs sind. Was unterscheidet denn das Software Engineering von dem klassischen Systems Engineering? Oder hast du da eventuell auch irgendwelche Parallelen, die du siehst oder die du uns nennen kannst? Ja, das ist eine gute Frage und das ist tatsächlich eine Frage, die höre ich immer mal wieder auch von Kunden.
Wenn wir mit Kunden sprechen und dann sind die da so im Umfeld, wo es nicht nur reine Software-Systeme sind, sondern wo es halt komplexere Systeme sind, die andere Disziplinen involviert haben, nämlich Mechanik, Elektronik, Elektrotechnik und so. Und die Frage dann halt, wo grenzt sich das ab oder was bedeutet jetzt das?
Und ich sehe sehr viele Parallelen. Ich glaube, dieser Ansatz, dass man versucht, systematisch und strukturiert komplexe oder komplizierte Systeme runterzubrechen, aufzuteilen, dann Schnittstellen zu bilden und dann einzelne Elemente da wieder möglichst unabhängig voneinander entwickeln und beherrschen zu können. Ich glaube, das ist bei beiden im Software-Umfeld wie auch im Systems Engineering-Umfeld dasselbe. Also da sehe ich eine sehr klare Parallele.
Ich habe auch von der Architektur-Definition her, da kommen wir vielleicht dann später nochmals, sehe ich das eigentlich genau gleich. Ich mache dann auch zum Teil halt Systeme, die nicht nur mit Software drin haben. Also da gibt es sehr, sehr viele Parallelen. Ich denke, es gibt aber auch ein paar Unterschiede und das sind dann dort, wo vielleicht dann auch manchmal etwas schwierig wird.
Ich meine, Software, wie der Name, so ein bisschen impliziert oder ist soft, ist veränderbar, hat häufig wenig Grenzen, wenige Constraints, wie ich dann sage, Rahmenbedingungen. Natürlich gibt es irgendwie auch die Abgrenzung dann vielleicht zu einem Betriebssystem, zu irgendeinem Abstraktionslayer, wo es dann vielleicht auf eine Hardware, auf eine Box geht, wo die Software drauf läuft.
Aber die Idee ist vermeintlich sehr einfach, man kann das ändern, man muss da nicht so sehr strukturiert vorgehen, weil da lässt sich ja alles wieder umsetzen in der Saft da drin.
Und das sind, glaube ich, so ein bisschen die Dinge, wo es dann unterschiedlich wird und wo dann halt im Systems Engineering vielleicht eher, das ist meine Erfahrung, eher ein bisschen strukturierter gearbeitet wird, wo man dann im Softwareumfeld eher so denkt, man kann ja da mal so ein bisschen agil durchiterieren und verändern und das funktioniert dann schon. Und ich glaube, das ist so ein bisschen dort, wo es dann ein bisschen unterschiedlich wird. aus meiner Erfahrung.
Also du meinst jetzt diese Annahme, dass in der Softwareentwicklung, weil es halt, wie du es gerade sagst, soft ist oder weich ist. Das kann man schnell noch mal ändern. Diese Auffassung, merkst du auch in den Unternehmen, wo du unterwegs bist? Ja, ganz genau. Ich meine, im Systems Engineering ist es, glaube ich, sehr klar und verständlich, es ist wichtig, Elemente aufzutrennen, saubere Schnittstellen zu definieren.
Es kann nicht funktionieren, irgendeine Hardware-Elemente, die können nicht funktionieren, wenn nicht eine klare Schnittstellenbeschreibung ist, wenn die Schnittstellen aufeinander passen. Ganz einfaches Beispiel, ich möchte irgendeinen Stecker, irgendein System anhängen, da ist wie klar, da muss genau definiert sein, wie der Stecker mechanisch aussieht, wie er elektrisch aussieht, wie das irgendwie verbunden werden kann. Das leuchtet jedem ein.
Aber dass es solche Dinge eben auch im Softwareumfeld gibt, dass es eben auch im Software diese Strukturen, diese Unterscheidung von Elementen braucht, die dann miteinander sinnvoll interagieren können. Das ist so für Leute, die nicht so dieses Softwareverständnis vielleicht haben, irgendwie dann ein bisschen schwieriger zu verstehen.
Und das führt dann häufig eben auch zu solchen Aussagen, genau wie du gesagt hast, dann lass uns da mal was ändern, lass uns da anpassen, neue Features reinbringen. Und das kann dann halt einfach sehr schwierig werden. Und ich glaube, dort unterscheiden sich eben so diese beiden Disziplinen etwas. Okay, und deswegen ist es auch oftmals, dass der Softwareteil zu einem Art Sorgenkind in der Systementwicklung wird, oder?
Ja, ganz genau. Oder ich meine, vielleicht kann ich da so eine Erfahrung, eine kleine Geschichte erzählen, die ich so erlebt habe. Da ging es darum, und ich habe ja da in sehr kritischen Umfeldern auch gearbeitet, wir haben Medizingeräte entwickelt, Beatmungsgeräte, also lebenserhaltende Systeme. Und da war ich involviert als Softwareverantwortlicher in so einer kompletten Beatmungsgeräteentwicklung.
Und dann hat das begonnen, da sind irgendwie die Hardware-Entwickler, Mechanik, Gehäuse usw., das hat dann so ein bisschen einen Vorlauf gehabt. Die haben dann versucht, eine Systementwicklung zu machen, Systemarchitektur, Systems Engineering. Und als wir dann vom Software erst einmal involviert waren, dann waren viele Dinge wie schon klar und definiert.
Es war dann so, dass viele Module, Bausteine von der Hardware, von der Elektronik waren dann einfach so sehr einfach mit so einem seriellen Bus, mit so einem I2C, I2C-Bus miteinander verhängt, weil das macht es sehr einfach, auch für die Hardware natürlich. Da kann man verschiedene Module zusammenhängen und so mit der Vorstellung, das ist ja dann auch gar kein Problem, weil das kann ja dann die Software irgendwie regeln, dass das alles irgendwie angesteuert werden kann.
Das Problem war dann, dass tatsächlich irgendwie sehr viele Teilnehmer da drin waren und so i²c, wenn man das ein bisschen genauer versteht, ist so ein Multimaster-Bus, Es ist fähig, auch verschiedene Master zu haben. Es ist nicht so klassisch, einer ist der Master und die anderen sind eher die Slaves, wie man dann sagt. Oder einfach so ein bisschen Client-Server kann man auch ansehen. Sondern es war dann tatsächlich so, dass da Module drauf hatten.
Die auch selbstständig von sich aus irgendwie da versucht haben, ein Bussystem zu übernehmen und da einfach in den Bus reinzusenden und die anderen Teilnehmer mussten dann warten. Und das kann man sich vorstellen, das ist extrem aufwendig, so etwas dann in der Software umzusetzen und das irgendwie sicherzustellen, dass das immer richtig funktioniert. Und das war so eine fixierte Systementscheidung, die da recht früh schon drin war und die uns dann irgendwie, ich weiß nicht.
Wir haben es nicht ab, wir haben es nicht irgendwie eruiert, aber ich denke, wir haben da Monate damit verbracht, auch dieses System dann wirklich zuverlässig zu entwickeln, einfach weil die Systementwicklung da Rahmenbedingungen reingebracht hat in die Software, die sehr schwer umsetzbar waren. Und das ist so ein bisschen das, was man unterschätzt. War das wirklich eine Systementwicklung oder waren das nur Mechanik- und Hardwareentwickler, die ihre Ideen schon eingebracht haben?
Also sprich, du hast gar keine Systementwicklung in dem Sinne gehabt, sondern es wurde auf Ebene der Hardware was entwickelt und du als Softwareentwickler oder du und dein Team, ihr musstet dann darauf reagieren. Das heisst also, es war gar nicht sauber im Vorfeld aufgeteilt worden? Ja, ganz genau.
Ich meine, das ist jetzt sicher, wenn man das sauber nach Systems Engineering-Prinzipien macht, hätte das eigentlich nicht passieren dürfen, weil dann wären diese Entscheide vielleicht dann auch sehr transparent und man hätte sich überlegt, okay, macht das wirklich Sinn? Man löst hier ein Problem und versucht, das einfacher zu machen. Auf der anderen Stelle gibt es dann halt Probleme, das hätte man sicher besser machen können.
Aber ist einfach so vielleicht auch ein gutes Beispiel, um zu sehen, dass eben... Dass eben Software dann häufig so ein bisschen gesehen wird, da kann ja Software sehr flexibel, da kann man ein paar Treiber schreiben, da kann man ein bisschen Software schreiben und dann funktioniert das. Aber das ist dann halt zum Teil irgendwie wirklich sehr aufwendig und sehr schwierig, da auch dann auch wirklich zuverlässige Systeme zu bauen, weil halt dann einfach die ganze Software sehr, sehr komplex wird.
Und das unterschätzt man ein bisschen und wenn dann halt auch noch so ein Mindset drin ist okay man kann da ja diese Features, die können wir dann in Software irgendwie reinbringen und das kann man dann verändern beliebig das macht es halt dann auch nicht einfacher, wenn man dann denkt, da hat man ja eine sehr einfache Möglichkeit das zu skalieren und weiterentwickeln zu machen, das muss dann halt auch von der Struktur her sinnvoll auch. Vorbereitet sein, ja.
Das heißt also, du als Software-Architekt würdest dir wünschen, wenn jemand im Vorfeld schon mal sich Gedanken darüber gemacht hat, hey, wir brauchen diese anderen, Disziplinen auch, also Mechanikentwicklung, Elektronikentwicklung, Softwareentwicklung, das gehört alles irgendwo zusammen und du als, Software-Architekt bekommst dann quasi so diesen Rahmen abgesteckt, Hey, wir erwarten von dir folgende Aufgaben, die gelöst werden müssen.
Und es gibt hier auch noch Schnittstellen zu der Elektronik und da müssen wir uns dann nochmal abgleichen. Also das wäre so ein Wunsch, den du quasi als Softwarearchitekt hättest. Habe ich das so verstanden? Ja, ich glaube, das ist tatsächlich so das, wie es funktionieren sollte. Bei einem Software-Architektur versucht man dann eigentlich auch diese Aufteilung in unterschiedliche Module, in unterschiedliche Komponenten. Ich nenne das dann meist sehr allgemein einfach Architekturelemente.
Das versucht man ja dann auch nicht einfach beliebig zu machen, sondern man versucht dann irgendwie halt basierend auf den Anforderungen, die man hat als System, zu sagen, okay, macht es jetzt irgendwie Sinn da, so verschiedene Layer zu machen oder wollen wir unabhängige Komponenten. Das sind dann so diese Design-Pattern oder Articult-Stile, wie man sie nennt.
Und das sind dann bewusste Entscheidungen, wo man sagt, okay, was soll unser System können, wie soll sich das verhalten, dann soll das eher ein sehr performantes System sein, soll das sehr einfach erweiterbar sein. Und basierend auf dem gibt es dann eben so die sinnvolle oder weniger sinnvolle Architektur.
Und das macht eben auch Sinn, das eben auf Systemebene schon so zu tun und dann ganz bewusst eine Entscheidung zu fällen, okay, welche Funktionalitäten, welche Verantwortung soll da die Software übernehmen, was können wir in Elektronik machen, macht das Sinn, die Schnittstelle dort zu machen, aber da braucht es, wie du richtig gesagt hast, das muss halt dann passieren, wenn nicht schon irgendwelche. Printentwicklungen passiert sind, weil dann ist es dann einfach zu spät.
Genau, dann ist das schon alles in, dann ist meistens schon irgendwie eine Entscheidung getroffen. Und genau, und eine Domäne ist dann halt nicht beachtet worden, zumindest nicht gefragt worden, ob es vielleicht auch andere Möglichkeiten gibt, das zu lösen. Sind das so übliche Missverständnisse, die zwischen den Beteiligten dann auftreten? Also, dass man glaubt, man weiß schon, wie es funktioniert und... Beaufschlagt dann die andere Domäne quasi mit immensen Aufgaben. Ohne das genau zu wissen.
Sind das so Missverständnisse zwischen den Entwicklern? Ja, ich glaube. Die Ursache ist wahrscheinlich da, kann an verschiedenen Stellen sein.
Häufig ist es dann auch so, dass natürlich auch eine Elektronikentwicklung und versucht auch vielleicht Module zu etablieren und irgendwie auch Schaltungen, die schon mal verwendet worden sind oder irgendwie ein Mikrocontroller oder Mikroprozessor-Board, das man schon mal vielleicht in einem System eingesetzt hat, wiederzuverwenden und dann ja, okay, dann sind halt diese Module, die sind, wie sie sind oder vielleicht gibt es dann halt einfach,
was irgendwie so als Peripherie dann sinnvoll angeplagt werden kann und das ist dann irgendwie so, eher so von unten versucht man dann, okay, jetzt habe ich alle Bausteine, die sind irgendwie drin und man überlegt sich dann vielleicht teilweise zu wenig, was das jetzt bedeutet, um die gesamte Systemfunktionalität da irgendwie zu erstellen.
Und ich meine, ich denke, das ist tatsächlich genau diese Systems Engineering Disziplin, die sie eben braucht, dass man halt wirklich von Features, von Funktionalität für das Gesamtsystem beginnt und dann sich überlegt, okay, was sind jetzt sinnvolle Strukturen, die dann eben erlauben, da das Optimum halt einfach rauszuholen und halt nicht irgendwie etwas einfacher zu machen, dafür das andere sehr viel komplizierter. Ja, ja.
Hast du aus deiner Erfahrung irgendwie Tipps, wie man denn diese Probleme umgehen kann? Also diese Missverständnisse zwischen den Bereichen, vielleicht auch ein nicht komplett aufgesetztes Systems Engineering. Wenn da jetzt Menschen das hören hier, die fragen sich doch bestimmt, wie hat der Matthias das gelöst oder wie würde er das lösen?
Ja, das ist eine gute Frage, weil häufig impliziert so Systems Engineering, ich weiss nicht, ob das auch deine Erfahrung ist, aber ich merke immer wieder, so Systems Engineering, das impliziert bei vielen Leuten, da brauchen wir dann Model-Based-Tools und was auch immer, irgendeine sehr komplizierte Infrastruktur, um das zu machen. Ich denke, es braucht... Nicht so viel. Ich glaube, es braucht einfach ein frühes Miteinander definieren. Sich austauschen, sinnvolle gemeinsame Modelle.
Und von Modellen, da braucht es ja nicht unbedingt das saubere Tool.
Es reicht manchmal auch einfach, wenn man da ans Whiteboard, ans Flipchart steht und sagt, okay, hier haben wir das Gesamtsystem, okay, was müssen wir denn tun und wo können wir da sinnvolle Grenzen legen und dann vielleicht ganz bewusst so diese Diskussion führen, welches Element, und ich spreche jetzt da wirklich von so einem Architekturelement, das entweder Hardware, Elektronik oder eben Software sein kann, welches Element soll jetzt welche Funktionalität, welche Verantwortung übernehmen
und dann, glaube ich, dann spricht man ja ganz automatisch über diese Schnittstelle und über diese Auftrennung. Ich glaube, das ist wichtig, dass so diese Klarheit über diese Begriffe, Zuständigkeit und Verantwortung geschieht, dass eine klare, bewusste Auftrennung passiert von diesen Elementen und ich denke, wenn man das irgendwie frühzeitig macht, Ich glaube, dann wird man hier auch nicht in solche Probleme reinlaufen.
Ja, genau. Also diese Aufteilung, wie du es gerade gesagt hast, finde ich auch immer sehr, sehr hilfreich. Und da kann man ja auch schon verschiedene Möglichkeiten aufzeigen. Ich habe immer als erstes Beispiel so eine Analog-Digital-Wandlung von irgendwelchen Signalen. Das kannst du natürlich in der Hardware machen, du kannst sowas aber auch in Software realisieren.
Die Frage ist halt dann immer nur, was ist performanter oder was spart mir halt vielleicht irgendwo nochmal einen zusätzlichen Baustein in meiner Elektronik ein. Das sind andere Fragen, die dann da auch noch geklärt werden müssen. Und je nachdem, was ich haben will, wähle ich dann die eine oder andere Alternative aus.
Ja, ganz genau. Ich meine, du sprichst einen guten Punkt an, den ich vielleicht hier noch erwähnen möchte, und zwar, häufig ist es ja tatsächlich so, dass ja so den Entwicklern schon bewusst ist, dass es unterschiedliche Lösungsmöglichkeiten gibt, oder so wie du gesagt hast, okay, sollen wir jetzt das in Elektronik machen, sollen wir das in Software machen, das sind dann so Beispiele wie eben so eine Wandlung von einem Signal,
oder auch zum Beispiel eine Entbrellung von Signalen, kann man auch in Software machen, kann man in Hardware machen. Ich hatte mal so ein Thema, wo es darum geht, eben so im kritischen Umfeld, ja, wollen wir jetzt einen Hardware-Wortstock haben oder wollen wir das irgendein paar Software überwachen? Das sind dann solche Dinge, wo dann so unterschiedliche Lösungsmöglichkeiten.
Betrachtet werden und wichtig ist eben, und ich glaube, das ist etwas, was ich auch vielfach sehe, dass das nicht gemacht wird, dann versucht man sich zu eigen auf eine Lösung und diskutiert da, aber wichtig ist ja, dass man da ganz nach hoch schaut und sagt, okay, wie soll denn unser System sein, welche Qualitätsanforderungen soll denn unser System irgendwie erfüllen, muss das irgendwie sehr performant sein oder muss das irgendwie sehr erweiterbar sein,
müssen wir da vielleicht, wissen wir noch gar nicht und müssen tatsächlich deshalb vielleicht Dinge in Software reintun, weil wir eben das nicht klar schon definieren können. Das sind dann solche Aspekte, die ganz bewusst basierend auf den Anforderungen, die das ganze System hat, gelöst werden sollten.
Und das vermisse ich vielfach, dass dann zwar über verschiedene Lösungsmöglichkeiten diskutiert wird, aber einfach so ein bisschen dieses Ingenieurs-Mindset, machen wir einfach so, was wir denken, sei die beste Lösung und nicht, was jetzt für Systeme. Für die Skalierbarkeit, die weiterentwickelbare Zukunftsfähigkeit vom System irgendwie sinnvollerweise eigentlich die richtige Lösung wäre. Ja, das stimmt. Das vermisse ich auch manchmal dabei. Sag mal, jetzt bist du ja Softwareentwickler.
Und dann weisst du ja wahrscheinlich auch, dass Software ja oftmals irgendwo nur auf so einem Computer läuft. Oder die ist nur in so einer Box drin. Wenn wir über Embedded Software sprechen, ist es manchmal noch extremer, dass man davon ja gar nichts mitbekommt. Also sie ist nicht greifbar. Also wenn du Hardware entwickelt hast, dann liegt irgendwann mal so eine Platine auf dem Tisch.
Du kannst es zumindest schon mal optisch untersuchen, ob das ein gutes Design ist, ob da gewisse Abstände eingehalten worden sind oder nicht. Also das kann man auch als Laie, könnte man da jetzt schon mal drauf gucken und irgendwie was sehen. Bei Software ist das immer irgendwie ein bisschen schwierig. Und ist das aus deiner Sicht ein Problem, dass man das eventuell nicht sehen kann?
Ja, das ist aus meiner Sicht ist das ein grosses Problem, dass man das wir im Softwareumfeld so ein bisschen diese, diese Greifbarkeit diese Sichtbarkeit nicht haben, das war übrigens der Grund, weshalb ich meine Firma visuell klar getauft habe nicht weil ich eine schöne, ich mache auch Visualisierung ich hoffe, die gefallenen Leuten auch, aber mir geht es tatsächlich darum eben diese Sichtbarkeit sicherzustellen, die eben bei Software nicht einfach per se kommt.
Und das ist, ich glaube, das ist häufig dann auch das Problem, dass vielleicht unter den Softwareentwicklern das noch gar nicht so als Problem angeschaut wird, weil die dann irgendwie versuchen, da auch schon in Code reinzuschauen und sich miteinander unterhalten.
Und dann aber Leute, die vielleicht ein bisschen weiter weg sind, so in vielleicht auch einer anderen Disziplin, wo es um Schnittstellen geht, die da irgendwie denken, okay, das ist tatsächlich für mich so ein bisschen eine Blackbox, ich verstehe da nicht. Und das ist aber etwas, was so ein bisschen meine, wirklich mein Antrieb ist auch hier, das versuchen zu verbessern, weil, und da hat mir mal jemand etwas gesagt in einem Workshop.
Wo ich über Architekturdokumentation gesprochen habe, da sagt mir einer, der übrigens auch auch aus dem Elektronik-Umfeld kam, warum sprecht ihr denn in der Software immer von solchen Dingen, die man nicht so richtig versteht, Design-Dokument, Architektur-Dokument, warum spricht ihr nicht einfach von dem Softwareplan? Und dann habe ich gedacht, ja klar, ich meine, Ein Schema ist ein Plan, wie man die Elektronik baut. Dann gibt es ein Layout.
Das ist auch ein Plan, wie dieser Print gebaut werden soll. Oder die Mechaniker machen auch Pläne. Da kann man sich vorstellen, wie das Ganze wird, bevor man wirklich was tut. Und in der Software sprechen wir dann so ein bisschen von Architektur und Design. Oder hat man so ein bisschen das Gefühl, das hat mit Kunst zu tun.
Und das sind ganz andere Dinge. Aber eigentlich geht es ja auch darum, dass wir in der Software auch saubere Pläne, saubere Konstruktionszeichnungen machen sollten, um eben einerseits die Entwicklung besser im Griff zu haben, andererseits aber besser miteinander kommunizieren zu können, untereinander, aber eben auch vielleicht mit benachbarten Disziplinen. Und das ist tatsächlich etwas, was viele nicht machen oder vielleicht auch nicht genau wissen, wie sie das tun sollen.
Und das ist eine grosse Thematik, ganz genau, ja. Bist du denn dann jetzt hergegangen und hast überlegt, das anders zu nennen? Also sprichst du noch von Architekturdokumenten oder sagst du jetzt, wir haben da einen Softwareplan? Ja, ich versuche tatsächlich so ein bisschen dieses Dokument, so ein Nachrichturdokument, gerade für Leute, die vielleicht da nicht so,
nicht so nahe dran sind. Ich spreche ja viel oder meine direkten Ansprechpartner sind häufig dann auch Führungskräfte, Entscheider in Softwareprojekten, in Softwareentwicklungen und das sind nicht unbedingt immer die, die auch schon jahrelange Software entwickelt haben und da spreche tatsächlich von einer, Softwarestruktur, die dokumentiert werden, einem Konstruktionsplan der Software.
Also ich versuche da auch so ein bisschen andere Begriffe reinzubringen, einfach, dass die Leute verstehen, okay, darum geht es.
Und ich habe eigentlich recht, ich finde das wird recht gut dann auch aufgenommen, weil die Leute dann auch wirklich verstehen und ich sage jedem Entscheider im, Softwareentwicklungsumfeld dann auch, es ist du darfst dich nicht damit abgeben, dass dir die Softwareentwickler sagen, okay, das ist ein bisschen kompliziert und das verstehst du nicht und den Code verstehst du nicht sondern da halt einfach wirklich auch einzufordern und sagen, ja okay,
aber zeig mir es auf dem Whiteboard, zeig mir es auf dem Flipchart, ich möchte ein Diagramm sehen, damit ich verstehen kann, über was du irgendwie sprichst und ich denke, das ist irgendwie wichtig, dass die Leute sich auch getrauen, ein bisschen, Gegenwert zu geben und zu sagen, hey nein, das geht auch in der Software, dass man Dinge erklärt und zeigt und eben greifend begreifbar macht. Das passt ja auch zu deinem Slogan, den du hast, der heisst Durchblick statt Blindflug.
Softwareentwicklung mit Struktur und System. Also, wenn ich das jetzt so verstehe, du willst das nicht nur, dass du einen Plan hast, wie muss die Software gebaut werden, sondern auch Menschen, die nicht unbedingt in der Software tätig sind, sollen trotzdem den Durchblick haben über das System, was da gebaut wird. Und wenn es jetzt in diesem Fall gerade ein Software-System ist, müssen sie natürlich das Software-System verstehen. Ja, ganz genau.
Da geht es ein bisschen in das, was ich vorhin schon erwähnt habe. Häufig ist es ja so, dass es natürlich auch ein bisschen unterschiedliche Leute gibt, die auch unterschiedliche Aufgaben und Rollen haben in so einer Softwareentwicklung. Dann gibt es die Leute, die dann über Termine, Budget, Abhängigkeiten usw., ob man das jetzt Management oder Entscheider oder wie auch immer man das nennt, ob der Produktoner, Teamleiter, was auch immer ist.
Aber das sind ja dann häufig die Leute, die wirklich eigentlich so ein bisschen auch die Möglichkeit haben, auch da wichtige Entscheidungen zu fällen. Und auf der anderen Seite haben wir dann häufig die, unten einen typischen Software-Entwickler, der sehr vertieft in seinem Umfeld drin ist. Die schaffen es dann nicht, miteinander sinnvoll zu kommunizieren, weil dieser Software ein bisschen als Blackbox aussieht. Es ist ja nicht so, dass in dieser Software-Entwicklung alles sehr gut funktioniert.
Meistens ist das dann aufwendiger als geplant. Dann sind Termine in Gefahr, da sind irgendeine Abhängigkeiten in Gefahr und dann fängt das an, dann ein bisschen Probleme zu verursachen und dann ist es dann meistens so, und das stelle ich immer wieder fest, dass die Leute dann einfach auch nicht miteinander sprechen können und einander gar nicht so richtig verstehen.
Und da eben so diesen Durchblick reinzubringen, dass man es schafft, auch Dinge verständlich zu machen und dann eben auch damit gute Entscheidungen zu fällen, das ist eigentlich genau so, was ich mit meinem Slogan da reinbringen wollte. Und ich glaube, das ist häufig das Problem, dass man dann irgendwo so ein bisschen die Softwareentwicklung ein bisschen auf die Seite stellt und sagt, ja okay.
Scheinbar ist das einfach so, das geht länger, die muss ich jetzt einfach machen lassen, hoffe, dass die mal kommen, meinen Plan können sie mir schon gar nicht mehr sagen, warum auch immer, ich verstehe es nicht. Und das sind dann solche Situationen, die sind dann sehr, sehr schwierig. Ja, die sollte man definitiv in den Griff kriegen. Ich vergleiche auch Systementwicklung und vielleicht auch Softwareentwicklung immer mit dem Hausbau.
Da würdest du ja auch nicht irgendwo einen Laster mit Steinen ankommen lassen und die Steine irgendwo hinschütten und dann sagen, baue mal irgendwas. Sondern da hat man ja auch ganz klar einen Plan, wie man vorgehen will. Und das vermisse ich auch manchmal wirklich bei der Softwareentwicklung, dass das nicht so aufgeteilt werden kann oder so dargestellt werden kann, dass man genau weiß, was muss denn alles getan werden. Ja, ganz genau, ganz genau, ja. Cool. Sag mal, wie ist denn das überhaupt?
Du hast jetzt ja auch eben von Architekturdokumenten und Designdokumenten, du sprichst von Anforderungen und so weiter. Wenn man das jetzt mal mit diesen ganzen Aussagen aus der agilen Szene dann mal korreliert, dann sagen die ja immer, ja, mit Anforderungen brauchen wir nichts, da haben wir nichts am Hut. Wir machen das alles mit User-Stories. Wie siehst du das bei deinen Tätigkeiten in der Softwareentwicklung, Softwarearchitektur? Kannst du mit diesem agilen Mindset irgendwie umgehen?
Nutzt du das selber oder wie stehst du dazu? Ja, das ist auch immer wieder ein Thema. Ich meine, es gibt gerade auch im Architekturumfeld gibt es auch so diese Begriffe, so dieses Big Design Upfront oder B-DUF abgekürzt.
Das bedeutet, man sollte eigentlich nicht am Anfang die ganze Software versuchen zu designen, Upfront, bevor man irgendwas tut, weil das ja dazu führt, dass man dann sehr viel Aufwand am Anfang investiert und man weiss ja dann, es kommt ja dann trotzdem ein bisschen anders und dann muss man diese Strukturen wieder verändern, diese Architektur wieder verändern und das ist so gegen diese Agilität. Das ist zwar richtig, grundsätzlich finde ich diese Agilität eine gute Sache.
Ich unterstütze das auch ich bin auch da in diesem Umfeld gross geworden aber ich denke man muss es auch ein bisschen differenziert betrachten gerade in solchem Umfeld wo wir Systeme bauen dann ist es ja tatsächlich nicht so dass man eigentlich gar nicht weiss was diese Systeme können sollen oder man muss ein bisschen auch die Historie von dieser Agilität anschauen die ist natürlich dort entstanden wo reine Software-Systeme gebaut wurden, wo man versucht hat,
sich zu überlegen, welche Features, welche Anforderungen da reinkommen, hat dann eine sehr lange Software gebaut und dann versucht, das auf den Markt zu schmeissen und hat dann gemerkt, sind wir da an den Kunden anfordernd und eigentlich haben wir vorbei entwickelt. Das ist dieser Impuls, der dann dazu geführt hat, wir müssen sehr viel iterativer, inkrementeller, wir müssen sehr viel schneller etwas zeigen können, wo man dann wieder Feedback einfließen
kann und das System evolutionär entwickelt. Das ist alles richtig. Wenn ich aber jetzt eine Systementwicklung habe, wo ich irgendwie weiss. Welche Funktionalität da bereitstehen muss, wo die Schnittstellen zur Elektronik sind, zur Hardware sind, zu anderen Systemen. Dann irgendwie das zu ignorieren und zu sagen, ich beginne einfach mal zu iterieren und so inkrementell zu entwickeln, das ist dann etwas, das nenne ich dann irgendwie planlos und ich meine, das ist aus meiner Sicht nicht agil.
Das muss man machen, aber dann halt eben irgendwie tatsächlich sich zu überlegen, jetzt gibt es wieder Dinge, da wissen wir noch nicht, da ist tatsächlich etwas, da müssen wir Erfahrung sammeln oder müssen vielleicht mit einem, eingeschränkten Funktionsumfang schon mal irgendwas lauffähiges haben, das macht irgendwie Sinn und das dann eben auch so zu entwickeln agil, das ist durchaus natürlich sinnvoll.
Aber das muss man beachten und ich stelle immer wieder fest, dass irgendeine Leute suchen rein agil zu entwickeln, obwohl sie eigentlich.
Ein Pflichtenheft haben oder zumindest ein Lastenheft haben und eigentlich sehen könnten, was sie entwickeln müssen, aber dann wird einfach so, wir beginnen mal einen Backlog zu füllen mit User Stories und beginnen mal irgendwie zu entwickeln und keine Architektur, keine Strukturen und dann kommt irgendwann ein neues Feature da vom Lastenheft findet dann den Weg ins Backlog und dann denkt man, hätten wir das am Anfang gewusst, hätten wir die Software ein bisschen anders
gebaut und das ist einfach, ein bisschen stupid so vorzugehen Ich bin ja auch da bin ich völlig bei dir erstmal aber ich bin auch der Meinung, dass ja auch, Architekturentwicklung agil laufen kann.
Und das, da bin ich völlig bei dir, aber wenn man das mal da noch mit reinnimmt, du musst dir das Lastenheft oder vielleicht auch ein Pflichtenheft, je nachdem, was da noch alles im Vorfeld schon gelaufen ist, musst du dir heranziehen, da reingucken, was ist denn überhaupt gefordert und dann bin ich der Meinung. Kann man eine Architektur entwerfen.
Sogar für die Architektur könnte ich ja eine User-Story schreiben und sagen, wir brauchen das und das und das und dann das in meinen Sprint mit übernehmen. Und daraus fallen ja dann auch noch weitere User-Stories ab. Also für mich ist dieser Weg, oder verbaue ich mir den Weg nicht, wenn ich einen Lastenheft und einen Pflichtenheft habe. Ich habe dann vielleicht sogar viel besser die Rahmenbedingungen vorgegeben,
in denen ich jetzt agil arbeiten kann. Und wenn ich dann noch so eine Architektur erstellt habe. Dann kann ich ja auch nochmal eine User-Story aufbringen und nochmal wieder reingehen und dieses Arbeitsergebnis verfeinern und überarbeiten. Also es ist ja nicht so, dass die Architektur, so wie du es gesagt hast, von Anfang an das System hundertprozentig beschreibt. Auch da werden ja irgendwie Änderungen dran durchgeführt werden müssen.
Nachher bin ich völlig bei dir, dass das auch mit der Agilität so funktioniert. Ja, ganz genau. Oder ich meine, was sicher heute eher weniger gemacht wird, oder ich meine, ich habe auch schon, also das ist schon ein paar Jahre her, aber da war ich auch in Projekte involviert, wo man sehr, sehr viel Aufwand investiert hat, um möglichst eine vollständige Anforderung in ein System zu kriegen.
Und ich meine, das ist tatsächlich, muss man sich dann überlegen, ist das irgendwie bis zu welchem Grad sinnvoll? Da kann man sich tatsächlich überlegen, muss man das tun? Natürlich, wenn es vielleicht eine Systementwicklung ist, wo man sagt, okay, wir wissen schon, wir haben vielleicht schon Geräte oder Systeme, die sehr ähnlich sind, wir wissen sehr genau, was wir wollen, dann macht das Sinn, das auch aufzuschreiben.
Aber sonst ist es schon so, ich denke, wichtig ist einfach das, was man weiss, dass man das auch berücksichtigt und dann, wie du richtig gesagt hast, dass man dann das als Inter, verwendet, um in so eine Architektur reinzukommen, ob jetzt das auf nur Software-Ebene oder System-Ebene ist, ist aus meiner Sicht genau dasselbe, dass man sagt, okay, das wissen wir, das müssen wir erreichen.
Vielleicht gibt es da noch so ein paar Themen, die sind nicht ganz klar, aber auch das ist wichtig, irgendwie dann so im Hinterkopf zu behalten bei der Architekturentwicklung, dann kann man sich überlegen, okay, was ist jetzt die sinnvollste Architektur mit diesen Anforderungen.
Und wenn dann eben etwas sehr agil ist, im Sinne von man weiss relativ wenig und man geht davon aus, dass sich dieses System irgendwie dann halt so inkrementell weiterentwickelt, solange man mehr Informationen hat, dann ist das eben auch etwas, das muss man unbedingt eben auch in der Architekturentwicklung berücksichtigen. Also das heisst, ob ich ein System baue, das wie ganz klar ist, das ist dieser abgeschlossene.
Funktionsumfang, oder ob ich ein System baue, das mal irgendwie zwei, drei Features hat, aber gedacht ist, um da irgendwie sehr. Zu skalieren und weiterentwickelbar sind, das sind dann diese Qualitätsanforderungen, die sind sehr wichtig, eben in die Architektur mit reinzubringen und dann eben auch eine Architektur zu bauen, die diese Skalierbarkeit und Weiterentwickelbarkeit eben auch zulässt. Oh ja, das ist wunderbar, dass du das gesagt hast. Entschuldigung,
wenn ich dir da rein... Ja, alles gut. Diese Qualitätsanforderungen, die können nämlich genau das, wie du es gerade gesagt hast, auch mittransportieren. Wenn mir das wichtig ist, dass ich das skalieren kann, dass ich auch Module austauschen kann, dann kann ich genau das auch in diese Qualitätsanforderungen mit reinschreiben. Ja, danke, dass du es nochmal erwähnt hast. Für mich als Anforderungsmanager ist das immer wichtig zu erklären, dass das definitiv möglich ist, ja.
Ja, das ist richtig, oder es ist sogar so, oder und das ist so, wenn ich mit den Leuten Architektur mache, ist das auch so ein ganz zentraler Punkt, eben diesen Fokus auf diese Qualitätsanforderungen. Oder man weiss heute tatsächlich, dass auch die Qualitätsanforderungen, also Dinge wie. Wie weiterentwickeln, wie stabil, wie performant, wie skalierbar, wie robust usw.
Das sind diese Qualitätsanforderungen, dass die einen grösseren Einfluss auf die Struktur der Software, also das heisst auf die Architektur haben, als dies die reinen funktionellen Anforderungen, also die Features haben.
Und das ist am Anfang ein bisschen schwierig zu verstehen, aber ich sage ein bisschen, mit einem Smile auch manchmal in den Workshops zu sagen, okay es kommt eigentlich nicht darauf an, ob wir jetzt eine Kaffeemaschine entwickeln oder Reuergeräte entwickeln wichtig ist, dass wir mir sagen, braucht ihr sehr ein skalierbares, performantes oder was auch immer System und dann machen wir eine Architektur und ob dann das Teil dann eher in den Kaffee rausbringen soll oder was anders tun soll,
das bringen wir dann auch noch rein, aber das ist nicht die Schwierigkeit die Schwierigkeit ist irgendwie die Qualitätsanforderungen möglichst gut umzusetzen. Und da braucht es dann eben wirklich einen richtigen, guten Architekturprozess, dass man das schafft. Und eben, um den Ding wieder zu schliessen, den Kreis wieder zu schliessen, wenn man sehr agil unterwegs sein möchte mit der Systementwicklung, heisst es eben auch, diese Agilitätsanforderungen,
gleich Qualitätsanforderungen da reinzubringen. Ja, ganz genau. Sehr schön, Matthias. Jetzt weiß ich aus meiner Vorbereitung, dass du ein Buch geschrieben hast zu diesem Thema oder worum geht es in dem Buch? Ja, genau. Es hat ein Buch geschrieben, dass der Titel ist «Navigieren in der Softwarekomplexität.
Strukturiert und systematisch vorgehen». Und du hast mich gefragt vorhin, ob ich denn versuche, jetzt diesen Begriff Architektur da ein bisschen anders zu verändern und eher von Planen oder von so anderen Begriffen zu sprechen.
Tatsächlich habe ich hier bewusst auch nicht jetzt einfach ein Architekturbuch, machen wollen, sondern eigentlich die Leute ansprechen, die eben gesehen haben, okay, diese Softwareentwicklung ist recht komplex, kompliziert, da fehlen mir vielleicht ein bisschen strukturierte und systematische Ansätze und das ist so eigentlich die Zielgruppe.
Also das ist nicht ein Architekturbuch, das ein Softwarearchitekt oder ein erfahrener Softwareentwickler vielleicht lesen müsste, aber für alle die Leute, die denken, okay, aber vielleicht geht es schon noch etwas strukturierter und systematischer und so, dass wir da nicht einfach auf Zufall ein gutes System hinkriegen, für das ist das eigentlich geschrieben.
Und es hat, wie die zwei Aspekte drin, die ich am Anfang erwähnt habe, einerseits auf das Produkt bezogen, also das sind dann wirklich Strukturen einer Software, also die Softwarearchitektur, aber dann eben auch auf die Organisation, also was dann eben auch organisationsentwicklungstechnisch wichtig ist, dass man es schafft, dann eben auch diese Software-Komplexität in den Griff zu kriegen. Okay, hört sich sehr pragmatisch an, das mag ich ja, solche Ansätze.
Den Link auf das Buch, weil jetzt, wo wir es erwähnt haben, werde ich auch noch in die Shownotes packen, dann kann man sich das auch noch mal angucken und vielleicht sogar kaufen. Und was ... Sind deine Dienstleistungen konkret? Also wir haben jetzt natürlich, haben wir schon immer wieder rausgehört, du machst Workshops, du begleitest Unternehmen dabei, Softwarearchitekturen aufzusetzen. Bin ich da schon richtig? Also sind das so deine Tätigkeitsfelder oder was machst du konkret?
Ja, häufig beginnt oder ist der Startpunkt, dass man entweder eben so auf ein Produkt, auf eine Entwicklung auf eine konkrete Entwicklung dann schaut und ich habe da so ein Dienstleistungsprodukt oder so ein Produkt as Service das ja du auch mit dieser Lassenhefterstellung hast, wo ich dann so eine Architekturanalyse mache, um einfach mal zu eruieren okay, macht das irgendwie Sinn, wie das jetzt angedacht ist.
Macht natürlich am meisten Sinn, wenn man das sehr früh tut und nicht erst, wenn das Kind schon im Brunnen gefallen ist. Das heisst, wenn vielleicht auch Pläne, Architektur, Designdokumentation da sind, dass man mal überlegt, ist das jetzt tatsächlich die richtige Architektur, um diese Eigenschaften dann zu erfüllen, das ist diese Architekturanalyse.
Oder es gibt dann auch analog auf Organisation auch so eine Analyse, wo ich da mal versuche, einfach mal reinzuschauen und mal zu überlegen, okay, was sind Dinge, die gut funktionieren, wo gibt es Reibungsverluste, was müsste man angehen und da versuche ich mich ein bisschen abzugrenzen oder unterschiedlich vorzugehen. Ich sage da nicht einfach, ihr müsst einfach eine agile Transformation machen, das ist alles gut, da gibt es es.
Da gibt es Dienstleistungen, die das tun. Ich gehe wirklich hin, also eher so diesen Ingenieursmindset und zu sagen, okay, zuerst muss man es ja mal analysieren und dann kann man sagen, wo wirklich da was gemacht werden muss. Und vielfach ist es ja auch so, dass sehr vieles schon da ist und auch gut funktioniert, auch nicht geändert werden sollte. Aber halt ein paar Orten sieht man dann, ja, hier solltet ihr was tun.
Genau, also das ist auch, da sprichst du mir aus dem Herzen, viele Sachen laufen ja gut, die Unternehmen verdienen ja Geld, also das kann ja nicht von, das kommt ja nicht von irgendwo her, sondern dadurch, dass man ja auch Ingenieure schon beschäftigt hat, aber wie du sagst, es gibt diese Reibungsverluste und das finde ich gar nicht mal so schlecht, diesen Ausdruck, Reibungsverluste, wo man sagen könnte, ey, damit das hier wie eine geölte Maschine läuft,
könnte man nochmal diese, zusehen, dass diese Reibungsverluste weggehen und dann gezielt das angehen an den Stellen. Und dann meistens läuft es dann halt nach so einer Analyse auch darauf raus, dass ich die Unternehmen nochmals eine Zeit lang begleite, aber das ist dann halt je nach Situation sinnvoll oder ob es dann ganze Teams sind, die man eher für Mentoring begleitet.
Ich habe jetzt zwei solche Kunden, wo es um eine Neuentwicklung geht, wo ich so dieses Mentoring im Bereich Architektur mache. Aber das ist dann halt sehr individuell, was da gebraucht wird. Manchmal reicht es auch einfach mal aufzuzeigen, wo man ist. Vielleicht braucht es einfach auch eine Expertise, wenn es um eine Entscheidung geht. Also das sind so diese Tätigkeitsfelder, wo ich unterwegs bin aktuell, ja. Okay.
Super, Matthias. Sag mal, jetzt haben wir ganz viel Systems Engineering, Software Engineering, Software Architektur darüber gesprochen. Agilität hatten wir auch angerissen. Gibt es irgendwas, was wir vergessen haben? Schweigen im Walde? Ja, nein, ich glaube, wir haben es recht umfassend.
Vielleicht abschliessend kann ich nochmals, Ich habe es sicher schon ein bisschen angesprochen, aber vielleicht nochmals betonen, dass es halt auch im Softwareumfeld, sollte es keine Ausrede geben, dass man das nicht verstehen kann, dass man das nicht irgendwie aufzeigen kann, wie das funktioniert, dass auch Leute, die nicht sehr tief drin sind, da mitdiskutieren, mitentscheiden können.
Ich glaube, das wäre so mein Aufruf an die Hörer, da irgendwie da hart zu bleiben und auch mal bei den Softwareentwicklungen einzufordern, dass sie zeigen, wie das funktioniert, sodass man dann miteinander auch darüber sprechen kann und gute Entscheidungen finden kann. Das wäre so noch vielleicht ein Abschlussvotum dazu. Ja, vielen Dank.
So, jetzt müssen wir ganz zum Schluss noch kurz drüber sprechen, wenn jemand Interesse hat, sich mit dir zu vernetzen oder mit dir über deine Dienstleistungen zu sprechen, wo finden dich die Menschen im Netz? Ja, meine Webseite ist relativ einfach merkbar, das heisst visuellklar.ch, das haben sicher die meisten schon mitgekriegt, ich komme aus der Schweiz.
Über LinkedIn mit meinem Namen findet man mich auch da bin ich auch recht aktiv einfach irgendwie eine Mail schreiben eine Kontaktanfrage bei LinkedIn machen oder auf meiner Webseite da gibt es auch so ein Kontaktformular da kann man auch schon direkt ein kleines Gespräch da buchen also ich denke da findet man mich würde mich freuen natürlich wenn da jemand das vielleicht hört und dann auf mich zukommt Alles klar.
Gut, das werde ich dann auch nochmal in die Shownotes verlinken und ja, dann bin ich mal gespannt, ob du darüber ein paar Kontakte mehr demnächst verzeichnen kannst. Vielen Dank für das Interview, hat mir Spaß gemacht, hat auch wirklich, dadurch, dass ich ja selber aus der Softwareentwicklung komme, einige Aspekte haben mich selber direkt angesprochen und auch meine Erfahrungen bestätigt. Von daher vielen Dank, dass du da warst und schöne Grüße in die Schweiz, Matthias.
Danke, Bär, ich danke dir für das spannende Gespräch. Das war mein heutiges Interview mit Matthias Künzi. Brauchst du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest du meine E-Mail in den Shownotes. Scrolle in den Shownotes einfach runter, da findest du sie, kopiere sie einfach und füge sie in deinem E-Mail-Programm ein, schicke mir eine Mail und ich melde mich bei dir, sodass wir darüber sprechen können.
Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Mein Name ist Björn Schorre und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem wünsche ich dir einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.