Lukas’ Firma hat zu einer Informationsveranstaltung für alle Mitarbeiter eingeladen. Nach dem offiziellen Teil gibt es ein kleines kaltes Buffet. Dort kommt Lukas mit Martin und Christian ins Gespräch.

Christian: „Verschwendung von Lebenszeit, sage ich nur! Wie oft haben wir von Gernot schon gehört, was unsere Strategie und unsere Vision sind?“

Martin: „Ich habe es schon vier Mal so oder so ähnlich gehört.“

Lukas: „Aber es scheint doch offensichtlich noch Klärungsbedarf zu geben. Gernot sagte ja auch, dass die neue Strategie aus seiner Sicht bislang nur von wenigen Teams umgesetzt wird.“

Christian: „Die Leier kann ich auch nicht mehr hören! Ich weiß sowieso nicht, was diese generische Strategie mit unserer Arbeit bei MusicStore zu tun hat.“

Lukas: „Genau denselben Spruch habe ich vorhin von Gordon gehört. Offensichtlich wissen die Teams doch nicht, wie sie die Strategie sinnvoll umsetzen können.“

Christian: „... weil die auch Unfug ist. Ich habe keine Ahnung, wer sich das wieder ausgedacht hat. Und dass Gernot sagt, es gibt einige Teams, mit deren Ergebnissen er überhaupt nicht zufrieden ist, finde ich eine Frechheit. Die Kollegen schuften da Tag und Nacht, und er stellt sich hin und haut so einen Spruch raus. Er kann nur von Glück sagen, dass er so etwas nicht über MusicStore gesagt hat, sonst wäre ich jetzt direkt auf den Barrikaden.“

Lukas: „Ich finde bedenklich, dass für diese Teams jetzt das Reporting intensiviert werden soll ...“

Martin: „... und Gernot enger mit den Product Ownern der Teams zusammenarbeiten will. Das läuft doch darauf hinaus, dass die entmündigt werden.“

Christian: „Ich freue mich schon auf haufenweise Micromanagement hier bei uns! Ich sage euch eins: Wenn dieser Quatsch jetzt hier auch anfängt, suche ich mir ein anderes Unternehmen!“

Selbstorganisation erzeugt nie keine Ergebnisse ...

Die Firma von Lukas, Martin und Christian hat vor etlichen Monaten angefangen, mit selbstorganisierten Teams zu experimentieren. Vorher vorhandene Entscheidungsstrukturen wurden sukzessive von Selbstorganisation abgelöst. Man versprach sich dadurch eine wesentlich schnellere, effektivere und stärker kundenzentrierte Arbeitsweise. Einige dieser erhofften Effekte sind auch eingetreten. Gernot, der CEO der Firma, stellt nun aber fest, dass die Selbstorganisation dazu führt, dass jedes Team in eine andere Richtung rennt und die Teams sich nicht hinter der gemeinsamen Strategie versammeln.

Jurgen Appelo schreibt in seinem Buch „Management 3.0“, dass Selbstorganisation keinen Unterschied zwischen gut oder schlecht bzw. nützlich und unnütz macht [1]. Selbstorganisierte Systeme erzeugen immer Ergebnisse. Ob diese Ergebnisse nützlich oder nicht sind, liegt im Auge des externen Betrachters. Appelo beschreibt als Beispiel, wie seine Kinder schreiend durch die Wohnung rennen. Sie organisieren sich selbst, er nimmt das Ergebnis aber nicht als wertvoll wahr.

Greift der externe Betrachter (z. B. Gernot) von außen ein, um die Ergebnisse zu steuern, stört oder eliminiert er die Selbstorganisation. Die Steuerung kann nur darüber erfolgen, dass das selbstorganisierte Team einen entsprechenden Rahmen gesetzt bekommt, in dem es sich bewegen kann. Im Optimalfall kann das Team selbst bestimmen, ob seine Ergebnisse vom Kontext als wertvoll oder nicht wahrgenommen werden – ohne Gernot unentwegt zu fragen.

