IT-Administrator: Was macht heutzutage das Applikationsmanagement aus?

Thomas Krampe: Im Prinzip verbinden wir immer noch die gleichen Konzepte wie vor zehn Jahren mit dem Begriff Applikationsmanagement: Die Betreuung einer Anwendung über ihren kompletten Lebenszyklus – von der Entwicklung über den Betrieb mit Installation, Wartung sowie Weiterentwicklung. Der komplette Support und die entsprechende Dekommissionierung der Anwendung, wenn das Lebensende erreicht ist, gehören ebenso dazu, wie die finanziellen und vertraglichen Aspekte einer Anwendung, also Einkauf, Vertrags- und Lizenzmanagement. Gern vergessen wird hier auch die Verwaltung der Abhängigkeiten einer Applikation wie gerade am Beispiel von Java aufgetreten: Plötzlich wird die Java Runtime als Basis vieler tausend Anwendungen kostenpflichtig. Zurück zum Wort "heutzutage": Die zuvor erwähnten Grundsätze des Konzepts haben sich in den letzten Jahren nicht verändert. Allerdings sind viele neue Anwendungstypen und Betriebs- sowie Verrechnungsmodelle hinzugekommen. Wir haben nicht mehr nur die klassischen Windows-Anwendungen, die einmalig per Benutzer lizenziert werden und dann jährlich mit einem Betrag für Wartung und Support in den Büchern stehen. Heute reden wir von Webanwendungen, Anwendungen für Mobilgeräte, die komplett andere Verwaltungswerkzeuge benötigen und auch anderen Abrechnungsmodellen folgen. Das Applikationsmanagement ist heutzutage durch die Vielzahl der Applikationstypen lediglich etwas komplexer, die Grundprinzipien bleiben aber die gleichen.

Tatsächlich lässt sich an dieser Stelle davon ausgehen, dass die Aufwände bei KMU deutlich geringer ausfallen. Das stimmt allerdings nur bei der Anzahl der Anwendungen. Während in großen Unternehmen teilweise mehrere tausend Anwendungen verwaltet werden müssen, sind es bei den KMU meist nur wenige hundert. Im Enterprise-Umfeld sind eigene Teams für das Applikationsmanagement zuständig. Bei KMU ist oft nur die Rolle vergeben und das Team der Administratoren auch mit dem Applikationsmanagement betraut. Von den technischen Aspekten mal abgesehen, würde ich immer die Aufmerksamkeit auf Vertrags- und Lizenzmanagement legen.

Hier habe ich tatsächlich alles schon einmal gesehen. Von sehr organisiert bis hin zum völligen Chaos war alles dabei. Je größer das Unternehmen ist, desto mehr Anwendungen sind in Verwendung und desto mehr Applikationsmanagement wird eingesetzt. Meiner Meinung nach beginnt das Applikationsmanagement – auch bei KMU – mit einem Applikationsverantwortlichen. Also eine Person oder Rolle, die sich zumindest im Groben mit der Applikation auskennt. Bei KMU wird dies in der Regel ein Benutzer sein, der die Anwendung auch selbst verwenden möchte, beziehungsweise vielleicht auch jemand, der die Anschaffung angeregt hat. Dieser Verantwortliche sollte dann nicht nur Kosten von Anschaffung, Implementierung, Betrieb und Wartung im Blick haben, sondern ist auch zuständig für beispielsweise Installationsanleitungen sowie funktionelle Anwendungstests. Entsprechende Technologien, die diese Konzepte abbilden, gibt es in nahezu jeder Ausprägung. Oftmals geben Hersteller, wie etwa Microsoft, die entsprechenden Tools mit dazu oder haben eine kostenpflichtige Lösung im Portfolio. Wo wir gerade bei Microsoft sind: Hier bietet sich natürlich die System-Center-Suite an. Auch hier wird vieles, aber eben nicht alles abgedeckt. Was nicht unbedingt schlimm ist. Denn die Verwaltung der Verträge oder die Anschaffungskosten werden vielleicht bereits in einem anderen Tool oder in einem anderen Team, etwa der Buchhaltung, verwaltet. Wichtig ist lediglich, im Blick zu haben, welche Prozesse es gibt und wer für diese verantwortlich ist.

Das ideale Applikationsmanagement gibt es nicht, da es sich um einen lebenden Prozess handelt. Und die haben die meist unangenehme Eigenschaft, dass sie ständigen Änderungen und Anpassungen unterliegen. Ist heute der Idealzustand erreicht, kann dieser morgen schon nicht mehr passen. Wichtig ist es, einen Verantwortlichen zu benennen, der in der Lage ist, die Schnittstelle zu den technischen Teams und den kaufmännischen Teams abzubilden. Bei Anwendungen, die im eigenen Unternehmen entwickelt, oder auch Anwendungen, die durch eigene Entwickler noch angepasst werden, setzen große Unternehmen auf das Dev-Ops-Modell, bei dem die Entwickler und der Betrieb in das gleiche Projektteam integriert werden. Meines Erachtens nach ist das allerdings noch nicht ausreichend: Hier fehlt die Schnittstelle zu den Finanzen. In das DevOps-Team sollte der Applikationsverantwortliche sowie Personen aus dem Bereich Einkauf, Vertrags- sowie Lizenzmanagement integriert werden.

