Blockchain im Zusammenspiel Mit KI und Edge Computing

FUTURE TECHNOLOGIES IN ACTION @ 7P

Wie können wir den Zug der Zukunft noch praktischer und das Reisen noch angenehmer gestalten? Wie können wir die Sicherheit beim Reisen gewährleisten und dabei gleichzeitig die Richtlinien der DSGVO einhalten? Wird der Zug der Zukunft intelligent sein und Daten in Echtzeit verarbeiten können? Blockchain im Zusammenspiel mit KI und Edge Computing könnte eine Antwort auf diese Fragen sein. Als beratende Experten für innovative IT-Lösungen für die Digitalisierung beschäftigen wir uns bei SEVEN PRINCIPLES mit genau diesen und ähnlich komplexen Fragestellungen und Themen. Unser Use Case führt einen Schritt näher zum Bahnbetrieb der Zukunft. Doch wie sollen all diese neuen Technologien im Zusammenspiel einwandfrei funktionieren? Und welche Rolle spielt dabei die Blockchain?

DIE KOMPONENTEN

Blockchain sichert Nachvollziehbarkeit

In der Blockchain können wichtige Daten kryptografisch geschützt, fälschungssicher protokolliert und redundant gespeichert werden. Sicherheitsrelevante Informationen werden auditierbar vorgehalten und vor Manipulation geschützt. Prozessdaten sind über die verteilte Blockchain schnell an allen relevanten Stellen verfügbar, auch über Unternehmensgrenzen hinweg.

Künstliche Intelligenz (KI) erhöht Sicherheit

Daten sind über Sensoren und Datenspeicher der verschiedensten Prozesse meistens in ausreichendem Maß, häufig sogar im Übermaß vorhanden. KI hilft nicht nur bei der Auswertung und Nutzengewinnung. Sie verschafft häufig erst die Sicherheit in der Bewertung und das Vertrauen in die abgeleiteten Ergebnisse und Regeln, die für eine erfolgreiche Anwendung benötigt werden. Und mit den richtigen Daten lässt sich die Technik so verfeinern, dass eine KI in der Lage ist, gefährliche Situationen eigenständig zu identifizieren und zu melden.

Edge Computing vereinfacht Datenschutz

Edge Computing bringt die erforderliche Rechenleistung zu den Daten, datenschutzrelevante Vorgänge wie Übertragung oder Speicherung können so minimiert oder ganz vermieden werden. Weitergegeben werden nur noch aufbereitete Ergebnisse oder (Warn-) Signale – auf die Informationsverarbeitung bezogen ist das Datenschutz by Design.

Architektur des SEVEN PRINCIPLES Showcase Network, Blockchain im Zusammenspiel mit KI und Edge Computing
Architektur des SEVEN PRINCIPLES Showcase Network, Blockchain im Zusammenspiel mit KI und Edge Computing

ANGENEHMES UND SICHERES REISEN

Sitzplätze per App identifizieren

Bereits heute erfassen Kameras das Geschehen in Zügen und spielen somit eine entscheidende Rolle, wenn es um sicherheitsrelevante Themen geht. Der SEVEN PRINCIPLES Use Case zeigt, dass die Kombination aus Edge Computing, Kameras und KI (Computer Vision, Tensorflow) eine Objekterkennung von Personen oder Gegenständen ermöglicht. In Kombination mit Umgebungssensoren lässt sich die Technik so verfeinern, dass die KI in der Lage ist, gefährliche Situationen eigenständig zu identifizieren und zu melden. Solche Situationen können einem Zugbegleiter angezeigt und bei wirklicher Gefahr zusammen mit den Metadaten auf einer Blockchain fälschungssicher persistiert werden. Natürlich sollte der Zug der Zukunft – die Sicherheit vorausgesetzt – auch praktisch und angenehm für die Reisenden sein.

Wäre es nicht schön, wenn die aktuelle Anzahl der freien (und belegten) Sitztplätze ermittelt und grafisch angezeigt würde? Die Verarbeitung dieser Daten wäre in Echtzeit möglich, und für die Validierung der Ergebnisse könnten Funk und WLAN herangezogen werden. Für ein optimiertes Ergebnis würden zusätzlich Sitzplatzreservierungen und Belegungsprognosen einbezogen werden. Reisende könnten sich freie Plätze anzeigen lassen und diese reservieren, sowohl am Bahnsteig, als auch im Zug selbst, und das ganz einfach über eine Anzeige bzw. über eine App.

Reisen ohne Stress dank Blockchain

Wir geben Ihnen ein Beispiel: Stellen Sie sich vor, Sie stehen am Bahnsteig. Es ist Feierabendverkehr und Sie wissen, dass der Zug sehr ausgelastet sein wird. Plötzlich weist Ihr Handy Sie darauf hin, dass der ICE Sprinter von Frankfurt nach Köln einfährt und die Wagons 3 bis 5 bereits belegt sind, sich jedoch ausreichend Plätze in den Wagons 6 bis 9 befinden. Es wäre nun ein Leichtes für Sie, sich am Bahnsteig richtig zu positionieren und sofort ohne große Umwege einen freien Sitzplatz zu finden. Sollte der Zug vollkommen überfüllt sein, bestände darüberhinaus die Möglichkeit, Ihnen alternative Züge oder sogar Verkehrsmittel
vorzuschlagen. – Reisen ohne Stress.

Angenehme Temperaturen

Zum angenehmen Reisen gehört nicht nur ein gemütlicher Sitzplatz, auch die Temperatur, der Luftdruck und die Luftfeuchtigkeit sollten stimmen, um besonders lange Fahrten – auch in Rekordsommern – angenehm und komfortabel zu gestalten. Umgebungssensoren in den Wagons könnten den Zugbegleiter informieren, sobald ein festgelegter Wert über- oder unterschritten wird, damit er entsprechende Maßnahmen einleiten kann.

Der Usecase verdeutlicht, dass die Verbindung der Komponenten Blockchain, KI und Edge Compting die Bahn-IT revolutionieren und das System Bahn im Hinblick auf die Digitalisierung deutlich voran bringen könnte.

DIE TECHNIK HINTER DER IT LÖSUNG

Klingen die beschriebenen Szenarien genau so verlockend für Sie wie für uns? Die SEVEN PRINCIPLES Blockchain-, KI- und Edge Computing-Experten haben die nötige Grundlage für diese kosteneffiziente und effektive IoT-Lösung entwickelt. Für den Datenaustausch zwischen den Zügen, den Eisenbahnverkehrsunternehmen und dem Benutzer wird im Showcase eine Blockchain-/Distributed Ledger-Lösung auf Basis des Hashgraph-/ Babble-Konsensalgorithmus angebunden. Somit wäre neben der Übertragung in Echtzeit, der erhöhten Sicherheit und der Einhaltung der DSGVO eine höhere Toleranz gegen Netzwerk- bzw. Kommunikationsabbrüche bei gleichzeitiger Auditierbarkeit möglich. Aufgrund dieser Eigenschaften bietet sich diese Lösung auch als Basis für andere Zug-ITSysteme an, z.B. zur Ticket-Kontrolle. Besonders sicherheitskritische Informationen wie Bauteil- Wartungszyklen könnten transparent kommuniziert und dauerhaft fälschungssicher abgespeichert werden. Und das dank Blockchain.

FAZIT

Die Verbindung von Blockchain, KI und Edge Computing würde den Bahnbetrieb, wie wir ihn heute kennen, revolutionieren. Das Reisen würde sicherer und komfortabler, Züge würden intelligenter werden und Informationsverarbeitung fände in Echtzeit statt. Der Datenschutz der Passagiere wäre zu jedem Zeitpunkt des Prozesses sichergestellt. Wie stellen Sie sich den Zug der Zukunft vor? Würden Sie sich so einen Zug wünschen? Wir freuen uns über Ihre Meinung in unserem Kommentarfeld.

