WikiDer > Anwendungsdienstebibliothek

Application Services Library
ASL-Modellübersicht

ASL (Application Services Library) ist ein von Best Practices unterstütztes Prozess-Framework, das die Prozesse der Verwaltung, Wartung und Innovation von Informationssystemen und Anwendungen beschreibt. Es stellt eine Möglichkeit dar, Organisationen, die Anwendungsmanagement durchführen, zu verbessern.Durch die Verwendung von Best Practices und Diagnosetools, wie beispielsweise Selbstbewertungen, können Mitarbeiter pragmatisch mit der Verbesserung des Anwendungsmanagements beginnen.

ASL beschreibt die Prozesse auf der ausführenden (operativen), steuernden (taktischen) und richtungsweisenden (strategischen) Ebene. Es hat sechs Cluster, die Prozesse enthalten.

Als Managementmethode ist ITIL stark auf das Management von IT-Infrastrukturen ausgerichtet, ASL legt den Schwerpunkt auf das Application Management, auf die Prozesse rund um die Verwaltung und Wartung von Software und Datenbanken. Die ITIL-Prozesse sind weitgehend innerhalb von ASL zu finden, insbesondere im Bereich der Managementprozesse und taktischen Prozesse. Spezifisch für ASL ist die Betonung des Entwicklungszyklus (Wartung / Erneuerung).

ASL ist ein öffentlich zugänglicher niederländischer Standard, der jeder Organisation zur Verfügung steht und von einer Stiftung verwaltet wird, die von einer Reihe großer IKT-Unternehmen unterstützt wird.

Position von ASL

In der IKT werden drei Arten des Managements (Managementdomänen) unterschieden:

  • Technische Leitung (ITIL)
Konzentriert sich auf das IT-Infrastrukturmanagement und hat ITIL als Standard. Die IT-Infrastruktur ist eine Grundlage, auf der Anwendungen ausgeführt werden können. Diese Anwendungen werden von Application Management verwaltet.
  • Bewerbungsmanagement (ASL)
Unter dieser Verwaltung versteht man die Anpassung der Anwendung an in der Anwendung gefundene Fehler oder sich ändernde technische oder funktionale Anforderungen. Sie betrifft explizit bestehende Anwendungen und nicht neue Anwendungen. ASL ist dafür der Standard. ASL ist neuer als und teilweise inspiriert von ITIL.
  • Funktionsmanagement (BiSL)
Die Anwendungen werden von der Nutzerorganisation genutzt. Diese Organisation muss angeben, welche Anforderungen der Antrag erfüllen muss, und prüfen, ob dieser Antrag nach einer Anpassung tatsächlich erfüllt wird. Dieser Prozess wird als Functional Management bezeichnet und hat als Standard as BiSL.

ASL 2

ASL 2 wurde 2009 eingeführt, gegenüber der Vorgängerversion wurden einige strukturelle Änderungen vorgenommen. Insbesondere die Steuerungsprozesse beinhalten große Veränderungen. So sind zum Beispiel die kontinuierliche Dynamik und Anpassung der Führungsstrukturen Teil der Prozesse geworden. Die Themen, die Abläufe und die Beschreibung der Prozesse haben sich fast vollständig verändert. Aus dem SLA-Management wurde das Vertragsmanagement, der Lieferantenmanagement-Prozess als neuer Prozess aufgenommen, das Qualitätsmanagement verbreitert und Funktionen des Problemmanagement-Prozesses übernommen. Das Kostenmanagement ist zum Finanzmanagement geworden, weil es mehr Interaktion zwischen den Käufern gibt. Auch die Managementprozesse haben sich verändert, insbesondere die Verschmelzung von Verfügbarkeitsmanagement und Kapazitätsmanagement. Diese sind in den neuen Betriebsführungsprozess eingeflossen. Das Konfigurationsmanagement ist allgemeiner und eindeutiger geworden. Das Incident-Management ist zum Benutzersupport geworden, da es nicht nur auf Incidents reagiert, sondern auch proaktiv kommuniziert. Der Wartungs- und Erneuerungscluster schenkt der Arbeit in Ketten etwas mehr Aufmerksamkeit. Das Organisationszyklusmanagement umfasst jetzt den Konten- und Marktdefinitionsprozess, der eine Verschmelzung aus der vorherigen Version von ASL ist. Die Lieferantendefinition ist ein neuer Prozess, und die Definition von Fähigkeiten wurde zu einer Definition von Fähigkeiten, um sie stärker auf die Unternehmensebene zu bringen.

