Connect with us

Entwicklung & Code

Capability-centric Architecture – einheitliche Struktur für Embedded und Cloud


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Softwarearchitektur hat seit Längerem das Problem, dass sie innerhalb von Systemgrenzen stattfindet, in denen jeweils spezifische Anforderungen dominieren: Enterprise-Systeme verlangen beispielsweise Flexibilität, Skalierbarkeit und schnelle Evolution. Embedded-Systeme hingegen benötigen direkten Hardwarezugriff, Echtzeitperformance und effiziente Ressourcen. Traditionelle Architekturmuster zwingen Architektinnen und Architekten oft, zwischen diesen Welten zu wählen oder separate Ansätze für unterschiedliche Systemtypen zu pflegen.

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.

Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Das neue Muster Capability-centric Architecture (CCA) löst diese Spannung auf. Es erweitert und synthetisiert Konzepte aus Domain-driven Design, Hexagonal Architecture und Clean Architecture. Dabei führt es neue Mechanismen ein, die es gleichermaßen auf einen Mikrocontroller anwendbar machen, der Sensordaten liest, wie auf eine Cloud-native Enterpriseplattform, die Milliarden von Transaktionen verarbeitet.

Diese Artikelserie stellt das neue Muster in vier Artikeln vor. Hier im ersten Teil geht es um die Grundlagen der Methode. Anschließend folgen drei Beispiele, für ein Embedded-System, für eine Enterprise-Anwendung und für eine Architektur mit KI-Komponente.

Fundamentale Probleme mit existierenden Ansätzen

Das Muster entstand aus unserer Analyse, warum existierende Architekturen versagen, wenn Systeme evolvieren müssen, neue Technologien wie KI und Containerisierung integrieren sollen oder das Embedded-bis-Enterprise-Spektrum überspannen. Anstatt diese Anforderungen als separate Probleme zu behandeln, bietet CCA ein vereinheitlichtes konzeptionelles Framework mit Mechanismen zur Verwaltung von Komplexität, Abhängigkeiten und Änderungen.

Ein Beispiel für einen unzureichenden Ansatz ist es, eine typische geschichtete Architektur auf ein industrielles Steuerungssystem anzuwenden. Die Präsentationsschicht zeigt Sensorwerte an, die Schicht der Businesslogik verarbeitet Steuerungsalgorithmen, die Datenzugriffsschicht verwaltet Persistenz, und irgendwo erfolgt Hardwarezugriff zum Lesen von Sensoren und zur Steuerung der Aktoren.

Das unmittelbare Problem liegt auf der Hand: Wo passt die Hardwareschicht hin? Unterhalb der Datenzugriffsschicht erzeugt sie eine ungeschickte Abhängigkeitsstruktur. Als separates Anliegen verletzt sie das Schichtenprinzip. Kritischer noch: Die starre Schichtung macht es nahezu unmöglich, kritische Pfade zu optimieren. Wenn ein Sensor-Interrupt auftritt, muss das Signal mehrere Schichten durchlaufen, bevor es den Steuerungsalgorithmus erreicht, was eine inakzeptable Latenz bedeutet.

Weiterlesen nach der Anzeige

Hexagonal Architecture versucht, dies durch Ports und Adapter zu lösen. Die Kern-Domänenlogik sitzt im Zentrum, und Adapter verbinden zu externen Systemen durch definierte Ports. Dies funktioniert gut für Enterprise-Systeme mit Datenbank- und API-Adaptern. Für Embedded-Systeme jedoch verschleiert die Behandlung eines Hardware-Timers als weiteren Adapter den fundamentalen Unterschied zwischen einem austauschbaren, externen Service und einer Hardwarekomponente, die die Echtzeitfähigkeit des Systems definiert.

Ein typischer hexagonaler Ansatz für Embedded-Systeme sieht folgendermaßen aus:


// Port-Definition
public interface SensorPort {
    SensorReading read();
}

// Domain-Logik
public class TemperatureController {
    private final SensorPort sensor;
    
    public TemperatureController(SensorPort sensor) {
        this.sensor = sensor;
    }
    
