À emporter: L’animatrice Rebecca Jozwiak discute des solutions d’architecture des données avec Eric Little d’OSTHUS, Malcolm Chisholm de First San Francisco Partners et Ron Huizenga d’IDERA.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Rebecca Jozwiak: Mesdames et Messieurs, bonjour et bienvenue à Hot Technologies en 2016. Nous discutons aujourd’hui de la «Construction d’une architecture de données axée sur les activités», un sujet d’actualité. Je m'appelle Rebecca Jozwiak, je serai votre hôte pour la diffusion Web d’aujourd’hui. Nous tweetons avec un hashtag # # HotTech16, donc si vous êtes déjà inscrit, n'hésitez pas à participer également. Si vous avez des questions à un moment quelconque, veuillez les insérer dans le volet Q & R en bas à droite de votre écran et nous veillerons à obtenir une réponse. Sinon, nous veillerons à ce que nos invités les reçoivent pour vous.
Nous avons donc aujourd’hui une gamme vraiment fascinante. Beaucoup de gros frappeurs sont avec nous aujourd'hui. Nous avons Eric Little, vice-président de la science des données chez OSTHUS. Nous avons Malcolm Chisholm, directeur de l'innovation, qui est un titre vraiment cool, pour First San Francisco Partners. Et nous avons Ron Huizenga, chef de produit senior chez IDERA. Et, vous savez, IDERA propose une suite vraiment complète de solutions de gestion de données et de modélisation. Et aujourd’hui, il nous présentera une démonstration du fonctionnement de sa solution. Mais avant d’y arriver, Eric Little, je vais vous passer le ballon.
Eric Little: Ok, merci beaucoup. Je vais donc passer en revue quelques sujets ici qui, je pense, vont relier un peu le discours de Ron et, espérons-le, préparer le terrain pour certains de ces sujets également, des questions-réponses.
C’est pourquoi ce qui m’intéresse avec ce que fait IDERA, c’est que je pense qu’ils soulignent à juste titre que les environnements complexes sont réellement le moteur de nombreuses valeurs commerciales de nos jours. Et par environnements complexes, nous entendons des environnements de données complexes. Et la technologie évolue vraiment rapidement et il est difficile de rester dans le contexte commercial actuel. Ainsi, les personnes qui travaillent dans les espaces technologiques verront souvent que vous avez des clients qui ont des problèmes avec, «Comment utiliser le Big Data? Comment incorporer la sémantique? Comment lier certaines de ces nouvelles données à mes anciennes données? ", Etc., et cela nous mène aujourd'hui à ces quatre sources de données volumineuses que beaucoup de gens connaissent bien, et je sais qu'il peut y en avoir plus de quatre parfois - j'en ai vu jusqu'à huit ou neuf -, mais normalement, lorsque les gens parlent de choses comme le big data ou si vous parlez de big data, vous envisagez généralement une activité à l'échelle de l'entreprise. Et ainsi, les gens vont dire: bon, eh bien, pensez au volume de vos données, ce qui est normalement l’objectif - c’est tout ce que vous avez. La rapidité des données dépend de la rapidité avec laquelle je peux les déplacer ou de la rapidité avec laquelle je peux les interroger ou obtenir les réponses, etc. Et personnellement, je pense que le côté gauche est quelque chose qui est résolu et traité assez rapidement par beaucoup d’approches différentes. Mais du côté droit, je vois beaucoup de possibilités d’amélioration et beaucoup de nouvelles technologies qui apparaissent vraiment au premier plan. Et cela a vraiment à voir avec la troisième colonne, la variété de données.
En d'autres termes, la plupart des entreprises s'intéressent aujourd'hui aux données structurées, semi-structurées et non structurées. Les données d'images commencent à devenir un sujet brûlant. Vous pouvez donc utiliser la vision par ordinateur, regarder les pixels, être capable de gratter, de décomposer la PNL, d'extraire des entités. Vous avez ainsi des informations graphiques issues de modèles statistiques ou de modèles sémantiques. , vous avez des données relationnelles existantes dans les tables, etc. Tirer ensemble toutes ces données et ces différents types représente donc un défi de taille et vous le constaterez, vous le savez, chez Gartner et chez d’autres personnes qui suivent en quelque sorte les tendances du secteur.
Et puis la dernière chose dont parlent les gens dans le Big Data est souvent cette notion de voracité, qui est vraiment l’incertitude de vos données, leur flou. Dans quelle mesure connaissez-vous le contenu de vos données, comprenez-vous bien ce qu’il contient et, vous savez? La possibilité d’utiliser des statistiques et d’utiliser certaines informations autour de ce que vous savez peut-être ou d’utiliser certains inconvénients peut être très utile. Vous avez ainsi la possibilité d’analyser vos données de la manière dont vous les possédez, à quelle vitesse vous devez les déplacer ou les utiliser, tous les types de données que vous pouvez avoir dans votre entreprise et votre degré de certitude. c'est ce que c'est, en quelle qualité il est, etc. Cela nécessite réellement un effort important et coordonné entre plusieurs personnes pour gérer efficacement leurs données. La modélisation des données revêt donc une importance croissante dans le monde d’aujourd’hui. Donc, de bons modèles de données génèrent beaucoup de succès dans les applications d'entreprise.
Vous avez des sources de données provenant de sources variées, comme nous le disions, qui nécessitent en réalité de nombreux types d'intégration. Il est donc très utile de tout rassembler pour pouvoir exécuter des requêtes, par exemple, sur de nombreux types de sources de données, et extraire des informations. Mais pour ce faire, vous avez besoin de bonnes stratégies de cartographie. La cartographie de ce type de données et le suivi de ces mappages peuvent constituer un véritable défi. Et puis vous avez ce problème de, bien comment puis-je lier mes données héritées à toutes ces nouvelles sources de données? Alors supposons que j’ai un graphique, est-ce que je prends toutes mes données relationnelles et les met dans un graphique? Ce n’est généralement pas une bonne idée. Alors, comment se fait-il que les gens soient capables de gérer tous ces types de modèles de données en cours? L'analyse doit en réalité être effectuée sur bon nombre de ces types de sources de données et de combinaisons. Les réponses qui en découlent, les réponses dont les gens ont besoin pour prendre de bonnes décisions commerciales sont donc essentielles.
Donc, il ne s’agit pas seulement de construire de la technologie pour le bien de la technologie, c’est vraiment ce que je vais faire, que puis-je faire avec elle, quel type d’analyse puis-je exécuter et la capacité, donc, comme je l’ai déjà fait? parler, rassembler, intégrer, est vraiment, vraiment important. Et l’un de ces types d’analyses s’appuie ensuite sur des éléments tels que la recherche et la requête fédérées. Cela devient vraiment un must. Vos requêtes doivent normalement être liées à plusieurs types de sources et extraire des informations de manière fiable.
L’un des éléments clés que souvent, en particulier les gens vont se pencher sur des éléments clés tels que les technologies sémantiques - et c’est quelque chose dont j’espère que Ron parlera un peu dans l’approche IDERA - est de savoir comment séparer ou gérer les couche modèle de vos données à partir de la couche de données elle-même, à partir de ces données brutes? Donc, au niveau de la couche de données, vous pouvez avoir des bases de données, des données de document, des données de tableur, des données d’image. Si vous travaillez dans des domaines tels que l’industrie pharmaceutique, vous disposez d’une grande quantité de données scientifiques. Et en plus de cela, les gens recherchent normalement un moyen de créer un modèle leur permettant d’intégrer rapidement ces données. En réalité, lorsque vous recherchez des données, vous ne cherchez pas à extraire toutes ces données dans votre couche modèle. Ce que vous cherchez à faire est de vous donner une belle représentation logique de ce qu’est la chose, des vocabulaires communs, des types communs d’entités et de relations et la possibilité d’atteindre réellement les données où elles se trouvent. Donc, il doit dire ce que c'est, et il doit dire où il se trouve, et il doit dire comment aller le chercher et le ramener.
C'est donc une approche qui a très bien réussi à faire progresser les technologies sémantiques, domaine dans lequel je travaille beaucoup. Donc, une question que je voulais poser à Ron, et que je pense être utile dans la section Q & R, est de voir comment cela est accompli par la plateforme IDERA. La couche de modèle est-elle donc réellement séparée de la couche de données? Sont-ils plus intégrés? Comment cela fonctionne-t-il et quels sont les résultats et les avantages qu’ils voient dans leur approche? Par conséquent, les données de référence deviennent vraiment critiques. Ainsi, si vous avez ce type de modèle de données, si vous voulez pouvoir effectuer une fédération et effectuer des recherches dans différents domaines, vous devez disposer de bonnes données de référence. Mais le problème est que les données de référence peuvent être très difficiles à conserver. Ainsi, souvent, la définition de normes en soi constitue un défi difficile. Un groupe appelle quelque chose X et un groupe appelle quelque chose Y et vous avez maintenant le problème de savoir comment trouver X et Y quand ils cherchent ce type d’information. Parce que vous ne voulez pas simplement leur donner une partie des données, vous voulez tout leur donner. En même temps que les conditions changent, les logiciels deviennent obsolètes, etc., comment maintenez-vous ces données de référence au fil du temps?
Et, encore une fois, les technologies sémantiques, utilisant notamment des taxonomies et des vocabulaires, des dictionnaires de données, ont fourni un moyen standard de le faire dans l’espace, très robuste, utilisant certains types de normes, mais la communauté des bases de données l’a déjà fait. longtemps aussi, mais de différentes manières. Je pense que l’une des clés est de réfléchir à la manière d’utiliser des modèles de relation d’entité, des modèles de graphes ou une approche qui vous donnera vraiment une manière espérée de traiter vos données de référence. Et bien sûr, une fois que vous avez les données de référence, les stratégies de mappage doivent gérer une grande variété de noms et d'entités. Les experts en la matière aiment donc souvent utiliser leurs propres termes.
Il est donc toujours difficile, dans ce contexte, de donner des informations à quelqu'un et de le rendre pertinent par rapport à la manière dont il en parle. Ainsi, un groupe peut avoir une façon de voir les choses, par exemple, vous pouvez être un chimiste travaillant sur un médicament, un biologiste structural travaillant sur le même médicament, et vous pouvez avoir des noms différents pour les mêmes types d'entités. qui se rapportent à votre domaine. Vous devez trouver des moyens de rassembler ces terminologies personnalisées, car l’autre approche consiste à obliger les gens à abandonner leur mandat et à utiliser le tarif de quelqu'un d’autre, ce qu’ils n’apprécient souvent pas. Il est également difficile de gérer un grand nombre de synonymes. Il existe donc de nombreux mots différents dans les données de nombreuses personnes pouvant faire référence à la même chose. Vous avez un problème de référence en utilisant un ensemble de relations plusieurs-à-un. Les termes spécialisés varient d’un secteur à l’autre. Par conséquent, si vous envisagez de mettre en place une solution globale pour ce type de gestion des données, pouvez-vous le transférer facilement d’un projet ou d’une application à l’autre? Cela peut être un autre défi.
L’automatisation est importante et c’est aussi un défi. Il est coûteux de gérer manuellement les données de référence. Il est coûteux de garder la cartographie manuelle et de faire cesser les travaux quotidiens des experts en la matière et de les obliger à modifier en permanence les dictionnaires de données, à mettre à jour les définitions, etc. Les vocabulaires réplicables montrent vraiment beaucoup de valeur. Ce sont donc souvent des vocabulaires que vous pouvez trouver à l’extérieur de votre organisation. Si vous travaillez dans le pétrole brut, par exemple, il existe certains types de vocabulaires que vous pouvez emprunter dans des espaces à source ouverte, comme les produits pharmaceutiques, les mêmes avec le secteur bancaire et financier, les mêmes avec beaucoup de ces types de domaines. Les gens utilisent des vocabulaires réutilisables, génériques et reproductibles.
Et, encore une fois, en regardant l'outil IDERA, je suis curieux de voir comment ils gèrent cela en termes d'utilisation de types de normes. Dans le monde de la sémantique, vous voyez souvent des choses comme les modèles SKOS qui fournissent des normes au moins plus larges que les relations et ces choses peuvent être difficiles à faire dans les modèles ER mais vous savez, ce n'est pas impossible, cela dépend machines et ce lien que vous pouvez manipuler dans ces types de systèmes.
Enfin, je voulais juste faire une sorte de comparaison avec certains moteurs sémantiques que je vois dans l’industrie, et demander à Ron et lui demander un peu de motivation pour peut-être expliquer comment le système IDERA a été utilisé conjointement avec toutes les technologies sémantiques.Est-il capable d'être intégré avec des magasins triples, des bases de données graphiques? Est-il facile d'utiliser des sources externes car ce type de choses dans le monde sémantique peut souvent être emprunté à l'aide de points d'extrémité SPARQL? Vous pouvez importer des modèles RDF ou OWL directement dans votre modèle - vous y renvoyer - afin, par exemple, l'ontologie des gènes ou l'ontologie des protéines, qui peuvent vivre quelque part dans son propre espace avec sa propre structure de gouvernance et je peux simplement importer tout ou partie. une partie de cela car j'en ai besoin dans mes propres modèles. Et je suis curieux de savoir comment IDERA aborde ce problème. Devez-vous tout conserver en interne ou existe-t-il des solutions pour utiliser d'autres types de modèles standardisés et les intégrer, et comment cela fonctionne-t-il? Et la dernière chose que j'ai mentionnée ici est combien de travail manuel est réellement impliqué pour construire les glossaires et les référentiels de métadonnées?
Je sais donc que Ron va nous montrer des démos sur ce genre de choses qui seront vraiment intéressantes. Mais le problème que je vois souvent consulter les clients, c’est que beaucoup d’erreurs se produisent lorsque des personnes écrivent dans leurs propres définitions ou leurs propres métadonnées. Donc, vous obtenez des fautes d’orthographe, des erreurs du doigt fatal, c’est une chose. Vous obtenez également des personnes qui peuvent prendre quelque chose, vous savez, juste Wikipédia ou une source qui n'est pas nécessairement de la qualité que vous souhaitez dans votre définition, ou votre définition n'est que du point de vue d'une personne, donc elle n'est pas complète et elle n'est pas claire ensuite. comment fonctionne le processus de gouvernance. La gouvernance, bien sûr, est un très gros problème chaque fois que vous parlez de données de référence et chaque fois que vous parlez de la manière dont cela peut s’intégrer aux données de base d’une personne, de la manière dont il va utiliser ses métadonnées et bientôt.
Donc, je voulais juste mettre certains de ces sujets sur le marché. Ce sont des éléments que je vois dans l'espace métier à travers de nombreux types de missions de conseil et beaucoup d'espaces différents, et je suis vraiment intéressé de voir ce que Ron va nous montrer avec IDERA pour souligner certains de ces sujets. . Alors merci beaucoup.
Rebecca Jozwiak: Merci beaucoup, Eric, et j'apprécie beaucoup votre commentaire, selon lequel de nombreuses erreurs peuvent survenir si les personnes écrivent leurs propres définitions ou métadonnées. Je sais que, dans le monde du journalisme, «beaucoup de personnes commettent peu d’erreurs», mais quand il s’agit d’applications pratiques, trop de mains dans la jarre à biscuits ont tendance à vous laisser avec beaucoup de cookies cassés, non?
Eric Little: Oui, et des germes.
Rebecca Jozwiak: Ouais. Cela dit, je vais laisser la parole à Malcolm Chisholm. Malcolm, la parole est à vous.
Malcolm Chisholm: Merci beaucoup, Rebecca. J'aimerais revenir un peu sur ce qu'Eric a dit et ajouter quelques remarques auxquelles, vous savez, Ron voudra peut-être répondre également en parlant de «Vers une architecture de données pilotée par l'entreprise». ”- Qu'est-ce que cela signifie d'être axé sur les affaires et pourquoi est-ce important? Ou est-ce juste une forme de battage médiatique? Je ne pense pas que ce soit le cas.
Si vous regardez ce qui s’est passé depuis, vous savez, les ordinateurs centraux sont vraiment devenus disponibles pour les entreprises - disons vers 1964 - jusqu’à aujourd’hui, nous pouvons constater qu’il ya eu beaucoup de changements. Et ces changements, je résumerais comme étant un passage de la centralisation des processus à la centralisation des données. Et c’est ce qui rend les architectures de données centrées sur les entreprises si importantes et pertinentes aujourd’hui. Et je pense, vous savez, ce n’est pas seulement un mot à la mode, c’est quelque chose qui est tout à fait réel.
Mais nous pouvons l’apprécier un peu plus si nous plongeons dans l’histoire. Revenons donc dans le temps, dans les années 1960 et ensuite, les ordinateurs centraux ont dominé. Celles-ci ont ensuite cédé la place à des ordinateurs personnels où les utilisateurs étaient en rébellion. Des mouvements rébellion contre l’informatique centralisée, qui, à leur avis, ne répondaient pas à leurs besoins, n’étaient pas assez agiles. Cela a rapidement donné naissance à l'informatique distribuée, lorsque les ordinateurs personnels étaient reliés entre eux. Et puis, Internet a commencé à arriver, ce qui a brouillé les frontières de l'entreprise: il pouvait désormais interagir avec des tiers en dehors de l'échange d'informations, ce qui n'était pas le cas auparavant. Et maintenant, nous sommes entrés dans l'ère du cloud et des mégadonnées où le cloud est une plate-forme qui banalise réellement l'infrastructure et nous laissons donc, pour ainsi dire, l'informatique de la nécessité de gérer de grands centres de données car, vous savez, Nous avons la capacité de cloud disponible, et concomitante de ces données volumineuses dont Eric a, vous le savez, discuté avec éloquence. Et globalement, comme nous le voyons, avec le changement de technologie, la technologie est devenue plus centrée sur les données, nous nous soucions davantage des données. Comme avec Internet, comment les données sont échangées. Avec le Big Data, les quatre v ou plus des données elles-mêmes.
Dans le même temps, et peut-être plus important encore, les cas d'utilisation professionnelle ont été modifiés. Lorsque les ordinateurs ont été introduits pour la première fois, ils étaient utilisés pour automatiser des tâches telles que les livres et les disques. Et tout ce qui était un processus manuel, qui impliquait des grands livres ou des choses comme ça, était programmé, essentiellement, en interne. Cela a changé dans les années 80 à la disponibilité de paquets opérationnels. Vous n’avez plus besoin d’écrire votre propre liste de paie, vous pouvez acheter quelque chose qui l’a fait. Cela a entraîné une importante réduction des effectifs à l'époque, ou une restructuration, dans de nombreux départements informatiques. Mais ensuite, la business intelligence, avec des choses comme les data warehouses, est apparue, principalement dans les années 90. Suivi par les modèles d’affaires de dotcom qui étaient, bien sûr, une grande frénésie. Puis MDM. Avec MDM, vous commencez à comprendre que nous ne pensons pas à l’automatisation; nous nous concentrons simplement sur la conservation des données en tant que données. Et ensuite, l'analyse, représentant la valeur que vous pouvez obtenir des données. Et dans le domaine de l’analyse, vous voyez des entreprises très performantes dont le modèle commercial central s’articule autour des données. Google, en ferait partie, mais vous pourriez également affirmer que Walmart l’est.
Et l’entreprise réfléchit désormais vraiment aux données. Comment pouvons-nous tirer parti des données? Comment les données peuvent conduire l'entreprise, la stratégie et nous sommes à l'âge d'or des données. Dans ce contexte, qu’en est-il de l’architecture de nos données, si les données ne sont plus considérées comme l’échappement des applications finales, mais au cœur de nos modèles commerciaux? L’informatique est en partie liée au cycle de vie du développement des systèmes, conséquence du fait qu’il a fallu gérer rapidement cette phase d’automatisation des processus dès le début de l’informatique et travailler projets est une chose similaire. Pour l'informatique - et c'est un peu une caricature - mais ce que j'essaie de dire, c'est que certains des obstacles à la création d'une architecture de données orientée métier proviennent du fait que nous avons en quelque sorte accepté une culture de l'informatique sans esprit critique. qui dérive d'un âge révolu.
Donc tout est projet. Dites-moi vos exigences en détail. Si les choses ne fonctionnent pas, c’est parce que vous ne me dites pas vos besoins. Cela ne fonctionne pas aujourd'hui avec les données, car nous ne commençons pas par des processus manuels non automatisés ou une conversion technique des processus métiers, vous savez, nous commençons très souvent avec des données de production existantes que nous essayons pour obtenir de la valeur. Mais personne qui sponsorise un projet centré sur les données ne comprend réellement ces données en profondeur. Nous devons faire la découverte des données, nous devons faire l'analyse des données sources. Et cela ne correspond pas vraiment au développement de systèmes, vous savez - le cycle de vie des chutes d’eau, SDLC -, dont Agile, j’aimerais dire, est une sorte de meilleure version de cela.
Et ce sur quoi nous nous concentrons est la technologie et la fonctionnalité, pas les données. Par exemple, lorsque nous effectuons des tests au cours d’une phase de test, c’est généralement ma fonctionnalité qui fonctionne, disons mon ETL, mais nous ne testons pas les données. Nous ne testons pas nos hypothèses sur les données source entrantes. Si nous le faisions, nous serions peut-être en meilleure forme et, en tant que personne ayant réalisé des projets d’entrepôts de données et ayant subi des changements en amont, détruisant mes ETL, je l’apprécierais. Et en fait, ce que nous souhaitons, c’est que les tests constituent une étape préliminaire de la surveillance continue de la qualité des données de production. Nous avons donc ici beaucoup d’attitudes où il est difficile d’atteindre l’architecture de données pilotée par l’entreprise, car nous sommes conditionnés par l’ère de la centralisation des processus. Nous devons passer à la centralisation des données. Et ce n’est pas une transition totale, vous savez, il reste encore beaucoup de travail à faire, mais nous ne pensons pas vraiment en termes de données lorsque c’est nécessaire, et dans les circonstances obligé de le faire.
Maintenant que l'entreprise comprend la valeur des données, elle souhaite les déverrouiller. Comment allons-nous procéder? Alors, comment faisons-nous la transition? Nous plaçons les données au cœur des processus de développement. Et nous laissons l'entreprise diriger les besoins en informations. Et nous comprenons que personne ne comprend les données sources existantes au début du projet. Vous pourriez soutenir que la structure de données et les données elles-mêmes y sont parvenues respectivement par le biais de l’informatique et des opérations; nous devrions donc le savoir, mais ce n’est vraiment pas le cas. C'est un développement centré sur les données. Nous devons donc savoir où et comment procéder à la modélisation des données dans un monde centré sur les données. Nous devons fournir aux utilisateurs des boucles de rétroaction pour affiner leurs besoins en informations, tout comme la découverte et le profilage des données. , prévoyez l’analyse des données source et, au fur et à mesure que nous obtenons de plus en plus de certitude sur nos données. Et maintenant, je parle d’un projet plus traditionnel comme un hub MDM ou un entrepôt de données, mais pas nécessairement les projets Big Data, même si c’est quand même, je maintiens, assez proche de cela. Et ces boucles de rétroaction incluent les modélisateurs de données, vous savez, progressant progressivement dans leur modèle de données et interagissant avec les utilisateurs pour s'assurer que les exigences en matière d'informations sont affinées en fonction des possibilités, des disponibilités et des données source à mesure qu'elles le comprennent, ce n'est plus le cas si le modèle de données est, vous savez, dans un état qui n'existe pas ou est complètement terminé, c'est une mise au point progressive.
De même, plus en aval, nous avons une assurance qualité dans laquelle nous élaborons des règles pour le test de la qualité des données afin de nous assurer que les données respectent les paramètres sur lesquels nous nous fondons. En entrant, Eric faisait référence aux changements dans les données de référence, ce qui peut arriver. Vous ne voulez pas être comme une victime en aval de tout changement non géré dans ce domaine, afin que les règles d’assurance qualité puissent être intégrées dans le contrôle continu de la qualité des données après la production. Vous pouvez donc commencer à voir si nous allons être centrés sur les données. La manière dont nous développons le développement est très différente de SDLC et Agile basés sur les fonctionnalités. Nous devons également tenir compte des points de vue des entreprises. Nous avons - et cela correspond encore à ce qu'Eric disait - nous avons un modèle de données définissant un récit de données bleu pour notre base de données, mais en même temps nous avons besoin de ces modèles conceptuels, de ces vues commerciales de données qui étaient traditionnellement inédites. le passé. Je pense que parfois, je pense, le modèle de données peut tout faire, mais nous devons avoir la vue conceptuelle, la sémantique, et examiner les données, les restituer à travers une couche d'abstraction qui traduit le modèle de stockage dans l'entreprise. vue. Et, encore une fois, toutes les choses dont Eric parlait en termes de sémantique deviennent importantes, alors nous avons en fait des tâches de modélisation supplémentaires. Je pense que c’est intéressant, vous savez, si vous montez dans les rangs en tant que modélisateur de données comme moi, et encore une fois, quelque chose de nouveau.
Enfin, j’aimerais dire que l’architecture plus large doit également refléter cette nouvelle réalité. Le MDM client traditionnel, par exemple, permet de placer nos données client dans un centre où nous pourrons, vous le savez, comprendre la qualité des données pour les applications de back-office. Ce qui du point de vue de la stratégie commerciale est une sorte de bâillement. Aujourd'hui, cependant, nous examinons les hubs MDM clients qui contiennent des données de profil client supplémentaires, pas seulement les données statiques, qui disposent alors d'une interface bidirectionnelle avec les applications de transaction du client. Oui, ils supportent toujours le back-office, mais nous connaissons également ces comportements de nos clients. C'est plus cher à construire. C'est plus complexe à construire. Mais il s’agit d’une stratégie commerciale qui n’est pas celle du client traditionnel MDM. Vous négociez une orientation de l'entreprise contre des conceptions plus simples et plus faciles à mettre en œuvre, mais pour l'entreprise, c'est ce qu'ils veulent voir. Nous sommes vraiment dans une nouvelle ère et je pense que nous devons répondre à plusieurs niveaux à l’architecture de données qui régit les affaires et je pense que c’est une période très excitante pour faire des choses.
Donc, merci à vous, Rebecca.
Rebecca Jozwiak: Merci Malcolm, et j'ai vraiment apprécié ce que vous avez dit sur les modèles de données doit nourrir la vision métier, parce que, contrairement à ce que vous disiez, l'informatique a tenu les rênes pendant si longtemps et que ce n'est plus le cas aujourd'hui et que la culture a besoin de changer. Et je suis presque sûr qu’il y avait un chien à l’arrière-plan qui était à 100% d’accord avec vous. Et avec ça, je vais passer le ballon à Ron. Je suis vraiment excité de voir votre démo. Ron, la parole est à vous.
Ron Huizenga: Merci beaucoup et avant de passer à cela, je vais passer en revue quelques diapositives, puis un peu de démonstration car, comme Eric et Malcolm l’ont souligné, il s’agit d’un sujet très vaste et approfondi. «Nous parlons d’aujourd’hui, nous ne faisons qu’effleurer la surface car il y a tant d’aspects et de choses qu’il faut vraiment prendre en compte et considérer à partir d’une architecture orientée métier. Et notre approche consiste à réellement utiliser ce modèle et à en tirer une valeur réelle, car vous pouvez les utiliser à la fois comme moyen de communication et comme couche pour activer d'autres systèmes. Que vous utilisiez une architecture orientée services ou autre chose, le modèle devient vraiment le moteur de ce qui se passe, avec toutes les métadonnées qui l’entourent et les données que vous possédez dans votre entreprise.
Ce dont je veux parler, cependant, c'est presque faire un pas en arrière, parce que Malcolm a évoqué une partie de l’histoire de la façon dont les solutions ont évolué et ce genre de chose. Une façon de vraiment souligner à quel point il est important de disposer d'une architecture de données solide est un cas d'utilisation que je rencontrais très souvent lorsque je consultais avant d'entrer dans un rôle de gestion de produit. J'allais dans les organisations. qu'ils fassent de la transformation opérationnelle ou qu'ils remplacent simplement certains systèmes existants, etc., on s'aperçut très vite à quel point les organisations comprenaient mal leurs propres données. Si vous prenez un cas d'utilisation particulier comme celui-ci, que vous soyez un consultant ou une personne qui vient de commencer avec une organisation, ou que votre organisation s'est construite au fil des ans avec l'acquisition de différentes entreprises, vous vous retrouverez up est un environnement très complexe très rapidement, avec un certain nombre de nouvelles technologies différentes, ainsi que la technologie existante, les solutions ERP et tout le reste.
L’une des choses que nous pouvons vraiment faire avec notre approche de modélisation consiste à répondre à la question suivante: comment puis-je donner un sens à tout cela? Nous pouvons vraiment commencer à rassembler les informations afin que l’entreprise puisse exploiter correctement les informations dont elle dispose. Et il s’agit de savoir ce que nous avons dans ces environnements? Comment puis-je utiliser les modèles pour éliminer les informations dont j'ai besoin et mieux les comprendre? Nous avons ensuite les types traditionnels de métadonnées pour tous les éléments, tels que les modèles de données relationnels, et nous sommes habitués à voir des définitions et des dictionnaires de données, vous savez, des types de données, etc. Mais qu’en est-il des métadonnées supplémentaires que vous souhaitez capturer pour leur donner encore plus de sens? Tels que, quelles entités sont vraiment les candidats qui devraient être des objets de données de référence, qui devraient être des objets de gestion de données de base et ces types d'objets et les lier entre eux. Et comment l'information circule-t-elle dans l'organisation? Les données découlent de la manière dont elles sont consommées, tant du point de vue du processus que de la lignée de données, en termes de parcours de l’information au sein de nos activités et de la façon dont elles se frayent un chemin à travers les différents systèmes, ou dans les magasins de données. lorsque nous construisons les solutions I, ou ce genre de choses, nous consommons en fait les informations correctes pour la tâche à accomplir.
Et puis, il est très important de savoir comment pouvons-nous amener toutes ces parties prenantes à collaborer, et en particulier les parties prenantes du monde des affaires, car ce sont elles qui nous donnent la véritable signification de la nature de ces données. L’entreprise, en fin de compte, est propriétaire des données. Ils fournissent les définitions des vocabulaires et des choses dont Eric parlait. Il nous faut donc un endroit pour relier tout cela. Et nous le faisons grâce à nos architectures de modélisation et de référentiel de données.
Je vais aborder quelques points. Je vais parler de ER / Studio Enterprise Team Edition. Je vais principalement parler du produit d’architecture de données dans lequel nous effectuons la modélisation des données et ce genre de choses, mais il y a beaucoup d’autres composants de la suite que je vais aborder très brièvement. Vous verrez un extrait de l’architecte commercial, dans lequel nous pouvons créer des modèles conceptuels, mais nous pouvons également créer des modèles de processus métier et nous pouvons les lier pour lier les données réelles que nous avons dans nos modèles de données. Cela nous aide vraiment à rapprocher ce lien. L'architecte logiciel nous permet de faire des constructions supplémentaires telles que la modélisation UML et ce genre de choses pour donner des logiques de support à certains des autres systèmes et processus dont nous parlons. Mais très important, à mesure que nous descendons, nous avons le référentiel et le serveur d’équipe, et je parlerai de cela comme une sorte de deux moitiés de la même chose. Le référentiel est l'endroit où nous stockons toutes les métadonnées modélisées ainsi que toutes les métadonnées métier en termes de glossaires et de termes métier. Et comme nous avons cet environnement basé sur un référentiel, nous pouvons ensuite associer toutes ces choses différentes dans le même environnement et les rendre disponibles pour la consommation, non seulement pour les techniciens, mais également pour les hommes d'affaires. Et c’est ainsi que nous commençons vraiment à encourager la collaboration.
Enfin, le dernier élément dont je vais parler brièvement est que, lorsque vous entrez dans ces environnements, vous ne disposez pas uniquement de bases de données. Vous allez avoir un certain nombre de bases de données, de magasins de données, ainsi que de nombreux artefacts hérités, ce que j’appellerais. Les gens ont peut-être utilisé Visio ou d’autres diagrammes pour cartographier certaines choses. Peut-être qu’ils ont eu d’autres outils de modélisation et ce genre de choses.Donc, ce que nous pouvons faire avec MetaWizard, c'est d'extraire une partie de ces informations et de les intégrer dans nos modèles, de les actualiser et de pouvoir les utiliser, les consommer, de manière actuelle, plutôt que de les laisser simplement de côté. Il devient maintenant une partie active de nos modèles de travail, ce qui est très important.
Comme je l'ai dit, lorsque vous entrez dans une organisation, il existe de nombreux systèmes disparates, de nombreuses solutions ERP, des solutions ministérielles incompatibles. De nombreuses organisations utilisent également des solutions SaaS, qui sont également contrôlées et gérées de manière externe. Par conséquent, nous ne contrôlons pas les bases de données ni ce type d'éléments hébergés sur ces hôtes, mais nous avons toujours besoin de savoir à quoi ressemblent ces données et, bien sûr, les métadonnées autour de cela. Nous constatons également que de nombreux systèmes hérités obsolètes n’ont pas été nettoyés à cause de l’approche basée sur les projets dont Malcolm a parlé. C’est incroyable de voir comment, au cours des dernières années, les entreprises ont démarré des projets, elles vont remplacer un système ou une solution, mais il n’ya souvent pas assez de budget alloué au projet pour mettre hors service les solutions obsolètes. Elles sont donc maintenant gênantes. Et nous devons déterminer ce dont nous pouvons réellement nous débarrasser dans notre environnement, ainsi que ce qui est utile pour l’avenir. Et cela est lié à la stratégie de déclassement pour les pauvres. Cela fait partie intégrante de la même chose.
Ce que nous constatons également, du fait que beaucoup d’organisations ont été créées à partir de toutes ces solutions différentes, c’est que nous voyons beaucoup d’interfaces point à point avec beaucoup de données se déplaçant à divers endroits. Nous devons être en mesure de rationaliser cela et de comprendre la lignée de données que j'ai brièvement évoquée précédemment afin de pouvoir adopter une stratégie plus cohérente, telle que l'utilisation d'une architecture orientée services, de bus de services d'entreprise, etc., afin de fournir les informations correctes. type de modèle de publication et d’abonnement que nous utilisons correctement dans l’ensemble de nos activités. Et, bien sûr, nous devons encore procéder à une sorte d’analyse, que nous utilisions des entrepôts de données, des dépôts de données avec ETL traditionnel ou certains des nouveaux lacs de données. Tout se résume à la même chose. C’est l’ensemble des données, qu’il s’agisse de données volumineuses ou de données traditionnelles dans des bases de données relationnelles. Nous devons rassembler toutes ces données afin de pouvoir les gérer et savoir ce que nous traitons dans nos modèles.
Encore une fois, la complexité que nous allons faire est que nous voulons être en mesure de faire un certain nombre d’étapes. Tout d’abord, vous entrez et vous n’avez peut-être pas ce blues de ce à quoi ressemble ce paysage de l’information. Dans un outil de modélisation de données tel que ER / Studio Data Architect, vous allez d’abord faire beaucoup d’ingénierie inverse en indiquant les sources de données existantes, en les rassemblant puis en les assemblant de manière plus représentative. modèles qui représentent l'ensemble de l'entreprise. L’important, c’est que nous souhaitons pouvoir décomposer ces modèles également en fonction des secteurs d’activité, de manière à pouvoir les identifier en petits morceaux, ce à quoi nos hommes d’affaires peuvent également s’identifier, ainsi que nos analystes métier et autres parties prenantes qui travaillent actuellement. dessus.
Les normes de nommage sont extrêmement importantes et je vous en parle de différentes manières ici. Nommer les normes en termes de nommage des éléments dans nos modèles. C'est assez facile à faire dans les modèles logiques, où nous avons une bonne convention de nommage et un bon dictionnaire de données pour nos modèles, mais nous voyons aussi différentes conventions de nommage pour bon nombre de ces modèles physiques que nous importons. ingénierie inverse, nous voyons souvent des noms abrégés et ce genre de choses dont je vais parler. Nous devons également traduire ces noms en noms anglais significatifs, significatifs pour l’entreprise, afin de pouvoir comprendre toutes ces données contenues dans l’environnement. Et puis, les mappages universels sont la façon dont nous les assemblons.
En plus de cela, nous documenterions et définirions ensuite et c’est là que nous pourrons classer nos données plus en détail avec un élément appelé Pièces jointes, sur lequel je vous montrerai quelques diapositives. Et puis, bouclant la boucle, nous voulons appliquer ce sens commercial, c’est là que nous relions nos glossaires métiers et que nous pouvons les associer à nos différents artefacts de modèle. Nous savons donc que lorsque nous parlons d’un terme commercial donné, mis en œuvre dans nos données à travers l’organisation. Enfin, j’ai déjà évoqué le fait que tout cela doit être basé sur un référentiel doté de nombreuses capacités de collaboration et de publication afin que nos parties prenantes puissent l’utiliser. Je vais parler du reverse engineering assez rapidement. Je vous ai déjà donné un aperçu rapide de cela. Je vais vous montrer cela dans une démonstration réelle, simplement pour vous montrer certaines des choses que nous pouvons apporter ici.
Et je veux parler de certains types de modèles et de diagrammes que nous produirions dans ce type de scénario. Évidemment, nous ferons les modèles conceptuels dans de nombreux cas; Je ne vais pas passer beaucoup de temps là-dessus. Je veux vraiment parler de modèles logiques, de modèles physiques et des types spécialisés de modèles que nous pouvons créer. Et il est important que nous puissions tous les créer sur la même plate-forme de modélisation afin de pouvoir les assembler. Cela inclut des modèles dimensionnels ainsi que des modèles qui utilisent certaines des nouvelles sources de données, telles que le NoSQL que je vais vous montrer. Et ensuite, à quoi ressemble le modèle de lignage de données? Et comment allons-nous assembler ces données dans un modèle de processus métier, c’est ce dont nous parlerons ensuite.
Je vais passer ici à un environnement de modélisation pour vous donner un aperçu très détaillé et rapide. Et je crois que vous devriez être capable de voir mon écran maintenant. Tout d’abord, je veux parler d’un type de modèle de données traditionnel. Et la manière dont nous souhaitons organiser les modèles lorsque nous les importons est que nous voulons pouvoir les décomposer. Vous voyez donc à gauche que nous avons des modèles logiques et physiques dans ce fichier de modèle particulier. La prochaine chose à faire est que nous pouvons décomposer le travail en fonction de la décomposition de l’entreprise, c’est pourquoi vous voyez les dossiers. Les modèles bleu clair sont des modèles logiques et les modèles verts sont des modèles physiques. Et nous pouvons également faire un zoom avant. Ainsi, dans ER / Studio, si vous avez une décomposition métier, vous pouvez accéder à autant de niveaux de profondeur ou de sous-modèles que vous le souhaitez, et les modifications apportées aux niveaux les plus bas sont automatiquement répercutées aux niveaux les plus élevés. les niveaux. Cela devient donc très rapidement un environnement de modélisation très puissant.
Je tiens également à souligner qu’il est très important de commencer à rassembler ces informations: nous pouvons avoir plusieurs modèles physiques qui correspondent également à un modèle logique. Très souvent, vous pouvez avoir un modèle logique, mais vous pouvez avoir des modèles physiques sur différentes plates-formes et ce type de choses. Peut-être qu’une de ses instances est une instance SQL Server, peut-être une autre est-elle une instance Oracle. Nous pouvons relier tout cela dans le même environnement de modélisation. Et là encore, ce que j’ai trouvé ici est un modèle d’entrepôt de données réel qui peut, encore une fois, être dans le même environnement de modélisation ou être stocké dans le référentiel et le relier également à différents éléments.
Ce que je voulais vraiment vous montrer là-dessus, ce sont certaines des choses et autres variantes des modèles dans lesquels nous entrons. Ainsi, lorsque nous entrons dans un modèle de données traditionnel comme celui-ci, nous avons l'habitude de voir les entités typiques avec les colonnes, les métadonnées et ce genre de choses, mais ce point de vue varie très rapidement lorsque nous commençons à traiter certaines de ces nouvelles technologies NoSQL. , ou comme certaines personnes aiment encore les appeler, les technologies Big Data.
Maintenant, disons que nous avons également Hive dans notre environnement. Si nous procédons à l’ingénierie inverse à partir d’un environnement Hive - et que nous pouvons effectuer des opérations d’ingénierie directe et inverse à partir de Hive avec exactement le même outil de modélisation -, nous constatons un phénomène un peu différent. Nous voyons toujours toutes les données sous forme de constructions ici, mais notre TDL est différent. Ceux d’entre vous qui ont l'habitude de voir SQL, ce que vous verriez maintenant, c'est Hive QL, qui est très semblable à SQL mais sorti du même outil, vous pouvez maintenant commencer à travailler avec les différents langages de script. Vous pouvez donc modéliser dans cet environnement, le générer dans l'environnement Hive, mais il est tout aussi important de pouvoir, dans le scénario que je viens de décrire, procéder à une ingénierie inverse, donner un sens et commencer à l'assembler également. .
Prenons-en un autre légèrement différent. MongoDB est une autre plate-forme que nous soutenons de manière native. Et lorsque vous commencez à entrer dans les types d’environnements JSON dans lesquels vous avez des magasins de documents, JSON est un animal différent et il contient des constructions qui ne correspondent pas à des modèles relationnels. Vous commencez bientôt à traiter avec des concepts tels que les objets incorporés et les tableaux incorporés d’objets lorsque vous commencez à interroger le code JSON et ces concepts n’existent pas dans la notation relationnelle traditionnelle. Ce que nous avons fait ici, c’est que nous avons réellement étendu la notation et notre catalogue pour pouvoir gérer cela dans le même environnement.
Si vous regardez à gauche ici, au lieu de voir des choses comme des entités et des tables, nous les appelons des objets. Et vous voyez différentes notations. Vous voyez toujours les types typiques de notations de référence ici, mais ces entités bleues que je montre dans ce diagramme particulier sont en fait des objets incorporés. Et nous montrons différentes cardinalités. La cardinalité en losange signifie que c’est un objet à une extrémité, mais sa cardinalité signifie que nous avons, au sein de l’éditeur, si nous suivons cette relation, un objet d’adresse incorporé. Lors de l’interrogation du JSON, nous avons constaté que c’est exactement la même structure d’objets que celle intégrée dans le client, mais elle est en réalité intégrée dans un tableau d’objets. Nous voyons cela, non seulement à travers les connecteurs eux-mêmes, mais si vous regardez les entités réelles, vous verrez que vous voyez les adresses sous le nom de l'utilisateur, qui sont également classées comme un tableau d'objets. Vous obtenez un point de vue très descriptif sur la façon dont vous pouvez apporter cela.
Et encore une fois, ce que nous avons vu jusqu’à présent en quelques secondes, ce sont des modèles relationnels traditionnels à plusieurs niveaux. Nous pouvons faire la même chose avec Hive, nous pouvons faire la même chose avec MongoDB et d’autres sources de données volumineuses. bien. Ce que nous pouvons également faire, et je vais simplement vous le montrer très rapidement, c’est que j’ai parlé du fait d’apporter des produits de différents domaines. Je vais supposer que je vais importer un modèle depuis une base de données ou l’ingénierie inverse, mais je vais le faire venir à partir de métadonnées externes. Juste pour vous donner un aperçu très rapide de tous les types de choses que nous pouvons commencer à importer.
Comme vous le voyez, nous pouvons intégrer une multitude de choses aux métadonnées dans notre environnement de modélisation. À commencer par des choses comme Amazon Redshift, Cassandra, beaucoup d’autres plates-formes de données volumineuses, de sorte que vous voyez beaucoup d’entre elles. Ceci est dans l'ordre alphabétique. Nous voyons beaucoup de sources de données volumineuses et ce genre de choses. Nous observons également de nombreux environnements de modélisation traditionnels ou anciens dans lesquels nous pouvons réellement transférer ces métadonnées. Si je passe par ici - et je ne vais pas passer du temps sur chacune d’elles - nous verrons beaucoup de choses différentes à partir desquelles nous pouvons l’apporter, en termes de plates-formes de modélisation et de plates-formes de données. Et il est très important de comprendre ici que nous pouvons faire autre chose lorsque nous commençons à parler de lignage des données. Dans Enterprise Team Edition, nous pouvons également interroger les sources ETL, qu'il s'agisse de mappages Talend ou SQL Server Information Services. apportez-le pour commencer également nos diagrammes de lignage de données et pour brosser un tableau de ce qui se passe dans ces transformations. Globalement, nous avons plus de 130 ponts différents qui font en réalité partie du produit Enterprise Team Edition. Cela nous aide vraiment à rassembler très rapidement tous les artefacts dans un environnement de modélisation unique.
Dernier point, mais non le moindre, je veux également parler du fait que nous ne pouvons pas perdre de vue le fait que nous avons besoin des autres types de constructions si nous réalisons l’entreposage de données ou tout type d’analyse. Nous voulons toujours avoir la capacité de faire des choses comme des modèles dimensionnels avec des tables de faits et des dimensions et ce genre de choses. Une chose que je veux également vous montrer est que nous pouvons également avoir des extensions de nos métadonnées qui nous aident à classer quels types de dimensions sont utilisés et tout le reste. Donc, si je regarde l'onglet de données dimensionnelles ici, par exemple, sur l'un d'eux, il détectera automatiquement, en fonction du modèle de modèle qu'il voit, et vous donnera un point de départ pour savoir s'il pense qu'il s'agit d'une dimension ou d'une table de fait. Mais au-delà de cela, ce que nous pouvons faire, c'est dans les dimensions et ce type de choses, nous avons même différents types de dimensions que nous pouvons utiliser pour classer les données dans un type d'environnement d'entreposage de données. Des capacités tellement puissantes que nous cousons tout à fait.
Je vais sauter dans celui-ci puisque je suis dans l’environnement de démonstration pour le moment et vous montrer quelques autres choses avant de revenir aux diapositives. Une des choses que nous avons récemment ajoutées à ER / Studio Data Architect est que nous avons rencontré des situations - et il s’agit d’un cas d’utilisation très courant lorsque vous travaillez sur des projets - les développeurs pensent en termes d’objets, alors que nos données les modélisateurs ont tendance à penser en termes de tables et d'entités et ce genre de chose. Il s'agit d'un modèle de données très simpliste, mais il représente quelques concepts de base, dans lesquels les développeurs, voire les analystes métier ou les utilisateurs métier, pourraient les considérer comme des objets ou des concepts métier différents. Jusqu'à présent, il était très difficile de les classer, mais dans l'édition 2016 de ER / Studio Enterprise Team Edition, nous avons désormais un concept appelé Business Data Objects. Cela nous permet d'encapsuler des groupes d'entités ou des tables dans de véritables objets métier.
Par exemple, ce que nous avons ici sur cette nouvelle vue est que l'en-tête de la commande d'achat et la ligne de commande ont été rassemblés maintenant, ils sont encapsulés en tant qu'objet, nous les considérerions comme une unité de travail lorsque nous conservons les données. , et nous les réunissons donc il est maintenant très facile de relier cela à différents publics. Ils sont réutilisables dans l’environnement de modélisation. C’est un véritable objet, pas seulement une construction de dessin, mais nous avons également l’avantage supplémentaire que lorsque nous communiquons réellement depuis la perspective de la modélisation, nous pouvons les réduire ou les développer de manière sélective, afin de produire une vue résumée des dialogues avec certains publics de parties prenantes, et nous pouvons aussi, bien sûr, conserver la vue plus détaillée telle que celle que nous voyons ici pour un public plus technique. Cela nous donne vraiment un très bon moyen de communication. Nous voyons maintenant la combinaison de plusieurs types de modèles différents, en les augmentant avec le concept d’objets de données d’entreprise, et je vais maintenant parler de la manière dont nous appliquons plus de signification à ces types de choses et comment nous les associons dans notre environnement. environnements globaux.
J'essaie simplement de retrouver mon WebEx ici pour pouvoir le faire. Et voilà, revenons aux diapositives Hot Tech. Je vais simplement faire avancer rapidement quelques diapositives ici parce que vous les avez déjà vues dans la démonstration du modèle elle-même. Je veux parler très rapidement des normes de nommage. Nous voulons appliquer et appliquer différentes normes de nommage. Ce que nous voulons faire, c’est que nous avons la capacité de stocker des modèles de normes de nommage dans nos référentiels afin de construire ce sens à travers des mots ou des expressions ou même des abréviations, et de les rattacher à un type de mot anglais significatif. Nous allons utiliser les termes commerciaux, les abréviations pour chacun, et nous pouvons spécifier l’ordre, les cas et ajouter des préfixes et des suffixes. Le cas d'utilisation typique de cette situation est généralement lorsque les personnes ont été en train de créer un modèle logique, puis de créer un modèle physique où elles auraient peut-être utilisé des abréviations, etc.
La belle chose est qu’elle est tout aussi puissante, et même inversement. Si nous pouvons simplement indiquer quelles sont les normes de nommage de certaines de ces bases de données physiques que nous avons modifiées, nous pouvons prendre ces abréviations, les transformer en données plus longues. mots et ramenez-les en arrière dans les phrases anglaises. En fait, nous pouvons maintenant obtenir des noms propres pour ce à quoi ressemblent nos données. Comme je l'ai dit, le cas d'utilisation typique est que nous allions de l'avant, logiques à physiques, et cartographions les magasins de données et ce type de choses. Si vous regardez la capture d'écran sur le côté droit, vous verrez qu'il existe des noms abrégés à partir des noms source et lorsque nous avons appliqué un modèle de normes de nommage, nous avons en fait davantage de noms complets. Et nous pourrions insérer des espaces et tout ce genre de choses si nous le souhaitons, en fonction du modèle de normes de nommage que nous avons utilisé. Nous pouvons faire en sorte que cela ressemble à ce que nous voulons que ce soit dans nos modèles. Ce n'est que lorsque nous savons comment s'appelle quelque chose que nous pouvons réellement y attacher des définitions, car à moins de savoir de quoi il s'agit, comment pouvons-nous lui donner un sens?
Ce qui est bien, c’est que nous pouvons réellement invoquer cela lorsque nous faisons toutes sortes de choses. J'ai parlé de reverse engineering, nous pouvons en fait invoquer simultanément des modèles de normes de dénomination lorsque nous faisons du reverse engineering. Ainsi, dans un ensemble d’étapes à travers un assistant, ce que nous pouvons faire, c’est que, si nous connaissons les conventions, nous pouvons procéder au reverse engineering d’une base de données physique, elle sera ensuite reprise en tant que modèle physique dans un environnement de modélisation. va également appliquer ces conventions de nommage. Nous verrons donc quelles sont les représentations de noms de type anglais dans le modèle logique correspondant dans l'environnement. Nous pouvons également le faire et le combiner avec la génération de schémas XML afin de pouvoir prendre un modèle et même le pousser avec nos abréviations, que nous utilisions des frameworks SOA ou ce type de choses, afin de pouvoir également appliquer différentes conventions de dénomination. que nous avons effectivement stockés dans le modèle lui-même. Cela nous donne beaucoup de capacités très puissantes.
Encore une fois, voici un exemple de ce à quoi cela ressemblerait si j’avais un modèle. Celui-ci montre en fait que j'avais EMP pour «employé», SAL pour «salaire», PLN pour «plan» dans une convention de normes de nommage. Je peux également les appliquer pour les faire fonctionner de manière interactive au fur et à mesure que je construis des modèles et que j'insère des éléments. Si j'utilisais cette abréviation et si je tapais "Plan de rémunération des employés" sur le nom de l'entité, cela agirait avec le modèle de normes de nommage. J'ai défini ici, cela m'aurait donné EMP_SAL_PLN lors de la création des entités et les noms physiques correspondants immédiatement.
Encore une fois, très utile lorsque nous concevons et transmettons également l’ingénierie. Nous avons un concept très unique et c’est là que nous commençons vraiment à rassembler ces environnements.Et cela s'appelle Universal Mappings. Une fois que nous avons importé tous ces modèles dans notre environnement, ce que nous sommes capables de faire, en supposant que nous ayons maintenant appliqué ces conventions de dénomination et qu'elles soient faciles à trouver, nous pouvons maintenant utiliser une construction appelée Universal Mappings in ER. /Studio. Nous pouvons relier des entités entre modèles. Partout où nous voyons «client» - nous aurons probablement «client» dans un grand nombre de systèmes et bases de données différents - nous pouvons commencer à relier tous ces éléments afin que, lorsque je travaille avec un modèle, je peut voir où sont les manifestations des clients dans les autres modèles. Et parce que nous avons la couche modèle qui représente cela, nous pouvons même la lier à des sources de données et la ramener à nos enquêtes utilisées pour savoir dans quelles bases de données elles résident également. Cela nous donne vraiment la capacité de lier tout cela de manière très cohérente.
Je vous ai montré les objets de données d’entreprise. Je veux aussi parler des extensions de métadonnées, que nous appelons les pièces jointes, très rapidement. Cela nous donne la possibilité de créer des métadonnées supplémentaires pour nos objets de modèle. Très souvent, je configurais ces types de propriétés de manière à gérer différentes choses du point de vue de la gouvernance et de la qualité des données, mais également à nous aider dans la gestion des données principales et les stratégies de conservation des données. L'idée de base est de créer ces classifications et de les attacher où vous voulez, au niveau de la table, de la colonne, etc. Le cas d'utilisation le plus courant, bien sûr, est que les entités sont des tables, et ensuite je peux définir: quels sont mes objets de données de base, quelles sont mes tables de référence, quelles sont mes tables de transaction? Du point de vue de la qualité des données, je peux effectuer des classifications en fonction de leur importance pour l’entreprise, afin que nous puissions hiérarchiser les efforts de nettoyage des données et ce type de choses.
Quelque chose est souvent négligé, quelle est la politique de rétention pour différents types de données dans notre organisation? Nous pouvons les configurer et les associer aux différents types d'artefacts d'informations de notre environnement de modélisation et, bien entendu, à notre référentiel. La beauté réside dans le fait que ces pièces jointes résident dans notre dictionnaire de données. Ainsi, lorsque nous utilisons des dictionnaires de données d’entreprise dans l’environnement, nous pouvons les associer à plusieurs modèles. Nous n'avons qu'à les définir une fois et nous pouvons les utiliser encore et encore dans les différents modèles de notre environnement. Ceci est juste une capture d'écran rapide pour montrer que vous pouvez réellement spécifier quand vous faites une pièce jointe, quels sont les morceaux que vous voulez attacher. Et cet exemple ici est en fait une liste de valeurs. Ainsi, lorsqu’elles sont entrées, vous pouvez choisir parmi une liste de valeurs, vous avez beaucoup de contrôle dans l’environnement de modélisation sur ce qui est sélectionné, et vous pouvez même définir la valeur par défaut. La valeur est si une valeur n'est pas choisie. Donc, beaucoup de pouvoir là-bas. Ils vivent dans le dictionnaire de données.
Quelque chose que je veux vous montrer un peu plus bas sur cet écran. En plus, vous voyez les pièces jointes apparaître dans la partie supérieure, en dessous, vous voyez des informations sur la sécurité des données. Nous pouvons également appliquer des politiques de sécurité des données aux différentes informations de l'environnement. Pour différents mappages de conformité et classifications de sécurité des données, nous en livrons un certain nombre que vous pouvez simplement générer et commencer à utiliser, mais vous pouvez également définir vos propres mappages et normes de conformité. Que vous fassiez HIPAA ou l’une des autres initiatives. Et vous pouvez vraiment commencer à construire cet ensemble très riche de métadonnées dans votre environnement.
Et puis le glossaire et les termes - c’est là que la signification commerciale est liée. Nous avons assez souvent des dictionnaires de données que très souvent une organisation utilise comme point de départ pour commencer à éliminer les glossaires, mais la terminologie et le verbiage sont: souvent très technique. Donc, ce que nous pouvons faire, c’est que nous pouvons, si nous le souhaitons, nous en servir comme point de départ pour éliminer les glossaires, mais nous voulons vraiment que l’entreprise en soit propriétaire. Dans l’environnement de serveurs d’équipe, nous avons donné aux utilisateurs la possibilité de créer des définitions métier, puis de les lier aux différents artefacts de modèle auxquels ils correspondent dans l’environnement de modélisation. Nous reconnaissons également le point qui a été discuté plus tôt, à savoir que plus vous avez de dactylographie, plus le potentiel d'erreur humaine est grand. Dans notre structure de glossaire, nous soutenons également une hiérarchie de glossaires, de sorte que nous pouvons avoir différents types de glossaire ou différents types d'éléments dans l'organisation, mais il est tout aussi important de savoir si vous avez déjà certaines de ces sources. Avec les termes et tout ce qui est défini, nous pouvons réellement importer CSV pour les insérer dans notre environnement de modélisation et notre serveur d'équipe ou notre glossaire, puis commencer à créer des liens à partir de là. Et chaque fois que quelque chose change, il y a une piste d'audit complète de ce que sont les images avant et après, en termes de définitions et de tout le reste, et ce que vous allez voir très prochainement est également un processus d'autorisation. nous pouvons donc vraiment contrôler qui en est responsable, les approbations par des comités ou des individus, et ce genre de choses, pour rendre le processus de gouvernance encore plus robuste à l'avenir.
Ce que cela fait également pour nous, c’est que lorsque nous avons ces termes de glossaire dans notre glossaire Serveur d’équipe, c’est un exemple de montage dans une entité du modèle même que j’ai évoqué ici. Il peut y avoir des termes liés, mais ce que nous faisons également, c’est que s’il existe des mots dans ce glossaire qui apparaissent dans les notes ou les descriptions de ce que nous avons ici dans nos entités, ceux-ci sont automatiquement affichés dans une couleur de lien hypertexte plus claire. survolez-les, vous pouvez également consulter la définition figurant dans le glossaire métier. Cela nous donne même des informations plus riches lorsque nous consommons les informations elles-mêmes, avec tous les termes du glossaire existants. Cela aide vraiment à enrichir l'expérience et à appliquer le sens à tout ce avec quoi nous travaillons.
Donc, encore une fois, c'était un survol très rapide. Évidemment, nous pourrions passer des jours à explorer ce sujet en explorant les différentes parties, mais il s’agit d’un survol très rapide de la surface. Ce que nous cherchons vraiment à faire, c’est de comprendre à quoi ressemblent ces environnements de données complexes. Nous souhaitons améliorer la visibilité de tous ces artefacts de données et collaborer pour les éliminer avec ER / Studio. Nous voulons permettre une modélisation des données plus efficace et automatisée. Et nous parlons de tous les types de données, qu’il s’agisse de données volumineuses, de données relationnelles traditionnelles, de magasins de documents ou de toute autre chose. Et encore une fois, nous avons accompli cela parce que nous disposons de puissantes capacités d'ingénierie directe et inverse pour les différentes plates-formes et les autres outils disponibles. Et tout est axé sur le partage et la communication à travers l’organisation avec toutes les parties prenantes impliquées. C’est là que nous appliquons le sens à travers des normes de nommage. Nous appliquons ensuite les définitions dans nos glossaires métiers. Nous pouvons ensuite procéder à des classifications supplémentaires pour toutes nos autres fonctionnalités de gouvernance avec les extensions de métadonnées, telles que les extensions de qualité des données, les classifications pour la gestion des données maître ou tout autre type de classification que vous souhaitez appliquer à ces données. Nous pourrons ensuite résumer davantage et améliorer encore davantage la communication avec les objets de données métiers, avec les différents publics de parties prenantes, en particulier entre les modélisateurs et les développeurs.
Et là encore, l’important est que, derrière tout cela, se trouve un référentiel intégré doté de capacités de gestion du changement très robustes. Je n’ai pas eu le temps de le montrer aujourd’hui parce que cela devient assez complexe, mais le référentiel dispose de capacités de gestion du changement et de pistes de vérification très robustes. Vous pouvez créer des versions nommées, vous pouvez créer des versions nommées, et nous avons également la capacité pour ceux d'entre vous qui font de la gestion des changements, nous pouvons l'intégrer directement dans vos tâches. Nous avons aujourd'hui la possibilité d'insérer des tâches et d'associer vos modifications de modèle à des tâches, tout comme les développeurs associeraient leurs modifications de code à des tâches ou à des user stories avec lesquelles ils travaillent également.
Encore une fois, c'était un aperçu très rapide. J'espère que cela a suffi à vous mettre en appétit pour que nous puissions engager une conversation beaucoup plus profonde sur le partage de certains de ces sujets à l'avenir. Merci pour votre temps, et retour à vous, Rebecca.
Rebecca Jozwiak: Merci, Ron, c’était fantastique et j’ai quelques questions de la part du public, mais je veux donner à nos analystes une chance de mordre dans ce que vous avez dit. Eric, je vais y aller et peut-être que si vous voulez aborder cette diapositive ou une autre, pourquoi ne pas y aller en premier? Ou toute autre question.
Eric Little: Sûr. Désolé, quelle était la question, Rebecca? Vous voulez que je demande quelque chose de spécifique ou…?
Rebecca Jozwiak: Je sais que vous aviez quelques questions au départ pour Ron. Si vous voulez lui demander maintenant de répondre à l'une de ces questions, ou à une autre de votre diapositive ou de tout autre sujet susceptible de susciter votre intérêt et sur lequel vous souhaitez poser des questions? À propos des fonctionnalités de modélisation d’IDERA.
Eric Little: Une des choses, Ron, alors comment est-il que les diagrammes que vous montriez sont des types généraux de diagrammes relation-entités comme vous le feriez normalement dans la construction d'une base de données, n'est-ce pas?
Ron Huizenga: Oui, en général, mais bien sûr, nous avons les types étendus pour les magasins de documents et ce genre de choses. Nous avons en fait varié de la notation purement relationnelle, nous avons également ajouté des notations supplémentaires pour ces autres magasins.
Eric Little: Existe-t-il un moyen d’utiliser des types de modélisation basés sur des graphes? Existe-t-il un moyen d’intégrer, par exemple, supposons que j’ai quelque chose comme un quadrant supérieur, un outil de composition TopBraid ou que j’ai fait quelque chose dans Protégé ou , vous savez, comme les financiers de FIBO, ils travaillent beaucoup en sémantique, entre autres, en RDF - existe-t-il un moyen d’intégrer ce type de modélisation de type graphe de relation d’entité dans cet outil et de l’utiliser?
Ron Huizenga: Nous cherchons actuellement à gérer les graphiques. Nous ne gérons pas de manière explicite les bases de données graphiques ni ce genre de choses, mais nous cherchons des moyens de le faire pour étendre nos métadonnées. Je veux dire, nous pouvons importer des choses via XML et ce type de choses maintenant, si nous pouvons au moins faire une sorte de rendu de XML pour le ramener comme point de départ. Mais nous cherchons des moyens plus élégants d’apporter cela.
Et je vous ai également montré la liste des ponts de rétro-ingénierie que nous avons également. Nous cherchons donc toujours à obtenir des extensions de ces ponts pour des plates-formes spécifiques également. C’est un effort continu et continu, si cela se comprend, de commencer à adopter un grand nombre de ces nouveaux concepts et des différentes plates-formes existantes. Mais je peux dire que nous sommes vraiment à l’avant-garde de cela. Tout ce que j'ai montré sur MongoDB, par exemple, est ce que nous sommes le premier fournisseur de modélisation de données à le faire de manière native dans notre propre produit.
Eric Little: Ok, ouais. L’autre question que j’avais pour vous, alors, concernait la gouvernance et le maintien de - comme lorsque vous utilisiez l’exemple, lorsque vous montriez l’exemple de la personne qui est un «employé», je crois que c’était un « salaire »et ensuite vous avez un« plan », y a-t-il un moyen, comment gérez-vous, par exemple, différents types de personnes qui peuvent avoir - supposons que vous ayez une grande architecture, non, supposons que vous ayez une grande entreprise et les gens commencent à rassembler des éléments dans cet outil et vous avez un groupe avec le mot «employé» et un groupe avec le mot «travailleur». Une personne ici dit «salaire» et une autre personne "salaire."
Comment conciliez-vous, gérez-vous et réglez-vous ce genre de distinctions? Parce que je sais comment nous le ferions dans le monde des graphes, vous utiliseriez des listes de synonymes ou vous diriez qu’il existe un concept et qu’il a plusieurs attributs, ou que vous pourriez dire dans le modèle SKOS que j’ai une étiquette préférée et que j’ai nombreux labels alternatifs que je peux utiliser. Comment faites-vous cela?
Ron Huizenga: Nous le faisons de différentes manières, et parlons d’abord de la terminologie. Bien entendu, nous souhaitons notamment définir les termes définis ou sanctionnés. Dans le glossaire métier, il va de soi que nous le souhaitons. Et nous autorisons également les liens vers des synonymes dans le glossaire métier. Vous pouvez donc dire, voici mon terme, mais vous pouvez également définir tous les synonymes de ceux-ci.
Maintenant, ce qui est intéressant, bien sûr, c’est que lorsque vous commencez à parcourir ce vaste paysage de données avec tous ces différents systèmes existants, vous ne pouvez pas simplement y aller et modifier les tables correspondantes. correspond à cette norme de dénomination, car il peut s'agir d'un package que vous avez acheté. Vous n'avez donc aucun contrôle sur la modification de la base de données ni sur quoi que ce soit.
Ce que nous pourrions faire ici, en plus d’associer les définitions du glossaire, c’est à travers les cartographies universelles dont je parlais, ce que nous ferions et une sorte d’approche recommandée, c’est d’avoir un modèle logique global qui définit vous parlez de ces différents concepts d’entreprise. Associez les termes du glossaire métier à ceux-ci; et la bonne chose à savoir, maintenant que vous avez cette construction qui représente une entité logique en quelque sorte, vous pouvez alors commencer à relier cette entité logique à toutes les implémentations de cette entité logique dans les différents systèmes.
Ensuite, là où vous en avez besoin, vous pouvez voir, oh, «personne» est appelé «employé» dans ce système. Le «salaire» est appelé ici «salaire» dans cet autre système. Parce que vous verrez cela, vous verrez toutes les différentes manifestations de celles-ci parce que vous les avez liées.
Eric Little: Ok génial, ouais, j'ai compris. Dans ce sens, est-il prudent de dire que c'est un peu comme certaines des approches orientées objet?
Ron Huizenga: Quelque peu. C’est un peu plus intense que cela, je suppose, pourrait-on dire. Je veux dire, vous pouvez choisir de les relier manuellement, de les passer en revue, de les inspecter et de les effectuer également. La seule chose dont je n’ai pas vraiment eu la chance de parler - car, là encore, nous avons beaucoup de fonctionnalités - nous avons également une interface d’automatisation complète dans l’outil Data Architect lui-même. Et une capacité macro, qui est vraiment un langage de programmation dans l'outil. Ainsi, nous pouvons réellement faire des choses comme écrire des macros, les faire sortir et les interroger et créer des liens pour vous. Nous l'utilisons pour importer et exporter des informations, nous pouvons l'utiliser pour modifier des éléments ou ajouter des attributs, des événements basés sur le modèle lui-même, ou nous pouvons l'utiliser pour exécuter des lots de manière à interroger des éléments et à renseigner différentes constructions dans le modèle. modèle. Il existe donc une interface d’automatisation complète dont les utilisateurs peuvent également tirer parti. Et utiliser les correspondances universelles avec celles-ci constituerait un moyen très puissant de le faire.
Rebecca Jozwiak: Ok, merci Ron et merci Eric. C'étaient de bonnes questions. Je sais que nous dépassons un peu l'heure, mais j'aimerais donner à Malcolm l'occasion de poser quelques questions à Ron. Malcolm?
Malcolm Chisholm: Merci, Rebecca Alors, Ron, c’est très intéressant, je vois qu’il ya beaucoup de capacités ici. Un des domaines qui m'intéresse beaucoup est, par exemple, si nous avons un projet de développement, comment voyez-vous le modélisateur de données utiliser ces fonctionnalités et peut-être travailler plus en collaboration avec des analystes commerciaux, avec un profileur de données, avec un analyste de la qualité des données , et avec les sponsors commerciaux qui seront finalement responsables des besoins d’information réels dans le projet. Comment le modélisateur de données rend-il vraiment, vous savez, le projet plus efficace grâce aux fonctionnalités que nous examinons?
Ron Huizenga: Je pense qu’une des premières choses que vous devez faire ici est en tant que modélisateur de données - et je ne veux pas attaquer certains modélisateurs, mais je le ferai quand même - c’est que certaines personnes ont encore l’impression que le modélisateur de données est vraiment le type de rôle de gardien de porte de type, nous définissons son fonctionnement, nous sommes les gardes qui s’assurent que tout est correct.
Maintenant, il y a un aspect à cela, vous devez vous assurer que vous définissez une architecture de données saine et tout le reste. Mais le plus important en tant que modélisateur de données - et j’ai trouvé cela assez évident lors de mes consultations - est que vous deveniez un facilitateur et que vous deviez rassembler ces personnes.
Ce ne sera plus une conception, une génération, une construction de bases de données: vous devez être capable de travailler avec tous ces groupes de parties prenantes, en procédant par exemple en ingénierie inverse, en important des informations, en ayant d'autres personnes collaborent, que ce soit sur les glossaires ou la documentation, etc., et soyez un facilitateur pour extraire cela dans le référentiel, relier les concepts ensemble dans le référentiel et travailler avec ces personnes.
Il s’agit bien plus d’un environnement collaboratif dans lequel, même en définissant des tâches ou même en ayant un fil de discussion ou ce genre de choses que nous avons en équipe, nous pouvons réellement collaborer, poser des questions et arriver au produit final final. besoin de leur architecture de données et de leur organisation. Est-ce que ce genre de réponse?
Malcolm Chisholm: Oui je suis d'accord. Vous savez, je pense que la compétence en facilitation est quelque chose de vraiment très souhaitable pour les modélisateurs de données. Je conviens que nous ne voyons pas toujours cela, mais je pense que cela est nécessaire et je suggérerais que vous souhaitiez parfois rester dans votre coin pour faire de la modélisation de vos données, mais vous devez vraiment travailler avec les autres groupes de parties prenantes. ou vous ne comprenez tout simplement pas l'environnement de données avec lequel vous traitez, et je pense que le modèle en souffre. Mais c'est juste mon opinion.
Ron Huizenga: Et c’est intéressant parce que vous avez mentionné plus tôt dans votre diapositive l’histoire selon laquelle les entreprises se détournent un peu des technologies de l’information parce qu’elles ne fournissaient pas les solutions en temps voulu et ce genre de choses.
Il est très intéressant de noter qu’au cours de mes dernières missions de conseil, avant de devenir chef de produit, la plupart des projets que j’avais réalisés au cours des deux dernières années étaient parrainés par des entreprises. C’était vraiment l’entreprise qui les pilotait et les architectes de données. et les modeleurs ne faisaient pas partie de l'informatique. Nous faisions partie d'un groupe parrainé par des entreprises et nous étions présents en tant qu'animateurs travaillant avec le reste des équipes de projet.
Malcolm Chisholm: Je pense donc que ce point est très intéressant.Je pense que nous commençons à voir un changement dans le monde des affaires où les entreprises demandent, ou pensent peut-être, moins que ce que je fais, en tant que processus, mais elles commencent aussi à penser aux données. que je travaille, quels sont mes besoins en matière de données, quelles sont les données dont je traite en tant que données, et dans quelle mesure pouvons-nous obtenir les produits et les capacités IDERA pour appuyer ce point de vue, et je pense que les besoins de l'entreprise, même bien que ce soit encore un peu naissant.
Ron Huizenga: Je suis d’accord avec vous et je pense que nous le constatons de plus en plus. Nous avons assisté à un réveil et vous en avez déjà parlé plus tôt en ce qui concerne l’importance des données. Nous avons vu l’importance des données au tout début de l’informatique ou de l’évolution des bases de données, puis, comme vous le dites, nous sommes en quelque sorte entrés dans tout ce cycle de gestion des processus - et le processus est extrêmement important, ne vous méprenez pas là-bas - mais maintenant, que s’est-il passé est quand cela est arrivé, le type de données de focus perdu.
Et maintenant, les organisations se rendent compte que les données sont vraiment le point central. Les données représentent tout ce que nous faisons dans notre entreprise. Nous devons donc nous assurer que nous disposons de données précises, que nous pouvons trouver les informations correctes nécessaires à la prise de décision. Parce que tout ne vient pas d'un processus défini. Une partie de l'information est un sous-produit d'autres choses et nous devons encore être en mesure de la trouver, de savoir ce que cela signifie et de pouvoir traduire les données que nous y voyons en une connaissance que nous pourrons utiliser pour améliorer notre activité.
Malcolm Chisholm: C’est un autre domaine dans lequel j’ai du mal à faire ce que j’appellerais le cycle de vie des données: vous savez, si nous examinons le type de chaîne de transmission de données passant par une entreprise, nous commencerions par l’acquisition la capture de données, qui peut être la saisie de données mais peut-être aussi, je reçois des données de l'extérieur de l'entreprise auprès d'un fournisseur de données.
Et puis, de la saisie des données, nous passons à la maintenance des données, où je songe à normaliser ces données et à les envoyer aux endroits où elles sont nécessaires. Et puis l'utilisation des données, les points où se trouvent les données, vous en tirerez une valeur.
Et à l’époque, tout cela se faisait dans un style individuel, mais aujourd’hui, il pourrait s’agir, par exemple, d’un environnement analytique, puis, au-delà, d’une archive, d’un magasin, où nous stockons les données lorsque nous ne sommes plus disponibles. besoin et enfin un processus de purge. Comment envisagez-vous l'intégration de la modélisation des données dans la gestion de l'ensemble de leur cycle de vie?
Ron Huizenga: C’est une très bonne question et l’une des choses que je n’ai vraiment pas eu le temps d’approfondir aujourd’hui, c’est ce dont nous commençons vraiment à parler, c’est le lignage des données. Donc, ce que nous pouvons réellement faire, c’est que nous avons une capacité de lignage de données dans nos outils et, comme je l’ai dit, nous pouvons en extraire une partie à partir d’outils ETL, mais vous pouvez aussi le mapper simplement en traçant le lignage. N'importe lequel de ces modèles de données ou bases de données que nous avons capturés et intégrés dans des modèles, nous pourrions référencer les constructions à partir de cela dans notre diagramme de lignage de données.
Ce que nous pouvons faire, c'est tracer un flux de données, comme vous le dites, de la source à la cible, et tout au long du cycle de vie de la façon dont ces données transitent par les différents systèmes et ce que vous allez trouver est, prenons les employés 'data - c'est l'un de mes favoris basé sur un projet que j'ai fait il y a des années. J'ai travaillé avec une organisation qui disposait de données sur les employés dans 30 systèmes différents. Ce que nous avons fini par faire ici - et Rebecca a fait apparaître la diapositive de lignage de données - c’est une diapositive de lignage de données assez simpliste ici, mais nous avons pu faire, c’est faire entrer toutes les structures de données, les référencer dans le diagramme, puis nous peut réellement commencer à regarder quels sont les flux entre, et comment ces différentes entités de données sont-elles liées dans un flux? Et nous pouvons aller au-delà de cela aussi. Cela fait partie d'un diagramme de flux de données ou de lignage que nous voyons ici. Si vous voulez aller plus loin, nous avons également la partie architecte d’affaires de cette suite et la même chose s’applique là-bas.
Toutes les structures de données que nous avons capturées dans l'environnement de modélisation de données peuvent être référencées dans l'outil de modélisation métier. Ainsi, même dans vos diagrammes de modèle métier ou vos diagrammes de processus métier, vous pouvez référencer des magasins de données individuels si vous le souhaitez. l'environnement de modélisation des données, et pendant que vous les utilisez dans les dossiers de votre modèle de processus métier, vous pouvez même spécifier le CRUD dans ces dossiers, en indiquant comment ces informations sont utilisées ou produites, puis nous pouvons commencer à générer des choses comme des rapports d’impact et d’analyse et des diagrammes.
Ce que nous visons, et nous avons déjà beaucoup de capacités, mais l’une des choses que nous avons en quelque sorte comme une sorte de but que nous examinons, à mesure que nous continuons à faire évoluer nos outils, est en mesure de tracer cette lignée de données organisationnelle de bout en bout et le cycle de vie complet des données.
Malcolm Chisholm: D'accord. Rebecca, est-ce que j'en ai un?
Rebecca Jozwiak: Je vous en permets une de plus, Malcolm, allez-y.
Malcolm Chisholm: Merci beaucoup. En ce qui concerne la gouvernance des données et la modélisation des données, comment pouvons-nous amener ces deux groupes à travailler efficacement ensemble et à se comprendre?
Eric Little: C’est intéressant, je pense que cela dépend vraiment de l’organisation, et cela remonte à mon concept précédent: dans les organisations où les initiatives étaient axées sur les activités, nous étions directement liés. Par exemple, je dirigeais une équipe d’architecture de données étaient étroitement liés aux utilisateurs professionnels et nous les aidions en réalité à mettre en place leur programme de gouvernance des données. Encore une fois, il s’agit davantage d’une approche consultative, mais c’est davantage une fonction de l’entreprise.
Pour ce faire, vous devez pouvoir disposer de concepteurs et d'architectes de données qui comprennent vraiment les activités, puissent établir des relations avec les utilisateurs professionnels et les ont ensuite aidés à gérer les processus de gouvernance qui les entourent. L’entreprise souhaite le faire, mais d’une manière générale, nous disposons des connaissances technologiques nécessaires pour pouvoir les aider à se démarquer de ce type de programmes. Il faut vraiment que ce soit une collaboration, mais cela doit appartenir à une entreprise.
Malcolm Chisholm: Ok, c’est génial. Je vous remercie.
Dr. Eric Little: D'accord.
Rebecca Jozwiak: Ok, merci beaucoup. Membres du public, je crains que nous n’ayons pas répondu à vos questions, mais je veillerai à ce qu’elles soient transmises à l’invité approprié que nous avions en ligne aujourd’hui. Je tiens à remercier Eric, Malcolm et Ron d’avoir été nos invités aujourd’hui. C'était génial, les gars. Et si vous appréciez la diffusion Web IDERA d’aujourd’hui, IDERA sera également présent mercredi prochain sur Hot Technologies, si vous souhaitez y participer, en discutant des défis de l’indexation et des Oracles, un autre sujet fascinant.
Merci beaucoup, faites attention, et à la prochaine fois. Bye Bye.