Modelarea datelor într-un mediu agil

De personalul Techopedia, 16 noiembrie 2016

Take away : Gazda Eric Kavanagh discută importanța modelării datelor în dezvoltarea agilă cu Robin Bloor, Dez Blanchfield și Ron Huizenga, IDERA.

În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.

Eric Kavanagh: Bine, doamnelor și domnilor. Bine ați venit din nou. Este miercuri la ora 4:00 EST. Asta înseamnă că este timpul pentru Hot Technologies. Da, întradevăr. Numele meu este Eric Kavanagh, voi fi gazda ta.

Pentru subiectul de astăzi, este un oldie, dar un bunat. Este din ce în ce mai bine în fiecare zi, deoarece ne conturează lumea de gestionare a datelor, „Modelarea datelor într-un mediu agil.” Există o prezentare cu adevărat asupra ta, lovește-mă pe Twitter @eric_kavanagh. Ar trebui să-l punem într-adevăr pe acel diapozitiv. Va trebui să mă ocup de asta.

Deci anul este fierbinte. Modelarea datelor a fost pentru totdeauna. A fost cu adevărat în centrul și sufletul afacerii de gestionare a informației, proiectarea modelelor de date, încercarea de a înțelege modelele de afaceri și a le alinia la modelele de date. Chiar asta încerci să faci, nu?

Modelul de date reprezintă afacerea într-un mod fundamental, deci cum se schimbă toate aceste noi surse de date? Vom afla despre asta. Vom afla cum poți să stai deasupra lucrurilor într-un mod agil. Și, desigur, acesta este cuvântul anului.

Robin Bloor alături de noi, analistul nostru principal, Dez Blanchfield, sunând din Sydney, Australia și Ron Huizenga, Senior Product Manager de la IDERA - prietenul meu de multă vreme, excelent vorbitor în acest spațiu, își cunoaște lucrurile, așa că nu fiți timizi, întrebați el întrebările grele, oamenii buni, cele grele. Cu asta, o voi face pe Robin prezentatoarea și o voi lua.

Dr. Robin Bloor: Bine. Mulțumesc pentru asta, Eric. Trebuie să spun despre modeling pe care cred că am fost, de fapt, în lumea IT-ului înainte de a exista, în sensul în care îmi amintesc în compania de asigurări la care am lucrat, că am avut un tip care ne-a venit și să ne dea tot un fel de atelier despre modul de modelare a datelor. Deci ne uităm la aproximativ 30 de ani, sunt 30 de ani? Poate chiar mai mult decât atât, poate acum 35 de ani. O modelare îndelungată și îndelungată a făcut parte din industrie și, desigur, nu are nimic de-a face cu doamnele de pe pasarele.

Lucrul pe care am vrut să-l spun, pentru că ceea ce facem în mod normal, sunt eu și Dez vorbesc despre diferite lucruri și m-am gândit doar să ofer o imagine de ansamblu generală a modelării, dar există o realitate în acest sens, acum devine evident.

Avem, știți, marea realitate de date, avem mai multe date, mai multe surse de date, avem fluxuri de date care au intrat în ecuație în ultimii trei sau patru ani și începe să obțină o parte mai mare din aceasta și există o nevoie mai mare de a înțelege datele și o creștere a vitezei de modificare, care se adaugă mai multe date și se utilizează mai multe structuri de date.

Este o lume dificilă. Iată o imagine a acesteia, care este de fapt ceva pe care am desenat-o acum aproximativ trei ani, dar practic, odată ce includeți fluxul în mix și veți face această idee de rafinărie de date, hub de date, link de date sau orice altceva, vedeți că există date care sunt cu adevărat în repaus, în sensul că nu se mișcă cam mult. Și atunci există datele, fluxurile și aveți toată aplicația tranzacțională, în plus, în prezent, aveți evenimente, fluxuri de date despre evenimente care se petrec în aplicații și ar putea avea nevoie și, în prezent, cu arhitecturile lambda despre care vorbește toată lumea, sunt cu adevărat având un impact asupra întregului câmp de date.

Și în zilele noastre gândiți-vă în ceea ce privește existența unui strat de date. Stratul de date există într-un fel de mod virtual, în sensul că o bună parte din acesta ar putea fi în cloud și poate fi răspândit în centrele de date, poate exista pe stații de lucru. Stratul de date este, într-o oarecare măsură, peste tot și în acest sens, există procese peste tot care încearcă într-un fel sau altul să proceseze datele și să le mute. Dar, de asemenea, a ști despre ce este vorba atunci când îl mutați, este o afacere mare.

Dacă privim modelarea datelor în sensul cel mai general, în partea de jos a acestui tip de stivă aveți fișiere și baze de date. Aveți elemente de date, care au chei, definiții ale elementelor, aliasuri, sinonime, formate fizice specifice și apoi avem acest strat de metadate.

Lucrul interesant despre metadate este faptul că metadatele sunt în întregime modul în care datele capătă semnificația lor. Dacă de fapt nu aveți metadate, atunci în cel mai bun caz puteți ghici semnificația datelor, dar veți avea multe dificultăți groaznice. Metadatele trebuie să fie acolo, dar sensul are structură. Nu vreau să intru în filosofia sensului, dar chiar și în modul în care ne ocupăm de date, există o mulțime de sofisticări în gândirea umană și în limbajul uman, care nu se exprimă cu ușurință în date. Dar chiar și în ceea ce privește datele pe care le prelucrăm efectiv în lume, metadatele au semnificația și structura metadatelor - o informație în raport cu alta și ce înseamnă asta când sunt reunite și ce înseamnă asta atunci când „ am fost alăturat cu alte date, solicită să o modelăm. Nu este suficient de bine să înregistrezi etichete de metadate la lucruri, de fapt trebuie să înregistrezi sensul pe structuri și relația dintre structuri.

Apoi avem în stratul superior, definițiile de afaceri, care este în mod normal un strat care încearcă să transfere sensul între metadate, care este o formă de definire a datelor care se încadrează în modul în care datele sunt organizate pe computer și sensul uman. Deci, aveți termeni de afaceri, definiții, relații, concepte la nivel de entitate care există în acel strat. Și dacă vom avea o incoerență între aceste straturi, trebuie să avem o modelare a datelor. Nu este chiar opțional. Cu cât îl puteți face mai mult în termeni de automatizare, cu atât mai bine. Dar pentru că are legătură cu sensul, este cu adevărat dificil să alternați. Este suficient de ușor să prindeți metadatele dintr-o înregistrare și să o puteți obține dintr-o serie de semnificații, dar nu vă spune structura înregistrărilor sau ce înseamnă înregistrările sau contextul înregistrării.

Așadar, despre asta este vorba despre modelarea datelor. Puncte de reținut: cu cât universul de date devine mai complex, cu atât trebuie să îl modelezi. Cu alte cuvinte, este un pic ca adăugăm nu doar mai multe cazuri de lucruri în lume, care ar corespunde înregistrărilor de date, dar de fapt adăugăm mai mult sens lumii prin captarea de date despre tot mai multe lucruri. Devine o senzație din ce în ce mai complexă pe care trebuie să o înțelegem.

În teorie, există un univers al datelor și avem nevoie de o vedere a acestuia. În practică, metadatele reale fac parte din universul datelor. Deci, nu este o situație simplă. Modelarea de început este de sus în jos și de jos în sus. Trebuie să construiți în ambele direcții și motivul pentru care este vorba, datele au semnificații pentru computer și proces, care trebuie să le prelucreze, dar au sens în sine. Deci, aveți nevoie de un sens de jos în sus, care să satisfacă software-ul care trebuie să acceseze datele și aveți nevoie de sensul de sus în jos, pentru ca ființele umane să le înțeleagă. Construirea modelelor de metadate nu este și nu poate fi niciodată un proiect; este o activitate continuă - ar trebui să fie o activitate continuă în fiecare mediu în care există. Din fericire, există o mulțime de medii în care acest lucru nu este cazul și lucrurile se scot din control în consecință.

Continuând, modelarea crește cu importanță pe măsură ce tehnologia avansează. Aceasta este părerea mea. Dar dacă te uiți la IoT, putem înțelege mai mult mobil decât ne-am obișnuit, deși a introdus noi dimensiuni: dimensiunea locației cu mobilul. După ce ați ajuns la IoT, ne uităm la probleme extraordinare de date pe care nu le-am făcut niciodată până acum și trebuie, într-un fel sau altul, să înțelegem corect ceea ce avem, exact cum îl putem agrega, ce putem face în ceea ce privește obținerea sensului din agregare și, bineînțeles, ce putem face cu ea, atunci când am procesat-o.

Cred că asta am spus suficient. O să transmit lui Dez Blanchfield, care va spune altceva în întregime.

Dez Blanchfield: Mulțumesc. Întotdeauna un act greu de urmat, dar acesta este un subiect pe care am fost de acord și despre care am vorbit despre acest lucru pe scurt în prezentul banter, iar dacă ați apelat devreme, probabil că ați prins o mulțime de pietre deosebite. Unul dintre cei care au luat de mâncare și nu vreau să fiu tunetul acestui anume, dar unul dintre cei care se pot purta din banterul nostru prezent pe care vreau să-l împărtășesc, în caz că nu l-ați prins, a fost doar în jurul subiectului călătoria datelor și m-a atras atenția să o notez, gândindu-mă la călătoria pe care datele o iau într-un context diferit în jurul vieții generaționale - an, luni, săptămână, zi, oră, minut, secundă - și contextul din jurul datelor sunt poziționat în contextul respectiv. Fie că sunt un cod care rulează un dezvoltator, fie că sunt specialist în date și mă gândesc la structura și formatul și la metadatele din jurul fiecărui element sau la modul în care sistemele și afacerea interacționează cu acesta.

Este foarte puțin interesant să iau în seamă, dar oricum, permiteți-mi să mă scufund. Proiectarea datelor, în special, este o frază pe care o folosesc pentru a vorbi despre toate lucrurile și în mod specific despre dezvoltarea aplicațiilor sau a infrastructurii bazei de date. Cred că designul de date este un termen care surprinde totul foarte bine în mintea mea. În aceste zile, când vorbim de design de date, vorbim despre design modern de date agile, iar părerea mea este că nu a fost atât de mult timp în urmă că dezvoltatorii și experții în date au lucrat singuri; se aflau în propriile silozuri și piese de design mergeau de la un siloz la altul. Dar îmi place foarte mult zilele acestea, că nu numai că se schimbă, ci trebuie să se schimbe; este un fel de necesitate și asta este aplicația - dezvoltatorii și orice trebuie să facă în jurul dezvoltării care se ocupă de date, proiectanții care realizează elementele de proiectare relevante ale schemelor și câmpurilor și înregistrărilor, sistemelor și infrastructurii locației și bazelor de date, modelarea și întregul management provocare în jurul lui. Acesta este un sport de echipă acum și, prin urmare, imaginea mea despre o grămadă de oameni care sără dintr-un avion care acționează ca o echipă pentru a juca acea imagine vizual interesantă a oamenilor care cad pe cer.

În al treilea rând, ce s-a întâmplat pentru a aduce asta? Ei bine, există un articol din 1986, scris de câțiva domni ai căror nume am încercat cu disperare să fac dreptate, Hirotaka Takeuchi și Ikujiro Nonaka, cred că este pronunțat, au produs un articol pe care l-au intitulat „Moving the Scrum Downfield.” această idee a unei metodologii de câștigare a unui joc de rugby plecând de la această activitate scrum, unde toată lumea se apropie într-un singur loc și două echipe în mod esențial blochează capetele în ceva numit scrum pentru a încerca să controleze mingea și să o joace pe teren. ajungeți la linia de încercare și atingeți pământul cu mingea și obțineți un punct, numit trin, și repetați acest proces și veți primi mai multe puncte pentru echipă.

Acest articol a fost publicat în 1986 în Harvard Business Review și, în mod curios, a atras foarte multă atenție. A primit foarte multă atenție pentru că a introdus concepte noi uimitoare și iată o captură de ecran a părții din față. Așa că au scos acest concept de scrum din rugby-ul jocului și l-au adus în afaceri și în special în jocul de proiectare și de livrare a proiectelor, în special de livrare a proiectelor.

Ce scrum a făcut ne-a oferit o metodologie nouă în comparație cu aprecierile PRINCE2 sau PMBOK pe care le-am folosit anterior în ceea ce am numit metodologia cascadă, știți, faceți acest lucru și acest lucru și acest lucru și urmăriți-le în secvență și conectați-le toate punctele din jur, care depind de ceea ce ai avut sau nu faci partea a doua până nu ai făcut prima parte, deoarece depindea de prima parte. Ceea ce ne-a oferit este o metodologie nouă pentru a fi un pic mai agil, care este de unde vine termenul, despre modul în care livrăm lucrurile și, în special, în jurul proiectării și dezvoltării proiectelor de bază.

Unii dintre chiriașii-cheie - tocmai așa mă descurc cu acest lucru - se află în jurul chiriașilor cheie din scrum. A introdus ideea construirii instabilității, că în mod efectiv dacă vă gândiți la frica haosului, lumea există într-o stare de haos, dar planeta s-a format, ceea ce este interesant, deci construirea instabilității, capacitatea de a sări în jurul unui pic și fac în continuare lucrurile să funcționeze, autoorganizarea echipelor de proiect, suprapunerea favorurilor printr-o dezvoltare foarte responsabilă, diferite tipuri de învățare și control prin călătoria livrării proiectului, transferul organizațional al învățării. Deci, cum luăm informațiile dintr-o parte a afacerii și le transferam altuia de la persoane care au o idee, dar nu dezvoltă cod sau nu dezvoltă baze de date și infrastructuri, ci date către acei oameni? Și, în mod specific, rezultate de timp. Cu alte cuvinte, haideți să facem acest lucru pentru o perioadă de timp, fie o zi, cât în ​​24 de ore, sau o săptămână sau câteva săptămâni și să vedem ce putem face, apoi să facem un pas înapoi și să-l privim.

Și deci, dacă iertați acest punct, acesta este într-adevăr un joc nou în livrarea proiectului și cele trei componente de bază ale acestuia, care vor avea sens, pe măsură ce vom ajunge puțin mai departe aici - există produsul: toți acești oameni au ideea și au o nevoie de a face ceva și povestea care îi înconjoară. Dezvoltatorii care operează în modelul agil de a-și obține poveștile și prin standup-uri zilnice, folosind metodologia scrum pentru a discuta despre aceasta și pentru a înțelege ce trebuie să facă, și apoi pur și simplu mergeți mai departe și faceți-o. Apoi, oamenii, am auzit de maeștri de scrum care supraveghează toată această problemă și înțeleg metodologia suficient de bună pentru a o conduce. Cu toții am văzut aceste imagini pe care le-am găsit pe partea dreaptă aici, cu pereți și tablă pline cu note Post-It și au fost servite ca pereți Kanban. Dacă nu știți cine este Kanban, vă invit pe Google cine a fost domnul Kanban și de ce a fost o schimbare a modului în care mutăm lucrurile dintr-o parte în alta într-un perete, literal, dar într-un proiect.

La prima vedere, fluxul de lucru Scrum face acest lucru: este nevoie de o listă de lucruri pe care o organizație dorește să le facă, să le ruleze printr-o serie de lucruri pe care le numim sprinturi care sunt împărțite în perioade de 24 de ore, perioade lungi și noi obțineți această serie incrementală de rezultate. Este o schimbare semnificativă a modului în care sunt derulate proiectele, au fost livrate până la acea etapă, deoarece o parte din aceasta curge ca armata americană care a avut o mare parte din dezvoltarea unui numit PMBOK, precum ideea că nu iau rezervorul pe câmp. până când pui gloanțe în lucrul acesta, pentru că dacă un rezervor din câmp nu are gloanțe, este inutil. Prin urmare, prima parte este pusă gloanțe în rezervor, partea a doua este introdusă rezervorul în câmp. Din păcate, totuși, ceea ce s-a întâmplat cu dezvoltatorii din lumea dezvoltării a luat cumva o abordare a acestei metodologii agile și a fugit cu ea, dacă iertați, la un sprint.

Invariabil ceea ce s-a întâmplat este atunci când ne gândim la agil, de obicei ne gândim la dezvoltatori și nu la baze de date și orice are de-a face cu lumea bazelor de date. A fost un rezultat nefericit, deoarece realitatea este că agilul nu se limitează doar la dezvoltatori. De fapt, termenul agil, în opinia mea, este adesea asociat greșit exclusiv cu dezvoltatorii de software și nu proiectanții și arhitecții de baze de date. Invariabil aceleași provocări cu care vă confruntați în dezvoltarea de software și aplicații se confruntă în toate aspectele legate de proiectarea, dezvoltarea și operarea și întreținerea și, prin urmare, a infrastructurii de date și în special a bazelor de date. Printre actorii din această distribuție de date se numără arhitecții de date, formatorii, administratorii, administratorii infrastructurilor de baze de date și bazele de date actuale până la analiștii de afaceri și sisteme și arhitecți, oameni care stau și se gândesc la modul în care sistemele sunt business și funcționează și cum am ajuns să transferăm date prin acestea.

Este un subiect pe care îl aduc în mod regulat, deoarece este o frustrare constantă a mea, prin faptul că sunt foarte de părere că specialiștii în date - nu ar trebui - trebuie să fie implicați în mod intim în fiecare componentă a livrării de proiect, într-adevăr, în special în dezvoltare. Pentru că nu, atunci nu ne oferim cu adevărat cea mai bună șansă pentru un rezultat bun. De multe ori trebuie să facem un cerc și să ne gândim la aceste lucruri, deoarece există un scenariu, ajungem la o aplicație care este construită și descoperim că dezvoltatorii nu sunt întotdeauna experți în date. Lucrul cu baze de date necesită abilități foarte specializate, în special în jurul datelor și creează o experiență. Nu devii doar instantaneu un guru al bazei de date sau expert în cunoștințe de date peste noapte; acesta este adesea ceva care provine dintr-o experiență de viață și, cu siguranță, pe placul doctorului Robin Bloor pe Code Today, care a scris destul de bogat cartea.

În multe cazuri - și este nefericit, dar este o realitate - că există două părți ale acestei monede, adică dezvoltatorii de software au o oprire de sine stătătoare în ceea ce privește specialistul bazelor de date și au construit abilitățile de care aveți nevoie în modelarea bazei de date, dezvoltarea modelului fiind doar fundamental pentru ingineria guruilor despre modul în care intră datele și modul în care organizarea călătoriei este necesară sau cum ar trebui sau nu ar trebui să arate, sau, fără îndoială, că a ingerat și a înțeles că este obținut de obicei în abilitățile native setate pentru dezvoltatorii de software. Și unele dintre provocările comune cu care ne confruntăm, doar pentru a pune asta în context, includ aprecierile de bază și crearea de bază și gestionarea proiectării de bază a bazei de date în sine, documentarea datelor și a infrastructurii bazei de date și apoi reutilizarea acelor date, a proiectelor de scheme, generarea schemelor, administrarea și întreținerea schemelor și utilizarea acestora, împărtășirea cunoștințelor în jurul motivului pentru care această schemă este proiectată într-un mod anume și punctele tari și punctele slabe care vin cu asta în timp determină schimbări de date în timp, modelarea datelor și tipurile a modelelor pe care le aplicăm sistemelor și datelor prin care trecem prin ele. Generarea codurilor de baze de date și continuă integrarea, apoi modelează datele din jurul lor și apoi accesul mai rapid la controlul securității în jurul datelor, integritatea datelor mutăm datele în timp ce le păstrăm integritatea, există suficiente metadate în jur ar trebui, vânzările ar trebui să vadă toate înregistrările din tabel sau ar trebui să vadă doar adresa, prenumele, prenumele care vă trimite chestii în postare? Și atunci, desigur, cea mai mare provocare a tuturor este aceea de a modela platforme de baze de date care este în totalitate o conversație diferită în sine.

Sunt foarte de părere că, având în vedere toate acestea, pentru a face posibilă oricare dintre aceste nirvana, este absolut critic faptul că atât specialiștii în date, cât și dezvoltatorii au instrumente adecvate și că aceste instrumente pot fi capabile să livreze proiecte axate pe echipă, proiectare, dezvoltare și întreținere operațională continuă. Știi, lucruri precum colaborarea în proiecte între experți în date și dezvoltatori de software, un singur punct de adevăr sau o singură sursă de adevăr pentru toate lucrurile din documentația bazelor de date în sine, datele, schemele, de unde provin înregistrările, proprietarii acelor înregistrări . Cred că în acea zi și vârstă este absolut critic, vom face ca acest nirvana de date să fie rege, că instrumentele potrivite trebuie să fie în loc, deoarece provocarea este prea mare acum pentru noi să o facem manual și dacă oamenii mutați-vă și ieșiți dintr-o organizație, este prea ușor pentru noi să nu urmăm același proces sau metodologie pe care o persoană ar putea să o stabilească, care să fie bună și care să nu transfere neapărat acele abilități și capacități care vor merge înainte.

Cu asta în minte, mă voi îndrepta către bunul nostru prieten de la IDERA și voi afla despre instrumentul respectiv și despre cum se adresează aceste lucruri.

Ron Huizenga: Vă mulțumesc foarte mult și mulțumesc atât lui Robin, cât și Dez pentru că ați pregătit cu adevărat scena și veți vedea un pic de suprapunere în câteva lucruri despre care am vorbit. Dar au pus într-adevăr o bază foarte solidă pentru unele dintre conceptele despre care voi vorbi din perspectiva modelării datelor. Și o mulțime de lucruri pe care le-au spus îmi reiese din propria experiență când am fost consultant care lucra în modelarea datelor și arhitectura de date, împreună cu echipele - atât cascadă în primele zile, cât și în evoluție spre produse mai moderne, cu proiecte în care foloseam agil metodologii de a oferi soluții.

Deci, despre ce voi vorbi astăzi, se bazează pe acele experiențe, precum și pe o vedere a instrumentelor și a unor capacități din instrumentele pe care le folosim pentru a ne ajuta în această călătorie. Ceea ce voi acoperi foarte pe scurt este că nu voi intra în scrum în multe detalii; am avut doar o imagine de ansamblu foarte bună despre ceea ce este. Voi vorbi despre asta în termeni de, ce este un model de date și ce înseamnă cu adevărat pentru noi? Și cum permitem conceptul de modelator de date agil în organizațiile noastre, în termeni de, cum angajăm modelatorii de date, care este participarea modelatorilor și arhitecților în timpul sprintului, care sunt tipurile de activități în care ar trebui să se angajeze și, ca fundal în acest sens, care sunt câteva dintre capabilitățile importante ale instrumentelor de modelare pe care le folosim pentru a ajuta cu adevărat să faciliteze acel loc de muncă? Apoi, voi analiza un articol și voi vorbi puțin despre unele dintre valorile și beneficiile afacerii de a avea un modelator de date implicat sau despre modul în care voi spune povestea, problemele de a nu avea un modelator de date angajat pe deplin în proiecte și vă voi arăta asta bazat pe experiență și pe o diagramă de defecte a unei imagini înainte și după un proiect real cu care am fost implicat cu mulți ani în urmă. Și apoi vom rezuma câteva puncte în plus, apoi vom avea întrebări și răspunsuri în plus.

Foarte pe scurt, ER Studio este o suită foarte puternică, care are o mulțime de componente diferite pentru ea. Data Architect, care este modelul de date și arhitecții își petrec cea mai mare parte a timpului realizând modelarea datelor lor. Există și alte componente despre care nu vom vorbi deloc astăzi, cum ar fi Business Architect, unde facem modelarea proceselor și Software Architect, pentru unele dintre modelările UML. Apoi, există Repository, unde facem check-in-ul și împărtășim modelele și permitem echipelor să colaboreze la acestea și să le publice pe serverul de echipă, astfel încât mai multe audiențe interesate implicate într-un proiect să poată vedea efectiv artefactele pe care le avem ” creăm din perspectiva datelor, precum și celelalte lucruri pe care le facem în momentul livrării proiectului.

Pe ce mă voi concentra astăzi, vor fi câteva lucruri pe care le vom vedea din Data Architect și pentru că este foarte important să avem colaborarea aspectelor bazate pe depozit. În special atunci când începem să vorbim despre concepte precum gestionarea schimbărilor, care sunt imperative, nu numai proiecte de dezvoltare agile, dar orice tip de dezvoltare va continua.

Așadar, să vorbim despre modelul Agile Data Modeler pentru o clipă. Așa cum am menționat mai întâi în prezentare, este că este imperativ să avem modelatori de date și / sau arhitecți angajați pe deplin în procesele de dezvoltare agile. Acum, ceea ce s-a întâmplat istoric este, da, ne-am gândit cu adevărat la agilitate din perspectiva dezvoltării și există câteva lucruri care au continuat, care au determinat într-adevăr să se producă. O parte din aceasta s-a datorat doar naturii modului în care s-a desfășurat dezvoltarea în sine. Pe măsură ce dezvoltarea agilă a început și am început cu acest concept al echipelor de auto-organizare, dacă beți Kool-Aid puțin prea pur și ai fost pe partea extremă de programare a lucrurilor, a existat o interpretare foarte literală a unor lucruri precum echipe de auto-organizare, ceea ce o mulțime de oameni a interpretat să însemne, tot ce avem nevoie este un grup de dezvoltatori care pot construi o întreagă soluție. Indiferent dacă înseamnă dezvoltarea codului, a bazelor de date sau a bazelor de date din spatele acestuia și totul a fost retrogradat dezvoltatorilor. Dar ceea ce se întâmplă cu asta este să pierzi din abilitățile speciale pe care oamenii le au. Am descoperit că cele mai puternice echipe sunt cele care sunt compuse din oameni din diferite medii. Cum ar fi o combinație de dezvoltatori software puternici, arhitecți de date, modelatori de date, analiști de afaceri și părți interesate de afaceri, toate colaborând împreună pentru a crea o soluție finală.

Ceea ce vorbesc și astăzi este că voi face acest lucru în contextul unui proiect de dezvoltare în care dezvoltăm o aplicație care, evident, va avea și componenta de date asociată cu aceasta. Cu toate acestea, trebuie să facem un pas înapoi înainte de a face acest lucru, deoarece trebuie să realizăm că există foarte puține proiecte de dezvoltare Greenfield acolo unde ne concentrăm total pe crearea și consumul de date care sunt limitate doar în cadrul acelui proiect de dezvoltare în sine . Trebuie să facem un pas înapoi și să privim punctul de vedere organizațional în ansamblu din perspectiva datelor și a procesului. Pentru că ceea ce aflăm este informația pe care o utilizăm poate exista deja undeva în organizații. În calitate de modelatori și arhitecți, vom scoate la iveală acest lucru, astfel încât să știm de unde provine informațiile din proiectele în sine. Cunoaștem, de asemenea, structurile de date implicate, deoarece avem modele de proiectare la fel ca dezvoltatorii care au modele de design pentru codul lor. Și, de asemenea, trebuie să luăm această perspectivă organizațională generală. Nu putem doar privi datele în contextul aplicației pe care o construim. Trebuie să modelăm datele și să ne asigurăm că le documentăm, deoarece acestea trăiesc mult dincolo de aplicațiile în sine. Aceste aplicații vin și pleacă, dar trebuie să fim capabili să analizăm datele și să ne asigurăm că acestea sunt solide și bine structurate, nu numai pentru aplicații, ci și pentru deciziile care raportează activitățile, raportarea BI și integrarea în alte aplicații, interne și externe și organizațiilor noastre. Așadar, trebuie să analizăm acea imagine de ansamblu a datelor și care este ciclul de viață al acestor date și să înțelegem călătoria informațiilor din întreaga organizație, de la leagăn la mormânt.

Revenind la echipele propriu-zise și la modul în care trebuie să lucrăm efectiv, metodologia cascadei a fost percepută ca fiind prea lentă pentru a da rezultate. Pentru că, așa cum s-a arătat cu exemplul rezervorului, a fost un pas după altul și de multe ori a durat prea mult timp pentru a obține un rezultat final viabil. Ceea ce facem acum este că trebuie să avem un stil de lucru iterativ în care dezvoltăm în mod incremental componente ale acestuia și le elaborăm în timp în care producem cod utilizabil sau artefacte utilizabile, voi spune pentru fiecare sprint. Lucrul important este colaborarea între părțile interesate tehnice din echipă și părțile interesate de afaceri, deoarece colaborăm pentru a conduce acele povești ale utilizatorilor într-o viziune implementabilă a codului și a datelor care acceptă și codul respectiv. Și Agile Data Modeler va descoperi adesea că nu avem suficiente modelatori în organizații, astfel încât un modelator de date sau un arhitect să poată susține simultan mai multe echipe.

Iar celălalt aspect este că, chiar dacă avem mai mulți modelatori, trebuie să ne asigurăm că avem un set de instrumente pe care îl utilizăm, care permite colaborarea mai multor proiecte care sunt în zbor în același timp și partajarea celor artefacte de date și funcțiile de check-in și check-out. O să trec peste asta foarte repede pentru că deja am acoperit-o în secțiunea anterioară. Adevărata premisă a agilului este că te bazezi pe lucrurile din istoric, din povești sau cerințe. În cadrul iterațiilor, colaborăm ca grup. De obicei, un sprint de două săptămâni sau o lună, în funcție de organizație, este foarte frecvent. Și, de asemenea, revizuirile zilnice și reuniunile de standup, astfel încât eliminăm blocanții și să ne asigurăm că înaintăm toate aspectele înainte fără a fi opriți în diferite domenii pe măsură ce trecem. Și în aceste sprinturi vrem să ne asigurăm că producem livrări utilizabile ca o porție a fiecărui sprint.

