Autorius „Techopedia“ darbuotojai, 2016 m. Lapkričio 16 d
„Takeaway“: Priimančioji Erika Kavanaghas aptaria duomenų modeliavimo svarbą judriam vystymuisi su Robinu Blooru, Dezu Blanchfieldu ir IDERA Ronu Huizenga.
Šiuo metu nesate prisijungęs. Jei norite pamatyti vaizdo įrašą, prisijunkite arba prisiregistruokite.
Ericas Kavanaghas: Gerai, ponios ir ponai. Dar kartą pasveikiname. Tai trečiadienis, 4:00 EST. Tai reiškia, kad atėjo laikas „Hot Technologies“. Taip išties. Mano vardas Ericas Kavanaghas, aš būsiu jūsų šeimininkas.
Šiandienos tema yra sena, bet gera. Kasdien tobulėja, nes formuojamas mūsų duomenų tvarkymo pasaulis „Duomenų modeliavimas judrioje aplinkoje“. Iš tikrųjų jūsų skaidrės apie jus yra „Twitter“ @eric_kavanagh. Mes tikrai turėtume įdėti jį į tą skaidrę. Aš turėsiu tuo užsiimti.
Taigi metai karšti. Duomenų modeliavimas buvo vykdomas amžinai. Informacijos valdymo verslui tikrai buvo prie širdies ir sielos, kuriant duomenų modelius, bandant suprasti verslo modelius ir suderinti juos su jūsų duomenų modeliais. Tai tikrai yra tai, ką bandai padaryti, tiesa?
Duomenų modelis atspindi verslą iš esmės, taigi kaip visi šie nauji duomenų šaltiniai keičia žaidimą? Mes apie tai sužinosime. Mes išsiaiškinsime, kaip galite judriai laikytis dalykų. Ir, žinoma, tai metų žodis.
Robinas Blooras kartu su mumis, mūsų vyriausiasis analitikas, Dez Blanchfield, paskambinęs iš Sidnėjaus, Australijos, ir Ronas Huizenga, vyresnysis produktų vadovas iš IDERA - ilgametis mano draugas, puikus kalbėtojas šioje erdvėje, žino jo medžiagą, todėl nebūk drovus, klausk jam sunkūs klausimai, žmonės, sunkūs. Turėdamas tai, aš padarysiu Robiną vedėju ir nunešiu jį.
Dr Robin Bloor: Gerai. Na, ačiū už tai, Ericai. Turiu pasakyti apie modeliavimą, kad, mano manymu, iš tikrųjų buvau IT pasaulyje, kol jis neegzistavo, ta prasme, kad prisimenu draudimo kompanijoje, kurioje dirbau, kad turėjome vaikiną, kuris atėjo ir mums visiems maloniai padėjo. seminaro, kaip modeliuoti duomenis. Taigi mes žiūrime apie 30 metų, ar tai 30 metų? Gal net ilgiau nei gal prieš 35 metus. Ilgas ir ilgas modeliavimas iš tikrųjų buvo pramonės dalis, ir, žinoma, jis neturėjo nieko bendra su moterimis ant takų.
Dalykas, kurį norėjau pasakyti, nes tai, ką mes paprastai darome, yra aš ir Dezas, kalbantys apie skirtingus dalykus, ir aš tiesiog galvojau, kad pateiksiu bendrą modeliavimo apžvalgą, tačiau tam yra realybė, kuri dabar paaiškėja.
Turime, žinote, didelių duomenų realybę, turime daugiau duomenų, daugiau duomenų šaltinių, turime duomenų srautus, kurie įvedė lygtį per pastaruosius trejus ar ketverius metus ir pradeda gauti didesnę jo dalį, ir Didesnis poreikis suprasti duomenis ir padidėjęs pokyčių greitis, nes pridedama daugiau duomenų ir naudojama daugiau duomenų struktūrų.
Tai sunkus pasaulis. Tai paveikslėlis, kuris iš tikrųjų yra kažkas, apie ką mes atkreipėme maždaug prieš trejus metus, tačiau iš esmės, kai jūs įtraukiate srautinį srautą į rinkinį ir jums kyla tokia duomenų rafinavimo, duomenų centrų, duomenų nuorodų ar ko nors kita idėja, matote, kad yra duomenų, nuoširdžiai ramiai, ta prasme, kad beveik nejuda. Ir tada yra duomenys, srautai ir visa operacijų programa, be to, šiais laikais jūs turite įvykius, įvykių duomenų srautus, kurie vyksta programose ir kurie gali tekti, o šiais laikais su „lambda“ architektūra, apie kurią visi kalba, yra tikrai. turintys įtakos tik visam duomenų laukui.
Ir šiais laikais galvokime apie duomenų lygmens egzistavimą. Duomenų sluoksnis egzistuoja tam tikru pavidalu virtualiai, ta prasme, kad nemažas jo gabalas gali būti debesyje ir gali būti paskirstytas duomenų centruose, jis gali egzistuoti darbo vietose. Duomenų sluoksnis tam tikru mastu yra visur ir ta prasme visur yra procesai, kurie vienaip ar kitaip bando apdoroti duomenis ir perkelia duomenis apie juos. Bet taip pat žinoti, kas tai yra, kai juda, apie tai reikia.
Jei pažvelgsime į duomenų modeliavimą bendrąja prasme, tai tokio tipo krūvos apačioje yra failai ir duomenų bazės. Jūs turite duomenų elementus, kuriuose yra raktai, elementų apibrėžimai, slapyvardžiai, sinonimai, konkretūs fiziniai formatai ir tada mes turime šį metaduomenų sluoksnį.
Įdomus metaduomenų dalykas yra tas, kad metaduomenys yra būtent tai, kaip duomenys įgauna prasmę. Jei iš tikrųjų neturite metaduomenų, geriausiu atveju galite atspėti duomenų prasmę, tačiau jūs patirsite nepaprastai daug sunkumų. Metaduomenys turi būti ten, bet prasmė turi struktūrą. Nenoriu gilintis į prasmės filosofiją, tačiau net ir tvarkant duomenis, žmogaus mintys ir kalba yra labai rafinuoti, o tai nėra lengva išreikšti savo duomenimis. Bet net ir kalbant apie duomenis, kuriuos iš tikrųjų apdorojame pasaulyje, metaduomenys turi prasmę ir metaduomenų struktūrą - vienas duomenų gabalas kito atžvilgiu ir ką tai reiškia, kai jie yra sudėti, ir ką tai reiškia, kai jie ' vėl sujungtas su kitais duomenimis, reikalauja, kad mes jį modeliuotume. Neužtenka tiesiog įrašyti daiktų metaduomenų žymas, jūs iš tikrųjų turite įrašyti kiekvienos struktūros reikšmę ir struktūrų santykį.
Tada mes turime viršutinį sluoksnį, verslo apibrėžimus, kurie paprastai yra sluoksniai, kuriais bandoma perkelti reikšmes tarp metaduomenų, tai yra duomenų apibrėžimo forma, tinkanti duomenų tvarkymo kompiuteryje ir žmogaus prasmei. Taigi jūs turite verslo terminus, apibrėžimus, ryšius, subjekto lygio sąvokas, egzistuojančias tame sluoksnyje. Ir jei mes turėsime nenuoseklumą tarp šių sluoksnių, turėsime modeliuoti duomenis. Tai tikrai nėra pasirenkama. Kuo daugiau iš tikrųjų galite tai padaryti automatizuodami, tuo geriau. Bet kadangi tai yra susiję su prasme, tai išties sunku pakeisti. Pakanka lengvai surinkti metaduomenis įraše ir gauti juos iš reikšmių serijos, tačiau jis nenurodo jums įrašų struktūros ar to, ką reiškia įrašai ar įrašo kontekstas.
Taigi, mano manymu, apie tai yra duomenų modeliavimas. Reikia atkreipti dėmesį: kuo sudėtingesnė duomenų visata, tuo daugiau reikia ją modeliuoti. Kitaip tariant, tai šiek tiek panašu, kad mes pridedame ne tik daugiau daiktų pavyzdžių pasauliui, kuris atitiktų duomenų įrašus, bet faktiškai pridedame pasauliui daugiau prasmės fiksuodami duomenis apie vis daugiau ir daugiau dalykų. Tai tampa vis sudėtingesnis pojūtis, kurį turime suprasti.
Teoriškai yra duomenų visuma ir mums reikia jos vaizdinio. Praktiškai tikrieji metaduomenys yra duomenų visumos dalis. Taigi, tai nėra paprasta situacija. Pradedamas modeliavimas iš viršaus į apačią ir iš apačios į viršų. Turite kurti abiem kryptimis, ir priežastis yra ta, kad duomenys turi reikšmę kompiuteriui ir procesui, kurie turi juos apdoroti, tačiau jie turi prasmę savaime. Taigi, jums reikia „iš apačios į viršų“ reikšmės, tenkinančios programinę įrangą, kuriai reikia prieigos prie duomenų, ir jums reikia „iš viršaus į apačią“ prasmės, kad žmonės galėtų ją suprasti. Metaduomenų modelių kūrimas nėra ir niekada negali būti projektas; tai tęstinė veikla - turėtų būti tęstinė veikla kiekvienoje aplinkoje, kurioje jie egzistuoja. Laimei, yra daugybė aplinkų, kuriose iš tikrųjų taip nėra ir viskas atitinkamai nekontroliuojama.
Einant į priekį, modelių svarba didėja, kai technologijos juda į priekį. Tokia mano nuomonė. Bet jei pažvelgsite į daiktinę internetą, mes galime suprasti mobilųjį telefoną labiau nei įpratę, nors jame atsirado naujos dimensijos: vietos su mobiliuoju aspektas. Kai pateksite į internetinę internetą, mes pažvelgsime į nepaprastas duomenų problemas, kurių niekada anksčiau neturėjome daryti, ir mes turime vienaip ar kitaip tinkamai suprasti, ką turime, būtent tai, kaip galime ją apibendrinti, ką mes galime padaryti, kad gautume prasmę iš apibendrinimo, ir, žinoma, ką mes galime su tuo padaryti, kai mes jį apdorosime.
Manau, kad aš pakankamai pasakiau. Aš perduosiu Dezui Blanchfieldui, kuris pasakys visai ką kita.
Dez Blanchfield: Ačiū. Visada sunkus poelgis, kurio reikia laikytis, tačiau tai yra tema, dėl kurios sutarėme ir trumpai apie tai kalbėjomės parodomoje parodoje. Jei pasirinktas anksti, turbūt pagaunate visą krūvą puikių brangakmenių. Vienas iš perėmimų ir nenoriu pavogti šio konkretaus griaustinio, tačiau vienas iš perpardavimų iš mūsų parodomosios banerio, kuriuo noriu pasidalinti, jei nepataikėte, buvo visai šalia šios temos: duomenų kelionė, ir tai mane sukrėtė, kad iš tikrųjų tai užrašiau, galvodama apie kelionę, kurią duomenys trunka skirtingame kontekste per visą kartų gyvenimą - metai, mėnesiai, savaitė, diena, valanda, minutė, sekundė, o aplink juos esantys duomenys yra išdėstytos tame kontekste. Nesvarbu, ar aš kūrėjas, naudodamas kodą, ar esu duomenų specialistas, ir galvoju apie kiekvieno elemento struktūrą ir formatą bei metaduomenis arba apie tai, kaip sistemos ir verslas sąveikauja su juo.
Tai įdomus nedidelis takelis, kurį reikia tik pastebėti, tačiau bet kokiu atveju leiskite man pasinerti. Visų pirma, duomenų dizainas yra frazė, kurią aš naudoju kalbėdamas apie visų dalykų duomenis ir konkrečiai kurdamas programas arba duomenų bazių infrastruktūrą. Aš manau, kad duomenų dizainas yra terminas, kuris visa tai labai gerai atspindi mano galvoje. Šiomis dienomis, kai mes kalbame apie duomenų dizainą, mes kalbame apie šiuolaikinį judrų duomenų dizainą, ir aš laikausi nuomonės, kad ne taip seniai kūrėjai ir duomenų ekspertai dirbo vieni; jie buvo savo silosuose, o dizaino gabalai perėjo iš vieno siloso į kitą. Tačiau aš labai laikausi šių dienų nuomonės, kad pasikeitė ne tik atvejis, bet ir pasikeitė; tai tarsi būtinybė ir tai yra ta programa - kūrėjai ir bet kas, kas susiję su plėtra, susijusi su duomenimis, dizaineriai, atliekantys atitinkamus schemų ir laukų bei įrašų projektavimo elementus, vietos ir duomenų bazių sistemas ir infrastruktūras, modeliavimą ir visą valdymą iššūkis aplink. Dabar tai yra komandinis sportas, taigi mano nuotrauka iš krūvos žmonių, iššokusių iš lėktuvo, veikia kaip komanda, kad galėtų parodyti tą vizualiai įdomų žmonių, krentančių per dangų, vaizdą.
Trečia, kas nutiko, kad tai atsirado? Štai 1986 m. Straipsnis, parašytas poros ponų, kurių vardais aš desperatiškai bandžiau teisintis, Hirotaka Takeuchi ir Ikujiro Nonaka, manau, kad jis ištariamas, parengė straipsnį, pavadintą „Sraigto judėjimas žemyn“. Jie pristatė straipsnį. ši regbio žaidimo, vykstančio iš šios slinkimo veiklos, laimėjimo metodikos idėja, kai visi susiburia vienoje vietoje ir dvi komandos iš esmės užstoja galvas vadinamame gurkšnyje, kad pabandytų suvaldyti kamuolį ir žaisti jį lauke. eikite į bandymo liniją ir palieskite žemę su kamuoliu ir gaukite tašką, vadinamą trine, ir jūs pakartosite šį procesą ir gausite daugiau taškų komandai.
Šis straipsnis buvo išspausdintas 1986 m. „Harvard Business Review“ ir, kaip įdomu, iš tikrųjų sulaukė daug dėmesio. Tai sulaukė daug dėmesio, nes pristatė nuostabias naujas sąvokas ir čia yra jo ekrano kopija. Taigi jie išėmė šią žaidimo regbio sąvoką ir pritaikė ją versle, ypač projektavimo ir projekto pristatymo, ypač projekto pristatymo, žaidime.
Tai, ką mestelėjome, suteikė mums naują metodiką, palyginti su panašiomis į PRINCE2 ar PMBOK, kurias anksčiau naudojome vadindami krioklio metodiką, žinote, darykite šį ir šį bei šį dalyką ir sekite juos iš eilės ir sujungkite visi taškai aplink, tai priklauso nuo to, ką turėjote, arba nedarykite antros dalies, kol nepadarysite pirmosios dalies, nes ji priklausė nuo pirmosios dalies. Tai, ką davė, yra nauja, šiek tiek judresnė metodika, iš kur kilęs terminas, apie tai, kaip mes pristatome daiktus, ypač apie projektavimo ir vystymo pagrindinius projektus.
Kai kurie pagrindiniai nuomininkai - tiesiog taip aš su tuo susipažinsiu - yra aplink svarbiausius namų savininkus. Jame buvo pristatyta nestabilumo idėja, kad, jei galvojate apie chaoso baimę, pasaulis egzistuoja chaoso būsenoje, tačiau susiformavo planeta, kuri yra įdomi, todėl pastato nestabilumas, galimybė truputį šoktelėti aplink ir vis tiek priverčia dalykus veikti, savarankiškai organizuodami projekto komandas, persidengdami palankumo dėka labai atsakingai kurdami įvairius mokymosi ir kontrolės būdus projekto vykdymo metu, organizuodami mokymosi perkėlimą. Taigi, kaip mes galime paimti informaciją iš vienos verslo dalies ir perduoti ją kitai iš žmonių, kurie turi idėją, bet nesukuria kodo ar ne kuria duomenų bazes ir infrastruktūras, o duomenis tiems žmonėms? Konkrečiai kalbant apie rezultatus. Kitaip tariant, padarykime tai tam tikrą laiką, per dieną, pavyzdžiui, per 24 valandas, arba savaitę ar porą savaičių, ir pažiūrėkime, ką galime padaryti, tada atsitraukime ir pažiūrėkime.
Taigi, jei jūs atleisite bausmę, tai iš tikrųjų yra naujas žaidimas projekto pristatyme ir trys pagrindiniai jo komponentai, kurie bus prasmingi, kai mes šiek tiek toliau eisime čia. Štai produktas: visi šie žmonės turi idėją ir turi poreikis ką nors padaryti ir istorija, kuri juos supa. Kūrėjai, kurie naudojasi judriu savo istorijų gavimo modeliu ir kasdieniais stengiais, naudodamiesi „scrum“ metodika, aptaria ją ir supranta, ką jiems reikia padaryti, o tada tiesiog eik ir imk toliau ir daryk. Tada žmonės, mes girdėjome apie valymo meistrus, kurie prižiūri visą šį reikalą ir pakankamai gerai supranta metodiką, kad galėtų tai valdyti. Mes visi matėme šiuos vaizdus, kuriuos gavau dešinėje pusėje, prie sienų ir lentų, pilnų „Post-It“ užrašų, ir jie buvo naudojami kaip „Kanban“ sienos. Jei nežinote, kas yra „Kanban“, kviečiu jus į „Google“, kas buvo ponas Kanbanas ir kodėl tai pasikeitė tuo, kaip mes perkeliame reikalus iš vienos pusės į kitą sienoje tiesiogine prasme, bet projekte.
Iš pirmo žvilgsnio „scrum“ eiga daro šį procesą: paima sąrašą dalykų, kuriuos organizacija nori padaryti, paleidžia juos per keletą dalykų, kuriuos vadiname sprintais ir kurie yra suskaidyti į 24 valandų periodus, mėnesio laikotarpius, o mes gauti šią prieauginę išvesties seriją. Tai reikšmingas projekto pristatymo būdo pakeitimas, kuris buvo pristatytas iki pat to etapo, nes dalis to srauto eina kaip JAV armija, kuriai labai teko kurti tai, kas vadinama PMBOK, pavyzdžiui, idėja, kad neveskite tanko į lauką kol įmesite kulkas į daiktą, nes jei lauke bakas neturi kulkų, tai nenaudinga. Taigi pirmoji dalis yra dedama į kulką, o antra dalis - į lauką. Deja, vis dėlto tai, kas nutiko kūrėjams vystymosi pasaulyje, kažkaip įsitvirtino šioje judrioje metodikoje ir, pasinaudoję bausme, išsisukinėjo sprintoje.
Visada tai, kas atsitiko, galvodami apie judrumą, dažniausiai galvojame apie kūrėjus, o ne apie duomenų bazes ir bet kokį ryšį su duomenų bazių pasauliu. Tai buvo apgailėtinas rezultatas, nes tikrovė yra tokia, kad judrus yra ne tik kūrėjai. Tiesą sakant, terminas „judrus“, mano nuomone, dažnai neteisingai siejamas tik su programinės įrangos kūrėjais, o ne su duomenų bazių kūrėjais ir architektais. Visada tie patys iššūkiai, su kuriais susiduriate kurdami programinę įrangą ir taikomąsias programas, susiduria su projektavimu ir plėtra bei valdymu ir priežiūra, taigi ir su duomenų infrastruktūra, ypač duomenų bazėmis. Dalyvaujantys šiame duomenų rinkime yra tokie, kaip duomenų architektai, formuotojai, duomenų bazių infrastruktūrų administratoriai, valdytojai ir pačios duomenų bazės, verslo ir sistemų analitikai bei architektai, žmonės, sėdintys ir galvojantys apie tai, kaip sistemos ir verslas veikia ir kaip mes turime juos perduoti.
Tai tema, kurią aš nuolat keliu, nes tai yra nuolatinis mano nusivylimas, nes aš labai laikausi nuomonės, kad duomenų specialistai privalo, o ne turėtų, dabar būti glaudžiai įtraukti į kiekvieną projekto teikimo komponentą, o ypač plėtrą. Jei ne, tada mes tikrai nesuteikiame sau geriausių galimybių pasiekti gerų rezultatų. Dažnai turime pasisukti atgal ir dar kartą pagalvoti apie šiuos dalykus, nes egzistuoja scenarijus, mes pereiname prie kuriamos programos ir atrandame, kad kūrėjai ne visada yra duomenų ekspertai. Darbui su duomenų bazėmis reikia labai specializuotų įgūdžių, ypač susijusių su duomenimis, ir kaupiama patirtis. Jūs ne tik akimirksniu netapsite duomenų bazės guru ar duomenų žinių ekspertu; tai dažnai kyla iš gyvenimo patirties ir, be abejo, su dr. Robinu Blooriu „The Code Today“, kuris gana turtingai parašė knygą.
Daugeliu atvejų, ir tai gaila, bet tai yra tikrovė, kad yra dvi šios monetos dalys, ty programinės įrangos kūrėjai turi savo užmokesčio už duomenų bazių specialistą ir sukaupė įgūdžius, kurių jums reikia modeliuojant duomenų bazę, o modelio kūrimas yra tik pagrindiniai guru inžinerijos aspektai, kaip gaunami duomenys ir kaip reikia organizuoti kelionę, kaip turėtų atrodyti ar neturėtų atrodyti, arba, be abejo, tai, kad praryjama ir suprantama, kad tai paprastai yra įgyta įgijus programinės įrangos kūrėjų įgūdžius. Kai kurie iš bendrų iššūkių, kuriuos turime patirti, apima tik pagrindinio duomenų bazės kūrimo, priežiūros ir tvarkymo pagrindus, duomenų ir duomenų bazės infrastruktūros dokumentavimą ir pakartotinį tų duomenų išteklių, schemų dizainų panaudojimą, schemų generavimas, schemų administravimas ir priežiūra bei jų naudojimas, dalijimasis žiniomis apie tai, kodėl ši schema yra sukurta tam tikru būdu, ir stipriosios bei silpnosios pusės, susijusios su tuo, laikui bėgant, keičiasi duomenys laikui bėgant, duomenų modeliavimas ir tipai modelių, kuriuos taikome sistemoms, ir duomenis, kuriuos mes tekame jomis. Duomenų bazės kodų generavimas ir tada vyksta integracija, tada modeliuojami duomenys aplink juos ir tada greičiau prieinama prie duomenų saugumo kontrolės, duomenų vientisumas yra tai, kad mes judame duomenis aplink, nes mes išsaugome jų vientisumą, ar yra pakankamai metaduomenų ar pardavėjai turėtų matyti visus lentelės įrašus ar jie turėtų matyti tik adresą, vardą, pavardę, kuris jums siunčia žinutes? Ir tada, be abejo, didžiausias iššūkis yra modeliuoti duomenų bazių platformas, o tai jau yra skirtingas pokalbis savaime.
Aš labai laikausi nuomonės, kad atsižvelgiant į visa tai, kad būtų įmanoma bet kuri iš šių nirvanų, yra be galo svarbu, kad tiek duomenų specialistai, tiek kūrėjai turėtų tinkamus įrankius ir kad tuos įrankius būtų galima nukreipti į komandą orientuotą projektą, projektavimas, plėtra ir nuolatinė eksploatacinė priežiūra. Žinote, tokie dalykai kaip duomenų ekspertų ir programinės įrangos kūrėjų bendradarbiavimas projektuose, vienas tiesos taškas ar vienas tiesos šaltinis visiems dalykams, susijusiems su pačių duomenų bazių dokumentais, duomenimis, schemomis, iš kur kilę įrašai, tų įrašų savininkais . Manau, kad šiais laikais tai yra be galo svarbu, kad ši duomenų nirvana taps karališka, kad reikia turėti tinkamus įrankius, nes iššūkis yra per didelis, kad galėtume tai padaryti rankiniu būdu ir jei žmonės Jei perkelsite veiklą iš vienos organizacijos į kitą ir iš jos, mums nesunku vadovautis tuo pačiu procesu ar metodika, kurią gali sukurti vienas asmuo, ir tai yra gerai, ir nebūtinai perduokime tuos įgūdžius ir galimybes ateityje.
Turėdamas tai omenyje, eisiu pas mūsų gerą draugą IDERA ir išgirsiu apie tą įrankį ir kaip jis sprendžia tuos pačius dalykus.
Ronas Huizenga: Labai ačiū ir ačiū tiek Robinui, tiek Dezui už tai, kad išties gerai pasirodėte scenoje, ir pamatysite, kad keli dalykai, apie kuriuos kalbėjau, šiek tiek sutaptų. Bet jie tikrai sukūrė labai tvirtą pagrindą kai kurioms sąvokoms, apie kurias kalbėsiu duomenų modeliavimo požiūriu. Daugybė jų pasakytų žodžių atkartoja mano patirtį, kai buvau konsultantas, dirbantis duomenų modeliavimo ir duomenų architektūros srityse, kartu su komandomis - tiek kriokliu pirmosiomis dienomis, tiek ištobulėjus į modernesnius produktus su projektais, kuriuose mes naudojome judrumą. metodikos sprendimų pateikimui.
Taigi apie tai, apie ką šiandien kalbėsiu, yra remiamasi tiek patirtimi, tiek įrankių, kuriuos mes naudojame, kad padėtume mums toje kelionėje, įvaizdžiu. Aš labai trumpai aptarsiu, kad nesigilinsiu į smulkmenas; mes tiesiog turėjome tikrai gerą apžvalgą, kas tai yra. Aš kalbėsiu apie tai, kas yra duomenų modelis ir ką jis iš tikrųjų reiškia mums? Ir kaip mes įgaliname judraus duomenų modeliuotojo sąvoką savo organizacijose, kalbant apie tai, kaip mes įtraukiame duomenų modeliuotojus, koks yra modeliuotojų ir architektų dalyvavimas sprinto metu, kokios veiklos rūšys turėtų būti vykdomos? ir kaip tam tikras svarbias modeliavimo įrankio galimybes, kurias mes naudojame, kad iš tikrųjų padėtume palengvinti šį darbą? Tuomet aš šiek tiek papusryčiausiu ir šiek tiek papasakosiu apie kai kurias verslo vertybes ir pranašumus, susijusius su duomenų modeliuotoju, arba tuo, kaip aš iš tikrųjų papasakosiu istoriją, problemos, kai duomenų modeliuotojas nėra visiškai įsitraukęs į projektus, ir aš jums tai parodysiu, remdamasis patirtimi ir faktinio projekto, kuriame dalyvavau prieš daugelį metų, prieš ir po paveikslėlio trūkumų diagrama. Tada mes apibendrinsime dar keletą punktų ir turėsime klausimų bei atsakymų.
Trumpai tariant, „ER Studio“ yra labai galingas rinkinys, turintis daugybę skirtingų komponentų. „Data Architect“, kur duomenų modeliuotojai ir architektai didžiąją laiko dalį praleidžia modeliuodami duomenis. Taip pat yra ir kitų komponentų, apie kuriuos šiandien visiškai nekalbėsime, pvz., „Business Architect“, kuriame atliekame procesų modeliavimą, ir „Software Architect“, skirtą kai kuriems UML modeliavimui. Tada yra saugykla, kurioje mes patikriname ir dalijamės modeliais, o komandoms leidžiame bendradarbiauti ir paskelbti juos komandos serveryje, kad kelios projekto dalyvių auditorijos iš tikrųjų matytų artefaktus, kuriuos mes ' kurti iš duomenų perspektyvos, taip pat kitus dalykus, kuriuos darome pristatydami patį projektą.
Tai, apie ką šiandien daug dėmesio skirsiu, bus keli dalykai, kuriuos pamatysime iš „Data Architect“, ir todėl, kad tikrai svarbu, jog bendradarbiaujame su saugyklomis pagrįstais aspektais. Ypač tada, kai pradedame kalbėti apie tokias sąvokas kaip pokyčių valdymas, kurios yra būtinos ne tik judriems plėtros projektams, bet ir bet kokio pobūdžio plėtrai.
Taigi trumpam pakalbėkime apie „Agile Data Modeler“. Kaip jau buvo sakoma anksčiau, pranešime buvo minėta, kad būtina, jog turėtume duomenų modeliuotojus ir (arba) architektus, kurie visapusiškai dalyvautų judriuose kūrimo procesuose. Taigi tai, kas nutiko istoriškai, taip, mes iš tikrųjų galvojome apie judrumą vystymosi požiūriu, ir yra keletas dalykų, kurie įvyko, dėl kurių tikrai atsirado. Iš dalies tai įvyko tik dėl to, kaip vyko pats vystymasis. Kai prasidėjo judrus vystymasis ir mes pradėjome nuo šios savarankiškai organizuojančių komandų idėjos, jei gėrėte „Kool-Aid“ šiek tiek per daug grynai ir buvote ekstremalių dalykų programavimo pusėje, ten buvo labai pažodžiui aiškinami tokie dalykai kaip „ savarankiškai organizuojančioms komandoms, kurias daug kas suprato turėdami omenyje, viskas, ko mums reikia, yra kūrėjų grupė, galinti sukurti visą sprendimą. Nesvarbu, ar tai yra kodo, duomenų bazių ar duomenų bazių kūrimas, ir viskas buvo perduota kūrėjams. Bet kas atsitiks su tuo, kad prarasite ypatingus sugebėjimus, kuriuos turi žmonės. Aš išsiaiškinau, kad stipriausios yra tos komandos, kurias sudaro skirtingų sluoksnių žmonės. Tokie kaip stiprių programinės įrangos kūrėjų, duomenų architektų, duomenų modeliuotojų, verslo analitikų ir verslo suinteresuotųjų subjektų derinys, visi kartu bendradarbiaujantys ieškodami galutinio sprendimo.
Aš taip pat šiandien kalbu apie tai, kad tai padarysiu įgyvendindamas plėtros projektą, kuriame mes kuriame programą, kuri, be abejo, taip pat turės su tuo susijusius duomenų komponentus. Prieš tai darydami, turime žengti žingsnį atgal, nes turime suvokti, kad ten yra labai mažai „Greenfield“ plėtros projektų, kuriuose mes visą dėmesį skiriame duomenų, kurie yra riboti tik pačiame plėtros projekte, kūrimui ir naudojimui. . Turime žengti žingsnį atgal ir pažvelgti į bendrą organizacijos požiūrį duomenų ir proceso perspektyva. Nes mes sužinome, kad informacija, kurią mes naudojame, jau egzistuoja kažkur organizacijose. Kaip modeliuotojai ir architektai tai išryškiname, kad žinotume, iš kur galime semtis informacijos iš pačių projektų. Mes taip pat žinome susijusias duomenų struktūras, nes turime dizaino modelius, kaip ir kūrėjai turi savo kodo projektavimo modelius. Mes taip pat turime atsižvelgti į šią bendrą organizacijos perspektyvą. Negalime vien tik žiūrėti į duomenis kurdami programą. Turime modeliuoti duomenis ir įsitikinti, kad juos dokumentuojame, nes jie gyvena daug ilgiau nei pačios programos. Tos programos ateina ir išeina, tačiau mes turime mokėti žiūrėti į duomenis ir įsitikinti, kad jie yra patikimi ir gerai susisteminti ne tik taikydami programas, bet ir priimdami sprendimus, kurie praneša apie veiklą, BI ataskaitų teikimą ir integraciją į kitas programas, vidines ir nepriklauso ir nuo mūsų organizacijų. Taigi turime pažvelgti į visą didelį duomenų vaizdą ir į tai, koks yra šių duomenų gyvenimo ciklas, ir suprasti informacijos gabalus visoje organizacijoje nuo lopšio iki kapo.
Grįžtant prie pačių komandų ir to, kaip turime iš tikrųjų dirbti, krioklio metodika buvo suvokta kaip per lėta rezultatams pasiekti. Nes, kaip pažymėta tanko pavyzdyje, tai buvo vienas žingsnis po kito ir dažnai reikėjo per daug laiko, kad būtų pateiktas tinkamas galutinis rezultatas. Tai, ką mes darome dabar, turime turėti iteracinį darbo stilių, kuriame palaipsniui tobuliname jo komponentus ir tobuliname laiką, kur gaminame tinkamus kodus ar tinkamus artefaktus, sakysiu, kiekvienam sprintui. Svarbus dalykas yra komandos techninių ir verslo suinteresuotųjų šalių bendradarbiavimas, nes mes bendradarbiaujame, kad šias vartotojų istorijas panaudotume įgyvendinamai kodo vizijai ir duomenims, palaikantiems tą patį kodą. O pats „Agile Data Modeler“ dažnai pastebės, kad mes neturime pakankamai modeliuotojų organizacijose, todėl vienas duomenų modeliuotojas ar architektas gali vienu metu palaikyti kelias komandas.
Kitas aspektas yra tas, kad net jei turime kelis modeliuotojus, turime įsitikinti, kad turime įrankių rinkinį, kurį naudojame, kad būtų galima bendradarbiauti su tuo pačiu metu vykstančiais projektais ir dalintis tais projektais. duomenų artefaktus ir registracijos bei išsiregistravimo galimybes. Aš tai perduosiu labai greitai, nes mes jau aptarėme tai ankstesniame skyriuje. Tikroji judrumo prielaida yra tai, kad jūs grindžiate dalykus nuo užsiminimų, istorijų ar reikalavimų. Pakartojimuose mes bendradarbiaujame kaip grupė. Paprastai dviejų savaičių arba vieno mėnesio sprintas, atsižvelgiant į organizaciją, yra labai dažnas. Taip pat kasdien apžvelgiame ir stengiamės susitikti, kad pašalintume blokatorius ir įsitikintume, kad judame visais aspektais į priekį, nesustodami įvairiose srityse, kai einame. Tuose sprintuose norime įsitikinti, kad kiekvieno sprinto metu gaminsime tinkamus naudoti produktus.
Tik šiek tiek kitaip, išplėsdami ją, „scrum“ yra metodika, apie kurią čia kalbėsiu konkrečiau, ir mes iš esmės tik papildėme tą ankstesnį paveikslą keliais kitais aspektais. Paprastai yra produktų atsilikimas, tada - sprintų atsilikimas. Taigi turime bendrą atsilikimą, kuris kiekvieno sprinto pakartojimo pradžioje leidžiasi pasakyti: „Ką mes sukursime šį sprintą?“, Ir tai padaryta sprinto planavimo susitikime. Tuomet išskaidome su tuo susijusias užduotis ir vykdome tuos vienos ar keturių savaičių sprintus su tomis dienos apžvalgomis. Kai darome, mes stebime savo pažangą naudodami perdegimo diagramas ir perdegimo diagramas, kad iš esmės stebėtume, ką liko sukurti, palyginti su tuo, ką statome, kad nustatytume tokius dalykus, koks yra mūsų plėtros greitis, ar ketinsime tvarkaraštį, visus tuos dalykus. Visi šie dalykai yra tobulinami nuolat, o ne kelis mėnesius einant keliu ir sužinojus, kad netrukus pasirodys, ir reikia pratęsti projekto tvarkaraštį. Ir labai svarbu, kad kaip visos komandos dalis yra sprinto peržiūra pabaigoje ir sprinto retrospektyva, todėl prieš pradėdami kitą iteraciją apžvelkite, ką padarėte, ir ieškote būdų, kaip galėtumėte pagerinti kitą kartą per.
Tiekiant iš esmės tai yra skaidrė, kurioje apibendrinami tipiniai daiktai, kurie vyksta sprintuose. Ir tai yra labai orientuota į plėtrą, todėl daug dalykų, kuriuos mes matome čia, pavyzdžiui, funkciniai dizainai ir naudojimo atvejai, atliekant projektavimo kodo testus, kai mes žiūrime į šias dėžutes čia, ir aš nesiruošiu jų peržvelgti. bet kuriame detalumo lygyje, jie labai orientuoti į vystymąsi. Čia palaidotas faktas, kad mes taip pat turime turėti tuos duomenų šaltinius, kurie kartu su tuo remia šias pastangas. Taigi kiekvieną kartą, kai matome tokius dalykus kaip atsilikimai, reikalavimai ir vartotojų istorijos, mes, eidami kelią, turime išnagrinėti, kokius kūrimo elementus turime atlikti, kokie yra analizės elementai, kuriuos turime atlikti, o kaip apie duomenų dizainas ar duomenų modelis, o kaip su verslo žodynėliais, kad galėtume verslo prasmę susieti su visais mūsų gaminiais? Nes mes turime gaminti tuos tinkamus naudoti produktus kiekviename sprinte.
Kai kurie žmonės sakys, kad kiekvieno sprinto pabaigoje turime sukurti naudotiną kodą. Nebūtinai, tai yra gryniausia vystymosi perspektyva, tačiau gana dažnai - ypač pradžioje - mes galime turėti kažką panašaus į nulinį sprinto periodą, kuriame mes orientuojamės tik į stovinčius dalykus, tokius dalykus, kaip bandymo strategijų kūrimas. vieta. Aukšto lygio dizainas, norint jį pradėti, prieš pradedant pildyti išsamią informaciją ir prieš pradedant domėtis kitomis auditorijomis ir įsitikinti, ar turime aiškų pradinių istorijų ar reikalavimų rinkinį, o tada einame į priekį kaip komanda. Visada yra šiek tiek pasiruošimo laiko, todėl gana dažnai turėsime nulinį sprinto ar net vieną. Gali būti šiek tiek pradinis etapas, kol mes pasiekėme pilną skrydį pristatydami sprendimą.
Trumpai pakalbėkime apie duomenų modelius. Kai žmonės galvoja apie duomenų modelius, jie dažnai galvoja apie duomenų modelį kaip apie įvairaus pobūdžio informacijos susiejimo vaizdą - tai tik ledkalnio viršūnė. Jei norite visiškai įkūnyti, kaip jūs iš tikrųjų norite kreiptis į duomenų modeliavimą, nesvarbu, ar tai yra judrus vystymasis, ar kitus dalykus, turite suvokti, kad duomenų modelis, jei jis padarytas teisingai, tampa jūsų išsamia specifikacija, ką šie duomenys reiškia organizacijoje ir kaip jis yra įdiegtas galinėse duomenų bazėse. Kai sakau duomenų bazes, turiu omenyje ne tik reliacines duomenų bazes, kuriomis mes galbūt naudojamės, bet ir šių dienų architektūrose, kur turime didelius duomenis ar NoSQL platformas, kaip aš mieliau jas vadinu. Taip pat tas dideles duomenų saugyklas, nes mes galime sujungti daugybę skirtingų duomenų saugyklų, kalbėdami apie informacijos suvartojimą ir įtraukimą į savo sprendimus, taip pat apie tai, kaip mes tą informaciją išsaugome ar išsaugome iš savo sprendimų.
Gali būti, kad tam tikros programos kontekste vienu metu dirbame su keliomis duomenų bazėmis ar duomenų šaltiniais. Labai svarbu yra tai, kad norime turėti išsamią specifikaciją, taigi loginę specifikaciją, ką tai reiškia sprintinei organizacinei perspektyvai, kokios yra fizinės konstrukcijos, kalbant apie tai, kaip mes iš tikrųjų apibrėžiame duomenis, kokie yra ryšiai tarp jų. savo duomenų bazes, referencinius vientisumo apribojimus, patikrinkite apribojimus, visus tuos patvirtinimo elementus, apie kuriuos paprastai galvojate. Aprašomieji metaduomenys yra nepaprastai svarbūs. Kaip jūs žinote, kaip panaudoti duomenis savo programose? Nebent jūs galite jį apibrėžti ir žinoti, ką tai reiškia, arba žinoti, iš kur jie atsirado, kad įsitikintumėte, jog naudojate teisingus duomenis tose programose - įsitikinkite, kad turime teisingas vardų sudarymo konvencijas, visas apibrėžtis, o tai reiškia ne tik duomenų duomenų žodyną, bet ir ne tik lenteles, bet stulpelius, kuriuos sudaro tos lentelės, - ir išsamias diegimo pastabas apie tai, kaip mes tai naudojame, nes turime sukurti šią žinių bazę, nes net tada, kai ši programa bus padaryta, ši informacija bus naudojama kitoms iniciatyvoms, todėl turime įsitikinti kad visa tai turime dokumentuose, kad galėtume juos įgyvendinti ateityje.
Vėlgi, mes svarstome tokius dalykus kaip duomenų tipai, raktai, rodyklės, pats duomenų modelis įkūnija daugybę verslo taisyklių, kurios yra svarbios. Santykiai nėra tik suvaržymai tarp skirtingų lentelių; jie dažnai mums padeda apibūdinti tikrąsias verslo taisykles, susijusias su tuo, kaip šie duomenys elgiasi ir kaip jie veikia kartu kaip darnus vienetas. Ir, žinoma, vertės apribojimai yra labai svarbūs. Be abejo, vienas iš dalykų, su kuriais nuolat susiduriame, ir jis tampa vis labiau paplitęs, yra tokie dalykai kaip duomenų valdymas. Taigi, žiūrėdami iš duomenų valdymo perspektyvos, turime taip pat išnagrinėti, ką mes čia apibrėžiame? Norime apibrėžti tokius dalykus kaip saugos klasifikacija. Su kokiais duomenų tipais mes susiduriame? Kas bus laikoma pagrindiniu duomenų valdymu? Kokias transakcijų parduotuves mes kuriame? Kokius informacinius duomenis naudojame šiose programose? Turime įsitikinti, kad tai tinkamai užfiksuota mūsų modeliuose. Be to, atsižvelgiant į duomenų kokybę, yra tam tikros informacijos, kuri organizacijai yra svarbesnė nei kitų.
Aš dalyvavau projektuose, kuriuose mes pakeitėme keliolika senų sistemų naujais verslo procesais ir kūrėme naujas programas ir duomenų saugyklas, kad jas pakeistume. Turėjome žinoti, iš kur gauta informacija. Kuriant svarbiausią informacijos dalį, žvelgiant iš verslo perspektyvos, jei pažiūrėsite į šį konkretų duomenų modelio skaidrę, kurią čia turiu, pamatysite, kad šių konkrečių subjektų apatiniai langeliai, kurie yra tik mažas poaibis, aš iš tikrųjų sugebėjome užfiksuoti verslo vertę. Nesvarbu, ar tai aukšta, vidutinė, ar žema šių tipų dalykams, tiems skirtingiems organizacijos konstruktams. Aš taip pat užfiksavau tokius dalykus kaip pagrindinės duomenų klasės, ar tai yra pagrindinės lentelės, ar jos yra nuorodos, ar jos buvo operatyvinės. Taigi mes galime išplėsti savo metaduomenis savo modeliuose, kad suteiktume daugybę kitų savybių, nepriklausančių pačiam duomenims, o tai tikrai padėjo mums imtis kitų iniciatyvų, nepriklausančių originaliems projektams, ir perduoti ją toliau. Dabar, kai to buvo daug vienoje skaidrėje, likusias dalis pereisiu gana greitai.
Dabar labai greitai kalbėsiu apie tai, ką daro duomenų modeliuotojas, kai išgyvename šiuos skirtingus sprintus. Visų pirma, visiškas sprinto planavimo sesijų dalyvis, kur mes imamės vartotojų pasakojimų, įsipareigojame tam, ką ketiname pristatyti tame sprinte, ir išsiaiškiname, kaip ketiname jį susisteminti ir pristatyti. Aš taip pat darau duomenų modeliuotojo darbą: žinau, kad dirbsiu atskirose srityse su skirtingais kūrėjais ar su skirtingais žmonėmis. Taigi viena iš svarbių savybių, kurias mes galime turėti, yra tai, kad mes darome duomenų modelį, mes galime padalyti tą duomenų modelį į skirtingus rodinius, nesvarbu, ar vadinate juos dalykinėmis sritimis, ar submodeliais, yra mūsų terminija. Kurdami modelį mes jį rodome ir pagal šias skirtingas submodelio perspektyvas, kad skirtingos auditorijos matytų tik tai, kas jiems aktualu, kad galėtų susikoncentruoti į tai, ką kuria ir pateikia. Taigi gali būti, kad kažkas dirba planavimo programos dalyje, galbūt kažkas dirba prie užsakymo įvedimo, kuriame visus šiuos veiksmus atliekame viename sprinte, tačiau aš galiu pateikti jiems požiūrį per tuos submodelius, kurie tik kreiptis į tą sritį, kurioje jie dirba. Tada jie renkasi į bendrą modelį ir visą submodelių struktūrą, kad pateiktų skirtingą auditorijos nuomonę, ką jiems reikia pamatyti.
Duomenų modeliavimo pagrindai, kuriuos mes norime turėti, visada turi pradinį scenarijų, prie kurio galime grįžti, nes vienas iš dalykų, kuriuos turime sugebėti padaryti, tai yra sprinto pabaigoje ar pabaigoje. iš kelių sprinto, mes norime žinoti, kur mes pradėjome, ir visada turėkime pagrindą žinoti, kokia buvo delta ar skirtumas, ką pagaminome tam tikrame sprinte. Mes taip pat turime įsitikinti, kad galime greitai apsispręsti. Jei įsitraukiate į tai kaip duomenų modeliuotojas, bet atlikdamas tradicinį vartų sargo vaidmenį sakydamas „Ne, ne, tu negali to padaryti, mes pirmiausia turime padaryti viską“, tu būsi pašalintas iš komandos, kai tau tikrai to reikia. būti aktyviu visų tų judrių tobulėjimo komandų dalyviu. Tai reiškia, kad kai kurie dalykai krinta iš vagono vykdant nurodytą sprinto laiką, ir jūs juos pasiimsite vėlesniuose sprintuose.
Kaip pavyzdį, jūs galite sutelkti dėmesį į duomenų struktūras tik tam, kad plėtra būtų savaime suprantama, ta užsakymo įvedimo dalis, apie kurią aš kalbėjau. Vėlesniame sprinte galite sugrįžti ir užpildyti duomenis, pavyzdžiui, kai kuriuos duomenų žodyno dokumentus, susijusius su kai kuriais iš jūsų sukurtų artefaktų. Neišpildysite šios apibrėžties viename sprinte; jūs ketinate tęsti savo pristatymus palaipsniui, nes kartais bus galima užpildyti šią informaciją dirbant su verslo analitikais, kai kūrėjai užsiims programų kūrimu ir išliks aplink šias duomenų saugyklas. Norite palengvinti, o ne būti kliūtimi. Yra įvairių būdų, kaip mes dirbame su kūrėjais. Kai kuriuose dalykuose mes turime dizaino modelius, taigi esame visiški dalyviai, todėl galime turėti dizaino modelį, kuriame sakysime, kad įdėsime jį į modelį, perkelsime į kūrėjų smėlio dėžės duomenų bazes ir tada jie galės pradėkite su juo dirbti ir reikalauti pakeitimų.
Gali būti ir kitų sričių, prie kurių kūrėjai dirba, kai ką jie dirba ir prototipuoja kai kuriuos dalykus, todėl kai kuriuos dalykus išbando savo kūrimo aplinkoje. Paimame tą duomenų bazę, su kuria jie dirba, įtraukiame ją į mūsų modeliavimo įrankį, lyginame su mūsų turimais modeliais, tada išsprendžiame ir grąžiname jiems pakeitimus, kad jie galėtų atnaujinti savo kodus, kad jie sektų tinkamą duomenų struktūrą. kad mums reikia. Kadangi jie galbūt sukūrė kai kuriuos dalykus, kuriuos jau turėjome kitur, todėl įsitikiname, kad jie dirba su tinkamais duomenų šaltiniais. Mes visą laiką tai kartojame iki sprinto, kad gautume visus pateiktus duomenis, visą dokumentaciją ir visų tų duomenų struktūrų, kurias mes gaminame, apibrėžimą.
Sėkmingiausi judrūs projektai, kuriuose dalyvavau, kalbant apie labai gerus pristatymus, yra tokia, kad turėjome filosofiją, modeliuodami visus visos fizinės duomenų bazės specifikacijos pakeitimus. Iš esmės duomenų modelis tampa dislokuotomis duomenų bazėmis, su kuriomis dirbate, kad ir ką sukurtume, ir joje yra visos nuorodos į kitas duomenų saugyklas, jei mes vartojame iš kitų išorinių duomenų bazių. Kaip dalį to mes gaminame papildomus scenarijus, palyginti su kiekvienos kartos visa karta. Mes naudojame savo dizaino modelius, kad suteiktume mums greitą pagreitį, kad viskas vyktų sprintuose su įvairiomis plėtros komandomis, su kuriomis mes dirbame.
„Sprint“ veikloje taip pat vėlgi yra palyginimo / sujungimo pagrindas, todėl imkimės kiekvieno pakeitimo modeliavimo idėjos. Kiekvieną kartą atlikdami pakeitimą norime modeliuoti pakeitimą ir tai, kas labai svarbu, ko trūko duomenų modeliavimui dar visai neseniai, iš tikrųjų, kol mes jo dar kartą neįdiegėme, yra galimybė susieti modeliavimą. užduotis ir jūsų rezultatus su vartotojo istorijomis ir užduotimis, kurios iš tikrųjų sukelia tuos pokyčius. Mes norime turėti galimybę patikrinti savo modelio pakeitimus, lygiai taip pat, kaip kūrėjai tikrina savo kodus, remdamiesi turimomis vartotojų istorijomis, kad žinotume, kodėl pirmiausia atlikome pakeitimus, tai yra tai, ką darome. Kai tai padarome, sugeneruojame papildomus DDL scenarijus ir skelbiame juos, kad juos būtų galima pasiimti su kitais kūrimo rezultatais ir patikrinti į mūsų „build“ sprendimą. Vėlgi, mes galime turėti vieną modelį arba dirbti su keliomis komandomis. Kaip aš jau kalbėjau, kai kuriuos dalykus sukūrė duomenų modeliuotojas, kitus dalykus sukūrė kūrėjai, ir mes susitinkame viduryje, kad sugalvotume bendrą geriausią dizainą, jį pastumtume į priekį ir įsitikintume, kad jis tinkamai suprojektuotas mūsų bendros duomenų struktūros. Turime išlaikyti discipliną, užtikrinančią, kad eidami į priekį turime visus tinkamus konstrukcijas savo duomenų modelyje, įskaitant niekinius, o ne niekinius dydžius, referencinius apribojimus, iš esmės tikrinimo apribojimus, visus tuos dalykus, apie kuriuos paprastai galvojame. .
Pakalbėkime tik apie keletą įrankių, kurie mums padeda tai padaryti, ekrano kopijų. Manau, kad svarbu turėti tą bendrą duomenų saugyklą, todėl tai, ką galime padaryti kaip duomenų modeliuotojai, ir tai yra duomenų modelio dalies fragmentas fone, yra tada, kai mes dirbame prie dalykų, kuriuos norime įsitikinti, kad galime dirbti tik su tais objektais, kuriuos turime turėti galimybę pakeisti, atlikti pakeitimus, sugeneruoti mūsų DDL scenarijus pakeitimams, kuriuos atlikome, kai tikriname dalykus iš naujo. Taigi, ką galime padaryti, „ER Studio“ yra pavyzdys, mes galime patikrinti objektus ar objektų grupes, prie kurių reikia dirbti, mes neturime tikrinti viso modelio ar submodelio, galime patikrinti tik tuos dalykus, kurie mus domina. Po to mes norime išsiregistravimo arba įsiregistravimo laiko - tai darome abiem būdais, nes skirtingos plėtros komandos veikia skirtingai. Norime įsitikinti, kad tai susiesime su vartotojo istorija ar užduotimi, kuriai keliami reikalavimai, ir tai bus ta pati vartotojo istorija ar užduotis, kurią kūrėjai kurs ir tikrins savo kodą.
Taigi, čia yra labai greitas fragmentas iš vieno iš mūsų pokyčių valdymo centrų ekranų. Ką tai daro, aš čia per daug detaliai nesigilinsiu, bet tai, ką matote, yra vartotojo pasakojimas ar užduotis ir po kiekvienu iš tų, kuriuos matote tikraisiais pakeitimų įrašais, - mes sukūrėme automatinį pakeitimų įrašą, kai mes atliekame registraciją ir išsiregistravimą, taip pat galime pateikti daugiau aprašymo ir tame pakeitimų įraše. Tai yra susieta su užduotimi. Mes galime atlikti kelis pakeitimus kiekvienoje užduotyje, kaip jūs tikėtumėtės. Kai mes einame į tą pokyčių įrašą, galime į jį pažvelgti ir, dar svarbiau, pamatyti, ką mes iš tikrųjų pakeitėme? Šiuo konkrečiu, paryškintu pasakojimu, aš turėjau vieno tipo pakeitimus, kurie buvo atlikti, ir kai aš pažiūrėjau į patį pakeitimų įrašą, jis atpažino pavienius pakeisto modelio kūrinius. Aš čia pakeičiau keletą požymių, iš naujo juos sukūriau ir kelionei buvo pateikiami vaizdai, kuriuos reikėjo pakeisti, kurie taip pat priklausė nuo tų, kad jie būtų sugeneruojami didėjančiame DLL. Tai ne tik modeliavimas baziniuose objektuose, bet ir toks galingas modeliavimo įrankis, kuris taip pat aptinka pakeitimus, kuriuos reikia perbraukti per priklausomus objektus duomenų bazėje arba duomenų modelyje.
Jei mes dirbame su kūrėjais, ir tai darome keliais skirtingais būdais, tai yra kažkas jų smėlio dėžėje ir norime palyginti ir pamatyti, kur yra skirtumai, mes naudojame palyginimo / sujungimo galimybes ten, kur yra dešinė ir kairė. pusėje. Mes galime pasakyti: „Čia yra mūsų modelis kairėje pusėje, čia yra jų duomenų bazė dešinėje pusėje, parodykite man skirtumus.“ Tada galime pasirinkti, kaip tuos skirtumus išspręsti, ar įtraukiame daiktus į duomenų bazę, ar duomenų bazėje yra keletas dalykų, kuriuos mes grąžiname į modelį. Mes galime eiti dviem kryptimis, kad galėtume eiti abiem kryptimis tuo pačiu metu atnaujindami tiek šaltinį, tiek taikinį, o tada sugeneruotume DDL scenarijus, kad tuos pakeitimus galėtume įdiegti pačioje duomenų bazės aplinkoje, o tai yra labai svarbu. Ką mes taip pat galime padaryti, mes taip pat galime naudoti šią palyginimo ir sujungimo galimybę bet kuriuo metu. Jei kelyje imame momentinius vaizdus, visada galime palyginti vieno sprinto pradžią iki kito sprinto pradžios ar pabaigos, kad galėtume pamatyti visas laipsniškas to, kas buvo padaryta tam tikrame vystymo sprinte arba per kelis sprinto ciklus, pokytis.
Tai labai greitas pakeisto scenarijaus pavyzdys, bet kuris iš jūsų, dirbęs su duomenų bazėmis, pamatysite tokio tipo dalykus. Štai ką galime išstumti iš kodo kaip pakeistą scenarijų, kad įsitikintume, jog išlaikyti daiktus čia. Ką aš iš čia ištraukiau, tik siekdamas sumažinti netvarką, mes taip pat darome su šiais pakeistais scenarijais, jei manome, kad ir tose lentelėse yra duomenų, todėl sukursime DML, kuris surinks informaciją apie laikinas lenteles ir stumkite jį atgal į naujas duomenų struktūras taip pat, todėl mes žiūrime ne tik į struktūras, bet ir duomenis, kuriuos jau turėjome ir tose struktūrose.
Labai greitai kalbėsime apie automatizuotas kūrimo sistemas, nes gana dažnai įgyvendindami lankstų projektą mes dirbame su automatizuotomis kūrimo sistemomis, kuriose turime kartu patikrinti skirtingus rezultatus, kad įsitikintume, jog nepažeidžiame savo versijų. Ką tai reiškia, kad mes sinchronizuojame rezultatus, reikia keisti tuos scenarijų pakeitimus, apie kuriuos aš kalbėjau su DDL scenarijumi, tuo pačiu metu reikia patikrinti ir atitinkamą programos kodą, o daugybė kūrėjų dabar, žinoma, nėra tai daroma naudojant tiesioginį SQL duomenų bazėms ir tokio tipo daiktams. Gana dažnai mes naudojame patvarumo sistemas ar pastatų duomenų paslaugas. Turime įsitikinti, kad tų sistemų ar paslaugų pakeitimai bus registruojami tiksliai tuo pačiu metu. Kai kuriose organizacijose jie pereina į automatizuotą kūrimo sistemą ir, jei sudėtinga metodika, prieš pradedant judėti, visos denio tvirtinimo užduotys yra visos rankos, kad žinotume, kad prieš eidami toliau, žinome, kad turime veikiantį sprendimą. Ir viename iš projektų, kuriuose dalyvavau, mes ėmėmės to į kraštutinumą - jei pastatydami broką iš tikrųjų buvome prijungę prie daugelio mūsų rajone esančių kompiuterių, kuriuose buvome apgyvendinti su verslo vartotojais, mes tiesiog turėjome raudonas mirksinčias lemputes. kaip policijos automobilių viršuje. Jei pastatas sugedo, pradėjo mirksėti tie raudoni mirksintys žibintai ir mes žinojome, kad visa tai yra ant denio: pritvirtinkime pastatą ir tęskime tai, ką darėme.
Noriu pakalbėti apie kitus dalykus, ir tai yra išskirtinė „ER Studio“ galimybė. Tai tikrai padeda, kai mes bandome kurti šiuos artefaktus kaip šių atkaklumo ribų kūrėjus, turime koncepciją, vadinamą verslo duomenų objektais, ir tai, kas mums leidžia jei pažvelgtumėte į šį labai supaprastintą duomenų modelį kaip į pavyzdį, jis leidžia mums sujungti subjektus ar subjektų grupes ten, kur yra patvarumo ribos. Kur mes, kaip duomenų modeliuotojai, galvojame apie pirkimo užsakymo antraštę, užsakymų suderinimo lentelę ir kitas išsamias lenteles, kurios atitiktų mūsų pateikimo principą, o mūsų duomenų paslaugų kūrėjai turi žinoti, kaip viskas vyksta atsižvelgiant į tuos skirtingus duomenis struktūros. Mūsų kūrėjai galvoja apie tokius dalykus kaip pirkimo užsakymas kaip bendras objektas ir kokia yra jų sutartis su tuo, kaip jie sukuria tuos konkrečius objektus. Mes galime atskleisti tą techninę detalę, kad žmonės, kuriantys duomenų serverius, matytų, kas yra po juo, ir mes galime apsaugoti kitas auditorijas nuo sudėtingumo, kad jie tiesiog matytų skirtingus aukštesnio lygio objektus, kurie taip pat labai gerai tinka bendrauti su verslu analitikai ir verslo suinteresuotieji subjektai, kai mes taip pat kalbame apie skirtingų verslo koncepcijų sąveiką.
Puiku ir tai, kad mes konstruktyviai juos plečiame ir sutraukiame, kad galėtume palaikyti ryšius tarp aukštesnės eilės objektų, net jei jie yra kilę iš konstrukcijų, esančių tuose verslo duomenų objektuose. Dabar, kaip modeliuotojas, nuvykite į sprinto pabaigą, po sprinto suvyniojimo, turiu daugybę dalykų, kuriuos turiu padaryti, kuriuos aš vadinu savo namų tvarkymu kitam sprintui. Kiekvieną sprinto laiką sukuriu tai, ką vadinu Pavadinta laida - tai suteikia man pagrindą tam, ką aš dabar turiu laidos pabaigoje. Taigi tai reiškia, kad mano pradinė linija eina į priekį, visas šias bazines linijas arba Pavadintus leidimus, kuriuos sukuriu ir išsaugoju saugykloje, galiu naudoti palyginimui / sujungimui, kad visada galėčiau palyginti su bet kuria kita sprinto pabaiga iš bet kurio kito sprinto, kuris labai svarbu žinoti, kokie buvo jūsų duomenų modelio pakeitimai pakeliui į kelionę.
Aš taip pat sukuriu DDL scenarijų delta, naudodamas vėl palyginimą / suliejimą nuo sprinto pradžios iki pabaigos. Aš galbūt patikrinau visą krūvą pavienių scenarijų, bet jei man jo reikia, dabar turiu scenarijų, kurį galėčiau panaudoti, kad atsistotų kitos smėlio dėžės, kad galėčiau tiesiog pasakyti, kad tai buvo tai, ką mes turėjome vieno sprinto pradžioje, stumti sukurti, sukurti duomenų bazę kaip „smėlio dėžę“, kad galėtume pradėti nuo kito sprinto, ir mes taip pat galime naudoti tuos dalykus, pavyzdžiui, standup QA egzempliorius, ir, žinoma, mes norime, kad mūsų pakeitimai būtų pritaikyti gamyboje, taigi turime daug dalykų. Tuo pačiu metu. Vėlgi, mes visapusiškai dalyvaujame sprinto planavime ir retrospektyvoje, retrospektyvos iš tikrųjų yra išmoktos pamokos ir tai yra nepaprastai svarbu, nes judrumo metu galite labai greitai pradėti važiuoti, turite sustoti ir švęsti sėkmes, kaip dabar. Išsiaiškink, kas ne taip, padaryk tai geriau kitą kartą, bet taip pat švęsk tuos dalykus, kurie vyko teisingai, ir remkis jais, kol judėsi į priekį per kitus sprintus eidamas į priekį.
Dabar labai greitai kalbėsiu apie verslo vertę. Buvo projektas, kuriame dalyvavau prieš daugelį metų ir kuris prasidėjo kaip judrus projektas, ir tai buvo kraštutinis projektas, taigi tai buvo grynai savarankiškai organizuojanti komanda, kur viską kūrė tiesiog kūrėjai. Trumpai tariant, šis projektas pritrūko ir jie pamatė, kad vis daugiau ir daugiau kartų išleido nustatytų trūkumų pašalinimui ir taisymui, nei buvo siekiama išplėsti didesnį funkcionalumą ir, tiesą sakant, kai jie žiūrėjo į jį pagrįstai. sudegusiųjų diagramose jie turėjo pratęsti projektą šešiais mėnesiais už didžiulę kainą. Kai mes tai pažvelgėme, būdas pašalinti šią problemą buvo panaudoti tinkamą duomenų modeliavimo įrankį su kvalifikuotu duomenų modeliuotoju, kuris dalyvavo pačiame projekte.
Jei pažvelgsite į šią vertikalią juostą šioje konkrečioje diagramoje, tai rodo kumuliacinius trūkumus, palyginti su kaupiamaisiais objektais, ir aš kalbu apie sukurtus duomenų objektus ar konstrukcijas, pavyzdžiui, lenteles su apribojimais ir tokio tipo daiktus, jei pažvelgėte į prieš įvedant duomenų modeliuoklį, defektų skaičius iš tikrųjų viršijo ir pradėjo šiek tiek didėti atotrūkis nuo tikrojo objektų, kurie buvo sukurti iki to laiko, skaičiaus. Po 21 savaitės, t. Y., Kai įėjo duomenų modeliuotojas, iš naujo pritaikė duomenų modelį, remdamasis tuo, kas turėjo išspręsti daugybę dalykų, ir tada pradėjo modeliuoti kaip dalį projekto komandos, einančios į priekį, pokyčiai, kai tas projektas buvo stumiamas į priekį . Ir jūs pamatėte labai greitą posūkį, kad maždaug per pusantro sprinto mes pamatėme didžiulį objektų ir duomenų konstrukcijų, kurios buvo kuriamos ir konstruojamos, skaičių padidėjimą, nes mes generuodavome ne iš duomenų modeliavimo įrankio, o iš kūrėjo lazdelės. pastatyti juos aplinkoje, ir jie buvo teisingi, nes turėjo tinkamą referencinį vientisumą ir kitas konstrukcijas, kurias jis turėjo. Defektų lygis palyginti su beveik plokščiais. Imdamasis tinkamų veiksmų ir įsitikinęs, kad duomenų modeliavimas buvo visapusiškai pritaikytas, projektas buvo pristatytas laiku, o jo kokybė buvo aukštesnė, ir iš tikrųjų jis nebūtų buvęs įgyvendintas, jei šie veiksmai nebūtų buvę atlikti. Yra daug judrių nesėkmių, taip pat yra nemažai judrių sėkmių, jei gautumėte tinkamus žmones į tinkamus vaidmenis. Aš esu didžiulis judraus, kaip operatyvinės disciplinos šalininkas, tačiau jūs turite įsitikinti, kad turite visų tinkamų grupių, kaip jūsų projekto komandos, įgūdžius, kai einate į priekį judrių pastangų link.
Apibendrinant galima pasakyti, kad duomenų architektai ir modeliuotojai turi būti įtraukti į visus plėtros projektus; jie iš tikrųjų yra klijai, laikantys viską kartu, nes, kaip duomenų modeliuotojai ir architektai, mes suprantame, ne tik pateikto plėtros projekto duomenų konstrukcijas, bet ir tai, kur yra duomenys organizacijoje ir iš kur galime juos gauti, ir kaip jie bus naudojama ir naudojama ne pačioje programoje, prie kurios dirbame. Mes suprantame sudėtingus duomenų ryšius ir labai svarbu sugebėti judėti į priekį, o taip pat ir iš valdymo perspektyvos, kad sudarytume dokumentą ir suprastume, kaip atrodo visas jūsų duomenų vaizdas.
Tai yra kaip gamyba; Aš kilęs iš gamybos srities. Galų gale jūs negalite patikrinti kokybės į ką nors - turite iš anksto ir pakeisdami savo dizainą integruoti kokybę, o duomenų modeliavimas yra būdas efektyviai ir ekonomiškai pritaikyti šią kokybę dizaine. . Ir vėl, ką reikia atsiminti - ir tai neturi būti apgaulinga, bet tiesa, kad programos ateina ir išeina, duomenys yra gyvybiškai svarbus įmonės turtas ir peržengia visas tas taikymo ribas. Kiekvieną kartą pateikdami programą turbūt esate paprašomi išsaugoti duomenis iš kitų anksčiau galiojusių programų, todėl mums tiesiog reikia atsiminti, kad tai yra gyvybiškai svarbus įmonės turtas, kurį mes nuolat prižiūrime.
Štai ir viskas! Iš čia imsimės daugiau klausimų.
Erikas Kavanaghas: Gerai, gerai, leisk man pirmiausia tai perduoti Robinui. Ir tada, Dez, aš tikiu, kad turite porą klausimų. Pašalink jį, Robin.
Dr Robin Bloor: Gerai. Tiesą sakant, aš niekada neturėjau problemų dėl judrių kūrimo metodų ir man atrodo, kad tai, ką jūs darote, yra be galo prasminga. Prisimenu, kai kažkada devintajame dešimtmetyje pažvelgiau į tai, kas iš tikrųjų nurodė, kad problema, su kuria jūs iš tikrųjų susidūrėte, kai projektas nekontroliuojamas, paprastai yra, jei leidžiate klaidai išlikti už tam tikro etapo. Tai tiesiog tampa vis sunkiau ištaisyti, jei neteisingai suprantate šį etapą, taigi vienas iš dalykų, kuriuos jūs čia darote - ir aš manau, kad tai yra skaidrė - bet vienas iš dalykų, kuriuos jūs čia darote Nulinis sprinte, mano manymu, yra be galo svarbus, nes tu tikrai bandai ten prikabinti rezultatus. Ir jei jums nereikia prisegti pristatymų, tada jie pakeis formą.
Tokia, mano nuomonė. Tai taip pat mano nuomonė - aš tikrai neturiu jokių argumentų su mintimi, kad prieš pradėdami pereiti, turite gauti duomenų modeliavimo teisę į tam tikrą detalumo lygį. Tai, ko aš norėčiau, kad jūs pabandytumėte padaryti, nes aš to nesupratau, tiesiog aprašykite vieną iš šių projektų pagal jo dydį, kaip jis vyko, kalbant apie tai, kas, jūs žinote, kur iškilo problemos, ar jos buvo išspręstos? Kadangi manau, kad ši skaidrė yra jos esmė ir, jei galėtumėte šiek tiek daugiau apie tai papasakoti, būčiau labai dėkinga.
Ron Huizenga: Žinoma, aš panaudosiu keletą pavyzdžių projektų. Tas, kuris tarsi nukrypo nuo bėgių, buvo sugrąžintas iš tikrųjų įtraukiant reikiamus žmones ir atliekant duomenų modeliavimą. Viskas iš tikrųjų buvo būdas įsitikinti, kad dizainas buvo geriau suprantamas ir mes, aišku, turėjome geresnį diegimo dizainą. pakeliui modeliuodamas. Nes modeliuodami, jūs žinote, galite sugeneruoti savo DDL ir viską, kas yra ne tik įrankyje, bet ir įrankyje, užuot prilipę prie to, kaip paprastai daro žmonės, eidami tiesiai į duomenų bazių aplinką. Ir tipiški dalykai, kurie nutiks su kūrėjais, yra tai, kad jie ten pateks ir sakys: gerai, man reikia šių lentelių. Tarkime, mes darome užsakymų įrašus. Taigi jie gali sukurti užsakymo antraštę ir užsakymo detalių lenteles bei tuos dalykus. Tačiau jie gana dažnai pamirš arba apleis, kad įsitikintų, jog pagrindiniai užsienio santykiai yra suvaržyti. Galbūt jie neturi raktų. Taip pat gali kilti įtarimų dėl pavadinimų sudarymo. Aš nežinau, kiek kartų esu patekęs į tokią aplinką, kur, pavyzdžiui, matai krūvą skirtingų lentelių su skirtingais pavadinimais, bet tada stulpelių pavadinimai tose lentelėse yra tokie, kaip ID, Vardas ar kas kita, taigi jie „Mes tikrai praradome kontekstą, neturėdami lentelės, kas tai yra.
Taigi paprastai modeliuodami duomenis įsitikinsime, kad taikome tinkamus vardų sudarymo metodus visiems artefaktams, kurie generuojami ir DDL. Kalbant konkrečiau apie pačių projektų pobūdį, paprastai kalbu apie gana dideles iniciatyvas. Vienas iš jų buvo 150 milijonų dolerių vertės verslo pertvarkymo projektas, kuriame mes pakeitėme daugiau nei tuziną senųjų sistemų. Vienu metu vyko penkios skirtingos judrios komandos. Aš turėjau pilną duomenų architektūros komandą, todėl turėjau duomenų modeliuotojų iš savo komandos, įdėtų į kiekvieną kitą taikymo srities komandą, ir mes dirbome kartu su vidaus verslo ekspertais, kurie žinojo dalyką, kurie dirbo pačių naudotojų pasakojimai apie pačius reikalavimus. Kiekvienoje komandoje buvo verslo analitikų, kurie realiai modeliavo verslo procesą, naudodamiesi veiklos schemomis ar verslo proceso schemomis, padėdami labiau suformuluoti vartotojų istorijas, prieš juos panaudodami ir likusiai komandai.
Ir tada, žinoma, kūrėjai, kurie kūrė programos kodą. Ir mes taip pat dirbome su, manau, kad keturi skirtingi sistemų integracijos pardavėjai taip pat kūrė skirtingas programos dalis, kur viena komanda kūrė duomenų paslaugas, kita - kūrė programos logiką vienoje srityje, kita - turėjo patirties. kitoje verslo srityje buvo kuriama taikymo logika toje srityje. Taigi, mes bendradarbiavome su žmonėmis, kurie dirbo prie šio projekto. Ypač toje komandoje buvo 150 žmonių krante, o dar 150 išteklių, esančių atviroje jūroje, komandoje, kurie bendradarbiavo dviejų savaičių sprintuose, kad išstumtų šį reikalą. Ir kad tai padarytumėte, turite įsitikinti, kad šaudote į visus cilindrus, ir visi yra gerai sinchronizuoti pagal tai, kokie yra jų produktai, ir jūs turėjote tuos dažnus nustatymus, kad įsitikintumėte, jog mes pristatėme visus reikalingus artefaktus. kiekvieno sprinto pabaigoje.
Dr Robin Bloor: Na, tai įspūdinga. Ir tik šiek tiek išsamiau apie tai - ar to projekto pabaigoje galėjote pateikti išsamų, vadinamą, MDM visos duomenų srities žemėlapį?
Ronas Huizenga: Mes turėjome išsamų duomenų modelį, kuris buvo suskirstytas pagal skilimą tarp visų skirtingų verslo sričių. Pats duomenų žodynas pagal visas apibrėžtis šiek tiek pritrūko. Mes apibrėžėme daugumą lentelių; daugumoje stulpelių buvo apibrėžta, ką jie tiksliai reiškia. Kai kurių tokių nebuvo, ir, įdomu tai, kad nemažai jų buvo informacija, gauta iš senųjų sistemų, kur, pasibaigus paties projekto apimčiai, ji vis dar buvo dokumentuojama kaip perkeliamas dokumentų rinkinys. artefaktus, kurie buvo ne iš paties projekto, nes tai turėjo kažkas palaikyti tolimesnei organizacijai. Taigi tuo pat metu organizacija pažiūrėjo į duomenų valdymo svarbą, nes matėme daug trūkumų tose senosiose sistemose ir tuose senų duomenų šaltiniuose, kuriuos bandėme sunaudoti, nes jie nebuvo dokumentuojami. Daugeliu atvejų mes turėjome tik duomenų bazes, kurias mums reikėjo pakeisti ir bandyti išsiaiškinti, kas ten buvo ir kam skirta informacija.
Dr Robin Bloor: Manęs tai nestebina, būtent tas jo aspektas. Duomenų valdymas yra, vadinkime tai, labai šiuolaikiškas rūpestis ir aš manau, kad tikrai yra daug darbo, kuris, sakykime, istoriškai turėjo būti atliktas duomenų valdymo srityje. Tai niekada nebuvo todėl, kad galėjai atsikratyti to nepadaręs. Bet kai duomenų šaltinis tik augo ir augo, galų gale jūs negalėjote.
Bet kokiu atveju aš pereisiu prie Dezo, nes manau, kad turėjau tam skirtą laiką. Dezas?
Dezas Blanchfildas: Taip, ačiū. Aš per visa tai stebiu ir galvoju sau, kad mes kalbame apie tai, kaip matome judrų, pyktį naudojantį įvairiais būdais. Nors tai turi neigiamas konotacijas; Aš turėjau omenyje tai teigiamai. Gal galėtumėte tiesiog pateikti scenarijų, turiu omenyje, kad yra dvi vietos, kur aš matau, kad tai yra tobulas rinkinys: vienas yra nauji projektai, kuriuos tiesiog reikia daryti nuo pirmosios dienos, bet aš manau, kad, be jokios abejonės, tai dažnai būna mano patirtis atvejis, kai projektai tampa pakankamai dideli, kad tai būtina įvairiais būdais, tarp dviejų pasaulių klijavimo yra įdomus iššūkis, tiesa? Ar galite pateikti mums kokių nors įžvalgų apie kai kurias sėkmės istorijas, kurias matėte kur įsitraukėte į organizaciją, tampa akivaizdu, kad jie šiek tiek susidūrė su dviem pasauliais ir jūs sugebėjote sėkmingai pateikti Ar tai yra vieta ir suburti didelius projektus ten, kur jie galbūt būtų nuėję ant bėgių? Aš žinau, kad tai labai platus klausimas, bet man tiesiog įdomu, ar yra koks nors konkretus atvejo tyrimas, kurį galite rūšiuoti, nurodyti, kur sakėte, žinote, mes visa tai įdėjome į vietą ir tai subūrė visą plėtros komandą su duomenų komanda ir mes, kažkaip, kreipėmės į tai, kas galbūt galėjo paskandinti valtį?
Ronas Huizenga: Tikrai, ir iš tikrųjų minėtasis projektas buvo dujotiekio projektas, į kurį aš užsiminiau, kur parodžiau tą diagramą su trūkumais prieš ir po duomenų modeliuotojo dalyvavimo. Gana dažnai ir yra išankstinių nusistatymų, ypač jei viskas susiklosto ten, kur tai padaryta vien iš plėtros perspektyvos, šiems judriems projektams dalyvauti kuriant programas yra reikalingi tiesiog kūrėjai. Taigi, kas ten nutiko, žinoma, ar jie išlipo iš bėgių, o ypač jų duomenų artefaktai ar jų kuriami duomenys buvo žymiai mažesni nei kokybės požiūriu, nei iš tikrųjų skirti visiems dalykams. Ir gana dažnai susidaro tokia klaidinga nuomonė, kad duomenų modeliuotojai sulėtins projektų vykdymą, ir jie nutiks, jei duomenų modeliuotojas neturės tinkamo požiūrio. Kaip aš sakau, jūs turite prarasti - kartais yra duomenų modeliuotojų, kurie laikosi tokio tradicinio „vartininko“ požiūrio, kai „mes čia norime kontroliuoti, kaip atrodo duomenų struktūros“, ir tas mentalitetas turi išnykti. Kiekvienas, įsitraukęs į judrų vystymąsi, ypač duomenų modeliuotojai, turi atlikti tarpininko vaidmenį, kad iš tikrųjų padėtų komandoms judėti į priekį. Geriausias būdas tai parodyti yra labai greitai parodyti komandoms, kiek jos gali būti produktyvios, pirmiausia modeliuodamas pokyčius. Ir vėlgi, todėl ir kalbėjau apie bendradarbiavimą.
Yra keletas dalykų, kuriuos pirmiausia galime modeliuoti ir sugeneruoti DDL, kad išstumtų kūrėjus. Mes taip pat norime įsitikinti, kad jie nesijaučia esą apriboti. Taigi, jei yra dalykų, prie kurių jie dirba, leisk jiems toliau dirbti savo kūrimo smėlio dėžėse, nes būtent ten kūrėjai dirba prie savo stalinių kompiuterių ar kitų duomenų bazių, kad galėtų atlikti kai kuriuos pakeitimus, kai jie išbando dalykus. Bendradarbiaukite su jais ir sakykite: „Gerai, dirbk su tuo.“ Įtrauksime jį į įrankį, išspręsime, tada mes jį perkelsime į priekį ir pateiksime scenarijus, kuriuos galėsite panaudoti, kad atnaujintumėte savo duomenų bazes, kad atnaujintume jas į tai, kokia bus tikroji sankcionuota tikrovės nuomonė apie tai, koks bus toliau, kai judame toliau. Ir jūs galite tai greitai pakeisti. Aš sužinojau, kad mano dienos buvo užpildytos ten, kur aš tiesiog eidavau pirmyn ir atgal kartodamas įvairias kūrimo komandas, žiūrėdamas į pokyčius, lygindamas, generuodamas scenarijus, įvesdamas juos ir aš gana lengvai sugebėjau atsilikti nuo keturių plėtros komandų, kai tik mes. pasiekė pagreitį.
Dezas Blanchfildas: Vienas iš dalykų, kurie į tai įsimenu, yra tas, kad, žinote, daugybė pokalbių, kuriuos aš kasdien turiu, yra apie tai, kad šis krovininis traukinys atvažiuoja pas mus, tarsi iš mašinų, į -mašina ir internetas. Ir jei mes manome, kad dabar turime labai daug duomenų apie dabartinę mūsų įmonės aplinką, žinote, jei akimirką atmesime vienaragius, kai žinosime, kad „Google“ ir „Facebooks“ bei „Ubers“ turi duomenų petatabčių, tačiau tradicinėje įmonėje mes kalbame apie šimtus terabaitų ir daugybę duomenų. Bet, mano manymu, šis krovininis traukinys ateina į organizacijas, kurias dr. Robinas Blooras užsiminė anksčiau. Žinote, turime daug internetinio srauto, socialinio srauto, dabar turime mobilumą ir mobiliuosius įrenginius, debesis tarsi sprogo, bet dabar turime intelektualią infrastruktūrą, išmaniuosius miestus ir yra visas šis duomenų pasaulis, kuris tik sprogo.
Kasdieninei organizacijai, ten sėdinti ir matanti šį skausmo pasaulį ateina vidutinio dydžio ir didelė organizacija, kuri neturi minties apie betarpišką planą, kuriuos galite pasiimti tik pora sakinių, kuriuos galite paimti, jiems, kada ir kur jiems reikia pradėti pokalbio metu galvoti apie kai kurių iš šių metodikų įdiegimą. Kaip anksti jiems reikia pradėti planuoti beveik sėdėti ir atkreipti dėmesį ir pasakyti, kad dabar yra tinkamas laikas turėti keletą įrankių, paruošti komandą ir susikalbėti kalbant apie šį iššūkį? Kaip per vėlai istorijoje per vėlu ar kada per anksti? Kaip tai atrodo kai kurioms organizacijoms, kurias matote?
Ronas Huizenga: Aš sakyčiau daugumai organizacijų, kad jei jos to dar nepadarė ir pritaikė duomenų modeliavimą ir duomenų architektūrą tokiomis galingomis priemonėmis kaip šis, laikas, kurį joms reikia padaryti, yra vakar. Nes įdomu, kad net ir šiandien, kai žiūrite į duomenis organizacijose, turime tiek daug duomenų savo organizacijose ir, kalbant paprastai, remiantis kai kuriomis apklausomis, kurias mes matėme, efektyviai naudojame mažiau nei penkis procentus tų duomenų kai žiūrime į organizacijas. O naudojant internetinę internetą ar net NoSQL, dideli duomenys - net jei tai ne tik internetas, bet ir tik dideli duomenys - ten, kur mes dabar pradedame vartoti dar daugiau informacijos, gaunamos ne iš mūsų organizacijų, šis iššūkis tampa vis didesnis. Visą laiką. Vienintelis būdas, kurį turime galimybę išspręsti, yra padėti mums suprasti, apie ką tie duomenys yra.
Taigi, naudojimo atvejis yra šiek tiek kitoks. Tai, kas mums atrodo, yra tai, kai mes žiūrime į tuos duomenis, juos fiksuojame, turime juos modifikuoti, pažiūrėti, kas yra tuose, ar tai yra mūsų duomenų ežeruose, ar net mūsų vidaus duomenų bazėse, susintetinti tai, kas yra Duomenys yra, pritaikykite jiems reikšmes ir apibrėžimus, kad galėtume suprasti, kas yra duomenys. Nes kol nesuprantame, kas tai yra, mes negalime užtikrinti, kad mes jį tinkamai ar tinkamai naudojame. Taigi mums tikrai reikia susitvarkyti, kokie tie duomenys yra. Kita dalis yra tai, nedarykite to, nes jūs, naudodamiesi visais šiais išoriniais duomenimis, galite įsitikinti, kad turite naudojimo atvejį, kuris palaiko šių išorinių duomenų naudojimą. Sutelkite dėmesį į dalykus, kurių jums reikia, o ne tik stenkitės patraukti ir panaudoti daiktus, kurių jums gali prireikti vėliau. Pirmiausia sutelkite dėmesį į svarbius dalykus ir atlikdami savo veiksmus, tada imsitės vartoti ir bandyti suprasti kitą informaciją iš išorės.
Puikus to pavyzdys yra tai, kad žinau, kad kalbame apie daiktinę internetą ir jutiklius, tačiau tos pačios rūšies problemos daugelyje organizacijų egzistuoja daugelį metų, net prieš internetą. Kiekvienas, kas turi gamybos kontrolės sistemą, nesvarbu, ar tai dujotiekio įmonė, gaminanti įmonė, bet kuri proceso pagrindu veikianti įmonė, turinti dalykų, kur daug automatizuoja valdikliais ir naudojasi duomenų srautais ir panašiais dalykais, turi Šie duomenų židiniai, kuriuos jie bando išgerti, kad išsiaiškintų, kokie įvykiai, įvykę mano gamybos įrangoje, signalizuoja - kas atsitiko ir kada? Tarp šio didžiulio duomenų srauto yra tik tam tikra informacija ar žymės, kurios juos domina ir kurias reikia išsiskirti, susintetinti, modeliuoti ir suprasti. Ir jie gali nekreipti dėmesio į likusią dalį, kol ateis laikas tai iš tikrųjų suprasti, ir tada jie galės išplėsti savo taikymo sritį, kad vis daugiau ir daugiau to įtrauktų į taikymo sritį, jei tai prasminga.
Dezas Blanchfildas: Iš tikrųjų taip yra. Yra vienas klausimas, į kurį aš atsakysiu. Tai pateikė džentelmenas, vardu Ericas, ir mes apie tai kalbėjomės privačiai. Aš tiesiog paprašiau jo leidimo, kurį jis davė, to paprašyti iš jūsų. Nes tai veda prie to, kad tik susitaupytų, nes mes po truputį einame į priekį ir aš grąžinsiu Erikui. Bet kito Erico klausimas buvo, ar pagrįsta manyti, kad pradedančiųjų įmonių savininkai yra susipažinę ir supranta unikalius iššūkius, susijusius su modeliavimo terminija, ir panašiai, ar turėtų būti perduoti kam nors kitam aiškinti? Taigi, kitaip tariant, ar pradedantysis turėtų būti pajėgus ir pasiruošęs, norintis ir sugebėti sutelkti dėmesį į tai ir to pasiekti? Ar tai yra kažkas, ką jie turbūt turėtų apsipirkti ir įtraukti ekspertus?
Ronas Huizenga: Manau, trumpas atsakymas - ar tai tikrai priklauso. Jei tai yra paleistis, kurioje nėra kažkokio vidinio duomenų architekto ar modeliuotojo, kuris iš tikrųjų suprastų duomenų bazę, tada greičiausias būdas pradėti yra suteikti kažkam konsultavimo pagrindą, kuris šioje srityje yra labai gerai išmanantis ir gali gauti. jie eina. Nes tai, ką rasite - ir iš tikrųjų aš tai padariau atlikdama daugybę užduočių, kurias padariau prieš perėjusi į tamsiąją produktų valdymo pusę - ar aš eisiu į organizacijas kaip konsultantas, vadovausiu jų duomenų architektūros komandoms, kad jie galėtų persiorientuoti ir išmokyti savo žmones, kaip tai padaryti, kad jie galėtų tai palaikyti ir vykdyti misiją. Ir tada aš pereisiu prie kito savo sužadėtuvių, jei tai prasminga. Yra daug žmonių, kurie tai daro, kurie turi labai gerą duomenų patirtį, kuri gali juos paskatinti.
Dezas Blanchfieldas: Tai puikus atsikraustymo taškas ir aš tam visiškai sutinku ir esu tikras, kad dr. Robinas Blooras taip pat tai atliktų. Visų pirma pradedant verslą, jūs orientuojatės į tai, kad esate maža ir vidutinė įmonė, atsižvelgdami į pasiūlymo, kurį norite sukurti kaip savo startuolio verslą, vertę ir tikriausiai neturėtumėte būti visko ekspertas, todėl turite puikių patarimų. Bet labai ačiū, fantastiškas pristatymas. Tikrai puikūs atsakymai ir klausimai. Erike, aš kreipsiuosi į jus, nes žinau, kad per tam tikrą laiką praleidome dešimt minučių, ir žinau, kad mėgstate prilipti prie mūsų laiko langų.
Erikas Kavanaghas: Tai gerai. Turime bent porą gerų klausimų. Leisk man vieną tau parodyti. Manau, jūs atsakėte į keletą kitų. Bet labai įdomus vieno dalyvio, kuris rašo, pastebėjimas ir klausimas, kartais judriuose projektuose duomenų modeliuotojas neturi viso ilgalaikio vaizdo ir todėl jie užbaigia ką nors suprojektuoti viename sprinte, o po to turi perdaryti tris ar keturis sprintuose. Ar tai neatrodo neproduktyvu? Kaip galima išvengti tokio dalyko?
Ronas Huizenga: Tiesiog judrus pobūdis yra tas, kad tam tikrame sprinte nepadarysite visko teisingai. Tai iš tikrųjų yra judrios dvasios dalis: dirbkite su ja - atliksite prototipų kūrimą ten, kur dirbate pagal kodą tam tikrame sprinte, ir jį patobulinsite. Dalis to proceso yra tai, kaip jūs pristatote daiktus, kuriuos mato galutinis vartotojas ir sako: „Taip, tai yra arti, bet man tikrai reikia, kad turėčiau tai padaryti ir šiek tiek papildomai“. Taigi, kad tai paveiktų ne tik funkcinį dizainą. paties kodo, tačiau gana dažnai mes turime pakeisti arba pridėti daugiau duomenų struktūros po šiais tam tikrais dalykais, kad pateiktume tai, ko vartotojas nori. Ir tai viskas sąžiningas žaidimas, ir todėl jūs tikrai norite naudoti didelio galingumo įrankius, nes labai greitai galite modeliuoti ir atlikti tą pakeitimą modeliavimo įrankyje, o tada sugeneruoti DDL duomenų bazei, kurią kūrėjai vėliau gali panaudoti pristatydami tą įrankį. pakeisti dar greičiau. Taupote juos, kad nereikėtų atlikti tokio duomenų kodavimo, koks buvo, rankomis, ir leisti jiems susikoncentruoti į programavimo ar taikymo logiką, kurią jie labiausiai moka.
Ericas Kavanaghas: Tai visiškai prasminga. Turėjome porą kitų žmonių, kurie klausė konkrečių klausimų, kaip visa tai susieta su įrankiu. Aš žinau, kad jūs praleidote tam tikrą laiką ieškodami pavyzdžių ir rodėte keletą ekrano kopijų, kaip iš tikrųjų išleidžiate dalį šios medžiagos. Kalbant apie visą šį sprinto procesą, kaip dažnai jūs matote, kad žaidžiant organizacijose, palyginti su tuo, kaip dažnai jūs matote tradiciškesnius procesus, kai viskas teisinga, savaime susitvarko ir užima daugiau laiko? Ar vyrauja sprinto stiliaus požiūris iš jūsų perspektyvos?
Ronas Huizenga: Manau, kad mes matome tai vis daugiau ir daugiau. Aš žinau, kad, sakyčiau, tikriausiai per pastaruosius 15 metų aš daug daugiau mačiau žmonių, kurie pripažino, jog jiems reikia greitesnio pristatymo. Taigi mačiau vis daugiau ir daugiau organizacijų šokinėjančių ant judraus juostinio vagono. Nebūtinai visiškai; jie gali pradėti nuo kelių bandomųjų projektų, kad įrodytų, kad tai veikia, tačiau yra keletas projektų, kurie vis dar yra labai tradiciniai ir jie laikosi krioklio metodo. Dabar, be abejo, gera žinia yra ta, kad įrankiai labai gerai veikia ir tose organizacijose, taip pat ir tokio tipo metodikose, tačiau įrankis yra pritaikomas taip, kad tie, kurie šokinėja, turi įrankius įrankių dėžėje jų pirštų galiukai. Tokie dalykai kaip palyginimas ir sujungimas, pavyzdžiui, atvirkštinio inžinerijos galimybės, kad galėtų pamatyti, kokie yra esami duomenų šaltiniai, taigi iš tikrųjų galėtų palyginti ir generuoti papildomus DDL scenarijus. Ir kai jie pradeda tai suvokti bei mato, kad gali turėti produktyvumą, jų polinkis apimti judrumą dar labiau padidėja.
Ericas Kavanaghas: Na, tai puikus dalykas, žmonės. Aš ką tik paskelbiau skaidrių nuorodą ten, pokalbių lange, todėl patikrinkite; tai tau truputį truputį. Mes turime visas šias internetines transliacijas, kad galėtume jas vėliau peržiūrėti. Nesivaržykite pasidalyti jais su draugais ir kolegomis. O Roni, labai ačiū už jūsų laiką šiandien, jums visada malonu būti šou - tikras srities ekspertas ir akivaizdu, kad žinote savo daiktus. Taigi, ačiū jums ir ačiū IDERA ir, žinoma, Dez ir mūsų pačių Robinui Bloorui.
Ir su tuo mes atsisveikinsime, žmonės. Dar kartą ačiū už jūsų laiką ir dėmesį. Dėkojame, kad laikotės 75 minutes, tai yra gana geras ženklas. Geri šou vaikinai, mes su jumis kalbėsimės kitą kartą. Iki.
