Was umfasst die Anwendungswartung?

Harsh Joshi

Co-founder & Technical Director

Die Anwendungswartung umfasst weit mehr als nur die Behebung von Fehlern. Erfahren Sie, welche acht Bereiche zum vollständigen Leistungsumfang gehören, was in der Regel nicht darunter fällt und wie Service-Levels und Kostentreiber den Umfang Ihrer Leistungen beeinflussen.

Die Anwendungswartung umfasst alle Arbeiten, die erforderlich sind, um die Sicherheit, Zuverlässigkeit, Kompatibilität und Nutzbarkeit der Software nach ihrer Einführung aufrechtzuerhalten. Dazu gehören Fehlerbehebungen, Sicherheitspatches, Aktualisierungen von Abhängigkeiten, Leistungsverbesserungen, die Aufrechterhaltung der Integration, Überwachung sowie kleinere Optimierungen.

Für Unternehmen, die auf maßgeschneiderte Anwendungen angewiesen sind, ist die Wartung eine fortlaufende Aufgabe der Softwareentwicklung. Ohne sie kann Software anfällig für Sicherheitsbedrohungen werden, mit neueren Plattformen inkompatibel sein, bei wachsenden Datenmengen langsamer werden oder bei Änderungen höhere Kosten verursachen. Aus diesem Grund umfassen die Softwareentwicklungsdienstleistungen von Monarch Innovation nicht nur die Entwicklung, sondern auch einen strukturierten Support nach der Veröffentlichung.

Zu wissen, dass eine Anwendung gewartet werden muss, ist jedoch nur der Ausgangspunkt. Unternehmen müssen auch verstehen, was die Wartung umfasst, welche Aktivitäten nicht in ihren Geltungsbereich fallen und was sie von einem Wartungsvertrag erwarten können.

In diesem Leitfaden werden der Umfang, die verschiedenen Arten, die Servicelevels, die Kosten und die Planungsaspekte erläutert, die CTOs, IT-Manager und Produktverantwortliche kennen sollten, bevor sie sich für einen Ansatz zur Anwendungswartung entscheiden.

Was umfasst die Anwendungswartung?

Die Anwendungswartung umfasst in der Regel acht Kernaktivitäten: Fehlerbehebung, Installation von Sicherheitspatches, Aktualisierung von Abhängigkeiten, Aufrechterhaltung der Integration, Leistungsoptimierung, Überwachung, kleinere Verbesserungen und Aktualisierung der Dokumentation.

Jede Maßnahme befasst sich mit einem anderen Risiko, das im Zuge der Weiterentwicklung von Software auftreten kann.

Fehlerbehebung und Korrektur von Mängeln: Identifizieren und Beheben von Fehlern, die die Funktionalität der Anwendung, die Datengenauigkeit oder die Benutzererfahrung beeinträchtigen.
Sicherheitspatches: Beheben Sie bekannte Sicherheitslücken im Anwendungscode, in Frameworks, Bibliotheken und Laufzeitumgebungen.
Aktualisierung von Abhängigkeiten und Plattformen: Aktualisieren Sie Softwarekomponenten und passen Sie Anwendungen an Änderungen bei Betriebssystemen, Browsern, mobilen Plattformen und Cloud-Diensten an.
Wartung der Integrationen: Stellen Sie sicher, dass die Verbindungen zu ERP-Systemen, CRM-Plattformen, Zahlungsgateways und APIs von Drittanbietern auch bei Änderungen an diesen Systemen weiterhin funktionieren.
Leistungsoptimierung: Untersuchung langsamer Datenbankabfragen, Speicherlecks und Engpässe, die mit steigender Nutzung und zunehmendem Datenvolumen auftreten.
Überwachung und Reaktion auf Störungen: Verfolgen Sie die Verfügbarkeit von Anwendungen, Fehler und Antwortzeiten und untersuchen Sie anschließend Warnmeldungen und Dienstunterbrechungen.
Kleinere Optimierungen: Nehmen Sie kleine, klar definierte Verbesserungen vor, wie beispielsweise das Hinzufügen eines Berichtsfilters, die Optimierung eines Arbeitsablaufs oder die Verbesserung einer Fehlermeldung.
Aktualisierung der Dokumentation: Pflege der technischen Dokumentation, der Bereitstellungsanweisungen, der Runbooks und der Änderungsprotokolle, damit zukünftige Wartungsarbeiten sicher durchgeführt werden können.