Bei einer Störung der Selbstorganisation verschwinden auch die positiven Effekte, derentwegen Lukas’ Firma mit diesem Experiment begonnen hat.

Die drei Gaps verhindern die Ausführung des perfekten Plans

Immer mehr Firmen stellen fest, dass ihre bisherige Arbeitsweise nicht mehr funktioniert. Diese Arbeitsweise ist in der Regel stark durch die Industrialisierung geprägt. Wenn eine Firma am Markt einen bestimmten Effekt erzielen möchte (z. B. Kunden für ein neues Produkt gewinnen), dann definiert sie einen Plan zur Umsetzung. In diesem Plan sind relativ detailliert alle Aktionen beschrieben, die nach Meinung des Planers zur Umsetzung und damit zur Erzielung des Effekts notwendig sind. Die Erfahrung zeigt, dass die heutige global vernetzte, postindustrielle Wirtschaft für dieses Vorgehen zu komplex geworden ist. Kundenteams müssen schnell und effektiv auf Veränderungen am Markt und die Wünsche der Kunden reagieren können. Aus diesem Grund sind selbstorganisierte Teams nicht nur in Lukas’ Firma eine sinnvolle Idee.

Vor rund 200 Jahren stand eine andere Berufsgruppe vor einer ähnlichen Herausforderung. Die preußische Armee hatte durch die blutige Niederlage 1806 in der Schlacht bei Jena und Auerstedt gelernt, dass sich die Gestalt des Krieges verändert hatte. Ähnlich wie unsere heutige Wirtschaft war er komplex und unplanbar geworden – im klassischen Sinne. Carl von Clausewitz beschreibt die Gründe dafür in seiner posthum veröffentlichten Schrift „Vom Kriege“. Diese Erkenntnisse wurden wiederum von Stephen Bungay in seinem Buch „The Art of Action“ [2] aufbereitet und auf die heutige Wirtschaft übertragen. Demnach gibt es drei Gaps, die das klassische Vorgehen stören (Abb. 1):

• Knowledge Gap: Um einen perfekten Plan aufzustellen, braucht es perfekte, vollständige Informationen. In einer komplexen, vernetzten Welt ist es nahezu unmöglich, zum Zeitpunkt der Entscheidung über perfekte Informationen zu verfügen.

• Alignment Gap: Selbst wenn der Ersteller des Plans – also der Feldherr, kommandierende Offizier oder CEO – über vollständige Informationen verfügt, heißt das nicht, dass sein Plan von den Soldaten bzw. Mitarbeitern perfekt umgesetzt wird. Zum einen ist nicht sichergestellt, dass sie den Plan verstanden haben, und zum anderen kann es sein, dass sie nicht in der Lage sind, ihn umzusetzen. Sowohl Christian als auch Gordon wissen ja z. B. nicht, was die Strategie konkret für ihr Team bedeutet.

• Effects Gap: Selbst wenn ein perfekter Plan perfekt umgesetzt wurde, bedeutet das in einer komplexen Welt noch nicht, dass der gewünschte Effekt eintritt. Das ist von vielen (teils zufällig erscheinenden) zusätzlichen Rahmenbedingungen abhängig.

Genau diese Gaps bzw. den Umgang mit ihnen können wir bei Gernot und den selbstorgansierten Teams beobachten. Er hat offenbar eine Strategie entwickelt und vorgestellt, die Christian als Unfug bezeichnet. Vermutlich ist diese Strategie sehr detailliert, aber auf der Basis unvollständiger Informationen entstanden. Firmen reagieren auf den Knowledge Gap in der Regel damit, dass sie versuchen, immer mehr gesicherte Informationen zusammenzutragen, bis sie den Wald vor lauter Bäumen nicht mehr sehen.

