Kaizen 2 go 334 : Software-Architekturen und Entwicklungsprozesse bei Embedded-Systems

Inhalt der Episode:

Was sind Embedded-Systems?
Was zeichnet die Produktentwicklung generell und die Software-Entwicklung im besonderen aus?
Welche Rolle spielt dabei die Software-Architektur und die übergeordnete Systemarchitektur?
Was bedeutet das, wenn man für Embedded-System agile Konzepte einsetzen will?
Welche Vor- und Nachteile kann das mit sich bringen? Welche Konsequenzen können sich dabei ergeben?
Welche Rolle spielen dabei die Software-Entwickler und der weitere Kontext der Produktentwicklung und dem Einsatz im Feld?
Welche Möglichkeiten des Transfers der Erkenntnisse und Konzepte in andere Kontexte bestehen dabei, bspw. auch im Führungskontext?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 334 : Software-Architekturen und Entwicklungsprozesse bei Embedded-Systems

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Alexander Eisenhuth bei mir im Podcast-Gespräch. Er ist Embedded Software Architekt. Hallo Alexander.

Alexander Eisenhuth: Hallo Götz, Grüß dich.

Götz Müller: Ja, schön, dass du heute dabei bist. Ich habe schon ein kurzes Stichwort zu dir gesagt, aber stell dich gern noch mal den Zuhörern in ein paar Sätzen vor.

Alexander Eisenhuth: Dankeschön. Mein Name ist Alexander Eisenhuth. Ich lebe und arbeite in Freiburg, bin in der IT selbständig, seit fast nun über 30 Jahren und, ja, immer typischerweise im Bereich von technischer Applikationensentwicklung oder Embedded Systems und seit den letzten 10 Jahren bin ich eigentlich hauptsächlich als Software-Architekt von Embedded Systems unterwegs. Und seit letztem Jahr biete ich ein 1-zu-1-Mentoring für Software-Architekten an.

Götz Müller: Genau. Und das ist auch ein großer Teil unseres Gesprächs und natürlich rede ich immer in irgendeiner Form mit meinen Gesprächspartnern über Prozesse. Jetzt in dem Fall halt über Entwicklungsprozesse im Kontext von Embedded Systems, da werden wir sicher noch dazu kommen, dass die Zuhörer dann auch, vielleicht außer uns beiden, richtig durchdringen, was damit gemeint ist. Ein bisschen erinnert mich das an mein früheres Leben. Zum Einstieg aber eben einfach die Frage, was ist deine Definition von Embedded Systems?

Alexander Eisenhuth: Ein Embedded System hat eigentlich immer eine ganz spezielle Aufgabe und diese spezielle Aufgabe macht es sehr zuverlässig. Also um es sich vorzustellen in unserer Welt, also wir leben in einer Welt umgeben von Embedded Systems. Mein Paradepferd ist immer das Bremssystem im Auto. Das kennt natürlich jeder, man drückt drauf und es muss bremsen. Es muss äußerst zuverlässig sein und es ist ein Embedded System im System Auto. Also es ist eingebettet in ein großes System und hat eine ganz spezifische Aufgabe. In einer Kaffeemaschine zum Beispiel ist auch in Embedded System drin, das die Kaffeezubereitung steuert oder eine Waschmaschine ist eben ein ganz populäres, ja, auch Embedded System.

Götz Müller: Ja, im Grunde kann man fast sagen, es gibt, wenn ich es mal grob von einem geistigen Auge vorbeiziehen lasse, gibt es fast nichts mehr, wo nicht in irgendeiner Form ein kleines Stückchen eben Embedded Software drinsteckt, die man aber eben als Normalsterblicher, wenn man nicht ganz, ganz intensiv darüber nachdenkt, halt gar nicht so wahrnimmt, oder?

Alexander Eisenhuth: Ja, so sehe ich es eigentlich auch. Wir sind eben, seitdem auch diese Chip-Entwicklung immer weiter fortgeschritten ist, immer leistungsfähiger, wird immer kostengünstiger, kann man jetzt eben in so einem digitalen System viel abbilden, was man früher vielleicht äußerst aufwendig in einer analogen Elektronik abbilden musste.

Götz Müller: Ja, und jetzt würden wir uns ja über das Thema heute nicht unterhalten, wenn es nicht doch aber besondere Dinge gäbe, die man im Kontrast vielleicht, und da kann man auch noch mal drauf, die man beachten muss im Gegensatz zur Software, die wirklich mit einem Menschen interagiert, so wie wir ja alle kennen, dass wir halt vor einem Computerbildschirm sitzen und da irgendwas passiert, weil wir da über die Tastatur, über die Maus und das, was wir schlichtweg sehen und soweit, ja interagieren. Und dann eben die Frage, was ist, kann man das so einfach umreißen, was ist dieser Unterschied dieser Form der Produktentwicklung, der Software-Entwicklung im Kontrast auch vielleicht zu dem, wo wir eben einen anderen Zugang dazu haben als Normalsterbliche wieder?