Stellen Sie sich eine Außendienstanwendung vor, die von Hunderten von Technikern genutzt wird. Eine neue Android-Version ändert die Standortberechtigungen, ein Zahlungsanbieter stellt eine API-Version ein, und ein Berichts-Dashboard wird langsamer, je mehr Auftragsdatensätze sich ansammeln.

Diese Probleme erfordern unterschiedliche technische Lösungen, fallen jedoch alle in den Bereich der Anwendungswartung. Das Ziel besteht darin, die bestehende Anwendung auch bei Veränderungen ihrer Betriebsumgebung funktionsfähig, sicher und zuverlässig zu halten.

Was sind die vier wichtigsten Arten der Anwendungswartung?

Die vier allgemein anerkannten Arten der Softwarewartung sind die korrektive, die adaptive, die perfektive und die präventive Wartung. Jede davon befasst sich mit einem anderen Grund für Änderungen an der Software nach deren Veröffentlichung.

Typ	Zweck	Beispiel
Korrektivwartung	Einen bestehenden Fehler beheben	Beheben Sie einen Fehler beim Bezahlvorgang, der gültige Zahlungen ablehnt
Adaptive Instandhaltung	Software an veränderte Umgebungsbedingungen anpassen	Eine Anwendung für ein neues Betriebssystem oder eine neue API-Version aktualisieren
Perfekte Wartung	Funktionalität, Benutzerfreundlichkeit oder Leistung verbessern	Ein langsames Dashboard optimieren oder ein Formular vereinfachen
Vorbeugende Wartung	Das Risiko künftiger Ausfälle verringern	Fragilen Code umgestalten, die Testabdeckung verbessern oder veraltete Abhängigkeiten entfernen

Diese Kategorien entsprechen der etablierten Terminologie im Bereich der Softwarewartung, einschließlich ISO/IEC/IEEE 14764:2022, der internationalen Norm für Softwarewartung.

In einigen Wartungsrahmenwerken wird auch die additive Wartung behandelt, bei der bereits im Einsatz befindlicher Software neue Funktionen hinzugefügt werden. Die genaue Klassifizierung kann je nach dem verwendeten Rahmenwerk oder der befolgten Norm variieren.

Ein ausgewogener Wartungsplan befasst sich nicht nur mit Produktionsfehlern. Korrekturmaßnahmen stellen die Funktionalität wieder her, während adaptive und präventive Maßnahmen dazu beitragen, zukünftige Störungen zu reduzieren. Optimierungsmaßnahmen sorgen dafür, dass die Anwendung stets den sich ändernden Anforderungen der Nutzer und des Unternehmens entspricht.

Anwendungswartung vs. Anwendungsunterstützung

Bei der Anwendungswartung liegt der Schwerpunkt auf der Änderung und Verbesserung von Software. Beim Anwendungssupport geht es darum, Anwendern zu helfen, Betriebsprobleme zu untersuchen und für einen reibungslosen Ablauf der täglichen Anwendungsnutzung zu sorgen.

Auch wenn sich die Tätigkeiten überschneiden, ist diese Unterscheidung bei der Festlegung der Zuständigkeiten in einem Dienstleistungsvertrag von Bedeutung.

Der Anwendungssupport ist in der Regel in drei Ebenen gegliedert:

Stufe 1 (L1): Beantwortet grundlegende Nutzerfragen, kümmert sich um das Zurücksetzen von Passwörtern, Anleitungen und die erstmalige Erfassung von Supportanfragen.
Stufe 2 (L2): Untersucht Anwendungsprobleme, überprüft Protokolle und Konfigurationen und wendet bekannte Lösungen oder Workarounds an.
Stufe 3 (L3): Behandelt komplexe technische Probleme, die ingenieurtechnisches Fachwissen, Ursachenanalysen oder Codeänderungen erfordern.

Die Zuständigkeiten variieren je nach Organisation. So kann beispielsweise ein L3-Techniker einen Fehler diagnostizieren, während das Wartungsteam die dauerhafte Lösung entwickelt, testet und freigibt.