Die drei Kollegen befürchten, dass Gernots Ankündigung, enger mit den Product Ownern einiger Teams zusammenzuarbeiten, in Wahrheit dazu führen wird, dass er diesen POs detaillierter sagt, was in ihren Teams getan werden soll. Dabei handelt es sich um eine Reaktion auf den Alignment Gap [3]. Getreu dem Motto: „Wenn die Mitarbeiter nicht so handeln, wie ich es möchte, weise ich noch detaillierter an, was sie tun sollen.“ In der Regel führt dieses Verhalten zu dem von Christian befürchteten Micromanagement.

Gleichzeitig möchte Gernot auch das Reporting erhöhen, was eine klassische Reaktion auf den Effects Gap ist. In der Realität führt dieses Vorgehen aber in der Regel in eine Abwärtsspirale, da sich die Firma durch das Zusammentragen von Informationen, immer detailliertere Anweisungen und wachsende Reportings selbst lähmt.

Wie kann eine gemeinsame Ausrichtung mit selbstorganisierten Teams dann gelingen?

Auftragstaktik und Subsidiaritätsprinzip helfen beim Alignment

In der Regel wird die Strategie nicht verstanden, weil das Warum nicht klar ist: „Was wollen wir erreichen und was ist anders bzw. besser, wenn wir es erreicht haben“. Es wird viel zu viel darüber gesprochen, was die Organisation genau tun soll und wie einzelne Aktionen aussehen. Der erste Schritt ist, sich über das Warum im Klaren zu sein.

Bezogen auf das Was und das Wie ist weniger mehr. Je weiter der CEO von den Teams und der konkreten Zusammenarbeit entfernt ist, desto weniger notwendige Informationen hat er im Normalfall. Helmuth von Moltke der Ältere hat aus diesem Grund ein Konzept entwickelt, das wir heute als Auftragstaktik kennen und das ebenfalls in das Buch von Stephen Bungay eingeflossen ist. Dort heißt es konkret, dass ich so wenig anweise wie möglich (Rahmenbedingungen), aber gleichzeitig die Ziele (Warum) so klar wie möglich mache. Alle Teams im Unternehmen richten sich an diesen Zielen und Rahmenbedingungen aus, handeln aber innerhalb dieser Grenzen mit maximaler Freiheit (Subsidiaritätsprinzip [4]).

Die drei Kollegen haben im Nachgang mit Ruben, ihrem Scrum Master, gesprochen und ihn gebeten, mit den anderen Scrum Mastern genau die in diesem Artikel genannten Probleme zu besprechen. Sie hoffen, dass sie so ein sinnvolles Alignment im Unternehmen hinbekommen, das nicht in Micromanagement und Reportingwahnsinn ausartet.

Ein häufiger Trugschluss, wenn es um große Literatur geht, ist die Annahme, der Inhalt sei dabei das schlachtentscheidende Element. Nimmt man einige klassische Werke und extrahiert das Wesentliche des Stoffs, merkt man schnell, dass dieses Wesentliche nicht der alleinige Grund für die Beliebtheit, Bekanntheit und die Langzeitwirkung einer Dichtung sein kann. Beispiele gefällig?

• „Die Leiden des jungen Werthers“: Junger Mann verliebt sich unglücklich und erschießt sich schlussendlich.

• „Der Zauberberg“: Junger Mann besucht Sanatorium im Hochgebirge, bleibt sieben Jahre, geht wieder.

• „Ulysses“: Nicht mehr ganz junger Mann wandert einen Tag lang durch Dublin.

Lassen sich der berühmte Werther-Effekt, die Weltwirkung des Mann’schen Romans und die Innovationskraft der modernen Odyssee von Joyce nur durch die Stoffe erklären? Gut, es kommen noch ein paar Details hinzu, dennoch: Der wegweisende Charakter der genannten Werke resultiert weniger aus ihren inhaltlichen Versatzstücken als vielmehr aus der Form und der Erzählökonomie – nicht (nur) aus dem „Was“, sondern aus dem „Wie“.

