Business Technology 06/11

Warum wir trotz allem einen Business Case erstellen können: Der Business Case für Architektur

Autor:

In diesem Artikel werde ich versuchen, einen möglichen Business Case für Architektur darzustellen. Jetzt könnten Sie fragen, ob das überhaupt eine sinnvolle Idee ist. Gerade in der IT sind Business Cases an sich schon ein eher umstrittenes Instrument, um Investitionsentscheidungen zu begründen und dann auch noch für ein so schwer bewertbares Thema wie Architektur? Das muss doch schiefgehen!

Diese Zweifel kann ich durchaus nachvollziehen und teile sie zu einem großen Teil auch. Business Cases treffen Annahmen über Erträge und Kosten, die in der Zukunft liegen, und diese Annahmen sind häufig so stabil wie die Klötzchentürme kleiner Kinder, kurz bevor sie in sich zusammenfallen. Erschwerend kommt hinzu, dass Architektur sich häufig nur indirekt und zeitlich verzögert auf die Kosten und Erträge auswirkt. Gerade eine schlechte Architektur führt in der Regel zu hohen Folgekosten, die nur sehr schwer gemessen werden können, weil meistens der Vergleich fehlt. Trotz dieser absolut berechtigten Probleme und Beschränkungen ist es dennoch so, dass wir von Zeit zu Zeit wahrscheinlich nicht umhin kommen, das Thema Architektur mit Zahlen zu untermauern. Genau aus diesem Grund versuche ich hier, einen möglichen Ansatz zu beschreiben.

Wartungskosten Software

Die Grenzen von Zahlen

Business Cases beschränken sich oftmals rein auf Zahlen, genauer Geld. In der einfachsten Variante werden die erwarteten Kosten ins Verhältnis zu den erwarteten Erträgen gesetzt. Etwas differenzierter sind ROI-Analysen, die zu bestimmen versuchen, nach welchem Zeitraum die Erträge die Kosten überschreiten. Dennoch betrachtet auch diese Variante letztlich nur ausgegebenes und eingenommenes Geld. Dieser Betrachtungsweise liegt die Annahme zugrunde, dass sich alle Einflussgrößen auf Kosten oder Erträge herunterbrechen lassen. Diese Annahme ist nicht ganz falsch. Man kann sich tatsächlich für fast jede Einflussgröße eine monetäre Quantifizierung überlegen. Trotzdem ist es in vielen Fällen so, dass eine Umrechnung einer Einflussgröße in Geld so viele Annahmen trifft, dass der Nutzen der monetären Darstellung sehr fragwürdig ist. So könnte z. B. im Zusammenhang mit Architektur die Entwicklerzufriedenheit eine relevante Einflussgröße sein. In ihrer ursprünglichen Form kann man diese problemlos auf einer bedarfsgerecht unterteilten Skala von „sehr unzufrieden“ bis „sehr zufrieden“ darstellen, die für alle Beteiligten intuitiv erfassbar ist.

Versucht man aber, die Entwicklerzufriedenheit in Geld umzurechnen, muss man Aspekte wie erwartete Kündigungen, Einarbeitung neuer Mitarbeiter, höhere Fehlerquoten oder reduzierte Produktivität in Geld umrechnen. Dafür muss man Faktoren, Summanden und Wahrscheinlichkeiten festlegen, die man in der Regel „raten“ muss, weil man keinerlei Datenmaterial zur Verfügung hat, anhand dessen man diese Werte festlegen kann. Die Aussagekraft der resultierenden Zahl wird also in der Regel eher fragwürdig sein und intuitiver ist die Größe auch nicht. Aus diesen Gründen empfehle ich, nicht nur eine monetäre Bewertung für eine Investitionsentscheidung durchzuführen, sondern diese immer um eine nicht monetäre Bewertung sowie eine Risikoanalyse zu ergänzen und die verschiedenen Einflussgrößen in geeigneter Weise den drei Bereichen zuzuordnen. Und da man für die nicht monetären Größen immer ein weitestgehend normiertes Schema (z. B. Zahlen von 1 bis 10) finden kann, leidet auch die intuitive Erfassbarkeit der Gesamtbewertung nicht.

