IT-Kosten

Wie rechnet sich SOA in der Praxis?

19.12.2008 von Daniel Liebhart
Wer die Frage nach dem wirtschaftlichen Nutzen einer SOA beantwortet, kann auch das Management von den Vorzügen des Konzepts überzeugen.

Der Nutzen von SOA als Instrument zur Standardisierung und Flexibilisierung von Anwendungslandschaften lässt sich auf einfache und auf komplexe Weise messen. Jede Architektur hat per se noch keinen messbaren Nutzen. Die konkrete Anwendung, die auf einer SOA basiert, stellt am Ende den Business Case dar. Für diese Lösungen lässt sich der betriebswirtschaftliche Effekt gut rechnen. Schwieriger sieht die Sache aus, wenn Skaleneffekte und Effizienzsteigerungen auf Unternehmensebene konkret ausgewiesen werden sollen.

Für ein Unternehmen besteht der wesentliche Nutzen einer SOA in der Standardisierung und Flexibilität bezüglich des Anwendungsportfolios. SOA ist die erste Standardarchitektur überhaupt, die bestehende Systeme als integralen Bestandteil eines neuen Systems betrachtet. Die Grundidee hinter dem Motto "Dienste statt Applikationen" ist die Weiterverwendung ganzer Systeme und die Kombination bestehender Systeme zu einem funktional erweiterten neuen Gesamtsystem. Erreicht wird dies durch die Kapselung ganzer Systeme mit Hilfe definierter Serviceschnittstellen. Diese Weiterverwendung hat einen großen Einfluss auf die Kosten eines Systems. Werden bestehende Anwendungen teilweise oder ganz weiterverwendet statt Systeme als Ganzes neu zu bauen, sind erhebliche Einsparungen realisierbar.

Prozesse sind einfacher änderbar

Die Flexibilisierung einer Anwendung durch die Trennung der Business-Logik in statische und dynamische Bereiche ist eine weitere Stärke von SOA. Der statische Bereich der Business-Logik wird als Service realisiert, der dynamische Bereich wird getrennt davon als Prozess oder als Regel modelliert, generiert und ausgeführt. Eine Anwendung wird zur Sequenz von einzelnen Prozessschritten. Jeder Schritt stellt einen Service dar. Die Sequenz selbst wird als ausführbarer Prozess oder auch Workflow grafisch modelliert und zur Laufzeit ausgeführt. Ändert sich nun ein Geschäftsprozess, so muss lediglich der entsprechend modellierte Prozess nachgeführt werden. Die neuen Prozessinformationen werden geladen und die Änderung ist durchgeführt. Auf SOA basierende Systeme sind änderungsfreundlicher und damit wesentlich flexibler als mit konventionellen Mitteln umgesetzte Anwendungen. Deshalb sind solche Systeme auch kostengünstiger zu betreiben.

Kosten und Nutzen werden kaum gerechnet

Das Berechnen des Nutzens der IT steckt noch in den Anfängen, zumal die Informatik als Unterstützungsfunktion nur indirekten Einfluss auf die Produktivität eines Unternehmens oder einer Organisation hat. Die Berechnung des konkreten Wertbeitrags der Informationstechnologie wird zwar von verschiedenen Wissenschaftlern bereits vorgeschlagen (siehe: Bilanzierung des SOA-Nutzens?). In die betriebliche Rechnungslegung hat dieser Wertbeitrag aber noch nicht systematisch Eingang gefunden.

Statistisch gesehen geben Unternehmen heute zirka vier Prozent des Umsatzes für die IT aus. Mehr als die Hälfte davon fließt in den Betrieb bestehender Informationssysteme. Lediglich ein Viertel stecken die Firmen in Projekte. Diese Investitionen werden normalerweise über RoI (Return on Investment)- oder NPV-Rechnungen (Net Present Value, auch Kapitalwertmethode) gerechtfertigt. Leider ist heute statistisch kaum belegt, wie viele der Organisationen diese Investitionen überhaupt amortisieren oder die ursprüngliche Investitionsrechnung nachträglich prüfen. Laut einer britischen Studie berechnen rund 90 Prozent aller Unternehmen den ROI einer IT Investition intuitiv oder schätzen den Wert grob. Deshalb ist es kaum möglich, glaubhafte, statistisch belegbare und repräsentative Zahlen zu einer Kosten-Nutzen-Rechnung von SOA auszuweisen.

