Gegevensmodellering in een agile omgeving

Door Techopedia Staff, 16 november 2016

Takeaway: gastheer Eric Kavanagh bespreekt het belang van datamodellering voor agile ontwikkeling met Robin Bloor, Dez Blanchfield en Ron Huizenga van IDERA.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Eric Kavanagh: Oké, dames en heren. Welkom weer terug. Het is woensdag om 4:00 EST. Dat betekent dat het tijd is voor Hot Technologies. Ja inderdaad. Mijn naam is Eric Kavanagh, ik zal je gastheer zijn.

Voor het onderwerp van vandaag is het een oldie maar een goodie. Het wordt elke dag beter omdat het onze datamanagementwereld vormgeeft, "Datamodellering in een Agile omgeving." Er is echt een dia over jou, laat me weten op Twitter @eric_kavanagh. We moeten het echt op die dia zetten. Daar zal ik op moeten ingaan.

Het is dus een warm jaar. Datamodellering bestaat altijd. Het is echt de kern van de IT-business geweest, datamodellen ontwerpen, proberen businessmodellen te begrijpen en af ​​te stemmen op uw datamodellen. Dat is echt wat je probeert te doen, toch?

Datamodel vertegenwoordigt het bedrijf op een fundamentele manier, dus hoe veranderen al deze nieuwe gegevensbronnen het spel? Daar gaan we achter komen. We gaan ontdekken hoe je op een agile manier op de hoogte kunt blijven. En dat is natuurlijk het woord van het jaar.

Robin Bloor is bij ons, onze hoofdanalist, Dez Blanchfield belt vanuit Sydney, Australië en Ron Huizenga, Senior Product Manager van IDERA - oude vriend van mij, uitstekende spreker in deze ruimte, kent zijn spullen, dus wees niet verlegen, vraag hij de moeilijke vragen, mensen, de moeilijke. Daarmee ga ik Robin tot presentator maken en meenemen.

Dr. Robin Bloor: Oké. Bedankt daarvoor, Eric. Ik moet zeggen dat ik denk dat ik eigenlijk al in de IT-wereld zat voordat het bestond, in de zin dat ik me herinner in de verzekeringsmaatschappij waar ik voor werkte, dat er een man binnenkwam die ons allemaal een soort gaf van workshop over het modelleren van gegevens. Dus we kijken naar ongeveer 30 jaar, is het 30 jaar? Misschien zelfs langer dan dat, misschien 35 jaar geleden. Een lange, lange tijd modellering is eigenlijk een onderdeel van de industrie geweest en heeft natuurlijk niets te maken met dames op catwalks.

Het ding dat ik wilde zeggen, want wat we normaal gesproken doen, zijn ik en Dez praten over verschillende dingen en ik dacht gewoon dat ik het algemene overzicht aan modellering zou geven, maar er is een realiteit die nu duidelijk wordt.

We hebben, weet je, de realiteit van big data, we hebben meer data, meer databronnen, we hebben datastromen die de afgelopen drie of vier jaar in de vergelijking zijn gekomen en er een groter deel van beginnen te krijgen, en er is een grotere behoefte om de gegevens te begrijpen en een toename in de mate van verandering, waarbij meer gegevens worden toegevoegd en ook meer gegevensstructuren worden gebruikt.

Het is een moeilijke wereld. Hier is een foto van, dat is eigenlijk iets dat we ongeveer drie jaar geleden hebben getekend, maar in feite, zodra je streaming in de mix opneemt en je dit idee krijgt van dataraffinaderij, datahub, datalink of wat dan ook, zie je dat er data is die echt in rust, in de zin dat het niet veel beweegt. En dan zijn er de gegevens, de streams en je hebt alle transactionele applicaties, plus tegenwoordig heb je evenementen, gebeurtenisgegevensstromen die in applicaties gebeuren en misschien moeten, en tegenwoordig met de lambda-architecturen waar iedereen het over heeft, echt met een impact op alleen het hele gegevensveld.

En tegenwoordig denken we in termen van een gegevenslaag. De gegevenslaag bestaat op een soort virtuele manier, in de zin dat een goed deel ervan zich in de cloud kan bevinden en kan worden verspreid over datacenters, het kan op werkstations bestaan. De gegevenslaag is tot op zekere hoogte overal en in die zin zijn er overal processen die op de een of andere manier proberen de gegevens te verwerken en te verplaatsen. Maar ook weten wat het is als je het verplaatst, is een groot probleem.

Als we naar gegevensmodellering in de meest algemene zin kijken, staan ​​onderaan deze stapel bestanden en databases. U hebt gegevenselementen, die sleutels, elementdefinities, aliassen, synoniemen, specifieke fysieke formaten hebben en dan hebben we deze metagegevenslaag.

Het interessante van metadata is dat metadata volledig is hoe data haar betekenis krijgt. Als je niet echt metadata hebt, kun je in het beste geval de betekenis van de gegevens raden, maar je zult heel veel problemen hebben. Metadata moet er zijn, maar betekenis heeft structuur. Ik wil niet ingaan op de filosofie van betekenis, maar zelfs in de manier waarop we met gegevens omgaan, zijn er veel verfijningen in het menselijk denken en de menselijke taal, die zich niet gemakkelijk in gegevens uitdrukken. Maar zelfs in termen van de gegevens die we daadwerkelijk in de wereld verwerken, hebben metagegevens betekenis en de structuur van de metagegevens - een stuk gegevens in relatie tot een ander en wat dat betekent wanneer ze worden samengevoegd en wat dat betekent wanneer ze ' opnieuw samengevoegd met andere gegevens, vereist dat we deze modelleren. Het is niet goed genoeg om alleen metadatatags aan dingen vast te leggen, je moet eigenlijk betekenis per structuur en de relatie tussen de structuren vastleggen.

Dan hebben we op de bovenste laag de bedrijfsdefinities, die normaal een laag is die probeert betekenis over te dragen tussen metagegevens, wat een vorm van gegevensdefinitie is die past bij de manier waarop gegevens op de computer zijn georganiseerd en menselijke betekenis. U hebt dus zakelijke termen, definities, relaties, concepten op entiteitsniveau die in die laag bestaan. En als we een incoherentie tussen deze lagen hebben, moeten we gegevensmodellering hebben. Het is niet echt optioneel. Hoe meer je het daadwerkelijk kunt doen, hoe beter. Maar omdat het met betekenis te maken heeft, is het echt moeilijk om te wisselen. Het is eenvoudig genoeg om de metadata binnen een record te vangen en uit een reeks betekenissen te halen, maar het vertelt u niet de structuur van de records of wat de records betekenen of de context van het record.

Dus hier gaat mijns inziens over datamodellering. Aandachtspunten: hoe complexer het data-universum, hoe meer u nodig hebt om het te modelleren. Met andere woorden, het is een beetje alsof we niet alleen meer dingen aan de wereld toevoegen, wat overeenkomt met gegevensrecords, maar we voegen eigenlijk meer betekenis aan de wereld toe door gegevens over steeds meer dingen vast te leggen. Het wordt een steeds complexer gevoel dat we moeten begrijpen.

In theorie is er een data-universum en daar moeten we zicht op hebben. In de praktijk maakt de eigenlijke metadata deel uit van het data-universum. Het is dus geen eenvoudige situatie. Beginnen met modelleren is top-down en bottom-up. Je moet in beide richtingen bouwen en de reden daarvoor is dat data betekenis heeft voor de computer en het proces, dat het moet verwerken, maar het heeft een eigen betekenis. Je hebt dus een bottom-up betekenis nodig die voldoet aan de software die toegang moet hebben tot de gegevens en je hebt de top-down betekenis nodig zodat mensen deze kunnen begrijpen. Het bouwen van metadatamodellen is geen project en kan dat ook nooit zijn; het is een voortdurende activiteit - zou een voortdurende activiteit moeten zijn in elke omgeving waarin ze bestaan. Gelukkig zijn er veel omgevingen, waar dat eigenlijk niet het geval is en dingen uit de hand lopen.

In de toekomst neemt het modelleren toe naarmate de technologie vooruit gaat. Dat is mijn mening. Maar als je naar het IoT kijkt, begrijpen we mobiel meer dan vroeger, hoewel het nieuwe dimensies heeft geïntroduceerd: de dimensie van locatie met mobiel. Als je eenmaal bij het IoT bent, kijken we naar buitengewone dataproblemen die we eigenlijk nooit eerder moesten doen en we moeten op de een of andere manier precies begrijpen wat we hebben, precies hoe we het kunnen aggregeren, wat we kunnen doen in termen van betekenis krijgen van aggregatie, en natuurlijk, wat we ermee kunnen doen, wanneer we het hebben verwerkt.

Ik denk dat ik dat genoeg heb gezegd. Ik ga door naar Dez Blanchfield, die helemaal iets anders zal zeggen.

Dez Blanchfield: Bedankt. Altijd een moeilijke daad om te volgen, maar dit is een onderwerp waarover we het eens waren en waarover we het kort hadden gehad in de pre-show scherts, en als je vroeg zou inbellen, zou je waarschijnlijk een heleboel geweldige edelstenen hebben gevangen. Een van de afhaalrestaurants, en ik wil de donder van deze specifieke niet stelen, maar een van de afhaalrestaurants van onze scherts die ik wil delen, voor het geval je het niet hebt begrepen, ging gewoon over het onderwerp de reis van gegevens, en het viel me op om het op te schrijven en na te denken over de reis die de gegevens maken in een andere context rond het generatieleven - jaar, maanden, week, dag, uur, minuut, seconde - en de context rond de gegevens zijn geplaatst in die context. Of ik nu een ontwikkelaar ben die code uitvoert, of dat ik een gegevensspecialist ben en ik denk aan de structuur en het formaat en de metadata rond elk van de elementen, of de manier waarop de systemen en het bedrijf ermee omgaan.

