Architektur vor Automatisierung

Automatisierung ist verführerisch, weil sie sofort wirkt.

Ein Agent schreibt Code. Ein Assistent erzeugt Tests. Ein Tool baut Komponenten. Ein Skript migriert Daten. Alles fühlt sich schneller an — und oft ist es das auch.

Aber Geschwindigkeit verstärkt immer das, was schon im System steckt.

Wenn die Richtung klar ist, bringt Automatisierung Tempo. Wenn die Richtung unklar ist, bringt sie schnelleres Chaos.

Deshalb wird ein alter Grundsatz in der KI-gestützten Softwareentwicklung wieder wichtiger:

Architektur vor Automatisierung.

Nicht als bürokratische Bremse. Nicht als monatelange Vorphase. Sondern als praktische Disziplin, bevor ein Team Maschinen damit beauftragt, viele Entscheidungen in kurzer Zeit zu materialisieren.

Warum KI schlechte Architektur nicht versteckt

Moderne KI-Werkzeuge können beeindruckend viel Code erzeugen. Sie können bestehende Muster erkennen, neue Dateien anlegen, APIs verdrahten, Tests ergänzen und Dokumentation schreiben.

Was sie nicht zuverlässig können: die Verantwortung für das Gesamtsystem übernehmen.

Ein Modell weiß nicht automatisch, welche Daten im Unternehmen führend sind. Es kennt nicht die politischen Grenzen zwischen Teams. Es versteht nicht von selbst, welche Fehler akzeptabel sind und welche einen Kundenvertrag gefährden. Es kann Annahmen treffen — aber Annahmen sind keine Architektur.

Wenn die Grundstruktur fehlt, entstehen typische Probleme:

• Logik wird an mehreren Stellen dupliziert;
• Datenmodelle wachsen aus Einzelfällen statt aus Fachlichkeit;
• Berechtigungen werden nachträglich angeklebt;
• Integrationen werden eng gekoppelt;
• Fehlerfälle bleiben unsichtbar;
• Tests prüfen Verhalten, das niemand bewusst entschieden hat.

Das Ergebnis kann lange funktionierend aussehen.

Bis die erste echte Änderung kommt.

Dann zeigt sich, ob das System gebaut wurde — oder nur gewachsen ist.

Architektur ist keine Zeichnung

Viele Teams denken bei Architektur an Diagramme.

Diagramme können helfen. Aber Architektur ist nicht das Bild an der Wand.

Architektur ist die Summe der Entscheidungen, die später schwer zu ändern sind.

Dazu gehören:

• Systemgrenzen;
• Datenhoheit;
• Integrationsverträge;
• Abhängigkeiten zwischen Modulen;
• Skalierungsannahmen;
• Sicherheits- und Rollenmodelle;
• Deployment- und Rollback-Strategien;
• Beobachtbarkeit und Betrieb.

Diese Entscheidungen müssen nicht alle am ersten Tag endgültig sein. Aber sie müssen bewusst sein.

Gerade mit KI ist das wichtig, weil die Umsetzungskosten sinken. Wenn Code billig ist, werden falsche Entscheidungen nicht sofort teuer. Sie werden später teuer — wenn Nutzer, Daten, Integrationen und Features bereits darauf aufbauen.

Der häufigste Fehler: lokale Optimierung

KI-Assistenten sind hervorragend darin, lokale Aufgaben zu lösen.

“Baue diesen Endpoint.”

“Schreibe diese Komponente.”

“Füge einen Import hinzu.”

“Erzeuge Tests für diese Funktion.”

Das ist nützlich. Aber viele Softwareprobleme sind nicht lokal.

Ein Endpoint ist nicht nur ein Endpoint. Er ist Teil eines API-Vertrags. Eine Komponente ist nicht nur UI. Sie transportiert Produktentscheidungen und Zustände. Eine Datenbanktabelle ist nicht nur Speicher. Sie definiert, wie das Unternehmen seine Wirklichkeit modelliert.

Wenn jedes Teil isoliert optimiert wird, kann das Ganze schlechter werden.

Das ist der Punkt, an dem menschliche Architekturverantwortung zählt.

Nicht, weil Menschen jede Zeile selbst schreiben müssen. Sondern weil jemand die Systemebene halten muss.

Was vor der Automatisierung geklärt werden sollte

Ein guter Architekturstart muss nicht groß sein. Für viele Projekte reichen einige klare Antworten.

1. Welche Domäne bauen wir wirklich?

Software spiegelt Fachlichkeit.

Wenn Begriffe unklar sind, wird der Code unklar. Was ist ein Kunde? Was ist ein Projekt? Wann ist eine Bestellung abgeschlossen? Wer besitzt welche Daten? Welche Zustände sind erlaubt?

Diese Fragen klingen simpel. Sie sind es selten.

2. Wo liegen die Systemgrenzen?

Nicht alles gehört in denselben Service, dieselbe App oder dieselbe Datenbank.

