Holistic Engineering, auf Deutsch ganzheitliches Engineering, bezieht alle nicht-technischen Variablen in technische Entscheidungen ein, damit Architekten und Entwickler das ganze System lösen und nicht nur den Code. Dazu gehören Organisationsdynamik, Anreize in Karrieremodellen, Produktstrategie, Weltgeschehen und die Lebensrealität der Menschen. Wer diese Faktoren ignoriert, schaltet ihren Einfluss nicht aus, sondern macht die entstehende Architektur nur unberechenbarer und schwerer änderbar.
Das Wichtigste in Kürze
- Karriere-Frameworks, die sichtbare Wirkung belohnen, verleiten Entwickler dazu, Code in gemeinsam genutzte Dienste zu schieben, statt saubere Architekturarbeit zu leisten, weil sich ein Link auf einen beliebten Pull Request im Mitarbeitergespräch besser macht als sechs Monate diszipliniertes Refactoring.
- Einen Monolithen, den am Montagmorgen im geplanten Sprint niemand anfassen will, muss trotzdem jemand am Samstagabend reparieren, wenn er in Produktion ausfällt; die Angst vor der Änderung wird so zum größeren Betriebsrisiko als die Änderung selbst.
- Holistic Engineering heißt, nicht-technische Variablen wie Produktstrategie, Gesetzgebung, Lebensereignisse von Mitarbeitenden und Organisationsdynamik in technische Entscheidungen einzubeziehen, denn genau diese Variablen prägen den Code, der entsteht.
- “Cirque du Soleil”-Programmierung, bei der jedes verfügbare Entwurfsmuster und jede neue Bibliothek in ein Feature gestopft wird, zeigt eine Kultur, die Komplexität über Einfachheit stellt und die Wartungskosten weit über das hinaus treibt, was das Feature rechtfertigt.
- Architektur und Teamstruktur müssen zu den fachlichen Produktbereichen passen, denn wenn Teamgrenzen und Systemgrenzen auseinanderfallen, entstehen Blockaden im Arbeitsfluss, die keine technische Entscheidung innerhalb dieser Grenzen ganz auflösen kann.
Warum Architektur von der Best Practice abweicht
Softwarearchitektur sieht selten so aus, wie ein Technologe sie beschreiben würde, wenn man ihn nach dem richtigen Muster fragt. Sie folgt den Kräften, die auf die Menschen wirken, die den Code schreiben. Genau hier setzt Holistic Engineering an, also ganzheitliches Engineering: Karriere-Frameworks, Lieferdruck, Vorbilder und Teamkultur schieben Software in die eine oder andere Richtung, und das Ergebnis hat oft wenig mit einer technischen Entscheidung zu tun.
Vanessa Formicola beschreibt diese Lücke sehr direkt. Frag die Technologen nach der Best Practice, und sie geben die richtige Antwort. Dann schau dir das echte System an, und es sieht völlig anders aus. Der Grund liegt außerhalb des Codes.
Sieben wiederkehrende Architekturmuster tauchen in ganz unterschiedlichen Unternehmen auf, und hinter jedem steckt eine menschliche oder organisatorische Ursache. Es geht nicht darum, die Muster auswendig zu lernen. Es geht darum, das Verhalten zu erkennen, das sie hervorbringt.
Das Kitchen-Sink-Muster: ein gemeinsamer Dienst, der niemandem gehört
Beim Kitchen-Sink-Muster handelt es sich um eine gemeinsame Bibliothek oder einen Utility-Dienst, in den jedes Team Funktionen kippt und für den niemand wirklich verantwortlich ist. Die englische Redewendung “everything but the kitchen sink” trifft es: Alles kommt hinein, ob nützlich oder nicht.
Es beginnt harmlos. Team A will etwas zwischen zwei eigenen Diensten teilen, völlig in Ordnung. Team B nutzt es mit. Dann steigen das dritte, vierte und zehnte Team ein. Die ersten beiden Teams haben vielleicht noch auf Duplikate und Tests geachtet. Die späteren nicht mehr.
Je größer der Dienst wird, desto weniger Leute wissen, was darin steckt, und niemand refaktoriert ihn. Der Explosionsradius bei einem Fehler wird groß, die Komplexität steigt, und die Zahl der Bugs zieht nach. Gemeinsame Verantwortung ohne Verantwortlichen ist die schlechteste Form von Verantwortung.
Zwei nicht-technische Kräfte treiben das an. Die erste ist das Karriere- und Leistungssystem. Viele Frameworks koppeln die Seniorität einer Person an die Reichweite ihrer Wirkung. Eine kleine Funktion in einem unternehmensweit genutzten Dienst ist dann ein bequemer Weg, im Review große Wirkung vorzuweisen. Die zweite ist der Lieferdruck. Bei einer unrealistischen Deadline nehmen Leute Abkürzungen, und einen bestehenden Anknüpfungspunkt wiederzuverwenden geht schneller als eine saubere Integration.
Achte also darauf, was du misst, denn du bekommst, was du misst. Ein Karrieresystem, das sichtbare Reichweite über Teams hinweg belohnt, erzeugt Dienste, die über Teams hinweg wuchern.
Cirque-du-Soleil-Programmierung: Raffinesse als Selbstzweck
Von Cirque-du-Soleil-Programmierung spricht man, wenn schon ein kleines Feature mit jedem Entwurfsmuster, jedem Bibliotheksdetail und jedem frisch erschienenen Tool vollgepackt wird, das der Autor greifen konnte. Wie bei den Akrobaten, auf die der Name anspielt, wird die Kunstfertigkeit zur eigentlichen Show.
Die Kosten fallen doppelt an. Du zahlst mehr, als das Feature gebraucht hätte, und du zahlst noch einmal bei der Wartung. Das tiefere Problem ist kulturell: Coolness zählt mehr als Einfachheit, dabei ist gerade Einfachheit das Zeichen von Professionalität.
Drei Kräfte nähren dieses Muster. Karriere-Frameworks, die von Entwicklern den Nachweis breiter Fähigkeiten verlangen, bringen Leute dazu, alles in einem einzigen Pull Request vorzuführen, denn kaum ein Manager sieht sich sechs Monate Arbeit an, um die Fähigkeit zu bestätigen. Ein angesehenes Vorbild mit Vorliebe für aufwendigen Code gibt den Ton an, und Junioren eifern ihm nach, um ihren eigenen Wert zu zeigen. Und eine toxische Teamkultur des Übertrumpfens, in der Kollegen sich mit noch einem cleveren Detail überbieten, füllt Pull Requests mit Code, den niemand braucht.
Nichts davon ist technische Praxis. Es ist menschliches Verhalten, das sich im Code ausdrückt.
Die Monolith-Konstellation: Angst, die zum Risiko wird
Die Monolith-Konstellation entsteht, wenn ein heikler Dienst zu etwas wird, das niemand mehr anfassen will. Kaum jemand versteht ihn, Tests fehlen meist, jede Änderung ist riskant. Also hören Teams auf, ihn zu ändern, und bauen stattdessen drumherum.
Der Dienst steht wie ein Stern im Zentrum. Teams behandeln ihn als Black Box: Sie wissen, was reingeht und was rauskommt, und hängen neue Dienste an die Ränder. Das Ergebnis ist Komplexität, die nach außen strahlt, und ein Explosionsradius, der immer weiter wächst.
Vanessa bringt es auf den Punkt.
“Wenn du Angst hast, ihn an einem Montagmorgen in einem normalen Sprint zu ändern, dann will ich wissen, was du am Samstagabend machst, wenn er in Produktion ausfällt.”
(Vanessa Formicola)
Die Ursache ist, dass niemand in die Kosten des Nichtstuns investiert. Wenn es für Refactoring keine offizielle Zeit gibt und es persönliches Risiko bedeutet, lässt selbst ein gewissenhafter Entwickler den Dienst lieber in Ruhe, statt seine Karriere zu gefährden. Solange nicht das ganze Unternehmen Zeit dafür einräumt und das Risiko mitträgt, wird es kein Einzelner tun. Das Risiko bleibt einfach liegen.
Die drei Affen: ausblenden, was nicht “technisch” ist
Die Voraussetzung für bessere Architektur ist das Eingeständnis, dass nicht-technische Variablen den Code prägen. Architekten und technische Führungskräfte verhalten sich oft wie die drei Affen: Sie sehen Konflikte zwischen Menschen, Probleme in der Produktabteilung oder im HR, und lassen all das aus ihrer technischen Analyse heraus, weil es ihnen kleinlich oder unwissenschaftlich vorkommt.
Diese Variablen wirken direkt auf den Code. Sie sind es, die ein Projekt über die Deadline hinausschieben. Wer die Augen davor verschließt, bringt sie nicht zum Verschwinden.
Vielleicht kannst du nicht alle ändern. Einige schon, und für alle kannst du gegensteuern. Der erste Schritt ist, die impliziten Kräfte explizit zu machen und den Menschen um dich herum zu helfen, sie ebenfalls zu sehen. Dann wird es legitim, sie mitzudenken.
Holistic Engineering: Lösungen für das ganze System
Holistic Engineering bedeutet, alle nicht-technischen Variablen in deine technischen Entscheidungen einzubeziehen, damit du für das System als Ganzes löst und nicht nur für die technische Sicht. Der Vergleich mit der Medizin passt: Ganzheitliche Medizin behandelt den Menschen und das Umfeld, das die Krankheit ausgelöst hat, nicht nur die Symptome.
Die Variablen lassen sich in externe und interne teilen. Beide sind wichtig, und beide werden meist unterschätzt.
Externe Faktoren liegen außerhalb der Organisation, wirken aber in sie hinein:
- Technologietrends, die du danach bewertest, wie sie sich über die Zeit positiv oder negativ auswirken, statt sie komplett zu übernehmen.
- Geschäftstrends, die zeigen, wohin sich das Produkt entwickelt und welche Teile des Systems sich deshalb ändern könnten.
- Weltgeschehen, von offensichtlichen Terminen wie Black Friday und Weihnachten bis zu dem, was viele Teams übersehen: Wahlen, Gesetzgebung und Entwicklungen wie digitale Souveränität.
Die internen Faktoren verteilen sich auf vier Bereiche, die jeweils eigene Aufmerksamkeit verdienen.
Organisation: ein lebendiges System, das du erbst
Betrachte die Organisation als lebendiges System, das schon vor dir da war und auch nach dir weiterbesteht. Versteh es, damit du darauf aufbauen, abfedern kannst, was sich nicht ändern lässt, und ändern kannst, was sich ändern lässt.
Das Organigramm ist nicht die echte Landkarte. Entscheidend sind die tatsächlichen Macht- und Informationsflüsse und die historischen Gründe, warum das eine als gut und das andere als schlecht gilt. Karriere-Frameworks und Belohnungssysteme kannst du von deiner Position aus kaum ändern, also musst du oft Wege um sie herum finden.
Produkt: was bleibt und was sich ändert
Das Produkt zu verstehen heißt zu wissen, welche Teile sich nie ändern und welche schon. In Health Tech ändern sich manche biologischen Funktionen nicht, diese Teile des Systems bleiben also stabil. Wie sich das Produkt präsentiert und welche Dienste darauf aufsetzen, wird sich dagegen ändern.
Wer den Unterschied kennt, weiß, wo sich Investitionen lohnen. Und Marketingkampagnen können die Prioritäten eines langjährigen Projekts durcheinanderwirbeln, was leicht unterschätzt wird.
Menschen: echte Leben statt austauschbarer Ressourcen
Deine Leute zu verstehen geht über Kopfzahlen und Senioritätsstufen hinaus. Bei deinen wichtigsten Mitarbeitenden musst du wissen, was in ihrem Leben gerade los ist und wie sich das auf die Arbeit auswirkt.
Wer sich scheiden lässt, ein Kind bekommt, einen älteren Angehörigen pflegt oder umzieht, trägt eine Zeit lang anders bei. Zwei Menschen, die sich zerstritten haben, arbeiten vielleicht nicht gut zusammen. Wenn Leute so etwas in angemessenem Rahmen teilen, kannst du gegensteuern, genauso wie beim Risikomanagement in der Software. So zu tun, als wären Menschen austauschbar, ist kein Plan.
Technik: Strategie, Security und ein ehrlicher Ausgangspunkt
Auf der technischen Seite lautet die Frage, ob die Arbeit zu einer technischen Strategie passt und ob es diese Strategie überhaupt gibt. Prüfe, ob die Änderung wirklich ein Schritt in die gewünschte Richtung ist.
Security und Datenschutz gehören früh in die Überlegungen, weil sie ein ansonsten hervorragendes Projekt komplett stoppen können. Sei ehrlich beim Ausgangspunkt: Die tatsächliche Qualität eines Dienstes und die Kosten für Themen auf den unteren Ebenen können eine Schätzung völlig verändern.
Prüfe schließlich, ob Architektur, Produkt und Teams zueinander passen. Wenn eine technische Einschränkung Teams erzwingt, die weder zur Fachdomäne noch zur Architektur passen, bekommst du blockierte Arbeitsflüsse und Risiken, die du im Moment der Entscheidung nicht mehr in der Hand hast.
Bessere Entscheidungen entstehen, wenn mehr Variablen zählen
Geschäftsentscheidungen in der Softwareentwicklung sind wenig verlässlich, und kaum ein Projekt wird pünktlich fertig. Für eine Ingenieursdisziplin ist das ein seltsamer Zustand, und ein Teil der Ursache ist, dass wir die meisten Variablen des Systems aus der Rechnung herauslassen.
Software wird nie eine exakte Wissenschaft sein. Sie kann sich aber anderen Ingenieursdisziplinen annähern, wenn sie mehr von dem einrechnet, was die Ergebnisse tatsächlich bestimmt. Ausgangspunkt ist die Tatsache, dass Menschen Software bauen und jeder menschliche Aspekt in die Entscheidung gehört.
Warum Tester den weitesten Blick brauchen
Der Blick auf das ganze System ist für jeden Technologen wichtig, für Tester noch mehr. Um die Lücken zu finden, muss ein Tester das System verstehen, nicht nur das einzelne Feature, das gerade vor ihm liegt.
Tiefes Fachwissen wird belohnt und ist wertvoll. Seniorität entsteht aber durch Breite: zu verstehen, wie eine Änderung durch das ganze System läuft, statt nur zu sehen, wie gut sie für sich allein aussieht. “Das ist nicht mein Job” ist die falsche Antwort, wenn Organisation, Menschen und Produkt genau das sind, was darüber entscheidet, ob die Software funktioniert.
Häufig gestellte Fragen
Können Karriere- und Leistungs-Frameworks die Struktur einer Codebasis verändern?
Ja. Viele Frameworks verknüpfen die Dienstaltersstufe mit dem Umfang des Einflusses einer Person. Daher wird das Hinzufügen einer kleinen Funktion zu einem unternehmensweit genutzten Dienst zu einer einfachen Möglichkeit, bei einem Review eine große Reichweite geltend zu machen. Ein Link zu einem beliebten Pull-Request macht einen besseren Eindruck als sechs Monate diszipliniertes Refactoring. Pass auf, was du misst: Belohne teamübergreifende Reichweite, und die Dienste breiten sich teamübergreifend aus.
Was läuft schief, wenn sich mehrere Teams einen Utility-Dienst teilen, ohne dass es einen klaren Verantwortlichen gibt?
Er wird zur Kitchen Sink, einem Sammelsurium. Die ersten beiden Teams verfolgen vielleicht noch Duplikate und das Testen, das vierte und das zehnte jedoch nicht. Während der Dienst wächst, wissen immer weniger Leute, was darin steckt, niemand refaktorisiert ihn, Komplexität und Fehleranzahl steigen, und der Auswirkungsbereich, wenn er ausfällt, wird immer größer. Geteilte Verantwortung ohne Verantwortlichen ist die schlimmste Form der Verantwortung.
Ist es eine sichere Strategie, einen anfälligen Legacy-Dienst unberührt zu lassen?
Nein. Wenn es zu riskant ist, einen Dienst an einem Montagmorgen im Rahmen eines geplanten Sprints zu ändern, muss sich trotzdem jemand an einem Samstagabend darum kümmern, wenn er in der Produktion ausfällt. Teams, die aufhören, sich damit zu beschäftigen, fangen an, neue Dienste darum herum aufzubauen, sodass sich die Komplexität nach außen ausbreitet. Die Grundursache liegt in der Unterinvestition in die Kosten des Nicht-Handelns: Für Refactoring wird keine offizielle Zeit eingeplant, und es birgt ein persönliches Karriererisiko.
Warum packen Entwickler kleine Features mit jedem verfügbaren Muster und jeder neuen Bibliothek voll?
Weil die umgebende Kultur das belohnt. Karrierekonzepte, die den Nachweis einer breiten Kompetenz verlangen, drängen die Leute dazu, alles in einem einzigen Pull-Request unter Beweis zu stellen, da ein Vorgesetzter selten sechs Monate Arbeit durchsieht. Ein angesehenes Vorbild mit einer Vorliebe für aufwendigen Code gibt den Ton an, und das Wettrennen um Überlegenheit unter Kollegen tut sein Übriges. Die Kosten schlagen doppelt zu: beim Build und bei der jahrelangen Wartung.
Welche Faktoren außerhalb des Unternehmens sollten bei einer technischen Entscheidung berücksichtigt werden?
Technologische Trends, geschäftliche Trends und weltweite Ereignisse. Trends sollten eher auf ihre positiven oder negativen Auswirkungen im Laufe der Zeit hin bewertet werden, anstatt sie pauschal zu übernehmen. Die geschäftliche Ausrichtung zeigt an, welche Teile des Systems sich wahrscheinlich verändern werden. Abgesehen von offensichtlichen Spitzenzeiten wie dem Black Friday und Weihnachten übersehen Teams häufig Wahlen, Gesetzgebungsprozesse und Veränderungen wie digitale Souveränität.
Sollten die persönlichen Umstände der Teammitglieder Teil der Planung sein?
Bei wichtigen Mitwirkenden: ja. Jemand, der gerade eine Scheidung durchmacht, ein Kind bekommt, einen älteren Verwandten pflegt oder umzieht, leistet für eine gewisse Zeit einen anderen Beitrag, und zwei Personen, die sich zerstritten haben, arbeiten möglicherweise nicht gut zusammen. Wenn Menschen solche Dinge angemessen mitteilen, kannst du Gegenmaßnahmen ergreifen, genauso wie beim Risikomanagement in der Softwareentwicklung. Menschen als austauschbare Ressourcen zu behandeln, ist kein Plan.
Warum werden so wenige Softwareprojekte pünktlich ausgeliefert?
Weil die meisten Variablen des Systems bei der Berechnung außer Acht gelassen werden. Organisationsdynamik, Produktstrategie, das Leben der Menschen und weltpolitische Ereignisse werden als nebensächlich oder unwissenschaftlich abgetan, dabei sind genau diese Faktoren es, die ein Projekt über seinen Termin hinausverzögern. Software wird niemals eine exakte Wissenschaft sein, aber wenn man mehr von dem berücksichtigt, was die Ergebnisse tatsächlich beeinflusst, rückt sie näher an andere Ingenieursdisziplinen heran.
Ist ganzheitliches Denken für Tester wichtiger als für andere Rollen?
Es ist für jeden Technologen wichtig und für Tester sogar noch wichtiger, denn Lücken werden nur für jemanden sichtbar, der das System versteht und nicht nur die isolierte Funktion vor sich. Fachliche Tiefe ist wertvoll und wird belohnt, aber Erfahrung entsteht durch Breite: zu erkennen, wie sich eine Änderung im gesamten System auswirkt. „Das ist nicht meine Aufgabe“ ist hier die falsche Antwort.
