Modélisation des données dans un environnement agile

Par Techopedia Staff, 16 novembre 2016

À retenir: l' hôte Eric Kavanagh discute de 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: D'accord, mesdames et messieurs. Bienvenue encore une fois. C'est mercredi à 16h00 HNE. Cela signifie qu'il est temps 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 oldie mais un goodie. Il s'améliore chaque jour parce qu'il façonne notre monde de gestion des données, «Modélisation des données dans un environnement agile». Il y a vraiment une diapositive sur la vôtre, contactez-moi sur Twitter @eric_kavanagh. Nous devrions vraiment le mettre sur cette diapositive. Je vais devoir m'y mettre.

Alors l'année est chaude. La modélisation des données existe depuis toujours. Cela a vraiment été au cœur et à l'âme de la gestion de l'information, à concevoir des modèles de données, à essayer de comprendre les modèles commerciaux et à les aligner sur vos modèles de données. C'est vraiment ce que vous essayez de faire, non?

Le modèle de données représente l'entreprise de manière fondamentale, alors comment toutes ces nouvelles sources de données changent-elles le jeu? Nous allons découvrir cela. Nous allons découvrir comment vous pouvez rester au top des choses de manière agile. Et bien sûr, c'est le mot de l'année.

Robin Bloor est avec nous, notre analyste en chef, Dez Blanchfield, appelle de Sydney, en Australie et Ron Huizenga, chef de produit senior chez IDERA - un ami de longue date, excellent conférencier dans cet espace, connaît son affaire, alors ne soyez pas timide, demandez lui les questions difficiles, les gens, les difficiles. Avec cela, je vais faire de Robin le présentateur et l'emporter.

Dr Robin Bloor: D'accord. Merci pour ça, Eric. Je dois dire à propos de la modélisation que je pense, j'étais en fait dans le monde de l'informatique avant son existence, dans le sens où je me souviens de la compagnie d'assurance pour laquelle je travaillais, que nous avions un gars qui venait nous donner à tous une sorte d'atelier sur la modélisation des données. Nous envisageons donc environ 30 ans, est-ce 30 ans? Peut-être même plus longtemps que cela, il y a peut-être 35 ans. Une modélisation de très longue date a en fait fait partie de l'industrie et bien sûr, cela n'a rien à voir avec les femmes sur les podiums.

La chose 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 donner un aperçu général de la modélisation, mais il y a une réalité à cela, qui devient maintenant évidente.

Nous avons, vous savez, la réalité des mégadonnées, 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 qui commencent à en obtenir une plus grande partie, et il y a un plus grand besoin de comprendre les données et une augmentation du taux de changement qui est plus de données ajoutées et aussi plus de structures de données utilisées.

C'est un monde difficile. Voici une photo de cela, qui est en fait quelque chose que nous avons dessiné il y a environ trois ans, mais en gros, une fois que vous incluez le streaming dans le mix et que vous avez cette idée de raffinerie de données, de hub de données, de liaison de données ou autre, vous voyez qu'il y a des données qui sont véritablement au repos, dans le sens où ça 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 avoir besoin, et de nos jours avec les architectures lambda dont tout le monde parle, sont vraiment ayant un impact sur tout le domaine des données.

Et de nos jours, pensez à l'existence d'une couche de données. La couche de données existe d'une manière virtuelle, dans le sens où une bonne partie de celle-ci peut être dans le cloud et peut être répartie entre les centres de données, elle peut exister sur les postes de travail. La couche de données est, dans une certaine mesure, partout et dans ce sens, il y a 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 aussi de quoi il s'agit lorsque vous le déplacez est un gros problème.

Si nous regardons la modélisation des données dans le sens le plus général, au bas de ce type de pile, vous avez 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.

Ce qui est intéressant avec les métadonnées, c'est que les métadonnées sont entièrement la façon dont les données prennent leur sens. Si vous ne disposez 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 façon 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 termes de données que nous traitons réellement dans le monde, les métadonnées ont un sens et la structure des métadonnées - un élément de données par rapport à un autre et ce que cela signifie quand ils sont rassemblés et ce que cela signifie quand ils '' re joint avec d'autres données, exige que nous le modélisons. Il ne suffit pas d'enregistrer des balises de métadonnées sur des choses, vous devez en fait enregistrer la signification par structures et la relation entre les structures.

Ensuite, nous avons à la couche supérieure, les définitions d'entreprise, qui est normalement une couche qui tente de transférer du sens entre les métadonnées, qui est une forme de définition de données qui s'adapte à la façon 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, des concepts au niveau de l'entité qui existent dans cette couche. Et si nous allons avoir une incohérence entre ces couches, nous devons avoir une modélisation des données. Ce n'est pas vraiment facultatif. Plus vous pouvez réellement le faire en termes d'automatisation, mieux c'est. Mais parce que c'est lié au sens, il est vraiment difficile d'alterner. Il est assez facile de capturer les métadonnées dans un enregistrement et de pouvoir les obtenir à partir d'une série de significations, mais cela ne vous dit pas la structure des enregistrements ni la signification des enregistrements ou le contexte de l'enregistrement.

C'est donc à cela que sert la modélisation des données. Points à noter: plus l'univers de données devient complexe, plus vous devez le modéliser. En d'autres termes, c'est un peu comme si nous ajoutions non seulement plus d'instances de choses au monde, ce qui correspondrait à des enregistrements de données, mais nous ajoutons en fait plus de sens 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 y a un univers de données et nous avons besoin d'une vue de celui-ci. En pratique, les métadonnées réelles font partie de l'univers de données. Ce n'est donc pas une situation simple. Commencer la modélisation est de haut en bas et de bas en haut. 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, qui doivent les traiter, mais elles ont un sens en soi. Donc, vous avez besoin d'une signification ascendante, qui satisfait le logiciel qui a besoin d'accéder aux données et vous avez besoin de la signification descendante pour que les êtres humains puissent les 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, où ce n'est pas le cas et où les choses deviennent hors de contrôle en conséquence.

À l'avenir, la modélisation augmente avec l'importance à mesure que la technologie progresse. Voilà mon opinion. Mais si vous regardez l'IoT, nous pouvons mieux comprendre le mobile qu'auparavant, bien qu'il introduise de nouvelles dimensions: la dimension de l'emplacement avec le mobile. Une fois que vous arrivez à l'IoT, nous examinons des problèmes de données extraordinaires que nous n'avions jamais eu à faire auparavant et que nous devons, d'une manière ou d'une autre, pour bien comprendre exactement ce que nous avons, exactement comment nous pouvons l'agréger, ce que nous pouvons faire pour obtenir un sens à partir de l'agrégation, et bien sûr, ce que nous pouvons en faire, lorsque nous l'avons traité.

Je pense que c'est moi qui en ai assez dit. Je vais passer à Dez Blanchfield, qui dira autre chose.

Dez Blanchfield: Merci. C'est toujours un acte difficile à suivre, mais c'est un sujet sur lequel nous nous sommes mis d'accord et en avons parlé brièvement dans les plaisanteries du préshow, et si vous aviez appelé tôt, vous auriez probablement attrapé tout un tas de superbes gemmes. L'un des plats à emporter, et je ne veux pas voler le tonnerre de celui-ci en particulier, mais l'un des plats à emporter de nos plaisanteries avant le show que je veux partager, au cas où vous ne l'auriez pas attrapé, était juste autour du sujet de le voyage des données, et cela m'a frappé de l'écrire en pensant au voyage que les données font dans un contexte différent autour de la durée de vie générationnelle - année, mois, semaine, jour, heure, minute, seconde - et le contexte autour des données sont positionnés dans ce contexte. Que je sois un développeur exécutant du code ou que je sois un spécialiste des données et que je pense à la structure et au format et aux métadonnées autour de chacun des éléments, ou à la façon dont les systèmes et l'entreprise interagissent avec.

C'est un petit point intéressant à noter, mais de toute façon, laissez-moi plonger. La conception de données, en particulier, est une expression que j'utilise pour parler de tout ce qui concerne les données et en particulier du développement d'applications ou d'infrastructure de base de données. Je pense que la conception de données est un terme qui capture tout cela très bien dans ma tête. Ces jours-ci, lorsque nous parlons de conception de données, nous parlons de conception de données agile moderne, et mon avis est 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 des pièces de design sont passées d'un silo à l'autre. Mais je suis beaucoup d'avis ces jours-ci, non seulement c'est le cas qui a changé, mais il doit changer; c'est une sorte de 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 localisation et de base de données, la modélisation et la gestion globale défi autour de cela. C'est un sport d'équipe maintenant et donc ma photo d'un groupe de personnes sautant d'un avion agissant en équipe pour jouer cette image visuellement intéressante de personnes tombant dans le ciel.

