Business Intelligence in the Cloud. Überblick und Bewertung


Masterarbeit, 2013

82 Seiten, Note: 2,7


Leseprobe


Inhaltsverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation und Zielsetzung
1.2 Vorgehensweise

2 Business-Intelligence-Grundlagen
2.1 Entwicklung und Begriffserklärung: Business-Intelligence
2.2 Architektur von Business-Intelligence-Systemen

3 Cloud-Computing-Grundlagen
3.1 Entwicklungsweg zum Cloud-Computing
3.2 Begriffserklärung: Cloud-Computing
3.3 Modelle von Cloud-Computing
3.3.1 Organisatorische Servicemodelle
3.3.1.1 Public-Cloud
3.3.1.2 Private-Cloud
3.3.1.3 Hybrid-Cloud
3.3.2 Technische Bereitstellungsmodelle von Cloud-Computing
3.3.2.1 Infrastructure-as-a-Service
3.3.2.2 Platform-as-a-Service
3.3.2.3 Software as-a-Service

4 Business-Intelligence-in-the-Cloud
4.1 Begriffserklärung: Business-Intelligence-in-the-Cloud
4.2 Framework des Business-Intelligence-in-the-Cloud
4.2.1 Infrastructure-as-a-Service
4.2.2 Platform-as-a-Service
4.2.3 Software as-a-Service

5 Kritische Analyse
5.1 Wirtschaftliche Aspekte
5.1.1 Implementierungsaufwand und Betriebskosten
5.1.2 Total-Cost-of-Ownership
5.2 Organisatorische Aspekte
5.2.1 Implementierung und die Fokussierung auf das Kerngeschäft
5.2.2 Abhängigkeit vom Anbieter
5.2.3 Vertragsgestaltung
5.3 Sicherheitsrelevante Aspekte
5.3.1 Daten- und Systemsicherheit
5.3.2 Datenschutz
5.4 Funktionale Aspekte
5.4.1 Weltweite Verfügbarkeit, Mobilität und Plattformunabhängigkeit
5.4.2 Funktionale Anpassungsfähigkeit
5.5 Technische Aspekte
5.5.1 Skalierbarkeit
5.5.2 Integrationsfähigkeit und Schnittstellen
5.5.3 Performance, Stabilität und Verfügbarkeit

6 Fazit

Literaturverzeichnis

Anhang A: Technologischer Framework des BI-Verständnisses

Anhang B: Architektur von BI-Systemen

Anhang C: Schematischer Vergleich: On-Premise & On-Demand

Anhang D: Organisatorische Servicemodelle des Cloud-Computing

Anhang E: Technische Bereitstellungsmodelle des Cloud-Computing

Anhang F: Framework des BI-in-the-Cloud

Anhang G: Mögliche hybride Infrastruktur (Hybrid-Cloud)

Anhang H: Mögliches Framework des BI-in-the-Cloud Nr.1

Anhang I: Mögliches Framework des BI-in-the-Cloud Nr.2

Anhang J: Kostenblöcke im Vergleich: On-Premise & BI-in-the-Cloud

Anhang K: Darstellung der TCO-Kosten: On-Premise & On-Demand

Anhang L: Mögliches Framework des BI-in-the-Cloud Nr.3

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation und Zielsetzung

Unternehmen befinden sich in dynamischen Märkten, wodurch eine weitreichende Infor- mationsversorgung unabdingbar geworden ist. Mit Hilfe von Business-Intelligence- Systemen (BI-Systemen) ist es möglich, Daten aus verschiedenen Datenquellen zu analy- sieren, daraus wettbewerbskritische Informationen abzuleiten und diese als Unterstützung für den Entscheidungsprozess zu verwenden (Thompson & Van der Walt, 2010, S.1).

In der Vergangenheit und auch heute noch werden diese Systeme mit einer herkömm- lichen/traditionellen IT-Infrastruktur (On-Premise) umgesetzt, bei der das Unternehmen sowohl die Software als auch die Hardware eigens kauft und betreibt. Während diese Sys- teme unter der Beachtung erfolgskritischer Anforderungen betrieben werden, befinden sich die Unternehmen trotzdem weiter auf der Suche nach neuen Technologien, die einen Vor- sprung gegenüber ihren Wettbewerbern ermöglichen können (Bange, Mack & Seidler, 2012, S.10-11 & 27).

Cloud-Computing könnte eine solche Technologie sein, die in Form einer Innovationswel- le in der IT insgesamt und besonders in Unternehmen dafür sorgen kann, bewährte IT- Systeme zu überdenken und neu auszurichten (Thompson & Van der Walt, 2010, S.3).

Unternehmen benötigen heute eine flexible IT, die sich den Turbulenzen im Unternehmensumfeld anpasst und neuen Anforderungen entgegentritt: Im Vergleich zu den eher starren On-Premise-Systemen kann die Cloud durch ihre Fähigkeit, Software und Hardware als Dienst nach Bedarf zur Verfügung zu stellen, eine flexible zukunftsfähige Lösung sein (Cramer, 2009, S.46; Haselmann, Hoeren & Vossen, 2012, S.26):

Unternehmen sehen darin eine zukünftige Chance, ihre vorhandene IT-Infrastruktur mit Cloud partiell zu optimieren oder vollständig zu ersetzen. Für junge Unternehmen mit wenig Budget eröffnen sich neue Tore, um gegenüber großen etablierten Unternehmen Wettbewerbsvorteile zu erkämpfen (Föckeler, 2009, S.40).

Kommt es nun mit einer Kombination von Cloud-Computing und BI zu der sogenannten BI-in-the-Cloud, muss trotz aller daraus entstehenden möglichen Vorteilen, anhand ausge- wählter Aspekte, das neue Konzept kritisch betrachtet werden, um diese Technologie voll- ständig zu verstehen und einschätzen zu können. Es muss ein Gleichgewicht entstehen zwischen den Anforderungen der Unternehmen an BI und den Möglichkeiten der BI-in- the-Cloud, damit das neue Konzept im Unternehmen erfolgreich eingeführt werden kann.

1.2 Vorgehensweise

Zum Verständnis der Thematik BI-in-the-Cloud werden die dabei kombinierten beiden Themengebiete BI und Cloud-Computing mit ihren jeweiligen theoretischen Grundlagen im Abschnitt 2 und 3 näher betrachtet. Anschließend kommt es im Abschnitt 4 zu einer Fusion der beiden Themengebiete, in der die Grundlagen des Hauptthemas BI-in-the- Cloud erarbeitet werden. Im Abschnitt 5 geht es anschließend darum, die Kombination von BI und Cloud-Computing anhand wirtschaftlicher (Implementierungsaufwand, Betriebs- kosten und Total-Cost-of-Ownership), organisatorischer (Implementierung, Fokussierung auf das Kerngeschäft, Abhängigkeit vom Anbieter und Vertragsgestaltung), sicherheitsre- levanter (Daten- und Systemsicherheit sowie Datenschutz), funktionaler (Weltweite Ver- fügbarkeit, Mobilität und Plattformunabhängigkeit) und technischer (Skalierbarkeit, Inte- grationsfähigkeit, Schnittstellen, Performance, Stabilität und Verfügbarkeit) Aspekte kri- tisch zu betrachten. Hierbei werden On-Premise- und On-Demand-Lösungen verglichen und daraus resultierende Chancen und Risiken aufgezeigt. Im Fazit wird anschließend ein endgültiges Ergebnis der Kombination beider Technologien erarbeitet, aus dem ersichtlich werden soll, ob diese Kombination für die betroffenen Unternehmen einen langfristigen und nachhaltigen Erfolg gewährleisten kann.

