Blog

Feeds

RSS 1.0-, RSS 2.0- oder Atom-Feed.

Daten und deren Herkunft finden mit DataHub

Einer der großen Schwierigkeiten für Data Scientists besteht darin, die benötigten Daten zu finden, sie zu verstehen und deren Vertrauenswürdigkeit zu bewerten. Ohne die notwendigen Metadaten zu den verfügbaren Datenquellen und ohne angemessene Suchfunktionen bleibt das Auffinden benötigter Daten eine große Herausforderung.

Traditionell wurde diese Funktion von aufgeblähten Datenkatalogisierungslösungen bereitgestellt. In den letzten Jahren kamen einige Open-Source-Projekte hinzu, die die Developer Experience (DX) sowohl beim Anbieten als auch beim Konsumieren von Daten verbessern, z.B. Metacat von Netflix , WhereHows von LinkedIn, Amundsen der LF AI & Data Foundation und Marquez von WeWork. Gleichzeitig änderte sich auch das Verhalten der Data Provider, die weggehen von den aufgeblähten Datenkatalogisierungslösungen hin zu Werkzeugen, die partielle Metadateninformationen aus unterschiedlichen Datenquellen ableiten können.

So hat auch LinkedIn WhereHows weiterentwickelt zu DataHub. Diese Plattform ermöglicht das Auffinden von Daten über ein erweiterbares Metadatensystem. Anstatt Metadaten zu crawlen und zu pullen, verwendet DataHub ein Push-Modell, bei dem die einzelnen Komponenten des Datenökosystems Metadaten über eine REST-API oder einen Kafka-Stream auf der zentralen Plattform veröffentlichen. Diese Push-basierte Integration verlagert die Verantwortung von der zentralen Einheit auf die einzelnen Teams, die damit für ihre Metadaten verantwortlich sind. Da immer mehr Unternehmen versuchen, datengesteuert zu werden, ist ein System, das bei der Datenerkennung und dem Verständnis der Datenqualität und -herkunft hilft, von entscheidender Bedeutung.

Dabei erlaubt die Generalized Metadata Architecture (GMA) von DataHub verschiedene Speichertechnologien, die angefragt werden können mit

  • dokumentenbasiertem CRUD (Create, Read, Update, Delete)
  • komplexen Abfragen auch verschachtelter Tabellen
  • Graph-Traversierung
  • Volltextsuche inkl. Autovervollständigung

Es stehen Plugins bereit u.a. für Dateien, BigQuery, dbt, Hive, Kafka, LDAP, MongoDB, MySQL, PostgreSQL, SQLAlchemy, und Snowflake. Darüberhinaus könnt ihr Metadaten an das DataHub übertragen via Konsole, REST-API und Dateien.

Mit der GMA kann auch jedes Team eigene Metadatendienste, sog. GMS, bereitstellen um ihre Daten über Graphen und Suchindizees erschließen zu können.

Um auch die Software, die zum Erstellen der Daten verwendet wurde, erschließen zu können, verwenden wir aktuell Git2PROV und importieren die PROV-Daten anschließend mit file sink.

Schließlich verwendet DataHub Apache Gobblin um den Lebenszyklus der Daten zu erschließen.

Wie bessere Developer Experience die Produktivität steigert

Laut State of DevOps 2021 ist in 78 Prozent der Unternehmen die Umsetzung von DevOps auf mittlerem Niveau ins Stocken geraten. Dieser Anteil ist 4 Jahren fast gleich geblieben.

Die Entwicklung von DevOps steckt auf mittlerer Ebene fest

Die überwiegende Mehrheit der Unternehmen steckt in der Entwicklung von DevOps auf mittlerer Ebene fest. In der Studie wurde die mittlere Ebene in drei Kategorien unterteilt um das Phänomen genauer zu untersuchen.

Wenig überraschend ist, dass Unternehmen, die in der DevOps-Umsetzung schon weit vorangeschritten sind, auch die meisten Abläufe automatisiert haben. In diesen Unternehmen ist auch der Top-Down-Zuspruch für den Bottom-Up-Wandel am größten (→ Top-down und Bottom-up):

Die am höchsten entwickelten Unternehmen profitieren von der Top-Down-Unterstützung der Bottom-Up-Transformation.

Weniger als 2 Prozent der Angestellten hochentwickelter Unternehmen berichten von Widerstand gegen DevOps auf Führungsebene und auch bei den mittel entwickelten Unternehmen sind es nur 3 Prozent. In ihnen geben jedoch nur 30 Prozent an, dass DevOps aktiv gefördert wird, verglichen mit 60 Prozent der hochentwickelten Unternehmen.

Eine Definition von DevOps lässt die Gründe erahnen, weswegen viele Unternehmen bei der Umsetzung steckenbleiben:

»DevOps ist die Philosophie der Vereinheitlichung von Entwicklung und Betrieb auf den Ebenen Kultur, Praxis und Tools, um eine schnellere und häufigere Bereitstellung von Änderungen in der Produktion zu erreichen.«

– Rob England: Define DevOps: What is DevOps?, 2014

Die Studie zeigt, dass DevOps-Tools zwar umfassend bereitgestellt werden, die praktische Umsetzung automatisierter Abläufe jedoch stockt und dem kulturellen Wandel Widerstand entgegenschlägt.

DevOps-Kultur

Ein wesentlicher Aspekt von DevOps-Kultur ist die gemeinsame Verantwortung für das System. Leicht verliert ein Entwicklungsteam das Interesse an Betrieb und Wartung, wenn es einem anderen Team zum Betrieb übergeben wird. Wenn jedoch das Entwicklungsteam die Verantwortung für den Betrieb eines Systems über die gesamte Lebensdauer teilt, kann es die Probleme des Betriebspersonals besser nachvollziehen und auch Wege zur Vereinfachung von Bereitstellung und Wartung finden, z.B. durch die Automatisierung von Bereitstellungen (→ Release, → Deploy, ) und verbessertes Monitoring (→ Metriken, → Incident Management, → Statusseite). Wenn umgekehrt das Betriebsteam die Verantwortung für ein System teilt, arbeiten sie enger mit dem Entwicklungsteam zusammen, das dann auch die betrieblichen Anforderungen besser versteht.

Um eine Kultur der geteilten Verantwortung zu unterstützen sind organisatorische Veränderungen erforderlich. Entwicklung und Betrieb sollten keine Silos sein. Für den Betrieb Verantwortliche sollten frühzeitig in das Entwicklungsteam eingebunden werden. Die Zusammenarbeit zwischen Entwicklung und Betrieb hilft bei der Zusammenarbeit. Übergaben und Freigaben entmutigen hingegen, behindern eine gemeinsame Verantwortung und fördern Schuldzuweisungen.

Die Schnittstelle zwischen Entwicklung und Betrieb kippt.

DevOps-Änderung

Um effektiv zusammenarbeiten zu können, müssen Entwicklungs- und Betriebsteam in der Lage sein, Entscheidungen zu treffen und Änderungen vorzunehmen. Dazu gehört Vertrauen in diese autonomen Teams, den nur dann wird sich ihr Umgang mit Risiken ändern und ein Umfeld geschaffen, das frei von Versagensängsten ist.

Um die Zusammenarbeit von Entwicklungsteam und Betriebspersonal zu fürdern und das System selbst kontinuierlich zu verbessern, ist Feedback essentiell. Dabei kann die Art des Feedbacks die Dauer und die Häufigkeit sehr unterschiedlich sein:

  • Das Überprüfen der eigenen Code-Änderungen sollte sehr häufig erfolgen und daher nur wenige Sekunden benötigen
  • Ob sich eine Komponente in alle anderen integrieren lässt, kann jedoch mehrere Stunden dauern und wird daher deutlich seltener ausgeführt werden.
  • Auch die Überprüfung von nicht-funktionale Anforderungen wie Zeitverhalten, Ressourcenverbrauch, Wartbarkeit etc. kann auch schon mal einen ganzen Tag dauern.
  • Die Antwort des Teams auf eine technische Frage sollte nicht erst nach Stunden oder gar Wochen erfolgen.
  • Die Zeit, bis neue Team-Mitglieder produktiv werden, kann Wochen oder auch Monate dauern.
  • Ein neuer Service sollte innerhalb weniger Tage produktiv werden können.
  • Fehler in Produktivsystemen zu finden ist jedoch häufig erst nach einem oder mehreren Tagen erfolgreich.
  • Eine erste Bestätigung durch die Zielgruppe, dass eine produktive Änderung angenommen wird, sollte nach wenigen Wochen möglich sein.

Dabei dürfte sich von selbst erklären, dass Feedbackschleifen häufiger durchgeführt werden wenn sie kürzer sind. Frühe und häufige Validierung wird auch die spätere Analyse und Nacharbeit reduzieren. Auch einfach zu interpretierende Feedback-Schleifen reduzieren die Aufwände erheblich.

Etsy erfasst nicht nur, ob die Verfügbarkeit und die Fehlerrate von Komponenten den eigenen Ansprüchen genügt, sondern auch in welchem Umfang eine Funktionsänderung von der Zielgruppe angenommen wird: sollte eine Änderung sich als wertlos herausstellen wird sie wieder entfernt, wodurch die technische Schulden reduziert werden können.

Developer Experience

Developer Experience (DX), die Konzepte aus der UX-Optimierung auf Erfahrungen in Entwicklungsteams anwendet, kann hier eine gute Ergänzung sein um die kulturelle Ebene besser aus Sicht des Entwicklungsteams zu erfassen. In Developer Experience: Concept and Definition unterscheiden Fabian Fagerholm und Jürgen Münch die folgenden drei Aspekte:

Aspekt Beschreibung Themen
Wahrnehmung Wie nehmen die Entwicklungsteams die Entwicklungsinfrastruktur wahr?
  • Plattform
  • Techniken
  • Prozess
  • Fähigkeit
  • Verfahren
Emotion Wie fühlen sich die Mitglieder des Entwicklungsteams bei ihrer Arbeit?
  • Respekt
  • Soziales
  • Team
  • Bindung
  • Zugehörigkeit
Motivation Wie sehen die Mitglieder des Entwicklungsteams den Wert ihres Beitrags?
  • Pläne
  • Ziele
  • Ausrichtungen
  • Absichten
  • Motivation
  • Engagement

So könnte der Tag für Mitglieder des Entwicklungsteams in einer wenig effektiven Umgebung aussehen:

  1. Der Tag beginnt mit einer Reihe von Problemen in der Produktion.
    1. Da es keine aggregierten Auswertungen gibt, wird der Fehler in verschiedenen Log-Dateien und Monitoring-Services gesucht.
    2. Schließlich wird das Problem im Auslagern des Arbeitsspeichers in eine Swap-Datei vermutet und das Betriebsteam um mehr Arbeitsspeicher gebeten.
  2. Nun ist endlich Zeit zu schauen, ob es Rückmeldungen vom QA-Team gab zu der neu implementierten Funktion.
  3. Dann ist auch schon das erste von mehreren Statusmeetings.
  4. Endlich könnte mit dem Entwickeln begonnen werden, wenn nur schon der Zugang zur erforderlichen API bereitgestellt worden wäre. Stattdessen werden nun Telefonate mit dem Team geführt, das die Zugänge für die API bereitstellt um nicht erst nach mehreren Tagen mit der Arbeit beginnen zu können.

Wir könnten noch viele weitere Blockaden aufzählen; letztendlich beenden die Mitglieder des Entwicklungsteams ihren Arbeitstag frustriert und demotiviert. Alles dauert länger als es sollte, und der Tag besteht aus nicht enden wollenden Hindernisse und Bürokratie. Die Mitglieder des Entwicklungsteams fühlen sich nicht nur ineffektiv und unproduktiv. Wenn sie diese Arbeitsweise irgendwann akzeptieren, breitet sich bei ihnen erlernte Hilflosigkeit aus.

In einer solchen Umgebung versuchen Unternehmen meist, die Produktivität zu messen und die leistungsschwächsten Team-Mitglieder zu erkennen indem sie die Anzahl der Code-Änderungen und erfolgreich bearbeiteten Tickets messen. In solchen Unternehmen werden meiner Erfahrung nach die besten Fachkräfte gehen; es gibt keinen Grund für sie, in einer ineffektiven Umgebung zu verharren, wenn innovative digitale Unternehmen nach starken technischen Talenten suchen.

Der Arbeitstag in einer hocheffektiven Arbeitsumgebung könnte hingegen so aussehen:

  1. Der Tag beginnt mit dem Blick auf das Projektmanagement-Tool des Teams, z.B. ein sog. Kanban-Board. Anschließend gibt es ein kurzes Standup-Meeting nach sich jedes Team-Mitglied im Klaren ist, woran es heute arbeiten wird.
  2. Das Team-Mitglied stellt fest, dass die Entwicklungsumgebung automatisch aktuelle Bibliotheken erhalten hat, die auch bereits in die Produktion übernommen wurden da alle CI/CD-Pipelines grün waren.
  3. Als nächstes werden die Änderungen in die eigene Entwicklungsumgebung übernommen und mit den ersten inkrementellen Code-Änderungen begonnen, die durch Komponententests schnell validiert werden können.
  4. Beim nächsten Feature wird der Zugang zur API eines Dienstes benötigt, der von einem anderen Team verantwortet wird. Der Zugang kann über ein zentrales Service-Portal beantragt werden, sich ergebende Fragen werden schnell in einem Chat-Raum beantwortet.
  5. Nun kann störungsfrei mehrere Stunden intensiv an dem neuen Feature gearbeitet werden.
  6. Nachdem das Feature implementiert und alle Komponententests bestanden wurden, wird in automatisierten Tests überprüft, ob sich die Komponente auch weiterhin in alle anderen Komponenten integriert.
  7. Sind alle Continuous-Integration-Pipelines grün, werden die Änderungen schrittweise für die vorgesehenen Zielgruppen in der Produktion freigegeben und dabei die Betriebskennzahlen überwacht.

Jedes Mitglied eines solchen Entwicklungsteams kann an einem Tag schrittweise Fortschritte machen und zufrieden mit dem Erreichten den Arbeitstag beenden. In einem solchen Arbeitsumfeld können die Arbeitsziele einfach und effizient erreicht werden und es gibt wenig Reibungsverluste. Die meiste Zeit verbringen die Team-Mitglieder damit, wertvolles zu schaffen. Produktiv zu sein motiviert die Mitglieder des Entwicklungsteams. Ohne Reibung haben sie Zeit, kreativ zu denken und sich einzusetzen. Hier konzentrieren sich die Unternehmen darauf, ein effektives technisches Umfeld bereitzustellen.

Meldet euch

Wir beraten euch gerne und erstellen ein passgenaues Angebot für eine gelingende DevOps-Transformation.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Ich rufe euch auch gerne zurück!

Jetzt anfragen

»Kriterien zur Auswahl sicherer Software« in iX 08/2021

Allgemein

  • Wie sicher ist die Software?

  • Wie gut sind die Daten vor unberechtigten Zugriffen geschützt?

  • Die Sicherheit von quelloffener Software lässt sich am zuverlässigsten prüfen.

  • Falls hinter einer quelloffenen Software ein Unternehmen steht, sollte dieses seine Finanzen und seine finanziellen Interessen an der Software transparent darstellen. Ein gutes Beispiel ist in dieser Hinsicht Delta Chat.

  • Prüft bei der Auswahl von Software nicht nur, ob sie alle funktionalen Anforderungen erfüllt, sondern auch, ob sie datensparsam ist.

  • Über welche Kanäle ist eine Software verfügbar?

    Ist eine Android-App beispielsweise nur über Googles Play Store oder auch über den datenschutzfreundlicheren F-Droid Store erhältlich?

  • Verwendet die Software sichere Verschlüsselungsmethoden?

    Zu unterscheiden ist hier zwischen der Transportverschlüsselung – idealerweise Ende-zu-Ende – und der Verschlüsselung von gespeicherten Daten.

    Die Synchronisierungssoftware Syncthing nutzt beispielsweise sowohl Transport Layer Security (TLS) als auch Perfect Forward Secrecy (PFS) um die Passwortdaten zu schützen.

  • Falls sich der Fingerprint eines Schlüssels ändert, sollte die Software die User darüber informieren.

  • Achtet bei Kommunikationssoftware darauf, dass sei Metadaten vermeidet oder zumindest schützt; sie können sehr viel über das Leben der User aussagen.

Video-Konferenzen

  • Kontrolliert auch bei Open-Source-Software, wie datenschutzfreundlich die Standardeinstellungen sind. So erstellt zum Beispiel Jitsi Meet externe Verbindungen zu gravatar.com und protokolliert mit dem Logging-Level INFO viel zu viele Informationen. Frühere Jitsi-Apps banden auch die Tracker Google CrashLytics, Google Firebase Analytics und Amplitude ein. Betreibt, wenn möglich, eigene STUN-Server, sonst wird meet-jit-si-turnrelay.jitsi.net verwendet.

Virtual Private Network (VPN)

  • Ein Virtual Private Network ist die Basis für den Zugriff auf das Firmennetzwerk von außen.
  • Vertrauen Sie nicht blindlings den Versprechungen von VPN-Anbietern.
  • Nutzt quelloffene Programme wie OpenVPN oder WireGuard.

Fernwartungssoftware

  • Auch für Fernwartungssoftware gibt es Open-Source-Lösungen wie Remotely, deren Quellcode im Gegensatz zu TeamViewer oder AnyDesk auf GitHub einsehbar ist.
  • Auch die Sicherheitsrisiken von quelloffener Software lassen sich nur von Fachleuten erkennen.
  • Nutzt Software, die einen Sicherheits-Audit erfolgreich bestanden hat.

Mobile Apps

  • Smartphone-Apps binden häufig sehr viele Tracker ein, die ohne das Wissen der User Daten an Dritte wie Google oder Facebook weitergeben.

  • εxodus Privacy ist eine Website, die Android-Apps analysiert und anzeigt, welche Tracker in einer App eingebunden sind.

  • Kontrolliert, ob die von einer App angeforderten Berechtigungen zur geplanten Nutzung passen.

  • Es ist zum Beispiel unverständlich, warum Messenger wie Signal, Telegram und WhatsApp zwingend die Eingabe der eigenen Telefonnummer verlangen.

  • Vermeidet Apps, die Werbung einbindet.

    Dies birgt die Gefahr von Malvertising, also der Auslieferung von Werbung mit Schadcode. Darüberhinaus können Trackingunternehmen über die eingebundene Werbung die Aktivitäten der User auswerten und vermarkten.

  • Es gibt zahlreiche Tools wie uBlock Origin für Firefox, Blokada für Android und iOS oder AdGuard Pro für iOS, die die Auslieferung von Werbung und den Abfluss persönlicher Daten unterbinden.

  • Mit HttpCanary für Android-Apps und Charles Proxy für iOS-Apps können User selbst untersuchen, wie sich Apps verhalten, sofern die App-Entwickler nicht auf Certificate-Pinning zurückgreifen. Die Burp Suite schneidet deutlich mehr als nur Datenpakete mit und kann auch Certificate-Pinning umgehen.

