Seite 2: Anforderungen

Inhaltsverzeichnis

Lokale versus entfernte Entwicklung

Zwar installiert man die Force.com-IDE wie das klassische Eclipse lokal auf dem Entwicklungsrechner, die IDE kann jedoch nicht (wie aus dem Java-Umfeld gewohnt) lokal auf einen Compiler oder Debugger zugreifen. Vielmehr erfordert jede noch so kleine Änderung am Code ein direktes Einspielen auf die Plattform, wo dann der Compiler seine Arbeit verrichtet. Ferner verlangt eine Richtlinie von Force.com, dass der überwiegende Teil des Codes durch Unit-Tests abzudecken ist, die sich in Form von testMethods direkt in den Code einbinden lassen. Ein Deployment lässt sich nur erfolgreich abschließen, wenn der serverseitige Compiler den übermittelten Code als fehlerfrei befindet und zusätzlich auch die Ausführung aller Testmethoden erfolgreich ist. Für umfangreiche Projekte verursacht ein Deployment dementsprechend eine merkliche Wartezeit. Zudem erweist sich die Eigenheit der Testmethoden, einerseits umfangreiche Abdeckung zu verlangen und sich andererseits immer auf den gesamten Code zu beziehen, als hinderlich – insbesondere im Zusammenhang mit iterativen Anpassungen des Datenmodells.

Die Kooperation mehrerer Entwickler an demselben Projekt auf der Force.com-Plattform lässt sich derzeit nur durch strikte Trennung der Aufgabenbereiche auf unterschiedliche Dateien bewerkstelligen, da keine zuverlässige Versionsverwaltung zur Verfügung steht. Ebenso muss der Entwickler noch auf den Debugger verzichten; zur Fehlersuche stehen ausschließlich textuelle Ausgaben im "Debug-Log" zur Verfügung.

Damit mutet die entfernte Entwicklung augenblicklich sowohl vom Komfort als auch von der Geschwindigkeit her wie ein Rückschritt über mehrere Dekaden hinweg in die Kindertage der Programmierung an. Das ist allerdings erkannt, und Salesforce.com will das mit zukünftigen Versionen von Force.com Stück für Stück beheben, jüngst etwa durch Einführung einer verbesserten Systemkonsole, die eine effizientere Auswertung der Daten eines "Debug-Logs" gestattet.

Zeigt der Entwickler Bereitschaft, seine Arbeitsweise an die genannten Einschränkungen anzupassen, sind die Ergebnisse, die sich bei der Arbeit mit der Plattform erzielen lassen, recht beachtlich und erreichen dank der umfangreichen Unterstützung durch die Force.com-Funktionen schnell produktives Niveau.

Austauschbarkeit der Plattform – ein Mythos?

Bei Betrachtung des Beispiels fallen zwei Aspekte auf: Rein formal betrachtet kommt keine Technik zum Einsatz, die an eine bestimmte Plattform geknüpft wäre. Force.com wird intern durch Java gestützt, wobei die Plattform als Persistenz-Backend eine relationale Datenbank verwendet. Für die Visualisierung der Benutzeroberfläche im Browser greift sie auf eine JavaServer Faces (JSF) unterstützende Technik zurück. Der S3-Zugriff ist durch die Webservice-Schnittstellen und das Verwenden der Flash-Komponente standardisiert. Auf der Basis sollte ein Wechsel der Plattform keine Probleme bereiten.

Dennoch entsteht beim Umstellen auf eine andere Plattform ein erheblicher Aufwand. Der Grund hierfür ist die optimale Ausnutzung der Plattformeigenschaften durch den Entwickler. Im konkreten Fall baut die Implementierung auf der Benutzer- und Rechteverwaltung von Salesforce.com auf. Ersetzt man nun Force.com durch ein anderes System, ist im besten Fall die Rechteverwaltung auf die Vorgaben der anderen Plattform umzustellen, im schlimmsten Fall ist es erforderlich, diesen Projektteil in Eigenarbeit zu implementieren. Auch die Implementierung der Webseiten für die Benutzeroberfläche des Portals erfolgt in den für die Force.com proprietären Sprachen Visualforce und Apex. Die programmierte Logik lässt sich zwar unter einer anderen Plattform verwenden, der Code ist allerdings auf eine dort nutzbare Programmiersprache umzuschreiben. Ein Wechsel der Storage Plattform ginge wegen der geänderten Schnittstellen für den Zugriff ebenfalls nicht ohne Code-Anpassungen ab.

Sicherheitsanforderungen und Verfügbarkeit

