Dateninventare im EU Data Act

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mal wieder mit Stefan Negele. Hallo Stefan.

Stefan Negele: Hallo. Schön hier zu sein.

Sven Johann: Ja, der Stefan hat einen Artikel geschrieben: „Dateninventare im EU Data Act, die Demokratisierung der IoT-Geräte“. Ich muss sagen, der Artikel ist so halb an mir vorbeigegangen, bis ich gehört habe, dass es Nachfragen gibt. Er war erfolgreich, und wir müssen jetzt unbedingt noch mal darüber reden. Der große Erfolg des Artikels führt zu dem heutigen Podcast. Man könnte auch sagen, aus meiner Sicht ist der Untertitel: „Sven Johann rantet über Regulierungen“. Aber wir wollen hier versuchen, aus diesem EU Data Act etwas Positives für die Firmen herauszuholen, die sozusagen am Galgen dieses Acts sind. Ich kenne mich nicht besonders gut mit diesem Act aus, aber ich werde gleich noch ein bisschen darüber ranten. Genau, jetzt habe ich schon zu viel gesagt. Vielleicht noch mal ganz kurz etwas über dich. Du beschäftigst dich hauptsächlich mit Data Governance Themen bei INNOQ. Sonst noch etwas Wichtiges?

Stefan Negele: Genau. Ja, ich hatte es, glaube ich, in der letzten Folge, in der wir gesprochen haben, schon gesagt. Ich bin Software-Ingenieur, Software-Architekt, komme aus der Ecke, bin jetzt stark im Datenthema und komme da immer mehr rein. Ich fange jetzt sogar an, selbst Machine Learning zu lernen, weil ich es so cool finde. Ja, spannendes Thema, finde ich cool, und Data Governance ist aber das, wo ich mich mittlerweile sehr gut auskenne, und deswegen reden wir auch heute fleißig darüber.

Sven Johann: Genau. Ich steige direkt mal mit einem kleinen Rant ein, einfach nur, damit ich meine Perspektive kurz dazu bringe. Zu Regulierungen: Wir gucken ja gleich noch mal auf diesen EU Data Act, mit dem ich tatsächlich nichts zu tun hatte, aber ich habe mit anderen Regulierungen zu tun, und meine grundsätzliche Einstellung ist, das sind alles immer gut gemeinte und sinnvolle Ideen, die da drin stehen. Aber im wahren Leben führt es immer zum völligen Desaster und zum Gegenteil. Zumindest ist es der 100-Prozent-Fall, aber es ist halt bewusst breit gehalten, und praktisch alle meine Kunden haben immer Angst vor dem Wirtschaftsprüfer. Es ist unklar, was zu tun ist, deswegen machen wir immer das Komplizierteste, damit wir da ja nicht zur BaFin laufen müssen. Also ich bin grundsätzlich schon mal negativ eingestellt gegenüber Regulierungen, obwohl die Ideen meistens gut sind. Genau, jetzt meine negative Grundeinstellung, aber wir wollen natürlich etwas Positives hier rausnehmen. Und zwar positiv im Sinne von: Was können wir eigentlich, wenn wir von diesem EU Data Act betroffen sind? Ich stricke es mal so negativ aus: Was können wir Positives daraus ziehen? Und da hast du ja diesen Artikel geschrieben, und jetzt würde ich direkt mal mit einer Einstiegsfrage anfangen: Es heißt ja die Dateninventare im EU Data Act. Was ist überhaupt ein Dateninventar im Sinne des EU Data Acts?

Stefan Negele: Okay. Also der EU Data Act, vielleicht fangen wir da an. Der EU Data Act sagt knapp gesagt, dass Hersteller von vernetzten Geräten, also ich würde mal sagen, umgangssprachlich IoT-Geräte, also alles, wo ein Netzwerkstecker dran ist oder ein WLAN-Chip eingebaut, ihren Konsumenten oder den Kunden, die Person, die diese Produkte kaufen, einen sauberen Datenzugang geben müssen. Sie müssen ihnen die Daten, die die Kunden mit der Nutzung dieser Geräte erzeugen, auch zur Verfügung stellen. Wichtig dabei ist, dass diese Schnittstellen da sind, also die muss schon da sein, der Kunde muss das oder die Person muss das nicht extra anfragen, sondern das muss vorbereitet sein. Das Ganze muss auch irgendwie kostenfrei sein, und die Idee dahinter ist, dass eben die Kunden von Produkten mit den Daten, die sie erstellen, beispielsweise, wenn ich jetzt eine Firma bin, die irgendwie eine Industriemaschine hat, die etwas produziert und da entstehen dann eben Daten, dass ich eben mit diesen Daten selbst etwas anfangen kann, um quasi mein eigenes Unternehmen zu optimieren. Also ich habe dann sozusagen die Chance, damit irgendwie datengetrieben zu arbeiten. Und auf der anderen Seite sollten dadurch eben auch wahrscheinlich irgendwie neue Industriezweige oder neue Geschäftsfelder entstehen, dass man sagt, hey, wir können vielleicht Drittanbieter können vielleicht eben für andere Leute diese Daten auswerten und eben irgendwie etwas zur Verfügung stellen und eben diese Datenmonopolisierung bei den Herstellern von den Geräten irgendwie so ein bisschen aufzulösen. Das und jetzt kommen wir aufs Dateninventar. Das Dateninventar ist im Prinzip dabei dann eben ein Katalog, der eben eine Übersicht gibt über die ganzen Daten, die anfallen und wie ich darauf zugreifen kann. Das soll eben strukturiert sein, das soll irgendwie Kontext geben, also welches Gerät ist es, es soll irgendwie eine fachliche, eine semantische Beschreibung dazu, was bedeuten denn diese Daten, die da sind. Informationen, wie kann ich zugreifen? Sowas muss da eben drin stehen.

Sven Johann: Ja, ja, also das kann ich gut nachvollziehen. Meine eigene Geschichte dahinter ist schon zehn Jahre her oder so, da habe ich mal mit Herstellern von Bierbraumaschinen geredet. Und die haben erstmal gar nicht über diese Bierbraumaschinen gesprochen, sondern über Flugzeugturbinen, weil die gesagt haben, hey, uns ist aufgefallen, Rolls-Royce baut ja nicht nur Autos, ich meine, wir beide haben ja eine in der Garage, und die bauen nicht nur Autos, sondern die bauen auch Turbinen für Flugzeuge, und die verkaufen diese Turbinen, also ich weiß gar nicht, wie das heute ist, aber die Idee war, diese Turbinen nicht mehr zu verkaufen, sondern so Turbine as a Service.

