Frederik Niehus, Softwarearchitekt bei AEB, erklärt im Interview, wie der IT-Anbieter Anforderungen nach Flexibilität und Individualität in seiner neuen Cloud-Plattform umsetzt.
AEB: Logistik ist in vielen Bereichen sehr individuell. Wie kann Software aussehen, die diese Individualität abbildet und Prozesse maßgeschneidert unterstützt?
Frederik Niehus: Unsere Cloud-Plattform ermöglicht es auf einfache Weise, kundenindividuelle Lösungen nach den Prinzipien des Process Driven Development zu erstellen. Das heißt, wir bauen damit Lösungen entlang der Geschäftsprozesse unserer Kunden. Diese bilden wir dabei nicht mit einem großen monolithischen System ab, sondern mithilfe von mehreren kleineren aufgabenorientierten Web-Anwendungen, die wir Apps nennen. Das Prinzip ist so, dass jeder Teilschritt eines Geschäftsprozesses möglichst einer Aufgabe entspricht, die ein User oder das System im Hintergrund zu einem Zeitpunkt erledigen muss. Und für jeden dieser Prozessschritte gibt es dann eine App mit der der User diese Aufgabe bestmöglich erledigen kann. Diese Apps lassen sich ganz individuell und passgenau an den Anforderungen des Kunden ausrichten. Also je nach dem, wie eine Aufgabe, deren Umfeld und deren Anwender aussieht, kann die App sehr spezifisch darauf optimiert werden. Die Apps lassen sich dann nahezu beliebig hintereinanderschalten, sodass auch der gesamte Kundenprozess maßgeschneidert wird.
Können Sie ein Beispiel geben?
Denken Sie an einen Versandprozess. Hier gibt es beispielsweise für den Packer am Packplatz eine eigene oder evtl. auch mehrere Apps, mit denen er seine Aufgaben bestmöglich erledigen kann. Der Anwender im Versandbüro, der für die Zollanmeldungen verantwortlich ist, hat hierfür hingegen eine andere eigene App.
Software, die sich flexibel anpassen und erweitern lässt. Die so leicht zu bedienen ist wie eine Wetter-App. Und die ganz auf Ihre Anwender und deren Aufgaben ausgerichtet wird. Das bringt Ihre Logistik weiter. Klicken Sie hier und erfahren Sie wie.
Wie genau erfolgt die Abbildung der Prozesse und die Koordination der Apps?
Die Prozessmodellierung erfolgt mithilfe von BPMN (Anm. der Red.: BPMN steht für Business Process Model and Notation und ist eine etablierte Modellierungssprache für Geschäftsprozesse). Hierfür gibt es einen eigenen Backend-Service, der Teil unserer Cloud-Plattform ist. Er erlaubt es, Prozesse grafisch zu modellieren und führt diese anschließend auch aus. Dabei werden die modellierten Prozessschritte mit den Apps verknüpft, die dadurch in den Gesamtablauf eingebunden werden. Zudem definiert der Prozess auch, wann welche Hintergrundverarbeitungen ausgeführt werden. Mit diesem Vorgehen erhält man nicht nur ganz automatisch eine Dokumentation der umgesetzten Geschäftsprozesse, sondern auch die Möglichkeit, diese im laufenden Betrieb überwachen und steuern zu können.
Eine Anforderung an Software ist es, dass diese immer flexibler sein soll – sich also an neue oder geänderte Anforderungen anpasst. Wie lässt sich das erreichen?
Unsere Architektur ist darauf ausgelegt, die Lösung flexibel während des Betriebs ändern zu können. Also etwa Apps und Prozesse ohne Wartungsfenster oder Downtime auszutauschen bzw. anzupassen. Das heißt, wir können einzelne Apps ins System integrieren und ändern, sowie Prozesse bzw. einzelne Schritte umgestalten, ergänzen oder streichen. Auch die Datenmodelle, die definieren wie die Geschäftsobjekte in einer Kundenlösung aussehen, lassen sich so anpassen. Beispielsweise kann man einem Geschäftsobjekt jederzeit neue Datenfelder hinzufügen, um diese in einer neuen App oder einem neuen Prozess verwenden zu können.
Die Prozessunterteilung in einzelne Aufgaben mit deren Apps erinnert an das Microservice-Konzept, das gerade sehr en vogue ist …
Viele der Ideen und Prinzipien von Microservices finden sich in unserer Architektur wieder. Die oben beschriebenen Apps sind eigenständig, haben einen überschaubaren Funktionsumfang, lassen sich unabhängig voneinander deployen und folgen der Unix-Philosophie „Do one thing and do it well“. All das sind Eigenschaften klassischer Microservices.
Gibt es auch Unterschiede?
Häufig verbindet man mit einem Microservice auch die Forderung nach eigenständiger Datenhaltung. Also das Prinzip von self-contained systems, in dem jeder Service seinen eigenen kompletten Stack inklusive eigener Persistenz hat. Das ist in unserer Cloud-Plattform anders. Um Geschäftsobjekte sowie deren Beziehungen zueinander modellieren und anschließend speichern und lesen zu können, gibt es einen weiteren Backend-Service, der den Apps dafür eine Schnittstelle bereitstellt. Im Allgemeinen kann man also sagen, dass unsere Apps zwar den Prinzipien von Microservices folgen, dabei aber Infrastruktur-Services der Plattform nutzen, um selbst möglichst leichtgewichtig zu bleiben. Bildlich gesprochen befinden sie sich auf einem komfortablen Bett eines gemeinsamen Prozess- und Datenmodells.
Frederik Niehus (Dipl.-Inf.) studierte Softwaretechnik an der Uni Stuttgart und ist seit 2010 bei der AEB. In seiner Rolle als Entwickler und Softwarearchitekt arbeitet er aktuell an der Entstehung und Weiterentwicklung der Cloud-Softwareplattform für flexible Logistiklösungen. Sein Schwerpunkt ist die Konzeption der Plattformkomponenten im Backend. In seiner Freizeit gehört sein Herz der Familie, der Natur und allem anderen was Spaß bringt.
Die Anbindung an andere Systeme ist immer ein Thema. Wie bewerkstelligen Sie das?
Die Kommunikation mit Partnersystemen, etwa einem ERP-System, übernimmt ein weiterer Plattform-Backend-Service, der Integration Manager. Mit ihm können Schnittstellen per Konfiguration eingerichtet werden. Genutzt wird dabei die Sprache, die die andere Lösung spricht. Egal ob GraphQL, SOAP-Webservices oder REST-Schnittstellen, egal ob XML oder JSON, …
Individualisierung und Flexibilität schön und gut. Für viele Aufgaben in der Logistik gibt es aber fest definierte Anforderungen, die in jedem Unternehmen gleich sind und die sich nicht ändern …
Immer dann, wenn es um nicht so dynamische, fachlich tiefgehende Business-Logik geht, sind bewährte Standards sinnvoll. Denken Sie wieder an das Beispiel der Zollanmeldung. Die Nachrichten, die mit dem Zoll ausgetauscht werden, unterliegen festen Vorgaben. Hier ist es viel sinnvoller und vor allem auch kostengünstiger, Standards zu verwenden und keine individuelle Lösung für jeden Kunden umzusetzen. Für derartige Fachfunktionalität nutzen wir daher im Hintergrund die bewährten AEB Standard Business Services, die in den Prozess eingebunden werden und die notwendige Funktionalität bereitstellen. Ein weiterer großer Vorteil dieser standardisierten, nicht kundenindividuellen Business Services ist es, dass diese kontinuierlich gewartet werden. Bei rechtlichen Änderungen stehen diese dann zum Stichtag zur Verfügung.
Noch eine Frage zum technischen Hintergrund: Welcher Technologie-Stack steckt hinter der Cloud-Plattform?
Bei der Entwicklung unserer Cloud-Plattform haben wir uns entschieden, die aktuell modernsten Technologien für die Realisierung unserer sicherlich ambitionierten Ziele einzusetzen. In Stichworten: Angular für die Frontend-Entwicklung, TypeScript als Entwicklungssprache im Front- und Backend, GraphQL als durchgängige Schnittstellensprache zwischen den Komponenten, eine NoSQL-Datenbank, um sich ändernde Datenstrukturen flexibel zu speichern, Docker für den containerisierten Betrieb. Bei der Entwicklung setzen wir häufig Open-Source-Software ein – wobei es für uns selbstverständlich ist, dass wir umgekehrt Teile unserer Plattform auch als Open Source anderen zur Verfügung stellen.
Herr Niehus, vielen Dank für das Gespräch.
