Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen

Schütte, Reinhard; Kari, Mohamed Article — Published Version Cloud Enterprise Systems– State of the Art und Herausforderungen für Unternehmen HMD Praxis der Wirtschaftsinformatik Provided in Cooperation with: Springer Nature Suggested Citation: Schütte, Reinhard; Kari, Mohamed (2025) : Cloud Enterprise Systems– State of the Art und Herausforderungen für Unternehmen, HMD Praxis der Wirtschaftsinformatik, ISSN 2198-2775, Springer Fachmedien Wiesbaden GmbH, Wiesbaden, Vol. 62, Iss. 1, pp. 5-24, https://doi.org/10.1365/s40702-025-01141-3 This Version is available at: https://hdl.handle.net/10419/319053 Standard-Nutzungsbedingungen: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Zwecken und zum Privatgebrauch gespeichert und kopiert werden. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich machen, vertreiben oder anderweitig nutzen. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, gelten abweichend von diesen Nutzungsbedingungen die in der dort genannten Lizenz gewährten Nutzungsrechte. Terms of use: Documents in EconStor may be saved and copied for your personal and scholarly purposes. You are not to copy documents for public or commercial purposes, to exhibit the documents publicly, to make them publicly available on the internet, or to distribute or otherwise use the documents in public. If the documents have been made available under an Open Content Licence (especially Creative Commons Licences), you may exercise further usage rights as specified in the indicated licence. http://creativecommons.org/licenses/by/4.0/deed.de GRUNDLAGENBEITRAG https://doi.org/10.1365/s40702-025-01141-3 HMD Praxis der Wirtschaftsinformatik (2025) 62:5–24 Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen Reinhard Schütte · Mohamed Kari Eingegangen: 14. September 2024 / Angenommen: 2. Januar 2025 / Online publiziert: 14. Januar 2025 © The Author(s) 2025 Zusammenfassung Die Softwarehersteller propagieren für Enterprise Systems das Cloud Computing. So sollen sämtliche Komponenten von Enterprise Systems langfristig nur noch als Software as a Service genutzt werden. Aufgrund der Abhängigkeit vieler Anwendungsunternehmen von den wenigen Anbietern (Microsoft, SAP, Oracle, Infor, Sage, Salesforce etc.) stellt sich die Frage, welchen Entwicklungen die Applikationsarchitekturen und IT-Prozesse unterworfen sein werden. Ausgehend von einer Entfaltung dessen, was unter Enterprise Systems verstanden wird und welche Präsuppositionen den nachfolgenden Abschnitten unterliegen, wird der State of the Art heutiger Enterprise Systems kurz skizziert. Es wird eine Referenzarchitektur entworfen, in der die Services der drei großen Hyperscaler verortet werden. Zuletzt werden die strategischen, prozessualen und applikationsmäßigen sowie systemtechnischen Implikationen des Cloud Computing für die Anwendungsunternehmen aufgezeigt. Der Beitrag verdeutlicht, dass die technologischen Paradigmen und Systems-Engineering-Vorgehensweisen im Cloud Computing die zukünftige Einführung von Enterprise Systems und auch deren Betrieb nachhaltig verändern werden. Der Beitrag schließt mit einem Ausblick auf zukünftige Herausforderungen für die Forschung und die betriebliche Praxis. Schlüsselwörter Enterprise Systems · Cloud Computing · SaaS · PaaS · Applikationsarchitektur · ERP-Einführung Reinhard Schütte · Mohamed Kari Fakultät für Informatik, Universität Duisburg-Essen, Essen, Deutschland E-Mail: reinhard.[email protected]e K 6R. Schütte, M. Kari Cloud Enterprise Systems – State of the Art and Challenge for Businesses Abstract Software manufacturers are propagating cloud computing for enterprise systems; in the long term, it can be assumed that all components of enterprise systems will only be provided as software as a service. Due to the dependence of many application companies on the few oligopolists (Microsoft, SAP, Oracle, Infor, Sage, Salesforce, etc.), the question arises as to how application architectures and IT processes will develop accordingly. Starting with an explanation of what is meant by enterprise systems and which presuppositions underlie the following sections, the state of the art of today’s enterprise systems is briefly outlined. A reference architecture for cloud computing is outlined, in which the different services of the three major hyperscalers are situated. Building on this, the strategic, processrelated, application-related and system-related implications of cloud computing for domain companies are highlighted. The article makes it clear that the technological paradigms and systems engineering approaches in cloud computing will permanently change the future implementation of enterprise systems and their operation. The article concludes with an outlook on future challenges for research and operational practice. Keywords Enterprise Systems · Cloud Computing · SaaS · PaaS · Application Architecture · ERP Implementation 1 Problemstellung und Entfaltung der Präsuppositionen Enterprise Systems werden gemeinhin nicht mehr als ein monolithisches System verstanden. Stattdessen wird in der Literatur die Einschätzung geteilt, dass derartige Systeme sich aus – je nach Autor – fünf (Gronau 2021) bis sechs (Schütte 2024) unterschiedlichen Systemen zusammensetzen, die abweichende funktionale und technische Aufgaben abdecken: Enterprise Resource Planning (ERP), Supplier Relationship Management (SRM), Supply Chain Management (SCM), Customer Relationship Management (CRM), Business Intelligence (BI) und nach dem vorliegenden Verständnis optional auch ein Shop-System (Schütte 2023,2024). Dabei sind Enterprise Systems dadurch geprägt, dass ihre Komponenten Standard-Anwendungssysteme sind, die einen hohen Integrationsgrad anstreben (Leyh und Wendt 2018; Gronau 2021; Kurbel 2021). Die mit dem Aufkommen des Cloud Computing induzierten technologischen Herausforderungen für Enterprise Systems sind erheblich, wie der vorliegende Beitrag darstellen wird. Die erforderlichen Änderungen in bestehenden Systemen haben ihre Ursache möglicherweise auch in den – bezüglich der Cloud-Technologien – geringen technologischen Fortschritten, die die Standardsoftwarehersteller bisher realisiert haben. Dabei wird in diesem Beitrag unter Cloud Computing (Hentschel et al. 2018; Hentschel und Leyh 2016) nicht nur der Verkauf einer Lösung als Software as a Service (SaaS) verstanden. Stattdessen unterstellt dieser Beitrag, dass mit dem Begriff eines „Cloud-basierten Systems“ die Realisierung von Eigenschaften des Cloud-Native oder Serverless Computing K Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 7 gemeint ist, welche jedoch durch Enterprise Systems von heute nicht oder oft nur sehr begrenzt erfüllt werden. Daraus ergeben sich die beiden zentralen Problembereiche, die dieser Beitrag adressiert: Welche Veränderungen in der Architektur von Enterprise Systems sind zu erwarten und wie wirkt sich dies auf die Evolution der Architekturen in den Anwendungsunternehmen aus? Welche Herausforderungen und Risiken ergeben sich aus den veränderten architektonischen Gegebenheiten für die im Einsatz befindlichen Applikationsarchitekturen? Der Diskussion der Problembereiche seien dabei folgende Präsuppositionen vorangestellt, um dem geneigten Leser die Basis der Bewertung nachvollziehbar zu entfalten: Ein Enterprise System ist nicht nur ein monolithisches System, sondern die Komposition von mehreren Systemen, die auch nicht nur von einem Softwarehersteller stammen muss (Architekturund Heterogenitätspräsupposition). Die ökonomische und auch technische Bedeutung des Cloud-Native Computing für die Softwarehersteller führt dazu, dass diese die Anwendungsunternehmen technologisch in die Cloud „treiben“ und alternative Technologieangebote geringer und vor allem weniger leistungsfähig werden (Cloud-Dominanzpräsupposition). Ein Enterprise-System-Hersteller dominiert die Anwendungssystemlandschaft von Unternehmen im inhaltlichen und auch technologischen Sinne (betriebswirtschaftliche und technologische Herstellerdominanz-Präsupposition). Da Enterprise Systems von den Softwareherstellern betriebswirtschaftlich vorgedacht werden, ist der Lösungsraum für das einführende Unternehmen für wesentliche wertschöpfende Prozesse betriebswirtschaftlich mit ganz wenigen Ausnahmen zwingend unterspezifiziert (Abbildungsunmöglichkeitspräsupposition). Es gibt lediglich zwei Fälle, in denen dieser wichtige Aspekt geringer ausgeprägt ist: Entweder Unternehmen sind an der Entwicklung der Lösungen beim Hersteller beteiligt oder die Anforderungen der Unternehmen sind tatsächlich im Standard vollumfänglich abbildbar. Die Erkenntnisse aus der Einführung von Standardsoftware belegen dabei aber, dass die Individualisierungsanforderungen erheblich sind und die letztgenannte Annahme unrealistisch ist. Auch die empirischen Ergebnisse belegen, dass in den Wertschöpfungsbereichen von Unternehmen eine solche Situation nicht vorliegt (Buxmann und König 1997; Brehm et al. 2002;Hansenetal.2023). 2 State of the Art heutiger Enterprise Systems und deren Einführung Enterprise Systems werden technologisch und betriebswirtschaftlich von den jeweiligen Softwareherstellern dominiert. Auch wenn es in unterschiedlichen Domänen viele Anbieter von Standardanwendungssystemen gibt, so dominieren aus einer Marktanteilsperspektive wenige, große Anbieter den Markt: Oracle, SAP, Microsoft K 8R. Schütte, M. Kari und Salesforce; Auch Sage und Workday sind in diesem Zusammenhang noch zu erwähnen (Sarferaz 2022,2023). Unabhängig von dem Standardsoftwarehersteller sind Applikationsarchitekturen entstanden, in deren Kern die Enterprise-SystemsKomponenten dominieren, auch wenn weitere wichtige Applikationen existieren. Die Kommunikation zwischen und die Integration mit diesen Komponenten bildet dabei die Basis oder „das Backbone“ der Applikationsarchitekturen (Olson und Kesharwani 2010). Dabei gibt es mindestens zwei Fundamentalaspekte, die in der Literatur angedeutet werden, allerdings in ihrer Wirkmächtigkeit für die Applikationsarchitekturen nicht ernsthaft diskutiert werden. Erstens hat sich in der Literatur die Einschätzung etabliert, dass die Rede von „generischen Standardsystemen“ (Klaus et al. 2000; Gronau 2021) ein zielführendes Leitbild für ERP-Systeme sein sollte. Die technische Realisierung dieser Anforderungen durch das Anwendungsunternehmen (oder deren Implementierungspartner) in der Software wird in der Literatur mehrheitlich als Customizing bezeichnet (Gronau 2021; Kurbel 2021; Klaus et al. 2000), wobei dies im engeren Sinne eher eine Parametrisierung darstellt (Schütte 2024). Der Umfang an Parametern ist dabei erheblich (vgl. Dittrich und Vaucouleur 2008) und diese Parametrisierung unterstellt, dass die vergrößerte Code-Basis mit einer darüberliegenden Parametrisierungsschicht Vorteile mit sich bringt. Damit werden implizite Annahmen getroffen, die im Widerspruch zur Abbildungsunmöglichkeitspräsupposition aus dem vorhergehenden Abschnitt dieses Beitrags stehen könnten. Ein solches Zielbild von Standardsoftware unterstellt die Möglichkeit hohe Standardisierungsgrade dadurch zu erzielen, dass unterschiedliche Anforderungen von Unternehmen in der Standardsoftware durch eine Erweiterung der Codebasis realisiert werden können oder es eine – im Wortsinn ernsthafte – generische Ableitungsmöglichkeit des Softwarecodes aus Anforderungen der Unternehmen gibt. Hier wird die Annahme nicht geteilt, denn die Anpassungsmaßnahmen in der Standardsoftware sind den zitierten empirischen Belegen zufolge immens und haben sich im Zeitablauf nicht verringert (Dittrich und Vaucouleur 2008). Hierzu sei auch exemplarisch der ehemaligen CIO von Aldi Nord zitiert: „Man ist schlussendlich hingegangen und hat sehr auf die bestehenden Bedarfe der jeweiligen Fachbereiche bzw. Länderspezifika gehört und hat eben nicht standardisiert, sondern in hohem Maße individualisiert. Wenn man das mal so vergleicht, sich das Coding mal ansieht, sind ungefähr 70% der Codestrecken, die wir heute nutzen, individueller Natur. Das heißt, tatsächlich selber entwickelt bzw. modifiziert, im SAP-Sprachgebrauch, und nur ungefähr 30% der Codestrecke sind von der Software vom Hersteller übernommen“ (Hoepfner 2021). Ungeachtet der enormen Individualisierung von Standardsystemen gilt es die Bedeutung von Standardkomponenten mit Ausnahme der BI-Komponente auf zwei Ebenen zu beachten. Zunächst ist aus einer Metaebene die konzeptionelle und terminologische Bedeutung derartiger Systeme erheblich. Es sind grundsätzliche betriebswirtschaftliche Konzeptionen, die die Art der Aufgabenkoordination festlegen. Beispielsweise determiniert die Kopplung des Rechnungswesens mit der Materialwirtschaft oder dem Vertrieb in einem SAP-System die „Sicht auf die ökonomische Wirklichkeit“. Auf einer Objektebene ist zu beachten, dass der strukturelle und prozessuale Rahmen des Unternehmens von Standardsoftwareherstellern vorgegeben wird und stets auch limitierend wirkt. Dabei sind die meisten aktuell im Einsatz befindlichen Systeme K Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 9 auf Datenmodellen basierend, die den Wunsch nach einer integrierten Datenhaltung durch Inkaufnahme als starr zu bezeichnender Datenstrukturen realisiert haben. Beispielsweise ist das alte SAP-Datenmodell aus dem R/2-System, in dem die zentralen Organisationseinheiten des Systems repräsentiert sind, noch immer in großen Teilen aktuell. Mehr als 50 Jahre sind diese Datenstrukturen und die darauf basierenden Algorithmen stabil geblieben. Zweitens wird auch die technologische Basis in der Diskussion sehr selten problematisiert. Dazu gehört die Art der Datenhaltung und des Datenbanksystems, der Programmiersprache und der Entwicklungsumgebung und nicht zuletzt die Softwarearchitektur und für den Betrieb besonders bedeutend das Deployment und die Softwarelogistik. Letztlich dürfte das Technologiealter der funktionalen Komponenten sehr hoch sein, was auch eine technologische Last für die Anwendungsunternehmen bedeutet. Aufgrund der Vielzahl von Stammkunden wirken diese technologischen Gegebenheiten wiederum ganz im Sinne des Innovator’s Dilemma von Christensen (1997) als Problem für eine wirkliche Neuentwicklung von ERP, CRM, SCM oder SRM-Komponenten. Im Ergebnis sind die heutigen Applikationsarchitekturen damit einerseits durch die betriebswirtschaftliche Prägung der wesentlichen Komponenten eines Enterprise Systems limitiert und ihrer Weiterentwicklung eingeschränkt. Andererseits wird der Betrieb der Applikationen und deren Weiterentwicklung aus technischer Sicht durch die Standardsoftwarehersteller vorgegeben. Der letztgenannte Aspekt erscheint vordergründig nicht so bedeutend zu sein, ist aber für die Organisation der IT und auch die Einführung der Systeme von hoher Bedeutung. Die Kompetenzbasis der IT-Ressourcen lässt sich nicht so einfach verändern, ist sie doch in den handelnden Personen begründet. Deren Wissen ist an die unterschiedlichen Ecosysteme technisch und auch ökonomisch gebunden, übergreifende und tiefe Domänenund Technologiekenntnisse sind überaus selten vorhanden. Folgerichtig werden von den Standardsoftwareherstellern in Abhängigkeit von dem Gegenstand der Einführung (den Komponenten eines ES, also BI, SCM, SRM, ERP, CRM und Shop-System) und dem Deployment-Modell in der Cloud unterschiedliche Vorgehensmodelle mitsamt der die Einführung unterstützenden Tools für das Application Lifecycle Management offeriert (Aral et al. 2024), die auch noch anhand der verfolgten Zwecke des Vorgehensmodells variiert werden (z.B. Produktentwicklung eines Template-Systems, Rollout eines Template-Systems, Release-Wechsel). Zusätzlich bieten die im Ecosystem (Wulfert 2024) der Softwarehersteller befindlichen Implementierungspartner i.d.R. adaptierte, mitunter auch eigene Vorgehensmodelle, um sich von Wettbewerbern zu differenzieren. Die Partner im Ecosystem reichen von global agierenden Systemhäusern über Schulungsanbieter bis hin zu Freelancern. Die bei diesen Partnern im Fokus stehenden Vorgehensmodelle lehnen sich in der Regel an eher klassische sequenzielle oder iterative oder an agile Vorgehensmodelle an. Dabei ist die Art des Vorgehens bei einer Standardsoftware nicht so frei wählbar, wie dies bei einer Individualsoftware der Fall ist. Die Vorgabe der betriebswirtschaftlichen Inhalte in Form von Datenstrukturen und Prozessen führt ebenso wie die Art der Realisierung dergleichen in Softwarecode dazu, dass das Vorgehen inhaltlichen und technologischen Restriktionen unterworfen ist. Damit wird auch der Einsatz „echter“ agiler Vorgehensweisen in komplexen transakK 10 R. Schütte, M. Kari Klassisch SRM Enterprise-Systems-Ausprägung CRM Agil Vorgehensmodell BI ERP Shop SCM Abb. 1 Dominante Vorgehensmodelltypen bei Komponenten von ES-Systemen. Die Grafik trägt das dominante Vorgehensmodell gegen die Enterprise-Systems-Komponenten auf. ERP und SCM werden weiterhin weitgehend im klassischen Modell entwickelt, während SRM, Shop, CRM und BI-Systeme vorranging dem agilen Vorgehensmodell folgend entwickelt werden. (Eigene Darstellung) tionalen Systemen innerhalb eines Enterprise Systems selten praktiziert. Abb. 1gibt einen Eindruck wieder, wie wenig verbreitet agile Vorgehensmodelle nach Einschätzung der Autoren entgegen gegenteiligen Ankündigungen der Hersteller in realen Projekten im Enterprise-Systems-Kontext sind. Dabei sei vor allem darauf hingewiesen, dass ein SCModer ein ERP-System weitaus stärker transaktional komplexere betriebswirtschaftliche Prozesse realisiert, als dies in den anderen Systemen der Fall ist. Aufgrund der damit verbundenen Integrationsproblematik in diesen Systemen werden daher auch klassische Vorgehensmodelle erforderlich. Unabhängig von dem Vorgehensmodelltyp werden „Referenz-Vorgehensmodellartig“ die fünf Phasen Projektvorbereitung, Anforderungsdefinition (oder in der Sprache der Praxis auch als Business Blueprint bezeichnet), Realisierung, Produktionsvorbereitung und Go Live unterschieden (Kurbel 2021). In diesen Phasen werden Aufgaben mit Problemlösungstechniken gelöst und mittels Darstellungstechniken die Lösungen dokumentiert (vgl. zum Verständnis von Phasen, Aufgaben, Darstellungsund Problemlösungstechniken auch die Ausführungen bei Teubner 1999). Dabei sind die im Rahmen der Phasen wahrzunehmenden Aufgaben von der spezifizierten Domäne und der technologischen Basis abhängig. Die realen Einführungsfälle werden durch die Vorgehensmodelle des jeweiligen Standardsoftwareherstellers geprägt (sei es SAP, Oracle, Microsoft, Salesforce, o.a.), die i.d.R. durch herstellerK Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 11 spezifische Tools für das Application Lifecycle Management unterstützt werden. Die beiden zentralen Phasen, die Anforderungsdefinition und die Realisierung, weisen dabei standardsoftwarespezifische Aspekte auf: Die Anforderungsdefinition ist nicht frei, sondern folgt je nach Vorgehensmodell und Ziel der Systemeinführung den in der Software realisierten betriebswirtschaftlichen Vorgaben des Standardsoftwareherstellers (z.B. Greenfield und Brownfield der Systeme/Organisation und Ausrichtung am Standardsoftwaresystem als systemtechnischem Ziel oder betriebswirtschaftlich sinnvolle Ausrichtung an den Anforderungen des Unternehmens). Dabei herrscht in der Praxis zu Beginn des Projektes die Vorgabe vor, dass so viel Standard wie möglich und so wenig Individualisierung wie nötig realisiert werden soll. Es werden dabei unterschiedliche Arten von Vorlagen verwendet, wie auf konzeptioneller Ebene Prozessmodelle oder auch eingerichtete Systeme mit Stammdaten und konfigurierten Prozessmodellen (z.B. SAP Market Standard). Bei der Realisierung folgt diese den technischen Rahmenbedingungen der heutigen Systemkomponenten, die i.d.R. einen historischen Hintergrund haben und damit auch die eingesetzten Paradigmen und Services begrenzen. Diese beiden Aspekte werden im nachfolgenden Kapitel aufgegriffen. Für die spätere Analyse der Einführungsveränderung durch neue Architekturprinzipien in einem Cloud Native Computing ist die Kenntnis beider Aspekte fundamental. 3 Architekturen im Cloud Computing 3.1 Cloud-Computing-Architekturen aus der Perspektive der Cloud Provider 3.1.1 Überblick Cloud Computing verleiht Hardware diejenigen Skalierbarkeitsund Automatisierungseigenschaften, die davor nur Software vorbehalten waren. Das Bereitstellen eines Computers, zehntausender Computer, eines globalen Netzwerks von Satelliten-Bodenstationen oder sogar eines Quantencomputers erfordert nicht mehr als eine Internetverbindung und das Ausführen einiger Codezeilen (und einer Kreditkartennummer). Von der Bereitstellung einer Webseite für eine lokale Schülerzeitung bis hin zum Betrieb von Netflix können alle erforderlichen Systemressourcen (Computer, Netzwerk, Datenbanken, Benutzerauthentifizierungsdienste oder GPU (Graphics Processing Units)-Cluster, die für das Training im Rahmen von Machine-LearningWorkloads benötigt werden) im gewünschten Layout in Software definiert und vollautomatisch bereitgestellt werden (Armbrust et al. 2009; Barroso et al. 2003;Waibel 2020). Das Cloud Computing soll für die Anwendungsunternehmen erheblich vereinfachte und beschleunigte Entwicklungsund Betriebsprozesse ermöglichen. Dabei ist die Realisierung der Ziele nicht nur abhängig von der angebotenen Servicebreite und -tiefe der Cloud-Anbieter, sondern vor allem auch von den Fähigkeiten des einsetzenden Unternehmens. Das zentrale Wertversprechen der drei großen CloudK 12 R. Schütte, M. Kari Hyperscale – Amazon, Alphabet und Microsoft – besteht darin, eine gut gestaltete Provisioning API (Application Programming Interface) anzubieten, die KundenRequests entgegennimmt und die Ressourcen entsprechend automatisch bereitstellt (Fehling und Leymann 2018). Im Kontext dieses Beitrags kommt der Produkt-Portfolio-Architektur der Cloud Provider eine besondere Rolle zu, um ihre Wirkung auf die Erstellung und den Betrieb von Enterprise Systems aus einer Architekturentwicklungsperspektive beurteilen zu können. 3.1.2 Serviceniveau-orientierte Einordnung Die Architektur der Cloud-Provider wird kanonischerweise in Infrastructure-as-aService (IaaS), Platform-as-a-Service (PaaS), und Software-as-a-Service (SaaS) untergliedert, unter denen sich einzelne als Produkt angebotene Services subsumieren lassen (Anselmi et al. 2017). In diesem Beitrag werden die IaaS-Komponenten und PaaS-Komponenten anhand des Kriteriums der „Self-Hostability“ unterschieden. Es stellt sich die Frage, ob ein Service durch einen Cloud-Verwender selbst auf anderen Low-Level-CloudRessourcen in vergleichbarer Weise gehostet werden könnte. Eine IaaS-Komponente kann nicht selbst gehostet werden, wobei ein PaaS-Komponente durch Inanspruchnahme anderer Cloud-Ressourcen selbst betrieben werden könnte. Ein NFS (Network File Service)-kompatibler File Server (etwa AWS EFS, Azure Files, oder Google Cloud Filestore) ebenso wie ein S3-kompatibler Object Store (etwa AWS S3, Azure Blob Storage, oder Google Cloud Storage) könnte etwa in Eigenregie durch Verwendung virtueller Maschinen, daran angehängter virtueller Festplatten und Installation eines NFS-Kernel-Server selbst betrieben werden. In der Diktion dieses Beitrags wäre es damit eine PaaS-Komponente. Im Gegensatz dazu ist eine virtuelle Festplatte als IaaS-Komponente einzuordnen, da sie nicht selbst durch SoftwareInstallation betrieben werden kann, sondern – trotz aller dazwischenliegenden Virtualisierungsebenen – durch den Cloud Provider in Korrespondenz zu physischem Festplattenspeicher bereitgestellt werden muss. Darüber hinaus werden in diesem Beitrag PaaS-Komponenten und SaaS-Komponenten danach unterschieden, ob die vornehmliche Nutzergruppe der Komponenten Softwareentwickler und systemtechnische Nutzer sind oder eine EndnutzerSchnittstelle vorliegt. Dieses Kriterium dient als Indikator für die Positionierung im digitalen „Wertschöpfungsprozess“ eines Systems. Aus softwaretechnologischer und softwarearchitektonischer Sicht ist die Frage, ob die darunterliegenden Schichten als IaaS und PaaS bereitgestellt werden oft von geringer Bedeutung. Ob etwa eine Postgres-Datenbank auf einer virtuellen LinuxMaschine unmittelbar im Hoheitsgebiet des Cloud-Users installiert wurde, oder auf einer virtuellen Linux-Maschine beim Cloud Provider installiert ist, erscheint für den Anwendungsserver kaum unterscheidbar. In beiden Fällen genügen IP-Adresse und Port zur ODBC-Schnittstelle der Datenbank, um SQL-Abfragen auszuführen. Wenngleich es kaum Studien zur Wirkung des Cloud Computing auf die Softwarequalität gibt, wird angenommen, das auch jenseits der Bewertung der Skalierbarkeit als einer Qualitätsdimension von Software die Qualität weiterer Evaluationskriterien steigt. Ebenso gibt es kaum Daten dazu, welche ökonomischen oder qualitativen K Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 19 warehersteller versuchen, diese Abbildung der Anforderungen in seinem Ecosystem und seiner Plattform zu halten. So weist die SAP Business Technology Platform genau diese Entwicklung auf. Der Umsatz nimmt zu und die Implementierungspartner sind angehalten, die ehemals im Projekt erfolgte Entwicklung über die Plattform als weitere Lösungskomponenten zu entwickeln und anzubieten. Damit wird dann zukünftig der Standardsoftwarehersteller am Umsatz der Partner bei Wartungsgebühren profitieren, der Implementierungspartner auch und die Anwendungsunternehmen neben den Nutzungsgebühren über die SaaS-Services auch noch laufende Nutzungsgebühren für die über die PaaS genutzten Komponenten zu bezahlen haben. Dieses Spannungsfeld birgt enorme Gefahren, wenn die Systeme in der Zukunft so eingeführt würden wie dies in der Vergangenheit der Fall gewesen ist. Grundsätzlich dürfte dabei die Transformation der Applikationsarchitekturen in die Cloud auch ein Anlass sein, bei dem die Prozesse grundsätzlich überdacht werden sollten. 4.3 Systemtechnische Revolution des Cloud Computing und deren Auswirkungen auf das IT-Management Die Aufgaben des IT-Managements und auch der operativen Betriebsprozesse werden in den Unternehmen durch das Cloud Computung auf der technischen Ebene durch die Andersartigkeit nachhaltig das „Wie“ der IT-Prozesse verändern. Nachfolgend sollen anhand der skizzierten Enterprise-Systems-spezifischen Kombination von SaaSund PaaS-Lösungen die neuen Integrationsund Koordinationsanforderungen angedeutet werden. Die Integrationsanforderungen, die aus der Verbindung mit SaaS-Lösungen entstehen (z.B. die Integration eines CRM von Salesforce mit dem ERP von SAP) bilden eine tradierte Aufgabe, die aufgrund der erwarteten Modularisierung von ES-Landschaften (Gartner 2020) weiter zunehmen werden. Dabei besteht aufgrund der zum Teil „erzwungenen“ Updates durch Cloud-Native-Anwendungen eine Aufgabe in der Unterstützung des Versionsmanagements durch wesentlich agilere ITProzesse. Eine bestehende Aufgabe, die dieses Problem ebenso betrifft, ist das Testmanagement. Das Testen wird zu einem laufenden Standardprozess, denn es sieht aktuell nach drei Versionierungen pro Jahr aus, so wie es Salesforce als erster großer Proponent und Anbieter des Cloud Computing für ES seit längerem praktiziert. Auch die Architekturund Integrationsmanagementaufgaben werden wichtiger und können von dem IT-Management nicht mehr missachtet werden. Die Koordinationsherausforderungen ergeben sich aus der institutionellen Komplexität, denn die ehemals dominant im eigenen Unternehmen wahrgenommenen Aufgaben sind zukünftig von einem Netz von Dienstleistern, Cloud-Anbietern und dem Unternehmen selbst wahrzunehmen. In diesem Zuge werden intern die Aufgaben zwischen der IT-Abteilung und den Fachbereichen neu verteilt und ehemals interne Aufgaben auch von Dienstleistern wahrgenommen. Damit setzt sich ein Trend fort, in dem sich die IT-Abteilung seit Jahren befindet und die IT-Wertschöpfungsketten verändern sich dramatisch. Damit wird auch die Diskussion um die Rollen von Chief Digital Officer und Chief Information Officer neu belebt und die IT-Systeme und deren Organisation wird viel stärker in dem Operations Management verankert werden, so die Prognose der Autoren. Für die Forschung ergeben K 20 R. Schütte, M. Kari sich damit neue Herausforderungen, die effektive und effiziente Organisation der IT und ihrer Prozesse zu untersuchen. Die Integrationsund Koordinationsproblematik wird durch einen mitunter zu gering beachteten Aspekt zusammengebracht: die Kompetenzen der Mitarbeiter. Die durch die Mitarbeiter repräsentierten Kompetenzen bilden die zentrale Knappheitsressource, an der sich die Entscheidungen auszurichten haben. Diese Überlegung, die dem Ausgleichsgesetz der Planung nach Gutenberg (1951, S. 126) folgt, erfordert aber zunächst eine Operationalisierung, die allerdings sowohl für Unternehmen als auch für die Wissenschaft sehr spannende, gestaltungsorientierte Einsichten bietet. 5Fazit Enterprise Systems stehen vor enormen Herausforderungen in Zeiten des Cloud Computing, denn die meisten der bestehenden Systeme weisen noch nicht die Modul-Charakteristika der in Abschn. 3 skizzierten Referenzarchitektur auf. Damit werden auch die Strategie und die zukünftige Einführungsweise sich erst in den nächsten Jahren sichtbar in den Unternehmen verändern. Es sind aufgrund der technologischen Bestrebungen bereits jetzt einige Trends offensichtlich. Zunächst wird die von den Herstellern zwingend verfolgte Reduktion der Systemkomplexität dazu führen, dass es mehr Standard im Kern der Systeme geben wird. Außerdem wird dadurch die Verbindung von SaaSund PaaS-Lösungen zwingend, so dass mehr Individualentwicklungen möglich werden – bei einer Separierung der spezifischen Individualisierungswünsche in Side-by-Side-Ansätzen. Diese Differenzierung zwischen den auch gerne als „lean core“ bezeichneten ES-Komponenten und den spezifischen Anforderungen des Unternehmens eröffnet auch die Möglichkeit, die strategisch wichtigen Anforderungen für Flexibilität und Agilität des Unternehmens außerhalb des vom Hersteller dominierten Softwarekontext zu realisieren. Damit ist es möglich, auch unter Betrachtung der AI Capabilities, dass wir ein neues Zeitalter von Individualsoftware erwarten dürfen, welches die ES-Komponenten als Commodity betrachtet. In jedem Fall wird deutlich, dass das Cloud Computing die Spielregeln zwischen Herstellern und Anwendungsunternehmen verändert und letztlich fundamental für die gesamte unternehmerische Entwicklung ist. K Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 21 6 Anhang Tab. 1 Service-(Produkt-)Angebot der Hyperscaler auf den unterschiedlichen Serviceebenen. (Eigene Darstellung) AWS Azure Google Cloud META-SERVICES Logging CloudTrail Monitor Logs Cloud Audit Logs Cloud User IAM IAM Identity Management IAM Billing Billing and Cost Management Billing Cloud Billing Cost Reduction Recommender Cost Optimization Cost Management Infrastructure as Code Resource Provisioning CloudFormation Azure Resource Manager Terraform on Google Cloud NETWORKING VPC VPC Virtual Network VPC DNS Route 53 DNS Cloud DNS CDN CloudFront Front Door Media CDN Firewall Web Application Firewall Web Application Firewall Cloud Armor Load Balancing Elastic Load Balancing Load Balancer Cloud Load Balancing PRIVATE CLOUD Integration at dedicated peering locations Direct Connect Express Route Cloud Interconnect Installation Outposts Stack Distributed Cloud COMPUTE: OS VIRTUALIZATION VMs EC2 Virtual Machines Compute Engine Remote Desktop WorkSpaces Virtual Desktop Compute Engine Transient Batch Jobs (also compatible containers) Batch Batch Batch COMPUTE: CONTAINER VIRTUALIZATION Kubernetes EKS AKS Kubernetes Engine High-Level Container Platform Fargate Container App Cloud Run Low-Level Container Platform ECS Container Instances Cloud Run COMPUTE: SERVERLESS Functions Lambda Functions Cloud Functions K 22 R. Schütte, M. Kari Tab. 1 (Fortsetzung) AWS Azure Google Cloud STORAGE Block EBS Disk Storage Persistent Disk Object S3 Blob Storage Cloud Storage Relational proprietary Aurora SQL AlloyDB, Cloud Spanner Relational 3rd party RDS Database SQL NoSQL DynamoDB Table Storage, Cosmos DB Datastore, Bigtable In-Memory Key-Value Store (Redis/Memcached) ElastiCache Cache Memorystore NFS/SMB EFS Files Filestore DATA-INTENSIVE COMPUTE/WORKLOADS & ML WORKLOADS SQL Query Engines (~Presto) Athena Synapse Polybase Presto on Dataproc ML Orchestrator SageMaker Machine Learning Studio Vertex AI SQL Data Warehouse Redshift Synapse Analytics BigQuery Data Lake Governance Lake Formation Data Share Dataplex ETL Glue Data Factory Cloud Data Fusion MPP EMR HDInsight Dataproc Enterprise Search Kendra AI Search Cloud Search Visualization QuickSight Power BI Looker Data Metadata Management Glue Data Catalog Data Explorer, Purview Dataplex SYNCHRONOUS COMMUNICATION API Management API Gateway API Management API Gateway GraphQL AppSync API Management (as a feature) Apigee (as a feature) ASYNCHRONOUS (EVENT/MESSAGE-BASED) COMMUNICATION Message Broker (~RabbitMQ) MQ, SQS+ SNS Service Bus Pub/Sub Stream Processing (~Kafka) Kinesis Event Hubs Partner Confluent Cloud Queuing SQS Queue Storage Pub/Sub Event Bus/Event Routing EventBridge Event Grid Eventarc Workflow automation Step Functions Logic Apps Workflows GENERIC APP SERVICES End User IAM Cognito App Service Auth Identity Platform, Firebase Auth Secret Management Secrets Manager Key Vault Secret Manager Web Hosting Amplify Hosting Firebase Hosting Static Web Pages Logging and Monitoring (~OpenTelemetry, Splunk, Sentry) CloudWatch Monitor Logs Cloud Logging Enterprise User IAM IAM Identity Center Entra ID Cloud Identity K Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen 23 Tab. 1 (Fortsetzung) AWS Azure Google Cloud App Framework Amplify App Service Firebase Tracing X-Ray Application Insights Cloud Trace (PRE-)TRAINED AI APIS Text-to-Speech Polly AI Speech Text-to-Speech AI NLP Comprehend AI Language Natural Language Conversational AI (Chatbots) Lex AI Bot Diagflow, Vertex AI Agent Translation Translate AI Translator Translate Computer Vision Rekognition AI Vision Vision AI CODE AUTOMATION CI/CD CodePipeline, CodeBuild, CodeDeploy, CodeCommit GitHub, Azure DevOps, Repos Cloud Build, Cloud Deploy, Source Repositories Registry ECR Container Registry, Artifacts Artifact Registry FULL-STACK SAAS APPLICATIONS SAP Deployment SAP on AWS (EC2, EBS, VPC, EFS) SAP on Azure (VMs, Disk Storage, Virtual Network, Files) SAP on Google Cloud (Compute Engine) Funding Open Access funding enabled and organized by Projekt DEAL. Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen. Weitere Details zur Lizenz entnehmen Sie bitte der Lizenzinformation auf http://creativecommons.org/licenses/by/ 4.0/deed.de. Literatur Anselmi J, Ardagna D, Lui JC, Wierman A, Xu Y, Yang Z (2017) The economics of the cloud. TOMPECS, Bd. 2(4). ACM Transactions on Modeling and Performance Evaluation of Computing Systems Aral S, Brynjolfson E, Gu C, Wang H, Wu DJ (2024) Understanding the returns from integrated enterprise systems: the impact of agile and phased implementation strategies. MISQ 48(2):749–774 Armbrust M, Fox A, Griffith R, Joseph AD, Katz RH, Konwinski A, Lee G, Patterson DA, Rabkin A, Stoica I, Zaharia M (2009) Above the clouds: a Berkeley view of cloud computing. Technical report, Bd. UCB/EECS-2009-28. University of California, Berkeley Barroso L, Dean J, Hölzle U (2003) Web search for a planet: the Google cluster architecture. IEEE Micro 23(2003):22–28 Brehm L, Heinzl A, Markus ML (2002) Tailoring ERP systems: a spectrum of choices and their implications. Proceedings if the 34th Annual Hawaii International Conference on Systems Sciences. Track: K 24 R. Schütte, M. Kari Organizational Systems and Technology, Minitrack: ERP System Issues and Answers, Island of Maui (Hawaii, USA), January 3–6, 2001 Buxmann P, König W (1997) Empirische Ergebnisse zum Einsatz der betrieblichen Standardsoftware SAP R/3. Wirtsch Inform 39(4):331–338 Christensen C (1997) The innovator’s dilemma: when new technologies cause great firms to fail, 1. Aufl. Harvard Business Review Press Dittrich Y, Vaucouleur S (2008) Practices around customization of standard systems. In: Cheng L, Sillito J, Storey MD, Tessem B, Venolia G, de Souza CRB, Dittrich Y, John M, Hazzan O, Maurer F, Sharp H, Singer J, Sim SE (Hrsg) Proceedings of the 2008 International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 2008, Leipzig, Germany, Tuesday, May 13, 2008. ACM, S 37–40 https://doi.org/10.1145/1370114.1370124 Fehling C, Leymann F (2018) Provisionierung. Gabler Wirtschaftslexion. Springer Gabler (https:// wirtschaftslexikon.gabler.de/definition/provisionierung-53362) Gartner (2020) The future of ERP is composable. https://www.gartner.com/en/documents/3991664. Zugegriffen: 10. Dez. 2022 Gronau N (2021) ERP-Systeme. Architektur, Management und Funktionen des Enterprise Resource Planning, 4. Aufl. Walter de Gruyter, Berlin, Boston Gutenberg E (1951) Die Produktion, 1. Aufl. Bd. 1. Springer, Berlin, Heidelberg https://doi.org/10.1007/ 978-3-662-21965-2 Hansen HF, Haddara M, Langseth M (2023) Investigating ERP system customization: a focus on cloudERP. Procedia Comput Sci 219:915–923 Hentschel R, Leyh C (2016) Cloud Computing: Gestern, heute, morgen. HMD 53(2016):563–579 Hentschel R, Leyh C, Petznick A (2018) Current cloud challenges in Germany: the perspective of cloud service providers. J Cloud Comput 7:5 Hoepfner G (2021) Interview von Guido Hoepfner zur SAP-Einführung bei ALDI Nord durch Reinhard Schütte Klaus H, Rosemann M, Gable G (2000) What is ERP? Inf Syst Front 2(2):141–162 Kurbel KE (2021) Enterprise resource planning und supply chain management in der Industrie, 9. Aufl. Springer, Berlin, Heidelberg Leyh C, Wendt T (2018) Enterprise Systems als Basis der Unternehmens-Digitalisierung. HMD 55:9–24 Olson DL, Kesharwani S (2010) Enterprise information systems. Contemporary trends and issues. World Scientific, New Jersey et al. Sarferaz S (2022) Compendium on enterprise resource planning. Market, functional and conceptual view based on SAP S/4HANA. Springer, Berlin Sarferaz S (2023) ERP-Software: Funktionalität und Konzepte. Basierend auf SAP S/4HANA. Vieweg, Wiesbaden Schütte R (1998) Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion konfigurationsund anpassungsorientierte Modelle. Gabler, Wiesbaden Schütte R (2023) ERP-Systeme in der Ära des Cloud Computings. ERP information, Bd. 1/2023. DPI Verlag, S 15–19 https://doi.org/10.58678/erp-information_23-1_15-19 Schütte R (2024) The next generation of ERP systems: problems of traditional ERP-Systems and the next wave of really standardized ERP-Systems. In: Strecker S, Jung J (Hrsg) Informing possible future worlds—Essays in honour of Ulrich Frank. Logos, Berlin, S 427–452 Teubner A (1999) Organisationsund Informationssystemgestaltung : theoretische Grundlagen und integrierte Methoden. Gabler, Wiesbaden Waibel P (2020) Cloud-based elasticity for business processes and data storage. TU Wien (Dissertation) Wulfert T (2024) Selected perspectives on platforms in E-commerce ecosystems. Recommendations for the design and management of boundary resources and guidance on the orchestration of ecosystem participants. Springer, Berlin Hinweis des Verlags Der Verlag bleibt in Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutsadressen neutral. K