Diplomarbeit - Fachbereich Informatik · Tab. 5 – Beispiel KPI ... SAP HR SAP Human Resources SAP ITS SAP Internet Transaction Servers ... SDM Software Delivery Manager

UNIVERSITÄT HAMBURG FAKULTÄT FÜR MATHEMATIK, INFORMATIK & NATURWISSENSCHAFTEN DEPARTMENT INFORMATIK ARBEITSBEREICH SOFTWARETECHNIK

Diplomarbeit

Volker Ritzau

Technischer und betriebswirtschaftlicher Vergleich des ABAP- und JAVA-Stacks von SAP NetWeaver zur Unterstützung bei der Technologieauswahl in

mittelständischen Unternehmen

Erstbetreuer: Dr. Guido Gryzcan Zweitbetreuer: Prof. Dr. Manfred Sommer

Abgabe: 17.05.2008

Kontaktdaten: Volker Ritzau Diplomstudiengang Wirtschaftsinformatik Matr.-Nr. 5401902 Tarpenbekstraße 66 20251 Hamburg [email protected] Telefon: 040 41303317 Mobil: 0172 4597397 Hamburg, 17.05.2008

Diplomarbeit Volker Ritzau Inhaltsverzeichnis Seite I

Inhaltsverzeichnis Inhaltsverzeichnis ...................................................................................................... I

Abbildungsverzeichnis ........................................................................................... IV

Tabellenverzeichnis ................................................................................................. V

Abkürzungsverzeichnis .......................................................................................... VI

1 Einleitung...........................................................................................................1

1.1 Motivation 2

1.2 Zielsetzung 3

1.3 Gang der Untersuchung 3

1.4 Intendierter Leserkreis 4

2 SAP NetWeaver(TM) Integrations- und Applikationsplattform ........................6

2.1 SAP-Technologieplattform (SAP Basis) 6

2.2 SAP NetWeaver-Komponenten 8

2.2.1 People Integration 8

2.2.2 Information Integration 9

2.2.3 Process Integration 9

2.2.4 Application Platform 9

2.2.5 Weitere Komponenten 10

2.3 SAP Web Application Server 11

2.3.1 Funktionale Architektur des SAP Web Application Servers 11

2.3.2 Internet Communication Manager 13

2.3.3 SAP Konnektoren 14

2.3.4 Systemlandschaft des SAP WAS 16

2.3.5 ABAP-Stack 16

2.3.6 JAVA-Stack 19

2.4 Vergleich der Technologiestacks 21

2.5 Zusammenfassung der Ergebnisse 25

3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs.................26

3.1 Bewertungskriterien und Kennzahlen 27

3.1.1 Klassische Qualitätskriterien von Software 27

Diplomarbeit Volker Ritzau Inhaltsverzeichnis Seite II

3.1.2 Bewertungskriterien für IT-Architekturen 29

3.1.3 Kennzahlen in der IT 31

3.1.4 Kriterien zur Bewertung der Technologiestacks 34

3.2 Auswertungs- und Bewertungsverfahren 37

3.2.1 Wirtschaftlichkeitsanalyse 37

3.2.2 Auswahl des Bewertungsverfahren 40


4 Vergleichende softwaretechnische Implementierung..................................42

4.1 Präsentationsschicht 42

4.1.1 Beschreibung 43

4.1.2 Programmierung und Ergebnisse 45

4.1.3 Auswertung 49

4.2 Persistenzschicht (ABAP-Schema) 50

4.2.1 Beschreibung 51

4.2.2 Programmierung und Ergebnisse 55

4.2.3 Auswertung 58


5 Aufstellung und Anwendung des Kriterienkatalogs ....................................62

5.1 Vorstellung der Projektsituation 62

5.2 Aufstellung des Kriterienkatalogs 64

5.2.1 Entscheidungsalternativen 64

5.2.2 Merkmalsübersicht 65

5.2.3 Bewertung der Entscheidungen 67

5.2.4 Auswertung & Technologieempfehlung 69

5.3 Kritik an der Anwendung des Kriterienkatalogs 70


6 Fazit und Ausblick...........................................................................................72

6.1 Zusammenfassung der geleisteten Arbeit 72

6.2 Offene Punkte 74

6.3 Erweiterung des Katalogs auf Anwendbarkeit im Nicht-SAP-Bereich 74

(A) Anhang Nutzwertanalyse .............................................................................77

(B) Anhang Quelltexte........................................................................................78

Diplomarbeit Volker Ritzau Inhaltsverzeichnis Seite III

(1) ZSQL 78

(2) ZBAPI_WRAPPER_SQLFLIGHT 79

(3) BSP ZBAPI_TEST 80

(4) SQLTest 81

(5) EnterpriseConnect 84

(6) Lokale Schnittstelle BAPI_SALESORDER_CREATEFROMDAT2 87

Literaturverzeichnis ................................................................................................88

Erklärung..................................................................................................................93

Diplomarbeit Volker Ritzau Abbildungsverzeichnis Seite IV

Abbildungsverzeichnis

Abb. 1 – “SAP NetWeaver Fridge” [KTD, S. 24] ................................................................................8

Abb. 2 – Applikationsserver Evolution bei SAP [SAP04, S. 11] ........................................................11

Abb. 3 – Architektur des SAP WAS [nach HR04, S. 33 & 46] ..........................................................12

Abb. 4 – SAP JCo-Architektur [vgl. SAP08i]....................................................................................15

Abb. 5 – Hierarchie der SAP-Berechtigungen ...................................................................................18

Abb. 6 – Entwicklungsprozess unter Einbeziehung aller Komponenten der JDI [KTD05, S. 45] ........20

Abb. 7 – Integration von JAVA und ABAP [nach HR04, S. 80] ........................................................24

Abb. 8 – Nutzenwert (vereinfacht) ....................................................................................................39

Abb. 9 – Beispiel HTMLB-Baumstruktur..........................................................................................43

Abb. 10 – BAPI-Explorer..................................................................................................................44

Abb. 11 – Layoutbereich des SAP-Geschäftsobjekts Produktkatalog .................................................44

Abb. 12 – BSP-Request „Treeclick“..................................................................................................46

Abb. 13 – GWT-Request „Treeclick" ................................................................................................46

Abb. 14 – Beispiel GWT-Baumstruktur ............................................................................................47

Abb. 15 – com.c1ips.gwtcatalog Paketstruktur ..................................................................................48

Abb. 16 – GwtbaseEAR Enterprise Application Project ....................................................................48

Abb. 17 – Ausgabe ZSQL.................................................................................................................51

Abb. 18 – Laufzeitanalyse ZSQL ......................................................................................................52

Abb. 19 – Test RFC-Funktionsbaustein ZBAPI_WRAPPER_SQLSFLIGHT ....................................52

Abb. 20 – Beispiel BSP-Benchmark..................................................................................................53

Abb. 21– Zusammenhänge des J2EE-Toolsets ..................................................................................54

Abb. 22 – Enterprise Connector - Select RFC Module.......................................................................57

Diplomarbeit Volker Ritzau Tabellenverzeichnis Seite V

Tabellenverzeichnis Tab. 1 – SAP WAS "wichtigste" Bestandteile ...................................................................................11

Tab. 2 – Exemplarische Requestverarbeitung und technische Architektur des SAP WAS [HR04, S. 43]

.................................................................................................................................................13

Tab. 3 – Vom SAP WAS unterstützte J2EE-Standards ......................................................................19

Tab. 4 – Gegenüberstellung der technischen Merkmale der Technologiestacks..................................22

Tab. 5 – Beispiel KPI - Produktivitätsindex.......................................................................................33

Tab. 6 – Auswahl der klassischen Qualitätskriterien für Software......................................................34

Tab. 7 – Auswahl der Bewertungskriterien für IT-Architekturen .......................................................34

Tab. 8 – Ausgewählte Kennzahlen für den Kriterienkatalog ..............................................................36

Tab. 9 – Risikotest (Auszug) [Kü05, S. 304] .....................................................................................38

Tab. 10 – Standard Ordnerstrukturen eines GWT-Projekts ................................................................45

Tab. 11 – Vergleichsobjekte für den Persistenzzugriff .......................................................................51

Tab. 12 – BSP-Benchmarks ..............................................................................................................53

Tab. 13 – JCo-Verbindungsparameter ...............................................................................................55

Tab. 14 – Laufzeitverhalten mit JCo.Client.Function.........................................................................56

Tab. 15 – Aufstellung der generierten Klassen des SAP Enterprise Connectors .................................57

Tab. 16 – Laufzeitverhalten mit SAP Enterprise Connector ...............................................................58

Tab. 17 – Gegenüberstellung der RFC-Laufzeiten .............................................................................59

Tab. 18 – Entscheidungsalternativen Technologieeinsatz...................................................................65

Tab. 19 – Übersicht ausgewählter Merkmmale..................................................................................66

Tab. 20 – Bewertungshierarchie ........................................................................................................68

Tab. 21 – Bewertungsmatrix .............................................................................................................69

Tab. 22 – Nutzenwert der Entscheidungsalternativen.........................................................................69

Diplomarbeit Volker Ritzau Abkürzungsverzeichnis Seite VI

Abkürzungsverzeichnis Abkürzung Erklärung 3Tier 3-Tier-Architektur ABAP Advanced Business Application Programming – SAP-spezifische

Programmiersprache ABAP VM ABAP Virtual Machine ABAP/4 ABAP - Programmiersprache der 4. Generation ABAP-OO ABAP - Objektorientiert ABAP-Stack ABAP Technologiestack ABAP Workbench ABAP Development Workbench – SAPs integrierte ABAP

Entwicklungsumgebung AJAX Asynchronous JavaScript and XML ALE Application Link Enabling – SAP spezifischer Integrationsdienst ALV-Grid Advanced List Viewer-Grid – SAP-spezifische Ausgabeart für

Listen und Tabellen AS Application Server BAPI Business Application Programming Interface BC-SERV Basis Component Server BO Business Object BOB Berechtigungsobjekt BOR Business Object Repository BSP Business Server Page CMS Change Management System CPU Central Processing Unit CSS Cascading Style Sheets DDIC Data Dictionary DMS Dokumentenmanagementsystem DTR Design Time Repository E-Commerce Electronic Commerce ERP Enterprise Resource Planning FLOBS Flex over BSPs GUI Graphical User Interface GWT Google Web Toolkit HTML Hypertext Markup Language HTMLB HTML Business – SAP-spezifische HTML-Erweiterung HTTP Hypertext Transfer Protocol HTTPS HyperText Transfer Protocol Secure ICF Internet Communication Framework ICM Internet Communication Manager IDE Integrated Development Environment IDocs Intermediate Document ISC Internet-Server-Cache IT Informationstechnologie

Diplomarbeit Volker Ritzau Abkürzungsverzeichnis Seite VII Abkürzung Erklärung IT BSC IT Balanced Scorecard ITIL IT Infrastructure Library IViews Integrated Views – eingebettete Seiten, z.B. im SAP Enterprise

Portal J2EE Java 2 Platform Enterprise Edition Standard JAVA VM JAVA Virtual Machine JAVA-Stack JAVA Technologiestack JEE5 Java Plattform Enterprise Edition 5 JNI Java Native Interface KPI Key Performance Indicator MaxDB Datenbankserver von SAP MT Manntage mySAP technology SAP Produktname mySAP.com SAP Produktname NPV Net Price Value NWA Nutzwertanalyse PC Personal Computer PDA Personal Digital Assistant P-System Produktivsystem Q-System System zur Qualitätssicherung RCO Real Cost of Ownership RPC Remote Procedure Call RFC Remote Function Call – proprietäre SAP-Standardschnittstelle zur

Realisierung systemübergreifender Kommunikation ROI Return on Investment SAP AS SAP Applikationsserver SAP Basis SAP Basisplattform SAP BI SAP Business Intelligence SAP CAF SAP Composite Application Framework SAP CRM SAP Customer Relationship Management SAP ECC SAP ERP Central Component SAP EP SAP NetWeaver Enterprise Portal SAP ERP SAP Enterprise Resource Planning SAP HR SAP Human Resources SAP ITS SAP Internet Transaction Servers SAP JCo SAP Java Connector SAP JDI SAP Java Development Infrastructure SAP JRA SAP Java Resource Adapter SAP Kernel SAP Systemkern SAP LDAP Connector SAP Leightweight Directory Access Protocol Connector SAP NetWeaver SAP NetWeaver Applikations- und Integrationsplattform SAP NWDS SAP NetWeaver Developer Studio SAP PI SAP Process Integration SAP R/3 SAP ERP-System – „R“ steht dabei für realtime („Echtzeit“) und

die „3“ steht für die 3-Tier-Architektur

Diplomarbeit Volker Ritzau Abkürzungsverzeichnis Seite VIII Abkürzung Erklärung SAP SCM SAP Supply Chain Management SAP SM SAP Solution Manager SAP WAS SAP Web Application Server SAP xApps SAP Cross Applications SAP XI SAP Exchange Infrastructure SDM Software Delivery Manager SDN Software Developer Forum SMTP Simple Mail Transfer Protocol SOA Serviceorientierte Architekturen SOAP Simple Object Access Protocol SQL Structured Query Language TCO Total Cost of Ownership TCP/IP Transmission Control Protocol/Internet Protocol TEI Total Economic Impact T-System Entwicklungs- und Testsystem TVO Total Value of Ownership UI User Interface WD4A WebDynpro for ABAP WDA WebDynpro Anwendungen WDJ WebDynpro Java WWW World-Wide-Web WYSIWYG What You See Is What You Get XHTMLB Extensible HTMLB XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformation

Diplomarbeit Volker Ritzau Kapitel 1 Einleitung Seite 1

1 Einleitung Die SAP AG stellte als eine der ersten Softwareentwicklungsfirmen für Unternehmens-Informationssysteme ihre Systemarchitektur der Systemlandschaft für IT-unterstützende Geschäftsprozesse (SAP R/3) auf eine - mittlerweile als „Quasi-Standard“ anzusehende - 3-Schichten-Systemarchitektur um. Diese ist für einen Betrieb auf Client/Server-Basis konzipiert und geprägt durch die Aufteilung in die drei Schichten (auch allgemein 3Tier-Architektur), bestehend aus Datenbanktier, Applikationsservertier und Frontendtier. [vgl. SAP08a; DFH03, S. 276ff.]. Mit dieser Umstellung wurde die Akzeptanz und Verbreitung der 3Tier-Architektur in IT-Geschäftsanwendungen – gerade im Enterprise Resource Planning (ERP)-Systemumfeld – angestoßen [vgl. SAP08a; KTB05, S.14]. Die Architektur der SAP Basisplattform (SAP Basis) ist gekennzeichnet durch drei Merkmale gekennzeichnet: Die alleinige Unterstützung der plattformneutralen, aber proprietären SAP-Applikationsplattform, der Optimierung der Laufzeitumgebung auf eine hohe Skalierbarkeit von Geschäftsanwendungen und die Integration der Entwicklungsumgebung in den SAP Applikationsserver (SAP AS). Deutlich zeigt sich die durchgängige „SAP ist eine eigene Welt“-Philosophie an der vollständigen Implementierung des Applikationsservers durch die SAP-eigene Programmiersprache Advanced Business Application Programming (ABAP) (bzw. ABAP-Objektorientiert (ABAP-OO)) und die Geschlossenheit durch die monolithischen Systeme wie SAP Enterprise Resource Planning (SAP ERP), SAP Supply Chain Management (SAP SCM), SAP Customer Relationship Management (SAP CRM) und andere. Mit Verbreitung und Wachstum des World-Wide-Web (WWW) und dem damit einhergehenden Erfolg der Programmiersprache JAVA, wurde auch bei SAP die proprietäre und monolithische Systemlandschaft weiter geöffnet. Dies wurde im ersten Schritt durch die Öffnung für Webanwendungen durch eine wiederum auf ABAP basierende Entwicklung und Implementierung des SAP Internet Transaction Servers (SAP ITS) durchgeführt. Dieser machte es möglich, über Standard Internetprotokolle (wie z. B. Hypertext Transfer Protocol (HTTP)) mit verschiedenen SAP-Systemen zu kommunizieren und Webanwendungen zu entwickeln, hatte aber noch keinen integrativ-offenen Ansatz. Im zweiten Schritt, wurde der Applikationsserver erweitert und reimplementiert, so dass es jetzt als vollwertiger Web Server benutzt werden konnte. Der so genannte SAP Web Application Server (SAP WAS) unterstützt ab Release 6.20 den kompletten Java 2 Enterprise Edition Standard (J2EE), seit neuestem mit SAP NetWeaver 7.1 den Java Enterprise Edition 5 Standard (JEE5), und bietet somit die Möglichkeit Java-Applikationen zu entwickeln, zu kompilieren und zu hosten. Die Öffnung der proprietären, auf ABAP beruhenden SAP-Entwicklungslandschaft, war somit der dritte Schritt, um die SAP-Systemlandschaft konkurrenzfähig und zukunftssicher für die Durchdringung der IT-Geschäftsprozesse durch Internettechnologien und die Chancen und Herausforderungen des Electronic Commerce (E-Commerce) zu machen. Diese Öffnung führt

Diplomarbeit Volker Ritzau Kapitel 1 Einleitung Seite 2 allerdings auch zu einem nebeneinander zweier teils stark unterschiedlicher Entwicklungsumgebungen, dem ABAP Technologiestack (ABAP-Stack) und dem JAVA Technologiestack (JAVA-Stack). Die weitergehende Entwicklung der Serviceorientierten Architekturen (SOA) und die Umsetzung dieses Konzepts durch SAP in Form des Produktes SAP NetWeaver, führte dazu, dass der SAP WAS Basis jedes SAP-Systems (SAP ERP, SAP CRM, SAP SCM; ab dem jeweiligen Releasestand) ist. Durch diese große Verbreitung des SAP WAS hat jeder Kunde eine große Auswahl an Technologien zur Umsetzung seiner Ideen und damit auch für viele Projekte die Qual der „Auswahl“, welches Produkt oder welche Technologie die beste zur Umsetzung seiner Anforderungen ist. Die SAP AG hat im Laufe der letzten Jahre und der weitergehenden Entwicklung des SAP WAS ihr Produktportfolio mehrfach umstrukturiert, umgruppiert und umbenannt. So wird im ERP-Systemumfeld von SAP R/3, SAP ERP und mittlerweile SAP ERP Central Component (SAP ECC) gesprochen und im Bereich der SAP-Internettechnologien reicht die Namensgebung über den SAP ITS, SAP WAS, mySAP.com, mySAP technology bis zu der SAP NetWeaver Applikations- und Integrationsplattform (SAP NetWeaver). Eine genauere Betrachtung von SAP NetWeaver und eine Definition und Vorstellung der benötigten SAP-Begrifflichkeiten und SAP NetWeaver-Komponenten wird in Kapitel 2 vorgenommen, ebenso eine Abgrenzung der letztendlich zu betrachtenden und zu bewertenden SAP NetWeaver-Komponenten.

1.1 Motivation Durch die Arbeit bei einem SAP-Systemhaus, dessen Kundenkreis zum großen Teil aus dem industriellen Mittelstand kommt, wurde in verschiedenen webanwendungsbezogenen Projektsituationen auf Basis der SAP-Technologien deutlich, dass beim Kunden große Unsicherheiten auftreten und die Lösung der Frage welche, Technologie verwendet werden soll, Projekte erschwert und verlängert. Es ist anzumerken, dass aufgrund des segmentierten Kundenkreises (industrieller Mittelstand mit vorhandener SAP-Systemlandschaft), sich die Entscheidung zumeist darauf beschränkt, mit welchen Mitteln, Produkten und Technologien der SAP AG eine Umsetzung der Kundenbedürfnisse realisiert werden kann. Fragen, die in diesem Zusammenhang auftreten, sind z.B.:

• Welcher Technologiestack bzw. welche Entwicklungsumgebung soll für Webanwendungen benutzt werden?

• Welche Konsequenzen für spätere Entwicklungen hat eine Entscheidung zwischen den beiden Technologiestacks?

• Welches sind die Schlüsselindikatoren unter denen eine Entscheidung zu treffen ist? • In wie weit ist die getroffene Entscheidung zukunftssicher?

Diplomarbeit Volker Ritzau Kapitel 1 Einleitung Seite 3

• Welche Ressourcen können weiter verwendet werden und in welche muss neu investiert werden?

• Was kostet die Auswahl einer bestimmten Technologie?

Erfahrene SAP-Berater und SAP-Entwickler sollten die jeweiligen Vor- und Nachteile der Entwicklung im Rahmen des JAVA- und bzw. oder des ABAP-Stacks der SAP NetWeaver Entwicklungsumgebung gut kennen und sich über die strategische Fragestellungen und Entscheidungen bewusst sein. Aus diesem Zusammenhang entstand die Notwendigkeit einen Kriterienkatalog aufzustellen, mit dem eine unkomplizierte, anpassbare und damit individuelle Beurteilung und Bewertung von Kundensituationen (Projekten) mit anschließender Technologieempfehlung durchgeführt werden kann.

1.2 Zielsetzung Zielsetzung dieser Diplomarbeit ist es einen solchen Kriterienkatalog auf Grundlage von betriebswirtschaftlichen und softwaretechnischen Kriterien zu entwickeln, aufgrund derer solch eine Beurteilung und Bewertung von Kundensituationen durchgeführt werden kann. Das Ergebnis dieser Projektcharakteristik soll eine klare und differenzierte Technologieempfehlung sein, die vorher ausgesuchte und gewichtete Schlüsselindikatoren und Entscheidungsfaktoren berücksichtigt. Der Kriterienkatalog soll weiterhin durch die vorgenommenen Testimplementierungen in Kapitel 4 mit anschaulichen Beispielen und einfachen Tests untermauert werden. Die Anwendung des Katalogs ist auf Projektsituationen aus dem Kundenkreis des SAP-Beratungshauses begrenzt. Das bedeutet, wie eingangs erläutert, die Kunden kommen zum einen aus dem (zumeist industriellen) Mittelstand und zum anderen ist im Voraus schon einmal eine Entscheidung für die Nutzung des SAP-ERP-Systems getroffen worden. Aus so einer Entscheidung folgt oft die Konsequenz, dass die Betrachtung von Fremdprodukten – damit sind hier Nicht-SAP-Produkte gemeint – aus integrativen Aspekten, d.h. dem Aufbau und der Unterstützung einer einheitlichen IT-Infrastruktur, zweitrangig ist. Diesem das Betrachtungsfeld stark eingrenzenden Punkt wird im Fazit dieser Arbeit genüge getan. Es wird ein Ausblick darauf gegeben, welche Schritte und Faktoren notwendig sind, um eine Erweiterung des Kriterienkatalogs auf die Betrachtung von Nicht-SAP-Produkten durchzuführen.

1.3 Gang der Untersuchung Kapitel 1 gibt eine Einführung in die Thematik, beschreibt die Entstehung der Aufgabenstellung, die Motivation und die Zielsetzung dieser Arbeit.

Diplomarbeit Volker Ritzau Kapitel 1 Einleitung Seite 4 Kapitel 2 enthält eine nähere Beschreibung der SAP NetWeaver Integrations- und Applikationsplattform, der SAP-spezifischen Systemlandschaft und der zu beurteilenden Technologiestacks. Es führt die SAP-eigenen Begrifflichkeiten ein, die für das Verständnis der weiteren Untersuchung hilfreich sind. Es wird außerdem eine klare Abgrenzung vollzogen und begründet, welche SAP NetWeaver-Komponenten in die Untersuchung einbezogen werden. Der in den darauf folgenden Kapiteln benutzte Kriterienkatalog wird in Kapitel 3 erarbeitet. Dazu werden zuerst Bewertungskriterien für Software, IT-Systeme und IT-Architekturen, sowie Kennzahlen aus der IT vorgestellt. Aus diesen wird eine sinnvolle Auswahl für die Bewertung der SAP NetWeaver-Technologiestacks getroffen. Teilweise werden die Bewertungskriterien auf die erläuterte Fragestellung angepasst. Im zweiten Teil wird die Wirtschaftlichkeitsanalyse vorgestellt. Aus dieser werden Teilverfahren für die Anwendung im Kriterienkatalog ausgewählt. In Kapitel 4 werden auf Grundlage einiger der im dritten Kapitel entwickelten Bewertungskriterien einfache Implementierungen zur Bewertung und argumentativen Untermauerung durchgeführt. Diese vergleichenden Implementierungen sind zur Aufstellung und späteren Anwendung des Kriterienkatalogs notwendig und sinnvoll. Bestimmte Merkmale der Technologiestacks wären im Projektumfeld erst nach einer Umsetzung des Projektes bewertbar, die Aufgabe des Katalogs ist aber die Entscheidungshilfe zur Auswahl einer Technologie. Die vergleichenden Implementierungen sind angelehnt an die 3Tier-Architektur des SAP WAS. D.h. es wird zumindest zur Prüfung der Schnittstellen zur Applikationsschicht jeweils eine Testimplementierung eines ausgewählten Kriteriums des Kataloges vorgenommen. Das Vorgehen bei der Implementierung wird beschrieben und die Implementierungen vorgestellt. Die Ergebnisse werden dargestellt und auf besonders kritische Bereiche oder Unterschiede wird aufmerksam gemacht. In Kapitel 5 wird anhand einer konkreten Projektsituation aus dem Kundenumfeld des SAP-Beratungshauses ein auf den und mit dem Kunden angepasster Kriterienkatalog aufgestellt und eine Analyse zur Technologieauswahl durchgeführt. Anhand dieser wird eine nachfolgende Empfehlung und Strategie für den Kunden beschrieben und ausgewertet. Die konkrete Anwendung des Katalogs wird ebenfalls kritisch betrachtet. Kapitel 6 zieht ein Resümee über die durchgeführte Arbeit, und zeigt einen Ausblick welche Punkte offen geblieben sind. Es werden Überlegungen dazu angestellt, in welcher Art und Weise der Katalog ergänzt werden kann, um auch Nicht-SAP-Produkte anhand dieser aufgestellten Kriterien mit in die Bewertung einzubeziehen.

1.4 Intendierter Leserkreis Das Ziel dieser Arbeit ist die Entwicklung eines Kriterienkatalogs zur Unterstützung bei der Entscheidungsfindung bei mittelständischen IT-Projekten, die Webanwendungen (Inter- oder Intranetanwendungen) auf der Grundlage der SAP ERP-Software und der SAP NetWeaver Integrations- und Applikationsplattform durchführen wollen.

Diplomarbeit Volker Ritzau Kapitel 1 Einleitung Seite 5 Von dem Leser wird ein grundlegendes Verständnis von IT-Systemen und IT-Anwendungen, sowie IT-Architektur erwartet, weil auf grundlegende Konzepte der Informatik nicht näher eingegangen wird. Explizit sollte ein Verständnis für die Funktionsweise von Webanwendungen gegeben sein, um die Unterschiede in den SAP-Technologieplattformen und der aufgeführten Beispiele einordnen zu können. Der intendierte Leserkreis ist aufgrund der speziellen Projektart somit im SAP-Umfeld zu finden: Berater und Entwickler, die sich mit den neueren Technologien von SAP auseinander setzen, sowie SAP-Kunden, die sich einen Überblick über die SAP-spezifischen Begrifflichkeiten und Möglichkeiten machen wollen und sich im Rahmen von IT-Projekten mit den verschiedenen Technologien beschäftigen. Allerdings bietet diese Arbeit auch für interessierte IT-Experten, die sich zuvor noch nicht mit den IT-Systemen, IT-Architekturen und Produkten von SAP auseinandergesetzt haben, die Möglichkeit, einen Einblick in die technologischen Grundlagen der SAP NetWeaver Integrations- und Applikationsplattform zu erhalten. Dabei hat die Arbeit nicht den Anspruch alle denkbaren Formen der Umsetzungsmöglichkeiten oder Lösungen von IT-Szenarios aufzuzeigen oder zu diskutieren, sondern beschränkt sich auf die Möglichkeiten der SAP-Technologiestacks.

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 6

2 SAP NetWeaver(TM) Integrations- und Applikations-plattform

„SAP NetWeaver ist die umfassende Integrations- und Anwendungsplattform der SAP.“ [vgl. HR05, S.19]. Dabei steht für SAP die „ganzheitliche Integration“ im Vordergrund, die sich aus der Zusammenführung von Menschen, Informationen und Geschäftsprozessen über alle Technologie- und Organisationsformen hinweg zusammensetzt [vgl. HR05, ebd.]. Im diesem Kapitel wird zuerst auf die Technologieplattform SAP Basis eingegangen, aus der der SAP WAS als Applikationsplattform gewachsen ist. Die SAP Basis in Form des SAP WAS bildet immer noch das Fundament von SAP NetWeaver und somit von allen Anwendungskomponenten, welche im nachfolgenden Kapitel beschrieben werden. Die Betrachtung der SAP Basis und der SAP-Systemarchitektur ist zum weitern Verständnis und zur späteren Abgrenzung der zu vergleichenden Bereiche sinnvoll. Im zweiten Teil dieses Kapitels, werden die wichtigsten Komponenten von SAP NetWeaver kurz vorgestellt, um auch hier im Weiteren die Abgrenzung und Auswahl der zu vergleichenden Komponenten vornehmen und begründen zu können. Als letztes wird der SAP WAS in seiner jetzigen Architektur und Funktionsweise betrachtet, sowie eine erste Gegenüberstellung der beiden Ausprägungen der Applikationsplattform vorgenommen.

2.1 SAP-Technologieplattform (SAP Basis) Die SAP AG stellt seit Anfang der Entwicklung ihres ERP Systems eine Technologieplattform zur Verfügung, im SAP-Sprachgebrauch kurz als SAP Basis bezeichnet. Diese hat im Laufe der Zeit einen umfangreichen Wandel vollzogen. Wie eingangs erwähnt stellte SAP als eines der ersten Unternehmen ihre Technologieplattform auf eine Client-/Server- und eine 3Tier-Architektur um. Die SAP Basis ist in der Integrations- und Applikationsplattform SAP NetWeaver aufgegangen und bildet dort als SAP WAS das Fundament für sämtliche SAP NetWeaver-Komponenten. Die SAP Basis hat als Technologieplattform die drei folgenden prägenden Architekturmerkmale: Plattformunabhängige und auf Geschäftsanwendungen optimierte Programmiersprache (ABAP) – ABAP wurde von SAP entwickelt. Sie ist für Geschäftsanwendungen optimiert. Diese Optimierung ist u.a. durch eine spezielle Technik des Zugriffs auf tabellenartige Objekte im Hauptspeicher und einen syntaktisch und semantisch in der Sprache eingebetteten Zugriff auf Datenbanktabellen über einen portablen SQL-Subset realisiert. Mit ABAP kann prozedural und seit 1989 objektorientiert programmiert werden (ABAP/4 oder ABAP-OO).

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 7 Integrierte Entwicklungsumgebung – Die Entwicklungsumgebung (ABAP Development Workbench (ABAP Workbench)) ist in die Basisplattform integriert. Über diese werden Datenbankstrukturen, Tabellen oder Integrated Views (IViews) im ABAP Dictionary definiert. Auf diesem werden weitergehende Strukturen und Datentypen definiert. Dies hat den Vorteil der aktiven Verwaltung aller Programmobjekte, was zur Folge hat, dass alle abhängigen Objekte bei Bedarf neu generiert werden. Angebot und Unterstützung zahlreicher Services und Frameworks – Durch den Einsatz von Frameworks werden eine normierte Bedienbarkeit und eine Performanceoptimierung erreicht. Nach Aussage von SAP steigt die Akzeptanz der Geschäftsanwendung, wenn gemeinsame Frameworksanwendungen übergreifend genutzt werden. Das Standard Framework von SAP ist das „Business Framework“. Hierunter versteht SAP die Konfiguration des Unternehmensgeschäftes. Das Framework hat im Wesentlichen die folgenden Bestandteile: Businesskomponenten, Businessobjekte (BO), Business Application Programming Interfaces (BAPIs) und den Integrationsdienst ALE (Application Link Enabling). Geschäftskomponenten setzen sich aus Geschäftsobjekten zusammen, z.B. die Komponente SAP Human Resources (SAP HR) aus BOs wie Mitarbeitern, Auftraggebern, Gehaltsabrechnungen und anderen. Die Geschäftskomponenten und -objekte können über BAPIs bearbeitet werden [vgl. De98, S.29-36]. Für die softwaretechnischen Vergleichstests in Kapitel 4 ist dabei zu wissen, dass aus historischer Sicht die Implementierung der BOs und damit auch deren Verarbeitung im ABAP-Stack durchgeführt werden. Sobald ein BAPI gerufen wird, findet die weitere Bearbeitung des Aufrufs im ABAP-Stack statt. ALE ist zur leichteren plattform- und firmenübergreifenden Interoperabilität von Applikationen und Systemen bzw. Geschäftsprozessen gedacht, wird im Laufe dieser Diplomarbeit aber keine weitere Rolle spielen [vgl. SAP08b]. Als weiteres Merkmal ist zu nennen, dass die SAP Basis von zugrunde liegender Hard- und Systemsoftware durch ein Transaktions- und Verbuchungskonzept abstrahiert [vgl. KTB05, S.13]. Die Portierung von SAP-Systemen ist auf den so genannten SAP Systemkern (SAP Kernel) beschränkt. Dieser hat aber für diese Arbeit keine weitere Bedeutung. Eine Unterstützung zahlreicher Plattformkombinationen ist möglich.


2.2 SAP NetWeaver-Komponenten SAP NetWeaver ist zum einen die technische Umsetzung und Implementierung einer Enterprise-SOA von SAP. Im SAP-Sprach-gebrauch wird auch von einer Enterprise Service Architecture (ESA) gesprochen. Eine ESA erweitert das Konzept von Web Services zu einer Architektur für Geschäfts-anwendungen. SAP versteht eine ESA als Werkzeug um das Design einer kompletten serviceorientierten Lösung für einen Geschäftsprozess durchzuführen [vgl. KTD05, S. 34 & 182; vgl. SAP08j]. Zum anderen wurden mit Einführung des Produktes SAP NetWeaver verschiedene ehemals eigenständige SAP-Produkte in einem integriert.

Die nebenstehende Grafik (Abb. 1) zeigt in Zentrum die vier Hauptebenen von SAP NetWeaver. Die drei oberen Ebenen bilden die Integrationsschicht, die unterste die Applikationsschicht. Die Ebenen der Integrationsschicht sind nicht hierarchisch aufgebaut. Sie sind unabhängig voneinander entstanden, wachsen aber im SAP NetWeaver-Konzept immer enger zusammen. Alle Ebenen haben die Applikationsschicht als Fundament. Die beiden Technologiestacks der Applikationsschicht sind der Hauptgegenstand der Betrachtungen dieser Arbeit. In den folgenden Unterkapiteln wird der Sinn und Zweck aller Komponenten kurz erläutert.

2.2.1 People Integration

Mit der Ebene der Anwenderintegration wird ein einheitlicher Zugriff auf verschiedene Systeme und Applikationen auf Frontendebene mit einem einheitlichen Benutzerinterface – per Webbrowser - gewährleistet [vgl. NKK07, S. 17ff.]. Durch diese Einbindung des Menschen in den Geschäftsprozess soll die Produktivität gesteigert werden [vgl. Ei07 et al. S. 407]. Dabei ist die Hauptkomponente das SAP NetWeaver Enterprise Portal (SAP EP). Über dieses haben Benutzer Zugang zu den Funktionen und Informationen, die sie individuell benötigen und für die sie über die ihnen zugeordnete Rolle die Berechtigung zum Lesen, Schreiben, Ausführen oder Verändern haben. Der Zugriff kann über beliebige Datenquellen stattfinden. Laut SAP bleibt der Administrationsaufwand der Benutzerrollen in einem

Abb. 1 – “SAP NetWeaver Fridge” [KTD, S. 24]

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 9 vernünftigen Verhältnis [vgl. HR05, S. 19] [vgl. KTD05, S. 25]. Das SAP EP bietet Möglichkeiten zur synchronen und asynchronen Zusammenarbeit in Teams und Gruppen. Auch die Darstellung und Bearbeitung von Geschäftsabläufen (Workflows) durch die Mitarbeiter kann mit dem SAP EP umgesetzt werden. Mit Multi-Channel-Access ist die Komponente SAP Mobile Infrastructure gemeint, mit der mobile Geräte wie Personal Digital Assistants (PDAs) oder mobile Anwendungen, online und offline, integriert werden.

2.2.2 Information Integration

Die Ebene der Informationsintegration konsolidiert strukturierte und unstrukturierte Informationen und macht diese einfach zugänglich [vgl. HR05, S.19]. In dieser Ebene wurde die SAP Business Intelligence (SAP BI) (vorher SAP Business Warehouse) in die SAP NetWeaver Architektur integriert. SAP BI ist das Datawarehouse und Managementinformationssystem von SAP. SAP BI Analysen und Reports sind u.a. voll über das SAP EP integriert. Das SAP Master Data Management stellt Services zur Konsolidierung, Harmonisierung und das zentrale Management von „Masterdaten“ (z.B. Produktdaten, Kundendaten) zur Verfügung, wobei es für Datenintegrität über alle Geschäftsprozesse sorgt.

2.2.3 Process Integration

Die Ebene der Prozessintegration soll nahtlose Geschäftsabläufe, die heterogene und Nicht-SAP-Systeme umspannen, ermöglichen [vgl. HR05, S.19]. Systemübergreifende Prozesse müssen vor Ablauf definiert werden und werden anschließend zur Ausführung gebracht, dafür werden entsprechende Werkzeuge und Ausführungsumgebungen benötigt. Dies wird in SAP NetWeaver durch die SAP Exchange Infrastructure (SAP XI) umgesetzt (seit kurzem auch SAP Process Integration (SAP PI)).

2.2.4 Application Platform

Die einheitliche und offene Applikationsplattform ist das Fundament aller vorher aufgezählten Ebenen. Sie bildet somit die komplette Infrastruktur, um zu entwickeln, zu betreiben und einzusetzen. Der SAP WAS ist laut SAP eine gut skalierbare und stabile Applikationsplattform. Er bietet die Möglichkeit mit ABAP und JAVA zu entwickeln und stellt jeweils eine integrierte Entwicklungsumgebung zur Verfügung. Der SAP WAS ist betriebssystem- und datenbankunabhängig. Er unterstützt offene Standards, wie die Standard Internet-Protokolle, und bietet die Möglichkeit Web Services zur Verfügung zu stellen. Durch die einheitliche Plattform für alle SAP-Lösungskonzepte, Kundenerweiterungen und Entwicklungen werden Installations- und Administrationskosten gesenkt.


2.2.5 Weitere Komponenten

Als weitere Komponenten von SAP NetWeaver sind zur Vollständigkeit das Life-Cycle-Management in Form des SAP Solution Mangers (SAP SM) und das Composite Application Framework (SAP CAF) zu erwähnen. Der SAP Solution Manager dient als Werkzeug zur Überwachung und Wartung von IT-Systemlandschaften. U.a. integriert er ein Service-Level-Reporting. Das SAP CAF bietet eine Entwicklungs- und Laufzeitumgebung zur Entwicklung von Composite Applications und SAP xApps, die Geschäftsprozesse über unterschiedliche Applikations-, System- und Organisationsebenen hinweg abbilden und eine flexible Integration neuer und alter funktionaler Bestandteile ermöglichen. Anzumerken ist, dass die SAP NetWeaver-Plattform verschiedene Sicherheitsstandards zur Authentifizierung und verschlüsselten Datenübertragung unterstützt.


2.3 SAP Web Application Server Der Applikationsserver ist die Kernkomponente der Betrachtung dieser Arbeit und der vergleichenden Implementierungen. Die Grafik (vgl. Abb. 1) zeigt die Entwicklung des SAP WAS über die verschiedenen Releasestände mit den wichtigsten Neuerungen. So ist z.B. die J2EE-Engine seit dem Releasestand 6.20 im Jahr 2002 integriert.

SAP gibt die in nebenstehender Tabelle (vgl. Tab. 1) aufgeführten Merkmale als „wichtigste Bestand-teile“ des SAP WAS an [vgl. HR05, S. 50]. Die für die weitere Betrachtung dieser Arbeit sich als wichtig herausstellenden Merkmale sind grau gekennzeichnet.

2.3.1 Funktionale Architektur des SAP Web Application Servers

Webbasierte Anwendungen werden wie bereits erwähnt in einer 3-Schichten Architektur entworfen: die Präsentations-, die Applikations- und die Datenbankschicht.

Abb. 2 – Applikationsserver Evolution bei SAP [SAP04, S. 11]

SAP WAS Bestandteile

Integriertes Datenbanksystem Skalierbare hoch

verfügbare SAP AS-Infrastruktur

J2EE-Integration

Integrierte Entwicklungsumgebung

Plattformunabhängigkeit Webserver

Softwarelogistik, Versionskontrolle

Vereinfachte Administration

Webservice Infrastruktur

Benutzerverwaltung, Berechtigungen

Internationalisierung

umfassende Konnektivität,

offene Internetstandards

Sicherheitsinfrastruktur Internet-Mail ITS-Integration

Tab. 1 – SAP WAS "wichtigste" Bestandteile

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 12 Die Präsentationsschicht liegt beim Client und stellt die Benutzerschnittstelle dar. Sie wird als Frontend bezeichnet. Die Datenbankschicht besteht aus einem oder mehreren Datenbank-servern, auf denen sämtliche Daten, die für die Anwendung benötigt werden, gespeichert werden. Die Datenbankschicht wird auch als Backend bezeichnet. In der Mitte liegt die Applikationsschicht, wo Applikationsserver die Verarbeitung und die Geschäftsfunktionalität übernehmen, Daten aus der Datenbankschicht beschaffen, verarbeiten und zurück schreiben und die angeforderten und evtl. aufbereiteten Daten der Präsentationsschicht zur Verfügung stellen. Die Applikationsschicht kann wiederum in weitere Schichten eingeteilt werden. Die folgende Grafik (vgl. Abb. 3) zeigt auf der linken Seite ein allgemeines Schema der Drei-Schichten-Architektur, auf der rechten Seite wird die Applikationsschicht anhand des speziellen funktionalen Aufbaus des SAP WAS dargestellt. Man kann erkennen, dass in der Präsentationsschicht, in der Businessschicht und der Persistenzschicht sämtliche Funktionalitäten in doppelter Ausprägung vorhanden sind. Diese werden für die Unterstützung der ABAP- (im Bild rosa gekennzeichnet) und der JAVA-Funktionalitäten (im Bild gelb gekennzeichnet) benötigt. Im weiteren Verlauf bezieht sich der Begriff JAVA-Stack auf die JAVA-Umgebung über alle Schichten, sowie der Begriff des ABAP-Stack auf alle Ausprägungen der ABAP-Umgebung. Ebenfalls aus der Grafik zu entnehmen ist, dass die Konnektivitätsschicht und die Integrationsschicht nicht speziell einem der Technologiestacks dienen, sondern mit ihren Funktionalitäten beiden zur Verfügung stehen.

Abb. 3 – Architektur des SAP WAS [nach HR04, S. 33 & 46]


2.3.2 Internet Communication Manager

Der Internet Communication Manager (ICM) ist die Schnittstelle des SAP WAS zum Internet, die die Kommunikation über das Transmission Control Protocol/Internet Protocol (TCP/IP) ermöglicht. Der ICM beinhaltet Plug-Ins, die die Kommunikation per HTTP, HTTP Secure (HTTPS) und Simple Mail Transfer Protocol (SMTP) benötigt. Der SAP WAS kann in der Serverrolle und in der Clientrolle auftreten. In der Serverrolle nimmt der ICM die Anfragen entgegen und „verteilt“ diese über die Dispatcher an die lokalen Ausführungseinheiten, die Workprozesse des ABAP-Stacks oder an die der J2EE-Engine. Eine exemplarische Reqestverarbeitung findet sich in folgender Tabelle (vgl. Tab. 2) Exemplarische Requestverarbeitung und technischen Architektur des SAP WAS 1. Der ICM erhält einen HTTP-Request (für Server und Port oder Standard) 2. ICM entscheidet, ob ABAP- oder JAVA-Stack gerufen werden müssen (hier: ABAP) 3. Der ICM legt die Daten in eine Memory Pipe und informiert den Dispatcher 4. Der Dispatcher nimmt den ICM-Request an, legt einen Kontext an und bestimmt einen Workprozess zur Verarbeitung 5. Der Workprozess bearbeitet die Daten aus der Memorypipe und speichert sie dort wieder 6. Der ICM schickt die Response Daten an den Client

Der ICM beinhaltet ebenfalls einen Cache für die Zwischenspeicherung von HTTP-Objekten. Der ICM-Server-Cache (auch: Internet-Server-Cache (ISC)) bedient wiederholte Client-Anfragen ohne einen Workprozess zu starten und somit ohne auf die Datenbank zuzugreifen. Für den angestrebten Vergleichstest wird der Server-Cache deaktiviert, damit keine Cache-Treffer die Ergebnisse verfälschen. Das Internet Communication Framework (ICF) liefert für den ABAP-Stack eine objektorientierte Verschalung zur Behandlung von HTTP-Anfragen und Antworten. Es wird auch als HTTP-Framework bezeichnet.

Tab. 2 – Exemplarische Requestverarbeitung und technische Architektur des SAP WAS [HR04, S. 43]

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 14 Die Entwicklung des ICF und des ICM ermöglichten erst die direkte Anbindung des SAP R/3 Applikationsservers als SAP WAS an das Internet [vgl. Ho06, S. 27].

2.3.3 SAP Konnektoren

SAP-Systemen inhärent ist schon immer die Möglichkeit BAPIs und Funktionsbausteine über einen Remote Function Call (RFC) zu rufen und darüber gerufen zu werden. RFC ist ein von SAP entwickeltes proprietäres Protokoll zum Aufruf von Funktionen in (anderen) Systemen über eine Netzwerkverbindung. Dabei können Übergabe- und Ergebnisparameter mitgegeben werden. [vgl. S-N04, S. 36]. RFC unterstützt dabei synchrone, asynchrone und transaktionale Aufrufe [vgl. S-N04, S. 330]. SAP hat die Öffnung ihrer monolithischen Strukturen über die Integration Engine (die Integrationsschicht des ICM) weiter vereinfacht. Die Aufgabe der Integration Engine ist die Kommunikation des SAP-Systems mit anderen Systemen zu ermöglichen. Ein wesentlicher Bestandteil der Integrationsschicht sind die SAP Konnektoren, sie sind entscheidenden Komponenten der SAP-Kommunikationstechnologie [vgl. SAP08i]. Diese werden von der SAP kostenlos mit ausgeliefert und ermöglichen die Anbindung von Fremdsystemen an den ABAP-Stack. Es gibt z.B. den SAP Leightweight Directory Access Protocol Connector (SAP LDAP Connector), den SAP Connector für Visual Studio .NET oder auch den SAP Java Connector (SAP JCo). Letztgenannter wird für unsere Betrachtungen der Technologiestacks eine wichtige Rolle spielen, deshalb soll dieser im Folgenden im Detail beschrieben werden. Die Nutzung und Bereitstellung von Webservices sind seit der Version 6.20 des SAP WAS für den ABAP- und den JAVA-Stack möglich. Webservices sind eine standardisierte Schnittstelle zur Kommunikation von Softwarekomponenten zwischen verschiedenen Systemen [vgl. S-N04, S. 37]. Somit ist auch die Kommunikation der beiden Technologiestacks über Webservices möglich. Dies ist einmal auf Applikationsebene (low-Level) möglich, bei der Simple Object Access Protocol (SOAP) Nachrichten durch die Anwendung selbst verschickt und interpretiert werden müssen oder durch den Integration Builder (high-Level), einer SAP PI Komponente, durch den Proxyklassen für Webservices generiert werden, die dann relativ leicht in Anwendungen integriert werden können. Angemerkt sei, dass SAP JCo genau auf die Kommunikation des JAVA-Stacks mit dem ABAP-Stack, in Form des SAP ECC Backends optimiert wurde. Es ist davon auszugehen, dass die Performanz eines JCo-Aufrufes um ein vielfaches besser ist, als bei der möglichen Kommunikation über Webservices, bei der eine produktionsreife Servicequalität noch nicht gewährleistet werden kann. SAP arbeitet allerdings daran, eine serviceorientierte Abstraktion von Anwendungsschicht und Persistenzschicht über Webservices zu erreichen [vgl. SAP08i]. An dieser Stelle sei herausgestellt, dass eine strikte Trennung von ABAP- und JAVA-Persistenzschicht von SAP beabsichtigt und umgesetzt ist. Dies beantwortet die sich stellende Frage, warum man nicht das vorhandene ABAP-Datenbankschema auch als JAVA-Persistenzschema benutzt und somit direkt, z.B. über Java Database Connectivity (JDBC), darauf zugreift, anstatt SAP Konnektoren (insbesondere JCo) zu verwenden. Hierfür führt SAP u.a. die folgenden beiden Gründe auf [vgl. S-N05, S. 290ff.]: Der direkte Zugriff würde zum einen dem J2EE-Standard widersprechen, da dann eine Existenz der ABAP-

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 15 Persistenzschicht vorausgesetzt würde und somit die Unabhängigkeit verloren ginge, zum anderen, müssten JAVA-Entwickler den ABAP-Konventionen z.B. bzgl. Sperrverwaltung und Transaktionssicherheit folgen, um die Datenkonsistenz sicher zu stellen. SAP JCo basiert auf dem Java Native Interface (JNI) und wurde von SAP teils in JAVA und teils in C programmiert. SAP JCo ist demnach eine Middleware, die als Brücke zwischen der ABAP- und JAVA-Welt dient. Dabei ermöglicht SAP JCo, dass ABAP-Anwendungen und JAVA-Anwendungen bidirektional miteinander kommunizieren können. Diese Kommunikation wird auch InboundCall (JAVA ruft ABAP) und OutboundCall (ABAP ruft JAVA) genannt. SAP JCo wird als ein Paket von JAVA-Klassen zur Verfügung gestellt, die zur Verwendung in ein JAVA-Programm importiert werden müssen. JCo ist Bestandteil des SAP Business Connectors und ebenso integraler Bestandteil des SAP WAS zur Kopplung der beiden Technologiestacks [vgl. S-N04, S. 331]. Aus Sicht eines JAVA-Clients wird eine JAVA-Methode des JCo Application Programming Interface (API) gerufen, diese wird über die RFC-Engine in einen ABAP-Aufruf gewandelt und an das SAP System gesendet. Andersherum wird der gleiche Weg beschritten, das SAP System generiert einen RFC-Aufruf, der über die RFC-Engine und die JCo-API in einen JAVA-Methodenaufruf umgewandelt wird. Die nebenstehende Abbildung (vgl. Abb. 4) veranschaulicht die beschriebenen Schritte. Von der SAP werden in Bezug auf JCo-Verbindungen zwei Alternativen zur Verfügung gestellt [vgl. SAP08i]: Direkte JCO-Verbindungen – diese werden direkt geöffnet und bleiben so lange erhalten, bis sie vom Programm wieder geschlossen werden. Der Anwendungsentwickler muss sich um Verbindungsaufbau und -abbau kümmern. JCo-Connection Pools – Bei Connection Pools wird eine definierte Anzahl an Verbindungen in einem Pool für alle Benutzer zur Verfügung gestellt und aufrecht gehalten. Soll eine Verbindung benutzt werden, wird eine Anfrage an den Pool gestellt. Dieser antwortet, indem dieser eine Verbindung zurückgibt. Ist das anfordernde Programm mit der Nutzung der Verbindung fertig, wird diese zum Schluss wieder an den Pool frei gegeben. Diese Verbindungspooling hat zwei Vorteile, einmal das ein Overhead bei der Anmeldung am SAP-System vermieden wird, da die Verbindungen erneut benutzbar sind, zum anderen kann die Anzahl der Verbindungen über den Pool begrenzt werden, so dass die Systemressourcen besser kontrolliert werden können. Bei InboundCalls, können direkte Verbindungen, oder Verbindungen über einen Connection Pool hergestellt werden. Bei „OutboundCalls“ muss ein als eigenständiger Server agierendes JAVA-Programm auf dem Host deployed werden, was letztendlich über Sockets die ankommenden ABAP-Clientaufrufe annimmt“ [vgl. S-N04, S. 339]. Alle Metadaten die für den Aufruf von RFC-fähigen Funktionsbausteinen benötigt werden, sind in einem JCo-Repository abgelegt. Dies beinhaltet z.B. Import- und Exportparameter und

Abb. 4 – SAP JCo-Architektur [vgl. SAP08i]

SAPJCO

Java Anwendung

JCo Java API

Middleware Interface

RFC Middleware

JNI Layer

RFC Library

SAP System

RFC

SAPJCO

Java Anwendung

JCo Java API

Middleware Interface

RFC Middleware

JNI Layer

RFC Library

SAP System

RFC

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 16 deren Typisierung. Alle Metadaten werden zur Laufzeit dynamisch vom Server geholt [vgl. SAP08i]. Da ABAP andere Datentypen verwendet, als JAVA ist ein Mapping zwischen den unterschiedlichen Typen notwendig [vgl. SAP08i]. SAP ist ständig bemüht, die Verbindungen zu ihren Systemen von „außerhalb“ zu vereinfachen und zu verbessern. Zu der zuvor beschrieben JCo-Architektur gibt es immer wieder Erweiterungen und Werkzeuge zur vereinfachten Handhabung. Hier sollen zwei genannt werden: Zum einen der SAP Enterprise Connector (vgl. Kapitel 2.3.3), der den Anwendungsentwickler durch die Generierung von Proxyklassen bei RFCs und Typisierung unterstützt. Zum anderen der SAP Java Resource Adapter (SAP JRA), der die J2EE-Standardschnittstellen von JCo implementiert und vereinfacht, so dass z.B. eine Konfiguration über eine Benutzeroberfläche möglich ist [vgl. SAP08i].

2.3.4 Systemlandschaft des SAP WAS

Ein SAP WAS wird meist innerhalb einer Systemlandschaft installiert und betrieben. Das Designkonzept einer solchen Landschaft sieht im Idealfall eine homogene Cluster-Architektur vor. Darin inbegriffen sind ein globaler Lastverteiler, eine Systemdatenbank mit einer zentralen Instanz (mit Message-Server, Enqueue-Server, usw.) und eine oder mehrere Dialoginstanzen mit Lastverteilungsknoten und Applikationsserverknoten. Die mögliche Cluster-Architektur des SAP WAS soll im weiteren Verlauf keine zentrale Rolle spielen. Die Erwähnung ist hier sinnvoll, da sie für beide Technologiestacks in Merkmalen wie Skalierbarkeit, Hochverfügbarkeit, Sicherheit, Supportability die gleiche Grundlage bietet. Dies hat zur Folge, dass diese Aspekte für eine spätere Betrachtung eines Vergleichs der beiden Technologiestacks außen vor bleiben können. In einer Minimalkonfiguration, können sämtliche Komponenten hardwaretechnisch auf einem Server betrieben werden. Diese Minimalkonfiguration vernachlässigt dann allerdings mögliche Konzepte zur Hochverfügbarkeit, Sicherheit und anderen.

2.3.5 ABAP-Stack

Der ABAP-Stack zeichnet sich durch eine hohe Zuverlässigkeit und Robustheit aus, insbesondere durch die langjährige Nutzung im Anwendungsfeld von erfolgskritischen Geschäftsanwendungen. Die Programmiersprache ABAP ist auf das Handling von Tabellen und somit Datenbankinhalten optimiert, was sich in einer intuitiv leichten Benutzbarkeit und Verarbeitung von SQL und damit gewonnen Daten zeigt. ABAP ist eine Interpretersprache, d.h. die Codeverarbeitung wird zuerst über einen Zwischencode (Interpreter Language) gewährleistet. Dieser „managed Code“ wird in einer ABAP Virtual Machine (ABAP VM) ausgeführt. Dieser Umstand beinhaltet die zuerst oben erwähnte Robustheit, da kein ABAP-Prozess die volle Kontrolle über den Server erlangen kann und diesen damit zur Überlastung und zum Absturz bringen kann. In der Zeit von JAVA und Plattformunabhängigkeit erscheint dieser Umstand als „normal“, wenn man aber bedenkt,

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 17 dass der SAP Applikationsserver dieses schon seit seiner Anfangszeit unterstützt, als JAVA noch in den sprichwörtlichen Kinderschuhen steckte, ist es eine zu erwähnende Leistung. Durch die Ausführung des Codes in der ABAP VM wird eine Plattformunabhängigkeit erreicht, da die Portierung auf andere Betriebssysteme sich auf die Portierung der Virtual Machine beschränkt. Der Entwickler hat so keine Probleme oder Besonderheiten mit unterschiedlichen Betriebsystemumgebungen. Mit der Integration eines SQL-Subsets, Open SQL, ist für eine Plattformunabhängigkeit des Zugriffs auf die Datenbankschicht gesorgt. Dabei sorgen Pufferzugriffe für Skalierbarkeit von komplexen Datenbankzugriffen. Dem System inhärent sind Sperrmechanismen und ein Verbuchungskonzept zur Integritätswahrung. Die Definition persistenter Datenobjekte (Persistenz über Laufzeit) ist möglich [vgl. HR055, S. 82]. Der ABAP-Stack bietet eine vollständige integrierte Entwicklungs- und Laufzeitumgebung für ABAP-basierte Geschäftsanwendungen. Bei der Entwicklung gibt es keine Notwendigkeit der expliziten Beachtung von Prozess- oder Speicherverwaltung, Multi-User Fähigkeit oder Datenbankverbindungen; dies sind Basisdienste des SAP WAS. In der integrierten Entwicklungsumgebung gibt es Oberflächeneditoren für SAP Graphical User Interface (SAP GUI) Entwicklungen, sowie zwei Entwicklungswerkzeuge beziehungsweise Frameworks für Web Anwendungen: Business Server Pages (BSPs) und WebDynpro Anwendungen (WDA). Das ABAP Dictionary bietet eine zentrale Verwaltung für Definitionen und Typisierungen. Mit dem „neuen“ ABAP Editor, ist der eigentliche Entwicklungskomfort durch Eigenschaften wie farbliche Kennzeichnungen und/oder Eingabehilfe bei benutzen Variablen gestiegen. Der ABAP-Stack unterstützt seit jeher ein ausgefeiltes Versionierungs- und Transportsystem. So werden z.B. alle verschiedenen Entwicklungsstände in der Versionierung beibehalten und können somit wiederhergestellt werden. Die Minimalsystemlandschaft von SAP-Systemen besteht aus einem Entwicklungs- und Testsystem (T-System) und einem Produktivsystem (P-System). Üblich ist es ebenfalls ein System zur Qualitätssicherung (Q-System) zu haben. Entwicklungsobjekte werden im Entwicklungssystem innerhalb von Paketen erzeugt und einem Transportauftrag zugeordnet. Um eine Entwicklung produktiv zu schalten, muss ein Transport der Pakete bzw. Transportaufträge über die eingeführten Transportwege stattfinden. Im Q-System wird die Entwicklung ausgiebig getestet und schließlich weiter zur produktiven Nutzung ins P-System transportiert. Möglichkeiten zum Fehler suchen und beseitigen (debuggen), Werkzeuge für Laufzeitanalyse und Testen sowie ein Modifikationsassistent zum Abgleich von kundeneigenen Entwicklungen stehen im ABAP-Stack zur Verfügung [vgl. HR05, S. 81]. Die Entwicklungssprache ABAP und ihre Erweiterung zu ABAP Objects bietet prozedurale und objektorientierte Entwicklungsmöglichkeiten mit der Möglichkeit objektorientierte Elemente und Paradigmen zu benutzen und Umzusetzen. Hier seien nur stellvertretend genannt Klassen, Interfaces, Vererbung, Polymorphie, usw. Hier sei auf Fachliteratur zur objektorientierten Programmierung und objektorientierten Rahmenwerken und


Sammelrollen Rolle (eines Benutzers) Sammelprofil Berechtigungsprofil Berechtigung (Ausprägung v. BOB) Objektklasse Berechtigungsobjekt (BOB) Berechtigungsfeld

Entwurfsmustern verwiesen [z.B. vgl. Bo93; KK07; Zü98]. ABAP Objects zählt somit zu der vierten Generation der Programmiersprachen BSPs sind eine Möglichkeit zum Design und zur Implementierung von Webapplikationen. Business Server Pages sind ein seitenbasiertes Programmiermodell, das serverseitiges scripting über HTML mit ABAP als Skriptsprache erlaubt. Seit der Version 6.40 gibt es die Möglichkeit das integrierte Model-View-Controller Design Pattern in der BSP Programmierung zu benutzen. Damit wird eine strikte Trennung von Präsentation und Businesslogik erreicht und die Wartbarkeit und Erweiterung der Anwendungen vereinfacht. Zur Vereinfachung des GUI-Designs gibt es die BSP-Extensions. Diese bieten die Möglichkeit UI Elemente wieder zu verwenden. Über die BSP-Extensions können selbständig HTML-Passagen frei definiert und programmiert werden, die wieder verwendbar sind. HTMLB und XHTMLB sind BSP-Extensions, die als vorgefertigte und mit ausgelieferte Erweiterungen von SAP zur erheblich einfacheren Layoutgestaltung dienen. In diesen vorgefertigten Erweiterungen gibt es viele Standard UI Elemente, die im SAP-Umfeld benutzt werden, z.B. „TableViews“ oder das Advanced List Viewer-Grid (ALV-Grid) zur Tabellendarstellung und -bearbeitung. WebDynpro for ABAP (WD4A) ist das von SAP als zukünftige Technologie für alle Benutzeroberflächen proklamierte GUI-Framework. Es ist ebenfalls voll in die ABAP Workbench mit einer Art von What-You-See-Is-What-You-Get (WYSIWYG)-Editor integriert. Ziel von WebDynpros ist es Technologien wie HTTP, HTML, Cascading Style Sheets (CSS) und Extensible Markup Language (XML) und clientseitiges scripting vollständig zu kapseln. WebDynpros ermöglichen es damit Business Logik zu entwickeln, ohne dabei ein Vielfaches an Zeit in die Anpassung von Layout & Design, sowie Anpassung von Kommunikationsprotokollen und Benutzerinteraktionen zu investieren. WD4A ist vollständig in ABAP-OO programmiert [vgl. Ho06, S.13]. Das Berechtigungskonzept des SAP WAS be-steht aus einem hierarchischen Kontrollsystem. Als kleinstes Element gibt es das Berechtigungsfeld, das oberste Objekt bilden Rollen bzw. Sammelrollen. Die Hierarchie, ist aus nebenstehender Grafik (Abb. 5) zu entnehmen. Eine Berechtigung kann jederzeit im ABAP-Code über: AUTHORITY-CHECK OBJECT ´Z_BO_BEISPIEL’

