Od zamestnancov Techopedia, 28. septembra 2016
Jedlo s sebou: Hostiteľka Rebecca Jozwiak diskutuje o riešeniach architektúry údajov s Ericom Littleom z OSTHUSU, Malcolmom Chisholmom z prvých partnerov v San Franciscu a Ronom Huizengom z spoločnosti IDERA.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Rebecca Jozwiak: Dámy a páni, ahoj, vitajte v Hot Technologies roku 2016. Dnes diskutujeme o „budovaní podnikovej dátovej architektúry založenej na podnikaní“, určite horúcou témou. Moje meno je Rebecca Jozwiak, budem vaším hostiteľom pre dnešné webové vysielanie. Robíme pípanie s hashtagom # HotTech16, takže ak ste už na Twitteri, neváhajte sa tiež pripojiť. Ak máte akékoľvek otázky, pošlite ich do tabla otázok a odpovedí v pravom dolnom rohu obrazovky a my sa ubezpečíme, že na ne dostanú odpoveď. Ak nie, zaistíme, aby ich naši hostia dostali za vás.
Takže dnes máme skutočne fascinujúcu zostavu. Dnes s nami veľa ťažkých hitárov. Máme Eric Little, viceprezident pre dátovú vedu z OSTHUSU. Máme prvého zodpovedného manažéra v oblasti inovácií Malcolma Chisholma pre First San Francisco Partners. A máme Ron Huizengu, produktového manažéra spoločnosti IDERA. A viete, IDERA má skutočne kompletnú sadu riešení na správu a modelovanie dát. A dnes nám dá ukážku o tom, ako jeho riešenie funguje. Ale skôr, ako sa dostaneme k tomu, Eric Little, idem ti dať loptu.
Eric Little: Dobre, ďakujem veľmi pekne. Takže tu prejdem niekoľko tém, o ktorých si myslím, že sa budú trochu týkať Ronovho rozhovoru, a dúfajme, že pripravia pôdu pre niektoré z týchto tém, niektoré otázky a odpovede.
Takže to, čo ma zaujímalo o to, čo robí spoločnosť IDERA, je, že si myslím, že správne poukazujú na to, že zložité prostredie v súčasnosti skutočne poháňa veľa obchodných hodnôt. A pod zložitým prostredím máme na mysli zložité dátové prostredie. A technológia sa skutočne pohybuje rýchlo a je ťažké udržať krok v dnešnom obchodnom prostredí. Tí ľudia, ktorí pracujú v technologických priestoroch, tak často uvidia, že máte zákazníkov, ktorí majú problémy s riešením: „Ako môžem používať veľké údaje? Ako zahrnem sémantiku? Ako prepojím niektoré z týchto nových vecí so svojimi staršími údajmi? “Atď. A tento druh nás v súčasnosti vedie k týmto štyrom veľkým údajom, s ktorými sú mnohí ľudia veľmi dobre oboznámení, a chápem, že môžu existovať viac ako štyri niekedy - videl som až osem alebo deväť - ale zvyčajne, keď ľudia hovoria o veciach, ako sú veľké dáta alebo ak hovoríte o veľkých údajoch, zvyčajne sa pozeráte na niečo, čo je v podnikovom meradle. A tak ľudia povedia, dobre, dobre, zamyslite sa nad objemom vašich údajov, na ktoré sa zvyčajne zameriavajú - to je presne to, koľko máte. Rýchlosť údajov súvisí buď s tým, ako rýchlo ich dokážem pohybovať, alebo ako rýchlo ich môžem vyhľadávať alebo získať odpovede, atď. A osobne si myslím, že ľavá strana je niečo, čo sa rieši a rieši pomerne rýchlo pomocou rôznych prístupov. Ale na pravej strane vidím veľa možností na zlepšenie a veľa nových technológií, ktoré sa skutočne dostávajú do popredia. A to skutočne súvisí s tretím stĺpcom, s rozmanitosťou údajov.
Inými slovami, väčšina spoločností sa v súčasnosti pozerá na štruktúrované, pološtrukturované a neštruktúrované údaje. Obrazové údaje sa začínajú stávať horúcou témou, takže je možné používať počítačové videnie, pozerať sa na pixely, byť schopný zoškrabať text, NLP, extrakciu entít, máte grafické informácie, ktoré vychádzajú buď zo štatistických modelov, alebo vychádzajú zo sémantických modely, máte relačné údaje, ktoré existujú v tabuľkách atď. A tak spojenie všetkých týchto údajov dohromady a všetkých týchto rôznych typov predstavuje skutočne veľkú výzvu, a to uvidíte, viete, v spoločnosti Gartner a ďalších ľuďoch, ktorí sledujú trendy v tomto odvetví.
A potom poslednou vecou, o ktorej ľudia hovoria vo veľkých údajoch, je často táto predstava o voracity, čo je skutočne neistota vašich údajov, jej múdrosť. Ako dobre viete, o čom vaše údaje sú, ako dobre rozumiete tomu, čo je tam, a viete? Dôležitá môže byť schopnosť používať štatistiku a schopnosť používať určitý druh informácií v okolí toho, čo by ste mohli vedieť alebo použiť nejaký kontext. A tak schopnosť nahliadnuť do údajov týmto spôsobom, pokiaľ ide o to, koľko máte, ako rýchlo ich musíte pohnúť alebo sa k nim dostať, všetky typy údajov, ktoré môžete mať vo svojom podniku, a aké ste si istí tým, kde ste je to, čo to je, v akej kvalite je a tak ďalej. To si v súčasnosti vyžaduje veľké a koordinované úsilie medzi mnohými jednotlivcami, aby mohli efektívne spravovať svoje údaje. Modelové údaje sú preto v dnešnom svete čoraz dôležitejšie. Dobré dátové modely teda v podnikových aplikáciách skutočne vedú k veľkému úspechu.
Ako sme povedali, máte zdroje údajov z rôznych zdrojov, čo si skutočne vyžaduje veľa rôznych druhov integrácie. Takže ich ťahanie dokopy je skutočne užitočné na to, aby bolo možné spúšťať dotazy, napríklad v mnohých typoch zdrojov údajov, a sťahovať informácie späť. Aby ste to však mohli urobiť, musíte mať dobré mapovacie stratégie, a preto môže byť mapovanie týchto druhov údajov a držanie sa týchto mapovaní skutočnou výzvou. A potom máte tento problém. Ako môžem prepojiť svoje staré údaje so všetkými týmito novými zdrojmi údajov? Predpokladajme teda, že mám graf, zoberiem všetky svoje relačné údaje a vložím ich do grafu? Zvyčajne to nie je dobrý nápad. Ako je teda možné, že ľudia sú schopní riadiť všetky tieto druhy dátových modelov, ktoré sa dejú? Analýza sa musí skutočne vykonať na mnohých týchto rôznych druhoch zdrojov údajov a kombináciách. Odpovede, ktoré z toho vychádzajú, odpovede, ktoré ľudia potrebujú, aby skutočne robili dobré obchodné rozhodnutia, sú preto kritické.
Nejde teda iba o budovanie technológie kvôli technológii, ale o to, čo skutočne urobím, čo s tým môžem urobiť, aký druh analýzy môžem spustiť, a teda o schopnosť, ako som už povedal, hovorili o tom, spojiť tieto veci dokopy, integrovať je naozaj, naozaj dôležité. A jeden z týchto typov analýz potom beží na veciach, ako je federované vyhľadávanie a dotaz. To sa skutočne stáva nevyhnutnosťou. Vaše otázky musia byť zvyčajne spracované na viacerých zdrojoch a spoľahlivo získavať informácie.
Jedným z kľúčových prvkov, ktoré sa často, najmä ľudia, budú pozerať na kľúčové veci, ako sú sémantické technológie - a dúfam, že Ron bude hovoriť trochu o prístupe IDERA - je to, ako oddelíte alebo spravujete modelovú vrstvu vašich údajov zo samotnej dátovej vrstvy, z týchto nespracovaných údajov? Takže v dátovej vrstve môžete mať databázy, môžete mať údaje o dokumentoch, môžete mať tabuľky, môžete mať obrazové údaje. Ak ste v oblastiach ako farmaceutický priemysel, máte obrovské množstvo vedeckých údajov. A naviac títo ľudia bežne hľadajú spôsob, ako vytvoriť model, ktorý im umožní rýchlo integrovať tieto údaje a skutočne, keď hľadáte údaje, teraz nechcete všetky údaje sťahovať do modelovej vrstvy., pozeráte sa na vrstvu modelu, aby ste dostali peknú logickú reprezentáciu toho, čo to je, bežné slovníky, bežné typy entít a vzťahov a schopnosť skutočne sa dostať k údajom tam, kde sú. Musí teda povedať, čo to je a musí povedať, kde to je, a musí povedať, ako to dosiahnuť a priniesť ho späť.
Takže to bol prístup, ktorý bol dosť úspešný pri presadzovaní sémantických technológií vpred, čo je oblasť, v ktorej veľa pracujem. Otázka, ktorú som chcel položiť Ronovi a ktorá bude podľa môjho názoru užitočná v časti Otázky a odpovede, spočíva v tom, ako sa to dosiahne platformou IDERA? Je teda vrstva modelu skutočne oddelená od vrstvy údajov? Sú integrovanejšie? Ako to funguje a aké sú niektoré z výsledkov a výhod, ktoré vidia zo svojho prístupu? Referenčné údaje sa preto stávajú skutočne kritickými. Takže ak budete mať tieto druhy dátových modelov, ak sa budete môcť federovať a prehľadávať veci, musíte skutočne mať dobré referenčné údaje. Problém je však v tom, že je ťažké udržiavať referenčné údaje. Takže často sú samotné pomenovania štandardov náročnou výzvou. Jedna skupina bude volať niečo X a jedna skupina bude volať Y a teraz máte problém, ako niekto nájde X a Y, keď hľadajú tento typ informácií? Pretože im nechcete dať iba časť údajov, chcete im dať všetko súvisiace. Súčasne sa zmenia podmienky, softvér prestane byť zastaraný, a tak ďalej, ako udržujete a udržujete tieto referenčné údaje v priebehu času?
A opäť, sémantické technológie, konkrétne s použitím vecí, ako sú taxonómie a slovníky, dátové slovníky, poskytli štandardný vesmírny spôsob, ako to dosiahnuť, čo je skutočne veľmi robustné, používa určité druhy štandardov, ale databázová komunita to urobila pre aj dlhý čas, len rôznymi spôsobmi. Myslím si, že jedným z kľúčov je zamyslieť sa nad tým, ako používať možno modely vzťahov medzi entitami, ako používať modely grafov alebo nejaký typ prístupu, ktorý vám tu, dúfajme, dá skutočne štandardný spôsob zaobchádzania s referenčnými údajmi. A potom, samozrejme, keď budete mať referenčné údaje, musia mapovacie stratégie spravovať širokú škálu mien a entít. Odborníci tak často používajú svoje vlastné termíny.
Výzvou v tomto je teda vždy, ako niekomu poskytnete informácie, ale urobíte ho dôležitým pre spôsob, akým o tom hovoria? Jedna skupina teda môže mať jeden spôsob, ako sa na niečo pozerať, napríklad, môžete byť chemikom pracujúcim na droge a môžete byť štrukturálnym biológom pracujúcim na tom istom lieku a môžete mať rôzne názvy pre rovnaké typy entít. ktoré sa týkajú vášho poľa. Musíte vymyslieť spôsoby, ako spojiť tieto personalizované terminológie, pretože druhým prístupom je, že musíte ľudí prinútiť, aby upustili od svojho funkčného obdobia a použili niekoho iného, čo sa im často nepáči. Ďalším bodom je manipulácia s veľkým počtom synoným, ktoré sú ťažké, takže v údajoch mnohých ľudí existuje veľa rôznych slov, ktoré môžu odkazovať na to isté. Máte problém s odkazom pomocou mnohonásobných vzťahov. Odborné termíny sa v jednotlivých odvetviach líšia, takže ak prídete s takým typom komplexného riešenia pre tento typ správy údajov, ako ľahko je prenosný z jedného projektu alebo z jednej aplikácie do druhej? To môže byť ďalšia výzva.
Automatizácia je dôležitá a je to tiež výzva. Ručné spracovanie referenčných údajov je drahé. Je nákladné mať manuálne mapovanie a je drahé, aby odborníci na predmet prestali robiť svoje každodenné úlohy a museli ísť a neustále opravovať dátové slovníky a aktualizovať definície a tak ďalej a tak ďalej. Replikovateľné slovníky skutočne ukazujú veľkú hodnotu. Toto sú teda časté slovníky, ktoré môžete nájsť mimo svojej organizácie. Ak napríklad pracujete s ropou, budú existovať určité druhy slovníkov, ktoré si môžete požičať z otvorených priestorov, rovnaké s farmaceutickými výrobkami, rovnaké s bankovým priemyslom a finančné, rovnako ako s mnohými podobnými oblasťami. Ľudia tu používajú opakovateľné, všeobecné, opakovateľné slovníky, aby ich ľudia mohli používať.
A opäť, pri pohľade na nástroj IDERA, som zvedavý, ako to riešia, pokiaľ ide o používanie rôznych štandardov. V sémantickom svete často vidíte veci, ako sú modely SKOS, ktoré poskytujú štandardy pre prinajmenšom širšie ako / užšie ako vzťahy, a tieto veci môžu byť ťažké urobiť v modeloch ER, ale viete, nie je to nemožné, záleží len na tom, koľko z toho strojového zariadenia a prepojenia, ktoré v týchto typoch systémov zvládnete.
Nakoniec som chcel urobiť nejaké porovnanie s niektorými sémantickými motormi, ktoré vidím v priemysle, a tak trochu požiadať Rona a trochu ho pripraviť, aby hovoril o tom, ako sa systém IDERA použil v spojení so všetkými sémantickými technológiami. Je možné ho integrovať do trojitých obchodov, databáz grafov? Ako ľahké je používať externé zdroje, pretože tieto druhy vecí v sémantickom svete si často môžete požičať pomocou koncových bodov SPARQL? Modely RDF alebo OWL môžete importovať priamo do svojho modelu - vrátiť sa k nim - napríklad génovej ontológii alebo proteínovej ontológii, ktoré môžu žiť niekde vo vlastnom priestore so svojou vlastnou riadiacou štruktúrou a môžem jednoducho importovať všetky alebo časť z toho, ako ju potrebujem do svojich vlastných modelov. A som zvedavý, ako IDERA pristupuje k tomuto problému. Musíš všetko udržiavať interne, alebo existujú spôsoby, ako ísť používať iné druhy štandardizovaných modelov a vtiahnuť ich dovnútra a ako to funguje? A posledná vec, ktorú som tu spomenul, je to, do akej miery je manuálna práca skutočne potrebná na zostavenie slovníkov a archívov metadát?
Takže viem, že Ron nám ukáže nejaké ukážky týchto vecí, ktoré budú skutočne zaujímavé. Problémy, s ktorými sa často stretávam so zákazníkmi, však spočívajú v tom, že ak ľudia píšu do svojich vlastných definícií alebo do svojich vlastných metaúdajov, dochádza k mnohým chybám. Takže máte pravopisné chyby, máte tučné chyby prstov, to je jedna vec. Získate tiež ľudí, ktorí môžu niečo vziať, viete, iba z Wikipédie alebo zo zdroja, ktorý nemusí byť nevyhnutne v kvalite, akú by ste mohli chcieť vo svojej definícii, alebo vaša definícia je iba z pohľadu jednej osoby, takže nie je úplná a potom nie je jasná ako funguje proces správy. Správa vecí verejných je, samozrejme, veľmi veľký problém vždy, keď hovoríte o referenčných údajoch a kedykoľvek hovoríte o tom, ako to môže zapadnúť do kmeňových údajov niekoho, ako budú používať ich metadáta a tak ďalej.
Chcel som len dať niektoré z týchto tém vonku. Toto sú položky, ktoré vidím v obchodných priestoroch v mnohých rôznych konzultačných zákazkách a v mnohých rôznych priestoroch, a skutočne ma zaujíma to, čo nám Ron ukázal s IDERA, aby poukázal na niektoré z týchto tém., Ďakujem vám veľmi pekne.
Rebecca Jozwiak: Ďakujeme veľmi pekne, Eric, a veľmi sa mi páči váš komentár, že ak ľudia píšu svoje vlastné definície alebo metaúdaje, môžu sa vyskytnúť mnohé chyby. Viem, že vo svete žurnalistiky existuje mantra, že „veľa očí robí niekoľko chýb“, ale keď príde na praktické aplikácie, príliš veľa rúk v nádobe na cookies má tendenciu nechať vás s množstvom rozbitých cookies, však?
Eric Little: Áno, baktérie.
Rebecca Jozwiak: Áno. S tým idem pokračovať a odovzdať ho Malcolmovi Chisholmovi. Malcolm, podlaha je tvoja.
Malcolm Chisholm: Ďakujem veľmi pekne, Rebecca. Chcel by som sa trochu pozrieť na to, o čom Eric hovoril, a pridať niekoľko poznámok, na ktoré, ako viete, by Ron mohol byť ochotný reagovať aj tým, že bude hovoriť o „smerovaní k podnikovej architektúre údajov“. “- čo to znamená byť podnikateľom a prečo je to dôležité? Alebo je to len nejaká forma humbuk? Nemyslím si, že to tak je.
Ak sa pozrieme na to, čo sa od tej doby deje, viete, počítače sálových počítačov boli skutočne k dispozícii spoločnostiam - povedzme okolo roku 1964 - až dodnes, môžeme vidieť, že došlo k mnohým zmenám. A tieto zmeny by som zhrnul ako posun od zamerania na proces k sústredeniu na údaje. To je dôvod, prečo sú podnikové dátové architektúry také dôležité a dôležité pre dnešný deň. A myslím si, že vieš, nie je to len módne slovo, je to niečo, čo je absolútne skutočné.
Ale môžeme to oceniť o niečo viac, ak sa ponoríme do histórie, takže sa vraciame v čase, späť do 60. rokov a na nejakú dobu potom dominovali mainframy. Tieto potom vystriedali počítače, na ktorých ste vlastne vzbúrili používateľov, keď prišli počítače. Povstanie proti centralizovaným IT, o ktorých si mysleli, že nespĺňajú ich potreby, nebolo dosť agilné. To rýchlo viedlo k distribuovanému počítaču, keď boli počítače navzájom prepojené. A potom sa začal internet, ktorý rozmazal hranice podniku - teraz by mohol komunikovať so stranami mimo seba, pokiaľ ide o výmenu údajov, čo sa predtým nestalo. A teraz sme prešli do éry cloudu a veľkých dát, kde cloud je platformou, ktorá skutočne predstavuje komoditizačnú infraštruktúru, a tak nechávame, ako to bolo, IT potrebu prevádzkovať veľké dátové centrá, pretože viete, že Máme k dispozícii cloudovú kapacitu a súbežne s veľkými údajmi, o ktorých Eric, ako viete, tak výrečne diskutovali. A celkovo, ako vidíme, keď nastal posun v technológii, stal sa viac zameraný na údaje, staráme sa viac o údaje. Rovnako ako na internete, ako sa vymieňajú údaje. Pri veľkých dátach sú štyri alebo viac údajov samotných údajov.
Zároveň, a čo je dôležitejšie, sa prípady obchodného použitia zmenili. Keď boli počítače prvýkrát predstavené, používali sa na automatizáciu vecí, ako sú knihy a záznamy. A všetko, čo išlo o manuálny proces, zahŕňajúce knihy alebo podobné veci, bolo naprogramované v podstate vlastne. To sa v 80. rokoch presunulo na dostupnosť operačných balíkov. Už nemusíte písať svoj vlastný výplatný list, môžete si kúpiť niečo, čo to urobilo. To viedlo k veľkému zníženiu v tom čase alebo k reštrukturalizácii mnohých IT oddelení. Potom sa však objavili obchodné informácie, napríklad s údajovými skladmi, väčšinou v 90. rokoch. Nasledovali obchodné modely dotcom, ktoré boli, samozrejme, veľkým šialenstvom. Potom MDM. S MDM začnete vidieť, že nemyslíme na automatizáciu; my sa vlastne zameriavame len na údaje ako na údaje. A potom analytika, ktorá predstavuje hodnotu, ktorú môžete získať z údajov. V rámci analýzy vidíte spoločnosti, ktoré sú veľmi úspešné a ktorých hlavný obchodný model sa točí okolo údajov. Google, Twitter, Facebook by boli súčasťou toho, ale mohli by ste tiež tvrdiť, že Walmart je.
A tak teraz podnikanie skutočne premýšľa o údajoch. Ako môžeme získať hodnotu z údajov? Ako údaje môžu riadiť podnik, stratégiu a sme v zlatom veku údajov. Čo sa teda deje v súvislosti s našou dátovou architektúrou, ak sa údaje už nepovažujú iba za výfuk, ktorý vychádza zo zadnej časti aplikácií, ale je skutočne základom našich obchodných modelov? Časť problému, ktorý máme pri dosahovaní toho, že IT je, je v minulosti skutočne zaseknutá životným cyklom vývoja systémov, ktorý bol dôsledkom nutnosti rýchlo sa zaoberať touto fázou automatizácie procesov v ranom veku IT a pracovať v projekty sú podobné. IT - a to je trochu karikatúra - ale ja sa snažím povedať, že niektoré prekážky, ktoré bránia získaniu obchodnej dátovej architektúry, sú preto, že sme nekriticky prijali kultúru v IT ktorá pochádza z minulého veku.
Takže všetko je projekt. Povedzte mi podrobne svoje požiadavky. Ak veci nefungujú, je to preto, že ste mi nepovedali svoje požiadavky. No to dnes s údajmi nefunguje, pretože nezačíname neautomatizovanými manuálnymi procesmi alebo, ako viete, technickou konverziou obchodných procesov, veľmi často začíname už existujúcimi výrobnými údajmi, ktoré skúšame získať hodnotu z. Nikto, kto sponzoruje projekt zameraný na údaje, však tieto údaje do hĺbky nerozumie. Musíme urobiť zisťovanie údajov, musíme urobiť analýzu zdrojových údajov. A to sa skutočne nezhoduje s vývojom systémov, viete - vodopád, životný cyklus SDLC - z ktorého by Agile, podľa môjho názoru, bola lepšou verziou.
A to, na čo sa zameriava, je technológia a funkčnosť, nie dáta. Napríklad, keď testujeme vo fáze testovania, bude to zvyčajne, funguje moja funkčnosť, povedzme moje ETL, ale údaje netestujeme. Netestujeme naše predpoklady o zdrojových údajoch, ktoré prichádzajú. Keby sme to urobili, boli by sme v lepšej kondícii a ako niekto, kto vykonal projekty v oblasti dátového skladu a trpel zmenami v prúde, zmlátil moje ETL, ocenil by som to. V skutočnosti chceme vidieť testovanie ako predbežný krok k nepretržitému monitorovaniu kvality výrobných údajov. Máme tu teda veľa postojov, v ktorých je ťažké dosiahnuť architektúru dát založenú na podnikaní, pretože sme podmienení obdobím zamerania na procesy. Potrebujeme urobiť prechod na zameranie na údaje. A nejde o úplný prechod, viete, ešte stále je veľa práce, ktorú treba urobiť, ale v prípade údajov sa skutočne nezmýšľame z hľadiska údajov a okolností, ktoré nastanú, keď skutočne povinný to urobiť.
Teraz si spoločnosť uvedomuje hodnotu údajov, chce ich odomknúť, tak ako to urobíme? Ako teda urobíme prechod? Dáta kladieme do centra vývojových procesov. A nechali sme podnikať s požiadavkami na informácie. Chápeme, že nikto nerozumie existujúcim zdrojovým údajom na začiatku projektu. Dalo by sa tvrdiť, že dátová štruktúra a samotné údaje sa tam dostali prostredníctvom IT a operácií, v tomto poradí by sme to mali vedieť, ale v skutočnosti to tak nie je. Toto je vývoj zameraný na údaje. Preto musíme pri premýšľaní o tom, kde a ako robíme modelovanie údajov vo svete zameranom na údaje, musíme mať spätnú väzbu pre používateľov, pokiaľ ide o spresnenie ich požiadaviek na informácie, ako zisťujeme údaje a profilováme údaje., predvídať analýzu zdrojových údajov a postupne získavame čoraz väčšiu istotu o našich údajoch. A teraz hovorím o tradičnejšom projekte, ako je MDM hub alebo dátový sklad, nie nevyhnutne o veľkých dátových projektoch, aj keď je to stále, myslím, dosť blízko. Takže tieto cykly spätnej väzby zahŕňajú, ako viete, dátový modelári, postupujú ďalej v ich dátovom modeli a spolupracujú s používateľmi, aby sa ubezpečili, že požiadavky na informácie sú vylepšené na základe toho, čo je možné, čo je dostupné, zo zdrojových údajov, keď ich lepšie pochopia, takže nie je to už prípad údajového modelu, viete, v stave, ktorý tam buď nie je alebo je úplne hotový, je to postupné zameranie sa na to.
Podobne, viac po prúde, že máme zabezpečenie kvality, kde vyvíjame pravidlá pre testovanie kvality údajov, aby sme sa uistili, že údaje sú v rámci parametrov, o ktorých predpokladáme. Eric ďalej hovoril o zmenách v referenčných údajoch, ktoré sa môžu vyskytnúť. Nechcete byť, ako to bolo, následnou obeťou nespravovaných zmien v tejto oblasti, takže pravidlá zabezpečenia kvality môžu ísť do postprodukčného a nepretržitého monitorovania kvality údajov. Takže môžete začať vidieť, či sa zameriavame na údaje, ako sa vývoj založený na údajoch úplne líši od funkcií založených na funkčnosti SDLC a Agile. A potom musíme venovať pozornosť aj obchodným názorom. Máme - a opäť to odráža to, čo povedal Eric -, máme dátový model definujúci plán dátových príbehov pre našu databázu, ale zároveň potrebujeme tie koncepčné modely, tie obchodné pohľady na údaje, ktoré sa tradične nevykonávali v minulosť. Myslím si, že sme si niekedy mysleli, že dátový model dokáže všetko, ale musíme mať koncepčný pohľad, sémantiku a pozrieť sa do údajov, vykresliť ich cez abstrakčnú vrstvu, ktorá prekladá model úložiska do podnikania. vyhliadka. A opäť, všetky veci, o ktorých Eric hovoril, pokiaľ ide o sémantiku, sa stanú dôležitými, aby sme to dosiahli, takže v skutočnosti máme ďalšie modelovacie úlohy. Myslím, že to je, viete, zaujímavé, ak ste prišli do radov ako dátový modelár ako ja, a znova, niečo nové.
Nakoniec by som chcel povedať, že táto nová realita musí odrážať aj väčšia architektúra. Napríklad tradičný MDM pre zákazníka je v poriadku, dobre, poďme dostať naše zákaznícke údaje do centra, kde ich vieme dať zmysel, pokiaľ ide o skutočne len kvalitu údajov pre back office aplikácie. Ktorý z hľadiska obchodnej stratégie je akýsi zívanie. Dnes sa však pozeráme na zákaznícke centrá MDM, ktoré v nich obsahujú ďalšie údaje o zákazníckych profiloch, nielen statické údaje, ktoré potom skutočne majú obojsmerné rozhranie s transakčnými aplikáciami zákazníka. Áno, stále podporujú back office, ale teraz vieme aj o správaní našich zákazníkov. Stavba je drahšia. To je zložitejšie stavať. Je to však spôsob podnikania, ktorým tradičný MDM pre zákazníka nie je. Obchodujete s orientáciou na podnikanie s jednoduchšími návrhmi, ktoré sa ľahšie implementujú, ale pre podnikanie to chcú vidieť. Sme skutočne v novej ére a myslím si, že existuje množstvo úrovní, na ktoré musíme reagovať na dátovú architektúru riadenia podniku, a myslím si, že je veľmi vzrušujúce robiť veci.
Ďakujem vám, späť k vám, Rebecca.
Rebecca Jozwiak: Ďakujem Malcolmovi a naozaj sa mi páčilo to, čo ste povedali o údajových modeloch, musí sa živiť obchodným pohľadom, pretože na rozdiel od toho, čo ste hovorili, tam, kde IT držalo opraty tak dlho a jednoducho to už tak nie je a že kultúra sa musí posunúť. Som si celkom istý, že v pozadí bol pes, ktorý s vami súhlasil 100%. A s tým idem odovzdať loptu Ronovi. Som naozaj nadšený, keď vidím vaše demo. Ron, podlaha je tvoja.
Ron Huizenga: Ďakujem veľmi pekne a predtým, ako sa do toho pustíme, prejdem niekoľko snímok a potom trochu ukážky, pretože, ako zdôraznili Eric a Malcolm, toto je veľmi široká a hlboká téma a s tým, o čom dnes hovoríme, sa len oškrabávame povrch, pretože existuje toľko aspektov a toľko vecí, ktoré musíme skutočne zvážiť a pozrieť sa na architektúru orientovanú na podnikanie. Náš prístup spočíva v tom, aby sa z modelov skutočne odvodila skutočná hodnota a aby sa z nich odvodila skutočná hodnota, pretože ich môžete použiť ako komunikačné vozidlo aj ako vrstvu na umožnenie ďalších systémov. Či už robíte architektúru orientovanú na služby alebo iné veci, model sa skutočne stane životnou silou toho, čo sa deje, so všetkými metadátami okolo neho a údajmi, ktoré máte vo svojom podnikaní.
O čom však chcem hovoriť, je to však o krok späť, pretože Malcolm sa dotkol časti histórie spôsobu, akým sa riešenia vyvíjali, a toho druhu. Jedným zo spôsobov, ako skutočne poukázať na to, aké dôležité je mať spoľahlivú dátovú architektúru, je prípad použitia, s ktorým som sa veľmi často stretával, keď som konzultoval predtým, ako som vstúpil do úlohy riadenia produktu, a to bolo, že by som išiel do organizácií či už robili transformáciu podniku alebo len nahrádzali niektoré existujúce systémy a tento druh vecí, a veľmi rýchlo sa ukázalo, ako zle organizácie rozumejú svojim vlastným údajom. Ak sa rozhodnete pre konkrétny prípad použitia, ako je tento, či už ste konzultantom, alebo je to osoba, ktorá práve začala s organizáciou, alebo vaša organizácia bola vybudovaná v priebehu rokov akvizíciou rôznych spoločností, čím skončíte je veľmi zložité prostredie veľmi rýchlo, s množstvom nových rôznych technológií, ako aj so staršou technológiou, ERP riešeniami a všetkým ostatným.
Takže jednou z vecí, ktoré s naším modelovým prístupom môžeme skutočne urobiť, je odpovedať na otázku, ako to všetko zmysel? Môžeme skutočne začať zhromažďovať informácie spolu, takže podnikanie môže využívať informácie, ktoré máme správne. A vyjde na to, čo máme tam v týchto prostrediach? Ako môžem pomocou modelov získať informácie, ktoré potrebujem, a lepšie ich porozumieť? A potom máme tradičné typy metaúdajov pre všetky rôzne veci, ako sú relačné dátové modely, a my sme zvyknutí vidieť veci, ako sú definície a dátové slovníky, viete, typy údajov a ten druh vecí. Ale čo ďalšie metaúdaje, ktoré chcete zachytiť, aby im skutočne dali ešte väčší zmysel? Napríklad, ktoré subjekty sú skutočne kandidátmi, ktoré by mali byť referenčnými dátovými objektmi, ktoré by mali byť objektmi správy hlavných údajov a týmito typmi vecí, a navzájom ich spájať. A ako tieto informácie prechádzajú organizáciou? Údajové toky vychádzajú z toho, ako sa spotrebúvajú z procesného hľadiska, ale aj z hľadiska toku informácií, pokiaľ ide o cestu informácií cez naše podniky a o to, ako prechádzajú rôznymi systémami alebo prostredníctvom úložísk údajov, takže vieme, keď vytvárame riešenia I alebo také typy vecí, v skutočnosti spotrebúvame správne informácie pre danú úlohu.
A potom je veľmi dôležité, ako môžeme prinútiť všetky zúčastnené strany, aby spolupracovali, a najmä obchodné zúčastnené strany, pretože práve tie nám dávajú skutočný význam toho, čo sú tieto údaje. Podnik na konci dňa vlastní údaje. Poskytujú definície pre slovníky a veci, o ktorých Eric hovoril, takže potrebujeme miesto, ktoré by to všetko spojilo dohromady. A spôsob, akým to robíme, je prostredníctvom nášho modelovania údajov a architektúr úložísk údajov.
Dotknem sa niekoľkých vecí. Budem hovoriť o ER / Studio Enterprise Team Edition. Hlavne budem hovoriť o produkte dátovej architektúry, kde robíme modelovanie údajov a tento typ vecí, ale existuje veľa ďalších súčastí balíka, na ktoré sa len veľmi krátko dotknem. Uvidíte jeden úryvok obchodného architekta, v ktorom môžeme robiť koncepčné modely, ale môžeme tiež robiť obchodné procesné modely a tieto procesné modely môžeme prepojiť, aby sme prepojili skutočné údaje, ktoré máme v našich údajových modeloch. Naozaj nám to pomáha spojiť túto kravatu. Softvérový architekt nám umožňuje robiť ďalšie konštrukty, ako napríklad niektoré modelovanie UML a také typy vecí, ktoré dávajú podpornú logiku niektorým z týchto iných systémov a procesov, o ktorých hovoríme. Ale veľmi dôležité je, že keď ideme dolu, máme úložisko a tímový server, o ktorom budem hovoriť ako o dvoch poloviciach tej istej veci. Úložisko je miesto, kde ukladáme všetky modelované metaúdaje, ako aj všetky obchodné metaúdaje v zmysle obchodných glosárov a výrazov. A pretože máme toto prostredie založené na úložisku, potom môžeme všetky tieto rôzne veci spojiť v tom istom prostredí a potom ich môžeme skutočne sprístupniť na spotrebu nielen pre technických ľudí, ale aj pre podnikateľov. A takto skutočne začíname viesť spoluprácu.
A potom posledná skladba, o ktorej sa krátko porozprávam, je, že keď vstúpite do týchto prostredí, nie sú to len databázy, ktoré tam máte. Budete mať množstvo databáz, dátových skladov, tiež budete mať veľa toho, čo by som nazval staršie artefakty. Možno ľudia použili program Visio alebo iné schémy na zmapovanie niektorých vecí. Možno mali iné modelovacie nástroje a také veci. To, čo môžeme s MetaWizardom urobiť, je teda extrahovať niektoré z týchto informácií a priniesť ich do našich modelov, urobiť z nich aktuálne a byť schopné ich používať, znova ich konzumovať aktuálnym spôsobom, a nielen ich tam nechať sedieť. Teraz sa stáva aktívnou súčasťou našich pracovných modelov, čo je veľmi dôležité.
Keď vstúpite do organizácie, ako som už povedal, je tam veľa rôznych systémov, veľa riešení ERP, nesúladné riešenia pre jednotlivé oddelenia. Mnoho organizácií tiež používa riešenia SaaS, ktoré sú tiež externe kontrolované a spravované, takže nekontrolujeme databázy a tieto typy vecí v hostiteľoch na nich, ale stále musíme vedieť, ako tieto údaje vyzerajú a samozrejme, metadáta okolo toho. Nájdeme tiež veľa zastaraných starých systémov, ktoré neboli odstránené z dôvodu projektového prístupu, o ktorom hovoril Malcolm. Je úžasné, ako v posledných rokoch organizácie rozbehnú projekty, nahradia systém alebo riešenie, ale často už nie je dosť rozpočtu na vyradenie zastaralých riešení z prevádzky, takže teraz sú už v ceste. A musíme zistiť, čo sa vlastne môžeme v našom prostredí zbaviť, ako aj to, čo je užitočné v budúcnosti. A to súvisí so zlou stratégiou vyraďovania. To je časť a tá istá vec.
Čo tiež zistíme, pretože zo všetkých týchto rôznych riešení bolo vybudovaných veľa organizácií, vidíme veľa rozhraní point-to-point s množstvom údajov, ktoré sa pohybujú na mnohých miestach. Musíme byť schopní to racionalizovať a zistiť, že dátová línia, o ktorej som sa zmienil predtým, aby sme mohli mať súdržnejšiu stratégiu, ako je využívanie architektúry orientovanej na služby, podnikových servisných autobusov a týchto typov vecí, na poskytovanie správnych informácií. modelu zverejnenia a prihlásenia na odber, ktorý správne používame v celom našom podnikaní. A potom, samozrejme, stále potrebujeme vykonať nejakú analýzu, či už využívame dátové sklady, dátové spojenia s tradičným ETL alebo niektoré z nových dátových jazier. To všetko príde na rovnakú vec. Sú to všetky údaje, či už ide o veľké údaje, či už ide o tradičné údaje v relačných databázach, musíme všetky tieto údaje spojiť, aby sme ich mohli spravovať a vedieť, čo riešime v rámci našich modelov.
Zložitosť, ktorú urobíme, je opäť v tom, že máme niekoľko krokov, ktoré chceme urobiť. Najprv vstúpite a možno nebudete mať tie plány, ako vyzerá táto informačná krajina. V nástroji na modelovanie údajov, ako je ER / Studio Data Architect, sa najprv chystáte robiť veľa spätného inžinierstva, pokiaľ ide o zdroje údajov, ktoré sú tam, priviesť ich a potom ich spojiť do reprezentatívnejších. modely, ktoré predstavujú celé podnikanie. Dôležité je, že chceme byť schopní tieto modely rozložiť aj v rámci obchodných línií, aby sme sa s nimi mohli spojiť v menších kúskoch, s ktorými sa môžu naši obchodníci tiež týkať, a našich obchodných analytikov a ďalších zainteresovaných strán, ktoré pracujú. na to.
Pomenovanie štandardov je nesmierne dôležité a hovorím o tom niekoľkými rôznymi spôsobmi. Pomenovanie štandardov podľa toho, ako v našich modeloch pomenujeme veci. Je dosť ľahké robiť v logických modeloch, kde máme dobré pomenovacie konvencie a dobrý slovník údajov pre naše modely, ale potom vidíme rôzne konvencie pomenovávania pre veľa z týchto fyzických modelov, ktoré prinášame. reverzný inžinier, často vidíme skrátené mená a také veci, o ktorých budem hovoriť. A tie musíme preložiť späť do zmysluplných anglických mien, ktoré sú zmysluplné pre podnikanie, aby sme mohli pochopiť, aké sú všetky tieto údaje, ktoré máme v prostredí. A potom je univerzálnym mapovaním to, ako sme ich spojili.
Okrem toho by sme potom dokumentovali a definovali ďalšie informácie, a tu môžeme ďalej klasifikovať naše údaje pomocou niečoho, čo sa nazýva Prílohy, na ktorom vám ukážem niekoľko snímok. A potom uzavrieť slučku, chceme aplikovať tento obchodný význam, čo je miesto, kde sa viažeme do našich obchodných glosárov a môžeme ich prepojiť s našimi rôznymi modelovými artefaktmi, takže vieme, keď hovoríme o určitom obchodnom termíne, kde je to implementované v našich údajoch v celej organizácii. A nakoniec som už hovoril o tom, že toto všetko potrebujeme, aby bolo založené na úložisku s množstvom možností spolupráce a publikovania, aby ho mohli využívať naše zúčastnené strany. O reverznom inžinierstve budem hovoriť pomerne rýchlo. Už som vás o tom veľmi rýchlo informoval. Ukážem vám to v skutočnom ukážke, aby som vám ukázal niektoré veci, ktoré tam môžeme priniesť.
A chcem hovoriť o niektorých rôznych typoch modelov a schém, ktoré by sme vytvorili v tomto type scenára. Je zrejmé, že koncepčné modely urobíme v mnohých prípadoch; Na to nebudem tráviť veľa času. Naozaj chcem hovoriť o logických modeloch, fyzických modeloch a špecializovaných typoch modelov, ktoré môžeme vytvoriť. Je dôležité, aby sme ich mohli vytvoriť všetky na tej istej platforme modelovania, aby sme ich mohli spojiť. To zahŕňa rozmerové modely a tiež modely, ktoré využívajú niektoré nové zdroje údajov, ako napríklad NoSQL, ktoré vám ukážem. A ako potom vyzerá model dátovej línie? A o tom, ako spojíme tieto údaje do modelu podnikových procesov, budeme hovoriť ďalej.
Prejdem sem do modelovacieho prostredia, aby som vám poskytol veľmi vysoký a rýchly prehľad. A verím, že by ste teraz mali vidieť moju obrazovku. Najskôr chcem hovoriť iba o tradičnom type dátového modelu. A spôsob, akým chceme modely usporiadať, keď ich zavádzame, chceme ich rozložiť. To, čo tu vidíte na ľavej strane, je, že v tomto konkrétnom modeli máme logické a fyzické modely. Ďalšia vec je, je, že ju môžeme rozobrať podľa obchodných dekompozícií, takže preto vidíte priečinky. Svetlo modré sú logické modely a zelené sú fyzické modely. A môžeme tiež podrobne rozobrať, takže v rámci ER / Studio, ak máte obchodný rozklad, môžete ísť tak hlboko, ako sa vám páči, a toľko úrovní, a zmeny, ktoré vykonáte na nižších úrovniach, sa automaticky prejavia na vyššej úrovni úrovniach. Takže sa veľmi rýchlo stáva veľmi silným modelovacím prostredím.
Chcel by som tiež zdôrazniť, že je veľmi dôležité začať tieto informácie zhromažďovať spoločne. Môžeme mať niekoľko fyzických modelov, ktoré zodpovedajú aj jednému logickému modelu. Pomerne často môžete mať logický model, ale môžete mať fyzické modely na rôznych platformách a pre tento typ vecí. Možno je to inštancia SQL Servera, možno iná inštancia Oracle. Máme to všetko možnosť zviazať v rovnakom prostredí modelovania. A opäť tu je to, čo tu mám, skutočný model dátového skladu, ktorý môže byť opäť v rovnakom prostredí modelovania alebo ho môžeme mať v úložisku a prepojiť ho aj s rôznymi vecami.
Naozaj som ti chcel ukázať niektoré ďalšie veci a ďalšie varianty modelov, do ktorých sa dostaneme. Takže keď sa dostaneme k tradičnému dátovému modelu, ako je tento, sme zvyknutí vidieť typické entity so stĺpcami a metadátami a takým typom veci, ale tento pohľad sa veľmi rýchlo mení, keď začneme riešiť niektoré z týchto novších technológií NoSQL. alebo ako niektorí ľudia stále radi nazývajú veľké dátové technológie.
Takže teraz povedzme, že v našom prostredí máme aj Úľ. Ak obrátime inžiniera z prostredia Úľa - a dokážeme vpred a vzad inžiniera z Úľa s týmto presne rovnakým nástrojom na modelovanie - vidíme niečo, čo je trochu iné. Stále vidíme všetky dáta ako konštrukty tam, ale naše TDL sa líšia. Tí z vás, ktorí sú zvyknutí vidieť SQL, by ste teraz videli Hive QL, čo je veľmi podobné SQL, ale z toho istého nástroja teraz môžete začať pracovať s rôznymi skriptovacími jazykmi. Takže môžete modelovať v tomto prostredí, generovať ho do prostredia Úľa, ale rovnako dôležité je, že v scenári, ktorý som opísal, môžete všetko prevrátiť a dať mu zmysel a začať ho tiež spájať.,
Zoberme si ďalšiu, ktorá je trochu iná. MongoDB je ďalšia platforma, ktorú natívne podporujeme. A keď začnete vstupovať do typov prostredí JSON, v ktorých máte sklady dokumentov, JSON je iné zviera a v ňom existujú konštrukty, ktoré nezodpovedajú relačným modelom. Čoskoro začnete pracovať s konceptmi, ako sú vložené objekty a vložené polia objektov, keď začnete vypočúvať JSON a tieto koncepty v tradičnom relačnom zápise neexistujú. To, čo sme tu urobili, je to, že sme vlastne rozšírili notáciu a náš katalóg, aby sme to dokázali zvládnuť v rovnakom prostredí.
Ak sa tu pozriete vľavo, namiesto toho, aby sme videli veci, ako sú entity a tabuľky, hovoríme im objekty. A vidíte rôzne zápisy. Stále tu vidíte typické typy referenčných zápisov, ale tieto modré entity, ktoré zobrazujem v tomto konkrétnom diagrame, sú skutočne vloženými objektmi. A my ukazujeme rôzne kardinality. Diamantová mohutnosť znamená, že je to objekt na jednej strane, ale mohutnosť jedného znamená, že v vydavateľovi, ak sa riadime týmto vzťahom, máme zabudovaný objekt adresy. Pri výsluchu JSON sme zistili, že je to presne rovnaká štruktúra objektov, ako je vložená do patróna, ale v skutočnosti je vložená ako skupina objektov. Vidíme to nielen prostredníctvom samotných konektorov, ale ak sa pozriete na skutočné entity, uvidíte, že pod patronátom uvidíte adresy, ktoré ho tiež klasifikujú ako skupinu objektov. Získate veľmi popisný pohľad na to, ako to dosiahnuť.
A opäť, to, čo sme doteraz videli za pár sekúnd, sú tradičné relačné modely, ktoré sú viacúrovňové, môžeme urobiť to isté s Hive, môžeme urobiť to isté s MongoDB a ďalšie veľké zdroje údajov, ako sú dobre. Čo môžeme tiež urobiť, a ja vám to ukážem veľmi rýchlo, hovoril som o tom, že veci prinášam z iných oblastí. Budem predpokladať, že budem importovať model z databázy alebo ho spätne analyzovať, ale prinesiem ho z externých metadát. Len aby som vám poskytol veľmi rýchly pohľad na rôzne typy vecí, ktoré môžeme začať prinášať.
Ako vidíte, máme nespočetné množstvo vecí, pomocou ktorých môžeme metadáta skutočne priniesť do nášho modelovacieho prostredia. Počnúc vecami, ako je napríklad Amazon Redshift, Cassandra, množstvo ďalších veľkých dátových platforiem, takže vidíte veľa z nich. Je to v abecednom poradí. Vidíme veľa veľkých zdrojov údajov a také veci. Vidíme tiež veľa tradičných alebo starších modelovacích prostredí, pomocou ktorých môžeme tieto metaúdaje skutočne priniesť. Ak tu prejdem - a nebudem tráviť čas v každej z nich - vidíme veľa rôznych vecí, z ktorých môžeme vychádzať, pokiaľ ide o modelovacie platformy a dátové platformy. A niečo, čo je veľmi dôležité si uvedomiť, je tu ďalšia časť, ktorú môžeme urobiť, keď začneme hovoriť o dátovej línii. Na Enterprise Team Edition môžeme tiež vypočúvať zdroje ETL, či už ide o mapovanie Talend alebo SQL Server Information Services, môžeme skutočne to priniesť, aby sme mohli začať aj s našimi diagramami dátových línií a nakresliť si obraz toho, čo sa deje v týchto transformáciách. Celkom z krabice máme viac ako 130 z týchto rôznych mostov, ktoré sú v skutočnosti súčasťou produktu Enterprise Team Edition, takže nám to skutočne pomáha rýchlo spojiť všetky artefakty do jedného modelovacieho prostredia.
V neposlednom rade by som chcel hovoriť aj o tom, že nemôžeme stratiť zo zreteľa skutočnosť, že potrebujeme ďalšie typy konštruktov, ak robíme sklady údajov alebo akékoľvek typy analytík. Stále chceme mať schopnosť robiť veci ako rozmerové modely, kde máme faktické tabuľky a máme dimenzie a tieto typy vecí. Chcel by som vám tiež ukázať, že môžeme mať aj rozšírenia našich metadát, ktoré nám pomôžu kategorizovať, aké sú typy dimenzií a všetko ostatné. Ak sa napríklad pozriem na kartu dimenzionálnych údajov, napríklad na jednu z nich, v skutočnosti automaticky zistí na základe vzoru modelu, ktorý vidí, a dá vám východiskový bod, či si myslí, že je to dimenzia alebo tabuľka faktov. Ale okrem toho, čo môžeme urobiť, je v rámci dimenzií a toho typu veci, dokonca máme rôzne typy dimenzií, ktoré môžeme použiť na klasifikáciu údajov v prostredí typu dátového skladu. Tak veľmi silné schopnosti, že to spájame úplne.
Do tohto skočím, pretože práve teraz som v demonštračnom prostredí a ukážem vám pár ďalších vecí, než skočím späť na snímky. Jednou z vecí, ktoré sme nedávno pridali do ER / Studio Data Architect, je to, že sme sa dostali do situácií - a to je veľmi častý prípad použitia, keď pracujete na projektoch - vývojári myslia z hľadiska objektov, zatiaľ čo naše údaje modelári majú tendenciu myslieť z hľadiska tabuliek a entít a toho typu veci. Je to veľmi zjednodušený dátový model, ale predstavuje niekoľko základných konceptov, v ktorých by ich vývojári alebo dokonca obchodní analytici alebo obchodní používatelia mohli považovať za rôzne objekty alebo obchodné koncepcie. Doteraz bolo veľmi ťažké klasifikovať tieto položky, ale to, čo sme v skutočnosti urobili v ER / Studio Enterprise Team Edition, vo vydaní 2016, je, že teraz máme koncept s názvom Business Data Objects. A to nám umožňuje zapuzdriť skupiny entít alebo tabuliek do skutočných obchodných objektov.
Napríklad, v tomto novom pohľade sme sa dostali k tomu, že hlavička objednávky a riadok objednávky boli teraz stiahnuté dokopy, sú zapuzdrené ako objekt, považujeme ich za pracovnú jednotku, keď údaje pretrvávame, a spájame ich, takže je teraz veľmi ľahké spojiť to s rôznymi skupinami publika. Sú opakovane použiteľné v prostredí modelovania. Sú skutočným objektom, nielen kresbou, ale majú aj ďalšiu výhodu, že keď skutočne komunikujeme z perspektívy modelovania, môžeme ich selektívne zbaliť alebo rozšíriť, aby sme mohli vytvoriť súhrnný pohľad na dialógy s určitým publikom zainteresovaných strán, a samozrejme si môžeme zachovať podrobnejší pohľad, ako tu vidíme ďalšie technické publikum. Naozaj nám to poskytuje skutočne dobré komunikačné prostriedky. Teraz vidíme kombináciu viacerých rôznych typov modelov, ich rozširovanie s konceptom obchodných dátových objektov a teraz budem hovoriť o tom, ako v skutočnosti aplikujeme na tieto typy vecí nejaký väčší význam a ako ich navzájom spájame v našich celkové prostredie.
Snažím sa tu nájsť môj WebEx, aby som to dokázal. A tam ideme späť k snímkam Hot Tech. Práve sa chystám rýchlo posunúť vpred niekoľko snímok, pretože ste ich už videli v samotnej ukážke modelu. Chcem hovoriť o pomenovaní štandardov veľmi rýchlo. Chceme uplatňovať a presadzovať rôzne normy pomenovávania. Chceme, aby sme v našich úložiskách skutočne uložili šablóny pomenovacích štandardov, ktoré v podstate budujú tento význam prostredníctvom slov, fráz alebo dokonca skratiek a viažu ich späť k významnému anglickému typu slova. Budeme používať obchodné podmienky, skratky pre každú z nich a môžeme špecifikovať poradie, prípady a pridať predpony a prípony. Typický prípad použitia je zvyčajne vtedy, keď ľudia vytvárajú logický model a potom v skutočnosti vytvoria fyzický model, v ktorom mohli používať skratky a všetko ostatné.
Krásna vec je, že je to rovnako výkonné, ešte silnejšie naopak, ak dokážeme len povedať, aké z tých štandardov pomenovávania sa nachádzali v niektorých z tých fyzických databáz, ktoré sme spätne navrhli, môžeme tieto skratky zobrať, zmeniť ich na dlhšie slov a priviesť ich späť do anglických fráz. Teraz môžeme odvodiť vlastné názvy toho, ako vyzerajú naše údaje. Ako hovorím, typickým prípadom použitia je, že by sme sa posunuli vpred, logicky k fyzickému a namapovali ukladanie údajov a tento druh vecí. Ak sa pozriete na snímku obrazovky na pravej strane, uvidíte, že zo zdrojových názvov existujú skrátené názvy a keď sme použili šablónu štandardov pomenovávania, v skutočnosti sme dostali viac úplných mien. A my by sme mohli vložiť medzery a všetko podobné, ak chceme, v závislosti od šablóny pomenovacích štandardov, ktorú sme použili. Môžeme to urobiť tak, aby to vyzeralo tak, aby to prinieslo naše modely. Až keď vieme, čo sa nazýva, môžeme k nemu začať pripájať definície, pretože ak nevieme, čo to je, ako naň môžeme aplikovať zmysel?
Dobrá vec je, že to môžeme skutočne vyvolať, keď robíme všetky druhy vecí. Keď som hovoril o spätnom inžinierstve, môžeme skutočne vyvolať pomenovanie šablón štandardov súčasne, keď robíme reverzné inžinierstvo. Takže v jednom súbore krokov pomocou sprievodcu môžeme urobiť to, že ak vieme, aké sú konvencie, môžeme spätne analyzovať fyzickú databázu, prinesie ju späť ako fyzikálne modely v modelovacom prostredí a je to tiež použijú tieto pomenovacie konvencie. Uvidíme, aké anglické reprezentácie mien sú v príslušnom logickom modeli v prostredí. Môžeme to urobiť aj kombinovať s generovaním schémy XML, aby sme mohli zobrať model a dokonca ho vytlačiť pomocou našich skratiek, či už robíme rámce SOA alebo také veci, takže potom môžeme tiež vytlačiť rôzne konvencie pomenovávania. ktoré sme skutočne uložili do samotného modelu. Poskytuje nám veľa veľmi silných funkcií.
Tu je príklad toho, ako by to vyzeralo, keby som mal šablónu. Tento dokument v skutočnosti ukazuje, že som mal EMP pre „zamestnanca“, SAL pre „plat“, PLN pre „plán“ podľa konvencie pomenovania štandardov. Môžem ich tiež použiť, aby ich interaktívne fungovali, keď budujem modely a vkladám veci. Keby som používal túto skratku a do názvu entity som napísal „Plátik platov zamestnancov“, konalo by to so šablónou názvových štandardov. Definoval som tu, bolo by mi to EMP_SAL_PLN, keď som vytváral entity a ihneď mi dal príslušné fyzické mená.
Opäť veľmi dobré pre projektovanie a vývoj vpred. Máme veľmi jedinečný koncept a tu skutočne začíname spájať tieto prostredia. A nazýva sa to Universal Mappings. Akonáhle sme priniesli všetky tieto modely do nášho prostredia, čo sme schopní urobiť, za predpokladu, že sme teraz použili tieto konvencie pomenovávania a dajú sa ľahko nájsť, teraz môžeme použiť konštrukciu s názvom Universal Mappings v ER / Studio. Môžeme prepojiť entity medzi modelmi. Kdekoľvek vidíme „zákazníka“ - pravdepodobne budeme mať „zákazníka“ v mnohých rôznych systémoch a v mnohých rôznych databázach - môžeme ich všetky prepojiť tak, že keď s ním pracujem v jednom modeli, vidieť, kde sú prejavy zákazníkov v iných modeloch. A keďže to máme ako vzorovú vrstvu, môžeme ju dokonca spojiť so zdrojmi údajov a priviesť ju k nášmu použitému dotazu, v ktorom sa nachádzajú aj databázy, v ktorých tieto databázy tiež existujú. Skutočne nám to dáva možnosť spojiť to všetko spolu veľmi súdržne.
Ukázal som vám objekty obchodných údajov. Chcem tiež veľmi rýchlo hovoriť o rozšíreniach metadát, ktoré nazývame Prílohy. To nám umožňuje vytvárať ďalšie metadáta pre naše modelové objekty. Pomerne často by som tieto typy nehnuteľností nastavil tak, aby z hľadiska správy údajov a kvality údajov vychádzal z množstva rôznych vecí a aby nám pomáhal s politikou správy hlavných údajov a so zásadami uchovávania údajov. Základnou myšlienkou je, že tieto klasifikácie vytvoríte a môžete ich pripojiť kdekoľvek chcete, na úrovni tabuľky, na úrovni stĺpca, k takýmto typom vecí. Najbežnejším prípadom použitia je, samozrejme, že entity sú tabuľky, a potom môžem definovať: aké sú moje kmeňové dátové objekty, aké sú moje referenčné tabuľky, aké sú moje transakčné tabuľky? Z hľadiska kvality údajov môžem robiť klasifikácie z hľadiska dôležitosti pre podnikanie, aby sme mohli uprednostniť úsilie o čistenie údajov a tento druh vecí.
Niečo, čo sa často prehliada, je, aké sú zásady uchovávania rôznych typov údajov v našej organizácii? Môžeme ich nastaviť a môžeme ich skutočne pripojiť k rôznym typom informačných artefaktov v našom modelovacom prostredí a samozrejme aj k nášmu úložisku. Krása spočíva v tom, že tieto prílohy žijú v našom dátovom slovníku, takže keď v prostredí využívame slovníky podnikových údajov, môžeme ich pripojiť k viacerým modelom. Musíme ich definovať iba raz a môžeme ich znova a znova využiť v rôznych modeloch v našom prostredí. Toto je iba rýchla snímka obrazovky, ktorá ukazuje, že v skutočnosti môžete určiť, kedy urobíte prílohu, k čomu sú všetky kusy pripojené. A tento príklad je vlastne zoznam hodnôt, takže keď idú dovnútra si môžete vybrať zo zoznamu hodnôt, máte v prostredí modelovania veľa kontroly, čo sa vyberie, a dokonca môžete nastaviť, aké predvolené hodnoty hodnota je, ak hodnota nie je vybraná. Takže veľa energie tam. Žijú v dátovom slovníku.
Na tejto obrazovke by som vám chcel ukázať niečo nižšie, navyše v hornej časti sa zobrazujú aj prílohy, pod ktorými sa zobrazujú informácie o zabezpečení údajov. V skutočnosti dokážeme aplikovať zásady bezpečnosti údajov aj na rôzne informácie v prostredí. Pre rôzne mapovania zhody, klasifikácie zabezpečenia údajov dodávame niekoľko z nich, ktoré môžete jednoducho vygenerovať a začať používať, ale môžete tiež definovať svoje vlastné mapovania a štandardy súladu. Či už robíte HIPAA alebo niektorú z ďalších iniciatív. A skutočne môžete začať vytvárať túto veľmi bohatú skupinu metadát vo svojom prostredí.
A potom Glosár a podmienky - tu sa spája obchodný význam. Často tu máme dátové slovníky, ktoré organizácia často používa ako východiskový bod na začatie vyháňania slovníkov, ale terminológia a verbifikácia sú často veľmi technické. Čo môžeme urobiť, je to, že ak ich chceme, môžeme ich použiť ako východiskový bod na vytlačenie glosárov, ale skutočne chceme, aby ich tieto podniky vlastnili. V prostredí tímového servera sme urobili možnosť, aby ľudia mohli vytvárať obchodné definície, a potom ich môžeme prepojiť s rôznymi artefaktmi modelu, ktorým zodpovedajú aj v prostredí modelovania. Uvedomujeme si tiež bod, o ktorom sa diskutovalo skôr, a to čím viac ľudí píšete, tým väčší je ľudský omyl. V našej štruktúre glosárov tiež robíme to, že podporujeme hierarchiu glosárov, takže v organizácii môžeme mať rôzne typy glosárov alebo rôzne typy vecí, ale rovnako dôležité je, ak už máte niektoré z týchto zdrojov tam, kde sú definované podmienky a všetko, môžeme skutočne urobiť import CSV, aby sme ich mohli preniesť do nášho modelovacieho prostredia a nášho tímového servera alebo aj do nášho slovníka a potom odtiaľ začať vytvárať prepojenia. A zakaždým, keď sa niečo zmení, je k dispozícii kompletný záznam o tom, čo boli obrázky pred a po, čo sa týka definícií a všetkého ostatného a čoho uvidíte v blízkej budúcnosti, je tiež skôr pracovným postupom autorizácie. takže môžeme skutočne kontrolovať, kto to má na starosti, schvaľovanie výbormi alebo jednotlivcami a také veci, aby sa proces správy ešte viac posilňoval, ako to bude ďalej.
To, čo to tiež platí pre nás, je, keď máme tieto slovníky v slovníku našich tímových serverov, je to príklad úprav v entite v samotnom modeli, ktorý som tu uviedol. Môže to mať prepojené výrazy, ale tiež robíme, ak existujú slová, ktoré sú v tomto slovníku, ktoré sa nachádzajú v poznámkach alebo popisoch toho, čo tu máme v našich entitách, ktoré sa automaticky zobrazia v ľahšej hyperlinkovanej farbe a ak Keď nad nimi prejdeme myšou, v skutočnosti uvidíme aj definíciu z obchodného slovníka. Dokonca nám poskytuje bohatšie informácie, keď konzumujeme informácie samotné, so všetkými výrazmi, ktoré sú v nej uvedené. Skutočne to pomáha obohatiť skúsenosti a aplikovať význam na všetko, s čím pracujeme.
Takže to bol opäť veľmi rýchly prelet. Pochopiteľne by sme na to mohli stráviť dni, keď sa ponoríme do rôznych častí, ale toto je veľmi rýchly prelet nad povrchom. Skutočne sa snažíme pochopiť, ako tieto zložité dátové prostredia vyzerajú. Chceme zlepšiť viditeľnosť všetkých týchto dátových artefaktov a spolupracovať, aby sme ich vyhnali v ER / Studio. Chceme umožniť efektívnejšie a automatizovanejšie modelovanie údajov. A to sú všetky typy údajov, o ktorých hovoríme, či už ide o veľké údaje, tradičné relačné údaje, sklady dokumentov alebo čokoľvek iné. A opäť sme to dosiahli, pretože máme silné schopnosti vpred a vzad pre rôzne platformy a ďalšie nástroje, ktoré tam môžete mať. A je to všetko o zdieľaní a komunikácii v celej organizácii so všetkými zúčastnenými stranami. To je miesto, kde aplikujeme význam prostredníctvom pomenovania štandardov. Definície potom použijeme prostredníctvom našich obchodných glosárov. Potom môžeme urobiť ďalšie klasifikácie pre všetky naše ďalšie možnosti správy pomocou rozšírení metadát, ako sú rozšírenia kvality údajov, klasifikácie pre správu kmeňových údajov alebo akékoľvek iné typy klasifikácií, ktoré chcete na tieto údaje použiť. A potom môžeme ďalej zhrnúť a ešte viac vylepšiť komunikáciu s objektmi obchodných údajov, s rôznymi skupinami zainteresovaných strán, najmä medzi modelármi a vývojármi.
A čo je na tom veľmi dôležité, za tým všetkým je integrovaný archív s veľmi robustnými schopnosťami riadenia zmien. Nemal som čas to ukázať dnes, pretože sa stáva pomerne zložitým, ale úložisko má veľmi robustné možnosti riadenia zmien a kontrolné záznamy. Môžete robiť pomenované vydania, môžete robiť pomenované verzie a my máme tiež možnosť pre tých z vás, ktorí robia správu zmien, môžeme to priamo spojiť s vašimi úlohami. Dnes máme možnosť vkladať úlohy a priraďovať vaše zmeny modelu k úlohám, rovnako ako vývojári spájajú zmeny kódu s úlohami alebo príbehmi používateľov, s ktorými tiež pracujú.
Opäť to bol veľmi rýchly prehľad. Dúfam, že vám to stačilo na to, aby sme sa mohli tešiť na hlbšie rozhovory o rozdelení niektorých z týchto tém, ako budeme v budúcnosti pokračovať. Ďakujem za váš čas a späť k vám, Rebecca.
Rebecca Jozwiak: Ďakujem, Ron, bolo to fantastické a mám celkom niekoľko otázok od publika, ale chcem dať našim analytikom šancu potopiť ich zuby tým, čo ste povedali. Eric, idem do toho a možno, ak sa chceš venovať tejto snímke alebo inej, prečo nejdeš ako prvý? Alebo akúkoľvek inú otázku.
Eric Little: Iste. Prepáč, aká bola otázka, Rebecca? Chcete, aby som sa opýtal niečo konkrétne alebo …?
Rebecca Jozwiak: Viem, že ste mali spočiatku nejaké otázky pre Rona. Ak chcete teraz požiadať, aby sa obrátil na niektorého z nich, alebo na niektorých z nich, alebo na niečo iné, čo vzbudilo váš záujem, na ktorý sa chcete spýtať? Informácie o modelových funkciách spoločnosti IDERA.
Eric Little: Áno, tak jedna z vecí, Ron, tak ako sa máte, vyzerá to, že diagramy, ktoré ste ukazovali, sú všeobecné druhy diagramov vzťahov entít, aké by ste normálne použili pri zostavovaní databázy, správne?
Ron Huizenga: Áno, všeobecne povedané, ale samozrejme máme rozšírené typy pre obchody s dokumentmi a tiež tento druh vecí. Skutočne sme sa líšili od čisto relačných zápisov, dokonca sme pridali ďalšie zápisy aj pre tieto ďalšie obchody.
Eric Little: Existuje spôsob, ako môžete chlapci využiť typy modelovania založené na grafoch, takže existuje spôsob, ako integrovať, napríklad, predpokladajme, že mám niečo ako najlepší kvadrant, skladateľský nástroj TopBraid alebo niečo urobil v Protégé alebo viete, podobne ako finančníci vo FIBO, robia veľa práce v sémantike, veciach RDF - existuje spôsob, ako začleniť tento typ modelovania typov entít a vzťahov do tohto nástroja a využiť ho to?
Ron Huizenga: Vlastne sa pozeráme na to, ako zvládneme grafy. Dnes sa výslovne nezaoberáme databázami grafov a takýmto typom vecí, ale hľadáme spôsoby, ako to urobiť, aby sme rozšírili naše metadáta. Myslím tým, že teraz môžeme priniesť veci cez XML a tento typ vecí, ak dokážeme prinajmenšom urobiť nejaký druh vykreslenia XML, aby sme ho uviedli ako východiskový bod. Pozeráme sa však na elegantnejšie spôsoby, ako to dosiahnuť.
A tiež som vám ukázal, že zoznam mostov pre spätné inžinierstvo, ktoré tam tiež máme, takže sa stále zameriavame na rozšírenie týchto mostov aj na konkrétne platformy. Ak to má zmysel, je to nepretržité a nepretržité úsilie o začatie prijímania množstva týchto nových konštruktov a rôznych platforiem. Môžem však povedať, že sme určite v popredí. Veci, ktoré som ukázal napríklad na MongoDB, a tento druh vecí, sme prvý predajca modelovania údajov, ktorý to natívne urobil v našom vlastnom produkte.
Eric Little: Dobre, áno. Takže ďalšia otázka, ktorú som pre vás mal, bola preto z hľadiska riadenia a udržiavania - napríklad keď ste použili príklad, keď ste ukázali príklad osoby, ktorá je „zamestnancom“, myslím si, že to bolo „ mzda “a potom máte„ plán “, existuje spôsob, ako spravujete napríklad rôzne druhy ľudí, ktorí môžu mať - predpokladajme, že máte veľkú architektúru, správne, predpokladajme, že máte veľký podnik a v tomto nástroji ľudia začnú ťahať veci dohromady a máte tu jednu skupinu, ktorá má slovo „zamestnanec“ a jednu skupinu, ktorá má slovo „pracovník“. Jedna osoba tu hovorí „plat“ a druhá osoba hovorí "mzdy."
Ako chlapci zmierite a spravujete a spravujete tieto rozdiely? Pretože viem, ako by sme to robili vo svete grafov, viete, používali by ste zoznamy synoným alebo by ste povedali, že existuje jeden koncept a má niekoľko atribútov, alebo by ste mohli povedať, že v modeli SKOS mám preferovanú menovku a mám početné alternatívne štítky, ktoré môžem použiť. Ako to robíte?
Ron Huizenga: Robíme to niekoľkými rôznymi spôsobmi a predovšetkým si povedzme najprv terminológiu. Jednou z vecí, ktorú robíme, samozrejme je, že chceme mať definované alebo sankcionované výrazy a v obchodnom glosári je to, kde ich chceme. A povoľujeme aj odkazy na synonymá v obchodnom slovníku, takže môžete povedať, že môžete povedať, tu je môj výraz, ale môžete tiež definovať, aké sú všetky synonymá pre nich.
Teraz je zaujímavé, že keď začnete pozerať na toto rozsiahle dátové prostredie so všetkými týmito rôznymi systémami, ktoré ste tam dostali, nemôžete tam len ísť a zmeniť zodpovedajúce tabuľky a tieto typy vecí na zodpovedajú tomuto pomenovaciemu štandardu, pretože to môže byť balík, ktorý ste si kúpili, takže nemáte žiadnu kontrolu nad zmenou databázy alebo čohokoľvek.
Mohli by sme tam urobiť, okrem toho, že sme schopní spájať definície pojmov, prostredníctvom tých univerzálnych zobrazení, o ktorých som hovoril, čo by sme urobili, a druh odporúčaného prístupu, je mať logický model, ktorý stanoví, čo tieto rôzne obchodné koncepty sú také, o ktorých hovoríte. Spojte pojmy z obchodného glosára s tými, a teraz je pekné, že máte tento konštrukt, ktorý predstavuje logickú entitu tak, ako bola, potom môžete začať prepojiť túto logickú entitu so všetkými implementáciami tejto logickej entity v rôzne systémy.
Potom, keď to potrebujete urobiť, uvidíte, oh, „osoba“ sa v tomto systéme nazýva „zamestnanec“. „Mzda“ sa v tomto inom systéme nazýva „mzda“. Pretože to uvidíte, uvidíte všetky rôzne prejavy tých, pretože ste ich spojili.
Eric Little: Dobre, dobre, dobre. Je v tomto zmysle možné povedať, že je to niečo ako niektoré objektovo orientované prístupy?
Ron Huizenga: Trochu. Je to trochu intenzívnejšie, ako by ste povedali. Myslím tým, že by ste sa mohli chopiť prístupu manuálneho prepojenia a prechodu a kontroly a vykonania všetkých z nich. O jednej veci, o ktorej som nemal skutočnú šancu hovoriť - pretože opäť máme veľa možností - máme aj úplné rozhranie automatizácie v samotnom nástroji Data Architect. A schopnosť makra, čo je skutočne programovací jazyk v nástroji. Takže môžeme skutočne robiť veci ako písať makrá, nechať ich ísť a vypočúvať veci a vytvárať odkazy pre vás. Používame ich na import a export informácií, môžeme ich použiť na zmenu vecí alebo pridávanie atribútov, udalostí založených na samotnom modeli, alebo ich môžeme použiť na spustenie v dávkach, aby skutočne vyšli von a vypočúvali veci a skutočne naplnili rôzne konštrukcie v Model. Takže existuje úplné rozhranie automatizácie, ktoré môžu využívať aj ľudia. A použitie univerzálnych mapovaní s nimi by bolo veľmi účinným spôsobom.
Rebecca Jozwiak: Dobre, vďaka Ronovi a vďaka Ericovi. To boli skvelé otázky. Viem, že beháme trochu za hranicu hodiny, ale chcel by som dať Malcolmovi šancu položiť pár otázok Ronovi cestu. Malcolm?
Malcolm Chisholm: Ďakujem, Rebecca. Takže, Ron, je to veľmi zaujímavé, vidím, že tu je veľa schopností. Jednou z oblastí, o ktoré ma veľmi zaujíma, je napríklad to, že ak máme vývojový projekt, ako vidíte dátový modelár, ktorý tieto schopnosti využíva a čo možno viac spolupracuje s obchodnými analytikmi, s profilovateľom údajov a s analytikom kvality údajov? a so sponzormi podnikania, ktorí budú v konečnom dôsledku zodpovední za skutočné požiadavky na informácie v projekte. Ako vlastne viete, modelár údajov zefektívni a zefektívni projekt pomocou schopností, na ktoré sa pozeráme?
Ron Huizenga: Myslím si, že jedna z prvých vecí, ktorú musíte urobiť, je ako dátový modelár - a nechcem si vyberať niektorých modelárov, ale aj tak budem - je, že niektorí ľudia majú stále dojem, že dátový modelár je skutočne typom úlohy strážcu, definujeme, ako to funguje, sme strážcovia, ktorí zabezpečujú, aby bolo všetko v poriadku.
Teraz je tu aspekt, že sa musíte ubezpečiť, že definujete architektúru zvukových údajov a všetko ostatné. Ale dôležitejšia vec je ako dátový modelár - a keď som konzultoval, zistil som to celkom zrejme - musíte sa stať sprostredkovateľom, takže musíte týchto ľudí pritiahnuť k sebe.
Nebude to už vopred dizajn, vytvárať, budovať databázy - to, čo musíte urobiť, je, že musíte byť schopní pracovať so všetkými týmito rôznymi skupinami zainteresovaných strán, robiť veci ako reverzné inžinierstvo, importovať informácie, mať iní ľudia spolupracujú, či už ide o glosáre alebo dokumentáciu, o všetko podobné - a byť sprostredkovateľom, aby to vtiahli do úložiska a prepojili pojmy v úložisku a spolupracovali s týmito ľuďmi.
Je to skutočne oveľa viac prostredie založené na spolupráci, kde aj vďaka definovaniu úloh alebo diskusných vlákien alebo typu vecí, ktoré máme v tímovom serveri, môžu ľudia skutočne spolupracovať, klásť otázky a dospieť k finálnym konečným produktom, ktoré oni potreba ich dátovej architektúry a organizácie. Odpoveď na túto otázku?
Malcolm Chisholm: Áno, súhlasím. Vieš, myslím si, že facilitátorská zručnosť je niečo, čo je v modelároch údajov skutočne veľmi žiaduce. Súhlasím s tým, že to nie vždy vidíme, ale myslím si, že je to potrebné a navrhoval by som, že niekedy existuje sklon zostať vo vašom rohu pri modelovaní údajov, ale v skutočnosti musíte byť tam, aby ste spolupracovali s ostatnými skupinami zainteresovaných strán. alebo jednoducho nerozumiete dátovému prostrediu, s ktorým sa stretávate, a myslím si, že výsledkom bude tento model. Ale to je len môj názor.
Ron Huizenga: A je to zaujímavé, pretože ste už vo svojej snímke spomenuli niečo o histórii toho, ako sa podniky odvracajú od IT, pretože neposkytovali riešenia včas a tieto typy vecí.
Je veľmi zaujímavé, že v mojich neskorších konzultáciách pred tým, ako som sa stal produktovým manažérom, väčšina projektov, ktoré som urobil za posledné dva roky pred tým, bola sponzorovaná firmou, kde to bola práve spoločnosť, ktorá ju viedla, a dátoví architekti. a modelári neboli súčasťou IT. Boli sme súčasťou skupiny sponzorovanej podnikmi a boli sme tam ako sprostredkovatelia pracujúci so zvyškom projektových tímov.
Malcolm Chisholm: Takže si myslím, že je to veľmi zaujímavý bod. Myslím, že začíname pozerať na posun v obchodnom svete, v ktorom sa firma pýta alebo možno rozmýšľa, nie toľko ako to, čo robím, je to proces, ale začínajú tiež premýšľať o tom, aké sú údaje s ktorými pracujem, aké sú moje údaje, aké sú údaje, s ktorými pracujem ako údaje, a do akej miery môžeme získať produkty a schopnosti IDERA na podporu tohto hľadiska, a myslím si, že potreby podnikania, dokonca aj aj keď je to trochu trochu rodiace sa.
Ron Huizenga: Súhlasím s vami a myslím si, že to tak vidíme stále viac. Videli sme prebudenie a vy ste sa ho už skôr dotkli, pokiaľ ide o dôležitosť údajov. Videli sme dôležitosť údajov na začiatku IT alebo vývoja databáz, potom, ako hovoríte, sme sa dostali do celého tohto cyklu riadenia procesov - a proces je nesmierne dôležitý, nechápte ma tam zle - ale teraz, čo sa stalo je, keď sa to stalo, dátový druh strateného zamerania.
Organizácie si teraz uvedomujú, že údaje sú skutočne ústredným bodom. Údaje predstavujú všetko, čo v našom podnikaní robíme, takže sa musíme uistiť, že máme presné údaje, aby sme našli správne informácie, ktoré potrebujeme, aby sme mohli robiť naše rozhodnutia. Pretože nie všetko pochádza z definovaného procesu. Niektoré informácie sú vedľajším produktom iných vecí a my ich stále musíme vedieť nájsť, vedieť, čo to znamená, a vedieť preniesť údaje, ktoré tu vidíme, do vedomostí, ktoré môžeme použiť na lepšie riadenie našich podnikov.
Malcolm Chisholm: Dobre, a teraz ďalšou oblasťou, s ktorou sa stretávam, by som nazval životný cyklus údajov, ktorý je, viete, ak sa pozrieme na druh reťazca dodávok údajov prechádzajúcim podnikom, začali by sme získavanie údajov alebo zaznamenávanie údajov, čo môže byť zadávanie údajov, ale rovnako to môže byť, získavam údaje od vonkajšieho podniku od niektorého dodávateľa údajov.
A potom zo zberu údajov ideme do údržby dát, kde premýšľam o štandardizácii týchto údajov a ich dodaní na miesta, kde je to potrebné. A potom použitie údajov, skutočné body, v ktorých sa údaje nachádzajú, z údajov získate hodnotu.
A za starých čias sa to všetko deje v jednom individuálnom štýle, ale dnes to môže byť, viete, analytické prostredie a potom aj archív, obchod, kam vložíme údaje, keď už prestaneme Potrebujeme to a nakoniec očistný druh procesu. Ako vidíte modelovanie údajov zapadajúce do riadenia celého tohto životného cyklu údajov?
Ron Huizenga: To je veľmi dobrá otázka a jednu vec, o ktorej som tu dnes vôbec nemal čas sa podrobne zaoberať, je to, o čom skutočne začíname hovoriť, je dátová línia. To, čo v skutočnosti dokážeme, je to, že máme v našich nástrojoch kapacitu dátových línií a, ako hovorím, môžeme niektoré z nich skutočne extrahovať z nástrojov ETL, ale môžete ich tiež zmapovať iba nakreslením línie. Ktorýkoľvek z týchto dátových modelov alebo databáz, ktoré sme zachytili a priniesli do modelov, by sme mohli referencovať konštrukty z tých, ktoré sú uvedené v našom diagrame dátovej línie.
Ako viete, môžeme nakresliť tok údajov od zdroja k cieľu a počas celého životného cyklu toho, ako sa tieto údaje prenášajú rôznymi systémami a čo hľadáte, vezmime zamestnancov. 'data - je to jeden z mojich obľúbených na základe projektu, ktorý som urobil pred rokmi. Pracoval som s organizáciou, ktorá mala údaje o zamestnancoch v 30 rôznych systémoch. To, čo sme tam nakoniec urobili - a Rebecca vyskočila na snímku dátovej línie - je to pomerne zjednodušená snímka na obrázkovej línii, ale to, čo sa nám podarilo urobiť, bolo priniesť všetky štruktúry údajov, uviesť ich v diagrame a potom v skutočnosti sa môže začať skúmať, aké sú toky medzi nimi a ako sú tieto rôzne dátové entity navzájom spojené v toku? A môžeme ísť aj ďalej. Toto je časť toku údajov alebo rodového plánu, ktorý vidíme tu. Ak chcete ísť ďalej, máme aj súčasť architektúry obchodných priestorov a to isté platí.
Akákoľvek z dátových štruktúr, ktoré sme zachytili v prostredí modelovania údajov, je možné na ne odkazovať v nástroji obchodného modelovania, takže aj v diagramoch obchodného modelu alebo v diagramoch podnikových procesov môžete odkazovať na jednotlivé úložiská údajov, ak si želáte prostredie na modelovanie údajov a keď ich používate v priečinkoch vo vašom modeli podnikových procesov, môžete dokonca určiť CRUD aj v týchto zložkách, ako sa tieto informácie buď spotrebúvajú alebo vyrábajú, a potom môžeme začať generovať veci ako správy o dopadoch a analýzy a diagramy z toho.
Na čo sa zameriavame, a máme už veľa schopností, ale jedna z vecí, ktorú máme, je ako druh žuvačky, na ktorú sa pozeráme, pretože v ďalšom vývoji našich nástrojov pokračujeme ďalej, je schopný zmapovať tento komplexný rad údajov o organizačných údajoch a celý životný cyklus údajov.
Malcolm Chisholm: Dobre. Rebecca, mám ešte jednu?
Rebecca Jozwiak: Dovoľte mi ešte jedného, Malcolme, choďte do toho.
Malcolm Chisholm: Ďakujem veľmi pekne. Ako premýšľame o riadení údajov a premýšľaní o modelovaní údajov, ako prinútime tieto dve skupiny, aby efektívne spolupracovali a vzájomne si rozumeli?
Eric Little: No, je to zaujímavé, myslím si, že to skutočne záleží na organizácii, a to sa vracia k môjmu predchádzajúcemu konceptu v tých organizáciách, v ktorých boli iniciatívy zamerané na podnikanie, kde sme boli priamo priviazaní. Napríklad som viedla dátovú architektúru tímu, ale boli sme priamo prepojení s podnikovými používateľmi a vlastne sme im pomáhali obstáť v ich programe správy údajov. Opäť platí, že viac konzultačný prístup, ale je to naozaj viac obchodné funkcie.
Potrebujete to, aby ste to dokázali, je to, že potrebujete modelárov údajov a architektov, ktorí skutočne rozumejú podnikaniu, môžu sa týkať podnikových používateľov a potom im pomáhajú postaviť sa v procese riadenia. Podnikanie to chce urobiť, ale vo všeobecnosti máme technologické znalosti, aby sme im pomohli vyniknúť pri týchto typoch programov. Skutočne to musí byť spolupráca, ale musí byť vo vlastníctve firmy.
Malcolm Chisholm: Dobre, to je skvelé. Ďakujem.
Eric Little: Dobre.
Rebecca Jozwiak: Dobre, ďakujem veľmi pekne. Členovia publika, obávam sa, že sme sa nedostali k vašim otázkam, ale ubezpečím sa, že sa dostanú k príslušnému hosťovi, ktorého sme mali dnes na linke. Chcem sa vám veľmi pekne poďakovať Ericovi, Malcolmovi a Ronovi za to, že ste dnes našimi hosťami. Bola to skvelá vec, ľudia. A ak ste si užili dnešné webové vysielanie IDERA, IDERA sa tiež chystá na budúcu stredu v Hot Technologies, ak sa chcete pripojiť, diskutovať o výzvach indexovania a Oracles, čo je ďalšia fascinujúca téma.
Ďakujem vám, vážení ľudia, dajte si pozor a nabudúce sa s vami stretneme. Zbohom.