Auch Regressionstests sind unverzichtbar. Jede Codeänderung sollte überprüft werden, um sicherzustellen, dass durch die Behebung eines Problems kein neues Problem entstanden ist. Aus diesem Grund sollten Qualitätssicherung und Softwaretests Teil des Wartungsablaufs sein.

Vergleichen Sie bei der Auswahl von Anwendungswartungsdiensten, ob Benutzer-Support, Überwachung, technische Fehlerbehebung und Release-Management im Preis inbegriffen sind oder separat berechnet werden.

Was ist in der Regel nicht in der Anwendungswartung enthalten?

Die routinemäßige Anwendungswartung konzentriert sich in der Regel auf ein bestehendes System. Sofern sie nicht ausdrücklich im Vertrag enthalten sind, erfordern größere Entwicklungsprojekte, umfangreiche Modernisierungen und der Infrastrukturbetrieb unter Umständen eine gesonderte Leistungsbeschreibung und Preisgestaltung.

Zu den üblichen Ausschlüssen gehören:

Wichtige neue Funktionen: Die Entwicklung eines neuen Kundenportals, einer Preisberechnungs-Engine oder eines umfangreichen Geschäftsmoduls erfordert in der Regel einen separaten Entwicklungsaufwand.
Anwendungsmodernisierung: Die Migration eines Altsystems auf eine neue Architektur, der Austausch wichtiger Komponenten oder die Verlagerung einer Anwendung auf eine andere Plattform ist in der Regel ein eigenständiges Modernisierungsprojekt.
Infrastruktur und Hosting-Betrieb: Serveradministration, Hosting-Management, Datensicherungen und Notfallwiederherstellung fallen möglicherweise nicht in den Wartungsumfang, obwohl viele Anbieter diese Leistungen als Zusatzdienste anbieten.
Produktfehler von Drittanbietern: Probleme innerhalb einer vom Anbieter verwalteten SaaS-Plattform oder eines lizenzierten Produkts müssen unter Umständen vom Anbieter behoben werden. Das Wartungsteam kann das Problem untersuchen und, soweit möglich, eine geeignete Übergangslösung implementieren.
Geschäftsabläufe: Die Dateneingabe, routinemäßige Inhaltsaktualisierungen und die administrative Benutzerverwaltung werden häufig von den Fachabteilungen oder vom Support-Personal übernommen.

Der wichtigste Unterschied besteht darin, ob es darum geht, bestehende Funktionen beizubehalten oder eine wesentliche neue Funktion bereitzustellen.

So kann beispielsweise das Hinzufügen eines einfachen Berichtsfilters als geringfügige Erweiterung gelten. Die Entwicklung eines neuen Berichtsmoduls mit zusätzlichen Datenquellen, Berechtigungen und Geschäftslogik erfordert hingegen eher einen separaten Kostenvoranschlag.

In einem Wartungsvertrag sollte diese Grenze klar definiert werden. Legen Sie den Umfang kleinerer Änderungen, das Genehmigungsverfahren für zusätzliche Arbeiten sowie die Zuständigkeiten für Infrastruktur, Datensicherungen, Zertifikate und Dienste von Drittanbietern fest.

Checkliste zur Anwendungswartung nach Häufigkeit

Ein strukturierter Wartungsplan hilft Teams dabei, Probleme zu erkennen, bevor sie zu kostspieligen Vorfällen werden. Die angemessene Häufigkeit hängt von der Kritikalität der Anwendung, den Sicherheitsanforderungen, den Release-Richtlinien und dem Betriebsrisiko ab.

Häufigkeit	Typische Tätigkeiten
Täglich	Überwachen Sie Warnmeldungen, führen Sie eine Triage von Vorfällen durch, überprüfen Sie kritische Fehler und vergewissern Sie sich, dass geplante Aufträge und Sicherungsprozesse abgeschlossen wurden
Wöchentlich	Fehlerrückstände überprüfen, wiederkehrende Fehler untersuchen, Sicherheitswarnungen prüfen und genehmigte Korrekturen mit geringem Risiko veröffentlichen
Monatlich	Überprüfen Sie Sicherheitspatches, Aktualisierungen von Abhängigkeiten, Leistungstrends, Zugriffsberechtigungen sowie Ablaufdaten von Zertifikaten oder Lizenzen
Vierteljährlich	Upgrades von Frameworks und Laufzeitumgebungen bewerten, die Wiederherstellung aus Backups testen, technische Schulden überprüfen und Kapazitätserweiterungen planen
Jährlich	Führen Sie eine Bewertung des Anwendungszustands durch, überprüfen Sie die End-of-Life-Termine der Komponenten und aktualisieren Sie den Wartungsplan sowie das Budget

