Die diesjährigen Thalia Innovation Days & Hackathon hat Mitarbeitende aus drei Standorten vereint, neue Wege zum Jedi-Meister hervorgebracht und neue Rekorde gebrochen.

Nach den Erfolgen der Thalia Hackathon & Innovation Days 2022 und der Umsetzung der Idee des Live-Commerce Teams wurde dieses Jahr noch mehr Fokus auf Innovation gesetzt. Am 6. und 7. September haben 73 Teilnehmende in interdisziplinären Teams insgesamt 7 Ideen gepitcht und ihre ersten Prototypen direkt vorgestellt. 

Die Teams hatten genügend Ansporn, um die gegebene Zeit für die Ausarbeitung ihrer Ideen möglichst effektiv zu nutzen. Dieses Jahr gab es insgesamt drei Preise zu gewinnen. Die sechsköpfige Fachjury hat einen Preis für die innovativste Idee und deren Umsetzung verliehen. Hierbei wurde das Thema einerseits danach bewertet, wie hoch sein Wert für die Kunden und Kundinnen von Thalia ist. Andererseits sollte das Thema auch realistisch umsetzbar sein.

Beim zweiten Preis dagegen wurde mehr auf die Originalität der Idee geachtet. Ein weiteres Kriterium war das Aufgreifen von aktuellen technologischen Trends bei der Umsetzung. Zusätzlich wurde das Publikum auch dieses Jahr eingebunden und durfte für sein Lieblingsthema stimmen.

Gewinner des Innovation-Preises: Team Krasse Kasse mit „Scan & Go meets SCO“

Niemand mag lange Warteschlangen an der Kasse. Deswegen bietet Thalia Scan & Go an, und erlaubt damit Kund*innen, die in der Buchhandlung unterwegs sind, ihre geliebten Bücher ohne Anstehen mit der Thalia App zu zahlen. Das Team „Krasse Kasse“ hat gemeinsam an der bestehenden Lösung weitergearbeitet, um auch Kund*innen, die auf ein Kundenkonto verzichten, oder z.B. mit ihrer Girocard zahlen möchten, Scan & Go anzubieten.

Das Vorgehen kennt man aus anderen großen Handelsketten: man scannt einfach die Artikel mit der Thalia App, und wählt die Option „an der Kasse zahlen“ aus. Aus dem digitalen Warenkorb wird ein QR-Code generiert, das an der Self-Checkout Kasse gescannt werden kann. Somit lassen sich die Artikel blitzschnell in die Kasse eintragen, und die Kundin darf nun mit allen Kartentypen zahlen, als Rechnung erhält sie den Kassenbonn.

Damit läßt sich ein Self-Checkout Vorgang im Durchschnitt um 25% schneller abwickeln, was neben den Kunden natürlich auch Thalia freut, da damit die mobilen Kassen weiter reduziert werden können. Neben einer voll funktionalen Demo hat das Team bereits Pläne für einen möglichen Rollout und dessen Vermarktung vorgestellt. Eine wirklich krasse Leistung!

Gewinner des Hackathon-Preises: Learn to read with Thalia

Dieses Team wollte eine Lösung entwickeln, um das gesellschaftliche Problem des Analphabetismus in Deutschland zu bekämpfen. Laut Studien sind heute 12.1% der Erwachsenen in Deutschland funktionale Analphabeten. Thalia hat sich bereits als Ziel gesetzt, die Anzahl der Nichtleser zu halbieren. Das Team hat ein Konzept für eine Lese-App entwickelt, und Teile davon als Prototypen umgesetzt.

Zuerst sollen Nutzer anhand des aktuellen Lesegrades in die passende Stufe (von „Padawan“ bis „Jedi Meister“) eingeordnet werden. Natürlich gibt es für jede Stufe Trainingsangebote: von dem Erkennen von einzelnen Buchstaben durch das Vorlesen von langen bzw. zusammengesetzten Wörtern bis hin zu kürzeren Leseproben aus Büchern bekommt jeder Nutzer und jede Nutzerin Hilfe beim Lesenlernen. In der Demo-Lektion konnte die App die Korrektheit des vorgelesenen Satzes bewerten und der Nutzerin eine prozentuale Erfolgsquote anzeigen. 

