T echnische Schulden sind Defizitein Anwendungen oder in der An-wendungslandschaft eines Unter-

nehmens, deren Fortbestehen ein gravie-rendes Risiko für die Firma darstellt oderdie Wartung oder Weiterentwicklung sub-stanziell beeinträchtigt. Laut einer Studievon CAST Software [a] werden die tech-nischen Schulden für die 288 Anwendun-gen in der CAST-Analysedatenbank mitim Schnitt 374 KLOC (1000 Lines ofCode) – defensiv geschätzt – je Anwen-dung auf mindestens 1ˇMillion US-$ be-ziffert.

Es gibt viele Ursachen, die zur Auf-nahme technischer Schulden führen kön-nen. Sie entstehen sowohl auf der Ebeneeinzelner Softwaresysteme, als auch aufder ganzer IT-Anwendungslandschaften.

Typische Problemfelder sind eine unnötighohe Komplexität der IT-Landschaft odereine erhöhte Heterogenität der eingesetz-ten Technologien. Ein erster Artikel [1]hat bereits den Begriff der technischenSchulden genauer erläutert und verschie-dene Modelle vorgestellt, die dabei hel-fen können, solche Schulden zu vermei-den beziehungsweise gering zu haltenund so die Softwarequalität zu gewähr-leisten.

Die Realität sieht traurig aus

Der vorliegende Artikel stellt typischeKategorien technischer Schulden vor. Diein den folgenden Abschnitten skizzierten

Beispiele stammen aus Beratungsman -daten für mittelständische Unternehmenmit 400 bis 1200 Mitarbeitern.

In den meisten IT-Anwendungsland-schaften findet man suboptimale, schnell„zusammengezimmerte“ Lösungen vor.Sie weisen bestimmte sich wiederholendeund im Unternehmen häufig wohlbekann-te Defizite auf, weil die Verantwortlichenbei der Entwicklung den Schwerpunkt aufTime to Market gelegt und wesentlicheEigenschaften wie Wartbarkeit, Adminis-trierbarkeit, Skalierbarkeit, Effizienz oderGebrauchstauglichkeit nicht angemessenberücksichtigt haben.

Ebenso häufig trifft man Anwendungenan, die Unternehmensstandards bezüglichPlattformen, Programmiersprachen, Aus-tauschformaten et cetera missachten. Sol-che Verletzungen führen zu einer höherenHeterogenität der eingesetzten Techno-logien als nötig und damit insgesamt zueiner höheren Komplexität der IT-Land-schaft. Es werden mehr Systeme betrie-ben und mehr Techniken eingesetzt alsnötig beziehungsweise gewünscht. Da-durch ist das erforderliche Know-howbreiter gestreut, und der Aufwand für dieEntwicklung sowie für Wartung und Be-trieb steigt.

!" iX #$/%$#%

REPORT | SOFTWAREPROJEKTE

Technische Schulden in der Unternehmensarchitektur

Lieber sparen als zahlenGeorg Molter, Matthias Kraaz

Ob technisches Kuck ucksei oder mono -lithische Strukturen einesSoftwaresystems – die Ursachen für technische Schulden sind vielfältig. Sie können in der Anwendungslandschaft eines Unternehmens ein hohes Risiko darstellen.

ix.1012.098-104 10.09.12 16:32 Seite 98

© Copyright by Heise Zeitschriften Verlag

Technische Schulden können aberauch die Anwendungslandschaft an sichbetreffen; die Defizite stecken dann inMechanismen oder Designprinzipien undresultieren nicht unmittelbar aus Eigen-schaften einer einzelnen Applikation. Ty-pische Beispiele sind Punkt-zu-Punkt-Schnittstellen zwischen Anwendungen ingrößerer Zahl oder enge funktionale Ab-hängigkeiten, die die Anwendungsland-schaft insgesamt monolithisch werdenlassen und es nahezu unmöglich machen,einzelne Systeme separat weiterzuentwi-ckeln und produktiv zu setzen. Daraus er-geben sich die in vielen Unternehmen be-kannten Gesamt-Releases, von denenunter großen Mühen pro Jahr zwei oderdrei getestet und produktiv gesetzt wer-den können. Die Vorlaufzeiten vom Er-kennen des Bedarfs an neuer Funktiona-lität bis hin zu ihrem Deployment liegendann nicht selten bei mindestens neunMonaten.

