Connect with us

Entwicklung & Code

Die vier Apokalyptischen Reiter der Aufwandsschätzung von Cloud-Legacy-Projekten


close notice

This article is also available in
English.

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

Viele ältere Anwendungen profitieren deutlich von einer Modernisierung zu einer Cloud‑Native‑Architektur. Dieser Ansatz löst bestehende Probleme durch neue Technologien, bietet Entwicklerinnen und Entwicklern eine moderne Arbeitsumgebung und eröffnet neue Absatzchancen als Software‑as‑a‑Service. Verschiedenen Studien zufolge ist Modernisierung bei einer Mehrheit der Unternehmen unvermeidlich, weil deren Altanwendungen geschäftskritisch sind (siehe Lünendonk: Unternehmen ringen mit der IT-Modernisierung und Thinkwise: Legacy-Modernisierung – Warnsignale ernst nehmen). Daher wächst das Interesse, bestehende Kernsysteme zu modernisieren und fit für die Cloud zu machen.

Weiterlesen nach der Anzeige


Thomas Zühlke, Cloud Solution Architect, adesso

Thomas Zühlke, Cloud Solution Architect, adesso

Thomas Zühlke ist Cloud-Architekt bei adesso SE mit fast 20 Jahren Berufserfahrung, davon die letzten neun Jahre ausschließlich im Cloud-Umfeld. Er berät Kunden bei der Adaption der Azure Cloud, erstellt Roadmaps, entwirft Migrationsstrategie und Modernisierungskonzepte. Trotz vorwiegender Konzeptionsarbeit begeistert er sich weiterhin für die technische Umsetzung der entworfenen Lösungen.

Die DOAG Cloud Native Community (DCNC) vernetzt Interessierte und Anwender aus Deutschland, Österreich und der Schweiz für den Informations- und Erfahrungsaustausch zu Themen rund um Cloud Native. Gemeinsam organisieren sie überregionale Veranstaltungen wie die CloudLand („Das Cloud Native Festival“), die sich wichtigen Themen widmet: AI & ML, DevOps, Compute / Storage / Network, Data & BI, Security & Compliance, Public Cloud, Architecture, Organization & Culture, Customer Stories, Sovereign Cloud und Cloud-native Software Engineering.
Im Rahmen der Cloud Native Kolumne beleuchten Expertinnen und Experten aus der Community regelmäßig die verschiedensten Trends und Aspekte Cloud-nativer Softwareentwicklung und -bereitstellung.

Einer Modernisierung geht meist ein Konzept voraus. Dieses analysiert alte und neue Anforderungen und beschreibt, wie sie umgesetzt werden sollen. Es benennt betriebliche Anpassungen und konzipiert neue Teamstrukturen. Auf dieser Basis erstellt das Unternehmen Schulungspläne für die beteiligten Mitarbeitenden. Alle Änderungen fließen in eine Roadmap ein, die sowohl verpflichtende als auch optionale Schritte mit ihren jeweiligen Kosten abbildet.

Oft ist schon vor dem Modernisierungskonzept eine erste Aufwandsschätzung nötig, etwa für die Budgetplanung. Diese Schätzung ist schwierig, weil Anwendungen komplex sind und sich konkrete Änderungen erst nach einer Analyse bestimmen lassen. Manchmal stehen mehrere Systeme zur Auswahl. Dann müssen Architektinnen und Architekten den geeignetsten Kandidaten identifizieren und eine grobe Kostenschätzung für die kommenden Jahre entwickeln. Unternehmen erwarten in dieser Phase häufig eine schnelle Einschätzung mit nachvollziehbaren Zahlen – quasi ein fundiertes Bauchgefühl.

Weiterlesen nach der Anzeige