Alexander Eisenhuth: Ja, eben so ein Embedded System hat ja viel mit anderen technischen Geräten und Physik zu tun, deswegen gibt es bei der Entwicklung eben auch ganz andere Disziplinen. Also man hat eigentlich immer eine Elektronik-Entwicklung, weil man muss dieses System aus verschiedenen Elektronikkomponenten aufbauen, da ist auch immer Mechanik, Gehäuse drin, dann gibt es so Spezialdisziplinen, je nachdem Optik oder Funktechnologie, die kommen eben auch noch mit rein und dann eben zum Schluss die Software, die das Ganze dann steuert und intelligent macht. Und ja, was ich immer so sehe ist, also ich habe auch Einblick in die Webentwicklung und Cloud-Entwicklung und dort weiß man gar nicht immer so genau, wie der Kunde eigentlich darauf reagiert auf das System, das man entwickeln will. Ich sage mal, ich möchte einen Yogakurs eben als Webanwendung machen und ich weiß ja ein bisschen, was er machen möchte, aber in der letzten Zeit geht man da oft eben so hypothesenbasiert vor. Das heißt, man überlegt sich eine Art und Weise, wie man das Produkt entwickelt, gestaltet, gibt das nach draußen und misst dann die Akzeptanz dieses Produktes und lässt es sofort wieder in seine Entwicklung einfließen, um dann eben ganz spezifisch ein erfolgreiches System zu schaffen. Bei einem Embedded System, das so speziell eingebettet ist in ein System, da sind die Schnittstellen und Anforderungen, oft sehr viel klarer, und ich kann dann eigentlich viel mehr mit stabilen Anforderungen rechnen und anhand von denen dann entwickeln.

Götz Müller: So, jetzt haben wir ja so einen Doppeltitel in unserer Episode – Entwicklungsprozess, aber eben auch Software-Architektur und ich glaube, Software-Architekturen gibt es jetzt auch wieder in beiden großen Bereichen. Klassische IT Schrägstrich Web als ein gewisses Unterthema, aber eben auch Embedded. Also, welche Rolle spielt da jetzt Software-Architektur und eben vor allen Dingen auch die übergeordnete Systemarchitektur, wenn ich über Embedded Systems rede.

Alexander Eisenhuth: Ja, es gibt ja auch bei der Entwicklung dann zwei Rollen, es gibt einen Systemarchitekt und einen Software-Architekt und der Systemarchitekt, der muss erstmal das große Problem weswegen man das System baut, muss er Runterbrechen im Endeffekt in: Was realisieren wir in Hardware und was realisieren wir in Software? Dann hat man so eine Systemarchitektur, man hat so diese Blöcke und hat Schnittstellen dazwischen. Und dann kommt das Software-Architekt zum Tragen und muss dann die Software anhand der Hardware-Schnittstellen entwickeln und was in der letzten Zeit immer deutlicher wird, ich meine, es war schon immer die Aufgabe des Software-Architekten ist oder auch mit dem Systemarchitekten zusammen die Qualitäten, die das Zielsystem haben soll, also das Produkt, das man entwickeln möchte. Unter Qualitäten kann man diese nicht-funktionellen Anforderungen verstehen, da gibt es so etwas wie ein Zeitverhalten, oder eine Skalierbarkeit des Produktes oder eine Portierbarkeit auf andere Plattformen oder ähnliches. Und es ist eben die Aufgabe des Software-Architekten, diese Qualitäten zu schaffen und dann macht er, typischerweise modularisiert er dann, also er schneidet das große Problem der Software in kleine Teile und schafft die Schnittstellen, spezifiziert diese, er trifft ganz viele Entscheidungen, auch mit dem System-Architekten vielleicht zusammen. Wir haben zwei, drei Möglichkeiten, es ist seine Aufgabe dann, eben diese Entscheidung zu fällen. Dann muss man viel auch Konzeptarbeit machen. Wie realisiert man jetzt diese Software? Und dann natürlich begleitet er die Entwicklung.

Götz Müller: Jetzt glaube ich, kommt man ja um das Thema agil, wenn man gleichzeitig den Begriff Software in den Mund nimmt, ja nicht drum rum und jetzt in meiner, ein Stück weit, etwas aus der Distanz wahrgenommen Wahrnehmung kommen agile Konzepte beziehungsweise werden agile Konzepte, du hast es eingangs schon erwähnt, ja sehr häufig eingesetzt in dem Augenblick, wo ich einen Benutzer, einen direkten Benutzer dieser Software habe, der also, ja, ein Stück weit aber auch ein Teil dann schon des Systems wird, anders wie vielleicht das Bremspedal beim Auto, was ja eine eher einfache Schnittstelle ist. Was bedeutet das jetzt für Embedded Systeme, dort den Software-Entwicklungsprozess, wenn ich agile Konzepte einsetzen will?

Alexander Eisenhuth: Also, lass es mal andersrum machen. Ich möchte jetzt gerade nicht gleich erklären, warum, sondern … mich halt interessiert, ich war letztes Jahr beim ESE-Kongress und habe dort über agile Software-Entwicklung in Embedded Systemen einen Vortrag gehalten und dann war meine Eingangsfrage „Wie viele der hier Anwesenden verwenden Agilität in ihrem Unternehmen?“ und es waren eher 40%, also nicht die Mehrheit, sondern eher weniger. Ich persönlich habe die Agilität eigentlich in meinen letzten 10 Jahren als Software-Architekt miterlebt, vor 10 Jahren waren es die ersten Projekte, das war damals ein Zugsicherungssystem, das dann als Pilotprojekt mal agil gemacht wurde und es waren eine sehr lustige Aspekte dabei, aber heute, Stand heute, würde ich sagen, 50-60%, also das nimmt einfach auch zu und die Aspekte sind jetzt weniger auf das bezogen, wie ich vorher gesagt habe, dass man den Endkunden eben und sein Feedback mit einarbeitet, aber ein Embedded System hat auch ganz andere Herausforderungen, oft kriegt man Chips auf den Tisch, die Spezifikation erfunden, die irgendwelche Mechanismen versprechen, und die muss man eben auch erstmal verifizieren und qualifizieren. Und das heißt, die ganze Entwicklung, die ganze Systementwicklung kann man auch eigentlich prima agil planen, indem man eben verschiedene Aspekte inkrementell entwickelt, weil man muss dann auch unter Umständen auf dem halben Weg sagen, okay, wir müssen das anders lösen, und wenn wir das, wie früher runterspezifiziert gemacht hätte, dann hätte man mittendrin erlebt: Okay, uh, hier haben wir aber eigentlich ein Problem. Ich weiß nicht, warum das ist, ob früher die Hardware dann stabiler war und ich möchte auch nicht sagen, dass der eigentliche Grund dafür Agilität ist, aber die Zusammenarbeit im Team bei der Software-Entwicklung, das ist eigentlich der große Benefit, den man neben den risikominimierenden Maßnahmen, die man finden kann, sehr gut einsetzen kann, nämlich dass die Leute zusammensitzen und zusammen entwickeln und auch mit per Programming oder eben sofort testen, Testing First oder ähnliche Dinge, eine sehr effektive Art der Software-Entwicklung haben.