Altes wird nicht immer über Bord geworfen

Andere technische Schulden entstehen,weil Legacy-Anwendungen erhalten wer-den müssen. Auf typische Beispiele tra-fen die Autoren in einem Unternehmenaus dem Bereich Finanzdienstleistungensowie einem aus dem Logistiksektor.Deren zentrale Mainframe-Applikatio-nen lassen sich über die Jahre hinwegzunehmend schlechter warten. Das liegtzum einen an der steigenden Komplexi-tät, zum anderen aber auch daran, dassdas für Wartung und Weiterentwicklungbenötigte Know-how immer knapperwird. Lange Zeit hat man daher neueFunktionen immer häufiger nicht mehrim Kernsystem ergänzt, sondern in vor-gelagerten Applikationen realisiert. Da-durch ergeben sich für die AnwenderSystembrüche, und die engen Abhängig-keiten der betroffenen Systeme unterein- ander führen statt zu einer Reduzierung

der Komplexität durch Separation of Con-cerns zu einer noch höheren Komplexi-tät und einer noch eingeschränkterenWartbarkeit.

In einer ebenfalls häufig anzutreffen-den Konstellation ändert sich die Daten-hoheit innerhalb der Anwendungsland-schaft täglich routinemäßig mit derTageszeit. Während des Arbeitstages istein Dialogsystem führend, in der Nachtwechselt die Datenhoheit auf andere Sys-teme, die Batch-Verarbeitungsschritteund Verdichtungen durchführen. Dasgeht so lange gut, wie die „Nachtstun-den“ zum Ausführen der Batch-Prozesseausreichen. Wird die Systemlandschaftzum ersten Mal auch Anwendern inAmerika oder Fernost zur Verfügung ge-stellt oder werden Rufe nach einer Near-Realtime-Aktualität der erstellten Aufbe-reitungen und der Reports laut, tretenKonflikte auf.

Ein anderes häufiges Muster ist derunkontrollierte, direkte Zugriff auf dieDatenbanken anderer Anwendungen. Da-durch entsteht eine enge Kopplung zwi-schen den beteiligten Systemen, weil siesich von der Datenbankstruktur als ei-nem Implementierungsdetail abhängigmachen.

Abkürzungen können Risiken bergen

Des Öfteren nutzen Entwickler gern in Re-porting-Datenbanken und in Data Ware-houses vorhandene Daten als schnellenInput für operative Anwendungen. Diehierdurch aufgenommenen technischenSchulden bestehen darin, dass operativeSysteme, die hoch verfügbar sein müs-sen, selbst von Systemen mit niedrigerenVerfügbarkeitsgarantien abhängig sind.Um ihre Leistung zu erbringen, beziehensie Daten von dispositiven Systemen, de-ren Service Level Agreements normaler-weise etwas laxer ausfallen. Es ist nahe-liegend, dass diese Konstellation die

Gesamtverfügbarkeit der benötigten An-wendungen beeinträchtigt.

Alles unter einen Hut bringen müssen

Ebenfalls häufig findet man die „All-in-one“-Applikation oder -Middleware, diein einem vorhandenen System viele ver-schiedene Funktionen kombiniert, die in-haltlich nicht direkt miteinander ver-knüpft sind. Wird eine neue Funktionbenötigt, gelangt sie häufig ins Aufgaben-buch des bereits laufenden Systems oderProjekts, das den geringsten Widerstandleistet, obwohl sie dort nicht unbedingthineinpasst. Auf diese Weise entstehenwiederum monolithische Service-Blöcke,die das Prinzip der Separation of Con-cerns verletzen und dadurch Wartbarkeitund die Möglichkeit zum separaten De-ployment beeinträchtigen.

