www.bt-magazin.de 4.2011 Heft 7

expertenwissen für it-architekten, projektleiter und Berater

Detlev Klage:

„Das Verständnis für

Architektur zählt.“

BUSINESS VALUE

Wertschöpfung durch IT?

Kostentransparenz im EAM-Modell

Der ROI der Cloud

Wertschöpfung durch IT?

Sonderdruck fürwww.codecentric.de

www.bt-magazin.de2 bt | 4.2011

Business Care

Autor: uwe Friedrichsen

Diese Zweifel kann ich durchaus nachvollziehen und teile sie zu einem großen Teil auch. Business Cases tref-fen Annahmen über Erträge und Kosten, die in der Zu-kunft 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 Fol-gekosten, die nur sehr schwer gemessen werden können, weil meistens der Vergleich fehlt. Trotz dieser absolut berechtigten Probleme und Beschränkungen ist es den-noch 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.

Die Grenzen von zahlenBusiness Cases beschränken sich oftmals rein auf Zahlen, genauer Geld. In der einfachsten Variante werden die er-

warteten Kosten ins Verhältnis zu den erwarteten Erträ-gen gesetzt. Etwas differenzierter sind ROI-Analysen, die zu bestimmen versuchen, nach welchem Zeitraum die Er-träge die Kosten überschreiten. Dennoch betrachtet auch diese Variante letztlich nur ausgegebenes und eingenom-menes Geld. Dieser Betrachtungsweise liegt die Annah-me 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 pro-blemlos 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ö-

Warum wir trotz allem einen Business Case erstellen können

Der Business Case für Architektur in diesem Artikel werde ich versuchen, einen möglichen Business case für Architektur dar-

zustellen. 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 investitionsentschei-

dungen zu begründen und dann auch noch für ein so schwer bewertbares thema wie Architek-

tur? das muss doch schiefgehen!

3bt | 4.2011www.bt-magazin.de

here Fehlerquoten oder reduzierte Produktivität in Geld umrechnen. Dafür muss man Faktoren, Sum-manden 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 Be-wertung für eine Investitionsent-scheidung durchzuführen, sondern diese immer um eine nicht mone-tä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 Ge-samtbewertung 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 mone-tären Größen können Sie entsprechend ergänzend, wenn Sie die Gelegenheit dazu haben sollten.

ziele von arChitekturWie komme ich nun aber zu einer monetären Bewertung von Architektur? Nach meiner Erfahrung ist es am be-sten, 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 The-ma Architektur, z. B. [1], doch die meisten beschäftigen sich nur mit dem Was, sprich den Aufgaben von Archi-tektur. 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 Stake-•holder über den Lebenszyklus des SystemsMinimierung aller bezogenen Kosten über den Le-•benszyklus 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 Archi-tektur ein paar Besonderheiten zu berücksichtigen:

Es geht nicht nur um die Zufriedenheit einer •Stake holder-Gruppe, sondern um alle beteiligten Stakeholder-Gruppen: Es geht nicht nur um die Ent-wicklerzufriedenheit (auch wenn sie ein wichtiger Faktor ist), sondern auch um die Zufriedenheit der Anwender, des Fachbereichs, des Betriebs, des Pro-jektsponsors, des Managements usw. Es soll nicht versucht werden, die Zufriedenheit einer Stakeholder-Gruppe zu Lasten der anderen Gruppen zu maximie-ren, sondern ein Zufriedenheitsoptimum über alle beteiligten Gruppen hinweg zu erreichen.Analog geht es nicht um die Minimierung der Kos-•ten 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. Entwicklungskos ten, sondern auch um Infrastruktur-kosten, Betriebskos ten, Lizenzkosten, Wartungskos-ten, Bedienungskosten, Änderungskosten usw. Auch hier ist ein Optimum über die verschiedenen Kosten-arten 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 Augen-blick 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 Lebenszy-klus des Systems. Meistens enden alle Überlegungen im „Change the Business“-Umfeld mit dem Ende des jeweiligen Projekts. Natürlich ist der Erfolg eines Pro-jekts unter Kos ten- und Zufriedenheitsaspekten wich-

Abb. 1: Anteilige wartungs- und weiterentwicklungskosten für software nach [2]

www.bt-magazin.de4 bt | 4.2011

tig, 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än-dig sind? Hier ist es die Aufgabe der Architektur, die verschiedenen Interessen über den Lebenszyklus des bezogenen Systems zu optimieren.

