Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Vorsicht Schuldenfalle – Was die IT aus der Fin...

Vorsicht Schuldenfalle – Was die IT aus der Finanzwelt lernen kann

Talk with Jörg Nitzsche about the technical debt metaphor. Slides in German.

Schulden machen ist leicht, zu leicht manchmal und ehe man sich versieht, hat man Mühe die Schuldenlast zurück zu zahlen. Ähnlich verhält es sich auch bei Softwarearchitektur. Ein "das fixen wir später" hier, "die Dokumentation ziehen wir nach der Abnahme nach" dort, ein kleiner Hack da, ein schnelles Feature dazu und schon sieht man sich einer degenerierten Software(architektur) gegenüber, die hohe Wartungskosten nach sich zieht und eine weitere Entwicklung nur bedingt zulässt.

Damit es nicht so weit kommt muss man sich der Schulden bewusst sein, die man durch manche Entscheidungen aufnimmt und muss den Schuldenberg im Griff behalten. Das gilt für traditionelle Softwareprojekte gleichermaßen wie für SOA- und BPM-Projekte.

In diesem Vortrag gehen wir auf verschiedene Arten technischer Schulden ein und zeigen Wege auf, wie man ihnen im Projektalltag begegnet.

Tammo van Lessen

May 14, 2014
Tweet

More Decks by Tammo van Lessen

Other Decks in Technology

