Construire une architecture de données orientée métier

Par Techopedia Staff, 28 septembre 2016

À retenir : l' animatrice Rebecca Jozwiak discute des solutions d'architecture de 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 de 2016. Aujourd'hui, nous discutons de «Construire une architecture de données orientée entreprise», définitivement un sujet brûlant. Je m'appelle Rebecca Jozwiak, je serai votre hôte pour la webdiffusion d'aujourd'hui. Nous tweetons avec un hashtag # HotTech16, donc si vous êtes déjà sur Twitter, n'hésitez pas à vous joindre à nous également. Si vous avez des questions à tout moment, veuillez les envoyer dans le volet Q&R en bas à droite de votre écran et nous nous assurerons qu'elles obtiennent une réponse. Sinon, nous veillerons à ce que nos clients les obtiennent pour vous.

Donc, aujourd'hui, nous avons une gamme vraiment fascinante. Beaucoup de gros frappeurs nous accompagnent 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 est une suite vraiment complète de solutions de gestion et de modélisation des données. Et aujourd'hui, il va nous faire une démonstration du fonctionnement de sa solution. Mais avant d'en arriver là, Eric Little, je vais vous passer le ballon.

Eric Little: D'accord, merci beaucoup. Je vais donc passer en revue quelques sujets ici qui, je pense, vont un peu se rapporter à la conversation de Ron et, espérons-le, préparer le terrain pour certains de ces sujets, certains Q&R.

Donc, ce qui m'a intéressé avec ce que fait IDERA, c'est que je pense qu'ils soulignent correctement que les environnements complexes génèrent beaucoup de 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 suivre le rythme dans le monde des affaires d'aujourd'hui. Ainsi, ces personnes qui travaillent dans des espaces technologiques verront souvent que vos clients ont des problèmes avec: «Comment utiliser les mégadonnées? Comment intégrer la sémantique? Comment puis-je lier certaines de ces nouvelles choses avec mes anciennes données? »Et ainsi de suite, et ce genre de nous conduit de nos jours dans ces quatre v de big data que beaucoup de gens connaissent assez bien, et je comprends qu'il peut y en avoir plus de quatre parfois - j'en ai vu jusqu'à huit ou neuf - mais normalement, quand les gens parlent de choses comme les mégadonnées ou si vous parlez de mégadonnées, vous regardez généralement quelque chose qui est à l'échelle de l'entreprise. Et donc les gens diront, d'accord, pensez au volume de vos données, qui est normalement le point de mire - c'est juste ce que vous avez. La vitesse des données est liée à la vitesse à laquelle je peux les déplacer ou à la vitesse à 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 géré relativement rapidement par de nombreuses approches différentes. Mais du côté droit, je vois beaucoup de possibilités d'amélioration et beaucoup de nouvelles technologies qui arrivent vraiment au premier plan. Et cela a vraiment à voir avec la troisième colonne, la variété des données.

En d'autres termes, la plupart des entreprises recherchent aujourd'hui des données structurées, semi-structurées et non structurées. Les données d'image commencent à devenir un sujet brûlant, donc pouvoir utiliser la vision par ordinateur, regarder les pixels, pouvoir gratter le texte, la PNL, l'extraction d'entités, vous avez des informations graphiques qui proviennent soit de modèles statistiques, soit de sémantique modèles, vous avez des données relationnelles qui existent dans les tables, etc. Et donc rassembler toutes ces données et tous ces différents types représente vraiment un grand défi et vous le verrez dans, vous le savez, chez Gartner et d'autres personnes qui suivent en quelque sorte les tendances de l'industrie.

Et puis la dernière chose dont les gens parlent dans les mégadonnées est souvent cette notion de voracité, qui est vraiment l'incertitude de vos données, leur flou. Dans quelle mesure savez-vous sur quoi portent vos données, comprenez-vous bien ce qui s'y trouve et, vous savez? La possibilité d'utiliser des statistiques et la possibilité d'utiliser un certain type d'informations sur ce que vous savez peut-être ou d'utiliser un certain contexte peuvent être utiles. Et donc la possibilité d'examiner les données de cette manière en termes de quantité, de rapidité dont vous avez besoin pour les déplacer ou y accéder, tous les types de données que vous pouvez avoir dans votre entreprise et dans quelle mesure vous êtes sûr de savoir où c'est, ce que c'est, de quelle qualité c'est, et ainsi de suite. Cela nécessite vraiment un effort important et coordonné entre de nombreuses personnes pour gérer efficacement leurs données. La modélisation des données est donc de plus en plus importante dans le monde d'aujourd'hui. Les bons modèles de données génèrent donc beaucoup de succès dans les applications d'entreprise.

Vous avez des sources de données provenant de diverses sources, comme nous le disions, qui nécessitent vraiment beaucoup de différents 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 récupérer des informations. Mais pour ce faire, vous avez besoin de bonnes stratégies de mappage et donc le mappage de ces types de données et le suivi de ces mappages peuvent être un véritable défi. Et puis vous avez ce problème de, comment puis-je lier mes données héritées à toutes ces nouvelles sources de données? Supposons donc que j'ai un graphique, dois-je prendre toutes mes données relationnelles et les mettre 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 vraiment être exécutée sur un grand nombre de ces différents types de sources de données et de combinaisons. Donc, les réponses qui en découlent, les réponses dont les gens ont besoin pour vraiment prendre de bonnes décisions commerciales sont essentielles.

Donc, il ne s'agit pas simplement de construire une technologie pour le plaisir de la technologie, c'est vraiment, que vais-je faire, que puis-je en faire, quel type d'analyse puis-je exécuter et, par conséquent, la capacité, comme je l'ai déjà fait dont j'ai parlé, rassembler ces choses, les intégrer est vraiment, vraiment important. Et l'un de ces types d'analyses s'exécute ensuite sur des éléments comme la recherche et la requête fédérées. Cela devient vraiment un must. Vos requêtes doivent normalement être réparties sur plusieurs types de sources et extraire les informations de manière fiable.

Le seul élément clé qui souvent, en particulier les gens vont examiner des éléments clés comme les technologies sémantiques - et c'est quelque chose dont j'espère que Ron va parler un peu dans l'approche IDERA - est de savoir comment séparer ou gérer le 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, vous pouvez avoir des données de document, vous pouvez avoir des données de feuille de calcul, vous pouvez avoir des données d'image. Si vous êtes dans des domaines comme les industries pharmaceutiques, vous disposez de grandes quantités de données scientifiques. Et en plus de cela, les gens recherchent normalement un moyen de construire un modèle qui leur permet d'intégrer rapidement ces données et vraiment lorsque vous recherchez des données maintenant, vous ne cherchez pas à rassembler toutes les données dans votre couche de modèle, ce que vous envisagez de faire pour la couche de modèle, c'est de vous donner une belle représentation logique de ce que sont les choses, des vocabulaires communs, des types communs d'entités et de relations, et la possibilité d'accéder réellement aux données où elles se trouvent. Il doit donc dire ce que c'est, et il doit dire où il se trouve, et il doit dire comment aller le chercher et le ramener.

Il s'agit donc d'une approche qui a très bien réussi à propulser les technologies sémantiques vers l'avant, qui est un domaine dans lequel je travaille beaucoup. Donc, une question que je voulais poser à Ron, et qui je pense sera utile dans la section Q&R, est de voir comment cela est-il accompli par la plateforme IDERA? La couche modèle est-elle donc réellement séparée de la couche 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 de leur approche? Par conséquent, les données de référence deviennent également essentielles. Donc, si vous voulez avoir ce genre de modèles de données, si vous voulez pouvoir vous fédérer et rechercher à travers les choses, vous devez vraiment avoir 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 à maintenir. Il est donc souvent difficile de nommer des normes en elles-mêmes. Un groupe appellera quelque chose X et un groupe appellera quelque chose Y et maintenant vous avez le problème de savoir comment quelqu'un trouve X et Y quand il recherche ce type d'informations? Parce que vous ne voulez pas simplement leur donner une partie des données, vous voulez leur donner tout ce qui est lié. Dans le même temps, les termes changent, les logiciels deviennent obsolètes, etc.

Et, encore une fois, les technologies sémantiques, utilisant spécifiquement des éléments tels que les taxonomies et les vocabulaires, les dictionnaires de données, ont fourni un moyen d'espace standard pour ce faire, qui est vraiment très robuste, il utilise certains types de normes, mais la communauté des bases de données l'a fait pour un longtemps aussi, juste de différentes manières. Je pense que l'une des clés ici est de réfléchir à la façon d'utiliser peut-être des modèles de relation d'entité, comment utiliser peut-être des modèles de graphique ou un type d'approche ici qui va vraiment vous donner, espérons-le, une manière standardisée et espacée de gérer vos données de référence. Et puis bien sûr, une fois que vous avez les données de référence, les stratégies de cartographie 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.

Donc, un défi dans tout cela est toujours, comment donnez-vous des informations à quelqu'un tout en les rendant pertinentes à la façon dont elles en parlent? Ainsi, un groupe peut avoir une façon de voir quelque chose, par exemple, vous pouvez être un chimiste travaillant sur un médicament, et vous pouvez être un biologiste structurel 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, parce que l'autre approche est, vous devez forcer les gens à abandonner leur mandat et à utiliser quelqu'un d'autre, ce qu'ils n'aiment souvent pas. Un autre point ici est que la gestion d'un grand nombre de synonymes devient difficile, donc il y a beaucoup de mots différents dans les données de nombreuses personnes qui peuvent se référer à 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'une industrie à l'autre, donc si vous prévoyez une sorte de solution globale pour ce type de gestion des données, est-il facile à transporter d'un projet ou d'une application à une autre? Cela peut être un autre défi.

L'automatisation est importante et c'est aussi un défi. La gestion manuelle des données de référence coûte cher. Il est coûteux de devoir continuer à mapper manuellement et il est coûteux d'avoir des experts en la matière qui cessent de faire leur travail au jour le jour et doivent entrer et corriger constamment les dictionnaires de données et mettre à jour les définitions, etc., etc. Les vocabulaires reproductibles ont 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 y aura certains types de vocabulaire que vous pouvez emprunter dans des espaces open source, de même avec les produits pharmaceutiques, de même avec le secteur bancaire et financier, de même avec beaucoup de ces types de domaines. Les gens mettent des vocabulaires réutilisables, génériques et reproductibles à la disposition des gens.

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 sémantique, vous voyez souvent des choses comme les modèles SKOS qui fournissent des normes au moins plus larges que / plus étroites que les relations et ces choses peuvent être difficiles à faire dans les modèles ER mais, vous savez, pas impossible, cela dépend juste de la quantité de cela machines et cette liaison que vous pouvez gérer 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 l'amorcer un peu pour parler peut-être de la façon dont le système IDERA a été utilisé en conjonction 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 parce que ce genre de choses dans le monde sémantique peut souvent être emprunté à l'aide de points de terminaison SPARQL? Vous pouvez importer des modèles RDF ou OWL directement dans votre modèle - y faire référence - donc, par exemple, l'ontologie génétique ou l'ontologie protéique, qui peut vivre quelque part dans son propre espace avec sa propre structure de gouvernance et je peux simplement importer tout ou en partie car j'en ai besoin dans mes propres modèles. Et je suis curieux de savoir comment IDERA aborde cette question. Devez-vous tout maintenir en interne, ou existe-t-il des moyens d'utiliser d'autres types de modèles standardisés et de 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 en consultant les clients est que beaucoup d'erreurs se produisent si les gens écrivent dans leurs propres définitions ou leurs propres métadonnées. Donc, vous obtenez des fautes d'orthographe, vous obtenez des erreurs au gros doigt, c'est une chose. Vous obtenez également des gens qui peuvent prendre quelque chose de, vous savez, seulement de Wikipedia ou d'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 ce n'est pas complet, et ce n'est pas clair alors comment fonctionne le processus de gouvernance. La gouvernance, bien sûr, est un très, 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 façon dont cela peut s'intégrer aux données de base de quelqu'un, comment il va utiliser ses métadonnées, et bientôt.

Je voulais donc simplement mettre certains de ces sujets là-bas. Ce sont des éléments que je vois dans l'espace des affaires à travers de nombreux types de missions de conseil et de nombreux 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'aime beaucoup votre commentaire selon lequel de nombreuses erreurs peuvent se produire si les gens écrivent leurs propres définitions ou métadonnées. Je sais que dans le monde du journalisme, il y a un mantra selon lequel «de nombreux yeux font peu d'erreurs», mais en ce qui concerne les applications pratiques, trop de mains dans le pot de cookies ont tendance à vous laisser avec beaucoup de cookies cassés, non?

Eric Little: Oui, et les germes.

Rebecca Jozwiak: Ouais. Sur ce, je vais continuer et le transmettre à Malcolm Chisholm. Malcolm, la parole est à vous.

Malcolm Chisholm: Merci beaucoup, Rebecca. Je voudrais en quelque sorte regarder un peu ce dont Eric a parlé, et ajouter, en quelque sorte, quelques observations auxquelles, vous savez, Ron voudra peut-être aussi répondre en parlant de «Vers une architecture de données axée sur les entreprises» »- 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.

Si nous regardons ce qui se passe depuis, vous savez, les ordinateurs centraux sont vraiment devenus disponibles pour les entreprises - disons, vers 1964 - jusqu'à aujourd'hui, nous pouvons voir qu'il y a eu beaucoup de changements. Et ces changements, je résumerais comme étant un passage d'une approche centrée sur les processus à une approche centrée sur les données. Et c'est ce qui rend les architectures de données axées sur l'entreprise si importantes et si pertinentes pour aujourd'hui. Et je pense, vous savez, ce n'est pas seulement un mot à la mode, c'est quelque chose qui est absolument réel.

Mais nous pouvons l'apprécier un peu plus si nous plongeons dans l'histoire, donc remontant dans le temps, remontant aux années 1960 et pendant un certain temps par la suite, les ordinateurs centraux ont dominé. Ceux-ci ont ensuite cédé la place à des PC où vous aviez réellement une rébellion des utilisateurs lorsque les PC sont entrés. La rébellion contre l'informatique centralisée, qui, selon eux, ne répondait pas à leurs besoins, n'était pas assez agile. Cela a rapidement donné naissance à l'informatique distribuée, lorsque les PC étaient reliés entre eux. Et puis Internet a commencé à se produire, ce qui a brouillé les frontières de l'entreprise - il pouvait désormais interagir avec des parties extérieures à lui en termes d'échange de données, 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 des plates-formes qui sont vraiment des infrastructures de marchandisation et nous laissons donc pour ainsi dire l'informatique de la nécessité de gérer des centres de données volumineux parce que, vous savez, nous avons la capacité de cloud disponible pour nous, et en même temps que le big data dont Eric, vous le savez, a parlé avec tant d'éloquence. Et dans l'ensemble, comme nous le voyons, au fur et à mesure que le changement technologique s'est produit, il est devenu plus centré sur les données, nous nous soucions plus des données. Comme avec Internet, comment les données sont échangées. Avec les mégadonnées, les quatre v ou plus des données elles-mêmes.

Parallèlement, et peut-être plus important encore, les cas d'utilisation commerciale ont changé. Lorsque les ordinateurs ont été introduits pour la première fois, ils ont été utilisés pour automatiser des choses comme les livres et les registres. Et tout ce qui était un processus manuel, qui impliquait des registres ou des choses comme ça, était programmé, essentiellement, en interne. Cela s'est déplacé dans les années 80 vers la disponibilité de packages opérationnels. Vous n'aviez plus besoin de rédiger votre propre paie, vous pouviez acheter quelque chose qui le faisait. Cela a entraîné une importante réduction des effectifs à l'époque, ou une restructuration, dans de nombreux services informatiques. Mais la Business Intelligence, avec des choses comme les entrepôts de données, est apparue, principalement dans les années 90. Suivi par les modèles d'entreprise dotcom qui ont été, bien sûr, une grande frénésie. Puis MDM. Avec MDM, vous commencez à voir que nous ne pensons pas à l'automatisation; nous nous concentrons simplement sur la conservation des données en tant que données. Et puis l'analyse, représentant la valeur que vous pouvez tirer des données. Et dans l'analyse, vous voyez des entreprises qui réussissent très bien dont le modèle commercial principal tourne autour des données. Google, Twitter, Facebook feraient partie de cela, mais vous pourriez également affirmer que Walmart l'est.

Et donc, l'entreprise pense vraiment aux données. Comment pouvons-nous tirer profit des données? Comment les données peuvent conduire l'entreprise, la stratégie et nous sommes à l'âge d'or des données. Alors, que se passe-t-il en termes d'architecture de données, si les données ne sont plus considérées comme le simple échappement qui sort du back-end des applications, mais sont vraiment au cœur de nos modèles économiques? Eh bien, une partie du problème que nous avons pour y parvenir est que l'informatique est vraiment coincée dans le passé avec le cycle de vie du développement des systèmes, ce qui était une conséquence de devoir traiter rapidement cette phase d'automatisation des processus au début de l'informatique et de travailler dans 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 à l'obtention d'une architecture de données axée sur l'entreprise sont parce que nous avons, en quelque sorte, accepté sans critique une culture informatique qui dérive d'une époque révolue.

Tout est donc un projet. Dites-moi vos besoins en détail. Si les choses ne fonctionnent pas, c'est parce que vous ne m'avez pas dit vos besoins. Eh bien, cela ne fonctionne pas aujourd'hui avec les données, car nous ne commençons pas avec des processus manuels non automatisés ou, vous savez, une conversion technique des processus métier, nous commençons très souvent avec des données de production déjà existantes que nous essayons pour obtenir de la valeur. Mais personne qui parraine un projet axé sur les données ne comprend vraiment ces données en profondeur. Nous devons faire la découverte des données, nous devons faire l'analyse des données source. Et cela ne correspond pas vraiment au développement de systèmes, vous savez - cascade, cycle de vie SDLC - dont Agile, je maintiens, est une sorte de meilleure version de cela.

Et ce qui se concentre sur la technologie et la fonctionnalité, pas sur les données. Par exemple, lorsque nous effectuons des tests dans une phase de test, ce sera généralement le cas, ma fonctionnalité fonctionne-t-elle, disons mon ETL, mais nous ne testons pas les données. Nous ne testons pas nos hypothèses sur les données sources qui arrivent. Si nous le faisions, nous serions peut-être mieux en forme et en tant que personne qui a réalisé des projets d'entrepôt de données et souffert de changements en amont, cassant mes ETL, j'apprécierais cela. Et en fait, ce que nous voulons voir, c'est tester comme une étape préliminaire à la surveillance continue de la qualité des données de production. Nous avons donc ici beaucoup d'attitudes où il est difficile de réaliser l'architecture de données axée sur l'entreprise, car nous sommes conditionnés par l'ère de la focalisation sur les processus. Nous devons faire la transition vers la data-centricity. Et ce n'est pas une transition totale, vous savez, il y a encore beaucoup de travail de processus à faire, mais nous ne pensons pas vraiment en termes de données lorsque nous en avons besoin, et les circonstances qui se produisent lorsque nous sommes vraiment obligé de le faire.

Maintenant, l'entreprise réalise la valeur des données, elle veut les débloquer, alors comment allons-nous faire? Alors, comment faisons-nous la transition? Eh bien, nous plaçons les données au cœur des processus de développement. Et nous laissons l'entreprise diriger en matière d'informations. Et nous comprenons que personne ne comprend les données source existantes au début du projet. Vous pourriez faire valoir que la structure des données et les données elles-mêmes y sont parvenues via l'informatique et les opérations, respectivement, alors nous devrions le savoir, mais vraiment, nous ne le savons pas. Il s'agit d'un développement centré sur les données. Nous devons donc, en réfléchissant à où et comment modéliser les données dans un monde centré sur les données, nous devons avoir des boucles de rétroaction pour les utilisateurs en termes d'affiner leurs besoins en informations, comme nous le faisons pour la découverte et le profilage des données, prévoient une analyse des données sources et, au fur et à mesure que nous aurons 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, pas nécessairement les projets Big Data, bien que ce soit encore, je le maintiens, assez proche de cela. Et donc, ces boucles de rétroaction incluent les modélisateurs de données, vous savez, qui avancent progressivement leur modèle de données et interagissent avec les utilisateurs pour s'assurer que les exigences en matière d'informations sont affinées en fonction de ce qui est possible, de ce qui est disponible, à partir des données source, comme ils le comprennent mieux, donc ce n'est plus le cas du modèle de données étant, vous savez, dans un état qui n'est pas là ou complètement terminé, c'est une mise au point progressive de celui-ci.

De même, plus en aval de cela, nous avons une assurance qualité où nous développons des règles pour les tests de qualité des données afin de nous assurer que les données respectent les paramètres sur lesquels nous faisons des hypothèses. En entrant, Eric faisait référence à des changements dans les données de référence, ce qui pourrait se produire. Vous ne voulez pas être, pour ainsi dire, une victime en aval de, en quelque sorte, des changements non gérés dans ce domaine, de sorte que les règles d'assurance qualité peuvent entrer dans la post-production, un contrôle continu de la qualité des données. Vous pouvez donc commencer à voir si nous allons être centrés sur les données, la façon dont nous procédons au développement centré sur les données est assez différente du SDLC basé sur les fonctionnalités et d'Agile. Et puis nous devons également prêter attention aux points de vue des entreprises. Nous avons - et là encore cela fait écho à ce qu'Eric disait - nous avons un modèle de données définissant un modèle d'histoire de données pour notre base de données, mais en même temps nous avons besoin de ces modèles conceptuels, de ces vues commerciales des données qui, traditionnellement, ne se faisaient pas en le passé. Nous avons parfois pensé, je pense, que 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 rendre à 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 pour le faire, nous avons donc en fait des tâches de modélisation supplémentaires. Je pense que c'est, vous le savez, intéressant si vous êtes entré dans les rangs en tant que modélisateur de données comme je l'ai fait, et encore une fois, quelque chose de nouveau.

Et enfin, je voudrais dire que l'architecture plus large doit également refléter cette nouvelle réalité. Le MDM client traditionnel, par exemple, est un peu, d'accord, mettons nos données client dans un hub où nous pouvons, vous le savez, donner un sens en termes de qualité de données vraiment juste pour les applications de back-office. Ce qui du point de vue de la stratégie d'entreprise est une sorte de bâillement. Aujourd'hui, cependant, nous examinons les hubs MDM client qui contiennent des données de profil client supplémentaires, pas seulement les données statiques, qui ont alors vraiment une interface bidirectionnelle avec les applications de transaction du client. Oui, ils soutiennent toujours le back-office, mais maintenant nous connaissons également ces comportements de nos clients. C'est plus cher à construire. C'est plus complexe à construire. Mais il est axé sur les affaires d'une manière différente du MDM client traditionnel. Vous échangez une orientation vers l'entreprise contre des conceptions plus simples qui sont 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 qu'il y a un certain nombre de niveaux auxquels nous devons répondre à l'architecture de données axée sur les affaires et je pense que c'est un moment très excitant pour faire les choses.

Alors merci à toi Rebecca.

Rebecca Jozwiak: Merci Malcolm, et j'ai vraiment apprécié ce que vous avez dit à propos des modèles de données qui doivent nourrir la vision de l'entreprise, car, un peu à la différence de ce que vous disiez, où l'informatique a tenu les rênes pendant si longtemps et ce n'est juste plus le cas et que la culture doit changer. Et je suis presque sûr qu'il y avait un chien en arrière-plan qui était d'accord à 100% 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 commencer, je vais parcourir quelques diapositives, puis un peu de démo car, comme Eric et Malcolm l'ont souligné, c'est un sujet très large et profond, et Avec ce dont nous parlons aujourd'hui, nous ne faisons qu'effleurer la surface, car il y a tellement d'aspects et de choses que nous devons vraiment considérer et examiner à partir d'une architecture orientée métier. Et notre approche est de vraiment créer ce modèle et de tirer une vraie valeur des modèles, car vous pouvez les utiliser comme véhicule de communication ainsi que comme couche pour activer d'autres systèmes. Que vous fassiez une architecture orientée services ou d'autres choses, le modèle devient vraiment l'élément vital de ce qui se passe, avec toutes les métadonnées qui l'entourent et les données que vous avez dans votre entreprise.

Ce dont je veux parler, cependant, est presque de faire un pas en arrière, car Malcolm avait abordé une partie de l'histoire de la façon dont les solutions ont évolué et ce genre de choses. Une façon de souligner à quel point il est important d'avoir une architecture de données saine est un cas d'utilisation que je rencontrais très souvent lorsque je consultais avant de devenir un gestionnaire de produits, c'est-à-dire que j'irais dans des organisations qu'ils fassent de la transformation commerciale ou simplement remplacent certains systèmes existants et ce genre de choses, et il est devenu évident très rapidement à quel point les organisations comprennent mal leurs propres données. Si vous prenez un cas d'utilisation particulier comme celui-ci, que vous soyez un consultant ou que ce soit une personne qui vient de commencer avec une organisation, ou que votre organisation se soit constituée au fil des ans avec l'acquisition de différentes entreprises, ce que vous finissez est un environnement très complexe très rapidement, avec un certain nombre de nouvelles technologies différentes, ainsi que des technologies héritées, des solutions ERP et tout le reste.

Donc, une des choses que nous pouvons vraiment faire avec notre approche de modélisation est de répondre à la question: comment puis-je donner un sens à tout cela? Nous pouvons vraiment commencer à rassembler les informations afin que l'entreprise puisse tirer parti des informations dont nous disposons correctement. Et cela se révèle, qu'est-ce que nous avons là-bas dans ces environnements? Comment puis-je utiliser les modèles pour chasser les informations dont j'ai besoin et mieux comprendre ces informations? Et puis nous avons les types de métadonnées traditionnels pour toutes les différentes choses comme les modèles de données relationnelles, et nous sommes habitués à voir des choses comme les définitions et les dictionnaires de données, vous savez, les types de données et ce genre de chose. Mais qu'en est-il des métadonnées supplémentaires que vous souhaitez capturer pour lui donner encore plus de sens? Telles 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 des données de base et ces types de choses et les lier ensemble. Et comment l'information circule-t-elle dans l'organisation? Les données découlent de la façon dont elles sont consommées à la fois du point de vue du processus, mais aussi de la lignée de données en termes de parcours de l'information à travers nos entreprises et comment elle se déplace à travers les différents systèmes ou à travers les magasins de données, donc nous savons 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, très important, comment pouvons-nous faire en sorte que toutes ces parties prenantes collaborent, et en particulier les parties prenantes commerciales, car ce sont elles qui nous donnent le véritable sens de ces données. L'entreprise, à la fin de la journée, détient les données. Ils fournissent les définitions des vocabulaires et des choses dont Eric parlait, nous avons donc besoin d'un endroit pour lier tout cela ensemble. 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 où nous faisons la modélisation des données et ce genre de chose, mais il y a beaucoup d'autres composants de la suite que je vais aborder très brièvement. Vous verrez un extrait de Business Architect, où nous pouvons faire des modèles conceptuels, mais nous pouvons également faire des modèles de processus métier et nous pouvons lier ces modèles de processus pour relier 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 certaines modélisations UML et ces types de choses pour donner des logiques de support à certains de ces autres systèmes et processus dont nous parlons. Mais très important, alors que nous descendons, nous avons le référentiel et le serveur d'équipe, et je vais en parler comme 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 commerciales en termes de glossaires et de termes commerciaux. Et parce que nous avons cet environnement basé sur un référentiel, nous pouvons ensuite assembler toutes ces différentes choses dans ce même environnement et ensuite nous pouvons réellement les rendre disponibles pour les consommations, non seulement pour les techniciens mais aussi pour les hommes d'affaires. Et c'est ainsi que nous commençons vraiment à stimuler la collaboration.

Et puis la dernière pièce dont je parlerai brièvement est, lorsque vous entrez dans ces environnements, ce ne sont pas seulement les bases de données que vous avez là-bas. Vous allez avoir un certain nombre de bases de données, de magasins de données, vous allez également avoir beaucoup, ce que j'appellerais, des artefacts hérités. Peut-être que les gens ont 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 chose. Donc, ce que nous pouvons faire avec le MetaWizard est en fait d'extraire certaines 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é. Cela devient maintenant une partie active de nos modèles de travail, ce qui est très important.

Lorsque vous entrez dans une organisation, comme je l'ai dit, il y a beaucoup de systèmes disparates, beaucoup de 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 en externe, nous ne contrôlons donc pas les bases de données et ces types de choses sur les hôtes, mais nous devons toujours savoir à quoi ressemblent ces données et, bien sûr, les métadonnées autour de cela. Ce que nous trouvons également, c'est un grand nombre de systèmes hérités obsolètes qui n'ont pas été nettoyés en raison de l'approche basée sur les projets dont Malcolm avait parlé. C'est incroyable de voir comment ces dernières années, les organisations vont lancer des projets, elles vont remplacer un système ou une solution, mais il n'y a souvent pas assez de budget de projet pour déclasser les solutions obsolètes, alors maintenant elles sont juste sur le chemin. Et nous devons déterminer ce que nous pouvons réellement éliminer de notre environnement ainsi que ce qui est utile à l'avenir. Et cela est lié à la mauvaise stratégie de déclassement. Cela fait partie intégrante de cette même chose.

Ce que nous constatons également, parce que de nombreuses organisations ont été constituées à partir de toutes ces différentes solutions, c'est que nous voyons beaucoup d'interfaces point à point avec beaucoup de données se déplaçant à plusieurs endroits. Nous devons être en mesure de rationaliser cela et de comprendre la lignée de données que j'ai brièvement mentionnée précédemment afin que nous puissions avoir une stratégie plus cohérente telle que l'utilisation d'une architecture orientée services, des bus de services d'entreprise et ce genre de choses, pour fournir les informations correctes à un type de modèle de publication et d'abonnement que nous utilisons correctement dans l'ensemble de nos activités. Et puis, bien sûr, nous devons encore faire une sorte d'analyse, que nous utilisions des entrepôts de données, des data marts avec ETL traditionnel ou en utilisant certains des nouveaux lacs de données. Tout revient à la même chose. Ce sont toutes des données, qu'il s'agisse de mégadonnées, qu'il s'agisse 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 à quoi nous avons affaire dans nos modèles.

Encore une fois, la complexité que nous allons faire est que nous avons un certain nombre d'étapes que nous voulons pouvoir faire. Tout d'abord, vous entrez et vous n'avez peut-être pas ces plans de ce à quoi ressemble ce paysage de l'information. Dans un outil de modélisation de données comme ER / Studio Data Architect, vous allez d'abord faire beaucoup de rétro-ingénierie en termes de pointons les sources de données qui sont là-bas, apportez-les, puis assemblez-les en fait plus représentatives modèles qui représentent l'ensemble de l'entreprise. L'important est que nous voulons être en mesure de décomposer ces modèles également le long des lignes d'activité afin de pouvoir les relier en petits morceaux, auxquels nos gens d'affaires peuvent également se rapporter, et nos analystes commerciaux et autres parties prenantes qui travaillent dessus.

Les normes de dénomination sont extrêmement importantes et j'en parle ici de différentes manières. Normes de nommage en termes de la façon dont nous nommons les choses dans nos modèles. C'est assez facile à faire dans les modèles logiques, où nous avons une bonne convention de dénomination et un bon dictionnaire de données pour nos modèles, mais aussi, nous voyons différentes conventions de dénomination pour beaucoup de ces modèles physiques que nous introduisons. rétro-ingénierie, nous voyons assez souvent des noms abrégés et ce genre de chose dont je vais parler. Et nous devons les traduire en noms anglais significatifs qui sont significatifs pour l'entreprise afin que nous puissions comprendre quelles sont toutes ces données que nous avons 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 davantage et c'est là que nous pouvons classer nos données davantage avec quelque chose appelé Pièces jointes, sur lequel je vais vous montrer quelques diapositives. Et puis, en bouclant la boucle, nous voulons appliquer cette signification commerciale, qui est là où nous lions nos glossaires commerciaux et pouvons les lier à nos différents artefacts de modèle, donc nous savons, lorsque nous parlons d'un certain terme commercial, où c'est mis en œuvre dans nos données dans toute l'organisation. Et enfin, j'ai déjà parlé du fait que nous avons besoin que tout cela soit basé sur un référentiel avec beaucoup de capacités de collaboration et de publication, afin que nos parties prenantes puissent l'utiliser. Je vais parler de rétro-ingénierie assez rapidement. Je vous ai déjà en quelque sorte donné un aperçu très rapide de cela. Je vais vous le montrer dans une démo réelle juste pour vous montrer certaines des choses que nous pouvons y apporter.

Et je veux parler de certains des différents types de modèles et 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 y consacrer beaucoup de temps. Je veux vraiment parler des modèles logiques, des modèles physiques et des types spécialisés de modèles que nous pouvons créer. Et il est important que nous puissions les créer tous sur la même plateforme de modélisation afin de pouvoir les assembler. Cela inclut des modèles dimensionnels et également des modèles qui utilisent certaines des nouvelles sources de données, comme le NoSQL que je vais vous montrer. Et puis, à quoi ressemble le modèle de lignée de données? Et comment assembler ces données dans un modèle de processus métier, c'est de cela que nous parlerons ensuite.

Je vais passer à un environnement de modélisation ici juste pour vous donner un aperçu très rapide et très élevé. Et je pense que vous devriez pouvoir voir mon écran maintenant. Tout d'abord, je veux parler d'un type de modèle de données traditionnel. Et la façon dont nous voulons organiser les modèles lorsque nous les introduisons, c'est que nous voulons pouvoir les décomposer. Donc, ce que vous voyez ici sur le côté gauche, c'est que nous avons des modèles logiques et physiques dans ce fichier de modèle particulier. La prochaine chose est que nous pouvons le décomposer le long des décompositions professionnelles, c'est pourquoi vous voyez les dossiers. Les bleus clairs sont des modèles logiques et les verts sont des modèles physiques. Et nous pouvons également explorer, donc dans ER / Studio, si vous avez une décomposition commerciale, vous pouvez aller autant de niveaux profonds ou de sous-modèles que vous le souhaitez, et les modifications que vous apportez aux niveaux inférieurs se reflètent automatiquement au plus haut les niveaux. Il 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 également avoir plusieurs modèles physiques qui correspondent à 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 genre de chose. Peut-être que l'un est une instance SQL Server de celui-ci, peut-être un autre est une instance Oracle. Nous avons la capacité de lier tout cela ensemble dans le même environnement de modélisation. Et là encore, ce que j'ai ici est un véritable modèle d'entrepôt de données qui peut, encore une fois, être dans le même environnement de modélisation ou nous pouvons l'avoir dans le référentiel et le lier entre différentes choses également.

Ce que je voulais vraiment vous montrer à ce sujet, c'est quelques-unes des autres choses et d'autres variantes des modèles dans lesquels nous entrons. Donc, lorsque nous entrons dans un modèle de données traditionnel comme celui-ci, nous sommes habitués à voir les entités typiques avec les colonnes et les métadonnées et ce genre de chose, mais ce point de vue varie très rapidement lorsque nous commençons à traiter avec certaines de ces nouvelles technologies NoSQL, ou comme certains aiment encore les appeler, les technologies du Big Data.

Alors maintenant, disons que nous avons également Hive dans notre environnement. Si nous effectuons une rétro-ingénierie à partir d'un environnement Hive - et nous pouvons transférer et inverser l'ingénierie à partir de Hive avec ce même outil de modélisation - nous voyons quelque chose qui est un peu différent. Nous voyons toujours toutes les données comme des constructions là-bas, mais nos TDL sont différents. 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 avec le 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 tout aussi important, dans le scénario que j'ai décrit, vous pouvez tout désosser et le comprendre et commencer à l'assembler également .

Prenons un autre qui est un peu différent. MongoDB est une autre plate-forme que nous prenons en charge de manière native. Et lorsque vous commencez à entrer dans les types d'environnements JSON où vous avez des magasins de documents, JSON est un animal différent et il y a des constructions qui ne correspondent pas aux modèles relationnels. Vous commencez bientôt à traiter des concepts tels que les objets intégrés et les tableaux d'objets intégrés lorsque vous commencez à interroger le JSON et ces concepts n'existent pas dans la notation relationnelle traditionnelle. Ce que nous avons fait ici, c'est que nous avons en fait é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 intégrés. Et nous montrons différentes cardinalités. La cardinalité du diamant signifie que c'est un objet à une extrémité, mais la cardinalité de l'un signifie que nous avons, au sein de l'éditeur si nous suivons cette relation, nous avons un objet d'adresse intégré. En interrogeant le JSON, nous avons constaté que c'est exactement la même structure d'objets qui est intégrée dans le lecteur, mais qui est en fait intégrée comme un tableau d'objets. Nous le voyons, non seulement à travers les connecteurs eux-mêmes, mais si vous regardez les entités réelles, vous verrez que vous voyez des adresses sous le patron qui le classent également 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, maintenant ce que nous avons vu jusqu'à présent en quelques secondes est des modèles relationnels traditionnels qui sont à 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 comme bien. Ce que nous pouvons aussi faire, et je vais vous montrer très rapidement, c'est que j'ai parlé du fait de faire venir des choses d'autres domaines. Je vais supposer que je vais importer un modèle à partir d'une base de données ou le rétroconcevoir, mais je vais l'intégrer à partir de métadonnées externes. Juste pour vous donner un point de vue très rapide sur tous les différents types de choses que nous pouvons commencer à apporter.

Comme vous le voyez, nous avons une myriade d'éléments avec lesquels nous pouvons réellement intégrer les métadonnées dans notre environnement de modélisation. En commençant par des choses comme Amazon Redshift, Cassandra, beaucoup d'autres plates-formes de Big Data, vous en voyez donc beaucoup répertoriées. C'est par ordre alphabétique. Nous voyons beaucoup de sources de Big Data et ce genre de choses. Nous voyons également beaucoup d'environnements de modélisation traditionnels ou plus anciens que nous pouvons réellement utiliser ces métadonnées. Si je passe par ici - et je ne vais pas passer du temps sur chacun d'eux - nous voyons beaucoup de choses différentes que nous pouvons en tirer, en termes de plates-formes de modélisation et de plates-formes de données. Et quelque chose qui est très important à réaliser ici est une autre partie que nous pouvons faire lorsque nous commençons à parler de lignée de données, sur Enterprise Team Edition, nous pouvons également interroger les sources ETL, que ce soit des mappages Talend ou SQL Server Information Services, nous pouvons en fait, apportez cela pour commencer également nos diagrammes de lignage de données et dessiner une image de ce qui se passe dans ces transformations. Au départ, nous avons plus de 130 de ces ponts différents qui font en fait partie du produit Enterprise Team Edition, donc cela nous aide vraiment à rassembler tous les artefacts dans un environnement de modélisation très rapidement.

Enfin et surtout, 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 faisons de l'entreposage de données ou tout type d'analyse. Nous voulons toujours avoir la possibilité de faire des choses comme des modèles dimensionnels où nous avons des tables de faits et nous avons des dimensions et ce genre de choses. Je veux également vous montrer que nous pouvons également avoir des extensions de nos métadonnées qui nous aident à classer les types de dimensions et tout le reste. Donc, si je regarde l'onglet des données dimensionnelles ici, par exemple, sur l'un d'entre 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 que c'est une dimension ou un table de faits. Mais au-delà de cela, ce que nous pouvons faire est dans les dimensions et ce type de chose, nous avons même différents types de dimensions que nous pouvons utiliser pour classer les données dans un environnement de type entrepôt de données. Des capacités tellement puissantes avec lesquelles nous assemblons tout cela.

Je vais sauter dans celui-ci puisque je suis dans l'environnement de démonstration en ce moment et vous montrer quelques autres choses avant de revenir aux diapositives. L'une des choses que nous avons récemment ajoutées à ER / Studio Data Architect est que nous avons rencontré des situations - et c'est un cas d'utilisation très courant lorsque vous travaillez sur des projets - les développeurs pensent en termes d'objets, tandis que nos données les modélisateurs ont tendance à penser en termes de tables et d'entités et de ce genre de choses. Il s'agit d'un modèle de données très simpliste, mais il représente quelques concepts de base, où les développeurs ou même les analystes commerciaux ou les utilisateurs commerciaux peuvent les considérer comme des objets ou des concepts commerciaux différents. Il a été très difficile de les classer jusqu'à présent, mais ce que nous avons réellement fait dans ER / Studio Enterprise Team Edition, dans la version 2016, c'est que nous avons maintenant un concept appelé Business Data Objects. Et ce que cela nous permet de faire, c'est de nous permettre d'encapsuler des groupes d'entités ou de tables dans de véritables objets métier.

Par exemple, ce que nous avons ici dans cette nouvelle vue, c'est que l'en-tête du bon de commande et la ligne de commande ont été rassemblés maintenant, ils sont encapsulés comme un objet, nous les considérerions comme une unité de travail lorsque nous persistons les données, et nous les réunissons, il est donc très facile de relier cela à différents publics. Ils sont réutilisables dans tout l'environnement de modélisation. Ils sont un véritable objet, pas seulement une construction de dessin, mais nous avons également l'avantage supplémentaire que lorsque nous communiquons réellement du point de vue 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 pour les dialogues avec certains publics de parties prenantes, et nous pouvons également, bien sûr, conserver une vue plus détaillée comme celle que nous voyons ici pour un plus grand nombre de publics techniques. Cela nous donne vraiment un très bon véhicule de communication. Ce que nous voyons maintenant est de combiner plusieurs types de modèles différents, en les augmentant avec le concept d'objets de données métier, et maintenant je vais parler de la façon dont nous appliquons un peu plus de sens à ces types de choses et comment nous les assemblons dans notre environnements globaux.

J'essaie simplement de retrouver mon WebEx ici afin de pouvoir le faire. Et voilà, revenons aux diapositives Hot Tech. Je vais juste avancer rapidement quelques diapositives ici parce que vous les avez déjà vues dans la démonstration du modèle lui-même. Je veux parler des normes de dénomination très rapidement. Nous voulons appliquer et faire respecter différentes normes de dénomination. Ce que nous voulons faire, c'est que nous avons la possibilité de stocker réellement des modèles de normes de dénomination dans nos référentiels pour construire essentiellement cette signification à travers, à travers des mots ou des expressions ou même des abréviations, et les lier à un type de mot anglais significatif. Nous allons utiliser des termes commerciaux, les abréviations de chacun, et nous pouvons spécifier l'ordre, les cas et ajouter des préfixes et suffixes. Le cas d'utilisation typique pour cela est généralement lorsque les gens ont construit un modèle logique et ont ensuite réellement avancé pour créer un modèle physique où ils auraient pu utiliser des abréviations et tout le reste.