Götz Müller: Okay, ich höre da jetzt auch raus, und wie gesagt, das ist vielleicht meine eher entfernte Vorstellung von agiler Software-Entwicklung, ich habe halt nicht diese Dynamik aufgrund des Faktors Mensch an der Benutzeroberfläche, den ich halt manchmal erst fragen muss bezüglich dem, was er da eigentlich damit machen will, was er denn damit machen will, sondern ich habe, der Nutzen der Agilität kommt da zustande, weil ich so komplexe Systeme habe, dass ich nicht mehr in der Lage bin, in Anführungszeichen, wie früher Dinge runterzuspezifizieren, Klammer auf, so uralte Konzepte wie Wasserfallmodell, einfach gar nicht mehr einsetzbar sind. Das ist so ein bisschen meine Interpretation, geht es in die Richtung?

Alexander Eisenhuth: Ich sehe zwei Dimensionen, ja. Zum einen ist es das technische System, das komplexer wird und zum anderen ist auch dieses System Unternehmen und dort wie die Abteilungen, also du hast ja, wenn du komplexe Embedded Systeme hast, hast du ja verschiedene Abteilungen, du hast ja Komponenten, die zugeliefert, du hast Schnittstellen in der Firma und ähnliches und dort ist eben auch die Zusammenarbeit eben durch Agilität viel, viel effektiver, weil du hast nicht diesen, wir schreiben hier Komponenten und werfen sie dann aufs System drauf und integrieren das zusammen und dann stellt man fest, das funktioniert nicht. Ich sage mal so eine ideale Software-Architektur, wenn man ein Greenfield-Projekt hat ist, dass man einen Pfad, eine Architektur-Vision macht und einen Pfad durch alle Schichten von oben der Applikation bis unten auf die Hardware schafft und anhand von diesem Gerüst eben, sage ich dann mal, man kann es auch gerne mit einem Skelett vergleichen, da macht man dann das Fleisch dran und dann entwickelt sich das System zusammen, auch über Abteilungen hinweg und solange die Schnittstelle definiert ist, kann man gegen diese Schnittstelle dann entwickeln.

Götz Müller: Ja, da, da kommt mir jetzt sofort eben ein Gedanke aus meinem früheren Leben und du hast es ja gerade genannt, ich habe halt nicht nur verschiedene Software-Entwicklungsabteilungen, die vielleicht verschiedene Teile des Systems realisieren, sondern es dehnt sich eben auch Richtung Hardware aus und da habe ich dann früher, vielleicht ist es heute immer noch so erlebt, dass man halt manchmal einfach ein Stück weit auch verschiedene Sprachen spricht, dass halt Hardware-Entwickler, eine ganz andere Sprache sprechen wie Software-Entwickler.

Alexander Eisenhuth: Ja, ich glaube, das kann ich bestätigen. Ja, jeder lebt so in seiner Welt und hat sein Verständnis. Es war ja, oder ist wahrscheinlich auch noch so, dass du ja zuerst die Hardware brauchst, damit du die Software drauf integrieren kannst. Aber diese Software-Hardware-Schnittstelle, die wird sich natürlich zusammen im Detail angeschaut und man muss sich nur über das im Klaren, im Kontext der Systemarchitektur, sein. Und ich glaube inzwischen redet man so miteinander, dass man da vielleicht weniger Sprachbarrieren dann hat.

Götz Müller: Ja, weil, und das habe ich am Ende erlebt, dass zum Beispiel eben. FPGA-Programmierung, schon allein der Begriff legt es nahe, ja, damals schon, also schon vor 20 Jahren, schon mit Softwaremitteln gemacht wurde, obwohl die Menschen zumindest damals, die, die mir begegnet sind, sich immer noch als Hardwareentwickler verstanden haben, trotzdem haben sie mit höheren Programmiersprachen, VHDL als eines der Dinge, die mir da im Kopf blieb, ihre Hardware mit softwaretechnischen Mitteln gestaltet.

Alexander Eisenhuth: Ja, das ist ganz lustig, ich hatte mit einem FPGA Entwickler eben auch die Frage, ob das Software ist, was er macht und er hatte die Ansicht, das ist keine Software, aber dann habe ich ihm gesagt “Nein, aber du hast hier die Hardware, du schiebst ein Bit-File drauf, also machst du, hast du eine Software gemacht eigentlich”, aber ja, das ist halt vielleicht das eigene Weltbild und vielleicht typischerweise der FPGA-Entwickler sieht es eben so, dass er eigentlich auch mehr, oder ein hochsprachiger Hardware-Entwickler ist.

Götz Müller: Ja, mir kam oder mir kommt jetzt, wo wir kurz drüber reden, eine Sache in den Sinn. Es war damals zumindest ein absolutes Tabu, eine Laser-Sicherheitsabschaltung, die halt sicherheitskritisch ist, in FPGA zu entwickeln, weil das ja Software ist. Das heißt, auch wenn man das ja technisch machen kann, war es, zumindest damals, ein absolutes Tabu, das als Teil eines FPGAs zu machen, sondern ich musste das diskret aus Widerständen, Transistoren und so weiter realisieren, um diesen etwas, ich drücke es jetzt mal ein bisschen flapsig, krass aus, um diesem etwas wie zwielichtigen Verhalten der Software beizukommen.

