Technologieentscheidungen made in cosee

Ausgangssituation

Wie Konstantin schon in seinem Vortrag “Entscheidungen an die Basis! Aber richtig.” geschildert hat, werden Entscheidungen bei cosee im bzw. durch das verantwortliche Team getroffen. Dies bezieht sich insbesondere auf die Technologien (Programmiersprache, Bibliotheken & Frameworks, etc.), die für ein Projekt eingesetzt werden sollen. Am Anfang hat dies auch gut funktioniert, da auf diese Weise die betroffenen Entwickler direkt entscheiden konnten, was aus ihrer Sicht am besten für das jeweilige Problem geeignet war.

Inspect & Adapt

Mit der Zeit wuchsen die Teams und wir mussten feststellen, dass Technologientscheidungen in der Form mehr schlecht als recht funktionierten und immer häufiger Probleme und Konflikte mit sich brachten. Es wurden Entscheidungen von einzelnen Personen ohne Absprache im Team getroffen (frei nach der „bring your own pet technology“-Philosophie) oder aber es begann die große Völkerwanderung, sobald eine Technologieentscheidung anstand, und alle wollten mitreden.

In Form einer Retrospektive haben wir die Probleme mit bisherigen Technologieentscheidungen gesammelt. Darauf aufbauend wollten wir Mittel und Wege finden, um diese Probleme in Zukunft zu vermeiden. Folgende Probleme haben wir dabei aufgedeckt:

• Mir ist gar nicht klar, was entschieden wird und wann es entschieden wird!
• Ich bin nicht informiert!
• Wer entscheidet mit? Und wer nicht?
• Sind alle Betriebsaspekte abgedeckt?
• Einmal getroffene Entscheidungen werden immer wieder diskutiert und in Frage gestellt!

Es war allen klar: So wie es jetzt ist, geht es nicht mehr weiter. Um dem „cosee-way“ treu zu bleiben, wollten wir das Problem aber nicht gleich mit einem detaillierten, wohl-definierten Prozess erschlagen. Also erarbeiteten wir einen „Rahmenkatalog“, der bei zukünftigen Technologieentscheidungen als Leitfaden helfen soll.

Technologieentscheidung 2.0

Der aus unserer Sicht wichtigste Aspekt bei Technologieentscheidungen ist, dass allen Beteiligten klar sein muss, was entschieden wird. Dabei geht es zum einen um die grundsätzliche Problemstellung, die durch die gewählte Technologie gelöst werden soll. Zum anderen müssen aber auch die zur Wahl stehenden Optionen und deren Eigenschaften sowie etwaige Vor- und Nachteile bekannt sein. Ziel sollte somit sein, anhand dieser Eigenschaften abzuwägen und einen Konsens zu finden, mit dem alle entscheidenden Personen leben können, um anschließenden Diskussionen von vornherein vorzubeugen.

Darüber hinaus muss festgelegt werden, wer die Entscheidung zu treffen hat. Dieser Personenkreis sollte nicht zu groß aber auch nicht zu klein gehalten werden. In diesem Zuge sollte man sich die Frage stellen, wer die maßgeblichen Personen sind, die die Entscheidung zu treffen und anschließend auch zu tragen haben. Unser CTO Konstantin gab uns die folgende Faustformel mit auf den Weg: „Es entscheiden die, die bei Problemen nachts aufstehen müssen.“ Übersetzt heißt das also, dass nicht nur diejenigen entscheiden sollen, die die Technologie in der Entwicklungsphase nutzen, sondern auch diejenigen, die die Technologie später im Produktiveinsatz betreuen müssen. Gemäß der DevOps Maxime „You build it, you run it!“ sind das bei cosee bis auf ein paar Ausnahmen letztendlich aber quasi die selben Personen. Um den Kreis der entscheidenden Personen nicht zu groß werden zu lassen, gibt es darüber hinaus die Möglichkeit, Personen, die etwa schon Erfahrung mit der Problemdomäne oder den zur Auswahl stehenden Technologien haben, als Berater hinzuzuziehen. Diese können dann ihre Erfahrungen oder Meinungen einfließen lassen, werden aber von der eigentlichen Entscheidung ausgeschlossen.

Der resultierende Rahmenkatalog umfasst also zusammengefasst folgende 4 Fragestellungen:

1. Was entscheiden wir?
2. Was sind die maßgeblichen Optionen und deren jeweilige Eigenschaften (Vor- & Nachteile)?
3. Wer sind die maßgeblichen Personen?
4. Wer sind die maßgeblichen Berater? Wer hat sich mit der Technologie schon beschäftigt (fachlich/ technisch)?

Praxisbeispiel: Welche Datenbank wollen wir nutzen?

Der neue Rahmenkatalog kam dann auch direkt bei der Auswahl einer Datenbank für ein neues Projekt zur Anwendung. Zur Entscheidungsfindung erarbeiteten wir eine Matrix, welche die zur Wahl stehenden Datenbanken anhand verschiedener funktionaler als auch nicht funktionaler Anforderungen vergleicht. Diese Matrix ist nachfolgend abgebildet.

Wie sich der Grafik entnehmen lässt, waren auf Seiten der funktionalen Anforderungen an eine Datenbank aus unserer Sicht vor allem die Art der Daten und der Abfragen entscheidend. Dazu kamen kaufmännische (Kosten, Sicherheit) und technische Anforderungen (Skalierbarkeit, Aufwand für Greenkeeping, Monitoring). Wichtig war uns zudem, wie gut sich die Datenbank in unsere bestehende Umgebung in der Cloud integrieren lässt (AWS Integration/ Deployment). Dazu gehört auch die Qualität der API, mit der die Datenbank aus der Applikation angesprochen wird. Und uns interessierten auch Erfahrungen, die mit den zur Wahl stehenden Datenbanken schon vorhanden waren, d.h. allgemeine Best Practices und Pittfalls sowie die persönlichen Erfahrungen der beteiligten Entwickler.

Für die Bewertung der einzelnen Aspekte entschieden wir uns für ein dreistufiges Wertungssystem, „-“ für negativ, „∅“ für neutral und „+“ für positiv. Dieses ist aber beliebig austauschbar, man könnte z.B. auch eine Bewertung anhand von Schulnoten nutzen.

Anhand dieser Matrix haben wir uns dann zusammengesetzt, die verschiedenen Optionen gegeneinander abgewogen und uns letzten Endes erfolgreich auf eine Datenbank einigen können.

Diese Entscheidung liegt nun schon einige Monate zurück. Zurückblickend lässt sich sagen, dass die Entscheidung aus heutiger Sicht absolut die richtige war, mit der alle Beteiligten bis heute zufrieden sind.

Fazit

Mit der in diesem Artikel beschriebenen Methodik für Technologieentscheidungen haben wir für uns ein Werkzeug gefunden, um nachhaltige Entscheidungen als Team zu treffen. Auch wenn wir das Rad vielleicht nicht neu erfunden haben, so haben wir zumindest einen Weg gefunden, der für uns bei cosee aktuell gut funktioniert. Und wenn wir im Laufe der Zeit feststellen, dass das aktuelle Vorgehen nicht mehr funktioniert, dann passen wir uns eben diesen neuen Bedingungen an.