Dienstbar

Anfang Dezember hat das Marktforschungsunternehmen Gartner Zahlen veröffentlicht, nach denen 53 % aller Befragten in Teilen ihrer Organisation eine Service Oriented Architecture nutzen. Zwar ist SOA umstritten – viele reden von „Boom“ oder „Blase“ –, aber Gartners Zahlen verdeutlichen, dass SOA Realität geworden ist. Anlass für eine rechtliche Einschätzung – denn eine konkrete Rechtsprechung steht noch aus.

Bis heute existiert keine allgemein anerkannte Definition von SOA. Erstmals verwendete Gartner im Jahr 1996 den Begriff „Service Oriented Architecture“. Er beschreibt einen Softwareentwicklungsansatz, der auf den bekannten Vorgaben Modularität und Wiederverwendbarkeit beruht.

Grundprinzip ist eine Software-Infrastruktur, in der wesentliche Funktionen einer Anwendung als modulare Services organisiert sind. Services können beliebig verteilt sein und lassen sich dynamisch zu Geschäftsprozessen verbinden. Dazu definiert SOA Schnittstellen, über die andere Systeme via Netzwerk diese Services nutzen können. Services können unabhängig von den zugrunde liegenden technischen Plattformen Daten austauschen. Damit liegt es nahe, einzelne oder alle Services von externen Providern integrieren und betreiben zu lassen. Doch spätestens, wenn SOA die Unternehmensgrenzen überschreitet, stellen sich knifflige rechtliche Fragen.

Ein besonders sensibles Thema ist auch bei SOA der Datenschutz. Die Verwendung von personenbezogenen Daten unterliegt den Einschränkungen des Bundesdatenschutzgesetzes (BDSG). Da das Gesetz jedoch nicht nur den Umgang mit personenbezogenen, sondern auch mit bloßen personenbeziehbaren Daten regelt, können Unternehmen schnell dessen weitreichende Bedeutung unterschätzen. Darüber hinaus urteilen Gerichte derzeit nicht einheitlich zu der Frage, wann Daten noch als personenbeziehbar gelten.

Haben Unternehmen Datenschutzvorgaben zu beachten und verarbeiten Daten im Zuge einer SOA über die Unternehmensgrenzen hinweg, müssen sie eine sogenannte Auftragsdatenverarbeitung einrichten. Sie bleiben Herr über die Daten, müssen jedoch Kontrollpflichten wahrnehmen.

Häufig reicht die SOA nicht nur über Unternehmens-, sondern auch über Landesgrenzen hinweg; besonders praxisrelevant ist damit die Frage des Datenexportes in Drittländer. Als Grundregel ist ein solcher Export nur
zulässig, wenn die Betroffenen einwilligen oder das Zielland ein ausreichendes Schutzniveau aufweist.

Kein einheitliches Datenschutzniveau

Innerhalb der EU ist ein ausreichendes Schutzniveau gewährleistet, doch schon für die Schweiz oder gar die USA gilt das nicht mehr automatisch. Für den Datenexport in die USA besteht mit der „Safe Harbour“-Vereinbarung eine ganz eigene Lösung.

Auch Indien, mit zahlreichen qualifizierten und zugleich günstigen Arbeitskräften schon als „größtes Backoffice der Welt“ angesehen, bietet kein ausreichendes Schutzniveau.

Derzeit sind also für Indien, die USA und alle anderen Staaten außerhalb der EU für einen rechtmäßigen Datentransfer im Rahmen einer SOA noch spezielle Rechtsgestaltungen erforderlich, die das an sich fehlende Schutzniveau ausgleichen.

Auch ein guter Vertrag kann kaum abschließend alle Eventualitäten regeln, die in der Zusammenarbeit der Vertragspartner auftreten können. Solche Regelungslücken müssen dann in der Praxis oft durch einen Rückgriff auf gesetzliche Bestimmungen geschlossen werden.

Das klingt zunächst einmal einfach, ist aber insbesondere im Falle einer von extern eingekauften SOA schwierig. Denn das deutsche Zivilrecht kennt verschiedene Grundtypen von Verträgen, für die das Bürgerliche Gesetzbuch (BGB) jeweils allgemeine Vorgaben enthält. So sieht es für einen Mietvertrag andere Regelungen vor als für einen Kaufvertrag. Weitere in der IT-Welt wichtige und vom BGB geregelte Vertragstypen sind insbesondere der Werkvertrag und der Dienstvertrag.