Grenzen entscheiden, wie leicht ein System später erweitert, ersetzt oder übergeben werden kann. Schlechte Grenzen führen zu Software, bei der jede Änderung drei andere Dinge beschädigt.

3. Welche Daten sind kritisch?

Nicht jede Information braucht denselben Schutz.

Kundendaten, Zahlungsdaten, operative Kernprozesse und interne Notizen haben unterschiedliche Anforderungen. Wer diese Unterschiede früh klärt, vermeidet später teure Umbauten.

4. Wie wird das System betrieben?

Deployment ist kein Nachgedanke.

Ein System braucht Logs, Metriken, Rollbacks, Umgebungen, Secrets, Backups und Verantwortlichkeiten. Selbst ein kleines Produkt profitiert davon, wenn Betrieb nicht erst nach dem ersten Ausfall geplant wird.

5. Welche Teile dürfen billig sein?

Das ist vielleicht die wichtigste Frage.

Nicht alles muss perfekt sein. Manche Komponenten dürfen bewusst pragmatisch, temporär oder ersetzbar sein. Gute Architektur bedeutet nicht maximale Schwere. Sie bedeutet bewusste Schwere an den richtigen Stellen.

Was KI danach besonders gut macht

Wenn die Architektur steht, wird KI deutlich wertvoller.

Dann kann sie innerhalb klarer Leitplanken arbeiten:

• bekannte Patterns anwenden;
• Boilerplate reduzieren;
• Tests aus Verträgen ableiten;
• Refactorings konsistent durchführen;
• Dokumentation aktuell halten;
• wiederkehrende Integrationsarbeit beschleunigen;
• Varianten für UI oder API-Design erzeugen.

Der Unterschied ist enorm.

Ohne Architektur erzeugt KI plausible Einzelteile.

Mit Architektur erzeugt KI Bausteine für ein bewusstes System.

Warum das für Kunden praktisch relevant ist

Für Kunden ist Architektur kein Selbstzweck.

Niemand kauft ein Datenmodell, weil es elegant ist. Kunden kaufen Ergebnisse:

• weniger Ausfälle;
• schnellere Weiterentwicklung;
• leichteres Onboarding neuer Entwickler;
• sicherere Integrationen;
• bessere Übergabe;
• realistischere Kosten über die Lebensdauer des Produkts.

Architektur ist das, was diese Ergebnisse wahrscheinlicher macht.

In KI-Projekten wird dieser Punkt noch wichtiger, weil kurzfristiges Tempo so leicht verfügbar ist. Ein Team kann sehr schnell sehr viel bauen. Die Frage ist, ob es in drei Monaten noch versteht, was es gebaut hat.

Wo McDougall Digital helfen kann

Unser Ansatz bei McDougall Digital ist nicht “erst ein halbes Jahr Architektur, dann vielleicht Umsetzung”.

Das wäre genauso falsch wie blindes Automatisieren.

Wir arbeiten lieber mit einer klaren Reihenfolge:

1. Ziel und Verantwortung des Systems verstehen.
2. Die wichtigsten Architekturentscheidungen treffen.
3. KI-gestützte Umsetzung innerhalb dieser Leitplanken nutzen.
4. Qualität durch Review, Tests, CI/CD und Betrieb absichern.
5. Nach dem Launch bewusst weiterentwickeln.

Das macht Projekte nicht langsamer.

Es verhindert, dass frühe Geschwindigkeit später durch Reparaturarbeit aufgefressen wird.

Ein pragmatischer Startpunkt

Wenn ein Team bereits mit KI baut, lohnt sich ein kurzer Architektur-Check:

• Welche Teile des Systems sind fachlich zentral?
• Wo entstehen Abhängigkeiten, die später teuer werden?
• Welche Datenmodelle sind noch zu unscharf?
• Welche Fehlerfälle sind nicht abgedeckt?
• Welche Aufgaben kann KI sicher übernehmen — und welche brauchen Review?

Das Ergebnis sollte kein 80-seitiges Dokument sein.

Es sollte eine handlungsfähige Karte sein: Was bleibt leicht, was wird stabilisiert, und wo darf keine Automatisierung ohne menschliche Entscheidung passieren?

Die Kernbotschaft

KI kann Softwareentwicklung massiv beschleunigen.

Aber sie macht Architektur nicht überflüssig. Sie macht Architektur sichtbarer.

Je schneller ein Team bauen kann, desto wichtiger wird die Frage, ob es in die richtige Richtung baut.

Architektur vor Automatisierung heißt deshalb nicht: weniger Tempo.

Es heißt: Tempo, das nicht gegen das eigene Produkt arbeitet.

Nächster Schritt

Wenn ihr KI-gestützte Entwicklung einführen, einen bestehenden Prototyp stabilisieren oder eine SaaS-Plattform sauber aufbauen wollt, beginnt mit einem fokussierten Architektur-Review.

Wir helfen dabei, Systemgrenzen, Datenmodelle, Integrationen und Betriebsanforderungen so zu klären, dass KI dort Tempo bringt, wo sie stark ist — und Menschen dort entscheiden, wo Verantwortung zählt.