− 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.

Vita

Nach seiner Ausbildung als Fachinformatiker in der Anwendungsentwicklung studiert Thomas Informatik an der Berufsakademie Mannheim. Er arbeitet einige Jahre als Entwickler und orientiert sich mehr und mehr in Richtung technische Projektleitung. Schließlich beginnt Thomas bei FactSet als Berater, kehrt dort aber als PO wieder in die technische Projektleitung zurĂŒck.

Tools

  • Jira, Confluence
  • Testrail
  • Postman
  • Zoom

Empfehlungen

  • Blog: Heise.de, Golem, Gonzobanker, Insideparadeplatz
  • Buch: The Phoenix Project

Social

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.

Digitale Leute - Thomas Lischetzki - Factset - Thomas Lischetzki ist Senior Business Consultant und arbeitet seit Juli 2016 als Product Owner fĂŒr ihre API, fĂŒr die sie einen komplett neuen Anwendungsfall entwickelt haben.

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.

Digitale Leute - Thomas Lischetzki - Factset - Thomas Lischetzkis Team arbeitet an Informationssystemen fĂŒr die Kunden aus dem Finanzsystem.

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 Produktentwicklungsrogramm 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.

840x__img_6887_bearbeitet

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.

840x__img_6891_bearbeitet

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.

1800x__img_6931

Digitale Leute - Thomas Lischetzki - Factset - Bei der Entwicklun der zentralen API war Thomas Lischetzki als Impulsgeber beteiligt.

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.

Digitale Leute - Thomas Lischetzki - Factset - Das Office von Factset in Frankfurt ist in eine ehemalige Fabrikhalle aus dem 19. Jahrhundert gebaut worden.

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.

Digitale Leute - Thomas Lischetzki - Factset - Thomas' Team arbeitet mit anderen Teams im Unternehmen zusammen, was gute Absprachen fordert.

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.

Digitale Leute - Thomas Lischetzki - Factset - Bei Factset hat Thomas als klassischer Berater begonnen, wurde dann aber aufgrund seiner Erfahrung in der Entwicklung als Produkt Owner fĂŒr die Weiterentwicklung der API angefragt.

Digitale Leute - Thomas Lischetzki - Factset - Thomas Lischetzki ist ursprĂŒnglich Entwickler und hat sich im Laufe der Jahre immer weiter in die Beratung weiterentwickelt.

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!

Digitale Leute - Thomas Lischetzki - Factset - Thomas Lischetzki, Senior Business Consultant bei Factset auf dem Balkon des Frankfurter Office.

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