2 Business-Intelligence-Grundlagen

2.1 Entwicklung und Begriffserklärung: Business-Intelligence

Bereits in den 60er Jahren wurden Projekte angestrebt, um Fach- und Führungskräfte hinsichtlich Planungs- und Kontrollprozesse über Informationstechnologien zu unterstützen. Die Erwartungen an diese Systeme wurden allerdings aufgrund fehlender technischer Machbarkeit nicht erfüllt und in den folgenden Jahrzehnten weiterentwickelt und verbessert: Es wurde nicht mehr nur die Datenversorgung gewährleistet, sondern auch interaktive Methoden und Modelle zur Lösungsfindung sowie die Vernetzung von bestehenden DVSystemen ermöglicht (Chamoni & Gluchowski, 2006, S.6-9).

Die hierbei entstandenen Systeme wurden unter dem von Scott Morton definierten Begriff Management Support Systeme (MSS) zusammengefasst: „The use of computers and rela- ted information technologies to support managers“. In den 90er Jahren entwickelte sich trotz der nach wie vor gebräuchlichen Bezeichnung MMS ein weiterer Begriff: Business- Intelligence (BI) (Baars, Kemper & Mehanna, 2010, S.1; Gluchowski & Kemper, 2006, S.12-14).

Der Begriff wird bis heute inflationär hauptsächlich von Beratungshäusern und Softwareherstellern verwendet und dabei nicht selten als neues Etikett für bereits existierende Lö- sungen gebraucht: Allerdings verkörpert BI die geradezu revolutionäre Entwicklung der Systeme zur Managementunterstützung und definiert sich an den geänderten Rahmenbe- dingungen: Dynamik, Komplexität, Funktionsvielfalt und die zunehmende IT- Implementierung von Geschäftsprozessen prägen die Anforderungen und Möglichkeiten der Systeme zur Managementunterstützung neu. Obwohl bis heute keine allgemein akzep- tierte Definition existiert, definierte GARTNER GROUP 1996 BI als eine Sammlung, Speicherung, Analyse von und Versorgung mit Daten, um Unternehmen bei der Entschei- dungsfindung zu unterstützen. Diese Definition zeigt das historische Wachsen von ver- schiedenen Strömungen in den MSS, begonnen in den 80er Jahren: Damals bereits be- währt, wird auch heute bei BI die Sammlung und Speicherung von Daten durch Data- Warehouse-Systeme (DWH) bewerkstelligt, die aus der Anforderung nach einheitlichen Datenbeständen und einer zukünftigen zentralen IT-Infrastruktur entstanden. Aus dem Ver- langen nach weiteren selbständigen und komfortablen Auswertungen, die eine Analyse und Versorgung mit Daten zur Entscheidungsfindung ermöglichen, entwickelten sich Dash- boards, Analyse- sowie Berichtssysteme. Auch die heutige in Unternehmen bewährte Standardtechnologie Online Analytical Processing (OLAP) zur intensiven und interaktiven Analyse fand ihren Ursprung in den damals schon vorhandenen multidimensionalen An- sätzen (Gluchowski & Kemper, 2006, S.12).

Neben dem Grundkonsenz von BI, wonach die Techniken und Anwendungen entschei- dungsunterstützenden Charakter besitzen, einen besseren Gesamtüberblick über das Unter- nehmen ermöglichen und das Verständnis von Wirkungsketten verbessern sollen, kann der Begriff in einen technologischen Framework eingeordnet werden: Hierbei wird zwischen einem engen, einem analyseorientierten und einem weiten BI-Verständnis unterschieden (siehe Anhang A): Im engen Sinn gehören Kernfunktionalitäten wie z.B. das OLAP für multidimensionale Analysen dazu, um eine unmittelbare Entscheidungsunterstützung zu ermöglichen. Die hierbei explizit ausgeklammerten Produkte zur Erstellung von Ad-Hoc- Reportings und die Data-Mining-Systeme (DM) finden ihren Platz im analyseorientierten BI-Verständnis und ergänzen OLAP: Mittels Methoden und Modellen können vorhandene, bereits harmonisierte, aufbereitete und abgestimmte Datenbestände zielgerichtet analysiert werden. Das in der Wissenschaft und Praxis scheinbar etablierte weite Verständnis kenn- zeichnet BI als einen Oberbegriff, unter dem alle Systemkomponenten zusammengefasst werden, die operatives Datenmaterial zur Informationsgenerierung aufbereiten und speichern sowie mit Auswertungs- und Präsentationsfunktionalitäten bereitstellen: Demnach werden neben den analytischen Komponenten auch das benötige DWH, der ETL-Prozess (Extraktion, Transformation und Laden) sowie das Standard-Reporting mit eingeschlossen (Baars et al. 2010, S.3-4; Dittmar et al. 2008, S.90-92; Oehler & Seufert, 2009, S.9-11).

Im Folgenden wird unter BI die weite Auslegung verstanden: Ein unternehmensweites System, das alle Komponenten einschließt, mit denen Daten aus Quellsystemen über die ETL-Prozesse in das DWH und anschließend über Auswertungs- und Präsentationsfunktionalitäten bereitgestellt werden können.

2.2 Architektur von Business-Intelligence-Systemen

Die Architektur von BI-Systemen orientiert sich stark an den unternehmensspezifischen Anforderungen. Zur Verdeutlichung des zuvor festgelegten weiten BI-Verständnisses kön- nen die jeweiligen Komponenten in die einzelnen Ebenen einer idealtyptischen Architektur eingebracht werden. Es wird zwischen der Ebene der Datenquellen, Datenbereitstellung sowie der Datennutzung unterschieden (siehe Anhang B): Die Datenquellen sind außerhalb der BI-Architektur angesiedelt und stellen lediglich Daten aus unternehmensinternen und - externen Bereichen zur Verfügung: Zum einen gibt es operative Vertriebs- und Produkti- onssysteme, die transaktionale und zeitpunktbezogene Daten über das Unternehmen selbst liefern. Zum anderen werden externe Daten aufgrund der steigenden Orientierung an End- anwendern aus Onlinedatenbanken und -diensten in den Datenbestand aufgenommen (Dittmar, Gabriel & Gluchowski, 2008, S.110; Gluchowski & Kemper, 2006, S.12-14).

Die Aufgabe der Datenbereitstellung ist es, eine von den Datenquellen getrennte, logisch zentrale dispositive Datenbasis für die gesamte unternehmerische Managementunterstützung bereitzustellen. Diese Integration der Daten erweist sich als schwierig und komplex, da die historisch gewachsenen operativen System im Vergleich zur angestrebten Zieldatenbank häufig Datenredundanzen, Inkonsistenzen und semantische Widersprüche aufweisen und daher unbedingt in einen inhaltlich widerspruchsfreien Zusammenhang überführt werden müssen (Baars et al. 2010, S.19-20).