Dennoch werde ich mich in diesem Artikel nur auf den Versuch beschränken, den Wert von Architektur als monetären Wert darzustellen. Die anderen nicht monetären Größen können Sie entsprechend ergänzend, wenn Sie die Gelegenheit dazu haben sollten.

Änderungskosten Software

Ziele von Architektur

Wie komme ich nun aber zu einer monetären Bewertung von Architektur? Nach meiner Erfahrung ist es am besten, in solchen Situationen nach dem Zweck bzw. den Zielen der zu bewertenden Sache – hier Architektur – zu fragen, da sie helfen, die relevanten Nutzentreiber zu identifizieren. Es gibt jede Menge Definitionen zum Thema Architektur, z. B. [1], doch die meisten beschäftigen sich nur mit dem Was, sprich den Aufgaben von Architektur. Das Warum, die Ziele von Architektur, werden in der Regel nicht adressiert.

Da ich im Laufe meines Berufslebens häufiger einmal gefragt worden bin, wofür Architektur denn überhaupt gut sei und mir die landläufigen Definitionen an der Stelle nicht weitergeholfen haben, habe ich mir zu dem Thema einige Gedanken gemacht. Meine Überlegungen brachten mich zu den folgenden zwei primären Zielen:

  • Maximierung der Zufriedenheit aller beteiligten Stakeholder über den Lebenszyklus des Systems
  • Minimierung aller bezogenen Kosten über den Lebenszyklus des Systems

Maximierung von Zufriedenheit und Minimierung von Kosten sind relativ häufig anzutreffende Ziele, also erst einmal nichts Besonderes. Allerdings gibt es für Architektur ein paar Besonderheiten zu berücksichtigen:

  • Es geht nicht nur um die Zufriedenheit einer Stakeholder- Gruppe, sondern um alle beteiligten Stakeholder-Gruppen: Es geht nicht nur um die Entwicklerzufriedenheit (auch wenn sie ein wichtiger Faktor ist), sondern auch um die Zufriedenheit der Anwender, des Fachbereichs, des Betriebs, des Projektsponsors, des Managements usw. Es soll nicht versucht werden, die Zufriedenheit einer Stakeholder- Gruppe zu Lasten der anderen Gruppen zu maximieren, sondern ein Zufriedenheitsoptimum über alle beteiligten Gruppen hinweg zu erreichen.
  • Analog geht es nicht um die Minimierung der Kosten für eine Kostenart, sondern um alle betroffenen Kostenarten. So geht es nicht nur – wie so häufig gefordert – um die Minimierung von Projekt- bzw. Entwicklungskosten, sondern auch um Infrastrukturkosten, Betriebskosten, Lizenzkosten, Wartungskosten, Bedienungskosten, Änderungskosten usw. Auch hier ist ein Optimum über die verschiedenen Kostenarten anzustreben, was häufig sehr schwerfällt, weil einige der Kosten erst verzögert zum Tragen kommen und so die Versuchung sehr hoch ist, für den Augenblick zu optimieren.
  • In der anderen Dimension geht es nicht darum, die Zufriedenheit oder die Kosten für einen Zeitpunkt zu optimieren, sondern über den gesamten Lebenszyklus des Systems. Meistens enden alle Überlegungen im „Changethe Business“-Umfeld mit dem Ende des jeweiligen Projekts. Natürlich ist der Erfolg eines Projekts unter Kosten- und Zufriedenheitsaspekten wichtig, aber was hilft ein sehr günstiges Projekt, wenn das entstandene System unter der Oberfläche so schlecht ist, dass die Betriebsstabilität schlecht ist, die Software viele Fehler hat und Änderungen ungemein aufwändig sind? Hier ist es die Aufgabe der Architektur, die verschiedenen Interessen über den Lebenszyklus des bezogenen Systems zu optimieren.

Schwierigkeit der Wertbestimmung