La belle chose est qu'elle est tout aussi puissante, encore plus puissante à l'envers, si nous pouvons simplement dire quelles étaient ces normes de dénomination sur certaines de ces bases de données physiques que nous avons rétroconçues, nous pouvons prendre ces abréviations, les transformer en plus longues mots, et les ramener en phrases anglaises. En fait, nous pouvons maintenant dériver des noms propres à quoi ressemblent nos données. Comme je l'ai dit, le cas d'utilisation typique est que nous irions de l'avant, de la logique au physique, et cartographierions les magasins de données et ce genre de choses. Si vous regardez la capture d'écran sur le côté droit, vous verrez qu'il y a des noms abrégés des noms source et lorsque nous avons appliqué un modèle de normes de nommage, nous avons en fait plus de noms complets. Et nous pourrions mettre des espaces et tout comme ça si nous le voulons, selon le modèle de normes de nommage que nous avons utilisé. Nous pouvons lui donner l'apparence que nous voulons qu'il apporte à nos modèles. Ce n'est que lorsque nous savons comment quelque chose s'appelle que nous pouvons réellement commencer à y attacher des définitions, parce que si nous ne savons pas ce que c'est, comment pouvons-nous lui appliquer 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é d'ingénierie inverse, nous pouvons en fait invoquer des modèles de normes de dénomination simultanément lorsque nous faisons de l'ingénierie inverse. Donc, en une seule étape à travers un assistant, ce que nous pouvons faire, c'est que si nous savons quelles sont les conventions, nous pouvons inverser l'ingénierie d'une base de données physique, cela va la ramener en tant que modèles physiques dans un environnement de modélisation et c'est va également appliquer ces conventions de dénomination. 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éma XML afin que nous puissions prendre un modèle et même le pousser avec nos abréviations, que nous fassions des frameworks SOA ou ce genre de chose, afin que nous puissions ensuite également pousser différentes conventions de dénomination que nous avons effectivement stocké 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 dénomination. Je peux également les appliquer pour les faire fonctionner de manière interactive pendant que je construis des modèles et que je mets les choses en place. Si j'utilisais cette abréviation et que je tapais «Plan de salaire 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 pendant que je créais les entités et m'aurait donné tout de suite les noms physiques correspondants.

Encore une fois, très bon pour la conception et l'ingénierie avancée. Nous avons un concept très unique et c'est là que nous commençons vraiment à rapprocher ces environnements. Et cela s'appelle Universal Mappings. Une fois que nous avons apporté tous ces modèles dans notre environnement, ce que nous pouvons faire, en supposant que nous avons maintenant appliqué ces conventions de dénomination et qu'elles sont faciles à trouver, nous pouvons maintenant utiliser une construction appelée Universal Mappings dans ER /Studio. Nous pouvons relier des entités à travers des modèles. Partout où nous voyons «client» - nous aurons probablement «client» dans beaucoup de systèmes différents et beaucoup de bases de données différentes - nous pouvons commencer à lier tous ces éléments de sorte que lorsque je travaille avec lui dans un modèle, je peut voir où sont les manifestations des clients dans les autres modèles. Et parce que nous avons la couche de modèle qui représente cela, nous pouvons même la lier à des sources de données et la ramener à nos enquêtes sur l'utilisation des bases de données dans lesquelles elles résident également. Cela nous donne vraiment la possibilité de lier tout cela de manière très cohérente.

Je vous ai montré les objets de données métiers. Je veux également parler des extensions de métadonnées, que nous appelons 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 pour générer beaucoup de choses différentes du point de vue de la gouvernance des données et de la qualité des données, ainsi que pour nous aider à gérer les politiques de gestion et de conservation des données. L'idée de base est de créer ces classifications et de les attacher où vous le souhaitez, au niveau de la table, au niveau de la colonne, ce genre de choses. Le cas d'utilisation le plus courant, bien sûr, est que les entités sont des tables, puis 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 transactionnelles? Du point de vue de la qualité des données, je peux faire des classifications en termes d'importance pour l'entreprise afin que nous puissions hiérarchiser les efforts de nettoyage des données et ce genre de choses.

Quelque chose qui est souvent négligé est, 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'information de notre environnement de modélisation et, bien sûr, de notre référentiel également. La beauté est que ces pièces jointes sont présentes dans notre dictionnaire de données, donc lorsque nous utilisons des dictionnaires de données d'entreprise dans l'environnement, nous pouvons les attacher à plusieurs modèles. Nous n'avons qu'à les définir une fois et nous pouvons les exploiter encore et encore à travers 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 lorsque vous effectuez une pièce jointe, quelles sont toutes les pièces auxquelles vous souhaitez l'attacher. Et cet exemple ici est en fait une liste de valeurs, donc quand ils vont, vous pouvez choisir dans une liste de valeurs, vous avez beaucoup de contrôle dans l'environnement de modélisation de ce qui est sélectionné, et vous pouvez même définir ce que la valeur par défaut la valeur est si aucune valeur n'est 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 le type de pièces jointes qui apparaît 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é, classifications de sécurité des données, nous en expédions un certain nombre prêts à l'emploi 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 là-bas. Et vous pouvez vraiment commencer à créer 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 souvent des dictionnaires de données là-bas que très souvent une organisation utilise comme point de départ pour commencer à publier des 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, les utiliser comme point de départ pour publier des glossaires, mais nous voulons vraiment que l'entreprise en soit propriétaire. Ce que nous avons fait dans l'environnement de serveur d'équipe, c'est que nous avons donné aux utilisateurs la possibilité de créer des définitions d'entreprise, puis nous pouvons les lier aux différents artefacts de modèle auxquels ils correspondent également dans l'environnement de modélisation. Nous reconnaissons également le point qui a été discuté précédemment, à savoir que plus vous avez de personnes à taper, plus il y a de risques d'erreur humaine. Ce que nous faisons également dans notre structure de glossaire, c'est que nous prenons en charge une hiérarchie de glossaire, nous pouvons donc avoir différents types de glossaire ou différents types de choses dans l'organisation, mais tout aussi important, c'est si vous avez déjà certaines de ces sources là-bas avec les termes et tout ce qui est défini, nous pouvons réellement faire une importation 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 est modifié, il existe une piste d'audit complète de ce qu'étaient les images avant et après, en termes de définitions et de tout le reste, et ce que vous allez voir arriver dans un avenir très proche est également plus un flux de travail d'autorisation afin que nous puissions vraiment contrôler qui en est responsable, les approbations par les comités ou les individus, et ce genre de choses, pour rendre le processus de gouvernance encore plus robuste à l'avenir.

Ce que cela fait aussi pour nous, c'est lorsque nous avons ces termes de glossaire dans notre glossaire de serveur d'équipe, c'est un exemple de modification dans une entité du modèle lui-même que j'ai présenté ici. Il peut y avoir des termes liés, mais ce que nous faisons également, c'est s'il y a des mots dans ce glossaire qui apparaissent dans les notes ou les descriptions de ce que nous avons dans nos entités ici, ceux-ci sont automatiquement affichés dans une couleur hyperliée plus claire, et si nous passez la souris dessus, nous pouvons également voir la définition dans le glossaire de l'entreprise. Cela nous donne même des informations plus riches lorsque nous consommons les informations elles-mêmes, avec tous les termes du glossaire qui existent. Cela aide vraiment à enrichir l'expérience et à appliquer le sens à tout ce avec quoi nous travaillons.

Donc, encore une fois, ce fut un survol très rapide. Évidemment, nous pourrions passer des jours à ce sujet pendant que nous explorons les différentes parties, mais c'est un survol très rapide sur la surface. Ce que nous nous efforçons vraiment de faire, c'est de comprendre à quoi ressemblent ces environnements de données complexes. Nous voulons 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 ce sont tous les types de données dont nous parlons, qu'il s'agisse de mégadonnées, de données relationnelles traditionnelles, de magasins de documents ou de toute autre chose. Et encore une fois, nous y sommes parvenus parce que nous disposons de puissantes capacités d'ingénierie avant et arrière pour les différentes plates-formes et les autres outils que vous pourriez avoir. Et il s'agit de partager et de communiquer à travers l'organisation avec toutes les parties prenantes impliquées. C'est là que nous appliquons le sens à travers des normes de dénomination. Nous appliquons ensuite les définitions dans nos glossaires commerciaux. Et puis nous pouvons effectuer d'autres classifications pour toutes nos autres capacité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 de base ou tout autre type de classifications que vous souhaitez appliquer à ces données. Ensuite, nous pouvons résumer davantage et améliorer encore la communication avec les objets de données métier, avec les différents publics des parties prenantes, en particulier entre les modélisateurs et les développeurs.