Oder nehmen Sie direkt Kontakt zu unserem Blockchain-, KI- und Edge-Computing-Expertenteam auf:
https://www.7p-group.com/kontakt-3/

Entwickler & Designer – Tipps für interdisziplinäre Zusammenarbeit

Innerhalb Softwareentwicklungsteams ist die Beziehung zwischen der Entwicklung und dem Design eine ganz besondere. Beide können nicht ohne einander funktionieren – die erfolgreiche Arbeit des anderen ist für ihr eigenes Werk essentiell. Arbeiten (UX/UI-)Designer und Programmierer eng zusammen, kann es so natürlich auch schnell zu Reibungen kommen, und das kann das gemeinsame Projekt gefährden. Das Zauberwort, um diese Probleme zu lösen, lautet interdisziplinäre Zusammenarbeit. Doch fangen wir erst mal von vorne an:

 

Ein Beispiel aus einem interdisziplinären Projekt, bedingt durch mangelnde Absprache:

Designer A ist stolz auf seinen kreativen Output und beharrt auf seinen gestalterischen Vorgaben, die er auch so im fertigen Produkt wiederfinden möchte. Entwickler B sieht in diesen Vorgaben allerdings zuerst einmal die mangelnde Umsetzbarkeit. Diese Beschränkungen wiederum waren Designer A nicht bekannt, und er meint, dass Entwickler B ihn davon hätte in Kenntnis setzen müssen. Entwickler B hingegen hält diese für selbstverständlich.

Wer im Endeffekt Recht hat, ist für das Projekt völlig irrelevant. Sicher ist nur, dass es einen Schaden davonträgt.

 

Diskrepanzen dieser Art kommen zwischen Developern und Designern leider recht häufig vor.

Aus diesem Grund widmet sich dieser Artikel einer Annäherung der zwei Disziplinen, um diese unwahrscheinlich wichtige Beziehung ein Stück weit zu verbessern.

 

Interdisziplinäre Kollaboration bei SEVEN PRINCIPLES

SEVEN PRINCIPLES arbeitet agil. Ein Kerngedanke dieses Arbeitsmodells: die interdisziplinäre Zusammenarbeit.

Bei 7P arbeiten wir mit vielen Kollegen aus unterschiedlichen Fachbereichen zusammen, die auch jederzeit bereit sind, mit ihrer Expertise einem anderen Kollegen zu helfen – sei es durch aktive Mitarbeit oder einfach durch einen Rat bei einem besonders schwerwiegenden Problem.

 

Bei der Softwareentwicklung kann das zum Beispiel so aussehen: Der Designer hat eine konzeptionelle Idee im Kopf und würde sie gerne testen. So sucht er sich zwei Entwickler innerhalb seines Projektteams und setzt sich mit ihnen ein paar Stunden zusammen, um einen benutzbaren Prototypen für seine Idee zu bauen. Wenn dieser dann die erhofften Ergebnisse bringt, ist das großartig. Wenn nicht, ist man zumindest um die Erkenntnis reicher, wie es nicht geht.

Eine gute Möglichkeit zum interdisziplinären Austausch können auch regelmäßige, offene Fachgruppenmeetings sein. Man kann hier sein Problem einigen Kollegen vorstellen, die mit einem ganz anderen Auge draufschauen und möglicherweise Lösungsansätze finden, auf die man selbst gar nicht kommen würde.

 

Ein echtes Fachgruppenmeeting sieht natürlich weniger nach einem Stockfoto aus, doch kommt der interdisziplinäre Zusammenarbeit sehr nahe.

 

Rollenverteilung im agilen Kontext

Die interdisziplinäre Zusammenarbeit ist bei uns essentieller Bestandteil aller Projekte. Kommunikation, Kollaboration und Ideenaustausch sind allerdings auch immer eine Herausforderung, wenn unterschiedliche Disziplinen aufeinandertreffen.

 

Wie sehen die möglichen Probleme nun aus? Und vor allem: Wie kann man sie vermeiden?

 

Wollen Designer und Entwickler erfolgreich zusammenarbeiten, müssen sie sich entgegenkommen. Jedem Mitarbeiter muss daran gelegen sein, die Arbeit seines Kollegen so leicht wie möglich zu machen und nicht zu behindern. Eben so, wie man es sich andersherum auch wünschen würde.

Dabei ist die althergebrachte Aufteilung aus dem Wasserfallmodell „erstens Design, zweitens Entwicklung“ bei einer agilen, adaptiven Arbeitsweise nicht mehr sinnvoll. Zwar bedarf es häufig einiger früher Designentscheidungen, um die Entwicklung voranzutreiben, der Designer sollte zur Optimierung seiner Arbeit aber weiterhin ins fortlaufende Projekt involviert sein.

 

Ein möglicher Lösungsweg: Vor der Umsetzung startet der Designer mit der Erstellung einer generellen „Experience“ (Flowchart, Navigationsstruktur, etc.). Die detaillierte, pixelgenaue Designarbeit wird daraufhin immer einen Sprint vor der Implementierung durch den Entwickler erstellt. Es wird also immer das designt, was im nächsten Sprint entwickelt werden soll. So ist zum einen eine Struktur und zum anderen die langfristige Verfügbarkeit des Designers für das Projekt gewährleistet, falls nachträglich Änderungen vollzogen werden müssen.

 

Wie auch immer man bei der Zusammenarbeit nun vorgeht: Bei alldem ist jederzeit ein gemeinsamer Informationsstand zu gewährleisten. Wenn alle Teammitglieder auf dem gleichen Wissensstand sind, können sie am besten voneinander profitieren.

 

Spielregeln für eine erfolgreiche interdisziplinäre Zusammenarbeit

Einer der ersten Fehler, die man in einem interdisziplinären Team machen kann, ist nicht früh genug zu kommunizieren.

Wer eng im Team zusammenarbeitet, muss einen gemeinsamen Weg finden. Deshalb sollte zu Beginn jedes Projekts eine Erwartungshaltung definiert werden. Strukturen und Prozesse sollten zudem aufeinander abgestimmt werden. Will man zum Beispiel inkrementell arbeiten oder fühlt man sich mit etwas mehr Vorarbeit wohler?

Des Weiteren sollte Klarheit über die Vorgehensweise beider Seiten herrschen und ein gemeinsamer Standard festgelegt werden.

  • Für welche Screengrößen braucht der Entwickler Designs?
  • Weiß der Designer, wie zum Beispiel Layout Constraints funktionieren?
  • Wurde über das Wording gesprochen?
  • Wie sieht es mit Margins, Paddings, Grids aus?
  • Wie sollen dynamische UI-Elemente agieren?
  • Wurde der Userflow von beiden Seiten durchdacht?

Wenn diese Dinge vorher geklärt wurden, spart man sich nachher viel Zeit und Mühe.

 

Einen großen Schritt in Richtung beiderseitigem Entgegenkommen kann der Designer mit einem einfachen Grundsatz machen: Genauigkeit. Bezüglich der User Experience heißt das beispielsweise, dass der Userflow lückenlos und ohne Sackgassen funktionieren sollte, um den Entwickler nicht mit offenen Fragen zurückzulassen. Beim User Interface Design ist damit die Pixelgenauigkeit gemeint, die Fehlinterpretationen bei der Implementierung so weit wie möglich einschränkt.