Datensicherung und -synchronisation

  • Am sichersten ist es, wenn Daten dezentral gespeichert werden.

    Falls dies nicht möglich ist, sind föderierte Systeme, wie zum Beispiel die E-Mail-Infrastruktur, zentralen vorzuziehen.

  • Können alle relevanten Daten auch sicher über die gesamte Nutzungsdauer gespeichert werden?

  • Kann ein Backup aller relevanten Daten erstellt werden?

  • Liegen diese Backups an einem sicheren Ort?

  • Und wer ist für die Backup-Daten rechtlich zuständig?

  • Erfolgt die Sicherung der relevanten Daten automatisch?

  • Sind die Backups verschlüsselt?

  • Können Daten einer Software zwischen mehreren Geräten abgeglichen werden, ohne dass ein zentraler Server zur Vermittlung dafür nötig ist? So synchronisieren wir bei Cusy z.B. unsere KeePass-Datenbank direkt zwischen unseren Geräten mit Syncthing und nicht über WebDAV oder Nextcloud. Dadurch werden die Passwort-Daten nirgends zwischengespeichert, sondern nur dort gespeichert, wo sie auch gebraucht werden.

»Pandemie als Neuanfang« in iX 08/2021

Schafft die Corona-Pandemie die Voraussetzung für neue Arbeitsmodelle und Führungskulturen?

Dies ist die zentrale Frage dieses Artikels [1].

Die Corona-Pandemie hat die Arbeitsplätze grundlegend verändert. Es zeichnet sich ab, dass Teammitglieder in Zukunft sehr viel häufiger zu Hause arbeiten werden. Dennoch ließen die Erfahrungen mit dem Homeoffice auch einige Befürchtungen aufkommen – sowohl im Management wie auch in den Teams. Mehrere Studien verdeutlichen sowohl das Ausmaß der Veränderung wie auch neue Reibungsverluste in der gemeinsamen Arbeit duetlich. In einer von Microsoft in Auftrag gegebenen Studie [2] wurden im August 2020 circa 9.000 Personen aus dem Management und den Teams großer Unternehmen in 15 europäischen Ländern befragt.

  1. Vor der Pandemie hatten demnach nur 15 Prozent der befragten Unternehmen flexible Arbeitsrichtlinien.
  2. Während der Pandemie, als der Druck auf die Unternehmen groß war, die Team-Mitglieder ins Homeoffice zu schicken und den traditionellen Arbeitstag aufzugeben, stieg die Zahl auf 76 Prozent.
  3. Nach der Pandemie erwartet ein Großtiel der Befragten, nämlich 88 Prozent, dass sich eine hybride Form der Fernarbeit fortsetzt. Ein ähnliches Umdenken hatte bereits im August das Leibniz-Zentrum für Europäische Wirtschaftsforschung (ZEW) registriert [3].

Im Homeoffice war jedoch keineswegs alles gut. Welche Herausforderungen müssen die Unternehmen bewältigen, damit die Arbeit im Homeoffice umfassend gelingen kann?

  • 39 Prozent befürchten, dass der Teamgeist verloren gehen könnte.
  • 51 Prozent der Team-Mitglieder sehen Schwierigkeiten beim Onboarding neuer Team-Mitglieder.

Ist Remote Work ein Produktivitäts- und Innovationskiller?

  • 24 Prozent des Managements sehen die Produktivität gefährdet.
  • Nur noch 30 Prozent des Managements glauben, dass sie innovativ sind; im Jahr zuvor waren es noch 40 Prozent.

Bezüglich der Produktivität im Home-Office sind die Ergebnisse der Studien widersprüchlich. Laut der Microsoft-Studie scheint die Befürchtung unbegründet, dass die Produktivität sinken könne. Die meisten Team-Mitglieder konnten sich im Home-Office trotz der häuslichen Ablenkung besser konzentrieren. Für fast ein Viertel des Managements war es jedoch schwierig, die Produktivität zu kontrollieren und zu steuern. Diese Widersprüche lassen sich eventuell mit einem traditionellen Führungsmodell erklären, das die Anwesenheit am Arbeitsplatz mit Produktivität gleichsetzt. Wenn ihr Team in der Ferne arbeitet, mit E-Mail und Chat kommuniziert, ist die Arbeitszeit weniger gut zu kontrollieren. Übertriebenes Mikromanagement ist jedoch auch keine Lösung. Mehr als 60 Prozent des Managements geben an, dass sie Delegation und Förderung der Eigenverantwortung in Remote-Teams nicht beherrschen. Jedoch ist nicht nur für das Management das Messen und Fördern der Zusammenarbeit schwierig; auch die Team-Mitglieder sehen hier Probleme:

  • fast ein Drittel fühlt sich weniger produktiv, wenn sie in großen Gruppen arbeiten
  • fast ein Viertel hat Schwierigkeiten, rechtzeitig Informationen von Kollegen zu erhalten
  • fehlende Schulungen verschärfen die Probleme noch weiter

Sowohl Team-Mitglieder als auch das Management äußern, nicht auf die Arbeit aus der Ferne vorbereitet zu sein, sowohl in Bezug auf geeignete Werkzeuge als auch auf Soft-Skills, wie Einfühlungsvermögen und Delegation von Verantwortung. Nur 41 Prozent der Team-Mitglieder seien nach Angaben des Managements für Telearbeit geschult.

Die Umfrageergebnisse legen nahe, dass Team-Mitglieder sich subjektiv als zu wenig produktiv empfinden und dies durch längere Arbeitszeiten zu kompensieren versuchen. Dies kann zu Burnout führen, zumal das Management den psychischen Zustand einzelner Team-Mitglieder aus der Ferne schlechter beurteilen kann. Für fast 30 Prozent der befragten Team-Mitglieder ist es bei Remote-Work schwieriger geworden, eine nachhaltige Work-Life-Balance aufrechtzuerhalten, und über die Hälfte fühlt sich erschöpft und nicht in der Lage, ihre Work-Life-Balance richtig zu managen.

Geht im Home-Office der Teamgeist verloren?

Wenn das Team nicht mehr im Büro zusammenkommt, kann der Teamgeist schnell verloren gehen, die Beziehungen schwächer werden und das gegenseitige Vertrauen sinken. Für fast 40 Prozent des Managements und fast 50 Prozent der Team-Mitglieder ist es eine Herausforderung, aus der Ferne zu arbeiten und den Zusammenhalt im Team und das Zugehörigkeitsgefühl aufrechtzuerhalten. Mehr als einem Drittel des Managements fällt es schwer, durch die physische Trennung den persönlichen Kontakt zu Team-Mitgliedern aufrechtzuerhalten.

Das Onboarding neuer Team-Mitglieder ist unter Home-Office-Bedingungen besonders schwierig. Obwohl viele Unternehmen gut dokumentierte Onboarding-Routinen haben, ist der informelle persönliche Kontakt nicht zu unterschätzen. Remote wird das Onboarding und Coaching neuer Team-Mitglieder daher zu einer besonderen Herausforderung. Darunter kann auf Dauer die Unternehmenskultur leiden, da neue Team-Mitglieder dann andere Werte und Arbeitsweisen entwickeln.

Wie kann die Zusammenarbeit aus der Ferne aussehen?

Zunächst erfordert das Arbeiten im Home-Office ein Umdenken beim Management. Den Team-Mitgliedern muss sehr viel mehr Raum für Eigenverantwortung und Selbstorganisation gelassen werden. Agile Arbeitsmethoden, wie sie in der Softwareentwicklung schon seit Jahren praktiziert werden, und Lean Management könnten als Blaupause für eine neue Arbeitsorganisation dienen. Elemente agiler Praktiken sind tägliche Stand-up-Meetings – wobei das Stehen soll die Sitzungen kurz und prägnangt halten soll. Die täglichen Selbstverpflichtungen ermöglichen den Team-Mitgliedern eine bessere Einschätzung der potenziellen Herausforderungen und der Koordination zeitaufwändiger Probleme. Bei der Sprint-Planung werden die Ziele für die nächsten Wochen gemeinsam festgelegt. Dabei ist das Kanban-Boards ein wertvolle Werkzeuge nicht nur für die Planung sondern auch den Sprint-Fortschritt sichtbar zu machen.

Kanban-Board

Kanban-Board

Diese Methoden und Werkzeuge lassen sich problemlos in die digitale Arbeitswelt des Home-Offices übertragen.

Wie lassen sich Remote Teams führen?

Die Boston Consulting Group (BCG) bezeichnet in ihrer Studie [4] die Remote-Führungskraft der Zukunft als inspirierend, fürsorglich und einfühlsam. Sie stellt die Eigenverantwortung der Team-Mitglieder in den Mittelpunkt und fördert Empowerment und Teamarbeit. In ihrer Studie stellt BCG jedoch fest, dass die Entwicklung einer fürsorglichen Führung noch nicht überall Wirklichkeit geworden ist. 69 Prozent der befragten Führungskräfte gaben an, dass es zu ihren Aufgaben gehört, Teams zu befähigen und Hindernisse aus dem Weg zu räumen. Ein Drittel glaubt jedoch, dass sie ihren Teams Ziele nicht klar kommunizieren. Und ein Viertel gibt zu, dass sie ihre Teams nicht ermutigen, selbst neue Perspektiven zu entwickeln. Dem Management ist durchaus bewusst, dass Telearbeit besondere Anforderungen stellt. Auf die Frage, welche Fähigkeiten sie noch nicht beherrschen, hoben mehr als 60 Prozent die Schaffung einer starken Teamkultur hervor. 57 Prozent gaben an, dass sie Verantwortung nur schlecht delegieren können und Schwierigkeiten haben, ihre Team-Mitglieder in die Lage zu versetzen, die zugeteilten Aufgaben zu erledigen. Diese Kompetenzlücke ist möglicherweise noch größer, als es dem Management bewusst ist. Die befragten Team-Mitglieder betrachten den Führungsstil ihres Managements nämlich noch kritischer:

  • Nur ein Drittel der Team-Mitglieder ist der Meinung, dass ihr Management Misserfolge toleriert.
  • Nur die Hälfte hat das Gefühl, dass ihr Management ihnen die nötigen Informationen und Kompetenzen gibt, damit sie ihre Arbeit machen können.
  • Ebenfalls die Hälfte der Team-Mirglieder gibt an, dass das Management sie bei wichtigen Entscheidungen nicht um ihre Meinung bittet.
  • Und eine Mehrheit sagt, dass ihr Management keine sichere Umgebung schafft, in der sie ihre Meinung äußern können.

Es ist also noch einiges zu tun, um offene Informations- und Feedback-Prozesse in den Unternehmen zu etablieren. Die Unternehmen werden in ihre Führungskräfte investieren müssen, damit diese in der Lage sind, die neuen Remote-Werte wie Eigenverantwortung, Verantwortlichkeit, Vertrauen und Empathie zu vermitteln und zu stärken.

Die blinden Flecken der Studie

Die Studien von Microsoft und dem Leibniz-Zentrum für Europäische Wirtschaftsforschung (ZEW) zeichnen ein differenziertes Bild der Erfahrungen, die Menschen im Home-Office gemacht haben. Die Boston Consulting Group (BCG) ergänzt dieses Bild um detaillierte Vorschläge für eine Strukturierung neuer Arbeitsmodelle und einer neuen Führungskultur im digitalen Zeitalter. Es gibt aber auch blinde Flecken. Fragen, die die unternehmenseigene IT-Abteilung, die Aufgaben der eigenen IT-Mitarbeiter und damit die digitale Souveränität des Unternehmens betreffen, werden ebenso ausgeklammert wie Fragen einer nachhaltigen Entwicklung der eigenen IT-Infrastruktur. Da zu Beginn der Pandemie ganz schnell Entscheidungen getroffen werden mussten, haben viele Unternehmen vermutlich zur nächstbesten Cloud-Lösung gegriffen, ohne zu bedenken, ob dies langfristig zu verantworten ist. Durch die Nutzung von Cloud-Lösungen entstehen neue Abhängigkeiten, die die digitale Souveränität eines Unternehmens schmälern können. Die Führungskräfte in den IT-Abteilungen der Unternehmen stehen momentan vor einer besonders großen Herausforderung. Wenn sie auf die von großen Konzernen angebotenen Cloud-Lösungen setzen, arbeiten sie im Grunde daran, ihre eigene Abteilung im Großen und Ganzen überflüssig zu machen. Setzen Sie stattdessen auf On-premise-Lösungen müssen sie gegenüber der Geschäftsführung den erhöhten Personalbedarf und unter Umständen Verzögerungen durch eigene Anpassungsleistungen rechtfertigen. Die Souveränität über die eigenen Daten und die Nachhaltigkeit der eigenen IT sind fürs Management oft eine abstrakte Größe, die sich erst dann mit Leistungskennzahlen messen lässt, wenn die Abhängigkeit des Unternehmens von einem einzigen Cloudanbieter so groß geworden ist, dass die Risiken, die sich daraus für das Unternehmen ergeben, nicht mehr zu übersehen sind. In der Regel ist es dann aber zu spät, um ohne erneute Investitionen umzuschwenken. Immer mehr Unternehmen werden sich dieser Gefahr aber bewusst. Sobald die Pandemie im Sommer letzten Jahres etwas abklang, haben die Unternehmen von ihren Beschöftigten wieder mehr Präsenz im Büro eingefordert. Der Grund für diesen schnellen Ausstieg aus dem Home-Office war sicher nicht nur die Furcht vor dem Verlust von Produktivität, Innovation und Teamgeist. Viele Unternehmen werden es bereut haben, beim überstürzten Wechsel ins Home-Office zur erstbesten Cloud-Lösung gegriffen zu haben. Was sollen die IT-Verantwortlichen in den Unternehmen jetzt tun? Wie kann Remote-Work auch auf Dauer gelingen, ohne dass die Kontrolle über die eigenen Daten verloren geht?

Auf dem Weg zu einer nachaltigen IT

Das neue Management-Paradigma muss natürlich durch eine entsprechende technische Infrastruktur unterstützt werden. Dazu gehören einerseits technische Werkzeuge wie eine sinnvolle Ausstattung mit mobilen und stationären Geräten, Kollaborationssoftware wie Videokonferenzen und andere Kommunikations-Tools, Software für Projekt- und Workflow-Management sowie Lernlösungen und soziale Netzwerke für den informellen Austausch. Andererseits benötigen Remote-Worker eine leistungsfähige, technologische Infrastruktur für Berechnungen und Speicherung.

In dieser Hinsicht wirkte Corona wie ein Katalysator und beschleunigte die Entwicklung. Die Zahl der täglich Aktiven auf Kollaborationsplattformen hat sich mehr als verdreifacht. Dreißig mal so viele Personen nahmen täglich an Videokonferenzen teil. Der Absatz von Notebooks für Unternehmen stieg im zweiten Quartal 2020 um mehr als 70 Prozent gegenüber dem gleichen Quartal 2019 [5].

Um sicherzustellen, dass die Vorteile der hybriden Arbeit ihre potenziellen Nachteile überwiegen, sollten Unternehmen einen kohärenten und gut organisierten Weg in die Zukunft der Arbeit einschlagen. Dazu ist eine übergreifende Strategie erforderlich, die die IT-Verantwortlichen in den Unternehmen von ihrer Geschäftsführung einfordern sollten.

Vendor Lock-in und Unterfinanzierung vermeiden

Bei der Umsetzung einer Remote-Work-Strategie sollten die IT-Verantwortlichen immer wieder an ihre Führungskräfte appellieren, nicht in die Falle der Unterinvestition zu tappen. Die BCG-Umfrage zeigt, dass Unternehmen sehr unterschiedliche Beträge für Remote-Working-Technologie ausgeben. Der Durchschnitt liegt zwar bei 533 € pro Mitarbeiter, aber mehr als ein Viertel gibt weniger als 100 € pro Mitarbeiter aus und nur 20 Prozent mehr als 750 €. Unternehmen, die sich von den wirtschaftlichen Auswirkungen der Pandemie erholen müssen, könnten versucht sein, als erstes die Kosten zu senken. Dabei sind Management und Angestellte gleichermaßen besorgt über zu geringe Investitionen – nur 43 Prozent der Angestellten, die Remote arbeiten, haben das Gefühl, dass ihr Unternehmen ihnen alle für die Arbeit erforderlichen Tools zur Verfügung stellen, und nur 27 Prozent des Managements sind der Meinung, dass sie über alle Technologien verfügen, um ihre Teams zu managen. In jedem Fall sollten Unternehmen daran interessiert sein, Vendor Lock-ins beim Aufbau ihrer Remote-Work-Infrastruktur weitestgehend zu vermeiden. Sie sollten darauf achten, dass die eingesetzten Lösungen ihren individuellen Anforderungen entsprechend angepasst werden können. Sie müssen also erweiterbar sein. Erweiterbarkeit kann am einfachsten durch die Verwendung offener Datenformate und offener Schnittstellen erreicht werden. Nur offene, anpassbare und erweiterbare Lösungen gewährleisten das notwendige Maß an Nachhaltigkeit, das Unternehmen von einer größeren Investition erwarten. Unternehmen, die ihren Angestellten Home-Office-Arbeitsplätze anbieten, sollten ferner sicherstellen, dass sie in jedem Fall die Souveränität über ihre Daten behalten. Unter diesem Gesichtspunkt verbietet sich im Grunde die Nutzung von Cloudlösungen großer US-Konzerne wie Amazon, Microsoft oder Google, selbst dann, wenn diese auf dem Papier die Einhaltung der europäischen Datenschutz-Grundverordung (EU-DSGVO) versprechen. Open-Source-Software, offene Schnittstellen und Datenformate gewährleisten nicht nur mehr Datensouveränität und Nachhaltigkeit, mit ihnen können auch Geschäftsprozesse realisiert werden, die wirklich zum Unternehmen passen. Für die vielfältigen vernetzten Services sollten IT-Dienstleister ausgesucht werden, mit denen eine Zusammenarbeit auf Augenhöhe möglich ist, anstatt unternehmenskritische Dienste an global agierende Konzerne auszulagern.


[1]iX 08/2021: Pandemie als Neuanfang – Neue Arbeitsmodelle und Führungskultur
[2]Microsoft: Building resilience & maintaining innovation in a hybrid world (PDF, 3,5 MB)
[3]ZEW: Unternehmen wollen auch nach der Krise an Homeoffice festhalten
[4]Boston Consulting Group: Remote Working and the Platform of the Future
[5]COVID-19-driven notebook momentum continues in Q2 2020

Kriterien für sichere und nachhaltige Software

Open Source
Am besten könnt ihr bei quelloffener Software überprüfen, wie sicher eure Daten vor unberechtigten Zugriffen sind.
Virtual Private Network
Meist ist dies die Basis für den Zugriff auf ein Firmennetzwerk von außen. Vertraut jedoch nicht blindlings den oft falschen Versprechungen von VPN-Anbietern sondern nutzt quelloffene Programme wie OpenVPN oder WireGuard.
Fernwartungssoftware
Mit Remotely gibt es eine gute OpenSource-Alternative zu TeamViewer oder AnyDesk.
Konfiguration

Kontrolliert auch bei Open-Source-Software, ob die Standard-Einstellungen wirklich datenschutzfreundlich sind:

So erstellt zum Beispiel Jitsi Meet externe Verbindungen zu gravatar.com und protokolliert mit dem Logging-Level INFO viel zu viele Informationen. Frühere Jitsi-Apps banden auch die Tracker Google CrashLytics, Google Firebase Analytics und Amplitude ein. Betreibt, wenn möglich, eigene STUN-Server, sonst wird meet-jit-si-turnrelay.jitsi.net verwendet.

Verschlüsselungsmethoden

