EAM#23: Schnittstellen vs. Datenprodukte - Warum Daten bewegen nicht reicht

00:00:04: Architektur entscheidet.

00:00:06: Über Komplexität, über Kosten, über Steuerbarkeit.

00:00:09: Ich bin David Hohl und heiße Dich herzlich willkommen.

00:00:12: bei Enterprisearchitektura wirkt der Podcast zu ERM.

00:00:20: Sehus grüßt Dich ohne jetzig Willkommen zu einer neuen Folge.

00:00:25: Die letzten Folgen haben uns ja viel über Daten, Editäten gesprochen.

00:00:30: Also das war die Folge einundzwanzig.

00:00:32: In Folge zweiundzwantzig ging es dann um den Data TCO Darüber warum schlechte Daten nicht einmal kosten, sondern immer wiederkosten.

00:00:45: Heute machen wir es ein bisschen schlanker auf der Folge oder Länge.

00:00:53: Ich denke mal auch dass diese Folge etwas kürzer wird.

00:00:57: Kürze durch die Würze.

00:01:01: Es geht um was ganz einfaches aber wichtiges und zwar und eine Unterscheidung zwischen Schnittstellen sind nicht automatisch Datenprodukte.

00:01:15: Und genau hier entstehen in vielen Organisationen ein Denkfehler meines Achtens.

00:01:21: Oft heißt es, die Daten sind doch verfügbar!

00:01:26: Wir haben doch jede Menge Integrations laufen dafür oder auch in einer Richtung Statements, das System liefert die Daten doch bei API ist doch alles da.

00:01:37: was regst ihr auf?

00:01:40: Die Daten werden doch schon übertragen.

00:01:46: Kann ja alle stimmen Aber Daten von A nach B zu bewegen ist nicht dasselbe Daten nutzbar zu machen.

00:01:56: Also eine Schnittstelle Beantwortet vor allem die Frage Wie kommen Daten von A nach B?

00:02:06: Ein Datenprodukt beantwortet aber eine andere Frage.

00:02:13: Welche Daten werden vom Fürwien in welcher Qualität, mit welchem Kontext und welche Verantwortung bereitgestellt?

00:02:23: Und das ist der große Unterschied dabei.

00:02:32: Ja Kapitel eins Der große Denkfehler Also eine typische Annahme, die man natürlich an der Stelle sehr oft wie immer wieder sehen ist.

00:02:44: Wenn eine Standstelle einfach da ist dann ist das Datenproblem in der Regel immer gelöst, nicht wahr?

00:02:50: Also wenn ein System miteinander verbindet, dann habe ich ja kein Datenproblem mehr weil die Informationen sind ja danach halt da vorhanden.

00:02:59: aber es stimmt heute meistens nicht.

00:03:02: Eine Standstellte kann halt technisch funktionieren über Natürlich eine direkte Point-to-Point-Integation, oder doch hast halt ein Event dazwischen.

00:03:12: Die fassen das da rüber, roten Wurstungen in den ESP im Platz und dann die Mittel werden wohlstärzt.

00:03:17: Und wenn du Ende des Tages technisch kriegt man das schon alles irgendwie hin... Aber das ja?

00:03:24: Und am Ende kannst du aber leider dazu führen dass es halt fachlich überhaupt nichts hilft weil halt irgendwas da drinnen stimmt!

00:03:36: Und was dabei all der schief gehen kann oder halt nicht funktionieren kann sind zum Beispiel, dass Daten werden zwar geliefert aber ohne Kontext.

00:03:47: Oder die Feldern dann übertragen aber ohne saubere Bedeutung.

00:03:50: also man weiß einfach nicht wo es das genug ist oder vielleicht auch sogar die Verbindung des Mappinges falsch.

00:04:00: Das kann aber auch dazu führen dass die Daten einfach nicht mehr vertrauenswürdig sind.

00:04:08: Die Integration kann natürlich stabil laufen, aber niemand fühlt sich für die Datenqualität verantwortlich und genau das ist halt der Punkt wo es eigentlich darum geht.

00:04:18: ein Schnittsteller löst halt einen Integrationsproblem Check Aber sie lösen halt nicht automatisch ein Datenproblem.

00:04:27: Sie sagt uns einfach nur Woher kommen die?

00:04:31: Und wo gehen sie?

00:04:33: In welchen Format werden sie übertragen und wie oft sie übertragen werden, über die welche technische Mechanismen sie bereitgestellt werden.

00:04:43: Das kann ich davon ablesen.

00:04:45: Also das ist aber eine ganz ausreichende, ich brauche ein bisschen mehr Informationen, was die Daten nämlich fachlich bedeuten ist für mich relevant, wer die Daten verantwortet oder auch irresponsible ist, welche Qualität erwartet wird für welchen Zweck die Daten gedacht sind, so viel was braucht es eigentlich und ob sie auch wieder verwendbar sind.

00:05:15: Ein anderes Thema wäre noch, ob ein anderes Team den Daten vertrauen kann, die da draußen stehen?

00:05:24: Das ist halt genau der Denkfeuler und wir verwechseln immer auf die technische Verfügbarkeit mit der fachlichen Nutzbarkeit.

00:05:39: Eine Schnittstelle wirklich macht.

00:05:42: Ich weiß nicht ob ich das erklären muss, aber wir probieren es mal.

00:05:45: vielleicht haben wir dann nachher das gleiche Verständnis.

00:05:49: Ein Interface ist milchig.

00:05:50: Darf ich mir den Frage stellen?

00:05:53: Ohne Interface funktioniert überhaupt keine IT-Landschaft doch funktioniert.

00:05:59: machen wir die Skette und dann schieben sie von A nach B. Das haben wir früher gemacht.

00:06:07: Scherz bei Seite!

00:06:09: Natürlich müssen die Systeme miteinander reden können und wir müssen Informationen austauschen.

00:06:14: Wenn es uns machen braucht man keine Prozesse überlegen, damit ist auch jede Organisation eigentlich heutzutage zum Scheitern fuhrteilt.

00:06:25: Aber eine Schnittstelle denkt meistens aus einer Sicht der Systeme Also immer ein sehr technischer Brille drauf.

00:06:33: Also das System A schickt da irgendwo aus, System B empfängt die irgendwo aus Datenfeld X sondern auf Datenfeld Y mapen.

00:06:41: Die Fehler werden technisch behandelt.

00:06:44: Die Vertragung läuft täglich, vernünftig oder minutlich in Echtzeit.

00:06:49: Bei Echt Zeit finde ich immer sehr spannend die Definition dahinter.

00:06:54: anderes Thema und wichtig für uns Das ist eine Integration Wichtig aber für die Enterprise Architektur ist etwas anderes.

00:07:07: Das ist genau das, was wir uns jetzt in den Fokus stellen wollen.

00:07:11: Uns ist wichtig nur ein Datenfluss oder entsteht daraus wirklich nutzbare Datenfähigkeiten.

00:07:23: So habe ich das richtig formuliert.

00:07:24: Die sind noch mal meine Notiz hier richtig vor.

00:07:29: Ist das nur ein Datenfluss?

00:07:30: Oder entsteht Daraus wirklich Nutzbare-Datenfähigkeit?

00:07:34: Das ist es!

00:07:34: Genau.

00:07:37: Kapitel drei was ein Datenprodukt anders macht.

00:07:44: Dataprodukt-Datenprodukt, ich bin mir nicht ganz sicher weil das jetzt auf Deutsch schon auf Englisch stand.

00:07:49: Egal Es geht nicht darum Daten zu transportieren.

00:07:53: Das ist nicht der Anspruch hier.

00:07:57: es geht darum Daten bereitzustellen dass andere sie sinnvoll wieder nutzen können.

00:08:03: Es gilt um die Wiederverwendbarkeit.

00:08:05: Also ein Daten Produkt hat deshalb mehr als nur eine technische Schnittstelle.

00:08:11: Es braucht nämlich etwas anderes noch.

00:08:14: Es braucht klare fachliche Bedeutung, definierte Qualitätsstandards, Verantwortlichkeiten, gute Dokumentation.

00:08:24: Der Nutzungskontext muss klar definiert sein.

00:08:27: Es muss stabil Bereitstellung verfügbar sein und wieder verwendbar sein.

00:08:34: Und letztes muss eine klare Erwartung an den Konsumenten haben.

00:08:39: Also ein Datenprodukt sagt halt nicht nur Das sind die Daten, sagt er.

00:08:44: Hier ist ein fallesicher Datenbestand für den bestimmten Zweck.

00:08:48: Ihr könnt ihn nutzen, ihr versteht ihn, ihr wisst wer verantwortlich ist und ihr kennt die Qualität dahinter.

00:08:56: Und das ist halt einfach eine andere Reife grad.

00:09:00: Machen wir ein Beispiel.

00:09:02: Ein Interface liefert Produktdaten in einem Webshop.

00:09:09: Dieses Datenprodukt... Product Information liefert definierte Produktdaten mit klarer Struktur, klare Verantwortlichkeit, Qualität und Beschreibung.

00:09:19: Und der Nutzungskontext und die Akkualität... Oh!

00:09:26: Jetzt kann ich nicht mehr mal meine ganzen Vomulierungen in einer Lesen-Aktualität hast du natürlich.

00:09:33: Hey, so viele Schreiben lernen.

00:09:37: Dann weiß ein Team halt nicht nur dass die Daten bekommen, das weiß auch, dass sie in Daten vertrauen kann.

00:09:42: und jetzt sind wir genau bei dem.

00:09:44: Ich muss halt wirklich gerade aus.

00:09:47: jeder Architekt in jedem Bereich und Domäne muss halt Vertrauen haben, dass diese Daten ja correct sind.

00:09:53: Witzigerweise gehe ich davon aus dem Prinzip aus.

00:09:56: Sobald ich aber enttäuscht werde, dass zum Beispiel irgendwelche Grunddaten nie richtig gepflegt werden oder aktualisiert werden dann verliere ich das Vertrauen und interfrare sogar manche Interfesis Und es macht halt genau den Unterschied Sichtbar.

00:10:15: Kapitel vier, warum das für uns in der Enterprise-Architektur relevant ist?

00:10:22: Na klar ist es relevant!

00:10:23: Was sind das für blöde Kapitelbeschreibungen gemacht?

00:10:29: Scherz... Also wirklich, das kriegst du entscheiden sogar Denn Architekturtafall nicht nur Linien zwischen Systemen malen, sondern einfach irgendwie Strich von Anachbemahlen und sagen, du süße Zone-Sultaten-Archeitekturen.

00:10:44: Das ist natürlich Blödsinn.

00:10:46: Natürlich brauchen wir Integrations-Glandkarten, wir brauchen auch eine Schnittstellenübersicht.

00:10:52: Wir müssen wissen mit welchen Systemen man kommuniziert.

00:10:56: Auf allem müssen wir uns anderes Wissen einfach sicherstellen dass der Transport die Informationen korrekt vonstatten geht und das wir genau wissen was die Qualität dahinter sagt und auch der fachliche Kontext Und das ist natürlich auch für die Architektur extrem stark und wichtig.

00:11:19: Bei Datenentitäten haben wir halt gesagt, wir müssen verstehen welche zentrale Datenobjekte im Unternehmen wirklich relevant sind... ...und bei der letzten Folge um Data Ties wurde man halt gesagt schlechte Daten kosten ja immer wieder und wenn sie sich bewegt und korrigiert und interpretiert und abgestimmt werden müssen.

00:11:45: Eine Schnittstelle alleine verhindert diese Kosten ja nicht.

00:11:48: Wenn eine Schnitzel schlechter oder unklarer und verantwortliche Daten weiter gibt, dann skaliert sie nicht Qualität, sie skaliert genau das die Probleme dahinter.

00:12:01: Sie multipliziert sie sogar.

00:12:05: Das ist zwar vielleicht ein bisschen hart formuliert gerade von mir.

00:12:08: aber eigentlich ist da wenn es da ins Spiegel schaust, ist das schon die Realität.

00:12:16: Kapitel Fünf und ich glaube das ist der Schletzter.

00:12:20: Damit habe ich schon gesagt, die Folge wird sehr kurz und knackig.

00:12:24: Ich mag einfach nur eine Fakten hier aufstellen und auch dass es ein bisschen klarer gesehen wird, dass Schnittstellen nicht Daten sind.

00:12:33: Kapitel V-Falt Der einfache Vergleich.

00:12:37: Man kann das eigentlich alles sehr einfach trennen.

00:12:41: Ein Interface fragt halt wie kommen Daten von A nach B?

00:12:45: Check.

00:12:47: Ein Datenprodukt hingegen fragt, welche Daten liefern welchen Wert für Wien.

00:12:55: und eine Schnittstelle ist halt immer technisch.

00:12:58: Klar!

00:13:00: Und ein Datenproduk ist aber was anderes?

00:13:03: Beides ist es fachlich untechnisch gedacht.

00:13:05: Eigentlich ist das das beste Verbindungsglied um im Endeffekt Informationen A nach B zu deklarieren.

00:13:13: Eine Schnittsstelle verbindet Systeme und ein Daten Produkt bedient Konsumenten und schafft Vertrauen.

00:13:20: Es schafft auch die Nutzbarkeit der Informationen.

00:13:23: Und vor allem schafft das etwas langfristig, kann es damit betrieben werden und die Verantwortlichkeit ist auch gegeben.

00:13:31: Damit ist uns einfach klar in der ERM nicht jede Schnittstelle muss ein Datenprodukt sein.

00:13:37: Das wäre natürlich zu viele Datenprodukte.

00:13:41: Es gibt technische Integrationen und Prozessionstellen.

00:13:45: Natürlich irgendwie Synchronisationen.

00:13:48: Die müssen nicht als Datenprodukt gedacht werden und so hätten das auch nicht.

00:13:52: Aber dort wo die Daten mehrfach genutzt werden, wo viele Konsumenten abhängig sind, wo ich halt wirklich sehr viele Prozesse BPM habe Und natürlich auch meine ganze EI entfalten möchte Darauf aufbauen.

00:14:10: Dort reicht eine reine Schnittstelle einfach nicht auf.

00:14:13: Dort brauche ich einfach dieses Produkt denken.

00:14:23: Nur Kapitel überlesen Kapitel sechs, was Architektur konkret fragen sollte.

00:14:30: Also was sollst du eigentlich daraus jetzt mitnehmen und wie gehst du das an?

00:14:35: Aus der EM-Sicht reichen einfach paar einfache Fragen um den Unterschied wirklich sichtbar zu machen.

00:14:42: Erstens welche Daten in die Däten wird hier eigentlich bewegt?

00:14:45: also geht es jetzt hier um Customer Product Contract usw oder um etwas komplett anderes?

00:14:52: Zweitens fragst du einfach wer verantwortlich ist?

00:14:56: Nettisch-Schnittstelle ist verantwortlich, sind die Bedeutung dahinter Qualität und die Veränderungen der Informationen.

00:15:04: Drittens, er nutzt diese Daten.

00:15:07: Ist das noch ein System oder sind es wirklich sehr viele?

00:15:10: Manchmal sind das auch nicht nur Systeme sondern einfach ganze Teams und Prozesse.

00:15:14: man kann sich dazu auch an den PPM Landschaften ein bisschen orientieren.

00:15:19: Viertens, ist die Schnittstellen nur für ein Projekt gebaut worden oder soll sie daraus wiederverwendbare Datenbasen entstehen?

00:15:27: Ich persönlich nebenbei bin sowieso der Meinung, wer ein Interface nur für ein System oder für eine Plattform oder ein Projekt baut.

00:15:35: Der hat irgendwie nicht ganz verstanden was es bei Interfaces geht.

00:15:41: also das würde ich sowieso mal prinzipiell mal hinterfragen.

00:15:45: Fünftens gibt es eine klare Erwartung an Qualität und Aktualität Stabilität.

00:15:53: wenn diese Fragen nicht beantwortet sind Dann haben wir wahrscheinlich nur Integration, also dann braucht auch kein echtes Datenprodukt.

00:16:05: und wenn darüber ein Einraus kommt.

00:16:08: Und wenn man uns den EI-Bezug dazu noch mal reinziehen, dann braucht halt nicht überall Datenzugriff.

00:16:18: Klar aber EI braucht halt verständliche und verlässliche und vor allem verantwortete Daten.

00:16:28: Wenn du halt zehn Schnittstellen zugreifst und niemand weiß genau, welche Daten da korrekt sind.

00:16:32: Und was dadurch geschossen wird.

00:16:34: Welche Definitionen gelten?

00:16:36: Wer verantwortlich ist, dann wird es über die Zeit einfach wirklich schweine-teuer.

00:16:41: Dann beginnt nämlich wieder diese ganze Vorarbeit muss an die Daten bitte erklären.

00:16:47: Wir müssen das ganz bereinigen.

00:16:48: Das ist alles Mister drinnen.

00:16:49: Es muss harmonisiert werden.

00:16:51: Die Qualität muss geprüft werden.

00:16:53: Verantwortlichkeiten und

00:16:54: etc.,

00:16:55: etc.

00:16:57: Also für EI brauche ich heute die Schnittstellen, das ist unrelevant.

00:17:01: EI braucht was anderes.

00:17:02: Es brauchen halt gute Datenprodukte oder zumindest Daten wie Produkte geführt werden mit Verantwortung, Qualitätskontext und Trust.

00:17:20: Das war es dann wieder von der Folge, diesmal ein bisschen wieder kürzer als wir sonst.

00:17:30: Abrieb nochmal.

00:17:31: Also mir war einfach wichtig, dass du das Verständnis zu Datenprodukten hast und auch den Unterschied zwischen den Interfaces erkannt hast.

00:17:39: hoffentlich Wir sollten uns halt nicht einfach nur fragen welche Systeme verbunden sind Gerade wenn wir mich ja Auto machen Sondern wir sollten uns wirklich diese Fragen wieder reinholen.

00:17:54: Welche Dateprodukte entstehen daraus?

00:17:57: Welche Data Entities werden da hintergeführt?

00:18:00: Wer verantwortet sie und was ist eigentlich der Business Value dahinter?

00:18:05: Und wird ja auch wirklich genutzt und ausgebaut.

00:18:09: Den Daten bewegen reicht es halt einfach nicht, Daten müssen einfach nutzbar werden und auch nutzbaar bleiben.

00:18:16: Genau dort beginnt der Unterschied zwischen Integration und echter Datenfähigkeit.

00:18:23: So, dann ich hoffe dir hat die Folge gefallen und wir haben uns da nachher In der nächsten Folge wieder.

00:18:33: Bis dahin, Servus und Papa bis auf bald!