Het is een interessante kleine afhaalmaaltijd om op te merken, maar laat me er in ieder geval in duiken. Gegevensontwerp, in het bijzonder, is een zin die ik gebruik om te praten over alle dingen gegevens en specifiek de ontwikkeling van applicaties of database-infrastructuur. Ik denk dat gegevensontwerp een term is die het allemaal heel goed in mijn hoofd vastlegt. Tegenwoordig praten we over modern ontwerp voor wendbare gegevens en mijn mening is dat het nog niet zo lang geleden was dat ontwikkelaars en data-experts alleen werkten; ze zaten in hun eigen silo's en stukken design gingen van de ene silo naar de andere. Maar ik ben tegenwoordig heel erg van mening dat niet alleen het geval is veranderd, maar ook moet veranderen; het is een soort noodzaak en dat is die applicatie - ontwikkelaars en alles wat rond ontwikkeling te maken heeft dat met gegevens omgaat, de ontwerpers die de relevante ontwerpelementen van schema's en velden en records en locatie- en databasesystemen en -infrastructuren, modellering en het hele beheer doen daar omheen uitdaging. Dat is nu een teamsport en vandaar mijn foto van een groep mensen die uit een vliegtuig springen en als een team optreden om dat visueel interessante beeld te spelen van mensen die door de lucht vallen.

Ten derde, wat is er gebeurd om dit te bewerkstelligen? Nou, er is een artikel in 1986 geschreven door een paar heren wiens namen ik wanhopig probeerde recht te doen, Hirotaka Takeuchi en Ikujiro Nonaka, ik denk dat het uitgesproken is, produceerden een artikel met de titel 'Moving the Scrum Downfield'. Ze introduceerden dit idee van een methodiek om een ​​rugbyspel te winnen vanuit deze scrumactiviteit, waarbij iedereen op één plek rondloopt en twee teams in wezen hoofden opsluiten in een zogenaamde scrum om te proberen controle over de bal te krijgen en deze het veld in te spelen om ga naar de try-lijn en raak de grond met de bal en krijg een punt, een trine genoemd, en je herhaalt dit proces en je krijgt meer punten voor het team.

Dit artikel werd in 1986 gepubliceerd in de Harvard Business Review en merkwaardig genoeg kreeg het eigenlijk veel aandacht. Het kreeg veel aandacht omdat het geweldige nieuwe concepten introduceerde en hier is een screenshot van de voorkant ervan. Dus haalden ze dit concept van scrum uit het rugbyspel en brachten het in de handel en met name in het spel van ontwerp en projectlevering, in het bijzonder projectlevering.

Wat Scrum deed was ons een nieuwe methodologie geven in vergelijking met PRINCE2 of PMBOK die we eerder hadden gebruikt in wat we de waterval-methodologie noemden, weet je, doe dit ding en dit ding en dit ding en volg ze in volgorde en verbind alle stippen eromheen, wat afhangt van wat je had, of deel twee pas doen als je deel één hebt gedaan, omdat het van deel één afhing. Wat het ons gaf is een nieuwe methode om een ​​beetje flexibeler te zijn, dat is waar de term vandaan komt, over hoe we dingen leveren, en met name rond ontwerp en ontwikkeling grassroots projectlevering.

Sommige van de belangrijkste huurders - alleen maar om hiermee door te gaan - hebben te maken met de belangrijkste huurders van Scrum. Het introduceerde het idee van instabiliteit, dat effectief als je denkt aan de angst voor chaos, de wereld bestaat in een staat van chaos, maar de planeet gevormd, wat interessant is, dus instabiliteit opbouwen, het vermogen om een ​​beetje rond te stuiteren en nog steeds dingen echt laten werken, zelforganiserende projectteams, overlappende gunsten door zeer verantwoorde ontwikkeling, verschillende soorten leren en controle tijdens de reis van de projectuitvoering, de organisatorische overdracht van leren. Dus hoe nemen we informatie van het ene deel van het bedrijf over en dragen het over aan een ander van mensen die een idee hebben maar geen code ontwikkelen of geen databases en infrastructuren ontwikkelen, maar gegevens aan die mensen? En specifiek time-boxed resultaten. Met andere woorden, laten we dit doen voor een periode van tijd, ofwel een dag als in 24 uur, of een week of een paar weken en kijken wat we kunnen doen en dan een stap achteruit doen en ernaar kijken.

En dus, als je de woordspeling wilt excuseren, is dit echt een nieuw spel in projectlevering en de drie kerncomponenten die logisch zijn als we hier wat verder komen - er is het product: al deze mensen hebben het idee en hebben een behoefte om iets gedaan te krijgen en het verhaal dat hen omringt. Ontwikkelaars die werken in het agile model van het krijgen van hun verhalen en via dagelijkse stand-ups met behulp van de scrum-methodiek om het te bespreken en te begrijpen wat ze moeten doen, en dan gewoon doorgaan en het doen. Dan mensen, we hebben gehoord van scrum-meesters die dit geheel overzien en de methodologie goed genoeg begrijpen om het aan te sturen. We hebben allemaal deze afbeeldingen gezien die ik hier aan de rechterkant had van muren en whiteboards vol Post-It-bankbiljetten en ze werden geserveerd als Kanban-muren. Als je niet weet wie Kanban is, nodig ik je uit om Google te vragen wie Mr. Kanban was en waarom het een verandering was in de manier waarop we dingen van de ene naar de andere kant verplaatsen in een muur, letterlijk maar in een project.

De scrum-workflow doet dit in één oogopslag: er is een lijst nodig met dingen die een organisatie wil doen, ze doorlopen een reeks dingen die we sprints noemen die zijn opgedeeld in perioden van 24 uur, maanden lang, en we ontvang deze incrementele reeks uitgangen. Het is een belangrijke verandering in de manier waarop projecten worden opgeleverd, tot op dat moment werden geleverd, omdat een deel daarvan stroomt zoals het Amerikaanse leger dat een groot deel heeft ontwikkeld aan het ontwikkelen van iets genaamd PMBOK, zoals het idee dat de tank niet het veld in gaat totdat je er kogels in steekt, want als een tank in het veld geen kogels heeft, is het nutteloos. Dus deel één wordt kogels in de tank geplaatst, deel twee zet de tank in het veld. Helaas, wat er met ontwikkelaars in de ontwikkelingswereld gebeurde, kreeg deze agile-methode op de een of andere manier te pakken en liep ermee rond, als je de woordspeling gratie verleent, in een sprint.

Wat er altijd gebeurde, is dat wanneer we aan agile denken, we meestal denken aan ontwikkelaars en niet aan databases en alles wat met de wereld van databases te maken heeft. Het was een ongelukkige uitkomst, omdat de realiteit is dat agile niet beperkt is tot ontwikkelaars. Naar mijn mening wordt de term agile naar mijn mening vaak uitsluitend geassocieerd met softwareontwikkelaars en niet met databaseontwerpers en architecten. Steeds dezelfde uitdagingen waarmee u te maken krijgt bij de ontwikkeling van software en applicaties, hebben te maken met alles wat te maken heeft met het ontwerp en de ontwikkeling en de werking en het onderhoud en dus met de gegevensinfrastructuur en met name databases. De actoren in deze specifieke datacast zijn onder meer data-architecten, vormgevers, de beheerders, beheerders van de database-infrastructuren en de eigenlijke databases zelf tot business- en systeemanalisten en architecten, mensen die zitten en nadenken over hoe de systemen en bedrijven opereren en hoe we hiermee gegevens hebben kunnen doorstromen.

Het is een onderwerp dat ik regelmatig ter sprake breng omdat het een constante frustratie van mij is, omdat ik heel erg van mening ben dat dataspecialisten nu nauw betrokken moeten zijn bij elk onderdeel van de projectuitvoering, echt, met name ontwikkeling. Als we dat niet doen, geven we onszelf echt niet de beste kans op een goed resultaat. We moeten vaak terugdraaien en opnieuw nadenken over deze dingen omdat er een scenario bestaat, we een applicatie bouwen en we ontdekken dat de ontwikkelaars niet altijd data-experts zijn. Het werken met databases vereist zeer gespecialiseerde vaardigheden, met name rond gegevens, en bouwt een ervaring op. Je wordt niet zomaar meteen een database-goeroe of data-kennisexpert; dit is vaak iets dat voortkomt uit een levenslange ervaring en zeker met mensen als Dr. Robin Bloor over de Code Today, die het boek vrij rijk heeft geschreven.

In veel gevallen - en het is jammer maar het is een realiteit - dat er twee delen van deze medaille zijn, dat softwareontwikkelaars een eigen black-out hebben met betrekking tot databasespecialist en de vaardigheden hebben opgebouwd die u nodig hebt bij het modelleren van databaseontwerp, waarbij modelontwikkeling slechts de fundamenteel voor de engineering van goeroes over hoe data binnenkomt en hoe de organisatie van de reis die het neemt en hoe het er al dan niet zou moeten uitzien, of ongetwijfeld dat opgenomen en begrip dat het meestal wordt verkregen in native vaardigheden voor softwareontwikkelaars. En enkele van de veel voorkomende uitdagingen waar we voor staan, om het in context te plaatsen, zijn onder meer het maken van alleen basiscreatie en onderhoud en beheer van het basisdatabaseontwerp zelf, het documenteren van de gegevens en de database-infrastructuur en het vervolgens hergebruiken van die gegevensactiva, schemaontwerpen, schema-generaties, beheer en onderhoud van het schema en het gebruik ervan, het delen van de kennis waarom dit schema op een bepaalde manier is ontworpen en de sterke en zwakke punten die daar in de loop van de tijd mee gepaard gaan, leiden tot gegevensveranderingen in de tijd, gegevensmodellering en de typen van modellen die we toepassen op de systemen en gegevens die we er doorheen stromen. Genereren van databasecodes en het gaat verder met integratie en vervolgens gemodelleerde gegevens om hen heen en dan sneller toegang om de beveiliging rond de gegevens te beheren, de integriteit van de gegevens verplaatsen we de gegevens terwijl we de integriteit ervan behouden, is er voldoende metagegevens Moet de verkoop alle records in de tabel zien of moeten ze alleen het adres, de voornaam, de achternaam zien die je dingen in de post stuurt? En dan is natuurlijk de grootste uitdaging van allemaal het modelleren van databaseplatforms dat op zichzelf een heel ander gesprek is.

