Osoblje Techopedia, 28. rujna 2016
Odlazak: Domaćin Rebecca Jozwiak razgovara o rješenjima za arhitekturu podataka s Ericom Littleom iz OSTHUS-a, Malcolmom Chisholmom iz tvrtke prvi partneri iz San Francisca i Ronom Huizengom iz IDERA-e.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Rebecca Jozwiak: Dame i gospodo, zdravo, dobrodošli u Hot Technologies 2016. Danas raspravljamo o "izgradnji poslovne arhitekture podataka", definitivno vruća tema. Moje ime je Rebecca Jozwiak, bit ću vam domaćin za današnji webcast. Mi tweetujemo s hashtagom od # HotTech16, pa ako ste već na Twitteru, slobodno se pridružite i tome. Ako imate pitanja u bilo kojem trenutku, pošaljite ih u okno s pitanjima u donjem desnom kutu zaslona i mi ćemo se potruditi da na njih odgovore. Ako ne, pobrinut ćemo se da ih naši gosti dobiju za vas.
Tako danas imamo stvarno fascinantnu postavu. Danas je s nama puno teških napadača. Imamo Eric Little-a, potpredsjednika znanosti o podacima iz OSTHUS-a. Imamo Malcolma Chisholma, glavnog odjela za inovacije, što je zaista super naslov, za tvrtku First San Francisco Partners. A mi imamo Ron Huizenga, starijeg menadžera proizvoda iz IDERA-e. I, znate, IDERA ima zaista pun paket rješenja za upravljanje podacima i modeliranjem. I danas će nam dati demonstraciju o tome kako njegovo rješenje funkcionira. Ali prije nego što stignemo do toga, Eric Little, prenijet ću ti loptu.
Eric Little: U redu, hvala puno. Proći ću kroz nekoliko tema za koje mislim da će se malo odnositi na Ronove razgovore i nadam se da će postaviti pozornicu i za neke od tih tema, a neke od pitanja i pitanja.
Dakle, ono što me je zanimalo što IDERA radi jest da mislim da oni ispravno ističu da složeno okruženje u današnje vrijeme pokreće puno poslovnih vrijednosti. A pod složenim okolinama mislimo na složena podatkovna okruženja. A tehnologija se stvarno brzo kreće i teško je biti ukorak s današnjim poslovnim okruženjem. Tako će oni ljudi koji rade u tehnološkim prostorima često vidjeti da imate kupce koji rade s problemima: "Kako da koristim velike podatke? Kako ugraditi semantiku? Kako mogu povezati neke od ovih novih stvari sa starijim podacima? ", I tako dalje, i takva vrsta nas danas vodi u ova četiri velika podatka koja su mnogi dobro poznati, i razumijem da ih može biti više od četiri ponekad - vidio sam čak osam ili devet - ali obično, kada ljudi govore o stvarima poput velikih podataka ili ako govorite o velikim podacima, tada obično gledate u nekoj vrsti poduzeća. I tako će ljudi reći, u redu, dobro, razmislite o količini vaših podataka, što je obično fokus - to je upravo vaš iznos. Brzina podataka odnosi se na to koliko brzo mogu da ih premještam ili koliko brzo mogu da ih upitam ili dobijem odgovore, i tako dalje. I osobno mislim da je lijeva strana toga nešto što se relativno brzo rješava i rješava s puno različitih pristupa. Ali s desne strane vidim puno mogućnosti za poboljšanje i puno novih tehnologija koje zaista dolaze u prvi plan. A to doista ima veze s trećim stupcem, raznolikošću podataka.
Drugim riječima, danas većina tvrtki gleda strukturirane, polustrukturirane i nestrukturirane podatke. Podaci o slici počinju postati vruća tema, tako da možete koristiti računalni vid, gledati piksele, moći skenirati tekst, NLP, vađenje entiteta, imate grafičke podatke koji izlaze ili iz statističkih modela ili izlaze iz semantičkih imate modele relacija koji postoje u tablicama i tako dalje. Dakle, združivanje svih tih podataka i svih ovih različitih vrsta zaista predstavlja veliki izazov i to ćete vidjeti u, znate, Gartneru i drugim ljudima koji na neki način prate trendove u industriji.
I onda je posljednja stvar o kojoj ljudi govore u velikim podacima često ovaj pojam glasnosti, što je doista neizvjesnost vaših podataka, nejasnost istih. Koliko dobro znate o čemu se radi u vašim podacima, koliko dobro razumijete što je unutra i, znate? Mogućnost korištenja statistika i mogućnost korištenja neke vrste informacija oko onoga što možda znate ili korištenja nekog konteksta mogu vam biti od koristi. Dakle, sposobnost da na ovaj način gledate podatke s obzirom na to koliko ih imate, koliko brzo ih trebate premještati oko sebe ili ih dobijati, sve vrste podataka koje imate u vašem poduzeću i koliko ste sigurni gdje ste je, kakva je, kakve je kvalitete, i tako dalje. Za to su potrebni veliki, koordinirani napori između mnoštva pojedinaca za učinkovito upravljanje njihovim podacima. Stoga su modeliranje podataka sve važnije u današnjem svijetu. Tako dobri modeli podataka donose puno uspjeha u poslovnim aplikacijama.
Imate izvore podataka iz raznih izvora, kao što smo rekli, što zapravo zahtijeva puno različitih vrsta integracije. Dakle, izvlačenje svega zajedno zaista je korisno za pokretanje upita, primjerice, na brojnim vrstama izvora podataka i povlačenje informacija natrag. No da biste to učinili, potrebne su vam dobre strategije mapiranja, pa mapiranje takvih podataka i njihovo praćenje mogu biti pravi izazov. I onda imate ovo pitanje, pa kako mogu povezati svoje naslijeđene podatke sa svim tim novim izvorima podataka? Pretpostavimo da imam graf, moram li uzeti sve svoje relacijske podatke i staviti ih u graf? Obično to nije dobra ideja. Pa kako je moguće da ljudi mogu upravljati svim ovakvim modelima podataka koji se događaju? Analiza se doista mora provesti na mnogim od tih različitih vrsta podataka i kombinacija. Dakle, odgovori koji izlaze iz ovoga, odgovori koji su ljudima potrebni da bi donijeli dobre poslovne odluke su kritični.
Dakle, ne radi se samo o izgradnji tehnologije radi tehnologije, zapravo je, što ću učiniti, što mogu s njom, kakvu analizu mogu pokrenuti i sposobnosti, dakle, kao što već znam Razgovarati, skupiti ove stvari, integrirati je stvarno, jako važno. A jedna od tih vrsta analiza tada se pokreće na stvarima poput federalnog pretraživanja i upita. To zaista postaje neophodno. Vaši upiti moraju normalno biti nanizani u više vrsta izvora i pouzdati podatke natrag.
Jedan ključni element koji često, pogotovo ljudi će gledati ključne stvari kao što su semantičke tehnologije - i to je nešto za što se nadam da će Ron malo razgovarati u pristupu IDERA - kako razdvojiti ili upravljati modelni sloj vaših podataka iz samog podatkovnog sloja, iz tih neobrađenih podataka? Dakle, dolje na podatkovnom sloju možete imati baze podataka, možda podatke o dokumentu, možda proračunske tablice, možda slikovne podatke. Ako ste na područjima poput farmaceutske industrije, imate ogromne količine znanstvenih podataka. A onda, povrh toga, ljudi obično traže način da naprave model koji im omogućava da brzo integriraju te podatke i stvarno kada tražite podatke, ne želite da sve podatke uvuku u svoj sloj modela, ono što tražite u sloju modela koji trebate učiniti je da vam pruži lijepu logičku predstavu o tome što su stvari, zajedničke vokabule, uobičajene vrste entiteta i odnosa i mogućnost da stvarno uđete u podatke tamo gdje su. Dakle, mora reći o čemu se radi i mora se reći gdje je, i mora reći kako to donijeti i vratiti natrag.
Dakle, ovo je bio prilično uspješan pristup promicanju semantičkih tehnologija, a to je područje na kojem radim puno. Dakle, pitanje koje sam želio postaviti Ronu i za koje mislim da će biti korisno u odjeljku Pitanja i odgovora je da vidim kako se to postiže IDERA platformom? Dakle, je li sloj modela zapravo odvojen od podatkovnog sloja? Jesu li integriraniji? Kako to funkcionira i koji su od rezultata i prednosti koje vide iz svog pristupa? Stoga referentni podaci postaju također kritični. Dakle, ako ćete imati ovakve modele podataka, ako ćete moći federatizirati i pretraživati različite stvari, zaista morate imati dobre referentne podatke. No, problem je što se referentni podaci mogu teško održavati. Stoga je često imenovanje standarda samo po sebi težak izazov. Jedna grupa će nazvati nešto X, a jedna grupa nešto nazvati Y, a sada imate problem kako netko nađe X i Y kada traži ovu vrstu informacija? Budući da im ne želite samo dati dio podataka, želite im dati sve što je povezano. Istodobno se mijenjaju uvjeti, softver postaje zastario i tako dalje, kako zadržati i održavati te referentne podatke tijekom vremena?
I opet, semantičke tehnologije, konkretno koristeći stvari poput taksonomija i vokabulara, rječnika podataka, osigurale su standardni način da se to učini, koji je stvarno vrlo robustan, koristi određene vrste standarda, ali zajednica baza podataka je to učinila za i na različit način. Mislim da je ovdje jedan od ključeva razmišljanje o tome kako koristiti možda modele odnosa entiteta, kako koristiti možda grafičke modele ili neku vrstu pristupa ovdje koji će vam, nadamo se, pružiti standardni raspoređeni način rukovanja s vašim referentnim podacima. I onda, naravno, kad imate referentne podatke, strategije mapiranja moraju upravljati širokim rasponom imena i entiteta. Stoga stručnjaci za teme često vole koristiti vlastite izraze.
Dakle, izazov je uvijek u tome, kako nekome dati informacije, ali učiniti ih relevantnim za način na koji oni razgovaraju o tome? Tako da jedna grupa može imati jedan način gledanja na nešto, na primjer, vi ste kemičar koji radi na nekom lijeku, a možda ste strukturalni biolog koji radi na istom lijeku i možda imate različita imena za iste vrste entiteta koje se odnose na vaše polje. Morate smisliti načine na koji ćete te personalizirane terminologije povezati, jer drugi je pristup: ljude morate prisiliti da odustanu od termina i da koriste tuđe, što često ne vole. Još jedna poanta ovdje je teško rukovanje velikim brojem sinonima, pa u podacima mnogih ljudi postoji puno različitih riječi koje se mogu odnositi na istu stvar. Tamo imate problem s referencama pomoću skupa odnosa više prema jednom. Specijalizirani pojmovi razlikuju se od industrije do industrije. Ako ćete smisliti sveobuhvatno rješenje za ovu vrstu upravljanja podacima, koliko je lako prenosivo iz jednog projekta ili jedne aplikacije u drugu? To može biti još jedan izazov.
Automatizacija je važna, a ujedno je i izazov. Ručno je rukovati referentnim podacima skupo. Skupo je stalno držati ručno preslikavanje, a skupo je tako što stručnjaci za teme prestaju obavljati svakodnevne poslove i moraju ulaziti i stalno popravljati rječnike podataka, ažurirati definicije i tako dalje, i tako dalje. Vokabulari koji se mogu primjenjivati doista pokazuju veliku vrijednost. To su često rječnici koje možete pronaći izvan organizacije. Na primjer, ako radite s sirovom naftom, postojat će određene vrste vokabulara koje možete posuditi iz prostora otvorenog koda, isto kao i s lijekovima, isto s bankarskom industrijom i financijskim, isto kao i s puno takvih područja. Ljudi tamo stavljaju vokabule za ponovnu upotrebu, generičke, ponovljive, kako bi ih ljudi mogli koristiti.
I opet, gledajući IDERA alat, znatiželjno sam vidjeti kako oni to rješavaju u pogledu korištenja vrsta standarda. U semantičkom svijetu često vidite stvari poput SKOS modela koji pružaju standarde barem šire od / uže od odnosa, a to može biti teško napraviti u ER modelima, ali, znate, nije nemoguće, samo ovisi o tome koliko toga strojevima i vezama kojima možete upravljati u tim vrstama sustava.
I na kraju, na kraju sam htio samo usporediti neke semantičke motore koje vidim u industriji i zamoliti Rona i nagovoriti ga da razgovara o tome kako se IDERA-in sustav koristi u kombinaciji s bilo kojom semantičkom tehnologijom. Je li to moguće integrirati s trostrukim trgovinama, bazama podataka s grafovima? Koliko je jednostavno koristiti vanjske izvore jer se takve se stvari u semantičkom svijetu često mogu posuđivati pomoću SPARQL krajnjih točaka? Možete uvesti RDF ili OWL modele izravno u svoj model - obratite im se natrag - tako, na primjer, ontologija gena ili proteinska ontologija, koja može živjeti negdje u vlastitom prostoru sa vlastitom upravljačkom strukturom i ja mogu jednostavno uvesti sve ili dio toga koliko mi treba u vlastitim modelima. Zanima me kako IDERA pristupa ovom pitanju. Morate li sve održavati interno ili postoje načini korištenja drugih vrsta standardiziranih modela i uvlačenja u njih te kako to funkcionira? I zadnje što sam ovdje spomenuo je koliko je ručni rad stvarno uključen u izgradnju pojmovnika i spremišta metapodataka?
Dakle, znam da će nam Ron pokazati neke demonstracije o takvim stvarima koje će biti stvarno zanimljive. No, problemi s kojima se često susrećem kod savjetovanja s kupcima je što se puno pogrešaka događa ako ljudi pišu u vlastitim definicijama ili vlastitim metapodacima. Dakle, dobivate pogrešno pravopise, greske u prstima, to je jedno. Dobivate i ljude koji vam mogu uzeti nešto, znate, samo Wikipediju ili izvor koji nije nužno one kvalitete kakvu možda želite u vašoj definiciji, ili je vaša definicija samo iz perspektive jedne osobe, tako da nije potpuna i tada nije jasno. kako funkcionira proces upravljanja. Svakako, upravljanje je vrlo, vrlo veliko pitanje svaki put kad govorite o referentnim podacima i kad god govorite o tome kako se to može uklopiti u nečije glavne podatke, kako će koristiti njihove metapodatke i tako dalje.
Pa sam samo želio staviti neke od tih tema vani. To su predmeti koje vidim u poslovnom prostoru kroz mnoštvo različitih vrsta savjetovališta i puno različitih prostora, a stvarno me zanima što će nam Ron pokazati s IDERA-om da istakne neke od ovih tema, Pa hvala puno.
Rebecca Jozwiak: Puno hvala, Eric, i stvarno mi se sviđa vaš komentar da se mogu pojaviti mnoge pogreške ako ljudi pišu svoje definicije ili metapodate. Znam da u svijetu novinarstva postoji mantra da „mnoge oči čine malo pogrešaka“, ali kada se govori o praktičnim primjenama, previše ruku u teglici s kolačićima obično ostavlja vas sa puno razbijenih kolačića, zar ne?
Eric Little: Da, i mikrobe.
Rebecca Jozwiak: Da. S tim ću ići dalje i proslijedit ću ga Malcolmu Chisholmu. Malcolm, pod je tvoj.
Malcolm Chisholm: Puno hvala, Rebecca. Želio bih malo pogledati o čemu je Eric govorio, i dodati neka vrsta opažanja na koja, znate, Ron će možda htjeti reagirati, govoreći o "Toward Business-Driven Data Architecture "- što znači voditi posao i zašto je to važno? Ili je to samo neki oblik hype-a? Mislim da nije.
Ako pogledamo što se događa od kada znate, mainframe računala su stvarno postala dostupna tvrtkama - recimo, oko 1964. - do danas, možemo vidjeti da je bilo puno promjena. A ove bi promjene sažeo kao pomak od centrične usredotočenosti na procese. A to je ono što poslovne arhitekture podataka čini tako važnim i toliko relevantnim za današnji dan. I mislim da, znate, to nije samo buzzword, već nešto apsolutno stvarno.
Ali mi to možemo malo više cijeniti ako zaronimo u povijest, pa se vraćamo u vrijeme, sve do šezdesetih godina prošlog stoljeća i neko vrijeme nakon toga dominirali su mainframes. Oni su tada ustupili mjesto osobnim računalima na kojima ste se zapravo pobunili korisnici kad su računala ušla. Pobuna protiv centraliziranog IT-a za koju su mislili da ne zadovoljava njihove potrebe nije bila dovoljno agilna. To je brzo dovelo do distribuiranog računanja, kada su računala povezana. A onda se počeo događati Internet, koji je zamaglio granice poduzeća - sada je mogao komunicirati sa strankama izvan sebe u smislu razmjene podataka, što se prije nije događalo. I sada smo otišli u eru oblaka i velikih podataka gdje je oblak platforma koja doista komoditizira infrastrukturu, pa odlazimo, kao da je to, IT-u potrebe za pokretanjem velikih podatkovnih centara, jer, znate, mi Na raspolaganju nam je kapacitet oblaka i uporedo s tim velikim podacima o kojima je Eric, evo, rječito raspravljao. I sveukupno, kako vidimo, kako je došlo do pomaka u tehnologiji, ona postaje više usredotočena na podatke, više nam je stalo do podataka. Kao i s Internetom, kako se razmjenjuju podaci. S velikim podacima, četiri ili više v-a samih podataka.
U isto vrijeme, i što je možda još važnije, slučajevi poslovne upotrebe pomaknuli su se. Kada su računala prvi put predstavljena, korištena su za automatizaciju stvari poput knjiga i zapisa. I sve što je ručni proces, koji uključuje knjige ili slično, bilo je programirano u kući. To se u 80-ima prebacilo na dostupnost operativnih paketa. Više vam nije trebalo pisati vlastite platne liste, mogli biste kupiti nešto što je i učinilo. To je dovelo do velikog smanjenja broja radnika u to vrijeme ili restrukturiranja u mnogim IT odjelima. Ali tada se pojavila poslovna inteligencija, sa stvarima poput skladišta podataka, uglavnom u 90-ima. Slijedili su ih poslovni modeli dotcoma koji su, naravno, bili velika mahnitost. Zatim MDM. S MDM-om počinjete shvaćati da ne razmišljamo o automatizaciji; zapravo se zapravo fokusiramo na prikupljanje podataka kao podataka. A zatim analitika, koja predstavlja vrijednost koju možete dobiti iz podataka. A unutar analitike vidite tvrtke koje su vrlo uspješne čiji se osnovni poslovni model vrti oko podataka. Google, Twitter, Facebook bili bi dio toga, ali možete i tvrditi da je Walmart.
I tako posao sada stvarno razmišlja o podacima. Kako možemo izvući vrijednost iz podataka? Kako podaci mogu pokrenuti posao, strategiju, a mi smo u zlatnom dobu podataka. Dakle, s obzirom na to što se događa s obzirom na našu arhitekturu podataka, ako se podaci više ne smatraju jednostavno ispuhom koji dolazi iz stražnjeg dijela aplikacija, ali je uistinu središnji za naše poslovne modele? Pa, dio problema koji imamo u postizanju toga je IT stvarno zaglavio u prošlosti s životnim ciklusom razvoja sustava koji je bio posljedica toga što smo se u ranoj dobi IT-a morali brzo baviti tom fazom automatizacije procesa i raditi u projekti su slična stvar. Za IT - a ovo je pomalo karikatura - ali ono što želim reći je da su neke prepreke za dobivanje poslovne podatkovne arhitekture zato što smo, nekako, nekritički prihvatili kulturu u IT-u koja potječe iz davnih vremena.
Dakle, sve je projekt. Recite mi svoje zahtjeve detaljno. Ako stvari ne funkcioniraju, to je zato što mi niste rekli svoje zahtjeve. Danas to ne funkcionira s podacima jer ne započinjemo s automatiziranim ručnim procesima ili tehničkom pretvorbom poslovnih procesa. Vrlo često počinjemo s već postojećim podacima o proizvodnji koje pokušavamo. za dobivanje vrijednosti. Ali nitko tko sponzorira projekt usmjeren na podatke zaista ne razumije te podatke u dubinu. Moramo otkriti podatke, moramo napraviti analizu izvornih podataka. A to se zapravo ne podudara s razvojem sustava, znate - vodopad, SDLC životni ciklus - od kojih bih, Agile, tvrdio, bolja verzija toga.
A ono na što se fokusira tehnologija i funkcionalnost, a ne podaci. Na primjer, kada testiramo u fazi testiranja obično će biti, funkcionira li moja funkcionalnost, recimo moj ETL, ali mi ne testiramo podatke. Ne testiramo naše pretpostavke o ulaznim podacima koji dolaze. Da jesmo, bili bismo u možda boljoj formi i kao neko ko je radio projekte skladišta podataka i pretrpio promjene koje su uslijedile od mojih pretvarača, poštovao bih to. U stvari, ono što želimo vidjeti je testiranje kao preliminarni korak neprekidnog praćenja kvalitete podataka o proizvodnji. Dakle, ovdje imamo puno stavova u kojima je teško postići poslovnu arhitekturu podataka, jer smo uvjetovani erom usredotočenosti na procese. Moramo napraviti prijelaz na koncentriranje na podatke. I ovo nije totalni prijelaz, znate, još uvijek moramo puno raditi u procesu, ali ne razmišljamo u podatkovnom smislu kad trebamo i okolnostima koje se događaju kada stvarno dužan to učiniti.
Sada posao shvaća vrijednost podataka, žele ih otključati, pa kako ćemo to učiniti? Pa kako izvršiti prijelaz? Pa, podatke stavljamo u središte razvojnih procesa. I puštamo posao da vodi informacijske zahtjeve. I razumijemo da nitko ne razumije postojeće izvorne podatke na početku projekta. Mogli biste tvrditi da su struktura podataka i sami podaci tamo stigli putem IT-a i operacija, tako da bismo to trebali znati, ali stvarno ne. Ovo je razvoj usmjeren na podatke. Stoga moramo razmišljati o tome gdje radimo i kako radimo modeliranje podataka u svijetu usmjerenom na podatke. Moramo imati petlje s povratnim informacijama za korisnike u smislu preciziranja njihovih zahtjeva za informacijama, kao što otkrivamo podatke i profiliranje podataka., predvidjeti analizu izvornih podataka i kako postupno dobivamo sve veću sigurnost o našim podacima. I sada govorim o tradicionalnijem projektu kao što je MDM čvorište ili skladište podataka, a ne nužno i projekti velikih podataka, iako je to, mislim, još uvijek prilično blizu tomu. I tako te petlje za povratne informacije uključuju modele podataka, znate, postupno unapređuju svoj model podataka i komuniciraju s korisnicima kako bi osigurali da se zahtjevi za informacijama usavršavaju na temelju onoga što je moguće, dostupnih izvornih podataka, kako ih oni bolje razumiju, tako da Znaš, više nije slučaj da se podatkovni model nalazi u stanju koje ili nije tamo ili je u potpunosti izvedeno, to je postepeno dovođenje u fokus.
Slično tome, niže od toga imamo osiguranje kvalitete gdje razvijamo pravila za testiranje kvalitete podataka kako bismo bili sigurni da su podaci unutar parametara o kojima dajemo pretpostavke. Ulazeći u njega, Eric je mislio na promjene u referentnim podacima, koje se mogu dogoditi. Ne želite biti žrtva daljnje vrste, nekakvih, neupravljanih promjena u tom području, tako da pravila osiguranja kvalitete mogu preći u postprodukciju, kontinuirano praćenje kvalitete podataka. Tako da možete početi gledati hoćemo li biti usredotočeni na podatke, kako radimo razvoj usmjeren na podatke sasvim se razlikuje od SDLC i Agile temeljenih na funkcionalnosti. A onda moramo obratiti pažnju i na poslovne poglede. Imamo - i to opet odjekuje ono što je Eric govorio - imamo podatkovni model koji definira nacrt podatkovne priče za našu bazu podataka, ali istodobno su nam potrebni oni konceptualni modeli, poslovni ugledi na podatke koji tradicionalno nisu učinjeni u prošlost. Ponekad smo, mislim, pomislili da model podataka može sve, ali moramo imati konceptualni prikaz, semantiku i pogledati podatke, pretvoriti ih kroz sloj apstrakcije koji model pohrane prevodi u posao pogled. I opet, sve ono o čemu je Eric govorio u smislu semantike postaje važno za to, tako da zapravo imamo dodatne zadatke za modeliranje. Mislim da je to, znate, zanimljivo ako ste se upustili u redove kao data modeler kao i ja, i opet, nešto novo.
I na kraju, želim reći da i veća arhitektura također mora odražavati tu novu stvarnost. Na primjer, tradicionalni MDM za kupce je vrsta, u redu, prebacimo naše podatke o klijentima u sastajalište gdje ga mi, znate, ima smisla u smislu stvarno samo kvalitete podataka za back office aplikacije. Što je s gledišta poslovne strategije vrsta zijevanja. Danas, međutim, promatramo MDM čvorišta kupaca koja u sebi sadrže dodatne podatke o profilu kupca, a ne samo statičke podatke koji tada stvarno imaju dvosmjerno sučelje s aplikacijama klijenta za transakcije. Da, i dalje podržavaju stražnji ured, ali sada znamo i za takva ponašanja naših kupaca. Ovo je skuplje za izgradnju. Ovo je složenije graditi. Ali poslovanje se vodi na način na koji tradicionalni MDM kupca nije. Tržite se orijentacijom na posao protiv jednostavnijih dizajna koji su lakši za implementaciju, ali za posao, to žele vidjeti. Zaista smo u novoj eri i mislim da postoji niz razina na koje moramo odgovoriti arhitekturi podataka koji vode poslovnim silama i mislim da je izuzetno uzbudljivo vrijeme raditi stvari.
Pa hvala, vraćam se tebi Rebecca.
Rebecca Jozwiak: Hvala Malcolm, i stvarno sam uživao u onome što ste rekli o modelima podataka mora hraniti poslovni pogled, jer, za razliku od onoga što ste govorili, gdje je IT tako dugo držao uzde i jednostavno nekako više nije tako, da se kultura treba pomaknuti. I prilično sam siguran da je u pozadini bio pas koji se s vama 100% složio. A s tim ću loptu proslijediti Ronu. Jako sam uzbuđena što vidim vaš demo. Ron, kat je tvoj.
Ron Huizenga: Puno vam hvala i prije nego što skočimo u to, ja ću proći kroz nekoliko slajdova, a zatim malo demo-a jer, kao što su Eric i Malcolm istaknuli, to je vrlo široka i duboka tema, i s onim o čemu danas govorimo samo smo strugali površinu jer postoji toliko mnogo aspekata i toliko stvari koje stvarno trebamo razmotriti i pogledati iz arhitekture usmjerene na poslovanje. Naš pristup je da se ta modela zasnivaju i dobiju istinsku vrijednost iz modela jer ih možete koristiti kao komunikacijsko vozilo kao i sloj koji će omogućiti druge sustave. Bez obzira radi li se o uslužno orijentiranoj arhitekturi ili drugim stvarima, model zaista postaje temelj života onoga što se događa, sa svim metapodacima oko sebe i podacima koje imate u svom poslu.
Ono o čemu želim razgovarati je gotovo da ovaj korak krenem unatrag, jer je Malcolm dotaknuo neke povijesti načina na koji su se razvijala rješenja i takve stvari. Jedan od načina da stvarno ukažem na to koliko je važno imati zdravu arhitekturu podataka je slučaj upotrebe koji sam se često susretao prilikom savjetovanja prije nego što sam ušao u ulogu upravljanja proizvodom, a to je bilo da bih krenuo u organizacije da li su radili o transformaciji poslovanja ili su samo zamijenili neke postojeće sustave i tu vrstu stvari, i vrlo je brzo postalo evidentno koliko loše organizacije razumiju vlastite podatke. Ako uzmete poseban slučaj poput ovog, bilo da se radi o savjetniku ili je to možda osoba koja je tek započela s organizacijom, ili je vaša organizacija stvorena tijekom godina stjecanjem različitih tvrtki, što završite je s vrlo složenim okruženjem vrlo brzo, s mnoštvom novih različitih tehnologija, kao i naslijeđene tehnologije, ERP rješenja i svega ostalog.
Dakle, jedna od stvari koje stvarno možemo učiniti našim pristupom modeliranju je odgovoriti na pitanje: kako ja imam smisla za sve to? Mi stvarno možemo početi dijeliti podatke, tako da posao može iskoristiti informacije koje imamo ispravno. I izlazi iz toga, što imamo tamo u tim sredinama? Kako se pomoću modela mogu izvući potrebne informacije i bolje razumjeti te informacije? I tada imamo tradicionalne vrste metapodataka za sve različite stvari poput relacijskih modela podataka, a navikli smo vidjeti stvari poput definicija i rječnika podataka, znate, tipove podataka i tu vrstu stvari. Ali što je s dodatnim metapodacima koje želite snimiti da biste im zaista dali još više smisla? Na primjer, koji su entiteti kandidati koji bi trebali biti referentni objekti podataka, koji bi trebali biti matični objekti za upravljanje podacima i takve vrste stvari i povezati ih. I kako informacije teče kroz organizaciju? Podaci teče kako se konzumiraju i s procesnog gledišta, ali i s podacima o liniji podataka kroz naše poslovanje i kako se probija kroz različite sustave ili kroz trgovine podataka, tako da znamo kada gradimo I-rješenja ili one vrste stvari, zapravo koristimo ispravne podatke za zadatak koji nam je pri ruci.
A onda je vrlo važno kako nazovimo sve te dionike na suradnju, a posebno poslovne dionike, jer oni su ti koji nam daju pravo značenje onoga što ti podaci imaju. Tvrtka na kraju dana posjeduje podatke. Oni daju definicije za vokabule i stvari o kojima je Eric govorio, pa nam treba mjesto gdje ćemo sve to povezati. A način na koji to radimo je kroz naše modeliranje podataka i arhitekture spremišta podataka.
Dotaknut ću se nekoliko stvari. Razgovarat ću o ER / Studio Enterprise Team Edition. Prvenstveno ću govoriti o proizvodu arhitekture podataka gdje radimo modeliranje podataka i takvu vrstu stvari, ali postoji puno drugih komponenti paketa koje ću se samo ukratko dotaknuti. Vidjet ćete jedan isječak poslovnog arhitekta, gdje možemo napraviti konceptualne modele, ali možemo i modele poslovnih procesa i te modele procesa povezati sa stvarnim podacima koje imamo u našim modelima podataka. Zaista nam pomaže da povežemo taj spoj. Software Architect omogućava nam da napravimo dodatne konstrukcije, poput nekih UML modeliranja i onih vrsta stvari, kako bismo pružili potpornu logiku nekim drugim sistemima i procesima o kojima govorimo. Ali što je vrlo važno, dok se krećemo prema dolje imamo poslužitelj spremišta i tim i o tome ću govoriti kao o dvije polovice iste stvari. Spremište je mjesto gdje pohranjujemo sve modelirane metapodate kao i sve poslovne metapodate u smislu poslovnih pojmovnika i izraza. A budući da imamo ovo okruženje temeljeno na skladištu, onda možemo sve te različite stvari spojiti zajedno u tom istom okruženju i tada možemo učiniti sve dostupnima za konzumaciju, ne samo tehničkim osobama, već i poslovnim ljudima. I tako zapravo počinjemo pokretati suradnju.
I onda je posljednji dio o kojem ću ukratko govoriti, kad uđete u ta okruženja, vani nisu samo baze podataka. Imat ćete niz baza podataka, spremišta podataka, također ćete imati puno, kako bih rekao, naslijeđenih artefakata. Možda su ljudi koristili Visio ili druge dijagrame za mapiranje nekih stvari. Možda su imali i druge alate za modeliranje i takve vrste stvari. Dakle, ono što možemo učiniti s MetaWizardom je zapravo izvući neke od tih podataka i unijeti ih u naše modele, učiniti ga aktuelnim i moći ga ponovo koristiti, konzumirati, a ne samo postavljati ga vani. Sada postaje aktivni dio naših radnih modela, što je vrlo važno.
Kad uđete u neku organizaciju, kao što rekoh, vani je puno raznolikih sustava, puno ERP rješenja, neusklađena odjela. Mnoge organizacije također koriste SaaS rješenja koja se također izvana kontroliraju i upravljaju, tako da mi ne kontroliramo baze podataka i te vrste stvari u domaćinima na njima, ali svejedno trebamo znati kako ti podaci izgledaju i, naravno, metapodaci oko toga. Ono što također nalazimo je puno zastarjelih zaostavljenih sustava koji nisu očišćeni zbog pristupa temeljenog na projektu koji je govorio Malcolm. Nevjerojatno je kako će posljednjih godina organizacije vršiti projekte, zamijenit će sustav ili rješenje, ali često nije preostalo dovoljno proračuna za uklanjanje zastarjelih rješenja, pa su oni sada na putu. I moramo shvatiti što se zapravo možemo riješiti u našem okruženju, kao i ono što je korisno naprijed. To je povezano s lošom strategijom razgradnje. To je dio te iste stvari.
Ono što također pronalazimo, jer je mnogo organizacija izgrađeno iz svih tih različitih rješenja, je da vidimo puno sučelja od točke do točke s puno podataka koji se kreću na mnogim mjestima. To trebamo biti u mogućnosti racionalizirati i shvatiti da je niz podataka koji sam prethodno ukratko spomenuo da bismo mogli imati kohezivniju strategiju poput korištenja servisno orijentirane arhitekture, korporativnih servisnih autobusa i takvih vrsta stvari za pružanje ispravnih podataka na tip modela za objavljivanje i pretplatu koji ispravno koristimo u svom poslu. I onda, naravno, još uvijek moramo napraviti neku vrstu analitike, bilo da koristimo skladišta podataka, marku podataka s tradicionalnim ETL-om ili upotrebljavamo neke od novih podataka. Sve se svodi na istu stvar. Sve su to podaci, bilo da se radi o velikim podacima, bilo da se radi o tradicionalnim podacima u relacijskim bazama podataka, sve te podatke moramo objediniti kako bismo ih mogli upravljati i znati s čime se bavimo u svim našim modelima.
Opet, složenost koju ćemo učiniti je da imamo nekoliko koraka koje želimo biti u mogućnosti učiniti. Prije svega, ulazite unutra i možda nemate one nacrte o tome kako izgleda taj informacijski krajolik. U alatu za modeliranje podataka poput ER / Studio Data Architect prvo ćete raditi mnogo obrnutog inženjeringa u smislu da ukažemo na izvore podataka koji su vani, unesite ih unutra, a zatim ih zajedno spojite u reprezentativnije modeli koji predstavljaju cjelokupno poslovanje. Važno je da li želimo da te modele možemo i razgraditi duž poslovnih linija kako bismo ih mogli povezati u manjim komadima, na što se mogu odnositi i naši poslovni ljudi i naši poslovni analitičari i drugi dionici koji rade na tome.
Standardi za nazive izuzetno su važni i ovdje govorim o nekoliko različitih načina. Imenovanje standarda u smislu kako imenujemo stvari u svojim modelima. To je prilično lako učiniti u logičkim modelima, gdje imamo dobru konvenciju o imenovanju i dobar rječnik podataka za naše modele, ali tada također vidimo različite konvencije o imenovanju za mnoge fizičke modele koje donosimo. obrnuti inženjer, vrlo često vidimo skraćena imena i onu vrstu stvari o kojoj ću govoriti. A mi ih moramo prevesti na značajna engleska imena koja imaju smisla za posao da bismo mogli razumjeti što sve ovi podaci imaju u okruženju. I onda je univerzalno preslikavanje način na koji ih zajedno šlepamo.
Povrh toga, mi bismo zatim dokumentirali i definirali dalje i tu možemo dalje klasificirati svoje podatke s nečim što se naziva Prilozi, a zatim ću vam pokazati nekoliko prezentacija. A zatim zatvarajući petlju, želimo primijeniti to poslovno značenje, a to je mjesto gdje povezujemo naše poslovne pojmovnike i možemo ih povezati s različitim artefaktima modela, tako da znamo kada govorimo o određenom poslovnom pojmu, gdje je to implementirani u naše podatke u cijeloj organizaciji. I na kraju, već sam govorio o činjenici da sve ovo treba da bude spremište temeljeno na puno mogućnosti suradnje i objavljivanja, tako da naši dionici mogu to iskoristiti. Razgovarat ću o obrnutom inženjeringu prilično brzo. Već sam vam dao jedan vrlo brz naglasak na tome. Pokazat ću vam to u stvarnom demo prikazu samo da vam pokažem neke stvari koje tamo možemo unijeti.
I želim razgovarati o nekim različitim vrstama modela i dijagramima koje bismo proizveli u ovoj vrsti scenarija. Očito ćemo konceptualne modele izraditi u puno slučajeva; Neću trošiti puno vremena na to. Doista želim razgovarati o logičnim modelima, fizičkim modelima i specijaliziranim vrstama modela koje možemo stvoriti. I važno je da sve to možemo stvoriti na istoj platformi za modeliranje kako bismo ih zajedno povezali. To uključuje dimenzionalne modele i modele koji koriste neke od novih izvora podataka, poput NoSQL-a koji ću vam pokazati. A onda, kako izgleda model linijske linije? A kako ćemo te podatke uklopiti u model poslovnog procesa, o čemu ćemo razgovarati u nastavku.
Ovdje ću se prebaciti na okruženje za modeliranje samo da bih vam pružio vrlo visok i brz pregled. I vjerujem da biste sada trebali moći vidjeti moj ekran. Prije svega želim razgovarati o samo tradicionalnom tipu modela podataka. A način na koji želimo organizirati modele kada ih unesemo, želimo da ih možemo razgraditi. Dakle, ono što ovdje vidite na lijevoj strani je da u ovoj datoteci modela imamo logičke i fizičke modele. Sljedeća stvar je da li možemo raščlaniti je na poslovne dekompozicije, pa zato vidite mape. Svijetloplave su logični modeli, a zelene fizički modeli. A mi također možemo smanjiti vrijednost, tako da u ER / Studio, ako imate poslovni raspad, možete ići na onoliko nivoa koliko duboko ili pod-modela, a promjene koje napravite na nižim razinama automatski se odražavaju na višim razinama. Na taj način vrlo brzo postaje vrlo moćno okruženje za modeliranje.
Nešto za što bih također želio istaknuti da je vrlo važno početi prikupljati ove podatke je da možemo imati više fizičkih modela koji odgovaraju i jednom logičkom modelu. Često imate logičan model, ali možda imate fizičke modele na različitim platformama i takvu vrstu stvari. Možda je jedan primjerak SQL Servera, možda je drugi primjerak Oracle. Imamo mogućnost da sve to povežemo zajedno u istom modelu. I opet, ovdje imam stvarni model skladišta podataka koji, opet, može biti u istom modeling okruženju ili ga možemo imati u spremištu i povezati ga kroz različite stvari.
Ono što sam vam uistinu htio pokazati su neke druge stvari i druge varijante modela u koji upadamo. Dakle, kada uđemo u tradicionalni model podataka kao što je ovaj, navikli smo vidjeti tipične entitete sa stupovima i metapodacima i takvu vrstu stvari, ali to gledište vrlo brzo varira kada se počnemo baviti nekim od ovih novijih NoSQL tehnologija, ili kako ih neki još uvijek vole nazivati, tehnologijama velikih podataka.
Recimo sada da smo i košnicu dobili u svom okruženju. Ako inženjer obrnemo iz okruženja košnice - a možemo inženjera iz Hive naprijed i obrnuto s istim istim alatom za modeliranje - vidimo nešto malo drugačije. Sve podatke i dalje shvaćamo kao konstrukte, ali TDL-ovi su različiti. Oni od vas koji su navikli vidjeti SQL, ono što biste sada vidjeli je Hive QL, koji je vrlo sličan SQL-u, ali izvan istog alata sada možete započeti raditi s različitim jezicima skriptiranja. Dakle, možete modelirati u ovom okruženju, generirati ga u okruženju košnice, ali što je još važnije, u scenariju koji sam opisao, možete obrnuti sve to u inženjer i smisliti ga te početi zajedno to zajedno praviti,
Uzmimo još jednu koja je malo drugačija. MongoDB je još jedna platforma koju izvorno podržavamo. A kad počnete ulaziti u JSON tipove okruženja u kojima imate skladišta dokumenata, JSON je drugačija životinja i u tome postoje konstrukti koji ne odgovaraju relacijskim modelima. Ubrzo se počinjete baviti pojmovima poput ugrađenih objekata i ugrađenih nizova objekata kad počnete ispitivati JSON i ti koncepti ne postoje u tradicionalnoj relacijskoj notaciji. Ono što smo ovdje učinili je da smo zapravo proširili oznaku i naš katalog da bismo to mogli nositi u istom okruženju.
Ako ovdje pogledate lijevo, umjesto da vidimo stvari poput entiteta i tablica, mi ih nazivamo objektima. I vidite različite naznake. Ovdje i dalje vidite tipične vrste referentnih bilježaka, ali ovi plavi entiteti koje prikazujem u ovom određenom dijagramu zapravo su ugrađeni objekti. I pokazujemo različite kardinalnosti. Kardinalnost dijamanata znači da je to objekt na jednom kraju, ali kardinalnost jednog znači da, unutar izdavača, ako slijedimo taj odnos, imamo ugrađeni objekt adrese. Ispitivanjem JSON-a otkrili smo da je točno ista struktura objekata ugrađena u zaštitnika, ali zapravo je ugrađena u niz predmeta. To vidimo ne samo preko samih priključaka, već ako pogledate stvarne entitete vidjet ćete da vidite adrese pod zaštitnikom, što je također klasificirano kao niz objekata. Dobivate vrlo opisno gledište kako to možete unijeti.
I opet, sada ono što smo do sada vidjeli u samo nekoliko sekundi su tradicionalni relacijski modeli koji su na više razina, isto možemo učiniti s Hiveom, isto možemo učiniti s MongoDB i drugim velikim izvorima podataka kao dobro. Ono što također možemo učiniti, a to ću vam brzo pokazati, govorio sam o činjenici dovođenja stvari iz drugih područja. Pretpostavit ću da ću uvesti model iz baze podataka ili ga obrnuti inženjer, ali donijet ću ga iz vanjskih metapodataka. Samo da vam vrlo brzo pružim pregled svih različitih vrsta stvari koje možemo početi unositi.
Kao što vidite, imamo bezbroj stvari s kojima možemo zapravo unijeti metapodate u naše modelirajuće okruženje. Počevši od stvari poput čak Amazon Redshift, Cassandra, puno drugih platformi velikih podataka, tako da vidite puno njih na popisu. To je abecednim redom. Vidimo mnogo velikih izvora podataka i takve stvari. Također vidimo mnoštvo tradicionalnih ili starijih okruženja za modeliranje kroz koje zapravo možemo prenijeti te metapodate. Ako prođem ovdje - i neću trošiti vrijeme na svaku od njih - vidimo puno različitih stvari koje možemo donijeti od njih, u smislu modeliranja platformi i platformi podataka. I nešto što je ovdje vrlo važno shvatiti je još jedan dio koji možemo učiniti kada počnemo razgovarati o liniji podataka, u Enterprise Team Editionu također možemo ispitivati izvore ETL-a, bilo da se radi o stvarima poput Talend ili preslikavanja SQL Server Information Services, možemo li Zapravo to pokrećemo i da pokrenemo naše dijagrame loze podataka i nacrtamo sliku onoga što se događa u tim transformacijama. Sveukupno imamo više od 130 ovih različitih mostova koji su zapravo dio Enterprise Team Edition proizvoda, tako da nam stvarno pomažu da brzo izvučemo sve artefakte u jedno okruženje za modeliranje.
Konačno, ali ne najmanje bitno, također želim razgovarati o činjenici da ne možemo izgubiti iz vida činjenicu da su nam potrebne druge vrste konstrukcija ako radimo skladištenje podataka ili bilo kakvu vrstu analitike. I dalje želimo imati mogućnost raditi stvari poput dimenzionalnih modela gdje imamo tablice činjenica, a mi imamo dimenzije i takve vrste stvari. Želim vam pokazati i to da možemo imati i proširenja naših metapodataka koja nam pomažu da kategoriziramo koje su vrste dimenzija i sve ostalo. Dakle, ako ovdje pogledam karticu dimenzionalnih podataka, na primjer, na jednu od njih, zapravo će se automatski prepoznati, na osnovu uzorka modela koji se vidi, i dati početnu točku misli li da je to dimenzija ili tablica činjenica. No, osim toga, ono što možemo učiniti je unutar dimenzija i te vrste stvari, čak imamo različite vrste dimenzija koje možemo upotrijebiti za razvrstavanje podataka u okruženje skladištenja podataka. Toliko moćne mogućnosti da zajedno s ovim crtamo.
Uskočit ću u ovaj jer sam trenutno u demo okruženju i pokazat ću vam nekoliko drugih stvari prije nego što se vratim na dijapozitive. Jedna od stvari koju smo nedavno dodali ER / Studio Data Architect jest da smo naišli na situacije - i to je vrlo čest slučaj korištenja kada radite na projektima - programeri razmišljaju u smislu predmeta, dok naši podaci Modelatori skloni razmišljati u smislu tablica i entiteta i takve vrste stvari. Ovo je vrlo pojednostavljen model podataka, ali on predstavlja nekoliko osnovnih koncepata, gdje programeri ili čak poslovni analitičari ili poslovni korisnici mogu misliti o njima kao o različitim objektima ili poslovnim konceptima. Do sada ih je bilo vrlo teško klasificirati, ali ono što smo ustvari napravili u izdanju ER / Studio Enterprise Team Edition, u izdanju za 2016. godinu, imamo li sada koncept pod nazivom Poslovni podaci objekti. A ono što nam to omogućava jest da nam omogući da enkapsuliramo grupe entiteta ili tablice u istinske poslovne objekte.
Na primjer, ono što smo ovdje dobili u ovom novom prikazu je zaglavlje narudžbe i linija naloga sada su spojeni, oni su kapsulirani kao objekt, o njima bismo mislili kao o jedinici rada kad ustrajemo u podacima, i mi ih okupljamo, tako da je sada vrlo lako povezati to s različitom publikom. Ponovno se mogu koristiti u okruženju modeliranja. Oni su pravi objekt, a ne samo konstrukcija crtanja, ali imamo i dodatnu korist što kad komuniciramo zapravo iz perspektive modeliranja, možemo ih selektivno urušiti ili proširiti tako da možemo stvoriti sažet prikaz dijaloga sa određenom publikom zainteresiranih strana, i mi također možemo zadržati detaljniji prikaz kao da vidimo ovdje za više tehničke publike. Doista nam daje stvarno dobro sredstvo komunikacije. Ono što sada vidimo je kombiniranje više različitih tipova modela, dopunjavajući ih konceptom poslovnih podataka, a sada ću govoriti o tome kako doista primjenjujemo nešto više značenja na ove vrste stvari i kako ih spajamo zajedno u naše cjelokupnom okruženju.
Samo pokušavam pronaći svoj WebEx ovdje, tako da to mogu učiniti. I tu se vraćamo natrag na Hot Tech dijapozitive. Samo ću ubrzati nekoliko slajdova ovdje jer ste ih već vidjeli u demonstraciji samog modela. Želim vrlo brzo razgovarati o imenovanju standarda. Želimo primijeniti i provesti različite standarde imenovanja. Ono što želimo učiniti je da imamo mogućnost da zapravo pohranimo predloške standarda za imenovanje u naša spremišta kako bismo u osnovi izgradili to značenje, kroz riječi ili izraze ili čak kratice, i vezali ih za smislenu englesku vrstu riječi. Koristit ćemo poslovne izraze, kratice za svaki, a možemo odrediti redoslijed, slučajeve i dodati prefikse i sufikse. Tipični slučaj upotrebe za to je obično kada ljudi grade logički model, a zatim zapravo kreiraju naprijed kako bi stvorili fizički model gdje bi mogli koristiti kratice i sve ostalo.
Lijepa stvar je što je jednako moćan, još snažniji obrnuto, ako samo možemo reći koji je od tih standarda imenovanja bio na nekim fizičkim bazama podataka koje smo napravili obrnuto, možemo uzeti te kratice, pretvoriti ih u duže riječi i vratite ih unatrag u engleske izraze. Mi zapravo sada možemo izvući odgovarajuća imena prema tome kako izgledaju naši podaci. Kao što kažem, tipični slučaj upotrebe je da se krećemo naprijed, logično na fizičko i preslikavamo spremnike podataka i tu vrstu stvari. Ako pogledate sliku zaslona s desne strane, vidjet ćete da postoje skraćena imena od izvora izvora i kad smo primijenili predložak standarda za imenovanje, zapravo imamo više punih imena. A mi možemo staviti razmake i sve ostalo ako želimo, ovisno o predlošku standarda imenovanja koji smo koristili. Možemo učiniti da izgleda, ali želimo da to uključi u naše modele. Tek kada znamo kako se nešto zove, možemo mu zapravo početi pridavati definicije, jer ako ne znamo što je, kako na to možemo primijeniti značenje?
Lijepa stvar je da se zapravo možemo pozivati na to kad radimo sve vrste stvari. Govorio sam o obrnutom inženjeringu, zapravo možemo istovremeno pozivati predloške za imenovanje standarda kada radimo obrnuti inženjering. Dakle, u jednom nizu koraka kroz čarobnjaka, ono što mi možemo učiniti je da ako znamo što su konvencije, možemo obrnuti inženjer fizičke baze podataka, vratit ćemo je kao fizičke modele u okruženje za modeliranje i to je također će primjenjivati te konvencije o imenovanju. Tako ćemo vidjeti kakvi su engleski nazivi imena u odgovarajućem logičkom modelu u okruženju. To možemo i kombinirati s generacijom XML sheme kako bismo mogli uzeti model, pa čak i istisnuti ga kraticama, bilo da radimo SOA okvire ili takvu vrstu stvari, tako da možemo izbaciti i različite konvencije o imenovanju koje smo zapravo pohranili u samom modelu. Daje nam puno vrlo moćnih mogućnosti.
Opet, evo primjera kako bi izgledao da imam predložak. Ovaj zapravo pokazuje da sam u konvenciji o standardima za imenovanje imao EMP za „zaposlenog“, SAL za „plaću“, PLN za „plan“. Mogu ih primijeniti i da ih interaktivno pokreću dok izrađujem modele i stavljam stvari. Da sam koristio ovu kraticu i upisao „Plan plaće zaposlenika“ na ime entiteta, djelovao bi s predloškom standarda imenovanja. Ovdje sam definirao, dao bi mi EMP_SAL_PLN dok sam stvarao entitete i odmah mi dao odgovarajuća fizička imena.
Opet, vrlo dobro za projektiranje i razvoj inženjeringa. Imamo vrlo jedinstven koncept i to je ono gdje zaista počinjemo zbližavati ta okruženja. A zove se Universal Mappings. Nakon što smo sve ove modele uveli u naše okruženje, što smo u mogućnosti napraviti, pretpostavljajući da smo sada primijenili ove konvencije o imenovanju i lako ih je pronaći, sada možemo u ER koristiti konstrukt pod nazivom Universal Mappings /Studio. Možemo povezati subjekte preko različitih modela. Gdje god vidimo „kupca“ - vjerojatno ćemo imati „kupca“ u puno različitih sustava i puno različitih baza podataka - sve to možemo započeti povezivati tako da, kad radim s njim u jednom modelu, možete vidjeti gdje su manifestacije kupaca na ostalim modelima. A s obzirom da imamo sloj modela koji to predstavlja, možemo ga čak i povezati s izvorima podataka i svesti ga na naše upite u kojima se koriste i baze podataka. To nam stvarno daje mogućnost da sve to zajedno povežemo vrlo kohezivno.
Pokazao sam vam poslovne poslovne podatke. Želim također vrlo brzo razgovarati o proširenjima metapodataka, koja nazivamo Privitci. Ono što to čini jest daje nam mogućnost stvaranja dodatnih metapodataka za naše modele modela. Često bih postavljao ove vrste entiteta kako bi se iz perspektive upravljanja podacima i kvalitetom podataka izbacilo puno različitih stvari, a također i da bi nam pomogao u upravljanju i pravilima čuvanja podataka. Osnovna ideja je da stvorite ove klasifikacije i možete ih pričvrstiti gdje god želite, na razini tablice, stupca, te vrste stvari. Naravno, najčešći je slučaj da su entiteti tablice, a zatim mogu definirati: koji su moji matični podaci, što su moje referentne tablice, što su moje transakcijske tablice? Iz perspektive kvalitete podataka mogu činiti klasifikacije s obzirom na važnost za posao kako bismo prioritet mogli dati naporima na čišćenju podataka i takvoj vrsti stvari.
Ono što se često zanemaruje jest, kakva je politika zadržavanja različitih vrsta podataka u našoj organizaciji? To možemo postaviti i zapravo ih možemo povezati s različitim vrstama artefakata informacija u našem modeling okruženju i, naravno, i našem spremištu. Ljepota je u tome što ovi prilozi žive u našem rječniku podataka, tako da kada koristimo rječnike podataka poduzeća u okolini, možemo ih priložiti na više modela. Moramo ih definirati samo jednom i možemo ih iznova i iznova utjecati na različite modele u našem okruženju. Ovo je samo brzi snimak zaslona koji pokazuje da zapravo možete navesti kada radite privitak, koji su to komadi na koje želite priložiti prilog. A ovaj je primjer ovdje zapravo popis vrijednosti, pa kad uđu u njih, možete odabrati s popisa vrijednosti, imate veliku kontrolu u okruženju modeliranja onoga što se odabire i čak možete postaviti što je zadana vrijednost je ako vrijednost nije odabrana. Dakle, puno snage. Žive u rječniku podataka.
Želim vam pokazati malo dalje na ovom zaslonu, a osim toga vidite privitke koji se prikazuju u gornjem dijelu, ispod njega vidite informacije o sigurnosti podataka. Politike sigurnosti podataka također možemo primijeniti i na različite podatke u okruženju. Za različita mapiranja usklađenosti, sigurnosne klasifikacije podataka, nekoliko njih isporučujemo izvan okvira koje možete samo generirati i početi koristiti, ali možete definirati i vlastita mapiranja i standarde usklađenosti. Bez obzira radite li HIPAA ili neku od drugih inicijativa vani. I stvarno možete započeti s izgradnjom ovog vrlo bogatog metapodataka u vašem okruženju.
A zatim Rječnik i pojmovi - ovdje se povezuje poslovno značenje. Često imamo vani rječnika podataka koje organizacija često koristi kao polazište za početak istjerivanja pojmovnika, ali terminologija i glagol su često vrlo tehnički. Dakle, ono što možemo učiniti je da, ako želimo, koristimo ih kao polaznu točku za istjerivanje pojmovnika, ali mi zaista želimo da ih posao posjeduje. Ono što smo učinili u okruženju timskog poslužitelja dali smo ljudima mogućnost stvaranja poslovnih definicija, a zatim ih možemo povezati s različitim artefaktima modela koji im odgovaraju i u okruženju za modeliranje. Također prepoznajemo ono o čemu se ranije raspravljalo, što više ljudi tipkate, više je potencijala za ljudske pogreške. Ono što također radimo u našoj glosarskoj strukturi je: jedno, mi podržavamo hijerarhiju pojmovnika, tako da možemo imati različite vrste pojmovnika ili različite vrste stvari u organizaciji, ali što je jednako važno, ako već imate neke od ovih izvora vani, uz uvjete i sve što je definirano, zapravo možemo napraviti CSV uvoz kako bismo ih povukli u svoje modelirajuće okruženje, i naš timski poslužitelj ili naš pojmovnik, a zatim se od tamo započeli povezivati. I svaki put kad se nešto promijeni, postoji puni revizijski trag onoga što su bile slike prije i poslije, u smislu definicija i svega ostalog, a ono što ćete vidjeti u skoroj budućnosti također je više tijek rada za autorizaciju. tako da stvarno možemo kontrolirati tko je zadužen za to, odobrenja od strane odbora ili pojedinaca, i takve stvari, kako bismo proces upravljanja učinili još snažnijim u naprijed.
Ovo također čini za nas kada imamo ove pojmove u pojmu poslužitelja našeg tima, ovo je primjer uređivanja entiteta u samom modelu koji sam ovdje iznio. Možda imaju povezane izraze, ali ono što također radimo je da postoje riječi koje se nalaze u onom pojmu koji se pojavljuju u bilješkama ili opisima onoga što ovdje imamo u našim entitetima, oni se automatski prikazuju svjetlijom hipervezanom bojom i ako prelazeći mišem preko njih, stvarnu definiciju možemo vidjeti i iz poslovnog pojma. To nam daje čak i bogatije informacije kada konzumiramo same informacije, sa svim pojmovnicima pojma koji su vani. Doista pomaže obogatiti se u iskustvu i primijeniti značenje na sve što radimo.
Pa, opet, to je bio vrlo brz let. Očito bismo mogli provesti dane na tome dok smo prokopavali različite dijelove, ali ovo je vrlo brzo letjeti površinom. Ono čemu stvarno težimo je shvatiti kako izgledaju ta složena podatkovna okruženja. Želimo poboljšati vidljivost svih tih artefakata podataka i surađivati na tome da ih izbacimo iz ER / Studio. Želimo omogućiti učinkovitije i automatiziranije modeliranje podataka. I to su sve vrste podataka o kojima govorimo, bilo da se radi o velikim podacima, tradicionalnim relacijskim podacima, spremištima dokumenata ili bilo čemu drugom. I opet, to smo postigli jer imamo moćne napredne i obrnute mogućnosti inženjeringa za različite platforme i druge alate koje možda imate tamo. Sve je to u dijeljenju i komunikaciji u cijeloj organizaciji sa svim uključenim dionicima. To je ono što mi primjenjujemo značenje kroz nazive standarda. Zatim primjenjujemo definicije kroz naše poslovne pojmovnike. I tada možemo napraviti daljnje klasifikacije svih naših mogućnosti upravljanja s proširenjima metapodataka, poput proširenja kvalitete podataka, klasifikacija za upravljanje glavnim podacima ili bilo koje druge vrste klasifikacija koje želite primijeniti na te podatke. I tada možemo dodatno sažeti i još više poboljšati komunikaciju s objektima poslovnih podataka, s različitim interesnim skupinama, posebno između modelara i programera.
I opet, ono što je vrlo važno u tome je, iza svega je integrirano spremište s vrlo robusnim mogućnostima upravljanja promjenama. Nisam ga imao vremena pokazati danas jer postaje poprilično složen, ali skladište ima vrlo robusne upravljačke mogućnosti promjena i zapise revizije. Možete raditi s imenovanim izdanjima, možete raditi s imenovanim verzijama, a mi također imamo mogućnost onih koji rade na upravljanju promjenama, to možemo ispravno uklopiti u vaše zadatke. Danas imamo mogućnost stavljanja zadataka i promjena vašeg modela u zadatke, baš kao što bi programeri svoje promjene kodova povezali sa zadacima ili korisničkim pričama s kojima rade.
Ponovo je to bio vrlo brz pregled. Nadam se da je dovoljno da potaknete svoj apetit da bismo mogli voditi mnogo dublje razgovore o razdvajanju nekih od tih tema u budućnosti. Hvala vam na vašem vremenu i vraćam se vama, Rebecca.
Rebecca Jozwiak: Hvala, Rone, to je bilo fantastično i imam dosta pitanja publike, ali želim pružiti priliku našim analitičarima da potonu zube u ono što ste morali reći. Eric, idem naprijed i možda ako želiš riješiti ovaj slajd ili neki drugi, zašto prvo ne naprijed? Ili bilo koje drugo pitanje.
Eric Little: Svakako. Oprosti, što je bilo pitanje, Rebecca? Želiš li da pitam nešto konkretno ili …?
Rebecca Jozwiak: Znam da ste u početku imali neka pitanja za Rona. Ako sada želite tražiti da se obraća bilo kojem od njih ili nekom od njih s vašeg slajda ili bilo čemu drugom što je probudilo vaše zanimanje koje želite pitati? O funkcijama modeliranja IDERA-e.
Eric Little: Da, tako, jedna od stvari, Ron, pa kako vi momci, izgleda da su dijagrami koje ste prikazivali općenite dijagrame odnosa entiteta kao što biste obično koristili u izgradnji baze podataka, zar ne?
Ron Huizenga: Da, općenito govoreći, ali naravno da imamo proširene vrste skladišta dokumenata i takve vrste stvari. Zapravo smo se razlikovali od samo čiste relacijske notacije, zapravo smo dodali i nove bilješke za ostale trgovine.
Eric Little: Postoji li način na koji vi dečki možete koristiti modele zasnovane na grafovima, pa postoji li način da se integrirate, na primjer, pretpostavimo da imam nešto poput vrhunskog kvadranta, TopBraid skladateljskog alata ili sam učinio nešto u Protégéu ili, znate, poput financija u FIBO-u, oni rade puno semantike, RDF stvari - postoji li način da se u ovaj alat uvede ta vrsta modeliranja grafikona odnosa odnosa entiteta i iskoriste to?
Ron Huizenga: Mi zapravo gledamo kako možemo obraditi grafikone. Danas ne obrađujemo izričito baze podataka grafikona i tu vrstu stvari, ali tražimo načine na koje to možemo proširiti svoje metapodate. Mislim, možemo stvari unijeti kroz XML i tu vrstu stvari upravo sada, ako barem možemo napraviti neku vrstu XML predaje da bismo je doveli kao početnu točku. Ali promatramo elegantnije načine kako to uvesti.
A također sam vam pokazao i popis obrnutih inženjerskih mostova koji također imamo tamo, tako da uvijek tražimo proširenja tih mostova i za određene platforme. Ako je to ima smisla, neprestano se nastoji započeti prihvaćati mnogo novih konstrukcija i različitih platformi vani. Ali mogu reći da smo definitivno na čelu toga. Stvari koje sam prikazao, na primjer, na MongoDB-u i takvoj vrsti stvari, mi smo prvi dobavljač podataka koji modelira podatke koji to stvarno rade u vlastitom proizvodu.
Eric Little: Dobro, da. Dakle, drugo pitanje koje sam vam tada postavio bilo je u vezi s upravljanjem i održavanjem - kao kad ste koristili primjer, kad ste pokazali primjer osobe koja je "zaposlenica", vjerujem da je bila " plaću "i onda imate" plan ", postoji li način kako upravljati, na primjer, različitim vrstama ljudi koji mogu imati - pretpostavimo da imate veliku arhitekturu, zar ne, pretpostavimo da imate veliko poduzeće i ljudi počinju povlačiti stvari zajedno u ovom alatu i ovdje imate jednu grupu koja ima riječ "zaposlenik" i jednu grupu koja ima riječ "radnik". I jedna osoba ovdje kaže "plaća", a druga osoba kaže "plaća."
Kako se pomirite, upravljate i upravljate takvim razlikama? Jer znam kako bismo to napravili u svijetu grafova, upotrijebili biste sinonimne popise ili biste rekli da postoji jedan koncept i da ima nekoliko atributa, ili u SKOS modelu možete reći da imam preferiranu oznaku i imam brojne alternativne naljepnice koje mogu koristiti. Kako to radite?
Ron Huizenga: Radimo to na nekoliko različitih načina, a prije svega prije svega razgovarajmo o terminologiji. Jedna od stvari koje mi, naravno, radimo je da želimo imati definirane ili sankcionirane pojmove, a u poslovnom pojmu očito je tamo gdje ih želimo. A u poslovnom rječniku dopuštamo i poveznice na sinonime, pa ono što možete učiniti je da kažete, evo mog termina, ali možete definirati i koji su svi sinonimi za to.
Zanimljiva je stvar, naravno, kad počnete gledati ovaj ogromni krajolik podataka sa svim tim različitim sustavima koji su vani, ne možete jednostavno izaći vani i promijeniti odgovarajuće tablice i one vrste stvari u odgovaraju tom standardu imenovanja, jer to može biti paket koji ste kupili, tako da nemate kontrolu nad promjenom baze podataka ili bilo što uopće.
Ono što bismo tamo mogli učiniti, osim što možemo povezati definicije pojmovnika, jest kroz ta univerzalna preslikavanja o kojima sam govorio, što bismo radili i kakav je preporučeni pristup, imati opći logički model koji postavlja ono što ti različiti poslovni koncepti su ono o čemu govorite. Povežite pojmove poslovnog pojma u one stvari, i lijepo je što ste dobili ovaj konstrukt koji predstavlja logičan entitet kakav je, tada možete početi povezivati se iz tog logičkog entiteta sa svim implementacijama tog logičkog entiteta u različiti sustavi.
Zatim tamo gdje to trebate vidjeti, oh, "osoba" ovdje se u ovom sustavu naziva "zaposlenik". Ovdje se u ovom drugom sustavu "plaća" ovdje zove "plaća". Jer ćete to vidjeti, vidjet ćete sve različite manifestacije onih jer ste ih povezali.
Eric Little: Dobro super, da, shvatio sam. Je li u tom smislu sigurno reći da je to poput nekih objektno orijentiranih pristupa?
Ron Huizenga: Donekle. Malo je intenzivnije od toga, pretpostavljam da bi mogli reći. Mislim, mogli biste pristupiti ručnom povezivanju i prolasku kroz njih i pregledati i raditi sve njih. Jedna stvar o kojoj zapravo nisam imao prilike razgovarati - jer opet, imamo puno mogućnosti - također imamo potpuno sučelje za automatizaciju u samom alatu Data Architect. I makronaredba, koja je doista programski jezik u alatu. Na taj način mi zapravo možemo raditi stvari poput pisanja makronaredbi, pustiti ih van i ispitivati te stvarati veze za vas. Koristimo ga za uvoz i izvoz informacija, možemo ga koristiti za promjenu stvari ili dodavanje atributa, događaja zasnovanih na samom modelu, ili ga možemo koristiti za pokretanje u skupinama kako bismo zapravo izlazili i ispitivali stvari, a zapravo napunili različite konstrukcije u model. Dakle, postoji potpuno sučelje za automatizaciju koje ljudi mogu također iskoristiti. A korištenje univerzalnih mapiranja s njima bio bi vrlo moćan način da se to postigne.
Rebecca Jozwiak: U redu, hvala Ron i hvala Ericu. To su bila sjajna pitanja. Znam da malo trčimo prema vrhuncu sata, ali želio bih pružiti Malcolmu priliku da izbaci nekoliko pitanja o Ronovom putu. Malcolm?
Malcolm Chisholm: Hvala, Rebecca. Dakle, Ron, vrlo je zanimljivo, vidim da ovdje ima puno mogućnosti. Jedno od područja koje me jako zanima jest, recimo, ako imamo razvojni projekt, kako vidite modele podataka kako koristi ove mogućnosti i radite možda više u suradnji s poslovnim analitičarima, s procesorom podataka, s analitičarom za kvalitetu podataka i sa poslovnim sponzorima koji će u konačnici biti odgovorni za stvarne potrebe za informacijama u projektu. Znate kako modelar podataka stvarno, znate, čini projekt učinkovitijim i učinkovitijim sa mogućnostima koje gledamo?
Ron Huizenga: Mislim da je jedna od prvih stvari koju morate učiniti tamo kao moderator podataka - i ne mislim odabrati neke od modelara, ali svejedno ću - neki ljudi još uvijek imaju dojam da data modeler je zaista vrsta uloge, definiramo kako to funkcionira, mi smo čuvari koji osiguravaju da je sve ispravno.
Sada postoji aspekt toga, da morate biti sigurni da definirate arhitekturu zvučnih podataka i sve ostalo. Ali važnija stvar je kao model modelar podataka - i to sam sasvim očito otkrio kad sam se savjetovala - da li morate postati moderator, pa te ljude morate povezivati.
To više neće biti dizajn, generirati, graditi baze podataka - ono što trebate biti u mogućnosti je da budete u mogućnosti raditi sa svim tim različitim interesnim skupinama, radeći stvari poput obrnutog inženjeringa, uvoza podataka u drugi ljudi surađuju, bilo da se radi o pojmovnicima ili dokumentaciji, i sve slično tome - i budite moderator koji će to povući u skladište i povezati koncepte u spremištu i raditi s tim ljudima.
To je zapravo mnogo više kolaborativnog tipa okruženja u kojem ljudi, kroz definiranje zadataka ili čak teme za raspravu ili one vrste stvari koje imamo u timskom poslužitelju, zapravo mogu surađivati, postavljati pitanja i dolaziti do krajnjih krajnjih proizvoda koje oni potreba za njihovom arhitekturom podataka i njihovom organizacijom. Je li takav odgovor?
Malcolm Chisholm: Da, slažem se. Znate, mislim da je vještina olakšavanja nešto što je zaista poželjno kod modelara podataka. Slažem se da to ne vidimo uvijek, ali mislim da je to potrebno i predlažem da ponekad postoji želja da ostanete u svom kutu radeći svoje modeliranje podataka, ali zaista morate biti vani radeći s drugim skupinama dionika ili jednostavno ne razumijete podatkovno okruženje s kojim se bavite i mislim da model pati kao rezultat toga. Ali to je samo moje mišljenje.
Ron Huizenga: I zanimljivo je to što ste ranije spomenuli nešto o povijesti o tome kako se tvrtke nekako odvrate od IT-a jer rješenja nisu isporučivale pravodobno i takve vrste stvari.
Vrlo je zanimljivo da su u kasnijim konzultantskim angažmanima, prije nego što sam postao voditelj proizvoda, većina projekata koja sam radila u posljednje dvije godine prije toga bila sponzorirana, gdje je stvarno bio taj posao koji je pokretao njega i arhitekti podataka a modeliri nisu bili dio IT-a. Bili smo dio poslovne sponzorirane grupe i bili smo tamo kao facilitatori koji su radili s ostalim projektnim timovima.
Malcolm Chisholm: Mislim da je to vrlo zanimljiva stvar. Mislim da počinjemo doživljavati pomak u poslovnom svijetu u kojem se posao pita ili možda razmišljam, ne toliko kao što radim, kao što je proces, ali oni također počinju razmišljati o tome koji su podaci s kojima radim, koje su moje potrebe za podacima, koji su podaci kojima se bavim kao podaci i u kojoj mjeri možemo dobiti IDERA proizvode i mogućnosti za podršku tom gledištu, i mislim da potrebe poslovanja, čak iako je nekako još uvijek pomalo narastao.
Ron Huizenga: Slažem se s tobom i mislim da to sve više viđamo tim putem. Vidjeli smo buđenje i dotakli ste ga ranije u smislu važnosti podataka. Vidjeli smo važnost podataka rano u IT-u ili u evoluciji baza podataka, tada smo, kako kažete, nekako ušli u cijeli ovaj ciklus upravljanja procesima - a proces je izuzetno važan, nemojte me krivo shvatiti - ali sada se ono što se dogodilo Kad se to dogodilo, podaci su izgubljeni fokus.
I sada organizacije shvaćaju da su podaci doista žarište. Podaci predstavljaju sve što radimo u našem poslu, tako da moramo biti sigurni da imamo točne podatke, da možemo pronaći točne podatke koje su nam potrebne za donošenje naših odluka. Jer sve ne proizlazi iz definiranog procesa. Neke su informacije nusproizvod drugih stvari, a još uvijek ih moramo biti u stanju pronaći, znati što znači i biti u stanju prevesti podatke koje vidimo tamo u konačnici u znanje koje možemo koristiti za bolje poslovanje.
Malcolm Chisholm: U redu, a sada se borim s još jednim područjem koje bih nazvao životnim ciklusom podataka, a to je, znate, ako pogledamo vrstu lanca dobave podataka koji prolazi kroz neko poduzeće, počeli bismo s prikupljanje podataka ili prikupljanje podataka, što može biti unos podataka, ali jednako tako može biti, dobivam podatke izvan poduzeća od nekog dobavljača podataka.
A onda iz prikupljanja podataka prijeđemo na održavanje podataka gdje razmišljam o standardizaciji tih podataka i isporučivanju na mjesta gdje su potrebni. A zatim upotrebom podataka, stvarnim točkama gdje su podaci, dobit ćete vrijednost iz podataka.
U stara vremena sve se to radi u jednom individualnom stilu, ali danas bi to moglo biti, znate, analitičko okruženje, na primjer, a potom izvan toga, arhiva, trgovina, u koju unosimo podatke kada više ne treba i konačno postupak čišćenja. Kako vidite da se modeliranje podataka uklapa u upravljanje cjelokupnim životnim ciklusom podataka?
Ron Huizenga: To je vrlo dobro pitanje i jedno o čemu zapravo danas nisam imao vremena detaljno raspravljati o tome je ono o čemu zapravo počinjemo razgovarati o podrijetlu podataka. Dakle, ono što mi u stvari možemo učiniti jest da u našim alatima imamo sposobnost generiranja podataka i, kao što rekoh, mi nešto zapravo možemo izdvojiti iz ETL alata, ali možete ga i preslikati samo crtanjem crte. Bilo koji od ovih modela podataka ili baze podataka koje smo snimili i uveli u modele, mogli bismo referencirati konstrukte iz toga u našem dijagramu loze podataka.
Ono što možemo učiniti jest nacrtati protok podataka, kao što kažete, od izvora do cilja, a kroz cjelokupni životni ciklus kako ti podaci prolaze kroz različite sustave i što ćete pronaći je da uzmemo zaposlenike 'podaci - jedan je od mojih favorita temeljen na projektu koji sam radio prije godina. Radio sam s organizacijom koja je imala podatke o zaposlenicima u 30 različitih sustava. Ono što smo tamo napravili - a Rebecca je otvorila dijapozitiv linija podataka - ovo je ovdje prilično pojednostavljen slajd podataka, ali ono što smo uspjeli učiniti je unijeti u sve strukture podataka, navesti ih u dijagramu, a zatim zapravo mogu započeti sagledati koji su tokovi između i kako su ti različiti entiteti podataka povezani u toku? A možemo i preko toga. To je dio dijagrama toka podataka ili linijskog dijagrama koji vidimo ovdje. Ako želite ići dalje od toga, mi također imamo poslovnog arhitekta, dio ovog apartmana i tamo vrijedi ista stvar.
Bilo koja struktura podataka koju smo zabilježili u okruženju za modeliranje podataka može se navesti u alatu za poslovno modeliranje, tako da čak i u dijagramima vašeg poslovnog modela ili dijagramima poslovnih procesa možete uputiti na pojedinačne prodavaonice podataka ako želite izaći iz okruženju za modeliranje podataka i dok ih upotrebljavate u mapama vašeg modela poslovnog procesa možete čak odrediti i CRUD na njima kako se te informacije troše ili proizvode, a tada možemo početi generirati stvari poput izvještaja o utjecaju i analize i dijagrama iz toga.
Ono čemu namjeravamo pristupiti, a već imamo puno mogućnosti, ali jedna je od stvari koju imamo kao vrsta strijele koja gledamo, dok nastavljamo s razvojem alata kako ide naprijed, je u mogućnosti preslikati tu krajnju organizacijsku liniju podataka i cijeli životni ciklus podataka.
Malcolm Chisholm: Dobro. Rebecca, smijem li dobiti još jednog?
Rebecca Jozwiak: Dopustit ću vam još jedan, Malcolme, samo naprijed.
Malcolm Chisholm: Puno hvala. Razmišljajući o upravljanju podacima i razmišljajući o modeliranju podataka, kako naterati te dvije skupine da zajedno učinkovito rade i razumiju se?
Eric Little: Pa to je zanimljivo, mislim da doista ovisi o organizaciji, i to se vraća na moj raniji koncept, u onim organizacijama gdje su inicijative pokrenute poslovanjem bili smo vezani. Na primjer, vodio sam arhitekturu podataka tim, ali bili smo povezani s poslovnim korisnicima i zapravo smo im pomogli da ustanu s programom upravljanja podacima. Opet, više konzultativnog pristupa, ali zapravo više od poslovne funkcije.
Ono što stvarno trebate biti u mogućnosti da to učinite jeste da su vam potrebni modelirači podataka i arhitekti koji stvarno razumiju poslovanje, mogu se odnositi na poslovne korisnike i tada su im pomogli da održe procese upravljanja oko njega. Posao to želi učiniti, ali općenito govoreći, imamo tehnološka znanja kako bismo im pomogli da se istaknu te vrste programa. To stvarno mora biti suradnja, ali treba biti u vlasništvu tvrtke.
Malcolm Chisholm: U redu, to je sjajno. Hvala vam.
Dr. Eric Little: U redu.
Rebecca Jozwiak: U redu, hvala puno. Članovi publike, bojim se da nismo stigli do vaših pitanja, ali pobrinut ću se da ih prosljede odgovarajućem gostu s kojim smo danas bili na liniji. Želim vam puno zahvaliti Ericu, Malcolmu i Ronu što su nam danas bili gosti. Ovo su bile sjajne stvari. A ako ste uživali u današnjem IDERA webcastu, IDERA će također iduću srijedu biti na Hot Technologiesu ako se želite pridružiti, raspravljajući o izazovima indeksiranja i Oraclesa, pa još jedna fascinantna tema.
Puno vam hvala, narode, pazite, i vidimo se sljedeći put. Doviđenja.