Regelmäßige „Pair Programming“-Sessions zwischen Programmierer und Designer können dabei letzte Zweifel beseitigen: Der Entwicklungsfortschritt wird regelmäßig gemeinsam begutachtet und eventuelle Designabweichungen werden direkt korrigiert. Dabei lernt man voneinander, und der Programmierer entwickelt so selbst ein Verständnis für Visualität und Gestaltung, während der Designer mit den Herausforderungen der Umsetzung konfrontiert wird.

 

Interdisziplinäre Zusammenarbeit - Pair Programmer

Zwei erfahrene Pair Programmer.

 

Umgang mit Kritik

Ein essentieller Bestandteil für gute interdisziplinäre und agile Zusammenarbeit ist erfahrungsgemäß eine funktionierende Feedbackkultur. Gerade beim Thema Design kann sowohl eine falsche Abgabe als auch Annahme von Kritik zu erheblichen Irritationen führen.

So sollte man sich immer bewusst sein, dass Design von Nicht-Designern immer leicht zu kritisieren ist, weil es greifbarer als z.B. Code ist. Zu einem Interface kann grundsätzlich jeder sagen, ob es ihn anspricht oder nicht. Designkritik (so wie das Design selbst) ist in den meisten Fällen subjektiv. Als Designer muss man lernen, andere Meinungen zu akzeptieren und daraus keinen Frust entstehen zu lassen.

Als Entwickler hingegen sollte man versuchen, in seiner Ansprache sachlich und respektvoll aufzutreten und seine Meinung auch immer zu begründen. Aussagen wie „Ich mag die Farbe von dem Element nicht, keine Ahnung wieso“ bieten dem Designer keine konkreten Anhaltspunkte, um etwas zu verbessern.

Bei besonders hartnäckigen Debatten kann es außerdem helfen, die Teamkollegen hinzuziehen. Oftmals ist hier ein Kompromiss die sinnvollste Lösung.

 

Was kann man noch tun?

Einen grundsätzlichen Gedanken kann man bei allen aufgelisteten Punkten wiederfinden: Designer und Entwickler müssen versuchen, sich in ihr Gegenüber hineinzuversetzen.

 

Zum Abschluss noch ein Tipp dazu: Generell kann jeder Designer in hohem Maße davon profitieren, wenn er (mit Hilfe eines Developers) einfach mal selber etwas programmiert, zum Beispiel eine Mobile App in Android Studio oder Xcode. Erst beim Selbermachen wird die Arbeitsweise von Entwicklern so richtig verstanden. Genauso kann der Entwickler einiges lernen, wenn er dem Designer beim Bauen eines Interfaces mit dem Grafiktool seiner Wahl über die Schulter schaut oder – noch viel besser – es selbst einmal versucht.

 

Die Möglichkeiten sind da, um Kenntnisse aus der anderen Disziplin zu erlangen. Also nutzen wir sie doch einfach auch!

Interdisziplinäre Zusammenarbeit - Am besten versetzt man sich in den Kollegen hinein

 

Kontakt

Wie sind Ihre Erfahrungen zu diesem Thema? Wir freuen uns über Ihre Kommentare.

Weitere Information zu unserem AMR Team finden Sie hier auf unserer Seite:
https://www.7p-group.com/leistungen/application-development-management/

Oder nehmen Sie direkt Kontakt zu unserem Team auf:
https://www.7p-group.com/kontakt-3/

 

Aus einer Codebasis werden für iOS und Android Apps erstellt

Cross Platform App-Entwicklung – Spektrum und kritische Auseinandersetzung

Wenn sich ein Unternehmen entscheidet eine neue App zu entwickeln, wird in erster Linie an die native Entwicklung in Objective C oder Swift für Apple-Geräte und Java oder Kotlin für Android-Geräte gedacht. Eine Alternative ist die Cross Platform Entwicklung, welche sich für besondere UseCases gut eignet.

Zum Beispiel möchte ein Startup-Unternehmen mit einem MVP schnell und kostengünstig an den Markt, um das Potenzial der neuen Idee praktisch auszuprobieren und ggf. Investoren finden. Um den „Time-to-Market“ klein zu halten könnten Cross Platform Frameworks verwendet werden.

Im Folgenden werden verschiedene Cross Platform Frameworks für iOS und Android miteinander verglichen und die Vor- und Nachteile beschrieben. Die Liste ist nicht vollständig, da es sehr viele verschiedene Anbieter in diesem Bereich gibt. Die gängigsten und populärsten Anbieter sind nach Ansicht des Autors enthalten.

Unterschied native Entwicklung gegenüber Cross Platform / Hybrid

Apps, welche nativ entwickelt werden, werden in Swift / Objective C und in Java / Kotlin entwickelt. Pro Betriebssystem muss die ganze Businesslogik, UI und Datenhaltung in separatem Code erstellt und gepflegt werden. Dieses erfordert oftmals verschiedene Entwickler mit dem jeweiligen Fokus auf ihren Plattformen, wenn eine App für die zwei wichtigsten Betriebssysteme veröffentlich werden soll.

Bei der Cross Platform Entwicklung soll eine Codebasis für verschiedene Betriebssysteme/Plattformen diesen Umstand ändern.

Die Cross Platform Entwicklung wird im Folgenden nochmals unterteilt.

  • Webseite in einer Webview (Hybrid) mittels Webtechnologien
  • Frameworks welche native UI-Elemente verwenden
  • Frameworks welche eigenen Renderer verwenden

Besonderheiten für alle Frameworks

  • Um auf native Schnittstellen der Betriebssysteme zuzugreifen, beispielsweise Bluetooth, NFC und Push-Nachrichten, benötigen alle Frameworks eine Verbindung zum Betriebssystem.
    Diese Brücken können über Dritt-Entwickler-Plugins eingebunden oder selbst erstellt werden.
  • Wenn betriebssystemspezifische UI-Designprinzipien pro Plattform verwendet werden, wird immer zusätzliche Komplexität ins Projekt gebracht, da unterschieden werden muss, auf welcher Plattform die App sich gerade befindet.
  • Wenn eine UI für beide Betriebssysteme angewendet wird, sollte ein betriebssystemunabhängiges Design gewählt werden, da sich Benutzer ungerne Designprinzipien anderer Plattformen aufzwängen lassen.

Hybride Apps

Native Apps konnten direkt ab ca. 2010 Internetseiten mittels eines internen Browsers Webseiten darstellen.

Diese Funktion wurde direkt benutzt um Apps mit Hilfe von HTML, CSS und Javascript zu erstellen. Im Folgenden werden die meist verwendeten Frameworks benannt um einen Container für diese Webseiten zur Verfügung zu stellen.

Cordova

Das Open-Source-Framework Cordova von Apache hilft bei der Erstellung von hybriden Apps. Es stellt einen Container zur Verfügung, welche Verbindungen zum Host-Betriebssystem erlaubt und auch die Möglichkeiten Splash-Screens und Icons für die Apps zu definieren.

Die Verknüpfung zwischen Webview und Betriebssystem ist nötig, da sonst nicht auf native Funktionalitäten zugegriffen werden kann.

Phonegap

Bei Phonegap handelt es sich um Cordova mit zusätzlichen Funktionen und Erweiterungen von Adobe. Eine dieser Erweiterungen ist das Kompilieren und Erstellen von hybriden Apps in der Cloud auf Adobe-Servern.

Ionic

Ionic basiert ebenfalls auf Cordova. Mittels Ionic lassen sich hybride Apps schneller entwickeln. Es stellt dafür UI-Elemente zur Verfügung und eigene Module von Dritthersteller, die in einem separaten Store erwerblich sind.

Diese Module können eigene Kalenderansichten, oder ganze Workflows sein.