Troisièmement, que s'est-il passé pour provoquer cela? Eh bien, il y a un article en 1986 écrit par un couple de messieurs dont j'ai essayé désespérément de rendre justice, Hirotaka Takeuchi et Ikujiro Nonaka, je pense qu'il est prononcé, a produit un article qu'ils ont intitulé "Moving the Scrum Downfield". cette idée d'une méthodologie pour gagner un match de rugby à partir de cette activité de mêlée, où tout le monde se déplace au même endroit et deux équipes verrouillent essentiellement la tête dans ce qu'on appelle une mêlée pour essayer de prendre le contrôle du ballon et de le jouer sur le terrain pour arriver à la ligne d'essai et toucher le sol avec le ballon et obtenir un point, appelé un trigone, et vous répétez ce processus et vous obtenez plus de points pour l'équipe.

Cet article a été publié en 1986 dans la Harvard Business Review et, curieusement, il a attiré 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 la mêlée du rugby du jeu et l'ont introduit dans les affaires et en particulier dans le jeu de la conception et de la livraison de projet, en particulier la livraison de projet.

Ce que Scrum a fait nous a donné une nouvelle méthodologie par rapport aux goûts de PRINCE2 ou PMBOK que nous avions précédemment utilisés dans ce que nous appelions la méthodologie de la cascade, vous savez, faites cette chose et cette chose et cette chose et suivez-les en séquence et connectez-vous tous les points autour, ce qui dépend de ce que vous aviez, ou ne faites pas la deuxième partie jusqu'à ce que vous ayez fait la première partie, car 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 vient, sur la façon dont nous livrons les choses, et plus particulièrement sur la conception et le développement de la livraison de projets de base.

Certains des locataires clés - pour que je continue avec ça - sont autour des locataires clés de la mêlée. Cela a introduit l'idée de construire l'instabilité, que si vous pensez à la peur du chaos, le monde existe dans un état de chaos, mais la planète s'est formée, ce qui est intéressant, donc construire l'instabilité, la capacité de rebondir un peu et faire toujours fonctionner les choses, des équipes de projet auto-organisées, des faveurs qui se chevauchent grâce à un développement très responsable, différents types d'apprentissage et de contrôle tout au long du parcours de livraison du projet, le transfert organisationnel de l'apprentissage. Alors, comment pouvons-nous prendre des 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 ou ne développent pas de bases de données et d'infrastructures, mais des données pour ces personnes? Et spécifiquement des résultats temporels. En d'autres termes, faisons cela pendant une période de temps, soit une journée comme dans 24 heures, soit une semaine ou quelques semaines et voyons ce que nous pouvons faire, puis reculons et examinons cela.

Et donc, si vous pardonnez le jeu de mots, c'est vraiment un nouveau jeu dans la livraison de projet et les trois composants de base qui auront du sens si nous avançons un peu plus loin ici - il y a le produit: toutes ces personnes 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 standups quotidiens 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, les gens, nous avons entendu parler de Scrum Masters qui supervisent tout cela et comprennent suffisamment la méthodologie pour la piloter. Nous avons tous vu ces images que j'ai sur le côté droit ici des murs et des tableaux blancs remplis de notes Post-It et ils ont été servis de murs Kanban. Si vous ne savez pas qui est Kanban, je vous invite à Google qui était M. Kanban et pourquoi cela a changé la façon dont nous déplaçons les choses d'un côté à l'autre dans un mur littéralement mais dans un projet.

En un coup d'œil, le flux de travail Scrum fait ceci: il prend une liste de choses qu'une organisation veut faire, les exécute à travers une série de choses que nous appelons des sprints qui sont divisés en périodes de 24 heures, des périodes d'un mois, et nous obtenir cette série incrémentielle de sorties. C'est un changement important dans la façon dont les projets sont livrés, ont été livrés à ce stade parce qu'une partie de cela coule comme l'armée américaine qui a eu une grande partie du développement de quelque chose appelé PMBOK, comme l'idée de ne pas emmener le char sur le terrain jusqu'à ce que vous mettiez des balles dans la chose parce que si un tank sur le terrain n'a pas de balles, c'est inutile. Donc donc la première partie est de mettre des balles dans le réservoir, la deuxième partie est de mettre le réservoir sur le terrain. Malheureusement, ce qui s'est passé avec les développeurs dans le monde du développement a en quelque sorte mis la main sur cette méthodologie agile et a couru avec elle, si vous pardonnez le jeu de mots, lors d'un sprint.

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 concerne le monde des bases de données. Ce fut un résultat malheureux car la réalité est que l'agilité ne se limite pas aux développeurs. En fait, le terme agile à mon avis 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 rencontrés dans tout ce qui concerne la conception et le développement et l'exploitation et la maintenance et donc de l'infrastructure de données et en particulier des bases de données. Les acteurs de cette distribution de données particulière comprennent les architectes de données, les mouleurs, les administrateurs, les gestionnaires des infrastructures de bases de données et les bases de données elles-mêmes jusqu'aux analystes et architectes commerciaux et systèmes, les personnes qui s'asseyent et réfléchissent à la façon dont les systèmes et les affaires fonctionnent et comment nous avons pu faire circuler les données à travers celles-ci.

C'est un sujet que j'aborde régulièrement parce que c'est une frustration constante en ce sens que je suis très convaincu que les spécialistes des données doivent - et non devraient - doivent désormais être intimement impliqués dans chaque composante de la livraison du projet, en particulier, en particulier le développement. Pour nous de ne pas, alors nous ne nous donnons vraiment pas la meilleure chance pour un bon résultat. Nous devons souvent revenir en arrière et réfléchir à nouveau à ces choses 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 autour des données, et construit une expérience. Vous ne devenez pas seulement instantanément un gourou de la base de données ou un expert en connaissance des données du jour au lendemain; c'est souvent quelque chose qui vient d'une expérience de toute une vie et certainement avec les goûts du Dr Robin Bloor sur le Code Today, qui a assez richement écrit le livre.

Dans de nombreux cas - et c'est malheureux mais c'est une réalité - qu'il y a deux parties de cette pièce, c'est-à-dire que les développeurs de logiciels ont leur propre panne de spécialiste de base de données et ont développé les compétences dont vous avez besoin dans la modélisation de conception de base de données, fondamentale pour l'ingénierie des gourous sur la façon dont les données entrent et comment l'organisation du voyage qu'elles prennent et à quoi elles devraient ou ne devraient pas ressembler, ou sans aucun doute cela a été ingéré et comprend qu'il est généralement obtenu dans des compétences natives définies pour les développeurs de logiciels. Et certains des défis communs auxquels nous sommes confrontés, pour mettre cela en contexte, comprennent la création de base, la maintenance et la gestion de la conception de la base de données elle-même, la documentation des données et de l'infrastructure de la base de données, puis la réutilisation de ces actifs de données, la conception des schémas, les générations de schémas, l'administration et la maintenance du schéma et son utilisation, le partage des connaissances sur les raisons pour lesquelles ce schéma est conçu d'une manière particulière et les forces et les faiblesses qui l'accompagnent au fil du temps provoquent des changements de données au fil du temps, la modélisation des données 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 et intégration, puis modélisation des données autour d'eux, puis accès plus rapide pour contrôler la sécurité autour des données, l'intégrité des données est que nous déplaçons les données tout en conservant leur intégrité, y a-t-il suffisamment de métadonnées autour cela, les ventes devraient-elles voir tous les enregistrements dans le tableau ou devraient-elles seulement voir l'adresse, le prénom, le nom de famille qui vous envoie des choses 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 en soi une conversation différente.

Je suis vraiment d'avis qu'avec tout cela à l'esprit pour rendre tout ce nirvana possible, il est absolument essentiel que les spécialistes des données et les développeurs disposent des outils appropriés et que ces outils soient capables de livrer des projets en équipe, conception, développement et maintenance opérationnelle continue. Vous savez, des choses comme la collaboration entre projets entre experts en données et développeurs de logiciels, un seul point de vérité ou une seule 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, d'où proviennent les enregistrements, les propriétaires de ces enregistrements . Je pense qu'aujourd'hui c'est absolument essentiel, nous allons obtenir ce nirvana de données étant roi, que les bons outils doivent être en place parce que le défi est trop grand maintenant pour nous de le faire manuellement, et si les gens 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 pourrait mettre en place et qui ne transfère pas nécessairement ces compétences et capacités à l'avenir.