Ähnlich verhält es sich bei dem Thema, das diesmal den Schwerpunkt des Java Magazins bildet, nämlich funktionale Softwarearchitektur. Der Artikel von Michael Sperber und Peter Thiemann (S. 24), flankiert von zwei Interviews zum Thema (mit Michael Sperber, S. 34, und Jan Hauer, S. 36), zeigt, dass eine Softwarearchitektur mit Funktionen, unveränderlichen Daten und Kombinatoren zu besseren Programmen führen kann als traditionelle, objektorientierte Architektur, und dass es dabei wie so oft nicht (nur) um das geht, „was“ sie da tut, sondern vor allem darum, „wie“ sie das tut. Und wenn ein Roman laut Autor (Joyce über „Ulysses“) Grundlage zur Rekonstruktion einer ganzen Stadt sein kann, so kann funktionale Softwarearchitektur mit Sicherheit ähnlich konstruktive Ergebnisse zeitigen!

Spaß und möglicherweise hinkende Vergleiche beiseite: Funktionale Softwarearchitektur steht ähnlich wie sogenannte Höhenkammliteratur im Ruf, sehr schwer zugänglich zu sein. Dabei führt Erstere häufig zu einer Verminderung der Komplexität und zu besseren Modellen und sollte wie Letztere etwas weniger kritisch und ehrfürchtig wahrgenommen werden – es lohnt sich!

Obendrein starten wir in dieser Ausgabe zwei neue Serien: eine zum Thema Test-driven Development (S. 70), eine zum Thema Domain-driven Design (S. 42) und haben auch sonst jede Menge zu bieten!

Bei der Lektüre wünscht Ihnen viel Freude und Erkenntnisgewinn

Fast keine App kommt ohne Daten aus. Statt diese lokal auf dem Client zu speichern oder sie auf einem schwergewichtigen SQL Server abzulegen, kommen Clouddienste zum Einsatz. Firebase ermöglicht als leistungsfähiges Backend die Speicherung von Daten mit unterschiedlichen Diensten. Meist genügen etwas Konfigurationsarbeit und die Anpassung des Referenzcodes aus Beispielen. Ein Überblick über die Datenwelt von Firebase und Co.

In dieser Artikelserie geben wir einen Überblick über die Dienste und Leistungen von Firebase als Cloud- und Back­end-Dienst von Google. Nach einem Streifzug durch alle angebotenen Services (Teil 1) und die Funktionen zur Nutzerauthentifizierung (Teil 2) geht es nun um die Kernfunktion der Datenspeicherung.

Kaum eine App kommt ohne die Speicherung von Daten aus. Für die lokale Zwischenspeicherung oder auch für Nutzungsszenarien ohne einen Austausch der Daten mit anderen Geräten und Nutzern kann eine lokale Datenbank eingesetzt werden. Die Daten werden in diesem Fall lokal auf dem Client, d. h. direkt im Speicher des Smartphones oder Tablets gespeichert. Häufig wird dazu die Datenbank SQLite eingesetzt [1]. SQLite ist eine kleinere, eigenständige und zuverlässige Datenbank. Die zugehörigen Bibliotheken werden in der Programmiersprache C geschrieben. Die Inter­aktion zwischen den Anwendungsprogrammen und der Datenbank erfolgt auf der Basis eines SQL-Dialekts. SQLite ist eine eingebettete Datenbank und wird direkt auf den Geräten, oft mobile Devices, verwendet. Das SQLite-Dateiformat ist stabil, plattformübergreifend und abwärtskompatibel. Die Entwickler der Datenbank haben sich verpflichtet, dieses Format bis mindestens 2050 beizubehalten. Der Code der Datenbank ist Public-Domain und steht zur freien Nutzung bereit. Die Nutzung von SQLite in Apps, zum Beispiel für ­Android, bietet die folgenden Vorteile:

• Es ist kein unabhängiger Datenbankserver notwendig, d. h. Client und Server (Datenbank) laufen im gleichen Prozess.

• SQLite steht zur freien Nutzung zur Verfügung. Mit der Einbindung sind keine Einschränkungen bezüglich der Lizenzbestimmungen für die eigene App verbunden.

• Da SQLite plattformübergreifend funktioniert, kann es auch für einen sehr einfachen Datenaustausch verwendet werden.