Hier solltet ihr unterscheiden zwischen der Transportverschlüsselung – idealerweise Ende-zu-Ende – und der Verschlüsselung von gespeicherten Daten.

Die Synchronisierungssoftware Syncthing nutzt beispielsweise sowohl TLS als auch Perfect Forward Secrecy, um die Kommunikation zu schützen.

Ihr solltet informiert werden, wenn sich der Fingerprint eines Schlüssels ändert.

Metadaten
Achtet darauf, dass Kommunikationssoftware Metadaten vermeidet oder zumindest schützt; sie können sehr viel über das Leben der Nutzer aussagen.
Audits
Auch die Sicherheitsrisiken von quelloffener Software lassen sich nur von Fachleuten erkennen. Nutzt Software, die einen Sicherheits-Audit erfolgreich bestanden hat.
Tracker

Smartphone-Apps binden häufig sehr viele Tracker ein, die ohne das Wissen der Nutzer*innen Daten an Dritte wie Google oder Facebook weitergeben. εxodus Privacy ist eine Website, die Android-Apps analysiert und anzeigt, welche Tracker in einer App eingebunden sind.

Kontrolliert auch, ob die von einer App angeforderten Berechtigungen zur geplanten Nutzung passen. Es ist zum Beispiel unverständlich, warum Messenger wie Signal, Telegram und WhatsApp zwingend die Eingabe der eigenen Telefonnummer verlangen.

Malvertising

Vermeidet Apps, die Werbung einbinden und damit die Gefahr von Werbung mit Schadcode bergen. Darüberhinaus können Trackingunternehmen über eingebundene Werbung die Aktivitäten der Nutzer*innen auswerten und vermarkten.

Es gibt zahlreiche Tools wie uBlock Origin für Firefox, Blokada für Android und iOS oder AdGuard Pro für iOS, die die Auslieferung von Werbung und den Abfluss persönlicher Daten unterbinden. Mit HttpCanary für Android-Apps und Charles Proxy für iOS-Apps können Nutzer selbst untersuchen, wie sich Apps verhalten, sofern die App-Entwickler nicht auf Certificate-Pinning zurückgreifen. Die Burp Suite schneidet deutlich mehr als nur Datenpakete mit und kann auch Certificate-Pinning umgehen.

Dezentrale Datenspeicherung
Am sichersten ist es, wenn Daten dezentral gespeichert werden. Falls dies nicht möglich ist, sind föderierte Systeme, wie zum Beispiel die E-Mail-Infrastruktur, zentralen vorzuziehen.
Finanzielle Transparenz
Falls hinter quelloffener Software Unternehmen stehen, sollten diese ihre Finanzen und finanziellen Interessen an der Software transparent darstellen. Ein gutes Beispiel ist in dieser Hinsicht Delta Chat.
Verfügbarkeit
Ist eine Android-App beispielsweise nur über Googles Play Store oder auch über den datenschutzfreundlicheren F-Droid Store.
Datensparsamkeit
Prüft bei der Auswahl von Software nicht nur, ob sie alle funktionalen Anforderungen erfüllt, sondern auch, ob sie nur die notwendigen Daten speichert.
Datensynchronisation
Daten einer Software sollten zwischen mehreren Geräten abgeglichen werden können, ohne dass ein zentraler Server zur Vermittlung dafür benötigt wird. So synchronisieren wir beispielsweise unsere KeePass-Datenbank direkt zwischen unseren Geräten mit Syncthing und nicht über WebDAV oder Nextcloud. Dadurch werden die Passwort-Daten nirgends zwischengespeichert, sondern nur dort gespeichert, wo sie auch gebraucht werden.
Backup
Damit alle relevanten Daten auch sicher über die gesamte Nutzungsdauer verfügbar sind, sollten Sicherungskopien erstellt werden. Diese sollten an einem sicheren Ort liegen, der auch rechtlich zulässig ist. Auch sollte die Sicherung automatisch erfolgen und die Backups verschlüsselt werden.

Python Pattern Matching im Linux-Magazin 05/2021

Die ursprünglich objektorientierte Programmiersprache Python soll in der Version 3.10 ein neues Feature erhalten, das vor allem aus funktionalen Sprachen bekannt ist: Pattern Matching. Die Änderung ist in der Python-Community umstritten und hat eine hitzige Debatte ausgelöst.

Pattern Matching ist ein Verfahren zur Symbolverarbeitung, das anhand eines Musters diskrete Strukturen oder Teilmengen, z.B. Zeichenketten, Bäume oder Graphen, identifiziert. Dieses Verfahren findet sich in funktionalen oder logischen Programmiersprachen, in denen ein Match-Ausdruck verwendet wird, um Daten basierend auf ihrer Struktur zu verarbeiten, z. B. in Scala, Rust und F#. Eine match-Anweisung nimmt einen Ausdruck und vergleicht ihn mit aufeinanderfolgenden Mustern, die als ein oder mehrere Fälle angegeben sind. Dies ist oberflächlich gesehen ähnlich wie eine switch-Anweisung in C, Java oder JavaScript, aber viel mächtiger.

Python 3.10 soll nun auch einen solchen Match-Ausdruck erhalten. Die Implementierung ist im PEP (Python Enhancement Proposal) 634 beschrieben [1]. Weitere Informationen zu den Plänen finden Sie in PEP 635 [2] und PEP 636 [3]. Wie das Pattern-Matching in Python 3.10 funktionieren soll, zeigt dieses sehr einfache Beispiel, bei dem ein Wert mit mehreren Literalen verglichen wird:

def http_error(status):
      match status:
          case 400:
              return "Bad request"
          case 401:
              return "Unauthorized"
          case 403:
              return "Forbidden"
          case 404:
              return "Not found"
          case 418:
              return "I'm a teapot"
          case _:
              return "Something else"

Im letzten Fall der match-Anweisung fungiert ein Unterstrich _ als Platzhalter, der alles abfängt. Dies hat unter Entwicklern für Irritationen gesorgt, da in Python üblicherweise ein Unterstrich vor Variablennamen verwendet wird, um diese für den internen Gebrauch zu deklarieren. Zwar wird in Python nicht so streng zwischen privaten und öffentlichen Variablen unterschieden wie in Java, aber es handelt sich dennoch um eine sehr weit verbreitete Konvention, die auch im Style Guide for Python Code [4] festgelegt ist.

Die vorgeschlagene match-Anweisung kann jedoch nicht nur Muster prüfen, d.h. eine Übereinstimmung zwischen dem Wert einer Variablen und einem gegebenen Muster feststellen, sondern auch die Variablen, die auf das gegebene Muster passen, neu binden.

Das führt dazu, dass wir es in Python plötzlich mit Schrödingers Konstanten zu tun haben, die nur so lange konstant bleiben, bis wir sie in einer Match-Anweisung näher betrachten. Das folgende Beispiel soll dies verdeutlichen:

NOT_FOUND = 404
retcode = 200

match retcode:
    case NOT_FOUND:
        print('not found')

print(f"Current value of {NOT_FOUND=}")

Dies führt zu der folgenden Ausgabe:

not found
Current value of NOT_FOUND=200

Dieses Verhalten führt zu harscher Kritik an dem Vorschlag von erfahrenen Python-Entwicklern wie Brandon Rhodes, Autor von «Foundations of Python Network Programming»:

Wenn diese schlecht durchdachte Funktion wirklich zu Python hinzugefügt wird, verlieren wir ein Prinzip, das ich meinen Studenten immer beigebracht habe: ›Wenn du eine undokumentierte Konstante siehst, kannst du sie immer benennen, ohne die Bedeutung des Codes zu verändern.‹ Das Substitutionsprinzip, gelernt in Algebra? Es wird nicht mehr gelten.

— Brandon Rhodes am 12. Februar 2021, 14:55 auf Twitter [5]

Viele langjährige Python-Entwickler murren aber nicht nur über das strukturelle Pattern-Matching, das in Python 3.10 kommen soll. Sie bedauern generell die Entwicklung der letzten Jahre, in denen immer mehr syntaktischer Zucker über die Sprache gestreut wurde. Ursprüngliche Prinzipien, wie sie im Zen von Python [6] niedergelegt sind, würden dabei vergessen und die funktionale Stabilität ginge verloren.

Obwohl Python mit den Python Enhancement Proposals (PEPs) [7] einen ausgefeilten Prozess definiert hat, mit dem die Weiterentwicklung von Python kollaborativ gesteuert werden kann, gibt es auf Twitter und anderen sozialen Medien immer wieder Kritik, so auch jetzt beim Structural Pattern Matching. Tatsächlich wurde das Thema in der Python-Community bereits intensiv diskutiert. Der Python Steering Council [8] empfahl, die Vorschläge bereits im Dezember 2020 zu verabschieden. Dennoch ist das Thema erst mit der Verabschiedung der Proposals so richtig aufgekocht. Der Grund dafür ist sicherlich die Größe und Vielfalt der Python-Community. Die meisten Programmierer sind wahrscheinlich nur an Diskussionen über Erweiterungen interessiert, die ihre eigenen Probleme lösen. Die anderen Entwicklungen werden übersehen, bis die PEPs angenommen sind. Dies ist wahrscheinlich der Fall beim strukturellen Mustervergleich. Es eröffnet Lösungen für Probleme, die vorher in Python kaum möglich waren. Zum Beispiel erlaubt es Datenwissenschaftlern, passende Parser und Compiler zu schreiben, für die sie bisher auf funktionale oder logische Programmiersprachen zurückgreifen mussten.

Mit der Verabschiedung des PEP ist die Diskussion nun in die breitere Python-Gemeinschaft getragen worden. Brett Cannon, ein Mitglied des Python Steering Councils, wies übrigens in einem Interview [9] darauf hin, dass das letzte Wort noch nicht gesprochen ist: Bis zur ersten Betaversion sei noch Zeit für Änderungen, falls Probleme im praktisch genutzten Code auftreten. Er stellte auch in Aussicht, die Bedeutung von _ noch einmal zu ändern.

Vielleicht bleiben uns also Schrödingers Konstanten erspart.


[1]PEP 634: Specification
[2]PEP 635: Motivation and Rationale
[3]PEP 636: Tutorial
[4]https://pep8.org/#descriptive-naming-styles
[5]@brandon_rhodes
[6]PEP 20 – The Zen of Python
[7]Index of Python Enhancement Proposals (PEPs)
[8]Python Steering Council
[9]Python Bytes Episode #221

Zur Rückkehr von Richard Stallman in den Vorstand der Free Software Foundation

Cusy unterstützt seit vielen Jahren freie und Open-Source-Projekte, auch solche, die von der Free Software Foundation (FSF) verwaltet werden. In Anbetracht der Umstände, unter denen Richard Stallman 2019 zurückgetreten war, ist Cusy entsetzt, dass er nun wieder in den Vorstand der FSF zurückgekehrt ist. Infolgedessen werden wir an keiner von der FSF ausgerichteten Veranstaltungen mehr teilnehmen. Darüber hinaus haben viele Cusy-Mitarbeiter mitgeteilt, dass auch sie nicht länger vorhaben, an von der FSF geleiteten oder unterstützten Veranstaltungen teilzunehmen.

Im Jahr 2019 sah sich Stallman gezwungen, aufgrund des öffentlichen Drucks infolge seiner umstrittenen Äußerungen zum Kinderhandel-Skandal um Jeffrey Epstein von seinem Vorstandsposten bei der FSF sowie seiner Tätigkeit am MIT zurückzutreten. Damals hofften wir, dass die durch seinen Rücktritt geschaffene Gelegenheit von der Free Software Foundation genutzt wird, um sich zu einer diversen und inklusiven Organisation zu wandeln. Leider hat die FSF nur wenige Schritte in diese Richtung unternommen. Die Rückkehr Richard Stallmans machte nun unsere Hoffnungen vorerst zunichte und auch die vorläufige Erklärung des Verwaltungsrats klingt für uns wenig glaubwürdig.

Seine Rückkehr in den Vorstand der Free Software Foundation durfte Stallman selbst verkünden:

Einige von Ihnen werden sich darüber freuen, und einige werden vielleicht enttäuscht sein, aber wer weiß. Auf jeden Fall ist es so, und ich habe nicht vor, ein zweites Mal zurückzutreten.

– Richard Stallman at LibrePlanet 2021 [1]

Auf ihrer Website betont die FSF jedoch:

Freie Software ist nur so erfolgreich wie die Gemeinschaften, die sie erstellen, benutzen, unterstützen und für sie eintreten.

Es ist überdeutlich, dass sich die FSF grundlegend und dauerhaft ändern muss, um das verspielte Vertrauen der Bewegung freier Software wiedererzuerlangen und um ihrem satzungsgemäßen, gemeinnützigen Auftrag zu entsprechen.


[1]«Some of you will be happy at this, and some might be disappointed but who knows. In any case, that’s how it is and I’m not planning to resign a second time.» (Video).

Sicherheitslücken und weitere unkalkulierbare Risiken bei Microsoft – Zeit, zu Open Source zu wechseln

Zehntausende Microsoft Exchange-Server in Deutschland sind über das Internet angreifbar und mit hoher Wahrscheinlichkeit bereits mit Schadsoftware infiziert. Doch auch Microsoft 365 und die Azure Cloud kämpfen mit massiven Problemen. Abhilfe könnten hier passende OpenSource-Alternativen bieten.

Mehrere kritische Sicherheitslücken bei Microsoft Exchange-Servern

Das Bundesamt für Sicherheit in der Informationstechnologie (BSI) wertet die aktuellen Schwachstellen in MS Exchange als geschäftskritische IT-Bedrohungslage mit massiven Beeinträchtigungen des Regelbetriebs [1]. Damit jedoch nicht genug:

»Exchange-Server besitzen in vielen Infrastrukturen standardmäßig (teilweise ungerechtfertigt) sehr hohe Rechte im Active Directory. Es ist denkbar, dass weitergehende Angriffe mit den Rechten eines übernommenen Exchange-Servers potenziell mit geringem Aufwand auch die gesamte Domäne kompromittieren können. Zu berücksichtigen ist zudem, dass die Schwachstelle ebenfalls aus dem lokalen Netz ausnutzbar wäre, sofern beispielsweise ein Angreifer über einen infizierten Client auf Outlook Web Access Zugriff erhält.«

– BSI: Mehrere Schwachstellen in MS Exchange, 17.03.2021

Das Computer Emergency Response Team der Bundesverwaltung (CERT-Bund) hält bei einem aus dem Internet erreichbaren Outlook Web Access-Server (OWA) eine Kompromittierung ab dem 26. Februar für wahrscheinlich [2]. Wenn Admins nun die Sicherheitspatches einspielen, werden zwar die bekannten Sicherheitslücken geschlossen, nicht jedoch eine mögliche Kompromitierung beseitigt. Zusätzlich muus also geschaut werden, ob Server in der Domäne bereits Ziel eines solchen Angriffs geworden sind und z.B. bereits Hintertüren geöffnet wurde.

Auch heute noch sollen ca. 12.000 von 56.000 Exchange-Servern mit offenem OWA in Deutschland für ProxyLogon [3] verwundbar sein und weitere 9.000 Exchange-Server in den letzten zwei Wochen offline genommen oder der Zugriff auf OWA aus dem Internet unterbunden worden sein [4]:

Exchange-Server mit offenem OWA in Deutschland. Verwundbarkeit für ProxyLogon (CVE-2021-26855 et al.). Stand: 16.03.2021

Quelle: CERT-Bund

Erst vor einem Monat warnte das CERT-Bund, dass auch ein Jahr nach Veröffentlichung des Sicherheitsupdates noch immer 31–63% der Exchange-Server in Deutschland mit offen aus dem Internet erreichbarem OWA für die kritische Schwachstelle CVE-2020-0688 verwundbar waren [5].

Probleme auch bei Microsoft 365 und Azure Cloud

Mehrere Dienste von Microsoft sind am Abend des 15. März 2021 ausgefallen. Verursacht wurden die Probleme durch einen automatisiert gelöschten Schlüssel im Azure Active Directory (AAD). Damit konnten sich Nutzer*innen stundenlang nicht mehr anmelden. Dies betraf auch andere Dienste, die auf der Azure Cloud aufsetzen, u.a. Microsoft Teams, XBox Streams und Microsoft Dynamics. Bereits im September 2020 und Februar 2019 gab es mehrstündige Ausfälle von Microsoft Cloud-Diensten, die ebenfalls auf Fehler im Azure Active Directory Service (AAD) zurückzuführen waren [6].

Das waren jedoch keinesfalls die einzigen Probleme bei Microsoft 365 und der Azure Cloud: Laut einer Studie von Sapio Research im Auftrag von Vectra AI [7] bei 1.112 IT-Sicherheitsentscheider*innen in Unternehmen, die Office 365 nutzen und mehr als tausend Mitarbeiter haben, können Angreifer*innen in den meisten Unternehmen Office-365-Konten übernehmen.

Anlass für die Studie war, dass Fernarbeit infolge der globalen Corona-Pandemie normal geworden ist und Unternehmen schnell in die Cloud gewechselt sind. Häufig wurde dabei zu Office 365 gewechselt. Mit 258 Millionen Benutzer*innen sind sie jedoch auch zu einem verlockenden Ziel für Cyberangriffe geworden. Demnach haben in den letzten 12 Monaten

  • 82% ein erhöhtes Sicherheitsrisikos ihres Unternehmens festgestellt
  • 70% Kontoübernahmen von autorisierten Benutzer*innen festgestellt, wobei durchschnittlich sieben Konten gekapert wurden
  • 58% eine größer werdende Kluft zwischen den Fähigkeiten von Angreifer*innen und Verteidiger*innen festgestellt.

Die meisten Befragten sehen mit der Verlagerung von Daten in die Cloud eine wachsende Bedrohung. Vor allem die Aufwände beim Absichern der Infrastruktur wurden zunächst unterschätzt.

Microsoft vs. Datenschutz

Schließlich fordern nun auch der Landesbeauftragte für Datenschutz in Mecklenburg-Vorpommern und der dortige Rechnungshof von der Landesregierung, ab sofort keine Microsoft-Produkte mehr zu verwenden:

»Betroffen sind davon unter anderem Produkte der Firma Microsoft. Eine rechtskonforme Nutzung dieser Produkte allein auf der Basis von Standarddatenschutzklauseln sei aber aufgrund der vom EuGH aufgestellten Grundsätze nicht möglich. Ohne weitere Sicherungsmaßnahmen würden personenbezogene Daten an Server mit Standort in den USA übermittelt.«

– Pressemitteilung des Landesbeauftragten für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern, 17.03.2021 [8]

Tatsächlich kommt diese Forderung jedoch nicht überraschend: Die Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder hat bereits 2015 auf diese Gefahren hingewiesen [9].

Folgerichtig schließt der Landesrechnungshof Mecklenburg-Vorpommern, dass nicht rechtskonform einzusetzende Software nicht wirtschaftlich betrieben werden kann.

Ausblick

Die Nachrichten der letzten Tage verdeutlichen, dass Microsoft weder sicher noch zuverlässig betrieben werden kann selbst wenn die Betriebskosten deutlich erhöht würden. Schlussendlich dürften die Microsoft-Services in Europa nicht rechtskonform zu nutzen sein. Mit OpenSource-Alternativen könnte wieder mehr Transparenz, Sicherheit und digitaler Souveränität erreicht werden. So begannen wir letztes Jahr, eine große deutsche Forschungseinrichtung bei den Alternativen zu Microsoft 365 zu beraten: Microsoft-Alternativen – Migration zu OpenSource-Technologien. Dabei ersetzen wir die Microsoft-Produkte schrittweise, über mehrere Jahre hinweg, durch OpenSource-Produkte.