Dans cet esprit, je vais me diriger vers notre bon ami chez IDERA et entendre parler de cet outil et de la façon dont il traite ces choses.

Ron Huizenga: Merci beaucoup et merci à Robin et Dez d'avoir vraiment bien préparé la scène, et vous allez voir un peu de chevauchement dans quelques-unes des choses dont j'ai parlé. Mais ils ont vraiment jeté des bases très solides pour certains des concepts dont je vais parler du point de vue de la modélisation des données. Et beaucoup de choses qu'ils ont dites font écho à ma propre expérience lorsque j'étais consultant travaillant dans la modélisation et l'architecture de données, avec des équipes - à la fois en cascade au début et en évoluant vers des produits plus modernes avec des projets où nous utilisions l'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 tout au long de ce voyage. Ce que je vais couvrir très brièvement, c'est que je ne vais pas entrer dans la mêlée avec beaucoup de détails; nous venons d'avoir un très bon aperçu de ce que c'est. Je vais en parler en termes de, qu'est-ce qu'un modèle de données et qu'est-ce que cela signifie vraiment pour nous? Et comment pouvons-nous activer le concept du modélisateur de données agile dans nos organisations, en termes de, comment impliquer les modélisateurs de données, quelle est la participation des modélisateurs et architectes pendant le sprint, quels sont les types d'activités dans lesquels ils devraient être engagés et, en toile de fond, quelles sont quelques-unes des capacités importantes des outils de modélisation que nous utilisons pour vraiment faciliter ce travail? Ensuite, je vais faire un peu de récapitulation et parler un peu de certaines des valeurs commerciales et des avantages d'avoir un modélisateur de données impliqué, ou de la façon dont je vais réellement raconter l'histoire: les problèmes de ne pas avoir un modélisateur de données pleinement engagé dans les projets et je vais vous montrer cela sur la base de l'expérience et d'un tableau de défauts d'une image avant et après d'un projet réel avec lequel j'ai été impliqué il y a de nombreuses années. Et puis nous résumerons quelques points de plus, puis nous aurons des questions et réponses en plus de cela.

Très brièvement, ER Studio est une suite très puissante qui comporte de nombreux composants différents. L'architecte de données, où les modélisateurs et architectes de données passent la plupart de leur temps à modéliser leurs données. Il y a aussi d'autres composants dont nous n'allons pas parler du tout aujourd'hui, comme le Business Architect, où nous faisons de la modélisation de processus et le Software Architect, pour une partie de la modélisation UML. Ensuite, il y a le référentiel, où nous nous enregistrons et nous partageons les modèles et nous permettons aux équipes de collaborer sur ceux-ci et de les publier sur le serveur d'équipe afin que plusieurs publics de parties prenantes engagés dans un projet puissent réellement voir les artefacts que nous '' re la création d'un point de vue des données ainsi que les autres choses que nous faisons dans la livraison du projet lui-même.

Ce sur quoi je vais me concentrer aujourd'hui va être quelques choses que nous allons voir dans Data Architect et parce qu'il est vraiment important que nous ayons la collaboration des aspects basés sur le référentiel de cela. En particulier lorsque nous commençons à parler de concepts comme la gestion du changement qui sont impératifs, non seulement pour les projets de développement agiles, mais pour tout type de développement à l'avenir.

Parlons donc un instant du Agile Data Modeler. Comme nous l'avons, en quelque sorte, mentionné plus tôt dans la présentation, il est impératif que nous ayons des modélisateurs de données et / ou des architectes pleinement impliqués dans les processus de développement agiles. Maintenant, ce qui s'est passé historiquement, c'est que oui, nous avons vraiment pensé à l'agilité du point de vue du développement, et il y a deux ou trois choses qui se sont produites qui ont vraiment provoqué cela. Cela est dû en partie à la nature même du déroulement du développement lui-même. Comme le développement agile a commencé et nous avons commencé avec ce concept d'équipes auto-organisées, si vous buviez le Kool-Aid un peu trop pur et que vous étiez du côté de la programmation extrême, il y avait une interprétation très littérale de choses comme le équipes auto-organisées, ce que beaucoup de gens ont interprété comme signifiant, tout ce dont nous avons besoin est un groupe de développeurs capables de construire une solution entière. Qu'il s'agisse de développer le code, les bases de données ou les banques de données derrière et tout a été relégué aux développeurs. Mais ce qui se passe avec cela, c'est que vous perdez les capacités spéciales des gens. J'ai trouvé que les équipes les plus fortes sont celles qui sont composées de personnes d'horizons différents. Comme une combinaison de développeurs de logiciels, d'architectes de données, de modélisateurs de données, d'analystes commerciaux et de parties prenantes, tous collaborant ensemble pour élaborer une solution finale.

Ce dont je parle également aujourd'hui, c'est que je vais le faire dans le cadre d'un projet de développement où nous développons une application qui, bien entendu, sera également associée à la composante de données. Nous devons cependant faire un pas en arrière avant de le faire, car nous devons réaliser qu'il y a très peu de projets de développement Greenfield là-bas où nous nous concentrons totalement sur la création et la consommation de données qui ne sont limitées que dans ce projet de développement lui-même. . 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. Parce que 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élisateurs et architectes, nous mettons cela en lumière afin que nous sachions où trouver ces informations 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 contexte de l'application que nous construisons. Nous devons modéliser les données et nous assurer que nous les documentons car elles vivent bien 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 l'application, mais également pour les décisions qui rendent compte des activités, des rapports BI et de l'intégration à d'autres applications, internes et externes à nos organisations. Nous devons donc examiner cette vue d'ensemble des données et le cycle de vie de ces données et comprendre le parcours des éléments d'information dans toute l'organisation, du berceau à la tombe.

Maintenant, revenons aux équipes elles-mêmes et à la façon dont nous devons réellement travailler, la méthodologie de la cascade a été perçue comme trop lente pour produire des résultats. Parce que, comme le montre l'exemple du réservoir, c'était une étape après l'autre et cela prenait souvent trop de temps pour fournir un résultat final réalisable. Ce que nous faisons maintenant, c'est que nous devons avoir un style de travail itératif où nous en développons progressivement les composants et l'élaborons au fil du temps où nous produisons du code utilisable ou des artefacts utilisables, je vais dire, pour chaque sprint. L'important est la collaboration entre les parties prenantes techniques de l'équipe et les parties prenantes de l'entreprise, car nous collaborons pour transformer ces histoires d'utilisateurs en une vision implémentable du code et des données qui prennent également en charge ce code. Et le modèle de données agile lui-même constatera souvent que nous n'avons pas suffisamment de modélisateurs dans les organisations, de sorte qu'un modélisateur de données ou un architecte peut simultanément prendre en charge plusieurs équipes.

Et l'autre aspect est que, même si nous avons plusieurs modélisateurs, nous devons nous assurer que nous avons un ensemble d'outils que nous utilisons qui permet la collaboration de plusieurs projets qui sont en vol en même temps et le partage de ceux-ci artefacts de données et les capacités de check-in et check-out. Je vais y revenir très rapidement car nous l'avons déjà abordé dans la section précédente. La vraie prémisse de l'agilité est que vous basez les choses sur l'arriéré, les histoires ou les exigences. Dans les itérations, nous collaborons en tant que groupe. En règle générale, un sprint de deux semaines ou d'un mois, selon l'organisation, est très courant. Et aussi des réunions de révision et de standup quotidiennes afin d'éliminer les bloqueurs et de nous assurer que nous avançons tous les aspects sans nous arrêter dans différents domaines au fur et à mesure. Et dans ces sprints, nous voulons nous assurer que nous produisons des livrables utilisables dans le cadre de chaque sprint.

Juste un point de vue légèrement différent à ce sujet, en l'étendant davantage, Scrum est la méthodologie dont je vais parler plus spécifiquement ici et nous avons simplement augmenté cette image précédente avec quelques autres facettes. En règle générale, il y a un backlog de produit, puis un backlog de sprint. Nous avons donc un carnet de commandes global qui, au début de chaque réitération de sprint, nous réduisons pour dire: «Qu'est-ce que nous allons construire pour ce sprint?» Et cela se fait lors d'une réunion de planification de sprint. Ensuite, nous décomposons les tâches qui y sont associées et nous exécutons dans ces sprints d'une à quatre semaines avec ces révisions quotidiennes. Pendant que nous faisons cela, nous suivons nos progrès à travers des graphiques de gravure et des graphiques de gravure pour suivre essentiellement ce qui reste à construire par rapport à ce que nous construisons pour établir des choses comme quelle est notre vitesse de développement, allons-nous faire notre calendrier, tous ces types de choses. Tous ceux-ci sont élaborés en continu pendant le sprint plutôt que d'aller quelques mois sur la route et de découvrir que vous allez manquer et que vous devez prolonger le calendrier du projet. Et très important, dans le cadre de cela, toutes les équipes, il y a une revue de sprint à la fin et une rétrospective de sprint, donc avant de lancer la prochaine itération, vous passez en revue ce que vous avez fait et vous cherchez des moyens que vous pouvez améliorer la prochaine fois.