Zur Veranschaulichung dient ein reales Beispielprojekt. Das Produkt läuft seit acht Jahren und umfasst ein Team aus einem Frontend-Entwickler, einem Backend-Entwickler und einem Architekten, die sich um die Weiterentwicklung kümmern – alle in Vollzeit. Pro Jahr entstehen rund 600 Personentage an Aufwand; über acht Jahre summiert sich das auf 4800 Personentage. Das Team war zu Beginn möglicherweise größer, dieser Effekt ist über die lange Laufzeit jedoch vernachlässigbar. Der Projektleiter bzw. Product Owner ist in dieser Betrachtung nicht enthalten, da der Fokus für die Berechnung auf den Entwicklungsaufwänden liegen soll.

Erfahrungen der vergangenen Jahre zeigen im Allgemeinen, dass für eine minimale Modernisierung und Cloud‑Readiness etwa 10 bis 30 Prozent der ursprünglichen Entwicklungskosten anfallen. Dieser Aufwand umfasst Änderungen an Konfigurationen, den Austausch einzelner Komponenten durch höherwertige Dienste sowie die Anpassung von Querschnittsthemen. Er gilt nicht für reine Lift‑and‑Shift‑Szenarien oder vollständige Neuimplementierungen, da jene deutlich weniger beziehungsweise diese erheblich mehr Aufwand erfordern.

Die Berechnungen setzen voraus, dass das bestehende Team die Modernisierung eigenständig durchführt – ohne externe Unterstützung und zusätzlichen Schulungsbedarf. Für das Beispielprodukt ergibt sich ein Aufwand zwischen 480 und 1440 Personentagen. Diese Spanne ist groß, insbesondere bei älteren Produkten. Je länger ein System läuft, desto größer ist der Anteil der Wartungsphase, die keine neuen Funktionen schafft und dadurch die ursprünglichen Entwicklungsaufwände verwässert. Zudem bleibt unklar, welche Softwareteile konkret angepasst oder modernisiert werden müssen. Der nächste Abschnitt zeigt, wie sich diese Werte genauer herleiten lassen, und nennt die wichtigsten Kostentreiber.

Mehrere Studien haben untersucht, wie sich Ressourcen im Lebenszyklus eines Softwareprojekts verteilen. Sie zeigen ähnliche Ergebnisse, setzen jedoch unterschiedliche Schwerpunkte. Ein bekanntes Beispiel ist „The Staged Model of the Software Lifecycle: A New Perspective on Software Evolution“.

Es gliedert den Lebenszyklus in folgende Phasen (siehe Abbildung unten):

  • Initial Development
  • Evolution
  • Servicing
  • Phase‑Out
  • Close‑Down

Das Modell unterscheidet zwischen aktiver (Evolution) und passiver Wartung (Servicing). Aktive Wartung gilt als Entwicklungsaufwand, da sie Erweiterungen durch neue Features, regulatorische Anforderungen oder Mandantenanpassungen umfasst. Passive Wartung betrifft ausschließlich erhaltende Maßnahmen wie Bugfixes oder Bibliotheksupdates und fließt nicht in die Modernisierungskosten ein. Weitergehende Informationen zu Modellen, die unter anderem auch die mit der Zeit steigenden Wartungskosten berücksichtigen, finden sich in: How much does software development cost? In-depth guide for 2025; Lebenszyklus-Kosten von IT Produkten und IT Project Outsourcing In 2025 – A Comprehensive Guide.

Aus der Erfahrung haben sich folgende, in der Abbildung hervorgehobenen Werte bewährt:

  • Initial Development ≈ 15 Prozent
  • Evolution ≈ 25 Prozent


Phasen des Software-Lebenszyklus

Phasen des Software-Lebenszyklus

Verteilung von Aufwänden auf die Phasen des Software-Lebenszyklus

Die Phasen Phase‑Out, Close‑Down und Servicing bleiben unberücksichtigt, da sie keine relevante Entwicklungstätigkeit enthalten. Der Entwicklungsanteil der Software beträgt (inklusive etwa 5 Prozent für die zu Beginn häufig erhöhte Lernkurve und eventuell benötigte Proof-of-Concepts) somit 40 Prozent von 4800 Personentagen, also 1920 Personentage. Davon entfallen 10 bis 30 Prozent auf die Modernisierung, also 192 bis 576 Personentage. Diese Werte sind realistisch, doch bleibt die Bandbreite groß. Um sie zu verfeinern, müssen die größten Aufwandstreiber identifiziert werden.


