Izņemšana: 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. Tās trešdiena plkst. 4:00 EST. Tas nozīmē savu laiku karstajām tehnoloģijām. Jā, patiesi. Mans vārds ir Ēriks Kavanaghs, es būšu jūsu saimnieks.
Mūsdienu tēmai tā ir veca, bet laba. Katru dienu tas kļūst arvien labāk, jo tas, veidojot mūsu datu pārvaldības pasauli “Datu modelēšana jutīgā vidē”, patiesībā ir slaids par jums, mani uzlasa vietnē @eric_kavanagh. Mums tas tiešām būtu jāliek uz šī slaida. Man par to ir jātiek.
Tāpēc gadi ir karsti. 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 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ājām. Mēs centīsimies uzzināt, 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, kurš zvana no Sidnejas, Austrālijas, un Rons Huizenga, IDERA vecākais produktu menedžeris - mans ilggadējais draugs, izcils runātājs šajā telpā, zina savas lietas, tāpēc nebaidieties, jautājiet viņam grūti jautājumi, ļaudis, cietie. 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ījā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 modelēšanai vispārēju pārskatu, bet tas ir reāli, un tas tagad kļūst acīmredzams.
Jums, jūs zināt, ir lielo datu realitāte, mums ir vairāk datu, vairāk datu avotu, mēs esam ieguvuši datu plūsmas, kas ir ievadījušas vienādojumu pēdējos trīs vai četros gados un sāk iegūt lielāku tās daļu, un ir lielāka vajadzība izprast datus un palielināts izmaiņu ātrums, jo vairāk datu tiek pievienoti, kā arī vairāk datu struktūru tiek izmantotas.
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, redzat, ka ir dati patiesi miera stāvoklī, tādā nozīmē, ka tas daudz nemudina. Un tad dati, straumes un viss jūsu darījuma lietojumprogramma, kā arī mūsdienās jums ir notikumi, notikumu datu plūsmas, kas notiek lietojumprogrammās un kas, iespējams, ir vajadzīgi, un mūsdienās ar lambda arhitektūru, par kuru vienmēr runājam, patiesi ietekmē tikai viss datu lauks.
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 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ā 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 strādājam ar datiem, cilvēka domas un cilvēku valoda ir ļoti sarežģīta, un tā pati sevi viegli neizpauž datos. 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 tie ir savienoti ar citiem datus, pieprasa, lai mēs to modelētu. Tas nav pietiekami labs, lai vienkārši ierakstītu lietu 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 rastos 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 patiešām grūti mainīt. Tas ir pietiekami viegli, lai ierakstu metadatus uztvertu un varētu tos iegūt no nozīmju virknes, taču tas jums nepasaka ierakstu struktūru vai to, ko ieraksti nozīmē, vai ieraksta negatīvie elementi.
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 mazliet līdzinās tam, ka pasaulei pievieno ne tikai vairāk lietu gadījumu, kas atbilst datu ierakstiem, bet faktiski pasaulei piešķir lielāku nozīmi, uztverot datus par vairāk un vairāk lietām. Tā kļūst arvien sarežģītāka un jūtama, kas mums ir jāsaprot.
Teorētiski tas ir 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 pastāvīga darbība - tai jābūt nepārtrauktai darbībai ikvienā vidē, kurā tie pastāv. Par laimi, ir ļoti daudz vides, kurās patiesībā tā 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ām ierīcēm varam saprast vairāk, nekā mēs pieraduši, kaut arī tā ieviesa jaunas dimensijas: atrašanās vietas dimensiju ar mobilo. Kad esat nokļuvis IoT, mēs apskatījām ārkārtas datu problēmas, kuras mums nekad agrāk nebija jādara, un mums tā vai citādi ir pareizi jāsaprot, ko mēs esam ieguvuši, kā tieši to varam apkopot, ko mēs varam darīt attiecībā uz jēgas iegūšanu no apkopošanas un, protams, to, ko mēs ar to varam paveikt, kad esam to apstrādājuši.
Es domāju, ka tas ir pietiekami pateikts. Es došos tālāk uz Dezu Blanšfīldu, pateikšu 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 piezvanījāt agri, jūs, iespējams, noķērāt veselu virkni lielisku dārgakmeņu. Viena no paņemšanām, un es nevēlos nozagt šī konkrētā pērkona negaisu, 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 nenoķērāt, bija tikai datu brauciena tēma. , un tas pārsteidza, ka es to faktiski pierakstīju, domājot par braucienu, kurā dati notiek dažādos laikos paaudzes laikā - gadu, mēnešus, nedēļu, dienu, stundu, minūti, sekundi - un konus ap datiem tiek novietoti tajā kon . Neatkarīgi no tā, vai esmu izstrādātājs, kurš izmanto kodu, vai arī es esmu datu speciālists, un 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.
Tā ir interesanta neliela ņemšanās, tikai jāatzīmē, bet jebkurā gadījumā ļ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ā. Mūsdienās, kad mēs runājam par datu dizainu, mēs runājam par mūsdienīgu, veiklu datu dizainu, un es uzskatu, ka tas nebija tik sen, ka 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 ne tikai tas ir mainījies, bet arī jāmaina; 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 baru, kurš izlec no lidmašīnas un darbojas kā komanda, lai parādī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, un viņi izstrādāja 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 varam ņemt informāciju no vienas uzņēmējdarbības daļas un nodot to citai no cilvēkiem, kuriem ir ideja, bet kuri neveido kodu vai neveido datu bāzes un infrastruktūras, bet gan 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 skuvekļu 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, kurus ieguvu šeit, pie sienas un tāfeles labajā pusē, 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 to dara: tiek ņemts saraksts ar lietām, kuras organizācija vēlas darīt, palaižot cauri virknei lietu, kuras mēs saucam par ss, kas ir sadalītas 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, izmantojot apžēlošanu, izlīdzināja.
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ā rada pastāvīgu neapmierinātību, jo es uzskatu, ka datu speciālistiem tagad ir jābūt - nevis jābūt - cieši iesaistītiem visos projekta piegādes komponentos, jo īpaši attīstībā. Lai mēs to nedarītu, tad mēs patiešām nedodam sev vislabākās izredzes uz labu iznākumu. Bieži vien mums 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āzes dizaina modelēšanā, modeļa izstrāde ir tikai pamatinformācija guru inženierijai par to, kā dati nonāk un kā notiek brauciena organizācija un kādam tam vajadzētu būt vai nevajadzētu izskatīties, vai, bez šaubām, tas, kas tiek patērēts un saprot, ka tas parasti tiek iegūts vietējās prasmēs, kas programmatūras izstrādātājiem tiek noteiktas. Un daži no kopīgajiem izaicinājumiem, ar kuriem mēs sastopamies, ietverot tādus kā vienkārša pamata datu bāzes veidošanas un uzturēšanas un pārvaldības pati 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 būtu jāredz visi tabulas ieraksti vai arī viņiem vajadzētu redzēt tikai adresi, vārdu un uzvārdu, ko jūs ierakstāt ziņojumā? 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ās draudzenes IDERA un dzirdēšu par šo rīku un kā tas risina šīs lietas.
Rons Huizenga: Liels paldies un paldies gan Robinam, gan Dezam par to, ka viņi patiešām labi uzstāja skatuvi, un jūs redzēsit nedaudz pārklāšanos pāris lietās, par kurām esmu runājis. Bet tie patiešām ir izveidojuši ļoti stabilu pamatu dažiem 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 iespējām, kādas rīkos 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īkā sīkumā; mums vienkārši bija patiešām labs pārskats par to, kas tas ir. Es runāšu 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 s laikā, kādi ir darbības veidi, kas viņiem būtu 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. Pēc tam mēs apkoposim vēl dažus punktus un papildus tam būsim 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, par biznesa arhitektu, kur mēs veicam procesu modelēšanu un programmatūras arhitektu, 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 pievērsīšos, būs dažas lietas, kuras mēs redzēsim no Data Architect, un tāpēc, ka ir ļoti svarīgi, lai mums būtu sadarbība, izmantojot uz krātuvi balstītus aspektus. Ī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 parunāsim par veiklo datu modelētāju. Kā mēs jau esam iezīmējušies, 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 vairākas 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. Es atklāju, ka spēcīgākās ir tās komandas, kuras veido cilvēki no dažāda pamata. 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 ietvaros, 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 ne tikai varam aplūkot datus mūsu veidotās lietojumprogrammas konsoles ietvaros. 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 atkārtotam darba stilam, kurā mēs pakāpeniski attīstām tā komponentus un laika gaitā to pilnveidojam, kur mēs ražojam izmantojamu kodu vai izmantojamus artefaktus, es teikšu, ka katram s. 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 veikls datu modelētājs 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 izdarīšu ļoti ātri, jo mēs to jau apskatījām iepriekšējā sadaļā. Veiklības patiesais 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 s, atkarībā no organizācijas, ir ļoti izplatīti. Katru dienu arī pārskatīsim un izskatīsim tikšanās, lai likvidētu bloķētājus un pārliecinātos, ka mēs virzāmies uz priekšu visiem, neapturot apturēšanu dažādās jomās, kad mēs iet. Un šajos ss mēs vēlamies pārliecināties, ka mēs ražojam izmantojamus nodevumus kā daļu no katra s.
Tikai nedaudz savādāk, paplašinot to, scrum ir metodoloģija, par kuru š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 ir izstrādājumu neizpilde, un tad ir iztrūkums. Tātad mums ir vispārējs kavējums, ka katra atkārtojuma sākumā mēs domājam teikt: “Ko mēs veidosim?”, Un tas tiek darīts plānošanas sanāksmē. Pēc tam mēs sadalām uzdevumus, kas ir saistīti ar to, un mēs veicam vienas līdz četru nedēļu laikā 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, nevis iet dažus mēnešus pa ceļu un uzzina, ka drīzumā nāksies saskarties un jums ir jāpagarina projekta grafiks. Un ļoti svarīgi, ka tā ir daļa no visām komandām, tā ir pārskatīšana nobeigumā un 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ā uzlabot nākamreiz cauri.
Runājot par nodevām, tas būtībā ir slaids, kurā apkopoti tipiski lietu veidi, kas notiek ss. 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 noformējums vai datu modelis, kā ir ar biznesa glosārijiem, lai biznesa nozīmi mēs varētu saistīt ar visiem mūsu radītajiem artefaktiem? Tā kā mums ir jāsniedz tie izmantojamie nodevumi katrā s.
Daži cilvēki teiks, ka mums ir jāsagatavo izmantojams kods katras s beigās. 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 nullei, kur mēs koncentrējamies tikai uz stāvēšanu, 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 mazliet sagatavošanās laika, tāpēc diezgan bieži mums būs s nulle vai pat s nulle un viens. Varētu būt nedaudz sākuma posms, pirms mēs piegādājam risinājumu pilnam lidojumam.
Par šo modeli īsumā runāsim. 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 noteiktas 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ē kā organizācijas perspektīvu, kādas ir fiziskās konstrukcijas attiecībā uz to, kā mēs patiesībā definējam datus, kādas ir to attiecības jūsu datu bāzes, jūsu 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.
Es 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ātuves, 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 šīs dažādās ss. Pirmkārt, pilntiesīgs plānošanas sesiju dalībnieks, kurā mēs uzņemamies lietotāju stāstus, apņemamies to, ko mēs šajos plānos piegādāsim, un izdomāsim, 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ī šajos dažādajos apakšmodeļu skatījumos, 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 darām vienā s, taču 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 pamatprincipiem, kurus mēs vēlamies iegūt, vienmēr ir jābūt sākotnējam stāvoklim, pie kura mēs varam atgriezties, jo viena no lietām, kas mums jāspēj darīt, ir, neatkarīgi no tā, vai tā ir pašā sākumā vai beigās. vairākas ss, mēs vēlamies zināt, kur mēs sākām, un vienmēr ir pamats, lai zinātu, kas bija delta vai atšķirība no tā, ko mēs ražojām dotajā s. 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 noteiktus s, un jūs tos paņemat vēlāk ss.
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ā laikā jūs varat atgriezties un aizpildīt datus, piemēram, dažus no datu vārdnīcas dokumentācijas, kas saistīti ar dažiem no jūsu izveidotajiem artefaktiem. Jūs neaizpildīsit šo definīciju vienā vienā; 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 mēs saņemam pilnu 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 dotu mums ātru uzlabojumu attiecībā uz to, kā viss notiek ar dažādām attīstības komandām, ar kurām mēs strādājam.
Arī s 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, būtībā 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 tagad uzņemam momentuzņēmumus, mēs vienmēr varam salīdzināt viena sākuma sākumu ar citas sākumu vai beigas, lai mēs varētu redzēt pilnīgas inkrementālas izmaiņas tajā, kas tika veikts noteiktā attīstībā vai virknē ss.
Š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ē dažādi nodevumi, 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 nedara. 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šoto 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 īpašos objektus. Mēs varam pakļaut šo tehnisko detaļu tā, 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ļūstiet s beigās, pēc s iesaiņošanas man ir daudz lietu, kas man jādara, ko es saucu par savu mājturību nākamajiem s. Katru reizi es izveidoju to, ko es saucu par nosaukto izlaidumu - tas man dod pamatu tam, kas man tagad ir izlaišanas beigās. Tātad tas nozīmē, ka tā ir mana izejas pozīcija, kas iet uz priekšu, visas šīs bāzes līnijas vai nosauktos laidienus, kurus 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 citu galu, kuru 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 atkal salīdzināšanu / apvienošanu no s 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 varu izvietot, lai pieceltos citas smilšu kastes, lai es vienkārši varu pateikt, ka tas bija tas, kas mums bija viena s sākumā, spiediet to izmantojot, izveidojiet datu bāzi kā smilšu kasti, lai sāktu ar nākamajām, 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 ražošanā, lai mums būtu vairākas lietas tajā pašā laikā. Atkal mēs pilnībā piedalāmies plānošanā un retrospektīvā, retrospektīvas ir patiešām gūtās atziņas, 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ākamajā ss, ejot 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 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 ēkas viņus vidē, un viņi bija pareizi, jo viņiem bija pareiza 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īvās disciplīnas piekritējs, taču, pārliecinoties par veikliem centieniem, jums ir jāpārliecinās, ka jums ir visu labo komandu, 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 attīstības 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 n nulles vērtībā, manuprāt, ir absolūti svarīgi, jo jūs patiešām cenšaties tur iegūtos materiālus. Un, ja jums nav pievienoti piegādes materiāli, tad piegādes maina formu.
Tāds ir mans viedoklis. Tas ir arī mans viedoklis - man patiešām nav nekādu argumentu ar domu, ka jums vajadzēja iegūt datu modelēšanas tiesības līdz noteiktam detalizācijas līmenim, pirms sākat darbu. 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 dažus 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 tur ieies, un viņi atbildēs: labi, man vajag šīs tabulas. Pieņemsim, ka 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 aizmirst vai novārtā atstāj pārliecību, 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 Es tiešām esmu pazaudējis saprašanu bez tabulas par to, kas 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, kas 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 laikā, 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. katras s 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 mēģinājām 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, 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 būtu bijis jāpaveic datu pārvaldības jomā. 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 veltīts laiks. Dez?
Dez Blanchfield: Jā, paldies. Visu šo lietu es vēroju un domāju, ka mēs runājam par to, ka redzam, ka veikls tiek izmantots daudzos 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ā viens projekts, kas notika kā cauruļvada projekts, bija tas, uz kuru es atsaucos, 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 šajos veiklīgajos projektos ir iesaistīti izstrādātāji. 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 neatbilda kvalitātes rādītājiem un patiešām risina lietas 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ājiem 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ņiem nav justies kā viņus ierobežo. 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.
Dez Blanchfield: Viena no lietām, kas man ienāk prātā, ir tā, ka, jūs zināt, daudzas man ikdienā notiekošās sarunas ir par šo kravas vilcienu, kas ierodas pie mums, sava veida mašīnām-mašīnām 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 zināt, ja mēs uz brīdi atstāsim vienradzus malā, kur mēs zinām, ka Googles un s, kā arī Ubers ir datu petabāti, bet tradicionālajā uzņēmumā mēs runājam par joprojām simtiem terabaitu un lielu datu daudzumu. Bet, manuprāt, šis kravas vilciens ierodas organizācijās, un Dr. 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: Lielākajai daļai organizāciju es teiktu, 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, laiks, kas tām 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 tas, kad mēs skatāmies uz šiem datiem, tie tiek notverti, 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ē 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 pārliecināties, ka mēs to izmantojam pareizi vai atbilstoši. Tāpēc mums patiešām ir jākontrolē, kādi ir šie dati.Otrkārt, nedariet to tāpēc, ka, ņ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, varēsit patērēt un mēģināt 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.
Dez Blanchfield: Tā tas tiešām ir. Ir viens jautājums, kuru es ņemšu vērā, un to uzdeva kungs ar nosaukumu Ēriks, un mēs par to esam runājuši privāti. Es tikko esmu lūdzis viņa atļauju, ko viņš ir devis, lai lūgtu to no jums. Tā kā tas labi noved pie tā, ka tikai jāapkopojas, jo mēs tagad mazliet pamazām ejam, un es atgriezīšos pie Ērika. 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.
Dez Blanchfield: 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 koncentrējaties uz to, ka esat MVU, uz tā piedāvājuma īpašo vērtību, kuru jūs plānojat izveidot kā daļu no sava sākuma biznesa, un jums, iespējams, nevajadzēs būt ekspertam par visu, tāpēc ir 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ā varbūt esam pagājuši desmit minūtes, un es zinu, ka jums patīk turēties tuvu mūsu laika logiem.
Ēriks Kavanaghs: 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ā, un tad viņiem ir jāpārveido trīs vai četri. Vai tas nešķiet neproduktīvi? Kā jūs varat izvairīties no šāda veida lietām?
Rons Huizenga: Tas ir tikai veikls raksturs, ka konkrētajā situācijā jūs nesaņemat visu absolūti pareizi. Un tā patiesībā ir veiklības sastāvdaļa: strādājiet ar to - jūs darīsit prototipēšanu tur, kur strādājat ar kodu dotajos punktos, 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 ietaupāt viņus no tā, ka tie ir jādara, piemēram, ar roku, datu struktūru kodēšanai un ļauj viņiem koncentrēties uz programmēšanas vai lietojumprogrammu loģiku, kurā viņi ir visprasmīgākie.
Ē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 apskatījis piemērus, un jūs esat parādījis dažus ekrānuzņēmumus par to, kā jūs faktiski izlaižat dažus no šiem materiāliem. Runājot par visu šo 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 viedokļa ir s-veida pieeja?
Rons Huizenga: Es domāju, ka mēs to redzam arvien vairāk. Es zinu, ka, es teiktu, iespējams, jo īpaši pēdējo 15 gadu laikā, esmu redzējis daudz vairāk tādu cilvēku pieņemšanu, 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 un vairāk organizāciju pāriet uz veiklās monētas. 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: Tie ir lieliski priekšmeti, ļaudis. Tikko tērzēšanas logā ievietoju saiti uz slaidiem, tāpēc pārbaudiet to; tas jums ir mazliet par mazu. 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 līdz ar to mēs atvadīsimies no jums, ļaudis. Paldies vēlreiz par jūsu veltīto laiku un uzmanību. Mēs pateicamies, ka jūs uzkavējaties 75 minūtes, tā ir diezgan laba zīme. Labi šova puiši, mēs ar jums sarunāsimies nākamreiz. Labdien!