Gerade der letzte Punkt macht die Bewertung des Nutzens von Architektur so schwierig. Architektur ist in vielen Aspekten eher auf die Zukunft ausgerichtet, d. h. der Nutzen einer jetzt getroffenen Architekturentscheidung zeigt sich häufig erst deutlich später. So ist z. B. eine sehr wichtige Aufgabe von Architektur, das System offen für Änderungen zu halten. Änderungen finden aber in der Zukunft statt, d. h. ich kann zum Zeitpunkt des Treffens einer Architekturentscheidung den Nutzen der Entscheidung noch gar nicht bestimmen. Umgekehrt bedeutet das, wenn ich nur den aktuellen Zeitpunkt bzw. einen kurzen Zeitraum wie z. B. ein Projekt zur Bewertung des Nutzens von Architektur heranziehe, dann werde ich viele Nutzenaspekte nicht erfassen bzw. viele Teile der Architekturarbeit als nutzlos erachten.

Nutzenpotenziale von Architektur

Zur Unterstützung dieser Aussage ist es sinnvoll, sich einmal die Ergebnisse der Untersuchungen von Koskinen (Abb. 1, [2]) anzuschauen. Darin erkennt man auf einen Blick, dass die Wartungs- und Weiterentwicklungskosten eines Systems um ein Vielfaches höher sind als die initialen Entwicklungskosten. Der große Hebel für Kosteneinsparungen liegt also in der Wartung und Weiterentwicklung eines Systems. Es macht also durchaus Sinn, sich Gedanken über die zukunftsbezogene Änderbarkeit eines Systems zu machen, da sich damit große Kosteneinsparpotenziale verbinden.

Hierzu lässt sich noch eine Untersuchung des Software Technology Support Center des Department of Defense heranziehen [3]. In dieser Untersuchung hat man zwei gleichstarke Teams gebildet und ihnen die gleiche Aufgabenstellung gegeben, nämlich eine Reihe von Änderungen und Erweiterungen in einem bestehenden System umzusetzen. Der Unterschied lag in der Software, die die Teams als Grundlage für ihre Arbeit erhalten hatten. Das erste Team hat die Software in ihrem ursprünglich, über die Jahre ziemlich degenerierten und schlecht strukturierten Zustand bekommen. Für das zweite Team wurde die Software wieder in Form gebracht, d. h. man hat die Software ohne Veränderung der Funktionalität einem Redesign unterzogen, sodass die Software wieder über ein sauberes Design verfügte.

Die Ergebnisse der Untersuchung waren recht beeindruckend: Das zweite Team hat die Aufgabe in der halben Zeit und mit der Hälfte der Aufwände und Kosten erledigt. Noch beeindruckender waren allerdings die Folgeeffekte: Die Lösung des zweiten Teams war um Längen stabiler. Sie hatte nur etwa zehn Prozent der Fehler, die in der Lösung des ersten Teams gefunden worden sind (Abb. 2).

Denkt man einen Augenblick über diese Ergebnisse nach, sind sie letztlich nicht sonderlich überraschend: Das menschliche Gehirn ist sehr beschränkt bzgl. der Menge an Informationen, die es zu einem Zeitpunkt überblicken kann. Selbst ein relativ einfaches IT-System besteht aus einem Vielfachen dieser Informationen. Um in dieser Menge an Informationen, Fakten und Beziehungen nicht den Überblick zu verlieren, benötigen wir Strukturen, in denen die Informationen organisiert sind. Je besser die Strukturen zu unserer jeweiligen Aufgabenstellung passen, desto leichter fällt uns die Umsetzung der Aufgabe und desto weniger Fehler machen wir typischerweise. Genau das ist eine der Kernaufgaben von Architektur und Design: die Software so zu strukturieren, dass wir darin nicht den Überblick verlieren.

Zusammenfassend können wir folgern, dass eine gute Architektur durchaus monetäre Vorteile für ein laufendes Entwicklungsprojekt bringen kann, die eigentlichen Einsparpotenziale aber typischerweise erst nach Abschluss des Projekts zum Tragen kommen.

Komplexitätsfolgekosten

Ein naiver Ansatz für einen Business Case

Dieses Wissen möchte ich jetzt nutzen, um zu versuchen, einen Business Case für Architektur zu erstellen. Dabei beginne ich mit der Auswahl des Business-Case-Modells: Am häufigsten werden einfache Kosten-Ertrag-Vergleiche oder ROI-Berechnungen als Business-Case-Modelle verwendet. Es gibt zwar aufwändigere Modelle, aber aufgrund der hohen Schätzunsicherheiten in den verwendeten Parametern hat es meistens keinen Sinn, ein komplizierteres Modell zu verwenden. Entsprechend werde ich hier mit dem einfachen Kosten-Ertrag-Vergleich arbeiten. Eine Übertragung der Ideen auf andere Modelle ist aber problemlos möglich.