Der Vorteil ist für alle zu sagen, ja, ich muss jetzt keine große, teure Anschaffung machen, mit so Flugzeugturbinen, sondern so wie Cloud. Also so wie du Cloud Compute aus der Steckdose bekommst, kriegst du halt auch Flugzeugturbinen aus der Steckdose. Du hast so einen konstanten Preis, den du halt immer bezahlst, und Rolls-Royce sorgt halt dafür, dass die Turbine immer in einem super Zustand ist. Und Rolls-Royce hat natürlich den Vorteil eines konstanten Revenue Streams, aber halt auch die wissen, weil sie die Daten sammeln über diese Flugeigenschaften, wissen die natürlich auch ideal, wann so eine Wartung stattfinden muss.

Und jetzt ist die Frage, also die Flugzeugunternehmen geben halt diese Turbinendaten gerne weiter, aber bei den Bierbrauern ist natürlich immer so die Angst, ja, wir könnten natürlich auch Bierbraumaschinen verleihen, nicht verleihen, sondern zu ‘Rent a Bierbraumaschine’.

Und dann wird dann vielleicht, sag mal, Hersteller von dieser Bierbraumaschine, gibt es unterschiedliche deutsche Firmen, die werden dann vielleicht zu Superbrauern, weil die natürlich alle Geheimnisse von allen Firmen kennen. Und da natürlich ist es so, dass man denkt, ah, jetzt kennen die natürlich meine Braudaten, kennen die vielleicht sogar besser als ich, ne?

Stefan Negele: Genau.

Sven Johann: Aber wenn ich so ein Dateninventar anbiete, dann…

Stefan Negele: Na, dann habe ich zumindest auch selbst Zugriff drauf, ne? Also klar, das ist, also die werden das ja weiterhin selbst auch auswerten können, also ob das jetzt vermietet ist oder verkauft, ich weiß auch nicht, wie das bei vermieteten Geräten ist, das weiß ich gar nicht. Ich bin auch kein Jurist, deswegen kann ich da, also, wenn ihr da betroffen seid, sprecht mal mit dem Juristen noch mal konkret, ne? Wir beleuchten das nur quasi aus IT-Sicht. Aber es geht schon darum, dass die Daten, die da eben produziert werden und die eben, du meintest ja gerade, vielleicht weiß der mehr über meine Bierbrauung als ich selbst, dass ich diese Hoheit wieder zurückgewinne, dass ich eben sagen kann, ich kann auch das jetzt auswerten und kann vielleicht als Bierbrauer beispielsweise den Prozess, den ich da habe, kann ich vielleicht noch optimieren, kann vielleicht die Zusammensetzung irgendwie anpassen, weil vielleicht irgendwie aus der Sensordate sich ja ergibt, dass vielleicht Bestandteil XY, ich bin kein, ich kann nicht Bierbrauen, ich habe mal so ein Bierbrauset gehabt, aber da habe ich zusammengekippt und die Hälfte ist nichts geworden, deswegen kann ich da nicht viel dazu sagen, aber ne, vielleicht kann man sagen, ne, vielleicht gibt’s ja irgendwie einen Überschuss an einem bestimmten Bestandteil, den man eigentlich vielleicht gar nicht braucht, dann kann ich irgendwie Kosten sparen und sowas. Solche Prozesse eben zu optimieren, vielleicht irgendwie Temperaturen irgendwie anzupassen, ich kann das ja dann vielleicht ja auch irgendwie zusammenbringen mit irgendwie den Informationen, die dann meine Nutzenden oder ja, also die Person, die das Bier dann trinken, dann irgendwie vielleicht mir auch als Feedback geben, oder was oder mit Verkaufszahlen, die hat dann der Hersteller von dem Gerät nicht, dann könnte ich vielleicht sagen, oh, ich habe ja die Verkaufszahlen von dem und jetzt habe ich die Zusammensetzung ein bisschen angepasst und plötzlich verkauft sich es besser oder schlechter, vielleicht hängt das ja mit zusammen. Und das geht natürlich nur, wenn ich das auswerten kann und wenn ich die Daten grundsätzlich überhaupt zur Verfügung habe.

Sven Johann: Ja. Also ich denke schon, dass sie natürlich viel auf Papier haben, also so pH-Werte und so weiter, ne? Und wahrscheinlich kann man da auch ein Excel, ne, also Enterprise Funktionalität CSV Export machen, aber ich gehe davon aus, dass natürlich der, dass in aller Regel, weil wir haben ja auch Kunden, die so Geräte bauen, also jetzt nicht unbedingt Bierbraumaschinen, aber andere Sachen. Wir wissen natürlich viel mehr als das, was in der App oder auf der Webseite angezeigt wird, ne? Und dass man praktisch die Daten zur Verfügung stellt. Jetzt ist natürlich so, das ist für das kann man sagen, schön für den Käufer des Systems, aber ist ja erstmal blöd für mich als Gerätehersteller, weil kostet mich Geld, ja? Und also ich sag mal zwei Sachen, ne? Geld und ich weiß vermutlich gar nicht so ganz genau, was sie von mir wollen und ich kann auch niemanden fragen, aber sag mal dieses Thema würde ich erstmal ausklammern, ja? Also so dieses allgemeine Regulierungsproblem, aber ich muss auf jeden Fall irgendwas bauen. Und das kostet mich bauen und betreiben und das kostet mich, das kostet mich einfach Geld und jetzt kann man sich halt fragen, was kann ich tun, also aus diesem Zwang, wie kann ich da irgendwie trotz allem noch strategisch Potenzial oder irgendwelche Vorteile da rausziehen, dass ich das machen muss?

Stefan Negele: Ja, also genau, vielleicht erstmal: Es ist natürlich klar, dass es erstmal Frust erzeugt, wenn ich sage, jetzt muss ich hier zusätzlich etwas bauen, das kommt aus einer Regulierung. Das verstehe ich auch, ne? Da sind wahrscheinlich manche auch stärker betroffen als andere. Aber was ich vielleicht für mich eben mitnehmen kann, und vor allem, wenn ich mich schwertue, so ein Inventar und solche Schnittstellen zu erzeugen, ist, dass ich vielleicht meinen eigenen Datenhaushalt, nenne ich es mal, nicht sauber strukturiert und nicht unter Kontrolle habe. Also ich würde behaupten, wenn ich so ein Inventar erzeuge, entweder habe ich grundsätzlich ein System, wo ich das quasi mehr oder weniger mit einem Fingerschnipsen exportieren kann. Ja, bisschen übertrieben jetzt, aber grundsätzlich habe ich schon die Informationen und muss das sozusagen nur noch nach außen geben und gucken, und vielleicht noch mal einen Anwalt drüber gucken lassen. Oder quasi die Gegenseite: Ich habe quasi nur reines Chaos in meinen Daten und habe dann aber auch einen Anhaltspunkt, dass ich sehe, wahrscheinlich arbeitet meine Organisation nicht sonderlich gut mit Daten. Also es ist ja innerhalb der Organisation auch nicht klar, wer hat welche Daten, wie kann darauf zugegriffen werden, was bedeuten diese Daten? Und das ist eben die Chance, die ich sehe, dass man sagt, hey, man wird zwar jetzt von außen gezwungen, irgendwas für externe Konsumenten/Kunden zu tun, aber lass uns das doch einfach nutzen und sagen, okay, dann räumen wir einfach mal bei uns auf und führen vielleicht eine moderne Datenarchitektur ein, die sowas eben auch unterstützt. Und haben danach vielleicht einfach intern auch eine bessere Art, mit Daten umzugehen, und Kompetenzen innerhalb der Belegschaft, wie ich mit Daten arbeite.

Sven Johann: Ja, ich denke, es gibt mindestens zwei Möglichkeiten. Die eine ist natürlich, ich stelle diese Daten irgendwie zur Verfügung und mache ganz viel Dokumentation und so weiter und so weiter, um einen Wirtschaftsprüfer oder wer das auch immer prüft, zu beruhigen, ja? Also einfach mit Informationen überschütten. Ist eine Möglichkeit, ne, dass man sagt, okay, hier haben sich viele Gedanken gemacht. Die andere Möglichkeit ist, wir haben eine moderne Datenarchitektur, die nachvollziehbar ist und die, ich weiß nicht, ob die mehr kostet oder weniger kostet. Tendenziell hätte ich schon fast gesagt, das kostet weniger, weil ich sage mal, so komplizierten Wahnsinn, ich sehe es bei vielen Kunden, irgendwann muss man diesen komplizierten Wahnsinn abbauen, weil das Unternehmen lähmt und dann lieber eine, ich sage mal, eine einfache, saubere, nachvollziehbare Lösung, die auch ein Wirtschaftsprüfer oder wer auch immer das prüft, nachvollziehen kann. Und ja, also dass man sagt, wir bauen jetzt eine moderne Datenarchitektur, ja? Wie würde denn, wie sieht denn so eine moderne Datenarchitektur aus - speziell, ich sag mal, mit dem Hintergrund EU Data Act und Dateninventare?

Stefan Negele: Also in meinen Augen ist eben eine moderne Datenarchitektur datenproduktgetrieben und eben auch föderiert. Es gab vor ein paar Jahren den Begriff Data Mesh, heute sagt man eigentlich eher datenproduktorientierte Architekturen oder eben föderierte Architekturen. Und das Gute an solchen Architekturen ist eben, dass Daten als Produkte dargestellt und innerhalb des Unternehmens, vielleicht auch extern, gerade wenn wir eben jetzt über den Data Act reden, zur Verfügung gestellt und eben auch beschrieben werden, wirklich als Produkte. Wir haben ja auch eine andere Folge darüber, wo wir darüber geredet haben, was Datenprodukte sind. Und das Gute ist, wenn ich sowas habe, dann habe ich quasi das Fachwissen aus dem Team, das meine Daten beschreibt, und habe das auch in einem Katalog oder in einem Datenmarktplatz, wo ich eben eine Übersicht über sämtliche Daten habe und da vor allem gut aufbereitet. Mit Semantik, und Semantik ist vor allem in dem Fall sehr, sehr wichtig. Und somit habe ich quasi schon mal eine Gesamtübersicht über alles, was in meinem Unternehmen anfällt, und kann das dann eben als Grundlage nehmen für so ein Dateninventar und kann entsprechend auch diese Daten dann auch vielleicht nach außen weitergeben. Ich sehe auch schon, wo sind denn vielleicht personenbezogene Daten drin, die ich nicht nach außen geben darf, wo sind denn vielleicht sonderlich schützenswerte Daten drin, die Geschäftsgeheimnisse beinhalten, die ich nicht nach außen geben muss. Also da gibt es ja auch Restriktionen in dem Data Act, dass ich beispielsweise nichts veröffentlichen muss, was irgendwie einem Konkurrenten helfen könnte, ein Konkurrenzprodukt aufzubauen mit den Daten, die er bei mir rausliest und so weiter.

Sven Johann: Ach so, das bedeutet, ich nenne mal ein Beispiel, also ich bleibe noch bei unseren Braumaschinen. Ich als Brauer A kaufe mir eine Braumaschine von Brauer B und analysiere, welche Daten da rauskommen, oder wie muss ich mir das vorstellen?

Stefan Negele: Ja, oder eben vielleicht eher sowas, ich sage, ich bin Brauer und miete mir meine Maschine beim Braumaschinenhersteller und beauftrage aber einen Dienstleister, mir diese Daten auszuwerten. Jetzt darf dieser Dienstleister die Daten nicht nutzen, um selbst in zwei Jahren plötzlich eine baugleiche Braumaschine auf dem Markt zu bringen.

Sven Johann: Ja, interessant, weil ich würde halt sagen, völlig normal in anderen Branchen. Also, ich bin mir ziemlich sicher, dass jeder Automobilhersteller vor zehn Jahren sich einen Haufen Teslas gekauft hat, um die auseinanderzunehmen, um zu gucken, wie funktionieren die überhaupt, oder egal welche Maschinen, ne? Also, man kauft sich ja eigentlich immer Konkurrenzprodukte, um die zu analysieren, aber die Daten, da gibt es Regeln.

Stefan Negele: Ja, also es soll halt nicht jetzt, es geht hier darum, dass wir nicht irgendwie eine Regulierung auf EU-Ebene stattfinden lassen, die Industriespionage irgendwie fördert. Also, das ist eben die klare Abgrenzung an der Stelle. Also, wie es dann genutzt wird, ist natürlich die andere Frage, aber da kann ich als Hersteller schon auch gucken, was gebe ich denn da oder als Gerätehersteller eben raus. Was gebe ich denn da raus, muss ich denn dieses Datum wirklich nach außen geben oder vor allem muss ich das extern zur Verfügung stellen?

Sven Johann: Ja, du hattest ja auf die vorherige Folge referenziert, aber kannst du vielleicht noch mal ein bisschen, also so den zwei, drei Minuten Überblick geben über Datenprodukt beziehungsweise Datenproduktkataloge oder Data Marketplace, was das ist?

Stefan Negele: Genau, kann ich gerne machen. Datenprodukte sind eben, ich hatte auch letztes Mal gesagt, es gibt keine Definition dafür, aber man kann sich es grob vorstellen, wie alles, was dazugehört, um einen Datensatz anzuzeigen. Also, irgendwie, ich habe Quellsysteme, ich habe irgendwelche Transformationen, die stattfinden, ich habe irgendwelche Cleaning Jobs, die die Daten reinigen, und ich habe dann irgendwie einen Output Port, wie wir auch klassisch in der Softwarearchitektur von Output Ports sprechen, wo ich dann eben diese Daten, genau, Schnittstellen zur Verfügung stelle.

Da hängt dann ein Data Contract dran, auch ein Thema, über das wir hier in dem Podcast oder du mit Simon Harrer schon gesprochen hast und wir letztes Mal das auch mal kurz angeschnitten haben. Und da wird dann eben das sauber beschrieben. Auch wichtig für unser Dateninventar wieder. Wir haben da schon eine Stelle, wo das sauber beschrieben wird, wo Semantik sauber beschrieben ist, wo die Qualität der Daten sauber beschrieben ist. Das sind grundsätzlich Datenprodukte, also Daten gesehen nicht als reines Daten-Asset oder als irgendeine Tabelle, die irgendwo in meiner Cloud liegt, sondern wirklich als Produkt, das ich an andere weitergeben will. Ein Data Marketplace ist eben dann der Marktplatz oder der Ort, wo diese Daten dann entsprechend angeboten werden, der auch Funktionalität zur Verfügung stellt, um irgendwie diese Daten sauber zu produzieren und dass die Regeln, die in meiner Organisation gelten, um mit diesen Daten zu arbeiten, auch wiederum eingehalten werden oder es mir auch leicht gemacht wird, diese einzuhalten.

Sven Johann: Ja, also ich meine, grundsätzlich denke ich immer so automatisch an die Person, die mich prüft.

Bei Gesetzen und da ist natürlich hilfreich, wenn man, ich erfinde nichts für diesen Fall, sondern wenn ich sagen kann, ich habe hier so ein klares Konzept basierend auf existierenden Konzepten, dann bin ich einmal, also ich sehe zwei Vorteile drin. Selbst erfinden ist eh immer blöd, lieber irgendwas nutzen, was schon funktioniert, dann kann ich einen Haufen Vorteile schon mal für mich rausziehen, wenn es ja unser Take hier, aber ich muss auch gar nicht so viel dokumentieren, ne, weil ich einfach nur sage, ich benutze diese Dinge. Da sind sie, Data Product, Data Marketplace, Data Contracts und dann kann man sich den Rest zusammensuchen. Das ist schon mal eine gute Sache.

Stefan Negele: Absolut. Und ich habe eben auch Gründe, warum ich beispielsweise Daten nicht rausgebe und kann auch beweisen, dass das vollständig ist, und habe auch schon grundsätzlich dokumentiert, wenn ich eine interne moderne Datenplattform habe, wie der Zugriff dafür funktioniert. Das heißt, der Schritt dahin, wie der Zugriff extern funktioniert, ist wahrscheinlich auch noch mal einfacher. Sowas wie Autorisierungskonzepte und so weiter sind schon da. Ich bin auch, ist auch eine Sache, die der Data Act vorgibt, die Daten sollen in gängiger Art und Weise ausgegeben werden, was auch immer jetzt gängig heißt.

Für mich heißt gängig eine REST-Schnittstelle oder irgendwie der genannte CSV-Export und jetzt nicht irgendein kryptisches proprietäres Dateiformat, das man erstmal lizenzieren muss oder sowas. Und sowas habe ich dann einfach auch schon alles. Und es ist halt irgendwie alles quasi by Design schon da. Also, ich habe by Design schon den ganzen Blumenstrauß an Dingen, die ich eben brauche, um diesem Dateninventar gerecht zu werden.

Sven Johann: Wenn ich jetzt an ein paar Kunden von uns denke: Wir haben im Vorgespräch schon darüber gesprochen, dass ich eigentlich mit dem und dem vorab hätte reden müssen. Wir haben ja auch einige Kunden aus dem IoT-Bereich, größere Unternehmen, die schon lange Software und Hardware entwickeln. Ich behaupte, die haben bereits Dateninitiativen am Laufen und denken über Data Contracts und Data Products nach. Sie würden also sagen, dass sie schon etwas haben und eine weitere Argumentation benötigen, um Geld zu bekommen und in die richtige Richtung zu gehen. Aber bei kleineren Unternehmen, die vielleicht noch nicht so softwareintensiv sind und gerade erst damit angefangen haben, zum Beispiel mit kleineren Geräten, bei denen noch nicht viel Software und Software-Know-how vorhanden ist: Kann man da auch im Kleinen anfangen, oder ist eine moderne Datenarchitektur immer direkt ein riesiges Projekt?

Stefan Negele: Nein, natürlich nicht. Eine Data Mesh Architektur, so wie sie ursprünglich beschrieben ist, macht für ein kleines Unternehmen keinen Sinn. Eine föderierte Architektur macht für ein kleines Unternehmen keinen Sinn. Wir führen ja auch keine Microservices ein, wenn wir nur ein Software-Team haben. Dafür brauchen wir schon sehr gute Gründe. Aber ich kann natürlich anfangen, meine Daten von vornherein sauber zu beschreiben, Dokumentation zu erstellen und Informationen über Datenqualität, die meistens in den Köpfen der Menschen vorhanden ist, zu dokumentieren. Und dann eben auch diese Denkweise zu entwickeln, mit diesen Daten zu arbeiten und die eigenen Prozesse damit zu optimieren. Eben zu überlegen: Welche Daten produziert mein Gerät beispielsweise oder vielleicht irgendwelche anderen Prozesse, und wie kann ich die nutzen, um das Produkt zu optimieren und meinem Nutzer eine bessere Erfahrung zu bieten?

Sven Johann: Ja, genau. Diesen Punkt haben wir noch gar nicht durchleuchtet. Ich denke über Daten nach, aber natürlich nicht nur darüber, dass meine Konsumenten die externen Kunden sind. Das muss ich tun. Aber ich habe natürlich auch, wenn ich es schon mache, interne Kunden, mit denen ich spreche und denen ich weitere Datenprodukte anbiete, um uns selbst innerhalb unseres Unternehmens zu verbessern.

Stefan Negele: Genau, das ist ja genau die Chance, die ich in dem Artikel beschrieben habe: Wenn wir schon gezwungen sind, unsere Daten zu organisieren, dann nehmen wir das doch jetzt als Anhaltspunkt. Und geben die Daten nicht nur anderen zur Auswertung, sondern nutzen sie auch selbst und strukturieren sie so, dass sie auch in einem kleineren oder größeren Unternehmen von allen genutzt werden können. Das ist ja eben auch Teil einer modernen Datenarchitektur, dass alle tendenziell, sofern das rechtlich in Ordnung ist, auch Zugriff auf die entsprechenden Datensätze haben.

Sven Johann: Ja, und es können auch ganz andere Datenprodukte sein. Ich stelle mir das so vor: Wenn ich jetzt wieder an unsere Kunden denke, wir haben natürlich Daten über unsere Kunden, die wir dem Kunden zur Verfügung stellen. Aber es gibt natürlich noch einen Haufen anderer Daten, die auf so einem Gerät anfallen. Die sind vielleicht für diesen EU Data Act völlig irrelevant, aber für uns intern können wir natürlich auch überlegen, welches Datenprodukt wir daraus machen.

Stefan Negele: Ja, und intern kann ich da auch noch mal anders skalieren. Ich sage intern, ich muss dem Kunden ja auch nur die Daten über seine Nutzungsdaten geben. Nicht die Nutzungsdaten von allen Kunden, aber ich gebe dem Kunden nicht die Daten von seinen Mitbewerbern.

Sven Johann: Ja, genau. Du hast in dem Artikel auch über Data Literacy als Erfolgsfaktor gesprochen. Was ist überhaupt Data Literacy, bevor wir sagen, warum es ein Erfolgsfaktor ist?

Stefan Negele: Ich hatte es, glaube ich, schon kurz angeschnitten. Ich versuche es jetzt noch mal klarer zu machen. Zu Deutsch heißt Data Literacy Datenkompetenz. Es gibt da ein paar Definitionen. Ich finde die von Jordan Morrow ganz gut, der ein Buch geschrieben hat, das heißt ‘Be Data Literate’. Ich habe es mal versucht, aus einem anderen Artikel, der hoffentlich schon da ist, wenn dieser Podcast hier erscheint, ins Deutsche zu übersetzen. Und zwar lese ich jetzt vor: Data Literacy ist die Fähigkeit, Daten zu lesen, mit ihnen zu arbeiten, sie zu analysieren und mit ihnen zu kommunizieren. Ganz spannend ist eben auch dieses ‘mit ihnen zu kommunizieren’. Das eine ist, ich muss Daten verstehen, also das Lesen. Ich muss irgendwie mit ihnen arbeiten können, also ich muss sie vielleicht transformieren können. Ich muss vielleicht aber auch nur Tools beherrschen. Die meisten können so etwas wie Excel, das ist ja schon ein sehr mächtiges Datentool. Und daran kann ich dann vielleicht auch Daten analysieren. Vielleicht habe ich aber auch ein Tool wie Power BI, wo ich kleine Analysen starten kann. Und ich will diese Informationen, die ich daraus habe, auch nach außen tragen, kommunizieren und vielleicht auch erklären, warum ich bestimmte Entscheidungen getroffen habe und nicht irgendwie sagen: ‘Das war ein Bauchgefühl’, sondern: ‘Ich habe hier eine Datenbasis, und die zeigt eindeutig, dass das so gemacht werden sollte.’ Wichtig dabei ist, das klingt jetzt irgendwie alles sehr krass, aber Morrow schreibt eben auch, dass man kein Data Scientist sein muss. Nicht jeder muss ein Data Scientist sein. Es gibt natürlich Leute, die haben da Lust drauf, die kennen sich mit Statistik aus, die haben die mathematischen Formeln im Petto und so weiter. Das muss ich aber gar nicht, sondern ich muss nur ein grundsätzliches Gefühl dafür haben, um mit Daten zu arbeiten und keine Scheu davor zu haben. Das ist Data Literacy für mich.

Sven Johann: Wie komme ich eigentlich zu Data Literacy? Wie kann ich mir das beibringen? Vielleicht noch mal als kleiner Hintergrund der Frage: Ich habe in den letzten 15 Jahren, seit das Thema Data Driven Decision Making aufkam, oft erlebt, dass wir Daten sammeln und Entscheidungen auf Basis von Daten treffen, und dann kommt trotzdem jemand und sagt: ‘Wir machen es aber so.’ Und dann sage ich: ‘Die Daten sagen aber etwas ganz anderes.’ ‘Ist mir egal, was die Daten sagen.’ Das hatte ich tatsächlich noch letzte Woche. Da sind irgendwelche Zahlen schlecht, und zwei Datensätze zeigen eigentlich an, dass hier etwas passieren muss. Aber Umfragen haben ergeben, dass wir eigentlich nur bei Thema 2 etwas tun müssen. Der große Chef sagt aber, wir machen Thema 1 und 2, wo ich sage: ‘Die Benutzer haben mit Thema 1 gar kein Problem.’ ‘Mir egal.’ Wir machen beides. Okay, wenn du es bezahlen willst, dann bezahl. Aber da denke ich immer: Wie kann ich den Leuten das beibringen? Welche Lernpfade gibt es da?

Stefan Negele: Das kann man auch wieder ganz groß oder ganz klein spinnen.

Sven Johann: Fangen wir mit klein an.

Stefan Negele: Ja, das, was du erzählst, ist irgendwie, also im Management ist da, glaube ich, also das Management sollte erstmal auch die Datenkompetenz haben und das vorleben. Ich glaube, das ist da irgendwie ganz wichtig. Also, wenn meine Mitarbeiter schon so weit sind und sagen: ‘Hey, ich habe hier die Daten, wir sollten das so machen’, und das Management sagt dann aber: ‘Nee, wir machen das anders, weil ich finde das jetzt wichtiger’, dann wird es schwierig für die Organisation, weiterhin datengetrieben zu arbeiten, weil das muss auch von oben vorgelebt werden, sage ich mal. Das ist, glaube ich, ein ganz wichtiger Schritt, eben, also das Management braucht selbst diese Data Literacy und muss das auch erkennen, warum das wichtig ist. Und ich bin halt der Überzeugung, dass es sehr, sehr wichtig ist, das zu haben, um eben am Markt bestehen zu können. Weil wenn wir Mitbewerber angucken, globale Mitbewerber angucken, dann arbeitet irgendjemand datengetrieben. Und das ist ganz spannend, vor allem auch, was in China passiert. Da wird sehr stark datengetrieben gearbeitet, und da werden dann einfach westliche Firmen quasi vom Markt gedrängt, weil die eben den Markt nicht verstehen, und die Firmen selber verstehen aber den Markt, weil sie eben die Daten analysiert haben.

Sven Johann: Ja, ich glaube, so weit muss man gar nicht gucken. Ich hatte ja lange in Holland gewohnt, und da gibt es, der berühmteste Fall ist booking.com, aber es gibt auch einige andere Unternehmen, die schon vor langer Zeit mit dem Spruch herumrannten: ‘Data is the new Gold’, oder ‘Data is the new Oil’. Aber wie, vielleicht noch mal ganz kurz, wie würde man datenkompetent werden? Gibt es irgendwelche Kurse, auf die ich zeigen kann, nach dem Motto: ‘Guck dir das mal an’? Oder welche Möglichkeiten gibt es für so eine Firma, datenkompetent zu werden?

Stefan Negele: Natürlich gibt es mit Sicherheit Dienstleister, die da Dinge anbieten. Ich muss mir, glaube ich, aber erstmal meine Mitarbeiter ansehen und gucken, wie sie ticken, was die richtige Form ist, um mit Daten zu arbeiten. Sind reine Excel-Kenntnisse vielleicht schon mal ganz cool? Und dann würde ich auch versuchen, so etwas in der Firmenkultur zu verankern, eine Community of Practice zu erstellen, die eben auch sagt: ‘Hey, wir sind Menschen, die das spannend finden, wir setzen uns in regelmäßigen Abständen zusammen, arbeiten an Themen, tauschen uns zu den Themen aus, kommunizieren das vielleicht auch nach außen.’ Also, überlegen wir uns auch: ‘Hey, haben wir vielleicht einen Unternehmensblog, wo man Erfolge beschreiben kann, die bestimmte Leute mit Daten hatten?’ Und eben, das finde ich immer einen sehr guten Ansatz, zu sagen: ‘Okay, wir entwickeln sozusagen das Community Building.’ Und auf der anderen Seite kann ich natürlich auch meinen Mitarbeitenden Kurse anbieten, die kann ich vielleicht selbst gestalten, wenn ich groß genug bin, aber die kann ich natürlich auch einkaufen. Muss aber mir erstmal natürlich angucken, wen habe ich denn da vor mir, und was passt denn zu den Leuten?

Sven Johann: Ja, also im Grunde genommen gibt es zwei Möglichkeiten: Ich kann im Stealth Mode Grassroots-mäßig loslegen, aber als Leader kann man natürlich auch anfangen und sagen, wir wollen das tun. Und ich fange schon mal damit an. Also, wenn wir jetzt irgendwie, es muss nicht unbedingt der CEO sein, aber Director Level oder so.

Stefan Negele: Genau, und ich glaube, das ist ganz wichtig, und dass so etwas auch angenommen wird. Ohne Management Support funktioniert das halt nicht. Product Owner sollten so etwas natürlich auch verinnerlichen. Wenn sie die Hoheit über Produktentscheidungen haben, also ein Product Owner sollte ja die Ownership am Produkt haben, dann sollten sie das auch machen können. Dann sollten die Personen das eben auch vielleicht schon leben. Das ist vielleicht so die kleinste Gruppierung, wo ich sage, da könnte man so etwas starten, von unten kommend. Wenn ich sage, okay, wir sind jetzt ein Team und wir versuchen als Team datengetrieben zu arbeiten. Wir gucken uns an, was produzieren wir denn innerhalb unseres Produkts. Da brauche ich noch gar keine große Datenarchitektur. Dann speichere ich mir das vielleicht irgendwie für meine Analysezwecke in meine PostgreSQL ab, wenn ich nichts anderes zur Verfügung habe. Vielleicht habe ich aber auch, wenn ich auf der Google Plattform bin, BigQuery und kann da dann vielleicht ein bisschen performanter Analysen machen. Man kann es ja klein gestalten. Und das wiederum, wenn man so etwas macht, kann man natürlich auch Erfolgsgeschichten schreiben und vielleicht andere damit anstiften und sagen: Hey, guck mal, wir haben unsere Prozesse optimiert. Oder vielleicht auch, wenn ich es als Product Owner schwer habe, Priorisierungen zu setzen, weil ich verschiedene Stakeholder habe, die Dinge von mir wollen, dann kann ich vielleicht auch Entscheidungen so begründen und sagen: Hey, ich mache jetzt dieses Thema zuerst, weil das bringt uns beispielsweise mehr Revenue oder das ist sehr schnell zu erledigen. Oder das ist wirklich ein Problem, und das ist nicht nur, weil jemand laut schreit, sondern wir können mit Zahlen belegen, dass da wirklich sehr viele Kunden in Schwierigkeiten geraten, auch wegen einem bestimmten Prozess, den wir noch nicht optimiert haben.

Sven Johann: Ja, auf jeden Fall ziemlich spannend. Bei mir schwirren gerade zwei Geschichten im Kopf herum, wo Data Driven Product Owner im IoT-Umfeld waren. Die haben das auch gedacht und vorgelebt, aber man muss natürlich auch sagen, im IoT-Umfeld ist Software ein Teil der Wertschöpfung, aber natürlich nicht der wichtigste Teil. Das ist immer noch das Gerät, was man da verkauft. Und viele Engineers, also ich sage mal, wenn so ein Principal Chief Engineer von einem Gerät, die leben meistens nicht in dieser Datenwelt und die dann davon zu überzeugen. Das habe ich auf jeden Fall schon zweimal gesehen, wo ich gesagt habe, okay, vielleicht warten wir einfach bis der in Rente geht.

Stefan Negele: Aber vielleicht kann ich das auch nur anekdotisch aus meiner Software-Entwicklungsvergangenheit sagen. Ich habe das auch mal gemacht, also da war es noch nicht mal auf Teamebene, sondern wirklich nur ich als Software-Entwickler. Ich habe quasi auch mit einem IoT-Gerät, also meine Software hat mit dem IoT-Gerät gesprochen und hat sogar dieses IoT-Gerät gesteuert. Diese IoT-Geräte wurden aber eingekauft und die haben immer wieder Fehlerbilder erzeugt, die sich keiner erklären konnte. Der Produzent von diesen Geräten hat quasi gesagt: Ja, nee, passt nicht bei unseren Laborbedingungen, da stimmt das immer. Wir können nicht, das muss eure Software sein, die diese Fehler erzeugt. Und dann habe ich eben auch angefangen, Daten zu sammeln. Damals als Software-Entwickler war mein Tool der Wahl natürlich, ich habe irgendwelche Grafana Dashboards gebaut. Und das war dann plötzlich schwer, für die Person zu verargumentieren, wo die, ich hatte plötzlich Dashboards, die bewiesen haben, dass meine Aussagen stimmen. Ich konnte damit zu meinem C-Level gehen und sagen: Hey, ihr erzeugt bei uns hier gerade enorm viel Arbeit und ich kann auch beweisen, dass wir nicht schuld daran sind. Und das war sozusagen auch eine anekdotische Story, wo das dann auch eben funktioniert hat, weil dann eben jemand, der sich vielleicht weigert, oder ein Gerätehersteller, oder eben dieser Hardware-Ingenieur, der sich weigert, irgendwie damit zu arbeiten. Na ja, wenn du dem halt irgendwie die Daten schwarz auf weiß in einem Dashboard gibst, dann muss er erstmal vielleicht irgendwas dagegen setzen, vielleicht auch datengetrieben arbeiten, um seinen Standpunkt klar zu machen. Aber ein reines „Das stimmt aber nicht“ geht halt irgendwann nicht mehr.

Sven Johann: Ja, muss ich sagen, ich habe es trotzdem oft gehört, es ist ja ein bisschen frustrierend.

Stefan Negele: Das ist auch die Story, wo es bei mir mal ganz gut funktioniert hat, muss ich sagen.

Sven Johann: Ja, aber ich denke immer, man braucht einen langen Atem. Gut, wo sind wir gerade? Also, wir müssen Dateninventare anbieten. Wir können dieses Gesetz dafür nutzen, eine moderne Datenarchitektur aufzubauen. Das kann man auch im Kleinen starten, muss nicht direkt so ein riesen Investment sein. Genauso mit Data Literacy, kann man als Grassroots-Bewegung starten, aber natürlich kann man es auch Top-Down oder Bottom-Up machen. Das sind auf jeden Fall Erfolgsfaktoren. Wir müssen damit rechnen, dass selbst bei besserem Wissen und Gewissen es natürlich in so einem Unternehmen noch Leute gibt, die einfach dagegenhalten, weil es zu fremd, zu neu ist, zu „habe ich die letzten 50 Jahre nicht gemacht“, finde das einfach normal. Also, dieses Frustlevel, das gibt es einfach, ein bisschen Glück braucht man immer.

Stefan Negele: Das ist aber wahr, was wir tun, oder?

Sven Johann: Gibt es noch irgendwas, was du sagst, das wäre noch interessant zu wissen, was diese Dateninventare im EU Data Act angeht?

Stefan Negele: Ja, also wir hatten viel davon gesprochen. Ich glaube, was wir noch nicht so unterstrichen hatten, war eben, dass wir, wenn wir wirklich auch Data Contracts und eben solche Praktiken einführen, einen relativ schnellen Schritt dazu haben, diese Inventare leicht zu erzeugen. Das wollte ich noch mal unterstreichen. Vielleicht noch mal auf das Thema zurück, was denn jetzt irgendwie vielleicht in der Kommunikation mit einem Wirtschaftsprüfer oder so passiert. Hatten wir auch schon gesagt, dass wir dem irgendwie beweisen können: Hey, wir haben irgendwie ein vollständiges Dateninventar. Wir wissen vielleicht irgendwie, können auch begründen, warum irgendwelche Daten aus welchen Gründen auch immer, die DSGVO ist so ein Thema, nicht rausgegeben werden können oder an wen sie nicht rausgegeben werden können. Wir haben eben auch irgendwie Zugriffskonzepte oder Prozesse dafür. Wir haben vielleicht auch einen Nachweis, dass das by Design eingebaut ist, weil das ist auch eben was, was das Gesetz vorsieht, dass eben diese Produkte by Design so entwickelt werden müssen, dass sie eben die Daten bereitstellen können.

Bei Altprodukten ist es übrigens anders, da sagt das Gesetz explizit, ich weiß gar nicht, ob es Gesetz ist oder Verordnung. Bin kein Jurist, wie gesagt. Aber da ist es so, da darf das auch nicht unverhältnismäßig sein, sozusagen, das dann rauszubringen. Man muss auch keine, wenn nur weil das Gerät intern irgendwelche Daten erzeugt, die aber selbst noch nicht rausgegeben werden, muss man das auch irgendwie jetzt dann plötzlich umständlich irgendwelche Software bauen, die diese Daten dann irgendwie da extrahiert. Genau. Aber das ist vielleicht dann noch ganz spannend eben noch in der Außenkommunikation, dass man eben das auch nachweisen kann, dass wir per Design so arbeiten. Und was natürlich irgendwie auch so ein Wirtschaftsprüfer bestimmt gut findet, ist, wenn man halt irgendwie auch zeigt, wir sind eine Datenorganisation, wir sind Datenkompetent. Wir haben das im Griff, mit diesen Daten umzugehen. Wir machen das nicht nur irgendwie so, weil wir es müssen und irgendwie mehr schlecht als recht und das geht die ganze Zeit kaputt, sondern hey, das ist für uns easy, weil es ist nur irgendwie ein Adapter, den wir in unseren Data Marketplace irgendwie dran gehangen haben. Und ich glaube, das ist noch eine Sache, die ich eben oder das sind auch eben Sachen, die ich dann unterstreichen möchte, ja.

Sven Johann: Dann würde ich sagen, ran an die Datenarchitektur.

Stefan Negele: Ja, bitte. Bitte, mit Daten arbeiten, das macht sehr viel Spaß. Das klingt erstmal schlimm, aber oder wenn man es nicht macht, dann klingt es vielleicht erstmal nicht so schön. Ich war früher auch kein Fan von Excel und mittlerweile benutze ich es sogar privat, zumindest Google Sheets, um mir irgendwie Sachen zu visualisieren und dann bekommt man plötzlich Erkenntnisse über Dinge, die man so irgendwie noch nicht gesehen hat. Aber nur weil man eine Spalte irgendwie anders einfärbt.

Sven Johann: Alright. Dann würde ich sagen, vielen Dank Stefan, vielen Dank an alle Zuhörer, die es bis hierhin geschafft haben.

Stefan Negele: Ja. Danke auch, danke fürs Zuhören. Danke fürs mich löchern mit Fragen, hat sehr viel Spaß gemacht.

Sven Johann: Bis dann.

Stefan Negele: Tschüss.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Wie können Softwarearchitekt:innen und -entwickler:innen die EU Data Act-Regulierung nicht nur als Last, sondern als strategische Chance für ihr Unternehmen nutzen? Stefan Negele und Sven Johann von INNOQ diskutieren, wie der Zwang zur Bereitstellung von Dateninventaren die Einführung moderner Datenarchitekturen und die Förderung von Datenkompetenz vorantreiben kann, um interne Prozesse zu optimieren und neue Geschäftsfelder zu erschließen.

Der EU Data Act: Eine Chance zur Daten-Demokratisierung

Der EU Data Act verpflichtet Hersteller vernetzter Geräte, sogenannte IoT-Geräte, ihren Kunden einen kostenfreien und strukturierten Zugang zu den von ihnen erzeugten Daten zu ermöglichen. Stefan Negele erläutert, dass dies nicht nur eine regulatorische Anforderung ist, sondern eine Möglichkeit, die Datenhoheit an die Nutzer zurückzugeben und neue datengetriebene Geschäftsmodelle zu fördern. Für Unternehmen, die von dieser Regulierung betroffen sind, stellt sich die Frage, wie sie diese Anforderung effizient und gewinnbringend umsetzen können. Anstatt die Erstellung von Dateninventaren als reine Kostenstelle zu betrachten, können Unternehmen dies als Anlass nehmen, ihre interne Datenorganisation zu verbessern.

“Das Dateninventar ist im Prinzip ein Katalog, der eine Übersicht gibt über die Daten, die anfallen und wie ich auf diese zugreifen kann.”

Dateninventare als Spiegel der eigenen Datenorganisation

Ein zentraler Punkt der Diskussion: Unternehmen, die Schwierigkeiten haben, ein Dateninventar zu erstellen, haben meist grundlegende Probleme mit ihrem Datenhaushalt. Stefan Negele erklärt, dass die Fähigkeit, schnell ein strukturiertes Inventar zu erzeugen, ein Indikator dafür ist, wie gut eine Organisation ihre Daten im Griff hat. Unternehmen mit klaren Datenstrukturen können diese Anforderung mit überschaubarem Aufwand erfüllen, während Chaos in der Datenorganisation sich spätestens jetzt rächt. Die Regulierung wirkt damit wie ein Stresstest für die eigene Datenarchitektur.

“Wenn ich mir schwer tue, so ein Inventar und solche Schnittstellen zu erzeugen, dann liegt das vielleicht daran, dass ich meinen eigenen Datenhaushalt nicht sauber strukturiert und nicht unter Kontrolle habe.”

Moderne Datenarchitekturen als strategischer Vorteil

Stefan Negele und Sven Johann betonen, dass eine moderne Datenarchitektur, insbesondere eine datenproduktgetriebene und föderierte Architektur wie ein Data Mesh, eine ideale Grundlage für die Erfüllung der Anforderungen des EU Data Acts bietet. Solche Architekturen behandeln Daten als Produkte, die innerhalb und außerhalb des Unternehmens bereitgestellt und beschrieben werden. Dies ermöglicht nicht nur eine transparente und gut aufbereitete Übersicht über alle anfallenden Daten, sondern auch die einfache Identifizierung und den Schutz sensibler oder geschäftsgeheimnisrelevanter Daten. Für Unternehmen, die noch keine umfassende Datenarchitektur etabliert haben, bietet der EU Data Act einen starken Anreiz, damit zu beginnen.

Dabei betonen beide, dass der Einstieg nicht zwingend ein Großprojekt sein muss. Auch kleinere Unternehmen können mit überschaubaren Schritten beginnen: Daten sauber dokumentieren, Informationen zur Datenqualität festhalten und die Denkweise entwickeln, mit Daten zu arbeiten. Eine vollständige Data-Mesh-Architektur ist erst bei größeren Organisationen sinnvoll – ähnlich wie Microservices nicht für jedes Team die richtige Wahl sind.

“Wenn ich so etwas habe, dann habe ich das Fachwissen aus dem Team, das meine Daten beschreibt, in einem Katalog oder Datenmarktplatz verfügbar – mit einer Übersicht über sämtliche Daten, die gut aufbereitet sind.”

Data Literacy als Schlüssel zum Erfolg

Ein weiterer entscheidender Erfolgsfaktor im Umgang mit dem EU Data Act und der Nutzung von Daten im Allgemeinen ist die Data Literacy, also die Datenkompetenz innerhalb des Unternehmens. Stefan Negele definiert Data Literacy als die Fähigkeit, Daten zu lesen, mit ihnen zu arbeiten, sie zu analysieren und mit ihnen zu kommunizieren. Er hebt hervor, dass nicht jeder ein Data Scientist sein muss, aber ein grundlegendes Verständnis und die Fähigkeit, mit Daten umzugehen, entscheidend sind. Die Förderung von Data Literacy sollte idealerweise vom Management vorgelebt werden, kann aber auch als Bottom-up-Initiative in Teams beginnen. Durch den Aufbau von Communities of Practice und das Angebot gezielter Schulungen können Unternehmen ihre Mitarbeiter befähigen, datengetrieben zu arbeiten und so die Vorteile der neuen Datenarchitekturen voll auszuschöpfen.

“Data Literacy ist die Fähigkeit Daten zu lesen, mit ihnen zu arbeiten, sie zu analysieren und mit ihnen zu kommunizieren.”