Ik ben heel erg van mening dat met dit alles in gedachten om dit nirvana mogelijk te maken, het absoluut van cruciaal belang is dat zowel de dataspecialisten als ontwikkelaars de juiste tools hebben en dat deze tools in staat zijn tot teamgerichte projectlevering, ontwerp, ontwikkeling en doorlopend operationeel onderhoud. Weet je, dingen zoals samenwerken in projecten tussen data-experts en softwareontwikkelaars, één punt van waarheid of één bron van waarheid voor alles rondom documentatie van de databases zelf, de gegevens, de schema's, waar de records vandaan komen, eigenaren van die records . Ik denk dat het vandaag de dag absoluut cruciaal is, we krijgen dit nirvana van data als koning, dat de juiste tools aanwezig moeten zijn omdat de uitdaging nu te groot is voor ons om het handmatig te doen, en als mensen in en uit een organisatie stappen, het is te gemakkelijk voor ons om niet hetzelfde proces of dezelfde methode te volgen die een persoon zou kunnen opzetten die goed zijn en die niet noodzakelijkerwijs die vaardigheden en capaciteiten in de toekomst overdragen.

Met dat in gedachten ga ik naar onze goede vriend bij IDERA en hoor ik over die tool en hoe het deze dingen aanpakt.

Ron Huizenga: Heel erg bedankt en dank aan zowel Robin als Dez voor het feit dat ze echt het podium hebben gezet, en je zult een beetje overlap zien in een paar dingen waar ik het over heb gehad. Maar ze hebben echt een zeer solide basis gelegd voor enkele van de concepten waar ik het over heb vanuit een perspectief van gegevensmodellering. En veel van de dingen die ze hebben gezegd, weerspiegelen mijn eigen ervaring toen ik een consultant was die werkte aan datamodellering en data-architectuur, samen met teams - zowel waterval in de vroege dagen als evoluerend naar meer moderne producten met projecten waarbij we agile gebruikten methodieken om oplossingen te leveren.

Dus waar ik het vandaag over ga hebben, is gebaseerd op die ervaringen en op een overzicht van de tools en enkele van de mogelijkheden in de tools die we gebruiken om ons op die reis te helpen. Wat ik heel kort ga behandelen, is dat ik niet in detail zal treden; we hadden net een heel goed overzicht van wat dat is. Ik ga erover praten in termen van, wat is een datamodel en wat betekent het echt voor ons? En hoe kunnen we het concept van de agile datamodeler in onze organisaties mogelijk maken, in termen van, hoe betrekken we de datamodelers, wat is de deelname van modelleerders en architecten tijdens de sprint, wat zijn de soorten activiteiten waaraan ze moeten deelnemen en wat zijn enkele van de belangrijke mogelijkheden van modelleringshulpmiddelen die we gebruiken om die taak echt gemakkelijker te maken? Dan ga ik een beetje afronden en een beetje praten over enkele van de zakelijke waarden en voordelen van het betrekken van een datamodeler, of de manier waarop ik het verhaal ga vertellen is, de problemen van het niet hebben van een datamodeler die volledig betrokken is bij de projecten en ik zal je dat laten zien op basis van ervaring en een defectgrafiek van een voor en na afbeelding van een echt project waar ik vele jaren geleden bij betrokken was. En dan zullen we nog een paar punten samenvatten en dan nog vragen en antwoorden hebben.

Heel kort is ER Studio een zeer krachtige suite met veel verschillende componenten. De Data Architect, dat is waar de datamodelers en architecten het grootste deel van hun tijd aan hun datamodellering besteden. Er zijn ook andere componenten waar we het vandaag helemaal niet over zullen hebben, zoals de Business Architect, waar we procesmodellering doen en de Software Architect, voor een deel van de UML-modellering. Dan is er de Repository, waar we inchecken en we de modellen delen en we laten de teams hieraan samenwerken en ze publiceren op de teamserver, zodat meerdere belanghebbenden die betrokken zijn bij een project de artefacten kunnen zien die we ' opnieuw creëren vanuit een gegevensperspectief, evenals de andere dingen die we doen in de projectlevering zelf.

Waar ik me vandaag op ga richten, zijn een paar dingen die we uit Data Architect gaan zien en omdat het echt belangrijk is dat we de samenwerking hebben met op Repository gebaseerde aspecten daarvan. In het bijzonder wanneer we beginnen te praten over concepten zoals verandermanagement die onontbeerlijk zijn voor niet alleen behendige ontwikkelingsprojecten, maar voor elke vorm van ontwikkeling in de toekomst.

Laten we het daarom even over de Agile Data Modeler hebben. Zoals we eerder in de presentatie hebben gezegd, is het noodzakelijk dat we datamodelers en / of architecten hebben die zich volledig bezighouden met de agile ontwikkelingsprocessen. Wat er historisch is gebeurd is, ja, we hebben echt nagedacht over agile vanuit een ontwikkelingsperspectief, en er zijn een paar dingen gebeurd die dat echt hebben veroorzaakt. Een deel ervan was te wijten aan alleen de aard van de manier waarop de ontwikkeling zich ontvouwde. Toen de agile ontwikkeling begon en we begonnen met dit concept van zelforganiserende teams, als je de Kool-Aid een beetje te puur dronk en je was aan de extreme programmeerkant van dingen, was er een zeer letterlijke interpretatie van dingen zoals de zelforganiserende teams, wat door veel mensen wordt geïnterpreteerd, we hebben alleen een groep ontwikkelaars nodig die een hele oplossing kan bouwen. Of het nu gaat om het ontwikkelen van de code, de databases of de achterliggende datastores en alles werd overgedragen aan de ontwikkelaars. Maar wat daarmee gebeurt, is dat je de speciale vaardigheden die mensen hebben misloopt. Ik heb ontdekt dat de sterkste teams zijn die zijn samengesteld uit mensen met verschillende achtergronden. Zoals een combinatie van sterke softwareontwikkelaars, data-architecten, datamodelers, bedrijfsanalisten en zakelijke stakeholders, die allemaal samenwerken om een ​​eindoplossing te verdrijven.

Waar ik het vandaag ook over heb, is dat ik dit ga doen in de context van een ontwikkelingsproject waarbij we een applicatie ontwikkelen waaraan uiteraard ook de gegevenscomponent is gekoppeld. We moeten echter wel een stap achteruit doen voordat we dat doen, omdat we ons moeten realiseren dat er maar heel weinig Greenfield-ontwikkelingsprojecten zijn waar we ons volledig richten op het creëren en verbruiken van gegevens die alleen beperkt zijn binnen dat ontwikkelingsproject zelf . We moeten een stap achteruit doen en vanuit een gegevensperspectief en een procesperspectief naar het algemene organisatieperspectief kijken. Omdat we ontdekken dat de informatie die we gebruiken al ergens in de organisaties bestaat. Als modelbouwers en architecten brengen we dat aan het licht, zodat we weten waar we die informatie vandaan moeten halen in de projecten zelf. We kennen ook de gegevensstructuren die erbij betrokken zijn, omdat we ontwerppatronen hebben, net zoals ontwikkelaars ontwerppatronen voor hun code hebben. En we moeten ook rekening houden met dat algemene organisatorische perspectief. We kunnen niet alleen naar gegevens kijken in de context van de applicatie die we bouwen. We moeten de gegevens modelleren en ervoor zorgen dat we het documenteren, omdat het lang buiten de toepassingen zelf leeft. Die applicaties komen en gaan, maar we moeten de gegevens kunnen bekijken en ervoor zorgen dat deze robuust en goed gestructureerd zijn, niet alleen voor applicaties, maar ook voor beslissingen die activiteiten, BI-rapportage en integratie met andere applicaties rapporteren, interne en ook buiten onze organisaties. We moeten dus kijken naar dat hele grote beeld van de gegevens en wat de levenscyclus van die gegevens is en de reis van stukjes informatie door de hele organisatie begrijpen, van wieg tot graf.

Nu terug naar de eigenlijke teams zelf en hoe we eigenlijk moeten werken, werd de watervalmethodologie als te langzaam ervaren om resultaten te leveren. Omdat het, zoals aangegeven in het tankvoorbeeld, de ene stap na de andere was en het vaak te lang duurde om een ​​werkbaar eindresultaat te leveren. Wat we nu doen, is dat we een iteratieve werkstijl moeten hebben waarbij we onderdelen ervan stapsgewijs ontwikkelen en in de loop van de tijd uitwerken waarin we bruikbare code of bruikbare artefacten produceren, zeg ik, voor elke sprint. Het belangrijkste is samenwerking tussen de technische belanghebbenden in het team en de zakelijke belanghebbenden, terwijl we samenwerken om die gebruikersverhalen te verdrijven in een uitvoerbare visie op code en de gegevens die die code ook ondersteunen. En de Agile Data Modeler zelf zal vaak merken dat we niet genoeg modelers in organisaties hebben, zodat één datamodeler of architect tegelijkertijd meerdere teams ondersteunt.

En het andere aspect daarvan is, zelfs als we meerdere modelleerders hebben, moeten we ervoor zorgen dat we een toolset hebben die we gebruiken die samenwerking mogelijk maakt van meerdere projecten die tegelijkertijd aan de gang zijn en die delen gegevensartefacten en de in- en uitcheckmogelijkheden. Ik ga dit heel snel bespreken omdat we het al in het vorige gedeelte hebben behandeld. Het echte uitgangspunt van Agile is dat je dingen baseert op achterstand, verhalen of vereisten. Binnen de iteraties werken we als groep samen. Typisch is een sprint van twee weken of een maand, afhankelijk van de organisatie, heel gebruikelijk. En ook dagelijkse evaluatie- en stand-up-vergaderingen, zodat we blokkers elimineren en ervoor zorgen dat we alle aspecten vooruit helpen zonder te worden gestopt in verschillende gebieden terwijl we doorlopen. En in die sprints willen we ervoor zorgen dat we bruikbare deliverables produceren als een deel van elke sprint.

Gewoon een iets andere kijk daarop, scrum is de methode waar ik hier meer specifiek over ga praten en we hebben die vorige foto in feite alleen maar uitgebreid met een paar andere facetten. Meestal is er een productachterstand en dan is er een sprintachterstand. We hebben dus een algehele achterstand die we aan het begin van elke sprintherhaling willen afdoen en zeggen: "Wat gaan we deze sprint opbouwen?" En dat gebeurt in een sprintplanningsvergadering. Vervolgens splitsen we de taken op die daarmee verband houden en voeren we die sprints van één tot vier weken uit met die dagelijkse reviews. Terwijl we dat doen, volgen we onze voortgang door middel van burn-up-diagrammen en burn-downdiagrammen om in principe bij te houden wat we moeten bouwen versus wat we bouwen om dingen vast te stellen zoals wat onze ontwikkelingssnelheid is, gaan we onze schema, al dat soort dingen. Al deze worden tijdens de sprint continu uitgewerkt in plaats van een paar maanden verder te gaan en erachter te komen dat je tekort komt en je het projectschema moet verlengen. En heel belangrijk, als onderdeel daarvan, de hele teams, er is een sprintrecensie aan het einde en een sprintretrospectief, dus voordat je de volgende iteratie begint, bekijk je wat je hebt gedaan en ben je op zoek naar manieren om de volgende keer verbeteren.

