Best practices für Open-Source-Datenkataloge

Für jede Datenherausforderung finden sich heutzutage die passenden Lösungen – darunter sind auch immer häufiger open source-Tools. Und obwohl einige (wie Linux, Python, Postgres u.v.m.) mittlerweile zu nahezu jedem Tech-Stack gehören, gibt es in so manchem Unternehmen  noch immer Bedenken andere OS-Lösungen zu verwenden. Typische Bedenken sind:

• die Sicherheit
• den Aufwand für Implementierung und Updates 
• Fehlende Erfahrung bei der Wartung 
• die langfristige Verfügbarkeit der Lösung
• das Fehlen zentraler Ansprechpartner

Dabei sind diese Bedenken dieselben, die es auch bei anderen Softwareimplementierungen gibt (oder geben sollte!).Zu einer kritischen Überprüfung kommt es jedoch im Unterschied zu kommerziellen Lösungen bei OS-Lösungen häufig nicht. Das bedeutet oft zu Unrecht einen frühen K.O. für Letztere. Dabei können OS-Lösungen viele Vorteile bringen. Einige sind:

• Geringe oder keine Lizenzkosten
• Mehr Flexibilität und bessere Möglichkeiten der Individualisierung
• Schnellere Weiterentwicklung und höhere Kompatibilität mit neuen Lösungen
• Freier Austausch von Best-Practices in der Community

Damit Sie aber für Ihre Tool-Evaluation und -diskussionen optimal vorbereitet sind, stellen wir im Folgenden unsere Best Practices für die Einführung und Maintenance von OS-Datenkatalogen vor. Mit deren Hilfe können Sie realistisch einschätzen, wie kompatibel ein OS-Datenkatalog mit Ihren Prozessen ist und wie viel Mehraufwand diese bedeuten. 

‍

Zentrale Best practices für OS-Tools

‍

Initiale Evaluierung

Am Beginn jeder Tool-Beschaffung steht die Evaluierung des Tools. Zu beantwortende Fragen sind:

• In welchem Umfang erfüllt das Tool Ihre Anforderungen?
• Passt es in den Tool-Stack? 
• Ist die Lösung vertrauenswürdig, stabil und wahrscheinlich langfristig am Markt?

__________________________________________________________________________________________

Für mehr Sicherheit hinsichtlich der Frage nach Vertrauenswürdigkeit, Stabilität und Nachhaltigkeit empfehlen wir, die vier folgenden Kernkriterien zu prüfen. Nicht alle OS-Projekte sind wirklich für den Einsatz in Unternehmen geeignet.

1. Größe der Projekt-Community: Projekt-Communities sind sehr unterschiedlich groß. Sie können einen einzelnen Menschen oder bis zu mehreren 10 000 Mitgliedern umfassen. Dementsprechend sind die Communities auch unterschiedlich stark organisiert und anders strukturiert. Für Anwendungen im Unternehmenskontext sollten Sie auf eine große, gut organisierte Community achten. Das sichert auch die langfristige Existenz des Tools. 

Unser Tipp: Typischerweise organisieren sich die Communities entweder in Foren oder modernen Kommunikationsplattformen wie Slack. Diese sind auch guter Anlaufpunkt für erste Schritte und Fragen.

2. Publizierter Softwareentwicklungsprozess: Große Projekte folgen üblicherweise einem definierten Softwareentwicklungsprozess. Nachzulesen ist das in den Community-Guidelines. Die Existenz eines sauber aufgesetzten Entwicklungsprozesses ist ein weiteres wichtiges Kriterium.  

3. Geschwindigkeit und Häufigkeit der Verbesserungen: Da der Code frei zugänglich ist, werden potenzielle Risiken und Schwachstellen von Projekten mit großen Communities (und vielen Augenpaaren) zügig erkannt und schnell behoben. Einen Eindruck der gefundenen und behobenen Probleme sollte sich das Unternehmen in der Code-Historie verschaffen. Je kürzer die Zeiten dort sind, desto besser ist das zumeist für die Sicherheit. 

4. Etablierung der Lösung: Ist die Lösung bereits bei anderen Unternehmen im Einsatz, belegt das die Eignung und ist zugleich ein weiterer Treiber dafür, dass die Lösung langfristig verfügbar sein wird. Diese Unternehmen haben dann schließlich ebenfalls ein Interesse an der stetigen Weiterentwicklung.

__________________________________________________________________________________________

Bei Open-Source-Lösung sind im Schritt der Evaluierung einige Themen besonders sorgfältig zu prüfen: 

• Passt das Tool zur erwarteten Benutzergruppe und deren Skills? 
• Hat das Tech-Team das benötigte technische Hintergrundwissen? 

Weitere Tipps dazu finden Sie in den Artikeln “Vor- und Nachteile eines Open-Source-Datenkatalogs” und “Open-Source-Datenkataloge für große Unternehmen?”

‍

Transparente Kommunikation

Dass es einige Unterschiede zwischen kommerziellen Lösungen und OS-Lösungen gibt, ist nicht von der Hand zu weisen. Vor- und Nachteile sollten Sie klar an sämtliche Stakeholder kommunizieren. Unserer Erfahrung nach lohnt es sich, zu Beginn eines Projektes mehr Zeit in Aufklärung zu investieren. Ein spät im Prozess auftauchendes Veto, weil Beteiligte nicht gut informiert waren, ist in jedem Fall mindestens ärgerlich.

‍

Planung

Es lohnt sich, ein Tool-Management-System zu etablieren. Dabei muss es sich aber keinesfalls um ein spektakuläres Tool handeln, sondern kann auch eine simple Inventarisierung sein. So wird nicht nur der Überblick behalten, sondern Maintenance-Prozesse werden auch einfacher zu managen. 

Ist der breitere Einsatz von Open-Source-Lösungen geplant, ist es ratsam, sich frühzeitig mit Richtlinien für den Einsatz auseinander zu setzen. Die Richtlinien geben den Rahmen für verschiedene Fragen vor: In welchen Bereichen können OS-Tools eingesetzt werden und in welchen nicht? Wie laufen Autorisierungen dafür ab? Wie ist bei POCs vorzugehen? Welche Setups sind möglich, welche nicht? Unserer Erfahrung nach sollten Unternehmen diese nicht in Stein meißeln, sondern regelmäßig überarbeiten. OS-Tools haben den Vorteil eines hohen Innovationstempos – und davon wollen Unternehmen ja schließlich profitieren, und es nicht intern blockieren. 

‍

Deployment und Updates

Typischerweise wird im Open-Source-Bereich auf den CI/CD (Continuous integration, continuous delivery/continuous deployment)-Ansatz gesetzt. Das Deployment erfolgt häufig in ein Kubernetes-Cluster. Das Helm-Konfigurationsframework hat sich dabei enorm bewährt. 

Neue Releases gibt es meist in einer deutlich höheren Frequenz als bei kommerziellen, proprietären Lösungen, z.B. 1x im Monat. Die Funktionen werden dazu paketiert und als Docker-Image auf einem Image-Server gehostet. 

Hat ein Unternehmen den Release-Prozess einmal sauber aufgesetzt, kann dieser zu gut 95% automatisiert erfolgen. Das Ganze dauert dann nur wenige Minuten. 

Für die Updates gilt: Installieren Sie so oft wie möglich, aber warten Sie circa zwei Wochen nach dem Releasetag ab. Das gewährleistet sowohl Stabilität als auch Sicherheit. Es empfiehlt sich außerdem, die Release-Notes genau zu prüfen, um individuelle Elemente unter Umständen anzupassen. 

‍

Tests

Stellen Sie sicher, dass Sie die wichtigsten Funktionen testen, bevor das Update in Produktion geht. In den meisten Fällen haben Unternehmen eine getrennte Struktur aus Development-Umgebung und Produktions-Umgebung und klar definierte Vorgehensweisen und Dokumentationsrichtlinien. Falls nicht, sei das an dieser Stelle wärmstens empfohlen. Ebenso entlastet eine Automatisierung der Tests die IT-Mitarbeiter insbesondere auf lange Sicht. 

Der Umfang der durchzuführenden Tests hängt ganz allgemein immer von der Applikation, der umgebenden Infrastruktur und der Funktion ab. Je größer das Risiko bei einer Fehlfunktion ist, desto akribischer ist zu prüfen. Setzt Ihr Unternehmen, wie unter “Deployment und Updates” empfohlen, auf CI/CD, ist der Testaufwand zumeist überschaubar. 

‍

Fazit

Sie werden festgestellt haben, dass diese Best Practices a) kein Hexenwerk sind und b) sich natürlich auch sehr gut auf alle OS-Tools und auch viele kommerzielle Softwarebereiche übertragen lassen. Je nachdem, wie Softwaredeployment-Prozesse derzeit in Ihrem Unternehmen aufgesetzt sind, kann ein OS-Tool allerdings durchaus eine Modernisierung aktueller Vorgehensweisen erfordern. Unsere Erfahrung dazu ist, dass es sich lohnt, bereits jetzt diese Prozesse zu modernisieren. Entwicklungszyklen von Tools werden kürzer und Datenarchitekturen individueller. Betrachten Sie die Einführung eines OS-Tools als Chance, Innovation zu ermöglichen und die Zukunft zu verproben.