Das Tempo hat angezogen. Ein bunter Strauß von Technologien und Open-Source-Projekten steht Unternehmen heute zur Verfügung. Vor etwa 20 Jahren lautete das Motto noch: „IT-Standardisierung“. Es sollte Schluss sein mit technischen Insellösungen, undurchsichtigen IT-Strukturen und stattdessen gab es ein „Ja“ zu Kostensenkung und Simplifizierung der IT. Heute weiß man jedoch, dass diese geschlossenen IT-Strategien mit einem klaren Fokus auf ein bestimmtes System oder einen bevorzugten Lieferanten in der Realität keinen sinnvollen Beitrag zum Erreichen eben dieser Ziele leisten. Monolithische Systeme versagen im Spannungsfeld aus Standardfunktionen und realen Prozess-Anforderungen. Sie skalieren in der Regel nur vertikal, sind viel zu behäbig in einer immer flexibleren und schnelleren Welt der agilen Anforderungen. Auch der reine Betrieb von solchen Lösungen wird spätestens mit zunehmender Komplexität und Größe (Datenvolumen) zu einer spürbaren Kostenfalle. Das gilt besonders dann, wenn nicht ausschließlich die vom Hersteller ausgelieferten Standards zum Einsatz kommen.

Und wer glaubt, sich ausschließlich durch den Rückzug auf Lösungen und Anwendungen im reinen Systemstandard zu retten, verzichtet in der Endkonsequenz auf seine eigenen prozessualen Vorteile gegenüber dem Wettbewerb. Die Lösung liegt nicht in der Selbstbeschränkung, sondern in einer neuen strategischen Ausrichtung von ERP-Projekten und -Infrastrukturen. Eine konsequente Strategie für die IT-Standardisierung war aus der Perspektive von vor 20 Jahren auch durchaus plausibel, ist heute aber nicht mehr zielführend. Dennoch scheinen viele Organisationen und Verantwortliche nur zögerlich und ängstlich neue Modelle zu adaptieren oder zu erproben. Es wird heute immer noch sehr viel Geld in ERP-Projekte investiert, um Lösungen zu erstellen, die nicht unbedingt optimal sind, nur um dem eigenen Standard gerecht zu werden. Eines ist in der Digitalisierung jedoch sicher: Wer sich auf den Status quo verlässt und zu starr ist, wird den technischen Anschluss verlieren.

Dass die Ablösung konventioneller ERP-Strategien heute überhaupt möglich ist, hat viel mit der Entwicklung der sogenannten Open-Source-Community zu tun, die es in dieser Form in den 90er-Jahren einfach noch nicht gab, weil sie erst ab 1998 entstanden ist. Aus den Lizenzrebellen von damals sind mittlerweile in vielen Bereichen Technologie- und Themenführer geworden. Und Player wie die Linux Foundation haben sich inzwischen auch auf Enterprise-Level bei einer Vielzahl großer Unternehmen durchgesetzt – weil sie sehr gut darin sind, initiale technologische Entwicklungen in solide Frameworks und Projekte zu überführen.

Im ERP-Segment sind es vor allem die agilen Microservices-Strategien, die der Integration von Open-Source-Tools den Boden bereiten.

Dabei geht es nicht darum, ein bestehendes ERP-System vollständig abzulösen – das wäre sicherlich sehr teuer, zu risikoreich, zu langwierig und politisch in den meisten Fällen kaum vermittelbar. Zudem dürfte es nahezu unmöglich sein, eine IT-Organisation, die es seit Jahren gewohnt ist, zentral oder standardisiert zu denken und zu handeln, auf Kommando agil arbeiten zu lassen. Es geht vielmehr darum, einen Microservice-Kosmos neben dem bewährten Stack entstehen zu lassen und über klar definierte Schnittstellen von und zum ERP-System zu betreiben. Diese Koexistenz aus alter und neuer Welt ist beabsichtigt, auch deshalb, weil es nicht sinnvoll ist, seit Jahren eingespielte Prozesse schlagartig auf eine agile Lösungsplattform zu portieren. Nicht alles, was ein klassischer ERP-Monolith bietet, ist auch automatisch schlecht – ganz im Gegenteil. Stattdessen sollten bestehende und effiziente ERP-Funktionen über feste Schnittstellen zum Teil der Microservices-Welt werden oder umgekehrt. Nur in den Bereichen, bei denen die klassischen ERP-Systeme keine leistungsfähigen und bezahlbaren Antworten liefern, sollte besser zweimal hinterfragt werden, ob eine teure Überforderung von Lösungen wirklich sinnvoll ist. Ich meine nein und halte es für sinnvoller, über eine neutrale Bewertung von technischen Alternativen herauszufinden, welcher Prozess mit welcher Technologie schneller, besser und preiswerter realisier- sowie betreibbar ist. Dogmatismus im Sinne einer klaren IT-Produktstrategie kann an dieser Stelle sehr teuer sein und führt nicht selten zusätzlich zu suboptimalen Ergebnissen. Zudem sorgt etwas interner Wettbewerb zwischen den Systemen an verschiedenen Stellen auch potenziell zu mehr Beweglichkeit in den Köpfen einiger Protagonisten.