In termen van deliverables is dit eigenlijk een dia die de typische soorten dingen samenvat die in sprints gaande zijn. En het is erg ontwikkelingsgericht, dus veel van de dingen die we hier zien, zoals functionele ontwerpen en use cases, ontwerpcodetests doen, als we deze vakken hier bekijken, en ik ga er niet doorheen in elk detailniveau zijn ze erg ontwikkelingsgericht. En hieronder begraven ligt het feit dat we ook die gegevens moeten hebben die hiermee gepaard gaan om deze inspanning te ondersteunen. Dus elke keer dat we dingen zien zoals de achterstanden, de vereisten en gebruikersverhalen, moeten we tijdens het doorlopen kijken naar wat de ontwikkelingsonderdelen zijn die we moeten doen, wat zijn de analyseonderdelen die we moeten doen, hoe zit het met gegevensontwerp of het gegevensmodel, hoe zit het met zaken als de zakelijke woordenlijsten zodat we bedrijfsbetekenissen kunnen associëren met alle artefacten die we produceren? Omdat we die bruikbare deliverables in elke sprint moeten produceren.

Sommige mensen zullen zeggen dat we aan het einde van elke sprint bruikbare code moeten produceren. Dat is niet noodzakelijkerwijs het geval, dat is het in een puur ontwikkelingsperspectief, maar heel vaak - vooral in het begin - kunnen we zoiets als de sprint nul hebben, waarbij we ons puur richten op het rechtzetten, dingen doen zoals onze teststrategieën binnenhalen plaats. Een ontwerp op hoog niveau om aan de slag te gaan voordat we beginnen met het invullen van de details en ervoor zorgen dat we een schone set van startverhalen of vereisten hebben voordat we andere doelgroepen aanspreken en vervolgens verder bouwen als een team terwijl we verder gaan. Er is altijd een klein beetje voorbereidingstijd, dus vaak hebben we een sprint nul of zelfs sprint nul en één. Misschien een beetje een opstartfase voordat we de volledige vlucht nemen om de oplossing te leveren.

Laten we het in dit verband heel kort hebben over datamodellen. Wanneer mensen aan datamodellen denken, beschouwen ze een datamodel vaak als een afbeelding van hoe de verschillende stukjes informatie samenkomen - dat is slechts het topje van de ijsberg. Om volledig te belichamen hoe je echt datamodellering wilt benaderen - of het nu in agile ontwikkeling en andere dingen is - moet je je realiseren dat datamodel, indien correct gedaan, je volledige specificatie wordt voor wat die data in de organisatie betekent en hoe het wordt geïmplementeerd in de back-enddatabases. Als ik databases zeg, bedoel ik niet alleen de relationele databases die we mogelijk gebruiken, maar in hedendaagse architecturen waar we big data of NoSQL-platforms hebben, zoals ik ze liever noem. Ook die big data-winkels, omdat we veel verschillende data-winkels kunnen combineren op het gebied van informatieconsumptie en het in onze oplossingen brengen, evenals hoe we die informatie ook in onze oplossingen bewaren of bewaren.

We werken mogelijk met meerdere databases of gegevensbronnen tegelijkertijd in het kader van een bepaalde toepassing. Wat heel belangrijk is, is dat we een volledige specificatie willen hebben, dus een logische specificatie van wat dit betekent voor een sprintorganisatieperspectief, wat de fysieke constructies zijn in termen van hoe we de gegevens daadwerkelijk definiëren, de relaties daartussen in uw databases, uw referentiële integriteitsbeperkingen, controlebeperkingen, al die validatiestukken waar u doorgaans aan denkt. De beschrijvende metadata is uiterst belangrijk. Hoe weet u hoe u de gegevens in uw applicaties kunt gebruiken? Tenzij u het kunt definiëren en weet wat het betekent of weet waar het vandaan komt om ervoor te zorgen dat u de juiste gegevens in die toepassingen gebruikt - zorg ervoor dat we correcte naamgevingsconventies hebben, volledige definities, wat betekent dat een volledig gegevenswoordenboek voor niet alleen de tabellen, maar de kolommen die deze tabellen bevatten - en gedetailleerde opmerkingen over de inzet over hoe we dat gebruiken omdat we deze kennisbank moeten opbouwen, want zelfs wanneer deze applicatie klaar is, zal deze informatie worden gebruikt voor andere initiatieven, dus we moeten ervoor zorgen dat dat we alles hebben gedocumenteerd voor toekomstige implementaties.

Nogmaals, we komen op zaken als gegevenstypen, sleutels, indexen, het datamodel zelf belichaamt veel van de bedrijfsregels die een rol spelen. De relaties zijn niet alleen beperkingen tussen verschillende tabellen; ze helpen ons vaak om te beschrijven wat de echte bedrijfsregels zijn rond hoe die gegevens zich gedragen en hoe ze samenwerken als een samenhangende eenheid. En natuurlijk zijn waardebeperkingen erg belangrijk. Nu, natuurlijk, een van de dingen waar we constant mee te maken hebben, en het komt steeds vaker voor, zijn dingen als data governance. Dus vanuit het oogpunt van gegevensbeheer moeten we ook kijken naar wat we hier definiëren? We willen zaken definiëren als beveiligingsclassificaties. Met welke soorten gegevens hebben we te maken? Wat wordt als stamgegevensbeheer beschouwd? Wat zijn de transactionele winkels die we creëren? Welke referentiegegevens gebruiken we in deze applicaties? We moeten ervoor zorgen dat dit correct wordt vastgelegd in onze modellen. En ook overwegingen met betrekking tot de gegevenskwaliteit, er zijn bepaalde stukjes informatie die belangrijker zijn voor een organisatie dan andere.

Ik ben betrokken geweest bij projecten waarbij we meer dan een dozijn oudere systemen vervangen door nieuwe bedrijfsprocessen en nieuwe applicaties en gegevensarchieven ontwerpen om deze te vervangen. We moesten weten waar de informatie vandaan kwam. Wat voor de belangrijkste stukjes informatie, vanuit een zakelijk perspectief, als je naar deze specifieke datamodeldia kijkt die ik hier heb, zie je dat de onderste vakken in deze specifieke entiteiten, wat slechts een kleine subset is, ik heb de bedrijfswaarde daadwerkelijk kunnen vastleggen. Of dit nu hoog, gemiddeld of laag is voor dit soort dingen voor deze verschillende constructies binnen de organisatie. En ik heb ook dingen vastgelegd zoals de stamgegevensklassen, of het hoofdtabellen zijn, of ze referentie zijn, of ze transactiegerelateerd waren. Dus we kunnen onze metagegevens in onze modellen uitbreiden om ons veel andere kenmerken buiten de gegevens zelf te geven, wat ons echt heeft geholpen met andere initiatieven buiten de oorspronkelijke projecten en deze verder kan brengen. Nu dat veel in één dia was, ga ik de rest van deze vrij snel doornemen.

Ik ga nu heel snel praten over wat een datamodeler doet tijdens deze verschillende sprints. Allereerst een volledige deelnemer aan de sprintplanningssessies, waar we de gebruikersverhalen nemen, ons verbinden aan wat we in die sprint gaan leveren, en uitzoeken hoe we het gaan structureren en afleveren. Wat ik ook als datamodeler doe, is dat ik weet dat ik in verschillende gebieden met verschillende ontwikkelaars of met verschillende mensen ga werken. Dus een van de belangrijke kenmerken die we kunnen hebben, is dat wanneer we een gegevensmodel maken, we dat gegevensmodel in verschillende weergaven kunnen verdelen, of u ze nu onderwerpgebieden of submodellen noemt, onze terminologie is. Dus terwijl we het model opbouwen, tonen we het ook in deze verschillende submodelperspectieven, zodat de verschillende doelgroepen alleen zien wat voor hen relevant is, zodat ze zich kunnen concentreren op wat ze ontwikkelen en naar voren brengen. Dus misschien heb ik iemand die aan een planningsonderdeel van een applicatie werkt, misschien heb ik iemand anders die aan een orderinvoer werkt waar we al deze dingen in één sprint doen, maar ik kan ze de gezichtspunten geven via die submodellen die alleen van toepassing op het gebied waar ze aan werken. En dan komen die samen in het algemene model en de hele structuur van submodellen om verschillende kijkers van het publiek te geven wat ze moeten zien.

Basisprincipes vanuit een perspectief van gegevensmodellering dat we willen hebben, hebben altijd een basislijn waar we naar terug kunnen gaan, omdat een van de dingen die we moeten kunnen doen is, of het nu aan het einde van een sprint is of aan het einde van verschillende sprints willen we weten waar we zijn begonnen en hebben we altijd een baseline om te weten wat de delta was of het verschil van wat we in een bepaalde sprint produceerden. We moeten er ook voor zorgen dat we een snelle ommekeer hebben. Als je er binnenkomt als datamodeler, maar in de traditionele poortwachter bent en zegt: "Nee, nee, dat kun je niet doen, we moeten dit allemaal eerst doen", dan word je uitgesloten van het team wanneer je echt nodig hebt om een ​​actieve deelnemer te zijn in al die flexibele ontwikkelingsteams. Dat betekent dat sommige dingen van de wagen vallen tijdens een bepaalde sprint en je ze opraapt in latere sprints.