Die Überführung der Quelldaten in die Zieldatenbank wird deshalb durch Extraktions-, Transformations- und Ladevorgänge, dem sogenannten ETL-Prozess, ermöglicht: Zu- nächst werden Übernahmekandidaten identifiziert, anschließend mittels Filtervorschriften auf einen relevanten Umfang eingegrenzt und aus der Datenquelle extrahiert. Die extra- hierten Daten werden im nächsten Schritt mittels Transformationen aufbereitet: Unter- scheiden sich die Daten in den unterschiedlichen Vorsystemen hinsichtlich ihrer Merkmale, müssen diese miteinander verknüpft werden, um verschiedene Datenschlüsselungen auszuschließen und eine gemeinsame spätere Betrachtung zu ermöglichen. Um eine unter- nehmensinterne und -externe Vereinheitlichung der Begrifflichkeiten anzustreben werden Synonyme und Homonyme gesucht und bei inhaltlichen Übereinstimmungen zusammen- geführt. Anschließend werden die Daten von syntaktischen und/oder semantischen Fehlern bereinigt (z.B. Datentypverletzungen oder unzulässige Wertebereiche). Damit verbunden erweisen sich fehlende Werte (z.B. Eingabefehler) in Daten als problematisch, wenn sie ungehindert in die Zieldatenbank gelangen und spätere Auswertungen verfälschen. Bevor der Ladeprozess in das DWH durchgeführt wird, werden die Informationsobjekte der Da- tenquellen den Informationsobjekten der Zieldatenbank zugeordnet. Befinden sich die Da- ten nach dem Transformationsprozess in einem mit der Zieldatenbank abgestimmten und konsistenten Zustand, können diese mittels Ladeprozess in das DWH übertragen werden. Besteht ein Bedarf nach weiteren Berechnungen in späteren Auswertungen, können die Daten vor dem Ladeprozess noch bspw. mit Aggregationen oder der Berechnung von neu- en Kennzahlen angereichert werden (Dittmar et al. 2008, S.135-138; Gluchowski & Kem- per, 2006, S.14).

In der Vergangenheit von MSS führte die Vernachlässigung der Datenhaltung bei umfas- sender Informationsversorgung der Entscheidungsträger zu weitreichenden Problemen: Der Aufwand bei der Zusammenführung heterogener Datenbestände wurde unterschätzt und führte zu inkonsistenten Datenbanken. Als Lösungsansatz wurden Konzepte entwi- ckelt, die unternehmensweit entscheidungsrelevante Daten verschiedenster Anwender- gruppen zentral in einer konsistenten und von den Vorsystemen getrennten Datenbank, dem DWH, zur Verfügung stellen: Das DWH vernachlässigt hierbei Prozessdaten und konzentriert sich auf die voraussichtlich später nachgefragten inhaltlichen Themenschwer- punkte des Unternehmens wie bspw. Daten über Produkte und Kunden. Um einen konsis- tenten Datenbestand aus heterogenen Datenbanken zu gewährleisten, werden die Daten über die bereits erwähnten ETL-Prozesse verarbeitet und zeitpunktbezogen abgelegt. Dabei finden nur relevante Daten auf bestimmten Verdichtungsstufen in der Datenbank Platz, die dem Entscheidungsträger wertvolle Dienste leisten könnten. Um die Performance des ge- samten DWH aufrecht zu halten und umfangreiche Datenbestände schnell und flexible analysieren zu können, richten Unternehmen zusätzlich sogenannte Data-Marts (DAMA) ein. Die darin enthaltenden Daten stammen aus dem zentralen DWH und bilden z.B. für spezielle Unternehmensbereiche/Analysen separierte dezentrale Datenbestände ab (Dittmar et al. 2008, S.117-122 & S.128-131 Gluchowski & Kemper, 2006, S.14-16).

An die Datenbereitstellung knüpft die Ebene der Datennutzung, in der das DWH als zentrale Ausgangsbasis für weiterführende Analysen in Planungs-, Prognose-, Diagnose- und Interpretationsprozessen dient. Dieser Ebene können jegliche Systeme zugeordnet werden, die Datenmaterial aufbereiten, analysieren und in geeigneter und gewünschter Form dem Endanwender zur Verfügung stellen: Es wird unterschieden in Präsentations- und Zugangssysteme mit Dashboards, Cockpits und BI-Portale, aber auch in konzeptorientierte Systeme wie bspw. Planungs- und Budgetierungssysteme, Systeme der wertorientierten Unternehmensführung oder Risikomanagementsysteme. Klassische Berichte, Ad-Hoc- Analysesysteme (OLAP sowie Querys), aber auch modell- und methodengestützte Analysesysteme wie DM-Systeme werden den generischen Basissystemen zugeordnet (Dittmar et al. 2008, S.143; Gluchowski & Kemper, 2006, S.12-16).

OLAP ermöglicht schnelle und dynamische Prüfungen und Belegungen von vorformu- lierten Hypothesen über Tatbestände, Beziehungen oder Entwicklungen: Die benötigten Informationen werden in gleichbleibenden, interaktiven und multidimensionalen Analyse- perspektiven aufbereitet: Mittels den Befehlen Drill-Down, Roll-Up, Slicing, Dicing, etc. kann der Anwender zwischen detailreichen und konsolidierten Stufen entlang mehrerer Dimensionen navigieren. Die vereinheitlichten Dimensionen erlauben die Generierung von intuitiven Datenanalysen, Ad-Hoc- sowie Standardauswertungen von homogenisierten Daten (Dittmar et al. 2008, S.143-149; Gluchowski & Kemper, 2006, S.17).

Neben der Hypothesenverifizierung bei OLAP können mit DM-Systemen eigene Hypothe- sen generiert und Beziehungen zwischen Objekten aufgedeckt werden: Die umfangreichen Datenbestände der Unternehmen beinhalten wertvolle verschüttete Informationen, deren Zusammenhänge/Datenmuster mit intelligenten Algorithmen aufgedeckt werden können. Werden die Daten zusätzlich mit externen Daten von z.B. Marktforschungsinstituten ange- reichert, eröffnen sich weitere Chancen für das Unternehmen, Wettbewerbsvorteile auszu- bauen. DM-Systeme nutzen vor allem Klassifikations-, Cluster- und Assoziationsverfah- ren, um in umfangreichen Datenbeständen erfolgversprechende Informationen zu generie- ren. Mit dem Klassifikationsverfahren werden Informationsobjekte vorgegebenen Klassen zugeordnet. Clusterverfahren segmentieren mit Algorithmen ähnliche Informationsobjekte in zuvor nicht festgelegte Klassen. Assoziationsverfahren ermöglichen das Aufdecken von Abhängigkeiten unterschiedlicher Daten. Alle gewonnenen Ergebnisse von DM-Systemen müssen anschließend von einem menschlichen Anwender hinsichtlich Gültigkeit, Neuar- tigkeit, Nützlichkeit und Verständlichkeit geprüft werden (Dittmar et al. 2008, S.191-195; Gluchowski & Kemper, 2006, S.17).

Im Gegensatz zu den zuvor angesprochenen Komponenten wird in Reporting-Systemen und Portalen weitgehend auf flexible Navigationen und weitreichende methodische Aufbe- reitungen verzichtet und eine reine Präsentation der relevanten Daten angestrebt. Für die meisten Problemstellungen und Mitarbeiter sind ereignis- oder zeitgesteuerte starre Berich- te für eine schnelle Einsicht in themenorientierte relevante Daten ausreichend. Die Berichte werden standardisiert automatisch erstellt und elektronisch dem Empfängerkreis innerhalb fester Zeitintervalle zur Verfügung gestellt (Dittmar et al. 2008, S.205-206 & 210).