Nicht selten kommt es vor, dass einbei separater Betrachtung gutes System,das die geforderten Qualitätseigenschaf-ten erfüllt, im Rahmen der Betrachtungder gesamten Unternehmenslandschaftsubstanzielle technische Schulden dar-stellt. Ein Beispiel ist ein Unternehmenmit einer weitgehend homogenen .NET-Landschaft, für das ein Dienstleister eineJava-Anwendung maßgeschneidert ent-wickelt und betrieben hat. Über kurzoder lang sah sich das Unternehmen da-zu gezwungen, die Weiterentwicklungund den Betrieb dieser Software selbstzu übernehmen – und war dann damitkonfrontiert, für ein einzelnes, aberfachlich zentrales System die Entwick-lungs- und Betriebskompetenz sowie die

#$$ iX #$/%$#%

REPORT | SOFTWAREPROJEKTE

x!TRACT! Technische Schulden sind Defizite in der Anwendungslandschaft eines Unterneh-

mens, deren Fortbestehen ein gravierendes Risiko für das Unternehmen darstelltoder die Wartung oder Weiterentwicklung substanziell beeinträchtigt.

! Bei der Kontrolle der technischen Schulden spielen das Management der Unter-nehmensarchitektur und die damit verbundene IT-Governance eine zentrale Rolle.

! Die Mechanismen zur Kontrolle der Schulden lassen sich so anpassen, dass sieauch für den Einsatz in mittelständischen Unternehmen geeignet sind.

Kategorien technischer Schulden

schnelle Lösungen

Heterogenität

monolithische Strukturen

Applikationsschichten um Legacy-Systeme

wechselnde Datenhoheit

enge Kopplung durch gemeinsame Datenbank

Vermischung operativer und dispositiverDatenhaltung

All-in-one-Middleware

technisches Kuckucksei

Maintenance und Erweiterungen ohne Anpassung der Struktur

ix.1012.098-104 10.09.12 16:32 Seite 100

© Copyright by Heise Zeitschriften Verlag

Infrastruktur für eine ansonsten nicht ge-nutzte Systemumgebung aufzubauen.

Modifikationen durchdacht vornehmen

Über die Lebenszeit eines Systems oderder gesamten Anwendungslandschaft hin-weg werden im Rahmen von Wartungund Erweiterung kontinuierlich Änderun-gen vorgenommen. In vielen Fällen istmit diesen Modifikationen eine schlei-chende Erosion der Anwendungs- oder IT-Architektur verbunden, wenn man nichtgleichzeitig Refaktorisierungen durch-führt, um die Architektur den neuen Er-fordernissen und Randbedingungen anzu-passen und sie schlank und effizient zuhalten. Dadurch ergibt sich ein Trade-offzwischen Kosten für eine unmittelbareBehebung der entstehenden Defizite undder wachsenden technischen Schulden imFalle ihrer Nicht-Behebung.

Technische Schulden lassen sich nachihrem Einflussbereich und dem Ort ihresAuftretens kategorisieren. Von diesen Ka-tegorien hängt es ab, wie man mit diesenSchulden umgehen kann. Die einzelnenAnsätze werden im weiteren Verlaufdieses Artikels vorgestellt (siehe Kasten„Kategorien technischer Schulden“).

Auf der Suche nach den Ursachen

Gründe und Wege zur Aufnahme techni-scher Schulden können sehr unterschied-lich sein. Dabei muss man berücksichti-gen, dass technische Schulden a priorinichts Schlechtes sind, sondern eine Formvon Kredit darstellen, den man üblicher-weise mit Zinsen zurückzahlen muss.