Die Vorteile von hybriden Apps besteht darin, dass auch Webentwickler ohne Kenntnisse der nativen Programmiersprachen Apps erstellen können, welche im App-Store zur Verfügung gestellt werden können.

Ein weiterer Vorteil ist eine Codebasis, die für iOS und Android und in dem Fall von hybriden Apps sogar für Webseiten benutzt werden kann.

Nachteile sind hier die Geschwindigkeit, da die App in einem Browser läuft und der fehlende Zugang auf native UI-Elemente. Wenn eine Offline-Funktionalität gewünscht ist, muss entweder auf die neue WebStorage-API zugegriffen, oder über eine Schnittstelle mit der nativen Datenhaltung in der App gearbeitet werden.

Frameworks mit nativen UI-Elementen

Die im folgenden besprochenen Cross Platform Frameworks benutzen einen anderen Ansatz.

Xamarin, React Native und Appcelerator verwenden für die Businesslogik auf beiden Plattformen eine Codebasis und generieren für die UI native Komponenten.

Xamarin

Xamarin verwendet die Sprache C# um für beide Plattformen die Geschäftslogik und die GUI abzubilden.

Dabei wird pro Betriebssystem in ein anderes Format kompiliert.

  • bei iOS wird der C#-Code mittels ahead-of-time (AOT) in eine ARM assembly kompiliert.
  • bei Android wird der C#-Code zu IL (Intermediate Language) kompiliert und mit der MonoVM paketiert. Native Funktionen können über JNI (Java Native Interface) angesprochen werden.

Native GUI-Elemente werden pro Plattform erstellt. Bei iOS kann direkt mit dem Xamarin iOS Designer eine Storyboard-Datei erstellt werden. Bei Android wird per Drag-and-Drop eine .AXML-Datei erstellt. Durch diese Architektur ist eine App nicht unterscheidbar, bezüglich UI und Performance, zwischen der nativen Entwicklung und Xamarin.

Als einziges Cross Platform Framework in diesem Beitrag ist Xamarin nicht komplett kostenlos. Die Community-Version kann für Unternehmen, mit weniger als eine Million Dollar Umsatz pro Jahr, verwendet werden. Die Professional-Version kostet im ersten Jahr 1.199$ und die Enterprise-Version 5.999$. Nach dem ersten Jahr werden die Lizenzen günstiger.

React Native

React Native verwendet auch native GUI-Komponenten, ähnlich wie Xamarin. Bei der Programmiersprache handelt es sich um Javascript.

Ein Vorteil von React Native gegenüber Xamarin ist die Möglichkeit über ein Hot-Reload-Mechanismus beim Entwickeln, schneller die Änderungen angezeigt zu bekommen.

Bei Xamarin beschweren sich die Entwickler über sehr lange Kompilierzeiten.

React Native verwendet eine Bridge zwischen den Javascript-Threads und den nativen Threads des jeweiligen Betriebssystems.

Diese Brücke erlaubt eine asynchrone und bidirektionale Kommunikation zwischen diesen Welten.

Durch diese Asynchronität ist die Geschwindigkeit mit der von nativen Apps gleichgestellt. Die Kommunikation wird auch verwendet, um UI-Elemente über Aufrufe zu generieren. Dabei können diese Elemente, wie bei der nativen Entwicklung bei iOS, im Objektbaum angezeigt werden.

XCode-Abschnitt mit vergrößerter Darstellung des React Native Viewbaums

React Native Viewbaum

React Native wurde von Facebook entwickelt und wird weiterhin sehr gepflegt. Durch native Module können Funktionen des Betriebssystems oder andere Bibliotheken der JavaScript Ebene zur Verfügung gestellt werden. Es gibt zahlreiche Module von Facebook, aber auch Drittanbieter erkannten Potenzial darin und bieten React Native Module an, um auf ihre nativen Bibliotheken zugreifen zu können.

Frameworks mit eigenen Renderern

Flutter

Flutter ist ein sehr junges Framework von Google. Die Apps werden mit der Programmiersprache Dart entwickelt wird.

Ähnlich wie React Native ist ein Hot-Reload-Mechanismus vorhanden, welches die Entwicklungszeit verkürzt.

Die Besonderheit bei Flutter liegt in dem graphischen Renderer Skia, welche sich um die UI-Erstellung kümmert. D.h.: Flutter erstellt keine nativen UI-Komponenten wie Xamarin oder React Native, sondern baut die komplette UI über die in C++ geschriebene Skia Bibliothek auf.

Es präferiert hierbei das hauseigene Material-UI, um eine GUI für iOS und Android zu erstellen. Trotzdem gibt es viele Implementierungen von Widgets, welche die nativen iOS-Funktionen nachbauen.

Beispiele von Flutter Cupertino Widgets

Beispiele von Flutter Cupertino Widgets

Widgets werden alle Komponenten für die UI in Flutter genannt. Dabei können Widgets einen Zustand speichern oder zustandslos sein. Widgets können auch weitere Widgets beinhalten und damit die UI in einer Baumstruktur aufbauen.

Nicht im Fokus

Progressive WebApps / Unity

Nicht im Fokus dieses Beitrages sind Progressive WebApps und Unity, mit welchen auch Dienste dem Benutzer zur Verfügung gestellt werden können und nur aus einer Code-Basis bestehen.

Vergleich als Tabelle

Nativ Cordova Xamarin React-Native Flutter
Benutzt native UI-Komponenten
Hat eigenen Renderer
Programmiersprache Java/Kotlin Objective C/Swift HTML/CSS/Javascript C# Javascript Dart

Zusammenfassung

Die Vorteile der Cross Platform Entwicklung sind im Wesentlichen die Benutzung einer Code-Basis und einer Programmiersprache für mehrere Betriebssysteme. Bei kleineren Projekten ohne eine Notwendigkeit für eine native Schnittstelle und nur ein UI-Design für beide Plattformen schrumpft die Entwicklungszeit um ein wesentliches für iOS und Android Geräte. Mittels Hot-Reload-Funktion wie in React-Native oder Flutter kann noch mehr Zeit eingespart werden.

In diesen Projekten entscheiden dann eher andere Faktoren die Auswahl des Frameworks. Beispielsweise lässt sich mit Cordova auch eine Webseite mit der gleichen Businesslogik und UI erstellen.

Wenn im Unternehmen bisher nur für das Web entwickelt wurde, wird die Einarbeitung in Cordova oder React Native wegen der verwendeten Sprache JavaScript deutlich verkürzt.

Soll die App performant sein, dann ist Cordova und Webtechnologie nicht dafür geeignet. Hier wäre React Native und Flutter vom Vorteil.

Als Entscheidungskriterium kann hierbei auch die Verfügbarkeit von Entwicklern gelten. Da Flutter erst im Winter 2018 die Version 1.0 herausgegeben hat, kann es noch keine Entwickler mit mehrjähriger Erfahrung geben.

Die größten Nachteile bei Cross Platform Entwicklung ist die Abhängigkeit der Framework- und Drittanbieterplugin-Entwickler. Wenn eine neue Betriebssystemversion für iOS oder Android erscheint, dann ist oft hier bei den Framework Anbietern Arbeit mit verbunden. Auch Anbieter von Plugins sind nicht immer aktuell oder aktualisieren ihre Software nicht. Beispielsweise kann sich eine interne Schnittstelle ändern und das eingebettete Plugin wird nicht mehr aktualisiert, weil der Entwickler keine Zeit und Interesse mehr hat. Bei diesem Szenario muss das Plugin oftmals selbst angepasst werden, was Expertise in der nativen Programmiersprache voraussetzt. Durch die Verwendung eines Cross Platform Frameworks erhöht sich die Pflege einer App gravierend.