Dashboards und Portale sind dagegen Informationsplattformen, die direkt am Bildschirm betrachtet werden sollen: Dashboards nutzen Visualisierungstechniken, um komplexe In- formationen nutzerbezogen und in komprimierter Form verständlich darstellen zu können. Müssen Inhalte und Funktionalitäten aus unterschiedlichen Vorsystemen zusammengeführt werden, ermöglichen BI-Portale einen zentralen Zugang zu ausgewählten Themenberei- chen und den entsprechenden Informationen und Diensten. Portale verhindern durch die Integration unterschiedlicher Informationen unter einer Oberfläche die Mehrfach- Anmeldung eines Anwenders in unterschiedlichen Systemen. Im Gegensatz zu den kom- primierten Dashboard-Darstellungen kann der Anwender in Portalen in Detailierungsstufen navigieren und dabei auf verschiedene Darstellungsformen zurückgreifen (Dittmar et al. 2008, S.214-216).

3 Cloud-Computing-Grundlagen

3.1 Entwicklungsweg zum Cloud-Computing

Die IT war schon immer geprägt von Trends, neuen Technologien, Wechselspielen zwi- schen dezentralen und zentralen räumlichen Kräften sowie ökonomischen Rahmenbedin- gungen. Am Anfang prägten zentrale Großrechner das Bild in Unternehmen, an denen le- diglich punktuell stattfindende Interaktionen möglich waren. Nach und nach wurden in den 80er Jahren dezentrale Einzelplatz-Anwender-Computer (Clients) mit zentralen Servern kombiniert. Durch die Einführung des Internet in den 90er wurden erste Zentralisierungen angestrebt und eine räumliche Trennung der Rechenleistung vom Anwender ermöglicht. Seit der Jahrtausendwende befindet sich die IT in einer Transformation zu einer service- orientierten IT-Welt, in der klassische Desktop-PCs an Bedeutung verlieren und Anforde- rungen nach Flexibilität und Integration immer stärker gefordert werden (Barot et al. 2009, S.20-21):

Cloud-Computing versucht diese Entwicklung aufzunehmen und mit bestehenden Techno- logien umzusetzen: Im Folgenden werden die historischen Entwicklungen dargestellt, um Technologien aufzuzeigen, die für Cloud-Computing elementare Bestandteile darstellen und Impulse gegeben haben: Dazu zählen Grid-Computing, Konsolidierungs- und Virtuali- sierungskonzepte sowie serviceorientierte-Architekturen (SOA) (Barot et al. 2009, S.69- 71):

1960 wurden erstmals komplexe Probleme nicht mehr mit einem großen zentralen Super- computer gelöst, sondern mit einem Verbund vieler einzelner unabhängiger Computer: Das sogenannte verteilte System aus einzelnen Teilsystemen (Knoten) entstand und zeichnete sich vor allem durch seine Skalierbarkeit aus: Erstmals konnten Ressourcen unabhängig ihrer geografischen Verteilung hinzugefügt werden, ohne dass die Leistung des gesamten Systems beeinträchtigt worden wäre. Cluster- und Grid-Computing sind verschiedene Ar- ten des verteilten Systems: Im Gegensatz zu Cluster-Computing, bei dem zahlreiche ho- mogene Knoten über ein Hochgeschwindigkeitsnetzwerk verbunden wurden, bietet das Grid-Computing eine starke Heterogenität und damit Flexibilität: Zum einen unterscheiden sich Knoten in Hardware und Software voneinander. Zum Anderen ist der Zeitpunkt, in denen Knoten sich aufbauen und trennen, beliebig (Haselmann et al. 2012, S.13-16).

Das größtenteils im Forschungsumfeld verbreitete Grid-Computing zur freien, effizienten und gemeinsamen Nutzung von Rechenkapazität lieferte eine fundamentale Grundlage für das heutige Cloud-Computing: Standardisierte, hochskalierbare Systemarchitekturen, die als IT-Services über das Internet angeboten werden können, sowie erste Ansätze von nutzungsabhängigen Bezahlmodellen und anwenderbezogenen Steuerungs- und Managementmöglichkeiten wurden von Grids an Clouds vererbt. Beide vereinen Gemeinsamkeiten, aber auch Unterschiede, folgen jedoch dem Konzept IT-as-a-Service (ITaaS), wobei Cloud-Computing klar zwischen Cloud-Anbieter und -Nutzer unterscheidet und die ökonomische Nutzung (nutzungsabhängige Abrechnung) eher in den Mittelpunkt stellt (Barot et al. 2009, S.69-71; Metzger, Reitz & Villar, 2011, S.24):

ITaaS erzeugt den Grundgedanken, physische Ressourcen gemeinsam zu nutzen und über ein Netzwerk darauf zuzugreifen: Anders als Cluster- und Grid-Computing verwendet Cloud-Computing allerdings virtuelle Ressourcen und ermöglicht deren unverzügliche Anpassbarkeit an den Bedarf im Rahmen der Selbstbedienung (Haselmann et al. 2012, S.25-26).

Die technologische Entwicklung und das mit den verteilten Systemen verbundene Kon- zept, nachdem der geografische Standort von Knoten in IT-Systemen keine Rolle mehr spielte, führte bei den Unternehmen zu Outsourcing-Gedanken: Teile der Wertschöpfung, die nicht mit der eigentlichen unternehmerischen Kernkompetenz in Verbindung stehen, sollen an spezialisierte Drittanbieter ausgelagert werden, um Skaleneffekte zu erzeugen: Es standen bei den Unternehmen häufig hohe Kapitalinvestitionen und Betriebsaufwendungen geringer Serverauslastung (5-15 Prozent) gegenüber und verursachten eine Verschwendung von Ressourcen. Durch das Zusammenführen, Automatisieren und Standardisieren von Systemen sollten IT-Infrastrukturen konsolidiert (Komplexität reduziert) und dabei das Qualitätsniveau und Skalenniveau bei sinkenden Betriebskosten aufgewertet werden (Barot et al. 2009, S.69-71; Haselmann et al. 2012, S.16):

Application-Service-Provider (ASP) versuchten erstmals, Unternehmen einzelne von Out- sourcing betroffene Anwendungen bei Bedarf (On-Demand) zur Verfügung zu stellen: Die Anwendungen konnten über exklusive Zugänge auf dedizierten Systemen in Rechenzen- tren von Drittanbietern abgerufen werden. Im Vergleich zum Cloud-Computing und seiner Multi-Tenancy-Fähigkeit (Mandantenfähigkeit) wurde allerdings für jeden Kunden eine eigene Server-Instanz aufgebaut. So kam es nur zu einer geringen gemeinsamen Nutzung physischer Ressourcen, wodurch die angestrebten Skaleneffekte und Kosteneinsparungen nicht erreicht werden konnten. Das gesamte Konzept schlug fehl, lieferte aber weitere Ideen für Cloud-Computing (Föckeler, 2009, S.31; Haselmann et al. 2012, S.16-17):

Einen Schritt weiter ermöglichte die Kombination von Konsolidierungs- und Virtualisie- rungskonzepten dem Cloud-Computing die Bereitstellung von flexiblen Services und das Erreichen einer optimierten und kostengünstigen IT-Infrastruktur (Barot et al. 2009, S.70- 71):