En termes de livrables, il s'agit essentiellement d'une diapositive qui résume les types de choses typiques qui se déroulent dans les sprints. Et c'est très axé 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 regardons ces cases ici, et je ne vais pas les parcourir à tous les niveaux de détail, ils sont très orientés développement. Et sous-jacent ici se trouve le fait que nous devons également avoir ces livrables de données qui vont de pair avec cela pour soutenir cet effort. Donc, chaque fois que nous voyons des choses comme les arriérés, les exigences et les histoires d'utilisateurs, au fur et à mesure que nous traversons, nous devons regarder quelles sont les pièces de développement que nous devons faire, quelles sont les pièces d'analyse que nous devons faire, que dire des la conception des données ou le modèle de données, qu'en est-il des éléments comme les glossaires commerciaux afin que nous puissions associer la signification commerciale à tous les artefacts que nous produisons? Parce que nous devons produire ces livrables utilisables à chaque sprint.

Certaines personnes diront que nous devons produire du code utilisable à la fin de chaque sprint. Ce n'est pas nécessairement le cas, c'est dans une perspective de développement la plus pure, mais assez souvent - en particulier au début - nous pouvons avoir quelque chose comme le sprint zéro où nous nous concentrons uniquement sur les choses debout, faire des choses comme obtenir nos stratégies de test endroit. Une conception de haut niveau pour commencer avant de commencer à remplir les détails et à nous assurer que nous avons un ensemble clair d'histoires ou d'exigences de départ avant de commencer à impliquer d'autres publics, puis à progresser en équipe au fur et à mesure. Il y a toujours un peu de temps de préparation, donc très souvent nous aurons un sprint zéro ou même un sprint zéro et un. Cela pourrait être un peu une phase de démarrage avant de lancer la solution.

Parlons très brièvement des modèles de données dans ce contexte. Lorsque les gens pensent aux modèles de données, ils pensent souvent à un modèle de données comme étant une image de la façon dont les différentes informations se lient - ce n'est que la pointe de l'iceberg. Pour incarner pleinement l'esprit de la façon dont vous voulez vraiment aborder la modélisation des données - que ce soit dans le développement agile et d'autres choses - vous devez réaliser que le modèle de données, s'il est fait correctement, devient votre spécification complète pour ce que ces données signifient dans l'organisation et comment il est déployé dans les bases de données principales. Quand je parle de bases de données, je veux dire non seulement les bases de données relationnelles que nous pouvons utiliser, mais dans les architectures d'aujourd'hui où nous avons des Big Data ou des plateformes NoSQL, comme je préfère les appeler. De même, ces magasins de données volumineuses, car nous pouvons combiner de nombreux magasins de données différents en termes de consommation d'informations et de leur intégration dans nos solutions, ainsi que de la façon dont nous persistons ou sauvegardons ces informations dans 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 être en mesure d'avoir une spécification complète, donc une spécification logique de ce que cela signifie pour une perspective organisationnelle de sprint, quelles sont les constructions physiques en termes de la façon dont nous définissons réellement les données, les relations entre elles dans vos bases de données, vos contraintes d'intégrité référentielle, les contraintes de vérification, toutes ces pièces de validation auxquelles vous pensez généralement. Les métadonnées descriptives sont extrêmement importantes. Comment savez-vous comment utiliser les données dans vos applications? À moins que vous ne puissiez le définir et savoir ce que cela signifie ou savoir d'où il vient pour vous assurer que vous consommez les données correctes dans ces applications - assurez-vous que nous avons des conventions de dénomination correctes, des définitions complètes, ce qui signifie un dictionnaire de données complet pour 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 les utilisons, car nous devons créer cette base de connaissances, car même lorsque cette application est terminée, ces informations seront utilisées pour d'autres initiatives, nous devons donc nous assurer que nous avons tout cela documenté pour les futures implémentations.

Encore une fois, nous passons à des choses comme les types de données, les clés, les index, le modèle de données lui-même incarne beaucoup de règles métier qui entrent en jeu. Les relations ne sont pas seulement des contraintes entre différentes tables; ils nous aident souvent à décrire quelles sont les véritables règles métier concernant le comportement de ces données et comment elles fonctionnent ensemble comme une unité cohérente. Et bien sûr, les restrictions de valeur sont très importantes. Maintenant, bien sûr, l'une des choses auxquelles nous sommes constamment confrontés, et qui devient de plus en plus courante, sont des choses comme la gouvernance des données. 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 capturé dans nos modèles. Et également pour des raisons de qualité des données, certaines informations sont plus importantes pour une organisation que d'autres.

J'ai participé à des projets où nous remplaçions plus d'une douzaine de systèmes hérités 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ù venaient les informations. Pour les informations les plus importantes, d'un point de vue commercial, si vous regardez cette diapositive de modèle de données particulière 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, je 'ai réussi à capter la valeur commerciale. Que ce soit élevé, moyen ou faible pour ces types de choses pour ces différentes constructions 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 principales, de références, 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 originaux et les faire avancer. Maintenant, c'était beaucoup dans une diapositive, je vais passer en revue les autres assez rapidement.

Je vais maintenant parler très rapidement de ce que fait un modélisateur de données alors que nous traversons ces différents sprints. Tout d'abord, un participant à part entière aux sessions de planification du sprint, où nous prenons les user stories, nous engageons sur ce que nous allons livrer dans ce sprint, et trouvons comment nous allons le structurer et le livrer. Ce que je fais également en tant que modélisateur de données, c'est que je sais que je vais travailler dans des domaines séparés avec différents développeurs ou avec différentes personnes. Donc, l'une des caractéristiques importantes que nous pouvons avoir est que lorsque nous faisons un modèle de données, nous pouvons diviser ce modèle de données en différentes vues, que vous les appeliez domaines ou sous-modèles, est notre terminologie. Alors que nous construisons le modèle, nous le montrons également dans ces différentes perspectives de sous-modèle afin que les différents publics ne voient que ce qui est pertinent pour eux afin qu'ils puissent se concentrer sur ce qu'ils développent et proposent. Donc, je pourrais avoir quelqu'un qui travaille sur une partie de planification d'une application, je pourrais avoir quelqu'un d'autre qui travaille sur une entrée de commande où nous faisons toutes ces choses en un seul sprint, mais je peux leur donner les points de vue à travers ces sous-modèles qui ne s'appliquent à la zone sur laquelle ils travaillent. Et ensuite, ceux-ci sont regroupés dans le modèle global et dans toute la structure des sous-modèles pour donner à différents publics ce qu'ils doivent voir.

Du point de vue de la modélisation des données que nous voulons avoir, nous avons toujours une base de référence à laquelle nous pouvons revenir parce que l'une des choses que nous devons être en mesure de faire, que ce soit à la fin d'un sprint ou à la fin de plusieurs sprints, nous voulons savoir où nous avons commencé et toujours avoir une base de référence pour savoir quel était le delta ou la différence de ce que nous avons produit dans un sprint donné. Nous devons également nous assurer que nous pouvons avoir un délai d'exécution rapide. Si vous y entrez en tant que modélisateur de données, mais dans le rôle traditionnel de gardien: «Non, non, vous ne pouvez pas le faire, nous devons d'abord faire tout cela», vous allez être exclu de l'équipe lorsque vous en aurez vraiment besoin d'être un participant actif dans toutes ces équipes de développement agiles. Cela signifie que certaines choses tombent du wagon en faisant un sprint donné et que vous les récupérez dans des sprints ultérieurs.

À titre d'exemple, vous pouvez vous concentrer sur les structures de données juste pour lancer le développement, par exemple, la pièce d'entrée de commande dont je parlais. Dans un sprint ultérieur, vous pouvez revenir et remplir 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 sprint; vous allez continuer à augmenter progressivement vos livrables, car il y aura des moments où vous pourrez remplir ces informations en travaillant avec des analystes commerciaux lorsque les développeurs seront occupés à créer les applications et la persistance autour de ces magasins de données. Vous voulez faciliter et ne pas être le goulot d'étranglement. Il existe différentes façons de travailler avec les développeurs. Pour certaines choses, nous avons des modèles de conception, nous sommes donc un participant à part entière, donc nous pouvons avoir un modèle de conception où nous dirons que nous le mettrons dans le modèle, nous le pousserons vers les bases de données du bac à sable des développeurs, puis ils pourront commencer à travailler avec lui et demander des modifications à cela.