Als een voorbeeld kunt u zich concentreren op de datastructuren om de ontwikkeling op gang te brengen, zeg maar, dat orderinvoerstuk waar ik het over had. In een latere sprint kunt u terugkomen en de gegevens invullen, zoals enkele documentatie voor het gegevenswoordenboek rond enkele van die artefacten die u hebt gemaakt. Je gaat die definitie niet allemaal in één sprint voltooien; u gaat uw leveringen incrementeel voortzetten, omdat er tijden kunnen zijn dat u die informatie kunt invullen in samenwerking met bedrijfsanalisten wanneer de ontwikkelaars bezig zijn met het bouwen van de applicaties en de persistentie rond die datastores. U wilt faciliteren en niet het knelpunt zijn. Er zijn verschillende manieren waarop we met ontwikkelaars werken. Voor sommige dingen hebben we ontwerppatronen, dus we zijn van tevoren een volledige deelnemer, dus we kunnen een ontwerppatroon hebben waarvan we zullen zeggen dat we het in het model zullen stoppen, we zullen het naar de sandbox-databases van de ontwikkelaars duwen en dan kunnen ze begin ermee te werken en vraag daar wijzigingen in aan.

Er zijn misschien andere gebieden waar ontwikkelaars aan werken, ze hebben iets waar ze aan werken en ze maken prototypen van sommige dingen, zodat ze sommige dingen uitproberen in hun eigen ontwikkelomgeving. We nemen die database waarmee ze hebben gewerkt, brengen deze in onze modelleringstool, vergelijken met de modellen die we hebben en lossen vervolgens de wijzigingen op en duwen ze terug zodat ze hun codes kunnen wijzigen zodat ze de juiste gegevensstructuren volgen die we nodig hebben. Omdat ze sommige dingen hebben gecreëerd die we elders al hadden, dus zorgen we ervoor dat ze met de juiste gegevensbronnen werken. We blijven maar doorgaan tot aan onze sprint, zodat we de volledige gegevensprestaties, volledige documentatie en de definitie van al die gegevensstructuren krijgen die we produceren.

De meest succesvolle agile projecten waar ik bij betrokken ben geweest in termen van zeer goede leveringen is, we hadden een filosofie, modelleren alle wijzigingen in de volledige fysieke database-specificatie. In wezen wordt het datamodel de geïmplementeerde databases waarmee u werkt voor alles wat we maken en heeft het volledige referenties van de andere datastores als we verbruiken vanuit andere externe databases. Als onderdeel daarvan produceren we incrementele scripts versus elke keer een volledige generatie doen. En we gebruiken onze ontwerppatronen om ons die snelle lift te geven in termen van dingen in sprints te laten gaan met de verschillende ontwikkelingsteams waarmee we samenwerken.

Ook bij sprintactiviteiten is dat weer de basislijn voor vergelijken / samenvoegen, dus laten we het idee nemen om elke verandering te modelleren. Elke keer dat we een verandering doen, willen we de verandering modelleren en wat heel belangrijk is, wat tot voor kort ontbrak in datamodellering, in feite, totdat we het opnieuw introduceerden, is de mogelijkheid om de modellering te associëren taken en uw deliverables met de gebruikersverhalen en taken die deze wijzigingen daadwerkelijk veroorzaken. We willen onze modelwijzigingen kunnen inchecken, op dezelfde manier waarop ontwikkelaars hun codes inchecken, verwijzend naar die gebruikersverhalen die we hebben, zodat we weten waarom we in de eerste plaats wijzigingen hebben aangebracht, dat is iets wat we doen. Wanneer we dat doen, genereren we onze incrementele DDL-scripts en plaatsen we deze zodat ze kunnen worden opgepikt bij de andere ontwikkelingsproducten en kunnen worden ingecheckt in onze build-oplossing. Nogmaals, we kunnen één model hebben of met meerdere teams werken. En zoals ik al heb gezegd, sommige dingen zijn afkomstig van de datamodeler, andere dingen zijn afkomstig van de ontwikkelaars en we ontmoeten elkaar in het midden om het algehele beste ontwerp te bedenken en het naar voren te schuiven en ervoor te zorgen dat het correct is ontworpen in onze algemene gegevensstructuren. We moeten de discipline handhaven om ervoor te zorgen dat we alle juiste constructies in ons datamodel hebben terwijl we verder gaan, inclusief dingen zoals null en niet null-waarden, verwijzingsbeperkingen, in principe constraints controleren, al die dingen waar we normaal gesproken aan zouden denken .

Laten we het nu hebben over een paar screenshots van enkele van de hulpmiddelen die ons hierbij helpen. Wat ik belangrijk vind is het hebben van die collaboratieve repository, dus wat we kunnen doen als datamodelers - en dit is een fragment van een deel van een datamodel op de achtergrond - is wanneer we werken aan dingen die we ervoor willen zorgen dat we kunnen werken alleen aan de objecten die we moeten kunnen veranderen, de aanpassingen kunnen maken, onze DDL-scripts genereren voor de wijzigingen die we hebben aangebracht terwijl we de dingen weer inchecken. Dus wat we kunnen doen, is in ER Studio een voorbeeld, we kunnen objecten of groepen objecten bekijken om aan te werken, we hoeven geen heel model of submodel te bekijken, we kunnen alleen die dingen bekijken die voor ons interessant zijn. Wat we daarna willen, is bij het uitchecken of bij het inchecken - we doen het op beide manieren omdat verschillende ontwikkelteams op verschillende manieren werken. We willen ervoor zorgen dat we dat associëren met het gebruikersverhaal of de taak die aan de eisen hiervoor voldoet en dat hetzelfde gebruikersverhaal of dezelfde taak zal zijn dat de ontwikkelaars hun code zullen ontwikkelen en inchecken.

Dus hier is een zeer snel fragment van een paar schermen van een van onze verandermanagementcentra. Wat dit doet, ga ik hier niet in detail doorlopen, maar wat u ziet is het gebruikersverhaal of de taak en ingesprongen onder elk van degenen die u de werkelijke wijzigingsrecords ziet - we hebben een geautomatiseerd wijzigingsrecord gemaakt wanneer we doen de check-in en check-out en we kunnen ook meer informatie over dat wijzigingsrecord plaatsen. Het is gekoppeld aan de taak, we kunnen meerdere wijzigingen per taak hebben, zoals je zou verwachten. En als we die veranderrecord bekijken, kunnen we ernaar kijken en nog belangrijker, wat hebben we eigenlijk veranderd? Voor deze specifieke, het gemarkeerde verhaal daar, had ik één type verandering die werd aangebracht en toen ik naar het feitelijke wijzigingsverslag zelf keek, heeft het de afzonderlijke stukken in het model geïdentificeerd die zijn veranderd. Ik heb hier een aantal attributen veranderd, ze opnieuw ingedeeld en het bracht voor de rit de aanzichten die moesten worden gewijzigd die daar ook van afhankelijk waren, zodat ze zouden worden gegenereerd in de incrementele DLL. Het gaat niet alleen om het modelleren van de basisobjecten, maar een krachtig modelleringsprogramma zoals dit detecteert ook de wijzigingen die ook door de afhankelijke objecten in de database of het gegevensmodel moeten worden gerippeld.

Als we met ontwikkelaars werken, en we doen dit in een aantal verschillende dingen, dat is iets doen in hun sandbox en we willen vergelijken en zien waar de verschillen zijn, gebruiken we vergelijk / samenvoegmogelijkheden waar aan de rechterkant en links kant. We kunnen zeggen: "Hier is ons model aan de linkerkant, hier is hun database aan de rechterkant, laat me de verschillen zien." We kunnen dan kiezen hoe we die verschillen oplossen, of we dingen in de database duwen of als er zijn enkele dingen die ze in de database hebben die we terugbrengen in het model. We kunnen bidirectioneel gaan, zodat we beide kanten op kunnen gaan en tegelijkertijd zowel bron als doel bijwerken en vervolgens de incrementele DDL-scripts produceren om die wijzigingen in de databaseomgeving zelf te implementeren, wat uiterst belangrijk is. Wat we ook kunnen doen, is dat we deze vergelijk- en samenvoegmogelijkheid ook op elk gewenst moment kunnen gebruiken. Als we onderweg foto's maken, kunnen we het begin van de ene sprint altijd vergelijken met het begin of het einde van een andere sprint, zodat we kunnen zien de volledige incrementele verandering van wat werd gedaan in een gegeven ontwikkelingssprint of over een reeks sprints.

Dit is een zeer snel voorbeeld van een alter-script, iedereen die met databases heeft gewerkt, zal dit soort dingen hebben gezien, dit is wat we uit de code kunnen verwijderen als een alter-script zodat we ervoor zorgen dat we dingen hier bewaren. Wat ik hier heb weggehaald, alleen om rommel te verminderen, is wat we ook doen met deze alter scripts is dat we aannemen dat er ook gegevens in die tabellen zijn, dus we zullen ook de DML genereren die de informatie van de tijdelijke tabellen haalt en duw het ook terug in de nieuwe datastructuren, dus we kijken niet alleen naar de structuren, maar ook naar de gegevens die we mogelijk al in die structuren hebben opgenomen.

Ik ga heel snel praten over geautomatiseerde build-systemen, want wanneer we een agile-project doen, werken we vaak met geautomatiseerde build-systemen waarbij we de verschillende deliverables samen moeten inchecken om ervoor te zorgen dat we onze builds niet breken. Wat dat betekent is dat we de te leveren producten synchroniseren, die veranderingsscripts waar ik het over had met het DDL-script moeten worden ingecheckt, de bijbehorende applicatiecode moet tegelijkertijd worden ingecheckt en veel ontwikkelaarsontwikkeling is nu natuurlijk niet wordt gedaan met directe SQL tegen de databases en dat soort dingen. Heel vaak gebruiken we persistentiekaders of bouwen we datadiensten. We moeten ervoor zorgen dat de wijzigingen voor die frameworks of services op precies hetzelfde moment worden ingecheckt. Ze gaan in sommige organisaties in een geautomatiseerd buildsysteem en als de build breekt, in een agile methodiek, zijn het allemaal hands-on deck fixing die build voordat we verder gaan, zodat we weten dat we een werkende oplossing hebben voordat we verder gaan. En een van de projecten waar ik bij betrokken was, hebben we tot het uiterste gebracht - als de build kapot was die we eigenlijk hadden aangesloten op een aantal computers in ons gebied waar we waren samen met de zakelijke gebruikers, hadden we alleen rode knipperlichten zoals de top van politieauto's. En als de build brak, begonnen die rode knipperende lichten uit te gaan en we wisten dat het allemaal aan dek lag: repareer de build en ga verder met wat we aan het doen waren.

