Mittels Technologieradar die Übersicht behalten

Bei all den vielen neuen Werkzeugen, Techniken und (JavaScript-) Frameworks die wie Pilze aus dem Boden schiessen ist es äusserst schwer den Überblick zu behalten. Überall sieht man neue Dinge und vieles davon sieht so spannend aus dass man dies gleich ausprobieren will. Nur ist die Menge mittlerweile viel zu gross um dies auch zu tun.

Was man bräuchte ist eine Art Filter mit dem man sich gezielt auf einige ausgewählte Themen und Werkzeugen konzentrieren kann. Man müsste wichtigeres von unwichtigem trennen können ohne dabei zu viel Zeit mit dem Kategorisieren zu verlieren. Was ich bräuchte wäre etwas wie der Technology Radar von ThoughtWorks, nur halt für mich und meine Interessen.

Von ThoughtWorks zum eigenen Technologieradar

ThoughtWorks veröffentlicht in etwa alle 6 Monate eine Aktualisierung ihres Technologieradars. Die Grafik ist dabei eine Zusammenfassung der internen Diskussionen und zeigt auf in welche Richtung sich die IT-Branche aus ihrer Sicht bewegt. Statt grosser Dokumente hilft einem eine einzige Grafik abzuschätzen ob man Zeit in die entsprechende Technologie investieren soll oder besser gleich eine Migration plant. Dazu dienen diese 4 Ringen:

• Hold (abwarten): Keine neuen Projekte mit diesen Technologien starten.
• Assess (einschätzen): Genauer hinschauen ob sich daraus etwas entwickelt.
• Trial (ausprobieren): In kleineren und weniger wichtigen Projekten Erfahrungen sammeln.
• Adopt (umsetzen): Bereit um in kritischen Anwendungen verwendet zu werden.

Neal Ford ist nicht nur beim Radar von ThoughtWorks involviert, sondern spricht auch an Konferenzen über den Nutzen eines persönlichen Technologieradars. In diesem Blogpost erklärt Ford wie man damit auch einen Realitätsabgleich machen kann. Fixiert man sich zu sehr auf einen Hersteller bekommt man nicht mehr mit wie sich die Welt um einen herum verändert – bis es zu spät ist und man keinen neuen Arbeitgeber findet.

Das Festlegen auf die einzelnen Technologien und wo man diese sieht ist der aufwändigste Teil um selber einen Technologieradar zu erstellen. Hier kommt es ganz auf die eigene Einschätzung an, da angesichts der schnellen Veränderungen objektive Kriterien kaum weiterhelfen. Sobald man alles beisammen hat geht es mit der grafischen Darstellung recht schnell. Dank der grossen Vorarbeit von Brett Dargan uns seinem Projekt Techradar braucht man nur noch eine JSON-Datei anzupassen und schon hat man seine Grafik.

Mein Technologieradar

Für meine Grafik bin ich recht schnell von ThoughtWorks abgewichen. Wenn auch etliche Technologien gleich sind so hat mir die Vorlage nicht ganz entsprochen. Der Quadrant "Techniques" ist bei mir weiter gefasst und beinhaltet neben technischen Lösungsansätzen auch Verfahren und Methoden. Gleiches gilt für den Quadranten "Infrastructure" der bei mir auch Plattformen und Services umschliesst.

Techniken, Verfahren & Methoden

In diesem Quadranten gibt es bei mir die meisten Einträge in den Ringen "Adopt" und "Trial". Dies war nicht so geplant, zeigt aber einen interessanten Nebeneffekt des Technologieradars: Durch die grafische Darstellung kann man eine thematische Häufung von Einträgen erkennen die einem so vorher nicht bewusst war.

Bei all den Dingen die ich anschauen oder umsetzen will gibt es eine grosse Ausnahme: Es muss aufhören aus reiner Bequemlichkeit in einer API 1:1 die Limitierungen der darunterliegenden Systemen weiterzureichen. Nur weil SQL Server Null-Werte als 1.1.1753 maskiert braucht ja nicht jeder Konsument der API in seiner Anwendung die Null-Konvertierung selber durchzuführen. Auch wenn ich dies bisher vor allem im Bereich von Datenbanken angetroffen habe gibt es keinen Grund dies nicht auch bei anderen Systemen zu beachten.

