HMD. Wirtschaftsinformatik. Praxis der. Susanne Strahringer (Hrsg.) Heft 278 April 2011

Transkript

1 HMD Heft 278 April 2011 Praxis der Wirtschaftsinformatik Susanne Strahringer (Hrsg.) Û Best Practices und Fallstudien Û Application Outsourcing Û Akzeptanzkritische Anwendungen Û Lifecycle Û SOA-Transformation Û Anwendungsintegration Û Testautomation Û Inbetriebnahme dpunkt.verlag

2 Praxis der Wirtschaftsinformatik Inhalt Application HMD Cartoon 3 Editorial 4 Einwurf von Matthias Melich 5 Michael Rohloff Standards und Best Practices für das Application 17 Michael Maicher, Gregor Sauerzapf, Jürgen Killich Application Outsourcing Risiken von Near-/Offshoring 30 Stefan H. Hallerstede, Frank Danzinger, Angelika C. Bullinger, Kathrin M. Möslein Akzeptanzorientiertes Application Lifecycle 41 Monika Müller Application Lifecycle bei Lufthansa Systems 48 Georg Disterer ITIL-basierte Inbetriebnahme neuer Anwendungen 58 Thomas Puschmann, Rainer Alt Überbetriebliches Lifecycle 68 Kai-Helmut Eckert, Daniel Fürstenau, Lutz Kirchner SOA-Transformation von Anwendungslandschaften Unterstützung durch Unternehmensarchitekturmanagement 78 Thomas Goetz, Phillipe Maurer Musterbasierte Anwendungsintegration Am Beispiel der Schweizerischen Bundesbahnen 88 Khalid Ebanhesaten, Christian Stenhorst Testautomation in großen Softwareprojekten 115 Glossar Das Blog zum Thema: Weitere Fachthemen 94 Heiner Lasi, Hans-Georg Kemper Integrationsansätze zur Verbesserung der Entscheidungsunterstützung im Innovationsmanagement 104 Tobias Schwartz, Matthias Betz, Gunnar Stevens Smart Metering für Büroarbeitsplätze BUIS als soziotechnische Gestaltungsherausforderung Rubriken 118 Notizen 120 Bücher 124 Vorschau 126 Stichwortverzeichnis 128 Impressum

3

4 Editorial Anwendungen stellen zweifelsohne ein wichtiges Thema der Wirtschaftsinformatik dar. Aber wie kann es dann sein, dass wir noch nie ein Schwerpunktheft zum Application gemacht haben? Nach ein paar Recherchen hat sich mir schnell ein Verdacht aufgedrängt: Die Wirtschaftsinformatik als Wissenschaft und Lehrfach hat die Attraktivität dieses Themas noch nicht für sich entdeckt. Auch die wenigen Einreichungen zu diesem Heft aus Hochschulen haben dies bestätigt. Dies mag daran liegen, dass auch Wissenschaft und Lehre bisweilen in den oftmals als Phänomen der Praxis kritisierten fachlichen Silos denken: Fragestellungen der Anwendungsentwicklung werden in der Softwaretechnik adressiert und solche des Anwendungsbetriebs im Sinne klassischen managements im Informationsmanagement. Das Fach Anwendungssysteme schließlich fokussiert sich stark auf Standardsoftware. Und letztlich scheinen Fragestellungen der Anwendungswartung in Wissenschaft und Lehre ohnehin unterbeleuchtet zu sein. Wieso also behandelt niemand alle wesentlichen Fragestellungen entlang des Anwendungslebenszyklus aus einer ganzheitlichen Perspektive? Neben den angedeuteten Silos gibt es darauf keine wirklich sinnvoll vertretbare Antwort. Mein Zwischenfazit: Wissenschaftler müssen eingestehen, dass die Praxis ihnen hier einen deutlichen Schritt voraus ist. Der Begriff ist in der Praxis etabliert. Anwenderunternehmen kennen Organisationseinheiten, die entsprechend benannt sind, oder auch die Funktion des Application Manager. Zwar heißt dies auch in der Praxis noch nicht, dass dort Application idealtypisch funktioniert, denn auch dort ist eine Barriere klar erkennbar: Eine eher in Projekten organisierte Anwendungsentwicklung auf der einen Seite und ein eher in Routineorganisation strukturierter Anwendungsbetrieb haben zunächst relativ wenig miteinander zu tun. Aber viele der aktuellen Themen, die die Praxis und auch die HMD in den letzten Jahren verfolgt und geprägt haben, wie IT-Governance, Anwendungsportfoliomanagement, Unternehmensarchitekturen oder auch SOA, haben deutlich gezeigt, dass eine scharfe Trennung zwischen Entwicklungs-, Betriebsund Wartungsfragestellungen nicht mehr zeitgemäß ist. Alle diese Themen erfordern eine ganzheitlichere Betrachtung von Aufgaben rund um Applikationen. Hinzu kommt, dass uns eine neue Generation von Anwendungen, die aus dem Web 2.0 stammt und sich mit dem Schlagwort»perpetual «assoziieren lässt, aufzeigt, dass die genannte Trennung bei bestimmten Anwendungstypen möglicherweise grundsätzlich infrage zu stellen ist. Zusammenfassend bleibt festzustellen, dass es höchste Zeit ist, den State-of-the-Art dieses Themas aufzuarbeiten und zu zeigen, wie die Praxis die genannten Probleme löst bzw. Barrieren überwindet und Aufgaben entlang des Application Lifecycle angeht. Ihnen viel Spaß und Erfahrungszuwachs bei der Lektüre unserer Beiträge! Susanne Strahringer HMD 278 3