CloudLand 2026 – das Cloud Native Festival

CloudLand 2026 – das Cloud Native Festival

(Bild: cloudland.org)

Vom 19. bis 22. Mai 2026 finden Interessierte beim Cloud Native Festival CloudLand ein prall gefülltes Line-up mit mehr als 200 Highlights – darunter die beiden neuen Themenbereiche „Open Source“ und „Platform Engineering“. Besucherinnen und Besucher erwartet eine bunte Mischung überwiegend interaktiver Sessions, Hands-ons und Workshops, begleitet von einem umfassenden Rahmenprogramm, das zum aktiven Mitmachen einlädt.

Tickets für das Festival und Unterkünfte im Heide Park Soltau lassen sich über die Festival-Homepage buchen.

Je gründlicher die Analyse einer Modernisierung, desto genauer wird die Schätzung. Für eine solide Näherung genügt es, die zentralen Aufwandstreiber zu erkennen und zu prüfen, ob sie im Projekt relevant sind. Einige Basisbausteine müssen bei jeder Modernisierung angepasst werden, etwa CI/CD‑Pipelines oder Logging‑Mechanismen. Solche Arbeiten lassen sich pauschal mit rund 5 Prozent der Entwicklungsaufwände veranschlagen.

Daneben existieren optionale Basisbausteine, die den Aufwand erheblich steigern können. Diese entscheidenden Faktoren werden sinnbildlich als apokalyptische Reiter bezeichnet. Jeder dieser vier Treiber kann mit etwa 5 Prozent der Entwickleraufwände bewertet werden:

Architektur der Geschäftslogik

Häufig erfolgt eine Umstellung auf Microservices oder Self‑Contained Systems. Dadurch entstehen neue System‑Schnitte, Kommunikationswege und Skalierungsmechanismen, während die Business‑Logik selbst unverändert bleibt.

Architektur des Speicherkonzepts

Ein Wechsel von relationalen Datenbanken zu Dokumenten‑ oder Graphenmodellen oder die Einführung von Event Sourcing/CQRS erfordert umfassende Anpassungen an Persistenz, Migration und Nachrichtenverarbeitung.

Mandantenkonzept

SaaS‑Lösungen verlangen Multi‑Tenant‑Fähigkeit. Altanwendungen nutzen häufig getrennte Installationen je Mandant und sind nicht auf zentrale Datenhaltung oder gemeinsame Berechtigungsmodelle ausgelegt.

Authentifizierung und Autorisierung (AuthN/AuthZ)

Viele Systeme verwenden noch eine eigene Benutzerverwaltung oder veraltete Identity‑Provider. Die Migration zu Cloud‑Providern (z. B. Azure Entra ID) sowie die Einführung verschlüsselter Kommunikation und zentraler Token‑Validierung erhöhen den Aufwand deutlich.

Selten umfasst die Modernisierung zusätzlich ein Redesign des GUI‑Konzepts oder den Wechsel zu einem neuen Frontend‑Framework. Auch dafür kann ein pauschaler Mehraufwand von 5 Prozent angesetzt werden. Darüber hinaus entstehen gelegentlich parallele Projekte für Infrastruktur und Governance (Landing Zones), um die modernisierte Lösung sicher betreiben zu können.

Im Beispielprojekt greifen drei dieser Reiter: die Umstellung auf Microservices (+ 5 %), die Einführung eines Mandantenkonzepts (+ 5 %) und die Modernisierung des Security‑Konzepts (+ 5 %). Zusammen mit der Basisanpassung ergibt sich ein Gesamtaufwand von 20 Prozent der 1920 Entwicklungs‑Personentage, also etwa 384 Personentage.