SChWieriGkeit Der WertBeStimmunGGerade der letzte Punkt macht die Bewertung des Nutzens von Architektur so schwierig. Architektur ist in vielen As-pekten 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 Ände-rungen zu halten. Änderungen finden aber in der Zukunft statt, d. h. ich kann zum Zeitpunkt des Treffens einer Ar-chitekturentscheidung 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 Ar-chitektur heranziehe, dann werde ich viele Nutzenaspekte nicht erfassen bzw. viele Teile der Architekturarbeit als nutzlos erachten.

nutzenpotenziale von arChitekturZur Unterstützung dieser Aussage ist es sinnvoll, sich einmal die Ergebnisse der Untersuchungen von Kos-

kinen (Abb. 1, [2]) anzuschauen. Darin erkennt man auf einen Blick, dass die Wartungs- und Weiterentwick-lungskosten 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 durch-aus Sinn, sich Gedanken über die zukunftsbezogene Än-derbarkeit eines Systems zu machen, da sich damit große Kosteneinsparpotenziale verbinden.

Hierzu lässt sich noch eine Untersuchung des Soft-ware 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 beste-henden 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 ih-rem 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ände-rung der Funktionalität einem Redesign unterzogen, sodass die Software wieder über ein sauberes Design verfügte.

Die Ergebnisse der Untersuchung waren recht beein-druckend: Das zweite Team hat die Aufgabe in der halben Zeit und mit der Hälfte der Aufwände und Kosten erle-

Abb. 2: Änderungskosten, -aufwand und Folgefehler bei guter und schlechter Architektur nach [3]

5bt | 4.2011www.bt-magazin.de

digt. Noch beeindruckender waren allerdings die Folge-effekte: 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-Sys-tem besteht aus einem Vielfachen dieser Informati-onen. 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 je-weiligen 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 Ein-sparpotenziale aber typischerweise erst nach Abschluss des Projekts zum Tragen kommen.

ein naiver anSatz für einen BuSineSS CaSeDieses 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-Verglei-che oder ROI-Berechnungen als Business-Case-Modelle verwendet. Es gibt zwar aufwändigere Modelle, aber aufgrund der hohen Schätzunsicherheiten in den verwen-deten Parametern hat es meistens keinen Sinn, ein kom-plizierteres Modell zu verwenden. Entsprechend werde ich hier mit dem einfachen Kosten-Ertrag-Vergleich ar-beiten. 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 interes-sieren.

In der naiven Variante werden jetzt auf der Kosten-seite nur die Erstellungskosten für die Software kalku-liert, d. h. die Konzeptionskosten, die Umsetzungskosten sowie weitere Kosten wie Lizenzen, Inbetriebnahmekos-ten 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 inner-halb eines Projekts relativ begrenzt sind, laufe ich schnell Gefahr, dass die Konzeptions- und Umsetzungskosten für die Architektur meine daraus resultierenden Einspa-rungen auffressen.

einBeziehen Der komplexitätSfolGekoStenAus 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 Sys-tem 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 Er-stellungskosten für das Feature (siehe oben) sowie sei-nen 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ätsfol-gekosten.

Komplexitätsfolgekosten entstehen immer dann, wenn ein Feature nicht passend zur gewählten Architek-tur umgesetzt wird. Man kennt diese Verstöße unter den Namen wie „Workarounds“, „Quickshots“, „Quick-fixes“ etc. Das Problem ist, dass ein Umgehen der vor-gesehenen Struktur die Komplexität des Systems erhöht, da es einen Sonderfall mehr gibt, den man bei einer zu-kü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 Son-derfä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 viele

www.bt-magazin.de6 bt | 4.2011

Entwickler die Sonderfälle nicht mehr überblicken und deshalb lieber einen weiteren lokalen Sonderfall einbau-en, 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 be-trachtet oftmals billiger und häufig auch einfacher sind. Man schafft eine auf die lokale Aufgabenstellung bezo-gene einfache und kostengünstige Lösung, die schneller und günstiger umsetzbar ist als wenn man sie architek-turkonform umsetzt.

Jetzt kann man einwenden, dass die Architektur schlecht sein muss, wenn es günstiger ist, sie zu umge-hen. Das ist allerdings zu kurz gedacht, weil es die Auf-gabe von Architektur ist, alle Kosten über den gesamten Lebenszyklus in Summe zu minimieren und nicht, die billigste Lösung für jede einzelne Aufgabenstellung an-zubieten. 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ätsfol-gekosten.