Wenn die jeweiligen nativen UX Paradigmen genutzt werden sollen, fällt zusätzliche Arbeit an und die Komplexität und Wartung steigt. Apps auf Basis von Cordova „fühlen“ sich nicht nativ an und können durch Performanceprobleme die Benutzer verstimmen.

Fazit

Für einen Prototypen mit wenigen Funktionen der in kurzer Zeit erstellt werden muss, eignen sich Cross Platform Frameworks gut. Falls es sich um größere und langlebige Projekte handelt, rät der Autor zu einer nativen Entwicklung. Diese hat die Vorteile, dass es viele Entwickler gibt und geben sollte, das UX für die Benutzer bekannt ist und die Performance stimmt. Der doppelte Programmieraufwand zu Beginn wird bei der Pflege des Produkts egalisiert und es ist für Betriebssystemaktualisierungen gewappnet.

Sie denken darüber nach eine innovative App mit geringer „Time-to-Market“ mittels Cross Platform Frameworks erstellen zu lassen oder möchten eine jahrelang leicht zu pflegende App entwickeln lassen? Im Bereich Application Development & Managment unterstützen wir Sie gerne dabei.  Kontaktformular

Links

Mitarbeitermotivation im Testteam – Fallbeispiele aus der Praxis

Aktuell werden in den Softwareunternehmen die Mitar­beiter auf die vorhandenen Projekte annähernd willkür­lich verteilt. Wunschtätigkeiten sind bei der angespannten wirtschaftlichen Lage eher Zufall. So hat auch das Testen nach wie vor den Ruf einer Parktätigkeit. Hier beginnt die Aufgabe des Teamleiters zu motivieren und entsprechende Perspektiven zu schaffen. Die Praxis hat aber gezeigt, dass die Mitarbeitermotivation nicht nur von den unterschiedlichen Anforderungen an das Testen, z.B. während der Softwareentwicklung oder dem Abnahmetest von Endprodukten, sondern auch von der Zusammensetzung der jeweiligen Testteams, dem Ausbildungsstand, dem Anteil der Mitarbeiter aus Fremdfirmen und der jeweiligen Projektsituation (Organisation, Termindruck) abhängt.

Deswegen hat sich uns die Frage gestellt, wie der entscheidende Erfolgsfaktor „Motivation“ im Testen gefördert werden kann. Die von uns im Hinblick darauf gemachten Projekterfahrungen gilt es, anhand geeigneter motivationstheoretischer Modelle zu verdeutlichen.

Wir können keinen vollständigen Überblick über die Motivationstheorie geben, wollen aber in der Praxis erprobte Lösungsansätze vorstellen, die den Testprojektalltag angenehmer gestalten.

Weiterlesen

Integrationstests mit Testcontainers und Keycloak

Wie das nach Konferenzen so ist: Es kribbelt in den Fingern und man möchte die Dinge schnell ausprobieren. Auf der diesjährigen Javaland gab es einen spannenden Talk zum Thema „Integrationstests mit Docker und Testcontainers“. Wir haben Testcontainers mal etwas genauer unter die Lupe genommen.

Weiterlesen

App-Entwicklung unter SharePoint: Anonymer Zugriff

Mit SharePoint gibt es keine öffentlichen Web-Seiten für ein anonymes Publikum. Wirklich?

Es ist schon richtig: Bei SharePoint geht es um die Zusammenarbeit von Teams im Netz. Bis in die kleinsten Verästelungen der Seiten-, Daten- und Anwendungsstruktur läßt sich komfortabel bestimmen, wer was bis zu welchen Grade ausführen, sehen oder ändern darf. Hier liegt eine der großen Stärken von SharePoint.
Aber wenn wir in speziellen Einzelfällen auf diese Stärken gerade einmal gar keinen Wert legen? Was, wenn wir eine Seite einem Publikum präsentieren wollen, das wir weder kennen noch zu kennen brauchen?
Das geht mit SharePoint nicht. Oder doch?
Das geht mit SharePoint nicht. Oder doch?
Beispiel: Während der Vorproduktion zu einem Werbefilm lädt die Casting-Direktorin Aspiranten für die zu besetzenden Rollen in ihr Studio ein. Film- und Fotoaufnahmen werden gemacht, Details zu den Bewerbern werden aufgenommen, und all diese Inhalte werden, komfortabel und benutzerfreundlich aufbereitet, auf einer SharePoint-Team-Site dem inneren Kreis der an dieser Talentsuche Beteiligten bereitgestellt.
Wir sind nun dieser „innere Kreis“, haben vielleicht einige Korrekturen vorgenommen und eine Vorauswahl unter den Aspiranten getroffen, und wollen nun unsere Seite einem größeren Publikum vorstellen: dem auftraggebenden Kunden, der Werbeagentur, oder wem auch immer. Dieses größere Publikum ist weder Teil unseres SharePoint-Teams, noch wäre es praktikabel, es dazu zu machen. Wir haben es also mit einem teilweise anonymen Publikum zu tun.
Lassen Sie uns für dieses Anwendungsbeispiel weiterhin annehmen, daß wir mit der aktuellen Online-Version von SharePoint arbeiten und unsere Erweiterungen konsequenterweise als SharePoint Framework (SPFx) WebParts, also als moderne client-seitige Web-Apps mit JavaScript-Werkzeugen und -Bibliotheken, realisieren. Mit dieser zusätzlichen Bedingung fallen bei unserem Beispiel dann auch sämtliche Lösungsansätze aus, die eine benutzerdefinierte server-seitige Instanz zur Zugriffskontrolle benötigen würden.
Die gute Nachricht ist nun, daß wir eine solche benutzerdefinierte Instanz gar nicht brauchen. Entgegen der landläufigen Meinung gibt es anonyme Zugriffe auf SharePoint-Ressourcen wie Dateien, Ordner und Seiten.
So geht’s:
Wenn SharePoint Online in der Ressourcen-Anforderung keinen rtFA- oder FedAuth-Cookie findet, wird es normalerweise das Azure Active Directory bitten, den Benutzer zu authentifizieren. Für unser Szenario mit einem teilweise anonymen Publikum brauchen wir also eine Technik, um diese Anfragen zu vermeiden.
Hierzu gibt es die Spezial-Seite guestaccess.aspx, die auch dann keine Anfrage an das Azure Active Directory sendet, wenn rtFA- oder FedAuth-Cookie fehlen. Statt dessen erwartet guestaccess.aspx einen speziellen Parameter „share“. Der Wert dieses Parameters ist ein Schlüssel für eine interne Tabelle, die solche Schlüssel auf die eigentlichen Ressourcen-Adressen abbildet. Eine gültige Anfrage an guestaccess.aspx beantwortet SharePoint mit einem Redirect auf die jeweils zugeordnete Ressource und einem FedAuth Antwortcookie.
Sendet nun der Client-Browser seine Anfrage – zusammen mit dem FedAuth-Cookie – an die Redirect-Adresse, liefert SharePoint die Ressource aus: Der Benutzer ist zwar weiterhin anonym, aber der vorhandene und für die Ressource gültige FedAuth-Cookie verhindert die sonst zwingende Anfrage an das Azure Active Directory.
Zurück zu unserem Beispiel mit der Casting-Direktorin: Das SPFx WebPart, mit dem unser Team arbeitet, hat seine Datenbasis in SharePoint Listen und Content-Typen. Die mächtige Rechteverwaltung von SharePoint stellt auf komfortable Weise sicher, daß die Anfragen, die ein Benutzer vom WebPart an die Datenbasis absetzt, so beantwortet werden, wie es den Zugriffsrechten des jeweiligen Benutzers entspricht.
Eine SharePoint Liste ist nun aber keine Ressource, für die ein „share“-Schlüssel für anonymen Zugriff, so wie für Seiten, Dateien und Ordner, erstellt werden könnte. Genauer betrachtet würde unsere Casting-Direktorin und das innere Produktionsteam dem anonymen Publikum auch gar keinen ungefilterten und ungeordneten Zugriff auf die ganze Liste geben wollen. Was unser Team nach seiner Vorauswahl und Rollenzuordnung der Aspiranten im Grunde will, ist folgendes: Eine geordnete, selektierte Liste in präsentabler Form an den auftraggebenden Kunden und die Werbeagentur übergeben.
Richtig betrachtet haben wir es in unserem Anwendungsbeispiel also gar nicht mit der Anforderung zu tun, einen anonymen Zugriff auf die eigentliche Datenbasis bereitzustellen. Was wir brauchen ist der anonyme Zugriff auf das Ergebnis einer Abfrage.
Das letzte Teil des Puzzles:
Für SPFx WebParts lassen sich im Manifest beliebige Schlüssel definieren, die im Kontext einer Seite mit Werten belegt werden können. Für das aktive WebPart sind diese Schlüssel “own properties”, also direkt verfügbare Variable.
Diese preconfiguredEntries.properties sind der letzte Baustein, den wir für unsere SharePoint-Präsentation für ein anonymes Publikum brauchen: Sie enthalten das Ergebnis einer vorher durch einen authentifizierten Nutzer ausgeführten Anfrage an die Datenbasis. Die veröffentlichte dynamische Seite trägt ihre Datenbasis sozusagen mit sich herum, womit diese Datenbasis denselben Zugriffsbedingungen unterliegt, wie die Seite selbst.
Und jetzt alles zusammen:
In unserem SPFx WebPart unterscheiden wir zwischen authentifizierten Benutzern mit Zugang zu allen Funktionen und normalem Datenbankzugriff einerseits und anonymen Gästen mit eingeschränktem Zugang und ohne Datenbankzugriff andererseits.
Authentifizierte Benutzer und anonyme Gäste
Statt eine Anfrage an die Datenbank abzusetzen, wird für anonyme Gäste der Inhalt vordefinierter WebPart Properties ausgelesen.
Anonyme Gäste erhalten den Inhalt vordefinierter WebPart Properties
Für authentifizierte Benutzer stellen wir eine Funktion bereit, die programmgesteuert neue Seiten erstellt, die unseren SPFx WebPart enthalten und diesem die gewünschten Werte für die vordefinierten WebPart Properties mitgibt. Diese Werte sind beispielsweise Antworten auf CAML-Abfragen.
Authentifizierte Benutzer erhalten eine Funktion bereit, die programmgesteuert neue Seiten erstellt
Für authentifizierte Benutzer stellen wir außerdem eine Funktion bereit, die einen Eintrag für die neu erstellte Seite in die interne /ShareLink Tabelle schreibt, und einen “share”-Token für guestaccess.aspx zurückgibt. Hinweis: Die URLs, die File.getShareLink im Beispiel unten zurückgibt, machen den “share”-Token nicht direkt sichtbar, da SharePoint einen internen Kurz-URL-Dienst anwendet.
Guest-Access-Seite und Share-Token
Die von File.getShareLink zurückgegebene URL wird dann an unser „anonymes“ Publikum – beispielsweise den auftraggebenden Kunden oder die Werbeagentur – weitergegeben. Die sonst bei SharePoint übliche Aufforderung zum Sign In wird dieses Publikum nicht sehen.

