Vom Tech Radar zum Radar Talk

Eigenes Radar für neue Technologien

Joachim Betz, Matthias Wittum

©Shutterstock / Makhnach_S

Welche Technologie sehe ich mir als Nächstes an? Welche ist für mich nicht mehr relevant? Zwei typische Fragen, auf die fast jeder Entwickler immer eine aktuelle Antwort parat hat. Diese Fragestellungen gelten auf ähnliche Weise auch für Unternehmen. Doch wer kümmert sich darum, die passenden Antworten dafür zu liefern, und welche Mittel nutzt derjenige dafür?

Bei der Frage nach neuen relevanten Technologien fällt einem spontan die Rolle des Architekten ein, der sich auf strukturierte Art und Weise mit diesem Thema befasst. Welche Mittel er wählt, bleibt normalerweise ihm überlassen. Das können einfache Notizen in einer To-do-Liste, eine managementtaugliche Präsentation oder irgendeine Technologieradarillustration sein. Eine individuelle Variante bietet sicherlich ausreichend Gestaltungsspielraum, hilft aber wenig, wenn man einen gemeinsamen Nenner benötigt. Das ist der Fall, wenn man mit Kollegen aus anderen Bereichen einen Abgleich machen oder einfach nur Technologieentscheidungen diskutieren möchte.

Bei 1&1 haben wir rund fünfzehn Entwicklungsbereiche. Jeder dieser Bereiche kümmert sich um die Entwicklung einer Produktfamilie oder verschiedener Informationssysteme. Um ihrem Auftrag bestmöglich nachkommen zu können, haben diese Bereiche weitestgehend freie Wahl beim Einsatz von Technologien und Vorgehensweisen. Dadurch ergibt sich natürlich eine gewisse Vielfalt. Um nicht an mehreren Stellen im gesamten Unternehmen auf das falsche Pferd zu setzen und von vorhandenem Wissen zu profitieren, tauschen sich Vertreter aus den einzelnen Bereichen in themenbezogenen Boards aus. Diese Vertreter müssen nicht zwangsläufig Architekten sein.

In einem dieser Boards entstand die Idee, sich über einen gemeinsamen Technologieradar auszutauschen. Zentrale Fragestellungen waren z. B. „Was probiert ihr gerade aus?“, „Wovon wollt ihr weg, weil ihr damit schlechte Erfahrung gemacht habt?“, „Was hat euch richtig vorangebracht?“ oder „Was setzt ihr in der Breite ein? Wo habt ihr fundiertes Know-how und dadurch auch kompetente Ansprechpartner?“.

Doch wie findet man ein gemeinsames Medium oder ein Tool, in dem sich ein Technologieradar abbilden lässt? Thoughtworks veröffentlicht auf ihrer Website eine der bekanntesten Technologieeinschätzungen. Allen fehlt allerdings ein Aspekt, der uns recht wichtig erschien: die Möglichkeit, zu gewichten.

Implementierung eines Tools

Unter Zuhilfenahme einiger Freiwilliger wurden unsere Anforderungen in eine einfache Single-Page-App gegossen, um unsere eigene Art eines Technologieradars zu visualisieren. Abbildung 1 zeigt, wie dieser aufgebaut ist. Inhaltlich enthält der Radar eine grobe Aggregation vieler Einzelradare aus unseren Bereichen, die im Einzelnen durchaus detaillierter sein können. Auf der x-Achse ist der Lebenszyklus mit den vier Phasen „trial“, „adopt“, „keep“ und „hold“ abgebildet. Die Phase „trial“ enthält die Technologien, die frisch auf dem Radar aufgetaucht sind, sich interessant anhören und die evaluiert werden. Unter „adopt“ finden sich die Elemente, die schon über die Evaluierungsphase hinaus gekommen sind und bereits testweise in ersten Projekten erprobt und eingesetzt werden. In „keep“ befinden sich all diejenigen, die zum Standard gehören und problemlos eingesetzt werden können. Alles, was nicht mehr genutzt werden soll oder dessen Lebenszyklus sich am Ende befindet, ist in „hold“ eingeordnet.

Abb. 1: Im Technologieradar zum Thema „Languages and Frameworks“ sind die verschiedenen Technologien nach Lebenszyklus und Wichtigkeit sortiert

Abb. 1: Im Technologieradar zum Thema „Languages and Frameworks“ sind die verschiedenen Technologien nach Lebenszyklus und Wichtigkeit sortiert