Gewinner des Publikumspreises: Die Bookshelfies mit „Das Bücherregal, von dem du schon immer geträumt hast“

Fast jeder, der liest, besitzt heutzutage Bücher in sowohl physischer als auch digitaler Form. So verliert man schnell den Überblick über die eigene mentale Büchersammlung. Hatte ich das letzte Fitzek Buch auf meinem Tolino, oder als Paperback? Und warum finde ich das nicht in meinem Regal? Für solche Probleme und für vieles mehr möchten die Bookshelfies eine Lösung bieten, und haben das Bücherregal unserer Träume geschaffen.

Die vorhandenen Bücher können gescannt und blitzschnell ins virtuelle Bücherregal einsortiert werden, bei Käufen im Thalia-Shop passiert das selbstverständlich automatisiert. Handelt es sich um ein digitales Buch, werden Lesefortschritte getracked, können aber natürlich auch manuell eingetragen werden.

Für Vielleser*innen lassen sich die Werke in verschiedene Listen einordnen, die einfach geteilt werden können. Denn unser Bücherregal dient nicht nur zum Überblick, sondern auch zur Bildung der Community: Mitglieder oder einzelne Listen können gefolgt werden, Kunden und Kundinnen können sich für Leseziele und andere Herausforderungen anmelden. So kann man nicht nur das eigene Leseverhalten im Blick behalten, aber sich auch von anderen Mitgliedern inspirieren lassen.

Die Umsetzung hat die Thalia-Community mit Sicherheit überzeugt: die Bookshelfies haben die meisten Stimmen aus dem Publikum erhalten und konnten somit den Publikumspreis abräumen. 

Insgesamt haben wir auch dieses Jahr eine inspirierende Veranstaltung erleben können, die die Kreativität der Teilnehmenden auf beeindruckende Weise zeigte. Die Zusammenarbeit zwischen den Vertreter*innen diverser Bereichen ermöglichte es, frische Ideen und innovative Lösungen für die Herausforderungen der Buchbranche zu entwickeln. Wir sind gespannt darauf, welche bahnbrechenden Ideen nächstes Jahr aus dieser Veranstaltung hervorgehen werden.

In der schnelllebigen Softwareentwicklung ist es wichtiger denn je, dass Anwendungen stabil und zuverlässig funktionieren und die Kundenansprache und das Design in den unterschiedlichen Komponenten der Anwendung möglichst konsistent sind. Aus diesem Grund ist das Testen in verschieden Testebenen, um dem Qualitäts- und Kostendruck gerecht zu werden, ein wichtiger Aspekt. Dieser Blog-Eintrag beschäftigt sich mit UI-Component Tests und einem mächtigen Werkzeug namens Cypress, welches Teams ermöglicht, ihre UI-Komponenten schnell und effizient zu testen. Cypress bietet eine intuitiv verwendbare Oberfläche, die es Entwickler*innen ermöglicht, ihre Tests auf einfache Weise zu schreiben und auszuführen.

Die Situation in unserem Team

Das agile Entwicklungsteam „Kundenbindung und Abo“ (KubA) steht vor der Herausforderung, dass unsere Services immer umfangreichere Front-End Komponenten ausliefern. Wichtig ist dabei, diese nicht nur auf ihre Funktionalität zu testen, sondern auch unseren unterschiedlichen Mandanten (thalia.de, orellfuessli.ch, osiander.de, etc.) regelmäßig auf ihre Konsistenz, beispielsweise in Bezug auf Styling, Wordings und Währungen zu überprüfen. Um dieser Herausforderung zu begegnen, setzten wir zu Beginn nur auf E2E-Tests mit Cypress, die sowohl das Testen der Funktionalität als auch die Überprüfung der Darstellung übernahmen (s. Abb. 1). Mit der Zeit übernahm das Team immer mehr Themen wie Payback, KultClub, Bonus- und Premiumkarte, wodurch immer mehr Frontend ausgeliefert werden musste. Deswegen führten wir zunächst E2E-Tests mit Cypress ein, um das Frontend in diesen Services zu testen, aber diese wurden im Laufe der Zeit immer umfangreicher.

