Oduzeti: Domaćin Rebecca Jozwiak razgovara o rješenjima za arhitekturu podataka s Ericom Littleom iz OSTHUS-a, Malcolmom Chisholmom iz tvrtke First San Francisco Partners i Ronom Huizengom iz tvrtke IDERA.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Rebecca Jozwiak: Dame i gospodo, zdravo i 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šnje emitiranje interneta. Tweetiramo s hashtagom # HotTech16, pa ako ste već uključeni, slobodno se pridružite i tome. Ako imate pitanja u bilo kojem trenutku, molimo pošaljite ih u okno Pitanja u donjem desnom kutu zaslona i mi ćemo se potruditi da 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 stvarno pun paket rješenja za upravljanje podacima i modeliranjem. 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: Ok, hvala puno. Proći ću kroz nekoliko tema za koje mislim da će se malo odnositi na Ronove razgovore i nadam se da ću 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. I 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 samo 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 stvarno ima veze sa trećim stupcem, raznolikošću podataka.
Drugim riječima, danas većina tvrtki gleda strukturirane, polustrukturirane i nestrukturirane podatke. Podaci o slici počinju postajati vruća tema, tako da možete koristiti računalni vid, gledati piksele, moći strugati, NLP, vađenje entiteta, imate grafičke podatke koji izlaze ili iz statističkih modela ili izlaze iz semantičkih modela , imate relacijske podatke koji postoje u tablicama i tako dalje. Tako da združivanje svih tih podataka i svih ovih različitih vrsta zaista predstavlja veliki izazov i to ćete vidjeti, znate, kod Gartnera i drugih ljudi 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 tamo i znate? Mogućnost korištenja statistika i mogućnost korištenja nekih vrsta informacija oko onoga što možda znate ili korištenje nekih uvjeta može 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, da li uzimam sve svoje relacijske podatke i stavim 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. Ako ćete imati ovakve modele podataka, ako ćete moći udružiti i pretraživati 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 će grupa 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 tu vrstu informacija? Budući da im ne želite dati samo jedan 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 jedan od ključeva ovdje razmišljanje o tome kako koristiti možda modele odnosa entiteta, kako koristiti možda grafičke modele ili neki takav pristup koji će vam stvarno naditi standardni način raspoređivanja raspoređenih u referentne podatke. 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 povezivanja tih personaliziranih terminologija, jer drugi je pristup: ljude morate prisiliti da odustanu od termina i da koriste tuđe načine, koje često ne vole. Drugi je poanta kod rukovanja velikim brojem sinonima teško, tako da postoji mnogo različitih riječi u podacima mnogih ljudi 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 upravljati referentnim podacima skupo. Skupo je stalno držati ručno preslikavanje, a skupo je tako da stručnjaci za teme prestanu 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. Ako, primjerice, radite na sirovoj nafti, postojat će određene vrste vokabulara koje možete posuditi iz prostora otvorenog koda, isti 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, zanima me kako oni to rješavaju u pogledu upotrebe vrsta standarda. U svijetu semantike često vidite stvari poput SKOS modela koji pružaju standarde barem šire od / uže od odnosa, a te stvari mogu biti teške u ER modelima, ali, znate, nije nemoguće, ovisi samo o tome koliko toga strojevima i vezama kojima možete upravljati u tim vrstama sustava.
I na kraju, samo sam želio 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.Može li se 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 tom 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. Tako ćete dobiti pravopisne pogreške, dobiti greške 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 radi o praktičnim primjenama, previše ruku u teglici s kolačićima obično vas ostavlja s puno slomljenih kolačića, zar ne?
Eric Little: Da, i mikrobe.
Rebecca Jozwiak: Da. S tim idem dalje i proslijedit ću ga Malcolmu Chisholmu. Malcolm, pod je tvoj.
Malcolm Chisholm: Puno ti 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 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 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,, bio bi dio toga, ali biste mogli tvrditi i 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, već je zaista središnji dio naših poslovnih modela? 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 radimo testiranje u fazi testiranja obično bude, funkcionira li moja funkcionalnost, recimo moj ETL, ali mi ne testiramo podatke. Ne testiramo svoje pretpostavke o ulaznim podacima koji dolaze. Da smo to učinili, bili bismo u možda boljoj formi i kao neko ko je radio projekte skladišta podataka i pretrpio promjene koje su uslijedile od nje, procijenio 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 na procesu, ali ne razmišljamo u podatkovnom smislu kad trebamo i na okolnosti 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 je struktura podataka i sami podaci tamo stigli putem IT-a i operacija, tako da bismo to trebali znati, ali stvarno, nemamo. 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. A 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, pretpostavljam, prilično blizu toga. 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 niže ikakve 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 opet to odjekuje ono što je Eric govorio - imamo podatkovni model koji za našu bazu podataka definira plavu podatkovnu priču, ali istodobno su nam potrebni oni konceptualni modeli, oni poslovni ukazi 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 došli u redove kao data modeler, kao što sam i ja, i opet, nešto novo.
I na kraju, želim reći da i veća arhitektura mora odražavati tu novu stvarnost. Na primjer, tradicionalni MDM za kupce je vrsta, u redu, ubacimo naše podatke o klijentima u sastajalište gdje ga mi, znate, možemo shvatiti 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 poslovni je 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. Stvarno smo u novoj eri i mislim da na brojne razine moramo odgovoriti arhitekturi podataka poslovnih vođenja i mislim da je izuzetno uzbudljivo vrijeme za to.
Pa hvala, vraćam se tebi Rebecca.
Rebecca Jozwiak: Hvala Malcolm, i stvarno sam uživao u onome što ste rekli o podatkovnim modelima mora hraniti poslovni pogled, jer, za razliku od onoga što ste govorili, gdje je IT tako dugo držao uzde i jednostavno to više nije tako i kultura treba se pomaknuti. Prilično sam siguran da je u pozadini postojao pas koji se 100% s vama složio. A s tim ću loptu proslijediti Ronu. Jako sam uzbuđena što vidim vaš demo. Ron, kat je tvoj.
Ron Huizenga: Hvala vam puno i prije nego što uskoč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, a s onim što mi danas govorimo o samo površini jer je toliko aspekata i toliko stvari koje stvarno trebamo razmotriti i pogledati iz poslovne arhitekture. 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 servisno orijentiranoj arhitekturi ili drugim stvarima, model zaista postaje bit ž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 takvu 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 kao što su relacijski modeli 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 izdanju ER / Studio Enterprise Team. Prvenstveno ću govoriti o proizvodu arhitekture podataka gdje radimo modeliranje podataka i takvu vrstu stvari, ali postoji mnoštvo drugih komponenti paketa koje ću se 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 stvarne podatke 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 takvih vrsta stvari, da pružimo 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 skladišta i tima i o tome ću govoriti kao o dvije polovice iste stvari. Repozitorij je mjesto gdje pohranjujemo sve modelirane metapodate kao i sve poslovne metapodatke 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 to je način na koji stvarno počinjemo pokretati suradnju.
I posljednji dio o kojem ću ukratko govoriti jest da, kada hodate u tim sredinama, tamo nisu samo baze podataka. Imat ćete niz baza podataka, spremišta podataka, imat ćete i mnogo, kako bih rekao, naslijeđenih artefakata. Možda su ljudi koristili Visio ili druge dijagrame za mapiranje nekih stvari. Možda su imali druge alate za modeliranje i takvu vrstu 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 o kojem je Malcolm govorio. Nevjerojatno je kako će posljednjih godina organizacije vršiti projekte, zamijenit će sustav ili rješenje, ali često nije preostalo dovoljno budžeta projekta za dekomponiranje zastarjelih rješenja, pa su sada na putu. I moramo shvatiti što se zapravo možemo riješiti u našem okruženju i što je korisno ići 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. Moramo to moći racionalizirati i shvatiti onu liniju podataka o kojoj sam ukratko već spomenuo kako bismo mogli imati kohezivniju strategiju poput korištenja servisno orijentirane arhitekture, korporativnih servisnih autobusa i sličnih vrsta kako bismo pružili ispravne informacije na tip modela za objavljivanje i pretplatu koji ispravno koristimo u svom poslu. A onda, naravno, još uvijek moramo napraviti neku vrstu analitike, bilo da koristimo skladišta podataka, marku podataka s tradicionalnim ETL-om ili koristimo neke od novih podataka. Sve se svodi na istu stvar. Sve su to podaci, bilo da su u pitanju veliki podaci, bilo da se radi o tradicionalnim podacima u relacijskim bazama podataka, sve te podatke moramo objediniti kako bismo ih mogli upravljati i znati č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, vi ulazite unutra i možda nemate one detalje kako taj informacijski krajolik izgleda. 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 o tome ovdje govorim na 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 na tom mjestu možemo dalje klasificirati svoje podatke s nečim što se naziva Prilozi, a ja ću vam pokazati nekoliko slajdova. 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. Gotovo ću brzo razgovarati o obrnutom inženjeringu. Već sam vam ustupio vrlo brzo to. 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 mnogim slučajevima; 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 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, ono je o čemu ćemo razgovarati u nastavku.
Ovdje ću se prebaciti na modeliranje kako 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 o poslovnoj dekompoziciji, 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.
Također želim naglasiti da je vrlo važno početi prikupljati ove podatke 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 cjeline sa stupovima i metapodacima i takvom vrstom 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.
Dakle, recimo da smo i mi dobili košnicu u svom okruženju. Ako inženjera obrnemo iz okruženja košnice - a možemo pomjeriti i obrnuti inženjera iz Hive s istim istim alatom za modeliranje - vidjet ćemo nešto malo drugačije. Sve podatke i dalje vidimo kao konstrukcije, ali TDL je drugačiji. Oni od vas koji su navikli gledati SQL, ono što biste sada vidjeli je Hive QL, koji je vrlo sličan SQL-u, ali izvan istog alata koji 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 inženjer sve to u njemu i smisliti ga te početi zajedno to zajedno ,
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 njoj postoje konstrukcije koje ne odgovaraju relacijskim modelima. Ubrzo se počinjete baviti pojmovima poput ugrađenih objekata i ugrađenih nizova objekata kad počnete ispitivati JSON, a 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ški, 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 u izdavaču ako slijedimo taj odnos imamo ugrađeni objekt adrese. Ispitivanjem JSON-a otkrili smo da je potpuno ista struktura objekata ugrađena u zaštitnika, ali zapravo je ugrađena u niz predmeta. To vidimo ne samo preko samih priključaka, ali ako pogledate stvarne entitete, vidjet ćete da ispod zaštitnika vidite adrese koje su također klasificirane 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 mi također možemo učiniti, i 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 unijeti ć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 svaki 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 nam trebaju 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. Tako snažne mogućnosti da zajedno s tim crtamo.
Uskočit ću u ovaj budući da sam trenutno u demo okruženju i pokazati vam nekoliko drugih stvari prije nego što se vratim na tobogane. 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, je 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 mogu to učiniti. I tu se vraćamo natrag na Hot Tech dijapozitive. Samo ću ubrzati nekoliko slajdova ovdje jer ste ih već vidjeli na 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 snimku zaslona s desne strane, vidjet ćete da postoje skraćena imena od imena 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 se možemo istovremeno pozivati na predloške predložaka 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 tako da ih interaktivno prikazuju 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 ono kad također dizajniramo i razvijamo inženjering. Imamo vrlo jedinstven koncept i to je ono gdje zaista počinjemo zbližavati ta okruženja.I to se zove Univerzalno preslikavanje. 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 u kojima se baze podataka nalaze. To nam stvarno daje mogućnost da sve to zajedno povežemo vrlo kohezivno.
Pokazao sam vam predmete poslovnih podataka. Ž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 glavnim podacima 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 da je najčešći slučaj da su entiteti tablice i tada 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 kad koristimo rječnike poslovnih podataka u okruženju, možemo ih povezati 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. Bilo da radite 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 daje nam mogućnost da ljudi stvaraju poslovne definicije, 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 započeli povezivanje od tamo. 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.
Što ovo također čini za nas je kada imamo te 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 pruža čak i bogatije informacije kada konzumiramo same podatke, sa svim onim što su pojmi pojmovnika. Zaista pomaže obogatiti iskustvo 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 da razumijemo 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 su u pitanju veliki podaci, tradicionalni relacijski podaci, spremanje dokumenata ili nešto treće. 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. I sve je u dijeljenju i komunikaciji u cijeloj organizaciji sa svim dionicima koji su uključeni. Tu primjenjujemo značenje kroz standarde imenovanja. 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 u vezi s tim vrlo važno, 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 također rade.
Ponovo je to bio vrlo brz pregled. Nadam se da je bilo 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 zubima u ono što ste morali reći. Eric, idem dalje i možda ako se želiš pozabaviti ovim slajdom ili drugim, zašto ne bi prvo naprijed? Ili bilo koje drugo pitanje.
Eric Little: Naravno. 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 poput onih koje 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 varirali od čisto čiste relacijske oznake, zapravo smo dodali i nove bilješke za ostale trgovine.
Eric Little: Postoji li način na koji vi možete koristiti vrste modeliranja zasnovanih na grafovima, pa postoji li način da se integrira, 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 financijskih dečki u FIBO-u, oni rade puno posla u semantičkim, RDF stvarima - postoji li način da u ovaj alat uvedete taj model modeliranja tipa grafa odnosa entiteta i iskoristite ga?
Ron Huizenga: Zapravo gledamo kako možemo obraditi grafikone. Mi danas ne bavimo se izričito bazama podataka s grafikonima i takvom vrstom stvari, ali tražimo načine na koje to možemo učiniti kako bismo proširili 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 gledamo elegantnije načine kako to uvesti.
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. Stalno je uporni napor, ako to ima smisla, započeti prihvaćati puno tih novih konstrukcija i različitih platformi vani. Ali mogu reći da nam je to definitivno na čelu. Stvari koje sam prikazao, na primjer, na MongoDB-u i takvoj vrsti stvari, mi smo prvi dobavljač koji modelira podatke koji to stvarno radi u vlastitom proizvodu.
Eric Little: Ok, 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: To radimo na nekoliko različitih načina, a prije svega prvo razmotrimo terminologiju. 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, tako da ono što možete učiniti je da kažete, evo mog termina, ali također možete definirati 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: Ok super, da, shvatio sam. Je li u tom smislu sigurno reći da je to poput nekih objektno orijentiranih pristupa?
Ron Huizenga: Nešto. To je malo intenzivnije nego, pretpostavljam, mogli biste 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: Ok, hvala Ron, i hvala Ericu. To su bila sjajna pitanja. Znam da trčimo malo iza vrha sata, ali želim pružiti Malcolmu priliku da baci Rona na neka pitanja. 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 li kako modelar podataka stvarno č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 birati neke od modelara, ali svejedno ću - neki ljudi još uvijek imaju dojam da moderator podataka doista je takva vrsta uloge, određujemo kako to funkcionira, mi smo čuvari koji osiguravaju da je sve ispravno.
Sada postoji aspekt toga, da morate biti sigurni da definirate kvalitetnu arhitekturu 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 facilitator, pa te ljude morate okupiti.
To više neće biti dizajn, generirati, graditi baze podataka - ono što trebate biti u mogućnosti je da morate raditi sa svim tim različitim interesnim skupinama, raditi stvari poput obrnutog inženjeringa, unositi informacije u, imati 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 čak i kroz definiranje zadataka ili čak niti za raspravu ili onu vrstu stvari koju 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 vrlo poželjno kod dizajnera 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: A zanimljivo je jer ste ranije u svojem dijapozitivu spomenuli nešto o tome kako se tvrtke nekako odvrate od IT-a jer rješenja nisu pravovremeno isporučivale 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 upravljao tim i arhitekti podataka a modeliri nisu bili dio IT-a. Bili smo dio poslovne sponzorirane skupine 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 vama i mislim da to vidimo sve više i dalje 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 svom poslu, tako da moramo biti sigurni da imamo točne podatke, da možemo pronaći točne podatke 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 je drugo područje s kojim se borim bilo ono što 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 prikupljanjem podataka ili snimanje 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 od prikupljanja podataka prijeđemo na održavanje podataka gdje razmišljam o standardizaciji tih podataka i isporučivanju ih na mjesta gdje su potrebni. A zatim koristite podatke, stvarne točke gdje su podaci, imat ć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 jako dobro pitanje, a jedno o čemu zapravo danas nisam imao vremena detaljnije raspravljati 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: U redu. Rebecca, smijem li dobiti još jednog?
Rebecca Jozwiak: Dozvolit ću ti još jedan, Malcolme, samo naprijed.
Malcolm Chisholm: Puno ti 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, zanimljivo je, mislim da doista ovisi o organizaciji, i to se vraća na moj raniji koncept, u onim organizacijama gdje su inicijative pokrenute u poslovanju bili smo vezani. Na primjer, vodio sam tim za arhitekturu podataka, ali mi bili povezani upravo s poslovnim korisnicima i zapravo smo im pomagali da ustanove svoj program upravljanja podacima. Opet više konzultativni pristup, ali zaista je više poslovna funkcija.
Ono što stvarno trebate biti u mogućnosti da to učinite je da su vam potrebni modelirači podataka i arhitekti koji stvarno razumiju poslovanje, mogu se povezati s poslovnim korisnicima 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: Ok, to je sjajno. Hvala vam.
Dr. Eric Little: U redu.
Rebecca Jozwiak: Ok, 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 vezi. Ž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 biti iduća srijeda na Hot Technologies 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.