Den Wertbeitrag der IT-Architektur ausweisen

Ist gute IT ihr Geld wert?

Daniel Liebhart

Die Informationstechnologie unterstützt Unternehmen bei ihrer betrieblichen Tätigkeit und stellt damit einen grundlegenden Bestandteil des Unternehmenserfolgs dar. Trotzdem ist es bisher schwierig, den Wertbeitrag der IT-Architektur konkret und sicher auszuweisen.

Business Technology Magazin

Der Artikel „Ist gute IT ihr Geld wert?“ von Daniel Liebhart ist erstmalig erschienen im

Business Technology Magazin 4.2011

Wo ist Pragmatismus gefragt?

Es existieren in der betrieblichen Informatik drei Bereiche, die praktisch sofort zu einem besseren Wertbeitrag der IT führen. Das ist die Verlängerung bestehender Anwendungen durch Modernisierung, die bewusste Umsetzung von Schnittstellen und die Konsolidierung gewachsener Anwendungen mit überlappender Funktionalität.

Für die Lebensverlängerung bestehender Anwendungen gibt es zwei schlagende Argumente. Erstens gibt es sie bereits, sprich die notwendigen Investitionen sind bereits getätigt: Es wesentlich billiger, eine Komponente weiter zu verwenden, als sie komplett neu zu erstellen. Zweitens haben die Anwendungen sich im Einsatz bewährt, sonst wären sie längst nicht mehr vorhanden. Bewährte Lösungen eignen sich mit größter Wahrscheinlichkeit zur weiteren Verwendung. Das wichtigste Instrument, das die IT zur Lebensverlängerung bestehender Anwendungen in den Händen hält, sind serviceorientierte Architekturen (SOA). Eigentlich sogar nur ein Aspekt einer SOA – die standardisierte Serviceschnittstelle. Um eine bestehende Anwendung in einer auf SOA basierenden Lösung einzusetzen, muss die Anwendung über eine Reihe von Web-Service-Interfaces verfügen. In der Praxis ist es sinnvoll, dieses nahe an den bestehenden Systemen zu realisieren, um möglichst wenig am bestehenden System ändern zu müssen. Das zieht jedoch in vielen Fällen eine extrem pragmatische Umsetzung im Unternehmen nach sich. Ziel der Weiterverwendung bestehender Systeme ist und bleibt nicht die konzeptionelle Integrität, sondern die Kostenersparnis. Beispielsweise ist es durchaus vernünftig, einen Web Service zu realisieren, der lediglich FTP-Dateien mit einem Host austauscht. Die Host-Anwendung muss folglich überhaupt nicht geändert werden. Eine solche Verlängerung den Lebenszyklus eines Informationssystems bedeutet, dass die Investition wesentlich besser amortisiert werden kann, als wenn es abgelöst werden muss. Dieser Kostenvorteil wird zusätzlich erhöht, wenn weite Teile des bestehenden Systems als unternehmensweit zugängliche Services zur Verfügung gestellt werden können und weitere Anwendungen darauf zugreifen können.

Die bewusste Umsetzung von Schnittstellen ist ein zweiter pragmatischer Ansatz, um den Wertbeitrag der IT an den Unternehmenserfolg zu steigern. Aus IT-Architektursicht ist die Schnittstellen einer der am meisten unterschätzten Aspekte einer Anwendungslandschaft. Es existieren praktisch keine Informationssysteme ohne Schnittstellen. Der Begriff umfasst sowohl das User Interface als auch die Schnittstellen zum Betriebssystem, zur Datenbank und zu anderen Systemen. Schnittstellen, die jedoch oft Kopfzerbrechen bereiten, sind die zum Datenaustausch zwischen verschiedenen Systemen. Die Schwierigkeit besteht vor allem darin, bestehende IT-Systeme mit neuen zu verbinden. In vielen Fällen sind die Beschreibungen der Daten, der Formate und der technischen Möglichkeiten unvollständig oder falsch. Hinzu kommt, dass die Daten verschieden granular verwendet werden. Laut einer Analyse von Forrester Research umfasst die Entwicklung von Schnittstellen 35 – 40 Prozent des Gesamtaufwands bei der Programmierung. Bei Punkt-zu-Punkt-Schnittstellen entfallen sogar 70 Prozent des für den Informationsaustausch. Darüber hinaus treten zwischen 39 Prozent und 50 Prozent aller Fehler eines Systems innerhalb der Schnittstelle auf.

In einer Schnittstelle zwischen zwei Systemen geschieht aus logischer Sicht eigentlich immer dasselbe. Daten werden aus dem einen System extrahiert, transformiert und/oder konvertiert und in das Zielsystem importiert. Selbst ein einfacher Aufruf mit Datenübergabe realisiert diese Grundmechanismen. Das Extrahieren und Importieren geschieht in einem Schritt, und etwaige Transformationen und Konversionen werden entweder vom aufrufenden oder Zielsystem übernommen. Zur Umsetzung von Schnittstellen existieren verschiedene konventionelle Lösungen: die komplett ausprogrammierte Schnittstelle, der Einsatz von Konvertern, ETL Tools oder Frameworks, beziehungsweise die Abwicklung via Messaging oder anderen Integrationsinfrastrukturen. Um Kosten und die Flexibilität bestehender und neuer Systeme kontrollieren zu können, verfügt eine kluge IT-Architektur über gute und explizit umgesetzte Schnittstellen. Darüber hinaus ist sie Garant für ein vernünftiges Funktionieren der gesamten Anwendungslandschaft.

Die Konsolidierung bestehender Anwendungen kann durch einen Vergleich bestehender und verfügbarer Software und aus Sicht der Fachabteilung notwendigen Dienste gesteuert werden. Dabei kommen Überlegungen zur Funktionalität, mögliche Überschneidungen sowie Aspekte der fachlichen Abbildbarkeit zum Tragen. Funktionalität, die in verschiedenen Anwendungen vorhanden ist und mit vergleichbaren Kosten als Service bereitgestellt werden kann, muss nicht doppelt abgedeckt werden. Eine funktionale Überschneidung der vorhandenen Systeme ergibt eine bestimmte Granularität. Ist diese deckungsgleich mit der Granularität von Diensten, die aus fachlichen Anforderungen abgeleitet werden, lohnt sich eine Konsolidierung. Ein bestehendes System weiter zu verwenden, macht aber nur dann Sinn, wenn verfügbare Dienste auch weitgehend mit fachlichen übereinstimmen oder zumindest die Zusammenstellung eines neuen Dienstes sehr einfach ist.

Eine Konsolidierung von Anwendungen setzt immer eine Bestandsaufnahme bereits vorhandener Systeme voraus. Außerdem muss eine fachliche Prozesslandkarte geschaffen werden, die alle Geschäftsprozesse der Domäne erfasst und beschreibt. Daraus wird eine Liste von Prozessen abgeleitet, die wiederum einzeln beschrieben werden. Ausführbare Prozesse trennt man dann von den nicht ausführbaren und modelliert sie. Daraus werden die „Prozess-Services“ isoliert und dokumentiert – beispielsweise mit einer Servicebeschreibung. Das Ergebnis des „Top Down Service Designs“ ist eine Liste mit Diensten, die allein aufgrund fachlicher Anforderungen erfasst wurden. Aus der Analyse der bestehenden Systeme werden nun die „Technischen Services“ abgeleitet. Für jeden einzelnen wird die zur Bereitstellung notwendige Modernisierungstechnik ausgewählt und die Kosten für eine Modernisierung des bestehenden Systems berechnet und ausgewiesen. Das Ergebnis der „Bottom Up Service Isolation“ ist eine Liste mit Diensten, die allein aufgrund der Struktur und der Funktionalitäten der bestehenden Anwendungen erfasst wurden.

Ordnung muss sein

Eine weitere zentrale Aufgabe der IT-Architektur ist die Zuordnung geforderter Funktionalität auf die richtige Umsetzungsebene. Dabei helfen zwei grundlegende Regeln: die Trennung von Daten und Anwendungen sowie die Einführung von Systemtypen. Laut Statistik liegt der durchschnittliche Lebenszyklus von Businessanwendungen zwischen 12 und 15 Jahren. Spätestens dann werden sie entweder abgelöst oder sie erfahren eine vollständige Modernisierung. Dieser Zyklus ist einerseits bedingt durch die Veränderung der Geschäftstätigkeit, durch die eine unterstützende IT nicht mehr den notwendigen Mehrwert liefern kann. Andererseits werden durch technologische Fortschritte sowohl Betrieb als auch Unterhalt einer 15 Jahre alten Anwendung sehr teuer. Daten hingegen leben mit 20 bis 30 Jahren fast doppelt so lange wie Anwendungen. Der Grund: Zentrale Businessobjekte, wie Kunden und Produkte, verschwinden nur selten komplett. Es gibt kaum ein Unternehmen, das die Informationen über Kunden – auch wenn sie schon lange nichts mehr bezogen haben – bedenkenlos löschen wollen. Dasselbe gilt für eigene Produkte und Dienstleistungen. Beide sind zentraler Bestandteil des Unternehmenswissens, die neben anderen Informationen so lange wie möglich vorgehalten werden, da sie sich sehr oft wieder als nützlich erweisen. Heute wird der fundamentalen Tatsache der unterschiedlichen Lebenszyklen kaum Rechnung getragen. Das wird eine kluge IT-Architektur ändern und damit den Wert der Unternehmensinformationen durch Einführung von Governance-Strukturen zur gezielten Pflege und die korrekte Zuordnung der Systeme steigern.