ASL-Prozesse

ASL ist ein Prozessmodell. Das bedeutet, dass die Arbeit in einem Unternehmen anhand von Prozessen beschrieben wird, die nicht unbedingt mit Abteilungen oder Personen mit einer bestimmten Funktion zusammenfallen müssen. Ein Prozess umfasst Aktivitäten, die nach dem ASL-Modell zusammengehören. In der Praxis kann eine Abteilung mehrere Prozesse durchführen und ein Prozess kann von mehreren Abteilungen durchgeführt werden. ASL hat die folgenden Prozesse:

Managementprozesse

Es gibt fünf Managementprozesse in ASL. Diese Prozesse sind wichtig, weil sie die Nutzung der Anwendungen mit möglichst wenigen Ressourcen und möglichst wenigen Anwendungsunterbrechungen unterstützen. Alle diese Prozesse sind auch in ITIL definiert, da sie hier jedoch aus dem Application Management detailliert werden, können sich die Prozesse geringfügig unterscheiden.Es lassen sich folgende Managementprozesse unterscheiden:

Wartungs- und Erneuerungsprozesse

Es wird geschätzt, dass etwa 80 % der Arbeit im Anwendungsmanagement mit Wartungs- und Erneuerungsprozessen zu tun haben. Da sich die von Anwendungen unterstützten Geschäftsprozesse ständig ändern, müssen sich die Anwendungen mit ihnen ändern. Für jede Änderung müssen die Wartungs- und Erneuerungsprozesse abgeschlossen werden. Diese Prozesse sind in ITIL nicht zu finden, es handelt sich um folgende Prozesse:

Prozesse verbinden

Die Verbindungsprozesse verbinden die oben genannten Managementprozesse mit den Wartungs- und Erneuerungsprozessen. Es gibt zwei Verbindungsprozesse. Das Änderungsmanagement bestimmt den Inhalt von Releases und welche Release-Pflege- und -Erneuerungsprozesse bearbeitet werden dürfen. Die Programmverwaltung und -verteilung prüft den Status von Anwendungskomponenten und legt fest, welche Anwendungskomponenten von den Managementprozessen verwendet werden dürfen.Diese Prozesse sind:

Controlling-Prozesse

Damit die oben genannten Prozesse optimal ablaufen, ist eine Kontrolle notwendig. Vier Aspekte sind hier wichtig: Lieferzeit, Kosten, Qualität für den Mitarbeiter und Qualität für den Kunden. Dies führt zu folgenden Prozessen:

  • Planung und Kontrolle
  • Kostenmanagement
  • Qualitätsmanagement
  • Dienstleistungsverwaltung

Jeder Prozess hat drei Arten von Aktivitäten. Zunächst muss ein Plan erstellt oder Vereinbarungen getroffen werden: Ressourcenplanung, Budgetierung, Qualitätsplan oder SLA. Dieser Plan oder diese Vereinbarungen müssen dann überwacht werden. Danach wird bewertet und gelernt.

ACM- und OCM-Prozesse

Die ACM-Prozesse (Application Cycle Management) stellen eine langfristige Strategie in Bezug auf die Anwendung sicher, dabei sind drei Dinge wichtig: technologische Entwicklungen, Entwicklungen in der Nutzer- bzw. Kundenorganisation und Entwicklungen im Umfeld der Nutzer- bzw. Kundenorganisation (z Unternehmen, mit denen die Nutzerorganisation zusammenarbeitet). Diese Sachverhalte führen zu einer Strategie bezüglich der Zukunft der Anwendung, der damit verbundenen erforderlichen Wartungsmaßnahmen und einer Strategie bezüglich des Anwendungsportfolios.

Die OCM-Prozesse (Organization Cycle Management) liefern eine langfristige Strategie in Bezug auf die ICT-Organisation, in der das Bewerbungsmanagement stattfindet. Dabei sind folgende Dinge wichtig: Marktentwicklungen, die gewünschte Herangehensweise an die Nutzer- bzw. Kundenorganisation, die gewünschten Kenntnisse und Fähigkeiten innerhalb der ICT-Organisation und die gewünschten technologischen Ressourcen für die ICT-Organisation. Diese Sachverhalte führen zu einer Festlegung der langfristig zu erbringenden Leistungen.

