ICT Outsourcing 2.0: Neue Möglichkeiten der Virtualisierung

Design-Autorität, Plattformkompatibilität und
Lizenzfragen
Herausforderungen an den Anbieter
virtualisierter Systeme
Ralph Gramigna, Rechtsanwalt, General Counsel, T-Systems Schweiz AG, Zürich
Heads-Up!
01
DesignAutorität
Plattformkompatibilität
Lizenzfragen
Fazit
02
03
04
05
Heads-Up!
Outsourcing 2.0 und Industrie 4.0
Industrie 4.0 Technologiefelder
Industrie 4.0 Kernelemente
Industrie 4.0 –
Einige Rechtsfragen
„Eigentum“ an Informationen und Daten?
Robuste
Netze
Cloud
Automation
Datenbankschutz – wann und wo?
Cloud
Embedded
Systems
CPS
IT Security
Smart Factory
Quelle: Bitkom.org
Big Data
M2M
Internet of
the Things;
Internet of
everything
Daten und Informationen: absolute und
relative Abwehrrechte?
Lizenzierung der Nutzung von Daten und
Informationen – wie?
Verantwortlichkeit für automatisierte
Erklärungen, Informationen, Handlungen?
Cloud-Plattformen und Virtualisierung: Was ist
zu beachten?
Ralph Gramigna
3
Heads-Up!
Outsourcing 1.0 und Outsourcing 2.0
Vertragsthemen
Outsourcing 1.0
Outsourcing 2.0
Übernahme von Personal, Assets und
Verträgen
Skalierbare Lösungen, Virtualisierung,
XaaS
Investitions- und Architekturhoheit beim
Kunden
Designautorität des Providers („Sphäre“)
Open Book
Pay-as-you-use, pay-as-you-order
(direkter) Audit, physische Step-In-Rights
Indirekte Audits
Dedizierte Umgebungen
Shared Plattforms, shared Services
Exklusivität
Cloud Brokerage Services
Lange Vertragsdauer, Financial
Engeneering
Multiprovider-Strategie, Tagespreise
Ralph Gramigna
4
Design-Autorität
Heads Up!
01
02
Plattformkompatibilität
Lizenzfragen
Fazit
03
04
05
Design-Autorität
Was ist Design-Autorität?
 Frage: Wer darf die
− die Tools,
− Prozesse
− Systeme (Hardware, Software)
− und anderen Ressourcen
− kurz: die Mittel,
einseitig bestimmen, mit denen die vereinbarten Services erbracht werden?
 Es geht nicht um die Änderung:
 der Services (vertragliche Lösung: Change Management )
 von Service Levels (vertragliche Lösungen: Service Level Allocation oder „Service
Level Improvement mechanism“)
 Preise (vertragliche Lösung: Benchmarking, Indexierungen)
Ralph Gramigna
6
Beispiel des Einsatzes einer Cloud-Plattform
DSI vCLoud – Service- und Liefermodell IAAS
Vom Kunden zu erbringende
Leistungen
Clients/Endgeräte
Netzwerkanbindung
Kunde
Hosting der applikationen
Infrastruktur-software
Betriebssystem
Self-Service-Portal
Virtualisierung
 ANBIETER
