Tag væk: Værten Eric Kavanagh diskuterer vigtigheden af datamodellering i smidig udvikling med Robin Bloor, Dez Blanchfield og IDERAs Ron Huizenga.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer. Velkommen tilbage igen. Dens onsdag kl. 4:00 EST. Det betyder, at det er tid for Hot Technologies. Ja bestemt. Mit navn er Eric Kavanagh, jeg vil være din vært.
Til dagens emne er det en oldie men en goodie. Det bliver bedre for hver dag, fordi det udformer vores datastyringsverden, ”Datamodellering i et agilt miljø.” Der er et lysbillede om dit, virkelig, ramte mig på @eric_kavanagh. Vi burde virkelig lægge det på det lysbillede. Jeg bliver nødt til at komme på det.
Så årene varme. Datamodellering har eksisteret for evigt. Det har virkelig været hjertet og sjælen i informationsadministrationsbranchen, designe datamodeller, forsøge at forstå forretningsmodeller og tilpasse dem til dine datamodeller. Thats virkelig hvad du prøver at gøre, ikke?
Datamodel repræsenterer virksomheden på en grundlæggende måde, så hvordan ændrer alle disse nye datakilder spillet? Vi skulle finde ud af det. Skal finde ud af, hvordan du kan holde dig ovenpå tingene på en smidig måde. Og det er selvfølgelig årets ord.
Robin Bloors med os, vores chefanalytiker, Dez Blanchfield, der kalder ind fra Sydney, Australien og Ron Huizenga, Senior Product Manager fra IDERA - mangeårig ven af mig, fremragende højttaler i dette rum, kender hans ting, så vær ikke sky, spørg ham hårde spørgsmål, folk, de svære. Med det vil jeg gøre Robin til præsentanten og tage den væk.
Dr. Robin Bloor: Okay. Nå tak for det, Eric. Jeg må sige om modellering, som jeg tror, jeg var faktisk i en verden af IT, før den eksisterede, i den forstand, at jeg husker i det forsikringsselskab, som jeg arbejdede for, at vi havde en fyr der kom ind og gav os alle en slags af workshop om, hvordan man modellerer data. Så kiggede vi på omkring 30 år, er det 30 år? Måske endda længere end måske for 35 år siden. En lang, lang tid modellering har faktisk været en del af branchen, og det har naturligvis intet at gøre med damer på catwalks.
Den ting, som jeg ønskede at sige, fordi hvad vi normalt gør, er mig og Dez, der taler om forskellige ting, og jeg tænkte bare, at Id gav det generelle overblik til modellering, men der er en realitet til dette, det bliver nu synligt.
Vi har, du ved, big data-virkeligheden, vi har flere data, flere datakilder, vi har datastrømme, der er gået ind i ligningen i de sidste tre eller fire år og begynder at få en større del af det, og der er et større behov for at forstå dataene og en stigning i ændringshastigheden, der er flere data, der tilføjes, og også flere datastrukturer, der bruges.
Det er en vanskelig verden. Her er et billede af det, som faktisk er noget, vi tegnet for omkring tre år siden, men dybest set, når du inkluderer streaming i mixen, og du får denne idé om dataraffinaderi, datahub, datalink eller hvad, ser du, at der er data, der er virkelig i ro, i den forstand, at det ikke bevæger sig meget. Og så er der dataene, streams og youve har alle de transaktionsapplikationer, plus i dag har du fået begivenheder, begivenhedsdataforløb, der forekommer i applikationer og muligvis skal, og i dag med lambda-arkitekturer, som alle taler om, har virkelig indflydelse på bare hele datafeltet.
Og i dag tænker på, at der er et datalag. Datalaget findes på en slags virtuel måde, i den forstand, at et godt stykke af det kunne være i skyen, og det kan være spredt over datacentre, og det kan eksistere på arbejdsstationer. Datalaget er til en vis grad overalt og i den forstand er der processer overalt, der forsøger på en eller anden måde at behandle dataene og flytte dataene omkring. Men det er også en stor ting at vide, hvad det er, når du flytter det.
Hvis vi ser på datamodellering i den mest generelle forstand, har du i bunden af denne slags stack filer og databaser. Du har dataelementer, som har nøgler, elementdefinitioner, aliaser, synonymer, specifikke fysiske formater, og så har vi dette metadatalag.
Det interessante ved metadata er, at metadata udelukkende er, hvordan data får sin betydning. Hvis du faktisk ikke har metadata, kan du i bedste fald gætte betydningen af dataene, men du vil have en frygtelig masse vanskeligheder. Metadata skal være der, men mening har struktur. Jeg vil ikke gå ind i filosofien om mening, men selv i den måde, vi håndterer data på, er der en masse raffinement i menneskelig tanke og menneskeligt sprog, som ikke let udtrykker sig i data. Men selv med hensyn til de data, som vi faktisk behandler i verden, har metadata mening og strukturen af metadataene - et stykke data i forhold til et andet, og hvad det betyder, når de er sammensat, og hvad det betyder, når de kom sammen med andre data kræver, at vi modellerer dem. Det er ikke godt nok at bare registrere metadatatags til ting, du er faktisk nødt til at registrere betydning pr. Strukturer og forholdet mellem strukturer.
Derefter har vi i det øverste lag forretningsdefinitionerne, som normalt er et lag, der forsøger at overføre mening mellem metadata, som er en form for datadefinition, der passer til den måde, hvorpå data er organiseret på computeren og den menneskelige betydning. Så du har forretningsbetingelser, definitioner, forhold, begreber på enhedsniveau, der findes i det lag. Og hvis vi skulle have en usammenhæng mellem disse lag, skal vi have datamodellering. Det er ikke rigtig valgfrit. Jo mere du faktisk kan gøre det med hensyn til at automatisere det, jo bedre. Men fordi det har betydning, er det virkelig vanskeligt at skifte. Det er let nok at fange metadataene inden for en post og være i stand til at hente dem fra en række betydninger, men det fortæller dig ikke strukturen af posterne, eller hvad posterne betyder eller ulemper med posten.
Så det er hvad datamodellering efter min mening handler om. Peg at bemærke: jo mere kompleks datauniverset bliver, jo mere er du nødt til at modellere det. Med andre ord, det var lidt som at tilføje ikke kun flere forekomster af ting til verden, som ville svare til dataposter, men faktisk tilføjede mere mening til verden ved at indsamle data om flere og flere ting. Det bliver en mere og mere kompleks fornemmelse af, at vi er nødt til at forstå.
I teorien er der et dataunivers, og vi har brug for et syn på det. I praksis er de faktiske metadata en del af datauniverset. Så det er ikke en simpel situation. Begyndende modellering er top-down og bottom-up. Du er nødt til at bygge i begge retninger, og årsagen hertil er, at data har betydning for computeren og processen, der er nødt til at behandle dem, men de har mening i sig selv. Så du har brug for en bottom-up mening, som tilfredsstiller den software, der skal få adgang til dataene, og du har brug for den ovenfra og ned-mening, så mennesker kan forstå det. Bygning af metadatamodeller er ikke og kan aldrig være et projekt; det er en løbende aktivitet - skal være en løbende aktivitet i ethvert miljø, de findes. Heldigvis er der en række miljøer, hvor det faktisk ikke er tilfældet, og tingene springer ud af kontrol i overensstemmelse hermed.
Fremover øges modellering med betydning, når teknologien bevæger sig fremad. Det er min mening. Men hvis man ser på IoT, kan vi forstå mobil mere, end vi plejede at skabe nye dimensioner: dimensionen af placering med mobil. Når du kom til IoT, så du på ekstraordinære dataproblemer, som vi faktisk aldrig havde gjort før, og vi er nødt til på en eller anden måde at forstå nøjagtigt, hvad vi har fået, nøjagtigt hvordan vi kan samle det, hvad vi kan gøre med hensyn til at få mening fra aggregering, og selvfølgelig, hvad vi kan gøre med det, når vi har behandlet det.
Jeg tror, det er mig, der har sagt nok. Jeg skal videre til Dez Blanchfield, så skal jeg sige noget helt andet.
Dez Blanchfield: Tak skal du have. Altid en hård handling at følge, men dette er et emne, vi var enige om og snakede om dette kort i preshow-banteren, og hvis du ringede ind tidligt, fangede du sandsynligvis en hel masse gode perler. En af takeaways, og jeg vil ikke stjæle tordenen fra netop denne, men en af takeaways fra vores preshow-skænderi, som jeg vil dele, i tilfælde af at du ikke fandt det, var lige omkring emnet for dataturen , og det slog mig at faktisk skrive det ned og tænke på den rejse dataene tager i en anden sammenhæng omkring generationens levetid - år, måneder, uge, dag, time, minut, sekund - og ulemperne omkring dataene er placeret inden for dette con . Uanset om jeg er en udvikler, der kører kode, eller om jeg er en dataspecialist og jeg tænker på strukturen og formatet og metadataene omkring hvert af elementerne, eller den måde, systemerne og virksomheden interagerer med det.
Det er en interessant lille afhentning bare for at bemærke, men alligevel, lad mig dykke i. Datadesign, især, er en sætning, som jeg bruger til at tale om alle ting data og specifikt udvikling af enten applikationer eller databaseinfrastruktur. Jeg tror, datadesign er et udtryk, der bare fanger det hele godt ud i mit sind. I disse dage når vi taler om data design, vi taler om moderne agile data design, og min opfattelse er, at det ikke var så længe siden, at udviklere og dataeksperter arbejdede alene; de var i deres egne siloer, og designstykker gik fra en silo til en anden. Men jeg er meget af den opfattelse i disse dage, at det ikke kun er tilfældet, der er ændret, men det skal ændres; det er en slags nødvendighed, og det er den applikation - udviklere og alt hvad der kan gøres omkring udvikling, der beskæftiger sig med data, designerne, der udfører de relevante designelementer i skemaer og felter og poster og placering og databasesystemer og infrastrukturer, modellering og hele ledelsen udfordring omkring det. Det er en holdsport nu, og derfor er mit billede af en flok mennesker, der springer ud af et fly, der fungerer som et hold for at spille det visuelt interessante billede af mennesker, der falder gennem himlen.
For det tredje, hvad er der sket med dette? Nå, der er en artikel i 1986 skrevet af et par herrer, hvis navne jeg desperat forsøgte at gøre retfærdighed over for, Hirotaka Takeuchi og Ikujiro Nonaka, jeg synes, det er udtalt, producerede en artikel, som de havde titlen “Moving the Scrum Downfield.” De introducerede denne idé om en metode til at vinde et spil rugby, der går fra denne scrum-aktivitet, hvor alle kommer rundt på ét sted og to hold i det væsentlige låser hoveder i noget, der kaldes et scrum for at prøve at få kontrol over bolden og spille det ned på banen for at komme til forsøgslinjen og røre jorden med bolden og få et punkt, kaldet en trine, og du gentager denne proces, og du får flere point for holdet.
Denne artikel blev offentliggjort i 1986 i Harvard Business Review, og underlig nok fik den faktisk en masse opmærksomhed. Det fik en masse opmærksomhed, fordi det introducerede fantastiske nye koncepter, og her er et skærmbillede af fronten af det. Så de tog dette koncept med skrum ud af spillet rugby, og de bragte det i forretning og især i spillet design og projektlevering, specifikt projektlevering.
Hvad scrum gjorde var at give os en ny metode i sammenligning med dem som PRINCE2 eller PMBOK, som vi tidligere havde brugt i det, vi kalder vandfaldsmetodikken, ved du, gør denne ting og denne ting og denne ting og følg dem i rækkefølge og forbinder alle prikkerne omkring, hvilket afhænger af, hvad du havde, eller gør ikke del to, før du har gjort del 1, fordi det afhang af del 1. Hvad det gav os er en ny metode til at være lidt mere smidig, og det er her udtrykket kommer fra, om hvordan vi leverer ting, og specifikt omkring design og udvikling af græsrods projektlevering.
Nogle af de vigtigste lejere - bare så jeg går videre med det - er omkring de vigtigste lejere på scrum.Det introducerede ideen om at opbygge ustabilitet, at effektivt, hvis man tænker på frygt for kaos, eksisterer verden i en tilstand af kaos, men planeten dannede, hvilket er interessant, så bygningsinstabilitet, evnen til at hoppe rundt lidt og stadig gør tingene til at fungere, selvorganiserende projektteam, overlapper favoriserer gennem meget ansvarlig udvikling, forskellige typer læring og kontrol gennem rejsen til projektleveringen, organisatorisk overførsel af læring. Så hvordan tager vi information fra en del af virksomheden og overfører dem til en anden fra mennesker, der har en idé, men ikke udvikler kode eller ikke udvikler databaser og infrastrukturer, men data til disse mennesker? Og specifikt tidsboksede resultater. Med andre ord, lad os gøre dette i en periode, enten en dag som i 24 timer, eller en uge eller et par uger og se, hvad vi kan gøre, og derefter gå tilbage og se på det.
Og så, hvis du undskylder ordspillet, er dette virkelig et nyt spil i projektlevering og de tre kernekomponenter dertil, som vil give mening, når vi kommer lidt længere her - der er produktet: alle disse mennesker har ideen og har et behov for at få gjort noget, og historien, der omgiver dem. Udviklere, der arbejder i den smidige model for at få deres historier og gennem daglige standups ved hjælp af scrum-metodikken til at diskutere det og forstå, hvad de har brug for at gøre, og så bare gå videre og gøre det. Så folk, vi har hørt om scrum-mestere, der fører tilsyn med hele denne ting og forstår metodikken godt nok til at drive det. Vi har alle set disse billeder, som jeg fik på højre side her af vægge og tavle fyldt med Post-It-noter, og de blev serveret som Kanban-vægge. Hvis du ikke ved, hvem Kanban er, inviterer jeg dig til Google, hvem Mr. Kanban var, og hvorfor det var en ændring i den måde, vi flytter ting fra den ene side til den anden i en væg bogstaveligt, men i et projekt.
På et øjeblik gør scrum-arbejdsgangen dette: det tager en liste over ting, som en organisation ønsker at gøre, køre dem gennem en række ting, vi kalder ss, der er opdelt i 24-timersperioder, månedlange perioder, og vi få denne trinvise række output. Det er en betydelig ændring af den måde, projekter leveres, blev leveret op til det stadie, fordi en del af det flyder som den amerikanske hær, der havde en stor del af at udvikle noget, der hedder PMBOK, som ideen, der ikke tager tanken ind i marken indtil du lægger kugler i tinget, fordi hvis en tank i marken ikke har kugler, er det nytteløst. Så derfor sættes del 1 kugler i tanken, del to sættes tanken i marken. Desværre fik det, der skete med udviklere i udviklingsverdenen, på en eller anden måde et greb om denne smidige metode og løb med den fladt ud, hvis du undskylder ordspillet, i et s.
Det, der skete, er uvægerligt, når vi tænker på smidige, vi normalt tænker på udviklere og ikke databaser og noget at gøre med databasenes verden. Det var et uheldigt resultat, fordi virkeligheden er, at smidig ikke er begrænset til udviklere. Faktisk er udtrykket agile efter min mening ofte forkert udelukkende forbundet med softwareudviklere og ikke databasedesignere og arkitekter. Unødvendigt står de samme udfordringer, som du står over for inden for software- og applikationsudvikling, i alle ting at gøre med design og udvikling og drift og vedligeholdelse og derfor af datainfrastruktur og især databaser. Aktørerne i denne særlige datastøbning inkluderer ligesom dataarkitekter, formere, administratorer, administratorer af databaseinfrastrukturer og de faktiske databaser i sig selv helt igennem til forretnings- og systemanalytikere og arkitekter, folk der sidder og tænker over, hvordan systemerne og forretningsdrift, og hvordan vi er nødt til at strømme data gennem disse.
Det er et emne, som jeg regelmæssigt bringer op, fordi det er en konstant frustration for mig, idet jeg er meget af den opfattelse, at dataspecialister skal - ikke skal - skal være intimt involveret i enhver komponent i projektlevering, virkelig, især udvikling. For at vi ikke kan det, giver vi virkelig ikke os den bedste chance for et godt resultat. Vi er ofte nødt til at cirkulere tilbage og få en anden tanke om disse ting, fordi der findes et scenario, vi kommer til en applikation, der er ved at blive bygget, og vi opdager, at udviklerne ikke altid er dataeksperter. At arbejde med databaser kræver meget specialiserede færdigheder, især omkring data, og bygger en oplevelse. Du bliver ikke bare med det samme en databaseguru eller datavidenekspert natten over; dette er ofte noget, der kommer fra en livstidsoplevelse og bestemt med dem som Dr. Robin Bloor på Code Today, der ganske rig skrev bogen.
I mange tilfælde - og det er uheldigt, men det er en realitet - at der er to dele af denne mønt, dvs. softwareudviklere har deres egen blackout til databasespecialist og bygget de færdigheder, du har brug for i databasedesign modellering, modeludvikling er bare grundlæggende for gurus-konstruktion af, hvordan data kommer ind, og hvordan organisationen af den rejse, den tager, og hvordan de skal eller ikke skal se ud, eller utvivlsomt den indtagne og forståelse for, at de normalt er opnået i native skills, der er indstillet til softwareudviklere. Og nogle af de fælles udfordringer, vi står over for, bare for at sætte det ind i hinanden, inkluderer ligesom bare grundlæggende oprettelse og vedligeholdelse og styring af selve databasedesignet, dokumentation af dataene og databaseinfrastrukturen og derefter genanvendelse af disse dataaktiver, skema design skema generationer, administration og vedligeholdelse af skema og brugen af dem, deling af viden om, hvorfor dette skema er designet på en bestemt måde, og de styrker og svagheder, der følger med det over tid, forårsager dataforandringer over tid, datamodellering og typer af modeller, vi anvender til systemerne og dataene, vi flyder gennem dem. Generering af databasekode, og det foregår på integration og derefter modellerede data omkring dem og derefter hurtigere adgang til at kontrollere sikkerhed omkring dataene, integriteten af dataene flytter vi dataene rundt, mens vi bevarer deres integritet, er der nok metadata omkring det, skal salget se alle posterne i tabellen, eller skulle de kun se adressen, fornavnet, efternavnet, som du holder på i posten? Og så er selvfølgelig den største udfordring af alle, at modellere databaseplatforme, som er en helt anden samtale i sig selv.
Jeg er meget af den opfattelse, at med alt dette i tankerne for at gøre noget af denne nirvana muligt, er det absolut kritisk, at både dataspecialister og udviklere har de passende værktøjer, og at disse værktøjer er i stand til team-fokuseret projektlevering, design, udvikling og løbende driftsvedligeholdelse. Du ved, ting som at samarbejde på tværs af projekter mellem dataeksperter og softwareudviklere, et enkelt sandhedspunkt eller en enkelt kilde til sandhed for alle ting omkring dokumentation af selve databaserne, dataene, skemaerne, hvor posterne kommer fra, ejere af disse poster . Jeg tror i denne dag og alder er det absolut kritisk, vi får denne nirvana af data til at være konge, at de rigtige værktøjer skal være på plads, fordi udfordringen er for stor nu til at vi kan gøre det manuelt, og hvis folk bevæge sig ind og ud af en organisation, er det for let for os at ikke følge den samme proces eller metode, som en person muligvis oprette, der er god og ikke nødvendigvis overføre disse færdigheder og evner fremadrettet.
Med det i tankerne vil jeg gå over til vores gode ven på IDERA og høre om det værktøj, og hvordan det adresserer netop disse ting.
Ron Huizenga: Tak så meget og tak til både Robin og Dez for virkelig at sætte scenen godt, og du vil se lidt overlapning i et par ting, som jeg har talt om. Men de har virkelig lagt et meget solidt fundament for nogle af de koncepter, som jeg vil tale om fra et datamodelleringsperspektiv. Og mange af de ting, som de har sagt, gentager min egen erfaring, da jeg var en konsulent, der arbejdede inden for datamodellering og dataarkitektur sammen med teams - både vandfald i de tidlige dage og udviklede sig til mere moderne produkter med projekter, hvor vi brugte agile metoder til at levere løsninger.
Så det, jeg skal tale om i dag, er baseret på disse oplevelser såvel som et overblik over værktøjerne og nogle af mulighederne i de værktøjer, vi bruger til at hjælpe os på den rejse. Hvad jeg vil dække meget kort, er, jeg vil ikke gå ind i scrum i en masse detaljer; vi havde bare et rigtig godt overblik over, hvad det er. Jeg vil tale om det i form af, hvad er en datamodel, og hvad betyder det virkelig for os? Og hvordan aktiverer vi konceptet med den agile datamodeller i vores organisationer, hvad angår, hvordan engagerer vi datamodellerne, hvad er deltagelse af modellerere og arkitekter i løbet af de s, hvilke typer aktiviteter de skal udøve , og som baggrund herfor, hvad er et par af de vigtige modelleringsværktøjsfunktioner, som vi udnytter til virkelig at hjælpe med at gøre dette job lettere? Derefter skal jeg gå ind i en smule sammenhængende og bare tale lidt om nogle af de forretningsmæssige værdier og fordele ved at have en datamodeller involveret, eller hvordan jeg rent faktisk fortæller historien er, problemerne med ikke at have en datamodeller fuldt ud involveret i projekterne, og jeg vil vise dig, at der er baseret på erfaring og et defektkort over et før og efter billede af et faktisk projekt, som jeg var involveret i for mange år siden. Og så opsummerer vi et par flere punkter og har derefter spørgsmål og svar ud over det.
Meget kort, ER Studio er en meget kraftig suite, der har en masse forskellige komponenter til den. Dataarkitekten, som er, hvor datamodellerne og arkitekterne bruger det meste af deres tid på at udføre deres datamodellering. Der er også andre komponenter, som vi overhovedet ikke vil tale om, f.eks. Forretningsarkitekt, hvor vi udfører processmodellering og softwarearkitekt til nogle af UML-modelleringerne. Så er der depotet, hvor vi tjekker ind, og vi deler modellerne, og vi tillader holdene at samarbejde om dem og udgive dem ud til teamserveren, så flere interessentgrupper, der er engageret i et projekt, faktisk kan se de artefakter, som vi ' skaber ud fra et dataperspektiv såvel som de andre ting, vi laver i selve projektleveringen.
Det, jeg vil fokusere på i dag, vil være et par ting, som vi vil se ud fra Data Architect, og fordi det er virkelig vigtigt, at vi har samarbejdet med depotbaserede aspekter af det. Især når vi begynder at tale om koncepter som forandringsstyring, som er vigtige for ikke kun smidige udviklingsprojekter, men enhver form for udvikling fremover.
Så lad os tale om Agile Data Modeler et øjeblik. Som vi har været slags, henvist til tidligere i præsentationen, er det, at det er bydende nødvendigt, at vi har datamodeller og / eller arkitekter, der er fuldt ud involveret i de smidige udviklingsprocesser. Hvad der historisk er sket er, ja, vi har virkelig tænkt på smidig set fra et udviklingsperspektiv, og der er et par ting, der er sket, der virkelig har fået det til at skabe. En del af det skyldtes bare arten af den måde, selve udviklingen udfoldede. Da den smidige udvikling startede, og vi startede med dette koncept om selvorganiserende teams, hvis du drak Kool-Aid lidt for ren og var på den ekstreme programmeringsside af tingene, var der en meget bogstavelig fortolkning af ting som selvorganiserende teams, som mange mennesker fortolker at betyde, alt hvad vi har brug for er en gruppe udviklere, der kan bygge en hel løsning. Uanset om det betyder at udvikle koden, databaserne eller datastores bag den, og alt blev henvist til udviklerne. Men hvad der sker med det, er at du mister de særlige evner, folk har. Jeg har fundet ud af, at de stærkeste hold er dem, der er sammensat af mennesker med forskellige baggrunde. Såsom en kombination af stærke softwareudviklere, dataarkitekter, datamodeller, forretningsanalytikere og forretningsinteressenter, der alle samarbejder om at få en slutløsning.
Det, jeg også taler om i dag, er, at jeg skal gøre dette i forbindelse med et udviklingsprojekt, hvor vi udvikler en applikation, som åbenlyst også vil have datakomponenten tilknyttet. Vi er dog nødt til at tage et skridt bagud, før vi gør det, fordi vi er nødt til at indse, at der er meget få Greenfield-udviklingsprojekter derude, hvor vi har totalt fokus på oprettelse og forbrug af data, der kun er begrænset inden for selve udviklingsprojektet . Vi er nødt til at tage et skridt bagud og se på det overordnede organisatoriske synspunkt fra et dataperspektiv og et procesperspektiv. For det, vi finder ud af, er de oplysninger, vi bruger, muligvis allerede findes et eller andet sted i organisationerne. Som modellerere og arkitekter bringer vi det frem, så vi ved, hvor vi kan hente den information fra i projekterne selv. Vi kender også de datastrukturer, der er involveret, fordi vi har designmønstre, ligesom udviklere har designmønstre til deres kode. Og vi er også nødt til at tage det overordnede organisatoriske perspektiv. Vi kan ikke bare se på data i den applikation, vi bygger, til. Vi er nødt til at modellere dataene og sørge for, at vi dokumenterer dem, fordi de lever længe ud over selve applikationerne. Disse applikationer kommer og går, men vi skal være i stand til at se på dataene og sikre, at de er robuste og velstrukturerede, ikke kun til anvendelse, men også for beslutninger, der rapporterer aktiviteter, BI-rapportering og integration til andre applikationer, interne og eksternt til vores organisationer. Så vi er nødt til at se på det hele store billede af dataene, og livscyklen for disse data er og forstå rejsen med informationsstykker i hele organisationen fra vugge til grav.
Nu tilbage til de faktiske teams selv, og hvordan vi faktisk har brug for at arbejde, blev vandfaldsmetodikken opfattet som for langsom til at levere resultater. Fordi det som påpeget med tankeksemplet var det et skridt efter det andet, og det tog ofte for lang tid at levere et brugbart slutresultat. Det, vi gør nu, er, at vi er nødt til at have en iterativ arbejdsstil, hvor vi gradvis udvikler komponenter af det og uddyber det gennem tid, hvor vi producerer brugbar kode eller anvendelige artefakter, vil jeg sige, for enhver sags skyld. Det vigtige er samarbejde mellem de tekniske interessenter i teamet og erhvervsinteressenterne, da vi samarbejder for at få disse brugerhistorier ud i en implementerbar vision af kode og de data, der også understøtter denne kode. Og Agile Data Modeler selv finder ofte, at vi ikke har nok modellerere i organisationer, så én datamodeller eller arkitekt kan muligvis samtidig støtte flere teams.
Og det andet aspekt af dette er, selvom vi har flere modeller, skal vi sørge for, at vi har et værktøjssæt, som vi bruger, der tillader samarbejde mellem flere projekter, der er i flyvning på samme tid og deling af dem dataartefakter og check-in og check-out mulighederne. Jeg vil overveje dette meget hurtigt, fordi vi allerede har dækket det i det foregående afsnit. Den virkelige forudsætning for smidig er, at du baserer ting ud fra efterslæb, historier eller krav. Inden for iterationerne samarbejder vi som en gruppe. Typisk er en to-uges eller en måned s, afhængigt af organisationen, meget almindelig. Og også daglige gennemgangs- og standupmøder, så vi eliminerer blokkeere og sørger for, at vi bevæger os alle aspekter fremad uden at blive stoppet på forskellige områder, når vi gennemgår. Og i disse ss ønsker vi at sikre, at vi producerer brugbare leverancer som en del af alle s.
Bare en lidt anderledes overtagelse af dette, ved at udvide det yderligere, er scrum den metode, jeg vil tale mere specifikt om her, og vi har bare dybest set forstærket det forrige billede med et par andre facetter. Der er typisk en produkt backlog, og så er der en backlog. Så vi har en samlet efterspørgsel, som vi i begyndelsen af enhver gentagelse sætter os ned for at sige, ”Hvad skal vi bygge dette op?”, Og det sker i et planlægningsmøde. Derefter opdeler vi de opgaver, der er forbundet med det, og vi udfører i disse en til fire uger med de daglige anmeldelser. Når vi gør, at vi sporer vores fremskridt gennem nedbrændingsdiagrammer og nedbrændte diagrammer for at spore grundlæggende, hvad der er tilbage at opbygge versus hvad vi bygger for at etablere ting som hvad vores udviklingshastighed er, skal vi gøre vores planlægge alle de slags ting. Alle disse uddybes kontinuerligt i løbet af s i stedet for at gå et par måneder ned ad vejen og finde ud af, at du kommer til at komme kort, og at du er nødt til at udvide projektplanen. Og meget vigtigt, som en del af det, hele holdene, der er som anmeldelse i slutningen og som retrospektiv, så inden du starter den næste iteration, gennemgår du, hvad du gjorde, og du leder efter måder, du kan forbedre på næste gang igennem.
Med hensyn til leverancer er dette dybest set et dias, der opsummerer de typiske typer ting, der foregår i ss. Og det er meget udviklingscentrisk, så mange af de ting, vi ser her, såsom funktionel design og brugskasser, udførelse af designkodetest, når vi ser på disse bokse her, og jeg vil ikke gennemgå dem i ethvert detaljeringsniveau er de meget udviklingsorienterede. Og begravet nedenunder er det faktum, at vi også har brug for de dataudleveringer, der går hånd i hånd med dette for at støtte denne indsats. Så hver gang vi ser ting som efterslæb, krav og brugerhistorier, når vi gennemgår, er vi nødt til at se på, hvad er de udviklingsstykker, vi skal gøre, hvad er de analysestykker, vi skal gøre, hvad med data design eller datamodellen, hvad med ting som forretningsordlisterne, så vi kan knytte forretningsbetydning til alle de artefakter, vi producerer? Fordi vi er nødt til at producere disse brugbare leverancer i enhver henseende.
Nogle mennesker vil sige, at vi er nødt til at fremstille brugbar kode i slutningen af alle s. Det er ikke nødvendigvis tilfældet, det er det i et reneste udviklingsperspektiv, men ganske ofte - især i begyndelsen - kan vi have noget i lighed med nulet, hvor vi er koncentreret udelukkende om at stå op, gøre ting som at få vores teststrategier i placere.Et design på højt niveau for at få det i gang, inden vi begynder at udfylde detaljerne og sørge for, at vi har et rent sæt af starthistorier eller krav, inden vi begynder at engagere andre målgrupper og derefter bygge videre som et team, når vi går fremad. Der er altid en lille smule forberedelsestid, så ganske ofte vil vi have et nul eller endda s nul og et. Det kan være lidt af en opstartfase, før vi får fuld flyvning med at levere løsningen.
Lad os tale om datamodeller i dette kort meget kort. Når folk tænker på datamodeller, tænker de ofte på en datamodel som et billede af, hvordan de forskellige informationsstykker binder sammen - det er bare toppen af isbjerget. For fuldt ud at legemliggøre ånden i, hvordan du virkelig vil henvende dig til datamodellering - hvad enten det drejer sig om agil udvikling og andre ting - er du nødt til at indse, at datamodellen, hvis den udføres korrekt, bliver din fulde specifikation for, hvad disse data betyder i organisationen og hvordan det implementeres i back-end-databaser. Når jeg siger databaser, mener jeg ikke kun de relationelle databaser, som vi muligvis bruger, men i dagens arkitekturer, hvor vi har big data eller NoSQL-platforme, som jeg foretrækker at kalde dem. Også de store datalagre, fordi vi muligvis kombinerer en masse forskellige datalagre med hensyn til at forbruge information og bringe dem ind i vores løsninger såvel som hvordan vi vedvarer eller gemmer informationen ud af vores løsninger også.
Vi arbejder muligvis med flere databaser eller datakilder samtidigt i forbindelse med en given applikation. Det, der er meget vigtigt, er, at vi ønsker at være i stand til at have en fuld specifikation, så en logisk specifikation af, hvad dette betyder for, som organisatorisk perspektiv, hvad de fysiske konstruktioner er i form af, hvordan vi rent faktisk definerer dataene, forholdene mellem dem i din databaser, dine referencemæssige integritetsbegrænsninger, kontrolbegrænsninger, alle disse valideringsstykker, som du typisk tænker på. De beskrivende metadata er ekstremt vigtige. Hvordan ved du, hvordan du bruger dataene i dine applikationer? Medmindre du kan definere det og vide, hvad det betyder eller vide, hvor det kom fra for at sikre dig, at du spiser de rigtige data i disse applikationer - skal du sørge for, at vi har korrekte navnekonventioner, fulde definitioner, hvilket betyder en fuld dataark til ikke kun tabellerne, men kolonnerne, der indeholder disse tabeller - og detaljer om implementering af detaljer om, hvordan vi bruger det, fordi vi er nødt til at opbygge denne videnbase, fordi selv når denne applikation er udført, vil denne information blive brugt til andre initiativer, så vi er nødt til at sikre os at vi har alt det, der er dokumenteret til fremtidige implementeringer.
Igen kommer vi ned på ting som datatyper, nøgler, indekser, selve datamodellen indeholder mange forretningsregler, der kommer i spil. Forholdene er ikke kun begrænsninger mellem forskellige tabeller; de hjælper os ofte med at beskrive, hvad de rigtige forretningsregler er for, hvordan disse data opfører sig, og hvordan de fungerer sammen som en sammenhængende enhed. Og selvfølgelig er værdibegrænsninger meget vigtige. Nu er selvfølgelig en af de ting, vi konstant beskæftiger os med, og det bliver mere og mere udbredt, ting som datastyring. Så ud fra et datastyringsperspektiv, er vi også nødt til at se på, hvad vi definerer her? Vi ønsker at definere ting som sikkerhedsklassifikationer. Hvilke typer data har vi at gøre med? Hvad vil blive betragtet som stamdatadministration? Hvad er de transaktionsbutikker, vi opretter? Hvilke referencedata bruger vi i disse applikationer? Vi er nødt til at sikre, at det fanges korrekt i vores modeller. Og også overvejelser om datakvalitet, der er visse oplysninger, der er vigtigere for en organisation end andre.
Jeg har været involveret i projekter, hvor vi erstattede over et dusin legacy-systemer med nye forretningsprocesser og designede nye applikationer og datalagre for at erstatte dem. Vi var nødt til at vide, hvor informationen kom fra. Hvilket af de vigtigste oplysninger fra et forretningsmæssigt perspektiv, hvis du ser på denne specifikke datamodellas, som jeg har her, vil du se, at bundkasserne i disse bestemte enheder, som kun er en lille undergruppe, jeg har faktisk været i stand til at fange forretningsværdien. Uanset om det er højt, medium eller lavt for disse typer ting for disse forskellige konstruktioner i organisationen. Og jeg har også fanget ting som masterdataklasserne, om de er mastertabeller, om de er reference, hvis de var transaktioner. Så vi kan udvide vores metadata i vores modeller til at give os en masse andre egenskaber uden for selve dataene, hvilket virkelig hjalp os med andre initiativer uden for de originale projekter og videreføre dem. Nu, der var meget i et lysbillede, vil jeg gennemgå resten af disse ret hurtigt.
Jeg vil nu tale meget hurtigt om, hvad gør en datamodeller, når vi går igennem disse forskellige ss. Først og fremmest en fuld deltager i planlægningssessionerne, hvor vi tager brugerhistorierne, forpligter os til, hvad vi skal levere i det, og finde ud af, hvordan vi skal strukturere det og levere det. Hvad jeg også gør som datamodeller er jeg ved, at jeg vil arbejde i separate områder med forskellige udviklere eller med forskellige mennesker. Så en af de vigtige egenskaber, som vi kan have, er, når vi laver en datamodel, og vi kan opdele den datamodel i forskellige synspunkter, uanset om du kalder dem emneområder eller undermodeller, er vores terminologi. Så når vi bygger op modellen, viser vi den også i disse forskellige undermodelperspektiver, så de forskellige målgrupper kun ser hvad der er relevant for dem, så de kan koncentrere sig om, hvad de udvikler og fremlægger. Så jeg har måske nogen, der arbejder på en planlægningsdel af en applikation, måske har jeg nogen anden, der arbejder på en ordreindgang, hvor vi gør alle disse ting i en enkelt s, men jeg kan give dem synspunkter gennem disse undermodeller, der kun gælder for det område, de arbejder på. Og så rulles de op til den overordnede model og hele strukturen af undermodeller for at give forskellige publikums synspunkter, hvad de har brug for at se.
Grundlæggende fra et datamodelleringsperspektiv, som vi ønsker at have, er altid at have en baseline, som vi kan gå tilbage til, fordi en af de ting, vi har brug for at være i stand til, er, om det er i slutningen af som eller i slutningen af flere ss, vi ønsker at vide, hvor vi startede og altid har en basislinje for at vide, hvad var deltaet eller forskellen på, hvad vi producerede i et givet s. Vi er også nødt til at sikre os, at vi kan få en hurtig vending. Hvis du kommer ind på det som en datamodeller, men i den traditionelle portvagterrolle med at sige "Nej, nej, du kan ikke gøre det, vi skal gøre alt dette først," vil du blive udelukket fra holdet, når du virkelig har brug for at være en aktiv deltager i alle disse agile udviklingsteams. Det betyder, at nogle ting falder ud af vognen med en given s, og du henter dem i senere ss.
Som et eksempel kan du fokusere på datastrukturer bare for at få udviklingen til at sige, det ordreindgangsstykke, som jeg talte om. På et senere tidspunkt kommer du muligvis tilbage og udfylder dataene som noget af dokumentationen til dataordbogen omkring nogle af de artefakter, du har oprettet. Du vil ikke færdiggøre denne definition alt på én; du vil fortsætte med dine leverancer trinvist, fordi der vil være tidspunkter, hvor du kan udfylde disse oplysninger, der arbejder med forretningsanalytikere, når udviklerne er i gang med at opbygge applikationer og vedholdenheden omkring disse datalagre. Du ønsker at lette og ikke være flaskehalsen. Der er forskellige måder, vi samarbejder med udviklere. For nogle ting har vi designmønstre, så vi er en fuld deltager foran, så vi kan have et designmønster, hvor vi vil sige, at vi vil sætte det i modellen, vi vil skubbe det ud til udviklernes sandkassedatabaser og så kan de begynde at arbejde med det og anmode om ændringer til det.
Der kan være andre områder, som udviklere har arbejdet på, de har noget, de arbejder på, og de prototyper nogle ting, så de prøver nogle ting i deres eget udviklingsmiljø. Vi tager den database, som de har arbejdet med, bringer den ind i vores modelleringsværktøj, sammenligner med de modeller, vi har, og løser og skubber ændringerne tilbage til dem, så de kan refaktorere deres koder, så de følger de rette datastrukturer som vi har brug for. Fordi de muligvis har oprettet nogle ting, som vi allerede havde andre steder, så vi sørger for, at de arbejder med de rigtige datakilder. Vi gentager bare hele vejen igennem dette til vores, så vi får de fulde dataudleveringer, fuld dokumentation og definitionen af alle de datastrukturer, vi producerer.
De mest succesrige agile projekter, som jeg har været involveret i med hensyn til meget gode leverancer er, vi havde en filosofi, modellerer alle ændringer til den fulde fysiske databasespecifikation. I det væsentlige bliver datamodellen de distribuerede databaser, som du arbejder med for noget nyt, som vi opretter, og som har fuld referencer til de andre datalagre, hvis vi spiser fra andre eksterne databaser. Som en del af dette producerer vi trinvise scripts versus at udføre en hel generation hver gang. Og vi bruger vores designmønstre til at give os det hurtige løft med hensyn til at få tingene til at gå i gang med de forskellige udviklingsteams, som vi arbejder med.
Også i aktiviteter er den grundlæggende for sammenligning / fletning, så lad os tage ideen om at modellere hver ændring. Hver gang vi foretager en ændring, hvad vi gerne vil gøre, er at vi ønsker at modellere ændringen, og hvad der er meget vigtigt, hvad der manglede på datamodellering indtil for nylig, faktisk, indtil vi genindfører den, er evnen til at knytte modelleringen opgaver og dine leverancer med brugerhistorier og opgaver, der faktisk får disse ændringer til at forekomme. Vi vil være i stand til at tjekke vores modelændringer, på samme måde som udviklere tjekker deres koder, og henviser til de brugerhistorier, vi har, så vi ved, hvorfor vi foretog ændringer i første omgang, det er noget, vi gør. Når vi gør det, genererer vi vores inkrementelle DDL-scripts og lægger dem, så de kan afhentes med de andre udviklingsleverancer og tjekkes ind i vores build-løsning. Igen kan vi have en model eller arbejde med flere teams. Og som jeg har talt om, stammer nogle ting af datamodelleren, andre ting stammer fra udviklerne, og vi mødes i midten for at komme med det overordnede bedste design og skubbe det frem og sørge for, at det er korrekt designet i vores overordnede datastrukturer. Vi er nødt til at opretholde disciplinen for at sikre, at vi har alle de rigtige konstruktioner i vores datamodel, når vi går fremad, inklusive ting som null og ikke nullværdier, referencebegrænsninger, grundlæggende kontrolbegrænsninger, alle de ting, vi typisk vil tænke på .
Lad os tale om blot et par skærmbilleder af nogle af de værktøjer, der hjælper os med at gøre dette. Det, jeg synes er vigtigt, er at have det samarbejdsopbevaringssted, så hvad vi kan gøre som datamodeller - og dette er et uddrag af en del af en datamodel i baggrunden - er når vi arbejder på ting, vi vil sikre os, at vi kan arbejde med bare de objekter, som vi har brug for for at kunne ændre, foretage ændringer, generere vores DDL-scripts til de ændringer, vi har foretaget, når vi tjekker tingene tilbage i. Så hvad vi kan gøre, er i ER Studio et eksempel, vi kan tjekke objekter eller grupper af objekter at arbejde på, vi behøver ikke at tjekke en hel model eller undermodel, vi kan tjekke bare de ting, der er af interesse for os. Det, vi gerne vil efter, er enten ved check-out eller check-in tid - vi gør det begge veje, fordi forskellige udviklingshold arbejder på forskellige måder. Vi vil sikre os, at vi forbinder det med den brugerhistorie eller -opgave, der driver kravene til dette, og det vil være den samme brugerhistorie eller -opgave, som udviklerne skal udvikle og kontrollere deres kode til.
Så her er et meget hurtigt uddrag af et par skærme fra et af vores ændringsadministrationscentre. Hvad dette gør, vil jeg ikke gennemgå i detaljer her, men hvad du ser er brugerhistorien eller opgaven og indrykket under hver enkelt af dem, du ser de faktiske ændringsposter - vi har oprettet en automatiseret ændringspost, når vi foretager indtjekning og udtjekning, og vi kan også lægge mere beskrivelse af denne ændringspost. Det er forbundet med opgaven, vi kan have flere ændringer pr. Opgave, som du ville forvente. Og når vi går ind på den ændringsrekord, kan vi se på den og endnu vigtigere se, hvad har vi faktisk ændret? For netop denne, den fremhævede historie der, havde jeg en type ændring, der blev foretaget, og da jeg kiggede på selve ændringsposten, har den identificeret de enkelte stykker i modellen, der er ændret. Jeg ændrede et par attributter her, gentilpassede dem, og det medbragte for turen de synspunkter, der skulle ændres, der også var afhængige af dem, så de ville blive genereret i den trinvise DLL. Det er ikke kun modellering på basisobjekterne, men et højdrevet modelleringsværktøj som dette registrerer også ændringerne, der også skal rippes gennem de afhængige objekter i databasen eller datamodellen.
Hvis vi arbejder med udviklere, og vi gør dette i et par forskellige ting, det gør noget i deres sandkasse, og vi ønsker at sammenligne og se, hvor forskellene er, bruger vi sammenlignings- / fletningsfunktioner hvor til højre og til venstre side. Vi kan sige, "Her er vores model på venstre side, her er deres database på højre side, vis mig forskellene." Vi kan derefter vælge og vælge, hvordan vi løser disse forskelle, om vi skubber ting ind i databasen eller hvis der er nogle ting, de har i databasen, som vi bringer tilbage til modellen. Vi kan gå tovejs, så vi kan gå begge retninger samtidigt opdatere både kilde og mål og derefter producere de inkrementelle DDL-scripts for at distribuere disse ændringer til selve databasemiljøet, hvilket er ekstremt vigtigt. Hvad vi også kan gøre, er at vi også kan bruge denne sammenligning og fusioneringskapacitet til enhver tid, hvis vi tager snapshots på vej gennem, kan vi altid sammenligne starten på en s til start eller slutning af en anden s, så vi kan se den fulde trinvise ændring af, hvad der blev gjort i en given udvikling eller over en række ss.
Dette er et meget hurtigt eksempel på et alter script, enhver af jer der har arbejdet med databaser vil have set denne type ting, det er hvad vi kan skubbe ud af koden som et alter script, så vi sørger for at vi beholde tingene her. Hvad jeg trak ud af her, bare for at reducere rod, er hvad vi også gør med disse alter-scripts er vi antager, at der også er data i disse tabeller, så vi vil også generere DML, som vil trække informationen om de midlertidige tabeller og skub det også tilbage i de nye datastrukturer, så vi ser ikke kun på strukturer men også de data, som vi allerede allerede har indeholdt i disse strukturer.
Vi taler meget hurtigt om automatiserede build-systemer, fordi når vi laver et smidigt projekt, arbejder vi ofte med automatiserede build-systemer, hvor vi er nødt til at tjekke de forskellige leverancer sammen for at sikre, at vi ikke bryder vores builds. Hvad det betyder er, at vi synkroniserer leverancer, disse ændringsskripts, som jeg talte om med DDL-scriptet, skal kontrolleres, den tilsvarende applikationskode skal tjekkes på samme tid, og en masse udviklereudvikling nu er selvfølgelig ikke gøres med direkte SQL mod databaserne og den type ting. Vi bruger ofte ofte persistensrammer eller bygger datatjenester. Vi er nødt til at sikre, at ændringerne for disse rammer eller tjenester kontrolleres nøjagtigt på samme tid. De går ind i et automatiseret build-system i nogle organisationer, og hvis builden går i stykker, i en smidig metode, er det alle hænder på dækfiksering, der bygger, før vi går videre, så vi ved, at vi har en fungerende løsning, før vi går videre. Og et af de projekter, som jeg var involveret i, vi tog dette til det ekstreme - hvis bygningen brød, vi faktisk havde knyttet til en række computere i vores område, hvor vi blev sammenkoblet med forretningsbrugere, havde vi røde blinkende lys bare som toppen af politibiler. Og hvis bygningen brød, begyndte de røde blinkende lys at slukke, og vi vidste, det var alle hænderne på dækket: fix bygningen og fortsæt derefter med det, vi gjorde.
Jeg vil tale om andre ting, og dette er en unik evne til ER Studio, det hjælper virkelig, når vi prøver at opbygge disse artefakter som udviklere til disse vedholdenhedsgrænser, vi har et koncept kaldet forretningsdataobjekter, og hvad der tillader os at gør, er, hvis du ser på denne meget forenklede datamodel som et eksempel, giver den os mulighed for at indkapslere enheder eller grupper af enheder, hvor persistensgrænserne er. Hvor vi som datamodeller muligvis kan tænke på noget som en indkøbsordrehoved og ordrejusteringen og andre detaljerede tabeller, der ville binde ind i det på den måde, vi bygger det op, og vores datatjenesterudviklere har brug for at vide, hvordan ting vedvarer til disse forskellige data strukturer. Vores udviklere tænker på ting som indkøbsordren som et objekt generelt, og hvad er deres kontrakt med, hvordan de opretter disse bestemte objekter. Vi kan udsætte den tekniske detalje, så folk, der bygger dataserverne, kan se, hvad der er under det, og vi kan beskytte de andre målgrupper for kompleksiteten, så de bare ser de forskellige objekter på højere niveau, som også fungerer meget godt til kommunikation med erhvervslivet analytikere og forretningsinteressenter, når vi også taler om interaktion mellem forskellige forretningskoncepter.
Det fine ved det også er, at vi konstruktivt udvider og kollapser disse, så vi kan bevare forholdet mellem objekter med højere orden, selvom de stammer fra konstruktioner, der er indeholdt i disse forretningsdataobjekter selv. Nu som modellerer, kom til slutningen af s, i slutningen af s oppakning, jeg har en masse ting, som jeg skal gøre, som jeg kalder min husholdning til de næste s. Hver gang jeg opretter det, jeg kalder den navngivne frigivelse - der giver mig min baseline for det, jeg nu har i slutningen af udgivelsen. Så det betyder, at det er min basislinje fremad, alle disse baselinjer eller navngivne udgivelser, som jeg opretter og gemmer i mit depot, jeg kan bruge til at sammenligne / flette, så jeg altid kan sammenligne med en given ende af s fra andre er meget vigtigt at vide, hvad dine ændringer var for din datamodel på vej gennem dens rejse.
Jeg opretter også et delta DDL-script ved hjælp af sammenligning / fletning igen fra start til slutning af s. Jeg har måske tjekket en hel masse trinvise script, men hvis jeg har brug for det, har jeg nu et script, som jeg kan indsætte til at stå op med andre sandkasser, så jeg kan bare sige, at det er det, vi havde i begyndelsen af det ene, skub det igennem, opbyg en database som en sandkasse til at starte med de næste s, og vi kan også bruge disse ting til at gøre ting som standup QA-tilfælde, og i sidste ende vil vi selvfølgelig skubbe vores ændringer til produktion, så vi har flere ting på gang på samme tid. Igen deltager vi fuldt ud i planlægningen og retrospektiverne, retrospektiverne er virkelig de erfaringer, og det er ekstremt vigtigt, fordi du kan komme i gang meget hurtigt under agile, du har brug for at stoppe og fejre succeserne, som nu. Find ud af, hvad der er galt, gør det bedre næste gang, men fejr også de ting, der gik rigtigt, og bygg videre på dem, mens du fortsætter med at komme videre i næste ss fremover.
Jeg vil nu meget hurtigt tale om forretningsværdi. Der var et projekt, som jeg blev involveret i for mange år siden, der startede som et smidigt projekt, og det var et ekstremt projekt, så det var et rent selvorganiserende team, hvor det bare var udviklere, der gjorde alt. For at gøre en lang historie kort var dette projekt ved at stoppe, og de opdagede, at de brugte flere og flere gange på at sanere og rette de defekter, der blev identificeret, end de pressede på mere funktionalitet, og faktisk, når de kiggede på det baseret på nedbrændte diagrammer skulle de forlænge projektet seks måneder til en enorm pris. Og da vi kiggede på det, var måden at afhjælpe problemet at bruge et ordentligt datamodelleringsværktøj med en dygtig datamodeller, der var involveret i selve projektet.
Hvis du ser på denne lodrette bjælke på netop dette diagram, viser dette kumulative defekter versus kumulative objekter, og jeg taler om dataobjekter eller konstruktioner, der blev oprettet, såsom tabellerne med begrænsningerne og de slags ting, hvis du kiggede på inden datamodelleren blev introduceret, overskred antallet af fejl faktisk og begyndte at opbygge lidt af et hul over det faktiske antal objekter, der blev produceret indtil dette tidspunkt. Efter uge 21, det var da datamodelleren kom ind, refakturerede datamodellen baseret på hvad der var for at løse et antal ting og begyndte derefter modellering som en del af projektgruppen fremover, ændringerne efterhånden som projektet blev skubbet frem . Og du så en meget hurtig vending, at inden for halvanden tid så vi en enorm stigning i antallet af objekter og datakonstruktioner, der blev genereret og konstrueret, fordi vi genererede ud af et datamodelleringsværktøj snarere end et udviklingssticksbygning dem i et miljø, og de var korrekte, fordi de havde den rette referencemæssige integritet og de andre konstruktioner, den skulle have. Mængden af fejl mod disse næsten flatline. Ved at tage den passende handling og sørge for, at datamodelleringen var fuldt ud engageret, blev projektet leveret til tiden med et meget højere kvalitetsniveau, og faktisk ville det slet ikke have leveret, hvis disse trin ikke havde fundet sted. Der er mange agile fiaskoer derude, der er også en masse smidige succeser, hvis du får de rigtige mennesker i de rigtige involverede roller. Jeg er en stor tilhænger af smidig som en operationel disciplin, men du er nødt til at sikre dig, at du har de færdigheder, der er involveret i alle de rigtige grupper, der er involveret som dine projektteams, når du går videre til en smidig type bestræbelser.
For at opsummere skal dataarkitekter og modellerere være involveret i alle udviklingsprojekter; de er virkelig limet, der holder alt sammen, fordi vi som datamodeller og arkitekter forstår, ikke kun datakonstruktionerne i det givne udviklingsprojekt, men også hvor dataene findes i organisationen, og hvor vi kan kilde disse data fra, og også hvordan det vil blive brugt og brugt uden for selve applikationen, som vi arbejder på. Vi forstår de komplekse dataforhold, og det er vigtigt at være i stand til at komme videre og også fra et styringsperspektiv til at kortlægge dokument og forstå, hvordan dit fulde datalandskab ser ud.
Det er som fremstilling; Jeg kom fra en fremstillingsbaggrund. Du kan ikke inspicere kvalitet til noget i slutningen - du er nødt til at indbygge kvalitet i dit design på forhånd og på vej igennem, og datamodellering er en måde at opbygge denne kvalitet ind i designet på en effektiv og omkostningseffektiv måde hele vejen igennem . Og igen, noget at huske - og det er ikke at være trite, men det er sandheden - applikationer kommer og går, data er det vigtige virksomhedsaktiver, og det overskrider alle disse applikationsgrænser. Hver gang du lægger en applikation op, bliver du sandsynligvis bedt om at bevare dataene fra andre applikationer, der kom før, så vi skal bare huske, at det er et vigtigt forretningsaktiv, som vi fortsætter med at opretholde over tid.
Og det er det! Herfra tager vi flere spørgsmål.
Eric Kavanagh: Okay, god, lad mig først smide det over til Robin. Og så, Dez, jeg er sikker på, at du har et par spørgsmål. Tag det væk, Robin.
Dr. Robin Bloor: Okay. For at være ærlig har jeg aldrig haft noget problem med agile udviklingsmetoder, og det ser ud til, hvad du gør her giver en fremtrædende mening. Jeg kan huske, at jeg så på noget i 1980'erne, der indikerede, at det problem, som du rent faktisk løber ind i et projekt, der løber ud af kontrol, normalt er, hvis du lader en fejl fortsætte ud over et bestemt trin. Det bliver bare mere og mere vanskeligt at ordne, hvis du ikke får den fase rigtigt, så en af de ting, du laver her - og jeg tror, dette er diaset - men en af de ting, du laver her i s nul er efter min mening absolut vigtig, fordi du virkelig prøver at få de leverede varer fastgjort der. Og hvis du ikke får fastgjort leverancer, ændrer leverancer form.
Det er slags, min mening. Det er også min mening - jeg har virkelig ikke noget argument med tanken om, at du er nødt til at få datamodelleringen ret til et vist detaljeringsniveau, før du går igennem. Hvad jeg gerne vil have, at du skulle prøve og gøre, fordi jeg ikke fik en fuldstændig fornemmelse af det, er bare at beskrive et af disse projekter med hensyn til dets størrelse, med hensyn til, hvordan det flydede, med hensyn til hvem, du ved, hvor problemerne kom sammen, blev de løst? Fordi jeg synes, at dette lysbillede stort set er hjertet i det, og hvis du kunne uddybe lidt mere om det, ville jeg være meget taknemmelig.
Ron Huizenga: Sikker på, og jeg vil bruge et par eksempler på projekter. Den, der slags gik ud af skinnerne, der blev bragt tilbage ved faktisk at få de rigtige mennesker involveret og udføre datamodelleringen, og alt var virkelig en måde at sikre, at designet blev forstået bedre, og vi havde tydeligvis bedre implementeringsdesign på vej gennem ved at modellere det. For når du modellerer det, ved du det, kan du generere din DDL og alt ud bagfra og ud af værktøjet i stedet for at skulle holde fast ved at bygge dette, som folk typisk kan gøre ved at gå direkte ind i et databasemiljø. Og typiske ting, der vil ske med udviklere, er at de vil gå derinde, og de vil sige, okay, jeg har brug for disse tabeller. Lad os sige, at vi foretager ordreindgange. Så de kan muligvis oprette ordrehovedet og tabellerne med ordredetaljer og disse typer ting. Men de vil ofte glemme eller forsømme at sikre sig, at begrænsningerne er der for at repræsentere de udenlandske nøgleforhold. De har muligvis ikke nøglerne korrekte. Navnekonventionerne kan også være mistænkelige. Jeg ved ikke, hvor mange gange jeg har gået ind i et miljø, for eksempel, hvor du ser en masse forskellige tabeller med forskellige navne, men så er kolonnenavnene i disse tabeller som ID, Navn eller hvad som helst, så de har virkelig mistet ulemperne uden tabellen for nøjagtigt hvad det er.
Så typisk når vi modellerer, vil vi sørge for, at vi anvender rigtige navnekonventioner til alle artefakter, der også genereres i DDL. Men for at være mere specifik om projekternes art er det generelt set, jeg taler om forholdsvis store initiativer. Et af dem var $ 150 millioner forretningstransformation projekt, hvor vi erstattede over et dusin gamle systemer. Vi havde fem forskellige agile hold, der foregik samtidig. Jeg havde et komplet dataarkitekturteam, så jeg havde datamodeller fra mit team indlejret i hvert af de andre applikationsområdet, og vi arbejdede med en kombination af interne forretningseksperter, der vidste emnet, der gjorde det brugerhistorier til selve kravene. Vi havde forretningsanalytikere i hvert af disse teams, der faktisk modellerede forretningsprocessen med aktivitetsdiagrammer eller forretningsprocesdiagrammer, hvilket hjalp med at udpege brugerhistorierne mere med brugerne, før de også blev fortæret af resten af teamet.
Og selvfølgelig udviklerne, der bygger applikationskoden oven på det. Og vi arbejdede også med, jeg tror, det var fire forskellige leverandører af systemintegration, der bygger forskellige dele af applikationen, samt hvor det ene team byggede datatjenesterne, det andet bygger applikationslogik inden for et område, et andet, der havde ekspertise i et andet forretningsområde byggede applikationslogikken i dette område. Så vi havde et helt samarbejde med mennesker, der arbejdede på dette projekt. Især på den ene havde vi 150 mennesker på land på holdet og yderligere 150 ressourcer offshore på teamet, der samarbejdede to ugers ss for at drive denne ting ud. Og for at gøre det skal du sørge for, at du skyder på alle cylindre, og alle er godt synkroniserede med hensyn til, hvad deres leverancer er, og du havde disse hyppige nulstillinger for at sikre, at vi afsluttede vores leverancer af alle de nødvendige artefakter i slutningen af alle s.
Dr. Robin Bloor: Nå, det er imponerende. Og bare for lidt mere detaljeret om det - endte du med en komplet, hvad jeg ville kalde, MDM-kort over hele dataområdet i slutningen af projektet?
Ron Huizenga: Vi havde en komplet datamodel, der blev opdelt med nedbrydningen mellem alle de forskellige forretningsområder. Selve dataordbogen med hensyn til fulde definitioner faldt lidt kort. Vi havde de fleste af tabellerne defineret; vi havde de fleste af kolonnerne defineret som nøjagtigt, hvad de betød. Der var nogle, der ikke var der, og interessant nok, mange af dem var informationsstykker, der kom fra de gamle systemer, hvor det, efter projektets slutning, stadig blev dokumenteret som et fremførende sæt af artefakter som det var uden for selve projektet, fordi det var noget, som organisationen skulle opretholde fremover. Så på samme tid tog organisationen et meget øget synspunkt på vigtigheden af datastyring, fordi vi så mange mangler i disse ældre systemer og de ældre datakilder, som vi forsøgte at forbruge, fordi de ikke var dokumenteret. I mange tilfælde havde vi kun databaser, som vi var nødt til at omvendt konstruere og prøve at finde ud af, hvad der var der, og hvad informationen var til.
Dr. Robin Bloor: Det overrasker mig ikke, det særlige aspekt af det. Datastyring er, lad os kalde det, en meget moderne bekymring, og jeg synes, der er virkelig en masse arbejde, som vi skal sige, skulle have været gjort historisk med datastyring. Det var aldrig fordi du slags kunne slippe af sted med ikke at gøre det. Men da dataressourcen bare voksede og voksede, kunne du i sidste ende ikke gøre det.
Under alle omstændigheder overgår jeg til Dez, fordi jeg tror, jeg har haft min tildelte tid. Dez?
Dez Blanchfield: Ja, tak. Gennem hele denne ting ser jeg og tænker for mig selv, at vi taler om at se agile brugt i vrede på mange måder. Selvom det har negative konnotationer; Det mente jeg på en positiv måde. Kunne du måske bare give os et scenarie med, jeg mener, der er to steder, hvor jeg kan se, at dette er et perfekt sæt: Det ene er nye projekter, der bare skal udføres fra dag ét, men jeg synes altid, efter min erfaring, at det ofte er i tilfælde af, at når projekter bliver store nok til, at dette er nødvendigt på mange måder, er der en interessant udfordring mellem limning af de to verdener, ikke? Kan du give os nogen form for indsigt i nogle succeshistorier, som du har set, hvor du er gået ind i en organisation, er det blevet klart, at de har fået et lille sammenstød mellem de to verdener, og du har været i stand til med succes at sætte dette på plads og bringe store projekter sammen, hvor de ellers måske var gået på skinnerne? Jeg ved, det er et meget bredt spørgsmål, men jeg spekulerer bare på, om der er et bestemt casestudie, du kan, slags, pege på, hvor du sagde, du ved, vi sætter dette på plads, og det bringer alt udviklingsholdet sammen med datateamet, og vi har slags behandlet noget, der ellers måske har sunket båden?
Ron Huizenga: Sikker på, og faktisk var det ene projekt, der tilfældigvis var et rørledningsprojekt, det, som jeg henviste til, hvor jeg viste det diagram med manglerne før og efter datamodelleren var involveret. Ganske ofte, og der er forudfattede forestillinger, især hvis ting er spundet op, hvor det gøres ud fra et rent udviklingsperspektiv, er det bare udviklere, der er involveret i disse smidige projekter til at levere applikationerne. Så hvad der skete der, selvfølgelig, er, at de kom væk fra skinnerne og deres dataartefakter især, eller de data, de leverede, som de producerede, kom ikke under markeringen med hensyn til kvaliteten og virkelig adresserer tingene generelt. Og der er ofte denne misforståelse om, at datamodellerne vil bremse projekter, og det vil de, hvis datamodelleren ikke har den rigtige holdning. Som jeg siger, er du nødt til at miste - nogle gange er der datamodeller, der har den traditionelle portvogner-holdning, hvor "Vi er her for at kontrollere, hvordan datastrukturen ser ud," og den mentalitet skal forsvinde. Enhver, der er involveret i smidig udvikling, og især datamodellerne, skal påtage sig en rolle som facilitator for virkelig at hjælpe holdene med at komme videre. Og den bedste måde at illustrere det på er meget hurtigt at vise hold, hvor produktive de kan være ved først at modellere ændringerne. Og igen, det var derfor, jeg talte om samarbejdet.
Der er nogle ting, som vi først kan modellere og generere DDL for at skubbe ud til udviklerne. Vi vil også sikre dig, at de ikke føler, at de er begrænset. Så hvis der er ting, de arbejder på, så lad dem fortsætte med at arbejde i deres udviklingssandkasser, fordi det er her, udviklere arbejder på deres egne desktops eller andre databaser for at foretage nogle ændringer, hvor de tester tingene ud. Og samarbejd med dem og siger: ”Okay, arbejd med det.” Vi bringer det ind i værktøjet, vi løser det, og så skubber vi det frem og giver dig scripts, som du kan distribuere det til at opdatere dit databaser for at opgradere dem til, hvad den faktiske sanktionerede ægte produktionsvisning af det vil være, når vi fortsætter med at komme videre. Og du kan vende det rundt på en meget hurtig måde. Jeg fandt ud af, at mine dage blev fyldt, hvor jeg bare gik frem og tilbage med at itereere med forskellige udviklingshold, se på ændringer, sammenligne, generere scripts, få dem til at gå, og jeg var i stand til at holde mig med fire udviklingshold temmelig let, når vi opnået et momentum.
Dez Blanchfield: En af de ting, der kommer ud af det, er, at du ved, at mange af de samtaler, jeg holder dagligt, handler om dette godstog, der kommer til os, slags, maskine-til-maskine og tingenes internet. Og hvis vi tror, at vi har en masse data nu om vores nuværende miljøer i virksomheden, ved du det, hvis vi tager enhjørningerne til side et øjeblik, hvor vi ved, at Googles og s og Ubers har petabytes af data, men i en traditionel virksomhed taler vi stadig om hundreder af terabyte og en masse data. Men der er efter min mening dette godstog, der kommer til organisationer, og Dr. Robin Bloor henviste til det tidligere af IoT. Du ved, vi har meget webtrafik, vi har social trafik, vi har nu mobilitet og mobile enheder, skyen har, slags, eksploderet, men nu har vi smart infrastruktur, smarte byer og der er hele denne verden af data, der lige er eksploderet.
For en dagligdags organisation, en mellemstor til stor organisation, der sidder der og ser denne verden af smerte, kommer på dem og ikke har en øjeblikkelig plan for øje, hvad er nogle af takeaways, i bare et par sætninger, som du ville lægge til dem, hvornår og hvor de har brug for at begynde at tænke samtidigt på at få nogle af disse metodologier på plads. Hvor tidligt har de brug for at begynde at planlægge at næsten sidde op og være opmærksomme og sige, at dette er det rigtige tidspunkt til at få nogle værktøjer på plads og få teamet trænet op og få en samtale om vokab, der går rundt om denne udfordring? Hvor sent i historien er for sent, eller hvornår er for tidligt? Hvordan ser det ud for nogle af de organisationer, du ser?
Ron Huizenga: Jeg vil sige for de fleste organisationer, at hvis de ikke allerede har gjort det og tilpasset datamodellering og dataarkitektur med magtfulde værktøjer som dette, er tiden, de har brug for at gøre det, i går. Fordi det er interessant, at selv i dag, når du ser på data i organisationer, har vi så mange data i vores organisationer og generelt set, baseret på nogle undersøgelser, som vi har set, bruger vi mindre end fem procent af disse data effektivt når vi ser på tværs af organisationer. Og med IoT eller endda NoSQL, store data - selvom det ikke kun er IoT, men bare big data i almindelighed - hvor vi nu begynder at forbruge endnu mere information, der stammer fra uden for vores organisationer, bliver denne udfordring større og større hele tiden. Og den eneste måde, vi har en chance for at være i stand til at tackle, er at hjælpe os med at forstå, hvad disse data handler om.
Så brugssagen er lidt anderledes. Hvad vi finder os selv gør, er, når vi ser på disse data, vi fanger dem, vi er nødt til at omvendt konstruere dem, se hvad der er i dem, hvad enten det er i vores datasøer eller endda i vores interne databaser, syntetisere, hvad data er, anvend betydninger på det og definitioner på dem, så vi kan forstå, hvad dataene er. For indtil vi forstår, hvad det er, kan vi ikke sikre, at vi bruger det korrekt eller tilstrækkeligt. Så vi har virkelig brug for at få fat på, hvad disse data er.Og den anden del af dette er, ikke gør det, fordi du med hensyn til forbrug af alle disse eksterne data kan sikre dig, at du har en brugssag, der understøtter forbrug af disse eksterne data. Fokuser på de ting, du har brug for, snarere end bare at prøve at trække og bruge de ting, du muligvis senere har brug for. Fokuser først på de vigtige ting, og når du arbejder dig igennem det, så kommer du til at fortære og forsøge at forstå de andre oplysninger udefra.
Et perfekt eksempel på det er, jeg ved, at vi taler om IoT og sensorer, men den samme type problem har faktisk været i mange organisationer i mange år, allerede før IoT. Alle, der har et produktionsstyringssystem, hvad enten de er et rørledningsfirma, fremstilling, alle procesbaserede virksomheder, der har ting, hvor de laver en masse automatisering med kontroller, og de bruger datastrømme og lignende ting, har disse brandslanger med data, som de prøver at drikke ud for at finde ud af, hvad er begivenhederne, der er sket i mit produktionsudstyr for at signalere - hvad er der sket, og hvornår? Og blandt denne enorme strøm af data er der kun specifikke oplysninger eller tags, som de er interesseret i, at de har brug for at sile ud, syntetisere, model og forstå. Og de kan ignorere resten af det, indtil det er tid til virkelig at forstå det, og så kan de udvide deres rækkevidde til at trække mere og mere af det ind i rækkevidde, hvis det giver mening.
Dez Blanchfield: Det gør det faktisk. Der er et spørgsmål, som jeg vil føre til, der kom fra en herre, der hedder Eric, og vi har snakket om det privat. Jeg har lige bedt om hans tilladelse, som han har givet, til at bede det om dig. Fordi det fører pænt ind i dette, bare for at pakke sammen, fordi vi går lidt efterhånden nu, og jeg vil give tilbage til Eric. Men spørgsmålet fra en anden Eric var, er det rimeligt at antage, at ejere af en startup er bekendt med og forstår de unikke udfordringer omkring modelleringsterminologi, eller så, eller skal det overleveres til en anden til fortolkning? Så skal med andre ord en opstart være i stand til og klar og villig og i stand til at fokusere på og levere på dette? Eller er det noget, de sandsynligvis burde shoppe ud og bringe eksperter med om bord med?
Ron Huizenga: Jeg antager, at det korte svar er, at det virkelig afhænger. Hvis det er en opstart, der ikke har nogen internt, der er en dataarkitekt eller -modeler, der virkelig forstår databasen, så er den hurtigste måde at starte med at bringe nogen med en konsulentbaggrund, der er meget velbevandret i dette rum og kan få dem går. Fordi hvad du finder - og faktisk gjorde jeg dette på en masse engagementer, som jeg gjorde, før jeg kom over til den mørke side inden for produktstyring - er, at jeg ville gå ind i organisationer som konsulent, lede deres dataarkitekturteam, så de kunne, slags, fokusere på sig selv og uddanne deres folk i, hvordan man gør disse typer ting, så de opretholder det og bærer missionen fremad. Og så fortsatte jeg til mit næste engagement, hvis det giver mening. Der er mange mennesker derude, der gør det, der har en meget god dataerfaring, der kan få dem til at gå.
Dez Blanchfield: Det er et fantastisk takeaway-punkt, og jeg er helt enig i det, og jeg er sikker på, at Dr. Robin Bloor også ville gøre det. Især i en opstart er du fokuseret på at være en SMV på den særlige værdi af det forslag, du ønsker at opbygge som en del af din start-up-virksomhed, og du skulle sandsynligvis ikke behøver at være en ekspert på alt, så gode råd. Men tusind tak, en fantastisk præsentation. Virkelig gode svar og spørgsmål. Eric, jeg vil give mig tilbage til dig, fordi jeg ved, at vi sandsynligvis er gået ti minutter over tid, og jeg ved, at du kan lide at holde os tæt på vores tidsvinduer.
Eric Kavanagh: Det er okay. Vi har mindst et par gode spørgsmål. Lad mig smide en til dig. Jeg tror, du har svaret på nogle af de andre. Men en meget interessant observation og spørgsmål fra en deltager, der skriver, sommetider smidige projekter har datamodelleren, der ikke har hele det langsigtede billede, og så de ender med at designe noget i det ene og derefter skulle redesigne i tre eller fire. Virker dette ikke kontraproduktivt? Hvordan kan du undgå den slags ting?
Ron Huizenga: Det er bare arten af smidig, at du ikke vil få alt helt rigtigt i et givet s. Og det er faktisk en del af ånden i smidig, er: arbejde med det - du skal lave prototyper, hvor du arbejder med kode i et givent stykke, og du vil gøre forbedringer til det. Og en del af denne proces er, når du leverer ting, som slutbrugeren ser det og siger: ”Ja, det er tæt på, men jeg har virkelig brug for at få det til at gøre dette lille ekstra også.” Så det påvirker ikke kun det funktionelle design af selve koden, men ofte er vi nødt til at ændre eller tilføje mere datastruktur under disse bestemte ting for at levere, hvad brugeren ønsker. Og det er alt retfærdigt spil, og det er derfor, du virkelig ønsker at bruge de kraftfulde værktøjer, fordi du meget hurtigt kan modellere og foretage den ændring i et modelleringsværktøj og derefter generere DDL til den database, som udviklerne derefter kan arbejde imod for at levere det ændre sig endnu hurtigere. Du sparer dem fra at skulle udføre den håndkodning som sådan af datastrukturer og lade dem koncentrere sig om den programmerings- eller applikationslogik, som de er mest dygtige til.
Eric Kavanagh: Det giver fuld mening. Vi havde et par andre mennesker, der bare stillede specifikke spørgsmål omkring, hvordan det hele binder tilbage til værktøjet. Jeg ved, at du har brugt nogen tid på at gennemgå eksempler, og du har vist nogle skærmbilleder om, hvordan du rent faktisk ruller nogle af disse ting ud. Hvad angår hele denne proces, hvor ofte ser du det i spil i organisationer versus hvor ofte ser du mere traditionelle processer, hvor tingene bare, slags, kaster sammen og tager mere tid? Hvor udbredt er s-stil tilgang fra dit perspektiv?
Ron Huizenga: Jeg tror, vi ser det mere og mere. Jeg ved, at jeg sandsynligvis især i de sidste 15 år har set meget mere af en adopsion af mennesker, der anerkender, at de virkelig har brug for hurtigere levering. Så jeg har set flere og flere organisationer hoppe på den smidige båndvogn. Ikke nødvendigvis helt; de kan starte med et par pilotprojekter for at bevise, at det fungerer, men der er nogle, der stadig er meget traditionelle, og de holder sig med vandfaldsmetoden. Nu er den gode nyhed naturligvis, at værktøjerne fungerer meget fint i disse organisationer også for den type metodologier, men vi har tilpasningsevnen i værktøjet, så de, der springer om bord, har værktøjerne i værktøjskassen på deres fingerspidser. Ting som sammenligning og fletning, ting som omvendt-engineering kapaciteter, så de kan se, hvad de eksisterende datakilder er, så de faktisk kan sammenligne og generere de inkrementelle DDL-scripts meget hurtigt. Og når de begynder at omfavne det og ser, at de kan have produktiviteten, øges deres tilbøjelighed til at omfatte agile endnu mere.
Eric Kavanagh: Dette er gode ting, folkens. Jeg har lige sendt et link til diasene der i chatvinduet, så tjek det ud; det er lidt af en bit derinde for dig. Vi har alle disse webcasts til senere visning. Del dem gjerne med dine venner og kolleger. Og Ron, tusind tak for din tid i dag, du er altid behagelig at have på showet - en rigtig ekspert på området, og det er indlysende, at du kender dine ting. Så tak til dig og tak til IDERA og selvfølgelig til Dez og vores helt egen Robin Bloor.
Og med det vil vi byde dig farvel, folkens. Tak igen for din tid og opmærksomhed. Vi værdsætter, at du holder dig rundt i 75 minutter, det er et ret godt tegn. Gode show fyre, vi taler med dig næste gang. Hej hej.