Alexander Eisenhuth: Kenne ich beides. Eine Lasterabschaltung ist lustigerweise, hatte ich jetzt hier auch einen Sensor mit Laser, die Laserabschaltung wurde aber auch in Software gelöst, aber mit einem Prozessor, also mit einem spezifischen Sicherheitssystem, das sonst keine anderen Aufgaben hat, aber auf der anderen Seite habe ich auch ein FPGA, der hat Sicherheitsfunktionalität, weil er eben so vorhersagbar ist im Gegensatz zur Software, bei FPGA hab ich ganz klare, viel bessere Echtzeit-Anforderungen, kann ich damit realisieren und kann dann eben auch sagen, wenn irgendetwas nicht zusammenpasst, im System: Abschalten, sicherer Zustand. Also FPGA ist heute durchaus ein Mittel, um das zu realisieren.

Götz Müller: Gut, jetzt müssen wir vielleicht aufpassen oder ich vor allen Dingen muss aufpassen, dass wir nicht zu sehr in super Details abschweifen, wo der Rest der Zuhörer sich dann fragt, über was reden die jetzt gerade. Wenn wir jetzt noch mal auf den Aspekt eben agile Entwicklung zurückkommen und ich persönlich … bei allen Dingen, die man in irgendeiner Form nutzt, sollte man immer berücksichtigen, dass so etwas Vorteile hat, sonst würde ich es nicht machen, aber vielleicht man auch bestimmte Dinge in Kauf nehmen muss und da jetzt noch mal ein bisschen nachgebohrt, was ist deine Ansicht, was sind eventuell Probleme, über die man sich bewusst sein sollte, wenn man agile Konzepte in einem Embedded-Kontext einsetzt, die man vielleicht in einem klassischen IT-, Software-Entwicklungskontext so nicht haben wird.

Alexander Eisenhuth: Ich würde sagen, du hast halt immer diese, du kannst nicht alle Domänen und die Domänen sind eben diese Fachdisziplinen, ne, Konstruktion, Elektronik, die ich dann vorher genannt habe, die kannst du nicht wirklich immer agil zusammenlaufen lassen. Ich sage mal so, in der Software hat es sich so eingebürgert, die Agilität beruht ja im Kern darauf, dass du immer Iterationen hast in bestimmten Abständen, du nimmst dir immer ein Inkrement vor, das du da schaffen möchtest und die sind sehr kurz, zwei, drei Wochen. Jetzt in zwei, drei Wochen kann eine Hardwareentwicklung eigentlich nichts anfangen, die müssen über viel längere Zeit Zeiträume das machen. Das heißt, du hast die Herausforderung auf jeden Fall, diese Elektronikentwicklung und die Software-Entwicklung on track zu kriegen, zusammen zu kriegen. Das ist bestimmt eine Herausforderung, die dir immer bei Embedded Systemen begegnet. Aber wenn ich mal, wenn ich jetzt mal den Entwicklungsprozess noch weiter denke oder weiter mache, man hat ja auch immer beim Testen, bei der Verifikation der Hardware hat man ja immer eben Verifikation des Systems, hat man immer die Hardware noch mit dabei und das ist eine besondere Herausforderung, die eben auch zu integrieren in der, sage ich mal, in der Software-Entwicklung, klassisch agil, hat man ja immer ein CI-System, das heißt man integriert diese Inkremente, die ich genannt habe immer kontinuierlich in die Software und da hat man eben die Herausforderung jetzt muss man es auf der Hardware testen. Das heißt, ich muss eine Hardware, nämlich die Zielhardware in das CI-System integrieren und muss dort eben automatisiert Software aufspielen und testen und das ist noch mal eine besondere Herausforderung, dass dann eben automatisierbar zu machen und dann vielleicht auch mit den Gedanken, na ja, gibt es vielleicht auch verschiedene Hardware-Varianten, die ich da auch noch mit testen möchte und irgendwann hört mal dieser kontinuierliche Gedanke auf und dann muss ich eben in einen manuellen Test gehen, wo ich eine System-, also eine Test-Spezifikation habe, die ich dann durchtesten muss.

Götz Müller: Ja, jetzt, jetzt möchte ich es insofern noch ein bisschen vertiefen, weil ich glaube, das ist dann auch die Chance, dass man diese, ja, nennen wir es mal besonderen Herausforderungen, die die Agilität an der Stelle vielleicht mit sich bringt, dass man das eben jetzt auch auf möglicherweise ganz andere Prozesse übertragen kann, wo jemand sagt, wow, Agilität hört sich ja spannend an, aber ob das jetzt bei mir funktioniert, weiß ich nicht und dann können wir uns ja jetzt durchaus von dem klassischen Produktentwicklungsprozess sogar mal lösen und auf was ich also ein bisschen raus will ist, du hast es schon angedeutet, ich möchte es gerne ein bisschen vertiefen: Wie gehe ich damit um? Weil ich glaube, das ist eben dann die die Chance des Transfers in möglicherweise ganz andere Dinge. Es gibt ja schon Gedanken in einem Baukontext auch Agilität einzusetzen, aber auch dort habe ich diese unterschiedlichen, ja Geschwindigkeiten, ohne dass jetzt schnell besser sein muss als langsam.

Alexander Eisenhuth: Das ist, also ich sag mal, ja, im Prinzip kann man ja ein agiles Vorgehen auf alles, auf alles anwenden. Ich kann auch ein Krankenhaus agil organisieren zum Beispiel. Aber wenn man dann so einen Gesamtprozess hat, der abgesehen von unserer Produktentwicklung irgendwie funktionieren muss. Das ist nicht mein Spezialgebiet und da verlasse ich dann auch meine Kompetenz, aber wenn ich es jetzt mal in das Unternehmen rein projiziere und dort eben vielleicht auch den Kunden mit reinnehme und ich sage: Okay, hier, ich mache eine neue Geräteentwicklung, Kunde, was ist dir denn besonders wichtig? Und wenn man das mit seinem Kundenportfolio abgleicht, kann man, sage ich mal, auch eine hervorragende Art und Weise, ein sogenanntes Minimal Viable Product zu spezifizieren und dann mit den Kunden zusammen eben auch solche Produktentwicklungen zu machen.