5 Matthias Melich Applikationen leben Kaum eine andere Disziplin ist derart produktiv bei der Kreation neuer Begriffe und Bezeichnungen wie die IT. Damit stellt die IT einen stetigen Born der Freude für Menschen dar, die sich mit Sprache und vor allem mit ihrer Semantik beschäftigen. Schaut man nämlich aus dieser Perspektive auf die Sprachproduktion der IT, dann ergeben sich z.t. interessante und durchaus amüsante Einsichten. Nehmen wir z.b. Google Earth. Vermutlich kennen alle Leser dieses Programm, doch was bedeutet Google Earth eigentlich: die Erde, wie Google sie sieht, oder die Erde virtuell bereitgestellt von Google. Ersteres wäre vermutlich bedenklich, denn es würde bedeuten, dass unsere Sicht auf die Erde durch das Programm gefiltert wäre und geprägt von dem kommerziellen Streben eines Konzerns. Für eine altruistische Sicht auf das Google-Programm müssten wir hingegen dankbar sein erlaubt das Programm doch, unseren Platz auf der Erde zu finden und virtuell (und somit umweltschonend) eine fast göttliche Sicht (will sagen von oben) auf die Welt zu erhalten. Dies hätte den schönen Nebeneffekt, dass unser Verständnis vom lokalen Handeln und den globalen Auswirkungen wachsen würde dank sei Google. Angemerkt sei an dieser Stelle, dass es ggf. noch eine dritte semantische Interpretation gibt: Wenn man sächsischen Ursprungs ist, dann könnte Google auch verstanden werden als Gugel (hochdeutsch Kugel). Dies würde wiederum bedeuten, dass das Modell der Erde als Scheibe dank Gugel Earth ein weiteres Mal eindrucksvoll widerlegt wird. Ein zweiter wunderbarer Begriff ist Cloud Computing frei nach Reinhard Mey also über den Wolken. Folgt man diesem Gedankengang, denkt man unwillkürlich an George Clooney in»up in the Air«den beständig sich in der Luft befindlichen Businessman, der dank»cloud Computing«die Zeit im Flugzeug produktiv nutzt (statt Whiskey zu trinken und mittelmäßige Filme zu schauen). Leider sind diese Assoziationen jedoch gänzlich falsch Cloud Computing steht letztlich nur für Rechenkapazität, die häufig gegen Gebühr zur Verfügung gestellt wird. Wie schaut es nun mit Application Lifecycle (ALM) aus? Welche Assoziationen und Interpretationen gibt es hier? Die Antwort ist einfach und weitgehend profan: ALM kann diesbezüglich nicht mit Google Earth oder Cloud Computing mithalten. ALM ist Down to Earth: Es beschreibt die Prozesse, Methoden und Werkzeuge, die zur Einführung und zum Betrieb von Applikationen notwendig sind, mathematisch ausgedrückt: LM(A). Aus SAP-Sicht stellt Application Lifecycle ein Kernelement für den Erfolg und den ROI dar, den Kunden mit ihren SAP-Investionen erzielen. Einen semantisch interessanten Aspekt gibt es aber doch: Der Begriff Lifecycle deutet darauf hin, dass es Leben gibt, also dass die Applikationen, die gemanagt werden, als eigenständige Wesen zu deuten sind ausgestattet z.b. mit einem eigenen Willen. Der Beweis, dass dies tatsächlich der Fall ist, wird streng wissenschaftlich nicht zu erbringen sein rein empirisch aber schon, denn eine Vielzahl von Menschen wird bestätigen, dass ihre Applikationen partout nicht immer das tun, was sie wollten ergo: Applikationen müssen einen eigenen Willen haben, was wiederum belegt, dass Applikationen ein Eigenleben besitzen, der Begriff ALM also angemessen ist. Mit diesen Gedanken möchte ich Sie in die Lektüre des Hefts entlassen in der Hoffnung, dass Sie von nun an ALM mit gebührendem Respekt betrachten und entsprechend verantwortungsvoll umgehen mit dem Ihnen anvertrauten digitalen Leben namens Applikation. Dr. Matthias Melich SAP AG SAP-Allee St. Leon-Rot 4 HMD 278