Ein Weg zur Aufnahme technischerSchulden ist daher die bewusste Entschei-dung auf Unternehmensebene in Abwä-gung gegen andere Faktoren wie Time toMarket oder Entwicklungskosten. Je nachUnternehmensstruktur treffen das Pro-duktmanagement, die IT-Leitung oder dieGeschäftsführung solche Entscheidungen,beispielsweise, weil die Firma ein Markt-

fenster für ein bestimmtes Angebot nurdann erreichen kann, wenn sie die IT-Un-terstützung dafür schnell und an internenStandards vorbei bereitstellt.

In vielen anderen Fällen nehmen Un-ternehmen technische Schulden aus Unwissenheit auf. Dies geschieht bei-spielsweise bei einer dezentralen Un -ternehmensstruktur mit autonomer IT-Entwicklung, in der Standards oder dieArchitekturlandschaft nicht hinreichenddokumentiert oder forciert werden. Eintypischer Fall ist eine dezentrale Ent-wicklung durch einen Produktbereich,der unternehmensinterne Standards nichtkennt und dadurch ein Produkt entwi-ckelt, das sich nicht gut in die Anwen-dungslandschaft einfügt.

In anderen Situationen werden techni-sche Schulden durch U-Boot-Entschei-dungen oder Umgehen von Standardsund Best Practices für Integrationsme-chanismen oder Tests bewusst in Kaufgenommen. Dies kann die explizite Ent-scheidung eines lokalen Sponsors sein –typisch beispielsweise bei einer dezen-tralen Entwicklung im Produktbereich,die „schnell sein möchte, ohne sich durchzentrale Standards ausbremsen zu las-sen“. Ein anderes Beispiel ist, dass dasProjektteam bewusst eine genommeneReduktion der Produktqualität hinnimmt,um Projekttermine einzuhalten, ohne dassder lokale Sponsor des Projekts oder ei-ne übergeordnete Instanz einen explizi-ten Beschluss gefasst hätte.

Technische Schulden entstehen auch –Stichwort technisches Kuckucksei –, wenn

es nach dem Zukauf eines Unterneh-mens oder eines Merger gilt, Kernsyste-me der übernommenen Firma in die An-wendungslandschaft zu integrieren, dieeigenen Standards in puncto Technolo-gie, Qualität oder bestimmter nichtfunk-tionaler Eigenschaften wie Verfügbarkeitet cetera widersprechen, zu deren Ein-satz es aber aus wirtschaftlichen Gründenkeine Alternative gibt oder die sogar dieeigentliche Motivation für die Übernah-me darstellen. Auf ähnliche Weise kön-nen sich technische Schulden durch denEinkauf eines Off-the-Shelf-Software-produkts ergeben, bei dem nicht alle Ei-genschaften bekannt sind oder das zumZeitpunkt des Erwerbs noch verborgeneDefizite aufweist.

Wie man technische Schulden analysiert

Bezüglich des Umgangs mit technischenSchulden auf der Ebene der Unterneh-mensarchitektur muss man zwei Sze -narien unterscheiden: die erstmalige Be-standsaufnahme der technischen Schuldeninnerhalb der Unternehmenslandschaftsowie den Umgang damit im kontinuier-lichen Projektportfoliomanagement.

Bei der erstmaligen Bestandsauf -nahme muss eine systematische Unter-suchung der Anwendungslandschaft aufDefizite erfolgen. Dazu empfiehlt es sich,analog zur in ISO/IECˇ25040:2011 [b]vorgeschlagenen Vorgehensweise zu-nächst die Untersuchungsschwerpunktezu bestimmen, beispielsweise die Ge-brauchstauglichkeit von Anwendungen,ihre Wartbarkeit, Compliance mit inter-nen Standards, aber auch vermutete Pro-blemfelder in der Unternehmensarchitek-tur. Ergebnis dieser Untersuchung kannbeispielsweise eine Heatmap wie in Ab-bildungˇ1 sein, die Defizite der Unterneh-mensarchitektur selbst sowie solche ein-zelner Anwendungen aufzeigt.

