Project Paper To SAP Riskmanagement Functionality

Studienbereich Wirtschaft
Studiengang Wirtschaftsinformatik
Evaluation zum Einsatz von Single-Sign- On

Infrastrukturen bei messagebasierten
Kommunikationsprotokollen unter besonderer
Berücksichtigung von Adobe Flex-Technologien
im Umfeld von S AP Gouvernance Risk and
Compliance Anwendungen
Für den Kunden-Einsatz von Werkzeugen zur Erstellung

von Dashboards
2. Projektarbeit
Im Rahmen der Prüfung zum Bachelor of Science (B. Sc.)
Verfasser /in: Marco Hammel

Kurs: WWI07B1
Ausbildungsbetrieb: SAP AG
Abgabedatum: 31.08.2009
Marco Hammel 25. August 2008
Abstract
Die Folgende Arbeit, ist eine Ermittlung und Untersuchung technischer Infrastrukturen, für
die Erstellung von webbasierten Anwendungen unter Verwendung von Adobe Flex, für die
Visualisierung von Kennzahlen, von SAP BusinessObjects Gouvernance Risk and
Compliance Anwendungen. Ziel ist die Beschreibung und Bewertung sowohl von
Anforderungen als auch von möglichen technischen Lösungen. Besondere
Berücksichtigung soll dabei auf die Nutzungsfähigkeit einer Lösung durch Kunden gelegt
werden. Ziel ist keine Realisierung, sondern das Aufzeigen von Verbesserungs- und
Entwicklungsbedarf möglicher Lösungen, auf Basis bestehender technischer
Infrastrukturen.
marco.hammel@sap.com
Eidesstattliche Erklärung:
Ich erkläre hiermit eidesstattlich, dass ich die vorliegende Arbeit selbstständig und
ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Aus den
benutzten Quellen direkt oder indirekt übernommene Gedanken habe ich als solche
kenntlich gemacht.
Diese Arbeit wurde bisher in gleicher oder ähnlicher Form oder auszugsweise noch
keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.
X
Marco Hammel
Student der Wirtschaftsinformatik
Abbildungsverzeichnis
Abb 1 BusinessObjects RiskManagement Overview-Dashboard..........................................9
Abb 2 Flex source-compile-deploy workflow (Kazoun 2008 Q2: S. 10)............................11
Abb 3 SAP Netweaver Komponenten-Übersicht (SAP AG 2009 Q. 14)............................24
Abb 3 SAP Netweaver Komponenten-Übersicht (SAP AG 2009 Q. 14)
Tabellenverzeichnis
Tab 1 Xcelsius relevante Unterschiede zwischen Microsoft Excel 2003 und 2007 (vgl.
Microsoft 2009 Q. 12)..........................................................................................................15
Tab 2 Punktbewertungsmatrix für Xcelsius und Flex Builder 3..........................................16
Tab 3 Gewichtung der Lösungs-Anforderungen..................................................................23
Tab 4 Grad der Anforderungserfüllung möglicher Lösungskonzepte.................................28
Tab 4 Grad der Anforderungserfüllung möglicher Lösungskonzepte
Inhaltsverzeichnis
Abstract.................................................................................................................................1
Eidesstattliche Erklärung:...................................................................................................2
Abbildungsverzeichnis.........................................................................................................3
Tabellenverzeichnis..............................................................................................................3
1. Motivation......................................................................................................................6
2. Hinweise zur Struktur der Arbeit...............................................................................8
3. Beschreibung des SAP GRC Anwendungsportfolios................................................9
4. Dashboards in GRC Anwendungen..........................................................................10
5. Flex-Technologien für webbasierte Dashboards......................................................12
5.1. Architektur von Flex-Applikationen.....................................................................12
5.2. Grafische Entwicklungsumgebungen....................................................................14
5.2.1. SAP Business Objects Xcelsius 2008 Engage...............................................15
5.2.2. Adobe Flex Builder 3 Professional................................................................17
5.2.3. Gegenüberstellung der grafischen Entwicklungsumgebungen......................18
6. Anforderungsanalyse..................................................................................................20
6.1. Funktionale Anforderungen...................................................................................20
6.1.1. Webbasierte Berichtserstattung......................................................................20
6.1.2. Benutzer Authentifizierung durch der NetWeaver RBAC.............................20
6.1.3. Single-Sign-On Anmeldeverfahren................................................................21
6.1.4. Identifizierungs- und Authentifizierungsmanagement...................................21
6.2. Nichtfunktionale Anforderungen...........................................................................22
6.2.1. Flexibilität......................................................................................................22
6.2.2. Ausfallssicherheit...........................................................................................23
6.2.3. Performance...................................................................................................23
6.2.4. Gesamtkosten.................................................................................................23
6.2.5. Visuelle Entwicklungsumgebung...................................................................24
6.2.6. Usability.........................................................................................................24
6.2.7. Portierbarkeit..................................................................................................24
6.3. Bewertung der Anforderungen..............................................................................25
7. Technische Analyse.....................................................................................................26
7.1. Ermittelte Lösungen..............................................................................................26
7.1.1. WebDynpro FlashIsland-Technology............................................................27
7.1.2. Xcelsisus SAP NetWeaver BI Anbindung mittels BICS...............................27
7.1.3. Flex-Applikation auf Basis von SAP GRC Webservices..............................28
7.2. Bewertung der Lösungen.......................................................................................29
8. Entwicklungspotentiale von Infrastrukturen für Echtzeit-Reporting........................31
Print-Quellen......................................................................................................................33
Elektronische Quellen........................................................................................................33
Sonstige Quellen.................................................................................................................34
Elektronisches Anhangsverzeichnis.................................................................................35
Elektronisches Anhangsverzeichnis
1. Motivation
„Eine gründliche, eigenständige Risikoprüfung hat offenbar nicht mehr
stattgefunden. Stattdessen wurden höchst risikoträchtige
Handelsgeschäfte im Schweinsgalopp getätigt.“ (Bahnsen 16.08.2009 Q.
9). Diese Aussage aus einem Artikel der Welt Online über das Risikomanagement der
HSH Nordbank beschreibt ein Verhalten, dass einen wenig rationalen Umgang mit
Risikodaten anprangert. Es wird jedoch selten auch im Zusammenhang der aktuellen
Finanzkrise selten betrachtet, dass speziell deutsche Banken im Zuge von gesetzlichen
Vorschriften, wie BASEL 2 1 eine Vielzahl von risikorelevanten Daten für zahlreiche
Geschäftsprozesse, insbesondere dem Kreditvergabeprozess sammeln müssen. Es stellt
sich nun die Frage, weshalb trotz der gesetzlichen Rahmenbedingungen offensichtlich die
Auswertung von Risikodaten oft falschen Entscheidungen in Kreditvergabeprozessen
führte.
Ein Wettbewerbskriterium im Finanzgeschäft ist die Geschwindigkeit, mit der

risikokritische Entscheidungen getroffen werden. Dieses Kriterium steht konträr zu einer
dezidierten, oft zeitintensiven und individuellen Aufbereitung von Daten für strategisch
relevante Informationen eines Geschäftsvorfalls. Entscheidende Werte, sog.
Schlüsselindikatoren bzw. im Risikomanagement als KRI2 bezeichnet definieren sich als
Ergebnis einer strukturellen Aufbereitung, der zu einem Geschäftsvorfall gesammelten
Daten. Die Interpretation dieser Daten kann aufgrund der hohen Komplexität der
Abhängigkeiten und dem unterschiedlichen Aussagehalt dieser Schlüsselindikatoren in
unterschiedlichen Geschäftsvorfällen meist nur vom Menschen geleistet werden. Zur
Exzerption notwendiger Informationen wird deshalb eine angemessene Visualisierung
benötigt, die eine individuelle Bewertung eines entscheidungsrelevanten Vorfalls zulässt.
Anhand der Risikobewertung innerhalb von Kreditvergabeprozessen ist leicht
nachzuvollziehen, weshalb standardisierte Visualisierungen von Schlüsselindikatoren
meist nur eingeschränkte Aussagekraft für den konkreten Fall aufweisen können. So gibt
es bei der Bewertung von Kreditrisiken zahlreiche Faktoren, die weit mehr als die schlichte
Auswertung von Bilanzdaten umfasst. So könnte eine umfassende Risikobewertung auch
das
• Marktrisiko der Branche, ggf.

• Währungs- und Wechselkursrisiken, die
• Vertriebsstruktur, oder die
• Risikovorsorge
eines möglichen Schuldners, um nur wenige Beispiele zu nennen betrachten. Um nun
speziell im Umfeld von SAP Business Objects Gouvernance Risk and Compliance
Anwendungen (in Folge GRC) eine bessere Vereinbarkeit der Ziele einer niedrigen
Entscheidungszeitspanne und einer hohen Entscheidungsqualität für den Kunden zu
1 BASEL 2:Gesamtheit der Eigenkapitalvorschriften, vorgeschlagen vom Basler Ausschuss für Bankenaufsicht. Seit 01. Januar 2007
EU Richtlinie
2 KRI: Key Risk Indicator, Wert zur Risikobewertung einer Aktivität
ermöglichen, wird eine technische Infrastruktur benötigt. Diese soll das einfache und
schnelle Erzeugen und Ausführen von qualitativ hochwertigen Datenvisualisierungs-
Anwendungen ermöglichen. Die Nutzerauthentifizierungen sollte mittels der SSO
-Unterstützung eines SAP NetWeaver Applikationsservers durchführbar sein.
1. Hinweise zur Struktur der Arbeit

