Monolithen in neuem Gewand ERP reloaded

Anbieter zum Thema

Schneider Electric GmbH

PresseBox - unn | UNITED NEWS NETWORK GmbH

Rosenberger-OSI GmbH & Co. OHG

Betriebswirtschaftliche Standardsoftware alias ERP entstand in den frühen Tagen der Digitalisierung. Aber auch heute in Zeiten von Edge und Cloud sind die Kern-Elemente der Monolithen von Nutzen, wenn nicht sogar unabdingbar.

Enterprise-Resource-Planning (ERP-)Software soll die Planung, Bewirtschaftung und Operationalisierung von Unternehmens-Ressourcen digital abbilden. In Zeiten der Vor-Ort-Rechenzentren als dem alleinigen digitalen Maschinenraum eines Unternehmens konnten die entsprechenden Prozesse in der Regel klar eingegrenzt und verortet werden. Sachgebiete wie Personalwesen, Rechnungswesen, Finanzbuchhaltung oder Vertrieb waren der gemeinsame organisatorische Nenner praktisch aller Unternehmen und wurden je nach Branche durch weitere Module wie Materialwirtschaft, Prozess-Steuerung oder Wartung ergänzt.

Die Module waren auf der Makro-Ebene standardisierbar und weitgehend austauschbar. Die Unternehmen mussten zwar in der Regel Anpassungen an die eigenen Gegebenheiten vornehmen, kamen aber im Prinzip mit den relativ schwergewichtigen Software-Monolithen quer durch die Branchen gut zurecht. Klar: Die Anpassungen kosteten Zeit und Geld, aber insgesamt war der Mehrwert gegenüber selbstgestrickten Eigenentwicklungen gewaltig.

Monolithen in Zeiten der Plattform-Ökonomie

Heute ist diese IT-Welt der standardisierten Monolithen weitgehend Geschichte, zumindest in der Form eines festgefügten Architektur-Modells. Die Monolithen gibt es noch, aber sie sind an allen Ecken und Kanten aufgebohrt und flexibilisiert. Denn die IT-Welt ist quasi „aus dem Häuschen“. Technologien wie das Internet der Dinge (IoT), die mobile IT in Gestalt von Smartphones und Tablets und den allgegenwärtigen Apps für alles und jedes sowie das weltweit vernetzte Cloud-Computing benötigen eine IT-Infrastruktur, in der Reaktionsgeschwindigkeit und bedarfsorientierte Skalierbarkeit Trumpf sind.

Starre monolithische Strukturen sind das Gegenteil dieses Ideals. Denn zumindest in der Tendenz sind Monolithen eher schwach strukturiert, schlecht dokumentiert und, wie es der Teufel will, ist der Teil, der besser dokumentiert ist, womöglich längst geändert oder ganz entfernt. Auch Testszenarien sind eher schwierig zu entwickeln. Das ist zugegebenermaßen ziemlich zugespitzt formuliert, vielleicht sogar ein wenig bösartig, aber in einigen Fällen durchaus nicht sehr weit weg von der Wahrheit.

Es ist schwer vorstellbar, wie man mit solcher Software die neuen, flexibel und schnell änderbaren Geschäftsmodelle der Plattform-Ökonomie abbilden will. Denn wenn beispielsweise im Umfeld der digitalen Ökonomie in eine eCommerce-Plattform neue Features eingebaut werden, dann kommt man nicht umhin, auch im dahinter liegenden ERP-System nachgelagerte Änderungen durchzuführen. Aber dies darf nicht erst in drei Monaten, wenn das nächste turnusmäßige Update ausgerollt wird, stattfinden, sondern möglichst sofort.

Microservices sind ERP-Ergänzung, nicht ERP-Ersatz

Service-orientierte Architekturen (SOA) sind unförmigen Monolithen in vielen Punkten überlegen. In ihrer modernen handlicheren und Cloud-basierten Form als so genannte Microservices innerhalb eines Service Mesh werden Funktionen und Funktionsbereiche in „kleine, gute verdaubare Happen“ zerlegt, so dass neue Features schnell umgesetzt und funktionale Dubletten vermieden werden können. Auf diese Weise kann beispielsweise ein Geodaten-Service oder ein Microservice, der eine Bild-Datenbank nach Bildern durchsucht, die für eine Risiko-Analyse wichtig sind, mit einem Modul des ERP-Systems verbunden werden.