Die Abläufe im Detail

Managementprozesse

Störungsmanagement

Bei der Nutzung von Anwendungen können Störungen, Fragen oder Wünsche auftreten. Diese werden als Incidents an einen Helpdesk oder Service Desk gemeldet, der Teil des Incident-Management-Prozesses ist. Dieser Prozess zielt darauf ab, den Service aufrechtzuerhalten, sodass die vereinbarten Service Level eingehalten werden. Komplizierte Vorfälle oder häufig auftretende Vorfälle werden als Problem an das Qualitätsmanagement weitergegeben. Neben der Reaktion auf Vorfälle wird auch proaktiv gehandelt, beispielsweise indem Entwicklungen zu einer bestimmten Anwendung kommuniziert werden.

Konfigurationsmanagement

Die Applikationen und Teile davon sowie die vereinbarten Services und Service Levels müssen verwaltet werden. Dies ist die Aufgabe des Konfigurationsmanagements. Auch wenn sich in diesem Bereich etwas ändert, muss es Verwaltung geben. Die Verwaltung heißt CMDB (Configuration Management DataBase).

Verfügbarkeitsmanagement

Wichtig ist, dass eine Anwendung zu den vereinbarten Zeiten die vereinbarte und gewünschte Funktionalität bereitstellen kann. Das Verfügbarkeitsmanagement tut dies, indem es Verfügbarkeitsniveaus misst und berichtet, alle Anwendungs- oder Managementmängel analysiert, Verbesserungen einleitet und an neuen Änderungen beteiligt ist. Diese Aktivitäten und Maßnahmen werden in einem Verfügbarkeitsplan festgehalten.

Kapazitätsmanagement

Die von einer Anwendung verwendeten Ressourcen wie Speicherplatz, Festplattenplatz und CPU-Leistung müssen optimal genutzt werden. Moment, Menge und Kosten sind hier wichtige Aspekte. Das Kapazitätsmanagement führt Messungen hinsichtlich der angeforderten und verfügbaren Kapazität durch, analysiert die Messungen, berichtet darüber und ergreift gegebenenfalls Maßnahmen. Mögliche Maßnahmen sind die Verlagerung oder Aufteilung der Bearbeitung, die Erhöhung der Kapazität und die Optimierung der Leistung. Diese Aktivitäten und Maßnahmen werden in einem Kapazitätsplan festgehalten.

Kontinuitätsmanagement

Alle Maßnahmen, die eine längerfristige Funktionsfähigkeit der Anwendungen und Dienste gewährleisten müssen, fallen unter das Kontinuitätsmanagement. Es ist notwendig, sich gegen verschiedene Bedrohungen zu schützen. Dies sind Bedrohungen wie: Viren, Hacker, Betrug, Feuer, Überschwemmungen. Auch der Verlust von Lieferanten, von denen man abhängig ist, sollte berücksichtigt werden. Da es sich um teure Maßnahmen handelt, muss das Risiko gegen die Kosten abgewogen werden. Diese Aktivitäten und Maßnahmen werden in einem Kontinuitätsplan festgehalten.

Wartung und Erneuerung

Einflussanalyse

Die Pflege einer Anwendung beginnt immer mit der Analyse der Auswirkungen der gewünschten Änderungen. Dies betrifft den Aufwand zur Umsetzung der Änderung und die Folgen für Benutzer (Organisation) und Administratoren. Dies setzt voraus, dass klar ist, welche Teile der Anwendung geändert werden müssen und von wem die jeweilige Anwendung (Releases) verwendet wird. Basierend auf diesen Informationen wird auch ermittelt, was die beste Lösung für die Änderung ist. Auch das Testen ist bereits in Planung. In dieser Phase gibt es viele Absprachen mit dem technischen und funktionalen Management.

Design