Die folgende Arbeit ist im Rahmen einer Untersuchung von technischen Infrastrukturen
von SAP- und BusinessObjects-Technologien entstanden. Ziel ist es auch technische
Synergie-Effekte entstehend durch die Produktintegration von BusinessObjects-
Anwendungen in SAP-Produkten zu erkennen und dem Entwicklungsbereich
RiskManagement innerhalb der SAP nutzbar zu machen. Viele Ansätze zur Vereinigung
der Produkte aus beiden Unternehmen, sind noch in der Planungsphase, bzw. befinden sich
in einem Beta-Stadium ihrer Entwicklung. Somit sind einige der hier beschriebenen
Verfahren noch nicht offiziell dokumentiert, sondern in dem hier beschriebenen Kontext
nur vom Autor der Projektarbeit getestet worden. Weshalb andere Quellen als der Autor
bisweilen nicht aufgeführt werden können.
2. Beschreibung des SAP GRC

Anwendungsportfolios
Mit zwei Anwendungen der Marke SAP BusinessObjects sollen Unternehmen Risiken
ihres Geschäftsbetriebs bewertet und Gegenmaßnahmen planen können. Das Paket
RiskManagement ist als eigenständiges Werkzeug oder zusammen mit den üblichen
Unternehmensanwendungen als Datenquelle einsetzbar, sodass Anwender Risiken gemäß
eigener Einschätzung oder nach Auswertung von Schlüsselindikatoren einpflegen können.
Mit der Anwendung Process Control können SAP Nutzer anschließend Maßnahmen zur
Prozessabsicherung konzipieren, etwa zusätzliche Kontrollschritte im Arbeitsablauf oder
regelmäßige Stichproben. Die Anwendung hilft zusätzlich bei der Dokumentation der
Kontrolle etwa nach dem BilMoG3, dem amerikanischen SOX4, oder Basel 2. Laut
Hersteller befördern beide Pakete ganzheitliches Risikomanagement, indem sie sich
nahtlos an gängige Anwendungen zur Prozessmodellierung und Module einer SAP-
Installation koppeln lassen (vgl. Abs. Risiken im Griff 20.07.2009 Q. 6: S. 36).
Die Anwendung SAP GRC Access Control, wurde zur Verwaltung und Kontrolle von
Sicherheitsrelevanten Risiken, wie der Benutzerrollenverwaltung, dem Zugang zu
Geschäftstransaktionen und der Überwachung von Power-User Systemzugängen
entwickelt.“(vgl. END-TO-END ENTERPRISE COMPLIANCE 2008 Q. 10: S.
16). Die Intention der Zusammenstellung des SAP BusinessObjects GRC
Lösungsportfolios ist die Produktkategorien der Compliance und Risikomanagement
Lösungen möglichst vollständig als Standardsoftware anbieten zu können. Die Paketierung
der oben beschriebenen Anwendungen hat zum Ziel sowohl Risiken, als auch Prozesse
und sicherheitskritische Informationen in einem Unternehmen nach gesetzliche Maßgaben
und unternehmensinternen Richtlinien sowohl verwalten, als auch überwachen zu können.
3BilMoG: Bilanzrechtsmodernisierungsgesetz, deutsches Bundesgesetz, Ziel ist die Annäherung an internationale Bilanzstandards
4 SOX: Sarbanes-Oxley-Act, US-Bundesgesetz zur Förderung der Verlässlichkeit der Berichterstattung von Unternehmen am
Kapitalmarkt
3. Dashboards in GRC Anwendungen

Külpmann (2006 Q. 3: S. 100) erkannte, dass Kennzahlen den
Informationsempfängern mittlerweile immer häufiger online statt in Papierform zur
Verfügung gestellt würden. Die so Külpmann neuen Möglichkeiten der Darstellung von
Kennzahlen würden in der Praxis immer häufiger in Form von sog. Kennzahlen-Cockpits
(in Folge Dashboards) bzw. Kennzahlen-Dashboards eingesetzt.
Külpmann nimmt mit dieser Aussage Bezug auf die Vorteile von Echtzeit-Auswertungen
die mit unterschiedlichen Filtern, oder Darstellungen (z.B. Balken- und Kreisdiagrammen)
direkte Berichtserstattung auf Produktiv-Datenbestande erlauben. Dies lässt sich jedoch für
einen großen Teil der Berichtsumgebung analytischer Management- Informationssysteme
neueren Entstehungsdatums proklamiere. Der entscheidende Unterschied bei einer
Visualisierung in Dashboards ist der hohe Grad der Verdichtung der Daten, zu
Kennzahlen, die aufbauend auf ihrem ermittelten Wert eine Qualifizierung erfahren.
A b b 1 B u sin e ssO b je c ts R isk M an a g e m e n t O v e rv ie w -D a sh b oa rd
Typische Bestandteile von Dashboards sind sogenannte Ampel-, Armatur- und

Diagrammkomponenten. Einige UI5-Komponenten, im speziellen eine Darstellung mit
Ampelzielfarbe, wie auf der rechten Seite in Abbildung 1 zu erkennen qualifizieren die
angezeigten Kennzahlenwerte. Dieses Vorgehen soll das exzerpieren des entscheidenden
Informationsgehaltes der Kennzahlen für den Nutzer erleichtern und vereinheitlichen.
Für GRC-Anwendungen bilden Dashboards ein wichtiges Instrument, für die auf
Schlüsselindikatoren basierte Überwachung von Risiken und Prozessen. Laut Brühwiler
(2003 Q. 1: 24) verlange Risikomanagement Methoden und Techniken, die
Risikoerkennung, Risikobewertung, Risikobewältigung und Risikoüberwachung
ermöglichen. Speziell die Risikoüberwachung kann ab einer kritischen Maße von
risikobewertungsrelevanten Daten nur effektiv und rechtzeitig mittels Verfahren der
elektronischen Datenverarbeitung beherrscht werden. Brühwiler (2003 Q. 1: S. 19)
beschreibt Risikomanagement als Frühwarnsystem, das - wenn auch nicht in allen, so doch
5 UI: User Interface, bezeichnet die visuelle Mensch-Maschine-Schnittstelle
in vielen Situationen die Chancen für eine rechtzeitige Erkennung und Abwendung von
unerwarteten Fehlentwicklungen oder Ereignissen massiv erhöhen könne. Dieser vielleicht
schon präkognitive Anspruch an Risikomanagement-Anwendungen beruht auf das
Vertrauen in deterministischen Verfahren, deren Präzision i.d.R. proportional zur
eingesetzten Datenmenge und der korrekte Ergebnisinterpretation Seitens des
Risikomanagers ist. Wie komplex diese Interpretation ohne eine gemeinsame
Visualisierung von Risikoschlüsselindikatoren darstellen kann, will ich an folgendem
stark vereinfachten Beispiel erläutern:
Für die Bewertung des Risikos einer Kernschmelze in einem Atomkraftwerk mit 16
Brennstäben sei angenommen, dass die folgenden Risikoindikatoren von besonderem
Belang sind:
• Temperatur des heißesten Brennstabes

• Durchschnittlicher Siedewasserdruck
• Voraussichtliche Menge an Kühlwasser.
Im obigen Beispiel ergibt sich schnell die Frage, wie diese Informationen innerhalb eines
definierten Handlungsfensters so aufbereitet werden können, dass ein Verantwortlicher mit
größtmöglicher Wahrscheinlichkeit im Falle einer Fehlentwicklung rechtzeitig
Maßnahmen zur Abwendung des Risikoeintritts durchführt. Ohne eine klare Visualisierung
der 3 angeführten Indikatoren könnte das Exzerpieren der notwendigen Werte zu viel Zeit
in Anspruch nehmen, um rechtzeitig handeln zu können. Ein wenig gelungene Darstellung
des ersten Indikators wären z.B. 16 einzelne Temperaturanzeigen der Brennstäbe einem
Nutzer zu präsentieren. Auch in diesem Fall, hätte die Komponente Mensch zwar die
Möglichkeit die notwendige Information zu entnehmen, jedoch unter deutlich erschwerten
Bedingungen.
1. Flex-Technologien für webbasierte

