Die Diskussion um eine mögliche „SaaSpocalypse“ treibt die Softwarebranche seit Monaten um. Der Begriff bringt die Sorge auf den Punkt: dass generative KI und vor allem autonome KI-Agenten das klassische Geschäftsmodell von Software-as-a-Service infrage stellen. Wir sprachen mit dem Tech-Analysten Philipp Klöckner darüber, wohin die Entwicklung geht.

iX: Derzeit wird viel über die SaaSpocalypse gesprochen, selbst große Anbieter wie Salesforce oder SAP stehen an der Börse unter Druck. Ist das eine Überreaktion oder ein fundamentaler Wandel des Softwaremarkts?

Philipp Klöckner: Beides. In einigen Bereichen ist die Reaktion übertrieben, in anderen Fällen sollten Unternehmen tatsächlich vorsichtig sein. Besonders unter Druck geraten Firmen mit klassischen „Per-Seat“-Modellen – also Anbieter, die pro Mitarbeiter abrechnen. Dazu zählen typische Kollaborations- und Projektmanagementtools wie Asana, Monday.com oder Teile der Atlassian-Suite wie Jira.

Der Hintergrund ist weniger, dass KI bereits massiv Jobs ersetzt, sondern dass viele Unternehmen das Overhiring der Coronazeit korrigieren und ihre Organisationen verschlanken. Weniger Mitarbeiter bedeuten automatisch geringeres Wachstum für solche SaaS-Modelle. Zudem lässt sich ein einfaches Kollaborationstool mit Nutzerverwaltung heute relativ schnell KI-gestützt entwickeln. Dadurch steigt der Wettbewerbsdruck erheblich.

Gleichzeitig halte ich manche Marktreaktionen für überzogen. Wenn etwa Anthropic ein neues Feature ankündigt und daraufhin Cybersecurity- oder Observability-Aktien zweistellig fallen, verwechselt das die Realität des Unternehmenseinkaufs mit Tech-Euphorie. Unternehmen wechseln ihre Kernsoftware nicht kurzfristig. Vertrauen, langfristige Verträge und hohe Lock-in-Effekte spielen eine enorme Rolle.

Was allerdings schwieriger wird: Neukundengewinnung. Start-ups, die heute beginnen, werden sich häufiger fragen, ob sie klassische SaaS-Produkte überhaupt noch kaufen oder bestimmte Lösungen selbst bauen. KI senkt die Einstiegshürden erheblich. Trotzdem sollte man die Wirtschaftlichkeit bestehender Software nicht unterschätzen. SaaS-Unternehmen arbeiten oft mit Rohmargen von 80 bis 90 Prozent. Wer Software selbst entwickelt, muss inklusive Wartung, Sicherheit und Zuverlässigkeit günstiger sein als eine bestehende Lizenzlösung – und das ist keineswegs trivial. Ich glaube deshalb nicht, dass Fortune-500-Unternehmen ihre ERP- oder CRM-Systeme kurzfristig durch Vibe-Coding-Lösungen ersetzen werden.

Low-Code- und No-Code-Plattformen haben schon früher versprochen, dass jeder Software bauen kann. Was ist diesmal anders?

Der Unterschied liegt vor allem in den Anforderungen an den Nutzer. Bei No-Code brauchte man oft noch relativ fortgeschrittene Produktmanagement- oder Toolkenntnisse. Mit generativer KI reicht heute Sprache als Interface: Wer ein Problem gut beschreiben kann, kommt deutlich schneller zu funktionierender Software.

Das heißt aber noch nicht automatisch, dass daraus professionelle Produkte entstehen, die man problemlos anderen Unternehmen verkaufen kann. Besonders schwierig bleibt die Integration in bestehende Legacy-Systeme. Die eigentliche Stärke von KI liegt momentan eher darin, neue und vergleichsweise einfache Lösungen „from scratch“ zu entwickeln – insbesondere in Nischenmärkten, für die sich früher kein eigenes Softwareunternehmen gelohnt hätte.

Gehen wir damit in die Richtung hyperindividualisierter Software und hin zu Mikromärkten?

Ja, das halte ich für wahrscheinlich. Vor einigen Jahren tauchte auf der OMR-Messe der Begriff „Disposable Software“ auf – also Wegwerfsoftware. Früher lag der Fokus darauf, möglichst modular und wiederverwendbar zu entwickeln. Künftig könnte Software viel stärker situativ entstehen.

Mit KI kann man für relativ geringe Kosten kleine Anwendungen generieren, testen und später wieder verwerfen oder komplett neu bauen. Dadurch verändert sich auch die Architekturphilosophie: Statt hochgradig modularer Systeme könnten häufiger Monolithen entstehen, die bei Änderungen einfach neu generiert werden. Das könnte bedeuten, dass Software künftig stärker „on demand“ entsteht und weniger langfristig gepflegt wird.