IF sy-subrc <> 0

...

Endif.

abgefragt werden. Die Funktionalität als Webserver ist im ABAP-Stack seit dem Jahr 2000 mit dem Release 6.10 des SAP WAS im SAP Applikationsserver integriert. Diese Integration hat den Vorteil, dass die Nutzung der Webfunktionalitäten des ABAP-Stacks keine weitere Installation von

Abb. 5 – Hierarchie der SAP-Berechtigungen

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 19 Komponenten, Modulen oder anderen Erweiterungen benötigt, vorausgesetzt ein SAP-System des entsprechenden Releases steht zur Verfügung. Die Funktionalitäten können relativ leicht über das Internet Communication Framework aktiviert und konfiguriert werden. Der Aufwand ist überschaubar.

2.3.6 JAVA-Stack

Der JAVA-Stack, der seit Release 6.20 im SAP WAS zur Verfügung steht, ist nach Java 2 Platform Enterprise Edition Standard implementiert. Daraus folgt, dass der JAVA-Stack eine nicht proprietäre Plattform zur Anwendungsentwicklung bietet. JAVA-Applikationen laufen in der JAVA Virtual Machine (JAVA VM). Dabei wird der JAVA-Quellcode in einen Zwischencode umgewandelt (JAVA-Bytecode), so dass eine kontrollierte Ausführung durch den/die Prozessor/en möglich ist. Kein Prozess kann so die volle Kontrolle über den Server übernehmen, und diesen damit überlasten und zum Absturz bringen. Die Prozesse werden dadurch ebenfalls voreinander geschützt, so dass Seiteneffekte auszuschließen sind. Der JAVA-Stack bietet Transaktionssteuerung, Datenbankanbindung, komponentenbasierte Entwicklung, Lastverteilung etc. Einer der Hauptgründe warum der JAVA-Stack von SAP in ihrem SAP WAS implementiert wurde, ist die große Verbreitung und Standardisierung. Eine große Community an JAVA-Entwicklern steht weltweit zur Verfügung. Dazu kommt eine Vielzahl an vorgefertigten Codebeispielen, Programmen und Tools. Der JAVA-Stack des SAP WAS ist mit dem Industriestandard J2EE-konform. In der neuesten Version SAP NetWeaver 7.1, unterstützt der JAVA-Stack sogar alle durch JEE5 definierten Standards für Enterprise Anwendungen [vgl. Ei07 et al. S. 411]. Damit besitzt er eine breite Basis von Entwicklungs- und Sicherheits-standards [vgl. SAP08c]. Es werden die in der nebenstehenden Tabelle (vgl. Tab. 3) aufgeführten J2EE-Komponenten und Schnittstellen unterstützt. Eine Webunter-stützung durch Standards wie SOAP, XML und Extensible Stylesheet Language Transformation (XSLT) sind quasi selbstverständlich. Der JAVA-Stack bietet keine integrierte Entwicklungsumgebung innerhalb des SAP WAS. Der Markt bietet aber eine Vielzahl von Standard JAVA-Entwicklungswerkzeugen. SAP stellt das SAP NetWeaver Developer Studio (SAP NWDS), ein auf der OpenSource Entwicklungsplattform Eclipse basierendes Produkt, zur Verfügung. Dieses wurde im

Unterstützte J2EE-Standards Abkürzung Java Connector Architecture (JCA) Java Database Connectivity (JDBC) Remote Method Invocation (RMI) Java Transaction API (JTA) Java Transaction Service (JTS) Java Cryptographic Architecture (JCA) Java Cryptography Extension (JCE) Java Authentication & Authorization Service

(JAAS)

Java Naming and Directory Interface

(JNDI)

Enterprise JavaBeans (1.1 & 2.0) (EJB) Java Message Service (JMS) JavaServer Pages (JSP) Java Servlets Java API for XML Processing (JAXP) Improved Container-Managed Persistence

(EJB CMP)

Query Language (EJB QL) Tab. 3 – Vom SAP WAS unterstützte J2EE-Standards

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 20 Vergleich zu Eclipse um verschieden Sichten, Projekttypen und Objekte erweitert, bietet aber den bekannten Entwicklungskomfort. Anknüpfend an das „sehr ausgefeilte, systemübergreifende Korrektur- und Transportwesen“ [vgl. Ei07 et al S. 411] des ABAP-Stacks hat SAP die SAP Java Development Infrastructure (SAP JDI) entwickelt. Diese bietet über das SAP NWDS die integrierte Möglichkeit zur Zusammenarbeit in großen Entwicklerteams, eine Versionsverwaltung und eine Art Transportsystem, welches in diesem Sinn einzigartig ist, da diese Funktionalität in der klassischen JAVA-Entwicklung nur über zusätzliche Werkzeuge und Prozesse realisieren lassen [vgl. Ei07 et al. S. 411]. Das Design Time Repository (DTR) ist damit eine zentrale Komponente zur Verwaltung der Entwicklungsobjekte. Mit dem Java Dictionary gibt es die Möglichkeit Datenbankobjekte oder globale Datentypen plattformunabhängig, zentral und projektübergreifend zu definieren und zu verwalten. Die Komponente Software Logistics des JAVA-Stacks beinhaltet ein Change Management System (CMS) und einen Software Delivery Manager (SDM) über den das Deployment von Anwendungen gesteuert wird. Über die SAP JDI mit ihren Komponenten wird eine lokale Entwicklung ermöglicht und die Verbindung und Synchronisation mit dem Entwicklungsteam gewährleistet. Ein Zusammenspiel der eben erwähnten Komponenten findet sich in der folgenden Grafik (vgl. Abb. 6).

Das SAP NWDS bietet weiterhin einige integrierte Werkzeuge (WebDynpro Toolset, J2EE-Toolset, Web Services IDE, Persistenz-Tools, SAP Enterprise Connector, SAP JAVA Testwerkzeuge). Mit dem SAP Enterprise Connector wird der Zugriff auf die SAP-Geschäftsfunktionalität aus JAVA-Anwendungen stark vereinfacht. Für eine genaue Beschreibung aller Werkzeuge sei auf die SAP-Onlinehilfe verwiesen [vgl. SAP08h]. Das Sicherheits- und Berechtigungskonzept von JAVA beruht zuerst einmal auf Sicherheit im Sprachkonzept. Es gibt keine direkten Zugriffe auf den Hauptspeicher, keine Pointer und eine automatische Garbage Collection. Damit sind provozierte Buffer Overflows (nahezu)

Abb. 6 – Entwicklungsprozess unter Einbeziehung aller Komponenten der JDI [KTD05, S. 45]

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 21 ausgeschlossen. Die Typisierung wird zur Laufzeit vorgenommen. Durch die oben erwähnte JAVA VM ist ein Sandkastenmodel (Sandbox) gewährleistet. Um dieses Modell etwas zu lockern und den Applikationen (besonders JAVA Applets) etwas mehr Berechtigungen zu geben, sind zuerst signierte Applets und später Berechtigungen auf Anwendungsebene (fine-grained security) eingeführt wurden. Über diese Berechtigungen können mehreren Applikationen verschiedene Berechtigungen zur Laufzeit zugeordnet werden. JAVA beinhaltet außerdem ein abstraktes Sicherheitskonzept, welches über eine Hierarchie von „Realms“ zu Benutzern, über Gruppen und Rollen hinweg geht. Die Implementierung bleibt dabei dem Entwickler überlassen. Der JAVA-Stack muss bei der Installation von SAP NetWeaver explizit mit installiert werden. Es gibt die Möglichkeit einer „Double-Stack“ Installation, d.h. ABAP+JAVA auf einem Server oder die jeweiligen Technologiestacks separat installieren.

2.4 Vergleich der Technologiestacks An dieser Stelle soll nun eine erste Gegenüberstellung und Bewertung der beiden Technologiestacks vollzogen werden. Damit sollen die gewonnenen Erkenntnisse zusammengefasst und veranschaulicht werden. Des Weiteren wird eine Eingrenzung der zu beachtenden Merkmale für die Aufstellung des Kriterienkatalogs vorgenommen. Die auf der nächsten Seite folgende Tabelle (vgl. Tab. 4) stellt die beiden Technologiestacks mit den in den vorherigen Abschnitten beschriebenen Merkmalen gegenüber. Dabei wird eine Gliederung in vier Kategorien vorgenommen: Entwicklungsumgebung, Integration und Konnektivität, Datenbankzugriff und Serverarchitektur. Es wird über die Symbole � und � das Vorhandensein des jeweiligen Merkmals gekennzeichnet und über die Vergabe von einem bis drei Sternen (�) eine „subjektive“ Bewertung vorgenommen, die im Folgenden noch erläutert wird.


Gegenüberstellung der technischen Merkmale der Technologiestacks Merkmal ABAP-Stack JAVA-Stack Vorhanden Bewertung Vorhanden Bewertung Entwicklungsumgebung IDE � �� Komfort des IDE � � � �� Datadictionary � �� Transportwesen � �� Versionskontrolle � �� Userinterfacedesign � ��

Integration und Konnektivität Standardwebprotokolle � �� Offenheit � � � �� Standardframeworks � �� Integration von SAP-Anwendungen

� ��

Integration von Nicht-SAP-Anwendungen

� � � ��

Web Services � �� Enterprise Service Architecture � - � - Portalfunktionalität � - � - Portalintegration � �� Prozess Integration � - � - Composite Applications � - � - Konnektoren � ��

Datenbankzugriff Auf Eigenes DB Schema � �� Direkter Zugriff auf SAP ERP-Daten (ABAP-Schema)

� �� -

Datenbankunabhängigkeit � �� Transaktionsfähigkeit (ACID) � �� Caching- und Tracingmechanismen

� ��

Serverarchitektur Plattformunabhängigkeit � �� Lastverteilung � �� Hochverfügbarkeit � �� Sicherheit � �� Berechtigungen � �� Ressourcennutzung � ��

Tab. 4 – Gegenüberstellung der technischen Merkmale der Technologiestacks

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 23 Die IDE des ABAP-Stacks ist vollständig im Applikationsserver integriert. Die Entwicklungsumgebung kann sofort nach Installation des SAP WAS genutzt werden. Das SAP NWDS hingegen ist erst nach separater Installation auf dem Client nutzbar. Die ABAP Workbench bietet nicht den Entwicklungskomfort, der im Eclipse Umfeld als Standard bezeichnet werden würde. Als Beispiel ist automatisches Vorschlagen von vorhandenen Funktionen einer Klasse nur über Assistenten („Wizards“) und Menüs („Muster“) möglich oder ein Paket umfassendes Refactoring von Funktionsnamen oder Variablennamen gar nicht möglich. Der Konfigurationsaufwand der ABAP Workbench ist trivial und beschränkt sich maximal auf die Auswahl des „neuen“ oder des „klassischen“ Editors. Beim SAP NWDS sind einige Konfigurationseinstellungen vorzunehmen, um das Deployment von Anwendungen möglich zu machen und das SAP NWDS an das SAP JDI zu koppeln und die Funktionen zum Transport und zur Versionierung nutzen zu können. Die Möglichkeiten des Userinterfacedesigns sind mit dem SAP NWDS komfortabler als mit der integrierten ABAP Workbench. Beide Technologiestacks bekommen die gleiche Bewertung allerdings aufgrund von unterschiedlichen Kriterien. Der JAVA-Stack bietet über das SAP NWDS die Möglichkeit zur Integration anderer UI, wie z.B. des Google Web Toolkits. Es gibt zahlreiche Möglichkeiten relativ einfach ein komplett anderes Look-and-Feel zu gestalten. Die WebDynpros JAVA (WDJ) sind seit früheren Releases vorhanden und damit in der Zahl ihrer Funktionsmöglichkeiten weiter ausgeprägt. Der ABAP-Stack bietet mit WD4A ein vollständig integriertes GUI-Framework. Durch diese Integration ist ein Zugriff auf SAP eigene Funktionsmodule, das Data Dictionary (DDIC) und die Persistenz ohne „umständliche“ Benutzung von JCo oder RFC möglich. Beispielsweise ist die SAP F4-Wertehilfe automatisch bei Feldern mit DDIC Bezug verfügbar genauso können Standard Suchhilfen oder Prüftabellen genutzt werden. Für alteingesessene ABAP-Entwickler ist das Entwicklungsumfeld der ABAP Workbench vertraut [vgl. SAP08f]. In der Kategorie Integration und Konnektivität ist der JAVA-Stack gegenüber dem ABAP-Stack im Vorteil. SAP setzt bei der Unterstützung und Umsetzung von neuen Technologien auf den JAVA-Stack. Als Beispiele dafür lässt sich anführen, dass die komplette SAP-Portalengine, die SAP XI und das SAP CAF auf dem JAVA-Stack entwickelt sind und diesen als Laufzeitumgebung benötigen. Der ABAP-Stack bietet SAP Standardschnittstellen wie IDocs, BAPIs, RFCs und die SAP Konnektoren. Es ist ebenfalls möglich Web Services über den ABAP-Stack anzubieten (und zu konsumieren). Der JAVA-Stack bietet zahlreiche weitere Standardschnittstellen wie JMS oder JCA, auch die komplette Enterprise Service Architektur basiert auf dem JAVA-Stack. Als klarer Vorteil des ABAP-Stacks im Bereich Konnektivität ist der Zugriff auf SAP ECC-Systeme zu nennen. Über ABAP ist ein direkter Zugriff auf die Persistenzschicht des SAP ECC möglich. Aus dem JAVA-Stack muss man grundsätzlich über einen Konnektor auf das SAP ERP-System zugreifen, da dessen Daten im ABAP-Schema der Persistenzschicht gehalten werden. Dieser Zusammenhang wird in der auf der nächsten Seite folgenden Grafik (vgl. Abb. 7) dargestellt und wurde auch in Kapitel 2.3.3 schon erläutert [vgl. SAP08g].

Diplomarbeit Volker Ritzau Kapitel 2 SAP NetWeaver(TM) Integrations- und Applikationsplattform Seite 24 Dieser erschwerte Zugriff auf die ERP Datenbasis macht einen großen Nachteil aus. Bei Datenbankzugriffen auf das eigene Datenbankschema, sowie bei der Transaktionssicherheit sind ABAP- und JAVA-Stack gleich zu bewerten. Als Unterschied beim Umgang mit Datenbanken zeigt sich allein, dass die Auswertung von Zugriffen, das Caching und Monitoring im ABAP-Stack direkt integriert sind und im SAP-System über zahlreiche Reports und Standardmechanismen zur Verfügung stehen. Bei der Entwicklung des JAVA-Stacks wurden ebenfalls Möglichkeiten zu eben Genanntem entwickelt, diese sind aber nicht so weit integriert, so dass nicht der gleiche Komfort erreicht wird. Die Bewertung der Serverarchitektur unterscheidet sich im Berechtigungskonzept, das beim ABAP-Stack sehr viel feiner strukturiert und sehr leicht anwendbar ist. Es gibt drei verschiedene Installationsvarianten des SAP WAS: ABAP-only, JAVA-only und eine „Doublel-Stack“ Installation. Beim Vergleich der allein stehenden Installationsvarianten kann man beim ABAP-Stack einen deutlich geringeren Ressourcenverbrauch in Form von Plattenplatz und Prozessorauslastung bei „Normalbetrieb“ feststellen. Verallgemeinert, sprechen SAP Basis-Experten von einem Faktor von ca. 1:1,3 beim Ressourcenverbrauch. Der ABAP-Stack ist hier nicht nur durch den ressourcenschonenden Umgang im Vorteil, sondern auch durch die einfache in Betriebnahme der Webserverfunktionalität.

Abb. 7 – Integration von JAVA und ABAP [nach HR04, S. 80]


2.5 Zusammenfassung der Ergebnisse Im diesem Kapitel wurde die SAP NetWeaver Integrations- und Applikationsplattform mit ihren Komponenten, sowie der SAP WAS als eigentliche Applikationsplattform im Detail vorgestellt und erklärt. Dabei wurden der Schwerpunkt auf die Funktionalität der beiden Technologiestacks, ABAP und JAVA, des SAP WAS gesetzt. Die Technologiestacks wurden anhand von vier Gruppen von Merkmalen verglichen. Diese legen den Schwerpunkt auf die integrierte Entwicklungsumgebung, die Integrationsmöglichkeiten und Konnektivität der Technologiestacks, die Möglichkeit des Datenbankzugriffs, gerade auf die Persistenzschicht eines SAP ERP-Systems, sowie auf bestimmte Merkmale der Serverarchitektur. Bei der Untersuchung und Gegenüberstellung hat sich herausgestellt, dass der ABAP-Stack historisch bedingt eine stabile, ausgereifte und performante Basis für die Be- und Verarbeitung der Anforderungen, die in einem SAP ERP-System auftreten ist. Er bietet den SAP-Anwendungsentwicklern einen angemessenen Komfort und ein beständiges und ausgereiftes Umfeld zur Entwicklung von erfolgskritischen Geschäftsanwendungen. Die Unterstützung neuerer Technologien wird zunehmend in den Kompetenzbereich des JAVA-Stacks verschoben. Gründe hierfür sind wohl die große Anzahl an Standards und Frameworks, die für eine globale Nutzung im Internet sinnvoll sind. Der Philosophie von SAP die hinter der Einführung des JAVA-Stacks steht spiegelt sich in seinen Vorteilen wieder (vgl. Kapitel 2.2 & Tab. 4). Mit dem JAVA-Stack, gesehen im Kontext des gesamten Produkts SAP NetWeaver, bietet SAP die technische Plattform, um eine Enterprise-SOA umzusetzen. SAP macht sein ERP-System mit der Umstellung auf servicebasierte Lösungen zukunftsfähig und ist zurzeit anderen Mitbewerbern von der Vollständigkeit voraus. SAP NetWeaver wird als Wegbereiter für Enterprise-SOA gesehen [vgl. Fu07, S.432]. Eine alleinige Betrachtung des JAVA-Stacks im Vergleich zum ABAP-Stack, oder auch im Vergleich zu anderen ähnlichen Produkten auf dem Markt, führt zur Auffindung bestimmter Probleme und Mängel, die unter bestimmten Einsatzbedingungen auftreten. Auch in Belangen der Benutzbarkeit und des Komforts der Bedienung sind noch Verbesserungen durchzuführen. Dies ist wohl auf die erst im letzten Jahr 2007 beginnende breitere Nutzung zurückzuführen [vgl. Fu07, S. 430ff.]. Da eine Technologieempfehlung im Rahmen von mittelständischen Projekten vor allem auch an wirtschaftliche Faktoren und nicht nur an technologische Merkmale gebunden ist, wird im folgenden Kapitel ein Kriterienkatalog mit verschiedenen Kriteriengruppen aufgestellt, sowie ein Verfahren zur Auswertung dieser Kriterien erläutert. Eine konkrete Anwendung und Auswertung des aufgestellten Katalogs wird dann in Kapitel 5 vorgenommen.

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 26

3 Erstellung eines Vergleichs- und Bewertungs-kriterienkatalogs

Die IT trägt heutzutage als Faktor zum Unternehmenserfolg bei. Mit zunehmendem Einfluss als Wertschöpfungsfaktor wird es auch immer wichtiger für die Verantwortlichen die IT unter wirtschaftlichen Gesichtspunkten zu betrachten und zu bewerten [vgl. Me03, S.12]. Für die Bewertung von IT gibt es in der Betriebswirtschaftslehre verschiedene Standardverfahren und Kriterien, von denen einige im folgenden Kapitel vorgestellt werden. Dabei ist folgende Problematik bei der Bewertung der hier zu betrachtenden Technologiestacks zu beachten. Es liegt eine enge Kopplung von Merkmalen der IT-Architektur, IT-Technologie und IT-Systeme innerhalb des SAP WAS vor. „Systeme haben Architekturen, Architekturen sind aber keine Systeme.“ [Al03, S.16]. Der SAP WAS ist im Rahmen von SAP NetWeaver eine IT-Architekturkomponente, bietet aber für die SAP NetWeaver-Anwendungskomponenten eine Basistechnologieplattform. Diese Basistechnologieplattform besitzt die in Kapitel 2 im Detail vorgestellten Ausprägungen. Entsprechend besitzt der SAP WAS spezifische Charakteristika und Abhängigkeiten in den impliziten Entwicklungsumgebungen, die bis in die Architekturmerkmale durchgreifen. Eine Betrachtung von vergleichbaren Technologiemerkmalen, die die Abhängigkeiten der Architekturkomponente vernachlässigen, ist somit nicht ausreichend. Auf der anderen Seite ist eine Betrachtung aller Architekturmerkmale die SAP NetWeaver als Integrations- und Applikationsplattform ausmachen, viel zu weitgreifend und zu undetailliert, um Aussagen über die eigentlichen Technologiestacks zu treffen. Die Lösung dieser Problematik kann nur darin liegen aus verschiedenen Gebieten Kriterien heranzuziehen, zu kombinieren und schließlich zu benutzen. Im Folgenden werden zuerst Kriterien und Kennzahlen zur Beurteilung von IT-Architekturen und IT-Technologien zusammengetragen. Im Weiteren werden Methoden zur betriebswirtschaftlichen Bewertung, Gewichtung und Auswertung von IT-Projekten, IT-Prozessen oder IT-Produkten vorgestellt. Es wird eine Bewertung und Auswahl der vorgestellten Kriterien und Methoden nach ihrer Benutzbarkeit für den Vergleich der Technologiestacks vorgenommen. Eine Entscheidung, welche Kriterien und Verfahren in einem Kundenprojekt zum Tragen kommen, kann nur individuell mit dem Kunden erarbeitet werden. Eine Anwendung des aufgestellten Kriterienkatalogs findet in Kapitel 5 statt.


3.1 Bewertungskriterien und Kennzahlen Bewertungskriterien für IT werden oft in empirischen Studien oder tatsächlich durchgeführten Projekten aufgestellt. Sie dienen dem Vergleich von Methoden, Lösungen oder Produkten. Bewertungskriterien sollen Objekte verschiedener Ausprägung vergleichbar machen, um eine Entscheidungsfindung bei der Auswahl zu erleichtern. Zum Zeitpunkt dieser Arbeit konnte kein allgemeingültiger Kriterienkatalog oder ein Standardwerk zur Bewertung von IT gefunden werden. Es wurden allerdings einige allgemeinere betriebswirtschaftliche und spezifischere IT-bezogene Kriterienkataloge zur Bewertung von IT-Architekturen, zur Bewertung von Software oder IT-Systemen und Kennzahlensystemen gefunden, die als Grundlage dienen sollen. Klassische Bewertungskriterien für Software, sind: Funktionsumfang, Sicherheit, Performanz, Verlässlichkeit und Anpassbarkeit [vgl. Al03, S. 151ff.]. Bei der Planung von IT-Architekturen werden eher Kriterien über den gesamten Prozess gebildet, d.h. von der Initialisierung eines IT-Architekturprojektes in der Design Time, bis hin zur Umsetzung des Projektes und den damit verbundenen operativen Kosten in der Run Time (die Begrifflichkeiten werden im dazugehörigen Abschnitt erläutert). Kennzahlen zur Bewertung von IT kommen meist aus dem Umfeld des Managements und Controllings. Sie bilden Grundlagen für die Entscheidung über Budgets, Aufwand, Investitionen und andere Managemententscheidungen. Dabei ist ein entscheidendes Merkmal, dass das Herunterbrechen auf einen monetären Nutzen im Vordergrund steht. Kennzahlen werden oft im Zusammenhang mit Einführungen von Balanced Scorecards [z.B. vgl. Kü05; Be02; u.a.] oder anderen Standardrahmenwerken wie z. B. der IT Infrastructure Library (ITIL) benutzt [vgl. OGC08]. Im Folgenden werden die drei eben genannten Bewertungstypen, klassische Kriterien zur Softwarebewertung, IT-Architekturkriterien und Kennzahlen der IT, kurz vorgestellt.

3.1.1 Klassische Qualitätskriterien von Software

Klassische Qualitätsmerkmale von Software sind aus verschiedenen Sichtweisen nützlich. Sie können vom Softwareentwickler als Messgrößen während der Entwicklung und beim Testen herangezogen werden, von Entscheidungsträgern als Stütze der zu treffenden Entscheidung oder auch vom Benutzer als Anhaltspunkt, um seine Zufriedenheit zu spezifizieren. Neben den hier genannten sechs Qualitätskriterien für Software können je nach Literaturbasis weitere gefunden werden oder andere Metriken benutzt werden. Es wird sich hier auf die folgenden beschränkt, weil sie auch in Bezug auf den SAP WAS und die Vergleichbarkeit der Technologiestacks eine Rolle spielen werden.

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 28 Funktionsumfang Funktionsumfang ist eine wichtige Größe zur Beurteilung von Software, kann aber nicht unbedingt isoliert quantitativ gemessen werden, sondern immer nur im Vergleich zu einem ähnlich gearteten Produkt. „Die Funktionalität bezeichnet die Menge der anwendungsbezogenen Funktionen, die ein Programmsystem ausführt. Enthält die Anwendungssoftware mehr Funktionalität als gefordert, spricht man von Funktionsüberdeckung. Funktionsunterdeckung bezeichnet fehlende benötigte Programmfunktionen und kann gravierende Störungen des Betriebsablaufs verursachen. Funktionsüberdeckung ist Funktionsballast durch unnötigen Ressourcenverbrauch, hohe Komplexität, große Fehleranfälligkeit, hohen Schulungsaufwand, etc.“ [vgl. SW01, S. 736]. Sicherheit Sicherheit bezieht sich unter anderem auf die Unterstützung von Standardsicherheitsmechanismen. Dazu zählen Mechanismen der Authentifizierung der Kommunikationspartner, die sichere Datenübertragung durch Verschlüsselung, Zugriffskontrolle (Autorisierung) durch Rechtekonzepte, Schutz vor Manipulation und Schutz vor Sabotage. [vgl. DFH03, S. 278] Hierbei ist darauf zu achten, dass Sicherheitswerkzeuge einfach, aber ausgereift und leicht verwaltbar sein sollten, damit sie die tägliche Arbeit von Benutzern und Administratoren nicht unnötig verkomplizieren. Schwerer zu überprüfen sind Sicherheitslücken in der eigentlichen Software oder in der jeweiligen Laufzeitumgebung. Sicherheit ist immer im Kontext der eingesetzten Software zu betrachten. Es ist ein schwer messbares Kriterium, weil Sicherheitslücken oft erst dann herausgefunden werden, wenn es zu kompromittierenden Aktionen gekommen ist. Performanz Die Performanz ist eines der am einfachsten messbaren Qualitätskriterien. Es kann durch verschiedene Kennzahlen gemessen werden, z.B. die Laufzeit eines Prozesses, durch verarbeitetes Datenvolumen pro Zeiteinheit, Antwortzeiten, (komplexe) Rechenoperationen pro Zeiteinheit oder ähnlichen Messgrößen. Performanzprobleme können an verschiedenen Stellen auftreten, z.B. beim Zugriff auf Datenbanksysteme, bei Programmabläufen, bei Prozessorauslastung, niedrigen Bandbreiten, uvm. [vgl. DFH03 S. 222 & 420] Immer dann, wenn eine Software nicht performant läuft, kommt es zu einer hohen Intoleranz durch die Benutzer. In Bezug auf Webanwendungen sind z.B. hohe Ladezeiten einer Seite ein Ausschlusskriterium für den Betrachter, sei die Seite noch so interessant oder sinnvoll. Verlässlichkeit Die Verlässlichkeit wird oft an der einkalkulierten und nicht einkalkulierten Ausfallzeit der Software oder des Systems gemessen. Bei geschäftskritischen Anwendungen sind keine bis geringe Ausfallzeiten ein „Muss“. Geschäftsprozesse sind heutzutage oftmals nicht mehr ohne IT-Unterstützung durchzuführen. Ein Ausfall von Software oder Systemen hat schon zu Firmeninsolvenzen geführt. Ein hoher Grad an Verlässlichkeit kann durch zusätzliche High-Availabilty-Funktionen erreicht werden, so können z.B. kritische Anwendungen auf Serverclustern betrieben werden, so dass bei Ausfall ein Ersatzsystem einspringt. Wichtige Daten und Prozesse werden oft an verschiedenen Orten redundant vorgehalten.

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 29 Anpassbarkeit Die Anpassbarkeit bezieht sich auf die Möglichkeit, die Software oder das IT-System an die individuellen Bedürfnisse des Kunden anzupassen und einzustellen. Dies kann relativ einfach mit der Einbindung eines Firmenlogos in die Komponente beginnen, oder die Anpassung des Designs an das Corporate Design der Firma beinhalten. Interessanter wird die Anpassung von Geschäfts- und Prozesslogiken an die individuellen Prozesse des Kunden. Bei ERP-Systemen unter dem Begriff Customizing bekannt, wird die Standard-ERP-Software so an die differenzierenden Merkmale der Kundenprozesse angepasst, dass diese als Alleinstellungsmerkmal Bestand haben. Benutzbarkeit Benutzbarkeit bezieht sich auf die Interaktion von Mensch und Maschine. Besonders grafische Benutzeroberflächen (GUI), müssen in der Art gestaltet werden, dass ein Benutzer intuitiv die Funktionalität verstehen und benutzen kann. Dabei ist es eine der obersten Direktiven der Ergonomie, dass sich nicht der Mensch der Maschine anpassen soll, sondern die Maschine dem Menschen. Bei der heutigen Verbreitung der IT-Technologien ist die Nachfrage nach einer webähnlichen Benutzeroberfläche hoch, weil viele Anwender mit solchen Oberflächen und Funktionsweisen vertraut sind. Langwierige Einweisungen in Programme erfordern viel Zeit und sind als Kostenfaktor zu berücksichtigen. Auch eine umständliche und zeitaufwendige Benutzbarkeit während der täglichen Arbeit kann Prozesse verkomplizieren, verlangsamen und damit höhere Kosten verursachen. Benutzbarkeit kann durch Beobachtung von Benutzern und deren Befragung nur qualitativ und nicht quantitativ gemessen werden. Studien zur quantitativen Messung von Benutzbarkeit (z.B. Zeitmessungen von Mausklicks) haben keine nennenswerten Erfolge zeigen können.