Doar o abordare ușor diferită, extinzând-o în continuare, scrum este metodologia despre care voi vorbi mai exact aici și tocmai am extins acea imagine anterioară cu alte câteva fațete. În mod obișnuit, există un backlog de produse și apoi există un backlog sprint. Așadar, avem un rezumat general care, la începutul fiecărei repetări a sprintului, ne împiedicăm să spunem: „Ce vom construi acest sprint?” Și asta se va face într-o ședință de planificare sprint. Apoi despărțim sarcinile care sunt asociate cu acestea și executăm în acele sprinturi de la una până la patru săptămâni cu acele recenzii zilnice. Pe măsură ce facem asta, urmărim progresul nostru prin intermediul graficelor de înregistrare și a graficelor de înregistrare, pentru a urmări practic ceea ce a mai rămas de construit versus ceea ce construim pentru a stabili care este viteza de dezvoltare a noastră. program, toate acele tipuri de lucruri. Toate acestea sunt elaborate în mod continuu în timpul sprint-ului, mai degrabă decât să parcurgi câteva luni pe drum și să afli că vei veni scurt și trebuie să extindeți programul proiectului. Și foarte important, ca parte a întregii echipe, există o revizuire sprint la final și o retrospectivă sprint, așa că, înainte de a da startul următoarei iterații, analizați ceea ce ați făcut și căutați modalități prin care puteți îmbunătățiți-vă la data viitoare prin.

În ceea ce privește livrabile, acesta este practic un slide care rezumă tipurile tipice de lucruri care se petrec în sprinturi. Și este foarte centrat în dezvoltare, așa că o mulțime de lucruri pe care le vedem aici, cum ar fi, proiectări funcționale și cazuri de utilizare, care fac teste de cod de proiectare, când privim aceste casete aici și nu o să le parcurg în orice nivel de detaliu, sunt foarte orientate spre dezvoltare. Și îngropat dedesubt aici este și faptul că trebuie să avem și acele livrări de date care merg mână în mână cu acest lucru pentru a susține acest efort. Așadar, de fiecare dată când vedem lucruri precum întârzierile, cerințele și poveștile utilizatorilor, pe măsură ce parcurgem, trebuie să analizăm care sunt piesele de dezvoltare pe care trebuie să le facem, care sunt piesele de analiză pe care trebuie să le facem, cât despre proiectarea datelor sau modelul de date, cum ar fi lucrurile precum glosarele de afaceri, astfel încât să putem asocia semnificația afacerii cu toate artefactele pe care le producem? Pentru că trebuie să producem aceste livrări utilizabile în fiecare sprint.

Unii oameni vor spune că trebuie să producem cod utilizabil la sfârșitul fiecărui sprint. Nu este neapărat cazul, adică într-o perspectivă de dezvoltare cea mai pură, dar destul de des - mai ales la început - s-ar putea să avem ceva de genul zero sprint, unde suntem concentrați pur și simplu pe lucrurile în picioare, făcând lucruri precum obținerea strategiilor noastre de testare în loc. Un design la nivel înalt pentru a-l începe înainte de a începe să completăm detaliile și să ne asigurăm că avem un set curat de povești de pornire sau cerințe înainte de a începe să angajăm alte categorii de public și apoi să construim mai departe ca o echipă pe măsură ce mergem înainte. Există întotdeauna un pic de timp de pregătire, așa că de multe ori vom avea un sprint zero sau chiar un sprint zero și unul. Ar putea fi un pic de fază de pornire înainte de a ajunge la zborul complet în furnizarea soluției.

Să vorbim despre modele de date în acest context foarte pe scurt. Când oamenii se gândesc la modele de date, de multe ori se gândește la un model de date ca fiind o imagine a modului în care diferitele informații se leagă - acesta este doar vârful aisbergului. Pentru a întruchipa pe deplin spiritul modului în care doriți cu adevărat să abordați modelarea datelor - indiferent dacă este în dezvoltare agilă și alte lucruri - este necesar să vă dați seama că modelul de date, dacă este făcut corect, devine specificația dvs. completă pentru ceea ce înseamnă aceste date în organizație și modul în care este implementat în bazele de date back-end. Când spun baze de date, mă refer nu numai la bazele de date relaționale pe care le putem folosi, ci în arhitecturile de astăzi unde avem date mari sau platforme NoSQL, așa cum prefer să le numesc. De asemenea, acele magazine de date mari, deoarece putem combina o mulțime de magazine de date diferite în ceea ce privește consumarea informațiilor și aducerea acestora în soluțiile noastre, precum și modul în care persistăm sau salvăm informațiile din soluțiile noastre.

Este posibil să lucrăm cu mai multe baze de date sau surse de date simultan în contextul unei aplicații date. Ceea ce este foarte important este să dorim să putem avea o specificație completă, deci o specificație logică a ceea ce înseamnă asta pentru o perspectivă organizațională sprint, ceea ce sunt construcțiile fizice în termenii modului în care definim de fapt datele, relațiile dintre acestea bazele de date, restricțiile dvs. de integritate referențială, verificarea constrângerilor, toate acele piese de validare la care vă gândiți de obicei. Metadatele descriptive sunt extrem de importante. Cum știi să folosești datele din aplicațiile tale? Cu excepția cazului în care îl poți defini și știi ce înseamnă sau știi de unde a venit pentru a te asigura că consumi datele corecte în acele aplicații - asigurându-te că avem convenții de denumire corecte, definiții complete, ceea ce înseamnă un dicționar complet de date pentru nu numai tabelele, dar coloanele care cuprind aceste tabele - și detalii despre implementarea detaliilor despre modul în care folosim asta, deoarece trebuie să construim această bază de cunoștințe, deoarece chiar și atunci când această aplicație este finalizată, aceste informații vor fi folosite pentru alte inițiative, deci trebuie să ne asigurăm că avem toate acestea documentate pentru implementări viitoare.

Din nou, ajungem la lucruri precum tipuri de date, chei, indexuri, modelul de date în sine întruchipează o mulțime de reguli de afaceri care intră în joc. Relațiile nu sunt doar constrângeri între diferite tabele; de multe ori ne ajută să descriem care sunt adevăratele reguli de afaceri în jurul modului în care se comportă aceste date și cum funcționează împreună ca unitate de coeziune. Și desigur, restricțiile de valoare sunt foarte importante. Acum, desigur, unul dintre lucrurile cu care ne ocupăm în permanență și devine tot mai răspândit, sunt lucruri precum guvernarea datelor. Deci, dintr-o perspectivă de guvernare a datelor, trebuie să analizăm și ceea ce definim aici? Vrem să definim lucruri precum clasificări de securitate. Cu ce ​​tipuri de date avem de-a face? Ce va fi considerat managementul principal al datelor? Care sunt magazinele tranzacționale pe care le creăm? Ce date de referință folosim în aceste aplicații? Trebuie să ne asigurăm că este capturat corect în modelele noastre. Și, de asemenea, considerente privind calitatea datelor, există anumite informații care sunt mai importante pentru o organizație decât altele.

Am fost implicat în proiecte în care înlocuiam peste o duzină de sisteme vechi cu noi procese de afaceri și proiectam noi aplicații și magazine de date care să le înlocuiască. Trebuia să știm de unde provin informațiile. Care pentru cele mai importante informații, din perspectiva afacerii, dacă te uiți la acest diapozitiv de model de date special pe care l-am obținut aici, vei vedea că casetele de jos din aceste entități particulare, care este doar un subset mic, Am reușit să surprindem valoarea afacerii. Indiferent dacă este înalt, mediu sau scăzut pentru aceste tipuri de lucruri pentru aceste construcții diferite în cadrul organizației. Și am capturat și lucruri precum orele de date master, fie că sunt tabele master, fie că sunt de referință, dacă erau tranzacționale. Prin urmare, ne putem extinde metadatele în modelele noastre pentru a ne oferi o mulțime de alte caracteristici în afara datelor în sine, ceea ce ne-a ajutat cu alte inițiative în afara proiectelor inițiale și să le ducem mai departe. Acum, asta a fost mult într-un singur diapozitiv, o să parcurg restul acestor destul de repede.

Acum voi vorbi foarte repede despre ce face un modelator de date pe măsură ce parcurgem aceste sprinturi diferite. În primul rând, un participant complet la sesiunile de planificare sprint, în care preluăm poveștile utilizatorilor, ne angajăm la ceea ce urmează să livrăm în acel sprint și ne dăm seama cum îl vom structura și livra. Ceea ce fac și ca modelator de date este că știu că voi lucra în zone separate cu diferiți dezvoltatori sau cu persoane diferite. Așadar, una dintre caracteristicile importante pe care le putem avea este atunci când facem un model de date, putem împărți acel model de date în puncte de vedere diferite, indiferent dacă le numim domenii de subiect sau sub-modele, este terminologia noastră. Așadar, pe măsură ce construim modelul, îl prezentăm și în aceste perspective sub-model diferite, astfel încât diferitele audiențe văd doar ce este relevant pentru ei, astfel încât să se poată concentra pe ceea ce dezvoltă și propun. Aș putea să am pe cineva care să lucreze la o parte a programării unei aplicații, aș putea avea pe cineva care lucrează la o intrare de comandă în care facem toate aceste lucruri într-un singur sprint, dar le pot oferi punctele de vedere prin acele sub-modele care doar aplicați în zona în care lucrează. Și apoi cei care se apropie de modelul de ansamblu și de întreaga structură a sub-modelelor pentru a oferi opiniei publicului diferite ceea ce trebuie să vadă.

Fundamentele dintr-o perspectivă de modelare a datelor pe care dorim să o avem este, să avem întotdeauna o bază de referință la care să ne putem întoarce, deoarece unul dintre lucrurile la care trebuie să putem face este, fie că este la sfârșitul unui sprint sau la sfârșitul din mai multe sprinturi, vrem să știm de unde am început și să avem întotdeauna o bază pentru a ști care a fost delta sau diferența dintre ceea ce am produs într-un sprint dat. De asemenea, trebuie să ne asigurăm că putem avea o schimbare rapidă. Dacă intrați în ea ca modelator de date, dar în rolul tradițional de gatekeeper de a spune „Nu, nu, nu puteți face asta, trebuie să facem toate aceste lucruri mai întâi”, veți fi excluse din echipă atunci când veți avea nevoie cu adevărat să fie un participant activ la toate acele echipe de dezvoltare agile. Asta înseamnă că unele lucruri cad din vagon făcând un sprint dat și le ridicați în sprinturi ulterioare.

