EAM#21: Data Entities - Der fehlende Baustein zwischen Capabilities und AI

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: Servus grüßt euch und herzlich willkommen zu einer neuen Folge!

00:00:25: Letztens haben wir uns ja sehr viel über die Business Capability ausgetauscht und gerade die letzte Folge ist... etwas explodiert von der Länge, ich hoffe sie hat dir doch etwas zugesagt.

00:00:42: Wenn man halt die Kippe Bild jetzt richtig sauber aufbaut und richtig schneidet dann hat man mal schon die halbe Miete für den Aufbau einer Enterprise Architektur Ebene.

00:00:55: Aber um im Endeffekt den richtigen Bindeglied zu den Applikationen schaffen zu können, brauchen wir noch etwas ganz Entscheidendes.

00:01:02: und auf das haben wir auch beim letzten Mal ein bisschen eingewirkt oder ich habe auch darauf hingewiesen.

00:01:07: Und zwar sind es die Daten!

00:01:10: Wenn wir von Daten sprechen in der Enterprise-Architektur dann reden wir vor allem von Data Entities.

00:01:16: Den witten wir uns dieses Monat mit vier Folgen rund um das ganze Thema.

00:01:23: Viel Spaß!

00:01:29: Was wir auf jeden Fall diesmal aber vermeiden, oder nicht diesmal sondern allgemein immer vermeiden natürlich dass er nicht so technisch eintauchen.

00:01:35: Wir werden sicherlich nicht über irgendwelche Datenbanken sprechen und welche Typme es davon gibt um schon gar nicht überehmliche Tabellen und Schnittstellen.

00:01:44: Das ist eine Ebene für die Slushnachdektur Und klar hat die Enterprise Architektur darauf Einwirkungen oder Auswirkungen.

00:01:53: Dennoch gehen wie einen Schritt eigentlich auf einer Generische Flughöhe und die Datenentitäten oder auch in Deutschland auf Datentöpfe.

00:02:04: dazu sind im Endeffekt unsere Ausgangslage.

00:02:09: Und wir wollen eigentlich dieser Folge vor allem, diese Serie folgende Frage beantworten welchen Informationen braucht eine Fähigkeit damit sie funktionieren kann?

00:02:25: da helfen uns die Datenentitäten.

00:02:34: Nach jeder Capability kommt halt die Daten-Layer und darunter halt die Schicht der Applikationen.

00:02:41: Jede Fähigkeit braucht ja Informationen, um leben zu können – ohne Informationen geht eigentlich gar nix!

00:02:47: Deswegen ist es halt umso wichtiger dass sie sauber geschnitten werden richtig verantwortet werden, also ein Ownership.

00:02:57: Denn wenn das nicht vorhanden ist dann wären halt einfach die Applikationen darunter und die Schnittstellen und die Governance und vor allem Kosten am Ende einfach einen Bauwerk.

00:03:09: eher gegen neue Innovationen wie unter anderem EI funktioniert halt ohne diese Verbindungen einfach nicht.

00:03:22: Wie gesagt, in der letzten Folge ging es um Fähigkeiten.

00:03:26: Und Fähigkeiten zeigen das Organisationen oder was Organisationen vielleicht leisten können.

00:03:32: Fähigkeit funktionieren aber nicht ohne Informationen und Informationen sind nicht automatisch einfach irgendwelche komischen Datenbanken.

00:03:44: Was oft auch gesehen wird dass die IT die Daten besitzt was eigentlich nicht stimmt oder halt obsoletes.

00:03:54: Daten sind einfach genau diese fachliche Architektur Bausteine, bzw.

00:03:59: das Bindeklid, wie ich immer so schön sage und genau deshalb müssen wir uns um die Datenintäten aufbauen.

00:04:07: Wir müssen eine klare Richtlinie aufsetzen, geschnitten werden, also man kann nicht einfach die Töpfe hinstellen und dann glauben alles ist erledigt.

00:04:17: Es muss richtig geschnitzen werden und da es auf der Hund begraben und darum geht das auch ein bisschen heute wie man das am besten angeht.

00:04:27: Jeder will halt AI in irgendeiner Art und Weise einsetzen und dann kennt sich ja auch dieses Diese Diskussion und von den komischen Use-Cases.

00:04:38: Und dann hat man irgendwo mal was gefunden, und dann überlegt man sich mit welchen Informationen fütter ich in das Ganze?

00:04:44: Dann fängt man an die Daten... Ich weiß gar nicht wo sie liegen oder was der Inhalt ist.

00:04:49: Wer ist denn dafür verantwortlich?

00:04:52: Hier kommt genau wieder unser Data Entities und das Governance Modell dahinter im Einsatz.

00:05:01: Im Grunde genommen ist es auch kein Rocket Time!

00:05:04: ehrlich zu sein.

00:05:05: Wenn man das einmal sauber richtig schneidet, dann hat man das für eine sehr lange Zeit oder vielleicht sogar für die Ewigkeit.

00:05:10: weil was sich halt auch letztens wieder in ein Gespräch formuliert dass ich niemals ändert sind die Daten.

00:05:19: Mitarbeiter kommen und gehen wissen kommt und geht Applikationen kommen bleiben blöderweise zu lange und gehen dann aber auch irgendwann mal.

00:05:29: Im Schluss werden diese Informationen, die in den Applikationen gespeichert sind oder in den Systemen als solches natürlich irgendwann migriert und somit bleiben sie im Unternehmen.

00:05:38: Und das sind die einzigen, die für die Ewigkeit gebaut sind.

00:05:43: Wenn man sich die Grundlage der Augustration der Daten richtig setzt ist es wie ein Stein gemeißelt und die alten Römer oder die neuen Römern danach können Sie auch immer lesen.

00:05:56: Aber wenn die Daten nicht sauber verstanden sind, wenn niemand verantwortlich ist.

00:06:01: Wenn keiner weiß wo sie entstehen oder geschweige wie sie genutzt werden und welche Bedeutung Sie haben dann steht halt jeder Initiative.

00:06:12: Und wenn man von der Eier redet auf wirklich sehr wackeligen Fundamenten Dann kann man so schöne Schaubilder machen Die man in einer Social Media Kanäle immer wieder davon sieht und davon wird man eigentlich mal wieder schlecht.

00:06:28: gleich mal als vorweg.

00:06:29: ich denke die folge wird leider schon wieder etwas lang.

00:06:32: aber schauen wir mal wo mein heute enden.

00:06:35: wir haben uns meinen ersten jetzt einmal probiert es in kapitel ein bisschen zu unterteilen und vielleicht gebe ich dir auch die da ein bisschen halt bisseres gefühl halt.

00:06:46: na also kapitel eins der übergang von capabilities zu detentities.

00:06:52: Ich habe zwar im intro so ein bisschen schon angesprochen.

00:06:56: wichtig ist einfach nochmals klar zu verständen ist.

00:06:59: gpbillis beschreiben was eine Organisation wirklich kann, ja, wir reden vom Körnern und die data entities beschreiben welche Informationen diese Fähigkeiten dann benötigen beziehungsweise vor allem was sie erzeugen oder verändern wieder auch hier verwechselt es nicht mit bpm, bpm nutzt die Fähigkeiten die Data Entities.

00:07:25: BPM nutzt, die Applikationen sind die Prozesse dazwischen?

00:07:29: also ich weiß nicht.

00:07:32: diese Diskussionen fühle ich so häufig dass man immer wieder glaubt das sind Prozesser da sind es nicht.

00:07:38: mit Data Entities setzt man im Infekt ein klares Regelwerk auf wie Daten behandelt werden in einer Organisation auf Basis von den Business Capabilities.

00:07:49: Also die Capability's sind ja unser Startpunkt unserer Story.

00:07:55: Aber eine Fähigkeit ist halt nicht isoliert, die braucht Informationen.

00:07:59: Sie erzeugt Informationen und sie verändert Organisationen wie ich schon vorhin erwähnt habe.

00:08:07: Und dadurch entsteht halt dieser Übergang von Business zur Architektur zu Datenarchitekturen.

00:08:13: Gucken wir mal ein Beispiel ein bisschen rauszunehmen.

00:08:17: Wenn wir uns Order Management anschauen.

00:08:19: Diese Capability ist eigentlich wenn man das Wenn man sich die Subtitel dazu anschauen würde, wird es relativ einfach sein.

00:08:28: Aber wenn wir danach natürlich ein bisschen sich die Informationen anschauen möchte dann verstecken sich hinterm Ordermanagement ganz schön viele Datenentitäten.

00:08:36: Sollen wir probieren ein bisschen aufzuschlüsseln ohne jetzt den Detailgrad?

00:08:40: Also man braucht natürlich für OrderManagement Customer, Product, Price, Contract oder solches Delivery, Payment Invoice alles Teil von OrderManishment.

00:08:51: Du siehst gerade raus oder hörst hoffentlich raus wie wichtig diese Informationen eigentlich sind.

00:08:59: Sobald nämlich irgendwas davon fehlt oder falsch ist, oder nicht verfügbar ist, dann funktioniert diese Fähigkeit nicht und natürlich alle Prozesse die daran hängen.

00:09:08: Und umso wichtiger ist hier das klar aufzuzeigen!

00:09:11: Wenn dies halt schon nicht funktioniert, dann kannst du mal sicher sein der Applikation geht in die Hose egal wie gut sie ist... ...und die Fähigkeiten wird nicht vollständig sein und der Reifengrad kann man sowieso dann knicken.

00:09:24: Also, wichtig ist nochmal hervorzustellen.

00:09:30: Wenn wir von Daten in Daten sprechen müssen wir uns eigentlich nur anschauen welche Daten braucht eine Capability?

00:09:38: was erzeugt sie?

00:09:39: noch mal etwas verändert sie was konsumiert sie und welche Daten sind kritisch?

00:09:45: welches sind regulatorischen Beispiel auch relevant?

00:09:48: Und wer ist dafür verantwortlich?

00:09:51: Das Interessante dahinter ist, es leitet sich eigentlich automatisch – und nicht automatisch aber großteilig eigentlich schon von diesen Fragen die ich gerade reingeworfen habe vor einer Fähigkeit ab.

00:10:02: Das kann man nicht relativ gut ableiten von oben nach unten Denn wir haben ja auch schon mal gesprochen über Kritikalität in den Capabilities.

00:10:10: Und im Endeffekt wenn eine Capability kritisch ist Na ja klar dann sind die Daten da hinter auch kritisch.

00:10:16: So Kapitel zwei was isst eine Datenität?

00:10:20: Also eine Daten ist eigentlich ein fachlich relevantes Informationsobjekt innerhalb einer Organisation, ich glaube diesen Satz habe ich irgendwo aus einem ganzen Fachbuch ausgekupiert.

00:10:36: Was im Grunde genommen nichts anderes ist, ja das ist ein Informationsobjektepunkt aus was es aber nicht ist und das ist genau dieser technische.

00:10:46: Es ist keine Tabelle, es ist keine Datenbank.

00:10:48: Es ist schon gar nicht ein Schnittsteller oder so und schon gar nichts.

00:10:51: Ist das irgendein Feld?

00:10:52: Oder ein Typ innerhalb eines Systems?

00:10:55: Das ist einfach nur ein fachliches Objekt und so soll es auch gesehen werden und auch in der Bedeutung.

00:11:02: Was könnten eigentlich Daten und Ideen sein?

00:11:06: Ich muss sagen man muss das ein bisschen üben.

00:11:09: also das kann man nicht... einfach schnell machen, man muss sich da wirklich auch Zeit nehmen.

00:11:14: Im Grunde genommen sind das sehr einfache Bezeichnungen für ganze Objekttöpfe zum Beispiel eine Order und Contract, Employee und Supply ein Asset Location Invoice oder Customer Produkt habe ich schon mal gesagt Ich weiß es nicht oder Price.

00:11:36: Also Es gibt...es sind einfache Terms und diese Terms dürfen sich auch nicht mehr verändern.

00:11:44: Das ist das einzige Problem an der ganzen Geschichte, deswegen ist das wirklich etwas was man einmalig machen sollte um danach hier nicht mehr anpassen.

00:11:55: Deswegen nimm dir wirklich Zeit wenn du so etwas schneidest.

00:12:00: Zudem schneide ich ja nicht nur in eine Eine Richtung, sondern was ich gerne mache ist... ...ich unterteile das in verschiedenen Levels.

00:12:11: Maximal zwei Levels hat sich irgendwie bewährt über die Zeit und diese Level ist im Endeffekt die Zuordnung zum Hauptdaten-Edit.

00:12:20: Also wenn ich z.B.

00:12:22: von Levels rede dann werden genau die, was ich vorhin aufgelistet habe bei Level Eins und danach ja Level Zwei wäre ein Bezug z. B., wenn man einen Customer jetzt sehr annimmt würde, Adress, Customer... Was werden Customer noch?

00:12:41: Address was wir noch.

00:12:43: Customer Metadata, Customer Access Data also etwas alles was dem Kunden danach zugewiesen sind aber nur für Kunden existiert und nirgends woanders im Endeffekt relevant ist.

00:12:58: oder auch Customer Contract, Customer Segment, Consent zum Beispiel ist nicht was eigenes.

00:13:05: Man kann es aus eigenes sehen, wo die Meta-Information vom Consent stehen.

00:13:09: Aber die Kunden spezifischen Informationen, dann kauft man Consent.

00:13:13: Also das wäre im Endeffekt danach das Level zwei.

00:13:17: und welche Diskussionen fühle ich da oft?

00:13:20: Die wirst du auch blödeweise führen müssen.

00:13:23: Es wird nämlich relativ schnell zur Spruch kommen, wenn man halt diese Fähigkeiten davon ableiten möchte.

00:13:29: Den Detas dann habe ich im Endeffekt oft gar nicht die Informationen und war schon ein Capabilis für Informationen erzeugt werden.

00:13:36: das ist sehr spannend weil... Wenn ich dann frage was tust du?

00:13:39: Ja wir tun da die Daten die liegen im CN ja Die kommen nebenbei von SAP oder die kommen vom Salesforce.

00:13:46: Und ja da drinnen sehen wir danach auch ein Reporting.

00:13:49: Äh ja toll Jetzt habe ich aber null Informationen.

00:13:55: Welche Informationen oder welche Datenentitäten es sich eigentlich handelt?

00:14:00: Deswegen frage ich danach halt eine sehr effektive Frage, die funktioniert sehr gut.

00:14:05: Welchen Informationen ist das und was bedeutet sie für dich und für das Business?

00:14:11: Und Beispiel halt, wenn ich über einen Kunden spreche dann kann dieser Kunde in mehreren Systemen natürlich aufdauern.

00:14:17: Da kann ja eine CM-Kunde sein, eine ERP, ein E-Commerce-Plattform, Newsletter und so weiter und so fort.

00:14:23: Aber die fachlichen Informationen zum Customer ist nicht automatisch das CM.

00:14:29: Das CM ist ja nur der System mit den Informationen arbeitet.

00:14:35: Wenn wir dies im Endeffekt nachher richtig sauber verstanden haben was eine data entity ist, kommt halt einfach der nächste Punkt.

00:14:43: Für was brauche ich den Spaß?

00:14:49: So und da sind wir schon bei Kapitel drei.

00:14:52: Für Was Brauche Ich Eine Data Entity?

00:14:55: Also Data Entities schaffen eine gemeinsame Sprache zwischen Business IT Und die Architekturen, die Governance Compliance ermöglicht mir im Endeffekt auch diese Sprache voll bringt, genau.

00:15:13: Ich stehe das auf keinen Fall raus und später im Endeffekt alle Innovationen wie zum Beispiel EI Implementationen Und die Data Entities helfen uns dabei einfach die Capable-Bildes mit wirklich Informationen zu verbinden.

00:15:28: also im Endeffer kann ich danach auch den Bezug recht sauber darstellen Daten von Applikationen zu entkoppeln Also aus fachliches Objekt zu sehen und nicht als Systemobjekt.

00:15:38: Schnittstellen werden einfach besser verstanden, weil ich auch verstehe welche Kritikalität und welche Dateninformationen fließen eigentlich dadurch.

00:15:46: Und nicht jetzt auf Feldbasis... ...und ich kann etwas auf einmal machen und das spreche mal in eurer Folge.

00:15:53: In der X-Nurfolgen ist es so genannte Data TCO, den kann ich auf einmal analysieren, die er auf dem eigentlichen TCO mit einzahlt.

00:16:03: Und ich kann auch Governance aufbauen, also Data Governance.

00:16:06: Super wichtig nebenbei!

00:16:08: Also einer der... Wenn du keine Data Governances hast dann kannst du mit allen regulatorischen Anforderungen nicht bauten gehen.

00:16:14: Das funktioniert nicht.

00:16:16: und natürlich unser Hauptthema aktuell einfach in den IAUs Case ist damit einfach ... Kann ich fachlich absichern?

00:16:24: So, ich probiere das nochmal ein bisschen fachlig beispiellhaft ein bisschen zusammen zu fassen.

00:16:31: Also ohne Data Enterprise passiert etwas, dass wir in Organisationen halt eigentlich fast immer haben.

00:16:38: Das Business sprecht halt immer in Form von Prozessen und wenn ich mit einer IT-Abteilung spreche dann reden die über eigentliche Applikationen und Systeme.

00:16:47: Wenn ich mit Compliance spreche, die das im Endeffekt alles kontrollieren muss, die sprechen nur über Risiken und so hat jeder halt seinen Topf.

00:16:56: Aber eigentlich ist die Verbindungssprache, die Informationen dahinter und das sind die Daten in die Däten.

00:17:02: Das heißt wir müssen als Enterprise-Architekten eine eindliche Datensprache einführen um den Effekt alle Bereiche im Unternehmen egal wo sie sitzen zu verbinden um eine eindeutliche Sprache zu sprechen und nicht danach von x und y und irgendwelche Daten dort und hier und dann sehen Sie im Endeffekt cmdaten obwohl es eigentlich Kundendaten sind.

00:17:23: und diese Kundendaten kommen überall vor in einer gewissen Ausbaustufe.

00:17:33: Kapitel vier, wie schneidet man?

00:17:35: Und diese Date-Endities wird so ein bisschen spannend.

00:17:38: Date-endities müssen so grob wie möglich und so konkret wie nötig geschnitten werden.

00:17:48: Das ist etwas Spannisch an.

00:17:54: Der größte Fehler Sofort wenn ich halt ins technische abrutsche das ist sehr mal verlassen dass sehr schnell verleiten.

00:18:02: also man kommt reddeffinell zu den menschluß ja wie das zum beispiel eines seelst was oder ein sap oder microsoft zu dann wird schon passen.

00:18:10: Das sollte man nicht machen.

00:18:11: es sollte auch die unternehmenssprach nebenbei spiegeln.

00:18:15: Ich habe mir mal hier bei bullet points zusammen geschrieben, was wir beim schneiden aufpassen.

00:18:21: Oder was man achten können sollte.

00:18:24: Also erstes Mal Es muss jeder verstehen.

00:18:28: Das ist schon mal die größte Schwierigkeit, deswegen empfehle ich hier auch im Englischen zu bleiben und auf gar keinen Fall irgendwelche deutschen Begriffe hier reinfließen zu lassen.

00:18:37: Es muss stabil über die Zeit sein weil Veränderungen habe ich schon ein bisschen vorhin angedriggert ist nicht drinnen.

00:18:45: es muss unabhängig von einzelnen Systemen, Applikationen und Plattformen sein.

00:18:49: das ist super wichtig.

00:18:52: redest du selbst so sprache über die für die ewigkeit auch wenn es das vielleicht einmal nicht mehr im laden hast.

00:18:59: Es muss relevant für mehrere fähigkeiten sein oder prozesse.

00:19:03: ein ganz wichtiges komme prozess der vermittelt spiel.

00:19:06: Wenn einfach datendaten definierst, die mendeffekt kennen hat nutzt kannst du gleich wegkauen wieder.

00:19:12: na Die sollen auf gar keinen fall technisch sein.

00:19:15: und fang nicht an sie nach irgendwelchen applikationen zu benennen.

00:19:19: Das ist Genau, das wird aus K-Szenario was du da noch vorstellen kannst.

00:19:24: Geh nicht zu tief!

00:19:25: Das heißt fangen einfach mit Level eins an also diese wirklich erste Ebene und dann nachher erst vielleicht in Ableitung nach innen noch hinzumachen.

00:19:34: jetzt zum Beispiel den Kunden.

00:19:35: wie ich es vorhin kurz ausgegliedert habe Fangen keine politischen Diskussionen an.

00:19:40: Ich hab z.B.

00:19:41: auch mal gesehen dass Leute anfangen Subcustomer zu nennen Und der Rest heißt Customer weil ich mein Customer Universum auf Sub Ebene habe und woanders, ganz schlimm.

00:19:53: Und das ist noch ein bisschen schwieriger im Unternehmen durchzusetzen, klare Ownership zu definieren.

00:20:02: Dazu kannst du wieder Fragen stellen wie zum Beispiel wird diese Information fachlich eigenständig verstanden?

00:20:10: Hast du eine eigene Verantwortlichkeit oder hast du einen eigenen Lebenszyklus für die Datendidee?

00:20:16: hat es vielleicht irgendeine regulatorische Bedeutung Dahinter?

00:20:22: ist dies für Reporting oder EI oder Entscheidungen irgendwie relevant.

00:20:27: Da kann man auch gut ableiten und zuordnen.

00:20:31: Es gibt auch Data Maturity Level, also du kannst diese Datendaten auch in Reifegrad zuweisen.

00:20:37: Und im Endeffekt auch dahinten in deinem Reifegrat.

00:20:42: Gerade das ist gemanagt für Daten.

00:20:44: Entitäten in den Mittelpunkt zu schieben oder auch bezüglich die Kritikalität von Datenen im Fokus zu heben.

00:20:53: Und vielleicht noch was letzte Frage ist, und da bringe ich jetzt vom Ownership – das habe ich glaube ihr schon gesagt – ist sie stabiler als eine einzelne Applikation?

00:21:03: Also ist diese Datenentität vorhanden im gesamten Unternehmen oder wirklich?

00:21:09: nur wird sie dann am Schluss für eine Applikierung genutzt?

00:21:13: Du kannst ja noch einen Test machen selber, probierst einfach aus.

00:21:17: Wenn du eine Datenidee mal geschnitten hast dann gehst du im Endeffekt einmal durch das Unternehmen durch, machst ein paar Gespräche und wenn es aber leider nur von der IT verstanden wird, dann hast du etwas falsch gemacht.

00:21:30: oder wenn es nur vor einem gewissen Kreis verstanden werden Dann hast du auch was falsch gemacht, dann musst du neu schneiden.

00:21:43: Kapitel V wie leitet man Datenideen ab?

00:21:47: Also, ich habe es glaube ich wiederholen mich gerade nochmal.

00:21:50: aber schneiden Sie bitte mache niemals den Fehler und leite sie von irgendwelchen Applikation ab auch wenns verloggt ist.

00:21:58: Sie werden immer von Capability's abgeleitet und sonst von gar nix.

00:22:03: also noch mal Business Capabilities und dann nachher die Datenidaten, dann die Applikations und dann ja diese Ableitung ist eigentlich relativ einfach einzuhalten.

00:22:18: Man muss da, das ist kein Rocket sein.

00:22:22: Sobald wir das jetzt abgeleitet haben korrekt.

00:22:25: dann kommt natürlich die nächste Frage wer es verantwortlich dafür und dass immer schon bei Kapitel sechs Data Ownership also beim Gehirn eigentlich wirklich die Daten Daten gehören.

00:22:42: halt kein System dieses ganz ganz wichtig vergisst das nicht?

00:22:47: Und setzt ihr das aus Grundsatz.

00:22:50: Die Systeme sind nicht die Ohne davon.

00:22:55: Es ist auch nicht automatisch irgendeinen DIT, die fühlt sich meistens für irgendwelche Daten verantwortlich.

00:23:04: und was ich erst vor ein paar Wochen mal gelernt habe in einem sehr interessanten Gespräch mit einem Freund der hat danach gesagt eigentlich hey du Das Data Ownership ist keine Besitzfrage.

00:23:20: Es gibt kein Ohner eigentlich, sondern es ist was anderes.

00:23:23: und eigentlich müsste dieses Data Ownerschip umgenannt werden als ist nämlich eine Verantwortung Frage also die Responsible.

00:23:30: Also eigentlich muss der Data Ownurship umgehend hauftwerten in Data Responsibility Und ich finde das viel treffender als eine Besitzfrage, sondern wer fühlt sich wirklich für Daten verantwortlich?

00:23:46: Prinzipiell gibt es sehr verschiedene Rollen im Unternehmen, die sich für Daten interessieren.

00:23:53: Das heißt jetzt nicht mit Rollen meine ich kein Titel oder so sondern Rollen halt.

00:23:57: Es gibt DataOna, es gibt SystemOna und es gibt DataConsumer in Rollen-Halt, die Manufactors aussagen... ...oder auch welche die Datacontroller sind Leute zum Beispiel die sich um regulatorische Rollen und personenbezogene Daten im Endeffekt kümmern etc.

00:24:19: So, wenn wir das im Endefekt auch geschafft haben dann stellt man sich natürlich jetzt die nächste Frage.

00:24:25: ich habe es jetzt schon in der letzten Beschreibung kurz angeteasert da sind die Datenregulatorien irgendwie kritisch Und das sind wir danach ja schon bei der Kapitel sieben regulatorische Themen wie zum Beispiel GDPAPIPL.

00:24:42: also das ist das chinesische Portons zu GDPR und Datenhaltung als solches.

00:24:49: Warum habe ich diese zwei Beispiele jetzt rausgenommen?

00:24:53: Weil sie gerade für Globalarchitekturen sehr wichtig sind, und finde ich immer ein wichtiger Aspekt, gerade aus der europäischen Brille heraus wird das oft ein bisschen vergessen.

00:25:06: Also wichtig zu diesem Kapitel Die Datenarchitektur, die Enden halt nicht im Modell.

00:25:13: Sie müssen einfach regulatorischen Anforderungen gerade an Speicherung und Zugriff und die Verarbeitung dahinter und vor allem die Übertragung und Datenhaltung berücksichtigen.

00:25:27: Und das fällt natürlich mit in den Data Governance.

00:25:31: am Ende des Tages fließt damit rein.

00:25:34: Die regulatorische Anforderung werden immer höher Und sobald du zum Beispiel gerade in diese irgendwelche EI Innovationen einsteigst, dann wirst du noch viel mehr regulatorische Anforderungen bekommen.

00:25:45: Wie zum Beispiel den EU Data Act oder den EI Act.

00:25:51: Die fließen da alle mit rein und ich glaube es wird noch ein bisschen mehr werden über die nächste Zeit.

00:26:00: Dabei reden wir halt nur über die EU.

00:26:02: Da gibt es natürlich weltweit von jedem Land ihre eigenen Süppchen, die gekocht werden.

00:26:07: Und natürlich sind wir Enterprise-Redeckten jetzt keine regulatorischen Profis besolven und uns damit beschäftigen und wissen welche existieren und welche Bereiche davon betroffen sind und vor allem welche Daten in die Däden damit sich gehen.

00:26:24: Das heißt immer wenn Wenn ich danach China höre, das Beispiel dann weiß ich schon mal ganz genau dass chinesische personenbezogene Daten auf keinen Fall aus China rausgehen dürfen oder irgendwo anders danach Verarbeiter gespeichert werden.

00:26:39: Es ist sehr ähnlich auch nebenbei zu GDPR.

00:26:42: es gibt da natürlich da gerade zu diesen PPL einiger Abweichungen aber nicht Teil unserer Story hier.

00:26:53: Wichtig ist einfach zu wissen Daten mit regulatorischen Themen in Kontakt kommen und daraus resultierend auch die kritische Elemente besser identifiziert werden kann.

00:27:13: So Kapitel A, Daten als Schlüssel zu EI.

00:27:16: Klar also EI beginnt nicht einfach so.

00:27:20: man braucht im Endeffekt Informationen oder Daten.

00:27:23: Die müssen einfach verstanden und dann richtig verantwortet werden.

00:27:27: Die müssten Qualitätsgesichert sein und natürlich regulatorisch nutzbar sein.

00:27:33: Und er braucht im Endeffekt Zauberdaten in den Daten, weil es genau auch in der gesamten Konstruktion methodisch vorgeht um dahinter klar zu definieren, nach wem gehören die da eigentlich?

00:27:44: Wie ist die Qualität dahinter?

00:27:45: Diese Analyse passiert ja dann... ...und einen Governance solltest du dann natürlich mitgeben dass halt da nicht ein Hexenwerk entsteht.

00:27:56: Und natürlich die klassische wachliche Bedeutung dahinter.

00:27:59: und technische Fügbarkeit, das musst du ja natürlich wissen.

00:28:02: Und die Enterprise-Architekten füttern die durch ihre Capabilitys definiert worden sind, durch diese Ableitungen und auch die Wichtigkeit für das Unternehmen.

00:28:14: Viele Organisationen starten halt immer mit der Frage welches Modell von ihr einnutzen wie welches Tool kaufen wir dann?

00:28:22: oder Welche Daten dürfen wir jetzt nutzen?

00:28:26: Was für Bedeutung haben Sie und wer verantwortet sie?

00:28:30: Beispiel ist oft, dass

00:28:33: z.B.,

00:28:34: wenn man Newscase ernehmt, wo es darum geht Grundberatung dann heißt natürlich nicht ich brauche nur einfach Grunddaten sondern ich brauch dann Customer, ich brauch Product, ich brauch die Order dahinter Ich brauche die Contracts gegeben falls ich braucht irgendwelche Service Histories, ich brauchen die Consent Da hörst du gerade raus, das sind alles Daten in den Taten in der Level eins und es ist alle notwendig um Kundendaten zu beschreiben.

00:29:01: So einfach ist es!

00:29:02: Und bei dem ganzen Views gesetzt muss natürlich klar sein woher kommen die Daten wie aktuell sind sie?

00:29:10: Wie gut sind sie von der Qualität?

00:29:12: darf ich sie überhaupt nutzen für solche Zwecke?

00:29:15: und wieder wer verantwortet sie und auf welche Kippe bilden die Zeit da ganz viel Spaß ein.

00:29:21: und natürlich welcher Business Value soll es am Ende des Tages ermöglichen.

00:29:27: Und das Ganze vom Punkt zu bringen, ohne Datenidäten sage ich da gleich funktioniert gar nix.

00:29:33: Keine Innovation und schon gar nicht EI!

00:29:36: Das wird auch endlich klar in die Köpfe von jedem eingetrichtert werden.

00:29:43: Wenn man jetzt nun ein Business Value identifiziert dann gibt es verschiedene Möglichkeiten.

00:29:48: Ich habe mir eine Methode entwickelt Die Zeit.

00:29:53: Also was ich immer gerne tue, ich komme von den Business Capabilities, leite sie in die Dateniditäten ab oder schaue halt welche da vorhanden sind weil... Ich bin in der Falle der News Case innerhalb der Fähigkeiten ja mehr Sucher oder Management oder was auch immer ein Lead-Management.

00:30:10: Dann gehe ich runter und schauen mal an wie ist das mit Türdelevel hinter der Datenidität?

00:30:14: Die Qualität habe ich im Ownership.

00:30:16: Wie schaut die Governance aus?

00:30:18: Was erlaubt Sie mir an dieser Stelle?

00:30:20: Und dann kann ich mit den Usges besser zusammenbauen und dem Business Value erstellen.

00:30:26: EI ist halt nicht der Anfang, es ist die Datenstrategie.

00:30:30: EIs zeigt nur schonungslos ob eine Strategie wirklich existiert und vor allem ob sie auch richtig exekutiert wird.

00:30:44: Ja da sind wir schon wieder am Ende einer der Folge rund um den Einstieg zu Datennetitäten.

00:30:52: Wir haben uns weiter vor allem halt einfach angeschaut, dass Capabilities oder Business Capabilities brauchen Informationen.

00:30:59: Sie erzeugen sie, sie konfirmieren sie und diese Informationen müssen als datendete Daten verstanden werden und nicht aufs Systeme.

00:31:10: Und wenn man das geschafft hat dann kann man auch in einer herglichen Kommunikation im Unternehmen einfach etabliern.

00:31:18: Und auch jede Art von Governance fließt auf einmal ganz anders und hat eine andere Marschrichtung als zuvor.

00:31:27: EI funktioniert halt nur, wenn es dort Daten hast.

00:31:32: Ich glaube gerade diese Folge wird dabei helfen das viel besser zu strukturieren.

00:31:38: Ein kurzer Ausblick auf die nächste Folge.

00:31:48: Wie man data TCO berechnet oder wie man den erzeugt.

00:31:52: Also, wie kann ich feststellen?

00:31:55: Wie teuer meine Daten sind dahinter und dabei reden wir nicht über Datenbanken und wie das Deutsch kostet.

00:32:02: Das ist ein super spannendes Thema!

00:32:05: Und es fließt in meiner Studie gerade rein die ich entwickelte rund um EI TCO.

00:32:12: Ja bist du auch hin?

00:32:14: Servus und Papa bis auf dem Ball.