Die vom Internet diktierte "Einfachheit" von Software-Anwendungen wird auch in Walldorf ernstgenommen. Ein für Intranets geeignetes Graphical User Interface (GUI), im SAP-Jargon als Service-Transaktion bezeichnet, soll keine Einarbeitung mehr erforderlich machen und frei von der Funktionsüberfrachtung sein, die R/3 so oft vorgeworfen wird. Der Weg dorthin kostet laut Plattner viel Mühe, dafür winkt den Walldorfern mit den kommenden "Consumer-to-Business"- und "Business-to-Business"-Lösungen ein nahezu unbegrenzter Markt. Bedienten die großen R/2-Installationen von 1991 rund 500 Concurrent User, so sollen die R/3-Zugriffe über das Internet bis in die Millionen reichen, da auch Consumer-Einwahlen direkt im R/3-Back-end abgerechnet werden sollen.
Um möglichst viele Benutzer im Rahmen von erweiterten Logistikketten zu integrieren, denkt SAP an einen Workflow, der jedem Teilnehmer seine jeweils benötigte Sicht auf zentrale Prozesse gewährleistet. Die Aufgabe besteht also darin, die Transaktionen der einzelnen Prozesse im Hintergrund optimal zu organisieren, während am Front-end eine dynamisch modifizierbare Anwendung arbeitet. Im professionellen Umfeld sei dies weitgehend gelungen, bezüglich der vom Internet geforderten Einfachheit stehe man allerdings noch am Anfang, gibt Plattner zu.
Den Weg dorthin soll die neue, von SAP Mitte des Jahres vorgestellte R/3-Architektur, Version 4, ebnen. Darin werden Basisanwendungen wie das Finanz- und Personalwesen sowie logistische Applikationen in getrennt voneinander entwickel- und pflegbare Einheiten gegliedert. Die Integration dieser sogenannten Business-Komponenten wird dabei nicht aufgegeben. Mit diesem Schritt, der in dem für die zweite Jahreshälfte 1997 angekündigten Release 4.0 vollzogen sein soll, wollen die Walldorfer auch erreichen, daß die Module jeweils getrennt voneinander Release-fähig werden.
Eine parallele Initiative, deren erste Ergebnisse in dem ab Dezember verfügbaren Release 3.1 zu sehen sind, hat die Entwicklung von Geschäftsobjekten zum Ziel. Mit Inhalten wie "Konto", "Rechnung", "Kunde" oder "Auftrag" orientieren sich derartige Business Objects (BOs) ausschließlich an der Praxis des Endanwenders. Der Benutzer erhält mit den Geschäftsobjekten die Möglichkeit, eine Anwendung entsprechend seiner Prozeßsicht zu gestalten. SAP zufolge mußte die BO-Ebene eingeführt werden, um eine von den zentralen Business-Komponenten unabhängige und flexible Gestaltung der Client-Anwendungen zu erreichen.
Bei der Definition eines Objekts, das je nach Inhalt über herstellerspezifische Schnittstellen auf mehrere Business-Komponenten zugreift, löst sich SAP von der eigenen proprietären 4GL "Abap" und steigt auf andere Entwicklungssprachen wie Java um.
Die Kommunikation der Objekte untereinander und deren Öffnung zu Software-Clients von Drittherstellern erfolgt über Business-APIs (BAPIs). Die anwendungsbezogenen Schnittstellen ermöglichen Entwicklern die Verwendung der Business-Objekte, um sie in Intranet-Lösungen zu integrieren.
Ein typisches Beispiel dafür wäre die Auftragsprüfung oder die Bestellverfolgung. SAP selbst wird gegen Ende dieses Jahres mit einer eigenen, auf BOs basierenden Anwendungssuite zunächst auf den amerikanischen Markt gehen, wo Intranets bereits intensiver als hierzulande genutzt werden.
Die vorerst 170 in einem Repository verwalteten BAPIs bilden den Dreh- und Angelpunkt für die Anbindung neuer Front-ends. Dabei spielt es keine Rolle, ob diese aus der Microsoft- oder Netscape-Welt kommen, ob mit Visual Basic, Active X oder Java programmiert wird. Entscheidend ist laut Plattner, daß sich Anwendungen auf BAPI-Ebene leichter schreiben lassen als R/3-Zusätze, die über technische Schnittstellen gehen und damit auf Grunddaten von R/3 zugreifen können. Um keine Verunsicherung wegen möglicherweise wechselnder Schnittstellen-Definitionen aufkommen zu lassen, verspricht der SAP-Chef, die BAPIs über mindestens zwei R/3-Releases hinweg konstant zu halten.
Wer angesichts der als "Business Framework" bezeichneten, neuen Systemarchitektur jedoch glaubt, zentrale R/3-Applikationen umbauen zu können, wird von Plattner in die Schranken verwiesen: Bei den Business Objects handle es sich um Subsets der in R/3 enthaltenen Funktionalität, die sich ausschließlich zur Anwendungsentwicklung für Front-end-Systeme eignen. Wie weit ein Objekt und dessen Schnittstelle in R/3 fortgeführt beziehungsweise wann ein objektorientierter Aufruf von einem der mehreren 100000 Funktionsaufrufe ersetzt werde, sei allein die Angelegenheit der SAP-Entwicklung.
Wenig Befürchtungen hegt Plattner in der Hinsicht, daß Unternehmen bei ihren geschäftskritischen Anwendungen dazu übergehen könnten, sich selbst eine Lösung aus den am Markt angebotenen Komponenten zu stricken. Dem Kunden nutze es nichts, mehrere hundert Einzelverträge mit Applet-Herstellern zu schließen, wenn ein immer komplexer werdendes Anwendungsmodell beherrscht werden müsse. Vergleichbar mit der Konzentration der Hersteller im Flugzeug- und Automobilbau schrumpfe künftig auch die Software-Industrie auf wenige Häuser, die in der Lage seien, große integrierte Systeme zu entwickeln und dafür Wartung, Service sowie eine Garantie für die Funktionsweise aller von Drittanbietern abgestimmten Komponenten zu übernehmen.
Von der Technologiegläubigkeit, die sich im Zuge der Objekt- und Komponententechnik ausgebreitet hat, hält Plattner ohnehin nicht allzuviel. Zwar unterstütze SAP bezüglich der Anbindung von Fremdprodukten Microsofts Common Object Model (COM) und Distributed COM sowie demnächst auch die Konkurrenzstandards der Common Object Request Broker Architecture (Corba). Von der Anwendungsseite her kommend, dürfe man jedoch solche Techniken nicht allzu religiös betrachten. Die Komplexität einer Organisation müsse erst einmal verstanden werden, und hier sei SAP ein ganzes Stück weiter als Komponentenhersteller, die bei der PC-Software im Extremfall nur den Einzelplatz kennen. 25jährige Erfahrungen mit Organisationsstrukturen ließen sich nicht durch ein neues Softwaredesign oder ein Gremium umdefinieren.