Ca un exemplu, vă puteți concentra pe structurile de date doar pentru a face ca dezvoltarea să spună, acea piesă de intrare a comenzii despre care vorbeam. Într-un sprint ulterior, este posibil să reveniți și să completați datele, precum unele documentații pentru dicționarul de date din jurul unora dintre acele artefacte pe care le-ați creat. Nu veți completa această definiție într-un singur sprint; aveți de gând să continuați la livrările dvs. în mod incremental, deoarece vor exista momente în care puteți completa aceste informații care lucrează cu analiștii de afaceri atunci când dezvoltatorii sunt ocupați să construiască aplicațiile și persistența din jurul acestor magazine de date. Vrei să facilitezi și să nu fii blocajul. Există diferite modalități prin care lucrăm cu dezvoltatorii. Pentru unele aspecte, avem modele de proiectare, astfel încât suntem un participant complet în față, așa că este posibil să avem un model de proiectare în care vom spune că îl vom pune în model, îl vom împinge către bazele de date pentru sandbox-uri ale dezvoltatorilor și apoi vor putea începe să lucrezi cu ea și să solicite modificări.

Pot exista și alte domenii la care dezvoltatorii au lucrat, au ceva în care lucrează și prototipizează anumite lucruri, astfel încât să încerce unele lucruri în propriul lor mediu de dezvoltare. Luăm baza de date cu care au lucrat, o introducem în instrumentul nostru de modelare, comparăm cu modelele pe care le avem și apoi rezolvăm și împingem modificările înapoi la ele, astfel încât să le poată refacta codurile, astfel încât să urmeze structurile de date adecvate că avem nevoie. Pentru că este posibil să fi creat unele lucruri pe care le-am avut deja în altă parte, așa că ne asigurăm că lucrează cu sursele de date potrivite. Pur și simplu continuăm să repetăm ​​acest lucru până la sprintul nostru, astfel încât să obținem datele complete, documentația completă și definiția tuturor acelor structuri de date pe care le producem.

Cele mai de succes proiecte agile cu care am fost implicat în ceea ce privește livrări foarte bune este, am avut o filozofie, modelarea tuturor modificărilor la specificația completă a bazelor de date fizice. În esență, modelul de date devine bazele de date dislocate cu care lucrezi pentru orice este nou creat și are referințe complete ale celorlalte depozite de date dacă consumăm din alte baze de date externe. Ca parte a acestui lucru, producem scripturi incrementale versus o generație completă de fiecare dată. Și folosim modelele noastre de proiectare pentru a ne oferi această ridicare rapidă în ceea ce privește obținerea lucrurilor în sprinturi cu diferitele echipe de dezvoltare cu care lucrăm.

De asemenea, în activitățile de sprint, este din nou acea bază de referință pentru comparație / îmbinare, deci să luăm ideea modelării fiecărei modificări. De fiecare dată când facem o schimbare, ceea ce vrem să facem este să vrem să modelăm schimbarea și ceea ce este foarte important, ceea ce a lipsit din modelarea datelor până de curând, de fapt, până când am reintrodus-o, este capacitatea de a asocia modelarea sarcinile și rezultatele dvs. cu poveștile și sarcinile utilizatorului care determină efectiv modificările respective. Vrem să putem verifica modificările modelului nostru, în același mod în care dezvoltatorii verifică codurile lor, făcând referire la acele povești de utilizator pe care le avem, astfel încât să știm de ce am făcut schimbări în primul rând, asta este ceva ce facem. Când facem asta, ne generează scripturile DDL incrementale și le postăm astfel încât să poată fi preluate cu celelalte rezultate de dezvoltare și verificate în soluția noastră de compilare. Din nou, este posibil să avem un model sau să lucrăm cu mai multe echipe. Și cum am vorbit, unele lucruri sunt create de modelatorul de date, alte lucruri sunt create de dezvoltatori și ne întâlnim la mijloc pentru a veni cu cel mai bun design general și a-l împinge înainte și pentru a ne asigura că este proiectat corect în structuri generale de date. Trebuie să menținem disciplina de a ne asigura că avem toate construcțiile corespunzătoare în modelul nostru de date pe măsură ce mergem înainte, inclusiv lucruri precum valori nule și nu nule, constrângeri referențiale, verificând practic constrângerile, toate acele lucruri la care ne-am gândi de obicei. .

Să vorbim acum despre câteva capturi de ecran ale unora dintre instrumentele care ne ajută să facem acest lucru. Ceea ce cred eu important este să avem acel depozit colaborativ, deci ceea ce putem face ca modelatori de date - și acesta este un fragment din o parte a unui model de date în fundal - este atunci când lucrăm la lucruri pe care vrem să ne asigurăm că putem lucrați doar la obiectele pe care trebuie să le putem modifica, să facem modificările, să generăm scripturile noastre DDL pentru modificările pe care le-am făcut pe măsură ce verificăm lucrurile înapoi. Deci, ceea ce putem face este, în ER Studio este un exemplu, putem verifica obiecte sau grupuri de obiecte pentru a lucra, nu trebuie să verificăm un model întreg sau un sub-model, putem verifica doar acele lucruri care ne interesează. Ceea ce vrem să facem după aceea este fie la check-out, fie la check-in time - o facem în ambele moduri, deoarece diferite echipe de dezvoltare lucrează în moduri diferite. Vrem să ne asigurăm că o asociem cu povestea sau sarcina utilizatorului care conduce la cerințele pentru aceasta și care va fi aceeași poveste de utilizator sau sarcină pentru care dezvoltatorii vor dezvolta și își vor verifica codul.

Iată un fragment foarte rapid de câteva ecrane ale unuia dintre centrele noastre de gestionare a schimbărilor. Ce face asta, nu voi parcurge aici în detaliu mare, dar ceea ce vedeți este povestea sau sarcina utilizatorului și indentat sub fiecare dintre cele pe care le vedeți înregistrările de schimbare efective - am creat o înregistrare de schimbare automată atunci când efectuăm check-in-ul și check-out-ul și putem pune și mai multe descrieri în acea înregistrare a modificărilor. Este asociat cu sarcina, putem avea mai multe modificări pe fiecare sarcină, așa cum vă așteptați. Și când intrăm în acea înregistrare a schimbărilor, o putem privi și mai important să vedem, ce am schimbat de fapt? Pentru această particularitate, povestea evidențiată acolo am avut un tip de schimbare care a fost făcută și când m-am uitat la înregistrarea efectivă în sine, a identificat piesele individuale din modelul care s-a schimbat. Am schimbat câteva atribute aici, le-am analizat și le-am adus pentru călătorie viziunile care trebuiau schimbate și care depindeau de acestea, astfel încât să fie generate în DLL incremental. Nu este doar modelarea pe obiectele de bază, dar un instrument de modelare de mare putere ca acesta, de asemenea, detectează modificările care trebuie umplute prin obiectele dependente din baza de date sau modelul de date.

Dacă lucrăm cu dezvoltatori și facem acest lucru în câteva lucruri diferite, adică facem ceva în sandbox-ul lor și vrem să comparăm și să vedem unde sunt diferențele, folosim capabilități de comparare / îmbinare unde sunt pe partea dreaptă și stânga latură. Putem spune: „Iată modelul nostru din partea stângă, iată baza lor de date din partea dreaptă, arată-mi diferențele.” Putem alege apoi și alege cum rezolvăm aceste diferențe, indiferent dacă împingem lucrurile în baza de date sau dacă există câteva lucruri pe care le au în baza de date pe care le readucem în model. Putem merge bidirecțional, astfel încât să putem merge ambele direcții actualizând simultan atât sursa cât și ținta și apoi să producem scripturile DDL incrementale pentru a implementa acele modificări în mediul bazei de date în sine, ceea ce este extrem de important. Ceea ce putem face, de asemenea, putem folosi această capacitate de comparare și îmbinare la un moment dat, dacă luăm instantanee pe parcurs, putem compara întotdeauna începutul unui sprint cu începutul sau sfârșitul unui alt sprint, astfel încât să putem vedea modificarea completă a ceea ce a fost făcut într-un sprint de dezvoltare dat sau pe o serie de sprinturi.

Acesta este un exemplu foarte rapid de modificare a scriptului, oricare dintre voi care a lucrat cu baze de date va fi văzut acest tip de lucruri, acesta este ceea ce putem împinge din cod ca un script alternativ, astfel încât să ne asigurăm că păstrează lucrurile aici. Ceea ce am scos de aici, doar pentru a reduce dezordinea, este ceea ce facem și cu aceste alte scripturi este să presupunem că există și date în acele tabele, deci vom genera și DML-ul care va atrage informațiile din tabelele temporare și împingeți-l înapoi în noile structuri de date, așa că ne uităm nu numai la structuri, dar la datele pe care le-am putut conține deja în acele structuri.

Vom discuta foarte repede despre sisteme automate de construire, deoarece atunci când facem un proiect agil destul de des, lucrăm cu sisteme de construire automate, unde trebuie să verificăm împreună diferitele rezultate care să ne asigure că nu ne rupem. Ceea ce înseamnă că este să sincronizăm livrările, acele schimbări de scripturi despre care am vorbit cu scriptul DDL trebuie să fie înregistrate, codul aplicației corespunzător trebuie să fie conectat în același timp și o mulțime de dezvoltatori de dezvoltare acum, desigur, nu este fiind realizată cu SQL direct împotriva bazelor de date și a acelui tip de lucru. Destul de des folosim cadre de persistență sau construim servicii de date. Trebuie să ne asigurăm că modificările pentru aceste cadre sau servicii sunt verificate exact în același timp. Acestea intră într-un sistem automatizat de construire în unele organizații și dacă construirea se întrerupe, într-o metodologie agilă, totul este bazat pe fixarea punții care se construiește înainte de a merge mai departe, astfel încât să știm că avem o soluție de lucru înainte de a merge mai departe. Și unul dintre proiectele în care am fost implicat, am dus acest lucru la extrem - dacă construirea s-a rupt, pe care de fapt ne-am atașat-o la o serie de computere din zona noastră unde am fost colocați cu utilizatorii de afaceri, aveam lumini intermitente roșii doar ca vârful mașinilor poliției. Și dacă construcția s-a rupt, acele lumini intermitente roșii au început să se stingă și știam că totul este pe mâini pe punte: reparați construcția și apoi continuați cu ceea ce făceam.

