Ang pagmomolde ng data sa isang maliksi na kapaligiran

Sa pamamagitan ng Techopedia Staff, Nobyembre 16, 2016

Takeaway: Tinatalakay ng Host na si Eric Kavanagh ang kahalagahan ng pagmomolde ng data sa pag-unlad ng maliksi kasama sina Robin Bloor, Dez Blanchfield at IDERA na si Ron Huizenga.

Kasalukuyan kang hindi naka-log in. Mangyaring mag-log in o mag-sign up upang makita ang video.

Eric Kavanagh: Okay, mga kababaihan at mga ginoo. Maligayang pagdating muli. Ito ay Miyerkules sa 4:00 EST. Nangangahulugan ito na oras para sa Hot Technologies. Oo, naman. Ang pangalan ko ay Eric Kavanagh, ako ang magiging host mo.

Para sa paksa ngayon, ito ay isang oldie ngunit isang goodie. Ito ay nakakakuha ng mas mahusay na araw-araw dahil ito ay humuhubog sa aming mundo ng pamamahala ng data, "Pagmomodelo ng Data sa isang maliksi na Kapaligiran." May slide tungkol sa iyo ng tunay, pindutin ako sa Twitter @eric_kavanagh. Dapat nating ilagay ito sa slide na iyon. Kukunin ko na upang makakuha ng na.

Kaya mainit ang taon. Ang pagmomolde ng data ay nasa paligid magpakailanman. Ito ay talagang nasa puso at kaluluwa ng negosyo ng pamamahala ng impormasyon, pagdidisenyo ng mga modelo ng data, sinusubukan na maunawaan ang mga modelo ng negosyo at ihanay ang mga ito sa iyong mga modelo ng data. Iyon talaga ang sinusubukan mong gawin, di ba?

Ang modelo ng data ay kumakatawan sa negosyo sa isang pangunahing paraan, kaya paano binabago ang lahat ng mga bagong mapagkukunan ng data na ito? Malalaman natin ang tungkol doon. Malalaman namin kung paano ka maaaring manatili sa tuktok ng mga bagay sa isang maliksi na paraan. At syempre, iyon ang salita ng taon.

Kasama kami ni Robin Bloor, ang aming punong analista, si Dez Blanchfield na tumatawag mula sa Sydney, Australia at Ron Huizenga, Senior Product Manager mula sa IDERA - matagal nang kaibigan ng mina, mahusay na tagapagsalita sa puwang na ito, alam ang kanyang mga gamit, kaya huwag mahiya, tanungin kanya ang mahirap na mga katanungan, mga tao, ang mahirap. Gamit iyon, gagawin ko ang Robin na nagtatanghal, at ilayo ito.

Robin Bloor: Okay. Well salamat sa iyo, Eric. Kailangan kong sabihin tungkol sa pagmomolde na sa palagay ko, ako ay nasa mundo ng IT bago ito umiiral, sa kamalayan na naalala ko sa kumpanya ng seguro na nagtrabaho ako, na mayroon kaming isang tao na pumasok at bigyan kami ng lahat ng isang uri ng pagawaan kung paano mag-modelo ng data. Kaya't tinitingnan namin ang tungkol sa 30 taon, 30 taon ba ito? Siguro kahit na mas mahaba kaysa rito, marahil 35 taon na ang nakalilipas. Ang isang mahaba, mahabang panahon sa pagmomolde ay talagang naging isang bahagi ng industriya at syempre wala itong kinalaman sa mga kababaihan sa mga catwalks.

Ang bagay na nais kong sabihin, dahil kung ano ang karaniwang ginagawa namin, ay ako at si Dez ay nag-uusap tungkol sa iba't ibang mga bagay at naisip ko lamang na ibibigay ko ang pangkalahatang pangkalahatang-ideya sa pagmomolde, ngunit mayroong isang katotohanan sa ito, ngayon ay nagiging maliwanag.

Alam namin, alam mo, ang malaking katotohanan ng data, marami kaming data, mas maraming mapagkukunan ng data, nakuha namin ang mga stream ng data na nakapasok sa equation sa huling tatlo o apat na taon at nagsisimula upang makakuha ng isang malaking bahagi nito, at mayroong higit na pangangailangan na maunawaan ang data at isang pagtaas sa rate ng pagbabago na mas maraming data na idinagdag at maraming mga istruktura ng data na ginagamit.

Ito ay isang mahirap na mundo. Narito ang isang larawan nito, na kung saan ay talagang isang bagay na iginuhit namin mga tatlong taon na ang nakalilipas ngunit talaga, sa sandaling isama mo ang pag-stream sa halo at makuha mo ang ideyang ito ng refinery ng data, data hub, data link o kung ano man, nakikita mo na mayroong data na tunay na sa pamamahinga, sa kamalayan na hindi ito gumagalaw tungkol sa marami. At pagkatapos ay mayroong data, stream at nakuha mo ang lahat ng transactional application, kasama na ngayong mayroon kang mga kaganapan, mga data ng kaganapan na nangyayari sa mga aplikasyon at maaaring kailanganin, at sa kasalukuyan kasama ang mga arkitektura ng lambda na pinag-uusapan ng lahat, ay totoo pagkakaroon ng isang epekto sa lamang ng buong larangan ng data.

At ngayon isipin sa mga tuntunin ng pagkakaroon ng isang layer ng data. Ang layer ng data ay umiiral sa isang uri ng virtual na paraan, sa kamalayan na ang isang mahusay na piraso nito ay maaaring nasa ulap at maaari itong kumalat sa mga sentro ng data, maaari itong umiral sa mga workstation. Ang layer ng data ay, sa kung saan, sa lahat ng dako at sa diwa, may mga proseso sa lahat ng lugar na sinusubukan sa isang paraan o sa iba pang proseso upang maiproseso ang data at ilipat ang data. Ngunit alam din kung ano ito kapag inililipat mo ito, ay isang malaking pakikitungo.

Kung titingnan namin ang data sa pagmomolde sa pinaka-pangkalahatang kahulugan, sa ilalim ng ganitong uri ng salansan mayroon kang mga file at database. Mayroon kang mga elemento ng data, na mayroong mga susi, mga kahulugan ng elemento, mga alias, magkasingkahulugan, mga tiyak na pisikal na mga format at pagkatapos ay mayroon kaming layer na metadata na ito.

Ang kagiliw-giliw na bagay tungkol sa metadata ay ang metadata ay lubos na kung paano nakukuha ang data. Kung hindi mo talaga nakilala ang metadata, pagkatapos ay pinakamahusay na maaari mong hulaan ang kahulugan ng data, ngunit magkakaroon ka ng isang kakila-kilabot na mga kahirapan. Ang Metadata ay kailangang naroroon, ngunit ang kahulugan ay may istraktura. Hindi ko nais na pumunta sa pilosopiya ng kahulugan, ngunit kahit na sa pakikitungo namin sa data, maraming sopistikado sa pag-iisip ng tao at wika ng tao, na hindi madaling ipahayag ang sarili sa data. Ngunit kahit na sa mga tuntunin ng data na aktwal nating pinoproseso sa mundo, ang metadata ay may kahulugan at ang istraktura ng metadata - isang piraso ng data na may kaugnayan sa isa pa at kung ano ang ibig sabihin kapag pinagsama-sama at kung ano ang ibig sabihin kapag sila ' sumali sa iba pang data, hinihiling na modelo natin ito. Hindi sapat na magrekord lamang ng mga metadata tags sa mga bagay, mayroon kang talagang naitala ang kahulugan sa bawat istruktura at ang ugnayan sa pagitan ng mga istruktura.

Pagkatapos mayroon kami sa tuktok na layer, ang mga kahulugan ng negosyo, na kung saan ay karaniwang isang layer na sumusubok na ilipat ang kahulugan sa pagitan ng metadata, na isang form ng kahulugan ng data na akma sa paraan ng pag-aayos ng data sa computer at kahulugan ng tao. Kaya mayroon kang mga term sa negosyo, kahulugan, relasyon, mga konsepto na antas ng entidad na umiiral sa layer na iyon. At kung magkakaroon kami ng isang hindi pagkakasundo sa pagitan ng mga layer na ito, kailangan nating magkaroon ng pagmomolde ng data. Hindi ito talagang opsyonal. Ang mas maaari mong gawin ito sa mga tuntunin ng pag-automate nito, mas mahusay. Ngunit dahil may kinalaman sa kahulugan, mahirap talagang kahalili. Napakadali upang mahuli ang metadata sa loob ng isang talaan at makuha ito mula sa isang serye ng mga kahulugan, ngunit hindi nito sinabi sa iyo ang istraktura ng mga talaan o kung ano ang ibig sabihin ng mga tala o konteksto ng talaan.

Kaya, ito ang tungkol sa pagmomolde ng data, sa aking palagay. Mga puntos na dapat tandaan: ang mas kumplikado ang uniberso ng data ay nagiging, mas kailangan mo itong modelo. Sa madaling salita, ito ay tulad ng pagdaragdag namin hindi lamang ng maraming mga pagkakataon ng mga bagay sa mundo, na kung saan ay tumutugma sa mga talaan ng data, ngunit talagang nagdaragdag kami ng higit na kahulugan sa mundo sa pamamagitan ng pagkuha ng data ng higit pa at maraming mga bagay. Nagiging mas kumplikado ang pakiramdam na dapat nating maunawaan.

Sa teorya mayroong isang data uniberso at kailangan namin ng isang view ng ito. Sa pagsasagawa, ang aktwal na metadata ay bahagi ng uniberso ng data. Kaya, hindi ito isang simpleng sitwasyon. Ang pagsisimula ng pagmomolde ay top-down at bottom-up. Kailangan mong bumuo sa parehong direksyon at ang dahilan para sa iyon ay, ang data ay may kahulugan sa computer at ang proseso, kailangan itong iproseso, ngunit mayroon itong kahulugan sa sarili nitong karapatan. Kaya, kailangan mo ng kahulugan sa ibaba, na nasiyahan ang software na kailangang ma-access ang data at kailangan mo ang pang-itaas na kahulugan upang maunawaan ito ng mga tao. Ang pagtatayo ng mga modelo ng metadata ay hindi at hindi maaaring maging isang proyekto; ito ay isang patuloy na aktibidad - dapat na isang patuloy na aktibidad sa bawat kapaligiran na mayroon sila. Sa kabutihang palad, mayroong maraming mga kapaligiran, kung saan hindi talaga ito ang kaso at ang mga bagay ay umiikot nang naaayon.

Pasulong, ang pagtaas ng pagmomolde ay may kahalagahan habang ang teknolohiya ay sumusulong. Iyon ang aking opinyon. Ngunit kung titingnan mo ang IoT maaari naming maunawaan ang mobile nang higit pa kaysa sa dati, bagaman ipinakilala ang mga bagong sukat: ang sukat ng lokasyon gamit ang mobile. Kapag nakarating ka sa IoT, tinitingnan namin ang mga pambihirang mga problema sa data na hindi namin talaga kailangang gawin bago at kailangan nating, isang paraan o iba pa, upang maunawaan nang eksakto kung ano ang nakuha namin, eksakto kung paano namin mapagsasama ito, kung ano ang maaari nating gawin sa mga tuntunin ng pagkuha ng kahulugan mula sa pagsasama-sama, at siyempre, kung ano ang magagawa natin dito, kapag naproseso natin ito.

Sa palagay ko ay sapat na ang sinabi ko. Pupunta ako sa Dez Blanchfield, na sasabihin nang iba pa.

Dez Blanchfield: Salamat. Laging isang matigas na kilos na dapat sundin, ngunit ito ay isang paksang napagkasunduan namin at pinag-usapan namin ito sa madaling sabi sa bantas na preso, at kung ikaw ay naka-dial nang maaga, marahil ay nahuli mo ang isang buong grupo ng mga magagandang hiyas. Isa sa mga takeaway, at hindi ko nais na nakawin ang kulog ng partikular na ito, ngunit ang isa sa mga takeaway mula sa aming bantog na preso na nais kong ibahagi, kung sakaling hindi mo ito nahuli, ay nasa paligid ng paksa ng ang paglalakbay ng data, at sinaktan ako ng tunay na isulat ito sa pag-iisip tungkol sa paglalakbay na kinukuha ng data sa isang kakaibang konteksto sa paligid ng panghabang-buhay na taon - taon, buwan, linggo, araw, oras, minuto, pangalawa - at ang konteksto sa paligid ng data ay nakaposisyon sa loob ng konteksto na iyon. Kung ako ay isang developer na nagpapatakbo ng code, o kung ako ay isang dalubhasa sa data at iniisip ko ang tungkol sa istraktura at ang format at ang metadata sa paligid ng bawat isa sa mga elemento, o ang paraan na nakikipag-ugnay dito ang mga system at negosyo.

Ito ay isang kagiliw-giliw na maliit na takeaway para lamang tandaan, ngunit pa rin, hayaan mo akong sumisid. Ang disenyo ng data, lalo na, ay isang pariralang ginagamit ko upang pag-usapan ang lahat ng mga bagay na data at partikular na pag-unlad ng alinman sa mga aplikasyon o imprastraktura ng database. Sa palagay ko ang disenyo ng data ay isang term na nakakakuha lamang ng maayos sa aking isipan. Sa mga araw na ito kapag pinag-uusapan natin ang tungkol sa disenyo ng data, pinag-uusapan natin ang modernong disenyo ng data ng maliksi, at ang aking pananaw ay hindi pa matagal na ang mga nag-develop at eksperto ng data ay nag-iisa; sila ay sa kanilang sariling mga silikon at mga piraso ng disenyo nagpunta mula sa isang silo patungo sa isa pa. Ngunit napakalaki ng pagtingin ko sa mga araw na ito, na hindi lamang ito ang nagbago, ngunit kailangang baguhin; ito ay uri ng isang pangangailangan at iyon ang aplikasyon - mga nag-develop at kahit anong gawin sa paligid ng pag-unlad na may kinalaman sa data, ang mga taga-disenyo na gumagawa ng mga nauugnay na elemento ng disenyo ng mga iskema at mga patlang at talaan at mga lokasyon at database system at imprastraktura, pagmomolde at buong pamamahala hamon sa paligid na. Iyon ay isang koponan ng koponan ngayon at samakatuwid ang aking larawan ng isang bungkos ng mga taong tumatalon mula sa isang eroplano na kumikilos bilang isang koponan upang i-play ang kapansin-pansin na imahe ng mga taong nahuhulog sa kalangitan.

Pangatlo, ano ang nangyari upang magawa ito? Buweno, mayroong isang artikulo noong 1986 na isinulat ng isang maginoo na ang mga pangalan na sinubukan kong gawin ang hustisya sa, sina Hirotaka Takeuchi at Ikujiro Nonaka, sa palagay ko ay binibigkas ito, gumawa ng isang artikulo na pinamagatang "Paglipat ng Scrum Downfield." Ipinakilala nila ang ideyang ito ng isang pamamaraan ng pagpanalo ng isang laro ng rugby na pupunta mula sa aktibidad na ito ng scrum, kung saan ang lahat ay nakakakuha sa paligid sa isang lugar at dalawang koponan na mahalagang lock ang mga ulo sa isang bagay na tinatawag na isang scrum upang subukan at makakuha ng kontrol ng bola at i-play ito sa bukid na makarating sa try line at hawakan ang lupa gamit ang bola at makakuha ng isang punto, na tinatawag na trine, at ulitin mo ang prosesong ito at makakakuha ka ng higit pang mga point para sa koponan.

Ang artikulong ito ay nai-publish noong 1986 sa Harvard Business Review, at kakaiba talaga itong nakuha ng maraming pansin. Nakakuha ito ng maraming pansin dahil ipinakilala nito ang mga kamangha-manghang mga bagong konsepto at narito ang isang screenshot ng harapan nito. Kaya kinuha nila ang konsepto na ito ng scrum sa laro ng rugby at dinala nila ito sa negosyo at lalo na sa laro ng disenyo at paghahatid ng proyekto, partikular na paghahatid ng proyekto.

Ang ginawa ng scrum ay nagbigay sa amin ng isang bagong pamamaraan sa paghahambing sa mga kagaya ng PRINCE2 o PMBOK na dati naming ginamit sa tinatawag naming pamamaraan ng talon, alam mo, gawin ang bagay na ito at ang bagay na ito at ang bagay na ito at sundin ang mga ito nang pagkakasunod-sunod at kumonekta lahat ng mga tuldok sa paligid, na nakasalalay sa kung ano ang mayroon ka, o huwag gawin ang dalawang bahagi hanggang sa magawa mo ang bahagi ng isa dahil nakasalalay ito sa isang bahagi. Ang ibinigay nito sa amin ay isang bagong pamamaraan upang maging mas maliksi, na kung saan nagmula ang termino, tungkol sa kung paano namin maihatid ang mga bagay, at partikular sa paligid ng disenyo at pagpapaunlad ng paghahatid ng proyekto ng mga katutubo.

Ang ilan sa mga pangunahing nangungupahan - sa gayon ay nakakasabay ako - ay nasa paligid ng mga pangunahing nangungupahan ng scrum. Ipinakilala nito ang ideya ng kawalang-tatag ng gusali, na epektibo kung iniisip mo ang tungkol sa takot sa kaguluhan, ang mundo ay umiiral sa isang estado ng kaguluhan, ngunit nabuo ang planeta, na kawili-wili, kaya ang kawalang-tatag ng gusali, ang kakayahang mag-bounce sa paligid ng kaunting aktwal pa ring gumawa ng mga bagay, gumagana sa sarili ng mga koponan ng proyekto, nag-overlay na pabor sa pamamagitan ng responsableng pag-unlad, iba't ibang uri ng pag-aaral at kontrol sa paglalakbay ng paghahatid ng proyekto, ang paglipat ng organisasyon ng pag-aaral. Kaya paano namin makukuha ang impormasyon mula sa isang bahagi ng negosyo at maililipat ito sa ibang tao mula sa mga taong may ideya ngunit hindi bumuo ng code o hindi bumuo ng mga database at imprastraktura, ngunit ang data sa mga taong iyon? At partikular na mga kinahinatnan na mga kinalabasan. Sa madaling salita, gawin natin ito para sa isang tagal ng panahon, alinman sa isang araw tulad ng sa 24 na oras, o isang linggo o ilang linggo at tingnan kung ano ang maaari nating gawin at pagkatapos ay tumalikod at tingnan ito.

At kaya, kung patawarin mo ang pun, ito ay talagang isang bagong laro sa paghahatid ng proyekto at ang tatlong mga pangunahing sangkap dito na magkakaroon ng kahulugan habang nakakuha kami ng kaunti pa kasama dito - mayroong produkto: lahat ng mga taong ito ay may ideya at magkaroon isang pangangailangan upang makagawa ng isang bagay at ang kwento na pumapalibot sa kanila. Ang mga nag-develop na nagpapatakbo sa modelo ng maliksi ng pagkuha ng kanilang mga kwento at sa pamamagitan ng pang-araw-araw na mga standup gamit ang pamamaraan ng scrum upang talakayin ito at maunawaan kung ano ang kailangan nilang gawin, at pagkatapos ay pumunta lamang at magpatuloy at gawin ito. Pagkatapos, mga tao, narinig namin ang mga masters ng scrum na nangangasiwa sa buong bagay na ito at naiintindihan nang maayos ang pamamaraan upang maipalabas ito. Nakita nating lahat ang mga larawang ito na nakuha ko sa kanang kamay dito ng mga dingding at mga pisara na puno ng mga tala ng Post-It at sila ay nagsilbi bilang mga pader ng Kanban. Kung hindi mo alam kung sino ang Kanban, inaanyayahan kita sa Google na si G. Kanban ay at kung bakit ito ay pagbabago sa paraan ng paglipat namin ng mga bagay mula sa isang tabi patungo sa isa pang pader sa literal ngunit sa isang proyekto.

Sa isang sulyap, ang daloy ng trabaho ng scrum ay gumagawa nito: kinakailangan ng isang listahan ng mga bagay na nais gawin ng isang samahan, patakbuhin ang mga ito sa isang serye ng mga bagay na tinatawag nating mga sprints na nasira sa 24-oras na mga panahon, tagal ng buwan, at kami makuha ang mga ito ng serye ng pagsasama. Ito ay isang makabuluhang pagbabago sa paraan ng mga proyekto ay naihatid, naihatid hanggang sa yugto na iyon dahil bahagi ng daloy na tulad ng hukbo ng Estados Unidos na nagkaroon ng isang mahusay na bahagi ng pagbuo ng isang bagay na tinatawag na PMBOK, tulad ng ideya na hindi kumuha ng tangke sa bukid hanggang sa ilagay mo ang mga bala sa bagay dahil kung ang isang tangke sa bukid ay walang mga bala, walang saysay. Kaya't ang bahagi ng isa ay ilagay ang mga bala sa tangke, ang dalawang bahagi ay inilalagay ang tangke sa bukid. Subalit, sa kasamaang palad, kung ano ang nangyari sa mga nag-develop sa mundo ng pag-unlad kahit papaano ay nakakuha ng mahigpit na pamamaraan na ito at tumakbo kasama ito ng flat, kung pinatawad mo ang pun, sa isang sprint.

Ang hindi madalas na nangyari ay, kapag iniisip natin ang maliksi ay karaniwang iniisip natin ang mga developer at hindi mga database at anumang bagay na gagawin sa mundo ng mga database. Ito ay isang hindi kanais-nais na kinalabasan dahil ang katotohanan ay ang maliksi ay hindi limitado sa mga nag-develop. Sa katunayan, ang term na maliksi sa aking pananaw ay madalas na mali na nauugnay nang eksklusibo sa mga developer ng software at hindi mga taga-disenyo ng database at arkitekto. Madalas ang parehong mga hamon na kinakaharap mo sa pag-unlad ng software at aplikasyon ay nahaharap sa lahat ng bagay na gagawin sa disenyo at pag-unlad at operasyon at pagpapanatili at samakatuwid ng mga datos na datos at partikular na mga database. Ang mga aktor sa partikular na data cast na ito ay kinabibilangan ng mga kagustuhan ng mga arkitekto ng data, mga taga-hulma, ng mga administrador, tagapamahala ng mga imprastruktura ng database at ang aktwal na mga database mismo sa kanilang mga paraan hanggang sa mga analyst at negosyo ng mga system at arkitekto, ang mga tao na nakaupo at iniisip tungkol sa kung paano ang mga system at nagpapatakbo ang negosyo at kung paano namin nakuha ang daloy ng data sa pamamagitan ng mga ito.

Ito ay isang paksa na regular kong pinalaki dahil ito ay isang palaging pagkabigo sa akin dahil sa labis na pananaw na dapat gawin ng mga espesyalista ng data - hindi dapat - nararapat na ngayon ay kasangkot sa bawat bahagi ng paghahatid ng proyekto, talaga, lalo na ang pag-unlad. Para hindi kami, kung gayon talagang hindi namin binibigyan ang aming sarili ng pinakamahusay na pagkakataon para sa isang mahusay na kinalabasan. Kadalasan ay kailangan nating bilugan at magkaroon ng isa pang pag-iisip tungkol sa mga bagay na ito dahil mayroong isang sitwasyon, nakarating kami sa isang application na binuo at natuklasan namin ang mga nag-develop ay hindi palaging eksperto ng data. Ang pagtatrabaho sa mga database ay nangangailangan ng napaka dalubhasang mga kasanayan, lalo na sa paligid ng data, at nagtatayo ng isang karanasan. Hindi ka lang agad maging isang database guru o dalubhasa sa kaalaman ng data sa magdamag; ito ay madalas na isang bagay na nagmumula sa isang buhay na karanasan at tiyak sa mga kagustuhan ni Dr. Robin Bloor sa Code Ngayon, na mayaman na sumulat ng libro.

Sa maraming mga kaso - at sa kasamaang palad ngunit ito ay isang katotohanan - na mayroong dalawang bahagi ng barya na ito, na ang mga developer ng software ay mayroong isang blackout ng kanilang sariling bilang sa mga espesyalista sa database at itinayo ang mga kasanayan na kailangan mo sa pagmomolde ng disenyo ng database, ang pag-unlad ng modelo ay lamang ang pangunahing para sa engineering ng mga gurus 'kung paano pumapasok ang data at kung paano ang samahan ng paglalakbay na kinakailangan at kung ano ang dapat o hindi dapat magmukhang, o walang alinlangan na ang ingested at pag-unawa na ito ay karaniwang nakuha sa mga katutubong kasanayan na itinakda para sa mga developer ng software. At ang ilan sa mga karaniwang mga hamon na kinakaharap natin, upang ilagay lamang sa konteksto, kasama ang kagaya ng mga pangunahing paglikha at pagpapanatili at pamamahala ng disenyo ng pangunahing database mismo, na nagdokumento ng data at database ng database at pagkatapos ay muling gamitin ang mga data assets, schema design, mga henerasyon ng schema, pangangasiwa at pagpapanatili ng schema at paggamit ng mga ito, ang pagbabahagi ng kaalaman sa paligid kung bakit ang schema na ito ay dinisenyo sa isang partikular na paraan at ang mga kalakasan at kahinaan na dulot ng paglipas ng panahon ay nagdudulot ng mga pagbabago sa data sa paglipas ng panahon, pagmomolde ng data at mga uri ng mga modelo na inilalapat namin sa mga system at data na dumadaloy sa atin. Ang henerasyon ng code ng database at nagpapatuloy sa pagsasama at pagkatapos ay na-modelo ng data sa paligid nila at pagkatapos ay mas mabilis na ma-access upang makontrol ang seguridad sa paligid ng data, ang integridad ng data ay inililipat namin ang data sa paligid habang pinapanatili namin ang integridad nito, may sapat bang metadata sa paligid ito, dapat bang makita ng mga benta ang lahat ng mga talaan sa talahanayan o dapat nilang makita lamang ang address, ang unang pangalan, apelyido na nagpapadala sa iyo ng mga bagay sa post? At pagkatapos siyempre ang pinakadakilang hamon ng lahat ay ang pagmomolde ng mga platform ng database na kung saan ay lubos na magkakaibang pag-uusap sa sarili nito.

Napakaisip ko na sa lahat ng ito ay nasa isip na gawin ang alinman sa nirvana na ito, ganap na kritikal na kapwa ang mga dalubhasa sa data at mga developer ay may naaangkop na mga tool at ang mga tool na ito ay may kakayahang maghatid ng proyekto na nakatuon sa koponan, disenyo, pag-unlad at patuloy na pagpapanatili ng pagpapatakbo. Alam mo, ang mga bagay tulad ng pakikipagtulungan sa mga proyekto sa pagitan ng mga eksperto ng data at mga developer ng software, solong punto ng katotohanan o iisang mapagkukunan ng katotohanan para sa lahat ng mga bagay sa paligid ng dokumentasyon ng mga database ng kanilang mga sarili, ang data, mga scheme, kung saan nagmula ang mga rekord, mga nagmamay-ari ng mga tala . Sa palagay ko sa araw na ito at edad na ito ay ganap na kritikal, kukunin namin ang nirvana ng data na maging hari, na ang tamang mga tool ay kailangang nasa lugar dahil ang hamon ay napakalaki ngayon para sa amin na manu-mano itong gawin, at kung ang mga tao lumipat at lumabas sa isang samahan, napakadali para sa amin na hindi sundin ang parehong proseso o pamamaraan na maaaring itakda ng isang tao na mabuti at hindi kinakailangang ilipat ang mga kasanayan at kakayahan na pasulong.

Sa pag-iisip, pupunta ako sa aming mabuting kaibigan sa IDERA at maririnig ang tungkol sa tool na iyon at kung paano ito tinutukoy ang mga bagay na ito.

Ron Huizenga: Maraming salamat at salamat sa parehong Robin at Dez sa tunay na pagtatakda nang maayos ng entablado, at makikita mo ang isang maliit na overlap sa isang pares ng mga bagay na napag-usapan ko. Ngunit talagang nagtakda sila ng isang napaka-solidong pundasyon para sa ilan sa mga konsepto na pag-uusapan ko mula sa isang pananaw sa pagmomolde ng data. At maraming mga bagay na sinabi nila ay nagbubunyi sa aking sariling karanasan noong ako ay isang consultant na nagtatrabaho sa data pagmomolde ng data at arkitektura ng data, kasama ang mga koponan - parehong talon sa unang araw at umuusbong sa mas modernong mga produkto na may mga proyekto kung saan gumagamit kami ng maliksi. mga pamamaraan upang maihatid ang mga solusyon.

Kaya ang pinag-uusapan ko ngayon ay batay sa mga karanasan na iyon pati na rin ang pagtingin sa mga tool at ilan sa mga kakayahan sa mga tool na ginagamit namin upang matulungan kami sa paglalakbay na iyon. Ang sasabihin ko sa madaling sabi ay, hindi ako pupunta sa scrum nang maraming detalye; nagkaroon lang kami ng isang mahusay na pangkalahatang-ideya ng kung ano iyon. Pag-uusapan ko ito sa mga tuntunin ng, ano ang isang modelo ng data at kung ano talaga ang kahulugan nito sa amin? At paano natin mapapagana ang konsepto ng modelo ng data ng maliksi sa aming mga samahan, sa mga tuntunin ng, paano natin isasangkot ang mga modelo ng data, kung ano ang pakikilahok ng mga modelo at arkitekto sa panahon ng sprint, ano ang mga uri ng mga aktibidad na dapat nilang makisali, at, bilang isang backdrop na, ano ang ilan sa mga mahahalagang kakayahan sa pagmomolde na ginagamit namin upang makatulong na gawing mas madali ang trabaho? Pagkatapos ay pupunta ako sa isang piraso ng isang pambalot at makipag-usap lamang ng kaunti tungkol sa ilan sa mga halaga ng negosyo at mga benepisyo ng pagkakaroon ng kasangkot sa isang modelo ng data, o ang paraan na talagang sasabihin ko ang kuwento ay, ang mga problema ng hindi pagkakaroon ng isang data modeler na ganap na nakatuon sa mga proyekto at ipapakita ko sa iyo na batay sa karanasan at isang tsart ng depekto ng isang bago at pagkatapos ng imahe ng isang aktwal na proyekto na kasangkot ako sa maraming mga taon na ang nakakaraan. At pagkatapos ay magbuod kami ng ilang higit pang mga puntos at pagkatapos ay magkakaroon ng mga katanungan at sagot bilang karagdagan sa na.

Napakadali, ang ER Studio ay isang napakalakas na suite na maraming iba't ibang mga sangkap dito. Ang Data Architect, na kung saan ang mga data ng mga modelo at arkitekto ay gumugugol ng karamihan sa kanilang oras sa paggawa ng kanilang pagmomolde ng data. Mayroong iba pang mga sangkap pati na hindi namin pinag-uusapan ngayon tulad ng Business Architect, kung saan ginagawa namin ang proseso ng pagmomolde at ang Software Architect, para sa ilan sa pagmomolde ng UML. Pagkatapos mayroong Repository, kung saan namin suriin at ibinabahagi namin ang mga modelo at pinapayagan namin ang mga koponan na makipagtulungan sa mga iyon at i-publish ang mga ito sa server ng koponan upang ang maraming mga madla ng stakeholder na nakikibahagi sa isang proyekto ay maaaring makita ang mga artifact na kami ' lumilikha muli mula sa isang pananaw ng data pati na rin ang iba pang mga bagay na ginagawa namin sa paghahatid ng proyekto mismo.

Ang magiging pansin ko ngayon ay magiging ilang mga bagay na makikita natin sa Data Architect at dahil talagang mahalaga na mayroon tayong pakikipagtulungan ng mga aspeto na batay sa Repositoryo. Lalo na kapag nagsisimula kaming makipag-usap tungkol sa mga konsepto tulad ng pamamahala ng pagbabago na kinakailangan, hindi lamang mga proyekto sa pag-unlad, ngunit ang anumang uri ng pag-unlad ay pasulong.

Kaya pag-usapan natin ang tungkol sa Agile Data Modeler. Tulad ng mayroon kami, uri ng, na tinukoy nang mas maaga sa pagtatanghal, ay kinakailangan na mayroon kaming mga modelo ng data at / o mga arkitekto na ganap na nakikibahagi sa mga proseso ng pag-unlad ng maliksi. Ngayon, kung ano ang nangyari sa kasaysayan ay, oo, talagang naisip namin ang tungkol sa maliksi mula sa isang pananaw sa pag-unlad, at may ilang mga bagay na naganap na talagang nagdulot sa nangyari. Ang bahagi nito ay dahil lamang sa likas na katangian ng paraan ng pagbuo mismo. Habang nagsimula ang pag-unlad ng maliksi at nagsimula kami sa konseptong ito ng mga koponan sa pag-aayos ng sarili, kung uminom ka ng Kool-Aid ng kaunting masyadong puro at ikaw ay nasa matinding pag-aayos ng programa ng mga bagay, mayroong isang napaka literal na interpretasyon ng mga bagay tulad ng mga pangkat ng pag-aayos ng sarili, na kung saan ang maraming mga tao na isinalin upang sabihin, ang kailangan lamang namin ay isang pangkat ng mga developer na maaaring bumuo ng isang buong solusyon. Kung nangangahulugan ito ng pagbuo ng code, ang mga database o ang mga datastores sa likod nito at ang lahat ay naibalik sa mga nag-develop. Ngunit kung ano ang mangyayari doon ay mawala ka sa mga espesyal na kakayahan ng mga tao. Nalaman ko na ang pinakamalakas na koponan ay ang mga binubuo ng mga tao mula sa iba't ibang mga background. Tulad ng isang kumbinasyon ng mga malakas na software developer, data arkitekto, data modelers, negosyo analysts, at mga stakeholder ng negosyo, lahat ay nagtutulungan upang itaboy ang isang pagtatapos na solusyon.

Ang pinag-uusapan ko ngayon ay, gagawin ko ito sa konteksto ng isang proyekto sa pag-unlad kung saan kami ay nagkakaroon ng isang aplikasyon na malinaw naman na magkakaroon din ng bahagi ng data na nauugnay dito. Kailangan nating gumawa ng isang hakbang pabalik bago natin gawin iyon, bagaman, kailangan nating mapagtanto na may napakakaunting mga proyekto sa pag-unlad ng Greenfield na naroroon kung saan mayroon tayong kabuuang pokus sa paglikha at pagkonsumo ng data na limitado lamang sa loob ng proyektong pag-unlad nito . Kailangan nating gumawa ng isang hakbang pabalik at tingnan ang pangkalahatang punto ng pang-organisasyon na pagtingin mula sa isang pananaw ng data at isang pananaw sa proseso. Dahil ang nalaman namin ay ang impormasyong ginagamit namin ay maaaring mayroon nang isang lugar sa mga samahan. Bilang mga modelo at arkitekto ay dinadala namin iyon upang magaan upang malaman namin kung saan mapagkukunan ang impormasyong mula sa mga proyekto mismo. Alam din namin ang mga istruktura ng data na kasangkot dahil mayroon kaming mga pattern ng disenyo tulad ng mga developer ay may mga pattern ng disenyo para sa kanilang code. At kailangan din nating gawin ang pangkalahatang pananaw ng organisasyon. Hindi lamang namin maaaring tumingin sa data sa konteksto ng application na aming binuo. Kailangan nating modelo ng data at tiyakin na idokumento namin ito dahil mahaba ang buhay nito na lampas sa mga aplikasyon mismo. Dumating ang mga application na iyon, ngunit kailangan nating tingnan ang data at tiyakin na ito ay matibay at maayos na nakabalangkas, hindi lamang para sa aplikasyon, kundi pati na rin sa mga desisyon na nag-uulat ng mga aktibidad, pag-uulat ng BI at pagsasama sa iba pang mga aplikasyon, panloob at panlabas din sa aming mga organisasyon. Kaya kailangan nating tingnan ang buong malaking larawan ng data at kung ano ang siklo ng buhay ng data na iyon at maunawaan ang paglalakbay ng mga piraso ng impormasyon sa buong samahan mula sa duyan hanggang sa libingan.

Ngayon bumalik sa aktwal na mga koponan mismo at kung paano namin talagang kailangan upang gumana ay, ang pamamaraan ng talon ay napagtanto na masyadong mabagal upang maihatid ang mga resulta. Sapagkat, tulad ng itinuro sa halimbawa ng tangke, ito ay isang hakbang pagkatapos ng isa pa at madalas na tumagal ng masyadong mahaba upang maghatid ng isang magagawa na resulta ng pagtatapos. Ang ginagawa natin ngayon ay kailangan nating magkaroon ng isang iterative style style kung saan kami ay pagdaragdag ng pagbuo ng mga bahagi nito at pag-elaborate ito sa oras kung saan gumagawa tayo ng magagamit na code o magagamit na mga artifact, sasabihin ko, para sa bawat sprint. Ang mahalagang bagay ay ang pakikipagtulungan sa gitna ng mga teknikal na stakeholder sa koponan at mga stakeholder ng negosyo habang kami ay nakikipagtulungan upang mapalayas ang mga kwentong gumagamit sa isang maisasakatuparan na pananaw ng code at ang data na sumusuporta din sa code na iyon. At ang Mabilis na Data Modeler mismo ay madalas na makahanap na wala kaming sapat na mga modelo sa mga samahan kaya ang isang data modeler o arkitekto ay maaaring sabay na sumusuporta sa maraming mga koponan.

At ang iba pang aspeto ng iyon, kahit na mayroon tayong maraming mga modelo, kailangan nating tiyakin na mayroon kaming isang set ng tool na ginagamit namin na nagbibigay-daan sa pakikipagtulungan ng maraming mga proyekto na lumipad sa parehong oras at pagbabahagi ng mga iyon artifact ng data at mga kakayahan sa pag-check-in at pag-check-out. Mabilis kong pupunta ito nang napakabilis dahil natakpan na namin ito sa nakaraang seksyon. Ang tunay na saligan ng maliksi ay na iyong binabalewala ang mga bagay sa backlog, ng mga kwento o mga kinakailangan. Sa loob ng mga iterasyon ay nagtutulungan kami bilang isang pangkat. Karaniwan ang isang dalawang-linggo o isang buwan na sprint, depende sa samahan, ay pangkaraniwan. At din ang pang-araw-araw na pagsusuri at mga standup na mga pagpupulong upang maalis ang mga blocker at tiyakin na inililipat namin ang lahat ng mga aspeto nang hindi napipigilan ang iba't ibang mga lugar na pinagdadaanan namin. At sa mga sprint na nais naming tiyakin na gumagawa kami ng mga magagamit na paghahatid bilang isang bahagi ng bawat sprint.

Lamang ng isang maliit na magkakaibang gawin sa, pagpapalawak nito nang higit pa, ang scrum ay ang pamamaraan na sasabihin ko tungkol sa mas partikular dito at kami lamang ang pinararami ang nakaraang larawan na may ilang iba pang mga facet. Karaniwan mayroong isang backlog ng produkto at pagkatapos ay mayroong isang sprint backlog. Kaya mayroon kaming pangkalahatang pag-backlog na, sa simula ng bawat pagsasanay sa sprint, inihanda namin upang sabihin, "Ano ang gagawin namin upang mabuo ang sprint na ito?" At nagawa ito sa isang pulong ng pagpaplano ng sprint. Pagkatapos ay masisira namin ang mga gawain na nauugnay dito at isinasagawa namin sa mga isa hanggang apat na linggong mga sprint kasama ang mga pang-araw-araw na pagsusuri. Habang ginagawa namin na sinusubaybayan namin ang aming pag-unlad sa pamamagitan ng mga nasusunog na mga tsart at mga nasusunog na tsart upang masubaybayan kung ano ang naiwan upang mabuo kumpara sa kung ano ang aming binuo upang maitaguyod ang mga bagay tulad ng kung ano ang aming bilis ng pag-unlad, gagawin ba natin iskedyul, lahat ng mga uri ng mga bagay. Ang lahat ng mga ito ay patuloy na detalyado sa panahon ng sprint kaysa sa paglipas ng ilang buwan sa kalsada at malaman na pupunta ka nang maikli at kailangan mong pahabain ang iskedyul ng proyekto. At napakahalaga, bilang bahagi nito, ang buong koponan, mayroong isang pagsusuri sa sprint sa dulo at isang retrospective ng sprint, kaya bago mo masipa ang susunod na pag-aalis ay sinusuri mo ang iyong ginawa at naghahanap ka ng mga paraan na makakaya mo pagbutihin sa susunod na oras.

Sa mga tuntunin ng mga naghahatid, ito ay karaniwang isang slide na nagbubuod sa mga tipikal na uri ng mga bagay na nagpapatuloy sa mga sprints. At napakahusay na sentimo sa pag-unlad, kaya maraming mga bagay na nakikita natin dito, tulad ng, mga pag-andar sa pag-andar at paggamit ng mga kaso, paggawa ng mga pagsubok sa code ng disenyo, kung titingnan namin ang mga kahon na ito, at hindi ko na madadaan ang mga ito sa anumang antas ng detalye, sila ay napaka-oriented sa pag-unlad. At inilibing sa ilalim nito ang katotohanan na kailangan din nating magkaroon ng mga naihahatid ng data na magkasama sa pagsuporta sa pagsisikap na ito. Kaya sa tuwing nakikita natin ang mga bagay tulad ng mga backlog, ang mga kinakailangan at kwento ng gumagamit, habang pinagdadaanan natin kailangan nating tingnan kung ano ang mga piraso ng pag-unlad na dapat nating gawin, ano ang mga piraso ng pagsusuri na kailangan nating gawin, paano ang tungkol sa disenyo ng data o modelo ng data, ano ang tungkol sa mga bagay tulad ng mga glosaryo ng negosyo upang maiugnay natin ang kahulugan ng negosyo sa lahat ng mga artifact na ginagawa natin? Sapagkat kailangan nating gumawa ng mga kapaki-pakinabang na mga paghahatid sa bawat sprint.

Sasabihin ng ilang tao na kailangan nating gumawa ng magagamit na code sa pagtatapos ng bawat sprint. Iyon ay hindi kinakailangan ang kaso, iyon ay sa isang purong pananaw sa pag-unlad, ngunit madalas - lalo na sa simula - maaaring magkaroon tayo ng isang bagay tulad ng sprint zero kung saan nakatuon kami sa paninindigan ng mga bagay, paggawa ng mga bagay tulad ng pagkuha ng aming mga diskarte sa pagsubok sa lugar. Isang disenyo ng mataas na antas upang masimulan ito bago natin simulan upang punan ang mga detalye at tiyakin na mayroon tayong malinis na hanay ng pagsisimula ng mga kwento o mga kinakailangan bago tayo magsimulang makisali sa iba pang mga madla at pagkatapos ay pagbuo ng isang koponan bilang pasulong tayo. Mayroong palaging isang maliit na oras ng prep, kaya madalas na magkakaroon kami ng isang sprint zero o kahit na sprint zero at isa. Maaaring maging isang maliit na bahagi ng pagsisimula bago namin matumbok ang buong paglipad sa paghahatid ng solusyon.

Pag-usapan natin ang tungkol sa mga modelo ng data sa konteksto na ito nang napakadali. Kapag iniisip ng mga tao ang mga modelo ng data, madalas nilang iniisip ang isang modelo ng data bilang isang larawan kung paano magkasama ang magkakaibang piraso ng impormasyon - iyon lamang ang dulo ng iceberg. Upang ganap na isama ang diwa ng kung paano mo talaga gustong lapitan ang pagmomolde ng data - kung ito ay sa pag-unlad ng maliksi at iba pang mga bagay - kailangan mong mapagtanto na ang modelo ng data, kung tapos nang tama, ay naging iyong buong pagtutukoy para sa kung ano ang ibig sabihin ng data sa samahan at kung paano ito nai-deploy sa back-end database. Kapag sinabi ko ang mga database, ang ibig kong sabihin ay hindi lamang ang mga kaugnay na mga database na maaaring magamit namin, ngunit sa mga arkitektura ngayon kung saan mayroon kaming malaking data o mga platform ng NoSQL, dahil mas gusto kong tawagan ang mga ito. Gayundin ang mga malalaking tindahan ng data dahil maaaring pagsasama-sama namin ang maraming iba't ibang mga tindahan ng data sa mga tuntunin ng pagkonsumo ng impormasyon at dalhin ito sa aming mga solusyon pati na rin kung paano namin pinagsisiksik o nai-save din ang impormasyong iyon sa aming mga solusyon.

Maaari kaming nagtatrabaho sa maraming mga database o mga mapagkukunan ng data nang sabay-sabay sa konteksto ng isang naibigay na application. Ano ang napakahalaga ay nais nating magkaroon ng isang buong pagtutukoy, kaya isang lohikal na detalye ng kung ano ang ibig sabihin nito sa isang pananaw sa organisasyon ng sprint, kung ano ang pisikal na mga konstruksyon ay nasa mga tuntunin kung paano namin talaga tinukoy ang data, ang mga ugnayan sa pagitan nito sa ang iyong mga database, ang iyong mga sanggunian ng referralidad ng integridad, suriin ang mga hadlang, lahat ng mga piraso ng pagpapatunay na karaniwang iniisip mo. Napakahalaga ng deskriptibong metadata. Paano mo malalaman kung paano magamit ang data sa iyong mga aplikasyon? Maliban kung maaari mong tukuyin ito at malalaman kung ano ang kahulugan o alam kung saan ito nagmula upang matiyak na naubos mo ang tamang data sa mga application na iyon - tinitiyak na mayroon kaming wastong pagbibigay ng mga kombensyon, buong kahulugan, na nangangahulugang isang buong diksyunaryo ng data para sa hindi lamang ang mga talahanayan ngunit ang mga haligi na binubuo ng mga talahanayan - at mga tala sa pag-deploy ng detalye tungkol sa kung paano natin gagamitin iyon dahil kailangan nating buuin ang kaalamang ito ng kaalaman sapagkat kahit na ang application na ito ay magagawa, ang impormasyong ito ay gagamitin para sa iba pang mga inisyatibo kaya kailangan nating tiyakin mayroon tayong lahat na dokumentado para sa mga pagpapatupad sa hinaharap.

Muli, bumababa tayo sa mga bagay tulad ng mga uri ng data, mga susi, index, ang data ng modelo mismo ay mayroong mga patakaran ng negosyo na naglalaro. Ang mga relasyon ay hindi lamang hadlang sa pagitan ng iba't ibang mga talahanayan; madalas nilang tinutulungan kaming ilarawan kung ano ang totoong mga patakaran sa negosyo sa paligid kung paano kumikilos ang data na iyon at kung paano ito gumagana bilang isang cohesive unit. At syempre, napakahalaga ng mga paghihigpit sa halaga. Ngayon siyempre, ang isa sa mga bagay na patuloy nating nakikipag-ugnayan, at ito ay nagiging higit at higit na laganap, ay mga bagay tulad ng pamamahala ng data. Kaya mula sa isang pananaw ng pamamahala ng data, kailangan din nating tingnan, ano ang tinukoy namin dito? Nais naming tukuyin ang mga bagay tulad ng pag-uuri ng seguridad. Anong mga uri ng data ang kinakaharap natin? Ano ang maituturing na pamamahala ng data ng master? Ano ang mga transactional store na nilikha natin? Anong sangguniang data ang ginagamit namin sa mga application na ito? Kailangan nating tiyakin na maayos na nakuha sa aming mga modelo. At din ang mga pagsasaalang-alang sa kalidad ng data, may ilang mga piraso ng impormasyon na mas mahalaga sa isang samahan kaysa sa iba.

Ako ay kasangkot sa mga proyekto kung saan kami ay nagpapalit ng higit sa isang dosenang mga sistema ng pamana sa mga bagong proseso ng negosyo at pagdidisenyo ng mga bagong aplikasyon at mga tindahan ng data upang mapalitan ang mga ito. Kailangan naming malaman kung saan nagmumula ang impormasyon. Alin sa pinakamahalagang piraso ng impormasyon, mula sa isang pananaw sa negosyo, kung titingnan mo ang partikular na slide ng modelo ng data na nakuha ko dito, makikita mo na ang mga ilalim na kahon sa mga partikular na nilalang, na isang maliit na subset lamang, ako aktwal na nagawang makuha ang halaga ng negosyo. Kung mataas, daluyan o mababa para sa mga ganitong uri ng mga bagay para sa iba't ibang mga konstruksyon sa loob ng samahan. At nakuha ko rin ang mga bagay tulad ng mga klase ng master data, kung sila ay mga talahanayan ng master, maging sila ay sanggunian, kung sila ay transactional. Kaya maaari naming pahabain ang aming metadata sa aming mga modelo upang mabigyan kami ng maraming iba pang mga katangian sa labas ng data mismo, na talagang nakatulong sa amin sa iba pang mga inisyatibo sa labas ng mga orihinal na proyekto at isulong ito. Ngayon na marami sa isang slide, pupunta ako sa daanan ng mga ito nang medyo mabilis.

Pupunta ako ngayon sa mabilis na pag-uusapan tungkol sa kung ano ang ginagawa ng isang modelo ng data habang pinagdadaanan namin ang iba't ibang mga sprints na ito. Una sa lahat, isang buong kalahok sa mga sesyon sa pagpaplano ng sprint, kung saan dadalhin namin ang mga kwento ng gumagamit, na ipinagkaloob sa kung ano ang ihahatid namin sa sprint na iyon, at pag-isipan kung paano namin bubuuin ito at maihatid ito. Ang ginagawa ko rin bilang isang modelo ng data ay alam kong nagtatrabaho ako sa magkahiwalay na lugar na may iba't ibang mga developer o sa iba't ibang mga tao. Kaya ang isa sa mga mahahalagang katangian na maaari nating magkaroon ay kapag gumagawa tayo ng isang modelo ng data, maaari nating hatiin ang modelong data na iyon sa iba't ibang mga pananaw, tinawag mo rin silang mga paksa na sakop o sub-modelo, ay ang aming terminolohiya. Kaya habang pinapagpapalakas natin ang modelo ay ipinapakita din natin ito sa iba't ibang mga pananaw na sub-modelo upang makita ng mga iba't ibang mga madla kung ano ang may kaugnayan sa kanila upang makakapagtutuon sila sa kung ano ang kanilang pagbubuo at isulong. Kaya maaari akong magkaroon ng isang tao na nagtatrabaho sa isang bahagi ng pag-iiskedyul ng isang aplikasyon, maaaring mayroon akong ibang tao na nagtatrabaho sa isang pagpasok sa order kung saan ginagawa namin ang lahat ng mga bagay na ito sa isang solong sprint, ngunit maaari kong bigyan sila ng mga pananaw sa pamamagitan ng mga sub-modelo na lamang mag-apply sa lugar na kanilang pinagtatrabahuhan. At pagkatapos ang mga gumulong hanggang sa pangkalahatang modelo at ang buong istraktura ng mga sub-modelo upang mabigyan ng iba't ibang mga pananaw sa madla ang kailangan nilang makita.

Ang mga batayan mula sa pananaw sa pagmomolde ng data na nais nating magkaroon, palaging magkaroon ng isang saligan na maaari nating balikan dahil ang isa sa mga bagay na kailangan nating magawa ay, kung ito ay nasa katapusan ng isang sprint o sa dulo ng ilang mga sprints, nais naming malaman kung saan kami nagsimula at palaging may isang baseline upang malaman kung ano ang delta o ang pagkakaiba ng ginawa namin sa isang naibigay na sprint. Kailangan din nating tiyakin na maaari tayong magkaroon ng isang mabilis na pag-ikot. Kung napasok mo ito bilang isang modelo ng data ngunit sa tradisyunal na papel ng gatekeeper na nagsasabing "Hindi, hindi, hindi mo magagawa iyon, kailangan muna nating gawin ang lahat ng bagay na ito, " ikaw ay aalisin mula sa koponan kung talagang kailangan mo upang maging isang aktibong kalahok sa lahat ng mga maliksi na koponan ng pag-unlad. Nangangahulugan ito na ang ilang mga bagay ay nahuhulog sa kariton na gumagawa ng isang naibigay na sprint at kinuha mo ang mga ito sa ibang mga sprint.

Bilang isang halimbawa, maaari kang tumuon sa mga istruktura ng data upang makuha ang sasabihin, ang order na piraso ng pagpasok na pinag-uusapan ko. Sa susunod na sprint, maaari kang bumalik at punan ang data tulad ng ilan sa mga babasahin para sa diksyunaryo ng data sa paligid ng ilan sa mga artifact na iyong nilikha. Hindi mo makumpleto ang kahulugan na lahat sa isang sprint; pupunta ka sa patuloy na pagpunta sa iyong mga naghahatid ng pagtaas dahil may mga oras na maaari mong punan ang impormasyong ito na nagtatrabaho sa mga analyst ng negosyo kapag ang mga developer ay abala sa pagbuo ng mga aplikasyon at pagtitiyaga sa paligid ng mga tindahan ng data. Nais mong mapabilis at hindi ang bottleneck. Mayroong iba't ibang mga paraan na nakikipagtulungan kami sa mga developer. Para sa ilang mga bagay na mayroon kaming mga pattern ng disenyo kaya kami ay isang buong kalahok sa harap, kaya maaari kaming magkaroon ng isang pattern ng disenyo kung saan sasabihin namin na ilalagay namin ito sa modelo, itutulak namin ito sa mga database ng sandbox ng mga developer at pagkatapos ay makakaya nila magsimulang magtrabaho dito at humiling ng mga pagbabago sa na.

Maaaring may iba pang mga lugar na pinagtatrabahuhan ng mga developer, nakakuha sila ng isang bagay na kanilang pinagtatrabahuhan at prototyping nila ang ilang mga bagay upang subukan nila ang ilang mga bagay sa kanilang sariling kapaligiran sa pag-unlad. Kinukuha namin ang database na pinagtatrabahuhan nila, dalhin ito sa aming tool sa pagmomolde, ihambing sa mga modelo na mayroon kami at pagkatapos ay malutas at itulak ang mga pagbabago pabalik sa kanila upang ma-refactor nila ang kanilang mga code kaya sinusunod nila ang wastong istruktura ng data na kailangan natin. Dahil maaaring lumikha sila ng ilang mga bagay na mayroon na kami sa ibang lugar, kaya siguraduhin namin na nagtatrabaho sila sa tamang mga mapagkukunan ng data. Pinapanatili lamang namin ang lahat ng mga paraan sa pamamagitan ng sa aming sprint upang makuha namin ang buong paghahatid ng data, buong dokumentasyon at kahulugan ng lahat ng mga istruktura ng data na aming ginagawa.

Ang pinakamatagumpay na mga maliksi na proyekto na ako ay kasangkot sa mga tuntunin ng napakahusay na paghahatid ay, nagkaroon kami ng isang pilosopiya, modelo ng lahat ng mga pagbabago sa buong pisikal na detalye ng database. Sa esensya, ang modelo ng data ay nagiging mga naka-deploy na mga database na nagtatrabaho ka para sa anumang bago na aming nilikha at may buong sanggunian ng iba pang mga tindahan ng data kung kumokonsulta tayo mula sa iba pang mga labas ng mga database. Bilang bahagi na kami ay gumagawa ng mga karagdagang script kumpara sa paggawa ng isang buong henerasyon sa bawat oras. At ginagamit namin ang aming mga pattern ng disenyo upang bigyan kami ng mabilis na pag-angat sa mga tuntunin ng pagkuha ng mga bagay na pupunta sa mga sprints kasama ang iba't ibang mga koponan ng pag-unlad na nagtatrabaho kami.

Sa mga aktibidad din ng sprint, muli na ang baseline para sa paghahambing / pagsamahin, kaya kunin natin ang ideya ng pagmomodelo sa bawat pagbabago. Sa bawat oras na gumawa tayo ng pagbabago, ang nais nating gawin ay nais nating mai-modelo ang pagbabago at kung ano ang napakahalaga, kung ano ang nawawala mula sa pagmomolde ng data hanggang sa kamakailan lamang, sa katunayan, hanggang sa muling maisagawa natin ito, ay ang kakayahang maiugnay ang pagmomolde mga gawain at iyong mga naihahatid sa mga kwentong gumagamit at mga gawain na talagang nagiging sanhi ng mga pagbabagong iyon. Nais naming suriin ang aming mga pagbabago sa modelo, sa parehong paraan na suriin ng mga developer sa kanilang mga code, tinukoy ang mga kwentong gumagamit na mayroon kami upang malaman namin kung bakit namin ginawa ang mga pagbabago sa unang lugar, iyon ay isang bagay na ginagawa namin. Kapag ginawa natin iyon, bubuo tayo ng aming mga script ng DDL ng karagdagang at mai-post ang mga ito upang maaari silang mapili kasama ang iba pang mga naghahatid ng pag-unlad at sinuri sa aming solusyon sa pagbuo. Muli, maaari kaming magkaroon ng isang modelo o nagtatrabaho sa maraming mga koponan. At tulad ng napag-usapan ko, ang ilang mga bagay ay nagmula sa modelo ng data, ang iba pang mga bagay ay nagmula sa mga nag-develop at nagkita kami sa gitna upang makabuo ng pangkalahatang pinakamahusay na disenyo at itulak ito pasulong at tiyaking maayos itong dinisenyo sa aming pangkalahatang mga istruktura ng data. Kailangan nating mapanatili ang disiplina ng pagtiyak na mayroon tayong lahat ng tamang mga konstruksyon sa aming modelo ng data habang nagpapatuloy tayo, kasama na ang mga bagay na tulad ng walang saysay na mga halaga, mga referensyong mga hadlang, karaniwang suriin ang mga hadlang, lahat ng mga bagay na karaniwang iniisip natin tungkol sa .

Pag-usapan natin ngayon ang ilan lamang sa mga screenshot ng ilan sa mga tool na makakatulong sa amin gawin ito. Ang sa palagay ko ay mahalaga ay ang pagkakaroon ng nagtitipid na imbakan, kaya kung ano ang maaari nating gawin bilang mga modelo ng data - at ito ay isang snippet ng bahagi ng isang modelo ng data sa background - ay kapag nagtatrabaho tayo sa mga bagay na nais nating siguraduhin na kaya natin magtrabaho lamang sa mga bagay na kailangan nating baguhin, gawin ang mga pagbabago, bubuo ng aming mga script ng DDL para sa mga pagbabagong nagawa natin habang sinuri natin ang mga bagay na bumalik. Kaya kung ano ang magagawa natin, sa ER Studio ay isang halimbawa. maaari nating suriin ang mga bagay o grupo ng mga bagay upang magawa, hindi natin kailangang suriin ang isang buong modelo o sub-modelo, maaari nating suriin ang mga bagay na interes lamang sa amin. Ang nais naming pagkatapos nito ay nasa alinman sa pag-check-out o pag-check-in - ginagawa namin ang parehong mga paraan dahil ang iba't ibang mga pangkat ng pag-unlad ay gumagana sa iba't ibang paraan. Nais naming tiyakin na iniuugnay namin na sa kwento ng gumagamit o gawain na nagmamaneho ng mga kinakailangan para dito at iyon ang magiging parehong kwento ng gumagamit o gawain na bubuo ng mga developer at suriin ang kanilang code para sa.

Kaya narito ang isang napakabilis na snippet ng isang pares ng mga screen ng isa sa aming mga sentro ng pamamahala ng pagbabago. Ano ang ginagawa nito, hindi ako dumadaan sa mahusay na detalye dito, ngunit ang nakikita mo ay ang kwento ng gumagamit o gawain at indentong nasa ilalim ng bawat isa sa mga nakikita mo sa aktwal na mga tala ng pagbabago - gumawa kami ng isang awtomatikong talaan ng pagbabago ginagawa namin ang pag-check-in at pag-check-out at maaari naming ilagay ang higit pang paglalarawan sa talaan ng pagbabago na iyon. Ito ay nauugnay sa gawain, maaari kaming magkaroon ng maraming mga pagbabago sa bawat gawain, tulad ng inaasahan mo. At kapag napunta tayo sa rekord ng pagbabago na maaari nating tingnan ito at mas mahalaga na makita, ano talaga ang nagbago natin? Para sa partikular na ito, ang naka-highlight na kwento doon ay mayroon akong isang uri ng pagbabago na ginawa at nang tiningnan ko ang aktwal na tala ng pagbabago, kinilala nito ang mga indibidwal na piraso sa modelo na nagbago. Nagbago ako ng isang pares ng mga katangian dito, naitago ang mga ito at dinala ito para sa pagsakay sa mga pananaw na kailangang mabago na nakasalalay din sa mga ito upang sila ay mabuo sa nadagdagan na DLL. Ito ay hindi lamang pagmomolde sa mga bagay na base, ngunit ang isang de-kalidad na tool ng pagmomolde na tulad nito ay nakakakita rin ng mga pagbabago na kailangang ma-rippled sa pamamagitan ng mga nakasalalay na bagay sa database o data model din.

Kung nagtatrabaho kami sa mga developer, at ginagawa namin ito sa isang iba't ibang mga bagay, na gumagawa ng isang bagay sa kanilang sandbox at nais naming ihambing at makita kung nasaan ang mga pagkakaiba, gumagamit kami ng ihambing / pagsamahin ang mga kakayahan kung saan sa kanang bahagi at kaliwa panig. Masasabi natin, "Narito ang aming modelo sa kaliwa, narito ang kanilang database sa kanang bahagi, ipakita sa akin ang mga pagkakaiba." Maaari nating piliin at piliin kung paano natin malulutas ang mga pagkakaiba, kung itulak natin ang mga bagay sa database o kung may ilang mga bagay na mayroon sila sa database na ibabalik namin sa modelo. Maaari kaming pumunta sa bidirectional upang makapunta kami sa parehong mga direksyon nang sabay-sabay na pag-update ng parehong mapagkukunan at target at pagkatapos ay makagawa ng mga nadagdag na script ng DDL upang maibahagi ang mga pagbabagong iyon sa kapaligiran ng database mismo, na napakahalaga. Ang maaari nating gawin ay maaari rin nating gamitin ito ihambing at pagsamahin ang kakayahan sa anumang naibigay na oras, kung kumukuha tayo ng mga snapshot sa daan, maaari nating laging ihambing ang pagsisimula ng isang sprint upang magsimula o magtapos ng isa pang sprint upang makita natin ang buong pagdaragdag ng pagbabago ng kung ano ang nagawa sa isang naibigay na sprint ng pag-unlad o sa isang serye ng mga sprint.

Ito ay isang napakabilis na halimbawa ng isang pagbabago ng script, alinman sa iyo na nakikipagtulungan sa mga database ay nakakita ng ganitong uri ng bagay, ito ang maaari nating itulak sa labas ng code bilang isang pagbabago ng script upang matiyak nating sigurado tayo panatilihin ang mga bagay dito. Ang hinugot ko rito, para mabawasan lang ang kalat, ay kung ano ang ginagawa din natin sa mga nabalitang script na ito ay ipinapalagay namin na mayroong mga data sa mga talahanayan na rin, kaya bubuo din tayo ng DML na kukuha ng impormasyon ng mga pansamantalang talahanayan at itulak muli ito sa mga bagong istruktura ng data kaya't tinitingnan namin hindi lamang ang mga istruktura kundi ang data na maaari na rin namin na nakapaloob sa mga istrukturang ito.

Ang pagpunta sa pag-uusap nang napakabilis tungkol sa mga awtomatikong build system dahil kapag gumagawa kami ng isang maliksi na proyekto medyo madalas kami ay nagtatrabaho sa mga awtomatikong build system kung saan kailangan nating suriin sa iba't ibang mga naghahatid na magkasama upang matiyak na hindi natin masisira ang aming mga build. Ano ang ibig sabihin nito ay nai-synchronize namin ang mga naghahatid, ang mga pagbabago ng script na binanggit ko tungkol sa script ng DDL ay kailangang suriin, ang kaukulang aplikasyon ng code ay kailangang suriin nang sabay-sabay at maraming mga pag-unlad ng pagbuo ngayon siyempre ay hindi ginagawa gamit ang direktang SQL laban sa mga database at na uri ng bagay. Madalas na ginagamit namin ang mga pagbabalangkas na mga balangkas o pagtatayo ng mga serbisyo ng data. Kailangan nating tiyakin na ang mga pagbabago para sa mga balangkas o serbisyo ay naka-check in nang eksakto sa parehong oras. Pumasok sila sa isang awtomatikong sistema ng pagbuo sa ilang mga samahan at kung ang mga break break, sa isang maliksi na pamamaraan, lahat ng mga kamay sa pag-aayos ng kubyerta na binuo bago tayo ay sumulong upang malaman natin na mayroon tayong isang gumaganang solusyon bago tayo magpatuloy. At ang isa sa mga proyekto na kasangkot ako, kinuha namin ito sa isang matinding - kung nasira ang build na aktwal na nakalakip kami sa isang bilang ng mga computer sa aming lugar kung saan kami ay kolektahin sa mga gumagamit ng negosyo, mayroon kaming mga pulang kumikislap na ilaw tulad ng tuktok ng mga kotse ng pulisya. At kung nasira ang build, ang mga pulang ilaw na kumikislap na ito ay nagsimulang umalis at alam namin na ang lahat ay kamay sa kubyerta: ayusin ang build at pagkatapos ay magpatuloy sa ginagawa namin.

Nais kong pag-usapan ang iba pang mga bagay, at ito ay isang natatanging kakayahan sa ER Studio, nakakatulong talaga ito kapag sinusubukan nating itayo ang mga artifact bilang mga developer para sa mga hangganan na ito, mayroon tayong konsepto na tinatawag na mga data ng negosyo at kung ano ang nagpapahintulot sa amin na ang gawin ay kung titingnan mo ang napakasimpleng modelo ng data bilang isang halimbawa, pinapayagan kaming mag-encapsulate ng mga nilalang o grupo ng mga nilalang para sa kung saan ang mga hangganan ng pagtitiyaga. Kung saan bilang isang modelo ng data ay maaaring mag-isip ng isang bagay tulad ng header ng order ng pagbili at pag-align ng order at iba pang detalyadong mga talahanayan na itatali sa paraan sa pagbuo nito at kailangan malaman ng aming mga developer ng serbisyo ng data kung paano nagpapatuloy ang mga bagay sa mga iba't ibang data istruktura. Iniisip ng aming mga developer ang mga bagay tulad ng order ng pagbili bilang isang pangkalahatang bagay at kung ano ang kanilang kontrata sa kung paano nila nilikha ang mga partikular na bagay. Maaari naming ilantad ang detalyeng teknikal na iyon upang makita ng mga tao na bumubuo ng mga data server kung ano ang nasa ilalim nito at maaari nating protektahan ang iba pang mga madla mula sa pagiging kumplikado upang makita lamang nila ang iba't ibang mga bagay na mas mataas na antas, na gumagana din nang maayos para sa pakikipag-usap sa negosyo analyst at mga stakeholder ng negosyo kapag pinag-uusapan natin ang pakikipag-ugnay ng iba't ibang mga konsepto sa negosyo.

Ang magaling na bagay tungkol doon pati na rin namin ay matatag na palawakin at ibagsak ang mga ito upang mapanatili natin ang mga ugnayan sa pagitan ng mga bagay na mas mataas na order kahit na nagmula ito sa mga konstruksyon na nakapaloob sa loob ng mga bagay na data ng negosyo sa kanilang sarili. Ngayon bilang isang modelo, hanggang sa dulo ng sprint, sa pagtatapos ng sprint wrap-up, marami akong mga bagay na kailangan kong gawin, na tinawag ko ang aking pag-aayos ng bahay para sa susunod na sprint. Bawat sprint na nilikha ko ang tinatawag kong Named Release - na nagbibigay sa akin ng aking baseline para sa kung ano ang mayroon ako ngayon sa pagtatapos ng paglabas. Kaya nangangahulugan iyon na ang aking baseline ay pasulong, ang lahat ng mga saligan na ito o Pinangalanang Paglabas na nilikha at nai-save ko sa aking reposit na maaari kong magamit upang gumawa ng isang paghahambing / pagsamahin upang maaari kong palaging ihambing sa anumang naibigay na pagtatapos ng sprint mula sa anumang iba pang sprint, na kung saan Napakahalaga na malaman kung ano ang iyong mga pagbabago sa iyong modelo ng data sa paraan sa paglalakbay nito.

Gumagawa din ako ng isang script ng delta DDL gamit ang ihambing / pagsamahin muli mula sa simula hanggang sa dulo ng sprint. Maaaring nasuri ko sa isang buong grupo ng mga nadagdag na script, ngunit kung kailangan ko ito mayroon ako ngayon ng isang script na maaari kong i-deploy upang tumayo ng iba pang mga sandbox upang masabi ko lang ito na kung ano ang mayroon kami sa simula ng isang sprint, itulak sa pamamagitan nito, magtayo ng isang database bilang isang sandbox upang magsimula sa susunod na sprint at maaari din nating gamitin ang mga bagay na iyon upang gawin ang mga bagay tulad ng mga pangyayari sa standup QA at sa huli syempre nais nating itulak ang ating mga pagbabago sa produksiyon kaya marami tayong mga nangyayari sa parehong oras. Muli, ganap naming nakikilahok sa pagpaplano at retrospectives ng sprint, ang mga retrospective ay talagang mga aralin na natutunan at napakahalaga, dahil mabilis kang makakapunta sa mabilis, kailangan mong ihinto at ipagdiwang ang mga tagumpay, tulad ngayon. Alamin kung ano ang mali, gawin itong mas mahusay sa susunod na oras sa paligid, ngunit ipagdiwang din ang mga bagay na napunta nang tama at bumuo sa mga ito habang patuloy kang sumusulong sa susunod na mga sprints na pasulong.

Pupunta ako ngayon sa napakabilis na pag-uusap tungkol sa halaga ng negosyo. Mayroong isang proyekto na nakasama ko sa maraming mga taon na ang nakakaraan na nagsimula bilang isang maliksi na proyekto, at ito ay isang matinding proyekto, kaya ito ay isang purong koponan ng pag-aayos ng sarili kung saan ang mga developer lamang ang gumagawa ng lahat. Upang makagawa ng isang mahabang kwento ng maikling, ang proyektong ito ay nakakatigil at nahanap nila na sila ay gumugugol nang maraming beses sa remediating at pag-aayos ng mga depekto na kinilala kaysa sila ay nagtulak sa higit pang pag-andar at, sa katunayan, kapag tiningnan nila ito batay sa mga nasusunog na tsart na kakailanganin nilang pahabain ang proyekto ng anim na buwan sa isang malaking gastos. At nang tiningnan namin ito, ang paraan upang mabigyan muli ang problema ay ang paggamit ng isang tamang tool sa pagmomolde ng data na may isang dalubhasang modelo ng data na kasangkot sa proyekto mismo.

Kung titingnan mo ang vertical bar na ito sa partikular na tsart, ipinapakita nito ang pinagsama-samang mga depekto laban sa mga pinagsama-samang mga bagay, at pinag-uusapan ko ang tungkol sa mga bagay na data o konstruksyon na nilikha tulad ng mga talahanayan na may mga hadlang at mga uri ng mga bagay, kung tiningnan mo bago ito ipinakilala ang modelo ng data, ang bilang ng mga depekto ay talagang lumampas at nagsisimulang bumuo ng kaunting puwang sa aktwal na bilang ng mga bagay na ginawa hanggang sa puntong iyon sa oras. Matapos ang linggo 21, iyon ay nang pumasok ang data modeler, refactored ang data model batay sa kung ano ang dapat ayusin ang isang bilang ng mga bagay at pagkatapos ay nagsimula ang pagmomolde bilang bahagi ng koponan ng proyekto pasulong, ang mga pagbabago habang ang proyekto ay itinutulak pasulong . At nakita mo ang isang napakabilis na pag-turnaround na sa loob ng halos isang sprint at kalahati, nakita namin ang isang malaking pag-uptick sa bilang ng mga bagay at mga konstruksyon ng data na nabuo at itinayo dahil kami ay bumubuo ng isang tool sa pagmomolde ng data sa halip na isang stick sticker pagtatayo ng mga ito sa isang kapaligiran, at tama ang mga ito dahil mayroon silang wastong referral na integridad at ang iba pang mga konstruksyon na dapat magkaroon nito. Ang antas ng mga depekto laban sa mga halos flatline. Sa pamamagitan ng pagsasagawa ng naaangkop na aksyon at tiyakin na ang data modeling ay ganap na nakikibahagi, ang proyekto ay naihatid sa oras na may mas mataas na antas ng kalidad, at sa katunayan, hindi ito maihatid sa lahat kung ang mga hakbang na ito ay hindi naganap. Maraming mga maliksi na pagkabigo sa labas, maraming mga tagumpay din kung makakakuha ka ng mga tamang tao na may kasamang tamang papel. Ako ay isang malaking proponent ng maliksi bilang isang pagpapatakbo ng disiplina, ngunit kailangan mong tiyakin na mayroon kang mga kasanayan sa lahat ng mga tamang pangkat na kasangkot bilang iyong mga koponan sa proyekto habang nagpapatuloy ka sa isang maliksi na uri ng pagpupunyagi.

Upang buod, ang mga arkitekto ng data at modelo ay dapat na kasangkot sa lahat ng mga proyekto sa pag-unlad; sila talaga ang pandikit na nagtataglay ng lahat dahil bilang mga modelo ng data at arkitekto naiintindihan natin, hindi lamang ang mga konstruksyon ng data ng ibinigay na proyekto sa pag-unlad, kundi pati na rin kung saan umiiral ang data sa samahan at kung saan maaari nating mapagkukunan ang data na iyon at kung paano din ito ay gagamitin at magamit sa labas ng partikular na application mismo na kami ay nagtatrabaho. Naiintindihan namin ang mga kumplikadong ugnayan ng data at pinakamahalaga na makapag-pasulong at mula sa isang pananaw ng pamamahala upang mapa ang dokumento at maunawaan kung ano ang hitsura ng iyong buong buong data.

Ito ay tulad ng pagmamanupaktura; Galing ako sa background ng pagmamanupaktura. Hindi mo maaaring suriin ang kalidad sa isang bagay sa dulo - kailangan mong bumuo ng kalidad sa iyong disenyo ng paitaas at sa iyong paraan, at ang pagmomolde ng data ay isang paraan ng pagbuo ng kalidad na iyon sa disenyo sa isang mahusay at mabisang gastos sa buong paraan sa pamamagitan ng . At muli, isang bagay na dapat tandaan - at hindi ito dapat maging trite, ngunit ito ang katotohanan - ang mga aplikasyon ay darating at pupunta, ang data ay ang mahahalagang pag-aari ng korporasyon at nalalampasan nito ang lahat ng mga hangganan ng aplikasyon. Sa bawat oras na inilalagay mo ang isang application marahil ay hinihilingin mong mapanatili ang data mula sa iba pang mga application na nauna, kaya kailangan nating tandaan na ito ay isang mahalagang pag-aari ng kumpanya na patuloy nating pinapanatili ang paglipas ng panahon.

At ito na! Mula dito ay kukuha kami ng higit pang mga katanungan.

Eric Kavanagh: Sige, mabuti, hayaan mo akong itapon muna kay Robin. At saka, Dez, sigurado akong mayroon kang ilang mga katanungan. Alisin mo ito, Robin.

Robin Bloor: Okay. Upang maging matapat, hindi ako nagkaroon ng anumang problema sa mga pamamaraan ng pag-unlad ng maliksi at tila sa akin kung ano ang ginagawa mo dito ay gumagawa ng natatanging kahulugan. Naaalala ko ang pagtingin sa isang bagay noong 1980 na nagpahiwatig, talaga, na ang problema na aktwal mong pinasukan sa isang tuntunin ng isang proyekto na umiikot sa labas ng kontrol, ay normal kung hahayaan mo ang isang pagkakamali na magpapatuloy na lampas sa isang partikular na yugto. Ito ay nagiging mas at mahirap na ayusin kung hindi mo nakuha ang yugtong iyon nang tama, kaya isa sa mga bagay na ginagawa mo dito - at sa palagay ko ito ang slide - ngunit isa sa mga bagay na ginagawa mo dito sa sprint zero, sa aking palagay, ay talagang mahalaga dahil sinusubukan mo talagang makuha ang mga paghahatid na naka-pin doon. At kung hindi ka nakakakuha ng mga pinadala na naka-pin, pagkatapos ay maihahatid ang pagbabago ng hugis.

Iyon, uri ng, aking opinyon. Ito rin ang aking opinyon - wala akong anumang argumento sa ideya na nakuha mo upang makuha ang data ng pagmomolde ng tama sa isang tiyak na antas ng detalye bago ka dumaan. Ano ang nais kong subukan at gawin dahil hindi ko kumpleto ang kahulugan nito, ay ilalarawan lamang ang isa sa mga proyektong ito sa mga tuntunin ng laki nito, sa mga tuntunin kung paano ito dumaloy, sa mga tuntunin ng kung sino, alam mo, kung saan naganap ang mga problema, naresolba na ba? Dahil sa palagay ko ang slide na ito ay halos lahat ng puso nito at kung maipaliliwanag mo nang kaunti ang tungkol dito, magpapasalamat ako.

Ron Huizenga: Oo naman, at gagamit ako ng ilang mga halimbawa ng mga proyekto. Ang isa na, uri ng, ay umalis sa mga riles na ibinalik sa pamamagitan ng aktwal na pagkuha ng tamang mga tao na kasangkot at paggawa ng pagmomolde ng data at lahat ng bagay ay talagang isang paraan ng pagtiyak na ang disenyo ay naiintindihan nang mas mahusay at malinaw na kami ay may mas mahusay na disenyo ng pagpapatupad on the way through by modelling it. Sapagkat kapag modelo mo ito, alam mo, maaari kang makabuo ng iyong DDL at lahat ng bagay sa likuran at labas ng tool kaysa sa pagkakaroon na manatiling itayo tulad ng mga tao ay maaaring karaniwang gawin sa pamamagitan ng pagdiretso sa isang kapaligiran sa database. At ang mga karaniwang bagay na mangyayari sa mga developer ay pupunta sila doon at sasabihin nila, okay, kailangan ko ang mga talahanayan na ito. Sabihin nating ginagawa namin ang mga order entry. Kaya maaari silang lumikha ng order header at mga talahanayan ng detalye ng order, at mga uri ng mga bagay. Ngunit madalas nilang kalimutan o pababayaan upang matiyak na ang mga hadlang ay naroroon upang kumatawan sa mga dayuhang susi na ugnayan. Maaaring hindi nila tama ang mga susi. Ang pangalan ng mga kombensyon ay maaaring pinaghihinalaan din. Hindi ko alam kung ilang beses na akong napunta sa isang kapaligiran, halimbawa, kung saan nakikita mo ang isang bungkos ng iba't ibang mga talahanayan na may iba't ibang mga pangalan, ngunit kung gayon ang mga pangalan ng haligi sa mga talahanayan ay tulad ng ID, Pangalan, o anuman, kaya sila talagang nawala ang konteksto nang wala ang talahanayan ng eksakto kung ano iyon.

Kaya, karaniwang kapag kami ay nagmomodelo ng data ay sisiguraduhin namin na inilalapat namin ang wastong pagbibigay ng mga kombensyon sa lahat ng mga artifact na nabuo din sa DDL. Ngunit upang maging mas tukoy tungkol sa likas na katangian ng mga proyekto mismo, sa pangkalahatan, nagsasalita ako tungkol sa medyo malaking mga inisyatibo. Ang isa sa kanila ay $ 150 milyong proyekto ng pagbabago ng negosyo kung saan pinalitan namin ang higit sa isang dosenang mga sistema ng legacy. Mayroon kaming limang magkakaibang mga maliksi na koponan na nagpapatuloy nang sabay. Mayroon akong isang buong koponan ng arkitektura ng data, kaya mayroon akong mga modelo ng data mula sa aking koponan na naka-embed sa bawat isa sa iba pang mga koponan ng lugar ng aplikasyon, at nagtatrabaho kami sa isang kumbinasyon ng mga dalubhasa sa negosyo na nasa bahay na alam ang paksa, na ginagawa ang mga kwento ng gumagamit para sa kanilang mga kinakailangan. Mayroon kaming mga analyst ng negosyo sa bawat isa sa mga koponan na aktwal na nagmomolde sa proseso ng negosyo, kasama ang mga diagram ng aktibidad o mga diagram ng proseso ng negosyo, na tumutulong sa laman ng mga kwento ng gumagamit nang higit pa sa mga gumagamit bago nila nakuha ang natitira sa koponan din.

At pagkatapos, siyempre, ang mga developer na nagtatayo ng application code sa tuktok ng iyon. At nagtatrabaho rin kami, sa palagay ko ito ay apat na magkakaibang sistema ng mga nagtitinda ng pagsasama na nagtatayo ng iba't ibang bahagi ng application pati na rin kung saan ang isang koponan ay nagtatayo ng mga serbisyo ng data, ang iba ay nagtatayo ng logic ng aplikasyon sa isang lugar, isa pa na may kadalubhasaan sa ibang lugar ng negosyo ay ang pagbuo ng application logic sa lugar na iyon. Kaya nagkaroon kami ng isang buong pakikipagtulungan ng mga tao na nagtatrabaho sa proyektong ito. Sa isang partikular na mayroon kaming 150 mga tao sa baybayin sa koponan at isa pang 150 mapagkukunan sa baybayin sa koponan na nakikipagtulungan ng dalawang linggong sprint upang palayasin ang bagay na ito. At upang gawin iyon kailangan mong tiyakin na nagpaputok ka sa lahat ng mga cylinders, at lahat ay maayos na naka-synchronize sa mga tuntunin ng kung ano ang kanilang mga naihatid, at mayroon kang mga madalas na pag-reset upang matiyak na nakumpleto namin ang aming mga paghahatid ng lahat ng kinakailangang mga artifact sa dulo ng bawat sprint.

Robin Bloor: Mahusay na kahanga-hanga. At para lamang sa isang maliit na detalye sa na - natapos ka ba ng isang kumpletong, ano ang tatawagin ko, mapa ng MDM ng buong lugar ng data sa katapusan ng proyekto na iyon?

Ron Huizenga: Mayroon kaming isang kumpletong modelo ng data na nasira kasama ang agnas sa lahat ng iba't ibang mga lugar ng negosyo. Ang diksyunaryo ng data mismo sa mga tuntunin ng buong kahulugan ay nahulog nang kaunti. Marami kaming mga talahanayan na tinukoy; mayroon kaming karamihan sa mga haligi na tinukoy kung ano mismo ang ibig sabihin nito. Mayroong ilan na wala doon at, kawili-wiling sapat, ang ilan sa mga piraso ng impormasyon na nagmula sa mga sistemang pamana kung saan, pagkatapos ng katapusan ng proyekto saklaw, na ito ay nai-dokumentado bilang isang carry-forward na set ng artifact, tulad ng ito, sa labas ng proyekto mismo, dahil ito ay isang bagay na kinakailangan upang mapanatili ng samahan ng pasulong. Kaya't sa parehong oras ang samahan ay tumaas ng mas mataas na pananaw sa kahalagahan ng pamamahala ng data dahil nakita namin ang maraming mga pagkukulang sa mga sistemang pamana at mga pinagmumulang datos ng pamana na sinisikap naming ubusin dahil hindi sila na-dokumentado. Sa maraming mga pagkakataon mayroon lamang kaming mga database na kailangan nating baligtarin ang inhinyero at subukang malaman kung ano ang nariyan at kung ano ang impormasyon.

Robin Bloor: Hindi ako sorpresa sa partikular na aspeto nito. Ang pamamahala ng data ay, tawagan natin ito, isang napaka-modernong pag-aalala at sa palagay ko, talaga, mayroong maraming trabaho na, sabihin nating, dapat ay tapos na nang kasaysayan sa pamamahala ng data. Hindi ito dahil sa maaari mong, uri ng, lumayo sa hindi paggawa nito. Ngunit habang lumalaki at lumaki ang mapagkukunan ng data, sa huli hindi mo magawa.

Pa rin, ipapasa ko kay Dez dahil sa palagay ko ay inilaan ko ang aking inilaang oras. Dez?

Dez Blanchfield: Oo, salamat. Sa pamamagitan ng buong bagay na ito ay pinapanood at iniisip ko sa aking sarili na pinag-uusapan natin ang nakakakita ng maliksi na ginamit sa galit sa maraming paraan. Kahit na nakuha ang negatibong konotasyon; Sinadya ko iyon sa isang positibong paraan. Maaari mo bang bigyan lang kami ng isang senaryo ng, ang ibig kong sabihin, mayroong dalawang lugar na nakikita kong ito ay isang perpektong hanay: ang isa ay mga bagong proyekto na kailangang gawin mula pa noong araw, ngunit sa palagay ko ay palagi, sa aking karanasan, madalas ang kaso na kapag ang mga proyekto ay nakakakuha ng sapat na malaki na ito ay kinakailangan sa maraming paraan, mayroong isang kawili-wiling hamon sa pagitan ng gluing ng dalawang mundo, di ba? Maaari mo bang ibigay sa amin ang anumang uri ng pananaw sa ilang mga kwentong tagumpay na nakita mo kung saan ka napunta sa isang samahan, naging malinaw na nakuha nila ang isang bahagyang pag-aaway ng dalawang mundo at nagawa mong matagumpay na ilagay ito sa lugar at magsasama ng mga malalaking proyekto kung saan maaaring hindi sila sumakay sa riles? Alam ko na ito ay isang malawak na tanong ngunit nagtataka lang ako kung mayroong isang partikular na pag-aaral sa kaso na maaari mong, uri ng, ituro sa kung saan sinabi mo, alam mo, inilalagay namin ang lahat sa lugar na ito at dinala ang lahat ng pangkat ng pag-unlad ang koponan ng data at kami, uri ng, ay nag-usap ng isang bagay na maaaring kung hindi man nalubog ang bangka?

Ron Huizenga: Oo naman, at sa katunayan ang isang proyekto na nangyari sa isang proyekto ng pipeline ay ang pinag-uusapan ko kung saan ko ipinakita ang tsart na may mga depekto bago at matapos ang data modeler. Madalas, at may mga paunang natukoy na mga paniwala, lalo na kung ang mga bagay ay spun up kung saan ito nagawa mula sa isang paningin na pag-unlad ng pananaw, ito lamang ang mga developer na kasangkot sa mga maliksi na proyekto upang maihatid ang mga aplikasyon. Kaya kung ano ang nangyari doon, siyempre, ay bumaba sila sa mga riles at ang kanilang mga artifact ng data sa partikular, o ang mga data na naghahatid na sila ay gumagawa, ay hindi natapos ang marka sa mga tuntunin ng kalidad at talagang tinutugunan ang mga bagay sa pangkalahatan. At mayroong madalas na maling kuru-kuro na ang mga data ng data ay magpapabagal ng mga proyekto, at gagawin nila kung ang data modeler ay walang tamang pag-uugali. Tulad ng sinasabi ko, kailangan mong mawala ang - kung minsan ay may mga data ng mga modelo na mayroon ng tradisyonal na saloobin ng gatekeeper kung saan, "Narito kami upang kontrolin kung ano ang hitsura ng mga istruktura ng data, " at ang pag-iisip ay kailangang mawala. Ang sinumang kasangkot sa pag-unlad ng maliksi, at lalo na ang mga modelo ng data, ay kailangang magsagawa ng papel bilang isang facilitator upang matulungan ang mga koponan na sumulong. At ang pinakamahusay na paraan upang mailarawan iyon ay upang mabilis na ipakita ang mga koponan kung paano maging produktibo ang mga ito sa pamamagitan ng pag-modelo ng mga pagbabago. At muli, iyon ang dahilan kung bakit ko napag-usapan ang pakikipagtulungan.

Mayroong ilang mga bagay na maaari naming unang modelo at makabuo ng DDL upang itulak sa mga nag-develop. Nais din nating tiyakin na hindi nila naramdaman na sila ay pinigilan. Kaya, kung may mga bagay na pinagtatrabahuhan nila, hayaan silang magpatuloy sa kanilang mga sandbox ng pag-unlad, dahil doon ay nagtatrabaho ang mga developer sa kanilang sariling mga desktop o iba pang mga database upang gumawa ng ilang mga pagbabago kung saan nila nasusubukan ang mga bagay. At makipagtulungan sa kanila at sabihing, "O sige, magtrabaho ka na." Dadalhin namin ito sa tool, malutas namin ito at pagkatapos ay itulak namin ito at bibigyan ka ng mga script na maaari mong i-deploy ito upang ma-update ang iyong ang mga database upang mai-upgrade ang mga ito sa kung ano ang aktwal na parusahan ng tunay na pagtingin sa produksiyon ng magiging nangyayari habang patuloy tayong sumulong. At maaari mong i-on iyon sa isang napakabilis na fashion. Natagpuan ko na ang aking mga araw ay napuno kung saan ako ay pabalik-balikan at may iterating na iba't ibang mga koponan sa pag-unlad, pagtingin sa mga pagbabago, paghahambing, pagbuo ng mga script, pagpunta sa kanila, at nagawa kong panatilihin ang aking sarili sa apat na mga koponan ng pagbuo nang madali sa sandaling madali kami nakamit ang isang momentum.

Dez Blanchfield: Ang isa sa mga bagay na nasa isip ko na, alam mo, maraming mga pag-uusap na kinukuha ko sa pang-araw-araw na batayan ay tungkol sa kargadang tren na darating sa amin, uri ng, ang machine-to -machine at IoT. At kung sa palagay namin marami kaming data ngayon sa aming kasalukuyang mga kapaligiran sa negosyo, alam mo, kung kukuha tayo ng mga unicorn sa isang sandali kung saan nalalaman natin na ang mga Googles at ang mga Facebook at ang Uber ay mayroong mga petabytes ng data, ngunit sa isang tradisyunal na negosyo na pinag-uusapan natin ang daan-daang mga terabytes at maraming data. Ngunit mayroong kargadang ito ng kargamento na dumarating sa mga samahan, sa aking pananaw, at binanggit ni Dr. Robin Bloor nang mas maaga ito, ng IoT. Alam mo, marami kaming trapiko sa web, mayroon kaming trapiko sa lipunan, nakuha na namin ngayon ang kadaliang mapakilos at mga aparatong mobile, ang ulap ay, uri ng, sumabog, ngunit ngayon mayroon kaming matalinong imprastruktura, matalinong mga lungsod at mayroong ang buong mundo ng data na sumabog lamang.

Para sa isang pang-araw-araw na samahan, isang daluyan hanggang sa malaking samahan na nakaupo roon at nakikita ang mundong ito ng sakit ay dumating sa kanila at hindi magkaroon ng isang agarang plano sa isipan, kung ano ang ilan sa mga takeaway, sa loob lamang ng ilang mga pangungusap, na mailalagay mo sa kanila kung kailan at kung saan kailangan nilang simulan ang pag-iisip ng pag-uusap tungkol sa paglalagay ng ilan sa mga pamamaraan na ito sa lugar. Gaano ka maaga kailangan nilang simulan ang pagpaplano upang halos umupo at magbayad ng pansin at sabihin na ito ang tamang oras upang makakuha ng ilang mga tool sa lugar at sanayin ang koponan at makakuha ng isang pag-uusap ng vocab na pumapaligid sa hamong ito? Gaano katagal ang huli sa kwento o kung kailan masyadong maaga? Ano ang hitsura ng ilan sa mga organisasyon na nakikita mo?

Ron Huizenga: Sasabihin ko sa karamihan sa mga samahan na kung hindi pa nila ito nagawa at inangkop ang data ng pagmomolde ng data at arkitektura ng data na may malalakas na tool tulad nito, ang oras na kailangan nilang gawin ito kahapon. Dahil kagiliw-giliw na, kahit ngayon, kung titingnan mo ang data sa mga samahan, marami kaming data sa aming mga samahan at sa pangkalahatan ay nagsasalita, batay sa ilang mga survey na aming nakita, ginagamit namin ang mas mababa sa limang porsyento ng data na iyon na epektibo kapag titingnan namin ang mga organisasyon. At sa IoT o kahit na NoSQL, malaking data - kahit na hindi lamang IoT, ngunit malaking data lamang sa pangkalahatan - kung saan nagsisimula kami ngayon kumonsumo ng higit pang impormasyon na nagmula sa labas ng aming mga samahan, ang hamon ay nagiging mas malaki at mas malaki sa lahat ng oras. At ang tanging paraan na magkaroon kami ng isang pagkakataon na makaya upang makatulong sa amin na maunawaan kung ano ang tungkol sa data na iyon.

Kaya, ang kaso ng paggamit ay medyo naiiba. Ang napag-alaman natin sa ating sarili ay kung titingnan natin ang datos na iyon, kinukuha natin ito, kailangan nating baligtarin ang inhinyero, tingnan kung ano ang nasa mga iyon, maging ito sa aming mga lawa ng data o kahit na sa aming mga in-house database, synthesize kung ano ang ang data ay, mag-apply ng mga kahulugan dito at mga kahulugan sa ito upang maunawaan natin kung ano ang data. Dahil hanggang sa maunawaan natin kung ano ito, hindi natin masiguro na ginagamit natin ito nang tama o sapat. Kaya kailangan nating makakuha ng isang hawakan sa kung ano ang data na iyon. At ang iba pang bahagi nito ay, huwag gawin ito dahil magagawa mo, sa mga tuntunin ng pag-ubos ng lahat ng panlabas na data na ito, tiyaking mayroon kang isang kaso ng paggamit na sumusuporta sa pag-ubos ng panlabas na data na ito. Tumutok sa mga bagay na kailangan mo sa halip na subukang hilahin at magamit ang mga bagay na maaaring kailanganin mo sa ibang pagkakataon. Tumutok muna sa mga mahahalagang bagay at habang pinagsisikapan mo ito, pagkatapos makakakuha ka ng pag-ubos at subukang maunawaan ang iba pang impormasyon mula sa labas.

Ang isang perpektong halimbawa nito ay, alam kong nakikipag-usap kami sa mga IoT at sensor, ngunit ang parehong uri ng problema ay talagang sa maraming mga organisasyon sa loob ng maraming taon, kahit na bago ang IoT. Ang sinumang may isang sistema ng control control, sila man ay isang tubo ng kumpanya, paggawa, anumang mga kumpanya na nakabase sa proseso na mayroong mga bagay kung saan ginagawa nila ang maraming automation na may mga kontrol at gumagamit sila ng mga stream ng data at mga bagay tulad nito, mayroon ang mga firehoses ng data na sinusubukan nilang inumin upang malaman, ano ang mga kaganapan na nangyari sa aking kagamitan sa paggawa upang mag-signal - ano ang nangyari at kailan? At sa gitna ng napakalaking stream ng data na ito ay may mga tiyak na piraso lamang ng impormasyon o mga tag na interesado sila na kailangan nilang mag-ayos, synthesize, modelo at maunawaan. At maaari nilang balewalain ang natitirang bahagi nito hanggang sa oras na talagang maunawaan ito, at pagkatapos ay maaari nilang mapalawak ang kanilang saklaw upang mas mahila pa ito sa saklaw, kung may katuturan iyon.

Dez Blanchfield: Ito ay, talaga. May isang katanungan na pupuntahan ko ang nagmula sa isang ginoong tinawag na Eric, at pribado kaming pinag-uusapan tungkol dito. Hiningi ko na lang ang kanyang pahintulot, na ibinigay niya, upang hilingin ito sa iyo. Dahil ito ay humahantong nang mabuti sa ito, upang mabalot lamang, dahil kaunti lang tayo sa paglipas ng panahon, at ibabalik ko kay Eric. Ngunit ang tanong mula sa isa pang Eric ay, makatwiran bang ipalagay na ang mga may-ari ng isang panimula ay pamilyar at maunawaan ang mga natatanging hamon sa paligid ng pagmomolde ng terminolohiya at kung gayon, o dapat itong ibigay sa ibang tao para sa interpretasyon? Kaya, sa madaling salita, ang isang pagsisimula ba ay may kakayahang at handa at handang at makapagtutuon at maihatid ito? O ito ay isang bagay na dapat nilang marahil mamili at magdala ng mga eksperto na nakasakay sa?

Ron Huizenga: Sa palagay ko ang maikling sagot ay nakasalalay talaga. Kung ito ay isang pagsisimula na hindi magkaroon ng isang tao sa loob ng bahay na isang arkitekto ng data o modelo na talagang naiintindihan ang database, kung gayon ang pinakamabilis na paraan upang magsimula ay ang pagdadala ng isang tao na may background sa pagkonsulta na napakahusay sa sanay na ito at makakakuha ng papunta sila. Dahil kung ano ang makikita mo - at sa katunayan, ginawa ko ito sa maraming mga pakikipagsapalaran na ginawa ko bago ako dumating sa madilim na bahagi sa pamamahala ng produkto - pupunta ba ako sa mga organisasyon bilang isang consultant, pamunuan ang kanilang mga data ng arkitektura ng data, upang maaari nilang, uri ng, muling itutok ang kanilang mga sarili at sanayin ang kanilang mga tao kung paano gawin ang mga ganitong uri ng mga bagay upang mapanatili nila ito at isulong ang misyon. At pagkatapos ay pupunta ako sa aking susunod na pakikipag-ugnay, kung may katuturan iyon. Mayroong isang pulutong ng mga tao na gumagawa doon, na may napakahusay na karanasan sa data na makakapunta sa kanila.

Dez Blanchfield: Iyan ay isang mahusay na takeaway point at lubos akong sumasang-ayon dito at sigurado ako na magkakaroon din si Dr. Robin Bloor. Lalo na sa isang pagsisimula, nakatuon ka sa pagiging isang SME sa partikular na halaga ng panukala na iyong hinahanap upang mabuo bilang bahagi ng iyong negosyo sa pagsisimula mismo at hindi mo marahil ay hindi kailangang maging isang dalubhasa sa lahat, kaya mahusay na payo. Ngunit maraming salamat, isang kamangha-manghang pagtatanghal. Talagang mahusay na mga sagot at tanong. Eric, ibabalik ako sa iyo dahil alam kong matagal kaming sampung minuto sa paglipas ng oras at alam kong gusto mong manatili malapit sa aming mga window windows.

Eric Kavanagh: Okay lang yan. Mayroon kaming hindi bababa sa isang pares ng magagandang katanungan. Hayaan akong ihagis ang isa sa iyo. Sa palagay ko sinagot mo ang ilan sa iba. Ngunit isang napaka-kagiliw-giliw na pagmamasid at tanong mula sa isang dumalo na nagsusulat, kung minsan ang mga maliksi na proyekto ay may data ng data na hindi nagkakaroon ng buong pangmatagalang larawan at sa gayon ay pinipilit nila ang pagdidisenyo ng isang bagay sa isang sprint at pagkatapos ay kailangang muling idisenyo sa sprint tatlo o apat. Hindi ba ito mukhang hindi produktibo? Paano mo maiiwasan ang ganitong uri?

Ron Huizenga: Ito lamang ang likas na liksi na hindi mo makuha ang lahat ng ganap na tama sa isang naibigay na sprint. At iyon ay talagang bahagi ng diwa ng maliksi, ay: magtrabaho kasama ito - gagawa ka ng prototyping kung saan nagtatrabaho ka sa code sa isang naibigay na sprint, at gagawa ka ng mga pagpipino dito. At ang isang bahagi ng proseso na iyon ay habang naghahatid ka ng mga bagay na nakikita ito ng gumagamit at sinabi, "Oo malapit na ito, ngunit talagang kailangan kong gawin itong kaunting dagdag na rin." Kaya hindi lamang nakakaapekto sa pagganap na disenyo ng code mismo ngunit madalas na kailangan nating baguhin o magdagdag ng mas maraming istraktura ng data sa ilalim ng mga tiyak na bagay na ito upang maihatid ang nais ng gumagamit. At iyon ang lahat ng patas na laro at iyon ang dahilan kung bakit nais mong gamitin ang mga de-kalidad na tool dahil maaari mong napakabilis na modelo at gawin itong pagbabago sa isang tool na pagmomolde at pagkatapos ay makabuo ng DDL para sa database na maaaring magtrabaho ang mga developer laban upang maihatid na magbago nang mas mabilis. Nai-save mo ang mga ito mula sa kinakailangang gawin ang kamay na coding, tulad nito, ng mga istruktura ng data at hinahayaan silang mag-concentrate sa programming o application logic na pinaka-mahusay sa kanila.

Eric Kavanagh: Gawin itong kumpleto. Nagkaroon kami ng isang pares ng iba pang mga tao na humihiling lamang ng mga tiyak na katanungan sa paligid kung paano ito nakatali sa lahat ng tool. Alam kong gumugol ka ng ilang oras sa pamamagitan ng mga halimbawa at ipinakita mo ang ilang mga screenshot tungkol sa kung paano mo talaga pinalabas ang ilan sa mga bagay na ito. Sa mga tuntunin ng buong proseso ng sprint na ito, gaano kadalas mong nakikita na naglalaro sa mga samahan kumpara kung gaano kadalas kang nakakakita ng mas maraming tradisyonal na mga proseso kung saan ang mga bagay ay, uri, sumasabay at kumuha ng mas maraming oras? Gaano kalaki ang diskarte ng estilo ng sprint mula sa iyong pananaw?

Ron Huizenga: Sa palagay ko mas maraming nakikita natin ito. Alam ko na, sasabihin ko, marahil sa huling 15 taon na partikular, nakita ko ang higit pa sa isang pag-aampon ng mga tao na kinikilala na talagang kailangan nilang yakapin ang mas mabilis na paghahatid. Kaya't marami na akong nakitang mga organisasyon na tumalon sa masiglang bandwagon. Hindi kinakailangang ganap; maaari silang magsimula sa isang pares ng mga proyekto ng pilot upang mapatunayan na ito ay gumagana, ngunit mayroong ilan na napaka-tradisyonal pa rin at ginagawa nila ang pamamaraan ng talon. Ngayon, ang mabuting balita ay, siyempre, na ang mga tool ay gumagana nang maayos sa mga samahang ito pati na rin para sa mga uri ng mga pamamaraan, ngunit mayroon kaming kakayahang umangkop sa tool upang ang mga tumalon sa board ay may mga tool sa toolbox sa ang kanilang mga daliri. Ang mga bagay tulad ng ihambing at pagsamahin, ang mga bagay tulad ng mga kakayahan sa reverse-engineering, kaya makikita nila kung ano ang umiiral na mga mapagkukunan ng data, kaya maaari nilang talagang ihambing at makabuo ng mga mabilis na script ng DDL. At habang sinimulan nila itong yakapin at makita na maaari silang magkaroon ng produktibo, ang kanilang pagkahilig na yakapin ang maliksi kahit na ang pagtaas.

Eric Kavanagh: Well, ito ay mahusay na bagay, mga tao. Nagpost lang ako ng isang link sa mga slide doon sa window ng chat, kaya suriin iyon; ito ay isang maliit na piraso ng isang Bitly doon para sa iyo. Mayroon kaming lahat ng mga webcasts na ito para sa pagtingin sa paglaon. Huwag mag-atubiling ibahagi ang mga ito sa iyong mga kaibigan at kasamahan. At Ron, maraming salamat sa iyong oras ngayon, palagi kang kaaya-aya sa palabas - isang tunay na dalubhasa sa larangan at malinaw na alam mo ang iyong mga gamit. Kaya, salamat sa iyo at salamat sa IDERA at, siyempre, kay Dez at sa aming sariling Robin Bloor.

At sa pamamagitan na kami ay mag-bid sa iyo ng paalam, mga tao. Salamat muli sa iyong oras at atensyon. Pinahahalagahan namin na dumikit ka sa paligid ng 75 minuto, iyon ay isang magandang magandang pag-sign. Magandang palabas guys, kakausapin namin kayo sa susunod. Paalam.