Et encore une fois, ce qui est très important à ce sujet, c'est que derrière tout cela se trouve un référentiel intégré avec des capacités de gestion des changements très robustes. Je n'ai pas eu le temps de le montrer aujourd'hui car il devient assez complexe, mais le référentiel possède des capacités de gestion des changements et des pistes d'audit très robustes. Vous pouvez faire des versions nommées, vous pouvez faire des versions nommées, et nous avons également la capacité pour ceux d'entre vous qui font de la gestion des changements, nous pouvons lier cela directement à vos tâches. Nous avons aujourd'hui la possibilité de placer des tâches et d'associer vos modifications de modèle à des tâches, tout comme les développeurs associeraient leurs modifications de code aux tâches ou aux user stories avec lesquelles ils travaillent également.

Encore une fois, c'était un aperçu très rapide. J'espère que cela a été suffisant pour vous mettre en appétit afin que nous puissions engager des conversations beaucoup plus approfondies sur la répartition de certains de ces sujets au fur et à mesure que nous progressons. Merci de votre temps et retour à vous, Rebecca.

Rebecca Jozwiak: Merci, Ron, c'était fantastique et j'ai pas mal de questions de la part du public, mais je veux donner à nos analystes une chance de mordre dans ce que vous avez à dire. Eric, je vais continuer 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: Bien 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 d'abord posé des questions à Ron. Si vous voulez lui demander maintenant de répondre à l'une de ces questions, ou à certaines d'entre elles sur votre diapositive ou à tout autre élément qui a suscité votre intérêt et que vous souhaitez poser? À propos des fonctionnalités de modélisation d'IDERA.

Eric Little: Oui, donc l'une des choses, Ron, alors comment les gars, il semble que les diagrammes que vous montriez sont des types généraux de diagrammes de relation d'entité comme vous utiliseriez normalement dans la construction d'une base de données, n'est-ce pas?

Ron Huizenga: Oui, d'une manière générale, mais bien sûr, nous avons les types étendus pour les magasins de documents et ce genre de choses également. Nous avons en fait varié de la notation relationnelle pure, nous avons également ajouté des notations supplémentaires pour ces autres magasins.

Eric Little: Existe - t-il un moyen d'utiliser les types de modélisation basés sur des graphiques, donc y a-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 à Protégé ou, vous savez, comme les gars de la finance à FIBO, ils font beaucoup de travail en sémantique, RDF - est-il un moyen d'intégrer ce type de modélisation de type de graphique entité-relation dans cet outil, et d'utiliser il?

Ron Huizenga: Nous cherchons actuellement à savoir comment gérer les graphiques. Nous ne gérons pas explicitement les bases de données graphiques et ce genre de choses aujourd'hui, mais nous cherchons des moyens de le faire pour étendre nos métadonnées. Je veux dire, nous pouvons apporter des choses via XML et ce genre de choses en ce moment, si nous pouvons au moins faire une sorte de rendu de XML pour l'introduire comme point de départ. Mais nous cherchons des moyens plus élégants de faire cela.

Et je vous ai également montré cette liste de ponts de rétro-ingénierie que nous avons également, donc nous cherchons toujours à obtenir des extensions de ces ponts pour des plates-formes spécifiques. C'est un effort continu et continu, si cela a du sens, de commencer à adopter un grand nombre de ces nouvelles constructions et des différentes plates-formes. Mais je peux dire que nous sommes définitivement à l'avant-garde dans ce domaine. Les choses que j'ai montrées, par exemple, MongoDB et ce genre de choses, nous sommes le premier fournisseur de modélisation de données à le faire de manière native dans notre propre produit.

Eric Little: D'accord, oui. Donc, l'autre question que j'avais pour vous, alors, concernait la gouvernance et le maintien de - comme lorsque vous avez utilisé l'exemple, lorsque vous avez montré l'exemple de la personne qui est un «employé», je crois que c'était un « salaire "et puis vous avez un" plan ", est-il possible, comment gérez-vous, par exemple, différents types de personnes qui peuvent avoir - supposons que vous avez une grande architecture, à droite, supposons que vous avez une grande entreprise et les gens commencent à rassembler les choses dans cet outil et vous avez un groupe ici qui a le mot «employé» et un groupe ici qui a le mot «travailleur». Et une personne ici dit «salaire» et une autre personne dit "salaire."

Comment conciliez-vous, gérez-vous et régissez-vous ce genre de distinctions? Parce que je sais comment nous le ferions dans le monde des graphes, vous savez, vous utiliseriez des listes de synonymes ou vous diriez qu'il y a un concept et il a plusieurs attributs, ou vous pourriez dire dans le modèle SKOS j'ai une étiquette préférée et j'ai de nombreuses étiquettes alternatives que je peux utiliser. Comment faites-vous ça?

Ron Huizenga: Nous le faisons de différentes manières, et parlons d'abord de la terminologie. Naturellement, nous voulons notamment avoir des termes définis ou sanctionnés et, dans le glossaire des affaires, c'est évidemment là où nous les voulons. Et nous autorisons également des liens vers des synonymes dans le glossaire de l'entreprise.Vous pouvez donc dire, voici mon terme, mais vous pouvez également définir tous les synonymes de ceux-ci.

Maintenant, la chose intéressante, bien sûr, c'est quand vous commencez à regarder à travers ce vaste paysage de données avec tous ces différents systèmes que vous avez là-bas, vous ne pouvez pas simplement aller là-bas et changer les tables correspondantes et ces types de choses en correspondent à 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 ou quoi que ce soit.

Ce que nous pourrions faire là-bas, en plus de pouvoir associer les définitions du glossaire, c'est à travers les mappages universels dont j'ai parlé, ce que nous ferions, et une sorte d'approche recommandée, c'est d'avoir un modèle logique global qui définit ce que ces différents concepts commerciaux sont ce dont vous parlez. Liez les termes du glossaire métier à ceux-ci, et la bonne chose est maintenant que vous avez cette construction qui représente une entité logique pour ainsi dire, vous pouvez ensuite commencer à établir un lien entre cette entité logique et 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» ici est appelée «employé» dans ce système. Ici, le «salaire» est appelé «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 ensemble.

Eric Little: Très bien, oui, je comprends. En ce sens, est-il sûr de dire que c'est un peu comme certaines des approches orientées objet?

Ron Huizenga: Un peu. C'est un peu plus intensif que, je suppose que vous pourriez dire. Je veux dire, vous pouvez adopter l'approche consistant à lier et à parcourir manuellement et à inspecter et à faire tous également. La seule chose dont je n'ai pas vraiment eu l'occasion de parler - car encore une fois, nous avons beaucoup de capacités - nous avons également une interface d'automatisation complète dans l'outil Data Architect lui-même. Et une fonction macro, qui est vraiment un langage de programmation dans l'outil. Nous pouvons donc faire des choses comme écrire des macros, les faire sortir et interroger des choses et créer des liens pour vous. Nous l'utilisons pour importer et exporter des informations, nous pouvons l'utiliser pour changer des choses ou ajouter des attributs, un événement basé sur le modèle lui-même, ou nous pouvons l'utiliser pour exécuter par lots pour réellement sortir et interroger des choses et réellement remplir différentes constructions dans le modèle. Il existe donc une interface d'automatisation complète dont les utilisateurs peuvent également profiter. Et utiliser les mappages universels avec ceux-ci serait un moyen très puissant de le faire.

Rebecca Jozwiak: D'accord, merci Ron et merci Eric. C'étaient de grandes questions. Je sais que nous courons un peu après le début de l'heure, mais j'aimerais donner à Malcolm une chance de poser quelques questions à la manière de Ron. Malcolm?

Malcolm Chisholm: Merci, Rebecca. Donc, Ron, c'est très intéressant, je vois qu'il y a beaucoup de capacités ici. L'un des domaines qui m'intéresse beaucoup est, disons, si nous avons un projet de développement, comment voyez-vous le modélisateur de données utiliser ces capacités et travailler peut-être plus en collaboration avec les analystes commerciaux, avec un profileur de données, avec un analyste de la qualité des données et avec les sponsors commerciaux qui seront en fin de compte responsables des besoins réels en informations du projet. Comment le modélisateur de données rend-il vraiment, vous le savez, le projet plus efficace et efficient avec les capacités que nous examinons?

Ron Huizenga: Je pense que l'une des premières choses que vous devez faire est en tant que modélisateur de données - et je ne veux pas m'attarder sur certains des modélisateurs, mais je le ferai quand même - est que certains ont toujours l'impression que le modeleur de données est vraiment le type de rôle de contrôleur d'accès, nous définissons comment cela fonctionne, nous sommes les gardiens qui s'assurent que tout est correct.

