Arda Akgür
Dieser Text erklärt nicht, wie man perfekte Systeme baut. Ich glaube auch nicht, dass es perfekte Systeme gibt.
Das sind Prinzipien, die ich über Jahre beim Systembau, beim Codieren, beim Unterrichten und beim Beobachten von scheiternden laufenden Systemen gesammelt habe.
Für mich ist System Engineering Problemlösen vor Technikauswahl.
1. Das Wichtigste in einem System ist Stabilität
Mit welcher Grundlogik du ein System auch gebaut hast — schreib diese Logik nicht ständig um, sobald das System läuft.
Parameter dürfen sich ändern. Kleine Verbesserungen sind erlaubt. Bugs werden behoben. Aber wenn du die Kernregeln mitten auf dem Weg ständig umschreibst, hast du nach einer Weile weder das ursprüngliche noch das neue Design.
Ist eine Major-Änderung nötig, ist manchmal der richtige Schritt nicht, das aktuelle System zu erzwingen — sondern eine neue Version zu starten.
Ändere die Spielregeln nicht mitten im Spiel.
2. Baue das einfachste System, das funktioniert
Plane nicht schon am ersten Tag für Millionen Nutzer, Fünf-Jahres-Scale und Probleme, die noch nicht existieren.
Das ist meist kein Engineering. Das ist YouTube-Architektur.
Baue das verständliche System, das das heutige Problem so schnell wie möglich löst und wirklich läuft.
Trifft dich eines Tages ein echtes Scale-Problem, ist das ein gutes Problem. Es bedeutet, das System hat lange genug gelebt, um dort anzukommen.
Wenn V2 nötig ist, kannst du V2 anders bauen.
3. Halte dich vom Status quo fern
Dass alle eine Technologie oder Architektur nutzen, heißt nicht, dass sie für dein Problem richtig ist.
„Industry standard sagt das“ ist für sich keine technische Begründung.
Definiere zuerst das Problem. Schau dann, was es am besten löst.
Ist die Antwort das, was alle nutzen — nutze es. Wenn nicht, hab keine Angst, anders zu handeln.
Sei dem Problem treu, nicht den Tools.
4. Triff keine wichtigen Entscheidungen hungrig oder erschöpft
Das wichtigste Werkzeug eines Architekten ist nicht der Computer. Es ist der Geist.
Hunger und ernsthafte Erschöpfung können Entscheidungsqualität zerstören. Eine Lösung, die du normalerweise ablehnen würdest, wirkt plötzlich „gut genug“. Du gehst unnötige Risiken ein, wirst leicht gereizt oder akzeptierst eine falsche Entscheidung nur, um fertig zu werden.
Manchmal wirkt dieser Zustand sogar intoxicated. Du glaubst, du könntest noch entscheiden — das Urteil ist schon zusammengebrochen.
Dann kannst du Routinearbeit tun: Code schreiben, Tests laufen lassen, Logs prüfen. Aber triff keine teuren Architekturentscheidungen, wenn du es vermeiden kannst.
Kann die Entscheidung bis morgen warten und bist du ausgebrannt — lass sie bis morgen warten.
Hunger und Erschöpfung sind deine Feinde.
Bevor das System entworfen wird, muss der Architekt selbst funktionsfähig sein.
5. Ändert sich der Code, muss sich die Dokumentation ändern
Aktualisiere mit jedem bedeutsamen Code-Update auch die Dokumentation.
Behandle Dokumentation nicht als separate Aufgabe für danach. Code und Dokumentation sind zwei Hälften derselben Änderung.
Moderne KI-Tools machen das viel leichter. Lass nach jeder wichtigen Änderung die KI den Diff und den zugehörigen Code prüfen. Erzeuge Markdown zum aktuellen Systemzustand oder aktualisiere Bestehendes.
Halte Dokumentation möglichst als `.md` im Repository. Markdown ist einfach, versioniert sich gut und rendert sauber auf GitHub.
Betrifft eine Backend-Änderung das Frontend, teile das relevante Markdown mit dem Frontend-Team.
Ein Frontend-Entwickler sollte Endpoint, Request/Response, geändertes Verhalten und Fallstricke verstehen — ohne zuerst im Code zu graben.
Dasselbe gilt team- und serviceübergreifend.
KI beschleunigt Dokumentation. Die Verantwortung für Korrektheit bleibt beim Engineer, der die Änderung gemacht hat. Übernimm KI-Docs nicht ungeprüft als Wahrheit.
Wurde Code aktualisiert und Docs nicht, ist die Arbeit nicht fertig.
Dokumentation ist das Gedächtnis des Systems.
6. Sieh das fertige System zuerst im Kopf
Bevor du Code schreibst, solltest du das fertige System im Kopf sehen können.
Kannst du das nicht — nimm Stift und Papier und zeichne.
Es muss kein ER-Diagramm sein. Kein UML. Kein Standard von irgendwem.
Zeichne Boxen. Zeichne Pfeile. Schreib Notizen daneben. Zeichne, wie es dir passt.
Schönheit ist egal. Du musst das ganze System sehen können.
Versuchst du ein System, das du nicht siehst, durch Codieren zu entdecken, beginnst du Design und Implementation gleichzeitig.
Zuerst sehen. Dann bauen.
7. Vergiss nicht, für wen das System ist
Verachte Ideen nichttechnischer Manager und Nutzer nicht.
Manchmal betrachtet eine technisch seltsam wirkende Idee das Problem aus einem Winkel, den du nie bedacht hast.
Ihre Aufgabe ist nicht, wie du zu denken.
Deine Aufgabe ist zu verstehen, was sie wollen — und es möglichst in ein laufendes System zu verwandeln.
Hör ihre Träume und versuch sie wahr zu machen. Manchmal wird dich das Ergebnis wirklich überraschen.
Baue das System für die Menschen, die es nutzen — nicht für dich.
8. Der Architekt darf die Kontrolle nicht verlieren
Jedes ernsthafte System braucht Fail-Safe-Mechanismen.
Du solltest das System bei Bedarf mit einer einzigen Environment-Variable stoppen können. Habe bei Bedarf einen kontrollierten Management-Endpoint. Plane Wege, kritische Teile zu deaktivieren.
Das dürfen keine unsicheren Geheim-Hintertüren sein. Sie sollen autorisiert, sicher und möglichst geloggt sein.
Egal wie autonom ein System wird — der Architekt darf nie Zuschauer des eigenen Systems werden.
Die finale Kontrolle bleibt beim Architekten.
9. Verdächtige zuerst deinen eigenen Fehler
Wenn das System langsamer wird, gib nicht sofort der Hardware die Schuld.
Vielleicht gibt es einen Deadlock, den du nicht siehst. Vielleicht eine schlechte Query. Vielleicht einen unnötigen Network-Call. Vielleicht sperrt ein Architekturfehler das System.
Ja — Hardware kann wirklich unzureichend sein.
Aber miss zuerst.
Ein Engineer muss akzeptieren können, dass er falschliegen kann. Daran ist nichts Beschämendes.
Wer nicht zugeben kann, falschgelegen zu haben, kann seinen Fehler auch nicht beheben.
10. Ziehe Schüler groß
Lass das System nicht nur in deinem Kopf leben.
Bring das System deinen Schülern bei.
Bist du morgen nicht da, muss das System weiterlaufen können. Wenn ein anderer es versteht und verbessert, schrumpft deine Autorität nicht. Es beweist, dass du ein guter Architekt bist.
Ein System, das nur einer versteht, ist nicht stark. Es ist zerbrechlich.
Gib das Wissen weiter.
11. Arbeite mit einem kleinen, abgestimmten Team
Sei kein Solo-Architekt. Baue auch kein unnötig großes Team.
Arbeite mit Menschen, die lernen wollen, zuhören, Fragen stellen und den Schülergeist nicht verloren haben.
Kritik ist wertvoll. Ein Junior kann den Bug sehen, den du verpasst hast. Hör zu.
Aber Menschen, die ständigen Widerspruch zum Arbeitsstil machen, sind beim Systembau gefährlich. Jede Entscheidung endlos neu zu verhandeln zwingt den Architekten, die Richtung ständig zu wechseln — und zerstört am Ende die Stabilität.
Diskutiere, bis die Entscheidung fällt.
Danach als Team ausführen.
Du musst nicht langfristig mit jemandem arbeiten, der Fortschritt durch ständigen Widerspruch blockiert.
12. Sei kreativ, bleib aber einfach
Ein erfahrener Engineer sollte vor einem guten System „wow“ sagen können.
Und ein guter Junior sollte im selben System etwa innerhalb einer Woche grob verstehen, was vor sich geht.
Das widerspricht sich nicht.
Wahre Meisterschaft heißt nicht, hundert Services zu nutzen oder Abstraktionen zu erfinden, die niemand versteht.
Es heißt, ein komplexes Problem mit einem überraschend einfachen System zu lösen.
Komplexität ist kein Handwerk.
13. Stopfe nicht jede Neuerung in das alte System
Kommt eine neue Idee, sollte dein erster Reflex nicht sein, sie ans aktuelle System zu schrauben.
Manchmal brauchst du einen neuen Service. Manchmal eine neue Anwendung. Manchmal wirklich V2.
Versuchst du das alte System ewig zu erweitern, stapelst du irgendwann Jahre an Entscheidungen und Ausnahmen auf das einfache Startsystem.
Manchmal ist Null von vorn günstiger, sauberer und richtiger.
Veränderung heißt nicht immer, das aktuelle System zu vergrößern.
14. Nutze künstliche Intelligenz als Werkzeug
KI kann ein System ernsthaft stärken.
Besonders moderne Reasoning-Engines sind stark beim Bauen und zur Runtime.
Sie können Code prüfen, Edge Cases finden, Entscheidungen stützen, natürliche Sprache verstehen und mehrdeutige Probleme lösen, an denen klassische Algorithmen scheitern.
Aber lade nicht alles auf die KI ab.
Reicht eine einfache deterministische Lösung — nutze sie. Bringt Reasoning echten Mehrwert — nutze KI. Arbeiten beide besser zusammen — baue hybrid.
Gib der KI Arbeit. Gib ihr keine Autorität über das System.
15. Erwarte keine Wunder von der KI
KI ist nur so schlau wie die Person, die sie benutzt.
Beschreibst du das Problem falsch, kann selbst ein starkes Modell schnell die falsche Lösung liefern.
Du musst wissen, was du willst. Das Problem genug verstehen, um die Antwort zu bewerten. Merken, wann sie falsch ist.
KI muss nicht der Engineer an deiner Stelle sein.
Gut genutzt erweitert sie deine Engineering-Kapazität.
Erwarte keine Wunder.
16. Charakter zieht, Scheiße stinkt
It is what it is.
Suche nicht in allem einen tiefen Sinn.
Manchmal ist ein Bug nur ein Bug. Schlechter Code ist schlechter Code. Eine Idee, die nicht funktioniert, funktioniert nicht. Eine falsche Entscheidung ist falsch.
Reicht eine einfache Erklärung, verzerre das Problem nicht mit unnötiger Theorie.
Schau zuerst auf die Realität vor dir.
17. Fürchte dich nicht, den Meister zu imitieren
Als Schüler musst du nicht alles erfinden.
Als Student habe ich Strukturen wie ArrayList von Grund auf neu geschrieben, um zu lernen. Ziel war nicht, eine neue Datenstruktur zu erfinden.
Ziel war, selbst zu tun, was Meister taten, zu verstehen, wie es wirkt, mit meiner Lösung zu vergleichen und zu wachsen.
Durch Nachahmung lernen ist kein Diebstahl.
Erreiche zuerst das Niveau, auf dem du tun kannst, was der Meister tat. Verstehe warum. Dann hinterfrage. Dann entwickle deine Methode.
Ablehnen, was du nicht verstehst, nur um anders zu sein, ist keine Kreativität.
Zuerst lernen. Später brechen.
Schlusswort
Gutes System Engineering ist nicht die Kunst, möglichst viel Technologie zu nutzen.
Es heißt, das Problem zu verstehen, die Lösung im Kopf zu sehen, so einfach wie möglich zu bauen, die Stabilität des Funktionierenden zu schützen und den eigenen Fehler zugeben zu können, wenn nötig.
Ein guter Architekt kennt zuerst den Zustand seines Geistes. Große Entscheidungen hungrig, erschöpft oder unklar denkend abzulehnen, ist selbst Teil des Engineerings.
Er schützt das Gedächtnis des Systems so sorgfältig wie den Code. Er dokumentiert Änderungen und teilt dieses Wissen mit denen, die das System weiterbauen.
Er kontrolliert sein System — er betet es nicht an.
Er führt sein Team — er macht seine Schüler nicht stumm.
Er nutzt künstliche Intelligenz — er lagert das Denken nicht an sie aus.
Er lernt aus dem Vergangenen — er ergibt sich nicht dem Status quo.
Und am wichtigsten: Läuft das System, versucht er zu verstehen warum; läuft es nicht, versucht er zu verstehen warum nicht.
Alles andere ist ein Werkzeug.
Arda Akgür
ARC-Systemprinzipien
v0.1 Final