Transcript

  1. Tammo van Lessen | InnoQ Dr. Jörg Nitzsche | T-Systems

    Vorsicht Schuldenfalle – Was die IT aus der Finanzwelt lernen kann
  2. Wer sind wir? Tammo van Lessen Senior Consultant bei innoQ

    SOA / BPM / Architektur / Web Apache Member und VP Apache ODE Dr. Jörg Nitzsche Senior Architect bei T-Systems EAM / SOA / BPM / Architektur
  3. Inhalt • Metaphern • Arten der Schulden • Was ist

    mit den Zinsen? • Wie verschulde ich mich? • Was muss ich über Schulden wissen? • Was tue ich bei drohender Insolvenz?
  4. Metaphern • Warum? – Helfen Dinge deutlich zu machen •

    Häufig verwendete Metaphern: – Haus = Applikation – Bebauungsplanung = Enterprise Architektur Management • Heute: – Natürliche Person = Applikation
  5. Natürliche Person • Spätestens seit Peter Zwegat wissen wir: –

    Personen verschulden sich, können die Schulden nicht tilgen und die Zinsen nicht bezahlen • Weitere Definition: – Schuldenlast = Kosten zur Problemlösung – Zinsen = Kosten mit der aktuellen Situation zu leben
  6. Technische Schulden • Metapher geprägt von Ward Cunningham '92 •

    Diskutiert von Martin Fowler & Steve McConnell • In der Praxis viel zu wenig ernst genommen
  7. Design & Architektur • Ungeeigneter Architekturstil • Falsche Wahl der

    Werkzeuge • Ignorieren von Konzernstandards • Zu viele Kompromisse und Workarounds • Frameworks „vergewaltigt“
  8. Code-Qualität • Hohe Anzahl von Ausfällen / Fehlern • Hohe

    Anzahl kritischer Bugs • Code-Metriken • Code-Duplizierung • Kein „clean code“ / SOLID
  9. Dokumentation • Wissen wird nicht dokumentiert. • Wissen wird nicht

    geteilt. • Wissen wird nicht verteilt. • „Bus factor“
  10. Wie hoch sind die Zinsen? • Betrieb: – Neustart des

    Servers jeden Tag wegen Memory Leak • Entwicklung: – Aufgrund einer Vorgabe muss EJB 2.1 statt 3.0 verwendet werden und deswegen entsteht viel mehr aufwand – Aufgrund fehlender automatisierter Regressionstests sind aufwändige manuelle Tests notwendig
  11. Was muss ich bzgl. der Zinsen wissen? • Generell muss

    man beim Schulden machen wissen, wie hoch die Folgekosten sind: – Bsp.: USA Finanzkrise / Immobilienkrise • Es wurden Darlehen mit variablen Zinsen vergeben, d.h. die Schuldner kannten die Kosten nicht Gehen Sie nur kalkulierbare Schulden ein!
  12. „Pech“ • Unvorhersehbar • Unbeeinflussbar • Applikation: – „Die strategische

    Ausrichtung hat sich geändert und das Framework XY darf nicht mehr verwendet werden“ – „Das Produkt wurde von einem anderen Anbieter übernommen und wird nicht mehr supported / zu gänzlich anderen Konditionen (höhere Zinsen). • Natürliche Person: – „Die Gesetzgebung hat sich geändert, und es darf nicht mehr mit Gas geheizt werden. Die Heizung muss erneuert werden“
  13. Unachtsamkeit • Verantwortungsloses / „Krankhaftes“ Verhalten • Mangelnde Kompetenz •

    Applikation: – „Featuresucht“ – „Es gibt Logging-Frameworks? Das hätte uns 3 Monate Entwicklungszeit gespart.“ – „Oh, das Framework das wir ausgesucht habe skaliert ja gar nicht entsprechend unseres Mengengerüsts.“ • Natürliche Person: – „Spielsucht“ – „Kaufrausch“ – „Ach, die Reisekosten muss ich selber bezahlen…“
  14. Strategisch • Geplant • langfristig • Applikation: – „Wir wollen

    mit unserem Produkt die ersten auf dem Mark sein, koste es was es wolle.“ • Natürliche Person: – „Baudarlehen“
  15. Taktisch • Geplant • kurzfristig • Applikation: – „Wir brauchen

    das Feature im nächsten Release, können es aber bis dahin nicht sauber umsetzen. Wir fixen das später.“ – „Die Applikation unterstützt eine Aktion und muss nur 6 Monate laufen, wie ist egal“ • Natürliche Person: – „Kredit zur Weihnachtszeit, bis zur nächsten nächsten Bonuszahlung“ – „Knockin‘ on heavens door“
  16. Inkrementell • Sammlung vieler kleiner Kompromisse • mangelnde Übersicht •

    „Ich weiß grad nicht wie viele Ratenkredite ich schon habe, aber den einen werd' ich schon noch verkraften.“ • „Kreditkartenschulden“
  17. Kategorisierung in Quadranten rücksichtslos besonnen vorsätzlich versehentlich Baufinanzierung „Das eingesetzte

    Produkt wurde von einem anderen Anbieter übernommen und wird nicht mehr unterstützt. „Log4J? Nie gehört, brauch ich nicht!“ „Was ist eine Schichten- Architektur?“ „Wir nehmen einfach den Prototyp. Der funktioniert doch!“ „Wir müssen dieses Release morgen veröffentlichen damit wir den Zuschlag bekommen. Die Konsequenzen sind kalkulierbar.“ Kredithai Abofalle „Wir haben keine Zeit für einen Entwurf!“ Karstadtpleite nach: M. Fowler
  18. Prognose bei Verschuldung • Rücksichtslose Verschuldung: – Zinszahlungen werden so

    hoch, dass sie nicht mehr zurückbezahlt werden können, bis hin zur Insolvenz • Besonnene Verschuldung: – In der Regel gut geplant und überlegt, d.h. in der Regel kann der Kredit zurückbezahlt werden, nur nicht bei unvorhersehbaren Ereignissen. Treffen Sie bewusste Entscheidungen, versuchen Sie unvorhergesehene Ereignisse zu antizipieren
  19. Ursachen für Schulden • Mangelnde Erfahrung aller Beteiligten: – Projektleiter

    / Applikationseigner – Architekt – Entwickler – … • Überlastung der Beteiligten: – Entwickler in Helpdesk-Aufgaben eingebunden. – Zu ambitionierte Planung • Unklare und sich ändernde Anforderungen • Oft auch Kulturprobleme: – Gegeneinander statt miteinander – Verschiedene Stakeholder mit unterschiedlichen Interessen
  20. Wie erkenne ich meine Schulden? Im realen Leben • Kontoauszug

    • Kreditkarte wird eingezogen • Schreiben vom Gerichtsvollziehers • Besuch des Gerichtsvollziehers • Haus wird zwangsversteigert
  21. Wie erkenne ich meine Schulden? In der IT • Sinkende

    Qualität • Sinkende Produktivität • Sinkende Testüberdeckung • Steigende Anzahl Defects • Steigende Testaufwände • Steigende Anzahl Hacks • Verspätete Releases • Stress vor Deadlines • Angst vor Code-Änderungen • Verwendung veralteter Bibliotheken Code- Metriken Issue Tracker Project Management KPIs Social Events
  22. Was mache ich mit meinen Schulden? • Schulden so belassen

    und einfach nur die Zinsen zahlen • Schulden abzahlen – Ansätze: • 10% der Teamzeit für refactorings und Aufräumarbeiten reservieren. • Aufräum-Releases planen. • Einen Schulden-Backlog pflegen – Mit Schuldenlast und Zinssatz
  23. Wer hält mich davon ab Schulden zu machen? • Natürliche

    Person: – Erziehungsberechtigter / Ich selber – Gläubiger: Banken – Schufa • Und meine Applikation? – Applikationseigner / Projektleiter? – Budgetverantwortliche / Fachbereich? – Enterprise Architekt bei QG Architecture – Architekt
  24. Wie vermeiden Architekt und Entwickler Schulden? • Kontinuierliches Refactoring •

    Automatisierung (Testen, Deployment,…) • Geteiltes und verteiltes Wissen • Clean Code / SOLID • Früh scheitern • Auf hohes, einheitliches Niveau achten • Pfadfinderregel
  25. Wie können Sie unterstützt werden? • Management (Projektleiter / Applikationseigner)

    – Technische Schulden erfassen und ernst nehmen (Schuldenmonitor) – Indizien und Kennzahlen nicht den Entwicklern zur Last legen (Unternehmenskultur verbessern) • Budgetverantwortliche / Fachbereich – Technische Schulden ernst nehmen – Raum für Schuldenabbau geben – Requirements klar definieren
  26. Was passiert bei Insolvenz? • Natürliche Person: – Privatinsolvenz anmelden:

    • Verhandlung mit Gläubigern über Schuldenerlass • Wenn Verhandlung nicht erfolgreich: Mehrere Jahre am Existenzminimum • Applikation: – Vor der Insolvenz: Versuchen sich mit dem Gläubiger zu einigen • Schulden eliminieren / Vorgaben ändern lassen: – z.B. DB2 ist strategisch einzusetzen, Oracle wird aber verwendet – z.B. Hibernate darf nicht eingesetzt werden, wird aber eingesetzt • Höheres Budget für Zinszahlungen (Run-Budget oder Development-Budget) – Wenn Verhandlung nicht erfolgreich: Es werden keine neuen fachlichen Anforderungen umgesetzt, bis die neue Applikation schuldenfrei aufgebaut wurde
  27. Wann melde ich Insolvenz an? • Natürliche Person: – Alle

    Schulden müssen auf den Tisch – Danach dürfen keine neuen Schulden bekannt werden – Erst wenn man nach Ablauf der Frist auf eigenen Beinen stehen kann
  28. Was bedeutet das für meine Applikation? • Wenn die Applikation

    am Ende ist, dann bringt es nichts, Insolvenz der Applikation anzumelden, und eine neue Applikation zu bauen. • Man muss wie im echten Leben danach wieder auf die Beine kommen können. • Man muss also sicher sein, dass es beim nächsten Mal besser wird. Also: – Keine unkontrollierten unerfahrenen Entwickler, die versehentlich Schulden machen – Architektur basierend auf den richtigen Prinzipien – Die fachlichen funktionalen und nicht-funktionalen Anforderungen müssen bekannt und sinnvoll sein Nehmen Sie im Fall der „technischen“ Insolvenz keine fachlichen Schulden mit !
  29. Was tue ich (Entwickler/Architekt) im Projektalltag zur Vermeidung der Insolvenz?

    • Ich identifiziere technische Schulden. • Ich muss meinem Projektmanager und den Stakeholdern klar machen, dass wenn wir die nicht abbauen, das Ding den Bach runter geht. • Ich bekomme von ihm einen Tag pro Woche oder vollständige Releases für Refactorings (Schuldenabbau) • Ich muss überwachen, ob das auch wirklich die Schulden verringert • Wenn ich merke, dass ich die Schulden nicht aus eigener Kraft abbauen kann, dann: haben wir zwei Möglichkeiten: – 1) Insolvenz: Applikation durch Neuentwicklung ablösen – 2) Irgendwoher billig Geld leihen: höheres Budgets für Run und Development bekommen
  30. Zusammenfassung • Die Metapher „Technische Schulden“ macht das Problem für

    Entscheider anschaulich und sensibilisiert das Team • Das hilft ein Umfeld zu schaffen in dem Schulden ernst genommen werden • Dadurch werden weniger Schulden aufgenommen und ggf. Schulden abgebaut. • Technische Schulden können guten Gewissens aufgenommen werden. – So lange man sie zurückzahlen kann!
  31. • Offene Sammlung von Mustern zur – Analyse – Evaluierung

    – Verbesserung von existierender Software • Initiiert von Gernot Starke • Lesen, profitieren, mitmachen. • http://www.aim42.org/