Update: 13. April 2021

Es gibt schon wieder Schwachstellen in Microsoft Exchange Server, für die Microsoft im Rahmen ihres Patchdays auch Updates für Exchange Server veröffentlicht hat [10]. Dieses solte unverzüglich eingespielt werden. Das BSI wertet dies als eine Sicherheitslücke mit verstärkter Beobachtung von Auffälligkeiten unter temporärer Beeinträchtigung des Regelbetriebs [11].

Update: 23. Juli 2021

In der Pressemitteilung äußert sich die Landesbeauftragte für den Datenschutz Niedersachsen, Barbara Thiel, weeiterhin kritisch zum Einsatz von Microsoft 365:

»Wir haben bislang keine entsprechende Anordnung oder Untersagung ausgesprochen, Richtig ist allerdings, dass wir den Einsatz dieser Produkte als sehr kritisch einschätzen. … Aufgrund der beschriebenen Gesamtsituation kann ich von einem Einsatz von Office 365 nachwie vor aus datenschutzrechtlicher Sicht nur dringend abraten.«

– Pressemitteilung der Landesbeauftragten für den Datenschutz Niedersachsen, Barbara Thiel, 22.07.2021 [12]

Rust für Kryptografie

Die Programmiersprache Rust [1] wird immer populärer und wird zunehmend zur Kryptografie eingesetzt. Für Rust spricht, dass die Sprache eine sehr sichere Speicherverwaltung verspricht, wodurch Fehler wie Pufferüberläufe und use after free unwahrscheinlicher werden. Angesichts der einer der bekanntesten TLS-Schwachstellen, dem OpenSSL Heartbleed-Bug [2], der die Speichersicherheit verletzt, ist diese Entwicklung nicht überraschend.

So wurde vor Kurzem für die curl-Bibliothek ein neues TLS-Backend mit Rustls [3] angekündigt [4]. Auch Hyper [5], eine in Rust geschriebene HTTP-Bibliothek, soll als Backend für Curl bereitgestellt werden [6].

Auch die Internet Security Research Group (ISRG) [7] kündigte an, dass sie ein Rust-basiertes TLS-Modul für den Apache-Webserver unterstützen werden [8]. Finanziert wird dies im Rahmen der Bemühungen von Google und der ISRG, Portierungen kritischer Open-Source-Software in speichersichere Sprachen zu überführen [9].

Der Umzug des Kryptographie-Pakets von Python führte jedoch zu heftigen Diskussionen un der Community, da vor allem einige ältere Plattformen ohne Rust-Compiler nicht mehr unterstützt würden [10]. Das cryptography [11]-Projekt hat bereits begonnen, Teile seines ASN1-Parsing-Codes in Rust zu reimplementieren, [12] [13] da ASN1-Parser in der Vergangenheit häufig Schwachstellen bei der Speichersicherheit aufwiesen.


[1]Rust
[2]The Heartbleed Bug
[3]Rustls
[4]curl supports rustls
[5]Hyper
[6]Rust in curl with hyper
[7]Internet Security Research Group
[8]A Memory Safe TLS Module for the Apache HTTP Server
[9]Google Security Blog: Mitigating Memory Safety Issues in Open Source Software
[10]Dependency on rust removes support for a number of platforms #5771
[11]github.com/pyca/cryptography
[12]Port a tiny tiny bit of the ASN.1 parsing to Rust
[13]Rust in pyca/cryptography

»Vertrauen ist das neue Öl« in iX 03/2021

Wie können in Zeiten von Big Data Entwickler und Betreiber von Software das Vertrauen der Nutzer*innen gewinnen?

Dies ist die zentrale Frage dieses Artikels [1].

Kein Wachstum ohne Vertrauen

Die International Data Corporation (IDC) beschäftigte sich in ihrem European Data Market Monitoring Tool Report [2] mit der Frage, welche Auswirkungen ein Klima des Vertrauens auf die euroopäische Datenwirtschaft hat. Sie bilden drei unterschiedliche Szenarien ab, wobei sie als bedeutendsten Faktor die politischen Rahmenbedingungen, genauer Datenschutz und Privatsphäre, den gemeinsamen digitale Markt und Offenheit, Standardisierung und Interoperabilität von Daten sehen. Sie erwarten das größte Wachstum bei einer weltweit gültigen DSGVO. So wird klar: Nicht die Daten sind das Öl des digitalen Zeitalters, nein, es ist das Vertrauen.

Einschneidend – die Corona-Warn-App

Als mit der Coronapandemie die Bundesregierung und das Robert-Koch-Institut die Einführung einer Contact-Tracing-App beschlossen, rückte der Datenschutz in das Bewusstsein der breiten Bevölkerung: viele fürchteten, als COVID-19-Patienten stigmatisiert zu werden, wenn diese Information an staatliche Stellen weitergegeben würde. Ein verbreitetes Misstrauen der Bevölkerung gegen die Corona-Warn-App hätte den Erfolg der Maßnahme im Keim erstickt. Denn um Ansteckungsketten wirksam zu unterbrechen, müssen möglichst viele Menschen eine Tracing-App benutzen. So stellte sich plätzlich eine völlig neue Frage: Wie können wir die Software so gestalten, dass ausreichend viele Menschen der App vertrauen und sie tagtäglich benutzen?

Im April veröffentlichte der Chaos Computer Club zehn Prüfsteine für die Beurteilung von Contact-Tracing-Apps [3]. Zu den gesellschaftlichen Anforderungen gehören für den CCC Zweckgebundenheit, Freiwilligkeit und Diskriminierungsfreiheit, die Wahrung der Privatsphäre sowie Transparenz und Prüfbarkeit. Die technischen Anforderungen sind der Verzicht auf eine zentrale Entität, der vertraut werden muss, Datensparsamkeit, Anonymität, keine Verkettung mit persönlichen Daten, Bewegungs- und Kontaktprofilen sowie die Vertraulichkeit der Kommunikation. Bundesregierung und RKI taten das einzig Richtige: sie hörten auf den Rat der Datenschützer und entschieden sich – entgegen der ursprünglichen Planung – für ein solches dezentrales und anonymes Verfahren. Das Vertrauen in die Corona-Warn-App endet erwartungsgemäß an den Grenzen der Betriebssysteme. Wer die technische Infrastruktur kontrolliert, hat die Macht. Und es erscheint immer noch fragwürdig, ob und wie europäische Datenschutzstandards jemals gegenüber den US-Konzernen durchgesetzt werden können.

Transparenz und Offenheit

Um in informierter Weise beurteilen zu können, ob ein Programm seinen Zweck erfüllt und keine versteckten Funktionen besitzt, muss der Quellcode öffentlich zugänglich sein. Um volle Transparenz zu gewährleisten, muss nicht nur der Quellcode des Programms öffentlich einsehbar sein, sondern auch sämtliche Bibliotheken, Protokolle und Schnittstellen, die ein Programm nutzt. Die gesamte Softwarearchitektur sollte dazu auf dem Open-Source-Modell aufbauen.

Privacy by Design, Dezentralität und Datenhoheit

Wenn die ersten beiden Forderungen erfüllt sind, kann die Öffentlichkeit entscheiden, ob ein Softwaresystem Privacy by Design bietet oder nicht. Eine vertrauenswürdige Software muss von Anfang an die Privatsphäre der Nutzer*innen schützen.

Kein blindes Vertrauen mehr

Jahrzehntelang haben die Nutzer*innen Software-Herstellern und Dienste-Anbietern blind vertraut. Dies ist heute anders:

Software muss sich unser Vertrauen verdienen. Die Zukunft gehört deshalb den transparenten Open-Source-Entwicklungsmodellen, die Privacy by Design und umfassenden Datenschutz gewährleisten.

– Veit Schiele, Gründer und Geschäftsführer der Cusy GmbH


[1]iX 03/2021: Vertrauen ist das neue Öl – Consent Management in der Softwareentwicklung
[2]IDC: How the power of data will drive EU economy. The European Data MarketMonitoring Tool Report
[3]CCC: 10 Prüfsteine für die Beurteilung von „Contact Tracing“-Apps

GitLab Compliance-Features

GitLab kann so konfiguriert werden, dass eine Instanz allgemeine Compliance-Standards sicherstellt.
SSH-Schlüssel
Die Mindestanforderungen an SSH-Schlüssel kann auf Instanz-Ebene festgelegt werden.
Feingranulare Benutzerrollen und flexible Berechtigungen

Die Berechtigungen können über fünf unterschiedliche Rollen verwaltet werden. Dabei kann die Zuordnung nicht nur für die Instanz, sondern auch für Gruppen und Projekte unterschiedlich vergeben werden. Die folgende Tabelle gibt einen Überblick über die wesentlichen Berechtigungen:

Aktion Gast Reporter Developer Maintainer Owner
Kommentieren
Code anzeigen
GitLab-Seiten anzeigen
Wiki-Seiten anzeigen
Job-Liste anzeigen
Job-Protokoll anzeigen
Aufgaben erstellen
Aufgaben zuweisen  
Reviewer zuweisen  
Label zuweisen  
Label verwalten  
Aufgaben sperren  
Issue-Tracker verwalten  
Commit-Status anzeigen  
Container-Registry anzeigen  
Environments anzeigen  
Liste der Merge-Requests anzeigen  
Merge-Request erstellen  
CI/CD-Analyse anzeigen  
Token verwalten      
Sicherheitsstufe wechseln        
Projekt verschieben        
Projekt umbenennen        
Projekt löschen        
Projekt archivieren        
Aufgaben löschen        
Pipelines löschen        
Deaktivieren von Benachrichtigungsmails        
Nutzungsbedingungen akzeptieren erzwingen
Das Akzeptieren der Nutzungsbedingungen kann instanzweit erzwungen werden.

GitLab als Qualitätsmanagementsystem für ISO 13485

Der internationale Standard ISO 13485 definiert die Erfordernisse für Design, Herstellung und Inverkehrbringen von Medizinprodukten. GitLab bietet viele Funktionen und Steuerelemente, die zur Erfüllung der Anforderungen nach ISO 13485 dienen können.

Note

Die auf dieser Website bereitgestellten Informationen dienen nur informativen Zwecken. Diese Informationen sind keine rechtlichen Hinweise. Sie sind nicht umfassend und gewährleisten für sich genommen noch nicht die Einhaltung der ISO 13485. Um ISO 13485-Compliance zu erlangen, empfehlen wir die Beratung durch Spezialist*innen.

Dokumentation erstellen und verwalten

Das GitLab Wiki kann als Dokumentationssystem verwendet werden. Wiki-Seiten können über eine benutzerfreundliche Weboberfläche oder Git für fortgeschrittene Benutzer*innen erstellt und verwaltet werden. Ein vollständiger Verlauf ist über die Versionsverwaltung mit Git gewährleistet.

Prozesse definieren und durchsetzen

GitLab bietet verschiedene Werkzeuge zum Durchsetzen von Prozessen, Standards, Überprüfungen und Genehmigungen:

  • Genehmigungen für Merge-Requests können verwendet werden um die Überprüfung von Änderungen vor dem Zusammenführen zu erzwingen.
  • Mit geschützten Entwicklungszweigen können Regeln zum Erstellen, Verschieben und Löschen festgelegt werden.
  • Das Anforderungsmanagement kann über Issues, Labels und Relationen strukturiert ermöglicht werden wobei die Prozesse nachvollziehbar durchgesetzt und überprüft werden können.

Softwarevalidierung nach ISO 13485

Für die Validierung der QM-Software müssen Verfahren zur Bewertung erstellt werden. GitLab erleichtert dies über Vorlagen, innerhalb der ihr Formulare und andere Dateien hochladen sowie Aufgabenlisten und vieles mehr erstellen könnt. Alle Aktionen, auch das Ändern der Beschreibung oder Kommentieren, werden protokolliert.

Aufgabenlisten und Kanban-Boards bieten eine einfache Möglichkeit zum Organisieren der Validierung.

IEC 62304-Compliance mit GitLab

Der internationale Standard IEC 62304 definiert die Anforderungen für den Lebenszyklus von Medizinproduktsoftware. Es schreibt Prozesse, Aktivitäten und Aufgaben vor, um die Sicherheit und Wirksamkeit eines Medizinprodukts durch einen umfassenden, risikobasierten Ansatz bei der Softwareentwicklung zu verbessern. Dabei kann GitLab als Plattform, die alle Werkzeuge von der Projektplanung bis zu Sicherheitstests bietet, gut zur Einhaltung der Anforderungen der IEC 62304 beitragen.

Note

Die auf dieser Website bereitgestellten Informationen dienen nur informativen Zwecken. Diese Informationen sind keine rechtlichen Hinweise. Sie sind nicht umfassend und gewährleisten für sich genommen noch nicht die Einhaltung der IEC 62304-Compliance. Um IEC 62304-Compliance zu erlangen, empfehlen wir die Beratung durch Spezialist*innen.

Prozesssteuerung

Softwareentwicklungspläne und -prozesse könnt ihr mit dem GitLab Wiki erstellten, verwalten und referenzieren. Es kann als umfassendes Dokumentationssystem verwendet werden um Eure Pläne und Prozesse nahtlos während des gesamten Lebenszyklus der Softwareentwicklung referenzieren und integrieren zu können.

Anforderungsmanagement

Für System-, Entwicklungs- und Kundenforderungen können Vorlagen erstellt und einfach in den Entwicklungsprozess einbezogen werden. Aufgabenlisten und Kanban-Boards bieten sowohl Developers wie auch Reviewers einfache Möglichkeiten, Aufgaben planen und nachverfolgen zu können.

Zur Durchsetzung von Anforderungen und Coding-Standards könnt ihr mit Merge Reuqests ein Genehmigungsverfahren verwenden, das nur berechtigten Prüfer*innen das Zusammenführen der gemachten Änderungen erlaubt. Mithilfe geschützter Zweige könnt ihr detaillierte Berechtigungen festlegen, wer wo Änderungen vornehmen darf.

GitLab als Service-Desk konfiguriert erlaubt die Interaktion mit Kund*innen und externen Stakeholdern um Feedback von ihnen zu erhalten und mit ihnen interagieren zu können.

Rückverfolgbarkeit

Die Rückverfolgung lässt sich über Labels und Relationen zwischen Problemen über den gesamten Lebenszyklus der Softwareentwicklung aufrechtzuerhalten. Labels erlauben nicht nur Aufgaben und Merge Requests erleichtern, auch kann durch Abonnieren einzelner Labels die Benachrichtigung gewährleistet werden.

Mit dem Aktivitätslog bleibt nachvollziehbar, wann welche Änderungen von wem vorgenommen wurden.

Risikomanagement

Jede Code-Änderung kann mit Statischer Code-Analyse automatisch auf Sicherheitslücken überprüft werden. Nach einem Scan wird direkt am Merge Request ein Bericht generiert, sodass die Rückverfolgbarkeit gewährleistet bleibt.

Wenn Risiken erkannt wurden, können die Bemühungen zur Beseitigung der Risiken mit Issues geplant und dokumentiert werden.

Compliance Management mit Gitlab

Ein Compliance Management System umfasst alle Maßnahmen, Strukturen und Prozesse, die regelkonform ausgeführt werden sollen. Mit GitLab lässt sich ein Compliance Management realisieren, das sich nahtlos in den Software-Entwicklungsprozess integriert und mit anderen Systemen verbunden werden kann. Dies erleichtert Teams, mit den sich ändernden Vorschriften und aufkommenden Risiken Schritt zu halten.

Im Einzelnen unterstützt GitLab

  • durch die Verwaltung von Regeln und Richtlinien
  • durch die Automatisierung von Compliance-Workflows
  • durch ein Audit-Management, das Aktivitäten protokolliert, Vorfälle identifiziert und die Einhaltung der Compliance-Regeln nachweist
  • durch ein Security-Management, das die Sicherheit des Quellcodes überprüft um Schwachstellen nachzuverfolgen und zu verwalten (→ DevSecOps).

Richtlinienverwaltung

Einzuhaltende Regeln und Richtlinien können definiert werden, sowohl interne Unternehmensrichtlinien als auch auf rechtlichen oder regulatorischen Rahmenbedingungen beruhende Richtlinien wie DSGVO, SOC2, PCI-DSS, SOX, HIPAA, ISO, COBIT, FedRAMP usw. GitLab stellt hierfür folgende Funktionen zur Verfügung:

Feingranulare Benutzerrollen und Berechtigungen
GitLab unterstützt fünf verschiedene Rollen mit unterschiedlichen Berechtigungen
Compliance-Einstellungen
Für verschiedene Projekte können unterschiedliche Compliance-Richtlinien festgelegt werden.
Inventar
Alle Aktionen werden inventarisiert.

Automatisieren der Compliance-Workflows

Sobald die Richtlinien und Regeln festgelegt sind, können die Prozesse automatisiert werden, z.B. durch

Projektvorlagen
Projektvorlagen mit bestimmten Prüfprotokollen und Prüfpfaden, wie z.B. bei HIPAA, können erstellt werden.
Projekt-Label
Je nach Richtlinie lassen sich unterschiedlich Label für Projekte und Aufgaben vordefinieren.

Audit-Management

Compliance-Audits erfordern die Nachvollziehbarkeit verschiedener Ereignisse wie z.B. Benutzeraktionen, Änderungen an den Berechtigungen oder Genehmigungen.


[1]ISO 19600:2014 Compliance management systems — Guidelines

Software-Reviews – rechtfertigt hochwertige Software höhere Kosten?

Über unseren gesamten Software-Entwicklungsprozess hinweg finden immer wieder Reviews statt, angefangen bei der Analyse von Anforderungen über die passende Software-Architektur bis hin zu Code- und Testing-Analysen. Wir führen für unsere Kundschaft jedoch auch Audits ihrer Software damit sie eine Einschätzung für Weiterentwicklung und Betrieb ihrer Software erhalten.

Welchen Nutzen haben Software-Reviews?

Software-Reviews führen zu deutlich weniger Fehlern. Laut einer Untersuchung an 12-Tsd. Projekten durch Capers Jones [1] reduzieren sich diese

  • bei Requirements Reviews um 20–50%
  • bei Top-level Design Reviews um 30–60%
  • bei detaillierten funktionellen Design Reviews um 30–65%
  • bei detaillierten logischen Design Reviews um 35–75%

Die Studie kommt zu dem Ergebnis:

Schlechte Code-Qualität ist bis zum Ende der Code-Phase billiger; danach ist hohe Qualität billiger.
Kosten über die Entwicklungsphasen Anforderung, Design, coding, Testing und Betrieb hinweg