Kostenwirksamkeit von SOA

Eigentlich sollte der Nutzen einer SOA sich in vielen Fällen direkt auf die Kosten auswirken. Den Nutzen selbst und die daran geknüpften Erwartungen haben viele Hersteller und etliche Studien dokumentiert. So hat beispielsweise die Technische Universität Darmstadt in diesem Jahr eine qualitative Expertenbefragung kombiniert mit einer Literaturrecherche organisiert. Sie wird im Rahmen eines Forschungsvorhabens zur Identifikation des in der Praxis beobachtbaren Nutzenpotenzials einer SOA erarbeitet. Die bei weitem wichtigsten Nutzenpotenziale sind die Agilität und die Prozessoptimierung. Unter Agilität ist eine höhere Umsetzungsgeschwindigkeit durch die Modularität und eine verbesserte Flexibilität durch die Trennung der Logik in zwei Teile verstanden.

Hinter dem Begriff Prozessoptimierung verbirgt sich die Abbildung und Automatisierung von bereichs- und sogar unternehmensübergreifenden Abläufen. Obwohl in der Befragung die Wiederverwendung weit oben in der Rangliste zu finden ist, sind sich die Befragten nicht einig, wie hoch deren Nutzen in der Praxis tatsächlich ist. Bei einer durchschnittlichen Wiederverwendungsrate von Services zwischen 1 und 2 bleibt die entsprechende Rechnung in einem engen Rahmen.

Die Kostenwirksamkeit der Agilität ist anhand der beiden Faktoren Umsetzungsgeschwindigkeit und Flexibilität relativ einfach nachweisbar. Wenn sich Geschäftsprozesse schneller ändern lassen, wirkt sich dies direkt auf die Kosten aus. Je rascher die unterstützenden IT-Systeme an neue oder veränderte Geschäftsfälle anpassbar sind, desto schneller kann ein Unternehmen auf Veränderungen reagieren. Auch wenn die konkrete Rechnung in der Praxis relativ schwierig und nur von Fall zu Fall zu berechnen ist, so ist der Effekt derart signifikant, dass er sich auf das Unternehmensergebnis auswirkt. Die Trennung der Logik in einen statischen (Service) und in einen dynamischen Bereich (Prozesse und Regeln) sowie die grafische Modellierung der dynamischen Logik erlaubt einfache Änderungen an bestehenden und auf SOA basierenden Systemen. Eine Expertenbefragung weist in diesem Kontext Zeiteinsparungen von 20 bis 50 Prozent im Vergleich zu monolithischen Systemen aus. Die Rechnung ist in diesem Fall einfach. Eine Änderung kommt nur noch halb so teuer zu stehen.

Die Kosteneffekte der Prozessoptimierung lassen sich anhand gängiger Prozesskostenrechnungen messen. Sie können beispielsweise anhand von Prozesskennzahlen wie der Durchlaufzeit oder des Personalbedarfss genau berechnet werden. Noch interessanter ist die Option, die Ergebnisse hinterher zu verifizieren. Noch einfacher zu belegen ist die Tatsache, dass SOA eine Automatisierung von Prozessen erlaubt. So lassen sich beispielsweise im Versicherungsgeschäft die Kosten der Schadensbearbeitung drastisch senken.

Modelle für Kosten kaum anwendbar

Für die Kostenberechung einer SOA existieren mehrere Rechnungsmodelle. Anhand von zwei Beispielen lässt sich illustrieren, wie sie funktionieren können. Eines der bekanntesten Modelle stammt von David Linthicum und umfasst eine einfache Formel zur Berechnung von SOA-Projekten (siehe: Die SOA-Formel von Linthicum). Der Vorteil dieser Berechnung ist die einfache Methode. Von Nachteil ist, dass die Faktoren für die Berechnung der Komplexität aus bestehenden Erhebungen älterer Projekte abgeleitet werden müssen. Dies ist aufgrund der oftmals fehlenden Zahlenbasis keine einfache Aufgabe und kann nur von Experten geleistet werden.