Dashboards
Statische Webanwendungen stoßen für die Entwicklung von Dashboards schnell an
gegebene Grenzen. So wäre bei der Implementierung von statischem HTML6 asynchrones
Ladeverhalten, oder effektunterstütze Visualisierung von Daten nicht möglich (vgl.
w3c.org 2009 Q.15). Webbasierte Dashboards sind aus diesen Gründen i.d.R. dem
Typus von RIAs 7zuzuordnen. Es gibt mittlerweile einige Technologien, die die
Implementierung von RIAs ermöglichen. Diese Technologien lassen sich grundsätzlich in
• Proprietären Standards, wie z.B. Adobe Flash und Microsoft Silverlight, oder
• Offene Standards, wie z.B. JavaFX8
unterteilen. Nach der Aussage des Entwicklungsleiters der SAP Business Objects GRC
Anwendung RiskManagement Dr. Gero Mäder, beruhe die Entscheidung für die
Verwendung des Adobe Flex-Frameworks, für die Implementierung der Dashboards des
Standardproduktportfolios auf den optisch ansprechenden und zahlreichen
6 HTML: Hypertext Markup Language; Beschreibungssprache des World Wide Web

7 RIA: Rich Internet Application; Internetanwendungen, die Nutzerinteraktionen asynchron behandeln
8 JavaFX: Eine von Sun Microsystems, auf der Java-Plattform basierte Technology für RIAs http://www.javafx.com/
Diagrammkomponenten und Visualisierungseffekten, die dieses Framework liefern würde.

Neben der zahlreichen Verbreitung des FlashPlayers als Browser-Plugin, der als
Laufzeitumgebung diene. Diese Vorteile sollten dem Kunden wenn möglich bei der
Erstellung von individuellen Dashboards ebenfalls zuteilwerden.
1.1. Architektur von Flex-Applikationen
Laut Kazoun und Lott (2008 Q. 2: S. 3) repräsentiere Flex ein Framework bzw. eine
Klassenbibliothek aus sog. ActionScript Klassen. ActionScript sei dabei die
Programmiersprache, die für die Ausführung einer Flex-Applikationen, im Adobe
FlashPlayer kompiliert werden könne.
A b b 2 Fle x so u rc e -co m p ile -d e p lo y w o rk floKw

a zou
( n 20 08 Q 2 : S . 1 0)
Wie in der Abbildung 2 zu sehen, kann der Quellcode einer Flex-Applikation aus 3
unterschiedlichen Komponenten bestehen.
• ActionScript in Version 3 ist wie auch von Kazoun und Lott (2008 Q. 2: S. 47)
beschrieben, eine objektorientierte Programmiersprache, mit starken Anlehnungen
an Java. Die Flex Klassenbibliothek bietet 3 zu unterscheidende API9-Gruppen.
○ FlashPlayer APIs, die den Zugriff auf die Laufzeitumgebung erlaubt und
somit auch z.B. auf Teile des Betriebssystems des Clients. Zum anderen auf
die
○ Flex framework APIs, die eine Abstraktionsschicht auf Basis der
FlashPlayer APIs repräsentiert. Sie stellen neben zahlreichen UI-
Komponenten auch Schnittstellen zum konsumieren von Webservices und
9 API: Application Programming Interface, Programmierschnitstelle zur Anwendungsentwicklung
Datentypen zur Repräsentation von u.a. XML Daten zu Verfügung.

Zusätzlich gibt es ähnlich wie in Java die Möglichkeit,
○ Benutzerdefinierte Schnittstellen zu implementieren.
• MXML, das laut Kazoun und Lott (2008 Q. 2: S. 35), als eine deklarative
Beschreibungssprache, stark angelehnt an XHTML10 ist. Dieses Prinzip ermöglicht
auch den Einsatz der von Adobe vertrieben IDE11 FlexBuilder als WYSIWYG-
Editor12, der im Hintergrund MXML-Programmcode erzeugt.
• Assets z.B. einige Mediendateitypen, oder weitere Flash-, oder Flex-Applikationen
in kompilierter Form als swf-Datei 13eingebunden werden.
So entsteht eine Flex-Applikation wie in dem in Abbildung 2 auf Seite 13 dargestellten
Prozess. Aus dem Quellcode entsteht ein generierter Code, der die MXML-
Implementierung in kompiliertes ActionScript wandelt und in Folge mit etwaigen Assets
einen Bytecode in Form einer swf-Datei deployt.
Üblicherweise kann nun eine browserbasierte Flex-Anwendung z.B. in HTML eingebettet

werden. Während der Client-Server-Kommunikation wird die swf-Datei per HTTP14-
Request übermittelt und clientseitig vom Flash Player ausgeführt. Neben der Möglichkeit
den FlashPlayer als Laufzeitumgebung zu nutzen, können Flex-Anwendungen mit
geringfügigen Änderungen auch auf dem Desktop mittels Adobe AIR15 ausgeführt werden.
Vergleichbar mit der Java Laufzeitumgebung bestünde hier nach Kazoun und Lott (2008
Q. 2: S. 551) die Möglichkeit plattformunabhängige Desktop-Applikationen zu
entwickeln.
1.1. Grafische Entwicklungsumgebungen
Mit dem Ziel dem Kunden eine messagebasierte SSO Infrastruktur zur Erstellung von
Dashboards unter der Verwendung von UI-Komponenten auf Basis von Adobe Flex
anzubieten, ergibt sich die Frage, mit welchen Hilfsmitteln sich ein Dashboard möglichst
einfach und schnell erstellen ließe. Unter der Annahme, dass der Kunde möglicherweise
nicht über Wissen und Fähigkeiten verfügen sollte Flex-Applikationen auf Quellcodeebene
mit der Anbindung an die beschriebene Infrastruktur zur Ausführung der Dashboards zu
entwickeln, bleibt als Alternative die Verwendung eines WYSIWYG-Editors16. Also eines
Editors, der Flex-Applikationen mittels grafischer Unterstützung, die Auswahl von UI-
Komponenten und deren Konfiguration ermöglicht, ohne detailliertes Wissen über die
Implementierung von Software zu benötigen.
Im Folgenden werden 2 Editoren betrachtet, die diesen Anspruch für Flex-Applikationen

erfüllen könnten.
10 XHTML: Extensible HTML, von der w3c formulierte Beschreibungssprache, soll Vorteile von HTML 4 und XML 1.0 vereinen
11 WYSIWYG-Editor: What you see is what you get Editor, Werkzeug für Realisierung von Nutzeroberflächen
12 IDE: Integrated Development Enviroment, integrierte Softwareentwicklungsumgebung
13 swf-Datei: Shockwave Flash-Datei, Binär-Datei, die vom Adobe FlashPLayer ausgeführt werden kann
14HTTP: Hyper Text Transfer Protocoll, Netzwerk-Protokoll für die Datenübermittlung, Häufig für Webanwendungen verwendet
(w3c 2009 Q.15)
15 AIR: Adobe Integrated Runtime, Desktop-Laufzeitumgebung von Flex-Applikationen
16 WYSIWYG-Editor: What you see is what you get Editor
1.1.1. SAP Business Objects Xcelsius 2008 Engage
Das Produkt SAP Business Objects Xcelsius (in Folge Xcelsius), ist ein kommerzielles
Werkzeug, das mit der konkreten Intention entwickelt wurde dem Kunden das entwickeln
grafische Oberflächen für die Visualisierung der Auswertungen von Management-
Informationssystemen zu ermöglichen. Somit ist hier die Entwicklung von Dashboards
formulierter, zentraler Aufgabenbestandteil. Diese Entwicklungsumgebung bietet ein
Portfolio, an speziell auf Dashboards angepasste UI-Komponenten und Templates, mit
verschieden Design-Themen, und Exportmöglichkeiten z.B. in HTML, Adobe pdf oder
Microsoft Power Point. Mit der Version ab 2008 bietet Xcelsius auch einen SDK für die
Entwicklung von eigenen Komponenten an. Hierbei handelt es sich um ActionScript
Bibliotheken, die bei der Realisierung neuer Komponenten eingesetzt werden müssen.
Neue Xcelsius-Komponenten lassen sich in das bestehende Repository als swf-Datei
importieren.
Mit dem Kauf des Spezialisten für Management-Informationssysteme BusinessObjects im

Jahr 2008 begann SAP mit der Integration der Business Objects Produkte in das
bestehende Lösungsportfolio der SAP BI17 Produkte, unter dem Namen SAP
BusinessObjects BI Solutions. Dies führte bisher auch zu einigen technischen
Entwicklungen auf Seiten Xcelsius. Betrachten wir nun, welche Datenquellen, um nur
wenige der insgesamt 12 Möglichkeiten zu nennen angebunden werden können. Die
technische Grundlage für speziellere Formen der Datenkonsumierung bilden wie folgt:
• Microsoft Excel-Tabellen, die statisch eingebunden werden, oder dynamisch

