System- und Software-Architektur

Im Detail

Was diese Leistung umfasst

Häufige Fragen

Was Kund:innen vorab wissen wollen

1. 01 Wann lohnt sich ein Architektur-Review?

   Ein Architektur-Review lohnt sich immer dann, wenn Symptome auf strukturelle Probleme hindeuten: Die Entwicklungsgeschwindigkeit lässt erkennbar nach, neue Features werden unverhältnismäßig teuer oder riskant, Fehler häufen sich in denselben Bereichen, oder vor einer größeren Investitionsentscheidung — etwa einer Migration, Skalierung oder Übernahme — wird belastbare Klarheit über den Ist-Zustand benötigt. Ein Review über ein bis zwei Wochen liefert in solchen Situationen einen priorisierten Maßnahmenkatalog mit konkreten Quick-Wins für die nächsten Wochen und eine Strategie für die kommenden zwölf Monate. Gerade weil ein Review vergleichsweise wenig Aufwand bedeutet, aber teure Fehlinvestitionen verhindern und die richtige Richtung vorgeben kann, gehört er zu den Maßnahmen mit der besten ROI-Quote in der Softwareentwicklung. Er ersetzt keine kontinuierliche Architekturarbeit, schafft aber den Überblick und die Entscheidungsgrundlage, auf der diese aufsetzen kann.

2. 02 Was ist der Unterschied zwischen C4 und Arc42?

   C4 und Arc42 ergänzen sich, statt zu konkurrieren. C4 ist ein Diagramm-Modell, das eine Architektur auf vier Zoom-Stufen darstellt: Context (das System in seiner Umgebung), Container (die ausführbaren Einheiten), Component (die Bausteine darin) und Code (die Implementierungsdetails). Es ist also primär eine visuelle Sprache, die Architektur auf verschiedenen Abstraktionsebenen begreifbar macht. Arc42 dagegen ist eine Dokument-Schablone mit zwölf Abschnitten, die Architektur-Entscheidungen, Quality Goals, Randbedingungen und Risiken textlich strukturiert und damit das „Warum" hinter der Architektur festhält. Die bewährte Praxis ist die Kombination beider: Arc42 dient als Dokument-Gerüst, das die Struktur und die Entscheidungen erfasst, und C4-Diagramme werden als visuelle Sprache darin eingebettet, um die Strukturen anschaulich zu zeigen. So entsteht eine Dokumentation, die sowohl die Übersicht als auch die Begründungen liefert — und für neue Teammitglieder wie für externe Prüfer gleichermaßen lesbar ist.

3. 03 Wie dokumentiere ich Architektur-Entscheidungen?

   Am wirkungsvollsten mit ADRs — Architecture Decision Records. Das sind kurze, datierte Markdown-Dateien, die direkt neben dem Code im Repository liegen und für jede wesentliche Entscheidung vier Dinge festhalten: Was wurde entschieden, warum, welche Alternativen wurden erwogen und welche Konsequenzen ergeben sich daraus. Weil sie versioniert mit dem Code mitwandern, bleiben sie aktuell und gehen nicht — wie ein separates Architektur-Wiki — mit der Zeit verloren oder veralten unbemerkt. Der eigentliche Wert zeigt sich nach Jahren: Ein neues Teammitglied kann nachvollziehen, warum die Architektur so aussieht, wie sie aussieht, auch wenn die ursprünglichen Entscheider längst nicht mehr im Projekt sind. Das verhindert, dass bewährte Entscheidungen aus Unkenntnis rückgängig gemacht oder dieselben Diskussionen immer wieder neu geführt werden. ADRs sind bewusst leichtgewichtig — eine halbe Seite genügt — damit sie tatsächlich geschrieben werden und nicht an Aufwand scheitern.