Ik wil over andere dingen praten, en dit is een unieke mogelijkheid voor ER Studio, het helpt echt wanneer we proberen deze artefacten te bouwen als ontwikkelaars voor deze persistentiegrenzen, we hebben een concept genaamd zakelijke gegevensobjecten en wat ons in staat stelt om Als je dit zeer simplistische datamodel als een voorbeeld bekijkt, kunnen we entiteiten of groepen entiteiten inkapselen voor de grenzen van persistentie. Waar wij als datamodeler misschien denken aan zoiets als een kop van een inkooporder en de orderuitlijning en andere gedetailleerde tabellen die daarop zouden aansluiten bij de manier waarop we het samenstellen en onze datadienstenontwikkelaars moeten weten hoe dingen blijven bestaan ​​voor die verschillende gegevens structuren. Onze ontwikkelaars denken over dingen als de inkooporder in het algemeen als een object en wat is hun contract met hoe ze die specifieke objecten maken. We kunnen dat technische detail blootleggen, zodat de mensen die de gegevensservers bouwen, kunnen zien wat eronder zit en we kunnen het andere publiek beschermen tegen de complexiteit, zodat ze alleen de verschillende objecten op een hoger niveau zien, wat ook heel goed werkt voor communicatie met het bedrijfsleven analisten en zakelijke stakeholders als we het ook hebben over de interactie van verschillende bedrijfsconcepten.

Het mooie hiervan is ook dat we deze constructief uitbreiden en samenvouwen, zodat we de relaties tussen de objecten van een hogere orde kunnen handhaven, ook al zijn ze afkomstig van constructen die zijn opgenomen in die bedrijfsgegevensobjecten zelf. Ga nu als modeler naar het einde van de sprint, aan het einde van de sprintafwikkeling, heb ik veel dingen die ik moet doen, die ik mijn huishouden voor de volgende sprint noem. Elke sprint die ik maak wat ik de Named Release noem - dat geeft me mijn basislijn voor wat ik nu heb aan het einde van de release. Dus dat betekent dat mijn basislijn in de toekomst is, al deze basislijnen of benoemde releases die ik maak en opsla in mijn repository die ik kan gebruiken om te vergelijken / samen te voegen, zodat ik altijd kan vergelijken met een bepaald einde van de sprint van elke andere sprint, die is erg belangrijk om te weten wat uw wijzigingen waren in uw gegevensmodel tijdens de reis.

Ik maak ook een delta DDL-script met het vergelijken / samenvoegen opnieuw van begin tot einde van de sprint. Ik heb misschien een hele reeks incrementele scripts ingecheckt, maar als ik het nodig heb, heb ik nu een script dat ik kan inzetten om andere sandboxen te laten staan, dus ik kan gewoon zeggen dat dit is wat we hadden aan het begin van de ene sprint, push het door, bouw een database als een sandbox om te beginnen met de volgende sprint en we kunnen die dingen ook gebruiken om dingen te doen zoals stand-up QA-instanties en uiteindelijk willen we onze veranderingen naar de productie pushen zodat we meerdere dingen aan de hand hebben tegelijkertijd. Nogmaals, we nemen volledig deel aan de sprintplanning en retrospectieven, de retrospectieven zijn echt de geleerde lessen en dat is uiterst belangrijk, omdat je tijdens agile heel snel aan de slag kunt, moet je stoppen en de successen vieren, zoals nu. Zoek uit wat er mis is, maak het de volgende keer beter, maar vier ook de dingen die goed gingen en bouw daarop voort terwijl je in de volgende sprints vooruit blijft gaan.

Ik ga nu heel snel praten over bedrijfswaarde. Er was een project waar ik jaren geleden bij betrokken raakte dat begon als een agile project, en het was een extreem project, dus het was een puur zelforganiserend team waar alleen ontwikkelaars alles deden. Om een ​​lang verhaal kort te maken, dit project liep vast en ze ontdekten dat ze meer en meer uitgeven aan het verhelpen en herstellen van de geconstateerde defecten dan aan het pushen van meer functionaliteit en, in feite, toen ze ernaar keken op de burn-down grafieken moesten ze het project met zes maanden verlengen tegen hoge kosten. En toen we ernaar keken, was de manier om het probleem op te lossen het gebruik van een geschikt datamodelleringstool met een bekwame datamodeler die bij het project zelf betrokken was.

Als u naar deze verticale balk in deze specifieke grafiek kijkt, toont dit cumulatieve defecten versus cumulatieve objecten, en ik heb het over gegevensobjecten of constructies die zijn gemaakt, zoals de tabellen met de beperkingen en dat soort dingen, als u keek naar voordat de datamodeler werd geïntroduceerd, was het aantal defecten zelfs groter en begon het een beetje een kloof te bouwen over het werkelijke aantal objecten dat tot dat moment was geproduceerd. Na week 21, dat is toen de datamodeler binnenkwam, het datamodel opnieuw gefactureerd op basis van wat er was om een ​​aantal dingen te repareren en vervolgens begon te modelleren als onderdeel van het projectteam in de toekomst, de veranderingen terwijl dat project naar voren werd geschoven . En je zag een zeer snelle ommekeer dat we binnen ongeveer anderhalve sprint een enorme toename zagen in het aantal objecten en gegevensconstructies die werden gegenereerd en geconstrueerd omdat we genereerden vanuit een datamodelleringstool in plaats van een ontwikkelaarstick ze in een omgeving te bouwen, en ze waren correct omdat ze de juiste referentiële integriteit hadden en de andere constructen die het zou moeten hebben. Het niveau van defecten tegen die bijna flatline. Door die juiste actie te ondernemen en ervoor te zorgen dat de datamodellering volledig was ingeschakeld, werd het project op tijd met een veel hoger kwaliteitsniveau geleverd, en in feite zou het helemaal niet hebben geleverd als die stappen niet hadden plaatsgevonden. Er zijn veel agile mislukkingen, er zijn ook veel agile successen als je de juiste mensen in de juiste rol zou krijgen. Ik ben een groot voorstander van agile als operationele discipline, maar je moet ervoor zorgen dat je over de vaardigheden beschikt van alle juiste betrokken groepen als je projectteams terwijl je een behendig type onderneming nastreeft.

Samenvattend moeten data-architecten en modelleerders bij alle ontwikkelingsprojecten worden betrokken; ze zijn echt de lijm die alles bij elkaar houdt, want als datamodelers en architecten begrijpen we niet alleen de dataconstructies van het gegeven ontwikkelingsproject, maar ook waar de data in de organisatie bestaat en waar we die data vandaan kunnen halen en hoe gaat worden gebruikt en gebruikt buiten de specifieke toepassing zelf waar we aan werken. We begrijpen de complexe gegevensrelaties en het is van het grootste belang om vooruit te komen en ook vanuit een governanceperspectief om een ​​document in kaart te brengen en te begrijpen hoe uw volledige gegevenslandschap eruit ziet.

Het is als productie; Ik kwam uit een productieachtergrond. Aan het eind kun je kwaliteit niet in iets inspecteren - je moet kwaliteit vooraf in je ontwerp inbouwen, en datamodellering is een manier om die kwaliteit in het ontwerp op een efficiënte en kosteneffectieve manier in te bouwen . En nogmaals, iets om te onthouden - en dit is niet zo simpel, maar het is de waarheid - applicaties komen en gaan, data is het essentiële bedrijfsmiddel en het overstijgt al die applicatiegrenzen. Elke keer dat u een applicatie aanbrengt, wordt u waarschijnlijk gevraagd om de gegevens van andere applicaties die eerder beschikbaar waren te bewaren, dus we moeten alleen onthouden dat het een vitaal bedrijfsmiddel is dat we in de loop van de tijd blijven behouden.

En dat is het! Vanaf hier zullen we meer vragen beantwoorden.

Eric Kavanagh: Oké, goed, ik zal het eerst aan Robin overgeven. En dan, Dez, weet ik zeker dat je een paar vragen hebt. Haal het weg, Robin.

Dr. Robin Bloor: Oké. Om eerlijk te zijn, heb ik nog nooit een probleem gehad met agile ontwikkelmethoden en het lijkt me wat je hier doet bij uitstek logisch. Ik herinner me dat ik in de jaren tachtig naar iets keek dat echt aangaf dat het probleem dat je eigenlijk tegenkomt in termen van een project dat uit de hand loopt, normaal is als je een fout voorbij een bepaald stadium laat blijven bestaan. Het wordt alleen maar moeilijker om op te lossen als je die fase niet goed krijgt, dus een van de dingen die je hier doet - en ik denk dat dit de dia is - maar een van de dingen die je hier doet in sprint nul, naar mijn mening, is absoluut belangrijk omdat je echt probeert om de deliverables daar vast te zetten. En als u geen deliverables vastzet, veranderen de deliverables van vorm.

Dat is eigenlijk mijn mening. Het is ook mijn mening - ik heb echt geen enkel argument met het idee dat je de gegevensmodellering tot op een bepaald detailniveau moet krijgen voordat je doorgaat. Wat ik graag zou willen dat je probeert te doen omdat ik er geen volledig idee van heb gekregen, is gewoon een van deze projecten beschrijven in termen van de omvang ervan, in termen van hoe het stroomde, in termen van wie, weet je, waar de problemen opdoken, werden ze opgelost? Omdat ik denk dat deze dia zo'n beetje de kern ervan is en als je daar wat meer over kunt vertellen, zou ik je erg dankbaar zijn.

Ron Huizenga: Natuurlijk, en ik zal een paar voorbeeldprojecten gebruiken. Degene die min of meer uit de rails liep en werd teruggebracht door de juiste mensen erbij te betrekken en de gegevensmodellering te doen en alles was echt een manier om ervoor te zorgen dat het ontwerp beter werd begrepen en we duidelijk een beter implementatieontwerp hadden onderweg door het te modelleren. Omdat wanneer u het modelleert, weet u, u uw DDL en alles uit de rug en uit de tool kunt genereren in plaats van dit te moeten bouwen zoals mensen normaal gesproken doen door rechtstreeks in een databaseomgeving te gaan. En typische dingen die met ontwikkelaars zullen gebeuren, zijn dat ze daar naar binnen gaan en ze zullen zeggen, oké, ik heb deze tabellen nodig. Laten we zeggen dat we orderinvoer doen. Dus ze kunnen de orderkop en de orderdetailtabellen en dat soort dingen maken. Maar ze zullen het vaak vergeten of verwaarlozen om ervoor te zorgen dat de beperkingen aanwezig zijn om de buitenlandse sleutelrelaties weer te geven. Ze hebben misschien niet de juiste sleutels. De naamgevingsconventies kunnen ook verdacht zijn. Ik weet niet hoe vaak ik in een omgeving ben gegaan, bijvoorbeeld, waar je een heleboel verschillende tabellen met verschillende namen ziet, maar dan zijn de kolomnamen in die tabellen zoals ID, Naam of wat dan ook, dus ze heb echt de context verloren zonder de tabel van wat dat precies is.