Il y a peut-être d'autres domaines sur lesquels les développeurs ont travaillé, ils ont quelque chose sur lequel ils travaillent et ils prototypent certaines choses afin d'essayer certaines choses dans leur propre environnement de développement. Nous prenons cette base de données avec laquelle ils ont travaillé, l'introduisons dans notre outil de modélisation, la comparons aux modèles que nous avons, puis résolvons et repoussons les modifications afin qu'ils puissent refactoriser leurs codes afin qu'ils suivent les structures de données appropriées dont nous avons besoin. Parce qu'ils ont peut-être créé des choses que nous avions déjà ailleurs, nous nous assurons donc qu'ils travaillent avec les bonnes sources de données. Nous continuons simplement à répéter tout cela jusqu'à notre sprint afin d'obtenir les livrables de données complets, 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, nous avions une philosophie, modéliser toutes les modifications de la spécification de la base de données physique complète. En substance, le modèle de données devient les bases de données déployées avec lesquelles vous travaillez pour tout ce que nous créons et a des références complètes des autres magasins de données si nous consommons à partir d'autres bases de données externes. Dans le cadre de cela, nous produisons des scripts incrémentiels par rapport à une génération complète à chaque fois. Et nous utilisons nos modèles de conception pour nous donner un coup de pouce rapide pour faire avancer les choses dans les sprints avec les différentes équipes de développement avec lesquelles nous travaillons.

Dans les activités de sprint également, c'est encore cette référence pour comparer / fusionner, alors prenons l'idée de modéliser chaque changement. Chaque fois que nous faisons un changement, ce que nous voulons faire, c'est que nous voulons modéliser le changement et ce qui est très important, ce qui manquait à la modélisation des données jusqu'à récemment, en fait, jusqu'à ce que nous le réintroduisions, c'est la capacité d'associer la modélisation tâches et vos livrables avec les user stories et les tâches qui provoquent réellement ces changements. Nous voulons être en mesure de vérifier nos modifications de modèle, de la même manière que les développeurs archivent leurs codes, en référençant les histoires d'utilisateurs que nous avons afin que nous sachions pourquoi nous avons apporté des modifications en premier lieu, c'est quelque chose que nous faisons. Lorsque nous faisons cela, nous générons nos scripts DDL incrémentiels et les publions afin qu'ils puissent être récupérés avec les autres livrables de développement et archivés dans notre solution de génération. Encore une fois, nous pouvons avoir un modèle ou travailler avec plusieurs équipes. Et comme je l'ai déjà dit, certaines choses sont générées par le modélisateur de données, d'autres par les développeurs et nous nous réunissons au milieu pour trouver la meilleure conception globale et la pousser vers l'avant et nous assurer qu'elle est correctement conçue dans notre structures de données globales. Nous devons maintenir la discipline de veiller à ce que nous ayons toutes les constructions appropriées dans notre modèle de données au fur et à mesure, y compris des choses comme des valeurs nulles et non nulles, des contraintes référentielles, essentiellement des contraintes de vérification, toutes ces choses auxquelles nous pensons généralement .

Parlons maintenant de quelques captures d'écran de certains des outils qui nous aident à le faire. Ce que je pense est important, c'est d'avoir ce référentiel collaboratif, donc ce que nous pouvons faire en tant que modélisateurs de données - et c'est un extrait d'une partie d'un modèle de données en arrière-plan - c'est quand nous travaillons sur des choses que nous voulons nous assurer que nous pouvons travailler uniquement sur les objets dont nous avons besoin pour pouvoir changer, effectuer les modifications, générer nos scripts DDL pour les modifications que nous avons apportées lors de l'archivage. Donc, ce que nous pouvons faire, dans ER Studio, c'est un exemple, nous pouvons extraire des objets ou des groupes d'objets sur lesquels travailler, nous n'avons pas à extraire un modèle ou un sous-modèle entier, nous pouvons extraire uniquement les éléments qui nous intéressent. Ce que nous voulons après, c'est au moment du départ ou de l'enregistrement - nous le faisons dans les deux sens car les 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 génère les exigences pour cela et que ce sera la même user story ou la même tâche que les développeurs développeront et vérifieront 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 passer en revue ici en détail, mais ce que vous voyez est l'histoire ou la tâche utilisateur et 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 faisons le check-in et check-out et nous pouvons mettre plus de description sur cet enregistrement de changement. Il est associé à la tâche, nous pouvons avoir plusieurs modifications par tâche, comme vous pouvez vous y attendre. Et quand nous entrons dans ce dossier de changement, nous pouvons l'examiner et surtout voir, qu'avons-nous réellement changé? Pour celui-ci en particulier, l'histoire en surbrillance là-bas, j'ai eu un type de changement qui a été fait et quand j'ai regardé l'enregistrement de changement lui-même, il a identifié les pièces individuelles du modèle qui ont changé. J'ai modifié quelques attributs ici, les ai remis en séquence et cela a amené pour le trajet les vues à modifier qui dépendaient également 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 puissant comme celui-ci détecte également les modifications qui doivent être répercutées 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 différentes manières, c'est-à-dire faire quelque chose dans leur bac à sable et nous voulons comparer et voir où sont les différences, nous utilisons des capacités de comparaison / fusion là où à droite et à gauche côté. Nous pouvons dire: «Voici notre modèle sur le côté gauche, voici leur base de données sur le côté droit, montrez-moi les différences.» Nous pouvons ensuite choisir et choisir comment nous résolvons ces différences, que nous poussions les choses dans la base de données ou si il y a certaines choses qu'ils ont dans la base de données que nous réintroduisons dans le modèle. Nous pouvons aller bidirectionnel afin de pouvoir aller dans les deux directions en mettant à jour simultanément la source et la cible, puis produire les scripts DDL incrémentiels pour déployer ces modifications dans l'environnement de base de données lui-même, ce qui est extrêmement important. Ce que nous pouvons également faire, c'est que nous pouvons également utiliser cette fonction 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 sprint au début ou à la fin d'un autre sprint afin que nous puissions voir le changement incrémentiel complet de ce qui a été fait dans un sprint de développement donné ou sur une série de sprints.

Ceci est un exemple très rapide d'un script alter, tous ceux qui ont travaillé avec des bases de données auront vu ce type de chose, c'est ce que nous pouvons pousser hors du code en tant que script alter afin que nous nous assurions que nous retenez les choses ici. Ce que j'ai retiré d'ici, juste pour réduire l'encombrement, c'est ce que nous faisons aussi avec ces scripts de modification, c'est que nous supposons qu'il y a aussi des données dans ces tables, donc nous allons également générer le DML qui tirera les informations des tables temporaires et le repousser également dans les nouvelles structures de données afin que nous examinions non seulement les structures, mais aussi les données que nous avons peut-être déjà contenues dans ces structures.

Je vais parler très rapidement des systèmes de construction automatisés, car lorsque nous réalisons un projet agile assez souvent, nous travaillons avec des systèmes de construction automatisés où nous devons archiver les différents livrables ensemble pour nous assurer de ne pas interrompre nos générations. Cela signifie que nous synchronisons les livrables, ces scripts de changement dont j'ai parlé avec le script DDL doivent être archivés, le code d'application correspondant doit être archivé en même temps et de nombreux développeurs ne sont bien sûr pas en développement maintenant se fait avec SQL direct contre les bases de données et ce genre de chose. Très souvent, nous utilisons des cadres de persistance ou construisons des services de données. Nous devons nous assurer que les modifications apportées à ces frameworks ou services sont enregistrées en même temps. Ils entrent dans un système de construction automatisé dans certaines organisations et si la construction échoue, dans une méthodologie agile, ce sont tous des correctifs sur le pont qui construisent avant d'aller de l'avant afin que nous sachions que nous avons une solution de travail avant d'aller plus loin. Et l'un des projets auxquels j'ai participé, nous l'avons poussé à l'extrême - si la construction a éclaté, nous avions en fait attaché à un certain nombre d'ordinateurs de notre région où nous étions colocalisés avec les utilisateurs professionnels, nous avions des lumières rouges clignotantes juste comme le haut des voitures de police. Et si la construction se cassait, ces feux rouges clignotants ont commencé à s'éteindre et nous savions que tout était sur le pont: réparez la construction, puis continuez ce que nous faisions.