Dabei geht die Studie noch von einem klassischen Wasserfall-Modell aus von Anforderungen über Software-Architektur zunächst zu Code, dann zu Tests und Betrieb. Bei agiler Software-Entwicklung wiederholt sich dieser Prozess jedoch in vielen Zyklen, sodass wir beim Entwickeln der Software die meiste Zeit damit verbringen, die vorhandene Code-Basis zu ändern oder zu ergänzen. Daher müssen wir nicht nur die Änderungsanforderungen verstehen sondern auch den bereits vorhandenen Code. EIne bessere Code-Qualität erleichtert uns, die Funktionen unserer Anwendung zu verstehen und zu erkennen, wie die Änderungen sinnvoll umgesetzt werden. Wenn Code gut in separate Module unterteilt ist, kann ich mir viel schneller einen Überblick verschaffen als bei einer großen monolithischen Code-Basis. Weiter kann ich bei einer klaren Benennung schneller verstehen, was verschiedene Teile des Codes bewirken ohne ins Detail gehen zu müssen. Je schneller ich den Code verstehe und die gewünschte Änderung umsetzen kann, umso weniger Zeit benötige ich für die Umsetzung. Verschärfend kommt hinzu, dass sich die Wahrscheinlichkeit erhöht, dass ich einen Fehler mache. Um solche Fehler zu finden und zu beheben geht weitere Zeit verloren. Diese zusätzlichen Zeitaufwände werden üblicherweise als technische Schulden verbucht.

Umgekehrt kann ich vielleicht einen schnellen Weg finden, um eine gewünschte Funktion bereitzustellen, die jedoch den über die vorhandenen Modulgrenzen hinausgeht. Eine solche quick and dirty-Implementierung erschwert jedoch in den kommenden Wochen und Monaten die Weiterentwicklung. Auch bei agiler Software-Entwicklung ohne angemessene Code-Qualität können die Fortschritte nur am Anfang schnell sein, je länger kein Review stattfindet umso zäher wird die Weiterentwicklung sein. In vielen Diskussionen mit erfahrenen Kolleg*innen war die Einschätzung, dass bereits nach wenigen Wochen regelmäßige Reviews und Refactorings zu einer höheren Produktivitiät führen.

Welche Review-Arten lösen welche Probleme?

Es gibt unterschiedliche Möglichkeiten ein Review durchzuführen. Diese sind abhängig vom Zeitpunkt und den Zielen des Reviews.

Die Norm IEEE 1028 [2] legt die folgenden fünf Review-Arten fest:

Walkthroughs
Mit dieser statischen Analysetechnik entwickeln wir Szenarien und machen Probeläufe um z.B. Anomalien in den Anforderungen sowie alternative Implementierungsmöglichkeiten zu finden. Sie dienen uns zum besseren Verständnis des Problems, sie müssen jedoch nicht zu einer Entscheidung führen.
Technische Reviews
Diese fachlichen Prüfungen führen wir durch, um z.B. in Diskussionen alternative Software-Architekturen zu bewerten, Fehler zu finden oder technische Probleme zu lösen und zu einer (Konsens-)Entscheidung zu kommen.
Inspektionen
Diese formale Review-Technik nutzen wir z.B. um schnell Widersprüche in den Anforderungen, falsche Modulzuordnungen, ähnliche Funktionen o.ä. zu finden und diese möglichst frühzeitig beseitigen zu können. Häufig führen wir solche Inspektionen beim Pair-Programming durch wodurch zusätzlich noch weniger erfahrene Entwickler*innen schnell und praktisch geschult werden.
Audits
Häufig erstellen wir vor der Inbetriebnahme einer Kundensoftware in den Betrieb eine Bewertung ihres Software-Produkts in Bezug auf Kriterien wie Walk-Through-Berichte, Software-Architektur, Code- und Security-Analyse sowie Testverfahren.
Management-Reviews
Diese systematische Bewertung von Entwicklungs- oder Beschaffungsprozessen verwenden wir um einen Überblick über den Projektfortschritt zu erhalten und mit etwaigen Zeitplänen abzugleichen.

Kundenstimmen

»Vielen Dank für die gute Arbeit. Wir sind sehr zufrieden mit dem Ergebnis!«

– Niklas Kohlgraf, Projektmanagement, pooliestudios GmbH

Meldet euch

Lasst euch noch heute zu Software-Reviews von cusy beraten:

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Ich rufe euch auch gerne zurück!

Jetzt anfragen


[1]Capers Jones: Software Quality in 2002: A Survey of the State of the Art
[2]IEEE Standard for Software Reviews and Audits 1028–2008

Atlassian stellt die Server-Produktreihe ein

Atlassian kündigte Mitte Oktober 2020 an, ihre Server-Produktreihe zum 2. Februar 2021 für die Produkte Jira, Confluence, Bitbucket und Bamboo vollständig einzustellen. Bestehende Server-Lizenzen sollen noch bis zum 2. Februar 2024 genutzt werden können wobei jedoch bezweifelt werden darf, dass Atlassian tatsächlich noch umfangreichen Support bis zum 2. Februar 2024 leisten wird.

Dabei wird die Produktreihe stufenweise auslaufen:

  • 2. Februar 2021: Server-Neulizenzen werden nicht mehr verkauft und Preiserhöhungen treten inkraft.
  • 2. Februar 2022: Up- und Downgrades werden nicht mehr möglich sein
  • 2. Februar 2023: App-Käufe für bestehende Server-Lizenzen werden nicht mehr möglich sein
  • 2. Februar 2024: Support-Ende

Während Atlassian die Migration in die Cloud empfiehlt, lehnen dies viele unserer Kunden aus geschäftlichen Anforderungen oder aus Datenschutzgründen ab. Wir analysieren mit unseren Kunden zusammen die Anforderungen an ihre bestehenden Jira-, Confluence-, Bitbucket- und Bamboo-Server und erarbeiten dann passende Migrationspläne, z.B. zu GitLab.

Meldet euch

Auch wenn ihr noch nicht Kunde von uns seid, berate Ich euch gerne und erstelle ein passgenaues Angebot für die Migration eurer Atlassian-Server.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Ich rufe euch auch gerne an!

Jetzt anfragen

Migration von Jenkins zu GitLab CI/CD

Unsere Erfahrung ist, dass Migrationen häufig sehr lange hinausgeschoben werden da sie keinen unmittelbaren Vorteil versprechen. Wenn die verwendeten Werkzeuge jedoch in die Jahre kommen und nicht mehr wirklich zu den neuen Anforderungen passen, häufen sich technische Schulden an, die ebenfalls die Weiterentwicklung gefährden.

Vorteile

Die Vorteile von GitLab CI/CD gegenüber Jenkins sind:

Nahtlose Integration
Das in GitLab integrierte CI/CD bietet einen vollständigen DevOps-Workflow, der sich nahtlos in das GitLab-Ökosystem einfügt.
Bessere Sichtbarkeit
Die bessere Integration führt auch zu mehr Transparenz über Pipelines und Projekte hinweg, sodass Teams fokusiert bleiben können.
Niedrigere Betriebskosten
Jenkins erfordert erhebliche Aufwände in Wartung und Konfiguration. GitLab hingegen bietet Code-Review und CI/CD in einer einzelnen Anwendungen.

Erste Schritte

Migrationen von Jenkins zu GitLab müssen jedoch nicht beängstigend sein. Viele Projekte wurden bereits von Jenkins zu GitLab CI/CD gewechselt, und es stehen etliche Hilfsmittel bereit um den Übergang zu erleichtern, z.B.:

  • Jenkins-Dateien in GitLab CI/CD ausführen

    Eine kurzfristige Lösung, die Teams bei der Migration von Jenkins auf GitLab CI/CD verwenden können, ist die Verwendung von Docker, um eine Jenkins-Datei in GitLab CI/CD auszuführen, während nach und nach die Syntax aktualisiert wird. Dies behebt zwar nicht die externen Abhängigkeiten, bietet jedoch bereits eine bessere Integration in das GitLab-Projekt.

  • Auto DevOps verwenden

    Möglicherweise kann Auto DevOps zum Erstellen, Testen und Bereitstellen Eurer Anwendungen verwendet werden, ohne dass eine spezielle Konfiguration erforderlich ist. Eine der aufwändigeren Aufgaben der Jenkins-Migration kann das Konvertieren der Pipelines von Groovy zu YAML sein; Auto DevOps bietet jedoch vordefinierte CI/CD-Konfigurationen, die in vielen Fällen eine passende Standard-Pipeline erstellen. Auto DevOps bietet weitere Funktionen wie Sicherheits-, Leistungs- und Codequalitätstests. Schließlich könnt ihr einfach die Vorlagen ändern wenn ihr weitere Anpassungen benötigt.

Best Practices

  • Fangt klein an!

    Die oben angegebenen Erste Schritte erlauben Euch, inkrementelle Änderungen vorzunehmen. So könnt ihr kontinuierlich Fortschritte in eurem Migrationsprojekt erzielen.

  • Nutzt die Werkzeuge effektiv!

    Mit Docker und Auto DevOps stehen Euch Werkzeuge zur Verfügung, die den Übergang vereinfachen.

  • Kommuniziert transparent und verständlich!

    Haltet das Team über den Migrationsprozess auf dem Laufenden und teilt den Projektfortschritt mit. Strebt auch klare Jobnamen an und gestaltet Eure Konfiguration so, dass sie einen möglichst guten Überblick gibt. Schreibt ggf. Kommentare für Variablen und schwer verständlichen Code.

Meldet euch

Ich berate euch gerne und erstelle ein passgenaues Angebot für die Migration eurer Jenkins-Pipeline zu GitLab CI/CD.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Ich rufe euch auch gerne an!

Jetzt anfragen

Auswahl der richtigen NoSQL-Datenbank

Relationale Datenbanken dominierten lange die Softwareindustrie und sind mit Mechanismen wie Redundanz, Transaktionskontrolle und Standardschnittstellen sehr ausgereift. Sie konnten jedoch zunächst nur mäßig auf höhere Anforderungen an Skalierbarkeit und Performance reagieren. So kam ab Anfang 2010 verstärkt der Begriff NoSQL auf um neuartige Datenbanken zu beschreiben, die diesen Anforderungen besser genügten.

NoSQL-Datenbanken sollten die folgenden Probleme lösen:

  • Überbrücken der internen Datenstruktur der Anwendung und der relationalen Datenstruktur der Datenbank
  • Abkehr von der Integration verschiedenster Datenstrukturen in ein einheitliches Datenmodell
  • Die wachsende Anzahl an Daten erforderte zunehmend Cluster zur Datenspeicherung

Aggregierte Datenmodelle

Die relationale Datenbankmodellierung unterscheidet sich erheblich von den Arten von Datenstrukturen, die Anwendungsentwickler verwenden. Die Verwendung der von Entwickler*innen modellierten Datenstrukturen zur Lösung verschiedener Problemdomänen hat zu einer Abkehr von der relationalen Modellierung hin zu aggregierten Modellen geführt. Der größte Teil davon wird von Domain Driven Design angetrieben. Ein Aggregat ist eine Sammlung von Daten, mit denen wir als Einheit interagieren. Diese Aggregate bilden die Grenzen für ACID-Operationen, wobei die Schlüsselwerte, Dokumente und Column Family als Formen einer aggregatorientierten Datenbank angesehen werden können.

Aggregate erleichtern der Datenbank die Verwaltung der Datenspeicherung auf einem Cluster, da sich die Dateneinheit jetzt auf jedem Computer befinden kann. Aggregatorientierte Datenbanken funktionieren am besten, wenn die meisten Dateninteraktionen mit demselben Aggregat durchgeführt werden, z.B. wenn ein Profil mit allen Details abgerufen werden muss. Es ist besser, das Profil als Aggregationsobjekt zu speichern, und diese Aggregate zu verwenden, um Profildetails abzurufen.

Distributionsmodelle

Aggregatorientierte Datenbanken erleichtern die Verteilung von Daten, da der Verteilungsmechanismus nur das Aggregat verschieben muss und sich nicht um verwandte Daten kümmern muss, da alle verwandten Daten im Aggregat selbst enthalten sind. Dabei gibt es im Wesentlichen zwei Arten der Datenverteilung:

Sharding
Sharding verteilt unterschiedliche Daten auf mehrere Server, sodass jeder Server als einzige Quelle für eine Teilmenge von Daten fungiert.
Replikation

Replikation kopiert Daten über mehrere Server hinweg, sodass jedes Datum an mehreren Stellen gefunden werden kann. Die Replikation erfolgt in zwei Formen:

Die Master-Slave-Replikation macht einen Knoten zur autorisierenden Kopie, die Schreibvorgänge verarbeitet, während Slaves mit dem Master synchronisiert werden und möglicherweise Lesevorgänge verarbeiten.

Die Peer-to-Peer-Replikation ermöglicht Schreibvorgänge auf jeden Knoten. Die Knoten koordinieren sich um ihre Kopien der Daten zu synchronisieren.

Die Master-Slave-Replikation verringert zwar die Wahrscheinlichkeit von Aktualisierungskonflikten, aber die Peer-to-Peer-Replikation vermeidet das Schreiben allerVorgänge auf einen einzelnen Server, wodurch ein einzelner Fehlerpunkt vermieden wird. Ein System kann eine oder beide Techniken verwenden.

CAP-Theorem

In verteilten Systemen sind die folgenden drei Aspekte wichtig:

  • Konsistenz (engl.: Consistency)
  • Verfügbarkeit (engl.: Availability)
  • Ausfalltoleranz (engl.: Partition tolerance)

Eric Brewer hat das CAP-Theorem aufgestellt, das besagt, dass wir in jedem verteilten System nur zwei der drei Optionen auswählen können. Viele NoSQL-Datenbanken versuchen, Optionen bereitzustellen, bei denen ein Setup gewählt werden kann, die Datenbank entsprechend dein Anforderungen aufzusetzen. Wenn ihr beispielsweise Riak als verteilte Schlüssel-Werte-Datenbank betrachtet, gibt es im Wesentlichen die drei Variablen

r
Anzahl der Knoten, die auf eine Leseanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
w
Anzahl der Knoten, die auf eine Schreibanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
n
Anzahl der Knoten, auf denen die Daten repliziert werden, auch Replikationsfaktor genannt

In einem Riak-Cluster mit 5 Knoten können wir die Werte für r, w und n so anpassen, dass das System sehr konsistent ist indem wir r = 5 und w = 5 setzen. Damit haben wir jedoch den Cluster für Netzwerkpartitionen anfällig gemacht, da kein Schreibvorgang möglich ist wenn nur ein Knoten nicht antwortet. Wir können denselben Cluster für Schreib- oder Lesevorgänge hoch verfügbar machen, indem wir r = 1 und w = 1 setzen. Jetzt kann jedoch die Konsistenz beeinträchtigt werden, da einige Knoten möglicherweise nicht über die neueste Kopie der Daten verfügen. Das CAP-Theorem besagt, dass ihr, wenn ihr eine Netzwerkpartition erhaltet, die Verfügbarkeit von Daten gegen die Konsistenz von Daten abwägen müsst. Auch die Haltbarkeit kann gegen die Latenz abgewogen werden, insbesondere wenn ihr Fehler mit replizierten Daten überstehen möchtet.

Häufig benötigtet ihr bei relationalen Datenbanken kaum ein Verständnis für diese Anforderungen; nun werden diese wieder wichtig. So dürftet ihr gewöhnt gewesen sein, in relationalen Datenbanken Transaktionen zu verwenden. In NoSQL-Datenbanken stehen euch diese jedoch nicht mehr zur Verfügung und ihr müsst selbst überlegen, wie diese implementiert werden sollen. Muss das Schreiben transaktionssicher sein? Oder ist es auch akzeptabel, dass mal Daten verlorengehen? Schließlich kann manchmal auch ein externer Transaktionsmanager wie ZooKeeper hilfreich sein.

Verschiedene Arten von NoSQL-Datenbanken

NoSQL-Datenbanken können grob in vier Typen eingeteilt werden:

Schlüssel-Werte-Datenbanken

Schlüssel-Werte-Datenbanken sind aus API-Sicht die einfachsten NoSQL-Datenspeicher. Der Client kann entweder den Wert für den Schlüssel abrufen, einen Wert für einen Schlüssel eingeben oder einen Schlüssel aus dem Datenspeicher löschen. Der Wert ist ein Blob, den der Datenspeicher nur speichert, ohne sich darum zu kümmern oder zu wissen, was sich darin befindet. Es liegt ausschließlich in der Verantwortung der Anwendung, zu verstehen, was gespeichert wurde. Da Schlüssel-Werte-Datenbanken immer den Primärschlüsselzugriff verwenden, weisen sie im Allgemeinen eine hohe Leistung auf und können leicht skaliert werden.

Einige der beliebtesten Schlüsselwertdatenbanken sind

Riak KV
Home | GitHub | Docs
Redis
Home | GitHub | Docs
Memcached
Home | GitHub | Docs
Berkeley DB
Home | GitHub | Docs
Upscaledb
Home | GitHub | C API Docs

Ihr müsst sie sorgfältig auswählen da es große Unterschiede zwischen ihnen gibt. Während Riak z.B. die Daten persistent speichert ist dies bei Memcached üblicherweise nicht der Fall.

Dokumentendatenbanken

Diese Datenbanken speichern und rufen Dokumente ab, bei denen es sich um XML, JSON, BSON usw. handeln kann. Diese Dokumente sind hierarchische Baumdatenstrukturen, die aus Karten, Sammlungen und Skalarwerten bestehen können. Dokumentendatenbanken bieten umfangreiche Abfragesprachen und Konstrukte wie Datenbanken, Indizes usw., die einen einfacheren Übergang von relationalen Datenbanken ermöglichen.

Einige der beliebtesten Dokumentendatenbanken sind

MongoDB
Home | GitHub | Docs
CouchDB
Home | GitHub | Docs
RavenDB
Home | GitHub | Docs
Elasticsearch
Home | GitHub | Docs
eXist
Home | GitHub | Docs

Column Family Stores

Diese Datenbanken speichern Daten in Column Families als Zeilen, die einem Zeilenschlüssel zugeordnet sind. Sie sind hervorragend geeignet für Gruppen verwandter Daten, auf die häufig zusammen zugegriffen wird. Dies können beispielsweise alle Profilinformationen einer Person sein, nicht jedoch deren Aktivitäten.

Zwar kann jede Column Family mit der Zeile in einer RDBMS-Tabelle verglichen werden, in dem der Schlüssel die Zeile identifiziert und die Zeile aus mehreren Spalten besteht; aber in Column Family Stores müssen die verschiedene Zeilen nicht dieselben Spalten haben.

Einige der beliebtesten Column Family Stores sind

Cassandra
Home | GitHub | Docs
HBase
Home | GitHub | Docs
Hypertable
Home | GitHub | Docs

Cassandra kann als schnell und einfach skalierbar beschrieben werden, da Schreibvorgänge über den Cluster verteilt sind. Der Cluster verfügt nicht über einen Masterknoten, sodass Lese- und Schreibvorgänge von jedem Knoten im Cluster ausgeführt werden können.

Graphdatenbank

In Graphdatenbanken könnt ihr Entitäten mit bestimmten Eigenschaften und Beziehungen zwischen diesen Entitäten speichern. Entitäten werden auch als Knoten bezeichnet. Stellt euch einen Knoten als Instanz eines Objekts in einer Anwendung vor; Beziehungen können dann als Kanten bezeichnet werden, die ebenfalls Eigenschaften haben können und gerichtet sind.