Götz Müller: Ja, ich find's insofern spannend, weil man natürlich, jetzt im Lean-Kontext, aber im Grunde gilt es ja für alle anderen Dinge auch, ich habe ja nicht nur den externen Kunden, sondern ich habe ja eventuell auch, oder ganz oft, eben einen internen Kunden, mit dem man manchmal, mit dem externen redet man auch nicht oft genug, das begegnet mir auch immer wieder, aber auch manchmal mit diesem internen Kunden nutzt man, finde ich, die Chance viel zu selten und das finde ich dann das spannende persönlich an dem agilen Ansatz, dass ich ja schon fast dazu, ja, gezwungen werde, mit ihm in Interaktion zu gehen und gleichzeitig sich daraus aber auch auf eine andere Art und Weise schon fast eine Verpflichtung ableitet, nämlich zu sagen, als Kunde, was ich wirklich haben will, was ich brauche, und mir darüber manchmal sogar auf einem anderen Detaillierungsgrad sogar darüber im Klaren zu werden, nicht diesem flapsigen Spruch: “Wenn ich meine Kunden gefragt hätte (Henry Ford), was sie denn haben möchten, hätten sie schnellere Pferde gesagt.”

Alexander Eisenhuth: Ja, da kann ich aber auch nur zurückkommen. Also die internen Kunden, die ich jetzt aus meiner Watte sehe, sind andere Entwicklungsabteilungen zum Beispiel, und wenn ich das dann jetzt noch mal in mein vorheriges Beispiel mit reinnehme und von außen der Kunde sagt, okay, er möchte einen Sensor, der nur eine spezifische Sache vielleicht als erstes kann, das reicht ihm vielleicht auch völlig, dann kann ich doch hergehen und diese kleine Sache eben runterbrechen über meine verschiedenen Domänen, die da vielleicht noch betroffen sind. Und dann ist es schon so, dass man das doch prima planen kann zwischen den einzelnen Abteilungen. Okay, wir haben jetzt diese Iteration vor, die dauert jetzt so geschätzt, sage ich mal ein Vierteljahr, und die müssen wir natürlich. machen und dann ergibt sich das schon fast von außen, von so einer Produkt-Roadmap, sage ich das mal, ergeben sich diese Teilschritte und diese Kommunikationsnotwendigkeiten fast schon eben aufgrund der System-Architektur. Und so habe ich das erlebt und fand das eine ganz spannende Projektphase.

Götz Müller: Mhm, ist es jetzt übertrieben zu sagen, wenn in dem Kontext auf Software-Entwickler und da habe ich jetzt vielleicht ein bisschen schräges Bild des Software-Entwicklers, auch weil ich vielleicht selber mal einer war, dass auf ihn da ein Stück weit neue Anforderungen zukommen, zum Beispiel eben kommunikativer Natur mit anderen Menschen im Gesamtprozess? Man sagt ja immer so bisschen flapsig und wie gesagt, vielleicht ist es auch bloß mein extrem verzerrtes Weltbild, dass jetzt Software-Entwickler nicht unbedingt die Kommunikativsten sind, um es mal vorsichtig auszudrücken.

Alexander Eisenhuth: Zum einen sag ich mal, ist es genau, sind es die kommunikativen Fähigkeiten des Architekten, die hier verlangt sind, weil er als Mittelsmann zwischen den Anforderungen, die vielleicht eine andere Abteilung oder das Gesamtsystem an ihn hat, passende Schnittstelle machen muss und wenn die Schnittstelle zwischen zwei Komponenten, zwischen zwei Lagern von Software-Entwicklung soweit klar ist und die beiden Architekten verstehen das, was da geschehen soll, dann hat natürlich der einzelne Entwickler auch die Aufgabe in diesem Kommunikationsmodell mitzuspielen, aber wenn du jetzt Scrum anschaust als Prozess, der ist ja schon auch sehr auf Kommunikation ausgelegt. Du hast deine täglichen Meetings, wo du dich dann kurz austauscht, was steht heute an, welche Hürden könnte da sein, habe ich externe Abhängigkeiten, man ist also vielleicht viel mehr im Gespräch wie vor 15 oder 20 Jahren. Und wenn man zu zweit, also dieses Pair Programming ist wirklich eine wahnsinnig intensive Sache, weil du hast einen doppelten Effekt. Du hast den Effekt, zwei schauen auf den Code, der beschrieben wird und wenn du das richtig machst und die Tastatur wechselst nach einem bestimmten Intervall, lernt der eine immer vom anderen beziehungsweise, ja, dann fragt man, was machst du jetzt und warum machst du das und es kann ja zum einen falsch sein, aber es kann auch einfach Input für dich sein, zum Beispiel, wird das Tooling dann besser verwendet, schneller, effektiver oder was auch immer. Und ich glaube, heute ist einfach eine ganz andere Kultur bei der Software-Entwicklung notwendig als vielleicht früher, der sich dann Tag, zwei Tage ohne Austausch nach außen, sagen wir mal, mit einem Problem befasst hat. Und das Ganze geht ja noch weiter. Wenn du das dann agil machst, dann schaust du dir auch immer an nach deinen ersten, nach deinen 14 Tagen, wo du vielleicht deinen Sprint hast und sagst, na ja, was ist gut gelaufen, was ist schlecht gelaufen und wenn man dann eben noch den guten Scrum-Master dabei hat, dann kitzelt er auch die Probleme, die vielleicht in den kommunikativen Möglichkeiten der Entwickler nicht gegeben sind, kitzelt der raus und dann, also ich sage mal, die modernen Software-Entwicklungsprozesse, die sind vielmehr auf Kommunikation angelegt und deswegen funktionieren die einfach oder haben auch andere Anforderungen an die Software entwickelt.