App-Entwicklung unter SharePoint: Table Joins

Joining SharePoint content für SQL Programmierer. Was geht und was nicht geht.

»Enttäuschung ist mir eine Beglückung, denn zuvor war ich getäuscht, danach ist die Täuschung aufgehoben.«
(Horst Eckert a.k.a. Janosch)

Wer Jahre mit SQL verbracht hat, und dann auf einmal SharePoint Listen und ContentTypes vor sich hat, sollte auf eine Lehrstunde gefaßt sein. Aus der SQL-Welt sind wir es gewohnt, selbst Tabellen, die in unserer Datenbank in keiner durch Constraints definierten Verbindung stehen, frei und je nach Anforderung neu miteinander zu verknüpfen. Manche mögen bei solchen Aktivitäten – vielleicht nicht ganz zu Unrecht – die Qualität des Datenbankdesigns in Frage stellen.
Für jene strengen Gemüter gibt es gute Nachrichten: Wer sich die gegenseitigen Abhängigkeiten und Bezüge seiner Daten nicht vor dem Bau seiner SharePoint Listen und ContentTypes gut überlegt, wird mit CAML – dem Äquivalent zu SQL bei SharePoint – nur wenig Freude haben. Gleich vorweg: Wer bei SharePoint nicht schon beim Datenbankdesign Relationen definiert, wird sich später seine Verknüpfungen nach einzelnen REST-Abfragen auf die beteiligten Listen/ContentTypes selbst zusammenbauen müssen.
Hier hört die Ähnlichkeit aber auch schon auf.
Verwandtschaften
Eine SharePoint “List” mit ihrem zugeordneten “ContentType” ist konzeptionell verwandt mit einem SQL Table.
Ein SharePoint “Lookup” Feld ist konzeptionell verwandt mit einem SQL Foreign Key Constraint.
Hier hört die Ähnlichkeit aber auch schon auf.
“Lookup” ist das SharePoint Zauberwort für Table-Joins
“Lookup” ist das SharePoint Zauberwort für Table-Joins
Während bei einer SQL-Abfrage prinzipiell jede Tabelle mit jeder anderen Tabelle über beliebige Spalten verknüpft werden kann, ist ein SharePoint Join immer und grundsätzlich an solche Relationen gebunden, die bereits durch Lookup Felder etabliert sind.
In die SQL-Welt übersetzt hieße das: Table-Joining nur über die bereits in der Datenbank definierten Foreign Keys Constraints.
Für moderne WebParts aufbauend auf dem SharePoint Framework (SPFx) und Deployment von Features (Lists, ContentTypes, Columns) als Teil des Solution-Deployments bedeutet das: Über mögliche Join-Operations wird bereits beim XML-Design der Site columns, Site content types und Site lists entschieden.
Option 1: Database first.
Und so geht’s. Option 1: Database first.
Mit dieser Option wird die Ergebnistabelle bereits bei der Feature-Implementierung vorbereitet. Nach SQL übersetzt: Datenbankseitig wird ein View über die primäre Tabelle und deren Referenzen erzeugt, und eine Abfrage auf diesen View braucht sich um das Joining nicht mehr zu kümmern. Table-Joins erscheinen für den Abfragenden vollständig transparent.
Implementierung:
Für den primären ContentType wird eine Lookup Column definiert, die auf den sekundären ContentType verweist. SharePoint realisiert dies intern immer über den Wert der ID-Column des sekundären ContentTypes. In SQL-Sprache: Die auf die sekundäre Tabelle verweisende Spalte der primären Tabelle wird mit einem Foreign Key Constraint an die ID-Spalte der sekundären Tabelle gebunden.
Für alle weiteren Spalten der sekundären Tabelle, die in der Ergebnistabelle benötigt werden, wird jeweils eine sekundäre Lookup-Column definiert, die auf die primäre Lookup-Column verweist.
Schema-Definition für Option 1: Database first.
Schema-Definition für Option 1: Database first.
Option 2: Code first.
Und so geht’s. Option 2: Code first.
Mit dieser Option werden alle weiteren Spalten, die aus der sekundären Tabelle benötigt werden, zur Abfragezeit durch CAML-Code deklariert.
Auch für diese Option 2 gilt: Eine Relation zwischen primärer und sekundärer List/ContentType wird Feature-seitig über eine Lookup column hergestellt. Existiert eine solche Relation nicht, kann eine Zusammenführung von Daten aus mehreren Lists/ContentTypes nicht durch eine einzelne Datenbankabfrage, sondern nur programmseitig über mehrere Einzelabfragen realisiert werden.
Implementierung:
Wie bei Option 1 wird für den primären ContentType eine Lookup Column definiert, die auf den sekundären ContentType verweist. Die Definition der weiteren Spalten, die in der Ergebnistabelle benötigt werden, erfolgt jedoch nicht bei der Feature-Definition, sondern wird erst zur Abfragezeit über CAML-Code dynamisch vorgenommen.
CAML-Definition für Option 2
Die Namen der “ProjectedFields” können jetzt wie bei Option 1 der Liste der abgefragten hinzugefügt werden.