Vreau să vorbim despre alte lucruri, iar aceasta este o capacitate unică pentru ER Studio, ajută cu adevărat atunci când încercăm să construim aceste artefacte ca dezvoltatori pentru aceste granițe de persistență, avem un concept numit obiecte de date de afaceri și ceea ce ne permite este de făcut dacă privim acest model de date foarte simplist ca exemplu, acesta ne permite să încapsulăm entități sau grupuri de entități pentru unde se află limitele persistenței. În cazul în care noi, ca modelator de date, ne putem gândi la ceva precum un antet al comenzii de cumpărare și alinierea comenzilor și alte tabele detaliate care ar lega de asta în modul în care o construim și dezvoltatorii serviciilor noastre de date trebuie să știe cum lucrurile persistă la aceste date diferite structuri. Dezvoltatorii noștri se gândesc la lucruri precum comanda de achiziție ca obiect în general și care este contractul lor cu modul în care creează acele obiecte particulare. Putem expune acel detaliu tehnic, astfel încât oamenii care construiesc serverele de date să vadă ce se află sub el și să putem proteja celelalte audiențe de complexități, astfel încât să vadă doar diferitele obiecte de nivel superior, care funcționează foarte bine și pentru comunicarea cu afacerile. analiști și părți interesate de afaceri atunci când vorbim despre interacțiunea diferitelor concepte de afaceri.

Lucrul frumos despre asta este, de asemenea, să extindem și să dărâmăm în mod constructiv, astfel încât să putem menține relațiile dintre obiectele de ordin superior, chiar dacă își au originea în construcții care sunt conținute în cadrul acestor obiecte de date comerciale. Acum ca model, ajungeți la sfârșitul sprintului, la sfârșitul sprintului, am o mulțime de lucruri pe care trebuie să le fac, pe care le numesc menaj pentru următorul sprint. Fiecare sprint creez ceea ce numesc lansarea numită - asta îmi oferă baza mea pentru ceea ce am acum la sfârșitul lansării. Așadar, asta înseamnă că aceasta este baza mea de mers înainte, toate aceste linii de bază sau versiuni denumite pe care le creez și le salvează în depozitul meu pe care le pot folosi pentru a face o comparație / îmbinare, astfel încât să pot compara întotdeauna cu orice capăt dat de sprint din orice alt sprint, care este foarte important să știți care au fost modificările dvs. la modelul dvs. de date pe parcursul călătoriei sale.

De asemenea, creez un script DDL delta folosind comparația / îmbinarea din nou de la început până la sfârșitul sprintului. Este posibil să fi verificat într-o grămadă de scripturi incrementale, dar dacă am nevoie, acum am un script pe care îl pot implementa pentru a pune în picioare alte cutii de nisip, așa că pot spune doar acest lucru pe care l-am avut la începutul unui sprint. Prin intermediul, creăm o bază de date ca o cutie de nisip pentru a începe cu următorul sprint și putem folosi, de asemenea, acele lucruri pentru a face lucruri precum instanțele de control standard și, în cele din urmă, dorim să ne împingem modificările către producție, astfel încât să avem mai multe lucruri în desfășurare. in acelasi timp. Din nou, participăm pe deplin la planificarea și retrospectivele sprint-urilor, retrospectivele sunt cu adevărat lecțiile învățate și asta este extrem de important, deoarece puteți merge foarte repede în timpul agil, trebuie să vă opriți și să celebrați succesele, ca și acum. Descoperiți ce este greșit, faceți-o mai bună data viitoare, dar și sărbătoriți lucrurile care au decurs bine și construiți-le pe măsură ce continuați să mergeți înainte în următoarele sprinturi care vor merge mai departe.

Acum voi vorbi foarte repede despre valoarea afacerii. A fost un proiect în care m-am implicat cu mulți ani în urmă, care a început ca un proiect agil și a fost un proiect extrem, deci a fost o echipă pură de auto-organizare, unde erau doar dezvoltatori care făceau totul. Pentru a face o poveste lungă, acest proiect s-a oprit și au descoperit că petrec din ce în ce mai multe ori pentru remedierea și remedierea defectelor identificate decât pentru a promova mai multă funcționalitate și, de fapt, când au privit-o pe listele de desfacere, trebuiau să extindă proiectul cu șase luni cu un cost imens. Și când ne-am uitat la ea, modul de remediere a problemei a fost utilizarea unui instrument adecvat de modelare a datelor cu un modelator de date calificat implicat în proiectul însuși.

Dacă vă uitați la această bară verticală din acest grafic special, aceasta arată defecte cumulative față de obiecte cumulate, și vorbesc despre obiecte de date sau constructe care au fost create, cum ar fi tabelele cu constrângerile și acele tipuri de lucruri, dacă ați privit înainte de introducerea modelatorului de date, numărul defectelor depășea efectiv și începea să creeze un decalaj față de numărul real de obiecte produse până la acel moment. După săptămâna 21, adică atunci când a intrat modelatorul de date, a refacturat modelul de date pe baza a ceea ce trebuia să remedieze o serie de lucruri și apoi a început modelarea ca parte a echipei de proiect, înainte, modificările pe măsură ce acel proiect a fost împins înainte . Și ați observat o transformare foarte rapidă, care în aproximativ un sprint și jumătate, am văzut o ridicare uriașă a numărului de obiecte și constructe de date care au fost generate și construite pentru că generam dintr-un instrument de modelare a datelor, mai degrabă decât un stick de dezvoltator. construindu-le într-un mediu și erau corecte, deoarece aveau integritatea referențială corespunzătoare și celelalte construcții pe care ar trebui să le aibă. Nivelul defectelor față de cele aproape plane. Luând măsurile corespunzătoare și asigurându-ne că modelarea datelor a fost complet angajată, proiectul a fost livrat la timp cu un nivel de calitate mult mai ridicat și, de fapt, nu s-ar fi realizat deloc dacă acești pași nu ar fi avut loc. Există o mulțime de eșecuri agile, există, de asemenea, o mulțime de succese agile dacă ați obține oamenii potriviți în rolurile potrivite. Sunt un mare susținător de agil ca disciplină operațională, dar trebuie să vă asigurați că aveți abilitățile tuturor grupurilor corecte implicate ca echipe de proiect în timp ce mergeți mai departe într-un tip agil de efort.

Pentru a rezuma, arhitecții și modelatorii de date trebuie să fie implicați în toate proiectele de dezvoltare; ei sunt într-adevăr lipiciul care ține totul împreună, deoarece, în calitate de modelatori și arhitecți, înțelegem, nu numai construcțiile de date ale proiectului de dezvoltare dat, ci și locul în care datele există în organizație și unde putem furniza aceste date și, de asemenea, cum acestea va fi folosit și utilizat în afara aplicației în sine pe care o lucrăm. Înțelegem relațiile complexe de date și este esențial să putem merge mai departe și, din perspectiva guvernării, să documentați harta și să înțelegeți cum arată peisajul dvs. complet de date.

Este ca fabricarea; Am venit dintr-un context de fabricație. Nu puteți inspecta calitatea în ceva la sfârșit - trebuie să vă integrați calitatea în proiectarea dvs. în avans și în drumul dvs., iar modelarea datelor este un mod de a construi această calitate în design într-un mod eficient și rentabil până la capăt . Și, din nou, ceva de reținut - și acest lucru nu trebuie să se amestece, ci este adevărul - aplicațiile vin și pleacă, datele sunt activul corporativ vital și transcende toate limitele aplicațiilor. De fiecare dată când introduceți o aplicație, vi se solicită probabil să păstrați datele din alte aplicații care au apărut înainte, așa că trebuie doar să ne amintim că este un atu corporatist vital pe care îl menținem în timp.

Si asta e! De aici vom lua mai multe întrebări.

Eric Kavanagh: Bine, bine, lasă-mă să o dau mai întâi lui Robin. Și atunci, Dez, sunt sigur că ai câteva întrebări. Scoate-l, Robin.

Dr. Robin Bloor: Bine. Sincer, nu am avut niciodată nicio problemă cu metodele de dezvoltare agile și mi se pare că ceea ce faci aici are sens eminent. Îmi amintesc că am analizat ceva din anii '80, care a indicat, într-adevăr, că problema cu care te confrunți în termeni de proiect care se depășește de sub control, este în mod normal dacă lași o greșeală să persiste dincolo de o anumită etapă. Pur și simplu devine din ce în ce mai dificil de remediat dacă nu obțineți acea etapă corect, deci unul dintre lucrurile pe care le faceți aici - și cred că acesta este diapozitivul - dar unul dintre lucrurile pe care le faceți aici în sprint zero, în opinia mea, este absolut important pentru că încercați cu adevărat să puneți livrabile fixate acolo. Și dacă nu primiți livrabile fixate, atunci livrabile își schimbă forma.

Asta e, părerea mea. De asemenea, este părerea mea - nu am niciun argument cu ideea că trebuie să obțineți modelarea datelor la un anumit nivel de detaliu înainte de a trece. Ceea ce mi-aș dori să încercați să faceți, deoarece nu am înțeles complet acest lucru, este doar să descriu unul dintre aceste proiecte în ceea ce privește dimensiunea sa, în ceea ce privește modul în care a decurs, în termeni de cine, știți, unde s-au rezolvat problemele, au fost rezolvate? Deoarece cred că acest diapozitiv este aproape de inima ei și dacă ai putea elabora un pic mai mult despre asta, aș fi foarte recunoscător.

Ron Huizenga: Sigur, și voi folosi câteva exemple de proiecte. Cel care, într-un fel, a plecat de pe șinele care au fost readuse prin implicarea efectivă a persoanelor potrivite și realizarea modelării datelor și totul a fost într-adevăr un mod de a ne asigura că designul a fost înțeles mai bine și, evident, avem o implementare mai bună a proiectării. pe parcurs prin modelarea acesteia. Deoarece atunci când îl modelați, știți, puteți genera DDL și totul din spatele și din instrument, mai degrabă decât să fie nevoiți să construiți acest lucru cum ar putea face oamenii, de obicei, intrând direct într-un mediu de bază de date. Și lucruri tipice care se vor întâmpla cu dezvoltatorii este că vor intra acolo și vor spune, bine, am nevoie de aceste tabele. Să zicem că facem înregistrări de comenzi. Astfel, pot crea antetul comenzii și tabelele de detalii ale comenzii și acele tipuri de lucruri. Dar foarte des vor uita sau neglija pentru a se asigura că restricțiile sunt acolo pentru a reprezenta relațiile cheie străine. Este posibil să nu aibă cheile corecte. Convențiile de denumire pot fi, de asemenea, suspecte. Nu știu de câte ori am intrat într-un mediu, de exemplu, unde vezi o grămadă de tabele diferite cu nume diferite, dar apoi numele coloanelor din acele tabele sunt ca ID, Nume sau orice altceva, deci Am pierdut într-adevăr contextul fără tabelul cu exactitate.

