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.

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.

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.

Wenn ein Bäcker regelmäßig eine große Tüte Brötchen des Mitbewerbers einkauft, betreibt er entweder intensive Marktbeobachtung – oder sieht seine Bedürfnisse von seinem eigenen Produkt nicht vollständig abgedeckt. Ähnliche Fragen stellen sich Beobachter mit Blick auf Microsoft. Nach Informationen des US-Tech-Portals The Verge setzt der Software-Riese verstärkt auf das KI-Entwicklungs-Tool Claude Code von seinem Mitbewerber Anthropic. Vornehmlich zum Vergleich, wie es heißt. Doch die Intensität des Tests ist dennoch ungewöhnlich.

Laut The Verge nutzen mehrere tausend Mitarbeiter aus verschiedenen Entwicklerteams Claude Code. Beim CoreAI-Team sollen die Tests schon seit Monaten laufen. Inzwischen sei auch die „Experiences + Devices Division“ aufgefordert worden, Claude Code zu installieren. Dieses Team betreut die für Microsoft wichtigen Produkte Windows, Microsoft 365, Outlook, Teams, Bing, Edge und Surface.

Ungewöhnlicher Faible für die Konkurrenz?

Microsofts Werkzeugauswahl überrascht deshalb, weil das Unternehmen mit dem GitHub Copilot doch über ein eigenes Tool verfügt. Die in Zusammenarbeit mit OpenAI entwickelte Software sei auch weiterhin das primäre KI-Coding-Tool, betont Microsoft.

Dennoch scheint Microsoft auch ein Faible für das Konkurrenzprodukt entwickelt zu haben. Während die Software-Ingenieure beide Tools nutzen und vergleichen sollen, werden Designer und Projektmanager ohne Programmier-Erfahrung dazu ermuntert, damit zu experimentieren, etwa um Prototypen auf den Weg zu bringen. Laut dem Bericht sei aber auch ein möglicher späterer Vertrieb von Claude Code an Azure-Kunden denkbar.

Besonderer Deal mit Anthropic

Das Fachmagazin The Information zählt Microsoft zu den Top-Kunden von Anthropic. Beide Unternehmen hätten eine besondere Vereinbarung geschlossen, die Anthropic dazu verpflichte, im Umfang von 30 Milliarden US-Dollar Rechenkapazitäten von Microsofts Cloud Azure zu nutzen. Microsoft rechne umgekehrt die Kosten für die eigene Nutzung der Anthropic-Modelle auf die Verkaufsquoten für Anthropics Azure-Nutzung an. Das sei ungewöhnlich, da normalerweise nur eigene Produkte und die aus der Partnerschaft mit OpenAI auf diese Weise gefördert würden.

(mki)

Google hat angekündigt, den kostenlosen Zugriff auf seinen vollständigen Suchindex für Entwickler einzustellen. Neue Programmable Search Engines können ab sofort nur noch maximal 50 Domains durchsuchen. Die bisher verfügbare Option „Search the entire web“ steht für neue Engines nicht mehr zur Verfügung.

Betreiber bestehender Suchmaschinen, die mehr als 50 Domains indexieren oder den vollständigen Web-Index nutzen, müssen bis zum 1. Januar 2027 auf eine Alternative umsteigen. Google begründet den Schritt in der Ankündigung mit einer „Evolution zu fokussierten, leistungsfähigeren Lösungen“, die eine bessere Nutzererfahrung bieten sollen.

Vertex AI Search als kostenpflichtige Alternative

Als Ersatz für den kostenlosen Vollzugriff verweist Google auf Vertex AI Search, einen Cloud-basierten Enterprise-Dienst mit KI-gestützten Features wie konversationeller Suche und Grounding (Verankerung von KI-Antworten in verifizierbaren Datenquellen). Wer weiterhin den vollständigen Google-Index nutzen möchte, muss ein Formular ausfüllen und auf ein individuelles Preisangebot warten. Öffentliche Preise existieren nicht, frühere Paid-API-Angebote kosteten rund 5 US-Dollar pro 1000 Anfragen.

Die Custom Search JSON API wird ebenfalls eingestellt. Nutzer müssen ihre Implementierungen bis zur Frist auf Vertex AI oder den neuen Enterprise-Full-Web-Dienst portieren. Das kostenlose „Sites to search“-Feature für maximal 50 Domains bleibt erhalten und ist laut Google optimal für fokussierte, seitenspezifische Suchergebnisse gedacht.

Indie-Entwickler unter Druck

Die Änderungen treffen besonders Entwickler von Nischensuchmaschinen, Bildungseinrichtungen und Non-Profit-Organisationen. Viele WordPress-Plugins und Drupal-Module, die auf Googles Programmable Search Engine basieren, müssen umgebaut oder eingestellt werden.

Als Alternativen bietet sich selbst gehostete Software wie Meilisearch, Typesense oder Elasticsearch an. Für Web-Index-basierte Anwendungen könnten Dienste wie Common Crawl (ein offenes Web-Archiv) in Kombination mit eigenen Modellen zum Einsatz kommen. Allerdings erreichen diese Alternativen nicht die Aktualität und Vollständigkeit des Google-Index.

Kartellrechtliche Bedenken?

Die Einschränkungen könnten in der EU kartellrechtliche Fragen aufwerfen. Als Gatekeeper im Sinne des Digital Markets Act kontrolliert Alphabet mit der Google-Suche den Zugang zu einem wesentlichen Infrastrukturelement des Internets. Offen ist, ob die Abschaffung des kostenlosen Zugriffs bei gleichzeitiger Einführung kostenpflichtiger Alternativen als wettbewerbswidrig interpretiert wird.

Google argumentiert hingegen, die Vereinfachung seines Produktportfolios diene der Qualität: „Wir vereinfachen und modernisieren unser Angebot, damit Sie das beste Werkzeug für Ihre Ziele auswählen können“, heißt es im Blogpost.

(fo)