In the Code: Wegweiser durch den Technologie­dschungel

Ergon-CTO Erich Oswald über den Nutzen des hauseigenen Technologieradars als Wegweiser und zur Unterstützung der Projektteams.
 
Die Zeit der Universalgelehrten ist auch in der Informatik schon lange vorbei. Die Wahrscheinlichkeit, dass sich ein noch so guter Entwickler sowohl in Kryptologie, Big Data, Browsertechnologien, Reporting Engines und Buildtools mit allen wichtigen Frameworks auskennt, ist verschwindend klein. Trotzdem baut heutzutage fast jedes IT-Projekt auf einem vielfältigen Mix von Technologien auf. Zeit und Lust, einen geeigneten Mix jedes Mal von Grund auf zu evaluieren, hat aber niemand. Viel lieber möchte man einen Baukasten mit einem beschränkten Sortiment an Komponenten zur Auswahl haben.
 
Als Entwickler wollen wir beim Bau einer Softwarelösung überzeugt sein, dass wir die richtigen Teile im Baukasten haben und diese vernünftig kombinieren. Das ist nicht immer ganz einfach: Wenn wir auf bekannte und bewährte Technologien setzen, verpassen wir vielleicht die Gelegenheit, ein innovatives und zukunftsträchtiges System zu bauen. Umgekehrt können wir zwar die neusten und vielversprechendsten Technologien einsetzen, müssen aber dafür mit Kinderkrankheiten und unerwarteten Unzulänglichkeiten rechnen. Im Idealfall wählt ein Projektteam einen Mix aus soliden Industriestandards und vielversprechenden Newcomern in einem Verhältnis, das zum Projekt passt. Bei Ergon liegt die Verantwortung für die Wahl der Technologien bei den Teams ? ich als CTO berate und unterstütze sie dabei, doch der endgültige Entscheid bleibt den Teams vorbehalten. Dies gibt ihnen viel Freiheit, ist aber auch anspruchsvoll. Denn wer beurteilt, welche Technologien in welche Kategorie gehören und welche für ein Projekt geeignet sind?
 
Ein Werkzeug, um etwas Ordnung in den Dschungel zu bringen und den Überblick zu behalten, ist der Technologieradar, den wir von Thoughtworks kennen und auf dieser Basis selber erarbeitet haben. Die Idee ist bestechend einfach: alle paar Monate bringen wir eine Menge von erfahrenen Entwicklern und Architekten in einem Raum zusammen, die sich im Rahmen ihres Jobs und aus persönlichem Interesse vertieft mit Teilgebieten der Technologielandschaft beschäftigen. Wir diskutieren dort aus, welche Technologien sich bewährt haben, welche wir ausprobieren sollten und von welchen wir besser die Finger lassen. Das Resultat visualisieren wir als stilisiertes Radarbild, in dem neue Technologien am Horizont auftauchen und sich zur Mitte hin bewegen, je stärker wir empfehlen, sie in Projekten einzusetzen.
 
Der Technologieradar gibt unseren Entwicklern eine Entscheidungshilfe, wenn es darum geht, Technologien für ein Projekt zu evaluieren. Er nimmt den Teams aber die Entscheidung nicht ab, denn wir berücksichtigen bewusst mehrere Alternativen. Jedes Team kann auch Technologien verwenden, die der Radar nicht kennt. Dann muss das Projektteam die entstehenden Risiken allerdings umso genauer evaluieren. Falls Sie diese Vorstellung beunruhigt: Bei uns ist noch kein Projekt gescheitert, weil ein Team eine unpassende Technologie ausgewählt hätte. Hingegen hätten wir viele Chancen für innovative Projekte verpasst, wenn wir immer auf Nummer sicher gegangen wären.
 
Der Technologieradar gibt uns keine langlebigen Garantien, weil er eine Momentaufnahme darstellt und ein halbes Jahr später bereits wieder anders aussieht. Trotzdem hat er Überzeugungskraft, da er die Einschätzung von mehreren gut informierten Experten widerspiegelt. Unseren Teams fällt es dadurch auch leichter, einen Lösungsvorschlag gegenüber dem Kunden glaubwürdig zu vertreten. Gerade wenn ein Kunde selber schon starke Vorstellungen hat, wir diese aber nicht für passend halten, kann der Technologieradar als kondensierte Expertenmeinung eine wichtige Rolle spielen.
 
Als Unternehmen profitieren wir von den Erfahrungen, die unsere Teams mit neuen Technologien sammeln. Das in den Projekten aufgebaute Know-how fliesst in die zukünftigen Versionen des Radars ein, indem zum Beispiel ein Vertreter des Teams gleich selbst am nächsten Workshop teilnimmt und die Erfahrungen seines Teams einbringt. Es kommt auch vor, dass einzelne Entwickler eine Einschätzung im Radar als unzutreffend empfinden. Bei guter Begründung ist die Chance ziemlich gross, dass eine solche Position im nächsten Radar angepasst wird.
 
Obwohl die Zusammensetzung der Arbeitsgruppe, die den Radar bestimmt, nie genau dieselbe ist und der Radar immer nur eine Momentaufnahme darstellt, ist er doch erstaunlich robust und zeigt ein funktionierendes Beispiel von Schwarmintelligenz. Er kondensiert das Know-how der gesamten Firma, insbesondere auch implizites Wissen, das wir in der Form sonst nicht niedergeschrieben haben.
 
Unsere Erfahrungen mit dem eigenen Technologieradar sind so positiv, dass wir ihn weiterhin pflegen werden. Allerdings ist auch der Radar nur eines von vielen Werkzeugen, wenn es darum geht, Know-how in einer komplexen, schnelllebigen Welt zu pflegen. Probieren Sie es selbst aus! Ihr eigener Technologieradar wird Ihnen nützlicher sein, als mancher Report und manches Survey aus dem Internet. (Erich Oswald)
 
Über den Autor
Erich Oswald ist Chief Technology Officer beim Zürcher Softwarehersteller Ergon. Zu seinen Aufgaben gehören neben der alltäglichen Entwicklung seit über zehn Jahren die Pflege des Technologieportfolios im Bereich von Java SE und Java EE sowie die Beratung von Kunden und Teams beim Einsatz von Technologie, Softwarearchitektur und agilen Entwicklungsmethoden. Erich Oswald hat seine Studien an der ETH Zürich mit einem Diplom in Informatik und einem Doktor der technischen Wissenschaften abgeschlossen.