Virtualisierungskonzepte bilden die Grundlage der meisten Cloud-Architekturen: Im Ver- gleich zu einem On-Premise-Server wird mit einer virtualisierten Infrastruktur eine Ab- straktion von der tatsächlich vorhandenen Hardware vorgenommen: Eine Virtualisie- rungsschicht wird mit Hilfe einer Virtualisierungstechnologie zwischen die Software- und Hardware-Umgebung eingebracht, sodass es zu einer Abbildung von logischer/virtueller Ressourcen auf physischen Ressourcen kommt (siehe Anhang C): Durch die Virtualisie- rung der Ressourcen ist es möglich, eine Vielzahl von heterogenen physischen Ressourcen zu einer gemeinsamen Menge homogener virtueller Ressourcen zusammenzufassen. Die Auslastung des Systems wird erhöht und der Anwender erhält dadurch die Illusion, auf unendlich viele Ressourcen zugreifen zu können (Haselmann et al. 2012, S.17-19):

Cloud-Computing greift dieses Konzept auf, reduziert physische Server und ersetzt diese durch virtuelle Maschinen. Ressourcen werden dadurch nicht mehr nur von einer Anwen dung dediziert, sondern von mehreren gemeinsam genutzt: Neben einer besseren Systemauslastung (70-90 Prozent) können nun Ressourcen in Form von IT-Services flexibel mehreren Anwendern angeboten werden. Viele Unternehmen besitzen allerdings unterschiedliche verstreute IT-Infrastrukturen, die einen effizienten Betrieb von IT-Services behinderten: Zentralisierungen der IT mussten angestrebt werden, um die gewonnenen Qualitätsverbesserungen und Skaleneffekte sicher zu stellen (Barot et al. 2009, S.71-72; Braun, Kunze, Nimis & Tai, 2011, S.9-18):

Serviceorientierte-Architekturen (SOA) wurden von Unternehmen vor einigen Jahren ein- geführt, um ähnliche Probleme der IT-Heterogenität und Dezentralisierung zu lösen: Dabei bildet SOA eine fundamentale Voraussetzung für Cloud-Computing. Es sind zwei einander ergänzende Konzepte: Unternehmen können mit SOA verschiedene Applikationen in ein- zelne Services zerlegen und flexibel über standardisierte Schnittstellen verbinden, orchest- rieren und kombinieren. Über Webservices werden zwischen den einzelnen Services In- formationen ausgetauscht. Interoperabilität und Integration der Services sind gewährleistet. Auf Basis dieser Grundlage können verteilte, lose gekoppelte IT-Dienste von Clouds ge- nutzt werden: Gerade bei der Kombination von verschiedenen technischen Bereitstel- lungsmodellen der Clouds ist diese Architektur unerlässlich (Barot et al. 2009, S.72-73; Braun et al. 2011, S.19-23; Föckeler, 2009, S.32).

3.2 Begriffserklärung: Cloud-Computing

Cloud-Computing vereint viele angesprochene Technologien und Konzepte, um Ressour- cen verschiedenster Art als elektronisch verfügbare Dienste dynamisch über das Internet oder Intranet zur Verfügung zu stellen. Eine standardisierte, einheitliche Definition gibt es für Cloud-Computing nicht. Allerdings kann auf die viel zitierte Definition des Nationalen- Institut-für-Standards-und-Technologie (NIST) verwiesen werden, die fünf wesentliche Merkmale, drei verschiedene technische Bereitstellungsmodelle und vier unterschiedliche organisatorische Servicemodelle festlegt (Braun et al. 2011, S.4-5; Grance & Mell, 2011, S.2-3):

Entsprechend der Definition werden mit Cloud-Computing nach Bedarf gemeinsam nutz- bare und flexibel skalierbare IT-Leistungen durch nicht fest zugeordnete IT-Ressourcen über ein Netzwerk zur Verfügung gestellt. Die bereitgestellten Ressourcen sollen ständig verfügbar und ohne menschliche Interaktion mit dem Anbieter sich jederzeit, unverzüglich und mittels Selbstbedienung an den tatsächlichen Bedarf des Cloud-Nutzers anpassen (Dehmel, Kriesel, Neugebauer & Weber, 2010, S.15; Haselmann et al. 2012, S.20).

Eine weitere Definition spricht im Gegensatz zu der NIST-Definition von einer expliziten Virtualisierung der Ressourcen und bezeichnet die Clouds als einen großen Vorrat einfach zu benutzender und leicht zugreifbarer virtualisierter Ressourcen. Hardware, Entwick- lungsumgebungen oder Dienste können dabei dynamisch entsprechend dem Bedarf nach oben und nach unten skaliert werden, sodass eine optimale Ressourcennutzung gewährleis- tet wird. Die Abrechnung erfolgt nach der tatsächlichen Nutzung (Pay-per-Use) und im Einklang der vertraglich vereinbarten Service-Level-Agreements (SLAs). Beide Definitio- nen enthalten weitgehend dieselben cloud-typischen Merkmale, sodass sie im folgenden näher betrachtet werden: Gemeinsame Nutzung physischer Ressourcen (Ressourcen- Pooling), unverzügliche Anpassbarkeit an aktuellen Ressourcenbedarf (Skalierbarkeit), Selbstbedienung nach Bedarf (On-Demand und self-service), umfassender Netzwerkzugriff (breitbandiger Netzwerkzugang) und Messung der Servicenutzung (Measured-Service) stellen die Merkmale dar. Hierbei ist zu erwähnen, dass die in der Definition enthaltene Serviceorientierung dahingehend realisiert ist, dass jeder Cloud-Service durch eine Schnitt- stellenbeschreibung nach außen spezialisiert ist und dadurch mit anderen Services gekop- pelt werden kann: So können die Services ähnlich der SOA modular miteinander kombi- niert werden (Braun et al. 2011, S.5-6; Grance & Mell, 2011, S.2; Haselmann et al. 2012, S.20-21; Metzger et al. 2011, S.13-14).

Um das Merkmal Ressourcen-Pooling zu erfüllen, müssen zunächst die physischen Res- sourcen mittels Virtualisierung zu einem gemeinsamen Vorrat/Pool an logischen/virtuellen Ressourcen konsolidiert werden. Anschließend werden sie im Rahmen des Multi-Tenancy- Konzepts den einzelnen Dienstnutzern ihrem Bedarf entsprechend bereitgestellt. Die Man- dantenfähigkeit suggeriert hierbei dem Dienstnutzer der einzige Benutzer der Ressource zu sein, obwohl diese durch eine Vielzahl von Anwendern gemeinsam sowie parallel in An- spruch genommen wird. Durch die Kombination von Virtualisierung und Multi-Tenancy werden die der Cloud zugeschriebenen vorteilhaften Skaleneffekte realisiert, allerdings dem Cloud-Nutzer nicht mehr die Möglichkeit gegeben, den genauen Standort der Res- sourcen zu erkennen. Skalierbarkeit ist ein weiteres Merkmal der Cloud und zeichnet sich dadurch aus, dass ein scheinbarer unlimitierter Vorrat an Ressourcen dem Dienstnutzer zur Verfügung steht: Die Cloud-Dienste können dynamisch bedarfsgerecht das Ressourcenan- gebot unverzüglich nach oben oder unten ohne spürbare Grenzen anpassen. Hierbei werden keine weitere Knoten hinzugefügt, sondern die Anzahl der Ressourcen pro Knoten variiert (scale-out/vertikale Skalierung). Durch die Möglichkeit, sich nach Bedarf selbst zu bedie- nen, kann der Dienstnutzer unverzüglich ohne Einbeziehung des Cloud-Anbieters in Eigeninitiative die benötigte Ressourcenmenge entweder manuell oder vom System automatisch an den Bedarf anpassen lassen. Die Cloud-Dienste werden über einen Netzwerkzu- griff angeboten und bezogen, weshalb eine hinreichend große Bandbreite sinnvoll ist, um die Dienste ausreichend über Internet oder Intranet nutzen zu können. Durch die Verwen- dung von Standardprotokollen können neben Arbeitsplatzrechnern und Laptops auch mo- bilen sowie heterogenen Endgeräten einen Zugriff auf die Cloud ermöglich werden. Zu- sätzlich wird die Servicenutzung quantitativ und qualitativ gemessen, um eine für die Cloud oftmals als Charakteristikum identifizierte Abrechnung nach der Nutzung zu ermög- lichen: Pay-per-Use beschreibt die reine nutzungsabhängige Abrechnung und ist von dem Begriff Pay-as-you-go abzugrenzen: Denn darunter wird eine periodisierte Zahlung (Mo- natsmiete) verstanden, die auch dann zu zahlen ist, wenn keine Nutzung der Dienste erfolgt ist (Braun et al. 2011, S.5-6; Grance & Mell, 2011, S.2; Haselmann et al. 2012, S.22-25; Metzger et al. 2011, S.13-14).

