Thomas Lischetzki, Senior Business Consultant bei FactSet

− in Kooperation mit FactSet −

Thomas gewährt uns einen Einblick in seine Doppelrolle als Berater und Product Owner und erklärt uns welche Anforderungen der Finanzsektor an die digitale Produktentwicklung hat.

Hallo Thomas, was ist deine Aufgabe bei FactSet?

Ich bin Senior Business Consultant und arbeite seit Juli 2016 als Product Owner für unsere API, für die wir einen komplett neuen Anwendungsfall entwickelt haben. Über die entwickelten Endpunkte können unsere Kunden MiFID-II-Daten abfragen. Das Projekt ist Teil eines großangelegten Produktentwicklungsprogramms von FactSet, mit dem wir die digitale Transformation unserer Kunden mit maßgeschneiderten Lösungen auf Basis einheitlicher Softwareprodukte leisten wollen.

Neben einzelnen Features bin ich außerdem für die Weiterentwicklung der API zuständig. Dabei beschäftigt uns die Frage, inwiefern wir unkritische Teile unserer Infrastruktur in die Cloud auslagern können.

Wie kommt es, dass du als Berater die Funktion eines PO ausführen kannst?

Ursprünglich bin ich Entwickler, habe eine Ausbildung als Fachinformatiker in der Anwendungsentwicklung gemacht und Informatik studiert. Ich habe ein paar Jahre als Entwickler gearbeitet, bin dann in die technische Projektentwicklung gegangen und habe mich so immer weiter in Richtung Berater entwickelt. Bei FactSet habe ich mit dem klassischen Consulting angefangen. Als dann die Weiterentwicklung der API anstand, habe ich aufgrund meiner Vita den PO-Job dazugenommen. Jetzt stehe ich als Vermittler zwischen den Anforderungen der Kunden und der Produktentwicklung.

Wie viel Prozent deiner Arbeit sind Consulting, wie viel PO?

Das hängt davon ab, wo gerade der Schuh drückt. Im Moment haben wir das Produkt ganz gut an den Kunden gebracht und wir fokussieren uns auf die Weiterentwicklung. Beratung findet immer wieder mal statt, aber die Produktentwicklung steht zurzeit klar im Vordergrund.

Da es nicht ganz selbsterklärend ist: Was macht ihr bei FactSet?

FactSet als Lösungsanbieter im Finanzbereich bedient grundsätzlich den kompletten Portfolio-Lebenszyklus eines Investmentprofis von Informationen und Daten, über Risiko und andere Analysetools sowie Order-Management bis hin zum Reporting. Ich arbeite bei FactSet für die Produktsparte „Digital Solutions“ wo wir grundsätzlich Lieferant von Informations-Systemen für Banken als auch Dienstleister sind. Wir liefern Produkt- und Stammdaten für die Marketingseiten der Kunden, aber auch für deren interne Systeme und Anwender. Das können riesige Datenmengen sein, die wir über Anbindungen an Börsen im Millisekundenbereich hereinbekommen. Diese bereiten wir auf, und je nachdem was der Kunde benötigt, geben wir zum Beispiel Realtime-Kurse heraus. Um die Performance gewährleisten zu können, nutzen wir dafür weitestgehend eigenentwickelte Datenbanken, die je nach Anwendungsfall auch in-memory basiert sind.

Um was geht es bei dem Projekt mit den MiFID-II-Daten?

MiFID II ist eine EU-Finanzmarktrichtlinie, die seit Anfang des Jahres gilt und den Wertpapierhandel reguliert. Die Regulation besagt jetzt ab dem 1. Januar 2018, dass zum Beispiel beim Kauf eines Fonds eine Art “Beipackzettel” (PRIIP KID) beiliegen muss, der den Endkunden über die Risiken und Pflichten informiert, um das, was während der Finanzkrise passiert ist, künftig zu verhindern. Banken, die Fonds anbieten, müssen also immer diesen Beipackzettel mitliefern. Es gibt allein in Europa weit über 400 Fonds-Anbieter. Für Banken ist es nahezu unmöglich, diese Anbieter selbst zu integrieren.

Darum haben wir das Produkt “Regulatory Document & Data Service (RDDS)” entwickelt, mit dem Banken zuverlässig und schnell auf die Beipackzettel zugreifen können. Zum einen ist es für uns spannend ein Produkt zu entwickeln, das wir weitestgehend standardisiert haben und an viele Kunden gleichzeitig ausliefern. Zum anderen ist es für viele Banken neu, dass sie keine teure Individualentwicklung bekommen, sondern ein Produkt wie zum Beispiel unsere API lizensieren. Hier arbeite ich praktisch an zwei Fronten.

Um was geht es bei dieser API?

Unsere API ist die Middleware, mit der wir verschiedene Produkte entwickeln, und die auf unsere verschiedensten Backend-Systeme zugreifen kann. RDDS ist ein solches Produkt. Ein anderes ist zum Beispiel, dass man ähnlich wie im Amazon-Shop eine Empfehlung bekommt. “Leute, die diesen Fonds gekauft haben, haben sich auch für dieses Wertpapier interessiert.” Das kann für den einzelnen Anwender durchaus eine relevante Information im Entscheidungsprozess sein.

Welche Rolle hast du bei der Entwicklung der API gespielt?

Bei der API war ich unter anderem Impulsgeber und habe die Bedarfe der anderen Produkte erarbeitet. Eine Anforderung eines Produktes war beispielsweise, dass die API problemlos drei Milliarden Anfragen im Monat für einen bestimmten Use Case aushalten muss. Es gab interne Anforderungen, aber auch solche von Kunden. Ich habe diese zusammengetragen.

Wir haben bei der Entwicklung einen Balanceakt vollzogen und in unserem Produktentwicklungsprogramm eine grundlegende, technische Ebene entwickelt, die gleichzeitig von anderen Projekten und Produkten genutzt wurde. Wir haben praktisch den Teppich geklöppelt, auf dem wir standen.

Lass uns auf die Entwicklung von RDDS eingehen. Wie seid ihr dabei vorgegangen?

Bei RDDS handelt es sich um einen regulatorischen Dokument- und Datenservice, was inhaltlich eher trocken ist, technisch aber spannend. Die Hauptaufgabe ist die Bereitstellung von regulatorischen Dokumenten, also diesen Beipackzetteln. Schritt eins war es, alle Dateien über den gesamten Markt einzusammeln, zu konsolidieren und dann unseren Kunden zentral zur Verfügung zu stellen.

Technisch spannend ist, was durch die Regulation an Anforderungen gestellt werden: Die Finanzinstitute haben sehr lange Speicherfristen. Das führt dazu, dass wir pro Woche regulatorische Dokumente mit einer Datenmenge von 500 Gigabyte neu dazubekommen.

Was für Daten sind das genau?

Das sind simple, dreiseitige PDF-Dokumente, die schon ziemlich gut komprimiert sind. Dennoch: Es sind jede Woche 500 Gigabyte, die wir zudem mindestens zehn Jahre lange speichern müssen.

Im Frühjahr 2016 haben wir auf der grünen Wiese mit der Entwicklung angefangen und unsere Deadline war Ende 2016, denn bei einem Liefertermin erst in 2017 wären unsere Kunden nur schwer in der Lage gewesen ihre Projekte umsetzen zu können. Wir waren also gezwungen, die Deadline zu halten, und standen dann vor der Entscheidung “Make or Buy”. Es gibt Komponenten des Produkts, die wir nicht selbst entwickelt haben. Zum Beispiel grundlegende Themen wie die Versionierung von Dokumentenversionen werden über am Markt vorhandene Document Management Systeme wie Nuxeo bereits gut abgedeckt. Wir erfinden das Rad auch nicht immer wieder neu, nur weil es klasse ist, alles selbst zu entwickeln.

Was habt ihr für die Suche genommen?

Für die Indizierung und Suche haben wir uns für Elasticsearch entschieden.

Wie groß ist das Team?

Das Team für RDDS ist aktuell acht Personen stark und besteht zum einen aus Frontend-Entwicklern, die für die Web-Applikationen verantwortlich sind, über die Kunden auf das Archiv zugreifen und selbst Dokumente hochladen können. Zwei Entwickler arbeiten im Import- und Export-Bereich. Sie schieben das Material in die Systeme und kümmern sich um die Performance. Zwei Backend-Entwickler kümmern sich um die Erweiterung der API. Das sind Module, die neue Endpunkte zur Verfügung stellen. Wenn man dann noch unsere Server-Administratoren dazunimmt, haben wir vier Frontend- und vier Backend-Entwickler.

Wie sieht es mit Design aus?

Unsere Designer sind nicht Teil unseres Teams, aber auf Abruf bereit, wenn wir zum Beispiel einen neuen Bereich für die GUI brauchen oder wenn es um Prozessfragen geht. Unser Produkt ist ja letztlich nicht für den Kunden sichtbar, und das, was sichtbar ist, ist nur ein kleiner Teil für einen sehr eingeschränkten Benutzerkreis. Bei uns geht es mehr um den technischen Unterbau. Der muss robust sein, funktionieren und hoch performant sein. Darauf legen wir den Fokus.

Mit welchen Tools arbeitet ihr?

Wir nutzen Jira und Confluence, zwei Systeme, die im täglichen Doing eingesetzt werden. Als Projektmanagementmethode setzen wir Scrum ein. Insofern ist Jira dafür prädestiniert, in dem wir unser Standard-Backlog mit konkreten Features haben, die in das Produkt fließen sollen. Confluence ist unser Collaboration- und Dokumentations-Tool. Prosa, die beschreibt, wohin wir mittel- bis langfristig hinwollen.

Wie kommt bei FactSet ein neues Feature in ein Produkt?

Als Consultant wirke ich beim Prozess mit, der unsere Strategie für die Zukunft festlegt, und als Product Owner priorisiere ich die Features für die nächsten zwei, drei Sprints. Obwohl wir verstärkt unsere eigenen Produkte entwickeln, gewinnt in der Priorisierung dann meist die Kundenanforderung – sie erhält häufiger eine höhere Priorisierung.

Welchen Sprint-Zyklus habt ihr?

Wir haben einen Drei-Wochen-Sprint-Rhythmus. In unserem Prozess, der aus Daten sammeln, umsetzen und visualisieren besteht, hat sich gezeigt, dass das der beste Sprint-Rhythmus ist.

Dabei versuchen wir, nah am Scrum-Standard zu arbeiten. Im Grooming zum Beispiel brechen wir die Tasks auf die einzelnen To-dos runter und am Ende des Sprints gibt es dann die Planning-Phase für den nächsten Sprint. Hier kann das Team sagen, was von der Kapazität her klappt, was rausfliegt und was später gemacht wird. Wichtig ist, dass man am Ende des Sprints wenigstens eine neue Funktionalität entwickelt hat.

Wie seid ihr beim Thema Testing aufgestellt?

Wir nutzen dazu Testrail als Testverwaltungslösung und wir haben natürlich unsere Buildsysteme. Alles, was eingecheckt ist, wird automatisch gebaut und dann gleich über automatisierte Tests überprüft, ob das, was wir gebaut haben, grün ist oder ob wir das System damit abgeschossen hätten.

Außerdem haben wir in unserem Team eine Testerin, die auch Bestandteil der Frontend-Entwicklung ist, aber einen starken Fokus auf Testing hat. Sie testet manuell, was noch nicht automatisiert getestet wird. Sie testet alle Features und Funktionalitäten und hat sogar in Jira einen eigenen Step. Sie schaut sich alles einmal an und gibt dann grünes Licht, in dem sie es in “ready for deployment” weiterschiebt. Sie ist außerdem Teil der Testing-Abteilung, die in unserer Firma für das Thema Testing und Erstellen von Testfällen in allen Projekten und Produktentwicklungsbereichen verantwortlich ist.

Gerade bei dieser Art von Produkt, das so so hohen Ansprüchen genügen muss, ist das Testing-Team ein zentrales und sehr wichtiges Team, das überall integriert ist. Das macht absolut Sinn.

Welche Tools nutzt ihr noch?

Da wir eine JSON-API haben, ist Postman unser Tool, um schnell mal was nachzuschauen. Wir setzen außerdem weitestgehend selbst entwickelte Monitoring-Tools ein. Denn wir wollen als Erster wissen, wenn etwas nicht mehr so performant ist, also bevor es der Kunde bemerkt.
Für die Kommunikation mit den Kunden nutzen wir ein dediziertes Servicedesk in Kombination mit einem Ticketsystem, das wir selbst entwickelt haben, als es Jira noch nicht gab und das extrem gut auf unsere Prozesse abgestimmt ist. Für die Teamkommunikation, gerade auch mit dem Remote-Team, setzen wir Zoom ein.

Ich persönlich nutze meinen Notizblock häufig, da ich es wesentlich persönlicher finde, als mit dem Laptop im Meeting zu sitzen. Der kommt neben dem Laptop überall mit hin.

Was wissen die meisten nicht über deinen Job?

Das er stressig sein kann, wissen glaube ich viele. Die wenigsten wissen aber, dass dieser Bereich trotz der Ansiedlung in der Finanzwelt sehr locker und auch auf einem persönlichen Level interessant ist. Grundsätzlich ist man auch im Finanzbereich relativ schnell per Du.

Trotz Hemd?

Ja. Das mag man hinter der Businesskleidung und den Glasfassaden in Frankfurt nicht vermuten. Aber das geht doch recht schnell.

Gibt es etwas, was in deinem Job immer wieder falsch gemacht wird?

Es wird immer wieder falsch gemacht, nicht den pragmatischen Mittelweg zu sehen. Entweder muss es eine technisch supergeile Lösung sein, die den Bedarf dann doch nicht deckt, oder eine Lösung, die technisch überhaupt nicht möglich ist. Da den Mittelweg zu finden, ist die schwierige Aufgabe, und das geht auch häufiger mal schief.

Welche Themen sind in deinem Bereich gerade spannend?

In der Finanzbranche ist es tatsächlich die digitale Transformation. Die Hauptnutzer sind inzwischen Leute, die mit den ganzen technischen Gadgets großgeworden sind. Die gehen nicht mehr in eine Bankfiliale, sondern die wollen alles unterwegs und möglichst über einen Kanal machen. Diese Trendwende haben die Banken eine zeitlang verschlafen und es gibt jetzt einen Riesendruck. Es drängen gerade richtig viele Player auf den Markt. Und da bringt es nichts, einfach nur eine App auf bestehende Services zu bauen. Es geht auch um ein neues Servicemodell.

Ein anderes Thema ist Robo-Advising, was gerade überall herumgeistert, also Beratung durch Algorithmen. Die beraten dann aber auch nicht nur, sondern entscheiden selbst, was gekauft und verkauft werden soll.

Welche Blogs liest du, welche Bücher kannst du empfehlen?

Um auf dem Laufenden zu sein, lese ich Heise und Golem. Ein amerikanischer Banking Blog, den ich empfehlen kann, ist Gonzobanker. Der betrachtet das Geschehen etwas kritischer. Ähnlich wie Insideparadeplatz. Der Paradeplatz ist der große Platz in Zürich, um den herum alle großen Banken ihren Sitz haben. Dieser Blog beleuchtet die Szene kritisch, hat aber auch den Hang, Klatsch und Tratsch aus den Bankentürmen zu berichten.

Als Buchempfehlung kann ich “The Phoenix Project” empfehlen. Das ist ein interessantes Buch, da Scrum aus einer erzählerischen Perspektive beleuchtet wird und man erst später, wenn man im Glossar nachliest, merkt, dass man sich gerade mit dieser oder jener Methode beschäftigt hat.

Was kannst du Leuten empfehlen, die etwas Ähnliches wie du machen möchten?

Ein Studium ist aus meiner Sicht kein Must-have. Was ich im Rückblick auf meine Vita als durchaus hilfreich betrachte, ist die Interdisziplinarität. Ich bin vom Bereich Technik in die Beratung gewechselt und das war für mich absolut hilfreich. So konnte ich nachvollziehen, warum es an einer Stelle hakt, was sinnvoll ist und was nicht.

In der Finanzbranche muss man sich natürlich im Klaren darüber sein, dass es auch trockene Themen gibt. Aber ob du jetzt bei Amazon oder Google terabyteweise mit Daten zu tun hast oder dies für eine Bank umsetzt: Die Mechanismen, die technischen Herausforderungen sind ähnlich und das ist hier genauso spannend wie auf der anderen Seite.

Lieber Thomas, vielen Dank für das Interview!

Dieses Interview wurde am 14. März 2018 in Kooperation mit FactSet in den Räumlichkeiten von FactSet in Frankfurt gehalten.