Jede Phase ist weiter unterteilt, um die Technologien nicht hart und abrupt von rechts nach links zu schieben, sondern auch Übergänge darstellen zu können. Die y-Achse zeigt die Gewichtung der Technologie. Abhängig von der Phase kann man verschiedene Dinge ablesen. Im abgebildeten Radar sind diverse Sprachen und Frameworks in der Phase „trial“ mit mittlerer Gewichtung abgebildet. Das ist ein Zeichen dafür, dass sich noch nicht so richtig abschätzen lässt, wie stark ihr Potenzial ist, großflächig Veränderungen herbeizuführen. Apache Spark kommt bereits mit dem Potenzial, die bestehende Map-Reduce-Landschaft abzulösen, und hat das Interesse von mehreren Bereichen geweckt. Java 8 hat dank der größeren Änderungen wie Lambdas oder Streaming bei vielen den Bedarf (hohe Gewichtung) geweckt und wird bei neuen Projekten in vielen Teams ausprobiert. In „keep“ tummeln sich die Standards wie Java 7 und Maven, die aktuell die größte Verbreitung haben. Aber auch solide Ergänzungen wie Python sind zu finden, allerdings in einer überschaubaren Verbreitung. Einen groben Anhalt gibt die Gewichtung auch darüber, wie aufwendig es ist, beispielsweise Java 6 loszuwerden. Es ist sogar noch etwas weiter verbreitet als unsere alte Workflow-Engine jBPM.

Eine klare Struktur hilft

Für die Eingabe der Punkte steht ein Formular zur Verfügung, in dem man eine Beschreibung oder Begründung eingeben kann, warum ein bestimmtes Element an der aktuellen Position im Radar platziert ist, z. B. als Grundlage für eine Diskussion. Die Eingabefelder verfügen über eine Autovervollständigung, die basierend auf den bisherigen Eingaben beim Tippen mögliche Ergebnisse vorschlägt. Diese Funktion soll vor allem dabei helfen, dass für eine Technologie möglichst auch nur ein Begriff verwendet wird und nicht mehrere. So kommen erst gar keine Begriffsproblematiken auf.
Um den Radar nicht zu überfrachten, kann beim Anlegen ausgewählt werden, für welche Kategorie man einen Radar erstellen möchte. Wir haben in drei Kategorien unterschieden, die in der Applikation jeweils andersfarbig dargestellt werden:

  • Languages and Frameworks: Unterschiedliche Programmiersprachen sowie Frameworks, die die Sprache um weitere Funktionalitäten und Möglichkeiten erweitern.
  • Platforms and Tools: Plattformen (z. B. Applikationscontainer) sowie Tools, die oft zum Ökosystem einer Plattform dazugehören oder aber genereller Natur sind wie Maven als Build-Tool.
  • Techniques and Methodologies: Vorgehensweisen, Techniken, Ansätze, aber auch Konzepte, die bei der Softwareentwicklung angewendet werden wie Scrum oder TDD.

Die genaue Definition der drei Kategorien findet sich in der Hilfe. Da die Kategorien nicht hundertprozentig trennscharf sind und es durchaus auch von der jeweiligen Interpretation der Person abhängt, die dazu einen Radar erstellt, kann es dazu kommen, dass Elemente unterschiedlich zugeordnet werden. Selbiges gilt für die Granularität. Zu Beginn hatten wir Radare, deren Technologieelemente mit feingranularen Versionsnummern versehen waren. Aber auch andere, die die Versionsnummern fast gänzlich weggelassen haben. Nach kurzer Diskussion haben wir uns darauf geeinigt, nicht zu detailliert vorzugehen und nur dort Versionsnummern (meist Majors) zu verwenden, wo es dem Verständnis dient.

Historie und Vergleichsfunktion bringen neue Erkenntnisse

