Ang pagbuo ng isang arkitektura ng data na hinihimok ng negosyo

Sa pamamagitan ng Techopedia Staff, Setyembre 28, 2016

Takeaway: Tatalakayin ni Host Rebecca Jozwiak ang mga solusyon sa arkitektura ng data kay Eric Little ng OSTHUS, Malcolm Chisholm ng Unang San Francisco Partners at Ron Huizenga ng IDERA.

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

Rebecca Jozwiak: Mga Babae at mga ginoo, kumusta, at maligayang pagdating sa Hot Technologies ng 2016. Ngayon ay pinag-uusapan natin ang "Pagbuo ng isang Arkitektura ng Data na Hinihimok ng Negosyo, " siguradong isang mainit na paksa. Ang pangalan ko ay Rebecca Jozwiak, ako ang magiging host mo para sa webcast ngayon. Nag-tweet kami gamit ang isang hashtag ng # HotTech16 kaya kung nasa Twitter ka na, mangyaring huwag mag-atubiling sumali din doon. Kung mayroon kang mga katanungan sa anumang oras, mangyaring ipadala ang mga ito sa panel ng Q&A sa ibabang kanan ng iyong screen at siguraduhin naming masasagot sila. Kung hindi, sisiguraduhin namin na makuha ng mga bisita ang mga ito para sa iyo.

Kaya ngayon mayroon kaming isang talagang kamangha-manghang lineup. Ang daming mabibigat na hitters na kasama natin ngayon. Mayroon kaming Eric Little, VP ng data science mula sa OSTHUS. Mayroon kaming Malcolm Chisholm, punong opisyal ng makabago, na kung saan ay isang tunay na cool na pamagat, para sa Mga Unang Kasosyo sa San Francisco. At mayroon kaming Ron Huizenga, manager ng senior product mula sa IDERA. At, alam mo, ang IDERA ay isang ganap na ganap na suite ng pamamahala ng data at mga solusyon sa pagmomolde. At ngayon bibigyan niya kami ng demo tungkol sa kung paano gumagana ang kanyang solusyon. Ngunit bago tayo makarating doon, Eric Little, ipapasa ko sa inyo ang bola.

Eric Little: Okay, maraming salamat. Kaya pupunta ako sa pamamagitan ng isang pares ng mga paksa dito na sa palagay ko ay magkakaugnay sa usapan ni Ron nang kaunti at sana ay itakda ang entablado para sa ilan sa mga paksang ito pati na rin, ang ilang mga Q&A.

Kaya ang bagay na interesado ako sa ginagawa ng IDERA ay sa palagay ko tama nilang itinuro na ang mga kumplikadong kapaligiran ay talagang nagmamaneho ng maraming mga halaga ng negosyo sa ngayon. At sa pamamagitan ng mga kumplikadong kapaligiran ay nangangahulugang kumplikado ang mga kapaligiran ng data. At ang teknolohiya ay talagang gumagalaw nang mabilis at mahirap mapanatili ang kapaligiran sa negosyo ngayon. Kaya't ang mga taong nagtatrabaho sa mga puwang ng teknolohiya ay madalas na makita na mayroon kang mga customer na gumagawa ng mga problema sa, "Paano ako gumagamit ng malaking data? Paano ko isasama ang mga semantika? Paano ko mai-link ang ilan sa mga bagong bagay na ito sa aking mas lumang data? "At iba pa, at ang uri ng mga ito ay humahantong sa amin sa kasalukuyan sa mga apat na v ng malaking data na maraming mga tao na pamilyar, at naiintindihan kong maaaring higit pa sa apat minsan - Nakita ko ng maraming bilang walong o siyam - ngunit karaniwan, kapag ang mga tao ay pinag-uusapan ang mga bagay tulad ng malaking data o kung pinag-uusapan mo ang malaking data pagkatapos ay karaniwang nakatingin ka sa isang bagay na uri ng scale ng negosyo. At sa gayon sasabihin ng mga tao, okay, well, isipin ang tungkol sa dami ng iyong data, na kung saan ay karaniwang ang pokus - iyon lamang ang kung mayroon ka. Ang bilis ng data ay may kinalaman sa alinman kung gaano kabilis maaari kong ilipat ito sa paligid o kung gaano kabilis maaari kong tanungin ito o makuha ang mga sagot, at iba pa. At sa palagay ko ang kaliwang bahagi ng iyon ay isang bagay na malulutas at hawakan nang medyo mabilis sa pamamagitan ng maraming iba't ibang mga pamamaraan. Ngunit sa kanang bahagi ay nakikita ko ang maraming kakayahan para sa pagpapabuti at maraming mga bagong teknolohiya na talagang darating sa harapan. At iyan ay talagang dapat gawin sa ikatlong haligi, ang iba't ibang data.

Kaya sa madaling salita, ang karamihan sa mga kumpanya ngayon ay tumitingin sa nakabalangkas, semi-nakabalangkas at hindi nakaayos na data. Ang data ng imahe ay nagsisimula na maging isang mainit na paksa, kaya nagagamit ang pangitain sa computer, tumingin sa mga pix, na magagawang mag-scrape ng teksto, NLP, pagkuha ng entidad, mayroon kang impormasyon sa graph na lumalabas sa alinman sa mga modelo ng istatistika o lumalabas sa semantiko mga modelo, mayroon kang data sa pamanggit na mayroon sa mga talahanayan, at iba pa. At kaya ang paghila ng lahat ng data na iyon nang magkasama at ang lahat ng mga iba't ibang uri na ito ay talagang kumakatawan sa isang malaking hamon at makikita mo ito, alam mo, sa Gartner at iba pang mga tao na uri ng pagsunod sa mga uso sa industriya.

At pagkatapos ay ang pangwakas na bagay na pinag-uusapan ng mga tao sa malaking data ay kadalasang ang paniwala na ito ng kalaswaan, na kung saan ay talagang ang kawalan ng katiyakan ng iyong data, ang pagkagulo sa mga ito. Gaano kahusay ang alam mo kung ano ang tungkol sa iyong data, gaano kahusay ang naiintindihan mo kung ano ang nariyan at, alam mo? Ang kakayahang gumamit ng mga istatistika at ang kakayahang gumamit ng ilang uri ng impormasyon sa paligid ng maaaring alam mo o gumamit ng ilang konteksto, ay maaaring maging halaga doon. At kaya ang kakayahang tumingin sa data sa ganitong paraan sa mga tuntunin kung gaano ka, kung gaano kabilis na kailangan mong ilipat ito sa paligid o makuha ito, ang lahat ng mga uri ng data na maaaring mayroon ka sa iyong negosyo at kung gaano ka tiyak tungkol sa kung saan ito ay, kung ano ito, kung ano ang kalidad nito, at iba pa. Ito ay talagang nangangailangan ng isang malaki, na pinagsama-samang pagsisikap ngayon sa pagitan ng maraming mga indibidwal upang mapangasiwaan ang kanilang data nang epektibo. Samakatuwid, ang modelo ng data ay lalong mahalaga sa mundo ngayon. Kaya ang mga mahusay na modelo ng data ay talagang nagmamaneho ng maraming tagumpay sa mga aplikasyon ng negosyo.

Mayroon kang mga mapagkukunan ng data mula sa iba't ibang mga mapagkukunan, tulad ng sinabi namin, na talagang nangangailangan ng maraming iba't ibang uri ng pagsasama. Kaya't ang paghila ng lahat ng ito ay talagang kapaki-pakinabang upang makapagpapatakbo ng mga query, halimbawa, sa maraming uri ng mga mapagkukunan ng data, at ibalik ang impormasyon. Ngunit upang magawa mo na kailangan mo ng mahusay na mga diskarte sa pagma-map at kaya ang pag-mapa ng mga uri ng data at pagpapanatiling mga mappings ay maaaring maging isang tunay na hamon. At pagkatapos ay mayroon ka ng isyung ito ng, mabuti kung paano ko mai-link ang aking data ng legacy sa lahat ng mga bagong mapagkukunan ng data? Kaya ipagpalagay na mayroon akong graph, kukuha ba ako ng lahat ng aking relational data at ilagay ito sa grapiko? Karaniwan hindi iyon isang magandang ideya. Kaya paano ito pinamamahalaan ng mga tao ang lahat ng mga uri ng mga modelo ng data na nangyayari? Ang pagtatasa ay talagang dapat patakbuhin sa maraming iba't ibang mga uri ng mga mapagkukunan ng data at mga kumbinasyon. Kaya ang mga sagot na lumalabas dito, ang mga sagot na kailangan ng mga tao na talagang gumawa ng magagandang desisyon sa negosyo ay kritikal.

Kaya ito ay hindi lamang tungkol sa pagbuo ng teknolohiya para sa kapakanan ng teknolohiya, ito talaga, kung ano ang gagawin ko, ano ang magagawa ko, kung anong uri ng pagsusuri ang maaari kong patakbuhin, at ang kakayahan, samakatuwid, tulad ng nagawa ko na pinag-uusapan, upang hilahin ang mga bagay na ito, upang pagsamahin ito ay talagang, talagang mahalaga. At ang isa sa mga ganitong uri ng pagsusuri pagkatapos ay tumatakbo sa mga bagay tulad ng pederal na paghahanap at query. Ito ay talagang nagiging isang dapat. Ang iyong mga query ay dapat na karaniwang sinulid sa maraming uri ng mga mapagkukunan at ibalik ang impormasyon sa isang maaasahan.

Ang isang pangunahing elemento na madalas, lalo na ang mga tao ay titingnan ang mga pangunahing bagay tulad ng mga teknolohiyang semantiko - at ito ay isang bagay na inaasahan kong si Ron ay pag-uusapan nang kaunti sa diskarte ng IDERA - kung paano mo ihiwalay o pamahalaan ang modelo ng layer ng iyong data mula sa data layer mismo, mula sa hilaw na data? Kaya sa ibaba ng data layer maaari kang magkaroon ng mga database, maaaring mayroon kang data ng dokumento, maaaring magkaroon ka ng data ng spreadsheet, maaari kang magkaroon ng data ng imahe. Kung nasa mga lugar ka tulad ng mga industriya ng parmasyutiko mayroon kang napakaraming data na pang-agham. At pagkatapos ay sa itaas ng mga taong ito ay normal na naghahanap ng isang paraan upang makabuo ng isang modelo na nagbibigay-daan sa kanila upang mabilis na isama ang data na iyon at talagang kapag naghahanap ka ng data ngayon hindi ka naghahanap upang hilahin ang lahat ng data hanggang sa modelo ng iyong layer, kung ano ang tinitingnan mo upang gawin ang modelo ng modelo ay upang mabigyan ka ng isang magandang lohikal na representasyon ng kung ano ang mga bagay, karaniwang mga bokabularyo, karaniwang uri ng mga nilalang at relasyon, at ang kakayahang talagang maabot sa data kung nasaan ito. Kaya kailangang sabihin kung ano ito, at dapat itong sabihin kung nasaan ito, at kailangang sabihin kung paano pumunta ito makuha at ibalik ito.

Kaya ito ay isang diskarte na naging matagumpay sa pagpapalakas ng mga teknolohiyang semantiko na pasulong, na isang lugar kung saan nagtatrabaho ako nang maraming. Kaya isang tanong na nais kong mag-pose para kay Ron, at sa palagay ko ay magiging kapaki-pakinabang sa seksyon ng Q&A, ay makita kung paano ito nagawa sa platform ng IDERA? Kaya't ang layer ng modelo ay talagang hiwalay sa layer ng data? Mas integrated ba sila? Paano ito gumagana at ano ang ilan sa mga resulta at benepisyo na nakikita nila mula sa kanilang diskarte? Samakatuwid ang data ng sanggunian ay talagang nagiging kritikal din. Kaya kung magkakaroon ka ng mga ganitong uri ng mga modelo ng data, kung magagawa mong makisali at maghanap sa mga bagay, kailangan mong magkaroon ng mahusay na data ng sanggunian. Ngunit ang problema ay ang data ng sanggunian ay maaaring talagang mahirap mapanatili. Kaya't madalas na pagbibigay ng mga pamantayan sa loob at sa kanilang sarili ay isang mahirap na hamon. Ang isang pangkat ay tatawag ng isang bagay X at isang pangkat ang tatawag sa isang bagay Y at ngayon mayroon kang problema kung paano nahanap ang isang X at Y kapag naghahanap sila ng ganitong uri ng impormasyon? Dahil hindi mo nais na bigyan lamang sila ng isang bahagi ng data, nais mong ibigay sa kanila ang lahat ng nauugnay. Kasabay ng pagbabago ng mga term ng panahon, ang software ay nagiging disecated, at iba pa, paano mo mapanatili at mapanatili ang data na sanggunian sa paglipas ng panahon?

At, muli, ang mga teknolohiyang semantiko, partikular na gumagamit ng mga bagay tulad ng taxonomies at bokabularyo, mga diksyonaryo ng data, ay nagbigay ng isang pamantayang paraan ng espasyo ng paggawa nito, na talagang lubos na matatag, gumagamit ito ng ilang mga uri ng pamantayan, ngunit ang komunidad ng database ay nagawa ito para sa isang mahabang panahon din, sa iba't ibang paraan. Sa palagay ko ang isa sa mga susi dito ay mag-isip tungkol sa kung paano gamitin ang marahil mga modelong may kaugnayan sa entity, kung paano gamitin marahil ang mga modelo ng grapiko o ilang uri ng isang diskarte dito na talagang magbibigay sa iyo ng pag-asa ng isang pamantayang espasyo na paraan ng paghawak sa iyong sanggunian. At pagkatapos siyempre kapag mayroon kang data ng sanggunian, ang mga diskarte sa pagmamapa ay kailangang pamahalaan ang isang iba't ibang mga uri ng mga pangalan at nilalang. Kaya ang mga eksperto sa paksa ng paksa ay madalas na nais na gumamit ng kanilang sariling mga term.

Kaya ang isang hamon sa ito ay palaging, paano ka bibigyan ng impormasyon sa isang tao ngunit gawin itong may kaugnayan sa paraan na pinag-uusapan nila ito? Kaya ang isang pangkat ay maaaring magkaroon ng isang paraan ng pagtingin sa isang bagay, halimbawa, maaaring ikaw ay isang chemist na nagtatrabaho sa isang gamot, at maaaring ikaw ay isang istrukturang biologist na nagtatrabaho sa parehong gamot, at maaaring mayroon kang iba't ibang mga pangalan para sa parehong mga uri ng mga nilalang na nauugnay sa iyong bukid. Kailangan mong malaman ang mga paraan upang magkasama ang mga isinapersonal na mga terminolohiya, dahil ang iba pang diskarte ay, kailangan mong pilitin ang mga tao na i-drop ang kanilang termino at gumamit ng ibang tao, na madalas na hindi nila gusto. Ang isa pang punto dito ay ang paghawak ng malaking bilang ng mga kasingkahulugan ay nahihirapan, kaya maraming mga magkakaibang mga salita sa maraming data ng mga tao na maaaring sumangguni sa parehong bagay. Mayroon kang isang problema sa sanggunian doon gamit ang maraming-sa-isang hanay ng mga relasyon. Ang mga dalubhasang termino ay nag-iiba mula sa industriya hanggang sa industriya kaya kung pupunta ka na may uri ng isang overarching solution para sa ganitong uri ng pamamahala ng data, gaano kadali ito mailalarawan mula sa isang proyekto, o isang application patungo sa isa pa? Na maaaring isa pang hamon.

Mahalaga ang automation at hamon din ito. Ito ay mahal upang manu-manong hawakan ang data ng sanggunian. Mahusay na panatilihin ang mano-mano ang pagma-map at ito ay mahal na ang mga eksperto sa paksa ay tumigil sa paggawa ng kanilang mga pang-araw-araw na trabaho at kailangang pumasok at patuloy na ayusin ang mga diksyonaryo ng data at muling i-update ang mga kahulugan at iba pa, at iba pa. Ang mga replicable na bokabularyo ay talagang nagpapakita ng maraming halaga. Kaya ang mga ito ay mga bokabularyo nang madalas na maaari mong makita ang panlabas sa iyong samahan. Kung nagtatrabaho ka sa langis ng krudo, halimbawa, magkakaroon ng ilang mga uri ng mga bokabularyo na maaari kang humiram mula sa mga bukas na mapagkukunan, pareho sa mga parmasyutiko, kapareho sa industriya ng pagbabangko at pananalapi, kapareho ng maraming mga uri ng mga lugar na ito. Ang mga tao ay naglalagay ng magagamit muli, generic, replicable vocabularies out doon para magamit ng mga tao.

At, muli, tinitingnan ang tool ng IDERA, interesado akong makita kung paano nila ito pinangangasiwaan sa mga tuntunin ng paggamit ng mga uri ng pamantayan. Sa mundo ng semantika madalas kang nakakakita ng mga bagay tulad ng mga modelo ng SKOS na nagbibigay ng mga pamantayan para sa hindi bababa sa mas malapad kaysa / mas makitid kaysa sa mga relasyon at mga bagay na maaaring mahirap gawin sa mga modelo ng ER ngunit, alam mo, hindi imposible, nakasalalay lamang ito sa kung magkano iyon makinarya at ang pag-uugnay na maaari mong hawakan sa mga uri ng mga system.

Kaya't sa wakas nais ko lamang na gumawa ng isang paghahambing sa ilang mga semantiko na makina na nakikita ko sa industriya, at uri ng tanungin si Ron at pangunahin siya nang kaunti upang pag-usapan marahil kung paano ginamit ang system ng IDERA kasabay ng anumang mga teknolohiyang semantiko. May kakayahan ba itong maisama sa mga triple store, mga database ng graph? Gaano kadali ang paggamit ng mga panlabas na mapagkukunan dahil ang mga uri ng mga bagay sa semantiko mundo ay madalas na hiramin gamit ang SPARQL Endpoints? Maaari kang mag-import ng mga modelo ng RDF o OWL nang direkta sa iyong modelo - sumangguni sa kanila - kaya, halimbawa, ang gen ontology o ang prottttt na protina, na maaaring mabuhay sa isang lugar sa sarili nitong puwang na may sariling istraktura ng pamamahala at maaari ko lamang mai-import ang lahat o bahagi ng bilang na kailangan ko ito sa aking sariling mga modelo. At interesado akong malaman kung paano lumapit ang IDERA sa isyung ito. Kailangan mo bang mapanatili ang lahat sa loob, o may mga paraan upang magamit ang iba pang mga uri ng mga pamantayang modelo at hilahin sila at paano ito gumagana? At ang huling bagay na nabanggit ko dito ay kung gaano karaming manu-manong gawain ang talagang kasangkot sa pagbuo ng mga glossary at metadata repositories?

Kaya alam kong magpakita sa amin si Ron ng ilang mga demo sa mga ganitong uri ng bagay na magiging talagang kawili-wili. Ngunit ang mga problema na madalas kong nakikita sa pagkonsulta sa mga customer ay ang maraming mga pagkakamali na nagaganap kung ang mga tao ay sumusulat sa kanilang sariling mga kahulugan o sa kanilang sariling metadata. Kaya't nakakakuha ka ng mga maling pagsasalita, nakakakuha ka ng mga pagkakamali sa taba, iyon ang isang bagay. Makakakuha ka rin ng mga taong maaaring kumuha ng isang bagay, alam mo, lamang ang Wikipedia o isang mapagkukunan na hindi kinakailangan ng kalidad na maaaring gusto mo sa iyong kahulugan, o ang iyong kahulugan ay mula lamang sa pananaw ng isang tao kaya hindi kumpleto, at hindi malinaw pagkatapos kung paano gumagana ang proseso ng pamamahala. Ang pamamahala, siyempre, pagiging isang napaka, napakalaking isyu sa anumang oras na pinag-uusapan mo ang sangguniang data at anumang oras na pinag-uusapan mo kung paano ito magkasya sa data ng master ng isang tao, kung paano nila gagamitin ang kanilang metadata, at kaya naman.

Kaya gusto ko lang ilabas ang ilan sa mga paksang ito. Ito ang mga item na nakikita ko sa puwang ng negosyo sa maraming iba't ibang uri ng mga pakikipagsangguni sa pagkonsulta at maraming iba't ibang mga puwang, at interesado akong makita kung ano ang ipapakita sa amin ni Ron ng IDERA upang maituro ang ilan sa mga paksang ito . Kaya maraming salamat.

Rebecca Jozwiak: Maraming salamat, Eric, at gusto ko talaga ang iyong puna na maraming mga pagkakamali ang maaaring mangyari kung ang mga tao ay sumusulat ng kanilang sariling mga kahulugan o metadata. Alam ko sa mundo ng journalism mayroong isang mantra na "maraming mga mata ang nagkakamali ng mga pagkakamali, " ngunit pagdating sa praktikal na mga aplikasyon, napakaraming mga kamay sa cookie jar ang may iwanan sa iyo ng maraming basag na cookies, di ba?

Eric Little: Oo, at mikrobyo.

Rebecca Jozwiak: Oo. Gamit na ako ay sige na at ipasa ito sa Malcolm Chisholm. Malcolm, ang sahig ay iyo.

Malcolm Chisholm: Maraming salamat, Rebecca. Nais kong tumingin ng kaunti sa kung ano ang pinag-uusapan ni Eric, at idagdag sa, uri ng, ilang mga obserbasyon na, alam mo, maaaring pag-aalagaan ni Ron na tumugon din, sa pakikipag-usap tungkol sa "Toward Business-Driven Data Architecture "- ano ang ibig sabihin na maging hinimok sa negosyo at bakit mahalaga iyon? O ito ay ilan lamang sa anyo ng hype? Sa palagay ko hindi ito.

Kung titingnan natin kung ano ang nangyayari mula noong, alam mo, ang mga computer ng mainframe ay talagang magagamit sa mga kumpanya - sabihin, sa paligid ng 1964 - hanggang ngayon, makikita natin na maraming pagbabago. At ang mga pagbabagong ito ay aking ibubuod bilang isang paglipat mula sa proseso-sentralidad sa data-sentrikidad. At iyon ang gumagawa ng mga arkitektura na data na hinihimok ng negosyo na napakahalaga at napakahalaga para sa ngayon. At sa palagay ko, alam mo, hindi lamang ito buzzword, ito ay isang bagay na talagang totoo.

Ngunit maaari naming pinahahalagahan ito nang kaunti pa kung sumisid tayo sa kasaysayan, kaya bumalik sa oras, pabalik sa 1960 at para sa ilang oras pagkatapos, ang mga pangunahing papel ay namuno. Ang mga ito pagkatapos ay nagbigay daan sa mga PC kung saan ka tunay na nagrerebelde sa mga gumagamit noong pumasok ang mga PC. Ang paghihimagsik laban sa sentralisadong IT, na akala nila ay hindi tinutupad ang kanilang mga pangangailangan, ay hindi masyadong maliksi. Mabilis na bumangon ito sa ipinamamahaging kompyuter, kapag magkasama ang mga PC. At pagkatapos ay nagsimulang mangyari ang internet, na lumabo sa mga hangganan ng negosyo - maaari na itong makihalubilo sa mga partido sa labas mismo sa mga tuntunin ng data exchange, na hindi pa nangyari. At ngayon napunta na kami sa panahon ng ulap at malaking data kung saan ang ulap ay mga platform na talagang nag-uod ng mga imprastraktura at sa gayon aalis kami, tulad ng, IT ng pangangailangan na magpatakbo ng malaking data center dahil, alam mo, kami Nakakuha ang kapasidad ng ulap na magagamit sa amin, at kasabay sa malaking data na mayroon si Eric, alam mo, kaya mahusay na tinalakay. At sa pangkalahatan, tulad ng nakikita natin, habang naganap ang pagbabago sa teknolohiya, naging mas maraming data-sentrik, mas mahalaga ang aming pag-aalaga sa data. Tulad ng sa internet, kung paano ipinagpapalit ang data. Sa malaking data, ang apat o higit pang v ng data mismo.

Kasabay nito, at marahil mas mahalaga, ang mga kaso ng paggamit ng negosyo ay inilipat. Kapag ang mga computer ay unang ipinakilala, nasanay sila upang i-automate ang mga bagay tulad ng mga libro at talaan. At ang anumang bagay na isang manu-manong proseso, na kasangkot sa mga ledger o mga bagay tulad nito, ay na-program, mahalagang, sa bahay. Iyon ay lumipat sa 80s sa pagkakaroon ng mga pakete ng pagpapatakbo. Hindi mo na kailangang isulat ang iyong sariling payroll, maaari kang bumili ng isang bagay na ginawa nito. Iyon ang nagresulta sa isang malaking pagbagsak sa oras, o muling pagsasaayos, sa maraming mga kagawaran ng IT. Ngunit pagkatapos ng katalinuhan sa negosyo, na may mga bagay tulad ng mga bodega ng data ay lumitaw, halos 90s. Sinundan ng mga modelo ng negosyo ng dotcom na kung saan ay, siyempre, isang malaking siklab ng galit. Pagkatapos MDM. Sa MDM nagsisimula kang makita na iniisip namin hindi tungkol sa automation; talagang tinutuon namin ang curating data bilang data. At pagkatapos ay ang analytics, na kumakatawan sa halaga na maaari mong makuha sa data. At sa loob ng analytics nakikita mo ang mga kumpanya na matagumpay na ang modelo ng pangunahing negosyo ay umiikot sa data. Ang Google, Twitter, Facebook ay magiging bahagi nito, ngunit maaari kang magtaltalan din na si Walmart.

At kaya ang negosyo ngayon ay talagang nag-iisip tungkol sa data. Paano tayo makakakuha ng halaga sa data? Paano makukuha ng data ang negosyo, diskarte, at nasa gintong edad ng data. Kaya't ibinigay na, kung ano ang nangyayari sa mga tuntunin ng aming arkitektura ng data, kung ang data ay hindi na itinuturing na simpleng tambutso na lumabas mula sa likod ng mga aplikasyon, ngunit talagang sentro sa aming mga modelo ng negosyo? Kaya, bahagi ng problema na mayroon tayo sa pagkamit na IT ay talagang natigil sa nakaraan sa mga sistema ng pag-unlad ng siklo ng buhay na isang kinahinatnan ng pagkakaroon ng mabilis na pagharap sa proseso ng proseso ng automation sa unang bahagi ng IT, at nagtatrabaho sa ang mga proyekto ay isang katulad na bagay. Sa IT - at ito ay isang maliit na karikatura - ngunit ang sinusubukan kong sabihin ay ang ilan sa mga hadlang sa pagkuha ng isang arkitektura na data na hinihimok ng negosyo ay dahil kami, uri ng, uncritically tinanggap ang isang kultura sa IT na nagmula sa isang edad na.