Wir gehen zur weiteren Vereinfachung erst einmal von einem konstanten Ertrag aus, d. h. dass unsere Architektur den Ertrag nicht beeinflusst. In der Praxis beeinflusst eine gute Architektur die Ertragsseite zwar durchaus positiv, aber dazu später mehr.

Auf der Ertragsseite steht damit erst einmal nur, was die Umsetzung der Anforderungen nach Schätzung des Fachbereichs oder des Managements in die Kassen des Unternehmens spülen soll. Die Zahlen auf dieser Seite des Business Cases basieren häufig auf recht spekulativen Annahmen, aber das soll uns an der Stelle nicht interessieren.

In der naiven Variante werden jetzt auf der Kostenseite nur die Erstellungskosten für die Software kalkuliert, d. h. die Konzeptionskosten, die Umsetzungskosten sowie weitere Kosten wie Lizenzen, Inbetriebnahmekosten etc. In dieser Variante habe ich wie bereits zuvor beschrieben nur sehr begrenzte Möglichkeiten, den Nutzen von Architekturarbeit zu rechtfertigen. Da die Einsparpotenziale aus gut strukturierter Software innerhalb eines Projekts relativ begrenzt sind, laufe ich schnell Gefahr, dass die Konzeptions- und Umsetzungskosten für die Architektur meine daraus resultierenden Einsparungen auffressen.

Einbeziehen der Komplexitätsfolgekosten

Aus den zuvor beschriebenen Untersuchungen wissen wir aber, dass sich der eigentliche Nutzen einer guten Architektur erst verzögert entfaltet und lange nachwirkt – analog zum Schaden durch eine schlechte Architektur. Wir müssen also die Zeit nach dem Erstellungsprojekt mit in die Bewertung der Kosten einbeziehen. Wie kann man das machen?

Eine Möglichkeit ist, die Gesamtkosten für ein System als Summe der Kosten für alle Features auszudrücken, die jemals für das System entwickelt worden sind. Die Kosten für ein Feature setzen sich nun aus den Erstellungskosten für das Feature (siehe oben) sowie seinen Folgekosten zusammen. Die Gesamtkosten für ein einzelnes Projekt kann man dann berechnen, indem man die Kosten für alle Features addiert, die in dem Projekt umgesetzt werden.

Was aber sind Folgekosten? Folgekosten sind die Kosten, die nach Abschluss des Projekts entstehen, in dem das zugehörige Feature umgesetzt worden ist. Grob gesagt sind das die kumulierten Betriebskosten für das Feature mit den eventuell anfallenden Komplexitätsfolgekosten.

Komplexitätsfolgekosten entstehen immer dann, wenn ein Feature nicht passend zur gewählten Architektur umgesetzt wird. Man kennt diese Verstöße unter den Namen wie „Workarounds“, „Quickshots“, „Quickfixes“ etc. Das Problem ist, dass ein Umgehen der vorgesehenen Struktur die Komplexität des Systems erhöht, da es einen Sonderfall mehr gibt, den man bei einer zukünftigen Änderung berücksichtigen muss.

Das geht noch ganz gut, wenn die Anzahl dieser Verstöße recht gering ist. Ab einem nicht allzu hohen Schwellwert steigen die Komplexitätsfolgekosten aber überproportional an, da ein Entwickler die ganzen Sonderfälle nicht mehr überblicken kann. Als Konsequenz sinkt die Entwicklungsgeschwindigkeit, die Fehlerquote steigt, die Betriebssicherheit sinkt etc. Zusätzlich steigt die Wahrscheinlichkeit weiterer Verstöße, weil vieleEntwickler die Sonderfälle nicht mehr überblicken und deshalb lieber einen weiteren lokalen Sonderfall einbauen, um ihr Problem irgendwie zu lösen. Das Problem der Architekturverstöße tendiert also dazu, sich ab einem bestimmten Schwellwert selbst zu verschärfen.