"Never touch a running system" ist eine Aussage, die gerade vor zehn Jahren häufig zu hören war. Ich bin mir heute nicht mehr sicher, ob diese Aussage jemals richtig war. Fakt allerdings ist, dass heutzutage kein Fünkchen Wahrheit mehr daran zu finden ist. Komplexe IT-Systeme, zu denen ich auch die entsprechenden Anwendungen zähle, sollten immer auf dem aktuellen Stand sein. Allein schon aus Sicherheitsgründen sollten Security-Patches unverzüglich ausgerollt werden. Bei Updates, die lediglich neue Funktionen und vielleicht den einen oder anderen unkritischen Fehler beseitigen, können auch mal ein, zwei Wochen ins Land gehen. Wichtig ist hier, Patches und Updates in einer Testumgebung technisch auf Funktionsfähigkeit und im zweiten Schritt in einem

User-Acceptance-Test gemeinsam mit Applikationsverantwortlichen und den Benutzern die logische Funktionsfähigkeit vor dem Ausrollen zu testen.

Wir folgen hier in der Beratung bei unseren Kunden einem DTAP-Prozess, der auf vier getrennten Umgebungen basiert: Entwicklung (Development), technische Abnahme (Technical), logische Abnahme (Acceptance) sowie Produktion (Production). Während die Entwicklung und die Produktion selbsterklärend sind, benötigen die beiden übrigen Schritte ein wenig Erläuterung. Im Bereich des Technical-Acceptance-Tests prüfen wir, ob die Applikation in der Ziel-Infrastruktur problemlos läuft. Fokus ist hier nicht die eigentliche Anwendung, sondern die Nutzung der vorhandenen Ressourcen. Ist zum Beispiel die CPU- und RAM-Nutzung im normalen Rahmen oder wird durch den Patch mehr als vorher verwendet – oder einfacher: laufen alle anderen Anwendungen nach der Installation dieses Updates noch wie gewünscht? Gerade diesen Test führen in der Regel Administratoren gemeinsam mit den Entwicklern durch. War dieser Test erfolgreich, muss natürlich die Anwendung selbst getestet werden. Dies wird dann vom Applikationsverantwortlichen und natürlich den Benutzern erledigt, da die Admins in der Regel überhaupt nicht wissen, wie diese spezielle Anwendung funktionieren muss. Waren beide Tests erfolgreich, kann das Update in der Produktion ausgerollt werden. Ohne solche Tests würde ich heute kein Update mehr in einer produktiven Umgebung bereitstellen.

Obwohl es gut zu wissen ist, wann eine Anwendung oder besser ausgedrückt ein Service nicht mehr verfügbar ist, hilft uns diese Art von Überwachung hier nicht weiter. Tatsächlich werden ganz andere Monitoringsysteme benötigt, die aus der Benutzersicht die Anwendung betrachten. Dazu gehört zum Beispiel das Starten der Anwendung mit synthetischen Benutzern, die dann Startzeiten der Anwendung sowie das Ausführen von bestimmten Tasks wie etwa Drucken oder Speichern messen und bewerten. Derzeitige Systeme können mittlerweile auch von der geöffneten Anwendung einen Screenshot erstellen und über Künstliche Intelligenz feststellen, ob sich die Anwendung wie gewünscht verhält. Wenn dauerhaft einige dieser synthetischen Benutzer diese Anwendungen betrachten, liefern sie schnell ein Bild, ab wann eine Anwendung nicht mehr dem Sollzustand entspricht, und können die Administratoren warnen, bevor die Benutzer einen Support-Case öffnen.

Reibungen wird es immer geben. Jedoch ist der beste Ansatz hier der Applikationsverantwortliche. Dieser sollte auch etwas technisches Wissen mitbringen und als Schnittstelle zwischen den technischen und kaufmännischen Teams sowie dem Business Owner fungieren. Meist hilft es hier, gemeinsam an dem Problem zu arbeiten. Reibereien entstehen nur deshalb, weil sich Verantwortlichkeiten überlappen. In einem solchen Fall hilft nur ein Schlichter, der auch in der Lage ist, Verantwortung zu übernehmen und Risiken zu tragen. Der Applikationsverantwortliche benötigt hier natürlich die Unterstützung der Geschäftsleitung, da er sonst kaum in der Lage ist, hier zu vermitteln.

Tatsächlich ist dieser Trend nicht mehr aufzuhalten. Was auch gut ist. Während die klassischen Unternehmen dem Ganzen etwas kritisch gegenüberstehen, haben andere, meistens Startups, eher einen Cloud-only-Ansatz. Hier stellt sich sicher nicht die Frage, was davon richtig ist, sondern eher, welche Mischung für mein Unternehmen die beste ist. Am Beispiel von Microsoft 365 sehen wir bei fast jedem Unternehmen eine Mischung aus installierten Anwendungen und Diensten, die aus der Cloud bezogen werden. Die Vorteile in der Cloud sind die Skalierbarkeit und die Geschwindigkeit, mit der sich entwickeln lässt. Gerade bei reinen Webanwendungen lassen sich diese unglaublich schnell – inklusive Datenbanken und Web-Frontend – in fast jeder Programmiersprache in der Cloud bereitstellen. Genau dieser Trend setzt sich immer mehr verstärkt in den klassischen Unternehmen durch. Ein zusätzlicher Schub in Richtung Cloud wurde auch durch die Corona-Pandemie ausgelöst.