Den aktuellen Stand zu diskutieren, ist zwar immer interessant, aber gelegentlich möchte man auch sehen, wie sich denn so ein Tec Radar oder die einzelne Technologien darin entwickelt haben. Hat beispielsweise eine in „trial“ verortete Technologie mit hohem Potenzial auch wirklich gezündet, wurde sie von vielen ausprobiert („adopt“) und hat mittlerweile eine große Verbreitung erlebt? Oder kam es ganz anders? In beiden Fällen ist natürlich auch das „Warum?“ interessant. Die Tec-Radar-Applikation ermöglicht es, bis zu drei Radare miteinander zu vergleichen, und zeigt den entsprechenden Veränderungspfad an. Abbildung 2 zeigt beispielhaft die Historie einiger Projektmethodiken bzw. Vorgehensweisen an. Man sieht, dass die Wasserfallmethodik vor einigen Jahren noch sehr stark verbreitet war. Dank des Siegeszugs der agilen Methoden hat diese aber nach und nach viel Boden verloren. Sicherlich gab es bereits Überlegungen, die Methodik ganz abzulösen. Aktuell hat die Wasserfallmethode wieder eine kleine Nische besetzt und kann so weiter in „keep“ eingeordnet werden, wird aber (hoffentlich) keine essenzielle Rolle mehr spielen.

Abb. 2: Wie sich eine Technologie über die Zeit geschlagen hat, zeigt der Radarvergleich

Abb. 2: Wie sich eine Technologie über die Zeit geschlagen hat, zeigt der Radarvergleich

So funktionieren Tec Radare in der Praxis

Die bisherigen Beispiele waren Aggregationen aus verschiedenen Bereichen und enthalten dadurch eine gewisse Unschärfe, da sich beispielsweise eine Technologie in einem Bereich noch in der Phase „adopt“ befinden, in einem anderen Bereich aber bereits in die Phase „hold“ gerutscht sein kann. Zur konkreteren Veranschaulichung hier einige Praxisbeispiele aus dem Tec Radar von 1&1 MyWebsite. Bei MyWebsite handelt es sich um den Website-Builder der 1&1. Die Beispiele decken je eine Kategorie ab und konzentrieren sich auf eine oder mehrere Technologien.

Languages and Frameworks: Camunda BPM

Eine der vielfältigsten Aufgaben innerhalb von 1&1 ist es, die verschiedenen Produkte und Dienstleistungen für unsere Kunden bereitzustellen. Dies wird in vielen Fällen durch mehr oder weniger komplexe Geschäftsprozesse abgebildet. Bei 1&1 gibt es die Möglichkeit, diese Prozesse in ausführbaren Java-Code zu überführen. Ermöglicht wird dies durch eine eigens entwickelte Plattform, deren Herzstück auf der so genannten Camunda Engine („keep“) basiert und die BPMN lesen kann. Das MyWebsite-Middleware-Team als ein Anwender kann nun über das Tec Radar neue Anforderungen wie Java-Versionen oder Logging-Frameworks einfließen lassen. Diese lassen sich dann wiederrum bei der Weiterentwicklung der internen Plattform gewichten und berücksichtigen. Über die Kategorisierung von Camunda BPM kann man trefflich streiten. Handelt es sich um ein Framework oder nicht? Als Bestandteil unserer internen Service- und Process-Plattform findet sie sich spätestens durch diese Integration auch in den Plattformen wieder.

Platforms and Tools: Versionsverwaltung

Das 1&1-Produkt MyWebsite wird über mehrere Teams verteilt und an verschiedenen Standorten entwickelt. In diesem Set-up war klar, dass wir die Vorteile einer verteilten Versionsverwaltung nutzten wollen. Die Entscheidung für die Versionsverwaltung Git war schnell getroffen. Aber wie setzt man Git in einem professionellen Umfeld ein? Bei MyWebsite arbeiten wir seit Längerem mit der webbasierten Oberfläche GitLab („keep“) (Abb. 3). Mithilfe des Tec Radars konnten wir aber feststellen, dass auch andere Bereiche des Unternehmens ähnliche Anforderungen an eine Versionsverwaltung haben. Aus diesem Grund wird gerade der unternehmensweite Einsatz von Bitbucket („adopt“) evaluiert.

Abb. 3: Welche Versionsverwaltung ist die richtige?

Abb. 3: Welche Versionsverwaltung ist die richtige?

Parallel zum unternehmensweiten Ansatz experimentieren wir im Team ständig mit neuen Technologien. Aktuell prüfen wir, welche Vor- und Nachteile Gerrit mit sich bringt („trial“). Diesen Umstand spiegeln wir dann wieder ins Tec Radar zurück und geben damit anderen die Möglichkeit, mit uns in Dialog zu treten. Am Ende sollen die Erfahrungen, die wir mit Gerrit sammeln, wieder dem Unternehmen zur Verfügung stehen.

