Michael

Seit über vier Jahrzehnten beschäftige ich mich mit technischen Systemen – nicht nur damit, wie sie funktionieren, sondern warum sie funktionieren.
Mich interessieren weniger einzelne Technologien als die Regeln, Abhängigkeiten und Rückmeldungen, durch die Systeme entstehen, zusammenarbeiten und über viele Jahre bestehen können.
Dabei zieht sich eine Frage durch sehr unterschiedliche Stationen meiner Arbeit:

Was passiert in einem System tatsächlich – und stimmt das mit dem überein, was wir von ihm erwarten?

Systeme verstehen – Stück für Stück

Komplexe Systeme lassen sich nicht vollständig überblicken.
Schon ein Unternehmen mit einigen Dutzend oder hundert Menschen besteht aus technischen Systemen, Arbeitsabläufen, informellem Wissen, Ausnahmen und Abhängigkeiten, die niemand vollständig im Kopf hat.
Deshalb versuche ich nicht, einem System möglichst schnell ein fertiges Modell oder eine neue Architektur überzustülpen.
Ich grenze einen relevanten Ausschnitt ab, schaue mir seine Prozesse, Zustände und bekannten Schnittstellen?Definierter Übergang zwischen Systemen oder Systembestandteilen, an dem relevante Eigenschaften, Wechselwirkungen oder Beziehungen festgelegt werden

Auch bekannt als: Interface, System Interface an und erweitere das Bild, wenn neue Abhängigkeiten sichtbar werden.
Das eigene Modell des Systems bleibt dabei genau das: ein Modell. Es darf unvollständig sein – solange bekannt ist, wo Wissen fehlt oder Annahmen noch nicht überprüft wurden.

Kontrolle und Abweichung

Ein großer Teil meiner Arbeit bestand schon immer darin, erwartete und tatsächliche Zustände miteinander zu vergleichen.
Das begann bei Auswertungen und Controlling-Systemen, führte über Baustellenkalkulation, Unternehmenssoftware und Systemmigrationen bis zu Plattformen, Produktionssystemen und heutigen KI-gestützten Arbeitsprozessen.
Eine Abweichung ist dabei zunächst eine Information.
Sie kann ein Fehler sein, ein Risiko, eine tolerierbare Besonderheit – oder etwas Interessantes, aus dem sich eine bessere Lösung entwickelt.
Mich interessieren deshalb fehlertolerante?Fähigkeit eines Systems, trotz bestimmter Fehler seine geforderte Funktion weiterhin zu erbringen

Auch bekannt als: Fault Tolerance, Fehlertolerantes System und resiliente?Fähigkeit eines Systems, unter Störungen und Veränderungen wesentliche Funktionen zu erhalten, wiederherzustellen oder angepasst fortzuführen

Auch bekannt als: Resilience, System Resilience, Systemresilienz Systeme: Systeme, die ihren Zustand sichtbar machen, mit Abweichungen umgehen können und trotzdem veränderbar bleiben.

Von Mainframes bis zu verteilten Plattformen

Meine berufliche Arbeit begann in den 1980er-Jahren in Elektrotechnik, Automatisierung und Großrechnerumgebungen.
Seitdem durfte ich sehr unterschiedliche Systeme kennenlernen und mitgestalten.

Dazu gehörten unter anderem:

• Auswertungs-, Controlling- und Migrationssysteme im Fieldservice
• Unternehmenssoftware für Bauunternehmen
• Buchhaltung, Kalkulation und betriebliche Prozesse
• vernetzte Standorte und Unix-Systeme
• Redaktions-, Verbands- und Intranet-Plattformen
• Logistik- und Vermittlungsplattformen
• Live-Streaming-, Abrechnungs- und Bezahlsysteme
• internetbasierte Maschinensteuerungen mit Rückmeldung und nutzungsabhängiger Abrechnung
• internationale Embedded- und Set-Top-Box-Projekte
• Produktions- und Digitalisierungsprozesse im Maschinenbau
• Server-, Netzwerk- und Systemmigrationen
• Verlags- und Publikationssysteme

Die eingesetzten Technologien wechselten dabei ständig.
Die grundlegenden Fragen erstaunlich selten.

Architektur, Integration und Betrieb

Software existiert selten für sich allein.
Mich interessieren besonders die Stellen, an denen Systeme miteinander verbunden werden müssen: Schnittstellen, Datenflüsse, Migrationen, alte und neue Komponenten, technische und betriebliche Prozesse.
Dazu gehören heute Begriffe wie Systems Analysis?Strukturierte Untersuchung eines Systems, seiner Eigenschaften und Zusammenhänge als Grundlage für technische Entscheidungen

Auch bekannt als: Systems Analysis, System Analysis, Systems Architecture?Grundlegende Struktur eines Systems mit seinen Elementen, Beziehungen, Schnittstellen und den Prinzipien, nach denen es aufgebaut ist

Auch bekannt als: Systems Architecture, System Architecture, Solution Architecture?Architektur einer konkreten technischen oder technisch-organisatorischen Lösung für eine abgegrenzte Problemstellung oder Menge von Anforderungen

Auch bekannt als: Solution Architecture, Solution-Architektur, Systems Integration?Verbindung unterschiedlicher Komponenten oder Systeme zu einem zusammenarbeitenden Gesamtsystem

Auch bekannt als: Systems Integration, System Integration, Verification & Validation?Prüfung, ob ein System festgelegte Anforderungen erfüllt und für seinen vorgesehenen Einsatzzweck geeignet ist

Auch bekannt als: Verification and Validation, Verification & Validation, V&V oder Legacy Modernization?Gezielte Veränderung eines bestehenden Systems oder seiner Umgebung, um aktuelle technische oder organisatorische Anforderungen besser zu erfüllen

Auch bekannt als: Legacy Modernization, Legacy-System-Modernisierung, Application Modernization.

Für mich beschreiben sie unterschiedliche Ausschnitte derselben Arbeit:

erst verstehen, was tatsächlich vorhanden ist – und danach entscheiden, was sinnvoll verändert werden kann.

Programmierung gehört dabei seit Jahrzehnten zu meinem Werkzeugkasten. Sie war für mich aber selten Selbstzweck.
Wenn ein kleines Programm ein Problem löst, wird ein kleines Programm geschrieben. Wenn keine neue Software notwendig ist, ist das häufig die bessere Lösung.

KI als Teil eines Systems

Seit 2025 beschäftige ich mich intensiver mit Large Language Models und KI-gestützten Arbeitsprozessen.
Der Einstieg war zunächst pragmatisch: Recherche, Webentwicklung, Programmierung und Texte konnten plötzlich erheblich schneller entstehen.
Damit wurden aber auch die Grenzen schnell sichtbar.
Gut formulierte Ergebnisse müssen nicht richtig sein. Ausführliche Anweisungen erzeugen nicht automatisch gleichbleibende Resultate. Mehr Kontext hilft nur so lange, wie der relevante Kontext noch verarbeitet werden kann. Und auch eine zweite KI kann denselben plausibel klingenden Fehler übersehen wie die erste.

Daraus entstanden neue Fragen:

• Wie lässt sich der für eine Aufgabe relevante Kontext bestimmen?
• Wie bleiben Regeln außerhalb eines probabilistischen?Eigenschaft eines Modells oder Systems, bei dem Wahrscheinlichkeiten Bestandteil der Berechnung oder Beschreibung möglicher Ergebnisse sind
  
  Auch bekannt als: Probabilistic, Probabilistisches System, Probabilistic System Modells überprüfbar?
• Wie können Ergebnisse unabhängig gegengeprüft werden?
• Welche Aussagen lassen sich gegen reale Systeme verifizieren?
• Wo muss ein Mensch die Verantwortung behalten?
• Wie baut man Arbeitsprozesse, die mit den Grenzen von KI umgehen, statt sie zu ignorieren?

Heute werden Teile dieses Arbeitsfeldes unter anderem als Context Engineering?Systematische Gestaltung und Bereitstellung des für eine konkrete KI-Aufgabe relevanten Kontexts

Auch bekannt als: Kontext-Engineering, Context Management, Kontextmanagement, AI Evaluation?Systematische Bewertung der Eigenschaften, Ergebnisse und des Verhaltens eines KI-Systems anhand festgelegter Kriterien

Auch bekannt als: AI Evaluation, AI Evaluation and Testing, LLM Evaluation, LLM-Evaluation oder AI Assurance?Systematische Erzeugung, Bewertung und Kommunikation von Evidenz, um begründetes Vertrauen in relevante Eigenschaften und den Einsatz eines KI-Systems zu ermöglichen

Auch bekannt als: KI-Assurance, Artificial Intelligence Assurance bezeichnet.
Bei dragons@work entstehen dazu eigene Werkzeuge und Regelwerke. Viele davon befinden sich selbst noch in Entwicklung und werden zunächst an unserer eigenen Arbeit erprobt.

Warum Low-Tech?

Technologien kommen und gehen. Gute Modelle bleiben.
Ich mag kleine, überschaubare Systeme.
Je weniger unnötige Komponenten ein System besitzt, desto leichter lässt sich nachvollziehen, was darin passiert, welche Wirkung eine Änderung hat und wo ein Fehler oder eine unerwartete Abweichung entsteht.
Low-Tech?Technischer Gestaltungsansatz, der einen tatsächlichen Bedarf mit einer möglichst angemessenen, verständlichen, langlebigen und beherrschbaren Lösung erfüllt

Auch bekannt als: Low Tech, Low Technology, Low-Tech-Ansatz bedeutet für mich deshalb nicht, alte Technik um ihrer selbst willen einzusetzen.
Es bedeutet, nur so viel Technik einzusetzen, wie ein Problem tatsächlich benötigt.
Das verbindet sich mit einem zweiten wichtigen Thema meiner heutigen Arbeit: digitale Souveränität?Fähigkeit, über digitale Systeme, Daten und Abhängigkeiten selbstbestimmt entscheiden und bei Veränderungen handlungsfähig bleiben zu können

Auch bekannt als: Digital Sovereignty, Digitale Unabhängigkeit, Technologische Souveränität.
Offene Formate?Datenformat, dessen technische Struktur und Bedeutung ausreichend öffentlich dokumentiert sind, sodass unabhängige Implementierungen Daten erzeugen, lesen und verarbeiten können

Auch bekannt als: Open Data Format, Offenes Format, Open Format, freie Software, Self-Hosting?Betrieb eines digitalen Dienstes oder Systems unter eigener technischer und organisatorischer Verantwortung

Auch bekannt als: Self Hosting, Selbsthosting, Eigenbetrieb und nachvollziehbare Abhängigkeiten können helfen, Systeme langfristig kontrollierbar und veränderbar zu halten.

Technischer Werkzeugkasten

Meine heutige tägliche Arbeit bewegt sich unter anderem in folgenden Bereichen:

• OpenBSD und Debian
• Lua, C und Shell
• Server- und Netzwerkarchitekturen
• Self-Hosting
• statische Websites und langlebige Web-Infrastrukturen
• offene Datenformate und föderierte Systeme
• technische Dokumentation
• KI-gestützte Entwicklungs- und Prüfprozesse

Über die Jahrzehnte kamen zahlreiche weitere Betriebssysteme, Programmiersprachen, Datenbanken, Plattformen und Werkzeuge hinzu.
Sie sind Erfahrung und Werkzeugkasten – nicht meine Berufsbezeichnung.

Nicht nur digital

Nicht alle Erfahrungen der vergangenen Jahrzehnte fanden vor einem Bildschirm statt.
Dazu gehören unter anderem Elektrotechnik und Montage, Handel und Vertrieb, Unternehmensführung, Buchhaltung, Verlagsarbeit, Märkte und auch der Bau unseres eigenen kleinen Wagens.
Diese Erfahrungen sind für meine technische Arbeit nicht bedeutungslos.
Technische Systeme werden von Menschen gebaut und benutzt und sind fast immer Teil größerer betrieblicher oder gesellschaftlicher Zusammenhänge.

Woran ich heute arbeite

Bei dragons@work entstehen heute Bücher, Software und offene Regelwerke rund um technische Systeme und digitale Unabhängigkeit.

Dazu gehören unter anderem:

• Fachbücher und technische Dokumentationen
• Referenzimplementierungen
• offene Protokolle und Datenformate
• Werkzeuge für langlebige und nachvollziehbare Systeme
• Verfahren zur Prüfung technischer und KI-gestützter Arbeit
• Biocodie als Versuch, Regeln, Zustände, Abweichungen und Entwicklung in technischen Systemen anders zu betrachten

Viele dieser Arbeiten greifen ineinander.
Bücher beschreiben Konzepte, Regelwerke schaffen gemeinsame Grundlagen und Software dient dazu, Ideen praktisch auszuprobieren und überprüfbar zu machen.

Technologien verändern sich. Gute Modelle bleiben.