Je veux parler d'autres choses, et c'est une capacité unique à 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 regardez 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 pour savoir où se trouvent les limites de persistance. Là où nous, en tant que modélisateur de données, pouvons penser à quelque chose comme un en-tête de commande et l'alignement de la commande et d'autres tableaux détaillés qui seraient liés à cela dans la façon dont nous les construisons et nos développeurs de services de données doivent savoir comment les choses persistent pour 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 afin que les personnes qui construisent les serveurs de données puissent voir ce qui se trouve en dessous et nous pouvons 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 communiquer avec les entreprises. les analystes et les intervenants commerciaux lorsque nous parlons également de l'interaction de différents concepts commerciaux.

La bonne chose à ce sujet est également que nous les développons et les réduisons de manière constructive afin de pouvoir maintenir les relations entre les objets d'ordre supérieur, même s'ils proviennent de constructions contenues dans ces objets de données métier eux-mêmes. Maintenant, en tant que modélisateur, arrivez à la fin du sprint, à la fin du résumé du sprint, j'ai beaucoup de choses à faire, que j'appelle mon ménage pour le prochain sprint. À chaque sprint, je crée ce que j'appelle la version nommée - ce qui me donne ma référence pour ce que j'ai maintenant à la fin de la version. Cela signifie donc que ma ligne de base va de l'avant, toutes ces lignes de base ou versions nommées que je crée et enregistre dans mon référentiel que je peux utiliser pour faire une comparaison / fusion afin que je puisse toujours comparer à une fin de sprint donnée à partir de n'importe quel autre sprint, ce qui est très important de savoir quels ont été vos changements dans votre modèle de données tout au long de son parcours.

Je crée également un script delta DDL en utilisant à nouveau la comparaison / fusion du début à la fin du sprint. J'ai peut-être archivé tout un tas de scripts incrémentiels, mais si j'en ai besoin, j'ai maintenant un script que je peux déployer pour tenir debout d'autres bacs à sable, donc je peux simplement dire que c'est ce que nous avions au début du sprint, appuyez sur à travers, construire une base de données comme un bac à sable pour commencer avec le prochain sprint et nous pouvons également utiliser ces choses pour faire des choses comme des instances QA standup et finalement, bien sûr, nous voulons pousser nos modifications à la production afin que nous ayons plusieurs choses en cours à la fois. Encore une fois, nous participons pleinement à la planification du sprint et aux rétrospectives, les rétrospectives sont vraiment les leçons apprises et c'est extrêmement important, car vous pouvez vous lancer très rapidement pendant l'agilité, vous devez vous arrêter et célébrer les succès, comme maintenant. Découvrez ce qui ne va pas, améliorez-le la prochaine fois, mais célébrez également les choses qui se sont bien passées et construisez-vous en continuant à avancer dans les prochains sprints.

Je vais maintenant parler très rapidement de la valeur commerciale. Il y a eu un projet auquel j'ai participé il y a de nombreuses années qui a commencé comme un projet agile, et c'était un projet extrême, donc c'était une pure équipe auto-organisée où seuls les développeurs faisaient tout. Pour faire court, ce projet était au point mort et ils constataient qu'ils consacraient de plus en plus de temps à la correction et à la correction des défauts identifiés plutôt qu'à la promotion de plus de fonctionnalités et, en fait, lorsqu'ils l'ont examiné en fonction sur les grilles de combustion, ils allaient devoir prolonger le projet de six mois à un coût énorme. Et quand nous l'avons regardé, la façon de résoudre le problème était d'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 particulier, cela montre les défauts cumulatifs par rapport aux objets cumulatifs, et je parle des objets de données ou des constructions qui ont été créés tels que les tables avec les contraintes et ces types de choses, si vous avez regardé avant l'introduction du modélisateur de données, le nombre de défauts dépassait réellement et commençait à créer un petit écart par rapport au nombre réel d'objets produits jusqu'à ce moment-là. Après la semaine 21, c'est à ce moment-là que le modélisateur de données est entré, a refactorisé le modèle de données en fonction de ce qu'il y avait à réparer un certain nombre de choses, puis a commencé à modéliser dans le cadre de l'équipe de projet à l'avenir, les changements au fur et à mesure que ce projet était avancé . Et vous avez vu un retournement très rapide qu'en environ un sprint et demi, nous avons vu une énorme augmentation du nombre d'objets et de constructions de données qui étaient 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 bâton de développeur les construire dans un environnement, et ils étaient corrects 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 par rapport à ceux presque à plat. En prenant les mesures appropriées et en veillant à ce que la modélisation des données soit pleinement engagée, le projet a été livré à temps avec un niveau de qualité beaucoup plus élevé et, en fait, il ne l'aurait pas été du tout si ces étapes n'avaient pas eu lieu. Il y a beaucoup d'échecs agiles là-bas, il y a aussi beaucoup de succès agiles si vous voulez impliquer les bonnes personnes dans les bons rôles. Je suis un grand 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 dans vos équipes de projet au fur et à mesure que vous avancez dans un type d'agilité.

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 tient tout ensemble parce qu'en tant que modélisateurs de données et architectes, nous comprenons non seulement les constructions de données du projet de développement donné, mais aussi où les données existent dans l'organisation et où nous pouvons les obtenir et comment elles 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 aussi du point de vue de la gouvernance pour cartographier le document et comprendre à quoi ressemble votre paysage de données complet.

C'est comme la fabrication; Je venais d'un milieu manufacturier. Vous ne pouvez pas inspecter la qualité dans quelque chose à la fin - vous devez intégrer la qualité dans votre conception dès le départ et sur votre chemin, et la modélisation des données est un moyen d'intégrer cette qualité dans la conception de manière efficace et rentable tout au long du processus. . Et encore une fois, 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 vital de l'entreprise et elles transcendent toutes ces frontières d'applications. Chaque fois que vous introduisez une application, il vous sera probablement demandé de conserver les données des autres applications précédentes, nous devons donc nous rappeler qu'il s'agit d'un actif d'entreprise essentiel que nous continuons à maintenir au fil du temps.

Et c'est tout! De là, nous prendrons plus de questions.

Eric Kavanagh: D' accord, très bien, permettez-moi de le jeter d'abord à Robin. Et puis, Dez, je suis sûr que vous avez quelques questions. Enlevez-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 agile et il me semble que ce que vous faites ici est tout à fait logique. Je me souviens d'avoir regardé quelque chose dans les années 1980 qui indiquait vraiment que le problème que vous rencontrez en termes de projet échappant à tout contrôle, c'est normalement si vous laissez une erreur persister au-delà d'une étape particulière. Cela devient de plus en plus difficile à corriger si vous ne réussissez pas à ce stade, donc l'une des choses que vous faites ici - et je pense que c'est la diapositive - mais l'une des choses que vous faites ici dans le sprint zéro, à mon avis, est absolument important parce que vous essayez vraiment de faire épingler les livrables là-bas. Et si les livrables ne sont pas épinglés, les livrables changent de forme.

C'est, en quelque sorte, mon avis. C'est aussi mon opinion - je n'ai vraiment aucun argument avec l'idée que vous devez obtenir la modélisation des données à un certain niveau de détail avant de passer. Ce que j'aimerais que vous essayiez de faire parce que je ne l'ai pas complètement compris, c'est simplement de décrire l'un de ces projets en termes de taille, en termes de flux, en termes de qui, vous savez, où les problèmes ont surgi, ont-ils été résolus? Parce que je pense que cette diapositive en est à peu près le cœur et 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, est sorti des rails qui a été ramené en impliquant réellement les bonnes personnes et en faisant la modélisation des données et tout était vraiment un moyen de s'assurer que la conception était mieux comprise et nous avions évidemment une meilleure conception de la mise en œuvre sur le chemin en le modélisant. Parce que lorsque vous le modélisez, vous savez, vous pouvez générer votre DDL et tout à l'arrière et à l'extérieur de l'outil plutôt que d'avoir à le construire, comme les gens le font généralement en allant directement dans un environnement de base de données. Et les choses typiques qui se produiront avec les développeurs, c'est qu'ils iront là-bas et ils diront, d'accord, j'ai besoin de ces tables. Disons que nous faisons des entrées de commande. Ils pourraient donc créer l'en-tête de la commande et les tables de détail de la commande, et ce genre de choses. Mais ils oublient ou négligent assez souvent de s'assurer que les contraintes sont là pour représenter les relations avec les clés étrangères. 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 colonne dans ces tables sont comme ID, Nom ou autre, donc ils 'ai vraiment perdu le contexte sans le tableau de ce que c'est exactement.