Die Kombination aus Entwicklungsaufwandsanalyse und Bewertung einzelner Änderungsbausteine liefert eine ausreichend präzise Schätzung. Da genaue Prozentwerte schwer festzulegen sind, empfiehlt sich eine Unterteilung in Fünf‑Prozent‑Schritte, sofern keine detaillierteren Informationen vorliegen. Eine Schätzung bleibt jedoch stets eine Annäherung.

Vor jeder Modernisierung ist deshalb ein detailliertes Konzept unverzichtbar. Es identifiziert obligatorische und optionale Änderungen, bewertet deren Aufwand und legt einen konkreten Umsetzungsplan fest. Fehlt dieses Konzept, scheitert die Modernisierung oft schon vor dem Projektstart.


(map)



Source link

Entwicklung & Code

Kuratierte KI-Agenten-Sammlung von JetBrains und Zed


Der IDE-Anbieter JetBrains und das Unternehmen hinter dem Sourcecode-Editor Zed, Zed Industries, haben gemeinsam die ACP Registry veröffentlicht. Diese soll es Entwicklerinnen und Entwicklern vereinfachen, mit dem Agent Client Protocol (ACP) kompatible KI-Coding Agenten bereitzustellen, aufzufinden und in Entwicklungsumgebungen zu installieren.

Weiterlesen nach der Anzeige

In der ACP Registry finden sich derzeit ausschließlich kuratierte KI-Agenten und -Extensions, die Authentifizierung unterstützen. Sie folgen dem Agent Client Protocol (ACP), einem standardisierten, offenen Protokoll für das Zusammenspiel von KI-Agenten und Editoren. ACP wurde von JetBrains und Zed Industries erstmals im Oktober 2025 vorgestellt.

Laut den Herstellern war das Protokoll bereits ein großer Schritt nach vorn, doch die Distribution war bisher fragmentiert. Agenten mussten für jeden Client als Extension verfügbar gemacht oder manuell durch User installiert werden. Hier setzt die ACP Registry an: Entwicklerinnen und Entwickler können ihre geeignete Implementierung eines Agenten oder einer Extension einmal registrieren, und diese wird dann für jeden ACP-kompatiblen Client verfügbar.

Sowohl Zed als auch die Entwicklungsumgebungen von JetBrains besitzen integrierten ACP-Registry-Support, um die Agenten auf einfache Weise zu installieren und ihre jeweils aktuellste Version zu verwenden. In JetBrains-IDEs – ab Version 2025.3.2 und mit JetBrains AI (253.30387.147) – lassen sich Agenten beispielsweise im Agent-Picker-Menü unter „Install From ACP Registry…“ auswählen und installieren. In Zed sieht die ACP-Registry-Seite wie folgt aus:


Zed bietet eine integrierte Anbindung an die ACP Registry.

Zed bietet eine integrierte Anbindung an die ACP Registry.

Zed bietet eine integrierte Anbindung an die ACP Registry.

(Bild: Zed Industries)

Weiterlesen nach der Anzeige

Die kuratierte ACP Registry enthält aktuell die folgenden neun Agenten und Extensions:

  • Auggie CLI
  • Claude Code
  • Codex CLI
  • Factory Droid
  • Gemini CLI
  • GitHub Copilot
  • Mistral Vibe
  • OpenCode
  • Qwen Code

Weitere Informationen zur ACP Registry finden sich auf der offiziellen Website und im GitHub-Repository sowie in den Ankündigungen von JetBrains und Zed Industries.

Lesen Sie auch


(mai)



Source link

Weiterlesen

Entwicklung & Code

Microsofts neues Kommandozeilen-Tool: Windows-Apps ohne Visual Studio entwickeln


close notice

This article is also available in
English.

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

Microsoft hat ein neues Kommandozeilen-Tool für die Windows-App-Entwicklung vorgestellt. winapp CLI soll den Entwicklungsprozess für Anwendungen vereinfachen, die mit Frameworks wie Electron oder Sprachen wie Rust, C++ und .NET erstellt werden. Es verbindet plattformübergreifende Entwicklung mit der nativen Windows-Umgebung. Das Open-Source-Tool befindet sich derzeit in der Public Preview und ist auf GitHub frei verfügbar.