Maintenant, il y a un aspect à cela, que vous devez vous assurer que vous définissez une architecture de données saine et tout le reste. Mais la chose la plus importante est en tant que modélisateur de données - et j'ai trouvé cela assez évident lorsque je consultais - est que vous devez devenir un facilitateur, donc vous devez rassembler ces personnes.

Cela ne va plus être une conception à l'avance, générer, construire des bases de données - ce que vous devez pouvoir faire, c'est que vous devez pouvoir travailler avec tous ces différents groupes de parties prenantes, faire des choses comme la rétro-ingénierie, importer des informations, avoir d'autres personnes collaborent, que ce soit sur les glossaires ou la documentation, tout comme ça - et soyez un facilitateur pour tirer cela dans le référentiel, relier les concepts ensemble dans le référentiel et travailler avec ces personnes.

C'est vraiment beaucoup plus un environnement collaboratif où même par la définition de tâches ou même de fils de discussion ou ce genre de choses que nous avons dans le serveur d'équipe, les gens peuvent réellement collaborer, poser des questions et arriver aux produits finaux finaux qu'ils 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 de facilitation est quelque chose de très souhaitable dans les modélisateurs de données. Je suis d'accord que nous ne voyons pas toujours cela, mais je pense que c'est nécessaire et je dirais qu'il y a parfois une tendance à rester dans votre coin pour faire votre modélisation de données, mais vous devez vraiment être là-bas pour 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 de la façon dont les entreprises se sont détournées de l'informatique parce qu'elles ne fournissaient pas les solutions en temps opportun et ce genre de choses.

Il est très intéressant de noter que dans mes missions de conseil ultérieures, avant de devenir chef de produit, la plupart des projets que j'avais réalisés au cours des deux dernières années auparavant étaient parrainés par des entreprises, où c'était vraiment l'entreprise qui les dirigeait et les architectes de données. et les modélisateurs ne faisaient pas partie de l'informatique. Nous faisions partie d'un groupe parrainé par des entreprises et nous étions là en tant que facilitateurs travaillant avec le reste des équipes de projet.

Malcolm Chisholm: Je pense donc que c'est un point très intéressant. Je pense que nous commençons à voir un changement dans le monde des affaires où l'entreprise demande, ou pense peut-être, pas tant que ce que je fais, comme un processus, mais ils commencent également à réfléchir à ce que sont les données avec lesquelles je travaille, quels sont mes besoins en matière de données, quelles sont les données que je traite en tant que données, et dans quelle mesure pouvons-nous obtenir des produits et des capacités IDERA pour soutenir 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 voyons cela de plus en plus de cette façon. Nous avons vu un réveil et vous en avez parlé plus tôt en termes d'importance des données. Nous avons vu l'importance des données tôt dans l'informatique ou dans l'évolution des bases de données, puis comme vous le dites, nous nous sommes lancés dans ce cycle de gestion des processus - et le processus est extrêmement important, ne vous méprenez pas - mais maintenant ce qui s'est passé c'est quand cela s'est produit, les données ont perdu le focus.

Et maintenant, les organisations se rendent compte que les données sont vraiment le point focal. Les données représentent tout ce que nous faisons dans notre entreprise, nous devons donc nous assurer que nous avons des données précises, que nous pouvons trouver les informations correctes dont nous avons besoin pour prendre nos décisions. Parce que tout ne vient pas d'un processus défini. Certaines informations sont un sous-produit d'autres choses et nous devons toujours être en mesure de les trouver, savoir ce qu'elles signifient et être en mesure de traduire les données que nous y voyons en fin de compte en connaissances que nous pouvons utiliser pour mieux conduire nos entreprises.

Malcolm Chisholm: D' accord, et maintenant un autre domaine avec lequel je me bats est ce que j'appellerais le cycle de vie des données qui est, vous savez, si nous regardons le type de chaîne d'approvisionnement de données traversant une entreprise, nous commencerions par acquisition de données ou capture de données, ce qui pourrait être la saisie de données, mais il se pourrait également que je reçoive des données de l'extérieur de l'entreprise auprès d'un fournisseur de données.

Et puis de la capture de données, nous allons à la maintenance des données où je pense à standardiser ces données et à les envoyer aux endroits où elles sont nécessaires. Et puis l'utilisation des données, les points réels où se trouvent les données, vous allez obtenir de la valeur des données.

Et dans le passé, tout cela se faisait dans un style individuel, mais aujourd'hui, cela pourrait être, vous savez, un environnement d'analyse, par exemple, puis au-delà, une archive, un magasin, où nous mettons les données lorsque nous ne sommes plus besoin et enfin un type de processus de purge. Comment voyez-vous la modélisation des données s'intégrer dans la gestion de l'ensemble de ce cycle de vie des données?

Ron Huizenga: C'est une très bonne question et une chose sur laquelle je n'ai vraiment pas eu le temps de me plonger dans les détails ici aujourd'hui, c'est ce dont nous commençons vraiment à parler, c'est la lignée des données. Donc, ce que nous pouvons réellement faire, c'est que nous avons une capacité de lignée de données dans nos outils et, comme je le dis, nous pouvons en extraire une partie à partir des outils ETL, mais vous pouvez également la cartographier simplement en dessinant la lignée. 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 lignée de données.

Ce que nous pouvons faire, c'est dessiner un flux de données, comme vous le dites, de la source à la cible, et à travers le cycle de vie global de la façon dont ces données transitent à travers les différents systèmes et ce que vous allez trouver, prenons les employés 'données - 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 là-bas - et Rebecca a fait apparaître la diapositive de lignage des données - c'est une diapositive de lignage des données assez simpliste ici, mais ce que nous avons pu faire était d'apporter toutes les structures de données, de 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 ensemble 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'entreprise de cette suite et la même chose s'applique là-bas.

N'importe laquelle des structures de données que nous avons capturées dans l'environnement de modélisation des données, celles-ci peuvent être référencées dans l'outil de modélisation métier de sorte que 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 souhaitez sortir de 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 sur ceux-ci, sur la façon dont ces informations sont consommées ou produites, puis nous pouvons commencer à générer des choses comme des rapports d'impact et d'analyse et des diagrammes à partir de cela.

Ce que nous visons à atteindre, et nous avons déjà beaucoup de capacités, mais l'une des choses que nous avons en quelque sorte comme un poteau de but que nous examinons, alors que nous continuons à faire évoluer nos outils à l'avenir, est en mesure de cartographier cette lignée de données organisationnelles de bout en bout et le cycle de vie complet des données.

Malcolm Chisholm: D'accord. Rebecca, ai-je droit à un autre?

Rebecca Jozwiak: Je vous en permettrai un de plus, Malcolm, allez-y.

Malcolm Chisholm: Merci beaucoup. En pensant à la gouvernance des données et en pensant à la modélisation des données, comment faire en sorte que ces deux groupes travaillent efficacement ensemble et se comprennent?

Eric Little: Eh bien, 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 l'entreprise, nous étions étroitement liés. Par exemple, je dirigeais une architecture de données mais nous étions étroitement liés aux utilisateurs professionnels et nous les aidions en fait à mettre en place leur programme de gouvernance des données. Encore une fois, c'est plus une approche consultative, mais c'est vraiment plus une fonction commerciale.

Ce dont vous avez vraiment besoin pour y parvenir, c'est que vous ayez besoin de modélisateurs de données et d'architectes qui comprennent vraiment les affaires, puissent établir des relations avec les utilisateurs métier et les ont ensuite aidés à mettre en place les processus de gouvernance qui les entourent. L'entreprise veut le faire, mais d'une manière générale, nous avons les connaissances technologiques pour être en mesure de les aider à se démarquer de ces types de programmes. Il faut vraiment que ce soit une collaboration, mais il faut que ce soit une entreprise.

Malcolm Chisholm: D'accord, c'est super. Je vous remercie.

Dr Eric Little: D'accord.

Rebecca Jozwiak: D'accord, merci beaucoup. Chers membres du public, je crains que nous n'ayons pas répondu à vos questions, mais je m'assurerai qu'elles soient transmises à l'invité approprié que nous avions en ligne aujourd'hui. Je tiens à remercier infiniment Eric, Malcolm et Ron d'être nos invités aujourd'hui. C'était génial, les amis. Et si vous avez apprécié la webdiffusion IDERA d'aujourd'hui, IDERA sera également sur une Hot Technologies mercredi prochain si vous voulez vous joindre, discutant des défis de l'indexation et d'Oracles, donc un autre sujet fascinant.

Merci beaucoup, les amis, faites attention, et nous vous verrons la prochaine fois. Bye Bye.