möGliChkeiten unD Grenzen einer BereChnunGSformelWie kann man diese Komplexitätsfolgekosten berech-nen? Tatsächlich ist das äußerst schwierig. Sie hängen zum einen von der Anzahl der bereits bestehenden Ar-chitekturverstöße und zum anderen von den für die Rest-lebensdauer des Systems noch benötigten Änderungen ab. Je mehr Architekturverstöße bereits bestehen, desto stärker wirkt sich ein weiterer Verstoß aus, und je weni-ger zukünftige Änderungen noch für das System umzu-setzen 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 resultie-renden Überblicksverlust eines Entwicklers zu doku-mentieren.

Natürlich ist eine solche Formel immer angreifbar, egal wie Sie sie formulieren. Zum einen können alle Ko-effizienten 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 Fra-ge 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 em-pirisches Annähern bestimmen kann, sondern das Be-wusstsein, dass es Komplexitätsfolgekosten gibt und dass sie einen essenziellen Kostenfaktor bei der Bewer-tung 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 Be-teiligten leicht fällt, ihnen zuzustimmen. Wenn Sie es geschafft haben, einer Business-Case-fixierten Runde die Existenz und die Multiplikationseffekte von Kom-plexitätsfolgekosten begreiflich zu machen, dann ha-ben Sie Ihr Ziel praktisch schon erreicht. Die exakten

Zahlen sind dann nicht mehr so wichtig.

Weitere anSatzpunkteDas war ein einfacher Ansatz zur monetären Bewertung des Nutzens von Architektur. Man kann ihn je-doch deutlich weiter ausbauen. So haben wir die Ertragsseite bislang noch gar nicht betrachtet. Amazon hat z. B. in einer Studie herausge-funden, dass eine durchschnittlich um 100 Millisekunden langsamere Antwortzeit signifikante Umsatz-einbußen zur Folge habe. Anders Abb. 3: ein möglicher Ansatz zur Berechnung von Komplexitätsfolgekosten [4]

7bt | 4.2011www.bt-magazin.de

ausgedrückt können sich schlechte Architekturentschei-dungen auch deutlich auf die Ertragsseite eines Business Cases auswirken.

Noch deutlicher wird das, wenn eine fachliche Ände-rung, 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 Gewinnein-bußen erleidet.

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

zuSammenfaSSunGBusiness Cases sind ein häufig verwendetes Instrument zur Überprüfung einer anstehenden Investitionsent-scheidung. Auch wenn die Aussagekraft eines Business Cases aufgrund seiner ausschließlichen Fokussierung auf eine monetäre Bewertung und der damit verbun-denen 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 bestim-men, ist besonders schwer, weil viele Architekturent-scheidungen erst weit in der Zukunft ihren Wert zeigen, während die Kosten sofort entstehen. Um hier über-haupt einen brauchbaren Business Case aufmachen zu können, muss man die Folgekosten für Architekturent-scheidungen jenseits der Grenzen eines einzelnen Pro-jekts mit in die Betrachtung einbeziehen. Insbesondere die Komplexitätsfolgekosten, die durch das Verletzen einer gegebenen Architektur entstehen, sind ein wich-tiger Faktor für die Bestimmung des Werts einer Ar-chitektur.

Trotzdem bleibt es schwierig, eine geschlossene und allgemein akzeptierte Formel für den Wert einer Ar-chitektur zu bilden. Das ist aber auch nicht so wichtig, wenn es gelingt, in einem Business-Case-fixierten Um-feld die Existenz und die Auswirkungen von Komple-xitä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 hel-fen kann, die Notwendigkeit einer integren Architek-tur zu verdeutlichen. Natürlich gibt es noch sehr viele

uwe friedrichsenhat langjährige erfahrungen als Archi-tekt, Projektleiter und Berater. Aktuell ist er bei der codecentric AG als cto tätig und beschäftigt sich in dem Kon-text insbesondere mit agilen Verfahren und neuen Architekturansätzen und technologien.

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, Appen-dix 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

andere 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 Dis-kussion 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 Wert-bestimmung.

codecentric AG Kölner Landstraße 11 40591 Düsseldorf

Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444

E-Mail: info@codecentric.de www.codecentric.de blog.codecentric.de