Nagarro setzt auf ergebnisgebundenes Cloud Native Engineering

Die entscheidende Frage, die jeder Head of Platform in einem regulierten mittelständischen Unternehmen seinem Einkaufsleiter in diesem Quartal stellen sollte, lautet nicht, ob das Monolith modernisiert werden soll. Sie lautet, ob der nächste Modernisierungsvertrag nach Aufwand oder nach Ergebnissen bepreist werden soll. Nagarro hat diese Frage gerade schwerer ausweichbar gemacht.

Das indisch-deutsche Digital-Engineering-Unternehmen hat sein Cloud Native Engineering-Angebot als produktisiertes Modernisierungspaket neu positioniert, das auf ergebnisgebundenen Meilensteinen statt auf Zeit-und-Material-Abrechnung basiert. Für Platform Leads, die ein fünfjähriges Legacy-Refactoring-Budget verwalten, ist diese Preisverschiebung wichtiger als sämtliche darunter liegenden Technologieentscheidungen.

Was geschehen ist

Nagarro SE, der in Frankfurt börsennotierte Digital-Engineering-Spezialist, schärft seinen Fokus auf die groß angelegte Anwendungsmodernisierung mit seinem Cloud Native Engineering-Service. Wie AD HOC NEWS berichtete, hilft das Beratungs- und Implementierungsangebot Unternehmen dabei, Legacy-Software für Kubernetes, Microservices und Multi-Cloud-Umgebungen neu aufzubauen – mit einem besonderen Fokus auf Unternehmen, die KI-fähig werden und gleichzeitig technische Schulden abbauen wollen.

Die Mechanismen sind entscheidend. Jedes Engagement beginnt mit einer Assessment-Phase, die bestehende Anwendungen, Infrastruktur, Release-Prozesse und Incident-Historie inventarisiert. Daraus entsteht ein Zielzustand-Blueprint, der festlegt, welche Workloads regehosted, replattformt oder vollständig refaktoriert werden sollen. Von dort aus treibt Nagarro eine inkrementelle Modernisierung voran statt einer Big-Bang-Migration, wobei Anwendungsdomänen dort in Microservices zerlegt werden, wo die wirtschaftliche Rechtfertigung gegeben ist.

Der Service bündelt Platform Engineering, Site Reliability Engineering und DevSecOps in einem einzigen Engagement, das auf AWS, Azure und Google Cloud läuft. Die Implementierungsarbeit umfasst CI/CD-Pipelines, Infrastructure as Code und Observability-Stacks, mit dem erklärten Ziel, dass neu modernisierte Services mehrmals täglich deployed und über hybride und Multi-Cloud-Umgebungen hinweg überwacht werden können.

Das Preismodell ist der Teil, den die meisten Analysten unterschätzen werden. Nagarro strukturiert Projekte rund um ergebnisgebundene Meilensteine: Reduzierung der Lead Time for Changes, Senkung der Incident-Häufigkeit oder die Migration eines definierten Prozentsatzes von Workloads auf Cloud-native Plattformen innerhalb eines festgelegten Zeitrahmens. Für langfristige Kunden integriert sich Cloud Native Engineering in Managed Services, sodass Nagarros Teams nach der Lieferung weiterhin gemeinsam den Stack betreiben. Die Preisgestaltung bleibt projektbasiert je nach Umfang und Laufzeit, mit Lieferung durch regionale Büros und Remote-Teams weltweit.

Technische Anatomie

Streicht man die Broschüren-Sprache heraus, ist die Architektur ein bekannter Referenz-Stack. Domain-Driven Design zerlegt den Monolith in Bounded Contexts. Diese Kontexte werden containerisiert, über Kubernetes-Distributionen der großen Cloud-Anbieter orchestriert und über Service Meshes miteinander verbunden. Die Referenzmuster entsprechen weitgehend dem, was die Kubernetes-Dokumentation als Multi-Cluster-, Multi-Tenant-Produktionsdeployments beschreibt.