Graph-Modelle
Labeled-Property-Graph
In einem Labeled-Property-Graph können sowohl Knoten als auch Kanten Eigenschaften (engl.: Properties) besitzen.
Resource Description Framework (RDF)
Im RDF werden Graphen mit Hilfe von Triplen repräsentiert. Ein Triple besteht aus drei Elementen in der Form Knoten-Kante-Knoten Subjekt --Prädikat-> Objekt, die als Ressourcen in Form einer weltweit eindeutigen URI oder als anonyme Ressource definiert werden. Um innerhalb einer Datenbank verschiedene Graphen verwalten zu können, werden diese als Quads gespeichert wobei ein Quad jedes Triple um eine Referenz auf den zugehörigen Graphen erweitert. Aufbauend auf RDF wurde mit RDF-Schema ein Vokabular entwickelt, um schwache Ontologien zu formalisieren und darüber hinaus mit der Web Ontology Language auch vollständig entscheidbare Ontologien beschreiben.
Algorithmen

Wichtige Algorithmen zur Abfrage von Knoten und Kanten sind:

Breitensuche, Tiefensuche
Breitensuche (engl.: breadth-first search, BFS) ist ein Verfahren zum Durchlaufen der Knoten eines Graphen verwendet. Im Gegensatz zur Tiefensuche (engl.: depth-first search, DFS) werden zunächst alle Knoten beschritten, die vom Ausgangsknoten direkt erreichbar sind. Erst danach werden Folgeknoten beschritten.
Kürzester Pfad
Pfad zwischen zwei unterschiedlichen Knoten eines Graphen, welcher minimale Länge bezüglich einer Kantengewichtsfunktion hat.
Eigenvektor
In der linearen Algebra ein vom Nullvektor verschiedener Vektor, dessen Richtung durch die Abbildung nicht verändert wird. Ein Eigenvektor wird also nur skaliert und der Skalierungsfaktor wird als Eigenwert der Abbildung bezeichnet.
Abfragesprachen
Blueprints
eine Java-API für Eigenschaftsgraphen, die zusammen mit verschiedenen Graphdatenbanken verwendet werden kann.
Cypher
eine Abfragesprache entwickelt von Neo4j.
GraphQL
eine SQL-artige Abfragesprache
Gremlin
eine Open-Source-Graphen-Programmiersprache, die mit verschiedenen Graphdatenbanken (Neo4j, OrientDB) genutzt werden kann.
SPARQL
vom W3C spezifizierte Abfragesprache für RDF-Datenmodelle.
Abgrenzung zu relationalen Datenbanken

Wenn wir Graphen in relationalen Datenbanken speichern wollen, geschieht dies meist nur für spezifische Bedingungen, z.B. für die Beziehungen zwischen Menschen. Das Hinzufügen weiterer Beziehungsarten ist dann normalerweise mit vielen Schemaänderungen verbunden.

In Graphdatenbanken ist das Durchlaufen der Verknüpfungen oder Beziehungen sehr schnell, da die Beziehung zwischen Knoten nicht erst zur Abfragezeit berechnet werden muss.

Einige der beliebtesten Graphdatenbanken sind

Neo4j
Home | GitHub | Docs
InfiniteGraph
Home

Auswahl der NoSQL-Datenbank

Allen NoSQL-Datenbanken ist gemein, dass sie kein bestimmtes Schema erzwingen. Im Gegensatz zu relationalen Datenbanken mit starkem Schema müssen Schemaänderungen nicht zusammen mit dem Quellcode, der auf diese Änderungen zugreift, gespeichert werden. Schemalose Datenbanken können Änderungen im implizierten Schema tolerieren, sodass sie keine Downtime zur Migration benötigen; sie sind daher vor allem bei Systemen, die 24/7 zur Verfügung stehen sollen, sehr beliebt.

Wie wählen wir nun aber unter so vielen NoSQL-Datenbanken die richtige aus? Im Folgenden können wir Ihnen nur einige allgemeine Kriterien nennen:

Schlüssel-Werte-Datenbanken
sind im Allgemeinen nützlich zum Speichern von Sessions, Benutzerprofilen und Einstellungen. Wenn jedoch Beziehungen zwischen den gespeicherten Daten abgefragt oder mehrere Schlüssel gleichzeitig bearbeitet werden sollen, würden wir Schlüsselwertdatenbanken vermeiden.
Dokumentendatenbanken
sind im Allgemeinen nützlich für Content-Management-Systeme und E-Commerce-Anwendungen. Wir würden die Verwendung von Dokumentdatenbanken jedoch vermeiden, wenn komplexe Transaktionen benötigt odermehrere Vorgänge oder Abfragen für unterschiedliche Aggregatstrukturen gestellt werden sollen.
Column Family Stores
sind im Allgemeinen nützlich für Content-Management-Systeme und für hohe Schreibvolumen wie z.B. bei der Protokollaggregation. Wir würden die Verwendung von Datenbanken für Column Family Stores vermeiden, die sich in der frühen Entwicklung befinden und deren Abfragemuster sich noch ändern können.
Graphdatenbanken
eignen sich sehr gut für Problembereiche, in denen wir Daten wie soziale Netzwerke, Geodaten, Routing-Informationen sowie Empfehlungssystem miteinander verbunden werden sollen.

Fazit

Der Aufstieg der NoSQL-Datenbanken führte nicht zum Niedergang der relationalen Datenbanken. Sie können gut nebeneinander existieren. Häufig werden unterschiedliche Datenspeichertechnologien verwendet um die Daten passend zu ihrer Struktur und erforderlichen Abfrage zu speichern.

Microsoft-Alternativen – Migration zu OpenSource-Technologien

Für eine große deutsche Forschungsgesellschaft entwickeln wir eine Migrationsstrategie von Microsoft 365 zu OpenSource-Technologien. Dabei geht es einerseits darum, die digitale Sourveränität zurückzuerhalten und andererseits erhöhte Sicherheitsanforderungen zu erfüllen. Dies soll nun unter Verwendung freier und quelloffener Software (FLOSS) erreicht werden. Insgesamt ähnelt das Projekt dem Microsoft Alternatives-Projekt (MAlt) des CERN und dem Projekt Phoenix von Dataport.

Die Grundsätze des Projekts sind:

  • Allen Mitarbeiter*innen soll der gleiche Service geboten werden
  • Vendor lock-ins sollen vermieden werden um das Risiko der Abhängigkeit zu verringern
  • Die Daten sollen weitestgehend im Besitz der Forschungsgesellschaft bleiben

Pläne für 2021

Für 2021 ist geplant, für viele Services und Dienstleistungen alternative Lösungen zu evaluieren sowie Prototypen und Pilotprojekte zu veröffentlichen.

Produktgruppe Service Product to evaluate Status
Identitäts- und Zugriffsmanagement LDAP OpenLDAP 🏭 Produktion
Personal Information Management E-Mail Zimbra 🚦 Evaluation
Kalender Zimbra 🚦 Evaluation
Kontakte Zimbra 🚦 Evaluation
Kollaboration Dateiaustausch NextCloud 🏭 Produktion
Office-Integration NextCloud 🚦 Evaluation
Direktnachrichten/ Chat Mattermost 🏭 Produktion
Videokonferenzen Jitsi Meet 🏭 Produktion
Suche Suchmaschine OpenSearch 🚦 Evaluation
Frontend/ Visualisierung OpenSearch Dashboards 🚦 Evaluation
Authentifizierung/ Zugriffskontrolle Open Distro Security 🚦 Evaluation
Nächste-Nachbarn Klassifikation Open Distro KNN 🚦 Evaluation
Projektmanagement Aufgaben/Meilensteine GitLab 🚦 Evaluation
Zeiterfassung gitlabtime 🚦 Evaluation
Dokumentation GitLab Wiki 🚦 Evaluation
Compliance-Management Richtlinienverwaltung, Audit-Management GitLab Compliance Management 🚦 Evaluation
Forschungssoftware [1], [2] Paketmanager Spack 🏭 Produktion
IDE JupyterHub 🏭 Produktion
Entwicklungsumgebungen Jupyter Kernels 🏭 Produktion
Software-Versionierung Git 🏭 Produktion
Datenversionierung DVC 🏭 Produktion
Erhebung und Speicherung von Daten Intake 🛫 Pilot
Tabellenkalkulation ipysheet 🏭 Produktion
Geodaten PostGIS 🏭 Produktion
Kartographische Daten OpenStreetMap 🏭 Produktion
DevOps GitLab CI/CD Pipeline 🛫 Pilot
Dokumentation Sphinx 🏭 Produktion

Hosting-Strategie

Innerhalb der Forschungsgesellschaft gibt es im wesentlichen drei verschiedene Hosting-Varianten:

Gesellschaftsweite Infrastruktur
Infrastruktur, die institutsübergreifend von einem Großteil der Forschungsprojekte und Verwaltungen genutzt wird, soll von der zentralen IT der Forschungsgesellschaft bereitgestellt werden.
Institutsweite Infrastruktur
Infrastruktur, die für die speziellen Forschungsbereiche eines Instituts benötigt werden oder die IT-Unterstützung vor-Ort benötigen, sollen von der IT des jeweiligen Instituts bereitgestellt werden.
Betriebs- und Georedundanz
Diese werden im Wesentlichen durch Institutskooperationen oder durch Kooperationen einzelner Institute mit der IT der Forschungsgesellschaft hergestellt. Technologisch werden hierfür Floating IPs und das Virtual Router Redundancy Protocol (VRRP) verwendet wobei die Entscheidungen auf Basis von BGP-Announcements getroffen werden.

[1]

Für die Infrastruktur, auf der die Forschungssoftware entwickelt wird, gibt es ausführliche Dokumentationen, die unter der BSD-3-Clause-Lizenz veröffentlicht sind:

[2]Hier stellt das geplante einheitliche API eine deutliche Vereinfachung dar; siehe auch Announcing the Consortium for Python Data API Standards.

»Versionskontrolle für Machine-Learning-Projekte« in Informatik Aktuell vom 11. August 2020

Cusy schreibt in Informatik Aktuell in loser Reihe Artikel über Data Science Workflows. Als erster Beitrag ist nun Versionskontrolle für Machine-Learning-Projekte am 11. August 2020 erschienen.

In diesem Artikel erfahrt ihr, wie die Modellentwicklung für maschinelles Lernen (ML) systematisch organisiert werden kann. So kann die Leistung eines Modells verbessert werden, wenn ihr die Parameter feiner abgestimmt oder wenn mehr Trainingsdaten verfügbar werden. Um die Verbesserung messen zu können, sollte nachverfolgt werden können, welche Daten für das Training in welcher Modelldefinition und -konfiguration (Parameter etc.) verwendet und welche Modellleistungen damit erzielt wurden. Dabei werden sowohl die Daten wie auch der zugehörige Programmcode in einer Version erfasst werden.

DVC-Workflow

DVC-Workflow

Anhand eines Beispielprojekts führt der Artikel durch die folgenden Phasen:

  1. Repositories erstellen
  2. Datenpipelines definieren
  3. Reproduzieren
  4. Pipeline visualisieren
  5. Daten teilen

Unser Fazit ist ,dass mit DVC sprachunabhängig reproduzierbare ML-Pipelines definiert und zusammen mit den zugehörigen Trainingsdaten, Konfigurationen, Leistungsmetriken usw. versioniert gespeichert werden können. Dabei arbeitet DVC mit allen modernen Versionsverwaltungen zusammen und unterstützt viele verschiedene Speicherarten wie S3, Google Cloud, Azure, SSH usw. DVC strukturiert so nicht nur die Datenhaltung, sondern durch einzelne, atomare Phasen der DVC-Pipeline bleiben Änderungen in den Daten auch transparent und nachvollziehbar. Insgesamt erleichtert und effektiviert dies die Arbeit an ML-Projekten erheblich.

EuGH kippt Privacy Shield

Paukenschlag mit Ansage

Während der Uraufführung der Symphonie Nr. 94 im Jahr 1792 weckte Haydn das verwöhnte Londoner Publikum im Andante des zweiten Satzes an einer besonders leisen Stelle mit einem lauten Paukenschlag plötzlich aus seinem Dämmerschlaf. Seitdem trägt das Musikstück den Beinamen ›Paukenschlagsymphonie‹.

Musikliebhaber, die heute in ein Haydn-Konzert gehen, sind natürlich vorbereitet, sodass der Effekt verpufft. Überraschungsmomente in der Kunst nutzen sich schnell ab. In der IT-Branche ist das offensichtlich nicht so, denn der Paukenschlag, mit dem der EuGH kürzlich das Privacy Shield kippte, scheint Politik und Wirtschaft völlig unvorbereitet getroffen zu haben. Dabei hat es schon einmal geknallt, als das oberste europäische Gericht vor fünf Jahren den Vorgänger vom Privacy Shield, das Safe-Harbour-Abkommen, für ungültig erklärt hatte.

Der neue Paukenschlag kam mit langer Ansage. Denn als am 12. Juli 2016 Privacy Shield in Kraft trat, warnten Datenschützer davor, sich auf dieses Abkommen zu verlassen. Im Cusy-Blog schlossen wir uns damals den Bedenken der Datenschützer an: »Man kann also davon ausgehen, dass Datenschützer auch gegen ›Privacy Shield‹ vor dem Europäischen Gerichtshof klagen werden. Eine dauerhafte Rechtssicherheit für Unternehmen, die personenbezogene Daten in die USA transferieren, zeichnet sich erst einmal nicht ab.«

Standardvertragsklauseln keine sichere Alternative

Während der EuGH den Privacy-Shield ins Nirwana beförderte, stellte er im gleichen Urteil fest, »dass die Prüfung des Beschlusses 2010/87 über Standardvertragsklauseln anhand der Charta der Grundrechte der Europäischen Union nichts ergeben hat, was seine Gültigkeit berühren könnte.« Unternehmen, die Daten ihrer Kunden in die USA transferieren, können also mit ihren Geschäftspartnern auch weiterhin Standardvertragsklauseln abschließen.

Allerdings, so betont Dr. Ingemar Kartheuser in der Legal Tribune Online, könnten die betroffenen Kunden und Mitarbeiter dieser Unternehmen »sich im Zweifelsfall an die zuständige lokale Datenschutzbehörde wenden, die unter Umständen US-Datentransfer des betreffenden Unternehmens untersagen könnte.« Susanne Dehmel aus der Bitkom-Geschäftsleitung befürchtet laut Spiegel Online sogar, dass die Praxis der Standardvertragsklauseln ins Wanken gerät.

Rechtssicherheit gibt es nur, wenn persönliche Daten in Europa bleiben

Allerorten wird nun die Rechtsunsicherheit beklagt, die sich für deutsche Unternehmen aus dem Urteil ergeben. Dabei ist eine solide und nachhaltige Lösung dieser Frage offensichtlich und naheliegend. Die Daten europäischer Bürger sollten in europäischen Rechenzentren gespeichert werden, solange ihre Verarbeitung in den USA (z.B. bei der Buchung eines Hotels) nicht zwingend erforderlich ist.

Der dritte Paukenschlag in ein paar Jahren sollte jedenfalls niemanden mehr überraschen. Ganz egal, unter welchem klingenden Namen die EU-Kommission einen Nachfolger für den Nachfolger aus dem Hut zaubert, ihn wird das gleiche Schicksal ereilen wie Safe Harbour und Privacy Shield, denn die grundsätzlichen Auffassungen von Datenschutz klaffen diesseits und jenseits des Atlantiks immer noch weit auseinander.

In der Politik scheint diese Erkenntnis auch langsam angekommen zu sein. So empfiehlt Bundesjustizministerin Christine Lambrecht, wie Spiegel Online berichtet, europäischen Unternehmen, Daten europäischer Bürger auf europäischen Servern zu speichern.

Update 24. August 2020

Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden Württemberg hat heute die Orientierungshilfe: Was jetzt in Sachen internationaler Datentransfer? (LfDI-BW-Orientierungshilfe-zu-Schrems-II.pdf) vorgelegt:

Im Zentrum des weiteren Vorgehens des LfDI Baden-Württemberg wird die Frage stehen, ob es neben dem von Ihnen gewählten Dienstleister/Vertragspartner nicht auch zumutbare Alternativangebote ohne Transferproblematik gibt.

Entwickler-Tools as a Service – datenschutzkonform aus Deutschland

Da durch moderne DevOps-Methoden Entwicklung und Betrieb immer enger zusammenwachsen, ist es ratsam, nicht erst im Produktivbetrieb von Software über den Datenschutz nachzudenken, sondern die gesamte agile Entwicklungs-Pipeline datenschutzkonform aufzustellen.

Cusy bietet seiner Kundschaft eine datenschutzkonforme Entwicklungs- und Betriebsplattform für den gesamten Lebenszyklus ihrer Anwendungen. Die Plattform ist modular aufgebaut, ermöglicht Privacy by Design und lässt sich flexibel skalieren. Agile Softwareteams profitieren von einer sofort einsetzbaren, vollständigen Tool-Chain: vom ersten Entwurf über das Projektmanagement und die Code-Verwaltung bis hin zum Deployment und dem Produktivbetrieb. Alle Daten, sowohl personenbezogene Daten von Kunden und Mitarbeitern als auch Geschäftsgeheimnisse, werden sicher und zuverlässig in einem deutschen Rechenzentrum gespeichert.

Cusy DevOps Toolchain

Cusy DevOps Toolchain

Meldet euch

Lasst euch noch heute bei der datenschutzkonformen Ausrichtung eurer IT von cusy beraten, damit ihr seelenruhig abwarten könnt, wie die Konkurrenz auch beim dritten Paukenschlag noch heftig zusammenzuckt.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Wir rufen euch auch gerne an!

Jetzt anfragen

Corona-Warn-App und Datenbank-Sicherheit

Alvar Freude hat sich den Datenbank-Code der Corona-Warn-App mal genauer angeschaut. Dieser zeigt beispielhaft, was bei vielen Datenbank-Projekten schieflaufen kann. Darüberhinaus zeigt er auch, wie wir selbst solche Fehler vermeiden können.

Alvar Freude ist Referent für technischen Datenschutz und Informationsfreiheit beim LfDI Baden-Württemberg. Zudem ist er Autor u.a. von PostgreSQL Secure Monitoring (Posemo) und TLS-Check. Er analysierte den Datenbank-Code des corona-warn-app Server und veröffentlichte seine Erkenntnisse auf Twitter.

Im Folgenden sind hier seine Tweets nochmal zusammengefasst und ergänzt:

Datenbank-Berechtigungen

Eines der wesentlichen Ergebnisse ist, dass die Datenbank-Berechtigungen viel zu weitgehend sind, und ein erfolgreicher Angreifer auf alle Daten zugreifen, diese löschen usw. könnte. Den Einwand, dass ein Angreifer nie soweit kommen dürfe widerlegt er mit der Erfahrung, dass dies leider immer wieder passiere.

Das PostgreSQL-Login per Superuser postgres sollte daher immer nur über Unix-Domain-Sockets und über localhost erlaubt sein. Der Zugang mit Peer-Authentifizierung in der pg_hba.conf-Datei ist hingegen ok:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer
host    all             all             10.23.42.1/24           scram-sha-256

Da die Anwendung einen Datenbank-Superuser erhält, jedoch keine Datenbank konfiguriert wird, wird diese wohl automatisch angelegt. Dies hieße jedoch, dass der Prozess als Superuser ausgeführt werden müsste – eine ganz schlechte Idee. Die Datenbank sollte vom DBA mit Superuser-Rechten angelegt und anschließend so konfiguriert werden, dass sich nicht jeder (PUBLIC) damit verbinden kann:

CREATE DATABASE cwa;
REVOKE ALL ON cwa FROM PUBLIC;

Damit kann sich nur noch der Superuser mit der Datenbank cwa verbinden.

