Osoblje Techopedia, 16.11.2016
Odlazak: Domaćin Eric Kavanagh razgovara o važnosti modeliranja podataka u agilnom razvoju s Robinom Bloorom, Dezom Blanchfieldom i IDERA-inog Rona Huizengom.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Eric Kavanagh: Dobro, dame i gospodo. Dobrodošli još jednom. Srijeda je u 4:00 EST. To znači da je vrijeme za Hot Technologies. Da svakako. Moje ime je Eric Kavanagh, bit ću vam domaćin.
Za današnju temu, to je stari, ali dobar. Svakodnevno je sve bolji, jer oblikuje naš svijet upravljanja podacima, "Modeliranje podataka u agilnom okruženju." Doista je slajd o vašem, na Twitteru @eric_kavanagh. Stvarno bismo ga trebali staviti na tobogan. Morat ću se snaći na tome.
Tako je godina vruća. Modeliranje podataka postojalo je oduvijek. Stvarno je bilo u srcu i duši poslovanja s informatičkim upravljanjem, dizajniranja podataka modela, pokušavanja razumijevanja poslovnih modela i usklađivanja s njihovim modelima podataka. To je stvarno ono što pokušavaš učiniti, zar ne?
Model podataka predstavlja posao na fundamentalni način, pa kako svi ti novi izvori podataka mijenjaju igru? Saznat ćemo o tome. Otkrivat ćemo kako na agilni način možete biti na vrhu stvari. I naravno, o tome je riječ godine.
Robin Bloor je s nama, naš glavni analitičar, Dez Blanchfield koji dolazi iz Sydneya u Australiji i Ron Huizenga, stariji menadžer proizvoda iz IDERA-e - moj dugogodišnji prijatelj, izvrstan govornik na ovom prostoru, zna što zna, pa nemojte se stidjeti, pitajte njemu teška pitanja, ljudi, ona tvrda. S tim ću napraviti Robina kao voditelja i oduzeti.
Dr. Robin Bloor: Dobro. Pa, hvala ti na tome, Eric. O modeliranju moram reći da mislim da sam zapravo bio u svijetu IT prije nego što je postojalo, u smislu da se sjećam u osiguravajućem društvu da sam radio, da smo imali momka da nam ustupi sve vrste radionice o modeliranju podataka. Dakle, gledamo oko 30 godina, je li 30 godina? Možda i duže od toga, možda prije 35 godina. Dugo i dugo modeliranje zapravo je dio industrije i naravno nema nikakve veze s damama na modnim pistama.
Ono što sam želio reći, jer ono što inače radimo, ja i Dez razgovaramo o različitim stvarima i samo sam mislio da ću dati opći pregled modeliranju, ali realnost je to, to sada postaje očito.
Imamo stvarnost velikih podataka, imamo više podataka, više izvora podataka, imamo tokove podataka koji su ušli u jednadžbu u posljednje tri ili četiri godine i počinje dobivati veći dio toga, postoji veća potreba za razumijevanjem podataka i porast stope promjene koja se dodaje, a također se koristi i više podataka.
To je težak svijet. Evo slike, koja je zapravo nešto što smo nacrtali prije tri godine, ali u osnovi, nakon što uključite streaming u miks i dobijete tu ideju o rafineriji podataka, čvorištu podataka, podatkovnoj vezi ili bilo čemu drugom, vidjet ćete da postoje podaci koji su istinski u mirovanju, u smislu da se ne kreće puno. A tu su podaci, tokovi i dobili ste svu transakcijsku aplikaciju, plus danas imate događaje, tokove podataka o događajima koji se događaju u aplikacijama i možda će trebati, a danas s lambda arhitekturama o kojima svi pričaju, zaista su ima utjecaja na samo cijelo polje podataka.
A danas razmišljamo u smislu postojanja podatkovnog sloja. Sloj podataka postoji na neki virtualni način, u smislu da dobar dio toga može biti u oblaku i može se širiti po podatkovnim centrima, može postojati i na radnim stanicama. Sloj podataka je, u određenoj mjeri, svugdje i u tom smislu se svugdje odvijaju procesi koji pokušavaju na jedan ili drugi način obraditi podatke i pomicati podatke. Ali i znati što je to kad se krećeš, velika je stvar.
Ako promatramo modeliranje podataka u najopćenitijem smislu, na dnu ove vrste snopaka imate datoteke i baze podataka. Imate elemente podataka koji imaju ključeve, definicije elemenata, pseudonimere, sinonime, specifične fizičke formate i tada imamo ovaj sloj metapodataka.
Zanimljivost metapodataka jest ta što metapodaci u cijelosti dobivaju na značenju podataka. Ako zapravo nemate metapodatke, onda u najboljem slučaju možete pogoditi značenje podataka, ali imat ćete ogromne poteškoće. Metapodaci trebaju biti tamo, ali značenje ima strukturu. Ne želim se upuštati u filozofiju značenja, ali čak i u načinu na koji obrađujemo podatke, postoji puno sofisticiranosti ljudske misli i ljudskog jezika, što se u podacima ne može lako izraziti. Ali čak i u pogledu podataka koje mi zapravo obrađujemo u svijetu, metapodaci imaju značenje i strukturu metapodataka - jedan podatak u odnosu na drugi i što to znači kada se sastave, a što to znači kada se ' pridružen ostalim podacima, zahtijeva da ga modeliramo. Nije dovoljno samo snimiti metapodatke u stvari, zapravo morate zabilježiti značenje po strukturama i odnos između struktura.
Zatim imamo na gornjem sloju poslovne definicije, što je obično sloj koji pokušava prijenos značenja između metapodataka, što je oblik definiranja podataka koji odgovara načinu organiziranja podataka na računalu i ljudskom značenju. Dakle, imate poslovne izraze, definicije, odnose, koncepte na razini entiteta koji postoje u tom sloju. A ako ćemo imati neusklađenost tih slojeva, tada moramo imati modeliranje podataka. To zapravo nije opcionalno. Što više možete to učiniti u smislu automatizacije, to bolje. Ali budući da je to povezano sa značenjem, zaista je teško alternativno. Dovoljno je lako uhvatiti metapodate u zapisu i moći ga dobiti iz niza značenja, ali ne govori vam o strukturi zapisa, niti onome što zapisi znače ili kontekstu zapisa.
Dakle, po mom mišljenju se radi o modeliranju podataka. Bilješke: što složeniji svemir podataka postaje, to ćete ga više morati modelirati. Drugim riječima, pomalo je kao da u svijet dodajemo ne samo više primjera stvari, što bi odgovaralo zapisima podataka, već zapravo svijetu dajemo više značenja, hvatajući podatke o sve više stvari. Postaje sve složeniji osjećaj koji moramo razumjeti.
Teoretski postoji svemir podataka i potreban nam je prikaz. U praksi su stvarni metapodaci dio svemira podataka. Dakle, nije jednostavna situacija. Modeliranje na početku je odozgo prema dolje i odozdo prema gore. Morate graditi u oba smjera, a razlog za to je da podaci imaju značenje za računalo i postupak koji to moraju obraditi, ali to ima značenje samo po sebi. Dakle, potrebno vam je značenje odozdo prema gore, koje zadovoljava softver koji mora pristupati podacima, a treba vam značenje odozdo prema gore kako bi ga ljudi mogli razumjeti. Izrada modela metapodataka nije i nikada ne može biti projekt; to je aktivnost koja je u tijeku - trebala bi biti kontinuirana aktivnost u svakom okruženju koje postoji. Srećom, postoji puno okruženja u kojima to zapravo nije slučaj i stvari prolaze van kontrole.
Naprijed, modeliranje postaje sve važnije kako tehnologija napreduje. To je moje mišljenje. Ali ako pogledate IoT, mobitel možemo razumjeti više nego što smo navikli, iako je uveo nove dimenzije: dimenziju lokacije s mobilnim uređajem. Jednom kada dođete do IoT-a, promatramo izvanredne probleme s podacima koje nikada prije nismo trebali učiniti i trebamo, na jedan ili drugi način, da ispravno razumijemo što imamo, tačno kako to možemo objediniti, što možemo učiniti u smislu dobivanja značenja od združivanja i, naravno, što možemo s njim kad ga obradimo.
Mislim da sam to rekao dovoljno. Prelazim na Dez Blanchfield koji će u cijelosti reći nešto drugo.
Dez Blanchfield: Hvala. Uvijek težak čin koji treba slijediti, ali ovo je tema o kojoj smo se dogovorili i o tome smo kratko govorili u pretprodaji predgovora, a ako nazovete rano, vjerojatno biste uhvatili čitavu gomilu sjajnih dragulja. Jedan od poduhvata i ne želim ukrasti grmljavinu ovog posebnog, ali jedan od postupaka s našeg oštrog pretpisa koji želim podijeliti, u slučaju da ga niste uhvatili, bio je samo oko teme putovanje podataka i pogodilo me to što sam ga zapravo zapisao razmišljajući o putovanju koje podaci poduzimaju u različitom kontekstu oko generacijskog vijeka - godina, mjeseci, tjedna, dana, sata, minute, sekunde - a kontekst oko podataka je pozicioniran u tom kontekstu. Bilo da sam programer koji radi na šifri, ili da li sam stručnjak za podatke i razmišljam o strukturi i formatu i metapodacima oko svakog od elemenata ili načinu na koji sustavi i poslovanje međusobno djeluju.
To je zanimljivo malo poduzeće samo za napomenu, ali svejedno, dopustite mi da uđem. Konkretni dizajn podataka fraza je koju koristim za razgovor o svim stvarima i konkretno razvoju bilo aplikacija ili baze podataka. Mislim da je dizajn podataka izraz koji jednostavno sve to bilježi u mom umu. Ovih dana kada govorimo o dizajnu podataka, govorimo o modernom agilnom dizajnu podataka, a moje je mišljenje da nije tako davno bilo da su programeri i stručnjaci za podatke radili sami; bili su u vlastitim silosima i komadi dizajna prelazili su iz jednog silosa u drugi. Ali danas sam vrlo stava da ne samo da je slučaj koji se mijenja, nego se mora promijeniti; to je vrsta potrebe i to je ta aplikacija - programeri i bilo što što se može učiniti oko razvoja koji se bavi podacima, dizajneri koji rade relevantne elemente dizajna shema i polja i zapisa te sustave i infrastrukture i lokacije i baze podataka, modeliranje i cjelokupno upravljanje izazov oko toga. To je sada momčadski sport i otuda moja slika hrpe ljudi koji iskaču iz aviona koji djeluje kao tim koji će igrati tu vizualno zanimljivu sliku ljudi koji padaju u nebo.
Treće, što se dogodilo zbog toga? Pa, tu je članak iz 1986. godine napisao par gospode čija sam imena očajnički pokušavao praviti, Hirotaka Takeuchi i Ikujiro Nonaka, mislim da se to izgovara, proizveli članak pod naslovom "Pomicanje zalogaja dolje". Uveli su ideja o metodologiji pobjede u ragbiju koja dolazi od ove aktivnosti Scruma, gdje se svi kreću na jednom mjestu, a dva tima uglavnom zaključavaju glave u nečemu što se zove scrum da bi pokušali steći kontrolu nad loptom i igrati je niz polje da bi doći do linije za pokušaj i dodirnuti zemlju loptom i dobiti bod, nazvan trina, i ponovite ovaj postupak i dobit ćete više bodova za tim.
Ovaj je članak objavljen 1986. u časopisu Harvard Business Review, a znatiželjno je zapravo dobio puno pozornosti. Privukla je veliku pažnju jer je uvela nevjerojatne nove koncepte i evo vam je snimka zaslona s prednje strane. Stoga su ovaj koncept Scruma izvukli iz igre u ragbiju i unijeli ga u posao, posebno u igru dizajna i izvedbe projekata, konkretno isporuku projekata.
Ono što je Scrum učinio bilo nam je davanje nove metodologije u odnosu na slične PRINCE2 ili PMBOK koje smo prethodno koristili u onome što smo zvali metodologija vodopada, znate, napravite ovo i ovu stvar i ovu stvar i slijedite ih u slijedu i povežite se sve točke oko, što ovisi o tome što ste imali, ili ne radite drugi dio dok niste napravili prvi dio, jer je ovisilo o prvom dijelu. Ono što nam je pružilo je nova metodologija da budemo malo fleksibilniji, odakle i dolazi pojam, o načinu na koji isporučujemo stvari, a konkretno oko dizajna i razvoja širokog ustroja projekata.
Neki od ključnih stanara - upravo tako i nastavim s tim - su oko ključnih stanara smeća. Uvela je ideju o izgradnji nestabilnosti, da učinkovito ako razmišljate o strahu od kaosa, svijet postoji u stanju kaosa, ali planeta se formirala, što je zanimljivo, pa izgradite nestabilnost, sposobnost da se malo poskočite i i dalje čine stvari funkcioniranjem, samoorganiziranjem projektnih timova, preklapanjem favorita kroz vrlo odgovoran razvoj, različitim vrstama učenja i kontrole kroz put realizacije projekta, organizacijskog prijenosa učenja. Pa kako preuzeti podatke iz jednog dijela poslovanja i prenijeti ih u drugi od ljudi koji imaju ideju, ali ne razvijaju kod ili ne razvijaju baze podataka i infrastrukturu, već podatke tim ljudima? A konkretno vremenski zaključeni rezultati. Drugim riječima, učinimo to kroz neko vremensko razdoblje, bilo na dan kao u 24 sata, ili tjedan ili nekoliko tjedana i vidjeti što možemo učiniti, a zatim se povučemo i pogledamo.
I tako, ako oprostite punku, ovo je stvarno nova igra u izvođenju projekata i tri glavne komponente koje će imati smisla dok malo dalje napredujemo ovdje - tu je proizvod: svi ti ljudi imaju ideju i imaju potreba da se nešto postigne i priča koja ih okružuje. Programeri koji djeluju u okretnom modelu dobivanja svojih priča i svakodnevnim prikazivanjima koriste scrum metodologiju da bi raspravljali o tome i razumjeli što trebaju učiniti, a onda samo nastavite i radite. Tada smo ljudi čuli za majstore izopačenja koji nadgledaju cijelu ovu stvar i razumiju metodologiju dovoljno dobro da je pokrenu. Svi smo vidjeli ove slike koje sam dobio s desne strane ovdje zidova i ploča punih Post-It bilješki, a služile su kao Kanban zidovi. Ako ne znate tko je Kanban, pozivam vas na Google tko je bio gospodin Kanban i zašto je to bila promjena u načinu na koji premještamo stvari s jedne strane na drugu u zidu doslovno, ali u projektu.
Na prvi pogled to radi ovako: uzima popis stvari koje organizacija želi učiniti, provodi ih kroz niz stvari koje nazivamo sprintovima koji su raščlanjeni na razdoblja od 24 sata, mjesečeve mjesece, a mi dobiti ovu inkrementalnu seriju rezultata. Značajna je promjena u načinu isporuke projekata, isporučenih do te faze, jer dio toga teče poput američke vojske koja je u velikom dijelu razvijala nešto što se zove PMBOK, poput ideje da tenk ne izvedu u teren dok ne ubacujete metke u stvar, jer ako tenk u polju nema metaka, to je beskorisno. Dakle, jedan dio je stavio metke u tenk, drugi dio je stavio tenk u polje. Nažalost, ipak, ono što se dogodilo s programerima u razvojnom svijetu nekako se uhvatilo ove agilne metodologije i istrčalo s njom iz stana, ako se oprostiš s punicom, na sprintu.
Neizbježno je ono što se dogodilo, kad pomislimo na agilnost, obično mislimo na programere, a ne na baze podataka i bilo kakve veze sa svijetom baza podataka. Bio je to nesretan ishod, jer je stvarnost da okretnost nije ograničena samo na programere. U stvari, po mom mišljenju pojam agilni često je pogrešno povezan isključivo s programerima softvera, a ne dizajnerima baza podataka i arhitektima. Neizbježno su isti izazovi s kojima se suočavate u razvoju softvera i aplikacija u svemu povezan s dizajnom i razvojem, radom i održavanjem, a samim tim i sa podatkovnom infrastrukturom, posebno s bazama podataka. Sudionici u ovom posebnom unosu podataka uključuju simpatije arhitekata podataka, izrađivača, administratora, menadžera infrastrukture baza podataka i samih baza podataka sve do poslovnih analitičara i arhitekata, ljudi koji sjede i razmišljaju o tome kako sustavi i posluju te kako smo došli do protoka podataka kroz njih.
To je tema koju redovito postavljam, jer je moja stalna muka zbog toga što ja smatram da stručnjaci za podatke moraju - a ne bi trebali - sada moraju biti intimno uključeni u svaku komponentu pružanja projekata, stvarno, posebno u razvoju. A da ne, tada zaista ne dajemo sebi najbolju šansu za dobar ishod. Često se moramo obratiti i razmišljati o tim stvarima jer postoji scenarij, dolazimo do aplikacije koja se izrađuje i otkrivamo da programeri nisu uvijek stručnjaci za podatke. Za rad s bazama podataka potrebno je vrlo specijalizirano znanje, posebno oko podataka, i izgrađuje iskustvo. Ne možete preko noći odmah postati guru baze podataka ili stručnjak za znanje podataka; to je često nešto što dolazi iz životnog iskustva i svakako s likovima dr. Robina Bloor-a iz emisije Code Today, koji je prilično bogato napisao knjigu.
U mnogim slučajevima - i to je nesretno, ali to je stvarnost - da postoje dva dijela ove kovanice, to jest da programeri softvera imaju svoje vlastite nesvjestice u pogledu stručnjaka za baze podataka i izgradili su vam potrebne vještine u modeliranju baza podataka, a razvoj modela je upravo onaj temeljno za inženjerstvo gurua o načinu na koji podaci dolaze i kako organizacija putovanja traje i na što bi trebao izgledati ili ne bi trebao izgledati ili je nesumnjivo to što se guta i razumijevanje da se to obično dobije u izvornim vještinama postavljenim za programere softvera. Neki od uobičajenih izazova s kojima se suočavamo, samo da bismo to stavili u kontekst, uključuju jednostavno osnovno stvaranje i održavanje i upravljanje samim dizajnom jezgre baze podataka, dokumentiranje podataka i infrastrukture baze podataka, a zatim ponovno korištenje tih podataka, nacrte shema, generacije shema, administriranje i održavanje sheme i njihova upotreba, razmjena znanja o tome zašto je ta shema dizajnirana na određeni način, a snage i slabosti koje dolaze s tim tijekom vremena uzrokuju promjene podataka tijekom vremena, modeliranje podataka i vrste modela koje primjenjujemo na sustave i podatke koje prenosimo kroz njih. Generiranje koda baze podataka i ide na integraciju, a zatim modeliraju podatke oko njih, a zatim brži pristup kontroli sigurnosti oko podataka, integritet podataka, mi se krećemo podacima oko nas dok zadržavamo njihov integritet, postoji li dovoljno metapodataka Da li bi prodaja trebala vidjeti sve zapise u tablici ili trebaju vidjeti samo adresu, ime i prezime koje vam šalju stvari u postu? A onda je, naravno, najveći izazov sve to modeliranje platformi baza podataka koje je samo po sebi različit razgovor.
Jako sam mišljenja da je, imajući sve to u vidu da se omogući bilo koja od ovih nirvana, apsolutno kritično da i stručnjaci za podatke i programeri imaju odgovarajuće alate i da ti alati mogu biti sposobni za timski fokusiranje projekata, dizajn, razvoj i tekuće operativno održavanje. Znate, stvari poput suradnje u projektima između stručnjaka za podatke i razvojnih programera, jedinstvena točka istine ili jedinstveni izvor istine za sve stvari oko dokumentacije samih baza podataka, podataka, shema odakle potječu zapisi, vlasnici tih zapisa, Mislim da je u današnje doba i to apsolutno kritično. Nabavit ćemo ovu nirvanu podataka da smo kralj, da moraju postojati pravi alati, jer je sada izazov prevelik za nas da to možemo učiniti ručno, i ako ljudi premještati se i izlaziti iz jedne organizacije, previše je lako da ne bismo slijedili isti postupak ili metodologiju koje bi jedna osoba mogla postaviti dobro, a ne nužno prenijeti one vještine i sposobnosti koje idu naprijed.
Imajući to na umu, uputit ću se do našeg dobrog prijatelja iz IDERA i čuti za taj alat i kako se bavi tim stvarima.
Ron Huizenga: Puno hvala i Robinu i Dezu što su zaista dobro postavili pozornicu, a vi ćete vidjeti malo preklapanja u nekoliko stvari o kojima sam govorio. Ali oni su zaista postavili vrlo solidne temelje za neke koncepte o kojima ću govoriti iz perspektive modeliranja podataka. I puno toga što su rekli odjekuje iz mog vlastitog iskustva kad sam bio savjetnik koji se bavio modeliranjem podataka i arhitekturom podataka, zajedno s timovima - i vodopad u ranim danima i evoluirajući u modernije proizvode s projektima gdje smo koristili okretnost metodologije za isporuku rješenja.
Dakle, ono o čemu ću danas govoriti temelji se na tim iskustvima, kao i na pogledu alata i nekih mogućnosti u alatima koje koristimo da nam pomognu na tom putu. Ono što ću kratko opisati jest da neću ulaziti u detalje mnogo detalja; samo smo imali stvarno dobar pregled onoga što je to. Govorit ću o tome u smislu, što je model podataka i što nam to zapravo znači? I kako omogućiti koncept agilnog modelera podataka u našim organizacijama, u smislu, kako angažirati modelere podataka, kakvo je sudjelovanje modelara i arhitekata tijekom sprinta, koje su vrste aktivnosti kojima bi se trebali baviti, i, kao pozadina toga, koje su neke od važnih mogućnosti alata za modeliranje koje koristimo da stvarno pomognu u olakšanju tog posla? Zatim ću se malo pozabaviti i samo malo porazgovarati o nekim poslovnim vrijednostima i prednostima uključivanja modele podataka, ili o načinu na koji ću zapravo ispričati priču, problemi s nedostatkom data modelera u potpunosti uključenim u projekte, a pokazat ću vam da se temelje na iskustvu i nedostatku slike stvarnog projekta prije i poslije stvarnog projekta s kojim sam sudjelovao prije mnogo godina. A onda ćemo sažeti još nekoliko točaka, a zatim ćemo uz to imati pitanja i odgovore.
Ukratko, ER Studio je vrlo moćan paket koji u sebi sadrži puno različitih komponenti. Arhitekt podataka, gdje modelirači podataka i arhitekti provode većinu svog vremena radeći na modeliranju podataka. Postoje i druge komponente o kojima danas uopće nećemo razgovarati, poput Business Architect-a, gdje radimo modeliranje procesa i Software Architect, za neke od UML modeliranja. Zatim je tu Repozitorij, gdje se prijavljujemo i dijelimo modele i dopuštamo timovima da surađuju na njima i objavljujemo ih na timskom poslužitelju tako da više zainteresiranih publika koje su angažirane na projektu zapravo mogu vidjeti artefakte koje imamo ' kreiramo iz podatkovne perspektive kao i ostale stvari koje radimo u samoj isporuci projekta.
Ono na što ću se danas fokusirati bit će nekoliko stvari koje ćemo vidjeti iz Data Architecta i zato što je zaista važno da imamo suradnju s aspektima skladišta koji se temelje na skladištu. Kad počnemo govoriti o konceptima poput upravljanja promjenama, koji su neophodni, ne samo agilni razvojni projekti, već i bilo kakav razvoj koji ide naprijed.
Pa razgovarajmo na trenutak o Agile Data Modeleru. Kao što smo i ranije aludirali na prezentaciju, da je neophodno da imamo modele podataka i / ili arhitekte koji su potpuno uključeni u napredne razvojne procese. Sada, ono što se povijesno dogodilo jest, da, stvarno smo razmišljali o okretnom s razvojne perspektive, a postoje i par stvari koje su i nastale zbog toga su i nastale. Dio je to bio posljedica samo prirode načina na koji se odvijao sam razvoj. Kako je započeo agilni razvoj i započeli smo s tim konceptom samoorganizirajućih timova, ako ste popili Kool-Aid malo previše čisto i bili ste na strani ekstremne programske strane, postojalo je vrlo doslovno tumačenje stvari poput samoorganizirajući timovi, što je puno ljudi protumačilo da znači, sve što trebamo je grupa programera koja može izgraditi cijelo rješenje. Bilo da to znači razvoj koda, baze podataka ili baze podataka iza njega i sve je prebačeno programerima. Ali s onim što se događa je da izgubite na posebnim sposobnostima koje ljudi imaju. Otkrio sam da su najjači timovi oni koji su sastavljeni od ljudi različitog porijekla. Kao što je kombinacija snažnih programera softvera, arhitekata podataka, modelara podataka, poslovnih analitičara i poslovnih dionika, a svi zajedno surađuju kako bi postigli krajnje rješenje.
Ono o čemu danas također govorim jest da ću to učiniti u kontekstu razvojnog projekta u kojem razvijamo aplikaciju za koju će očito biti povezana i podatkovna komponenta. Moramo napraviti korak unatrag prije nego što to učinimo, jer moramo shvatiti da je vani vrlo malo projekata za razvoj Greenfield-a gdje smo posvećeni usredotočenju na stvaranje i potrošnju podataka koji su ograničeni samo unutar samog tog razvojnog projekta., Moramo napraviti korak unatrag i sagledati cjelokupno organizacijsko stajalište iz podatkovne perspektive i procesne perspektive. Jer ono što smo saznali su informacije koje koristimo već postoje negdje u organizacijama. Kao modelatori i arhitekti to objavljujemo kako bismo znali odakle izvoriti te podatke u samim projektima. Također znamo strukture podataka koje su uključene jer imamo modele dizajna baš kao što programeri imaju modele dizajna za svoj kod. A također moramo zauzeti tu ukupnu organizacijsku perspektivu. Ne možemo samo gledati podatke u kontekstu aplikacije koju gradimo. Moramo modelirati podatke i osigurati da ih dokumentiramo jer žive dugo izvan samih aplikacija. Te aplikacije dolaze i odlaze, ali moramo biti u mogućnosti pogledati podatke i biti sigurni da su robusni i dobro strukturirani, ne samo za primjenu, već i za odluke koje prijavljuju aktivnosti, BI izvješćivanje i integraciju u druge aplikacije, interne i interne eksterno i za naše organizacije. Stoga moramo sagledati cijelu ovu veliku sliku podataka i kakav je životni ciklus tih podataka, te razumjeti putovanje informacija kroz organizaciju od kolijevke do groba.
Vratimo se samim timima i kako zapravo trebamo raditi, metodologija vodopada je shvaćena kao prespora za postizanje rezultata. Jer, kao što je istaknuto primjerom tenka, bio je to korak za drugim i često je trajalo predugo da bi se dobili izvediv krajnji rezultat. Ono što sada radimo je da moramo imati iterativni stil rada gdje postupno razvijamo njegove sastavne dijelove i razrađujemo ga kroz vrijeme gdje izrađujemo upotrebljiv kod ili korisne artefakte, reći ću, za svaki sprint. Važna stvar je suradnja između tehničkih dionika u timu i poslovnih dionika jer surađujemo kako bismo te korisničke priče pretočili u implementacijsku viziju koda i podataka koji podržavaju taj kôd. I sam Agile Data Modeler često će utvrditi da nemamo dovoljno modelara u organizacijama, tako da jedan modelar podataka ili arhitekt istovremeno može podržati više timova.
A drugi aspekt toga je, čak i ako imamo više modelara, moramo osigurati da imamo set alata koji koristimo koji omogućava suradnju više projekata koji su u letu istovremeno i dijeljenje istih artefakti podataka i mogućnosti prijave i odjave. To ću vrlo brzo prijeći jer smo to već objavili u prethodnom odjeljku. Stvarna pretpostavka agilnosti je da stvari temeljiš na zaostatku, pričama ili zahtjevima. U okviru iteracija surađujemo kao grupa. Obično je dvotjedni ili jednomjesečni šprint, ovisno o organizaciji, vrlo čest. A također i svakodnevne preglede i sastanke u pripravnom stanju, tako da uklanjamo blokatore i osiguravamo da pomičemo sve aspekte naprijed bez zaustavljanja u različitim područjima kroz koja prolazimo. I u tim sprintovima želimo biti sigurni da proizvodimo korisne ispise kao dio svakog sprinta.
Samo malo drukčije shvaćam to, proširujući ga dalje, scrum je metodologija o kojoj ću ovdje detaljnije govoriti, a tu smo sliku u osnovi nadogradili s još nekoliko aspekata. Obično postoje zaostaci za proizvodom, a zatim i zaporci za sprint. Dakle, imamo sveukupni zaostatak koji se na početku svakog ponovnog sprinta ponavljamo i kažemo: "Što ćemo stvarati ovaj sprint?", A to je učinjeno na sastanku planiranja sprinta. Zatim raščlanjujemo zadatke koji su povezani s tim i vršimo u tim tjednima do četiri tjedna s tim dnevnim pregledima. Dok radimo to, pratimo svoj napredak putem pregazivnih i gorućih grafikona kako bismo u osnovi pratili ono što preostaje za izgradnju nasuprot onome što gradimo da bismo uspostavili stvari poput onoga što je brzina našeg razvoja, hoćemo li napraviti naš raspored, sve te vrste stvari. Svi se oni razrađuju kontinuirano tijekom sprinta, a ne da krenete nekoliko mjeseci niz cestu i otkrijete da ćete uskoro stići i trebate produžiti raspored projekta. I vrlo je važno, kao dio toga, čitavi timovi, na kraju je pregled sprinta i retrospektiva sprinta, pa prije nego što započnete sljedeću iteraciju pregledavate što ste napravili i tražite načine na koje to možete poboljšati se sljedeći put.
Što se tiče rezultata, ovo je u osnovi dijapozitiv koji sažima tipične vrste stvari koje se događaju u sprinterima. I to je vrlo usmjereno na razvoj, tako da puno stvari koje ovdje vidimo, poput funkcionalnih dizajna i slučajeva, radeći testove dizajnerskog koda, kad pogledamo ove okvire ovdje, i neću ih prolaziti u bilo kojoj razini detalja usmjereni su na razvoj. I ispod ovoga je pokopana činjenica da također moramo imati one podatke koji će ići ruku pod ruku s tim kako bismo podržali ovaj napor. Dakle, svaki put kada vidimo stvari poput zaostataka, zahtjeva i korisničkih priča, dok prolazimo moramo pogledati koji su razvojni dijelovi koje moramo napraviti, koji su dijelovi analize koje trebamo učiniti, kako o dizajn podataka ili podatkovni model, što je s poslovnim pojmovnicima kako bismo poslovno značenje mogli povezati sa svim artefaktima koje proizvodimo? Jer trebamo proizvesti one korisne rezultate u svakom sprintu.
Neki će ljudi reći da moramo proizvesti korisni kod na kraju svakog sprinta. To nije nužno slučaj, to je u najčišćoj razvojnoj perspektivi, ali prilično često - posebno na početku - možemo imati nešto poput nulte sprinta gdje smo čisto fokusirani na stojeće stvari, radeći stvari poput pronalaženja svojih testnih strategija u mjesto. Dizajn na visokoj razini kako bismo ga započeli prije nego što počnemo ispunjavati detalje i osigurati da imamo čist niz početnih priča ili zahtjeva prije nego što započnemo angažirati drugu publiku, a zatim gradimo naprijed kao tim kako idemo naprijed. Uvijek ima malo vremena za pripremanje, tako da ćemo vrlo često imati sprintersku nulu ili čak sprint nulu i jedan. Može biti malo pokretačka faza prije nego što postignemo cjelovit let u pružanju rješenja.
Razgovarajmo o modelima podataka u ovom kontekstu vrlo kratko. Kad ljudi razmišljaju o modelima podataka, često smatraju da je podatkovni model slika slike spajanja različitih podataka - to je samo vrh ledenog brijega. Da biste u potpunosti utjelovio duh načina na koji stvarno želite pristupiti modeliranju podataka - bilo da je u agilnom razvoju i drugim stvarima - trebate li shvatiti da model podataka, ako se pravilno radi, postaje vaša puna specifikacija za to što ti podaci znače u organizaciji i kako se implementira u pozadinskim bazama podataka. Kad kažem baze podataka, mislim ne samo na relacijske baze podataka koje možda koristimo, već na današnje arhitekture u kojima imamo velike podatkovne ili NoSQL platforme, kako ih radije nazivam. Također one velike prodavaonice podataka jer možda kombiniramo puno različitih spremišta podataka u smislu konzumiranja informacija i njihovog unošenja u naša rješenja, kao i načina na koji uporno ili spremamo te podatke i iz naših rješenja.
Možda radimo s više baza podataka ili izvora podataka istovremeno u kontekstu određene aplikacije. Ono što je vrlo važno jest da želimo imati punu specifikaciju, pa logična specifikacija šta to znači sprint organizacijske perspektive, kakvi su fizički konstrukti u smislu kako mi zapravo definiramo podatke, odnose između njih u vaše baze podataka, vaša referentna ograničenja integriteta, provjerite ograničenja, sve one dijelove provjere valjanosti o kojima obično razmišljate. Opisni metapodaci izuzetno su važni. Kako znate kako koristiti podatke u svojim aplikacijama? Ako ga ne možete definirati i znati što to znači ili znati odakle su došli da biste bili sigurni da trošite ispravne podatke u tim aplikacijama - pri tome budite sigurni da imamo ispravne konvencije o imenovanju, potpune definicije, što znači i cjelovit rječnik podataka ne samo tablice, ali stupci koji sadrže te tablice - i detaljne napomene o primjeni načina na koji ih koristimo jer trebamo izgraditi bazu znanja jer će se i kad se napravi ova aplikacija koristiti za druge inicijative, tako da moramo biti sigurni da imamo sve to dokumentirano za buduće implementacije.
Opet se svodimo na stvari poput tipova podataka, ključeva, indeksa, sam podatkovni model utjelovljuje mnoga poslovna pravila koja se primjenjuju. Odnosi nisu samo ograničenja između različitih tablica; često nam pomažu da opišemo koja su prava poslovna pravila oko toga kako se ti podaci ponašaju i kako djeluju zajedno kao kohezivna jedinica. I naravno, vrijednosna ograničenja su vrlo važna. Naravno, jedna od stvari s kojom se stalno bavimo, a koja postaje sve prisutnija, jesu stvari poput upravljanja podacima. Dakle, iz perspektive upravljanja podacima, također trebamo gledati, što ovdje definiramo? Želimo definirati stvari poput sigurnosnih klasifikacija. Kojim vrstama podataka imamo posla? Što će se smatrati glavnim upravljanjem podacima? Koje su transakcijske trgovine koje stvaramo? Koje referentne podatke koristimo u tim aplikacijama? Moramo se pobrinuti da se to pravilno prikupi u našim modelima. Uz pitanja u vezi s kvalitetom podataka, postoje podaci koji su za organizaciju važniji od ostalih.
Sudjelovao sam u projektima u kojima smo preko desetak naslijeđenih sustava zamijenili novim poslovnim procesima i dizajnirali nove aplikacije i prodavaonice podataka kako bi ih zamijenili. Morali smo znati odakle informacije dolaze. Što se tiče najvažnijih informacija, iz poslovne perspektive, ako pogledate dijapozitiv ovog posebnog modela podataka koji sam dobio ovdje, vidjet ćete da donji okviri u tim određenim entitetima, što je samo mali podskup, zapravo sam uspio uhvatiti poslovnu vrijednost. Bilo visoko, srednje ili nisko za ove vrste stvari za ove različite konstrukcije u organizaciji. Uhvatio sam i stvari poput matičnih klasa podataka, jesu li to matične tablice, jesu li referentne, jesu li bile transakcijske. Na taj način možemo proširiti svoje metapodate u našim modelima i dati nam puno drugih karakteristika izvan samih podataka, što nam je uistinu pomoglo u drugim inicijativama izvan izvornih projekata i prenošenju naprijed. Sad je bilo puno u jednom slajdu, ostatak ću ih brzo proći.
Sada ću vrlo brzo razgovarati o tome što radi modelar podataka dok prolazimo kroz ove različite sprintove. Prije svega, punopravni sudionik sestrinstva planiranja sprint-a, gdje vodimo korisničke priče, obvezajući se na ono što ćemo dostaviti u tom sprintu i smišljamo kako ćemo ga strukturirati i dostaviti. Ono što također radim kao modelar podataka jest da znam raditi na odvojenim područjima s različitim programerima ili s različitim ljudima. Dakle, jedna od važnih karakteristika koju možemo imati kada radimo model podataka, taj model podataka možemo podijeliti u različite poglede, bilo da ih nazivate predmetnim područjima ili pod-modelima, naša je terminologija. Kako gradimo model, prikazujemo ga i u raznim perspektivama pod-modela, tako da različita publika vidi samo ono što je za njih važno kako bi se mogli usredotočiti na ono što razvijaju i razvijaju. Tako da možda imam nekoga tko radi na zakazivanju dijela aplikacije, a možda bi netko drugi radio na unosu naloga gdje sve ove stvari radimo u jednom sprintu, ali mogu im dati stavove kroz one pod-modele koji samo odnose se na područje na kojem rade. A onda se oni prelaze u cjelokupni model i cijelu strukturu podmodela kako bi različitim gledateljima pružili pregled onoga što trebaju vidjeti.
Osnove iz perspektive modeliranja podataka koje želimo imati jest uvijek imati osnovnu liniju na koju se možemo vratiti jer jedna od stvari koje trebamo biti je da li je to na kraju sprinta ili na kraju od nekoliko sprintova, želimo znati odakle smo započeli i uvijek imamo početnu crtu da znamo koja je bila delta ili razlika onoga što smo proizveli u određenom sprintu. Moramo se pobrinuti da brzo uspijemo preokrenuti. Ako u njega uđete kao data modeler, ali u tradicionalnoj ulozi vratara da kažete "Ne, ne, ne možete to učiniti, prvo moramo sve ove stvari", bit ćete isključeni iz tima kada vam stvarno trebaju biti aktivan sudionik u svim tim agilnim razvojnim timovima. To znači da neke stvari padaju s vagona radeći određeni sprint i vi ih pokupite u kasnijim sprintovima.
Kao primjer, možete se usredotočiti na strukture podataka samo da bi se išlo u razvoj, recimo, onog dijela za unos naloga koji sam govorio. U kasnijem sprintu možete se vratiti i ispuniti podatke poput neke dokumentacije za rječnik podataka oko nekih artefakata koje ste stvorili. Nećete dovršiti tu definiciju sve u jednom sprintu; nastavit ćete postepeno pratiti svoje rezultate jer će postojati vremena kada te informacije možete nadopuniti radeći s poslovnim analitičarima kada su programeri zauzeti izgradnjom aplikacija i upornošću oko tih spremišta podataka. Želite olakšati, a ne biti usko grlo. Postoje različiti načini na koje radimo s programerima. Za neke stvari imamo uzorke dizajna, tako da smo unaprijed punopravni sudionik, tako da možda imamo dizajnerski uzorak gdje ćemo reći da ćemo ga staviti u model, izbacit ćemo ga u baze podataka programere, a zatim oni mogu započnite raditi s njom i zatražite promjene u tome.
Možda postoje druga područja na kojima programeri rade, dobili su nešto na čemu rade i prototipiraju neke stvari tako da neke stvari isprobavaju u vlastitom razvojnom okruženju. Uzimamo tu bazu podataka s kojom su radili, unosimo je u naš alat za modeliranje, uspoređujemo s modelima koje imamo, a zatim ih rješavamo i guramo promjene natrag kako bi mogli ponovno izraditi kodove tako da slijede odgovarajuće strukture podataka da nam treba. Jer su možda stvorili neke stvari koje smo već imali drugdje, pa se pobrinemo da rade s pravim izvorima podataka. Samo nastavljamo ponavljati sve do ovog našeg sprinta, tako da dobivamo cjelovitu dostavu podataka, potpunu dokumentaciju i definiciju svih onih podataka koje stvaramo.
Najuspješniji agilni projekti u koje sam sudjelovao u pogledu vrlo dobrih isporuka su: imali smo filozofiju, modelirali smo sve promjene u potpunoj specifikaciji fizičke baze podataka. U osnovi, model podataka postaje raspoređene baze podataka s kojima radite za sve novo što stvaramo i ima potpune reference drugih skladišta podataka ako ih konzumiramo iz drugih vanjskih baza podataka. Kao dio toga izrađujemo inkrementalne skripte nasuprot tome što svaki put radimo punu generaciju. I mi koristimo svoje dizajnerske obrasce da bi nam brzo pokrenuli stvari koje idu u sprintu s različitim razvojnim timovima s kojima radimo.
I u sprinterskim aktivnostima, opet je to osnovna vrijednost za usporedbu / spajanje, pa uzmimo ideju o modeliranju svake promjene. Svaki put kad učinimo promjenu, ono što želimo učiniti je da modeliramo promjenu, a ono što je vrlo važno, ono što je nedostajalo u modeliranju podataka donedavno, zapravo dok je nismo ponovo uveli, jeste mogućnost povezivanja modeliranja. zadacima i vašim rezultatima s korisničkim pričama i zadacima koji zapravo uzrokuju te promjene. Želimo biti u mogućnosti provjeriti promjene u našem modelu, isto kao što programeri provjeravaju u kodovima, referencirajući one korisničke priče koje imamo, tako da znamo zašto smo prvo napravili promjene, to je nešto što radimo. Kad to učinimo, generiramo naše inkrementalne DDL skripte i objavljujemo ih tako da se mogu odabrati s ostalim razvojnim rezultatima i provjeriti u našem rješenju za izgradnju. Opet, možda imamo jedan model ili rad s više timova. I kao što sam već govorio, neke stvari potiču od modera za podatke, druge stvari su stvorili programeri, a mi se u sredini sastajemo kako bismo osmislili najbolji dizajn i gurnuli ga naprijed i uvjerili se da je pravilno dizajniran u našem cjelokupne strukture podataka. Moramo održati disciplinu osiguravanja da imamo sve ispravne konstrukcije u našem modelu podataka dok napredujemo, uključujući stvari poput null, a ne null vrijednosti, referentna ograničenja, u osnovi provjere ograničenja, sve one stvari o kojima obično razmišljamo,
Razgovarajmo sada o nekoliko snimki zaslona nekih alata koji nam pomažu u tome. Ono što mislim da je važno jest posjedovanje zajedničkog spremišta, tako da ono što možemo učiniti kao modelirači podataka - a ovo je isječak dijela podatkovnog modela u pozadini - jest kada radimo na stvarima za koje želimo biti sigurni da možemo radimo samo na objektima koje trebamo moći mijenjati, unositi izmjene, generirati naše DDL skripte za promjene koje smo izvršili dok ponovno provjeravamo stvari. Dakle, ono što možemo učiniti je da u ER studiji primjer, možemo provjeriti predmete ili grupe objekata na kojima radimo, ne moramo provjeriti cijeli model ili pod-model, možemo provjeriti samo one stvari koje nas zanimaju. Ono što želimo nakon toga je ili odjava ili prijava - to radimo na oba načina jer različiti razvojni timovi rade na različite načine. Želimo biti sigurni da to povezujemo s korisničkom pričom ili zadatkom koji pokreće zahtjeve za to i to će biti ista korisnička priča ili zadatak koji programeri razvijaju i provjeravaju svoj kod.
Dakle, evo vrlo brzog isječka s nekoliko zaslona jednog od naših centara za upravljanje promjenama. Ovdje se nećemo baviti detaljno, ali ono što vi vidite je korisnička priča ili zadatak i razvedeno ispod svakog od onih kod kojih vidite stvarne zapise o promjenama - stvorili smo automatizirani zapis o promjenama kada vršimo prijavu i odjavu te možemo dodati još opisa na taj zapis promjena. Povezan je s zadatkom, možemo imati više promjena po zadatku, kao što biste očekivali. A kad uđemo u taj zapis promjena, možemo ga pogledati i što je još važnije vidjeti, što smo zapravo promijenili? Za ovu posebnu, istaknutu priču ondje sam izvršio jednu vrstu promjene i kad sam pogledao sam stvarni zapis o promjeni, identificirao je pojedine dijelove u modelu koji se promijenio. Ovdje sam promijenio nekoliko atributa, ponovno ih usporedio i to je za vožnju donijelo poglede koje je trebalo promijeniti, koji su ovisili i o njima, tako da će se oni generirati u inkrementalnom DLL-u. To nije samo modeliranje na osnovnim objektima, već i moćni alat za modeliranje poput ovog također otkriva promjene koje se moraju probiti kroz ovisne objekte u bazi podataka ili modelu podataka.
Ako radimo s programerima, a to radimo u nekoliko različitih stvari, radi nešto u njihovom pješčaniku i želimo usporediti i vidjeti gdje su razlike, koristimo mogućnosti usporedbe / spajanja gdje se nalaze s desne i lijeve strane strana. Možemo reći, "Evo našeg modela s lijeve strane, ovdje je njihova baza podataka s desne strane, pokažite mi razlike." Tada možemo odabrati i odabrati kako ćemo riješiti te razlike, bilo da uguramo stvari u bazu podataka ili ako postoje neke stvari koje se nalaze u bazi podataka koje vraćamo u model. Možemo ići dvosmjerno, tako da možemo ići u oba smjera istovremeno ažuriranjem i izvora i cilja, a zatim proizvesti inkrementalne skripte DDL-a za razmjenu tih promjena u samom okruženju baze podataka, što je izuzetno važno. Ono što također možemo učiniti je da također možemo upotrijebiti ovu mogućnost uspoređivanja i spajanja u bilo kojem trenutku, ako radimo snimke na putu, uvijek možemo usporediti početak jednog sprinta s početkom ili kraj drugog sprinta, tako da možemo vidjeti potpuna inkrementalna promjena onoga što je učinjeno u određenom razvojnom sprintu ili preko niza sprintova.
Ovo je vrlo brz primjer alter skripte, bilo tko od vas koji radi s bazama podataka vidjet će ovu vrstu stvari. To možemo izbaciti iz koda kao alter skriptu kako bismo bili sigurni da zadrži stvari ovdje. Ono što sam izvukao odavde, samo da bismo smanjili nered, je ono što radimo i s ovim alter skriptama, pretpostavljamo da postoje i podaci u tim tablicama, tako da ćemo generirati i DML koji će izvlačiti podatke o privremenim tablicama i vratimo ga u nove strukture podataka, tako da ne promatramo samo strukture, već i podatke koje smo možda već sadržavali u tim strukturama.
Vrlo brzo ćemo razgovarati o sustavima automatizirane gradnje jer kad radimo agilni projekt često radimo sa sustavima automatizirane gradnje gdje moramo zajedno provjeriti različite rezultate kako bismo bili sigurni da nećemo pokvariti svoje teškoće. To znači da sinkroniziramo rezultate, one skripte za promjene o kojima sam govorio sa DDL skriptu je potrebno provjeriti, odgovarajući aplikacijski kôd treba istovremeno prijaviti, a puno razvoja programera sada, naravno, nije. se izvodi s direktnim SQL-om protiv baza podataka i takve vrste. Često koristimo uporne okvire ili gradimo podatkovne usluge. Moramo biti sigurni da se izmjene tih okvira ili usluga prijavljuju u isto vrijeme. Ulaze u automatizirani sustav sastavljanja u nekim organizacijama i ako se konstrukcija pokvari, po agilnoj metodologiji, sve je stvar na popravljanju palube koja se gradi prije nego što krenemo naprijed, tako da znamo da imamo radno rješenje prije nego što nastavimo dalje. A jedan od projekata u kojima sam sudjelovao, to smo doveli do krajnosti - ako se sastav pokvario, zapravo smo bili priključeni na određena računala na našem području gdje smo bili raspoređeni s poslovnim korisnicima, imali smo crvene trepereće lampice samo poput vrha policijskih automobila. A ako se sastav pokvario, ona crvena bljeskajuća svjetla počela su se gasiti i znali smo da je sve u redu na palubi: popravite sklop i nastavite s onim što radimo.
Želim razgovarati o drugim stvarima, a ovo je jedinstvena sposobnost ER Studija, zaista pomaže kada pokušavamo izgraditi te artefakte kao programere za ove granice postojanosti, imamo koncept koji se naziva objektima poslovnih podataka i ono što nam omogućava Doista, ako ovaj primjer vrlo jednostavnih podataka shvatite kao primjer, omogućava nam da objedinimo entitete ili grupe entiteta za one gdje su granice postojanosti. Tamo gdje mi kao moderator podataka možemo razmišljati o nečemu poput zaglavlja naloga za kupnju i usklađivanja narudžbi i drugih detaljnih tablica koje bi se uklopile u način na koji je gradimo, a naši programeri za podatkovne usluge moraju znati kako stvari i dalje postoje do tih različitih podataka strukture. Naši programeri razmišljaju o stvarima poput narudžbenice kao objekta u cjelini i kakav je njihov ugovor s načinom izrade tih određenih objekata. Možemo izložiti taj tehnički detalj tako da ljudi koji grade poslužitelje podataka mogu vidjeti što se nalazi ispod njega, a ostale publike možemo zaštititi od složenosti tako da samo vide različite objekte više razine, što također vrlo dobro funkcionira za komunikaciju s tvrtkom analitičari i poslovni dionici kada govorimo i o interakciji različitih poslovnih koncepata.
Dobra stvar je u tome što ih konstruktivno proširujemo i urušavamo tako da možemo održavati odnose između objekata višeg reda iako potječu od konstrukcija koje su sadržane u samim tim poslovnim podacima. Sada kao manekenka, dođite do kraja sprint-a, na kraju sprint wrap-up-a, imam puno stvari koje trebam učiniti, što za sljedeći sprint zovem vođenjem kuće. Svaki sprint koji stvorim ono što zovem Named Release - to mi daje osnovnu vrijednost za ono što sada imam na kraju izlaska. Dakle, to znači da moja osnovna linija ide prema naprijed, sve ove osnovne linije ili Named Release koje stvorim i spremim u svoje spremište pomoću kojih mogu napraviti usporedbu / spajanje tako da se uvijek mogu usporediti s bilo kojim danom kraj sprinta iz bilo kojeg drugog sprint-a, koji vrlo je važno znati koje su vaše promjene u modelu podataka bile na putu kroz njegovo putovanje.
Također stvaram delta DDL skriptu koristeći ponovo usporedbu / spajanje od početka do kraja sprinta. Možda sam provjerio u hrpi inkrementalnih skripti, ali ako mi zatreba, sada imam skriptu koju mogu implementirati u druge pješčanike, pa mogu samo reći da smo to imali na početku jednog sprinta, push to kroz, izgraditi bazu podataka kao kutija za pijesak da biste započeli sa sljedećim sprinta, a možemo ih koristiti i za stvari poput standup QA instanci i na kraju, naravno da želimo gurnuti naše promjene u proizvodnju, tako da imamo više stvari u isto vrijeme. Opet, u potpunosti sudjelujemo u planiranju sprint-a i retrospektivama, retrospektive su zaista naučene lekcije i to je izuzetno važno, jer tijekom agilnog kretanja možete krenuti vrlo brzo, morate se zaustaviti i proslaviti uspjehe, kao i sada. Otkrijte što nije u redu, sljedeći put budite bolji, ali također proslavite stvari koje su krenule po redu i nadograđujte ih dok nastavite krenuti prema naprijed u sljedećim sprinterima.
Sada ću vrlo brzo razgovarati o vrijednosti poslovanja. Bio je projekt u koji sam se uključio prije mnogo godina koji je započeo kao agilni projekt, i bio je to ekstremni projekt, pa je to bio čisti samoorganizirajući tim u kojem su upravo programeri radili sve. Da skratim, ovaj je projekt zastao i otkrili su da sve više i više puta troše na saniranje i ispravljanje utvrđenih nedostataka nego što su isticali više funkcionalnosti i, zapravo, kada su gledali na to na temelju na izgaranim ljestvicama trebali su produžiti projekt šest mjeseci uz ogromne troškove. A kad smo ga pogledali, problem za uklanjanje problema bio je korištenje ispravnog alata za modeliranje podataka s kvalificiranim modelom podataka koji je uključen u sam projekt.
Ako pogledate ovu okomitu traku na ovom određenom grafikonu, to pokazuje kumulativne nedostatke nasuprot kumulativnim objektima, a ja govorim o objektima podataka ili konstrukcijama koje su stvorene, poput tablica s ograničenjima i onih vrsta stvari, ako pogledate prije uvođenja modera podataka broj oštećenja je zapravo premašio i počeo je stvarati jaz između stvarnog broja objekata koji su proizvedeni do tog trenutka. Nakon što je 21. tjedan, kad je data modeler, ponovo napravio faktorski model na temelju onoga što je trebalo popraviti niz stvari, a zatim počeo modelirati kao dio projektnog tima koji ide prema naprijed, promjene koje su taj projekt gurale naprijed, I vidjeli ste vrlo brz zaokret da smo unutar otprilike sprinta i pol vidjeli ogroman napredak u broju objekata i konstrukcija podataka koji se generiraju i izrađuju jer smo generirali iz alata za modeliranje podataka, a ne od strane programera gradeći ih u okruženju, i bili su ispravni jer su imali odgovarajući referentni integritet i ostale konstrukte koje bi trebao imati. Razina nedostataka u odnosu na one gotovo ravna. Poduzimanjem odgovarajućih aktivnosti i osiguravanjem da je modeliranje podataka u potpunosti uključeno projekt je izveden na vrijeme s mnogo višom razinom kvalitete, a u stvari uopće se ne bi isporučio da se ti koraci nisu poduzeli. Puno je agilnih neuspjeha, ima i puno okretnih uspjeha ako biste u svoje uloge uključili prave ljude. Ja sam veliki zagovornik agilnosti kao operativne discipline, ali trebate osigurati da imate vještine svih pravih grupa koje su uključene u projektne timove dok napredujete na agilnom tipu nastojanja.
Da zaključimo, arhitekti podataka i modeličari moraju biti uključeni u sve razvojne projekte; oni su stvarno ljepilo koje sve drži zajedno, jer mi kao modelirači podataka i arhitekti razumijemo, ne samo konstrukcije podataka određenog razvojnog projekta, već i gdje podaci postoje u organizaciji i odakle možemo te podatke izvoriti, kao i kako to koristit će se i koristiti izvan određene aplikacije na kojoj radimo. Razumijemo složene odnose podataka i najvažnije je da se možemo kretati naprijed, a također i iz perspektive upravljanja kako biste preslikali dokument i shvatili kako izgleda vaš cjelovit podatkovni pejzaž.
To je poput proizvodnje; Dolazio sam iz proizvodnje. Ne možete na kraju provjeriti kvalitetu nečega - kvalitetu trebate ugraditi u svoj dizajn unaprijed i na putu, a modeliranje podataka način je da tu kvalitetu ugradite u dizajn na učinkovit i isplativ način sve do kraja, I opet, nešto za pamćenje - a to ne treba biti bahato, ali istina je - aplikacije dolaze i odlaze, podaci su vitalno korporativno dobro i prelaze sve one granice aplikacije. Svaki put kada postavljate aplikaciju, od vas se vjerojatno traži da sačuvaju podatke iz ostalih aplikacija koje su ranije stigle, stoga se samo moramo sjetiti da je to vitalna korporativna imovina koju stalno zadržavamo.
I to je to! Odavde ćemo uzeti više pitanja.
Eric Kavanagh: Dobro, dobro, dopusti mi da ga prvo prebacim Robinu. A onda, Dez, siguran sam da imaš par pitanja. Odnesi to, Robin.
Dr. Robin Bloor: Dobro. Da budem iskren, nikad nisam imao problema s agilnim razvojnim metodama i čini mi se da ovo što ovdje radite ima ugled. Sjećam se da sam gledao nešto iz 1980-ih što je, zaista, ukazivalo na to da je problem u kojem naiđete na projekt koji se ne može kontrolirati normalno ako dopustite da greška potraje i izvan određene faze. Jednostavno postaje sve teže popraviti ako tu fazu ne postignete dobro, tako da je jedna od stvari koja ovdje radite - i mislim da je to slajd - ali jedna od stvari koje ovdje radite u sprintu je nula, po mom mišljenju apsolutno važna jer se tamo stvarno želite zabiti. A ako ne dobijete prikačene isporuke, tada isporuke mijenjaju oblik.
To je, nekako, moje mišljenje. To je također moje mišljenje - stvarno nemam argumentaciju s idejom da morate ispravno modelirati podatke do određene razine detalja prije nego što prođete. Ono što bih volio da pokušate i učinite jer nisam imao potpunu spoznaju, je samo opisati jedan od tih projekata u smislu njegove veličine, u smislu kako je tekao, s obzirom na to tko, znate, gdje su se problemi nagomilali, jesu li riješeni? Jer mislim da je ovaj dijapozitiv srce njegova srca i ako biste mogli malo više razraditi na tome, bio bih vam vrlo zahvalan.
Ron Huizenga: Naravno, i ja ću koristiti nekoliko primjera projekata. Ona koja je, nekako, otišla sa tračnica koje su nas vratile zapravo uključivanjem pravih ljudi i provođenjem modeliranja podataka, a sve je stvarno bio način kako osigurati da se dizajn bolje razumije i očito smo imali bolji izvedbeni dizajn na putu kroz njegovo modeliranje. Jer kad ga modelirate, znate, možete generirati svoj DDL i sve iz leđa i iznutra iz alata, a ne da se morate praviti ovako kako to ljudi obično rade izravno u okruženje baze podataka. A tipične stvari koje će se dogoditi kod programera jesu da će ući unutra i oni će reći, u redu, trebaju mi ove tablice. Recimo da radimo unose u narudžbe. Tako mogu stvoriti zaglavlje i tablice detalja o narudžbi i takve vrste stvari. Ali oni će često zaboraviti ili zapostaviti kako bi bili sigurni da postoje ograničenja koja predstavljaju strane ključne odnose. Možda ključevi nisu točni. Konvencije o imenovanju također mogu biti sumnjive. Na primjer, ne znam koliko puta sam upao u okruženje gdje vidite gomilu različitih tablica s različitim imenima, ali tada su nazivi stupaca u tim tablicama poput ID-a, imena ili bilo čega drugog, pa oni Zaista sam izgubio kontekst bez tablice onoga što je to.
Dakle, obično kad modeliramo podatke pobrinut ćemo se da primjenimo pravilne konvencije o imenovanju na sve artefakte koji se generiraju i u DDL-u. Ali da budem precizniji o prirodi samih projekata, općenito govoreći, govorim o prilično velikim inicijativama. Jedan od njih bio je projekt transformacije poslovanja u iznosu od 150 milijuna dolara, gdje smo zamijenili preko desetak naslijeđenih sustava. Imali smo pet različitih agilnih momčadi istovremeno. Imao sam cjeloviti tim za arhitekturu podataka, tako da sam iz svog tima modelirao podatke koji su ugrađeni u svaki od ostalih timova iz područja aplikacije, a radili smo s kombinacijom internih poslovnih stručnjaka koji su znali temu, koji su radili korisničke priče za same zahtjeve. U svakom od tih timova imali smo poslovne analitičare koji su zapravo modelirali poslovni proces, sa dijagramima aktivnosti ili dijagramima poslovnih procesa, pomažući u iscrpljivanju korisničkih priča više s korisnicima prije nego što ih je pojeo i ostatak tima.
I onda, naravno, programeri koji su preko toga gradili aplikacijski kod. I mi smo također radili, mislim da su četiri različita proizvođača sistemske integracije koja su gradila različite dijelove aplikacije i gdje je jedan tim gradio podatkovne usluge, drugi je gradio logiku aplikacija na jednom području, drugi je imao stručnost u drugom je poslovnom području izgradnja logike primjene na tom području. Tako da smo imali čitavu suradnju ljudi koji su radili na ovom projektu. Na tom jednom, u timu smo imali 150 ljudi na obali i još 150 resursa na moru u timu koji su surađivali u dvotjednim sprinterima kako bi otjerali ovu stvar. Da biste to učinili, morate osigurati da pucate na sve cilindre, a svi su dobro sinkronizirani u pogledu isporuka, a imali ste i te česte resete da biste bili sigurni da smo dovršili isporuku svih potrebnih artefakata na kraju svakog sprinta.
Dr. Robin Bloor: Pa to je impresivno. I samo još malo detalja o tome - jeste li na kraju tog projekta završili s kompletnom, kako bih nazvao, MDM mapom čitavog područja podataka?
Ron Huizenga: Imali smo cjelovit model podataka koji je razbijen razgradnjom između svih različitih područja poslovanja. Sam rječnik podataka u smislu punih definicija malo je prekrao. Imali smo definiranu većinu tablica; imali smo većinu stupaca koji su točno definirani. Bilo ih je koji nisu bili tamo, a što je zanimljivo, puno je bilo informacija koje su dolazile iz naslijeđenih sustava u kojima se, nakon završetka samog projekta, još uvijek dokumentiralo kao prijenosni niz artefakte, kao da su izvan samog projekta, jer je to bilo nešto što je trebalo podržati od organizacije koja ide naprijed. Dakle, istodobno je organizacija zauzela puno veće stajalište o važnosti upravljanja podacima, jer smo vidjeli mnogo nedostataka u tim nasljeđenim sustavima i onim naslijeđenim izvorima podataka koje smo pokušavali iskoristiti, jer nisu dokumentirani. U mnogim smo slučajevima imali samo baze podataka za koje smo morali obratiti inženjer i pokušati shvatiti o čemu se radi i čemu služe informacije.
Dr. Robin Bloor: Ne iznenađuje me, njegov poseban aspekt. Upravljanje podacima je, nazovimo to, vrlo moderna briga i mislim da, zaista, treba puno raditi na, recimo, trebalo bi povijesno raditi na upravljanju podacima. To nikad nije bilo zato što biste se, nekako, mogli izvući ako to ne učinite. No kako su resursi podataka samo rasli i rasli, na kraju niste mogli.
U svakom slučaju, preći ću u Dez jer mislim da sam imao vremena. Dez?
Dez Blanchfield: Da, hvala. Kroz cijelu ovu stvar gledam i razmišljam sebi da govorimo o tome da vidimo agile korišten u gnjevu na mnogo načina. Iako ima negativne konotacije; Mislio sam to na pozitivan način. Možete li nam samo dati scenarij, mislim, postoje dva mjesta za koja vidim da je ovo savršen set: jedno su novi projekti koji jednostavno trebaju biti učinjeni od prvog dana, ali mislim da je, u mom iskustvu, često to često u slučaju da kada projekti postanu dovoljno veliki da je to potrebno na mnogo načina, postoji zanimljiv izazov između lijepljenja dva svijeta, zar ne? Možete li nam dati bilo kakav uvid u neke priče o uspjehu koje ste vidjeli gdje ste ušli u neku organizaciju, postalo je jasno da su se oni neznatno sukobili u dva svijeta i da ste uspjeli uspješno ovo je na mjestu i spojiti velike projekte gdje bi inače mogli krenuti na tračnice? Znam da je to vrlo široko pitanje, ali samo me zanima postoji li određena studija slučaja koju, nekako, možete uputiti tamo gdje ste rekli, znate, mi smo sve to postavili na svoje mjesto i to je donio sav razvojni tim zajedno sa tim za podatke i nekako smo se bavili nečim što bi inače moglo potonuti brod?
Ron Huizenga: Svakako, i zapravo jedan projekt koji se dogodio kao cjevovod bio je onaj na koji sam aludirao gdje sam pokazao taj grafikon s nedostacima prije i nakon uključivanja u posao modelera podataka. Često postoje i unaprijed stvoreni pojmovi, posebno ako se stvari pokrenu tamo gdje je to učinjeno iz čisto razvojne perspektive, samo su programeri uključeni u ove agilne projekte za isporuku aplikacija. Dakle, ono što se tamo dogodilo je naravno da su se sišli s tračnica i posebno su im artefakti podataka ili podaci koji su ih proizveli pali ispod oznake u pogledu kvalitete i stvarno se bave stvarima u cjelini. A prilično je često zabluda da će modelirači podataka usporiti projekte i da će modelar podataka imati pravi stav. Kao što kažem, morate izgubiti - ponekad postoje modelirači podataka koji imaju onaj tradicionalni stav vratara, „Ovdje smo da kontroliramo kako izgledaju podatkovne strukture“, a taj mentalitet mora nestati. Svi koji su uključeni u agilni razvoj, a posebno modeličari podataka, moraju preuzeti ulogu moderatora kako bi stvarno pomogli timovima da napreduju. A najbolji način za to je ilustrirati vrlo brzo pokazati timovima koliko mogu biti produktivni tako što prvo modeliraju promjene. I opet, zato sam i razgovarao o suradnji.
Postoje neke stvari koje možemo prvo modelirati i generirati DDL kako bismo ih gurnuli programerima. Također želimo osigurati da se ne osjećaju kao da im je ograničeno. Dakle, ako postoje stvari na kojima rade, pustite ih da nastave raditi u svojim razvojnim kutijama za razvoj, jer tamo programeri rade na svojim radnim površinama ili drugim bazama podataka kako bi napravili neke promjene na kojima testiraju stvari. I surađujte s njima i recite: "U redu, radite s tim." Mi ćemo ga unijeti u alat, riješit ćemo ga, a zatim ćemo ga gurnuti naprijed i dati vam skripte koje možete implementirati da ažurirate svoj baze podataka da bismo ih nadogradili na ono što je stvarni sankcionirani stvarni pogled proizvodnje kakav će biti, dok ćemo i dalje ići naprijed. A to možete vrlo brzo preokrenuti. Otkrio sam da su mi se dani ispunili tamo gdje sam se upravo vraćala naprijed i natrag iteratirajući s različitim razvojnim timovima, gledajući promjene, uspoređujući, generirajući skripte, započinjući ih, a ja sam uspjela održati korak s četiri razvojna tima prilično lako kad jednom postigao zamah.
Dez Blanchfield: Jedna od stvari koja mi padne na pamet je da, znate, puno razgovora koje vodim svakodnevno odnosi se na to da teretni vlak dolazi k nama, kao, iz automata -machine i IoT. A ako mislimo da sada imamo puno podataka o našem trenutnom okruženju u poduzeću, znate, ako na trenutak oduzmemo jednoroge gdje znamo da Googles i Facebooks i Ubers imaju petabajt podataka, ali u tradicionalnom poduzeću govorimo o još stotinama terabajta i puno podataka. Ali, po mom mišljenju ovaj teretni vlak dolazi u organizacije, a dr. Robin Bloor aludirao je ranije na IoT. Znate, imamo puno web prometa, imamo socijalni promet, imamo mobilnost i mobilne uređaje, oblak je nekako eksplodirao, ali sada imamo pametnu infrastrukturu, pametne gradove i tu je čitav svijet podataka koji je upravo eksplodirao.
Za svakodnevnu organizaciju, srednju do veliku organizaciju koja sjedi tamo i vidi kako ovaj svijet boli dolazi prema njima i nema neposredan plan, što su neka od poteza, u samo nekoliko rečenica, koje biste postavili o njima kada i gdje trebaju početi razgovorno razmišljati o postavljanju nekih od ovih metodologija. Koliko rano trebaju započeti s planiranjem da gotovo sjede i obrate pažnju i kažu da je ovo pravo vrijeme da se nađu neki alati i da se tim obuči i da razgovara vocab oko ovog izazova? Koliko je kasno u priči prekasno ili kada je prerano? Kako to izgleda za neke organizacije koje vidite?
Ron Huizenga: Za većinu organizacija bih rekao da ako to već nisu učinili i prilagodili modeliranje podataka i arhitekturu podataka s moćnim alatima poput ovog, vrijeme je potrebno da to urade jučer. Jer je zanimljivo da čak i danas, kada gledate podatke u organizacijama, imamo toliko podataka u našim organizacijama i općenito govoreći, na osnovu nekih anketa koje smo vidjeli, mi koristimo manje od pet posto tih podataka učinkovito kada pogledamo preko organizacija. A s IoT ili čak NoSQL-om, velikim podacima - čak i ako se ne radi samo o IoT-u, već o velikim podacima općenito - gdje sada počinjemo trošiti još više informacija koje dolaze izvan naših organizacija, taj izazov postaje sve veći i veći cijelo vrijeme. I jedini način na koji se imamo priliku boriti je taj koji će nam pomoći da shvatimo o čemu se ti podaci tiču.
Dakle, slučaj upotrebe je malo drugačiji. Ono što nalazimo je da kad pogledamo te podatke, snimamo ih, moramo ih unaprijediti, vidjeti što je u njima, bilo da je riječ o našim jezicima podataka ili čak u našim internim bazama podataka, sintetizirati ono što podaci su, primijenite na njega značenja i definicije kako bismo razumjeli što su podaci. Jer dok ne razumijemo o čemu se radi, ne možemo osigurati da ga ispravno ili adekvatno koristimo. Tako da doista trebamo shvatiti o tim podacima. A drugi dio toga je, nemojte to činiti jer možete, s obzirom na konzumiranje svih tih vanjskih podataka, provjeriti imate li slučaj upotrebe koji podržava konzumiranje tih vanjskih podataka. Usredotočite se na ono što vam je potrebno, a ne samo na povlačenje i korištenje stvari koje će vam možda trebati kasnije. Prvo se usredotočite na važne stvari i dok prolazite kroz njih, tada ćete doći do konzumiranja i pokušavanja razumijevanja ostalih informacija izvana.
Savršen primjer za to je, znam da govorimo o IoT-u i senzorima, ali isti je problem u mnogim organizacijama duži niz godina, čak i prije IoT-a. Svatko tko ima sustav kontrole proizvodnje, bilo da je riječ o plinovodu, proizvođačima, bilo kojim kompanijama koje se bave procesima, a koje rade puno automatizacije s kontrolama i koriste tokove podataka i slične stvari. ove baze podataka koje pokušavaju popiti kako bi shvatili, koji događaji su se dogodili u mojoj proizvodnoj opremi da signaliziraju - što se dogodilo i kada? Među ovim ogromnim nizom podataka postoje samo određene informacije ili oznake koje zanimaju da ih trebaju prosijati, sintetizirati, modelirati i razumjeti. I mogu ignorirati ostatak dok ne dođe vrijeme da ga stvarno shvate, a onda mogu proširiti svoje područje primjene da sve više i više toga povuku u domet, ako to ima smisla.
Dez Blanchfield: Zaista. Postoji jedno pitanje koje ću voditi u vezi s gospodinom zvanim Eric, i razgovarali smo privatno o tome. Upravo sam pitao njegovo dopuštenje, koje je dao, da ga pitam od vas. Jer to dovodi lijepo do ovoga, samo da završimo, jer sada idemo malo s vremenom, a ja ću se predati Ericu. Ali pitanje drugog Erica bilo je, je li razumno pretpostaviti da su vlasnici startupa upoznati i razumiju jedinstvene izazove oko modeliranja terminologije i slično, ili bi je trebao predati nekom drugom tumačenju? Drugim riječima, treba li startup biti sposoban i spreman i voljan i sposoban se usredotočiti na to i ostvariti ga? Ili je to nešto što bi vjerojatno trebali kupovati i dovesti stručnjake?
Ron Huizenga: Pretpostavljam da kratak odgovor zapravo ovisi. Ako je to startup koji nema nekoga tko je arhitekt podataka ili modelar koji stvarno razumije bazu podataka, tada najbrži način za početak je dovesti nekoga s konzultantskom pozadinom koja je vrlo dobro upoznata u ovom prostoru i može dobiti oni idu. Jer ono što ćete naći - a u stvari sam to i učinio na puno angažmana koji sam radio prije nego što sam prešao na mračnu stranu u upravljanju proizvodima - jeste li išao u organizacije kao konzultant, vodio njihove timove za arhitekturu podataka, kako bi se mogli, na neki način, preusmjeriti i osposobiti svoje ljude o tome kako ih raditi te stvari kako bi ih održavali i izvršavali misiju naprijed. I tada bih nastavio sa svojim sljedećim angažmanom, ako to ima smisla. Mnogo je ljudi koji to rade, a imaju vrlo dobro podatkovno iskustvo koje ih može pokrenuti.
Dez Blanchfield: To je sjajna stvar preuzimanja i potpuno se slažem s tim i siguran sam da bi i dr. Robin Bloor. Osobito u startup-u, usredotočeni ste na to da budete MSP na određenoj vrijednosti ponude koju želite izgraditi kao dio samog pokretačkog posla i vjerojatno vam ne bi trebao biti stručnjak za sve, tako da je sjajan savjet. Ali hvala puno, fantastična prezentacija. Zaista sjajni odgovori i pitanja. Eric, vratit ću ti se jer znam da smo vjerojatno prošli za deset minuta i znam da se voliš približiti našim vremenskim prozorima.
Eric Kavanagh: To je u redu. Imamo bar par dobrih pitanja. Dopustite da vam bacim jedan. Mislim da ste odgovorili na neke druge. Ali vrlo zanimljivo promatranje i pitanje jednog sudionika koji piše, ponekad okretni projekti imaju da modelar podataka nema cjelokupnu dugoročnu sliku, pa završe s dizajniranjem nečega u sprintu, a zatim moraju redizajnirati u sprintu tri ili četiri. Ne izgleda li to kontraproduktivno? Kako možete izbjeći takve stvari?
Ron Huizenga: Samo priroda okretnog je da u datom sprintu nećete postići sve apsolutno kako treba. A to je zapravo dio okretnog duha, glasi: radite s njim - napravit ćete prototipiranje tamo gdje radite kod u određenom sprintu, a vi ćete ga doraditi. I dio tog procesa je dok isporučujete stvari koje krajnji korisnik vidi i kaže: „Da, to je blizu, ali stvarno moram to učiniti i ovo malo više.“ Tako da ne utječe samo na funkcionalni dizajn samog koda, ali vrlo često moramo izmijeniti ili dodati više strukture podataka ispod ovih određenih stvari da bismo isporučili ono što korisnik želi. I to je sve fer igra i zato zaista želite koristiti napredne alate jer možete vrlo brzo modelirati i izvršiti tu promjenu u alatu za modeliranje, a zatim generirati DDL za bazu podataka na kojoj programeri mogu raditi sa isporukom promijeni se još brže. Spasujete ih od potrebe da to ručno kodiraju, kao da jesu, podatkovne strukture i dopuštate im da se koncentriraju na programsku ili aplikativnu logiku u kojoj su najiskusniji.
Eric Kavanagh: To ima potpuni smisao. Imali smo nekoliko drugih ljudi koji su nam postavljali samo određena pitanja oko toga kako se sve to vezuje za alat. Znam da ste proveli neko vrijeme proučavajući primjere i pokazali ste nekoliko snimaka zaslona o tome kako zapravo izvlačite neke od ovih stvari. Što se tiče čitavog sprinterskog procesa, koliko često to vidite u organizacijama nasuprot koliko često vidite tradicionalnije procese u kojima se stvari, kao što su, plivaju i oduzimaju više vremena? Koliko je iz vaše perspektive rasprostranjen pristup sprint stilu?
Ron Huizenga: Mislim da je viđamo sve više i više. Znam da sam, rekao bih, vjerojatno u posljednjih 15 godina posebno mnogo više posvojenja ljudi koji priznaju da im zaista treba brže isporučiti. Tako sam vidio sve više i više organizacija kako skaču po okretnom pojasu. Ne nužno u potpunosti; možda će započeti s nekoliko pilot projekata kako bi dokazali da to uspijeva, ali postoje neki koji su i dalje vrlo tradicionalni i drže se metode vodopada. Dobra vijest je, naravno, da alati djeluju vrlo dobro u tim organizacijama, kao i za one vrste metodologija, ali mi imamo prilagodljivost u alatu tako da oni koji skoče na brod imaju alate u kutiji s alatima na vrhovima prstiju. Stvari poput usporedbe i spajanja, stvari poput mogućnosti obrnutog inženjeringa, tako da mogu vidjeti koji su postojeći izvori podataka, tako da zapravo mogu vrlo brzo usporediti i generirati inkrementalne DDL skripte. I kako to počinju prihvaćati i vide da mogu imati produktivnost, njihova sklonost zagrljaju još više se povećava.
Eric Kavanagh: Pa, ovo su sjajne stvari. Upravo sam objavio link do slajdova tamo u prozoru za chat, pa provjeri to; malo je Bitly tu za vas. Imamo sve ove mrežne emisije za kasnije pregledavanje. Slobodno ih podijelite sa svojim prijateljima i kolegama. A Ron, hvala ti puno na današnjem vremenu, uvijek si ugodan za nastup - pravi je stručnjak za to područje i očito je da znaš svoje stvari. Dakle, hvala vama i hvala IDERA i, naravno, Dezu i našoj vlastitoj Robin Bloor.
I s tim ćemo se oprostiti, ljudi. Još jednom hvala na vašem vremenu i pažnji. Cijenimo što strpimo oko 75 minuta, to je prilično dobar znak. Dobri momci iz emisije, razgovarat ćemo s vama sljedeći put. Doviđenja.