Die DevSecOps-Ebene ist der Bereich, in dem das Engagement in regulierten Sektoren seine Marge verdient. Shift-Left-Sicherheitstests, automatisiertes Dependency Scanning, Secrets Management und Policy-as-Code sind in die Pipeline integriert statt nachträglich eingefügt. Für Kunden aus dem Finanzwesen, dem Gesundheitswesen und dem öffentlichen Sektor ist das kein Nice-to-have. Es ist die einzige Möglichkeit, wie ein Modernisierungsprojekt eine Compliance-Prüfung besteht, ohne die Timeline zu verdoppeln.

Observability erhält gleiches Gewicht. Zentralisierte Metriken, Logs und Traces speisen SRE-Praktiken einschließlich Error Budgets und blameless Postmortems. Dieses Tooling-Stack macht die ergebnisgebundenen Meilensteine überhaupt erst messbar. Man kann keine „reduzierte Incident-Häufigkeit" abrechnen, wenn die bestehende Observability des Kunden keine belastbare Baseline liefern kann. Die Assessment-Phase ist in der Praxis zur Hälfte Discovery und zur Hälfte Instrumentierung: Das Legacy-System muss lesbar gemacht werden, bevor man einen Vertrag verkaufen kann, der verspricht, es zu verbessern.

Die Tooling-Entscheidungen sind pragmatisch. Kubernetes-Distributionen von Hyperscalern, Container Registries, Git-basierte Quellcodeverwaltung, automatisierte Quality Gates, Security Scanning in der Deployment-Pipeline. Eine jüngste Partnerschaft im Testing-Bereich verbindet Nagarros Engineering-Services mit spezialisierten Tooling-Anbietern für Test Automation auf komplexen Web- und Mobile-Frontends. Branchenberichte auf DevOpsdigest haben Nagarros Positionierung als Engineering-Partner bei moderner Test Automation und Cloud-Native-Transformation hervorgehoben, was mit der produktisierten Ausrichtung übereinstimmt.

Die architektonische Grundhaltung dahinter ist konservativ – und das ist ein Feature. Nagarro verkauft kein Rip-and-Replace. Es verkauft eine lange Migration mit messbaren Zwischenzuständen. Für einen CFO, der Modernisierungsausgaben über drei Budgetzyklen amortisieren muss, ist diese Konservativität das eigentliche Produkt.

Wer unter Druck gerät

Die Verlierer in dieser Verschiebung sind nicht andere Systemintegratoren. Es sind interne Platform-Teams, die drei Jahre damit verbracht haben, maßgeschneiderte Modernisierungs-Frameworks zu bauen, und jetzt keine glaubwürdige Kosten-pro-Workload-Zahl für den Vorstand vorlegen können.

Ich würde argumentieren, dass der General Counsel jedes regulierten Unternehmens den CTO diese Woche fragen sollte, ob die aktuellen Modernisierungs-Vendor-Verträge Ergebnisklauseln enthalten oder nur Preislisten. Handelt es sich um Preislisten, zahlt das Unternehmen für Aktivität, nicht für Lieferung. Wenn ein Wettbewerber wie Nagarro mit einem Festpreis auftaucht, der an Release-Frequenz-Verbesserungen geknüpft ist, wird das Einkaufsgespräch schnell unangenehm. Das ist die relevante Verschiebung, die es zu beobachten gilt.

Die Implikationen für den Einstellungsmarkt sind schärfer als sie auf den ersten Blick erscheinen. Wenn ergebnisgebundene Modernisierungsverträge zum Standard im Finanz- und Gesundheitswesen werden, konsolidiert sich die Nachfrage auf ein engeres Qualifikationsprofil: Engineers, die Domain-Driven Decomposition durchführen, Legacy-Systeme für SRE-taugliche Observability instrumentieren und Policy-as-Code in regulierte Pipelines einbringen können. Das ist eine andere Person als der generische Kubernetes-Engineer, den der Markt fünf Jahre lang ausgebildet hat. Erwarten Sie einen Aufpreis auf Platform Engineers mit regulierten Branchen-Erfahrung und einen weicher werdenden Markt für reine Containerisierungsspezialisten.