3.1.2 Bewertungskriterien für IT-Architekturen

In der Literatur lassen sich zahlreiche Kriterien für die Einordnung von IT-Architekturen finden. Diese sind oft aus zahlreichen Erhebungen verschmolzen. Es ist zu beachten, dass IT-Architekturen stark an der Strategie eines Unternehmens ausgerichtet sein müssen [vgl. KS-E03]. Durch diese Ausrichtung am Unternehmenskontext werden Metriken und Betrachtungen im kurz-, mittel- und langfristigen Bereich angestrebt, die für unsere Auswertung in dieser Art und Weise nicht von Bedeutung sind. Hingegen soll hier der Prozess der Einführung einer IT-Architektur, im speziellen einer SOA betrachtet werden und deren Bewertung und Vergleich [vgl. AS05 S. 8-13]. Diese Betrachtung ist nahe liegend, da die Architektur von SAPs NetWeaver eine solche SOA ist. Um eine Evaluation von Service-Orientierten-Architekturen vornehmen zu können, werden verschiedenste Kriterien betrachtet, die die Design Time und die Run Time der implementierten Architektur berücksichtigen. Mit der Designzeit einer IT-Architekturkomponente ist die Zeit vor dem Einsatz und der Benutzung der IT-Architektur gemeint. Dazu zählen vergleichbare Projektphasen der Initialisierung, Planung, Implementierung und Tests [vgl. Mo04].

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 30 Die Run Time bezieht sich entsprechend auf die Kriterien, die während des Einsatzes der implementierten IT-Architektur zur Geltung kommen. Vergleichend könnte man von der Produktivphase der IT-Architektur sprechen [vgl. Mo04]. Ayer und Schönher führen eine szenariobasierte Evaluation von Integrationsarchitekturen anhand der im folgenden aufgeführten Kriterien durch [vgl. AS05, S. 8-13], hierbei ist zu berücksichtigen, dass in konkreten Kundensituationen Definitionen eventuell aufgelockert oder angepasst werden müssen. Initiale Planungskosten (Initial planning efforts) Bei den Initialen Planungskosten, wird ein Unterschied zwischen Kosten zur Unterstützung der unternehmenseigenen IT-Abteilung und dem Kauf externer Beratungsleistungen getroffen. Es werden die Kosten betrachtet, die für den Aufbau von Fähigkeiten, Wissen und Kompetenz benötigt werden, um die IT-Infrastruktur den Anforderungen entsprechend anzupassen. Initiale Entwicklungskosten (Initial development efforts) Bei Nutzung von nicht-standardisierten Technologien muss beachtet werden, dass bei Eigenentwicklung ein erhöhtes Volumen an Entwicklungskosten auftreten kann. Durch Nutzung von Standardtechnologien kann der Faktor der Entwicklungskosten reduziert werden, kann aber im Gegenzug durch anfallende Lizenz- oder Produktkosten nahezu ausgeglichen werden. Persistente Modellierung (Persistent modeling) Bei der Abbildung von Prozessen ist es wünschenswert, gleiche und konsistente Modelle zu benutzen. Dies gewährleistet ein einheitliches Verständnis und bietet die Möglichkeit Prozesse später leichter miteinander zu vergleichen. Technische Anpassbarkeit (Technical adaptions) Die Kosten für technische Anpassungen nach der Einführung der IT-Technologie müssen beachtet werden. Darunter fallen z.B. Aktualisierungen in Form von Versionswechseln oder Sicherheitskorrekturen oder Anpassungen, damit die Technologie neuen Anforderungen gerecht wird (Anpassungen von implementierten Standards o.ä.). Nicht-invasive Integration von Legacy/Host-Systemen (Non-invasive legacy/host integration) Bei Einführung von IT-Technologien ist die Integrationsmöglichkeit in die bestehende IT-Architektur oder die Offenheit und Integrationsfähigkeit der eingeführten Technologie für Altsysteme von großer Bedeutung. Hierunter fallen z.B. Aspekte der Datenübernahme oder auch der Integration von bestehenden Anwendungen in neue Prozessketten. Sicherheit (Security) Bei zunehmender Offenheit der Technologien sind Sicherheitsaspekte ein zunehmendes Kriterium für IT-Entscheidungen. Unterstützung von Standardsicherheitsmechanismen wie Authentifizierung oder Verschlüsselung ist obligatorisch.

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 31 Wartbarkeit (Maintainability) Das Kriterium der Wartbarkeit umfasst Aspekte der Unterstützung von Administrationsaufgaben durch eingebaute Werkzeuge, Lastverteilung, Metadatenmanagement, Monitoring u.a.. Anpassbarkeit (Customizability) Dieser Punkt bezieht sich auf allgemeine Anpassbarkeit der Technologiekomponente und nicht auf die oben aufgeführte technische Anpassbarkeit. Generell bezieht sich Customizinig auf die Anpassung von betriebswirtschaftlichen Prozessen, die durch IT abgebildet werden, an die der Unternehmung. Im weiteren Sinn fällt unter diesen Punkt auch z.B. die Anpassung von Masken und Menüs, Adapterschnittstellen oder unterstützten Prozessen, die bei der täglichen Arbeit mit der Technologie wünschenswert wären. Auch Individualisierung auf ein Corporate Design zählt in dieses Kriterium mit hinein. Stabilität (Stability) Bei diesem Kriterium wird die technische Verlässlichkeit betrachtet. Systemausfallzeiten müssen minimiert werden. Transaktionsverhalten (Transactionality) Heutige Technologien gerade im Bereich der Kommunikation über und mit dem Internet müssen mit einem stetig höheren Datendurchsatz und Transaktionsvolumen zurechtkommen. Auch im Zusammenspiel verschiedenster Systeme müssen Transaktionskosten berücksichtigt werden, wenn Informationen z.B. an mehrere Systeme zur Verfügung gestellt werden müssen. Betriebskosten (Cost of operation) Die Betriebskosten einer Technologie sind eines der wichtigsten betriebswirtschaftlichen Kriterien und müssen von Anfang an in Betracht gezogen werden. Darunter können auch Kosten von Lizenzen oder Wartungsverträgen summiert werden.

3.1.3 Kennzahlen in der IT

“Die Atome des IT-Controllings sind Kennzahlen” [vgl. Kü07, S. VII]. Die Überwachung von IT-Projekten, IT-Budgets oder anderer Controllingobjekte wird durch den so genannten Controllingregelkreis gesteuert. Für ein Controllingobjekt werden Kennzahlensysteme definiert, aus diesen werden IST-Werte mit zuvor definierten SOLL-Werten verglichen. Anhand dieser Analyse werden Maßnahmen bezüglich des Controllingobjektes getroffen, die im nächsten Regelkreisdurchlauf die IST-Werte beeinflussen sollen. Controllingobjekte der IT können Projekte, Produkte & Leistungen, Prozesse, Ressourcen und Organisationen sein. Der wohl schwierigste Aspekt des IT-Controllings ist die Findung und Definition der Kennzahlsysteme und Kennzahlen. Kennzahlen können verhältnismäßig leicht auf einer IT-Infrastrukturebene und einer Hardwareebene (Ressourcen) vollzogen werden, z.B. sind Rechnerleistung (CPU-Zeit), Speicherleistung (Plattenplatz), Anzahl und Kosten von PC/Workstation-Arbeitsplätzen leicht zu messen und zu kontrollieren. Die Aufzählung aller möglichen Kennzahlen der IT würde den Rahmen dieser Arbeit übersteigen, eine umfassende

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 32 Auf- und Zusammenstellung von IT-Infrastruktur Kennzahlen u.a. findet sich in dem Buch Kennzahlen in der IT von Martin Kühn [vgl. Kü07, S. 105ff]. Gerade im Bereich von SAP-Diensten (und dem Vergleich mit Nicht-SAP-Produkten) ist eine sehr wichtige Kennzahl die der Lizenzkosten (Initial product or license efforts). Bei Benutzung von Standardtechnologieprodukten sind die Anschaffungskosten in Form von Produkt- und/oder Lizenzkosten zu berücksichtigen. Auch weitergehende laufende Kosten, wie z.B. Wartungskosten, sind einzubeziehen und abzuwägen. Um Lizenz- und Produktkosten zu senken, sind Alternativen aus dem OpenSource-Bereich zu berücksichtigen. Dabei ist zu beachten, ob ein andauernder Support gewährleistet werden kann und ob zusätzliches Expertenwissen eingekauft werden kann. Im Weiteren werden einige wesentliche Kennzahlen für den Vergleich der Technologiestacks aufgeführt und erläutert. SAP hat ein Lizenzkonzept der definierten Benutzer (named User), welches sie folgendermaßen definiert:

„[Definierte Benutzer sind] Mitarbeiter des Auftraggebers, seiner verbundenen Unternehmen oder ein Mitarbeiter von Drittunternehmen, der berechtigt ist, direkt oder indirekt, unabhängig von der technischen Schnittstelle, auf die überlassene Software zuzugreifen. Definierte Benutzer sind auch technische Systeme, die in Informationsaustausch zum SAP-System stehen, sowie deren Benutzer“ [SAP08e].

Ebenfalls wichtig sind die Wartungskosten auf SAP-Systeme, die, je nach Verhandlungen, zwischen 15%-20% des Vertragsvolumens betragen. Aufgrund der Budgetierung von IT-Projekten sind Kennzahlen zur Messung der Wirtschaftlichkeit unerlässlich. Dabei soll anhand der Kennzahlen eine Auswahl aus den zur Verfügung stehenden IT-Projekten anhand der Rentabilität getroffen werden. Dabei ist anzumerken, dass es oft auch IT-Projekte gibt, die durchgeführt werden müssen ohne dass dabei auf Rentabilität geachtet werden kann, z.B. bei Änderungen von Gesetzen (Risikomanagement) oder staatlichen Verfahren (Zoll, Im- und Export). Zur Rentabilität gibt es vier wichtige Kennzahlen, die im Folgenden kurz erklärt werden sollen, Nettobarwert (NPV), Return on Investment (ROI), Amortisation und Amortisationsdauer. Der Nettobarwert (im englischen Net Price Value, NPV), basiert auf der Zinseszinsrechnung und vergleicht die Investitionskosten mit einer alternativen Anlage des Kapitals am Kapitalmarkt. Hierbei werden alle Wertflüsse auf den Projektbeginn abgezinst und aufsummiert. Ist dieser Wert, der Nettobarwert, größer Null, ist die Investition vorteilhaft. „Return on Investment ist das Verhältnis der Rückflüsse (Netto Cash Flow) einer Investition zur Investitionssumme“ [vgl. Kü07, S. 124]. Dieser Wert ist immer auf ein Jahr bezogen, bei mehrjähriger Betrachtung wird ein Mittelwert gebildet. Die Amortisation gibt über den gesamten Betrachtungszeitraum das Verhältnis aus der Summe aller (Netto-) Rückflüsse und der Investitionssumme an [vgl. Kü07, S. 125].

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 33 Die Amortisationsdauer bezieht sich auf den Nettobarwert. Sie gibt an, wie lange es dauert, bis dieser positiv wird. Nach Ablauf der Amortisationsdauer, sind die für das Projekt anfallenden Kosten, als Kredit betrachtet, vollständig zurückgezahlt. Ein Projekt ist umso rentabler, je kleiner die Amortisationsdauer [vgl. Kü07, S. 125]. Die eben aufgeführten Kennzahlen werden auch für die im nächsten Abschnitt aufgeführten Aus- und Bewertungsmethoden bei der Wirtschaftlichkeitsanalyse benötigt. Das am meisten verbreitete Konzept von Kennzahlen in der IT ist die IT Balanced Scorecard (IT BSC) [z.B. vgl. Kü05; Be02; u.a.], ein aus der Betriebswirtschaftslehre übernommenes und angepasstes Werkzeug zur Verdeutlichung von Informationen eines Unternehmens, als IT BSC bezogen auf die Informationstechnologie einer Unternehmung. Die folgende kurze Aufführung der IT BSC, dient dem Aufzeigen der Möglichkeiten zur Kontrolle und Bewertung von IT-Projekten und IT-Technologien. Sie wird im weiteren Verlauf dieser Arbeit keine Rolle spielen, weil die Einführung einer IT BSC eher ein Werkzeug im Konzernumfeld darstellt als in Mittelstandsprojekten. Das Werkzeug der IT BSC soll das Informationsmanagement unterstützen, indem es anhand von Schlüsselkenn-größen in verschiedenen Bereichen (Finanzwirtschaft, Geschäftsprozessunterstützung, Kunden, Mitarbeiter/Organisation) ein Rahmenwerk von Schlüsselindikatoren (Key Performance Indicator (KPI)) zum Verständnis und der Strategie einer Unternehmung definiert. Anhand dieser kann man Aussagen z.B. über die Produktivität treffen. In nebenstehender Tabelle (vgl. Tab. 5) findet sich ein Beispiel für den KPI Produktivitätsindex.

Produktivitätsindex Identifizierungs-Code: F-007 Formel: Aufwand (Ressourcen) zur Erstellung/Anzahl bzw. Menge der Output-Elemente Beschreibung: Ressourceneinsatz je Output-Element (z.B. Anzahl bearbeiteter Trouble-Tickets oder Desktop Installationen) Anwendbar z.B. für die nachkalkulierten Aktivitäten des Berichtzeitraums Definition der Inputparameter: Standardisierte Output-Elemente (z.B. Trouble-Tickets, User Helpdesk Calls), Aufwand (Personalkosten und sonstige Aufwendungen) Nutzen: Indikator für die Effizienz der Leistungserbringung in der IT; Identifikation von Kostensenkungspotenzialen Datenquelle: Reporting-Datenbank Zielwert: xxx Euro / Output-Element

Tab. 5 – Beispiel KPI - Produktivitätsindex


3.1.4 Kriterien zur Bewertung der Technologiestacks

Die nachfolgenden Tabellen (vgl. Tab. 6, Tab. 7, Tab. 8) zeigen die ausgewählten Kriterien zur Bewertung der Technologiestacks aus den vorherigen Abschnitten. Es wird begründet, warum diese Kriterien für den Kriterienkatalog ausgewählt wurden.

Klassische Qualitätskriterien für Software Auswahl Funktionsumfang � Sicherheit � Performanz � Verlässlichkeit � Anpassbarkeit � Benutzbarkeit �

Die oben stehende Tabelle (vgl. Tab. 6) zeigt die Auswahl der klassischen Qualitätskriterien für Software, die zum Vergleich der Technologiestacks in den Kriterienkatalog mit aufgenommen werden. Die Wahl fällt auf den Funktionsumfang, die Performanz und die Anpassbarkeit der Technologiestacks, die Kriterien Sicherheit, Verlässlichkeit und Benutzbarkeit werden nicht mit aufgenommen. Das ist damit zu begründen, dass die Kriterien Sicherheit und Verlässlichkeit beim SAP WAS weitestgehend durch die Serverarchitektur und die Systemlandschaft realisiert werden, so dass die Unterschiede innerhalb der Technologiestacks nur eine untergeordnete Rolle spielen (vgl. Kap. 2). Die Benutzbarkeit zum einen der Entwicklungsumgebung und zum anderen der erstellten Anwendungen ist ein sehr subjektives Kriterium, welches stark von jedem einzelnen Benutzer und dessen Vorlieben sowie von der jeweiligen implementierten Anwendung abhängt. Beide Technologiestacks bieten die Möglichkeiten, benutzerfreundliche Applikationen [z.B. vgl. ISO98] zu entwickeln. Eine detaillierte Untersuchung der Unterschiede in der Benutzbarkeit, wird bei der Technologieauswahl eine untergeordnete Rolle spielen und ist nicht Thema dieser Diplomarbeit. Bei den Kriterien zur Bewertung von IT-Architekturen wird die folgende Auswahl getroffen, die in nebenstehender Tabelle aufgeführt ist (vgl. Tab. 7). Dabei sind Überschneidungen zu den klassischen Qualitäts-kriterien von Software festzu-stellen. Sicherheit, Anpass-barkeit und „Stability“ (Ver-lässlichkeit) fallen demnach aus o.g, Gründen ebenso aus der Betrachtung heraus.

Tab. 6 – Auswahl der klassischen Qualitätskriterien für Software

Bewertungskriterien für IT-Architekturen Auswahl Initial planning efforts � Initial development efforts � Persistent modelling � Technical adaptions � Non-invasive legacy/host integration � Security � Maintainability � Customizability � Stability � Transactionality � Cost of operation �

Tab. 7 – Auswahl der Bewertungskriterien für IT-Architekturen

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 35 Das Kriterium Initiale Planungskosten ist eines der wesentlich unterschiedlichen Merkmale für den Vergleich, weil die Technologiestacks vom Initialaufwand der Inbetriebnahme stark unterschiedlich zu bewerten sind. Dies liegt darin begründet, dass der ABAP-Stack in den heutigen Releases der SAP ERP-Systeme (oder SAP ECC) enthalten ist, und die Webfunktionalitäten mit installiert sind, so dass nur einige Konfigurationsparameter gesetzt werden müssen. Bei der Neu- bzw. Zusatzinstallation des JAVA-Stacks muss eine initiale Planung oder Erweiterung der IT-Systemlandschaft durchgeführt werden. Die initialen Entwicklungskosten spielen beim Vergleich der Technologiestacks keine Rolle, weil beide zum SAP-Standard gehören und keine Eigenentwicklung der Umgebung vorgenommen werden muss. Die persistente Modellierung ist von Bedeutung, weil der JAVA-Stack für die Umsetzung einer ESA benötigt wird. Viele der dafür benötigten Werkzeuge und Grundlagen beruhen auf der Technologie des JAVA-Stacks. Die technische Anpassbarkeit ist im ABAP- und im JAVA-Umfeld ähnlich zu bewerkstelligen und müssen von SAP Basis-Experten vorgenommen werden. Dieses Kriterium gehört nicht in den Vergleich der Technologiestacks hinein. Die Wartbarkeit von ABAP- und JAVA-Stack macht nach SAP-Preisliste keinen Unterschied in den zu erwartenden Kosten aus. Das Customizing ist in Bezug auf die mögliche Anpassung des UI der entwickelten Webanwendungen ein interessanter Punkt. Customizing im eigentlichen Sinn, nämlich die Anpassung der Geschäftsprozesse findet im ERP-System selbst statt, spielt also auf den ersten Blick keine Rolle. Auf den zweiten Blick und im weiteren Sinn gesehen kann sich die gewünschte Anpassung der Prozesse als Ausschlusskriterium bei der Technologiestackauswahl herausstellen. Wie bereits erwähnt (vgl. Kapitel 2.3.6 & 2.4) sind neue Technologien wie SAP CAF oder SAP xApps, die ein servicebasiertes Framework zur Geschäftsprozess- und Anwendungsmodellierung bieten, allein mit dem JAVA-Stack umsetzbar. Stabilität und Transaktionsverhalten sind serverarchitekturabhängig und für den Vergleich der Technologiestacks eher ungeeignet, weil sie sich bei beiden stark ähneln. Betriebskosten schließlich haben ihre Berechtigung, zumindest in der Wirtschaftlichkeitsanalyse, und werden somit berücksichtigt. Aus dem Bereich der Kennzahlen werden zwei Gruppen eine wichtige Rolle im weiteren Verlauf spielen: Einmal die zuvor als Infrastrukturkennzahlen beschriebenen [vgl. Kü04, S.221], die dem Bereich Produktmanagement zuzuordnen sind und andererseits die aufgezählten Rentabilitätskennzahlen, die ebenfalls bei der Wirtschaftlichkeitsanalyse aufgegriffen werden. Dabei muss beachtet werden, dass das IT-Portfolio eines IT-Bereichs aus Beratungs- und Dienstleistungen, sowie der Bereitstellung und dem Betrieb von IT-Systemen dient und je nach Aufgabenstellung die Kennzahlen zu wählen sind. Weiterhin ist zu beachten, dass das Produktmanagement mit dem Prozessmanagement eng verzahnt ist, denn IT-Produkte

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 36 sind Ergebnisse von Prozessen, die durch sie abgebildet werden. Prozesse sind dabei die Innensicht, die IT-Produkte die Außensicht. Für die Aufstellung des Kriterienkatalogs und die tatsächliche Anwendung im Projektumfeld können kundenspezifische Kennzahlen sinnvoll sein, z.B. ist ein Fremdkräfteanteil (zur Betreibung des SAP WAS) für ein mittelständisches Unternehmen wichtig, für einen Konzern evtl. nur nebensächlich. Es kann ebenso sinnvoll sein, Kennzahlen aus dem Bereich Innovationsmanagement und Risikomanagement hinzuzunehmen. Dies hängt von der Kundensituation ab in der die Kennzahlen Anwendung finden. In der folgenden Auswahl (vgl. Tab. 8) sind zwei Kennzahlen, der Fremdkräfteanteil und der Risikoindex berücksichtigt, die in Kapitel 5, welches die praktische Anwendung des Kriterienkatalogs zeigt, benutzt wurden. Ausgewählte Kennzahlen Beschreibung Produktmanagement Änderungsabstand Zeitspanne die zwischen aufeinander folgenden

Hardware- oder Softwareveränderungen (z.B. Releasewechseln) liegt

Anteil Kosten X an Produktkosten

Enthält nur die Kosten eines spezifischen Prozesses (z.B. Entwicklungs-, Einführungs-, Installations- und Wartungskosten, u.a.); Mehrfachverwendung sinnvoll.

Antwortzeit Zeitspanne nach der Eingabe einer Aufgabenstellung durch den Benutzer bis zu dem Zeitpunkt, an dem die erste Systemreaktion erfolgt (präzise Definition erforderlich)

Rentabilitätskennzahlen Return on Investment (ROI) Verhältnis der Rückflüsse (Netto Cash Flow) einer

Investition zur Investitionssumme Amortisationsdauer Beschreibt die mit dem IT-System erwirtschafteten

Nettoüberschüsse, bezogen auf den Aufwand für die Herstellung/Bereitstellung dieses Systems

Wirtschaftlichkeit Summe der bewerteten Nutzeneffekte im Verhältnis zur Summe der Kosten, bezogen auf die gewünschte Aggregationsstufe (z.B. Produkt, Projekt, Portfolio, ...)

Weitere Kundenspezifische Fremdkräfteanteil Verhältnis der Personalkapazität (in z.B. Manntagen)

von externen zu internen Mitarbeitern, in Bezug auf das Controllingobjekt.

Risikoindex Ermittlung einer Risikokennzahl über eine Checkliste. Bei Auftreten von Risikofaktoren werden Risikopunkte vergeben. Der Risikoindex sollte möglichst klein sein.

Tab. 8 – Ausgewählte Kennzahlen für den Kriterienkatalog


3.2 Auswertungs- und Bewertungsverfahren In der Betriebswirtschaftslehre finden sich verschiedene Methoden zur Überprüfung von Wirtschaftlichkeit, Kosten- & Nutzenmessung, Controlling, Investitionssicherheit und vielen anderen Fragestellungen. Exklusive Bewertungsmethoden für IT sind dabei schwer zu finden, meist findet eine Übertragung der gängigen Verfahren auf die IT statt. Bei der nachfolgenden Vorstellung von Analysemethoden wurde eine Auswahl von Methoden getroffen, bei denen jeweils eine Anwendung auf IT-Szenarios möglich und gängig ist. Dabei sind Vor- und Nachteile in Bezug auf die Bewertung unserer Kriterien zu beachten und zudem die Komplexität der Methodik zu berücksichtigen

3.2.1 Wirtschaftlichkeitsanalyse

Wirtschaftlichkeit ist das optimale Verhältnis von Aufwand (Kosten) zu Ertrag (Nutzen). Am Anfang einer Wirtschaftlichkeitsanalyse steht die Identifizierung der Leistung einer Anwendung gegenübergestellt zu den Kosten einer Anwendung. Eine Wirtschaftlichkeitsanalyse analysiert die Kostenstruktur, die Nutzenstruktur und die Beziehungszusammenhänge zwischen beiden. Von Wirtschaftlichkeit eines Projektes spricht man, wenn die SOLL-Kosten den IST-Kosten und der SOLL-Nutzen dem IST-Nutzen entsprechen. Wesentlicher Punkt einer Wirtschaftlichkeitsanalyse ist es, die Erfolgsfaktoren und mögliche Gefahren eines Projektes zu bewerten. Daraus folgt, dass die drei Säulen der Wirtschaftlichkeitsanalyse die Kosten-, Nutzen- und Risikoanalyse sind [vgl. Me03]. Wirtschaftlichkeitsanalysen sollten objektiv und neutral durchgeführt werden. Eine Möglichkeit, das zu gewährleisten, ist es externe Personen oder Unternehmen mit der Durchführung zu beauftragen. Dabei ist die Seriosität zu wahren und ein vorschnelles „Quick-Assessment“ zu vermeiden. Dies wird durch die unterschiedliche Funktion jeder Unternehmung und einem unterschiedlichen Verständnis von Nutzen begründet. Zur Wirtschaftlichkeitsanalyse sollten ebenfalls keine herstellerabhängigen Produkte zur Kalkulation benutzt werden, sondern die Werte zu Kosten und Nutzen mit projektneutralen, allein auf der Finanzmathematik beruhenden, unzweifelhaften Methoden berechnet werden [vgl. Me03]. Bei der Kostenanalyse steigt die Komplexität zur Berechnung des Return on Investments durch die Berücksichtigung aller Kosten und Folgekosten von Projekten. Um die Komplexität in einem handelbaren Rahmen zu halten, werden nur bestimmte Kostengruppen betrachtet: Hardware, Software, Personal, Betriebskosten und Kosten für externe Dienstleistungen. Dabei wird eine Einteilung in „harte“ (direkte) und „weiche“ (indirekte) Kosten vorgenommen. Direkte Kosten sind einfach ablesbare Kosten (z.B. Anschaffungskosten). Indirekte Kosten bedeutet, dass sie nicht direkt ablesbar sind, sondern mit einem entsprechenden Aufwand gemessen werden müssen. Ebenfalls können ordinale Kosten auftreten, die primär „emotional“ motiviert sind [vgl. Me03].

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 38 Je nach Modell, z.B. nach Gartner Group oder Meta Group, werden diese Kostengruppen unterschiedlich zusammengefasst und angewendet. Die Gartner Group betrachtet mit ihrem Total Cost of Ownership (TCO) Verfahren, entwickelt um 1987, Kosten auf Server- und Clientseite, sowie Benutzerkosten und Opportunitätskosten. Die Meta Group mit ihrem sehr ähnlichen Real Cost of Ownership (RCO) Verfahren hingegen, konzentriert ihre Kostengruppen auf Server- und Clientseite. (Seit 01. April 2005, gehört die Meta Group nach Übernahme durch die Gartner Group zu selbiger) [vgl. z.B. TG05, S. 149ff; WH00, S. 2ff.; GA08]. Beide Verfahren beinhalten keine Nutzenanalyse. Aufgrund dieser Kritik wurden ab ca. 1997 wertorientierte Modelle entwickelt, die eine Nutzenanalyse beinhalten. Bei der Nutzenanalyse ist die Einteilung des Nutzens ebenfalls in qualitative und quantitative Faktoren möglich. Als quantitative Methoden werden direkte Messungen und indirekte Messungen des Nutzens durchgeführt, als qualitative Methode, eine ordinale Messung des Nutzens, wie z.B. bei einem Faktor Kundenzufriedenheit. Verfahren, die diese Nutzenmessung einbeziehen, sind unter anderem von Giga Information das Total Economic Impact (TEI) Verfahren und von McKinsey das Total Value of Ownership (TVO) Verfahren. Hierbei werden neben den Kosten- und Nutzenmessungen auch noch Risiko und Flexibilität bewertet und finanzwirtschaftliche Kennzahlen betrachtet. Beide Verfahren basieren auf der TCO-Methodik und fassen alle aufgeführten Merkmale in ein Rahmenkonzept zusammen. Risikoanalyse bedeutet eine Dokumentation von möglich auftretenden Risiken. Diese müssen ihrer Eintrittswahrscheinlichkeit bewertet werden. Hierzu kann z.B. ein Risikotest durchgeführt werden. In nebenstehender Tabelle (vgl. Tab. 9) findet sich ein Auszug aus einem Risikotest für IT-Projekte. Dabei zählen alle Fragen die mit „Ja“ beantwortet werden, einen Punk, ab einer bestimmten Grenze, die der Risikoindex nicht überschreiten darf, muss sich über die Durchführung des Projektes nachgedacht werden. Bei der Wirtschaftlichkeitsanalyse kann außerdem zwischen dynamischen und statischen Verfahren unterschieden werden. Die Idee bei einem dynamischen Verfahren ist, dass Kosten, Nutzen und Risiken nicht über den gesamten Zeitraum eines Projektes gleich bleiben müssen und sich wandeln können. Z.B. wird der Mehrwert einer Investition über den Projektzeitraum über einen Abschlag bereinigt, da die Einsparungen inflationsbedingt über die Durchführungszeit an Wert verlieren können. Statische Verfahren zeichnen sich schlichtweg

Risikotest (Auszug) Erfordert das Projekt überdurchschnittlich hohen Aufwand? Deckt das Projekt überdurchschnittlich viele Funktionalitäten ab? Ist die geschätzte Projektdauer überdurchschnittlich hoch? Gibt es Mitarbeiter im Projekt, die mit den einzusetzenden Technologien oder Produkten nicht vertraut sind? Sind die benötigten Tools noch nicht verfügbar oder funktionieren nur mit Mängeln? Sind Teile des Projekts oder des zu realisierenden Produkts technologisch schwer einschätzbar? Sind Anforderungen mit Risiken oder Unwägbarkeiten vereinbart? Sind Änderungen der Anforderungen vor dem Start zu erwarten? Sind nicht alle Anforderungen deutlich dokumentiert? Gibt es kritische Fähigkeiten, für die niemand identifiziert ist?