Dieser Zeitplan dient als Ausgangspunkt und ist keine allgemeingültige Regel. Kritische Sicherheitslücken und Dienstausfälle erfordern zeitnahe Maßnahmen, anstatt auf ein geplantes Wartungsfenster zu warten. Bei einigen Anwendungen sind aufgrund gesetzlicher oder betrieblicher Anforderungen zudem häufigere Patches und Zugriffsprüfungen erforderlich.

Automatisierung kann den Aufwand für Routineaufgaben reduzieren. CI/CD-Pipelines, die Überprüfung von Abhängigkeiten, automatisierte Regressionstests und Überwachungswarnungen helfen Teams dabei, Probleme zu erkennen und Änderungen konsistenter bereitzustellen.

Bei Anwendungen, die auf einer Cloud-Infrastruktur basieren und häufige Releases erfordern, können Cloud-, DevOps- und Sicherheitsentwicklung den Wartungsprozess ergänzen.

Wie funktionieren Service-Levels bei der Anwendungswartung?

In einer Service Level Agreement (SLA) wird die Dienstleistung festgelegt, zu deren Erbringung sich ein Wartungsanbieter verpflichtet. Darin werden in der Regel die Supportzeiten, die Prioritäten bei Störungen, die Reaktionsziele, die Erwartungen hinsichtlich der Behebung, die Eskalationsverfahren und die Anforderungen an die Berichterstattung festgelegt.

Ein gängiges Schweregradsmodell umfasst vier Stufen.

Schweregrad	Beispiel	Typischer Vorgehensweise
P1: Kritisch	Die Anwendung ist für alle Benutzer nicht verfügbar oder es liegt ein schwerwiegender Sicherheitsvorfall vor	Sofortige Reaktion, Eskalation und kontinuierliche Arbeit, bis der Dienst wiederhergestellt ist oder das vereinbarte Wiederherstellungsziel erreicht ist
P2: Hoch	Eine zentrale Geschäftsfunktion fällt aus, ohne dass es eine praktikable Ausweichlösung gibt	Priorisierung der Untersuchung und ein vereinbartes Ziel für die Behebung oder eine Übergangslösung
P3: Mittel	Eine Funktion funktioniert nicht, es gibt jedoch eine Umgehungslösung	Planmäßige Untersuchung und Lösung entsprechend der vereinbarten Priorität
P4: Niedrig	Ein kosmetisches Problem oder eine Anfrage zur geringfügigen Verbesserung	Auftragsbestandverwaltung und geplante Auslieferung

Hierbei handelt es sich um beispielhafte Kategorien und nicht um branchenweit garantierte Reaktionszeiten. Die genauen Zielwerte sollten die Auswirkungen auf den Geschäftsbetrieb, die Kritikalität der Anwendung, den Supportumfang und den Wartungsvertrag widerspiegeln.

Eine kundenorientierte Zahlungsplattform benötigt möglicherweise eine Rund-um-die-Uhr-Betreuung bei kritischen Vorfällen. Ein internes Berichtstool, das während der Geschäftszeiten genutzt wird, hat möglicherweise andere Anforderungen.

Mit welchen Kennzahlen lässt sich die Leistung im Bereich Instandhaltung messen?

Die richtigen Kennzahlen zeigen, ob die Wartung die Zuverlässigkeit der Anwendung verbessert und das Betriebsrisiko verringert.

Durchschnittliche Zeit bis zur Behebung (MTTR): Gibt an, wie lange es dauert, bis Vorfälle behoben sind, basierend auf der von der Organisation festgelegten Messmethode.
Verfügbarkeit: Erfasst den Anteil der Zeit, in der die Anwendung zur Nutzung verfügbar ist.
Fehlerquote bei Änderungen: Misst den Anteil der Bereitstellungen, die zu Fehlern führen, die ein Eingreifen oder eine Behebung erfordern.
Patch-Latenz: Misst die Zeitspanne zwischen der Verfügbarkeit eines Sicherheitspatches und dessen Bereitstellung.
Alter des Rückstands: Zeigt an, wie lange Fehler und Wartungsanfragen ungelöst bleiben.

Betrachten Sie diese Kennzahlen im Zusammenhang mit der Schwere der Vorfälle und den Auswirkungen auf das Geschäft. Eine geringere Anzahl von Tickets bedeutet nicht zwangsläufig eine bessere Wartung, wenn schwerwiegende Probleme ungelöst bleiben.

Wovon hängen die Kosten für die Anwendungswartung ab?

Die Kosten für die Anwendungswartung hängen vom Zustand der Anwendung, der Komplexität ihres Technologie-Stacks, dem erforderlichen Supportumfang und dem Risikoniveau ab, das das Unternehmen bewältigen muss.

Zu den wichtigsten Kostenfaktoren zählen:

Codequalität und Testabdeckung: Gut strukturierte, gründlich getestete Anwendungen lassen sich in der Regel einfacher und sicherer ändern.
Das Technologiezeitalter: Nicht mehr unterstützte Frameworks und veraltete Laufzeitumgebungen können einen höheren Aufwand für Untersuchungen, Upgrades und Kompatibilitätsarbeiten erfordern.
Komplexität der Integration: Jede externe API, jeder Zahlungsdienst, jedes ERP-System und jede CRM-Plattform bringt Abhängigkeiten mit sich, die sich unabhängig voneinander ändern können.
Compliance- und Sicherheitsanforderungen: Geltende Vorschriften wie die DSGVO, HIPAA oder PCI DSS können den Aufwand für Dokumentation, Tests, Zugriffskontrolle und Sicherheitsmaßnahmen erhöhen.
Supportumfang: Die Bearbeitung von Störungen rund um die Uhr erfordert in der Regel mehr Ressourcen als der Support während der Geschäftszeiten.
Qualität der Dokumentation: Fehlende Architekturhinweise, Bereitstellungsanweisungen oder Störungsberichte können die Untersuchungsdauer verlängern.
Kritikalität der Anwendung: Systeme, die geschäftskritische Abläufe unterstützen, erfordern unter Umständen strengere Tests, Überwachung, Notfallpläne und eine Eskalation bei Vorfällen.

Wartungsanbieter setzen in der Regel monatliche Pauschalen mit festgelegten Stundenkontingenten, eine Abrechnung nach Zeit und Materialaufwand oder eigens dafür vorgesehene Entwicklerteams ein. Das richtige Modell hängt von der Vorhersehbarkeit des Arbeitsaufwands, der Komplexität der Anwendung und dem Umfang der benötigten Entwicklungskapazitäten ab.

Bei der Bewertung der langfristigen Betriebskosten von Software sollten auch die Wartungskosten berücksichtigt werden. Das anfängliche Entwicklungsbudget allein spiegelt nicht den laufenden Aufwand wider, der erforderlich ist, um die Software sicher, kompatibel und nutzbar zu halten.

Um einen umfassenderen Überblick über diese Entscheidungen zu erhalten, lesen Sie den Leitfaden von Monarch Innovation zum Thema „Entwicklung, Kauf oder Outsourcing von Unternehmenssoftware“.

Sollten Sie sich für eine interne, eine ausgelagerte oder eine hybride Wartung entscheiden?

Das beste Modell für die Anwendungswartung hängt von den internen technischen Kapazitäten, der Bedeutung der Anwendung für das Unternehmen und dem Umfang der erforderlichen fachlichen Unterstützung ab.

Eigene Instandhaltung

Ein internes Team kann eine gute Wahl sein, wenn die Anwendung für das Produkt von zentraler Bedeutung ist und die Entwickler deren Architektur bereits kennen. Die Herausforderung besteht darin, einen Ausgleich zwischen Wartungsarbeiten, der Entwicklung neuer Funktionen und anderen Prioritäten der Roadmap zu finden.

Ausgelagerte Instandhaltung

Ein externer Anbieter kann spezielle technische Kapazitäten bereitstellen, ohne dass das Unternehmen jeden Spezialisten intern einstellen muss. Der Erfolg hängt von einem strukturierten Wissenstransfer, klaren Zugriffskontrollen, dokumentierten Zuständigkeiten und einer Vereinbarung über die Service-Levels ab.

Hybride Wartung

Ein Hybridmodell verbindet die interne Verantwortung mit externer technischer Unterstützung. Das interne Team kann Produktentscheidungen und Prioritäten festlegen, während ein Partner vereinbarte Aufgaben wie Sicherheitsupdates, Leistungsverbesserungen, Upgrades, Tests und die Behebung von Fehlern übernimmt.

Bevor Sie sich für ein Modell entscheiden, sollten Sie klären, wer für den Code, die Bereitstellungsumgebungen, die Zugangsdaten, die Dokumentation, die Eskalation von Vorfällen und die Freigabe von Releases verantwortlich ist. Diese Zuständigkeiten sollten klar geregelt sein, unabhängig davon, wer die Wartungsarbeiten durchführt.

So erstellen Sie einen Plan zur Anwendungswartung

Ein wirksamer Plan zur Anwendungswartung beginnt mit dem Verständnis des Softwareportfolios und der damit verbundenen betrieblichen Risiken. Ein Vertrag sollte auf dieser Bewertung aufbauen und sie nicht ersetzen.

Befolgen Sie diese Schritte, um einen praktischen Plan zu erstellen:

Erstellen Sie eine Bestandsaufnahme Ihrer Anwendungen. Erfassen Sie die verwendeten Systeme, deren Geschäftszweck, Technologie-Stacks, Integrationen und technischen Verantwortlichen.
Bewerten Sie die geschäftliche Kritikalität. Ermitteln Sie, welche Anwendungen wesentliche Prozesse unterstützen und welche Auswirkungen eine Störung auf das Unternehmen hätte.
Legen Sie den Wartungsumfang fest. Geben Sie die enthaltenen Aktivitäten, Ausschlüsse, Grenzen für geringfügige Erweiterungen sowie die Zuständigkeiten für Abhängigkeiten von Drittanbietern an.
Legen Sie Service-Levels fest. Definieren Sie Schweregrade, Reaktions- und Lösungsziele, Supportzeiten sowie Eskalationsverfahren.
Zuweisung von Zuständigkeiten. Klärung der Verantwortlichkeiten für Quellcode, Infrastruktur, Zugangsdaten, Sicherheit, Tests, Releases und die Koordination mit Anbietern.
Legen Sie Leistungskennzahlen fest. Erfassen Sie Vorfälle, Verfügbarkeit, Verzögerungen bei der Patch-Installation, fehlgeschlagene Änderungen und noch nicht abgeschlossene Wartungsarbeiten.
Überprüfen Sie den Plan regelmäßig. Bewerten Sie Prioritäten, technologische Risiken, Kosten und Servicelevels neu, sobald sich die Anwendung und das Geschäft weiterentwickeln.

Ein klarer Plan verringert Unklarheiten und hilft Unternehmen dabei, zwischen wesentlichen Wartungsarbeiten und Aufgaben zu unterscheiden, die ein eigenständiges Entwicklungsprojekt erfordern.

Monarch Innovation unterstützt Unternehmens- und Industrieteams durch seine Dienstleistungen im Bereich Digital Engineering, darunter maßgeschneiderte Softwareentwicklung, Cloud- und DevOps-Lösungen sowie Qualitätssicherung. Die Koordinierung dieser Kompetenzen kann dazu beitragen, Übergänge zu reduzieren, wenn Anwendungsänderungen Code, Infrastruktur und Tests betreffen.

Sie sind sich nicht sicher, was Ihr aktueller Wartungsumfang umfasst?

Sprechen Sie mit Monarch Innovation über Ihre Anwendung, deren Integrationen und die Service-Levels, die Ihr Unternehmen benötigt.

Besprechen Sie Ihre Bewerbung

Wie oft sollte die Anwendungswartung durchgeführt werden?