Die lokale Datenhaltung – die Vorhaltung einer entsprechenden Redundanz bei Hardware und sonstiger Infrastruktur vorausgesetzt – bietet durch die Nähe zum Anwender die beste Verfügbarkeit und höchste Performanz. Ferner ermöglicht sie optimal auf den lokalen Bedarf abgestimmte Geschäftsprozesse. Zugleich verursacht die Vorhaltung der redundanten Infrastruktur eines lokalen Datenzentrums jedoch auch Kosten für qualifiziertes Personal und Material. In kleinen Unternehmen ist der Ansatz noch ohne allzu große Probleme umsetzbar. Mit wachsender Unternehmensgröße steht die lokale Datenhaltung jedoch vor der Herausforderung, für alle Mitarbeiter weltweit einen einheitlichen Datenbestand bei hoher Verfügbarkeit vorzuhalten. Eine Kostenexplosion entweder für eine schnelle hochgradig ausfallsichere Anbindung der einzelnen Standorte an das Firmennetz oder für die Synchronisierung der Datenbestände verschiedener unabhängiger Standorte sind die Folge.

Die entfernte Datenhaltung des "As a Service"-Universums versucht sich der Aufgabe anzunehmen. Die gemeinsame Nutzung der hochverfügbaren Datenzentren, die auch das technische Personal mit einbeziehen, sorgen für die Verteilung der Kosten für die Infrastruktur auf mehrere Unternehmen. Zusätzliche Vereinbarungen zur Servicequalität und -verfügbarkeit sowie zu Nutzungsrechten und -pflichten regeln zwischen den Vertragsparteien, dass die Dienste jederzeit in bester Qualität zur Verfügung stehen. Idealerweise sind alle Unternehmensstandorte weltweit gleichberechtigt beim Zugriff auf die Firmendaten, ohne dass hierfür enorme Kosten die Bilanz des Unternehmens belasteten; kleinere Einschränkungen in Funktionsumfang und Anpassbarkeit gleichen die Synergieeffekte bei der globalen Zusammenarbeit mehr als aus.

Bei genauerer Betrachtung muss der Unternehmer jedoch feststellen, dass die Daten auf ihrem Weg vom externen Datenzentrum in die jeweilige Niederlassung durch fremde Netzwerke, insbesondere das öffentlich zugängliche Internet, geleitet werden, denn ein direktes Peering der Unternehmensstandorte mit dem Dienstanbieter wäre viel zu kostspielig. Durch den Anschluss des Datenzentrums an das Internet stellt dieses selbst als Sammelstelle für Unternehmensdaten aus unterschiedlichen Quellen ein höchst attraktives Ziel für Angriffe dar. Zu nennen sind Angriffe mit dem Ziel der Datenspionage und auf Sabotage zielende DoS-Attacken (Denial of Service). Durch den Aufbau des Internet als dezentrales Netz ist auch der genaue Transportweg der Daten vom Datenzentrum zum Endanwender nicht im Voraus bestimmbar. Die Qualität der Anbindung unterliegt demnach Variationen durch äußere Einflüsse, für die keine Vertragspartei garantieren kann. Ferner ist die Frage zu beantworten, welche Verschlüsselungstechnik die Übertragung der Daten zuverlässig vor unberechtigtem Zugriff schützt.

Die Bedenken werden noch bedeutsamer, wenn man neben der reinen Datenhaltung Teile der Business-Logik als Service in die Cloud auslagert, denn hierdurch überlässt eine Firma teilweise auch Geschäftsgeheimnisse einer dritten Partei zur Ausführung der Datenverarbeitung.

Bei der Entscheidung für "As a Service"-Produkte vertraut der Auftraggeber also darauf, dass sein Auftragnehmer Sicherheitsstandards verwendet, die in der Lage sind, die überlassenen Daten effektiv abzuschirmen, einerseits vor Angriffen, die von außen kommen, und andererseits vor dem Zugriff etwa durch einen Konkurrenten, der sich bei demselben Dienstleister eingekauft hat. Ferner fordert der Kunde ein genügend großes redundantes Netz, das durch geeignete Lastverteilung in der Lage sein muss, etwaige Leistungsschwankungen auszugleichen, ohne dass der Endanwender dadurch in seiner Arbeit beeinträchtigt wird. Wie im Beispiel verdeutlicht, kann auch die Verteilung der Aufgaben auf mehrere Anbieter eine Option sein.

Wo liegen die Daten?

Bei der Suche nach passenden Anbietern kommt verständlicherweise die Frage, wo die Daten zu finden sind. Kann der Diensteanbieter die Frage zum Beispiel, ohne zu zögern, mit den Worten beantworten: "Unser Hochsicherheits-Datenzentrum liegt in der Heilmannstraße 30 in Pullach im schönen Isartal und wird dort 24/7 von unserer Abteilung für technische Unterstützung nach deutschen Qualitätsstandards betreut", dann weicht die erste Freude über den vermeintlich sicheren Standort schon bald der Frage, wie es bei nur einem Standort um die Datensicherheit im Katastrophenfall bestellt sein mag.

Im Regelfall lässt sich kein eindeutiger Ort für die Speicherung der Daten benennen, vielmehr übernimmt immer ein Verbund von Rechenzentren die Aufgabe. Bestenfalls benennt der Serviceanbieter eine Region, die alle für den Servicenutzer relevanten Daten verarbeitet. Im Beispiel etwa lagern die auf der Force.com-Plattform verarbeiteten Daten in den Vereinigten Staaten (primär in Ashburn, Virginia, und zusätzlich auf einem Failover System im kalifornischen San José, CA), die genutzten S3-Dienste hostet Amazon in der EU, genauer gesagt in Irland.