Von zentraler Bedeutung im MyWebsite-Bereich ist unser ELK-Stack („keep“). Einerseits lassen wir hier sämtliche Applikationslogs in Elasticsearch einfließen. Die flexiblen Darstellungsmöglichkeiten mit Kibana unterstützen uns dann beim täglichen Operating und bei der Fehleranalyse. Anderseits verwenden wir Elasticsearch zur Berechnung der Produkt-KPIs und ergänzen damit wiederum die zentrale Business Intelligence.

Eine der spannenden Fragen, die uns aktuell bewegen, ist die Frage nach der Skalierbarkeit von Middleware-Lösungen. Wir experimentieren derzeit mit Microservices-Architekturen und sehen uns verschiedene Messaging-Systeme genauer an. In der engeren Auswahl ist Apache Kafka („trial“). Hiervon versprechen wir uns in Bezug auf Performance und Nachhaltigkeit sehr viel.

Techniques and Methodologies: Culture 2.0

Innerhalb des MyWebsite-Bereichs spielen agile Vorgehensweisen und Methoden schon lange eine zentrale Rolle. Die Teams sind bestens vertraut mit Entwicklungsmodellen wie Scrum und Kanban („keep“) und können das für sie beste Vorgehen mitgestalten. Weitergetragen werden diese Ideen durch die so genannte Culture-2.0.-Initiative. Diese umfasst Werte wie Ownership und Selbstorganisation und fördert ein Umdenken des gesamten Bereichs („adopt“). Mit dem Tec Radar haben wir die Möglichkeit, diese Ansätze in die Unternehmenskultur einfließen zu lassen.

Und wie oft erstellt man jetzt einen Radar?

An sich ist das jedem selbst überlassen, wie oft man einen Radar erstellt. Wir haben uns vorgenommen, den aktuellen Stand zwei- bis dreimal im Jahr zu aktualisieren und die Veränderungen zu diskutieren. Denn dadurch entsteht ein kontinuierlicher Mehrwert. Über den Technologieradar bekommt jeder mit, mit welchen Technologien sich die Kollegen aus anderen Bereichen beschäftigen und welche sie ablösen wollen. Durch die Kontinuität erhält man im Nachgang auch Erfahrungswerte, welches echte Potenzial und auch welche Schwierigkeiten eine neue Technologie mit sich gebracht hat. Aber auch Informationen darüber, wie aufwendig beispielsweise das Entfernen oder Ersetzen einer weit verbreiteten Technologie war.

Wenn man es genau nimmt, hat die Tec-Radar-Applikation eigentlich gar nicht mehr so viel mit dem Begriff „Technologieradar“ zu tun. Statt eines Radars ist es eher eine Art Lebenszykluskoordinatensystem. Da auch Nicht-Technologie-Elemente vorgesehen sind (Techniques and Methodologies), ist es noch nicht einmal auf „Technology“ festgelegt. Die Applikation selbst ist sicherlich noch ausbaufähig. Diverse Featurewünsche wie ein Benutzer-/Rollenkonzept oder auch eine Heatmap für einzelne Technologien wurden bereits angefragt. Wer die Tec-Radar-Applikation ausprobieren möchte, kann dies unter http://tecradar.design-types.net direkt tun (wird täglich zurückgesetzt) oder auf GitHub forken und die Anwendung selbst an seine eigenen Ansprüche anpassen.

In unserem Fall ist nicht das Tool das Ziel, sondern der Austausch untereinander und das Lernen voneinander. Das Tool hat lediglich Struktur und Motivation in die Diskussion gebracht.

Verwandte Themen:

Geschrieben von
Joachim Betz
Joachim Betz
Joachim Betz ist Teamleiter bei der 1&1 Internet SE. Er beschäftigt sich seit mehr als zehn Jahren mit Softwareentwicklung und IT-Infrastrukturen. Seine Schwerpunkte liegen dabei im Java-Enterprise-Umfeld. Darüber hinaus interessiert er sich für alles rund um die Themen Leadership und agile Methoden.
Matthias Wittum
Matthias Wittum
Matthias Wittum hat sich viele Jahre als technischer Architekt mit der Entwicklung diverser SOAs in einem sehr agilen Umfeld beschäftigt. Mittlerweile leitet er ein Orientierungs- und Weiterentwicklungsprogramm für Softwareentwickler namens 1&1 Source Center.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: