Autors: Techopedia Staff, 2016. gada 16. novembris
Takeaway: Uzņēmējs Ēriks Kavanagh ar Robinu Blooru, Dezu Blanšfīldu un IDERA Ronu Huizengu apspriež datu modelēšanas nozīmi elastīgā attīstībā.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Ēriks Kavanaghs: Labi, dāmas un kungi. Esiet sveicināts vēlreiz. Ir trešdiena plkst. 4:00 EST. Tas nozīmē, ka ir pienācis laiks karstajām tehnoloģijām. Jā, patiesi. Mans vārds ir Ēriks Kavanaghs, es būšu jūsu saimnieks.
Šodienas tēmai tā ir vecene, bet labvēlis. Katru dienu tas kļūst arvien labāk, jo tas veido mūsu datu pārvaldības pasauli “Datu modelēšana saspringtā vidē”. Ir patiess slaids par tavu patiesību, mani uzlaiko Twitter @eric_kavanagh. Mums tas tiešām būtu jāliek uz šī slaida. Man būs jātiek pie tā.
Tātad gads karsts. Datu modelēšana ir notikusi mūžīgi. Tas patiešām ir bijis informācijas pārvaldības biznesa pamatā un dvēselē, izstrādājot datu modeļus, mēģinot izprast biznesa modeļus un pielāgot tos jūsu datu modeļiem. Tas tiešām ir tas, ko jūs mēģināt darīt, vai ne?
Datu modelis atspoguļo uzņēmējdarbību principiāli, tāpēc kā visi šie jaunie datu avoti maina spēli? Mēs par to uzzināsim. Mēs uzzināsim, kā jūs varat veikli uzkavēties virs lietām. Un, protams, tas ir gada vārds.
Robins Bloors kopā ar mums, mūsu galvenais analītiķis Dezs Blanšfīlds, zvanot no Sidnejas, Austrālijas, un Ronis Huizenga, IDERA vecākais produktu menedžeris - mans ilggadīgais draugs, izcils runātājs šajā telpā, zina savas lietas, tāpēc nekautrējieties, jautājiet viņam grūti jautājumi, ļaudis, grūti cilvēki. Līdz ar to es padarīšu Robinu par vadītāju un aizvedīšu to prom.
Dr Robin Bloor: Labi. Nu paldies par to, Ēriks. Par modelēšanu man jāsaka, ka, manuprāt, es patiesībā biju IT pasaulē, pirms tā pastāvēja, tādā nozīmē, ka apdrošināšanas uzņēmumā, kurā strādāju, es atceros, ka mums bija ienācis puisis un mums visiem laipni seminārs par to, kā modelēt datus. Tātad mēs skatāmies apmēram 30 gadus, vai tas ir 30 gadi? Varbūt pat ilgāk par to, varbūt pirms 35 gadiem. Ilgstošs, ilgs laiks, modelēšana faktiski ir bijusi nozares sastāvdaļa, un tam, protams, nav nekā kopīga ar dāmām, kas atrodas uz celiņiem.
Lieta, ko es gribēju pateikt, jo tas, ko mēs parasti darām, ir es un Dezs, runājot par dažādām lietām, un es tikai domāju, ka es sniegšu vispārīgu pārskatu modelēšanai, bet tam ir realitāte, kas tagad kļūst acīmredzama.
Mums, jūs zināt, ir lielo datu realitāte, mums ir vairāk datu, vairāk datu avotu, mums ir datu plūsmas, kas pēdējo trīs vai četru gadu laikā ir ievadījušas vienādojumu un sāk iegūt lielāku tās daļu, un ir lielāka vajadzība izprast datus un ir jāpalielina izmaiņu temps, jo vairāk datu tiek pievienoti, kā arī tiek izmantotas vairāk datu struktūras.
Tā ir sarežģīta pasaule. Šeit ir attēls no tā, kas patiesībā ir kaut kas tāds, ko mēs uzzīmējām apmēram pirms trim gadiem, bet būtībā, kad jūs iekļaujat straumēšanu maisījumā un rodas ideja par datu rafinēšanu, datu centrmezglu, datu saiti vai ko citu, jūs redzat, ka ir dati, kas ir patiesi miera stāvoklī tādā ziņā, ka tas neko daudz nekustina. Un tad ir dati, straumes un jums ir viss transakciju lietojums, kā arī mūsdienās patiesi ir notikumi, notikumu datu plūsmas, kas notiek lietojumprogrammās un, iespējams, ir vajadzīgas, un mūsdienās ar lambda arhitektūru, par kuru visi runā. kas ietekmē tikai visu datu lauku.
Un mūsdienās domā par datu slāņa esamību. Datu slānis pastāv sava veida virtuālā veidā tādā nozīmē, ka labs tā elements varētu atrasties mākonī un to varētu izplatīt dažādos datu centros, un tas varētu pastāvēt darbstacijās. Datu slānis zināmā mērā ir visur un tādā nozīmē visur ir procesi, kas tādā vai citādā veidā mēģina apstrādāt datus un pārvietot datus par tiem. Bet arī zināt, kas tas ir, kad jūs to virzāt, ir ļoti daudz.
Ja mēs skatāmies uz datu modelēšanu vispārīgākā nozīmē, tad šāda veida kaudzes apakšā jums ir faili un datu bāzes. Jums ir datu elementi, kuriem ir atslēgas, elementu definīcijas, pseidonīmi, sinonīmi, īpaši fiziski formāti, un tad mums ir šis metadatu slānis.
Metadatu interesanta lieta ir tā, ka metadati ir pilnīgi tā, kā dati iegūst savu nozīmi. Ja jums faktiski nav metadatu, tad labākajā gadījumā jūs varat uzminēt datu nozīmi, taču jums būs šausmīgi daudz grūtību. Metadatiem jābūt tur, bet nozīmei ir struktūra. Es nevēlos iedziļināties jēgas filozofijā, bet pat tādā veidā, kā mēs rīkojamies ar datiem, cilvēka domāšanā un cilvēka valodā ir daudz sarežģītības, kas viegli neizpauž datus. Bet pat attiecībā uz datiem, kurus mēs faktiski apstrādājam pasaulē, metadatiem ir nozīme un metadatu struktūra - viens datu gabals attiecībā pret otru, un ko tas nozīmē, kad tie tiek salikti, un ko tas nozīmē, kad viņi “ atkārtoti pievienojies citiem datiem, pieprasa to modelēt. Tas nav pietiekami labi, lai lietās vienkārši ierakstītu metadatu tagus, jums faktiski ir jāreģistrē nozīme uz struktūrām un attiecības starp struktūrām.
Tad augšējā slānī ir biznesa definīcijas, kas parasti ir slānis, kas mēģina nodot nozīmi starp metadatiem, kas ir datu definīcijas forma, kas pielāgo veidu, kā dati tiek organizēti datorā, un cilvēka nozīmi. Tātad jums ir biznesa termini, definīcijas, attiecības, entītiju līmeņa koncepcijas, kas pastāv šajā slānī. Un, ja starp šiem slāņiem rodas neatbilstība, tad mums ir jābūt datu modelēšanai. Tas nav īsti fakultatīvs. Jo vairāk jūs to faktiski varat izdarīt automatizējot, jo labāk. Bet tāpēc, ka tas ir saistīts ar nozīmi, to ir grūti mainīt. Tas ir pietiekami viegli, lai ierakstu ievilktu metadatus un varētu tos iegūt no nozīmju virknes, taču tas nepasaka jums par ierakstu struktūru vai to, ko ieraksti nozīmē, vai ieraksta kontekstu.
Tātad, par to, manuprāt, ir domāta datu modelēšana. Norādiet uz piezīmi: jo sarežģītāks kļūst datu visums, jo vairāk jums to nepieciešams modelēt. Citiem vārdiem sakot, tas ir mazliet kā tas, ka mēs pievienojam pasaulei ne tikai vairāk lietu lietu, kas atbilstu datu ierakstiem, bet mēs faktiski pievienojam pasaulei lielāku nozīmi, uztverot datus par vairāk un vairāk lietām. Mums tas ir jāsaprot arvien sarežģītāk.
Teorētiski pastāv datu visums, un mums tas ir nepieciešams. Praksē faktiskie metadati ir daļa no datu kopuma. Tātad, tā nav vienkārša situācija. Sākuma modelēšana notiek no augšas uz leju un no apakšas. Jums jāveido abos virzienos, un iemesls tam ir tas, ka datiem ir nozīme datoram un procesam, kam tie ir jāapstrādā, taču tiem ir nozīme pats par sevi. Tātad jums ir nepieciešama augšupēja nozīme, kas apmierina programmatūru, kurai ir nepieciešama piekļuve datiem, un jums ir nepieciešama augšupējā nozīme, lai cilvēki to varētu saprast. Metadatu modeļu veidošana nav un nekad nevar būt projekts; tā ir nepārtraukta darbība - tai jābūt nepārtrauktai darbībai katrā vidē, kurā tie pastāv. Par laimi, ir daudz vides, kur tas patiesībā nav, un lietas attiecīgi iziet ārpus kontroles.
Turpinoties modelēšanai, tehnoloģijai virzoties uz priekšu, nozīme pieaug. Tas ir mans viedoklis. Bet, ja paskatās uz IoT, mēs mobilajās ierīcēs varam saprast vairāk, nekā mēs pieraduši, lai gan tajā ir ieviestas jaunas dimensijas: atrašanās vietas dimensija ar mobilo. Kad esat nokļuvis IoT, mēs aplūkojam ārkārtas datu problēmas, kuras mums nekad agrāk nebija jādara, un mums tā vai citādi ir pareizi jāsaprot, kas tieši mums ir, tieši tas, kā mēs to varam apkopot, ko mēs varam darīt, lai iegūtu jēgu no apkopošanas, un, protams, ko mēs varam darīt ar to, kad esam to apstrādājuši.
Es domāju, ka tas esmu es pietiekami pateikts. Es došos tālāk Dez Blanchfield, kurš pateiks kaut ko citu.
Dez Blanchfield: Paldies. Vienmēr smaga rīcība, kas jāievēro, taču šī ir tēma, par kuru vienojāmies un par to īsi runājām pirmsizstādes ķircināšanā, un, ja jūs zvanītu agri, jūs, iespējams, būtu noķēris veselu virkni lielisku dārgakmeņu. Viena no paņemšanām, un es nevēlos nozagt šī konkrētā pērkonu, bet viena no uzstāšanās reizēm no mūsu izstādes autora, ar kuru es vēlos padalīties, ja jūs to nepieķērāt, bija tikai ap tēmu datu ceļojums, un tas mani pārsteidza, pierakstot to, domājot par braucienu, ko dati veic citā kontekstā paaudžu dzīves laikā - gads, mēneši, nedēļa, diena, stunda, minūte, otra - un konteksts ap datiem ir novietots šajā kontekstā. Neatkarīgi no tā, vai esmu izstrādātājs, kurš darbojas ar kodu, vai arī esmu datu speciālists, es domāju par struktūru un formātu un metadatiem ap katru no elementiem, vai par to, kā sistēmas un bizness mijiedarbojas ar to.
Tas ir interesants neliels veikals, kuru vienkārši jāpiezīmē, bet katrā ziņā ļaujiet man ienirt. Jo īpaši datu dizains ir frāze, kuru es izmantoju, lai runātu par visu lietu datiem un īpaši par lietojumprogrammu vai datu bāzes infrastruktūras attīstību. Es domāju, ka datu dizains ir termins, kas to visu ļoti labi uztver manā prātā. Šajās dienās, kad mēs runājam par datu dizainu, mēs runājam par mūsdienīgu veiklu datu dizainu, un es uzskatu, ka ne tik sen, izstrādātāji un datu eksperti strādāja vieni; tie atradās savās tvertnēs, un dizaina gabali gāja no viena tvertnes uz otru. Bet šajās dienās es ļoti uzskatu, ka mainījies ir ne tikai gadījums, bet arī tas; tā ir sava veida nepieciešamība, un tā ir šī lietojumprogramma - izstrādātāji un viss, kas saistīts ar attīstību, kas nodarbojas ar datiem, dizaineri, kuri veic attiecīgus shēmu un lauku un ierakstu dizaina elementus, kā arī atrašanās vietas un datu bāzes sistēmas un infrastruktūras, modelēšana un visa vadība izaicinājums tam apkārt. Tagad tas ir komandas sporta veids, un līdz ar to mans attēls ar cilvēku loku, kurš izlec no lidmašīnas un darbojas kā komanda, lai izspēlētu šo vizuāli interesanto cilvēku attēlu, kas krīt caur debesīm.
Treškārt, kas notika, lai to panāktu? Nu, tur ir 1986. gada raksts, ko uzrakstījuši pāris kungi, kuru vārdus es izmisīgi mēģināju darīt taisnīgi. Hirotaka Takeuchi un Ikujiro Nonaka, manuprāt, tas tiek izrunāts, sagatavoja rakstu, kura nosaukums bija “Scrum Downfield pārvietošana”. Viņi iepazīstināja ar šo rakstu. šī metodikas ideja, kā uzvarēt regbija spēli, aizejot no šīs skrējiena aktivitātes, kur visi pārvietojas vienā vietā un divas komandas būtībā ieslogo galvas kaut ko sauc par skrubi, lai mēģinātu iegūt kontroli pār bumbu un izspēlēt to laukumā nokļūstiet mēģinājumu līnijā un pieskarieties bumbiņai ar zemi un iegūstiet punktu, ko sauc par trinu, un jūs atkārtojat šo procesu, un komandai tiek piešķirti vairāk punktu.
Šis raksts tika publicēts 1986. gadā Hārvarda Biznesa pārskatā, un, kas dīvaini, tas patiesībā ieguva daudz uzmanības. Tam tika pievērsta liela uzmanība, jo tika ieviesti pārsteidzoši jauni jēdzieni, un šeit ir ekrāna ekrāna attēls tā priekšpusē. Tāpēc viņi izņēma šo skrējiena jēdzienu no spēles regbija un ieviesa to biznesā, it īpaši dizaina un projekta piegādes, īpaši projekta piegādes, spēlē.
Tas, ko izdarīja skrubis, deva mums jaunu metodoloģiju, salīdzinot ar PRINCE2 vai PMBOK patīkām, kuras mēs iepriekš bijām izmantojuši tā dēvētajā ūdenskrituma metodoloģijā, ziniet, dariet šo un šo lietu un šo lietu un sekojiet tām secīgi un savienojiet visi punkti apkārt, kas atkarīgs no tā, kas jums bija, vai neveiciet otro daļu, kamēr neesat paveicis pirmo daļu, jo tas bija atkarīgs no pirmās daļas. Tas, ko mums deva, ir jauna metodika, lai kļūtu mazliet veiklāka, no kurienes nāk šis termins, par to, kā mēs piegādājam lietas, un jo īpaši par projekta izstrādi un attīstību pamata projektā.
Daži no galvenajiem īrniekiem - tikai tā es ar to ķēros klāt - ir ap galvenajiem skuvekļu īrniekiem. Tā iepazīstināja ar ideju par nestabilitātes veidošanu, ka, ja domājat par haosa bailēm, pasaule pastāv haosa stāvoklī, bet veidojas planēta, kas ir interesanta, tāpēc ēkas nestabilitāte, spēja mazliet atlēkt un joprojām faktiski liek darboties, pašorganizējoties projekta komandām, savstarpēji pārklājoties, izmantojot ļoti atbildīgu attīstību, dažāda veida mācīšanos un kontroli projekta izpildes laikā, organizatorisko mācību nodošanu. Tātad, kā mēs ņemam informāciju no vienas biznesa daļas un nododam to citai no cilvēkiem, kuriem ir ideja, bet kuri neveido kodu vai neveido datu bāzes un infrastruktūru, bet datus šiem cilvēkiem? Un īpaši laika ziņā ieņemtie rezultāti. Citiem vārdiem sakot, darīsim to noteiktu laika periodu, dienu vai 24 stundas, vai nedēļu vai pāris nedēļas, un redzēsim, ko mēs varam darīt, un tad atkāpsimies un apskatīsim to.
Un tāpēc, ja jūs apžēlojat pundu, šī ir patiešām jauna spēle projekta piegādē un tam piederošajām trim galvenajām sastāvdaļām, kurai būs jēga, kad mēs šeit mazliet tālāk nonāksim - tur ir produkts: visiem šiem cilvēkiem ir ideja un viņiem ir vajadzība kaut ko paveikt, un stāsts, kas viņus ieskauj. Izstrādātāji, kas darbojas ar veiklu stāstu iegūšanas modeli un ikdienā izmanto standarta norādes, izmantojot scrum metodoloģiju, lai apspriestu to un saprastu, kas viņiem jādara, un tad vienkārši dodieties un ķersieties pie tā, kā to darāt. Tad mēs esam dzirdējuši par skrubu meistariem, kuri pārrauga visu šo lietu un pietiekami labi saprot metodoloģiju, lai to vadītu. Mēs visi esam redzējuši šos attēlus, kas man parādījās labajā pusē pie sienām un tāfelēm, kas bija pilnas ar Post-It piezīmēm, un tās tika pasniegtas kā Kanban sienas. Ja jūs nezināt, kurš ir Kanbans, es jūs uzaicinu uz Google, kurš bija Kanbans kungs un kāpēc tas mainīja veidu, kā mēs burtiski, bet projektā pārceļam lietas no vienas puses uz otru sienā.
Īsumā scrum darbplūsma rīkojas šādi: tiek ņemts saraksts ar lietām, kuras organizācija vēlas darīt, palaižot cauri virknei lietu, kuras mēs saucam par sprintiem, kas sadalīti 24 stundu periodos, mēneša periodos, un mēs iegūstiet šo izejas pieaugošo sēriju. Tās ir nozīmīgas izmaiņas projektu piegādes veidā, tika piegādāti līdz tam posmam, jo daļa no tā plūst kā ASV armija, kurai bija liela daļa kaut ko attīstot ar nosaukumu PMBOK, piemēram, ideja neņemt tanku laukā līdz brīdim, kad jūs ieliekat lodes, jo, ja tvertnei laukā nav ložu, tā ir bezjēdzīga. Tāpēc pirmā daļa tiek ievietota lodes tvertnē, otrā daļa - tvertni laukā. Diemžēl, tas, kas notika ar izstrādātājiem attīstības pasaulē, kaut kā sagrāba šo veiklo metodoloģiju un, spriežot pēc soda, izlaida to sprintā.
Vienmēr ir noticis tas, ka, domājot par veiklību, mēs parasti domājam par izstrādātājiem, nevis par datu bāzēm un jebko, kas saistīts ar datu bāzu pasauli. Tas bija neveiksmīgs iznākums, jo realitāte ir tāda, ka veikls nav tikai izstrādātāji. Faktiski terminu veikls, manuprāt, bieži vien kļūdaini saista tikai ar programmatūras izstrādātājiem, nevis ar datu bāzu izstrādātājiem un arhitektiem. Vienmēr tie paši izaicinājumi, ar kuriem jūs saskaras programmatūras un lietojumprogrammu izstrādē, ir sastopami visās lietās, kas saistītas ar projektēšanu un izstrādi, darbību un uzturēšanu, tātad arī ar datu infrastruktūru un jo īpaši datu bāzēm. Šajā konkrētajā datu izlases dalībnieku skaitā ir tādi, kā datu arhitekti, veidotāji, administratori, datu bāzu infrastruktūru pārvaldītāji un pašas datu bāzes līdz biznesa un sistēmu analītiķiem un arhitektiem, cilvēkiem, kuri sēž un domā par to, kā sistēmas un bizness darbojas, un kā mēs esam ieguvuši, lai caur tiem plūstu datus.
Tā ir tēma, kuru es regulāri aktualizēju, jo tā ir nepārtraukta manis sarūgtināšana, jo es ļoti uzskatu, ka datu speciālistiem ir - nevis jābūt - tagad ir cieši jāiesaista visos projekta piegādes komponentos, patiesībā, īpaši attīstībā. Lai mēs to nedarītu, mēs patiešām nedodam sev labākās izredzes uz labu iznākumu. Mums bieži vien ir jāgriežas atpakaļ un jādomā par šīm lietām, jo pastāv scenārijs, mēs nonākam pie izveidojamas lietojumprogrammas un atklājam, ka izstrādātāji ne vienmēr ir datu eksperti. Darbs ar datu bāzēm prasa ļoti specializētas prasmes, jo īpaši attiecībā uz datiem, un tas rada pieredzi. Jūs ne tikai vienā mirklī nekļūstat par datu bāzes guru vai datu zināšanu ekspertu; tas bieži ir kaut kas tāds, kas nāk no dzīves pieredzes, un tas, protams, ir līdzīgs dakterim Robinam Blooram laikrakstā The Code Today, kurš diezgan bagātīgi rakstīja grāmatu.
Daudzos gadījumos - un tas ir žēl, bet tā ir realitāte - ka ir divas šīs monētas daļas, tas ir, programmatūras izstrādātājiem ir savs aptumšojums attiecībā uz datu bāzes speciālistu un viņi ir iebūvējuši nepieciešamās prasmes datu bāzu dizaina modelēšanā, modeļa izstrāde ir tikai fundamentāls guru inženierijas veids, kā dati tiek iegūti un kā notiek brauciena organizācija un kā tam vajadzētu būt vai nevajadzētu izskatīties, vai neapšaubāmi tas ir patērēts un saprotams, ka tas parasti tiek iegūts vietējās prasmēs, kas programmatūras izstrādātājiem noteiktas. Un daži no kopīgajiem izaicinājumiem, ar kuriem mēs sastopamies, vienkārši sakot kontekstā, ietver tādas pašas darbības kā vienkārša pamata datu bāzes veidošana, uzturēšana un pārvaldīšana, datu un datu bāzes infrastruktūras dokumentēšana un pēc tam šo datu aktīvu, shēmu izstrāde, shēmu ģenerēšana, shēmas administrēšana un uzturēšana, kā arī to izmantošana, dalīšanās ar zināšanām, kāpēc šī shēma ir veidota noteiktā veidā, un stiprās un vājās puses, kas ar laiku saistītas, laika gaitā izraisa datu izmaiņas, datu modelēšanu un veidus modeļu, kurus mēs izmantojam sistēmām, un datiem, kurus mēs caur tiem plūdam. Datu bāzes kodu ģenerēšana, un pēc tam notiek integrācija, pēc tam modelējot datus ap tiem un pēc tam ātrāk piekļūstot datu drošības kontrolei, datu integritāte ir tāda, ka mēs pārvietojam datus apkārt, saglabājot to integritāti, vai apkārt ir pietiekami daudz metadatu tas, vai pārdevējiem vajadzētu redzēt visus tabulas ierakstus vai arī viņiem vajadzētu redzēt tikai adresi, vārdu un uzvārdu, kas jums nosūta ziņas pa pastu? Un tad, protams, lielākais izaicinājums ir datu bāzes platformu modelēšana, kas pati par sevi ir atšķirīga saruna.
Es ļoti uzskatu, ka, paturot prātā visu šo nirvānu, ir absolūti svarīgi, lai gan datu speciālistiem, gan izstrādātājiem būtu piemēroti rīki un šie rīki būtu spējīgi uz komandu vērstus projektus, projektēšana, izstrāde un pastāvīga ekspluatācijas uzturēšana. Jūs zināt, tādas lietas kā sadarbība starp projektiem starp datu ekspertiem un programmatūras izstrādātājiem, viens patiesības punkts vai viens patiesības avots visām lietām, kas saistītas ar pašu datu bāzu dokumentēšanu, datiem, shēmām, no kurienes nāk ieraksti, šo ierakstu īpašniekiem . Es domāju, ka mūsdienās tas ir absolūti kritiski, un mēs iegūstam šo datu nirvānu par to, ka valdīsim, ka ir jābūt pareizajiem instrumentiem, jo tagad izaicinājums ir pārāk liels, lai mēs to izdarītu manuāli, un, ja cilvēki Pāriet vienā organizācijā un iziet no tās, mums ir pārāk viegli nesekot vienam un tam pašam labajam procesam vai metodikai, ko varētu izveidot viena persona, un tas ne vienmēr nodod tālāk esošās prasmes un iespējas.
Paturot to prātā, es došos pie mūsu labā drauga IDERA un uzzināšu par šo rīku un tā risināšanu tieši šajās lietās.
Rons Huizenga: Liels paldies un paldies gan Robinam, gan Dezam, ka viņi patiešām labi uzstāja skatuvi, un jūs redzēsit mazliet pārklāšanos pāris lietās, par kurām esmu runājis. Bet viņi patiešām ir izveidojuši ļoti stabilu pamatu dažiem no jēdzieniem, par kuriem es runāšu no datu modelēšanas viedokļa. Un daudzas no tām, ko viņi teica, atkārto manu pieredzi, kad es biju konsultants, kas strādāja ar datu modelēšanu un datu arhitektūru kopā ar komandām - gan ūdenskritums pirmajās dienās, gan attīstot mūsdienīgākus produktus ar projektiem, kur mēs izmantojām veiklu metodoloģijas risinājumu sniegšanai.
Tātad tas, par ko es šodien runāšu, ir balstīts uz šo pieredzi, kā arī uz viedokli par rīkiem un dažām rīku iespējām, kurus mēs izmantojam, lai palīdzētu mums šajā ceļojumā. Tas, ko es īsi aprakstīšu, ir tas, ka es neiedziļināšos sīkumos; mums vienkārši bija patiešām labs pārskats par to, kas tas ir. Es runāšu par to, runājot par to, kas ir datu modelis un ko tas mums patiesībā nozīmē? Un kā mēs savās organizācijās iespējam veiklās datu modelētāja koncepciju, runājot par to, kā mēs iesaistām datu modelētājus, kāda ir modelētāju un arhitektu līdzdalība sprinta laikā, kādi ir darbības veidi, kas viņiem jāveic un, ņemot vērā to, kādas ir dažas no svarīgām modelēšanas rīka iespējām, kuras mēs izmantojam, lai patiešām palīdzētu atvieglot šo darbu? Pēc tam es mazliet iedziļināšos un mazliet pastāstīšu par dažām biznesa vērtībām un priekšrocībām, kas saistītas ar datu modelētāja iesaistīšanu, vai arī veids, kā es patiesībā stāstu stāstu, problēmas, kas saistītas ar to, ka datu modelētājs nav pilnībā iesaistījies projektos, un es jums to parādīšu, balstoties uz pieredzi un faktiskā projekta pirms un pēc attēla defektu diagrammu, kurā biju iesaistīts pirms daudziem gadiem. Tad mēs apkoposim vēl dažus punktus, un tad papildus tam būs jautājumi un atbildes.
Īsi sakot, ER Studio ir ļoti jaudīgs komplekts, kam ir ļoti daudz dažādu komponentu. Datu arhitekts, kur datu modelētāji un arhitekti lielāko daļu laika pavada, modelējot datus. Ir arī citi komponenti, par kuriem šodien vispār nerunāsim, piemēram, biznesa arhitekts, kur mēs veicam procesu modelēšanu un programmatūras arhitekts, attiecībā uz kādu no UML modelēšanu. Tad tur ir repozitorijs, kurā mēs reģistrējamies un dalāmies ar modeļiem, un mēs ļaujam komandām sadarboties ar tiem un publicēt tos komandas serverī, lai vairākas ieinteresēto personu auditorijas, kas iesaistītas projektā, faktiski varētu redzēt artefaktus, kurus mēs esam “ tiek izveidota no datu perspektīvas, kā arī citas lietas, kuras mēs darām paša projekta piegādē.
Tas, uz ko es šodien koncentrēšos, būs dažas lietas, kuras mēs redzēsim no Data Architect, un tāpēc, ka ir patiešām svarīgi, lai mums būtu sadarbība ar Repository balstītiem aspektiem. Īpaši tad, kad mēs sākam runāt par tādām koncepcijām kā izmaiņu vadība, kas ir obligāti ne tikai veikliem attīstības projektiem, bet arī jebkura veida attīstībai.
Tāpēc uz brīdi runāsim par Agile Data Modeler. Kā mēs jau esam iezīmējuši, iepriekš pieminējot prezentācijā, ir svarīgi, lai mums būtu datu modelētāji un / vai arhitekti, kas pilnībā iesaistīti veiklajos attīstības procesos. Tagad tas, kas notika vēsturiski, jā, mēs patiešām esam domājuši par veiklību no attīstības viedokļa, un ir dažas lietas, kas ir notikušas, kas patiesībā ir izraisījušas šo notikumu. Daļēji tas bija saistīts ar pašas attīstības veida raksturu. Kad sākās veikla attīstība un mēs sākām ar šo pašorganizējošo komandu jēdzienu, ja jūs dzērāt Kool-Aid mazliet pārāk tīri un jūs bijāt lietu galējā programmēšanas pusē, tur bija ļoti burtiska interpretācija tādām lietām kā pašorganizējošās komandas, kuras daudzi cilvēki to uzskatīja, viss, kas mums vajadzīgs, ir izstrādātāju grupa, kas var izveidot visu risinājumu. Neatkarīgi no tā, vai tas ir koda, datu bāzu vai datu bāzes attīstīšana, un viss tika nodots izstrādātājiem. Bet kas ar to notiek, jūs zaudējat īpašās spējas, kas cilvēkiem ir. Esmu noskaidrojis, ka spēcīgākās komandas ir tās, kuras veido cilvēki no dažādām vidēm. Piemēram, spēcīgu programmatūras izstrādātāju, datu arhitektu, datu modelētāju, biznesa analītiķu un biznesa ieinteresēto pušu apvienojums, kas visi sadarbojas, lai rastu gala risinājumu.
Tas, par ko es šodien runāju, ir tas, ka es to darīšu attīstības projekta kontekstā, kur mēs izstrādājam lietojumprogrammu, kurai acīmredzot būs arī ar to saistītā datu sastāvdaļa. Tomēr, pirms to darām, mums ir jāsper solis atpakaļ, jo mums ir jāsaprot, ka ir ļoti maz Greenfield attīstības projektu, kur mēs pilnībā koncentrējamies uz tādu datu izveidi un patēriņu, kas ir ierobežoti tikai pašā attīstības projektā. . Mums ir jāsper solis atpakaļ un jāskatās uz kopējo organizācijas viedokli no datu perspektīvas un procesa perspektīvas. Tā kā mēs uzzinām, ka informācija, kuru mēs izmantojam, jau pastāv kaut kur organizācijās. Kā modelētāji un arhitekti mēs to izceļam, lai mēs zinātu, no kurienes šo informāciju iegūt pašos projektos. Mēs zinām arī iesaistītās datu struktūras, jo mums ir dizaina modeļi tāpat kā izstrādātājiem ir sava koda dizaina modeļi. Un mums ir arī jāņem vērā šī vispārējā organizatoriskā perspektīva. Mēs nevaram tikai apskatīt datus mūsu izveidotās lietojumprogrammas kontekstā. Mums ir jāmodelē dati un jāpārliecinās, ka tos dokumentējam, jo tie dzīvo tālu ārpus pašu lietojumprogrammām. Šīs lietojumprogrammas nāk un iet, taču mums jāspēj aplūkot datus un pārliecināties, ka tie ir robusti un labi strukturēti ne tikai lietojumprogrammām, bet arī lēmumiem, kas ziņo par darbībām, BI pārskatu veidošanu un integrāciju citām lietojumprogrammām, iekšējām un arī ārpus mūsu organizācijām. Tāpēc mums ir jāaplūko viss lielais datu attēls un to dzīves cikls, kā arī jāsaprot informācijas gabalu ceļojums visā organizācijā no šūpuļa līdz kapam.
Tagad atgriežoties pie pašām komandām un tā, kā mums patiesībā ir jāstrādā, ūdenskrituma metodoloģija tika uztverta kā pārāk lēna, lai sniegtu rezultātus. Jo, kā norādīts ar tanka piemēru, tas bija viens solis pēc otra, un bieži vien vajadzēja pārāk ilgu laiku, lai sniegtu praktiski izmantojamu gala rezultātu. Tas, ko mēs tagad darām, ir tāds, ka mums ir jābūt iteratīvam darba stilam, kur mēs pakāpeniski attīstām tā komponentus un attīstām to laika gaitā, kur mēs ražojam izmantojamu kodu vai izmantojamus artefaktus, es teikšu, ka katram sprintam. Svarīga lieta ir sadarbība starp komandas tehniskajām ieinteresētajām personām un biznesa ieinteresētajām personām, jo mēs sadarbojamies, lai šos lietotāju stāstus iedvesmotu realizējamā koda redzējumā un datos, kas arī atbalsta šo kodu. Un pats Agile Data Modeler bieži pamanīs, ka organizācijās mums nav pietiekami daudz modelētāju, tāpēc viens datu modelētājs vai arhitekts vienlaikus var atbalstīt vairākas komandas.
Otrs aspekts ir tas, ka pat tad, ja mums ir vairāki modelētāji, mums jāpārliecinās, ka mums ir rīku komplekts, kuru mēs izmantojam un kas ļauj sadarboties vairākiem projektiem, kuri vienlaikus atrodas lidojumā, un dalīties ar tiem datu artefaktus un reģistrēšanās un izrakstīšanās iespējas. Es to ļoti ātri pārdomāšu, jo mēs to jau apskatījām iepriekšējā sadaļā. Agile veikls priekšnoteikums ir tas, ka jūs balstāt lietas uz aizkavēšanos, stāstiem vai prasībām. Ierāciju ietvaros mēs sadarbojamies kā grupa. Parasti divu nedēļu vai viena mēneša sprints atkarībā no organizācijas ir ļoti izplatīts. Katru dienu arī pārskatīsim un izskatīsim tikšanās, lai mēs likvidētu bloķētājus un pārliecinātos, ka mēs virzāmies uz priekšu visiem, bez apstāšanās dažādās jomās, kad mēs iet. Šajos sprintos mēs vēlamies pārliecināties, ka katra sprinta laikā mēs ražojam izmantojamus nodevumus.
Tikai nedaudz savādāk, paplašinot to, scrum ir metodoloģija, par kuru es šeit runāšu konkrētāk, un mēs sākotnēji esam tikai papildinājuši šo attēlu ar dažām citām šķautnēm. Parasti tur ir produktu atlikums un tad sprints. Tātad mums ir vispārējs kavējums, ka katra sprinta atkārtojuma sākumā mēs domājam teikt: “Ko mēs veidosim šo sprintu?”, Un tas tiek darīts sprinta plānošanas sanāksmē. Pēc tam mēs sadalām uzdevumus, kas ir saistīti ar to, un izpildām tos vienas līdz četru nedēļu sprintā ar šīm ikdienas atsauksmēm. Tā kā mēs darām, mēs izsekojam mūsu progresam, izmantojot izdegšanas diagrammas un izdegšanas diagrammas, lai izsekotu galvenokārt to, kas ir palicis, lai veidotu, salīdzinot ar to, ko mēs veidojam, lai izveidotu tādas lietas kā mūsu attīstības ātrums, vai mēs grafiks, visu šo lietu veidi. Tie visi tiek izstrādāti nepārtraukti sprinta laikā, nevis dodoties dažus mēnešus pa ceļu un uzzinot, ka jūs drīz nāksit klajā un jums jāpagarina projekta grafiks. Un ļoti svarīgi, ka tā sastāv no visām komandām, ir sprinta pārskats beigās un sprinta retrospektīva, tāpēc pirms nākamās iterācijas uzsākšanas jūs pārskatāt paveikto un meklējat veidus, kā varat uzlabot nākamajā reizē, izmantojot.
Runājot par nodevām, tas būtībā ir slaids, kurā apkopoti tipiskie lietu veidi, kas notiek sprintos. Un tas ir ļoti orientēts uz attīstību, tāpēc daudzas lietas, kuras mēs šeit redzam, piemēram, funkcionālie dizaini un lietošanas gadījumi, veicot dizaina koda testus, kad mēs šeit aplūkojam šīs rūtiņas, es negrasos tos cauri jebkurā detalizācijas pakāpē viņi ir ļoti orientēti uz attīstību. Šeit ir apslēpts fakts, ka mums arī ir vajadzīgi tie datu nodevumi, kas iet roku rokā ar šo, lai atbalstītu šos centienus. Tāpēc katru reizi, kad mēs redzam lietas, piemēram, aizkavēšanos, prasības un lietotāju stāstus, mums pārdomājot, kādi ir attīstības gabali, kas mums jādara, kādas ir analīzes daļas, kas mums jādara, kā būtu ar datu dizains vai datu modelis, kā ir ar biznesa glosārijiem, lai biznesa nozīmi varētu saistīt ar visiem mūsu radītajiem artefaktiem? Jo mums katrā sprintā jāražo tie izmantojamie nodevumi.
Daži cilvēki teiks, ka mums katra sprinta beigās ir jāsagatavo izmantojams kods. Tas nebūt nav tas pats, tas ir, tīrākajā attīstības perspektīvā, bet diezgan bieži - it īpaši sākumā - mums var būt kaut kas līdzīgs sprinta nullei, kur mēs koncentrējamies tikai uz stāvošām lietām, veicot tādas darbības kā testa testa stratēģiju iegūšana vieta. Augsta līmeņa dizains, lai to sāktu, pirms mēs sākam aizpildīt detaļas un pārliecināties, ka mums ir tīrs sākuma stāstu vai prasību kopums, pirms mēs sākam iesaistīt citas auditorijas un pēc tam veidot komandu kā komandu, turpinot virzību uz priekšu. Vienmēr ir nedaudz sagatavošanās laika, tāpēc diezgan bieži mums būs nulles sprints vai pat nulles sprints. Varētu būt nedaudz sākuma posms, pirms mēs piegādājam risinājumu pilnam lidojumam.
Par datu modeļiem šajā kontekstā runāsim ļoti īsi. Kad cilvēki domā par datu modeļiem, viņi bieži domā par datu modeli kā attēlu par to, kā dažādi informācijas elementi sasaistās - tas ir tikai aisberga redzamā daļa. Lai pilnībā iemiesotu garu tam, kā jūs patiešām vēlaties pieiet pie datu modelēšanas - neatkarīgi no tā, vai tas ir attīstīts, vai arī citās lietās -, jums ir jāsaprot, ka datu modelis, ja tas tiek izdarīts pareizi, kļūst par jūsu pilnīgu specifikāciju tam, ko šie dati nozīmē organizācijā un kā tas tiek izvietots fona datu bāzēs. Kad es saku datu bāzes, es domāju ne tikai relāciju datu bāzes, kuras mēs varbūt izmantojam, bet mūsdienu arhitektūrās, kur mums ir lieli dati vai NoSQL platformas, kā es labprātāk tos saucu. Arī tos lielos datu krājumus, jo, iespējams, mēs kombinējam daudz dažādu datu krātuvju attiecībā uz informācijas patērēšanu un ieviešanu mūsu risinājumos, kā arī par to, kā mēs šo informāciju saglabājam vai saglabājam arī no mūsu risinājumiem.
Iespējams, ka konkrētās lietojumprogrammas ietvaros mēs vienlaikus strādājam ar vairākām datu bāzēm vai datu avotiem. Ļoti svarīgi ir tas, ka mēs vēlamies, lai mums būtu pilnīga specifikācija, tātad loģiska specifikācija, ko tas nozīmē sprinta organizatoriskajā perspektīvā, kādas ir fizikālās konstrukcijas attiecībā uz to, kā mēs faktiski definējam datus, attiecības starp to jūsu datu bāzes, atsauces integritātes ierobežojumi, pārbaudes ierobežojumi - visi tie validācijas gabali, par kuriem jūs parasti domājat. Aprakstošie metadati ir ārkārtīgi svarīgi. Kā jūs zināt, kā izmantot datus lietojumprogrammās? Ja vien jūs to nevarat definēt un zināt, ko tas nozīmē, vai zināt, no kurienes tas nāk, lai pārliecinātos, ka šajās lietojumprogrammās patērējat pareizus datus - pārliecinieties, vai mums ir pareizas nosaukšanas konvencijas, pilnīgas definīcijas, kas nozīmē pilnu datu vārdnīcu ne tikai tabulas, bet slejas, kurās ir šīs tabulas, un detalizētas ieviešanas piezīmes par to, kā mēs to izmantojam, jo mums ir jāveido šī zināšanu bāze, jo pat tad, kad šī lietojumprogramma tiks veikta, šī informācija tiks izmantota citām iniciatīvām, tāpēc mums jāpārliecinās ka mēs to visu esam dokumentējuši turpmākai ieviešanai.
Atkal mēs nonākam pie tādām lietām kā datu tipi, atslēgas, indeksi, pats datu modelis iemieso daudzus biznesa noteikumus, kas tiek izmantoti. Attiecības nav tikai ierobežojumi starp dažādām tabulām; tie bieži palīdz mums aprakstīt, kādi ir patiesie uzņēmējdarbības noteikumi, kas attiecas uz to, kā šie dati uzvedas un kā tie darbojas kopā kā saliedēta vienība. Un, protams, vērtības ierobežojumi ir ļoti svarīgi. Protams, viena no lietām, ar kuru mēs pastāvīgi saskaramies, un tā kļūst arvien izplatītāka, ir tādas lietas kā datu pārvaldība. Tātad no datu pārvaldības viedokļa mums ir jāaplūko arī tas, ko mēs šeit definējam? Mēs vēlamies definēt tādas lietas kā drošības klasifikācijas. Ar kādiem datu veidiem mēs strādājam? Kas tiks uzskatīts par galveno datu pārvaldību? Kādus darījumu veikalus mēs veidojam? Kādus atsauces datus mēs izmantojam šajās lietojumprogrammās? Mums jāpārliecinās, ka tas ir pareizi atspoguļots mūsu modeļos. Apsverot arī datu kvalitātes apsvērumus, ir noteikta informācija, kas organizācijai ir svarīgāka nekā citiem.
Esmu iesaistījies projektos, kur vairāk nekā duci mantoto sistēmu mēs aizstājām ar jauniem biznesa procesiem un izstrādājām jaunas lietojumprogrammas un datu krājumus, lai tos aizstātu. Mums vajadzēja zināt, no kurienes nāk šī informācija. Kas attiecas uz vissvarīgāko informāciju, skatoties no biznesa viedokļa, ja aplūkojat šo konkrēto datu modeļa slaidu, kas man šeit ir, jūs redzēsit, ka šo konkrēto entītiju apakšējie lodziņi, kas ir tikai maza apakškopa, es mēs patiesībā esam spējuši uztvert biznesa vērtību. Neatkarīgi no tā, vai šāda veida lietām ir augsta, vidēja vai zema līmeņa rādītāji šīm dažādajām konstrukcijām organizācijā. Es esmu iemūžinājis arī tādas lietas kā pamatdatu klases, neatkarīgi no tā, vai tās ir galvenās tabulas, vai tās ir atsauces, ja tās ir transakcijas. Tātad mēs varam paplašināt metadatus savos modeļos, lai sniegtu mums daudz citu raksturlielumu, kas nav saistīti ar pašiem datiem, kas mums patiešām palīdzēja ar citām iniciatīvām ārpus sākotnējiem projektiem un pārnesa to tālāk. Tagad, kad vienā slaidā bija daudz, es diezgan ātri pārdomāšu pārējos.
Tagad es ļoti ātri runāšu par to, ko dara datu modelētājs, pārdzīvojot šos dažādos sprintus. Pirmkārt, pilntiesīgs sprinta plānošanas sesiju dalībnieks, kurā mēs uzņemamies lietotāju stāstus, apņemamies to, ko mēs sniegsim šajā sprintā, un izdomājām, kā mēs to strukturēsim un piegādāsim. Tas, ko es daru arī kā datu modelētājs, ir tas, ka es zinu, ka strādāšu atsevišķās jomās ar dažādiem izstrādātājiem vai ar dažādiem cilvēkiem. Tātad viens no svarīgākajiem raksturlielumiem, kas mums var būt, kad mēs darām datu modeli, mēs varam sadalīt šo datu modeli dažādos skatos, neatkarīgi no tā, vai jūs tos saucat par priekšmetu apgabaliem vai apakšmodeļiem, ir mūsu terminoloģija. Tā kā mēs veidojam modeli, mēs to parādām arī šajās dažādajās apakšmodeļu perspektīvās, lai dažādās auditorijas redzētu tikai to, kas viņiem ir piemērots, lai viņi varētu koncentrēties uz to, ko viņi izstrādā un izvirza. Tātad, iespējams, kāds strādā pie lietojumprogrammas plānošanas daļas, iespējams, kāds cits strādā pie pasūtījuma ievadīšanas, kur mēs visas šīs lietas veicam vienā sprintā, bet es varu viņiem dot viedokli, izmantojot tos apakšmodeļus, kuri tikai attiecas uz teritoriju, kurā viņi strādā. Un pēc tam tie izvēlas kopējo modeli un visu apakšmodeļu struktūru, lai sniegtu dažādiem auditorijas skatījumiem to, kas viņiem jāredz.
Datu modelēšanas pamatprincipi, kas mums ir nepieciešami, vienmēr ir ar sākotnējo vērtību, pie kuras mēs varam atgriezties, jo viena no lietām, kas mums jāprot, ir, neatkarīgi no tā, vai tas ir sprinta beigās vai beigās no vairākiem sprintiem, mēs vēlamies zināt, kur mēs sākām, un vienmēr ir pamats, lai zinātu, kāda bija delta vai atšķirība no tā, ko mēs ražojām dotajā sprintā. Mums arī jāpārliecinās, ka mēs varam ātri rīkoties. Ja jūs ieejat tajā kā datu modelētājs, bet tradicionālajā vārtsarga lomā sakot “Nē, nē, jūs to nevarat izdarīt, mums viss tas ir jādara vispirms”, jūs tiksit izslēgts no komandas, kad jums patiešām būs nepieciešams būt aktīvam dalībniekam visās šajās veiklās attīstības komandās. Tas nozīmē, ka dažas lietas nokrīt no vagona, veicot konkrētu sprintu, un jūs tos uzņemsit vēlākos sprintos.
Piemēram, jūs varat koncentrēties uz datu struktūrām tikai tāpēc, lai attīstītu, teiksim, pasūtījuma ierakstu, par kuru es runāju. Vēlākā sprintā jūs varētu atgriezties un aizpildīt tādus datus kā daži no datu vārdnīcas dokumentācijas ap dažiem no jūsu izveidotajiem artefaktiem. Jūs neaizpildīsit šo definīciju vienā sprintā; jūs pakāpeniski turpināsit strādāt pie saviem nodevumiem, jo būs reizes, kad šo informāciju varēsit aizpildīt, strādājot ar biznesa analītiķiem, kad izstrādātāji ir aizņemti, veidojot lietojumprogrammas, un noturība ap šiem datu krājumiem. Jūs vēlaties atvieglot un nebūt par sašaurinājumu. Ir dažādi veidi, kā mēs strādājam ar izstrādātājiem. Dažās lietās mums ir dizaina modeļi, tāpēc mēs esam pilntiesīgi dalībnieki, tāpēc mums var būt tāds dizaina modelis, kurā mēs teiksim, ka ievietosim to modelī, mēs to izliksim izstrādātāju smilšu kastes datu bāzēs un tad viņi varēs sāciet ar to strādāt un pieprasiet izmaiņas tajā.
Var būt arī citas jomas, pie kurām izstrādātāji strādā, viņi ir ieguvuši kaut ko, pie kā strādā, un prototipē dažas lietas, tāpēc viņi izmēģina dažas lietas savā attīstības vidē. Mēs ņemam to datu bāzi, ar kuru viņi ir strādājuši, iekļaujam to mūsu modelēšanas rīkā, salīdzinām ar mūsu rīcībā esošajiem modeļiem un pēc tam atrisinam un izstumjam atpakaļ uz tiem izmaiņas, lai viņi varētu atjaunot savus kodus, lai viņi ievērotu pareizo datu struktūru ka mums vajag. Tā kā viņi, iespējams, ir izveidojuši dažas lietas, kas mums jau bija citur, tāpēc mēs pārliecināmies, ka viņi strādā ar pareizajiem datu avotiem. Mēs visu laiku to atkārtojam līdz sprintam, lai mēs iegūtu pilnīgu datu piegādi, pilnu dokumentāciju un visu to datu struktūru definīciju, kuras mēs ražojam.
Visveiksmīgākie veiklie projekti, ar kuriem esmu iesaistījies, ņemot vērā ļoti labas piegādes, ir filozofija, kas modelē visas izmaiņas fiziskās datu bāzes pilnajā specifikācijā. Būtībā datu modelis kļūst par izvietotajām datu bāzēm, ar kurām strādājat, lai kaut ko jaunu izveidotu, un tam ir pilnīgas atsauces uz citiem datu krātuvēm, ja patērējam no citām ārpus datu bāzēm. Kā daļu no šī procesa mēs ražojam papildu skriptus, salīdzinot katru reizi ar pilnu paaudzi. Un mēs izmantojam savus dizaina modeļus, lai nodrošinātu mums ātru uzlabojumu attiecībā uz to, kā viss notiek sprintā ar dažādām attīstības komandām, ar kurām mēs strādājam.
Arī sprinta aktivitātēs atkal ir pamats salīdzināšanai / apvienošanai, tāpēc ņemsim vērā ideju modelēt katru izmaiņu. Katru reizi, kad mēs veicam izmaiņas, mēs vēlamies modelēt izmaiņas, un tas, kas ir ļoti svarīgi, kas datu modelēšanai trūka vēl nesen, faktiski, līdz mēs to atkal ieviesām, ir spēja saistīt modelēšanu. uzdevumus un jūsu nodevumus ar lietotāju stāstiem un uzdevumiem, kas faktiski izraisa šīs izmaiņas. Mēs vēlamies, lai mēs varētu pārbaudīt mūsu modeļa izmaiņas, tāpat kā izstrādātāji pārbauda savus kodus, atsaucoties uz mums esošajiem lietotāju stāstiem, lai mēs zinām, kāpēc, pirmkārt, mēs izdarījām izmaiņas, tas ir, ko mēs darām. To darot, mēs ģenerējam savus papildu DDL skriptus un ievietojam tos, lai tos varētu paņemt kopā ar citiem izstrādes nodevumiem un pārbaudīt mūsu veidošanas risinājumā. Atkal mums var būt viens modelis vai darbs ar vairākām komandām. Un, tāpat kā es esmu runājis, dažas lietas rada datu modelētājs, citas lietas izstrādā izstrādātāji, un mēs satiekamies pa vidu, lai nākt klajā ar labāko labāko dizainu, virzīt to uz priekšu un pārliecināties, ka tas ir pareizi izstrādāts mūsu vispārējās datu struktūras. Mums ir jāuztur disciplīna, kā nodrošināt, ka, virzoties uz priekšu, mūsu datu modelī ir visas pareizās konstrukcijas, ieskaitot tādas lietas kā nulles un nevis nulles vērtības, atsauces ierobežojumi, pamatā pārbaudes ierobežojumi, visas tās lietas, par kurām mēs parasti domājam .
Parunāsim tikai par dažiem ekrānuzņēmumiem no dažiem rīkiem, kas mums palīdz to izdarīt. Manuprāt, ir svarīgi, lai būtu šī sadarbības repozitorija, tāpēc tas, ko mēs varam darīt kā datu modelētāji - un tas ir fragments no datu modeļa daļas fonā - ir tad, kad mēs strādājam pie lietām, kuras mēs vēlamies pārliecināties, ka mēs varam strādājiet tikai ar objektiem, kurus mums jāspēj mainīt, veiciet modifikācijas, ģenerējiet mūsu DDL skriptus izmaiņām, kuras esam veikuši, kad atkal pārbaudām lietas. Tātad, ko mēs varam darīt, ir ER Studio, mēs varam pārbaudīt objektus vai objektu grupas, pie kuriem strādāt, mums nav jāpārbauda viss modelis vai apakšmodelis, mēs varam pārbaudīt tikai tās lietas, kas mūs interesē. Tas, ko mēs vēlamies, ir gan izrakstīšanās, gan reģistrēšanās laikā - mēs to darām abpusēji, jo dažādas attīstības komandas strādā atšķirīgi. Mēs vēlamies pārliecināties, ka tas tiek saistīts ar lietotāja stāstu vai uzdevumu, kas nosaka prasības tam, un tas būs tas pats lietotāja stāsts vai uzdevums, kuru izstrādātāji izstrādās un pārbaudīs savu kodu.
Tātad šeit ir ļoti ātrs fragments no pāris ekrāniem vienā no mūsu izmaiņu pārvaldības centriem. Ko tas dara, es šeit detalizēti neiedziļināšos, bet jūs redzat lietotāja stāstu vai uzdevumu un zem katra no tiem, kuriem redzat faktiskos izmaiņu ierakstus, mēs esam izveidojuši atkāpi - mēs esam izveidojuši automatizētu izmaiņu ierakstu, kad mēs veicam reģistrēšanos un izrakstīšanos, un arī šo izmaiņu reģistrā varam ievietot sīkāku aprakstu. Tas ir saistīts ar uzdevumu, katram uzdevumam var būt vairākas izmaiņas, kā jūs varētu gaidīt. Un, iedziļinoties šajā izmaiņu reģistrā, mēs to varam apskatīt un, vēl svarīgāk, redzēt, ko mēs patiesībā mainījām? Šim konkrētajam, tur izceltajam stāstam man bija viena veida izmaiņas, un, kad es apskatīju pašu izmaiņu ierakstu, tas ir identificējis atsevišķos modeļa gabalus, kas ir mainījušies. Es šeit mainīju pāris atribūtus, tos secīgi noteicu, un tas brauciena laikā deva skatus, kuri bija jāmaina un kas bija atkarīgi arī no tiem, lai tie tiktu ģenerēti pieaugošajā DLL. Tas nav tikai modelēšana uz bāzes objektiem, bet arī tāds jaudīgs modelēšanas rīks, kā šis, arī nosaka izmaiņas, kuras jāpārraida caur atkarīgiem objektiem datu bāzē vai arī datu modelī.
Ja mēs strādājam ar izstrādātājiem, un mēs to darām pāris dažādās lietās, tas ir, kaut ko darām viņu smilšu kastē, un mēs vēlamies salīdzināt un redzēt, kur ir atšķirības, mēs izmantojam salīdzināšanas / sapludināšanas iespējas tur, kur labajā un kreisajā pusē pusē. Mēs varam teikt: “Šeit ir mūsu modelis kreisajā pusē, šeit ir viņu datu bāze labajā pusē, parādiet man atšķirības.” Pēc tam mēs varam izvēlēties, kā atrisināt šīs atšķirības, neatkarīgi no tā, vai mēs ievietojam lietas datu bāzē vai arī Datubāzē ir dažas lietas, kuras mēs atkal ievedam modelī. Mēs varam iet divvirzienu virzienā, lai mēs varētu iet abos virzienos, vienlaikus atjauninot gan avotu, gan mērķi, un pēc tam ražot papildu DDL skriptus, lai šīs izmaiņas ieviestu pašā datu bāzes vidē, kas ir ārkārtīgi svarīgi. Ko mēs arī varam darīt, mēs varam arī izmantot šo salīdzināšanas un apvienošanas iespēju jebkurā brīdī. Ja mēs paņemam momentuzņēmumus, mēs vienmēr varam salīdzināt viena sprinta sākumu ar cita sprinta sākumu vai beigas, lai mēs varētu redzēt pilnīgas inkrementālās izmaiņas tam, kas tika veikts noteiktā attīstības sprintā vai vairākās sprintos.
Šis ir ļoti ātrs mainīta skripta piemērs, un ikviens no jums, kas strādājāt ar datu bāzēm, būs redzējis šāda veida lietas. Tas ir tas, ko mēs varam izspiest no koda kā mainītu skriptu, lai mēs pārliecinātos, ka saglabāt lietas šeit. Tas, ko es izvilku no šejienes, lai mazinātu jucekli, ir tas, ko mēs darām arī ar šiem mainīgajiem skriptiem, ja mēs pieņemam, ka arī tabulās ir dati, tāpēc mēs ģenerēsim arī DML, kas iegūs informāciju no pagaidu tabulām un iestumt to atpakaļ arī jaunajās datu struktūrās, tāpēc mēs skatāmies ne tikai uz struktūrām, bet arī uz datiem, kas, iespējams, jau ir ietverti šajās struktūrās.
Ļoti ātri runāsim par automatizētām būvēšanas sistēmām, jo, kad diezgan bieži veicam veiklu projektu, mēs strādājam ar automatizētām būvēšanas sistēmām, kurās mums kopā ir jāreģistrējas dažādos rezultātos, lai pārliecinātos, ka mēs neizjaucam savas konstrukcijas. Ko tas nozīmē, ka mēs sinhronizējam nodevumus, tie izmaiņas skripti, par kuriem es runāju ar DDL skriptu, ir jāreģistrē, vienlaikus ir jāreģistrē arī atbilstošais lietojumprogrammas kods, un daudz izstrādātāju, protams, tagad to izstrādā, nevis tiek darīts ar tiešu SQL pret datu bāzēm un šāda veida lietām. Diezgan bieži mēs izmantojam noturības ietvarus vai ēku datu pakalpojumus. Mums jāpārliecinās, ka šo ietvaru vai pakalpojumu izmaiņas tiek reģistrētas tieši tajā pašā laikā. Dažās organizācijās tie nonāk automatizētā būvēšanas sistēmā, un, ja būvēšana sabojājas, veiklā metodoloģijā, pirms mēs virzāmies uz priekšu, visi uz klāja nostiprināšanas ir jānodarbojas, lai mēs zinātu, ka mums ir funkcionējošs risinājums, pirms dodamies tālāk. Un vienā no projektiem, kurā es iesaistījos, mēs to pievērsām galējībai - ja būvēšanas pārtraukums, kuru mēs faktiski bijām piestiprinājuši daudziem datoriem mūsu rajonā, kur mēs bijām izvietoti ar biznesa lietotājiem, mums bija tikai sarkanas mirgojošas gaismas piemēram, policijas automašīnu augšpusē. Un, ja būve sabojājās, tie sarkanie mirgojošie lukturi sāka nodzēst, un mēs zinājām, ka visas rokas ir uz klāja: salabojiet būvi un tad turpiniet ar to, ko mēs darījām.
Es gribu runāt par citām lietām, un tā ir unikāla ER Studio spēja. Tas patiešām palīdz, kad mēs mēģinām veidot šos artefaktus kā izstrādātājus šīm noturības robežām, mums ir koncepcija, ko sauc par biznesa datu objektiem, un tas, kas mums ļauj tas ir, ja paraugāties uz šo ļoti vienkāršo datu modeli, tas ļauj mums iekapsulēt entītijas vai entītiju grupas tur, kur ir noturības robežas. Kur mēs kā datu modelētājs varam domāt par kaut ko līdzīgu pirkšanas pasūtījuma galvenei un pasūtījuma izlīdzināšanai un citām detalizētām tabulām, kas būtu savienojamas ar to, kā mēs to veidojam, un mūsu datu pakalpojumu izstrādātājiem jāzina, kā lietas pastāv šiem atšķirīgajiem datiem struktūras. Mūsu izstrādātāji domā par tādām lietām kā pirkuma pasūtījums kā vispārējs objekts un kāds ir viņu līgums ar to, kā viņi veido šos konkrētos objektus. Mēs varam pakļaut šo tehnisko detaļu, lai cilvēki, kas veido datu serverus, varētu redzēt, kas atrodas zem tā, un mēs varētu pasargāt citas auditorijas no sarežģītības, lai viņi vienkārši redz dažādus augstākā līmeņa objektus, kas arī ļoti labi palīdz saziņai ar biznesu analītiķi un biznesa ieinteresētās puses, kad mēs runājam arī par dažādu biznesa koncepciju mijiedarbību.
Patīkami arī tas, ka mēs tos konstruktīvi paplašinām un sakļaujam, lai mēs varētu uzturēt sakarus starp augstākas kārtas objektiem, pat ja tie rodas no konstrukcijām, kas atrodas šajos biznesa datu objektos. Tagad kā modelētājs nokļuvu līdz sprinta beigām, sprinta iesaiņojuma beigās man ir daudz lietu, kas man jādara, ko es saucu par savu mājturību nākamajam sprintam. Katru sprintu es izveidoju to, ko es saucu par nosaukto izlaidumu - tas man dod pamatu tam, kas man tagad ir izlaišanas beigās. Tas nozīmē, ka tā ir mana izeja uz priekšu, turpinot, visas šīs bāzes līnijas vai nosauktos laidienus, ko izveidoju un saglabāju savā krātuvē, es varu izmantot, lai veiktu salīdzināšanu / apvienošanu, lai es vienmēr varētu salīdzināt ar jebkuru citu sprinta galu no jebkura cita sprinta, kurš ir ļoti svarīgi zināt, kādas bija jūsu datu modeļa izmaiņas ceļojuma laikā.
Es arī izveidoju delta DDL skriptu, izmantojot salīdzināšanas / apvienošanas vēlreiz no sprinta sākuma līdz beigām. Es, iespējams, esmu pārbaudījis veselu virkni inkrementālu skriptu, bet, ja man tas ir vajadzīgs, man tagad ir skripts, kuru es varu izmantot, lai pieceltos citas smilšu kastes, lai es vienkārši teiktu: tas ir tas, kas mums bija viena sprinta sākumā, push to izmantojot, izveidojiet datu bāzi kā smilšu kasti, lai sāktu ar nākamo sprintu, un mēs varam arī izmantot šīs lietas, lai veiktu tādas darbības kā standup QA gadījumi, un galu galā, protams, mēs vēlamies virzīt mūsu izmaiņas uz ražošanu, lai mums būtu vairākas lietas tajā pašā laikā. Atkal mēs pilnībā piedalāmies sprinta plānošanā un retrospekcijās, retrospektīvas ir patiešām gūtās mācības, un tas ir ārkārtīgi svarīgi, jo veiklības laikā jūs varat nokļūt ļoti ātri, jums jāpārtrauc un jāsvin panākumi, kā tagad. Izdomājiet, kas ir nepareizi, padariet to labāku nākamreiz, bet atzīmējiet arī lietas, kas gāja pareizi, un balstieties uz tām, turpinot virzīties uz priekšu nākamajos sprintos, dodoties uz priekšu.
Tagad es ļoti ātri runāšu par biznesa vērtību. Bija projekts, kurā es iesaistījos pirms daudziem gadiem un kas sākās kā veikls projekts, un tas bija ekstrēms projekts, tāpēc tā bija tīri pašorganizējoša komanda, kur visu darīja tikai izstrādātāji. Īsi sakot, šis projekts apstājās, un viņi secināja, ka arvien vairāk un vairāk reizes tērē konstatēto defektu novēršanai un labošanai, nekā vairāk funkcionēšanas veicināšanai, un faktiski, kad viņi to aplūkoja sadedzināšanas diagrammās viņiem vajadzēja pagarināt projektu par sešiem mēnešiem par milzīgām izmaksām. Kad mēs to apskatījām, veids, kā novērst problēmu, bija izmantot pareizu datu modelēšanas rīku ar kvalificētu datu modelētāju, kas iesaistīts pašā projektā.
Ja aplūkojat šo vertikālo joslu šajā konkrētajā diagrammā, tas parāda kumulatīvos defektus salīdzinājumā ar kumulatīvajiem objektiem, un es runāju par datu objektiem vai konstrukcijām, kas tika izveidotas, piemēram, tabulas ar ierobežojumiem un šāda veida lietas, ja paskatījāties pirms datu modelētāja ieviešanas defektu skaits faktiski pārsniedza un sāka nedaudz palielināties starp faktisko objektu skaitu, kas tika saražoti līdz šim brīdim. Pēc 21. nedēļas, tas ir, kad ienāca datu modelētājs, atkārtoti izveidoja datu modeli, pamatojoties uz to, kas bija nepieciešams, lai labotu vairākas lietas, un pēc tam sāka modelēt kā daļu no projekta komandas, kas turpināja darbu, izmaiņas, kad šis projekts tika virzīts uz priekšu . Un jūs redzējāt ļoti ātru apgrozījumu, ka aptuveni pusotra sprinta laikā mēs redzējām milzīgu to objektu un datu konstrukciju skaita pieaugumu, kas tiek ģenerēti un konstruēti, jo mēs ģenerējām no datu modelēšanas rīka, nevis izstrādātāja nūjas. būvējot tos vidē, un tie bija pareizi, jo viņiem bija atbilstoša atsauces integritāte un citas konstrukcijas, kas tai būtu vajadzīgas. Defektu līmenis salīdzinājumā ar gandrīz līdzeniem. Veicot šo atbilstošo darbību un pārliecinoties, ka datu modelēšana ir pilnībā iesaistīta, projekts tika laicīgi piegādāts ar daudz augstāku kvalitātes līmeni, un faktiski tas vispār nebūtu sasniegts, ja šie pasākumi nebūtu veikti. Tur ir daudz veiklu neveiksmju, ir arī daudz veiklu panākumu, ja jūs iesaistītu īstos cilvēkus pareizajās lomās. Es esmu milzīgs veiklības kā operatīvas disciplīnas piekritējs, taču, pārliecinoties par veikliem centieniem, jums ir jāpārliecinās, ka jums ir visu labo grupu, kuras ir iesaistītas projektā, prasmes.
Rezumējot, datu arhitekti un modelētāji jāiesaista visos attīstības projektos; tie tiešām ir līme, kas satur visu kopā, jo kā datu modelētāji un arhitekti mēs saprotam ne tikai konkrētā attīstības projekta datu konstrukcijas, bet arī to, kur dati pastāv organizācijā un no kurienes mēs varam tos iegūt, un arī to, kā tiks izmantots un izmantots ārpus pašas lietojumprogrammas, pie kuras mēs strādājam. Mēs saprotam sarežģītās datu attiecības, un ir ārkārtīgi svarīgi spēt virzīties uz priekšu un arī no pārvaldības viedokļa, lai kartētu dokumentu un saprastu, kā izskatās jūsu pilna datu ainava.
Tas ir kā ražošana; Es nācu no ražošanas fona. Jūs nevarat pārbaudīt kvalitāti kaut kā beigās - jums ir jāiekļauj kvalitāte projektēšanā jau pašā sākumā un cauri, un datu modelēšana ir veids, kā visu šo kvalitāti kvalitatīvi iekļaut dizainā efektīvā un rentablā veidā. . Un atkal kaut kas, kas jāatceras - un tas nedrīkst būt nemaldīgs, bet tā ir patiesība - lietojumprogrammas nāk un iet, dati ir būtisks korporatīvais īpašums, un tas pārsniedz visas šīs lietojuma robežas. Katru reizi, kad ievietojat lietojumprogrammu, jums, iespējams, tiek lūgts saglabāt datus no citām lietojumprogrammām, kas bija iepriekš, tāpēc mums vienkārši jāatceras, ka tas ir būtisks korporatīvais īpašums, kuru laika gaitā mēs pastāvīgi uzturam.
Un tas arī viss! Turpmāk mēs uzzināsim vairāk jautājumu.
Ēriks Kavanaghs: Labi, labi, ļaujiet man vispirms to pārmest Robinam. Un tad, Dez, es esmu pārliecināts, ka jums ir pāris jautājumu. Atņem to, Robin.
Dr Robin Bloor: Labi. Godīgi sakot, man nekad nav bijis problēmu ar veiklām izstrādes metodēm, un man šķiet, ka tas, ko jūs šeit darāt, ir izcils. Es atceros, ka kaut ko skatījos 80. gados, un tas tiešām norādīja, ka problēma, ar kuru jūs faktiski saskaraties, ņemot vērā projektu, kas ir nekontrolējams, parasti ir tad, ja pieļaujat, ka kļūda pastāv ārpus noteikta posma. To vienkārši kļūst arvien grūtāk labot, ja šis posms nav pareizi izveidots, tāpēc viena no lietām, ko jūs šeit darāt - un es domāju, ka tas ir slaids -, bet viena no lietām, ko jūs šeit darāt nulles sprintā, manuprāt, ir absolūti liela nozīme, jo jūs patiešām cenšaties panākt, lai piegādes tiktu tur piespraustas. Un, ja jums nav piesaistīti piegādes, tad piegādes maina formu.
Tas ir sava veida, mans viedoklis. Tas ir arī mans viedoklis - man patiešām nav nekādu argumentu ar domu, ka jums ir jāsaņem datu modelēšanas tiesības līdz noteiktam detalizācijas līmenim, pirms jūs to darāt cauri. Tas, ko es gribētu, lai jūs izmēģinātu un izdarītu, jo man nebija pilnīgas izpratnes par to, ir tikai jāapraksta viens no šiem projektiem tā lieluma ziņā, kā tas notika, kā tas, kurš, jūs zināt, kur problēmas radušās, vai tās tika atrisinātas? Tā kā es domāju, ka šis slaids ir tā pamatā, un, ja jūs varētu mazliet vairāk par to pastāstīt, es būtu ļoti pateicīgs.
Rons Huizenga: Protams, es izmantošu pāris projektu piemērus. Tas, kas, piemēram, aizgāja no sliedēm, kas tika atjaunots, faktiski iesaistot īstos cilvēkus un veicot datu modelēšanu, un viss tiešām bija veids, kā pārliecināties, ka dizains tiek labāk izprasts un mums acīmredzot ir labāks ieviešanas dizains pa ceļam, to modelējot. Tā kā, modelējot to, jūs zināt, jūs varat ģenerēt savu DDL un visu, kas ir ārpus tā un no rīka, nevis jāturas pie tā, kā parasti dara cilvēki, dodoties tieši datu bāzes vidē. Un tipiskas lietas, kas notiks ar izstrādātājiem, ir tas, ka viņi ieies tur un pateiks, labi, man vajag šīs tabulas. Teiksim, mēs veicam pasūtījumu ierakstus. Tāpēc viņi varētu izveidot pasūtījuma galveni un pasūtījuma detaļu tabulas, kā arī šāda veida lietas. Bet viņi diezgan bieži aizmirsīs vai atstāj novārtā, lai pārliecinātos, ka pastāv ierobežojumi, lai pārstāvētu galvenās ārvalstu attiecības. Iespējams, ka taustiņi nav pareizi. Var būt aizdomas arī par nosaukšanas konvencijām. Es nezinu, cik reizes esmu nokļuvis vidē, kur, piemēram, redzat virkni dažādu tabulu ar dažādiem nosaukumiem, bet tad tabulas kolonnu nosaukumi ir tādi kā ID, nosaukums vai kas cits, tāpēc viņi Mēs patiešām esam zaudējuši kontekstu, nesniedzot tabulu, kas tieši tas ir.
Parasti datu modelēšanas laikā mēs pārliecināsimies, ka visiem artefaktiem, kas tiek ģenerēti arī DDL, mēs piemērojam pareizas nosaukšanas konvencijas. Bet, runājot precīzāk par pašu projektu būtību, es runāju par diezgan lielām iniciatīvām. Viens no tiem bija biznesa pārveidošanas projekts 150 miljonu dolāru vērtībā, kurā mēs aizstājām vairāk nekā duci mantoto sistēmu. Mums vienlaikus darbojās piecas dažādas veiklīgas komandas. Man bija pilna datu arhitektūras komanda, tāpēc manā komandā bija datu modelētāji, kas bija iestrādāti katrā citā lietojumprogrammu apgabala komandā, un mēs strādājām kopā ar iekšējiem biznesa ekspertiem, kuri zināja priekšmetu, bet arī lietotāju stāsti par pašām prasībām. Mums bija biznesa analītiķi katrā no tām komandām, kuras faktiski modelēja biznesa procesu ar darbības diagrammām vai biznesa procesu diagrammām, palīdzot labāk sakārtot lietotāju stāstus ar lietotājiem, pirms viņus patērēja arī pārējā komanda.
Un tad, protams, izstrādātāji, kas izstrādāja lietojumprogrammas kodu virs tā. Un mēs strādājām arī ar, es domāju, ka četri dažādi sistēmu integrācijas pārdevēji veidoja dažādas lietojumprogrammas daļas, kā arī viena komanda veidoja datu pakalpojumus, otra veidoja lietojumprogrammu loģiku vienā apgabalā, otra - kurai bija zināšanas citā biznesa jomā tika veidota lietojumprogrammu loģika šajā jomā. Tātad mums bija visa sadarbība ar cilvēkiem, kas strādāja pie šī projekta. Konkrēti, vienā komandā krastā bija 150 cilvēku, bet komandā - vēl 150 resursi, kas darbojās divu nedēļu sprintā, lai šo lietu izdzenātu. Un lai to izdarītu, jums jāpārliecinās, ka šaujat uz visiem cilindriem, un visi ir labi sinhronizēti attiecībā uz to, kas ir viņu piegādājamie materiāli, un jums bija šīs biežās atiestatīšanas, lai pārliecinātos, ka mēs pabeidzam visu nepieciešamo artefaktu piegādi. katra sprinta beigās.
Dr Robin Bloor: Nu tas ir iespaidīgi. Un tikai nedaudz sīkāk par to - vai šī projekta beigās jūs izveidojāt pilnīgu, ko es sauktu, MDM karti ar visu datu apgabalu?
Rons Huizenga: Mums bija pilnīgs datu modelis, kas tika sadalīts līdz ar sadalīšanos starp visām dažādajām biznesa jomām. Pati datu vārdnīca pilnīgu definīciju ziņā nedaudz pietrūka. Mums bija definēta lielākā daļa tabulu; lielākajā daļā kolonnu bija precīzi noteikts, ko tās nozīmē. Bija daži, kuru tur nebija, un, kas ir interesanti, liela daļa no tiem bija informācijas fragmenti, kas nāca no mantotajām sistēmām, kur pēc paša projekta apjoma beigām tā joprojām tika dokumentēta kā pārnests kopums artefaktus, it kā, ārpus paša projekta, jo tas bija kaut kas tāds, kas bija jāuztur, turpinot organizāciju. Tajā pašā laikā organizācija pieņēma daudz lielāku viedokli par datu pārvaldības nozīmīgumu, jo mēs redzējām daudz trūkumu tajās mantotajās sistēmās un tajos mantotajos datu avotos, kurus mēs centāmies izmantot, jo tie nebija dokumentēti. Daudzos gadījumos mums bija tikai datu bāzes, kuras mums vajadzēja mainīt, lai mēģinātu noskaidrot, kas tur bija un kādai informācijai bija.
Dr Robin Bloor: Tas mani nepārsteidz, ka tas ir tas īpašais aspekts. Datu pārvaldība, sauksim to, ir ļoti moderna problēma, un es domāju, ka tiešām ir daudz darba, kas, teiksim, vēsturiski bija jāpaveic datu pārvaldībai. Tas nekad nebija tāpēc, ka jūs varētu kaut kā dabūt prom no tā nedarīšanas. Bet, tā kā datu resurss tikai auga un auga, galu galā jūs to nevarējāt.
Jebkurā gadījumā es pāriešu uz Dezu, jo es domāju, ka man bija atvēlēts savs laiks. Dez?
Dezs Blanšfīlds: Jā, paldies. Visu šo lietu es vēroju un domāju, ka mēs runājam par to, ka mēs redzam veiklību, kas daudzējādā ziņā tiek izmantota dusmās. Lai gan tam ir negatīvas konotācijas; Es to domāju pozitīvā veidā. Vai jūs varētu vienkārši sniegt mums scenāriju, es domāju, ka ir divas vietas, kur es redzu, ka tas ir ideāls komplekts: viens ir jauni projekti, kas vienkārši jādara no pirmās dienas, bet es domāju, ka vienmēr, pēc manas pieredzes, tas bieži notiek gadījums, kad projekti kļūst pietiekami lieli, ka tas ir vajadzīgs daudzos veidos, starp abām pasaulēm ir jāpieliek interesants izaicinājums, vai ne? Vai varat sniegt mums jebkāda veida ieskatu dažos veiksmes stāstos, kurus esat redzējis organizācijā, ir kļuvis skaidrs, ka viņiem ir neliela divu pasauļu sadursme un jūs esat spējuši veiksmīgi Vai tas ir vietā un apvieno lielus projektus tur, kur viņi varētu būt gājuši uz sliedēm? Es zinu, ka tas ir ļoti plašs jautājums, bet es tikai domāju, vai ir kāds konkrēts gadījuma pētījums, kuru jūs varētu norādīt uz to, kur jūs teicāt, jūs zināt, mēs to visu ievietojam vietā, un tas ir saliedējis visu attīstības komandu datu komanda un mēs esam kaut kā uzrunājuši kaut ko tādu, kas, iespējams, citādi būtu nogrimis laivā?
Rons Huizenga: Protams, un patiesībā tas projekts, kas notika kā cauruļvada projekts, bija tas, uz kuru es atsaucos un kur parādīju šo diagrammu ar defektiem pirms un pēc datu modelētāja iesaistīšanas. Diezgan bieži, un pastāv aizspriedumaini priekšstati, it īpaši, ja lietas tiek virzītas tur, kur tas tiek darīts tikai no attīstības viedokļa, un tikai šie izstrādātāji ir iesaistīti šajos veiklīgajos projektos, lai piegādātu programmas. Tātad, kas tur notika, protams, ir tas, ka viņi patiešām izkāpa no sliedēm, un jo īpaši viņu datu artefakti vai arī viņu ražotie datu noieta rādītāji kvalitātes ziņā atpalika no vietas un patiesībā attiecas uz lietām kopumā. Un diezgan bieži pastāv nepareizs uzskats, ka datu modelētāji palēninās projektu izstrādi, un tas notiks, ja datu modelētājam nebūs pareizas attieksmes. Kā es saku, jums ir jāzaudē - dažreiz ir datu modelētāji, kuriem ir tāda tradicionālā vārtsarga attieksme, kad “Mēs esam šeit, lai kontrolētu, kā izskatās datu struktūras”, un šai mentalitātei ir jāzūd. Ikvienam, kas ir iesaistīts ātrdarbīgā izstrādē, un jo īpaši datu modelētājam ir jāuzņemas koordinatora loma, lai patiešām palīdzētu komandām virzīties uz priekšu. Un labākais veids, kā to parādīt, ir ļoti ātri parādīt komandām, cik produktīvas tās var būt, vispirms modelējot izmaiņas. Un atkal tas ir iemesls, kāpēc es runāju par sadarbību.
Ir dažas lietas, kuras mēs vispirms varam modelēt un ģenerēt DDL, lai izstumtu tos izstrādātājiem. Mēs arī vēlamies pārliecināties, ka viņi nejūtas kā ierobežoti. Tātad, ja ir lietas, pie kurām viņi strādā, ļaujiet viņiem turpināt strādāt attīstības smilšu kastēs, jo tieši tur izstrādātāji strādā pie sava galddatora vai citām datu bāzēm, lai veiktu dažas izmaiņas, kad viņi testē lietas. Un sadarbojieties ar viņiem un sakiet: “Labi, strādājiet ar to.” Mēs to ienesīsim rīkā, mēs to izlabosim, un pēc tam mēs to virzīsim uz priekšu un sniegsim jums skriptus, kurus varat izmantot, lai atjauninātu datu bāzēm, lai tās atjauninātu līdz faktiskajam, par kuru sankcionēts, ražošanas skatījums uz to, kā mēs turpinātu virzīties uz priekšu. Un jūs varat to ātri mainīt. Es atklāju, ka manas dienas bija piepildītas, un es vienkārši eju turp un atpakaļ, iterējoties ar dažādām attīstības komandām, apskatot izmaiņas, salīdzinot, ģenerējot skriptus, panākot to izpildi, un man bija diezgan viegli sekot līdzi četrām attīstības komandām, kad mēs sasniegusi impulsu.
Dezs Blanšfīlds: Viena no lietām, kas man ienāk prātā, ir tā, ka, jūs zināt, daudzas sarunas, kuras man ikdienā notiek, ir par šo kravas vilcienu, kas ierodas pie mums, sava veida, no mašīnas uz -mašīna un IoT. Un, ja mēs domājam, ka tagad esam ieguvuši daudz datu par mūsu pašreizējo vidi uzņēmējdarbībā, tad, ja mēs uz brīdi atceramies vienradzus, mēs zinām, ka Googles un Facebooks un Ubers rīcībā ir datu petabāti, bet tradicionālajā uzņēmumā mēs runājam par joprojām simtiem terabaitu un lielu datu daudzumu. Bet tur, manuprāt, ir šis kravas vilciens, kas ierodas organizācijās, un doktors Robins Bloors uz to jau minēja IoT. Jūs zināt, mums ir daudz tīmekļa trafika, mums ir sociāla trafiks, tagad mums ir mobilitāte un mobilās ierīces, mākonis ir sava veida sprādzis, bet tagad mums ir vieda infrastruktūra, viedas pilsētas un tur ir visa šī datu pasaule, kas tikko ir eksplodējusi.
Ikdienas organizācijai vidēja vai liela organizācija, kas tur sēž un redz šo sāpju pasauli, nonāk pie viņiem un pat nedomā par tūlītēju plānu, kas ir daži no pārņemtajiem gadījumiem, tikai dažiem teikumiem, kurus jūs varētu ievietot viņiem par to, kad un kur viņiem ir jāsāk sarunvalodā domāt par dažu no šīm metodoloģijām ieviešanu. Cik agri viņiem ir jāsāk plānot gandrīz sēdēt un pievērst uzmanību un teikt, ka ir īstais laiks, lai iegūtu dažus instrumentus un apmācītu komandu, kā arī runātu par šo problēmu? Cik vēlu stāstā ir par vēlu vai kad ir par agru? Kā tas izskatās dažās organizācijās, kuras jūs redzat?
Rons Huizenga: Es teiktu lielākajai daļai organizāciju, ka, ja tās to vēl nav izdarījušas un pielāgojušas datu modelēšanu un datu arhitektūru ar tādiem jaudīgiem rīkiem kā šis, laiks, kas viņiem to jādara, ir vakardiena. Tā kā ir interesanti, ka pat šodien, kad skatāties uz organizāciju datiem, mūsu organizācijās ir tik daudz datu, un, vispārīgi runājot, balstoties uz dažām aptaujām, kuras mēs esam redzējuši, mēs efektīvi izmantojam mazāk nekā piecus procentus no šiem datiem kad mēs skatāmies pāri organizācijām. Un, izmantojot IoT vai pat NoSQL, lielie dati - pat ja tie nav tikai IoT, bet tikai lieli dati kopumā - kur mēs tagad sākam patērēt vēl vairāk informācijas, kuras izcelsme ir ārpus mūsu organizācijām, šī problēma kļūst arvien lielāka. visu laiku. Un vienīgais veids, kā mums ir iespējas tikt galā, ir palīdzēt mums saprast, par ko ir šie dati.
Tātad, lietošanas gadījums ir nedaudz atšķirīgs. Tas, kas mums šķiet, ir, aplūkojot šos datus, tos tverot, mums tie ir jāmaina, jāredz, kas tajos atrodas, vai tie atrodas mūsu datu ezeros vai pat mūsu iekšējās datu bāzēs, sintezē to, kas dati ir, lietojiet tam nozīmes un definīcijas, lai mēs saprastu, kas ir dati. Tā kā, kamēr mēs saprotam, kas tas ir, mēs nevaram nodrošināt, ka mēs to pareizi vai atbilstoši izmantojam. Tāpēc mums patiešām ir jākontrolē, kādi ir šie dati. Otrkārt, nedariet to, jo, ņemot vērā visu šo ārējo datu patēriņu, varat pārliecināties, ka jums ir lietošanas gadījums, kas atbalsta šo ārējo datu patēriņu. Koncentrējieties uz nepieciešamajām lietām, nevis tikai mēģiniet piesaistīt un izmantot lietas, kas jums vēlāk varētu būt vajadzīgas. Vispirms koncentrējieties uz svarīgām lietām, un, kad jūs to darīsit, tad jūs patērēsit un mēģināsit saprast citu informāciju no malas.
Lielisks piemērs tam ir tas, ka es zinu, ka mēs runājam par IoT un sensoriem, bet tāda paša veida problēmas jau daudzus gadus ir bijušas daudzās organizācijās, pat pirms IoT. Ikvienam, kam ir ražošanas kontroles sistēma, neatkarīgi no tā, vai tas ir cauruļvadu uzņēmums, ražojošs uzņēmums, jebkuram procesam balstītam uzņēmumam, kam ir lietas, kur viņi daudz automatizē ar vadības ierīcēm un izmanto datu plūsmas un tamlīdzīgas lietas, ir Šīs datu sērijas, kuras viņi mēģina izdzert, lai izdomātu, kādi ir notikumi, kas notikuši manā ražošanas iekārtā, lai signalizētu - kas un kad noticis? Starp šo milzīgo datu plūsmu ir tikai konkrēta informācija vai tagi, kas viņus interesē un kas viņiem ir nepieciešams atsijāt, sintezēt, modelēt un saprast. Un viņi var ignorēt pārējo daļu, līdz ir pienācis laiks to patiesi saprast, un tad viņi var paplašināt savu darbības jomu, lai arvien vairāk un vairāk no tā iekļautu darbības jomā, ja tam ir jēga.
Dezs Blanšfīlds: Patiešām. Ir viens jautājums, kuru es ņemšu vērā, un tas nāca no kunga, vārdā Ēriks, un mēs par to esam runājuši privāti. Es tikko prasīju viņa atļauju, ko viņš ir devis, lai pajautāju to no jums. Tā kā tas labi noved pie tā, ka tikai jāapņemas, jo mēs tagad ar laiku dodamies mazliet atpakaļ, un es atdošu Ērikam. Bet cita Ērika jautājums bija, vai ir pamatoti uzskatīt, ka jaunizveidoto uzņēmumu īpašnieki pārzina un izprot unikālos izaicinājumus, kas saistīti ar terminoloģijas modelēšanu, un tā, vai arī tas būtu jānodod kādam citam interpretācijai? Tātad, citiem vārdiem sakot, vai startup jābūt spējīgam un gatavam, ar vēlmi un spējīgu uz to koncentrēties un to sasniegt? Vai arī tas ir kaut kas tāds, ko viņi, iespējams, vajadzētu iepirkties un iesaistīt ekspertus?
Rons Huizenga: Es domāju, ka īsā atbilde ir, ka tas tiešām ir atkarīgs. Ja tas ir startaps, kurā nav neviena uzņēmuma, kas ir datu arhitekts vai modelētājs un kurš patiešām saprot datu bāzi, tad ātrākais veids, kā sākt, ir dot kādu ar konsultantu pieredzi, kurš ļoti labi pārzina šo vietu un var iegūt viņi iet. Jo tas, ko jūs atradīsit - un patiesībā es to izdarīju daudzos pasākumos, ko es izdarīju, pirms es pārgāju uz tumšo pusi produktu pārvaldībā - vai es ieeju organizācijās kā konsultants, vadīšu viņu datu arhitektūras komandas, lai viņi varētu sava veida pārorientēties un apmācīt savus cilvēkus, kā rīkoties šāda veida lietās, lai viņi to izturētu un turpinātu misiju. Un tad es turpinātu savu nākamo saderināšanos, ja tam būtu jēga. Ir daudz cilvēku, kas to dara, kuriem ir ļoti laba datu pieredze, kas viņiem var palīdzēt.
Dezs Blanšfīlds: Tas ir lielisks līdzņemšanas punkts, un es tam pilnībā piekrītu, un esmu pārliecināts, ka arī Dr Robins Bloors to darīs. Īpaši jaundibinot, jūs esat koncentrējies uz to, ka esat MVU, jo īpaši vērtējams piedāvājums, kuru vēlaties izveidot kā daļu no sava sākuma biznesa, un jums, iespējams, nevajadzētu būt ekspertam par visu, tik lielisks padoms. Bet liels paldies par fantastisko prezentāciju. Patiešām lieliskas atbildes un jautājumi. Ēriks, es došos pie jums, jo es zinu, ka laika gaitā esam aizgājuši, iespējams, desmit minūtes, un es zinu, ka jums patīk turēties tuvu mūsu laika logiem.
Ēriks Kavanaghs: Tas ir labi. Mums ir vismaz pāris labu jautājumu. Ļaujiet man to pārmest jums. Es domāju, ka jūs esat atbildējis uz dažiem citiem. Bet ļoti interesants novērojums un jautājums no viena dalībnieka, kurš raksta, dažreiz veikliem projektiem ir tāds, ka datu modelētājam nav visa ilgtermiņa attēla, tāpēc viņi noslēdz kaut ko projektēt vienā sprintā un pēc tam ir jāpārprojektē sprintā trīs vai četri. Vai tas nešķiet neproduktīvs? Kā jūs varat izvairīties no šāda veida lietām?
Rons Huizenga: Tas ir tikai veikls raksturs, ka dotajā sprintā jūs nesaņemat visu absolūti pareizi. Tas faktiski ir daļa no veiklības principa: strādājiet ar to - jūs darīsit prototipēšanu, kur strādājat ar kodu noteiktā sprintā, un jūs to pilnveidosit. Un šī procesa sastāvdaļa ir tā, kā jūs piegādājat lietas, ko gala lietotājs to redz un saka: “Jā, tas ir tuvu, bet man tiešām ir nepieciešams, lai tas arī izdarītu šo mazliet papildus”. Tā, ka tas ietekmē ne tikai funkcionālo dizainu paša koda versiju, bet diezgan bieži mums ir jāmaina vai jāpievieno vairāk datu struktūras zem šīm dažām lietām, lai sniegtu to, ko lietotājs vēlas. Tas viss ir godīga spēle, un tāpēc jūs patiešām vēlaties izmantot lieljaudas rīkus, jo ļoti ātri varat modelēt un veikt šīs izmaiņas modelēšanas rīkā un pēc tam ģenerēt DDL datu bāzei, kuru izstrādātāji pēc tam var strādāt, lai piegādātu šo mainīt vēl ātrāk. Jūs glābjat viņus no tā, ka tie ir jādara, piemēram, ar roku, datu struktūru kodēšanai un ļaujiet viņiem koncentrēties uz programmēšanas vai lietojumprogrammu loģiku, kuru viņi vislabāk pārzina.
Ēriks Kavanaghs: Tam ir pilnīga jēga. Mums bija pāris citu cilvēku, kas tikai uzdeva konkrētus jautājumus par to, kā tas viss saistās ar rīku. Es zinu, ka jūs kādu laiku esat pavadījis, apskatot piemērus, un jūs esat parādījis dažus ekrānuzņēmumus par to, kā jūs faktiski izlaižat šo saturu. Runājot par visu sprinta procesu, cik bieži jūs redzat, ka, spēlējoties organizācijās, salīdzinot ar to, cik bieži jūs redzat tradicionālākus procesus, kur lietas vienkārši, sava veida, aiziet garām un prasa vairāk laika? Cik izplatīta no jūsu skatpunkta ir sprinta stila pieeja?
Rons Huizenga: Es domāju, ka mēs to redzam arvien vairāk un vairāk. Es zinu, ka, es teiktu, iespējams, jo īpaši pēdējo 15 gadu laikā, daudz vairāk esmu redzējis tādu cilvēku adopciju, kuri atzīst, ka viņiem patiešām ir jāapņemas ātrāk piegādāt. Tāpēc esmu redzējis, ka arvien vairāk organizāciju pāriet uz veiklo bandwagon. Ne vienmēr pilnībā; viņi var sākt ar dažiem izmēģinājuma projektiem, lai pierādītu, ka tas darbojas, taču ir daži projekti, kas joprojām ir ļoti tradicionāli, un tie tomēr ievēro ūdenskrituma metodi. Tagad, protams, labā ziņa ir tā, ka rīki ļoti labi darbojas arī tajās organizācijās, kā arī šāda veida metodikām, taču mums ir rīka pielāgojamība, lai tiem, kas lēkā uz kuģa, būtu rīku komplekts viņu pirkstu gali. Piemēram, salīdzināšana un apvienošana, piemēram, apgrieztās inženierijas iespējas, lai viņi varētu redzēt, kādi ir esošie datu avoti, lai viņi patiesībā varētu ļoti ātri salīdzināt un ģenerēt papildu DDL skriptus. Un, kad viņi sāk to aptvert un redz, ka viņiem var būt produktivitāte, vēl vairāk palielinās tieksme uzņemties veiklību.
Ēriks Kavanaghs: Nu, šī ir lieliska lieta, ļaudis. Tikko tērzēšanas logā ievietoju saiti uz slaidiem, tāpēc pārbaudiet to; tas ir mazliet par jums. Mums visas šīs tīmekļa pārraides ir paredzētas vēlākai apskatei. Jūtieties brīvi dalīties tajos ar draugiem un kolēģiem. Un Ron, liels paldies par jūsu šodienas laiku, jums vienmēr ir patīkami būt izstādē - īstam jomas ekspertam un ir acīmredzami, ka jūs zināt savas lietas. Tātad, paldies jums un paldies IDERA un, protams, Dez un mūsu pašu Robin Bloor.
Un ar to mēs jūs atvadīsimies, ļaudis. Paldies vēlreiz par jūsu veltīto laiku un uzmanību. Mēs novērtējam, ka jūs uzlīmējat 75 minūtes, tā ir diezgan laba zīme. Labi šova puiši, mēs ar jums sarunāsimies nākamreiz. Labdien!