3.3 Modelle von Cloud-Computing

3.3.1 Organisatorische Servicemodelle

Im Folgendem werden entsprechend der NIST-Definition in drei grundlegende organisa- torische Servicemodelle (Public-, Private- und Hybrid-Cloud) unterschieden und zusätzlich weitere mögliche spezielle Formen und Kombinationen aufgezeigt und beschrieben (siehe Anhang D). Alle organisatorischen Servicemodelle erfüllen die cloud-typischen Merkmale und stellen innerhalb ihrer Grenzen die Nutzung der drei technischen Bereitstellungsmo- delle (Serviceebenen) zur Verfügung (Barot et al. 2009, S.29-31; Dehmel et al. 2010, S.17; Haselmann et al. 2012, S.30).

3.3.1.1 Public-Cloud

Die Public-Cloud (Öffentliche-/ External-Cloud) ist ein Servicemodell, bei der Cloud- Anbieter und -Nutzer nicht derselben organisatorischen Einheit angehören. Über das Inter- net werden einer hinreichend großen Anzahl an Cloud-Nutzern hochstandardisierte Cloud- Dienste gegen eine Nutzungsgebühr zur Verfügung gestellt. Eine Spezialform der Public- Cloud stellt die Virtual-Private-Cloud dar: Mit Hilfe geeigneter Sicherheitsmechanismen wird auf der Basis einer Public-Cloud eine von anderen Cloud-Nutzern separierte und in- dividualisierte IT-Umgebung ermöglicht. Der Cloud-Nutzer nimmt über ein Virtual- Private-Network (VPN)-Zugang die Cloud-Dienste und dabei auch sämtliche Skaleneffek- ten in Anspruch (Barot et al. 2009, S.30; Braun et al. 2011, S.27-28; Dehmel et al. 2010, S.18; Haselmann et al. 2012, S.30).

3.3.1.2 Private-Cloud

Im Vergleich zur Public-Cloud wird die Private-Cloud (Internal Cloud) für eine einzige Organisation betrieben, weshalb Cloud-Anbieter und -Nutzer derselben organisatorischen Einheit angehören. Der Cloud-Nutzer betreibt die Cloud-Umgebung selbst und hat sie ent- sprechend seinen Bedürfnissen individuell angepasst, wobei die Cloud-Dienste nur über das Intranet z.B. über VPN-Tunnels in Anspruch genommen werden können (Barot et al. 2009, S.30, Braun et al. 2011, S.28; Dehmel et al. 2010, S.18; Haselmann et al. 2012, S.30).

Eine andere Form der Private-Cloud ist die Hosted-/ Managed-Private-Cloud und Outsour- ced-Private-Cloud: Bei ersterem organisatorischen Servicemodell erfolgt der Betrieb der Cloud innerhalb der Organisation und im Eigentum des Cloud-Nutzer, allerdings in Ver- antwortung eines externen Cloud-Anbieters. Die Outsourced-Private-Cloud stellt hingegen eine Private-Cloud dar, die an einen externen Cloud-Anbieter übertragen oder dort als de- dizierte Cloud-Infrastruktur aufgebaut und in dessen Eigenverantwortung betrieben wird (Barot et al. 2009, S.31).

3.3.1.3 Hybrid-Cloud

Die Hybrid-Cloud ist kein eigener Cloud-Typ, sondern eine Bezeichnung für die Kombina- tion mehrerer organisatorischer Servicemodelle untereinander, aber auch einer Kombinati- on von Clouds mit der eigenen On-Premise-IT-Umgebung. Die Kombination erfolgt über Standards und ermöglicht die parallele Nutzung der jeweils mit der Technologie verbunde- nen Leistungen und hat damit Vorteile. Während die Gesamtverantwortung beim Kunden verbleibt, wird die Betriebsverantwortung entsprechend auf die jeweiligen Servicemodelle aufgeteilt (Braun et al. 2011, S.28-29; Dehmel et al. 2010, S.18-19; Haselmann et al. 2012, S.31).

3.3.2 Technische Bereitstellungsmodelle von Cloud-Computing

Cloud-Computing stellt IT-Leistungen als Dienste (as-a-Service) bereit, wobei die Defini- tion von NIST drei konkrete technische Bereitstellungsmodelle vorschlägt: Infrastructure- as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS). Ne- ben den drei genannten gibt es eine nahezu unüberschaubare Vielfalt an Bezeichnungen für die Bereitstellungsmodelle des Cloud-Computing, die wegen ihres gemeinsamen Suffix unter dem Begriff Anything-as-a-Service (XaaS) zusammengefasst werden können (Ha- selmann et al. 2012, S.27-28).

Die einzelnen technischen Bereitstellungsmodelle lassen sich entsprechend ihrem Abstrak tionsgrad in ein Schichtenmodell einordnen (siehe Anhang E). Die höheren Schichten können die Dienste aller unterliegenden Schichten für ihre Dienstrealisierung benutzen und wenn nötig auch bspw. die nächst tiefer liegende Schicht überspringen: Demnach kann eine SaaS-Lösung auch direkt auf einer IaaS-Lösung ohne den PaaS-Dienst realisiert werden. Im Nachfolgenden werden die von NIST priorisierten Bereitstellungsmodelle aufgezeigt (Braun et al. 2011, S.29-31; Haselmann et al. 2012, S.28-29).

3.3.2.1 Infrastructure-as-a-Service

Anstelle eines klassischen Erwerbs von Hardware kann über dieses Bereitstellungsmodell dem Cloud-Nutzer nach Bedarf IT-Infrastruktur als Service angeboten werden. Hierbei werden Server, Speicher, Netzwerk und andere Rechenzentrums-Infrastruktur als abstrak- ter, virtualisierter Service über ein Netzwerk bereitgestellt und nutzungsabhängig abge- rechnet. Durch die Virtualisierung wird dem Dienstnutzer ein unerschöpfliches Rechen- zentrum illusioniert, dessen Infrastruktur hoch skalierbar dem Ressourcenverbrauch ent- sprechend in alle Richtung flexibel anpassbar ist. Über eine Web-Oberfläche kann der Cloud-Nutzer seinen geänderten Bedarf mitteilen. Die Verantwortung über die physische Hardware (Backup und Wartung) obliegt dem Dienstanbieter, während der Dienstnutzer die oberhalb angesiedelten Schichten (PaaS und SaaS) mit Betriebssystem, Datenbanken und Software in Eigenverantwortung verwalten und priorisieren muss (Barot et al. 2009, S.24-25; Grance & Mell, 2011, S.3; Haselmann et al. 2012, S.30 & 78-79).