Kaya lahat ng proyekto. Sabihin mo sa akin ang iyong mga kinakailangan sa detalye. Kung ang mga bagay ay hindi gumagana, ito ay dahil hindi mo sinabi sa akin ang iyong mga kinakailangan. Hindi na gumagana ngayon sa data dahil hindi kami nagsisimula sa mga hindi awtomatikong mga proseso ng manu-mano o, alam mo, isang teknikal na pagbabagong-anyo ng mga proseso ng negosyo, nagsisimula kami nang madalas kasama ang mayroon nang data ng produksyon na sinusubukan namin. upang makakuha ng halaga ng. Ngunit walang sinuman na nag-sponsor ng isang proyekto na nakasentro ng data na talagang nakakaintindi sa malalim na data. Kailangan nating gawin ang pagtuklas ng data, kailangan nating gawin ang pagsusuri ng mapagkukunan ng mapagkukunan. At iyon ay hindi talaga tumutugma sa pag-unlad ng mga system, alam mo - talon, SDLC lifecycle - kung saan Agile, nais kong mapanatili, ay isang uri ng isang mas mahusay na bersyon ng na.

At kung ano ang nakatuon sa teknolohiya at pag-andar, hindi data. Halimbawa, kapag nagsasagawa kami ng pagsubok sa isang yugto ng pagsubok na karaniwang magiging, gumagana ba ang aking pag-andar, sabihin natin ang aking ETL, ngunit hindi namin sinusubukan ang data. Hindi namin sinusubukan ang aming mga pagpapalagay tungkol sa mga mapagkukunan na data na pumapasok. Kung nagawa natin, magiging mas mahusay kami sa hugis at bilang isang tao na nagawa ang mga proyekto ng bodega ng data at nagdusa sa mga pagbabago sa agos, pinaputok ang aking mga ETL, gugustuhin ko iyon. At sa katunayan, ang nais nating makita ay pagsubok bilang isang paunang hakbang sa patuloy na pagmamanman ng kalidad ng data ng produksyon. Kaya nakuha namin dito ang maraming mga saloobin kung saan mahirap makamit ang arkitektura ng data na hinihimok ng negosyo dahil nakondisyon kami ng panahon ng proseso-sentralidad. Kailangan naming gumawa ng isang paglipat sa data-centricity. At hindi ito isang kabuuang paglipat, alam mo, marami pa rin ang proseso ng trabaho upang gawin doon, ngunit hindi kami talagang nag-iisip sa mga term-sentrik na termino kung kailangan natin, at ang mga pangyayari na nangyayari kapag talagang kami obligadong gawin iyon.

Ngayon napagtanto ng negosyo ang halaga ng data, nais nilang i-unlock ang data, kaya paano natin gagawin iyon? Kaya paano natin gagawin ang paglipat? Kaya, inilalagay namin ang data sa gitna ng mga proseso ng pag-unlad. At hinayaan namin ang negosyo na humantong sa mga kinakailangan sa impormasyon. At nauunawaan namin na walang nakakaintindi sa umiiral na data ng mapagkukunan sa simula ng proyekto. Maaari mong magtaltalan na ang istraktura ng data at ang data mismo ay nakarating doon sa pamamagitan ng IT at mga operasyon, ayon sa pagkakabanggit, kaya dapat nating malaman iyon, ngunit talagang, hindi namin. Ito ay ang pag-unlad ng data-sentrik. Kaya kailangan nating, sa pag-iisip tungkol sa kung saan tayo at paano natin gagawin ang data sa pagmomolde ng data sa isang mundo na nakasentro sa data, kailangan nating magkaroon ng mga puna ng feedback sa mga gumagamit sa mga tuntunin ng pagpino ng kanilang mga kinakailangan sa impormasyon, habang ginagawa natin ang pagkatuklas ng data at data profiling, inaasahan ang pagtatasa ng data ng mapagkukunan, at habang unti-unting nakakakuha tayo ng higit at katiyakan tungkol sa aming data. At ngayon nagsasalita ako ng isang mas tradisyunal na proyekto tulad ng isang hub ng MDM o isang bodega ng data, hindi kinakailangan ang malaking proyekto ng data, kahit na ito ay pa rin, pinapanatili ko, medyo malapit doon. At sa gayon ang mga mga loop ng feedback ay kasama ang mga modelo ng data, alam mo, unti-unting isulong ang kanilang modelo ng data at nakikipag-ugnay sa mga gumagamit upang matiyak na ang mga iniaatas na impormasyon ay pinino batay sa kung ano ang posible, kung ano ang magagamit, mula sa mapagkukunan ng data dahil mas mahusay nilang maunawaan ito, hindi pa ito kaso ng data model na, alam mo, sa isang estado na alinman wala doon o ganap na nagawa, ito ay isang unti-unting pagpasok sa pagtuon nito.

Katulad nito, higit pang pag-agos ng na mayroon kaming katiyakan sa kalidad kung saan kami ay nagkakaroon ng mga patakaran para sa pagsubok sa kalidad ng data upang matiyak na ang data ay nasa loob ng mga parameter na ginagawa namin. Papasok, tinukoy ni Eric ang mga pagbabago sa sangguniang data, na maaaring mangyari. Hindi mo nais na, tulad ng dati, isang pababang biktima ng, uri ng, hindi pinamahalaang pagbabago sa lugar na iyon, kaya ang mga panuntunan ng katiyakan ng kalidad ay maaaring mapunta sa post-production, patuloy na pagsubaybay sa kalidad ng data. Kaya maaari mong simulan upang makita kung kami ay magiging data-sentrik, kung paano namin ginagawa ang pag-unlad ng data-sentrik ay naiiba sa pag-andar na batay sa SDLC at Agile. At pagkatapos ay kailangan nating bigyang pansin din ang mga pananaw sa negosyo. Mayroon kaming - at muli itong sumasalamin sa sinabi ni Eric - mayroon kaming isang modelo ng data na tumutukoy sa isang plano ng data ng kwento para sa aming database, ngunit sa parehong oras na kailangan namin ang mga konseptong modelo, ang mga pananaw sa negosyo ng data na ayon sa kaugalian ay hindi pa nagawa sa ang nakaraan. Minsan, sa palagay ko, naisip ko na ang data model ay maaaring gawin ang lahat, ngunit kailangan nating magkaroon ng konsepto na view, ang semantika, at tingnan ang data, ibigay ito sa pamamagitan ng isang abstraction layer na isinalin ang modelo ng imbakan sa negosyo tingnan. At, muli, ang lahat ng mga bagay na pinag-uusapan ni Eric sa mga tuntunin ng semantika, ay nagiging mahalaga na gawin iyon, kaya talagang mayroon kaming mga karagdagang mga gawain sa pagmomolde. Sa palagay ko, alam mo, kawili-wili kung dumating ka sa mga ranggo bilang isang modelo ng data tulad ng ginawa ko, at muli, isang bago.

At sa wakas nais kong sabihin na ang mas malaking arkitektura ay mayroon ding upang ipakita ang bagong katotohanan. Halimbawa, ang tradisyunal na customer na MDM, ay uri ng, okay, kunin natin ang data ng aming customer sa isang hub kung saan maaari naming, alam mo, magkaroon ng kahulugan dito sa mga tuntunin ng talagang kalidad ng data para sa mga aplikasyon ng back office. Alin mula sa isang diskarte sa diskarte sa negosyo ay uri ng isang hikog. Ngayon, subalit, tinitingnan namin ang mga hub ng MDM ng customer na may karagdagang data ng profile ng customer sa kanila, hindi lamang ang static data, na kung saan ay talagang mayroong isang bidirectional interface sa mga aplikasyon ng transaksyon ng customer. Oo, sinusuportahan pa rin nila ang back office, ngunit ngayon alam din natin ang tungkol sa mga pag-uugali na ito ng aming mga customer. Ito ay mas mahal upang itayo. Ito ay mas kumplikado upang maitaguyod. Ngunit ito ay hinihimok ng negosyo sa isang paraan kung saan ang tradisyunal na MDM ay hindi. Ipinagpapalit mo ang isang orientation sa negosyo laban sa mas simpleng disenyo na mas madaling ipatupad, ngunit para sa negosyo, ito ang nais nilang makita. Tayo ay talagang nasa isang bagong panahon at sa palagay ko mayroong isang bilang ng mga antas na dapat nating tumugon sa arkitektura ng data ng pagmamaneho ng negosyo at sa palagay ko ito ay isang napaka-kapana-panabik na oras sa paggawa ng mga bagay.

Kaya salamat, pabalik sa iyo Rebecca.

Rebecca Jozwiak: Salamat Malcolm, at talagang nasisiyahan ako sa sinabi mo tungkol sa mga modelo ng data ay dapat pakainin ang pananaw sa negosyo, sapagkat, uri ng hindi katulad ng sinabi mo, kung saan pinanghawakan ng IT ang reins ng napakahaba at ito ay uri lamang ng hindi na kaso at na ang kultura ay kailangang lumipat. At sigurado ako na mayroong isang aso sa background na sumang-ayon sa iyo 100%. At kasama ko ay ipapasa ko ang bola kay Ron. Tuwang-tuwa ako na makita ang iyong demo. Ron, ang sahig ay iyo.

Ron Huizenga: Maraming salamat at bago kami tumalon doon, madadaan ako ng ilang mga slide at pagkatapos ng kaunting demo dahil, tulad ng itinuro nina Eric at Malcolm, ito ay isang napakalawak at malalim na paksa, at sa kung ano ang pinag-uusapan natin ngayon ay binabalisa lamang natin ang ibabaw nito dahil maraming aspeto at maraming bagay na talagang dapat nating isaalang-alang at tingnan mula sa isang arkitekturang hinihimok ng negosyo. At ang aming diskarte ay upang gawin talaga ang batay sa modelo at makuha ang tunay na halaga sa labas ng mga modelo dahil maaari mong gamitin ang mga ito bilang isang sasakyan sa komunikasyon pati na rin ang isang layer upang paganahin ang iba pang mga system. Kung ginagawa mo ang arkitekturang nakatuon sa serbisyo, o iba pang mga bagay, ang modelo ay talagang nagiging buhay ng kung ano ang nangyayari, kasama ang lahat ng metadata sa paligid nito at ang data na mayroon ka sa iyong negosyo.

Gayunman, ang nais kong pag-usapan, ay halos gawin itong hakbang, dahil si Malcolm ay naantig sa ilan sa kasaysayan ng mga paraan ng paglutas ng mga solusyon at ang uri ng bagay na iyon. Ang isang paraan upang talagang ituro kung gaano kahalaga na magkaroon ng isang arkitektura ng tunog ng data ay isang kaso ng paggamit na dati kong pinapatakbo nang madalas kapag kumunsulta ako bago ako pumasok sa isang papel na pamamahala ng produkto, at iyon ay, pupunta ako sa mga organisasyon kung sila ay gumagawa ng pagbabago sa negosyo o pagpapalit lamang ng ilang mga umiiral na mga sistema at ang uri ng bagay na ito, at naging malinaw ito nang napakabilis kung paano nauunawaan ng mga hindi maayos na samahan ang kanilang sariling data. Kung kumuha ka ng isang partikular na kaso ng paggamit tulad nito, kung ikaw ay isang consultant na pumapasok o marahil ito ay isang tao na nagsimula pa lamang sa isang samahan, o ang iyong samahan ay binuo sa loob ng maraming taon sa pagkuha ng iba't ibang mga kumpanya, kung ano ang tapusin mo napupunta sa isang napaka-kumplikadong kapaligiran nang napakabilis, na may maraming mga bagong magkakaibang teknolohiya, pati na rin ang teknolohiyang pamana, mga solusyon sa ERP at lahat ng iba pa.

Kaya ang isa sa mga bagay na maaari nating gawin sa aming diskarte sa pagmomolde ay upang sagutin ang tanong ng, paano ko malalaman ang lahat ng ito? Maaari naming talagang simulan upang i-piraso ang impormasyon nang magkasama, upang ang negosyo ay maaaring magamit ang impormasyon na mayroon kaming maayos. At lumabas ito, ano ang mayroon tayo doon sa mga kapaligiran? Paano ko magagamit ang mga modelo upang palayasin ang impormasyon na kailangan ko at maunawaan nang mas mahusay ang impormasyong iyon? At pagkatapos ay mayroon kaming mga tradisyunal na uri ng metadata para sa lahat ng iba't ibang mga bagay tulad ng mga modelong relational data, at nasanay kami na makita ang mga bagay tulad ng mga kahulugan at mga diksyonaryo ng data, alam mo, mga uri ng data at ang uri ng bagay. Ngunit ano ang tungkol sa karagdagang metadata na nais mong makuha upang talagang magbigay ng higit pang kahulugan dito? Tulad ng, kung aling mga entidad ang talagang mga kandidato na dapat maging sangguniang data na mga bagay, na dapat maging master object data management at mga uri ng mga bagay at itali ang mga ito. At paano dumadaloy ang impormasyon sa samahan? Ang mga data ay dumadaloy mula sa kung paano sila natupok mula sa parehong isang proseso ng view, ngunit din ang linya ng data sa mga tuntunin ng paglalakbay ng impormasyon sa pamamagitan ng aming mga negosyo at kung paano ito ginagawa sa pamamagitan ng iba't ibang mga system, o sa pamamagitan ng mga data store, kaya alam natin kapag itinatayo namin ang mga I-solution, o mga uri ng mga bagay, na talagang naubos natin ang tamang impormasyon para sa gawain na nasa kamay.

At ang pinakamahalaga ay, paano natin makikipagtulungan ang lahat ng mga stakeholder, at lalo na ang mga stakeholder ng negosyo dahil sila ang nagbibigay sa atin ng totoong kahulugan ng kung ano ang data na iyon. Ang negosyo, sa pagtatapos ng araw, ay nagmamay-ari ng data. Ibinibigay nila ang mga kahulugan para sa mga bokabularyo at mga bagay na pinag-uusapan ni Eric, kaya kailangan namin ng isang lugar upang itali ang lahat. At ang paraan na ginagawa natin ay sa pamamagitan ng aming data ng pagmomolde ng data at arkitektura ng data ng imbakan.

Pupunta ako sa hawakan ng ilang mga bagay. Pupunta ako sa pakikipag-usap tungkol sa ER / Studio Enterprise Team Edition. Pangunahin kong pinag-uusapan ang tungkol sa produkto ng arkitektura ng data kung saan ginagawa namin ang pagmomolde ng data at ang uri ng bagay na iyon, ngunit maraming iba pang mga sangkap ng suite na hawakan ko lamang nang maikli. Makakakita ka ng isang snippet ng Business Architect, na kung saan makakagawa kami ng mga konseptong modelo, ngunit maaari rin nating gawin ang mga modelo ng proseso ng negosyo at maaari nating itali ang mga proseso ng proseso upang maiugnay ang aktwal na data na mayroon tayo sa aming mga modelo ng data. Tumutulong talaga ito sa amin na magkasama. Pinapayagan kami ng Software Architect na gumawa ng karagdagang mga konstruksyon tulad ng ilang pagmomolde ng UML at mga uri ng mga bagay upang magbigay ng pagsuporta sa mga lohika sa ilan sa iba pang mga system at proseso na pinag-uusapan natin. Ngunit napakahalaga habang lumilipas kami ay mayroon kaming repository at server ng koponan, at pag-uusapan ko iyon bilang uri ng dalawang halves ng parehong bagay. Ang imbakan ay kung saan namin iniimbak ang lahat ng mga modelo ng metadata pati na rin ang lahat ng metadata ng negosyo sa mga tuntunin ng mga glosaryo ng negosyo at mga termino. At dahil mayroon kaming kapaligiran na nakabase sa pag-iimbak, maaari nating i-tahiin ang lahat ng iba't ibang mga bagay na magkasama sa parehong kapaligirang iyon at pagkatapos ay maaari nating gawin ang mga magagamit para sa mga pangagpas, hindi lamang para sa mga teknikal na tao ngunit para sa mga negosyante rin. At iyon ay kung paano kami talaga nagsisimula upang humimok ng pakikipagtulungan.

At pagkatapos ang huling piraso na sasabihin ko sa madaling sabi ay, kapag naglalakad ka sa mga kapaligiran na ito, hindi lamang ito mga database na mayroon ka doon. Magkakaroon ka ng isang bilang ng mga database, mga data store, magkakaroon ka rin ng maraming, kung ano ang tatawagin ko, mga artifact sa legacy. Marahil ay ginamit ng mga tao ang Visio o iba pang mga diagram upang mag-mapa ng ilang mga bagay. Siguro mayroon silang iba pang mga tool sa pagmomolde at ang uri ng bagay. Kaya kung ano ang maaari nating gawin sa MetaWizard ay talagang kunin ang ilan sa impormasyong iyon at dalhin ito sa aming mga modelo, gawin itong kasalukuyang at magagamit ito, ubusin ito, sa isang kasalukuyang fashion muli, sa halip na maiupo lamang ito. Ito ay nagiging isang aktibong bahagi ng aming mga nagtatrabaho na modelo, na napakahalaga.

Kapag naglalakad ka sa isang samahan, tulad ng sinabi ko, maraming mga magkakaibang mga sistema ay wala roon, maraming mga solusyon sa ERP, mga solusyon sa kagawaran. Maraming mga organisasyon ang gumagamit din ng mga solusyon sa SaaS, na kinokontrol din at pinamamahalaang panlabas, kaya hindi namin kinokontrol ang mga database at mga uri ng mga bagay na naka-host sa mga iyon, ngunit kailangan pa rin nating malaman kung ano ang hitsura ng data na iyon at, siyempre, ang metadata sa paligid na iyon. Ang nahanap din namin ay maraming mga lipas na mga sistema ng legacy na hindi nalinis dahil sa diskarte na nakabase sa proyekto na pinag-usapan ni Malcolm. Nakapagtataka kung paano sa mga nakaraang taon ang mga organisasyon ay magsulid ng mga proyekto, papalitan nila ang isang sistema o isang solusyon, ngunit madalas na hindi sapat ang badyet ng proyekto na naiwan upang maalis ang mga hindi na ginagamit na mga solusyon, kaya ngayon nasa paraan lamang sila. At kailangan nating malaman kung ano talaga ang maalis natin sa ating kapaligiran pati na rin kung ano ang kapaki-pakinabang na pasulong. At iyon ay nakatali sa mahinang diskarte sa decommissioning. Bahagi at parsela ng parehong bagay.

Ang nahanap din namin, dahil ang maraming mga organisasyon ay naitayo mula sa lahat ng iba't ibang mga solusyon, nakikita natin ang maraming mga point-to-point na mga interface na may maraming data na gumagalaw sa isang bilang ng mga lugar. Kailangang ma-rationalize natin iyon at alamin na ang lineage ng data na aking binanggit nang madaling panahon upang magkaroon tayo ng isang mas magkakaugnay na diskarte tulad ng paggamit ng arkitekturang nakatuon sa serbisyo, mga serbisyo ng enterprise at mga uri ng mga bagay, upang maihatid ang tamang impormasyon sa isang publish-at-subscribe na uri ng modelo na ginagamit namin nang tama sa buong aming negosyo. At pagkatapos, siyempre, kailangan pa nating gumawa ng ilang uri ng analytics, gumagamit man tayo ng mga bodega ng data, data marts na may tradisyonal na ETL o gumagamit ng ilan sa mga bagong lawa ng data. Ang lahat ng ito ay bumababa sa parehong bagay. Ito ang lahat ng data, kung ito ay malaking data, kung ito ay tradisyonal na data sa mga nakabatay na mga database, kailangan nating dalhin ang lahat ng data na iyon upang maaari nating pamahalaan ito at malaman kung ano ang pakikitungo natin sa buong aming mga modelo.

Muli, ang pagiging kumplikado na gagawin namin ay mayroon kaming isang bilang ng mga hakbang na nais nating magawa. Una sa lahat, lumalakad ka at baka hindi mo naisip ang mga blueprints na iyon kung ano ang hitsura ng landscape na impormasyon na iyon. Sa isang tool ng pagmomolde ng data tulad ng ER / Studio Data Architect ay unang gagawa ka ng maraming reverse engineering sa mga tuntunin ng sabihin natin sa mga mapagkukunan ng data na nariyan, dalhin sila at pagkatapos ay tunay na tahiin ang mga ito sa mas maraming kinatawan mga modelo na kumakatawan sa buong negosyo. Ang mahalagang bagay ay, nais ba nating ma-decompose ang mga modelong iyon pati na rin kasama ang mga linya ng negosyo upang maaari nating maiugnay ang mga ito sa mas maliit na mga chunks, na maaari ring maiugnay ang mga taong negosyante sa ating negosyo, at ang ating mga analyst ng negosyo at iba pang mga stakeholder na nagtatrabaho sa ito.

Napakahalaga ng mga pamantayan sa pagbibigay ng pangalan at pinag-uusapan ko ito sa isang iba't ibang mga paraan dito. Ang mga pamantayan sa pagbibigay ng pangalan sa mga tuntunin ng kung paano namin pinangalanan ang mga bagay sa aming mga modelo. Napakadaling gawin sa mga lohikal na modelo, kung saan mayroon kaming isang mahusay na pangalan ng pagpupulong at isang mahusay na diksyonaryo ng data para sa aming mga modelo, ngunit pagkatapos din, nakakakita kami ng iba't ibang mga kombensyon sa pagbibigay ng pangalan para sa maraming mga pisikal na modelo na dinadala namin. reverse engineer, madalas na nakikita natin ang mga pinaikling pangalan at ang uri ng bagay na tatalakayin ko. At kailangan nating i-translate ang mga pabalik sa mga makabuluhang pangalan ng Ingles na makabuluhan sa negosyo upang maunawaan natin kung ano ang lahat ng mga piraso ng data na ito na mayroon tayo sa kapaligiran. At pagkatapos ay ang mga universal mappings ay kung paano namin silang magkakasama.

Sa tuktok ng nais naming i-dokumento at tukuyin nang higit pa at na kung saan maaari naming pag-uri-uriin ang aming data nang higit pa sa isang bagay na tinatawag na Mga Attachment, na ipapakita ko sa iyo ang isang pares ng mga slide. At pagkatapos ay isinasara ang loop, nais naming ilapat ang kahulugan ng negosyo, na kung saan ay itinali namin sa aming mga glosaryo ng negosyo at mai-link ang mga ito sa aming iba't ibang mga artifact ng modelo, kaya alam namin, kapag pinag-uusapan natin ang tungkol sa isang tiyak na term ng negosyo, kung saan ipinatupad sa aming data sa buong samahan. At pagkatapos ay huli, napag-usapan ko na ang katotohanan na kailangan namin ang lahat ng ito upang maging isang repositoryo batay sa maraming mga kakayahan sa pakikipagtulungan at pag-publish, kaya magamit ito ng aming mga stakeholder. Pupunta ako sa pakikipag-usap tungkol sa reverse engineering nang mabilis. Na uri ako ng binigyan ka ng isang napakabilis na highlight ng na. Ipapakita ko iyon sa iyo sa isang aktwal na demo para lamang ipakita sa iyo ang ilan sa mga bagay na maaari nating dalhin doon.

At nais kong pag-usapan ang tungkol sa ilan sa iba't ibang mga uri ng modelo at diagram na gagawin namin sa ganitong uri ng isang senaryo. Malinaw na gagawin namin ang mga modelo ng konsepto sa maraming mga pagkakataon; Hindi ako gagastos ng maraming oras sa na. Nais kong pag-usapan ang tungkol sa mga lohikal na modelo, mga pisikal na modelo at mga dalubhasang uri ng mga modelo na maaari naming likhain. At mahalaga na maaari nating likhain ang lahat sa parehong platform ng pagmomolde upang maaari naming silang magkatabi. Kasama rito ang mga dimensional na modelo at mga modelo din na gumagamit ng ilan sa mga bagong mapagkukunan ng data, tulad ng NoSQL na ipapakita ko sa iyo. At pagkatapos, ano ang hitsura ng modelo ng linya ng data? At paano natin itatakip ang data na iyon sa isang modelo ng proseso ng negosyo, ang susunod na tatalakayin natin.

Pupunta ako sa paglipat sa isang kapaligiran ng pagmomodelo dito upang mabigyan ka ng napakataas at mabilis na pangkalahatang-ideya. At naniniwala ako na maaari mong makita ang aking screen ngayon. Una sa lahat nais kong pag-usapan ang tungkol sa isang tradisyunal na uri lamang ng modelo ng data. At ang paraan na nais naming ayusin ang mga modelo kapag dinala namin sila, nais ba nating ma-decompose ang mga ito. Kaya kung ano ang nakikita mo dito sa kaliwang bahagi ay mayroon kaming lohikal at pisikal na mga modelo sa partikular na file na ito. Ang susunod na bagay ay, maaari ba nating masira ito kasama ang mga decompositions ng negosyo, kaya't kung bakit nakikita mo ang mga folder. Ang mga light blue ay mga lohikal na modelo at ang mga berde ay mga pisikal na modelo. At maaari rin kaming mag-drill down, kaya sa loob ng ER / Studio, kung mayroon kang isang agnas ng negosyo, maaari kang pumunta ng maraming mga antas ng malalim o sub-modelo na gusto mo, at ang mga pagbabago na ginagawa mo sa mas mababang antas ay awtomatikong sumasalamin sa mas mataas mga antas. Kaya't ito ay naging isang napakalakas na kapaligiran sa pagmomolde nang napakabilis.