Ein wesentlich komplexeres Modell stammt von der Universität Eindhoven und berechnet den Preis eines Services in einer SOA. Das Modell basiert auf einem Supply-Chain-Paradigma, und versucht über den maximal akzeptierbaren Preis, zu dem ein Lieferant einen Service liefern kann, eine Formel herzuleiten. Die Berechnung für eine Reihe von Services, die in einem bestimmten Workflow ablaufen, ist noch weitaus komplizierter und in der unternehmerischen Praxis wohl kaum berechenbar.

Einfachere Rechnung 1: Lebensverlängerung durch Modernisierung

Die Modernisierung und damit die Weiterverwendung bestehender Systeme als integrale Komponente ist eine Eigenschaft von SOA, die sie von allen anderen Standardarchitekturen unterscheidet. Das Konzept geht davon aus, dass bereits Anwendungen existieren und diese in Form von Services in einer SOA eingesetzt werden können. Nun sind Services jedoch gut in sich abgeschlossene und weitgehend unabhängige Komponenten, die über definierte und standardisierte Schnittstellen verfügen. Dies ist bei bestehenden Systemen nicht immer der Fall. Also ist eine Reihe von Erweiterungen notwendig, um aus einem bestehenden System einen einsatzfähigen Dienst zu machen. Zudem sind in vorhandenen älteren Systemen der Ablauf und die Funktionen nicht so getrennt wie in einer auf SOA basierenden Lösung.

Trotzdem gibt es zwei schlagende Argumente für die Weiterverwendung dieser Systeme. Erstens gibt es sie bereits, die Investitionen sind also bereits getätigt; in jedem Fall ist es wesentlich billiger, eine Komponente weiter zu verwenden, als sie neu zu erstellen. Zweitens haben sie sich im Einsatz bewährt, sonst wären diese Anwendungen nicht mehr vorhanden. Und was sich bewährt hat, eignet sich mit größter Wahrscheinlichkeit zur weiteren Nutzung. SOA verlängert den Lebenszyklus eines Informationssystems. Dies bedeutet, dass die Investition wesentlich besser amortisiert werden kann, als wenn das System abgelöst werden muss. Dieser Kostenvorteil verstärkt sich noch, wenn weite Teile des bestehenden Systems als unternehmensweit zugängliche Services zur Verfügung gestellt werden und weitere Anwendungen darauf zugreifen können.

Einfachere Rechnung 2: Schnittstellen mit SOA

Ohne Schnittstellen gäbe es keine betrieblichen Informationssysteme. Der gängige Schnittstellenbegriff umfasst sowohl das User Interface als auch die Schnittstellen zum Betriebssystem, zur Datenbank und zu anderen Systemen. Diejenigen Schnittstellen, die uns Kopfzerbrechen bereiten, sind solche zum Datenaustausch zwischen verschiedenen Systemen. Die Schwierigkeit besteht darin, dass bestehende Systeme mit neuen verbunden werden müssen. In vielen Fällen sind die Beschreibungen der Daten, der Formate und der technischen Möglichkeiten bestehender und manchmal auch neuer Systeme unvollständig oder falsch. Hinzu kommt, dass die Daten in verschiedenen Systemen unterschiedlich granular verwendet werden. Die Schnittstellen sind ein zentraler Kostenfaktor in der Softwareentwicklung und im Betrieb.

Schnittstellen basierend auf SOA zu bauen, ist ein neuer Ansatz, der sich in der Praxis bewährt hat. Die Strukturierung von Schnittstellen durch Service Groups, die Bereitstellung spezieller Konversions- und Transformations-Dienste und die Steuerung von Abläufen mittels BPEL (Business Process Execution Language) erlauben flexible und rationelle Ansätze beim Schnittstellenbau. Sie sind jeder anderen Realisierung bezüglich Änderungsfreundlichkeit und Betriebskosten weit überlegen. Laut einer Analyse von Forrester Research beansprucht die Entwicklung von Schnittstellen 35 bis 40 Prozent des Gesamtaufwands der Programmierung; bei Punkt-zu-Punkt-Integrationen sogar 70 Prozent. Mit einer Schnittstellenplattform, sprich einer Datenintegrationspattform auf Unternehmensebene, werden diese Kosten drastisch reduziert. Zusätzlich lassen sich mit der expliziten Modellierung aller einzelnen Funktionen einer Schnittstelle die Fehlerkosten senken. Unternehmen können also mit einer Ersparnis von rund 20 Prozent gegenüber den üblichen Projektkosten rechnen. Allerdings sind solche Plattform nicht billig. Die Investition lohnt sich nur dann, wenn eine bestimmte Mindestanzahl von Systemen mit einander verbunden werden soll.