Dus meestal zorgen we bij het modelleren van gegevens ervoor dat we de juiste naamgevingsconventies toepassen op alle artefacten die ook in de DDL worden gegenereerd. Maar om specifieker te zijn over de aard van de projecten zelf, heb ik over het algemeen over vrij grote initiatieven. Een daarvan was een $ 150 miljoen zakelijk transformatieproject waarbij we meer dan een dozijn oudere systemen hebben vervangen. We hadden vijf verschillende agile teams tegelijkertijd aan de gang. Ik had een volledig team voor gegevensarchitectuur, dus ik had datamodelers van mijn team ingebed in alle andere toepassingsgebiedteams en we werkten samen met een combinatie van interne bedrijfsexperts die het onderwerp wisten, die de gebruikersverhalen voor de vereisten zelf. We hadden bedrijfsanalisten in elk van die teams die het bedrijfsproces aan het modelleren waren, met de activiteitsdiagrammen of bedrijfsprocesdiagrammen, om de gebruikersverhalen meer uit te werken met de gebruikers voordat ze ook door de rest van het team werden geconsumeerd.

En dan natuurlijk de ontwikkelaars die de applicatiecode daar bovenop bouwden. En we werkten ook mee, ik denk dat het vier verschillende leveranciers van systeemintegratie waren die verschillende delen van de applicatie bouwden en waar het ene team de datadiensten bouwde, het andere was het bouwen van applicatielogica op één gebied, een ander met expertise in een ander bedrijfsgebied was het bouwen van de applicatielogica in dat gebied. We hadden dus een hele samenwerking van mensen die aan dit project werkten. Met name op die ene hadden we 150 mensen aan wal in het team en nog eens 150 offshore-middelen in het team die twee weken durende sprints werkten om dit ding te verdrijven. En om dat te doen, moet je ervoor zorgen dat je op alle cilinders vuurt, en iedereen is goed gesynchroniseerd in termen van wat hun deliverables zijn, en je hebt die frequente resets gehad om ervoor te zorgen dat we onze leveringen van alle benodigde artefacten voltooiden aan het einde van elke sprint.

Dr. Robin Bloor: Nou dat is indrukwekkend. En slechts voor een beetje meer informatie daarover, heb je aan het eind van dat project een complete, wat ik zou noemen, MDM-kaart van het hele gegevensgebied?

Ron Huizenga: We hadden een compleet datamodel dat werd opgesplitst in de ontbinding tussen alle verschillende bedrijfsonderdelen. Het gegevenswoordenboek zelf in termen van volledige definities viel een beetje kort. We hadden de meeste tabellen gedefinieerd; we hadden de meeste kolommen gedefinieerd met betrekking tot wat ze precies bedoelden. Er waren er enkele die er niet waren en, interessant genoeg, veel daarvan waren stukjes informatie die afkomstig waren van de oude systemen waar, na het einde van de projectscope zelf, nog steeds werd gedocumenteerd als een reeks artefacten als het ware buiten het project zelf, omdat het iets was dat de organisatie in de toekomst moest ondersteunen. Dus tegelijkertijd nam de organisatie een veel groter standpunt in over het belang van gegevensbeheer, omdat we veel tekortkomingen zagen in die oude systemen en die oude gegevensbronnen die we probeerden te gebruiken omdat ze niet waren gedocumenteerd. In veel gevallen hadden we alleen databases die we moesten reverse engineeren en proberen te achterhalen wat er was en waar de informatie voor was.

Dr. Robin Bloor: Het verbaast me niet, dat specifieke aspect ervan. Data governance is, laten we het noemen, een zeer moderne zorg en ik denk dat er echt veel werk is dat, laten we zeggen, historisch had moeten worden gedaan aan data governance. Het was nooit omdat je er zo maar mee weg kon komen als je het niet deed. Maar terwijl de gegevensbron groeide en groeide, kon je dat uiteindelijk niet.

Hoe dan ook, ik zal overgaan naar Dez omdat ik denk dat ik mijn toegewezen tijd heb gehad. Dez?

Dez Blanchfield: Ja, bedankt. Door dit hele ding kijk en denk ik bij mezelf dat we het hebben over het zien van agile die op veel manieren in woede wordt gebruikt. Hoewel dat negatieve connotaties heeft; Ik bedoelde dat op een positieve manier. Zou je ons misschien een scenario kunnen geven van, ik bedoel, er zijn twee plaatsen waar ik zie dat dit een perfecte set is: een zijn nieuwe projecten die gewoon vanaf de eerste dag moeten worden gedaan, maar ik denk altijd dat het in mijn ervaring vaak het geval dat wanneer projecten groot genoeg worden dat dit op veel manieren nodig is, er een interessante uitdaging is tussen het lijmen van de twee werelden, toch? Kun je ons enig soort inzicht geven in enkele succesverhalen die je hebt gezien waar je een organisatie bent binnengegaan, het is duidelijk geworden dat ze een lichte botsing hebben tussen de twee werelden en je bent erin geslaagd om dit op zijn plaats en brengen grote projecten samen waar ze anders op de rails zouden zijn gegaan? Ik weet dat het een zeer brede vraag is, maar ik vraag me alleen af ​​of er een specifieke case study is die je kunt wijzen naar waar je zei, weet je, we hebben dit allemaal op zijn plaats en het heeft het hele ontwikkelteam samengebracht met het datateam en we hebben iets aangepakt dat anders de boot zou hebben doen zinken?

Ron Huizenga: Tuurlijk, en in feite was het enige project dat toevallig een pijplijnproject was het project waar ik op heb gewezen waar ik die grafiek liet zien met de defecten voordat en nadat de gegevensmodelbouwer was betrokken. Heel vaak, en er zijn vooropgezette ideeën, vooral als dingen worden verzonnen waar het wordt gedaan vanuit een puur ontwikkelingsperspectief van, het zijn gewoon ontwikkelaars die betrokken zijn bij deze flexibele projecten om de applicaties te leveren. Dus wat daar gebeurde, is natuurlijk dat ze van de rails zijn geraakt en met name hun data-artefacten, of de data-deliverables die ze produceerden, tekortschoten in termen van kwaliteit en echt dingen in het algemeen aanpakken. En er is vaak een misvatting dat datamodelers projecten zullen vertragen, en dat zullen ze doen als de datamodeler niet de juiste houding heeft. Zoals ik al zei, je moet de - soms zijn er datamodelers die die traditionele poortwachter-houding hebben waarbij: "We zijn hier om te bepalen hoe de datastructuren eruit zien", en die mentaliteit moet verdwijnen. Iedereen die betrokken is bij agile ontwikkeling, en met name de datamodelers, moet een rol spelen als facilitator om de teams echt vooruit te helpen. En de beste manier om dat te illustreren, is om teams heel snel te laten zien hoe productief ze kunnen zijn door eerst de wijzigingen te modelleren. En nogmaals, daarom heb ik het over de samenwerking gehad.

Er zijn enkele dingen die we eerst kunnen modelleren en de DDL kunnen genereren om naar de ontwikkelaars te duwen. We willen er ook voor zorgen dat ze niet het gevoel hebben dat ze worden beperkt. Dus, als er dingen zijn waar ze aan werken, laat ze dan blijven werken in hun ontwikkelingssandboxen, want daar werken ontwikkelaars aan hun eigen desktops of andere databases om enkele wijzigingen aan te brengen waar ze dingen uittesten. En werk met hen samen en zeg: "Oké, werk ermee." We zullen het in de tool opnemen, we zullen het oplossen en dan zullen we het naar voren schuiven en u de scripts geven die u kunt inzetten om uw databases om ze te upgraden naar wat de werkelijke gesanctioneerde echte productieweergave van het zal zijn als we verder gaan. En dat kun je heel snel omdraaien. Ik merkte dat mijn dagen vol waren waarin ik net heen en weer ging met verschillende ontwikkelingsteams, naar veranderingen keek, vergelijkingen maakte, scripts genereerde, ze op gang bracht, en ik was in staat mezelf vrij gemakkelijk bij te houden met vier ontwikkelingsteams zodra we bereikte een momentum.

Dez Blanchfield: Een van de dingen die in me opkomt, is dat, weet je, veel van de gesprekken die ik dagelijks heb over deze goederentrein die op ons afkomt van, een soort van -machine en IoT. En als we denken dat we nu veel gegevens hebben over onze huidige bedrijfsomgevingen, weet je, als we de eenhoorns even apart houden waar we weten dat de Googles en de Facebooks en de Ubers petabytes aan gegevens hebben, maar in een traditionele onderneming hebben we het nog steeds over honderden terabytes en veel gegevens. Maar er komt naar mijn mening deze goederentrein naar organisaties, en Dr. Robin Bloor heeft er eerder op gewezen, van het IoT. Weet je, we hebben veel webverkeer, we hebben sociaal verkeer, we hebben nu mobiliteit en mobiele apparaten, de cloud is een beetje ontploft, maar nu hebben we slimme infrastructuur, slimme steden en er is een hele wereld van data die net is ontploft.

Voor een alledaagse organisatie, een middelgrote tot grote organisatie die daar zit en deze wereld van pijn naar zich toe ziet komen en geen onmiddellijk plan in gedachten heeft, wat zijn de afhaalmaaltijden, in slechts een paar zinnen, die je zou zeggen voor hen wanneer en waar ze moeten beginnen om in gesprek te gaan over het toepassen van enkele van deze methoden. Hoe vroeg moeten ze beginnen met plannen om bijna rechtop te gaan zitten en op te letten en te zeggen dat dit het juiste moment is om wat hulpmiddelen op hun plaats te krijgen en het team getraind te krijgen en een gesprek te voeren over vocab die deze uitdaging aangaat? Hoe laat in het verhaal is te laat of wanneer is het te vroeg? Hoe ziet dat eruit voor sommige organisaties die je ziet?