Isang bagay na nais kong ituro din na napakahalaga upang simulan upang hilahin ang impormasyong ito nang magkasama ay maaari tayong magkaroon ng maraming mga pisikal na modelo na nauugnay din sa isang lohikal na modelo din. Madalas na maaari kang magkaroon ng isang lohikal na modelo ngunit maaari kang magkaroon ng mga pisikal na modelo sa iba't ibang mga platform at ganoong uri ng bagay. Siguro ang isang SQL Server halimbawa nito, marahil ang isa pa ay isang Oracle halimbawa. Mayroon kaming kakayahang itali ang lahat ng iyon sa parehong kapaligiran sa pagmomolde. At doon muli, ang nakuha ko dito ay isang aktwal na modelo ng bodega ng data na maaari, muli, maging sa parehong kapaligiran ng pagmomolde o maaari nating makuha ito sa imbakan at mai-link ito sa iba`t ibang mga bagay din.

Ang talagang nais kong ipakita sa iyo ay ang ilan sa iba pang mga bagay at iba pang mga variant ng mga modelo na nakukuha namin. Kaya kapag nakakuha tayo ng isang tradisyunal na modelo ng data tulad nito ay nasanay na kami upang makita ang mga tipikal na mga nilalang na may mga haligi at metadata at uri ng bagay, ngunit ang pananaw na iyon ay nag-iiba nang napakabilis kapag sinimulan nating harapin ang ilan sa mga mas bagong teknolohiyang NoSQL, o tulad ng nais pa ring tawagan ng ilang mga tao, ang malaking teknolohiya ng data.

Kaya ngayon sabihin natin na mayroon din tayong Hive sa ating kapaligiran. Kung baligtarin namin ang inhinyero mula sa isang kapaligiran ng Hive - at maaari naming ipasa at baligtarin ang inhinyero mula sa Hive kasama ang eksaktong parehong tool sa pagmomolde - nakikita namin ang isang bagay na medyo naiiba. Nakikita pa rin namin ang lahat ng data bilang konstruksyon doon, ngunit naiiba ang aming TDL. Ang mga sa iyo na ginagamit upang makita ang SQL, kung ano ang makikita mo ngayon ay ang Hive QL, na napaka-SQL ngunit sa labas ng parehong tool na maaari mong simulan ang pagtatrabaho sa iba't ibang mga wika ng script. Kaya maaari mong modelo sa kapaligiran na ito, makabuo ito sa kapaligiran ng Hive, ngunit tulad ng mahalaga, sa senaryo na inilarawan ko, maaari mong baligtarin ang inhinyero na ito sa lahat at magkaroon ng kamalayan ng ito at simulan itong tusahin ito. .

Kumuha tayo ng isa pa na medyo naiiba. Ang MongoDB ay isa pang platform na sinusuportahan namin nang katutubong. At kapag sinimulan mo ang pagpasok sa mga uri ng JSON ng mga kapaligiran na kung saan mayroon kang mga tindahan ng dokumento, ang JSON ay isang kakaibang hayop at mayroong mga konstruksyon sa iyon, hindi naaayon sa mga pamalitang modelo. Kaagad mong simulan ang pakikitungo sa mga konsepto tulad ng naka-embed na mga bagay at naka-embed na mga arrays ng mga bagay kapag sinimulan mong mag-interogate ang JSON at ang mga konsepto na iyon ay hindi umiiral sa tradisyonal na notasyon ng relational. Ang nagawa namin dito ay talagang pinalawak namin ang notasyon at ang aming katalogo upang makayanan ito sa parehong kapaligiran.

Kung titingnan mo sa kaliwa dito, sa halip na makita ang mga bagay tulad ng mga nilalang at talahanayan, tinawag namin silang mga bagay. At nakikita mo ang iba't ibang mga notasyon. Nakikita mo pa rin ang mga tipikal na uri ng sanggunian ng sanggunian dito, ngunit ang mga asul na entity na ipinapakita ko sa partikular na diagram na ito ay talagang naka-embed na mga bagay. At ipinapakita namin ang iba't ibang mga kardinal. Ang kardinalidad ng brilyante ay nangangahulugan na ito ay isang bagay sa isang dulo, ngunit ang kardinalidad ng isa ay nangangahulugang mayroon tayo, sa loob ng publisher kung susundin natin ang kaugnayan na iyon, mayroon kaming isang naka-embed na object object. Sa pagsisiyasat sa JSON ay natagpuan namin ito eksaktong eksaktong istraktura ng mga bagay na naka-embed sa patron, ngunit iyon ay talagang naka-embed bilang isang hanay ng mga bagay. Nakikita namin iyon, hindi lamang sa mga konektor mismo, ngunit kung titingnan mo ang aktwal na mga nilalang makikita mo na nakikita mo ang mga address sa ilalim ng patron na inuri din ito bilang isang hanay ng mga bagay. Nakakakuha ka ng isang napaka naglalarawang pananaw kung paano mo maiuwi ito.

At muli, ngayon kung ano ang nakita natin hanggang ngayon sa loob lamang ng ilang segundo ay tradisyonal na mga modelong relational na maraming antas, maaari nating gawin ang parehong bagay sa Hive, maaari nating gawin ang parehong bagay sa MongoDB, at iba pang malaking mapagkukunan ng data bilang mabuti. Ano ang maaari nating gawin, at ipapakita ko lang sa inyo ito nang napakabilis ay, napag-usapan ko ang katotohanan na magdala ng mga bagay mula sa iba pang iba't ibang mga lugar. Ipagpalagay ko na mag-import ako ng isang modelo mula sa isang database o reverse engineer nito, ngunit dadalhin ko ito mula sa panlabas na metadata. Para lamang mabigyan ka ng isang napakabilis na pananaw sa lahat ng iba't ibang uri ng mga bagay na maaari naming simulan upang dalhin.

Tulad ng nakikita mo, marami kaming mga bagay na maaari nating dalhin sa metadata sa aming kapaligiran sa pagmomolde. Simula sa mga bagay tulad ng kahit Amazon Redshift, Cassandra, maraming iba pang mga malaking platform ng data, kaya nakikita mo ang maraming mga nakalista. Ito ay ayon sa pagkakasunud-sunod. Marami kaming nakikitang malaking mapagkukunan ng data at ang uri ng bagay. Marami rin kaming nakakakita ng tradisyonal o mas luma na pagmomolde ng mga kapaligiran na maaari nating dalhin ang metadata. Kung dumadaan ako dito - at hindi ako gagastos ng oras sa bawat isa sa kanila - nakikita namin ang maraming iba't ibang mga bagay na maaari nating dalhin mula sa, sa mga tuntunin ng mga modelo ng mga platform at platform ng data. At ang isang bagay na napakahalagang mapagtanto dito ay isa pang bahagi na magagawa natin kapag sinimulan nating pag-usapan ang tungkol sa linya ng data, sa Enterprise Team Edition maaari rin nating maimbestiga ang mga mapagkukunan ng ETL, bagay man ito tulad ng Talend o SQL Server Information Services mappings, maaari natin talagang dalhin na upang simulan ang aming mga diagram ng linya ng data pati na rin at gumuhit ng isang larawan ng kung ano ang nangyayari sa mga pagbabagong ito. Halos wala sa kahon na mayroon kaming higit sa 130 sa iba't ibang mga tulay na talagang bahagi ng produkto ng Enterprise Team Edition, kaya makakatulong ito sa amin na hilahin ang lahat ng mga artifact sa isang modelong kapaligiran nang napakabilis.

Huling ngunit hindi bababa sa, nais ko ring pag-usapan ang katotohanan na hindi namin maiiwasan ang katotohanan na kailangan natin ang iba pang mga uri ng mga konstruksyon kung ginagawa natin ang warehousing ng data o anumang uri ng analytics. Nais pa rin nating magkaroon ng kakayahang gumawa ng mga bagay tulad ng mga dimensional na modelo kung saan mayroon kaming mga talahanayan ng katotohanan at mayroon kaming mga sukat at mga uri ng mga bagay. Isang bagay na nais kong ipakita sa iyo pati na rin ay maaari rin tayong magkaroon ng mga extension sa aming metadata na makakatulong sa amin na maikategorya kung ano ang mga uri ng mga sukat at lahat ng iba pa. Kaya't kung titingnan ko ang dimensional na tab ng data dito, halimbawa, sa isa sa mga ito, awtomatiko itong makakakita, batay sa pattern ng modelo na nakikita nito, at bibigyan ka ng isang panimulang punto kung sa palagay nito ay isang sukat o isang talahanayan ng katotohanan. Ngunit sa kabila nito, ang maaari nating gawin ay sa loob ng mga sukat at ang uri ng bagay na mayroon tayo kahit na iba't ibang uri ng mga sukat na magagamit natin upang maiuri ang data sa isang uri ng warehousing ng data ng kapaligiran. Kaya napakalakas na mga kakayahan na kami ay stitching na ito nang sama.

Pupunta ako sa isang ito dahil nasa demo ako ngayon at magpakita sa iyo ng ilang iba pang mga bagay bago ako lumundag sa mga slide. Isa sa mga bagay na kamakailan na naidagdag namin sa ER / Studio Data Architect ay tumakbo kami sa mga sitwasyon - at ito ay isang pangkaraniwang kaso ng paggamit kapag nagtatrabaho ka sa mga proyekto - iniisip ng mga developer sa mga tuntunin ng mga bagay, samantalang ang aming data ang mga modelo ay may posibilidad na mag-isip sa mga tuntunin ng mga talahanayan at mga nilalang at ang uri ng bagay. Ito ay isang napaka-sadyang modelo ng data, ngunit ito ay kumakatawan sa ilang mga pangunahing konsepto, kung saan ang mga nag-develop o kahit na mga analyst ng negosyo o mga gumagamit ng negosyo, ay maaaring isipin ang mga ito bilang iba't ibang mga bagay o konsepto sa negosyo. Napakahirap na pag-uri-uriin ang mga ito hanggang ngayon ngunit kung ano talaga ang nagawa namin sa ER / Studio Enterprise Team Edition, sa 2016 na release, mayroon na tayong konsepto na tinatawag na Mga Business Data Object. At kung ano ang nagpapahintulot sa amin na gawin ay nagpapahintulot sa amin na mag-encapsulate ng mga grupo ng mga nilalang o talahanayan sa mga tunay na bagay ng negosyo.

Halimbawa, kung ano ang nakuha namin dito sa bagong view na ito ay ang Purchase Order header at Order Line ay pinagsama nang magkasama, naka-encode sila bilang isang bagay, iisipin natin sila bilang isang yunit ng trabaho kapag nagpapatuloy kami sa data, at pinagsama-sama namin ang mga ito kaya napakadali na maiugnay ito sa iba't ibang mga madla. Magagamit muli ang mga ito sa buong kapaligiran ng pagmomolde. Ang mga ito ay isang tunay na bagay, hindi lamang isang konstruksyon ng pagguhit, ngunit mayroon din tayong dagdag na benepisyo na kapag kami ay tunay na nakikipag-usap mula sa pananaw sa pagmomodelo ay maaari nating piliin ang pagbagsak o palawakin ang mga ito upang makagawa tayo ng isang minubuyong pagtingin para sa mga diyalogo sa ilang mga tagapakinig ng stakeholder, at maaari rin nating, syempre, panatilihin ang mas detalyadong view tulad ng nakikita namin dito para sa higit pa sa mga teknikal na madla. Nagbibigay talaga ito sa amin ng isang mahusay na sasakyan ng komunikasyon. Ang nakikita natin ngayon ay ang pagsasama-sama ng maraming iba't ibang mga uri ng modelo, pinalaki ang mga ito sa konsepto ng mga bagay na data ng negosyo, at ngayon ay sasabihin ko kung paano namin talaga mailalapat ang higit pang kahulugan sa mga ganitong uri ng mga bagay at kung paano namin pinagsama ang mga ito sa aming pangkalahatang mga kapaligiran.

Sinusubukan ko lang na bumalik ang aking WebEx dito upang magawa ko iyon. At doon kami pupunta, bumalik sa mga slide ng Hot Tech. Pupunta lang ako ng mabilis na i-slide ang ilang mga slide dito dahil nakita mo na ito sa pagpapakita mismo ng modelo. Nais kong pag-usapan ang tungkol sa mga pamantayan sa pagbibigay ng pangalan. Nais naming mag-aplay at magpatupad ng iba't ibang mga pamantayan sa pagbibigay ng pangalan. Ang nais nating gawin ay, may kakayahan tayong aktwal na mag-imbak ng mga pamantayan ng mga pamantayan ng mga template sa aming mga repositori na panimulang itayo ang kahulugan sa pamamagitan ng, sa pamamagitan ng mga salita o parirala o kahit na mga pagdadaglat, at itatali sila pabalik sa isang makabuluhang uri ng salita ng Ingles. Gumagamit kami ng mga term sa negosyo, mga pagdadaglat para sa bawat isa, at maaari naming tukuyin ang pagkakasunud-sunod, ang mga kaso at magdagdag ng mga prefix at mga suffix. Ang karaniwang kaso ng paggamit para sa mga ito ay karaniwang kapag ang mga tao ay nagtatayo ng isang lohikal na modelo at pagkatapos ay talagang pasulong upang lumikha ng isang pisikal na modelo kung saan maaaring gumamit sila ng mga pagdadaglat at lahat ng iba pa.