Ainsi, généralement lorsque nous modélisons des données, nous nous assurons que nous appliquons également des 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, je parle, d'une manière générale, d'initiatives assez importantes. L'un d'eux était un projet de transformation commerciale de 150 millions de dollars où nous avons remplacé plus d'une douzaine de systèmes hérités. Nous avions cinq équipes agiles différentes fonctionnant simultanément. J'avais une équipe complète d'architecture de données, donc j'avais des modélisateurs de données de mon équipe intégrés dans chacune des autres équipes du domaine d'application, et nous travaillions avec une combinaison d'experts métier internes qui connaissaient le sujet, qui faisaient le des histoires d'utilisateurs pour les exigences elles-mêmes. Nous avions des analystes commerciaux dans chacune de ces équipes qui modélisaient réellement le processus métier, avec les diagrammes d'activité ou les diagrammes de processus métier, aidant à étoffer davantage les histoires d'utilisateurs avec les utilisateurs avant qu'elles ne soient également consommées par le reste de l'équipe.

Et puis, bien sûr, les développeurs qui construisaient le code d'application par-dessus cela. Et nous travaillions également avec, je pense, que quatre fournisseurs d'intégration de systèmes différents construisaient différentes parties de l'application ainsi qu'une équipe développait les services de données, l'autre construisait la logique d'application dans un domaine, un autre qui avait une expertise dans un autre domaine d'activité, la construction de la logique d'application dans ce domaine était en cours. Nous avons donc eu toute une collaboration de personnes qui travaillaient sur ce projet. Sur celui-ci en particulier, nous avions 150 personnes à terre dans l'équipe et 150 autres ressources à l'étranger dans l'équipe qui collaboraient à des sprints de deux semaines pour chasser cette chose. Et pour ce faire, vous devez vous assurer que vous tirez sur tous les cylindres, et tout le monde est bien synchronisé en ce qui concerne leurs livrables, et vous avez eu ces réinitialisations fréquentes pour vous assurer que nous achevions nos livraisons de tous les artefacts nécessaires à la fin de chaque sprint.

Dr Robin Bloor: Eh bien, c'est impressionnant. Et juste pour un peu plus de détails à ce sujet - vous êtes-vous retrouvé avec une carte MDM complète, ce que j'appellerais, une carte MDM de toute la zone de données à la fin de ce projet?

Ron Huizenga: Nous avions un modèle de données complet qui a été décomposé avec la décomposition entre tous les différents secteurs d'activité. Le dictionnaire de données lui-même en termes de définitions complètes est un peu court. Nous avions défini la plupart des tables; nous avons fait définir la plupart des colonnes exactement ce qu'elles signifiaient. Il y en avait qui n'étaient pas là et, chose intéressante, beaucoup de ces informations provenaient des anciens systèmes où, après la fin de la portée du projet elle-même, cela était toujours documenté comme un ensemble de des artefacts, pour ainsi dire, en dehors du projet lui-même, parce que c'était quelque chose qui devait être soutenu par l'organisation à l'avenir. Donc, en même temps, l'organisation a adopté un point de vue beaucoup plus important sur l'importance de la gouvernance des données, car nous avons 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 que nous devions inverser et essayer de comprendre ce qui était là et à quoi servaient les informations.

Dr Robin Bloor: Cela ne me surprend pas, cet aspect particulier. La gouvernance des données est, appelons-le, une préoccupation très moderne et je pense qu'en réalité, il y a beaucoup de travail qui, disons, aurait dû être fait historiquement sur la gouvernance des données. Cela n'a jamais été parce que vous pourriez, en quelque sorte, vous en tirer sans le faire. Mais au fur et à mesure que la ressource de données augmentait et grandissait, vous ne pouviez finalement pas.

Quoi qu'il en soit, je vais céder la parole à Dez parce que je pense que j'ai eu mon temps alloué. Dez?

Dez Blanchfield: Oui, merci. À travers tout cela, je regarde et je me dis que nous parlons de voir l'agile utilisé dans la colère de plusieurs façons. Bien que cela ait des connotations négatives; Je voulais dire cela d'une manière positive. Pourriez-vous peut-être simplement nous donner un scénario, 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, selon 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 entre coller les deux mondes, non? Pouvez-vous nous donner un aperçu de certaines réussites que vous avez vues où vous êtes entré dans une organisation, il est devenu clair qu'ils ont un léger choc des deux mondes et que vous avez réussi à mettre cela en place et rassembler de grands projets où ils auraient pu autrement être mis sur les rails? Je sais que c'est une question très large, mais je me demande simplement s'il y a une étude de cas particulière que vous pouvez, en quelque sorte, indiquer où vous avez dit, vous savez, nous avons mis tout cela en place et cela a réuni toute l'équipe de développement avec 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 seul projet qui s'est avéré être un projet de pipeline était celui auquel j'ai fait allusion où j'ai montré ce graphique avec les défauts avant et après l'implication du modélisateur de données. Très souvent, et il existe des notions préconçues, en particulier si les choses se déroulent là où cela se fait dans une perspective purement de développement, ce ne sont que des développeurs qui sont impliqués dans ces projets agiles pour fournir 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 en particulier, ou les livrables de données qu'ils produisaient, n'ont pas atteint le niveau requis en termes de qualité et ont vraiment abordé les choses dans leur ensemble. Et il y a assez souvent cette idée fausse selon laquelle les modélisateurs de données ralentiront les projets, et ils le feront si le modélisateur de données n'a pas la bonne attitude. Comme je l'ai dit, vous devez perdre le - parfois, il y a des modélisateurs de données qui ont cette attitude traditionnelle de gardien: «Nous sommes ici pour contrôler à quoi ressemblent les 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 pour vraiment aider les équipes à progresser. Et la meilleure façon d'illustrer cela est de montrer très rapidement aux équipes à quel point elles peuvent être productives en modélisant d'abord les changements. Et encore une fois, c'est pourquoi j'ai parlé de la collaboration.

Il y a certaines choses que nous pouvons modéliser en premier et générer le DDL à transmettre aux développeurs. Nous voulons également nous assurer qu'ils ne se sentent pas limités. Donc, s'il y a des choses sur lesquelles ils travaillent, laissez-les continuer à travailler dans leurs bacs à sable de développement, car c'est là que les développeurs travaillent sur leurs propres bureaux ou autres bases de données pour apporter des modifications là où ils testent les choses. Et collaborez avec eux et dites: «D'accord, travaillez avec cela.» Nous l'intégrerons dans l'outil, nous le résoudrons, puis nous le pousserons vers l'avant et vous donnerons les scripts que vous pouvez déployer pour mettre à jour votre bases de données pour les mettre à niveau à ce que la vue réelle de la production réelle sanctionnée de ce sera alors que nous continuons à aller de l'avant. Et vous pouvez changer cela très rapidement. J'ai trouvé que mes journées étaient remplies où je faisais des allers-retours en itérant avec différentes équipes de développement, en examinant les changements, en comparant, en générant des scripts, en les mettant en marche, et j'ai pu suivre assez facilement quatre équipes de développement une fois que nous atteint un élan.

Dez Blanchfield: Une des choses qui me vient à l'esprit est que, vous savez, beaucoup de conversations que j'ai quotidiennement portent sur ce train de marchandises qui nous arrive, en quelque sorte, de la machine à -machine et IoT. Et si nous pensons que nous avons maintenant beaucoup de données sur nos environnements actuels en entreprise, vous savez, si nous prenons les licornes de côté pendant un moment où nous savons que les Google et les Facebook 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 beaucoup de données. Mais il y a ce train de marchandises qui arrive dans des organisations, à mon avis, et le Dr Robin Bloor y a fait allusion plus tôt, de l'IoT. Vous savez, nous avons beaucoup de trafic Web, nous avons du trafic social, nous avons maintenant de la mobilité et des appareils mobiles, le cloud a, en quelque sorte, explosé, mais maintenant nous avons 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 taille moyenne à grande qui est assise là et qui voit ce monde de douleur venir à elle et qui n'a pas de plan immédiat en tête, quels sont les points à retenir, en seulement quelques phrases, que vous mettriez pour eux quand et où ils doivent commencer à réfléchir de manière conversationnelle à la mise en place de certaines de ces méthodologies. Combien de temps ont-ils besoin pour commencer à planifier de presque s'asseoir et faire attention et dire que c'est le bon moment pour mettre en place certains outils et former l'équipe et obtenir une conversation de vocabulaire autour de ce défi? Quelle est la fin de l'histoire ou trop tôt? À quoi cela ressemble-t-il pour certaines des organisations que vous voyez?