6 Michael Rohloff Standards und Best Practices für das Application Das Application ist ein Spiegelbild des grundlegenden Wandels von und Organisation der IT. Eine zunehmende Industrialisierung und orientierung der IT sind treibende Kräfte. Dies erfordert, das Application ganzheitlich in seinem gesamten Lebenszyklus von der Anwendungsentwicklung über den Betrieb bis zur Wartung anzugehen. Aufgrund der Veränderungen von Technologien und Markt bieten sich vielfältige Gestaltungsoptionen zwischen Eigenerstellung und Fremdbezug. Eine IT-Wertschöpfung über mehrere Partner hinweg erfordert jedoch eine Abstimmung der Prozesse wie auch die Nutzung etablierter Standards und Best Practices, wie z.b. ITIL für das IT-management, die Application s Library (ASL), Methoden des Projektmanagements und Vorgehensmodelle der Softwareentwicklung. Inhaltsübersicht 1 Application und Industrialisierung der IT 2 Der Application Lifecycle 3 Standards und Best Practices 3.1 IT Infrastructure Library (ITIL) 3.2 Application s Library (ASL) 3.3 Best Practices und Vorgehensmodelle für Projekte und die Softwareentwicklung 4 Herausforderungen und zukünftige Entwicklungen 5 Literatur 1 Application und Industrialisierung der IT Die Praxis des Application (AM, Anwendungsmanagement) unterlag in den letzten 10 Jahren großen Veränderungen. Letztendlich ist das ein Spiegelbild des grundlegenden Wandels in der Organisation und im der IT. Die traditionelle Trennung von Anwendungsentwicklung und -betrieb hat über lange Zeit sowohl das Verständnis als auch die praktische Ausgestaltung bestimmt. In der Folge haben sich die verschiedenen Disziplinen, die sich mit den jeweiligen Aufgabenbereichen auseinandersetzen, getrennt entwickelt. So hat das Software Engineering die Anwendungsentwicklung maßgeblich beeinflusst, während der Anwendungsbetrieb nur nachgeordnet betrachtet wurde. Mit einer zunehmenden orientierung der IT erhält dieser Bereich inzwischen eine zentrale Bedeutung. Das IT- management wird durch ITIL entscheidend geprägt und Aufgaben des Betriebs einschließlich der Anwenderbetreuung und der Wartung von Anwendungssystemen rücken in das Zentrum der Betrachtung. Nicht nur die orientierung, sondern auch die zunehmende Industrialisierung der IT haben starke Auswirkungen auf die Gestaltung und Aufgaben des Anwendungsmanagements. Die Industrialisierung hat in der Fertigungsindustrie im vergangenen Jahrhundert große Veränderungen und ungeahnte Produktivitätsfortschritte gebracht. Mithin war es nur konsequent und eine Frage der Zeit, die Industrialisierung auch auf die Produktion von Hardware, Software und IT-s zu übertragen [Walter et al. 2007]. Schwerpunkt der Industrialisierung war zunächst der Infrastrukturbereich HMD 278 5