Abb. 3: Ordnung durch Systemtypen

Enterprise-Lösungen, also Informationssysteme zur Unterstützung der betrieblichen Tätigkeit, können in verschiedene Arten oder auch Systemtypen unterschieden werden (Abb. 3). Eine solche Aufteilung reflektiert einerseits die heutige betriebliche Realität und andererseits das Angebot der Hersteller. Der Grund: Bestimmte Funktionen können klar bestimmten Typen zugeordnet werden. Systeme können entsprechend ihrer Zuordnung verwaltet, geplant, realisiert und betrieben werden. Auch ihre Eignung zur möglichen Auslagerung in die Cloud lässt sich anhand nachvollziehbarer Kriterien prüfen. Die Aufteilung von Enterprise Lösungen in Systemtypen ist relativ einfach: Man unterscheidet zwischen operativen und dispositiven Systemen und zwischen Systemen für die Verwaltung unstrukturierter Daten. Operative Systeme lassen sich in branchenspezifische, generelle und Intercompany-Systeme unterteilen. Die generellen operativen Systemtypen sind Enterprise Ressource Planning (ERP), Customer Relationship Management (CRM) und Supply Chain Management (SCM). Zu den branchenspezifischen gehören Straight Through Processing (STP) für Banken, Product Lifecycle Management (PLM) für Industriebetriebe oder Track-and-Trace-Systeme für Logistikunternehmen. Unter Intercompany-Systeme fallen elektronische Märkte oder Datenaustauschplattformen. Die dispositiven Systeme umfassen die beiden Klassen Management-Information-Systeme (MIS) und Planungssysteme. Unter MIS sind Systemtypen wie Data Warehouse (DWH) und Corporate Performance Management (CPM) zu finden, während sich unter Planungssysteme Data Mining, Analytics und Simulationen subsumieren lassen. Wissensbasierte Anwendungen, Büro-Automation und Multimedia sind Ausprägungen der Systeme zur Verwaltung unstrukturierter Daten. Durch Systemtypen kann jede IT-Architektur Ordnung schaffen und ermöglicht damit ein vernünftiges Nebeneinander bestehender und neuer Technologien.

Kosten sind nur schwer korrekt auszuweisen

Heutzutage ist es üblich, jede größere IT-Investition auf der Basis einer Kosten-Nutzen-Rechung zu tätigen. In den meisten Fällen werden jedoch nur relativ einfache Kalkulationen durchgeführt. Beispielsweise stellt man gern die zu erzielende Arbeitszeitersparnis und höhere Betriebseffektivität dem notwendigen Aufwand für Bereitstellung und Betrieb des Informationssystems gegenüber. Der Nutzen einer Investition entspricht dann exakt den Ersparnissen an Prozesskosten wie Durchlaufzeiten oder Personalbedarf. Ein weiteres Berechnungsbeispiel ist die Senkung der Unterhaltskosten durch Neubau oder Ersatz eines bestehenden IT-Systems. Der betriebswirtschaftliche Nutzen lässt sich hier direkt aus der Reduktion der Betriebskosten berechnen, was nicht zuletzt auch die steigende Beliebtheit von Konsolidierungen von Serverlandschaften und anderen Infrastrukturkomponenten erklärt. Darüber hinaus sind noch viele weitere Varianten im Rahmen der normalen Investitionsrechnungen für die Informationstechnologie üblich. Was jedoch bedenklich stimmt, ist die Tatsache, dass gemäß einer britischen Studie etwa 90 Prozent aller Unternehmen den Return on Invest (ROI) von IT-Investitionen lediglich intuitiv oder in Form einer groben Schätzung berechnen. Leider ist statisch nicht belegt, wie viele Unternehmen eine vorbereitende ROI- oder Net-Present-Value-Rechnung nach der Investition auf ihre Korrektheit prüfen. IT-Entscheider sollten sich dieser Tatsache jedoch bewusst sein und immer versuchen, laufende Kosten und den betrieblichen Nutzen schlüssig nachzuweisen – selbst wenn das im buchhalterischen Sinne kaum möglich ist.

Daniel Liebhart ist Dozent für Informatik an der Hochschule für Technik in Zürich und Solution Manager der Trivadis AG. Er ist Autor des Buchs „SOA goes real“ (Hanser Verlag) und Koautor verschiedener Fachbücher.
Geschrieben von
Daniel Liebhart
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.