Warum kommt es überhaupt zu diesen Verstößen? Das geschieht häufig, weil die Verstöße kurzfristig betrachtet oftmals billiger und häufig auch einfacher sind. Man schafft eine auf die lokale Aufgabenstellung bezogene einfache und kostengünstige Lösung, die schneller und günstiger umsetzbar ist als wenn man sie architekturkonform umsetzt.

Jetzt kann man einwenden, dass die Architektur schlecht sein muss, wenn es günstiger ist, sie zu umgehen. Das ist allerdings zu kurz gedacht, weil es die Aufgabe von Architektur ist, alle Kosten über den gesamten Lebenszyklus in Summe zu minimieren und nicht, die billigste Lösung für jede einzelne Aufgabenstellung anzubieten. Trotzdem sorgen Zeit- und Kostendruck in Projekten häufig dafür, dass man der Verlockung der „einfachen“ Lösung erliegt, um kurzfristig dem Druck zu entgehen. Doch die Rechnung dafür zahlt man später mit Zins und Zinseszins in Form der Komplexitätsfolgekosten.

Möglichkeiten und Grenzen einer Berechnungsformel

Wie kann man diese Komplexitätsfolgekosten berechnen? Tatsächlich ist das äußerst schwierig. Sie hängen zum einen von der Anzahl der bereits bestehenden Architekturverstöße und zum anderen von den für die Restlebensdauer des Systems noch benötigten Änderungen ab. Je mehr Architekturverstöße bereits bestehen, desto stärker wirkt sich ein weiterer Verstoß aus, und je weniger zukünftige Änderungen noch für das System umzusetzen sind, desto weniger Situationen gibt es, in denen die Verstöße zum Tragen kommen.

Es gibt jetzt viele Möglichkeiten, dies in eine Formel zu gießen. Ich habe für einen JAX-Vortrag einmal eine Formel entwickelt (Abb. 3, [4]), verzichte aber darauf, sie hier weiter zu erläutern, weil sie genauso gut oder schlecht ist wie jede andere Formel. Man sollte bei der Erstellung primär darauf achten, dass die Kosten ab einem gewissen Schwellwert an Architekturverstößen stark überproportional ansteigen, um den Effekt der Komplexitätsmultiplikation und den daraus resultierenden Überblicksverlust eines Entwicklers zu dokumentieren.

Natürlich ist eine solche Formel immer angreifbar, egal wie Sie sie formulieren. Zum einen können alle Koeffizienten mangels statistisch belegbarer Datenbasis in Frage gestellt werden und zum anderen kann die Formel an sich in Frage gestellt werden. An der Stelle kann man versuchen, Gleiches mit Gleichem zu vergelten und die Formeln und Koeffizienten auf der Ertragsseite in Frage zu stellen, doch das wird in der Regel keinen großen Nutzen bringen.

Wichtig ist meines Erachtens auch nicht die exakte Formel, da man die genaue Form und die benötigten Koeffizienten in der Regel erst durch langfristiges empirisches Annähern bestimmen kann, sondern das Bewusstsein, dass es Komplexitätsfolgekosten gibt und dass sie einen essenziellen Kostenfaktor bei der Bewertung von Architektur darstellen.

Deshalb sollten Sie auch nicht so sehr an der Formel an sich feilen, sondern viel mehr an der Begründung für die Formel. Untersuchungen wie die des Department of Defense sind da sehr hilfreich, und die Koeffizienten sollte man ruhig defensiv wählen, sodass es allen Beteiligten leicht fällt, ihnen zuzustimmen. Wenn Sie es geschafft haben, einer Business-Case-fixierten Runde die Existenz und die Multiplikationseffekte von Komplexitätsfolgekosten begreiflich zu machen, dann haben Sie Ihr Ziel praktisch schon erreicht. Die exakten Zahlen sind dann nicht mehr so wichtig.

Weitere Ansatzpunkte

Das war ein einfacher Ansatz zur monetären Bewertung des Nutzens von Architektur. Man kann ihn jedoch deutlich weiter ausbauen. So haben wir die Ertragsseite bislang noch gar nicht betrachtet. Amazon hat z. B. in einer Studie herausgefunden, dass eine durchschnittlich um 100 Millisekunden langsamere Antwortzeit signifikante Umsatzeinbußen zur Folge habe. Anders ausgedrückt können sich schlechte Architekturentscheidungen auch deutlich auf die Ertragsseite eines Business Cases auswirken.

