Das interne Projekt Lithosphere ist eine technische Plattform für alle esentri Mitarbeiter und wurde dieses Jahr ins Leben gerufen. Es basiert auf dem ersten Lithosphere-Projekt aus den Vorjahren, bei dem bereits die internen operativen Prozesse von esentri wie die Erfassung von Arbeitszeiten, das Einreichen von Urlaubsanträgen und Krankmeldungen digitalisiert wurden.

Das Ziel des neuen Systems ist es, eine moderne Microservices-Architektur umzusetzen, die mit dem User-Interface der Applikationen effektiver und gezielter kommuniziert. Die bisherigen Funktionen von Lithosphere werden neu implementiert und durch weitere ergänzt. Das Ganze soll u.a. die Projektverwaltung, das Zeitmanagement und die Ressourcenplanung aller Kollegen erleichtern.

Dafür wurde Lithosphere aus APEX und PL/SQL heraus in einer Microservice-Architektur umgesetzt, sodass die einzelnen Funktionalitäten später besser unabhängig voneinander laufen können. Ein schöner Nebeneffekt des Projekts ist die steile Lernkurve für die daran teilhabenden Kollegen. Durch die Mitarbeit bei Lithosphere erlernen gerade unsere Einsteiger den Umgang mit verschiedenen Technologien und sammeln praxisnahe Erfahrungen für zukünftige Kundenprojekte.

Über Hürden und Erfolge – Real Talk mit dem Technical Lead Torsten 

Woher kommt der Name „Lithosphere“?

In der Lithosphere befinden sich die festen Bestandteile der Erde, auf der sich das gesamte Leben abspielt. Da es sich bei der Plattform Lithosphere um die wichtigsten Supportprozesse von esentri handelt und darauf alle Geschäftsprozesse gelebt werden, kam die Idee zum Projektnamen.

Auf welche Technologien setzt ihr?

Wir verwenden Spring Boot Microservices für Backends. Angular für Frontends und OpenShift für die Plattform, mit der die Services gemanaged werden. Für alles, was dazwischen passiert, verwenden wir Atlassian Toolchain und JFrog Artifactory, um eine möglichst automatisierte CI/CD für alle Services zu ermöglichen.

Wie organisiert ihr euch in dem Projekt?

Wir arbeiten nach der Scrum-Methode. In drei- bis vierwöchigen Sprints wird eine vorher definierte Anzahl an Tickets über Jira im Team verteilt und von jedem bis zum Ende des Sprints erledigt. Dadurch können wir möglichst schnell auf Änderungen in den Projektanforderungen reagieren. An jedem Sprintende soll dann ein verwendbares Zwischenprodukt bestehen.

Hattet ihr manchmal Schwierigkeiten, sowohl technisch als auch im Team?

Es war anfangs eine ganz schöne Herausforderung, ein solches Projekt mit einem Team aus Studenten ohne viele Vorerfahrungen umzusetzen. Technisch gesehen haben wir uns immer wieder gefragt: „Wie viel Komplexität hinsichtlich Microservices brauchen wir eigentlich für eine nicht allzu komplexe Architektur?“

Was kannst du jetzt besser?

Wir haben als Team eine ganze Reihe von Technologien besser kennen gelernt, wie z. B. Angular, OpenShift, AWS und Spring Boot. Außerdem verstehen wir jetzt viel besser, worauf es beim agilen Arbeiten wirklich ankommt. Von großer Bedeutung für mich persönlich ist die Erfahrung als Team-/Technical Lead, aus der ich viel praktisches Wissen gewonnen habe. Ich bin mir sicher, dass das mir in zukünftigen Projekten viel nutzen wird.

Was macht das Projekt deiner Meinung nach arete (=exzellent)?

Ich denke, dass vor allem das Lernpotenzial hier sehr groß ist. Wir haben uns bisher immer gefragt: „Können wir das noch besser? Geht das mit einer anderen Technologie viel einfacher und schneller?“, um möglichst viel zu lernen. Außerdem haben wir immer viel Wert auf eine saubere Dokumentation und Planung in Confluence gelegt.

Welche Verbindung hat Lithosphere mit dem goldenen Circle, sprich unserem USP?

Auf jeden Fall wurde im Projekt das Mindset der Knowledge Sharing Company wirklich gelebt und durch die Transparenz im Unternehmen gefördert. Agilität steht in der täglichen Arbeit außerdem hoch im Fokus. Und im Projekt setzen wir besonders auf Cloud-Ressourcen und DevOps durch die nahe Bindung an die Cloud.

Was ist der aktuelle Stand? Wie lange geht das Projekt „Lithosphere“noch ?

Es gibt da kein cut-off-Datum. Wir haben ein „funktionales“ Ziel bis Ende des Jahres, also eine bestimmte Funktionalität, die erfüllt werden soll (das automatische Generieren von Rechnungen) und danach schauen wir weiter. Theoretisch gibt es noch sehr viel zu tun – besser geht immer!

Das Team: Product Owner Frank Szilinski, Technical/Team Lead Torsten, DevOps-Entwickler Harald und die Developer Marvin, Oleh, Vladimir, Vanessa, Stefanie, Alexander, Caner, Jannis, Tom & Yannick.