Dank Componentware sollen Softwaresysteme nicht länger Monolithen aus der Werkstatt nur eines Herstellers sein, sondern aus allen möglichen Modulen bestehen. Auf einem Client sollte demnach nur noch eine Basissoftware installiert sein, während die nur gelegentlich benötigten oder hochspezialisierten Programmodule bei Bedarf vom Netz geladen werden. Componentware gilt als geschäftliche Alternative zu Marktführern wie SAP und Microsoft.
Doch existiert Componentware bis heute nur in Ansätzen. Gleichwohl könnte ihm die Zukunft gehören. Denn die absehbaren Anforderungen der Anwenderorganisationen lassen sich nur erfüllen, wenn Systeme durch Objektorientierung und offene Schnittstellen modularisiert werden.
Die großen unternehmenstragenden Softwaresysteme müssen mehreren Aspekten Rechnung tragen: Es muß erstens eine Kombination und ein Zusammenspiel von leistungsfähiger und funktional weit entwickelter kaufmännischer Standardsoftware mit hochspezialisierter, branchen- und anwendungsspezifischer Software möglich sein.
Zweitens gilt es, individuell entwickelte Komponenten mit hinzugekauften zu kombinieren. Die Verknüpfung darf nicht auf einer niedrigen Ebene des Datenaustauschs stattfinden, sondern muß die Bearbeitungsfunktionen und Datenobjekte verbinden.
Teile der Softwaresysteme müssen sich drittens voneinander entkoppelt lassen, um die Pflege, das Update und den Austausch von Teilen einer Lösung leichter möglich zu machen. Entwickler müssen viertens Teilfunktionen zukaufen können. Schließlich müssen sich Informationssysteme kurzfristig an veränderte Geschäftsprozesse anpassen lassen.
Im folgenden werden kommerziell verfügbare Ansätze von Componentware beurteilt. Im Mittelpunkt stehen unternehmensweite Lösungen. Komponententechnik für PC-Software wird hier nicht behandelt. SAP und IBM fallen als Anbieter besonders auf, obwohl (oder weil) die Ansätze, die Motive und der Realisierungsgrad sehr unterschiedlich sind.
SAP hat als ein Element einer Modularisierung Schnittstellen, die sogenannten Business Application Programming Interfaces (Bapis), eingeführt, die einige Anwender in der Praxis bereits eingesetzt haben, um selbstentwickelte Lösungen mit R/3 zu verbinden. Oft handelt es sich bei den angebundenen Komponenten der Anwender um Software zur prozeß- und kundennahen Datenerfassung im Bereich Service, Außendienst, Betriebsdatenerfassung oder Fertigungssteuerung.
Auch andere DV-Anbieter nutzen die Schnittstellen und Business Objects von R/3, um ihre Lösungen auf hoher logischer Ebene mit der Standardsoftware zu kombinieren. Das zentrale, dominante System, in dem die Geschäftsprozesse abgebildet sind, bleibt aber bestehen. Die Komponenten der Partner sind eher hilfreiche oder, wie SAP es ausdrückt, "komplementäre" Ergänzungen.
Das Konzept dient nicht nur dazu, um sich für Dritte zu öffnen, vielmehr erfolgen längst fällige Modularisierungen. SAP führt an, daß sich nun auch einzelne Komponenten wie "Personalwirtschaft" oder "Konsolidierung" austauschen lassen, selbst dann, wenn sie nicht demselben R/3-Release angehören.
Klagen der Anwender finden Resonanz
Was hier als Fortschritt gepriesen wird, hat mancher Anwender seit langem beklagt. Möglicherweise war dies sogar der eigentliche Grund, der zur Komponentenstrategie bei R/3 geführt hat.
Dennoch hat SAP Flexibilität und Schnelligkeit bewiesen. Als Marktführer kann das Unternehmen auch leichter eigene "Standards" setzen und muß nicht warten, bis sich breitere Übereinkünfte ergeben. Das ist ein Problem der kleineren Softwarehäuser. Normierungsversuche gibt es auf der Ebene der Objekttechniken (zum Beispiel Corba), während firmenübergreifende Aktivitäten zur Vereinheitlichung von Business-Objekten kaum wahrzunehmen sind. Das Componentware Consortium (CWC) ist beispielsweise 1997 nicht mehr in der Öffentlichkeit aufgetreten.
Andere Anbieter von Standardsoftware erwecken eher den Eindruck, daß sie nur mühsam reagieren. Beispielsweise hat Baan im November 1997 einen "Fahrplan" angekündigt, wie die eigene Software in Komponenten zerlegt werden soll. Dies soll im ersten Halbjahr 1998 zu Ergebnissen führen.
Siemens-Nixdorf hatte einen interessanten Ansatz zur Componentware: "ALX Comet" sollte die Verbindung von SNI-Komponenten mit Modulen ermöglichen, die von branchenorientierten Softwarepartnern stammen. Allerdings hat SNI kapituliert und diese Geschäftsaktivitäten an Baan verkauft.
Ein grundsätzlich anderes Modell als SAP verfolgt IBM mit dem Projekt "San Francisco". Im Prinzip handelt es sich dabei um eine umfassende objektorientierte Entwicklungsumgebung, bei der bestimmte Softwarekomponenten gleich mitgeliefert werden. Nutzer dieses Angebots sind zunächst Softwarehäuser, besonders die große Zahl derer, die für den Mittelstand oder sehr branchenspezifisch entwickeln.
Sie erhalten vorgefertigte Common Business Objects, vorbereitete Strukturen, mit denen sich Kunden, Projekte, Zahlungsverfahren etc. abbilden lassen. Darüber hinaus liefert IBM sogenannte Core Business Processes mit. Heute ist dies eine Sachbuchhaltung, 1998 sollen eine Debitoren-, eine Kreditorenbuchhaltung, Einkauf, Verkauf und Lagerwirtschaft folgen.
Diese Komponenten kann der Software-Entwickler erweitern oder verändern und in eine Gesamtlösung integrieren. Den Überbau, die Spezifika und die gesamte Benutzeroberfläche entwickelt das Softwarehaus. Die Geschäftsprozesse bildet damit der jeweilige Entwickler in der Software ab.
Durch die Komponenten sollen laut IBM rund 40 Prozent der Sachlogik einer kompletten Anwendung bereits vorgefertigt sein. Softwarehäuser und Technologieberater halten diese Maßgröße für realistisch, bemerken aber auch, daß die Einarbeitung und das Kennenlernen der verfügbaren Funktionsbausteine sehr aufwendig werden können.
Die Lizenzierung erfolgt ähnlich wie bei anderen Entwicklungsumgebungen. An IBM werden entsprechende Gebühren dann fällig, wenn das gesamte System beim Anwender installiert wird. IBM geht also deutlich in Vorleistung und kann mit Gewinnen aus "San Francisco", wenn überhaupt, erst in ferner Zukunft rechnen. Der geschäftliche Ansatz des Unternehmens ist es eher, die Entwickler zu stärken, und weniger, mit eigenen Angeboten direkt am Markt aufzutreten. Zweifellos will IBM damit auch die bisherigen AS/400-Entwickler bei der Stange halten.
Hieran machen sich die größten Zweifel fest: Ist IBM als Partner zuverlässig genug, diese Plattform langfristig so weiterzuentwickeln, daß die Softwarehäuser zu marktgängigen Lösungen kommen? Wo liegt der geschäftliche Nutzen von IBM? Ist dies nur ein Laborprojekt, das Objekttechnologen angezettelt haben, oder steht IBM strategisch dahinter?
Besonders spannend wird die Geschichte, wenn man die Plattform betrachtet. San Francisco wurde mit der Programmiersprache C++ begonnen, ist inzwischen aber vollständig auf Java umgestellt.
Damit kann man einige Mutmaßungen zur Strategie von IBM anstellen: Wenn San Francisco bei den Entwicklern Anklang findet, könnte Big Blue derzeitige Performance-Probleme lösen, indem man spezialisierte Prozessoren baut oder die AS/400-Linie in Richtung Java-Performance weiterentwickelt. Die Eigenständigkeit beim Power-PC-Prozessor würde so geschäftlich genutzt, letztendlich käme sogar ein Zusammengehen mit Sun Microsystems in Betracht.
Zu dieser These paßt, daß der Konzern an verschiedenen Stellen recht konsequent auf Java setzt. So entsteht ein Access Builder für SAP R/3, der R/3-Business-Objects vollständig in Java-Beans umsetzt. Damit ließen sich auch Java-Programme an R/3 anbinden. Und noch ein Element gehört zu diesem Szenario: Die "Net Stations" sind IBM-NCs ohne Microsoft-Betriebssystem, sehr wohl aber in der Lage, Java-Programme ablaufen zu lassen. Damit entsteht der Eindruck, daß IBM im Sinn hat, hier eine Hard- und Softwarekonkurrenz zur "Wintel"-Schiene aufzubauen.
Das gesamte Szenario paßt in eine denkbare, glaubwürdige Geschäftsstrategie von IBM. Es könnte ein großer Wurf werden. Doch müssen viele Funktionen erst noch entstehen, technische Probleme, unter anderem in Sachen Performance, harren einer Lösung. Das alles kann noch Jahre dauern. Wenn namhafte IBM-Entwicklungspartner nennenswerte Kapazitäten für San Francisco einsetzen, dann ist eine erste Hürde genommen - aber nicht mehr. Allerdings ist das Interesse bei den Partnern groß, besonders in deutschen Softwarehäusern. IBM hat eine relativ hohe Bindung an diese Partner und dürfte sie nicht ohne Not im Stich lassen.
*Dieter Sinn ist Consultant in München.