[Folie 1] Liebe Freunde der gepflegten Programmierung In diesem Vortrag möchte ich Menschen mit geringer IT-Erfahrung verdeutlichen warum Software Architekten sinnvoll ist, und andeuten welche Aufgaben ein Software Archtitekt übernimmt. [Folie 2] Ich hoffe Sie kennen alle Projekte die einfach Spass machen, weil diese Projekte flutschen. Die Einarbeitung ist einfach, weil der Programmierstil konsistent und einheitlich ist. Bei Verbesserungen oder Weiterentwicklungen wissen Sie schnell an welchen Stellen Sie Ihre Änderungen ansetzen müssen. Die Schnittstellen sind einfach, konsistent und slbst erklärend. Die Korrektheit ist leicht nachweisbar - auch weil das Logging und Monitoring in sich logisch ist. Die Anforderungen sind explizit erwähnt und deurch automatisierte Tests abgedeckt. Sie haben keine Angst dass Sie versteckte Anforderungen übersehen. [Folie 3] Leider machen die meisten von uns in der täglichen Arbeit die gegenteilige Erfahrung. Sie haben bei Änderungen Angst ausversehen schon bestehende teilweise nicht explizit erwähnte Anforderungen zu verletzten. Der Programmierstil ist uneinheitlich, da viele Entwickler mit jeweils eigenen Stil mitentwickeln. Mit zunehmender Dauer wird Software immer komplexer da der Mut und das Vertrauen fehlt bestehenden Code zu ändern. Der Unterschied liegt meist darin, dass im ersteren Fall die Softwarearchitektur explizit entwickelt, kommuniziert und überwacht wird. Eine zentrale Aufgabe eines Softwarearchitekten ist es den Beteiligten eine Anleitung zu geben, wie sie Änderungen und Erweiterungen anzugehen haben. [Folie 4] Eine Möglichkeit eine Architektur zu bewerten, ohne eine Ahnung von Technik zu haben, ist es das Team auszutauschen. Sind die Einarbeitungszeiten extrem lange zeugt dies von schlechter Architektur. Sind die Einarbeitungszeiten kurz, ist dies ein Indiz von guter Architektur. An denen Projekten an denen Ich persönlich beteiligt war, wie die Materialbeschaffung der Bundeswehr und die Versteigerung der Mobilfunkfrequenzen ist es ein enormes Risiko, wenn diese Aufgabe nur ganz wenige Superspezialisten ausgeführt werden können. Die innere Sicherheit oder Aufbau der digitalen Infrastruktur darf nicht von den Gehirnzellen einzelner Individuen abhängig sein. Schon alleinig deswegen ist Einfachheit eines der wichtigsten Prinzipien von Softwarearchitekten. Folie [Folie 5] So wird in fast jedem Lehrbuch über Softwarearchitektur, das Prinzip der Einfachheit gepriesen. Auf die 5 Minuten im erwähnten Zitat würde ich mich nicht versteifen. Aber das Grundprinzip teile ich. Nichts ist so kompliziert, dass man es auch einfach erklären kann. Und dies ist die eigentliche Faszination des Berufs als Software Entwickler. Dies widerstrebt natürlich meist dem Gewinnstreben der Softwarefirmen, die meist den Kunden in Abhängigkeit treiben wollen. Es gibt übrigens Firmen deren Geschäftsmodell ist es die Architekturlösungen von fremden Firmen zu begleiten und zu bewerten. Die Vergabepraxis deutscher Behörden wird sich mittelfristig ändern müssen und diese Firmen nutzen, bzw. noch besser entsprechende Experten selbst beschäftigen. Teams, die sich der agilen Methodik verschrieben haben, setzen absichtlich ihre Mitarbeiter immer an neuen Themen ein und simulieren damit den Austausch des Teams. Bei mir persönlich war es ein Schlaganfall mit gleichzeitigen Ausfall meines technischen Backups. So musste ein ehemaliger Arbeitskollege, der schon 4 Jahre aus dem Projekt draussen war meine Arbeit übernehmen. Allerdings hatte ich das Glück von den Ärzten auf diesen Tag und den nachfolgenden schweren Monaten gut vorbereitet gewesen zu sein. [Folie 6] Ich versuche nun anhand einer elektronischen Zahnbürste den Unterschied zwischen guter und schlechter Softwarearchitektur aufzuzeigen. Diese Zahnbürste ist gleichzeitig ein Beispiel von extrem guter und extrem schlechter Architektur. [Folie 7] Ich habe für diese Bürste einen Bausteinplan erstellt, wie Ich ihn für sinnvoll halte. Die Module nannte ich Kern, Strom und Bürsten. Die sinnvolle Einteilung der Einzelbausteine in Module ist Aufgabe des Softwarearchitekten. Beachten Sie dass diese Bürste nur zu Demonstationszwecken dient. In Softwareprojekten haben wir i.a. mehr als tausend einzelne Bausteine. Deshalb ist die Einteilung in Module, so wichtig um das Softwareprodukt beherrschbar zu machen. Module mit nur ein bis 2 Bausteine wie bei dieser Demo entsprechen nicht der Realität. Im Kern befindet sich der eigentliche Stab mit einem Aufsatz. Die Bürsten müssen zum Aufsatz passen. Dies erfolgt über eine gemeinsame Schnittstelle. Ich nenne die Schnittstelle I_Buerste. Das I steht für Interface. §s ist u.a. die Aufgabe des Softwarearchitekten für eine einheitliche und Konsistente Namen zu achten umd zu kommunizieren. Ob man dies jetzt über sinnvolle Namen, Annotations oder andere Methoden macht, darüber kann man streiten. Entscheidend ist die Konsistenz. Bringt jeder Programmierer seinen eigenen gewohnten Stil ein, ehrält man am Ende ein Softwareprodukt das extrem schwer wartbar ist. [Folie 8] Die Module sind so zu entwerfen, dass wenn Modul A auf Modul B zugreift, darf Modul B nicht auf Modul A zugreifen. Zyklische Abhängigkeiten sind unbedingt zu vermeiden. Eine lose Kopplung zwischen den Modulen und eine hohe Kohäsion innerhalb der Module ist das Ziel einer guten Softwararchitektur. [Folie 9] Kennt Modul A das Modul B und beide benötigen brmötigen denselben Baustein S, dann muss der Baustein S entweder in B implementiert sein - [Folie 10] oder es wird ein neues Modul C eingeführt, das den Baustein C enthält. [Folie 11] Die Schnittstelle I_Buerste gehört übrigens in das Modul Bürste. Das Modul Kern kennt das Modul -Bürste, von daher ist dies kein Problem. Da der Aufsatz im Modul Kern, nicht auf eine konkrete Klasse aus dem Modul Bürste verweist - sondern auf eine Schnittstelle sind die Module Kern und Bürste lose gekoppelt. Die lose Kopplung zeigt sich darin, dass man die Bürsten einfach austauschen kann. Das Problem dabei ist dass man die Kopplung messen kann, die Kohäsion leider nicht. Rein theoretisch könnte man die Bürsten auch nach der Farbe gruppieren. Welche Bausteine logisch zusammengehören ist Fachwissen und kann i.a. nicht durch Werkzeuge unterstützt werden. Was der Design des Kopfes betrifft, so ist die Zahnbürste ein Beispiel für eine gelungene und sinnvolle Architektur. [Folie 12] Anders sieht es aber mit dem Akku aus. Wenn Sie den Stab genau anschauen erkennen Sie dass ein Akku enthalten ist. Schliesslich erkennt man ein Licht und die Alltagserfahrung sagt, dass wo was leuchtet auch Strom vorhanden sein muss. Das eigentliche Problem ist dass Akku und Stab fest miteinander verbaut sind. Mit hoher Wahrscheinlichkeit ist dies keine Schlamperei sondern Absicht. Ich vermute es war ein BWLer oder ein Jurist, der dies anordnete. Jetzt ist bekannt dass der Akku ein Verschleissteil ist. Der Kunde ist gezwungen, wenn er auf dem Komfort einer elektronischen Zahnbürste nicht verzichen will - bei regelmässiger Nutzung alle paar Jahre eine ganz neue elektronische Zahnbürste zu kaufen. Ob diese Strategie langfristig Erfolg hat, ist eine andere Frage. Bei einigen Kunden siegt die Bequemlichkeit, andere fühlen sich hintergangen und waerden von einm erneuten Kauf zurückschrecken. Vertrauen in eine Firma kann man nicht messen. Volkswirtschaftlich und ökologisch gesehen ist dieses Verhalten aber extrem schädlich. Funktioniert die Bürste nicht mehr, haben Sie extreme Schwierigkeiten die Ursache zu erkennen und zu testen. Da Sie den Akku nicht herausnehmen können, können Sie diesen auch nicht testen. Das Beispiel zeigt auch dass das Testen kein nachgelagerter Prozess sein darf, sondern schon im Design berücksichtigt werden muss.