Design-Autorität, Plattformkompatibilität und. Herausforderungen an den Anbieter virtualisierter Systeme

Transkript

1 Design-Autorität, Plattformkompatibilität und Lizenzfragen Herausforderungen an den Anbieter virtualisierter Systeme, Rechtsanwalt, General Counsel, T-Systems Schweiz AG, Zürich

2 Heads-Up! Design- Autorität Plattformkompatibilität Lizenzfragen Fazit

3 Heads-Up! Outsourcing 2.0 und Industrie 4.0 IT Security Industrie Technologiefelder Robuste Netze Quelle: Bitkom.org Smart Factory Cloud Embedded Systems CPS Industrie Kernelemente Automation Cloud Internet of the Things; Internet of everything Big Data M2M Industrie 4.0 Einige Rechtsfragen Eigentum an Informationen und Daten? Datenbankschutz wann und wo? 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? 3

4 Heads-Up! Outsourcing 1.0 und Outsourcing 2.0 Vertragsthemen Outsourcing 1.0 Outsourcing 2.0 Übernahme von Personal, Assets und Verträgen Investitions- und Architekturhoheit beim Kunden Open Book (direkter) Audit, physische Step-In-Rights Dedizierte Umgebungen Exklusivität Lange Vertragsdauer, Financial Engeneering Skalierbare Lösungen, Virtualisierung, XaaS Designautorität des Providers ( Sphäre ) Pay-as-you-use, pay-as-you-order Indirekte Audits Shared Plattforms, shared Services Cloud Brokerage Services Multiprovider-Strategie, Tagespreise 4

5 Design-Autorität Heads Up! Plattformkompatibilität Lizenzfragen Fazit

6 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) 6

7 Beispiel des Einsatzes einer Cloud-Plattform DSI vcloud Service- und Liefermodell IAAS Vom Kunden zu erbringende Leistungen Kunde Clients/Endgeräte Netzwerkanbindung Hosting der applikationen Infrastruktur-software Betriebssystem ANBIETER IaaS Self-Service-Portal Virtualisierung Physikalische Server Netzwerk & Firewall Rechenzentrumsinfrastruktur Vom Anbieter zu erbringende IaaS Leistungen Ohne Management des Kundenbetriebssystems Mit Management des Kundenbetriebssystems (IaaS+)

8 Design-Autorität Interessen und Risiken der Parteien Kunden Anbieter 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 Nichterfüllung wegen Transformations- Resistenz Nicht kommerzialisierte Speziallösungen Unzufriedenheit des Kunden Roter Account Risiken bei nicht ausgewogenen Verträgen Compliance (Datenschutz) Kontrollverlust über involvierte Leistungserbringer Vendor-Lock-In Kosten für Zusatz -Leistungen Legacy-Systeme als Altlast 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) 8

9 Design-Autorität typische (&Einseitige) Vertragsbestimmungen 9

10 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 10

11 Plattform- Kompatibilität Heads Up! Design- Autorität Lizenzfragen Fazit

12 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 12

13 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 13

14 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 14

15 Lizenzfragen Heads Up! Design- Autorität Plattform- Kompatibilität Fazit

16 Lizenzfragen Einführung am Beispiel Licensing Oracle Software in the Cloud Computing Environment und Oracle Partitioning Policy ( und 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 16

17 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.) 17

18 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 18

19 Fazit Heads Up! Design- Autorität Plattform- Kompatibilität Lizenzfragen

20 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 20

21 vielen Dank für Ihre Aufmerksamkeit! T-Systems Schweiz AG General Counsel Balz-Zimmermann-Strasse Zürich-Flughafen ralph.gramigna@t-systems.com 21