Die Anwendungswartung erfolgt kontinuierlich und ist kein einmaliges, jährliches Ereignis. Die Überwachung und die Einstufung von Vorfällen können täglich stattfinden, während Sicherheitspatches und Überprüfungen der Abhängigkeiten einem risikobasierten Zeitplan folgen, der bei Routine-Updates häufig monatlich erfolgt. Kritische Sicherheitslücken und Dienstausfälle erfordern gemäß den im Service Level Agreement vereinbarten Schweregradregeln zeitnahe Maßnahmen, unabhängig vom geplanten Wartungszyklus.

Ist Anwendungswartung dasselbe wie Anwendungsmanagement-Services?

Nein. Bei der Anwendungswartung stehen technische Änderungen im Vordergrund, die die Zuverlässigkeit der Software gewährleisten und sie auf dem neuesten Stand halten. „Application Management Services“ (AMS) ist ein weiter gefasster Begriff, der neben der Wartung auch Anwendersupport, Überwachung sowie Hosting- oder Betriebsdienstleistungen umfassen kann. Achten Sie beim Vergleich von AMS-Angeboten darauf, welche dieser Leistungen der jeweilige Anbieter tatsächlich einbezieht, anstatt sich allein auf die Bezeichnung zu verlassen.

Umfasst die Anwendungswartung auch neue Funktionen?

Dies kann kleinere, vereinbarte Verbesserungen umfassen, wie beispielsweise einen Berichtsfilter oder eine Anpassung des Workflows. Umfangreiche Funktionen, neue Module und größere Integrationen erfordern in der Regel einen separaten Entwicklungsaufwand. In der Vereinbarung sollten die Grenzen klar definiert werden, beispielsweise durch die Festlegung einer Obergrenze für den Aufwand pro Änderungsanforderung und eines Genehmigungsverfahrens für umfangreichere Änderungen.

Was passiert, wenn die ursprünglichen Entwickler nicht mehr zur Verfügung stehen?

Nach einer strukturierten Übergabe kann ein neues Team die Arbeit übernehmen. Dazu gehört in der Regel der Zugriff auf den Quellcode, Repositorys, Deployment-Pipelines, Umgebungen, die Architekturdokumentation, bekannte Probleme und Betriebsabläufe. Eine Einarbeitungsphase hilft dem neuen Team, das System zu verstehen, bevor es die volle Verantwortung übernimmt.

Woran erkennt man, dass die Wartung einer Anwendung zu teuer geworden ist?

Zu den Warnzeichen zählen steigender Wartungsaufwand, häufige Regressionen, zunehmend langsame Änderungen, wiederkehrende Vorfälle und Technologiekomponenten, die nicht mehr unterstützt werden. Wenn der Großteil des Budgets dafür aufgewendet wird, die Anwendung am Laufen zu halten, anstatt sie zu verbessern, sollten Sie die laufenden Kosten und Risiken der Wartung mit den Kosten und Risiken einer Modernisierung oder eines Austauschs über einen Zeitraum von drei bis fünf Jahren vergleichen.

Was sollte ein Wartungsvertrag für eine Anwendung beinhalten?

Darin sollten die abgedeckten Anwendungen und Umgebungen, die einbezogenen Aktivitäten, Ausschlüsse, Schweregrade, Reaktions- und Lösungsziele, Supportzeiten, Grenzen für Funktionserweiterungen, Sicherheitsverantwortlichkeiten, Berichterstattung, Leistungskennzahlen sowie Übergaberegelungen festgelegt werden. Klare Ausschlüsse sind ebenso wichtig wie Einbeziehungen, da die meisten Streitigkeiten darauf zurückzuführen sind, dass jede Seite davon ausgegangen ist, dass die andere Seite für bestimmte Aufgaben zuständig sei.

Lässt sich die Anwendungswartung automatisieren?

Ja, teilweise. Überwachung, Abhängigkeitsprüfungen, CI/CD-Pipelines, automatisierte Regressionstests sowie planmäßige Zertifikats- und Backup-Prüfungen können viele Routineaufgaben übernehmen. Es werden jedoch weiterhin Entwickler benötigt, um die Ursachen zu ermitteln, Risiken zu priorisieren und zu beurteilen, ob eine Änderung für das Unternehmen unbedenklich ist. Die Automatisierung reduziert also den Wartungsaufwand, ersetzt aber nicht das Wartungsteam.