Dies hatte eine erschwerte Wartbarkeit und eine längere Testlaufzeit zur Folge. Außerdem mussten die E2E-Tests auch bei kleinsten Änderungen angepasst werden, weil vergessen wurde, in Teststep „x“ String „y“ zu ändern, was wiederum zu Verzögerungen bei der Entwicklung geführt hat. Deswegen suchten wir nach Lösungen und wurden beim Team „Suchen & Beraten“ fündig. Das Team hatte in Rahmen eines PoCs eine Kombination aus Cypress und Express.js eingesetzt, sodass es möglich war Komponenten und ihre Darstellung für den jeweiligen Mandaten automatisiert innerhalb weniger Sekunden (s. Abb. 2) bereits im Feature-Branch zu testen. Deswegen entschlossen wir uns, dieses Vorgehen für unser Team zu adaptieren, um wieder auf unseren Fail-Fast Ansatz einzuzahlen. In der Testpyramide befinden sich diese Tests auf der Unit-Test Ebene (s. Abb. 1).

Was sind UI-Component Tests?

Doch bevor wir uns sofort in Details verlieren, werden im Folgenden Grundlagen zu den Themen UI-Component Tests und Cypress erläutert.
UI-Component Tests sind ein wichtiger Teil einer unserer Teststrategie, da sie dazu beitragen, die Integrität und Zuverlässigkeit der Benutzeroberfläche (UI) einer Anwendung sicherzustellen. Sie überprüfen, ob die UI wie erwartet funktioniert und ob sie den Anforderungen der Benutzer*innen entsprechen. Außerdem können sie dabei helfen, GUI-/E2E-Tests zu entschlacken, um diese schneller und robuster zu machen.

Warum Cypress?

Cypress ist ein modernes (End-to-End-) Testing Framework, das speziell für die Entwicklung von Web-Anwendungen entwickelt wurde. Es ermöglicht Entwickler*innen, ihre Anwendungen automatisch zu testen, indem es direkt im Browser ausgeführt wird.

Ein wichtiger Vorteil von Cypress ist, dass nicht nur die Funktionalität der Anwendung, sondern auch die Benutzerinteraktion getestet werden kann. Cypress arbeitet direkt mit dem DOM (Document Object Model) und simuliert das Verhalten von Benutzer*innen, was es zu einem idealen Werkzeug für das Testing von UI-Komponenten macht.

Cypress bietet eine einfache und intuitiv verwendbare API, die es Entwickler*innen ermöglicht, ihre Tests schnell und einfach zu schreiben und auszuführen. Es unterstützt automatisch paralleles Testing und bietet umfangreiche Fehlerdiagnose- und Debugging-Funktionen. Infolgedessen können Probleme in ihren Tests identifiziert und effektiv behoben werden.

Cypress ist auch umfangreich dokumentiert und wird von einer aktiven und hilfsbereiten Community unterstützt, die ständig neue Funktionen und Erweiterungen entwickelt. Außerdem kommt Cypress nicht nur bei uns, sondern auch bei vielen anderen Entwicklungsteams im Zusammenhang mit E2E-Tests zum Einsatz, wodurch wir uns die Einführung eines weiteren Tools sparen können.

Das Wichtigste zusammenfassend:

• Echtzeit-Debugging: Cypress bietet eine integrierte Debugging-Umgebung, die es ermöglicht, Tests in Echtzeit auszuführen und zu debuggen. Dies macht es einfacher, Fehler in Tests zu identifizieren und zu beheben.
• Unterstützung für verschiedene Browser: Cypress kann in verschiedenen Browsern wie Chrome, Firefox und Edge ausgeführt werden. Dies ermöglicht es sicherzustellen, dass die UI überall korrekt funktioniert.
• Tool wird bereits verwendet – Knowledge muss nicht erst aufgebaut werden und die Pflege eines weiteren Tools ist nicht nötig
• Große aktive Community – hoher Google-Faktor

Was passiert vor und bei der Testausführung genau?

Abbildung 2 zeigt bereits den Ausschnitt einer Testausführung in einer CI/CD-Pipeline. Doch was passiert da eigentlich genau?

In Abbildung 4 ist eine Komponente in der IDE zusehen, welche bereits unter „tests/cypress“ für vier Mandanten eine Test-Suite samt Test-Cases hinterlegt hat. Da es sich hier um Tests auf Unit-Test-Ebene handelt, müssen diese nicht unbedingt für nicht-Entwickler*innen lesbar sein, weswegen an dieser Stelle auf einen Cucumber-Vorbau verzichtet wurde, welcher aber durchaus möglich wäre.