Götz Müller: Ja, und das finde ich insofern spannend, weil ich das eben als Chance betrachte, wenn man sich mit Agilität und mit agilen Konzepten beschäftigt, auch wenn man halt nicht aus einem Software-Kontext kommt, weil im Grunde das genau die gleichen Herausforderungen sind, wie du sie gerade genannt hast, dass man viel zu wenig miteinander redet, dass man viel zu wenig miteinander über das gleiche, Schrägstrich, dasselbe redet, schon das sind ja zwei verschiedene Dinge, dass also dieses gemeinsame Verständnis für ein Problem eben in klassischen Konzepten gar nicht so existiert oder gar nicht so unterstützt wird und da finde ich dann, auch wenn ich jetzt durch die Lean-Brille betrachtet sage, viele Elemente dessen, was im agilen Kontext definiert ist, hat seinen Ursprung im Lean. Andererseits, wenn man dann mal guckt, wie es denn im agilen Kontext eingesetzt wird, glaube ich gleichzeitig, dass es wieder eine unheimliche Chance ist, zu sehen, wie jemand andere Dinge im Grunde in einem ganz anderen Kontext verwendet und deshalb bestimmte neue Erkenntnisse dazu kommen können.

Alexander Eisenhuth: Ja. Ich frage mal oder ich betrachte das mal aus der anderen Richtung. Was hätten wir den für andere Möglichkeiten, außer dass wir uns über etwas unterhalten? Na ja, klassischerweise ist, dass wir das niederschreiben und lesen. Aber auch beim Lesen ist nicht gewährleistet, dass der, der das schreibt, das gleiche meint wie der, der das liest, aber der kann in dem Moment ja nicht rückfragen und das ist einfach, aus diesem Winkel betrachtet, ist da der kommunikative Ansatz einfach der viel effizientere. Und auch effektivere, würde ich mal sagen, wenn du auf das angespielt hast.

Götz Müller: Ja, definitiv auch. Und gerade wo du den Begriff schreiben genannt hast oder den Vorgangs des Schreibens, habe ich mich dann auch wieder an einen Punkt erinnert, der mir im Grunde aber auch heute noch ständig begegnet, kommentieren von Software-Code. In dem Augenblick, wo ich es codiert habe, ist mir ja völlig klar, was ich da gemacht habe und jetzt ist die ganz große Kunst und das lässt sich eben auf vieles, meiner Ansicht nach, übertragen, das allein für mich selber so zu verschriftlichen, dass ich es am nächsten Tag, in zwei Wochen, in einem halben Jahr immer noch verstehe. Und das ist, finde ich, also das war damals schon, ich weiß nicht, vielleicht hat sich da die Welt auch völlig verändert, aber das war damals schon eine große Herausforderung, das für einen selber und auch für andere natürlich, auch so zu verschriftlichen, dass es dort mit genau dem ankam, was ich selber an Intention hatte. Und da eben dann das, was du auch gerade noch mal betont hast, vielleicht auch nach Alternativen zu suchen. Eben nicht nur zu schreiben, dieser flapsige Spruch “Wer schreibt, der bleibt” zu nutzen und sich aus, ja, vielleicht einem hergebrachten Modell auch rauszubewegen.

Alexander Eisenhuth: Ich finde, hier sind es zwei Sachen. Ich muss noch mal etwas zur Software nachher sagen, aber ich sage mal, eine Architektur, die nicht dokumentiert ist, das ist eigentlich ein No-Go, aus mehreren Sachen. Das ist das zentrale Wissen über eine Software, über ein ganz wichtiges Produkt, über eine Reihenfolge von Entscheidungen, über eine Struktur. Jeder, der heute neu in ein Team reinkommt und das alles über Kommunikation bekommt, der bekommt nicht ein Big Picture präsentiert, sondern irgendwie halt so ganz spezifische Dinge. Also das braucht man unbedingt, diese übergeordnete Dokumentation, die nicht ausschweifend, aber die wichtigen Aspekte niederlegt. In der Software hat sich, ich denk mal, das war im Jahr 2000, der Clean-Code-Gedanke durchgesetzt und ein Aspekt des Clean Code ist, dass du so programmieren sollst, dass du keine Kommentare brauchst. Das heißt, du kannst die Software mit einer Semantik lesen. Und das ist etwas, was Entwickler lernen müssen, dass sie rauskommen aus technischer Beschreibung ihres Quellcodes, wo man Kommentare zu machen muss, was das jetzt bedeutet, hin zu viel feingranularer, aber mit, ich sage mal, mit Verben, mit Semantik, mit Dingen, dass wenn du gut geschriebenen Clean Code vor dir hast, dann kannst du den auch noch in einem Jahr verstehen, weil man erkannt hat, ein Code wird 20 mal öfters gelesen, als dass er geschrieben wird.

Götz Müller: Ja, ja, ist nachvollziehbar. Und eben in der Lage zu sein, Dinge festzuhalten. Ich nenne es mal bewusst so neutral, dass es halt auch jemand anderes versteht, egal ob es jetzt um den Software-Code geht oder um eine, aber Software ist im Grunde auch nichts anderes, eine abstrakte Form von Problemlösung.

Alexander Eisenhuth: Ja, kann man genauso sehen.

