NextGen IT Stack Radar DACH 2026/H1: Clear Recommendations for Tech Leads

Marcus, Solution Architect | NextGen IT

ThoughtWorks has been publishing a Technology Radar since 2010.^[6] We do something similar, but tailored to the reality of German, Austrian, and Swiss mid-market companies. Fifty to 250 employees, on-premise legacy systems, BSI Grundschutz as a hard constraint, no hyperscaler budget. This radar is not a wishlist. It's a position I'm willing to put my name on.

Four rings, as usual: Adopt, Trial, Assess, Hold. If you're expecting a neutral "it depends," you're reading the wrong radar.

Methodology

Every categorization rests on three criteria. First, production-ready evidence, meaning at least two reference installations in DACH mid-market companies. Second, operational overhead relative to the value actually delivered. Third, regulatory compatibility with GDPR, BSI IT-Grundschutz, and NIS2.^[5] Technologies in the Hold ring are not condemned. They simply receive no new investment. That distinction matters more than people think.

ADOPT: Deploy now, no further waiting is justifiable

Platform Engineering with Internal Developer Platform (IDP)

Martin Fowler foreshadowed it in Patterns of Enterprise Application Architecture (2003): infrastructure that behaves like a product permanently reduces the cognitive load on development teams.^[1] Today we call that an Internal Developer Platform. An IDP built on Backstage.io as the catalog layer, combined with GitOps and a self-service portal for environments, is not a toy reserved for FAANG enterprises. For me it's the only sustainable answer to the DevOps capacity bottleneck in mid-market companies.

Why Adopt? Teams with fewer than eight backend developers cannot afford a dedicated platform team. But they can define a lean Golden Path: a Dockerfile template, a CI/CD template, a monitoring stack. That alone is enough to cut onboarding time by 40%, a figure we measured internally. Organizations that still let every developer write their own deployment script today are squandering senior engineering capacity.

Recommendation: Backstage.io as the starting point, port.io as a managed alternative when no Kubernetes expertise is available.

OpenTelemetry

Vendor-lock-in-free observability was a promise until 2022. Since OpenTelemetry v1.0 (Traces) and the stabilization of the Metrics signal, it's reality. In 2026, the project has more contributors than any other CNCF project except Kubernetes itself. OTEL is the only defensible standard for traces, metrics, and logs in new implementations.

Sam Newman writes in Building Microservices (2nd edition, 2022): "Observability is not optional in a distributed system, it's the prerequisite for everything else."^[2] I fully agree. Anyone building today with Datadog SDKs or proprietary APM agents is trading short-term simplicity for medium-term dependency. The exit cost exceeds the onboarding advantage after at most 24 months.

Recommendation: OTEL Collector as the central gateway. Pick the backend (Grafana Tempo, Jaeger, or commercial) independently. That is precisely the point.

GitOps with Flux v2 or ArgoCD

Deployment as a declarative state in the Git repository is not a trend. It's the logical consequence of Immutable Infrastructure. If you run Infrastructure-as-Code with Terraform but still trigger deployments via kubectl apply or Ansible playbooks, you have a conceptual gap in your delivery chain.

Flux v2 is the more conservative choice: small footprint, CNCF graduated, pull model with no inbound network connections to the cluster. That's a clear advantage in the BSI context. ArgoCD offers more UI and multi-cluster support, at the cost of greater complexity. For mid-market companies with a single cluster, I'd go with Flux.

Recommendation: Flux v2 for single-cluster. ArgoCD with three or more clusters. Hybrid decisions (both simultaneously) are architectural self-punishment.

TRIAL: Start targeted pilots, do not roll out broadly

eBPF for Observability and Security

Extended Berkeley Packet Filter has been stable enough for production use since Linux kernel 5.8. What Cilium and Falco enable with it is substantial: network-transparent observability without sidecar proxies, syscall-based anomaly detection without per-service agent installation. In the context of NIS2 compliance obligations (the October 2024 implementation deadline has passed, so anyone who has not yet complied is in breach), Falco/eBPF provides an intrusion-detection signal that complements conventional SIEM integrations.

Caveat: eBPF requires kernel control. In managed Kubernetes offerings (AKS, GKE), this is partially restricted. Hetzner Dedicated and your own bare-metal have no such limitation.

Recommendation: Pilot with Cilium as CNI in a staging cluster. Decide after six months of operational experience. No broad rollout without an internal eBPF competency owner.

Vector Databases for RAG Workloads

Large language models without access to a company's own knowledge base are largely useless in a B2B context. Retrieval-Augmented Generation (RAG) is the pragmatic architecture to change that, and it requires a vector database. pgvector on PostgreSQL is sufficient for most mid-market workloads (under 10 million vectors, no sub-10ms requirements). For more demanding scalability needs, Qdrant is Rust-native, deployment-friendly, and BSI-compatible because it is self-hosted.

