Datenengineering-Manifest

Das Manifest ist eine Reihe von Prinzipien, die sicherstellen, dass Ihre Projekte pünktlich geliefert werden, Ihre Mitarbeiter befähigt werden und die Stabilität Ihrer Produkte gewährleistet ist.

Dies basiert auf unserer gemeinsamen Erfahrung aus all unseren Projekten.

1. Wir sind Software-Ingenieure.

Ein Dateningenieur erstellt Software, indem er Code schreibt und dabei bewährte Praktiken befolgt. Dazu gehört die Annahme von Software-Design-Prinzipien, Versionskontrolle, automatisierten Tests, CI/CD, Cloud-Native und DevSecOps-Praktiken.

2. Daten sind ein Produkt.

Ohne Kunden, die es tatsächlich nutzen oder kaufen, generiert das Daten nichts. Es ist ein Produkt, und wir sollten es wie eines behandeln und messen, wie erfolgreich es ist: Nutzung, Markteinführungszeit, Qualität, Verfügbarkeit, ...

3. Wir ermöglichen dies, indem wir Selbstbedienungslösungen anbieten.

Als Dateningenieure bauen wir maßgeschneiderte Datenpipeline für komplexe Anwendungsfälle. Für häufigere Anwendungsfälle bieten wir Selbstbedienungslösungen an. Wir sind ein Ermöglicher in einer Organisation.

4. Wir setzen auf Cloud- und Managed-Services.

Öffentliche Cloud-Anbieter haben das Spielfeld des Daten-Engineerings in den letzten Jahren drastisch verändert. Sie haben die Flexibilität erhöht und gleichzeitig die betrieblichen Belastungen verringert. Es gibt immer noch gültige Ausnahmeszenarien, aber die Cloud ist der neue Standard.

5. Die Batchverarbeitung ist einfacher als die Streamverarbeitung.

Während es interessanter sein könnte, einen Echtzeit-Datenstrom aufzubauen, kann dies unnötige Komplexität (Zustand, Wiederholung, ...) hinzufügen. Wenn Ihr Anwendungsfall nur einmal täglich Daten erfordert, halten Sie es einfach, halten Sie es dumm, halten Sie es nachhaltig! Das bedeutet nicht, dass wir bei Bedarf auf die Streamverarbeitung verzichten.

6. Wir streben nach Einfachheit durch Konsistenz.

Konsistenz ist eine mächtige Waffe, doch es gibt keinen goldenen Hammer. Für jeden Anwendungsfall versuchen wir zuerst bestehende "langweilige" Technologien, anstatt eine Technologie auszuwählen, um unser eigenes Wissen und unsere Erfahrung zu erweitern. Wir werden Technologien an der Spitze der Entwicklung einsetzen, wenn wir einen guten Grund dafür haben.

7. Notebooks sind für Forschung, nicht für Entwicklung.

Notizbücher bringen zu Beginn eines Datenprodukts Wert, wenn man Daten erkundet, nach potenziellen Lösungen sucht und dabei dokumentiert. Die Struktur von Notizbüchern fördert jedoch keine guten Softwaredesignmuster. Sobald Sie mit der Erkundung fertig sind, ist eine geeignete IDE das richtige Werkzeug für die Aufgabe.

8. Datenwissenschaftler sind unsere Kollegen, nicht unsere Sterblichen Feinde.

Dateningenieure und Data Scientists teilen sich einen gemeinsamen Technologiestack, spielen jedoch oft eine unterschiedliche Rolle in der Organisation. Dies kann zu einer dysfunktionalen Ehe führen, muss es aber nicht. Wir arbeiten zusammen und sehen die besten Ergebnisse in funktionsübergreifenden Teams entstehen.

9. SQL ist der niedrigste gemeinsame Nenner.

Im Laufe der Jahre haben wir den Aufstieg von domänenspezifischen Sprachen und Drag-and-Drop-Tools erlebt. Nichts kommt der Ausdruckskraft und Akzeptanz von SQL nahe. Wir sehen es als die Brücke, um weniger technische Profile zu ermöglichen, und bevorzugen es als Schnittstelle in Self-Service-Lösungen.