Av Techopedia Staff, 28. september 2016
Takeaway: Vert Rebecca Jozwiak diskuterer dataarkitekturløsninger med Eric Little fra OSTHUS, Malcolm Chisholm fra First San Francisco Partners og Ron Huizenga fra IDERA.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Rebecca Jozwiak: Mine damer og herrer, hallo, og velkommen til Hot Technologies i 2016. I dag diskuterer vi “Building a Business-Driven Data Architecture, ” definitivt et hett tema. Jeg heter Rebecca Jozwiak, jeg vil være vertskapet for dagens webcast. Vi tweeter med en hashtag av # HotTech16, så hvis du allerede er på Twitter, kan du gjerne være med på det også. Hvis du har spørsmål når som helst, kan du sende dem til spørsmål og svar-ruten nederst til høyre på skjermen, så sørger vi for at de blir besvart. Hvis ikke, sørger vi for at gjestene våre får dem for deg.
Så i dag har vi en veldig fascinerende serie. Mange tunge hiters med oss i dag. Vi har Eric Little, VP for datavitenskap fra OSTHUS. Vi har Malcolm Chisholm, sjef for innovasjonssjef, som er en veldig kul tittel, for First San Francisco Partners. Og vi har Ron Huizenga, senior produktsjef fra IDERA. Og du vet, IDERA har virkelig en komplett pakke med datastyrings- og modelleringsløsninger. Og i dag skal han gi oss en demonstrasjon om hvordan løsningen hans fungerer. Men før vi kommer til det, Eric Little, skal jeg gi ballen videre til deg.
Eric Little: Ok, tusen takk. Så jeg kommer til å gå gjennom et par temaer her som jeg tror kommer til å forholde meg til Rons samtale og forhåpentligvis sette scenen for noen av disse temaene også, noen spørsmål og svar.
Så det som interesserte meg for hva IDERA gjør, er at jeg tror de påpeker riktig at komplekse miljøer virkelig driver mye forretningsverdier i dag. Og med komplekse miljøer mener vi komplekse datamiljøer. Og teknologien går virkelig raskt, og det er vanskelig å følge med i dagens forretningsmiljø. Så de menneskene som jobber i teknologiområder, vil ofte se at du har kunder som jobber med problemer med, “Hvordan bruker jeg big data? Hvordan innlemmer jeg semantikk? Hvordan kobler jeg noen av disse nye tingene med mine eldre data? ”Og så videre, og den slags fører oss nå til dags inn i disse fire v-er av store data som mange mennesker er ganske kjent med, og jeg forstår at det kan være mer enn fire noen ganger - jeg har sett så mange som åtte eller ni - men normalt sett, når folk snakker om ting som big data, eller hvis du snakker om big data, ser du vanligvis på noe som er en slags bedriftsskala. Og slik vil folk si, ok, vel, tenk på volumet på dataene dine, som normalt er fokuset - det er akkurat hvor mye du har. Datas hastighet har å gjøre med enten hvor raskt jeg kan bevege det rundt, eller hvor raskt jeg kan spørre om det eller få svar, og så videre. Og personlig tror jeg venstresiden av det er noe som løses og håndteres relativt raskt ved mange forskjellige tilnærminger. Men på høyre side ser jeg mye forbedringsevne og mange nye teknologier som virkelig kommer i forgrunnen. Og det har virkelig å gjøre med den tredje kolonnen, datavariet.
Så med andre ord, de fleste selskaper i dag ser på strukturerte, semistrukturerte og ustrukturerte data. Bildedata begynner å bli et hett tema, så å kunne bruke datamaskinvisjon, se på piksler, kunne skrape tekst, NLP, utvinning av enheter, du har grafinformasjon som kommer ut av enten statistiske modeller eller som kommer ut fra semantisk modeller, har du relasjonsdata som finnes i tabeller, og så videre. Og så å trekke alle disse dataene sammen og alle disse forskjellige typene representerer virkelig en stor utfordring, og du vil se dette i, vet du, i Gartner og andre mennesker som følger med på trendene i bransjen.
Og så er den endelige tingen som folk snakker om i big data ofte denne forestillingen om glupskhet, som virkelig er usikkerheten i dataene dine, uklarheten til dem. Hvor godt vet du hva dataene dine handler om, hvor godt forstår du hva som er der inne, og vet du? Muligheten til å bruke statistikk og muligheten til å bruke en slags informasjon rundt det du kanskje vet eller til å bruke en eller annen kontekst, kan være av verdi der. Og dermed muligheten til å se på data på denne måten med tanke på hvor mye du har, hvor raskt du trenger å flytte dem rundt eller få tak i dem, alle typer data du måtte ha i bedriften og hvor sikker du er på hvor det er, hva det er, hvilken kvalitet det er i, og så videre. Dette krever virkelig en stor, koordinert innsats nå mellom mange individer for å administrere dataene sine effektivt. Modellering av data blir derfor stadig viktigere i dagens verden. Så gode datamodeller fører virkelig til stor suksess i bedriftsapplikasjoner.
Du har datakilder fra en rekke kilder, som vi sa, som virkelig krever mye forskjellige typer integrasjon. Så å trekke det hele sammen er virkelig nyttig for å kunne kjøre spørsmål, for eksempel på tvers av mange typer datakilder, og trekke informasjon tilbake. Men for å gjøre det trenger du gode kartleggingsstrategier, og det kan være en virkelig utfordring å kartlegge den slags data og følge med på disse kartleggingene. Og så har du dette problemet, og hvordan knytter jeg mine gamle data til alle disse nye datakildene? Så antar at jeg har graf, tar jeg alle relasjonsdataene mine og legger de i graf? Vanligvis er det ikke en god idé. Så hvordan har det seg at folk klarer å administrere alle disse typer datamodeller som foregår? Analyse må virkelig kjøres på mange av disse forskjellige datakildene og kombinasjonene. Så svarene som kommer ut av dette, svarene som folk trenger for å virkelig ta gode forretningsavgjørelser er kritiske.
Så dette handler ikke bare om å bygge teknologi for teknologiens skyld, det er egentlig, hva skal jeg gjøre, hva kan jeg gjøre med det, hva slags analyse kan jeg kjøre, og evnen, som jeg allerede har gjort snakket om, å trekke disse tingene sammen, for å integrere det er virkelig, veldig viktig. Og en av disse typer analyser kjører deretter på ting som føderalt søk og spørring. Det blir virkelig et must. Spørsmålene dine må normalt tres over flere typer kilder og trekke informasjonen tilbake pålitelig.
Det ene sentrale elementet som ofte, spesielt folk skal se på sentrale ting som semantiske teknologier - og dette er noe jeg håper Ron kommer til å snakke litt om i IDERA-tilnærmingen - er hvordan du skiller eller administrerer modelllag av dataene dine fra selve datalaget, fra de rå dataene? Så nedover i datalaget kan du ha databaser, du kan ha dokumentdata, du kan ha regnearkdata, du kan ha bildedata. Hvis du er i områder som legemiddelindustrien, har du enorme mengder vitenskapelige data. Og så på toppen av dette ser folk normalt etter en måte å bygge en modell som lar dem raskt integrere disse dataene, og virkelig når du leter etter data nå, er du ikke ute etter å trekke alle dataene opp i modellsjiktet ditt, hva du ser på modelllaget å gjøre er å gi deg en fin logisk fremstilling av hva ting er, vanlige vokabularer, vanlige typer enheter og relasjoner, og muligheten til å virkelig nå inn i dataene der de er. Så det må si hva det er, og det må si hvor det er, og det må si hvordan du skal hente det og bringe det tilbake.
Så dette har vært en tilnærming som har vært ganske vellykket med å fremføre semantiske teknologier fremover, som er et område hvor jeg jobber mye. Så et spørsmål som jeg ønsket å stille til Ron, og som jeg tror vil være nyttig i spørsmål og svar-delen, er å se hvordan oppnås dette av IDERA-plattformen? Så er modelllaget egentlig atskilt fra datalaget? Er de mer integrerte? Hvordan fungerer det, og hva er noen av resultatene og fordelene de ser av tilnærmingen? Derfor blir referansedata virkelig også kritisk. Så hvis du skal ha denne typen datamodeller, hvis du skal være i stand til å sammenslå og søke på tvers av ting, må du virkelig ha gode referansedata. Men problemet er at referansedata kan være veldig vanskelig å vedlikeholde. Så ofte er det vanskelig å navngi standarder i seg selv. En gruppe vil kalle noe X og en gruppe vil kalle noe Y, og nå har du problemet med hvordan finner noen X og Y når de leter etter denne typen informasjon? Fordi du ikke bare vil gi dem en del av dataene, vil du gi dem alt relatert. Samtidig som vilkårene endres, programvaren blir utdatert, og så videre, hvordan holder du oppe og vedlikeholder referansedataene over tid?
Og igjen har semantiske teknologier, spesielt ved bruk av ting som taksonomier og ordforråd, dataordbøker, gitt en standard plass måte å gjøre dette på, som virkelig er veldig robust, det bruker visse typer standarder, men databasefellesskapet har gjort dette for en lang tid også, bare på forskjellige måter. Jeg tror en av nøklene her er å tenke på hvordan man bruker kanskje entitetsforholdsmodeller, hvordan man kanskje bruker grafmodeller eller en slags tilnærming her som virkelig vil gi deg forhåpentligvis en standard distribuert måte å håndtere referansedataene på. Når du har referansedataene, må kartleggingsstrategiene selvfølgelig administrere et bredt utvalg av navn og enheter. Så fageksperter liker ofte å bruke sine egne ord.
Så en utfordring i dette er alltid, hvordan gir du noen informasjon, men gjør den relevant for måten de snakker om det på? Så en gruppe kan ha en måte å se på noe, for eksempel kan du være en kjemiker som jobber med et stoff, og du kan være en strukturell biolog som jobber med det samme stoffet, og du kan ha forskjellige navn på de samme enhetene som angår ditt felt. Du må finne ut måter å samle de personlige terminologiene på, fordi den andre tilnærmingen er at du må tvinge folk til å slippe begrepet og bruke andres, som de ofte ikke liker. Et annet poeng her er å håndtere at store antall synonymer blir vanskelig, så det er mange forskjellige ord i mange menneskers data som kan referere til det samme. Du har et referanseproblem der ved å bruke et mange-til-ett sett av relasjoner. Spesialiserte vilkår varierer fra bransje til bransje, så hvis du skal komme på en slags overordnet løsning for denne typen datastyring, hvor lett er det bærbart fra et prosjekt eller en applikasjon til en annen? Det kan være en annen utfordring.
Automatisering er viktig, og det er også en utfordring. Det er dyrt å håndtere referansedata manuelt. Det er dyrt å måtte fortsette manuelt å kartlegge, og det er dyrt å ha fageksperter slutte å gjøre de daglige jobbene sine og måtte gå inn og stadig fikse dataordbøker og oppdatere definisjoner og så videre, og så videre. Repeterbare vokabularer viser virkelig mye verdi. Så dette er ordforråd ofte du kan finne utenfor organisasjonen din. Hvis du for eksempel jobber med råolje, vil det være visse former for ordforråd du kan låne fra åpne kilder, det samme med legemidler, det samme med banknæringen og finans, det samme med mange av disse områdene. Folk legger gjenbrukbare, generiske, replikerbare vokabularer der ute for folk å bruke.
Og igjen, når jeg ser på IDERA-verktøyet, er jeg nysgjerrig på å se hvordan de håndterer dette med tanke på bruk av slags standarder. I semantikkverdenen ser du ofte ting som SKOS-modeller som gir standarder for minst bredere enn / smalere enn forhold, og de tingene kan være vanskelige å gjøre i ER-modeller, men du vet, ikke umulig, det kommer bare an på hvor mye av det maskiner og den koblingen du kan håndtere i de typer systemer.
Så til slutt ville jeg bare gjøre en sammenligning med noen semantiske motorer som jeg ser i bransjen, og på en måte spørre Ron og prime ham litt for å snakke om hvordan IDERAs system har blitt brukt i forbindelse med noen semantiske teknologier. Kan det integreres med trippelbutikker, grafdatabaser? Hvor lett er det å bruke eksterne kilder fordi den slags ting i den semantiske verden ofte kan lånes ved å bruke SPARQL endepunkter? Du kan importere RDF- eller OWL-modeller direkte inn i modellen din - henvis tilbake til dem - så for eksempel genontologien eller proteinontologien, som kan leve et sted i sitt eget rom med sin egen styringsstruktur, og jeg kan ganske enkelt importere alle eller del av det slik jeg trenger det i mine egne modeller. Og jeg er nysgjerrig på å vite hvordan IDERA tilnærmer seg denne saken. Må du vedlikeholde alt internt, eller er det måter å bruke andre typer standardiserte modeller og trekke dem inn, og hvordan fungerer det? Og det siste jeg nevnte her er hvor mye manuelt arbeid som egentlig er involvert for å bygge ordlistene og metadata-lagringene?
Så jeg vet at Ron kommer til å vise oss noen demoer om slike ting som vil være veldig interessante. Men problemene som jeg ofte ser å rådføre seg med kunder er at det oppstår mye feil hvis folk skriver i sine egne definisjoner eller sine egne metadata. Så du får stavefeil, får fete-finger feil, det er en ting. Du får også folk som kanskje tar noe fra, du vet, bare Wikipedia eller en kilde som ikke nødvendigvis er av den kvaliteten du måtte ønske deg i definisjonen din, eller definisjonen din er bare fra en persons perspektiv, så den er ikke fullstendig, og det er ikke klart da hvordan styringsprosessen fungerer. Styring er selvfølgelig et veldig, veldig stort tema hver gang du snakker om referansedata og når du snakker om hvordan dette kan passe inn i noens masterdata, hvordan de skal bruke metadataene sine, og så videre.
Så jeg ville bare legge noen av disse emnene der ute. Dette er elementer som jeg ser i forretningsområdet på tvers av mange forskjellige slags konsulentoppgaver og mange forskjellige områder, og jeg er virkelig interessert i å se hva Ron kommer til å vise oss med IDERA for å påpeke noen av disse temaene . Så tusen takk.
Rebecca Jozwiak: Tusen takk, Eric, og jeg liker kommentaren din om at det kan oppstå mange feil hvis folk skriver sine egne definisjoner eller metadata. Jeg vet at i journalistikkens verden er det et mantra som “mange øyne gjør få feil”, men når det kommer til praktiske bruksområder, har for mange hender i informasjonskapselet en tendens til å forlate deg med mange ødelagte informasjonskapsler, ikke sant?
Eric Little: Ja, og bakterier.
Rebecca Jozwiak: Ja. Med det skal jeg gå videre og gi den videre til Malcolm Chisholm. Malcolm, gulvet er ditt.
Malcolm Chisholm: tusen takk, Rebecca. Jeg vil gjerne se litt på hva Eric har snakket om, og legge til, slags, noen observasjoner som du vet, Ron kanskje vil svare på, også når vi snakker om “Mot forretningsdrevet dataarkitektur ”- hva betyr det å være forretningsdrevet, og hvorfor er det viktig? Eller er det bare en form for hype? Det tror jeg ikke.
Hvis vi ser på hva som har skjedd siden, vet du, stasjonære datamaskiner ble virkelig tilgjengelig for selskaper - si rundt 1964 - til i dag, kan vi se at det har skjedd mange endringer. Og disse endringene vil jeg oppsummere som et skifte fra prosessentrisitet til datasentrisitet. Og det er det som gjør forretningsdrevne dataarkitekturer så viktige og så relevante for i dag. Og jeg tror, du vet, det er ikke bare et buzzword, det er noe som er helt ekte.
Men vi kan sette pris på det litt mer hvis vi dykker ned i historien, så å gå tilbake i tid, langt tilbake til 1960-tallet og for en tid etterpå, dominerte mainframes. Disse ga deretter vei til PC-er der du faktisk hadde opprør av brukerne da PC-er kom inn. Opprør mot sentralisert IT, som de mente ikke oppfylte deres behov, var ikke smidige nok. Det ga raskt opphav til distribuert databehandling, da PC-er ble koblet sammen. Og så begynte internett å skje, noe som tåket grensene for foretaket - det kunne nå samhandle med parter utenfor seg selv når det gjelder datautveksling, som ikke hadde skjedd før. Og nå har vi gått inn i en tid med sky og big data der skyen er plattformer som virkelig kommuniserer infrastruktur, og så forlater vi som det er IT-behovet for å drive store datasentre fordi, du vet, vi har fått skykapasiteten tilgjengelig for oss, og sammen med de store dataene som Eric har, vet du, så veltalende diskutert. Og generelt sett, som vi ser, når skiftet i teknologi skjedde, har det blitt mer datasentrisk, vi bryr oss mer om data. Som med internett, hvordan data blir utvekslet. Med store data, de fire eller flere V-ene for selve dataene.
Samtidig, og kanskje enda viktigere, tilfeller av forretningsbruk forskjøvet. Da datamaskiner ble introdusert, ble de brukt til å automatisere ting som bøker og poster. Og alt som var en manuell prosess, som involverte reskontro eller sånt, ble i hovedsak programmert i hus. Det skiftet på 80-tallet til tilgjengeligheten av operative pakker. Du trengte ikke å skrive din egen lønnsliste lenger, du kunne kjøpe noe som gjorde det. Det resulterte i en stor nedbemanning den gangen, eller omstrukturering, i mange IT-avdelinger. Men så dukket forretningsinformasjon, med ting som datavarehus, mest på 90-tallet. Etterfulgt av dotcom forretningsmodeller som selvfølgelig var en stor vanvidd. Så MDM. Med MDM begynner du å se at vi ikke tenker på automatisering; vi fokuserer bare på å kurere data som data. Og deretter analyser, som representerer verdien du kan få ut av dataene. Og innen analytics ser du selskaper som er svært vellykkede hvis kjernevirksomhetsmodell dreier seg om data. Google, Twitter, Facebook ville være en del av det, men du kan også hevde at Walmart er det.
Og slik tenker virksomheten nå virkelig på data. Hvordan kan vi få verdi ut av data? Hvordan data kan drive virksomheten, strategien og vi er i datidens gullalder. Hva er det som skjer med tanke på dataarkitekturen, hvis data ikke lenger blir sett på som bare eksosen som kommer ut av baksiden av applikasjoner, men virkelig er sentral i forretningsmodellene våre? Vel, en del av problemet vi har for å oppnå det er IT er virkelig fast i fortiden med systemutviklingen livssyklus som var en konsekvens av å måtte håndtere den prosessautomatiseringsfasen raskt i den tidlige alder av IT, og jobbe i prosjekter er en lignende ting. For IT - og dette er litt av en karikatur - men det jeg prøver å si er at noen av hindringene for å få en forretningsstyrt dataarkitektur er fordi vi, på en slags, ukritisk måte har akseptert en kultur innen IT som stammer fra svunnen tid.
Så alt er et prosjekt. Fortell om dine krav i detalj. Hvis ting ikke fungerer, er det fordi du ikke har fortalt meg dine krav. Vel, det fungerer ikke i dag med data fordi vi ikke starter med ikke-automatiserte manuelle prosesser eller en, du vet, en teknisk konvertering av forretningsprosesser, vi starter veldig ofte med allerede eksisterende produksjonsdata som vi prøver å få verdi ut av. Men ingen som sponser et datasentrisk prosjekt forstår virkelig de dataene i dybden. Vi må gjøre dataoppdagelse, vi må gjøre kildedataanalyse. Og det stemmer ikke egentlig med systemutviklingen, du vet - foss, SDLC-livssyklus - som Agile, vil jeg opprettholde, er en slags en bedre versjon av det.
Og det som blir fokusert på er teknologi og funksjonalitet, ikke data. For eksempel, når vi tester i en testfase, vil det vanligvis være, fungerer funksjonaliteten min, la oss si ETL, men vi tester ikke dataene. Vi tester ikke forutsetningene våre om kildedataene som kommer inn. Hvis vi gjorde det, ville vi være i bedre form, og som noen som har gjort datavarehusprosjekter og lidd gjennom oppstrømsendringer og sprengt ETL-ene mine, vil jeg sette pris på det. Og det vi faktisk vil se er å teste som et foreløpig skritt for kontinuerlig overvåkning av datakvalitet. Så vi har her mange holdninger der det er vanskelig å oppnå den forretningsdrevne dataarkitekturen fordi vi er betinget av en tid med prosessentrisitet. Vi må gjøre en overgang til datasentrisitet. Og dette er ikke en total overgang, du vet, det er fortsatt mye prosessarbeid å gjøre der ute, men vi tenker ikke egentlig på datasentriske termer når vi trenger det, og omstendighetene som oppstår når vi virkelig er forpliktet til å gjøre det.
Nå innser bedriften verdien av dataene, de vil låse opp dataene, så hvordan skal vi gjøre det? Så hvordan gjør vi overgangen? Vel, vi setter data kjernen i utviklingsprosessene. Og vi lar virksomheten lede med informasjonskrav. Og vi forstår at ingen forstår de eksisterende kildedataene i starten av prosjektet. Du kan hevde at datastrukturen og selve dataen kom dit gjennom henholdsvis IT og drift, så vi burde vite det, men egentlig gjør vi det ikke. Dette er datasentrisk utvikling. Så vi må, når vi tenker over hvor og hvordan gjør vi modellering av data i en datasentrisk verden, vi må ha tilbakemeldingsløkker til brukerne når det gjelder å foredle informasjonskravene sine, slik vi gjør dataoppdagelse og dataprofilering, forutse kildedataanalyse, og etter hvert som vi gradvis får mer og mer sikkerhet om dataene våre. Og nå snakker jeg om et mer tradisjonelt prosjekt som et MDM-hub eller et datavarehus, ikke nødvendigvis big data-prosjektene, selv om dette fremdeles er, tror jeg, ganske nært det. Og så inkluderer disse tilbakemeldingsløyppene datamodellerne, du vet, gradvis fremme datamodellen og samhandler med brukerne for å sikre at informasjonskravene blir foredlet basert på hva som er mulig, hva som er tilgjengelig, fra kildedataene slik de bedre forstår det, så det er ikke tilfelle lenger at datamodellen er, i en tilstand som enten ikke er der eller fullstendig utført, det er en gradvis å bringe fokus i den.
Tilsvarende mer nedstrøms for det har vi kvalitetssikring der vi utvikler regler for testing av datakvalitet for å sikre at dataene er innenfor parametrene vi antar. Innenfor refererte Eric til endringer i referansedata, som kan skje. Du ønsker ikke å være som et nedstrøms offer for en slags, ukontrollert endring på dette området, slik at kvalitetssikringsreglene kan gå i etterproduksjon, kontinuerlig overvåking av datakvalitet. Så du kan begynne å se om vi kommer til å være datasentrisk, hvordan vi gjør datasentrisk utvikling er ganske annerledes enn den funksjonsbaserte SDLC og Agile. Og da må vi ta hensyn til synspunkter fra virksomheten også. Vi har - og igjen dette gjengjelder det Eric sa - vi har en datamodell som definerer en dataregistreringsplan for databasen vår, men samtidig trenger vi de konseptuelle modellene, de forretningsmessige synene på data som tradisjonelt ikke er gjort i fortiden. Noen ganger har jeg trodd trodd at datamodellen kan gjøre alt, men vi må ha det konseptuelle synet, semantikken og se på dataene, gjengi det gjennom et abstraksjonslag som oversetter lagringsmodellen til virksomheten utsikt. Og igjen, alle tingene Eric snakket om i form av semantikk, blir viktig å gjøre det, så vi har faktisk flere modelleringsoppgaver. Jeg tror det er, vet du, interessant hvis du har kommet opp i gradene som en datamodeller som jeg gjorde, og igjen, noe nytt.
Og til slutt vil jeg si at den større arkitekturen også må gjenspeile denne nye virkeligheten. Tradisjonell kunde-MDM er for eksempel på en måte, ok, la oss få kundedataene våre inn i et knutepunkt der vi, vet du, kan gi mening om det når det gjelder egentlig bare datakvalitet for back-office applikasjoner. Som fra et forretningsstrategisk synspunkt er et slags gjesp. I dag ser vi imidlertid på kunde-MDM-huber som har ytterligere kundeprofildata i seg, ikke bare de statiske dataene, som da virkelig har et toveis grensesnitt med transaksjonsapplikasjoner fra kunden. Ja, de støtter fremdeles back office, men nå vet vi også om atferden til kundene våre. Dette er dyrere å bygge. Dette er mer komplekst å bygge. Men det er forretningsdrevet på en måte som den tradisjonelle kunden MDM ikke er. Du handler med en orientering mot virksomheten mot enklere design som er enklere å implementere, men for bedriften er det dette de vil se. Vi er virkelig i en ny epoke, og jeg tror det er flere nivåer vi må svare på den forretningsdrivende dataarkitekturen, og jeg synes det er en veldig spennende tid å gjøre ting.
Så takk, tilbake til deg Rebecca.
Rebecca Jozwiak: Takk Malcolm, og jeg likte det du sa om datamodeller må mate forretningsvisningen, fordi, i motsetning til hva du sa, der IT holdt tømmene så lenge, og det er bare ikke sånn lenger og at kulturen trenger å skifte. Og jeg er ganske sikker på at det var en hund i bakgrunnen som var enig med deg 100%. Og med det skal jeg gi ballen videre til Ron. Jeg er virkelig spent på å se demoen din. Ron, gulvet er ditt.
Ron Huizenga: Tusen takk, og før vi hopper inn i det, skal jeg gå gjennom noen lysbilder og deretter litt demo fordi, som Eric og Malcolm har påpekt, dette er et veldig bredt og dyp tema, og med det vi snakker om i dag, skraper vi bare overflaten av det fordi det er så mange aspekter og så mange ting som vi virkelig trenger å vurdere og se på fra en forretningsdrevet arkitektur. Og vår tilnærming er å virkelig gjøre den modellbaserte og hente ekte verdi ut av modellene fordi du kan bruke dem som et kommunikasjonsmiddel og et lag for å aktivere andre systemer. Enten du driver med serviceorientert arkitektur eller andre ting, blir modellen virkelig livsnerven i det som skjer, med alle metadataene rundt det og dataene du har i virksomheten din.
Det jeg imidlertid vil snakke om, er nesten å ta dette et skritt bakover, fordi Malcolm hadde berørt noe av historien til løsningenes utvikling og den typen ting. En måte å virkelig påpeke hvor viktig det er å ha en lyddataarkitektur er en brukssak som jeg pleide å støte på veldig ofte da jeg konsulterte før jeg kom inn i en produktstyringsrolle, og det var at jeg ville gå inn i organisasjoner om de foretok forretningsforvandling eller bare byttet ut noen eksisterende systemer og den typen ting, og det ble veldig raskt tydelig av hvor dårlig organisasjoner forstår deres egne data. Hvis du tar en spesiell brukssak som denne, enten du er en konsulent som skal inn eller kanskje det er en person som nettopp har startet med en organisasjon, eller organisasjonen din har blitt bygd opp gjennom årene med å anskaffe forskjellige selskaper, hva slutter du opp med er et veldig komplekst miljø veldig raskt, med en rekke nye forskjellige teknologier, så vel som arvteknologi, ERP-løsninger og alt annet.
Så en av tingene vi virkelig kan gjøre med modelleringstilnærmingen vår er å svare på spørsmålet om, hvordan får jeg mening av alt dette? Vi kan virkelig begynne å dele informasjonen sammen, slik at virksomheten kan utnytte informasjonen vi har riktig. Og det kommer til, hva er det vi har der ute i de miljøene? Hvordan kan jeg bruke modellene til å drive ut informasjonen jeg trenger og forstå den informasjonen bedre? Og så har vi de tradisjonelle typene metadata for alle de forskjellige tingene som de relasjonsdatamodellene, og vi er vant til å se ting som definisjoner og dataordbøker, du vet, datatyper og den typen ting. Men hva med ytterligere metadata som du ønsker å fange opp for å virkelig gi enda mer mening til det? Som for eksempel hvilke enheter som egentlig er kandidatene som bør være referansedataobjekter, som bør være masterdataadministrasjonsobjekter og de typer ting og knytte dem sammen. Og hvordan flyter informasjonen gjennom organisasjonen? Data flyter fra hvordan de forbrukes både fra prosessperspektiv, men også avstamning når det gjelder informasjonsreise gjennom virksomhetene våre og hvordan de kommer seg gjennom de forskjellige systemene, eller gjennom datalagrene, så vi vet når vi bygger jeg-løsningene, eller slike ting, at vi faktisk bruker riktig informasjon for oppgaven.
Og da er det veldig viktig, hvordan kan vi få alle disse interessentene til å samarbeide, og spesielt forretningsinteressentene fordi det er de som gir oss den sanne betydningen av hva disse dataene er. På slutten av dagen eier virksomheten dataene. De gir definisjonene for ordforrådene og tingene Eric snakket om, så vi trenger et sted å knytte alt dette sammen. Og måten vi gjør det på, er gjennom datamodellering og arkivering av data.
Jeg kommer til å berøre noen få ting. Jeg skal snakke om ER / Studio Enterprise Team Edition. Primært skal jeg snakke om dataarkitekturproduktet der vi utfører datamodellering og den typen ting, men det er mange andre komponenter i suiten som jeg bare vil berøre veldig kort. Du vil se ett utdrag av Business Architect, hvor vi kan gjøre konseptuelle modeller, men vi kan også gjøre forretningsprosessmodeller og vi kan knytte disse prosessmodellene for å koble de faktiske dataene vi har i datamodellene våre. Det hjelper oss virkelig å bringe det bindet sammen. Programvarearkitekt lar oss gjøre ytterligere konstruksjoner som for eksempel UML-modellering og slike ting for å gi støttelogikk til noen av de andre systemene og prosessene vi snakker om. Men veldig viktig når vi rykker ned har vi depotet og teamserveren, og jeg skal snakke om det som slags to halvdeler av samme ting. Oppbevaringsstedet er der vi lagrer alle modellerte metadata så vel som alle forretningsmetadata når det gjelder virksomhetsordliste og vilkår. Og fordi vi har dette depot-baserte miljøet, kan vi deretter sy alle disse forskjellige tingene sammen i det samme miljøet, og da kan vi faktisk gjøre dem tilgjengelige for forbruk, ikke bare for de tekniske menneskene, men også for forretningsfolk. Og det er slik vi virkelig begynner å drive samarbeid.
Og så er det siste stykket jeg skal snakke om kort, når du går inn i disse miljøene, er det ikke bare databaser du har der ute. Du kommer til å ha en rekke databaser, datalagre, du kommer også til å ha mye av det jeg vil kalle, arv arv. Kanskje folk har brukt Visio eller andre diagrammer for å kartlegge noen ting. Kanskje har de hatt andre modelleringsverktøy og den typen ting. Så det vi kan gjøre med MetaWizard er faktisk å trekke ut noe av den informasjonen og ta den med inn i modellene våre, gjøre den aktuell og kunne bruke den, konsumere den på en aktuell måte igjen, i stedet for bare å ha den der ute. Det blir nå en aktiv del av våre arbeidsmodeller, noe som er veldig viktig.
Når du går inn i en organisasjon, som sagt, er det mange forskjellige systemer der ute, mange ERP-løsninger, uoverensstemmende avdelingsløsninger. Mange organisasjoner bruker også SaaS-løsninger, som også er eksternt kontrollert og administrert, så vi kontrollerer ikke databasene og de typer ting i vertene på disse, men vi trenger fortsatt å vite hvordan disse dataene ser ut, og selvfølgelig, metadataene rundt det. Det vi også finner er mange foreldede arvsystemer som ikke har blitt renset på grunn av den prosjektbaserte tilnærmingen som Malcolm hadde snakket om. Det er utrolig hvordan organisasjoner de siste årene vil spinne opp prosjekter, de vil erstatte et system eller en løsning, men det er ofte ikke nok prosjektbudsjett igjen til å ta av de foreldede løsningene, så nå er de bare i veien. Og vi må finne ut hva vi faktisk kan kvitte oss med i miljøet vårt, så vel som hva som er nyttig fremover. Og det knytter seg til den dårlige nedbyggingsstrategien. Det er en del av den samme tingen.
Det vi også finner, fordi mange organisasjoner har blitt bygd opp fra alle disse forskjellige løsningene, er at vi ser mange punkt-til-punkt-grensesnitt med mye data som beveger seg rundt mange steder. Vi må være i stand til å rasjonalisere det og finne ut hvilken datatavle som jeg kort nevnte før, slik at vi kan ha en mer sammenhengende strategi som bruk av serviceorientert arkitektur, bedriftsservicebusser og slike ting, for å levere riktig informasjon til en publiserings- og abonnementsmodell som vi bruker riktig i hele vår virksomhet. Og da må vi selvfølgelig fortsatt gjøre en slags analyse, enten vi bruker datavarehus, datamars med tradisjonell ETL eller bruker noen av de nye datasjøene. Det hele kommer til samme ting. Det er alle data, enten det er big data, om det er tradisjonelle data i relasjonsdatabaser, vi må samle alle disse dataene slik at vi kan håndtere dem og vite hva vi har å gjøre med gjennom modellene våre.
Igjen, kompleksiteten vi skal gjøre er at vi har en rekke trinn som vi ønsker å kunne gjøre. Først av alt går du inn, og du har kanskje ikke de tegningene av hvordan informasjonslandskapet ser ut. I et datamodelleringsverktøy som ER / Studio Data Architect, skal du først gjøre mye omvendt prosjektering når det gjelder å la oss peke på datakildene som er der ute, ta dem inn og deretter sy dem sammen til mer representative modeller som representerer hele virksomheten. Det viktige er, er at vi ønsker å kunne dekomponere disse modellene også langs forretningsområder, slik at vi kan forholde oss til dem i mindre biter, som forretningsfolkene våre også kan forholde seg til, og våre forretningsanalytikere og andre interessenter som jobber på den.
Å navngi standarder er ekstremt viktig, og jeg snakker om det på et par forskjellige måter her. Å navngi standarder i forhold til hvordan vi navngir ting i modellene våre. Det er ganske enkelt å gjøre i logiske modeller, der vi har en god navnekonvensjon og en god datakatalog for modellene våre, men da ser vi også forskjellige navnekonvensjoner for mange av disse fysiske modellene som vi bringer inn. Når vi reverse engineer, ganske ofte ser vi forkortede navn og den typen ting jeg skal snakke om. Og vi må oversette dem tilbake til meningsfylte engelske navn som er meningsfylte for bedriften, slik at vi kan forstå hva alle disse databladene er som vi har i miljøet. Og så er universelle kartlegginger hvordan vi syr dem sammen.
På toppen av det ville vi deretter dokumentere og definere ytterligere, og det er der vi kan klassifisere dataene våre ytterligere med noe som heter Vedlegg, som jeg vil vise deg et par lysbilder på. Og så lukker løkka, vil vi bruke den forretningsmessige betydningen, det er der vi binder inn virksomhetsordlistene og kan koble dem til våre forskjellige modellgjenstander, så vi vet når vi snakker om et visst forretningsuttrykk, hvor det er implementert i våre data i hele organisasjonen. Og så til slutt har jeg allerede snakket om at vi trenger alt dette for å være depotbasert med mye samarbeids- og publiseringsevner, slik at våre interessenter kan utnytte det. Jeg skal snakke om reversering ganske raskt. Jeg har allerede gitt deg et veldig raskt høydepunkt av det. Jeg vil vise det til deg i en faktisk demonstrasjon bare for å vise deg noen av tingene som vi kan ta med inn der.
Og jeg vil snakke om noen av de forskjellige modelltyper og diagrammer som vi ville produsere i denne typen scenarier. Det er klart at vi gjør de konseptuelle modellene i mange tilfeller; Jeg har ikke tenkt å bruke mye tid på det. Jeg vil virkelig snakke om logiske modeller, fysiske modeller og de spesialiserte modellmodellene vi kan lage. Og det er viktig at vi kan lage disse alle i den samme modelleringsplattformen slik at vi kan sy dem sammen. Det inkluderer dimensjonsmodeller og modeller som bruker noen av de nye datakildene, for eksempel NoSQL som jeg viser deg. Og så, hvordan ser ut avstamningsmodellen ut? Og hvordan vi sy sammen disse dataene i en forretningsprosessmodell, er det vi skal snakke om videre.
Jeg skal gå over til et modelleringsmiljø her bare for å gi deg en veldig høy og rask oversikt. Og jeg tror du burde kunne se skjermen min nå. Først av alt vil jeg snakke om bare en tradisjonell type datamodell. Og måten vi ønsker å organisere modellene på når vi tar dem inn, er at vi ønsker å kunne dekomponere dem. Så det du ser her på venstre side, er at vi har logiske og fysiske modeller i akkurat denne modellfilen. Den neste tingen er at vi kan bryte det ned langs dekomposisjonene i virksomheten, så det er derfor du ser mappene. De lyseblå er logiske modeller, og de grønne er fysiske modeller. Og vi kan også bore ned, så innen ER / Studio, hvis du har en forretningsnedbrytning, kan du gå så mange nivåer dypt eller undermodeller du vil, og endringer du gjør på de lavere nivåene reflekteres automatisk ved det høyere nivåer. Så det blir et veldig kraftig modelleringsmiljø veldig raskt.
Noe som jeg også vil påpeke, og som er veldig viktig for å begynne å samle denne informasjonen, er at vi kan ha flere fysiske modeller som tilsvarer en logisk modell også. Ganske ofte kan du ha en logisk modell, men du kan ha fysiske modeller på forskjellige plattformer og den typen ting. Kanskje er en en SQL Server-forekomst av den, kanskje en annen er en Oracle-forekomst. Vi har muligheten til å knytte alt dette sammen i samme modelleringsmiljø. Og der igjen, det jeg har her, er en faktisk datavarehusmodell som igjen kan være i samme modelleringsmiljø, eller vi kan ha den i depotet og koble den inn på tvers av forskjellige ting også.
Det jeg virkelig ønsket å vise deg på dette er noen av de andre tingene og andre varianter av modellene som vi kommer inn på. Så når vi kommer inn på en tradisjonell datamodell som denne, er vi vant til å se de typiske enhetene med kolonnene og metadataene og den typen ting, men det synspunktet varierer veldig raskt når vi begynner å håndtere noen av disse nyere NoSQL-teknologiene, eller som noen fortsatt liker å kalle dem, store datateknologiene.
Så la oss si at vi også har Hive i miljøet. Hvis vi reverserer ingeniør fra et Hive-miljø - og vi kan frem- og bakingeniør fra Hive med akkurat det samme modelleringsverktøyet - ser vi noe som er litt annerledes. Vi ser fortsatt alle dataene som konstruksjoner der, men våre TDL er forskjellige. De av dere som er vant til å se SQL, det du vil se nå er Hive QL, som er veldig SQL-aktig, men ut av det samme verktøyet kan du nå begynne å jobbe med de forskjellige skriptspråkene. Så du kan modellere i dette miljøet, generere det ut i Hive-miljøet, men like viktig, i scenariet som jeg har beskrevet, kan du reversere det hele og gjøre mening av det og begynne å sy det sammen også .
La oss ta en annen som er litt annerledes. MongoDB er en annen plattform som vi støtter innfødt. Og når du begynner å komme inn i JSON-miljøene der du har dokumentbutikker, er JSON et annet dyr, og det er konstruksjoner i det, som ikke samsvarer med relasjonsmodeller. Du begynner snart å håndtere begreper som innebygde objekter og innebygde matriser av objekter når du begynner å avhøre JSON, og disse begrepene finnes ikke i den tradisjonelle relasjonsnotasjonen. Det vi har gjort her, er at vi faktisk har utvidet notasjonen og katalogen vår for å kunne håndtere det i samme miljø.
Hvis du ser over til venstre her, i stedet for å se ting som enheter og tabeller, kaller vi dem objekter. Og du ser forskjellige notasjoner. Du ser fremdeles de typiske typene referanserotasjoner her, men disse blå enhetene som jeg viser i dette spesielle diagrammet, er faktisk innebygde objekter. Og vi viser forskjellige kardinaliteter. Diamantkardinaliteten betyr at det er et objekt i den ene enden, men kardinaliteten til en betyr at vi har i forlaget hvis vi følger det forholdet, vi har et innebygd adresseobjekt. I avhør av JSON har vi funnet at det er nøyaktig den samme strukturen av objekter som er innebygd i beskytteren, men som faktisk er innebygd som en rekke objekter. Vi ser det, ikke bare gjennom selve kontaktene, men hvis du ser på de faktiske enhetene, vil du se at du ser adresser under skytshelgen som også klassifiseres som en rekke objekter. Du får et veldig beskrivende synspunkt på hvordan du kan få det inn.
Og igjen, nå har vi sett så langt på bare noen få sekunder tradisjonelle relasjonsmodeller som er flernivå, vi kan gjøre det samme med Hive, vi kan gjøre det samme med MongoDB og andre store datakilder som vi vil. Hva vi også kan gjøre, og jeg bare skal vise deg dette veldig raskt er, jeg snakket om det faktum å bringe ting inn fra andre forskjellige områder. Jeg kommer til å anta at jeg kommer til å importere en modell fra en database eller reverse engineer den, men jeg kommer til å hente den inn fra eksterne metadata. Bare for å gi deg et veldig raskt synspunkt på alle de forskjellige typene ting vi kan begynne å få inn.
Som du ser, har vi et utall av ting som vi faktisk kan bringe metadataene inn i modelleringsmiljøet vårt med. Starter med ting som til og med Amazon Redshift, Cassandra, mange av de andre big data-plattformene, så du ser mange av disse listet. Dette er i alfabetisk rekkefølge. Vi ser mange store datakilder og den typen ting. Vi ser også mange tradisjonelle eller eldre modelleringsmiljøer som vi faktisk kan bringe de metadataene gjennom. Hvis jeg går gjennom her - og ikke skal bruke tid på hver og en av dem - ser vi mange forskjellige ting vi kan ta det med fra, når det gjelder modelleringsplattformer og dataplattformer. Og noe som er veldig viktig å innse her, er en annen del som vi kan gjøre når vi begynner å snakke om datelinje, på Enterprise Team Edition kan vi også avhøre ETL-kilder, enten det er ting som Talend eller SQL Server Information Services-kartlegginger, vi kan ta det faktisk med for å starte data-avstamningsdiagrammene også og tegne et bilde av hva som skjer i de transformasjonene. Til sammen har vi over 130 av disse forskjellige broer som faktisk er en del av Enterprise Team Edition-produktet, så det hjelper oss virkelig å samle alle gjenstander til ett modelleringsmiljø veldig raskt.
Sist, men ikke minst, vil jeg også snakke om det faktum at vi ikke kan miste synet av det faktum at vi trenger andre typer konstruksjoner hvis vi driver med datavarehus eller andre typer analyser. Vi ønsker fortsatt å ha muligheten til å gjøre ting som dimensjonsmodeller der vi har faktatabeller og vi har dimensjoner og de typer ting. En ting jeg også vil vise deg, er at vi også kan ha utvidelser til metadataene våre som hjelper oss å kategorisere hva som er dimensjonstyper og alt annet. Så hvis jeg ser på den dimensjonale datafanen her, for eksempel på en av disse, vil den faktisk automatisk oppdage, basert på modellmønsteret den ser, og gi deg et utgangspunkt om den tror det er en dimensjon eller en faktabord. Men utover det er det vi kan gjøre innenfor dimensjonene og den typen ting har vi til og med forskjellige typer dimensjoner som vi kan bruke til å klassifisere dataene i en datavarehusmiljø. Så veldig kraftige evner at vi sy dette helt sammen.
Jeg kommer til å hoppe inn i denne siden jeg er i demomiljøet akkurat nå og viser dere et par andre ting før jeg hopper tilbake til lysbildene. En av tingene som vi nylig har lagt til ER / Studio Data Architect er at vi har kjørt inn i situasjoner - og dette er en veldig vanlig brukstilfelle når du jobber med prosjekter - utviklere tenker når det gjelder objekter, mens dataene våre modellerere har en tendens til å tenke når det gjelder tabeller og enheter og den typen ting. Dette er en veldig forenklet datamodell, men den representerer noen få grunnleggende konsepter, der utviklerne eller til og med forretningsanalytikere eller forretningsbrukere kan tenke på dem som forskjellige objekter eller forretningskonsepter. Det har vært veldig vanskelig å klassifisere disse før nå, men det vi faktisk har gjort i ER / Studio Enterprise Team Edition, i 2016-utgivelsen, er at vi nå har et konsept som heter Business Data Objects. Og det som gjør det mulig for oss å gjøre er at vi kan innkapslere grupper av enheter eller tabeller til sanne forretningsobjekter.
Det vi for eksempel har her i denne nye visningen er innkjøpsordreoverskriften og ordrelinjen har blitt trukket sammen nå, de er innkapslet som et objekt, vi vil tenke på dem som en arbeidsenhet når vi vedvarer dataene, og vi bringer dem sammen, så det er nå veldig enkelt å relatere det til forskjellige målgrupper. De er gjenbrukbare i hele modelleringsmiljøet. De er et sant objekt, ikke bare en tegningskonstruksjon, men vi har også den fordelen at når vi faktisk kommuniserer fra modelleringsperspektiv, kan vi selektivt kollapse eller utvide dem slik at vi kan produsere en oppsummert visning for dialoger med bestemte interessentgrupper, og vi kan selvfølgelig også beholde den mer detaljerte visningen som vi ser her for flere av de tekniske publikumene. Det gir oss virkelig et virkelig godt kommunikasjonsmiddel. Det vi ser nå er å kombinere flere forskjellige modelltyper, forbedre dem med konseptet med forretningsdataobjekter, og nå skal jeg snakke om hvordan vi faktisk bruker litt mer mening på denne typen ting og hvordan vi sy sammen dem i generelle miljøer.
Jeg prøver bare å finne min WebEx her, slik at jeg kan gjøre det. Og der går vi, tilbake til Hot Tech-lysbildene. Jeg skal bare spole frem noen lysbilder her fordi du allerede har sett disse i selve modelldemonstrasjonen. Jeg vil snakke om navngivende standarder veldig raskt. Vi ønsker å anvende og håndheve forskjellige navnestandarder. Det vi ønsker å gjøre er at vi faktisk har muligheten til å lagre navneskapsstandardmaler i depotene våre for i utgangspunktet å bygge den betydningen gjennom, gjennom ord eller uttrykk eller til og med forkortelser, og knytte dem tilbake til en meningsfull engelsk type ord. Vi skal bruke forretningsbetegnelser, forkortelsene for hver, og vi kan spesifisere rekkefølgen, sakene og legge til prefikser og suffikser. Den typiske brukssaken for dette er typisk når folk har bygget en logisk modell og deretter faktisk fremover for å lage en fysisk modell der de kanskje har brukt forkortelser og alt annet.
Det vakre er at det er like kraftig, enda kraftigere i omvendt retning, hvis vi bare kan fortelle hva noen av disse navnestandardene var på noen av de fysiske databasene som vi har utviklet omvendt, kan vi ta disse forkortelsene, gjøre dem om til lengre ord, og bringe dem bakover i engelske fraser. Vi kan nå få riktige navn på hvordan dataene våre ser ut. Som jeg sier, den typiske brukssaken er at vi ville bevege oss fremover, logiske til fysiske, og kartlegge datalagrene og den typen ting. Hvis du ser på skjermdumpen på høyre side, vil du se at det er forkortede navn fra kildenavnene, og når vi har brukt en navngivende standardmal, har vi faktisk flere fulle navn. Og vi kunne plassere mellomrom og alt sånt i om vi vil, avhengig av navnestandardmalen vi brukte. Vi kan få det til å se ut, men vi vil at det skal se inn i modellene våre. Først når vi vet hva noe heter, kan vi faktisk begynne å knytte definisjoner til det, for med mindre vi vet hva det er, hvordan kan vi bruke en mening på det?
Det fine er at vi faktisk kan påberope oss dette når vi gjør alle slags ting. Jeg snakket om omvendt prosjektering, vi kan faktisk påkalle navne på standard standardmaler samtidig når vi driver med reverse engineering. Så i ett sett med trinn gjennom en veiviser, er det vi kan gjøre, hvis vi vet hva konvensjonene er, kan vi reversere en fysisk database, den kommer til å bringe den tilbake som fysiske modeller i et modelleringsmiljø og det er også kommer til å bruke de navnekonvensjonene. Så vi får se hva de engelskspråklige representasjonene av navn er i den tilsvarende logiske modellen i miljøet. Vi kan også gjøre det og kombinere det med XML Schema-generasjon, slik at vi kan ta en modell og til og med skyve den ut med forkortelsene våre, enten vi gjør SOA-rammer eller den typen ting, så vi kan også skyve ut forskjellige navnekonvensjoner som vi faktisk har lagret i selve modellen. Det gir oss mange veldig kraftige evner.
Her er et eksempel på hvordan det ville se ut hvis jeg hadde en mal. Denne viser faktisk at jeg hadde EMP for "ansatt, " SAL for "lønn, " PLN for "plan" i en navnestandardkonvensjon. Jeg kan også bruke dem for å få dem til å fungere interaktivt når jeg bygger ut modeller og setter ting inn. Hvis jeg brukte denne forkortelsen og jeg skrev inn "Ansattes lønnsplan" på enhetsnavnet, ville den fungere med navnestandardmalen Jeg har definert her, det ville gitt meg EMP_SAL_PLN da jeg opprettet enhetene og gitt meg de tilsvarende fysiske navnene med en gang.
Igjen, veldig bra for når vi designer og videreutvikler engineering. Vi har et veldig unikt konsept, og det er her vi virkelig begynner å bringe disse miljøene sammen. Og det kalles Universal Mappings. Når vi har brakt alle disse modellene inn i miljøet vårt, hva vi kan gjøre, forutsatt at vi nå har brukt disse navnekonvensjonene og de er enkle å finne, kan vi nå bruke en konstruksjon som heter Universal Mappings i ER / Studio. Vi kan koble enheter på tvers av modeller. Uansett hvor vi ser "kunde" - vi vil sannsynligvis ha "kunde" i mange forskjellige systemer og mange forskjellige databaser - kan vi begynne å koble alle disse sammen slik at når jeg jobber med det i en modell jeg kan se hvor er manifestasjonene av kunder i de andre modellene. Og fordi vi har modellsjiktet som representerer det, kan vi til og med knytte det til datakilder og bringe det ned til i hvor det er brukt henvendelser om hvilke databaser også disse bor i. Det gir oss virkelig en mulighet til å knytte alt dette sammen veldig sammenhengende.
Jeg har vist deg forretningsdataobjektene. Jeg vil også snakke om metadatautvidelsene, som vi kaller Vedlegg, veldig raskt. Det som gjør det er at det gir oss muligheten til å lage flere metadata for modellobjektene våre. Ganske ofte ville jeg sette opp denne typen egenskaper for å drive mange forskjellige ting ut fra et datastyring og datakvalitetsperspektiv, og også for å hjelpe oss med hoveddatastyring og datalagringspolitikk. Den grunnleggende ideen er at du oppretter disse klassifiseringene, og du kan knytte dem uansett hvor du vil, på tabellnivå, kolonnivå, de typer ting. Det vanligste brukssaken er selvfølgelig at enheter er tabeller, og så kan jeg definere: hva er stamdataobjektene mine, hva er referansetabellene mine, hva er de transaksjonstabellene mine? Fra et datakvalitetsperspektiv kan jeg gjøre klassifiseringer med tanke på viktighet for virksomheten, slik at vi kan prioritere datarensing og den type ting.
Noe som ofte overses er, hva er oppbevaringspolitikken for forskjellige typer data i vår organisasjon? Vi kan konfigurere disse, og vi kan faktisk knytte dem til de forskjellige typer informasjonsgjenstander i vårt modelleringsmiljø og, selvfølgelig, vårt lager også. Det fine er, er disse vedleggene levende i vår dataordbok, så når vi bruker enterprise data ordbøker i miljøet, kan vi knytte dem til flere modeller. Vi må bare definere dem én gang, og vi kan utnytte dem om og om igjen på tvers av de forskjellige modellene i miljøet vårt. Dette er bare et raskt skjermbilde for å vise at du faktisk kan spesifisere når du gjør et vedlegg, hva alle brikkene er som du vil knytte det til. Og dette eksemplet her er faktisk en liste over verdier, så når de skal inn, kan du velge fra en liste over verdier, du har mye kontroll i modelleringsmiljøet for det som blir valgt, og du kan til og med angi hva som standard verdien er hvis det ikke velges en verdi. Så mye kraft der. De lever i dataordboken.
Noe jeg vil vise deg litt lenger nede på denne skjermen, i tillegg ser du vedleggene som dukker opp i den øverste delen, under den ser du datasikkerhetsinformasjon. Vi kan faktisk bruke datasikkerhetspolitikk også for de forskjellige informasjonsdelene i miljøet. For forskjellige overholdelseskartlegginger, datasikkerhetsklassifiseringer sender vi et antall av dem ut av esken som du bare kan generere og begynne å bruke, men du kan også definere dine egne samsvarsmappinger og standarder. Enten du gjør HIPAA eller noen av de andre initiativene der ute. Og du kan virkelig begynne å bygge opp dette veldig rike settet med metadata i miljøet.
Og så ordlisten og begrepene - det er her den forretningsmessige betydningen er bundet i. Vi har ganske ofte dataarklister der ute som ganske ofte en organisasjon bruker som utgangspunkt for å begynne å drive ut ordlister, men terminologien og ordtaket er ofte veldig teknisk. Så det vi kan gjøre er at vi kan, hvis vi ønsker det, bruke dem som utgangspunkt for å drive ut ordliste, men vi ønsker virkelig at virksomheten skal eie disse. Det vi har gjort i teamservermiljøet, har vi gitt muligheten for at folk kan lage forretningsdefinisjoner, og så kan vi koble dem til de forskjellige modellgjenstandene som de tilsvarer også i modelleringsmiljøet. Vi anerkjenner også poenget som ble diskutert tidligere, og det er, jo flere du har skrevet, jo mer potensial er det for menneskelig feil. Det vi også gjør i ordlisten vår, er at vi støtter et hierarki av ordliste, slik at vi kan ha forskjellige ordlistetyper eller forskjellige typer ting i organisasjonen, men like viktig er det at hvis du allerede har noen av disse kildene der ute med vilkårene og alt definert, kan vi faktisk gjøre en CSV-import for å trekke disse inn i vårt modelleringsmiljø, og teamserveren vår eller ordlisten vår også, og deretter begynne å koble derfra. Og hver gang noe endres er det en full revisjonsspor av hva før og etter bilder var, med tanke på definisjonene og alt annet, og hva du kommer til å se komme i løpet av en veldig nær fremtid, er også mer en autorisasjonsarbeidsflyt slik at vi virkelig kan kontrollere hvem som har ansvaret for det, godkjenninger fra utvalg eller enkeltpersoner, og den typen ting, for å gjøre styringsprosessen enda mer robust når vi går fremover.
Det dette også gjør for oss er når vi har disse ordlistene i teamtjenersordlisten, dette er et eksempel på redigering i en enhet i selve modellen som jeg har tatt opp her. Det kan ha koblede begreper, men det vi også gjør er hvis det er ord som er i den ordlisten som vises i notatene eller beskrivelsene av hva vi har i enhetene våre her, blir de automatisk vist i en lysere hyperkoblet farge, og hvis vi musen over dem, kan vi faktisk se definisjonen fra virksomhetsordlisten også. Det gir oss til og med rikere informasjon når vi konsumerer selve informasjonen, med alle ordene som finnes der ute. Det hjelper virkelig å berike opplevelsen og anvende betydningen på alt vi jobber med.
Så igjen, det var en veldig rask flyby. Det er klart vi kunne bruke dager på dette når vi fordypet oss i de forskjellige delene, men dette er en veldig rask flyby over overflaten. Det vi virkelig prøver å gjøre er å forstå hvordan de komplekse datamiljøene ser ut. Vi ønsker å forbedre synligheten til alle disse artefaktene og samarbeide for å drive dem ut med ER / Studio. Vi ønsker å muliggjøre mer effektiv og automatisert datamodellering. Og det er alle typer data vi snakker om, enten det er big data, tradisjonelle relasjonsdata, dokumentbutikker eller noe annet. Og igjen oppnådde vi det fordi vi har kraftige teknologier for fremover og bakover for de forskjellige plattformene og de andre verktøyene du kan ha der ute. Og det handler om å dele og kommunisere på tvers av organisasjonen med alle interessenter som er involvert. Det er der vi bruker mening gjennom navnestandarder. Vi bruker deretter definisjoner gjennom virksomhetsordlistene. Og så kan vi gjøre ytterligere klassifiseringer for alle våre andre styringsmuligheter med metadatautvidelser som utvidelser av datakvalitet, klassifiseringer for masterdatastyring eller andre typer klassifiseringer du vil bruke på disse dataene. Og så kan vi oppsummere ytterligere og forbedre kommunikasjonen enda mer med forretningsdataobjektene, med de forskjellige interessentgruppene, spesielt mellom modellerere og utviklere.
Og igjen, det som er veldig viktig med dette er, bak det hele er et integrert depot med veldig robuste endringsledelsesfunksjoner. Jeg hadde ikke tid til å vise det i dag fordi det blir ganske komplekst, men depotet har veldig robuste evner for endringsadministrasjon og revisjonsspor. Du kan gjøre navngivne utgivelser, du kan gjøre navngitte versjoner, og vi har også muligheten for de av dere som driver med endringsledelse, vi kan knytte det rett inn i oppgavene dine. Vi har muligheten i dag til å legge inn oppgaver og knytte modellendringene dine til oppgaver, akkurat som utviklere vil knytte kodeendringene sine til oppgavene eller brukerhistoriene de også jobber med.
Igjen, det var en veldig rask oversikt. Jeg håper det har vært nok til å få appetitten slik at vi kan delta i mye dypere samtaler om å dele ut noen av disse temaene når vi går fremover. Takk for tiden din, og tilbake til deg, Rebecca.
Rebecca Jozwiak: Takk, Ron, det var fantastisk, og jeg har ganske mange spørsmål fra publikum, men jeg vil gi analytikerne våre en sjanse til å synke tennene i det du har sagt. Eric, jeg kommer til å gå foran, og kanskje hvis du vil ta opp dette lysbildet, eller et annet, hvorfor ikke gå foran? Eller noe annet spørsmål.
Eric Little: Visst. Beklager, hva var spørsmålet, Rebecca? Vil du at jeg skal spørre noe spesifikt eller …?
Rebecca Jozwiak: Jeg vet at du først hadde noen spørsmål til Ron. Hvis du ønsker å be ham om å adressere noen av dem, eller noen av dem fra lysbildet ditt eller noe annet som vekket din interesse som du vil spørre om? Om IDERAs modelleringsfunksjoner.
Eric Little: Ja, så en av tingene, Ron, så hvordan ser dere ut, det ser ut som diagrammene som dere viste er generelle typer entitetsforholdsdiagrammer som dere vanligvis ville brukt i databasekonstruksjon, ikke sant?
Ron Huizenga: Ja, generelt sett, men selvfølgelig har vi de utvidede typene for dokumentlagrene og den typen ting også. Vi har faktisk variert fra bare ren relasjonell notasjon, vi har faktisk lagt til flere notasjoner for de andre butikkene også.
Eric Little: Er det en måte som dere kan bruke grafbaserte modeller av modellering, så er det en måte å integrere, for eksempel, la oss anta at jeg har noe som en toppkvadrant, TopBraid komponistverktøy, eller at jeg har gjort noe i Protégé eller, du vet, som de økonomiske gutta i FIBO, de jobber mye med semantikk, RDF-ting - er det en måte å få inn den typen grafisk modellering av enhet-forhold i dette verktøyet, og bruke den?
Ron Huizenga: Vi ser faktisk på hvordan vi kan håndtere grafer. Vi håndterer ikke eksplisitt grafdatabaser og den typen ting i dag, men vi ser på måter vi kan gjøre det for å utvide metadataene våre. Jeg mener, vi kan ta inn ting gjennom XML og den typen ting akkurat nå, hvis vi i det minste kan gjøre en slags gjengivelse av XML for å få det inn som utgangspunkt. Men vi ser på mer elegante måter å få det inn på.
Og jeg viste deg også den listen over brobygger som vi har der også, så vi ser alltid på å få utvidelser til disse broene også for spesifikke plattformer. Det er en kontinuerlig og kontinuerlig innsats, hvis det er fornuftig, å begynne å omfavne mange av disse nye konstruksjonene og de forskjellige plattformene der ute. Men jeg kan si at vi definitivt er i forkant med å gjøre det. Tingene jeg viste på for eksempel MongoDB og den typen ting, vi er den første leverandøren av datamodellering som faktisk gjorde det innfødt i vårt eget produkt.
Eric Little: Ok, ja. Så det andre spørsmålet jeg hadde til deg, da, var når det gjaldt styring og opprettholdelse av - som når du brukte eksemplet, da du viste eksemplet til personen som er en "ansatt", jeg tror det var en " lønn ”og så har du en“ plan ”, er det en måte, hvordan klarer du for eksempel forskjellige typer mennesker som kan ha - la oss anta at du har en stor arkitektur, ikke sant, la oss anta at du har et stort foretak og folk begynner å trekke ting sammen i dette verktøyet, og du har en gruppe her borte som har ordet "ansatt" og en gruppe her borte som har ordet "arbeider." Og en person her borte sier "lønn" og en annen person sier “lønn”.
Hvordan forener dere og forvalter og styrer den slags distinksjoner? Fordi jeg vet hvordan vi ville gjort det i grafverdenen, vet du, du ville brukt synonymerlister, eller du vil si at det er ett konsept og det har flere attributter, eller du kan si i SKOS-modellen at jeg har en foretrukket etikett og jeg har mange alternative etiketter som jeg kan bruke. Hvordan gjør dere det?
Ron Huizenga: Vi gjør det på et par forskjellige måter, og la oss først og fremst snakke om terminologien. Noe av det vi gjør, er selvfølgelig at vi vil ha de definerte eller sanksjonerte vilkårene, og i virksomhetsordlisten er det åpenbart hvor vi vil ha dem. Og vi tillater også koblinger til synonymer i virksomhetsordlisten, så det du kan gjøre er at du kan si, her er mitt begrep, men du kan også definere hva alle synonymer for disse er.
Nå er det interessante, selvfølgelig, når du begynner å se over det enorme datalandskapet med alle disse forskjellige systemene du har der ute, kan du ikke bare gå ut der og endre de tilsvarende tabellene og de slags ting til samsvarer med den navngivningsstandarden fordi det kan være en pakke du kjøpte, slik at du ikke har kontroll over å endre databasen eller noe i det hele tatt.
Det vi kunne gjøre der, i tillegg til å kunne knytte ordlistedefinisjonene, er gjennom de universelle kartlegginger som jeg snakket om, hva vi ville gjøre, og slags anbefalt tilnærming, er å ha en overordnet logisk modell som legger ut hva disse forskjellige forretningskonseptene er det du snakker om. Bind virksomhetsordlistene til disse, og det fine er nå at du har fått denne konstruksjonen som representerer en logisk enhet som den var, så kan du begynne å koble fra den logiske enheten til alle implementeringene av den logiske enheten i de forskjellige systemene.
Når du trenger å gjøre det, kan du se, "person" her kalles "ansatt" i dette systemet. "Lønn" her kalles "lønn" her i dette andre systemet. Fordi du vil se det, vil du se alle de forskjellige manifestasjonene av dem fordi du har koblet dem sammen.
Eric Little: OK bra, ja, det. Er det i den forstand trygt å si at det er sånn som noen av de objektorienterte tilnærmingene?
Ron Huizenga: Noe. Det er litt mer intensivt enn det, antar jeg at du kan si. Jeg mener, du kan ta tilnærmingen til å manuelt koble sammen og gå gjennom og inspisere og gjøre dem alle også. Den ene tingen hadde jeg ikke en sjanse til å snakke om - for igjen, vi har mange muligheter - vi har også et fullstendig automatiseringsgrensesnitt i selve Data Architect-verktøyet. Og en makrofunksjon, som virkelig er et programmeringsspråk i verktøyet. Så vi kan faktisk gjøre ting som å skrive makroer, få det til å avhøre ting og lage koblinger for deg. Vi bruker den til å importere og eksportere informasjon, vi kan bruke den til å endre ting eller legge til attributter, hendelse basert i selve modellen, eller vi kan bruke den til å kjøre i partier for å faktisk gå ut og forhøre ting og faktisk befolke forskjellige konstruksjoner i modell. Så det er et fullstendig automatiseringsgrensesnitt som folk også kan dra nytte av. Og å bruke universelle kartlegginger med disse ville være en veldig kraftig måte å gjøre det på.
Rebecca Jozwiak: Ok, takk Ron og takk Eric. Det var store spørsmål. Jeg vet at vi løper litt forbi toppen av timen, men jeg vil gjerne gi Malcolm en sjanse til å kaste noen spørsmål Rons vei. Malcolm?
Malcolm Chisholm: Takk, Rebecca. Så Ron, det er veldig interessant, jeg ser at det er mange muligheter her. Et av områdene som jeg er veldig interessert i er, for eksempel, hvis vi har et utviklingsprosjekt, hvordan ser du datamodelleren bruke disse mulighetene og kanskje samarbeide mer med forretningsanalytikere, med en dataprofilator, med en datakvalitetsanalytiker, og med næringslivsponsorene som til slutt vil være ansvarlig for de faktiske informasjonskravene i prosjektet. Hvordan gjør datamodelleren egentlig, vet du, prosjektet mer effektivt og effektivt med de egenskapene vi ser på?
Ron Huizenga: Jeg tror at en av de første tingene du må gjøre der er som datamodeller - og jeg har ikke tenkt å velge noen av modellene, men det vil jeg uansett - er det noen som fortsatt har inntrykk av at datamodelleren er virkelig portvokteren type rolle å like, vi definerer hvordan det fungerer, vi er vaktene som sørger for at alt er riktig.
Nå er det et aspekt av det, at du må sørge for at du definerer en lyddataarkitektur og alt annet. Men det viktigste er som datamodeller - og jeg fant dette ganske tydelig da jeg konsulterte meg - er du å bli en tilrettelegger, så du må trekke disse menneskene sammen.
Det kommer ikke til å være et design foran, generere, bygge databaser lenger - det du trenger å kunne gjøre er at du trenger å kunne samarbeide med alle disse forskjellige interessentgruppene, gjøre ting som reverse engineering, importere informasjon i, ha andre mennesker samarbeider, enten det er på ordlistene eller dokumentasjonen, alt sånt - og være en tilrettelegger for å trekke dette inn i depotet, og koble konseptene sammen i depotet, og jobbe med disse menneskene.
Det er virkelig mye mer av en samarbeidstype miljø der selv gjennom definisjon av oppgaver eller diskusjonstråder eller den typen ting som vi har i teamserveren, at folk faktisk kan samarbeide, stille spørsmål og komme frem til de endelige sluttproduktene som de behov for deres dataarkitektur og organisering. Gjorde den slags svar?
Malcolm Chisholm: Ja, jeg er enig. Du tror, jeg tror at tilretteleggingsevnen er noe som virkelig er veldig ønskelig hos datamodeller. Jeg er enig i at vi ikke alltid ser det, men jeg tror det er nødvendig, og jeg vil foreslå at det noen ganger er en tilbøyelighet til å være i hjørnet ditt med å gjøre datamodellering, men du trenger virkelig å være der ute og samarbeide med de andre interessentgruppene eller du forstår bare ikke datamiljøet du arbeider med, og jeg tror modellen lider som et resultat. Men det er bare min mening.
Ron Huizenga: Og det er interessant fordi du nevnte noe tidligere i lysbildet ditt om historien om hvordan virksomheter er slags bortvist fra IT fordi de ikke leverte løsningene på en riktig måte og de slags ting.
Det er veldig interessant at i de senere konsulentoppdragene mine, før jeg ble produktansvarlig, ble de fleste prosjektene som jeg gjorde de to siste årene før det, forretningssponsorert, hvor det virkelig var virksomheten som drev det og dataarkitektene. og modellerere var ikke en del av IT. Vi var en del av en forretnings sponset gruppe og vi var der som tilretteleggere som jobbet med resten av prosjektgruppene.
Malcolm Chisholm: Så jeg synes det er et veldig interessant poeng. Jeg tror vi begynner å se et skifte i forretningsverdenen der virksomheten spør, eller tenker kanskje, ikke så mye som hva jeg gjør, å være prosesslignende, men de begynner også å tenke på hva som er dataene som jeg jobber med, hva er databehovene mine, hva er dataene jeg arbeider med som data, og i hvilken grad kan vi få IDERA-produkter og evner for å støtte det synspunktet, og jeg tror at virksomhetens behov, til og med selv om det er litt fremdeles begynnende.
Ron Huizenga: Jeg er enig med deg, og jeg tror vi ser det gå mer og mer den veien. Vi har sett en oppvåkning, og du berørte den tidligere når det gjelder viktigheten av data. Vi så viktigheten av data tidlig i IT eller i utviklingen av databaser, så som du sier, vi kom ganske inn i hele prosessstyringssyklusen - og prosessen er ekstremt viktig, ikke misforstå det - men nå, hva som skjedde er når det skjedde, data slags mistet fokus.
Og nå innser organisasjoner at data virkelig er samlingspunktet. Data representerer alt vi gjør i vår virksomhet, så vi må sørge for at vi har nøyaktige data, slik at vi kan finne riktig informasjon som vi trenger for å ta våre beslutninger. For ikke alt kommer fra en definert prosess. Noe av informasjonen er et biprodukt av andre ting, og vi må fortsatt kunne finne den, vite hva den betyr og kunne oversette dataene vi ser der til slutt til kunnskap som vi kan bruke til å drive virksomhetene våre bedre.
Malcolm Chisholm: Akkurat, og nå et annet område jeg har slitt med, er det jeg vil kalle datalivssyklusen, som du vet, hvis vi ser på hva slags dataforsyningskjede som går gjennom en bedrift, ville vi starte med datainnsamling eller datafangst, noe som kan være dataregistrering, men det kan også være, jeg får data utenfor bedriften fra en eller annen dataleverandør.
Og så går vi fra datainnsamling til datavedlikehold der jeg tenker å standardisere disse dataene og frakte dem til steder der det trengs. Og så bruker data, de faktiske punktene der data er, du kommer til å få verdi ut av dataene.
Og i gamle dager er alt dette gjort i en individuell stil, men i dag kan det for eksempel være et analytisk miljø, og deretter utover det, et arkiv, en butikk, der vi legger dataene når vi ikke lenger trenger det og til slutt en reningsform for prosess. Hvordan ser du datamodellering passe inn i styringen av hele datalivets syklus?
Ron Huizenga: Det er et veldig godt spørsmål, og en ting jeg egentlig ikke hadde tid til å fordype meg i noen detaljer her i dag, i det hele tatt, det vi egentlig begynner å snakke om, er datalinje. Så det vi faktisk er i stand til å gjøre er at vi har en datalinjefunksjon i verktøyene våre, og som jeg sier, vi kan faktisk trekke ut noe av det fra ETL-verktøy, men du kan også kartlegge det bare ved å tegne avstamningen også. Noen av disse datamodellene eller databasene som vi har fanget opp og brakt inn i modeller, kan vi referere til konstruksjonene fra det i vår datataveldiagram.
Det vi kan gjøre er å trekke en datastrøm, som du sier, fra kilde til mål, og gjennom den samlede livssyklusen for hvordan data går over i de forskjellige systemene og hva du kommer til å finne er å la oss ta ansatte data - det er en av favorittene mine basert på et prosjekt som jeg gjorde for mange år siden. Jeg jobbet med en organisasjon som hadde medarbeidersdata i 30 forskjellige systemer. Det vi endte opp med å gjøre der - og Rebeccas dukket opp datastavl-lysbildet - dette er et ganske forenklet datatrafikk-lysbilde her, men det vi klarte å gjøre var å få inn alle datastrukturer, referere dem til diagrammet, og så kan faktisk begynne å se på hva er strømningene mellom, og hvordan er de forskjellige dataenhetene koblet sammen i en flyt? Og vi kan gå utover det også. Dette er en del av et datastrøm- eller avstandsdiagram som vi ser her. Hvis du vil gå utover det, har vi også forretningsarkitektdelen av denne suiten, og det samme gjelder der.
Hvilke som helst av datastrukturen vi har fanget i datamodelleringsmiljøet, kan det henvises til i forretningsmodelleringsverktøyet, slik at selv i forretningsmodelldiagrammer eller forretningsprosessdiagrammer kan du referere til individuelle datalagre hvis du ønsker å datamodelleringsmiljøet, og mens du bruker dem i mappene i forretningsprosessmodellen, kan du til og med spesifisere CRUD på disse også, om hvordan denne informasjonen enten konsumeres eller produseres, og så kan vi begynne å generere ting som konsekvens- og analyserapporter og diagrammer ut av det.
Det vi har som mål å komme til, og vi har mange muligheter allerede, men en av de tingene som vi slags har en slags målpost som vi ser på, når vi fortsetter å utvikle verktøyene våre fremover, er i stand til å kartlegge den ende-til-ende, organisatoriske datatrafikk og hele livssyklusen til data.
Malcolm Chisholm: OK. Rebecca, får jeg lov til en til?
Rebecca Jozwiak: Jeg vil tillate deg en til, Malcolm, gå foran.
Malcolm Chisholm: tusen takk. Tenker vi på styring av data og tenker på datamodellering, hvordan får vi disse to gruppene til å jobbe effektivt og forstå hverandre?
Eric Little: Vel, det er interessant, jeg tror det virkelig avhenger av organisasjonen, og det går tilbake til det tidligere konseptet mitt er, i de organisasjonene der initiativene var forretningsdrevet vi var bundet rett i. For eksempel ledet jeg en dataarkitektur teamet, men vi ble bundet rett inn med bedriftsbrukere, og vi hjalp dem faktisk til å gjøre opp sitt styringsprogram for data. Igjen, mer av en rådgivende tilnærming, men det er egentlig mer en forretningsfunksjon.
Det du virkelig trenger for å kunne gjøre det, er at du trenger datamodeller og arkitekter som virkelig forstår virksomhet, kan forholde seg til bedriftsbrukere og så ha hjulpet dem med å stå opp styringsprosessene rundt det. Virksomheten ønsker å gjøre det, men generelt sett har vi teknologikunnskapen for å kunne hjelpe dem med å skille seg ut de typene programmer. Det må virkelig være et samarbeid, men det trenger å være virksomhetseid.
Malcolm Chisholm: Ok, det er flott. Takk skal du ha.
Dr. Eric Little: OK.
Rebecca Jozwiak: Ok, tusen takk. Publikum medlemmer, jeg er redd for at vi ikke fikk spørsmålene dine, men jeg vil sørge for at de blir sendt videre til den aktuelle gjesten vi hadde på linjen i dag. Jeg vil takke så mye til Eric, Malcolm og Ron for at vi var våre gjester i dag. Dette var gode ting, folkens. Og hvis du likte dagens IDERA-webcast, vil IDERA også være med på en Hot Technologies neste onsdag hvis du vil være med, diskutere utfordringene med indeksering og Oracle, så et annet fascinerende tema.
Tusen takk, folkens, ta vare, så ser vi deg neste gang. Ha det.