Weiterlesen nach der Anzeige

Das zentrale Versprechen: Was früher zwölf manuelle Schritte erforderte, soll nun ein einziger Befehl erledigen. Der Befehl winapp init lädt die benötigten SDKs wie Windows SDK und Windows App SDK automatisch herunter, generiert Code-Projektionen wie C++/WinRT und konfiguriert Manifeste, Assets, Zertifikate sowie Abhängigkeiten. Das Tool ist bewusst so konzipiert, dass Entwickler ihre gewohnten Editoren – also VS Code genauso wie andere IDEs – weiterverwenden können. Mit winapp restore lässt sich die exakte Entwicklungsumgebung für gemeinsam genutzte Projekte oder in CI/CD-Pipelines wiederherstellen.

Besonders für Cross-Platform-Entwickler interessant ist die Funktion create-debug-identity. Sie fügt einer ausführbaren Datei temporär eine Package Identity hinzu, ohne dass die Anwendung vollständig als MSIX-Paket verpackt werden muss. Das beschleunigt den Entwicklungszyklus erheblich, da moderne Windows-APIs wie die Windows AI APIs, Benachrichtigungen, Shell-Integration oder Hintergrundaufgaben eine solche Identity verwenden.

Für Electron-Entwickler bietet Microsoft ein spezielles npm-Paket an: Mit npm install @microsoft/winappcli --save-dev lässt sich winapp in bestehende Projekte integrieren. Der Befehl winapp node add-electron-debug-identity injiziert die Package Identity direkt in den laufenden Prozess. Zusätzlich stellt das Paket @microsoft/winapp-windows-ai Node.js-Projektionen für Microsofts KI-APIs bereit, etwa für lokale Sprachmodelle oder Text- und Bildverarbeitung.

Das Tool übernimmt auch das Erstellen von MSIX-Paketen für die Distribution über den Microsoft Store oder Sideloading. Mit winapp pack ./my-app-files --cert ./devcert.pfx erzeugt es Store-fähige oder für manuelles Deployment vorbereitete Pakete. Entwicklerzertifikate lassen sich per winapp cert generate erstellen und optional lokal installieren. Auch das Aktualisieren von Manifest-Ressourcen funktioniert über die CLI, etwa mit winapp manifest update-assets C:\images\my-logo.png.

Weiterlesen nach der Anzeige

Für Continuous-Integration-Workflows bietet Microsoft Actions für GitHub Actions und Azure DevOps an. Die setup-WinAppCli-Action installiert winapp automatisch in der Pipeline. Entwickler können damit konsistente Build-Umgebungen schaffen, ohne manuell SDKs oder Tools konfigurieren zu müssen.

winapp CLI ist laut Ankündigung explizit als Ergänzung für Entwickler gedacht, die außerhalb des Visual-Studio-Ökosystems arbeiten. Neben Electron und Rust unterstützt winapp auch C++ mit CMake, .NET, Dart und weitere Sprachen und Frameworks. Guides für diese Technologien sowie Beispielprojekte finden sich im GitHub-Repository.

Die Installation erfolgt wahlweise über WinGet mit winget install Microsoft.winappcli --source winget, als npm-Paket oder manuell über GitHub Releases. Während der Public Preview sammelt Microsoft Feedback über das GitHub-Repository. Welche Features Priorität erhalten und wann eine finale Version erscheint, ist aktuell offen. Für Entwickler, die auf alternative Cross-Platform-Frameworks setzen, bleiben Optionen wie .NET MAUI, Avalonia, Uno Platform oder React Native for Desktop bestehen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Google-DeepMind-Chef: Der nächste Einstein könnte eine KI sein