Statische Testumgebung aufbauen

Bevor die Tests gestartet werden können, wird die zu testende Komponente, die sich im Wesentlichen hinter der index.hbs verbirgt, in eine statische Seite überführt. Der konkrete Zustand dieser Seite wird über die model.config.json konfiguriert. Diese erlaubt es, mehrere Varianten (variants) derselben Komponente zu definieren, sodass umfangreiches Testen möglich ist. Beispielsweise werden in dieser Komponente Kund*innen unterschiedliche Aktionen angeboten, abhängig davon, ob es sich um ein aktives, pausiertes oder gekündigtes Abo handelt. Mithilfe der Variante können all diese Zustände bespielt werden. Wenn die statischen Seiten gebaut sind, sind diese im Ordner

„target/classes/hbs-templates/[service]/resources/[componente]“

auffindbar.

Express.js liefert die Testseiten aus

Wenn nun der Express.js Server gestartet wird, ist es möglich über den Browser die Komponenten, die uns als Testbasis dienen, aufzurufen:

Abbildung 5 zeigt die Mandanten, für die unsere Testseiten gebaut wurden. Auf Abbildung 6 hingegen sind die einzelnen Frontend-Komponenten des Services zusehen. Dahinter verbirgt sich dann die Seite, gegen die Cypress im Anschluss unsere Tests laufen lässt. Dies geschieht in der Pipeline natürlich headless, aber während der Implementierung haben Entwickler*innen die Möglichkeit, die Testausführung im Browser zu betrachten. Mit einem watcher werden die statischen Komponenten bei jeder Änderung automatisch neu gebaut und die Tests direkt neu gestartet, sodass Entwickler*innen die Möglichkeit haben bequem Test-Driven oder Test-First zu arbeiten.

Aufbau und Organisation der Tests

UI-Component Tests mit Cypress werden mithilfe von sogenannten Test-Suites organisiert, die für jeden Mandanten nach Notwendigkeit angelegt werden können. Eine Test-Suite ist eine Sammlung von Tests, die alle ein bestimmtes Ziel verfolgen. Jede Test-Suite besteht aus einem oder mehreren Test-Cases, die wiederum aus einer Reihe von Test-Schritten bestehen.

Test-Suites können für jeden benötigten Mandanten in einem separaten Test-File angelegt werden. Ob dies nötig ist, entscheidet die Test-Strategie und schlussendlich die Entwickler*innen. Bei simplen Komponenten, die wenig mandantenspezifisches Verhalten aufweisen, ist es häufig sinnvoll, um Redundanz zu vermeiden, in weiteren Test-Suites nur genau diese zu testen oder ganz auf diese zu verzichten.

Eine Test-Suite beginnt mit der Beschreibung über ein describe(), das beispielsweise die getestete Komponente und den Mandanten enthalten sollte (s. Abb. 7): Hier die Komponente abo-aktionen und der Mandant Thalia.de. Vor jedem Lauf wird die Testumgebung der Komponente aufgerufen, das passiert über

cy.visit("2/abo-aktionen")

im beforeEach()-Block. Die zwei im Pfad steht dabei für den Mandanten Thalia.de. Das it() kennzeichnet den Beginn eines Test-Case. Dabei haben Entwickler*innen die Möglichkeit zu beschreiben, was genau der Test prüft. Innerhalb der geschweiften Klammern sind die Test-Steps definiert. Im vereinfachten Beispiel wird das HTML-Object mit dem Selektor data-test“HelloWorld“ aufgerufen und dann geprüft, ob dieser sichtbar ist und einen bestimmten Text enthält. Hier sind Entwickler*innen fast keine Grenzen gesetzt, wie die offizielle Dokumentation zeigt.

Was bedeutet das jetzt konkret? Beispiel!

