Software‑Architektur: von C++ bis zum KI‑Agentensystem

Der ehemalige rumänische Präsident Ceaușescu konnte oder wollte keine Baupläne lesen. Er ließ daher insbesondere beim neuen Staatspalast ganz agil erst einmal bauen, um dann zu begutachten und wieder abreißen zu lassen. Im Laufe der Zeit entstanden auf diese Weise mit dem Parlaments‑ und Frühlingspalast höchst beeindruckende Bauten. Nicht ganz billig die Methode, aber als Diktator gönnt man sich ja sonst nichts.

Wenn man kein Staatsdiktator ohne Fähigkeit zum räumlichen Sehen ist, wird es eine gute Idee sein, die gute alte Handwerkerregel „Erst Grübeln, dann Dübeln“ umzusetzen. An der Spitze der Kriterien liegen die Ziele des Geschäftsfeldes. Der Plan zur Erreichung der Ziele wird Strategie genannt. Architekturen, sei es von der gesamten Organisation, der Software oder dem Datenmanagement, sind Teil der längerfristigen Strategie: Sie haben das „Was, Warum und Wann“ zu beantworten. Werkzeuge, neudeutsch „Tools“, sind lediglich taktisch: sie werden je nach Bedarf der Strategie und Verfügbarkeit neu ausgewählt: Sie stellen die momentane Antwort auf das „Wie“ dar. Tools mit blumigen Bezeichnern wie Snowflake, Glue, BigQuery, Anthos, Outposts, Backblaze, Cloudflare sind in den letzten Jahrzehnten z.T. auf wöchentlicher Basis entstanden und vergangen. Leider verlieben sich Entwickler immer wieder in ein neues Werkzeug und führen es einfach mal ein. Der Kuss des Todes.

Bei Architekturen im Unternehmenskontext liegt der Beitrag zu Wertschöpfung und ‑erhalt an der Spitze der Gestaltungskriterien. Sie sind zu verstehen als das bewusste Design von Systemen zur Erfüllung der naturgemäß veränderlichen Software‑ und Datenbedarfe für eine Welt, die volatil, ungewiss, komplex und ambivalent (vuka) ist. Eine langfristig taugliche Software‑Architektur weist daher je nach Unternehmenskultur, Geschäftsmodell und Persönlichkeitseigenschaften der Stakeholder u.a. folgende Eigenschaften auf:

• Hoch Modularisiert für (a) geringen Abstimmungsbedarf bei verteilten Teams, (b) einfache Updatefähigkeit, (c) Cybersecurity by Design und damit (d) dicht an einer cloud‑nativen Microservice‑Architektur
• Flexibel skalierbar in beide Richtungen für stetes Optimum, im Idealfall selbsttätig dynamisch skalierend bei Lastspitzen (Cloud-Container in VMs, orchestriert z.B. mit Kubernetes, Docker)
• Die Reversibilität von Entscheidungen ermöglichend = möglichst wenig Endgültigkeit
• Cybersecurity by Design: das veraltete und angreifbare Modell "Burggraben" (Perimeteransatz) wird durch Härtung auf allen Ebenen ersetzt. Auch gelingendes Social Engineering (Human Hacking) darf nicht zu erfolgreichen Angriffen führen. Hierzu kann der Wirtschaftspsychologe ganz besonders gut beitragen.
• Testbarkeit bereits im Entwurfsstadium und Ermöglichung automatisierter statischer und dynamischer Tests. Auch Leistungstests, Überlasttests, Fuzzy‑ und Chaos‑Testing, Prüfung der Metriken zum Grad der Modularisierung, des Zusammenhalts und der Kopplung sowie verbotene Programmierbefehle u.v.m. sind hier enthalten. Möglichst mit einem Dashboard‑Tool.
• Cloud‑Native: Beispielsweise verlangt das Abfangen von Lastspitzen mittels Containern, dass die Anwendung mehrfach parallel laufen kann - diese muss dazu passend entwickelt sein. Ein Aufwand, der auf seine Sinnhaftigkeit im Vergleich zu anderen Lösungen gut durchdacht sein will.
• Geringe Entropieanfälligkeit: Das Anhäkeln von Workarounds und Ähnliches senkt die Qualität der Software progressiv zügig. Bekannte Prinzipien der Personalführung (wie wäre ein Inhouse‑Coachingprozess? 🙄 Sorry, konnte nicht anders 😉.) in Verbindung mit passendem DevOps sind ein Start dazu...
• [...]

An dieser Stelle noch eine stark verkürzte Beispielgeschichte aus variantenreicher Praxis: Ein System bricht des Nachts immer mal wieder zusammen. Die Person des Betriebsteams in Bereitschaft wird regelmäßig jede dritte Nacht geweckt und findet heraus, dass eine Log‑Datei fehlerhafterweise so füllig beschrieben wird, dass die Festplatte überläuft. Löschen ist der sofortige nächtliche Quick‑Fix. Dann schreibt sie ein Ticket - die Entwickler können (wollen?) das Ganze allerdings tagsüber nicht nachvollziehen. Nach einigen Malen ist die Person aus dem Betriebsteam genervt und schreibt ein Skript, das die Logdatei stündlich automatisch löscht. Halleluja, Problem gelöst und das, ohne diese halbdebilen Sturköpfe 🙄 aus anderen Abteilungen zu benötigen. Echt jetzt? Natürlich nicht. Kunden rund um die Welt werden weiterhin durch die Disfunktion erst verärgert, dann verscheucht. Die Ab‑Teilungsstruktur (bewusst so geschrieben) und historisch entstandene und laufen ergänzte Missliebigkeiten verhindern eine angemessene, kooperative RCA (Root Cause Analysis). Eine wirtschaftspsychologisch kluge Integration von Personen und Abteilungen können in Verbindung mit DevOps geeignet sein, Probleme dieser Art für alle Zeit gründlich zu mindern. Aber machen wir uns nichts vor: eine Teambuilding‑Maßnahme im Wald wird hier kaum die Lösung bringen. Eine Weiterbildung der Führungskräfte hin zu tatsächlich hilfreicher Handlungskompetenz dagegen schon. Aber: an einem Seminartag ist das nicht zu schaffen.

Eine langfristig taugliche Datenarchitektur bedient sich in ähnlicher Weise kombinatorisch u.a. folgender Grundarchitekturen (mehr dazu unter Data Engineering).

• Data Warehouse: eindeutig strukturierte Daten mit definierter Semantik z.B. für KPIs, ML und KI. Leider zwangsläufig monolithisch und damit u.a. ein besonderes Security-Risiko. Data Markets könnten die Lösung sein. Oder auch nicht.
• Data Lake: Sammelstelle für Daten verschiedener Art wie Dokumente, Bilder, Audios, Videos, pdf u.v.m. Da der Mensch dazu neigt, Systeme zu übernutzen, könnte sich bei ungenügender Führung eine Müllhalde entwickeln.
• Data Swamp: z.B. für sog. "Write‑Once‑Read‑Never‑Daten (WORN)", wie sie z.B. für regulatorische Anforderungen vorzuhalten sind. Hierfür werden spezielle Angebote genutzt, bei denen Upload und Speicher extrem billig und der Abruf teuer ist. In Bezug auf Fehlnutzung gilt das vorher Gesagte.
• Auch Repositorys haben eine Architektur. Ob Monorepo oder Multi‑Projekt‑Repository oder was‑auch‑immer will gut durchdacht sein. Erst grübeln, dann dübeln.
• [...]

Diese und viele andere Begriffe sind weder gesetzlich noch fachlich verbindlich definiert. Wie die am wenigsten schleche Lösung aussieht, wird aus dem Geschäftsmodell und seine vermutbaren zukünftigen Szenarien im Rahmen moderierter Workshops mit den wichtigsten Stakeholdern abzuleiten sein. Ob Brown- oder Greenfield oder auch die auf das Geschäftsfeld bezogene Bedeutung von Skalierbarkeit, Elastizität, Verfügbarkeit, Reliabilität und die Notwendigkeit, bei Fehlfunktion oder teilweise gelingenden Cyberangriffen eine elegante (graceful) Form der Funktionsminderung zu zeigen, ist individuell zu entscheiden. Da nicht alles einfach miteinander vereinbar ist, werden gut moderierte Abstimmungsprozesse erforderlich sein, mit deren Hilfe ein am Geschäftsmodell orientiertes Design für Daten und Software definiert wird.

Die verschiedenen „Gewerke“ sollten sich folglich insgesamt gut abstimmen, damit später alles zusammenpasst. Wie bei Gebäuden, sprechen wir auch im Bereich der Software incl. Maschinellem Lernen ML und Künstlicher Intelligenz KI/AI von einer „Architektur“ - und auch so ziemlich aus dem selben Grund. Ihre fachgerechte Gestaltung anhand bewährter Architektur- und Entwurfsmuster zwingt alle Beteiligten zu sorgfältigem, am gesamten SDLC orientierten Nachdenken (SDLC: Software Development Life Cycle). Gut moderierte Meetings nehmen späterem Chaos während des Betriebs früh (nahezu) jeden Wind aus den Segeln. Das sehr stark vereinfachte Beispiel links macht das Prizip deutlich: Das Team hat sich beispielsweise entschlossen, ein Agentensystem zur Dokumentation mit Python, Visual Studio Code und z.B. Claude aufzubauen. In gut moderierten Meetings wurde die Grundstruktur entschieden: Es wird das sog. „Pipeline‑Architekturmuster“ gewählt. Über MCP‑Server (MCP: Model Context Protocol) werden die verschiedenen Dokumente eingelesen (Option: RAG-Retrieval Augmented Generation). Ein erster Agent erstellt daraus eine vereinheitliche (normalisierte) Art der Datendarstellung: Markdown. Dann optimiert ein generatives LLM (Large Language Model) in einer Schleife, bis der Output den Qualitätsprüfungs-Agenten erfolgreich passiert. Abschließend erzeugt ein Agent aus dem normalisierten Markdown‑Inhalt ein Word‑Dokument, welches die Dokumentation darstellt. Natürlich wird diese erste Übersichts-Architektur in der Praxis durch Detaillierungen ergänzt, bevor es im nächsten Schritt von V‑Modell und DevOps an die Realisierung des Agentensystems geht.

Während einer hochwertig moderierten Erstellungsphase von Visualisierungen in den 14 Diagrammarten von UML und begleitender natürlicher Sprache finden sehr nützliche Erkenntnis- und Abstimmungsprozesse statt: Anforderungs‑ und weitere Lücken werden geschlossen, Security‑Risiken durch Design gemildert, Schnittstellen systematisch vor dem Hintergrund des gesamten Projektes definiert und es werden Betrieb, Wartung, Wiederverwendbarkeit und die Außerbetriebsetzung samt Ersatz gemeisam von Allen und von Anfang an mitbedacht. Left‑Shift par excellence!

Reden wir jetzt darüber!