3.3.2.2 Platform-as-a-Service

Das oberhalb der IaaS-Schicht angesiedelte Bereitstellungsmodell PaaS ist nicht an Endkunden, sondern vor allem an Entwickler gerichtet (Braun et al. 2011, S.35):

Der Cloud-Dienst liefert nicht nur eine Plattform zum Betrieb von Software (Laufzeitumgebung), sondern auch eine Entwicklungsumgebung, um innerhalb der Cloud-Infrastruktur mit einer vom Anbieter festgelegten Programmiersprache Software (Cloud-Dienste) zu erstellen (Haselmann et al. 2012, S.29).

Anders als bei IaaS übernimmt der Nutzer hierbei für die untere Schicht mit Server, Spei- cher, Netzwerk und Betriebssystem keine Verantwortung, sondern konzentriert sich ledig- lich auf die eingesetzte Software (Amr et al. 2011, S.643; Grance & Mell, 2011, S.2-3).

3.3.2.3 Software-as-a-Service

SaaS ist im Rahmen von Cloud-Computing die oberste Schicht, bei der eine Software unmittelbar durch den Endanwender über das Netzwerk bezogen werden kann. Anstelle einer lokalen Software-Installation bzw. einer bei ASP üblichen Software-Installation je Dienstnutzer wird eine gemeinsam nutzbare Software bereitgestellt (siehe Anhang C): Alle Endanwender nutzen dieselbe Software auf einer standardisierten Code-Basis, die nach den Bedürfnissen aller Anwender konfiguriert wurde. Die Multi-Tenancy-Architektur sorgt dafür, dass die Daten der einzelnen Endanwender strikt logisch voneinander getrennt sind (Barot et al. 2009, S.27; Föckeler, 2009, S.34-35).

Die Priorisierung der benötigten Ressourcen (Erkennung und Anpassung von Ressourcenbedarf) geschieht hierbei manuell oder automatisch. Der Dienstnutzer muss sich nicht um Betrieb, Wartung, Weiterentwicklung oder Lizensierung der Software und der Hardware (Server, Storage, Netzwerk und Betriebssystem) kümmern. Diese Übertragung der Verantwortung ist auch eine Schenkung von Vertrauen an den Cloud-Anbieter, was aber gewollt und ein Vorteil des Cloud-Paradigmas darstellt (Grance & Mell, 2011, S.2; Haselmann et al. 2012, S.28-29, 79 & 185).

Die über SaaS angebotenen Dienste können einzelne oder komplexe Anwendungen beinhalten. Teile der Anwendungen können entweder direkt vom Endkunden genutzt werden oder stellen lediglich Komponenten dar, die andere Anwendungen unterstützen und miteinander in Verbindung stehen (Braun et al. 2011, S.37-38).

4 Business-Intelligence-in-the-Cloud

4.1 Begriffserklärung: Business-Intelligence-in-the-Cloud

Um das Thema Business-Intelligence-in-the-Cloud (BI-in-the-Cloud) auszuarbeiten, wer- den nun die beiden Themengebiete Cloud-Computing und BI in einen Kontext gebracht: Entsprechend den zuvor aufgeführten Definitionen wird unter BI-in-the-Cloud ein Konzept verstanden, das es ermöglicht, die Fähigkeiten eines BI-Systems mit Hilfe von Cloud- Computing als Cloud-Dienste zur Verfügung zu stellen (Dresner, 2012, S.11; Gurjar & Rathore, 2013, S.82):

Dabei werden die Komponenten der Datenaufbereitung und -nutzung eines BI-Systems als gemeinsam nutzbare und flexibel skalierbare IT-Leistung (BI-Cloud-Dienst) durch nicht fest zugeordnete ständig verfügbare IT-Ressourcen über ein Netzwerk zur Verfügung gestellt und entsprechend der tatsächlichen Nutzung abgerechnet (Dehmel et al. 2010, S.15; Dittmar et al. 2008, S.90-92; Haselmann et al. 2012, S.20).

Auch bei diesem Konzept gelten die in Absatz 3.2 genannten Merkmale des Cloud- Computing, die aufgrund der Kombination von Cloud und BI hinsichtlich verschiedener Aspekte im Abschnitt 5 kritisch analysiert werden müssen: Die Cloud-Dienste greifen bspw. im Rahmen des Ressourcen-Poolings auf einen gemeinsamen Vorrat an virtualisier- ten Ressourcen zu, die über das Multi-Tenancy-Konzept entsprechend dem Bedarf des jeweiligen Cloud-Nutzers bereitgestellt werden: Bestimmte Cloud-Dienste speichern und verwenden sensible Daten, die einen besonderen Schutz benötigen und womöglich auf einer mit anderen Parteien gemeinsam genutzten Infrastruktur gelagert werden. Trotz der logischen Trennung der verschiedenen Mandanten bedarf es hier einer näheren Diskussion über Daten- und Systemsicherheit sowie Datenschutz. BI-Komponenten, die ressourcenin- tensiv und/oder einer unregelmäßigen Systemauslastungen unterliegen, treffen hingegen auf das Cloud-Merkmal Skalierbarkeit: Dadurch erlangen sie die Fähigkeit, auf einen scheinbar unlimitierten Ressourcenvorrat zuzugreifen und ihren Bedarf dynamisch nach oben und unten anzupassen, weshalb wirtschaftliche und technische Aspekte betrachtet werden sollten. Aufgrund des serviceorientierten Charakters der Cloud-Dienste müssen Fragen bezüglich der Integrationsfähigkeit in die Unternehmensinfrastruktur und der mo- dularen Kombination mit anderen Cloud-Diensten (Schnittstellen) beantwortet werden. Der Bezug von BI-Fähigkeiten über ein Netzwerk (Internet und/oder Intranet) und ein ge- nerell mögliches Abhängigkeitsverhältnis des Unternehmens wirft technische und organi- satorische Fragen auf. Die der Cloud als Charakteristikum zugeschriebene nutzungsabhän- gige Abrechnung betrifft auch die BI-Cloud-Dienste, sodass wirtschaftliche Aspekte be- trachtet werden müssen, um herauszufinden, welche BI-Komponenten als Cloud-Dienst überhaupt wirtschaftlich sind (Braun et al. 2011, S.5-6; Grance & Mell, 2011, S.2; Hasel- mann et al. 2012, S.20-25; Metzger et al. 2011, S.13-14).

4.2 Framework des Business-Intelligence-in-the-Cloud

Die IT-Architektur von Unternehmen ist sehr spezifisch, weshalb in diesem Abschnitt eines von vielen möglichen Frameworks des BI-in-the-Cloud-Konzeptes erarbeitet wird. Hierzu wird das zuvor aufgezeigte weite Verständnis von BI mit seinen Komponenten in die technischen Bereitstellungsmodelle des Cloud-Computings integriert und ein erweitertes Framework erstellt (siehe Anhang F) (Baars & Kemper, 2010, S.1531; Bernhardt & Seufert, 2010, S.5-6; Bernhardt & Seufert, 2011a, S.100; Gluchowski & Kemper, 2006, S.14-17; Haselmann et al. 2012, S.80):