Tab. 9 – Risikotest (Auszug) [Kü05, S. 304]

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 39 durch ihre einfachere Berechnung aus, da sie zeitpunktbezogen ist. Sie können auch am Anfang von Analyseverfahren sinnvoll sein, wenn die strukturellen Bedingungen für die Nutzung von dynamischen Verfahren noch nicht klar ersichtlich sind. Statische Verfahren sind in dynamische Verfahren überführbar. Trotz dieser erweiterten Verfahren, bleibt das Problem, dass ein „Return on Investment“ bei IT-Produkten, IT-Projekten oder IT-Systemen schwer in monetären Größen messbar bleibt. Wesentlich für eine gute Wirtschaftlichkeitsanalyse sind das Ziel des Kunden und das Objekt der Betrachtung und die korrekte Anwendung der dafür angepassten Analysemethode. Für den Vergleich der Nutzeneffekte sollte dann eine weitere Bewertung mit der Nutzwertanalyse (NWA) durchgeführt werden. Bei dieser wird Nutzen gewichtet und bewertet. Sie dient damit der Erfassung von nicht monetär zu erfassenden Merkmalen und zum Vergleich von nicht identischen Kandidaten (z.B. in Funktionsumfang oder Einsatzart) [vgl. SH02, S. 309ff.]. Zur Durchführung der Nutzwertanalyse werden die Anforderungen an das IT-Objekt nach ihrer Bedeutung für das Unternehmen detailliert gewichtet. Bei der Definition der Gewichtungsfaktoren der NWA sollten möglichst alle Projektbeteiligten oder Produktverantwortlichen einbezogen werden. Die Bewertung qualitativen Nutzens ist stark subjektiv und muss demnach von der breiten Mehrheit befürwortet werden, um letztendlich eine „relative Objektivität“ zu erhalten. Die Summe aller Gewichtungen sollte hundert Prozent ergeben. Im Weiteren wird der Erfüllungsgrad der gewichteten Nutzenkriterien aufgestellt und priorisiert, z.B. „0 Punkte“, wenn die Anforderung nicht erfüllt, und „5 Punkte“ wenn die Anforderung vollständig erfüllt ist. Der Nutzwert des IT-Objektes errechnet sich dann prinzipiell über die Summe (Leistungspunkte x Gewichtung) mit ins Verhältnis gesetzt zum Preis bzw. den Kosten des IT-Objektes, dargestellt in folgender Abbildung (vgl. Abb. 8) [vgl. z.B. SH02, S. 309ff; ZA70].

( ) ( )

eisAngebotspr

iGewichtungiunkteLeistungsp

NNutzenwert i∑ ×

=

1

)(

)(

i = Anzahl der Merkmale

Die im Rahmen der Nutzwertanalyse verwendeten Gewichtungsverfahren unterstellen den Charakter von Substitutionsraten, d.h. es ist sinnvoll, aufgrund des subjektiven Charakters der Gewichtungen, die Nutzwerte einer Plausibilitätsprüfung zu unterziehen. So muss darauf geachtet werden, dass die Nichterfüllung eines wichtigen Kriteriums, durch die Erfüllung anderer weniger wichtiger Faktoren vollständig ersetzt wird. Bei der Anwendung der Nutzwertanalyse muss ebenfalls darauf geachtet werden, dass die Kriterien im Zusammenhang mit dem Nutzen stehen, und nicht das Kriterium an sich gewertet wird (Beispiel: Keine Bewertung nach der schnellsten Antwortzeit, sondern Bewertung der notwendigen Antwortzeit zum einwandfreien Betrieb der Anwendung). Kriterien, die einen

Abb. 8 – Nutzenwert (vereinfacht)

Diplomarbeit Volker Ritzau Kapitel 3 Erstellung eines Vergleichs- und Bewertungskriterienkatalogs Seite 40 Ausschluss der zu vergleichenden IT-Objekte zur Folge haben („no-goes“, „Killerkriterien“), fließen nicht in eine Nutzwertanalyse ein. Die Gewichtung der aufgestellten Kriterien soll durch den Kunden vorgenommen werden. Dabei soll der Kunde die erarbeiteten Kriterien auf einer Skala anhand von für ihn verständlichen Bewertungskriterien (ist mir wichtig, ist mir weniger wichtig) bewerten. Diese Bewertung wird anhand einer Nutzwertanalyse ausgewertet. Bei dieser werden die vom Kunden intuitiv beantworteten Fragen in Gewichtungsfaktoren umgewandelt. Wenn die Nutzwertanalyse durchgeführt wurde, wird diese dem Kunden wiederum vorgestellt zur Verifikation, ob er sich mit den tatsächlichen Zahlen identifizieren kann. Bei zunehmender Kompetenz und Fachwissen kann der Kunde Bewertung und Nutzwertanalyse selbst vornehmen. Der Abschluss einer Wirtschaftlichkeitsanalyse wird durch ein klar formuliertes Ergebnis anhand der ausgewerteten Kriterien vollzogen. Dies kann z.B. in der Form von „Bei Auswahl von IT-Objekt A fallen X,- EUR Kosten an und die Rentabilität wird um Y% gesteigert“ erfolgen.

3.2.2 Auswahl des Bewertungsverfahren

Im vorherigen Abschnitt wurde die Wirtschaftlichkeitsanalyse mit ihren unterschiedlichen Verfahren zur Analyse von Kosten, Nutzen und Risiko beschrieben. Die Durchführung einer alle Verfahren umfassenden Wirtschaftlichkeitsanalyse ist für die beschriebenen Projektsituationen für die der Kriterienkatalog entwickelt wird zu umfangreich. Somit werden für die Anwendung nur Teile aus dem gesamten Analyseprozess benutzt. Bei den zuvor ausgewählten Kriterien und Merkmalen eignet sich aufgrund ihrer starken Unterschiedlichkeit, die Nutzwertanalyse als Bewertungsverfahren. Sie wird im Kriterienkatalog das vorrangige Analyseverfahren sein. Die Nutzwertanalyse ist relativ schnell und präzise anwendbar, wenn erst einmal die Kriterien und ihre Gewichtungsfaktoren aufgestellt sind. Die Erhebung, um zum einen die Kriterien und zum anderen ihre Gewichtungsfaktoren festzulegen, kann unterschiedlich kompliziert gestaltet werden. Durch die hier durchgeführte Vorauswahl von sinnvollen Kriterien zur Bewertung der Technologiestacks, wird das Verfahren also vereinfacht. Bei Kunden, die eine hohe Fachkenntnis mit sich bringen und die Kriterien „verstehen“ und selbst wissen, welche Prioritäten in ihrer Unternehmung vorliegen, kann so eine Nutzwertanalyse schnell durchgeführt werden. Bei Kunden ohne ein großes Maß an Fachkenntnis, kann der Prozess durch den Faktor Informationsverständnis in die Länge gezogen werden. Andere Bewertungs- und Analyseverfahren wie die Aufstellung einer IT BSC sind in diesem Kundenumfeld nicht durchzuführen und auch aus wirtschaftlichen Gesichtspunkten nicht sinnvoll. Kennzahlensysteme liefern eine genauere Klassifizierung für die Messbarkeit der Faktoren. Das Aufstellen eines „kompletten“ Systems zur Bewertung von IT kann ebenfalls in einem solchen Projektrahmen meistens nicht geleistet werden. Einige Standardkennzahlen, die leicht abzuschätzen oder zu berechnen sind, wie z.B. Benutzerlizenzkosten (named User) können leicht in die Bewertung eingebracht werden.


3.3 Zusammenfassung der Ergebnisse Für die Bewertung der beiden SAP NetWeaver Technologiestacks wurden, aufgrund der nicht eindeutig möglichen Zuordnung dieser zu einer Kriteriengruppe, drei verschiedene Gruppen von Kriterien aufgeführt: Qualitätskriterien für Software, Kriterien zur Bewertung von IT-Architekturen und Kennzahlen der IT. Aus diesen wurde eine begründete Auswahl getroffen. Zur Auswertung und Bewertung dieser Kriterien wurde die Wirtschaftlichkeitsanalyse mit ihren verschiedenen Teilverfahren der Kosten-, Nutzen und Risikoanalyse vorgestellt. Durch die typische Projektcharakteristik in mittelständischen Unternehmen, dass möglichst kurze, prägnante und überschaubare, dabei selbstverständlich kostengünstige Verfahren zur Entscheidungsfindung benutzt werden, wurde aus den vorgestellten Verfahren die Nutzwertanalyse als gängigste Methode identifiziert und ausgewählt. Bestimmte Merkmale, wie z.B. Performanz und Laufzeitverhalten, oder auch andere Kriterien der Run Time, können hingegen vor einer Projektsituation nicht oder nur schwer von Kundenseite her getestet und ausgewertet werden. Um für die Anwendung des Kriterienkatalogs, die in Kapitel 5 vorgenommen wird, auch in dieser Hinsicht Unterstützung zu bieten werden im folgenden Kapitel 4 verschiedene softwaretechnische Implementierungen vorgenommen, ausgewertet und bewertet. Diese Implementierungen können beispielhaft in einer Kundensituation zur Verdeutlichung der Unterschiede der Technologiestacks verwendet werden und sollen hierzu dem Kriterienkatalog als Anhang beigefügt oder dem Kunden persönlich vorgestellt werden.

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 42

4 Vergleichende softwaretechnische Implementierung

Eine praktische Bewertung und Analyse der beiden Technologiestacks soll durch funktionalitätsgleiche Implementierungen verglichen werden. Die Technologiestacks bestehen jeweils aus den in Kapitel 2 dargestellten drei Schichten: Der Präsentationsschicht, der Applikationsschicht und der Persistenzschicht. Die softwaretechnische Betrachtung wird anhand von ausgewählten Merkmalen über die Schichten bzw. über die Schnittstellen der Applikationsschicht zu den anderen Schichten stattfinden. Um die vergleichenden Implementierungen in einem angemessenen Rahmen zu halten, wird jeweils ein Beispiel gesucht, das ein bestimmtes zu überprüfendes Kriterium beinhaltet. Es werden in der Arbeit also im Rahmen der Möglichkeiten Schwerpunkte zur Untermauerung der Technologieempfehlungen gesetzt. Weitere Beispiele werden im Laufe der praktischen Arbeit für das SAP-Systemhaus hinzukommen und den Kriterienkatalog anschaulich ergänzen. Die Implementierungen sind bewusst einfach und allgemein verständlich gehalten, um sie besser vergleichbar zu machen. Für die Schnittstelle zur Präsentationsschicht wird die Offenheit der JAVA-Umgebung betrachtet. Konkret wird das durch die Anbindung eines Nicht-SAP-Frameworks, dem Google Web Toolkit (GWT), auf dem JAVA-Stack getestet. Mit diesem wird ein Baustein eines schon durchgeführten Entwicklungsprojektes innerhalb des ABAP-Stack verglichen. Für die Persistenzschicht, wird das Hauptaugenmerk auf die einfache und intuitive Benutzbarkeit der Datenbankzugriffe gerichtet. Es soll die unterschiedliche Durchführung von Zugriffen auf das ABAP-Schema betrachtet werden. Als zweites wichtiges Kriterium wird die Laufzeit der Zugriffe betrachtet. Des Weiteren liefern die Implementierungen Einblicke in die verschiedenen Möglichkeiten im SAP-Umfeld zu entwickeln. Die Applikationsschicht selbst wird nicht durch Implementierung verglichen.

4.1 Präsentationsschicht Die wichtigsten Merkmale für die Präsentationsschicht im Internet, sprich die Darstellung der Anwendung im Browser, sind im Folgenden aufgeführt. Des Weiteren werden Kriterien, die bei der Entwicklung selbst auftreten aufgezählt.

Qualitative Kriterien

• Konfigurationszeit bis zum Start der Entwicklung • Vorhandene Onlinehilfe und Community • Entwicklungsaufwand der Oberfläche • Aussehen • Kompatibilität

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 43 Quantitative Kriterien

• Datenvolumen (HTTP-Request/Response) • Performanz der erstellten Seiten (gemessen an ungecachter Ladezeit)

4.1.1 Beschreibung

Im Rahmen eines Projektes des SAP-Beratungshaus wurde ein Online-Shop entwickelt. Dieser wurde auf der Basis eines SAP WAS 6.40 ECC 5.0 implementiert. Zu SAP-konformer Entwicklung stand nur der ABAP-Stack des Applikationsservers zur Verfügung. Aufgrund des Releasestands des SAP-Systems fiel die Wahl der Technologie auf BSPs. Eine vergleichende Implementierung unter Benutzung des JAVA-Technologiestacks des SAP WAS soll im Weiteren beschrieben werden. Dabei soll als Kriterium die Offenheit und Flexibilität des JAVA-Stacks überprüft werden. Dazu soll die vergleichende Implementierung nicht mit den von SAP unterstützten WebDynpros oder Java Server Pages vorgenommen werden, sondern unter Benutzung des Google Web Toolkits ein Baustein der Shopoberfläche implementiert werden. Das Hauptnavigationselement des Shops ist ein Baumelement. Dieses wurde in der produktiven Umsetzung mit dem HTMLB-Element <htmlb:tree></htmlb:tree> umgesetzt, dem eine Tabelle vom Typ „tview“ übergeben wird. 

<htmlb:tree id = "tree_productcat"

title = "<%= otr(zweb_shop_paket/

produktkatalog) %>"

table = "<%= treetab %>"

width = "260px"

toggle = "X" /> In diesem werden die Produktoberkategorien und Produktunterkategorien zur Verfügung gestellt. Man kann die Baumelemente „öffnen“ und „schließen“ und über Mausklick ein Event auslösen (Öffnen im Anzeigebereich) aus (vgl. Abb. 9).

Abb. 9 – Beispiel HTMLB-

Baumstruktur

Die Daten für den Aufbau der Produktkategorien kommen aus dem SAP ERP-System (vgl. Abb. 11). Dort werden sie in dem Geschäftsobjekt Produktkatalog gepflegt. Für dieses BO stehen verschiedene BAPIs zur Verfügung, um die Daten bearbeiten zu können (vgl. Abb. 10).


Abb. 10 – BAPI-Explorer

Abb. 11 – Layoutbereich des SAP-Geschäftsobjekts Produktkatalog

Im ABAP-Stack kann auf die BAPIs direkt zugegriffen werden. Im JAVA-Stack muss zuerst eine JCo-Verbindung zum SAP ERP hergestellt werden, um dann die BAPIs aufrufen zu können. GWT ist ein OpenSource JAVA-Entwicklungsframework, das die Asynchronous JavaScript and XML (AJAX)-Technologie benutzt. Auf den Seiten der Herausgeber, wird es wie folgt beschrieben: “GWT is an open source Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler translates your Java application to browser-compliant JavaScript and HTML.” [vgl. Go08a]. Der vom GWT erzeugte JAVA-Sourcecode ist J2SE 1.4.2 konform [vgl. Go08b]. Aufgrund der dargestellten Gegebenheiten wird für die Implementierung im JAVA-Stack erwartet, dass das Benutzerinterface (Design und Bedienoberfläche) mit dem GWT ansprechender und komfortabler bedienbar entwickelt werden kann. Dank der AJAX-Technologie sollte die Lade- und Reaktionszeit der Baumelemente performanter möglich sein. Der Zugriff auf die SAP ERP-Daten und die Anpassung der Datentypen sollte sich als komplizierter und zeitintensiver als im ABAP-Stack herausstellen. Die Erwartungen an die GWT-Oberfläche ist im Hinblick auf Performanz und Design hoch. Weiterhin wird vermutet, dass die Einbettung der GWT-Funktionalität unkompliziert auf dem J2EE-Server von SAP vorgenommen werden kann.


4.1.2 Programmierung und Ergebnisse

Im Software Developer Forum (SDN) von SAP findet man eine Kurzanleitung zur Einbettung der GWT-Logik und GWT-Klassen in das SAP NetWeaver Developer Studio. Diese Anleitung als Basis befolgend, mit Hilfe der Grundlagenbeschreibungen und Dokumentation auf den Seiten von Google war es gut möglich, die GWT-Funktionalität über ein WebProject im SAP NWDS einzubinden und zu benutzen. Beim Download des GWT Software Development Kits bekommt man einige Batchprogramme mitgeliefert. Eines davon, der „projectCreator“, unterstützt die Anlage der Grundstruktur eines Entwicklungsprojektes unter Eclipse, der „applicationCreator“ legt bei Ausführung zwei Batchdateien an: Eine mit der man seinen geschriebenen Code in einem lokalen Server ausführen, anschauen und debuggen kann, sowie eine andere zum Kompilieren des JAVA-Codes in JavaScript und HTML-Dateien.. Die Ordnerstrukturen die in folgender Tabelle (vgl. Tab. 10) aufgeführt sind werden angelegt, sowie einige Konfigurationsdateien, wie z.B. die GWT-Moduldatei, und eine HTML-Einstiegsseite Ordnerstruktur GWT-Entwicklungspaket Funktion com/c1ips/gwtclient Das Wurzelverzeichnis. Enthält Modul

XML-Konfigurationsdateien. com/c1ips/gwtclient/client Client-seitige Quelldateien und Subpakete com/c1ips/gwtclient/server Server-seitige Quelldateien und Subpakete com/c1ips/gwtclient/public Statische öffentliche Ressourcen

Im Vergleich zur Nutzung der ABAP-Stack Funktionalitäten, ist der initiale Konfigurationsaufwand bis man die erste Zeile Code schreiben kann größer. Für die Nutzung der GWT-Funktionalität an sich und der integrierten AJAX-Aufrufe, müssen verschiedene Serviceklassen implementiert werden. Die AJAX-Funktionalität bietet dabei die Möglichkeit Daten vom Server nachzuladen ohne dabei einen kompletten HTTP-Request/Response Vorgang der gesamten Seite durchlaufen zu müssen. Es wird also per Remote Procedure Call (RPC) eine Anfrage der zu bestimmenden Daten abgegeben, bei unserem Beispiel eine Unterkategorie aus dem Produktkatalog, die angeforderten Daten werden vom Server bereitgestellt und zurück gesendet. Die Übertragung über HTTP beschränkt sich also auf das Delta der aktuellen und der angeforderten Seite. Für den Aufbau der Baumstruktur bietet sich die Nutzung der AJAX Funktionalität an. So können beim initialen Laden der Seite die Oberkategorien übertragen werden und Einträge in den Unterkategorien über AJAX-Aufrufe nachgeladen werden. Das SAP HTMLB-TreeView-Element hat bei zunehmender Anzahl an Baumelementen Probleme mit der Performance. SAP empfiehlt, nicht mehr als dreißig Elemente gleichzeitig an den Baum anzuhängen. Beobachtet man den Quellcode, so erkennt man, dass für das

Tab. 10 – Standard Ordnerstrukturen eines GWT-Projekts

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 46 Element und die Gestaltung sehr viel HTML- und JavaScript-Code erzeugt wird. SAP löst dieses Problem über eine Option, die das Nachladen der Unterelemente unterstützt (toggle) (Abb. 9), dabei wird aber jeweils der komplette Baum neu geladen. Der in oben aufgeführter Abbildung generierte Baum wird mit ca. 20.500 Zeichen (ohne Leerzeichen) dargestellt. Diese Zeichen enthalten vor allem den HTML-Quellcode, die CSS-Klassen und die JavaScript-Steuerungslogik. Die in der untenstehenden Grafik (vgl. Abb. 12) gemessenen HTTP-Request/Response-Größen werden bei einem Klick auf die Produktkategorie „Getränke“ ausgelöst. Schaut man sich die detaillierte HTTP-Response an erkennt man, dass die gesamte Seite übertragen wird.

Der Vergleich mit dem generierten GWT-Baumelement gestaltet sich nicht ganz einfach, da ein Zugriff auf den HTML-Quelltext durch die GWT-Wrapper-HTML-Seite verdeckt wird. Über diese Wrapper-Seite wird der Aufruf des GWT-Moduls gesteuert. Schaut man sich die JavaScript-Funktionalitäten an, findet man eine Funktion für die initiale Baumstruktur, die nicht mehr als 10 Zeilen Code entspricht. Die gesamte Seite, wie in der nächsten Abbildung (vgl. Abb. 14) zu sehen, umfasst mit der vollen GWT-Funktionalität der asynchronen Aufrufe ca. 15.000 Zeichen. Schaut man sich im Folgenden die Response des asynchronen HTTP-Aufrufs an (vgl. Abb. 13), findet man einen einzelnen HTTP-Response, die die nachgeladenen Daten enthält.

Abb. 12 – BSP-Request „Treeclick“

Abb. 13 – GWT-Request „Treeclick"


HTTP-Response bei Aufruf des asynchronen GwtService //OK[1,["Bier;Weissbier;Alkoholfreies\x20Bier;Sekt;Prosecco;Champanger;Alko

holfreie\x20Getränke;Fruchtsäfte;Mineralwasser"],0,3]

Bei der Performanz der Seiten und der Dateigröße liefert das GWT-Modul ganz eindeutig, wie erwartet, die bessere Leistung. Schaut man sich den Entwicklungsaufwand an, wird es schwer eine objektive Bewertung zu finden. Ein routinierter JAVA-Entwickler wird keine größeren Schwierigkeiten haben, sich in der GWT API zurecht zu finden. Klare Elementdefinitionen, eine vollständige Dokumentation der Eigenschaften und Methoden machen die Entwicklung einfach. Im WWW finden sich zahlreiche Beispiele zur Umsetzung der zur Verfügung stehenden Elemente. Nichtsdestotrotz muss das Design der Seiten ohne zusätzliche Tools selbst entwickelt werden. Der Aufwand für die GwtCatalog-Applikation entsprechende CSS-Dateien zu erstellen, sowie das Baumelement mit eigenen Bildern für die Ordnerstruktur zu gestalten war im Rahmen dieser Arbeit nicht mehr möglich. Da GWT sogenannte ImageMaps unterstützt, werden sämtliche Bilder in einer HTTP-Request/Response geladen und sorgen so für eine hohe Performanz. Das GUI-Design im vorgefertigten SAP HTMLB-Framework mit Hilfe der ABAP Workbench, welche alle Elemente und Piktogramme (Icons) im passenden Design mitliefert, ist auf den ersten Blick einfacher. Über einen „Themeeditor“ können die vorhandenen Standard Themen von SAP mit der Vielzahl an CSS-Dateien browserübergreifend angepasst werden. In diesem Zusammenhang ist allerdings darauf hinzuweisen, dass es zusätzlich erwerbbare Applikationen gibt, z.B. den GWT Designer, mit dem die Gestaltung von GWT-Applikationen über einen WYSIWYG Editor möglich ist. Auch das Anpassen der CSS-Dateien soll darüber stark vereinfacht sein [vgl. In08]. Ein Test dieser zusätzlichen Applikationen war hier nicht möglich.

Abb. 14 – Beispiel GWT-Baumstruktur

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 48 Das Standard-Erscheinungsbild der GWT-Widgets und Komponenten ist schlicht, kann aber nach Belieben, mit dem zuvor beschriebenen Aufwand, angepasst werden. Die eigentliche GWT-Applikation wird im SAP NWDS über ein Web Application Project gesteuert (vgl. Abb. 15). In diesem legt man die clientseitigen und serverseitigen Klassen an. Für den RPC-Aufruf sollten zwei Interfaces (hier IGwtService und IGwtServiceAsync) angelegt werden, welche durch die eigentlichen Anwendungsklassen implementiert werden, um die asynchrone Kommunikation möglich zu machen.

Das erstellte Web Application Project wird einem Enterprise Application Project (vgl. Abb. 16) zugeordnet. Nach Benutzung des GWT-Compilers, wird das Enterprise Application Project auf der J2EE-Engine deployed. Die Standardeinstiegsseite (hier GwtCatalog.html) kann dann in dem öffentlichen Webverzeichnis aufgerufen werden. Das Testen der GWT-Anwendung kann im „hosted“ mode vorgenommen werden, einem lokalen GWT-Entwicklungsserver. Die für die J2EE-Engine benötigten Klassen zur Unterstützung der GWT-Funktionalität können über ein „Libraryprojekt“ (hier: com.c1ips.gwtbase.lib) auf die J2EE-Engine übertragen und referenziert werden. Zur browserübergreifenden Kompatibilität findet man auf den GWT-Internetseiten [vgl. Go08b] die Aussage, dass die Google Widgets und Komponenten bei den gängigen Browsern (Internet Explorer, Firefox, Safari) keine Probleme verursachen. Entwickelt man eigenen UI-Elemente oder Komponenten, ist ein Test mit verschiedenen Browsern unumgänglich. SAP garantiert eine komplette Nutzung der BSP und WebDynpro Webfunktionalitäten für den Internet Explorer (zurzeit noch teilweise eingeschränkt für Version 7). Bei WebDynpros und der Portalumgebung gibt es in den SAP-Hinweisen aufgeführte Inkompatibilitäten mit Firefox.

Abb. 15 – com.c1ips.gwtcatalog Paketstruktur Abb. 16 – GwtbaseEAR Enterprise Application Project


4.1.3 Auswertung

SAP bietet im eigenen Software Developer Forum eine gute Community an interessierten und fachlich kompetenten Softwareentwicklern. Für das GWT standen Unterlagen zur Verfügung und auch zu anderen OpenSource-Produkten, die mit SAP-Systemen gekoppelt werden oder integriert werden, gibt es Beschreibungen oder Erfahrungsberichte. Diese Dokumentationen und das Forum bieten eine gute Wissens- und Hilfebasis zur erweiterten Nutzung des JAVA-Stacks, werden aber meistens nicht offiziell von SAP unterstützt. Dies hat zur Folge, dass keine Gewährleistung gegeben und auch kein Support von SAP geleistet wird. Beispiele hierfür sind die Nutzung des GWT oder auch ein anderes SAP-Community-Projekt, Flex over BSPs (FLOBS), mit dem die Einbettung von AJAX-Funktionalität im BSP-Umfeld untersucht wird. Der J2EE-Server auf dem SAP WAS ist, wie erwartet, in den getesteten Bereichen Standardkonform zu dem implementierten J2EE-Standard und verhält sich in Punkten Offenheit und Integration anderer J2EE-Komponenten wie bei dem getesteten GWT pflegeleicht. Da das SAP NWDS auf der OpenSource-Plattform Eclipse beruht, ist die Integration der GWT-Klassen kein Hindernis. Wie bereits erwähnt, ist ein erhöhter initialer Konfigurationsaufwand im Vergleich zur Programmierung im ABAP-Stack zu leisten. SAP gibt über den JAVA-Stack die Möglichkeit die Präsentationsschicht mit allen denkbaren Mitteln nach Belieben zu gestalten. Im Kontext von Geschäftsanwendungen müssen die Entscheidungsträger die Balance zwischen der Notwendigkeit einer voll anpassbaren GUI und der effizienten Umsetzung einer stabilen, praktikablen und von SAP unterstützten und eingebetteten Lösung wahren.


4.2 Persistenzschicht (ABAP-Schema) Ein Standardszenario im SAP-(Web-)Entwicklungsumfeld beinhaltet den Zugriff einer (Web-) Applikation auf ein SAP ERP-System. Das bedeutet ein Zugriff auf das ABAP-Schema der Datenbasis muss erfolgen. Dieser Zugriff auf die ABAP-Datenbasis ist bei JAVA-Programmen über SAP Konnektoren (hier: JCo; vgl. Kapitel 2.3.3) zu ermöglichen. Eine JAVA-Applikation wird beim Zugriff also ähnlich einem Nicht-SAP-Programm behandelt und hat nicht die Möglichkeit direkt auf die Daten zuzugreifen, sondern muss remotefähige Funktionsbausteine oder BAPIs benutzen, die wiederum den eigentlichen Datenzugriff per SQL durchführen. Über das SAP NWDS sind diese Zugriffe in ihrem Komfort verbessert worden. Der SAP Enterprise Connector ist ein Hilfsmittel, mit dem automatisiert Proxyklassen zur Nutzung von BAPIs und RFC-fähigen Funktionsbausteinen erstellt werden können. Für die folgenden Implementierungen wird eine Datenbanktabelle auf die der Zugriffe erfolgt aus dem Standardschulungsszenario von SAP ausgewählt, da es hierfür die Möglichkeit gibt Testdatensätze zu generieren. Zur Bewertung der Persistenzzugriffe werden folgende qualitative und quantitative Kriterien benutzt: Qualitative Kriterien

• Programmieraufwand des Zugriffes • Einfachheit der Verarbeitung der gewonnen Daten (Anlegen, Konvertieren von

Datentypen, usw.) • Unterstützung durch Muster oder Automatismen bei der Entwicklung

Quantitative Kriterien

• Laufzeit Die Laufzeit als einziges quantitatives Kriterium gibt hier nicht die Laufzeit des SQL-Zugriffs im eigentlichen Sinn an. Bei der Laufzeit wird die Programmlaufzeit, der bei den JAVA-Applikationen nötige JCo-Verbindungsaufbau und -abbau, die Ausführung des RFCs und die Laufzeit der Ausgabe der gewonnen Daten gemessen. Die Messungen sollen Aufschluss über den Zusatzaufwand für die Verwaltung der JCo-Verbindungen geben. Des Weiteren wird sich zeigen, ob der externe Aufruf des RFC-Bausteins im Gegensatz zum systeminternen Aufruf einen messbaren Unterschied in der Verarbeitungsgeschwindigkeit mit sich bringt. Die Geschwindigkeit der Ausgabe ist hier nur nebensächlich, da das Hauptaugenmerk auf der Datenbeschaffung liegt.


4.2.1 Beschreibung

SAP hat für Testprogramme, Schulungen und Beispiele ein Standardszenario von Flugbuchungen konstruiert. Dieses Szenario soll hier nicht als Buchungsszenario benutzt werden, sondern dient lediglich dazu eine Standarddatenbanktabelle „SFLIGHT“ mit Testdatensätzen, hier Verbindungsdaten von Flügen, zur Verfügung zu stellen. Die Auswahl ist auf diese Standardtabelle gefallen, da es in jedem SAP-System die entsprechenden Datenelemente und Datenstrukturen gibt, Standardreporte zur Erstellung von Testdaten zur Verfügung stehen und BAPIs zum Zugriff auf diese Daten existieren. Der Persistenzzugriff wird an fünf Programmen verglichen. Ein einfacher ABAP Report, ein RFC-fähiger Funktionsbaustein, eine BSP-Seite, die den RFC-fähigen Funktionsbaustein ruft, eine JAVA-Klasse mit selbst realisiertem und reguliertem Zugriff und einer JAVA-Klasse mit einem über den SAP Enterprise Connector realisierten Zugriff (vgl. Tab. 11). Vergleichsobjekt Beschreibung ABAP Report „ZSQL“ Nativer SQL-Zugriff ABAP BAPI „ZBAPI_WRAPPER_SQLSFLIGHT”

SQL-Zugriff über remotefähigem Baustein gekapselt

BSP-Seite „ZBAP_TEST“ BSP-Seite, die den remotefähigen Baustein ruft und im Browser ausgibt

JAVA WebProject WebSQLTest Klasse SQLTest

Selber erstellte und verwaltete direkte JCo-Verbindung, Aufruf des remotefähigen Bausteins über JCo-Funktionsobjekt

JAVA WebProject WebSQLTest Klasse EnterpriseConnect