Wie man SQLite in Android (Java, Kotlin) einsetzt, wird zum Beispiel in der Android-Developer-Dokumentation unter [2] beschrieben. Über die Klassen des Packages android.database.sqlite erhält man einen Low-Level-Zugriff auf die eingebettete Datenbank und kann dann mit dieser arbeiten, d. h. Daten lesen, schreiben, löschen usw.

Möchte man die Daten jedoch zwischen Geräten und Nutzern teilen, muss man sie auf einem Server ablegen. Dazu bieten sich die Dienste von Firebase an, die wir gleich ausführlicher vorstellen. In vielen Szenarien ist es notwendig, sowohl Daten offline als auch online zu speichern und bei Verfügbarkeit einer Internetverbindung zu synchronisieren. Dazu bietet Firebase mit dem Produkt Firestore einen eigenen Modus, um die Daten für die Zeit ohne Netzwerkzugriff offline zu cachen.

Datenspeicherung mit Google

Google bietet inzwischen eine umfassende Palette an cloudbasierten Datenbankdiensten (Abb. 1) [3]. Diese Produkte umfassen eine breite Auswahl an verwalteten Datenbanken (relationale Datenbanken und NoSQL-Datenbanken). Die Angebote sind auf den Enterprise-Markt ausgerichtet und kommen für die Nutzung in mobilen Apps nur bedingt in Frage. Einen kompakten Überblick gibt Tabelle 1. Wir können diese Dienste dann von den nachfolgend im Detail vorgestellten Database Services von Firebase unterscheiden.

Den richtigen Cloudspeicherdienst auszuwählen, ist gar nicht so einfach. Damit man im Dschungel der Angebote durchblickt, gibt es eine Entscheidungshilfe in Form eines Flussdiagramms von Google (Abb. 2).

Wesentliche Trennungsmerkmale, die im Entscheidungsbaum dargestellt werden, sind die Eigenschaften „strukturierte Daten“ versus „unstrukturierte Daten“. Für unstrukturierte Daten werden bevorzugt NoSQL-Datenspeicher verwendet. Diese unterscheiden sich im Aufbau und der Nutzung von relationalen Datenbanken (Kasten „Relationale Datenbank vs. NoSQL-Datenbank“).

Ein weiteres wichtiges Kriterium ergibt sich aus der clientseitigen Verwendung des Speicherdiensts. Sofern man ihn aus einer Anwendung für die mobilen Geräte verwendet, wird er in der Regel mit Hilfe eines SDKs angesprochen. Gegenüber einer generischen Schnittstelle reduziert ein SDK die Arbeit für den Speicherdienst erheblich. Statt umfassender allgemeiner Datenbankabfragen können Standardanforderungen an die Datenbank, wie Lesen, Schreiben und Löschen, mit Hilfe von Methoden aus Klassen erledigt werden. Die Speicherdienste für den Einsatz auf mobilen Geräten werden unter den Services von Firebase von Google zusammengefasst. Wir wollen uns deshalb jetzt näher mit Firebase Realtime Database und Cloud Firestore for Firebase beschäftigen.

Datenspeicherung mit Firebase

Die Firebase Realtime Database ist eine in der Cloud gehostete Datenbank und über das Dashboard von Fire­base zu erreichen und zu administrieren. Die Daten werden als JSON gespeichert und in Echtzeit mit jedem verbundenen Client synchronisiert. Bei plattformübergreifenden Apps, die mit iOS-, Android- und JavaScript-SDKs erstellt sind, wird eine Instanz einer Echtzeitdatenbank gemeinsam von allen Clients genutzt. Auf diese Weise erhalten alle Clients automatisch die Updates auf den neuesten Stand der Daten. Der Zugriff auf die Datenbank wird direkt über clientseitigen Code ermöglicht. Die Daten werden auch lokal gespeichert, damit ist eine Offlineverarbeitung möglich. Wenn das betreffende Gerät die Verbindung wiederherstellt, synchronisiert die Echtzeitdatenbank die lokalen Datenänderungen mit den Remote-­Aktualisierungen, die stattgefunden haben, während der Client offline war. Mögliche Datenkonflikte werden automatisch aufgelöst. Mit Hilfe der Firebase Realtime Database Security Rules legt man fest, wie die Daten strukturiert werden. Bei der Integration in die Firebase-Authentifizierung können Entwickler bestimmen, wer auf welche Daten zugreifen darf. Die Implementierung läuft nach den folgenden Schritten ab:

1. Erstellen Sie die Realtime Database References

2. Stellen Sie die Daten bereit

3. Aktivieren Sie Offline Persistence

4. Sichern Sie Ihre Daten

Die Realtime Database ist die ursprüngliche Datenbank von Firebase. Es handelt sich um eine effiziente Lösung mit geringer Latenz für mobile Apps. Der Speicherdienst Cloud Firestore ist die neue Datenbank für die Entwicklung mobiler Apps. Technisch basiert sie auf einem neuen Datenmodell. Cloud Firestore bietet außerdem umfangreichere, schnellere Abfragen und skaliert besser als die Realtime Database. Sowohl Realtime Database als auch Cloud Firestore sind jeweils NoSQL-Datenbanken. Tabelle 2 stellt Realtime Database und Cloud Firestore einander gegenüber.

Für den Einsatz in der Praxis ergibt sich daher, dass man beide Datenspeicherdienste für viele Anforderungen einsetzen kann. Google empfiehlt in der Dokumentation, für neue Projekte Cloud Firestore einzusetzen. Es handelt sich um den neueren technischen Ansatz, der besser skaliert und mehr Konfigurationsoptionen bietet. Eine zwingende Migration von Projekten mit Realtime Database auf Cloud Firestore ist im Moment jedoch nicht notwendig oder gar zwingend.

Das Datenmodell von Firestore

Eine NoSQL-Datenbank sieht – wie bereits ausgeführt – keine Speicherung in Tabellen vor. Stattdessen werden Dokumente verwendet, die in Collections organisiert sind. Wie muss man sich das genau vorstellen? Jedes Dokument enthält eine Reihe von Schlüssel-Wert-Paaren. Alle Dokumente müssen in Collections aufbewahrt werden. Dokumente können Sub-Collections und verschachtelte Objekte enthalten, die beide primitive Felder wie Zeichenfolgen oder komplexe Objekte wie Listen enthalten können. Die Speichereinheit ist das Dokument. Ein Dokument ist ein Datensatz, der Felder enthält, die Werten zugeordnet sind. Jedes Dokument wird durch einen Namen identifiziert. Ein Beispiel: Das Dokument User enthält die Felder Vorname, Nachname und Geburtsdatum und hat einen Namen (Key) zur Identifikation. Komplexe, verschachtelte Objekte in einem Dokument werden als Maps bezeichnet. Dokumente haben damit eine gewisse Ähnlichkeit mit dem JSON-Datenformat.

Mehrere Dokumente werden zu Collections zusammengefasst. Beispielsweise könnte eine Collection die Auflistung der verschiedenen Benutzer enthalten, die jeweils durch ein Dokument dargestellt werden. Die Datenbank ist schemalos, d. h. es wird nicht festgelegt, welche Datentypen Sie in diesen Feldern speichern. Dokumente in derselben Collection können alle unterschiedliche Felder enthalten oder unterschiedliche Datentypen in diesen Feldern speichern. Dennoch ist es empfehlenswert, mit einer einheitlichen Abbildung der Datenrepräsentation zu arbeiten.

Der Zugriff auf die Dokumente erfolgt über einen Schlüssel. Diese Schlüssel der Dokumente in einer Collection sind eindeutig. Sie können Ihre eigenen Schlüssel, beispielsweise Benutzer-IDs, bereitstellen (und müssen dann selbst für Eindeutigkeit sorgen) oder durch Cloud Firestore automatisch zufällige IDs erstellen lassen. Letzteres geschieht, wenn Sie ein Dokument mittels der Methode add(…) einer Collection hinzufügen. Beachten Sie: Eine Collection muss man nicht anlegen oder löschen. Fügt man ein Dokument hinzu, wird eine Collection generiert. Sind alle Dokumente entfernt, existiert die Collection nicht mehr.

