Architektur-Consulting
für Systeme, die bleiben.
Die meisten Systeme werden nicht durch eine falsche Zeile Code ruiniert, sondern durch drei Entscheidungen, die zwei Jahre vorher getroffen wurden. Dieses Dokument beschreibt, wie ich mit Gründern, CTOs und Tech-Leads an solchen Entscheidungen arbeite — pragmatisch, direkt im Code und in der Infrastruktur, nicht in einem Foliensatz.
Der Moment, in dem „läuft ja" aufhört zu reichen.
Architektur interessiert niemanden, solange das System läuft. Sie wird interessant an dem Punkt, an dem eine der folgenden Fragen unbeantwortet im Raum steht: Wir wollen einen zweiten Markt bespielen — geht das? Der Monolith braucht zwanzig Minuten für ein Deployment — bleibt das so? Wir haben drei Features parallel in Arbeit und zwei davon brechen ständig das dritte — woran liegt das? Ein potenzieller Käufer will unsere Infrastruktur sehen — was zeigen wir?
Meistens meldet sich jemand nicht, weil ein Architekturproblem eskaliert ist, sondern weil er ahnt, dass die nächste Entscheidung ihn für die nächsten drei Jahre festlegt. Die Kunden sind Gründer, die ihr erstes produktives System bauen. CTOs im Mittelstand, die den nächsten Schritt in die Cloud planen. Tech-Leads in Scale-ups, die merken, dass der Code, der sie auf 10.000 Nutzer gebracht hat, sie nicht auf 100.000 bringen wird. Und Investoren, die wissen wollen, ob die Codebasis, in die sie gerade investieren sollen, das Versprechen der Pitch-Deck-Folien hält.
Diese Gespräche sind nicht theoretisch. Sie enden in Entscheidungen, die Geld, Zeit und Optionen kosten. Deswegen lohnt es, sie ernst zu nehmen, bevor sie erzwungen werden.
Zu viel Architektur ist genauso teuer wie zu wenig.
Die meisten Systeme, die mir begegnen, leiden an einer von zwei Krankheiten. Die erste ist Overengineering. Ein Team von drei Entwicklern betreibt Kubernetes mit Service-Mesh, hat den Monolithen vorzeitig in sieben Microservices zerlegt und wundert sich, warum jede Feature-Auslieferung zwei Wochen dauert. Die Architektur ist auf einen Maßstab zugeschnitten, den das Produkt in fünf Jahren vielleicht erreicht — heute kostet sie nur Geschwindigkeit, Komplexität und Nerven.
Die zweite ist Underengineering. Ein Monolith, der in zwei Jahren organisch gewachsen ist, bis niemand mehr weiß, welcher Cron-Job welche Tabelle schreibt. Deployments passieren montags, weil jeder Tag danach zu riskant ist. Die Datenbank ist der Single Point of Everything. Das System trägt — bis es das nicht mehr tut, meistens genau dann, wenn ein großer Kunde unterschreibt.
„Premature Microservices sind nicht skalierbare Software. Sie sind teurer Selbstbetrug in drei Repositories." Enes Kaya
Der Weg dazwischen ist unspektakulär: ein Monolith, der bewusst modular geschnitten ist. Eine klare Datenschicht. Wenige, dafür richtig gesetzte Abstraktionen. Serverless oder Container dort, wo sie Arbeit abnehmen, nicht dort, wo sie nach dem letzten Konferenzvortrag zwingend wirken. Diese Art von System ist unglamourös, gut dokumentiert und hält ein Jahrzehnt. Genau darum geht es.
Fünf Formate, ein Anspruch: belastbare Entscheidungen.
Ich arbeite nicht in Visio und nicht in einem 40-seitigen Konzeptdokument. Die Ergebnisse meiner Arbeit sind Architekturdiagramme, die in Markdown leben, Infrastruktur-Code, den Sie selbst weiterbetreiben können, und Entscheidungsdokumente (ADRs), die auch in zwei Jahren noch erklären, warum eine Entscheidung so und nicht anders gefallen ist. Die folgenden fünf Formate decken die typischen Anlässe ab.
-
01
Architektur-Review
Ein bestehendes System, ein frischer Blick. Ich lese Code, lese Infrastruktur, sitze mit Ihrem Team zusammen und liefere eine ehrliche Bewertung: Was trägt, was bricht im nächsten Wachstum, was ist harmlos und was ist ein ungesehener Risiko-Hotspot. Ergebnis: ein priorisierter Maßnahmenkatalog, den Sie selbst abarbeiten können.
-
02
Cloud-Design auf AWS
Greenfield oder Replatforming. Ich entwerfe Ihre AWS-Infrastruktur so, dass sie heute zu Ihrem Team passt und morgen nicht im Weg steht — Serverless-first, wo es sinnvoll ist, Container dort, wo Workloads es erzwingen. Infrastructure as Code mit SST oder Pulumi, keine Klickstrecken in der Konsole.
-
03
Backend- und API-Strategie
REST oder GraphQL? Event-driven oder synchron? Ein Postgres oder Postgres plus Read-Model? Diese Entscheidungen sind selten binär, aber sie sind selten reversibel. Ich arbeite mit Ihnen das Schnittstellenmodell aus, das zu Ihren Konsumenten passt — und das Sie in zwei Jahren ohne Breaking-Change erweitern können.
-
04
Tech Due Diligence
Für Investoren und Käufer: eine technische Bewertung vor dem Term Sheet. Codequalität, Architektur, Abhängigkeiten, Security-Posture, Key-Person-Risiken. Geschrieben so, dass sowohl das Investment-Committee als auch das Zielteam damit arbeiten können — ohne Schmerzen, aber auch ohne Schonfärberei.
-
05
Build-vs-Buy und Migrationen
„Sollen wir das selbst bauen oder zukaufen?" ist selten eine Bauchentscheidung. Ich nehme die Anforderungen, die Betriebsrealität und die wahrscheinliche Zweitnutzung auseinander, lege Aufwände neben Lizenzkosten und lege eine Empfehlung auf den Tisch. Gleiches Vorgehen bei Migrationen: von On-Prem in die Cloud, von Heroku zu AWS, von Firebase zu Postgres.
Vier Schritte, kein Theater.
Die Zusammenarbeit ist bewusst kurz getaktet. Ein Architektur-Engagement dauert selten länger als sechs bis acht Wochen. Danach ist entweder klar, was zu tun ist, oder die Umsetzung läuft bereits — meistens mit Ihrem Team, nicht mit mir. Mein Ziel ist, mich überflüssig zu machen, nicht, Abhängigkeiten aufzubauen.
-
01
Erstgespräch
Dreißig Minuten, kostenlos, unverbindlich. Sie schildern das System, den Anlass und das, was Sie befürchten. Ich sage Ihnen ehrlich, ob ich der richtige Ansprechpartner bin — und wenn nicht, wer es sein könnte.
-
02
Zugang und Sichtung
Lesezugriff auf Repository und Cloud-Konto, ein kurzer Call mit dem Team, Einsicht in die vorhandene Dokumentation. Ich rekonstruiere das System, wie es tatsächlich läuft — nicht, wie es im Onboarding beschrieben ist.
-
03
Analyse und Empfehlung
Ich schreibe das Architekturdokument. Diagramme, ADRs, Risiko-Hotspots, ein priorisierter Maßnahmenplan mit Aufwandsschätzung. Zwischenstand nach einer Woche, finaler Stand nach drei bis fünf — je nach Umfang.
-
04
Umsetzung oder Übergabe
Entweder begleite ich die ersten Umsetzungsschritte selbst — Infrastructure as Code schreiben, API-Schnitt bauen, Migrations-Playbook durchziehen — oder Ihr Team übernimmt. Beides ist legitim. Ich habe kein Interesse daran, dauerhaft im Retainer zu sitzen.
Warum ich — und nicht eine Agentur.
Agenturen skalieren über Junior-Team und Senior-Sales. Der Architekt, der im Pitch-Meeting sitzt, ist selten derjenige, der später den Code anfasst. Bei mir ist das dieselbe Person. Das schränkt die Zahl der parallelen Projekte ein — bewusst. Ich nehme pro Quartal eine Handvoll Engagements an, die ich tief bearbeite, statt ein Dutzend, die ich delegiere.
Mein Hintergrund ist breit, aber nicht diffus: sechs Jahre Enterprise Security in einem DAX-40-Konzern, CISSP-Zertifizierung, danach der Sprung in die Gründung. Heute baue ich als CTO eine AI-Plattform im PropTech-Bereich — produktiv, mit zahlenden Kunden, auf AWS, Serverless-first. Nebenbei trage ich zu SST bei, einem der Open-Source-Frameworks, mit dem ich selbst arbeite. Das ist kein Zufall. Ich empfehle nur Werkzeuge, die ich selbst im Produktivbetrieb nutze.
Ein Gespräch, kein Verkaufsprozess.
Wenn Sie gerade an einer Architekturentscheidung sitzen und das Gefühl haben, dass die nächste falsche Abzweigung teuer wird: schreiben Sie mir. Das Erstgespräch ist kostenlos und ist kein Akquise-Termin. Nach zwanzig bis dreißig Minuten ist meistens klar, ob ein Review, ein Redesign oder schlicht eine zweite Meinung der richtige nächste Schritt ist — und wenn keines davon, sage ich Ihnen das auch.
enes@enkaconsulting.de
Düsseldorf, Deutschland · LinkedIn →