Chancen und Herausforderungen agiler Vorgehensweisen

Wann agile Vorgehensweisen und leichtgewichtige Dokumente an ihre Grenzen kommen

Seit Jahren wächst der Hype um agile Vorgehensweisen, wobei sich der Hype in den vergangenen Jahren, zusammen mit den Themen Digitalisierung und Industrie 4.0 exponentiell gesteigert hat. Fast täglich erscheinen neue Artikel, White-Paper, Management-Präsentationen oder gar ganze Bücher, die Agilität als eine Art Wunderwaffe predigen. Agile Vorgehensweisen sollen helfen, der stetig steigenden Komplexität und dem Bedarf einer immer kürzer werdenden Time-To-Market gerecht zu werden. Aber ist es tatsächlich der Fall, dass mit agilen Vorgehensweisen nun – mehr als 30 Jahre nach Brooks Aussage: „there is no silver bullet in software engineering“ – endlich ein Allheilmittel gefunden wurde, um Software mit besserer Qualität in kürzerer Zeit zu liefern?

[den vollständigen Artikel finden Sie im Objektspektrum Online-Themenspezial Requirements Engineering]

Data Lake, Datenschutz und die Cloud

 

Data Lake in der Cloud

Ein wichtiges Thema, dass fast jedes Unternehmen „umtreibt“ ist die Frage, ob man mit seinen IT-Systemen wie etwa einem Data Lake in die Cloud gehen soll. Der Betrieb von Anwendungen in der Cloud bietet nämlich zahlreiche Vorteile, die in vielen Fällen das Entwickeln und auch die Betriebsführung derselben einfacher und billiger machen können. Auf der anderen Seite gibt es aber Nachteile, welche sorgfältig gegen die Vorteile abgewogen werden müssen. Dazu gehört unter anderem, eine genaue Vorstellung zu entwickeln, wie man mit einem geeigneten Vorgehen den eher negativ bewerteten Aspekten gegensteuern kann, ohne die eigentlichen Vorteile zu verlieren.  Zu diesen gehören:

  • Die Cloud bietet standardisierte Produkte und eine möglichst einfache Automatisierung aller Arbeitsschritte
  • „Pay per Use“ oder „Pay as you go“: Klare Preismodelle, d.h. die Kosten sind vorhersagbar. Das hängt natürlich davon ab, ob man die Einsatzszenarien hinreichend genau kennt: Ein möglicher Kostentreiber kann Datentransfer von und in die Cloud sein. Klar bedeutet hierbei auch nicht, dass sich die Kosten einfach berechnen lassen, denn es gibt typischerweise viele Faktoren und Unbekannte, die die Kosten am Ende bestimmen… Und: „Cloud“ ist nicht unbedingt in allen Fällen billiger!
  • Verläßliche und bei Bedarf hochverfügbare und einfach skalierbare Umgebungen, ohne eine eigene Infrastruktur dafür betreiben zu müssen

Dem gegenüber stehen auch Nachteile, wie:

  • Höhere Abhängigkeit im Vergleich mit „On-Premise“ Lösungen, da die Infrastruktur nicht mehr in meiner eigenen Hand liegt und gegebenenfalls auch proprietäre Lösungen des Cloud Providers in Frage kommen
  • Das Thema Dateneigentümerschaft ist problematisch, denn der Cloud Provider hat ja notwendigerweise auch die Daten
  • Datenschutzthemen allgemein werden vor dem Hintergrund der Cloud kritisch gesehen

Erhalten der Vorteile, minimieren der Nachteile..

Dem Problem „höhere Abhängigkeit“ läßt sich relativ leicht gegensteuern. Im Grunde genommen muss ich nur dafür sorgen, dass Standardprodukte zum Einsatz kommen, welche problemlos auch in der Cloud eines anderen Providers laufen könnten, wie hier skizziert:

  • Aufbau des Data Lakes in „leeren“ virtuellen Umgebungen mit einer Standard Linux Distribution als Betriebssystem
  • Einsatz einer standardisierten Big Data Distribution wie beispielsweise Hortonworks und, soweit möglich, Vermeidung irgendwelcher herstellerspezifischer Komponenten
  • Generell Einsatz von Open Source Hadoop Tools und Big Data Komponenten
  • Verwendung von Architekturstandards und –patterns
  • Einsatz gängiger Programmiersprachen und Protokolle
  • Vermeiden des Einsatzes von Cloud Provider spezifischen Lösungen

Ein schwierigeres Thema ist das des Datenschutzes und der eng damit verbundenen Problematik der Dateneigentümerschaft. Hier besteht ja das Grundproblem schon darin, dass die Daten nicht „bei mir“ sondern „irgendwo“ in der Cloud liegen. Das heißt natürlich, sie liegen in der Infrastruktur des Cloud Providers. Dieser hat damit potentiell auch Vollzugriff auf die Daten, wobei nicht zwischen sensiblen und (relativ) unsensiblen Daten unterschieden wird. Genau hier kommt auch gleich der Datenschutz ins Spiel – ohne nachgewiesenen Schutz dürfen sensible Daten typischerweise gar nicht das Unternehmen verlassen. Manchmal heißt „gar nicht“ auch im absoluten Sinne, dass es unmöglich ist, die Daten außerhalb bestimmter zugelassener „Bereiche“ innerhalb des Unternehmens zu speichern. In diesem Falle ist Cloud leider keine Lösung. Wenn es darum geht, dass Daten nur in Cloudcentern einer bestimmte Region physikalisch gespeichert werden oder gar ein Land nicht verlassen dürfen, dann ist die Antwort größerer Cloud Provider meist das Angebot, Daten auch physikalisch nur in Cloud-Rechenzentren einer bestimmten Region (Europa) oder eines Landes (z.B. Deutschland / Frankfurt) zu speichern. Oftmals ist das verbunden mit rechtlichen Konstrukten die unterbinden, dass Dritte Zugriff auf die Daten verlangen dürfen.

Eine Stufe „tiefergelegt“

Neben diesen allgemeinen Maßnahmen gibt es zahlreiche weitere, die tiefer gehen. Im folgenden eine Auswahl anhand von konkreter Praxiserfahrung in Data Lake Projekten:

  • Verschlüsselung der Root Partition aller „Server“ Instanzen und aller weiteren Partitionen (falls vorhanden), ganz besonders auch der Bereiche, in denen meine Daten gespeichert werden
  • Verschlüsselung aller Daten vor Upload in den Data Lake in der Cloud, Entschlüsselung erst nach Download aus der Cloud

  • Sichere Protokolle
  • Zugriffe über Edge Server / Bastion Server
  • Nur die benötigten Services und Ports zwischen konkreten Endpunkten freischalten
  • Feingranulares Berechtigungskonzept
  • Mandantenbasierte Architektur und Sandboxing
  • Klardaten speichern nur wo explizit hierfür eine Rechtsgrundlage existiert
  • Pseudonymisierung und Anonymisierung aller anderen Daten
  • Feingranulares Löschkonzept von Beginn an vorsehen