Selbst erstellte und verwaltete direkte JCo-Verbindung, über SAP Enterprise Connector realisierter Aufruf des remotefähigen Bausteins

Zu beachten bei der Laufzeitanalyse ist der Systemcache. Die Erstausführung eines Programms kann um einiges erhöht sein, als bei folgenden Aufrufen, da bestimmte Tabellen- oder Strukturdefinitionen für Im- und Export vorgeladen werden. Die hier gemessenen Aufrufe sind alle in diesem Sinn gecachte Aufrufe, da eine explizite Cachekontrolle für ABAP- und JAVA-Stack nicht möglich war. Der Zugriff aus dem ABAP-Stack, wird im ersten Beispiel über ein Programm mit einem direkten SQL-Statement durchgeführt. Die Daten werden in eine interne Tabelle geschrieben und auf einfachste Weise am Bildschirm ausgegeben. Für das ABAP-Programm wird die Laufzeit über die im ABAP-Stack integrierte Laufzeitanalysefunktion gemessen. Die Ausgabe des Programms wird auszugsweise zur Verdeutlichung in nebenstehender Grafik (vgl. Abb.

Tab. 11 – Vergleichsobjekte für den Persistenzzugriff

Abb. 17 – Ausgabe ZSQL

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 52 17) gezeigt. Es wurden 1.863 Datensätze ausgegeben. Der Quelltext des Programms ZSQL ist zur Vollständigkeit im Anhang aufgeführt (vgl. Anhang Quelltexte (B)).

Die Laufzeitmessung des Programms ZSQL ergibt 42.803 Mikrosekunden. Die Messung wird in die Teile Laufzeit des Programms, Laufzeit des Datenbankzugriffs und die Laufzeit des Systems unterteilt. Das eigentliche SQL-Statement beansprucht ca. 30% der Laufzeit. Der Hauptteil wird mit 62% durch die Aufbereitung der Daten und der Bildschirmausgabe ausgemacht. Ändert man das Programm in sofern ab, dass nur noch das SQL-Statement ausgeführt wird und die gelesenen Daten einfach in einer internen Tabelle gespeichert werden, wird eine Laufzeit von ca. 5.000 Mikrosekunden erreicht. Diese Unterscheidung ist deshalb wichtig, da das zweite Testobjekt genau so funktionieren wird. Es wird das SQL-Statement ausgeführt und als Export bzw. Rückgabeparameter eine Tabellenstruktur übergeben. Das zweite ABAP-Testobjekt ist als RFC-fähiger Funktionsbaustein „ZBAPI_WRAPPER_SQLSFLIGHT“ geschrieben. Hierbei ist zu beachten, dass dieser als „sofort auszuführen“ definiert wird. Es gibt die Möglichkeit Verbuchungsbausteine zu entwickeln, diese nehmen die tatsächlichen Änderungen in der Datenbank nicht unbedingt sofort, sondern nur zu bestimmten Zeitpunkten vor. Ein Funktionsbaustein kann im SAP-System selbst getestet werden. Beim Aufruf wird die Laufzeit des Zugriffs direkt angezeigt. Das Ausführen des

Abb. 18 – Laufzeitanalyse ZSQL

Abb. 19 – Test RFC-Funktionsbaustein ZBAPI_WRAPPER_SQLSFLIGHT

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 53 SQL-Statements als remotefähiger Baustein liefert in etwa die gleiche Performance. Die Rückgabeparameter stehen ebenfalls nach ca. 5.000 Mikrosekunden zur Verfügung (vgl. Abb. 19). Dies ist eine gute Vorraussetzung für den Vergleich zwischen einem ABAP-Aufruf des Bausteins und einem JAVA-Aufruf, da die Performance nicht durch den RFC-Baustein selbst verändert wird. Das dritte ABAP-Programm – eine BSP-Seite – wird als Vergleich für Webapplikationen herangezogen. Die BSP-Seite ist von der Ausgabehandhabung im Browser mit Java Server Pages zu vergleichen. Beide sind z.B. scriptfähig. Die BSP-Seiten haben durch ihre EventHandler allerdings eher noch den Zusatzcharakter von Servlets. Die Ausgabe geschieht über HTML bzw. HTMLB. Da die BSP Funktionalität im ABAP-Stack integriert ist, ist keine Besonderheit im Typenhandling, wie bei den JAVA-Applikationen zu beachten. Zur Laufzeitmessung stellt SAP eine BSP-Extension „Benchmark“ zur Verfügung, die die Zeit zur Berechnung des „Body“ in Millisekunden ausgibt. Hier bietet es sich an zwei Tests mit der BSP durchzuführen. Einmal mit einem RFC über seitenbasiertes Scripting, und einmal ein Aufruf des RFCs in dem EventHandler OnRequest. Zu erwarten ist, dass sich der Benchmark hierdurch um ca. 5 Millisekunden unterscheidet, da das Ausführen des eigentlichen RFC-Funktionsbausteins mit 5 Milisekunden gemessen wurde. Das Ergebnis der BSP-Benchmarks, liegt nach mehreren Messungen genau in dieser Erwartung. bei ca. 61.250 Mikrosekunden für die EventHandler-Methode, und bei ca. 65.500 Mikrosekunden für die scriptbasierte Version (vgl. Tab. 12 & Abb. 20). Diese drei ABAP-Programme werden als Vergleichsobjekte zu den zu erstellenden JAVA-Klassen herangezogen.

BSP-Benchmarks Versuch Seitenbasiert EventHandler 1 65021 62836 2 64589 61880 3 65115 62175 4 65922 60682 5 65573 60560 6 65135 63169 7 65484 60227 8 67500 60768 9 66526 60431 10 64682 59802 Mittel 65554,7 61253

Tab. 12 – BSP-Benchmarks

Abb. 20 – Beispiel BSP-Benchmark

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 54 Die JAVA-Programme werden in einem Webmodul angelegt. Dieser Projektcontainer, zugehörig zum J2EE-Toolset, bietet den Rahmen zur Entwicklung von browserfähigen Anwendungen (vgl. Abb. 21).

Es werden z.B. XML-Konfigurationsdateien (Deployment Desriptors) angelegt, über die bestimmte Applikationsparameter gesteuert werden. Dieser Projektstruktur inhärent ist die jeweilige Erstellung (Building) der Webarchive (WAR) und des Enterprise Application Archivs (EAR) und dem abschließendem Deployment auf die J2EE-Engine. Zur Herstellung der JCo-Verbindung wird eine JAVA-Klasse benutzt. Die Funktionsaufrufe werden über ein JAVA-Servlet durchgeführt, die Ausgabe der erhaltenen Daten erfolgt in selbigem. Es wurde auf Techniken wie Enterprise JavaBeans verzichtet, um eine möglichst einfache Architektur abzubilden. Der JAVA-Stack bietet verschiedene Möglichkeiten, RFC-fähige Funktionsbausteine aufzurufen und zu verarbeiten (vgl. Kapitel 2.3.3 & 2.3.6). Bei den folgenden JAVA-Implementierungen werden nur direkte JCo-Verbindungen benutzt. Die erste JAVA-Applikation benutzt die JCo-eigenen Möglichkeiten, RFC-Funktionen aufzurufen, die zweite JAVA-Applikation benutzt das Werkzeug des SAP Enterprise Connectors, der den Entwickler durch die automatische Generierung von Proxyklassen bei der Typisierung und dem Datenhandling unterstützt. Die Ergebnisse der Entwicklung und des Vergleichs werden im folgenden Abschnitt dargelegt.

Abb. 21– Zusammenhänge des J2EE-Toolsets


4.2.2 Programmierung und Ergebnisse

Für die Entwicklung der JAVA-Applikationen muss ein installiertes und konfiguriertes SAP NWDS zur Verfügung stehen. Dieses braucht über den Software Deployment Manager eine Verbindung zur J2EE-Engine. Um Fehler zu vermeiden ist es am einfachsten, wenn das SAP NWDS und die J2EE-Engine vom gleichen Servicepackstand sind. Ist dies nicht der Fall, so sollten die benötigten JAVA-Archive am Besten von der J2EE-Engine in die Entwicklungsprojekte mit aufgenommen und als Bibliotheken eingebunden werden. So werden Kompatibilitätsprobleme vermieden. Der erste Schritt zur Realisierung der RFC-Aufrufe ist die Verbindungsherstellung zum Remotesystem. Dafür wird eine Hilfsklasse geschrieben, die ein JCO.Client-Objekt anlegt und zur Verfügung stellt. Dazu werden in dieser die notwendigen Verbindungsparameter hinterlegt (vgl. Tab. 13). Bei der Benutzung einzelner Verbindungen muss der Entwickler darauf achten die Verbindungen zu erstellen, zu aktivieren, zu deaktivieren und abzubauen. Hierzu wird die Hilfsklasse instantiiert, an dem zur Verfügung stehenden JCo.Client-Objekts wird eine Verbindung hergestellt und nach Aufruf des RFC-fähigen Funktionsbausteins wieder unterbrochen. Als nächstes wird über den JCO.Client ein Funktionsobjekt JCO.Client.Function über den Namen des RFC-fähigen Funktionsbausteins erstellt. Bei der Objektanlage wird im Remotesystem überprüft, ob der RFC-Funktionsbaustein zur Verfügung steht. Ist dies der Fall, werden die Metadaten übergeben. Als nächstes kann die Funktion ausgeführt werden. Die in diesem Fall zurückgegebene Tabelle wird nun ausgelesen. Hierbei ist auf die Typisierung zu achten. Das JCo-Objekt stellt anhand einer Zuordnungstabelle (Mapping [vgl. SAP08i]) für jeden ABAP-Datentyp eine spezifische Getter-Methode zur Verfügung. Für die Bearbeitung von Tabellenobjekten werden zusätzliche Funktionen zur Verfügung gestellt. Die Ausgabe auf dem Browser erfolgt über ein Standard Ausgabe Objekt, einen „PrintWriter“. Für die Auswertung der Laufzeit gibt es keine integrierte Laufzeitanalyse. Die Messdaten müssen also durch eigenes Messen der Systemzeit in Millisekunden, über die Systemfunktion currentTimeMillis() erfolgen. Zur besseren Vergleichbarkeit wird die Laufzeit erst ab JCo-Verbindungsaufbau gemessen und im Folgenden an den Messpunkten: RFC-Funktionsaufruf, Datenausgabe, Verbindungsabbau.

JCo-Verbindungsparameter

SAP-Mandant

SAP-Benutzer

Benutzerpasswort

Anmeldesprache

Host des Applikationsservers

SAP-Systemnummer

Tab. 13 – JCo-Verbindungsparameter

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 56 Für eine erste Bewertung wird das Programm zehn Mal ausgeführt. Die Messung ergibt folgende Ergebnisse, alle Angaben in Millisekunden:

Laufzeitverhalten bei Nutzung der JCo.Client.Function Versuch Laufzeit RFC-Aufruf JCo+ JCo-

(1) (296) (141) (39) (13) 2 167 39 13 0 3 102 13 12 0 4 146 14 15 15 5 219 59 29 14 6 161 15 29 15 7 131 15 14 15 8 161 15 44 15 9 160 14 44 14

10 138 30 16 16 11 90 12 13 13

Mittel (2-11) 147,5 22,6 22,9 11,7

Man kann erkennen an den in der Tabelle (vgl. Tab. 14) abgebildeten Messwerte, dass jeweils beim ersten Aufruf der JAVA-Applikation ein deutlicher Unterschied zu den folgenden Aufrufen festzustellen ist. Dieses teilweise erheblich längere Laufzeitverhalten ist wie auch schon bei den Aufrufen des RFC-fähigen Funktionsbausteins im Remotesystem unter anderem durch das auf den Erstaufruf folgende Caching von z.B. Tabellentypen zu erklären. Der erste Aufruf sollte deshalb aus der Betrachtung heraus gelassen werden. Das Messen der Laufzeit ist bei dieser Methode evtl. einigen Problemen unterstellt. So können z.B. ein laufender GarbageCollector oder auch einfach Unregelmäßigkeiten bei der Netzwerkverbindung und die Auslastung der J2EE-Engine das Verhalten beeinflussen. Dadurch lassen sich starke „Spitzen“ bei den Werten durchaus erklären. Das zweite Applikationsbeispiel ist einfacher zu programmieren. Über einen Assistenten, der den Zielort (JAR oder Package) sowie die Anmeldung an dem Remotesystem als Eingaben benötigt, kann man nach Auswahl des gewünschten RFC-fähigen Funktionsbausteins (vgl. Abb. 22) die Proxyklassen generieren lassen.

Tab. 14 – Laufzeitverhalten mit JCo.Client.Function


Es werden fünf Proxyklassen generiert. Die Hauptklasse über die die Ausführung des RFCs durchgeführt wird und verschiedene Hilfsklassen zur Typisierung der Funktion und der Eingabe- und Ausgabeparameter. Diese Hilfsklassen stellen Setter-/Gettermethoden zur Bearbeitung der Daten zur Verfügung. Das notwendige Datenmapping der ABAP- nach JAVA-Typen, sowie die zusätzliche Strukturen (z.B. „bapireturn“) wird aus den Metadaten ausgelesen und innerhalb dieser Klassen automatisch angelegt. Eine Aufstellung der generierten Klassen findet sich in der folgenden Tabelle (vgl. Tab. 15). Generierte Klasse Beschreibung SFLIGHT_PortProxy Proxyklasse zum Aufruf der RFC-Funktion SflightType Typdefinition der RFC-Funktion,

Datenmapping, Setter/Getter-Methoden Zbapi_Wrapper_Sflight_Input Input-Parameter Zbapi_Wrapper_Sflight_Output Output-Parameter SflightType_List Utility Klasse, Typdefinition als Liste

Der eigentliche Aufruf der RFC-Funktion folgt dem folgenden Ablauf: 1) Hilfsklasse für JCo-Verbindung instantiieren, dadurch JCo.Client-Objekt anlegen 2) Proxy-Klasse instantiieren, JCo.Client-Objekt übergeben 3) Eingabe- und Ausgabeparameter-Klassen instantiieren, evtl. Eingabeparameter setzen 4) Aufruf der RFC-Funktion am Proxyobjekt, Eingabeparameter übergeben,

Ausgabeparameter empfangen 5) Ausgabeparameter verarbeiten 6) JCo-Verbindung schließen

Abb. 22 – Enterprise Connector - Select RFC Module

Tab. 15 – Aufstellung der generierten Klassen des SAP Enterprise Connectors

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 58 Die Messdaten werden nach dem gleichen Muster wie bei der ersten Implementierung erhoben. Sie ergeben die folgenden Werte (vgl. Tab. 16):

Laufzeitverhalten bei Nutzung des SAP Enterprise Connectors Versuch Laufzeit RFC-Aufruf JCo+ JCo-

(1) (3231) (213) (0) (15) 2 167 15 15 15 3 137 15 0 0 4 137 15 15 15 5 244 16 15 15 6 183 15 0 15 7 124 16 0 16 8 139 15 0 0 9 123 15 0 0

10 123 15 0 15 11 93 16 15 16

Mittel (2-11) 147 15,3 6 10,7

Der Unterschied in der Programmierung der beiden JAVA-Beispiele ist in diesem Beispielfall nicht erheblich, da der aufgerufene RFC-fähige Funktionsbaustein, durch seinen einzigen tabellenartigen Exportparameter sehr einfach gehalten wurde. Ein echter Vorteil des SAP Enterprise Connectors kommt erst mit zunehmender Komplexität der aus dem RFC-System zu holenden und zu übergebenden Daten zum tragen. Schaut man sich z.B. einen BAPI zum Anlegen von Verkaufsbelegen an („BAPI_SALESORDER_CREATE-FROMDAT2“), so müssten im Extremfall bei dessen Aufruf über 20 Strukturen und Tabellen übergeben werden. Für jede dieser Parameter, müssten die entsprechenden Objekte mit Typisierungen für die Übergabe angelegt werden (vgl. Anhang Quelltexte (B)). Der Zeitaufwand und die Fehleranfälligkeit sind dabei nicht zu unterschätzen. Für den mit remotefähigen ABAP-Funktionsbausteinen bekannten JAVA-Entwickler sind beide Verfahren gut handhabbare Lösungen. Der SAP Enterprise Connector macht es allerdings auch für JAVA-Entwickler, die keine Erfahrung im Umgang mit SAP-Systemen haben, leicht möglich auf die gängigen Businessobjekte und RFC-fähigen Funktionsbausteine zuzugreifen.

4.2.3 Auswertung

Der Vergleich der RFC-Aufrufe bringt keine Überraschungen mit sich. Befindet man sich im ABAP-Stack ist es leichter möglich Daten zu schreiben und zu lesen und Berichte daraus zu erstellen, da ein direkter Zugriff gewährleistet ist. Diese Zugriffe sind in ihrer Art und von ihrem Zugriff stark optimiert, des Weiteren ist ABAP gerade auf die Verarbeitung von Tabellendaten ausgelegt. Mit den internen Tabellen und den darauf basierenden Befehlssätzen

Tab. 16 – Laufzeitverhalten mit SAP Enterprise Connector

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 59 wird dem ABAP-Entwickler ein mächtiges Werkzeug zur Verarbeitung von Datenbankzugriffen gegeben. Die Datenbankzugriffe selbst werden in einem SQL-Subset programmiert, welches alle gängigen Funktionen bietet. Die Entwicklung mit normalen ABAP Reports oder BSPs benötigt keine zusätzlichen Installationen oder Konfigurationen von Seiten des Entwicklers. Die Programme und Seiten können schnell angelegt werden und sind im System auf ihre Funktionalität und Leistung hin überprüfbar. Für die Entwicklung von komplexen eigenen Anwendungen, d.h. mit einem komplett eigenen Datenschema und eigener Anwendungslogik, wird dem Entwickler allerdings im Gegensatz zur JAVA-Umgebung kein eigenes in sich geschlossenes Entwicklungsframework wie Enterprise JavaBeans zur Seite gestellt. Dies liegt daran, dass die ABAP-Programmierung von ihrer eigentlichen Bedeutung her die Möglichkeit gibt das ERP System zu erweitern, anzupassen und zu modifizieren. Befindet man sich mit der Entwicklung im Bereich des Business Object Repositories (BOR), stehen alle Türen offen. Verwiesen sei hier noch einmal auf das bereits erwähnte WebDynpro Framework (vgl. Kapitel 2.3.5), mit dem in die Richtung der einfachen Abbildung komplexer (Web-)Anwendungen und Abläufe im ABAP-Stack gegangen wird. Der über JAVA erwartete komplizierte Zugriff auf das ABAP-Schema hat sich als gut lösbar und – über angebotene Hilfsmittel als sehr komfortabel gestaltbar – herausgestellt. Steht erst einmal ein SAP NWDS und eine J2EE-Engine in der gleichen Version zur Verfügung, sind Zugriffe einfach realisierbar. In der folgenden Tabelle sind die Zugriffszeiten der einzelnen Programme noch einmal gegenübergestellt. Es wird der eigentliche RFC-Aufruf als Referenz betrachtet. RFC-Aufruf Laufzeit ABAP RFC ca. 5ms ABAP RFC über BSP ca. 5ms RFC-Aufruf über JCo.Client.Function ca. 22ms RFC-Aufruf über SAP Enterprise Connector ca. 15ms Referenz nativer ABAP SQL Select ca. 5ms

Die Laufzeit unterscheidet sich ca. um den Faktor drei bis vier. Dies ist in Hinblick auf das Szenario ein gutes Ergebnis. Um eine spezifischere und gesicherte Aussage zu erlangen, sollten die Tests in folgender Weise erweitert werden:

• Einführung eines Automatismus (z.B. über das JUnit-Framework) • Erhöhung der Testläufe • Größere und unterschiedliche Datenvolumina testen

Diese Ausarbeitung der Tests war im Rahmen dieser Arbeit nicht möglich.

Tab. 17 – Gegenüberstellung der RFC-Laufzeiten

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 60 Als mögliche Erweiterung sollte man auch den Test mit JCo-Verbindungspools durchführen, um den daraus resultierenden Nutzen an klaren Zahlen darzustellen. Zusammenfassend kann man zu den JAVA-Zugriffen auf die ABAP-Persistenzschicht sagen, dass diese mit den zur Verfügung stehenden Hilfsmitteln in annehmbarer Zeit und in einem angemessen Aufwand durchgeführt werden können.

4.3 Zusammenfassung der Ergebnisse Die in den vorangegangenen Abschnitten durchgeführten Vergleichsimplementierungen zeigen vor allem die folgenden drei Dinge: SAP hält in den Punkten Offenheit und Standardisierung, in Bezug auf den implementierten JAVA-Stack, was sie versprochen hat. Durch die Implementierung einer Vielzahl von neuen Technologien (vgl. Kapitel 2.2 & 2.3.6) auf Basis des JAVA-Stacks gibt es eine ebenso wachsende Zahl an eingängigen Hilfsmittel, Assistenten und Werkzeugen, die die Entwicklung im JAVA-Bereich sehr komfortabel machen. Gerade die untersuchte Schnittstelle zum ABAP-Backend ist über die SAP Konnektoren einfach benutzbar implementiert und wird ständig weiter verbessert, optimiert und vereinfacht. Sind die Anforderungen an die Anwendungsentwicklung eine „einfache“ Erweiterung des SAP Business Frameworks (vgl. Kapitel 2.1), so ist eine Lösung schnell und mit geringem Aufwand über verschiedene Möglichkeiten im ABAP WAS voll und ganz zu realisieren. Diese Lösungen bringen einen hohe Performanz und Stabilität mit sich, die eine vergleichbare JAVA-Implementierung voraussichtlich nur schwer erreichen kann. Ist eine komplexe Anwendung gefordert, wobei komplex meint, dass sie eine ganz eigene Logik beinhaltet, die auf unterschiedliche heterogene IT-Ressourcen zugreifen muss, macht einem der JAVA-Stack durch die bereits erwähnte Offenheit vieles leichter. Nicht nur der Zugriff auf das SAP ERP, sonder auch die Integration über Web Services oder andere generische Schnittstellen ist Sinn und Zweck der JAVA-Lösungen. Als Dritter Punkt sei der vorherrschende „quasi“ Designstandard im WWW aufgezeigt. Das öffentliche Internet hat am 30. April 2008 seinen 15. Geburtstag gefeiert [z.B. vgl. MSN08, SCH08]. Fünfzehn Jahre der Entwicklung liegen zwischen einer einfachen textbasierten Oberfläche zum vollanimierten und dynamischen Multimediamedium. Im Vergleich dazu zeichnen sich Lösungen und Anwendungen die mit dem ABAP-Stack entwickelt sind, als eher praktisch und funktional aus, denn als optisch vollendet. Möchte man eine moderne Lösung einsetzen mit allen im Internet zur Verfügung stehenden „Features und Gadgets“ sollte die Präferenz bei der Implementierung im JAVA-Stack liegen. Hierbei sei revidierend angeführt, dass der Hauptanspruch eines ERP Systems gerade in den genannten Bereichen Performanz und Stabilität liegt und das „Look & Feel“ eher auf hinteren Plätzen rangiert. Zudem muss an dieser Stelle noch einmal klar gestellt werden, dass im Zusammenspiel mit einem SAP ERP-System JAVA-Anwendungen ohne das entsprechende ABAP-Backend in Form von BAPIs und Funktionsbausteinen keinesfalls auskommen. Außerdem muss klar sein, dass SAP es sich nicht zur Aufgabe macht jeden Trend in der JAVA-Entwicklung zu

Diplomarbeit Volker Ritzau Kapitel 4 Vergleichende softwaretechnische Implementierung Seite 61 unterstützen, geschweige denn Gewährleistung dafür zu übernehmen. SAP-Standards werden durch SAP definiert. Mit den so gewonnen Erkenntnissen aus den vergleichenden Implementierungen wird die Anwendung des in Kapitel 3 aufgestellten Kriterienkatalogs unterstützt. Anhand einer konkreten Projektsituation wird im folgenden Kapitel 5 der Kriterienkatalog angewendet. Für Merkmale, die vor oder während der Projektsituation von Kundenseite her schwer oder unzureichend bewertet werden können, sollen die durchgeführten Implementierungen als anschauliche Beispiele dienen.

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 62

5 Aufstellung und Anwendung des Kriterienkatalogs Im folgenden Kapitel wird der Kriterienkatalog anhand einer konkreten Projektsituation angewandt. Hierzu wird zuerst die Kundenanforderung des Projektes eines mittelständische Unternehmens kurz beschrieben und dargestellt. Eine Kurzvorstellung des Mittelstandsbetriebs findet anonymisiert statt. Anhand dieser Darstellungen werden die Schlüsselindikatoren für die Projektsituation aufgestellt und gewichtet. Auf Grundlage dessen werden die Kriterien ausgewertet und eine Technologieempfehlung gegeben. Anzumerken bei der Anwendung innerhalb dieser Arbeit ist, dass sich das beschriebene Projekt in bestimmten Bereichen in der Spezifikationsphase befindet. Dies hat zur Folge, dass bestimmte Annahmen und Bewertungen innerhalb dieses Arbeitsabschnitts unter Unsicherheit getroffen werden. Des Weiteren sind bestimmte Aspekte, insbesondere Zeitschätzungen und Preise in soweit abgeändert, dass sie nicht den konkreten Aufwand und die Zeit im Rahmen des Projektes wiedergeben. Es wurde aber darauf geachtet, dass die auftretenden Relationen beibehalten werden.

5.1 Vorstellung der Projektsituation Ein mittelständischer Elektronikbetrieb beabsichtigt zur Unterstützung des Fertigungsprozesses eine Applikation einzuführen, über die auftragsbezogene Daten über einen Web-Browser im Firmennetzwerk abgerufen und ausgegeben sowie bearbeitet und rückgemeldet werden können. Die Applikation soll die Bereitstellung der notwendigen Artikel aus dem Hauptlager sowie aus den Produktionslagern unterstützen, zum einen bei der Bereitstellungsplanung, zum anderen bei der Abwicklung der Bereitstellung - voraussichtlich über mobile Handscanner. Im weiteren Verlauf des Fertigungsprozesses sollen auftragsbezogene Statusinformationen zur Verfügung stehen und die Auftragsverteilung an verschiedene Bearbeiter koordiniert werden. Die Auftragsbearbeitungsplanung wird ähnlich der Bereitstellungsplanung unterstützt, d.h. der Planer verteilt die anstehenden Aufträge auf die zur Verfügung stehenden Mitarbeiter. Dem Planer wird eine ständige und aktuelle Übersicht über die verteilten Aufträge und ihren Bearbeitungsstatus gegeben. Die Vorgangsbearbeitung soll in der Form umgesetzt werden, dass die Rückmeldung der einzelnen Produkte des Fertigungsauftrages pro Arbeitsvorgang ermöglicht wird. Weiterhin sollen für den Bearbeiter am jeweils aktuellen Vorgang Dokumente zur Fertigungsunterstützung aus dem in der Einführung befindlichen Dokumentenmanagementsystem (DMS) zur Verfügung gestellt werden Während des gesamten Fertigungsprozesses haben Planer und Bereitsteller die Möglichkeit Meldungen für das Qualitätsmanagement anzulegen.

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 63 Letztendlich werden die Arbeitsvorgänge bzw. mit dem letzten Arbeitsvorgang der Fertigungsauftrag als vollständig bearbeitet zurück gemeldet (Endrückmeldung). Die Fertigerzeugnisse werden mit der Endrückmeldung in das Fertiglager gebucht. Eine weitere Fachabteilung soll die Applikation nutzen, um einen Strukturaufbau von Geräten und Anlagen durchzuführen. Das bedeutet, dass bei der Fertigung die mit Seriennummern versehenen Bauteile als Unterequipments in Geräte und Anlagen eingebaut werden. Die Bauteile werden über Barcodes eingescannt und im SAP-System dem entsprechenden Oberequipment zugeordnet. Dieser für sich stehende Prozess wird ebenfalls aufgenommen, da in bestimmten Fällen während der Fertigung ein Strukturaufbau vorgenommen werden muss. Ziele der Einführung sind eine Verbesserung des Fertigungsprozesses und eine Verbesserung des Kundenservices bei Wartungsarbeiten und Instandsetzungsarbeiten. Durch das Scannen der Bauteile und das Rückmelden der Produkte während der Fertigung, werden Fehler bei der Bestückung und Montage vermieden. Durch den Strukturaufbau werden mehr Informationen zur Nachverfolgung von Produkten gesammelt. Das Aufnehmen von detaillierten Meldungen für das Qualitätsmanagement verbessert die Rückverfolgbarkeit von Fehlern und gibt besseren Aufschluss über Qualitätsmerkmale von Bauteilen und Produkten. Die Unternehmensführung hat sich zusammen mit der IT-Abteilung für eine Umsetzung als browserfähige Anwendung entschlossen, zum Einen um eine einfache Lösung zur Integration von mobilen und stationären Barcodescannern zu gewährleisten und zum Anderen um Schulungen der Produktionsmitarbeiter zur Benutzung der SAP GUI zu vermeiden. Mobile Scanner werden heutzutage meistens mit einem „vollwertigen“ Webbrowser ausgeliefert. Ein weiterer Punkt für die Umsetzung über eine browserbasierte Lösung sind die Lizenzkosten. Die Applikation wird so ausgelegt sein, dass nur eine geringe Anzahl von vergleichsweise günstigen SAP-Rückmeldebenutzern verwendet werden muss. Die IT-Infrastruktur des Unternehmens besteht aus einem SAP ECC 5.0 System (Produktiv- und Testumgebung), laufend auf einem separaten Datenbankserver mit einer MaxDB des aktuellsten Releasestandes. Dies bedeutet, dass für die Entwicklung zurzeit ein SAP WAS in der Version 6.40 mit dem integrierten ABAP-Stack zur Verfügung steht. Eine Nutzung von JAVA-Anwendungen im Unternehmen wurde bisher nicht benötigt. Dieser SAP WAS unterstützt keine WD4A Anwendungen. Die IT-Abteilung des Kunden besteht aus sechs Personen. Zwei IT-Mitarbeiter verfügen über tiefergehendes Wissen der Programmiersprache ABAP. Keiner der Angestellten in der IT hat bisher mit JAVA entwickelt. Das Projekt ist eng budgetiert, so dass mit vorhandenen Mitteln gearbeitet werden soll. Es ist kein Budget für Fortbildung oder Schulung der IT-Mitarbeiter oder für das Einstellen eines neuen Mitarbeiters vorgesehen. Von der Unternehmensberatung wurde schon im Vorfeld darauf aufmerksam gemacht, dass eine Umsetzung der Applikation auf Grundlage des WebDynpro Frameworks als

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 64 Entwicklungstechnik besser für die Umsetzung des Projektes geeignet ist. WebDynpros ermöglichen eine schnellere und einfachere Programmierung und sind für mobile Scanner unkompliziert nutzbar. Die Pflege der Applikation durch die IT-Abteilung ist bei Einsatz von WD4A möglich. Das Projektvolumen der Anwendungsentwicklung wurde von der Unternehmensberatung auf ca. 65-80 Manntage (MT) geschätzt. Der relativ große Spielraum im Projektvolumen ist anhand der noch zu definierenden Schnittstellen und der zu definierenden Prozesse zu begründen. Die Schnittstelle zum Dokumentenmanagementsystem ist zum jetzigen Zeitpunkt noch nicht genau spezifiziert, da der Auswahlprozess für einen Anbieter noch nicht abgeschlossen ist und einige Maschinenschnittstellen im Fertigungsprozess noch zu definieren sind. Ebenfalls fehlt von einer Fachabteilung noch die benötigte Anforderungsspezifikation. Es wird im Weiteren vereinfacht mit einem Projektvolumen von 70 MT und einem Tagessatz von 1.000,- Euro / Manntag gerechnet. Damit beläuft sich das Entwicklungsvolumen auf ca. 70.000,- Euro. Die Lizenzkosten beschränken sich auf die einzusetzenden SAP-Rückmeldebenutzer und die im weiteren Verlauf darauf anzurechnende Wartungsgebühr. Bei ca. 30 Rückmeldebenutzern zum Preis von 450,- Euro, sind das einmalig 12.500,- Euro Lizenzkosten. Die Wartungsgebühr entspricht 17% der Lizenzkosten im Jahr. Das wiederum entspricht 2.125,- Euro laufende Kosten. Evtl. Serverinstallationskosten oder vorbereitende Maßnahmen zur Anpassung der IT-Infrastruktur sind in dem genannten Volumen nicht enthalten.

5.2 Aufstellung des Kriterienkatalogs Anhand der beschriebenen Projektsituation muss nun vom Unternehmen eine Entscheidung getroffen werden, welche SAP-Technologie zum Einsatz kommen soll. Die Aufstellung des Kriterienkatalogs soll das Unternehmen dabei unterstützen. Es werden zuerst die zur Entscheidung stehenden Technologiealternativen vorgestellt. Anschließend wird eine Übersicht der ausgewählten Schlüsselindikatoren und Merkmale gegeben und die kundenindividuellen Merkmale werden erklärt. Folgend darauf, wird die Gewichtung der Kriterien erläutert, die Bewertung vorgenommen und schließlich eine Technologieempfehlung ausgesprochen.

5.2.1 Entscheidungsalternativen

Bei diesem Projekt kommen drei verschiedene technologische Umsetzungsmöglichkeiten in Betracht. Zum einen gibt es die Entscheidung, ob der ABAP-Stack oder der JAVA-Stack genutzt werden soll. Für die Nutzung des ABAP-Stacks gibt es allerdings zwei

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 65 Entscheidungsalternativen, nämlich ob das bestehende SAP-Release benutzt werden soll, oder ein Releasewechsel durchgeführt wird, so dass neuere Technologien, hier WD4A, zur Anwendungsentwicklung zur Verfügung stehen. Diese Entscheidung kommt in die engere Wahl, da ein Releasewechsel des bestehenden SAP-Systems voraussichtlich 2011 ansteht. Die folgende Tabelle (vgl. Tab. 18) zeigt die drei Entscheidungsalternativen. Alternative ABAP-Stack, ECC 5.0 ABAP-Stack, ECC 6.0 JAVA-Stack, ECC 6.0 IT-System-architektur

Direkte Nutzung der vorhandenen SAP-Systemlandschaft

Releasewechsel SAP-System, oder zusätzliche ABAP-Instanz neueren Releases

Installation des JAVA-Stacks als zusätzliche Instanz oder zusätzlicher Server

Web-funktionalität

Beschränkung der Webtechnik auf BSPs

Alle ABAP-Webfunktionalitäten vorhanden

Alle JAVA-Funktionalitäten, kein SAP Enterprise Portal

Bei den Entscheidungsvarianten ABAP ECC 6.0 und JAVA kommen zu den eigentlich anfallenden Projektkosten noch Installations-/Konfigurationskosten für eine separate SAP NetWeaver-Instanz oder einen Releasewechsel des Systems zutragen. Diese Kostenblöcke treten bei der ABAP ECC 5.0 Version jetzt nicht auf. Allerdings ist in Bezug auf einen evtl. späteren Releasewechsel mit leicht erhöhten Kosten zu rechnen. Diese Zusatzkosten können hier nur als grobe und stark vereinfachte Schätzwerte aufgeführt werden und sind stark von möglichen Projektfaktoren abhängig. Der Aufwand eines Releasewechsels kann nicht ohne weiteres geschätzt werden. Es kommen viele unterschiedliche Faktoren zusammen, z.B. Umfang der installierten Software (Module), Anzahl und Qualität der Eigenentwicklungen u.v.m.. Um es überschaubar zu halten, wird von einem unkomplizierten Fall ausgegangen und es werden 10.000,- Euro (ca. 10 MT) Aufwand angesetzt. Eine Installation, Konfiguration und Patchen eines angepassten JAVA-Servers wird mit ca. 5.000,- Euro (ca. 5 MT) angesetzt, hierbei muss aber noch neue Serverhardware gekauft werden, da die JAVA-Instanz nicht auf dem jetzigen System laufen kann. Neue Serverhardware wird ebenfalls pauschal mit ca. 10.000 Euro veranschlagt.

5.2.2 Merkmalsübersicht

In der folgenden Tabelle (vgl. Tab. 19) sind die Merkmale, die der Kunde für die von ihm gestellten Projektanforderungen für wichtig erachtet, dargestellt. Merkmale Gewichtungsfaktor Funktionsumfang (technisch benötigt) 30% (insgesamt) Standardwebprotokolle 10%

Tab. 18 – Entscheidungsalternativen Technologieeinsatz

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 66 Kompatibilität der Anwendung zu verschiedenen Frontends

35%

Leichte Integration des SAP ERP und von SAP-Standardfunktionen

20%

Integration des DMS 15% Erweiterbarkeit (bzgl. Schnittstellen) 10% Kontrolle über Anpassbarkeit des GUIs 10% Funktionsumfang (anwendungsspezifisch) benötigt)

20% (insgesamt)

Leichte Bedienbarkeit 33% Intuitive Bedienbarkeit 33% Hohe Performanz 33% Wirtschaftlichkeitsaspekte 50% (insgesamt) Kleiner initialer Planungsaufwand 20% Ausnutzung vorhandener Ressourcen 20% Geringe Betriebskosten 20% Geringer Änderungsabstand 20% Kosteneffiziente Entwicklung 20%

Eine Vorauswahl der Merkmale wurde innerhalb der stattfindenden Projekttreffen durch das Beratungshaus durchgeführt. Auf Basis dieser Selektion wurden dem Kunden die Merkmale vorgestellt. Zusammen mit dem Kunden wurden die Merkmale gruppiert und der Kunde wurde aufgefordert, sie nach ihrer Wichtigkeit zu bewerten. Dazu wurden zum einen die Gruppierungen zueinander und zum anderen die Merkmale innerhalb der Gruppen untereinander ins Verhältnis gesetzt. Bei der Bewertung des Kunden ist klar ersichtlich, dass die Wirtschaftlichkeit der Lösung am schwersten ins Gewicht fällt. Die technischen und anwendungsbezogenen Funktionalitäten teilen sich den Rest der Aufmerksamkeit. Einige Merkmale, wie die Aufstellung eines Risikoindex oder die Bewertung des Fremdkräfteanteils zur Durchführung des Projektes, wurden von dem Kunden aus der Aufstellung herausgenommen. Dies ist voraussichtlich auf die langjährige Zusammenarbeit zwischen dem Beratungshaus und dem Kunden zurückzuführen. Das Vertrauen, dass ein Projekt zur vollsten Zufriedenheit umgesetzt wird besteht, ohne größere Risikoanalyse oder Skepsis was den Fremdkräfteanteil angeht. Die im Voraus aufgeführten und betonten Wirtschaftlichkeitskennzahlen (ROI, Amortisationsdauer und Wirtschaftlichkeit (vgl. Kapitel 3.1.3)) sind hier nicht weiter aufgeführt und berechnet, weil eine Analyse des Nutzeneffektes des eigentlichen Projektinhalts (Welchen wirtschaftlichen Nutzen hat die Einführung der Applikation z.B. durch Qualitätsverbesserungen etc.?) nicht Ziel dieser Arbeit ist und somit den Rahmen übersteigen würde.

Tab. 19 – Übersicht ausgewählter Merkmmale

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 67

5.2.3 Bewertung der Entscheidungen

Die Bewertung der drei aufgeführten Möglichkeiten anhand der oben genannten Kriterien wird über eine qualitative Bewertung durchgeführt. Die Bewertungsskala reicht von „1 nicht ausgeprägt“ bis „5 voll ausgeprägt“ (vgl. Tab. 20).

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 68 Bewertung Erklärung „1 nicht ausgeprägt“ Nicht ausgeprägt, nicht vorhanden. „2 teilweise ausgeprägt“ Ausprägungsmerkmale fehlen teilweise oder nur

erschwerte Umsetzung möglich „3 ausgeprägt“ Wesentliche Merkmale vorhanden, Umsetzung möglich, es

gibt einfachere/bessere/effizientere Alternativen „4 gut ausgeprägt“ Merkmal gut umsetzbar „5 voll ausgeprägt“ Merkmal nachhaltig umsetzbar

Es ergibt sich folgende Bewertungsmatrix (vgl. Tab. 21): Merkmale ABAP ECC 5.0 ABAP ECC 6.0 JAVA ECC 6.0 Funktionsumfang (technisch benötigt)

Standardwebprotokolle 4 5 5 Kompatibilität der Anwendung zu verschiedenen Frontends

3 5 5

Leichte Integration des SAP ERP und von SAP-Standardfunktionen

4 5 3

Integration des DMS 3 3 4 Erweiterbarkeit (bzgl. Schnittstellen)

3 3 5

Kontrolle der Anpassbarkeit des GUIs

5 3 4

Funktionsumfang (anwendungsspezifisch benötigt)

Leichte Bedienbarkeit 4 4 4 Intuitive Bedienbarkeit 4 4 4 Hohe Performanz 4 3 3 Wirtschaftlichkeitsaspekte Kleiner initialer Planungsaufwand

5 2 2

Ausnutzung vorhandener Ressourcen

5 3 2

Geringe Betriebskosten 4 4 3 Geringer Änderungsabstand 2 5 5 Kosteneffiziente Entwicklung 3 5 4

Tab. 20 – Bewertungshierarchie

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 69 Merkmale ABAP ECC 5.0 ABAP ECC 6.0 JAVA ECC 6.0 Kostenaufschlüsselung Projektkosten Entwicklung 70.000€ 60.000€ 60.000€ Projektkosten Infrastruktur 0€ 10.000€ 15.000€ Projektkosten Lizenzen 12.500€ 12.500€ 12.500€ Gesamtprojektkosten 82.500€ 82.500€ 87.500€ Betriebskosten/Wartung 2.125€ 2.125€ 2.125€ +

Serverbetrieb Wirtschaftlichkeitskennzahlen Anteil Kosten Infrastruktur an Projektkosten

0% 12,12% 17,14%

Anteil Kosten Entwicklung an Projektkosten

84,85% 72,73% 68,57%

Anteil Kosten Lizenz an Projektkosten

15,15% 15,15% 14,29%

5.2.4 Auswertung & Technologieempfehlung

Führt man die Nutzwertanalyse durch (vgl. Anhang Nutzwertanalyse (A)), kommt man zu folgendem errechneten Nutzenwert (vgl. Tab. 22). Entscheidungsalternative ABAP 5.0 ABAP 6.0 JAVA Nutzenwert 3,742 3,916 3,631

Nach dem Nutzwert ist das Durchführen eines Releasewechsels und die Entwicklung der Applikation mit der neuen WD4A Technologie am Besten bewertet worden. Betrachtet man hierzu noch die Wirtschaftlichkeitskennzahlen, insbesondere die Betriebskosten der ABAP zur JAVA-Nutzung, fällt eine Entscheidung zu Alternative ABAP 6.0 relativ eindeutig aus. Das Ergebnis ist nicht sehr überraschend, da die Prioritäten des Unternehmens auf einer kosteneffizienten Umsetzung unter Nutzug vorhandener Ressourcen mit einer nachhaltigen Lösung liegen. Wegen der effizienteren Umsetzung durch WD4A sind auch die geringeren Infrastrukturkosten nicht ausschlaggebend, besonders im Hinblick auf eine nachhaltige Lösung. Da nur in geringem Maß mit Anforderungen an Offenheit und Integration in Bezug auf das DMS und die Maschinenschnittstellen zu rechnen ist, sowie eine Kommunikation über Unternehmensgrenzen gar nicht benötigt wird, kommen die Stärken des JAVA-Stacks, leichte Integration heterogener Anwendungen oder Umsetzung neuer Technologieframeworks, nicht zur Geltung.

Tab. 21 – Bewertungsmatrix

Tab. 22 – Nutzenwert der Entscheidungsalternativen

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 70 Zur Veranschaulichung wie schnell eine Technologieentscheidung obsolet werden kann, sei angeführt, dass die SAP Mobile Infrastructure (enthalten in SAP NetWeaver CE (7.1), die speziell auf Anwendungen mit mobilen Endgeräten ausgerichtet ist), zurzeit eine JAVA-Instanz als Entwicklungsumfeld benötigt. Eine ABAP-Version ist in der Entwicklungsphase. Für das vorgestellte Szenario ist die SAP NetWeaver CE Umgebung nicht erforderlich, wäre allerdings der „offline“-Betrieb der mobilen Erfassungsgeräte eine Anforderung gewesen, hätte der JAVA-Stack einen größeren Nutzwert erreichen müssen. Für das beschriebene Projekt kann eine Technologieempfehlung klar für einen Releasewechsels und die Benutzung des WD4A Frameworks ausgesprochen werden.

5.3 Kritik an der Anwendung des Kriterienkatalogs Die spezifische Anwendung des Kriterienkatalogs ist gerade durch die Individualität jeder IT-Architektur stark an die jeweiligen Projektgegebenheiten und an die zur Verfügung stehenden Informationen und deren Qualität gebunden. Bestimmte Merkmale können nicht abstrakt angewendet werden. Die Qualität der Beurteilung der Kriterien ist ebenso stark abhängig von den Projektbeteiligten, also aller Stakeholder, und deren Kenntnis der notwendigen und richtigen Information, sowie ihrer Fähigkeit klare Prioritäten im Firmeninteresse zu definieren. So sind bei der beschriebenen Anwendung des Kriterienkatalogs folgende Mängel aufgetreten, die bei erneuter Anwendung somit bedacht und so weit wie möglich behoben werden müssen. Bei der Aufstellung der Kriterien zu diesem Zeitpunkt im Projektverlauf sind bestimmte Merkmale unter starker Unsicherheit bewertet worden. Sollten im Verlauf des Projektes entscheidende Änderungen passieren oder neue Erkenntnisse gewonnen werden, so kann dies die bisherige Auswertung und Technologieentscheidung komplett nichtig werden lassen. Diese Kritik bezieht sich im Besonderen auf die Einschätzung der Schnittstellenproblematik zum in der Einführung befindlichen DMS. Eigentlich müsste aufgrund dieser Unsicherheit das Kriterium der Integration des DMS bei der Berechnung des Nutzenwerts ausgeschlossen werden, da es sich z.B. als ein „Killerkriterium“ herausstellen könnte. Diesem Punkt wurde in Diskussionen in dem Sinn genüge getan, dass daraufhin allen Entscheidungsalternativen ein ähnlicher Leistungswert zugeordnet wurde. Die vermutliche bessere Integrationsmöglichkeit innerhalb des JAVA-Stacks wurde trotzdem berücksichtigt. Ein weiterer Kritikpunkt ist die Bewertung der Gruppe „Funktionsumfang (anwendungsspezifisch benötigt)“. Um bei der Auswertung ein genaueres Ergebnis erzielen zu können, müsste diese Bewertung über eine Erhebung bzw. einen Usability-Test mit den kommenden Benutzern durchgeführt werden. Hierbei müssten drei technologisch unterschiedliche Applikationen (BSPs, WD4A & Java) mit gleicher Funktionsweise von einer repräsentativen Anwendergruppe getestet und von diesen bewertet werden, sowie die Benutzung dieser Applikation beobachtet und ausgewertet werden. Zurzeit basiert die Bewertung der unterschiedlichen Anwendung auf der Erfahrung der im Projekt anwesenden Berater und der Vorführung und der Auswertung von Demoapplikationen vor der Projektgruppe. Dieses einfache Verfahren beinhaltet ein gewisses Risiko, in dem Sinn, dass

Diplomarbeit Volker Ritzau Kapitel 5 Aufstellung und Anwendung des Kriterienkatalogs Seite 71 eine vergleichbare Aussage über die Benutzbarkeit nicht exakt getroffen werden kann, ist aber nach Meinung des Kunden so zu tragen. Schaut man sich hingegen objektiv die tatsächliche Bewertung der Merkmale Bedienbarkeit an, so ist lapidar festzustellen, dass alle Technologien vom Kunden gleich bewertet wurden und somit in der Berechnung des Nutzwerts hier keine Verfälschung erzielt wird. Des Weiteren ist anzumerken, dass die Anwendung des Kriterienkatalogs in diesem Fall relativ einfach durchzuführen ist, steht einer erneuten Berechnung der Nutzenwerte, bei einer Veränderung des Informationsgehalts und einer damit einhergehenden Veränderung der Bewertung nichts entgegen.

5.4 Zusammenfassung der Ergebnisse Die Anwendung des Kriterienkatalogs hat als Ergebnis eine klare Technologieempfehlung gebracht. Diese Empfehlung basiert auf der Auswahl der für die Projektsituation wichtigen und passenden Kriterien. Diese müssen erkannt, priorisiert und anschließend gewichtet werden. Problematisch und in folgenden Anwendungen zu berücksichtigen ist der Sicherheits- bzw. Unsicherheitsfaktor der Merkmale. Übrig bleibt im folgenden und letzten Kapitel 6 ein Fazit über die geleistete Arbeit zu ziehen und auf die in dieser Arbeit nicht bearbeiteten Punkte aufmerksam zu machen. Dabei soll vor allem auch ein Ausblick darauf gegeben werden, in welcher Art und Weise eine Erweiterung des Kriterienkatalogs möglich ist, so dass auch Nicht-SAP-Produkte mit in ein Auswahlverfahren integriert werden könne.

Diplomarbeit Volker Ritzau Kapitel 6 Fazit und Ausblick Seite 72

6 Fazit und Ausblick Im folgenden Kapitel soll die geleistete Arbeit noch einmal zusammengefasst werden. Zuerst werden die Ergebnisse des Vergleichs der beiden Technologiestacks aufgezeigt und die wesentlichen Punkte des Kriterienkatalogs aufgegriffen. Im weiteren Verlauf gibt es einen Überblick über die in dieser Arbeit offen gebliebenen Punkte. Abschließend folgt im dritten Teil ein Ausblick und eine Heranführung an eine Erweiterung des Kriterienkatalogs zu einer Anwendbarkeit im Zusammenhang mit Nicht-SAP-Produkten.

6.1 Zusammenfassung der geleisteten Arbeit SAP hat mit der Öffnung ihrer monolithischen Strukturen einen Paradigmenwechsel eingeleitet. Mit SAP NetWeaver wurde eine technologische Plattform eingeführt, die eine technische Umsetzung einer Enterprise Service Architektur möglich macht. [vgl. KTD05, S. 34]. Der Reifegrad der einzelnen NetWeaver Komponenten ist unterschiedlich weit ausgeprägt. [vgl. Fu07, S. 431], SAP NetWeaver wird allerdings als Wegbereiter der Enterprise-SOA gesehen [vgl. FU07, S. 433]. In dieser Diplomarbeit wurden die beiden SAP-Technologiestacks – als Applikationsplattformen – von verschiedenen Seiten beleuchtet. Dazu wurden eine Gegenüberstellung der vorhandenen Merkmale der Technologiestacks und eine Bewertung dieser vorgenommen. Für den ABAP-Stack wurde festgestellt, dass der Schwerpunkt nicht auf der Neuentwicklung von Technologien liegt, sondern der Technologiestack als solides Backendsystem erweitert und auf neuere Gegebenheiten angepasst wird. So wird im Bereich des Schnittstellenmanagements mit Hilfe von SAP Konnektoren ein vielschichtiges Angebot an einfachen Zugriffsmöglichkeiten angeboten, welches einem ständigen Verbesserungs- und Optimierungsprozesses unterliegt. Die Kernschnittstelle des Business Object Repositories und der damit angebotenen BAPIs ist zuverlässig und bildet das Fundament für einen performanten und stabilen Zugriff. Die Unterstützung von Web Services durch den ABAP-Stack ist ein zweiter Aspekt der Öffnung und der Umsetzung von serviceorientierten Lösungen. Trotz der Einführung des JAVA-Stacks und der vielschichtigeren Anwendbarkeit und Umsetzungsmöglichkeit von Webanwendungen wird weiterhin daran gearbeitet, auch ABAP-Anwendungen über Technologien wie BSPs oder WD4A webfähig und integrierbar zu halten. Dies ist wahrscheinlich zum einen auf den wirtschaftlichen Aspekt des Investitionsschutzes zurückzuführen, zum anderen um auch das Alleinstellungsmerkmal, welches ein SAP ERP-System mit sich bringt, in Grundzügen zu wahren. Der JAVA-Stack innerhalb des SAP NetWeaver-Paketes ist die Technologieplattform der zukünftigen SAP-Entwicklungen. Die Untersuchung der angebotenen Funktionalität und der technologischen Möglichkeiten machen ihn gegenüber dem ABAP-Stack überlegen. Bestimmte Punkte, wie z.B. die Performanz müssen noch verbessert werden. Auch andere Untersuchungen durch Praktiker zeigen, dass der JAVA-Stack sich in Punkten wie Stabilität und Performanz noch nicht mit den besten vergleichbaren Nicht-SAP-Produkten auf dem

Diplomarbeit Volker Ritzau Kapitel 6 Fazit und Ausblick Seite 73 Markt messen kann [Fu07, S. 431]. SAP hat hingegen Funktionalitäten wie SAP JDI oder DTR dem JAVA-Stack von SAP NetWeaver hinzugefügt, die so in anderen Nicht-SAP-Produkten nicht zu finden sind und ihn so für die Entwicklung von erfolgskritischen Geschäftsanwendungen bevorzugen. Im Vergleich zum ABAP-Stack, der solche Funktionalitäten schon viel länger bietet, sind diese allerdings mit weniger Komfort und unter einem erhöhten Konfigurationsaufwand einsetzbar. Die Aufstellung des Kriterienkatalogs hat die Schwierigkeiten der Aufstellung und Auswahl geeigneter Kriterien gezeigt. Bei einer betriebswirtschaftlichen Bewertung beider Technologiestacks kommt zu den üblichen Schwierigkeiten der monetären Bewertung von IT-Objekten das Problem hinzu, dass die Technologiestacks Merkmale von IT-Architekturen, IT-Technologien und IT-Systemen aufweisen. Als Lösung dieser Problematik wurden aus verschiedenen vorgestellten Standardkriterien die ausgesucht, die bei einem Vergleich der Technologiestacks sinnvoll erscheinen. Es wurde die Wirtschaftlichkeitsanalyse als Instrument der Bewertung vorgestellt, und dabei die Vor- und Nachteile ihrer Teilverfahren dargestellt (vgl. Kapitel 3.2). Schließlich wurde die Nutzwertanalyse als Auswertungsverfahren ausgewählt und im späteren konkreten Anwendungsfall (vgl. Kapitel 5.2) durchgeführt. Mit Auswahl der Kriterien zeigte sich, dass bestimmte Merkmale wie z.B. Performanz und Laufzeitverhalten, aber auch Unterstützung von neuen Technologien, vor einer Projektsituation nicht von Kundenseite her getestet und ausgewertet werden können, diese aber für eine Be- und Auswertung und die anschließende Technologieempfehlung von großer Bedeutung sein können. So wurden softwaretechnische Implementierungen vorgenommen, um bestimmtes Verhalten und Problematiken der Technologiestacks beispielhaft zu verdeutlichen. Dabei wurden vor allem zwei Schwerpunkte gesetzt: Zum einen wurde das Augenmerk auf die Offenheit und die Möglichkeit der Umsetzung von neueren Technologie im JAVA-Stack gesetzt (vgl. Kapitel 4.1). Der zweite Schwerpunkt lag auf dem Kriterium der Performanz und des Zugriffs auf SAP ERP-Daten (vgl. Kapitel 4.2). Die Implementierungen zeigen, dass bei einem Standardwebszenario, welches die Datenbeschaffung aus dem SAP ERP-System und deren Anzeige im Webbrowser beinhaltet, sich der Zugriff über den JAVA-Stack auf das SAP-Backend als weitaus weniger problematisch herausgestellt hat als vermutet. Es wird ein einfacher und quasi intuitiver Zugang über die SAP Konnektoren zur Verfügung gestellt, der allerdings von der Performanz hinter einem nativen Zugriff aus dem ABAP-Stack etwas zurücksteht. Hingegen wurde anhand der Nutzung des GWT OpenSource Frameworks gezeigt, dass der JAVA-Stack interessante Alternativen bietet, die über den ABAP-Stack so nicht realisierbar sind. Festzuhalten ist ebenso, dass der Konfigurationsaufwand für eine benutzbare und lauffähige JAVA-Entwicklungsumgebung erheblich höher ist, als bei der Entwicklung im ABAP-Stack, der dem Programmierer eine voll integrierte Umgebung mit zahlreichen mächtigen Entwicklungswerkzeugen bietet. Die Anwendung des Kriterienkatalogs in einer realen Projektsituation hat ein zufrieden stellendes Ergebnis mit einer deutlichen Technologieempfehlung geliefert. Es hat sich dabei gezeigt, dass Merkmale, bei denen eine starke Unsicherheit vorliegt, bisher nicht anders berücksichtigt werden müssen, als sicher erscheinende Merkmale. So ist bei der Anwendung darauf zu achten, dass Kriterien, die sich als „Killerkriterien“ herausstellen können, diese

Diplomarbeit Volker Ritzau Kapitel 6 Fazit und Ausblick Seite 74 entweder mit einer entsprechenden Gewichtung versehen werden müssen, oder evtl. aus der tatsächlichen Nutzwertberechnung herausgenommen werden sollten.

6.2 Offene Punkte Wie bereits in den entsprechenden Kapiteln erwähnt, kann und soll diese Arbeit natürlich nicht den Anspruch auf eine vollständige Betrachtung haben. So sind gerade bei der Durchführung und Betrachtung der vergleichenden Implementierungen Schwerpunkte gesetzt worden, die keine allgemeingültigen Aussagen auf SAP NetWeaver zulassen. So müssen diese Applikationen im Kontext als einfache und anschauliche Beispiele gesehen werden. Außerdem ist ebenfalls zu beachten, dass ein bestimmtes Verhalten der IT-Systeme in einem Entwicklungsprozess zu betrachten ist. So können zurzeit auftretende Performanz- oder beobachtete Komfortprobleme mit dem nächsten Release einer Komponente behoben sein. Ziel bei der praktischen Anwendung des Kriterienkatalogs ist es weitere Referenzimplementierungen zu erstellen und ein größeres Spektrum an Merkmalen und Kriterien zu untersuchen. Somit sei hier deutlich gemacht, dass eine Erweiterung und Anpassung der genannten betriebswirtschaftlichen Verfahren (z.B. auf die Berücksichtigung von Unsicherheiten), eine Erweiterung der vergleichenden Implementierungen auf mehr Merkmale (z.B. Test der Web Service Funktionalitäten der beiden Technologiestacks) und eine Erweiterung des Horizontes der Kataloganwendung (Einbeziehung anderer Nicht-SAP-Produkte) als offene Punkte ausstehen. Dem letzten genannten Punkt soll im folgenden Abschnitt Beachtung geschenkt werden.

6.3 Erweiterung des Katalogs auf Anwendbarkeit im Nicht-SAP-Bereich

In dieser Arbeit wurden ein Vergleich und eine Technologieauswahl von SAP-Produkten untereinander betrachtet. Dies ist aus der Aufgabenstellung des SAP-Systemhauses und dem zu betrachtenden Kundenkreis abzuleiten gewesen. Im Folgenden soll kurz skizziert werden, in welcher Weise der Kriterienkatalog angepasst werden könnte, damit nicht nur SAP-Technologien in den Vergleich und die Bewertung aufgenommen werden können, sondern auch andere Nicht-SAP-Produkte. Hierbei soll an dieser Stelle keine komplette Anpassung des Katalogs vorgenommen werden, sondern auf einige wesentliche Punkte und evtl. auftretende Schwierigkeiten, die beachtet werden müssen, hingewiesen werden. Zuerst einmal sei festgestellt, dass die hier benutzten Kriterien, mit wenigen Ausnahmen, allgemeingültig für den jeweiligen Bereich – Software, Enterprise-SOAs oder Kennzahlen der

Diplomarbeit Volker Ritzau Kapitel 6 Fazit und Ausblick Seite 75 IT – sind. Wirklich SAP-spezifisch ist nur die Kennzahl der „direkten Benutzer“, welche aber in dem allgemeinen Kriterium der Lizenzkosten aufgehen kann. Das eigentliche Problem der Vergleichbarkeit liegt also in der Auswahl und Zusammenstellung der Kriterien. Ein gängiger Software- oder Architekturauswahlprozess beinhaltet die Phasen Projektdefinition, IST-Analyse, SOLL-Konzeption, Systemevaluation, Auswahlentscheidung [z.B. vgl. BVW07, S. 65ff.]. Dieser oder ein ähnlicher angepasster Prozess muss bei einem Vergleich unterschiedlicher Produkte und Technologien komplett durchlaufen werden. Bei der in dieser Arbeit durchgeführten Technologieentscheidung zwischen den zwei SAP-Technologiestacks konnte dieser Auswahlprozess vereinfacht durchgeführt werden, welches sich in den zwei Punkten der Merkmalsausprägung und den anzustellenden strategischen Überlegungen zeigt. Beide Punkte sollen im Folgenden weiter erörtert werden. So mussten zum einen nicht alle funktionalen Kriterien bei der Technologieentscheidung betrachtet werden. Es wurde das Delta der Stacks herausgearbeitet, weil andere Kriterien sich stark ähnelten (z.B. Hochverfügbarkeitsarchitektur oder Sicherheitsaspekte). Diese spielen bei einem Produktvergleich mit anderen IT-Architekturen oder IT-Systemen selbstverständlich auch eine wichtige Rolle. Folgern kann man daraus, dass der Schritt eines Vergleichs nur über eine exakte Anforderungsanalyse der notwendigen Eigenschaften gegangen werden kann, die die einzuführende Technologieplattform mitbringen muss, um das anstehende Projekt umzusetzen. Zum anderen betrachtet der in dieser Arbeit geleistete Auswahlprozess in dem Sinn keine strategische Ausrichtung der IT-Infrastruktur. Wie sich schon bei der Auswahl der Kriterien in Kapitel 3 gezeigt hat, ist SAP NetWeaver mehr als eine Software oder eine IT-Architekturkomponente. Aus den Praxisberichten von Stefan Fuchs [vgl. FU07 S. 442] wird deutlich, dass zurzeit SAP NetWeaver der vollständigste Technologiestack auf dem Markt ist. Es wurde also quasi im Voraus bei diesen Beispielen eine Entscheidung für ein Produkt (SAP) und eine Philosophie getroffen, so dass eine weitere strategische Diskussion über eine Ausrichtung der IT-Architektur und IT-Systemlandschaft unnötig gewesen ist. Diese Betrachtung muss im Rahmen eines erweiterten Vergleichs durchgeführt werden und hat sehr wohl ihre Berechtigung. Heutzutage sind Geschäftspläne mehr denn je an einer bestimmten Strategie ausgerichtet, ganz nach dem Motto „Think global, act local“. Es besteht ein deutlicher Trend in dem Bestreben zu einer hohen Flexibilität der IT-Systeme mit zugleich gesenkten IT-Kosten (Stichwort TCO) [vgl. Ag07]. IT-Strategie ist oft ausgerichtet auf Prinzipien wie Portfolio Rationalisierung (Vereinfachung von Anwendungen und Instanzen), Standardisierung von Technologie und Plattformen und Prozessrationalisierung [vgl. Ag07]. Diese Kriterien im Hinterkopf behaltend muss man im strategischen Bereich getroffenen Entscheidungen beachten. Nach den Ausführungen von SAP ist SAP NetWeaver ein Schritt in genau diese Richtung.