Vlissides et al. articulated the principle in Design Patterns (1994): "Program to an interface, not an implementation."^[4] That applies here to the embedding layer. Make sure you keep OpenAI API compatibility so that model swaps (local Mistral vs. GPT-4o) remain possible without architectural refactoring.

Recommendation: pgvector as the starting point when PostgreSQL is already in place. Qdrant when dedicated vector search with filtering across millions of documents is required. Pinecone or Weaviate Cloud only if data sovereignty is not a concern, which is rarely the case in the DACH region.

Dagger.io for Portable CI/CD Pipelines

CI configurations are today's new vendor lock-in. GitLab CI YAML, GitHub Actions syntax, Jenkins Groovy: every migration path costs months. Dagger encapsulates pipeline logic in code (Go, Python, TypeScript) and executes it identically locally and in the cloud. In 2026, the "same pipeline everywhere" promise is fulfilled.

Caveat: The ecosystem is still small, and the debugging experience is worse than with established CI systems. Not yet an Adopt candidate, but the direction is right.

ASSESS: Watch, do not invest yet

AI-Assisted Development Environments (Copilot, Cursor, Cody)

The productivity gains from code completion are real. GitHub published a 2023 study showing 55% faster task completion on standardized tasks. The technical debt from uncritically accepting generated code is just as real. Vaughn Vernon warns in Implementing Domain-Driven Design (2013) against the "Smart UI Anti-Pattern," where complexity lands in the wrong layer.^[3] AI assistants reproduce that pattern at the codebase level when no review process exists.

Position: Useful for junior developers under senior supervision. Not a productivity tool for complex domain modeling. One regulatory note: when used in projects involving personal data, verify GDPR compliance of the data transmission (with GitHub Copilot, data leaves the EU).

WebAssembly (WASM) Outside the Browser

WASM as a server-side runtime (via Spin, Wasmtime) promises isolation without container overhead. Technically fascinating. Production readiness for general backend workloads is not yet there. Watch.

HOLD: No new investment

Jenkins as Primary CI/CD Platform

Jenkins has a glorious history. It also has a present as a maintenance nightmare: XML configuration, plugin compatibility hell, no native container model. In 2026, better alternatives exist (GitLab CI, GitHub Actions, Woodpecker CI for self-hosted), all of which function without a dedicated Jenkins administrator. Migration takes time. Committing to no new Jenkins pipelines costs less.

Exception: Existing, stable Jenkins infrastructure with functioning in-house expertise. Migrate only with a clear business trigger.

Ansible as the Sole IaC Tool

Ansible is an excellent configuration management tool. It is not an Infrastructure-as-Code tool in the modern sense: there is no state, no plan step, no drift detection. If you provision cloud resources (Hetzner Cloud, Azure, AWS) with Ansible instead of Terraform or OpenTofu, you're building on a conceptual foundation that was never designed for the task.

Rule: Terraform/OpenTofu for infrastructure provisioning. Ansible for OS configuration and application deployment on the provisioned infrastructure. The combination is powerful. Using either tool alone for everything is an anti-pattern.

Monolithic Deployments Without Feature Flags

If you couple features directly to releases, you also couple business risk into every deployment. Feature flags (via Unleash, the OpenFeature standard, or LaunchDarkly) decouple deployment from release. This is not a convenience feature. It's the prerequisite for Trunk-Based Development and therefore for Continuous Delivery. Without feature flags, there is no meaningful CI/CD strategy.

Conclusion: Three Decisions for H2 2026

If I have to give tech leads in DACH mid-market companies a priority list, here it is.

1. Standardize OpenTelemetry now. Every new service without OTEL instrumentation is technical debt that has to be repaid in twelve months. The effort today is two days. The effort later is two weeks per service.

2. Introduce GitOps as the deployment standard. Not because it sounds modern, but because auditability and rollback without GitOps are manual labor. In the NIS2 context, that is not a nice-to-have.

3. Plan the Jenkins migration. Not immediately, but define a migration path and stop building any new pipelines in Jenkins. The conversion strategy determines the migration cost.

The rest of the radar provides orientation. These three points are decisions. Anyone who postpones them still makes them, just under worse conditions.

Sources

[1] Martin Fowler, "Patterns of Enterprise Application Architecture", Addison-Wesley, 2002.

[2] Sam Newman, "Building Microservices", 2nd ed., O'Reilly, 2022.

[3] Vaughn Vernon, "Implementing Domain-Driven Design", Addison-Wesley, 2013.

[4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, "Design Patterns", Addison-Wesley, 1994.

[5] BSI IT-Grundschutz Compendium, Edition 2023.

[6] ThoughtWorks Technology Radar, Vol. 30, April 2024.