Noch deutlicher wird das, wenn eine fachliche Änderung, z. B. die Unterstützung eines innovativen Produkts aufgrund einer schlechten Architektur so lange dauert, dass das Unternehmen das „Window of Opportunity“ verpasst, d. h. dass es zu spät mit dem Produkt in den Markt eintritt und so massive Umsatz- und Gewinneinbußen erleidet.

Ebenfalls negativ wirkt es sich auf die Ertragsseite aus, wenn das System aufgrund einer schlechten Architektur fehleranfällig geworden ist und häufig im Produktivbetrieb ausfällt usw. Die Liste lässt sich noch deutlich verlängern und man kann daraus noch viele weitere Ansatzpunkte zur Erstellung eines Business Cases für Architektur ableiten.

Zusammenfassung

Business Cases sind ein häufig verwendetes Instrument zur Überprüfung einer anstehenden Investitionsentscheidung. Auch wenn die Aussagekraft eines Business Cases aufgrund seiner ausschließlichen Fokussierung auf eine monetäre Bewertung und der damit verbundenen Zwangsquantifizierung aller qualitativen und Risikowerte durchaus fragwürdig ist, muss man sich damit arrangieren, dass dieses Instrument häufig zum Einsatz kommt und in seiner Grundidee auch durchaus sinnvoll ist.

Den monetären Wert einer Architektur zu bestimmen, ist besonders schwer, weil viele Architekturentscheidungen erst weit in der Zukunft ihren Wert zeigen, während die Kosten sofort entstehen. Um hier überhaupt einen brauchbaren Business Case aufmachen zu können, muss man die Folgekosten für Architekturentscheidungen jenseits der Grenzen eines einzelnen Projekts mit in die Betrachtung einbeziehen. Insbesondere die Komplexitätsfolgekosten, die durch das Verletzen einer gegebenen Architektur entstehen, sind ein wichtiger Faktor für die Bestimmung des Werts einer Architektur.

Trotzdem bleibt es schwierig, eine geschlossene und allgemein akzeptierte Formel für den Wert einer Architektur zu bilden. Das ist aber auch nicht so wichtig, wenn es gelingt, in einem Business-Case-fixierten Umfeld die Existenz und die Auswirkungen von Komplexitätsfolgekosten verständlich zu machen. In Summe haben wir dieses Thema nur gestreift. Wir haben einen willkürlichen Aspekt der Architektur herausgepickt und darauf eine Wertbestimmung aufgebaut, die helfen kann, die Notwendigkeit einer integren Architektur zu verdeutlichen. Natürlich gibt es noch sehr vieleandere Ansatzpunkte, um den Wert einer Architektur zu bestimmen, was aber den Rahmen dieses Artikels bei Weitem gesprengt hätte. Wenn Ihnen die Ideen in diesem Artikel aber helfen sollten, die nächste Diskussion darüber, ob man denn das dringende Feature nicht schnell an der Architektur vorbei implementieren sollte, erfolgreich zu meistern, dann würde mich das freuen. Ich wünsche Ihnen auf jeden Fall viel Erfolg in den sicherlich noch häufigen Diskussionen zu dem Thema sowie beim Finden eigener Modelle zur Wertbestimmung.

 

Links & Literatur

[1] Software Engineering Institute, Carnegie Mellon: Defining Software Architecture: http://www.sei.cmu.edu/architecture/ start/definitions.cfm

[2] Koskinen, Jussi: Software Maintenance Cost, 2003: http://www.cs.jyu.fi/~koskinen/smcosts.htm

[3] Guidelines for Successful Acquisition and Management of Software Intensive Systems, Version 3.0 May 2000, Appendix F, Kapitel F1.3.2, Software Technology Support Center: http://www.stsc.hill.af.mil/resources/tech_docs/gsam3.html

[4] Friedrichsen, Uwe: Der Business Case für Architektur, JAX 2010: http://it-republik.de/konferenzen/jax2010/ session/?tid=1540#session-13078

Vollständiger Artikel