Fazit

Obwohl SOA wie jede andere Architektur per se noch keinen kalkulierbaren Kostenvorteil mit sich bringt, ergeben sich bereits aus den grundlegenden Vorteilen mögliche Berechnungen. Alleine schon der wichtigste Nutzen einer SOA - die Agilität durch die Trennung der Logik in dynamische und statische Bereiche - ergibt Skaleneffekte, die sich direkt umrechnen lassen. So können Unternehmen Produkte schneller auf den Markt bringen und der Änderungsaufwand für ein bestehendes System sinkt um bis zu 50 Prozent. Ein anderer Faktor - die Möglichkeit der Prozessoptimierung - lässt sich berechnen, wenn die gängigen Kennzahlen der Prozesskostenrechnung wie beispielsweise Durchlaufzeiten oder Personalbedarf einbezogen werden. In konkreten Projekten wie der Modernisierung von bestehenden Systemen, dem systematisierten Bau von Schnittstellen oder der Konsolidierung bestehender Anwendungen, sind die Kostenvorteile offensichtlich. Hinzu kommt, dass in naher Zukunft sämtliche Hersteller von Standardsoftware ihre Produkte als Sammlungen von Services auf den Markt bringen werden. Damit dürften die Einführungskosten für solche Systeme deutlich sinken. (wh)

Mehr zum Thema SOA und Business-Process-Management im CW-Experten-Blog SOA meets BPM.

Die SOA Formel von Linthicum

Der US-Analyst David Linthicum hat eine relativ einfache Formel zum Berechnen der SOA-Kosten entwickelt:

Kosten einer SOA = (Kosten der Datenkomplexität + Kosten der Servicekomplexität + Kosten der Prozesskomplexität + Kosten der eingesetzten Technologie)

Die Kosten der Datenkomplexität errechnen sich aus der Anzahl der Datenelemente multipliziert mit dem Speicherkomplexitätsfaktor (0,3 für relationale Datenhaltung, 0,6 für objektorientierte und 0,8 für ISAM) multipliziert mit den Kosten für den Arbeitsaufwand. Die anderen Faktoren werden entsprechend eingesetzt.

Die wichtigsten Grundlagen zur Berechnung der Kosten sind:

Bilanzierung des SOA-Nutzens?

Viviane Dehos von der FH Köln zeigt in einer Diplomarbeit auf, wie gemäss den Rechnungslegungsvorschriften IAS (International Accounting Standard) und dem neuen BilMoG (Bilanzmodernisierungsgesetzt - seit 21.5.2008 in Kraft) Informationssysteme als Strukturwert (Strukturkapital respektive Strukturvermögen) bilanziert werden können. Unter Strukturkapital wird derjenige Teil der immateriellen Vermögenswerte einer Unternehmung verstanden, der zu einem flüssigen Arbeitsprozess beiträgt. Also beispielsweise Strukturen, Prozesse und Regelsysteme, über die eine Organisation verfügt, wenn die Mitarbeiter nach Hause gehen. Und damit auch Informationssysteme, die im eigenen Hause entwickelt worden sind. Der Nutzen von SOA kann somit als Strukturwert einer selbstentwickelten Software in der Buchhaltung aktiviert werden. Dies geschieht über eine Trennung der üblichen Projektschritte (Analyse, Design, Entwicklung, Test, etc.) in zwei Bereiche: die Forschungs- und die Entwicklungsphase.

Während eine Aktivierung der Forschungsphase (Planung und Indeenfindung) gemäss Rechnungslegungsvorschriften verboten ist, kann die Entwicklungsphase (Entwurf, Fertigung und Testen) unter bestimmten Bedingungen aktiviert werden. Ein weiterer Schritt auf dem Weg zum konkreten Nachweis des Wertbeitrags der Informationstechnologie ist somit möglich.