À emporter: Eric Kavanagh, animateur, explique l'importance de la modélisation des données dans le développement agile avec Robin Bloor, Dez Blanchfield et Ron Huizenga d'IDERA.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Eric Kavanagh: Ok, mesdames et messieurs. Bienvenue encore une fois. C'est mercredi à 4h00 EST. Cela signifie que son heure pour Hot Technologies. Oui en effet. Je m'appelle Eric Kavanagh, je serai votre hôte.
Pour le sujet d'aujourd'hui, c'est un vieux mais un goodie. Il s'améliore chaque jour, car il façonne notre monde de la gestion de données, intitulé «Modélisation des données dans un environnement agile». Une diapositive à propos de la vôtre vraiment, lancez-moi sur @eric_kavanagh. Nous devrions vraiment le mettre sur cette diapositive. Je vais devoir continuer là-dessus.
Alors les années sont chaudes. La modélisation des données existe depuis toujours. C’est au cœur de l’activité de gestion de l’information, de la conception de modèles de données, de la compréhension de ces derniers et de leur alignement sur vos modèles de données. Cest vraiment ce que vous essayez de faire, non?
Le modèle de données représente l'entreprise de manière fondamentale. Comment toutes ces nouvelles sources de données changent-elles le jeu? Allions découvrir à ce sujet. Allaient découvrir comment vous pouvez rester au courant des choses de manière agile. Et bien sûr, c'est le mot de l'année.
Robin Bloors avec nous, notre analyste en chef, Dez Blanchfield de Sydney, en Australie, et Ron Huizenga, chef de produit principal chez IDERA - un ami de longue date, un excellent orateur dans ce domaine, connaît son travail, alors ne soyez pas timide, demandez-lui le des questions difficiles, les gens, les difficiles. Sur ce, je vais faire de Robin la présentatrice et l’emporter.
Dr Robin Bloor: D'accord. Bien merci pour ça, Eric. Je dois dire à propos de la modélisation que, je pense, j’étais dans le monde de l’informatique avant qu’elle n’existe, dans la mesure où je me souviens de la compagnie d’assurance pour laquelle je travaillais, que nous avions un type qui venait nous donner à tous d'atelier sur la modélisation des données. Alors regardions-nous environ 30 ans, est-ce 30 ans? Peut-être même plus longtemps que cela, peut-être il y a 35 ans. La modélisation a longtemps fait partie de l'industrie et, bien entendu, elle n'a rien à voir avec les femmes sur les podiums.
Ce que je voulais dire, parce que ce que nous faisons normalement, c’est que Dez et moi parlons de choses différentes et je pensais juste que je donnerais un aperçu général de la modélisation, mais il ya une réalité à cela, qui devient maintenant apparente.
Vous avez, vous savez, la réalité des données volumineuses, nous avons plus de données, plus de sources de données, nous avons des flux de données qui sont entrés dans l’équation au cours des trois ou quatre dernières années et commencent à en obtenir une plus grande part, et Un plus grand besoin de comprendre les données et une augmentation du taux de changement, c'est-à-dire que davantage de données sont ajoutées et que plus de structures de données sont utilisées.
C’est un monde difficile. Voici une image de ce que nous avons dessiné il y a environ trois ans. En gros, une fois que vous incluez la diffusion en continu dans le mix, vous obtenez cette idée de raffinerie de données, de concentrateur de données, de liaison de données ou autre, vous constatez qu'il existe des données. véritablement au repos, dans le sens où il ne bouge pas beaucoup. Et puis il y a les données, les flux et vous avez toutes les applications transactionnelles, et de nos jours, vous avez des événements, des flux de données d'événements qui se produisent dans les applications et peuvent nécessiter, et de nos jours, les architectures lambda dont tout le monde parle, ont réellement un impact sur juste tout le champ de données.
Et de nos jours, pensez à une couche de données. La couche de données existe de manière virtuelle, dans la mesure où une bonne partie de celle-ci pourrait se trouver dans le nuage et qu'elle peut être répartie dans des centres de données, et peut exister sur des postes de travail. La couche de données est, dans une certaine mesure, omniprésente et, dans ce sens, il existe partout des processus qui tentent d’une manière ou d’une autre de traiter les données et de les déplacer. Mais savoir ce que c'est quand vous le déplacez est un gros problème.
Si nous examinons la modélisation des données au sens le plus général, vous trouverez au bas de ce type de pile des fichiers et des bases de données. Vous avez des éléments de données, qui ont des clés, des définitions d'éléments, des alias, des synonymes, des formats physiques spécifiques, puis nous avons cette couche de métadonnées.
La chose intéressante à propos des métadonnées est que les métadonnées sont entièrement comment les données prennent leur sens. Si vous n'avez pas réellement de métadonnées, vous pouvez au mieux deviner la signification des données, mais vous allez avoir énormément de difficultés. Les métadonnées doivent être présentes, mais le sens a une structure. Je ne veux pas entrer dans la philosophie du sens, mais même dans la manière dont nous traitons les données, il y a beaucoup de sophistication dans la pensée humaine et le langage humain, qui ne s'exprime pas facilement dans les données. Mais même en ce qui concerne les données que nous traitons réellement dans le monde, les métadonnées ont une signification et leur structure - une donnée par rapport à une autre et ce que cela signifie quand elles sont rassemblées et ce que cela signifie quand elles sont jointes à d'autres données, exige que nous modélisons. Ce n’est pas suffisant pour enregistrer des balises de métadonnées dans des choses, vous devez en fait enregistrer le sens par structure et la relation entre les structures.
Ensuite, nous avons la couche supérieure, les définitions métier, qui est normalement une couche qui tente de transférer le sens entre les métadonnées, qui est une forme de définition de données qui tient compte de la manière dont les données sont organisées sur l'ordinateur et la signification humaine. Vous avez donc des termes métier, des définitions, des relations et des concepts au niveau de l'entité qui existent dans cette couche. Et si nous devions avoir une incohérence entre ces couches, nous devrons alors avoir une modélisation des données. Ce n'est pas vraiment facultatif. Plus vous pourrez réellement l'automatiser, mieux ce sera. Mais parce que cela a un sens, il est vraiment difficile d’alterner. Il est assez facile de saisir les métadonnées dans un enregistrement et de l’obtenir à partir d’une série de significations, mais cela ne vous dit pas la structure des enregistrements, ni ce que ces enregistrements signifient ou ce qu’ils signifient.
Donc, voici à quoi sert la modélisation des données. Points à noter: plus l'univers de données est complexe, plus vous avez besoin de le modéliser. En d’autres termes, c’est un peu comme ajouter non seulement plus d’occasions de choses au monde, ce qui correspondrait à des enregistrements de données, mais en réalité ajouter plus de signification au monde en capturant des données sur de plus en plus de choses. Cela devient une sensation de plus en plus complexe que nous devons comprendre.
En théorie, il existe un univers de données et nous devons en avoir une vue. En pratique, les métadonnées réelles font partie de l'univers des données. Donc, ce n'est pas une situation simple. La modélisation commence par le haut et le bas. Vous devez construire dans les deux sens et la raison en est que les données ont un sens pour l'ordinateur et le processus, elles doivent le traiter, mais elles ont un sens en soi. Vous avez donc besoin d'une signification ascendante, qui satisfasse le logiciel nécessaire pour accéder aux données, ainsi que d'une signification descendante pour que les êtres humains puissent la comprendre. La construction de modèles de métadonnées n’est pas et ne peut jamais être un projet; c'est une activité continue - devrait être une activité continue dans tous les environnements où ils existent. Heureusement, il existe de nombreux environnements dans lesquels ce n'est pas le cas et les choses tournent hors de contrôle en conséquence.
À l'avenir, la modélisation augmente avec l'importance de la technologie. Cest mon avis. Mais si vous regardez l'IdO, vous pouvez comprendre le mobile plus que nous ne le faisions auparavant, bien que de nouvelles dimensions aient été introduites: la dimension de localisation avec le mobile. Une fois que vous êtes arrivé à l'IdO, vous avez été confronté à des problèmes de données extraordinaires que nous n'avions jamais dû affronter auparavant et que nous devions, d'une manière ou d'une autre, comprendre correctement ce que nous avons obtenu, comment nous pouvons l'agréger, ce que nous pouvons faire. en termes de signification de l'agrégation, et bien sûr, ce que nous pouvons en faire, une fois que nous l'avons traitée.
Je pense que c'est moi qui en ai assez dit. Je vais donner la parole à Dez Blanchfield, qui va dire autre chose.
Dez Blanchfield: Je vous remercie. C’est toujours un acte difficile à suivre, mais c’est un sujet sur lequel nous nous sommes mis d’accord et dont nous avons brièvement parlé dans le discours moqueur, et si vous appelez tôt, vous aurez probablement attrapé de nombreux joyaux. Un des plats à emporter, et je ne veux pas voler le tonnerre de celui-ci en particulier, mais un des plats à emporter de notre plaisanterie que je veux partager, au cas où vous ne l'auriez pas attrapé, était juste autour du sujet du voyage des données , et il m’a frappé de noter cela en pensant au chemin parcouru par les données dans une vie différente - année, mois, semaine, jour, heure, minute, seconde - et la situation autour des données se situe dans cette . Que ce soit un développeur exécutant du code ou un spécialiste des données et réfléchissant à la structure, au format et aux métadonnées entourant chacun des éléments, ou à la manière dont les systèmes et l'entreprise interagissent avec eux.
C'est un petit plat intéressant à noter, mais de toute façon, permettez-moi de plonger dedans. La conception de données, en particulier, est une expression que j'utilise pour parler de tout ce qui concerne les données et plus précisément du développement d'applications ou de l'infrastructure de base de données. Je pense que la conception de données est un terme qui résume tout cela très bien dans mon esprit. De nos jours, lorsque nous parlons de conception de données, nous parlons de conception de données agile moderne, et j'estime qu'il n'y a pas si longtemps, les développeurs et les experts en données travaillaient seuls; ils étaient dans leurs propres silos et les éléments de design passaient d'un silo à l'autre. Mais je suis tout à fait du même avis ces jours-ci, non seulement le cas a changé, mais il doit aussi en changer; c'est en quelque sorte une nécessité et c'est cette application - les développeurs et tout ce qui concerne le développement qui traite des données, les concepteurs qui font les éléments de conception pertinents des schémas et des champs et des enregistrements et des systèmes et infrastructures de base de données et de localisation, de la modélisation et de l'ensemble de la gestion défi autour de cela. C’est maintenant un sport d’équipe et c’est pourquoi j’ai eu l’image d’un groupe de personnes qui sautaient d’un avion et qui agissaient en équipe pour reproduire cette image visuellement intéressante de personnes qui tombaient dans le ciel.
Troisièmement, que s'est-il passé pour que cela se produise? Eh bien, il y a un article de 1986 rédigé par un couple de messieurs dont je me suis efforcé désespérément de rendre justice, Hirotaka Takeuchi et Ikujiro Nonaka, je pense qu'il est prononcé, a publié un article intitulé «Moving the Scrum Downfield». Cette idée de la méthodologie pour gagner une partie de rugby à partir de cette activité de mêlée, où tout le monde se déplace au même endroit et où deux équipes bloquent la tête dans ce qu’on appelle une mêlée pour tenter de prendre le contrôle du ballon et de le jouer sur le terrain pour atteignez la ligne d’essai et touchez le sol avec le ballon et obtenez un point, appelé trigone, et vous répétez ce processus pour obtenir plus de points pour l’équipe.
Cet article a été publié en 1986 dans le Harvard Business Review et, curieusement, il a suscité beaucoup d’attention. Il a attiré beaucoup d'attention car il a introduit de nouveaux concepts incroyables et voici une capture d'écran de l'avant. Ils ont donc retiré ce concept de mêlée du rugby et l’ont introduit dans les affaires, en particulier dans le jeu de la conception et de la réalisation de projets, en particulier de réalisation de projets.
Ce que nous avons fait, c’est une nouvelle méthodologie comparée à PRINCE2 ou PMBOK que nous avions précédemment utilisée dans ce que nous appelions la méthodologie de la cascade, vous savez, faites ceci et cela et ceci et ceci et suivez-les en séquence et connectez-vous tous les points autour, ce qui dépend de ce que vous avez fait, ou ne faites pas la deuxième partie jusqu'à ce que vous ayez terminé la première partie parce que cela dépendait de la première partie. Cela nous a donné une nouvelle méthodologie pour être un peu plus agile, d'où le terme, la manière dont nous livrons les choses, et plus particulièrement la conception et le développement de projets de base.
Certains des locataires clés - juste pour que je passe à autre chose - sont autour des locataires clés de Scrum.Il a introduit l’idée d’instabilité de la construction, que si l’on pense effectivement à la crainte du chaos, le monde existe dans un état de chaos, mais la planète s’est formée, ce qui est intéressant, si bien que l’instabilité de la construction, la capacité de rebondir un peu et toujours faire fonctionner les choses, équipes de projet auto-organisatrices, chevauchement des faveurs grâce à un développement très responsable, différents types d’apprentissage et de contrôle tout au long du parcours de réalisation du projet, transfert d’apprentissage organisationnel. Alors, comment pouvons-nous récupérer les informations d’une partie de l’entreprise et les transférer à une autre de personnes qui ont une idée, mais ne développent pas de code, ne développent pas de bases de données et d’infrastructures, mais transmettent des données à ces personnes? Et plus précisément, les résultats prévus En d’autres termes, faisons-le pendant un certain temps, soit un jour dans 24 heures, soit une semaine ou deux semaines et voyons ce que nous pouvons faire, puis reculons et examinons cela.
Et donc, si vous excusez le jeu de mots, c’est vraiment un nouveau jeu dans la réalisation du projet et ses trois composants principaux qui auront un sens si nous avançons un peu plus loin - il y a le produit: tous ces gens ont l’idée et ont un besoin de faire quelque chose et l'histoire qui les entoure. Les développeurs qui opèrent dans le modèle agile consistant à obtenir leurs histoires et à travers des confrontations quotidiennes en utilisant la méthodologie Scrum pour en discuter et comprendre ce qu’ils doivent faire, puis aller de l’avant et le faire. Ensuite, nous avons entendu parler de scrum masters qui supervisent tout cela et comprennent suffisamment la méthodologie pour le piloter. Nous avons tous vu ces images que j’ai placées à droite de murs et de tableaux blancs remplis de post-it et qui ont servi de murs kanban. Si vous ne savez pas qui est Kanban, je vous invite à dire qui est M. Kanban à Google et pourquoi il s’agit d’un changement dans la façon dont nous déplaçons les choses d’un côté à l’autre dans un mur mais dans un projet.
En un coup d’œil, le workflow Scrum fait ceci: il faut une liste de choses qu’une organisation veut faire, les passer en revue dans une série de choses que nous appelons ss qui sont divisées en périodes de 24 heures, de mois, et obtenir cette série incrémentielle de sorties. C'est un changement significatif dans la manière dont les projets sont livrés, ils l'ont été jusqu'à ce stade, parce qu'une partie de cela coule comme l'armée américaine qui a eu beaucoup de mal à développer quelque chose appelé PMBOK, comme l'idée de ne pas mener le char sur le terrain. jusqu'à ce que vous mettiez des balles dans la chose, car si un tank sur le terrain n'a pas de balles, c'est inutile. La première partie consiste donc à placer des balles dans le réservoir, la deuxième partie à placer le réservoir dans le champ. Malheureusement, ce qui s’est passé avec les développeurs du monde du développement a réussi à maîtriser cette méthodologie agile et à s’y tenir à fond, si vous pardonnez le jeu de mots, à un.
Invariablement, ce qui s’est passé, c’est que lorsque nous pensons à l’agilité, nous pensons généralement aux développeurs et non aux bases de données et à tout ce qui touche au monde des bases de données. C'était un résultat regrettable car la réalité est que l'agile ne se limite pas aux développeurs. En fait, à mon avis, le terme agile est souvent associé à tort exclusivement aux développeurs de logiciels et non aux concepteurs et architectes de bases de données. Invariablement, les mêmes défis que vous rencontrez dans le développement de logiciels et d’applications sont présents dans tout ce qui concerne la conception, le développement, l’exploitation et la maintenance, et donc l’infrastructure de données et en particulier les bases de données. Les acteurs de cette diffusion de données comprennent des architectes de données, des mouleurs, des administrateurs, des gestionnaires d’infrastructures de base de données et les bases de données elles-mêmes, ainsi que des analystes et architectes commerciaux et systèmes, des personnes qui réfléchissent à la manière dont les systèmes et les affaires fonctionnent et comment nous avons réussi à transmettre des données à travers celles-ci.
C’est un sujet que je soulève régulièrement car c’est une frustration constante, car j’estime que les spécialistes des données ne doivent pas, mais devraient, être intimement impliqués dans chaque élément de la réalisation du projet, en particulier dans le développement. Pour nous, alors nous ne nous donnons vraiment pas la meilleure chance d’obtenir un bon résultat. Nous devons souvent faire demi-tour et réfléchir à nouveau à ces questions car il existe un scénario, nous arrivons à une application en cours de construction et nous découvrons que les développeurs ne sont pas toujours des experts en données. Travailler avec des bases de données nécessite des compétences très spécialisées, en particulier en matière de données, et construit une expérience. Vous ne devenez pas instantanément un gourou de la base de données ou un expert en matière de données. c'est souvent quelque chose qui provient d'une expérience de toute une vie et certainement du Dr Robin Bloor du Code Today, qui a écrit assez abondamment le livre.
Dans de nombreux cas - et c’est regrettable, mais c’est une réalité - que les développeurs de logiciels ont eux-mêmes une panne de mémoire en tant que spécialiste des bases de données et qu’ils ont acquis les compétences dont vous avez besoin en modélisation de la conception de bases de données, le développement de modèles n’est que le Ce qui est fondamental pour l’ingénierie des gourous en ce qui concerne l’entrée des données et comment l’organisation du voyage qu’il prend et ce qu’il devrait ou ne devrait pas être, ou bien cette ingestion et cette compréhension qu’il est généralement acquis dans les compétences natives des développeurs de logiciels. Et quelques-uns des défis communs auxquels nous sommes confrontés, pour ne pas dire plus, comprennent la création, la maintenance et la gestion de base de la conception de base de données, la documentation des données et de l’infrastructure de base de données, puis la réutilisation de ces actifs, la conception des schémas, générations de schéma, administration et maintenance du schéma et leur utilisation, partage des connaissances sur les raisons pour lesquelles ce schéma est conçu de manière particulière, et forces et faiblesses qui en découlent au fil du temps provoquent des modifications des données au fil du temps, la modélisation et les types des modèles que nous appliquons aux systèmes et aux données que nous leur transmettons. Génération de code de base de données, intégration, modélisation des données et accès plus rapide au contrôle de la sécurité des données, intégrité des données, transfert des données à mesure que l’intégrité est préservée, métadonnées suffisantes les ventes doivent-elles voir tous les enregistrements de la table ou ne doivent-elles voir que l’adresse, le prénom, le nom de famille que vous avez mis dans le message? Et puis, bien sûr, le plus grand défi de tous est de modéliser les plates-formes de bases de données, ce qui est une conversation totalement différente en soi.
Tout en pensant que pour rendre possible ce nirvana, il est absolument essentiel que les spécialistes des données et les développeurs disposent des outils appropriés et qu'ils soient capables de mener à bien des projets axés sur l'équipe, conception, développement et maintenance opérationnelle continue. Vous savez, des choses comme la collaboration entre des experts en données et des développeurs de logiciels, un point de vérité ou une source de vérité pour tout ce qui concerne la documentation des bases de données elles-mêmes, les données, les schémas, l’origine des enregistrements, les propriétaires de ces enregistrements . Je pense qu’à notre époque, c’est absolument essentiel, nous allons faire en sorte que ce nirvana des données soit roi, que les bons outils doivent être en place, car le défi est trop grand pour nous de le faire manuellement, et si les gens le souhaitent. Pour entrer et sortir d’une organisation, il est trop facile pour nous de ne pas suivre le même processus ou la même méthodologie qu’une seule personne qui pourrait mettre en place qui sont bons et ne pas nécessairement transférer ces compétences et capacités à l’avenir.
Gardant cela à l’esprit, je vais me rendre chez notre bon ami d’IDERA et entendre parler de cet outil et de la façon dont il traite de ces choses.
Ron Huizenga: Merci beaucoup et merci à Robin et à Dez d’avoir vraiment bien préparé le terrain, et vous allez voir un peu de chevauchement dans un certain nombre de choses dont j’ai parlé. Mais ils ont vraiment établi une base très solide pour certains des concepts dont je vais parler du point de vue de la modélisation des données. Et beaucoup des choses qu'ils disent ont fait écho à ma propre expérience quand j'étais consultant travaillant dans la modélisation et l'architecture de données, avec des équipes - à la fois en cascade et en évoluant vers des produits plus modernes avec des projets où nous utilisions agile méthodologies pour fournir des solutions.
Donc, ce dont je vais parler aujourd’hui est basé sur ces expériences ainsi que sur une vue des outils et de certaines des capacités des outils que nous utilisons pour nous aider dans cette voie. Ce que je vais aborder très brièvement, c’est que je ne vais pas entrer dans les détails avec beaucoup de précision; nous venons d'avoir un très bon aperçu de ce que c'est. Je vais en parler, en quoi consiste un modèle de données et que signifie-t-il vraiment pour nous? Et comment activons-nous le concept de modélisateur de données agile dans nos organisations, comment engage-t-on les modélisateurs de données, quelle est la participation des modélisateurs et des architectes au cours de la s, quels types d'activités ils devraient être engagés? et, en guise de toile de fond, quelles sont certaines des fonctionnalités importantes des outils de modélisation que nous utilisons pour réellement faciliter ce travail? Ensuite, je vais résumer un peu et parler un peu des valeurs et des avantages commerciaux de la participation d’un modélisateur de données, ou de la façon dont je vais raconter l’histoire, les problèmes liés au fait de ne pas avoir un modélisateur de données pleinement engagé dans les projets et je vous montrerai cela en fonction de l'expérience et d'un tableau des défauts d'une image avant et après d'un projet réel auquel je participais il y a de nombreuses années. Nous résumerons ensuite quelques points, puis nous poserons des questions et des réponses.
Très brièvement, ER Studio est une suite très puissante qui comporte de nombreux composants. L'architecte de données, qui est l'endroit où les modélisateurs de données et les architectes passent le plus clair de leur temps à modéliser leurs données. Il existe également d’autres composants dont nous ne parlerons pas du tout aujourd’hui, tels que Business Architect, où nous effectuons la modélisation de processus et Software Architect, pour certains modèles de modélisation UML. Ensuite, il y a le référentiel, dans lequel nous archivons et partageons les modèles. Nous autorisons les équipes à collaborer sur ceux-ci et à les publier sur leur serveur afin que plusieurs groupes de parties prenantes impliqués dans un projet puissent réellement voir les artefacts que nous avons '. Recréer à partir d’une perspective de données, ainsi que des autres éléments de la réalisation du projet.
Ce sur quoi je vais me concentrer aujourd’hui, ce sont quelques choses que nous allons voir dans Data Architect et parce qu’il est vraiment important que nous ayons la collaboration des aspects de cela basés sur le référentiel. Particulièrement lorsque nous commençons à parler de concepts tels que la gestion du changement qui sont impératifs, non seulement pour les projets de développement agiles, mais pour tout type de développement à venir.
Parlons donc un instant du logiciel Agile Data Modeler. Comme nous l’avons déjà fait remarquer plus tôt dans la présentation, il est impératif que les modélisateurs de données et / ou les architectes s’impliquent pleinement dans les processus de développement agiles. Maintenant, ce qui est arrivé dans l’histoire, c’est que, oui, nous avons vraiment pensé à l’agilité du point de vue du développement, et il ya eu plusieurs événements qui ont réellement provoqué cette évolution. Cela était en partie dû à la nature même de la manière dont le développement s’était déroulé. Lorsque le développement agile a commencé et que nous avons commencé avec ce concept d'équipes auto-organisées, si vous buviez un peu trop pur dans le Kool-Aid et si vous étiez dans le côté programmation, il y avait une interprétation très littérale de choses comme des équipes auto-organisées, ce que beaucoup de gens interprètent comme étant tout ce dont nous avons besoin, c'est d'un groupe de développeurs capables de construire une solution complète. Qu'il s'agisse de développer le code, les bases de données ou les datastores sous-jacents, tout a été relégué aux développeurs. Mais ce qui se passe, c’est que vous perdez les capacités spéciales dont disposent les gens. J’ai constaté que les équipes les plus fortes sont celles composées de personnes issues de différents milieux. Comme une combinaison de puissants développeurs de logiciels, d’architectes de données, de modélisateurs de données, d’analystes et de parties prenantes, qui collaborent tous pour créer une solution finale.
Ce dont je parle aussi aujourd’hui, c’est que je vais le faire dans le cadre d’un projet de développement dans le cadre duquel nous développons une application à laquelle le composant de données sera associé. Nous devons toutefois faire un pas en arrière avant de le faire, car nous devons réaliser qu'il existe très peu de projets de développement Greenfield dans lesquels nous nous concentrons entièrement sur la création et la consommation de données qui sont limitées uniquement dans le cadre de ce projet de développement. . Nous devons faire un pas en arrière et examiner le point de vue organisationnel global du point de vue des données et du processus. Ce que nous découvrons, c’est que les informations que nous utilisons peuvent déjà exister quelque part dans les organisations. En tant que modélistes et architectes, nous mettons cela en lumière afin que nous sachions où trouver cette information dans les projets eux-mêmes. Nous connaissons également les structures de données impliquées, car nous avons des modèles de conception, tout comme les développeurs ont des modèles de conception pour leur code. Et nous devons également adopter cette perspective organisationnelle globale. Nous ne pouvons pas simplement regarder les données dans le con de l’application que nous construisons. Nous devons modéliser les données et veiller à les documenter, car elles survivent longtemps au-delà des applications elles-mêmes. Ces applications vont et viennent, mais nous devons être en mesure d'examiner les données et de nous assurer qu'elles sont robustes et bien structurées, non seulement pour les applications, mais également pour les décisions qui rapportent les activités, le reporting BI et l'intégration à d'autres applications, internes et externes. externe à nos organisations aussi. Nous devons donc examiner l'ensemble du tableau des données et leur cycle de vie, et comprendre le cheminement des informations au sein de l'organisation, du berceau à la tombe.
Pour en revenir aux équipes elles-mêmes et à la façon dont nous devons réellement travailler, la méthodologie en cascade a été perçue comme trop lente à donner des résultats. Comme indiqué dans l'exemple du char d'assaut, il s'agissait d'une étape à la fois et il fallait souvent trop de temps pour obtenir un résultat final réalisable. Ce que nous faisons maintenant, c’est que nous devons adopter un style de travail itératif qui consiste à en développer progressivement les composants et à l’élaborer au fil du temps, en produisant du code utilisable ou des artefacts utilisables, je vais le dire, pour chaque projet. L’important est la collaboration entre les parties prenantes techniques de l’équipe et les parties prenantes de l’entreprise, car nous collaborons pour amener ces histoires d’utilisateurs dans une vision réalisable du code et des données qui le prennent également en charge. Et Agile Data Modeler lui-même s'aperçoit souvent que nous n'avons pas assez de modélisateurs dans les organisations, de sorte qu'un même modélisateur ou architecte de données peut prendre en charge simultanément plusieurs équipes.
Et l’autre aspect est que, même si nous avons plusieurs modélisateurs, nous devons nous assurer de disposer d’un ensemble d’outils permettant d’utiliser plusieurs projets en même temps et de les partager. artefacts de données et les capacités d’enregistrement et de retrait. Je vais y revenir très rapidement car nous l’avons déjà abordé dans la section précédente. Le principe de base d’agile est que vous vous en remettez à des arriérés, à des récits ou à des besoins. Au sein des itérations, nous collaborons en tant que groupe. En général, une semaine ou un mois, selon l’organisation, est très courant. Et également des réunions de bilan et de réunions quotidiennes afin d’éliminer les bloqueurs et de faire avancer tous les aspects sans s’arrêter dans différents domaines à mesure que nous progressons. Et dans ces ss, nous voulons nous assurer que nous produisons des livrables utilisables comme une partie de chaque s.
La méthode dont je vais parler plus précisément ici est un peu différente, mais nous avons élargi le sujet. Nous avons simplement enrichi cette image précédente de quelques autres facettes. En règle générale, il existe un arriéré de produits, puis un arriéré. Nous avons donc un arriéré général qui, au début de chaque réitération, consiste à dire: «Qu'est-ce que nous allons construire à partir de cela?» Et cela a été fait lors d'une réunion de planification. Ensuite, nous décomposons les tâches qui y sont associées et nous exécutons ces travaux d’une à quatre semaines avec ces examens quotidiens. Au fur et à mesure que nous le faisons, nous suivons nos progrès à l’aide de graphiques de combustion et de graphiques de combustion afin de suivre en gros ce qui reste à construire par rapport à ce que nous construisons pour établir des éléments tels que notre vitesse de développement. calendrier, tous ces types de choses. Tous ces éléments sont élaborés de manière continue au cours de la réunion plutôt que d’aller dans quelques mois et de découvrir que vous allez faire faillite et que vous devez allonger le calendrier du projet. Et très important, en tant que partie intégrante de l’ensemble des équipes, il existe un examen final et une rétrospective. Avant de lancer la prochaine itération, vous passez en revue ce que vous avez fait et vous recherchez des moyens d’améliorer la situation. la prochaine fois à travers.
En ce qui concerne les produits livrables, il s’agit essentiellement d’une diapositive qui résume les types d’activités typiques des art. Et il est très centré sur le développement, donc beaucoup de choses que nous voyons ici, telles que les conceptions fonctionnelles et les cas d'utilisation, les tests de code de conception, lorsque nous examinons ces encadrés ici, et je ne vais pas les passer en revue. peu importe le niveau de détail, ils sont très orientés développement. Et sous-tendu ici, nous avons également besoin de disposer des livrables de données qui vont de pair pour soutenir cet effort. Ainsi, chaque fois que nous constatons des problèmes tels que les arriérés, les exigences et les histoires d'utilisateurs, nous devons examiner en même temps quels sont les éléments de développement que nous devons faire, quels sont les éléments d'analyse que nous devons faire, et comment la conception des données ou le modèle de données, qu'en est-il des choses comme les glossaires commerciaux afin que nous puissions associer une signification commerciale à tous les artefacts que nous produisons? Parce que nous devons produire ces livrables utilisables dans tous les cas.
Certaines personnes diront que nous devons produire du code utilisable à la fin de chaque s. Ce n’est pas nécessairement le cas, c’est dans une perspective de développement la plus pure, mais assez souvent - surtout au début - nous pouvons avoir quelque chose comme le s zéro où nous nous concentrons uniquement sur des choses debout, comme des stratégies de test dans endroit.Une conception de haut niveau pour le lancer avant de commencer à fournir les détails et à nous assurer que nous avons un ensemble d'histoires de départ ou d'exigences avant de commencer à intéresser d'autres publics, puis de continuer à progresser en tant qu'équipe. Il y a toujours un peu de temps de préparation, donc nous aurons souvent un zéro, voire un zéro. Cela pourrait être un peu une phase de démarrage avant que nous puissions fournir la solution.
Parlons très brièvement des modèles de données dans cette configuration. Lorsque les gens pensent à des modèles de données, ils pensent souvent qu’ils illustrent la façon dont les différentes informations s’associent - c’est la partie visible de l’iceberg. Pour incarner pleinement l’esprit de la manière dont vous voulez vraiment aborder la modélisation des données - qu’il s’agisse de développement agile ou autre -, vous devez réaliser que ce modèle de données, s’il est correctement conçu, devient votre spécification complète de ce que ces données signifient pour l’entreprise et comment il est déployé dans les bases de données back-end. Quand je parle de bases de données, je ne parle pas seulement des bases de données relationnelles que nous utilisons peut-être, mais dans les architectures d’aujourd’hui où nous avons des plateformes Big Data ou NoSQL, comme je préfère les appeler. De plus, ces grands magasins de données, car nous combinons peut-être un grand nombre de magasins de données différents en termes de consommation d’informations et de leur intégration dans nos solutions, ainsi que de la manière dont nous conservons ou conservons ces informations hors de nos solutions.
Nous pouvons travailler avec plusieurs bases de données ou sources de données simultanément dans le contexte d’une application donnée. Ce qui est très important, c’est que nous voulons pouvoir avoir une spécification complète, donc une spécification logique de ce que cela signifie en tant que perspective organisationnelle, en quoi consistent les constructions physiques en termes de définition des données, de relations entre elles. bases de données, vos contraintes d’intégrité référentielle, vos contraintes de vérification, tous ces éléments de validation auxquels vous pensez habituellement. Les métadonnées descriptives sont extrêmement importantes. Comment savez-vous comment utiliser les données dans vos applications? Sauf si vous pouvez le définir et savoir ce que cela signifie ou savoir d'où il vient pour vous assurer de consommer les données correctes dans ces applications - en vous assurant que nous avons les conventions de dénomination correctes, des définitions complètes, ce qui signifie un dictionnaire de données complet non seulement les tables mais les colonnes qui les composent - et des notes de déploiement détaillées sur la façon dont nous l'utilisons car nous devons construire cette base de connaissances, car même lorsque cette application est terminée, cette information sera utilisée pour d'autres initiatives. Nous devons donc nous assurer que que nous avons tout ce qui est documenté pour les implémentations futures.
Encore une fois, nous abordons des sujets tels que les types de données, les clés, les index: le modèle de données lui-même incarne de nombreuses règles métier. Les relations ne sont pas simplement des contraintes entre différentes tables; ils nous aident souvent à décrire les véritables règles métier relatives au comportement de ces données et à leur fonctionnement en tant qu'unité cohérente. Et bien sûr, les restrictions de valeur sont très importantes. Maintenant, bien sûr, l’une des questions auxquelles nous sommes constamment confrontés, et qui devient de plus en plus répandue, est la gouvernance des données. Donc, du point de vue de la gouvernance des données, nous devons également examiner ce que nous définissons ici. Nous voulons définir des choses comme les classifications de sécurité. Quels types de données traitons-nous? Qu'est-ce qui va être considéré comme la gestion des données de base? Quels sont les magasins transactionnels que nous créons? Quelles données de référence utilisons-nous dans ces applications? Nous devons nous assurer que cela est correctement pris en compte dans nos modèles. Outre la qualité des données, certaines informations sont plus importantes que d’autres pour une organisation.
J’ai été impliqué dans des projets dans lesquels nous remplacions plus d’une douzaine de systèmes existants par de nouveaux processus métier et concevions de nouvelles applications et des magasins de données pour les remplacer. Nous devions savoir d'où venait l'information. Pour les éléments d’information les plus importants, d’un point de vue commercial, si vous regardez cette diapositive de modèle de données que j’ai ici, vous verrez que les cases inférieures de ces entités particulières, qui ne sont qu’un petit sous-ensemble, 'ai effectivement été capable de capturer la valeur commerciale. Que ce soit élevé, moyen ou faible pour ce genre de choses pour ces différents concepts au sein de l'organisation. Et j’ai également capturé des éléments tels que les classes de données de base, qu’il s’agisse de tables maîtres, de référence ou s’il s’agissait de transactions. Nous pouvons donc étendre nos métadonnées dans nos modèles pour nous donner beaucoup d'autres caractéristiques en dehors des données elles-mêmes, ce qui nous a vraiment aidés avec d'autres initiatives en dehors des projets d'origine et de les faire avancer. C’était maintenant beaucoup sur une diapositive, je vais parcourir le reste assez rapidement.
Je vais maintenant parler très rapidement de ce que fait un modélisateur de données au cours de ces différentes étapes. Tout d’abord, participez pleinement aux séances de planification, où nous prenons les histoires d’utilisateurs, nous nous engageons à ce que nous allons fournir, et nous déterminons comment nous allons le structurer et le livrer. Ce que je fais aussi en tant que modélisateur de données, c’est que je sais que je vais travailler dans des zones distinctes avec différents développeurs ou avec différentes personnes. Ainsi, l’une des caractéristiques importantes que nous pouvons avoir est que lorsque nous élaborons un modèle de données, nous pouvons le diviser en différentes vues, qu’il s’agisse de domaines ou de sous-modèles, c’est notre terminologie. Alors que nous construisons le modèle, nous le montrons également dans ces différentes perspectives de sous-modèles, de sorte que les différents publics ne voient que ce qui les intéresse, afin qu’ils puissent se concentrer sur ce qu’ils développent et proposent. Donc, il se peut que quelqu'un travaille sur une partie de la planification d'une application, quelqu'un d'autre travaille sur une entrée de commande où nous faisons toutes ces choses en un seul passage, mais je peux leur donner les points de vue à travers ces sous-modèles appliquer à la zone sur laquelle ils travaillent. Ensuite, ceux-ci sont regroupés dans le modèle global et dans la structure complète des sous-modèles afin de donner à différents auditoires ce qu'il doit voir.
Les bases de la modélisation des données que nous souhaitons, c’est d’avoir toujours une base de référence sur laquelle nous pouvons revenir car l’une des choses que nous devons être en mesure de faire est, que ce soit à la fin de l’échéance ou à la fin de celle-ci. plusieurs années, nous voulons savoir où nous avons commencé et nous avons toujours une base de référence pour savoir quel était le delta ou la différence de ce que nous avons produit dans un s donné. Nous devons également nous assurer que nous pouvons avoir un redressement rapide. Si vous entrez dans la modélisation en tant que modélisateur de données mais que vous agissez traditionnellement en tant que contrôleur d'accès: «Non, non, vous ne pouvez pas le faire, nous devons d'abord faire tout ce travail», vous allez être exclu de l'équipe si vous en avez vraiment besoin. participer activement à toutes ces équipes de développement agiles. Cela signifie que certaines choses tombent du wagon en train de faire un s donné et que vous les récupérez plus tard.
Par exemple, vous pouvez vous concentrer sur les structures de données uniquement pour lancer le développement, cet élément de saisie de commande dont je parlais. Plus tard, vous pourrez revenir compléter les données, comme une partie de la documentation du dictionnaire de données autour de certains de ces artefacts que vous avez créés. Vous n'allez pas compléter cette définition en un seul geste; vous allez continuer à utiliser progressivement vos produits livrables, car vous pourrez parfois saisir ces informations en collaboration avec des analystes métier lorsque les développeurs sont en train de créer les applications et de préserver la persistance de ces magasins de données. Vous voulez faciliter et ne pas être le goulot d'étranglement. Nous travaillons de différentes manières avec les développeurs. Pour certaines choses, nous avons des modèles de conception, nous sommes donc un participant à part entière dès le départ. Nous pouvons donc avoir un modèle de conception dans lequel nous dirons que nous l'insérerons dans le modèle, nous le transmettrons aux bases de données des développeurs, puis ils peuvent commencer à travailler avec elle et demander des modifications à cela.
Il se peut que les développeurs travaillent sur d'autres domaines, qu'ils travaillent sur quelque chose et prototypent certaines choses afin qu'ils essayent certaines choses dans leur propre environnement de développement. Nous prenons la base de données avec laquelle ils travaillaient, nous l'introduisons dans notre outil de modélisation, nous comparons avec les modèles que nous avons, puis nous résolvons et leur renvoyons les modifications afin qu'elles puissent refactoriser leurs codes afin qu'elles suivent les structures de données appropriées. dont nous avons besoin. Parce qu'ils ont peut-être créé des éléments déjà existants ailleurs, nous nous assurons qu'ils travaillent avec les bonnes sources de données. Nous continuons simplement à itérer jusqu'à ce que nous obtenions tous les éléments livrables, la documentation complète et la définition de toutes les structures de données que nous produisons.
Les projets agiles les plus réussis auxquels j'ai participé en termes de très bonnes livraisons sont, selon notre philosophie, de modéliser toutes les modifications apportées à la spécification de base de données physique complète. Essentiellement, le modèle de données devient les bases de données déployées avec lesquelles vous travaillez pour tout élément nouveau que nous créons, et contient les références complètes des autres magasins de données si nous utilisons d'autres bases de données externes. Dans ce cadre, nous produisons des scripts incrémentiels par opposition à une génération complète à chaque fois. Et nous utilisons nos modèles de conception pour nous permettre de réagir rapidement avec les différentes équipes de développement avec lesquelles nous travaillons.
Dans les activités également, c’est encore une fois la base de référence pour la comparaison / fusion, prenons donc l’idée de modéliser chaque changement. Chaque fois que nous apportons un changement, nous voulons modéliser le changement. Ce qui est très important, c'est que la modélisation des données manquait jusqu'à récemment. En fait, jusqu'à ce que nous le réintroduisions, il est possible d'associer la modélisation. tâches et de vos livrables avec les user stories et les tâches qui entraînent ces modifications. Nous voulons pouvoir vérifier les modifications apportées à notre modèle, de la même manière que les développeurs, dans leurs codes, en référençant les histoires d'utilisateurs que nous avons afin de savoir pourquoi nous avons apporté des modifications, c'est quelque chose que nous faisons. Lorsque nous le faisons, nous générons nos scripts DDL incrémentiels et les publions afin qu'ils puissent être récupérés avec les autres produits livrables du développement et archivés dans notre solution de génération. Encore une fois, nous pouvons avoir un seul modèle ou travailler avec plusieurs équipes. Et comme je l’ai dit plus tôt, le modélisateur de données a créé certaines choses, les développeurs en ont créé une autre et nous nous réunissons au milieu pour trouver la meilleure conception globale, la faire avancer et s’assurer qu’elle est correctement conçue dans notre environnement. structures de données globales. Nous devons maintenir la discipline consistant à veiller à ce que notre modèle de données comprenne tous les concepts appropriés, y compris des valeurs telles que des valeurs nulles et non négatives, des contraintes référentielles, des contraintes de contrôle essentiellement, toutes les choses auxquelles nous pensons habituellement. .
Parlons maintenant de quelques captures d'écran de certains des outils qui nous aident à le faire. Ce qui est important à mes yeux, c’est de disposer de ce référentiel collaboratif. Ce que nous pouvons faire en tant que modélisateurs de données - c’est un extrait d’une partie d’un modèle de données en arrière-plan - c’est lorsque nous travaillons sur des éléments sur lesquels nous voulons être sûrs. travaillez uniquement sur les objets que nous devons pouvoir modifier, apportez les modifications, générez nos scripts DDL pour les modifications apportées lors de la vérification des éléments. Nous pouvons donc procéder comme suit: dans ER Studio, par exemple, nous pouvons consulter des objets ou des groupes d’objets sur lesquels travailler, nous n’avons pas à vérifier un modèle ou un sous-modèle complet, nous pouvons uniquement vérifier les éléments qui nous intéressent. Ce que nous voulons ensuite, c’est au moment du check-out ou de l’enregistrement - nous le faisons dans les deux sens, car différentes équipes de développement travaillent de différentes manières. Nous voulons nous assurer que nous associons cela à la user story ou à la tâche qui détermine les exigences pour cela et que ce sera la même user story ou la même tâche que celle que les développeurs vont développer et archiver leur code.
Voici donc un extrait très rapide de quelques écrans de l’un de nos centres de gestion du changement. Ce que cela fait, je ne vais pas donner plus de détails ici, mais ce que vous voyez est la user story ou la tâche et est mis en retrait sous chacun de ceux que vous voyez les enregistrements de changement réels - nous avons créé un enregistrement de changement automatisé lorsque nous effectuons les entrées et les sorties et nous pouvons également ajouter davantage de descriptions à cet enregistrement de modification. Comme il est associé à la tâche, nous pouvons avoir plusieurs modifications par tâche, comme vous le souhaitiez. Et lorsque nous entrons dans ce dossier de changement, nous pouvons l'examiner et, surtout, voir ce que nous avons réellement changé. Pour ce cas particulier, l’histoire surlignée, j’ai eu un type de changement qui a été apporté et lorsque j’ai regardé l’enregistrement de changement proprement dit, il a identifié les éléments individuels du modèle qui a changé. J'ai changé quelques attributs ici, je les ai réorganisés et cela a amené pour le trajet les vues à modifier dépendantes de celles-ci afin qu'elles soient générées dans la DLL incrémentielle. Ce n'est pas seulement la modélisation sur les objets de base, mais un outil de modélisation très puissant comme celui-ci détecte également les modifications à répercuter sur les objets dépendants de la base de données ou du modèle de données.
Si nous travaillons avec des développeurs et que nous le faisons de plusieurs manières différentes, c’est-à-dire qu’ils font quelque chose dans leur bac à sable et que nous voulons comparer et voir où sont les différences, nous utilisons des fonctionnalités de comparaison / fusion dans la partie droite et gauche. côté. Nous pouvons dire: «Voici notre modèle du côté gauche, voici leur base de données du côté droit, montrez-moi les différences.» Nous pouvons ensuite choisir comment nous allons résoudre ces différences, que nous introduisions ou non des éléments dans la base de données. la base de données contient des éléments que nous intégrons dans le modèle. Nous pouvons aller dans les deux sens pour pouvoir aller dans les deux sens simultanément en mettant à jour les sources et les cibles, puis produire les scripts DDL incrémentiels pour déployer ces modifications dans l'environnement de la base de données, ce qui est extrêmement important. Ce que nous pouvons également faire, c’est que nous pouvons également utiliser cette capacité de comparaison et de fusion à tout moment. Si nous prenons des instantanés en cours de route, nous pouvons toujours comparer le début d’un s au début ou à la fin d’un autre s afin de voir le changement incrémental complet de ce qui a été fait dans un développement donné ou dans une série d’actes.
C’est un exemple très rapide de script de modification. Tous ceux qui travaillent avec des bases de données auront déjà vu ce genre de chose. C’est ce que nous pouvons utiliser comme code de modification pour nous assurer que nous conserver les choses ici. Ce que j’ai tiré d’ici, juste pour réduire l’encombrement, c’est ce que nous faisons également avec ces scripts de remplacement: nous supposons que ces tables contiennent également des données; nous allons donc générer le DML qui extraira les informations des tables temporaires et repoussez-le également dans les nouvelles structures de données afin que nous examinions non seulement les structures, mais également les données que nous avons peut-être déjà contenues dans ces structures.
Nous allons parler très rapidement des systèmes de construction automatisés, car lorsque nous réalisons un projet agile, nous travaillons souvent avec des systèmes de construction automatisés. Nous devons vérifier ensemble les différents produits livrables pour nous assurer de ne pas casser nos constructions. Cela signifie que nous synchronisons les produits livrables, que les scripts de modification dont j'ai parlé avec le script DDL doivent être archivés, que le code de l'application correspondante doit être archivé en même temps et qu'un grand nombre de développeurs en cours de développement ne sont bien sûr pas concernés. fait avec SQL direct contre les bases de données et ce genre de chose. Nous utilisons souvent des frameworks de persistance ou des services de données. Nous devons nous assurer que les modifications apportées à ces infrastructures ou services sont archivées exactement au même moment. Elles utilisent un système de construction automatisé dans certaines organisations et, si la construction se casse, avec une méthodologie agile, il est essentiel de procéder à la construction du pont avant de poursuivre, de sorte que nous sachions que nous avons une solution opérationnelle avant d'aller plus loin. Et l’un des projets auxquels je participais a été pris à l’extrême - si la construction s’est brisée sur un certain nombre d’ordinateurs de notre région où nous étions hébergés avec des utilisateurs professionnels, nous avions des voyants rouges clignotants comme le haut des voitures de police. Et si la construction se cassait, ces lumières clignotantes rouges commençaient à s'éteindre et nous savions que tout était à portée de main: corrigez la construction puis procédez comme nous le faisions.
Je veux parler d'autres choses, et c'est une capacité unique pour ER Studio. Cela aide vraiment lorsque nous essayons de construire ces artefacts en tant que développeurs pour ces limites de persistance, nous avons un concept appelé objets de données métier et ce qui nous permet de Si vous prenez ce modèle de données très simpliste à titre d’exemple, il nous permet d’encapsuler des entités ou des groupes d’entités à l’endroit où se trouvent les limites de la persistance. En tant que modélisateur de données, nous pouvons penser à quelque chose comme un en-tête de commande d'achat et l'alignement des commandes et d'autres tableaux détaillés qui pourraient être liés à la manière dont nous le construisons et à nos développeurs de services de données ont besoin de savoir comment les choses persistent avec ces différentes données. structures. Nos développeurs pensent à des choses comme le bon de commande comme un objet global et quel est leur contrat avec la façon dont ils créent ces objets particuliers. Nous pouvons exposer ces détails techniques de manière à ce que les utilisateurs des serveurs de données puissent voir ce qui se trouve en dessous et à protéger les autres publics des complexités afin qu’ils ne voient que les différents objets de niveau supérieur, ce qui fonctionne également très bien pour la communication avec les entreprises. analystes et parties prenantes de l’entreprise lorsque nous parlons également de l’interaction de différents concepts d’entreprise.
La bonne chose à propos de cela également est que nous développons et réduisons ces éléments de manière constructive afin de pouvoir conserver les relations entre les objets d'ordre supérieur, même s'ils proviennent de constructions contenues dans ces objets de données métiers eux-mêmes. Maintenant, en tant que modélisateur, arrêtez-vous à la fin, à la fin de la synthèse, j'ai beaucoup de choses à faire, que j'appelle les tâches ménagères suivantes. Chaque fois que je crée ce que j'appelle la publication nommée - cela me donne la base de référence pour ce que j'ai maintenant à la fin de la publication. Cela signifie donc que c’est ma ligne de base pour l’avenir. Toutes ces lignes de base ou versions nommées que je crée et enregistre dans mon référentiel, je peux les utiliser pour faire une comparaison / fusion afin que je puisse toujours comparer avec une fin donnée de s de tout autre s, qui Il est très important de savoir quelles modifications ont été apportées à votre modèle de données tout au long de son parcours.
Je crée également un script delta DDL en utilisant la comparaison / fusion à nouveau du début à la fin de s. J'ai peut-être vérifié un tas de scripts incrémentiels, mais si j'en ai besoin, j'ai maintenant un script que je peux déployer pour afficher d'autres sandbox afin que je puisse simplement dire que c'est ce que nous avions au début de celui-ci, Construisez une base de données en tant que bac à sable pour commencer par le prochain. Nous pouvons également utiliser ces éléments pour faire des choses telles que des instances de contrôle qualité et, en définitive, nous souhaitons appliquer nos modifications à la production afin que de multiples activités soient en cours. en même temps. Encore une fois, nous participons pleinement à la planification et aux rétrospectives, les rétrospectives sont vraiment les leçons apprises et c’est extrêmement important, car vous pouvez aller très vite pendant une période agile, vous devez vous arrêter et célébrer les succès, comme maintenant. Déterminez ce qui ne va pas, améliorez-le la prochaine fois, mais célébrez les succès qui ont bien fonctionné et renforcez-les au fur et à mesure que vous avancez dans les années à venir.
Je vais maintenant parler très rapidement de la valeur commerciale. Il y a de nombreuses années, j’ai commencé à travailler sur un projet agile. C’était un projet extrême. Il s’agissait donc d’une pure équipe auto-organisatrice, composée uniquement de développeurs. En résumé, ce projet était en panne et ils s'apercevaient qu'ils consacraient de plus en plus de temps à la réparation et à la correction des défauts identifiés, plutôt qu'à l'amélioration de la fonctionnalité. sur les tableaux de répartition, ils allaient devoir prolonger le projet de six mois à un coût énorme. Et lorsque nous avons examiné la question, la solution du problème consistait à utiliser un outil de modélisation de données approprié, avec un modélisateur de données qualifié impliqué dans le projet lui-même.
Si vous regardez cette barre verticale sur ce graphique, cela montre les défauts cumulés par rapport aux objets cumulés, et je parle des objets de données ou des constructions qui ont été créés, tels que les tables avec les contraintes et ce genre de choses, si vous avez regardé Avant l'introduction du modélisateur de données, le nombre de défauts était en réalité supérieur et commençait à créer un léger décalage par rapport au nombre réel d'objets produits jusque-là. Après la semaine 21, le modélisateur de données est entré, a remanié le modèle de données en fonction de ce qui était prévu pour résoudre un certain nombre de problèmes, puis a commencé à modéliser dans le cadre de l'équipe de projet, à mesure que le projet évoluait. . Et vous avez assisté à un très rapide retournement: environ un demi-heure à peine, nous avons assisté à une énorme augmentation du nombre d'objets et de constructions de données générés et construits parce que nous générions à partir d'un outil de modélisation de données plutôt que d'un stick de développeur. eux dans un environnement, et ils avaient raison parce qu’ils avaient l’intégrité référentielle appropriée et les autres constructions qu’il devrait avoir. Le niveau de défauts contre ceux presque flatline. En prenant cette mesure appropriée et en veillant à ce que la modélisation des données soit pleinement utilisée, le projet a été livré à temps avec un niveau de qualité beaucoup plus élevé. En fait, il n'aurait pas abouti si ces étapes n'avaient pas eu lieu. Il y a beaucoup d'échecs agiles, mais aussi beaucoup de succès agiles si vous voulez que les bonnes personnes occupent les bons rôles. Je suis un fervent partisan de l’agile en tant que discipline opérationnelle, mais vous devez vous assurer que vous avez les compétences de tous les bons groupes impliqués en tant qu’équipes de projet lorsque vous avancez dans une entreprise de type agile.
Pour résumer, les architectes de données et les modélisateurs doivent être impliqués dans tous les projets de développement; ils sont vraiment le ciment qui unit tout, car en tant que modélisateurs et architectes de données, nous comprenons non seulement les constructions de données du projet de développement donné, mais également le lieu où les données existent dans l’organisation et où nous pouvons extraire ces données et comment. va être utilisé et utilisé en dehors de l'application particulière elle-même sur laquelle nous travaillons. Nous comprenons les relations complexes entre les données et il est primordial de pouvoir aller de l'avant et, du point de vue de la gouvernance, cartographier et comprendre à quoi ressemble votre paysage de données.
C'est comme fabriquer; Je viens d'un milieu manufacturier. Vous ne pouvez pas inspecter la qualité à la fin. Vous devez intégrer la qualité dans votre conception, dès le départ, et la modélisation des données est un moyen d’intégrer cette qualité dans la conception de manière efficace et économique. . Et encore une fois, il y a quelque chose à retenir - et ce n'est pas banal, mais c'est la vérité - les applications vont et viennent, les données sont l'actif essentiel de l'entreprise et transcendent toutes les frontières de ces applications. Chaque fois que vous installez une application, on vous demande probablement de préserver les données des applications précédentes. Vous devez donc vous rappeler que c'est un atout essentiel pour l'entreprise que nous conservons au fil du temps.
Et c'est tout! À partir de là, nous répondrons à plus de questions.
Eric Kavanagh: Bon, d'accord, laissez-moi d'abord céder la parole à Robin. Et puis, Dez, je suis sûr que vous avez quelques questions. Enlève-le, Robin.
Dr Robin Bloor: D'accord. Pour être honnête, je n’ai jamais eu de problème avec les méthodes de développement agiles et il me semble que ce que vous faites ici a un sens éminent. Je me souviens d’avoir observé quelque chose dans les années 1980 qui indiquait, en réalité, que le problème que vous rencontrez en ce qui concerne un projet qui échappe à tout contrôle est normalement si vous laissez une erreur persister au-delà d’un certain stade. Cela devient de plus en plus difficile à régler si vous ne vous y prenez pas bien, alors l'une des choses que vous faites ici - et je pense que ceci est la diapositive - mais l'une des choses que vous faites ici À mon avis, zéro est absolument important parce que vous essayez vraiment d’obtenir les résultats attendus. Et si les livrables ne sont pas épinglés, les livrables changent de forme.
C'est en quelque sorte mon opinion. C’est aussi mon opinion - je n’ai vraiment aucune objection à l’idée que vous deviez obtenir un bon niveau de détail dans la modélisation des données avant de passer à la suivante. Ce que je voudrais que vous essayiez de faire parce que je n’en ai pas une idée complète, c’est juste de décrire l’un de ces projets en termes de taille, de déroulement, de qui, vous savez, où les problèmes ont surgi, ont-ils été résolus? Parce que je pense que cette diapositive en est le cœur et que si vous pouviez en dire un peu plus à ce sujet, je vous en serais très reconnaissant.
Ron Huizenga: Bien sûr, et je vais utiliser quelques exemples de projets. Celui qui, en quelque sorte, a dérapé a été ramené en faisant participer les bonnes personnes et en effectuant la modélisation des données. Tout était vraiment une manière de s'assurer que la conception était mieux comprise et nous avions évidemment une meilleure conception d'implémentation. sur le chemin à travers en le modelant. Parce que lorsque vous modélisez, vous savez, vous pouvez générer votre DDL et tout le reste de l'outil, plutôt que de vous contenter de le construire, comme le font généralement les utilisateurs, en allant directement dans un environnement de base de données. Et ce qui arrivera généralement aux développeurs, c’est qu’ils y iront et qu’ils diront: bon, j’ai besoin de ces tables. Disons que nous faisons des entrées de commande. Ils peuvent donc créer l'en-tête de la commande et les tables de détail de la commande, etc. Mais ils oublieront souvent ou négligeront de s’assurer que les contraintes sont là pour représenter les relations de clé étrangère. Ils pourraient ne pas avoir les clés correctes. Les conventions de dénomination peuvent également être suspectes. Je ne sais pas combien de fois je suis allé dans un environnement, par exemple, où vous voyez un tas de tables différentes avec des noms différents, mais les noms de colonnes dans ces tables sont comme l'ID, le nom, etc. 'ai vraiment perdu le con sans la table de ce que c'est exactement.
Ainsi, lorsque nous modélisons des données, nous veillons généralement à appliquer les conventions de dénomination appropriées à tous les artefacts générés dans la DDL. Mais pour être plus précis sur la nature des projets eux-mêmes, c’est en général, je parle d’initiatives assez importantes. L’un d’eux était un projet de transformation de 150 millions de dollars dans lequel nous avons remplacé plus d’une douzaine de systèmes hérités. Nous avions cinq équipes agiles différentes simultanément. J'avais une équipe complète d'architectes de données; j'avais donc des modélisateurs de données de mon équipe intégrés dans chacune des autres équipes de domaine d'application, et nous travaillions avec une combinaison d'experts métier internes qui connaissaient le sujet, qui effectuaient les tâches suivantes: histoires d'utilisateurs pour les exigences elles-mêmes. Dans chacune de ces équipes, des analystes métiers étaient en train de modéliser le processus métier, avec les diagrammes d'activité ou les diagrammes de processus, contribuant à étoffer davantage les histoires d'utilisateurs avec les utilisateurs avant qu'ils ne soient également consommés par le reste de l'équipe.
Et bien sûr, les développeurs qui construisaient le code de l'application par dessus. Et nous travaillions également avec, je pense, quatre fournisseurs différents d'intégration de systèmes qui construisaient différentes parties de l'application. Une équipe était chargée de la construction des services de données, l'autre de la construction de la logique d'application dans un domaine, une autre possédant de l'expertise. dans un autre domaine d’activité, la logique applicative était en cours de construction. Nous avons donc eu toute une collaboration de personnes travaillant sur ce projet. Sur ce point en particulier, nous avions 150 personnes à terre dans l’équipe et 150 autres ressources à l’étranger dans l’équipe, qui collaboraient pendant deux semaines pour faire avancer les choses. Et pour ce faire, vous devez vous assurer de ne rien faire, et tout le monde est bien synchronisé en ce qui concerne les produits livrables. Vous avez également procédé à de fréquents réinitialisations pour vous assurer que nous livrions tous les artefacts nécessaires. à la fin de chaque s.
Dr Robin Bloor: C'est impressionnant. Et juste pour un peu plus de détails à ce sujet - vous êtes-vous retrouvé avec une carte complète, que j'appellerais, une carte MDM de l'ensemble de la zone de données à la fin de ce projet?
Ron Huizenga: Nous avions un modèle de données complet décomposé par décomposition entre tous les secteurs d'activité. Le dictionnaire de données lui-même en termes de définitions complètes est un peu court. Nous avons défini la plupart des tables; nous avions la plupart des colonnes définies exactement ce qu'elles signifiaient. Il y en avait qui n'étaient pas là et, ce qui est intéressant, beaucoup de ces informations provenaient des systèmes hérités où, après la fin du projet lui-même, elles étaient toujours documentées sous forme de série de reports. des artefacts, en quelque sorte, en dehors du projet lui-même, parce que c'était quelque chose qui devait être maintenu par l'organisation pour aller de l'avant. En même temps, l’organisation considérait de plus en plus l’importance de la gouvernance des données car nous avions constaté de nombreuses lacunes dans ces systèmes hérités et ces sources de données héritées que nous essayions de consommer car elles n’étaient pas documentées. Dans de nombreux cas, nous n'avions que des bases de données sur lesquelles nous devions faire de l'ingénierie inverse et essayer de comprendre ce qui était là et à quoi l'information était destinée.
Dr Robin Bloor: Cela ne me surprend pas, cet aspect particulier. Disons que la gouvernance des données est une préoccupation très moderne et je pense vraiment qu’il ya beaucoup de travail qui, disons, aurait dû être réalisé historiquement sur la gouvernance des données. Ce n'était jamais parce que vous pouviez, en quelque sorte, vous en sortir sans le faire. Mais comme les ressources de données venaient de croître, vous ne pouviez plus le faire.
Quoi qu’il en soit, je vais laisser la parole à Dez car je pense que j’ai le temps qui m’est imparti. Dez?
Dez Blanchfield: Oui merci. À travers tout cela, je regarde et je pense à moi-même que nous parlons de voir agile utilisé dans la colère de plusieurs façons. Bien que cela ait des connotations négatives; Je le pensais de manière positive. Pourriez-vous peut-être nous donner un scénario de, je veux dire, il y a deux endroits où je peux voir que c'est un ensemble parfait: l'un est de nouveaux projets qui doivent juste être faits dès le premier jour, mais je pense invariablement, d'après mon expérience, c'est souvent le cas où, lorsque les projets deviennent suffisamment importants pour que cela soit nécessaire à bien des égards, il y a un défi intéressant à relever entre le collage des deux mondes, n'est-ce pas? Pouvez-vous nous donner un aperçu des exemples de réussite que vous avez vus dans une organisation? Il est devenu clair qu'ils ont un léger conflit entre les deux mondes et que vous avez réussi à mettre en place cela en place et rassembler les grands projets là où ils auraient pu passer autrement? Je sais que la question est très large, mais je me demandais simplement si vous pouviez, en quelque sorte, indiquer une étude de cas. Indiquez où vous avez dit, vous savez, nous avons tout mis en place et nous avons réuni toute l’équipe de développement. l'équipe de données et nous avons, en quelque sorte, abordé quelque chose qui aurait autrement coulé le bateau?
Ron Huizenga: Bien sûr, et en fait, le projet qui se trouvait être un pipeline était celui auquel j'ai fait allusion, où j'ai montré ce diagramme avec les défauts avant et après que le modélisateur de données ait été impliqué. Assez souvent, et il y a des idées préconçues, en particulier si les choses se déroulent dans une perspective purement de développement, ce sont juste les développeurs qui participent à ces projets agiles pour livrer les applications. Donc, ce qui s’est passé là-bas, bien sûr, c’est qu’ils ont déraillé et que leurs artefacts de données, ou les livrables de données qu’ils produisaient, n’ont pas été à la hauteur en ce qui concerne la qualité et le traitement global. Et il ya assez souvent cette idée fausse selon laquelle les modélisateurs de données vont ralentir les projets, et ils le feront si le modélisateur de données n’a pas la bonne attitude. Comme je le disais, vous devez perdre le - parfois il existe des modélisateurs de données qui adoptent cette attitude traditionnelle du contrôleur: «nous sommes ici pour contrôler l’apparence des structures de données» et cette mentalité doit disparaître. Toute personne impliquée dans le développement agile, et en particulier les modélisateurs de données, doit jouer un rôle de facilitateur afin d’aider réellement les équipes à progresser. Et le meilleur moyen d'illustrer cela est de montrer très rapidement à des équipes à quel point elles peuvent être productives en modélisant d'abord les changements. Et encore une fois, c’est la raison pour laquelle j’ai parlé de collaboration.
Nous pouvons modéliser d’abord certaines choses et générer le DDL pour les proposer aux développeurs. Nous voulons également nous assurer qu’ils ne se sentent pas restreints. Par conséquent, s’ils travaillent sur certains éléments, laissez-les continuer à travailler dans leurs sandbox de développement, car c’est là que les développeurs travaillent sur leur propre ordinateur de bureau ou dans une autre base de données pour apporter certaines modifications lorsqu’ils testent. Et collaborez avec eux et dites: «D'accord, travaillez avec ça." Nous allons l'introduire dans l'outil, nous allons le résoudre, puis nous le ferons avancer et vous donnerons les scripts que vous pourrez déployer pour mettre à jour votre ordinateur. bases de données pour les mettre à niveau vers ce que sera réellement la véritable vision de la production sanctionnée au fur et à mesure de notre progression. Et vous pouvez remédier à cela très rapidement. J'ai constaté que mes journées étaient remplies et que je ne faisais qu'aller et revenir, itérant avec différentes équipes de développement, en examinant les changements, en comparant, en générant des scripts, en les faisant fonctionner, et j'ai été capable de gérer moi-même assez facilement quatre équipes de développement atteint un élan.
Dez Blanchfield: L’une des choses qui me viennent à l’esprit, c’est que, vous savez, un grand nombre de conversations que j’entends quotidiennement portent sur ce train de marchandises qui nous arrive, en quelque sorte, de machine à machine et IdO. Et si nous pensons que nous avons beaucoup de données sur nos environnements actuels dans les entreprises, vous savez, si nous prenons les licornes de côté pour un moment où nous savons que les googles et les s et les Ubers ont des pétaoctets de données, mais dans une entreprise traditionnelle, nous parlons encore de centaines de téraoctets et de nombreuses données. Mais à mon avis, ce train de marchandises arrive dans des organisations, et le Dr Robin Bloor y a fait allusion plus tôt, de l’IoT. Vous savez, nous avons beaucoup de trafic Web, social, de mobilité et d'appareils mobiles, le cloud a en quelque sorte explosé, mais nous avons maintenant une infrastructure intelligente, des villes intelligentes. et il y a tout ce monde de données qui vient d'exploser.
Pour une organisation de tous les jours, une organisation de moyenne à grande taille qui est assise là et qui voit ce monde de douleur l’atteindre sans projet immédiat, quelles sont les choses à retenir, en quelques phrases, que vous mettriez pour eux quand et où ils doivent commencer à réfléchir à la mise en place de certaines de ces méthodologies. Combien de temps faut-il au début de la planification pour se lever et dire que c’est le bon moment pour mettre en place certains outils et former l’équipe et engager une conversation de vocabulaire autour de ce défi? Il est trop tard ou quand est-il trop tard dans l’histoire? À quoi cela ressemble-t-il pour certaines des organisations que vous voyez?
Ron Huizenga: Pour la plupart des entreprises, je dirais que si elles ne l’ont pas déjà fait et n’ont pas adapté la modélisation des données et l’architecture des données avec des outils puissants comme celui-ci, le temps dont elles ont besoin pour le faire est hier. Parce qu'il est intéressant de noter que, même aujourd'hui, lorsque vous examinez les données dans les organisations, nous en avons tellement que dans nos organisations. En général, d'après certaines enquêtes, nous utilisons efficacement moins de cinq pour cent de ces données. quand on regarde à travers les organisations. Et avec l'IoT ou même NoSQL, le Big Data - même s'il ne s'agit pas que d'IoT, mais simplement de Big Data -, où nous commençons à consommer de plus en plus d'informations provenant de l'extérieur de nos organisations, ce défi devient de plus en plus grand. tout le temps. Et le seul moyen de nous en sortir est de nous aider à comprendre en quoi consistent ces données.
Le cas d'utilisation est donc un peu différent. Ce que nous constatons, c’est que lorsque nous examinons ces données, nous les capturons, nous devons procéder à une ingénierie inverse, voir ce qu’elles contiennent, que ce soit dans nos bases de données ou même dans nos bases de données internes, synthétiser ce que data is, appliquez-lui des significations et des définitions afin que nous puissions comprendre ce qu’elles sont. Parce que tant que nous n’aurons pas compris ce que c’est, nous ne pouvons pas garantir que nous l’utilisons correctement ou adéquatement. Nous devons donc vraiment savoir quelles sont ces données.De plus, ne le faites pas, car vous pouvez, en termes de consommation de toutes ces données externes, vous assurer que votre cas d'utilisation prend en charge la consommation de ces données externes. Concentrez-vous sur les choses dont vous avez besoin plutôt que d'essayer de tirer et d'utiliser les choses dont vous pourriez avoir besoin plus tard. Concentrez-vous d'abord sur les éléments importants et, au fur et à mesure de votre progression, vous pourrez consommer et essayer de comprendre les autres informations de l'extérieur.
L’exemple parfait est que je sais que nous parlons d’IoT et de capteurs, mais le même type de problème existe dans de nombreuses organisations depuis de nombreuses années, même avant l’IoT. Quiconque possède un système de contrôle de la production, qu'il s'agisse d'une société pipelinière, d'une société de fabrication, ainsi que de toute entreprise basée sur des processus qui automatise beaucoup ses contrôles et utilise des flux de données, entre autres, a Ces sources de données qu’ils essaient de comprendre pour savoir quels sont les événements survenus dans mon équipement de production pour signaler - que s’est-il passé et quand? Et parmi cet énorme flot de données, il n’existe que des éléments d’information ou des balises spécifiques dont ils ont besoin pour filtrer, synthétiser, modéliser et comprendre. Et ils peuvent ignorer le reste jusqu'à ce qu'il soit temps de vraiment le comprendre, puis élargir leur champ d'action pour en extraire de plus en plus, si cela a du sens.
Dez Blanchfield: C'est le cas, en effet. Il y a une question à laquelle je vais m'attarder qui a été posée par un homme appelé Eric, et nous en avons parlé en privé. Je viens de lui demander la permission, qu’il nous a donnée, de vous la demander. Parce que cela nous amène à cela, pour terminer, parce que nous dépassons un peu le temps maintenant, et je céderai la parole à Eric. Mais la question posée par un autre Eric était la suivante: est-il raisonnable de supposer que les propriétaires d’une start-up connaissent et comprennent les défis uniques posés par la modélisation de la terminologie, ou doit-elle être confiée à une autre personne pour interprétation? Donc, en d’autres termes, une startup doit-elle être capable, disposée et désireuse et capable de se concentrer sur cela? Ou est-ce quelque chose qu'ils devraient probablement acheter et faire venir des experts?
Ron Huizenga: Je suppose que la réponse courte est que cela dépend vraiment. Si c'est une start-up qui n'a pas en interne d'architecte de données ou de modélisateur qui comprend vraiment la base de données, le moyen le plus rapide de commencer est de faire appel à une personne ayant une formation en consultation très bien maîtrisée dans cet espace et pouvant obtenir les aller. Parce que ce que vous découvrirez - et en fait, je l'ai fait pour de nombreuses missions que j'ai faites avant de passer du côté obscur de la gestion de produits - est que j'irais dans des organisations en tant que consultant, dirigerais leurs équipes d'architecture de données, afin qu’ils puissent, en quelque sorte, se recentrer et former leur personnel sur la façon de faire ce genre de choses de manière à le maintenir et à mener à bien la mission. Et ensuite, je passerais à mon prochain engagement si cela avait du sens. Il y a beaucoup de gens qui font ça, qui ont une très bonne expérience de données qui peuvent les faire avancer.
Dez Blanchfield: C’est un excellent point à retenir et je suis tout à fait d’accord avec lui et je suis sûr que le Dr Robin Bloor le ferait également. Dans une start-up en particulier, vous souhaitez avant tout être une PME sur la valeur particulière de la proposition que vous souhaitez construire dans le cadre de votre entreprise en phase de démarrage. Vous ne devriez probablement pas avoir besoin d'être un expert en la matière, donc des conseils avisés. Mais merci beaucoup, une présentation fantastique. Vraiment d'excellentes réponses et questions. Eric, je vais vous rendre la parole parce que je sais que nous sommes partis probablement plus de dix minutes et que vous aimez rester près de nos fenêtres horaires.
Eric Kavanagh: C'est bon. Nous avons au moins deux bonnes questions. Laissez-moi vous en jeter un. Je pense que vous avez répondu à certains des autres. Mais une observation très intéressante et une question d’un participant qui écrit, parfois des projets agiles, montrent que le modélisateur de données n’a pas l’image complète à long terme. Ils finissent donc par concevoir quelque chose dans la première et devoir ensuite la refaire par trois ou quatre. Cela ne semble-t-il pas contre-productif? Comment pouvez-vous éviter ce genre de chose?
Ron Huizenga: C’est simplement en raison de la nature agile que vous n’allez pas tout obtenir parfaitement dans un s donné. Et cela fait partie de l’esprit d’agile, c’est: travailler avec cela - vous allez faire du prototypage en travaillant sur du code dans un environnement donné, et vous allez l’affiner. Et une partie de ce processus consiste en ce que vous livrez des choses que l'utilisateur final voit et dit: «Oui, c'est proche, mais j'ai vraiment besoin que ça fasse un peu plus aussi." Donc, cela n'a pas seulement un impact sur la conception fonctionnelle. du code lui-même, mais nous avons souvent besoin de modifier ou d’ajouter plus de structure de données sous ces éléments afin de fournir ce que l’utilisateur souhaite. Et c’est un jeu équitable. C’est pourquoi vous souhaitez réellement utiliser les outils les plus performants, car vous pouvez très rapidement modéliser et apporter cette modification dans un outil de modélisation, puis générer le DDL de la base de données sur laquelle les développeurs peuvent ensuite travailler pour fournir ce résultat. changer encore plus vite. Vous leur évitez ainsi de coder manuellement les structures de données et de les laisser se concentrer sur la logique de programmation ou d’application pour laquelle ils sont les plus compétents.
Eric Kavanagh: Cela fait sens. Quelques autres personnes ont simplement posé des questions précises sur le lien entre tout cela et l'outil. Je sais que vous avez passé un certain temps à passer en revue des exemples et que vous montrez des captures d’écran montrant comment vous déployez certaines de ces choses. En ce qui concerne tout ce processus, combien de fois voyez-vous cela en jeu dans les organisations par rapport à combien de fois voyez-vous des processus plus traditionnels où les choses marchent juste, en quelque sorte et prennent plus de temps? Quelle est la prévalence de l'approche s-style de votre point de vue?
Ron Huizenga: Je pense que nous le voyons de plus en plus. Je sais que, je dirais, probablement au cours des 15 dernières années en particulier, j’ai vu beaucoup plus de gens adopter, reconnaissant qu’ils doivent vraiment adopter une livraison plus rapide. J’ai donc vu de plus en plus d’organisations suivre le mouvement agile. Pas nécessairement entièrement; ils peuvent commencer par quelques projets pilotes pour prouver que cela fonctionne, mais certains sont encore très traditionnels et ils restent fidèles à la méthode de la cascade. La bonne nouvelle, c’est bien sûr que les outils fonctionnent très bien dans ces organisations également pour ce type de méthodologies, mais nous avons l’adaptabilité dans l’outil, de sorte que ceux qui se joignent à eux disposent des outils dans la boîte à outils: leurs doigts. Des fonctionnalités telles que la comparaison et la fusion, des fonctionnalités telles que les fonctionnalités de reverse engineering, afin de pouvoir identifier les sources de données existantes, afin de pouvoir comparer et générer très rapidement les scripts DDL incrémentaux. Et au fur et à mesure qu’ils commencent à comprendre cela et s’aperçoivent qu’ils peuvent avoir une productivité accrue, leur envie de passer à l’agile augmente encore.
Eric Kavanagh: Eh bien, c’est formidable, les gars. Je viens de poster un lien vers les diapositives dans la fenêtre de discussion, alors jetez-y un coup d'œil; c’est un peu Bitly qui vous tient à cœur. Nous avons toutes ces webémissions pour les visionner plus tard. N'hésitez pas à les partager avec vos amis et collègues. Et Ron, merci beaucoup pour le temps que vous avez passé aujourd’hui, vous êtes toujours agréable à l’émission - un véritable expert dans le domaine et il est évident que vous connaissez votre matériel. Donc, merci à vous et à IDERA et, bien sûr, à Dez et à notre propre Robin Bloor.
Et avec cela, nous allons vous dire au revoir, chers amis. Merci encore pour votre temps et votre attention. Nous vous remercions de rester 75 minutes, c’est un bon signe. Bon spectacle les gars, nous vous parlerons la prochaine fois. Bye Bye.