Götz Müller: Und eben aus der, und vielleicht sogar idealerweise aus der Form der Problemlösung sogar noch ein Verständnis auf der Metaebene entwickelt, um dann Problemlösungen an sich zu, ja, seine Problemlösungskompetenz weiterzuentwickeln, so im Sinne von der Frage im Hintergrund: Ja, wie ist denn der da vorgegangen, lässt sich das auf meinen Kontext übertragen?

Alexander Eisenhuth: Jetzt sprichst du wieder, triggerst du wieder etwas im Herzen des Architekten, so. Technische Konzepte und das, was der Architekt vorgibt, wie man Software entwickeln sollte, sollten natürlich durchgängig sein. Das heißt, jedes Problem sollte auf die gleiche Art und Weise in der Software gelöst sein, da spricht man dann von querschnittlichen Konzepten. Wenn ich, zum Beispiel, um das bildhaft zu machen, wenn ich mit Fehlern umgehe, sollte ich das eigentlich immer gleich machen. Ich sollte nicht, zum Beispiel, hier eine Lognachricht schreiben und dann um etwas Spezifisches zu machen, im anderen Fall nicht. Und wenn das nicht ist, dass es überall richtig umgesetzt ist, dieses Konzept. Entwickler schauen immer, wie sah denn die Problemlösung damals aus, auf ein ähnliches Problem, das ich jetzt gerade vor mir habe und wenn du dann das dort falsch gelöst hast, man sprich dann von der technischen Schuld, es ist nicht richtig gelöst, dann kopiert er das und dann verbreitet es sich so und dann wird das Ganze, dann verlierst du deine Qualität, die du als Architekt für die Software dir überlegt hast.

Götz Müller: Ja, und da spielt, glaube ich, ein ganz wichtiges Element wieder mit rein, das mir zumindest ganz oft begegnet. Dieser auch wieder, diese etwas flapsig, flapsige Begründung ist das falsche Wort jetzt, aber ein Grund, warum man irgendetwas macht, der mir oft begegnet, diese Aussage “Ja, haben wir schon immer so gemacht”, in dem Augenblick, wo ich es mache, ist ja immer ein Einzelfall, aber dieses Wiederholte, was ich jetzt bei dir rausgehört habe, das ist der entscheidende Faktor.

Alexander Eisenhuth: Absolut. Und das bringt die Qualität. Und ich sag mal so, eine gute Software-Architektur wird von einem Architekten gemacht, der im Team agiert und der eine Architektur definiert und die von allen getragen wird. Da hast du nämlich das Problem, wenn du als Architekt dir auf dem Papier etwas überlegst und sagst: Hier, so müsst ihr es machen, das wird garantiert so gemacht. Weil du musst die Leute mitnehmen. Und das ist auch etwas Agiles, was der Architekt jetzt als Aufgabe hat. Er muss nicht sein eigenes Krönchen hier in die Software gießen, sondern er muss mit dem Team zusammen die Software nach der konzeptionellen Integrität einfach voranbringen.

Götz Müller: Ja, das finde ich jetzt einen spannenden Punkt, auch wenn wir schon ziemlich gut fortgeschritten sind, aber das möchte ich noch kurz ein bisschen vertiefen, weil im Grunde kann man den Architekten ja ein Stück weit auch als Führungskraft betrachten, auch wenn er sich vielleicht selber gar nicht so sieht, aber er bestimmt, wie andere Menschen agieren, im Sinne von Produktentwicklung. Und da finde ich es eben spannend, weil das sind wieder Dinge, die sonst im Allgemeinen, und wenn man jetzt rein über Verbesserungen, wieder Lean-Kontext darüber sprechen, eben auch ganz oft der Fall ist, dass ich irgendetwas im Kopf habe, aber halt nicht in der Form in der Lage bin, das zu kommunizieren und mich dann hinterher wundere, dass die anderen das nicht so machen, wie ich das gedacht habe, Klammer auf, was ganz eben oft, und da wieder der Begriff Führung, bei Führungskräften eine Herausforderung ist, so im Sinne von: Ich habe es ihnen doch gesagt und sie tun es aber nicht.

Alexander Eisenhuth: Absolut, da bin ich völlig bei dir, Götz. Der Architekt ist ein bisschen eine Führungsposition, nämlich er gibt die Führung hier in der Konstruktion der Software vor und es ist seine Aufgabe, auch in diese Rolle wahrgenommen und respektiert zu werden. Ich sage mal, er muss der sein, zu dem das Team geht, wenn es ein Problem hat, technischer Natur und das schafft er einfach, indem er sich mit seinen Social Skills, also als Architekt brauchst du die einfach, während der Arbeit im Team auf alle Fälle, als dieser eine, zu dem man geht, positionierst und die Leute das eben auch gern machen, weil eben die Kommunikation mit ihm einfach klappt und ja, er eben auch wenn so, sage ich mal, so in einem Team so strittige Punkte sind, so irgendwie, dann muss er eben auch als Vermittler ran. Nicht dass er jetzt hier etwas vorgibt, sondern Entwickler A hat eine andere Auffassung wie Entwickler B und dann gehe ich dann immer hin “So, jetzt gehen wir mal ans Whiteboard und zeichnen das auf”, weil manchmal ist einfach auch das Verständnis des anderen, du kennst es ja bestimmt so aus Konflikten auch, ist eigentlich das Problem, das dann aufzulösen in einer kleinen Moderation. Das sind einfach auch diese Dinge, die begegnen, die als Software-Architekt im täglichen Alltag.