Ron Huizenga: Ik zou voor de meeste organisaties zeggen dat als ze het nog niet hebben gedaan en de datamodellering en -architectuur hebben aangepast met krachtige tools zoals deze, het gisteren moet zijn. Omdat het interessant is dat, zelfs vandaag, wanneer je naar gegevens in organisaties kijkt, we zoveel gegevens in onze organisaties hebben en over het algemeen, op basis van enkele onderzoeken die we hebben gezien, we minder dan vijf procent van die gegevens effectief gebruiken wanneer we over organisaties kijken. En met het IoT of zelfs NoSQL, big data - zelfs als het niet alleen IoT is, maar gewoon big data in het algemeen - waar we nu zelfs nog meer informatie beginnen te gebruiken die van buiten onze organisaties afkomstig is, wordt die uitdaging steeds groter altijd. En de enige manier waarop we een kans hebben om dat aan te pakken, is ons te helpen begrijpen waar die gegevens over gaan.

De use case is dus een beetje anders. Wat we doen, is wanneer we naar die gegevens kijken, we deze vastleggen, we moeten het reverse-engineeren, kijken wat erin zit, of het nu in onze gegevensmeren is of zelfs in onze interne databases, synthetiseren wat de gegevens is, er betekenissen op toepassen en definities erop zodat we kunnen begrijpen wat de gegevens zijn. Omdat totdat we begrijpen wat het is, we niet kunnen garanderen dat we het correct of adequaat gebruiken. We moeten dus echt grip krijgen op wat die gegevens zijn. En het andere deel is, doe het niet omdat je, wat betreft het verbruik van al deze externe gegevens, ervoor kunt zorgen dat je een use case hebt die het gebruik van deze externe gegevens ondersteunt. Concentreer u op de dingen die u nodig hebt in plaats van te proberen dingen te trekken en te gebruiken die u later misschien nodig heeft. Concentreer je eerst op de belangrijke dingen en terwijl je je er doorheen baant, ga je de andere informatie van buitenaf consumeren en proberen te begrijpen.

Een perfect voorbeeld daarvan is, ik weet dat we het hebben over IoT en sensoren, maar hetzelfde type probleem is eigenlijk al vele jaren in vele organisaties, zelfs vóór IoT. Iedereen die een productiecontrolesysteem heeft, of het nu een pijplijnbedrijf is, productiebedrijven, procesgebaseerde bedrijven die dingen hebben waarbij ze veel automatisering met controles uitvoeren en datastromen en dergelijke gebruiken, hebben deze firehoses van gegevens waar ze uit proberen te drinken, wat zijn de gebeurtenissen die hebben plaatsgevonden in mijn productie-apparatuur om aan te geven - wat is er gebeurd en wanneer? En onder deze enorme stroom gegevens bevinden zich alleen specifieke stukjes informatie of tags waarin ze geïnteresseerd zijn die ze moeten uitzoeken, synthetiseren, modelleren en begrijpen. En ze kunnen de rest negeren totdat het tijd is om het echt te begrijpen, en dan kunnen ze hun reikwijdte uitbreiden om meer en meer daarvan in reikwijdte te brengen, als dat logisch is.

Dez Blanchfield: Dat doet het inderdaad. Er is een vraag die ik ga beantwoorden die van een heer, Eric, kwam, en we hebben er privé over gepraat. Ik heb zojuist zijn toestemming gevraagd, die hij heeft gekregen, om het van je te vragen. Omdat het hier aardig toe leidt, om het af te ronden, want we gaan nu een beetje in de tijd en ik geef het terug aan Eric. Maar de vraag van een andere Eric was, is het redelijk om aan te nemen dat eigenaars van een startup bekend zijn met de unieke uitdagingen rond modelleringsterminologie en deze begrijpen en dus, of moeten ze voor interpretatie aan iemand anders worden overhandigd? Dus met andere woorden, moet een start-up capabel en klaar en bereid en in staat zijn om zich hierop te concentreren en te leveren? Of is het iets dat ze waarschijnlijk moeten kopen en experts aan boord moeten nemen?

Ron Huizenga: Ik denk dat het korte antwoord is dat het er echt van afhangt. Als het een startup is die niet iemand in huis heeft die een data-architect of modeler is die de database echt begrijpt, dan is de snelste manier om te beginnen iemand met een consultingachtergrond te brengen die zeer goed thuis is in deze ruimte en ze gaan. Omdat wat je zult vinden - en in feite heb ik dit gedaan op veel opdrachten die ik deed voordat ik aan de donkere kant kwam in productbeheer - is dat ik organisaties zou ingaan als consultant, hun data-architectuurteams zou leiden, zodat ze zichzelf een beetje kunnen heroriënteren en hun mensen kunnen trainen in het doen van dit soort dingen, zodat ze het volhouden en de missie voortzetten. En dan zou ik doorgaan naar mijn volgende verloving, als dat logisch is. Er zijn veel mensen die dat doen, die een zeer goede data-ervaring hebben die hen op weg kan helpen.

Dez Blanchfield: Dat is een geweldig afhaalpunt en ik ben het er helemaal mee eens en ik weet zeker dat Dr. Robin Bloor dat ook zou doen. Met name in een start-up bent u gericht op het MKB zijn op de specifieke waarde van propositie die u wilt bouwen als onderdeel van uw start-upbedrijf zelf en u zou waarschijnlijk geen expert op alles moeten zijn, dus geweldig advies. Maar heel erg bedankt, een fantastische presentatie. Echt geweldige antwoorden en vragen. Eric, ik ga je teruggeven omdat ik weet dat we waarschijnlijk tien minuten over tijd zijn gegaan en ik weet dat je graag dicht bij onze tijdvensters blijft.

Eric Kavanagh: Dat is goed. We hebben minstens een paar goede vragen. Laat me er een aan je overgeven. Ik denk dat je een paar van de anderen hebt beantwoord. Maar een zeer interessante observatie en vraag van een deelnemer die schrijft, soms behendige projecten hebben de datamodeler niet het hele lange-termijnbeeld en dus eindigen ze iets in sprint één en moeten ze vervolgens opnieuw ontwerpen in sprint drie of vier. Lijkt dit niet contraproductief? Hoe kun je dat soort dingen vermijden?

Ron Huizenga: Het is gewoon de aard van behendig dat je niet alles helemaal goed krijgt in een bepaalde sprint. En dat is eigenlijk een onderdeel van de geest van agile, is: werk ermee - je gaat prototyping doen waar je in een bepaalde sprint aan code werkt, en je gaat het verfijnen. En een deel van dat proces is als je dingen levert die de eindgebruiker het ziet en zegt: "Ja, dat is dichtbij, maar ik moet het ook net dat beetje extra doen." Dus dat heeft niet alleen invloed op het functionele ontwerp van de code zelf, maar vaak moeten we meer gegevensstructuur onder deze bepaalde dingen aanpassen of toevoegen om te leveren wat de gebruiker wil. En dat is allemaal eerlijk spel en daarom wil je echt de krachtige tools gebruiken, omdat je heel snel die verandering kunt modelleren en in een modelleringstool kunt aanbrengen en vervolgens de DDL voor de database kunt genereren waar de ontwikkelaars vervolgens tegen kunnen werken om dat te leveren nog sneller veranderen. U bespaart hen dat ze als het ware die handcodering van de datastructuren moeten doen en ze zich moeten laten concentreren op de programmeer- of applicatielogica waar ze het meest in zijn.

Eric Kavanagh: Dat is volkomen logisch. We hadden een paar andere mensen die alleen maar specifieke vragen stelden over hoe dit allemaal verband houdt met de tool. Ik weet dat je wat tijd hebt besteed aan het doornemen van voorbeelden en dat je enkele screenshots hebt laten zien over hoe je sommige van deze dingen daadwerkelijk uitrolt. In termen van dit hele sprintproces, hoe vaak zie je dat in organisaties spelen versus hoe vaak zie je meer traditionele processen waar dingen gewoon, soort van, meeslepen en meer tijd kosten? Hoe overheersend is de sprintachtige benadering vanuit uw perspectief?

Ron Huizenga: Ik denk dat we het steeds meer zien. Ik weet dat, zou ik zeggen, waarschijnlijk vooral in de laatste 15 jaar, ik veel meer mensen heb aangenomen die erkennen dat ze echt een snellere levering moeten omarmen. Ik heb dus steeds meer organisaties op de agile bandwagon zien springen. Niet noodzakelijk helemaal; ze kunnen beginnen met een paar pilootprojecten om te bewijzen dat het werkt, maar er zijn enkele die nog steeds erg traditioneel zijn en ze blijven bij de watervalmethode. Het goede nieuws is natuurlijk dat de tools in die organisaties ook prima werken voor dat soort methodologieën, maar we hebben het aanpassingsvermogen in de tool zodat degenen die aan boord springen de tools in de toolbox hebben op hun vingertoppen. Dingen zoals vergelijken en samenvoegen, dingen zoals de reverse-engineering-mogelijkheden, zodat ze kunnen zien wat de bestaande gegevensbronnen zijn, zodat ze de incrementele DDL-scripts zeer snel kunnen vergelijken en genereren. En als ze dat beginnen te omarmen en zien dat ze de productiviteit kunnen hebben, neemt hun neiging om behendig te omarmen nog meer toe.

Eric Kavanagh: Nou, dit is geweldig spul, mensen. Ik heb zojuist een link naar de dia's in het chatvenster gepost, dus bekijk dat eens; het is een beetje een beetje daar voor jou. We hebben al deze webcasts voor later bekijken. Deel ze gerust met je vrienden en collega's. En Ron, heel erg bedankt voor je tijd vandaag, je bent altijd aangenaam om in de show te hebben - een echte expert in het veld en het is duidelijk dat je je dingen kent. Dus, dankzij jou en dankzij IDERA en, natuurlijk, aan Dez en onze eigen Robin Bloor.

En daarmee gaan we u vaarwel zeggen, mensen. Nogmaals bedankt voor je tijd en aandacht. We stellen het op prijs dat je 75 minuten blijft hangen, dat is een redelijk goed teken. Goede show jongens, we spreken je de volgende keer. Tot ziens.