Your SlideShare is downloading. ×
ix.1012.098-104 10.09.12 16:32 Seite 98            REPORT | SOFTWAREPROJEKTE            Technische Schulden in der Unterne...
ix.1012.098-104 10.09.12 16:32 Seite 100            REPORT | SOFTWAREPROJEKTE                Technische Schulden können ab...
ix.1012.098-104 10.09.12 16:32 Seite 102            REPORT | SOFTWAREPROJEKTE                                        Wartb...
zugehörigen Tools unterstützen die Mes-      kaum realistisch. Dennoch bieten viele             [h], PEAF [i] und COBIT [j...
ix.1012.098-104 10.09.12 16:32 Seite 104            REPORT | SOFTWAREPROJEKTE             Onlinequellen             [a] Ap...
Upcoming SlideShare
Loading in...5
×

Technische Schulden in der Unternehmensarchitektur (iX 10/2012)

613

Published on

Ob technisches Kuckucksei oder monolithische Strukturen eines Softwaresystems – die Ursachen für technische Schulden sind vielfältig. Sie können in der Anwendungslandschaft eines Unternehmens ein hohes Risiko darstellen.
Artikel in der iX10/2012 von Matthias Kraaz und Georg Molter.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
613
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Technische Schulden in der Unternehmensarchitektur (iX 10/2012)"

  1. 1. ix.1012.098-104 10.09.12 16:32 Seite 98 REPORT | SOFTWAREPROJEKTE Technische Schulden in der Unternehmensarchitektur Lieber sparen als zahlen Georg Molter, Matthias Kraaz Ob technisches Beispiele stammen aus Beratungsman- daten für mittelständische Unternehmen Kuckucksei oder mono- mit 400 bis 1200 Mitarbeitern. lithische Strukturen eines In den meisten IT-Anwendungsland- schaften findet man suboptimale, schnell Softwaresystems – die Ursachen für technische Schulden „zusammengezimmerte“ Lösungen vor. sind vielfältig. Sie können in der Anwendungslandschaft Sie weisen bestimmte sich wiederholende und im Unternehmen häufig wohlbekann- eines Unternehmens ein hohes Risiko darstellen. te Defizite auf, weil die Verantwortlichen bei der Entwicklung den Schwerpunkt auf Time to Market gelegt und wesentliche T echnische Schulden sind Defizite Typische Problemfelder sind eine unnötig Eigenschaften wie Wartbarkeit, Adminis- in Anwendungen oder in der An- hohe Komplexität der IT-Landschaft oder trierbarkeit, Skalierbarkeit, Effizienz oder wendungslandschaft eines Unter- eine erhöhte Heterogenität der eingesetz- Gebrauchstauglichkeit nicht angemessen nehmens, deren Fortbestehen ein gravie- ten Technologien. Ein erster Artikel [1] berücksichtigt haben. rendes Risiko für die Firma darstellt oder hat bereits den Begriff der technischen Ebenso häufig trifft man Anwendungen die Wartung oder Weiterentwicklung sub- Schulden genauer erläutert und verschie- an, die Unternehmensstandards bezüglich stanziell beeinträchtigt. Laut einer Studie dene Modelle vorgestellt, die dabei hel- Plattformen, Programmiersprachen, Aus- von CAST Software [a] werden die tech- fen können, solche Schulden zu vermei- tauschformaten et cetera missachten. Sol- nischen Schulden für die 288 Anwendun- den beziehungsweise gering zu halten che Verletzungen führen zu einer höheren gen in der CAST-Analysedatenbank mit und so die Softwarequalität zu gewähr- Heterogenität der eingesetzten Techno- im Schnitt 374 KLOC (1000 Lines of leisten. logien als nötig und damit insgesamt zu Code) – defensiv geschätzt – je Anwen- einer höheren Komplexität der IT-Land- dung auf mindestens 1ˇMillion US-$ be- schaft. Es werden mehr Systeme betrie- ziffert. Die Realität sieht ben und mehr Techniken eingesetzt als Es gibt viele Ursachen, die zur Auf- traurig aus nötig beziehungsweise gewünscht. Da- nahme technischer Schulden führen kön- durch ist das erforderliche Know-how nen. Sie entstehen sowohl auf der Ebene Der vorliegende Artikel stellt typische breiter gestreut, und der Aufwand für die einzelner Softwaresysteme, als auch auf Kategorien technischer Schulden vor. Die Entwicklung sowie für Wartung und Be- der ganzer IT-Anwendungslandschaften. in den folgenden Abschnitten skizzierten trieb steigt. 98 iX 10/2012 © Copyright by Heise Zeitschriften Verlag FA-241, 2012
  2. 2. ix.1012.098-104 10.09.12 16:32 Seite 100 REPORT | SOFTWAREPROJEKTE Technische Schulden können aber der Komplexität durch Separation of Con- auch die Anwendungslandschaft an sich cerns zu einer noch höheren Komplexi- Kategorien betreffen; die Defizite stecken dann in tät und einer noch eingeschränkteren Mechanismen oder Designprinzipien und Wartbarkeit. technischer Schulden resultieren nicht unmittelbar aus Eigen- In einer ebenfalls häufig anzutreffen- schnelle Lösungen schaften einer einzelnen Applikation. Ty- den Konstellation ändert sich die Daten- pische Beispiele sind Punkt-zu-Punkt- hoheit innerhalb der Anwendungsland- Heterogenität Schnittstellen zwischen Anwendungen in schaft täglich routinemäßig mit der monolithische Strukturen größerer Zahl oder enge funktionale Ab- Tageszeit. Während des Arbeitstages ist hängigkeiten, die die Anwendungsland- ein Dialogsystem führend, in der Nacht Applikationsschichten um Legacy-Systeme schaft insgesamt monolithisch werden wechselt die Datenhoheit auf andere Sys- wechselnde Datenhoheit lassen und es nahezu unmöglich machen, teme, die Batch-Verarbeitungsschritte enge Kopplung durch gemeinsame einzelne Systeme separat weiterzuentwi- und Verdichtungen durchführen. Das Datenbank ckeln und produktiv zu setzen. Daraus er- geht so lange gut, wie die „Nachtstun- geben sich die in vielen Unternehmen be- den“ zum Ausführen der Batch-Prozesse Vermischung operativer und dispositiver kannten Gesamt-Releases, von denen ausreichen. Wird die Systemlandschaft Datenhaltung unter großen Mühen pro Jahr zwei oder zum ersten Mal auch Anwendern in All-in-one-Middleware drei getestet und produktiv gesetzt wer- Amerika oder Fernost zur Verfügung ge- technisches Kuckucksei den können. Die Vorlaufzeiten vom Er- stellt oder werden Rufe nach einer Near- kennen des Bedarfs an neuer Funktiona- Realtime-Aktualität der erstellten Aufbe- Maintenance und Erweiterungen lität bis hin zu ihrem Deployment liegen reitungen und der Reports laut, treten ohne Anpassung der Struktur dann nicht selten bei mindestens neun Konflikte auf. Monaten. Ein anderes häufiges Muster ist der unkontrollierte, direkte Zugriff auf die Gesamtverfügbarkeit der benötigten An- Datenbanken anderer Anwendungen. Da- wendungen beeinträchtigt. Altes wird nicht immer durch entsteht eine enge Kopplung zwi- über Bord geworfen schen den beteiligten Systemen, weil sie sich von der Datenbankstruktur als ei- Alles unter einen Hut Andere technische Schulden entstehen, nem Implementierungsdetail abhängig bringen müssen weil Legacy-Anwendungen erhalten wer- machen. den müssen. Auf typische Beispiele tra- Ebenfalls häufig findet man die „All-in- fen die Autoren in einem Unternehmen one“-Applikation oder -Middleware, die aus dem Bereich Finanzdienstleistungen Abkürzungen können in einem vorhandenen System viele ver- sowie einem aus dem Logistiksektor. Risiken bergen schiedene Funktionen kombiniert, die in- Deren zentrale Mainframe-Applikatio- haltlich nicht direkt miteinander ver- nen lassen sich über die Jahre hinweg Des Öfteren nutzen Entwickler gern in Re- knüpft sind. Wird eine neue Funktion zunehmend schlechter warten. Das liegt porting-Datenbanken und in Data Ware- benötigt, gelangt sie häufig ins Aufgaben- zum einen an der steigenden Komplexi- houses vorhandene Daten als schnellen buch des bereits laufenden Systems oder tät, zum anderen aber auch daran, dass Input für operative Anwendungen. Die Projekts, das den geringsten Widerstand das für Wartung und Weiterentwicklung hierdurch aufgenommenen technischen leistet, obwohl sie dort nicht unbedingt benötigte Know-how immer knapper Schulden bestehen darin, dass operative hineinpasst. Auf diese Weise entstehen wird. Lange Zeit hat man daher neue Systeme, die hoch verfügbar sein müs- wiederum monolithische Service-Blöcke, Funktionen immer häufiger nicht mehr sen, selbst von Systemen mit niedrigeren die das Prinzip der Separation of Con- im Kernsystem ergänzt, sondern in vor- Verfügbarkeitsgarantien abhängig sind. cerns verletzen und dadurch Wartbarkeit gelagerten Applikationen realisiert. Da- Um ihre Leistung zu erbringen, beziehen und die Möglichkeit zum separaten De- durch ergeben sich für die Anwender sie Daten von dispositiven Systemen, de- ployment beeinträchtigen. Systembrüche, und die engen Abhängig- ren Service Level Agreements normaler- Nicht selten kommt es vor, dass ein keiten der betroffenen Systeme unterein- weise etwas laxer ausfallen. Es ist nahe- bei separater Betrachtung gutes System, ander führen statt zu einer Reduzierung liegend, dass diese Konstellation die das die geforderten Qualitätseigenschaf- ten erfüllt, im Rahmen der Betrachtung der gesamten Unternehmenslandschaft substanzielle technische Schulden dar- x-TRACT stellt. Ein Beispiel ist ein Unternehmen G Technische Schulden sind Defizite in der Anwendungslandschaft eines Unterneh- mit einer weitgehend homogenen .NET- mens, deren Fortbestehen ein gravierendes Risiko für das Unternehmen darstellt Landschaft, für das ein Dienstleister eine oder die Wartung oder Weiterentwicklung substanziell beeinträchtigt. Java-Anwendung maßgeschneidert ent- wickelt und betrieben hat. Über kurz G Bei der Kontrolle der technischen Schulden spielen das Management der Unter- oder lang sah sich das Unternehmen da- nehmensarchitektur und die damit verbundene IT-Governance eine zentrale zu gezwungen, die Weiterentwicklung Rolle. und den Betrieb dieser Software selbst G Die Mechanismen zur Kontrolle der Schulden lassen sich so anpassen, dass sie zu übernehmen – und war dann damit auch für den Einsatz in mittelständischen Unternehmen geeignet sind. konfrontiert, für ein einzelnes, aber fachlich zentrales System die Entwick- lungs- und Betriebskompetenz sowie die 100 iX 10/2012 © Copyright by Heise Zeitschriften Verlag
  3. 3. ix.1012.098-104 10.09.12 16:32 Seite 102 REPORT | SOFTWAREPROJEKTE Wartbarkeit Bedienbarkeit Zuverlässigkeit Performance Machbarkeit es nach dem Zukauf eines Unterneh- Anwendung A mens oder eines Merger gilt, Kernsyste- me der übernommenen Firma in die An- Anwendung B wendungslandschaft zu integrieren, die Anwendung C eigenen Standards in puncto Technolo- Datenkreislauf gie, Qualität oder bestimmter nichtfunk- IT-Architektur tionaler Eigenschaften wie Verfügbarkeit et cetera widersprechen, zu deren Ein- satz es aber aus wirtschaftlichen Gründen 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). keine Alternative gibt oder die sogar die eigentliche Motivation für die Übernah- Infrastruktur für eine ansonsten nicht ge- fenster für ein bestimmtes Angebot nur me darstellen. Auf ähnliche Weise kön- nutzte Systemumgebung aufzubauen. dann erreichen kann, wenn sie die IT-Un- nen sich technische Schulden durch den terstützung dafür schnell und an internen Einkauf eines Off-the-Shelf-Software- Standards vorbei bereitstellt. produkts ergeben, bei dem nicht alle Ei- Modifikationen In vielen anderen Fällen nehmen Un- genschaften bekannt sind oder das zum durchdacht vornehmen ternehmen technische Schulden aus Zeitpunkt des Erwerbs noch verborgene Unwissenheit auf. Dies geschieht bei- Defizite aufweist. Über die Lebenszeit eines Systems oder spielsweise bei einer dezentralen Un- der gesamten Anwendungslandschaft hin- ternehmensstruktur mit autonomer IT- weg werden im Rahmen von Wartung Entwicklung, in der Standards oder die Wie man technische und Erweiterung kontinuierlich Änderun- Architekturlandschaft nicht hinreichend Schulden analysiert gen vorgenommen. In vielen Fällen ist dokumentiert oder forciert werden. Ein mit diesen Modifikationen eine schlei- typischer Fall ist eine dezentrale Ent- Bezüglich des Umgangs mit technischen chende Erosion der Anwendungs- oder IT- wicklung durch einen Produktbereich, Schulden auf der Ebene der Unterneh- Architektur verbunden, wenn man nicht der unternehmensinterne Standards nicht mensarchitektur muss man zwei Sze- gleichzeitig Refaktorisierungen durch- kennt und dadurch ein Produkt entwi- narien unterscheiden: die erstmalige Be- führt, um die Architektur den neuen Er- ckelt, das sich nicht gut in die Anwen- standsaufnahme der technischen Schulden fordernissen und Randbedingungen anzu- dungslandschaft einfügt. innerhalb der Unternehmenslandschaft passen und sie schlank und effizient zu In anderen Situationen werden techni- sowie den Umgang damit im kontinuier- halten. Dadurch ergibt sich ein Trade-off sche Schulden durch U-Boot-Entschei- lichen Projektportfoliomanagement. zwischen Kosten für eine unmittelbare dungen oder Umgehen von Standards Bei der erstmaligen Bestandsauf- Behebung der entstehenden Defizite und und Best Practices für Integrationsme- nahme muss eine systematische Unter- der wachsenden technischen Schulden im chanismen oder Tests bewusst in Kauf suchung der Anwendungslandschaft auf Falle ihrer Nicht-Behebung. genommen. Dies kann die explizite Ent- Defizite erfolgen. Dazu empfiehlt es sich, Technische Schulden lassen sich nach scheidung eines lokalen Sponsors sein – analog zur in ISO/IECˇ25040:2011 [b] ihrem Einflussbereich und dem Ort ihres typisch beispielsweise bei einer dezen- vorgeschlagenen Vorgehensweise zu- Auftretens kategorisieren. Von diesen Ka- tralen Entwicklung im Produktbereich, nächst die Untersuchungsschwerpunkte tegorien hängt es ab, wie man mit diesen die „schnell sein möchte, ohne sich durch zu bestimmen, beispielsweise die Ge- Schulden umgehen kann. Die einzelnen zentrale Standards ausbremsen zu las- brauchstauglichkeit von Anwendungen, Ansätze werden im weiteren Verlauf sen“. Ein anderes Beispiel ist, dass das ihre Wartbarkeit, Compliance mit inter- dieses Artikels vorgestellt (siehe Kasten Projektteam bewusst eine genommene nen Standards, aber auch vermutete Pro- „Kategorien technischer Schulden“). Reduktion der Produktqualität hinnimmt, blemfelder in der Unternehmensarchitek- um Projekttermine einzuhalten, ohne dass tur. Ergebnis dieser Untersuchung kann der lokale Sponsor des Projekts oder ei- beispielsweise eine Heatmap wie in Ab- Auf der Suche nach ne übergeordnete Instanz einen explizi- bildungˇ1 sein, die Defizite der Unterneh- den Ursachen ten Beschluss gefasst hätte. mensarchitektur selbst sowie solche ein- Technische Schulden entstehen auch – zelner Anwendungen aufzeigt. Gründe und Wege zur Aufnahme techni- Stichwort technisches Kuckucksei –, wenn Im eigentlichen Projektgeschäft muss scher Schulden können sehr unterschied- das Management technischer Schulden in lich sein. Dabei muss man berücksichti- die Prozesse einbezogen werden. Grund- gen, dass technische Schulden a priori funktionale lage für die Betrachtung dieser Schulden nichts Schlechtes sind, sondern eine Form auf Anwendungsebene sind die analyti- Informations- Architektur architektur von Kredit darstellen, den man üblicher- sche Qualitätssicherung sowie eine Mo- weise mit Zinsen zurückzahlen muss. Anwendungs- netarisierung, die es ermöglicht, eine re- Ein Weg zur Aufnahme technischer architektur flektierte Entscheidung zu treffen [1]. Schulden ist daher die bewusste Entschei- Unter Monetarisierung versteht man eine dung auf Unternehmensebene in Abwä- Kostenbewertung der Beseitigung bezie- gung gegen andere Faktoren wie Time to Systemarchitektur/ hungsweise Nicht-Beseitigung der techni- Market oder Entwicklungskosten. Je nach Infrastruktur schen Schulden [c]. Die 25000er-ISO- Unternehmensstruktur treffen das Pro- Normen [d] bieten den Rahmen zur duktmanagement, die IT-Leitung oder die Die wesentlichen Sichten der Unterneh- Ausrichtung dieses Steuerungsprozesses, Geschäftsführung solche Entscheidungen, mensarchitektur helfen, den Überblick zu konkrete Qualitätsmodelle wie SQALE [e] beispielsweise, weil die Firma ein Markt- behalten (Abb.ˇ2). helfen bei der Ausgestaltung, und die 102 iX 10/2012 © Copyright by Heise Zeitschriften Verlag
  4. 4. zugehörigen Tools unterstützen die Mes- kaum realistisch. Dennoch bieten viele [h], PEAF [i] und COBIT [j] bieten Her-sung der Qualität sowie die Monetari- Umgebungen geeignete Stellen, an de- angehensweisen für eine effektive Auf-sierung der betrachteten technischen nen sich die vorhandene Infrastruktur arbeitung und planerische GestaltungSchulden. nutzen lässt, um diesbezüglich relevante der IT-Unternehmensarchitektur. Aller- Auf der Ebene der Unternehmensar- Erkenntnisse zu erhalten – beispielswei- dings sind sie kein Allheilmittel, und ihrechitektur sind eine analytische Qualitäts- se Log-Dateien der Datenlade- und Ent- Verbreitung insbesondere in mittelstän-sicherung und Steuerung aus vielfältigen lade-Jobs in Mainframe-Umgebungen, dischen Unternehmen ist eher lücken-Gründen ungleich schwieriger. Die An- Reports über die Nutzung von ESBs haft [2].wendungslandschaft ist im Regelfall hete- (Enterprise Service Bus) oder EAM-Infra- Glücklicherweise sind die Etablie-rogen. Während eine einzelne Anwendung strukturen (Enterprise-Architecture-Ma- rung eines formalen Enterprise-Archi-typischerweise nur eine oder wenige un- nagement) et cetera. Diese Daten lassen tecture-Management und die flächende-terschiedliche Programmiersprachen be- Rückschlüsse über den Informations- ckende Einführung eines komplexenziehungsweise Technologien nutzt, ent- fluss zwischen den Anwendungen zu EA-Frameworks keine Voraussetzunghält die Anwendungslandschaft in der und können mit relativ geringem Auf- dafür, technische Schulden innerhalb derRegel viele unterschiedliche Komponen- wand automatisch ausgewertet werden. Unternehmensarchitektur beherrschbarten, in denen – wenn überhaupt – ver- Auf diese Weise erkennt man beispiels- zu machen. Entscheidend ist, ein Be-schiedene Werkzeuge die Qualitätssiche- weise Verletzungen der Soll-Anwen- wusstsein für die EA-Standards und ihrerung unterstützen. Dies erschwert eine dungsarchitektur. Bedeutung im Unternehmen zu schaffendurchgängige Verwendung von Metriken und eine Community von Architekten zumit einheitlicher Bedeutung. Zudem sind etablieren, die die Standards aktiv in ih-die Indikatoren beziehungsweise Steue- Konstruktive Qualitäts- re Projekte einfließen lassen. Der Ein-rungsgrößen für technische Schulden auf sicherung durch EAM satz von EAM-Instrumenten kann dabeider Ebene der Unternehmensarchitektur ganz pragmatisch erfolgen.normalerweise nicht automatisiert zu er- Konstruktive Qualitätssicherung auf der Generell bietet die Unternehmensar-fassen. Ebene der Anwendungslandschaft ist chitektur eine Grundlage für die Planung Zwar ist eine unternehmensweite ana- maßgeblich geprägt durch Architektur- der künftigen IT-Landschaft mit ihrenlytische Qualitätssicherung auf der Ebe- Governance [f] und Enterprise Archi- Plattformen und Anwendungen. Einene der Anwendungslandschaft, die alle tecture Management. Frameworks wie vereinfachte Darstellung der Unterneh-Systeme einschließt, aus diesen Gründen TOGAF [g], das Zachman-Framework mensarchitektur, wie sie Abbildungˇ2iX 10/2012 103 © Copyright by Heise Zeitschriften Verlag
  5. 5. ix.1012.098-104 10.09.12 16:32 Seite 104 REPORT | SOFTWAREPROJEKTE Onlinequellen [a] Application Technical Debt: [c] Israel Gat; Technical Debt on [f] IT-Governance A Data-Driven Approach to Balance Your Balance Sheet de.wikipedia.org/wiki/IT-Governance Delivery Agility with Business Risk theagileexecutive.com/2009/09/29/ [g] TOGAF www.castsoftware.com/campaigns/ technical-debt-on-your-balance-sheet/ www.togaf.org how-to-monetize-application- [d] Software Engineering – Software product [h] Zachman technical-debt Quality Requirements and Evaluation www.zachman.com/about-the-zachman- [b] ISO/IEC 25040:2011; Systems and soft- (SQuaRE) – Guide to SQuaRE framework ware engineering – Systems and software www.iso.org/iso/iso_catalogue/ [i] Pragmatic EA Quality Requirements and Evaluation catalogue_tc/catalogue_detail.htm? www.pragmaticea.com csnumber=35683 (SQuaRE) – Evaluation process [j] COBITˇ5: A Business Framework www.iso.org/iso/iso_catalogue/ [e] SQALE (Software Quality Assessment for the Governance and Management catalogue_tc/catalogue_detail.htm? based on Lifecycle Expectations) of Enterprise IT csnumber=35765 sqale.org www.isaca.org/cobit/pages/default.aspx zeigt, sollte zumindest folgende Sichten nischen Schulden im Kontext der An- gutes System, das die geforderten Qua- enthalten: wendungslandschaft. litätseigenschaften erfüllt, substanzielle –ˇAus der Business-Perspektive lassen Eine der wichtigsten Zielgrößen für technische Schulden verursachen kann, sich die groben funktionalen Blöcke der technische Schulden auf der Ebene der wenn man es im Rahmen der gesamten Unternehmensarchitektur beschreiben. Unternehmensarchitektur ist die Homo- Unternehmenslandschaft betrachtet. –ˇDie Anwendungsarchitektur enthält die genität beziehungsweise Heterogenität Konsequenterweise müssen auch die Systeme, die in ihrer Gesamtheit die be- in der Anwendungslandschaft. Gemessen Maßnahmen zum Umgang mit den tech- nötigten Funktionen erbringen, sowie ih- wird sie über die Zahl und den Schwe- nischen Schulden teilweise auf einzelne re Schnittstellen untereinander. regrad der Abweichungen der Anwen- Systeme und partiell auf die gesamte Un- –ˇEinen Überblick über die für das Unter- dungen von den unternehmensinternen ternehmenslandschaft abzielen. Dafür nehmen relevanten Informationsarten, die Standards sowie Vorgaben beispiels- spielen das Management der Unterneh- Informationshoheit und -verwendung gibt weise bezüglich eingesetzter Technolo- mensarchitektur und die damit verbunde- die Informationsarchitektur. gien und der Gestaltung der Unterneh- ne Architektur-Governance eine zentrale –ˇDie Systemarchitektur beschreibt die mensarchitektur. Rolle. Wichtig ist ein expliziter und über- technische Abbildung der Anwendungen Technische Schulden sollten moneta- legter Umgang mit technischen Schulden, auf konkrete Hardware. risiert werden. Dabei sollte man die Kos- anstatt ihre Auswirkungen erst dann fest- ten, die bei der Behebung der Schulden zustellen, wenn die Entscheidungen schon anfallen, denen gegenüberstellen, die bei längst gefallen sind. (ka) Zwischen Homogenität und der Nichtbehebung anfallen. Analog zur Heterogenität Anwendungsebene gilt das für die Ebe- Dr. Georg Molter ne der Unternehmensarchitektur; ent- Den wichtigsten Beitrag leisten in diesem sprechende Schritte müssen in die Go- ist Chief Information Officer der Zühlke Zusammenhang eine klare Zielvorstel- vernance-Prozesse integriert werden, um Engineering GmbH und berät Kunden bei lung und eine damit verbundene Strate- die Entstehung technischer Schulden als Unternehmensarchitektur- und Transfor- gie für die Unternehmensarchitektur, die Bestandteil der Total Cost of Ownership mationsprojekten. die Ausrichtung der IT-Anwendungsland- explizit zu machen und eine dezidierte schaft bestimmt und Standards vorgibt, Entscheidung zum Umgang damit zu er- Matthias Kraaz die als Messlatte für die Qualität aus möglichen. Die Notwendigkeit dafür er- Sicht der umgebenden Anwendungsland- gibt sich schon aus der Tatsache, dass aus arbeitet bei der Zühlke Engineering schaft – also die Nutzungsqualität nach den technischen Schulden teilweise sub- GmbH als Lead Software Architect. Seine ISO 25010 – herangezogen werden kön- stanzielle Geschäftsrisiken erwachsen Spezialgebiete sind Konstruktion und nen. Diese Vorgaben und Standards mün- können, die es unter Kontrolle zu halten Test sicherheitskritischer und eingebette- den implizit oder explizit in ein Qualitäts- gilt. Durch die Monetarisierung werden ter Systeme. modell für die Unternehmensarchitektur, die Qualitätsdefizite mit Geld bewertet. in dem sie konkretisiert und auf die Ebe- Das ermöglicht eine Vergleichbarkeit und Literatur ne der einzelnen Anwendung herunter- dadurch einen objektiven Umgang mit gebrochen werden. den Schulden. [1]ˇMatthias Kraaz; Vorsicht, Zinsen!; Damit definiert man die Anforderun- Softwarequalität und technische gen, die, bezogen auf die einzelne An- Schulden; iX 9/12, S.ˇ82 wendung, wichtig für ihre Integration Fazit [2]ˇWolfgang Keller; IT-Unternehmens- und das nahtlose Einfügen in die gesam- architektur; Von der Geschäftsstrategie te Anwendungslandschaft sind. Erfüllt Sowohl auf der Ebene einzelner Soft- zur optimalen IT-Unterstützung; eine Applikation diese Anforderungen waresysteme als auch auf der von IT-Un- dpunkt.verlag, Heidelberg 2007 und weist keine gravierenden Defizite ternehmensarchitekturen entstehen tech- gegenüber dem für sie gültigen Quali- nische Schulden. Dabei ist zu beachten, Alle Links: www.ix.de/ix1210098 x tätsmodell auf, verursacht sie keine tech- dass auch ein bei separater Betrachtung 104 iX 10/2012 © Copyright by Heise Zeitschriften Verlag

×