Infrastruktur, Plattformen & Services

Das grosse Thema in diesem Quadranten ist die Cloud. Trotz all der NSA Enthüllungen gibt es hier Chancen die zu gut sind um sie zu ignorieren. Angefangen bei GitHub über Code Climate bis hin zu Amazon und Azure gibt es unzählige Einsatzgebiete die auf eine Erkundung warten.

Bei RavenDB habe ich am längsten um die Einteilung gerungen. Da mir noch einige wichtige Informationen für den Produktiveinsatz fehlen blieb es schlussendlich beim Einsatz in kleineren Projekten. Die Wissenslücken für den Einsatz in geschäftskritischen Anwendungen sollte ich aber bald schliessen können.

Tools

Viel Auszuprobieren gibt es für mich bei den Tools. Rund um Ruby gibt es eine Vielzahl von Helfern fürs Testing und den Aufbau von Entwicklungsumgebungen. Bei .Net vermisse ich bisher so ausgereifte Werkzeuge. Daher wird es Zeit genau zu prüfen wie weit SpecFlow und MSpec, respektive Puppet und Chef gekommen sind.

Ein weiteres spannendes Thema sind für mich Micro ORMs. Realistisch betrachtet wechselt man kaum je die Datenbank bei einem Projekt aus. Daher sind OR-Mapper wie Entity Framework oder NHibernate mit ihren Abstraktionsschichten oft ein grosser Overhead der einem den Zugriff auf datenbankspezifischen Funktionen nur über Umwege erlaubt. Micro ORMs könnten da eine Alternative sein die eine vertiefte Abklärung verdienen.

Sprachen und Frameworks

Sowohl für C# wie für Ruby Entwickler dürften die meisten Einträge in diesem Quadranten nachvollziehbar sein. Wo es wohl einige Erklärung braucht ist der "Hold" Ring.

Bei den Desktop-Frameworks wie WPF aber auch WinForms halte ich mich derzeit zurück. Angesichts verteilter Standorte, Home Office und der Verbreitung von Tablets setze ich viel eher auf die Webentwicklung. Diese allerdings abseits von WebForms und Silverlight. Da Silverlight selbst von Microsoft nicht mehr in allen IE-Varianten unterstützt wird ist diese Technologie definitiv gestorben – auch wenn die Supportseite einem eine andere Geschichte erzählen will.

Sehr skeptisch bin ich auch bei TypeScript. Hier handelt es sich aus meiner Sicht um eine Lösung auf der Suche nach einem Problem. Die Probleme vieler Entwickler mit JavaScript lassen sich nicht durch ein aufgepfropftes Typensystem lösen – viel eher muss man JavaScript als eigenständige Sprache akzeptieren und die Eigenheiten lernen. Und sollte TypeScript tatsächlich länger bleiben kann man später immer noch auf diesen Zug aufsteigen.

Fazit

Beim Zusammenstellen des Technologieradars muss man sich plötzlich festlegen. Es genügt nicht mehr nur eine vage Liste mit interessanten Technologien zu haben - nun wird auch eine Einteilung in die Kreise und Quadranten benötigt. Es bleibt einem nichts anderes übrig als die einzelnen Technologien zu ordnen und zu klassifizieren.

Der grosse Nutzen dieser Übung liegt für mich im bewussten Auseinandersetzen mit den einzelnen Technologien und der Entscheidung, ob diese nun einen Platz im Radar finden oder nicht. Dabei spielt es keine grosse Rolle wo genau sich diese auf der Grafik befinden. Viel wichtiger ist welche Technologien es überhaupt hinein schaffen.

Wieviel mir die ganze Übung am Ende bringen wird muss sich noch zeigen. Die ersten Erfahrungen waren allerdings so hilfreich dass ich die Erstellung eines eigenen Technologieradars sehr empfehlen kann.