7 Application Standards und Best Practices und in zunehmendem Maße sind inzwischen auch die Prozesse für die Erbringung von IT-s betroffen. Die Umsetzung der Industrialisierung wird durch die folgenden Konzepte erreicht [Brenner et al. 2007]:! Automatisierung und Standardisierung der IT-Leistungserstellung durch Übertragung bewährter Methoden und Prozesse aus dem Bereich der industriellen Fertigung, z.b. Nutzung von Plattformen und Standards, Vereinheitlichung der Prozesse, Standards für IT- Produkte und -s (IT-Produktkataloge)! Modularisierung und Komponentenbildung mit definierten Schnittstellen auf allen Ebenen von der Hardware über die Software bis zu den IT-s! Kontinuierliche Verbesserung der Prozesse zur Leistungserstellung wie auch der Leistungen selbst, z.b. durch Anwendung von Level Agreements und konsequente Verfolgung der Qualität! Konzentration auf Kernkompetenzen, da eine standardisierte IT-Produktion neben der Nutzung von Skaleneffekten auch den Fremdbezug von Leistungen erleichtert, sowohl in der Entwicklung als auch im Betrieb Das Anwendungsmanagement ist durch diese Maßnahmen zur Industrialisierung stark beeinflusst worden. Eine Trennung von Entwicklung und Betrieb von Anwendungen entspricht nicht mehr den heutigen Anforderungen. Die Praxis erfordert, die Entwicklung, den Betrieb und die Wartung von Anwendungssystemen ganzheitlich anzugehen. Dem der Anwendungen kommt eine Schlüsselfunktion für das gesamte IT- zu, denn es beeinflusst entscheidend die operative Umsetzung der IT. Es bildet die Schnittstelle zwischen den Geschäftsprozessen und der technischen Infrastruktur. Einerseits unterstützen Anwendungen Geschäftsprozesse und machen deren Durchführung oft erst möglich. Andererseits ist für den Betrieb der Applikationen eine entsprechend dimensionierte Infrastruktur notwendig. Im Anwendungsmanagement fließen damit verschiedene geschäftsrelevante Faktoren zusammen. Zum einen ist seine inhaltliche Ausrichtung entscheidend für das Business/ IT-Alignment. Es gilt, erfolgskritische Prozesse mit den passenden Anwendungen zu unterstützen. Zum anderen ist neben einer Performance-Verbesserung für das Geschäft auch auf eine ökonomische Leistungserbringung beim Betrieb dieser Applikationen zu achten. 2 Der Application Lifecycle Der Lebenszyklus des Anwendungsmanagements nach heutigem Verständnis umfasst sowohl die Entwicklung als auch den Betrieb und die Wartung von Anwendungen. Die Anwendungsentwicklung beschäftigt sich mit den Anforderungen an eine Applikation, dem Entwurf und der anschließenden Softwareentwicklung. Im klassischen Verständnis kommt erst nach diesen Phasen der Anwendungsentwicklung das management zur Anwendung, indem es die Software einführt, betreibt und stetig verbessert. Ein umfassendes Anwendungsmanagement zielt auf eine Verzahnung von Anwendungsentwicklung und -betrieb. Liegt beides in einer Hand, können Aspekte des managements, wie Verfügbarkeit, Zuverlässigkeit, Sicherheit und Performance, bereits bei der Entwicklung von Applikationen in die Planung einbezogen werden. Das gewährleistet eine bessere Integration der zu entwickelnden Applikation in die zukünftige Systemlandschaft und stellt deren Betrieb entsprechend vereinbarten Levels sicher. Abbildung 1 zeigt den gesamten Lebenszyklus des Anwendungsmanagements im Überblick. Nachfolgend werden die Prozessschritte und Aufgaben entlang des Lebenszyklus des Anwendungsmanagements skizziert. Requirements, im Deutschen auch als Anforderungen (an Systeme) bezeichnet, stellen die Basis für die Entwicklung komplexer Systeme und von Software dar. Sie bilden häufig die 6 HMD 278

8 Application Standards und Best Practices Organisation Anwendungslandschaft Prozesse Applikation A Applikation B Applikation C Applikation A Applikation B Applikation D Applikation A Applikation B Applikation E Bebauung mit Anwendungen Anwendungsportfolio Optimize Requirements Lebenszyklus von Anwendungen Design Build Operate Deploy Abb. 1: Gegenstand des Anwendungsmanagements vertragliche Grundlage für die Realisierung dieser Systeme. Das Requirements Engineering ist der Prozess der Spezifikation und Verfeinerung von Anforderungen. Er steht typischerweise am Anfang von Entwicklungsprojekten. Anforderungen an das zukünftige System werden erhoben, dokumentiert und schrittweise verfeinert und die Ergebnisse in Lasten- und Pflichtenheften festgeschrieben. Das Lastenheft (Anforderungsspezifikation) beschreibt die Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers. Das Pflichtenheft dagegen beschreibt, wie der Auftragnehmer die Anforderungen im Lastenheft umzusetzen gedenkt. Bei Vergabe an Dritte bilden diese Dokumente eine wichtige Grundlage für die Vertragsgestaltung. In der traditionellen Anwendungsentwicklung kommt diesem Prozess eine zentrale Bedeutung zu. Neue oder geänderte Anforderungen tauchen aber auch immer wieder über den gesamten Lebenszyklus des Systems auf. So können beispielsweise neben neuen Kundenanforderungen auch Probleme im Betrieb von s zu Requests führen, die Anpassungen erforderlich machen. Das Design umfasst den gesamten Entwurf des Systems. Während das Requirements Engineering die Beschreibung der fachlichen Anforderungen umfasst, wird im Design die Umsetzung dieser fachlichen Anforderungen in der Software und den technischen Systemen festgelegt. Das Build beinhaltet die Implementierung des Softwareentwurfs sowie die Integration und den Test der einzelnen Komponenten. Außerdem sind das Betriebssystem und die Infrastruktur für die Laufzeitumgebung der Anwendung aufzusetzen. Letzteres ist insbesondere für Anwendungen, die als s betrieben werden sollen, ein unverzichtbarer Bestandteil. Am Ende steht die Abnahme der gesamten Applikation und Systemlösung. Nach dem traditionellen Verständnis war die Anwendungsentwicklung weitgehend auf die Prozesse bis zur Bereitstellung der Software begrenzt. Mit der Überführung in den Betrieb und der Betreuung der Anwendung schließen sich weitere Prozessschritte an. Im Deploy werden sowohl die Anwendung als auch das Betreibermodell und die dafür erforderliche Infrastruktur eingeführt und in die HMD 278 7

