Das ist eine Folge für alle, die mehr über die Entwicklungsgeschichte von ERP wissen oder einfach nur verstehen wollen, warum ihr ERP-System optisch modern wirkt, aber sich in der Entwicklung kaum noch „vom Fleck“ bewegt.
In der heutigen Folge spreche ich über die historische Entwicklung von ERP-Architekturen von der monolithischen Mainframewelt bis hin zu modernen Web Scale SOA und Microservices von „heute“ und „morgen“.
Viel Vergnügen!
————————–
Wenn Ihnen unsere Folgen gefallen, dann freuen wir uns über eine 5-Sterne-Bewertung auf Ihrer Wunschplattform, damit auch andere auf diesen Podcast aufmerksam werden und wir das Angebot weiter verbessern können. Zeitaufwand: 1-2 Minuten.
In diesem Sinne: keep connected.
Herzlichst
Ihr
Axel Winkelmann
Transcript:
ERP-Podcast Folge 127, zweiter Teil. Technische Einblicke in die ERP-Architektur. Herzlich willkommen zum ERP-Podcast, dem Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen auseinandersetzen wollen.
Mit diesem Podcast möchte ich Sie mit eigenen Gedanken und Interviews bei der Gestaltung moderner IT-Konzepte nebenbei, also zum Beispiel beim Spazierengehen oder Autofahren begleiten. Damit möchte ich Ihnen in dieser von technologischen Veränderungen geprägten Zeit Informationen anbieten, die sich in Zeitschriften, Fachbüchern und wissenschaftlichen Artikeln in dieser Form nicht darlegen lassen und für die sich im hektischen Alltag ohnehin nicht die Zeit findet. Mein Name ist Axel Winkelmann, ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.
Herzlich willkommen zurück zum ERP-Podcast. Zweiter Teil einer Episode, um so ein bisschen aufzuarbeiten, wie sehen ERP-Architekturen aus. Ich vereinfache sicherlich an einigen Stellen, aber ich möchte das Thema einfach mal aufgreifen.
Ich hoffe, dass das für alle so unterhaltsam ist, dass man selber gerne zuhört, ein bisschen was mitnimmt. Wir waren letztes Mal gestartet, 50er, 60er, vielleicht 70er Jahre. Die Mainframe-Zeit, ein großes Rechnersystem für Großunternehmen, vor allen Dingen, andere konnten sich das gar nicht leisten.
Assembler-Programmierung, Maschinensprachenprogrammierung, Lochkartensysteme, IBM Mainframe-Systeme, über die wir gesprochen haben. Ja, für die Informatik ein Graus, weil natürlich in Spaghetti-Code gearbeitet wurde. Es war sehr, sehr schwierig, diesen Code, der aus Datenhaltung, Funktionalität, Benutzeroberfläche parallel irgendwie bestand, diesen Code zu warten, zu vergrößern, zu updaten.
Also sehr, sehr schwierig. Deswegen hat man dann, als die ersten Client-Systeme, als die ersten Endanwender-Geräte kamen, natürlich schnell architektonisch reagiert mit der Two-Tier, mit der Zwei-Schichten-Architektur. Also man hat getrennt zentrale Datenhaltung und Funktionalität, beziehungsweise Benutzerschnittstelle auf der anderen Seite, nämlich auf Seiten des Endanwenders.
Ja, und das hat man natürlich, je leistungsfähiger die Endanwender-Systeme wurden, die waren ja in den 80er-Jahren noch wenig leistungsfähig, Mitte der 90er-Jahre sah das dann schon ganz anders aus. Da hat man dann natürlich entsprechend differenziert entwickeln können. Und wir waren letztes Mal gekommen bis zu den sogenannten FAT-Clients.
Das heißt, man hat wirkliche Software-Systeme entwickelt für die Endanwender-Systeme und die wurden dann dort entsprechend installiert und hatten dann Zugriff über auch schmalbandige Leitungen auf die zentrale Datenhaltung, den Server, also sogenannte Client-Server-Architekturen, die jetzt langsam ins Spiel kamen, hatten aber natürlich den riesigen Nachteil, wenn ich auf dem Endgerät etwas installiere, ja, dann habe ich irgendwann ein Update. Das ist nicht weiter schlimm, wenn das Endgerät direkt vor meiner Nase steht. Wenn ich aber durch ganz Deutschland dafür reisen muss, um 2000 Endgeräte mit einem Update zu versorgen, dann ist das natürlich eine Riesen-Nummer an der Stelle.
Und entsprechend hat sich der FAT-Client am Anfang natürlich durchgesetzt, aber er hat sich eben langfristig nicht durchgesetzt. Er hatte noch einen weiteren Nachteil. Es kamen nämlich zunehmend andere Endgeräte, die eben nicht mehr das typische Röhrenmonitor-Format hatten, die eben nicht mehr rein nur auf dem Schreibtisch des Endanwenders gestanden haben, sondern die plötzlich mobil waren.
So, und das war eine Entwicklung, die so um die Jahrtausendwende dann auch von sich ging. Und man hat dann überlegt, wie kriegt man einerseits die Funktionalität, die man eben von dem FAT-Client auf dem Endanwender-Rechner gewohnt war, dann auch entsprechend in besser skalierbare, besser auf verschiedenen Endgeräten nutzbare Systeme. Und das war eigentlich der Beginn der Entwicklung von sogenannten Rich Clients.
Rich Clients sind Software-Systeme, die nicht per se mit sehr viel Code daherkommen, die nicht per se vorinstalliert auf dem Rechner sein müssen, sondern die auch Funktionscode durchaus von dem zentralen System nachladen oder zu späteren Zeiten dann entsprechend als Add-on in einem Webbrowser funktionierten. Das war das Problem, was wir nach der Jahrtausendwende mit den Webbrowsern generell hatten. Die Funktionalität, die diese Anzeigesysteme für das World Wide Web letztendlich hatten, die war nicht so ausgereift, dass wir tatsächlich wirklich gut dort Software drin laufen lassen konnten.
Okay, es gab auch sowas wie gmx, wie web.de. Mein erstes Startup hat selber Websoftware entwickelt, Unified Messaging Software. Also es war irgendwo für statische Masken schon möglich, so erste grafische Nachbildungen zu bauen, die nur im Browser funktionierten. Aber es war nicht wirklich eine Benutzerfreude, sage ich mal.
Und da boten nachladbare Funktionsbibliotheken, da boten Extensions für den Webbrowser natürlich bessere Möglichkeiten. Und das waren eben am Anfang die sogenannten Rich Clients. War dann immer ein Problem bei Rechnern, bei denen man nichts installieren konnte.
Aber der Riesenvorteil gegenüber dem Fat Client war natürlich, dass man eben nicht vorab und permanent immer etwas installieren muss, sondern dass man für die Nutzung sich den Code entsprechend vom zentralen Server ziehen konnte. Ja und die Weiterentwicklung von dem Ganzen, bei dem eben auch keine Funktionalität dann mehr auf dem Endgerät liegt, ist der sogenannte Thin Client. Den Thin Client in seiner heutigen Ausprägung, den kennen wir sicherlich alle als HTML5.
Browser-Anwendung mittlerweile sehr, sehr mächtig. Mittlerweile Standard für fast alle Funktionsgattungen von Software, dass man entsprechend im Browser an jedem beliebigen Endgerät, also nicht nur rein mit einem großen Monitor, sondern auch Tablet oder auf dem Smartphone entsprechend die Software nutzen kann. Ja und dieses überall nutzen bedeutet natürlich auch, dass wir entsprechend leistungsfähige Rechnersysteme haben, was nach der Jahrtausendwende sicherlich der Fall war.
Wir haben in den 90er Jahren angefangen, sehr stark objektorientiert Meerschichtenarchitekturen zu entwickeln. Jetzt nach der Jahrtausendwende ist das Internet, ist das World Wide Web, ist die Browser-Technologie so weit gereift, dass wir überall eigentlich auf unsere Daten zugreifen können. Und damit stellt sich natürlich die Frage, ob so ein Software-System wie ERP, was den Anspruch hat, alle Unternehmensressourcen irgendwie abzubilden, aber dann doch vielleicht an manchen Stellen nicht abbildet, ob man das nicht öffnen kann, ob man nicht von anderen Software-Systemen auf diese Daten, auf diese Funktionalität zugreifen kann.
Und das ist dann der Moment, wo sich die Technologie-Experten natürlich überlegt haben, wie können wir es ermöglichen, dass Funktionalität, dass entsprechende Daten auch so von außen genutzt werden können. Außen muss noch nicht mal heißen, nur innerhalb des Unternehmens, denn ein Unternehmen ist letztendlich ja auch eine künstliche Beschränkung auf die Datenmenge, sondern durchaus auch von zum Beispiel Lieferanten, Banken, dem Finanzamt oder Kunden, beispielsweise in Form von E-Commerce-Systemen, die auf den Lagerbestand zugreifen wollen. Ja, und da hat man sich natürlich Konzepte überlegt.
Man hatte Mitte der 90er Jahre schon angefangen mit der Object Management Architecture aus der letztendlich CORBA entstanden war, die Common Object Request Broker Architecture, um eben auf einzelne Funktionen, auf einzelne Funktionalitäten mit entsprechenden Daten des Gesamtsystems zugreifen zu können. Das war noch relativ aufwendig in der dahinterliegenden Struktur. Man wollte das viel schmaler, viel schlanker, viel webbasierter haben.
Also man wollte gekapselt auf einzelne Dinge zugreifen können und hat sich dann einen Standard ausgedacht, der da heißt Web Service. Und die Idee hinter Web Service ist es eben, Funktionsaufrufe aus der Ferne tätigen zu können, und zwar rein über die Web-Infrastruktur, also sogenannte Remote Procedure Calls, RPC. Und dafür sollte das Ganze möglichst einfach funktionieren, über das Internet, über das World Wide Web funktionieren.
Und herausgekommen ist eigentlich eine Erfolgsgeschichte, die bis heute weiterlebt. Einerseits in Form von Web Services, andererseits in Form von Service-orientierten Architekturen, sogenannten SOA-Architekturen. Und diese SOA-Architekturen, die haben eigentlich das kleine Server-Paradigma, wie wir es noch in den 90er Jahren sehr stark kannten, dann komplett aufgelöst.
Der Grundgedanke dahinter war, das, was man aus den Web Services eben kannte, die Kapselung wirklich auf die vollständige Architektur zu übertragen. Also die Idee, alle Bereiche der Architektur so zu kapseln, dass entsprechend verteilte Systeme entstehen können und aus der Ferne auf einzelne Komponenten des Systems zugegriffen werden kann. Ja, und das Ganze natürlich auf Basis von Internet-Technologie.
Also man wollte wirklich die Fachlandschaft, die IT-Fachlandschaft, das Unternehmenssoftware-System größtmöglich in Teilbereiche kapseln, um entsprechend in der sogenannten Orchestrierung diese Teilbereiche dann jeweils zweckspezifisch nutzen zu können, eben über entsprechende Web Services. Die grundlegende Annahme, die man bereits relativ am Anfang hatte, war eben, dass ich beliebig Services nutzen, gegebenenfalls sogar gegeneinander austauschen kann. Ich behaupte, betriebswirtschaftlich ist das nicht an jeder Stelle sinnvoll.
Zwar kann ich einzelne Funktionalitäten austauschen, durch andere ersetzen, aber ob die dann wirklich das identisch Gleiche machen, sei mal dahingestellt. Insofern ist natürlich diese Vision, ich kann alles gegeneinander austauschen, ich kann beliebig orchestrieren, die ist natürlich nur eine Vision. Trotzdem die Flexibilisierung hatte damit Einzug erhalten in die Entwicklung von Unternehmenssoftware.
SOA ist etwas, was vor allen Dingen in der Dekade nach der Jahrtausendwende sehr stark geprägt wurde. In den 2010er-Jahren kam jetzt etwas Neues dazu, was in wenigen ganz modernen Architekturen erst so richtig Einfluss gehalten hat, was wir als Konsumenten aber durchaus kennen, nämlich die sogenannte Weiterentwicklung von SOA, nämlich Webscale. SOA, das wird wahrscheinlich auch eine Architekturform sein, die sehr stark noch in die Zukunft reicht.
Was wollte man? Also mit SOA hatten wir immer noch sozusagen das Unternehmen im Blick, im Vordergrund die Betrachtung der lokalen oder der zentralen Orchestrierung einzelner Services. Webscale SOA zieht das Ganze auf eine andere Ebene, Beispiel Netflix und Co. Dort locke ich mich zum Beispiel über mein Facebook-Account ein, habe einen Zahlungsdienstleister, über den die Zahlungen abgewickelt werden, habe verschiedenste Server, über die die Performance der Videobereitstellung läuft etc.
pp. Also ganz, ganz viele kleine Einzelpuzzleteile sozusagen, die hier zusammengebracht werden zu einem großen System, zu einer großen Leistungserbringung, in dem Falle eben Netflix. Und genau das Gleiche möchte man natürlich zunehmend auch im ERP, im Unternehmenssoftwareumfeld haben.
Dort ist es nicht so schlank und einfach möglich, weil natürlich die Integration zwischen einzelnen Funktionalitäten die Entwicklung eines ERP oder einer Unternehmenssoftware sehr, sehr langwierig macht. Also Konzepte, die wir schon seit einigen Jahren immer stärker sehen, im Consumerbereich beispielsweise, die werden sicherlich noch ein bisschen brauchen, bis sie in der Breite von ERP-Systemen angekommen sind. Wobei man natürlich auch immer sagen muss, jemand der sein ERP-System in den 90er Jahren entwickelt hat, der kann seine Architektur nicht einfach so schnell von jetzt auf gleich umwerfen und daraus ein vollständig modernes Architektursystem machen.
Das funktioniert einfach nicht. Das kann ich nur machen, wenn ich eine neue Produktlinie auf den Markt bringe. Insofern sehen wir das noch verhältnismäßig selten.
So, aber die Idee, klar, wir wollen neue Organisationsformen von Unternehmenssoftware schaffen. Wir wollen auch eine verbesserte Wartungsfähigkeit haben, eine höhere Skalierbarkeit und Austauschbarkeit der entsprechenden Services, um hier neue Geschäftsmodelle viel, viel, viel, viel, viel stärker unterstützen zu können im Business-IT-Alignment, als dass wir das bislang überhaupt konnten. Damit einhergeht, dass wir nicht mehr nur auf eine Programmiersprache verfallen sind, sondern im Prinzip wird heute in modernen Architekturen mit nahezu beliebigen Programmiersprachen gearbeitet.
Das ist natürlich ein bisschen übertrieben, aber durchaus extrem viele Programmiersprachen, die hier parallel genutzt werden, um sozusagen eine neue Art von Best-of-Breed zu schaffen, eine neue Art von, mit welchen Sprachen entwickle ich bestimmte Aspekte, bestimmte Funktionalitäten, bestimmte Teilbereiche der Software. Und das hilft natürlich den Softwareunternehmen auch sehr stark. Ja, wen das Thema verschiedenste Programmiersprachen auch interessiert, der sei gerne auch verwiesen auf die Folge 120, ein Interview mit dem Gründer von Plenty Systems, eine große E-Commerce-ERP-Plattform mit ganz, ganz vielen Programmiersprachen, die eben auch diese neuen Technologien entsprechend auch genutzt werden.
Und diese neuen Technologien, die haben natürlich auch noch einen entscheidenden Vorteil, den wir in der Vergangenheit nicht gehabt haben. Also historisch gesehen, 70er Jahre, Mainframe, es gab nur einen zentralen Rechner, auf den das System lief. Das heißt, man konnte keine Skalierung irgendwie zwischen verschiedensten Firmen machen.
Das konnte man eigentlich erst so richtig, als man die Virtualisierung auf dem System über virtuelle Maschinen sich überlegt hatte. Dann konnte man natürlich auf der gleichen Hardware verschiedene virtuelle Maschinen laufen lassen, die zu unterschiedlichen Zeiten beispielsweise die CPU-Performance entsprechend gefordert haben. In der Weiterführung war das natürlich Cloud oder Software-as-a-Service.
Und jetzt habe ich so ein bisschen die Problematik, die alte Technologiewelt, gerade die aus den 90er Jahren und vorangegangenen Jahrzehnten, die lief tendenziell und läuft tendenziell nur in dedizierten virtuellen Maschinen. Das heißt, wenn ich derartige Software ins Internet bringe, in die Cloud bringe, also eine Cloud ist ja auch nichts weiter als virtualisierte Rechenzentren, dann habe ich das Problem, dass ich eben pro Kunde eine Instanz, gegebenenfalls eine virtuelle Maschine habe. Wir sprechen dann von Single Instance Cloud System.
Das wird immer ganz gerne vergessen von den ERP-Herstellern zu erzählen, dass sie eigentlich nur eine Virtualisierung betreiben, die auf einer 1 zu 1 Basis beruht. Das hat man natürlich immer ein bisschen weiterentwickelt, technologisch und so weiter. Aber man hat immer diese Restriktionen gehabt.
In den neuen Architekturen habe ich diese Problematik in der Form nicht mehr, sondern ich kann beliebige Software-Konzepte aufbauen. Ich kann Container verwalten. Ich kann dynamisch Arbeitslasten adressieren über verschiedene Maschinen, sogar über verschiedene Rechenzentren verteilen.
Docker Container Management ist ein großes Stichwort an der Stelle. Und das ist eben ein Riesenvorteil, den ich bei ganz modernen Multi-Tenant-Systemen habe, also Systeme, die Multi-, Mehrfachmandanten oder Tenants, wie sie heute geheißen haben, auf dem gleichen Software-Code laufen lassen können. Und damit kann ich natürlich auch kostenmäßig ganz andere ERP-Installationen den Anwendungsunternehmen anbieten, als ich das noch zum Beispiel zu Zeiten von Client-Server-Systemen konnte.
Auch dazu hören Sie zum Beispiel gerne mal in die Folge 43, wie man ein ERP-System in der Cloud baut mit dem Weap-Clap-Gründer an. Wie alle Folgen, die ich hier genannt habe, referenziere ich das aber auch gerne in den Shownotes. Folge 43.
So, also das mag so ein bisschen, ohne jetzt wirklich in einzelne Technologien großartig reingesprungen sein, ein kleiner, einstündiger Ausflug in die technischen Gründe von ERP-Architekturen gewesen sein. Ich hoffe, es hat ein bisschen Spaß gemacht. Mir hat es ganz viel Spaß gemacht, das für Sie mal rauszuarbeiten und entsprechend zu vertonen.
Wie immer, ich wünsche Ihnen eine schöne Restwoche. Keep connected. Herzlichst, Ihr Axel Winkelmann.
Ihnen hat der ERP-Podcast gefallen und Sie konnten wertvolle Erkenntnisse gewinnen? Dann würde ich mich über eine Bewertung auf iTunes freuen, damit auch andere von diesem Podcast erfahren können. Eine Anleitung für die Bewertung finden Sie auf www.erp-podcast.de. Dort finden Sie auch weitere Hinweise, Links und Aktualisierungen zu dieser Folge. Das war der ERP-Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen losgelöst von Fachzeitschriften, Büchern und wissenschaftlichen Veröffentlichungen zum Beispiel beim Spazierengehen oder Autofahren auseinandersetzen wollen.
Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.