Av Techopedia Staff, 16. november 2016
Takeaway: Vert Eric Kavanagh diskuterer viktigheten av datamodellering i smidig utvikling med Robin Bloor, Dez Blanchfield og IDERAs Ron Huizenga.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, mine damer og herrer. Velkommen tilbake igjen. Det er onsdag klokken 16:00 EST. Det betyr at det er på tide med Hot Technologies. Ja absolutt. Jeg heter Eric Kavanagh, jeg vil være din vert.
For dagens tema er det en oldie men en goodie. Det blir bedre hver dag fordi det former vår datahåndteringsverden, "Datamodellering i et smidig miljø." Det er et lysbilde om ditt, virkelig, slo meg opp på Twitter @eric_kavanagh. Vi burde virkelig legge den på den lysbilden. Jeg må komme på det.
Så årets hete. Datamodellering har eksistert for alltid. Det har virkelig vært kjernen og sjelen til informasjonshåndteringsvirksomheten, utformet datamodeller, prøvd å forstå forretningsmodeller og justere dem til datamodellene dine. Det er virkelig det du prøver å gjøre, ikke sant?
Datamodell representerer virksomheten på en grunnleggende måte, så hvordan endrer alle disse nye datakildene spillet? Vi kommer til å finne ut om det. Vi skal finne ut hvordan du kan holde deg oppdatert på en smidig måte. Og det er selvfølgelig årets ord.
Robin Bloors med oss, vår sjefanalytiker, Dez Blanchfield som ringer inn fra Sydney, Australia og Ron Huizenga, senior produktsjef fra IDERA - mangeårig venn av meg, utmerket høyttaler på dette stedet, kjenner tingene sine, så ikke vær sjenert, spør ham de vanskelige spørsmålene, folkens, de harde. Med det skal jeg gjøre Robin til programleder, og ta den bort.
Dr. Robin Bloor: OK. Vel takk for det, Eric. Jeg må si om modellering som jeg tror, jeg var faktisk i en verden av IT før den eksisterte, i den forstand at jeg husker i forsikringsselskapet som jeg jobbet for, at vi hadde en fyr som kom inn og ga oss alle en slags av workshop om hvordan man modellerer data. Så vi ser på omtrent 30 år, er det 30 år? Kanskje enda lenger enn det, kanskje for 35 år siden. En lang, lang modellering har faktisk vært en del av bransjen, og det har selvfølgelig ikke noe med damer å gjøre på catwalks.
Det jeg ønsket å si, fordi det vi vanligvis gjør, er at jeg og Dez snakker om forskjellige ting, og jeg trodde bare at jeg skulle gi den generelle oversikten til modellering, men det er en realitet for dette, det blir nå tydelig.
Vi har, du vet, big data-virkeligheten, vi har mer data, flere datakilder, vi har datastrømmer som har kommet inn i ligningen de siste tre eller fire årene og begynner å få en større del av den, og det er et større behov for å forstå dataene og en økning i endringshastigheten som er mer data som blir lagt til og også flere datastrukturer som blir brukt.
Det er en vanskelig verden. Her er et bilde av det, som faktisk er noe vi tegnet for omtrent tre år siden, men i utgangspunktet, når du inkluderer streaming i miksen og du får denne ideen om dataraffinaderi, datahub, datalink eller hva som helst, ser du at det er data som er virkelig i ro, i den forstand at det ikke beveger seg mye. Og så er det data, strømmer og du har alt av transaksjonsapplikasjoner, pluss at i dag har du hendelser, hendelsesdataflyter som skjer i applikasjoner og kanskje trenger, og i dag med lambda-arkitekturene alle snakker om, er virkelig å ha innvirkning på bare hele datafeltet.
Og i dag tenker på at det er et datalag. Datasjiktet eksisterer på en slags virtuell måte, i den forstand at en god del av den kan være i skyen og at den kan spres over datasentre, det kan eksistere på arbeidsstasjoner. Datasjiktet er til en viss grad overalt og i den forstand er det prosesser overalt som forsøker på en eller annen måte å behandle dataene og flytte dataene om. Men å vite hva det er når du flytter det, er en stor sak.
Hvis vi ser på datamodellering i den mest generelle forstand, har du i bunnen av denne typen bunker filer og databaser. Du har dataelementer, som har nøkler, elementdefinisjoner, aliaser, synonymer, spesifikke fysiske formater og så har vi dette metadatasjiktet.
Det interessante med metadata er at metadata helt er hvordan data får sin mening. Hvis du faktisk ikke har metadata, kan du i beste fall gjette betydningen av dataene, men du kommer til å ha forferdelig mange vanskeligheter. Metadata må være der, men mening har struktur. Jeg vil ikke gå inn på filosofien om mening, men selv i måten vi håndterer data på, er det mye raffinement i menneskelig tanke og menneskers språk, som ikke lett uttrykker seg i data. Men selv når det gjelder dataene vi faktisk behandler i verden, har metadata mening og strukturen til metadataene - ett stykke data i forhold til et annet og hva det betyr når de er satt sammen og hva det betyr når de ' har blitt sammen med andre data, krever at vi modellerer dem. Det er ikke bra nok å bare registrere metadatatagger på ting, du må faktisk registrere mening per strukturer og forholdet mellom strukturene.
Så har vi i toppsjiktet, forretningsdefinisjonene, som normalt er et lag som prøver å overføre mening mellom metadata, som er en form for datadefinisjon som rommer måten data er organisert på datamaskinen og menneskelig mening. Så du har forretningsbetingelser, definisjoner, relasjoner, konsepter på enhetens nivå som finnes i det laget. Og hvis vi kommer til å ha en usammenheng mellom disse lagene, må vi ha datamodellering. Det er egentlig ikke valgfritt. Jo mer du faktisk kan gjøre det når det gjelder å automatisere det, jo bedre. Men fordi det har med mening å gjøre, er det virkelig vanskelig å veksle. Det er lett nok å fange metadataene i en post og være i stand til å hente dem fra en rekke betydninger, men det forteller deg ikke strukturen til postene eller hva postene betyr eller konteksten til posten.
Så dette er hva datamodellering, etter min mening, handler om. Poeng å merke seg: jo mer komplekst datauniverset blir, jo mer trenger du å modellere det. Med andre ord, det er litt som om vi ikke bare legger flere tilfeller av ting til verden, noe som tilsvarer dataregister, men vi legger faktisk mer mening til verden ved å fange inn data om flere og flere ting. Det blir en mer og mer sammensatt følelse som vi må forstå.
I teorien er det et dataunivers, og vi trenger et syn på det. I praksis er de faktiske metadataene en del av datauniverset. Så det er ikke en enkel situasjon. Begynnelsen av modellering er ovenfra og ned og opp. Du må bygge i begge retninger, og årsaken til det er at data har betydning for datamaskinen og prosessen, som må behandle det, men det har mening i seg selv. Så du trenger en bottom-up mening, som tilfredsstiller programvaren som trenger tilgang til dataene, og du trenger mening fra ovenfra og ned slik at mennesker kan forstå det. Bygging av metadatamodeller er ikke og kan aldri være et prosjekt; det er en pågående aktivitet - skal være en pågående aktivitet i alle omgivelser de eksisterer. Heldigvis er det mange miljøer, der det faktisk ikke er tilfelle og ting spinner ut av kontroll deretter.
Fremover øker modelleringen med betydning når teknologien går fremover. Det er min mening. Men hvis du ser på IoT, kan vi forstå mobil mer enn vi pleide å gjøre, selv om den har introdusert nye dimensjoner: dimensjonen til beliggenhet med mobil. Når du kommer til IoT, ser vi på ekstraordinære dataproblemer som vi aldri måtte gjøre før, og vi må på en eller annen måte for å forstå nøyaktig hva vi har, nøyaktig hvordan vi kan samle det, hva vi kan gjøre med tanke på å få mening fra aggregering, og selvfølgelig, hva vi kan gjøre med det, når vi har behandlet det.
Jeg tror det er meg som har sagt nok. Jeg skal videre til Dez Blanchfield, som vil si noe annet helt.
Dez Blanchfield: Takk. Alltid en tøff handling å følge, men dette er et tema vi ble enige om og snakket om dette kort i preshowbanteren, og hvis du ringte inn tidlig, ville du sannsynligvis fanget en hel haug med gode perler. En av takeawayene, og jeg vil ikke stjele tordenen for akkurat denne, men en av takeawayene fra vår preshowbanter som jeg vil dele, i tilfelle du ikke ville fange den, var bare rundt temaet datainten, og det slo meg å faktisk skrive det ned og tenke på reisen dataene tar i en annen sammenheng rundt generasjons levetid - år, måneder, uke, dag, time, minutt, sekund - og konteksten rundt dataene er plassert i den sammenhengen. Enten jeg er en utvikler som kjører kode, eller om jeg er en dataspesialist og jeg tenker på strukturen og formatet og metadataene rundt hvert av elementene, eller måten systemene og virksomheten samhandler med det.
Det er en interessant liten takeaway bare å merke seg, men uansett, la meg dykke inn. Spesielt datadesign er en setning som jeg bruker for å snakke om alle data og spesifikt utvikling av enten applikasjoner eller databaseinfrastruktur. Jeg tror datadesign er et begrep som bare fanger opp alt veldig godt i tankene mine. I disse dager når vi snakker om data design, snakker vi om moderne smidig data design, og mitt syn er at det ikke var så lenge siden at utviklere og dataeksperter jobbet alene; de var i sine egne siloer og designstykker gikk fra en silo til en annen. Men jeg er veldig opptatt av i disse dager, at det ikke bare er tilfelle som er endret, men det må endres; det er liksom en nødvendighet, og det er den applikasjonen - utviklere og alt å gjøre rundt utvikling som omhandler data, designerne som gjør de relevante designelementene til skjemaer og felt og poster og lokasjons- og databasesystemer og infrastrukturer, modellering og hele ledelsen utfordring rundt det. Det er en lagsport nå, og derav bildet mitt av en gjeng mennesker som hopper ut av et fly som fungerer som et lag for å spille ut det visuelt interessante bildet av mennesker som faller gjennom himmelen.
For det tredje, hva har skjedd for å få til dette? Vel, det er en artikkel i 1986 skrevet av et par herrer hvis navn jeg prøvde desperat å gjøre rettferdighet mot, Hirotaka Takeuchi og Ikujiro Nonaka, jeg tror det er uttalt, og produserte en artikkel som de hadde tittelen “Moving the Scrum Downfield.” De introduserte denne ideen om en metodikk for å vinne et spill med rugby som går fra denne skrumaktiviteten, der alle kommer seg rundt på ett sted og to lag i hovedsak låser hodene i noe som kalles et skrum for å prøve å få kontroll over ballen og spille den nedover banen komme til prøvelinjen og berøre bakken med ballen og få et poeng, kalt en trine, og du gjentar denne prosessen og du får flere poeng for laget.
Denne artikkelen ble publisert i 1986 i Harvard Business Review, og merkelig nok fikk den faktisk mye oppmerksomhet. Den fikk mye oppmerksomhet fordi den introduserte fantastiske nye konsepter, og her er et skjermbilde av fronten på den. Så de tok dette konseptet med scrum ut av spillrugbyen, og de brakte det til virksomhet, og spesielt innen design og prosjektleveranse, spesielt prosjektlevering.
Det scrum gjorde var å gi oss en ny metodikk sammenlignet med PRINCE2 eller PMBOK som vi tidligere hadde brukt i det vi kalte fossefallmetodikken. Du vet, gjør denne tingen og denne tingen og denne tingen og følg dem i rekkefølge og koble til alle prikkene rundt, som avhenger av hva du hadde, eller ikke gjør del to før du har gjort del en fordi den var avhengig av del en. Det det ga oss er en ny metodikk for å være litt smidigere, og det er her begrepet kommer fra, om hvordan vi leverer ting, og spesielt rundt design og utvikling av grasrot prosjektlevering.
Noen av de viktigste leietakerne - bare slik at jeg går videre med dette - er rundt nøkkelleietakerne på scrum. Det introduserte ideen om å bygge ustabilitet, at effektivt hvis du tenker på frykten for kaos, eksisterer verden i en tilstand av kaos, men planeten dannet seg, noe som er interessant, så å bygge ustabilitet, evnen til å sprette litt rundt og fremdeles faktisk få ting til å fungere, selvorganiserende prosjektgrupper, overlappende tjenester gjennom veldig ansvarlig utvikling, forskjellige typer læring og kontroll gjennom reisen til prosjektleveransen, organisasjonsoverføring av læring. Så hvordan tar vi informasjon fra en del av virksomheten og overfører den til en annen fra folk som har en idé, men ikke utvikler kode eller ikke utvikler databaser og infrastrukturer, men data til disse menneskene? Og spesielt tidsboksede utfall. La oss med andre ord gjøre dette i en periode, enten en dag som om 24 timer, eller en uke eller et par uker og se hva vi kan gjøre, og deretter gå tilbake og se på det.
Og så, hvis du tilgir ordspillet, er dette virkelig et nytt spill i prosjektlevering og de tre kjernekomponentene til det som vil være fornuftig når vi kommer litt lenger her - det er produktet: alle disse menneskene har ideen og har et behov for å få gjort noe og historien som omgir dem. Utviklere som opererer i den smidige modellen for å få historiene sine og gjennom daglig standups ved å bruke skrummetodikken for å diskutere det og forstå hva de trenger å gjøre, og så bare gå videre og gjøre det. Så folk, vi har hørt om scrum-mestere som har tilsyn med hele denne saken og forstår metodikken godt nok til å drive den. Vi har alle sett disse bildene som jeg fikk på høyre side her av vegger og tavler fulle av Post-It-lapper, og de ble servert som Kanban-vegger. Hvis du ikke vet hvem Kanban er, inviterer jeg deg til Google hvem Mr. Kanban var, og hvorfor det var en endring i måten vi flytter ting fra den ene siden til den andre i en vegg bokstavelig talt, men i et prosjekt.
På et øyeblikk gjør scrum-arbeidsflyten dette: den tar en liste over ting som en organisasjon vil gjøre, fører dem gjennom en serie ting vi kaller sprints som er oppdelt i 24-timersperioder, månedslange perioder, og vi få denne trinnvise serien med utganger. Det er en betydelig endring i måten prosjekter blir levert, ble levert opp til det stadiet fordi en del av det flyter som den amerikanske hæren som hadde en stor del av å utvikle noe som heter PMBOK, som ideen som ikke tar tanken inn i feltet til du legger kuler i tingen fordi hvis en tank i feltet ikke har kuler, er den ubrukelig. Så derfor blir del 1 satt kuler i tanken, del to blir tanken satt i feltet. Dessverre fikk det som skjedde med utviklere i utviklingsverdenen på en eller annen måte tak i denne smidige metodikken og løp med den flatt ut, hvis du tilgir ordspillet, på en sprint.
Unødvendigvis er det som skjedde, når vi tenker smidig tenker vi vanligvis på utviklere og ikke databaser og noe med databasens verden å gjøre. Det var et uheldig resultat fordi realiteten er at smidig ikke er begrenset til utviklere. Faktisk er begrepet smidig etter mitt syn ofte feil utelukkende forbundet med programvareutviklere og ikke databasedesignere og arkitekter. Unødvendigvis står de samme utfordringene som du står overfor i programvare- og applikasjonsutvikling i alle ting å gjøre med design og utvikling og drift og vedlikehold og derfor av datainfrastruktur og spesielt databaser. Aktørene i denne spesielle datastegningen inkluderer slike som arkitekter, moldere, administratorer, administratorer av databaseinfrastrukturen og de faktiske databasene selv til forretnings- og systemanalytikere og arkitekter, folk som sitter og tenker på hvordan systemene og forretningsdrift og hvordan vi har fått til å strømme data gjennom disse.
Det er et tema som jeg regelmessig bringer opp fordi det er en konstant frustrasjon av meg fordi jeg er veldig av den oppfatning at dataspesialister må - ikke bør - nå må være intimt involvert i hver komponent i prosjektlevering, virkelig, spesielt utvikling. For at vi ikke skal gjøre det, så gir vi oss ikke den beste sjansen for et godt resultat. Vi må ofte slå tilbake og få en annen tenke på disse tingene fordi det eksisterer et scenario, vi kommer til en applikasjon som bygges og vi oppdager at utviklerne ikke alltid er dataeksperter. Å jobbe med databaser krever veldig spesialiserte ferdigheter, spesielt rundt data, og bygger en opplevelse. Du blir ikke bare en databaseguru eller ekspert på datakunnskaper over natten; dette er ofte noe som kommer fra en livsopplevelse og absolutt med slike som Dr. Robin Bloor på Code Today, som ganske rikt skrev boken.
I mange tilfeller - og det er uheldig, men det er en realitet - at det er to deler av denne mynten, det vil si programvareutviklere har en egen blackout som databasespesialist og bygde de ferdighetene du trenger i databasedesignmodellering, og modellutvikling er bare grunnleggende for gurus 'prosjektering av hvordan data kommer inn og hvordan organiseringen av reisen den tar og hvordan den skal eller ikke skal se ut, eller utvilsomt den inntatte og forståelsen av at de vanligvis har fått i egne ferdigheter som er satt for programvareutviklere. Og noen av de vanlige utfordringene vi står overfor, bare for å sette det i sammenheng, inkluderer slike som bare grunnleggende oppretting og vedlikehold og styring av selve databasedesignet, dokumentere dataene og databasens infrastruktur og deretter gjenbruke disse dataene, skjemautforminger, skjema generasjoner, administrasjon og vedlikehold av skjema og bruk av dem, deling av kunnskapen rundt hvorfor dette skjemaet er designet på en spesiell måte og styrkene og svakhetene som følger med det over tid forårsaker dataendringer over tid, datamodellering og typer av modeller vi bruker på systemene og dataene vi flyter gjennom dem. Generering av databankoder, og det går på integrasjon og deretter modellerte data rundt dem og deretter raskere tilgang til å kontrollere sikkerhet rundt dataene, integriteten til dataene flytter vi dataene rundt når vi beholder sin integritet, er det nok metadata rundt Skal salg se alle postene i tabellen, eller skal de bare se adressen, fornavnet, etternavnet som sender deg ting i innlegget? Og så er selvfølgelig den største utfordringen av alle å modellere databaseplattformer som helt og holdent er en annen samtale i seg selv.
Jeg er veldig opptatt av at med alt dette i tankene for å gjøre noe av denne nirvana mulig, er det helt avgjørende at både dataspesialistene og utviklerne har de riktige verktøyene og at disse verktøyene kan være i stand til teamfokusert prosjektlevering, design, utvikling og løpende driftsvedlikehold. Du vet, ting som å samarbeide på tvers av prosjekter mellom dataeksperter og programvareutviklere, enkelt sannhetspunkt eller en enkel kilde til sannhet for alle ting rundt dokumentasjon av databasene selv, dataene, skjemaene, der postene kommer fra, eiere av disse postene . Jeg tror i dag og alder er det helt kritisk, vi kommer til å få denne nirvanaen til data til å være konge, at de riktige verktøyene må være på plass fordi utfordringen er for stor nå til at vi kan gjøre det manuelt, og hvis folk flytte inn og ut av en organisasjon, er det for lett for oss å ikke følge den samme prosessen eller metodikken som en person kan sette opp som er gode og ikke nødvendigvis overføre disse ferdighetene og evnene fremover.
Med det i tankene skal jeg ta turen til vår gode venn på IDERA og høre om det verktøyet og hvordan det adresserer nettopp disse tingene.
Ron Huizenga: Tusen takk og takk til både Robin og Dez for virkelig å sette scenen godt, og du kommer til å se litt overlapping i et par ting som jeg har snakket om. Men de har virkelig satt et veldig solid grunnlag for noen av konseptene som jeg skal snakke om fra et datamodelleringsperspektiv. Og mange av de tingene som de har sagt, gjenspeiler min egen erfaring da jeg var en konsulent som jobbet innen datamodellering og dataarkitektur, sammen med team - begge fossene i de første dagene og utviklet seg til mer moderne produkter med prosjekter der vi brukte agile metoder for å levere løsninger.
Så det jeg skal snakke om i dag, er basert på disse erfaringene, samt et syn på verktøyene og noen av mulighetene i verktøyene vi bruker for å hjelpe oss på den reisen. Det jeg kommer til å dekke veldig kort, er at jeg ikke skal gå inn på skrum i mange detaljer; vi hadde en veldig god oversikt over hva det er. Jeg skal snakke om det i form av, hva er en datamodell og hva betyr det egentlig for oss? Og hvordan aktiverer vi konseptet med den smidige datamodelleren i organisasjonene våre, med tanke på, hvordan engasjerer vi datamodellerne, hva er deltakelse av modellerere og arkitekter i løpet av sprinten, hva er aktivitetstypene de bør drive med, og som bakgrunn for det, hva er noen av de viktige modelleringsverktøyene vi bruker for å virkelig bidra til å gjøre jobben enklere? Så kommer jeg til å gå inn på litt sammenlegg og bare snakke litt om noen av forretningsverdiene og fordelene ved å ha en datamodeller involvert, eller hvordan jeg faktisk skal fortelle historien er, problemene med å ikke ha en datamodeller fullt ut involvert i prosjektene, og jeg skal vise deg at basert på erfaring og et mangeldiagram over et før og etter bilde av et faktisk prosjekt som jeg var involvert i for mange år siden. Og så vil vi oppsummere noen flere punkter, og deretter ha spørsmål og svar i tillegg til det.
Veldig kort er ER Studio en veldig kraftig suite som har mange forskjellige komponenter til den. Dataarkitekten, det er her datamodellerne og arkitektene bruker mesteparten av tiden sin på å gjøre sin datamodellering. Det er andre komponenter som vi ikke skal snakke om i dag, for eksempel Business Architect, der vi prosessmodellerer og Software Architect, for noen av UML-modelleringene. Så er det depotet, der vi sjekker inn, og vi deler modellene, og vi lar teamene samarbeide om dem og publisere dem ut til teamserveren slik at flere interessentgrupper som er engasjert i et prosjekt, faktisk kan se gjenstandene som vi oppretter fra et dataperspektiv så vel som de andre tingene vi gjør i selve prosjektleveransen.
Det jeg kommer til å fokusere på i dag, kommer til å være noen få ting vi kommer til å se av Data Architect, og fordi det er veldig viktig at vi har samarbeidet med depotbaserte aspekter av det. Spesielt når vi begynner å snakke om konsepter som endringsledelse som er avgjørende for ikke bare smidige utviklingsprosjekter, men alle typer utvikling fremover.
Så la oss snakke om Agile Data Modeler et øyeblikk. Som vi har blitt henvist til tidligere i presentasjonen, er at det er avgjørende at vi har datamodeller og / eller arkitekter som er fullt ut engasjert i de smidige utviklingsprosessene. Det som skjedde historisk er, ja, vi har virkelig tenkt på smidige fra et utviklingsperspektiv, og det er et par ting som har skjedd som virkelig har fått det til å skje. En del av det skyldtes bare arten av utviklingen i seg selv. Da den smidige utviklingen startet og vi startet med dette konseptet med selvorganiserende team, hvis du drakk Kool-Aid litt for rent og du var på den ekstreme programmeringssiden av ting, var det en veldig bokstavelig tolkning av ting som selvorganiserende team, som mange mennesker tolket til å bety, alt vi trenger er en gruppe utviklere som kan bygge en hel løsning. Enten det betyr å utvikle koden, databasene eller datastores bak, og alt ble relegert til utviklerne. Men det som skjer med det, er at du taper på de spesielle evnene folk har. Jeg har funnet ut at de sterkeste lagene er de som er sammensatt av mennesker med forskjellig bakgrunn. For eksempel en kombinasjon av sterke programvareutviklere, dataarkitekter, datamodeller, forretningsanalytikere og forretningsinteressenter, som alle samarbeider for å få en sluttløsning.
Det jeg også snakker om i dag, er at jeg skal gjøre dette i sammenheng med et utviklingsprosjekt der vi utvikler en applikasjon som tydeligvis også kommer til å ha datakomponenten knyttet til den. Vi trenger å ta et skritt bakover før vi gjør det selv, fordi vi må innse at det er veldig få Greenfield-utviklingsprosjekter der ute, hvor vi har et totalt fokus på opprettelse og forbruk av data som bare er begrenset i selve utviklingsprosjektet. . Vi må ta et skritt bakover og se på det overordnede organisatoriske synspunktet fra et dataperspektiv og et prosessperspektiv. Fordi det vi finner ut er informasjonen vi bruker allerede kan finnes et sted i organisasjonene. Som modellerere og arkitekter bringer vi det fram slik at vi vet hvor vi kan få informasjonen fra i prosjektene. Vi kjenner også datastrukturene som er involvert fordi vi har designmønstre akkurat som utviklere har designmønstre for koden deres. Og vi må også ta det overordnede organisatoriske perspektivet. Vi kan ikke bare se på data i sammenheng med applikasjonen vi bygger. Vi må modellere dataene og sørge for at vi dokumenterer dem fordi de lever lenge utover applikasjonene selv. Disse applikasjonene kommer og går, men vi må kunne se på dataene og sørge for at de er robuste og godt strukturerte, ikke bare for applikasjoner, men også for beslutninger som rapporterer aktiviteter, BI-rapportering og integrasjon til andre applikasjoner, interne og eksternt til våre organisasjoner. Så vi må se på det hele store bildet av dataene og hva livssyklusen til disse dataene er og forstå reisen med informasjonsstykker i organisasjonen fra vugge til grav.
Nå tilbake til de faktiske teamene selv og hvordan vi faktisk trenger å jobbe, ble fossen metodikk oppfattet som for treg til å levere resultater. For som påpekt med tankeksemplet var det det ene trinnet etter det andre, og det tok ofte for lang tid å levere et gjennomførbart sluttresultat. Det vi gjør nå, er at vi trenger en iterativ arbeidsstil der vi trinnvis utvikler komponenter av den og utdyper den gjennom tid der vi produserer brukbar kode eller brukbare gjenstander, skal jeg si, for hver sprint. Det viktige er samarbeid mellom de tekniske interessentene i teamet og næringslivets interessenter, da vi samarbeider for å drive brukerhistoriene ut i en implementerbar visjon om kode og dataene som også støtter den koden. Og Agile Data Modeler selv vil ofte finne at vi ikke har nok modellerere i organisasjoner, slik at én datamodeller eller arkitekt samtidig kan støtte flere team.
Og det andre aspektet av det er, selv om vi har flere modellerere, må vi sørge for at vi har et verktøy som vi bruker som gjør det mulig å samarbeide om flere prosjekter som er på flukt samtidig og dele av dem data artefakter og innsjekkings- og utsjekkingsfunksjonene. Jeg kommer til å gå raskt over dette fordi vi allerede har dekket det i forrige avsnitt. Den virkelige forutsetningen for smidige er at du baserer ting på etterslep, historier eller krav. Innenfor iterasjonene samarbeider vi som en gruppe. Vanligvis er en sprint på to uker eller en måned, avhengig av organisasjon, veldig vanlig. Og også daglig gjennomgang og standup-møter, slik at vi eliminerer blokkering og sørger for at vi beveger alle aspekter fremover uten å bli stoppet på forskjellige områder mens vi går gjennom. Og i de spurtene vil vi sørge for at vi produserer brukbare leveranser som en del av hver sprint.
Bare et litt annet inntrykk av det, utvide det ytterligere, skrum er metodikken jeg skal snakke om mer spesifikt her, og vi har i utgangspunktet forsterket det forrige bildet med noen få andre fasetter. Vanligvis er det en produktets etterslep og så er det en sprint etterslep. Så vi har en samlet etterslep som vi i begynnelsen av hver sprint-gjentakelse setter oss ned for å si: "Hva skal vi bygge ut denne sprinten?", Og det er gjort i et sprintplanleggingsmøte. Så bryter vi opp oppgavene som er assosiert med det, og vi utfører i de ene til fire ukers sprintene med de daglige gjennomgangene. Når vi gjør at vi sporer fremdriften vår gjennom nedbrente diagrammer og nedbrente diagrammer for å spore i utgangspunktet hva som gjenstår å bygge kontra det vi bygger for å etablere ting som hva som er utviklingshastigheten vår, skal vi gjøre planlegge, alle de typer ting. Alle disse blir utdypet kontinuerlig under sprinten i stedet for å gå noen måneder nedover veien og finne ut at du kommer til å komme kort og at du må utvide prosjektplanen. Og veldig viktig, som en del av det, hele lagene, det er en sprintanmeldelse på slutten og et sprint retrospektiv, så før du starter den neste iterasjonen, vurderer du hva du gjorde, og du leter etter måter du kan bli bedre neste gang.
Når det gjelder leveranser er dette i utgangspunktet et lysbilde som oppsummerer de typiske typene ting som foregår i spurter. Og det er veldig utviklingssentrisk, så mange av de tingene vi ser her, for eksempel funksjonell design og brukskasser, å gjøre designkodetester, når vi ser på disse boksene her, og jeg har ikke tenkt å gå gjennom dem i alle detaljnivåer er de veldig utviklingsorienterte. Og begravet under her er det faktum at vi også trenger å ha de dataleveransene som går hånd i hånd med dette for å støtte denne innsatsen. Så hver gang vi ser ting som etterslep, krav og brukerhistorier, når vi går gjennom, må vi se på hva som er utviklingsdelene vi må gjøre, hva er analysestykkene vi trenger å gjøre, og hva med data design eller datamodellen, hva med ting som virksomhetsordlistene slik at vi kan knytte forretningsbetydning til alle gjenstandene vi produserer? Fordi vi må produsere de brukbare leveransene i hver sprint.
Noen mennesker vil si at vi trenger å produsere brukbar kode på slutten av hver sprint. Det er ikke nødvendigvis tilfelle, det er det i et reneste utviklingsperspektiv, men ganske ofte - spesielt i begynnelsen - kan vi ha noe som sprint null der vi fokuserer rent på å stå opp, gjøre ting som å få teststrategiene våre i plass. Et høyt nivå design for å få det i gang før vi begynner å fylle ut detaljene og sørge for at vi har et rent sett med starthistorier eller krav før vi begynner å engasjere andre målgrupper og deretter bygge videre som et team når vi går fremover. Det er alltid litt forberedelsestid, så ofte vil vi ha en sprint null eller til og med sprint null og en. Kan være litt av en oppstartsfase før vi treffer full flukt med å levere løsningen.
La oss snakke om datamodeller i denne sammenhengen veldig kort. Når folk tenker på datamodeller, tenker de ofte på en datamodell som et bilde av hvordan de forskjellige informasjonsbitene binder seg sammen - det er bare toppen av isfjellet. For å legemliggjøre ånden til hvordan du virkelig vil tilnærme deg datamodellering - enten det er i smidig utvikling og andre ting - må du innse at datamodellen, hvis den blir gjort riktig, blir din fulle spesifikasjon for hva dataene betyr i organisasjonen og hvordan den distribueres i back-end-databasene. Når jeg sier databaser, mener jeg ikke bare de relasjonsdatabaser som vi bruker, men i dagens arkitekturer hvor vi har big data eller NoSQL-plattformer, som jeg foretrekker å kalle dem. Også de store datalagrene fordi vi kanskje kombinerer mange forskjellige datalagre når det gjelder å konsumere informasjon og bringe den inn i løsningene våre, samt hvordan vi vedvarer eller lagrer informasjonen ut av løsningene våre også.
Vi jobber muligens med flere databaser eller datakilder samtidig i sammenheng med en gitt applikasjon. Det som er veldig viktig er at vi ønsker å kunne ha en full spesifikasjon, så en logisk spesifikasjon av hva dette betyr for et sprint organisasjonsperspektiv, hva de fysiske konstruksjonene er i forhold til hvordan vi faktisk definerer dataene, forholdene mellom dem i databasene dine, referansebegrensningene, sjekkbegrensningene, alle de valideringsdelene du vanligvis tenker på. De beskrivende metadataene er ekstremt viktige. Hvordan vet du hvordan du kan bruke dataene i applikasjonene dine? Med mindre du kan definere det og vite hva det betyr eller vite hvor det kom fra for å forsikre deg om at du bruker riktig data i disse applikasjonene - sørg for at vi har riktige navnekonvensjoner, fullstendige definisjoner, som betyr en full dataordbok for ikke bare tabellene, men kolonnene som inneholder disse tabellene - og detaljerte distribusjonsnotater om hvordan vi bruker det fordi vi trenger å bygge opp dette kunnskapsgrunnlaget fordi selv når denne applikasjonen er ferdig, vil denne informasjonen bli brukt til andre initiativer, så vi må sørge for at vi har alt det som er dokumentert for fremtidige implementeringer.
Igjen kommer vi ned på ting som datatyper, nøkler, indekser, selve datamodellen legemliggjør mange av forretningsreglene som kommer inn. Forholdene er ikke bare begrensninger mellom forskjellige tabeller; de hjelper oss ofte å beskrive hva de sanne forretningsreglene er rundt hvordan data oppfører seg og hvordan de fungerer sammen som en sammenhengende enhet. Og selvfølgelig er verdibegrensninger veldig viktige. Nå er selvfølgelig en av tingene vi kontinuerlig arbeider med, og det blir mer og mer utbredt, ting som styring av data. Så fra et datastyringsperspektiv, må vi også se på hva vi definerer her? Vi ønsker å definere ting som sikkerhetsklassifiseringer. Hvilke typer data har vi å gjøre med? Hva kommer til å bli betraktet som hoveddatadministrasjon? Hva er transaksjonsbutikkene vi lager? Hvilke referansedata bruker vi i disse applikasjonene? Vi må sørge for at det fanges ordentlig i modellene våre. Og også hensyn til datakvalitet, det er visse opplysninger som er viktigere for en organisasjon enn andre.
Jeg har vært involvert i prosjekter der vi erstattet over et dusin legacy-systemer med nye forretningsprosesser og designet nye applikasjoner og datalagre for å erstatte dem. Vi trengte å vite hvor informasjonen kom fra. Hvilke for de viktigste informasjonsdelene, fra et forretningsmessig perspektiv, hvis du ser på denne spesielle datamodell-lysbilden som jeg har her, vil du se at bunnkassene i disse bestemte enhetene, som bare er en liten undergruppe, jeg har faktisk vært i stand til å fange forretningsverdien. Enten høy, middels eller lav for denne typen ting for disse forskjellige konstruksjonene i organisasjonen. Og jeg har også fanget opp ting som masterdataklassene, om de er hovedtabeller, om de er referanse, om de var transaksjonelle. Så vi kan utvide metadataene våre i modellene våre for å gi oss mange andre kjennetegn utenfor selve dataene, noe som virkelig hjalp oss med andre initiativ utenfor de opprinnelige prosjektene og videreføre dem. Nå som det var mye i ett lysbilde, skal jeg gjennomgå resten av disse ganske raskt.
Jeg skal nå snakke veldig raskt om hva gjør en datamodeller når vi skal gjennom disse forskjellige sprintene. Først av alt, en full deltaker i sprintplanleggingsøktene, hvor vi tar brukerhistoriene, forplikter oss til hva vi skal levere i den sprinten, og finner ut hvordan vi skal strukturere den og levere den. Hva jeg også gjør som datamodeller er at jeg vet at jeg skal jobbe i separate områder med forskjellige utviklere eller med forskjellige mennesker. Så en av de viktige egenskapene vi kan ha, er når vi gjør en datamodell, og vi kan dele den datamodellen i forskjellige synspunkter, enten du kaller dem fagområder eller delmodeller, er terminologien vår. Så mens vi bygger opp modellen, viser vi den også i disse forskjellige undermodellperspektivene, slik at de forskjellige målgruppene bare ser hva som er relevant for dem, slik at de kan konsentrere seg om det de utvikler og legger frem. Så jeg kan ha noen som jobber med en planleggende del av et program, kanskje jeg har noen andre som jobber med en ordreoppføring der vi gjør alle disse tingene i en enkelt sprint, men jeg kan gi dem synspunktene gjennom de undermodellene som bare gjelder for området de jobber med. Og så ruller de opp til den overordnede modellen og hele strukturen til undermodeller for å gi forskjellige publikumsvisninger hva de trenger å se.
Grunnleggende fra et datamodelleringsperspektiv som vi ønsker å ha, er å alltid ha en grunnleggende linje som vi kan gå tilbake til fordi en av tingene vi trenger å kunne gjøre er, enten det er på slutten av en sprint eller på slutten av flere spurter, vil vi vite hvor vi startet og alltid ha en grunnlinje for å vite hva som var deltaet eller forskjellen på hva vi produserte i en gitt sprint. Vi må også sørge for at vi kan få en rask snuoperasjon. Hvis du kommer inn på det som datamodeller, men i den tradisjonelle portvaktrollen som å si "Nei, nei, du kan ikke gjøre det, vi må gjøre alle disse tingene først, " kommer du til å bli ekskludert fra teamet når du virkelig trenger å være en aktiv deltaker i alle de smidige utviklingsteamene. Det betyr at noen ting faller av vognen med en gitt sprint, og du henter dem i senere spurter.
Som et eksempel kan du fokusere på datastrukturen bare for å få utviklingen til å si, den ordreinngangsdelen som jeg snakket om. I en senere sprint kan du komme tilbake og fylle ut dataene som noe av dokumentasjonen for dataordboken rundt noen av de gjenstandene du har laget. Du kommer ikke til å fullføre den definisjonen i en sprint; du kommer til å fortsette med leveringene dine trinnvis fordi det vil være tidspunkter du kan fylle ut den informasjonen som jobber med forretningsanalytikere når utviklerne er opptatt med å bygge applikasjonene og utholdenheten rundt disse datalagrene. Du vil tilrettelegge og ikke være flaskehalsen. Det er forskjellige måter vi jobber med utviklere. For noen ting har vi designmønstre, så vi er en full deltaker foran, så vi kan ha et designmønster der vi vil si at vi vil legge det inn i modellen, vi vil skyve det ut til utviklerenes sandkassedatabaser og så kan de begynn å jobbe med det og be om endringer i det.
Det kan være andre områder som utviklere har jobbet med, de har fått noe de jobber med, og de prototyper noen ting, så de prøver ut noen ting i sitt eget utviklingsmiljø. Vi tar den databasen som de har arbeidet med, tar den med i modelleringsverktøyet vårt, sammenligner med modellene vi har og løser og presser endringene tilbake til dem slik at de kan refaktorere kodene sine slik at de følger de riktige datastrukturene som vi trenger. Fordi de kan ha laget noen ting vi allerede hadde andre steder, så vi sørger for at de jobber med de riktige datakildene. Vi fortsetter med å itere hele veien gjennom dette til sprinten vår, slik at vi får de fullstendige datautleveringene, full dokumentasjon og definisjonen av alle de datastrukturene vi produserer.
De mest vellykkede smidige prosjektene som jeg har vært involvert i når det gjelder veldig gode leveranser er, vi hadde en filosofi, modellerer alle endringer i den fullstendige fysiske databasespesifikasjonen. I hovedsak blir datamodellen de distribuerte databasene som du jobber med for noe nytt som vi oppretter, og som har fulle referanser til de andre datalagrene hvis vi konsumerer fra andre databaser utenfor. Som en del av det produserer vi trinnvise skript kontra å gjøre en hel generasjon hver gang. Og vi bruker designmønstrene våre for å gi oss det raske løftet når det gjelder å få ting til å gå i sprint med de forskjellige utviklingsteamene vi jobber med.
Også i sprintaktiviteter er det grunnleggende for sammenligning / sammenslåing, så la oss ta ideen om å modellere hver endring. Hver gang vi gjør en endring, hva vi vil gjøre er at vi ønsker å modellere endringen og hva som er veldig viktig, det som har manglet på datamodellering inntil nylig, faktisk, til vi introduserte det på nytt, er muligheten til å knytte modelleringen oppgaver og leveranser med brukerhistoriene og oppgavene som faktisk får de endringene til å skje. Vi ønsker å kunne sjekke inn modellendringene våre, på samme måte som utviklere sjekker inn kodene sine, med referanse til brukerhistoriene som vi har, så vi vet hvorfor vi gjorde endringer i utgangspunktet, det er noe vi gjør. Når vi gjør det, genererer vi de inkrementelle DDL-skriptene våre og legger dem ut slik at de kan hentes med andre utviklingsleveranser og sjekkes inn i byggeløsningen vår. Igjen, vi kan ha en modell eller jobbe med flere team. Og som jeg har snakket om, noen ting stammer fra datamodelleren, andre ting stammer fra utviklerne og vi møtes i midten for å komme frem til det overordnede beste designet og skyve det frem og sørge for at det er riktig designet i vår generelle datastrukturer. Vi må opprettholde disiplinen for å sikre at vi har alle de riktige konstruksjonene i datamodellen vår når vi går fremover, inkludert ting som null og ikke nullverdier, referansebegrensninger, i utgangspunktet sjekkbegrensninger, alle de tingene vi vanligvis vil tenke på .
La oss snakke om bare noen få skjermbilder av noen av verktøyene som hjelper oss å gjøre dette. Det jeg synes er viktig er å ha det samarbeidsdepot, så det vi kan gjøre som datamodeller - og dette er et utdrag av en del av en datamodell i bakgrunnen - er når vi jobber med ting vi vil sørge for at vi kan jobbe med bare objektene som vi trenger for å kunne endre, gjøre endringer, generere DDL-skriptene våre for endringene vi har gjort når vi sjekker tingene inn igjen. Så det vi kan gjøre er at i ER Studio er et eksempel, vi kan sjekke ut objekter eller grupper av objekter å jobbe med, vi trenger ikke å sjekke ut en hel modell eller delmodell, vi kan sjekke ut akkurat de tingene som er av interesse for oss. Det vi vil etter det er enten ved utsjekking eller innsjekkingstid - vi gjør det begge veier fordi forskjellige utviklingsteam jobber på forskjellige måter. Vi vil forsikre oss om at vi knytter det til brukerhistorien eller oppgaven som driver kravene til dette, og det vil være den samme brukerhistorien eller oppgaven som utviklerne skal utvikle og sjekke koden sin for.
Så her er et veldig raskt stykke av et par skjermer fra et av sentrene for endringsadministrasjon. Hva dette gjør, skal jeg ikke gjennomgå i detalj her, men det du ser er brukerhistorien eller oppgaven og innrykket under hver enkelt av de du ser de faktiske endringspostene - vi har laget en automatisert endringspost når vi gjør innsjekking og utsjekking, og vi kan legge mer beskrivelse på den endringsposten også. Det er assosiert med oppgaven, vi kan ha flere endringer per oppgave, som du forventer. Og når vi går inn på den endringsposten, kan vi se på den og enda viktigere, hva har vi egentlig endret? For akkurat denne, den fremhevede historien der, hadde jeg en type endring som ble gjort, og da jeg så på selve endringsposten, har den identifisert de enkelte brikkene i modellen som har endret seg. Jeg endret et par attributter her, gjenopplignet dem, og det brakte for turen visningene som måtte endres, som var avhengige av dem også, slik at de ville bli generert i den inkrementelle DLL. Det er ikke bare modellering på basisobjektene, men et høydrevet modelleringsverktøy som dette oppdager også endringene som må kruskes gjennom de avhengige objektene i databasen eller datamodellen også.
Hvis vi jobber med utviklere, og vi gjør dette i et par forskjellige ting, som gjør noe i sandkassen deres, og vi vil sammenligne og se hvor forskjellene er, bruker vi sammenlignings- / fletteevne hvor til høyre og til venstre side. Vi kan si: "Her er vår modell på venstre side, her er databasen deres på høyre side, vis meg forskjellene." Vi kan deretter velge og velge hvordan vi løser disse forskjellene, om vi skyver ting inn i databasen eller om det er noen ting de har i databasen som vi tar med tilbake til modellen. Vi kan gå toveis, slik at vi kan gå i begge retninger samtidig oppdatere både kilde og mål og deretter produsere de inkrementelle DDL-skriptene for å distribuere disse endringene i selve databasemiljøet, noe som er ekstremt viktig. Det vi også kan gjøre er at vi også kan bruke denne sammenligne og slå sammen evnen til enhver tid. Hvis vi tar øyeblikksbilder på vei gjennom, kan vi alltid sammenligne starten på en sprint til start eller slutt på en annen sprint slik at vi kan se full trinnvis endring av hva som ble gjort i en gitt utviklingssprint eller over en serie med sprints.
Dette er et veldig raskt eksempel på et alter script, alle dere som har jobbet med databaser vil ha sett denne typen ting, dette er hva vi kan skyve ut av koden som et alter script slik at vi sørger for at vi beholde ting her. Det jeg dro ut her, bare for å redusere rotet, er det vi også gjør med disse alter-skriptene. Vi antar at det også er data i disse tabellene, så vi vil også generere DML som vil trekke informasjonen til de midlertidige tabellene og skyv den tilbake i de nye datastrukturene, så vi ser på ikke bare strukturene, men dataene som vi allerede har inneholdt i disse strukturene.
Kommer til å snakke veldig raskt om automatiserte build-systemer, fordi når vi gjør et smidig prosjekt, jobber vi ofte med automatiserte build-systemer der vi må sjekke inn de forskjellige leveransene sammen for å sikre at vi ikke ødelegger byggene våre. Hva det betyr er at vi synkroniserer leveransene, de endringsskriptene som jeg snakket om med DDL-skriptet må sjekkes inn, den tilsvarende applikasjonskoden må sjekkes inn samtidig og mye utvikling av utviklere nå er selvfølgelig ikke gjøres med direkte SQL mot databasene og den typen ting. Ganske ofte bruker vi utholdenhetsrammer eller bygger datatjenester. Vi må sørge for at endringene for disse rammene eller tjenestene sjekkes inn på nøyaktig samme tid. De går inn i et automatisert byggesystem i noen organisasjoner, og hvis byggingen går i stykker, i en smidig metodikk, er det alle hendene på dekkfesting som bygger før vi går videre slik at vi vet at vi har en fungerende løsning før vi går videre. Og ett av prosjektene som jeg var involvert i, vi tok dette til det ekstreme - hvis bygningen brøt vi faktisk hadde festet til en rekke datamaskiner i vårt område der vi ble kolokulert med forretningsbrukerne, hadde vi røde blinkende lys bare som toppen av politibiler. Og hvis bygningen brøt, begynte de røde blinkende lysene å slukke, og vi visste at det var alle hender på dekk: fikse byggverket og fortsett med det vi gjorde.
Jeg vil snakke om andre ting, og dette er en unik evne til ER Studio, det hjelper virkelig når vi prøver å bygge disse gjenstandene som utviklere for disse utholdenhetsgrensene, vi har et konsept som heter forretningsdataobjekter og hva som tillater oss å Hvis du ser på denne veldig forenklede datamodellen som et eksempel, lar den oss innkapsle enheter eller grupper av enheter for hvor utholdenhetsgrensene er. Der vi som datamodeller kan tenke på noe som en innkjøpsordreoverskrift og ordrejusteringen og andre detaljerte tabeller som vil knytte seg til det på den måten vi bygger det ut og våre datatjenesterutviklere trenger å vite hvordan ting vedvarer til de forskjellige dataene strukturer. Utviklerne våre tenker på ting som innkjøpsordren som et objekt generelt, og hva er kontrakten deres med hvordan de lager de spesielle objektene. Vi kan eksponere den tekniske detaljene slik at personene som bygger dataserverne kan se hva som er under den, og vi kan beskytte de andre målgruppene fra kompleksiteten, slik at de bare ser de forskjellige objektene på høyere nivå, som også fungerer veldig bra for å kommunisere med virksomheten analytikere og forretningsinteressenter når vi snakker om samspillet mellom forskjellige forretningskonsepter også.
Det fine med det også er at vi konstruktivt utvider og kollapser disse, slik at vi kan opprettholde forholdet mellom objekter med høyere orden, selv om de har sitt utspring i konstruksjoner som finnes i selve forretningsdataobjektene. Nå som modellerer, kom til slutten av sprinten, på slutten av sprintopppakningen, jeg har mange ting jeg trenger å gjøre, som jeg kaller hushjelp for neste sprint. Hver sprint lager jeg det jeg kaller Named Release - som gir meg baseline for det jeg har nå på slutten av utgivelsen. Så det betyr at det er grunnlinjen min fremover, alle disse grunnlinjene eller navngitte utgivelser som jeg lager og lagrer i depotet mitt, jeg kan bruke til å sammenligne / slå sammen, slik at jeg alltid kan sammenligne med en gitt sprint fra en hvilken som helst annen sprint, som er veldig viktig å vite hva endringene dine var i datamodellen din på vei gjennom reisen.
Jeg lager også et delta DDL-skript ved å bruke sammenligne / slå sammen igjen fra start til slutten av sprinten. Jeg har kanskje sjekket inn en hel haug med trinnvise skript, men hvis jeg trenger det, har jeg nå et skript som jeg kan distribuere for å stå opp andre sandkasser, så jeg kan bare si at det var det vi hadde på begynnelsen av den ene sprinten, trykk det gjennom, bygg en database som sandkasse for å starte med neste sprint, og vi kan også bruke de tingene til å gjøre ting som standup QA-tilfeller, og til slutt ønsker vi selvfølgelig å skyve endringene våre til produksjon, slik at vi har flere ting på gang samtidig. Igjen, vi deltar fullt ut i sprintplanleggingen og retrospektiver, retrospektivene er virkelig leksjonene, og det er ekstremt viktig, fordi du kan komme i gang veldig raskt i smidighet, du trenger å stoppe og feire suksessene, som nå. Finn ut hva som er galt, gjør det bedre neste gang, men feir også tingene som gikk riktig og bygg videre på dem når du fortsetter å gå fremover i de neste spurtene fremover.
Jeg skal nå veldig raskt snakke om forretningsverdi. Det var et prosjekt som jeg ble involvert i for mange år siden som startet som et smidig prosjekt, og det var et ekstremt prosjekt, så det var et rent selvorganiserende team der det bare var utviklere som gjorde alt. For å gjøre en lang historie kort, dette prosjektet ble stoppet, og de oppdaget at de brukte flere og flere ganger på å sanere og fikse de feilene som ble identifisert enn de hadde på å presse frem mer funksjonalitet, og faktisk når de så på det basert på nedbrente diagrammer de måtte forlenge prosjektet seks måneder til en enorm kostnad. Og da vi så på det, var måten å avhjelpe problemet på å bruke et skikkelig datamodelleringsverktøy med en dyktig datamodeller som var involvert i selve prosjektet.
Hvis du ser på denne vertikale linjen på dette spesifikke diagrammet, viser dette kumulative defekter kontra kumulative objekter, og jeg snakker om dataobjekter eller konstruksjoner som ble opprettet, for eksempel tabellene med begrensningene og de slags ting, hvis du så på før datamodelleren ble introdusert, var antallet defekter faktisk overskredet og begynte å bygge litt av et gap over det faktiske antallet objekter som ble produsert fram til det tidspunktet. Etter uke 21, det var da datamodelleren kom inn, refaktert datamodellen basert på hva det var for å fikse en rekke ting og deretter startet modellering som en del av prosjektgruppen fremover, endringene etter hvert som prosjektet ble presset frem . Og du så en veldig rask snuoperasjon at innen omtrent en og en halv sprint så vi en enorm uptick i antall objekter og datakonstruksjoner som ble generert og konstruert fordi vi genererte ut av et datamodelleringsverktøy i stedet for en utviklerpinne å bygge dem i et miljø, og de var riktige fordi de hadde den rette referansegruppen og de andre konstruksjonene den skulle ha. Nivået på mangler mot de nesten flatline. Ved å iverksette passende tiltak og sørge for at datamodelleringen var fullt ut engasjert, ble prosjektet levert i tide med et mye høyere kvalitetsnivå, og faktisk ville det ikke ha levert i det hele tatt hvis disse trinnene ikke hadde funnet sted. Det er mange smidige feil der ute, det er også mange smidige suksesser hvis du ville fått de rette personene i de riktige rollene som er involvert. Jeg er en stor tilhenger av smidig som en operasjonell disiplin, men du må sørge for at du har ferdighetene til alle de riktige gruppene som er involvert som prosjektgrupper når du går videre på en smidig type bestrebelser.
For å oppsummere, må dataarkitekter og modellerere være involvert i alle utviklingsprosjekter; de er virkelig limet som holder alt sammen fordi vi som datamodellere og arkitekter forstår, ikke bare datakonstruksjonene til det gitte utviklingsprosjektet, men også hvor dataene finnes i organisasjonen og hvor vi kan kildes til dataene fra, og også hvordan de kommer til å bli brukt og brukt utenfor selve applikasjonen som vi jobber med. Vi forstår de komplekse dataforholdene, og det er helt avgjørende å kunne komme videre, og også fra et styringsperspektiv for å kartlegge dokument og forstå hvordan det fulle datalandskapet ditt ser ut.
Det er som produksjon; Jeg kom fra en produksjonsbakgrunn. Du kan ikke inspisere kvalitet til noe på slutten - du trenger å bygge kvalitet inn i designet på forhånd og på vei gjennom, og datamodellering er en måte å bygge den kvaliteten inn i designet på en effektiv og kostnadseffektiv måte hele veien gjennom . Og igjen, noe å huske - og dette er ikke for å være trite, men det er sannheten - applikasjoner kommer og går, data er den viktige bedriftens eiendel og den overskrider alle disse applikasjonsgrensene. Hver gang du legger inn en applikasjon, blir du sannsynligvis bedt om å bevare dataene fra andre applikasjoner som kom før, så vi trenger bare å huske at det er en viktig bedriftens eiendel som vi fortsetter å opprettholde over tid.
Og det er det! Herfra vil vi ta flere spørsmål.
Eric Kavanagh: OK, bra, la meg kaste den over til Robin først. Og da, Dez, jeg er sikker på at du har et par spørsmål. Ta den bort, Robin.
Dr. Robin Bloor: OK. For å være ærlig har jeg aldri hatt noe problem med smidige utviklingsmetoder, og det ser ut til at det du gjør her gir utmerket mening. Jeg husker at jeg så på noe på 1980-tallet som tydet på at problemet du faktisk støter på i form av et prosjekt som spinner ut av kontroll, vanligvis er hvis du lar en feil vedvare utover et bestemt stadium. Det blir mer og mer vanskelig å fikse hvis du ikke får det stadiet riktig, så en av tingene du gjør her - og jeg tror dette er lysbildet - men en av tingene du gjør her i sprint null er etter min mening helt viktig fordi du virkelig prøver å få festene festet der. Og hvis du ikke får festet leveranser, endrer leveranser form.
Det er, slags, min mening. Det er også min mening - jeg har egentlig ikke noe argument for ideen om at du må få datamodelleringen rett til et visst detaljnivå før du går gjennom. Hva jeg ønsker at du skulle prøve og gjøre fordi jeg ikke fikk en fullstendig følelse av det, er bare å beskrive et av disse prosjektene når det gjelder størrelsen, med tanke på hvordan det rant, med tanke på hvem, du vet, hvor problemene dukket opp, ble de løst? Fordi jeg tror at denne lysbilden er ganske hjertet av det, og hvis du kunne utdype litt mer om det, ville jeg være veldig takknemlig.
Ron Huizenga: Visst, og jeg vil bruke et par eksempelprosjekter. Den som, slags, gikk av skinnene som ble brakt tilbake ved faktisk å få de rette menneskene involvert og gjøre datamodelleringen, og alt var virkelig en måte å sikre at designen ble forstått bedre og vi tydeligvis hadde bedre implementeringsdesign på vei gjennom ved å modellere det. For når du modellerer det, vet du, kan du generere DDL og alt ut bakfra og ut av verktøyet i stedet for å måtte holde fast ved å bygge dette slik folk vanligvis kan gjøre ved å gå rett inn i et databasemiljø. Og typiske ting som vil skje med utviklere er at de vil gå inn der, og de vil si, ok, jeg trenger disse tabellene. La oss si at vi gjør ordreoppføringer. Så de kan lage ordreoverskriften og tabellene for ordredetaljer, og de typer ting. Men de vil ofte glemme eller forsømme å forsikre seg om at begrensningene er der for å representere de utenlandske nøkkelforholdene. De har kanskje ikke nøklene riktig. Navnekonvensjonene kan også være mistenkelige. Jeg vet ikke hvor mange ganger jeg har gått inn i et miljø, for eksempel der du ser en haug med forskjellige tabeller med forskjellige navn, men da er kolonnenavnene i disse tabellene som ID, Navn eller hva som helst, så de har virkelig mistet konteksten uten tabellen over nøyaktig hva det er.
Så, typisk når vi modellerer data, vil vi sørge for at vi bruker riktige navnekonvensjoner på alle gjenstandene som blir generert i DDL også. Men for å være mer spesifikk om arten av selve prosjektene snakker jeg generelt sett om ganske store initiativer. Et av dem var $ 150 millioner forretningstransformasjonsprosjekt hvor vi erstattet over et dusin legacy-systemer. Vi hadde fem forskjellige smidige lag på gang samtidig. Jeg hadde et fullstendig dataarkitekturteam, så jeg hadde datamodeller fra teamet mitt innebygd i hvert av de andre applikasjonsområdene, og vi jobbet med en kombinasjon av interne forretningseksperter som visste emnet, som gjorde det brukerhistorier for kravene selv. Vi hadde forretningsanalytikere i hvert av disse teamene som faktisk modellerte forretningsprosessen, med aktivitetsdiagrammer eller forretningsprosessdiagrammer, som hjalp til med å utpeke brukerhistoriene mer med brukerne før de også ble fortært av resten av teamet.
Og så, selvfølgelig, utviklerne som bygde applikasjonskoden over toppen av det. Og vi jobbet også med, jeg tror det var fire forskjellige leverandører av systemintegrasjon som bygde forskjellige deler av applikasjonen i tillegg der det ene teamet bygde datatjenestene, det andre bygde applikasjonslogikk på ett område, et annet som hadde kompetanse i et annet forretningsområde bygde applikasjonslogikken i det området. Så vi hadde et helt samarbeid med mennesker som jobbet med dette prosjektet. Spesielt på den ene hadde vi 150 mennesker på land, og ytterligere 150 ressurser offshore på teamet som samarbeidet to ukers sprint for å drive denne tingen ut. Og for å gjøre det må du sørge for at du skyter på alle sylindere, og alle er godt synkronisert med tanke på hva leveransen er, og du hadde de hyppige tilbakestillinger for å sikre at vi fullførte leveransene våre av alle nødvendige gjenstander på slutten av hver sprint.
Dr. Robin Bloor: Det er imponerende. Og bare for litt mer detalj om det - endte du opp med en komplett, hva jeg vil kalle, MDM-kart over hele dataområdet på slutten av dette prosjektet?
Ron Huizenga: Vi hadde en komplett datamodell som ble brutt sammen med nedbrytningen mellom alle de forskjellige forretningsområdene. Selve dataordboken når det gjelder fulle definisjoner falt litt kort. Vi hadde de fleste tabellene definert; vi hadde de fleste kolonnene definert til nøyaktig hva de mente. Det var noen som ikke var der, og interessant nok, mange av disse var informasjonsstykker som kom fra arvesystemene der det, etter endt prosjektomfang, fremdeles ble dokumentert som et fremførende sett med artefakter, som det var, utenfor selve prosjektet, fordi det var noe som måtte opprettholdes av organisasjonen fremover. Så på samme tid tok organisasjonen et mye økt synspunkt på viktigheten av styring av data fordi vi så mange mangler i disse arvsystemene og de gamle datakildene som vi prøvde å konsumere fordi de ikke var dokumentert. I mange tilfeller hadde vi bare databaser som vi måtte reversere og prøve å finne ut hva som var der og hva informasjonen var til.
Dr. Robin Bloor: Det overrasker meg ikke, det bestemte aspektet av det. Datastyring er, la oss kalle det, en veldig moderne bekymring, og jeg tror virkelig, det er mye arbeid som, la oss si det, burde vært gjort historisk med datastyring. Det var aldri fordi du kunne, slippe unna med å ikke gjøre det. Men ettersom dataressursen bare vokste og vokste, kunne du til slutt ikke gjøre det.
Uansett vil jeg overføre til Dez fordi jeg tror jeg har hatt min tildelte tid. Dez?
Dez Blanchfield: Ja, takk. Gjennom hele saken ser jeg på og tenker for meg selv at vi snakker om å se smidige brukt i sinne på mange måter. Selv om det har negative konnotasjoner; Det mente jeg på en positiv måte. Kan du kanskje bare gi oss et scenario av, jeg mener, det er to steder jeg kan se at dette er et perfekt sett: ett er nye prosjekter som bare må gjøres fra første dag, men jeg tror alltid, etter min erfaring, er det ofte i tilfelle at når prosjekter blir store nok til at dette er nødvendig på mange måter, er det en interessant utfordring mellom å lime de to verdenene, ikke sant? Kan du gi oss noen form for innsikt i noen suksesshistorier du har sett hvor du har gått inn i en organisasjon, er det blitt klart at de har fått et lite sammenstøt mellom de to verdenene, og du har vært i stand til å dette på plass og bringe store prosjekter sammen der de ellers kunne ha gått på skinnene? Jeg vet at det er et veldig bredt spørsmål, men jeg lurer bare på om det er en spesiell casestudie du kan, på en måte peke på hvor du sa, du vet, vi satte alt dette på plass og det har brakt alt utviklingsteamet sammen med datateamet, og vi har liksom adressert noe som ellers kan ha sunket båten?
Ron Huizenga: Visst, og faktisk det ene prosjektet som tilfeldigvis var et rørledningsprojekt, var det jeg henviste til der jeg viste det diagrammet med manglene før og etter datamodelleren var involvert. Ganske ofte, og det er forutinntatte forestillinger, spesielt hvis ting blir spunnet opp der det gjøres fra et rent utviklingsperspektiv, er det bare utviklere som er involvert i disse smidige prosjektene for å levere applikasjonene. Så det som skjedde der, selvfølgelig, er at de gikk av skinnene og deres data-artefakter spesielt, eller dataleverandørene de produserte, falt under merket når det gjelder kvaliteten og virkelig adresserte ting generelt. Og det er ofte denne misforståelsen at datamodellere vil bremse prosjekter, og det vil de gjøre hvis datamodelleren ikke har den rette holdningen. Som jeg sier, du må miste den - noen ganger er det datamodeller som har den tradisjonelle portvakt holdningen der, "Vi er her for å kontrollere hvordan datastrukturene ser ut, " og at mentaliteten må forsvinne. Alle som er involvert i smidig utvikling, og spesielt datamodellerne, må påta seg en rolle som tilrettelegger for å virkelig hjelpe teamene med å komme videre. Og den beste måten å illustrere det på er å veldig raskt vise team hvor produktive de kan være ved å modellere endringene først. Og igjen, det er derfor jeg snakket om samarbeidet.
Det er noen ting vi først kan modellere og generere DDL for å skyve ut til utviklerne. Vi vil også sørge for at de ikke føler at de blir begrenset. Så hvis det er ting de jobber med, la dem fortsette å jobbe i utviklingssandkassene, fordi det er der utviklere jobber på sine egne stasjonære maskiner eller andre databaser for å gjøre noen endringer der de tester ut ting. Og samarbeide med dem og si: "Ok, jobbe med det." Vi tar det inn i verktøyet, vi løser det og så vil vi skyve det frem og gi deg skriptene som du kan distribuere det for å oppdatere databaser for å oppgradere dem til hva den faktiske sanksjonerte ekte produksjonsvisningen av det kommer til å bli når vi fortsetter å gå videre. Og du kan snu det på en veldig rask måte. Jeg fant ut at dagene mine var fylt der jeg bare gikk frem og tilbake og itererer med forskjellige utviklingsteam, så på endringer, sammenliknet, genererte skript, fikk dem til å gå, og jeg klarte å holde følge med fire utviklingsteam ganske enkelt når vi oppnådd et momentum.
Dez Blanchfield: En av tingene som kommer opp i tankene om det er at, du vet, mange av samtalene jeg holder på daglig handler om dette godstoget som kommer til oss, slags, maskin-til -maskin og IoT. Og hvis vi tror vi har mye data nå om våre nåværende miljøer i bedriften, vet du, hvis vi tar enhjørningene til side for et øyeblikk hvor vi vet at Googles og Facebooks og Ubers har petabytes med data, men i en tradisjonell virksomhet snakker vi om fortsatt hundrevis av terabyte og mye data. Men det er dette godstoget som kommer til organisasjoner, etter mitt syn, og Dr. Robin Bloor henviste til det tidligere, av IoT. Du vet, vi har mye nettrafikk, vi har sosial trafikk, vi har nå mobilitet og mobile enheter, skyen har, slags, eksplodert, men nå har vi fått smart infrastruktur, smarte byer og det er hele dataverdenen som bare eksploderte.
For en hverdagsorganisasjon, en mellomstor til stor organisasjon som sitter der og ser denne verdenen av smerte kommer på dem og ikke har en umiddelbar plan i tankene, hva er noen av takeaways, i bare et par setninger, som du ville lagt til dem når og hvor de trenger å begynne å tenke samtale på å få noen av disse metodikkene på plass. Hvor tidlig trenger de å begynne å planlegge å nesten sette seg opp og ta hensyn og si at dette er rett tid for å få noen verktøy på plass og få teamet trent opp og få en samtale om vokab som går rundt denne utfordringen? Hvor sent i historien er det for sent eller når det er for tidlig? Hvordan ser det ut for noen av organisasjonene du ser?
Ron Huizenga: Jeg vil si for de fleste organisasjoner at hvis de ikke allerede har gjort det og tilpasset datamodellering og dataarkitektur med kraftige verktøy som dette, er tiden de trenger å gjøre det i går. Fordi det er interessant at vi i dag, når du ser på data i organisasjoner, har så mye data i våre organisasjoner og generelt sett, basert på noen undersøkelser vi har sett, bruker vi mindre enn fem prosent av disse dataene effektivt når vi ser på tvers av organisasjoner. Og med IoT eller til og med NoSQL, store data - selv om det ikke bare er IoT, men bare big data generelt - der vi nå begynner å konsumere enda mer informasjon som stammer fra utenfor organisasjonene våre, blir utfordringen større og større hele tiden. Og den eneste måten vi har en sjanse til å kunne takle det på er å hjelpe oss med å forstå hva disse dataene handler om.
Så brukssaken er litt annerledes. Det vi finner på at vi gjør er når vi ser på disse dataene, vi fanger dem inn, vi trenger å omgjøre dem, se hva som er i disse, enten det er i våre innsjøer eller til og med i våre interne databaser, syntetisere hva data er, bruk betydninger på det og definisjoner på det slik at vi kan forstå hva dataene er. For inntil vi forstår hva det er, kan vi ikke sikre at vi bruker det riktig eller tilstrekkelig. Så vi trenger virkelig å få tak i hva disse dataene er. Og den andre delen av det er, ikke gjør det fordi du, i form av å konsumere alle disse eksterne dataene, kan sørge for at du har en brukssak som støtter forbruk av disse eksterne dataene. Fokuser på de tingene du trenger, i stedet for å bare prøve å trekke og bruke ting du måtte trenge senere. Fokuser på de viktige tingene først, og når du jobber deg igjennom det, så kommer du til å konsumere og prøve å forstå den andre informasjonen utenfra.
Et perfekt eksempel på det er at jeg vet at vi snakker IoT og sensorer, men samme type problem har faktisk vært i mange organisasjoner i mange år, allerede før IoT. Alle som har et produksjonsstyringssystem, enten de er et rørledningsfirma, produserer, prosessbaserte selskaper som har ting der de driver med mye automatisering med kontroller, og de bruker datastrømmer og sånt, har disse brannslangene med data de prøver å drikke ut for å finne ut, hva er hendelsene som har skjedd i produksjonsutstyret mitt for å signalisere - hva har skjedd og når? Og blant denne enorme strømmen av data er det bare spesifikke opplysninger eller koder som de er interessert i at de trenger for å sile ut, syntetisere, modellere og forstå. Og de kan ignorere resten av det til det er på tide å virkelig forstå det, og så kan de utvide omfanget til å trekke mer og mer av det inn i omfanget, hvis det er fornuftig.
Dez Blanchfield: Det gjør det. Det er ett spørsmål som jeg kommer til å lede til som kom fra en herre som heter Eric, og vi har snakket om det privat. Jeg har akkurat bedt om tillatelsen hans, som han har gitt, til å spørre den om deg. For det fører fint inn i dette, bare for å pakke sammen, fordi vi går litt etter hvert nå, og jeg vil gi tilbake til Eric. Men spørsmålet fra en annen Eric var, er det rimelig å anta at eiere av en oppstart er kjent med og forstår de unike utfordringene rundt modelleringsterminologi og så, eller skal det overleveres noen andre for tolkning? Så, med andre ord, skal en oppstart være i stand og klar og villig og i stand til å fokusere på og levere på dette? Eller er det noe de sannsynligvis burde shoppe ut og ta med seg eksperter om bord med?
Ron Huizenga: Jeg antar at det korte svaret er at det virkelig kommer an. Hvis det er en oppstart som ikke har noen i huset som er en dataarkitekt eller modellerer som virkelig forstår databasen, så er den raskeste måten å starte å bringe noen med en konsulentbakgrunn som er veldig godt kjent i dette rommet og kan få dem går. Fordi det du finner - og faktisk gjorde jeg dette på mange engasjementer som jeg gjorde før jeg kom over til den mørke siden innen produktstyring - er at jeg ville gått inn i organisasjoner som konsulent, ledet deres dataarkitekturteam, slik at de kunne, slags fokusere seg på nytt og trene folket i hvordan de kan gjøre denne typen ting slik at de opprettholder det og bærer oppdraget fremover. Og så ville jeg gå videre til mitt neste engasjement, hvis det gir mening. Det er mange mennesker der ute som gjør det, som har veldig god dataerfaring som kan få dem til å gå.
Dez Blanchfield: Det er et fantastisk takeaway-poeng, og jeg er helt enig i det, og jeg er sikker på at Dr. Robin Bloor også ville gjort det. Spesielt i en oppstart, er du fokusert på å være en SME på den spesielle verdien av proposisjoner du ønsker å bygge som en del av selve oppstartsvirksomheten din, og du bør sannsynligvis ikke trenge å være en ekspert på alt, så gode råd. Men tusen takk, en fantastisk presentasjon. Virkelig gode svar og spørsmål. Eric, jeg vil gi tilbake til deg fordi jeg vet at vi sannsynligvis har gått ti minutter over tid, og jeg vet at du liker å holde deg nær tidsvinduene våre.
Eric Kavanagh: Det er greit. Vi har minst et par gode spørsmål. La meg kaste en over til deg. Jeg tror du har svart på noen av de andre. Men en veldig interessant observasjon og spørsmål fra en deltaker som skriver, noen ganger smidige prosjekter har datamodelleren som ikke har hele det langsiktige bildet, og slik at de ender opp med å designe noe i sprint en for så å måtte redesigne i sprint tre eller fire. Virker ikke dette kontraproduktivt? Hvordan kan du unngå den typen ting?
Ron Huizenga: Det er bare det smidige som du ikke kommer til å få alt helt riktig i en gitt sprint. Og det er faktisk en del av ånden til smidig, er: jobbe med det - du kommer til å gjøre prototyping der du jobber med kode i en gitt sprint, og du kommer til å gjøre forbedringer av det. Og en del av prosessen er når du leverer ting sluttbrukeren ser det og sier: "Ja, det er nær, men jeg må virkelig få det til å gjøre dette litt ekstra også." Så det påvirker ikke bare den funksjonelle designen av selve koden, men ganske ofte må vi endre eller legge til mer datastruktur under disse bestemte tingene for å levere det brukeren ønsker. Og det er alt bra spill, og det er grunnen til at du virkelig vil bruke de høye drevne verktøyene fordi du veldig raskt kan modellere og gjøre den endringen i et modelleringsverktøy og deretter generere DDL for databasen som utviklerne deretter kan jobbe mot for å levere det endres enda raskere. Du sparer dem fra å måtte gjøre den håndkodingen, som den var, av datastrukturer og la dem konsentrere seg om programmerings- eller applikasjonslogikken som de er dyktigste på.
Eric Kavanagh: Det gir full mening. Vi hadde et par andre mennesker som bare stilte spesifikke spørsmål rundt hvordan det hele knytter seg til verktøyet. Jeg vet at du har brukt litt tid på å gå gjennom eksempler, og at du har vist noen skjermbilder om hvordan du faktisk ruller ut noen av disse tingene. Når det gjelder hele denne sprintprosessen, hvor ofte ser du at i spill i organisasjoner kontra hvor ofte ser du mer tradisjonelle prosesser der ting bare, slags, kaster seg sammen og tar mer tid? Hvor utbredt er sprintstilnærmingen fra ditt perspektiv?
Ron Huizenga: Jeg tror vi ser det mer og mer. Jeg vet at sannsynligvis i løpet av de siste 15 årene har jeg sett mye mer av en adopsjon av folk som erkjenner at de virkelig trenger å omfatte raskere levering. Så jeg har sett flere og flere organisasjoner hoppe på den smidige bandwagon. Ikke nødvendigvis helt; de kan starte med et par pilotprosjekter for å bevise at det fungerer, men det er noen som fremdeles er veldig tradisjonelle, og de holder seg til fossen metoden. Den gode nyheten er selvfølgelig at verktøyene fungerer veldig bra i de organisasjonene også for den typen metodologier, men vi har tilpasningsevnen i verktøyet slik at de som hopper om bord har verktøyene i verktøykassen på fingertuppene. Ting som sammenligne og slå sammen, ting som omvendt-engineering evner, slik at de kan se hva de eksisterende datakildene er, slik at de faktisk kan sammenligne og generere de inkrementelle DDL-skriptene veldig raskt. Og når de begynner å omfavne det og ser at de kan ha produktiviteten, øker deres tilbøyelighet til å omfavne smidige enda mer.
Eric Kavanagh: Dette er gode ting, folkens. Jeg har nettopp lagt ut en lenke til lysbildene der i chatvinduet, så sjekk det ut; det er litt av det litt for deg. Vi har alle disse webcastene for senere visning. Del dem gjerne med dine venner og kolleger. Og Ron, tusen takk for tiden din i dag, du er alltid hyggelig å ha på showet - en ekte ekspert på området, og det er åpenbart at du kjenner til tingene dine. Så takk til deg og takk til IDERA og selvfølgelig til Dez og vår helt egen Robin Bloor.
Og med det kommer vi til å ta farvel, folkens. Takk igjen for din tid og oppmerksomhet. Vi setter pris på at du holder deg rundt i 75 minutter, det er et ganske godt tegn. Bra show folkens, vi snakker med deg neste gang. Ha det.