9 Application Standards und Best Practices bestehende IT-Umgebung integriert. Die Lauffähigkeit in der Umgebung wird abschließend getestet und die Prozesse überprüft, bevor eine Übergabe in den Betrieb erfolgt. Im Operate wird die leistung erbracht und die Performance gemessen sowie die Einhaltung der definierten Levels überprüft. Im Optimize werden die Prozesse der erbringung auf Basis von Performance-Messungen, Problemreports und Kennzahlen verbessert und Kosten optimiert. Das Anwendungsmanagement umfasst demzufolge den gesamten Lebenszyklus einer Applikation und deckt alle Aufgaben von der Entwicklung bis zum Betrieb von Anwendungen ab. Anwendungen werden jedoch nicht isoliert geplant und entwickelt, sondern sind in die gesamte Anwendungslandschaft zu integrieren. Die einzelnen Anwendungen sind hinsichtlich der funktionalen Abdeckung und der Unterstützung von Prozessen abzustimmen und in die bestehende Infrastruktur zu integrieren. Dieses des Applikationsportfolios wird in einem weitgefassten Verständnis ebenfalls als ein Bestandteil des Anwendungsmanagements betrachtet. Mit der Planung und Entwicklung von Anwendungen auf der übergeordneten Ebene einer Portfolio- und Programmplanung setzt sich das von Unternehmensarchitekturen auseinander. Im Mittelpunkt steht das Unternehmen als Gesamtsystem und die am Geschäft ausgerichtete Planung integrierter IT- Landschaften (»Architektur im Großen«), ähnlich wie bei einer Stadtplanung, bei der die Planung und das Layout eines kompletten Areals mit Gebäuden und der erforderlichen Infrastruktur und nicht die Architektur einzelner Gebäude im Mittelpunkt steht. Wie bei einer Stadtplanung sind auch hier Bebauungspläne ein zentrales Element der Planung. Ein Bebauungsplan für Anwendungen zum Beispiel zeigt in einer zweidimensionalen Matrix die Zuordnung von Anwendungen zu den Geschäftsprozessen, für die sie genutzt werden, sowie deren Anwendung in Bereichen der Organisation (siehe das Beispiel in [Rohloff 2008, S. 94]). Bebauungspläne sind ein zentrales Kommunikationsmittel, um die IT-Landschaft sowohl im Istzustand als auch als Zielarchitektur transparent zu beschreiben. Sie dienen als Entscheidungsgrundlage auf der ebene und helfen, den Wert und den Lebenszyklus der aktuellen und zukünftigen Systeme planen zu können. Aus den Bebauungsplänen können erforderliche Projekte zur Weiterentwicklung der Architektur abgeleitet und mithilfe von Portfoliodarstellungen priorisiert werden. Damit stellen die Planung der Unternehmensarchitektur und das Architekturmanagement eine übergeordnete Planung für Anwendungen dar. Sie definieren die Rahmenbedingungen für das Anwendungsmanagement und legen die inhaltlichen Schwerpunkte und Eigenschaften der einzelnen Anwendungen fest. Die Integration der Entwicklung von Unternehmensarchitekturen mit dem Anwendungsmanagement ist damit eine vordringliche Aufgabe für ein erfolgreiches der Informationssysteme. In der Abstimmung der gesamten Leistungskette erschließen sich unterschiedliche Gestaltungsformen von der Eigenentwicklung von Software, dem Einsatz von Standardlösungen sowie dem Outsourcing von der Anwendungsentwicklung bis zu einem Application Providing. Diese arbeitsteilige Leistungserbringung über mehrere Partner hinweg erfordert aber auch eine eindeutige Abstimmung und Beschreibung von Prozessen, Aufgaben und deren Schnittstellen. Nicht zuletzt aufgrund der zunehmenden Industrialisierung und neuer Formen der Arbeitsteilung und Organisation der IT haben sich über die letzten Jahre verschiedene Best Practices und Standards etabliert. Ihre Nutzung erleichtert die Abstimmung und Integration sowie die durchgängige Leistungserbringung über den gesamten Lebenszyklus hinweg. Abschnitt 3 stellt für das Anwendungsmanagement wesentliche Best Practices vor. 8 HMD 278