Falls eine Tabelle, wie z.B. V1__createTables.sql jedoch zunächst normal angelegt wurde, d.h. PUBLIC alle Rechte hat, sollten diese entzogen werden mit:

REVOKE ALL ON diagnosis_key FROM PUBLIC;
REVOKE ALL ON diagnosis_key FROM current_user;

Anschließend könnt ihr eine Rolle cwa_users mit den beiden Nutzern cwa_reader und cwa_inserter erstellen um zwischen lesenden und schreibenden Zugriffen unterscheiden zu können:

CREATE ROLE cwa_users;
CREATE USER cwa_reader IN ROLE cwa_users PASSWORD '…';
CREATE USER cwa_inserter IN ROLE cwa_users  PASSWORD '…';

Nun erhält die Rolle cwa_users zunächst CONNECT-Rechte und dann cwa_reader Lese- und cwa_inserter Hinzufügen-Rechte:

GRANT CONNECT ON DATABASE to cwa_users;
GRANT SELECT ON diagnosis_key TO cwa_reader;
GRANT INSERT ON diagnosis_key TO cwa_inserter;

Der cwa_reader-User kann jedoch damit zunächst alle Daten auf einmal lesen. Da dies jedoch nicht erforderlich ist, kann dieser Angriffspunkt durch eine Funktion beschnitten werden:

CREATE OR REPLACE FUNCTION get_key_data(in_id UUID)
    RETURNS JSONB
    AS 'SELECT key_data FROM diagnosis_key WHERE id = in_id;'
    LANGUAGE sql SECURITY DEFINER SET search_path = :schema, pg_temp;

Anschließend wird die Funktion cwa_owner zugewiesen, cwa_reader und cwa_inserter die Berechtigungen entzogen und schließlich die Ausführung der Funktion cwa_reader erlaubt:

ALTER FUNCTION get_key_data(UUID) OWNER TO cwa_owner;
REVOKE ALL ON FUNCTION get_key_dataUUID) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION get_key_data(UUID) TO cwa_reader;

Damit kann cwa_reader also nur noch einen einzelnen Datensatz lesen.

Passwörter speichern

Auch die in .env genannten Standardpasswörter haben für Alvar Freude gute Chancen, auch in der Produktion erhalten zu bleiben.

Daher sollten beim Anlegen der Users sichere Passwörter vergeben werden, die anschließend in Vault oder ähnlichem gespeichert werden sollten.

id

Interessant in der Tabellen-Definition ist auch, dass die id als bigserial realisiert ist. Eine hochzählende Zahl könnte jedoch von Angreifern erraten werden. Daher dürfte der UUIDv4-Datentyp besser geeignet sein. Zur UUIDv4-Generierung kommt entweder die uuid-ossp-Erweiterung oder für PostgreSQL≥9.4 auch die pgcrypto-Erweiterung infrage, also entweder:

CREATE EXTENSION "uuid-ossp";
CREATE TABLE diagnosis_key (
  id uuid primary key default uuid_generate_v4() NOT NULL,
  …
);

oder:

CREATE EXTENSION "pgcrypto";
CREATE TABLE diagnosis_key (
  id uuid primary key default gen_random_uuid() NOT NULL,
  …
);

Zeitstempel

In der Tabellen-Definition von V1__createTables.sql werden Datum und Zeit in submission_timestamp als bigint, also als Zahl, gespeichert, und dies obwohl es auch einen TIMESTAMP-Datentyp gibt. Dies hätte den Vorteil, dass mit ihnen auch gerechnet werden kann, also z.B.:

SELECT age(submission_timestamp);
SELECT submission_timestamp - '1 day'::interval;

Außerdem könnten die Daten nach einer bestimmten Zeit gelöscht werden, z.B. nach dreißig Tagen mit:

DELETE FROM diagnosis_key WHERE age(submission_timestamp) > 30;

Das Löschen kann noch beschleunigt werden, wenn für jeden Tag mit der PostgreSQL-Erweiterung pg_partman eine eigene Partition erstellt wird.

Leuphana-Universität Lüneburg: IT-Infrastruktur für Hackathons

Was ist ein Hackathon?

Das Wort Hackathon setzt sich zusammen aus den beiden Worten Hack und Marathon. Es ist eine kollaborative IT-Veranstaltung mit dem Ziel, gemeinsam Prototypen zu spezifischen Themen oder Problemen herzustellen.

Über die thematische Ausrichtung eines Hackathons können Bezüge zu den Lebenswelten der Teilnehmer*innen hergestellt werden. Sie erfahren, wie Probleme gemeinsam mit technischen Mitteln gelöst werden können. Häufig wurden Hackathons jedoch auch veranstaltet um kreativ Lösungswege zu finden. Schließlich führen sie auch zu einer Vernetzung der Teilnehmer*innen, auch wenn diese aktuell nur online möglich ist.

Nach dem erfolgreichen Hackathon der Bundesregierung WirVsVirus u.a. zusammen mit Code for Germany und Prototype Fund haben auch andere für sich Hackathons als geeignetes Veranstaltungsformat gefunden, so beispielsweise auch das Hochschulforum Digitalisierung mit ihrem SemesterHack.

Für den Lüneburg Hackathon 2020 mit bis zu 500 Teilnehmer*innen konzipierten wir nicht nur die IT-Infrastruktur sondern auch die Event-Begleitung mit folgenden Phasen:

  1. Setup mit 24h
  2. 14-tägiger Vorlauf mit 9h
  3. 3-tägiger Event mit 36h
  4. 14-tägiger Nachlauf mit 5h

Im Wesentlichen sahen wir die drei große Herausforderungen:

  • in kurzer Zeit uns eng mit den Veranstalter*innen der Leuphana-Universität Lüneburg abzustimmen
  • eine einfache Integration der verwendeten IT-Komponenten:
  • Jitsi als hochverfügbaren Cluster-Service bereitzustellen, mit dem die 500 Teilnehmer*innen gleichzeitig kommunizieren können

Wie läuft ein Hackathon ab?

Der typische Ablauf eines Online-Hackathons kann dann z.B. so aussehen:

  1. Begrüßung der Teilnehmer*innen und Kennenlernen im Mattermost Chat
  2. Vorstellung des Formats und Agenda des Hackathons mit Jitsi-Videokonferenz und Screensharing
  3. Kurze Impulsvorträge zu den wichtigsten Tools, Daten und thematischen Schwerpunkten
  4. Brainstorming mit GitLab Kanban-Boards
  5. Gruppenbildung mit jeweils eigenen Kanban-Boards, Git-Repositories, Mattermost-Channels und ggf. Entwicklungsumgebungen auf Basis von Jupyter Notebooks.
  6. Präsentationen mit Jitsi-Videokonferenzen und ggf. Jupyter Notebooks im Präsentationsmodus

Welche Hackathons gibt es in Deutschland?

Jugend hackt
Ihr Motto ist Mit Code die Welt verbessern und soll einen verantwortungsbewussten Umgang mit Technik fördern um Lösungen für gesellschaftspolitische Fragen zu finden. Es ist ein nicht-gwinnorientiertes Programm der gemeinnützigen Vereine Open Knowledge Foundation Deutschland e.V. und mediale pfade.org.
Coding da Vinci
Seit 2014 vernetzt Coding da Vinci technikaffine und kulturbegeisterte Communities mit deutschen Kulturinstitutionen, um offene Kulturdaten zu erhalten.
Science Hack Day Berlin
Der Science Hack Day Berlin wird von Freiwilligen aus den Bereichen Wissenschaft, Design, IT, Ingenieurwesen und Kommunikation organisiert.
Wikimedia Hackathon
Die Wikimedia Hackathons werden veranstaltet um um die technologische Infrastruktur von Wikipedia und anderen Wikimedia-Projekten, insbesondere der ihnen zugrunde liegenden MediaWiki-Plattform zu verbessern.

Falls ihr nun selbst einen Hackathon veranstalten möchtet, so kann Cusy auch euch mit der passenden IT-Infrastruktur und Support unterstützen.

Meldet euch

Ich berate euch gerne und erstelle ein passgenaues Angebot für IT-Infrastruktur und Support bei einem Hackathon.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Wir rufen euch auch gerne an!

Jetzt anfragen

Datenschutz in Zeiten von Covid-19

Unternehmen und Organisationen haben Daten, die sie nicht auch anderen zur Verfügung stellen wollen. Zudem stehen sie auch ihren Kunden, Partnern und Angestellten in besonderer Verantwortung. Nicht Souverän dieser Daten zu sein, bedeutet nicht nur einen Vertrauensverlust, sondern meist auch kommerzielle Einbußen.

Zeigt euren Kunden, Partnern und Mitarbeitern, dass euch Datenschutz wichtig ist und ihr Verantwortung übernehmt zur Wahrung ihrer Privatsphäre. Zeigt, dass ihr die Regeln der Europäischen Datenschutz-Grundverordnung (DSGVO) von Mai 2018 umgesetzt habt.

Verzichtet daher auf Google-Dienste und benutzt Alternativen. Google verdient Geld mit den Daten, die ihr Google liefert:

Mit eurer Erlaubnis gebt ihr uns weitere Informationen über euch selbst und eure Freunde, wodurch wir die Qualität unserer Suche verbessern können. Ihr müsst überhaupt nicht tippen. Wir wissen wo ihr seid. Wir wissen, wo ihr wart. Wir können mehr oder weniger wissen, woran ihr denkt. [1]

Diese Äußerung des damaligen Google CEO, Eric Schmidt, ist aktueller denn je. Es kann einem schon unheimlich werden bei der Vorstellung, dass ein Konzern mehr oder weniger weiß, woran man denkt. Lediglich einen Teil dieser Informationen gibt der Konzern auch wieder preis, sofern ihr noch ein Google-Konto besitzt – gespeicherte Graphen und andere Auswertungen bleiben euch weiter verborgen.

Im Folgenden wollen wir euch einige datenschutzfreundliche Alternativen zu Google-Diensten vorstellen:

… für eure Büroarbeit

… für eure Website

… für eure Apps

Zum Weiterlesen

Telearbeit und Mobiles Arbeiten
Information des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI), Januar 2019
Top Tips for Cybersecurity when Working Remotely
Artikel der European Union Agency for Cybersecurity (ENISA), März 2020
Home-Office? – Aber sicher!
Information des Bundesamts für Sicherheit in der Informationstechnik (BSI), März 2020

[1]Google’s CEO: ‹The Laws Are Written by Lobbyists›, 2010.

Cusy DevOps­-Toolchain as a Service in der iX extra 04/2020

Cusy wird im Extra Hosting für Entwickler der Zeitschrift iX 04/2020 besprochen. Insebsondere werden in diesem Heft zwei Entwicklertrends hervorgehoben: Microservices und DevOps. Dies sind auch Schwerpunkte unserer Arbeit, über die wir immer wieder berichten, z.B. in unserem Blog:

Beim Beispiel einer DevOps-Toolchain bezieht sich der iX-Artikel dann auch direkt auf uns:

Entwickleraufgabe Softwaretool
Projektmanagement Jira-Software
Dokumentenmanagement Confluence
Versionsverwaltung Gitblit
Code-Review Gerrit
Testen/Deployment Jenkins
Log-Management und -Analyse Sentry
Helpdesk Jira Service Desk
Webanalyse Matomo

Auch am Ende des Artikels wird Cusy noch einmal mit einem Alleinstellungsmerkmal erwähnt – die DevOps-Tools lassen sich leicht integrieren und verfügen über eine einheitliche Benutzerverwaltung:

Ganz auf Entwicklerwerk­zeuge hat sich Cusy spezialisiert. Alle Tools lassen sich einzeln als virtuelle Maschinen buchen, kön­nen aber über ein integriertes LDAP-­Directory zusammenarbei­ten.

Beuth Hochschule: Prototyp Medikamenten-App

Für die Beuth Hochschule entwickeln wir den Prototypen einer Medikamenten-App. Dabei soll die Sicherheit für Patienten bei der Medikation verbessert werden, und zwar insebsondere

  • das Monitoring des Einnahmerhythmus
  • die Warnung vor Nebenwirkungen und wechselseitigen Beeinflussungen.

Dabei soll die Nutzung der App nicht nur für Patienten selbst, sondern auch für Angehörige Und Pflegekräfte möglich sein.

Tatsächlich gibt es bereits viele Apps, die versprechen, die Anforderungen zu erfüllen. Bei einer genaueren Recherche weisen sie jedoch erhebliche Mängel auf.

Fachliche Qualität

Die fachliche Qualität der meisten Apps ist nur selten erkennbar und dürfte, wenn die wenigen Überprüfungen zugrundegelegt werden, meist sehr gering sein. Dies ist umso problematischer, wenn Apps versprechen, auf Wechselwirkungen und doppelte Verordnungen ähnlich wirkender Medikamente hinzuweisen. Für Kunden, die sich darauf verlassen, dass ihre App sie schon auf Gefahren, z.B. bei ihren Selbst­medikations­wünschen hinweisen wird, dürften massiv gefährdet sein.

Nutzergruppen

Die bereits existierenden Apps machen auch ganz selten Angaben zu ihren Nutzergruppen, weder zur

  • Eignung für spezifische Erkrankungen/Leiden
  • Eignung für Geschlecht, spezielle Altersgruppen (bzw. -bereiche) etc.
  • Eignung für bestimmte Gesundheitsberufe bzw. Berufsgruppen und Settings: klinisch, ambulant, zu Hause, …
  • Eignung bei physiologischen und körperlichen Beeinträchtigungen, auch nicht die Unterstützung für TalkBack für Android und VoiceOver für iPhone.
  • Unterstützung länderspezifischer Arzneimittel und Packungsgrößen

Datenschutz

Auch der Umgang mit Nutzerdaten ist meist mangelhaft. Die Datenschutzerklärungen lassen Kunden meist im Unklaren, was mit ihren Angaben geschieht. Dies ist umso problematischer, da über 80% der Apps Daten an Infrastrukturanbieter wie Google, Facebook etc. übertragen. Noch nicht einmal die verschlüsselte Übertragung von Nutzerdaten war immer gewährleistet, dies vor allem dann nicht, wenn Daten per E-Mail übertragen werden. Die wenigen unabhängigen Testverfahren dürften hier kaum zu einer Klärung beitragen, da sie sich meist auf die Selbstauskunft verlassen.

elena international: Webbasiertes Planungswerkzeug für Microgrids

Für elena international realisieren wir ein Web-basiertes Planungswerkzeug für Microgrids, bei dem wir Jupyter Notebooks und Voilà vuetify für die schnelle, einfache und robuste Weiterentwicklung der Darstellungslogik und der User Interactions nutzen.

elena international GmbH ist ein Startup, das maßgeschneiderte Lösungen für verschiedene Phasen der Netzplanung liefert.

Als erstes realisieren wir ein Walking Skeleton eines webbasierten Planungswerkzeug für Microgrids.

Die gewählte Software-Architektur erlaubt elena, ihre Julia-Bibliotheken weiterzuentwickeln. Die Übernahme neuer Features in das Webtool erfolgt dann mit PyJulia in IPython-Notebooks. In diesen Notebooks können auch die voila-vuetify-Widgets für die Interaktion mit den NutzerInnen definiert werden. Schließlich werden diese Notebooks mit Voilà in ein interaktives Dashboard umgewandelt:

Voilà-Dashboard

Um die Notebooks für die Produktion zu härten sind die Methoden einerseits mit Tests versehen, die mit GitLab CI/CD regelmäßig durchlaufen werden, andererseits erleichtert Logging die Fehlerdiagnose und das Monitoring.

Damit beantworten wir nicht nur die Frage Sind Jupyter Notebooks produktionsreif? sondern erweitern die Möglichkeiten von Notebooks noch: sie dienen hier als umfassendes Editorensystem, in dem nicht nur Texte verfasst und Medien hinzugefügt werden können, sondern auch die Darstellungslogik wissenschaftlicher Berechnungen und interaktive Widgets definiert werden können.

Sind Jupyter Notebooks produktionsreif?

In den letzten Jahren gab es einen rasanten Anstieg in der Verwendung von Jupyter Notebooks, s.a. Octoverse: Growth of Jupyter Notebooks, 2016-2019. Hierbei handelt es sich um eine von Mathematica inspirierte Anwendung, die Text, Visualisierung und Code in einem Dokument kombiniert. Jupyter-Notebooks werden von unseren Kunden häufig für das Prototyping und die Erforschung von Analysen und maschinellem Lernen verwendet. Wir haben jedoch auch gesehen, dass die wachsende Popularität auch dazu beigetragen hat, dass Jupyter-Notebooks in anderen Bereichen der Datenanalyse verwendet wird und zusätzliche Werkzeuge genutzt wurden, um mit ihnen auch umfangreiche Berechnungen durchzuführen.

Zum Erstellen von skalierbarem, wartbarem und langlebigem Produktionscode erscheinen uns Jupyter Notebooks jedoch meist ungeeignet. Zwar lassen sich mit einigen Tricks Notebooks sinnvoll versionieren und es lassen sich auch automatisierte Tests ausführen, bei komplexeren Projekten wird die Vermischung von Code, Kommentaren und Tests jedoch zum Hindernis: Jupyter Notebooks lassen sich nur unzureichend modularisieren. Zwar können Notebooks als Module importiert werden, diese Möglichkeiten sind jedoch äußerst beschränkt: so müssen die Notebooks zunächst vollständig in den Speicher geladen und ein neues Modul erstellt werden, bevor jede Zelle in diesem ausgeführt werden kann.

In der Folge kam es zum ersten Notebook-Krieg, s. The First Notebook War, der im Wesentlichen ein Konflikt zwischen Data Scientists und Software Engineers war.

Wie können die Gräben überwunden werden?

Notebooks erfreuen sich bei Data Scientists rasch wachsender Beliebtheit und werden zum De-facto-Standard für rapid Prototyping und explorative Analysen. Vor allem Netflix hat jedoch ein umfangreiches Ökosystem von zusätzlichen Tools und Services erstellt, wie z.B. Genie und Metacat. Diese Tools vereinfachen die Komplexität und unterstützen einen breiteren Anwenderkreis von Analysten über Wissenschaftler bis hin zu Informatikern. Im Allgemeinen hängt jede dieser Rollen von verschiedenen Tools und Sprachen ab. Oberflächlich betrachtet scheinen die Workflows unterschiedlich, wenn nicht komplementär zu sein. Auf einer abstrakteren Ebene jedoch haben diese Workflows mehrere überlappende Aufgaben:

Datenexploration

tritt früh in einem Projekt auf

Dies kann das Anzeigen von Beispieldaten, die statistische Profilerstellung sowie die Datenvisualisierung umfassen

Datenaufbereitung

iterative Aufgabe

kann das Bereinigen, Standardisieren, Transformieren, Denormalisieren und Aggregieren von Daten umfassen

Datenvalidierung

wiederkehrende Aufgabe

kann das Anzeigen von Beispieldaten, das Ausführen von Abfragen zur statistischen Profilerstellung und aggregierten Analyse sowie das Visualisieren von Daten umfassen

Produkterstellung

tritt spät in einem Projekt auf

Dies kann das Bereitstellen von Code für die Produktion, Schulungsmodelle und das Planen von Workflows umfassen

Ein JupyterHub kann hier schon gute Dienste leisten um diese Aufgaben möglichst einfach und überschaubar zu gestalten. Dabei ist es skalierbar und reduziert die Anzahl der Tools erheblich.