Fehlt nun eine vertragliche Regelung und müssen die Beteiligten auf gesetzliche Bestimmungen zurückgreifen, stellt sich die Frage, welche Regelungen aus dem BGB eigentlich anzuwenden sind. Kurz: Sind per SOA von externen Dritten eingeholte Leistungen eine Art Mietvertrag? Oder ein Werkvertrag? Dienstvertrag?

Eindeutig liegt kein Kaufvertrag vor, auch wenn umgangssprachlich Leistungen „eingekauft“ werden. Ebenso scheidet ein Mietvertrag aus, denn der Schwerpunkt der Leistung liegt nicht im Überlassen einer Sache oder eines Programms, sondern im Zugänglichmachen von Funktionen.

Einige sehen in einer SOA einen Werkvertrag. Von diesem Vertragstyp sprechen Juristen, wenn der Provider ein fertiges Werk abzuliefern hat: Das kann ebenso ein errichtetes Haus sein wie ein reparierter Fernseher oder ein geschriebenes Programm. Bei einem Werkvertrag einigen sich beide Parteien auf einen Erfolg. Der Provider schuldet also nicht bloß den Versuch, etwa ein Programm zu schreiben, sondern den konkreten Erfolg, das gemäß Vorgaben funktionierende Programm.

Die Befürworter der Einordnung als Werkvertrag argumentieren, dass der Verarbeitungserfolg eines jeden Servicemoduls zwar von der Qualität der Eingangsdaten abhänge, aber bei Anlieferung korrekter Eingabedaten eben auch spezifikationsgemäß erreicht werden müsse, sodass letztlich ein Verarbeitungserfolg geschuldet sei und damit ein Werkvertrag vorliege. Gezahlt wird für das Arbeitsergebnis.

Die Gegner meinen, dass der Provider nur die Funktionen für die Verarbeitung schulde, aber eben keinen Erfolg der Verarbeitung von Daten – und damit liege kein Werkvertrag, sondern ein Dienstvertrag vor. Hier schuldet der Provider das verlässliche Tätigwerden, jedoch keinen Erfolg. Der Provider wird fortlaufend tätig und erhält eine fortlaufende Entlohnung. Soll das Vertragsverhältnis enden, ist eine Kündigung erforderlich. Ein Dienstvertrag ist also kaum etwas anderes als ein Arbeitsvertrag. Oder anders herum: Für von Dritten erbrachte SOA-Leistungen sollen dieselben gesetzlichen Bestimmungen wie für angestellte Entwickler gelten.

Wie so oft existiert in dem Streit keine eindeutig richtige Meinung. Eindeutig ist jedoch eines: Ein Werkvertrag ist für den Kunden rechtlich vorteilhafter, denn er kann ein messbares Arbeitsergebnis verlangen. Doch bringt das nur etwas, wenn das einzelne Arbeitsergebnis überhaupt messbar ist. Man muss zumindest für jeden Übergang zu einem anderen Provider einen Übergabepunkt und möglichst ein Arbeitsergebnis spezifizieren – das entspricht gleichzeitig wieder den spezifizierten Eingangsdaten für den Folgeservice. Auf keinen Fall sollte über mehrere Provider hinweg gemessen werden, denn der Anwender kann so nicht erkennen, welcher Provider das Problem verursacht hat.

Darüber hinaus wird es immer einzelne Services geben, für die man kein echtes Ergebnis, sondern nur eine Verarbeitungsweise spezifizieren kann. In dem Fall handelt es sich um ein dienstvertraglich gestaltetes Modul.

Um beides abbilden zu können, ist eine Vertragsgestaltung wichtig, die in einzelnen Service Level Agreements so weit möglich Übergabepunkte definiert, an denen sich der Erfolg der Leistungserbringung messen lässt.

Wenn ein Provider die Leistungen nicht ordentlich erbringt, sind Streitigkeiten zu erwarten. In einer Single-Vendor-Konstellation ist die Auseinandersetzung noch relativ einfach. Denn es gibt nur den Verantwortungsbereich des Kunden und den des Providers. Schwieriger zeigt sich die Situation beim Multi-Vendor-Environment. Verarbeiten Dienste unterschiedlicher Provider sequenziell Daten und arbeitet nur ein Dienst fehlerhaft, ist das Ergebnis der gesamten Bearbeitung korrumpiert. Obendrein werden im Falle von geschuldeten Erfolgen diese gern vermischt, bevor der Kunde sie sieht oder abnehmen kann. Verstärkt wird diese Komplexität noch, wenn die Services Querverbindungen aufweisen.