IaaS
Physikalische Server
Netzwerk & Firewall
Rechenzentrumsinfrastruktur
Vom Anbieter zu erbringende
IaaS Leistungen
Ohne Management des Kundenbetriebssystems
Mit Management des Kundenbetriebssystems (IaaS+)
Design-Autorität
Interessen und Risiken der Parteien
Kunden
Interessen
Innovations-Roadmap des Kunden
State-of-the-Art – Services
„as-is“ Service-Erbringung mit Continuous
Improvement der Services und Service Levels
Unterstützung der alten und neuen Technologien
Kundenseitiger Investitionsschutz und
Preissicherheit, Benchmarking
Risiken bei nicht ausgewogenen Verträgen
Compliance (Datenschutz)
Kontrollverlust über involvierte
Leistungserbringer
„Vendor-Lock-In“
Kosten für „Zusatz“-Leistungen
Legacy-Systeme als Altlast
Anbieter
Risiken bei nicht ausgewogenen Verträgen
Nichterfüllung wegen „TransformationsResistenz“
Nicht kommerzialisierte Speziallösungen
Unzufriedenheit des Kunden
„Roter“ Account
Interessen
Vereinheitlichung der Tools, Prozesse, Systeme,
Qualität
Anbieterseitige-Standardisierung über alle
Kunden (Shared Services & Shared Plattforms)
Kunde folgt Lifecycle der Drittanbieter
Freiheit bezüglich Service-Delivery-Modell (bspw.
Lokation, involvierte Leistungserbringer)
Ralph Gramigna
8
Design-Autorität
typische (&Einseitige) Vertragsbestimmungen
Ralph Gramigna
9
Design-Autorität
Rechtliche Schranken und Lösungsmöglichkeiten
Schranken
 Gegenstand des Vertrags und Vertragswortlaut („holistischer“ Ansatz)
− Ergebnis- , Tätigkeits- oder Qualitäts-orientierte Beschreibung der Services
− Änderungsverfahren (Change Management)
− Schnittstellenanforderungen (Prozesse, Tools, Technologien)
− Vertragsthemen wie Subkontraktoren, Relokationen, Innovationsmanagement,
Datenschutz
 Treu und Glauben und clausula rebus sic stantibus
Bemerkenswert
 Explizite Abgrenzung, wie weit die Design-Autorität reicht
 Vorrang der Bestimmungen zu Datenschutz, Regulatory & Compliance,
Zustimmungsvorbehalt bei Einsatz von Subunternehmen und Relokationen
der Leistungserbringungsorte (Data Centers) etc.
 Genaue Definition der Services sowie der Schnittstellen zum Kunden
 Vorbehalt der „wesentlichen“ Auswirkungen
Ralph Gramigna
10
PlattformKompatibilität
Heads Up!
DesignAutorität
01
02
03
Lizenzfragen
Fazit
04
05
PlattformKompatibilität
Hintergründe
Voraussetzungen für die Nutzung von Cloud-Plattformen
 Technologisch:
− Fakt: Unterstützte Betriebssysteme und Anwendungen sind beschränkt
− Fakt: Virtualisierung als Voraussetzung zur Nutzung der Cloud
 Regulatorisch:
− Datenschutz und andere Querschnittsthemen schränken Möglichkeiten ein.
Genaue Analyse ist erforderlich
− Branchenspezifische Gesetze, Verordnungen, Richtlinien etc. müssen dem
Anbieter nicht nur zur Kenntnis gebracht, sondern vertraglich implementiert
werden – dies bedingt umfassendes Verständnis
Typische und neue Anforderungen auf Kundenseite
 Kundenspezifische Anforderungen als „add-on“
 IT of the 2 speeds
 Bug-Kompatibilität
Ralph Gramigna
12
PlattformKompatibilität
Abgründe
Problemstellungen
 Business Cases (des Kunden und des Anbieters) gehen von falschen und ggf.
unterschiedlichen Annahmen zum Virtualisierungsgrad aus
 Nicht festgelegter, nicht voraussehbarer Release-Plan des Anbieters bedingt
nicht kalkulierbare und nicht kalkulierte Investitionen auf Kundenseite
 Kundenspezifische Anforderungen oder Anbieter-Features führen zum
Vendor-Lock-In
 „fail often, fail earlier“-Ansatz des Kunden und konservative Anforderungen
können nicht unter einen Hut gebracht werden oder führen zu einer
einseitigen Verlagerung der Risiken zu einer der Parteien
Ralph Gramigna
13
PlattformKompatibilität
Lösungen in der Balance
Gebote und Verbote
 Abschliessende und transparente Information über Annahmen zur
Virtualisierung von Applikationen, welche dem Business Case beider Parteien
zugrunde liegen. Berater in der Pflicht!
 Due Diligence durch Kunde und Anbieter mit folgender Festlegung, welche