Im eigentlichen Projektgeschäft mussdas Management technischer Schulden indie Prozesse einbezogen werden. Grund-lage für die Betrachtung dieser Schuldenauf Anwendungsebene sind die analyti-sche Qualitätssicherung sowie eine Mo-netarisierung, die es ermöglicht, eine re-flektierte Entscheidung zu treffen [1].Unter Monetarisierung versteht man eineKostenbewertung der Beseitigung bezie-hungsweise Nicht-Beseitigung der techni-schen Schulden [c]. Die 25000er-ISO-Normen [d] bieten den Rahmen zurAusrichtung dieses Steuerungsprozesses,konkrete Qualitätsmodelle wie SQALE [e]helfen bei der Ausgestaltung, und die

#$% iX #$/%$#%

REPORT | SOFTWAREPROJEKTE

Wartbarkeit Bedienbarkeit Zuverlässigkeit Performance Machbarkeit

Anwendung A

Anwendung B

Anwendung C

Datenkreislauf

IT-Architektur

& Risiken vorhanden (risk) & Risiken adressiert (non-risk) ' unkritisch & Sensibilität (sensitivity point) & Zielkonflikt (trade-off-point)

Eine Heatmap zeigt Defizite in der Anwendungslandschaft (Abb.ˇ1).

Systemarchitektur/Infrastruktur

Info

rmat

ions

-ar

chite

ktur

Anwendungs-architektur

funktionaleArchitektur

Die wesentlichen Sichten der Unterneh-mensarchitektur helfen, den Überblick zubehalten (Abb.ˇ2).

ix.1012.098-104 10.09.12 16:32 Seite 102

© Copyright by Heise Zeitschriften Verlag

zugehörigen Tools unterstützen die Mes-sung der Qualität sowie die Monetari -sierung der betrachteten technischenSchulden.

Auf der Ebene der Unternehmensar-chitektur sind eine analytische Qualitäts-sicherung und Steuerung aus vielfältigenGründen ungleich schwieriger. Die An-wendungslandschaft ist im Regelfall hete-rogen. Während eine einzelne Anwendungtypischerweise nur eine oder wenige un-terschiedliche Programmiersprachen be-ziehungsweise Technologien nutzt, ent-hält die Anwendungslandschaft in derRegel viele unterschiedliche Komponen-ten, in denen – wenn überhaupt – ver-schiedene Werkzeuge die Qualitätssiche-rung unterstützen. Dies erschwert einedurchgängige Verwendung von Metrikenmit einheitlicher Bedeutung. Zudem sinddie Indikatoren beziehungsweise Steue-rungsgrößen für technische Schulden aufder Ebene der Unternehmensarchitekturnormalerweise nicht automatisiert zu er-fassen.

Zwar ist eine unternehmensweite ana-lytische Qualitätssicherung auf der Ebe-ne der Anwendungslandschaft, die alleSysteme einschließt, aus diesen Gründen

kaum realistisch. Dennoch bieten vieleUmgebungen geeignete Stellen, an de-nen sich die vorhandene Infrastrukturnutzen lässt, um diesbezüglich relevanteErkenntnisse zu erhalten – beispielswei-se Log-Dateien der Datenlade- und Ent-lade-Jobs in Mainframe-Umgebungen,Reports über die Nutzung von ESBs(Enterprise Service Bus) oder EAM-Infra-strukturen (Enterprise-Architecture-Ma-nagement) et cetera. Diese Daten lassenRückschlüsse über den Informations-fluss zwischen den Anwendungen zuund können mit relativ geringem Auf-wand automatisch ausgewertet werden.Auf diese Weise erkennt man beispiels-weise Verletzungen der Soll-Anwen-dungsarchitektur.

Konstruktive Qualitäts -sicherung durch EAM

Konstruktive Qualitätssicherung auf derEbene der Anwendungslandschaft istmaßgeblich geprägt durch Architektur-Governance [f] und Enterprise Archi-tecture Management. Frameworks wieTOGAF [g], das Zachman-Framework