In dieser Phase werden in Absprache mit dem Functional Management die gewünschten Veränderungen ausgearbeitet und eindeutig spezifiziert. Teil dieser Spezifikation ist unter anderem eine funktionale Beschreibung der zu verarbeitenden Informationen, der gewünschten Operationen und der gewünschten Ausgabe in der neuen Situation. Auch auf Kohärenz und Reihenfolge sollte geachtet werden. Zur Spezifikation wird häufig ein funktionales Design verwendet. Darüber hinaus wird auch ausgearbeitet, wie nach der Realisierung zu testen ist.

Realisierung

Bei der Realisierung wird das Pflichtenheft aus der vorherigen Phase technisch zu einem technischen Design ausgearbeitet. Dann wird es weiter ausgearbeitet und gebaut. Das Ergebnis ist ein Änderungspaket, die geänderten Programmkomponenten und Datendateien. Auch die modifizierten Teile durchlaufen einen ersten Test: die Gerätetest wo die Teile getrennt voneinander geprüft werden. Ein wichtiger Aspekt dabei ist, das Wiederauftreten von Fehlern zu verhindern, die in früheren Releases bereits behoben wurden.

Prüfung

Es müssen Tests durchgeführt werden, um zu verhindern, dass die Änderungen zu Fehlern in der Anwendung führen und um sicherzustellen, dass die gewünschte Funktionalität in das neue Release integriert wurde. Teil des Prozesses zu testen sind die folgenden Arten von Tests:

  • technischer Systemtest (hinsichtlich festgelegter Spezifikationen und Wartbarkeit der Software)
  • funktionaler Systemtest (hinsichtlich vereinbarter Funktionalität und Qualität)
  • (Unterstützung des) Produktionstests durch die Technische Leitung (hinsichtlich Verwertbarkeit)

Diese Tests werden nach Möglichkeit so aufgebaut, dass sie bei jedem neuen Release wiederverwendbar sind. So können Sie effizient arbeiten. Um das Testen noch strukturierter anzugehen, wurden Methoden entwickelt, wie z TMAP und Testrahmen. Diese Methoden werden nicht von ASL abgedeckt.

Implementierung

Außer dem Wort Implementierung weist darauf hin, dass es beim Implementierungsprozess nicht um die tatsächliche Implementierung des neuen Releases in der Produktionsumgebung geht. Diese Aktion wird ausgeführt von technische Leitung in Zusammenarbeit mit Funktionsmanagement der sich um die Benutzerbetreuung kümmert. Dieser Prozess unterstützt Technische Leitung und Funktional Verwalten Sie dies. Darüber hinaus schließt dieser Vorgang die Freigabe und die Abtretung nach Erhalt einer Erklärung zur Annahme der Abtretungsentlastung von Funktionsmanagement.

Prozesse verbinden

Änderungsmanagement

Verschiedene Prozesse senden Änderungsanträge an Änderungsmanagement. Diese Änderungen werden dann registriert, geclustert, priorisiert und in Releases eingeplant. Dies geschieht in Absprache mit Prozessen wie Dienstleistungsverwaltung, Funktionsmanagement, Planung und Kontrolle und Einflussanalyse. Anschließend überwacht dieser Prozess die Ausführung der Erstellung eines neuen Releases im Wartungs- und Erneuerungsprozesse.

Programmverwaltung und -verteilung

Dieser Vorgang soll verhindern, dass unbefugte Änderungen vorgenommen werden. Wenn bestimmte Anwendungsteile im Wartungs- und Erneuerungsprozess geändert werden müssen, muss dieser Teil zunächst über diesen Prozess bereitgestellt werden. Wenn die Anwendung in Produktion gehen muss, sorgt dieser Prozess für die Verteilung, damit die richtigen Anwendungsteile einsatzbereit sind. Dabei wird unter anderem auf Interferenzen und Überschneidungen zwischen verschiedenen parallel laufenden Releases geachtet.

Literatur

  • Remko van der Pols, ASL: Ein Anwendungsmanagement-Framework, 2001, ISBN 904400266X
  • Yvette Backer, Remko van der Pols, Anwendungsservicebibliothek: ein Managementleitfaden, 2003, ISBN 90-77212-04-3
  • Peter Janssen, Bewerbungsmanagement nach ASL, 2005, ISBN 90-430-0883-4
  • Remko van der Pols, ASL 2: ein Anwendungsmanagement-Framework, 2009 ISBN 978-90-8753-312-0

Externer Link