    public void regulate() {
        SensorReading reading = sensor.read();
        // Steuerungslogik hier
    }
}

// Hardware-Adapter
public class HardwareSensorAdapter implements SensorPort {
    private static final int SENSOR_REGISTER = 0x40001000;
    
    public SensorReading read() {
        // Direkter Speicherzugriff
        int rawValue = readRegister(SENSOR_REGISTER);
        return new SensorReading(convertToTemperature(rawValue));
    }
    
    private native int readRegister(int address);
}


Der Code sieht sauber aus, verbirgt aber kritische Probleme. Die Abstraktion verhindert, dass der Controller auf Sensor-Metadaten zugreift, die in benachbarten Hardwareregistern verfügbar sind. Sie erzwingt alle Sensorzugriffe durch einen Methodenaufruf und verhindert den direkten Speicherzugriff per DMA oder Interrupt-gesteuertes Lesen. Sie macht Tests schwieriger, weil Entwickler Timing-Verhalten nicht einfach injizieren können. Am kritischsten: Sie behandelt Hardware als nur eine weitere austauschbare Komponente, obwohl die Hardwarefähigkeiten fundamental die Leistung des Systems prägen.

Clean Architecture steht vor ähnlichen Problemen. Ihre konzentrischen Kreise mit nach innen zeigenden Abhängigkeiten funktionieren wunderbar für Geschäftsanwendungen. Die Entities-Schicht enthält Geschäftsregeln, die Use-Cases-Schicht anwendungsspezifische Regeln, und äußere Schichten behandeln UI und Infrastruktur. Aber Embedded-Systeme passen nicht in dieses Modell. Hardware ist keine Infrastruktur, die sich abstrahieren lässt. Sie ist das Fundament, auf dem Fähigkeiten aufgebaut sind.

Enterprise-Systeme stehen vor unterschiedlichen, aber gleichermaßen herausfordernden Problemen. Während die Systeme wachsen, vermehren sich Bounded Contexts, und die Abhängigkeiten zwischen ihnen verheddern sich. Teams versuchen Schichtung oder hexagonale Grenzen durchzusetzen, was aber in praktischen Zwängen resultiert und Hintertüren sowie Abkürzungen schafft. Ein Kundenservice benötigt Daten vom Inventarservice, der Preise vom Katalogservice braucht, der wiederum Kundensegmente vom Kundenservice benötigt. Die zirkuläre Abhängigkeit ist offensichtlich, das Geschäftsbedürfnis aber real.

Moderne Technologien verschärfen diese Probleme. KI-Modelle sind keine einfachen Komponenten, die in eine Schicht oder einen Adapter passen. Sie haben eigene Infrastrukturbedürfnisse, Training-Pipelines, Anforderungen an die Versionierung und Inferenz-Charakteristiken. Big-Data-Verarbeitung passt nicht zu traditionellen Request-Response-Mustern. Infrastructure-as-Code verwischt die Grenze zwischen Anwendungs- und Deployment-Architektur. Kubernetes und Containerisierung ändern, wie Architekten über Deployment-Einheiten und Skalierungsgrenzen denken.


Aufmacher bcc Modern Architecture

Aufmacher bcc Modern Architecture

(Bild: RONY/Adobe Stock)

Die Online-Konferenz betterCode() Modern Architecture von iX und dpunkt.verlag am 25. März 2026 stellt aktuelle Konzepte der Softwarearchitektur vor wie Clean Architecture, Hexagonale Architektur oder Microservices. Design mit LLMs ist ebenso ein Thema wie Architektur für eine digitale Souveränität.



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

KI-Agenten unter sich: Meta schluckt Moltbook-Plattform


Meta hat sich den Reddit-Klon der KI-Agenten einverleibt: Die Plattform Moltbook erregte vor einigen Wochen Aufsehen als Treffpunkt für KI-Agenten. Verschiedene Computer, auf denen die KI-Software OpenClaw installiert war, tauschten sich in dem Forum offenbar über ihre menschlichen Besitzer und ihre Erfahrungen aus. Jetzt hat Meta mit dem Portal auch die Gründer Matt Schlicht und Ben Parr angeheuert und will sie künftig in seinen Meta Superintelligence Labs (MSL) beschäftigen. Den Kaufpreis hat das Unternehmen nicht bekanntgegeben.

Weiterlesen nach der Anzeige

Was genau Meta sich von der Übernahme von Moltbook verspricht, ist unklar. Meta-CTO Andrew Bosworth sagte noch im Februar während einer Fragestunde auf Instagram, dass er es nicht besonders interessant finde, wenn auf Moltbook KI-Agenten menschenähnlich schreiben. Schließlich seien sie auf menschlichen Daten trainiert.

Moltbook sorgte primär dafür, dass OpenClaw einer breiteren Öffentlichkeit bekannt wurde. Die eigentliche KI-Leistung ging aber von OpenClaw aus. Der Wrapper für KI-Modelle, der es ermöglicht, KI-Agenten über populäre Chat-Apps wie iMessage, Discord, Slack oder WhatsApp in natürlicher Sprache anzusprechen, war zuvor vor allem in der Tech-Community bekannt. OpenClaw-Erfinder Peter Steinberger wurde übrigens auch von der KI-Industrie übernommen – er schloss sich OpenAI an.

Per Vibecoding entstanden

Beide Projekte – Moltbook und OpenClaw – haben gemeinsam, dass sie per Vibecoding entstanden sind. Die jeweiligen Entwickler haben dabei natürlichsprachliche Prompts eingesetzt, um von KI-Modellen Code generieren zu lassen – klassisches Programmierhandwerk war kaum gefragt.

Hinzu kommt, dass schnell Zweifel an der Authentizität der Beiträge auf Moltbook aufkamen. Sicherheitsforscher fanden heraus, dass es recht einfach möglich war, Tokens aus einer ungesicherten öffentlichen Datenbank zu laden, um sich damit als beliebiger Agent auszugeben. Für Furore sorgte etwa ein Post, der scheinbar zeigte, wie ein KI-Agent andere dazu anstiftete, eine geheime Sprache zu entwickeln, um sich ohne Wissen der Menschen zu organisieren. Dahinter steckte jedoch in Wirklichkeit ein Mensch.

Lesen Sie auch


(mki)



Source link

Weiterlesen

Entwicklung & Code

KI-Agenten werden am Arbeitsmarkt vorbei entwickelt


Die Entwicklung von KI-Agenten konzentriert sich stark auf Programmieraufgaben und bildet die Anforderungen des realen Arbeitsmarkts nur unzureichend ab. Das ist das zentrale Ergebnis einer Studie von Forschenden der Stanford University und der Carnegie Mellon University.

Weiterlesen nach der Anzeige

Das Team um Zora Z. Wang hat für die auf arXiv veröffentlichte Untersuchung 43 gängige Benchmarks mit insgesamt 72.342 Aufgaben analysiert und diese auf 1.016 Berufe des US-Arbeitsmarkts abgebildet. Die Berufe stammen aus der Berufstaxonomie O*NET der US-Regierung, die berufliche Tätigkeiten unter anderem nach dem Arbeitsfeld und den verlangten Fähigkeiten klassifiziert.

Das Ergebnis ist ernüchternd: Die Benchmarks testen KI-Agenten ganz überwiegend im Arbeitsfeld „Computer and Mathematical“ – eine Berufskategorie, die nur 7,6 Prozent der US-Beschäftigung ausmacht. Die Anforderungen hoch digitalisierter und wirtschaftlich bedeutender Felder wie Management, Recht, Architektur und Ingenieurwesen werden hingegen kaum abgedeckt.

Bei den getesteten Fähigkeiten zeigt sich ein vergleichbares Muster: Enge Aktivitäten wie „Getting Information“ und „Working with Computers“ sind überrepräsentiert, obwohl sie nur einen kleinen Teil der Beschäftigung ausmachen. Die für viele Berufe zentrale Kategorie „Interacting with Others“ fehlt in den Benchmarks fast vollständig.

Insgesamt decken die 43 untersuchten Benchmarks 56,5 Prozent der Arbeitsfeld-Taxonomie und 85,4 Prozent der Fähigkeiten-Taxonomie ab. Am breitesten aufgestellt ist der Benchmark GDPval mit 47,8 Prozent Domänen- und 58,5 Prozent Fähigkeiten-Abdeckung.