Das Umdenken ist genauso wegweisend wie simpel. Eine einfache Metapher hilft beim Verständnis: Es beginnt mit dem Abschied vom voll beladenen Containerschiff – dem „alten“ ERP-System – und dem Umstieg auf eine neue Flotte von Schnellbooten – die Microservices. Natürlich kann ein klassischer ERP-Ozeanriese, wenn er erst einmal erbaut ist, eine gigantische Last aufnehmen. Aber in einer Zeit, in der es um kurze Bremswege, hohe Geschwindigkeiten, kleine Wendekreise, geringe Ausfallrisiken, vernünftige Beschaffungskosten und minimale Wartungsaufwände geht, ist er allein nicht mehr konkurrenzfähig. Die kleinen, schnellen Microservices folgen einem völlig anderen Prinzip. Jedes dieser Schnellboote kann vielleicht nur eine einzige Aufgabe erfüllen – mit der Flotte ist man aber in der Lage, in kurzer Zeit tausend Schnellboote koordiniert zu klonen, zu Wasser zu lassen und in die gleiche Richtung zu steuern. Bei Bedarf können einzelne Boote ihre Richtung oder Geschwindigkeit verändern. Und wird ein einzelnes Schnellboot ausgemustert, tangiert das die Funktion der Gesamtflotte nicht.

Microservice – ja, aber mit welcher Technologie?

All das klingt recht einfach, jedoch sollte man sich auch der Risiken und Herausforderungen solcher Strategien bewusst sein. Von Microservices nur zu sprechen und keine grundlegenden Veränderungen in der IT herbeizuführen, wird fulminant scheitern. Die Ursache dafür ist das häufig mangelhafte oder kaum verfügbare Know-how in diesem Bereich. Typischerweise sind containerbasierte Infrastrukturen das Mittel der Wahl, wenn es um Mircoservices geht. Und containerisierte Systeme bauen nicht selten auf frei verfügbarer Software auf. Angebote für Containersoftware, aber auch für die Anwendungssoftware innerhalb der Container gibt es zuhauf. Selbst einige der alten „Ozeanriesen“ schaffen es bisweilen, ihre monolithische Software in riesige Container zu pressen und ihnen so einen etwas moderneren Anstrich zu verpassen.

Im Dschungel der freien Technologien muss man sich aber erst einmal zurechtfinden. Welches Projekt ist für welche fachliche Herausforderung das beste? Nein, auch hier sind feste Standards leider nicht sinnvoll. Ein gutes Beispiel liefert die bunte Welt der Datenbanken: relational, spaltenbasiert, Key Value, Graph oder auch Mischformen wie die sogenannten NewSQL-Datenbanken. Was soll es sein? Welche Technologie ist für welche Anforderung die beste? Handelt es sich um gleichförmige Datenströme? Welches Datenvolumen soll verarbeitet werden? Ist Verteilung wichtig? Wird eine ACID-Zusicherung bei der Verarbeitung von Transaktionen benötigt? Wo fallen die Daten an? Steht Lesen oder Schreiben im Fokus? … und, und, und? All diese Fragen müssen beantwortet werden, um die geeignete Datenbanktechnologie für eine konkrete Anforderung zu ermitteln. Dazu müssen jedoch die Unterschiede der zugrunde liegenden Paradigmen und Technologien erst einmal verstanden werden. Und falls die beste Option identifiziert wurde, fehlt meist immer noch ein Team, das in der Lage ist, entsprechende Projekte auch technisch zu realisieren. Stark verkürzt könnte man auch zusammenfassen, dass ein neuer Typus IT-Mitarbeiter gebraucht wird: jemand, der sich permanent mit neuen Technologien beschäftigt, Konzepte verinnerlicht, miteinander vergleicht und erprobt. Der klassische Oracle-Spezialist der 90er- oder 2000er-Jahre ist hier weniger gefragt. Denn ein Hammer wird immer auf den Nagel schlagen – auch wenn der vermeintliche Nagel eine Schraube ist, die hinterher aus der Wand fällt. Aber genau an dieser Stelle liegt das Potenzial vieler Unternehmen. Agil arbeiten, heißt auch, stetig und agil Technologien zu analysieren und zu testen. Agile Entwicklungsmodelle auf einer schicken Microservice-Plattform, die aber keinerlei technologischen Spielraum lassen, sind schlussendlich genauso starr wie der klassische ERP-Monolith.