ngineering I
Wiederholungs-Skript-IE1
A - besonders relevant, B - nur ein gutes Bild, nicht markiert - irgendwie relevant, Wwichtige Kernideen wiedergeben können. Immer oberhalb notiert
Integration als Prozess (W, selber erarbeiten, welche Begriffe helfen)
ALS PROZESS - INTEGRIERUNG
formatik | Professur
Informationsmanagement
Hier
sehr umfangreiche
Anmerkungen in Vorlesungen. Wesentlich sind:
Begriffe und Beziehungen (IVerfahren wird im IProzess eingesetzt)
5
Integration-Engineering(IE): W
- Kurbel/Rautenstrauch 1996: „Gegenstand des Integration Engineering ist die Analyse,
Entwicklung und Anwendung von Prinzipien, Modellen, Methoden und Werkzeugen für die
Erstellung von IIS [Integrierten Informationssystemen].“
- ingenieurmäßiger Prozess der Integrierung
- Orientierung an einem Vorgehen
- zu integrierende Sachverhalte – insbesondere Daten und Funktionen neuerdings mit
Semantik (Ontologien)
- IE liefert „das Handwerkszeug mit zugehörigen Einsatzanweisungen [Verfahren], damit
Integrierung durchgeführt werden kann“ (A)
- Ex-ante-Integrierung - Neuentwicklung von IIS (A)
- Ex-post-Integrierung - Zusammenführung bereits existierender IIS (A)
AUFGABENBEREICHE DES INTEGRATION-ENGINEERING
- Integrationsprojekte im Integration-Engineering:
B:
Einführung | Integration Engineering I
A:
AUFGABENBEREICHE
DES INTEGRATION-ENGINEERING
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
15
- Operationen zur Ex-ante-Integrierung:
- Erstellung = Erstellung eines IObjekt
- Vernichtung = Gegenoperation zur Erstellung
- Anpassung = IObjekt so anpassen, dass es
integrationsfähig wird
- Restrukturierung = innere Struktur des
verändern (ohne Schnittstellenveränderungen)
(invasiv)
- Schnittstellenergänzung = eine oder
mehrere Schnittstellen ergänzen (invasiv)
- Schnittstellenentfernung = entgegengesetzte Operation
zurI Schnittstellenergänzung
Einführung | Integration
Engineering
(invasiv)
AUFGABENBEREICHE
DES INTEGRATION-ENGINEERING
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
A:
17
- Operationen zur Ex-post-Integrierung:
- direkte Kopplung = erstellen einer Verbindung zwischen den IObjekten
- indirekte Kopplung = IObjekte über ein spezielles System – das
Kopplungssystem – verbinden
- Verschmelzung = zwei bestehende
IObjekte zu einem neuen verschmelzen
- Entkopplung = Trennung von
IObjekten, die durch direkte oder
indirekte Kopplung verbunden sind
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
20
W
Bezogen auf den Integrationsprozess:
- Beschreibung geeigneter Vorgehensmodelle (inkl. Dokumentation der
zugehörigen Einsatzkriterien und Anpassungsmöglichkeiten)
- Sicherstellung des integrierten Einsatzes von Verfahren, Techniken, Methoden,
Hilfsmitteln und Werkzeugen innerhalb eines Integrationsprojekts
- z.B. Schaffung von Werkzeugunterstützung, die integrierten Einsatz unterstützt
- Sicherstellung einer projektübergreifenden Wiederverwendung entwickelter Verfahren,
Techniken, Methoden, Hilfsmittel, Werkzeuge und auch von Ergebnissen über mehrere
Integrationsprojekte hinweg
- Durchführung von Integrationsprojekten einschließlich Bewertung
Beziehungen zwischen Unternehmen:
- reine Leistungsaustauschbeziehungen
- Koordination ablaufender Transaktionen durch Mechanismen des Marktes
- Zweckbeziehungen
- Effizienzsteigerungen durch gemeinschaftliches Handeln
- unter dem Begriff Integration zusammengefasst
- Unternehmen = IObjekte - Kooperation
- rechtliche und wirtschaftliche Selbstständigkeit - Konzentration
A:
Integration unabhängiger Unternehmen
Ziele:
- Expansion – Stärken der Position auf angestammten Märkten bzw. mit
angestammten
Produkten
- Diversifikation – Erweiterung der Produktpalette bzw. der Zielmärkte
- Gründe:
- wirtschaftlicher Vorteil
- verfolgte Ziele sind in erster Linie geschäftlicher Natur
- funktionelle, quantitative und technische Ziele sind untergeordnet
- Spezialisierung, Effizienzerhöhung
- Kostenvorteil, z. B. Senkung Transaktionskosten
Risiken (Wesentliches):
- Kostennachteile
- fallen im Vergleich zu alternativen Koordinationsformen an
- Gründungs-, Koordinations-, Kommunikations- und Transportkosten
- Zeitnachteile und Agilitätsverlust
- Verlängerung des Entscheidungsweges – Verschlechterung der Reaktionsfähigkeit
- Wissensabfluss
- Austausch von Wissen zwischen Partnern
- einseitigerAbflussvonWissenohneentsprechendeGegenleistung-Gefahr für die
Wettbewerbsfähigkeit eines Kooperationspartners
- Verlust der Wettbewerbsfähigkeit
- durch Auslagerung von Forschungs- und Entwicklungs (FuE)-Tätigkeiten - Verlust an
Innovationskraft
- Verlust an Wettbewerbsfähigkeit
- Verringerung der Attraktivität des Unternehmens
Einführung | Integration
Engineering I
- Abhängigkeit
- Ausgliederung von Aufgaben
- zunehmende Abhängigkeit von diesen Aufgabenträgern - hohe Spezialisierung kann
INTEGRATIONSOBJEKTE
zur Monopolisierung führenIN UNTERNEHMEN
Architektur:
INTEGRATIONSOBJEKTE IN UNTERNEHMEN - Strategische Integration
• Organisation
eines Systems, Geschäftsfeldintegration - Organisatorische und
- Strategiekomplementarität,
administrative
• dargestellt
durch Integration
dessen Komponenten, deren Beziehungen zueinander und zur
- Prozessintegration, Controllingintegration - Personelle Integration
Umgebung
- Führungsstil, Vergütungssysteme - Kulturelle Integration
- Corporate Identity und Design - Operative Integration
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
- Konsolidierungen,
Kostensynergien
- Externe Integration
- Kommunikation und Einbindung von Stakeholdern
Geschäftsprozess (GP): A
- ist zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von
mehreren Organisationen oder Organisationseinheiten unter Nutzung von
Informations- und Kommunikationstechniken ausgeführt werden können
- Unterscheidung in:
- Steuerungsprozesse
- Kerngeschäftsprozesse (primäre Prozesse)
- Unterstützungsgeschäftsprozesse (Querschnittprozesse)
- Steuerungsprozesse: integratives Zusammenspiel der Gesamtheit der
Geschäftsprozesse
- Kernprozesse: Leistungserstellung
- Unterstützungsgeschäftsprozesse: Unterstützung und Sicherstellung der
Kernprozesse
Workflows: A
- im engen Zusammenhang zu GP
- Workflow modelliert automatisierbare Aktivitäten
- Ausführung durch Workflowmanagementsysteme
- Workflow-Modelle - Verfeinerung von Geschäftsprozessmodellen
- Ziel: (Teil-)Automatisierung der Prozesse in Form von Workflow
30
Unterscheidung: A
- Geschäftsprozessmodellintegration (Modelle)
- Geschäftsprozessintegration (reale Objekte) - Geschäftsprozessmodellintegration:
- Geschäftsprozessmodelle sind die Integrationsobjekte
- spezielle Geschäftsprozessmodellierungssprachen, z.B.:
- Ereignisgesteuerte Prozessketten (EPKs)
- Business Process Modelling Notation (BPMN)
- Integrationsart:
- Verbindung (z. B. Aufrufbeziehung)
- Verschmelzung (Zusammenführung)
Geschäftsprozessintegration: A
- Integrationsobjekte sind Geschäftsprozesse
- Ergebnis einer fachlichen Abstimmung über den Geschäftsprozess
- Ziel: durchgängiger Geschäftsprozess
- zu berücksichtigen sind:
- organisatorische GP-Integration – technische GP-Integration
Verteilte Informaitonssysteme
Blockierende und Synchrone Interaktion: A
- traditionell – Nutzung blockierender Aufrufe
- Synchrone Interaktion: Sender und Empfänger “on-line”
- Sender sendet Request
- Empfänger erhält und verarbeitet Request
- Empfängers endet Antwort an Sender zurück
- Sender muss bis Eintreffen der Antwort warten
- Empfänger muss zum Zeitpunkt des Aufrufs nicht existieren
- ABER: Interaktion erfordert, dass Sender und Empfänger zur gleichen Zeit “am
Leben” sind
Nachteile durch Synchronisation: A
- Verbindungs-overhead
- erhöhte Fehlerwahrscheinlichkeit
- Schwierigkeiten der Identifizierung und Reaktion auf Fehler
Design von Informationssystemen | Integration Engineering I
- 1-zu-1-System–nicht praktisch für geschachtelte Aufrufe und komplexe
Interaktionen
KOMMUNIKATION IN INFORMATIONSSYSTEMEN
- Overhead durch Synchronisation:
- Synchrone Interaktion erfordert
- Kontext für jeden Aufruf
- Kontextmanagementsystem für alle ankommenden Aufrufe
- Kontext identifiziert
- Session
- Client
- Art der Interaktion
à Erfordert Session zwischen Sender und Empfänger
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
5
Design von Informationssystemen | Integration Engineering I
KOMMUNIKATION IN INFORMATIONSSYSTEMEN
- Overhead durch Synchronisation:
- Aufrechterhaltung der Session ist teuer und konsumiert CPU- Ressourcen
- Limit an aktiven Sessions = Limit an Clientverbindungen zum Server
- connection pooling zur Optimierung der Ressourcenauslastung
- Pool von offenen Verbindungen
Design von Informationssystemen | Integration Engineering I
- Assoziieren eines Threads mit jeder Verbindung
- Bündelungen von Verbindungen
KOMMUNIKATION IN INFORMATIONSSYSTEMEN
W:
- Fehler bei synchronen Aufrufen - Lösungsmöglichkeiten:
für Wirtschaftsinformatik
| Professur Informationsmanagement
- Institut
1. Erweiteter
Support
- Transaktionale Interaktion:
6
- Sicherstellen einer “exactly-once” Ausführung
- Ermöglichung komplexer Interaktionsmuster mit Ausführungsgarantien
Design von Informationssystemen | Integration Engineering I
- Service Replikation und Load Balancing:
KOMMUNIKATION
IN INFORMATIONSSYSTEMEN
- Sicherstellen der Verfügbarkeit eines Services (àFehlertoleranz)
- Fehlerbehandlung auf Clientseite immer noch notwendig
- Fehler
bei synchronen Aufrufen - Lösungsmöglichkeiten:
W
- 2.
Asynchrone
Institut
für WirtschaftsinformatikInteraktion
| Professur Informationsmanagement
- Sender sendet Nachricht
7
- Nachricht wird gespeichert bis Empfänger sie abruft
- Empfänger sendet Antwort auf gleiche Weise zurück
- Zwei Formen:
- Nicht-blockierender Aufruf
- Persistente Warteschlange
Design von Informationssystemen | Integration Engineering I
KOMMUNIKATION
IN INFORMATIONSSYSTEMEN
W
- Message queuing:
8
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- ideales Komplement zur synchronen Interaktion:
- unterstützt gute Modularisierung
- verbesserte Verteilung der Rechenleistung auf mehrere Maschinen
- bessere Unterstützung von Multicasts,
Transfer, Replikation
request()
- hilfreich für das Handling der
queue
receive
Kommunikations-Sessions
process
- guter Weg zur Implementierung von komplexen
return
Interaktionen zwischen heterogenen
queue
do with
Systemen
answer
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
9
MIDDLEWARE (W)
- Erleichtern und Managen der Interaktionen zwischen Anwendungen in
heterogenen Infrastrukturen
Design von Informationssystemen | Integration Engineering I
- Integration von Servern und Applikationen über eine allgemeine
Serviceschnittstelle
EINFÜHRUNG
MIDDLEWARE
- Middleware als Programmierabstraktion:
-
Verbergen der Hardware- und Plattformdetails
größere Anzahl an leistungsfähigen Stammfunktionen und Schnittstellen
schwierige Aufgaben an Vermittler übergeben (Compiler, Optimizer , …)
Reduzierung von Programmierfehlern, Entwicklungs- und Wartungskosten
Middleware bietet Programmierabstraktionen:
- Verständnis des Programmiermodells
- Programmiermodell bestimmt:
- Einschränkungen
- generelle Performanz
Design von Informationssystemen | Integration Engineering I
- Eignung eines Types von Middleware
- wie Plattform entwickelt wird und
- wie Plattform sich bei neuen Technologien bewähren kann
EINFÜHRUNG MIDDLEWARE
Application servers
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
TP-Monitors
Object
brokers
Message
brokers
11
Spezialisierte Formen von RPC, mit zusätzlichen
Funktionalitäten oder Eigenschaften, aber fast immer auf RPC
Plattformen laufend
Remote Procedure Call: versteckt Kommunikations-details
hinter Prozeduraufruf und hilft beim Überrücken
Remote Procedure Call
von heterogenen Plattformen
Sockets: Interface auf OS Ebene verbirgt das
darunter liegende Kommunikationsprotokoll
Sockets
TCP, UDP:
User Datagram Protocol (UDP) transportiert
Datenpakete
Design von Informationssystemen | Integration Engineering
I ohne Garantien
TCP, UDP
Transmission Control Protocol (TCP) prüft korrekte Übermittlung der
Datenströme
Internet Protocol (IP):
Internet Protocol (IP)
transportiert ein Datenpaket von einem Knoten zum anderen
EINFÜHRUNG MIDDLEWARE
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Middleware als Infrastruktur:
12
- komplexe Software Infrastruktur realisiert die Abstraktionsschichten
- heutiger Trend:
- erhöhte Komplexität
- Produkte liefern mehr und mehr Programmierabstraktionen unter
Einbeziehung weiterer Layer (z.B. Web Server)
Ø Middleware Plattformen als sehr komplexe Softwaresysteme
- RPC als bestes Beispiel à hat sich über Jahre weiterentwickelt
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
14
Design von Informationssystemen | Integration Engineering I
REMOTE PROCEDURE CALL – RPC
- Funktionsweise:
- 1. Schritt: Definition der Prozedurenschnittstelle
- mittels Interface Definition Language (IDL)
- IDL liefert abstrakte Repräsentation der Input- und Return-Parameter der
Funktion
- 2. Schritt: Compilieren der IDL-Beschreibung
- es entstehen folgende Artefakte:
Design von Informationssystemen | Integration Engineering I
- Client Stubs
- Server Stubs
- Code-Templates
Referenzen
REMOTE PROCEDURE
CALLund
– RPC
A
- Funktionsweise:
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
16
- Artefakte:
- Client Stubs: Verbindung zum Client - verantwortlich für Prozeduraufruf
(Binding), Datenformatierung (Marshalling und Serialisierung),
Kommunikation mit dem Server, Request/Response-Abwicklung
- Server Stubs: analog zum Client Stub - verantwortlich für serverseitige
Abwicklung
- Code-Templates und Referenzen: IDL-Compiler liefert alle Zusatzdateien,
die für Entwicklung benötigt werden
- RPC-Stubs decken alle Netzwerk-Kommunikationsdetails (Timeouts,
Retransmissions, etc.) ab
- Bei Erforderung von mehr Steuerung à Lieferung von verschiedenen Interfaces
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
18
Design von Informationssystemen | Integration Engineering I
W
BROKER
- Object Broker:
- erweitern RPC Paradigma um Objekt-orientierte Welt
- bieten Reihe von Services
- erleichtern Entwicklung von verteilten Objekt-orientierten Anwendungen
- unterstützen Interoperabilität zwischen Objekten als Middleware-Infrastrukturen
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
22
Design von Informationssystemen | Integration Engineering I
BROKER
- Common Object Request Broker Architecture – CORBA:
- Ziele:
- Unterstützung verteilter und heterogener Objekt-Requests in einer für den
Nutzer und Anwendungsprogrammierer transparenten Art
- Erleichterung der Integration von neuen und Legacy Komponenten
- Offener Standard
- basierend auf breitem Industriekonsens
- Object Model:
- Objekte, Typen, Module, Attribute, Operationen, Requests
Design von Informationssystemen | Integration Engineering I
- Exceptions, Subtypen
A
Institut für Wirtschaftsinformatik
| Professur
Informationsmanagement
MESSAGE
ORIENTED
MIDDLEWARE
- MOM
23
- Historischer Hintergrund:
- Idee nicht neu, asynchrone Interaktionen bereits für:
- Batchsysteme
- in RPC
- TP-Monitore nutzten bereits Queuing-Systeme (Tuxedo)
- Moderne MOM direkte Nachfahren von Queuing Systemen
- Persistente Warteschlangen seit Beginn 90-er Jahre bekannt
- für die Entwicklung von breitgefächerten und großen Systemen
- heute: präferierte Integrationslösung
- Beispiele:
- Standalone: IBM WebSphere MQ, Microsoft Message Queuing (MSMQ), Oracle
Java System Message Queue
- Bestandteil von: Java EE (JMS und Message-Driven Beans)
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
B
36
Design von Informationssystemen | Integration Engineering I
MESSAGE ORIENTED MIDDLEWARE - MOM
- Nachrichtenbasierte Interoperabilität:
a) Sender (Client) sendet Angebot an Empfänger (Server)
b) Empfänger sendet Antwort zurück an Sender
Empfänger
Sender
a)
b)
Message quoteRequest {
Message-Oriented Middleware
QuoteReferenceNumber: 325
Customer: IWI
Item: #115 (Laptop, Sony)
Message quote {
Quantity: 5
QuoteReferenceNumber: 325
ExpectedDeliveryDate: 30.11.2010
RequestedDeliveryDate:
01.12.2010
Design von
Informationssystemen | Integration
Engineering I
DeliveryAddress: Leipzig
}
Price: 10.000 € }
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
MESSAGE
ORIENTED MIDDLEWARE - MOM
38
B
- Architektur:
- Kernkonzepte: Nachrichten, Warteschlangen und Warteschlangenverwalter
- Umwandlung der Nachrichten in vorgegebenes Nachrichtenformat zur
Übertragung
- Übergabe an Warteschlangenverwalter
Sender
Warteschlangen
Warteschlangenverwalter
Design von Informationssystemen | Integration Engineering
I
Zugriffsschnittstelle
Empfänger
Zugriffsschnittstelle
Middleware Protokoll
Protokollstack
MESSAGE ORIENTED MIDDLEWARE - MOM
A
40
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Architektur:
- Transport der Nachricht über Subnetzgrenzen auch Aufgabe von
Warteschlangenverwaltern (Router)
- diese führen auch Transformationen in andere Formate aus
Verwalter
Verwalter
Sender
Empfänger
Verwalter
Sender
A
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Empfänger
42
Design von Informationssystemen | Integration Engineering I
MESSAGE ORIENTED MIDDLEWARE - MOM
- Message Queues:
Vorteile
Nachteile
Sender/Empfänger muss nicht ständig auf
Nachricht warten
fehlende Typsicherheit
Empfänger Kontrolle über
Nachrichtenprozess
Overhead durch Ver-/ Entpacken und
Übermittlung der Nachrichten
hohe Fehlerrobustheit
•
Empfänger nicht ständig aktiv sein
•
wenn nicht aktiv à Nachricht
zwischengespeichert
•
Ablaufdatum
lose Kopplung zwischen Client und Server
Design von Informationssystemen | Integration Engineering I
hohes Maß an Interoperabilität zwischen
heterogenen Systemen
MESSAGE
ORIENTED MIDDLEWARE - MOM
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
A
45
- Kommunikationsarten:
- Point-to-Point – Standardfall eines nachrichtenorientierten Programmiermodells
- 2 Kommunikationspartner
- Request-Reply-Modell
- 2-Wege-Kommunikation (auch synchrone Kommunikation möglich)
- Verwendung von temporären Reply-Warteschlangen
- Publish-Subscribe-Modell
- simuliert über Warteschlangen ein Abonnentensystem
- Sender kann Nachrichten veröffentlichen
- interessierte Empfänger können diese abonnieren
… und zugehörige Skizzen sind relevant
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
A
51
Design von Informationssystemen | Integration Engineering I
MESSAGE ORIENTED MIDDLEWARE - MOM
- Request-Reply-Modell:
- Sender legt Nachricht in Warteschlange von Empfänger
- fordert parallel eine temporäre Warteschlange für Antwort an
- wurde Antwortnachricht erstellt, wird sie in temporäre Warteschlange gelegt und
vom Sender empfangen
Reply-Warteschlange
Empfänger
Sender
Design von Informationssystemen | Integration Engineering I
Request- Warteschlange
MESSAGE
ORIENTED
MIDDLEWARE - MOM
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
52
A
- Publish-Subscribe-Modell:
- 3 Rollen:
- Publisher: Veröffentlichung von Nachrichten
- Subscriber: Abonnieren von Nachrichten
- Vermittler: Koordination der Nachrichtenvermittlung
Warteschlange zu Thema a
Thema a
Subscriber
Design von Informationssystemen | Integration Engineering I
Thema b
Publisher
Subscriber
MESSAGE ORIENTED MIDDLEWARE - MOM
- Zwei Arten von
A
Warteschlange zu Thema b
Vermittler (Broker)
Nachrichtenkanälen:
Nachricht b
Nachricht b
53
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Queue: einfache Warteschlangen für n:1-Kommunikation (einer empfängt)
Sender
Queue
Empfänger
- jede Nachricht wird nur einmal ausgeliefert
- eine Nachricht wird ggf. solange gespeichert, bis ein Empfänger sie abholt
- eine Übermittlungsreihenfolge wird nicht garantiert
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
A
54
MESSAGE ORIENTED MIDDLEWARE - MOM
- Zwei Arten von Nachrichtenkanälen:
- Topic: Publish/Subscribe-Kanäle für n:m-Kommunikation (alle empfangen)
Sender 1
Empfänger 1
Topic
Sender 2
Empfänger 2
- Variante 1:
- nur die Abonnenten zum Sendezeitpunkt empfangen
- Nachrichten können ggf. gar nicht empfangen werden
- Variante 2 (durable):
- auch die später hinzukommenden Empfänger erhalten die Nachricht
- Queues und Topics sind zueinander inkompatibel
Design von Informationssystemen | Integration Engineering I
55
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
ENTERPRISE APPLICATION INTEGRATION – EAI
Vorteile
Nachteile
Standardisierte Integrationsmittel (nachrichtenbasierte
Middleware)
großer Aufwand für die Einführung
Reduktion der Schnittstellenanzahl zwischen IT-Systemen
hohe Kosten für die Einführung
Reduktion des Aufwands für den Unterhalt der ITSysteme (25% – 70%)
breite Unterstützung des Managements erforderlich
Reduktion des Entwicklungsaufwandes neuer IT-Systeme
(20% - 40%)
Unternehmensweite Verfügbarkeit von Informationen
Schnelle Reaktionsfähigkeit auf sich ändernde
Marktbedingungen
Höherer Investitionsschutz
è EAI ist als langfristige Investition zu betrachten
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Motivation für Cloud Computing und einführende Beispiele | Integration Engineering I
67
A
WAS IST CLOUD COMPUTING?
- „Cloud computing is using the Internet to access someone else‘s software
running on some else‘s hardware data center“
- Zitat vom Lewis Cunningham:
- (www.linkedin.com/in/lewiscunningham)
- Meinung vom Nicholas Carr (www.nicholascarr.com):
- vergleicht Cloud mit elektrischen Strom im Sinne der Bereitstellung von
Recheninfrastruktur
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
3
Motivation für Cloud Computing und einführende Beispiele | Integration Engineering I
WAS IST CLOUD COMPUTING?
B
- Problem 1 – Ressourcenplanung:
Unterprovisionierung:
unzureichende Leistung
Oberprovisionierung:
hohe Kosten
Motivation für Cloud Computing und einführende Beispiele | Integration Engineering I
WAS IST CLOUD COMPUTING?
B
4
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Problem 1 – Ressourcenplanung:
- Ressourcen:
- Allgemein
- Computing
- Daten
- Netzwerk
- Menschen (Soziale Netze)
- In der Wissenschaft oft entsprechend
- High Performance Computing (HPC)
- Computing
High Throughput
Computing
(HTC)| Integration Engineering I
Motivation für Cloud
und einführende
Beispiele
- High Speed Networking
- Virtuelle Organisationen (VO)
RELEVANZ DES CLOUD COMPUTING
A
6
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Entwicklungsoptionen der Unternehmens-IT mit Cloud-Diensten:
Eigene IT
Cloud-Infrastruktur
(IaaS)
Cloud-Plattform
(PaaS)
Cloud-Software
(SaaS)
Amazon Web Services
et. al.
Force.com,
Google Appe Engine
et. al.
Gliffy,
Google Apps for Business,
Zoho et al.
Daten
Daten
Daten
Daten
Anwendungslogik
Anwendungslogik
Anwendungslogik
Entwicklung, Runtime
Entwicklung, Runtime
Anwendungslogik,
Entwicklung,
Runtime,
Infrastruktur
Infrastruktur
Infrastruktur
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Entwicklung,
Runtime,
Infrastruktur
27
Motivation für Cloud Computing und einführende Beispiele | Integration Engineering I
RELEVANZ DES CLOUD COMPUTING
W
- Gründe für die Nutzung von Cloud Computing:
-
Mobile interaktive Applikationen
Parallele Stapel-Verarbeitung
Number-Crunching und Datenanalyse (BI-Verfahren für Big Data)
Unterstützung von Endgeräten bei rechenintensiven Aufgaben
- »bodenständige« Probleme à nicht in die Cloud auslagern
- Beispiele:
Motivation
für Cloud Computing und einführende Beispiele | Integration Engineering I
- Systeme, die eine extrem niedrige Latenz garantieren müssen
- elektronische Börsen
- Notabschaltung einer Maschine oder eines Kraftwerks.
FRAGESTELLUNGEN
A
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
- Technische
Aspekte:
28
- generelle Leistungsfähigkeit der Cloud, Datensicherung
- WiederhersteIlbarkeit von Daten nach Systemfehlern
- Integration von Cloud-Diensten in bestehende Anwendungen
- Wirtschaftliche Aspekte:
- Kosten beim Einstieg in die Cloud/ Einspareffekte
- Reputation des Anbieters
- für
Preismodelle
Anwendungen
Motivation
Cloud Computingder
und einführende
Beispiele | Integration Engineering I
- Lock-in-Effekte
- Schwierigkeiten beim Wechsel des Providers
FRAGESTELLUNGEN
A
- Organisatorische Aspekte:
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
-
suchen nach strukturierten Vorgehen zur Anbieterauswahl
nach Möglichkeiten zur Dokumentation von Cloud Architekturen
nach Support-Leistungen
nach Möglichkeiten zur Kommunikation mit dem Provider oder mit anderen
Cloud-Nutzern
- Rechtliche Aspekte:
- Gesetze
- rechtlichen Fragestellungen
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
31
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
B
KLASSIFIKATION VON CLOUD SERVICES
Benutzerschicht
S
S
P
I
S
S
P
Software-as-a-Service
P
I
I
Platform-as-a-Service
P
I
Infrastructure-as-a-Service
Virtualisierungsschicht
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Hardware
Wird transparent durch
den Cloud-Anbieter
Verwaltet.
KLASSIFIKATION
VON
CLOUD
SERVICES
Institut für Wirtschaftsinformatik
| Professur
Informationsmanagement
27
A
Software-as-a-Service (SaaS)
Provider bietet Software an
Betrieb der Software vollständig beim Anbieter
Anbieter verantwortlich für Wartung, Aktualisierung, Fehlerbeseitigung,
Definitionen,
Begriffe, Geschäftsmodelle
| Integration
I Soft- und Hardware
Weiterentwicklung,
Lizensierung
derEngineering
benötigten
Einsatz mandantenfähiger Programme
Erzielung nötiger Skaleneffekte
Zugriff auf Software per Webbrowser
Beispiele:
KLASSIFIKATION
VON CLOUD SERVICES
SalesForce CRM
A
Google Drive (PaaS)
Platform-as-a-Service
Zoho on Demand
Gliffy eigener Programme auf einer Plattform in der Cloud
Bereitstellung
SAPNutzer:
Business
By Design
Typische
Web-Entwickler
Infrastruktur von Plattform-Software bis Hardware vom Provider bereitgestellt und
verwaltet
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
Provider
legt Rahmenbedingungen
fest
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Freie Gestaltung der Programme durch Kunden
Zusätzliches Angebot einer Umgebung für Entwicklung der Programme
Beispiele:
KLASSIFIKATION
VON CLOUD SERVICES
Google App Engine
A
Heroku
Infrastructure-as-a-Service (IaaS)
Microsoft Azure
Force.com
Ähnlich der Vision des Utility-Computings
Cloud-Provider bietet virtuelle Hardware oder Infrastrukturdienste an
z.B. Speicherplatz, Rechenleistung oder Netzwerkbandbreite
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Typischer Nutzer: IT-Architekt
Virtuelle Infrastruktur kann in IT-Landschaft eingebaut werden
Profitieren von hoher Verfügbarkeit, automatischen Backups und transparenter
Wartung durch den Anbieter
Benutzung der Ressourcen mit größtmöglicher Flexibilität
Beispiele:
Amazon Web Services (EC2, S3, SimpleDB
)
GoGrid
RackSpace
28
29
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
ARTEN VON CLOUDS
W
Öffentliche Clouds (Public Cloud)
Jeder kann angebotene Services beziehen gegen ggf. Nutzungsgebühr
Produktpalette für Allgemeinheit verfügbar
Verwaltung durch einen auf Cloud-Services spezialisierten Anbieter
Beispiel: Amazon
Nichtöffentliche Clouds (Private Cloud)
Ausschließlich für eine einzige Organisation
Organisation verwaltet Cloud-Dienste selbst oder durch externen Dienstleister
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Zugang zu Cloud-Diensten auf Mitarbeiter beschränkt
Attraktives Modell für sehr große Organisationen
Beispiel:
Universitätsrechenzentrum
CLOUD
SERVICES
AUS NUTZERSICHT
A
Institutlohnt
für Wirtschaftsinformatik
Professur Informationsmanagement
Warum
sich die |Cloud
aus Nutzersicht?
32
Senkung der Kosten durch
Effizienzsteigerungen
Erübrigung bestimmter Ausgaben (Entfall von Personalkosten)
Effizienzsteigerungen fast automatisch
Abrechnung der Ressourcen im Wesentlichen anhand der tatsächlichen Nutzung
Pay-per-Use
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Entfall von Ausgaben für Sicherheitsreserven, brachliegende Kapazitäten oder
S
,
R
CLOUD SERVICES AUS NUTZERSICHT
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
35
Warum lohnt sich die Cloud aus Nutzersicht?
Steigerung der Flexibilität
Profitieren der Flexibilität auf IT-Ebene
Unternehmen wird an sich flexibler
Einführung von Cloud-Services in der Regel Umstellung auf Service-orientiertes
Paradigma
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
36
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
GESCHÄFTSMODELLE FÜR CLOUD SERVICES
A
Ertragsmodelle
Pay-per-Use
Bezahlung allein abhängig von tatsächlicher Nutzungsintensität
Sinnvolle Maßeinheiten
MB belegten Speicherplatzes
Anzahl verbrauchter CPU-Sekunden
AnzahlGeschäftsmodelle
verarbeiteter Datensätze
Definitionen, Begriffe,
| Integration Engineering I
Problem: Messgrößen sollten durch angebotene Funktionalitäten motiviert sein,
nicht durch technische Realisierung
Preismodelle und Dienstimplementierung
sollten
voneinander entkoppelt sein
GESCHÄFTSMODELLE
FÜR CLOUD
SERVICES
A
Ertragsmodelle
Pay-per-Unit
39
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Bezahlung einmalig pro gekauftem Produkt
Unabhängig von tatsächlicher Nutzungsintensität
Beispiele:
Apple berechnet einmalige Gebühr für Kauf eines Musiktitels und
Definitionen, Begriffe,
Geschäftsmodelle
| Integration Engineering I
unbegrenztes
abspielen
Android-Market: einmaliger Kauf einer App, Verwendung beliebig oft
GESCHÄFTSMODELLE FÜR CLOUD SERVICES
A (beides)
Ertragsmodelle
Abonnement
Nutzer zahlt periodisch eine fixe Gebühr
Unabhängig von tatsächlicher Nutzung
Beispiele:
Flatrate beim Internetanschluss
Office 365 von Microsoft
40
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Ertragsmodelle
Free
Service kostenlos
Kompensation über indirekte Erlöse (Werbung)
-F
(F
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
)
41
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
W
GESCHÄFTSMODELLE
FÜR CLOUD SERVICES
Nur zur Verdeutlichung der Idee: Kombinationen auch machbar
Kombination Ertragsmodelle
Abonnement + Pay-per-Use
Regelmäßige, fixe Grundgebühr
Abdeckung eines Services in gewissem Umfang
Zusätzliche nutzungsabhängige Gebühren
Kombination Ertragsmodelle
Pay-per-Unit + Pay-per-Use
Einmaliger Kaufpreis
Nutzungsabhängige Gebühren
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Bei zusätzlicher Soft- oder Hardware zur Nutzung eines Services
Beispiel: Amazon für Reserved Instances beim EC2-Dienst
GESCHÄFTSMODELLE FÜR CLOUD SERVICES
W
42
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Service
Modelle
Cloud-Service in eine der drei Ebenen des SPI-Frameworks eingeordnet
Kunde kann direkt auf Services aller Schichten zugreifen
Anbieter kann beliebige Kombination der Schichten nutzen
CSP kann Mehrwert schaffen, durch Mashup aus bestehenden Services
S
Beispiel: http://housingmaps.com
visualisiert Kleinanzeigen für
Immobilien aus Craigslist mithilfe von Google Maps
Mashup kann sich über mehrere Software-Services erstrecken als auch
Definitionen,
Begriffe, Geschäftsmodelle
| Integration
schichtenübergreifend
eine
SaaS Engineering
mit einerI laaS verbinden
W
ENTWICKLUNG
UND
UMSETZUNG
EINER CLOUD STRATEGIE
Institut für Wirtschaftsinformatik
| Professur
Informationsmanagement
46
Inhalt, Umfang und Motivation
Strategie = verbindliche Richtlinie für gesamtes Unternehmen mit einem mehr oder
weniger engen Handlungsspielraum
Oberste Richtlinie gibt Top-Management in Unternehmensstrategie vor
Ableitung von Teilstrategien möglich (IT-Strategie, Sourcing-S
, )
Cloud-Strategie
Cloud-Sourcing-Strategie
Welche Services unter welchen Rahmenbedingungen aus Cloud beziehen
Cloud-Providing-Strategie
Unternehmen möchte als CSP agieren (Software-Anbieter)
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
52
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
ENTWICKLUNG UND UMSETZUNG EINER CLOUD STRATEGIE
Inhalt, Umfang und Motivation
W
Cloud-Strategie
Aussagen zur Abgrenzung der Cloud-Aktivitäten eines Unternehmens
Aussagen zur Einordnung in Unternehmensstrategie
Definitionen, Begriffe, Geschäftsmodelle | Integration Engineering I
Aussagen sind quantifizierbar bzw. überprüfbar und können allgemeine
Vorgaben enthalten
ENTWICKLUNG UND UMSETZUNG EINER CLOUD STRATEGIE
B
Inhalt, Umfang und Motivation
Serviceauswahl
Anbieterauswahl
Risikoabwägung
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Monitoring &
Controllling
CSP-Management
Zeitplan
Finanzen
Interne Abkäufe
Innovation &
Wachstum
IT-Effizienzsteigerung
Entwicklung neuer
Produkte
Steigerung der
Kosteneffizienz
Technische Aspekte
| Integration Engineering I
IT-Konsolidierung
Fremdbezug
Geeigneter Services
Cloud-Orientierung
53
Erschließung neuer
Vertriebskanäle
Exemplarische Unternehmensziele
ANFORDERUNGEN
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
W
54
Ausfallsicherheit und hohe Verfügbarkeit
Schaffung von Redundanzen
Zusätzliche Hardware
Bsp.: zwei identische Systeme
Spezielle Form von Redundanz:
Replizierung von Daten an unterschiedlichen, voneinander
unabhängigen Speicherorten
Erforderlichkeit spezieller algorithmischer Maßnahmen zur Herstellung bzw.
Sicherung der Konsistenz von Daten
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
5
Technische Aspekte | Integration Engineering I
ANFORDERUNGEN
A
Transaktionale Garantien
Ausgedrückt durch ACID-Eigenschaften
Atomicity
Consistency
Isolation
Durability
Technische Aspekte
| Integration Engineering I
Transaktionskonzept speziell für Cloud-Applikationen relevant
ANFORDERUNGEN
W
Datensicherung und Schutz von Daten vor unberechtigten Zugriff
Institut für Wirtschaftsinformatik
Professur Informationsmanagement
Datendiebstahl
und | Spionage
Maßnahmen: Verschlüsselungstechniken
Datensicherung
Technische
Aspekte | Integration aufgrund
Engineering I von
Datenverlust
Maßnahmen: Vorkehrungen gegen Verlust treffen
ANFORDERUNGEN
A
Elastizität und Skalierbarkeit
Cloud-Systeme typischerweise elastisch
Unverzügliche
des Ressourcenangebots
Institut für
Wirtschaftsinformatik |Anpassung
Professur Informationsmanagement
8
Skalierbarkeit beschreibt Laufzeitverhalten eines Systems bei einer Änderung
verschiedener Input- oder Problemgrößen
Messung in Dimensionen Größe, geografische Verteilung und Verwaltung
Technische
Aspekte | Integration
Engineering
I
Spezielle
Techniken
und Maßnahmen
notwendig (z.B. NoSQL-Datenbanken
anstatt SQL-Datenbanken)
ANFORDERUNGEN
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Automatisierte Administration und Messung von Verbrauch
In Cloud Anwender ohne Sorge um Software- und Hardware-Wartung
Automatisierte Administration auch im Softwarebetrieb
Messung genutzter Ressourcen: nachvollziehbare Gestaltung für Kunden
Dashboards zur Verwaltung von Rechen-, Speicher- und anderen Cloud-Ressourcen
(Bsp.: AWS Management Console)
9
Technische Aspekte | Integration Engineering I
REPLIKATION, DATENKONSISTENZ, RECOVERY
A
Replikationen zur Steigerung der Verfügbarkeit
Replizierung der Daten von Cloud-Diensten sinnvoll
Identische Werte vorgehaltener Datenobjekte: Kohärenz bzw. kohärente Objekte
oder (strenge) Konsistenz bzw. konsistente Objekte
Verschiedene Ansätze zur Erzielung von Konsistenz:
Master-Slave-Replikation: Eines der beteiligten Systeme hat die Autorität
(Master)
Multi-Master-Replikation: Eine kleine Zahl von gleichberechtigten Master
Servern
verwaltet
die
Technische Aspekte
| Integration
Engineering
I aktuell gültigen Werte
Peer-to-Peer-Replikation: Eine große Anzahl gleichberechtigter Knoten
muss sich auf die aktuell gültigen Werte einigen
REPLIKATION,
DATENKONSISTENZ, RECOVERY
A
12
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Daten in verteilten Systemen
das CAP-Theorem
Verteilte bzw. replizierte Datenhaltung in Cloud aus Gründen der Ausfallsicherheit
und Verfügbarkeit
Isolation einzelner Knoten möglich durch physische Trennung dieser
Konsistentes Terminieren von Transaktionen wichtig
Vermeidung durch 2-Phasen-Commit-Protokoll (2PC)
Wünschenswerte Eigenschaften verteilter Systeme:
Atomic Consistency (atomare (Daten-)Konsistenz)
Availability (Verfügbarkeit)
Partition Tolerance (Toleranz in Bezug auf Netzwerkpartitionierung)
Technische Aspekte | Integration Engineering I
REPLIKATION, DATENKONSISTENZ, RECOVERY
A
Institut
Wirtschaftsinformatik
| Professur Informationsmanagement
Daten
infürverteilten
Systemen
das CAP-Theorem
17
Atomic Consistency (atomare (Daten-)Konsistenz)
alle Anfragen an ein verteiltes System werden so verarbeitet, als würde ein
einzelner Knoten diese der Reihe nach abarbeiten
Availability (Verfügbarkeit)
jede Anfrage, die von einem funktionstüchtigen Knoten empfangen wird, muss
beantwortet werden
Partition Tolerance (Toleranz in Bezug auf Netzwerkpartitionierung)
Verlorene Nachrichten beeinträchtigen ein korrektes Funktionieren des Systems
nicht
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
18
Technische Aspekte | Integration Engineering I
REPLIKATION, DATENKONSISTENZ, RECOVERY
W
Daten in verteilten Systemen
das CAP-Theorem
Kein verteiltes System mit gemeinsamer Datenbasis kann gleichzeitig mehr als
zwei der drei Eigenschaften garantieren (Eric Brewer, University of California,
Berkeley 2000)
CAP-Theorem
CA ,
CA , C
A
Bewusster Verzicht auf eine der drei Eigenschaften durch Cloud-Anbieter
CA: Erzielung von Datenkonsistenz und Verfügbarkeit über
Transaktionsprotokolle
Technische Aspekte | Integration Engineering I
ABER: Für große weltweit verteilte Systeme Netzwerkpartitionierungen
unvermeidlich
C und A kann nicht gleichzeitig erzielt werden
REPLIKATION,
DATENKONSISTENZ,
RECOVERY
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
W
Daten in verteilten Systemen
19
das CAP-Theorem
Bewusster Verzicht auf eine der drei Eigenschaften durch Cloud-Anbieter
AP: Reduzierte Konsistenz zugunsten hoher Verfügbarkeit
CP: Priorisierung von Konsistenz unter der Bedingung, dass das System
gelegentlich nicht verfügbar ist
Hochverfügbare
Abstriche in Konsistenz
Technische Aspekte
| IntegrationCloud-Datenbanksysteme:
Engineering I
Anbieter setzen auf Eventual-Consistency
ACID-Garantien in einer Database-as-a-Service (DaaS) nicht mehr gültig
BASE (Basically
Available, Soft State, Eventually
Consistent)
REPLIKATION,
DATENKONSISTENZ,
RECOVERY
Optimistic Replication
A
Konsequenzen aus dem CAP-Theorem
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
20
Verwendete Methoden um Eventual-Consistency zu garantieren:
Read-Your-Writes
Prozess schreibt Wert
Sieht eigene Änderung oder neueren Stand bei nächsten Lesen
Erhält nie ältere Version
Write follows Read
Schreibvorgang für einen Wert
Folgt auf früheren Lesevorgang des Wertes
Überschreiben desselben oder eines aktuelleren Wertes
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
22
Technische Aspekte | Integration Engineering I
SICHERUNG UND WIEDERHERSTELLUNG VON DATEN
A
Grundsätzliches
Datensicherung
Aspekte der Vorbeugung von Datenverlust
Datensicherheit/ Informationssicherheit Zustand, in dem Vertraulichkeit,
Integrität und Verfügbarkeit von Informationen gewährleistet ist
Technische Aspekte | Integration Engineering I
Datenschutz Schutz des Einzelnen vor dem Missbrauch seiner
personenbezogenen
Daten
SICHERUNG
UND WIEDERHERSTELLUNG
VON DATEN
A
Arten der Datensicherung
Für Datendienste in der Cloud gibt es vergleichbare Optionen
Vollsicherung (Full Backup) bzw. Abbildsicherung (Image Backup)
Bsp. für SaaS: Sicherung der kompletten Datenbank mit Daten aller
Mandanten durch Anbieter
23
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Inkrementelles
Technische Aspekte | Integration
Engineering IBackup
SICHERUNG
und differenzielles Backup
Aufzeichnung der Änderungen seit letzter Sicherung
Differentielles Backup: Berechnung der Unterschiede zur letzten
Vollsicherung
UND
WIEDERHERSTELLUNG VON DATEN
Inkrementelles Backup: Aufsetzen auf der aktuellen Sicherung
Arten der Datensicherung
A
30
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Für Datendienste in der Cloud gibt es vergleichbare Optionen
Umgekehrte Deltas (Reverse Deltas)
Spiegelung des aktuellen Stands der Daten im Backup
Abgleich mit neuem Stand A
(
Rekonstruierung älterer Datenstände möglich
Kontinuierliche Datensicherung (Continuous Data Protection)
Alle Veränderungen am Dateisystem werden aufgezeichnet
Entstehende Log-Dateien dienen der Wiederherstellung alter
Datenstände
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
)
33
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
A
ANBIETERAUSWAHL
Vereinbarkeit mit Qualitätsanforderungen
Formulierung konkreter Qualitätsanforderungen
Nicht-Funktional
Funktional
Verfügbarkeit
Leistungsfähigkeit/Perform
ance
Nutzungsintensität
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Sicherheit
Nutzungsgebühren
Verortung
Eingabe-/Ausgabedaten
Vor-/Nachbedingungen
Antwortverhalten
Verhalten im Fehlerfall
ANBIETERAUSWAHL
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Vereinbarkeit mit Qualitätsanforderungen
W (alle Eigenschaften)
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
26
Verfügbarkeit – Nicht-Funktional:
ANBIETERAUSWAHL
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
b
c
a
A
Z
Vereinbarkeit
mit Qualitätsanforderungen
nutzbar
war.
a
,
c
S
c
Typische Angabe: pro Jahr mit Granularität von einigen Minuten
ANBIETERAUSWAHL
Beispiel:
Leistungsfähigkeit/Performance
– Nicht-Funktional:
Ein
Jahr
=
8.760
Stunden
Vereinbarkeit mit Qualitätsanforderungen
b aZeitscheibe
e c àe5 Minuten
be
e A. 60 abe 105.120
ab ea be e
e de
e .
Service– verzeichnet
in 480 Zeitscheiben einen Ausfall so ist die
Nutzungsintensität
Nicht-Funktional:
Verfügbarkeit:
Variante 1: Spezifizierung der Zeit für Erhalt einer Anfrage an den Service bis
.
zum Absenden
,54 Bder Antwort
S
B
.
.
Relevant
für
synchrone
Service-Aufrufe
Fachliche Größen sinnvoll
SuchanfrageMwird innerhalb
beantwortet
B Bsp.:
.: Eine
T
A von max. 250ms
T
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
27
Variante
2: Angabe der Dauer der reinen Verarbeitung
Sicherheit
– Nicht-Funktional:
Sinnvoll für asynchrone Service-Aufrufe
Bsp.:
werden
min. 250
Log-Daten
pro Minute
verarbeitet.
Angaben
von Es
Rollen,
Personen
oderMB
Systemen,
die Service
benutzen
Angaben zu übertragenen Daten, welche sich auf die anzuwendenden
technischen Sicherheitsmechanismen auswirken
28
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
29
ANBIETERAUSWAHL
Vereinbarkeit mit Qualitätsanforderungen
Nutzungsgebühren – Nicht-Funktional:
Pay-per-Use-Preismodell, das auf fachliche Größen basiert
Bsp.: Gebühren pro erfolgreicher Anfrage oder nach übertragenen
Datenvolumen
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Nicht empfehlenswert: Pay-per-Use-Preismodelle, die auf den für den Anbieter
relevanten Messgrößen wie CPU-Zyklen basieren
Verortung – Nicht-Funktional:
ANBIETERAUSWAHL
F mit Qualitätsanforderungen
Vereinbarkeit
(B .:
E )
Auch: konkrete Angaben, in welchem Netzwerksegment oder auf welchem
physischen Server ein Service zu betreiben ist
Eingabe-/Ausgabedaten – Funktional:
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
30
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Protokolle im Rahmen von Cloud-Services:
HTTP(S) in Verbindung mit einer REST-Schnittstelle
ANBIETERAUSWAHL
SOAP (via HTPP)
Festlegung konkreter Eingabe- und Ausgabedaten
VereinbarkeitJemit
Qualitätsanforderungen
nach
Protokoll unterschiedliche Darstellungen
Bsp.: Einsatz einer JSON- oder eine XML-Darstellung
Vor-/Nachbedingungen – Funktional:
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Z
b .A
Service-Aufruf
zu
erfüllen
sind.
ANBIETERAUSWAHL
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
,
ac
31
Vereinbarkeit
Qualitätsanforderungen
Bsp.:mit
Forderung
einer existierenden Sitzung (Session) als Vorbedingung für
einen Service-Aufruf
Antwortverhalten
Funktional:
Bedingungen–im
Betrieb nicht so relevant wie Planung, Entwicklung und
Testen der Systeme
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Synchroner Aufruf der meisten Services
Wartezeit auf Antwort
Alternativ verschiedene asynchrone Muster:
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Fire-and-Forget Aufruf eines Dienstes ohne Interesse an einer
ANBIETERAUSWAHL
Antwort
Push-Prinzip Benachrichtigung des Auftraggebers bei Fertigstellung
Vereinbarkeitdes
mit
Qualitätsanforderungen
aufgerufenen
Services durch Service-Aufruf
Polling regelmäßige Abfrage des Bearbeitungsstandes
32
Verhalten im Fehlerfall – Funktional:
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
33
Fehlerarten:
Auf dem Übertragungsweg zum Anbieter oder zum Kunden
Laufzeitfehler
Verarbeitungsfehler
Erkennung der Fehler als solche und Behandlung dieser
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
34
ANBIETERAUSWAHL
Vereinbarkeit mit Qualitätsanforderungen
B
Formulierung konkreter Qualitätsanforderungen
Abstimmung genannter Aspekte mit den Anforderungen der
Sicherheitsverantwortlichen in Bezug auf Metriken und Standards
Einarbeitung in Service Level Targets einfache Ermöglichung der eigenen
Sicherheitsmechanismen und Erfüllung aller regulatorischen Anforderungen
Service Level Targets sind immer SMART:
Spezifisch
Messbar
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Ausführbar (erreichbar)
Relevant
Terminierbar (im Zeitbezug)
ANBIETERAUSWAHL
A
Vereinbarkeit
mit Qualitätsanforderungen
Institut für Wirtschaftsinformatik
| Professur Informationsmanagement
35
Ausgewogenes Verhältnis als Schlüssel zum Erfolg
Komplementäres Verhalten genauer SLAs und guter Beziehungen zwischen
Kunde und Provider nicht substitutiv
Wichtig ist genaue Formulierung eines SLAs mit
a
M d a
d
Vereinbarkeiten zu Veränderungs- und Konfliktlösungsprozessen
CLOUD-SPEZIFISCHE
Führt zu langfristiger Zusammenarbeit
WIRTSCHAFTLICHKEITSBETRACHTUNGEN
A
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Hauptargument: wirtschaftliche Vorteile
ABER: kein einzelner IT-Sourcing-Ansatz
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
36
Spezifische Aspekte für Cloud-Sourcing:
Zahlung nur noch für tatsächliche Nutzung (Pay-per-Use)
Realisierung von Kostenvorteilen für Cloud-Anwender
Lohnt sich Cloud-Sourcing?
Vergleich zwischen Lösung im eigenen Haus und Cloud-Computing
notwendig
Voraussetzung: Kosten für entsprechende interne Lösungen bekannt oder
ermittelbar
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
37
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
CLOUD-SPEZIFISCHE
WIRTSCHAFTLICHKEITSBETRACHTUNGEN
B
Chancen und Risiken eines IT-Fremdbezugs
Chancen
Risiken
Komplexitätsreduktion
Abhängigkeit vom ausgewählten ITOutsourcing-Anbieter
Konsolidierung
Ungewissheit über die rechtlichen
Rahmenbedingungen
Senkung der Stückkosten der IT-Produktion
Management der Outsourcing-Beziehung
Variabilisierung von Fixkosten
Instabilität der Anforderungen
Verbesserung der Zuverlässigkeit und
Innovation
Technologische Komplexität
Aufwertung
derCloud-Computings
Aufgaben von | Integration Engineering
Know-how-Verlust
Wirtschaftliche
Aspekte des
I
Mitarbeitern
Reduktion von Mitarbeitern und Erzielung
Kulturelle Konflikte zwischen Anbieter und
CLOUD-SPEZIFISCHE
von Cash-Effekten
Anwender
WIRTSCHAFTLICHKEITSBETRACHTUNGEN
A
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Chancen
und Risiken eines IT-Fremdbezugs - Fazit
38
IT-Outsourcing bietet attraktive Chancen für Einsparungen und zusätzliche Flexibilität
Outsourcing bietet Gelegenheit gewachsene Strukturen in der eigenen IT-Abteilung
neu zu konzeptionieren und zu konsolidieren
Berücksichtigung nicht unbedeutender Risiken
IT-Outsourcing ist mit Kosten verbunden
Übergangsphase Anstieg der Kosten um bis zu 10%
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
Amortisierung im zweiten bis vierten Jahr
Langfristige Kosteneinsparung um etwa 20% durch IT-Outsourcing im Vergleich
zum Ursprungszustand
ZUSAMMENFASSENDE BETRACHTUNG
im eigenen
Cloud-Sourcing
InstitutBereitstellung
für Wirtschaftsinformatik
| Professur Informationsmanagement
Klassisches IT-Outsourcing
48
Rechenzentrum
Einmalige Vorabkosten, die sich aus
notwendigen Vorbereitungen ergeben
A
Auswahl, Kauf, Lizensierung,
Installation, Customizing von
Hard-/Software
Ggf. Erweiterung RZInfrastruktur
Initiale Datenmigration
Integration mit internen
Systemen
Tests
Schulungen der Mitarbeiter
Serviceidentifikation
Anbieterauswahl
Ggf. Vorbereitung 1.
Outsourcing
Initiale Datenmigration
Anpassung interner Systeme
(Integration)
Tests
Schulungen der Mitarbeiter
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Abgrenzung ITO-Umfang
Anbieterauswahl
Ggf. Vorbereitung 1.
Outsourcing
Installation, Konfiguration,
Customizing begleiten
Initiale Datenmigration
begleiten
Tests
Schulungen der Mitarbeiter
61
Wirtschaftliche Aspekte des Cloud-Computings | Integration Engineering I
A
ZUSAMMENFASSENDE BETRACHTUNG
Abhängig
Periodische Kosten
Bereitstellung im eigenen
Rechenzentrum
Effektiv keine
Cloud-Sourcing
PPU-Gebühren
Bandbreite
Unabhängig von Nutzung
IT-Controlling
Abo-Gebühren
Wirtschaftliche
Aspekte des Cloud-Computings |Ggf.
Integration
Engineering I
Wartung Hard-/ Software
CCO-Kosten
RZ-Infrastruktur
Wartung interner
IT-Personal
Schnittstellen
Support
Ggf. Verbindungskosten
Ggf. Bandbreite
(VPN)
Rücklagen für regelmäßige
Mitarbeiter-Support
Bereitstellung
Cloud-Sourcing
Upgrades im eigenen
Rechenzentrum
ZUSAMMENFASSENDE BETRACHTUNG
Risiko
Kosten durch Ausfälle
Kosten durch Ausfälle
Informationssicherheit
in der Cloud | |Professur
Integration
Engineering
I
Institut für Wirtschaftsinformatik
Informationsmanagement
Cloud-Risiken
Klassisches IT-Outsourcing
Effektiv keine
ITO-Gebühren
Bandbreite +
Verbindungskosten (VPN)
ITO-Controlling
Support-Leistungen des ITOAnbieters
Mitarbeiter-Support
Klassisches IT-Outsourcing
Kosten durch Ausfälle
IT-Outsourcing-Risiken
62
RISIKEN IN DERVorabkosten:
CLOUD starke Ähnlichkeit zwischen Cloud-Lösung und
W
klassisches IT-Outsourcing
Cloud-spezifische Risiken
(1)
ABER: Anpassungen
und Setup-Schritt beim Cloud-Sourcing
durch Anbieter
Periodische Kosten: Unterscheidung in abhängig von
Unüberprüfbare
Datenhaltung
tatsächlicher Nutzung und unabhängig von Systemnutzung
Datenhaltung
vollständig
im Verantwortungsbereich
gewählten
Kalkulatorische
Risiken:
Kosten für Systemausfälle indes
jedem
Fall
Storage-Providers
vorhanden
Cloud-
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Mangelhafte Kontrollmöglichkeiten über Provider
Protokolle und Dokumentationen zur Datenverarbeitung in der Cloud beim
Cloud-Anbieter
63
Informationssicherheit in der Cloud | Integration Engineering I
Vervielfältigung und Verteilung von Daten
Für Kunden keine Gewissheit über geografischen Ort der Datenverarbeitung
RISIKEN IN DER CLOUD
W
Institut für Wirtschaftsinformatik | Risiken
Professur Informationsmanagement
Cloud-spezifische
(2)
7
Höheres Risiko für Verfügbarkeit von Diensten
Bedeutung der Stabilität der jeweiligen Schnittstellen (APIs)
Gesteigerte Komplexität der IT-Landschaft
Betrachtung von bekannten Risiken verteilter Systeme auf vormals
unbekannter Skala
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
8
Informationssicherheit in der Cloud | Integration Engineering I
RISIKEN IN DER CLOUD
W
Cloud-spezifische Risiken (3)
Beeinflussung bei IaaS-Nutzung
M glichkei de L hm ng on i ellen Ma chinen bei gemein am
genutzter Cloud-Computing-Service durch I/O-Last eines Nutzers
Beeinflussung bei PaaS- und SaaS-Nutzung
Zugriff von Tenants prinzipiell auf den Programmcode oder die Daten
Informationssicherheit in der Cloud | Integration Engineering I
anderer Nutzer (Beispiel Dropbox)
Blockierung notwendiger Ressourcen durch Programme anderer Tenants
TECHNISCHE SICHERHEITSMAßNAHMENN
A
Grundbegriffe
9
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Vertraulichkeit
Sch
I f
ai e
de le e de Z g iff a
i ie e
Dritte
Integrität
Sch
I f
ai e
de
e de de Z g iff d ch
unautorisierte Dritte
kryptografische Verfahren notwendig zur Verschlüsselung oder zur Erzeugung
kryptografischer Prüfsummen
Verfügbarkeit
M glichkei , a f I f
a i e i de M e
g eife , i de
sie benötigt werden
Frage der physischen Infrastruktur
Ansätze der Verschlüsselung: symmetrische und asymmetrische Verfahren
Informationssicherheit in der Cloud | Integration Engineering I
Einsatz kryptografischer Schlüssel
Mindestlänge eines Schlüssels für symmetrisches Verfahren: 128 bis 256 Bits
und für asymmetrische Verfahren 1024 bis 4096 Bits
TECHNISCHE SICHERHEITSMAßNAHMENN
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Grundbegriffe
10
Symmetrische Verfahren ver- und entschlüsseln mit demselben geheimen Schlüssel
Schlüssel muss Sender und Empfänger bekannt sein
Typische Vertreter: AES, Twofish
Asymmetrische Verfahren ver- und entschlüsseln mit jeweils verschiedenen
Schlüsseln (öffentliche und private Schlüssel)
Publizierung des öffentlichen Schlüssels durch Empfänger
Verschlüsselung der Nachricht mit öffentlichen Schlüssel durch Sender
Entschlüsselung der Nachricht mit privatem Schlüssel des Empfängers
Typische Vertreter: RSA, DSA, Software Pretty Good Privacy (PGP) bzw. GnuPG
(GPG)
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
11
Informationssicherheit in der Cloud | Integration Engineering I
TECHNISCHE SICHERHEITSMASSNAHMEN
A
Grundbegriffe
Punkt-zu-Punkt-Sicherheit
Abschnittsweise Sicherheit
Sicherheit der übertragenen Daten nur bis zur nächsten Zwischenstation
Verwendung von HTTPS/TLS
Anfällig gegen einen Man-in-the-Middle-Angriff
Ende-zu-Ende-Sicherheit
Sicherheit übermittelter Daten vom Sender bis zum Empfänger
Verschlüsselte Daten für Mittelsmänner
Mittelsmänner müssen aber Routing-Informationen kennen
Informationssicherheit
in der Cloud | Integration
Engineering
I
Nachrichten
können
fehlgeleitet
werden
Beispiel: Übermittlung einer mit S/MIME gesicherten E-Mail
TECHNISCHE SICHERHEITSMASSNAHMEN
W Institut für Wirtschaftsinformatik | Professur Informationsmanagement
13
Grundbegriffe
Netzwerkebene
Verursachung leichter Störungen von internen Prozessen durch
Aussenstehende möglich durch Angriff von Cloud-Diensten
Grössere Gefahr der Verbindung über ein WAN als der vorherigen über ein
LAN (bei interner Datenhaltung) (DNS ist relativ schlecht gesichert)
Host-Ebene VMs
Offenlegung im Rahmen eines Geheimhaltungsvertrags der Details zu den
gewählten bzw. angebotenen Virtualisierungslösungen
Informationssicherheit in der Cloud | Integration Engineering I
Bei Beteiligung eines Hypervisors an der Virtualisierung Beachtung der
Sicherheitsmechanismen, sonst Zugriff auf beliebige Daten möglich
Vertrauen durch SaaS- und PaaS-Nutzer notwendig
TECHNISCHE SICHERHEITSMASSNAHMEN
W
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Sicherheit und Schutz der Daten
14
Ansätze zur Wahrung der Datenvertraulichkeit
Grundsatzfrage: Darf dem CSP vertraut werden?
Abhängig von Arbeit mit Klartext oder Verschlüsselung
Teilaspekte der Datenvertraulichkeit:
1. Zugriffskontrolle (Access Control) für Zugriffe durch Cloud-Software
2. Schutz der Daten vor unberechtigten Zugriffen
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
17
Informationssicherheit in der Cloud | Integration Engineering I
TECHNISCHE SICHERHEITSMASSNAHMEN
W
Sicherheit und Schutz der Daten
Siche hei de e eck e Da e ei e Cl d-Anbieters
Beach g de Samml g e eck e Da e im Hi e g d d ch de Cl dAnbieter
Sammlung von Metadaten und deren Schutz
Beachtung diverser Log-Dateien oder Statistiken
Dienen der Überwachung der Systeme des Anbieters (Firewalls, Intrusion
Prevention Systems (IPS))
Weitere Risiken der Datenvertraulichkeit
Insolvenz eines Providers
Beschlagnahmung von Hardware
A
Institut für Wirtschaftsinformatik | Professur Informationsmanagement
Intrusion Dectection System vs. Intrusion Prevention System:
1. Wahrnehmung … durch Sensoren, aufzeichnet aller Pakete im Netzwerk (Logdaten)
2. Mustererkennung … Überprüfen und vergleichen mit Musterdatenbank / Angriffsmuster
3. Reaktion …. „Intrusion Alert“ (Einbruchs-Alarm) vielfältiger Natur: E-Mail, SMS, Sperrung
Intrusion Prevention System: Verhindern, blockieren von Angriffen
20