Anwendungen werden beschafft oder entwickelt. Häufig erfolgt dies im Rahmen eines klaren und abgestimmten regelmäßigen Prozesses. Natürlich werden sie dann betrieben, damit sie für den Anwender verfügbar sind. Und dann verschwinden sie regelmäßig vom Radar-Schirm. Die Wartung und Pflege, die Anwenderunterstützung, der Updatezyklus, die kontinuierliche Sicherheitsprüfung, die Investitionen in Erweiterungen und die Entscheidungskriterien, wann die Anwendung abgelöst und migriert werden müssen – alle diese Aufgaben verschwinden in einer dunklen Wolke und erfolgen zu unbestimmten Zeiten. Aber muss nicht gerade dieser kostenträchtige Teil des Lebenszyklus von Anwendungen proaktiv überwacht und gemanagt werden? Müssen die Investitionen nicht bekannt sein, die notwendig sind, um die jeweilige Anwendung auf aktuellen Stand zu halten? Die Kernanwendungen in einem Unternehmen werden doch nicht selten mehr als 10-15 Jahre eingesetzt und erfordern in dieser Zeit ein Vielfaches der eigentlichen Beschaffungskosten.

Aber was ist eigentlich eine Anwendung und wo sollte man die Analyse zunächst eingrenzen? In der heutigen komplexen IT-Infrastrukturlandschaft ist dies nicht mehr so eindeutig feststellbar. Webservice, Mashups, ScriptingHosts, JavaScript und StoredProcedures machen es bei der Identifikation einer Anwendung nicht mehr so einfach, wie es mal zu Mainframe-Zeiten und Terminals war. Ist es die Excel-Tabelle oder die Website mit verteilten Umgebung mit unterschiedlichen Dienstleistern und Zuständigkeitsgrenzen.

Gartner definiert hierbei eine Anwendung als

• Zusammenstellung von Software-Code, welcher Prozesslogik und Geschäftsregeln enthält
• Eingaben von Nutzern oder Systemen in Datenstrukturen überträgt und
• das Ziel verfolgt, Geschäftsprozesse, Aufgaben oder Aktivitäten zu optimieren oder automatisieren

Und was sind die Schlüssel-Elemente in der gesamten Anwendungslandschaft? Wie sieht der Teil des Eisberges unter Wasser aus, der von Anwender oder der Führungskraft nicht gesehen werden, aber die Flexibilität und Kosten der Gesamtanwendung in einem Unternehmen ausmachen:

• Anzahl der geschulten Anwender
• Notwendige technologische Fähigkeiten
• Anwendungs- und Diensteserver
• Integration mit anderen Anwendungen und Schnittstellen
• Betriebssystemplattformen
• Anzahl der Datensätze und Informationsobjekte
• Werkzeuge für das Systemmanagement
• Werkzeuge für die Entwicklung und Testverfahren

Für die Erstellung einer Anwendungsstrategie ist sicherlich ein klares Verständnis über den aktuellen Stand und die zukünftige Ausrichtung / Herstellerunterstützung dieser begleitenden Komponenten erforderlich.

Hierbei ist es wichtig, dass der Planungshorizont nicht nur auf das aktuelle Bugetjahr oder Folgejahr bezogen ist, sondern aufgrund des i.d.R. langen Lebenszyklus der Anwendungen ein Mehrjahresszenario abdecken sollte. Als Zeitraum sollten mindestens 6-7 Jahre angesetzt werden. Auch wenn es schwer sein wird, über einen solchen Zeitraum belastbare Informationen zu gewinnen, müssen bei nicht klaren Rahmenbedingungen jeweils begründete Annahmen dokumentiert werden. Hierbei müssen die unterschiedlichen Anforderungen in einer ausgewogenen Balance dargestellt werden, um unterschiedliche mögliche Zukunfsszenarien entwickeln zu können. Diese Zukunftsszenarien müssen dann Auskunft darüber geben, wenn ein z.B. bestimmtes Ereignis eintritt (z.B. Abkündigung der Herstellerunterstützung einzelner Produkte, veränderte Zusammenarbeit mit anderen Unternehmen/Organisationen, radikale Änderung der Informationsanforderungen, etc.), welche Option und Auswirkungen dies als Planentscheidung zur Folge haben wird.

Um einen regelmäßigen Überblick zu den einzelnen Anwendungen zu erhalten, sind die wesentlichen Eigenschaften zu den einzelnen Anwendungen zu bewerten:

• Betriebskosten (Budget)
• Benutzerfreundlichkeit (Anwenderprobleme, HelpDesk-Auswertungen)
• Integrationsfähigkeit (Schnittstellenbeschreibungen , Architekturbausteine)
• Zuverlässigkeit (Fehlerrate)
• Ausfallsicherheit (Ausfälle pro Woche)
• etc.

Diese sog. Anwendungslandschaft kann natürlich nicht isoliert betrachtet werden, sondern muss aufgrund der Abhängigkeiten mit anderen Komponenten im Rahmen einer Portfoliobewertung regelmäßig überwacht und gesteuert werden:

• Anwendungsportfolio (Übersicht aller Fachanwendungen)
• Standardsoftwareportfolio (Übersicht der Betriebssysteme, Office-Anwendungen, Kommunikationsplattform, Middleware, Test- und Entwicklungswerkzeuge)
• Hardwareportfolio (Übersicht der Comuterplattformen, Server, Speichermedien und Netzwerkgeräte)

Jede Planung geht dabei von Annahmen aus, wie sich die Zukunft entwickeln wird. Jede dieser Annahmen sollte entsprechend dokumentiert werden, damit in regelmäßigen Abständen die Veränderungen neu bewertet und integriert werden kann. Grundsätzlich sollte hierbei jeweils ein Portfolio einer bestimmten Person verantwortlich zugeordnet werden. Diese hat dann die Aufgabe, mit den entsprechenden Verfahrensverantwortlichen der jeweiligen Fachanwendung die Annahmen regelmäßig zu prüfen. Im Rahmen der Gesamtstrategieplanung können dann einmal im Jahr die Portfoliobewertungen übergreifend analysieren werden, sodass sie rechtzeitig in die IT-Strategieplanung einfließen können.

Das Portfoliomanagement ist sicherlich nicht einfach und schnell in einer großen Organisation aufzubauen, wo zumeist hunderte von Fachanwendungen und eine heterogene Infrastrukturlandschaft vorzufinden ist. Also gilt auch hier der Grundsatz: Klein Anfangen und steigern…

2-3 große Kernanwendungen als Beispiel verwenden. Die Erfahrungen als Kochbuch nutzen und dieses dann schrittweise auf die anderen oben aufgeführten Bereiche erweitern.

Weitere Informationen zum Thema Strategische IT-Planung sind u.a. hier zu finden:

IT-Strategie ist nicht nur ein Dokument, sondern ein Prozess!

Wie kann eine Managementfassung der IT-Strategie aussehen?

Beispiele von IT-Strategien in der amerikanischen öffentlichen Verwaltung

Weitere Artikel auf diesem Blog mit dem Stichwort ‘Strategie’…