Capability-centric Architecture – a unified structure for embedded and cloud

Software architecture has long faced the problem of operating within system boundaries where specific requirements dominate: Enterprise systems, for example, demand flexibility, scalability, and rapid evolution. Embedded systems, on the other hand, require direct hardware access, real-time performance, and efficient resource utilization. Traditional architectural patterns often force architects to choose between these worlds or maintain separate approaches for different system types.

The new Capability-centric Architecture (CCA) pattern resolves this tension. It extends and synthesizes concepts from Domain-driven Design, Hexagonal Architecture, and Clean Architecture. In doing so, it introduces new mechanisms that make it equally applicable to a microcontroller reading sensor data as it is to a cloud-native enterprise platform processing billions of transactions.

This article series introduces the new pattern in four parts. The first part focuses on the fundamentals of the method. It will be followed by three examples: one for an embedded system, one for an enterprise application, and one for an architecture with an AI component.

Fundamental Problems with Existing Approaches

The pattern emerged from our analysis of why existing architectures fail when systems need to evolve, integrate new technologies like AI and containerization, or span the embedded-to-enterprise spectrum. Instead of treating these requirements as separate problems, CCA offers a unified conceptual framework with mechanisms for managing complexity, dependencies, and changes.

One example of an insufficient approach is applying a typical layered architecture to an industrial control system. The presentation layer displays sensor values, the business logic layer processes control algorithms, the data access layer manages persistence, and somewhere, hardware access occurs to read sensors and control actuators.

The immediate issue is obvious: Where does the hardware layer fit? Below the data access layer, it creates an awkward dependency structure. As a separate concern, it violates the layering principle. More critically, the rigid layering makes optimizing critical paths nearly impossible. When a sensor interrupt occurs, the signal must traverse multiple layers before reaching the control algorithm, resulting in unacceptable latency.

Hexagonal Architecture attempts to solve this with ports and adapters. Core domain logic resides at the center, and adapters connect to external systems through defined ports. This works well for enterprise systems with database and API adapters. However, for embedded systems, treating a hardware timer as just another adapter obscures the fundamental difference between a replaceable external service and a hardware component that defines the system's real-time capability.

A typical hexagonal approach for embedded systems looks like this:

// 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);
}

The code looks clean but hides critical issues. The abstraction prevents the controller from accessing sensor metadata available in adjacent hardware registers. It forces all sensor accesses through a method call, preventing direct memory access via DMA or interrupt-driven reading. It makes testing more difficult because developers cannot easily inject timing behavior. Most critically, it treats hardware as just another interchangeable component, even though hardware capabilities fundamentally shape the system's performance.

Clean Architecture faces similar problems. Its concentric circles with inward-pointing dependencies work wonderfully for business applications. The Entities layer contains business rules, the Use Cases layer application-specific rules, and outer layers handle UI and infrastructure. But embedded systems don't fit this model. Hardware is not infrastructure to be abstracted; it is the foundation upon which capabilities are built.

Enterprise systems face different but equally challenging difficulties. As systems grow, bounded contexts proliferate, and dependencies between them become tangled. Teams try to enforce layering or hexagonal boundaries, but this results in practical constraints and creates backdoors and shortcuts. A customer service needs data from the inventory service, which needs prices from the catalog service, which in turn needs customer segments from the customer service. The circular dependency is obvious, but the business need is real.

Modern technologies exacerbate these issues. AI models are not simple components that fit into a layer or an adapter. They have their own infrastructure needs, training pipelines, versioning requirements, and inference characteristics. Big data processing doesn't fit traditional request-response patterns. Infrastructure-as-Code blurs the line between application and deployment architecture. Kubernetes and containerization change how architects think about deployment units and scaling boundaries.

Heise conference on modern software architecture concepts on May 25, 2026

The online conference betterCode() Modern Architecture by iX and dpunkt.verlag on March 25, 2026, presents current software architecture concepts such as Clean Architecture, Hexagonal Architecture, or Microservices. Design with LLMs is also a topic, as is architecture for digital sovereignty.