Ang magagandang bagay ay ito ay kasing lakas, kahit na mas malakas sa baligtad, kung masasabi lamang natin kung ano ang ilan sa mga pamantayang pangngalan na iyon sa ilan sa mga pisikal na database na muli nating inhinyero, maaari nating kunin ang mga pagdadaglat, mapalitan ang mga ito mga salita, at dalhin ang mga ito pabalik sa mga parirala sa Ingles. Totoong ngayon ay maaari nating makuha ang tamang mga pangalan para sa kung ano ang hitsura ng aming data. Tulad ng sinasabi ko, ang tipikal na kaso ng paggamit ay nais naming ilipat pasulong, lohikal sa pisikal, at i-map ang mga data store at ang uri ng bagay. Kung titingnan mo ang screenshot sa kanang bahagi, makikita mo na may mga pinaikling mga pangalan mula sa mga pangalan ng pinagmulan at kapag inilapat namin ang isang template ng pamantayan sa pagbibigay ng pangalan, mayroon kaming talagang mas buong pangalan. At maaari naming ilagay ang mga puwang at lahat ng tulad nito sa kung nais namin, depende sa pamantayan ng pamantayang template na ginamit namin. Maaari naming itong tumingin gayunpaman nais namin upang tumingin upang dalhin sa aming mga modelo. Kapag alam lamang natin kung ano ang tinatawag na maaari nating aktwal na simulan upang mailakip ang mga kahulugan, sapagkat maliban kung alam natin kung ano ito, paano natin mailalapat ang isang kahulugan nito?

Ang masarap na bagay ay, maaari ba nating tulungan ito kapag ginagawa namin ang lahat ng uri ng mga bagay. Napag-usapan ko ang tungkol sa reverse engineering, maaari naming aktwal na maimbitahan ang mga template ng pamantayan sa pagbibigay ng pangalan nang sabay-sabay kapag gumagawa kami ng reverse engineering. Kaya sa isang hanay ng mga hakbang sa pamamagitan ng isang wizard, kung ano ang magagawa natin, kung alam natin kung ano ang mga kombensyon, maaari nating baligtarin ang inhinyero ng isang pisikal na database, ibabalik ito bilang mga pisikal na modelo sa isang modelong kapaligiran at ito ay ilalapat din ang mga nagngangalang kombensyon. Kaya makikita natin kung ano ang mga tulad ng Ingles na mga representasyon ng mga pangalan sa kaukulang lohikal na modelo sa kapaligiran. Maaari rin nating gawin ito at pagsamahin ito sa henerasyon ng XML Schema upang maaari tayong kumuha ng isang modelo at kahit na itulak ito sa aming mga pagdadaglat, ginagawa man natin ang mga SOA frameworks o ganoong uri ng bagay, kaya maaari din nating itulak ang iba't ibang mga kumbensyong pangngalan na aktwal na naimbak namin sa modelo mismo. Nagbibigay ito sa amin ng maraming napakalakas na kakayahan.

Muli, narito ang isang halimbawa ng kung ano ang magiging hitsura kung mayroon akong isang template. Ang taong ito ay aktwal na ipinapakita na mayroon akong EMP para sa "empleyado, " SAL para sa "suweldo, " PLN para sa "plano" sa isang pamantayang pamantayan sa pagpapangalan. Maaari ko ring ilapat ang mga ito upang paandarin ang mga ito nang interaktibo habang nagtatayo ako ng mga modelo at inilalagay ang mga bagay. Kung gumagamit ako ng singsing na ito at nag-type ako sa "Employee Salary Plan" sa pangalan ng entidad, ito ay kumilos gamit ang pamantayang pamantayan ng template Natukoy ko dito, bibigyan nito ako ng EMP_SAL_PLN habang nililikha ko ang mga nilalang at binigyan kaagad ako ng kaukulang pisikal na pangalan.

Muli, napakahusay para sa kapag kami ay dinisenyo at ipasa ang engineering din. Mayroon kaming isang napaka natatanging konsepto at ito ay kung saan talaga kaming nagsisimula upang dalhin ang mga kapaligiran na ito nang magkasama. At ito ay tinatawag na Universal Mappings. Sa sandaling dinala namin ang lahat ng mga modelong ito sa aming kapaligiran, kung ano ang magagawa namin, sa pag-aakalang na inilapat namin ngayon ang mga pangalang ito ng mga kombensiyon at madali silang makahanap, maaari na nating magamit ang isang konstruksyon na tinatawag na Universal Mappings sa ER / Studio. Maaari naming mai-link ang mga entidad sa buong mga modelo. Kung saan man nakikita natin ang "customer" - marahil ay mayroon kaming "customer" sa maraming iba't ibang mga sistema at maraming iba't ibang mga database - maaari naming simulan ang link ang lahat ng mga iyon nang sa gayon ay kapag nagtatrabaho ako dito sa isang modelo ko maaaring makita kung saan ang mga manipestasyon ng mga customer sa iba pang mga modelo. At dahil nakuha namin ang layer layer na kumakatawan sa, maaari naming itali ito sa mga mapagkukunan ng data at dalhin ito sa aming kung saan ang mga ginamit na mga katanungan na kung saan ang mga database ay nakatira din dito. Nagbibigay talaga ito sa amin ng isang kakayahan upang itali ang lahat ng ito nang magkasama nang magkakasabay.

Ipinakita ko sa iyo ang mga bagay na data ng negosyo. Nais ko ring pag-usapan ang tungkol sa mga metadata extension, na tinatawag naming Mga Attachment, napakabilis. Ang ginagawa nito ay nagbibigay sa amin ng kakayahang lumikha ng karagdagang metadata para sa aming mga bagay na modelo. Madalas na nais kong mag-set up ng mga ganitong uri ng mga pag-aari upang magmaneho ng maraming iba't ibang mga bagay mula sa pamamahala ng data at pananaw sa kalidad ng data, at makakatulong din sa amin sa pamamahala ng data at mga patakaran sa pagpapanatili ng data. Ang pangunahing ideya ay nilikha mo ang mga pag-uuri na ito at maaari mong ilakip ang mga ito saanman gusto mo, sa antas ng talahanayan, antas ng haligi, ang mga uri ng mga bagay. Ang pinaka-karaniwang kaso ng paggamit, siyempre, ay ang mga nilalang ay mga talahanayan, at pagkatapos ay maaari kong tukuyin: ano ang aking mga object data ng master, ano ang aking mga talahanayan ng sanggunian, ano ang aking mga talahanayan ng transactional? Mula sa isang perspektibo ng kalidad ng data ay maaari kong gawin ang mga pag-uuri sa mga tuntunin ng kahalagahan sa negosyo upang maaari nating unahin ang mga pagsisikap sa paglilinis ng data at ang uri ng bagay.

Isang bagay na madalas na hindi napapansin, ano ang patakaran sa pagpapanatili para sa iba't ibang uri ng data sa aming samahan? Maaari naming itakda ang mga ito at maaari naming aktwal na ilakip ang mga ito sa iba't ibang uri ng mga artifact ng impormasyon sa aming kapaligiran ng pagmomolde at, siyempre, ang aming imbakan din. Ang kagandahan ay, ang mga attachment na ito ay nakatira sa aming diksyunaryo ng data kaya kapag gumagamit kami ng mga diksyonaryo ng data ng enterprise sa kapaligiran, maaari naming ilakip ang mga ito sa maraming mga modelo. Kailangan lamang naming tukuyin ang mga ito nang isang beses at maaari nating gamitin nang paulit-ulit ang mga iba't ibang mga modelo sa ating kapaligiran. Ito ay isang mabilis na screenshot upang ipakita na maaari mong aktwal na tukuyin kapag gumawa ka ng isang kalakip, kung ano ang lahat ng mga piraso na nais mong ilakip ito. At ang halimbawang ito dito ay talagang isang listahan ng mga halaga, kaya kapag pumapasok sila maaari kang pumili mula sa isang listahan ng mga halaga, marami kang kontrol sa pagmomolde ng kapaligiran ng napili, at maaari mo ring itakda kung ano ang default ang halaga ay kung ang isang halaga ay hindi napili. Kaya maraming kapangyarihan doon. Nakatira sila sa diksyunaryo ng data.

Isang bagay na nais kong ipakita sa iyo nang kaunti pa sa screen na ito, bilang karagdagan makikita mo ang mga uri ng mga kalakip na nagpapakita ng tuktok na bahagi, sa ilalim nito makikita mo ang impormasyon ng seguridad ng data. Maaari kaming aktwal na mag-aplay ng mga patakaran sa seguridad ng data sa iba't ibang mga piraso ng impormasyon sa kapaligiran. Para sa iba't ibang mga mappings sa pagsunod, mga pag-uuri ng seguridad ng data, ipinapadala namin ang bilang ng mga ito sa labas ng kahon na maaari mo lamang mabuo at simulang gamitin, ngunit maaari mo ring tukuyin ang iyong sariling pagsunod sa mga mappings at pamantayan. Kung ginagawa mo ang HIPAA o alinman sa iba pang mga inisyatibo sa labas. At maaari mo talagang simulan upang mabuo ang napaka mayaman na hanay ng metadata na ito sa iyong kapaligiran.

At pagkatapos ay ang Glossary and Terms - ito ay kung saan ang kahulugan ng negosyo ay nakatali. Kami ay madalas na mayroong mga dictionaries ng data doon na madalas na isang organisasyon ay gumagamit bilang isang panimulang punto upang simulan upang palayasin ang mga glossary, ngunit ang terminolohiya at ang verbiage ay madalas napaka teknikal. Kaya kung ano ang maaari nating gawin ay magagawa natin, kung nais natin, gamitin ang mga ito bilang panimulang punto upang mapalayas ang mga glossary, ngunit talagang nais natin ang pag-aari ng negosyo. Ang nagawa namin sa kapaligiran ng server ng koponan ay nabigyan kami ng kakayahan para sa mga tao na lumikha ng mga kahulugan ng negosyo at pagkatapos ay mai-link namin ang mga ito sa iba't ibang mga artifact ng modelo na naaayon din sa kapaligiran ng pagmomolde. Kinikilala din namin ang puntong tinalakay kanina nang mas, kung mas maraming tao na na-type mo, mas maraming potensyal para sa pagkakamali ng tao. Ang ginagawa din natin sa aming glossary na istraktura ay, isa, sinusuportahan namin ang isang hierarchy ng glossary, kaya maaari tayong magkaroon ng iba't ibang mga uri ng glossary o iba't ibang uri ng mga bagay sa samahan, ngunit tulad ng mahalaga, ay kung mayroon ka nang ilan sa mga mapagkukunang ito doon kasama ang mga termino at lahat ng tinukoy, maaari naming aktwal na gawin ang isang import ng CSV upang hilahin ang mga ito sa aming kapaligiran sa pagmomolde, at ang aming koponan ng server o ang aming glossary din, at pagkatapos ay simulan ang pag-link mula doon. At sa tuwing may mababago na mayroong isang buong trail ng pag-audit ng kung ano ang bago at pagkatapos ng mga imahe, sa mga tuntunin ng mga kahulugan at lahat ng iba pa, at kung ano ang makikita mo na darating sa napakalapit na hinaharap ay higit pa sa isang workflow ng pahintulot kaya maaari nating kontrolin kung sino ang namamahala dito, pag-apruba ng mga komite o indibidwal, at ang uri ng bagay na iyon, upang mas mapalakas ang proseso ng pamamahala habang tayo ay pasulong.

Ano ang ginagawa nito para sa amin ay kapag mayroon kaming mga glossary term sa glosaryo ng aming server ng koponan, ito ay isang halimbawa ng pag-edit sa isang nilalang sa modelo mismo na dinala ko rito. Maaari itong maiugnay ang mga termino, ngunit ang ginagawa din natin ay kung mayroong mga salita na nasa glossary na lumilitaw sa mga tala o paglalarawan ng mayroon tayo sa ating mga nilalang dito, ang mga ito ay awtomatikong ipinapakita sa isang mas magaan na kulay na naka-link, at kung tayo mouse sa kanila, maaari naming aktwal na makita ang kahulugan mula sa glosaryo ng negosyo. Nagbibigay pa ito sa amin ng mas mayamang impormasyon kapag naubos namin ang impormasyon mismo, kasama ang lahat ng mga salitang glossary na nandiyan. Nakakatulong talaga ito upang mapayaman ang karanasan at mailapat ang kahulugan sa lahat ng ating pinagtatrabahuhan.