Wie sind solche Fälle rechtlich abzuwickeln? Wo ist auf der technischen Schicht der Fehler zu suchen? Handelt es sich tatsächlich um einen Fehler auf Ebene der Dienste und ist damit der Service-Provider, der den korrumpierenden Dienst anbietet, verantwortlich? Sind auch die weiteren Service-Provider verantwortlich, die den möglicherweise erkennbaren Fehler nicht abfangen? Oder hat vielmehr derjenige versagt, der für die Koordination verantwortlich ist und damit auch Fehler identifizieren und isolieren müsste?

Verantwortlichkeiten entwirren

Um solche komplexen Verantwortlichkeiten zu entwirren, stellt sich zunächst die Frage, in welchem Rechtsverhältnis die unterschiedlichen Provider zueinander stehen. Aus Kundensicht ideal wäre ein sogenanntes Gesamtschuldverhältnis. Dann würde jeder der beteiligten Diensteanbieter insgesamt für den Erfolg der Services aller Provider haften.

Der Auftraggeber könnte sich im Falle eines wo auch immer liegenden Fehlers schlicht irgendeinen Provider heraussuchen und gegen diesen vorgehen. Im zweiten Schritt müsste der so belangte Provider dann von den übrigen Providern einen Ausgleich erstreiten. In der Praxis sieht man solche Gesamtschuldverhältnisse sehr selten, denn jeder Provider müsste quasi die Verträge der anderen mitunterschreiben.

Die aus Kundensicht zweitbeste Lösung ist der Generalunternehmer. Hier übernimmt einer der Provider die Verantwortung und das Management der anderen – sie werden seine Subunternehmer. Der Generalunternehmer ist gegenüber dem Kunden für die Gesamtkette der Services verantwortlich und der Kunde kann mit ihm ein Ende-zu-Ende-SLA für die ganze Prozesskette vereinbaren.Diese Konstellation ist deutlich häufiger anzutreffen, bringt allerdings auch höhere Kosten mit sich.

Am häufigsten ist die auf den ersten Blick billigste Konstellation anzutreffen: Der Kunde hat einzelne Verträge mit jedem einzelnen Provider. Hier muss er alle Provider selbst managen. Das hat gravierende Nachteile: Wenn ein Provider in der Kette nicht liefert, haftet der Kunde gegenüber dem nachfolgenden Provider hinsichtlich der Zulieferung der Eingangsdaten.

Rechtlich gesehen heißt das, der Kunde nimmt jedes Zwischenergebnis entgegen und gibt es dem nachfolgenden Provider. Wenn das nicht klappt, kann der nachfolgende Provider nicht arbeiten. Deshalb wird es in dieser Konstellation sehr teuer, wenn der Kunde die Zwischenergebnisse und Übergabepunkte nicht messbar ausgestaltet hat – denn hier geht der Schaden durch fehlerhafte Organisation in erster Linie zu seinen Lasten.

Letztlich sind die Juristen in der Verantwortung, die Vertragsstruktur und die Dokumentation so zu gestalten, dass Unklarheiten und Streit vermieden werden. Dazu müssen sie genau Kenntnis von Vernetzung und Abfolge der Services in der eingesetzten SOA-Landschaft haben. Deshalb ist es wichtig, dass sich Architekten und Juristen frühzeitig zusammensetzen und die zur Architektur passende Struktur festlegen. Kann man einzelne Services über mehrere Provider nicht messen, zieht man beispielsweise um diese Services eine Klammer und vereinbart eine Generalunternehmerschaft eines beteiligten Providers. Nur soweit einzelne Services abgrenzbar und messbar sind, können sie getrennt vergeben werden. Auch auf technischer Ebene sollte ein Kunde Vorkehrungen gegen fehlerhafte Services treffen: Komponenten sollten wo irgend möglich standardisiert und damit einfach austauschbar und messbar gehalten werden. Die Standardisierung ist ja ohnehin ein Grundprinzip der SOA.

Georg Meyer-Spasche und Dr. Marc Störing sind Rechstanwälte bei Osborne Clarke . (gs)