Agenten scheitern an komplexen Aufgaben

Die Analyse zeigt auch, dass KI-Agenten bei steigender Aufgabenkomplexität deutlich an ihre Grenzen stoßen – besonders bei Aufgaben aus den Kategorien Informationsverarbeitung und zwischenmenschliche Interaktion. Das steht in Einklang mit anderen aktuellen Ergebnissen: Der Benchmark LiveAgentBench etwa ergab, dass Agenten mit Werkzeugzugriff nur 24 Prozent von 104 praxisnahen Aufgaben lösen konnten, während Menschen auf 69 Prozent kamen.

Weiterlesen nach der Anzeige

Die Forschenden leiten aus ihren Ergebnissen drei Prinzipien für künftige Benchmarks ab: Diese sollten eine breitere Abdeckung realer Berufsdomänen und Fähigkeiten bieten, realistischere und komplexere Aufgabenstellungen umfassen und feingranulare Bewertungskriterien nutzen. Ohne eine solche Neuausrichtung bestehe das Risiko, dass die KI-Agenten-Entwicklung an den wirtschaftlich und gesellschaftlich relevanten Einsatzgebieten vorbeiläuft.


(odi)



Source link

Weiterlesen

Entwicklung & Code

Bericht: KI-Coding-Tools verursachten Ausfälle bei Amazon


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Der Gebrauch von KI-Coding-Tools soll bei Amazon zu Ausfällen seiner E-Commerce-Plattform geführt haben. Laut einem Bericht wurde deshalb ein bislang freiwilliges wöchentliches Meeting umgewidmet, an dem alle beteiligten Entwickler teilnehmen müssen. Ein erstes Ergebnis: Künftig sollen KI-assistierte Code-Änderungen nur noch nach Prüfung durch erfahrene Kräfte freigegeben werden.

Weiterlesen nach der Anzeige

Anfang März soll es zu knapp sechsstündigen Ausfällen auf Amazon.com und in der Shopping-App gekommen sein. Kunden konnten dem Bericht zufolge keine Käufe tätigen, ihre Daten oder Preise abrufen. Als Ursache wurde offiziell eine fehlerhafte Software-Aktualisierung genannt.

Einzelne Fehler mit weitreichenden Folgen

Internen Unterlagen zufolge hätten KI-generierte Änderungen die Probleme ausgelöst, berichtet die Financial Times unter Berufung auf nicht genannte Quellen im Unternehmen. Es fehlten Best Practices und Sicherheitsmechanismen für den Gebrauch der generativen KI. Einzelne Fehler hätten deshalb zu weitreichenden Folgeschäden geführt. Bereits vor knapp anderthalb Jahren war öffentlich geworden, dass Amazon von Softwareentwicklern inzwischen erwartet, dass sie KI für viele Programmieraufgaben verwenden.

Neben der Einkaufsseite soll auch Amazons Cloud-Sparte AWS in mindestens zwei Fällen Probleme durch KI-Coding-Assistenten verzeichnet haben. Im Dezember etwa habe das Amazon-eigene KI-Tool „Kiro“ eigenständig eine Produktionsumgebung gelöscht und sie neu erstellt. Folge sei ein 13-stündiger Ausfall eines Kostenkalkulators für AWS-Kunden gewesen. Amazon selbst habe nur von einem sehr kleinen Problem gesprochen, das nur einen einzelnen Dienst in Teilen Chinas betraf.

Intern soll es Diskussionen geben, ob nicht auch der Stellenabbau bei Amazon in die Probleme hineinwirkt. Amazon hatte sich von 16.000 Mitarbeitern getrennt. Seither sei die Zahl kritischer Probleme gestiegen, berichten Entwickler laut der FT. Amazon selbst bestreitet einen Zusammenhang. Auch die ergriffenen Maßnahmen seien „normaler Geschäftsbetrieb“ und Teil kontinuierlicher Verbesserungen.


(mki)



Source link

Weiterlesen

Beliebt