Mittels Referenzen kann man im Quellcode Dokumente identifizieren und mit diesen arbeiten. Ein einfaches Beispiel: DocumentReference myDocument­Ref = db.collection("users").document("klaus"); Wir bekommen einen Zugriff auf das Dokument klaus aus der Collection users. Über Sub-Collections kann man Dokumente hierarchisch organisieren. Firestore kommt mit einer Vielzahl von Datentypen zurecht. Zur Erinnerung: Da die NoSQL-Datenbank schemalos arbeitet, müssen Sie im Vorfeld keine Struktur vorgeben. Sie können Daten mit den folgenden Datentypen speichern: Arrays, Boolean, Bytes, Data and Time, Floating-Point Number, Geographical Point, Integer Map (Schlüssel-Wert-Kombinationen), Null, Referenzen (auf Dokumente und Collections) und Textstrings.

Firebase nicht nur für Android

Auch wenn Firebase und Android aus einem Hause stammen und beide Produkte sehr gut aufeinander abgestimmt sind – zum Beispiel durch eine schnelle Integration in Android Studio – ist die Verwendung keine Einbahnstraße. Ein Blick in die Dokumentation zeigt: es gibt entsprechende Software Development Kits (SDKs) für alle gängigen Systeme, d. h. Android, iOS und Java­Script. Es stehen aber auch SDKs für C++ und Unity zur Verfügung. Auch eine generische Verwendung über ein RESTful Interface ist möglich. Damit kann man die Speicherdienste von Firebase geräte- und plattformübergreifend einsetzen. Das können zum Beispiel gemischte Systemumgebungen und Anwendungen für mobile Apps sein. Dort muss man heute i. d. R. sowohl Android- als auch iOS-Devices gleichermaßen unterstützen. Auch ein Einsatz im Enterprise-Umfeld ist möglich, denn dort kommen neben mobilen Geräten oft auch Web- und Desktopclients hinzu. Hier wird man dann zum Beispiel das RESTful Interface nutzen.

Wo liegen die Daten?

Die Daten liegen der Cloud, genauer: auf den Servern von Google. Die Dokumentation sagt dazu: „Bevor Sie Cloud Firestore verwenden, müssen Sie einen Speicherort für Ihre Datenbank auswählen. Speichern Sie Ihre Daten in der Nähe der Benutzer und Dienste, die sie benötigen, um die Latenz zu verringern und die Verfügbarkeit zu erhöhen.“

Neben Multi-Region Location können Sie die Speicherung auch in Regional Locations veranlassen. Zur Auswahl stehen dann Nordamerika, Südamerika, Europa (London, Frankfurt, Zürich), Asien und Australien [6]. Der Standort beantwortet noch nicht die Frage, ob die strengeren Datenschutzbestimmungen der EU-Datenschutzgrundverordnung damit eingehalten werden. Eine umfassende Recherche führt zu folgender Aussage von Google [7]: „Firebase is GDPR-ready“. Wenn Sie als Entwickler/Betreiber einer App Firebase verwenden, ist Google in der Regel ein Datenverarbeiter und verarbeitet die personenbezogenen Daten in Ihrem Namen. Für die Firebase Dienste gelten i. d. R. die Nutzungsbedingungen der Google Cloud Platform (GCP).

Wie ist das zu werten? Die Datenspeicherung kann man lokal verorten. Für Firebase gelten die Datenschutzbestimmungen von Google. Die Plattform unterstützt es, die Bestimmungen der DSGVO umzusetzen. Das geschieht beispielsweise, indem offengelegt wird, welche Daten in welcher Form für die Verarbeitung gespeichert werden. Ebenso werden für die Firebase-Dienste die Einhaltung von ISO- und SOC-Bestimmungen nachgewiesen. In der Dokumentation finden sich beispielsweise Hinweise zur praktischen Umsetzung der so genannten Opt-in-Verfahren. Diese sorgen dafür, dass der Nutzer explizit vor der Nutzung eines Service mit Datenverarbeitung zustimmen muss. Ein Beispiel: Für die Übermittlung der Daten zur App-Analyse, wie Crash Reporting der Analytics, muss der Nutzer explizit (Opt-in) zustimmen.