Webservices, in Form von
• Klassischen Webservice Anbindungen, oder als
• Query as a Webservice Daten in der tabellarischen Form einer DataWarehouse
Query. Ebenfalls möglich ist die Anbindung an
• Flash Variablen, dies ermöglicht unteranderem die bidirektionale
Kommunikation von kaskadierten Flashkompilierten Xcelsius-Applikationen
und Flex-Applikationen.
Als Folge der Integration in das SAP BI Portfolio entstanden auch Schnittstellen für die
Anbindung an SAP-Systeme. Hervorzuheben ist hier die von Ackermann und Sessler
(2009 Q. 7: S. 12) beschriebene Möglichkeit eines Remote-Webservice basierenden
Query as a Webservice Aufrufes, mit Anbindung an ein SAP BI Query. Die dabei
verwendete Schnittstelle wird in Kapite7.1 näher beschrieben.
Die Modellierung eines Dashboards erfolgt nach einer Abstrahierung der Daten auf eine 2-
dimensionale Tabelle, auf Basis eines Microsoft Excel Tabelleninstanz, die anbhängig von
der installierten Office Version (Eine Systemvoraussetzung ist die Installation von
Microsoft Office 2003 oder 2007) als Excel Tabelleninstanz in die Entwicklungsumgebung
eingebunden wird. Dies vereinfacht das Anbinden, an die jeweiligen UI-Komponenten
17 BI: Business Intelligence, System für die Geschäftsanalyse
zwar stark, da die Auswahlen von Tabellenbereichen als Datenquellen dient. Jedoch
können komplexe Daten und Datenstrukturen teilweise nur, mit hohem Aufwand in dieses
Schema überführt werden. So lässt sich das Abbilden von Hierarchien, oder Kapselungen,
oft nicht generisch lösen. Es muss für den konkreten Anwendungsfall womöglich ein
eigenes Konzept zur Überführung der Daten in eine 2-dimensionale Darstellung entwickelt
werden. Weshalb auch eine Verwendung von Xcelsius in einer SOA18 Umgebung nicht
vorgesehen. Weshalb Xcelsius explizit dem nicht SOA basierten Lösungsportfolio von
SAP BI zugeordnet wird und nach Aussage des Business Objects Integrationsmanagers
Olaf Fischer (30.06.2009 Q. 16) auch keine Schnittstelle zum SAP Enterprise Service
Repository geplant ist.
Durch dieses Datenkonzept auf Basis von Microsoft Excel ergeben sich auch weiter
Restriktionen im Bezug auf Datenvolumina und Datentypen. So können z.B. keine
Mediendaten, wie Bilder oder Videodaten bei Laufzeit über eine der beschriebenen
Schnittstellen gestreamt werden. Diese müssten entweder zur Designzeit als Asset
hinzugefügt, oder mittels der Integration einer Flex-, oder Flash-Applikation konsumiert
werden. Auch muss die Beschränkung an Zeilen und Spalten von Microsoft Excel,
abhängig von der jeweiligen Version beachtet werden.
18 SOA: Service Oriented Architecture, Softwarekonzept für die Strukturierung von Sevices verteilter Systeme
RESTRIKTION MS EXCEL 2003 MS EXCEL 2007

Maximale Anzahl Zeilen 65.536 1.048.576
Maximale Anzahl Spalten 256 16.384
Arbeitsspeicherverwaltung max. 1 GB 2 GB
T a b 1 X c e lsiu s re le v a n te U n te rsc h ie d e zw isch e n M ic ro so ft Ex ce l 20 03 u n d 2 00 7
(v g l. M ic ro so ft 2 0 09 Q . 1 2 )
Nach Xcelsius wir im folgenden Kapitel der Adobe Flex-Builder als grafische
Entwicklungsumgebung für Flex-Applikationen betrachtet.
1.1.1. Adobe Flex Builder 3 Professional
„Flex Builder is the official Adobe IDE for building and debugging Flex
applications. Built on the popular Eclipse IDE” (Kazoun 2008 Q. 2: S. 5).
Wie Xcelsius ist der Adobe Flex Builder ebenfalls ein kommerzielles Produkt. Jedoch
bietet Adobe auch einen freien SDK19 für Flex-Applikationen an. Dieser bietet keine
WYSIWYG-Funktionalität, lässt sich aber in die ebenfalls freie Eclipse Classic 3.x IDE
integrieren. Der Flex Builder liefert wie von Kazoun und Lott (2008 Q. 2: S. 5)
beschrieben das Flex-Framework, also alle von Adobe veröffentlichten Flex- und Flash
ActionScript Klassenbibliotheken standardmäßig aus. Eigene Bibliotheken können
vergleichbar mit Java in Eclipse als Bibliotheken erstellt und mit in einer projektbasierten
Paketverwaltung organisiert werden.
Die Professional-Version erweiterte die Funktionalitäten der IDE laut Adobe (2009 Q.
8) um Testwerkzeuge für die Performance- und Speicheroptimierung, sowie um eine
interaktive Datenvisualisierung von Diagramm-Komponenten und Datenquellen, mittels
Drag&Drop-Funktionalität. Jede Komponenten aus der Flex Bibliothek besitzt zudem ein
grafisches Eigenschaften-Menü, mit der alle Parameterwerte der Komponente gesetzt
werden können.
Im Gegensatz zu Xcelsius bestehen hier keine Einschränkungen durch eine

Datenabstraktion in eine 2-dimensionale Tabellen-Darstellung. Die im Flex-Framework
enthaltenen UI-Komponenten sind relativ generisch. So können als Datenquellen für
Diagramme XML-Formate, Arrays oder ähnliches verwendet werden.
Nach Beschreibung beider IDEs wird nun ein konkreter Vergleich relevanter
Entscheidungsparameter auf Basis der Erstellung von kundenspezifischen Dashboards für
GRC-Anwendungen durchgeführt.
19 SDK: Software Development Kit, Sammlung von Werkzeugen für die Programmentwicklung
1.1.2. Gegenüberstellung der grafischen Entwicklungsumgebungen
Die folgende Tabelle soll einen Überblick über relevante Kriterien für eine Eignung der
jeweiligen Entwicklungsumgebungen zum erstellen kundenspezifischer Dashboards
liefern. Hier ist zu bemerken, dass nicht zu quantifizierende Kriterien durch die
Erfahrungen des Autors mit beiden Entwicklungsumgebungen in einem 5-Skalen-
Bewertungssystem von (++ sehr erfüllt) bis (-- nicht erfüllt) festgelegt wurden.
SAP BUSINESS ADOBE FLEX BUILDER

OBJECTS XCELSIUS 3 PROFESSIONAL
BEWERTUNGSKRITERIEN
2008 ENGAGED
++ + 0 - -- ++ + 0 - --
Q UA Das hboar d Indi vi dual it ät x x
LITA Erweiterbarkeit x x
TIVE
Entwicklungsgeschwindigk
FAK x x
eit
TOR
EN
Dokumentation x x
Adobe AIR
Q UA Ja Ja
kompilierungsfähig
NTIT
ATIV SAP
Ja Nein
E Integrationsunterstützung
FAK
Einmalige Lizenzkosten
TOR
(Download; Stand 839,95 € 593,81 €
EN
22.08.2009)
T a b 2 P u n k tb e w e rtu n g sm a trix fü r X ce lsiu s u n d F le x B u ild e r 3
Eine ausgewogene Bewertung durchzuführen bedarf hier eines abstrakten Ansatzes. Da es

sich zwar in beiden Fällen um Entwicklungsumgebungen für Flash-Applikationen unter
Nutzung des Flex-Frameworks handelt sind beide Werkzeuge im formulierten
Nutzerkontext und ihrer Spezifität verschieden. Die in Tabelle 3 vorgenommene
Bewertung ist deshalb nur im Bezug auf den beschriebenen Usecase, der
kundenspezifischen Entwicklung von Kennzahlen Cockpits für GRC-Anwendungen zu
betrachten.
Als Resümee kann gezogen werden, dass Flex Builder 3 Professional trotz grafischer
Unterstützung eher ein Werkzeug für Softwareentwickler ist, da recht zügig Grenzen für
einen Nutzerkreis erreicht werden, die keine Kenntnisse über grundsätzliche Sachverhalte
der Software- und Web-Anwendungsentwicklung (z.B. Paketmanagement, Client-Server-
Architektur, Webservices) besitzen. Dafür erlaubt dieses Werkzeug ein weit größeren
Spielraum beim Umgang und der Visualisierung der Daten.
Neben der Vielzahl von Templates und der einfachen, wenn auch einschränkenden
Datenanbindung an UI-Komponenten, liegt der entscheidende Vorteil in den
Möglichkeiten der Interaktion mit dem SAP BI Produkten. Dieser Vorteil könnte auch für
erfahrene Entwickler auf Seiten des Kunden ausschlaggebend sein Xcelsius zu nutzen, da
ansonsten detaillierte Kenntnisse sowohl über SAP BI Schnittstellenkonzepte, als auch
über das Flex-Framework benötigt würden.
2. Anforderungsanalyse
Nachdem nun der Usecase ermittelt und beschrieben wurde. Ebenso Hilfsmittel für dessen
Realisierung beurteilt wurden. Bedarf es nun einer Analyse welche Anforderungen eine
technische Infrastruktur, zur Erfüllung der Kundenbedürfnisse in diesem Anwendungsfall
erfüllen sollte. Im Folgenden wird hier eine Trennung zwischen funktionalen und nicht-
funktionalen Anforderungen durchgeführt. Die Identifizierung von Anforderungen erfolgte
indes nicht über eine direkte Kundenkommunikation, sondern in einem Evalutionsprozess
des Autors, mit zwei Mitarbeitern der SAP BusinessObjects RiskManagement
Entwicklungsgruppe, Dr. Gero Mäder und Alexander Wussow. Anzumerken ist, dass es
sich auf einer rein kognitiven Anforderungsanalyse in prä-prototypischem Stadium
handelt.
2.1. Funktionale Anforderungen
Funktionale Anforderungen beinhalten die zur Nutzung notwendigen Funktionen der

