Ära võtma: Host Rebecca Jozwiak arutab andmearhitektuuri lahendusi OSTHUSe Eric Little, esimese San Francisco partneri Malcolm Chisholmi ja IDERA Ron Huizengaga.
Te pole praegu sisse logitud. Video nägemiseks logige sisse või registreeruge.
Rebecca Jozwiak: Daamid ja härrad, tere ja tere tulemast 2016. aasta kuumade tehnoloogiate juurde. Arutame täna kindlasti kuuma teemat „Ettevõtluspõhise andmearhitektuuri loomine“. Minu nimi on Rebecca Jozwiak, ma olen teie tänase veebiülekande host. Me teeme säutsu # HotTech16 hashtagiga, nii et kui olete juba sisse loginud, siis palun julgelt ka sellega ühineda. Kui teil on mis tahes ajal küsimusi, palun sisestage need ekraani paremas alanurgas olevasse küsimuste ja vastuste paani ja tagame, et neile vastatakse. Kui ei, siis hoolitseme selle eest, et meie külalised saaksid need teie eest.
Nii et täna on meil tõeliselt põnev koosseis. Täna on meiega palju raskeid lööjaid. Meil on Eric Little, OSTHUSe andmeteaduste osakonna juhataja. Meil on First San Francisco Partnerite innovatsioonijuht Malcolm Chisholm, mis on tõeliselt lahe tiitel. Ja meil on IDERA vanem tootejuht Ron Huizenga. Ja te teate, IDERA on tõesti täielik andmehaldus- ja modelleerimislahenduste komplekt. Ja täna annab ta meile demo, kuidas tema lahendus töötab. Kuid enne kui me selleni jõuame, Eric Little, annan teile palli edasi.
Eric Little: Olgu, suur tänu. Nii et ma käin siin läbi paar teemat, mis minu arvates seostuvad Roni jutuga natuke ja loodetavasti seadsin aluse ka mõnele neist teemadest, mõnele küsimusele ja vastusele.
IDERA tegemistest huvitas mind see, et arvan, et nad osutavad õigesti, et keerulised keskkonnad juhivad tänapäeval tõesti palju äriväärtusi. Ja keerukate keskkondade all peame silmas keerulisi andmekeskkondi. Ja tehnoloogia liigub tõesti kiiresti ja tänapäeva ettevõtluskeskkonnas on raske sammu pidada. Nii näevad need inimesed, kes töötavad tehnoloogiaruumides, sageli, et teil on kliente, kes tegelevad probleemidega: „Kuidas kasutada suurandmeid? Kuidas semantilisi ühendada? Kuidas siduda osa sellest uuest kraamist oma vanemate andmetega? ”Ja nii edasi, ja see viib meid tänapäeval nendesse nelja suure andmeandme hulka, mis on paljudele inimestele tuttavad ja ma saan aru, et neid võib olla rohkem kui neli Mõnikord - olen näinud koguni kaheksat või üheksa - aga tavaliselt, kui inimesed räägivad sellistest asjadest nagu suurandmed või kui räägite suurandmetest, siis tavaliselt vaadatakse midagi sellist, mis on omamoodi ettevõtlus. Ja nii ütlevad inimesed: okei, hästi, mõelge oma andmete mahule, millele tavaliselt keskendutakse - see on just see, kui palju teil on. Andmete kiirus on seotud sellega, kui kiiresti suudan neid liigutada või kui kiiresti saan päringuid teha või vastuseid saada jne. Ja isiklikult arvan, et selle vasak külg on asi, mida lahendatakse ja käsitletakse suhteliselt kiiresti paljude erinevate lähenemisviiside abil. Kuid paremal küljel näen palju paranemisvõimalusi ja palju uusi tehnoloogiaid, mis on tõesti esiplaanile jõudmas. Ja see on tõesti seotud kolmanda veeruga, andmete sordiga.
Ehk teisisõnu: enamik ettevõtteid vaatab tänapäeval struktureeritud, poolstruktureeritud ja struktureerimata andmeid. Kujutise andmed on hakanud muutuma kuumaks teemaks, nii et kui teil on võimalik kasutada arvutinägemust, vaadata piksleid, kraapida, NLP, olemi ekstraheerimine, teil on graafiku kohta teavet, mis pärineb kas statistilistest mudelitest või semantilistest mudelitest. , teil on relatsiooniandmeid, mis on olemas tabelites jne. Ja kõigi nende andmete koondamine ning kõik need erinevad tüübid kujutab endast tõesti suurt väljakutset ja te näete seda Gartneris ja teistes inimestes, kes jälgivad justkui suundumusi tööstuses.
Ja siis on viimane asi, millest inimesed suurandmetes räägivad, sageli see kõnekuse mõiste, mis on tegelikult teie andmete ebakindlus, selle hägusus. Kui hästi te teate, mis teie andmetega on seotud, kui hästi saate aru, mis seal on ja kas teate? Seal võib olla väärtuseks statistika kasutamise oskus ja võime kasutada teatavat tüüpi teavet selle ümber, mida võite teada, või mõne con). Ja nii on võimalus vaadata andmeid sel viisil, kui palju teil on, kui kiiresti peate neid ümber laadima või sellega tutvuma, igat tüüpi andmeid, mis teie ettevõttes võivad olla, ja kui kindlad olete, kus olete see on, mis see on, mis kvaliteediga see on jne. See nõuab tõesti paljude inimeste vahel suuri, kooskõlastatud jõupingutusi, et oma andmeid tõhusalt hallata. Seetõttu on andmete modelleerimine tänapäeva maailmas üha olulisem. Nii et head andmemudelid viivad ettevõtterakendustes tõesti palju edu.
Teil on andmeallikaid mitmesugustest allikatest, nagu me ütlesime, mis nõuab tõesti palju erinevaid integratsioone. Nii et kogu selle kokku koondamine on tõesti kasulik, et saaksite päringuid käivitada näiteks paljude eri tüüpi andmeallikate puhul ja teavet tagasi tõmmata. Kuid selleks on vaja häid kaardistamisstrateegiaid ja seega võib seda tüüpi andmete kaardistamine ja nende kaardistamise jälgimine olla tõeline väljakutse. Ja siis on teil see küsimus. Kuidas ma saan siduda oma vanad andmed kõigi nende uute andmeallikatega? Nii et oletame, et mul on graafik, kas ma võtan kõik oma relatsioonandmed ja panen selle graafikusse? Tavaliselt pole see hea mõte. Kuidas on nii, et inimesed on võimelised haldama kõiki selliseid toimivaid andmemudeleid? Analüüs tuleb tõesti läbi viia paljudel erinevat tüüpi andmeallikatel ja nende kombinatsioonidel. Seega on kriitilised vastused, mis sellest välja tulevad, vastused, mida inimesed vajavad heade äriotsuste tegemiseks.
Nii et see ei puuduta ainult ehitustehnoloogiat tehnoloogia huvides, see on tegelikult see, mida ma kavatsen teha, mida ma saan sellega teha, millist analüüsi ma saan läbi viia, ja seetõttu ka võime, nagu ma juba olen on olnud väga oluline, et seda kraami kokku tõmmata, integreerida. Ja üks seda tüüpi analüüsidest töötab siis näiteks ühendatud otsingu ja päringuga. See on tõesti muutumas kohustuslikuks. Teie päringud peavad tavaliselt olema keermestatud erinevat tüüpi allikate vahel ja tõmbama teabe usaldusväärse tagasi.
Üks põhielement, mis sageli, eriti inimesed, vaatleb selliseid võtmeasju nagu semantilised tehnoloogiad - ja see on asi, millest loodan, et Ron räägib IDERA-lähenemises natuke - on see, kuidas te eraldate või haldate mudeli kiht oma andmeid andmekihist endast, sellest töötlemata andmetest? Nii et andmekihis võivad teil olla andmebaasid, teil võivad olla dokumentide andmed, võib-olla arvutustabeli andmed, teil võivad olla pildiandmed. Kui asute sellistes valdkondades nagu farmaatsiatööstus, olete saanud tohutul hulgal teaduslikke andmeid. Ja peale selle otsivad inimesed tavaliselt viisi, kuidas luua mudel, mis võimaldab neil neid andmeid kiiresti integreerida. Kui otsite andmeid nüüd, ei taha te kogu andmeid mudeli kihti üles tõmmata , mida te vaatate, kuidas mudelikihti teha, on anda teile kena loogiline esitus selle kohta, mis asjad on, ühised sõnavarad, ühised olemite ja suhete tüübid ning võimalus jõuda päriselt andmeteni seal, kus see on. Nii et ta peab ütlema, mis see on, ja ütlema, kus see asub, ja ütlema, kuidas seda tuua ja tagasi tuua.
Nii et see on olnud lähenemine, mis on olnud üsna edukas semantiliste tehnoloogiate tõukamisel, mis on valdkond, kus töötan palju. Niisiis on küsimus, mille ma tahtsin Ronile esitada ja mis on minu arvates küsimuste ja vastuste osas kasulik, küsimus: kuidas seda IDERA platvorm täidab? Nii on mudeli kiht tegelikult andmekihist eraldi? Kas nad on rohkem integreeritud? Kuidas see töötab ja mis on mõned tulemustest ja eelistest, mida nad oma lähenemisest näevad? Seetõttu on võrdlusandmed tõesti muutumas ka kriitiliseks. Nii et kui teil on sellist tüüpi andmemudeleid ja kui teil on võimalus koondada asju ja otsida mitmesuguseid asju, peavad teil tõesti olema head viiteandmed. Kuid probleem on võrdlusandmetes, mida on tõesti raske hooldada. Seega on standardite iseenesest nimetamine sageli keeruline väljakutse. Üks rühm nimetab midagi X ja üks rühm midagi Y ja nüüd on teil probleem, kuidas keegi leiab X ja Y, kui nad seda tüüpi teavet otsivad? Kuna te ei soovi neile vaid osa andmetest anda, soovite neile anda kõik seotud. Samal ajal muutuvad terminid, tarkvara vananeb ja nii edasi, kuidas seda viiteandmeid aja jooksul hoida ja säilitada?
Ja jällegi, semantilised tehnoloogiad, kasutades konkreetselt selliseid asju nagu taksonoomiad ja sõnaraamatud, andmesõnastikud, on andnud selleks tavapärase kosmoseviisi, mis on tõesti väga jõuline, kasutab teatud tüüpi standardeid, kuid andmebaasikogukond on seda teinud ka pikka aega, lihtsalt erineval viisil. Arvan, et üks võtmeid siin on mõelda sellele, kuidas kasutada võib-olla olem-seose mudeleid, kuidas kasutada võib-olla graafilisi mudeleid või mõnda tüüpi lähenemisviisi, mis annab teile loodetavasti standardse vahemaa viisi oma võrdlusandmete käsitlemiseks. Ja muidugi, kui teil on viiteandmed, peavad kaardistamisstrateegiad haldama mitmesuguseid nimesid ja üksusi. Nii et teemaekspertidele meeldib sageli kasutada oma termineid.
Seega on selles alati väljakutse: kuidas anda kellelegi teavet, kuid muuta see asjakohaseks viisil, kuidas nad sellest räägivad? Nii et ühel rühmal võib olla üks viis millegi vaatamiseks, näiteks võite olla keemik, kes töötab mõne ravimi kallal, ja võite olla sama ravimiga tegelev struktuuribioloog ning sama tüüpi üksuste jaoks võivad olla erinevad nimed mis on seotud teie valdkonnaga. Peate välja mõtlema, kuidas neid isikustatud terminoloogiaid kokku viia, sest teine lähenemisviis on see, et peate sundima inimesi loobuma oma ametiajast ja kasutama kellegi teise oma, mis neile sageli ei meeldi. Veel üks asi siin on see, et suure hulga sünonüümide käsitlemine muutub keeruliseks, nii et paljude inimeste andmetes on palju erinevaid sõnu, mis võivad viidata samale asjale. Teil on seal viiteprobleem, kasutades mitmekesi suhteid. Spetsialiseerunud terminid erinevad valdkonniti, nii et kui soovite pakkuda sellist tüüpi andmehalduse jaoks kõikehõlmavat lahendust, kui hõlpsalt on see kaasaskantav ühest projektist või ühest rakendusest teise? See võib olla veel üks väljakutse.
Automatiseerimine on oluline ja samas ka väljakutse. Viiteandmete käsitsi käsitlemine on kallis. Kulukas on käsitsi kaardistamise pidamine ja kulukas on, kui teemaeksperdid lõpetavad oma igapäevaste tööde tegemise ning peavad sisse logima ja pidevalt parandama andmesõnastikke ning värskendama määratlusi ja nii edasi ja nii edasi. Korduv sõnavara näitab tõesti palju väärtust. Nii et need on sageli sõnavara, mille leiate organisatsioonist väljaspool. Näiteks kui töötate näiteks toornaftaga, siis on olemas teatud tüüpi sõnavarasid, mida saate laenata avatud lähtekoodiga ruumidest, sama on ravimitega, sama panganduse ja finantssektoriga, sama paljudes teistes valdkondades. Inimesed esitavad seal kasutamiseks korduvkasutatavaid, üldisi, korratavaid sõnastikke.
Ja jällegi, vaadates IDERA tööriista, on mul uudishimulik näha, kuidas nad seda käsitlevad mitmesuguste standardite kasutamise osas. Semantikamaailmas näete sageli selliseid asju nagu SKOS-mudelid, mis pakuvad suhteid vähemalt laiematele / kitsamatele standarditele ja neid asju saab ER-mudelis olla keeruline teha, kuid teate, mitte võimatu, see sõltub lihtsalt sellest, kui palju sellest masinad ja linkimine, millega saate seda tüüpi süsteemides hakkama saada.
Lõpuks tahtsin ma lihtsalt võrrelda mõnda semantilisi mootoreid, mida ma selles valdkonnas näen, ja paluda siis Ronil natuke juhtida, et ta räägiks sellest, kuidas IDERA süsteemi on kasutatud koos kõigi semantiliste tehnoloogiatega.Kas seda saab integreerida kolmekordsete kaupluste, graafiaandmebaasidega? Kui lihtne on väliseid allikaid kasutada, kuna selliseid asju semantilises maailmas saab sageli laenata SPARQLi lõpp-punktide abil? Võite importida RDF- või OWL-mudeleid otse oma mudelisse - vaadake neile tagasi - seega näiteks geeni ontoloogia või valgu ontoloogia, mis võivad elada kuskil oma ruumis oma juhtimisstruktuuriga ja ma saan lihtsalt importida kõik või osa sellest, kui vajan seda omaenda mudelitesse. Ja mul on uudishimulik teada saada, kuidas IDERA selle teema juurde suhtub. Kas peate kõike sisemiselt hooldama või on olemas võimalusi, kuidas muud tüüpi standardseid mudeleid kasutada ja neid sisse tõmmata ning kuidas see töötab? Ja viimane asi, mida ma siin mainisin, on see, kui palju on käsitsitööd sõnastike ja metaandmete hoidlate koostamiseks?
Nii et ma tean, et Ron näitab meile selliseid asju, mis on tõeliselt huvitavad. Kuid sageli näen klientidega konsulteerimist selles, et paljud vead tekivad siis, kui inimesed kirjutavad oma määratlused või metaandmed. Nii et saate valesti kirjutatud vead ja rasvase sõrme vead, see on üks asi. Te saate ka inimesi, kes võivad võtta midagi, teate, lihtsalt Vikipeediast või allikast, mis ei pruugi tingimata olla selle kvaliteediga, mida võiksite oma määratluses soovida, või on teie määratlus ainult ühe inimese vaatevinklist, nii et see pole täielik ja pole siis selge kuidas juhtimisprotsess töötab. Juhtimine on muidugi väga-väga suur probleem igal ajal, kui räägite viiteandmetest ja igal ajal, kui räägite sellest, kuidas see võib sobida kellegi põhiandmetega, kuidas nad hakkavad oma metaandmeid kasutama ja nii edasi.
Nii et ma tahtsin lihtsalt mõned neist teemadest sinna välja panna. Need on esemed, mida näen äriruumis väga paljudes erinevates konsultatsiooniettevõtetes ja paljudes erinevates ruumides. Mulle on tõesti huvitav näha, mida Ron meile IDERA abil näitab, et mõnda neist teemadest välja tuua . Nii et tänan teid väga.
Rebecca Jozwiak: Suur tänu, Eric, ja mulle väga meeldib teie kommentaar, et kui inimesed kirjutavad oma definitsioone või metaandmeid, võib tekkida palju vigu. Ma tean, et ajakirjandusmaailmas on mantrat, et „paljud silmad teevad vigu vähe”, kuid kui rääkida praktilistest rakendustest, kipub küpsistepurgil liiga palju käsi jätma teile palju katkiseid küpsiseid, eks?
Eric Little: Jah ja mikroobe.
Rebecca Jozwiak: Jah. Sellega kavatsen ma edasi minna ja anda see edasi Malcolm Chisholmile. Malcolm, põrand on sinu oma.
Malcolm Chisholm: Tänan teid väga, Rebecca. Tahaksin natuke uurida, mida Eric on rääkinud, ja lisada veel mõned tähelepanekud, millele, teate, võiks Ronil ka reageerida, rääkides teemal “Ettevõtluspõhise andmearhitektuuri poole” ”- mida tähendab olla ettevõtluspõhine ja miks see on oluline? Või on see lihtsalt mingi hüpe vorm? Ma ei usu, et see nii on.
Kui me vaatame seda, mis pärast seda on toimunud, teate, suurarvutid said ettevõtetele tõesti kättesaadavaks - näiteks 1964. aasta paiku - tänapäevani, siis näeme, et seal on tehtud palju muutusi. Ja need muudatused võin kokku võtta kui nihke protsessikesksusest andmekesksusele. Ja see teebki ettevõtluspõhise andmearhitektuuri tänapäeval nii oluliseks ja asjakohaseks. Ja ma arvan, et te ei tea lihtsalt, et see on lihtsalt võlusõna, see on midagi tõeliselt tõelist.
Kuid me võime seda natuke rohkem hinnata, kui sukelduda ajalukku, nii et ajas tagasi minnes, tagasi 1960ndatesse ja mõnda aega hiljem, domineerisid suurarvutid. Seejärel andsid need teed personaalarvutitele, kus teie arvutisse sisenemisel olid kasutajad tegelikult mässanud. Mäss tsentraliseeritud IT vastu, kes nende arvates ei vastanud nende vajadustele, polnud piisavalt agarad. See tõi kiiresti kaasa hajutatud andmetöötluse, kui arvutid olid omavahel ühendatud. Ja siis hakkas toimuma Internet, mis hägustas ettevõtte piire - nüüd sai see andmevahetuse osas suhelda endaga väljaspool asuvate osapooltega, mida varem polnud toimunud. Ja nüüd oleme jõudnud pilve- ja suurandmete ajastusse, kus pilv on platvormid, mis tõepoolest tarbeks taristu muudavad ja seetõttu jätame IT-le vajaduse suurte andmekeskuste haldamiseks, sest teate, me Oleme pilve läbilaskevõime meile kättesaadavaks saanud ja käinud kaasas nende suurte andmetega, mida Eric on, teie teada, nii ilukõneliselt arutanud. Ja üldiselt, nagu näeme, kui tehnoloogia nihe toimus, on see muutunud andmekesksemaks, hoolime rohkem andmetest. Nagu ka Interneti puhul, kuidas andmeid vahetatakse. Suurte andmete korral on andmetest neli või enam v-d.
Samal ajal ja võib-olla veelgi olulisem - ärikasutuse juhtumid nihkusid. Kui arvutid esmakordselt kasutusele võeti, kasutati neid automatiseerida selliseid asju nagu raamatud ja dokumendid. Ja kõik, mis oli käsitsiprotsess, mis hõlmas pearaamatuid või midagi sellist, programmeeriti sisuliselt majas. See nihkus 80-ndatel operatsioonipakettide kättesaadavusele. Te ei pidanud enam oma palgaarvestust kirjutama, vaid võite osta midagi, mis seda tegi. Selle tulemuseks oli toona paljude IT-osakondade suur vähendamine või ümberkorraldamine. Kuid siis ilmus äriteave koos andmete ladudega, enamasti 90ndatel. Järgnesid dotcomi ärimudelid, mis olid muidugi suured meeletud. Siis MDM. MDM-iga näete, et me ei mõtle mitte automatiseerimisele; keskendume tegelikult lihtsalt andmete kureerimisele. Ja siis analüütika, mis tähistab väärtust, mille abil saate andmetest välja tulla. Ja analüütikas näete väga edukaid ettevõtteid, kelle põhiline ärimudel keerleb andmete ümber. Google oleks selles osa, kuid võite ka väita, et Walmart on.
Ja nii mõtleb ettevõte nüüd tõesti andmetele. Kuidas saaksime andmetest väärtust? Kuidas saavad andmed juhtida äri, strateegiat ja kuidas oleme andmete kuldajal. Arvestades seda, mis juhtub meie andmearhitektuuri osas, kui andmeid ei peeta enam pelgalt heitgaasideks, mis rakenduste tagaküljest välja tuleb, vaid mis on meie ärimudelites tõesti kesksel kohal? Noh, osa probleemist, mis meil on IT saavutamisel, on tõesti minevikus kinni süsteemide arendamise elutsüklist, mis oli tingitud sellest, et IT-varases eas tuli kiiresti selle protsessi automatiseerimisetapiga hakkama saada ja projektid on sarnane asi. Infotehnoloogiale - ja see on natuke karikatuur -, kuid ma üritan öelda, et mõned tõkked ettevõtluspõhise andmearhitektuuri saamisel on seetõttu, et me oleme omamoodi IT-alase kultuuri kriitiliselt aktsepteerinud. mis tuleneb möödunud ajastust.
Nii et kõik on projekt. Rääkige mulle oma vajadustest üksikasjalikult. Kui asjad ei toimi, siis sellepärast, et te ei öelnud mulle oma nõudeid. Noh, see ei tööta tänapäeval andmetega, kuna me ei alusta mitte automatiseeritud käsitsiprotsessidega ega äriprotsesside tehnilise muundamisega, vaid alustame väga sageli juba olemasolevate tootmisandmetega, mida proovime väärtusest välja saada. Kuid keegi, kes sponsoreerib andmekeskset projekti, ei saa nendest andmetest sügavuti aru. Peame tegema andmete avastamise, tegema lähteandmete analüüsi. Ja see ei vasta tegelikult süsteemiarendusele, teate - juga, SDLC elutsükkel - millest Agile, ma väidaksin, on omamoodi parem versioon sellest.
Ja millele keskendutakse, on tehnoloogia ja funktsionaalsus, mitte andmed. Näiteks kui me katsetame testimisetapis, siis tavaliselt toimib see minu funktsionaalsus, ütleme näiteks minu ETL, kuid me ei katseta andmeid. Me ei testi oma eeldusi sissetulevate lähteandmete kohta. Kui me seda teeksime, oleksime võib-olla paremas vormis ja oleksin tänulik, kui keegi teine, kes on teinud andmelao projekte ja kannatanud ülesvoolu tehtavate muudatuste tõttu ja põrkas mu ETL-id üle. Ja tegelikult on see, mida me tahame näha, testimine kui eelnev samm pideva tootmisandmete kvaliteedi jälgimise poole. Nii et meil on siin palju hoiakuid, kus ettevõtluspõhist andmearhitektuuri on keeruline saavutada, kuna meid tingib protsessikesksuse ajastu. Peame tegema ülemineku andmekesksusele. Ja see ei ole täielik üleminek, teate, seal on veel palju protsessi ära teha, kuid me ei mõtle tegelikult andmekesksuses, kui vaja, ja asjaoludele, mis tekivad siis, kui oleme tegelikult kohustatud seda tegema.
Nüüd saavad ettevõtted aru andmete väärtusest, nad tahavad andmed lahti võtta, siis kuidas me seda teeme? Kuidas me siis üleminekut teeme? Panime andmed arenguprotsesside keskmesse. Ja me laseme ettevõttel juhinduda teabenõuetega. Ja me mõistame, et keegi ei mõista projekti alguses olemasolevaid lähteandmeid. Võite väita, et andmestruktuur ja andmed ise said sinna vastavalt infotehnoloogia ja toimingute kaudu, nii et me peaksime seda teadma, kuid tegelikult me seda ei tee. See on andmekeskne areng. Seega peame mõeldes, kus me töötame ja kuidas andmemudelit andmekeskses maailmas modelleerime, peavad meil olema kasutajatele tagasiside andmise lingid nende teabenõuete täpsustamiseks, kuna teeme andmete otsimist ja profileerimist , näete lähteandmete analüüsi ja kuna järk-järgult saame oma andmete suhtes üha enam kindlust. Ja nüüd ma räägin traditsioonilisemast projektist, nagu MDM-jaotur või andmeladu, mitte tingimata suurandmete projektidest, ehkki see on minu arvates endiselt üsna lähedal sellele. Ja nii hõlmavad need tagasisideahelad ka andmeside modelleerijaid, edendades järk-järgult oma andmemudelit ja suheldes kasutajatega, et veenduda, et teabenõudeid täpsustatakse vastavalt sellele, mis on võimalik, mis on saadaval, lähteandmete põhjal, kuna nad saavad sellest paremini aru, seega see ei kehti enam juhul, kui andmemudel on olukorras, mida seal pole või mis on täielikult valmis, see on järk-järguline fookus.
Samamoodi on ka tagantjärgi kvaliteeditagamine, kus töötame välja andmete kvaliteedi testimise reeglid, veendumaks, et andmed vastavad parameetritele, mille kohta me eeldusi teeme. Sisse minnes viitas Eric viiteandmete muutustele, mis võivad juhtuda. Te ei soovi, nagu oleks, selles valdkonnas mingisuguste haldamatute muudatuste alljärgnev ohver, nii et kvaliteeditagamise reeglid võivad minna tootmise järgsesse pidevasse andmete kvaliteedi jälgimisse. Nii et võite hakata nägema, kas me hakkame olema andmekesksed, kuidas me andmekeskset arendust teeme, erineb see funktsionaalsusel põhineva SDLC ja Agile puhul üsna erinevalt. Ja siis peame pöörama tähelepanu ka ärivaadetele. Meil on - ja see kordab jälle seda, mida Eric ütles - meil on andmemudel, mis määratleb meie andmebaasi jaoks andmestiku sinise, kuid samal ajal vajame neid kontseptuaalseid mudeleid, neid ärivaateid andmetest, mida traditsiooniliselt ei tehtud minevik. Mõnikord oleme arvanud, et andmemudel saab selle kõigega hakkama, kuid meil peab olema kontseptuaalne vaade, semantika ja uurima andmeid, et need saaks esitada abstraktsioonikihi kaudu, mis tõlgib salvestusmudeli ettevõttesse vaade. Ja jälle, kõik asjad, millest Eric semantika osas rääkis, muutuvad selle jaoks oluliseks, nii et tegelikult on meil täiendavaid modelleerimisülesandeid. Arvan, et see on huvitav, kui olete üles astunud andmemudelisena nagu mina, ja jällegi midagi uut.
Ja lõpetuseks tahaksin öelda, et ka suurem arhitektuur peab kajastama seda uut reaalsust. Näiteks traditsiooniline kliendi MDM on omamoodi, okei, viige meie kliendiandmed keskusesse, kus saame, tead, seda mõistlikuks, pidades silmas taga kontorirakenduste tõeliselt õiglast andmete kvaliteeti. Mis äristrateegia vaatenurgast on omamoodi kära. Täna vaatame aga klientide MDM-jaotureid, kus neis on täiendavaid kliendi profiiliandmeid, mitte ainult staatilisi andmeid, millel siis tegelikult on kahesuunaline liides kliendi tehingurakendustega. Jah, nad toetavad endiselt tagakontorit, kuid nüüd teame ka meie klientide sellisest käitumisest. Selle ehitamine on kallim. Selle ehitamine on keerulisem. Kuid see on suunatud ettevõtlusele viisil, milles traditsiooniline klient MDM pole. Olete orienteerunud ettevõttele lihtsamate disainilahenduste vastu, mida on lihtsam rakendada, kuid ettevõtte jaoks on see just see, mida nad tahavad näha. Oleme tõesti uues ajajärgus ja arvan, et ettevõtluse edendamise andmearhitektuurile peame vastama mitmel tasandil ja minu arvates on asjade ajamine väga põnev aeg.
Nii et tänan teid, Rebecca.
Rebecca Jozwiak: Tänan Malcolmi ja mulle väga meeldis, mida te ütlesite andmemudelite kohta, et see peaks toetama ärivaadet, sest erinevalt sellest, mida te ütlesite, kus IT hoidis nii kaua ohutust ja see pole lihtsalt enam selline juhtum, ning et kultuur peab nihkuma. Ja ma olen üsna kindel, et taustal oli koer, kes oli sinuga 100% nõus. Ja koos sellega annan palli Ronile. Mul on väga hea meel näha teie demo. Ron, põrand on sinu oma.
Ron Huizenga: Tänan teid väga ja enne kui me sellesse süveneme, siis käin läbi mõned slaidid ja siis natuke demo, sest nagu Eric ja Malcolm on märkinud, on see väga lai ja sügav teema ning koos sellega Täna räägime, et me kraapime lihtsalt selle pinda, sest seal on nii palju aspekte ja nii palju asju, mida peame tõesti arvestama ja ettevõttest lähtuva arhitektuuri järgi vaatama. Ja meie lähenemisviis on muuta see mudelipõhine ja saada mudelitest tõeline väärtus, kuna saate neid kasutada nii kommunikatsioonivahendina kui ka kihina teiste süsteemide lubamiseks. Ükskõik, kas teete teenusele orienteeritud arhitektuuri või muid asju, saab mudel tõepoolest toimuva elujõuks koos kõigi selle ümber olevate metaandmete ja teie ettevõttes sisalduvate andmetega.
See, millest tahan rääkida, on aga peaaegu selle sammu tagasiminek, sest Malcolm oli puudutanud lahenduste kujunemise ajalugu ja seda tüüpi asju. Üks viis, kuidas tõestada, kui oluline on usaldusväärse andmearhitektuuri olemasolu, on kasutusjuhtum, millega sattusin enne tootehalduse rolli asumist väga tihti kokku, kui konsulteerisin, ja see tähendab, et astuksin organisatsioonidesse kas nad tegid ümberkujundamist ettevõttes või lihtsalt asendasid mõnda olemasolevat süsteemi ja seda tüüpi asju, ja selgus väga kiiresti, kui halvasti organisatsioonid mõistavad nende endi andmeid. Kui võtate mõne konkreetse juhtumi, näiteks selle, kas olete konsultant, kes tööle asub, või võib-olla on tegemist inimesega, kes on just asutanud organisatsiooni, või on teie organisatsioon aastate jooksul üles ehitatud erinevate ettevõtete omandamisel, siis millega te lõpetate koos on väga keerukas keskkond, kus on palju uusi erinevaid tehnoloogiaid, aga ka pärandtehnoloogia, ERP-lahendused ja kõik muu.
Nii et üks asi, mida me oma modelleeriva lähenemisega tõesti ära teha saame, on vastata küsimusele, kuidas ma seda kõike mõistan? Saame tõesti hakata teavet koondama, nii et ettevõte saab kasutada meie olemasolevat teavet. Ja tuleb välja, mis on see, mis meil seal keskkonnas on? Kuidas saan mudeleid kasutada vajaliku teabe väljajuurimiseks ja selle teabe paremaks mõistmiseks? Ja siis on meil kõigi erinevate asjade jaoks metaandmete traditsioonilised tüübid, näiteks relatsioonilised andmemudelid, ja oleme harjunud nägema näiteks määratlusi ja andmesõnastikke, teate, andmetüüpe ja seda tüüpi asju. Aga kuidas oleks lood täiendavate metaandmetega, mida soovite jäädvustada, et sellele tõesti veelgi rohkem tähendust anda? Näiteks, millised üksused on tegelikult kandidaadid, mis peaksid olema võrdlusandmeobjektid, mis peaksid olema põhiandmehaldusobjektid ja seda tüüpi asjad ning need omavahel siduma. Ja kuidas teave organisatsiooni kaudu voolab? Andmete voog sõltub sellest, kuidas neid tarbitakse, nii protsessi vaatepunktist, kui ka andmete liini osas, mis puudutab teabe rändamist läbi meie ettevõtete ja kuidas see toimub erinevate süsteemide kaudu või andmehoidlate kaudu, nii et me teame I-lahenduste või seda tüüpi asjade ehitamisel tarbime tegelikult käepärase ülesande jaoks õiget teavet.
Ja siis on väga oluline, kuidas saaksime kõik need sidusrühmad ja eriti ettevõtjate sidusrühmad koostööd tegema, sest just nemad annavad meile nende andmete tõelise tähenduse. Andmed on päeva lõpus ettevõttele. Nad esitavad sõnavara ja asjade definitsioonid, millest Eric rääkis, seega vajame kohta, kus kõik see omavahel siduda. Ja kuidas me seda teeme, on meie andmemudelite ja andmehoidlate arhitektuuride kaudu.
Ma puudutan mõnda asja. Ma räägin ER / Studio Enterprise Team Editionist. Peamiselt räägin ma andmearhitektuuri tootest, kus me modelleerime andmetöötlust ja seda tüüpi asju, kuid komplektis on veel palju muid komponente, mida ma puudutan väga lühidalt. Näete ühte fragmenti äriarhitektist, kus saame teha kontseptuaalseid mudeleid, kuid võime teha ka äriprotsessimudeleid ja saame need protsessimudelid siduda, et siduda tegelikud andmed, mis meil andmemudelites on. See aitab meil seda lipsu kokku viia. Tarkvaraarhitekt võimaldab meil teha täiendavaid konstruktsioone, näiteks mõnda UML-i modelleerimist ja seda tüüpi asju, et anda toetavat loogikat mõnele neist muudest süsteemidest ja protsessidest, millest me räägime. Kuid väga oluline on, et kolides on meil hoidla ja meeskonnaserver ning ma räägin sellest sama asja kahest poolest. Hoidlas hoiame kõiki modelleeritud metaandmeid, aga ka kõiki ettevõtte metaandmeid ärisõnastike ja terminite osas. Ja kuna meil on see hoidlatepõhine keskkond, saame siis kõik need erinevad asjad samasse keskkonda õmmelda ja siis saame need teha tarbimiseks kättesaadavaks mitte ainult tehnilistele inimestele, vaid ka ärimeestele. Ja just nii hakkame koostööd tegema.
Ja siis viimane tükk, millest lühidalt räägin, on see, et kui neisse keskkondadesse sisse kõndida, pole tegemist ainult andmebaasidega, mis teil seal on. Teil on arvukalt andmebaase, andmehoidlaid, teil on ka palju pärandlikke esemeid, mida ma nimetaksin. Võib-olla on inimesed mõne asja kaardistamiseks kasutanud Visio või muid diagramme. Võib-olla on neil olnud muid modelleerimisvahendeid ja seda tüüpi asju.See, mida me MetaWizardiga teha saame, on tegelikult osa sellest teabest kaevandada ja tuua see meie mudelitesse, muuta see ajakohaseks ja kasutada seda, seda tarbida, taas praegusel viisil, selle asemel, et lihtsalt seal väljas istuda. Nüüd muutub see meie töötavate mudelite aktiivseks osaks, mis on väga oluline.
Kui sisenete organisatsiooni, nagu ma ütlesin, on seal palju erinevaid süsteeme, palju ERP-lahendusi, sobimatud osakondade lahendused. Paljud organisatsioonid kasutavad ka SaaS-lahendusi, mis on ka väliselt kontrollitavad ja hallatavad, nii et me ei kontrolli andmebaase ja seda tüüpi asju hostides neis, kuid peame siiski teadma, millised need andmed välja näevad, ja muidugi, selle ümber olevad metaandmed. Samuti leiame palju vananenud pärandsüsteeme, mida pole Malcolmist rääkinud projektipõhise lähenemisviisi tõttu puhastatud. On hämmastav, kuidas viimastel aastatel organisatsioonid projektid käivitavad, nad süsteemi või lahenduse asendavad, kuid vananenud lahenduste dekomisjoneerimiseks ei ole sageli piisavalt projekti eelarvet, nii et nüüd on nad lihtsalt teel. Ja me peame välja mõtlema, millest saaksime oma keskkonnas tegelikult vabaneda, ja sellest, mis on edaspidiseks kasulik. Ja see seostub kehva dekomisjoneerimise strateegiaga. See on lahutamatu osa samast asjast.
Mida me ka leiame, kuna paljudest organisatsioonidest on üles ehitatud kõik need erinevad lahendused, kas me näeme paljudes punktides liideseid, kus paljudes kohtades liigub palju andmeid. Peame suutma seda ratsionaliseerida ja välja mõtlema selle andmeliini, mida ma varem lühidalt mainisin, et meil oleks õigema teabe edastamiseks ühtsem strateegia, näiteks teenustele orienteeritud arhitektuuri, ettevõtte teenindusbusside ja seda tüüpi asjade kasutamine avaldamis- ja tellimustüübile, mida me kogu oma äritegevuses õigesti kasutame. Ja siis peame muidugi veel mingisugust analüüsi tegema, olgu selleks siis andmelaod, traditsiooniliste ETL-idega andmekaardid või mõned uued andmejärved. Kõik taandub ühele ja samale asjale. See on kõik andmed, olgu tegemist suurandmetega, olenemata sellest, kas tegemist on traditsiooniliste andmetega relatsiooniandmebaasides. Peame kõik need andmed kokku viima, et saaksime neid hallata ja oleksime kursis oma mudelitega.
Jällegi, keeruliseks peame seda, et meil on mitmeid samme, mida tahame teha. Esiteks kõnnite sisse ja teil ei pruugi olla neid siniseid, kuidas see infomaastik välja näeb. Andme modelleerimise tööriistas, nagu ER / Studio Data Architect, teete esmalt palju pöördprojekteerimist, osutades seal olevatele andmeallikatele, viies need sisse ja õmmeldes need seejärel esinduslikumaks mudelid, mis esindavad kogu ettevõtet. Oluline on see, kas tahame neid mudeleid ka ärivaldkondade kaupa lagundada, et saaksime neid käsitleda väiksemates tükkides, millega meie ärimehed võivad samuti suhelda, ning meie ärianalüütikute ja muude sidusrühmadega, kes töötavad selle kallal.
Nimetuse standardid on äärmiselt olulised ja ma räägin sellest siin paaril moel. Standardite nimetamine selles osas, kuidas me oma mudelites asju nimetame. Seda on üsna lihtne teha loogilistes mudelites, kus meil on oma nimede jaoks hea nimetamismeetod ja hea andmestikku sisaldav sõnastik, kuid ka paljudele nendele füüsilistele mudelitele, mida me toome, näeme erinevaid nimetamise tavasid. pöördtehnik, üsna sageli näeme lühendatud nimesid ja seda tüüpi asju, millest ma räägin. Ja peame tõlkima need tähendusrikkad ingliskeelsed nimed, mis on ettevõttele tähenduslikud, et saaksime aru, mis need kõik andmed meie keskkonnas on. Ja siis me õmbleme need omavahel kokku universaalsed kaardistused.
Lisaks dokumenteeriksime ja määratleksime edasi ning selles osas saaksime oma andmeid liigitada nn manustega, mida ma näitan teile paaril slaidil. Ja siis silmuse sulgedes tahame rakendada seda äritegevuse tähendust, mis on see, kus me seome oma ärisõnastikud ja saame neid siduda meie erinevate mudelite artefaktidega, nii et teame, kui räägime teatud äriterminist, kus see on rakendatud meie andmetes kogu organisatsioonis. Ja lõpuks, ma olen juba rääkinud tõsiasjast, et meil on vaja, et see kõik oleks hulgaliselt koostöö- ja avaldamisvõimalustega hoidlatepõhine, et meie sidusrühmad saaksid seda kasutada. Ma räägin pöördprojekteerimisest üsna kiiresti. Olen teile juba omamoodi andnud selle kiiret esiletõstmist. Ma näitan teile seda reaalajas demos, lihtsalt selleks, et näidata teile mõnda asja, mida me saame sinna tuua.
Ja ma tahan rääkida mõnest erinevast mudelitüübist ja skeemist, mille me seda tüüpi stsenaariumi korral tooksime. Ilmselt teeme kontseptuaalseid mudeleid paljudel juhtudel; Ma ei kavatse sellele palju aega kulutada. Ma tõesti tahan rääkida loogilistest mudelitest, füüsilistest mudelitest ja spetsialiseeritud tüüpidest, mida saame luua. Ja on oluline, et saaksime need kõik luua samal modelleerimisplatvormil, et saaksime need kokku õmmelda. See hõlmab mõõtmetega mudeleid ja ka mudeleid, mis kasutavad mõnda uut andmeallikat, näiteks NoSQL, mida ma teile näitan. Ja kuidas siis andmeliini mudel välja näeb? Ja kuidas me need andmed äriprotsessimudelisse õmbleme, sellest räägime järgmisena.
Kavatsen siin minna üle modelleerimiskeskkonnale lihtsalt selleks, et anda teile väga kõrge ja kiire ülevaade. Ja ma usun, et te peaksite nüüd mu ekraani nägema. Kõigepealt tahan rääkida lihtsalt traditsioonilisest tüüpi andmemudelist. Ja kuidas me tahame mudeleid nende sissetoomisel korraldada, tahame neid lagundada. Mida te siin vasakpoolsest küljest näete, on see, et selles konkreetses mudelifailis on loogilised ja füüsilised mudelid. Järgmine asi on see, kas suudame selle ettevõtte lagunemisel jaotada, nii et näete kaustu. Helesinised on loogilised mudelid ja rohelised on füüsilised mudelid. Ja me võime ka põhjalikumalt läbi vaadata, nii et ER / Stuudios saate ettevõtte lagunemise korral minna nii paljudele sügavustele või alammudelitele kui soovite, ja madalamatel tasemetel tehtud muudatused kajastuvad automaatselt kõrgemal taset. Nii et sellest saab väga kiiresti väga võimas modelleerimiskeskkond.
Midagi, millele tahan ka tähelepanu juhtida, on väga oluline hakata seda teavet koondama, on see, et meil võib olla mitu füüsilist mudelit, mis vastavad ka ühele loogilisele mudelile. Üsna sageli võib teil olla loogiline mudel, kuid teil võivad olla füüsilised mudelid erinevatel platvormidel ja seda tüüpi asi. Võib-olla üks on selle SQL Serveri eksemplar, võib-olla teine Oracle'i eksemplar. Meil on võimalus siduda kõik see samasse modelleerimiskeskkonda. Ja jälle on mul siin tegemist tegeliku andmelao mudeliga, mis võib jällegi olla samas modelleerimiskeskkonnas või kui meil on see hoidlas ja saab seda ka erinevatesse asjadesse siduda.
Mida ma tõesti tahtsin teile selles näidata, on mõned muud asjad ja muud mudelite variandid, millega me kokku puutume. Niisugusesse traditsioonilisse andmemudelisse sattudes oleme harjunud nägema tüüpilisi üksusi veergude ja metaandmetega ning seda tüüpi asju, kuid see vaade muutub väga kiiresti, kui hakkame tegelema mõne sellise uuema NoSQL-tehnoloogiaga või nagu mõnele inimesele ikka meeldib neile helistada, suurandmete tehnoloogia.
Ütleme nüüd nii, et ka meie keskkonnas on taru. Kui me tarukeskkonnast inseneri tagasi saame ja taru edasi ja tagasi saame just selle sama modelleerimisriistaga -, näeme midagi, mis on natuke teistsugune. Näeme seal endiselt kõiki andmeid konstruktidena, kuid meie TDL on erinev. Need, kes olete harjunud SQL-i nägema, näeksite praegu Hive QL-i, mis on väga SQL-i moodi, kuid samast tööriistast, millega nüüd saate hakata tegelema erinevate skriptikeeltega. Nii saate selles keskkonnas modelleerida, taru keskkonda genereerida, kuid sama oluline on ka minu kirjeldatud stsenaariumi korral, et saaksite selle kõik ümber kujundada ja selle mõistma hakata ning hakata seda ka omavahel kokku õmblema. .
Võtame veel ühe, mis on natuke teistsugune. MongoDB on veel üks platvorm, mida me ise loomulikult toetame. Ja kui hakkate sattuma JSON-tüüpi keskkondadesse, kus teil on dokumendipoode, on JSON erinev loom ja selles on konstruktsioone, mis ei vasta relatsioonimudelitele. Kui hakkate JSON-i ülekuulama, hakkate varsti tegelema selliste mõistetega nagu manustatud objektid ja manustatud objektide massiivid, kui neid mõisteid traditsioonilises relatsioonimärgistuses ei eksisteeri. Mida me siin teinud oleme, oleme tegelikult märget ja kataloogi laiendanud, et saaksime seda ka samas keskkonnas käsitleda.
Kui vaatate siin vasakul üle, nimetame objektide ja tabelite nägemise asemel objekte. Ja näete erinevaid märkusi. Näete siin endiselt tüüpilisi viitemärke, kuid need sinised üksused, mida sellel konkreetsel diagrammil näitan, on tegelikult manustatud objektid. Ja me näitame erinevaid kardinaalsusi. Teemantkardinaalsus tähendab, et see on objekt ühest otsast, kuid ühe kardinaalsus tähendab, et kui avaldaja seda suhet jälgib, on meil manustatud aadressiobjekt. JSON-i ülekuulamisel leidsime, et see on täpselt sama objektide struktuur, mis on manustatud patroonile, kuid see on tegelikult manustatud objektide massiivi. Me näeme seda mitte ainult konnektorite kaudu, vaid ka siis, kui vaatate tegelikke olemeid, näete, et te näete patrooni all aadresse, mis on klassifitseeritud ka objektide hulgaks. Saate väga kirjeldava vaatepunkti, kuidas seda sisse viia.
Ja jälle, nüüd on vaid mõne sekundi jooksul seni nähtud traditsioonilised relatsioonimudelid, mis on mitmetasandilised, saame sama teha Hive'iga, sama teha MongoDB-ga ja muude suurte andmeallikatega nagu noh. Mida me ka teha saame ja ma näitan teile seda lihtsalt väga kiiresti, rääkisin asjade toomisega muudest erinevatest piirkondadest. Ma eeldan, et impordin mudeli andmebaasist või pöördprojekteerin selle, kuid kavatsen selle tuua sisse välistest metaandmetest. Lihtsalt selleks, et anda teile väga kiire ülevaade erinevatest asjadest, mida me saame sisse tooma.
Nagu näete, on meil hulgaliselt asju, millega saaksime metaandmed tegelikult oma modelleerimiskeskkonda tuua. Alustades sellistest asjadest nagu Amazon Redshift, Cassandra, paljude teiste suurte andmesideplatvormidega, nii et näete neid loendites palju. Seda tähestikulises järjekorras. Me näeme palju suuri andmeallikaid ja seda tüüpi asju. Samuti näeme palju traditsioonilisi või vanemaid modelleerimiskeskkondi, mille kaudu me metaandmeid saame. Kui ma siit läbi käin - ja ma ei kavatse igaühele neist aega kulutada -, näeme me palju erinevaid asju, mida me selle platvormide ja andmeplatvormide modelleerimiseks võime tuua. Ja see, mis on siinjuures väga oluline, on veel üks osa, mida saame teha, kui hakkame rääkima andmeliigist. Enterprise Team Editionis saame üle kuulata ka ETL-i allikaid, olgu tegemist näiteks Talendi või SQL Serveri infoteenuste kaardistustega, mida me saame teha. tegelikult viige see sisse ka meie andmeliiniskeemide käivitamiseks ja joonistage pilt nendes teisendustes toimuvast. Kokku on meil karbist üle 130 sellise erineva silla, mis on tegelikult Enterprise Team Editioni toote osa, nii et see aitab meil tõesti kõik esemed väga kiiresti kokku koondada ühte modelleerimiskeskkonda.
Ja viimane, kuid mitte vähem tähtis, tahan rääkida ka asjaolust, et me ei tohi unustada tõsiasja, et vajame muud tüüpi konstruktsioone, kui tegeleme andmete ladustamisega või mis tahes tüüpi analüütikaga. Ikka tahame, et meil oleks võimalus teha selliseid asju nagu dimensioonimudelid, kus meil on faktabelid ja dimensioonid ning seda tüüpi asjad. Üks asi, mida tahan teile ka näidata, on see, et meil on ka metaandmete laiendusi, mis aitavad meil kategoriseerida, mis on mõõdutüübid ja kõik muu. Nii et kui ma vaatan siin näiteks ühte neist mõõtmete andmete vahekaardist, tuvastab see tegelikult tema nähtaval mudelimustril põhineva automaatselt ja annab teile lähtepunkti, kas tema arvates on see mõõde või faktabel. Kuid peale selle on see, mida me teha saame, mõõtmete piires ja seda tüüpi asjadel on meil isegi erinevat tüüpi mõõtmeid, mida saame kasutada andmete klassifitseerimiseks ka andmelao tüüpi keskkonnas. Nii võimsad võimalused, millega me selle õmbleme.
Ma lähen selle juurde, kuna olen praegu demokeskkonnas ja näitan teile enne slaidide juurde tagasi minemist veel mõnda asja. Üks asi, mille oleme hiljuti lisanud ER / Studio Data Architect, on see, et oleme sattunud olukordadesse - ja see on projektide kallal väga tavaline kasutusjuht - arendajad mõtlevad objektide osas, samas kui meie andmed modelleerijad kipuvad mõtlema tabelite ja olemite ning seda tüüpi asjade osas. See on väga lihtsustatud andmemudel, kuid see esindab mõnda põhimõistet, kus arendajad või isegi ärianalüütikud või ärikasutajad võiksid neid mõelda erinevate objektide või ärikontseptsioonidena. Siiani on neid olnud väga raske klassifitseerida, kuid mida me oleme teinud 2016. aasta väljaandes ER / Studio Enterprise Team Editioni raames, kas meil on nüüd kontseptsioon nimega Business Data Objects. Ja mis võimaldab meil seda teha, see võimaldab meil kapseldada üksuste rühmad või tabelid tõelisteks äriobjektideks.
Näiteks, mis meil siin uues vaates on, on ostutellimuse päis ja tellimuste rida on nüüd kokku koondatud, need on kapseldatud kui objekt, arvaksime neid andmete säilitades tööühikuna ja koondame nad kokku, nii et seda on nüüd väga lihtne erinevate sihtrühmadega siduda. Neid saab kogu modelleerimiskeskkonnas korduvalt kasutada. Need on tõeline objekt, mitte ainult joonistuskonstruktsioon, kuid meil on ka eelis, et tegelikult modelleerimise vaatenurgast suheldes saame need valikuliselt kokku kukkuda või laiendada, et saaksime kokkuvõtliku vaate luua dialoogi pidamiseks teatud sidusrühmadega, ja muidugi võime ka suurema tehnilise vaatajaskonna jaoks säilitada üksikasjalikuma ülevaate, nagu näeme siin. See annab meile tõesti väga hea suhtlusvahendi. See, mida me praegu näeme, on mitme erineva mudeli tüübi ühendamine, täiendamine neid äriandmeobjektide mõistega ja nüüd ma räägin sellest, kuidas me seda tüüpi asjadele tegelikult veel mõnda tähendust rakendame ja kuidas me need oma üldine keskkond.
Üritan lihtsalt oma WebExi siit üles leida, et saaksin seda teha. Ja sinna me läheme, tagasi Hot Tech'i slaidide juurde. Kiirendan siin lihtsalt paari slaidi edasi, kuna olete neid juba mudellemonstratsioonis ise näinud. Tahan standardite nimetamisest väga kiiresti rääkida. Tahame rakendada erinevaid nimestandardeid ja jõustada neid. Mida me tahame teha, on see, et meil on reaalselt võimalik oma hoidlates nimetamisstandardite malle salvestada, et põhimõtteliselt seda tähendust sõnade või fraaside või isegi lühendite abil üles ehitada ja siduda need tähendusliku ingliskeelse sõnatüübiga. Me hakkame kasutama äritermineid, nende lühendeid ja saame täpsustada tellimuse, juhtumid ning lisada prefiksid ja järelliited. Tüüpiline kasutusjuhtum on see tavaliselt siis, kui inimesed on loonud loogilise mudeli ja siis tegelikult kavatsevad luua füüsilise mudeli, kus nad võisid kasutada lühendeid ja kõike muud.
Ilus asi on see, et see on sama võimas, veelgi võimsam vastupidine, kui me saame lihtsalt öelda, millised olid mõned nimestandardid mõnes füüsilises andmebaasis, mille oleme ümber ehitanud, võime võtta need lühendid, muuta need pikemaks sõnu ja viige need tagasi ingliskeelsetesse fraasidesse. Nüüd saame tegelikult tuletada õigeid nimesid sellele, kuidas meie andmed välja näevad. Nagu ma ütlen, on tüüpiline kasutusjuhtum edasi liikuda, loogiliselt füüsiliseks ja kaardistada andmesalved ja seda tüüpi asjad. Kui vaatate ekraanipilti paremal, näete, et lähtenimedest on lühendatud nimesid ja kui oleme rakendanud nimetamisstandardite malli, on meil tegelikult rohkem täisnimesid. Ja kui tahame, võiksime tühikud ja kõik muu taolise sisestada, sõltuvalt kasutatavatest nimetamisstandardite mallidest. Saame selle välja nägema, aga tahame, et see ka meie mudelitesse tooks. Alles siis, kui saame teada, mida millekski nimetatakse, saame sellele tegelikult määratlusi lisama hakata, sest kuidas me saame sellele tähendust rakendada, kui me ei tea, mis see on?
Tore asi on see, kas me saame sellele ka kõikvõimalikke asju tehes tugineda. Rääkisin pöördprojekteerimisest. Pöördprojekteerimisel saame tegelikult nimetamisstandardite malle kutsuda samaaegselt. Nõustaja kaudu ühe sammuna saame teha, kui teame, millised on konventsioonid, füüsilise andmebaasi insenerprojekteerida, see tuuakse modelleerimiskeskkonnas füüsiliste mudelitena tagasi ja see on rakendades ka neid nimetamiskonventsioone. Nii näeme, millised on nimede ingliskeelsed esindused keskkonnas vastavas loogilises mudelis. Saame seda ka teha ja kombineerida XML-skeemi genereerimisega, et saaksime võtta mudeli ja isegi lühendada seda oma lühenditega, olgu siis tegemist SOA raamistike või seda tüüpi asjadega, et saaksime siis välja lükata ka erinevad nimetamismeetodid mille oleme tegelikult mudelisse ise salvestanud. See annab meile palju väga võimsaid võimalusi.
Siin on jällegi näide sellest, kuidas see näeks välja, kui mul oleks mall. See näitab tegelikult, et mul oli nimetamisstandardite konventsioonis EMP töötaja jaoks, SAL palgale ja PLN plaanile PLN. Saan neid kasutada ka interaktiivsel käitamisel, kui ma konstrueerin mudeleid ja panen asju sisse. Kui kasutaksin seda lühendit ja kirjutaksin üksuse nimele „Töötaja palgaplaan”, toimiks see nimetamisstandardite malliga Nagu ma siin määratlenud olen, oleks see olemite loomisel andnud mulle kohe EMP_SAL_PLN ja andnud mulle kohe vastavad füüsilised nimed.
Jällegi, väga hea, kui projekteerime ja arendame ka tehnikat. Meil on väga ainulaadne kontseptsioon ja just siin hakkame neid keskkondi omavahel kokku viima.Ja seda nimetatakse universaalseks kaardistamiseks. Kui oleme kõik need mudelid oma keskkonda toonud, mida me suudame teha, eeldades, et oleme nüüd neid nimetamismeetodeid rakendanud ja neid on lihtne leida, saame nüüd ER-is kasutada konstruktsiooni nimega Universal Mappings. / Stuudio. Saame siduda üksusi mudelite vahel. Kus iganes me näeme “klienti” - tõenäoliselt on meil “klient” paljudes erinevates süsteemides ja paljudes erinevates andmebaasides -, saame hakata kõiki neid omavahel siduma, nii et kui töötan sellega ühes mudelis saab näha, kus on muudes klientides esinevad ilmingud. Ja kuna meil on seda mudelikihti esindav, saame selle isegi siduda andmeallikatega ja viia selle meie kasutatavate päringute juurde, millistes andmebaasides need asuvad. See annab meile võimaluse siduda see kõik omavahel väga sidusalt.
Ma näitasin teile ettevõtte andmeobjekte. Samuti tahan väga kiiresti rääkida metaandmete laienditest, mida kutsume manusteks. See aga annab meile võimaluse luua oma mudeiobjektide jaoks täiendavaid metaandmeid. Üsna sageli seadsin ma seda tüüpi atribuudid andmehalduse ja andmete kvaliteedi vaatenurgast välja palju erinevaid asju ning aitamaks meid ka põhiandmete haldamisel ja andmete säilitamise poliitikates. Põhiidee on see, et loote need klassifikaatorid ja saate need kinnitada kuhu iganes soovite, tabeli ja veeru tasemel seda tüüpi asju. Kõige tavalisem kasutusjuhtum on muidugi see, et üksused on tabelid ja siis saan ma määratleda: mis on minu põhiandmeobjektid, mis on minu viidetabelid, millised on minu tehingustabelid? Andmekvaliteedi seisukohast saan klassifitseerida ettevõtte jaoks olulisuse järgi, et saaksime andmete puhastamise ja seda tüüpi asjade tähtsuse järjekorda seada.
Mida sageli tähelepanuta jäetakse, on see, mis on meie organisatsiooni eri tüüpi andmete säilitamispoliitika? Saame need üles seada ja tegelikult saame neid siduda erinevat tüüpi teabeartiklitega meie modelleerimiskeskkonnas ja muidugi ka meie hoidlas. Ilu on see, kas need manused asuvad meie andmesõnastikus, nii et kui me kasutame keskkonnas ettevõtte andmete sõnastikke, saame need manustada mitmele mudelile. Peame need määratlema ainult üks kord ja saame neid ikka ja jälle oma keskkonna eri mudelites kasutada. See on lihtsalt kiire ekraanipilt, mis näitab, et saate tegelikult manuse määramisel täpsustada, milliste tükkidega soovite seda manustada. Ja see näide siin on tegelikult väärtuste loend, nii et kui need sisse lähevad, saate valida väärtuste loendist, siis saate modelleerimiskeskkonnas palju kontrollida, mida valitakse, ja saate isegi seada, mis on vaikimisi väärtus on siis, kui väärtust ei valitud. Nii palju jõudu seal. Nad elavad andmesõnastikus.
Midagi, mida ma tahan teile sellel ekraanil pisut kaugemal näidata, lisaks näete manuseid, nagu ülaosas, selle all näete andmete turvalisuse teavet. Andmeturbepoliitikaid saame tegelikult rakendada ka keskkonna eri teabele. Erinevate vastavuskaardistuste, andmeturbe klassifikaatorite jaoks saadame mitu neist karbist, mida saate lihtsalt genereerida ja kasutama hakata, kuid saate määratleda ka oma vastavuskaardistused ja standardid. Ükskõik, kas teete HIPAA-d või mõnda muud seal pakutavat algatust. Ja võite tõesti hakata seda väga rikkalikku metaandmete komplekti oma keskkonnas üles ehitama.
Ja siis sõnastik ja terminid - see on see, kuhu äriline tähendus on seotud. Meil on üsna sageli olemas andmete sõnastikke, mida organisatsioon kasutab sageli lähtepunktina sõnastike väljaajamiseks, kuid terminoloogia ja sõnamõte on sageli väga tehniline. Mida me teha saame, on see, et saame soovi korral kasutada neid sõnastike koostamiseks lähtepunktina, kuid me tõesti tahame, et ettevõte omaks neid. See, mida me meeskonna serveri keskkonnas oleme teinud, on see, et oleme andnud inimestele võimaluse luua ettevõtte määratlusi ja seejärel saame neid siduda erinevate mudeli artefaktidega, millele nad vastavad ka modelleerimiskeskkonnas. Tunnistame ka punkti, millest varem räägiti: mida rohkem inimesi kirjutate, seda suurem on inimlike eksimuste potentsiaal. Mida me oma sõnastiku ülesehituses ka teeme, on see, et toetame sõnastike hierarhiat, nii et organisatsioonis võivad olla erinevad sõnastiku tüübid või eri tüüpi asjad, kuid sama oluline on see, kui teil on mõni neist allikatest juba olemas seal, kus on olemas terminid ja kõik määratletud, saame tegelikult CSV-faili importida, et tõmmata need meie modelleerimiskeskkonda ja ka meie meeskonnaserverisse või meie sõnastikku ja seejärel hakata linke looma. Ja iga kord, kui midagi muudetakse, on täielik kontrolljälg selle kohta, millised olid eelnevad ja järgnevad pildid, määratluste ja kõige muu osas, ning see, mida näete lähitulevikus tulevat, on ka rohkem autoriseerimise töövoog seega saame tõesti kontrollida, kes selle eest vastutab, komiteede või üksikisikute kinnitused ja seda tüüpi asjad, et juhtimisprotsessi edasi liikudes veelgi tugevamaks muuta.
See teeb meie jaoks oluliseks ka selle, kui meil on need meeskonnaserveri sõnastikus need sõnastiku terminid. See on näide mudeli enda olemuse muutmisest, mille ma siin üles kasutasin. Võimalik, et terminid on omavahel seotud, kuid mida me ka teeme, kui selles sõnastikus on sõnu, mis ilmuvad märkustesse või kirjeldustesse meie siinsete üksuste kohta, kuvatakse need automaatselt heledama lingitud värviga ja kui me Kui hiirekursor nende kohal on, näeme määratlust tegelikult ka ärisõnastikust. See annab meile isegi rikkamat teavet, kui me ise seda teavet tarbime koos kõigi seal sisalduvate sõnastiku mõistetega. See aitab tõesti kogemusi rikastada ja rakendada tähendust kõigele, millega me töötame.
See oli jällegi väga kiire lend. Ilmselt võiksime sellele kulutada päevi, kui sukelduda erinevatesse osadesse, kuid see on pinna kohal väga kiire lendamine. Selle nimel, mida me tegelikult püüame teha, on mõista, kuidas need keerulised andmekeskkonnad välja näevad. Tahame parandada kõigi nende andmete artefaktide nähtavust ja teha koostööd nende eemaldamiseks koos ER / Stuudioga. Tahame võimaldada efektiivsemat ja automatiseeritud andmete modelleerimist. Ja see on igat tüüpi teave, millest me räägime, olgu see siis suurandmed, traditsioonilised suhteandmed, dokumendipoed või midagi muud. Ja jällegi saavutasime selle tänu sellele, et meil on eri platvormide ja muude tööriistade võimsad edasiliikumis- ja tagasisuunamisvõimalused, mis teil seal võivad olla. Ja see kõik seisneb organisatsioonis jagamise ja suhtlemises kõigi kaasatud sidusrühmadega. Seal rakendame tähendusi nimetamisstandardite kaudu. Seejärel rakendame määratlusi oma ärisõnastike kaudu. Ja siis saame kõigi meie muude haldusvõimaluste jaoks täiendavaid klassifikatsioone teha metaandmelaienditega, näiteks andmete kvaliteedilaiendid, põhiandmete haldamise klassifikatsioonid või muud tüüpi klassifikatsioonid, mida soovite nende andmete suhtes rakendada. Ja siis saame teha täiendavaid kokkuvõtteid ja veelgi täiustada suhtlust äriandmeobjektidega, erinevate sidusrühmade vaatajaskonnaga, eriti modelleerijate ja arendajate vahel.
Ja selles osas on väga oluline, et kõige taga on integreeritud hoidla, millel on väga tugevad muudatuste haldamise võimalused. Mul polnud täna aega seda näidata, kuna see läheb üsna keerukaks, kuid hoidlal on väga tugevad muudatuste haldamise võimalused ja kontrolljäljed. Saate teha nimelisi väljalaseid, saate teha ka nimedega versioone ja meil on võimalus ka neil, kes haldavad muudatuste haldamist, saame selle siduda teie ülesannetega. Täna on meil võimalus lisada ülesandeid ja seostada teie mudelimuudatused ülesannetega, nii nagu arendajad seostaksid oma koodimuutused ülesannete või kasutajate lugudega, millega nad samuti töötavad.
See oli jällegi väga kiire ülevaade. Ma loodan, et see on piisav teie isu kasvatamiseks, et saaksime tulevikus nende teemade jaotamisel palju põhjalikumatesse vestlustesse minna. Tänan teid aja eest ja tagasi teile, Rebecca.
Rebecca Jozwiak: Aitäh, Ron, see oli fantastiline ja mul on publiku poolt üsna palju küsimusi, kuid ma tahan anda meie analüütikutele võimaluse oma hambad sinna sisse valada, mida te olete öelnud. Eric, ma lähen edasi ja võib-olla kui te soovite seda või muud slaidi käsitleda, miks te siis kõigepealt edasi ei lähe? Või mõni muu küsimus.
Eric Little: Muidugi. Vabandust, mis oli küsimus, Rebecca? Kas soovite, et ma küsiks midagi konkreetset või…?
Rebecca Jozwiak: Ma tean, et teil oli Ronil algselt mõned küsimused. Kui soovite nüüd paluda, et ta pöörduks mõne poole või mõne neist teie slaidi ääres või millegi muu suhtes, mis tekitas teie huvi, mille kohta soovite küsida? IDERA modelleerimisfunktsioonide kohta.
Eric Little: Jah, üks asi, Ron, kuidas teil läheb, näib, et diagrammid, mida te näitasite, on üldised olemussuhete skeemid, mida tavaliselt kasutaksite andmebaasi ehitamisel, eks?
Ron Huizenga: Jah, üldiselt öeldes, kuid loomulikult on meil dokumendipoodidele laiendatud tüübid ja ka seda tüüpi asjad. Oleme tegelikult varieerunud pelgalt relatsiooniliste märkuste vahel, oleme tegelikult lisanud täiendavaid märkusi ka nende muude poodide jaoks.
Eric Little: Kas on nii, et te, kutid, saate kasutada graafipõhiseid modelleerimise tüüpe, siis kas on olemas võimalus näiteks integreerimiseks, oletagem näiteks, et mul on midagi ülemise kvadrandi, helilooja TopBraidi sarnast või olen teinud midagi Protégé'is või , teate, nagu FIBO finantsmehed, et nad teevad palju tööd semantikas, RDF-i asju - kas on olemas võimalus tuua sellesse olemi-suhte graafi tüüpi modelleerimine sellesse tööriista ja seda kasutada?
Ron Huizenga: Otsime tegelikult, kuidas graafikutega hakkama saada. Me ei käsitle tänapäeval otseselt graafikute andmebaase ja seda tüüpi asju, kuid otsime võimalusi, kuidas saaksime seda oma metaandmete laiendamiseks teha. Ma mõtlen, et saame asju XML-i ja seda tüüpi asjade kaudu kohe sisse tuua, kui saame vähemalt teha mingisuguse XML-i üleviimise, et tuua see lähtepunktiks. Kuid otsime elegantsemaid viise, kuidas seda sisse viia.
Ja ma näitasin teile ka seda pöördprojekteerimise sildade nimekirja, mis meil ka olemas on, seega otsime alati, kas saaksime ka nende sildade laiendusi konkreetsete platvormide jaoks. Kui see on mõistlik, on pidev ja pidev ettevõtmine, et hakata omaks võtma paljusid neid uusi konstruktsioone ja erinevaid platvorme. Kuid võin öelda, et oleme seda tehes kindlasti esirinnas. Need asjad, mida näitasin näiteks MongoDB-l ja seda tüüpi asjadel, oleme esimesed andmete modelleerimise müüjad, kes teevad seda tegelikult oma tootes.
Eric Little: Olgu, jah. Niisiis oli teine küsimus, mis mul teie jaoks oli, juhtimise ja ülalpidamise osas - nagu siis, kui te näite kasutasite, kui näitasite eeskuju inimesest, kes on „töötaja”, ma usun, et see oli „ palk ”ja siis on teil“ plaan ”, kas on olemas viis, kuidas juhtida näiteks erinevaid inimesi, kellel võib olla - oletame, et teil on suur arhitektuur, eks, oletame, et teil on suur ettevõte ja inimesed hakkavad selle tööriistaga asju kokku tõmbama ja teil on siin üks rühm, millel on sõna “töötaja”, ja siin üks rühm, millel on sõna “töötaja”. Ja üks inimene siin ütleb “palk” ja teine inimene ütleb “Palk”.
Kuidas te kutid seda tüüpi vahet eristate ja neid haldate ning juhite? Kuna ma tean, kuidas me seda graafimaailmas teeks, kasutate sünonüümide loendeid või ütlete, et on üks mõiste ja sellel on mitu atribuuti, või võiksite SKOS-mudelis öelda, et mul on eelistatud silt ja mul on arvukalt alternatiivseid silte, mida saan kasutada. Kuidas te kutid seda teete?
Ron Huizenga: Me teeme seda mitmel erineval viisil ja räägime kõigepealt terminoloogiast. Üks asi, mida me muidugi teeme, on see, et me tahame, et meil oleks määratletud või sanktsioneeritud mõisted ja ärisõnastikus on ilmselgelt see, kus me neid tahame. Ja me lubame ka ärisõnastikus linke sünonüümidele, nii et võite öelda, et siin on minu termin, kuid võite ka määratleda, millised on nende sünonüümid.
Nüüd on muidugi huvitav, kui hakkate vaatama läbi selle tohutu andmemaastiku kõigi nende erinevate süsteemidega, mis teil seal väljas on, ei saa te lihtsalt seal käia ja muuta vastavaid tabeleid ja seda tüüpi asju vastavad sellele nimetamisstandardile, kuna tegemist võib olla ostetud paketiga, nii et teil pole kontrolli andmebaasi muutmise või üldse millegi üle.
Lisaks sellele, et saaksime seostada sõnastiku definitsioone, saaksime nende universaalsete kaardistamiste kaudu, millest ma rääkisin, seda, mida me teeksime, ja omamoodi soovitatav lähenemisviis oleks omada kõikehõlmavat loogilist mudelit, mis sätestaks, mida need erinevad ärikontseptsioonid on need, millest sa räägid. Siduge ärisõnastiku terminid nendeks ja tore on see, et nüüd, kui olete saanud selle konstruktsiooni, mis esindab loogilist üksust, nagu see oli, võite hakata lingima sellest loogilisest olemist kõigi selle loogilise olemi rakendustega erinevad süsteemid.
Siis, kus peate seda tegema, näete, oh, "inimest" nimetatakse siin süsteemis töötajaks. Selles teises süsteemis nimetatakse siin palka siin palgaks. Kuna näete seda, näete kõiki nende erinevaid ilminguid, kuna olete need omavahel ühendanud.
Eric Little: Hea küll, jah, sain aru. Selles mõttes on ohutu öelda, et see sarnaneb mõnele objektorienteeritud lähenemisviisile?
Ron Huizenga: Mõneti. See on natuke intensiivsem, kui ma arvan, et võiks öelda. Ma mõtlen, et võiksite kasutada ka käsitsi ühendamist ja läbimist ning ka kõigi nende kontrollimist ja teostamist. Üks asi, millest mul tegelikult polnud võimalust rääkida - kuna meil on jällegi palju võimalusi -, on meil ka täielik automatiseerimisliides andmearhitekti tööriistas endas. Ja makro võime, mis on tõesti tööriista programmeerimiskeel. Nii et me saame tegelikult teha asju nagu makrode kirjutamine, lasta see kustuda ja asju üle kuulata ning teile linke luua. Me kasutame seda teabe importimiseks ja eksportimiseks, saame seda kasutada asjade muutmiseks või atribuutide lisamiseks, mudelis baseeruvaks sündmuseks või kasutada seda partiidena, et asjad tegelikult välja minna ja ülekuulada ning asustada tegelikult erinevaid konstruktsioone mudel. Seega on olemas täielik automatiseerimisliides, mida ka inimesed saavad ära kasutada. Ja universaalsete kaardistamiste kasutamine nendega oleks väga võimas viis selleks.
Rebecca Jozwiak: Olgu, tänan Ronit ja täname Ericut. Need olid suurepärased küsimused. Ma tean, et me jookseme natuke tunni tipust mööda, kuid sooviksin anda Malcolmile võimaluse visata mõned küsimused Ronni teed. Malcolm?
Malcolm Chisholm: Aitäh, Rebecca. Ron, see on väga huvitav, ma näen, et siin on palju võimalusi. Üks valdkondi, mis mind väga huvitab, on näiteks öelda, kui meil on arendusprojekt, kuidas näete, kuidas andmeside modelleerija kasutab neid võimalusi ja teeb võib-olla rohkem koostööd ärianalüütikutega, andmeprofiili või andmete kvaliteedianalüütikuga ja koos ettevõttesponsoritega, kes vastutavad lõpuks projekti tegelike teabenõuete eest. Kuidas teie andmetel modelleerija tegelikult projekti tulemuslikumaks ja tulemuslikumaks muudab, mida me vaatame?
Ron Huizenga: Arvan, et üks esimesi asju, mida peate seal tegema, on andmeside modelleerija - ja ma ei pea silmas seda, et valiksin mõne modelleerija, aga ma niikuinii -, kas mõnel inimesel on endiselt mulje, et andmeside modelleerija on tõesti väravavahi tüüpi roll, me määratleme, kuidas see töötab, oleme valvurid, kes hoolitsevad selle eest, et kõik oleks korrektne.
Nüüd on sellel üks aspekt, et peate veenduma, et määratlete usaldusväärse andmearhitektuuri ja kõik muu. Kuid olulisem on andmete modelleerijana - ja ma leidsin seda konsulteerides ilmselgelt -, kas te peate saama vahendajaks, nii et peate neid inimesi kokku tõmbama.
See ei pea olema enam projekteerimine, andmebaaside genereerimine, loomine - peate vaid suutma töötada kõigi nende erinevate sidusrühmadega, tehes selliseid asju nagu pöördprojekteerimine, teabe importimine, teised inimesed teevad koostööd, olgu see siis sõnastikes või dokumentatsioonis, kõige selle kohta - ja saate selle abil hoidlasse tõmmata, linke mõisteid hoidlas siduda ja nende inimestega koostööd teha.
See on tõesti palju rohkem koostöötüüpi keskkond, kus isegi ülesannete määratlemise või isegi arutelulõngade määratlemise või seda tüüpi asjade kaudu, mis meil meeskonnaserveris on, saavad inimesed tegelikult teha koostööd, esitada küsimusi ja jõuda lõpptoodeteni, mille nad nende andmearhitektuuri ja korralduse vajadus. Kas selline vastus oli?
Malcolm Chisholm: Jah, olen nõus. Tead, ma arvan, et hõlbustusoskus on midagi, mis on andmeside modelleerijates väga soovitav. Olen nõus, et me ei näe seda alati, kuid arvan, et see on vajalik, ja pakun välja, et mõnikord on kalduvus jääda oma nurka oma andmete modelleerimisega, kuid peate tõesti olema teiste sidusrühmade rühmas koos. või te ei saa lihtsalt aru andmekeskkonnast, millega olete tegelenud, ja ma arvan, et selle tõttu kannatab mudel. Kuid see on ainult minu arvamus.
Ron Huizenga: Ja see on huvitav, kuna mainisite varem slaidis midagi selle kohta, kuidas ettevõtted on infotehnoloogiast eemale pööranud, kuna nad ei tarninud lahendusi õigeaegselt ja seda tüüpi asju.
On väga huvitav, et minu hilisemates nõustamisprojektides, enne tootejuhiks saamist, toetati enamikku projektidest, mida ma viimase kahe aasta jooksul enne seda tegin, äri, kus seda juhtis tegelikult just ettevõte ja andmearhitektid ja modelleerijad ei olnud IT osa. Me kuulusime ettevõtete toetatavasse rühma ja olime seal abistajatena koos ülejäänud projektimeeskondadega.
Malcolm Chisholm: Nii et ma arvan, et see on väga huvitav punkt.Arvan, et hakkame nägema muutust ärimaailmas, kus ettevõte küsib või mõtleb võib-olla mitte niivõrd selle peale, mida ma teen, kui protsess on selline, vaid nad hakkavad ka mõtlema, mis on andmed mida ma töötan, mis on minu andmevajadused, mis on need andmed, mida ma käsitlen andmetena ja mil määral saame IDERA tooteid ja võimalusi selle vaate toetamiseks, ja ma arvan, et ettevõtte vajadused, isegi kuigi see on omamoodi ikkagi pisut tärkav.
Ron Huizenga: Olen teiega nõus ja arvan, et näeme seda üha enam ja enam. Oleme näinud ärkamist ja teie puudutasite seda andmete tähtsuse osas varem. Nägime andmete olulisust juba IT-s või andmebaaside arengus, siis nagu te ütlesite, sattusime omamoodi kogu sellesse protsessihaldustsüklisse - ja protsess on äärmiselt oluline, ärge saage minust valesti aru - aga nüüd, mis juhtus on siis, kui see juhtus, andmesorti kadunud fookus.
Ja nüüd mõistavad organisatsioonid, et keskpunktiks on tõesti andmed. Andmed tähistavad kõike, mida me oma ettevõttes teeme, nii et peame kontrollima, et meil on täpsed andmed ja et me leiame õige teabe, mida vajame oma otsuste tegemiseks. Sest kõik ei tulene määratletud protsessist. Osa teabest on muude asjade kõrvalsaadus ja me peame siiski oskama seda leida, teadma, mida see tähendab, ja oskama tõlkida seal nähtavaid andmeid lõpuks teadmisteks, mida saame kasutada oma ettevõtte paremaks juhtimiseks.
Malcolm Chisholm: Õige, ja nüüd on veel üks valdkond, millega olen hädas olnud, seda, mida ma nimetaksin andmete elutsükliks, mis on, teate, kui vaataksime omamoodi andmetöötlusahelat, mis läbi ettevõtte läheb, alustaksime andmete hankimisega või andmete kogumine, mis võib küll olla andmesisestus, kuid sama võib olla ka, ma saan andmeid väljastpoolt ettevõtet mõnelt andmeemüüjalt.
Ja siis andmete kogumise juurest läheme andmehooldusele, kus mõtlen nende andmete standardiseerimisele ja kohaletoimetamisele vajalikesse kohtadesse. Ja siis andmete kasutamisel, tegelikes punktides, kus andmed asuvad, saate andmete abil väärtust juurde.
Ja vanasti tehti seda kõike ühes individuaalses stiilis, kuid tänapäeval võib see olla, näiteks, analüüsikeskkond ja seejärel arhiiv, pood, kuhu andmed sisestada, kui meid enam pole vaja seda ja lõpuks puhastustüüpi protsessi. Kuidas näete, et andmete modelleerimine sobib kogu andmete elutsükli haldusesse?
Ron Huizenga: See on väga hea küsimus ja üks asi, mida mul tegelikult polnud täna siin üldse vaja süveneda, on see, millest me tegelikult rääkima hakkame, on andmeside. Mida me tegelikult teha saame, on see, et meil on oma tööriistades andmeside võimalus ja nagu ma ütlen, saame selle osa ETL-i tööriistadest kaevandada, kuid saate selle ka kaardistada, joonistades ka sugupuu. Mis tahes nendest andmemudelitest või andmebaasidest, mille oleme jäädvustanud ja mudelitesse viinud, võiksime viidata konstruktsioonidele, mis on toodud meie andmeliiniskeemis.
Mida me suudame teha, on juhtida andmevoogu, nagu te ütlete, allikast sihtrühma ja kogu elutsükli vältel, kuidas need andmed erinevate süsteemide kaudu edastatakse ja mida te leiate, võtame töötajad 'andmed - see on üks minu lemmikuid projekti põhjal, mille tegin aastaid tagasi. Tegin koostööd organisatsiooniga, kus oli töötajate andmeid 30 erinevas süsteemis. Mida me seal lõpuks tegime - ja Rebecca hüppas üles andmeliini slaidi - see on siin üsna lihtsustatud andmeliini slaid, kuid mida me suutsime teha, oli tuua sisse kõik andmestruktuurid, suunata need diagrammile ja siis me kas tegelikult saab hakata uurima, millised on vood omavahel ja kuidas on need erinevad andmeüksused omavahel ühendatud? Ja me võime ka sellest kaugemale minna. See on osa andmevoo või põlvnusskeemi kohta, mida me siin näeme. Kui soovite sellest kaugemale jõuda, on meil ka selle komplekti äriarhitekti osa ja sama asi kehtib ka seal.
Kõigile andmestruktuuridele, mille oleme andmete modelleerimise keskkonnas hõivanud, saab nendele viidata ärimudelite tööriistas, nii et isegi teie ärimudelite diagrammides või äriprotsesside diagrammides saate viidata üksikutele andmehoidlatele, kui soovite andmete modelleerimise keskkonda ja kui kasutate neid oma äriprotsessimudeli kaustades, saate isegi nendes CRUD-i täpsustada, kuidas seda teavet tarbitakse või toodetakse ja siis saame hakata genereerima näiteks mõju- ja analüüsiaruanded ning skeemid sellest.
Mida me tahame saavutada ja meil on juba palju võimalusi, kuid üks asi, mis meil on, on justkui selline eesmärk, mida me vaatame, kui me oma tööriistu edasi arendame, on võimeline kaardistama selle otspunkti, organisatsiooni andmete liini ja andmete täieliku elutsükli.
Malcolm Chisholm: Okei. Rebecca, kas mul lubatakse veel ühte?
Rebecca Jozwiak: Ma luban sul veel ühe, Malcolm, minna.
Malcolm Chisholm: Tänan sind väga. Mõeldes andmehaldusele ja mõeldes andmete modelleerimisele, kuidas me saame need kaks rühma tõhusalt koos töötada ja üksteist mõista?
Eric Little: Noh, see on huvitav, ma arvan, et see sõltub tõepoolest organisatsioonist ja see ulatub tagasi minu varasema kontseptsiooni juurde - nendes organisatsioonides, kus algatused olid ettevõtluspõhised, seoti meid otse sisse. Näiteks juhtisin andmearhitektuurimeeskonda, kuid me olid seotud ärikasutajatega ja me aitasime neil tegelikult oma andmehaldusprogrammi üles seada. Jällegi rohkem nõuandev lähenemisviis, kuid see on tõesti rohkem ärifunktsioon.
Mida te tegelikult vajate, selleks on vaja andmesidemudeleid ja arhitekte, kes mõistavad äritegevust tõeliselt, saavad olla seotud ärikasutajatega ja on aidanud neil seista selle ümber toimuvatel juhtimisprotsessidel. Ettevõte soovib seda teha, kuid üldiselt on meil tehnoloogiaalaseid teadmisi, mis aitavad neil seda tüüpi programme silma paista. See peab tõesti olema koostöö, kuid see peab siiski olema ettevõtte omanduses.
Malcolm Chisholm: Okei, see on tore. Aitäh.
Dr Eric Little: Okei.
Rebecca Jozwiak: Olgu, tänan nii palju. Sihtgrupi liikmed, ma kardan, et me ei jõudnud teie küsimuste juurde, kuid ma hoolitsen selle eest, et nad edastataks ikkagi meie vastavale külalisele, kellega me täna liinil olime. Tahan teid nii palju tänada Ericule, Malcolmile ja Ronile, et olete täna meie külalised. See oli suurepärane värk, inimesed. Ja kui teile meeldis täna IDERA veebiülekanne, on IDERA järgmisel kolmapäeval ka Hot Technologies, kui soovite liituda, arutades indekseerimise ja oraaklite väljakutseid, mis on veel üks põnev teema.
Tänan teid väga, inimesed, hoolitsege ja näeme teid järgmine kord. Headaega.