Um zu verstehen, warum Jupyter-Notebooks für uns so überzeugend sind, heben wir noch einmal ihre Kernfunktionalitäten hervor:

  • Ein Messaging-Protokoll zum Prüfen und Ausführen von sprachunabhängigem Code
  • Ein bearbeitbares Dateiformat zum Beschreiben und Erfassen von Code, Code-Ausgabe und Markdown-Notes
  • Eine webbasierte Benutzeroberfläche zum interaktiven Schreiben und Ausführen von Code sowie zur Datenvisualisierung

Use Cases

Von unseren zahlreichen Anwendungsfällen verwenden wir Notebooks heute am häufigsten für Datenzugriffe, Parametrisierung und Workflow-Planung.

Datenzugriffe

Notebooks wurden von uns erstmals eingeführt, um Data-Science-Workflows zu unterstützen. Als die Akzeptanz zunahm, sahen wir die Möglichkeit, die Vielseitigkeit und Architektur von Jupyter-Notebooks auch für den allgemeinen Datenzugriff nutzen zu können. Mitte 2018 begannen wir damit, die Notebooks von einem Nischenprodukt zu einer universellen Datenplattform auszubauen.

Aus Sicht der Benutzer bieten Notebooks eine komfortable Oberfläche für die iterative Ausführung von Code, das Durchsuchen und Visualisieren von Daten – alles in einer einzigen Entwicklungsplattform. Aufgrund dieser Kombination aus Vielseitigkeit, Leistung und Benutzerfreundlichkeit haben wir eine schnelle Akzeptanz für viele Benutzergruppen auf der gesamten Plattform festgestellt.

Paremtrisierte Notebooks

Einhergehend mit der zunehmenden Akzeptanz haben wir weitere Funktionen für weitere Anwendungsfälle eingeführt. Aus dieser Arbeit gingen einfach parametrisierbare Notebooks hervor. Dies bot unseren Nutzern einen einfachen Mechanismus um Notizbücher als wiederverwendbare Vorlagen zu definieren.

Workflow-Planung

Als weiteren Einsatzbereich von Notebooks haben wir die Planung von Workflows entdeckt. Sie haben u.a. folgende Vorteile:

  • Notebooks erlauben einerseits interaktives Arbeiten und rapid Prototyping, um anschließend fast reibungslos in den Produktivbetrieb überführt werden zu können. Evtl. werden die Notebooks modularisiert und als vertrauenswürdig gekennzeichnet.
  • Ein weiterer Vorteil von Notebooks sind die unterschiedlichen Kernel, sodass die sich Benutzer die jeweils passende Ausführungsumgebung auswählen können.
  • Zudem sind Fehler in Notebooks einfacher nachzuvollziehen da sie bestimmten Zellen zugeordnet sind und die Ausgaben gespeichert werden können.

Logging

Um Notebooks nicht nur für Rapid Prototyping sondern auch dauerhaft produktiv verwenden zu können, müssen bestimmte Prozesseereignisse protokolliert werden, sodass z.B. Fehler einfacher diagnostiziert und der Gesamtprozess überwacht werden kann. Hierfür kann in IPython Notebboks das logging-Modul der Python-Standardbibliothek oder loguru verwendet werden, s.a. Jupyter-Tutorial: Logging.

Tests

Es gab schon früher einige Ansätze, mit denen sich Notebooks automatisiert testen ließen, z.B. nbval, aber erst mit ipytest wurde das Schreiben von Tests für Notebooks deutlich vereinfacht, siehe auch Jupyter-Tutorial: ipytest.

Re­sü­mee

In den letzten Jahren förderten wir die enge Zusammenarbeit von Software Engineers mit Data Scientists um zu skalierbarem, wartbarem und produktionsfähigem Code zu gelangen. Gemeinsam haben wir Lösungen gefunden, die produktionsreife Modelle auch für Machine Learning-Projekte bereitstellen können.

Springer Nature: Lemma-Verwaltung

Mit dem Lemma-Verwaltungssystem (LVS) werden die Inhalte folgender Lexika verwaltet:

Dabei unterscheidet das System zwischen den folgenden Artikeltypen:

  • Lemma/Sublemma
  • Autor/Co-Autor
  • Band
  • Fachgebiet

Domain-Driven Datenarchitektur

Viele Unternehmen investieren weiterhin in Data-Lake, in der Hoffnung, Daten in großem Maßstab demokratisieren zu können. Es ist jedoch bereits jetzt absehbar, dass darauf basierende Plattformen die Versprechungen nicht erfüllen werden können. Um die Probleme anzugehen, müssen wir die bisherigen Paradigmen des Data-Lake und seines Vorgängers Data-Warehouse überwinden und die Vorteile beider nutzen. Diese Lösung geht von einer verteilten Architektur aus, die den verschiedene Fachdomänen eine Self-Service-Dateninfrastruktur bereitstellt und die Daten als Produkte behandelt.

Wir arbeiten seit zwei Jahren am Aufbau eines Computercluster für das Fraunhofer ISE.

Dabei wurde von uns häufig erwartet, dass wir diesen zentralisiert, monolithisch und domänenunabhängig aufbauen, also als sog. Data Lake.

Die größte Herausforderung besteht nicht darin, einen Datensee zu erstellen, sondern die sich daraus ergebenden Chancen zu nutzen.

– Sean Martin, CTO Cambridge Semantics

Wir konnten jedoch bereits früher zusammen mit anderen Kunden erkennen, dass diese Chancen kaum genutzt werden konnten. Hier deswegen zunächst ein kurzer Überblick über frühere Architektur-Generationen:

Historie

  1. Generation: Enterprise Data Warehouse (EDW)

    Vor einem Jahrzehnt waren Daten meist ein Synonym für relationale Datenbanken. Meist führte dies jedoch zu hohen technischen Schulden in Form von tausenden nicht zu überarbeitenden ETL (extract, transform, load)-Jobs, die nur eine kleine Gruppe von Fachleuten versteht. Damit blieben jedoch die erhofften positiven Auswirkungen unerfüllt.

  2. Generation: Big-Data-Ökosystem mit einem Data Lake

    Jetzt können Daten eine erstaunliche Vielfalt von Formen annehmen einschließlich NoSQL, Zeitreihen und SQL. Dies ist auf den Wunsch zurückzuführen, immer schneller auf immer größere, vielfältigere und schnellere Datenquellen zu reagieren. Forscher werden jedoch mit dem Verstehen unterschiedlicher Arten der Datenhaltung vor zusätzliche Herausforderungen gestellt. Aktuell bekommen wir also zusätzliche Möglichkeiten, ohne dass jedoch die grundlegenden Probleme der vorgehenden Generation gelöst worden wären. Diese Ökosysteme mit lange laufenden Batch-Jobs werden mit all ihren Auswirkungen meist nur von hochspezialisierten Fachleuten verstanden. Zwar führte dies theoretisch zu einer Fülle von möglichen Analysen und Simulationen, diese konnten aber wegen ihres Umfangs und ihrer Komplexität praktisch nur selten realisiert werden.

    CockRoachDB und Spanner bieten darüberhinaus globale Konsistenz und Event stream processing (ESP) mit Abfragemöglichkeiten für aggregierte Log-Dateien.

    Ein Nachteil dieses Ansatzes besteht jedoch darin, dass er eher an low-level Database Events als an Geschäftsereignisse auf höherer Ebene gebunden ist, die für uns die Grundlage einer ereignisorientierten Architektur sein sollte – Ereignisse sollten in ihren Domänen explizit erfasst werden oder Statusübergänge sollten nicht impizit erschlossen werden müssen.

Beiden Generationen sind jedoch die folgenden Architekturfehler gemeinsam:

  1. zentral und monolithisch
  2. sequenzierte Pipeline
  3. spezialisiertes Eigentum

Ad 1. Zentral und monolithisch

Alle zugänglichen Daten wurden erfasst und dem ETL (extract, transform, load)-Dreischritt unterworfen:

  1. Extract

    Möglichst alle Daten wurden erfasst, unabhängig davon, ob sie für eine spezifische Fachdomäne benötigt wurden oder nicht.

  2. Transform

    Die Transformation der Daten erfolgte üblicherweise ebenfalls nicht in Hinblick auf die konkreten Erfordernisse sondern vielmehr in Hinblick auf eine möglichst universelle Verwendbarkeit. Häufig wurden die Daten auch noch mit Informationen aus anderen Datenquellen angereichert um prinzipiell noch umfassendere Analysen machen zu können.

  3. Load

    In diesem Schritt wurde darauf geschaut, dass die Daten für eine Vielzahl von Fachdomänen über die gewünschten Protokolle bereitgestellt werden können.

Während wir bei der Anwendungsentwicklung in den letzten Jahren darauf achteten, dass das Design spezifisch für die jeweilige Domäne ist und auch nur in diesem spezifischen Kontext funktionieren muss, wurde Domain Driven Design bei den Datenplattformen weitgehend ignoriert. Dies führte dann zu den bekannten Problemen:

  • Die Aufwände, diese domänenunspezifischen Daten zu harmonisieren, nahmen zu.
  • In vielen Fällen war zu sehen, dass die Integration neuer Datenquellen verzögert oder blockiert wurde, weil sie nicht in das universelle Schema passen wollen.

Die von uns vorgeschlagene Alternative wird nicht zu fragmentierten, isolierten und domänenorientierten Daten führen, die schwer zu entdecken sind sowie spezifisches Wissen zum Verstehen und verarbeiten benötigen. Dies wären dann auch nur wieder fragmentierte Data Warehouses, wie sie sich häufig zur Umgehung der oben genannten Probleme angestaut haben und die nun als technische Schulden weitere Innovationen behindern.

Ad 2: Sequenzierte Pipeline

Der ETL (extract, transform, load)-Dreischritt offenbart jedoch noch weitere Schwierigkeiten, die sich aus der sequentiellen Aufteilung der Funktionen ergeben. Die Motivation für das Sequenzieren der Datenverarbeitung lag in der bestehenden Arbeitsteilung der Forschungsteams.

Organisationen, die Systeme entwerfen, … sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

– Melvyn E. Conway: Conway’s Law, 1967

Obwohl diese Gliederung ein gewisses Maß an Skalierung zu bietet scheint, da Teams verschiedenen Phasen der Verarbeitungspipeline zugewiesen werden, kommt dieser Effekt jedoch meist nicht zum Tragen, da bei neuen Features meist alle Sequenzen der Pipeline überarbeitet werden müssen.

So müssten z.B. für die Ergänzung der Strom-Ex- und Import-Daten um geplante und ungeplante Kraftwerksausfälle alle drei ETL-Bereiche angepasst werden.

Ad 3: Spezialisiertes Eigentum

Das dritte Problem hängt damit zusammen, wie die Teams strukturiert sind, die die Plattform erstellen und betreiben. Meist sind diese Teams isoliert von denjenigen, die diese Plattform für ihre Analysen und Simulationen nutzen. Sie erlangen also meist keine Kenntnis von den Datenquellen und deren Verwendung; sie sollen nur betriebliche und analytische Anforderungen erfüllen, ohne jedoch jemals ein klares Verständnis für eine konkrete Anwendung der Daten zu erhalten.

Die nächste Generation von Datenplattformen

Aus den oben angesprochenen Problemen wird deutlich, dass ein Paradigmenwechsel erforderlich ist. Ein Paradigmenwechsel, der in anderen IT-Bereichen bereits stattgefunden hat und dort bereits die Erprobungsphase verlassen hat: Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking führen zu ubiquitous computing in einem vermaschten Netz (engl. Mesh).

Domain-Driven Architektur

Domänenorientierte Aufteilung und Eigentum der Datensätze

Eric Evans Buch Domain-Driven Design hat nicht nur die moderne Software-Architektur tiefgreifend beeinflusst, sondern auch die Organisationsentwicklung: Nicht nur wurden monolithische Systeme in Microservices zerlegt, auch die um Technologieschichten (Datenbank, Anwendungslogik, UI) organisierten Teams wurden umgewandelt in domänenspezifische Teams.

Bei einem solchen dezentralen Datenmanagement ist dann die Herausforderung, wie diese domänenspezifischen Daten gemeinsam genutzt werden können. Dies ist gut in Ben Stopfords Data Dichotomy-Artikel beschrieben.

Um nun eine monolithische Datenplattform zu dezentralisieren, müssen wir auch unsere Einstellung zu Ort und Eigentum dieser Daten überdenken: statt fleißig Daten in unseren eigenen, zentral gelegenen Data Lake zu übernehmen, müssen nun die Fachdomänen selbst für das Hosting dieser Daten sorgen und sie in einfach zu verarbeitender Weise zur Verfügung stellen. Dies kann dann zur Folge haben, dass wir dieselben Daten, jedoch für jede der Fachdomänen unterschiedlich aufbereitet, so auch in verschiedenen Domänen speichern.

Damit verlagert sich der Datenfluss von einem sequenzierten Pipeline-Prozess hin zu einer domänenspezifischen Aufbereitung.

Quelldomän-Datensätze

Einige Domänen richten sich natürlich nach der Herkunft der Datensätze. Meist entstehen diese Datensätze sehr nahe an der Quelle, an der die Daten entstehen. Idealerweise übernehmen die Lieferanten dieser Datensätze auch die Gewähr, dass diese hinreichend integer sind.

Note

Diese Datensätze enthalten meist nur Rohdaten, die zum Zeitpunkt der Erstellung möglichst genau wiedergeben und nicht für einen bestimmten Konsumenten angepasst oder modelliert sind.

Verbraucherorientierte und gemeinsam genutzte Datensätze

Einige Domänen bestimmen sich nicht aus der Herkunft sondern dem Ziel, das erreicht werden soll. Auch ansonsten unterscheiden sich diese Datensätze erheblich von denjenigen der Quelldomäne: Sie werden jedoch transformiert, um einen möglichst einfachen Zugriff darauf zu erlauben. Hier entsteht also eine Pipeline zur Bereinigung, Aufbereitung, Aggregation und Bereitstellung der Daten.

Self-Service-Platforms

Es gibt jedoch nicht nur innerhalb der Domänen von verbraucherorientierten Datensätzen Verarbeitungspipelines, sondern auch bereits bei Quelldomän-Datensätzen: Dort müssen die Daten auf Vollständigkeit überprüft werden und frei von Dubletten sein.

Um die Komplexität solcher Pipelines jedoch so gering wie möglich zu halten, werden sie immer nur innerhalb ihrer eigenen Domäne behandelt. Dort können dann auch Service-Levels für die Daten dieser Domäne definiert werden wie Aktualität, Fehlerraten etc.

Product Thinking

In anderen Bereichen wurden Produkte schon viel früher über Projekte gestellt, s.a. Products over Projects. Zukünftig werden die Teams einer Datendomäne den Forschungsteams ihre Funktionen als APIs zur Verfügung stellen und liefern so einen Baustein für die Schaffung höherer Funktionalitäten und Auftragswerte. Damit ein solches Produkt erfolgreich wird, müssen die Daten folgende Eigenschaften aufweisen:

  • Ein Datenprodukt muss leicht auffindbar sein

    Eine übliche Implementierung besteht in einer Registrierung und einem Datenkatalog aller Datenprodukte mit ihren Metainformationen. Diese zentrale Anlaufstelle ermöglicht Datenkonsumenten, die Datensätze ihres Interesses leicht zu finden.

  • Jedes Datenprodukt muss eine eindeutige Adresse haben

    Diese Adresse muss einer globalen Konvention folgen und anderen Benutzern erleichtern, programmatisch auf diese Daten zuzugreifen. Und auch wenn die zugrundeliegenden Speicher und Datenformate unterschiedlich sind, z.B. Events als Stream von Kafka Topics oder Kolumnen in Apache Parquet, so müssen diese Daten doch einheitlich adressierbar sein um Reibungsverluste beim Auffinden und Zugreifen auf diese Daten gering zu halten.

  • Die Daten müssen vertrauenswürdig und wahrheitsgemäß sein

    Hierfür werden Service-level Objectives (SLOs) definiert und überwacht. Hierfür werden die Daten bereinigt, Dubletten entfernt und automatisiert Integritätstests durchgeführt.

    Ebenso sollte die Datenherkunft (engl.: Data Lineage) als Metadaten bereitgestellt werden um die Eignung für spezielle Bedürfnisse ermitteln zu können.

    Die SLOs können jedoch zwischen den einzelnen Datenprodukten variieren.

  • Die Semantik und Syntax sollte leicht zugänglich sein

    Datenschemata sind häufig der Ausgangspunkt für die Bereitstellung von Self-Service-Datenbeständen. Daher werden sie üblicherweise zusammen mit Beispieldatensätzen leicht zugänglich veröffentlicht.

  • Die Daten sollten interoperabel sein

    Auch wenn die Daten in einzelnen Fachdomänen verwaltet werden, so ist jedoch erklärtes Ziel, die Daten domänenübergreifend korrelieren zu können. Voraussetzung für effektive Korrelationen sind das Einhalten bestimmter Standards und Harmonisierungsregeln. Dies wird z.B. über die Definition von Feldtypen, die Identifizierung bestimmter Polyseme in verschiedenen Domänen, Adresskonventionen für Datensätze, gemeinsame Metadatenfelder, Event-Formate wie z.B. in der CloudEvents Specification) festgelegt etc.

  • Der Zugriff auf Produktdatensätze muss sicher sein und sollte einer globalen Zugriffskontrolle unterliegen

    Hierfür können Single Sign On und Role Based Access Control verwendet werden.

Vermaschtes Netz

Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking kommen zusammen in einem vermaschten Netz. Einerseits besteht dieses aus verteilten Datenprodukten, die sich an Domänen orientieren und die im Besitz unabhängiger und funktionsübergreifender Teams sind; andererseits nutzen sie eine gemeinsame Dateninfrastruktur mit einer Hosting-Plattform und ETL-Bibliotheken. Darüberhinaus wird die Vereinheitlichung von batch- und streaming-Jobs, z.B. mit Apache Beam, die problemlose Verarbeitung adressierbarer polyglotter Datensätze ermöglichen. Das Beam-Modell basiert auf dem Dataflow-Modell, mit dem sich die Logik elegant ausdrücken lässt. Zudem werden von Beam auch verschiedenste Runner unterstützt, u.a. Apache Flink, Apache Spark und Apache Samza, s.a. Beam Capability Matrix. Es ist jedoch zu beachten, dass die Runner unterschiedlichste Fähigkeiten haben und die Bereitstellung einer übergreifenden API ein schwieriges Unterfangen bleibt.

Beam hat darüberhinaus ein umfangreiches Set an eingebauten I/O-Transformationen, die einen großen Teil der Daten-Pipeline-Anforderungen abdecken dürfte. Und falls diese nicht ausreichen sollten, können auch benutzerdefinierte Transformationen definiert werden.

Zum Weiterlesen

Eric Evans: Domain-Driven Design

ein nicht einfach zu lesendes Buch, aber die kanonische Quelle für Domain-Driven Design.

In Kapitel IV wird das Ermitteln der Domänengrenzen beschrieben.

Vaughn Vernons: Implementing Domain-Driven Design
konzentriert sich auf strategisches Design und erläutert in Kapitel 2 ausführlich, wie eine Domäne in begrenzte Kontexte untergliedert wird.
William Kent: Data and Reality
und auch wenn das Buch etwas in die Jahre gekommen ist, so ist es doch weiterhin relevant für das Datenmanagement.