Oduzeti: Domaćin Eric Kavanagh raspravlja o važnosti modeliranja podataka u agilnom razvoju s Robinom Bloor-om, Dez Blanchfield-om i IDERA-inim Ronom Huizengom.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Eric Kavanagh: U redu dame i gospodo. Dobrodošli još jednom. Srijeda 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 oblikovanje našeg svijeta upravljanja podacima, „Modeliranje podataka u agilnom okruženju.“ Doista je slajd o vašem, na @eric_kavanagh. Stvarno bismo ga trebali staviti na tobogan. Moram na to.
Tako su godine vruće. Modeliranje podataka postojalo je oduvijek. Doista 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 stvarno pokušavaš, zar ne?
Model podataka predstavlja posao na fundamentalni način, pa kako svi ti novi izvori podataka mijenjaju igru? Hoćemo li saznati za to. Saznali smo kako na agilni način možete biti na vrhu stvari. I naravno, o tome je riječ godine.
Robin Bloors s nama, naš glavni analitičar, Dez Blanchfield koji dolazi iz Sydneya u Australiji i Ron Huizenga, stariji menadžer proizvoda iz IDERA-e - dugogodišnji moj prijatelj, izvrstan govornik na ovom prostoru, zna što zna, pa nemojte biti stidljivi teška pitanja, narode, ona tvrda. S tim ću napraviti Robina kao voditelja i oduzeti.
Dr. Robin Bloor: U redu. 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. Pa gledali smo 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 mislila da Id pružim opći pregled modeliranju, ali realnost toga, to sada postaje očito.
Imamo, znate, stvarnost velikih podataka, imamo više podataka, više izvora podataka, dobili smo protoke podataka koji su ušli u jednadžbu u posljednje tri ili četiri godine i počinje dobivati veći dio toga, i tu je 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 o tome, što je zapravo nešto što smo nacrtali prije oko 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 istinski u mirovanju, u smislu da se ne kreće puno. I tada su ti podaci, protoci i vi dobili 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 govore, zaista imaju 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ćete, 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 jako puno poteškoća. 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 lako ne izražava u podacima. 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 i što to znači kada se udružuju s drugim podataka, zahtijeva da ga modeliramo. Nije dovoljno dobro samo zapisivanje metapodataka 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 bi došlo do neusklađenosti tih slojeva, tada moramo imati modeliranje podataka. To zapravo nije fakultativno. Što više možete to učiniti u smislu automatizacije, to bolje. Ali zato što ima veze sa značenjem, to je zaista teško alternativno. Dovoljno je jednostavno uhvatiti metapodate u zapisu i moći ga dobiti iz niza značenja, ali ne govori vam o strukturi zapisa ili onome što zapisi znače ili koji su u redu za zapis.
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 dodavalo ne samo više primjera stvari u svijetu, što bi odgovaralo zapisima podataka, već su zapravo dodavali više značenja svijetu unoseći podatke o sve više stvari. To 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, to 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; njegova stalna aktivnost - trebala bi biti kontinuirana aktivnost u svakom okruženju u kojem postoje. Srećom, postoji puno okruženja u kojima to zapravo i nije slučaj i stvari su u skladu s tim izvan 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 su njegove nove dimenzije: dimenzija lokacije s mobilnim uređajem. Jednom kada dođete do IoT-a, gledali smo izvanredne probleme s podacima koje nikada prije nismo trebali učiniti i trebamo, na jedan ili drugi način, ispravno razumjeti što imamo, tačno kako to možemo objediniti, što možemo učiniti u smislu dobivanja značenja od združivanja i, naravno, onoga što možemo učiniti s njim, kada smo ga obradili.
Mislim da sam to dovoljno rekao. Preći ću na Dez Blanchfield, koji će u potpunosti reći nešto drugo.
Dez Blanchfield: Hvala vam. 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, a ja ne želim ukrasti grom ovoga konkretnog, ali jedan od odlazaka s našeg pregovora, koji želim podijeliti, u slučaju da ga niste uhvatili, bio je samo oko teme putovanja podataka , i pogodilo me to što sam ga zapravo zapisao razmišljajući o putovanju koje podaci zauzimaju u različitoj generacijskoj životnoj dobi - godini, mjesecima, tjednima, danima, satima, minutima, sekundama - a razlozi oko tih podataka su smješteni unutar tog razgovora , Bilo da sam programer koji radi na kodu, ili jesam li 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 komuniciraju s njim.
Zanimljivo je malo poduzimanje 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 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 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 ja imam veliko stajalište ovih dana, da se nije samo slučaj promijenio, 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 skaču iz aviona koji djeluju kao tim da sviraju vizualno zanimljive slike ljudi koji padaju u nebo.
Treće, što se dogodilo zbog toga? Pa, tu je članak iz 1986. godine napisao par gospode čija sam se imena očajnički pokušavao praviti, Hirotaka Takeuchi i Ikujiro Nonaka, mislim da se to izgovara, proizveli članak pod naslovom "Pomicanje štrafta dolje." 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 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 posebno oko dizajna i razvoja široke izvedbe 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 određeni vremenski period, 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 izoliranja koji nadgledaju cijelu ovu stvar i razumiju metodologiju dovoljno dobro da bi je vodili. Svi smo vidjeli te slike koje sam dobio s desne strane ovdje zidova i ploča punih Post-It bilješki, a poslužene 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 ss koji su podijeljeni u razdoblja od 24 sata, mjesečeve mjesece i 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 je shvatilo ovu agilnu metodologiju i istrčalo s njom, ako se oprostiš s punicom, na s.
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 smatram da stručnjaci za podatke moraju - ne bi trebali - sada moraju biti intimno uključeni u svaku komponentu izvođenja projekata, zaista, posebno u razvoj. Da to ne bismo, tada stvarno ne dajemo sebi najbolju priliku za dobar ishod. Često se moramo krenuti unatrag i razmišljati o tim stvarima jer postoji scenarij, stižemo 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 odmah preko noći 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 ili ne bi trebao izgledati ili je nesumnjivo to što su progutali i razumjeli da se obično stječu u izvornim vještinama postavljenim za programere softvera. A neki od uobičajenih izazova s kojima se suočavamo, samo da to povežemo, uključuju jednostavno osnovno stvaranje i održavanje i upravljanje samim dizajnom osnovne 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, prezime koje unosite u post? 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 u vidu, uputit ću se do našeg dobrog prijatelja iz IDERA i čuti o tom alatu i kako se bavi tim stvarima.
Ron Huizenga: Puno hvala i hvala i Robinu i Dezu što su zaista dobro postavili pozornicu i vidjet ćete malo preklapanja u nekoliko stvari o kojima sam razgovarao. Ali oni su zaista postavili vrlo čvrst temelj 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 koji koristimo da nam pomognu na tom putu. Ono što ću opisati ukratko je da neću ulaziti u detalje mnogo detalja; samo smo imali stvarno dobar pregled onoga što je to. Razgovarat ću o tome u smislu, što je podatkovni model i što nam to zapravo znači? I kako u našim organizacijama omogućiti koncept agilnog modelera podataka, kako angažirati modelere podataka, kakvo je sudjelovanje modelara i arhitekata tijekom godina, koje su vrste aktivnosti kojima bi se trebale 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. Zatim ćemo sažeti još nekoliko točaka, a zatim ćemo imati pitanja i odgovore uz to.
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 publike koja je uključena u projekt zapravo može vidjeti artefakte koje mi 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. 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.
Dakle, razgovarajmo na trenutak o Agile Data Modeleru. Kao što smo već upozoravali, prezentacija je 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, da, stvarno smo razmišljali o okretnom s razvojne perspektive, a postoji nekoliko 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 pričam jest, to ću učiniti u sklopu razvojnog projekta u kojem razvijamo aplikaciju koja će očito imati i komponentu podataka s njom povezanu. 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 otkrili su podaci koje koristimo već mogu postojati 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 con aplikaciji 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 u kojem postupno razvijamo njegove sastavne dijelove i razrađujemo ga kroz vrijeme gdje izrađujemo upotrebljiv kôd ili upotrebljive artefakte, reći ću za sve. Važna stvar je suradnja 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 ustanoviti 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. Unutar iteracija surađujemo kao grupa. Obično su dvotjedni ili jednomjesečni, ovisno o organizaciji, vrlo često. A također svakodnevno pregledavajte i postavljajte redovne sastanke tako da uklanjamo blokade i osiguravamo da pomičemo sve aspekte naprijed bez zaustavljanja u različitim područjima kroz koja prolazimo. I u tim slovima želimo se pobrinuti da proizvodimo upotrebljive isporuke kao dio svakog sljedećeg.
Samo malo drukčije shvaćam to, proširujući ga dalje, scrum je metodologija o kojoj ću ovdje konkretnije govoriti, a mi smo samo uvećali prethodnu sliku s još nekoliko aspekata. Obično postoji zaostatak proizvoda, a zatim i zastoj. Dakle, imamo sveukupni zaostatak koji se na početku svakog ponovljenog ponavljanja kažemo: "Što ćemo ovo napraviti?", A to je učinjeno na planiranom sastanku. Zatim razbijamo zadatke koji su povezani s tim i izvršavamo ih u tim tjednim ili četverotjednim pregledima 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 oni se razrađuju kontinuirano tijekom vremena, a ne da krenete nekoliko mjeseci niz cestu i otkrijete da ćete uskoro doći i morate produžiti raspored projekta. I vrlo je važno da, kao dio toga, čitavi timovi postoje na kraju pregleda i retrospektivni, pa prije nego što započnete sljedeću ponavljanje pregledavate što ste napravili i tražite načine na koje biste mogli poboljšati sljedeći put putem.
Što se tiče rezultata, ovo je u osnovi dijapozitiv koji sažima tipične vrste stvari koje se događaju u ss. 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 ovdje je pokopana činjenica da također trebamo imati te podatke koji će ići ruku pod ruku s tim pokušajima. 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 napraviti, 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 mi moramo proizvoditi ove korisne rezultate u svim s.
Neki će ljudi reći da na kraju svakog s moramo proizvesti korisni kod. To nije nužno slučaj, to je u najčistijoj perspektivi razvoja, ali često - posebno na početku - možemo imati nešto poput nule na kojoj smo usredotočeni isključivo 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 pripremu, pa ćemo vrlo često imati nulu, pa čak i nulu i jedan. Može biti malo pokretačka faza prije nego što postignemo cjelovit let u pružanju rješenja.
O ovom modelu podataka razgovarat ćemo ukratko. 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 podatke 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 u određenoj aplikaciji radimo istovremeno s više baza podataka ili izvora podataka. Ono što je vrlo važno jest da želimo imati punu specifikaciju, pa logična specifikacija što to znači organizacijska perspektiva, kakvi su fizički konstrukti u smislu kako mi zapravo definiramo podatke, odnose između njih u vašem 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, i 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. Također sam uhvatio i stvari poput master 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, morat ću brzo proći sve ostale.
Sada ću vrlo brzo razgovarati o tome što radi model moderator podataka dok prolazimo kroz ove različite ss. Prije svega, punopravni sudionik u sesijama planiranja, gdje donosimo korisničke priče, obvezujući se na ono što ćemo im isporučiti u tim okvirima i smišljamo kako ćemo ga strukturirati i dostaviti. Ono što također radim kao modelar podataka jest da znam da radim u zasebnim 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. Kao što gradimo model, prikazujemo ga i u različitim 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 radimo sve ove stvari u jednom trenu, 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 su uvijek osnova koja se možemo vratiti jer jedna od stvari koju trebamo biti je da li je to kraj ili na kraju ili nekoliko ss, ž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 s. 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 zadani s, a vi ih pokupite u kasnijim ss.
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. Na kasnijim se adresama možete 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 trenu; 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. Jednostavno nastavljamo s ponavljanjem do ovog mjesta, tako da dobivamo cjelovite isporuke podataka, potpunu dokumentaciju i definiciju svih onih struktura 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 kako bismo nam brzo pokrenuli napredak u pogledu poboljšanja stvari s različitim razvojnim timovima s kojima radimo.
I u s aktivnostima je opet 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 s početka ili kraj drugog, tako da možemo vidjeti potpuna inkrementalna promjena onoga što je učinjeno u određenom razvojnom s ili u nizu ss-ova.
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 s automatiziranim sustavima gradnje gdje moramo zajedno provjeriti različite rezultate kako bismo bili sigurni da nećemo prekinuti svoje konstrukcije. 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, na kraju završetka sakupljanja posla, moram puno toga što moram učiniti, a za sljedeći slovce nazivam svojim domaćinstvom. Svako s kojim kreiram ono što zovem Named Release - to mi daje osnovnu vrijednost za ono što sada imam na kraju izdanja. 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 s bilo kojeg drugog, što 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 s. Možda sam provjerio čitavu gomilu inkrementalnih skripti, ali ako mi zatreba, sada imam skriptu koju mogu rasporediti kako bih izdržao druge sandučiće tako da mogu samo reći da smo ovo imali na početku one, pritisnite proradimo, izgradimo bazu podataka kao kutiju za pseće korake kako bismo započeli sa sljedećim s, a mi ih također možemo upotrijebiti za obavljanje stvari poput standup QA instanci i na kraju, naravno da želimo gurnuti promjene u proizvodnju, tako da imamo više stvari u isto vrijeme. Opet, u potpunosti sudjelujemo u planiranju i retrospektivama, retrospektive su zaista naučene lekcije, a to je izuzetno važno, jer tijekom agilnosti možete krenuti vrlo brzo, morate se zaustaviti i proslaviti uspjehe, kao i sada. Otkrijte što nije u redu, sljedeći put vam bude bolje, ali također proslavite stvari koje su krenule po redu i nadograđujte ih dok nastavite krenuti prema naprijed u sljedećim s.
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 pola i pol dana 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 zgrade developera njih 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 morate osigurati da imate vještine svih pravih grupa koje su uključene u projektne timove dok napredujete na agilnom naumu.
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, dopusti mi da ga prvo prebacim Robinu. A onda, Dez, siguran sam da imaš par pitanja. Odnesi to, Robin.
Dr. Robin Bloor: U redu. Da budem iskren, nikad nisam imao problema s agilnim razvojnim metodama i čini mi se da ovo što ovdje radite ima eminentnog smisla. 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 istječe izvan kontrole, obično 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 Po mom mišljenju, nula je, po mom mišljenju, apsolutno važna, jer vi stvarno pokušavate tamo staviti priložene rezultate. A ako vam ne stoje isporučeni proizvodi, onda proizvodi mijenjaju oblik.
To je vrsta mog mišljenja. To je također moje mišljenje - stvarno nemam nikakvu raspravu s idejom da trebate 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 zahvalan.
Ron Huizenga: Sigurno i upotrijebit ću par 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 narudžbi. Tako mogu stvoriti zaglavlje i tablice detalja o narudžbi i takve vrste stvari. Ali oni će često zaboraviti ili zanemariti 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 Stvarno sam izgubio prevaru bez tablice upravo onoga što je to.
Dakle, obično prilikom modeliranja podataka pobrinut ćemo se da primijenimo odgovarajuće konvencije o imenovanju na sve artefakte koji se generiraju i u DDL-u. Ali da budem precizniji o prirodi samih projekata je, 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 trajanju od dva tjedna kako bi otjerali ovu stvar. Da biste to učinili, morate biti sigurni 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 s.
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 razgrađen 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 naslijeđenim sustavima i onim naslijeđenim izvorima podataka koje smo pokušali 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, taj njegov specifični 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 imala svoje vrijeme. Dez?
Dez Blanchfield: Da hvala ti. Kroz cijelu ovu stvar promatram i razmišljam sebi kako pričamo o tome da vidimo mnogo agilnog korištenog u gnjevu. 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 modera podataka. Često postoje i unaprijed stvoreni pojmovi, posebno ako se stvari pokrenu tamo gdje je to napravljeno iz čisto razvojne perspektive, to su samo programeri koji su 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 često postoji zabluda da će modeli dizajnera podataka usporiti projekte i da će moderator podataka imati pravi stav. Kao što kažem, morate izgubiti - ponekad postoje modelirači podataka koji imaju onaj tradicionalni stav vratara, „Ovdje smo da bismo kontrolirali kako izgledaju podatkovne strukture“, a taj mentalitet mora nestati. Svi koji su uključeni u agilni razvoj, a posebno oni koji rade na modeliranju podataka, moraju preuzeti ulogu moderatora kako bi timovima zaista pomogli 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 govorio o saradnji.
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 su im ograničena. Ako postoje stvari na kojima rade, pustite ih da nastave raditi u svojim okvirima za razvoj softvera, jer programeri tamo rade na vlastitim radnim površinama ili drugim bazama podataka da bi izvršili 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 pada na pamet je ta, znate, da se puno razgovora koje vodim svakodnevno odnosi na to da teretni vlak dolazi k nama, od nekog tipa, od stroja do stroja i IOT. I ako mislimo da sada imamo puno podataka o našem trenutnom okruženju u poduzeću, znate, ako na trenutak odvedemo jednoroge u stranu gdje znamo da Googles i s 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 je na to aludirao i ranije. 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 u nekim organizacijama koje vidite?
Ron Huizenga: Rekao bih za većinu organizacija da ako to već nisu učinile i prilagodile modeliranje podataka i arhitekturu podataka moćnim alatima poput ovog, vrijeme je potrebno za to. Jer je zanimljivo da čak i danas, kada pogledate 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 možemo suočiti 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 se radi o našim podacima ili čak u našim internim bazama podataka, sintetizirati ono što podaci su, primijenite značenja na njega i definicije da bismo razumjeli što su podaci. Jer dok ne razumijemo o čemu se radi, ne možemo osigurati da ga ispravno ili primjereno koristimo. Tako da doista trebamo shvatiti o tim podacima.A drugi dio toga je, nemojte to činiti jer možete, u smislu konzumiranja svih tih vanjskih podataka, osigurati da imate 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 toga 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 tim ogromnim nizom podataka postoje samo određene informacije ili oznake koje ih 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 u koje ću se upustiti u pitanje gospode zvane Eric, a mi smo privatno razgovarali o tome. Samo sam pitao njegovo dopuštenje, koje je dao, da ga pitam od vas. Zato što to dovodi do toga lijepo, samo da završimo, jer sada pomalo idemo s vremenom, a ja ću se vratiti Eriku. 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: Valjda kratak odgovor je da doista ovisi. Ako je to startup koji nema nekoga tko je arhitekt podataka ili modelar koji stvarno razumije bazu podataka, onda 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 pri izvođenju 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 prijedloga koju želite izgraditi kao dio samog startup poslovanja i vjerojatno vam ne bi trebao biti stručnjak za sve, pa sjajni savjeti. Ali hvala puno, fantastična prezentacija. Zaista sjajni odgovori i pitanja. Eric, vratit ću ti se jer znam da smo vjerojatno prošli deset minuta, a znam da se volite pridržavati naših vremenskih prozora.
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 jednom, a zatim moraju redizajnirati tri ili četiri. Ne izgleda li to kontraproduktivno? Kako možete izbjeći takve stvari?
Ron Huizenga: To je samo priroda okretnosti u kojoj nećete dobiti sve apsolutno kako treba u datom trenutku. A to je zapravo dio okretnog duha: radite s njom - napravit ćete prototipiranje tamo gdje radite kod na određenom sjonu, 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. Uštedjeli ste ih od potrebe da ručno kodiraju strukture podataka i ostave ih da se koncentriraju na programsku ili aplikacijsku 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 prolazeći kroz primjere i pokazali ste neke snimke zaslona o tome kako zapravo izvlačite neke od ovih stvari. Što se tiče ovog čitavog procesa, koliko često to vidite u organizacijama, a koliko često vidite tradicionalnije procese, gdje se stvari jednostavno, vrte i oduzimaju više vremena? Koliko je iz vaše perspektive rasprostranjen pristup stilu stila?
Ron Huizenga: Mislim da to viđamo sve više i više. Znam da bih, rekao bih, vjerojatno u posljednjih 15 godina naročito više vidio usvajanje ljudi koji priznaju da im zaista treba brže isporučiti. Tako sam vidio da sve više i više organizacija skače 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, to su sjajne stvari, ljudi. Upravo sam objavio link do slajdova tamo u prozoru za chat, pa provjeri to; malo je tu bitnih za vas. Imamo sve ove mrežne emisije za kasnije pregledavanje. Slobodno ih podijelite sa svojim prijateljima i kolegama. I Ron, hvala vam puno na vašem vremenu danas, uvijek ste ugodni na showu - pravi je stručnjak za to područje i očito je da znate 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, poprijat ćemo s vama sljedeći put. Doviđenja.