Götz Müller: Ja, und ich glaube eben nicht, zumindest ist das so mein Weltbild, ich werde ja nicht als Software-Architekt geboren, sondern ich entwickle mich ja ganz oft, so ist es mir selber mal gegangen, ich entwickle mich ja ganz oft über Jahre hinweg in die Rolle rein. Vielleicht war ich mal, in Anführungszeichen, normaler Software-Entwickler und habe irgendwie so ein bisschen ein Händchen gehabt für Architektur und ich glaube eben auch, da ist der Transfer in Richtung Führung unheimlich spannend, weil dort habe ich ganz oft ja ähnliche Aspekte, dass ich, ja, fachlich sehr gut bin, das macht mich dann zur Führungskraft und da muss ich plötzlich Dinge aufhören zu tun, die mich dorthin gebracht haben. Das finde ich jetzt insofern ganz spannend, weil ich vor kurzem auch eine Diskussion mit jemandem darüber geführt habe. Jetzt muss ich also aufhören, Dinge zu tun, die mich dorthin gebracht haben und das, glaube ich, ist eine ganz große Herausforderung, der Software-Architekt soll ja jetzt nicht hergehen, die Tastatur sich schnappen und sagen “Ja, das machen wir so” und da geschwind was runterhacken.

Alexander Eisenhuth: Das ist auch eine spannende Frage. Programmiert der Software-Architekt? Ich würde mal sagen, wenn es einer ist, wie ich auch zum Beispiel, und aus der Entwicklung einfach komme, dann würde er es gerne machen. Aber er hat einfach nicht die Zeit dazu, aber durchaus Spezifikationen macht man, von Schnittstellen, nicht auf Papier, sondern man schreibt auch ein Stückchen Quellcode, einfach nur die Schnittstelle, die abstrakte Schnittstelle und die wird dann dokumentiert und was auch immer es ist und die wird dann verwendet von den Entwicklern. Also ich komme schon ab und zu an die Tastatur, aber nicht um Algorithmen und Problemlösungen runterzuschreiben, sondern um. Zu entwerfen.

Götz Müller: Ja, ja. Aber eben nicht, so habe ich es jetzt zumindest verstanden, aber eben nicht um die direkten Probleme, mit denen jemand zu mir kommt, um die ihm zu lösen, sondern ihn dort zu unterstützen, das dann selber lösen zu können. Es sei denn, da hat sich irgendetwas auf einer Architekturebene irgendeinen offenen Punkt ergeben, da bin ich dann natürlich wieder gefordert.

Alexander Eisenhuth: Ja, also Funktionen oder funktionelle Anforderungen umsetzen, das macht er eigentlich nicht. Was ich als Architekt eben oft mache, ist den Code der Programmierer lesen und dann eben meine Kommentare dazu reinschreiben und das ist einfach ein super Mittel des Feedbacks in den agilen Prozessen, hier als Reviewer und Software-Reviewer sind heute eigentlich gang und gäbe. Es gibt keinen Code, der committed wird, ohne das vorher ein Software Review stattfindet oder wenn es große Commits gibt, dann bin ich da und schaue mir dann von den Schnittstellen her eben das Ganze dann an.

Götz Müller: Mhm, ja. Ich sehe also wirklich da diesen, und das hat sich jetzt erst im Gespräch im Grunde ergeben, diese hohe Ähnlichkeit zu einer klassischen Führungsrolle, wo ich auch eben aufhören muss, bestimmte Dinge zu tun, ohne nicht trotzdem mal ins Detail zu gucken. Das heißt, ich schaue mir natürlich schon, auch wenn jemand mit einem Problem oder idealerweise auch mit einer Problemlösung oder mit einem Vorschlag von einer Problemlösung auf mich zukommt, dann schaue ich mir schon an, was er sich dabei gedacht hat, aber ich löse ihm das Problem nicht direkt, sondern ich unterstütze ihn dabei.

Alexander Eisenhuth: Genau. Ich unterstütze ihn dabei, indem ich ihm Feedback gebe, indem ich ihm auch den Horizont noch mal ein bisschen erweitere, weil das ist ja das Wesen der Architektur, dass du den gesamten Überblick hast über das System und aber auch, je nach Architektenrolle, wie sie gelebt ist. Ich habe ja die, dass ich ganz nah beim Team dran bin, auch über die Umsetzung, ich kann es ja lesen, ich weiß, was sie programmieren und da gebe ich ihnen schon Feedback und ich finde es auch ganz wichtig, wenn ich Review-Kommentare schreibe, dann schreibe ich nicht “falsch”, “richtig”, sondern ich stell es ein bisschen in eine Frage rein oder so “Können wir das nicht auch so machen?” oder “Was hältst du von dem? Ist das ein guter Vorschlag” oder so, und wenn man so wertschätzend dann einfach mit dem Entwickler umgeht, dann baut man eben nicht dieses “Ich oben, du unten” auf und das ist mir ganz wichtig, weil das würde das ganze Klima in dem Entwicklungsteam natürlich dann katastrophal verändern.

Götz Müller: Ja, und ich glaube, das lässt sich, und das ist dann auch für mich jetzt ein gutes Schlusswort von dir, das lässt sich eben eins zu eins auf, in Anführungszeichen, klassische Führungsszenarien übertragen, wo es, glaube ich, auch nicht hilfreich ist, wenn ich zum Schluss dann auf die Schulter zeigen muss und da sage: “Guck mal, hier sind es vier Streifen und bei dir sind es auch bloß zwei und deshalb, im Extremfall, habe ich recht.”

Alexander Eisenhuth: Absolut, ja. Also Führung zeichnet sich ja nicht dadurch aus, dass ich meine Position missbrauche, ist eine blöde Antwort darauf, aber Führung ist für mich, du ermöglichst dem Team, möglichst effektiv zu arbeiten, indem du das, was sie machen in die Richtung lenkst, dass sie das Richtige machen.

Götz Müller: Alexander, das war ein wunderbares Schlusswort. Ich danke dir für deine Zeit.

Alexander Eisenhuth: Götz, es hat mir einen Riesenspaß gemacht.

Götz Müller: Das war die heutige Episode im Gespräch mit Alexander Eisenhuth zum Thema Software-Architekturen und Entwicklungsprozesse bei Embedded-Systems. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 334.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.