Auch wenn es viele unterschiedliche Definitionen und Messwerte für "Technical Debt" gibt, eines ist klar - diese verborgenen Kosten sind exponentiell angestiegen. Denn Wartungsarbeiten werden möglichst reduziert, da Entwicklungsteams gezwungen sind, immer kürzere Entwicklungszyklen einzuhalten und gleichzeitig mehr Funktionalität zu implementieren.
In dem Bericht "Measure and Manage Your IT Debt", illustriert Andy Kyte, Vice President und Partner von Gartner, das Risiko im Applikationsportfolio, welches durch eine Anhäufung von "Technical Debt" in den letzten zehn Jahren entstanden ist, in eindrucksvoller Weise.
Gartner geht davon aus, dass Fortune 2.000 Unternehmen und größere Organisationen im öffentlichen Bereich mit mehr als 200 Millionen US-Dollar an "Technical Debt" belastet sind und somit der Suche nach einer Lösung für "Technical Debt" im nächsten Jahrzehnt eine hohe Priorität eingeräumt werden muss.
CAST definiert "Technical Debt" als Kosten für die Lösung von strukturellen Qualitätsproblemen in einer Anwendung, die, wenn sie nicht behoben werden, mit hoher Wahrscheinlichkeit schwerwiegende Störungen verursachen und somit unternehmerische Risiken darstellen.
Zur objektiven Feststellung dieser Kosten haben wir bei CAST Appmarq entwickelt: eine Datenbank, welche Informationen über Größe, Komplexität und strukturelle Qualität von derzeit ca. 300 Anwendungen aus 75 IT-Unternehmen weltweit beinhaltet. Mit mehr als 8.000 Datenpunkten aus 27 verschiedenen Merkmalen verwendet CAST eine datenbasierte Methode zur Messung und Monetarisierung von
"Technical Debt" in einer Anwendung. Weitere Einzelheiten zu den Daten und Kalkulationen sind in dem Bericht CAST Worldwide Application Software Study - 2010 ausführlicher dargestellt.
Ein fundamentaler Bestandteil bei der Berechnung von "Technical Debt" sind sogenannte "violations". Diese Regelverletzungen entstehen, wenn eine Anwendung gegen eine oder mehrere Grundsätze qualitativ-hochwertiger Softwareentwicklung verstößt. Diese Verletzungen sind somit die eigentlichen Ursachen für Softwarekosten und -risiken: Mit anderen Worten, sie sind die grundlegende IT-Maßeinheit für strukturelle Qualität.
Aufgrund der erhobenen und ausgewerteten Daten in Appmarq nimmt CAST an, dass eine durchschnittliche Geschäftsanwendung mit einem
"Technical Debt" von mehr als einer Million US-Dollar belastet ist. Wenn die strukturelle Qualität in Dollar ausgedrückt wird, erhält sie eine Form, die auch für das "Business" verständlich und bewertbar ist. Dadurch ist diese mit anderen IT-Kosten und Investments vergleichbar und bietet eine fundierte Entscheidungsgrundlage.
Wann sollte "Technical Debt" erhoben werden? CAST empfiehlt, dies als integralen Bestandteil in die wiederkehrende Analyse Ihrer unternehmenskritischen Anwendungen aufzunehmen.
1. Zählen Sie die Anzahl der Verletzungen der strukturellen Qualität einmal pro Quartal und vergleichen Sie diese mit vorangegangenen Ergebnissen. Legen Sie einen automatisierten Prozess für die Messung der strukturellen Qualität einer Anwendung fest. Damit sind Sie in der Lage, die richtige Bewertung bezüglich Entwicklungsgeschwindigkeit, Anwendungsqualität und Business Value der Applikation vorzunehmen.
2. Setzen Sie ein "Quality Gate" auf. Definieren Sie Grenzwerte für die Anwendungsqualität und stellen Sie sicher, dass nur Applikationen die diese Grenzwerte einhalten, in den produktiven Betrieb übernommen werden. Dadurch können Sie die Qualitätsstandards klar Ihren unternehmensinternen Teams und externen Service Providern kommunizieren.
3. Stärken Sie Ihre Risikominimierungsprozesse. Integrieren Sie die Praxis der Messung von Verletzungen in Ihr Liefermodell, um Risiken zu vermeiden oder zu korrigieren, bevor sie Ihr "Technical Debt" erhöhen.
4. Beginnen Sie mit der Identifizierung der "violations" für alle neuen Releases. So stellen Sie sicher, dass zumindest keine kritischen Verletzungen hinzugefügt werden. Wenn das gewährleistet ist, beginnen Sie mit der Bereinigung der Historie.
Wenn das "Technical Debt" ermittelt wurde, stellen Sie dieses dem "Business Value" der Anwendung gegenüber, um zwischen Lieferagilität und Geschäftsrisiko abwägen zu können. Legen Sie einen angemessenen Schwellenwert für Ihr "Technical Debt" fest und überwachen Sie, wie sich Ihre kritischen Anwendungen gegenüber diesem Schwellenwert verhalten, um das richtige Gleichgewicht zwischen Agilität und Geschäftsrisiko beizubehalten, während sich IT- und Geschäftsanforderungen weiterentwickeln.
In dem Bericht "Measure and Manage Your IT Debt", illustriert Andy Kyte, Vice President und Partner von Gartner, das Risiko im Applikationsportfolio, welches durch eine Anhäufung von "Technical Debt" in den letzten zehn Jahren entstanden ist, in eindrucksvoller Weise.
Gartner geht davon aus, dass Fortune 2.000 Unternehmen und größere Organisationen im öffentlichen Bereich mit mehr als 200 Millionen US-Dollar an "Technical Debt" belastet sind und somit der Suche nach einer Lösung für "Technical Debt" im nächsten Jahrzehnt eine hohe Priorität eingeräumt werden muss.
CAST definiert "Technical Debt" als Kosten für die Lösung von strukturellen Qualitätsproblemen in einer Anwendung, die, wenn sie nicht behoben werden, mit hoher Wahrscheinlichkeit schwerwiegende Störungen verursachen und somit unternehmerische Risiken darstellen.
Zur objektiven Feststellung dieser Kosten haben wir bei CAST Appmarq entwickelt: eine Datenbank, welche Informationen über Größe, Komplexität und strukturelle Qualität von derzeit ca. 300 Anwendungen aus 75 IT-Unternehmen weltweit beinhaltet. Mit mehr als 8.000 Datenpunkten aus 27 verschiedenen Merkmalen verwendet CAST eine datenbasierte Methode zur Messung und Monetarisierung von
"Technical Debt" in einer Anwendung. Weitere Einzelheiten zu den Daten und Kalkulationen sind in dem Bericht CAST Worldwide Application Software Study - 2010 ausführlicher dargestellt.
Ein fundamentaler Bestandteil bei der Berechnung von "Technical Debt" sind sogenannte "violations". Diese Regelverletzungen entstehen, wenn eine Anwendung gegen eine oder mehrere Grundsätze qualitativ-hochwertiger Softwareentwicklung verstößt. Diese Verletzungen sind somit die eigentlichen Ursachen für Softwarekosten und -risiken: Mit anderen Worten, sie sind die grundlegende IT-Maßeinheit für strukturelle Qualität.
Aufgrund der erhobenen und ausgewerteten Daten in Appmarq nimmt CAST an, dass eine durchschnittliche Geschäftsanwendung mit einem
"Technical Debt" von mehr als einer Million US-Dollar belastet ist. Wenn die strukturelle Qualität in Dollar ausgedrückt wird, erhält sie eine Form, die auch für das "Business" verständlich und bewertbar ist. Dadurch ist diese mit anderen IT-Kosten und Investments vergleichbar und bietet eine fundierte Entscheidungsgrundlage.
Wann sollte "Technical Debt" erhoben werden? CAST empfiehlt, dies als integralen Bestandteil in die wiederkehrende Analyse Ihrer unternehmenskritischen Anwendungen aufzunehmen.
1. Zählen Sie die Anzahl der Verletzungen der strukturellen Qualität einmal pro Quartal und vergleichen Sie diese mit vorangegangenen Ergebnissen. Legen Sie einen automatisierten Prozess für die Messung der strukturellen Qualität einer Anwendung fest. Damit sind Sie in der Lage, die richtige Bewertung bezüglich Entwicklungsgeschwindigkeit, Anwendungsqualität und Business Value der Applikation vorzunehmen.
2. Setzen Sie ein "Quality Gate" auf. Definieren Sie Grenzwerte für die Anwendungsqualität und stellen Sie sicher, dass nur Applikationen die diese Grenzwerte einhalten, in den produktiven Betrieb übernommen werden. Dadurch können Sie die Qualitätsstandards klar Ihren unternehmensinternen Teams und externen Service Providern kommunizieren.
3. Stärken Sie Ihre Risikominimierungsprozesse. Integrieren Sie die Praxis der Messung von Verletzungen in Ihr Liefermodell, um Risiken zu vermeiden oder zu korrigieren, bevor sie Ihr "Technical Debt" erhöhen.
4. Beginnen Sie mit der Identifizierung der "violations" für alle neuen Releases. So stellen Sie sicher, dass zumindest keine kritischen Verletzungen hinzugefügt werden. Wenn das gewährleistet ist, beginnen Sie mit der Bereinigung der Historie.
Wenn das "Technical Debt" ermittelt wurde, stellen Sie dieses dem "Business Value" der Anwendung gegenüber, um zwischen Lieferagilität und Geschäftsrisiko abwägen zu können. Legen Sie einen angemessenen Schwellenwert für Ihr "Technical Debt" fest und überwachen Sie, wie sich Ihre kritischen Anwendungen gegenüber diesem Schwellenwert verhalten, um das richtige Gleichgewicht zwischen Agilität und Geschäftsrisiko beizubehalten, während sich IT- und Geschäftsanforderungen weiterentwickeln.