Zu sehen (s. Abb. 8) ist die Seite in unserem Shop, auf der Kund*innen den aktuellen Status ihres Hörbuch-Abonnements einsehen und verwalten können. Die Darstellung wurde bisher vollständig durch deutlich langsamere E2E-Tests geprüft. Da es Kund*innen mit Abonnements in fünf verschiedenen Status (aktiv, pausiert, gekündigt, beendet oder ohne Abonnement) geben kann erhöht sich die Laufzeit stark, denn die funktionalen Tests mussten zusätzlich die korrekte Darstellung sicherstellen. Dadurch wurden die Tests massiv aufgebläht, was wiederum zu einer verdoppelten Laufzeit und mehr unzuverlässigen Tests führte. Wartbarkeit wurde zu einem Problem, das die Feature-Entwicklung verzögerte oder sogar dazu führte, dass Tests vorübergehend deaktiviert wurden. Durch die Einführung der UI-Component Tests konnten wir die blauen markierten Flächen in den E2E-Tests komplett ignorieren. Die grünen Flächen spielen weiterhin eine Rolle, allerdings nur funktional. Das heißt wir prüfen hier nicht auf Darstellung und/oder Wording, sondern gehen nur den Kundenprozess durch und schauen nicht abseits des Weges.

Im Rückspiegel

UI-Component Tests können ein wichtiger Bestandteil der Teststrategie sein. Für uns ist dabei Cypress das richtige Tool. Es ermöglicht eine schnelle und einfache Testdurchführung und lässt sich problemlos in CI/CD-Pipelines einbauen und automatisieren. Ein wichtiger Faktor bei der Tooleinführung in unserem Team war ein niedrigschwelliger Einstieg, der durch die Verwendung von Cypress als E2E-Testing Tool gegeben war. Aber es sollte eine kritische Frontend-Masse gegeben sein, damit sich eine Einführung lohnt, denn es erfordert schon ein Anpassen des Arbeitsablaufs bei der Frontend-Entwicklung. Das muss aber nicht unbedingt negativ sein, denn es bietet, mit dem richtigen Setup, auch die Chance, Test-Driven oder Test-First Development zu betreiben. Schlussendlich wird zunächst zusätzliche Arbeitskraft durch das Etablieren einer zusätzlichen Testebene investiert, wodurch aber ein Vielfaches eingespart wird, indem weniger Fehlermeldungen aufkommen und effektiver entwickelt wird.

Harder, better, faster, stronger

Nach dem Erfolg des rein digitalen Hackathons 2021 haben wir uns dieses Jahr größere Ziele gesetzt. Mehr Teilnehmende aus verschiedenen Abteilungen und Standorten, mehr Zeit, und das ganze vor Ort.

Insgesamt 70 Teilnehmer*innen aus Münster, Berlin, Hagen und Aachen haben über anderthalb Tage an sieben spannenden und innovativen Themen gearbeitet, die Thalia einen weiteren Schritt digital exzellenter machen. Nach der Abschlusspräsentation vor über 150 Kolleg*innen wurden drei Teams von einer Fachjury aus verschiedenen Bereichen geehrt und ein Publikumspreis vergeben.

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

PGlmcmFtZSB0aXRsZT0iVGhhbGlhIEhhY2thdGhvbiAyMDIyIiB3aWR0aD0iOTQwIiBoZWlnaHQ9IjUyOSIgc3JjPSJodHRwczovL3d3dy55b3V0dWJlLW5vY29va2llLmNvbS9lbWJlZC9oOVBtLVAyTTFtdz9mZWF0dXJlPW9lbWJlZCIgZnJhbWVib3JkZXI9IjAiIGFsbG93PSJhY2NlbGVyb21ldGVyOyBhdXRvcGxheTsgY2xpcGJvYXJkLXdyaXRlOyBlbmNyeXB0ZWQtbWVkaWE7IGd5cm9zY29wZTsgcGljdHVyZS1pbi1waWN0dXJlOyB3ZWItc2hhcmUiIGFsbG93ZnVsbHNjcmVlbj48L2lmcmFtZT4=

Live Commerce

Ein Trend aus dem asiatischen Raum, der derzeit auch nach Europa überschwappt, ist „Live Commerce“. Hierbei geht es um eine noch engere Omnichannel-Verzahnung, indem stationäre Beratungskompetenz auch online zugänglich gemacht wird. Auch Sichtbarkeit und Präsenz der Marke Thalia sowie eine Stärkung der Social-Media-Kanäle und des Social Commerce sind erhoffte Effekte.