Deci, de obicei, atunci când modelăm date, ne vom asigura că aplicăm convenții de denumire adecvate la toate artefactele care sunt generate și în DDL. Dar a fi mai specific despre natura proiectelor în sine înseamnă, în general, vorbesc despre inițiative destul de mari. Unul dintre ei a fost un proiect de transformare a afacerilor de 150 de milioane de dolari, unde am înlocuit peste o duzină de sisteme moștenite. Am avut cinci echipe diferite, agile, care se desfășoară simultan. Aveam o echipă completă de arhitectură a datelor, așa că aveam modelatori de date din echipa mea încorporate în fiecare dintre celelalte echipe din zona de aplicații și lucram cu o combinație de experți în afaceri interni care cunoșteau subiectul, care făceau obiectul povești de utilizator pentru cerințele în sine. Am avut analiști de afaceri în fiecare dintre acele echipe care au modelat efectiv procesul de afaceri, cu diagramele de activitate sau diagramele procesului de afaceri, ajutând să redea mai mult poveștile utilizatorilor cu utilizatorii înainte de a fi consumați și de restul echipei.

Și apoi, bineînțeles, dezvoltatorii care construiau codul aplicației peste asta. Și am lucrat și noi, cred că erau patru furnizori diferiți de integrare a sistemelor care construiau diferite părți ale aplicației, unde o echipă construia serviciile de date, cealaltă construia logica aplicațiilor într-o zonă, alta care avea expertiză. într-o altă zonă de afaceri se construia logica aplicației în acea zonă. Deci am avut o întreagă colaborare de oameni care lucrau la acest proiect. La acea, în special, am avut 150 de oameni pe țărm în echipă și alte 150 de resurse în larg în echipa care colaborau cu sprinturi de două săptămâni pentru a scoate acest lucru. Pentru a face asta, trebuie să vă asigurați că trageți pe toți cilindrii și toată lumea este bine sincronizată în ceea ce privește livrările lor și aveți acele resetări frecvente pentru a vă asigura că finalizăm livrările tuturor artefactelor necesare. la sfârșitul fiecărui sprint.

Dr. Robin Bloor: Ei bine, este impresionant. Și doar pentru ceva mai multe detalii despre asta - ați ajuns la o completă, cum aș numi, harta MDM a întregii zone de date de la finalul acelui proiect?

Ron Huizenga: Am avut un model complet de date care a fost defalcat odată cu descompunerea dintre toate diferitele domenii de afaceri. Dicționarul de date în sine în ceea ce privește definițiile complete a căzut puțin. Am avut cele mai multe tabele definite; aveam cele mai multe coloane definite ca exact ceea ce însemnau. Au existat unele care nu erau acolo și, destul de interesant, multe dintre acestea au fost informații provenite din sistemele moștenite în care, după terminarea domeniului de aplicare al proiectului, aceasta era încă documentată ca un set de reportaj artefacte, cum ar fi fost, în afara proiectului în sine, pentru că a fost ceva care trebuia să fie susținut de către organizație care merge mai departe. Așadar, în același timp, organizația a avut o perspectivă mult mai mare a importanței guvernanței datelor, deoarece am observat o mulțime de deficiențe în acele sisteme de moștenire și în acele surse de date moștenite pe care încercam să le consumăm pentru că nu erau documentate. În multe cazuri, aveam doar baze de date pe care trebuia să le inversăm inginerului și să încercăm să ne dăm seama ce era acolo și pentru ce erau informațiile.

Dr. Robin Bloor: Nu mă surprinde acest aspect particular. Guvernarea datelor este, să o numim, o preocupare foarte modernă și cred că, într-adevăr, există foarte multe lucrări care, să zicem, ar fi trebuit să fie făcute istoric în ceea ce privește guvernarea datelor. Niciodată n-a fost pentru că ai putea, cumva, să scapi să nu o faci. Dar, deoarece resursa de date a crescut și a crescut, în cele din urmă nu ați putut.

Oricum, voi trece la Dez pentru că cred că am avut timpul alocat. Dez?

Dez Blanchfield: Da, mulțumesc. Prin tot acest lucru, mă uit și mă gândesc la mine că vorbim despre a vedea agil folosit în furie în multe feluri. Deși asta are conotații negative; Am vrut să spun asta într-un mod pozitiv. Puteți să ne dați doar un scenariu, adică sunt două locuri în care pot vedea că este un set perfect: unul este proiecte noi care trebuie făcute doar din prima zi, dar cred că invariabil, în experiența mea, este adesea cazul în care proiectele devin suficient de mari încât acest lucru este necesar în multe feluri, există o provocare interesantă între lipirea celor două lumi, nu? Puteți să ne oferiți un fel de cunoaștere a unor povești de succes pe care le-ați văzut unde ați intrat într-o organizație, este clar că au obținut o ușoară ciocnire a celor două lumi și ați reușit să puneți cu succes acest lucru în loc și să aducă proiecte mari la un loc unde altfel ar fi putut merge pe șine? Știu că este o întrebare foarte largă, dar mă întreb dacă există un studiu de caz anume pe care îl puteți, într-un fel, să indicați unde ați spus, știți, am pus toate acestea la punct și a adus toată echipa de dezvoltare împreună cu echipa de date și am abordat, într-un fel, ceva care ar fi putut scufunda barca?

Ron Huizenga: Sigur, și de fapt singurul proiect care s-a întâmplat a fi un proiect de conductă a fost cel la care am făcut aluzie în cazul în care am arătat acea diagramă cu defectele înainte și după ce a fost implicat modelatorul de date. Destul de des, și există noțiuni preconcepute, mai ales dacă lucrurile sunt învârtite acolo unde se face dintr-o perspectivă pur de dezvoltare, sunt doar dezvoltatorii care sunt implicați în aceste proiecte agile pentru a livra aplicațiile. Așadar, ceea ce s-a întâmplat acolo, desigur, este că au dat jos șinele și artefactele lor de date în special, sau livrările de date pe care le produceau, au scăzut din punct de vedere al calității și au abordat cu adevărat lucrurile în general. Și există destul de des această concepție greșită potrivit căreia modelatorii de date vor încetini proiectele și vor fi în cazul în care modelatorul de date nu are atitudinea corectă. Așa cum spun eu, trebuie să pierdeți - uneori există modelatori de date care au acea atitudine tradițională de gatekeeper în care, „Suntem aici pentru a controla cum arată structurile de date”, iar mentalitatea trebuie să dispară. Oricine este implicat într-o dezvoltare agilă, în special modelatorii de date, trebuie să își asume un rol de facilitator pentru a ajuta într-adevăr echipele să avanseze. Și cel mai bun mod de a ilustra asta este să arătați foarte rapid echipelor cât de productive pot fi modelând mai întâi schimbările. Și din nou, de aceea am vorbit despre colaborare.

Există câteva lucruri pe care le putem modela mai întâi și generam DDL pentru a le transmite dezvoltatorilor. De asemenea, dorim să ne asigurăm că nu li se pare că sunt restricționate. Așadar, dacă există lucruri pe care lucrează, permiteți-le să lucreze în casetele de nisip pentru dezvoltare, deoarece acolo dezvoltatorii lucrează la propriile lor desktop sau la alte baze de date pentru a face unele schimbări acolo unde testează lucrurile. Și colaborează cu ei și spune: „Bine, lucrează cu asta.” Îl vom introduce în instrument, îl vom rezolva și apoi îl vom împinge înainte și vă vom oferi scripturile pe care le puteți implementa pentru a vă actualiza bazele de date pentru a le actualiza la ceea ce va fi adevărata concepție a producției sancționate, pe măsură ce continuăm să avansăm. Și puteți transforma asta într-un mod foarte rapid. Am descoperit că zilele mele s-au umplut unde mă întorceam înainte și înainte cu iterarea cu diferite echipe de dezvoltare, uitându-mă la schimbări, comparând, generând scripturi, făcându-le să meargă și am putut să mă mențin cu patru echipe de dezvoltare destul de ușor odată a obținut un impuls.

Dez Blanchfield: Unul dintre lucrurile care îmi vin în minte este faptul că, știți, o mulțime de conversații pe care le-am purtat zilnic sunt despre acest tren de marfă care vine la noi, un fel de mașină -machine și IoT. Și dacă ne gândim că avem o mulțime de date acum asupra mediilor noastre actuale din întreprindere, știți, dacă luăm deoparte unicornii pentru un moment în care știm că Googles, Facebook-urile și Ubers-urile au petabytes de date, dar într-o întreprindere tradițională vorbim despre încă sute de terabyți și o mulțime de date. Dar, din punctul meu de vedere, vine acest tren de marfă la organizații, iar dr. Robin Bloor a făcut referire la acest lucru mai devreme la IoT. Știi, avem mult trafic web, avem trafic social, acum avem mobilitate și dispozitive mobile, cloud-ul a explodat, un fel de, dar acum avem infrastructură inteligentă, orașe inteligente și există întreaga lume de date care tocmai au explodat.

Pentru o organizație de zi cu zi, o organizație medie până la mare, care stă acolo și vede această lume a durerii venind la ele și nu are un plan imediat în minte, care sunt unele dintre cele care pot fi luate, în doar câteva propoziții, pe care le-ai pune pentru ei, când și unde trebuie să înceapă să se gândească conversațional despre punerea în aplicare a unora dintre aceste metodologii. Cât de devreme trebuie să înceapă planificarea pentru a sta aproape și a da atenție și a spune că acesta este momentul potrivit pentru a pune la dispoziție niște instrumente și pentru a pregăti echipa și pentru a obține o conversație vocabulară în jurul acestei provocări? Cât de târziu în poveste este prea târziu sau când este prea devreme? Cum arată asta pentru unele organizații pe care le vedeți?