Diplomarbeit Volker Ritzau Kapitel 6 Fazit und Ausblick Seite 76 Betrachtet man beispielhaft andere kommerzielle Produkte, z.B. das WebSphere Produktportfolio von IBM, wichtig für Bereiche wie Integrationsplattformen, Applikationsserver und Middlewarekomponenten, dauert es nicht lange bis man auf die strategischen Partnerschaften zwischen SAP und IBM aufmerksam wird. Große Firmen wie SAP und IBM setzen immer mehr auf kooperatives Handeln und Kollaboration, um einheitliche konsolidierte Systeme und den entsprechenden Support und die Gewährleistung für ihre Kunden zu erreichen [z.B. vgl. IBM08; SAP08k]. Die Frage, die bei OpenSource Produkten wie z.B. JBoss Enterprise Middleware Suite gestellt werden muss, ist, ob ein Vergleich und eine Entscheidung für eine einzelne Komponente so eines Portfolios möglich und unter dem Aspekt der oben aufgeführten Schlagworte für IT-Strategien sinnvoll ist. Für die hier angeführten SAP-Szenarien sind essentielle Betrachtungsschwerpunkte die Schnittstellen zum SAP-ERP-System. Durch die Beschränkung auf SAP-eigene Produkte wird eine Optimierung der Schnittstellen erreicht, bei Einsatz eines ABAP-Stacks, durch den schon bereits erwähnten direkten Zugriff und bei Benutzung des SAP-eigenen J2EE-Servers durch die Optimierungen im Bereich der SAP Konnektoren und die relativ problemlose Integration über die von SAP zur Verfügung gestellten Hilfsmittel wie SAP NWDS. Kosten die beim Einsatz von Nicht-SAP-Produkten bei anstehenden Releasewechseln aufgrund von Portierungen oder Schnittstellen anfallen, müssen bei einer vergleichenden Nutzenwertanalyse auf jeden Fall mit einbezogen werden. Auch die Entwicklung von zusätzlichen Schnittstellen oder eigenen Konnektoren muss als Mehraufwand berücksichtigt werden. Letztendlich bleibt auch die Frage des Supports von großer Bedeutung. Für die Vorgehensweise eines erweiterten Vergleichs sind also die folgenden Schritte zu beachten und durchzuführen:

1) Rahmenszenario festlegen (Ist es ein Standard SAP-Szenario?) 2) IT-Strategie des Unternehmens berücksichtigen 3) Aufstellung der relevanten Entscheidungskriterien durchführen 4) SAP ERP-spezifische Kriterien berücksichtigen

a. Schnittstellen b. Support & Wartung c. Releasewechsel

5) Abgrenzung der zu vergleichenden Komponenten des Portfolios aufgrund der Anforderungsanalyse durchführen

6) Aufstellung der Bewertungsmatrix und Berechnung der Nutzwertanalyse durchführen Zusammenfassend kann man wohl feststellen, dass, sobald eine signifikante Grenze an Investitionen in SAP-Produkten zur Abwicklung des eigenen Geschäfts überschritten ist, es besonders aus strategischen Gründen einen tieferen Sinn ergibt, auch im technologischen Bereich eine Standardisierung zu SAP-Technologien vorzunehmen und andere Komponenten auf Basis dieser zu integrieren.

Diplomarbeit Volker Ritzau Anhang Nutzwertanalyse Seite 77

(A) Anhang Nutzwertanalyse

Diplomarbeit Volker Ritzau Anhang Quelltexte Seite 78

(B) Anhang Quelltexte

(1) ZSQL


(2) ZBAPI_WRAPPER_SQLFLIGHT


(3) BSP ZBAPI_TEST

<%@page language="abap"%>

<%@extension name="htmlb" prefix="htmlb"%>

<%@ extension name="Benchmark" prefix="Benchmark" %>

<Benchmark:duration output="true">

<htmlb:content design="design2003">

<htmlb:page title = "Testseite RFC Aufruf über BSP ">

<htmlb:form>

<htmlb:textView encode="true" text="Testprogramm RFC mit BSP ABAP<b

r>-------------------------------------" />

<table>

<tr><th>Counter</th><th>Fluglinie</th><th>Flugnummer</th><th>Datu

m</th><th>Preis</th></tr>

<%

CALL FUNCTION 'ZBAPI_WRAPPER_SQLSFLIGHT'

TABLES

EXPORTFLIGHT = myExporttable

.

loop at myExporttable into wa_myExporttable.

move sy-tabix to lv_cnt.

%>

<tr>

<td><%= lv_cnt %></td>

<td><%= wa_myExporttable-carrid %></td>

<td><%= wa_myExporttable-connid %></td>

<td><%= wa_myExporttable-fldate %></td>

<td><%= wa_myExporttable-price %></td>

</tr>

<%

endloop.

%>

</table>

</htmlb:form>

</htmlb:page>

</htmlb:content>

</Benchmark:duration>


(4) SQLTest package com.c1ips.sqltest;

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import com.sap.mw.jco.*;

public class SQLTest extends HttpServlet {

public JCO.Table codes = null;

JCO.Repository mRepository;

JCO.Function function = null;

protected void doGet(

HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException {

PrintWriter out = response.getWriter();

long mOutputCallTime = 0;

long mOutputCallTimeEnd = 0;

try {

// Laufzeit ausgeben

long start = System.currentTimeMillis();

out.println("Start Laufzeit:" + start + " MS <p>");

//instantiate conncetion object

SQLSimpleTest conObject = new SQLSimpleTest();

if (conObject == null) {

throw new RuntimeException("Error in SQLTest doGet(): test was

null");

} else if (conObject.mConnection == null) {

throw new RuntimeException("Error in SQLTest doGet():

test.mConnection was null");

} else {

// instantiate JCO Repository

mRepository =

new JCO.Repository("SQLTestJCo", conObject.mConnection);

if (mRepository == null) {

throw new RuntimeException("Error in SQLTest doGet() :

mRepository was null");

} else {

// connect

conObject.mConnection.connect();

if (conObject.mConnection.isAlive()) {

// check connection

long mStartConnectionTime =

System.currentTimeMillis();

out.println("SQLTest Bapi call with JCO &

Repository");

out.println("<br>");

out.println("-----------------------");


out.println("JCo Connection Created!");


out.println("-----------------------");

out.println("<p>");

mOutputCallTime = System.currentTimeMillis();

// create function object


function =

this.createFunction("ZBAPI_WRAPPER_SQLSFLIGHT");

if (function == null) {

System.out.println(

"ZBAPI_WRAPPER_SQLSFLIGHT"

+ " not found in SAP.");

}

// execute function over conObject

conObject.mConnection.execute(function);

// receive export table

codes =

function.getTableParameterList().getTable(

"EXPORTFLIGHT");

if (codes == null) {

throw new RuntimeException("Error in

SqlTestBapi SQlTestBapi() : codes was null");

} else {

mOutputCallTimeEnd =


// output table data

out.println(

"--- Testing Bapi - Output of

Exporttable ---");

out.println("<p>");

out.println("<table><tr><th>Counter</th><th>Fluglinie</th><th>FLugnummer</th><th>Datum</th

><th>Preis</th></tr>");

for (int i = 0; i < codes.getNumRows(); i++)

{

codes.setRow(i);

int y = i + 1;

out.println("<tr><td>" + y + "</td>");

out.println("<td>" +

codes.getString("CARRID") + "</td>");


codes.getString("CONNID") + "</td>");


codes.getDate("FLDATE") + "</td>");


codes.getBigDecimal("PRICE") + "</td></tr>");

}

out.println("</table>");

out.println("<p>");

out.println("--- Output done ---");

out.println("<p>");

// close connection

out.println("--- Close JCo connection ---");

out.println("<p>");

long mCloseConnectionTime =


conObject.mConnection.disconnect();

if(!conObject.mConnection.isAlive()){

out.println("--- JCo connection

closed---");

}


out.println("<p>");

long end = System.currentTimeMillis();

out.println("Ende Laufzeit:" + end + "

MS<p>");

out.println("Laufzeit Insgesamt: " + (end -

start) + " MS<br>");

out.println("Bapi-Proxy Aufruf: " +

(mOutputCallTimeEnd - mOutputCallTime) + " MS<br>");

out.println("JCo Verbindungsaufbau: " +

(mStartConnectionTime - start) + " MS<br>");

out.println("JCo Verbindungsabbau: " + (end -

mCloseConnectionTime) + " MS<br>");

}

}


}

}

} catch (Exception e) {

e.printStackTrace();

}

}

public JCO.Function createFunction(String name) throws Exception {

try {

IFunctionTemplate ft =

mRepository.getFunctionTemplate(name.toUpperCase());

if (ft == null)

return null;

return ft.getFunction();

} catch (Exception ex) {

throw new Exception("Problem retrieving JCO.Function object.");

}

}

}


(5) EnterpriseConnect /*

* Created on 27.04.2008

*

*/

package com.c1ips.ecconnect;

import java.io.IOException;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.PrintWriter;

import com.sap.aii.proxy.framework.core.SystemFaultException;

import com.sap.aii.proxy.framework.core.ApplicationFaultException;

/**

* @author vritzau

*

*/

public class EnterpriseConnect extends HttpServlet {

protected void doGet(

HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException {

try {

SQLSimpleTest test = new SQLSimpleTest();

if (test == null) {

throw new RuntimeException("Error in SQLTest doGet(): test was

null");

} else if (test.mConnection == null) {

throw new RuntimeException("Error in SQLTest doGet():

test.mConnection was null");

} else {

// get Print Writer

PrintWriter out = response.getWriter();

long mOutputCallTime = 0;

long mOutputCallTimeEnd = 0;


long start = System.currentTimeMillis();

out.println("Start Laufzeit:" + start + " MS <p>");

// get JCo COnnection, check alive

test.mConnection.connect();

if(test.mConnection.isAlive()){

out.println("----------JCo Connection Created ------------

");

out.println("<p>");

}

long mStartConnectionTime = System.currentTimeMillis();

// create proxy object

SQLFLIGHT_PortType proxy = new SQLFLIGHT_PortType();

// give connection to proxy obeject

proxy.messageSpecifier.setJcoClient(test.mConnection);

// create input object

Zbapi_Wrapper_Sqlsflight_Input input =

new Zbapi_Wrapper_Sqlsflight_Input();

//create output object

Zbapi_Wrapper_Sqlsflight_Output output =


new Zbapi_Wrapper_Sqlsflight_Output();

// checkings

if (proxy == null) {

throw new RuntimeException("Error in EnterpriseConnect

doGet(): proxy was null");

} else if (input == null) {


doGet(): input was null");

} else if (output == null) {


doGet(): output was null");

} else {

mOutputCallTime = System.currentTimeMillis();

try {

// execute proxybapi

output = proxy.zbapi_Wrapper_Sqlsflight(input);

} catch (SystemFaultException sys) {

sys.printStackTrace();

} catch (ApplicationFaultException afe) {

afe.printStackTrace();

}

mOutputCallTimeEnd = System.currentTimeMillis();

SflightType[] flighttab = null;

// get exporttable

flighttab = output.getExportflight();

out.println(output.generationInfo());

out.println("<p>");

out.println(

// print output table to printer

"---------Iterate over Flighttab-----------

");

out.println("<table><tr><th>Counter</th><th>Fluglinie</th><th>FLugnummer</th><th>Datum</th

><th>Preis</th></tr>");

if (flighttab.length!=0)

for (int i = 0; i < flighttab.length; i++) {

int y = i + 1;

out.println("<tr><td>" + y + "</td>");

out.println(

"<td>" +

flighttab[i].getCarrid().toString() + "</td>");

out.println(

"<td>" +

flighttab[i].getConnid().toString() + "</td>");

out.println(

"<td>" +

flighttab[i].getFldate().toString() + "</td>");

out.println(

"<td>" +

flighttab[i].getPrice().toString() + " $</td></tr>");

}

else {

out.println(flighttab.length);

}

out.println("</table>");

out.println(

"---------Iteration done -----------");

}

// close JCo connection

out.println("<p>");

out.println("Close JCo Connection-----------------");

out.println("<p>");

// Systemzeit ausgeben

long mCloseConnectionTime = System.currentTimeMillis();

test.mConnection.disconnect();

out.println("Close JCo Connection done------------");

out.println("<p>");


long end = System.currentTimeMillis();


out.println("Ende Laufzeit:" + end + " MS<p>");

out.println("Laufzeit Insgesamt: " + (end - start) + "

MS<br>");

out.println("Bapi-Proxy Aufruf: " + (mOutputCallTimeEnd -

mOutputCallTime) + " MS<br>");

out.println("JCo Verbindungsaufbau: " +

(mStartConnectionTime - start) + " MS<br>");

out.println("JCo Verbindungsabbau: " + (end -

mCloseConnectionTime) + " MS<br>");

}

} catch (Exception e) {

e.printStackTrace();

}

}

}


(6) Lokale Schnittstelle BAPI_SALESORDER_CREATEFROMDAT2

*"---------------------------------------------------------------------- *"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(SALESDOCUMENTIN) LIKE BAPIVBELN-VBELN OPTIONAL *" VALUE(ORDER_HEADER_IN) LIKE BAPISDHD1 STRUCTURE BAPISDHD1 *" VALUE(ORDER_HEADER_INX) LIKE BAPISDHD1X STRUCTURE BAPISDHD1X *" OPTIONAL *" VALUE(SENDER) LIKE BAPI_SENDER STRUCTURE BAPI_SENDER OPTIONAL *" VALUE(BINARY_RELATIONSHIPTYPE) LIKE BAPIRELTYPE-RELTYPE *" OPTIONAL *" VALUE(INT_NUMBER_ASSIGNMENT) LIKE BAPIFLAG-BAPIFLAG OPTIONAL *" VALUE(BEHAVE_WHEN_ERROR) LIKE BAPIFLAG-BAPIFLAG OPTIONAL *" VALUE(LOGIC_SWITCH) LIKE BAPISDLS STRUCTURE BAPISDLS OPTIONAL *" VALUE(TESTRUN) LIKE BAPIFLAG-BAPIFLAG OPTIONAL *" VALUE(CONVERT) LIKE BAPIFLAG-BAPIFLAG DEFAULT SPACE *" EXPORTING *" VALUE(SALESDOCUMENT) LIKE BAPIVBELN-VBELN *" TABLES *" RETURN STRUCTURE BAPIRET2 OPTIONAL *" ORDER_ITEMS_IN STRUCTURE BAPISDITM OPTIONAL *" ORDER_ITEMS_INX STRUCTURE BAPISDITMX OPTIONAL *" ORDER_PARTNERS STRUCTURE BAPIPARNR *" ORDER_SCHEDULES_IN STRUCTURE BAPISCHDL OPTIONAL *" ORDER_SCHEDULES_INX STRUCTURE BAPISCHDLX OPTIONAL *" ORDER_CONDITIONS_IN STRUCTURE BAPICOND OPTIONAL *" ORDER_CONDITIONS_INX STRUCTURE BAPICONDX OPTIONAL *" ORDER_CFGS_REF STRUCTURE BAPICUCFG OPTIONAL *" ORDER_CFGS_INST STRUCTURE BAPICUINS OPTIONAL *" ORDER_CFGS_PART_OF STRUCTURE BAPICUPRT OPTIONAL *" ORDER_CFGS_VALUE STRUCTURE BAPICUVAL OPTIONAL *" ORDER_CFGS_BLOB STRUCTURE BAPICUBLB OPTIONAL *" ORDER_CFGS_VK STRUCTURE BAPICUVK OPTIONAL *" ORDER_CFGS_REFINST STRUCTURE BAPICUREF OPTIONAL *" ORDER_CCARD STRUCTURE BAPICCARD OPTIONAL *" ORDER_TEXT STRUCTURE BAPISDTEXT OPTIONAL *" ORDER_KEYS STRUCTURE BAPISDKEY OPTIONAL *" EXTENSIONIN STRUCTURE BAPIPAREX OPTIONAL *" PARTNERADDRESSES STRUCTURE BAPIADDR1 OPTIONAL *" NFMETALLITMS STRUCTURE /NFM/BAPIDOCITM OPTIONAL *"----------------------------------------------------------------------

Diplomarbeit Volker Ritzau Literaturverzeichnis Seite 88

Literaturverzeichnis [Al03] ALBIN, Stephen T. : The Art of Software Architecture - Design Methods and

Techniques. 1. Auflage, Indianapolis, Indiana Wiley Publishing, Inc.2003. - ISBN 0-471-22886-9

[Ag07] AGARWAL, Manish : SAP centric Enterprise Architecture - Part 4 - Can SAP

become the center of the Universe? URL: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6293, Letzter Abruf: 13.05.2008.

[AS05] AIER, Stephan ; SCHÖNHERR, Martin : Evaluating Enterprise Architectures – A

Scenario-Based Evaluation of Integration Architectures. In: DRAHEIM, Dirk (Eds.) ; WEBER, Gerald (Eds.) : Trends in Enterprise Application Architecture: VLDB Workshop, TEAA 2005, Revised Selected Papers. Berlin, Heidelberg, New York Springer Verlag 2005. S. 2-14. – ISBN 3-540-32734

[Be02] BERNHARD, Martin G. : Report. Balanced Scorecard in der IT – Praxisbeispiele

– Methoden – Umsetzung. Hrsg.: BLOMER, Roland. 2. Auflage, Düsseldorf, Symposion Publishing Aug. 2002. – ISBN 3-933-81473-1

[BVW07] BECKER, Jörg ; VERING, Oliver; WINKELMANN, Axel : Softwareauswahl und -

einführung in Industrie und Handel: Vorgehen und Erfahrungen bei ERP- und Warenwirtschaftssystemen. 1. Auflage, Berlin Springer Verlag 2007. – ISBN 3-540-47424-2

[Bo93] BOOCH, Grady : Object Oriented Analysis and Design. With Applications.

Auflage: Nachdruck, Amsterdam, Addison-Wesley Longman Oktober 1993. – ISBN 0-8053-5340-2

[De98] DEIMEL, Anton : The SAP R/3 Business Framework. In: Software - Concepts &

Tools. Berlin, Heidelberg Springer Verlag Juni 1998, Vol. 19, Nr. 1, S. 29-36. - ISSN 0945-8115 (Print) 1432-2188 (Online)

[DFH03] DIESTERER, Georg ; FELS, Friedrich ; HAUSOTTER, Andreas : Taschenbuch der

Wirtschaftsinformatik. 2. Auflage, München, Wien Fachbuchverlag Leipzig im Carl Hanser Verlag 2003. – ISBN 3-446-21973-0

[Ei07 et al.] EISELE, Markus ; KOLB, Ralf ; KRAUS, Erwin ; VON EHRENSTEIN, Christian :

SAP NetWeaver: Slicing the fridge – Überblick und Einordnung aus Sicht der Informatik. In: Informatik Spektrum. Heidelberg Springer Verlag Dezember 2007, Band 30, Heft 6, S. 407-412. – DOI 10.1007/s00287-007-0194-0


[Fu07] FUCHS, K. : SAP NetWeaver in der Praxis – Wie gut bewährt sich der Technologie-Stack in der praktischen Arbeit?. In: Informatik Spektrum. Heidelberg Springer Verlag Dezember 2007, Band 30, Heft 6, S. 428-433. – DOI 10.1007/s00287-007-0191-3

[GA08] GARTNER GROUP : Decision Tools for Cost Management. URL:

http://www.gartner.com/4_decision_tools/measurement/decision_tools/tco/tco.html, Letzter Abruf: 06.03.08.

[Go08a] GOOGLE : Google Web Toolkit – Product Overview. URL:

http://code.google.com/webtoolkit/overview.html, Letzter Abruf: 25.01.2008. [Go08b] GOOGLE : Google Web Toolkit – Fundamentals.

http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.html, Letzter Abruf: 25.01.2008.

[Ho06] HOFFMANN, Ulli : Praxisbuch WebDynpro for ABAP. 1. Auflage, Bonn Galileo

Press 2006. – ISBN 3-89842-690-4 [HR05] HEINEMANN, Frédéric ; RAU, Christian : Webentwicklung in ABAP mit dem SAP

Web Application Server. 2. überarbeitete und erweiterte Auflage, Bonn Galileo Press GmbH 2005. – ISBN 3-89842-523-1

[NKK07] NICOLESCU, Valentin ; KLAPPERT, Katharina ; KRCMAR, Helmut : SAP

NetWeaver Portal. 1. Auflage, Bonn, Galileo Press GmbH 2007. – ISBN 978-3-89842-1025-6

[IBM08] IBM : IBM WebSphere and SAP NetWeaver Interoperability. URL: http://www-

03.ibm.com/solutions/sap/doc/content/resource/business/1440627130.html, Letzter Abruf: 15.05.2008.

[In08] INSTANTIATIONS : GWT Designer. URL:

http://www.instantiations.com/gwtdesigner/, Letzter Abruf: 26.04.2008. [ISO98] INTERNATIONAL ORGANIZATION OF STANDARDISATION : Ergonomische

Anforderungen für Bürotätigkeiten mit Bildschirmgeräten - Teil 11: Anforderungen an die Gebrauchstauglichkeit. In: ISO 9241-11:1998, Deutsche Fassung, EN ISO 9241-11:1998.

[KK07] KELLER, Horst ; KRÜGER, Sascha : Abap Objects – Abap Programming in SAP

NetWeaver. 2. Auflage, Bonn Galileo Press März 2007. – ISBN 1-5922-9079-5 [KS-E03] KRÜGER, Sascha ; SEELMANN-EGBERT, Jörg : IT Architektur Engineering –

Systemkomplexität bewältigen, Kosten senken, Potenziale freisetzen. 1. Auflage, Bonn Galileo Press GmbH 2003. -ISBN 3-89842-327-1


[KTD05] KESSLER, Karl ; TILLERT, Peter ; DOBRIKOV, Panayot : Java-Programmierung mit dem SAP Web Application Server. 1 Auflage, Bonn Galileo Press GmbH 2005. – ISBN 3-89842-317-4

[Kü05] KÜTZ, Martin : IT-Controlling für die Praxis. 1. Auflage, Heidelberg

dpunkt.verlag GmbH Juli 2005. – 3-89864-265-8 [Kü07] KÜTZ, Martin : Kennzahlen in der IT: Werkzeuge für Controlling und

Management. 2.überarbeitete und erweiterte Auflage, Heidelberg dpunkt.verlag GmbH 2007. – ISBN 3-89864-405-7

[Me03] MEINEKE, Lars : Wirtschaftlichkeitsanalyse – Basis zur Durchführung von IT-

Projekten. In: IT Management. Sauerlach IT-Verlag für Informationstechnik GmbH 2003. Heft 12, S. 12-17.

[Mo04] MOORE, Paul A.: Characteristics of a Service Oriented Architecture. URL:

http://hosteddocs.ittoolbox.com/PM043004.pdf, Letzter Abruf: 12.01.08. [MSN08] MICROSFOT NETWORK : Tech & Gadgets – 15 years of the world wide web.

URL: http://tech.uk.msn.com/features/article.aspx?cp-documentid=8197321, Letzter Abruf: 30.04.2008.

[OGC08] OFFICE OF GOVERNMENT COMMERCE : ITIL. URL:

http://www.ogc.gov.uk/guidance_itil_4438.asp, Letzter Abruf: 30.04.08. [SAP04] SAP AG : What's Inside Your SAP Web Application Server? URL:

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/13d02057-0601-0010-abba-be4a86d47f9e, Letzter Abruf: 28.04.2008.

[SAP08a] SAP AG : SAP Deutschland – Geschichte der SAP. URL:

http://www.sap.com/germany/about/company/geschichte/index.epx, Letzter Abruf: 12.01.08.

[SAP08b] SAP AG : SAP Info Glossar. URL:

HTTP://WWW.SAP.INFO/PUBLIC/INT/INT/GLOSSARY/INT, Letzter Abruf: 12.01.2008.

[SAP08c] SAP AG : SAPHelp - Java-Technologie im SAP Web Application Server. URL:

http://help.sap.com/saphelp_nw04/helpdata/de/0d/a3bb3eff62847ae10000000a114084/frameset.htm, Letzter Abruf: 21.02.2008.

[SAP08d] SAP AG : SAPHelp - SAP NetWeaver Developer’s Guide. URL:

http://help.sap.com/saphelp_nw70/helpdata/de/8b/0b674240449c60e10000000a1550b0/frameset.htm, Letzter Abruf: 02.03.2008.

[SAP08e] SAP AG : SAPHelp - SAP-Lizenzen. URL:

http://help.sap.com/saphelp_nw70/helpdata/de/88/705540b8cdcd01e10000000a155106/frameset.htm, Letzter Abruf: 06.03.2008


[SAP08f] SAP AG : SAP Info: Starke Säule fürs Web. Heft Nr. 133, URL:

http://www.sap.info/public/DE/de/index/PrintEdition-162784399d9b94d656/-1/articlesVersions-163034399c74323e34, Letzter Abruf: 06.03.2008.

[SAP08g] SAP AG : SAP Software Developer Net. Frequently Asked Questions:

Coexistence of ABAP and JAVA in SAP NetWeaver Application Server. URL: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/ad47eb90-0201-0010-7cb2-ddfa5ed879ec, Letzter Abruf: 06.03.2008.

[SAP08h] SAP AG : SAP Help - SAP-Toolsets und –Perspektiven. URL:

http://help.sap.com/saphelp_webas630/helpdata/DE/79/c6213e225f9a0be10000000a114084/frameset.htm, Letzter Abruf: 18.03.2008.

[SAP08i] SAP AG : SAP Help - Komponenten der SAP-Kommunikationstechnologie.

URL: http://help.sap.com/saphelp_nw04/helpdata/de/6f/1bd5c6a85b11d6b28500508b5d5211/frameset.htm, Letzter Abruf: 18.03.2008.

[SAP08j] SAP AG : SAP INFO – Enterprise Service Architecture. URL:

http://www.sap.info/public/INT/int/glossary/de/glossarysearch/Word-50633e881378e6d28_glossary/ESA#Word-50633e881378e6d28_glossary, Letzter Abruf: 30.04.2008.

[SAP08k] SAP AG : SAP und IBM erweitern strategische Zusammenarbeit. URL:

http://www.sap.com/germany/about/press/archive/press_show.epx?ID=4311, Letzter Abruf: 13.05.2008.

[Sch08] SCHALTZEIT: Internet hat 15 Geburtstag? URL:

http://blog.schaltzeit.de/2008/04/30/der-15-geburtstag-des-internets/, Letzter Abruf: 30.04.2008.

[S-N04] SCHNEIDER-NEUREITHER, Andreas : Java für ABAP-Entwickler. 1. Auflage,

Bonn Galileo Press GmbH 2004. – ISBN 3-89842-4081 [SH02] STAHLKNECHT, P. ; HASENKAMP, U.: Einführung in die Wirtschaftsinformatik.

10. Auflage, Berlin, Heidelberg, New York Springer Verlag 2002. [SW01] SCHNEIDER, Uwe ; WERNER, Dieter : Taschenbuch der Informatik. 4. Auflage,

München, Wien Fachbuchverlag Leipzig im Carl Hanser Verlag 2001. – ISBN 3-446-21753-3

[TG05] TAMM, Gerrit ; GÜNTHER, Oliver : Webbasierte Dienste: Technologien, Märkte

und Geschäftsmodelle. Heidelberg Physica-Verlag 2005. – ISBN 3-7908-1566-7


[WH00] WILD, Martin ; HERGES, Sascha : Total Cost of Ownership (TCO) – Ein Überblick. In: Arbeitspapiere WI. Nr. 1/2000 Hrsg.: Lehrstuhl für Allg. BWL und Wirtschaftsinformatik, Johannes Gutenberg Universität: Mainz 2000. URL: http://geb.uni-giessen.de/geb/volltexte/2004/1577/pdf/Apap_WI_2000_01.pdf, Letzter Abruf: 06.03.08.

[Za70] ZANGEMEISTER, Christof : Nutzwertanalyse in der Systemtechnik – Eine

Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen. Diss. Techn. Univ. Berlin 1970, 4. Aufl., München: Wittemann, ISBN 3-923264-00-3.

[Zac07] ZAVARZIN, Sergey : Using Google Web Toolkit (GWT) for Developing AJAX-

Based Web Applications for the SAP NetWeaver J2EE Framework. URL: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e085272c-739f-2910-d1b1-acfa897eb977, Letzter Abruf: 06.03.2008.

[Zü98] ZÜLLIGHOVEN, Heinz : Das objektorientierte Konstruktionshandbuch.

Heidelberg, Dpunkt Verlag 1998. – ISBN 3-9325-8805-3

Diplomarbeit Volker Ritzau Erklärung Seite 93

Erklärung Ich versichere, dass ich die vorstehende Arbeit selbständig und ohne fremde Hilfe angefertigt und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedient habe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden, sind als solche kenntlich gemacht. ____________________________ Hamburg, 17.05.2008 Volker Ritzau

Documents

Diplomarbeit - Fachbereich Informatik · Tab. 5 – Beispiel KPI ... SAP HR SAP Human Resources SAP ITS SAP Internet Transaction Servers ... SDM Software Delivery Manager