Ära võtma: Host Eric Kavanagh arutab Robin Bloori, Dez Blanchfieldi ja IDERA Ron Huizenga andmete modelleerimise olulisust agiilses arengus.
Te pole praegu sisse logitud. Video nägemiseks logige sisse või registreeruge.
Eric Kavanagh: Hea küll, daamid ja härrad. Tere tulemast veel kord. Selle kolmapäev kell 4:00 EST. See tähendab, et on aeg Hot Technologiesi jaoks. Jah, tõesti. Minu nimi on Eric Kavanagh, ma olen teie peremees.
Tänase teema jaoks on see vanavara, aga maiuspala. See muutub iga päevaga paremaks, kuna see kujundab meie andmehaldusmaailma “Andmete modelleerimine agiilses keskkonnas”. Teie oma slaid tõesti kajastab mind saidil @eric_kavanagh. Me peaksime selle tõesti sellele slaidile panema. Ma pean sellega hakkama saama.
Nii et aastad on kuumad. Andmete modelleerimine on kestnud igavesti. See on olnud tõepoolest teabehaldusettevõtte keskmes ja hinges, kavandades andmemudeleid, püüdes aru saada ärimudelitest ja viia need vastavusse teie andmemudelitega. See on tõesti see, mida proovite teha, eks?
Andmemudel esindab ettevõtet põhimõtteliselt, kuidas kõik need uued andmeallikad mängu muudavad? Tahtsime sellest teada saada. Saime teada, kuidas saaksite asjade peal kõigega kursis olla. Ja muidugi, see on aasta sõna.
Robin Bloors koos meiega, meie peaanalüütik Dez Blanchfield, kes helistab Sydneyst, Austraaliast ja Ron Huizenga, IDERA vanemtoodete juht - minu kauaaegne sõber, kes on selles ruumis suurepärane esineja, teab oma asju, nii et ärge kartke, küsige temalt rasked küsimused, inimesed, rasked. Sellega kavatsen saatejuhi Robini teha ja ta ära viia.
Dr Robin Bloor: Okei. Noh, tänan teid selle eest, Eric. Ma pean modelleerimise kohta ütlema, et ma arvan, et olin tegelikult IT-maailmas juba enne selle olemasolu, selles mõttes, et mäletan kindlustusseltsis, kus töötasin, et meil oli üks mees, kes tuli sisse ja andis meile kõikvõimaliku andmete modelleerimise töötoa seminar. Nii vaadati umbes 30 aastat, kas see on 30 aastat? Võib-olla isegi kauem kui see, võib-olla 35 aastat tagasi. Pikk-pikk modelleerimine on tegelikult olnud osa tööstusharust ja loomulikult pole sellel midagi pistmist daamidega jalutuskäikudel.
Asi, mida ma tahtsin öelda, kuna see, mida me tavaliselt teeme, on see, et mina ja Dez räägime erinevatest asjadest ja ma lihtsalt arvasin, et annan modelleerimisele üldise ülevaate, kuid sellel on reaalsus, see on nüüd ilmsiks tulnud.
Tead, suurandmete reaalsus, meil on rohkem andmeid, rohkem andmeallikaid, oleme saanud andmevooge, mis on võrrandisse sisenenud viimase kolme või nelja aasta jooksul ja hakkavad sellest suuremat osa saama ning seal on suurem vajadus andmetest aru saada ja muutuste kiirus on suurenenud, kuna lisandub rohkem andmeid ja kasutatakse ka rohkem andmestruktuure.
See on keeruline maailm. Siin on pilt sellest, mis on tegelikult midagi, mida me umbes kolm aastat tagasi joonistasime, kuid põhimõtteliselt, kui lisate voogesituse segu ja saate selle idee rafineerimistehastest, andmekeskusest, andmelingist või muust, näete, et seal on andmeid tõeliselt puhates, selles mõttes, et see ei liigu eriti palju. Ja siis on andmetel, voogudel ja teil kogu tehingurakendus, millele lisanduvad tänapäeval sündmused, sündmuste andmevood, mis juhtuvad rakendustes ja mida võib vaja minna, ning tänapäeval koos lambdaarhitektuuridega, millest iial räägitakse, tõeliselt mõjutavad lihtsalt kogu andmeväli.
Ja tänapäeval mõelge andmekihi olemasolu üle. Andmekiht eksisteerib omamoodi virtuaalsel viisil, selles mõttes, et hea tükk sellest võiks olla pilves ja seda saaks levitada andmekeskuste vahel, see võib eksisteerida tööjaamades. Andmekiht on mingil määral kõikjal ja selles mõttes on kõikjal protsessid, mis üritavad ühel või teisel viisil andmeid töödelda ja andmeid teisaldada. Kuid ka teadmine, mis see on, kui seda liigutate, on suur asi.
Kui vaatame andmete modelleerimist kõige üldisemas tähenduses, siis on teil sedalaadi pinu lõpus failid ja andmebaasid. Teil on andmeelemente, millel on võtmed, elementide määratlused, varjunimed, sünonüümid, konkreetsed füüsilised vormingud ja siis on meil see metaandmete kiht.
Metaandmete juures on huvitav see, et metaandmed on täielikult see, kuidas andmed oma tähenduse saavad. Kui teil ei ole metaandmeid, siis võite parimal juhul andmete tähenduse ära arvata, kuid teil on kohutavalt palju raskusi. Metaandmed peavad olema olemas, kuid tähendusel on struktuur. Ma ei taha süveneda tähendusfilosoofiasse, kuid isegi selles, kuidas me käsitleme andmeid, on inimmõttes ja inimkeeles palju keerukust, mis ei väljenda end andmetes hõlpsalt. Kuid isegi nende andmete osas, mida me maailmas tegelikult töötleme, on metaandmetel tähendus ja metaandmete struktuur - üks andmestik teise suhtes ja mida see tähendab, kui nad kokku pannakse ja mida see tähendab siis, kui nad on teistega ühendatud andmeid, nõuab, et me seda modelleeriksime. See pole piisavalt hea, et lihtsalt asjadele metaandmesilte registreerida, peate tegelikult salvestama tähenduse struktuuride kaupa ja struktuuride omavahelisi suhteid.
Siis on ülemisel kihil ettevõtte määratlused, mis on tavaliselt kiht, mis üritab tähendusi metaandmete vahel üle kanda, mis on andmete määratluse vorm, mis sobib andmete arvutis korraldamise ja inimliku tähendusega. Nii et teil on selles kihis olemas äriterminid, definitsioonid, suhted, olemitaseme mõisted. Ja kui nende kihtide vahel tekiks ebakõla, siis peab meil olema andmete modelleerimine. See pole tegelikult valikuline. Mida rohkem saate seda automatiseerida, seda parem. Kuid kuna see on seotud tähendusega, on seda vaheldumisi tõesti keeruline. See on piisavalt lihtne, et dokumendis sisalduvaid metaandmeid tabada ja mitmest tähendusest saada, kuid see ei ütle teile dokumentide ülesehitust ega seda, mida kirjed tähendavad või puudutavad.
Niisiis, minu arvates on andmete modelleerimine see. Juhib tähelepanu: mida keerukamaks andmete universum muutub, seda rohkem on vaja seda modelleerida. Teisisõnu, see sarnaneb sellega, et ei lisata maailmale mitte ainult rohkem asju, mis vastaks andmerekorditele, vaid lisaksid maailmale veelgi rohkem tähendust, jäädvustades andmeid üha rohkemate asjade kohta. Selle tunnetamine on üha keerukam ja seda peame mõistma.
Teoreetiliselt on tegemist andmete universumiga ja me vajame sellest vaadet. Tegelikkuses on tegelikud metaandmed osa andmestikust. Niisiis, see pole lihtne olukord. Alustav modelleerimine on ülalt alla ja alt üles. Te peate ehitama mõlemas suunas ja selle põhjus on see, et andmetel on arvuti ja protsessi jaoks tähendus, mis peavad neid töötlema, kuid sellel on omaette tähendus. Niisiis, vajate alt-üles tähendust, mis rahuldab andmetele juurdepääsu vajavat tarkvara, ja vajate ülalt alla tähendust, et inimesed saaksid sellest aru. Metaandmemudelite loomine ei ole ega saa kunagi olla projekt; see on pidev tegevus - peaks olema pidev tegevus igas keskkonnas, kus nad on olemas. Õnneks on palju keskkondi, kus see tegelikult nii pole ja asjad lähevad vastavalt kontrolli alt välja.
Edasi minnes suureneb modelleerimise tähtsus tehnoloogia edasiliikumisel. See on minu arvamus. Kuid kui vaadata asjade Interneti, saame mobiiltelefonidest rohkem aru kui vanasti, ehkki selle turule toodi uued dimensioonid: asukoha mõõde mobiiliga. Kui olete IoT-sse jõudnud, vaatasite erakorralisi andmeprobleeme, mida me kunagi varem tegema ei pidanud ja peame ühel või teisel viisil õigesti aru saama, mida me täpselt saime, kuidas seda kokku koondada, mida teha saame. seoses tähenduse saamisega liitmisest ja muidugi sellest, mida me sellega teha saame, kui seda töötleme.
Ma arvan, et see on mulle piisavalt öelnud. Ma annan edasi Dez Blanchfieldile, öelge midagi muud.
Dez Blanchfield: Aitäh. Järgida on alati raske tegu, kuid see on teema, milles me leppisime kokku ja rääkisime sellest lühidalt eelnäituse peos ning kui varakult valisite, siis saite tõenäoliselt terve hulga suurepäraseid kalliskive. Üks kaasavõtmistest ja ma ei taha selle konkreetse äikest varastada, kuid üks meie näitusetrüki tagaajajatest, mida ma tahan jagada, juhul kui te seda ei püüdnud, oli andmete rändamise teema ümber , ja see tabas mind, et kirjutasin selle tegelikult üles teekonnale mõeldes, kui palju andmeid kulub erineval põlvkonna eluperioodil - aasta, kuud, nädal, päev, tund, minut, sekund - ja andmete ümber olevad koonused asuvad selles con . Ükskõik, kas ma olen arendaja käivitav kood või olen andmespetsialist ja mõtlen iga elemendi ülesehituse ja vormingu ning metaandmete ümber või kuidas süsteemid ja ettevõte sellega suhestuvad.
See on huvitav väike kaasavõtt, mida tuleb vaid märkida, kuid igatahes lubage mul sukelduda. Eelkõige on andmekujundus fraas, mida räägin kõigi asjade andmete kohta ja konkreetselt kas rakenduste või andmebaasi infrastruktuuri arendamiseks. Arvan, et andmete kujundamine on termin, mis lihtsalt hoiab seda kõike minu meelest väga hästi. Nendel päevadel, kui me räägime andmekujundusest, räägime kaasaegsest paindlikust andmekujundusest ja minu arvates on see nii ammu, et arendajad ja andmeeksperdid töötasid üksi; need olid omas silos ja kujundused läksid ühest silost teise. Kuid olen tänapäeval väga seisukohal, et mitte ainult see, et asi on muutunud, vaid ka see peab muutuma; see on omamoodi vajadus ja see on see rakendus - arendajad ja kõik, mis on seotud andmetega seotud arendustegevusega, disainerid, kes teevad skeemide ja väljade ning kirjete asjakohaseid kujunduselemente ning asukoha- ja andmebaasisüsteeme ja infrastruktuure, modelleerivad ja kogu halduse väljakutse selle ümber. See on nüüd võistkondlik sport ja sellest ka minu pilt inimestest, kes hüppavad lennukist välja meeskonnana ja tegutsevad meeskonnana, et mängida seda visuaalselt huvitavat pilti inimestest, kes langevad läbi taeva.
Kolmandaks, mis selle juhtumiseni juhtus? Noh, seal on 1986. aastal artikkel, mille on kirjutanud paar härrat, kelle nimega üritasin meeleheitlikult õiglust avaldada. Hirotaka Takeuchi ja Ikujiro Nonaka, ma arvan, et see hääldatakse, koostasid artikli, mille pealkiri oli "Scrumi allapoole liikumine." idee sellest ragbimängust võetava ragbimängu võitmise metoodikast, kus kõik saavad ringi ühest kohast ja kaks võistkonda lukustavad pea millekski, mida nimetatakse võsaks, et proovida saada pall kontrolli alla ja mängida seda väljal jõuda proovimisjoonele ja puudutada palliga maad ja saada punkt, mida nimetatakse trine'iks ning korrata seda protsessi ja saad meeskonna jaoks rohkem punkte.
See artikkel ilmus 1986. aastal ajakirjas Harvard Business Review ja huvitaval kombel pälvis see tegelikult palju tähelepanu. See pälvis palju tähelepanu, kuna tutvustas hämmastavaid uusi kontseptsioone ja siin on ekraanipilt selle esiosast. Niisiis võtsid nad selle kontseptsiooni mängu ragbist välja ja viisid selle äri, eriti disaini ja projektide pakkumise, eriti projektide kohaletoimetamise mängu.
See, mida scrum tegi, andis meile uue metoodika, võrreldes PRINCE2 või PMBOK-iga, mida me varem kasutasime nn jugametoodikaks nimetades, teate, tehke see ja see asi ja see asi ja järgige neid järjest ja ühendage kõik punktid ümber, mis sõltub sellest, mis teil oli, või ärge tehke teist osa enne, kui olete esimese osa teinud, sest see sõltus esimesest osast. See andis meile uue metoodika, et olla pisut liikuvam - just sealt see termin pärinebki, kuidas asju toimetame, ja eriti just rohujuuretasandi projektide väljatöötamise ja arendamise ümber.
Mõned peamistest üürnikest - just nii saan ma sellega hakkama - on võsa üürnike ümber.See tutvustas ebastabiilsuse loomise ideed, et kui mõelda kaose kartusele, eksisteerib maailm kaose olukorras, kuid planeet moodustus, mis on huvitav, nii et hoone ebastabiilsus, võime natuke põrgata ümber ja ikka paneb asjad toimima, iseorganiseeruvad projektirühmad, kattumised väga vastutustundliku arendamise, eri tüüpi õppimise ja juhtimise kaudu projekti elluviimise teekonna jooksul, õppe organisatsiooniline ülekandmine. Niisiis, kuidas võtta ettevõtte ühest osast teavet ja edastada see inimesele, kellel on idee, kuid kellel pole koodi arendamist või andmebaaside ja infrastruktuuride väljaarendamist, vaid andmeid nendele inimestele? Ja konkreetselt ajaliselt piiratud tulemused. Teisisõnu, teeme seda teatud aja jooksul, näiteks päeval nagu 24 tunni jooksul või nädal või paar nädalat ja vaatame, mida me teha saame, ning astugem siis tagasi ja vaatame järele.
Ja nii, et kui armu anda punni järele, on see projekti elluviimisel tõesti uus mäng ja selle kolm põhikomponenti, mis on mõttekas, kui me siin veidi edasi läheme - siin on toode: kõigil neil inimestel on idee ja neil on vajadus midagi korda saata ja lugu, mis neid ümbritseb. Arendajad, kes tegutsevad oma lugude agiilse mudeli abil ja igapäevaste stansside kaudu, kasutades scrum-metoodikat, et seda arutada ja mõista, mida nad peavad tegema, ning siis lihtsalt minna ja asuda ning seda teha. Siis oleme inimesed kuulnud koristusmeistritest, kes jälgivad kogu seda asja ja saavad metoodikast piisavalt hästi aru, et seda juhtida. Me kõik oleme näinud neid pilte, mis mul siin seinte ja tahvlite paremas servas post-iti märkmeid täis olid ja neid serveeriti Kanbani seintena. Kui te ei tea, kes see Kanban on, kutsun teid Google'i poole, kes oli hr Kanban ja miks see muutis viisi, kuidas me asju ühelt poolt teisele seina teisaldame sõna otseses mõttes, aga projektis.
Lühidalt teeb scrumi töövoog järgmist: ta võtab nimekirja asjadest, mida organisatsioon soovib teha, viib läbi rea asju, mida me kutsume ss, jaotatud 24-tunnisteks, kuudepikkusteks perioodideks ja me hankige see järkjärguline väljundseeria. See on oluline muudatus projektide kohaletoimetamise viisis, kuni selleni jõudmiseni, sest osa sellest voolab nagu USA armee, kellel oli suur osa PMBOK-nimelise nime väljaarendamisel, näiteks idee, et ärge viige tanki põllule kuni paned täppe asjasse, sest kui põllu tankil pole täppe, on see mõttetu. Seetõttu pannakse esimene osa kuulid paaki, teine osa pannakse paak põllule. Kahjuks aga sai arengumaailma arendajatega juhtunu kuidagi sellest vilgas metoodikast kinni ja jooksis selle välja, kui armu anda, siis a.
Alati juhtub see, kui mõtleme agiilselt, enamasti mõtleme arendajatele, mitte andmebaasidele ja midagi pistmist andmebaaside maailmaga. See oli kahetsusväärne tulemus, sest reaalsus on see, et agile ei piirdu ainult arendajatega. Tegelikult seostatakse terminit vilgas minu arvates sageli ekslikult tarkvaraarendajatega, mitte andmebaaside kujundajate ja arhitektidega. Alati seisavad samad väljakutsed, millega tarkvara ja rakenduste arendamisel silmitsi seisavad, kõik, mis on seotud projekteerimise ja arendamise ning käitamise ja hooldusega ning seega ka andmete infrastruktuuri ja eriti andmebaasidega. Selles konkreetses andmestikus osalejate hulka kuuluvad näiteks andmearhitektid, vormistajad, andmebaaside infrastruktuuride administraatorid, haldajad ja tegelikud andmebaasid ise kuni äri- ja süsteemianalüütikute ja arhitektideteni, inimesteni, kes istuvad ja mõtlevad süsteemide üle ja äri tegutsevad ning kuidas oleme saanud nende kaudu andmeid voolata.
See on teema, mida ma regulaarselt tõstatan, kuna see tekitab pidevat pettumust selles osas, et olen väga seisukohal, et andmespetsialistid peavad - ei tohiks - olema nüüd tihedalt seotud projekti elluviimise kõigi komponentidega, eriti arendamisega. Kui me seda ei tee, siis ei anna me tegelikult endast parimat võimalust hea tulemuse saavutamiseks. Peame sageli ringi pöörduma ja mõtlema nende asjade üle uuesti, sest on olemas stsenaarium, jõuame ehitatava rakenduse juurde ja avastame, et arendajad pole alati andmeeksperdid. Andmebaasidega töötamine nõuab väga spetsiaalseid oskusi, eriti andmete osas, ja loob kogemusi. Sinust ei saa üleöö lihtsalt andmebaasi guru või andmeteadmiste ekspert; see on sageli midagi sellist, mis tuleneb elukogemusest ja kindlasti koos dr Robin Blooriga ajakirjas Code Today, kes raamatut üsna rikkalikult kirjutas.
Paljudel juhtudel - ja see on kahetsusväärne, kuid see on reaalsus - on, et sellel mündil on kaks osa, see tähendab, et tarkvaraarendajatel on oma andmebaasi spetsialistide elektrikatkestus ja nad on ehitanud andmebaasi kujundamise modelleerimisel vajalikud oskused, mudeli väljatöötamine on lihtsalt gurude kavandamisel on oluline, kuidas andmed satuvad ja kuidas kulub teekonna korraldamine ning milline see peaks või ei peaks välja nägema, või kahtlemata see, mis on sisse toodud ja mõista, et see on tavaliselt omandatud tarkvaraarendajatele seatud emakeelsete oskuste kaudu. Ja mõned ühised väljakutsed, millega kokku puutume, hõlmavad näiteks põhiandmebaasi kujundamise põhilist loomist ja hooldamist ning haldamist, andmete ja andmebaasi infrastruktuuri dokumenteerimist ning nende andmevarade, skeemikujunduste taaskasutamist, skeemipõlvkonnad, skeemi haldamine ja hooldamine ning nende kasutamine, teadmiste jagamine selle kohta, miks see skeem on konkreetselt välja töötatud, ning tugevused ja nõrkused, mis aja jooksul sellega kaasnevad, põhjustavad aja jooksul andmete muutumist, andmete modelleerimist ja tüüpe mudelitest, mida rakendame süsteemidele ja nende kaudu voolavatele andmetele. Andmebaasikoodide genereerimine ja see toimub integreerimisel ning seejärel modelleeritakse nende ümber olevad andmed ja seejärel kiirem juurdepääs andmete turvalisuse kontrollimiseks, andmete terviklikkus liigutab andmeid ümber, säilitades selle terviklikkuse, kas metaandmete ümber on piisavalt kas müüjad peaksid nägema kõiki tabelis olevaid kirjeid või peaksid nad nägema ainult aadressi, eesnime ja perekonnanime, mille postituses olete? Ja muidugi on kõigi suurim väljakutse andmebaasiplatvormide modelleerimine, mis on juba iseenesest erinev vestlus.
Olen väga seisukohal, et seda kõike silmas pidades on selle nirvaana võimalikuks tegemine äärmiselt oluline, et nii andmespetsialistidel kui ka arendajatel oleksid sobivad tööriistad ja et need tööriistad oleksid suutelised meeskonnakeskse projekti elluviimiseks, projekteerimine, arendamine ja käimasolev hooldus. Teate, näiteks projektide koostöö andmeekspertide ja tarkvaraarendajate vahel, tõe ühtne punkt või üks tõdeallikas andmebaaside endi dokumentide, andmete, skeemide, kust kirjed pärinevad, ja nende dokumentide omanike jaoks . Ma arvan, et praegusel ajal on see absoluutselt kriitiline, et me saaksime selle andmete nirvaana kuningaks, et õiged tööriistad peavad olema paigas, sest väljakutse on praegu liiga suur, et seda käsitsi teha ja kui inimesed Ühest organisatsioonist sisse ja välja kolimisel on meil liiga lihtne mitte järgida sama protsessi või metoodikat, mille üks inimene võiks sisse seada, mis on hea, ega pea tingimata neid oskusi ja võimeid edasi arendama.
Seda silmas pidades kavatsen pöörduda IDERA poole meie hea sõbra juurde ja kuulda sellest tööriistast ja kuidas see just nendele asjadele reageerib.
Ron Huizenga: Tänan teid väga ja tänu nii Robinile kui ka Dezile, et nad tõesti lava hästi sättisid ja näete paaris asjas, millest ma olen rääkinud, natuke kattumist. Kuid nad on tõesti loonud väga kindla aluse mõistele, millest ma räägin andmete modelleerimise vaatenurgast. Ja paljud neist, mida nad ütlesid, kajastavad minu enda kogemusi, kui olin konsultandina, kes töötas koos meeskondadega andmete modelleerimise ja andmearhitektuuri alal - mõlemad juga algusaegadel ja kujunenud kaasaegsemateks toodeteks projektidega, kus me kasutasime nutikat metoodikad lahenduste pakkumiseks.
Niisiis põhineb see, millest ma täna räägin, need kogemused, samuti ülevaade tööriistadest ja tööriistade mõned võimalused, mida me sellel teekonnal kasutame. Mida ma lühidalt käsitlen, on see, et ma ei kavatse üksikasjalikult uurida; meil oli lihtsalt väga hea ülevaade sellest, mis see on. Ma räägin sellest selles osas, mis on andmemudel ja mida see meie jaoks tegelikult tähendab? Ja kuidas me võimaldame oma organisatsioonide agiilse andmeside modelleerija kontseptsiooni, kuidas kaasata andmeside modelleerijaid, milline on modelleerijate ja arhitektide osalus projektide ajal, milliseid tegevusi nad peaksid tegema? ja selle taustal, millised on mõned olulised modelleerimisriista võimalused, mida me selle töö lihtsustamiseks tegelikult kasutame? Siis hakkan natuke kokku võtma ja lihtsalt natuke rääkima andmemudeldi kaasamisega kaasnevatest äriväärtustest ja eelistest või sellest, kuidas ma tegelikult loo räägin, probleemid, kuna andmesidemudelit ei ole projektides täielikult kaasatud ja ma näitan teile seda kogemuste põhjal ning eelneva ja järgneva pildi eelnevat ja järelpilti puudutavat pilti tegelikust projektist, millega olin mitu aastat tagasi seotud olnud. Ja siis võtame kokku veel mõned punktid ja meil on lisaks sellele veel küsimusi ja vastuseid.
Lühidalt öeldes on ER Studio väga võimas komplekt, millel on palju erinevaid komponente. Andmearhitekt, kus andmete modelleerijad ja arhitektid veedavad suurema osa ajast andmete modelleerimisega. Samuti on ka muid komponente, millest me täna üldse ei räägi, näiteks äriarhitekt, kus teostame protsesside modelleerimist ja tarkvaraarhitekt mõne UML-i modelleerimise jaoks. Siis on hoidla, kus me registreerume sisse ja jagame mudeleid ning võimaldame meeskondadel nendega koostööd teha ja meeskonna serverisse avaldada, et mitmed projektiga seotud sidusrühmad saaksid reaalselt näha esemeid, mida me " andmete loomisest, aga ka muudest asjadest, mida me ise projekti elluviimisel teeme.
Sellele, millele ma täna keskenduma hakkan, on mõned asjad, mida me Data Architectist välja näeme ja kuna on väga oluline, et me teeksime seda koostööd hoidlatepõhiste aspektide osas. Eriti kui hakkame rääkima sellistest kontseptsioonidest nagu muudatuste juhtimine, mis on hädavajalikud mitte ainult agiilsetele arendusprojektidele, vaid ka mis tahes edaspidisele arengule.
Räägime siis korraks Agile Data Modelerist. Nagu me juba varem oleme esitluses viidanud, on hädavajalik, et meil oleks andmeside modelleerijaid ja / või arhitekte, kes oleksid täielikult kaasatud paindlikesse arendusprotsessidesse. Nüüd, mis ajalooliselt juhtus, on jah, me oleme arenguperspektiivis tõesti mõelnud agiilsest ja on paar asja, mis on edasi läinud, mis selle tinginud on. Osaliselt oli selle põhjuseks just see, kuidas areng ise arenes. Kui vilgas areng algas ja me alustasime selle iseorganiseeruvate meeskondade kontseptsiooniga, kui te jõite Kool-Aidi natuke liiga puhtaks ja olite asjade äärmisel programmeerimise poolel, oli seal selliste asjade tõlgendamine väga sõnasõnaline nagu isekorraldusmeeskonnad, mida paljud inimesed tõlgendasid nii, on meil vaja vaid arendajate rühma, kes saavad luua kogu lahenduse. Kas see tähendab koodi, andmebaaside või selle taga olevate andmepoodide arendamist ja kõik anti arendajatele üle. Mis aga juhtub, kaotate inimeste erilised võimed. Olen leidnud, et tugevaimad meeskonnad on need, kes koosnevad erineva taustaga inimestest. Nagu näiteks tugevate tarkvaraarendajate, andmearhitektide, andmete modelleerijate, ärianalüütikute ja ettevõtjate sidusrühmade kombinatsioon, kes kõik teevad lõpplahenduse välja töötamiseks koostööd.
Täna räägin ka seda, et kavatsen seda teha arendusprojekti raames, kus töötame välja rakenduse, millel ilmselgelt on ka sellega seotud andmekomponent. Enne selle tegemist peame siiski astuma sammu tagasi, sest peame mõistma, et seal on väga vähe Greenfieldi arendusprojekte, kus keskendume täielikult selliste andmete loomisele ja tarbimisele, mis on piiratud ainult selle arendusprojekti enda sees . Peame astuma sammu tagasi ja vaatama organisatsiooni üldist vaatenurka andmete ja protsessi vaatenurgast. Sest me saame teada, et meie poolt kasutatav teave võib juba kuskil organisatsioonides olemas olla. Modelleerijate ja arhitektidena toome selle päevavalgele, et teaksime, kust seda teavet projektidest ise saada. Teame ka kaasatud andmestruktuure, kuna meil on kujundamismustrid, just nagu arendajatel on oma koodi kujundusmustrid. Ja peame arvestama ka selle üldise organisatsioonilise perspektiiviga. Me ei saa vaadata ainult andmeid meie loodavas rakenduses. Peame andmed modelleerima ja kindlasti dokumenteerima, kuna need elavad kaugel rakendustest endast. Need rakendused tulevad ja lähevad, kuid me peame suutma andmeid vaadata ja veenduda, et need on robustsed ja hästi üles ehitatud, mitte ainult rakenduste jaoks, vaid ka otsuste jaoks, mis kajastavad tegevusi, BI-aruandlust ja integreerimist muudesse rakendustesse, sisemistesse ja ka väljaspool meie organisatsioone. Seega peame vaatama kogu seda suurt pilti andmetest ja nende andmete elutsüklist ning mõistma teabe tükki kogu organisatsioonis hällist hauani.
Nüüd tegelike meeskondade endi juurde tagasi vaadates ja selles, kuidas me tegelikult töötama peame, arvati, et juga metoodika on tulemuste saavutamiseks liiga aeglane. Sest nagu tanki näites viidati, oli see üks samm teise järel ja toimiva lõpptulemuse saamine võttis sageli liiga kaua aega. Nüüd teeme seda, et meil peab olema iteratiivne tööstiil, kus arendame selle komponente järk-järgult ja arendame seda aja jooksul edasi, kus toodetakse kasutatavaid koode või kasutatavaid esemeid, ma ütlen, igaühe jaoks. Oluline on koostöö meeskonna tehniliste sidusrühmade ja ettevõtluse sidusrühmade vahel, kuna teeme koostööd, et juhtida need kasutajajutud rakendatavaks visiooniks koodist ja ka seda koodi toetavatest andmetest. Ja Agile Data Modeler ise leiab sageli, et meil pole organisatsioonides piisavalt modelleerijaid, nii et üks andmeside modelleerija või arhitekt võib samaaegselt toetada mitut meeskonda.
Ja selle teine külg on see, et isegi kui meil on mitu modelleerijat, peame veenduma, et meil oleks tööriistakomplekt, mida kasutame ja mis võimaldaks koostööd teha korraga mitme lenduga projektiga ning jagada neid korraga andmeartiklid ning sisse- ja väljaregistreerimisvõimalused. Ma kavatsen selle väga kiiresti üle vaadata, sest me käsitlesime seda juba eelmises jaotises. Agiilsuse tegelik eeldus on see, et hoiate asju mahajäämusest, lugudest või nõuetest. Iteratsioonide raames teeme grupina koostööd. Tavaliselt on kahenädalane või ühekuuline sõltuvalt organisatsioonist väga levinud. Ja ka igapäevaseid ülevaatusi ja standupi koosolekuid, et kaotada blokeerijad ja veenduda, et liigutame kõiki aspekte edasi, ilma et peaksime erinevates valdkondades meid peatama. Ja nendes ss tahame olla kindlad, et toome igast osast osa kasutatavaid tarneid.
Pisut teisiti võttes, laiendades seda veelgi, on scrum see metoodika, millest ma siin täpsemalt räägin, ja me lihtsalt täiendasime seda eelmist pilti veel mõne tahuga. Tavaliselt on toote mahajäämus ja siis on mahajäämus. Nii et meil on üldine mahajäämus, et iga korduse alguses võiksime öelda: „Mida me selle välja ehitame?“ Ja seda tehakse ka plaanimiskoosolekul. Seejärel lagundame ülesanded, mis on sellega seotud, ja täidame ühe- kuni neljanädalased need igapäevased ülevaated. Me jälgime oma edusamme läbipõlemis- ja läbipõlemisdiagrammide abil, et jälgida põhimõtteliselt seda, mida on alles jäänud ehitada, võrreldes sellega, mida ehitame, et luua selliseid asju nagu meie arengukiirus, kas me teeme oma ajakava, kõik need asjad. Neid kõiki töötatakse välja pidevalt, selle asemel, et mõni kuu mööda teed minna ja teada saada, et teil tuleb vähe aega ning peate projekti ajakava pikendama. Ja väga oluline, et see oleks osa kogu meeskonnast, on ülevaade nii lõpus kui ka tagasiulatuvalt, nii et enne järgmise iteratsiooni alustamist vaatate üle oma tehtud tööd ja otsite võimalusi, mida saaksite paremaks muuta järgmine kord läbi.
Väljundite osas on see põhimõtteliselt slaid, mis võtab kokku tüüpilised asjad, mis ss-s edasi lähevad. Ja see on väga arengukeskne, nii et paljud asjad, mida me siin näeme, näiteks funktsionaalsed kujundused ja kasutusjuhtumid, disainikoodide testide tegemine, kui me neid kaste siin vaatame ja ma ei kavatse neid läbi vaadata mis tahes detailsuse tasemel, nad on väga arengule orienteeritud. Ja siia alla on maetud asjaolu, et selle pingutuse toetamiseks peavad meil olema ka andmed andmete esitamiseks, mis käivad sellega käsikäes. Nii et iga kord, kui näeme selliseid asju nagu mahajäämus, nõuded ja kasutajate lood, peame käimasolevalt uurima, millised on arendustükid, mida peame tegema, millised on analüüsitükid, mida peame tegema, kuidas oleks andmekujundus või andmemudel, aga kuidas on näiteks ärisõnastikega, et saaksime ettevõtte tähenduse seostada kõigi toodetavate esemetega? Sest me peame tootma neid kasutatavaid tulemusi igas s.
Mõni inimene väidab, et peame iga s lõppu tootma kasutatava koodi. See ei pruugi nii olla, ehkki tegemist on kõige puhtamas arenguperspektiivis, kuid üsna sageli - eriti alguses - võib meil olla midagi sellist, nagu null, kus oleme keskendunud puhtalt seismisele, tehes selliseid asju nagu oma testimisstrateegiate saamine koht.Kõrgetasemeline disain selle alustamiseks enne, kui hakkame detaile täitma, ja veenduge, et enne muude vaatajaskondade kaasamist ja enne meeskonna loomist meeskonna arendamisel veenduge, et meil oleks puhas alguslugude või -nõuete komplekt. Alati on natuke ettevalmistusaega, nii et üsna sageli on meil null või isegi s null ja üks. Võib-olla peaksin olema natuke käivitusfaas, enne kui lahenduse kättetoimetamisel täie hooga jõuame.
Räägime selles mudelis andmemudelitest väga lühidalt. Kui inimesed mõtlevad andmemudelitele, mõtlevad nad andmemudelile sageli kui pilti sellest, kuidas erinevad infotükid omavahel seovad - see on vaid jäämäe tipp. Andmete modelleerimise vaimu täielikuks kehastamiseks - olgu see siis arenevas arenduses ja muudes asjades - peate mõistma, et kui õigesti tehtud andmemudel saab teie täielikuks spetsifikatsiooniks selle kohta, mida need andmed organisatsioonis tähendavad ja kuidas seda tagavara andmebaasides kasutatakse. Andmebaaside ütlemisel ei pea ma silmas mitte ainult relatsioonilisi andmebaase, mida me võib-olla kasutame, vaid ka tänapäeva arhitektuurides, kus meil on suurandmeid või NoSQL-i platvorme, nagu ma eelistaksin neid nimetada. Ka need suured andmesalved, kuna võib-olla ühendame palju erinevaid andmesalvesid nii teabe tarbimise kui ka oma lahendustesse viimise osas ning selle kohta, kuidas me seda teavet säilitame või salvestame ka oma lahendustest.
Võib-olla töötame antud rakenduse raames samaaegselt mitme andmebaasi või andmeallikaga. Mis on väga oluline, tahame, et meil oleks täielik spetsifikatsioon, seega loogiline täpsustus selle kohta, mida see tähendab organisatsiooni perspektiivina, millised on füüsikalised konstruktsioonid selles osas, kuidas me tegelikult andmeid määratleme, millised on teievahelised seosed teie andmebaasid, teie soovituslikud terviklikkuse piirangud, kontrollipiirangud - kõik need valideerimise tükid, mille kohta tavaliselt mõtlete. Kirjeldavad metaandmed on äärmiselt olulised. Kuidas teate, kuidas andmeid oma rakendustes kasutada? Kui te ei saa seda määratleda ja ei tea, mida see tähendab, või ei tea, kust see pärit on, veenduge, et tarbite nendes rakendustes õigeid andmeid - veenduge, et meil oleks korrektsed nimetamismeetodid ja täielikud määratlused, mis tähendab mitte ainult täielikku andmete sõnastikku tabelid, kuid veerud, mis neid tabeleid sisaldavad - ja üksikasjalikud juhendid selle kasutamise kohta, kuna meil on vaja see teadmistebaas üles ehitada, sest isegi siis, kui see rakendus on tehtud, kasutatakse seda teavet muude algatuste jaoks, nii et peame veenduma et meil on kõik see dokumenteeritud edaspidiseks rakendamiseks.
Jälle jõuame selliste asjadeni nagu andmetüübid, võtmed, indeksid, andmemudel ise kehastab paljusid mängureegleid. Suhted ei ole lihtsalt piirangud erinevate tabelite vahel; need aitavad meil sageli kirjeldada, millised on tõelised ärieeskirjad selle kohta, kuidas need andmed käituvad ja kuidas need ühtse üksusena toimivad. Ja muidugi on väärtuspiirangud väga olulised. Muidugi on üks asi, millega pidevalt tegeleme, ja see on üha enam levinud, sellised asjad nagu andmehaldus. Nii et andmete haldamise vaatenurgast peame ka vaatama, mida me siin määratleme? Tahame määratleda selliseid asju nagu turvaklassifikatsioonid. Millist tüüpi andmeid me käsitleme? Mida peetakse põhiandmete haldamiseks? Milliseid tehingupoode me loome? Milliseid võrdlusandmeid me nendes rakendustes kasutame? Peame tagama, et see oleks meie mudelitesse õigesti jäädvustatud. Ja ka andmete kvaliteediga seotud kaalutlused, on olemas teatud teave, mis on organisatsiooni jaoks olulisem kui teistele.
Olen osalenud projektides, kus asendasime üle tosina pärandsüsteemi uute äriprotsessidega ja kavandasime nende asendamiseks uusi rakendusi ja andmepoode. Me pidime teadma, kust teave pärineb. Mis kõige olulisema teabe jaoks, ärivaates, kui vaadata seda konkreetset andmemudeli slaidi, mis mul siin on, näete, et nende konkreetsete üksuste alumised kastid, mis on vaid väike alamhulk, Olen tegelikult suutnud ettevõtte väärtust hõivata. Kas organisatsiooni eri konstruktsioonide jaoks seda tüüpi asjade jaoks kõrge, keskmine või madal. Ja ma olen jäädvustanud ka selliseid andmeid nagu põhiandmete klassid, olgu need siis põhitabelid, kas need on võrdlusandmed, kui need olid tehingulised. Nii et me saame oma mudelites metaandmeid laiendada, et anda meile lisaks andmetele ka palju muid tunnuseid, mis tõesti aitasid meid teiste algsest projektist väljaspool olevate algatustega ja seda edasi viia. Nüüd, kui ühes slaidis oli palju, käin need ülejäänud üsna kiiresti läbi.
Ma räägin nüüd väga kiiresti sellest, mida andmemudelistaja teeb, kui me neid erinevaid sse läbi viime. Esiteks, täielik osaleja plaanimisseanssides, kus võtame kasutaja lugusid, pühendume sellele, mida me nendes kavades edastame, ja nuputame, kuidas seda struktureerida ja edastada. Andmemodelleerijana teen ka seda, et tean, et töötan erinevates arendajates või erinevate inimestega eraldi aladel. Nii et üks olulisi omadusi, mis meil võib olla, on andmemudeli koostamisel, et saaksime selle andmemudeli jagada erinevateks vaadeteks, sõltumata sellest, kas nimetate neid teemavaldkondadeks või alamudeliteks, on meie terminoloogia. Nii et mudeli ülesehitamisel näitame seda ka nendes erinevates alammudeli vaatenurkades, nii et erinevad vaatajaskonnad näevad ainult seda, mis on nende jaoks oluline, et nad saaksid keskenduda sellele, mida nad arendavad ja esitavad. Nii et võib-olla on mul keegi, kes töötab rakenduse sõiduplaani koostamise kallal, võib-olla keegi teine, kes töötab tellimuse sisestamise kallal, kus me teeme kõiki neid asju ühe toiminguga, kuid ma võin anda neile vaateid nende alammudelite kaudu, mis ainult kohaldatakse piirkonnas, kus nad töötavad. Ja siis need rullivad üldmudeli ja alammudelite kogu struktuuri juurde, et anda publikule erinevad vaated, mida nad peavad nägema.
Põhimõtted andmete modelleerimise vaatenurgast, mida me tahame omada, on alati varustatud lähteolukorraga, mille juurde me tagasi jõuame, sest üks neist asjadest, mida me peame suutma teha, on see, olgu see siis alguses või lõpus mitu ss, tahame teada, kust me algust tegime, ja meil on alati olemas lähtepunkt, et teada, mis oli delta või mille erinevus sellest, mida me antud s-s tekitasime. Peame tagama ka kiire pöörde. Kui satud sellesse andmete modelleerijana, kuid tavapärases väravavahi rollis öeldes „Ei, ei, sa ei saa seda teha, kõigepealt peame kogu selle asja ära tegema,” arvatakse teid meeskonnast välja, kui te seda tõesti vajate olla aktiivne osaleja kõigis neis agiilsetes arendusmeeskondades. See tähendab, et mõned asjad kukuvad vagunilt etteantud s-i tehes ära ja te korjate need hilisemate ss-dena üles.
Näitena võite keskenduda andmestruktuuridele lihtsalt selleks, et arendused saaksid just seda öelda - tellimuse sisestustükk, millest ma rääkisin. Hiljem võite tulla tagasi ja täita andmeid, nagu näiteks osa teie loodud artefakte, näiteks mõned andmestiku sõnastiku dokumendid. Sa ei täida seda määratlust ühe korraga; kavatsete oma väljundite osas järk-järgult edasi liikuda, kuna on kordi, kui saate selle teabe ärianalüütikutega täita, kui arendajad tegelevad rakenduste loomisega ja nende andmehoidlate püsivusega. Tahad hõlbustada ja mitte olla kitsaskoht. Arendajatega töötamiseks on erinevaid viise. Mõne asja jaoks on meil kujundamismustrid, nii et oleme täieõiguslikud osalejad, seega võib meil olla kujundusmuster, kus öeldakse, et paneme selle mudelisse, lükkame selle välja arendajate liivakasti andmebaasidesse ja siis saavad nad hakake sellega tegelema ja taotlege selles muudatusi.
Võib olla ka muid valdkondi, kus arendajad on töötanud, nad on saanud midagi, mille kallal nad töötavad, ja nad prototüübivad mõnda asja, nii et proovivad mõnda asja omaenda arenduskeskkonnas proovida. Võtame selle andmebaasi, millega nad on töötanud, lisame selle meie modelleerimisvahendisse, võrdleme olemasolevate mudelitega ning lahendame ja lükkame siis muudatused tagasi nendesse, et nad saaksid oma koode taaskoostada, et nad järgiksid õigeid andmestruktuure mida me vajame. Kuna nad võivad olla loonud mõned asjad, mis meil mujal juba olemas olid, hoolitseme selle eest, et nad töötaksid õigete andmeallikatega. Me lihtsalt kordame seda kogu toiminguga kuni oma failideni, nii et saaksime täielikud andmete esitamised, täieliku dokumentatsiooni ja kõigi nende andmestruktuuride määratluse, mida me toodeme.
Kõige edukamad agiilsed projektid, millega ma väga heade tarnete osas olen seotud olnud, on meil filosoofia, mis modelleerib kõiki muudatusi täieliku füüsilise andmebaasi spetsifikatsioonis. Põhimõtteliselt saavad andmemudelid kasutusele võetud andmebaasideks, millega töötate kõige uue loomisel, mille loome, ja sellel on täielikud viited muudele andmehoidlatele, kui me tarbime muudest välistest andmebaasidest. Selle osana toome juurde juurdekasvavaid skripte versus iga kord täispõlve tegemise. Ja me kasutame oma disainilahendusi, et anda meile kiire areng seoses erinevate arendusmeeskondadega, kellega me töötame, ss.
Ka s tegevuses on jällegi võrdluse / ühendamise lähtealus, nii et mõelgem iga muudatuse modelleerimise idee. Iga kord, kui muudatusi teeme, tahame muutust modelleerida ja mis on väga oluline - andmestiku modelleerimisest kuni viimase ajani puudu on tegelikult olnud võimalus modelleerimisega seostada ülesandeid ja teie tulemusi koos kasutaja lugude ja ülesannetega, mis neid muudatusi tegelikult põhjustavad. Tahame, et saaksime kontrollida oma mudelimuudatusi, samal viisil kui arendajad kontrollivad oma koode, viidates nendele kasutajalugudele, mis meil on, et me teaksime, miks me kõigepealt muudatusi tegime, see on midagi, mida teeme. Kui me seda teeme, genereerime oma täiendavad DDL-skriptid ja postitame need nii, et neid oleks võimalik koos teiste arenduse väljunditega kätte saada ja meie ehituse lahendusesse kontrollida. Jällegi võib meil olla üks mudel või töötada mitme meeskonnaga. Ja nagu ma olen juba rääkinud, pärinevad mõned asjad andmemudeldist, teised asjad on arendajate algatatud ja me kohtume keskel, et tulla välja üldise parima kujundusega, edasi lükata ja veenduda, et see on meie õigesti kujundatud üldised andmestruktuurid. Peame säilitama distsipliini tagada, et edasisuunas oma andmemudelis oleksid kõik õiged konstruktsioonid, sealhulgas sellised asjad nagu nullväärtused ja mitte nullväärtused, referentsipiirangud, põhimõtteliselt kontrollipiirangud - kõik need asjad, mille kohta tavaliselt mõtleme .
Räägime nüüd vaid paarist ekraanipildist tööriistadest, mis aitavad meil seda teha. Minu arvates on oluline, et sellel ühisel repositooriumil oleks, ja see, mida me andmete modelleerijatena saame teha - ja see on osa taustal olevast andmemudelist - on siis, kui töötame asjadega, mille tahame veenduda, et suudame töötada ainult nende objektidega, mida peame saama muuta, teha muudatusi, genereerida meie DDL-skriptid muudatuste jaoks, mida oleme teinud, kui kontrollime asju uuesti sisse. Niisiis, mida me teha saame, on ER Stuudios näide, saame vaadata objekte või objektide rühmi, mille kallal töötada, me ei pea kontrollima tervet mudelit või alammudelit, me võime kontrollida vaid neid asju, mis meid huvitavad. Mida me pärast seda tahame, on kas väljaregistreerimine või registreerimine - teeme seda mõlemal viisil, kuna erinevad arendusmeeskonnad töötavad erinevalt. Tahame veenduda, et seostame selle kasutajaloo või -ülesandega, mis juhib sellekohaseid nõudeid, ning see on sama kasutajalugu või -ülesanne, mida arendajad arendavad ja oma koodi kontrollivad.
Nii et siin on väga kiire katkend ühe meie muudatuste juhtimiskeskuse paarist ekraanist. Mida see teeb, ei hakka ma siin üksikasjalikult läbi käima, kuid see, mida näete, on kasutaja lugu või ülesanne ja igaüks neist, millele te tegelikke muudatuste kirjeid näete, on taandatud - oleme loonud automatiseeritud muudatuste kirje, kui me teeme sisse- ja väljaregistreerimise ning saame ka selle muudatuste kirje kohta rohkem kirjeldust. See on ülesandega seotud, meil võib iga ülesande kohta olla mitu muudatust, nagu võiksite oodata. Ja kui me muutuste registrisse läheme, saame seda vaadata ja mis veelgi tähtsam - näha, mida me tegelikult muutisime? Selle konkreetse, seal esile tõstetud loo jaoks oli mul üks tüüpi muudatused, mis tehti ja kui vaatasin tegelikku muudatuste salvestust ennast, siis see on tuvastanud mudeli üksikud tükid, mis on muutunud. Muutsin siin paar atribuuti, tuletasin need uuesti ja see tõi sõiduks kaasa muutmiseks vajalikud vaated, mis sõltusid ka neist, et need genereeritaks järkjärgulises DLL-is. See ei ole mitte ainult alusobjektide modelleerimine, vaid ka selline suure jõudlusega modelleerimisriist tuvastab muudatused, mis tuleb läbi viia andmebaasis olevate objektide või ka andmemudeli sõltuvate objektide kaudu.
Kui teeme koostööd arendajatega ja teeme seda paaris erinevas asjas, siis tehakse midagi nende liivakastis ja tahame võrrelda ja näha, kus erinevused on, kasutame võrdlus- / liitmisvõimalusi paremal ja vasakul külg. Me võime öelda: „Siin on vasakul küljel meie mudel, siin paremal on nende andmebaas, näidake mulle erinevusi.“ Seejärel saame valida, kuidas me need erinevused lahendame, kas sisestame asjad andmebaasi või kui nende andmebaasis on mõned asjad, mille toome mudelisse tagasi. Saame minna kahesuunaliseks, nii et saame minna nii suunda kui ka värskendada samaaegselt nii lähte- kui ka sihtpunkti ning seejärel toota juurdelisatud DDL-skriptid, et need muudatused andmebaasi keskkonda ise juurutada, mis on äärmiselt oluline. Mida me ka teha saame, on see, et võime seda võrdlus- ja liitmisvõimalust ka igal ajal kasutada. Kui teeme läbilõike pilte, saame alati võrrelda ühe algusest teise algust või lõppu, et näha teatavas arengus või mitme rea jooksul tehtud toimingute täielik inkrementaalne muutmine.
See on väga kiire näide muudetud skriptist, igaüks teist, kes on andmebaasidega töötanud, on seda tüüpi asju näinud, see on see, mille saame välja lülitada koodist alternatiivse skriptina, nii et tagame, et säilita asju siin. Selle, mille ma siit välja tõmbasin, lihtsalt segaduse vähendamiseks, teeme ka nende muudetud skriptidega, kui eeldame, et ka nendes tabelites on andmeid, nii et genereerime ka DML-i, mis tõmbab ajutiste tabelite ja lükake see tagasi ka uutesse andmestruktuuridesse, nii et vaatleme mitte ainult struktuure, vaid ka andmeid, mis meil juba võisid nendes struktuurides sisalduda.
Räägime väga kiiresti automatiseeritud ehitamissüsteemidest, sest kui me tegeleme üsna sageli paindliku projektiga, töötame koos automatiseeritud ehitamissüsteemidega, kus peame kontrollima erinevaid tulemusi, et veenduda, et me ei rikuks oma ehitust. Mida see tähendab, et sünkroonime väljundid, tuleb sisse logida need muutusskriptid, millest ma rääkisin DDL-i skriptiga, samal ajal tuleb sisse logida ka vastav rakenduskood ja palju arendajaid muidugi praegu ei arenda seda tehakse otsese SQL-iga andmebaaside ja seda tüüpi asjade vastu. Üsna sageli kasutame püsivuse raamistikke või ehitame andmesideteenuseid. Peame tagama, et nende raamistike või teenuste muudatused registreeritakse täpselt samal ajal. Need lähevad mõnes organisatsioonis automatiseeritud ehitamissüsteemi ja kui ehitamine puruneb, rakendatakse paindliku metoodika korral kõik teki kinnitamine enne edasiliikumist, et me teaksime, et enne kaugemale minekut on meil toimiv lahendus. Ja ühe projektiga, millega ma seotud olin, viisime selle äärmusesse - kui ehituse purunemine, mille olime tegelikult kinnitanud paljudele meie piirkonnas asuvatele arvutitele, kus olime koos ärikasutajatega, olid meil punased vilkurid, siis nagu politseiautode ülaosa. Ja kui ehitamine purunes, hakkasid need punased vilkuvad tuled kuskima ja me teadsime, et see on kõik tekil: kinnitage ehitis ja jätkake sellega, mida tegime.
Ma tahan rääkida muudest asjadest ja see on ER Stuudio ainulaadne võimekus. See aitab tõesti, kui proovime neid püsivuse piiride arendajatena artefakte üles ehitada, meil on kontseptsioon nimega äriandmeobjektid ja mis võimaldab meil seda kui vaatate näitena seda väga lihtsustatud andmemudelit, võimaldab see meil kapseldada üksused või üksuste rühmad sinna, kus püsivuse piirid asuvad. Kui me andmete modelleerijana võiksime mõelda ostutellimuse päise ja tellimuste joondamise ning muude üksikasjalike tabelite seosele, mis on selle kujundamise viisil seotud, ja meie andmesideteenuste arendajad peavad teadma, kuidas asjad nende erinevate andmetega püsivad struktuurid. Meie arendajad mõtlevad sellistele asjadele nagu ostutellimus kui objekt üldiselt ja milline on nende leping nende konkreetsete objektide loomise lepinguga. Saame selle tehnilise detaili paljastada, nii et andmeservereid ehitavad inimesed saaksid näha, mis selle all on, ja saaksime kaitsta teisi auditooriume keerukuse eest, et nad näeksid lihtsalt erinevaid kõrgema taseme objekte, mis sobib ka väga hästi äriga suhtlemiseks. kui räägime ka erinevate ärikontseptsioonide koostoimimisest, siis analüütikud ja ettevõtluse sidusrühmad.
Tore on ka see, et laiendame ja ahendame neid konstruktiivselt, et saaksime säilitada seoseid kõrgema järgu objektide vahel, isegi kui need pärinevad konstruktsioonidest, mis sisalduvad nendes äriandmeobjektides endas. Nüüd modelleerijana jõuage s-i lõppu, s-mähkimise lõpus on mul palju asju, mida ma pean tegema, mida ma kutsun järgmisteks s-ideks oma majapidamisse. Iga kord, kui ma loon seda, mida ma nimetan nimega väljalaseks, annab see mulle lähtekoha selle jaoks, mis mul nüüd väljalaske lõpus on. See tähendab, et edasi läheb minu lähteseis, kõiki neid lähtejooni või nimega väljaandeid, mida loon ja oma hoidlasse salvestan, saan kasutada võrdlemiseks / liitmiseks, et saaksin alati võrrelda mis tahes teise lõppu mis tahes ülejäänud otsast, mis on väga oluline teada, millised olid teie andmemudeli muudatused selle teekonna vältel.
Samuti loon delta DDL-skripti, kasutades uuesti võrdlemist / ühendamist s algusest lõpuni. Võib-olla olen kontrollinud terve hulga järkjärgulisi skripte, kuid kui mul seda vaja on, on mul nüüd skript, mille saan kasutada teiste liivakastide püstitamiseks, nii et võin lihtsalt öelda, et see oli meil selle ühe alguses, lükake looge see läbi, ehitage andmebaas liivakastina, et alustada järgmiste teemadega ja me saame neid asju kasutada ka näiteks standup QA eksemplaride tegemiseks ja lõpuks tahame muidugi oma muudatused tootmisele suunata, nii et meil on mitu asja käimas samal ajal. Jällegi osaleme täielikult planeerimises ja tagasiulatuvates osades, tagasiulatuvad vaated on tegelikult õpitud õppetunnid ja see on äärmiselt oluline, kuna kiirel ajal saate väga kiiresti minema, peate peatuma ja tähistama õnnestumisi, nagu praegu. Mõelge välja, mis on valesti, tehke järgmine kord paremaks, aga tähistage ka asju, mis läksid õigesti, ja ehitage neile üles, kui jätkate järgmise ss edasi liikudes.
Ma räägin nüüd väga kiiresti ettevõtte väärtusest. Oli üks projekt, millesse ma aastaid tagasi haarasin ja mis sai alguse agara projektina, ja see oli äärmuslik projekt, seega oli tegemist puhta iseorganiseeruva meeskonnaga, kus kõike tegid vaid arendajad. Lühidalt öeldes - see projekt takerdus ja nad leidsid, et kulutasid üha enam tuvastatud puuduste kõrvaldamisele ja parandamisele, kui rohkem funktsionaalsuse edendamisele ja tegelikult siis, kui nad seda vaatasid põlemiskaartidel pidid nad projekti kuue kuu võrra tohutute kuludega pikendama. Ja kui me seda vaatasime, oli probleemi leevendamise viis korrektse andmete modelleerimise tööriista kasutamine koos asjatundliku andmeside modelleerijaga, kes on projekti endaga seotud.
Kui vaatate selle konkreetse diagrammi vertikaalset riba, näitab see kumulatiivseid defekte versus kumulatiivseid objekte ja ma räägin andmeobjektidest või konstruktsioonidest, mis loodi, näiteks piirangutega tabeleid ja seda tüüpi asju, kui vaatasite enne andmete modelleerija kasutuselevõttu oli defektide arv tegelikult ületanud ja hakanud tekkima tühimik tegeliku objektide arvu suhtes, mida selle ajani toodeti. Pärast 21. nädalat, st siis, kui andmete modelleerija tuli, tegi uue mudeli andmemudeli jaoks, tuginedes sellele, mis pidi paranema, ja asus siis modelleerima projektirühma osana edasi liikudes, muutused selle projekti edasiliikumisel . Ja te nägite väga kiiret pööret, et umbes pooleteise jooksul nägime genereeritavate ja konstrueeritavate objektide ja andmekonstruktsioonide arvu tohutut tõusu, kuna tootsime välja pigem andmete modelleerimise tööriista, mitte arendaja kepihoone. neid keskkonnas ja nad olid korrektsed, kuna neil oli õige referentsterviklus ja muud konstruktsioonid, mida see pidi omama. Defektide tase nende peaaegu lamedate suhtes. Võttes selle asjakohase meetme ja veendudes andmete modelleerimise täielikus kaasamises, viidi projekt õigel ajal kohale palju kõrgema kvaliteediga ja tegelikult poleks see üldse ellu viidud, kui neid samme poleks toimunud. Seal on palju vilgasid ebaõnnestumisi, on ka palju vilgasid õnnestumisi, kui saaksite õiged inimesed õigetesse rollidesse. Olen kiiv kui operatiivse distsipliini pooldaja, kuid te peate veenduma, et kõigil projektirühmades kaasatud õigetel rühmadel on oskused, kui liigute edasi agara tüüpi ettevõtmistega.
Kokkuvõtteks tuleb öelda, et andmearhitektid ja modelleerijad peavad olema kaasatud kõigisse arendusprojektidesse; need on tõesti liim, mis hoiab kõike koos, sest andmete modelleerijate ja arhitektidena mõistame mitte ainult antud arendusprojekti andmekonstruktsioone, vaid ka seda, kus andmed organisatsioonis olemas on ja kust me neid andmeid hankida saame ning kuidas ka hakatakse kasutama ja kasutama väljaspool konkreetset rakendust, mille kallal me töötame. Mõistame keerulisi andmesuhteid ja on ülioluline, et saaksime edasi liikuda ja ka valitsemise vaatenurgast dokumente kaardistada ja mõista, kuidas teie täielik andmemaastik välja näeb.
See on nagu tootmine; Tulin tootmistaustalt. Lõpuks ei saa kvaliteeti millegi suhtes kontrollida - peate oma disaini kvaliteedi integreerima nii alguses kui ka teel ning andmete modelleerimine on viis selle kvaliteedi integreerimiseks disainilahendusele tõhusal ja kuluefektiivsel viisil lõpuni. . Ja jälle, midagi, mida tuleb meeles pidada - ja see ei tohi olla ebalev, vaid see on tõde - rakendused tulevad ja lähevad, andmed on ettevõtte jaoks oluline väärtus ja see ületab kõik need rakenduse piirid. Iga kord, kui rakendust sisestate, palutakse teil tõenäoliselt säilitada andmed muude rakenduste kohta, mis varem tulid, seega peame lihtsalt meeles pidama, et see on oluline ettevõtte vara, mida me aja jooksul säilitame.
Ja see ongi kõik! Siit võtame veel küsimusi.
Eric Kavanagh: Hea küll, las ma viskan selle kõigepealt Robinile. Ja siis, Dez, olen kindel, et teil on paar küsimust. Võtke see ära, Robin.
Dr Robin Bloor: Okei. Ausalt öeldes pole mul kunagi olnud probleeme agressiivsete arendusmeetoditega ja mulle tundub, et see, mida te siin teete, on eriti mõistlik. Ma mäletan, et vaatasin 1980ndatel midagi, mis näitas tõesti, et probleem, millega tegelikult kontrolli alt väljuva projektiga seoses kokku puutute, on tavaliselt see, kui lasete mingil konkreetsel etapil viga püsima jääda. See muutub lihtsalt keerukamaks, kui te ei saa seda etappi õigesti, nii et üks neist asjadest, mida siin teete - ja ma arvan, et see on slaid -, aga üks neist asjadest, mida siin teete n-s on minu arvates absoluutselt oluline, kuna proovite tõesti kättetoimetatavaid faile sinna kinnitada. Ja kui te ei saa kättetoimetatavaid faile, siis muutuvad need tooted kuju.
See on selline, minu arvamus. See on ka minu arvamus - mul pole tõepoolest ühtegi argumenti mõttega, et enne andmete läbimist peate saama andmemudelite õigsuse teatud detailsusastmele. Mida ma tahaksin, et prooviksite teha, kuna ma ei saanud sellest täielikult aru, on lihtsalt kirjeldada ühte neist projektidest selle suuruse ja voolavuse ning selle järgi, kes, teate, kus probleemid kerkisid üles, kas need lahendati? Kuna minu arvates on see slaid üsnagi selle süda ja kui te võiksite seda natuke lähemalt kirjeldada, oleksin väga tänulik.
Ron Huizenga: Muidugi, ja ma kasutan paari näidisprojekti. See, mis läks omamoodi rööpast välja, viidi tagasi selleks, et tegelikult kaasati õiged inimesed ja tehti andmete modelleerimine. Kõik oli tõesti viis veenduda, et kujundust mõistetakse paremini ja meil on ilmselgelt parem rakenduskujundus seda modelleerides. Kuna teate, et teate seda, saate genereerida oma DDL-i ja kõik tagantpoolt ja tööriistast välja, selle asemel et jääda kleepima, nagu tavaliselt inimesed tavaliselt teevad, minnes otse andmebaasi keskkonda. Ja tüüpilised asjad, mis arendajatega juhtuvad, on see, et nad lähevad sinna sisse ja ütlevad, et okei, mul on neid tabeleid vaja. Oletame, et teeme tellimuste sisestusi. Nii võivad nad luua tellimuse päise ja tellimuse üksikasjade tabeleid ning seda tüüpi asju. Kuid nad unustavad või jätavad üsna sageli tähelepanuta, et väliste võtmesuhete esindamiseks on olemas piirangud. Võimalik, et võtmed pole õiged. Ka nimetamistava võib kahtlustada. Ma ei tea, mitu korda olen sattunud näiteks keskkonda, kus näete hunnikut erinevaid tabeleid erinevate nimedega, kuid siis on nende tabelite veerunimed nagu ID, nimi või mis iganes, nii et nad olen tõesti kaotanud kaastöötaja ilma tabelita, mis see täpselt on.
Nii et tavaliselt andmete modelleerimise ajal veendume, et rakendame kõigi DDL-is tekkivate artefaktide puhul korralikke nimetamismeetodeid. Kuid kui rääkida projektide olemusest täpsemalt, siis üldiselt räägin ma üsna suurtest algatustest. Üks neist oli 150 miljoni dollari väärtuses ettevõtete ümberkujundamise projekt, kus asendasime üle tosina pärandsüsteemi. Meil oli korraga viis erinevat vilgas meeskonda. Mul oli täielik andmearhitektuurimeeskond, nii et minu meeskonnast olid modelleerijad kõigisse teistesse rakendusala meeskondadesse ja me töötasime koos ettevõttesiseste ettevõtlusekspertidega, kes teadsid seda teemat ja tegid kasutajate lood nõuete enda jaoks. Kõigis neis meeskondades olid ärianalüütikud, kes tegelesid äriprotsesside modelleerimisega tegevusskeemide või äriprotsessiskeemidega, aidates kasutajatega lood kasutajatele paremini selgeks teha, enne kui ka ülejäänud meeskond neid ära tarbis.
Ja siis muidugi arendajad, kes ehitasid rakenduskoodi üle selle. Ja me tegime koostööd ka, ma arvan, et ka neli erinevat süsteemiintegratsiooni müüjat ehitasid rakenduse erinevaid osi, kus üks meeskond ehitas andmesideteenuseid, teine ehitas rakenduse loogikat ühes piirkonnas, teine aga, kellel oli teadmisi teises ärivaldkonnas ehitati selles piirkonnas rakenduse loogikat. Nii et meil oli terve projekt inimesi, kes selle projekti kallal töötasid. Eelkõige selles, et meeskonnal oli kaldal 150 inimest ja meeskonnas veel 150 ressurssi, kes tegid kahenädalast koostööd selle asja ajamiseks. Ja selleks peate veenduma, et tulistate kõiki silindreid ja kõik on hästi sünkroniseeritud selle osas, mis on nende tarnitavad materjalid. Teil tuli neid sagedamini lähtestada, et veenduda, et oleme tarninud kõik vajalikud esemed. iga s lõpus.
Dr Robin Bloor: No see on muljetavaldav. Ja ainult selle kohta pisut üksikasjalikumalt - kas sa said selle projekti lõpus kokku täieliku, mida ma nimetaksin, MDM-kaardi kogu andmeala kaardilt?
Ron Huizenga: Meil oli täielik andmemudel, mis lagunes kõigi erinevate ärivaldkondade vahel. Andmesõnastik ise täielike määratluste osas jäi pisut napiks. Enamik tabeleid oli meil määratletud; meil oli enamus veerge täpselt määratletud, mida need tähendasid. Mõningaid neid polnud ja huvitaval kombel oli palju selliseid andmeid, mis pärinesid pärandsüsteemidest, kus pärast projekti ulatuse lõppu dokumenteeriti seda endiselt edasikantava kogumina. artefakte, nagu see oli, väljaspool projekti ennast, sest see oli midagi, mida edasine organisatsioon pidi ülal pidama. Nii et samal ajal võttis organisatsioon andmehalduse olulisuse suhtes palju suurenenud vaatepunkti, kuna nägime palju puudusi neis pärandsüsteemides ja pärandiandmeallikates, mida üritasime ära kasutada, kuna neid polnud dokumenteeritud. Paljudel juhtudel olid meil ainult andmebaasid, mida pidime ümber tegema ja proovima aru saada, mis seal oli ja milleks see teave oli.
Dr Robin Bloor: Mind see ei üllata, selle konkreetne aspekt. Andmehaldus on, nimetagem seda, väga tänapäevane probleem ja ma arvan, et tõesti on palju tööd, mida oleksime pidanud ajalooliselt andmehalduse alal ära tegema. Kunagi ei olnud see põhjus, et võiksite kuidagi ära saada, kui te seda ei teeks. Kuid kuna andmeressurss lihtsalt kasvas ja kasvas, siis lõpuks ei saanud te seda teha.
Igatahes lähen üle Dezile, sest arvan, et mul on olnud selleks piisavalt aega. Dez?
Dez Blanchfield: Jah aitäh. Kogu selle asja vältel jälgin ja mõtlen endamisi, et me räägime sellest, kuidas näeme agiilset, mida kasutatakse viha mitmel viisil. Kuigi sellel on negatiivsed varjundid; Ma mõtlesin seda positiivsel viisil. Kas te võiksite meile lihtsalt anda stsenaariumi, ma mõtlen, et on kaks kohta, kus ma näen, et see on täiuslik komplekt: üks on uued projektid, mida tuleb lihtsalt teha esimesest päevast alates, kuid ma arvan, et minu kogemuse tõttu on see alati muutumatu juhtum, et kui projektid saavad piisavalt suureks, et see on mitmel viisil vajalik, on kahe maailma liimimise vahel huvitav väljakutse, eks? Kas saate anda meile mingisuguse ülevaate mõnedest edulugudest, mida olete juba näinud organisatsiooni astudes, siis saab selgeks, et neil on kahe maailma kerge kokkupõrge ja olete suutnud edukalt kas see on paigas ja koondab suured projektid sinna, kuhu nad muidu oleks rööbastele jõudnud? Ma tean, et see on väga lai küsimus, aga ma lihtsalt mõtlen, kas on olemas mõni konkreetne juhtumianalüüs, kuhu saaksite suunata, osutada sinna, kus ütlesite: teate, me panime selle kõik paika ja see on kokku viidud kogu arendusmeeskonnaga koos andmemeeskond ja me oleme omamoodi lahendanud midagi, mis oleks võinud muidu paadi uppuda?
Ron Huizenga: Muidugi, ja tegelikult oli see üks projekt, mis juhtus torujuhtmeprojektina, millele viitasin, kus ma näitasin seda diagrammi koos defektidega enne ja pärast andmete modelleerija kaasamist. Üsna sageli ja on olemas eelarvamustevastaseid ideid, eriti kui asju keerutatakse seal, kus seda tehakse puhtalt arenguperspektiivist lähtuvalt, on rakenduste tarnimiseks nendesse agiilsetesse projektidesse kaasatud vaid arendajad. Mis seal muidugi juhtus, on see, kas nad tõusid rööbastelt ära ja eriti nende andmeeskirjad või nende toodetavad andmete esitamised jäid kvaliteedilt märgi alla ja tegelikkuses käsitleti üldiselt asju. Ja sageli eksisteerib selline eksiarvamus, et andmeside modelleerijad aeglustavad projekte, ja kui andmeside modelleerijal pole õiget suhtumist, siis nad seda ka teevad. Nagu ma ütlen, peate kaotama - mõnikord leidub andmeside modelleerijaid, kellel on see traditsiooniline väravavahi hoiak, kus “me oleme siin, et kontrollida, kuidas andmestruktuurid välja näevad”, ja see mentaliteet peab kaduma. Kõik, kes on kaasatud aruka arenduse arendamisse, eriti andmeside modelleerijad, peavad võtma vahendaja rolli, et aidata meeskondadel edasi liikuda. Ja parim viis selle illustreerimiseks on näidata kiiresti meeskondi, kui produktiivsed nad saavad olla, modelleerides kõigepealt muudatused. Ja jälle, sellepärast rääkisin koostööst.
Mõned asjad, mida saame kõigepealt modelleerida ja genereerida DDL-i, et arendajatele välja suruda. Samuti tahame veenduda, et nad ei tunneks, et neid piiratakse. Seega, kui on asju, mille kallal nad töötavad, laske neil töötada oma arendusliivakastides, sest just seal töötavad arendajad oma töölaudade või muude andmebaaside kallal, et teha asju muudatuste tegemiseks. Ja tehke nendega koostööd ja öelge: „Olgu, töötage sellega.” Toome selle tööriista sisse, lahendame selle ja siis lükkame selle edasi ja anname teile skriptid, mida saate selle oma värskendamiseks kasutada andmebaasides, et neid uuendada, et saada edasi tegelik tootmis sanktsioon, kui me jätkame edasiliikumist. Ja saate selle väga kiiresti ümber pöörata. Ma leidsin, et mu päevad olid täis seda, et ma lihtsalt käisin edasi ja tagasi, itereerides erinevate arendusmeeskondadega, vaadates muutusi, võrdledes, genereerides skripte, käivitades neid ja suutsin end nelja arendusmeeskonnaga üsna hõlpsalt kursis hoida, kui me seda tegime. saavutasid hoogu.
Dez Blanchfield: Üks asi, mis selle peale meelde tuleb, on see, et teate, palju vestlusi, mida ma igapäevaselt pidasin, on selle kaubarongi kohta, mis meile vastu tuleb, omamoodi masinast masinale ja IoT. Ja kui me arvame, et meie praeguse ettevõtluskeskkonna kohta on nüüd palju andmeid, siis teate, kui jätta ükssarved hetkeks kõrvale, kui me teame, et Googles ja s ning Ubersis on andmeid petabaite, kuid traditsioonilises ettevõttes räägime ikka sadadest terabaitidest ja paljudest andmetest. Kuid see kaubarong tuleb minu arvates organisatsioonide juurde ja dr Robin Bloor viitas sellele juba asjade Interneti kaudu. Teate, meil on palju veebiliiklust, sotsiaalset liiklust, liikuvust ja mobiilseadmeid, pilv on nagu plahvatanud, kuid nüüd on meil nutikas infrastruktuur, nutikad linnad ja seal on kogu see andmemaailm, mis on lihtsalt plahvatanud.
Igapäevase organisatsiooni jaoks on keskmise või suure organisatsiooni esindaja, kes istub seal ja näeb seda valumaailma, tulemas neile otsa ja ei pea vahetut plaani silmas pidama, millised on paaril lausel mõned kaasavõtmised, mille paneksite neile, millal ja kus nad peavad vestluslikult mõtlema mõne sellise metoodika paikapanemise üle. Kui varakult peavad nad hakkama planeerima, et peaaegu istuda ja tähelepanu pöörata ning öelda, et on õige aeg mõned tööriistad paigas saada, meeskond välja koolitada ja selle väljakutse ümber kõnelemiseks kõnelusi korraldada? Kui hilja on loos liiga hilja või millal on liiga vara? Kuidas see välja näeb mõne organisatsiooni jaoks, mida näete?
Ron Huizenga: Ma ütleksin enamiku organisatsioonide jaoks, et kui nad pole seda juba teinud ja kohandanud andmemudelit ja andmearhitektuuri selliste võimsate tööriistadega, on vaja seda teha eile. Sest huvitav on see, et ka tänapäeval, kui vaadata organisatsioonide andmeid, on meie organisatsioonides nii palju andmeid ja üldiselt, mõne uuringu põhjal, mida oleme näinud, kasutame efektiivselt vähem kui viis protsenti nendest andmetest kui vaatleme organisatsioone. Ja IoT või isegi NoSQL-i korral saavad suured andmed - isegi kui need pole mitte ainult IoT, vaid lihtsalt suurandmed - kus me hakkame tarbima veelgi rohkem teavet, mis pärineb väljastpoolt meie organisatsioone, see väljakutse muutub üha suuremaks kogu aeg. Ja ainus viis, kuidas meil on võimalus sellega hakkama saada, on aidata meil mõista, mida need andmed tähendavad.
Niisiis, kasutusjuhtum on natuke erinev. Me leiame end nende andmete vaatlemisel, jäädvustamisel, peame neid ümber kujundama, vaatama, mis neil on, olgu see siis meie andmejärvedes või isegi meie sisestes andmebaasides, sünteesima, mida andmed on olemas, rakendage sellele tähendusi ja määratlusi, et saaksime aru, mis andmed need on. Kuni me ei saa aru, mis see on, ei saa me tagada, et kasutame seda õigesti või piisavalt. Seega peame tõesti saama aru, mis need andmed on.Ja teise osa sellest, ärge tehke seda, kuna saate kõigi nende väliste andmete tarbimise osas veenduda, et teil on kasutusjuhtum, mis toetab nende väliste andmete tarbimist. Keskenduge vajaminevatele asjadele, selle asemel et lihtsalt proovida tõmmata ja kasutada asju, mida võite hiljem vajada. Keskenduge kõigepealt olulistele asjadele ja kui olete selle läbi töötanud, siis hakkate tarbima ja proovima mõista muud teavet väljastpoolt.
Selle suurepäraseks näiteks on see, et me räägime asjade Interneti-andurist ja anduritest, kuid sama tüüpi probleemid on paljudes organisatsioonides olnud juba aastaid, isegi enne asjade Interneti. Kõigil, kellel on tootmise juhtimissüsteem, olenemata sellest, kas nad on torujuhtmeid tootvad ettevõtted, mis tahes protsessipõhised ettevõtted, kus on asju, kus nad teevad palju kontrollimistega automatiseerimist ja kes kasutavad andmevooge ja muud sellist, on need andmed, mida nad proovivad ära joosta, et aru saada, mis on minu tootmisseadmete sündmused, mis annavad märku - mis ja millal juhtus? Ja selle tohutu andmevoo hulgas on ainult konkreetne teave või sildid, mis neid huvitavad, et neil oleks vaja sõeluda, sünteesida, modelleerida ja mõista. Ja nad saavad ülejäänud osa tähelepanuta jätta, kuni on aeg seda tõeliselt mõista, ja siis saavad nad laiendada oma ulatust, et seda üha enam ulatusse tõmmata, kui see on mõistlik.
Dez Blanchfield: Tõepoolest. On üks küsimus, mille juurde hakkan vastama, selle esitas härrasmees nimega Eric ja me oleme sellest vestelnud privaatselt. Ma lihtsalt küsisin temalt luba, mille ta on andnud, et seda sinult küsida. Sest see viib kenasti selleni, et lihtsalt kokku mässida, sest nüüd läheme natuke aega edasi ja annan Ericule tagasi. Kuid teise Ericu küsimus oli, kas on mõistlik eeldada, et alustava ettevõtte omanikud tunnevad ja mõistavad unikaalseid väljakutseid, mis on seotud terminoloogia modelleerimisega, või tuleks see tõlgendamiseks kellelegi teisele anda? Ehk teisisõnu, kas startup peaks olema suuteline ja valmis ning valmis ja suuteline sellele keskenduma ja sellele jõudma? Või on see midagi, mida nad peaksid ilmselt välja ostma ja eksperdid pardale tooma?
Ron Huizenga: Vist lühike vastus on, et see tõesti sõltub. Kui tegemist on startupiga, kus pole kedagi ettevõttesisest, kes on andmearhitekt või modelleerija ja kes andmebaasi päriselt mõistab, siis on kiireim viis alustamiseks tuua keegi konsultatsioonitaustaga, kes on selle ruumiga väga hästi kursis ja võib saada nad lähevad. Sest mis te leiate - ja tegelikult tegin seda paljudel kaasamistel, mis ma tegin enne, kui jõudsin tootehalduse hämarale küljele - kas ma läheksin organisatsioonidesse konsultandina, juhin nende andmearhitektuurimeeskondi, nii, et nad saaksid end ümber suunata ja koolitada oma inimesi, kuidas seda tüüpi asju teha, et nad saaksid seda säilitada ja missiooni edasi viia. Ja kui see on loogiline, siis jätkaksin oma järgmise töövõtuga. Seal on palju inimesi, kes seda teevad, kellel on väga head andmekogemused, mis neid tööle panevad.
Dez Blanchfield: See on suurepärane kaasavõtu punkt ja olen sellega täiesti nõus ning olen kindel, et dr Robin Bloor peaks seda ka tegema. Eriti ettevõtte asutamisel olete keskendunud väikese ja keskmise suurusega ettevõtjaks olemisele selle pakkumise konkreetsel väärtusel, mida soovite oma alustava ettevõtte osana luua, ja tõenäoliselt ei pea te olema kõige asjatundja, seega on suurepärane nõuanne. Kuid suur tänu, fantastiline esitlus. Tõesti suurepärased vastused ja küsimused. Eric, ma lähen teile tagasi, sest tean, et meil on aja möödudes möödunud arvatavasti kümme minutit ja ma tean, et teile meeldib jääda meie ajaakende lähedale.
Eric Kavanagh: See on okei. Meil on vähemalt paar head küsimust. Las ma viskan sulle ühe. Ma arvan, et olete mõnele teisele vastanud. Kuid väga huvitav tähelepanek ja küsimus ühelt osalejalt, kes kirjutab, on agiilses projektis mõnikord seda, et andmeside modelleerijal pole kogu pikaajalist pilti ja nii nad kavandavad midagi ühes ja siis peavad nad s-s kolm või neli ümber kujundama. Kas see ei tundu olevat kahjulik? Kuidas saab sellist asja vältida?
Ron Huizenga: See on lihtsalt vildakas olemus, et te ei saa etteantud olukorras kõike täiesti õigesti. Ja see on tegelikult osa vilgas vaimus: töötage sellega - teete prototüüpi seal, kus töötate antud koodi koodiga, ja hakkate seda täpsustama. Ja osa sellest protsessist on see, kui te toimetate asju, mida lõppkasutaja näeb ja ütleb: “Jah, see on lähedal, aga mul on tõesti vaja, et see ka natuke ära teeks.” Nii, et see ei mõjutaks ainult funktsionaalset disaini koodi enda järgi, kuid üsna sageli peame nende soovitud asjade alla muutma või lisama täiendavat andmestruktuuri, et kasutaja soovitud teavet edastada. Ja see on kõik aus mäng ja sellepärast soovite tõesti kasutada suure võimsusega tööriistu, kuna saate modelleerimise tööriistaga väga kiiresti modelleerida ja muudatusi teha ning seejärel genereerida andmebaasi DDL-i, mille arendajad saavad selle edastamiseks töötada muutke veelgi kiiremini. Säästad neid sellest, et nad ei peaks käsitsema andmestruktuuride käsitsi kodeerimist ja lasevad neil keskenduda programmeerimis- või rakenduse loogikale, mida nad kõige valdavad.
Eric Kavanagh: See on täiesti mõistlik. Paar teist inimest küsisid lihtsalt konkreetseid küsimusi, kuidas see kõik tööriista külge seob. Ma tean, et veetsite mõnda aega näiteid vaadates ja olete näidanud ekraanipilte selle kohta, kuidas te mõnda seda kraami tegelikult veeretate. Kui sageli näete kogu selle protsessi kontekstis organisatsioonide mängimises või kui sageli näete traditsioonilisemaid protsesse, kus asjad lihtsalt käivad mööda ja võtavad rohkem aega? Kui levinud on teie vaatevinklist s-stiilis lähenemine?
Ron Huizenga: Ma arvan, et me näeme seda üha enam. Ma tean, et ma ütleksin, et ilmselt eriti viimase 15 aasta jooksul olen näinud palju rohkem inimeste adopteerimist, kes mõistavad, et neil on tõesti vaja kiiremat kohaletoimetamist. Nii et ma olen näinud üha rohkem organisatsioone, kes hüppavad vilgale ribalainele. Mitte tingimata täielikult; nad võivad alustada mõne pilootprojektiga, et tõestada, et see töötab, kuid mõned on endiselt väga traditsioonilised ja vastavad jugameetodile. Nüüd on hea uudis muidugi see, et tööriistad töötavad väga hästi ka nendes organisatsioonides ja seda tüüpi metoodikate jaoks, kuid meil on tööriist kohandatav, nii et neil, kes hüppavad pardale, on tööriistad tööriistakastis aadressil nende sõrmeotsad. Sellised asjad nagu võrdlemine ja ühendamine, näiteks pöördprojekteerimisvõimalused, saavad nad vaadata olemasolevate andmeallikate sisu, nii et nad saavad tegelikult DDL-i skripte suhteliselt kiiresti võrrelda ja genereerida. Ja kui nad hakkavad seda omaks võtma ja näevad, et neil võib olla produktiivsust, suureneb nende kalduvus vilgas omaks võtta veelgi.
Eric Kavanagh: Noh, see on suurepärane värk, inimesed. Postitasin just vestlusaknasse seal olevate slaidide lingi, nii et kontrollige seda; see on natuke teie jaoks natuke olemas. Meil on kõik need veebisaated hilisemaks vaatamiseks olemas. Jagage neid julgelt oma sõprade ja kolleegidega. Ja Ron, tänan teid väga teie tänase aja eest. Teil on alati meeldiv olla saatel - tõeline oma ala asjatundja ja on ilmne, et teate oma asju. Nii et tänu teile ja tänu IDERAle ja muidugi Dezile ja meie enda Robin Bloorile.
Ja sellega tahame teile hüvasti jätta, inimesed. Täname teid veel kord teie aja ja tähelepanu eest. Oleme tänulikud, et olete 75 minutit ringi liikunud, see on päris hea märk. Tublid show-kutid, räägime teiega järgmine kord. Headaega.