Es ist das ewige Versprechen der Branche und das Feigenblatt, um bis dahin das Verbrennen von Milliarden Dollar und Unmengen an Energie zu rechtfertigen: die Suche nach der AGI. Die Artificial General Intelligence (Künstliche allgemeine Intelligenz) gilt als heiliger Gral der KI-Forscher. Wenn die Software lernt, ohne menschliche Hilfe zu lernen, sollen undenkbare Fortschritte möglich sein. Manch einer hat auch Angst, dass sich die KI dann gegen den Menschen wendet. Aber in zunehmendem Maße halten Menschen diese Zukunftsvision für eine Fata Morgana und den Weg dorthin noch für sehr weit.

Weiterlesen nach der Anzeige

Demis Hassabis, Chef von Googles KI-Sparte DeepMind, hält die AGI für erreichbar. Aber erst in fünf bis zehn Jahren. In einem Interview mit Alex Kantrowitz von Big Technology ließ er kein gutes Haar an seinem Mitbewerber OpenAI und dessen Chef Sam Altman. Man dürfe AGI nicht als Marketingbegriff verwenden, mahnt er. Die allgemeine künstliche Intelligenz sei ein System, das alle kognitiven Fähigkeiten zeigen kann, die Menschen haben, sagt er: „Und ich meine alle.“

Aber wo ist der Nutzen für die Menschheit? Den würde diese Form von KI erst haben, wenn sie der Menschheit zu neuen Durchbrüchen verhilft, erklärt Hassabis. Es sei nicht damit getan, eine mathematische Gleichung oder eine Vermutung zu lösen. Bahnbrechende Vermutungen sind gefragt, ein neuer Einstein. Oder im künstlerischen Bereich ein Picasso oder ein Mozart. Und zwar mit Fähigkeiten und einer Schlagzahl, wie sie bei Menschen kaum oder gar nicht möglich wäre.

Und obwohl er die Ansicht vertritt, dass die Fähigkeiten heutiger KI-Modelle noch gar nicht alle erkannt und ausgeschöpft sind, zeigt sich Hassabis überzeugt, dass diese noch weit von einer AGI entfernt sind. Heutige KI habe ein „Goldfischgehirn“. Sie kann das Internet durchsuchen, aber dieses Wissen ändere das Modell nicht und sei nach der Sitzung wieder vergessen. Eine Superintelligenz würde sogar noch weitergehen, sie könnte andere Systeme wie Wettersatelliten integrieren oder in 14 Dimensionen denken – Dinge, zu denen kein Mensch fähig wäre.

Weiterlesen nach der Anzeige

KI brauche auf dem Weg zur AGI noch mehrere Durchbrüche: Neben kontinuierlichem Lernen seien das effizientere Kontextfenster und langfristige Planung. Während das menschliche Gehirn mit selektiver Aufmerksamkeit nur das Wichtige verarbeitet, behandelt KI alle Informationen im Kontext gleich. Dies ist ineffizient und teuer.

In dem Bühnengespräch in Davos ging Hassabis auch auf die Frage ein, ob Google wie OpenAI plane, in seinem Chatbot Werbung zu integrieren. Viel Lob verteilte Hassabis für Start-up Anthropic, in das Google bereits Milliarden Dollar investiert hat. Deren Entwicklungs-Tool Claude Code sei sehr gelungen. Google selbst will die Fähigkeiten seines KI-Modells Gemini mit der neu veröffentlichten IDE Antigravity besser zur Geltung bringen.

Konkret äußerte sich Hassabis zu Smart Glasses: Google arbeitet mit Partnern wie Warby Parker, Gentle Monster und Samsung an einer neuen Generation KI-gestützter Brillen, die „vielleicht bis zum Sommer“ auf den Markt kommen sollen. Anders als beim gescheiterten Google Glass vor gut zehn Jahren seien nun sowohl die Form ausgereift als auch – entscheidend – die „Killer-App“ vorhanden: ein universeller digitaler Assistent, der freihändig im Alltag hilft. Hassabis selbst arbeitet persönlich an dem Projekt mit.


(mki)



Source link

Weiterlesen

Beliebt