Microservices sind nicht mehr und nicht weniger als eine der letzten Ausprägungen einer strukturierten beziehungsweise modular orientierten Programmierung, allerdings insofern etwas Neues, als sie über die Cloud funktionieren. Und Microservices sind – wie der Name schon andeutet – viel handlicher als beispielsweise SOA-Gebilde. Insofern kann eine Umsetzung von SOA-Architekturen in Microservices sehr mühsam und kostspielig werden.

Wie dem auch sei: Moderne ERP-Systeme wie „SAP S/4HANA“ sind ohnehin keine altertümlichen Monolithen mehr, sondern „Multicloud-fähig“ und sie bieten vielfältige Schnittstellen in die neue Microservices-Welt. Dabei können sogar Microservices genutzt werden, ohne dass ein vollständiges S/4HANA-System im Einsatz ist.

Microservices haben nicht zuletzt den großen Vorteil, dass sie mit modernen Programmierstilen wie DevOps gut zusammenspielen, bei denen Programmentwicklung, Programmtest und Programmausführung einen einheitlichen Zyklus bilden, so dass neue Leistungsmerkmale schneller umgesetzt werden können als mit den herkömmlichen Entwicklungsschleifen.

Microservices und Unternehmensapplikationen

Bei allen Vorteilen sind Microservices oder auch heutige Container-Techniken kein Allheilmittel. Die große Herausforderung bei solch kleinteiliger und lose gekoppelter Programmierung ist der Kommunikationsaufwand. Die einzelnen Komponenten, die unter Umständen in verschiedenen Programmiersprachen erstellt sind, müssen sich bei der Bewältigung der gestellten Aufgabe optimal zusammenfinden.

Die REST-Schnittstellen-Standards, durch die in verschiedenen Sprachen geschriebene Microservices überhaupt erst möglich werden, sind sicher ein großer Fortschritt. Gleichwohl ist die Frage berechtigt, ob man mit einer solchen „wuselnden Vielfalt an Code“ wirklich eine stabile Unternehmens-App bauen sollte.

Eine Unternehmensapplikation, wie wir sie uns hier vorstellen, ist kein Facebook-Gimmick, sondern beispielsweise ein wichtiges Glied in der Produktionssteuerung im Maschinenbau oder ein zentrales Element im Zahlungsverkehr des Bankensystems. Oft wird bei der Eignungsbeurteilung von Microservices für ERP-Dienste übersehen, dass leichtgewichtige, womöglich mit Low-Code erstellte Apps nur deshalb in den jeweiligen Kontexten funktionieren, weil sie sich implizit auf bewährte monolithische Komponenten im Hintergrund abstützen können.

ABAP und Konsorten im Edge- und Cloud-Zeitalter

Tatsächlich befindet sich in den Tausenden und Abertausenden Zeilen von ABAP-Code (mit dem traditionell die ERP-Software von SAP geschrieben ist) oder auch in anderen seit Dekaden existierenden ERP-Systemen ein „IT-Kultur-Erbe“, auf das man auch heute nicht verzichten sollte und auch gar nicht kann. Was beispielsweise die Change-Management-Prozesse betrifft, so mögen auf den ersten Blick die Änderungsgeschwindigkeiten für das Webshop-Zeitalter nicht ausreichend sein, aber traditionelle alte Tools wie der SAP Solution Manager bieten sehr gute Mechanismen für Change-Management und Tests auch in Plattform-Ökonomie-Zeiten.

Und warum sollten beispielsweise DevOps-Methoden und DevOps-Tools wie „Git“, „Marvin“ oder „Docker“ nicht auch auf ABAP und Konsorten übertragbar sein? Insofern sind Microservices, Container und DevOps keine Alternativen zu den heute ohnehin nur noch bedingt monolithischen ERP-Systemen, sondern eher Ergänzungen und methodische Bereicherungen. Und auch die vielen IoT-Geräte in der Vorfeld-Verarbeitung (Edge) benötigen eine stabile ERP-Basis (siehe: Ergänzendes zum Thema), mit der die vielen Daten abgeglichen werden können, um beispielsweise gute zielführende Visualisierungen generieren zu können.

(ID:46868042)