Ganzheitliches Engineering bedeutet, alle nicht-technischen Variablen in technische Entscheidungen einzubeziehen, damit Architekten und Entwickler das gesamte System im Blick haben und nicht nur den Code. Zu diesen Variablen gehören organisatorische Dynamiken, Anreizstrukturen für die Karriere, Produktstrategie, weltpolitische Ereignisse und die Lebensrealitäten der Menschen. Sie zu ignorieren, beseitigt ihren Einfluss nicht; es macht die daraus resultierende Architektur lediglich weniger vorhersehbar und schwerer zu ändern.
Das Wichtigste in Kürze
- Karriere-Frameworks, die sichtbare Ergebnisse belohnen, bringen Entwickler dazu, Code zu gemeinsamen, weit verbreiteten Diensten beizusteuern, anstatt die richtige Architekturarbeit zu leisten – denn ein Link zu einem beliebten Pull-Request lässt sich bei einer Review-Beurteilung leichter präsentieren als sechs Monate diszipliniertes Refactoring.
- Ein Monolith, den sich am Montagmorgen in einem geplanten Sprint niemand anzurühren wagt, muss dennoch am Samstagabend bearbeitet werden, wenn er in der Produktion ausfällt – wodurch die Angst vor Veränderungen zu einem größeren operativen Risiko wird als die Veränderung selbst.
- Ganzheitliches Engineering bedeutet, nicht-technische Variablen – darunter Produktstrategie, Gesetzgebung, Lebensereignisse der Mitarbeiter und Organisationsdynamik – in technische Entscheidungen einzubeziehen, denn diese Variablen prägen direkt den Code, der geschrieben wird.
- „Cirque de Soleil“-Programmierung, bei der jedes verfügbare Entwurfsmuster und jede neue Bibliothek in eine Funktion gestopft wird, signalisiert eine Kultur, die Komplexität gegenüber Einfachheit belohnt und die langfristigen Kosten der Wartung über das Maß hinaus in die Höhe treibt, das die Funktion rechtfertigt.
- Architektur und Teamstruktur müssen auf die Produktbereiche abgestimmt sein, denn eine Diskrepanz zwischen Teamgrenzen und Systemgrenzen führt zu Blockaden im Arbeitsfluss, die durch keine technische Entscheidung innerhalb dieser Rahmenbedingungen vollständig behoben werden können.
Warum Architektur von Best Practices abweicht
Softwarearchitektur entspricht selten der Antwort, die ein Technologe geben würde, wenn man ihn nach dem richtigen Muster fragt. Sie folgt vielmehr den Einflüssen, denen die Leute ausgesetzt sind, die den Code schreiben. Karrierebedingungen, Lieferdruck, Vorbilder und Teamkultur treiben die Software in die eine oder andere Richtung, und das Ergebnis hat oft wenig mit einer technischen Entscheidung zu tun.
Vanessa Formicola beschreibt diese Kluft ganz direkt. Frag die Technologen, was Best Practice ist, und sie geben die richtige Antwort. Dann schau dir das tatsächliche System an, und es sieht ganz anders aus als das, was sie beschrieben haben. Der Grund dafür liegt außerhalb des Codes.
Sieben immer wiederkehrende Architekturmuster tauchen in verschiedenen Unternehmen auf, und hinter jedem steckt eine menschliche oder organisatorische Ursache. Es geht nicht darum, die Muster auswendig zu lernen, sondern zu lernen, die Verhaltensweisen zu deuten, die sie hervorbringen.
Das „Kitchen Sink“-Muster: Ein gemeinsamer Dienst, für den niemand verantwortlich ist
Das „Kitchen Sink“-Muster ist eine gemeinsame Bibliothek oder ein Dienst, in den jedes Team Funktionen hineinwirft und für den niemand wirklich verantwortlich ist. Der englische Ausdruck „everything but the kitchen sink“ bringt es auf den Punkt: Man stopft alles hinein, was einem einfällt, egal ob nützlich oder nicht.
Es fängt klein an. Team A möchte etwas zwischen zwei seiner Dienste teilen, was völlig in Ordnung ist. Team B beschließt, es wiederzuverwenden. Dann machen das dritte, vierte und zehnte Team mit. Die ersten beiden Teams haben vielleicht Duplikate und das Testen nachverfolgt. Die späteren Teams tun das nicht.
Je größer der Dienst wird, desto weniger Leute wissen, was darin steckt, und niemand refaktorisiert ihn. Der Auswirkungsbereich, wenn etwas kaputtgeht, wird groß, die Komplexität steigt und die Anzahl der Bugs folgt. Geteilte Verantwortung ohne Verantwortlichen ist die schlimmste Form der Verantwortung.
Zwei nicht-technische Faktoren treiben das voran. Der eine ist das Karriere- und Leistungssystem. Viele Rahmenwerke besagen, dass der Senioritätsgrad einer Person vom Umfang ihres Einflusses abhängt – daher wird das Hinzufügen einer kleinen Funktion zu einem unternehmensweit genutzten Service zu einer einfachen Möglichkeit, bei einer Review-Beurteilung einen weitreichenden Einfluss geltend zu machen. Die andere ist der Lieferdruck. Unter einer unrealistischen Deadline nehmen die Leute Abkürzungen, und die Wiederverwendung eines bestehenden Anbindungspunkts ist schneller als eine ordentliche Integration.
Sei vorsichtig bei der Messung, denn du bekommst, was du misst. Ein Karrieresystem, das sichtbare Reichweite über Teams hinweg belohnt, wird zu Services führen, die sich über Teams hinweg ausbreiten.
„Cirque de Soleil“-Programmierung: Raffinesse um der Raffinesse willen
Von „Cirque de Soleil“-Programmierung spricht man, wenn selbst eine kleine Funktion mit jedem Designmuster, jedem Bibliotheksdetail und jedem neu veröffentlichten Tool vollgestopft ist, auf das der Autor zurückgreifen konnte. Wie bei den Akrobaten, auf die sich der Name bezieht, wird die Raffinesse zum Mittelpunkt der Show.
Die Kosten fallen doppelt an. Du zahlst mehr, als die Funktion ursprünglich erforderte, und du zahlst noch einmal für die Wartung. Das tiefer liegende Problem ist kultureller Natur: Coolness wird höher geschätzt als Einfachheit, dabei ist Einfachheit das Kennzeichen von Professionalität.
Drei Faktoren nähren dieses Muster. Karriere-Frameworks, die von Entwicklern verlangen, die Breite ihrer Fähigkeiten unter Beweis zu stellen, drängen die Leute dazu, dies in einem einzigen Pull-Request zu demonstrieren, denn ein Manager überprüft selten sechs Monate Arbeit, um zu bestätigen, dass jemand über die entsprechenden Fähigkeiten verfügt. Ein angesehenes Vorbild mit einer Vorliebe für aufwendigen Code gibt den Ton an, und Nachwuchskräfte ahmen ihn nach, um ihren eigenen Wert zu beweisen. Und eine toxische Teamkultur des „Sich-Übertrumpfen-Wollens“, in der Kollegen darum wetteifern, noch eine clevere Sache hinzuzufügen, füllt Pull-Requests mit Code, den niemand braucht.
Nichts davon ist technische Praxis. Es ist menschliches Verhalten, das sich durch Code ausdrückt.
Die Monolith-Konstellation: Angst, die zum Risiko wird
Die Monolith-Konstellation entsteht, wenn ein sensibler Dienst zu etwas wird, das niemand mehr anfassen will. Er wird kaum verstanden, ist meist ungetestet und Änderungen sind ein Risiko – also hören Teams auf, ihn zu ändern, und fangen stattdessen an, um ihn herum zu bauen.
Der Dienst steht wie ein Stern im Zentrum. Teams behandeln ihn wie eine Black Box: Sie wissen, was reinkommt und was rauskommt, und sie verkabeln neue Dienste an den Rändern. Das Ergebnis ist Komplexität, die nach außen strahlt, und ein Explosionsradius, der immer weiter wächst.
Vanessa bringt die Kernfrage unverblümt auf den Punkt.
Wenn du Angst hast, ihn an einem Montagmorgen in einem regulären Sprint zu ändern, möchte ich wissen, was du am Samstagabend tun wirst, wenn er in der Produktion ausfällt. — Vanessa Formicola
Die Ursache hierfür ist eine zu geringe Investition in die Kosten des Nichtstuns. Wenn für Refactoring keine offizielle Zeit vorgesehen ist und es mit persönlichem Risiko verbunden ist, wird selbst ein gewissenhafter Entwickler den Service lieber in Ruhe lassen, anstatt seine eigene Karriere zu gefährden. Wenn nicht das gesamte Unternehmen Zeit dafür aufbringt und das Risiko akzeptiert, wird es kein Einzelner tun. Das Risiko bleibt einfach bestehen und wird ignoriert.
Die drei Affen: Ignorieren, was nicht „technisch“ ist
Die Vorbedingung für eine bessere Architektur ist das Eingeständnis, dass nicht-technische Variablen den Code beeinflussen. Architekten und technische Führungskräfte verhalten sich oft wie die drei Affen: Sie sehen Probleme zwischen den Mitarbeitern, in der Produktabteilung, in der Personalabteilung – und lassen diese Probleme aus ihrer technischen Analyse heraus, weil sie sie für belanglos oder unwissenschaftlich halten.
Diese Variablen haben direkten Einfluss auf den Code. Sie sind es, die ein Projekt über den Termin hinaus verzögern. Die Augen davor zu verschließen, lässt sie nicht verschwinden.
Vielleicht kannst du nicht alle ändern. Du kannst einige ändern und bei allen Abhilfemaßnahmen ergreifen. Der erste Schritt besteht darin, die impliziten Kräfte explizit zu machen und den Menschen um dich herum zu helfen, sie ebenfalls zu erkennen, damit es legitim wird, sie zu berücksichtigen.
Ganzheitliches Engineering: Lösungen für das gesamte System
Ganzheitliches Engineering bedeutet, alle nicht-technischen Variablen in deine technischen Entscheidungen einzubeziehen, sodass du Lösungen für das gesamte System findest und nicht nur aus technischer Sicht. Die medizinische Analogie passt hier gut: Ganzheitliche Medizin behandelt den Menschen und das Umfeld, das die Krankheit verursacht hat, nicht nur die Symptome.
Die Variablen lassen sich in externe und interne Gruppen unterteilen. Beide sind wichtig, und beide werden meist zu wenig berücksichtigt.
Externe Faktoren liegen außerhalb der Organisation, wirken sich aber auf sie aus:
- Technologietrends, die du eher auf ihre positiven oder negativen Auswirkungen im Laufe der Zeit hin bewertest, anstatt sie pauschal zu übernehmen.
- Geschäftstrends, die dir zeigen, in welche Richtung sich das Produkt entwickelt und welche Teile des Systems sich daher möglicherweise ändern werden.
- Weltgeschehen, von offensichtlichen Ereignissen wie dem Black Friday und Weihnachten bis hin zu solchen, die viele Teams übersehen: Wahlen, Gesetzgebung und Veränderungen wie digitale Souveränität.
Interne Faktoren lassen sich in vier Bereiche unterteilen, die gesonderte Beachtung verdienen.
Organisation: ein lebendiges System, das du übernimmst
Behandle die Organisation als ein lebendiges System, das schon vor deiner Ankunft existierte und auch nach deinem Weggang weiterbestehen wird. Verstehe es, damit du darauf aufbauen, das, was du nicht ändern kannst, abmildern und das, was du ändern kannst, tatsächlich ändern kannst.
Das Organigramm ist nicht die eigentliche Landkarte. Was zählt, sind die tatsächlichen Macht- und Informationsflüsse sowie die historischen Gründe, warum das eine als gut und das andere als schlecht angesehen wird. Karriererahmen und Belohnungssysteme lassen sich von deiner Position aus nur schwer ändern, daher musst du oft Wege finden, sie zu umgehen.
Produkt: Was bleibt und was ändert sich
Das Produkt zu verstehen bedeutet zu wissen, welche Teile sich nie ändern und welche schon. In der Health-Tech-Branche ändern sich manche biologischen Funktionen nicht, daher bleiben diese Teile des Systems stabil. Wie sich das Produkt präsentiert und welche Dienste darauf aufbauen, wird sich ändern.
Wenn du den Unterschied kennst, weißt du, wo du investieren musst. Und Marketingkampagnen können bei einem langfristig angelegten Projekt die Prioritäten neu ordnen – ihre Wirkung wird daher leicht unterschätzt.
Menschen: Echte Leben, keine austauschbaren Ressourcen
Deine Mitarbeiter zu verstehen, geht über Personalzahlen und Dienstaltersbezeichnungen hinaus. Bei deinen wichtigsten Mitarbeitern musst du wissen, was in ihrem Leben gerade passiert und wie sich das auf die Arbeit auswirkt.
Jemand, der sich scheiden lässt, ein Kind bekommt, einen älteren Verwandten pflegt oder umzieht, leistet für eine gewisse Zeit einen anderen Beitrag. Zwei Menschen, die sich zerstritten haben, arbeiten möglicherweise nicht gut zusammen. Wenn die Leute solche Dinge angemessen mitteilen, kannst du Gegenmaßnahmen ergreifen – genauso, wie du Risiken im Software-Code verwaltest. So zu tun, als seien Menschen austauschbar, ist kein Plan.
Technik: Strategie, IT-Sicherheit und ehrliche Ausgangspunkte
Auf der technischen Seite solltest du fragen, ob die Arbeit mit einer technischen Strategie übereinstimmt und ob es diese Strategie überhaupt gibt. Überprüfe, ob die Änderung ein echter Schritt in die beabsichtigte Richtung ist.
IT-Sicherheit und Datenschutz müssen frühzeitig in die Überlegungen einfließen, da sie ein ansonsten hervorragendes Projekt komplett zum Scheitern bringen können. Seid ehrlich, was euren Ausgangspunkt angeht: Die tatsächliche Qualität eines Dienstes und die Kosten für untergeordnete Aspekte können eine Schätzung komplett verändern.
Prüft schließlich, ob Architektur, Produkt und Teams aufeinander abgestimmt sind. Wenn eine technische Einschränkung dazu führt, dass Teams eingesetzt werden, die nicht zum Fachgebiet oder zur Architektur passen, kommt es zu Blockaden im Arbeitsablauf und zu Risiken, die ihr zum Zeitpunkt der Entscheidung nicht kontrollieren könnt.
Bessere Entscheidungen entstehen durch die Berücksichtigung weiterer Variablen
Geschäftliche Entscheidungen in der Softwareentwicklung haben eine geringe Zuverlässigkeit, und fast kein Projekt wird pünktlich ausgeliefert. Das ist ein ungewöhnlicher Zustand für eine ingenieurwissenschaftliche Disziplin, und ein Teil der Ursache liegt darin, dass wir die meisten Variablen des Systems bei der Berechnung außer Acht lassen.
Software wird niemals eine exakte Wissenschaft sein. Sie kann sich anderen Ingenieursbereichen annähern, indem sie mehr von dem berücksichtigt, was die Ergebnisse tatsächlich beeinflusst – ausgehend von der Tatsache, dass Menschen Software entwickeln und dass jeder menschliche Aspekt in die Entscheidung einfließen muss.
Warum Tester den weitesten Blickwinkel brauchen
Die Perspektive auf das Gesamtsystem ist für jeden Technologen wichtig, und für Tester ist sie noch wichtiger. Um die Lücken zu finden, muss ein Tester das System verstehen, nicht nur die isolierte Funktion, die er gerade vor sich hat.
Fundiertes Fachwissen wird belohnt und ist wertvoll. Erfahrung entsteht durch Breite: zu verstehen, wie sich eine Änderung im gesamten System auswirkt, anstatt nur zu sehen, wie gut sie für sich genommen aussieht. „Das ist nicht mein Job“ ist die falsche Antwort, wenn die Organisation, die Menschen und das Produkt genau die Faktoren sind, die darüber entscheiden, ob die Software funktioniert.