Das Team konnte mit einem gut durchdachten Business Case und einer kurzweiligen Live-(Commerce-)Präsentation sowohl Jury als auch Publikum überzeugen und holte sich so den ersten Preis und den Publikumspokal.

Visual Search

Bilderkennung boomt und wird immer besser. Neben dem Schulbuch-Scanner, der EANs auf einem Schulbuch-Zettel erkennt, gibt es noch weitere Business Cases mit großem Potenzial. Scannt man ganze Regale und erhält so eine Liste der Bücher, kann dies bei der Inventarisierung in der Buchhandlung helfen oder dabei, Empfehlungen auszuspielen.

In einem Designsprint wurden die verschiedenen Ideen evaluiert und parallel ein erster Prototyp einer iOS-App gebaut, welche die Texte auf dem Buchrücken erkennt und den Artikel identifiziert. Diese Kombination fachlicher und technischer Expertise führte das Team zur Silbermedaille.

Attribute von Panem

Mit einer Vielzahl an (Daten-)Lieferanten und 13 Millionen Artikeln im Webshop ist die Pflege der Artikeldaten eine große Herausforderung. Dieser hat sich das Team angenommen und verschiedene Prozessverbesserungen entwickelt, um dauerhaft eine noch höhere Datenqualität zu erreichen.

Einen großen Anteil hat dabei Gamification. Beispielsweise kann es in Zukunft interne Challenges geben, bei denen in einem abgesteckten Zeitraum möglichst viele Artikel gepflegt werden sollen. Mit diesem Ansatz sicherte sich das Team den dritten Platz und schon einige Anmeldungen für die kommenden Challenges!

Buch-Finder

Bei #booktok werden Bücher empfohlen und teilweise in hoher Frequenz oder gespiegelt in die Kamera gehalten. Um Bücher wiederzufinden, an die man sich vielleicht nicht mehr allzu gut erinnert, wurde der Buch-Finder entworfen. Mit Hilfe von Machine Learning wurden Informationen aus Artikelbildern extrahiert, um auf diese filtern zu können.

Neben #booktok sah das Team noch weitere Potenziale wie beispielsweise die Ausweitung auf weitere Sortimente und die Unterstützung der Kolleg*innen in den Buchhandlungen.

AutoDoc für (Micro)Services

Unter dem Motto „klassische Dokumentation ist in dem Moment veraltet, in dem sie geschrieben wird“ schloss sich ein Team zusammen, um die fachliche Dokumentation von Services im Code zu ermöglichen und dadurch aktuell zu halten.

Fragen wie „Was macht dieser Service?“ oder „Mit welchen Services kommuniziert er?“ wurden in diesem auf SpringAnnotation basierenden Framework schon im Code beantwortet und automatisiert in eine visuelle Repräsentation überführt. Eine Lösung mit viel Potenzial, die die Abstimmung zwischen verschiedenen Teams stark vereinfachen würde!

Don’t look up!

Im Thalia-Webshop gibt es eine Vielzahl von Sortimenten und Kategorien. Während Oberkategorien händisch kuratiert werden, ist dies bei der schieren Anzahl von Unterkategorien nicht möglich. Um den Kund*innen beim Stöbern einen besseren Überblick über die gewählte Kategorie zu geben, wurde mittels Text Mining der Artikelbeschreibungen beispielhaft eine Wortwolke der Kategorie „Brettspiele“ erzeugt.

Der potenzielle Business Value wurde vom Team anhand verschiedener Szenarien evaluiert, die z.B. die Verringerung der Ausstiegsrate berücksichtigten.

In-Store-Navigation

Eine Unterstützung für Kund*innen und Kolleg*innen in den Buchhandlungen ist die In-Store-Navigation, die Suchende und ihr Buch zusammenbringt.

Das Team zeigte verschiedene Ausbaustufen auf, von der Markierung des Regals auf der Karte über mit Pathfinding-Algorithmen gezeichneten Wegen bis hin zu Augmented Reality.

Zusammenfassung

Der Hackathon war ein voller Erfolg! Mit spannenden Technologien wie Texterkennung (OCR), Text Mining und Machine Learning wurden innovative Prototypen entwickelt. Der Blick über den Tellerrand, sowohl innerhalb von Thalia bei der Zusammenarbeit mit Kolleg*innen anderer Abteilungen, als auch außerhalb wie bei dem Sieger-Thema „Live Commerce“ war eine willkommene Abwechslung und hat zu großartigen Ergebnissen geführt.