Mittelgroße Beratungsunternehmen ohne eine produktisierte Cloud-Native-Praxis sind am stärksten gefährdet. Ihr Pitch war Senior-Personal zu einem Tagessatz. Wenn der Auftraggeber einen Nagarro-Festpreis-Ergebnis-Vertrag mit einem 200-tägigen Staff-Augmentation-Engagement vergleichen kann, verliert das Staff-Aug-Deck, sofern es keine glaubwürdige Co-Delivery-Story mitbringt. Boutiquen mit tiefer vertikaler Spezialisierung werden überleben. Generalisten in der Mitte nicht.

Interne Platform-Teams bei Series-B- und Series-C-Fintechs stehen vor einer leiseren Version desselben Drucks. Der Vorstand möchte zunehmend sehen, dass Modernisierungsausgaben an einer marktüblichen Alternative gemessen werden. „Wir könnten das für X an Nagarro auslagern" wird zu einer realen Vergleichszahl, nicht zu einer Hypothese.

Playbook für Engineering-Teams

Für Platform Leads, die in den nächsten 90 Tagen Modernisierungsoptionen evaluieren, sind drei konkrete Maßnahmen diese Woche empfehlenswert.

Erstens: Instrumentieren Sie, bevor Sie architektonisch planen. Die Nagarro Assessment-Phase existiert, weil kein ehrlicher Modernisierungsvertrag ohne Baseline-Metriken zu Lead Time for Changes, Incident-Häufigkeit und Deployment-Frequenz bepreist werden kann. Auch wenn Sie intern bauen, führen Sie dieselbe Bewertung intern durch. Wenn Sie diese Zahlen nicht liefern können, können Sie keinen Vendor-Vorschlag glaubwürdig bewerten und den Fortschritt Ihres eigenen Teams nicht messen.

Zweitens: Trennen Sie die Frage der Vertragsstruktur von der Build-versus-Buy-Frage. Ergebnisgebundene Preisgestaltung ist von mehreren Anbietern erhältlich und kann auch internen Teams über OKRs auferlegt werden, die an dieselben Metriken geknüpft sind. Die interessante strategische Entscheidung ist, ob Ihr Unternehmen die Platform-Engineering-Kompetenz langfristig besitzen oder mieten möchte. Regulierte Sektoren müssen sie in der Regel irgendwann besitzen. Die Frage ist, ob Sie diese Fähigkeit aufbauen, bevor oder nachdem ein Managed-Services-Partner die Migration beschleunigt.

Drittens: Setzen Sie die Sicherheits- und Policy-as-Code-Muster auf Pipeline-Ebene richtig um, bevor Sie Microservices skalieren. Die teuersten Modernisierungsfehler, die ich sehe, entstehen bei Teams, die den Monolith schneller zerlegt haben, als ihr DevSecOps-Tooling mithalten konnte, und dann die nächsten 18 Monate damit verbracht haben, Kontrollen nachzurüsten. Shift-Left, automatisiertes Dependency Scanning und Secrets Management sind in einem 200-Service-Estate nicht optional. Sie sind die tragende Wand.

Teams, die Cloud Native Engineering-Angebote evaluieren – ob von Nagarro oder einem anderen Anbieter – sollten sich eine schärfere Frage stellen: Wie sieht das interne Team in Jahr drei aus, wenn der Managed-Service-Vertrag zur Verlängerung ansteht und sich die Nutzung erneut verändert?

Wichtigste Erkenntnisse

• Nagarros Cloud Native Engineering-Service ist als produktisiertes Modernisierungspaket positioniert, das Platform Engineering, SRE und DevSecOps auf AWS, Azure und Google Cloud kombiniert.
• Ergebnisgebundene Meilensteine, die an Lead Time, Incident-Häufigkeit und Workload-Migrationsanteilen hängen, sind der eigentliche Differenziator – nicht der Technologie-Stack.
• Regulierte Sektoren wie Finanzwesen, Gesundheitswesen und öffentlicher Sektor sind die primäre Zielgruppe, mit DevSecOps und Policy-as-Code als Compliance-Ankerpunkt.
• Interne Platform-Teams sehen sich nun einem marktüblichen Benchmark für Modernisierungsausgaben gegenüber, was Vorstandsgespräche über Build versus Buy verändert.
• Der Einstellungsmarkt wird Platform Engineers mit Erfahrung in regulierten Branchen bevorzugen gegenüber generalistischen Kubernetes-Spezialisten, da sich ergebnisgebundene Verträge ausbreiten.