Af Techopedia Staff, 28. september 2016
Takeaway: Host Rebecca Jozwiak diskuterer løsninger til dataarkitektur med Eric Little fra OSTHUS, Malcolm Chisholm fra First San Francisco Partners og Ron Huizenga fra IDERA.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Rebecca Jozwiak: Mine damer og herrer, hej og velkommen til Hot Technologies i 2016. I dag diskuterer vi “Bygge en forretningsdrevet dataarkitektur”, bestemt et varmt emne. Mit navn er Rebecca Jozwiak, jeg vil være din vært for dagens webcast. Vi twitter med en hashtag af # HotTech16, så hvis du allerede er i Twitter, er du velkommen til at deltage også i det. Hvis du til enhver tid har spørgsmål, skal du sende dem til Q & A-ruden nederst til højre på din skærm, så sørger vi for, at de bliver besvaret. Hvis ikke, sørger vi for, at vores gæster får dem til dig.
Så i dag har vi en virkelig fascinerende lineup. En masse tunge mødre med os i dag. Vi har Eric Little, VP for datavidenskab fra OSTHUS. Vi har Malcolm Chisholm, chef for innovationschef, som er en rigtig cool titel til First San Francisco Partners. Og vi har Ron Huizenga, senior produktchef fra IDERA. Og du ved, IDERA er en rigtig fuld pakke med datastyrings- og modelleringsløsninger. Og i dag vil han give os en demo om, hvordan hans løsning fungerer. Men inden vi kommer til det, Eric Little, vil jeg give bolden videre til dig.
Eric Little: Okay, mange tak. Så jeg vil gennemgå et par emner her, som jeg tror kommer til at forholde sig til Rons tale lidt og forhåbentlig sætte scenen for nogle af disse emner også, nogle spørgsmål og spørgsmål.
Så det, der interesserede mig for, hvad IDERA gør, er, at jeg tror, de korrekt påpeger, at komplekse miljøer virkelig driver en masse forretningsværdier i dag. Og med komplekse miljøer mener vi komplekse datamiljøer. Og teknologien bevæger sig virkelig hurtigt, og det er svært at følge med i dagens forretningsmiljø. Så de mennesker, der arbejder i teknologirum, vil ofte se, at du har kunder, der arbejder med problemer med, ”Hvordan bruger jeg big data? Hvordan inkorporerer jeg semantik? Hvordan forbinder jeg nogle af disse nye ting med mine ældre data? ”Osv., Og den slags fører os i dag ind i disse fire v's af store data, som mange mennesker er temmelig velkendte med, og jeg forstår, at der kan være mere end fire undertiden - jeg har set så mange som otte eller ni - men normalt, når folk taler om ting som big data, eller hvis du taler om big data, ser du normalt på noget, der er slags virksomhedsskala. Og så vil folk sige, okay, ja, tænk på mængden af dine data, som normalt er i fokus - det er bare hvor meget du har. Datahastigheden har at gøre med enten hvor hurtigt jeg kan bevæge dem rundt, eller hvor hurtigt jeg kan spørge efter dem eller få svarene, og så videre. Og personligt tror jeg, at venstre side af det er noget, der løses og håndteres relativt hurtigt ved en masse forskellige tilgange. Men på højre side ser jeg en masse evner til forbedring og en masse nye teknologier, der virkelig kommer i forgrunden. Og det har virkelig at gøre med den tredje kolonne, datasorten.
Så med andre ord ser de fleste virksomheder i dag på strukturerede, semistrukturerede og ustrukturerede data. Billeddata begynder at blive et varmt emne, så at være i stand til at bruge computervision, se på pixels, være i stand til at skrabe tekst, NLP, enhedsekstraktion, du har grafinformation, der kommer ud af enten statistiske modeller, eller som kommer ud af semantisk modeller, har du relationelle data, der findes i tabeller, og så videre. Og så at samle alle disse data sammen og alle disse forskellige typer repræsenterer virkelig en stor udfordring, og du vil se dette i, du ved, i Gartner og andre mennesker, der slags følger de tendenser i branchen.
Og så er den sidste ting, som folk taler om i big data, ofte denne forestilling om gådefuldhed, som virkelig er usikkerheden i dine data, uklarheden ved dem. Hvor godt ved du, hvad dine data handler om, hvor godt forstår du hvad der er derinde, og ved du? Evnen til at bruge statistikker og evnen til at bruge en form for information omkring det, du måske ved eller til at bruge en eller anden kontekst, kan være af værdi der. Og så muligheden for at se på data på denne måde med hensyn til hvor meget du har, hvor hurtigt du har brug for at flytte dem rundt eller komme på dem, alle de typer data, du måtte have i din virksomhed, og hvor sikker du er om hvor det er, hvad det er, hvilken kvalitet det er i, og så videre. Dette kræver virkelig en stor, koordineret indsats nu mellem mange individer for at administrere deres data effektivt. Modellering af data bliver derfor stadig vigtigere i nutidens verden. Så gode datamodeller kører virkelig en stor succes i virksomhedsapplikationer.
Du har datakilder fra forskellige kilder, som vi sagde, hvilket virkelig kræver en masse forskellige slags integration. Så at trække det hele sammen er virkelig nyttigt at være i stand til at køre forespørgsler, f.eks. På tværs af adskillige typer datakilder, og trække information tilbage. Men for at gøre det har du brug for gode kortlægningsstrategier, og det kan derfor være en reel udfordring at kortlægge den slags data og følge med på disse kortlægninger. Og så har du dette problem med, og hvordan linker jeg mine gamle data til alle disse nye datakilder? Så antag at jeg har en graf, tager jeg alle mine relationelle data og lægger dem i graf? Normalt er det ikke en god ide. Så hvordan er det, at folk er i stand til at styre alle disse slags datamodeller, der foregår? Analyse skal virkelig køres på en masse af disse forskellige typer datakilder og kombinationer. Så de svar, der kommer ud af dette, de svar, som folk har brug for for virkelig at tage gode forretningsbeslutninger, er kritiske.
Så dette handler ikke kun om at bygge teknologi af hensyn til teknologien, det er virkelig, hvad skal jeg gøre, hvad kan jeg gøre med det, hvilken slags analyse kan jeg køre, og evnen derfor, som jeg allerede har gjort talte om, at trække disse ting sammen, for at integrere det er virkelig, virkelig vigtigt. Og en af disse typer analyser kører derefter på ting som fødereret søgning og forespørgsel. Det bliver virkelig et must. Dine forespørgsler skal normalt trådes på tværs af flere slags kilder og trække information tilbage på en pålidelig.
Det ene nøgleelement, der ofte, især mennesker vil se på centrale ting som semantiske teknologier - og dette er noget, jeg håber, Ron vil tale om lidt i IDERA-metoden - er, hvordan man adskiller eller administrerer modellag af dine data fra selve datalaget, fra de rå data? Så nede ved datalaget har du muligvis databaser, du har muligvis dokumentdata, du har muligvis regnearksdata, du har muligvis billeddata. Hvis du befinder dig i områder som farmaceutiske industrier, har du enorme mængder af videnskabelige data. Og derefter på toppen af dette søger folk normalt efter en måde at opbygge en model, der giver dem mulighed for hurtigt at integrere disse data, og virkelig når du leder efter data, nu er du ikke på udkig efter at trække alle data op i dit modellag, hvad du ser på modellaget, du skal gøre, er at give dig en dejlig logisk repræsentation af, hvad ting er, almindelige ordforråd, almindelige typer enheder og relationer, og evnen til virkelig at nå ud i de data, hvor de er. Så det skal sige, hvad det er, og det må sige, hvor det er, og det må sige, hvordan man skal hente det og bringe det tilbage.
Så dette har været en tilgang, der har været ret succesrig med at fremføre semantiske teknologier fremad, hvilket er et område, hvor jeg arbejder meget. Så et spørgsmål, som jeg ønskede at stille til Ron, og som jeg tror vil være nyttigt i Q & A-sektionen, er at se, hvordan opnås dette ved IDERA-platformen? Så er modellaget faktisk adskilt fra datalaget? Er de mere integrerede? Hvordan fungerer det, og hvad er nogle af de resultater og fordele, de ser af deres tilgang? Derfor bliver referencedata virkelig også kritiske. Så hvis du vil have denne slags datamodeller, hvis du vil være i stand til at sammenslutne og søge på tværs af ting, skal du virkelig have gode referencedata. Men problemet er, at referencedata kan være virkelig vanskelige at vedligeholde. Så ofte er navngivning af standarder i sig selv en vanskelig udfordring. En gruppe kalder noget X og en gruppe kalder noget Y, og nu har du problemet med, hvordan finder nogen X og Y, når de leder efter denne type information? Fordi du ikke bare ønsker at give dem en del af dataene, vil du give dem alt det, der er relateret. På samme tid ændres betingelserne, software udskrives, og så videre, hvordan holder du vedligeholdelse og vedligeholdes disse referencer over tid?
Og igen, semantiske teknologier, specifikt ved hjælp af ting som taksonomier og ordforråd, dataark, har givet en standard plads måde at gøre dette på, hvilket virkelig er meget robust, det bruger visse typer standarder, men databasefællesskabet har gjort dette for en længe også, bare på forskellige måder. Jeg tror, at en af nøglerne her er at tænke på, hvordan man måske bruger enhedsrelationsmodeller, hvordan man måske bruger grafmodeller eller en slags metode her, der virkelig vil give dig forhåbentlig en standardafstand til håndtering af dine referencedata. Og så er det naturligvis, når du først har referencerne, skal kortlægningsstrategierne styre en lang række navne og enheder. Så fageksperter kan ofte lide at bruge deres egne vilkår.
Så en udfordring i dette er altid, hvordan giver du nogen information, men gør det relevant for den måde, de taler om det? Så en gruppe kan have en måde at se på noget på, for eksempel kan du være en kemiker, der arbejder på et stof, og du kan være en strukturel biolog, der arbejder på det samme stof, og du kan have forskellige navne på de samme typer enheder der vedrører dit felt. Du er nødt til at finde ud af måder, hvorpå du kan bringe disse personlige terminologier sammen, fordi den anden tilgang er, at du er nødt til at tvinge folk til at droppe deres valgperiode og bruge en andens, som de ofte ikke kan lide. Et andet punkt her er, at det bliver vanskeligt at håndtere et stort antal synonymer, så der er mange forskellige ord i mange menneskers data, der kan henvise til den samme ting. Du har et referenceproblem der ved hjælp af et mange-til-én sæt af relationer. Specialiserede vilkår varierer fra branche til branche, så hvis du vil komme på en slags overordnet løsning til denne type datastyring, hvor let er det bærbart fra et projekt eller en applikation til en anden? Det kan være en anden udfordring.
Automation er vigtig, og det er også en udfordring. Det er dyrt at håndtere referencedata manuelt. Det er dyrt at skulle have manuelt kortlægning, og det er dyrt at have fageksperter stopper med at udføre deres daglige job og skal gå ind og konstant rette dataordbøger og genopdatere definitioner og så videre, og så videre. Repeterbare ordforråd viser virkelig meget værdi. Så dette er ordforråd ofte, som du kan finde eksternt til din organisation. Hvis du f.eks. Arbejder med råolie, vil der være visse former for ordforråd, som du kan låne fra open source-rum, det samme med lægemidler, det samme med bankindustrien og finansiel, det samme med masser af disse slags områder. Folk lægger genanvendelige, generiske, replikerbare ordforråder derude, så folk kan bruge dem.
Og igen, når jeg ser på IDERA-værktøjet, er jeg nysgerrig efter at se, hvordan de håndterer dette med hensyn til anvendelse af slags standarder. I semantikverdenen ser man ofte ting som SKOS-modeller, der giver standarder for mindst bredere end / smalere end forhold, og disse ting kan være vanskelige at gøre i ER-modeller, men du ved, ikke umuligt, det afhænger bare af hvor meget af det maskiner og den sammenkobling, som du kan håndtere i disse typer systemer.
Så til sidst ville jeg bare foretage en sammenligning med nogle semantiske motorer, som jeg ser i branchen, og venligst spørge Ron og prime ham lidt for at tale om måske hvordan IDERAs system er blevet brugt i forbindelse med enhver semantisk teknologi. Er det i stand til at blive integreret med tredobbelt butikker, grafdatabaser? Hvor let er det at bruge eksterne kilder, fordi den slags ting i den semantiske verden ofte kan lånes ved hjælp af SPARQL Endpoint? Du kan importere RDF- eller OWL-modeller direkte til din model - henvise tilbage til dem - så for eksempel genontologien eller proteinontologien, der kan leve et sted i sit eget rum med sin egen regeringsstruktur, og jeg kan simpelthen importere alle eller en del af det, som jeg har brug for det i mine egne modeller. Og jeg er nysgerrig efter at vide, hvordan IDERA nærmer sig dette spørgsmål. Skal du vedligeholde alt internt, eller er der måder at bruge andre former for standardiserede modeller og trække dem ind, og hvordan fungerer det? Og den sidste ting, jeg nævnte her, er, hvor meget manuelt arbejde der virkelig er involveret i at opbygge ordlisterne og metadataoplagrene?
Så jeg ved, at Ron vil vise os nogle demonstrationer om disse slags ting, som vil være rigtig interessant. Men de problemer, som jeg ofte ser at rådføre sig med kunder, er, at der opstår en masse fejl, hvis folk skriver i deres egne definitioner eller deres egne metadata. Så du får stavefejl, får fat-finger fejl, det er en ting. Du får også folk, som måske tager noget fra, du ved, bare Wikipedia eller en kilde, der ikke nødvendigvis er af den kvalitet, du muligvis vil have i din definition, eller din definition er kun fra en persons perspektiv, så den er ikke komplet, og det er ikke klart hvordan styringsprocessen fungerer. Styring er naturligvis et meget, meget stort problem, hver gang du taler om referencedata, og hver gang du taler om, hvordan dette kan passe ind i en persons stamdata, hvordan de bruger deres metadata, og snart.
Så jeg ville bare lægge nogle af disse emner derude. Dette er genstande, som jeg ser i forretningsområdet på tværs af mange forskellige slags konsulentopgaver og en masse forskellige rum, og jeg er virkelig interesseret i at se, hvad Ron vil vise os med IDERA for at påpege nogle af disse emner . Så tusind tak.
Rebecca Jozwiak: Tak så meget, Eric, og jeg kan virkelig godt lide din kommentar om, at der kan opstå mange fejl, hvis folk skriver deres egne definitioner eller metadata. Jeg ved i journalistikens verden, at der er et mantra, der "mange øjne laver få fejl", men når det kommer til praktiske anvendelser, er der for mange hænder i cookie-krukken, der har tendens til at efterlade dig med en masse ødelagte cookies, ikke?
Eric Little: Ja, og bakterier.
Rebecca Jozwiak: Ja. Med det vil jeg gå videre og give det videre til Malcolm Chisholm. Malcolm, ordet er dit.
Malcolm Chisholm: Mange tak, Rebecca. Jeg vil gerne se lidt på det, Eric har talt om, og tilføje til, slags, nogle få observationer, som du ved, Ron måske være interesseret i at svare på også ved at tale om ”Mod forretningsdrevet dataarkitektur ”- hvad betyder det at være forretningsdrevet, og hvorfor er det vigtigt? Eller er det bare en form for hype? Det tror jeg ikke.
Hvis vi ser på, hvad der foregår siden, ved du, mainframe-computere blev virkelig tilgængelige for virksomheder - siger omkring 1964 - til i dag, kan vi se, at der er sket mange ændringer. Og disse ændringer vil jeg sammenfatte som et skift fra procescentricitet til datacentricitet. Og det er det, der gør forretningsdrevne dataarkitekturer så vigtige og så relevante for i dag. Og jeg tror, du ved, det er ikke kun et buzzword, det er noget, der er helt ægte.
Men vi kan sætte pris på det lidt mere, hvis vi dykker ned i historien, så at gå tilbage i tiden, tilbage tilbage til 1960'erne og i et stykke tid derefter dominerede mainframes. Disse gav derefter plads til pc'er, hvor du faktisk havde oprør af brugerne, da pc'er kom ind. Oprør mod centraliseret it, som de mente ikke opfyldte deres behov, var ikke smidige nok. Det gav hurtigt anledning til distribueret computing, da pc'er blev koblet sammen. Og så begyndte internettet at ske, hvilket slørede virksomhedens grænser - det kunne nu interagere med parter uden for sig selv med hensyn til dataudveksling, som ikke havde fundet sted før. Og nu er vi gået ind i en æra med sky og big data, hvor skyen er platforme, der virkelig commoditizing infrastruktur, og så vi forlader, som det var, IT af behovet for at køre big data centre, fordi du ved, vi Vi har den skykapacitet, der er tilgængelig for os, og sammen med de store data, som Eric har, så ved du, så veltalende diskuteret. Og som vi ser, da skiftet i teknologi skete, er det blevet mere datacentrisk, vi er ligeglad med data. Ligesom med internettet, hvordan data udveksles. Med big data er de fire eller flere V'er af selve dataene.
På samme tid, og måske mere vigtigt, ændrede sager til forretningsbrug. Da computere først blev introduceret, blev de brugt til at automatisere ting som bøger og poster. Og alt, hvad der var en manuel proces, der involverede hovedbøger eller lignende, blev i det væsentlige programmeret i hus. Det skiftede i 80'erne til tilgængeligheden af operationelle pakker. Du behøvede ikke at skrive din egen lønningsliste mere, du kunne købe noget, der gjorde det. Det resulterede i en stor nedskæring på det tidspunkt eller omstrukturering i mange it-afdelinger. Men så dukket forretningsoplysning med ting som datavarehaller, mest i 90'erne. Efterfulgt af dotcom forretningsmodeller, som naturligvis var en stor vanvid. Derefter MDM. Med MDM begynder du at se, at vi ikke tænker på automatisering; vi fokuserer faktisk bare på at sammenlægge data som data. Og derefter analyser, der repræsenterer den værdi, du kan få ud af dataene. Og inden for analyse ser du virksomheder, der er meget succesrige, hvis kerneforretningsmodel drejer sig om data. Google, Twitter, Facebook ville være en del af det, men du kan også argumentere for, at Walmart er det.
Og derfor tænker virksomheden nu virkelig på data. Hvordan kan vi få værdi ud af data? Hvordan data kan drive virksomheden, strategien, og vi er i datidens gyldne tidsalder. Så i betragtning af hvad, hvad sker der med hensyn til vores dataarkitektur, hvis data ikke længere betragtes som blot den udstødning, der kommer ud af applikationernes bagenden, men virkelig er central for vores forretningsmodeller? Nå, en del af det problem, vi har med at opnå det er IT, er virkelig fast i fortiden med systemudviklingen livscyklus, som var en konsekvens af, at vi hurtigt skulle håndtere den procesautomatiseringsfase i den tidlige alder af IT, og arbejde i projekter er en lignende ting. Til IT - og dette er lidt af en karikatur - men det, jeg prøver at sige, er, at nogle af hindringerne for at få en forretningsdrevet dataarkitektur er, fordi vi, slags, ukritisk har accepteret en kultur inden for it som stammer fra en svunnen tid.
Så alt er et projekt. Fortæl mig dine krav i detaljer. Hvis tingene ikke fungerer, er det fordi du ikke har fortalt mig dine krav. Det fungerer ikke i dag med data, fordi vi ikke starter med ikke-automatiserede manuelle processer eller en, du ved, en teknisk konvertering af forretningsprocesser, vi starter meget ofte med allerede eksisterende produktionsdata, som vi prøver at få værdi ud af. Men ingen, der sponsorerer et datacentrisk projekt, forstår virkelig disse data dybtgående. Vi skal foretage dataopdagelse, vi skal foretage kildedataanalyse. Og det stemmer ikke rigtig med systemudviklingen, ved du - vandfald, SDLC-livscyklus - som Agile, vil jeg fastholde, er en slags en bedre version af det.
Og hvad der fokuseres på er teknologi og funktionalitet, ikke data. For eksempel, når vi tester i en testfase, vil det typisk være, fungerer min funktionalitet, lad os sige min ETL, men vi tester ikke dataene. Vi tester ikke vores antagelser om, at kildedataene kommer ind. Hvis vi gjorde det, ville vi være i bedre form, og som en person, der har udført datalagerprojekter og lidt under opstrømsændringer, og som sprænger mine ETL'er, ville jeg værdsætte det. Og det, vi gerne vil se, er faktisk testning som et indledende skridt til kontinuerlig overvågning af produktionsdatakvalitet. Så vi har her en masse holdninger, hvor det er vanskeligt at opnå den forretningsdrevne dataarkitektur, fordi vi er betinget af æraen med procescentricitet. Vi er nødt til at foretage en overgang til datacentricitet. Og dette er ikke en total overgang, ved du, der er stadig meget procesarbejde at gøre derude, men vi tænker ikke rigtig på datacentriske vilkår, når vi har brug for det, og de omstændigheder, der opstår, når vi virkelig er forpligtet til at gøre det.
Nu er virksomheden klar over værdien af dataene, de vil låse dataene op, så hvordan skal vi gøre det? Så hvordan gør vi overgangen? Nå, vi sætter data i hjertet af udviklingsprocesser. Og vi lader virksomheden føre med informationskrav. Og vi forstår, at ingen forstår de eksisterende kildedata i starten af projektet. Du kan argumentere for, at datastrukturen og selve dataene kom der hen gennem henholdsvis IT og operationer, så vi skulle vide det, men det gør vi faktisk ikke. Dette er datacentrisk udvikling. Så vi er nødt til at overveje, hvor skal vi og hvordan gør vi modellering af data i en datacentrisk verden, vi skal have feedback-løkker til brugerne med hensyn til at forbedre deres informationskrav, som vi gør dataopdagelse og dataprofilering, forudse kildedataanalyse, og når vi gradvist får mere og mere sikkerhed om vores data. Og nu taler jeg om et mere traditionelt projekt som et MDM-hub eller et datavarehus, ikke nødvendigvis big data-projekterne, selvom dette stadig er, mener jeg, temmelig tæt på det. Og så inkluderer disse feedback-sløjfer datamodellerne, du ved, gradvist at fremme deres datamodel og interagere med brugerne for at sikre, at informationskravene forbedres baseret på hvad der er muligt, hvad der er tilgængeligt, fra kildedataene, da de bedre forstår det, så det er ikke længere et tilfælde, hvor datamodellen er, ved du, i en tilstand, der enten ikke er der eller helt udført, det er en gradvis, der bringer det i fokus.
Tilsvarende mere nedstrøms for det har vi kvalitetssikring, hvor vi udvikler regler for datakvalitetstest for at sikre, at dataene er inden for de parametre, som vi antager. Som indgang henviste Eric til ændringer i referencedata, hvilket kan ske. Du ønsker som sådan ikke at være et downstream-offer for en slags, ustyret ændring i dette område, så reglerne for kvalitetssikring kan gå i postproduktion, kontinuerlig datakvalitetskontrol. Så du kan begynde at se, om vi vil være datacentriske, hvordan vi gør datacentrisk udvikling er ganske anderledes end den funktionsbaserede SDLC og Agile. Og så skal vi også være opmærksomme på forretnings synspunkter. Vi har - og igen dette gentager det, Eric sagde - vi har en datamodel, der definerer en datahistorisk plan for vores database, men på samme tid har vi brug for de konceptuelle modeller, de forretningsmæssige syn på data, som traditionelt ikke er blevet udført i fortiden. Vi har undertiden troet, at datamodellen kan gøre det hele, men vi er nødt til at have det konceptuelle syn, semantikken og se på dataene, gøre det gennem et abstraktionslag, der oversætter lagringsmodellen til virksomheden udsigt. Og igen bliver alle de ting, Eric talte om i form af semantik, vigtigt at gøre det, så vi har faktisk yderligere modelleringsopgaver. Jeg tror, det er, du ved, interessant, hvis du er kommet op i rækkerne som en datamodeller som jeg gjorde, og igen, noget nyt.
Og endelig vil jeg gerne sige, at den større arkitektur også er nødt til at afspejle denne nye virkelighed. Traditionel kunde-MDM er for eksempel slags, okay, lad os få vores kundedata til et hub, hvor vi, du ved, kan give mening af det med hensyn til virkelig bare datakvalitet til back office-applikationer. Hvilket fra en forretningsstrategisk synspunkt er slags et gab. I dag ser vi dog på MDM-hubs hos kunder, der har yderligere kundeprofildata i sig, ikke kun de statiske data, som så virkelig har en tovejsgrænseflade med kundens transaktionsapplikationer. Ja, de understøtter stadig back office, men nu ved vi også om vores adfærd hos vores kunder. Dette er dyrere at bygge. Dette er mere kompliceret at bygge. Men det er forretningsdrevet på en måde, som den traditionelle kunde-MDM ikke er. Du handler med en orientering mod virksomheden mod enklere design, der er lettere at implementere, men for virksomheden er det dette, de vil se. Vi er virkelig i en ny æra, og jeg tror, at der er et antal niveauer, som vi er nødt til at svare på den forretningsdrivende dataarkitektur, og jeg synes, det er en meget spændende tid at gøre ting.
Så tak, tilbage til dig Rebecca.
Rebecca Jozwiak: Tak Malcolm, og jeg nød virkelig, hvad du sagde om datamodeller, der skal fodre forretningsvisningen, fordi, i modsætning til hvad du sagde, hvor IT holdt tøjlerne så længe, og det er bare slags ikke tilfældet mere og at kulturen behøver at skifte. Og jeg er temmelig sikker på, at der var en hund i baggrunden, der var 100% enig med dig. Og med det vil jeg give bolden videre til Ron. Jeg er virkelig spændt over at se din demo. Ron, ordet er dit.
Ron Huizenga: Mange tak, og inden vi springer ind i det, vil jeg gennemgå et par lysbilleder og derefter en lille smule demo, fordi, som Eric og Malcolm har påpeget, dette er et meget bredt og dybt emne, og med det, vi taler om i dag, skraber vi bare overfladen af det, fordi der er så mange aspekter og så mange ting, som vi virkelig skal overveje og se på fra en forretningsdrevet arkitektur. Og vores tilgang er virkelig at gøre den modelbaserede og udlede ægte værdi ud af modellerne, fordi du kan bruge dem som et kommunikationsmiddel samt et lag for at aktivere andre systemer. Uanset om du laver serviceorienteret arkitektur eller andre ting, bliver modellen virkelig livsnerven i det, der foregår, med alle metadata omkring det og de data, du har i din virksomhed.
Hvad jeg imidlertid vil tale om, er næsten at tage dette et skridt tilbage, fordi Malcolm havde berørt noget af historien om den måde, løsninger har udviklet sig, og den type ting. En måde at virkelig påpege, hvor vigtigt det er at have en lyddataarkitektur, er en brugssag, som jeg plejede at møde meget ofte, da jeg konsulterede, før jeg kom ind i en produktstyringsrolle, og det var, at jeg ville gå ind i organisationer om de foretog forretningsforvandling eller blot erstattede nogle eksisterende systemer og den type ting, og det blev meget tydeligt tydeligt af, hvordan dårligt organisationer forstår deres egne data. Hvis du tager en bestemt brugssag som denne, uanset om du er en konsulent, der går ind, eller måske er det en person, der lige er startet med en organisation, eller din organisation er blevet opbygget gennem årene med at erhverve forskellige virksomheder, hvad du ender op med er et meget komplekst miljø meget hurtigt med en række nye forskellige teknologier såvel som ældre teknologi, ERP-løsninger og alt andet.
Så en af de ting, vi virkelig kan gøre med vores modelleringsmetode, er at besvare spørgsmålet om, hvordan får jeg mening af alt dette? Vi kan virkelig begynde at dele informationerne sammen, så virksomheden kan udnytte de oplysninger, vi har korrekt. Og det kommer ud til, hvad er det, vi har derude i disse miljøer? Hvordan kan jeg bruge modellerne til at køre de oplysninger, jeg har brug for, og forstå disse oplysninger bedre? Og så har vi de traditionelle typer metadata til alle de forskellige ting, som de relationelle datamodeller, og vi er vant til at se ting som definitioner og dataarmbøger, du ved, datatyper og den type ting. Men hvad med yderligere metadata, som du ønsker at fange for virkelig at give dem endnu mere mening? F.eks. Hvilke enheder der virkelig er de kandidater, der skal være referencedataobjekter, som skal være masterdataadministrationsobjekter og disse typer ting og binde dem sammen. Og hvordan flyder informationen gennem organisationen? Data flyder fra, hvordan de forbruges fra både et processynspunkt, men også datalinje med hensyn til informationsrejsen gennem vores forretninger, og hvordan de kommer vej gennem de forskellige systemer eller gennem datalagrene, så vi ved når vi bygger I-løsningen eller disse typer ting, at vi faktisk bruger de rigtige oplysninger til den aktuelle opgave.
Og så er det meget vigtigt, hvordan kan vi få alle disse interessenter til at samarbejde, og især erhvervsinteressenterne, fordi det er dem, der giver os den rigtige betydning af, hvad disse data er. I slutningen af dagen ejer virksomheden dataene. De leverer definitionerne for ordforrådene og tingene, som Eric talte om, så vi har brug for et sted at binde alt dette sammen. Og den måde, vi gør det på, er gennem vores datamodellering og databasearkitekturer.
Jeg kommer til at røre ved et par ting. Jeg vil tale om ER / Studio Enterprise Team Edition. Først og fremmest vil jeg tale om dataarkitekturproduktet, hvor vi udfører datamodellering og den type ting, men der er mange andre komponenter i suiten, som jeg bare vil røre meget kort om. Du vil se et uddrag af Business Architect, hvor vi kan udføre konceptuelle modeller, men vi kan også udføre forretningsprocesmodeller, og vi kan binde disse processmodeller til at sammenkæde de faktiske data, vi har i vores datamodeller. Det hjælper os virkelig med at bringe det slips sammen. Software Arkitekt giver os mulighed for at udføre yderligere konstruktioner såsom nogle UML-modellering og disse typer ting for at give understøttende logik til nogle af disse andre systemer og processer, som vi taler om. Men meget vigtigt, når vi bevæger os ned, har vi depotet og teamserveren, og jeg vil tale om det som slags to halvdele af den samme ting. Opbevaringsstedet er, hvor vi gemmer alle de modellerede metadata såvel som alle forretningsmetadataene med hensyn til forretningsordliste og vilkår. Og fordi vi har dette depot-baserede miljø, kan vi derefter sy alle disse forskellige ting sammen i det samme miljø, og så kan vi faktisk stille dem til rådighed til forbrug, ikke kun for de tekniske folk, men også for forretningsfolk. Og det er sådan, vi virkelig begynder at drive samarbejde.
Og så er det sidste stykke, jeg vil tale om kort, når du går ind i disse miljøer, det er ikke kun databaser, du har derude. Du kommer til at have et antal databaser, datalagre, du vil også have en masse, hvad jeg vil kalde, arv artefakter. Måske har folk brugt Visio eller andre diagrammer til at kortlægge nogle ting. Måske har de haft andre modelleringsværktøjer og den type ting. Så hvad vi kan gøre med MetaWizard er faktisk at udtrække nogle af disse oplysninger og bringe dem ind i vores modeller, gøre dem aktuelle og være i stand til at bruge den, forbruge den på en aktuel måde igen i stedet for bare at have den sidder derude. Det bliver nu en aktiv del af vores arbejdsmodeller, hvilket er meget vigtigt.
Når du går ind i en organisation, som jeg sagde, er der mange forskellige systemer derude, en masse ERP-løsninger, uoverensstemmende afdelingsløsninger. Mange organisationer bruger også SaaS-løsninger, der også styres og styres eksternt, så vi kontrollerer ikke databaserne og de slags ting i værter på disse, men vi er stadig nødt til at vide, hvordan disse data ser ud, og selvfølgelig metadataene deromkring. Hvad vi også finder, er en masse forældede arvssystemer, der ikke er blevet renset på grund af den projektbaserede tilgang, som Malcolm havde talt om. Det er forbløffende, hvordan organisationer i de senere år vil spin up projekter, de erstatter et system eller en løsning, men der er ofte ikke nok projektbudget tilbage til at nedlægge de forældede løsninger, så nu er de bare i vejen. Og vi er nødt til at finde ud af, hvad vi rent faktisk kan slippe af med i vores miljø såvel som hvad der er nyttigt fremover. Og det er knyttet til den dårlige nedlukningsstrategi. Det er en del af den samme ting.
Hvad vi også finder, fordi mange organisationer er bygget op fra alle disse forskellige løsninger, er vi ser en række punkt-til-punkt-grænseflader med en masse data, der bevæger sig rundt flere steder. Vi er nødt til at være i stand til at rationalisere det og finde ud af den datalinje, som jeg kort nævnte før, så vi kan have en mere sammenhængende strategi såsom udnyttelse af serviceorienteret arkitektur, virksomheds servicebusser og de slags ting, for at levere den rigtige information til en type-udgave-og-abonnementstype, som vi bruger korrekt i hele vores forretning. Og så er vi selvfølgelig stadig nødt til at foretage en form for analyse, uanset om vi bruger datavarehuse, datamarkeringer med traditionel ETL eller bruger nogle af de nye datasøer. Det hele kommer ned på den samme ting. Det er alle data, uanset om det er big data, uanset om det er traditionelle data i relationelle databaser, vi er nødt til at bringe alle disse data sammen, så vi kan administrere dem og vide, hvad vi har at gøre med gennem vores modeller.
Igen, den kompleksitet, vi skal gøre, er, at vi har et antal trin, som vi ønsker at være i stand til at gøre. Først og fremmest går du ind, og du har muligvis ikke disse tegninger af, hvordan det informationslandskab ser ud. I et datamodelleringsværktøj som ER / Studio Data Architect, skal du først lave en masse reverse engineering med hensyn til lad os pege på de datakilder, der er derude, bringe dem ind og derefter faktisk sy dem sammen til mere repræsentative modeller, der repræsenterer hele virksomheden. Den vigtige ting er, er, at vi ønsker at være i stand til at nedbryde disse modeller også langs forretningsgrene, så vi kan forholde os til dem i mindre bidder, som vores forretningsfolk også kan forholde sig til, og vores forretningsanalytikere og andre interessenter, der arbejder på det.
At navngive standarder er ekstremt vigtige, og jeg taler om det på et par forskellige måder her. At navngive standarder med hensyn til, hvordan vi navngiver ting i vores modeller. Det er temmelig let at gøre i logiske modeller, hvor vi har en god navnekonvention og en god datakatalog for vores modeller, men så ser vi også forskellige navnekonventioner for mange af disse fysiske modeller, som vi bringer ind. Når vi reverse engineer, ofte ser vi forkortede navne og den type ting, som jeg vil tale om. Og vi er nødt til at oversætte dem tilbage til meningsfulde engelske navne, der er meningsfulde for virksomheden, så vi kan forstå, hvad alle disse databaser er, som vi har i miljøet. Og så er universelle kortlægninger, hvordan vi syr dem sammen.
Oven på det vil vi derefter dokumentere og definere yderligere, og det er her, vi kan klassificere vores data yderligere med noget, der hedder Vedhæftede filer, som jeg viser dig et par lysbilleder på. Og derefter lukning af løkken, vil vi anvende den forretningsmæssige betydning, som er det sted, hvor vi binder vores forretningsordlister og kan forbinde dem til vores forskellige modelartefakter, så vi ved, når vi taler om en bestemt forretningsbetegnelse, hvor det er implementeret i vores data i hele organisationen. Og så til sidst har jeg allerede talt om det faktum, at vi har brug for alt dette for at være depotbaseret med en masse samarbejds- og publiceringsfunktioner, så vores interessenter kan udnytte det. Jeg vil tale om reverse engineering relativt hurtigt. Jeg har allerede slags givet dig en meget hurtig fremhævning af det. Det viser jeg dig i en faktisk demonstration bare for at vise dig nogle af de ting, som vi kan bringe derinde.
Og jeg vil tale om nogle af de forskellige modeltyper og diagrammer, som vi ville fremstille i denne type scenarier. Vi gør selvfølgelig de konceptuelle modeller i mange tilfælde; Det vil jeg ikke bruge meget tid på. Jeg vil virkelig tale om logiske modeller, fysiske modeller og de specialiserede typer modeller, som vi kan skabe. Og det er vigtigt, at vi kan oprette disse alle i den samme modelleringsplatform, så vi kan sy dem sammen. Det inkluderer dimensionelle modeller og også modeller, der bruger nogle af de nye datakilder, såsom NoSQL, som jeg viser dig. Og så, hvordan ser datalinjemodellen ud? Og hvordan kan vi sy disse data til en forretningsprocesmodel, er det, vi skal tale om næste gang.
Jeg vil skifte over til et modelleringsmiljø her bare for at give dig et meget højt og hurtigt overblik. Og jeg mener, du skulle kunne se min skærm nu. Først og fremmest vil jeg tale om bare en traditionel type datamodel. Og den måde, vi ønsker at organisere modellerne på, når vi bringer dem ind, er, at vi vil være i stand til at nedbryde dem. Så det, du ser her på venstre side, er, at vi har logiske og fysiske modeller i netop denne modelfil. Den næste ting er, er, at vi kan nedbryde det langs forretningsnedbrydelserne, så det er derfor, du får vist mapperne. De lyseblå er logiske modeller, og de grønne er fysiske modeller. Og vi kan også bore ned, så inden for ER / Studio, hvis du har en forretningsnedbrydning, kan du gå så mange niveauer dybe eller undermodeller, som du vil, og ændringer, du foretager på de lavere niveauer, reflekteres automatisk ved det højere niveauer. Så det bliver et meget kraftfuldt modelleringsmiljø meget hurtigt.
Noget, som jeg også vil påpege, det er meget vigtigt at begynde at samle disse oplysninger sammen, er at vi kan have flere fysiske modeller, der også svarer til en logisk model. Ganske ofte har du muligvis en logisk model, men du kan have fysiske modeller på forskellige platforme og den type ting. Måske er det en SQL Server-forekomst af det, måske er en anden en Oracle-instans. Vi har evnen til at binde alt dette sammen i det samme modelleringsmiljø. Og der igen, hvad jeg har her, er en faktisk datalagermodel, der igen kan være i det samme modelleringsmiljø, eller vi kan også have det i depotet og forbinde det også på tværs af forskellige ting.
Hvad jeg virkelig ønskede at vise dig om dette er nogle af de andre ting og andre varianter af de modeller, vi får ind på. Så når vi kommer ind i en traditionel datamodel som denne, er vi vant til at se de typiske enheder med kolonnerne og metadataene og den type ting, men det synspunkt varierer meget hurtigt, når vi begynder at håndtere nogle af disse nyere NoSQL-teknologier, eller som nogle mennesker stadig gerne kalder dem, store datateknologier.
Så lad os nu sige, at vi også har Hive i vores miljø. Hvis vi reverse engineer fra et Hive-miljø - og vi kan sende og reverse engineer fra Hive med nøjagtigt det samme modelleringsværktøj - ser vi noget, der er lidt anderledes. Vi ser stadig alle dataene som konstruktioner der, men vores TDL er forskellige. De af jer, der er vant til at se SQL, hvad du vil se nu, er Hive QL, som er meget SQL-lignende, men ud af det samme værktøj kan du nu begynde at arbejde med de forskellige scripting-sprog. Så du kan modellere i dette miljø, generere det ud i Hive-miljøet, men lige så vigtigt kan du i det scenarie, som jeg har beskrevet, vende det hele ind og give mening af det og begynde at sy det sammen .
Lad os tage en anden, der er lidt anderledes. MongoDB er en anden platform, som vi støtter indfødt. Og når du begynder at komme ind i JSON-typer miljøer, hvor du har dokumentlagre, er JSON et andet dyr, og der er konstruktioner i det, der ikke svarer til relationelle modeller. Du begynder snart at beskæftige dig med begreber som indlejrede objekter og indlejrede arrays af objekter, når du begynder at forhøre JSON, og disse begreber findes ikke i den traditionelle relationelle notation. Hvad vi har gjort her, er, at vi faktisk har udvidet notationen og vores katalog for at kunne håndtere det i det samme miljø.
Hvis du ser over til venstre her, i stedet for at se ting som enheder og borde, kalder vi dem objekter. Og du ser forskellige notationer. Du ser stadig de typiske typer af referencemeddelelser her, men disse blå enheder, som jeg viser i dette særlige diagram, er faktisk indlejrede objekter. Og vi viser forskellige kardinaliteter. Diamantkardinaliteten betyder, at det er et objekt i den ene ende, men kardinaliteten ved det ene betyder, at vi har inden for udgiveren, hvis vi følger det forhold, vi har et indlejret adresseobjekt. Ved at forhøre JSON har vi fundet, at det er nøjagtigt den samme struktur af objekter, der er indlejret i protektoren, men det er faktisk indlejret som en række objekter. Vi ser det, ikke kun gennem konnektorerne i sig selv, men hvis du ser på de faktiske enheder, vil du se, at du ser adresser under skytshelgen, der også klassificeres som en række objekter. Du får et meget beskrivende synspunkt på, hvordan du kan bringe det ind.
Og igen, nu, hvad vi har set hidtil på kun få sekunder er traditionelle relationelle modeller, der er på flere niveauer, vi kan gøre det samme med Hive, vi kan gøre det samme med MongoDB og andre big data kilder som godt. Hvad vi også kan gøre, og jeg vil bare vise dig dette meget hurtigt, jeg talte om det faktum at bringe ting ind fra andre forskellige områder. Jeg vil antage, at jeg vil importere en model fra en database eller reverse engineer den, men jeg vil bringe den ind fra eksterne metadata. Bare for at give dig et meget hurtigt synspunkt på alle de forskellige typer ting, som vi kan begynde at bringe ind.
Som du ser, har vi et utal af ting, som vi faktisk kan bringe metadataene ind i vores modelleringsmiljø med. Start med ting som endda Amazon Redshift, Cassandra, en masse af de andre big data platforme, så du kan se en masse af disse opført. Dette er i alfabetisk rækkefølge. Vi ser en masse store datakilder og den type ting. Vi ser også en masse traditionelle eller ældre modelleringsmiljøer, som vi faktisk kan bringe disse metadata igennem. Hvis jeg går igennem her - og jeg ikke vil bruge tid på alle dem - ser vi en masse forskellige ting, som vi kan bringe det ind fra, hvad angår modelleringsplatforme og dataplatformer. Og noget, der er meget vigtigt at indse her, er en anden del, som vi kan gøre, når vi begynder at tale om datalinje, på Enterprise Team Edition kan vi også forhøre ETL-kilder, hvad enten det er ting som Talend eller SQL Server Information Services kortlægning, vi kan faktisk bringe det ind for at starte vores datalinjediagrammer også og tegne et billede af, hvad der sker i disse transformationer. Alt i alt har vi over 130 af disse forskellige broer, der faktisk er en del af Enterprise Team Edition-produktet, så det hjælper os virkelig med at samle alle artefakter i ét modelleringsmiljø meget hurtigt.
Sidst, men ikke mindst, vil jeg også tale om det faktum, at vi ikke kan miste synet af det faktum, at vi har brug for de andre typer konstruktioner, hvis vi laver datavarehus eller andre typer analyser. Vi vil stadig have evnen til at gøre ting som dimensionelle modeller, hvor vi har faktaborde, og vi har dimensioner og de slags ting. Én ting, jeg også vil vise dig, er, at vi også kan have udvidelser til vores metadata, der hjælper os med at kategorisere, hvad der er typerne af dimensioner og alt andet. Så hvis jeg ser på den dimensionelle datafane her, for eksempel på en af disse, registrerer den faktisk automatisk, baseret på det modelmønster, den ser, og giver dig et udgangspunkt for, om det tror, det er en dimension eller en faktabord. Men ud over det, hvad vi kan gøre, er inden for dimensionerne, og den type ting, vi har endda forskellige typer dimensioner, som vi kan bruge til at klassificere dataene i en datalager-miljø også. Så meget kraftfulde funktioner, at vi syer dette helt sammen.
Jeg vil hoppe ind i denne, da jeg er i demomiljøet lige nu og viser dig et par andre ting, før jeg springer tilbage til lysbillederne. En af de ting, som vi for nylig har tilføjet til ER / Studio Data Architect, er, at vi er løbet ind i situationer - og dette er en meget almindelig brugssag, når du arbejder med projekter - udviklere tænker med hensyn til objekter, mens vores data modellerere har en tendens til at tænke i form af tabeller og enheder og den type ting. Dette er en meget forenklet datamodel, men det repræsenterer et par grundlæggende koncepter, hvor udviklerne eller endda forretningsanalytikere eller forretningsbrugere måske tænker på dem som forskellige objekter eller forretningskoncepter. Det har været meget vanskeligt at klassificere disse indtil nu, men hvad vi faktisk har gjort i ER / Studio Enterprise Team Edition, i 2016-udgivelsen, er vi nu har et koncept, der hedder Business Data Objects. Og hvad det gør det muligt for os at gøre, det giver os mulighed for at indkapsle grupper af enheder eller tabeller til ægte forretningsobjekter.
For eksempel, hvad vi har her på denne nye visning er Indkøbsordrerhovedet og ordrelinjen er blevet trukket sammen nu, de er indkapslet som et objekt, vi ville tænke på dem som en enhed af arbejde, når vi fortsætter dataene, og vi bringer dem sammen, så det er nu meget let at relatere det til forskellige målgrupper. De kan genanvendes i hele modelleringsmiljøet. De er et sandt objekt, ikke kun en tegningskonstruktion, men vi har også den ekstra fordel, at når vi faktisk kommunikerer fra modelleringsperspektiv, kan vi selektivt kollapse eller udvide dem, så vi kan producere en sammenfattet visning til dialoger med bestemte interessentgrupper, og vi kan naturligvis også beholde den mere detaljerede visning, som vi ser her for flere af de tekniske målgrupper. Det giver os virkelig et rigtig godt kommunikationsmiddel. Det, vi ser nu, er at kombinere flere forskellige modelltyper, udvide dem med konceptet med forretningsdataobjekter, og nu skal jeg tale om, hvordan vi rent faktisk anvender en mere mening på disse typer ting, og hvordan vi syer dem sammen i vores overordnede miljøer.
Jeg prøver bare at finde min WebEx tilbage her, så jeg kan gøre det. Og der går vi tilbage til Hot Tech-lysbillederne. Jeg vil bare spole frem et par lysbilleder her, fordi du allerede har set disse i selve modeldemonstrationen. Jeg vil meget hurtigt tale om at navngive standarder. Vi ønsker at anvende og håndhæve forskellige navnestandarder. Det, vi gerne vil gøre, er, at vi faktisk har mulighed for at gemme navnestandardskabeloner i vores depoter for dybest set at opbygge den betydning gennem ord eller sætninger eller endda forkortelser og binde dem tilbage til en meningsfuld engelsk type ord. Vi vil bruge forretningsbetingelser, forkortelserne for hver, og vi kan specificere rækkefølgen, sagerne og tilføje præfikser og suffikser. Den typiske brugstilfælde til dette er typisk, når folk har opbygget en logisk model og derefter faktisk fremad for at skabe en fysisk model, hvor de måske har brugt forkortelser og alt andet.
Den smukke ting er, at det er lige så magtfuldt, endnu mere kraftfuldt i omvendt retning, hvis vi bare kan fortælle, hvad nogle af disse navnestandarder var på nogle af disse fysiske databaser, som vi har udviklet omvendt, kan vi tage disse forkortelser, gøre dem til længere ord, og bringe dem bagud i engelske sætninger. Vi kan faktisk nu udlede rigtige navne på, hvordan vores data ser ud. Som jeg siger, den typiske brugssag er, at vi ville bevæge os fremad, logiske til fysiske, og kortlægge datalagrene og den type ting. Hvis du ser på skærmbilledet i højre side, ser du, at der er forkortede navne fra kildenavnene, og når vi har brugt en navngivningsstandardskabelon, har vi faktisk flere fulde navne. Og vi kunne placere mellemrum og alt det der, hvis vi vil, afhængigt af den navngivende standardskabelon, vi brugte. Vi kan få det til at se ud, men vi vil have det til at se ind i vores modeller. Først når vi ved, hvad der hedder noget, kan vi faktisk begynde at knytte definitioner til det, for medmindre vi ved, hvad det er, hvordan kan vi anvende en mening på det?
Den dejlige ting er, er, at vi faktisk kan påberåbe os dette, når vi laver alle slags ting. Jeg talte om reverse engineering, vi kan faktisk påkalde navnestandardskabeloner samtidig, når vi laver reverse engineering. Så i et sæt trin gennem en guide, hvad vi er i stand til, er, hvis vi ved, hvad konventionerne er, kan vi omvendt konstruere en fysisk database, det vil bringe den tilbage som fysiske modeller i et modelleringsmiljø, og det er vil også anvende disse navnekonventioner. Så vi vil se, hvad de engelske lignende repræsentationer af navne er i den tilsvarende logiske model i miljøet. Vi kan også gøre det og kombinere det med XML-skema-generation, så vi kan tage en model og endda skubbe den ud med vores forkortelser, uanset om vi laver SOA-rammer eller den type ting, så vi kan også skubbe forskellige navnekonventioner ud som vi faktisk har gemt i selve modellen. Det giver os en masse meget stærke kapaciteter.
Igen, her er et eksempel på, hvordan det ville se ud, hvis jeg havde en skabelon. Denne viser faktisk, at jeg havde EMP for "medarbejder, " SAL for "løn, " PLN for "plan" i en konvention om navnestandarder. Jeg kan også anvende dem til at få dem til at køre interaktivt, da jeg bygger ud modeller og lægger ting i. Hvis jeg brugte denne forkortelse, og jeg skrev "Medarbejderlønningsplan" på enhedsnavnet, ville det handle med navnestandardskabelonen Jeg har defineret her, det ville have givet mig EMP_SAL_PLN, da jeg opretter enhederne og givet mig de tilsvarende fysiske navne med det samme.
Igen, meget godt, når vi også designer og videresender engineering. Vi har et meget unikt koncept, og det er her vi virkelig begynder at samle disse miljøer. Og det kaldes Universal Mappings. Når vi først har bragt alle disse modeller ind i vores miljø, hvad vi er i stand til at gøre, forudsat at vi nu har anvendt disse navnekonventioner og de er lette at finde, kan vi nu bruge en konstruktion kaldet Universal Mappings i ER / Studio. Vi kan forbinde enheder på tværs af modeller. Uanset hvor vi ser "kunde" - vi vil sandsynligvis have "kunde" i en masse forskellige systemer og en masse forskellige databaser - kan vi begynde at knytte alle disse sammen, så når jeg arbejder med det i en model jeg kan se, hvor er kundernes manifestationer i de andre modeller. Og fordi vi har modellaget, der repræsenterer det, kan vi endda binde det ind i datakilder og bringe det ned i vores, hvor brugte forespørgsler, til hvilke databaser disse også befinder sig i. Det giver os virkelig en mulighed for at binde alt dette meget sammenhængende.
Jeg har vist dig forretningsdataobjekter. Jeg vil også meget hurtigt tale om metadataudvidelser, som vi kalder Vedhæftede filer. Hvad det gør er, det giver os muligheden for at oprette yderligere metadata til vores modelobjekter. Ganske ofte opretter jeg disse typer egenskaber til at drive en masse forskellige ting ud fra et datastyrings- og datakvalitetsperspektiv og også for at hjælpe os med styring af masterdata og opbevaring af data. Den grundlæggende idé er, at du opretter disse klassifikationer, og du kan vedhæfte dem, uanset hvor du vil, på bordniveau, kolonniveau, disse typer ting. Det mest almindelige brugssag er naturligvis, at enheder er tabeller, og derefter kan jeg definere: hvad er mine stamdataobjekter, hvad er mine referencetabeller, hvad er mine transaktionsborde? Fra et datakvalitetsperspektiv kan jeg udføre klassificeringer med hensyn til vigtighed for virksomheden, så vi kan prioritere datarensning og den type ting.
Noget, der ofte overses, er, hvad er opbevaringspolitikken for forskellige typer data i vores organisation? Vi kan indstille disse, og vi kan faktisk knytte dem til de forskellige typer informationsartefakter i vores modelleringsmiljø og naturligvis også vores depot. Det skønne er, er disse vedhæftede filer live i vores dataark, så når vi bruger firmadataordbøger i miljøet, kan vi knytte dem til flere modeller. Vi skal kun definere dem én gang, og vi kan udnytte dem igen og igen på tværs af de forskellige modeller i vores miljø. Dette er bare et hurtigt skærmbillede for at vise, at du faktisk kan specificere, når du laver en vedhæftet fil, hvad alle brikkerne er, som du vil knytte den til. Og dette eksempel her er faktisk en liste over værdier, så når de går ind, kan du vælge fra en liste over værdier, du har en masse kontrol i modelleringsmiljøet for det, der vælges, og du kan endda indstille, hvad standard værdi er, hvis en værdi ikke vælges. Så meget magt der. De lever i dataordbogen.
Noget, jeg vil vise dig lidt længere nede på denne skærm, derudover kan du se de vedhæftede slags, der vises i den øverste del, under det ser du datasikkerhedsoplysninger. Vi kan faktisk også anvende datasikkerhedspolitikker på de forskellige oplysninger i miljøet. Ved forskellige overholdelseskortlægninger, datasikkerhedsklassifikationer sender vi et antal af dem ud af boksen, som du bare kan generere og begynde at bruge, men du kan også definere dine egne overholdelseskortlægninger og standarder. Uanset om du laver HIPAA eller et af de andre initiativer derude. Og du kan virkelig begynde at opbygge dette meget rige sæt metadata i dit miljø.
Og så ordlisten og vilkårene - det er her den forretningsmæssige betydning er bundet. Vi har ganske ofte datagræsbøger derude, som en organisation ofte bruger som udgangspunkt for at begynde at uddrive ordbøger, men terminologien og ordsprogene er ofte meget teknisk. Så hvad vi kan gøre, er, at vi kan, hvis vi ønsker det, bruge dem som udgangspunkt for at uddrive ordbøger, men vi ønsker virkelig, at virksomheden skal eje disse. Hvad vi har gjort i teamservermiljøet, har vi givet folk mulighed for at oprette forretningsdefinitioner, og så kan vi linke dem til de forskellige modelartefakter, som de svarer til også i modelleringsmiljøet. Vi anerkender også det punkt, der blev diskuteret tidligere, og det er, jo flere mennesker du har skrevet, jo mere potentiale er der for menneskelig fejl. Det, vi også gør i vores ordliste, er, det ene, vi understøtter et hierarki af ordliste, så vi kan have forskellige ordlistetyper eller forskellige typer ting i organisationen, men lige så vigtigt er det, hvis du allerede har nogle af disse kilder derude med de definerede vilkår og alt, kan vi faktisk foretage en CSV-import for at trække disse ind i vores modelleringsmiljø, og vores teamserver eller vores ordliste også, og derefter begynde at linke derfra. Og hver gang noget ændres, er der en fuld revisionsspor over, hvad billederne før og efter var, hvad angår definitionerne og alt andet, og hvad du vil se komme i den nærmeste fremtid er også mere en autorisationsarbejdsgang så vi kan virkelig styre, hvem der er ansvarlig for det, godkendelser fra udvalg eller enkeltpersoner, og den type ting, for at gøre styringsprocessen endnu mere robust, når vi går videre.
Hvad dette også gør for os, er når vi har disse ordbøger i vores team-server-ordliste, dette er et eksempel på redigering i en enhed i selve modellen, som jeg har bragt op her. Det kan have sammenkædede udtryk, men hvad vi også gør, er, hvis der er ord, der findes i den ordliste, der vises i noterne eller beskrivelserne af, hvad vi har i vores enheder her, disse vises automatisk i en lettere hyperlinket farve, og hvis vi musen hen over dem, kan vi faktisk også se definitionen fra virksomhedsordlisten. Det giver os endda rigere oplysninger, når vi forbruger selve informationen med alle de ordbøger, der findes derude. Det hjælper virkelig med at berige oplevelsen og anvende betydningen på alt det, vi arbejder med.
Så igen, det var en meget hurtig flyby. Vi kunne naturligvis bruge dage på dette, mens vi dykker ned i de forskellige dele, men dette er en meget hurtig flyby over overfladen. Det, vi virkelig stræber efter, er at forstå, hvordan disse komplekse datamiljøer ser ud. Vi ønsker at forbedre synligheden af alle disse dataartefakter og samarbejde for at uddrive dem med ER / Studio. Vi ønsker at muliggøre mere effektiv og automatiseret datamodellering. Og det er alle typer data, som vi taler om, hvad enten det er big data, traditionelle relationelle data, dokumentlagre eller noget andet. Og igen opnåede vi det, fordi vi har stærke fremad- og bagudvendige teknikfunktioner til de forskellige platforme og de andre værktøjer, som du måtte have derude. Og det handler om at dele og kommunikere på tværs af organisationen med alle de involverede interessenter. Det er her vi anvender mening gennem navnestandarder. Vi anvender derefter definitioner gennem vores forretningsordliste. Og så kan vi udføre yderligere klassifikationer for alle vores andre styringsfunktioner med metadataudvidelser, såsom datakvalitetsudvidelser, klassifikationer til masterdatastyring eller andre typer klassifikationer, som du vil anvende til disse data. Og så kan vi sammenfatte yderligere og forbedre kommunikationen endnu mere med forretningsdataobjekterne, med de forskellige interessentgrupper, især mellem modellerere og udviklere.
Og igen, hvad der er meget vigtigt ved dette er, bag det hele er et integreret lager med meget robuste ændringsstyringsfunktioner. Jeg havde ikke tid til at vise det i dag, fordi det bliver ret kompliceret, men depotet har meget robuste ændringsstyringsfunktioner og revisionsspor. Du kan gøre navngivne udgivelser, du kan gøre navngivne versioner, og vi har også muligheden for dem af jer, der laver ændringshåndtering, vi kan binde det ret ind i dine opgaver. Vi har i dag evnen til at placere opgaver og knytte dine modelændringer til opgaver, ligesom udviklere også vil knytte deres kodeændringer til de opgaver eller brugerhistorier, som de også arbejder med.
Igen, det var et meget hurtigt overblik. Jeg håber, at det har været nok til at få din appetit til at øge, så vi kan deltage i meget dybere samtaler om at opdele nogle af disse emner, når vi går fremover. Tak for din tid og tilbage til dig, Rebecca.
Rebecca Jozwiak: Tak, Ron, det var fantastisk, og jeg har ganske mange spørgsmål fra publikum, men jeg vil gerne give vores analytikere en chance for at synke tænderne ned i det, du har sagt. Eric, jeg vil gå videre, og måske hvis du vil adressere dette lysbillede, eller en anden, hvorfor går du ikke videre? Eller ethvert andet spørgsmål.
Eric Little: Sikker på. Beklager, hvad var spørgsmålet, Rebecca? Vil du have mig til at spørge noget specifikt eller …?
Rebecca Jozwiak: Jeg ved, at du oprindeligt havde nogle spørgsmål til Ron. Hvis du nu vil bede ham om at adressere nogen af dem, eller nogle af dem fra dit lysbillede eller noget andet, der fik din interesse, som du vil spørge om? Om IDERAs modelleringsfunktionaliteter.
Eric Little: Ja, så en af tingene, Ron, så hvordan gør I det, det ser ud som de diagrammer, du viste, er generelle former for enhedsforholdsdiagrammer, som du normalt ville bruge i databasekonstruktion, rigtigt?
Ron Huizenga: Ja, generelt set, men vi har selvfølgelig de udvidede typer til dokumentlagrene og den type ting også. Vi har faktisk varieret fra bare ren relationel notation, vi har faktisk tilføjet yderligere notationer til de andre butikker også.
Eric Little: Er der en måde, som I kan bruge grafbaserede typer modelleringer, så er der en måde at integrere, for eksempel, lad os antage, at jeg har noget som en topkvadrant, TopBraid komponistværktøj, eller jeg har gjort noget i Protégé eller, ved du, ligesom de økonomiske fyre i FIBO, de laver en masse arbejde i semantik, RDF-ting - er der en måde at bringe den type grafisk type modellering af enhed-forhold i dette værktøj til, og bruge det?
Ron Huizenga: Vi ser faktisk på, hvordan vi kan håndtere grafer. Vi håndterer ikke eksplicit grafdatabaser og den type ting i dag, men vi ser på måder, vi kan gøre det for at udvide vores metadata. Jeg mener, vi kan bringe ting ind gennem XML og den type ting lige nu, hvis vi i det mindste kan gøre en slags gengivelse af XML for at bringe det ind som udgangspunkt. Men vi ser på mere elegante måder at bringe det ind på.
Og jeg viste dig også den liste over reverse engineering-broer, som vi også har der, så vi ser altid på at få udvidelser til disse broer også til specifikke platforme. Det er en kontinuerlig, løbende indsats, hvis det giver mening, at begynde at omfavne en masse af disse nye konstruktioner og de forskellige platforme derude. Men jeg kan sige, at vi bestemt er på forkant med at gøre det. De ting, jeg viste på for eksempel MongoDB og den type ting, vi er den første leverandør af datamodellering, der faktisk gør det naturligt i vores eget produkt.
Eric Little: Okay, ja. Så det andet spørgsmål, jeg havde til dig, var da med hensyn til regeringsførelse og opretholdelse af - som når du brugte eksemplet, da du viste eksemplet på den person, der er en "medarbejder, " jeg tror, det var en " løn ”og så har du en” plan ”, er der en måde, hvordan administrerer du for eksempel forskellige slags mennesker, der måske har - lad os antage, at du har en stor arkitektur, ikke, lad os antage, at du har en stor virksomhed og folk begynder at trække ting sammen i dette værktøj, og du har en gruppe herover, der har ordet "medarbejder" og en gruppe herover, der har ordet "arbejder." Og en person herover siger "løn", og en anden person siger ”løn”.
Hvordan forsoner I og styrer og styrer den slags sondringer? Fordi jeg ved, hvordan vi ville gøre det i grafverdenen, ved du, du ville bruge synonymlister, eller du vil sige, at der er et koncept, og det har flere attributter, eller du kan sige i SKOS-modellen, at jeg har en foretrukken etiket, og jeg har adskillige alternative etiketter, som jeg kan bruge. Hvordan gør I det?
Ron Huizenga: Vi gør det på et par forskellige måder, og lad os først og fremmest tale om terminologien. En af de ting, vi gør, er naturligvis, at vi ønsker at have de definerede eller sanktionerede vilkår, og i forretningsordlisten er det selvfølgelig, hvor vi vil have dem. Og vi tillader også links til synonymer i virksomhedsordlisten, så hvad du kan gøre er, at du kan sige, her er min sigt, men du kan også definere, hvad alle synonymer til dem er.
Nu er den interessante ting naturligvis, når du begynder at kigge over dette enorme datalandskab med alle disse forskellige systemer, du har derude, du ikke bare kan gå derude og ændre de tilsvarende tabeller og disse typer ting til svarer til den navngivningsstandard, fordi det kan være en pakke, du har købt, så du har ingen kontrol over at ændre databasen eller noget som helst.
Hvad vi kunne gøre der, ud over at være i stand til at knytte sammen ordlistedefinitionerne, er gennem de universelle kortlægninger, som jeg talte om, hvad vi ville gøre, og slags en anbefalet fremgangsmåde, er at have en overordnet logisk model, der fastlægger, hvad disse forskellige forretningskoncepter er det, du taler om. Knyt forretningsordlisteordene til dem, og det dejlige er nu, at du har denne konstruktion, der repræsenterer en logisk enhed som den var, kan du derefter begynde at linke fra den logiske enhed til alle implementeringerne af den logiske enhed i de forskellige systemer.
Så hvor du har brug for det, kan du se, åh, "person" her kaldes "medarbejder" i dette system. "Løn" her kaldes "løn" her i dette andet system. Fordi du ser det, vil du se alle de forskellige manifestationer af dem, fordi du har knyttet dem sammen.
Eric Little: Okay fantastisk, ja, det. I den forstand er det sikkert at sige, at det er sådan som nogle af de objektorienterede tilgange?
Ron Huizenga: Noget. Det er lidt mere intensivt, end jeg antager, du kunne sige. Jeg mener, du kan tage den tilgang til manuelt at linke og gå igennem og inspicere og gøre dem alle også. Den ene ting havde jeg ikke rigtig en chance for at tale om - fordi vi igen har en masse muligheder - vi har også en fuld automatiseringsgrænseflade i selve Data Architect værktøjet. Og en makrofunktion, som virkelig er et programmeringssprog i værktøjet. Så vi kan faktisk gøre ting som at skrive makroer, få det til at gå ud og forhøre ting og oprette links til dig. Vi bruger det til at importere og eksportere information, vi kan bruge det til at ændre ting eller tilføje attributter, begivenhed baseret i selve modellen, eller vi kan bruge den til at køre i batches for faktisk at gå ud og forhøre ting og faktisk udfylde forskellige konstruktioner i model. Så der er en komplet automatiseringsgrænseflade, som folk også kan drage fordel af. Og at bruge de universelle kortlægninger med dem ville være en meget kraftig måde at gøre det på.
Rebecca Jozwiak: Okay, tak Ron, og tak Eric. Det var store spørgsmål. Jeg ved, at vi løber lidt forbi toppen af timen, men jeg vil gerne give Malcolm en chance for at smide nogle spørgsmål fra Ron's måde. Malcolm?
Malcolm Chisholm: Tak, Rebecca. Så Ron, det er meget interessant, jeg kan se, at der er mange muligheder her. Et af de områder, som jeg er meget interesseret i, er, hvis vi har et udviklingsprojekt, hvordan kan du se datamodelleren bruge disse muligheder og arbejde måske mere samarbejde med forretningsanalytikere, med en dataprofilator og en datakvalitetsanalytiker, og med de forretnings sponsorer, der i sidste ende vil være ansvarlige for de faktiske informationskrav i projektet. Hvordan gør datamodelleren virkelig, ved du, projektet mere effektivt og effektivt med de muligheder, vi ser på?
Ron Huizenga: Jeg tror, at en af de første ting, du skal gøre der, er som en datamodeller - og jeg mener ikke, at nogle af modellerne skal vælges, men jeg vil alligevel - er nogle mennesker, der stadig har indtryk af, at datamodelleren er virkelig den gateekeeper type rolle som lignende, vi definerer, hvordan det fungerer, vi er vagterne, der sørger for, at alt er korrekt.
Nu er der et aspekt af det, at du skal sikre dig, at du definerer en lyddataarkitektur og alt andet. Men den vigtigere ting er som datamodeller - og jeg fandt dette ganske tydeligt, da jeg konsulterede - er du nødt til at blive en facilitator, så du er nødt til at trække disse mennesker sammen.
Det kommer ikke til at være et design foran, generere, opbygge databaser længere - hvad du skal være i stand til at gøre, er du har brug for at være i stand til at arbejde med alle disse forskellige interessentgrupper, gøre ting som reverse engineering, importere information i, have andre mennesker samarbejder, hvad enten det drejer sig om ordlister eller dokumentation, alt lignende - og vær en facilitator til at trække dette ind i depotet og forbinde koncepterne sammen i depotet og arbejde med disse mennesker.
Det er virkelig meget mere af en samarbejdende type miljø, hvor selv gennem definition af opgaver eller endda diskussionstråde eller den type ting, som vi har i teamserveren, at folk faktisk kan samarbejde, stille spørgsmål og komme frem til de endelige slutprodukter, som de behov for deres dataarkitektur og deres organisation. Har den slags svar?
Malcolm Chisholm: Ja, jeg er enig. Du ved, jeg tror, at faciliteringsevnen er noget, der virkelig er meget ønskeligt hos datamodeller. Jeg er enig i, at vi ikke altid ser det, men jeg synes, det er nødvendigt, og jeg vil foreslå, at der undertiden er en tilbøjelighed til at blive i dit hjørne og gøre din datamodellering, men du er virkelig nødt til at være derude og samarbejde med de andre interessentgrupper eller du forstår bare ikke det datamiljø, du har at gøre med, og jeg tror, modellen lider som et resultat. Men det er bare min mening.
Ron Huizenga: Og det er interessant, fordi du nævnte noget tidligere i dit lysbillede om historien om, hvordan virksomheder er slags vendt bort fra IT, fordi de ikke leverede løsningen på en rettidig måde og de slags ting.
Det er meget interessant, at i mine senere konsulentopgaver, før jeg blev produktchef, var de fleste af de projekter, jeg gjorde i de sidste to år før det, forretningssponsoreret, hvor det virkelig var virksomheden, der kørte det, og dataarkitekterne og modellerere var ikke en del af IT. Vi var en del af en erhvervssponsoreret gruppe, og vi var der som facilitatorer, der arbejdede med resten af projektteamene.
Malcolm Chisholm: Så det synes jeg er et meget interessant punkt. Jeg tror, vi begynder at se et skift i forretningsverdenen, hvor virksomheden spørger, eller måske tænker, ikke så meget som hvad jeg gør, ved at være proceslignende, men de begynder også at tænke over, hvad er dataene at jeg arbejder med, hvad er mine databehov, hvad er de data, jeg beskæftiger mig med som data, og i hvilket omfang kan vi få IDERA-produkter og -funktioner til at understøtte det synspunkt, og jeg tror, at virksomhedens behov, selv selvom det er slags stadig lidt nytende.
Ron Huizenga: Jeg er enig med dig, og jeg tror, vi ser det gå mere og mere på den måde. Vi har set en opvågning, og du rørte ved den tidligere med hensyn til vigtigheden af data. Vi så vigtigheden af data tidligt i it eller i udviklingen af databaser, så som du siger, vi kom lige ind i hele denne processtyringscyklus - og processen er ekstremt vigtig, giv mig ikke noget galt der - men nu er der sket er, når det skete, dataform af mistet fokus.
Og nu er organisationer klar over, at data virkelig er omdrejningspunktet. Data repræsenterer alt det, vi laver i vores forretning, så vi er nødt til at sikre os, at vi har nøjagtige data, så vi kan finde de rigtige oplysninger, som vi har brug for for at tage vores beslutninger. Fordi ikke alt kommer fra en defineret proces. Nogle af oplysningerne er et biprodukt af andre ting, og vi er stadig nødt til at være i stand til at finde dem, vide, hvad det betyder, og være i stand til at oversætte de data, vi ser der, i sidste ende til viden, som vi kan bruge til at drive vores virksomheder bedre.
Malcolm Chisholm: Lige, og nu er et andet område, jeg har kæmpet med, hvad jeg vil kalde datalivets cyklus, som du ved, hvis vi ser på den slags dataforsyningskæde, der går gennem en virksomhed, ville vi starte med dataindsamling eller datafangst, hvilket kan være dataregistreringen, men det kan også være, jeg får data uden for virksomheden fra en bestemt dataleverandør.
Og så går vi fra dataindsamling til datavedligeholdelse, hvor jeg overvejer at standardisere disse data og sende dem rundt til steder, hvor det er nødvendigt. Og derefter brug af data, de faktiske punkter, hvor data er, vil du få værdi ud af dataene.
Og i gamle dage sker alt sammen i en enkelt stil, men i dag kan det for eksempel være et analytisk miljø, og derefter ud over det, et arkiv, en butik, hvor vi lægger dataene, når vi ikke længere har brug for det og til sidst en udrensning slags proces. Hvordan ser du datamodellering, der passer ind i styringen af hele denne datalivscyklus?
Ron Huizenga: Det er et meget godt spørgsmål, og en ting, som jeg virkelig ikke havde tid til at undersøge nogen detaljer her i dag overhovedet, er det, vi virkelig begynder at tale om, er datalinje. Så hvad vi faktisk er i stand til at gøre, er at vi har en datalinjefunktion i vores værktøjer, og som jeg siger, kan vi faktisk udtrække noget af det fra ETL-værktøjer, men du kan også kortlægge det bare ved at tegne afstamningen også. Enhver af disse datamodeller eller databaser, som vi har indfanget og bragt ind i modeller, kunne vi henvise til konstruktionerne fra det i vores datatrafikdiagram.
Hvad vi er i stand til at gøre er at tegne en dataflow, som du siger, fra kilde til mål, og gennem den samlede livscyklus for, hvordan disse data overføres gennem de forskellige systemer, og hvad du vil finde, er, lad os tage medarbejdere 'data - det er en af mine favoritter baseret på et projekt, som jeg gjorde for mange år siden. Jeg arbejdede med en organisation, der havde medarbejderdata i 30 forskellige systemer. Hvad vi endte med at gøre der - og Rebecca dukkede op datalinjedia - dette er et ret forenklet datalinjefremvisning her, men hvad vi var i stand til at gøre var at bringe alle datastrukturerne ind, henvise til dem i diagrammet, og så vi kan faktisk begynde at se på, hvad er strømningerne imellem, og hvordan er de forskellige dataenheder knyttet sammen i en strøm? Og vi kan også gå ud over det. Dette er en del af et dataflow eller afstamningsdiagram, som vi ser her. Hvis du vil gå ud over det, har vi også forretningsarkitektdelen af denne suite, og det samme gælder der.
Enhver af de datastrukturer, som vi har fanget i datamodelleringsmiljøet, kan der henvises til i forretningsmodelleringsværktøjet, så du selv i din forretningsmodeldiagrammer eller dine forretningsprocesdiagrammer kan referere til individuelle datalagre, hvis du vil ud af datamodelleringsmiljøet, og mens du bruger dem i mapperne i din forretningsprocesmodel, kan du endda specificere CRUD på dem også, hvordan disse oplysninger enten forbruges eller produceres, og så kan vi begynde at generere ting som konsekvens- og analyserapporter og diagrammer ud af det.
Hvad vi sigter mod at komme til, og vi har allerede mange muligheder, men en af de ting, som vi slags har, er som en slags målpost, som vi ser på, når vi fortsætter med at udvikle vores værktøjer fremover, er i stand til at kortlægge den ende-til-ende, organisatoriske datalinje og den fulde livscyklus af data.
Malcolm Chisholm: Okay. Rebecca, får jeg lov til en mere?
Rebecca Jozwiak: Jeg vil give dig en til, Malcolm, gå videre.
Malcolm Chisholm: Mange tak. Når vi tænker på datastyring og tænker på datamodellering, hvordan får vi disse to grupper til at arbejde effektivt sammen og forstå hinanden?
Eric Little: Det er interessant, jeg synes, det afhænger virkelig af organisationen, og det går tilbage til mit tidligere koncept er, i de organisationer, hvor initiativerne var forretningsdrevne, vi var bundet lige i. For eksempel ledte jeg en dataarkitektur hold, men vi var lige bundet med forretningsbrugere, og vi hjalp dem faktisk med at opstille deres datastyringsprogram. Igen mere en konsultativ tilgang, men det er virkelig mere en forretningsfunktion.
Hvad du virkelig har brug for for at være i stand til det, er at du har brug for datamodeller og arkitekter, der virkelig forstår forretning, kan forholde sig til forretningsbrugere og så have hjulpet dem med at opstille styringsprocesserne omkring det. Virksomheden ønsker at gøre det, men generelt set har vi teknologikendskab til at være i stand til at hjælpe dem med at skille sig ud fra disse typer programmer. Det skal virkelig være et samarbejde, men det skal være ejet af virksomheden.
Malcolm Chisholm: Okay, det er fantastisk. Tak skal du have.
Dr. Eric Little: Okay.
Rebecca Jozwiak: Okay, tak så meget. Publikum medlemmer, jeg er bange for, at vi ikke kom til dine spørgsmål, men jeg vil sørge for, at de bliver sendt videre til den passende gæst, vi havde på linjen i dag. Jeg vil gerne takke Eric, Malcolm og Ron for at have været vores gæster i dag. Dette var gode ting, folkens. Og hvis du nød dagens IDERA-webcast, vil IDERA også være med på en Hot Technologies næste onsdag, hvis du vil være med, diskutere udfordringerne ved indeksering og Oracle, så et andet fascinerende emne.
Mange tak, folk, pas på, så ser vi dig næste gang. Hej hej.