Letztendlich müssen die Nutzer von Firebase, d. h. die Entwickler und Betreiber der Apps, die Prozesse der Datenverarbeitung transparent machen und dann prüfen, ob je nach Brisanz der Daten eine Speicherung in der Google Cloud zulässig ist. Im Einzelfall wird man hier rechtlichen Rat einholen müssen.

Jenseits von Firebase

Auch wenn diese Artikelserie die Services von Firebase vorstellt, gibt es natürlich Alternativen. Darauf hatten wir bereits im ersten Teil hingewiesen. Für die Aufgaben der Datenspeicherung sind die Dienste des Azure Portals von Microsoft weitgehend vergleichbar. Um den direkten Vergleich zu bekommen, möchten wir diese hier kurz als Alternative vorstellen. Der passende Service heißt bei Azure „Mobile Apps“. Darunter werden umfassende Funktionen für Apps zusammengefasst: Speicherung der Daten in der Cloud, Useridentifikation mit der Möglichkeit, Identity Provider, wie zum Beispiel Facebook, zu nutzen und der Einsatz von Push Notifications. Bleiben wir bei den Funktionen zur Datenspeicherung. Azure bietet dazu mehrere Optionen. Zum einen kann man einen SQL Server nutzen und ihn auch als Azure-Dienst in der Cloud ausführen. Mit Azure Blob Storage steht ein weiterer Dienst bereit, um unstrukturierte Daten als Objekte (Blobs) zu speichern. Im Blob Storage können alle Arten von Text- oder Binärdaten gespeichert werden, beispielsweise ein Dokument oder eine Mediendatei. Der Speicherdienst Table Storage speichert strukturierte NoSQL-Daten und bietet einen Schlüssel-/Attributspeicher mit einem schemalosen Design.

Grundsätzlich umfasst die Entwicklung zwei Bereiche: zum einen die Programmierung des Clients für die mobilen Plattformen, zum anderen die Programmierung des Backends, u. a. mit der Datenzugriffsschicht. Das Backend wird komplett über das Dashboard online im Browser konfiguriert. Table Storage bietet die Wahl zwischen .NET- und Node.js Backends. Clientseitig erfolgt der Zugriff über das Azure SDK und den individuellen Endpunkt. Auch hier gilt (wie bei Firebase von ­Goo­gle): Die Dienste von Azure geben sich erfreulicherweise sehr kommunikativ. Neben dem hauseigenen Windows (C#) werden ebenso Android mit Java, iOS mit Swift und JavaScript-basierte Applikationen unterstützt. Für alle Plattformen stehen Bibliotheken zur Einbindung zur Verfügung.

Fazit

Die Google-Cloud-Lösung Firebase ist eine Sammlung von leistungsfähigen Services für mobile Apps. Zwei Kernfeatures, Authentifizierung und Datenspeicherung haben wir ausführlicher vorgestellt. Firebase kann mit einem fairen Preismodell punkten, die meisten Dienste kann man in der kostenfreien Variante Spark Plan (Free) ausprobieren. Die Speicher- und Transfergrenzen sind in diesem Angebot ausreichend, um produktive Projekte auf dieser Basis zu realisieren. Firebase hat sich – wie die Dienste anderer Cloudanbieter auch – für die Nutzung auf anderen Plattformen und Geräten jenseits von An­droid, Java/Kotlin und Android Studio geöffnet.

Benötigen Sie für Ihr nächstes Mobile-App-Projekt ein leistungsfähiges Backend, sollte Firebase auf jeden Fall mit in die Auswahl kommen.

Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://larinet.com.