Und, und , und … Hier ließen sich sicher noch weitere Dinge aufzählen. Doch ich denke, dass das, was ich hier skizziert habe schon mal einen gewissen Überblick zu möglichen Lösungsszenarien gibt. Wenn ich alle diese Dinge beachte (es dürfen auch gerne mehr sein), dann habe ich tatsächlich eine Chance, einen sicheren Data Lake in der Cloud aufzubauen. Einen Data Lake, der den Anforderungen aus Compliance und Datenschutz wirklich genügt.

 

Data Lake und Datenschutz: Alles schwimmt in eigenen Bahnen

Sandboxing und logische Trennung von Bereichen

Ein Begriff, der in Diskussionen zur Architektur von Hadoop-basierten Data Lakes immer wieder fällt, ist „Sandboxing“. Damit ist gemeint, dass es für bestimmte Zwecke nützlich, für manche sogar notwendig ist, vom „eigentlichen“ Data Lake getrennte Bereiche zu haben. Diese können auch außerhalb der Data Lake Infrastruktur liegen. Ein Beispiel hierfür sind analytische Sandboxes, die maßgeschneiderte Umgebungen und Daten nur für Data Scientists bereitstellen. In solchen Umgebungen können verschiedene Methoden und Verfahren entwickelt und erprobt werden, ohne die große „Allgemeinheit“ der Data Lake User zu stören. Da solche Sandboxes typischerweise kleine Varianten derselben Hadoop Distribution sind, ist es in der Regel sehr einfach, später die Ergebnisse in den großen Data Lake zu übertragen. „Klein“ bedeutet hierbei, dass die Anzahl der Worker Nodes und damit auch des Speicherplatzes gegenüber dem eigentlichen Data Lake kleiner ausfallen. Es kann sogar Sinn machen, einen Single Node Cluster aufzusetzen, beispielsweise um bestimmte Funktionalitäten initial auszuprobieren.

Was natürlich auch in Hinblick auf Kosten und gemeinsame Verwendung von Ressourcen oftmals angestrebt wird, ist die Realisierung von „Sandboxes“ in der eigentlichen Data Lake Infrastruktur als alternative Variante. Neben der Notwendigkeit, für alle Benutzerkreise ein passendes Ressourcenmanagement zu entwickeln – hier ist YARN eine wichtige Komponente zur Steuerung – muss man auch Daten und Zugriffsbereiche separieren. Oder anders gesagt: Hier ist nicht nur aus Gründen des Datenschutzes ein passendes Sicherheits- und Zugriffskonzept zu entwickeln – in der Regel gibt es User, die nur auf bestimmte Daten in bestimmten „Sandboxes“ zugreifen dürfen! Jeder Benutzerkreis schwimmt also in seinen eigenen Bahnen.

 

 

 

 

Das läuft darauf hinaus, dass man abgegrenzte Bereiche einrichtet, auf die der eigentliche Data Lake keinen Zugriff hat, sondern nur ein bestimmter Kreis von Usern und / oder Mandanten. Ein typisches Beispiel sind spezielle Klardatenbereiche, die nur dann zulässig sind, wenn man nachweisen kann, dass nur berechtigte Personen mit diesen Daten etwas „machen dürfen“. Das Managen und Nutzen dieser Daten obliegt dann auch ausschließlich diesem Personenkreis. Genauso aber können das auch anonymisierte oder pseudonymisierte Bereiche sein, für die ähnliches gilt. Was also generell gefordert wird ist eine Mandantenfähigkeit des Data Lakes, also die Möglichkeit klar abgegrenzte Bereiche einzurichten

  • mit feingranularer Zugriffsteuerung
  • mit der Möglichkeit einer passenden Ressourcensteuerung

Es ist natürlich innerhalb eines großen Data Lakes viel schwieriger das alles einzurichten, zu steuern und zu administrieren. Deshalb muss immer auch eine Abwägung vorgenommen werden, ob es vielleicht einfacher ist, mit separaten Umgebungen zu arbeiten. Hier sind die Bereiche auch „physisch“ getrennt. Eine Forderung, die von Seiten des Datenschutzes oftmals erhoben wird. Aber nehmen wir mal an, wir könnten mit „logisch“ getrennten Bereichen im Data Lake arbeiten. Wie kann man das erreichen?

Mandantenfähigkeit

Typische Hadoop Distributionen wie z.B. Hortonworks enthalten Mittel für solche Zwecke. Das sind Services und Tools, die die Trennung von Mandanten unterstützen. Wichtig ist dabei, dass eine zentrale Security und Governance Infrastruktur eine Klammer um das Ganze bilden kann.

Im Fall von Hortonworks ist hierbei Apache Ranger eine wesentliche Komponente. Über Ranger lassen sich User, Gruppen / Rollen und deren Berechtigungen feingranular in den folgenden wichtigen Hadoop Komponenten verwalten:

  • Apache Hadoop HDFS
  • Apache Hive
  • Apache HBase
  • Apache Solr
  • Apache Storm
  • Apache Knox
  • Apache Kafka
  • Apache Nifi
  • Apache YARN

Mandanten sind hierbei Gruppen / Rollen und deren Berechtigungen. Grundsätzlich sind das zunächst die Berechtigungen zu schreiben, zu lesen, Daten zu löschen, Objekte anzulegen und zu löschen. Aber es geht auch noch spezieller: In Hive lässt sich beispielsweise der Zugriff auf Tabellen und Views, bestimmte Spalten und sogar eine „row-level“ Security in den Daten selbst realisieren. Das heißt es lässt sich eine Filterung der Daten abhängig vom Security Kontext über eine implizite „where-clause“ des SQL (HiveQL) Statements erreichen. Genauso lassen sich im Hadoop Filesystem HDFS Bereiche (Folder) nur für Mandanten einrichten, dasselbe gilt für Kafka Topics, also die Kafka Messages Bereiche, die nur für bestimmte Mandanten gedacht sind. Ranger wiederum nutzt die nativen Security Mechanismen der einzelnen Komponenten via Plug-Ins.

Und „Sandboxes“?

Sandboxes sind dann einfach die jeweils für bestimmte Nutzergruppen und / oder Mandanten zugänglichen Bereiche wie Hive und HBase Tabellen, bestimmte Directories im HDFS, bestimmte Kafka Topics und auch Solr Collections, beziehungsweise in Hive auch Views und noch tiefergehende Berechtigungen wie „Row-level Security“, die an einer „Mandanten-ID“ in der jeweiligen Tabelle festgemacht werden kann. Wichtig ist eigentlich nur, dass man allen anderen Usern / Gruppen / Rollen, die auch Zugriff auf den Data Lake haben, den Zugriff auf die solchermaßen geschützten Ressourcen entzieht. Für Klardaten bietet sich zusätzlich auch die Verwendung von „Encryption Zones“ im HDFS an, d.h. nur ein Mandant mit dem entsprechenden Schlüssel kann die Daten in Klarform abgreifen, alle anderen bleiben hier außen vor, selbst wenn sie unberechtigterweise sich Zugriff auf die Daten verschaffen können. Das generelle Verschlüsseln von Daten jenseits der speziellen Anforderungen der Anonymisierung und Pseudonymisierung ist besonders für den Cloud Betrieb relevant. Dazu demnächst mehr.