• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sonderdruck codecentric btm_4_2011_friedrichsen_mon
 

Sonderdruck codecentric btm_4_2011_friedrichsen_mon

on

  • 424 views

 

Statistics

Views

Total Views
424
Views on SlideShare
424
Embed Views
0

Actions

Likes
1
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sonderdruck codecentric btm_4_2011_friedrichsen_mon Sonderdruck codecentric btm_4_2011_friedrichsen_mon Document Transcript

    • www.bt-magazin.de 4.2011 Heft 7 expertenwissen für it-architekten, projektleiter und Berater : Detlev Klage dnis für „Das Verstän hlt.“ Architektur zä BUSINESS VALUESonderdruck fürwww.codecentric.de Wertschöpfung durch IT? Kostentransparenz im EAM-Modell Der ROI der Cloud
    • Business CareWarum wir trotz allem einen Business Case erstellen könnenDer Business Casefür Architekturin 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 itsind 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!Autor: uwe Friedrichsen warteten Kosten ins Verhältnis zu den erwarteten Erträ- gen gesetzt. Etwas differenzierter sind ROI-Analysen, dieDiese Zweifel kann ich durchaus nachvollziehen und zu bestimmen versuchen, nach welchem Zeitraum die Er-teile sie zu einem großen Teil auch. Business Cases tref- träge die Kosten überschreiten. Dennoch betrachtet auchfen Annahmen über Erträge und Kosten, die in der Zu- diese Variante letztlich nur ausgegebenes und eingenom-kunft liegen, und diese Annahmen sind häufig so stabil menes Geld. Dieser Betrachtungsweise liegt die Annah-wie die Klötzchentürme kleiner Kinder, kurz bevor sie in me zugrunde, dass sich alle Einflussgrößen auf Kostensich zusammenfallen. Erschwerend kommt hinzu, dass oder Erträge herunterbrechen lassen. Diese Annahme istArchitektur sich häufig nur indirekt und zeitlich verzö- nicht ganz falsch. Man kann sich tatsächlich für fast jedegert auf die Kosten und Erträge auswirkt. Gerade eine Einflussgröße eine monetäre Quantifizierung überlegen.schlechte Architektur führt in der Regel zu hohen Fol- Trotzdem ist es in vielen Fällen so, dass eine Umrechnunggekosten, die nur sehr schwer gemessen werden können, einer Einflussgröße in Geld so viele Annahmen trifft, dassweil meistens der Vergleich fehlt. Trotz dieser absolut der Nutzen der monetären Darstellung sehr fragwürdigberechtigten Probleme und Beschränkungen ist es den- ist. So könnte z. B. im Zusammenhang mit Architekturnoch so, dass wir von Zeit zu Zeit wahrscheinlich nicht die Entwicklerzufriedenheit eine relevante Einflussgrößeumhin kommen, das Thema Architektur mit Zahlen zu sein. In ihrer ursprünglichen Form kann man diese pro-untermauern. Genau aus diesem Grund versuche ich blemlos auf einer bedarfsgerecht unterteilten Skala vonhier, einen möglichen Ansatz zu beschreiben. „sehr unzufrieden“ bis „sehr zufrieden“ darstellen, die für alle Beteiligten intuitiv erfassbar ist.Die Grenzen von zahlen Versucht man aber, die Entwicklerzufriedenheit inBusiness Cases beschränken sich oftmals rein auf Zahlen, Geld umzurechnen, muss man Aspekte wie erwartetegenauer Geld. In der einfachsten Variante werden die er- Kündigungen, Einarbeitung neuer Mitarbeiter, hö-2 bt | 4.2011 www.bt-magazin.de
    • here Fehlerquoten oder reduzierteProduktivität in Geld umrechnen.Dafür muss man Faktoren, Sum-manden und Wahrscheinlichkeitenfestlegen, die man in der Regel„raten“ muss, weil man keinerleiDatenmaterial zur Verfügung hat,anhand dessen man diese Wertefestlegen kann. Die Aussagekraftder resultierenden Zahl wird also inder Regel eher fragwürdig sein undintuitiver ist die Größe auch nicht. Aus diesen Gründen empfehleich, nicht nur eine monetäre Be-wertung für eine Investitionsent- Abb. 1: Anteilige wartungs- und weiterentwicklungskosten für software nach [2]scheidung durchzuführen, sonderndiese immer um eine nicht mone-täre Bewertung sowie eine Risikoanalyse zu ergänzen Maximierung von Zufriedenheit und Minimierung vonund die verschiedenen Einflussgrößen in geeigneter Kosten sind relativ häufig anzutreffende Ziele, also erstWeise den drei Bereichen zuzuordnen. Und da man für einmal nichts Besonderes. Allerdings gibt es für Archi-die nicht monetären Größen immer ein weitestgehend tektur ein paar Besonderheiten zu berücksichtigen:normiertes Schema (z. B. Zahlen von 1 bis 10) findenkann, leidet auch die intuitive Erfassbarkeit der Ge- • Es geht nicht nur um die Zufriedenheit einersamtbewertung nicht. Stakeholder-Gruppe, sondern um alle beteiligten Dennoch werde ich mich in diesem Artikel nur auf Stakeholder-Gruppen: Es geht nicht nur um die Ent-den Versuch beschränken, den Wert von Architektur als wicklerzufriedenheit (auch wenn sie ein wichtigermonetären Wert darzustellen. Die anderen nicht mone- Faktor ist), sondern auch um die Zufriedenheit dertären Größen können Sie entsprechend ergänzend, wenn Anwender, des Fachbereichs, des Betriebs, des Pro-Sie die Gelegenheit dazu haben sollten. jektsponsors, des Managements usw. Es soll nicht versucht werden, die Zufriedenheit einer Stakeholder-ziele von arChitektur Gruppe zu Lasten der anderen Gruppen zu maximie-Wie komme ich nun aber zu einer monetären Bewertung ren, sondern ein Zufriedenheitsoptimum über allevon Architektur? Nach meiner Erfahrung ist es am be- beteiligten Gruppen hinweg zu erreichen.sten, in solchen Situationen nach dem Zweck bzw. den • Analog geht es nicht um die Minimierung der Kos-Zielen der zu bewertenden Sache – hier Architektur – ten für eine Kostenart, sondern um alle betroffenenzu fragen, da sie helfen, die relevanten Nutzentreiber zu Kostenarten. So geht es nicht nur – wie so häufigidentifizieren. Es gibt jede Menge Definitionen zum The- gefordert – um die Minimierung von Projekt- bzw.ma Architektur, z. B. [1], doch die meisten beschäftigen Entwicklungskosten, sondern auch um Infrastruktur-sich nur mit dem Was, sprich den Aufgaben von Archi- kosten, Betriebskosten, Lizenzkosten, Wartungskos-tektur. Das Warum, die Ziele von Architektur, werden ten, Bedienungskosten, Änderungskosten usw. Auchin der Regel nicht adressiert. hier ist ein Optimum über die verschiedenen Kosten- Da ich im Laufe meines Berufslebens häufiger einmal arten anzustreben, was häufig sehr schwerfällt, weilgefragt worden bin, wofür Architektur denn überhaupt einige der Kosten erst verzögert zum Tragen kommengut sei und mir die landläufigen Definitionen an der und so die Versuchung sehr hoch ist, für den Augen-Stelle nicht weitergeholfen haben, habe ich mir zu dem blick zu optimieren.Thema einige Gedanken gemacht. Meine Überlegungen • In der anderen Dimension geht es nicht darum, diebrachten mich zu den folgenden zwei primären Zielen: Zufriedenheit oder die Kosten für einen Zeitpunkt zu optimieren, sondern über den gesamten Lebenszy-• Maximierung der Zufriedenheit aller beteiligten Stake- klus des Systems. Meistens enden alle Überlegungen holder über den Lebenszyklus des Systems im „Change the Business“-Umfeld mit dem Ende des• Minimierung aller bezogenen Kosten über den Le- jeweiligen Projekts. Natürlich ist der Erfolg eines Pro- benszyklus des Systems jekts unter Kosten- und Zufriedenheitsaspekten wich-www.bt-magazin.de bt | 4.2011 3
    • Abb. 2: Änderungskosten, -aufwand und Folgefehler bei guter und schlechter Architektur nach [3] tig, aber was hilft ein sehr günstiges Projekt, wenn das kinen (Abb. 1, [2]) anzuschauen. Darin erkennt man entstandene System unter der Oberfläche so schlecht auf einen Blick, dass die Wartungs- und Weiterentwick- ist, dass die Betriebsstabilität schlecht ist, die Software lungskosten eines Systems um ein Vielfaches höher sind viele Fehler hat und Änderungen ungemein aufwän- als die initialen Entwicklungskosten. Der große Hebel dig sind? Hier ist es die Aufgabe der Architektur, die für Kosteneinsparungen liegt also in der Wartung und verschiedenen Interessen über den Lebenszyklus des Weiterentwicklung eines Systems. Es macht also durch- bezogenen Systems zu optimieren. aus Sinn, sich Gedanken über die zukunftsbezogene Än- derbarkeit eines Systems zu machen, da sich damit großeSChWieriGkeit Der WertBeStimmunG Kosteneinsparpotenziale verbinden.Gerade der letzte Punkt macht die Bewertung des Nutzens Hierzu lässt sich noch eine Untersuchung des Soft-von Architektur so schwierig. Architektur ist in vielen As- ware Technology Support Center des Department ofpekten eher auf die Zukunft ausgerichtet, d. h. der Nutzen Defense heranziehen [3]. In dieser Untersuchung hateiner jetzt getroffenen Architekturentscheidung zeigt sich man zwei gleichstarke Teams gebildet und ihnen diehäufig erst deutlich später. So ist z. B. eine sehr wichtige gleiche Aufgabenstellung gegeben, nämlich eine ReiheAufgabe von Architektur, das System offen für Ände- von Änderungen und Erweiterungen in einem beste-rungen zu halten. Änderungen finden aber in der Zukunft henden System umzusetzen. Der Unterschied lag in derstatt, d. h. ich kann zum Zeitpunkt des Treffens einer Ar- Software, die die Teams als Grundlage für ihre Arbeitchitekturentscheidung den Nutzen der Entscheidung noch erhalten hatten. Das erste Team hat die Software in ih-gar nicht bestimmen. Umgekehrt bedeutet das, wenn ich rem ursprünglich, über die Jahre ziemlich degeneriertennur den aktuellen Zeitpunkt bzw. einen kurzen Zeitraum und schlecht strukturierten Zustand bekommen. Fürwie z. B. ein Projekt zur Bewertung des Nutzens von Ar- das zweite Team wurde die Software wieder in Formchitektur heranziehe, dann werde ich viele Nutzenaspekte gebracht, d. h. man hat die Software ohne Verände-nicht erfassen bzw. viele Teile der Architekturarbeit als rung der Funktionalität einem Redesign unterzogen,nutzlos erachten. sodass die Software wieder über ein sauberes Design verfügte.nutzenpotenziale von arChitektur Die Ergebnisse der Untersuchung waren recht beein-Zur Unterstützung dieser Aussage ist es sinnvoll, sich druckend: Das zweite Team hat die Aufgabe in der halbeneinmal die Ergebnisse der Untersuchungen von Kos- Zeit und mit der Hälfte der Aufwände und Kosten erle-4 bt | 4.2011 www.bt-magazin.de
    • digt. Noch beeindruckender waren allerdings die Folge- In der naiven Variante werden jetzt auf der Kosten-effekte: Die Lösung des zweiten Teams war um Längen seite nur die Erstellungskosten für die Software kalku-stabiler. Sie hatte nur etwa zehn Prozent der Fehler, die liert, d. h. die Konzeptionskosten, die Umsetzungskostenin der Lösung des ersten Teams gefunden worden sind sowie weitere Kosten wie Lizenzen, Inbetriebnahmekos-(Abb. 2). ten etc. In dieser Variante habe ich wie bereits zuvor Denkt man einen Augenblick über diese Ergebnisse beschrieben nur sehr begrenzte Möglichkeiten, dennach, sind sie letztlich nicht sonderlich überraschend: Nutzen von Architekturarbeit zu rechtfertigen. Da dieDas menschliche Gehirn ist sehr beschränkt bzgl. der Einsparpotenziale aus gut strukturierter Software inner-Menge an Informationen, die es zu einem Zeitpunkt halb eines Projekts relativ begrenzt sind, laufe ich schnellüberblicken kann. Selbst ein relativ einfaches IT-Sys- Gefahr, dass die Konzeptions- und Umsetzungskostentem besteht aus einem Vielfachen dieser Informati- für die Architektur meine daraus resultierenden Einspa-onen. Um in dieser Menge an Informationen, Fakten rungen auffressen.und Beziehungen nicht den Überblick zu verlieren,benötigen wir Strukturen, in denen die Informationen einBeziehen Der komplexitätSfolGekoStenorganisiert sind. Je besser die Strukturen zu unserer je- Aus den zuvor beschriebenen Untersuchungen wissenweiligen Aufgabenstellung passen, desto leichter fällt wir aber, dass sich der eigentliche Nutzen einer gutenuns die Umsetzung der Aufgabe und desto weniger Architektur erst verzögert entfaltet und lange nachwirktFehler machen wir typischerweise. Genau das ist eine – analog zum Schaden durch eine schlechte Architektur.der Kernaufgaben von Architektur und Design: die Wir müssen also die Zeit nach dem ErstellungsprojektSoftware so zu strukturieren, dass wir darin nicht den mit in die Bewertung der Kosten einbeziehen. Wie kannÜberblick verlieren. man das machen? Zusammenfassend können wir folgern, dass eine gute Eine Möglichkeit ist, die Gesamtkosten für ein Sys-Architektur durchaus monetäre Vorteile für ein laufendes tem als Summe der Kosten für alle Features auszudrü-Entwicklungsprojekt bringen kann, die eigentlichen Ein- cken, die jemals für das System entwickelt worden sind.sparpotenziale aber typischerweise erst nach Abschluss Die Kosten für ein Feature setzen sich nun aus den Er-des Projekts zum Tragen kommen. stellungskosten für das Feature (siehe oben) sowie sei- nen Folgekosten zusammen. Die Gesamtkosten für einein naiver anSatz für einen BuSineSS CaSe einzelnes Projekt kann man dann berechnen, indem manDieses Wissen möchte ich jetzt nutzen, um zu versuchen, die Kosten für alle Features addiert, die in dem Projekteinen Business Case für Architektur zu erstellen. Dabei umgesetzt werden.beginne ich mit der Auswahl des Business-Case-Modells: Was aber sind Folgekosten? Folgekosten sind dieAm häufigsten werden einfache Kosten-Ertrag-Verglei- Kosten, die nach Abschluss des Projekts entstehen, inche oder ROI-Berechnungen als Business-Case-Modelle dem das zugehörige Feature umgesetzt worden ist. Grobverwendet. Es gibt zwar aufwändigere Modelle, aber gesagt sind das die kumulierten Betriebskosten für dasaufgrund der hohen Schätzunsicherheiten in den verwen- Feature mit den eventuell anfallenden Komplexitätsfol-deten Parametern hat es meistens keinen Sinn, ein kom- gekosten.plizierteres Modell zu verwenden. Entsprechend werde Komplexitätsfolgekosten entstehen immer dann,ich hier mit dem einfachen Kosten-Ertrag-Vergleich ar- wenn ein Feature nicht passend zur gewählten Architek-beiten. Eine Übertragung der Ideen auf andere Modelle tur umgesetzt wird. Man kennt diese Verstöße unter denist aber problemlos möglich. Namen wie „Workarounds“, „Quickshots“, „Quick- Wir gehen zur weiteren Vereinfachung erst einmal fixes“ etc. Das Problem ist, dass ein Umgehen der vor-von einem konstanten Ertrag aus, d. h. dass unsere gesehenen Struktur die Komplexität des Systems erhöht,Architektur den Ertrag nicht beeinflusst. In der Praxis da es einen Sonderfall mehr gibt, den man bei einer zu-beeinflusst eine gute Architektur die Ertragsseite zwar künftigen Änderung berücksichtigen muss.durchaus positiv, aber dazu später mehr. Das geht noch ganz gut, wenn die Anzahl dieser Auf der Ertragsseite steht damit erst einmal nur, was Verstöße recht gering ist. Ab einem nicht allzu hohendie Umsetzung der Anforderungen nach Schätzung des Schwellwert steigen die Komplexitätsfolgekosten aberFachbereichs oder des Managements in die Kassen des überproportional an, da ein Entwickler die ganzen Son-Unternehmens spülen soll. Die Zahlen auf dieser Seite derfälle nicht mehr überblicken kann. Als Konsequenzdes Business Cases basieren häufig auf recht spekulativen sinkt die Entwicklungsgeschwindigkeit, die FehlerquoteAnnahmen, aber das soll uns an der Stelle nicht interes- steigt, die Betriebssicherheit sinkt etc. Zusätzlich steigtsieren. die Wahrscheinlichkeit weiterer Verstöße, weil vielewww.bt-magazin.de bt | 4.2011 5
    • Entwickler die Sonderfälle nicht mehr überblicken und Es gibt jetzt viele Möglichkeiten, dies in eine Formeldeshalb lieber einen weiteren lokalen Sonderfall einbau- zu gießen. Ich habe für einen JAX-Vortrag einmal eineen, um ihr Problem irgendwie zu lösen. Das Problem der Formel entwickelt (Abb. 3, [4]), verzichte aber darauf,Architekturverstöße tendiert also dazu, sich ab einem sie hier weiter zu erläutern, weil sie genauso gut oderbestimmten Schwellwert selbst zu verschärfen. schlecht ist wie jede andere Formel. Man sollte bei der Warum kommt es überhaupt zu diesen Verstößen? Erstellung primär darauf achten, dass die Kosten abDas geschieht häufig, weil die Verstöße kurzfristig be- einem gewissen Schwellwert an Architekturverstößentrachtet oftmals billiger und häufig auch einfacher sind. stark überproportional ansteigen, um den Effekt derMan schafft eine auf die lokale Aufgabenstellung bezo- Komplexitätsmultiplikation und den daraus resultie-gene einfache und kostengünstige Lösung, die schneller renden Überblicksverlust eines Entwicklers zu doku-und günstiger umsetzbar ist als wenn man sie architek- mentieren.turkonform umsetzt. Natürlich ist eine solche Formel immer angreifbar, Jetzt kann man einwenden, dass die Architektur egal wie Sie sie formulieren. Zum einen können alle Ko-schlecht sein muss, wenn es günstiger ist, sie zu umge- effizienten mangels statistisch belegbarer Datenbasis inhen. Das ist allerdings zu kurz gedacht, weil es die Auf- Frage gestellt werden und zum anderen kann die Formelgabe von Architektur ist, alle Kosten über den gesamten an sich in Frage gestellt werden. An der Stelle kann manLebenszyklus in Summe zu minimieren und nicht, die versuchen, Gleiches mit Gleichem zu vergelten und diebilligste Lösung für jede einzelne Aufgabenstellung an- Formeln und Koeffizienten auf der Ertragsseite in Fra-zubieten. Trotzdem sorgen Zeit- und Kostendruck in ge zu stellen, doch das wird in der Regel keinen großenProjekten häufig dafür, dass man der Verlockung der Nutzen bringen.„einfachen“ Lösung erliegt, um kurzfristig dem Druck Wichtig ist meines Erachtens auch nicht die exaktezu entgehen. Doch die Rechnung dafür zahlt man später Formel, da man die genaue Form und die benötigtenmit Zins und Zinseszins in Form der Komplexitätsfol- Koeffizienten in der Regel erst durch langfristiges em-gekosten. pirisches Annähern bestimmen kann, sondern das Be- wusstsein, dass es Komplexitätsfolgekosten gibt undmöGliChkeiten unD Grenzen einer dass sie einen essenziellen Kostenfaktor bei der Bewer-BereChnunGSformel tung von Architektur darstellen.Wie kann man diese Komplexitätsfolgekosten berech- Deshalb sollten Sie auch nicht so sehr an der Formelnen? Tatsächlich ist das äußerst schwierig. Sie hängen an sich feilen, sondern viel mehr an der Begründung fürzum einen von der Anzahl der bereits bestehenden Ar- die Formel. Untersuchungen wie die des Departmentchitekturverstöße und zum anderen von den für die Rest- of Defense sind da sehr hilfreich, und die Koeffizientenlebensdauer des Systems noch benötigten Änderungen sollte man ruhig defensiv wählen, sodass es allen Be-ab. Je mehr Architekturverstöße bereits bestehen, desto teiligten leicht fällt, ihnen zuzustimmen. Wenn Sie esstärker wirkt sich ein weiterer Verstoß aus, und je weni- geschafft haben, einer Business-Case-fixierten Rundeger zukünftige Änderungen noch für das System umzu- die Existenz und die Multiplikationseffekte von Kom-setzen sind, desto weniger Situationen gibt es, in denen plexitätsfolgekosten begreiflich zu machen, dann ha-die Verstöße zum Tragen kommen. ben 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 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-Abb. 3: ein möglicher Ansatz zur Berechnung von Komplexitätsfolgekosten [4] einbußen zur Folge habe. Anders6 bt | 4.2011 www.bt-magazin.de
    • ausgedrückt können sich schlechte Architekturentschei- andere Ansatzpunkte, um den Wert einer Architekturdungen auch deutlich auf die Ertragsseite eines Business zu bestimmen, was aber den Rahmen dieses ArtikelsCases auswirken. bei Weitem gesprengt hätte. Wenn Ihnen die Ideen in Noch deutlicher wird das, wenn eine fachliche Ände- diesem Artikel aber helfen sollten, die nächste Dis-rung, z. B. die Unterstützung eines innovativen Produkts kussion darüber, ob man denn das dringende Featureaufgrund einer schlechten Architektur so lange dauert, nicht schnell an der Architektur vorbei implementierendass das Unternehmen das „Window of Opportunity“ sollte, erfolgreich zu meistern, dann würde mich dasverpasst, d. h. dass es zu spät mit dem Produkt in den freuen. Ich wünsche Ihnen auf jeden Fall viel ErfolgMarkt eintritt und so massive Umsatz- und Gewinnein- in den sicherlich noch häufigen Diskussionen zu dembußen erleidet. Thema sowie beim Finden eigener Modelle zur Wert- Ebenfalls negativ wirkt es sich auf die Ertragsseite bestimmung.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 deutlichverlä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 Instrumentzur Überprüfung einer anstehenden Investitionsent-scheidung. Auch wenn die Aussagekraft eines BusinessCases aufgrund seiner ausschließlichen Fokussierungauf eine monetäre Bewertung und der damit verbun-denen Zwangsquantifizierung aller qualitativen undRisikowerte durchaus fragwürdig ist, muss man sichdamit arrangieren, dass dieses Instrument häufig zumEinsatz kommt und in seiner Grundidee auch durchaussinnvoll ist. Den monetären Wert einer Architektur zu bestim-men, ist besonders schwer, weil viele Architekturent- links & literatur [1] software engineering institute, carnegie Mellon: definingscheidungen erst weit in der Zukunft ihren Wert zeigen, software Architecture: http://www.sei.cmu.edu/architecture/während die Kosten sofort entstehen. Um hier über- start/definitions.cfmhaupt einen brauchbaren Business Case aufmachen zu [2] Koskinen, Jussi: software Maintenance cost, 2003:können, muss man die Folgekosten für Architekturent- http://www.cs.jyu.fi/~koskinen/smcosts.htm [3] Guidelines for successful Acquisition and Management ofscheidungen jenseits der Grenzen eines einzelnen Pro- software intensive systems, Version 3.0 May 2000, Appen-jekts mit in die Betrachtung einbeziehen. Insbesondere dix F, Kapitel F1.3.2, software technology support center:die Komplexitätsfolgekosten, die durch das Verletzen http://www.stsc.hill.af.mil/resources/tech_docs/gsam3.htmleiner gegebenen Architektur entstehen, sind ein wich- [4] Friedrichsen, uwe: der Business case für Architektur, JAX 2010: http://it-republik.de/konferenzen/jax2010/tiger Faktor für die Bestimmung des Werts einer Ar- session/?tid=1540#session-13078chitektur. Trotzdem bleibt es schwierig, eine geschlossene undallgemein akzeptierte Formel für den Wert einer Ar-chitektur zu bilden. Das ist aber auch nicht so wichtig, uwe friedrichsenwenn es gelingt, in einem Business-Case-fixierten Um- hat langjährige erfahrungen als Archi-feld die Existenz und die Auswirkungen von Komple- tekt, Projektleiter und Berater. Aktuellxitätsfolgekosten verständlich zu machen. In Summe ist er bei der codecentric AG als cto tätig und beschäftigt sich in dem Kon-haben wir dieses Thema nur gestreift. Wir haben einen text insbesondere mit agilen Verfahrenwillkürlichen Aspekt der Architektur herausgepickt und neuen Architekturansätzen undund darauf eine Wertbestimmung aufgebaut, die hel- technologien.fen kann, die Notwendigkeit einer integren Architek-tur zu verdeutlichen. Natürlich gibt es noch sehr vielewww.bt-magazin.de bt | 4.2011 7
    • codecentric AGKölner Landstraße 1140591 DüsseldorfTel: +49 (0) 211.9941410Fax: +49 (0) 211.9941444E-Mail: info@codecentric.dewww.codecentric.deblog.codecentric.de