10 Application Standards und Best Practices 3 Standards und Best Practices 3.1 IT Infrastructure Library (ITIL) Die IT Infrastructure Library (ITIL, ist eine Best-Practice-Sammlung insbesondere für das IT-management [ITSMF 2007]. Sie beinhaltet eine umfassende und öffentlich verfügbare Dokumentation zur Planung, Erbringung und Unterstützung von IT- Dienstleistungen. Die Ursprünge von ITIL gehen in die 90er-Jahre zurück. Über die Jahre wurde ITIL unter der Federführung des britischen Office of Government Commerce (OGC) von Anwendern, Dienstleistern, Herstellern und Beratern kontinuierlich weiterentwickelt und ist mittlerweile ein De-facto-Standard. In den Jahren wurde ITIL überarbeitet, in acht Büchern zusammengefast und als ITIL Version 2 veröffentlicht. Diese besteht aus zwei Kernbereichen, der Bereitstellung von IT-Diensten (IT- Delivery) und der Unterstützung der Diensterbringung (IT- Support). Damit deckt diese Version zentrale Bereiche der Erbringung von IT-s ab, behandelt aber z.b. die Entwicklung der s oder die Einbindung in die Planung und das Geschäft nur am Rande. Im Jahre 2007 wurde ITIL Version 3 veröffentlicht. Diese Version betrachtet wesentlich umfassender den gesamten Lebenszyklus von IT-Dienstleistungen von der strategie und dem design über den Betrieb bis zur kontinuierlichen verbesserung. ITIL besteht in seiner dritten Version aus den fünf Kernpublikationen:! Strategy (strategie)! Design (Modelle für den Betrieb)! Transition (implementierung bzw. -einführung)! Operation (operativer Betrieb von s)! Continual Improvement (kontinuierliche Verbesserung von s) Die fünf Publikationen beschreiben insgesamt 26 verschiedene Prozesse, von der strategischen Ausrichtung der IT bis zu laufenden Verbesserungsprozessen in der erstellung. Entsprechend der Zielsetzung liegen die Schwerpunkte von ITIL jedoch bei der Entwicklung und dem Betrieb von s. Das Anwendungsmanagement als Grundlage für die Entwicklung von s ist ein wichtiger Bestandteil, liegt aber nicht unbedingt im Schwerpunkt der Betrachtung. Es verbleiben Aufgaben im Anwendungsmanagement, die nur zum Teil durch die Best Practices von ITIL abgedeckt werden. Aufgrund der unterschiedlich gesetzten Schwerpunkte ist der Lifecycle nach ITIL anders als der des Anwendungsmanagements definiert. Tabelle 1 zeigt die ITIL-Prozesse entlang der Phasen des Lifecycle von der Strategie bis zur Implementierung. Gleichzeitig sind diese Prozesse in der Tabelle den Phasen des Anwendungsmanagements von Requirements bis Optimize zugeordnet, in der sie durchgeführt werden. So zeigt die Tabelle im Überblick, wie und mit welchen Prozessen ITIL das Anwendungsmanagement abdeckt. Für das Anwendungsmanagement kann auf einen großen Fundus an Best Practices nach ITIL zurückgegriffen werden. Es bleiben jedoch Themenbereiche offen, die nicht abgedeckt werden und eine Ergänzung erfordern. Gleichwohl bietet ITIL, auch aufgrund der zunehmenden Verbreitung, eine unverzichtbare Grundlage für die Implementierung standardisierter Prozesse für das IT-management und ist auch für die Integration des Anwendungsmanagements unbedingt zu berücksichtigen. 3.2 Application s Library (ASL) Die Arbeiten zur Application s Library (ASL) entstanden Ende der 90er-Jahre in den Niederlanden und wurden mit der Gründung der ASL Foundation ( als Public Domain zur Verfügung gestellt [Pols & Backer 2006; Bon & Verheijen 2007, Kap. 20]. Wie bereits durch den Namen deutlich wird, stellt die ASL das Anwendungsmanagement in das Zentrum ihrer Beschreibung. HMD 278 9

11 Application Standards und Best Practices ITIL Lifecycle AM Lifecycle Strategy Design Transition Operation Continual Improvement Requirements Portfolio, Demand Level, Requirements Engineering Level Design Requirements Engineering, Catalogue Build Configuration, Validation & Testing Deploy Change, Release & Deployment Operate Capacity, Availability, Continuity, Information Security Assets & Configuration Incident, Request Fulfilment, Problem, Access Mgt. Measurement & Control Optimize Level Assessment & Analysis Tab. 1: Zuordnung der ITIL-Prozesse des Lifecycle zum Application (vgl. [Meijer et al. 2008, S. 5]) ITIL und ASL sind komplementäre Frameworks. Während ITIL üblicherweise auf allgemeine managementprozesse angewandt wird, wurde die ASL für die Prozesse des Anwendungsmanagements, die ITIL nicht in der Tiefe behandelt, entwickelt. Die ASL versteht unter dem Anwendungsmanagement die vertraglich vereinbarte Verantwortung für das und die Durchführung aller Aktivitäten, die sich auf die Wartung und die Entwicklung bestehender Anwendungen innerhalb genau definierter Levels beziehen, wobei unter der Entwicklung vor allem die Weiterentwicklung bestehender Applikationen gemeint ist. Die Aktivitäten der Erstentwicklung und damit die Aufgaben der Anwendungsentwicklung nach klassischem Verständnis stehen weniger im Fokus. Die Modelle werden nicht als Konkurrenz zu ITIL gesehen, sondern die Foundation unternimmt den Versuch einer Integration und Koexistenz der Referenzmodelle. Dadurch sollen die spezifischen Vorteile der Modelle in ihren jeweiligen Anwendungsbereichen genutzt werden. 10 HMD 278

12 Application Standards und Best Practices Die ASL richtet sich an Manager und Experten, die die Prozesse und den Reifegrad ihrer s im Anwendungsmanagement verbessern möchten. Die Application s Library wird international unterstützt, die größte Akzeptanz findet sich jedoch nach wie vor in den Niederlanden, wo die meisten großen provider und eine Reihe von Anwenderorganisationen der Foundation beigetreten sind. Abbildung 2 zeigt das ASL-Framework im Überblick. Es besteht aus sechs Prozessclustern, die in drei Ebenen aufgeteilt sind: die operativen Prozesse und die prozesse mit einer kurz- bis mittelfristigen Perspektive sowie die längerfristig ausgerichteten Strategieprozesse. ASL basiert auf ITIL-Konzepten, was durch die Namen und die Struktur vieler Prozesse offensichtlich wird. ASL setzt diese Konzepte jedoch mit dem Schwerpunkt im der Wartung und der Erweiterung von Anwendungen ein. Dies hat nicht nur andere Fragestellungen zum Gegenstand, sondern erfordert auch unterschiedliche Fähigkeiten, sodass die inhaltlichen Ausprägungen dieser Prozesse in ASL andere sind. Das Cluster Maintenance & Control zielt darauf ab, sicherzustellen, dass alle Anwendungen funktionieren und laufen. Die Anwendungen sollen die Geschäftsprozesse unterstützen, möglichst unter optimalem Einsatz der Ressourcen sowie einem Minimum an Unterbrechungen des Betriebs. Die fünf dem Cluster zugeordneten Prozesse Incident, Configuration, Availability, Capacity und Continuity sind den ITIL-Prozessen mit gleichen Namen ähnlich, aber aufgrund der Natur und den Zielsetzungen des Anwendungsmanagements anders ausgestaltet. Das Cluster Enhancement & Renovation stellt sicher, dass die Anwendungen entsprechend sich verändernden Anforderungen weiterentwickelt und angepasst werden. Die zugeordneten Prozesse sind den Aktivitäten ähnlich, die während der ursprünglichen Entwicklung der Anwendungen durchgeführt werden. Die Organizational Cycle Applications Cycle Account Definition Market Definition Customer Organization Strategy Strategic Processes Skill Definition Delivery Definition Technology Definition ICT Development Strategy ICT Portfolio Lifecycle Customer Environment Strategy Processes Planning and Control Cost Quality Level Incident Change Design Operational Processes Continuity Availability Impact Analysis Implementation Realization Capacity Configuration Software Control/Distribution Testing Maintenance & Control Connecting Processes Enhancement & Renovation Abb. 2: Das ASL-Framework [Pols & Backer 2006, S. 15; Heslenfeld et al. 2007, S. 68] HMD

13 Application Standards und Best Practices Auswirkungsanalyse umfasst alle Aktivitäten zur Identifizierung und Bewertung der Auswirkung einer Änderungsanforderung (Request for Change). Der Entwurf beinhaltet eine Informationsanalyse und den funktionalen Entwurf. Die Umsetzung umfasst den technischen Entwurf und die Programmierung der Änderungen in den Anwendungen. Es schließt sich der Test der neuen Releases und die Übergabe zur Akzeptanzprüfung an. Dem folgt die Einführung der geänderten Software und anderer komponenten, einschließlich Konvertierung, Akzeptanztests, Schulung, Anleitung und Migration sowie der abschließenden Abnahme. Diese beiden operativen Prozesscluster stehen in enger Verbindung, da sie sich mit den gleichen Anwendungsobjekten beschäftigen. Sie werden durch zwei verbindende Prozesse ergänzt. Das Change umfasst sämtliche Abstimmungen von Änderungen mit dem Kunden und deren Berücksichtigung in neuen Releases. Die Software Control/Distribution sichert die Verteilung von Software und Dokumentation während der Entwicklung, des Testens sowie der Übergabe in den Betrieb. Die Ebene der prozesse stellt sicher, dass alle operativen Prozesscluster aufeinander abgestimmt und gemanagt werden. Schwerpunkte sind die Planung und Steuerung von Terminen, Ressourcen, Kosten und Qualität sowie die Einhaltung der Levels. Die strategische Ebene umfasst das Anwendungszyklusmanagement und die langfristige Organisationsentwicklung für das Anwendungsmanagement. Das Cluster Applications Cycle beschäftigt sich mit dem Business/IT-Alignment und entwickelt eine langfristige Strategie für den Einsatz von Informationssystemen. Diese wird im Einklang mit der Strategie der Unternehmensorganisation entworfen. Außerdem wird die Unternehmensumwelt berücksichtigt. Dabei stehen zwei Blickwinkel im Mittelpunkt der Betrachtung, die individuellen Anwendungen und ihr Lebenszyklus sowie das gesamte Anwendungsportfolio. Die ASL wird damit einer umfassenden Betrachtung nicht nur des Lebenszyklus einzelner Anwendungen gerecht, sondern auch der IT- Landschaft und des Portfolios, wie es in Abbildung 1 skizziert wurde. Das Cluster Organizational Cycle betrachtet die langfristige Organisationsentwicklung der organisation. Hierzu gehören die Marktentwicklung, die Festlegung eigener Leistungen und möglicher Partnerschaften in der Leistungserbringung. Außerdem werden die dafür erforderlichen Fähigkeiten und Technologien bestimmt. Das ASL-Framework umfasst damit Prozessbeschreibungen zu 26 Prozessen. Es beinhaltet für jeden Prozess die Zielsetzungen, die jeweiligen Aktivitäten mit Inputs und Outputs sowie die Beziehungen zu den anderen Prozessen. In Ergänzung zu dem ASL-Framework und den Best Practices wurde außerdem ein Reifegradmodell entwickelt, um die Reife der individuellen Prozesse im Anwendungsmanagement sowie der organisation zu messen. Nachdem wichtige Aufgabenbereiche, die insbesondere die Schnittstelle zwischen Geschäft und IT-Organisation betreffen, durch das ASL-Framework nicht erfasst sind, wurde dieses durch die Business Information s Library (BiSL) ergänzt [Pols & Backer 2007; Bon & Verheijen 2007, Kap. 16]. Die Grundstruktur des Modells ist mit der des ASL-Frameworks vergleichbar. Der Schwerpunkt liegt im Informationsmanagement und adressiert das bisher noch nicht abgedeckte Themenfeld des s von Informationssystemen. Die wesentlichen Prozesscluster im Modell sind auf der strategischen Ebene die IT-Organisation, die Entwicklung der Informationsstrategie sowie die Verknüpfung durch die Informationskoordination. Die Prozesse auf der ebene sind die Planung von Zeiten und Kapazitäten, das Kostenmanagement, das Demand sowie das Level. Auf der operativen Ebene stehen das der Nutzung, d.h. die operative 12 HMD 278