4.2.1 Infrastructure-as-a-Service

Bei der IaaS-Schicht handelt es sich auch im Kontext des BI-in-the-Cloud um die unterste Schicht im Bereitstellungsmodell, die den oberhalb angesiedelten Schichten (PaaS und SaaS) die benötigte Hardware in Form von hoch skalierbaren virtualisierten Ressourcen zur Verfügung stellt (Barot et al. 2009, S.25; Grance & Mell, 2011, S.3; Haselmann et al. 2012, S.30)

Die BI-Cloud-Dienste befinden sich z.B. in der SaaS-Schicht und werden über IaaS mit den Ressourcen bedarfsgerecht versorgt. Dabei können sie auf einen nahezu unerschöpfli- chen und flexibel anpassbaren Ressourcenvorrat zugreifen, um bspw. Aufgaben im Bereich der Datenaufbereitungs- und/oder Datennutzungsaufgaben eines BI-Systems zu erfüllen. Neben der Versorgung der BI-Cloud-Dienste kann die IaaS-Schicht auch Unternehmen mit einem On-Premise-BI-System außerhalb der Cloud unterstützen (siehe Anhang G). Dabei werden ohne den klassischen Erwerb von Hardware, bspw. bei Ressourcenengpässe, die notwendigen Ressourcen für das BI-System über ein Netzwerk als Cloud-Service in die Infrastruktur des Unternehmen integriert. Bestehen die Ressourcenengpässe nicht mehr, kann der Service von der hauseigenen Infrastruktur abgekoppelt werden (Bronzin & Stipić, 2012, S.1920; Gurjar & Rathore, 2013, S.84; Metzger et al. 2011, S.20).

4.2.2 Platform-as-a-Service

Unternehmen können auch die Services einer PaaS-Schicht beziehen und eine Laufzeitum- gebung sowie eine Entwicklungsumgebung in Anspruch nehmen (Braun et al. 2011, S.35):

Mit Hilfe der Laufzeitumgebung können Unternehmen eigene BI-Komplettsysteme in der Cloud realisieren und auf der SaaS-Ebene als BI-Cloud-Dienste bereitstellen (Amr et al. 2011, S.645; Bronzin & Stipić, 2012, S.1920; Gund, Menon & Rehani, 2012, S.26; Gurjar & Rathore, 2013, S.84; Menon & Rehani, 2012, S.7).

Durch die Entwicklungsumgebung besteht für Entwickler die Möglichkeit, im Rahmen einer vom Cloud-Anbieter festgelegten Programmiersprache eigene BI-Cloud-Dienste zu programmieren und als Service dem Unternehmen zur Verfügung zu stellen (Gund et al. 2012, S.26; Haselmann et al. 2012, S.29).

Vor allem in Hinblick auf die Individualisierung des BI-in-the-Cloud-Konzeptes an unternehmensspezifische Prozesse spielt die PaaS-Schicht eine wesentliche Rolle: Es können dem Unternehmen neue Services bereitgestellt oder aber entsprechend den neuen Anforderungen bestehende Services angepasst werden.

4.2.3 Software-as-a-Service

Die SaaS-Schicht ist auch im BI-in-the-Cloud-Framework die oberste Schicht, bei der Software als Service dem Cloud-Nutzer über ein Netzwerk angeboten wird. Anstelle der Bezeichnung Software kann von den jeweiligen BI-Komponenten gesprochen werden, die sich nach dem weiten Verständnis der BI-Definition in die Ebene der Datenbereitstellung und Datennutzung unterteilen: Dabei wandeln sie sich bspw. innerhalb der Datenbereitstel- lungsebene zu den BI-Cloud-Diensten ETL-as-a-Service (ETLaaS), Data-Warehouse-as-a- Service (DWHaaS) und Data-Mart-as-a-Service (DAMAaaS) um. Jeder Cloud-Dienst stellt hierbei einen eigenen Service mit den jeweiligen typischen BI-Funktionalitäten dar. Auf- grund der Serviceorientierung kann das Unternehmen nach Bedarf die Services in An- spruch nehmen oder beenden bzw. mit anderen Services und der unternehmenseigenen Infrastruktur kombinieren. Dadurch entstehen eine Vielzahl an Kombinationsmöglichkei- ten (Frameworks), wobei jedes Unternehmen im Einzelnen die im 5. Abschnitt beschriebe- nen wirtschaftlichen, organisatorischen, sicherheitsrelevanten, funktionalen sowie techni- schen Aspekten abwägen sollte. Denn der Bezug einzelner oder ganzer Kombinationen von BI-Cloud-Diensten und deren Integration kann je nachdem Vorteile, Nachteile, Chancen und Risiken für das Unternehmen bedeuten: Bspw. bestimmt die Güte des oftmals kompli- zierten ETL-Prozesses erfolgskritisch die Qualität der im DWH verfügbaren Daten: Das Unternehmen muss entscheiden, ob diese Komponente im eigenen Unternehmen selbst betrieben oder als ETLaaS bezogen wird (Bronzin & Stipić, 2012, S.1919; Gluchowski & Kemper, 2006, S.13).

Das DWH kann ebenfalls als Service bezogen werden, weshalb auch hier die angesproche- nen Aspekte näher betrachtet werden müssen: Es ist in der Regel sehr groß, enthält wett- bewerbskritische und personenbezogene Daten, und benötigt eine angemessene Perfor- mance, Stabilität und Zugriffsgeschwindigkeit. Ob die Komponenten der Datenbereitstel- lung einzeln oder auch im Verbund mit anderen aus der Cloud bezogen werden sollten, muss kritisch analysiert werden (siehe Anhang H) (Ariyachandra, Frolick & Gash, 2011, S.264; Gund et al. 2012, S.25; Gurjar & Rathore, 2013, S.85; Kucharska, Rostek & Wiśniewski, 2013, S.117; Menon & Rehani, 2012, S.7; Thompson & Van der Walt, 2010, S.1).

Die aufgeführten BI-Cloud-Dienste können auch unter dem Begriff Data-as-a-Service (DaaS) zusammengefasst werden, wobei die Datenbereitstellungsschicht nicht nur die Aufbereitung der internen Datenbestände umfasst, sondern auch die Anreicherung mit ex- ternen Daten über sonstige Cloud-Schnittstellen (Bernhardt & Seufert, 2011a, S.101-102).

[...]

Ende der Leseprobe aus 82 Seiten

Details

Titel
Business Intelligence in the Cloud. Überblick und Bewertung
Hochschule
Universität des Saarlandes
Veranstaltung
Wirtschaftsinformatik und Controlling
Note
2,7
Autor
Jahr
2013
Seiten
82
Katalognummer
V271655
ISBN (eBook)
9783656625704
ISBN (Buch)
9783656625698
Dateigröße
1636 KB
Sprache
Deutsch
Schlagworte
business intelligence, business intelligence system, systeme, data warehouse, sap, datawarehouse, microsoft, entwicklungsweg, cloud-computing, cloud, begriffserklärung, modelle, organisatorische servicemodelle, public cloud, publiccloud, privatecloud, private cloud, hybrid cloud, hybridcloud
Arbeit zitieren
M.Sc. Martin Stroh (Autor:in), 2013, Business Intelligence in the Cloud. Überblick und Bewertung, München, GRIN Verlag, https://www.grin.com/document/271655

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Business Intelligence in the Cloud. Überblick und Bewertung



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden