Aufbau einer geschäftsorientierten Datenarchitektur

Von Techopedia Staff, 28. September 2016

Imbiss: Gastgeber Rebecca Jozwiak bespricht Datenarchitekturlösungen mit Eric Little von OSTHUS, Malcolm Chisholm von First San Francisco Partners und Ron Huizenga von IDERA.

Du bist derzeit nicht angemeldet. Bitte melde dich an oder registriere dich, um das Video zu sehen.

Rebecca Jozwiak: Sehr geehrte Damen und Herren, hallo und willkommen bei Hot Technologies of 2016. Heute diskutieren wir über „Aufbau einer geschäftsorientierten Datenarchitektur“, definitiv ein heißes Thema. Mein Name ist Rebecca Jozwiak, ich werde Ihr Gastgeber für den heutigen Webcast sein. Wir twittern mit einem Hashtag von # HotTech16. Wenn Sie also bereits auf Twitter sind, können Sie sich auch daran beteiligen. Wenn Sie zu irgendeinem Zeitpunkt Fragen haben, senden Sie diese bitte an den Frage- und Antwortbereich unten rechts auf Ihrem Bildschirm. Wir werden sicherstellen, dass sie beantwortet werden. Wenn nicht, sorgen wir dafür, dass unsere Gäste sie für Sie bekommen.

Heute haben wir also eine wirklich faszinierende Aufstellung. Heutzutage haben wir eine Menge Hitter. Wir haben Eric Little, VP of Data Science von OSTHUS. Für First San Francisco Partners haben wir Malcolm Chisholm, den Chief Innovation Officer, ein wirklich cooler Titel. Und wir haben Ron Huizenga, Senior Product Manager von IDERA. Und IDERA ist eine wirklich umfassende Suite von Datenmanagement- und Modellierungslösungen. Und heute wird er uns eine Demo geben, wie seine Lösung funktioniert. Aber bevor wir dazu kommen, Eric Little, werde ich den Ball an Sie weitergeben.

Eric Little: Okay, vielen Dank. Ich werde hier ein paar Themen durchgehen, von denen ich denke, dass sie etwas mit Rons Vortrag zu tun haben, und hoffentlich auch die Voraussetzungen für einige dieser Themen schaffen, einige Fragen und Antworten.

Das, was mich an den Aktivitäten von IDERA interessiert hat, ist, dass ich denke, sie weisen richtig darauf hin, dass komplexe Umgebungen heutzutage wirklich viele Unternehmenswerte vorantreiben. Und mit komplexen Umgebungen meinen wir komplexe Datenumgebungen. Die Technologie entwickelt sich sehr schnell und es ist schwierig, im heutigen Geschäftsumfeld mitzuhalten. Diejenigen, die in Technologieräumen arbeiten, werden häufig feststellen, dass Sie Kunden haben, die Probleme mit den folgenden Themen haben: „Wie verwende ich Big Data? Wie binde ich Semantik ein? Wie verbinde ich einige dieser neuen Inhalte mit meinen älteren Daten? “Und so weiter. Diese Art führt uns heutzutage zu diesen vier großen Datenmengen, mit denen viele Leute vertraut sind, und ich verstehe, dass es mehr als vier geben kann manchmal - ich habe bis zu acht oder neun gesehen - aber normalerweise, wenn Leute über Dinge wie Big Data sprechen oder wenn Sie über Big Data sprechen, dann schauen Sie normalerweise auf etwas, das eine Art von Unternehmensskala ist. Und so werden die Leute sagen, okay, denken Sie über das Volumen Ihrer Daten nach, das normalerweise im Mittelpunkt steht - genau so viel haben Sie. Die Geschwindigkeit der Daten hängt entweder davon ab, wie schnell ich sie verschieben oder wie schnell ich sie abfragen oder die Antworten erhalten kann, und so weiter. Und persönlich denke ich, dass die linke Seite davon etwas ist, das durch viele verschiedene Ansätze relativ schnell gelöst und gehandhabt wird. Aber auf der rechten Seite sehe ich viel Verbesserungspotential und viele neue Technologien, die wirklich in den Vordergrund rücken. Und das hat wirklich mit der dritten Spalte zu tun, der Datenvielfalt.

Mit anderen Worten, die meisten Unternehmen beschäftigen sich heutzutage mit strukturierten, halbstrukturierten und unstrukturierten Daten. Bilddaten werden langsam zu einem heißen Thema. Wenn Sie also Computer Vision verwenden, Pixel betrachten, Text, NLP und Entitätsextraktion kratzen können, haben Sie Diagramminformationen, die entweder aus statistischen Modellen oder aus semantischen stammen Modelle haben Sie relationale Daten, die in Tabellen usw. vorhanden sind. Das Zusammenführen all dieser Daten und all dieser unterschiedlichen Typen stellt also eine große Herausforderung dar. Sie werden dies bei Gartner und anderen Personen feststellen, die den Trends in der Branche folgen.

Und dann ist das Letzte, worüber die Leute in Big Data sprechen, oft der Begriff der Unvorsichtigkeit, der in Wirklichkeit die Unsicherheit Ihrer Daten und deren Unschärfe ist. Wie gut wissen Sie, worum es in Ihren Daten geht, wie gut verstehen Sie, was darin enthalten ist, und wissen Sie? Die Fähigkeit, Statistiken zu verwenden und Informationen zu verwenden, die sich auf das beziehen, was Sie vielleicht wissen, oder einen bestimmten Kontext zu verwenden, kann dort von Wert sein. Die Möglichkeit, Daten auf diese Weise zu betrachten, um festzustellen, wie viel Sie haben, wie schnell Sie sie verschieben oder abrufen müssen, über welche Arten von Daten Sie möglicherweise in Ihrem Unternehmen verfügen und wie sicher Sie sind, wo Sie sich befinden es ist, was es ist, in welcher Qualität es ist und so weiter. Dies erfordert wirklich einen großen, koordinierten Aufwand zwischen vielen Einzelpersonen, um ihre Daten effektiv zu verwalten. Die Modellierung von Daten gewinnt daher in der heutigen Welt zunehmend an Bedeutung. Gute Datenmodelle sind in Unternehmensanwendungen sehr erfolgreich.

Sie haben Datenquellen aus einer Vielzahl von Quellen, wie wir sagten, was wirklich viele verschiedene Arten der Integration erfordert. Daher ist es sehr nützlich, alles zusammenzufassen, um beispielsweise Abfragen für zahlreiche Arten von Datenquellen ausführen und Informationen zurückholen zu können. Dafür sind jedoch gute Zuordnungsstrategien erforderlich. Daher kann es eine echte Herausforderung sein, diese Art von Daten zuzuordnen und diese Zuordnungen beizubehalten. Und dann haben Sie diese Ausgabe von: Wie kann ich meine alten Daten mit all diesen neuen Datenquellen verknüpfen? Angenommen, ich habe ein Diagramm. Nehme ich alle relationalen Daten und zeichne sie auf? Normalerweise ist das keine gute Idee. Wie ist es also möglich, dass Menschen all diese Arten von Datenmodellen verwalten können, die derzeit laufen? Die Analyse muss wirklich für viele dieser verschiedenen Arten von Datenquellen und -kombinationen durchgeführt werden. Daher sind die Antworten, die sich daraus ergeben, die Antworten, die die Menschen benötigen, um wirklich gute Geschäftsentscheidungen zu treffen, von entscheidender Bedeutung.

Es geht also nicht nur darum, Technologie der Technologie zuliebe zu bauen. Es geht wirklich darum, was ich tun werde, was ich damit machen kann, welche Art von Analyse ich durchführen kann und welche Fähigkeiten ich daher bereits habe darüber gesprochen, dieses Zeug zusammenzubringen, es zu integrieren, ist wirklich sehr wichtig. Und eine dieser Arten von Analysen wird dann für föderierte Suchen und Abfragen ausgeführt. Das wird wirklich ein Muss. Ihre Abfragen müssen normalerweise über mehrere Arten von Quellen verteilt sein und Informationen zuverlässig zurückholen.

Das eine Schlüsselelement, das häufig, besonders die Leute, Schlüsselsachen wie semantische Technologien betrachten werden - und das ist etwas, von dem ich hoffe, dass Ron im IDERA-Ansatz ein wenig sprechen wird -, ist, wie Sie das trennen oder verwalten Modellschicht Ihrer Daten aus der Datenschicht selbst, aus diesen Rohdaten? Auf der Datenebene verfügen Sie möglicherweise über Datenbanken, Dokumentdaten, Tabellenkalkulationsdaten und Bilddaten. Wenn Sie in Bereichen wie der Pharmaindustrie tätig sind, verfügen Sie über große Mengen an wissenschaftlichen Daten. Darüber hinaus suchen die Benutzer normalerweise nach einer Möglichkeit, ein Modell zu erstellen, mit dem sie diese Daten schnell integrieren können, und wenn Sie wirklich nach Daten suchen, möchten Sie nicht alle Daten in Ihre Modellebene ziehen Wenn Sie sich die Modellebene ansehen, möchten Sie eine schöne logische Darstellung der Dinge, der gemeinsamen Vokabulare, der gemeinsamen Arten von Entitäten und Beziehungen und der Fähigkeit, wirklich auf die Daten zuzugreifen, in denen sie sich befinden, geben. Es muss also sagen, was es ist, und es muss sagen, wo es ist, und es muss sagen, wie man es holt und zurückbringt.

Das war ein Ansatz, der sehr erfolgreich war, um semantische Technologien voranzutreiben. In diesem Bereich arbeite ich viel. Eine Frage, die ich für Ron stellen wollte und die meiner Meinung nach im Abschnitt "Fragen und Antworten" nützlich sein wird, ist, wie dies durch die IDERA-Plattform erreicht wird. Ist die Modellschicht tatsächlich von der Datenschicht getrennt? Sind sie stärker integriert? Wie funktioniert das und was sind einige der Ergebnisse und Vorteile, die sie aus ihrem Ansatz ziehen? Daher werden Referenzdaten auch wirklich kritisch. Wenn Sie also über diese Art von Datenmodellen verfügen und in der Lage sind, Daten zusammenzufassen und über verschiedene Dinge hinweg zu suchen, müssen Sie wirklich über gute Referenzdaten verfügen. Das Problem ist jedoch, dass Referenzdaten sehr schwer zu pflegen sind. Daher ist es oftmals eine schwierige Herausforderung, Standards für sich zu benennen. Eine Gruppe nennt etwas X und eine Gruppe nennt etwas Y und jetzt haben Sie das Problem, wie jemand X und Y findet, wenn er nach dieser Art von Informationen sucht? Weil Sie ihnen nicht nur einen Teil der Daten geben möchten, möchten Sie ihnen alles geben, was damit zu tun hat. Gleichzeitig ändern sich die Bedingungen, und Software wird veraltet. Wie können Sie diese Referenzdaten im Laufe der Zeit aufrechterhalten und pflegen?

Und wieder haben semantische Technologien, die speziell Taxonomien und Vokabulare, also Datenwörterbücher, verwenden, einen Standardraum bereitgestellt, der wirklich sehr robust ist, bestimmte Arten von Standards verwendet, aber die Datenbank-Community hat dies für a getan lange Zeit auch, nur auf unterschiedliche Weise. Ich denke, einer der Schlüssel hier ist, darüber nachzudenken, wie man vielleicht Entitätsbeziehungsmodelle verwendet, wie man vielleicht Graphmodelle verwendet oder eine Art von Ansatz, der Ihnen hoffentlich eine Standardmethode für den Umgang mit Ihren Referenzdaten bietet. Sobald Sie die Referenzdaten haben, müssen die Zuordnungsstrategien natürlich eine Vielzahl von Namen und Entitäten verwalten. Fachexperten verwenden daher häufig ihre eigenen Begriffe.

Eine Herausforderung dabei ist also immer, wie Sie jemandem Informationen geben, diese aber für die Art und Weise relevant machen, in der er darüber spricht. So kann es vorkommen, dass eine Gruppe eine bestimmte Sichtweise hat, z. B. dass Sie ein Chemiker sind, der an einer Droge arbeitet, und dass Sie ein Strukturbiologe sind, der an derselben Droge arbeitet, und dass Sie für dieselben Entitätstypen unterschiedliche Namen haben die sich auf Ihr Gebiet beziehen. Sie müssen herausfinden, wie Sie diese personalisierten Terminologien zusammenführen können, da der andere Ansatz darin besteht, die Leute dazu zu zwingen, ihre Begriffe fallen zu lassen und die anderer zu verwenden, die sie oft nicht mögen. Ein weiterer Punkt ist, dass der Umgang mit einer großen Anzahl von Synonymen schwierig wird, sodass die Daten vieler Menschen viele verschiedene Wörter enthalten, die auf dasselbe verweisen können. Sie haben dort ein Referenzproblem, wenn Sie mehrere Beziehungen verwenden. Fachbegriffe variieren von Branche zu Branche. Wenn Sie also eine übergreifende Lösung für diese Art der Datenverwaltung finden, wie einfach ist es, diese von einem Projekt oder einer Anwendung zu einer anderen zu übertragen? Das kann eine weitere Herausforderung sein.

Automatisierung ist wichtig und auch eine Herausforderung. Es ist teuer, Referenzdaten manuell zu verarbeiten. Es ist teuer, die manuelle Zuordnung zu halten, und es ist teuer, Fachexperten zu veranlassen, ihre täglichen Aufgaben nicht mehr auszuführen und ständig Datenwörterbücher zu reparieren und Definitionen usw. erneut zu aktualisieren. Wiederholbare Vokabeln sind wirklich sehr wertvoll. Das sind also Vokabeln, die Sie häufig außerhalb Ihres Unternehmens finden. Wenn Sie beispielsweise mit Rohöl arbeiten, gibt es bestimmte Arten von Vokabeln, die Sie aus Open-Source-Bereichen ausleihen können, genau wie bei Pharmazeutika, genau wie in der Bankenbranche und im Finanzwesen, genau wie in vielen Bereichen dieser Art. Die Leute stellen wiederverwendbare, generische und reproduzierbare Vokabeln zur Verfügung.

Wenn ich mir das IDERA-Tool wieder anschaue, bin ich gespannt, wie sie damit umgehen, wenn sie verschiedene Standards verwenden. In der semantischen Welt sieht man oft Dinge wie SKOS-Modelle, die Standards für mindestens breitere als / engere als Beziehungen liefern, und diese Dinge können in ER-Modellen schwierig sein, aber Sie wissen, nicht unmöglich, es hängt nur davon ab, wie viel davon Maschinen und die Verknüpfung, die Sie in diesen Arten von Systemen handhaben können.

Als letztes wollte ich nur einen Vergleich mit einigen semantischen Engines anstellen, die ich in der Branche sehe, und Ron ein wenig bitten, darüber zu sprechen, wie das IDERA-System in Verbindung mit irgendwelchen semantischen Technologien verwendet wurde. Ist es in der Lage, in Triple-Stores und Graph-Datenbanken integriert zu werden? Wie einfach ist es, externe Quellen zu verwenden, da solche Dinge in der semantischen Welt häufig mit SPARQL-Endpunkten ausgeliehen werden können? Sie können RDF- oder OWL-Modelle direkt in Ihr Modell importieren - verweisen Sie darauf -, also zum Beispiel auf die Gen-Ontologie oder die Protein-Ontologie, die mit ihrer eigenen Governance-Struktur irgendwo in ihrem eigenen Raum leben können und ich kann einfach alle oder importieren ein Teil davon, wie ich es in meinen eigenen Modellen brauche. Und ich bin gespannt, wie IDERA dieses Problem angeht. Müssen Sie alles intern warten, oder gibt es Möglichkeiten, andere Arten standardisierter Modelle zu verwenden und diese einzufügen, und wie funktioniert das? Und das Letzte, was ich hier erwähnt habe, ist, wie viel manuelle Arbeit wirklich erforderlich ist, um die Glossare und Metadaten-Repositorys zu erstellen.

Ich weiß also, dass Ron uns einige Demos zu solchen Dingen zeigen wird, die wirklich interessant sein werden. Das Problem, das ich häufig bei Kunden sehe, ist, dass viele Fehler auftreten, wenn Benutzer ihre eigenen Definitionen oder Metadaten eingeben. So kommt es zu Rechtschreibfehlern, zu Fettfingerfehlern, das ist eine Sache. Sie bekommen auch Leute, die etwas von Wikipedia oder einer Quelle nehmen, die nicht unbedingt die Qualität hat, die Sie in Ihrer Definition haben möchten, oder Ihre Definition ist nur aus der Perspektive einer Person, also nicht vollständig, und es ist dann nicht klar Wie funktioniert der Governance-Prozess? Governance ist natürlich ein sehr, sehr großes Thema, wenn Sie über Referenzdaten sprechen und wenn Sie darüber sprechen, wie diese in die Stammdaten einer Person passen, wie sie ihre Metadaten verwenden wird und bald.

Ich wollte nur einige dieser Themen veröffentlichen. Dies sind Dinge, die ich im Geschäftsbereich in vielen verschiedenen Arten von Beratungsaufträgen und in vielen verschiedenen Bereichen sehe, und ich bin wirklich gespannt, was Ron uns mit IDERA zeigen wird, um auf einige dieser Themen hinzuweisen . Also vielen Dank.

Rebecca Jozwiak: Vielen Dank, Eric, und ich mag Ihren Kommentar wirklich, dass viele Fehler auftreten können, wenn Leute ihre eigenen Definitionen oder Metadaten schreiben. Ich weiß, dass es in der Welt des Journalismus ein Mantra gibt, das besagt, dass "viele Augen nur wenige Fehler machen", aber wenn es um praktische Anwendungen geht, neigen zu viele Hände im Keksdose dazu, eine Menge zerbrochener Kekse zu hinterlassen, oder?

Eric Little: Ja, und Keime.

Rebecca Jozwiak: Ja. Damit gehe ich voran und gebe es an Malcolm Chisholm weiter. Malcolm, der Boden gehört dir.

Malcolm Chisholm: Vielen Dank, Rebecca. Ich möchte ein bisschen auf das schauen, worüber Eric gesprochen hat, und ein paar Beobachtungen ergänzen, auf die Ron möglicherweise auch mit dem Thema „Toward Business-Driven Data Architecture“ eingehen möchte ”- was bedeutet es, geschäftstüchtig zu sein und warum ist das wichtig? Oder ist es nur eine Art Hype? Das glaube ich nicht.

Wenn wir uns ansehen, was seitdem passiert ist, wissen Sie, dass Mainframe-Computer tatsächlich für Unternehmen verfügbar wurden - etwa um 1964 -, dann können wir bis heute feststellen, dass es eine Menge Änderungen gegeben hat. Und diese Änderungen würde ich als Verschiebung von prozessorientierter zu datenzentrierter Darstellung zusammenfassen. Deshalb sind geschäftsorientierte Datenarchitekturen heute so wichtig und relevant. Und ich denke, weißt du, es ist nicht nur ein Modewort, es ist etwas, das absolut real ist.

Aber wir können es ein bisschen mehr zu schätzen wissen, wenn wir in die Geschichte eintauchen, also in eine Zeit zurückgehen, die bis in die 1960er Jahre zurückreicht und einige Zeit später von Mainframes dominiert wird. Diese machten dann den PCs Platz, auf denen die Benutzer tatsächlich rebellierten, als die PCs eintrafen. Die Rebellion gegen die zentralisierte IT, von der sie glaubten, dass sie ihre Bedürfnisse nicht erfüllten, war nicht agil genug. Das führte schnell zu verteiltem Rechnen, wenn PCs miteinander verbunden wurden. Und dann begann das Internet, das die Grenzen des Unternehmens verwischte - es konnte nun mit Parteien außerhalb des Unternehmens in Bezug auf den Datenaustausch interagieren, was zuvor noch nicht geschehen war. Und jetzt sind wir in die Ära von Cloud und Big Data eingetreten, in der die Cloud Plattformen darstellt, die die Infrastruktur tatsächlich kommodifizieren, und wir verlassen sozusagen die IT, weil wir Big Data Center betreiben müssen Ich habe die Cloud-Kapazität, die uns zur Verfügung steht, zusammen mit den großen Datenmengen, die Eric, wie Sie wissen, so eloquent besprochen hat. Und insgesamt, wie wir sehen, ist der technologische Wandel datenzentrierter geworden, und wir kümmern uns mehr um Daten. Wie im Internet, wie Daten ausgetauscht werden. Bei Big Data die vier oder mehr Vs der Daten selbst.

Gleichzeitig, und vielleicht noch wichtiger, haben sich die Geschäftsanwendungsfälle verschoben. Bei der Einführung von Computern wurden diese zum Automatisieren von Büchern und Aufzeichnungen verwendet. Und alles, was ein manueller Prozess war, der Sachbücher oder ähnliches beinhaltete, wurde im Wesentlichen im eigenen Haus programmiert. Dies verlagerte sich in den 80er Jahren auf die Verfügbarkeit von Betriebspaketen. Sie brauchten keine eigene Gehaltsabrechnung mehr zu schreiben, Sie konnten etwas kaufen, das es tat. Dies führte zu einem starken Downsizing oder einer Umstrukturierung in vielen IT-Abteilungen. Aber dann tauchte Business Intelligence mit Dingen wie Data Warehouses vor allem in den 90er Jahren auf. Gefolgt von Dotcom-Geschäftsmodellen, die natürlich ein großer Rausch waren. Dann MDM. Mit MDM werden Sie feststellen, dass wir nicht an Automatisierung denken. Wir konzentrieren uns nur darauf, Daten als Daten zu kuratieren. Und dann Analytics, die den Wert darstellen, den Sie aus den Daten ziehen können. Und in der Analytik sehen Sie sehr erfolgreiche Unternehmen, deren Kerngeschäftsmodell sich auf Daten konzentriert. Google, Twitter, Facebook wären ein Teil davon, aber man könnte auch argumentieren, dass Walmart dies ist.

Und so denkt das Geschäft jetzt wirklich über Daten nach. Wie können wir aus Daten einen Nutzen ziehen? Wie Daten das Geschäft, die Strategie und das goldene Zeitalter der Daten bestimmen können. Was passiert also in Bezug auf unsere Datenarchitektur, wenn Daten nicht mehr nur als der Auspuff betrachtet werden, der aus dem Back-End von Anwendungen stammt, sondern wirklich zentral für unsere Geschäftsmodelle ist? Nun, ein Teil des Problems, das wir haben, um dies zu erreichen, ist die IT, die in der Vergangenheit wirklich im Lebenszyklus der Systementwicklung stecken geblieben ist. Dies war eine Folge der raschen Bewältigung dieser Phase der Prozessautomatisierung im frühen Alter der IT und der Arbeit in Projekte ist eine ähnliche Sache. Für die IT - und das ist eine kleine Karikatur - aber ich versuche zu sagen, dass einige der Hindernisse für eine geschäftsorientierte Datenarchitektur darin bestehen, dass wir eine Kultur in der IT sozusagen unkritisch akzeptiert haben das stammt aus einer vergangenen Zeit.

Also ist alles ein Projekt. Nennen Sie mir Ihre Anforderungen im Detail. Wenn die Dinge nicht funktionieren, liegt es daran, dass Sie mir Ihre Anforderungen nicht mitgeteilt haben. Nun, das funktioniert heute nicht mit Daten, da wir nicht mit nicht automatisierten manuellen Prozessen oder einer technischen Konvertierung von Geschäftsprozessen beginnen, sondern sehr oft mit bereits vorhandenen Produktionsdaten, die wir versuchen Wert herausholen aus. Aber niemand, der ein datenorientiertes Projekt sponsert, versteht diese Daten wirklich genau. Wir müssen Daten ermitteln, wir müssen die Quelldaten analysieren. Und das passt nicht wirklich zur Systementwicklung, wissen Sie - Wasserfall, SDLC-Lebenszyklus - von der Agile, wie ich behaupten würde, eine Art bessere Version davon ist.

Der Fokus liegt auf Technologie und Funktionalität, nicht auf Daten. Wenn wir zum Beispiel in einer Testphase testen, funktioniert meine Funktionalität normalerweise, sagen wir, meine ETL, aber wir testen die Daten nicht. Wir testen nicht unsere Annahmen über die eingehenden Quelldaten. Wenn wir dies tun, wären wir vielleicht in besserer Verfassung und als jemand, der Data-Warehouse-Projekte durchgeführt und durch vorgelagerte Änderungen gelitten hat und meine ETLs zerstört hat, würde ich das begrüßen. In der Tat wollen wir das Testen als einen vorbereitenden Schritt für die kontinuierliche Überwachung der Produktionsdatenqualität sehen. Wir haben also eine Reihe von Einstellungen, in denen es schwierig ist, eine geschäftsorientierte Datenarchitektur zu erreichen, da wir von der Ära der Prozessorientierung abhängig sind. Wir müssen den Übergang zur Datenzentrierung vollziehen. Und das ist kein vollständiger Übergang, wissen Sie, da draußen ist noch viel Prozessarbeit zu erledigen, aber wir denken nicht wirklich datenzentriert, wenn es nötig ist, und die Umstände, die auftreten, wenn wir wirklich sind dazu verpflichtet.

Jetzt erkennt das Unternehmen den Wert der Daten. Sie möchten die Daten entsperren. Wie machen wir das? Wie machen wir den Übergang? Wir stellen Daten in den Mittelpunkt der Entwicklungsprozesse. Und wir lassen das Geschäft mit Informationsanforderungen führen. Und wir verstehen, dass zu Beginn des Projekts niemand die vorhandenen Quelldaten versteht. Man könnte argumentieren, dass die Datenstruktur und die Daten selbst durch die IT bzw. den Betrieb dorthin gelangt sind. Das sollten wir wissen, aber im Grunde tun wir das nicht. Dies ist eine datenorientierte Entwicklung. Wenn wir uns überlegen, wo und wie wir in einer datenorientierten Welt Datenmodelle erstellen, müssen wir den Benutzern Feedback-Schleifen geben, um ihre Informationsanforderungen zu verfeinern, ebenso wie Datenermittlung und Datenprofilerstellung Sehen Sie eine Analyse der Quelldaten voraus, und mit der Zeit erhalten wir immer mehr Gewissheit über unsere Daten. Und jetzt spreche ich von einem traditionelleren Projekt wie einem MDM-Hub oder einem Data Warehouse, nicht unbedingt den Big-Data-Projekten, obwohl dies, wie ich behaupte, immer noch ziemlich nahe daran ist. Zu diesen Rückkopplungsschleifen gehören also die Datenmodellierer, die ihr Datenmodell schrittweise weiterentwickeln und mit den Benutzern interagieren, um sicherzustellen, dass die Informationsanforderungen basierend auf dem, was möglich und verfügbar ist, aus den Quelldaten verfeinert werden, so wie sie es besser verstehen Es ist kein Fall mehr, dass das Datenmodell in einem Zustand ist, in dem es entweder nicht vorhanden oder vollständig fertig ist. Es wird schrittweise in den Fokus gerückt.

Darüber hinaus haben wir eine Qualitätssicherung, bei der wir Regeln für Datenqualitätstests entwickeln, um sicherzustellen, dass die Daten innerhalb der Parameter liegen, von denen wir ausgehen. Als Eric eintrat, bezog er sich auf Änderungen der Referenzdaten, die auftreten könnten. Sie möchten nicht gleichsam ein nachgeschaltetes Opfer einer Art von nicht verwaltetem Wandel in diesem Bereich sein, sodass die Qualitätssicherungsregeln in die kontinuierliche Überwachung der Datenqualität nach der Produktion einfließen können. Sie können also sehen, ob wir datenzentriert sein werden, und wie wir datenzentriert entwickeln, unterscheidet sich erheblich von der funktionsbasierten SDLC und Agile. Und dann müssen wir auch die geschäftlichen Ansichten berücksichtigen. Wir haben - und das stimmt auch mit Eric überein - ein Datenmodell, das einen Data-Story-Entwurf für unsere Datenbank definiert, aber gleichzeitig brauchen wir diese konzeptionellen Modelle, diese Geschäftsansichten von Daten, die traditionell nicht erstellt wurden die Vergangenheit. Ich denke, wir haben manchmal gedacht, dass das Datenmodell alles kann, aber wir müssen die konzeptionelle Sicht, die Semantik und den Blick in die Daten haben und sie durch eine Abstraktionsschicht rendern, die das Speichermodell in das Geschäft übersetzt Aussicht. Und noch einmal, all die Dinge, über die Eric in Bezug auf die Semantik gesprochen hat, werden wichtig, damit wir zusätzliche Modellierungsaufgaben haben. Ich denke, das ist interessant, wenn Sie als Datenmodellierer in die oberen Ränge gekommen sind, wie ich es getan habe, und wieder etwas Neues.

Abschließend möchte ich sagen, dass die größere Architektur auch diese neue Realität widerspiegeln muss. Zum Beispiel ist traditionelles Kunden-MDM eine Art, okay, lassen Sie uns unsere Kundendaten in einen Hub bringen, in dem wir sie, wie Sie wissen, in Bezug auf die Datenqualität für Back-Office-Anwendungen sinnvoll einsetzen können. Was aus Sicht der Geschäftsstrategie eine Art Gähnen ist. Heute betrachten wir jedoch Kunden-MDM-Hubs, die zusätzliche Kundenprofildaten enthalten, nicht nur statische Daten, die dann tatsächlich eine bidirektionale Schnittstelle zu Transaktionsanwendungen des Kunden haben. Ja, sie unterstützen immer noch das Backoffice, aber jetzt wissen wir auch über diese Verhaltensweisen unserer Kunden Bescheid. Dies ist teurer zu bauen. Dies ist komplexer zu bauen. Aber es ist in einer Weise geschäftsorientiert, wie es das traditionelle Kunden-MDM nicht ist. Sie tauschen eine Ausrichtung auf das Unternehmen gegen einfachere Designs aus, die einfacher zu implementieren sind, aber für das Unternehmen ist dies das, was sie sehen möchten. Wir befinden uns wirklich in einer neuen Ära und ich denke, es gibt eine Reihe von Ebenen, auf die wir auf die geschäftsbestimmende Datenarchitektur reagieren müssen, und ich denke, es ist eine sehr aufregende Zeit, Dinge zu tun.

Also danke, zurück zu dir, Rebecca.

Rebecca Jozwiak: Vielen Dank, Malcolm, und ich habe es wirklich genossen, was Sie über Datenmodelle gesagt haben, um die geschäftliche Sicht zu stärken dass sich die Kultur verändern muss. Und ich bin mir ziemlich sicher, dass es im Hintergrund einen Hund gab, der Ihnen zu 100% zustimmte. Und damit werde ich den Ball an Ron weitergeben. Ich freue mich sehr auf Ihre Demo. Ron, der Boden gehört dir.

Ron Huizenga: Vielen Dank und bevor wir uns darauf einlassen, werde ich ein paar Folien durchgehen und dann ein bisschen Demo, weil, wie Eric und Malcolm darauf hingewiesen haben, dies ein sehr breites und tiefes Thema ist und Mit dem, wovon wir heute sprechen, kratzen wir nur an der Oberfläche, weil es so viele Aspekte und so viele Dinge gibt, die wir bei einer geschäftsorientierten Architektur wirklich berücksichtigen und betrachten müssen. Und unser Ansatz ist es, dieses Modell wirklich modellbasiert zu machen und aus den Modellen einen echten Wert abzuleiten, da Sie sie sowohl als Kommunikationsmittel als auch als Schicht zur Aktivierung anderer Systeme verwenden können. Unabhängig davon, ob Sie eine serviceorientierte Architektur oder andere Aufgaben ausführen, wird das Modell zum Lebenselixier der aktuellen Entwicklungen mit all den Metadaten und den Daten, über die Sie in Ihrem Unternehmen verfügen.

Worüber ich jedoch sprechen möchte, ist, dass ich fast einen Schritt zurück mache, weil Malcolm einen Teil der Geschichte der Entwicklung von Lösungen und dergleichen angesprochen hat. Ein Weg, um wirklich zu verdeutlichen, wie wichtig es ist, eine solide Datenarchitektur zu haben, ist ein Anwendungsfall, auf den ich sehr oft gestoßen bin, als ich mich in der Beratung befand, bevor ich eine Produktmanagement-Rolle antrat Es zeigte sich sehr schnell, wie schlecht Unternehmen ihre eigenen Daten verstehen, ob sie eine Geschäftstransformation durchführen oder nur einige vorhandene Systeme und dergleichen ersetzen. Wenn Sie sich für einen bestimmten Anwendungsfall wie diesen entscheiden, für einen Berater oder für eine Person, die gerade mit einer Organisation begonnen hat, oder für eine Organisation, die im Laufe der Jahre mit dem Erwerb verschiedener Unternehmen aufgebaut wurde, was Sie enden Es entsteht sehr schnell eine sehr komplexe Umgebung mit einer Reihe neuer Technologien sowie Legacy-Technologien, ERP-Lösungen und allem anderen.

Eines der Dinge, die wir mit unserem Modellierungsansatz wirklich tun können, ist die Beantwortung der Frage: Wie kann ich all das verstehen? Wir können wirklich anfangen, die Informationen zusammenzufügen, damit das Unternehmen die Informationen, die wir haben, richtig nutzen kann. Und es stellt sich heraus, was haben wir da draußen in diesen Umgebungen? Wie kann ich die Modelle verwenden, um die benötigten Informationen auszutreiben und diese Informationen besser zu verstehen? Und dann haben wir die traditionellen Arten von Metadaten für all die verschiedenen Dinge, wie die relationalen Datenmodelle, und wir sind es gewohnt, Dinge wie Definitionen und Datenwörterbücher zu sehen, wissen Sie, Datentypen und solche Dinge. Aber was ist mit zusätzlichen Metadaten, die Sie erfassen möchten, um sie wirklich noch aussagekräftiger zu machen? Wie zum Beispiel, welche Entitäten sind wirklich die Kandidaten, die Referenzdatenobjekte sein sollten, welche Stammdatenverwaltungsobjekte und diese Art von Dingen sein sollten, und binden sie zusammen. Und wie fließen die Informationen durch die Organisation? Daten fließen dahingehend, wie sie sowohl aus Prozesssicht als auch in Bezug auf den Informationsfluss durch unsere Unternehmen und die Art und Weise, in der sie durch die verschiedenen Systeme oder durch die Datenspeicher geleitet werden, konsumiert werden Wenn wir die I-Lösungen oder solche Dinge erstellen, verbrauchen wir tatsächlich die richtigen Informationen für die jeweilige Aufgabe.

Und dann ist es sehr wichtig, wie wir all diese Stakeholder zur Zusammenarbeit bringen können, und insbesondere die Geschäfts-Stakeholder, weil sie uns die wahre Bedeutung dieser Daten geben. Letztendlich besitzt das Unternehmen die Daten. Sie liefern die Definitionen für die Vokabeln und Dinge, über die Eric gesprochen hat, also brauchen wir einen Ort, um all das zusammenzubinden. Dies geschieht durch unsere Datenmodellierungs- und Datenrepository-Architekturen.

Ich werde ein paar Dinge ansprechen. Ich werde über ER / Studio Enterprise Team Edition sprechen. In erster Linie werde ich über das Datenarchitekturprodukt sprechen, in dem wir die Datenmodellierung durchführen, aber es gibt viele andere Komponenten der Suite, auf die ich nur ganz kurz eingehen werde. Sie sehen einen Ausschnitt aus dem Business Architect, in dem wir sowohl konzeptionelle Modelle als auch Geschäftsprozessmodelle erstellen und diese Prozessmodelle verknüpfen können, um die tatsächlichen Daten in unseren Datenmodellen zu verknüpfen. Es hilft uns wirklich, diese Verbindung herzustellen. Mit Software Architect können wir zusätzliche Konstrukte wie UML-Modellierung und solche Dinge erstellen, um einigen anderen Systemen und Prozessen, von denen wir sprechen, unterstützende Logik zu verleihen. Aber sehr wichtig, wenn wir nach unten gehen, haben wir das Repository und den Team-Server, und ich werde darüber als eine Art von zwei Hälften derselben Sache sprechen. Im Repository werden alle modellierten Metadaten sowie alle Geschäftsmetadaten in Form von Geschäftsglossaren und Begriffen gespeichert. Und da wir diese Repository-basierte Umgebung haben, können wir all diese verschiedenen Dinge in derselben Umgebung zusammenfügen und sie dann tatsächlich für den Verbrauch verfügbar machen, nicht nur für die Techniker, sondern auch für die Geschäftsleute. Und so beginnen wir wirklich, die Zusammenarbeit voranzutreiben.

Und das letzte Stück, über das ich kurz sprechen werde, ist, dass Sie nicht nur Datenbanken haben, wenn Sie in diese Umgebungen gehen. Sie werden eine Reihe von Datenbanken haben, Datenspeicher, Sie werden auch eine Menge, wie ich es nennen würde, veralteter Artefakte haben. Vielleicht haben die Leute Visio oder andere Diagramme verwendet, um einige Dinge herauszufinden. Vielleicht hatten sie andere Modellierungswerkzeuge und so etwas. Mit dem MetaWizard können wir also tatsächlich einige dieser Informationen extrahieren und in unsere Modelle einbringen, sie auf den neuesten Stand bringen und sie verwenden, sie wieder auf aktuelle Weise verbrauchen, anstatt sie nur dort draußen stehen zu lassen. Es wird jetzt ein aktiver Teil unserer Arbeitsmodelle, was sehr wichtig ist.

Wenn Sie, wie ich bereits sagte, in eine Organisation eintreten, gibt es viele unterschiedliche Systeme, viele ERP-Lösungen und nicht übereinstimmende Abteilungslösungen. Viele Organisationen verwenden auch SaaS-Lösungen, die auch extern gesteuert und verwaltet werden. Wir kontrollieren also nicht die Datenbanken und diese Art von Dingen auf den Hosts, aber wir müssen immer noch wissen, wie diese Daten aussehen, und natürlich die Metadaten dazu. Was wir auch finden, sind viele veraltete Legacy-Systeme, die aufgrund dieses projektbasierten Ansatzes, über den Malcolm gesprochen hatte, nicht bereinigt wurden. Es ist erstaunlich, wie Unternehmen in den letzten Jahren Projekte aufbauen, ein System oder eine Lösung ersetzen, aber oftmals ist nicht mehr genügend Projektbudget vorhanden, um die veralteten Lösungen außer Betrieb zu setzen. Jetzt sind sie nur noch im Weg. Und wir müssen herausfinden, was wir in unserer Umgebung tatsächlich loswerden können und was für die Zukunft nützlich ist. Und das knüpft an die schlechte Stilllegungsstrategie an. Das ist ein wesentlicher Bestandteil derselben Sache.

Da aus all diesen unterschiedlichen Lösungen viele Organisationen entstanden sind, stellen wir auch fest, dass sich viele Punkt-zu-Punkt-Schnittstellen mit vielen Daten an mehreren Stellen bewegen. Wir müssen in der Lage sein, dies zu rationalisieren und die zuvor kurz erwähnte Datenherkunft herauszufinden, damit wir eine kohärentere Strategie wie die Nutzung einer serviceorientierten Architektur, von Enterprise-Service-Bussen und dergleichen verfolgen können, um die richtigen Informationen zu liefern zu einem Publish-and-Subscribe-Modell, das wir in unserem gesamten Unternehmen korrekt verwenden. Und dann müssen wir natürlich noch einige Analysen durchführen, egal ob wir Data Warehouses, Data Marts mit traditioneller ETL oder einige der neuen Data Lakes verwenden. Alles läuft auf dasselbe hinaus. Es sind alles Daten, ob es sich um Big Data handelt, ob es sich um herkömmliche Daten in relationalen Datenbanken handelt, wir müssen all diese Daten zusammenführen, damit wir sie verwalten und wissen, womit wir uns in unseren Modellen befassen.

Die Komplexität, die wir tun werden, besteht wiederum in einer Reihe von Schritten, die wir ausführen möchten. Zuallererst gehen Sie hinein und haben möglicherweise nicht die Pläne, wie diese Informationslandschaft aussieht. In einem Datenmodellierungstool wie ER / Studio Data Architect werden Sie zunächst eine Menge Reverse Engineering durchführen, um auf die Datenquellen zu verweisen, diese einzubringen und sie dann tatsächlich zu repräsentativeren zusammenzufügen Modelle, die das gesamte Unternehmen repräsentieren. Wichtig ist, dass wir diese Modelle auch nach Geschäftsbereichen aufteilen können, damit wir sie in kleinere Teile aufteilen können, auf die sich auch unsere Geschäftsleute beziehen können, sowie unsere Geschäftsanalysten und andere Stakeholder, die arbeiten darauf.

Namensstandards sind extrem wichtig und ich spreche hier auf verschiedene Arten darüber. Namensstandards in Bezug darauf, wie wir Dinge in unseren Modellen benennen. In logischen Modellen, in denen wir eine gute Benennungskonvention und ein gutes Datenwörterbuch für unsere Modelle haben, ist dies recht einfach, aber wir sehen auch unterschiedliche Benennungskonventionen für viele dieser physischen Modelle, die wir einbringen Reverse Engineer, oft sehen wir abgekürzte Namen und solche Dinge, über die ich sprechen werde. Und wir müssen diese zurück in aussagekräftige englische Namen übersetzen, die für das Unternehmen von Bedeutung sind, damit wir verstehen können, welche Daten in der Umgebung vorhanden sind. Und dann werden sie durch universelle Zuordnungen zusammengefügt.

Darüber hinaus würden wir dann dokumentieren und weiter definieren und dort können wir unsere Daten mit so genannten Anhängen weiter klassifizieren, auf denen ich Ihnen ein paar Folien zeigen werde. Und wenn wir dann den Kreis schließen, wollen wir diese geschäftliche Bedeutung anwenden, in die wir unsere Geschäftsglossare einbinden und sie mit unseren verschiedenen Modellartefakten verknüpfen, damit wir wissen, wenn wir über einen bestimmten Geschäftsbegriff sprechen, wo dieser liegt in unseren Daten in der gesamten Organisation umgesetzt. Und zum Schluss habe ich bereits darüber gesprochen, dass wir all das brauchen, um ein Repository mit vielen Möglichkeiten für die Zusammenarbeit und Veröffentlichung zu schaffen, damit unsere Stakeholder es nutzen können. Ich werde ziemlich schnell über Reverse Engineering sprechen. Ich habe dir schon ein kurzes Highlight gegeben. Ich werde Ihnen das in einer tatsächlichen Demo zeigen, um Ihnen einige der Dinge zu zeigen, die wir dort einbringen können.

Und ich möchte über einige der verschiedenen Modelltypen und Diagramme sprechen, die wir in einem solchen Szenario erstellen würden. Natürlich werden wir die konzeptionellen Modelle in vielen Fällen durchführen. Ich werde nicht viel Zeit damit verbringen. Ich möchte wirklich über logische Modelle, physikalische Modelle und die speziellen Modelltypen sprechen, die wir erstellen können. Und es ist wichtig, dass wir diese alle auf derselben Modellierungsplattform erstellen können, damit wir sie zusammenfügen können. Dazu gehören dimensionale Modelle sowie Modelle, die einige der neuen Datenquellen verwenden, z. B. das von mir gezeigte NoSQL. Und wie sieht dann das Datenherkunftsmodell aus? Und wie wir diese Daten zu einem Geschäftsprozessmodell zusammenfügen, darüber werden wir als Nächstes sprechen.

Ich werde hier auf eine Modellierungsumgebung umsteigen, um Ihnen einen sehr guten und schnellen Überblick zu geben. Und ich glaube, Sie sollten jetzt meinen Bildschirm sehen können. Zunächst möchte ich nur über eine traditionelle Art von Datenmodell sprechen. Und die Art und Weise, wie wir die Modelle organisieren möchten, wenn wir sie einbringen, ist, dass wir sie zerlegen können möchten. Was Sie hier auf der linken Seite sehen, ist, dass wir in dieser speziellen Modelldatei logische und physikalische Modelle haben. Das nächste ist, dass wir es entlang der Geschäftszerlegungen aufschlüsseln können. Deshalb sehen Sie die Ordner. Die hellblauen sind logische Modelle und die grünen sind physikalische Modelle. Wir können auch einen Drilldown durchführen. In ER / Studio können Sie also bei einer Geschäftszerlegung beliebig viele Ebenen oder Untermodelle durchgehen und Änderungen, die Sie auf den niedrigeren Ebenen vornehmen, werden automatisch auf der höheren Ebene wiedergegeben Ebenen. So wird es sehr schnell zu einer sehr leistungsfähigen Modellierungsumgebung.

Ich möchte auch darauf hinweisen, dass es sehr wichtig ist, mit dem Zusammenführen dieser Informationen zu beginnen, dass wir mehrere physikalische Modelle haben können, die auch einem logischen Modell entsprechen. Oft haben Sie ein logisches Modell, aber möglicherweise physische Modelle auf verschiedenen Plattformen und dergleichen. Vielleicht ist es eine SQL Server-Instanz, vielleicht eine Oracle-Instanz. Wir haben die Möglichkeit, all dies in derselben Modellierungsumgebung zusammenzuführen. Und wieder habe ich hier ein tatsächliches Data-Warehouse-Modell, das sich wiederum in derselben Modellierungsumgebung befinden kann, oder wir können es im Repository haben und es auch über verschiedene Dinge hinweg verknüpfen.

Was ich Ihnen unbedingt zeigen wollte, sind einige der anderen Dinge und Varianten der Modelle, auf die wir uns einlassen. Wenn wir also in ein traditionelles Datenmodell wie dieses eintauchen, sind wir es gewohnt, die typischen Entitäten mit den Spalten und den Metadaten und dergleichen zu sehen, aber dieser Standpunkt ändert sich sehr schnell, wenn wir uns mit einigen dieser neueren NoSQL-Technologien befassen oder, wie manche Leute sie immer noch gerne nennen, die Big-Data-Technologien.

Nehmen wir also an, wir haben auch Hive in unserer Umgebung. Wenn wir ein Reverse Engineering aus einer Hive-Umgebung durchführen - und mit genau demselben Modellierungswerkzeug ein Forward- und Reverse Engineering aus Hive durchführen können - sehen wir etwas, das ein bisschen anders ist. Wir sehen immer noch alle Daten als Konstrukte dort, aber unsere TDL ist anders. Diejenigen von Ihnen, die es gewohnt sind, SQL zu sehen, würden jetzt Hive QL sehen, das sehr SQL-ähnlich ist, aber mit demselben Tool können Sie jetzt mit den verschiedenen Skriptsprachen arbeiten. Sie können also in dieser Umgebung modellieren, sie in der Hive-Umgebung generieren, aber genauso wichtig ist, dass Sie in dem von mir beschriebenen Szenario alles rückentwickeln und verstehen und anfangen können, es auch zusammenzufügen .

Nehmen wir einen anderen, der etwas anders ist. MongoDB ist eine weitere Plattform, die wir nativ unterstützen. Und wenn Sie sich mit den JSON-Umgebungen befassen, in denen Dokumentenspeicher vorhanden sind, ist JSON ein anderes Tier, und es gibt Konstrukte, die keinen relationalen Modellen entsprechen. Sie werden sich bald mit Konzepten wie eingebetteten Objekten und eingebetteten Arrays von Objekten befassen, wenn Sie beginnen, JSON abzufragen, und diese Konzepte sind in der traditionellen relationalen Notation nicht vorhanden. Was wir hier getan haben, ist, dass wir die Notation und unseren Katalog erweitert haben, um dies in derselben Umgebung zu handhaben.

Wenn Sie hier links nachsehen, anstatt Entitäten und Tabellen zu sehen, bezeichnen wir sie als Objekte. Und Sie sehen verschiedene Notationen. Sie sehen hier noch die typischen Typen von Referenznotationen, aber diese blauen Entitäten, die ich in diesem bestimmten Diagramm zeige, sind tatsächlich eingebettete Objekte. Und wir zeigen verschiedene Kardinalitäten. Die Diamant-Kardinalität bedeutet, dass es sich um ein Objekt am einen Ende handelt. Die Kardinalität eines Objekts bedeutet jedoch, dass wir innerhalb des Publishers, wenn wir dieser Beziehung folgen, ein eingebettetes Adressobjekt haben. Bei der Abfrage von JSON haben wir festgestellt, dass es sich um genau dieselbe Objektstruktur handelt, die im Benutzer eingebettet ist, die jedoch tatsächlich als Array von Objekten eingebettet ist. Wir sehen das nicht nur durch die Konnektoren selbst, sondern wenn Sie sich die tatsächlichen Entitäten ansehen, werden Sie sehen, dass Adressen unter Benutzer angezeigt werden, die es auch als Array von Objekten klassifizieren. Sie erhalten eine sehr anschauliche Sichtweise, wie Sie das einbringen können.

Und wieder, was wir bisher in wenigen Sekunden gesehen haben, sind traditionelle relationale Modelle, die mehrstufig sind. Wir können dasselbe mit Hive tun, wir können dasselbe mit MongoDB und anderen Big-Data-Quellen wie Gut. Was wir auch tun können, und ich werde Ihnen dies nur sehr schnell zeigen, ist, dass ich über die Tatsache gesprochen habe, Dinge aus anderen Bereichen einzubringen. Ich gehe davon aus, dass ich ein Modell aus einer Datenbank importieren oder zurückentwickeln werde, aber ich werde es aus externen Metadaten einspielen. Nur um Ihnen einen kurzen Überblick über die verschiedenen Arten von Dingen zu geben, die wir einführen können.

Wie Sie sehen, haben wir eine Vielzahl von Dingen, mit denen wir die Metadaten tatsächlich in unsere Modellierungsumgebung bringen können. Angefangen bei Dingen wie Amazon Redshift, Cassandra und vielen anderen Big-Data-Plattformen. Dies ist in alphabetischer Reihenfolge. Wir sehen viele große Datenquellen und so etwas. Wir sehen auch eine Menge traditioneller oder älterer Modellierungsumgebungen, durch die wir diese Metadaten tatsächlich übertragen können. Wenn ich hier durchgehe - und ich werde nicht für jeden von ihnen Zeit aufwenden -, sehen wir viele verschiedene Dinge, aus denen wir sie einbringen können, in Bezug auf Modellierungsplattformen und Datenplattformen. Und etwas, das hier sehr wichtig ist, ist ein weiterer Teil, den wir tun können, wenn wir anfangen, über Datenherkunft zu sprechen. In der Enterprise Team Edition können wir auch ETL-Quellen abfragen, egal ob es sich um Talend- oder SQL Server Information Services-Zuordnungen handelt Bringen Sie dies tatsächlich ein, um auch unsere Datenherkunftsdiagramme zu starten und ein Bild davon zu zeichnen, was in diesen Transformationen vor sich geht. Insgesamt sind mehr als 130 dieser verschiedenen Bridges im Lieferumfang des Enterprise Team Edition-Produkts enthalten, sodass wir alle Artefakte sehr schnell in einer Modellierungsumgebung zusammenführen können.

Last but not least möchte ich auch darauf hinweisen, dass wir die Tatsache nicht aus den Augen verlieren können, dass wir die anderen Arten von Konstrukten benötigen, wenn wir Data Warehousing oder andere Arten von Analysen durchführen. Wir wollen immer noch die Fähigkeit haben, Dinge wie dimensionale Modelle zu tun, in denen wir Faktentabellen haben und wir haben Dimensionen und diese Arten von Dingen. Eine Sache, die ich Ihnen auch zeigen möchte, ist, dass wir auch Erweiterungen unserer Metadaten haben können, die uns helfen, die Arten von Dimensionen und alles andere zu kategorisieren. Wenn ich zum Beispiel die Registerkarte Dimensionsdaten hier betrachte, erkennt sie anhand des angezeigten Modellmusters automatisch, ob es sich um eine Dimension oder eine handelt Faktentabelle. Darüber hinaus können wir jedoch innerhalb der Dimensionen und dieser Art von Dingen unterschiedliche Dimensionen verwenden, um die Daten auch in einer Data-Warehousing-Umgebung zu klassifizieren. So mächtige Fähigkeiten, mit denen wir das alles zusammennähen.

Ich werde in dieses springen, da ich gerade in der Demo-Umgebung bin, und Ihnen ein paar andere Dinge zeigen, bevor ich zu den Folien zurückspringe. Eines der Dinge, die wir kürzlich zu ER / Studio Data Architect hinzugefügt haben, ist, dass wir auf Situationen gestoßen sind - und dies ist ein sehr häufiger Anwendungsfall, wenn Sie an Projekten arbeiten - Entwickler denken in Objekten, während unsere Daten Modellierer tendieren dazu, in Tabellen und Entitäten zu denken. Dies ist ein sehr vereinfachtes Datenmodell, es stellt jedoch einige grundlegende Konzepte dar, bei denen Entwickler oder sogar Geschäftsanalysten oder Geschäftsbenutzer sie möglicherweise als unterschiedliche Objekte oder Geschäftskonzepte betrachten. Bisher war es sehr schwierig, diese zu klassifizieren. In der Version 2016 von ER / Studio Enterprise Team Edition wurde jedoch ein Konzept mit dem Namen Business Data Objects eingeführt. Dies ermöglicht es uns, Gruppen von Entitäten oder Tabellen in echte Geschäftsobjekte zu kapseln.

In dieser neuen Ansicht haben wir zum Beispiel den Bestellkopf und den Bestellposten zusammengefasst. Sie sind als Objekt eingekapselt. Wir würden sie als Arbeitseinheit betrachten, wenn wir die Daten beibehalten und wir bringen sie zusammen, so dass es jetzt sehr einfach ist, das mit verschiedenen Zielgruppen in Verbindung zu bringen. Sie können in der gesamten Modellierungsumgebung wiederverwendet werden. Sie sind ein echtes Objekt, nicht nur ein Zeichnungskonstrukt, sondern wir haben auch den zusätzlichen Vorteil, dass wir, wenn wir tatsächlich aus der Modellierungsperspektive kommunizieren, sie selektiv reduzieren oder erweitern können, um eine zusammengefasste Ansicht für Dialoge mit bestimmten Stakeholder-Zielgruppen zu erstellen. und wir können natürlich auch die detailliertere Ansicht, wie wir sie hier sehen, für ein größeres technisches Publikum beibehalten. Es gibt uns wirklich ein wirklich gutes Kommunikationsmittel. Was wir jetzt sehen, ist das Kombinieren mehrerer verschiedener Modelltypen und deren Erweiterung mit dem Konzept von Geschäftsdatenobjekten. Jetzt werde ich darüber sprechen, wie wir diesen Dingen tatsächlich mehr Bedeutung verleihen und wie wir sie in unseren zusammenfügen Gesamtumgebungen.

Ich versuche nur, meinen WebEx hier zu finden, damit ich das tun kann. Und dann geht es zurück zu den Hot Tech-Folien. Ich werde hier nur ein paar Folien vorspulen, da Sie diese bereits in der Modelldemonstration selbst gesehen haben. Ich möchte sehr schnell über Namensstandards sprechen. Wir wollen unterschiedliche Namensstandards anwenden und durchsetzen. Was wir tun möchten, ist, dass wir die Möglichkeit haben, Namensstandardvorlagen tatsächlich in unseren Repositories zu speichern, um diese Bedeutung im Grunde durch Wörter oder Phrasen oder sogar Abkürzungen aufzubauen und sie mit einem aussagekräftigen englischen Worttyp zu verknüpfen. Wir werden Geschäftsbegriffe verwenden, die Abkürzungen für jeden, und wir können die Reihenfolge, die Groß- und Kleinschreibung angeben und Präfixe und Suffixe hinzufügen. Der typische Anwendungsfall hierfür ist normalerweise, wenn Benutzer ein logisches Modell erstellt haben und dann tatsächlich ein physisches Modell erstellen, in dem sie möglicherweise Abkürzungen und alles andere verwendet haben.

Das Schöne ist, es ist genauso mächtig, und umgekehrt sogar noch mächtiger. Wenn wir nur feststellen können, welche dieser Namensstandards für einige der von uns rückentwickelten physischen Datenbanken gelten, können wir diese Abkürzungen verwenden und in längere verwandeln Wörter, und bringen Sie sie rückwärts in englische Phrasen. Wir können jetzt tatsächlich Eigennamen für das ableiten, wie unsere Daten aussehen. Wie ich bereits sagte, ist der typische Anwendungsfall, dass wir vorwärts gehen, von logisch zu physisch und die Datenspeicher und diese Art von Dingen zuordnen. Wenn Sie sich den Screenshot auf der rechten Seite ansehen, werden Sie feststellen, dass die Quellennamen abgekürzt sind. Wenn wir eine Vorlage für Namensstandards angewendet haben, haben wir tatsächlich mehr vollständige Namen. Und wir könnten Leerzeichen und ähnliches einfügen, wenn wir möchten, abhängig von der von uns verwendeten Vorlage für Namensstandards. Wir können es so aussehen lassen, wie wir wollen, um es in unsere Modelle zu integrieren. Nur wenn wir wissen, wie etwas heißt, können wir ihm tatsächlich Definitionen hinzufügen, denn wie können wir ihm eine Bedeutung zuweisen, wenn wir nicht wissen, was es ist?

Das Schöne ist, dass wir dies tatsächlich aufrufen können, wenn wir alle möglichen Dinge tun. Ich habe über Reverse Engineering gesprochen. Wir können beim Reverse Engineering sogar gleichzeitig Namensvorlagen für Standards aufrufen. Wenn wir also die Konventionen kennen, können wir in einem Satz von Schritten durch einen Assistenten eine physische Datenbank rückentwickeln. Sie wird dann als physische Modelle in einer Modellierungsumgebung wiederhergestellt und ist es werde auch diese Namenskonventionen anwenden. Wir werden also sehen, wie die englischen Darstellungen von Namen im entsprechenden logischen Modell in der Umgebung sind. Wir können es auch tun und es mit der XML-Schema-Generierung kombinieren, um ein Modell zu erstellen und es sogar mit unseren Abkürzungen herauszugeben, unabhängig davon, ob wir SOA-Frameworks oder dergleichen verwenden, damit wir dann auch andere Namenskonventionen herausgeben können dass wir tatsächlich im Modell selbst gespeichert haben. Es gibt uns eine Menge sehr mächtiger Fähigkeiten.

Hier ist ein Beispiel dafür, wie es aussehen würde, wenn ich eine Vorlage hätte. Diese zeigt tatsächlich, dass ich EMP für "Mitarbeiter", SAL für "Gehalt", PLN für "Plan" in einer Namensnormenkonvention hatte. Ich kann sie auch anwenden, um sie interaktiv laufen zu lassen, während ich Modelle ausbaue und Dinge einbaue. Wenn ich diese Abkürzung verwende und "Employee Salary Plan" für den Entitätsnamen eingebe, würde dies mit der Vorlage für Namensstandards funktionieren Ich habe hier definiert, es hätte mir EMP_SAL_PLN gegeben, als ich die Entitäten erstellte, und mir sofort die entsprechenden physischen Namen gegeben.

Wiederum sehr gut, wenn wir konstruieren und das Engineering vorantreiben. Wir haben ein sehr einzigartiges Konzept und hier fangen wir wirklich an, diese Umgebungen zusammenzubringen. Und es heißt Universal Mappings. Nachdem wir alle diese Modelle in unsere Umgebung aufgenommen haben, können wir, sofern wir diese Namenskonventionen jetzt anwenden und sie leicht zu finden sind, ein Konstrukt namens Universal Mappings in ER verwenden /Studio. Wir können Entitäten modellübergreifend verknüpfen. Wo immer wir "Kunde" sehen - wir werden wahrscheinlich "Kunde" in vielen verschiedenen Systemen und in vielen verschiedenen Datenbanken haben - können wir anfangen, all diese miteinander zu verknüpfen, so dass ich, wenn ich damit arbeite, in einem Modell arbeite kann sehen, wo die Manifestationen der Kunden in den anderen Modellen sind. Und weil wir den Modell-Layer haben, der das repräsentiert, können wir ihn sogar an Datenquellen binden und in unseren Verwendungsnachfragen darauf zurückführen, in welchen Datenbanken sich diese ebenfalls befinden. Es gibt uns wirklich die Möglichkeit, all dies sehr zusammenhängend miteinander zu verbinden.

Ich habe Ihnen die Geschäftsdatenobjekte gezeigt. Ich möchte auch schnell auf die Metadatenerweiterungen eingehen, die wir als Anhänge bezeichnen. Dadurch können wir zusätzliche Metadaten für unsere Modellobjekte erstellen. Sehr oft habe ich diese Eigenschaftstypen eingerichtet, um viele verschiedene Aspekte aus der Perspektive der Datenverwaltung und Datenqualität herauszuholen und um uns bei der Stammdatenverwaltung und den Richtlinien zur Datenaufbewahrung zu helfen. Die Grundidee ist, dass Sie diese Klassifizierungen erstellen und sie an beliebiger Stelle anhängen können, auf Tabellenebene, Spaltenebene, diese Art von Dingen. Der häufigste Anwendungsfall ist natürlich, dass Entitäten Tabellen sind, und dann kann ich definieren: Was sind meine Stammdatenobjekte, was sind meine Referenztabellen, was sind meine Transaktionstabellen? Unter dem Gesichtspunkt der Datenqualität kann ich Klassifizierungen in Bezug auf die Bedeutung für das Unternehmen vornehmen, damit wir Datenbereinigungsbemühungen und dergleichen Prioritäten setzen können.

Was häufig übersehen wird, ist die Aufbewahrungsrichtlinie für verschiedene Datentypen in unserer Organisation? Wir können diese einrichten und sie tatsächlich an die verschiedenen Arten von Informationsartefakten in unserer Modellierungsumgebung und natürlich auch in unserem Repository anhängen. Das Schöne ist, dass diese Anhänge in unserem Datenwörterbuch vorhanden sind. Wenn wir also Enterprise-Datenwörterbücher in der Umgebung verwenden, können wir sie an mehrere Modelle anhängen. Wir müssen sie nur einmal definieren und können sie über die verschiedenen Modelle in unserer Umgebung hinweg immer wieder einsetzen. Dies ist nur ein kurzer Screenshot, der zeigt, dass Sie beim Erstellen eines Anhangs tatsächlich angeben können, an welche Teile Sie ihn anhängen möchten. Und dieses Beispiel hier ist tatsächlich eine Liste von Werten. Wenn Sie also in die Liste der Werte wechseln, haben Sie viel Kontrolle in der Modellierungsumgebung darüber, was ausgewählt wird, und Sie können sogar die Standardwerte festlegen value ist, wenn ein Wert nicht ausgewählt ist. Also viel Kraft da. Sie leben im Datenwörterbuch.

Etwas, das ich Ihnen weiter unten auf diesem Bildschirm zeigen möchte. Außerdem werden die Anhänge im oberen Bereich angezeigt. Darunter werden Informationen zur Datensicherheit angezeigt. Wir können Datensicherheitsrichtlinien auch auf die verschiedenen Informationen in der Umgebung anwenden. Für verschiedene Compliance-Zuordnungen und Datensicherheitsklassifizierungen liefern wir eine Reihe von Standardzuordnungen aus, die Sie erstellen und sofort verwenden können. Sie können jedoch auch Ihre eigenen Compliance-Zuordnungen und -Standards definieren. Egal, ob Sie HIPAA oder eine der anderen Initiativen durchführen. Und Sie können wirklich anfangen, diese sehr umfangreichen Metadaten in Ihrer Umgebung aufzubauen.

Und dann das Glossar und die Begriffe - hier ist die geschäftliche Bedeutung verankert. Es gibt häufig Datenwörterbücher, die ein Unternehmen als Ausgangspunkt für die Herausgabe von Glossaren verwendet, aber die Terminologie und die Aussprache sind oft sehr technisch. Was wir also tun können, ist, dass wir, wenn wir möchten, diese als Ausgangspunkt verwenden können, um Glossare zu vertreiben, aber wir möchten, dass das Unternehmen diese besitzt. In der Team-Server-Umgebung haben wir den Mitarbeitern die Möglichkeit gegeben, Geschäftsdefinitionen zu erstellen und sie dann mit den verschiedenen Modellartefakten zu verknüpfen, denen sie auch in der Modellierungsumgebung entsprechen. Wir erkennen auch den Punkt an, der zuvor besprochen wurde: Je mehr Menschen Sie tippen, desto mehr Potenzial besteht für menschliches Versagen. Was wir auch in unserer Glossarstruktur tun, ist, dass wir eine Hierarchie von Glossaren unterstützen, sodass wir verschiedene Glossartypen oder verschiedene Arten von Dingen in der Organisation haben können, aber genauso wichtig ist es, wenn Sie bereits einige dieser Quellen haben Mit den dort definierten Begriffen und allem, was dazu gehört, können wir tatsächlich einen CSV-Import durchführen, um diese in unsere Modellierungsumgebung und auch in unseren Team-Server oder unser Glossar zu ziehen und von dort aus mit der Verknüpfung zu beginnen. Und jedes Mal, wenn sich etwas ändert, gibt es einen vollständigen Audit-Trail darüber, was die Vorher- und Nachher-Bilder waren, was die Definitionen und alles andere betrifft und was Sie in naher Zukunft sehen werden, ist auch eher ein Autorisierungs-Workflow So können wir wirklich kontrollieren, wer dafür zuständig ist, Genehmigungen von Ausschüssen oder Einzelpersonen und dergleichen, um den Governance-Prozess in Zukunft noch robuster zu gestalten.

Für uns bedeutet dies auch, dass wir diese Glossarbegriffe in unserem Team-Server-Glossar haben. Dies ist ein Beispiel für die Bearbeitung einer Entität im Modell selbst, das ich hier angesprochen habe. Es gibt möglicherweise verknüpfte Begriffe, aber wir tun dies auch, wenn Wörter in diesem Glossar in den Notizen oder Beschreibungen unserer Entitäten enthalten sind und diese automatisch in einer helleren Hyperlink-Farbe angezeigt werden Wenn Sie mit der Maus darüber fahren, können Sie die Definition auch aus dem Geschäftsglossar ablesen. Es gibt uns sogar reichhaltigere Informationen, wenn wir die Informationen selbst konsumieren, mit all den Glossarbegriffen, die es gibt. Es hilft wirklich, die Erfahrung zu bereichern und die Bedeutung auf alles anzuwenden, mit dem wir arbeiten.

Das war also wieder ein sehr schneller Vorbeiflug. Natürlich könnten wir Tage damit verbringen, während wir uns in die verschiedenen Teile vertiefen, aber dies ist ein sehr schneller Vorbeiflug über die Oberfläche. Was wir wirklich anstreben, ist zu verstehen, wie diese komplexen Datenumgebungen aussehen. Wir möchten die Sichtbarkeit all dieser Datenartefakte verbessern und sie gemeinsam mit ER / Studio vertreiben. Wir wollen eine effizientere und automatisierte Datenmodellierung ermöglichen. Und das sind alle Arten von Daten, von denen wir sprechen, egal ob Big Data, traditionelle relationale Daten, Dokumentenspeicher oder irgendetwas anderes. Auch dies haben wir erreicht, weil wir leistungsstarke Vorwärts- und Rückwärtsentwicklungsfunktionen für die verschiedenen Plattformen und die anderen Tools haben, die Sie möglicherweise auf dem Markt haben. Und es geht darum, das gesamte Unternehmen mit allen beteiligten Stakeholdern zu teilen und zu kommunizieren. Hier wenden wir Bedeutung durch Namensstandards an. Wir wenden dann Definitionen über unsere Geschäftsglossare an. Anschließend können wir mit den Metadatenerweiterungen, z. B. Datenqualitätserweiterungen, Klassifizierungen für die Stammdatenverwaltung oder anderen Arten von Klassifizierungen, die Sie auf diese Daten anwenden möchten, weitere Klassifizierungen für alle unsere anderen Governance-Funktionen durchführen. Und dann können wir die Kommunikation mit den Geschäftsdatenobjekten und den verschiedenen Stakeholder-Zielgruppen, insbesondere zwischen Modellierern und Entwicklern, weiter zusammenfassen und verbessern.

Das Wichtigste dabei ist wiederum, dass sich dahinter ein integriertes Repository mit sehr robusten Change-Management-Funktionen verbirgt. Ich hatte heute keine Zeit, es zu zeigen, da es ziemlich komplex wird, aber das Repository verfügt über sehr robuste Änderungsverwaltungsfunktionen und Prüfpfade. Sie können benannte Releases erstellen, Sie können benannte Versionen erstellen, und wir haben auch die Möglichkeit für diejenigen von Ihnen, die Änderungsmanagement durchführen. Wir können dies direkt in Ihre Aufgaben einbinden. Wir haben heute die Möglichkeit, Aufgaben einzugeben und Ihre Modelländerungen mit Aufgaben zu verknüpfen, so wie Entwickler ihre Codeänderungen auch mit den Aufgaben oder User Stories verknüpfen würden, mit denen sie arbeiten.

Das war wieder ein sehr kurzer Überblick. Ich hoffe, es hat gereicht, um Ihren Appetit anzuregen, damit wir uns in Zukunft viel eingehender mit der Aufteilung einiger dieser Themen befassen können. Vielen Dank für Ihre Zeit und zurück zu Ihnen, Rebecca.

Rebecca Jozwiak: Danke, Ron, das war fantastisch und ich habe einige Fragen aus dem Publikum, aber ich möchte unseren Analysten die Möglichkeit geben, sich in das zu vertiefen, was Sie zu sagen hatten. Eric, ich werde weitermachen und wenn Sie diese Folie oder eine andere ansprechen möchten, warum gehen Sie nicht zuerst weiter? Oder irgendeine andere Frage.

Eric Little: Sicher. Entschuldigung, was war die Frage, Rebecca? Sie möchten, dass ich etwas Bestimmtes frage oder …?

Rebecca Jozwiak: Ich weiß, dass Sie anfangs einige Fragen an Ron hatten. Wenn Sie jetzt darum bitten möchten, dass er sich an einen von ihnen wendet, oder an einen von Ihnen, oder an irgendetwas anderem, das Ihr Interesse geweckt hat, nach dem Sie fragen möchten? Über die Modellierungsfunktionen von IDERA.

Eric Little: Ja, also eines der Dinge, Ron, wie geht es euch? Es sieht so aus, als wären die Diagramme, die Sie angezeigt haben, allgemeine Arten von Entity-Relationship-Diagrammen, wie Sie sie normalerweise bei der Datenbankkonstruktion verwenden würden, richtig?

Ron Huizenga: Ja, im Allgemeinen, aber natürlich haben wir die erweiterten Typen für die Dokumentenspeicher und solche Dinge auch. Wir haben tatsächlich von der reinen relationalen Notation abgewichen und auch für diese anderen Stores zusätzliche Notationen hinzugefügt.

Eric Little: Gibt es eine Möglichkeit, dass Sie graphbasierte Arten von Modellierungen verwenden können? Nehmen wir also beispielsweise an, dass ich so etwas wie einen Top Quadranten, ein TopBraid-Komponistentool oder etwas gemacht habe in Protégé oder, wissen Sie, wie die Finanzleute in der FIBO, sie leisten eine Menge Arbeit in Semantik und RDF - gibt es eine Möglichkeit, diese Art der Modellierung von Entity-Relationship-Graphen in dieses Tool einzubringen und zu nutzen es?

Ron Huizenga: Wir schauen uns gerade an, wie wir mit Diagrammen umgehen können. Wir beschäftigen uns heute nicht explizit mit Graphendatenbanken und dergleichen, aber wir suchen nach Möglichkeiten, wie wir dies tun können, um unsere Metadaten zu erweitern. Ich meine, wir können Dinge über XML und diese Art von Dingen jetzt einbringen, wenn wir zumindest eine Art von XML-Wiedergabe durchführen können, um sie als Ausgangspunkt zu verwenden. Aber wir suchen nach eleganteren Wegen, um das in die Tat umzusetzen.

Und ich habe Ihnen auch die Liste der Reverse Engineering-Bridges gezeigt, die wir auch dort haben. Daher sind wir immer bemüht, Erweiterungen für diese Bridges auch für bestimmte Plattformen zu erhalten. Es ist eine ständige, andauernde Anstrengung, wenn das Sinn macht, eine Menge dieser neuen Konstrukte und der verschiedenen Plattformen da draußen in Angriff zu nehmen. Aber ich kann sagen, dass wir definitiv an der Spitze dabei sind. Das Zeug, das ich zum Beispiel auf MongoDB und so gezeigt habe, sind wir der erste Datenmodellierungsanbieter, der das in unserem eigenen Produkt tatsächlich nativ macht.

Eric Little: Okay, ja. Die andere Frage, die ich an Sie stellte, betraf also die Steuerung und Aufrechterhaltung der - wie Sie es getan haben, als Sie das Beispiel der Person gezeigt haben, die ein "Angestellter" ist. Ich glaube, es war ein " Gehalt “und dann haben Sie einen„ Plan “, gibt es eine Möglichkeit, wie Sie beispielsweise mit verschiedenen Arten von Menschen umgehen können, die möglicherweise - nehmen wir an, Sie haben eine große Architektur, richtig, nehmen wir an, Sie haben ein großes Unternehmen und Die Leute fangen an, die Dinge in diesem Tool zusammenzuführen, und Sie haben hier eine Gruppe mit dem Wort "Mitarbeiter" und eine Gruppe mit dem Wort "Arbeiter". Eine Person hier sagt "Gehalt" und eine andere Person sagt "Lohn."

Wie versöhnt und verwaltet ihr diese Art von Unterscheidungen? Weil ich weiß, wie wir es in der Grafikwelt machen würden, Sie würden Synonymlisten verwenden, oder Sie würden sagen, dass es ein Konzept gibt und es mehrere Attribute hat, oder Sie könnten im SKOS-Modell sagen, dass ich ein bevorzugtes Label habe und ich habe zahlreiche alternative Bezeichnungen, die ich verwenden kann. Wie macht ihr das?

Ron Huizenga: Wir machen das auf verschiedene Arten und lassen uns zuerst über die Terminologie sprechen. Eines der Dinge, die wir natürlich tun, ist, dass wir die definierten oder sanktionierten Begriffe haben wollen, und im Geschäftsglossar ist offensichtlich, wo wir sie wollen. Wir erlauben auch Links zu Synonymen im Geschäftsglossar. Sie können also sagen, hier ist mein Begriff, aber Sie können auch definieren, was alle Synonyme für diese sind.

Das Interessante ist natürlich, wenn Sie anfangen, diese riesige Datenlandschaft mit all den verschiedenen Systemen zu durchsuchen, die Sie da draußen haben, können Sie nicht einfach dorthin gehen und die entsprechenden Tabellen und diese Art von Dingen ändern entsprechen diesem Benennungsstandard, da es sich möglicherweise um ein Paket handelt, das Sie gekauft haben, sodass Sie keinerlei Kontrolle über Änderungen an der Datenbank haben.

Wir könnten dort neben der Möglichkeit, die Glossardefinitionen zu verknüpfen, durch diese universellen Zuordnungen, über die ich gesprochen habe, ein übergreifendes logisches Modell erstellen, in dem erläutert wird, was zu tun ist Diese unterschiedlichen Geschäftskonzepte sprechen Sie an. Verknüpfen Sie die Geschäftsglossarbegriffe mit diesen Begriffen, und das Schöne ist, dass Sie jetzt dieses Konstrukt haben, das sozusagen eine logische Entität darstellt. Anschließend können Sie damit beginnen, eine Verknüpfung von dieser logischen Entität zu allen Implementierungen dieser logischen Entität in zu erstellen die verschiedenen Systeme.

Wo Sie das tun müssen, können Sie sehen, oh, "Person" heißt in diesem System "Angestellter". In diesem anderen System wird „Gehalt“ hier als „Lohn“ bezeichnet. Weil du das siehst, siehst du all die verschiedenen Manifestationen von denen, weil du sie miteinander verbunden hast.

Eric Little: Okay, großartig, verstanden. Ist es in diesem Sinne sicher zu sagen, dass dies mit einigen objektorientierten Ansätzen vergleichbar ist?

Ron Huizenga: Etwas. Es ist ein bisschen intensiver als, könnte man sagen. Ich meine, Sie könnten den Ansatz der manuellen Verknüpfung und Durchsicht sowie der Überprüfung und Durchführung all dieser Schritte wählen. Das einzige, worüber ich nicht wirklich sprechen konnte - denn wir haben wieder viele Möglichkeiten -, wir haben auch eine vollständige Automatisierungsschnittstelle im Data Architect-Tool selbst. Und eine Makrofunktion, die eigentlich eine Programmiersprache im Tool ist. So können wir beispielsweise Makros schreiben, sie ausschalten und Dinge abfragen und Links für Sie erstellen. Wir verwenden es zum Importieren und Exportieren von Informationen, wir können es zum Ändern von Dingen oder Hinzufügen von Attributen verwenden, ereignisbasiert im Modell selbst, oder wir können es verwenden, um in Stapeln zu arbeiten, um tatsächlich Dinge abzufragen und verschiedene Konstrukte im zu füllen Modell. Es gibt also eine vollständige Automatisierungsschnittstelle, die auch von Menschen genutzt werden kann. Und die Verwendung der universellen Zuordnungen mit diesen wäre eine sehr mächtige Möglichkeit, dies zu tun.

Rebecca Jozwiak: Okay, danke Ron und danke Eric. Das waren großartige Fragen. Ich weiß, wir rennen ein bisschen hinter der vollen Stunde her, aber ich möchte Malcolm die Chance geben, ein paar Fragen nach Rons Art zu werfen. Malcolm?

Malcolm Chisholm: Danke, Rebecca. Also, Ron, es ist sehr interessant, ich sehe, dass es hier viele Möglichkeiten gibt. Einer der Bereiche, an denen ich sehr interessiert bin, ist, wenn wir ein Entwicklungsprojekt haben, wie Sie sehen, dass der Datenmodellierer diese Funktionen nutzt und möglicherweise besser mit Geschäftsanalysten, einem Datenprofiler und einem Datenqualitätsanalysten zusammenarbeitet und mit den Geschäftspartnern, die letztendlich für die tatsächlichen Informationsanforderungen im Projekt verantwortlich sind. Wie macht der Datenmodellierer das Projekt mit den Funktionen, die wir uns ansehen, wirklich effektiver und effizienter?

Ron Huizenga: Ich denke, eines der ersten Dinge, die Sie dort tun müssen, ist ein Datenmodellierer - und ich möchte nicht einige der Modellierer auswählen, aber ich werde es trotzdem tun - einige Leute haben immer noch den Eindruck, dass Der Datenmodellierer ist wirklich die Art von Gatekeeper-Rolle. Wir definieren, wie es funktioniert. Wir sind die Wächter, die sicherstellen, dass alles korrekt ist.

Nun gibt es einen Aspekt davon, dass Sie sicherstellen müssen, dass Sie eine Sounddatenarchitektur und alles andere definieren. Das Wichtigste ist jedoch, dass Sie als Datenmodellierer - und das war mir bei der Beratung ziemlich offensichtlich - ein Moderator werden müssen, damit Sie diese Leute zusammenbringen können.

Es wird kein Design im Vorfeld, keine Generierung, keine Erstellung von Datenbanken mehr sein. Sie müssen in der Lage sein, mit all diesen verschiedenen Stakeholder-Gruppen zu arbeiten, Dinge wie Reverse Engineering durchzuführen, Informationen zu importieren, zu haben Andere Personen arbeiten zusammen, egal ob es sich um Glossare oder Dokumentationen handelt, und helfen Ihnen dabei, diese Informationen in das Repository zu übernehmen, die Konzepte im Repository zu verknüpfen und mit diesen Personen zu arbeiten.

Es handelt sich vielmehr um eine kollaborative Umgebung, in der die Mitarbeiter selbst durch die Definition von Aufgaben oder Diskussionsthreads oder dergleichen, die wir in Team Server haben, tatsächlich zusammenarbeiten, Fragen stellen und zu den endgültigen Endprodukten gelangen können, die sie haben brauchen für ihre Datenarchitektur und ihre Organisation. Hat diese Art von Antwort?

Malcolm Chisholm: Ja, ich stimme zu. Wissen Sie, ich denke, dass die Fähigkeit zur Moderation für Datenmodellierer sehr wünschenswert ist. Ich stimme zu, dass wir das nicht immer sehen, aber ich denke, dass dies notwendig ist, und ich würde vorschlagen, dass es manchmal eine Neigung gibt, bei der Datenmodellierung in Ihrer Ecke zu bleiben, aber Sie müssen wirklich mit den anderen Interessengruppen zusammenarbeiten oder Sie verstehen einfach nicht die Datenumgebung, mit der Sie es zu tun haben, und ich denke, das Modell leidet darunter. Aber das ist nur meine Meinung.

Ron Huizenga: Und es ist interessant, weil Sie in Ihrer Folie bereits erwähnt haben, wie Unternehmen sich von der IT abgewandt haben, weil sie die Lösungen nicht rechtzeitig und unter diesen Umständen geliefert haben.

Es ist sehr interessant, dass in meinen späteren Beratungsaufträgen, bevor ich Produktmanager wurde, die meisten Projekte, die ich in den letzten zwei Jahren zuvor durchgeführt habe, von Unternehmen gesponsert wurden, in denen es wirklich das Unternehmen war, das es vorantrieb, und die Datenarchitekten und Modellierer waren kein Teil der IT. Wir waren Teil einer von Unternehmen gesponserten Gruppe und wir waren dort als Moderatoren und arbeiteten mit den übrigen Projektteams zusammen.

Malcolm Chisholm: Ich denke, das ist ein sehr interessanter Punkt. Ich glaube, wir erleben eine Veränderung in der Geschäftswelt, in der das Unternehmen nachfragt oder vielleicht nicht so sehr denkt wie ich, sondern darüber nachdenkt, was die Daten sind Ich arbeite mit, was sind meine Datenbedürfnisse, mit welchen Daten beschäftige ich mich als Daten, und inwieweit können wir IDERA-Produkte und -Funktionen erhalten, um diese Sichtweise zu unterstützen, und ich denke, dass die Anforderungen des Geschäfts sogar erfüllt werden obwohl es ein bisschen noch im Entstehen ist.

Ron Huizenga: Ich stimme Ihnen zu und ich denke, wir werden es immer mehr so ​​sehen. Wir haben ein Erwachen gesehen, und Sie haben es früher in Bezug auf die Wichtigkeit von Daten angesprochen. Wir haben die Bedeutung von Daten frühzeitig in der IT oder in der Entwicklung von Datenbanken erkannt. Wie Sie sagen, sind wir dann in den gesamten Prozessmanagementzyklus eingetreten - und der Prozess ist extrem wichtig, verstehen Sie mich nicht falsch - aber jetzt ist was passiert ist, wenn das passiert ist, Daten Art Fokus verloren.

Und jetzt erkennen Unternehmen, dass Daten wirklich im Mittelpunkt stehen. Daten stellen alles dar, was wir in unserem Geschäft tun. Daher müssen wir sicherstellen, dass wir über genaue Daten verfügen und die richtigen Informationen finden, die wir für unsere Entscheidungen benötigen. Weil nicht alles aus einem definierten Prozess stammt. Einige der Informationen sind ein Nebenprodukt von anderen Dingen, und wir müssen immer noch in der Lage sein, sie zu finden, zu wissen, was sie bedeuten, und die Daten, die wir dort sehen, letztendlich in Wissen zu übersetzen, das wir verwenden können, um unsere Geschäfte besser voranzutreiben.

Malcolm Chisholm: Richtig, und jetzt ist ein weiterer Bereich, mit dem ich zu kämpfen habe, der Datenlebenszyklus. Wenn wir uns die Art der Datenlieferkette ansehen, die ein Unternehmen durchläuft, fangen wir damit an Datenerfassung oder Datenerfassung, bei denen es sich möglicherweise um die Dateneingabe handelt, bei denen es sich jedoch auch um eine Dateneingabe handelt, werden von einem Datenanbieter Daten von außerhalb des Unternehmens abgerufen.

Und dann gehen wir von der Datenerfassung zur Datenpflege, wo ich darüber nachdenke, diese Daten zu standardisieren und an Orte zu transportieren, an denen sie benötigt werden. Und dann Datennutzung, die tatsächlichen Punkte, an denen sich Daten befinden, werden Sie Wert aus den Daten ziehen.

Früher wurde das alles in einem individuellen Stil gemacht, aber heute könnte es sich beispielsweise um eine Analyseumgebung handeln, und danach um ein Archiv, einen Speicher, in dem wir die Daten ablegen, wenn wir sie nicht mehr benötigen brauche es und schließlich eine Art von Prozess zu reinigen. Wie fügt sich die Datenmodellierung in die Verwaltung dieses gesamten Datenlebenszyklus ein?

Ron Huizenga: Das ist eine sehr gute Frage, und eine Sache, über die ich heute überhaupt keine Zeit hatte, mich eingehend mit Einzelheiten zu befassen, ist, worüber wir wirklich zu sprechen beginnen, ist die Datenherkunft. Was wir also tatsächlich tun können, ist, dass wir eine Datenherkunftsfunktion in unseren Werkzeugen haben und, wie ich bereits sagte, einen Teil davon aus ETL-Werkzeugen extrahieren können. Sie können dies aber auch einfach durch Zeichnen der Herkunft abbilden. Für jedes dieser Datenmodelle oder Datenbanken, die wir erfasst und in Modelle integriert haben, können wir die Konstrukte aus diesem in unserem Datenherkunftsdiagramm referenzieren.

Wir können einen Datenfluss von der Quelle zum Ziel zeichnen und über den gesamten Lebenszyklus hinweg, wie diese Daten durch die verschiedenen Systeme übertragen werden und was Sie finden werden, lassen Sie uns die Mitarbeiter mitnehmen 'data - es ist einer meiner Favoriten, basierend auf einem Projekt, das ich vor Jahren gemacht habe. Ich arbeitete mit einer Organisation zusammen, die Mitarbeiterdaten in 30 verschiedenen Systemen hatte. Was wir letztendlich dort gemacht haben - und Rebecca hat die Folie mit den Datenlinien geöffnet -, ist eine ziemlich vereinfachte Folie mit den Datenlinien, aber wir konnten alle Datenstrukturen einbringen, sie im Diagramm referenzieren und dann haben wir können Sie sich tatsächlich ansehen, zwischen welchen Datenflüssen und wie diese verschiedenen Datenentitäten in einem Datenfluss miteinander verbunden sind. Und wir können auch darüber hinausgehen. Dies ist Teil eines Datenfluss- oder Herkunftsdiagramms, das wir hier sehen. Wenn Sie darüber hinaus gehen möchten, haben wir auch den Business Architect-Teil dieser Suite, und dort gilt das Gleiche.

Alle Datenstrukturen, die wir in der Datenmodellierungsumgebung erfasst haben, können im Geschäftsmodellierungstool referenziert werden, sodass Sie auch in Ihren Geschäftsmodelldiagrammen oder Geschäftsprozessdiagrammen auf einzelne Datenspeicher verweisen können, wenn Sie möchten In der Datenmodellierungsumgebung und während Sie sie in den Ordnern in Ihrem Geschäftsprozessmodell verwenden, können Sie sogar die CRUD für diese angeben und festlegen, wie diese Informationen entweder verbraucht oder produziert werden. Anschließend können wir mit der Generierung beginnen Dinge wie Auswirkungs- und Analyseberichte und Diagramme daraus.

Was wir erreichen wollen und wir haben bereits viele Möglichkeiten, aber eines der Dinge, die wir als eine Art Torpfosten betrachten, während wir unsere Werkzeuge weiterentwickeln, ist in der Lage, diese durchgängige, organisatorische Datenherkunft und den gesamten Lebenszyklus von Daten abzubilden.

Malcolm Chisholm: Okay. Rebecca, darf ich noch eine?

Rebecca Jozwiak: Ich erlaube Ihnen noch einen, Malcolm, machen Sie weiter.

Malcolm Chisholm: Vielen Dank. Wie bringen wir diese beiden Gruppen dazu, effektiv zusammenzuarbeiten und sich gegenseitig zu verstehen, wenn wir über Data Governance und Datenmodellierung nachdenken?

Eric Little: Nun, es ist interessant, ich denke, es hängt wirklich von der Organisation ab, und es geht auf mein früheres Konzept zurück: In den Organisationen, in denen die Initiativen vom Geschäft getrieben wurden, waren wir direkt eingebunden. Zum Beispiel leitete ich eine Datenarchitektur Wir waren jedoch eng mit den Geschäftsbenutzern verbunden und halfen ihnen tatsächlich dabei, ihr Data Governance-Programm zu verbessern. Auch hier handelt es sich eher um einen beratenden Ansatz, es handelt sich jedoch eher um eine Geschäftsfunktion.

Was Sie wirklich brauchen, um in der Lage zu sein, ist, dass Sie Datenmodellierer und Architekten benötigen, die das Geschäft wirklich verstehen, sich auf die Geschäftsbenutzer beziehen und ihnen dann dabei geholfen haben, die damit verbundenen Governance-Prozesse zu bewältigen. Das Unternehmen möchte es tun, aber im Allgemeinen verfügen wir über das technologische Wissen, um diese Art von Programmen hervorzuheben. Es muss wirklich eine Zusammenarbeit sein, aber es muss im Besitz des Unternehmens sein.

Malcolm Chisholm: Okay, das ist großartig. Vielen Dank.

Dr. Eric Little: Okay.

Rebecca Jozwiak: Okay, vielen Dank. Zuhörer, ich befürchte, wir haben Ihre Fragen nicht beantwortet, aber ich werde dafür sorgen, dass sie an den entsprechenden Gast weitergeleitet werden, den wir heute in der Leitung hatten. Ich möchte Eric, Malcolm und Ron vielmals dafür danken, dass sie heute unsere Gäste sind. Das war großartiges Zeug, Leute. Und wenn Ihnen der heutige IDERA-Webcast gefallen hat, wird IDERA am kommenden Mittwoch auch bei einem Hot Technologies-Event dabei sein, bei dem Sie über die Herausforderungen der Indizierung und Orakel, also ein weiteres faszinierendes Thema, diskutieren.

Vielen Dank, Leute, passt auf euch auf, und wir sehen uns beim nächsten Mal. Tschüss.