Ron Huizenga: Je dirais pour la plupart des organisations que si elles ne l'ont pas déjà fait et 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 constater que, même aujourd'hui, lorsque nous examinons les données dans les organisations, nous avons tellement de données dans nos organisations et, d'une manière générale, d'après certaines enquêtes que nous avons vues, 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 si ce n'est pas seulement l'IoT, mais juste le Big Data en général - où nous commençons maintenant à consommer encore plus d'informations provenant de l'extérieur de nos organisations, ce défi devient de plus en plus grand tout le temps. Et la seule façon dont nous avons une chance de pouvoir y faire face est de nous aider à comprendre en quoi consistent ces données.

Ainsi, le cas d'utilisation est un peu différent. Ce que nous nous trouvons à faire, c'est lorsque nous regardons ces données, nous les capturons, nous devons les rétroconcevoir, voir ce qu'elles contiennent, que ce soit dans nos lacs de données ou même dans nos bases de données internes, synthétiser ce que les données, leur appliquer des significations et des définitions afin que nous puissions comprendre ce que sont les données. Parce que tant que nous ne comprenons pas ce que c'est, nous ne pouvons pas nous assurer que nous l'utilisons correctement ou adéquatement. Nous devons donc vraiment comprendre quelles sont ces données. Et l'autre partie est de ne pas le faire parce que vous pouvez, en termes de consommation de toutes ces données externes, vous assurer d'avoir un cas d'utilisation qui 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 choses importantes et au fur et à mesure que vous progressez, vous allez consommer et essayer de comprendre les autres informations de l'extérieur.

Un exemple parfait de cela est, je sais que nous parlons de l'IoT et des 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 a un système de contrôle de la production, qu'il s'agisse d'une société de pipeline, de fabrication, de toute entreprise basée sur des processus qui a des choses où il fait beaucoup d'automatisation avec des contrôles et qui utilise des flux de données et des choses comme ça, a ces incendies de données qu'ils essaient de boire pour comprendre, quels sont les événements qui se sont produits dans mon équipement de production pour signaler - que s'est-il passé et quand? Et parmi cet énorme flux de données, il n'y a que des informations ou des balises spécifiques qui les intéressent et dont ils ont besoin pour filtrer, synthétiser, modéliser et comprendre. Et ils peuvent ignorer le reste jusqu'à ce que le moment soit venu de vraiment le comprendre, puis ils peuvent étendre leur portée pour en tirer de plus en plus, si cela a du sens.

Dez Blanchfield: Oui, effectivement. Il y a une question que je vais vous poser et qui vient d'un monsieur appelé Eric, et nous en avons discuté en privé. Je viens de lui demander la permission qui lui a été donnée de vous la demander. Parce que cela mène bien à cela, juste pour conclure, parce que nous allons un peu au fil du temps maintenant, et je vais remettre à Eric. Mais la question d'un autre Eric était: est-il raisonnable de supposer que les propriétaires d'une startup connaissent et comprennent les défis uniques liés à la modélisation de la terminologie et ainsi, ou devraient-ils être remis à quelqu'un d'autre pour interprétation? Donc, en d'autres termes, une startup devrait-elle être capable et prête, disposée et capable de se concentrer sur cela et de le livrer? Ou est-ce quelque chose avec lequel ils devraient probablement magasiner et faire venir des experts?

Ron Huizenga: Je suppose que la réponse courte est que cela dépend vraiment. Si c'est une startup qui n'a pas en interne quelqu'un qui est un architecte de données ou un modeleur qui comprend vraiment la base de données, alors le moyen le plus rapide pour commencer est d'amener quelqu'un avec une formation en consultation qui est très bien versé dans cet espace et peut obtenir eux vont. Parce que ce que vous trouverez - et en fait, je l'ai fait sur de nombreux engagements que j'ai faits avant de passer au côté obscur de la gestion des produits - c'est que j'entrerais 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 peuple sur la façon de faire ce genre de choses afin qu'ils le maintiennent et poursuivent la mission. Et puis je passerais à mon prochain engagement, si cela a du sens. Il y a beaucoup de gens qui font cela, qui ont une très bonne expérience des données qui peuvent les faire avancer.

Dez Blanchfield: C'est un excellent point à retenir et je suis totalement d'accord avec lui et je suis sûr que le Dr Robin Bloor le serait aussi. En particulier dans une startup, vous vous concentrez sur le fait d'être une PME sur la valeur particulière de la proposition que vous cherchez à construire dans le cadre de votre entreprise de démarrage elle-même et vous ne devriez probablement pas avoir besoin d'être un expert sur tout, donc d'excellents conseils. Mais merci beaucoup, une présentation fantastique. Vraiment d'excellentes réponses et questions. Eric, je vais vous rendre la main parce que je sais que nous avons probablement dépassé dix minutes dans le temps et je sais que vous aimez vous en tenir à nos fenêtres horaires.

Eric Kavanagh: Ça va. Nous avons au moins quelques bonnes questions. Permettez-moi de vous en jeter un. Je pense que vous avez répondu à certaines des autres. Mais une observation et une question très intéressantes d'un participant qui écrit, parfois des projets agiles ont le modélisateur de données n'ayant pas la totalité de l'image à long terme et donc ils finissent par concevoir quelque chose dans le sprint un, puis doivent repenser dans le sprint trois ou quatre. Cela ne semble-t-il pas contre-productif? Comment pouvez-vous éviter ce genre de chose?

Ron Huizenga: C'est juste la nature de l'agilité que vous n'obtiendrez pas tout parfaitement dans un sprint donné. Et cela fait en fait partie de l'esprit de l'agilité, c'est: travailler avec - vous allez faire du prototypage où vous travaillez sur du code dans un sprint donné, et vous allez y apporter des améliorations. Et une partie de ce processus consiste à fournir des choses que l'utilisateur final voit et dit: «Oui, c'est proche, mais j'ai vraiment besoin de le faire faire un peu plus aussi.» Donc, cela n'impacte pas seulement la conception fonctionnelle du code lui-même, mais assez souvent, nous devons modifier ou ajouter plus de structure de données sous ces certaines choses pour fournir ce que l'utilisateur veut. Et tout cela est un jeu équitable et c'est pourquoi vous voulez vraiment utiliser les outils puissants car vous pouvez très rapidement modéliser et apporter cette modification dans un outil de modélisation, puis générer le DDL pour la base de données que les développeurs peuvent ensuite utiliser pour livrer cela. changer encore plus rapidement. Vous leur évitez d'avoir à coder manuellement, pour ainsi dire, les structures de données et vous les laissez se concentrer sur la logique de programmation ou d'application dans laquelle ils sont le plus compétents.

Eric Kavanagh: C'est tout à fait logique. Quelques autres personnes nous ont simplement posé des questions précises sur la façon dont tout cela est lié à l'outil. I know you spent some time going through examples and you've been showing some screenshots about how you actually roll some of this stuff out. In terms of this whole sprint process, how often do you see that in play in organizations versus how often do you see more traditional processes where things just, kind of, plod along and take more time? How prevalent is the sprint-style approach from your perspective?

Ron Huizenga: I think we're seeing it more and more. I know that, I would say, probably in the last 15 years in particular, I've seen much more of an adoption of people recognizing that they really need to embrace quicker delivery. So I've seen more and more organizations jump on the agile bandwagon. Not necessarily entirely; they may start out with a couple of pilot projects to prove out that it works, but there are some that are still very traditional and they do stick with the waterfall method. Now, the good news is, of course, that the tools work very fine in those organizations as well for those type of methodologies, but we have the adaptability in the tool so that those who do jump on board have the tools in the toolbox at their fingertips. Things like the compare and merge, things like the reverse-engineering capabilities, so they can see what the existing data sources are, so they can actually compare and generate out the incremental DDL scripts very quickly. And as they start to embrace that and see that they can have the productivity, their inclination to embrace agile even more increases.

Eric Kavanagh: Well, this is great stuff, folks. I just posted a link to the slides there in the chat window, so check that out; it's a little bit of a Bitly in there for you. We do have all these webcasts for later viewing. Feel free to share them with your friends and colleagues. And Ron, thank you very much for your time today, you're always pleasant to have on the show – a real expert in the field and it's obvious that you know your stuff. So, thanks to you and thanks to IDERA and, of course, to Dez and our very own Robin Bloor.

And with that we're going to bid you farewell, folks. Merci encore pour votre temps et votre attention. We appreciate you sticking around for 75 minutes, that's a pretty good sign. Good show guys, we'll talk to you next time. Bye Bye.