beschriebenen Infrastruktur.
2.1.1. Webbasierte Berichtserstattung
Dashboards sind Managementwerkzeuge, die der Entscheidungsfindung dienen sollen.

Wie in der Motivation dieser Arbeit beschrieben, formuliert sich der Anspruch an
Entscheidungsträger in Unternehmen in einem möglichst kurzen Prozess Entscheidungen
hoher Qualität zu treffen. Dies bedeutet für Management-Informationssysteme, dass sie
möglichst ubiquitär und aktuell Daten aufbereiten und zur Verfügung stellen sollten. Das
Medium, dass Daten nahezu zu jeder Zeit und weltweit zur Verfügung stellen kann, ist das
Internet. Da Webbrowser in Client-Betriebssystemen weit verbreitet sind, soll diese als
Interpretationsschicht der Webanwendung dienen. Etwaige Interpretationsproblem
unterschiedlicher Webbrowser können in diesem Stadium nicht berücksichtigt werden.
2.1.2. Benutzer Authentifizierung durch der NetWeaver RBAC20
Die Nutzung des vorgestellten Infrastrukturkonzepts setzt die Nutzung des SAP
Applikationsservers NetWeaver voraus. Dieser verwendet als Verfahren zu Identifizierung
eines Nutzers eine Rollenbasierte Zugangsverwaltung. Um weltweit als
Unternehmenslösung verkauft zu werden, muss NetWeaver eine die gesetzlichen
Anforderungen erfüllende Zugangskontrolle zu Unternehmensdaten gewährleisten. Um die
Akzeptanz eines Kunden für den Einsatz der Lösung zu fördern, darf mit deren Einsatz
kein erheblicher Mehraufwand für die Gewährleistung von gesetzlichen Standards und
unternehmensinternen Richtlinien der Datensicherheit entstehen.
20 RBAC: Role based Access Control, Rollenbasierte Zugriffsüberwachung für Anwendungen
2.1.3. Single-Sign-On Anmeldeverfahren
Sofern der Kunde eine SSO Infrastruktur besitzt, sollte er sie auch im Rahmen der
Verwendung eigens erstellter Dashboards nutzen können. Nach Mezler-Andelberg (2008
Q. 4: S. 250) steige nicht nur der Komfort, wenn sich ein Benutzer für alle
Applikationen nur noch ein Passwort merken müsse, sondern es spare auch Zeit. Dies kann
zu einer Kostenreduktion der IT-Kosten des Unternehmens beitragen kombiniert mit
steigendem Komfort für Nutzer mehrerer Systeme.
2.1.4. Identifizierungs- und Authentifizierungsmanagement
Exemplarisch wir in Folge die Bedeutung von Datensicherheit und Identity Management
(in Folge IDM 21) für SAP GRC-Anwendungen anhand des Anwendungsbereichs
RiskManagement erläutert.
„Wir verstehen Risk Management als ein Führungsinstrument, das die

Risiken frühzeitig erkennt und Maßnahmen gegen Fehlentwicklungen
oder Schadenereignisse rechtzeitig einleitet, um das Unternehmen vor
Unheil zu bewahren.“ (Brühwiler 2003 Q. 1: S. 19).
Brühwiler beschreibt mit seiner Aussage damit einen oft vernachlässigten Aspekt des
Risikomanagement. Risikodaten sind Daten mit strategische Bedeutung und
Informationsgehalt, da sie als Ergebnis eines strategischen Analyseprozesse zu betrachten
sind und als Grundlage für Planungsprozesse dienen. Sie können Aufschluss geben, mit
welcher Perspektive Verantwortliche die aktuelle Lage und zukünftige Entwicklungen
eines Unternehmens betrachten. Neben den Bilanzdaten könnten Risikodaten für die
Vorhersagen der Entwicklung eines Unternehmens aus der Perspektive eines Analysten
sehr wertvoll sein.
Neben der sicherheitsstrategischen Relevanz die abhängig vom Unternehmen

unterschiedlich ausgeprägt sein kann, müssten laut Mezler-Andelberg (2008 Q. 4: S.
189) jedoch auch offizielle Vorgaben für IDM erfüllt werden. Geläufig ist dies unter dem
Begriff Compliance. In Folge wir anhand des SOX22 eine Betrachtung von Compliance-
Anforderungen speziell im Bereich der Datensicherheit erfolgen. Laut Mezler-Andelberg
(2008 Q. 4: S. 193) ließen sich folgende Forderungen an die zu gewährleistende
Datensicherheit in Unternehmen wie im folgenden Abschnitt formulieren.
• Es muss sichergestellt sein, dass nur authentifizierte Personen mit dem System
arbeiten. Dazu sind die Methoden der Systeme zu prüfen. Auch ist sicherzustellen,
dass ein Benutzeraccount jeweils nur von einer Person verwendet wird.
• Zugriffsverletzungen müssen aufgezeichnet werden.
• Berechtigungen für die Systeme müssen regelmäßig geprüft werden.
• Sensible Daten werden gegen unberechtigten Zugriff oder unberechtigte Änderung
geschützt.
21 IDM: Identity Management, Summe aller Maßnahmen für die Datensicherheit und Zugangskontrolle
22 SOX: Sarbanes-Oxley-Act, US-Bundesgesetz; formuliert Bilanzierungs- und Sicherheitsrichtlinien für Unternehmen am
Kapitalmarkt
Diese Formulierungen bieten einen großen Spielraum für Interpretation.
Nach Mezler-Andelberg (2008 Q. 4: S. 193) ließe sich für Authentisierungsmethoden

aus SOX lediglich entnehmen, dass die ausreichend sicher sein müssten (regelmäßiger
Passworttausch, sichere Passwörter usw.). Folglich sollte das Bestreben sein, bestehende
Sicherheitsstandards in Unternehmen nicht durch die Verwendung von kundenbasierten
Dashboards aufzuweichen und Sicherheitsentwicklungen nicht zu behindern.
1.1. Nichtfunktionale Anforderungen
Im Bereich der nichtfunktionalen Anforderungen wird werden sogenannte

Qualitätsindikatoren betrachtet. Sind beinhalten keine Funktionalität im eigenen Sinne,
sind aber entscheidende Faktoren für den Einsatz von Software
1.1.1. Flexibilität
Flexibilität wird insbesondere im Bezug auf die Modellierung der benötigten Daten des
Dashboards gefordert. Wie beschrieben, ist es ein Merkmal von Dashboards, dass sie
anwendungsübergreifend und ggf. Systemübergreifend Kennzahlen eines Unternehmens
visualisieren können sollten.
1.1.2. Ausfallssicherheit
Im Bezug auf die Ausfallssicherheit ist zwischen dem Prozesse der Erstellung von
Dashboards und deren Nutzung zu unterscheiden. Grundsätzlich ist die Nutzung hier von
entscheidenderer Bedeutung für die Bewertung der Ausfallssicherheit. An sie wird die
Forderung gerichtet, als webbasierte Lösung möglichst ubiquitär zur Verfügung zu stehen.
Ein Konservativer, aber auch erfolgreicher Weg zur Erfüllung dieser Anforderung ist den
Einsatz bereits vorhandener, bereits getesteter Technologien zu forcieren.
1.1.3. Performance
Für die Nutzer-Akzeptanz von kundenerzeugten Dashboards muss von ähnlichen

Anforderungen im Bezug auf die Ausführungs- und Anzeigegeschwindigkeit ausgegangen
werden, wie sie bei Verwendung einer Standardsoftware erwartet werden. Eine exakte
Quantifizierung der Anzeigegeschwindigkeit kann nur schwer angegeben werden, da diese
auch vom Design der Dashboards durch den Kunden abhängt. Weshalb Maßnahmen zu
Unterstützung der Performance betrachtet werden sollten. Hier einige Maßnahmen, die den
Kunden in seinen Performanceanforderungen unterstützen sollten. Der Kunde sollte
sowohl eine
• Aggregation und Komprimierung, wie eine hohe

• Selektivität im Bezug auf seine Daten nutzen können. Also möglichst nur Daten
abfragen müssen, die er benötigt.
Ziel sind möglichst kurze Übertragungszeiten zwischen Client und Server und eine
verhältnismäßig kleine Beanspruchung des Client-Arbeitsspeichers.
Eine serverseitige
• Persistierung von Daten sollte gewährleistet werden können, um zeitintensive

Datenbankzugriffe zu vermeiden und damit die Ausführungsgeschwindigkeit zu
erhöhen.
1.1.1. Gesamtkosten
Die Gesamtkosten, geläufiger als TCO23 einer Investition zur Verwendung einer
Infrastruktur für die kundenbasierte Modellierung von Dashboards, sollte möglichst
niedrig ausfallen. Als Anbieter dieser Lösung besteht die Möglichkeit Einfluss auf
• Lizenzkosten der benötigten Anwendungen/Produkte, die

• Wartungsfähigkeit der Software, den
• Supportkosten und der
• Integrationsfähigkeit
einer Softwarelösung zu nehmen. Aus dieser Erkenntnis lässt sich folgender Leitsatz für
die Anforderung der niedrigen TCO bilden.
Verwende Technologien und Produkte, die Kunden bereits einsetzen. Diese sind bereits in
die IT-Umwelt des integriert, müssen nicht mehr lizenziert werden und besitzen i.d.R.
bereits Supportverträge.
1.1.1. Visuelle Entwicklungsumgebung
Grafische Entwicklungsumgebungen sollten für die Nutzung der Lösung verwendet

werden können, um wenig technisch versierten Nutzer keine Nutzungs-Barriere zu
schaffen. Sie steht dabei in enger Beziehung mit der folgenden Anforderung. Detaillierte
Gründe für diese Anforderung sind in Kapitel 5.2 beschrieben.
1.1.2. Usability
Der Nutzer sollte in Zusammenarbeit mit einer grafischen Entwicklungsumgebung in die

Lage versetzt werden den Prozess zur Erstellung eines Dashboards mit möglichst geringem
Schulungsaufwand durchführen zu können. Auf diesen Aspekt kann SAP als Hersteller nur
beim Einsatz von SAP BusinessObjects Xcelsius Einfluss nehmen. Zu prüfen ist hier in
Zusammenarbeit mit Kunden, Mitarbeiter welchen Profils sich mit der Erstellung von
Dashboards auf Basis dieser Lösung beschäftigen würden. Für die Usability der eigenen
Dashboards trägt natürlich der Kunde die Verantwortung.
1.1.3. Portierbarkeit
Bei Verwendung des SAP BusinessObjects GRC Produktportfolios, kann grundsätzlich ein
NetWeaver-Applikationsserver vorausgesetzt werden. Somit sollte die Lösung auf jedem
NetWeaver-Applikationsserver mit den nötigen Systemanforderungen portiert werden
können. Grundsätzlich ist aber auch bei großen Unternehmen, unter dem Aspekt eines
23 TCO: Total Cost of Ownership; Gesamtkosten einer Investition und Nutzung eines Gutes
unternehmensübergreifenden Risikomanagements, nicht von einer Vielzahl an NetWeaver

basierten Management-Informationssystemen auszugehen.
1.2. Bewertung der Anforderungen
In Tabelle 3 erfolgt nun eine Bewertung der exzerpierten Anforderung anhand eines 5-
Punkte-Bewertungssystem. Indikator ist die Wichtigkeit der analysierten Anforderungen,
für den Einsatz der Lösung. (++) indiziert dabei sehr wichtig, (--) signalisiert ein geringe
Bedeutung der Anforderungserfüllung.
WICHTIGKEIT
ANFORDERUNG
++ + 0 - --
1. Webbasierte Berichtserstattung x
FU 2. Benutzer Authentifizierung
x
NKT NetWeaver RBAC
ION 3. SSO-Anmeldeverfahren x
AL 4. Identifizierungs- und
x
Authentifizierungsmanagement
NI 5. Flexibilität x
CHT 6. Ausfallssicherheit x
- 7. Performance x
FU 8. Gesamtkosten x
NKT 9. Visuelle Entwicklungsumgebung x
ION 10. Usability x
AL
11. Portierbarkeit x
T a b 3 G e w ic htu n g d e r Lö su n g s-A n fo rd e ru n g e n
Bisher unbekannte technische Beschränkungen, oder differenzierte Anforderungskriterien

des Kunden, konnten in diese Bewertung noch nicht einfließen. Somit ist diese Bewertung
als Ergebnis der Usecase-Auswertung der Lösung Versuchs zu betrachten.
1. Technische Analyse
Nach Ermittlung und Analyse der Anforderungen einer möglichen Lösung, sollte eine
analytische Betrachtung der bestehenden technischen Infrastruktur des SAP
BusinessObjects GRC-Anwendungsportfolio erfolgen. Voraussetzung für den Einsatz eine
SAP GRC-Lösung ist der NetWeaver-Applikationsserver. Die folgende Darstellung soll
den Aufbau des SAP NetWeaver 7.0 EHP 241 beschreiben, dieses System ist im Folgenden
auch Grundlage der Untersuchung.
A b b 3 SA P N e tw ea v e r K o m p on e n ten -Ü be rsich t (SA P A G 20 09 Q . 14 )
Das Prinzip des NetWeaver beruht auf der Absicht, sowohl technische Laufzeitumgebung
(in Abbildung 3 APPLICATION PLATFORM), als auch Anwendungsübergreifenden
Lösungen und Schnittstellen für die Integration der übrigen Systemlandschaft des Kunden,
in einem System zur Verfügung zu stellen. Die möglichen Schnittstellen der SAP
BusinessObjects GRC-Lösung sind durch den NetWeaver Applikationsserver definiert.
1.1. Ermittelte Lösungen
Im Folgenden werden nun technische Infrastrukturen betrachtet, die eine Realisierung auf
Basis messagebasierter Protokolle erlaubt. Als bekanntester Vertreter Protokoll ist wohl
SOAP25, als Standard der w3c26 für Webservices zu nennen. Aber auch das von Roy
24 EHP: Enhancement-Pack, SAP Softwarepaket für die Erweiterung der NetWeaver-Funktionalität

25 SOAP: ehem. Simple Object Access Protocol, remotaufruffähiges Netzwerkprotokoll; Repräsentiert Daten mittels XML
26 w3c: World Wide Web Konsortium, Organisation für die Standardisierung und Entwicklung von Webtechnologien
Fielding (2000 Q. 13: S. 13) beschriebene REST27-Konzept, beschreibt unteranderem

den Einsatz von HTTP als messagebasiertes Protokoll.
Für die Betrachtung der Konsumierung von Daten der SAP BusinessObjects GRC-Lösung
ist zu erwähnen, dass diese sowohl über die Anwendungen selbst, als Webservice, oder als
BI-Daten zur Verfügung stehen. Auf Basis dieser Erkenntnis konnten 3 Verfahren
evaluiert werden.
1.1.1. WebDynpro FlashIsland-Technology
Die Nutzung von WebDynpro28 für das einbetten der Flex- in eine WebDynpro-
Applikation unter der Verwendung der von Lutz (2008 Q. 11: S. 3) beschriebenen
FlashIsland Wrapper-Technology. Diese Methode wird derzeit für die Implementierung
von Standard-Dashboards und zur Realisierung von RIA-Funktionalitäten in WebDynpro-
Applikationen verwendet. Die ausführbare swf-Datei wird in das Datei-Repository der
WebDynpro-Applikation abgelegt und eine bidirektionale Datenanbindung über XML-
Wrapping und Unwrapping realisiert.
Vorteile dieser Lösung sind die bereits von WebDynro bereitgestellten Authentifizierungs-
und SSO Verfahren. Auch die Datenübertragung zwischen der clientseitig ausgeführten
Flex-Anwendung und dem Server ist mittels eines über HTTP übertragenen angepassten
XML-Formates optimiert. Dadurch kann der sonst üblichen Overhead bei der Verwendung
von SOAP basierten Webservices erheblich reduzieren werden.
Nachteil ist Notwendigkeit ausgeprägter Technologie- und Implementierungskenntnisse im

Bereich WebDynpro, MVC29-Pattern, und Flex. Die Entwicklung eines Dashboards hierbei
nur marginal grafische Unterstützung, für das Design der UI-Oberfläche der Flex-
Applikation erfahren.
1.1.2. Xcelsisus SAP NetWeaver BI Anbindung mittels BICS
Nutzung des BICS30, für den Zugriff auf BI-Queries, nach den von Ackermann und Sessler
dokumentierten neuen Xcelsius Schnittstellen. Damit ließen sich Daten eines SAP
NetWeaver BI Queries als Query as a Webservice von einem mit Xcelsius erzeugten
Dashboard konsumieren. Im Zuge der Integration von Xcelsius in das SAP NetWeaver BI
Produktportfolio könnte ein gesamter Prozess von der Herstellung einer
1. Konnektierung an das SAP NetWeaver BI-System, der

2. Konfiguration eines Query repräsentierenden Webservice mittels wsdl31, der
3. Ablage des Dashboards im Datei-Repository des NetWeaver und dessen
4. Ausführung in einer NetWeaver Portal-Instanz
beschrieben werden (vgl. Abs. 2009 Q. 7: S. 12).
27 REST: Representational State Transfer, Softwarekonzept; basierend auf dem Uniform-Ressource-Identifier- und HTTP-Standard
28WebDynpro: SAP-Technologie für Erstellung von Webanwendungen auf Basis von Java oder ABAP
29 MVC: Model View Controler, Architekturmuster für die Softwareentwicklung
30BICS: Business Intelligence Consumer Service, Dienst für SAP NetWeaver BI Anbindungen
31 wsdl: Webservice Description Language: Beschreibungssprache für Netzwerkdienste auf Basis von XML
Vorteil ist die Möglichkeit mit wenigen Menüschritten in Xcelsius die Datenanbindung
auch für komplexere Dashboards realisieren zu können, ohne eine Zeile Programmcode
implementieren zu müssen. Die Authentifizierung erfolgt unter Verwendung der
NetWeaver Portal-Technology und kann als sicher und compliant eingestuft werden.
Problematisch sind die Anforderungen an hohe Versionsstände der eingesetzten Produkte.

So wird mit Xcelsius 2008 SP2, NetWeaver 7.01 SP5 und Business Explorer 7.10
Software benötigt, die im Falle von NetWeaver 7.01 SP5 voraussichtlich erst im
September 2009 Marktreife erreicht. Dies kann zu einer starken Einschränkung der
Portierbarkeit erstellter Dashboards auch in einer SAP-Systemlandschaft führen.
1.1.1. Flex-Applikation auf Basis von SAP GRC Webservices
Nutzung von SAP Webservices für den Einsatz eigenständiger Flex-Applikation:
Die swf-Dateien könnten bei diesem Ansatz in HTML eingebettet auf einem Webserver
abgelegt werden, oder als Adobe AIR-Applikation auf Clients installiert werden. Vorteil
dieser Lösung ist das hohe Maß an Flexibilität, in der Verwendung von Flex-IDEs. Jedoch
gibt es noch keine Infrastruktur, die clientseitig die Authentifizierung des Nutzers
übernehmen könnte, oder SSO-Daten weiterleiten würde. Realisieren ließe sich eine solche
Infrastruktur Laut NetWeaver Dokumentation mittels eines
• X.50932 Client-Zertifizierungs-, dem

• SAP-Logon-Ticket 33Verfahren, oder einem
• SAML34 Token
(vgl. Abs. SAP AG 2009 Q. 14).
Diesem Vorgehen könnte ebenfalls zum Nachteil gereichen, dass zwar der Datenschutz der
Daten Seitens des NetWeaver-Systems gewährleistet werden könnte, jedoch Informationen
auch aus Dashboards ohne Auswertungsbezogene Daten von sicherheitskritischer Natur
sein könnten. Sei es, dass sich anhand der Auswertung einer Flex-Applikation auch ohne
Daten die Berichtsintention des Dashboards, oder Konstanten ersichtlich werden könnte.
1.1. Bewertung der Lösungen
In der Folgenden Tabelle wird nun zusammenfassend, die Tauglichkeit der oben
beschriebenen Lösungen, für die in Kapitel 1 beschriebe Motivation dieses
Projektauftrages bewertet. Wie in Tabelle 3 wird für die Bewertung des Erfüllungsgrades
jeder Lösung der in Kapitel 6 definierten Anforderungen erneut ein 5-Punkte-
Bewertungssystem angewendet. (++) indiziert, dass eine volle Erfüllung der jeweiligen
Anforderung möglich wäre, (--) signalisiert, dass die Anforderung nicht erfüllt werden
kann. Zusätzlich wird eine Gewichtung nach der Bewertung der Anforderungswichtigkeit
(siehe Tabelle 3) mit den Faktoren 1 bis 5 (unwichtig bis sehr wichtig) durchgeführt und
relevante Summen gebildet.
32 X.509: Standard für digitale Zertifikate

33 SAP-Logon-Ticket: SAP-SSO-Technologie auf Basis der Anmeldung an einer Clientanwendung
34 SAML: Security Assertion Markup Language SSO-Technologie auf Basis der Anmeldung an einer Webanwendung
7.1.1 7.1.2 7.1.3

ANFORDERUNG
++ + 0 - -- (g) ++ + 0 - -- (g) ++ + 0 - -- (g)
1. Webbas i er t e
x 25 x 25 x 25
Ber i cht s er s t at t ung
2. Benut z er
F x 25 x 25 x 15
Aut hent if i z i er ung
UN
KT N et Weaver RBAC
IO
3. SSO-
NA x 15 x 12 x 9
Anmel dever f ahr en
L
4. Ident i f iz i er ungs - und

Aut hent if i z i er ungs - x 20 x 20 x 12
Mgmt .
Summe Funkt i onal 85 82 61

5. Fl exi bi li t ät x 12 x 9 x 15
NI 6. Aus f al l s s i cher hei t x 20 x 12 x 16
CH
T- 7. Per f or mance x 10 x 8 x 6
F 8. Ges amt kos t en x 12 x 9 x 15
UN
KT 9. Vi s uell e Entw .-
x 9 x 15 x 12
IO Umgebung
NA
L
10. Us abil i t y x 6 x 15 x 9
11. Por ti er bar kei t x 4 x 6 x 4
Summe Ni cht - Funkt i onal 73 74 77
Gesamtbewertung 158 156 138
T a b 4 G ra d d e r A n fo rd e ru n g se rfü llu n g m ö g lic h e r Lö su n g sko n ze p te
Als Ergebnis dieser Analyse wurde dem Produktmanagement Lösung 7.1.2, die Xcelsisus
SAP NetWeaver BI Anbindung mittels BICS vorgeschlagen. Sie erfüllt die Funktionalen
Anforderung fast vollständig und weist geringe Vorteile in Nicht-Funktionalen
Gesichtspunkten gegenüber der WebDynpro FlashIsland-Technology basierten Lösung
auf.
1. Entwicklungspotentiale von Infrastrukturen für

Echtzeit-Reporting
Die Evaluation technischer Möglichkeiten für das Erstellen und Ausführen individueller
Dashboards, entstand auch Aufgrund von Kundenwünschen nach umfassenderen
zahlreicheren Anwendungen von Dashboards im Bereich der SAP BusinessObjects GRC

Anwendungen. Die Spezifikationen der Kunden waren dabei oft zu speziell um in ein
Standardprodukt integriert werden zu können. Die Alternative ist die teils langwierige
Erweiterung der Standardsoftware durch den Kunden, oder der Verzicht auf
Echtzeitdatenauswertung bestimmter Geschäftsvorfälle. Was im Berichtswesen für den
Kunden vieleicht nur ärgerlich oder teuer ist, kennzeichnet derzeit eine entscheidende
Schwäche von BI-Technologien sich als Management-Informationssysteme auch der
Nutzergruppe des Unternehmensmanagements zugänglich machen zu können. Das Fehlen
einer zugänglichen Lösung schränkt das Management in seinen Entscheidungsprozessen
oft ein. Berichte müssen oft Tage vor dem Zusammentreffens eines Gremiums erstellt und
aufbereitet werden oder es werden mangels Zeit und Wissen entscheidende Informationen,
obwohl entsprechende Daten verfügbar sind, u.U. nicht berücksichtig. Ein agiler Prozess
innerhalb einer Versammlung, z.B. eine im Verbund entstandene Fragestellung direkt
untersuchen und darstellen zu können ist so nahezu nicht möglich. Stattdessen muss bisher
darauf geachtet werden, dass der Mehrwert durch fachübergreifender Zusammenarbeit und
Brainstorming, dokumentiert und entsprechende Informationen nachträglich evaluiert
werden. Der Erfolg iterativer Verfahren, in denen Erkenntnisse und Informationen
aufeinander aufbauen, ist so vom Kenntnis-Stand der Beteiligten abhängig.
Mit dem beginnenden heranwachsen von Führungskräften aus der Generation der Digital
Natives und einem damit stärkeren Wunsch nach, besonders in Puncto Usability und
Performance hochwertigen IT-Lösungen entwickelt sich ein Markt für eine neue Vision
von Management-Informationssystemen:
• Das Internet dient als nahezu ubiquitäres Kommunikationsmedium

• Der WebBrowser ist die akzeptierte Schnittstelle
• Ideen können direkt modelliert werden, Design und Ausführung von Berichten
kann innerhalb des gleichen Werkzeugs, zeitgleich durchgeführt werden
• Arbeitsspeicherdatenbanken, Multicore-Prozessoren erlauben die Auswertung und
Visualisierung von Daten, noch während des designen eines Berichts, oder
Abfrage.
• Ein lernendes nutzerabhängiges Vorschlagswesen, erzeugt
Visualisierungstemplates, die der Nutzer beliebig verändern kann.
• Eine integrierte, sprachunabhängige semantische Suche, die einen Kontext,
zwischen Daten und Informationen bildet, hält alle Daten eines Unternehmens
bereit.
Diese Vision basiert auf Entwicklungen, die derzeit im Bereich von Berichts- und BI-
Lösungen entstehen. Produkte, wie der SAP Business Explorer, oder die SAP
EnterpriseSearch, haben die Fähigkeit in neue Generation von Informations-
Managementsystemen eingesetzt zu werden.
Print-Quellen
Q 1.Brühwiler, B 2003,“ Risk Management als Führungsaufgabe. Methoden und
Prozesse der Risikobewältigung für Unternehmen, Organisationen, Produkte und
Projekte“, Haupt, Bern.
Q 2.Kazoun, C & Lott, J 2008,” Programming Flex 3. the comprehensive guide to
creating rich Internet applications with Adobe Flex”, O'Reilly, Beijing.
Q 3.Külpmann, B 2006,“ Kennzahlen im Betrieb. Wichtige Werte im Wettbewerb“,
Cornelsen, Berlin.
Q 4.Mezler-Andelberg, C 2008,“ Identity Management. Eine Einführung ;
Grundlagen, Technik, wirtschaftlicher Nutzen“, dpunkt-Verl., Heidelberg.
Q 5.Wöhe, G & Döring, U 2005,“ Einführung in die allgemeine
Betriebswirtschaftslehre“, Vahlen, München.
Q 6.hps 2009,“ Risiken im Griff'“, c´t 20 July, S. 36. Erhältlich von: www.heise.de/ct
[10 August 2009].
Elektronische Quellen
Q 7.Ackermann, M & Sessler, M 2009,” SAP BusinessObjects BI Solutions Exploring
SAP NetWeaver Business Warehouse Data”. Erhältlich von:
https://www.sdn.sap.com/irj/boc/index?rid=/library/uuid/100369a7-033e-2c10-
94a4-f254f8578153 [22 August 2009].
Q 8.Adobe 2009. Erhältlich von:
http://www.adobe.com/products/flex/features/flex_builder [22 August 2009].
Q 9.Bahnsen, H 2009, “ Das Risikomanagement war miserabel - aber die Boni fließen
immer weiter“, Welt Online 16 August. Erhältlich von:
http://www.welt.de/hamburg/article4334224/Das-Risikomanagement-war-
miserabel-aber-die-Boni-fliessen-immer-weiter.html#reqNL [18 August 2009].
Q 10.Sun Microsystems, 2008, “END-TO-END ENTERPRISE COMPLIANCE,
PROVISIONING, AND ROLE ENFORCEMENT. WITH SUN JAVA™ SYSTEM
IDENTITY MANAGER AND SAP GRC ACCESS CONTROL”. Erhältlich von:
http://www.zdnet.de/end_to_end_enterprise_compliance__provisioning_and_role_
enforcement_download-39002355-88030528-1.htm [22 August 2009].
Q 11.Manfred Lutz 2008, “Integration of Adobe Flash Island for Web Dynpro ABAP”.
Erhältlich von:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/307b434f-ff32-
2b10-e885-991247270480 [22 August 2009].
Q 12.Microsoft 2009,“ Produktübersicht zu Microsoft Office Excel 2007“. Erhältlich
von: http://office.microsoft.com/de-de/excel/HA101656321031.aspx [21 August
2009].
Q 13.Roy Fielding 2000,” Architectural Styles and the Design of Network-based
Software Architectures”. Erhältlich von:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm [20 August 2009].
Q 14.SAP AG 2009,” SAP Netweaver 7.0 EHP1. SAP NetWeaver by Key Capability”.
Erhältlich von:
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/6a/44b2420e71c511e10000000
a1550b0/frameset.htm
Q 15.w3c 2009,” HTML 5”. Erhältlich von: www.w3c.org [22 August 2009].
Sonstige Quellen
Q 16.Fischer, O 2009,“ Xcelsius Integration“. Telefonat, olaf.fischer@sap.com .
Q 17.SAP AG, SAP BusinessObjects RiskManagment. Overview Dashboard 2009,
SAP AG.
Elektronisches Anhangsverzeichnis
A1. (A1_SunMS) Sun Microsystems, 2008, “END-TO-END ENTERPRISE
COMPLIANCE, PROVISIONING, AND ROLE ENFORCEMENT. WITH SUN
JAVA™ SYSTEM IDENTITY MANAGER AND SAP GRC ACCESS CONTROL”.
A2. (A2_Lutz_SAP) Manfred Lutz 2008, “Integration of Adobe Flash Island for Web
Dynpro ABAP”.
A3. (A3_Fielding) Roy Fielding 2000,” Architectural Styles and the Design of
Network-based Software Architectures”.
A4. (A4_SesslerAckermann) Ackermann, M & Sessler, M 2009,” SAP
BusinessObjects BI Solutions Exploring SAP NetWeaver Business Warehouse
Data”.
A5. (A5_SAP) SAP 2008 “Xcelsius Manual”.
Die Projektarbeit selbst liegt ebenfalls auf dem Speichermedium in elektronischer Form
sowohl als pdf, wie als Word-Dokument vor.

Project Paper To SAP Riskmanagement Functionality

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Paper To SAP Riskmanagement Functionality

Hochgeladen von

Copyright:

Verfügbare Formate

Studienbereich Wirtschaft

Evaluation zum Einsatz von Single-Sign- On

Für den Kunden-Einsatz von Werkzeugen zur Erstellung

Verfasser /in: Marco Hammel

keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.

2. Hinweise zur Struktur der Arbeit...............................................................................8

3. Beschreibung des SAP GRC Anwendungsportfolios................................................9

4. Dashboards in GRC Anwendungen..........................................................................10

5. Flex-Technologien für webbasierte Dashboards......................................................12

5.1. Architektur von Flex-Applikationen.....................................................................12

5.2. Grafische Entwicklungsumgebungen....................................................................14

5.2.1. SAP Business Objects Xcelsius 2008 Engage...............................................15

5.2.2. Adobe Flex Builder 3 Professional................................................................17

5.2.3. Gegenüberstellung der grafischen Entwicklungsumgebungen......................18

6.1. Funktionale Anforderungen...................................................................................20

6.1.1. Webbasierte Berichtserstattung......................................................................20

6.1.2. Benutzer Authentifizierung durch der NetWeaver RBAC.............................20

6.1.3. Single-Sign-On Anmeldeverfahren................................................................21

6.1.4. Identifizierungs- und Authentifizierungsmanagement...................................21

6.2. Nichtfunktionale Anforderungen...........................................................................22

6.2.5. Visuelle Entwicklungsumgebung...................................................................24

6.3. Bewertung der Anforderungen..............................................................................25

7.1. Ermittelte Lösungen..............................................................................................26

7.1.1. WebDynpro FlashIsland-Technology............................................................27

7.1.2. Xcelsisus SAP NetWeaver BI Anbindung mittels BICS...............................27

7.1.3. Flex-Applikation auf Basis von SAP GRC Webservices..............................28

7.2. Bewertung der Lösungen.......................................................................................29

8. Entwicklungspotentiale von Infrastrukturen für Echtzeit-Reporting........................31

Ein Wettbewerbskriterium im Finanzgeschäft ist die Geschwindigkeit, mit der

• Marktrisiko der Branche, ggf.

1. Hinweise zur Struktur der Arbeit

2. Beschreibung des SAP GRC

3. Dashboards in GRC Anwendungen

A b b 1 B u sin e ssO b je c ts R isk M an a g e m e n t O v e rv ie w -D a sh b oa rd

Typische Bestandteile von Dashboards sind sogenannte Ampel-, Armatur- und

• Temperatur des heißesten Brennstabes

1. Flex-Technologien für webbasierte

6 HTML: Hypertext Markup Language; Beschreibungssprache des World Wide Web

Diagrammkomponenten und Visualisierungseffekten, die dieses Framework liefern würde.

1.1. Architektur von Flex-Applikationen

A b b 2 Fle x so u rc e -co m p ile -d e p lo y w o rk floKw

9 API: Application Programming Interface, Programmierschnitstelle zur Anwendungsentwicklung

Datentypen zur Repräsentation von u.a. XML Daten zu Verfügung.

Üblicherweise kann nun eine browserbasierte Flex-Anwendung z.B. in HTML eingebettet

1.1. Grafische Entwicklungsumgebungen

Im Folgenden werden 2 Editoren betrachtet, die diesen Anspruch für Flex-Applikationen

1.1.1. SAP Business Objects Xcelsius 2008 Engage

Mit dem Kauf des Spezialisten für Management-Informationssysteme BusinessObjects im

• Microsoft Excel-Tabellen, die statisch eingebunden werden, oder dynamisch

17 BI: Business Intelligence, System für die Geschäftsanalyse

RESTRIKTION MS EXCEL 2003 MS EXCEL 2007

1.1.1. Adobe Flex Builder 3 Professional

Im Gegensatz zu Xcelsius bestehen hier keine Einschränkungen durch eine

1.1.2. Gegenüberstellung der grafischen Entwicklungsumgebungen

SAP BUSINESS ADOBE FLEX BUILDER

Eine ausgewogene Bewertung durchzuführen bedarf hier eines abstrakten Ansatzes. Da es

2.1. Funktionale Anforderungen

Funktionale Anforderungen beinhalten die zur Nutzung notwendigen Funktionen der

2.1.1. Webbasierte Berichtserstattung

Dashboards sind Managementwerkzeuge, die der Entscheidungsfindung dienen sollen.

2.1.2. Benutzer Authentifizierung durch der NetWeaver RBAC20

20 RBAC: Role based Access Control, Rollenbasierte Zugriffsüberwachung für Anwendungen

2.1.3. Single-Sign-On Anmeldeverfahren