Technisches Schulden Szenario #4: Hype Driven Development
Das Entwickler Team ist ständig auf der Jagd nach den neusten Technologie-Hypes. Aktuell werden im Team bereits zwei unterschiedliche Frontend-Frameworks gleichzeitig eingesetzt und die Geschwindigkeit des Teams wird dadurch ausgebremst. Was würdest Du tun?
Das nächste Szenario wie technische Schulden aufgebaut werden, dreht sich um den Umgang mit Technologie-Hypes sowie den Umgang mit unterschiedlichen Lebenszyklen von Technologien im eigenen Business-Kontext.
Dies ist der vierte Artikel, der sich damit befasst wie technische Schulden aufgebaut werden. Wenn Du die vorherigen Artikel lesen möchtest, klicke auf die nachfolgenden Links. 👇
Patrick Roos
Patrick Roos
Patrick Roos
Inhalt
Szenario
Entwickler 1: Hey, hast Du dieses neue Frontend-Framework XYZ auf GitHub in den Trends bereits gesehen? 🤓
Entwickler 2: Hmm...nein? 🤷♀️
Entwickler 1: Was? 🤭 Warte, ich schicke Dir den Link auf das Repo.
Entwickler 1: Lass uns das Framework in unserem Produkt verwenden. Ich denke das ist einfach ein MUST-HAVE! Wir brauchen das. Wir können dann endlich component-driven entwickeln...und hast Du gesehen, ich bin bereits auch Contributor. Hast Du das gesehen? 🤤
Entwickler 2: Hm...ich habe es angeschaut. Ich denke der Einsatz von diesem Framework würde uns sehr stark binden. Tendenziell sollten wir auf solche Frontend-Frameworks eher verzichten und gegen Web Standards, wie z.B. die Web Components Konzepte entwicklen. Daher bin ich nicht sicher, ob wir dies einsetzen sollen. 🤔
Entwickler 1: Come on. Dieses Framework ist auch unterstützend für Behavior-Driven-Development. 🚀
Entwickler 2: Naja, wir sollten zuerst saubere Unit-Tests schreiben lernen. 🥴 Aber ja, wenn's Dir Freude macht, kannst Du ja mal einen Vorschlag im Team machen. Ist mir eigentlich egal. 🥱
Entwickler 1: Ok, ich werde dies als mögliche technische Aufgabe vorstellen. Das würde uns ein cooles Seitenprojekt für 1 - 3 Monate geben - da bin ich mir sicher!! 😎
Was ist das Problem?
Ständig dem letzten Technologie Hype nachzurennen, kann die Geschwindigkeit eines Produktteams stark mindern. Auf der einen Seite gibt es dadurch immer mehr Technologien die man beherrschen muss und auf der anderen Seite entsteht ein richtiger "Technologie-Zoo". Und mit der Grösse dieses Zoo's, vergrössern sich natürlich auch die technischen Schulden.
Technologien sollten beim Lösen von Kundenproblemen unterstützend wirken und dienen nicht in erster Linie dem individuellen Entwickler-Bedürfnis. Das bedeutet aber nicht, dass man als Produktteam keine modernen Technologien einsetzen resp. nutzen sollte.
Mit der kontinuierlichen Vergrösserung des eingesetzten "technischen Zoo's" können auch immer mehr der eingesetzten Technologien End of Life gehen oder - im community getriebenen Open-Source Fall - gar von der Community verlassen werden. Die eingesetzte Technologie wird zur Legacy-Technologie und dass kann einen massiven Impact auf das Unternehmen haben. Zum einen gibt es Risiken auf der Produktseite (wie z.B. kein Support mehr in einem Fehlerfall) oder auch organisatorische Risiken wie z.B. die Minderung der Arbeitgeberattraktivität. Die Entwickler finden es nicht mehr interessant mit einem damals "gehypten" - heute legacy Framework zu arbeiten.
Ein gutes Beispiel dazu ist die Geschichte von AngularJS und Angular. AngularJS war einmal ein richtiger Hype. Sehr viele Unternehmen haben entweder ihre bestehenden Produkte (serverseitig gerenderten) Web Applikationen mit AngularJS in guter SPA Manier umgestellt oder gar neue Vorhaben direkt mit dem AngularJS gestartet. Nun ein paar Jahre nach dem Hype kam Google & die Community und entschloss einen kompletten Rewrite des Frameworks zu machen. Angular entstand. Nur schon durch die Ankündigung entstand in vielen Firmen grosse technische Schulden.
Wenn man jetzt die Zeit zurückdrehen würde, würdest Du wieder auf AngularJS setzen? Oder generell würdest Du wieder auf einen Single Page Application Ansatz setzen?
Wie kann man dieses Problem verhindern?
Aktives Technologie-Management ist eine wichtige Aktivität um die eingesetzten Technologien und somit auch die daraus resultierenden technischen Schulden zu verwalten. Technologie-Management sollte im Team, wie auch im Unternehmen verankert werden. Ein gutes Werkzeug für aktives Technologie Management ist der Technologie Radar.
Was ist ein Technologie Radar?
Ein Technologie Radar unterstützt beim Beobachten der potentiell einsetzbaren und eingesetzten Technologien. D.h. der Technologie Radar hilft Technologien zu identifizieren, welche im Business Kontext beurteilt "Assess", ausprobiert "Trial", eingesetzt "Adopt" oder ausgemustert "Hold" werden sollen. Der Technologie-Radar begleitet den kompletten Lebenszyklus einer Technologie.
Wie ist dieser Lebenszyklus im Technologie Radar abgebildet?
Wie im obigen Kapitel schon angedeutet, wird der Lebenszyklus im Technologie Radar mit sogn. Rings in Assess, Trial, Adopt und Hold repräsentiert wie die folgende Abbildung zeigt.
Assess
Wenn eine Technologie möglicherweise Potential für das Lösen von bestimmten Problemen im Kontext des Produktes hat, wie vielleicht das Frontend-Framework aus dem obigen Szenario, dann sollte diese Technologie angeschaut und beurteilt werden. In diesem Fall würde man dieses Frontend-Framework in den Assess Ring stellen. Gelangt eine Technologie in den Assess Ring sollte man Zeit erhalten, um erste Erfahrungen mit dieser Technologie machen zu können. Beispielsweise kann man für ein bestimmtes Problem, bei welchem vermutlich diese Technologie unterstützend wirkt, einen Prototypen erstellen. In dieser Phase geht es darum zu beurteilen, ob die Technologie für das eigene Business passen könnte, ob es mehr als nur einen Hype ist und - eben - ob die Technologie im Business-Kontext auch wirklich ein Problem (besser) lösen kann. Mit den Erfahrungen kann dann beurteilt werden, ob die Technologie erstmals eingesetzt werden soll.
Trial
Bei einer positiven Beurteilung resp. der Bedarf für den Einsatz dieser Technologie vorhanden ist, kommt die nächste Phase der Technologie - die Trial-Phase. In der Trial-Phase wird die Technologie in einer produktiven Applikation, idealerweise in einer risikoarmen Umgebung (z.B. in einem unterstützenden Tool) eingesetzt - aber in Produktion! Mit der Nutzung der Technologie in einer produktiven Umgebung, erhält man automatisch tiefere Erfahrungen und Erkenntnisse. Wenn die entsprechende Technologie für einige Monate in dieser Appliakation erfolgreich eingesetzt und verwendet wurde, kann beurteilt werden, ob diese Technologie breit eingesetzt werden kann.
Adopt
Wird die Technologie breit eingesetzt, kommt sie in den Adopt Ring und ist somit für die allgemeine Nutzung freigegeben.
Hold
Bei jeder Technologie kommt irgendwann mal der End-of-Life Status. Wenn beispielsweise die Technologie nicht mehr länger durch die Community unterstützt wird oder durch den Lieferanten, ist es Zeit, die Technologie auf "Hold" zu setzen. Eine Technologie auf "Hold" zusetzen bedeutet, dass diese Technologie in sämtlich eingesetzten Anwendungen kurz- oder mittelfristig dekomissioniert werden sollte. Hier werden die angehäuften technischen Schulden somit sichtbar.
Wie werden die Technologien in einem Technologie Radar strukturiert?
Es kommt selbstverständlich auf die Organisation der Teams resp. das Unternehmen an. Ein viel verbreiteter Ansatz ist es, wie folgt den Technologie-Radar zu strukturieren (inspieriert vom ThoughtWorks Technology Radar).
Techniken
Techniken unterstützen das Produktteam während dem kompletten Engineering-Prozess, das können z.B. Vorgehens-Ansätze aus Domain Driven Design oder auch Architekturansätze wie z.B. Micro-Frontends sein.
Tools
Unter Tools werden Datenbank Management Systeme sowie Engineering Tools gebündelt. Beispiele sind hier z.B. MongoDB, IntelliJ oder k6.
Plattformen
Plattformen bildet die Basis auf was die Applikationen gebaut und entwicklelt werden. Technologien welche in diese Kategorie fallen sind beispielsweise Azure DevOps, ArgoCD oder generell die Google Cloud Platform.
Programmiersprachen und Frameworks
Mit Programmiersprachen und Frameworks werden die Applikationen umgesetzt. Beispiele sind hier das .NET, Java, TypeScript, React, Angular oder Spring Boot.
Sollte man einen Technologie Radar unternehmensweit oder team spezifisch einsetzen?
Es kommt darauf an, wie man organisiert ist. Wenn das Team komplette Autonomie resp. Entscheidungsfreiheit in der Wahl von Technologien hat, kann das Team natürlich seinen eigenen Technologie-Radar führen.
Oftmals ist es aber so, dass Produktteams nicht die komplette Freiheit haben in der Auswahl von Technologien. Dafür gibt es verschiedene Gründe. Werden wirksame Technologieentscheidungen übergreifend gefällt, gibt es dazu oftmals übergreifende Technologie- und Architekturboards. Hier unterstützt der Technologie-Radar als Mittel um Technologie-Entscheidungen herbeizuführen, diese zu kommunizieren und den Lebenszyklus entsprechend zu begleiten.
In welcher Frequenz soll der Technologie-Radar neu beurteilt werden?
Wenn das Team autonom ist resp. seinen eigenen Technologie-Radar führt, kann das Team beispielsweise jeden Monat einen Technologie-Tag durchführen. An diesem Tag wird man aber nicht spontan nach neuen Technologien Ausschau gehalten. Dies sollte selbstverständlich in der täglichen Arbeit geschehen. Am Technologie-Tag werden sämtliche relevanten Technologien auf dem Technologie-Radar neu beurteilt und neue vorbreitete Vorschläge aus dem Team werden behandelt.
Wenn das Unternehmen einen übergreifenden Technologieradar führt, ist eine gute Daumenregel, dass pro Quartal der Technologieradar neu beurteilt wird. Teammitglieder kommen stellvertretend für die Teams in das Technologie- und Architekturboard um neue übergreifend gültige Technologien zu besprechen. Dieser Workshop pro Quartal gibt Raum für den Austausch und die Diskussion rund um den Einsatz von neuen (und alten) Technologien im Kontext des Unternehmens. Gemeinsam im Board wird beispielsweise entschieden ob neue Technologien in den Assess Ring kommen und entsprechend in der nächsten Periode beurteilt werden sollen.
Das gleiche passiert für die Technologien in den anderen Lebenszyklen:
- Trial: Wie war die Erfahrung mit Technology X in der Komponente Z?
- Adopt: Gibt es breit eingesetzte Technologien die nächstens EoL werden oder den Community Support verlieren?
- Hold: Was ist der Status und auch die Erfahrung im Migrationspfad vom Produkt X um die Technologie Z auszumustern?
In welcher Granularität sollten Technologien auf den Technologie-Radar kommen?
Es sollten lediglich Technologien mit einem finanziellen Impact oder lock-in Risiko (implizit oder explizit) auf den Technologie-Radar platziert werden:
- Treiber für Lizenz- und/oder Betriebskosten
- Grosser Know-How Aufbau
- Starke Kopplung an die entsprechende Technologie
Bei folgendem Granularitätslevel sollten Technologien nicht auf einen Technologie-Radar platziert werden sollten (resp. besteht die Gefahr für Micro-Management): Finanziell insignifikante, einfach ersetzbare 3rd Party Abhängigkeiten wie z.B. (transitive) npm-packages, bestimmte kleinere maven-libraries oder andere Bibliotheken.
Wer kann neue Technologien vorschlagen?
Jedes Team-Mitglied, egal ob Lehrling oder Senior, Expert oder whatever Entwickler, soll die Möglichkeit haben, Vorschläge für den Einsatz von neuen Technologien haben. Wichtig ist, dass sie ein bestimmtes Problem (besser) lösen. Durch diese strukturierte Offenheit können auch effizient neue Hypes einfach und konstruktiv beurteilt werden.
Gibt es gute Beispiele von einem Technologie-Radar in der Praxis?
Unter dem folgenden Post habe ich verschiedene gute Beispiele von Technology Radar Implementationen zusammengefasst:
Patrick Roos
Wie kann ich einen eigenen Technologieradar erstellen?
ThoughtWorks bietet mit Build Your Own Radar ein Excel-basiertes Tool an, um einen eigenen (angepassten) Technologie-Radar erstellen zu können.
Zusätzlich gibt es auf GitHub einzelne Projekte, welche sich dieser Thematik angenommen haben. Wie z.B. das folgende Projekt:
bdarganZusammenfassung
Mit aktivem Technologiemanagement können Hypes einfach beurteilt werden und somit dem Hype Driven Development entgegengesetzt werden. Aktives Technologiemanagement meint, dass Vorschläge für den Einsatz von neuen Technologien aktiv gefördert, neue beurteilt, ausprobiert und schlussendlich die Entscheidung nachvollziehbar und klar dokumentiert werden. Eingesetzte Technologien werden bis zur Dekommisionierung begleitet.
Ein unterstützendes Tool für aktives Technologiemanagement ist der Technolog-Radar, welcher unternehmensweit oder team-spezifisch eingesetzt werden kann. Der Technologie-Radar hilft dem Team oder der gesamten Unternehmung neue oder bereits eingesetzte Technologien durch den ganzen Lebenszyklus zu beobachten und entsprechend kontinuierlich zu beurteilen. Daraus können zukünftige Aktionen - wie z.B. der Phase-out von einer Legacy-Technologie - angestossen werden.
Comments ()