Advisory · Diagnose-Methodik
Warum Ihre Zahlen trügen
Gemeint sind die berichteten: grüne Dashboards, übererfüllte Story Points. Und trotzdem steigen die Kosten, Quartal für Quartal.
Dort, wo Ihr Code arbeitet, trügen Messungen nicht; erst der Bericht lernt es später. Wie ein solches Messen aussieht, führt Ihnen diese Seite an sich selbst vor: Die Leiste am oberen Rand liest die Prozesse live aus und legt ihre Werte offen. Was Reporting hinter grünen Ampeln verbirgt, lässt sich sichtbar und rechenbar machen.
Die Werte oben zeigen, wie wenig diese Seite braucht; was wenig braucht, kostet wenig im Betrieb.
Diese Seite dokumentiert eine Arbeitsweise, kein Angebot. Mandate nehme ich nicht an.
Der verdeckte Schmerz
Was Sie sehen, sind die Zahlen, die Ihnen berichtet werden: Velocity steigt, Sprints liefern wie angekündigt, und das Dashboard leuchtet grün. Was der Betrieb Ihrer Systeme Sie wirklich kostet, steht in keinem Sprint-Review. Diese eine Zahl steigt trotzdem mit.
Das ist nicht etwa Betrug, das ist Architektur. Reporting misst Aktivität, nach Ursachen fragt es dabei nicht. Je mehr Schichten ein System hat, desto mehr gibt es zu berichten und desto weniger ist vom Ganzen zu sehen.
Die Kosten dahinter
Cloud-Rechnungen wachsen schneller als der Umsatz. Releases brauchen Wochen, weil niemand mehr das ganze System versteht. Und das Team verbringt die Hälfte seiner Zeit damit, den Unterbau zu warten, statt das Produkt zu bauen.
Jede dieser Positionen hat eine Ursache. In keiner Auswertung taucht sie auf, wohl aber in Ihrem System, und dort lässt sie sich finden und benennen. Nur sucht dort kaum jemand, weil alles in lauter einzelne Teams zergliedert ist und jedes für sich grüne Zahlen meldet.
Was die Diagnose sichtbar macht
Ich stelle die Frage, die Ihr Reporting nicht stellt: Warum kostet das so viel, dauert so lange und bricht beim kleinsten Anstoß? Die Antwort hat zwei Stufen. Beide beginnen mit Diagnose, nicht mit Umbau.
Stufe eins Optimierung des Bestehenden
Besser machen, was da ist, ohne Wegwerfen: kleiner Eingriff, schnelle Wirkung, mehr nicht.
Stufe zwei Die schlanke Lösung für die Zukunft
Im Dauerbetrieb günstiger, schneller und zuverlässiger. Ein besseres Fundament statt einer Reparatur.
Der Aufwand verteilt sich anders, als man denkt:
Das Bestehende zu optimieren ist die aufwändigere Arbeit, nicht die einfachere: Ich muss mich erst in ein über Jahre gewachsenes, individuelles System eindenken, mit all seinen Schrulligkeiten. Eine neue Lösung baue ich auf klaren Prinzipien, reduziert aufs Notwendige, ohne diese Archäologie.
Die Diagnose zeigt das Maximum: wie schlank, schnell und günstig ein System sein könnte, oft mit FreeBSD am oberen Ende der Skala. Ob ein Team bis zur vollen Effizienz geht oder den pragmatischen Schritt dahin wählt, bleibt seine Entscheidung, und zwar eine bewusste.
Die Diagnosen
Vier Diagnosen, und jede beginnt beim Symptom:
Nutzer warten Performance- & Health-Audit
Warum die Anwendung langsam ist, Warnungen wirft und unter Last kippt.
Releases dauern Architektur-Review
Ob die Architektur trägt – und wo Schichten wegkönnen.
Die Marge schrumpft Komplexitäts- & Kosten-Diagnose
Warum die Kosten seit dem letzten Umbau immer weiter steigen, gerechnet bis zum Maximum erreichbarer Ersparnis.
Die Unterschrift fehlt Vibe-Coding-Diagnose
KI-Code, den niemand mehr verantwortet, und wie Rollen, Veto-Ränge und messungsgedeckte Freigabe das ändern.
Jede Diagnose endet mit einem schriftlichen Befund: Ursachen, Belege, Maßnahmen, so formuliert, dass ein Team ihn ohne externe Hilfe umsetzen und betreiben kann.
Die Einwände
„Dann entsteht Abhängigkeit.“
Einfachheit ist das Gegenteil von Abhängigkeit. Eine Lösung aus Standardbausteinen versteht ein Linux-Administrator in wenigen Tagen; es entsteht keine Spezialisten-Insel und kein teures Unikat. Die Kontrolle bleibt beim Betreiber.
„Das Neue ist doch das Risiko.“
Die schlanke Lösung ist für jeden, der FreeBSD und Jails kennt, sofort erschließbar: lückenlos dokumentiert, stabil, von einer weltweiten Community getragen. Wer Linux spricht, hört in FreeBSD einen Dialekt, keine Fremdsprache. Worauf verlässt man sich am Ende lieber: auf eine individuell gewachsene Umgebung, die nur wenige durchschauen, oder auf ein Fundament, das sich seit Jahrzehnten bewährt?
„Docker ist doch auch dokumentiert.“
Das Format ja – die Engine, die CLI. Was in den Images steckt, nicht: fremde Base-Layer, Pakete aus wandernden Repos, „latest“-Tags, die morgen anders sind. Ein dokumentiertes Verpackungsformat um einen undokumentierten Inhalt. Reproduzierbar freilich nur bis zum nächsten Build. Dazu schreibt jedes Image sein eigenes Linux-Userland vor, jedes mit eigener Sicherheitsdoktrin. Ein FreeBSD-Basissystem ist ein Quellbaum mit geprüfter Herkunft und nachvollziehbarer Betriebshistorie, also Isolation, deren Inhalt sich tatsächlich verantworten lässt, statt einer Lieferkette, die niemand mehr durchschaut. Genau das kompensieren die immer teureren Werkzeuge und Teams, die dafür nötig werden.
Wie ich solche Fragen begründe, steht öffentlich im Blog und im Buch – dieselbe Methode, an echten Systemen vorgerechnet, zum Nachrechnen.
Haltung
Urteil, kein Rezept: Ich arbeite ergebnisoffen. Manchmal ist die Antwort FreeBSD und Jails, manchmal bleibt es Linux, manchmal sogar Docker. Die Methode ist keine Tagesform: Sie steht auf 371 Seiten gedruckt, „Integrated by Design“, erschienen 2026.
Ich rede niemandem nach dem Mund. Ich erarbeite, erläutere und dokumentiere – freundlich, aber bestimmt, auch wenn das Ergebnis unbequem ist. Wer Bestätigung sucht, ist hier falsch. Wer die Ursache finden will, richtig.
Rechnet sich eine Diagnose nicht, sage ich das offen, bevor sie beginnt, nicht auf Seite 40 eines Berichts.
Ich nehme Komplexität heraus, nicht hinzu.
Stand
Diese Seite dokumentiert eine Arbeitsweise, kein Angebot. Mandate nehme ich nicht an.