[h], PEAF [i] und COBIT [j] bieten Her -angehensweisen für eine effektive Auf-arbeitung und planerische Gestaltungder IT-Unternehmensarchitektur. Aller-dings sind sie kein Allheilmittel, und ihreVerbreitung insbesondere in mittelstän-dischen Unternehmen ist eher lücken-haft [2].

Glücklicherweise sind die Etablie-rung eines formalen Enterprise-Archi-tecture-Management und die flächende-ckende Einführung eines komplexenEA-Frameworks keine Voraussetzungdafür, technische Schulden innerhalb derUnternehmensarchitektur beherrschbarzu machen. Entscheidend ist, ein Be-wusstsein für die EA-Standards und ihreBedeutung im Unternehmen zu schaffenund eine Community von Architekten zuetablieren, die die Standards aktiv in ih-re Projekte einfließen lassen. Der Ein-satz von EAM-Instrumenten kann dabeiganz pragmatisch erfolgen.

Generell bietet die Unternehmensar-chitektur eine Grundlage für die Planungder künftigen IT-Landschaft mit ihrenPlattformen und Anwendungen. Einevereinfachte Darstellung der Unterneh-mensarchitektur, wie sie Abbildungˇ2

iX 10/2012 103

ix.1012.098-104 10.09.12 16:32 Seite 103

© Copyright by Heise Zeitschriften Verlag

zeigt, sollte zumindest folgende Sichtenenthalten:–ˇAus der Business-Perspektive lassensich die groben funktionalen Blöcke derUnternehmensarchitektur beschreiben.–ˇDie Anwendungsarchitektur enthält dieSysteme, die in ihrer Gesamtheit die be-nötigten Funktionen erbringen, sowie ih-re Schnittstellen untereinander.–ˇEinen Überblick über die für das Unter-nehmen relevanten Informationsarten, dieInformationshoheit und -verwendung gibtdie Informationsarchitektur.–ˇDie Systemarchitektur beschreibt dietechnische Abbildung der Anwendungenauf konkrete Hardware.

Zwischen Homogenität undHeterogenität

Den wichtigsten Beitrag leisten in diesemZusammenhang eine klare Zielvorstel-lung und eine damit verbundene Strate-gie für die Unternehmensarchitektur, diedie Ausrichtung der IT-Anwendungsland-schaft bestimmt und Standards vorgibt,die als Messlatte für die Qualität ausSicht der umgebenden Anwendungsland-schaft – also die Nutzungsqualität nachISO 25010 – herangezogen werden kön-nen. Diese Vorgaben und Standards mün-den implizit oder explizit in ein Qualitäts-modell für die Unternehmensarchitektur,in dem sie konkretisiert und auf die Ebe-ne der einzelnen Anwendung herunter -gebrochen werden.

Damit definiert man die Anforderun-gen, die, bezogen auf die einzelne An-wendung, wichtig für ihre Integrationund das nahtlose Einfügen in die gesam-te Anwendungslandschaft sind. Erfüllteine Applikation diese Anforderungenund weist keine gravierenden Defizitegegenüber dem für sie gültigen Quali-tätsmodell auf, verursacht sie keine tech-

nischen Schulden im Kontext der An-wendungslandschaft.

Eine der wichtigsten Zielgrößen fürtechnische Schulden auf der Ebene derUnternehmensarchitektur ist die Homo-genität beziehungsweise Heterogenitätin der Anwendungslandschaft. Gemessenwird sie über die Zahl und den Schwe-regrad der Abweichungen der Anwen-dungen von den unternehmensinternenStandards sowie Vorgaben beispiels -weise bezüglich eingesetzter Technolo-gien und der Gestaltung der Unterneh-mensarchitektur.