Ron Huizenga: Aș spune pentru majoritatea organizațiilor că, dacă nu au făcut-o deja și au adaptat modelarea datelor și arhitectura de date cu instrumente puternice ca aceasta, timpul necesar pentru a face acest lucru este ieri. Deoarece este interesant că, chiar și astăzi, când analizăm datele din organizații, avem atât de multe date în organizațiile noastre și, în general, pe baza unor sondaje pe care le-am văzut, folosim mai puțin de cinci la sută din aceste date în mod eficient când ne uităm peste organizații. Și cu IoT sau chiar NoSQL, date mari - chiar dacă nu este vorba doar de IoT, ci doar de date mari în general - unde acum începem să consumăm și mai multe informații care provin din afara organizațiilor noastre, această provocare devine din ce în ce mai mare tot timpul. Și singurul mod în care avem o șansă de a putea aborda asta este să ne ajute să înțelegem despre ce este vorba.

Deci, cazul de utilizare este puțin diferit. Ceea ce ne considerăm că facem este atunci când ne uităm la aceste date, le capturăm, trebuie să le realizăm înapoi, să vedem ce se află în acestea, indiferent dacă este în lacurile noastre de date sau chiar în bazele noastre de date interne, să sintetizăm ceea ce datele sunt, aplicați-le semnificații și definiții, astfel încât să putem înțelege care sunt datele. Pentru că până nu înțelegem ce este, nu putem asigura că îl folosim corect sau adecvat. Deci trebuie să ne ocupăm cu adevărat de aceste date. Iar cealaltă parte a acestui lucru este să nu o faceți, deoarece puteți, în ceea ce privește consumarea tuturor acestor date externe, să vă asigurați că aveți un caz de utilizare care acceptă consumul acestor date externe. Concentrați-vă asupra lucrurilor de care aveți nevoie mai degrabă decât să încercați să trageți și să utilizați lucruri de care ați putea avea nevoie mai târziu. Concentrează-te mai întâi pe lucrurile importante și pe măsură ce îți treci drumul prin ea, vei ajunge să consumi și să încerci să înțelegi celelalte informații din exterior.

Un exemplu perfect este că știu că vorbim de IoT și de senzori, dar același tip de problemă a fost de fapt în multe organizații de mulți ani, chiar înainte de IoT. Oricine are un sistem de control al producției, fie că este o companie de conducte, producție, orice companii bazate pe procese care au lucruri în care fac multă automatizare cu controale și folosesc fluxuri de date și lucruri de genul acesta, aceste fire de date pe care încearcă să le bea pentru a-și da seama, care sunt evenimentele care au avut loc în echipamentul meu de producție pentru a semnala - ce s-a întâmplat și când? Și printre acest flux uriaș de date există doar anumite informații sau etichete care sunt interesate de faptul că au nevoie pentru a le identifica, sintetiza, modela și înțelege. Și pot ignora restul până când va veni timpul să o înțeleagă cu adevărat și atunci își pot extinde domeniul de aplicare pentru a atrage din ce în ce mai mult obiectul, dacă asta are sens.

Dez Blanchfield: Da, într-adevăr. Există o întrebare pe care o voi pune în discuție, care a venit de la un domn numit Eric și am discutat despre asta în privat. Tocmai am cerut permisiunea lui, pe care i-a dat-o, să o întreb de la tine. Pentru că conduce bine la acest lucru, trebuie doar să ne împachetăm, pentru că acum mergem puțin în timp și îl voi înmâna lui Eric. Dar întrebarea de la un alt Eric a fost: este rezonabil să presupunem că proprietarii unei startup-uri sunt familiarizați cu și înțeleg provocările unice din jurul terminologiei modelării și așa, sau ar trebui să fie înmânată altcuiva pentru interpretare? Deci, cu alte cuvinte, ar trebui ca o startup să fie capabilă și pregătită și dispusă și să poată să se concentreze pe acest lucru? Sau este ceva cu care ar trebui probabil să cumpere și să aducă experți la bord?

Ron Huizenga: Cred că răspunsul scurt este că depinde cu adevărat. Dacă este o pornire care nu are pe cineva care este un arhitect de date sau un modelator care înțelege cu adevărat baza de date, atunci cel mai rapid mod de a începe este să aducem pe cineva cu un fond de consultanță care să fie foarte bine versat în acest spațiu și care să poată obține ei mergând. Pentru că ceea ce veți găsi - și, de fapt, am făcut acest lucru pe o mulțime de angajamente pe care le-am făcut înainte de a ajunge la partea întunecată în gestionarea produselor - este că aș intra în organizații ca consultant, să conduc echipele lor de arhitectură de date, pentru a putea, într-un fel, să se reorienteze și să-și instruiască oamenii cu privire la modul de a face aceste tipuri de lucruri, astfel încât să o susțină și să ducă misiunea mai departe. Și atunci aș continua la următoarea mea logodnă, dacă ar avea sens. Există o mulțime de oameni care fac asta, care au experiență de date foarte bună care le poate duce la bun sfârșit.

Dez Blanchfield: Acesta este un punct minunat de a lua și sunt în totalitate de acord cu acesta și sunt sigur că și dr. Robin Bloor ar fi. În special în cadrul unei startup-uri, sunteți concentrat pe a fi un IMM pe valoarea particulară a propunerii pe care doriți să o construiți ca parte a activității de startup în sine și, probabil, nu trebuie să fiți expert în toate, atât de bune sfaturi. Dar mulțumesc foarte mult, o prezentare fantastică. Răspunsuri și întrebări foarte bune. Eric, o să te înapoiez pentru că știu că am trecut probabil cu zece minute în timp și știu că îți place să rămâi aproape de ferestrele noastre de timp.

Eric Kavanagh: E în regulă. Avem cel puțin câteva întrebări bune. Lasă-mă să arunc unul peste tine. Cred că ați răspuns la unele dintre celelalte. Dar o observație foarte interesantă și o întrebare din partea unui participant care scrie, uneori proiecte agile au modelatorul de date care nu are întreaga imagine pe termen lung și astfel se termină proiectând ceva în sprint unul și apoi trebuie să reproiecteze în sprint trei sau patru. Nu vi se pare contraproductiv? Cum poți evita acest lucru?

Ron Huizenga: Este doar natura agilă că nu veți obține totul absolut corect într-un sprint dat. Și aceasta este de fapt o parte a spiritului agil, este: lucrați cu ea - veți face prototipuri unde lucrați pe cod într-un sprint dat și veți face rafinări. Și o parte a acestui proces este ca tu să livrezi lucruri pe care utilizatorul final îl vede și spune: „Da, este aproape, dar chiar trebuie să-l fac să facă și acest lucru în plus”. Așa că nu numai că are impact asupra designului funcțional. a codului în sine, dar destul de des trebuie să modificăm sau să adăugăm mai multe structuri de date sub aceste anumite lucruri pentru a oferi ceea ce utilizatorul dorește. Și acesta este un joc corect și tocmai de aceea doriți cu adevărat să utilizați instrumentele cu putere mare, deoarece puteți modela foarte repede și puteți efectua această schimbare într-un instrument de modelare și apoi generați DDL pentru baza de date cu care dezvoltatorii pot lucra apoi pentru a livra asta schimbă și mai repede. Îi economisești de la nevoia de a face acea codificare manuală, așa cum era, a structurilor de date și îi lași să se concentreze pe logica de programare sau aplicație la care sunt cei mai pricepuți.

Eric Kavanagh: Asta are sens complet. Am avut câteva alte persoane care pun doar întrebări specifice despre cum se leagă toate acestea de instrument. Știu că ați petrecut ceva timp parcurgând exemple și ați arătat câteva capturi de ecran despre modul în care redați unele dintre aceste lucruri. În ceea ce privește acest întreg proces de sprint, cât de des vedeți că în joc în organizații față de cât de des vedeți mai multe procese tradiționale în care lucrurile doar, fel de bine, complotează și durează mai mult timp? Cât de răspândită este abordarea stilului sprint din perspectiva ta?

Ron Huizenga: Cred că îl vedem din ce în ce mai mult. Știu asta, aș spune, probabil, în ultimii 15 ani, în special, am văzut mult mai mult de o adopție de oameni care recunosc că au nevoie într-adevăr să îmbrățișeze o livrare mai rapidă. Așa că am văzut din ce în ce mai multe organizații sărind pe vagonul de bandă agil. Nu neapărat în întregime; s-ar putea să înceapă cu câteva proiecte pilot pentru a demonstra că funcționează, dar există unele care sunt încă foarte tradiționale și se potrivesc cu metoda cascadei. Acum, bineînțeles, veștile bune sunt, desigur, că instrumentele funcționează foarte bine atât în ​​organizațiile respective, cât și pentru acel tip de metodologii, dar avem adaptabilitatea în instrument, astfel încât cei care sară la bord să aibă instrumentele din cutia de instrumente la vârful degetelor. Lucruri precum compararea și îmbinarea, lucruri precum capabilitățile de inginerie inversă, astfel încât să poată vedea care sunt sursele de date existente, astfel încât să poată compara și genera foarte rapid scripturile DDL. Și pe măsură ce încep să îmbrățișeze asta și văd că pot avea productivitate, înclinația lor de a îmbrățișa agil crește și mai mult.

Eric Kavanagh: Ei bine, acestea sunt lucruri grozave, oameni buni. Tocmai am postat un link către diapozitive de acolo în fereastra de chat, așa că verificați acest lucru; este un pic un pic acolo pentru tine. Avem toate aceste transmisii web pentru vizualizare ulterioară. Nu ezitați să le împărtășiți prietenilor și colegilor. Și Ron, îți mulțumesc foarte mult pentru timpul petrecut astăzi, ești mereu plăcut să ai parte de spectacol - un adevărat expert în domeniu și este evident că îți cunoști lucrurile. Așadar, mulțumim ție și mulțumită IDERA și, desigur, lui Dez și chiar propriului nostru Robin Bloor.

Și cu asta o să vă luăm rămas bun, oameni buni. Mulțumesc din nou pentru timpul acordat și atenție. Apreciem că te-ai lipit de 75 de minute, acesta este un semn destul de bun. Buni băieți de spectacol, o să vorbim cu tine data viitoare. Pa! Pa.