Kaya, muli, iyon ay isang napakabilis na flyby. Malinaw na maaari naming gumastos ng mga araw sa ito habang kami ay sumasalamin sa iba't ibang mga bahagi, ngunit ito ay isang napakabilis na flyby sa ibabaw. Ang talagang pinagsisikapang gawin ay maunawaan kung ano ang hitsura ng mga kumplikadong mga kapaligiran ng data. Nais naming mapabuti ang kakayahang makita ng lahat ng mga artifact ng data at makipagtulungan upang palayasin ang mga ito kasama ang ER / Studio. Nais naming paganahin ang mas mahusay at awtomatikong pagmomolde ng data. At iyon ang lahat ng mga uri ng data na pinag-uusapan natin, kung ito ay malaking data, tradisyunal na relational data, mga tindahan ng dokumento o anumang bagay. At muli, natapos namin iyon dahil mayroon kaming malakas na pasulong at reverse engineering na kakayahan para sa iba't ibang mga platform at iba pang mga tool na maaaring mayroon ka doon. At lahat ito ay tungkol sa pagbabahagi at pakikipag-ugnay sa buong samahan sa lahat ng mga stakeholder na kasangkot. Doon namin inilalapat ang kahulugan sa pamamagitan ng mga pamantayan sa pagbibigay ng pangalan. Pagkatapos ay inilalapat namin ang mga kahulugan sa pamamagitan ng aming mga glossary sa negosyo. At pagkatapos ay maaari naming gawin ang karagdagang mga pag-uuri para sa lahat ng aming iba pang mga kakayahan sa pamamahala kasama ang mga extension ng metadata tulad ng mga extension ng kalidad ng data, pag-uuri para sa pamamahala ng data ng master, o anumang iba pang mga uri ng pag-uuri na nais mong ilapat sa data na iyon. At pagkatapos ay maaari nating lagomin ang karagdagang at mapahusay ang komunikasyon kahit na higit pa sa mga bagay ng data ng negosyo, kasama ang iba't ibang mga madla ng stakeholder, lalo na sa pagitan ng mga modelo at developer.

At muli, kung ano ang napakahalaga tungkol dito, sa likod ng lahat ay isang pinagsama-samang repositoryo na may napakalakas na mga kakayahan sa pamamahala ng pagbabago. Wala akong oras upang ipakita ito ngayon dahil nakakakuha ito ng medyo kumplikado, ngunit ang repositoryo ay may napakalakas na mga kakayahan sa pamamahala ng pagbabago at mga daanan sa pag-audit. Maaari mong gawin ang mga pinangalanang paglabas, maaari kang gumawa ng mga pangalang bersyon, at mayroon din kaming kakayahan para sa mga sa iyo na gumagawa ng pamamahala ng pagbabago, maaari naming itali iyon mismo sa iyong mga gawain. Mayroon kaming kakayahang ngayon na mailagay ang mga gawain at iugnay ang iyong mga pagbabago sa modelo sa mga gawain, tulad ng mga developer ay maiugnay ang kanilang mga pagbabago sa code sa mga gawain o kwento ng gumagamit na nagtatrabaho din sila.

Muli, iyon ay isang napakabilis na pangkalahatang-ideya. Inaasahan ko na sapat na upang gisingin ang iyong gana sa pagkain upang maaari kaming makisali sa mas malalim na pag-uusap sa paghiwalayin ang ilan sa mga paksang ito habang hinaharap tayo sa hinaharap. Salamat sa iyong oras, at bumalik sa iyo, Rebecca.

Rebecca Jozwiak: Salamat, Ron, kamangha-manghang iyon at mayroon akong kaunting mga katanungan mula sa madla, ngunit nais kong bigyan ang aming mga analyst na magkaroon ng pagkakataon na lumubog ang kanilang mga ngipin sa iyong sinabi. Eric, pupunta ako sa unahan at marahil kung nais mong tugunan ang slide na ito, o ibang iba, bakit hindi mo muna mauna? O anumang iba pang katanungan.

Eric Little: Oo naman. Paumanhin, ano ang tanong, Rebecca? Nais mo bang hilingin sa akin ng isang bagay na tiyak o …?

Rebecca Jozwiak: Alam kong mayroon kang ilang mga katanungan sa una para kay Ron. Kung nais mong tanungin ngayon para sa kanya upang matugunan ang alinman sa mga iyon, o ilan sa mga ito sa iyong slide o anumang iba pa na tumagilid ng iyong interes na nais mong tanungin? Tungkol sa pag-andar ng pagmomodelo ng IDERA.

Eric Little: Oo, kaya ang isa sa mga bagay, Ron, kaya paano kayong mga lalaki, mukhang ang mga diagram na ipinakita ninyo ay mga pangkalahatang uri ng mga diagram ng relasyon sa entidad tulad ng karaniwang ginagamit ninyo sa pagtatayo ng database, tama?

Ron Huizenga: Oo, sa pangkalahatan ay nagsasalita, ngunit siyempre mayroon kaming mga pinalawig na uri para sa mga tindahan ng dokumento at pati na rin ang uri ng bagay. Talagang nag-iba kami mula sa purong notasyon ng relational, talagang nagdagdag kami ng mga karagdagang notasyon para sa iba pang mga tindahan.

Eric Little: Mayroon bang paraan na maaari mong magamit ang mga uri ng mga modelo na batay sa grapiko, kaya mayroong isang paraan upang maisama, halimbawa, ipagpalagay na mayroon akong isang bagay tulad ng isang nangungunang kuwadrante, tool ng kompositor ng TopBraid o may nagawa akong isang bagay sa Protégé o, alam mo, tulad ng mga pinansiyal na mga tao sa FIBO, ginagawa nila ang maraming trabaho sa semantika, bagay ng RDF - mayroong isang paraan upang dalhin ang ganitong uri ng pagmomolde ng uri ng graph ng relasyon sa entity-model sa tool na ito, at magamit ito?

Ron Huizenga: Kami ay talagang tinitingnan kung paano namin mahawakan ang mga grap. Hindi namin malinaw na paghawak ng mga database ng mga graph at ang uri ng bagay ngayon, ngunit naghahanap kami ng mga paraan na magagawa namin upang mapalawak ang aming metadata. Ibig kong sabihin, maaari nating dalhin ang mga bagay sa pamamagitan ng XML at ang uri ng bagay ngayon, kung maaari nating gawin kahit anong uri ng isang rendisyon ng XML upang dalhin ito bilang panimulang punto. Ngunit tinitingnan namin ang mas matikas na paraan upang maipasok ito.

At ipinakita ko rin sa iyo ang listahan ng mga reverse engineering bridges na mayroon kami doon, kaya lagi kaming nakatingin sa pagkuha ng mga extension sa mga tulay na iyon para sa mga tiyak na platform din. Ito ay patuloy, patuloy na pagsisikap, kung may katuturan, upang simulan na yakapin ang maraming mga bagong konstruksyon at ang iba't ibang mga platform doon. Ngunit masasabi ko na tiyak na tayo ang nangunguna sa paggawa nito. Ang mga bagay na ipinakita ko sa, halimbawa, MongoDB at ang uri ng bagay na iyon, kami ang unang nagtitinda ng pagmomolde ng data na aktwal na gawin iyon nang katutubong sa aming sariling produkto.

Eric Little: O sige, oo. Kaya ang iba pang katanungan na mayroon ako para sa iyo, kung gayon, ay sa mga tuntunin ng pamamahala at pagpapanatili ng - tulad ng noong ginamit mo ang halimbawa, kapag ipinakita mo ang halimbawa ng isang tao na "empleyado, " naniniwala ako na ito ay isang " suweldo "at pagkatapos ay mayroon kang isang" plano, "ay mayroong isang paraan, paano mo pinamamahalaan, halimbawa, iba't ibang uri ng mga tao na maaaring magkaroon - sabihin na mayroon kang isang malaking arkitektura, tama, ipagpalagay na mayroon kang isang malaking negosyo at ang mga tao ay nagsisimulang mag-isa ng mga bagay sa tool na ito at nakuha mo ang isang pangkat dito na may salitang "empleyado" at isang pangkat dito na may salitang "manggagawa." At isang tao sa itaas ang nagsasabing "suweldo" at sinabi ng ibang tao. "Sahod."

Paano kayo nakikipagkasundo at namamahala at namamahala sa mga uri ng pagkakaiba? Dahil alam ko kung paano natin gagawin ito sa mundo ng grapiko, alam mo, gagamitin mo ang mga listahan ng magkasingkahulugan o sasabihin mong mayroong isang konsepto at mayroon itong ilang mga katangian, o masasabi mo sa modelo ng SKOS na mayroon akong isang ginustong label at mayroon ako maraming kahaliling label na magagamit ko. Paano mo ginagawa iyon?

Ron Huizenga: Ginagawa namin ito sa isang iba't ibang mga paraan, at lalo na pag-usapan muna natin ang mga terminolohiya. Ang isa sa mga bagay na ginagawa natin, siyempre, ay nais nating magkaroon ng tinukoy o pinakahulugan na mga termino at sa glossary ng negosyo ay malinaw na kung saan natin nais ang mga ito. At pinapayagan namin ang mga link sa mga kasingkahulugan sa glossary ng negosyo pati na rin kung ano ang maaari mong gawin ay masasabi mo, narito ang term ko, ngunit maaari mo ring tukuyin kung ano ang lahat ng mga kasingkahulugan para sa mga iyon.

Ngayon ang kagiliw-giliw na bagay, siyempre, kapag sinimulan mo ang pagtingin sa buong malawak na tanawin ng data sa lahat ng mga iba't ibang mga system na iyong nakuha doon, hindi ka lamang makakalabas doon at baguhin ang kaukulang mga talahanayan at mga uri ng mga bagay na tumutugma sa pamantayang pangngalan na ito sapagkat maaaring ito ay isang pakete na binili mo, kaya wala kang kontrol sa pagbabago ng database o anuman.

Ang magagawa natin doon, bilang karagdagan sa kakayahang maiugnay ang mga kahulugan ng glossary, ay sa pamamagitan ng mga unibersal na mappings na napag-usapan ko, kung ano ang gagawin namin, at uri ng isang inirekumendang diskarte, ay ang magkaroon ng isang overarching lohikal na modelo na naglalabas ng kung ano ang iba't ibang mga konsepto ng negosyo na iyong pinag-uusapan. Itali ang mga tuntunin ng glossary ng negosyo sa mga iyon, at ang magandang bagay ay nakuha mo na ang konstruksyon na ito na kumakatawan sa isang lohikal na nilalang na tulad nito, maaari mong simulan upang mai-link mula sa lohikal na nilalang sa lahat ng mga pagpapatupad ng logical na nilalang na iyon ang iba't ibang mga sistema.

Pagkatapos kung saan kailangan mo sa na, maaari mong makita, oh, "tao" dito ay tinatawag na "empleyado" sa sistemang ito. Ang "suweldo" dito ay tinawag na "sahod" dito sa ibang sistemang ito. Dahil makikita mo iyon, makikita mo ang lahat ng iba't ibang mga pagpapakita ng mga iyon dahil magkasama mong iniugnay ang mga ito.

Eric Little: Okay mahusay, oo, nakuha ito. Sa diwa, ligtas bang sabihin na uri ng tulad ng ilang mga diskarte na nakatuon sa object?

Ron Huizenga: Medyo. Ito ay isang maliit na mas masidhi na kaysa, sa palagay ko maaari mong sabihin. Ibig kong sabihin, maaari mong gawin ang diskarte ng mano-mano ang pag-link at pagdaan at pag-inspeksyon at paggawa ng lahat ng mga ito din. Ang isang bagay na hindi talaga ako nagkaroon ng pagkakataon na pag-usapan - dahil muli, marami kaming kakayahan - mayroon din kaming isang buong interface ng automation sa tool mismo ng Data Architect. At isang kakayahan ng macro, na kung saan ay talagang isang wika sa programming sa tool. Kaya maaari naming aktwal na gawin ang mga bagay tulad ng pagsulat ng macros, lumabas ito at mag-usisa sa mga bagay at lumikha ng mga link para sa iyo. Ginagamit namin ito para sa pag-import at pag-export ng impormasyon, maaari naming gamitin ito para sa pagbabago ng mga bagay o pagdaragdag ng mga katangian, kaganapan na nakabase sa modelo mismo, o maaari naming gamitin ito upang tumakbo sa mga batch upang aktwal na lumabas at mag-interogate ng mga bagay at aktwal na mamayan ng iba't ibang mga konstruksyon sa modelo. Kaya mayroong isang buong interface ng automation na maaaring samantalahin din ng mga tao. At ang paggamit ng unibersal na mga mapa sa mga iyon ay isang napakalakas na paraan upang gawin iyon.

Rebecca Jozwiak: Okay, salamat Ron, at salamat kay Eric. Ang mga iyon ay mahusay na mga katanungan. Alam kong nagpapatakbo kami ng kaunting nakaraan sa tuktok ng oras, ngunit nais kong bigyan si Malcolm ng pagkakataon na itapon ang ilang mga katanungan ni Ron. Malcolm?

Malcolm Chisholm: Salamat, Rebecca. Kaya, Ron, napaka-kawili-wili, nakikita kong mayroong maraming mga kakayahan dito. Ang isa sa mga lugar na kinagigiliwan ko ay, sabihin kung mayroon kaming isang proyekto sa pag-unlad, paano mo nakikita ang data modeler na gumagamit ng mga kakayahan na ito at nagtatrabaho marahil na mas magkasama sa mga analyst ng negosyo, na may isang tagabuo ng data, na may isang kalidad ng data analyst, at sa mga sponsor ng negosyo na sa huli ay magiging responsable para sa aktwal na mga kinakailangan sa impormasyon sa proyekto. Paano talaga, ang alam ng data, alam mo, gawing mas epektibo at mahusay ang proyekto sa mga kakayahan na tinitingnan namin?