Die fünfte Vorschauversion der kommenden .NET-Version 11.0 ist gestern Abend erschienen. Parallel dazu gab es auch die Version 11904.113 der für .NET 11.0 notwendigen Insiders-Variante von Visual Studio 2026. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.

Sortieren und Paging beim bei Blazor Static SSR

Bei dem in .NET 8.0 eingeführten statischen serverseitigen Rendering (Blazor Static SSR), das als eine Ablösung für ASP.NET Core MVC und ASP.NET Core Razor Pages verstanden werden kann, funktioniert das Tabellensteuerelement QuickGrid, das Microsoft im NuGet-Paket Microsoft.AspNetCore.Components.QuickGrid liefert, bisher nur eingeschränkt. Lediglich bei den interaktiven Varianten Blazor Server und Blazor WebAssembly sowie Blazor Hybrid stehen alle Funktionen des QuickGrid-Steuerelements zur Verfügung.

Seit Blazor 11.0 Preview 5 ist es möglich, dass das QuickGrid-Steuerelement auch in statisch serverseitig gerenderten Blazor-Seiten sortieren und blättern kann. Wenn das Grid nicht interaktiv ist, werden die sortierbaren Spaltenüberschriften und die Seitennavigation als erweiterte HTML-Formulare gerendert, die ihren Zustand über URL-Abfrageparameter (Query String) übertragen. Lädt eine Nutzerin oder ein Nutzer die Seite neu oder kopiert die URL und öffnet sie erneut, bleiben Sortierung und aktuelle Seite erhalten. Dadurch lassen sich diese Zustände einfach per URL teilen oder als Lesezeichen speichern.

Im Schnelltest zeigte sich: In Zusammenarbeit mit Entity Framework Core als Datenquelle mit Paging in der Datenbank erzeugt das Blättern einen Laufzeitfehler: „InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.“

Das folgende Beispiel funktioniert aktuell nur korrekt, wenn es immer alle Datensätze lädt und das Paging im RAM ausführt via

private List flightSet => context.Flights.ToList();

@page "/QuickGridSSR"
@using Microsoft.AspNetCore.Components.QuickGrid
@using Microsoft.EntityFrameworkCore
@inject IDbContextFactory DbFactory
@implements IAsyncDisposable
 
QuickGrid SSR
 

 

  p.FlightNo)" Title="FlugNr" Sortable="true" />
  p.Departure)" Title="Abflugort" Sortable="true">
 
  p.Destination)" Title="Zielort" Sortable="true">
  
  p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
  p.FreeSeats)" Title="Freie Plätze" />

 

 
@code {
 private readonly PaginationState pagination = new() { ItemsPerPage = 15 };
 
 private DA.WWWings.WwwingsV1EnContext context;
 private IQueryable flightSet => context.Flights;
  
 protected override void OnInitialized()
 {
  context = DbFactory.CreateDbContext();
 }
 
 // IAsyncDisposable implementieren, um den DbContext korrekt zu verwerfen, wenn die Komponente nicht mehr benötigt wird
 public async ValueTask DisposeAsync()
 {
  if (context != null)
  {
   await context.DisposeAsync();
  }
 }
}

Listing: QuickGrid mit Blazor Static SSR mit Zugriff auf eine Datenbank via Entity Framework Core

Vereinfachte Session-Handhabung

Blazor Static SSR unterstützt seit der Einführung in .NET 8.0 die in ASP.NET Core verfügbaren serverseitigen Sessions (Cookie .AspNetCore.Session mit Session-ID, Speicherung der Daten im RAM oder einem persistenten Speicher) zur Datenübergabe zwischen Seiten. Bisher mussten Entwicklerinnen und Entwickler dafür das Session-Objekt im HttpContext-Objekt verwenden und komplexe Objekte selbst per JSON serialisieren:

@inject IHttpContextAccessor HttpContextAccessor
…
var HttpContext = HttpContextAccessor.HttpContext;
var json = System.Text.Json.JsonSerializer.Serialize(regForm);
HttpContext.Session.SetString("Formulardaten", json);

beziehungsweise

BO.RegistrationData daten = 
    System.Text.Json.JsonSerializer.Deserialize(
        HttpContext.Session.GetString("Formulardaten") ?? string.Empty);

In .NET 11.0 Preview 5 hat Microsoft nun die Annotation [SupplyParameterFromSession] eingeführt, die die Handhabung von Session-Variablen genauso einfach macht wie von Query-String-Parametern [SupplyParameterFromQuery], Form-Daten [SupplyParameterFromForm] und TempData-Werten [SupplyParameterFromTempData], wobei letztere Annotation erst in .NET 11.0 Preview 4 eingeführt wurde.

Entwicklerinnen und Entwickler annotieren in einer Seite eine oder mehrere Properties mit der Annotation [SupplyParameterFromSession]. Dabei sind einfache und komplexe Datentypen möglich, während [SupplyParameterFromTempData] auch in Preview 5 weiterhin nur mit einfachen Datentypen funktioniert:

[SupplyParameterFromSession]
public string Message { get; set; }
[SupplyParameterFromSession] 
public BO.RegistrationData RegData { get; set; }

Session-Werte werden dabei automatisch mit System.Text.Json in JSON serialisiert.

Analoge Properties deklarieren Entwicklerinnen und Entwickler in den Folgeseiten und können dann auf die Werte ohne weiteres Zutun zugreifen. Voraussetzung ist wie bisher, dass in der Startseite die Sessions aktiviert wurden:

builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();
…
app.UseSession();

Mit OpenProject 17.5 können Anwender erstmals zwischen zwei Arten von Kennungen für ihre Arbeitspakete wählen: einer fortlaufenden Nummerierung über die gesamte Installation oder projektbezogenen Kennungen. Vor allem große Organisationen und Teams, die von Atlassian Jira umsteigen, sollen davon profitieren. Daneben erweitert die Version die Möglichkeiten zur Anpassung agiler Backlogs und bringt kleinere Verbesserungen für Dokumentation und Besprechungsplanung.

OpenProject ist eine quelloffene Anwendung für Projektmanagement und Zusammenarbeit. Die Software unterstützt klassische und agile Projektmethoden und bietet unter anderem Aufgaben- und Ressourcenverwaltung, Gantt-Diagramme, Scrum-Backlogs sowie Funktionen für Dokumentation und Team-Arbeit. Sie läuft wahlweise als Cloud-Dienst oder im Eigenbetrieb.

Projektbezug direkt in der Kennung

Die wichtigste Neuerung von OpenProject 17.5 sind projektspezifische Arbeitspaket-Kennungen, die zunächst als Beta vorliegen. Bislang vergab OpenProject die IDs ausschließlich über eine globale Nummernfolge für die gesamte Installation. Ein Arbeitspaket erhielt etwa die Kennung „#2385“ – unabhängig davon, zu welchem Projekt es gehörte.

Künftig können Administratoren stattdessen projektbezogene Kennungen aktivieren. Diese ergänzen die ID um ein Projektkürzel und orientieren sich damit an einem Schema, das viele Anwender bereits von Jira kennen. Aus einer generischen Nummer wird so eine Kennung wie „ERP-2385“ oder „APP-4711“. Zu welchem Projekt ein Arbeitspaket gehört, lässt sich auf diese Weise sofort erkennen – das erleichtert die Orientierung in Umgebungen mit vielen Projekten.

Bestehende IDs bleiben gültig

Nach Angaben des Herstellers funktionieren bestehende numerische IDs und Verweise auch nach einer Umstellung weiter. Alte Links, Lesezeichen und Referenzen sollen weiterhin auf die jeweiligen Arbeitspakete zeigen. Die Wahl zwischen numerischen und projektspezifischen Kennungen gilt allerdings für die gesamte Installation und damit für alle Projekte.

Ein wesentlicher Grund für die neuen Kennungen sind Migrationen von Jira. Unternehmen können ihre bisherigen Jira-Issue-Keys beibehalten, wenn sie ihre Projekte nach OpenProject übertragen. So lassen sich etablierte Namenskonventionen und Referenzen in Dokumentationen, Integrationen oder Automatisierungen weiternutzen. Der Jira-Migrator übernimmt jetzt zusätzlich Fälligkeitstermine sowie geschätzte und verbleibende Arbeitsstunden.

Mehr Kontrolle über Backlogs

Auch die agilen Planungsfunktionen hat OpenProject ausgebaut. Administratoren können nun einzelne Arbeitspakettypen gezielt aus Backlogs ausschließen. So sehen Teams bei der Sprint-Planung nur die Aufgaben, die für sie tatsächlich relevant sind.

Zudem hat OpenProject die Sprint- und Kartenansichten überarbeitet. Informationen wie übergeordnete Arbeitspakete, Prioritäten, Story Points, Zuständigkeiten und der Sprint-Status lassen sich dadurch schneller erfassen.

Kleinere Neuerungen bei Dokumentation und Meetings

Weitere Änderungen betreffen die Dokumentation und Besprechungsplanung. Verweise auf Arbeitspakete lassen sich nun direkt in den Fließtext einbetten. In Eingabefeldern auf Basis des CKEditor reichert OpenProject solche Verweise schon während der Eingabe mit Zusatzinformationen an.

Wiederkehrende Besprechungen unterstützen außerdem neue monatliche Muster wie den ersten Montag oder den letzten Freitag eines Monats. Ändert sich ein Termin, fasst das System mehrere Änderungen in einer Benachrichtigung zusammen und reduziert so die Zahl der E-Mails.

Die Cloud-Anwendungen von OpenProject erhalten das Update seit dem 10. Juni 2026 automatisch; für selbst betriebene Instanzen stehen Anleitungen für Paket- und Docker-Installationen bereit. Alle Details listet OpenProject in den Release Notes zu Version 17.5 auf.

Siehe auch:

(fo)