Wir freuen uns auf jeden Fall auf das nächste Mal!

Platform ENGineering bei Thalia eCommerce kommt aus dem klassischen IT-Operations und entwickelt sich weiter zu einem agilen cross-functional Team.

Bei Thalia bewegt sich im Moment echt viel!

Aus der klassischen IT-Welt kommend mit Anforderung, Entwicklung, QA und Operations etablieren wir eine Omnichannel-Produkt-Organisation mit dem Ziel, coole Features schnell den Kunden und Kundinnen auf allen Touchpoints/Berührungspunkten mit Thalia zur Verfügung zu stellen. Neben Standard-Features, die z.B. eine App, ein eReader oder auch ein Online-Shop haben muss, macht die Entwicklung von Features, die Mitbewerber nicht anbieten können, am meisten Spaß.

Alles auf einer zentralen und modernen Plattform

Genau diese und alle weiteren Features benötigen eine moderne, robuste und verfügbare Plattform. Diese Plattform betreibt und entwickelt das Team „Thalia Platform Engineering“. Das Team besteht aus Datenbank-, Linux-, Security- und Infrastruktur-Spezialisten. Jeder im Team bringt seine besondere Fähigkeit ein, um am Ende das beste Ergebnis für unsere Kunden und Kundinnen zu produzieren.

Mit unserem Team unterstützen wir die Software-Delivery-Teams in Münster und Berlin. In unseren Rechenzentren betreiben wir mehrere hundert Server, die zum Großteil virtualisiert sind. Automatismen machen uns die Arbeit immer leichter und werden kontinuierlich weiterentwickelt.

Viele alltägliche Operation-Jobs werden direkt in den jeweiligen Produktteams erledigt, was die Teams schnell und unabhängig macht. Im Platform Engineering Team entwickeln und betreiben wir Produkte wie z.B. eine Logdaten-Management-Infrastruktur mit >100.000 Events/s, eine automatisierte Monitoring- und Alarmierung-Infrastruktur inkl. Timeseries Database, einen Selfservice zum automatischen Bereitstellen von produktionsbereiten Servern inkl. Anwendung und zugehöriger Konfiguration sowie Datenbanken in der Bandbreite von der kleinsten Datenbank für eine einzelne Anwendung bis hin zum hochleistungsfähigen Datenbank Cluster.

Es geht nur mit einem tollen Team

Im Team legen wir Wert auf eine gute Stimmung und eine gute Kultur. Uns ist es wichtig eigenverantwortlich zu arbeiten, Fehler machen zu dürfen und daraus zu lernen, um noch schneller und besser zu werden. Besonders coole Fehler werden gerne mit einem T-Shirt gefeiert.

Know-How ist ein sehr wichtiger Schlüssel. Wo es möglich ist organisieren wir interne Sessions/Workshops, besuchen externe Veranstaltungen oder buchen interne/externe Schulungen.

Auch das Team entwickelt sich weiter. Agile Methoden und klassische Operations. Geht das? Macht das Sinn? Wir wissen es noch nicht. Jedoch experimentieren wir zusammen mit einem Agile Coach sehr viel mit SCRUM und Kanban in diesen Bereichen und spüren bereits erste Erfolge. Eine 1:1-Kopie der Methodik aus dem Development-Bereich passt jedoch nicht. Wir erarbeiten unser eigenes auf uns zugeschnittenes Model.

Nachwuchs ist willkommen

Natürlich bilden wir auch „Fachinformatiker FR Systemintegration“ aus. Auszubildende haben bei uns die Chance, sich so ungefähr alles, was eine IT zu bieten hat, anzuschauen und sich auszutoben. Wir bieten Windows, Linux, Virtualisierung, Rechenzentrum, Automation, Software Entwicklung, DevOps, Agile Mindset, Datenbanken, Mailsysteme, Web, Tomcat, FTP, … und die Liste geht noch ewig so weiter 🙂

Unser Team wächst weiter

Unser Team und unsere Produkte entwickeln sich immer weiter. Daher suchen wir permanent Leute, die Lust haben etwas zu bewegen. Schau einfach mal unter JOBS vorbei.