Ron Huizenga: Sa palagay ko ang isa sa mga unang bagay na kailangan mong gawin doon ay bilang isang modelo ng data - at hindi ko ibig sabihin na kunin ang ilan sa mga modelo, ngunit kahit papaano ay - may ilang mga tao pa rin ang impression na ang data modeler ay talagang uri ng papel na tulad ng gatekeeper, tinukoy namin kung paano ito gumagana, kami ang mga bantay na tinitiyak na tama ang lahat.

Ngayon ay may isang aspeto na, kailangan mong tiyakin na tinukoy mo ang isang arkitektura ng tunog ng data at lahat ng iba pa. Ngunit ang mas mahalagang bagay ay bilang isang modelo ng data - at natagpuan ko ito ng medyo malinaw nang ako ay kumunsulta - kailangan mong maging isang facilitator, kaya kailangan mong hilahin ang mga taong ito.

Hindi ito magiging isang disenyo sa harap, bubuo, magtayo ng mga database - kung ano ang kailangan mong magawa ay kailangan mong magtrabaho kasama ang lahat ng iba't ibang mga grupo ng stakeholder, paggawa ng mga bagay tulad ng reverse engineering, pag-import ng impormasyon sa, pagkakaroon ang iba pang mga tao ay nakikipagtulungan, nasa glosaryo o dokumentasyon, lahat ng tulad nito - at maging isang facilitator upang hilahin ito sa repository, at i-link ang mga konsepto nang magkasama sa repositoryo, at magtrabaho kasama ang mga taong iyon.

Ito ay talagang higit pa sa isang nagtutulungan na uri ng kapaligiran kung saan kahit na sa pamamagitan ng kahulugan ng mga gawain o kahit na mga talakayan ng talakayan o ang uri ng bagay na mayroon tayo sa server ng koponan, na ang mga tao ay maaaring magtulungan, magtanong at makarating sa mga pangwakas na produkto ng pagtatapos na sila kailangan para sa kanilang data architecture at kanilang samahan. Ganito bang sagot?

Malcolm Chisholm: Oo, sumasang-ayon ako. Alam mo, sa palagay ko na ang kasanayan sa pagpapadali ay isang bagay na talagang kanais-nais sa mga modelo ng data. Sumasang-ayon ako na hindi namin laging nakikita iyon, ngunit sa palagay ko kinakailangan iyon at nais kong iminumungkahi na mayroong isang pagkahilig kung minsan upang manatili sa iyong sulok na ginagawa ang iyong data sa pagmomolde, ngunit talagang kailangan mong lumabas doon na nagtatrabaho sa iba pang mga stakeholder group o hindi mo lang naiintindihan ang kapaligiran ng data na nakikipag-ugnayan ka, at sa palagay ko ang modelo ay naghihirap. Ngunit iyon lang ang aking opinyon.

Ron Huizenga: At kagiliw-giliw na dahil nabanggit mo ang isang bagay nang mas maaga sa iyong slide tungkol sa kasaysayan tungkol sa kung paano ang mga negosyo ay uri ng pagtalikod sa IT dahil hindi sila naghahatid ng mga solusyon sa isang napapanahong fashion at mga uri ng mga bagay.

Ito ay napaka-kagiliw-giliw na sa aking paglaon sa pagkonsulta sa kalaunan, bago maging isang tagapamahala ng produkto, karamihan sa mga proyekto na ginawa ko sa huling dalawang taon bago iyon, ay na-sponsor ng negosyo, kung saan talaga ang negosyo na nagmamaneho nito at ang mga arkitekto ng data. at ang mga modelo ay hindi bahagi ng IT. Kami ay isang bahagi ng isang pangkat na na-sponsor ng negosyo at doon kami bilang mga facilitator na nagtatrabaho kasama ang natitirang mga koponan ng proyekto.

Malcolm Chisholm: Kaya sa palagay ko iyon ay isang napaka-kagiliw-giliw na punto. Sa palagay ko nagsisimula kaming makakita ng isang paglipat sa mundo ng negosyo kung saan tinatanong ang negosyo, o iniisip siguro, hindi ganoon ang ginagawa ko, pagiging proseso tulad ng, ngunit nagsisimula din silang mag-isip tungkol sa kung ano ang data na nakikipagtulungan ako, ano ang mga pangangailangan ng aking data, ano ang datos na tinutukoy ko bilang data, at hanggang saan tayo makakakuha ng mga produkto at kakayahan ng IDERA upang suportahan ang pananaw na iyon, at sa palagay ko, ang mga pangangailangan ng negosyo, kahit na kahit na ito ay uri ng kaunti pa rin nascent.

Ron Huizenga: Sumasang-ayon ako sa iyo at sa palagay ko ay nakikita namin ito nang higit pa. Nakita namin ang isang paggising at hinawakan mo ito nang mas maaga sa mga tuntunin ng kahalagahan ng data. Nakita namin ang kahalagahan ng data nang maaga sa IT o sa ebolusyon ng mga database, kung gayon tulad ng sinasabi mo, kami ay uri ng nakuha sa buong pag-ikot ng pamamahala ng proseso - at ang proseso ay napakahalaga, huwag ako magkakamali doon - ngunit ngayon kung ano ang nangyari ay kapag nangyari iyon, ang uri ng data ng nawala na pagtuon.

At ngayon napagtatanto ng mga organisasyon na ang data ay talagang focal point. Ang data ay kumakatawan sa lahat ng ginagawa namin sa aming negosyo kaya kailangan nating tiyakin na mayroon kaming tumpak na data, na maaari nating mahanap ang tamang impormasyon na kailangan nating gawin ang ating mga pagpapasya. Dahil hindi lahat ay nagmula sa isang tinukoy na proseso. Ang ilan sa mga impormasyon ay isang byproduct ng iba pang mga bagay at kailangan pa rin nating mahanap ito, malaman kung ano ang kahulugan nito, at magagawang isalin ang data na nakikita natin doon sa huli sa kaalaman na maaari nating gamitin upang mas mapalakas ang ating mga negosyo.

Malcolm Chisholm: Tama, at ngayon ang isa pang lugar na pinaghirapan ko ay ang itatawag ko sa data ng ikot ng buhay na alam mo, kung titingnan namin ang uri ng data ng kadena ng supply ng pagdaan sa pamamagitan ng isang negosyo, magsisimula kami sa data acquisition o data capture, na maaaring ang data entry ngunit maaaring pantay na ito, nakakakuha ako ng data mula sa labas ng negosyo mula sa ilang data vendor.

At pagkatapos ay mula sa pagkuha ng data pumunta kami sa pagpapanatili ng data kung saan iniisip ko ang tungkol sa pag-standardize ng data na ito at maipapadala ito sa mga lugar kung saan kinakailangan ito. At pagkatapos gamitin ang data, ang aktwal na mga puntos kung saan ang data, makakakuha ka ng halaga sa data.

At sa mga lumang araw na ito ay tapos na ang lahat sa isang indibidwal na istilo, ngunit ngayon maaari na, alam mo, isang kapaligiran ng analytics, halimbawa, at pagkatapos ay lampas na, isang archive, isang tindahan, kung saan inilalagay namin ang data kapag hindi na kami kailangan ito at sa wakas ay isang uri ng proseso ng paglinis. Paano mo nakikita ang pag-modelo ng data na umaangkop sa pamamahala ng buong ikot ng buhay ng data?

Ron Huizenga: Iyon ay isang napakahusay na katanungan at isang bagay na talagang hindi ako nagkaroon ng oras upang matuklasan ang anumang detalye dito ngayon, kung ano talaga ang nagsisimula nating pag-usapan ay ang linya ng data. Kaya kung ano ang tunay na magagawa namin ay mayroon kaming kakayahan sa linya ng data sa aming mga tool at, tulad ng sinabi ko, maaari naming aktwal na kunin ang ilan dito mula sa mga tool ng ETL, ngunit maaari mo ring i-map ito sa pamamagitan lamang ng pagguhit ng taludtod. Ang alinman sa mga modelong data o database na aming nakuha at dinala sa mga modelo ay maaari naming isangguni ang mga konstruksyon mula sa diagram ng aming linya ng data.

Ang magagawa namin ay gumuhit ng isang daloy ng data, tulad ng sinabi mo, mula sa mapagkukunan hanggang sa target, at sa pamamagitan ng pangkalahatang ikot ng buhay ng kung paano lumilipat ang data sa iba't ibang mga sistema at kung ano ang makikita mo, kunin natin ang mga empleyado 'data - ito ay isa sa aking mga paborito batay sa isang proyekto na ginawa ko mga taon na ang nakalilipas. Nagtatrabaho ako sa isang samahan na mayroong data ng empleyado sa 30 iba't ibang mga sistema. Ang natapos naming gawin roon - at na-pop up ni Rebecca ang data lineage slide - ito ay isang medyo sadyang data lineage slide dito, ngunit ang nagawa naming gawin ay magdala ng lahat ng mga istruktura ng data, isangguni ang mga ito sa diagram, at pagkatapos namin maaari talagang magsimulang tingnan kung ano ang mga daloy sa pagitan, at paano naiugnay ang magkakaibang mga entity ng data sa isang daloy? At maaari rin nating lampasan iyon. Ito ay bahagi ng isang daloy ng data o linya ng guhit na nakikita natin dito. Kung nais mong lampasan na mayroon din kaming arkitekto ng negosyo ng bahagi ng suite na ito at ang parehong bagay ay nalalapat doon.

Ang alinman sa mga istruktura ng data na aming nakuha sa kapaligiran ng pagmomolde ng data, ang mga maaaring mai-refer sa tool sa pagmomolde ng negosyo upang kahit na sa iyong mga diagram ng modelo ng negosyo o mga diagram ng proseso ng iyong negosyo, maaari kang sumangguni sa mga indibidwal na tindahan ng data kung nais mong lumabas ng ang data sa kapaligiran ng data, at habang ginagamit mo ang mga ito sa mga folder sa iyong modelo ng proseso ng negosyo, maaari mo ring tukuyin ang CRUD sa mga ito, pati na rin kung paano ang inpormasyon na iyon ay natupok o ginawa, at pagkatapos ay maaari nating simulan upang makabuo mga bagay tulad ng mga ulat ng epekto at pagsusuri at mga diagram sa labas.

Ang pinupuntirya naming makarating, at mayroon kaming maraming mga kakayahan na, ngunit ang isa sa mga bagay na uri namin ay isang uri ng isang layunin na tinitingnan namin, habang patuloy na nagbabago ang aming mga tool sa pasulong, nagawang ma-mapa ang end-to-end, ang linya ng organisasyon ng data at ang buong ikot ng buhay ng data.

Malcolm Chisholm: Okay. Rebecca, pinayagan ba ako ng isa pa?

Rebecca Jozwiak: Papayagan kita ng isa pa, Malcolm, sige.

Malcolm Chisholm: Maraming salamat. Pag-iisip tungkol sa pamamahala ng data at pag-iisip tungkol sa pagmomolde ng data, paano natin makikipagtulungan ang dalawang pangkat na iyon at maunawaan ang bawat isa?

Eric Little: Sa gayon, kawili-wili, sa palagay ko talagang nakasalalay sa samahan, at bumalik sa aking naunang konsepto ay, sa mga samahang ito kung saan ang mga inisyatibo ay hinihimok ng negosyo na kami ay nakatali sa tama. koponan ngunit kami ay nakatali nang wasto sa mga gumagamit ng negosyo at tinutulungan namin silang tumayo ng kanilang programa ng pamamahala ng data. Muli, higit pa sa isang diskarte sa pagkonsulta ngunit talagang higit pa sa isang pag-andar ng negosyo.

Ang talagang kailangan mong magawa iyon ay kailangan mo ng mga modelo ng data at arkitekto na talagang nauunawaan ang negosyo, maaaring maiugnay sa mga gumagamit ng negosyo at pagkatapos ay tinulungan silang tumayo ang mga proseso ng pamamahala sa paligid nito. Nais ng negosyo na gawin ito, ngunit sa pangkalahatan ay nagsasalita mayroon kaming kaalaman sa teknolohiya upang matulungan silang matukoy ang mga uri ng mga programa. Kailangan talaga itong maging isang pakikipagtulungan, ngunit kailangan itong maging pag-aari ng negosyo.

Malcolm Chisholm: Okay, mahusay iyon. Salamat.

Eric Little: Okay.

Rebecca Jozwiak: Okay, maraming salamat. Mga miyembro ng madla, natatakot ako na hindi namin nakuha ang iyong mga katanungan, ngunit sisiguraduhin kong maipasa nila sa nararapat na panauhin na mayroon kami sa linya ngayon. Gusto kong maraming salamat kina Eric, Malcolm at Ron sa pagiging aming mga bisita ngayon. Ito ay mahusay na mga bagay-bagay, mga tao. At kung nasiyahan ka sa webcast ngayon ng IDERA, ang IDERA ay pupunta din sa isang Hot Technologies sa susunod na Miyerkules kung nais mong sumali, tatalakayin ang mga hamon ng pag-index at Oracles, kaya isa pang kamangha-manghang paksa.

Maraming salamat, mga tao, mag-ingat, at makikita ka namin sa susunod. Paalam.