4. 04 Was ist ein Compound-AI-System?

   Ein Compound-AI-System löst eine Aufgabe nicht mit einem einzigen Modellaufruf, sondern als Zusammenspiel mehrerer Komponenten: ein oder mehrere Sprachmodelle, eine Retrieval-Schicht für den Zugriff auf Ihr Wissen, Werkzeuge für Aktionen in Fachsystemen, Validierungs- und Verifikationsschritte sowie eine Steuerungslogik, die alles orchestriert. Der Begriff hat sich durchgesetzt, weil die Praxis gezeigt hat: Robuste KI-Anwendungen entstehen selten durch ein noch größeres Modell, sondern durch eine gut entworfene Architektur um das Modell herum. Das ist eine gute Nachricht für Entscheider, denn es verschiebt den Hebel vom kaum beeinflussbaren Modell hin zum gestaltbaren System — Qualität, Nachvollziehbarkeit und Kosten werden zu Architekturfragen. Für die Praxis heißt das, KI-Funktionalität von Anfang an als System aus austauschbaren Bausteinen zu entwerfen: Jede Komponente ist einzeln testbar, das zugrundeliegende Modell bleibt austauschbar, und neue Anforderungen lassen sich ergänzen, ohne das Ganze neu zu bauen.

5. 05 Deterministische oder LLM-gesteuerte Orchestrierung — was ist wann richtig?

   Bei der Orchestrierung eines KI-Workflows gibt es zwei Grundmuster. Deterministisch bedeutet: Die Abfolge der Schritte ist im Code fest verdrahtet, das Sprachmodell füllt nur klar umrissene Teilaufgaben aus. Das ist vorhersehbar, günstig zu testen und leicht zu auditieren — die richtige Wahl, wenn der Ablauf bekannt und stabil ist. LLM-gesteuert bedeutet: Das Modell entscheidet selbst, welche Schritte in welcher Reihenfolge nötig sind, und ruft Werkzeuge dynamisch auf. Das ist flexibel und stark bei offenen, schwer vorab strukturierbaren Aufgaben — aber weniger vorhersehbar, teurer und aufwendiger abzusichern. Die bewährte Praxis ist kein Entweder-oder, sondern die richtige Grenze: so viel deterministische Struktur wie möglich, so viel Modell-Autonomie wie nötig. Man verdrahtet den bekannten Rahmen fest und überlässt dem Modell nur die Teilentscheidungen, die echte Flexibilität erfordern. Diese Grenze bewusst zu ziehen ist eine der wichtigsten Architekturentscheidungen jeder Agenten-Anwendung — sie bestimmt Kosten, Testbarkeit und das Vertrauen in das System.

6. 06 Was sind Event-Sourced Agents und warum sind sie robuster?

   Event Sourcing ist ein etabliertes Architekturmuster: Statt nur den aktuellen Zustand zu speichern, wird jede Zustandsänderung als unveränderliches Ereignis protokolliert; der aktuelle Zustand ergibt sich aus dem Abspielen dieser Ereigniskette. Überträgt man das auf KI-Agenten, wird jeder Schritt eines Agenten — jede Modellentscheidung, jeder Werkzeugaufruf, jedes Ergebnis — als Ereignis festgehalten. Der Gewinn ist erheblich: Ein unterbrochener oder abgestürzter Agent kann exakt an der letzten Stelle weiterlaufen, statt von vorn zu beginnen; jede Aktion ist lückenlos auditierbar, was gerade für Compliance und Fehlersuche unbezahlbar ist; und ein fehlerhafter Lauf lässt sich nachvollziehen und reproduzieren, indem man die Ereignisse erneut abspielt. Für langlaufende oder geschäftskritische Agenten ist dieses Muster deshalb oft die Grundlage für Verlässlichkeit — es macht aus einem unberechenbaren Black-Box-Prozess einen nachvollziehbaren, wiederanlauffähigen Ablauf. Der Aufwand lohnt sich überall dort, wo ein Agent Aktionen mit Folgen ausführt und nicht nur Text erzeugt.

Häufig kombiniert mit

Verwandte Leistungen

Zum Weiterlesen

Passende Ratgeber

• Pattern12-Factor-Agents: KI-Agenten, die in Produktion haltenBeeindruckende Demo, aber im Alltag unzuverlässig? Die 12-Factor-Prinzipien zeigen, was einen KI-Agenten vom Prototyp zum produktionsreifen System macht.→