Extrait
Inhaltsverzeichnis
1. Einleitung
2. Vorgehensweise
3. Komponententechnik
3.1. Definition und Begriffe
3.2. Anforderungen an moderne Komponententechnik
3.3. Benefits von Componentware
3.4. Problematik beim Einsatz von Komponententechnik
4. Komponententechnik am Beispiel SAP
5. Der technologische Wandel des Systems SAP R/3
6. Kritische Betrachtung des aktuellen SAP R/3-Systems
7. Schlußbetrachtung und Fazit
Abbildungsverzeichnis
Abbildung 1 - Evolution des Business Framework
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
,,Zeit ist Geld, und Flexibilität unabdingbar: Deshalb sind kurze Entwick-lungsphasen von flexibler Anwendungssoftware immer wichtiger für den reibungslosen Geschäftsablauf."1 Der hohe Innovationszwang im Bereich Informationstechnologie und die ständig wechselnden wirtschaftlichen Rahmenbedingungen in den Unternehmen, machen den langwierigen Prozeß der Entwicklung und Installation neuer Softwareprodukte zunehmend kompliziert. Um diesem Entwicklungsdruck standzuhalten und die Prozesse zu beschleunigen, hat sich in den letzten zwei Jahren ein Wandel bei der Erstellung und dem Einsatz von Softwareprodukten ergeben.
Bei der Entwicklung neuer Standardsoftware wird seit einiger Zeit immer mehr der Übergang von komplexen Systemen hin zu kleineren, funktionsorientierten Anwendungskomponenten vollzogen.
Warum die sogenannte Komponententechnik (engl. Componentware) in den Augen der Unternehmensführung und des IT-Managements immer mehr an Bedeutung gewinnt, läßt sich durch folgendes Zitat eines amerikanischen Netzwerkadministrators belegen: ,,Ich brauche kleinere Anwendungen, will aber nicht auf Funktionalität verzichten."2 Nicht nur diesem zentralen Anspruch, sondern sämtlichen Anforderungen aus den verschiedensten Bereichen, muß eine moderne Software gerecht werden. Mit Hilfe der sich seit ca. zwei Jahren immer mehr durchsetzenden Componentware gelingt es den Softwareherstellern, diesen Forderungen in einem geeigneten Maße zu entsprechen.
2. Vorgehensweise
Da im Rahmen dieses Seminars die Grundlagen und Auswirkungen von Komponententechnik in den vorangegangenen Ausarbeitungen ausführlich geschildert wurden, liegt der Schwerpunkt dieses Referats in der Betrachtung der Standardsoftware SAP. Im folgenden Kapitel (3. Kapitel) wird zunächst eine kurze Einführung in die Thematik der Komponententechnik sowie die grundlegenden Begriffe dieser Softwarearchitektur gegeben. In Abschnitt 3.2. wird aufgezeigt, welche unterschiedlichen und vielschichtigen Anforderungen an diese moderne Softwarearchitektur gestellt werden. Danach werde ich versuchen, die Benefits bei der Entwicklung und Verwen-dung von Componentware herauszuarbeiten.
Nicht zu vernachlässigen ist jedoch die Problematik, die für die Anwender von Komponententechnik entsteht, auf die im Kapitel 3.4. näher eingegangen wird.
Das zentrale Kapitel dieser Arbeit (4. Kapitel) beschreibt ausführlich die vom Walldorfer Softwareunternehmen SAP AG entwickelte Komponententechnik, die im 6. Kapitel kritisch beurteilt wird.
Das 7. Kapitel gibt dem Leser noch einmal eine kurze Zusammenfassung über die dargestellten Sachverhalte.
3. Komponententechnik
Durch die Entwicklung und den Einsatz von Komponententechnik hat die Arbeitsweise der verantwortlichen EDV-Beauftragten und Programmierern einen entscheidenden Wandel erfahren. ,,Die eigentliche Programmentwicklung verlagert sich damit mehr und mehr weg von der Programmierung und hin zum der Lösung und zur Montage der Komponenten."3 Der Grundgedanke von Componentware ist dabei, Softwaresysteme aus Standardkomponenten zusammenzusetzen, die auch von unterschiedlichen Herstellern entwickelt worden sein können.
Es ist eine angemessene Dokumentation erforderlich, um die Komponenten entsprechend ihrer Funktionalität in einem bestimmten betriebswirtschaftlichen Kontext integrieren zu können.4
3.1. Definition und Begriffe
Komponente
Unter dem Begriff Komponente versteht man in der Fachliteratur ,,ein Stück Software, das klein genug ist, um es an einem Stück erzeugen und pflegen zu können, groß genug ist, um eine sinnvoll einsetzbare Funktionalität zu bieten, und mit einer standardisierten Schnittstelle ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten."5
Componentware
Mit dem Begriff Componentware werden Anwendungssysteme umschrieben, die aus verschiedenen Bausteinen (Komponenten) zusammengestellt werden. Diese Anwendungssysteme werden durch Selektion (Auffinden bzw. Auswählen der geeigneten Komponente), Modifikation (Anpassen bzw. Erweitern der gewählten Komponente) und Montage (Kombination mit den anderen Bausteinen des Systems) zu einem ablauffähigen Softwaresystem kombiniert. 6
Framework
Frameworks sind wiederverwendbare Softwarearchitekturen und dienen als Basistechnologie für Componentware.7 Frameworks fassen das Wissen über Funktionsweisen und architektonische Strukturen eines Anwendungsbereichs zusammen und kondensieren dieses in einer weiter- und wiederverwendbaren Form.8 Das Framework stellt die Funktionalität zahlreicher Geschäftsprozesse standardmäßig zur Verfügung, was zur Vereinheitlichung und Senkung der Komplexität der Systeme führt.
Business Object
Unter Business Objects versteht man Anwendungen, die sich an die Wünsche und
Erfordernisse eines Unternehmens anpassen können. Zum Zweck der Kompexitätsreduktion werden detaillierte Unternehmensobjekt wie Kunde, Bestellung oder Artikel unter dem Dach eines Business Objects zu einer größeren Einheit zusammengefaßt. Diese werden schließlich durch Schnittstellen miteinander verbunden, um eine Kommunikation zwischen den einzelnen Komponenten bzw. Bereichen zu ermöglichen.
3.1.Anforderungen an moderne Komponententechnik
,,Beim Entwurf von Komponenten ist unbedingt auf die spätere Wieder-verwendbarkeit zu achten. Eine Komponente, die nicht wiederverwendet werden kann, ist keine Komponente"9 Die Wiederverwendbarkeit von Komponenten ist die zentrale Anforderung bei der Programmentwicklung innerhalb dieser Softwarearchitektur. Dabei beschreibt der Begriff Wiederverwendbarkeit die Eigenschaft von Bausteinen, teilweise oder vollständig bei der Erstellung unternehmensspezifischer Anwendungssysteme verwendet werden zu können.10
Die Anforderung der Wiederverwendbarkeit setzt eine völlige Offenheit der entwickelten Komponenten durch Verwendung von Schnittstellenstandards (z.B. CORBA, COM/DCOM , ActiveX, OLE) und Kommunikationsstandards (z.B. TCP/IP) voraus.
Eine weitere wichtige Anforderung an moderne Componentware ist die vollständige Integration des betriebswirtschaftlichen Hintergrunds. Darunter versteht man, daß bei der Modellierung der Anwendungen darauf zu achten ist, daß die gleichen Komponenten in möglichst vielen unterschiedlichen Geschäfts-prozessen eingesetzt werden können. 11 Weiterhin muß eine hohe Anpaßbarkeit (Customizing) gewährleistet sein, d.h. die Komponenten der Standardsoftware müssen ohne Modifikation von Pro-grammen an die individuellen Geschäftsprozesse eines Unternehmens angepaßt werden können. Im Hinblick auf die zukünftige Entwicklung des Marktes bzw. der Unter-nehmung muß komponentenbasierte Standardsoftware leicht erweiterbar sein, was bedeutet, daß unter
Beibehaltung der vorhandenen Komponenten zusätzliche Elemente hinzugefügt werden können. Wie bei der Implementierung sämtlicher neuer Software wird von den Unternehmen weiterhin eine leicht verständliche, anwenderfreundliche Bedienung, eine hohe Zuverlässigkeit und Verfügbarkeit des Systems, sowie ein geringer Wartungsaufwand gefordert.
3.3. Benefits von Componentware
Über die Vielzahl an Vorteilen durch die Entwicklung und Nutzung einer komponentenbasierten Softwarearchitektur ist man sich in der Fachwelt einig. Komponententechnik ermöglicht auf lange Sicht eine drastische Senkung der Entwicklungskosten für Individualsoftware, da man dazu übergegangen ist, betriebswirtschaftlich fundierte Standard-Anwendungskomponenten einzusetzen. Der
Anwender erhält flexible und vor allen Dingen skalierbare Systeme, die er entsprechend seiner Unternehmensanforderungen zusammensetzen und an-passen kann. Die Wiederverwendbarkeit von Softwarekomponenten garantiert dem Nutzer einen hohen Investitionsschutz, da die einzelnen Bausteine nahezu beliebig upgedated und ergänzt werden können, ohne daß ein komplettes neues System beschafft und implementiert werden muß. Änderungen in einzelnen Komponenten haben keine Auswirkung auf das Gesamtsystem, wodurch eine gute Wartungsperformance und Erweiterbarkeit erzielt wird. Den Hauptnutzen von Componentware zieht der Anwender aus der markanten Verkürzung der Entwicklungszeit. Componentware befreit ihn weitgehend von Implementierungsfragen.12 Der Programmierer wird von Routineaufgaben entlastet.13
Im Zuge des Wettbewerbsdrucks wird es den Unternehmen mittels Kompo-nententechnik ermöglicht, schnell auf neue Herausforderungen zu reagieren, da die bestehenden Komponenten im Bedarfsfall Teil neuer Anwendungen werden können. Ein bestehendes System kann Schritt für Schritt erweitert werden, ohne das Unternehmen mit einer umfassenden Systemeinführung zu belasten.14
Weitere wesentliche Vorteile einer komponentenorientierten Softwarestrategie liegen in einem besseren Informationsfluß, einer Produktivitätssteigerung, Qualitätssicherung, einer besseren Koordination und Arbeitsverteilung sowie einer Reduzierung der Durchlaufzeiten.15 Wichtig bei der Betrachtung der Vorteile von Componentware ist auch die Tatsache, daß es durch Schaffung von Standards und Schnittstellen möglich ist, Komponenten von verschiedenen Herstellern miteinander zu kombinieren, wodurch die Anforderungen jedes einzelnen Unternehmensbereichs optimal erfüllt werden können.
Ein wichtiger Vorteil, der im Kontext dieses Referatsthemas näher zu betrachten sein wird, ist der Vorteil eines sukzessiven Releasewechsels, der nicht mehr unternehmensweit mit großem Implementierungs- und Schulungsaufwand durchgeführt werden muß, sondern je nach Bedarf für die einzelnen Komponenten vorgenommen werden kann.
3.4. Problematik beim Einsatz von Komponententechnik
Natürlich birgt der Einsatz von komponentenbasierten Softwaresystemen nicht nur Vorteile, sondern auch einige Risiken für den Anwender.
Hierbei ist hervorzuheben, daß sich die Verwaltung der Schnittstellen zwischen einzelnen Komponenten als sehr anspruchsvoll gestalten kann.
Der Einsatz unterschiedlichster Business Objects, sowie der breit gefächerte betriebswirtschaftliche Hintergrund, erfordern unter Umständen einen hohen Koordinationsaufwand.
Ein weiterer kritischer Punkt bei der Betrachtung von Komponententechnik ist die Tatsache, daß langfristig gesehen zwar eine enorme Kostenreduzierung durch die oben aufgeführten Vorteile zu erzielen ist. Zunächst fallen jedoch bei der Entwicklung und Implementierung einer komponentenbasierten Strategie unter anderem durch die Schaffung des notwendigen Frameworks hohe Kosten an. Einen nicht zu unterschätzenden Kostenfaktor während der gesamten Einsatz-dauer von Componentware stellen die Kosten für die Bereiche Projekt- dokumentation und -koordination dar.16
Fraglich ist ebenso, ob ohne großen Aufwand ein reibungsloses Zusammenspiel zwischen den einzelnen Komponenten gewährleistet werden kann. Diese Frage stellt sich im besonderen, wenn es sich um Komponenten unterschiedlicher Hersteller oder andere externe Systeme handelt.
Zwar wird dem Anwender eine enorme Komplexitätsreduktion versprochen, ob die Überschaubarkeit und Benutzbarkeit jedoch jederzeit garantiert ist, bleibt offen.
Trotz aller Kritik bin ich überzeugt, daß die Komponententechnik zu recht als neue Standardstrategie im Bereich der Softwarearchitektur gilt, da die eben erläuterten Problemfelder in vielen Fällen rasch durch tiefgreifende Vorteile kompensiert werden können.
4. Komponententechnik am Beispiel SAP
Nachdem im Verlauf dieser Ausarbeitung die Architektur, die Anforderungen an und die Vorteile von Komponententechnik dargestellt worden sind, wird in diesem zentralen Kapitel das R/3-System des Walldorfer Softwareherstellers SAP AG auf seine Eigenschaften als komponentenbasierte Standardsoftware untersucht.
Als zentrales Element in der Komponenten-Strategie der SAP findet man das sogenannte Business Framework, das laut SAP ,,das Ergebnis langjähriger An-strengungen, die durch Kundenanforderungen vorangetrieben wurden," ist.17
Die nachfolgende Abbildung zeigt die Entstehung und Weiterentwicklung des Business Framework, beginnend bei Release 2.2 bis hin zu Release 4.0.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 - Evolution des Business Framework
Es kann festgestellt werden, daß SAP überhaupt erst mit dem Release 4.0 begonnen hat, ihren Kunde eine den Anforderungen entsprechende Kompo-nententechnik für das R/3-System zu entwickeln.
Im folgenden soll in stark gestraffter Form die Entwicklung des R/3-Systems von einer umfassenden Komplettlösung hin zu einer objektorientierten Component-ware aufgezeigt werden.
5. Der technologische Wandel des Systems SAP R/3
R/3 Release 2.2 und davor
Das Release 2.2 war als völlig eigenständige, logische und physikalische Systemeinheit zu betrachten. Interne Kommunikation zwischen Schnittstellen wurde über die Technologie RFC (Remote Function Call) realisiert, die noch heute als Transporttechnologie für Nachrichten zwischen R/3-Systemen sowie R/3-Systemen und externen Komponenten verwendet wird.18
R/3 im Jahre 1995
Das Release 3.0 stellte für die SAP einen wichtigen Durchbruch in der Unter-stützung verteilter, kundendefinierter und flexibler Geschäftsprozesse dar.19 Mit der Einführung von ALE (Application Link Enabling) gelang es dem Her-steller, die Kommunikation zwischen R/3-System und externen Komponenten, sowie die Synchronisation von physisch getrennten R/3-Systemen zu ermöglichen. Mit Hilfe des ALE wurde für das R/3-System eine gewisse Dezentralisierung erreicht und über geschaffene Schnittstellen (API - Application Programming Interface) eine Verbindung sogar zwischen R/2- und R/3-Systemen hergestellt. Ein weiterer Schritt im Richtung zur heutigen Komponententechnik war die Möglichkeit, daß selbst R/3-Systeme mit unter-schiedlichen Releaseständen miteinander kommunizieren konnten.
Mit dieser neuen, objektorientierten Schnittstellentechnologie wurden gleich-zeitig die SAP Business Objects eingeführt, die dem Anwender vor ihrem je-weiligen betriebswirtschaftlichen Hintergrund eine hohe Flexibilität im Bezug auf die Verarbeitung seiner relevanten Gechäftsprozesse versprachen.
Diese Schaffung der Business Objects innerhalb des Business Frameworks stellte einen wichtigen Meilenstein für die Entwicklung von SAP R/3 zum markt-führenden System im Bereich Standardsoftware dar.
,,Die SAP Business-Objekte bieten eine starke Abstraktion der zugrundeliegen-den Daten, sowie deren Funktionalität und Rahmen- und Integritätsbedingungen. So eröffnet das Business-Objekt-Modell eine neue Kommunikationsmöglichkeit zwischen der Betriebswirtschaft und der Informationstechnologie."20
R/3 im Jahre 1996
Neben einer erhöhten Internetorientierung des Systems bedeutete die Einführung weiterer 100 Business-Schnittstellen (BAPI - Business Application Program-ming Interface) einen erneuten Schritt hin zur Komponententechnik. Durch die neu geschaffenen Schnittstellen ermöglichte es SAP seinen Kunden, eine Viel-zahl von externen Systemen in das System R/3 zu integrieren.
R/3 im Jahre 1997
,,Mit dem Release R/3 4.0 macht die komponentenorientierte Struktur des Systems einen gewaltigen Sprung nach vorn. Da die zugrundeliegenden Tech-nologien wie z.B. BAPI's und ALE zu diesem Zeitpunkt schon mehrere Jahre im Einsatz sein werden, wird das Augenmerk auf Anwendungskomponenten und deren Schnittstellen gerichtet sein."21
Im Zuge der Komponentisierung wurde durch das Abkoppeln des Moduls HR
(Personalwirtschaft) der erste Schritt für eine Aufsplittung der internen R/3-Technologie vollzogen. Die reibungslose Kommunikation wurde über BAPI's gewährleistet.
R/3 nach 1997
Wie mit dem Release 4.0 angekündigt, erfolgte eine immer stärkere Zerlegung des Systems in einzelne, unabhängig voneinander zu betreibende Komponenten. Weitere Module, z.B. FI (Finanzen) und LO (Logistik) wurden vom eigentlichen Kernsystem gelöst und durch Schnittstellen integriert.
R/3 heute
Durch die Entwicklung des R/3-Systems zu einer Familie integrierter Kompo-nenten mit Hilfe des Business Framework, ist SAP in der Lage, neue, wichtige Funktionen mit Anwendungs- und Internetkomponenten anzubieten; jede hat ihren eigenen, vom System R/3 unabhängigen Release-Zyklus.22 Durch ein komponentenweises Vorgehen besteht die Möglichkeit einer Komplexitäts-reduktion bei früher aufwendigen Release-Wechsel. Die mittlerweile über 1000 Schnittstellen eröffnen weitreichende Möglichkeiten einer objektorientieren Kommunikation und tragen maßgeblich zur Verwirk-lichung einen komponentenbasierten Strategie bei.
6 Kritische Betrachtung des aktuellen SAP R/3-System
Wenn man den Ausführungen und Versprechen des Hersteller Glauben schenken kann, handelt es sich beim heutigen R/3-System mit dem aktuellen Releasestand 4.5 um eine völlig komponentenbasierte Standardsoftware.
Anhand der in Abschnitt 3.2. dargestellten Anforderungen soll im folgenden Verlauf überprüft werden, ob man die Architektur des aktuellen SAP R/3 in allen Beziehungen als Komponententechnik bezeichnen
Im Verlauf dieses Abschnitts wird mittels der unter 3.2. dargestellten Anfor-derungen untersucht, ob die Architektur des aktuellen R/3-Systems wirklich als Komponententechnik zu klassifizieren ist.
Die zentrale Anforderung der Wiederverwendbarkeit einer Komponente wird innerhalb des SAP R/3-Systems erfüllt. Betrachtet man die Definition des Be-griffs Wiederverwendbarkeit, so kann festgestellt werden, daß die einzelnen Bausteine des R/3-Systems (genauer gesagt: die Module) entsprechend der be-trieblichen Anforderungen einer Unternehmung weiter verwendet werden können, wenn andere Module ersetzt, ergänzt oder geändert werden. Dafür sorgt die umfassend angelegte Schnittstellenstrategie der SAP durch die Einhaltung strenger Standards wie ActiveX oder COM/DCOM.
Auch die geforderte Integration des betriebswirtschaftlichen Hintergrunds läßt sich durch den weitreichenden Business Framework und die darin enthalten Business Objects realisieren. ,,Seit Release 3.0 enthält das System R/3 über 170 verschiedene SAP Business-Objekte, die im Business Object Repository (BOS) dokumentiert sind. SAP Business-Objekte bieten stabile Schnittstellen für eine breite Palette stringent durchdachter Prozesse und Daten, auf die über das Business Object Repository zugegriffen werden kann."23
Das Customizing gestaltet sich bei den Komponenten des R/3-Systems nicht völlig problemlos, trotzdem lassen sich mit Hilfe der breiten Produktpalette und einzelnen SAP Initiativen (SAP SCOPE, SAP Business Intelligence Lösungen oder SAP Supply Chain Management) sämtliche Unternehmensstrukturen und Geschäftsprozesse ohne individuelle Programmierung von Software umsetzen.
Die notwendige Erweiterbarkeit sehe ich beim SAP R/3-System als gegeben an, denn dank der, den Marktanforderungen folgend neu entwickelten Programme, bietet das Walldorfer Softwareunternehmen seinen Kunden eine hohen Investitionsschutz und eine Zukunftssicherheit der eingesetzten Komponenten.
Die sukzessive Erweiterung des Systems sowie die Updates einzelner Komponenten können ohne Offline-Betrieb des Gesamtsystems vorgenommen werden, die Anwender müssen nicht permanent in neuen Anwendungen geschult werden, die Entwicklungs- und Implementierungskosten sind zwar nicht zu ver-nachlässigen, aber ein schneller Return on Investment ist garantiert.
Der streng umgesetzte betriebswirtschaftliche Rahmen unterliegt keinem an-nähernd so schnellen Wandel wie ein rein technologisch basiertes System. An diesem Punkt setzen die SAP Business-Objects an, die einem langen Lebens-zyklus unterworfen sind.
Natürlich muß in einer kritischen Betrachtung bzw. Überprüfung auch auf die Nachteile bzw. Schwierigkeiten der Komponentenarchitektur des R/3-Systems eingegangen werden.
Zwar bietet SAP mit seiner Vielzahl von Schnittstellen ein geeignetes Mittel zur Anbindung externer Systeme, doch die Praxis hat gezeigt, daß sich die Synchro-nisation oftmals als sehr schwierig, und nur durch hohe Programmierungskosten realisierbar, erweist. Es muß ebenfalls angemerkt werden, daß sich SAP die Auswahl vorbehält, welchen Systemen bzw. Produkten es den ,,Zugang" zu ihrem System ermöglicht und dies durch hohe Zertifizierungskosten erschwert.
Auch die Administration eines produktiven R/3-Systems gestaltet sich durch die Vielzahl der Möglichkeiten des Einsatzes und der Kombination, sowie die mög-licherweise aufwendige Verwaltung der Schnittstellen weniger einfach, als es vom Hersteller in seinen Veröffentlichungen dargestellt wird.
7. Schlußbetrachtung und Fazit
Ohne Zweifel hat SAP mit ihrem System R/3 den entscheidenden Schritt in Richtung einer komponentenbasierten Softwarearchitektur vollzogen.
Die völlige Abkopplung der einzelnen Module, ihre komponentenweise Upgrade-Fähigkeit, sowie die Ergänzung des R/3-Systems durch diverse branchen- bzw. unternehmensspezifische Komponenten, bieten dem Anwender einen völlig umfassende betriebswirtschaftliche Lösung, die er, fein skalierbar, entsprechend seines Geschäftsumfeldes, zu einem Gesamtsystem zusammen-setzen kann.
Wichtig war auch die Öffnung des SAP R/3-Systems hinsichtlich der unter-schiedlichsten Fremdanwendungen durch die Einführung und Ausweitung der BAPI's, was in meinen Augen entscheidend zum weltweiten Erfolg von SAP beigetragen hat.
Nachteilig hierbei wirkt sich jedoch aus, daß zur Einführung des R/3-System zunächst das komplette Rahmenwerk eingeführt werden muß, bevor man zur Auswahl und zum Einsatz einzelner Komponenten übergehen kann.
Ist dieser Rahmen jedoch angelegt, ist der Anwender in der Lage, sämtliche Vorteile einer strategischen Komponententechnik abzuschöpfen. Als erfolg-versprechend empfinde ich hierbei vor allem die stark wirtschaftliche Aus-richtung der gesamten SAP-Produktpalette.
Die Einsicht von SAP, für ihre Standardsoftware einen komponententechnischen und objektorientierten Ansatz zu wählen, geschah meiner Meinung nach erst relativ spät, zumal Wettbewerber wie Baan schon deutlich früher den Versuch unternahmen, diesen Weg der Softwareentwicklung einzuschlagen.
Die Betrachtung dieser Ausarbeitung hat jedoch gezeigt, daß SAP maßgeblich dazu beitragen kann, die Komponententechnik zu einem neuen Standard im Bereich der Softwareentwicklung zu erklären.
Literaturverzeichnis
Griffel, Frank: Componentware, dpunkt-Verlag, 1998
SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996
URL: http://homepages.fh-giessen.de/~hg6804/studies/vmt/chapter5.html URL: http://www.componentware.de/vorteile.htm
URL: http://www.computerwoche.de/archiv/1996/10/C10GF06.SAU.html URL: http://www.de.ibm.com/go/kn/news/Francisco.htm URL: http://www.im-c.de/akademie/content1/1313/1313-1/scr1313-1.htm URL: http://www.o3sis.de/products/component.html
URL: http://www.pst.informatik.uni-muenchen.de/veranstaltungen/VortragK/pree.html URL: http://www.sap.com/germany/products/rel40/componen.htm URL: http://www.systemberatung.de/compware.htm URL: http://www.wib.ch/dlcompo.htm
URL: http://www.winfoline.de/ARIS-Modul/Uebung/html/lsg-23-2.htm
[...]
1 URL: http://www.de.ibm.com/go/kn/news/Francisco.htm
2 URL: http://www.computerwoche.de/archiv/1996/10/C10GF06.SAU.html
3 URL: http://www.im-c.de/akademie/content1/1313/1313-1/scr1313-1.htm
4 URL: http://www.im-c.de/akademie/content1/1313/1313-1/scr1313-1.htm
5 URL: http://www.wib.ch/dlcompo.htm
6 Griffel, Frank: Componentware, dpunkt-Verlag, 1998
7 URL: http://www.pst.informatik.uni-muenchen.de/veranstaltungen/VortragK/pree.html
8 URL: http://www.wib.ch/dlcompo.htm
9 URL: http://www.wib.ch/dlcompo.htm
10 URL: http://www.winfoline.de/ARIS-Modul/Uebung/html/lsg-23-2.htm
11 URL: http://www.componentware.de/vorteile.htm
12 URL: http://www.wib.ch/dlcompo.htm
13 URL: http://www.o3sis.de/products/component.html
14 URL: http://www.im-c.de/akademie/content1/1313/1313-1/scr1313-1.htm
15 URL: http://www.systemberatung.de/compware.htm
16 URL: http://homepages.fh-giessen.de/~hg6804/studies/vmt/chapter5.html
17 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 5
18 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 6
19 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 7
20 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 8
21 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 12
22 URL: http://www.sap.com/germany/products/rel40/componen.htm
23 SAP: System R/3 - Das Business Framework, White Paper, Oktober 1996, S. 17
- Citation du texte
- Stefan Seibel (Auteur), 1999, Komponententechnik am Beispiel SAP, Munich, GRIN Verlag, https://www.grin.com/document/96289
Textes similaires
Devenir un auteur
Commentaires