Systeme und Anwendungen unterstützt werden
 Verankerung eines (abstrakten, aber griffigen) Release-Plans
 Qualitätsanforderungen sind und bleiben Vertragsinhalt
Ralph Gramigna
14
Lizenzfragen
Heads Up!
DesignAutorität
PlattformKompatibilität
01
02
03
Fazit
04
05
Lizenzfragen
Einführung am Beispiel
 „Licensing Oracle Software in the Cloud Computing
Environment“ und „Oracle Partitioning Policy“
(http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf und
http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf):
 “Under this cloud computing policy, Oracle Database
Standard Edition may only be licensed on Authorized
Cloud Environment instances up to 16 virtual cores.”
 “…Database Enterprise Edition licensing in an Authorized
Cloud Environment: Licensing Oracle Database
Enterprise Edition on a single instance of 8 virtual cores
(on Intel multicore chips; see the processor metric
definition on the price list), would require 8 * 0.5 = 4
processor licenses (each virtual core is considered
equivalent to a physical core).”
 “Unless explicitly stated elsewhere in this document, soft
partitioning (including features/functionality of any
technologies listed as examples above) is not permitted
as a means to determine or limit the number of software
licenses required for any given server or cluster of
servers. “
 Zulässigkeit per se oder
eingeschränkte Zulässigkeit
 Lizenzmodell
 Auswirkung der Virtualisierung
Ralph Gramigna
16
Lizenzfragen
Einige Fragen
 Exportrestriktionen
 Ist Nutzung in einer virtualisierten Umgebung überhaupt zulässig und entspricht die
virtualisierte Umgebung den Lizenzanforderungen?
 Falls ja, Untersuchung des Lizenzmodells im Hinblick auf den Einsatz:
− auslösende Sachverhalte (Core, User, Instanzen, etc. und Kombinatonen)
− Kommerzielle Pitfalls
− Vertragliche Pönalen
− Gerichtsstand:
− gemäss Vertrag
− Erfolgsort
− Handlungsort (letzterer kann im Cloud-Umfeld „überall sein“!)
− Vertrags- und Deliktsstatut (Urheberrecht, Kondiktionen, ungerechtfertigte Bereicherung etc.)
Ralph Gramigna
17
Lizenzfragen
Verantwortlichkeiten
Angrenzung in Verträgen
 Financial Responsibility Matrix
− Legt pro Asset fest, wer die Verantwortung trägt, aber…
− Vorsicht: Meist „nur“ Teil der finanziellen Bedingungen
 In Cloud-Verträgen: Negativ-Abgrenzung je nach Service-Modell
− Iaas: Provider nur bis Hypervisor, ggf. auch OS in der Pflicht
− Pbaas / DbaaS : Abgrenzung genau zu prüfen
− SaaS: Nutzung der blossen Funktionalität der Anwendung durch den Kunden
Berater in der Pflicht
 Auftragsrechtliche Haftung
 Beratung setzt vertieftes Verständnis der Technologie voraus
Ralph Gramigna
18
Fazit
Heads Up!
DesignAutorität
PlattformKompatibilität
Lizenzfragen
01
02
03
04
05
Fazit
 Zunehmende Geschwindigkeit der Entwicklung
− „Alte IT-Verträge“
− Outsourcing 1.0
− Outsourcing 2.0
− Industrie 4.0
− …Was kommt als nächstes?




hohe Anforderungen an den Berater, an den internen und externen Kunden
Fokus-Themen verändern sich
Reduktion der Fragen auf bekannte Rechtsfiguren
Forderung nach „de lege ferenda“ : da wo es Not tut
Ralph Gramigna
20
vielen Dank für Ihre Aufmerksamkeit!
T-Systems Schweiz AG
Ralph Gramigna
General Counsel
Balz-Zimmermann-Strasse 7
8058 Zürich-Flughafen
[email protected]
Ralph Gramigna
21

Download Report