Technische Schulden sollten moneta-risiert werden. Dabei sollte man die Kos-ten, die bei der Behebung der Schuldenanfallen, denen gegenüberstellen, die beider Nichtbehebung anfallen. Analog zurAnwendungsebene gilt das für die Ebe-ne der Unternehmensarchitektur; ent-sprechende Schritte müssen in die Go-vernance-Prozesse integriert werden, umdie Entstehung technischer Schulden alsBestandteil der Total Cost of Ownershipexplizit zu machen und eine dezidierteEntscheidung zum Umgang damit zu er-möglichen. Die Notwendigkeit dafür er-gibt sich schon aus der Tatsache, dass ausden technischen Schulden teilweise sub-stanzielle Geschäftsrisiken erwachsenkönnen, die es unter Kontrolle zu haltengilt. Durch die Monetarisierung werdendie Qualitätsdefizite mit Geld bewertet.Das ermöglicht eine Vergleichbarkeit unddadurch einen objektiven Umgang mitden Schulden.

Fazit

Sowohl auf der Ebene einzelner Soft-waresysteme als auch auf der von IT-Un-ternehmensarchitekturen entstehen tech-nische Schulden. Dabei ist zu beachten,dass auch ein bei separater Betrachtung

gutes System, das die geforderten Qua -litätseigenschaften erfüllt, substanzielletechnische Schulden verursachen kann,wenn man es im Rahmen der gesamtenUnternehmenslandschaft betrachtet.

Konsequenterweise müssen auch dieMaßnahmen zum Umgang mit den tech-nischen Schulden teilweise auf einzelneSysteme und partiell auf die gesamte Un-ternehmenslandschaft abzielen. Dafürspielen das Management der Unterneh-mensarchitektur und die damit verbunde-ne Architektur-Governance eine zentraleRolle. Wichtig ist ein expliziter und über-legter Umgang mit technischen Schulden,anstatt ihre Auswirkungen erst dann fest-zustellen, wenn die Entscheidungen schonlängst gefallen sind. (ka)

Dr. Georg Molter

ist Chief Information Officer der ZühlkeEngineering GmbH und berät Kunden beiUnternehmensarchitektur- und Transfor-mationsprojekten.

Matthias Kraaz

arbeitet bei der Zühlke EngineeringGmbH als Lead Software Architect. SeineSpezialgebiete sind Konstruktion und Test sicherheitskritischer und eingebette-ter Systeme.

Literatur

[1]ˇMatthias Kraaz; Vorsicht, Zinsen!;Softwarequalität und technische Schulden; iX 9/12, S.ˇ82

[2]ˇWolfgang Keller; IT-Unternehmens -architektur; Von der Geschäftsstrategiezur optimalen IT-Unterstützung;dpunkt.verlag, Heidelberg 2007

#$) iX #$/%$#%

REPORT | SOFTWAREPROJEKTE

[a] Application Technical Debt: A Data-Driven Approach to Balance Delivery Agility with Business Riskwww.castsoftware.com/campaigns/how-to-monetize-application-technical-debt

[b] ISO/IEC %*$)$:%$##; Systems and soft-ware engineering – Systems and softwareQuality Requirements and Evaluation(SQuaRE) – Evaluation processwww.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=(*+,*

[c] Israel Gat; Technical Debt on Your Balance Sheettheagileexecutive.com/%$$!/$!/%!/technical-debt-on-your-balance-sheet/

[d] Software Engineering – Software product Quality Requirements and Evaluation(SQuaRE) – Guide to SQuaREwww.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=(*,"(

[e] SQALE (Software Quality Assessment based on Lifecycle Expectations)sqale.org

[f] IT-Governancede.wikipedia.org/wiki/IT-Governance

[g] TOGAFwww.togaf.org

[h] Zachmanwww.zachman.com/about-the-zachman-framework

[i] Pragmatic EAwww.pragmaticea.com

[j] COBITˇ*: A Business Framework for the Governance and Management of Enterprise ITwww.isaca.org/cobit/pages/default.aspx

Onlinequellen

Alle Links: www.ix.de/ix!"!##$% x

ix.1012.098-104 10.09.12 16:32 Seite 104

© Copyright by Heise Zeitschriften Verlag