Auf diese geographischen Angaben des Serviceanbieters vertraut man als Servicenutzer ebenso wie auf die Zusagen hinsichtlich der Sicherheit und Verfügbarkeit des gesamten Rechenzentrumnetzes. Die Bindung an einen Partner in der Datenverarbeitung darf nicht nur aus einem bloßem Bauchgefühl heraus erfolgen, sondern bedarf – nicht zuletzt aus juristischen Gründen – einer genauen Prüfung im Vorfeld.

Für Unternehmen mit Standort in Deutschland ist das Bundesdatenschutzgesetz (BDSG) die Grundlage für die Erhebung, Verarbeitung und Nutzung personenbezogener Daten. Es setzt die Datenschutzrichtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24. Oktober 1995 in deutsches Recht um und wird regelmäßig an die aus dem technischen Fortschritt resultierenden neuen Anforderungen angepasst. Einerseits erhalten die Unternehmen damit verbindliche Grundlagen für die Datenverarbeitung, andererseits setzt das Gesetz aber auch enge Grenzen für den Umgang mit personenbezogenen Daten. Umfassende Informationen zum Thema bietet der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit in diversen Veröffentlichungen, etwa [3], für die Allgemeinheit zugänglich an.

Für das "As a Service"-Universum sind zwei Bereiche des Gesetzes von besonderem Belang: Erstens gibt es die Regelungen zu den technischen und organisatorischen Maßnahmen, die zum Schutz der Daten vor Missbrauch, Fehlern und Unglücksfällen zu treffen sind. Das Gesetz definiert bewusst keine konkreten Maßnahmen, sondern spezifiziert vielmehr in der Anlage zu §9 Anforderungen, die solche Maßnahmen zu erfüllen haben, nämlich dass

• Unbefugte keinen direkten Zugang zu den Datenverarbeitungsanlagen erhalten.
• sich die Systeme nicht auf andere Weise von Unbefugten nutzen lassen.
• befugte Benutzer der Datenverarbeitungsanlage nur Zugriff auf die Daten erhalten dürfen, für die sie eine Berechtigung haben.
• die Übertragung der Daten vor unbefugtem Lesen, Ändern oder Löschen zu schützen ist, was insbesondere die Kontrolle der Datenweitergabe an Dritte umfasst.
• es nachvollziehbar sein muss, wer wann Daten eingegeben, geändert oder entfernt hat.
• sich im Falle der Datenverarbeitung durch einen Dritten im Auftrag die Daten nur gemäß dem Umfang des Auftrags verarbeiten lassen.
• die Daten gegen zufällige Zerstörung oder Verlust geschützt sind.
• sich zu unterschiedlichen Zwecken erhobene Daten weder vermischen noch korrelieren lassen.

Aus diesen Punkten ergeben sich in Abhängigkeit von Art und Umfang der Daten konkrete Anforderungen an die Rechenzentren der Serviceanbieter. Auch ist das zuvor angesprochene "Wo" der Datenhaltung juristisch interessant, da in vielen Fällen die Datenzentren der Serviceanbieter im Ausland liegen. Hierbei stellt das BDSG die Frage im Vordergrund, ob im Zielland ein mit europäischen Standards vergleichbares Datenschutzniveau besteht.

Für Datenübermittlungen innerhalb der Europäischen Union und an andere Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum ist die Situation vergleichsweise einfach, da sich diese ohne weitere Detailprüfung genauso wie inländische Datenübertragungen einstufen lassen. Auch für Argentinien, Guernsey, die Isle of Man, Kanada, die Schweiz und Ungarn hat die EU-Kommission entsprechende Einstufungen vorgenommen. Jedoch war für den Datenverkehr mit den Vereinigten Staaten ein Sonderweg zu schaffen, da dort keine dem europäischen Standard nachkommende Datenschutzgesetze existieren. Daher sind Datenübertragungen – sofern überhaupt nach deutschem Recht zulässig – in die Staaten nur erlaubt, wenn sich der dortige Empfänger freiwillig den Regeln der "Safe Harbor Principles" unterworfen hat. Für andere Staaten sind keine vordefinierten Regeln verfügbar, das heißt, eine Einzelfallprüfung muss über die Zulässigkeit der Datenübertragung entscheiden. Eine Sonderregelung kann sich zum Beispiel auf die in §4c des Bundesdatenschutzgesetzes definierten Ausnahmen stützen. Der Betroffene kann etwa seine Einwilligung gegeben haben oder die Datenübermittlung kann für die Erfüllung vertraglicher Angelegenheiten zwischen dem Betroffenen und der verantwortlichen Stelle erforderlich sein. In jedem Fall ist die datenerhaltende durch die datenübertragende Stelle auf die Nutzungseinschränkungen hinzuweisen.