Mythos 3: Kostenersparnis
Das "Standardverkaufsargument" diverser Beratungsunternehmen und Werkzeughersteller für den Einsatz einer SOA lautet: Eine SOA ermöglicht durch den Einsatz von austauschbaren Services eine massive Verbesserung des Return on Investment (RoI) bei gleichzeitig sinkenden Entwicklungskosten. Vorstände, speziell Finanzvorstände, hören so etwas gerne, schließlich bekommt man anscheinend mehr Wert für weniger Einsatz. Dieses Argument scheint durch die permanente Wiederholung in Gesprächen, Fachvorträgen und Artikeln diverser Zeitschriften durchaus glaubwürdig zu sein.
Aber spart eine SOA wirklich Geld? Und wenn ja, gegenüber was wird denn eingespart?
Kernaussagen
Die meisten Softwarekosten entstehen nicht in den Services.
Eine Wiederverwendung ist nicht a priori sichergestellt.
Kosten werden stark durch die permanenten Veränderungen der Domäne beeinflusst.
ESBs und Repositories stellen eine hohe Investition dar.
Kostenreduktion ist ein beliebtes Thema eines jeden Verkäufers, der eine neue Technik an ein Unternehmen liefern möchte. Einsparungen werden auch immer wieder gerne zitiert, um die Unternehmensleitung von Investitionen in Software oder Projekte zu überzeugen. Um die Kostenfrage wirklich zu klären, gilt es zu prüfen, was in den Softwareprojekten wirklich Kosten produziert. Typische Kostentreiber sind Entwicklungskosten, Wartungs- und Weiterentwicklungskosten sowie Betriebskosten. Wie beeinflusst eine SOA diese Faktoren?
Die Entwicklungskosten sind primär durch die Personalkosten bestimmt. In aller Regel machen eventuelle Hardware- und Lizenzkosten nur marginale Teile eines Softwareprojekts aus. Softwarevorhaben sind meist dadurch charakterisiert, dass sie Personalkosten verursachen. Die größten Kostenblöcke sind die Projektdauer und die Benutzeroberflächen. Letztere können bis zu 70 Prozent der Gesamtkosten (inklusive Test und Spezifikation) ausmachen. Die Ursache für diesen großen Anteil liegt in der Komplexität heutiger ereignisgetriebener Oberflächen, die auf diverse Kombinationen reagieren müssen. Beschäftigt sich SOA damit? Nein! In einer SOA erscheint die Oberfläche auf magische Weise in Form von Präsentations-Services oder Portalen, ohne dass das Komplexitätsproblem oder die Oberflächengestaltung angegangen wird. Nur, welche Ersparnis ist denn zu erwarten wenn bis zu 70 Prozent der Kosten ignoriert werden?
Neben der Oberfläche bietet eine SOA keinerlei Kostenvorteile gegenüber einer modul- oder komponentenbasierten Entwicklung. Auch diese Konzepte setzen ja auf Zerlegung und Modularisierung; die langjährige Erfahrung hat gezeigt, dass eine komponentenbasierte Entwicklung nicht billiger ist als andere Arten. Die oft zitierte Argumentationskette, SOA bedeute Wiederverwendung, wodurch sich Kosten senken ließen, geht davon aus, dass Wiederverwendung durch SOA tastsächlich zum Tragen kommt. Nur, wie wir im sechsten Teil dieses Artikels sehen werden, findet Wiederverwendung nicht wirklich statt.
Der andere Kostentreiber in der Entwicklung ist die permanente Veränderung der fachlichen Spezifikationen. Wenn sich nur drei Prozent der Spezifikationen pro Monat verändern, dann hat sich nach zwei Jahren praktisch alles verändert. Diese wiederholten Änderungen schlagen sich in der Dauer und damit direkt in den Kosten nieder. Ändert eine SOA etwas daran? Nein!
Für den Kostentreiber Wartung ist der Wert einer SOA eher zweifelhaft. Ein Großteil des Wartungsaufwands liegt im Bereich der Fehlerbehebung oder deren Auffindung. In einer verteilten Umgebung Fehler zu finden, ist meist sehr viel schwerer als in einem Monolithen. Folglich dürften die Wartungskosten mit einer SOA sogar zunehmen.
Wird der Betrieb einer Software durch SOA billiger? Im Gegenteil: eine SOA wird auf Dauer Kosten erzeugen, denn sie braucht beispielsweise einen Enterprise Service Bus (ESB). Und dieser bedeutet eine massive Investition, wenn man die Erfahrungen aus dem EAI-Umfeld extrapoliert, ganz zu schweigen von den Kosten für das aufzubauende Wissen und die Mitarbeiterqualifikation. Außerdem gilt für den Betrieb das gleiche wie für die Wartung: Je verteilter und komplexer ein System ist, desto teurer wird sein Unterhalt.
Auch die Zahl der möglichen Fehlerquellen steigt durch eine SOA an, schließlich bildet ein ESB einen Single Point of Failure. Diese zusätzlichen Fehlerquellen spiegeln sich in einem erhöhten Betriebsrisiko und damit in einer niedrigeren Verfügbarkeit wieder.
Fazit: SOA reduziert keine Entwicklungs- und Betriebskosten! Im Gegenteil: eine SOA produziert vermehrt Kosten, selbst wenn man die hohen Aufwändungen für das Know-how nicht mit berücksichtigt.