Bygga en affärsdriven dataarkitektur

Hämtmat: Värd Rebecca Jozwiak diskuterar lösningar för dataarkitektur med Eric Little från OSTHUS, Malcolm Chisholm från First San Francisco Partners och Ron Huizenga från IDERA.

Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.

Rebecca Jozwiak: Mina damer och herrar, hej och välkommen till Hot Technologies 2016. Idag diskuterar vi ”Att bygga en affärsdriven dataarkitektur”, definitivt ett hett ämne. Jag heter Rebecca Jozwiak, jag kommer att vara din värd för dagens webbutsändning. Vi tweetar med en hashtagg av # HotTech16 så om du redan är i, känn dig gärna med på det också. Om du har frågor när som helst kan du skicka dem till frågeformuläret längst ner till höger på skärmen så ser vi till att de får svar. Om inte, kommer vi att se till att våra gäster får dem åt dig.

Så idag har vi en riktigt fascinerande sortiment. Många tunga träffar på oss idag. Vi har Eric Little, VP för datavetenskap från OSTHUS. Vi har Malcolm Chisholm, chef för innovationschef, som är en riktigt cool titel för First San Francisco Partners. Och vi har Ron Huizenga, senior produktchef från IDERA. Och du vet, IDERA är ett riktigt komplett paket med datahantering och modelleringslösningar. Och idag kommer han att ge oss en demo om hur hans lösning fungerar. Men innan vi kommer till det, Eric Little, ska jag skicka bollen till dig.

Eric Little: Okej, tack så mycket. Så jag kommer att gå igenom ett par ämnen här som jag tror kommer att relatera till Rons prat lite och förhoppningsvis sätta scenen för några av dessa ämnen också, vissa frågor och svar.

Så det som intresserade mig för vad IDERA gör är att jag tror att de korrekt påpekar att komplexa miljöer verkligen driver många affärsvärden idag. Och med komplexa miljöer menar vi komplexa datamiljöer. Och tekniken går verkligen snabbt och det är svårt att hålla jämna steg med dagens affärsmiljö. Så de människor som arbetar i teknikutrymmen kommer ofta att se att du har kunder som arbetar med problem med, ”Hur använder jag big data? Hur integrerar jag semantik? Hur kopplar jag in några av de här nya sakerna med mina äldre data? ”Och så vidare, och den typen leder oss idag in i dessa fyra v-filer med stor data som många är ganska bekanta med, och jag förstår att det kan finnas mer än fyra ibland - jag har sett så många som åtta eller nio - men normalt sett, när människor pratar om saker som big data eller om du pratar om big data så tittar man vanligtvis på något som är typ av företagskala. Och så kommer folk att säga, okej, ja, tänk på volymen på dina data, som normalt är fokus - det är precis hur mycket du har. Datahastigheten har att göra med antingen hur snabbt jag kan flytta runt det eller hur snabbt jag kan fråga eller få svar, och så vidare. Och personligen tror jag vänster sida av det är något som lösas och hanteras relativt snabbt med många olika tillvägagångssätt. Men på höger sida ser jag mycket kapacitet för förbättringar och många nya tekniker som verkligen kommer i förgrunden. Och det har verkligen att göra med den tredje kolumnen, datasorten.

Så med andra ord tittar de flesta företag idag på strukturerade, semistrukturerade och ostrukturerade data. Bilddata börjar bli ett hett ämne, så att kunna använda datorsyn, titta på pixlar, kunna skrapa, NLP, utvinning av enheter, du har grafinformation som kommer ut från antingen statistiska modeller eller som kommer ut från semantiska modeller , har du relationella data som finns i tabeller, och så vidare. Och så att samla all den informationen och alla dessa olika typer representerar verkligen en stor utmaning och du kommer att se detta i, du vet, i Gartner och andra människor som liksom följer trenderna i branschen.

Och sedan är den sista saken som folk pratar om i big data ofta denna uppfattning om svårighet, som verkligen är osäkerheten i dina data, fuzziness av det. Hur väl vet du vad dina uppgifter handlar om, hur väl förstår du vad som finns där och vet du? Möjligheten att använda statistik och förmågan att använda någon typ av information kring vad du kanske vet eller att använda vissa svårigheter kan vara av värde där. Och så förmågan att titta på data på detta sätt i termer av hur mycket du har, hur snabbt du behöver flytta runt eller komma åt dem, alla typer av data du kan ha i ditt företag och hur säker du är om var det är, vad det är, vilken kvalitet det är i, och så vidare. Detta kräver verkligen en stor, samordnad insats nu mellan många individer för att hantera sina data effektivt. Därför blir modelleringsdata allt viktigare i dagens värld. Så bra datamodeller driver verkligen mycket framgång i företagsapplikationer.

Du har datakällor från en mängd olika källor, som vi sa, vilket verkligen kräver många olika slags integration. Så att dra allt ihop är verkligen användbart för att kunna köra frågor, till exempel över flera typer av datakällor, och dra tillbaka information. Men för att göra det behöver du bra kartläggningsstrategier och så att kartlägga den typen av data och hålla koll på dessa kartläggningar kan vara en verklig utmaning. Och då har du den här frågan om, hur kopplar jag mina gamla data till alla dessa nya datakällor? Så antar att jag har en graf, tar jag alla mina relationsdata och lägger den i graf? Vanligtvis är det inte bra. Så hur är det att människor kan hantera alla dessa typer av datamodeller som pågår? Analys måste verkligen köras på många av dessa olika typer av datakällor och kombinationer. Så de svar som kommer ut ur detta, de svar som människor behöver för att verkligen fatta bra affärsbeslut är kritiska.

Så det handlar inte bara om att bygga teknik för teknikens skull, det är verkligen, vad ska jag göra, vad kan jag göra med det, vilken typ av analys kan jag köra och förmågan, som jag redan har gjort har pratat om, att dra samman det här, att integrera det är verkligen, verkligen viktigt. Och en av dessa typer av analyser körs sedan på saker som federerad sökning och fråga. Det blir verkligen ett måste. Dina frågor måste normalt gängas över flera typer av källor och dra tillbaka informationen på ett tillförlitligt sätt.

Det enda viktiga elementet som ofta, särskilt människor kommer att titta på viktiga saker som semantisk teknik - och det är något som jag hoppas att Ron kommer att prata lite om i IDERA-metoden - är hur du separerar eller hanterar modelllager av dina data från själva dataskiktet, från den rådata informationen? Så ner i dataskiktet kan du ha databaser, du kan ha dokumentdata, du kan ha kalkylbladsdata, du kan ha bilddata. Om du befinner dig i områden som läkemedelsindustrin har du enorma mängder vetenskaplig information. Och på toppen av detta letar folk normalt efter ett sätt att bygga en modell som gör att de snabbt kan integrera dessa data och verkligen när du letar efter data nu letar du inte efter att dra upp all information i ditt modelllager , vad du tittar på modellskiktet att göra är att ge dig en fin logisk framställning av vad saker är, vanliga ordförråd, vanliga typer av enheter och relationer och förmågan att verkligen nå ut i uppgifterna där de är. Så det måste säga vad det är, och det måste säga var det är, och det måste säga hur man ska hämta det och föra tillbaka det.

Så detta har varit en metod som har varit ganska framgångsrik med att driva semantiska teknologier framåt, vilket är ett område där jag arbetar mycket. Så en fråga som jag ville ställa till Ron, och som jag tror kommer att vara användbar i avsnittet Frågor och svar, är att se hur uppnås detta med IDERA-plattformen? Så är modellskiktet faktiskt åtskilt från dataskiktet? Är de mer integrerade? Hur fungerar det och vad är några av de resultat och fördelar de ser med sin strategi? Därför blir referensdata verkligen också kritiska. Så om du kommer att ha den här typen av datamodeller, om du kommer att kunna förenas och söka över saker, måste du verkligen ha bra referensdata. Men problemet är att referensdata kan vara riktigt svåra att underhålla. Så ofta är namngivning av standarder i sig själva en svår utmaning. En grupp kommer att kalla något X och en grupp kommer att kalla något Y och nu har du problemet med hur hittar någon X och Y när de letar efter den här typen av information? Eftersom du inte bara vill ge dem en del av uppgifterna, vill du ge dem allt relaterat. Samtidigt ändras villkoren, mjukvaran försvinner, och så vidare, hur håller du upp och underhåller referensdata över tid?

Och återigen har semantiska tekniker, speciellt med saker som taxonomier och ordförråd, datalister, tillhandahållit ett standardutrymme för att göra detta, vilket verkligen är mycket robust, det använder vissa typer av standarder, men databasgemenskapen har gjort detta för en länge också, bara på olika sätt. Jag tror att en av nycklarna här är att tänka på hur man kanske använder enhetsrelaterade modeller, hur man använder kanske grafmodeller eller någon typ av metod här som verkligen kommer att ge dig förhoppningsvis ett standardiserat sätt att hantera dina referensdata. Och så när du väl har referensdata måste kartläggningsstrategierna naturligtvis hantera en mängd olika namn och enheter. Så ämnesexperter gillar ofta att använda sina egna termer.

Så en utmaning i detta är alltid, hur ger du någon information men gör den relevant för hur de pratar om den? Så en grupp kan ha ett sätt att titta på något, till exempel kan du vara en kemist som arbetar på ett läkemedel, och du kan vara en strukturbiolog som arbetar på samma läkemedel, och du kan ha olika namn på samma typ av enheter som relaterar till ditt område. Du måste ta reda på sätt att föra samman de personliga terminologierna, eftersom det andra tillvägagångssättet är att du måste tvinga människor att släppa sin termin och använda någon annans, som de ofta inte gillar. En annan punkt här är att hantera ett stort antal synonymer blir svårt, så det finns många olika ord i många människors data som kan hänvisa till samma sak. Du har ett referensproblem där med en mängd relationer. Specialiserade termer varierar från bransch till bransch, så om du ska komma på en typ av en övergripande lösning för denna typ av datahantering, hur lätt är det bärbart från ett projekt eller en applikation till en annan? Det kan vara en annan utmaning.

Automation är viktigt och det är också en utmaning. Det är dyrt att manuellt hantera referensdata. Det är dyrt att behöva hålla kartläggning manuellt och det är dyrt att ämnesexperter slutar göra sina dagliga jobb och måste gå in och ständigt fixa datorordböcker och uppdatera definitioner och så vidare, och så vidare. Replikerbara ordförråd visar verkligen mycket värde. Så det är ordförråd ofta som du kan hitta externt i din organisation. Om du till exempel arbetar med råolja kommer det att finnas vissa typer av ordförråd du kan låna från öppna källor, samma med läkemedel, samma med bankindustrin och finansiella, samma med många sådana områden. Människor sätter återanvändbara, generiska, replikerbara ordförråd där ute för människor att använda.

Och igen, när jag tittar på IDERA-verktyget är jag nyfiken på hur de hanterar detta när det gäller att använda typer av standarder. I semantikvärlden ser man ofta saker som SKOS-modeller som ger standarder för åtminstone bredare än / smalare än förhållanden och dessa saker kan vara svåra att göra i ER-modeller, men du vet, inte omöjligt, det beror bara på hur mycket av det maskiner och den länk som du kan hantera i de typer av system.

Så slutligen ville jag bara göra en jämförelse med några semantiska motorer som jag ser i branschen, och typ fråga Ron och prima honom lite för att prata om kanske hur IDERA: s system har använts i samband med alla semantiska tekniker.Kan den integreras med trippelbutiker, grafdatabaser? Hur lätt är det att använda externa källor eftersom sådana saker i den semantiska världen ofta kan lånas med SPARQL Endpoints? Du kan importera RDF- eller OWL-modeller direkt till din modell - hänvisa tillbaka till dem - så till exempel genontologin eller proteinontologin, som kan leva någonstans i sitt eget utrymme med sin egen styrningsstruktur och jag kan helt enkelt importera alla eller del av det eftersom jag behöver det i mina egna modeller. Och jag är nyfiken på hur IDERA närmar sig denna fråga. Måste du underhålla allt internt, eller finns det sätt att använda andra typer av standardiserade modeller och dra in dem och hur fungerar det? Och det sista jag nämnde här är hur mycket manuellt arbete som verkligen är involverat för att bygga ordlistorna och metadataförlagren?

Så jag vet att Ron kommer att visa oss några demonstrationer om sådana saker som kommer att bli riktigt intressanta. Men de problem som jag ofta ser att konsultera med kunderna är att många fel uppstår om människor skriver i sina egna definitioner eller sina egna metadata. Så du får stavfel, du får fel-fingerfel, det är en sak. Du får också människor som kan ta något från, du vet, bara Wikipedia eller en källa som inte nödvändigtvis är av den kvalitet du kanske vill ha i din definition, eller din definition är bara från en persons perspektiv så att den inte är fullständig, och det är inte klart då hur styrningsprocessen fungerar. Styrning är naturligtvis en mycket, väldigt stor fråga när du pratar om referensdata och när du pratar om hur detta kan passa in i någons huvuddata, hur de ska använda sina metadata och så vidare.

Så jag ville bara lägga några av dessa ämnen där ute. Det här är artiklar som jag ser i affärsutrymmet över många olika slags konsultuppdrag och många olika utrymmen, och jag är verkligen intresserad av att se vad Ron kommer att visa oss med IDERA för att påpeka några av dessa ämnen . Så tack så mycket.

Rebecca Jozwiak: Tack så mycket, Eric, och jag gillar verkligen din kommentar att många fel kan uppstå om människor skriver sina egna definitioner eller metadata. Jag vet att i journalistikvärlden finns det ett mantra som "många ögon gör få fel", men när det gäller praktiska tillämpningar tenderar för många händer i kakan att lämna dig med många trasiga kakor, eller hur?

Eric Little: Ja, och bakterier.

Rebecca Jozwiak: Ja. Med det kommer jag att gå vidare och skicka det till Malcolm Chisholm. Malcolm, golvet är ditt.

Malcolm Chisholm: Tack så mycket, Rebecca. Jag skulle vilja titta lite på vad Eric har pratat om och lägga till, typ av, några observationer som, du vet, Ron kanske bryr sig om att också svara på, i att prata om ”Mot affärsstyrd dataarkitektur ”- vad betyder det att vara affärsdrivna och varför är det viktigt? Eller är det bara någon form av hype? Jag tror inte att det är det.

Om vi ​​tittar på vad som har hänt sedan, du vet, stordator-datorer blev verkligen tillgängliga för företag - säg omkring 1964 - till idag kan vi se att det har skett en hel del förändringar. Och dessa förändringar skulle jag sammanfatta som en övergång från processcentricitet till datacentricitet. Och det är det som gör affärsdrivna dataarkitekturer så viktiga och så relevanta för idag. Och jag tror, ​​du vet, det är inte bara ett surrord, det är något som är absolut verkligt.

Men vi kan uppskatta det lite mer om vi dyker in i historien, så att gå tillbaka i tiden, långt tillbaka till 1960-talet och under en tid därefter dominerade stordatorer. Dessa gav sig sedan till datorer där du faktiskt hade gjort uppror för användarna när datorer kom in. Uppror mot centraliserad IT, som de trodde inte uppfyllde sina behov, var inte smidiga nog. Det gav snabbt upphov till distribuerad databehandling när datorer kopplades samman. Och sedan började internet hända, vilket oskärpte företagets gränser - det kunde nu interagera med parter utanför sig själv när det gäller datautbyte, som inte hade hänt tidigare. Och nu har vi gått in i eraen med moln och big data där molnet är plattformar som verkligen commoditizing infrastruktur och så vi lämnar, som det var, IT av behovet av att driva big data centra eftersom, du vet, vi Vi har molnkapaciteten tillgänglig för oss och tillsammans med den stora data som Eric har, vet du, så vältaligt diskuterat. Och totalt sett, som vi ser, när teknikskiftet har skett, har det blivit mer datacentriskt, vi bryr oss mer om data. Liksom på internet, hur data utbyts. Med big data, de fyra eller fler V: erna av själva uppgifterna.

Samtidigt, och kanske viktigare, ärenden om affärsanvändning flyttade. När datorer först introducerades användes de för att automatisera saker som böcker och poster. Och allt som var en manuell process, som involverade bokar eller sådant, programmerades, i huvudsak, i hus. Det skiftade på 80-talet till tillgängligheten av operativa paket. Du behövde inte skriva din egen lön längre, du kunde köpa något som gjorde det. Det resulterade i en stor nedskärning då, eller omstrukturering, i många IT-avdelningar. Men då dök affärsinformation, med saker som datalager, mest på 90-talet. Följt av dotcom affärsmodeller som naturligtvis var en stor vanvidd. Sedan MDM. Med MDM börjar du se att vi inte funderar på automatisering; vi fokuserar bara på att samla data som data. Och sedan analyser, som representerar värdet du kan få ut data. Och inom analys ser du företag som är mycket framgångsrika vars kärnverksamhetsmodell handlar om data. Google skulle vara en del av det, men du kan också hävda att Walmart är det.

Och så tänker verksamheten nu verkligen på data. Hur kan vi få värde ur data? Hur data kan driva verksamheten, strategin och vi befinner oss i dataåldern. Så med tanke på det, vad händer i termer av vår dataarkitektur, om data inte längre betraktas som helt enkelt avgaserna som kommer ut ur applikationens baksida, men verkligen är centrala för våra affärsmodeller? Nåväl, en del av problemet som vi har för att uppnå det är IT är verkligen fastnat i det förflutna med systemutvecklingens livscykel som var en konsekvens av att vi snabbt måste hantera den processautomatiseringsfasen under IT: s tidiga ålder och arbeta i projekt är en liknande sak. Till IT - och det här är lite karikatyr - men vad jag försöker säga är att några av hinder för att få en affärsstyrd dataarkitektur beror på att vi, typ av, okritiskt har accepterat en kultur inom IT som härrör från en förfluten tid.

Så allt är ett projekt. Berätta dina krav i detalj. Om saker inte fungerar beror det på att du inte berättade för mig dina krav. Det fungerar inte idag med data eftersom vi inte börjar med automatiserade manuella processer eller en, du vet, en teknisk omvandling av affärsprocesser, vi börjar mycket ofta med redan befintlig produktionsdata som vi försöker att få värde ur. Men ingen som sponsrar ett datacentriskt projekt förstår verkligen dessa data på djupet. Vi måste göra upptäckt av data, vi måste göra källdataanalys. Och det stämmer inte riktigt med systemutvecklingen, du vet - vattenfall, SDLC-livscykel - som Agile, skulle jag säga, är en typ av en bättre version av det.

Och det som fokuseras på är teknik och funktionalitet, inte data. Till exempel, när vi testar i en testfas är det vanligtvis, fungerar min funktionalitet, låt oss säga min ETL, men vi testar inte uppgifterna. Vi testar inte våra antaganden om källdata som kommer in. Om vi ​​gjorde det, skulle vi vara i bättre form och som någon som har gjort datavarehusprojekt och lidit genom uppströmsförändringar, som stänger mina ETL: er, skulle jag uppskatta det. Och faktiskt, det vi vill se är att testa som ett preliminärt steg för kontinuerlig övervakning av produktionsdata. Så vi har här en hel del attityder där det är svårt att uppnå den affärsdrivna dataarkitekturen eftersom vi är betingade av eran med processcentricitet. Vi måste göra en övergång till datacentricitet. Och detta är inte en total övergång, du vet, det finns fortfarande mycket processarbete att göra där ute, men vi tänker inte riktigt i datacentriska termer när vi behöver, och de omständigheter som uppstår när vi verkligen skyldig att göra det.

Nu inser verksamheten värdet på data, de vill låsa upp data, så hur ska vi göra det? Så hur gör vi övergången? Vi lägger data till kärnan i utvecklingsprocesser. Och vi låter verksamheten leda med informationskrav. Och vi förstår att ingen förstår befintliga källdata i början av projektet. Du kan hävda att datastrukturen och själva informationen kom dit genom respektive IT och operationer, så vi borde veta det, men egentligen gör vi inte det. Detta är datacentrisk utveckling. Så vi måste, när vi tänker på var och hur gör vi modellering av data i en datacentrisk värld, vi måste ha feedback-slingor till användarna när det gäller att förfina sina informationsbehov, liksom vi gör upptäckt av data och dataprofilering , förutse källdatanalys, och när vi gradvis får mer och mer säkerhet om våra data. Och nu talar jag om ett mer traditionellt projekt som ett MDM-nav eller ett datalager, inte nödvändigtvis big data-projekt, även om det fortfarande är, tror jag, ganska nära det. Och så innehåller dessa feedback-slingor datamodellerna, du vet, gradvis främjar deras datamodell och interagerar med användarna för att se till att informationskraven förfinas baserat på vad som är möjligt, vad som är tillgängligt, från källdata eftersom de bättre förstår det, så det är inte fallet längre med att datamodellen är, du vet, i ett tillstånd som antingen inte är där eller helt gjort, det är en gradvis inriktning på den.

På liknande sätt, mer nedströms av det har vi kvalitetssäkring där vi utvecklar regler för datakvalitetstest för att se till att uppgifterna ligger inom de parametrar som vi gör antaganden om. När han gick in hänvisade Eric till förändringar i referensdata, vilket kan hända. Du vill inte vara som ett nedströmsoffer för, typ av obekvämd förändring inom det området, så att kvalitetssäkringsreglerna kan gå till efterproduktion, kontinuerlig övervakning av datakvalitet. Så du kan börja se om vi kommer att vara datacentriska, hur vi gör datacentrisk utveckling är helt annorlunda än funktionsbaserad SDLC och Agile. Och då måste vi också uppmärksamma affärssynen. Vi har - och återigen detta ekar vad Eric sa - vi har en datamodell som definierar en datahistoria som är blå för vår databas, men samtidigt behöver vi de konceptuella modellerna, de affärsvyer av data som traditionellt inte har gjorts i det förflutna. Vi har ibland, tror jag, tänkt att datamodellen kan göra allt, men vi måste ha den konceptuella vyn, semantiken och titta på data, göra den genom ett abstraktionslager som översätter lagringsmodellen till verksamheten se. Och, återigen, alla saker som Eric pratade om i form av semantik, blir viktiga för att göra det, så vi har faktiskt ytterligare modelleringsuppgifter. Jag tror att det är, du vet, intressant om du har kommit upp i raden som en datamodeller som jag gjorde, och igen, något nytt.

Och slutligen skulle jag vilja säga att den större arkitekturen också måste återspegla denna nya verklighet. Traditionell kund MDM, till exempel, är typ av, okej, låt oss få våra kunddata till ett nav där vi, du vet, kan förstå det i termer av egentligen bara datakvalitet för back office-applikationer. Vilket från en affärsstrategisk synvinkel är ett slags gäspning. Idag tittar vi dock på kundens MDM-nav som har ytterligare kundprofildata i dem, inte bara de statiska uppgifterna, som då verkligen har ett dubbelriktat gränssnitt med kundens transaktionsapplikationer. Ja, de stöder fortfarande back office, men nu vet vi också om våra kunders beteenden. Detta är dyrare att bygga. Detta är mer komplicerat att bygga. Men det är affärsdrivet på ett sätt som den traditionella kund-MDM inte är. Du handlar med en orientering mot verksamheten mot enklare design som är lättare att genomföra, men för företaget är det detta de vill se. Vi är verkligen i en ny era och jag tror att det finns ett antal nivåer som vi måste svara på den affärsdrivande dataarkitekturen och jag tycker att det är en mycket spännande tid att göra saker.

Så tack, tillbaka till dig Rebecca.

Rebecca Jozwiak: Tack Malcolm, och jag gillade verkligen vad du sa om datamodeller måste mata affärssynen, för, till skillnad från vad du sa, där IT höll tyglarna så länge och det är helt enkelt inte så fallet längre och att kulturen behöver skiftas. Och jag är ganska säker på att det fanns en hund i bakgrunden som höll med dig 100%. Och med det kommer jag att skicka bollen till Ron. Jag är verkligen glad att se din demo. Ron, golvet är ditt.

Ron Huizenga: Tack så mycket, och innan vi hoppar in i det kommer jag att gå igenom några bilder och sedan lite demo eftersom, som Eric och Malcolm har påpekat, detta är ett mycket brett och djupt ämne, och med vad vi vi pratar om idag, vi skraper bara ytan på det eftersom det finns så många aspekter och så många saker som vi verkligen måste tänka på och titta på från en affärsstyrd arkitektur. Och vår strategi är att verkligen göra det modellbaserade och hämta verkligt värde ur modellerna eftersom du kan använda dem som ett kommunikationsfordon såväl som ett lager för att möjliggöra andra system. Oavsett om du gör serviceorienterad arkitektur eller andra saker, blir modellen verkligen livsnerven för vad som händer, med alla metadata kring den och de data du har i ditt företag.

Men vad jag vill prata om är nästan att ta detta ett steg bakåt, för Malcolm hade berört en del av historien om hur lösningar har utvecklats och den typen av saker. Ett sätt att verkligen påpeka hur viktigt det är att ha en sund dataarkitektur är ett användningsfall som jag brukade stöta på ofta när jag konsulterade innan jag kom in i en produkthanteringsroll, och det var att jag skulle gå in i organisationer oavsett om de genomförde affärsomvandling eller bara ersatte vissa befintliga system och den typen av saker, och det blev mycket snabbt uppenbart av hur dåliga organisationer förstår sina egna data. Om du tar ett särskilt användningsfall som det här, oavsett om du är en konsult som går in eller kanske det är en person som just har börjat med en organisation, eller din organisation har byggts upp genom åren med att förvärva olika företag, vad du slutar upp med är en mycket komplex miljö mycket snabbt, med ett antal nya olika tekniker, såväl som arvteknologi, ERP-lösningar och allt annat.

Så en av de saker som vi verkligen kan göra med vår modelleringsmetod är att svara på frågan om, hur kan jag känna till allt detta? Vi kan verkligen börja samla informationen så att verksamheten kan utnyttja den information vi har korrekt. Och det kommer ut, vad är det som vi har där ute i dessa miljöer? Hur kan jag använda modellerna för att driva ut den information som jag behöver och förstå den informationen bättre? Och sedan har vi de traditionella typerna av metadata för alla olika saker som de relationella datamodellerna, och vi är vana vid att se saker som definitioner och datalister, du vet, datatyper och den typen av saker. Men hur är det med ytterligare metadata som du vill fånga för att verkligen ge det ännu mer mening? Till exempel vilka enheter som verkligen är de kandidater som borde vara referensdataobjekt, som borde vara masterdatahanteringsobjekt och dessa typer av saker och binda dem samman. Och hur flödar informationen genom organisationen? Data flyter från hur de konsumeras ur både en processsynvinkel, men också datalinjer i termer av informationsresan genom våra företag och hur de tar sig igenom de olika systemen, eller genom datalagren, så vi vet när vi bygger I-lösningarna, eller sådana saker, konsumerar vi faktiskt rätt information för den aktuella uppgiften.

Och då är det mycket viktigt, hur kan vi få alla dessa intressenter att samarbeta, och särskilt företagens intressenter, eftersom det är de som ger oss den verkliga innebörden av vad den informationen är. I slutet av dagen äger verksamheten uppgifterna. De tillhandahåller definitionerna för ordförråd och saker som Eric pratade om, så vi behöver en plats för att binda allt detta tillsammans. Och hur vi gör det är genom vår datamodellering och datalagringsarkitekturer.

Jag kommer att beröra några saker. Jag kommer att prata om ER / Studio Enterprise Team Edition. Jag kommer främst att prata om dataarkitekturprodukten där vi gör datamodelleringen och den typen av saker, men det finns många andra komponenter i sviten som jag bara kommer att beröra mycket kort. Du kommer att se ett utdrag av affärsarkitekten, där vi kan göra konceptuella modeller, men vi kan också göra affärsprocessmodeller och vi kan binda de processmodellerna för att länka de faktiska data som vi har i våra datamodeller. Det hjälper oss verkligen att sätta ihop det slips. Programvaruarkitekt gör det möjligt för oss att göra ytterligare konstruktioner, till exempel en del UML-modellering och sådana saker för att ge stödjande logik till några av de andra system och processer som vi pratar om. Men mycket viktigt när vi flyttar ner har vi förvaret och teamservern, och jag kommer att prata om det som en typ av två halvor av samma sak. Förvaret är där vi lagrar alla modellerade metadata såväl som alla affärsmetadata när det gäller affärsordlistor och villkor. Och eftersom vi har den här förvarebaserade miljön kan vi sedan sammanfoga alla dessa olika saker i samma miljö och sedan kan vi faktiskt göra dem tillgängliga för konsumtion, inte bara för de tekniska människorna utan också för företagarna. Och det är så vi verkligen börjar driva samarbete.

Och sedan är det sista stycket som jag kommer att prata om kort, när du går in i dessa miljöer är det inte bara databaser som du har där ute. Du kommer att ha ett antal databaser, datalagrar, du kommer också att ha mycket, vad jag skulle kalla, gamla artefakter. Kanske har människor använt Visio eller andra diagram för att kartlägga vissa saker. Kanske har de haft andra modelleringsverktyg och den typen av saker.Så vad vi kan göra med MetaWizard är faktiskt att extrahera en del av den informationen och ta med den i våra modeller, göra den aktuell och kunna använda den, konsumera den på ett aktuellt sätt igen, snarare än att bara ha den där ute. Det blir nu en aktiv del av våra arbetsmodeller, vilket är mycket viktigt.

När du går in i en organisation, som jag sa, finns det många olika system där ute, många ERP-lösningar, avvikande avdelningslösningar. Många organisationer använder också SaaS-lösningar, som också styrs externt och hanteras, så vi kontrollerar inte databaserna och de typer av saker i värdar på dessa, men vi måste fortfarande veta hur den informationen ser ut och, naturligtvis, metadata runt det. Vad vi också hittar är många föråldrade arvssystem som inte har rengjorts på grund av det projektbaserade tillvägagångssättet som Malcolm hade talat om. Det är fantastiskt hur de senaste åren kommer organisationer att snurra upp projekt, de kommer att ersätta ett system eller en lösning, men det finns ofta inte tillräckligt med projektbudget för att stänga av de föråldrade lösningarna, så nu är de bara i vägen. Och vi måste ta reda på vad vi faktiskt kan bli av med i vår miljö och vad som är användbart framöver. Och det binder till den dåliga avvecklingsstrategin. Det är en del av samma sak.

Vad vi också hittar, eftersom många organisationer har byggts upp från alla dessa olika lösningar, är att vi ser många punkt-till-punkt-gränssnitt med mycket data som rör sig runt på ett antal platser. Vi måste kunna rationalisera det och räkna ut den datainstamning som jag kort nämnde tidigare så att vi kan ha en mer sammanhållen strategi som användning av serviceorienterad arkitektur, företagstjänster och sådana saker för att leverera korrekt information till en typ av publicering och prenumeration som vi använder korrekt i hela vår verksamhet. Och så måste vi naturligtvis fortfarande göra någon form av analyser, oavsett om vi använder datalager, datamarkeringar med traditionell ETL eller använder några av de nya dataljöarna. Allt kommer till samma sak. Det är all data, oavsett om det är big data, om det är traditionella data i relationella databaser, vi måste föra samman all den informationen så att vi kan hantera den och veta vad vi har att göra med i våra modeller.

Återigen, komplexiteten vi kommer att göra är att vi har ett antal steg som vi vill kunna göra. Först och främst går du in och du kanske inte har de blues av hur det informationslandskapet ser ut. I ett datamodelleringsverktyg som ER / Studio Data Architect kommer du först att göra en hel del omvänd teknik när det gäller att låta oss peka på datakällorna som finns där, föra in dem och sedan faktiskt sy dem samman till mer representativa modeller som representerar hela verksamheten. Det viktiga är att vi vill kunna sönderdela de modellerna också längs affärsgränserna så att vi kan relatera till dem i mindre bitar, som våra affärsmän också kan relatera till, och våra affärsanalytiker och andra intressenter som arbetar på det.

Namnstandarder är oerhört viktiga och jag talar om det på ett par olika sätt här. Namnge standarder i termer av hur vi namnger saker i våra modeller. Det är ganska lätt att göra i logiska modeller, där vi har en bra namnkonvention och en bra datakatalog för våra modeller, men då ser vi också olika namnkonventioner för många av dessa fysiska modeller som vi tar in. När vi reverse engineer, ganska ofta ser vi förkortade namn och den typen av saker som jag ska prata om. Och vi måste översätta dem tillbaka till meningsfulla engelska namn som är meningsfulla för företaget så att vi kan förstå vad alla dessa databitar är som vi har i miljön. Och sedan är universella kartläggningar hur vi syr samman dem.

Ovanpå det skulle vi sedan dokumentera och definiera ytterligare och det är där vi kan klassificera våra data ytterligare med något som heter Bilagor, som jag ska visa dig ett par bilder på. Och sedan stänga slingan, vill vi tillämpa den affärsbetydelsen, det är där vi binder in våra affärsordlistor och kan koppla dem till våra olika modellföremål, så vi vet, när vi talar om en viss affärsterm, där det är implementeras i våra data i hela organisationen. Och senast har jag redan pratat om att vi behöver allt detta förvar baserat med mycket samarbets- och publiceringsfunktioner, så att våra intressenter kan använda det. Jag kommer att prata om omvänd teknik ganska snabbt. Jag har redan gett dig en mycket snabb höjdpunkt på det. Jag kommer att visa det för dig i en verklig demo bara för att visa dig några av de saker som vi kan ta med där.

Och jag vill prata om några av de olika modelltyper och diagram som vi skulle producera i den här typen av scenarier. Självklart kommer vi att göra de konceptuella modellerna i många fall; Jag tänker inte spendera mycket tid på det. Jag vill verkligen prata om logiska modeller, fysiska modeller och de specialiserade modellerna som vi kan skapa. Och det är viktigt att vi kan skapa alla i samma modelleringsplattform så att vi kan sy dem samman. Det inkluderar dimensionella modeller och även modeller som använder några av de nya datakällorna, till exempel NoSQL som jag ska visa dig. Och hur ser datamodellmodellen ut? Och hur vi sammanfogar dessa data till en affärsprocessmodell är det vi kommer att prata om nästa.

Jag kommer att byta till en modelleringsmiljö här för att ge dig en mycket hög och snabb översikt. Och jag tror att du borde kunna se min skärm nu. Först och främst vill jag prata om bara en traditionell typ av datamodell. Och hur vi vill organisera modellerna när vi tar in dem, är att vi vill kunna sönderdela dem. Så det du ser här på vänster sida är att vi har logiska och fysiska modeller i just denna modellfil. Nästa sak är att vi kan dela upp det längs affärsnedbrytningarna, så det är därför du ser mapparna. De ljusblå är logiska modeller och de gröna är fysiska modeller. Och vi kan också borra ner, så inom ER / Studio, om du har en affärsnedbrytning, kan du gå så många nivåer djup eller delmodeller som du vill, och ändringar som du gör på de lägre nivåerna reflekteras automatiskt vid högre nivåer. Så det blir en mycket kraftfull modelleringsmiljö mycket snabbt.

Något som jag också vill påpeka att det är mycket viktigt att börja samla denna information är att vi kan ha flera fysiska modeller som motsvarar en logisk modell också. Ganska ofta kan du ha en logisk modell men du kan ha fysiska modeller på olika plattformar och den typen av saker. Kanske är en SQL Server-instans av den, kanske en annan är en Oracle-instans. Vi har förmågan att binda allt detta i samma modelleringsmiljö. Och där igen, vad jag har här är en faktisk datalagermodell som återigen kan vara i samma modelleringsmiljö eller så kan vi ha den i förvaret och länka den i olika saker också.

Det jag verkligen ville visa er på detta är några av de andra sakerna och andra varianter av modellerna som vi kommer in på. Så när vi går in i en traditionell datamodell som denna är vi vana att se de typiska enheterna med kolumnerna och metadata och den typen av saker, men den synvinkeln varierar mycket snabbt när vi börjar ta itu med några av dessa nyare NoSQL-teknologier , eller som vissa fortfarande gillar att kalla dem, stora datateknologier.

Så låt oss nu säga att vi också har Hive i vår miljö. Om vi ​​bakåtingenjörer från en Hive-miljö - och vi kan vidarebefordra och bakåtingenjör från Hive med exakt samma modelleringsverktyg - ser vi något som är lite annorlunda. Vi ser fortfarande all data som konstruktioner där, men våra TDL är annorlunda. De av er som är vana vid att se SQL, vad du skulle se nu är Hive QL, som är mycket SQL-liknande men av samma verktyg kan du nu börja arbeta med de olika skriptspråken. Så du kan modellera i den här miljön, generera den ut i Hive-miljön, men lika viktigt, i scenariot som jag har beskrivit, kan du vända det hela och förstå det och börja sömma det också .

Låt oss ta en annan som är lite annorlunda. MongoDB är en annan plattform som vi stöder nativt. Och när du börjar komma in i JSON-typer av miljöer där du har dokumentlagrar, är JSON ett annat djur och det finns konstruktioner i det, som inte motsvarar relationella modeller. Du börjar snart ta itu med begrepp som inbäddade objekt och inbäddade uppsättningar av objekt när du börjar förhöra JSON och dessa begrepp finns inte i den traditionella relationella notationen. Vad vi har gjort här är att vi faktiskt har utökat notationen och vår katalog för att kunna hantera det i samma miljö.

Om du tittar över till vänster här, istället för att se saker som enheter och tabeller, kallar vi dem för objekt. Och du ser olika notationer. Du ser fortfarande de typiska typerna av referensnotationer här, men dessa blå enheter som jag visar i detta specifika diagram är faktiskt inbäddade objekt. Och vi visar olika kardinaliteter. Diamantkardinaliteten innebär att det är ett objekt i ena änden, men kardinaliteten hos en innebär att vi har inom förlaget om vi följer det förhållandet, vi har ett inbäddat adressobjekt. När vi förhörde JSON har vi funnit att det är exakt samma struktur av objekt som är inbäddade i beskyddaren, men som faktiskt är inbäddade som en rad objekt. Vi ser det, inte bara genom själva kontakterna, utan om du tittar på de verkliga enheterna ser du att du ser adresser under beskydd som också klassificerar det som en rad objekt. Du får en mycket beskrivande syn på hur du kan ta in det.

Och igen, nu har vi sett hittills på bara några sekunder traditionella relationella modeller som är på flera nivåer, vi kan göra samma sak med Hive, vi kan göra samma sak med MongoDB och andra stora datakällor som väl. Vad vi också kan göra, och jag ska bara visa dig detta väldigt snabbt är, jag talade om att få in saker från andra områden. Jag kommer att anta att jag kommer att importera en modell från en databas eller omvänd ingenjör, men jag kommer att ta med den från externa metadata. Bara för att ge dig en mycket snabb syn på alla de olika typerna av saker som vi kan börja få in.

Som ni ser har vi en mängd saker som vi faktiskt kan föra metadata in i vår modelleringsmiljö med. Börjar med saker som till och med Amazon Redshift, Cassandra, många andra big data-plattformar, så du ser många av dessa listade. Detta är i alfabetisk ordning. Vi ser många stora datakällor och den typen av saker. Vi ser också många traditionella eller äldre modelleringsmiljöer som vi faktiskt kan ta fram de metadata. Om jag går igenom här - och jag tänker inte spendera tid på var och en av dem - ser vi många olika saker som vi kan ta med det från, när det gäller modelleringsplattformar och dataplattformar. Och något som är mycket viktigt att inse här är en annan del som vi kan göra när vi börjar prata om datastamning, på Enterprise Team Edition kan vi också förhöra ETL-källor, oavsett om det är saker som Talend eller SQL Server Information Services mappningar, vi kan ta med det faktiskt också för att starta våra datatrafikdiagram och rita en bild av vad som händer i dessa transformationer. Totalt har vi över 130 av dessa olika broar som faktiskt ingår i Enterprise Team Edition-produkten, så det hjälper oss verkligen att sammanföra alla artefakter till en modelleringsmiljö mycket snabbt.

Sist men inte minst vill jag också tala om det faktum att vi inte kan tappa synen på det faktum att vi behöver de andra typerna av konstruktioner om vi gör datalagring eller någon annan typ av analys. Vi vill fortfarande ha förmågan att göra saker som dimensionella modeller där vi har faktatabeller och vi har dimensioner och sådana saker. En sak jag också vill visa er är att vi också kan ha tillägg till våra metadata som hjälper oss att kategorisera vilka typer av dimensioner och allt annat. Så om jag tittar på den dimensionella datafliken här, till exempel, på en av dessa, kommer den faktiskt att automatiskt upptäcka, baserat på modellmönstret som den ser, och ge dig en utgångspunkt för huruvida den tror att det är en dimension eller en faktabord. Men utöver det, vad vi kan göra är inom dimensionerna och den typen av saker har vi till och med olika typer av dimensioner som vi kan använda för att klassificera informationen i en datalagringstyp miljö också. Så mycket kraftfulla kapaciteter att vi syr helt detta med.

Jag kommer att hoppa in i den här eftersom jag är i demomiljön just nu och visar dig ett par andra saker innan jag hoppar tillbaka till bilderna. En av de saker som vi nyligen har lagt till ER / Studio Data Architect är att vi har stött på situationer - och detta är ett mycket vanligt användningsfall när du arbetar med projekt - utvecklare tänker när det gäller objekt, medan våra data modellerare tenderar att tänka i termer av tabeller och enheter och den typen av saker. Detta är en mycket förenklad datamodell, men den representerar några grundläggande koncept, där utvecklarna eller till och med affärsanalytiker eller affärsanvändare kan tänka på dem som olika objekt eller affärsidéer. Det har varit väldigt svårt att klassificera dessa tills nu, men vad vi faktiskt har gjort i ER / Studio Enterprise Team Edition, i släppet 2016, är att vi nu har ett koncept som heter Business Data Objects. Och det som gör det möjligt för oss att göra det är att vi kan kapa grupper av enheter eller tabeller till verkliga affärsobjekt.

Till exempel, vad vi har här på den här nya vyn är inköpsorderhuvudet och orderraden har dragits samman nu, de är inkapslade som ett objekt, vi skulle tänka på dem som en arbetsenhet när vi fortsätter data , och vi samlar dem så det är nu väldigt lätt att relatera det till olika målgrupper. De kan återanvändas i hela modelleringsmiljön. De är ett sant objekt, inte bara en ritningskonstruktion, men vi har också den fördelen att när vi faktiskt kommunicerar från modelleringsperspektiv kan vi selektivt kollapsa eller utöka dem så att vi kan skapa en sammanfattad vy för dialoger med vissa intressentgrupper, och vi kan naturligtvis också hålla den mer detaljerade vyn som vi ser här för mer av de tekniska publiken. Det ger oss verkligen ett riktigt bra kommunikationsmedel. Det vi ser nu är att kombinera flera olika modelltyper, förstärka dem med konceptet för affärsdataobjekt, och nu ska jag prata om hur vi faktiskt tillämpar lite mer mening på dessa typer av saker och hur vi sys samman i våra övergripande miljöer.

Jag försöker bara hitta min WebEx här så att jag kan göra det. Och där går vi tillbaka till Hot Tech-bilderna. Jag kommer bara att spola fram några bilder här för att du redan har sett dem i själva modelldemonstrationen. Jag vill prata om namngivning av standarder mycket snabbt. Vi vill tillämpa och upprätthålla olika namnstandarder. Vad vi vill göra är att vi faktiskt kan lagra namnstandardmallar i våra förvar för att i princip bygga den meningen genom, genom ord eller fraser eller till och med förkortningar, och binda dem tillbaka till en meningsfull engelsk typ av ord. Vi kommer att använda affärsterminer, förkortningarna för varje, och vi kan ange ordning, fall och lägga till prefix och suffix. Det typiska användningsfallet för detta är vanligtvis när människor har byggt en logisk modell och sedan faktiskt kommit framåt för att skapa en fysisk modell där de kan ha använt förkortningar och allt annat.

Det vackra är att det är lika kraftfullt, ännu kraftfullare i omvänd riktning, om vi bara kan berätta vad några av dessa namnstandarder fanns på några av dessa fysiska databaser som vi har omvänt, kan vi ta dessa förkortningar, förvandla dem till längre ord och föra dem bakåt till engelska fraser. Vi kan faktiskt nu få egna namn på hur våra uppgifter ser ut. Som jag säger är det typiska användningsfallet att vi skulle gå framåt, logiska till fysiska, och kartlägga datalagren och den typen av saker. Om du tittar på skärmdumpen till höger ser du att det finns förkortade namn från källnamnen och när vi har använt en namnstandardmall har vi faktiskt fler fulla namn. Och vi kan lägga ut utrymmen och allt sådant om vi vill, beroende på vilken standard för mallen vi använde. Vi kan få den att se ut men vi vill att den ska se ut för att ta in våra modeller. Först när vi vet vad något heter kan vi faktiskt börja knyta definitioner till det, för om vi inte vet vad det är, hur kan vi tillämpa en mening på det?

Det trevliga är att vi faktiskt kan åberopa detta när vi gör alla slags saker. Jag talade om omvänd teknik, vi kan faktiskt åberopa namngörande standardmallar samtidigt när vi gör omvänd teknik. Så i en uppsättning steg genom en guide, vad vi kan göra är, om vi vet vad konventionerna är, kan vi omvända en fysisk databas, den kommer att föra tillbaka den som fysiska modeller i en modelleringsmiljö och det är kommer också att tillämpa dessa namnkonventioner. Så vi får se vad de engelska representationerna av namn är i motsvarande logiska modell i miljön. Vi kan också göra det och kombinera det med XML Schema-generation så att vi kan ta en modell och till och med driva ut den med våra förkortningar, oavsett om vi gör SOA-ramverk eller den typen av saker, så vi kan också driva ut olika namnkonventioner som vi faktiskt har lagrat i själva modellen. Det ger oss mycket mycket kraftfulla funktioner.

Återigen, här är ett exempel på hur det skulle se ut om jag hade en mall. Den här visar faktiskt att jag hade EMP för "anställd," SAL för "lön", PLN för "plan" i ett namnkonvention. Jag kan också tillämpa dem för att få dem att fungera interaktivt när jag bygger ut modeller och sätter in saker. Om jag använde den här förkortningen och jag skrev in ”Anställds löneplan” på enhetsnamnet, skulle det agera med namnsnormallmallen Jag har definierat här, det skulle ha gett mig EMP_SAL_PLN när jag skapade enheterna och gett mig motsvarande fysiska namn direkt.

Återigen, mycket bra för när vi också utformar och vidarebefordrar teknik. Vi har ett mycket unikt koncept och det är där vi verkligen börjar föra samman dessa miljöer.Och det kallas Universal Mappings. När vi har fört alla dessa modeller in i vår miljö, vad vi kan göra, förutsatt att vi nu har använt dessa namnkonventioner och de är lätta att hitta, kan vi nu använda en konstruktion som heter Universal Mappings i ER /Studio. Vi kan länka enheter mellan modeller. Oavsett var vi ser "kund" - vi kommer förmodligen att ha "kund" i många olika system och många olika databaser - kan vi börja koppla alla dessa tillsammans så att när jag arbetar med det i en modell jag kan se var är manifestationerna hos kunderna i de andra modellerna. Och eftersom vi har modellskiktet som representerar det, kan vi till och med binda det i datakällor och föra det ned i vår där använda förfrågningar om vilka databaser som dessa också finns i. Det ger oss verkligen en förmåga att binda allt detta mycket sammanhängande.

Jag har visat er affärsdataobjekt. Jag vill också prata om metadata-tillägg, som vi kallar bilagor, mycket snabbt. Vad det gör är att det ger oss möjligheten att skapa ytterligare metadata för våra modellobjekt. Ganska ofta skulle jag ställa in dessa typer av egenskaper för att driva en hel del olika saker ur ett datahantering och datakvalitetsperspektiv, och också för att hjälpa oss med grundläggande datahantering och policy för datalagring. Den grundläggande idén är att du skapar dessa klassificeringar och du kan bifoga dem vart du vill, på tabellnivå, kolumnnivå, de typerna av saker. Det vanligaste användningsfallet är naturligtvis att enheter är tabeller och sedan kan jag definiera: vad är mina masterdataobjekt, vad är mina referenstabeller, vilka är mina transaktionstabeller? Från ett datakvalitetsperspektiv kan jag göra klassificeringar i termer av betydelse för verksamheten så att vi kan prioritera datarengöringsinsatser och den typen av saker.

Något som ofta förbises är, vad är lagringspolicyn för olika typer av data i vår organisation? Vi kan ställa in dessa och vi kan faktiskt fästa dem till de olika typerna av informationsföremål i vår modelleringsmiljö och, naturligtvis, till vårt förvar också. Det vackra är, om dessa bilagor lever i vår datorordbok så när vi använder företagsdataordböcker i miljön kan vi fästa dem till flera modeller. Vi måste bara definiera dem en gång och vi kan utnyttja dem om och om igen mellan olika modeller i vår miljö. Detta är bara en snabb skärmdump för att visa att du faktiskt kan specificera när du gör en bilaga, vad alla bitar är som du vill koppla den till. Och det här exemplet här är faktiskt en lista med värden, så när de kommer in kan du välja från en lista med värden, du har mycket kontroll i modelleringsmiljön för vad som väljs och du kan till och med ställa in vilket standard värde är om ett värde inte väljs. Så mycket kraft där. De lever i dataordboken.

Något jag vill visa dig lite längre ner på den här skärmen, dessutom ser du de bilagor som dyker upp i den övre delen, under den ser du datasäkerhetsinformation. Vi kan faktiskt också tillämpa datasäkerhetspolicyer för olika informationsdelar i miljön. För olika överensstämmelsekartläggningar, datasäkerhetsklassificeringar skickar vi ett antal av dem som du bara kan skapa och börja använda, men du kan också definiera dina egna överensstämmelsekartläggningar och standarder. Oavsett om du gör HIPAA eller något annat initiativ där ute. Och du kan verkligen börja bygga upp denna mycket rika uppsättning metadata i din miljö.

Och sedan ordlistan och villkoren - det är här den affärsmässiga betydelsen är knuten till. Vi har ganska ofta datorordböcker där som en organisation ganska ofta använder som en utgångspunkt för att börja driva ut ordlistor, men terminologin och verbiage är ofta mycket tekniskt. Så vad vi kan göra är att vi kan, om vi vill, använda dem som en utgångspunkt för att driva ut ordlistor, men vi vill verkligen att verksamheten ska äga dessa. Det vi har gjort i teamserverns miljö är att vi har gett människor möjlighet att skapa affärsdefinitioner och sedan kan vi länka dem till de olika modellföremål som de motsvarar i modelleringsmiljön också. Vi känner också igen den punkt som diskuterades tidigare vilket är, ju fler människor du skriver, desto större potential finns det för mänskliga misstag. Det vi också gör i vår ordlista är att vi stöder en hierarki med ordlista, så vi kan ha olika ordlistor eller olika typer av saker i organisationen, men lika viktigt är att om du redan har några av dessa källor där ute med villkoren och allt definierat, kan vi faktiskt göra en CSV-import för att dra dessa in i vår modelleringsmiljö och vår teamserver eller vår ordlista också, och sedan börja länka därifrån. Och varje gång något ändras finns det en fullständig granskningsspår av vad före och efter bilder var, i termer av definitionerna och allt annat, och vad du kommer att se komma inom en mycket nära framtid är också mer ett godkännande arbetsflöde så vi kan verkligen kontrollera vem som ansvarar för det, godkännanden från utskott eller individer och den typen av saker för att göra styrningsprocessen ännu mer robust när vi går framåt.

Vad detta också gör för oss är när vi har dessa ordlistor i vår gruppserverordlista, detta är ett exempel på redigering i en enhet i själva modellen som jag har tagit upp här. Det kan ha länkade termer, men det vi också gör är om det finns ord som finns i den ordlistan som visas i anteckningarna eller beskrivningarna av vad vi har i våra enheter här, de visas automatiskt i en lättare hyperlänkad färg, och om vi med musen över dem kan vi faktiskt se definitionen från företagsordlistan också. Det ger oss ännu mer information när vi konsumerar själva informationen, med alla ordlistor som finns där ute. Det hjälper verkligen att berika upplevelsen och tillämpa innebörden på allt vi arbetar med.

Så igen, det var en mycket snabb flyby. Vi kan uppenbarligen spendera dagar på detta när vi studerar de olika delarna, men detta är en mycket snabb flyby över ytan. Det vi verkligen strävar efter är att förstå hur dessa komplexa datamiljöer ser ut. Vi vill förbättra synligheten för alla dessa dataartefakter och samarbeta för att driva dem ut med ER / Studio. Vi vill möjliggöra effektivare och automatiserad datamodellering. Och det är alla typer av data som vi pratar om, oavsett om det är big data, traditionella relationsdata, dokumentlagrar eller något annat. Och igen uppnådde vi det eftersom vi har kraftfulla tekniker för framåt och bakåt för de olika plattformarna och de andra verktygen du kan ha där ute. Och det handlar om att dela och kommunicera över hela organisationen med alla berörda parter. Det är där vi tillämpar mening genom namngivningsstandarder. Vi tillämpar sedan definitioner genom våra affärsordlistor. Och sedan kan vi göra ytterligare klassificeringar för alla våra andra styrningskapaciteter med metadata-tillägg, till exempel datakvalitetsförlängningar, klassificeringar för masterdatahantering eller andra typer av klassificeringar som du vill använda på den informationen. Och sedan kan vi sammanfatta ytterligare och förbättra kommunikationen ännu mer med affärsdataobjekten, med olika intressentgrupper, särskilt mellan modellerare och utvecklare.

Och igen, det som är mycket viktigt med detta är, bakom allt är ett integrerat arkiv med mycket robusta förändringshanteringsfunktioner. Jag hade ingen tid att visa det idag eftersom det blir ganska komplicerat, men förvaret har mycket robusta förändringshanteringsfunktioner och revisionsspår. Du kan göra namngivna versioner, du kan göra namngivna versioner, och vi har också förmågan för de av er som gör ändringshantering, vi kan binda det rätt i dina uppgifter. Vi har möjlighet idag att lägga upp uppgifter och associera dina modelländringar med uppgifter, precis som utvecklare skulle associera sina kodändringar med uppgifterna eller användarhistorier som de också arbetar med.

Återigen var det en mycket snabb översikt. Jag hoppas att det har räckt för att få din aptit så att vi kan delta i mycket djupare samtal om att dela ut några av dessa ämnen när vi går framöver. Tack för din tid och tillbaka till dig, Rebecca.

Rebecca Jozwiak: Tack Ron, det var fantastiskt och jag har en hel del frågor från publiken, men jag vill ge våra analytiker en chans att sjunka tänderna i det du har sagt. Eric, jag kommer att gå vidare och kanske om du vill ta itu med den här bilden, eller en annan, varför går du inte vidare först? Eller någon annan fråga.

Eric Little: Säker. Tyvärr, vad var frågan, Rebecca? Vill du att jag ska fråga något specifikt eller ...?

Rebecca Jozwiak: Jag vet att du ursprungligen hade några frågor till Ron. Om du vill be nu om att han ska adressera någon av dem, eller några av dem från din bild eller något annat som väckte ditt intresse som du vill fråga om? Om IDERAs modelleringsfunktioner.

Eric Little: Ja, så en av sakerna, Ron, så hur ser ni, det ser ut som att diagrammen som ni visade är generella typer av enhetsförhållande diagram som ni vanligtvis skulle använda i databaskonstruktion, rätt?

Ron Huizenga: Ja, generellt sett, men naturligtvis har vi de utökade typerna för dokumentlagren och den typen av saker också. Vi har faktiskt varierat från bara ren relationell notation, vi har faktiskt lagt till ytterligare notationer för de andra butikerna också.

Eric Little: Finns det ett sätt som ni kan använda grafbaserade modeller av modeller, så finns det ett sätt att integrera, till exempel, låt oss anta att jag har något som en toppkvadrant, TopBraid kompositverktyg eller att jag har gjort något i Protégé eller , du vet, liksom de finansiella killarna i FIBO, de gör en hel del arbete inom semantik, RDF-grejer - finns det ett sätt att få in den här typen av grafikmodeller av enhet-relation-graf i det här verktyget och använda det?

Ron Huizenga: Vi tittar faktiskt på hur vi kan hantera grafer. Vi hanterar inte uttryckligen grafdatabaser och den typen av saker idag, men vi tittar på hur vi kan göra det för att utvidga våra metadata. Jag menar, vi kan ta in saker genom XML och den typen av saker just nu, om vi åtminstone kan göra någon form av en återgivning av XML för att ta det in som utgångspunkt. Men vi tittar på mer eleganta sätt att ta in det.

Och jag visade också den listan över broar som vi har där också, så vi tittar alltid på att få tillägg till dessa broar för specifika plattformar också. Det är en kontinuerlig, pågående ansträngning, om det är vettigt, att börja omfamna en hel del av dessa nya konstruktioner och de olika plattformarna där ute. Men jag kan säga att vi definitivt är i spetsen för att göra det. De saker jag visade på till exempel MongoDB och den typen av saker, vi är den första leverantören av datamodellering som faktiskt gör det naturligt i vår egen produkt.

Eric Little: Okej, ja. Så den andra frågan jag hade för dig var då när det gäller styrning och upprätthållande av - som när du använde exemplet, när du visade exemplet på personen som är en "anställd", jag tror att det var en " lön ”och sedan har du en” plan ”, finns det ett sätt, hur hanterar du till exempel olika typer av människor som kan ha - låt oss anta att du har en stor arkitektur, rätt, låt oss anta att du har ett stort företag och folk börjar samla saker i det här verktyget och du har en grupp här som har ordet "anställd" och en grupp här som har ordet "arbetare." Och en person här säger "lön" och en annan person säger "lön."

Hur förenar ni och hanterar och styr sådana distinktioner? Eftersom jag vet hur vi skulle göra det i grafvärlden, vet du, du skulle använda synonymlistor eller så kan du säga att det finns ett koncept och det har flera attribut, eller så kan du säga i SKOS-modellen att jag har en föredragen etikett och jag har flera alternativa etiketter som jag kan använda. Hur gör ni det?

Ron Huizenga: Vi gör det på ett par olika sätt och låt oss först prata om terminologin först. En av de saker som vi gör är naturligtvis att vi vill ha de definierade eller sanktionerade termerna och i affärsordlistan är uppenbarligen var vi vill ha dem. Och vi tillåter också länkar till synonymer i företagsordlistan, så vad du kan göra är att du kan säga, här är min term, men du kan också definiera vad alla synonymer för dem är.

Nu är naturligtvis det intressanta när du börjar titta över det stora datalandskapet med alla dessa olika system som du har där ute, du kan inte bara gå ut där och ändra motsvarande tabeller och dessa typer av saker till motsvarar den namngivningsstandarden eftersom det kan vara ett paket du köpte, så du har ingen kontroll över att ändra databasen eller någonting alls.

Det vi kunde göra där, förutom att vi kan associera definitionerna av ordlistor, är genom de universella kartläggningar som jag talade om, vad vi skulle göra, och typ av en rekommenderad strategi, är att ha en övergripande logisk modell som fastställer vad dessa olika affärsidéer är det du pratar om. Bind affärsordlistor till dessa, och det trevliga är nu att du har denna konstruktion som representerar en logisk enhet som den var, kan du sedan börja länka från den logiska enheten till alla implementeringarna av den logiska enheten i de olika systemen.

Då du behöver på det kan du se, oh, "person" här kallas "anställd" i detta system. "Lön" här kallas "lön" här i detta andra system. Eftersom du ser det ser du alla de olika manifestationerna av dem eftersom du har kopplat dem ihop.

Eric Little: Okej bra, ja, det har du. I det avseendet, är det säkert att säga att det är så som några av de objektorienterade metoderna?

Ron Huizenga: Något. Det är lite mer intensivt än, antar jag att du kan säga. Jag menar, du kan ta tillvägagångssättet att manuellt länka och gå igenom och inspektera och göra dem alla också. Den ena saken hade jag inte riktigt en chans att prata om - för igen har vi en hel del funktioner - vi har också ett komplett automatiseringsgränssnitt i själva Data Architect-verktyget. Och en makrofunktion, som verkligen är ett programmeringsspråk i verktyget. Så vi kan faktiskt göra saker som att skriva makron, låta det gå ut och förhöra saker och skapa länkar för dig. Vi använder den för att importera och exportera information, vi kan använda den för att ändra saker eller lägga till attribut, händelse baserad i själva modellen, eller vi kan använda den för att köra i partier för att faktiskt gå ut och förhöra saker och faktiskt fylla olika konstruktioner i modell. Så det finns ett komplett automatiseringsgränssnitt som människor också kan dra nytta av. Och att använda de universella kartläggningarna med dessa skulle vara ett mycket kraftfullt sätt att göra det.

Rebecca Jozwiak: Okej, tack Ron, och tack Eric. Det var fantastiska frågor. Jag vet att vi springer lite förbi timmen, men jag skulle vilja ge Malcolm chansen att kasta några frågor från Ron. Malcolm?

Malcolm Chisholm: Tack, Rebecca. Så Ron, det är väldigt intressant, jag ser att det finns mycket kapacitet här. Ett av de områden som jag är väldigt intresserad av är att säga om vi har ett utvecklingsprojekt, hur ser du datamodern som använder dessa funktioner och kanske arbetar mer samarbete med affärsanalytiker, med en dataprofilator, med en datakvalitetsanalytiker , och med de affärsponsorer som slutligen kommer att ansvara för de faktiska informationskraven i projektet. Hur gör datamodelleren verkligen, du vet, projektet mer effektivt och effektivt med de funktioner vi tittar på?

Ron Huizenga: Jag tror att en av de första sakerna du måste göra där är som en datamodeller - och jag menar inte att välja några modellerare, men jag kommer ändå att göra det - är att vissa människor fortfarande har intryck av att datamodelleren är verkligen portvaktens typ av roll av liknande, vi definierar hur det fungerar, vi är vakterna som ser till att allt är korrekt.

Nu är det en aspekt av det, att du måste se till att du definierar en ljuddataarkitektur och allt annat. Men det viktigare är som datamodeller - och jag tyckte att det ganska uppenbart när jag konsulterade - är att du måste bli en underlättare, så du måste ta dessa människor ihop.

Det kommer inte att vara en design framåt, generera, bygga databaser längre - det du behöver kunna göra är att du behöver kunna arbeta med alla dessa olika intressentgrupper, göra saker som omvänd teknik, importera information i, ha andra människor samarbetar, oavsett om det finns i ordlistorna eller dokumentationen, allt sådant - och vara en underlättare för att dra detta in i förvaret, och koppla samman koncepten i förvaret och arbeta med dessa människor.

Det är verkligen mycket mer av en samverkande typ av miljö där även genom definition av uppgifter eller till och med diskussionstrådar eller den typen av saker som vi har i teamserver, att människor faktiskt kan samarbeta, ställa frågor och komma fram till de slutliga produkterna som de behov av deras dataarkitektur och deras organisation. Har den sortens svar?

Malcolm Chisholm: Ja jag håller med. Du vet, jag tror att underlättningsförmågan är något som verkligen är mycket önskvärt hos datamodeller. Jag håller med om att vi inte alltid ser det, men jag tror att det är nödvändigt och jag skulle föreslå att det ibland finns en benägenhet att stanna i ditt hörn och göra din datamodellering, men du måste verkligen vara ute och arbeta med de andra intressentgrupperna eller så förstår du bara inte den datamiljö som du har att göra med, och jag tror att modellen lider som ett resultat. Men det är bara min åsikt.

Ron Huizenga: Och det är intressant eftersom du nämnde något tidigare i din bild om historien om hur företag är lite avvisade från IT eftersom de inte levererade lösningarna i tid och sådana saker.

Det är väldigt intressant att i mina senare konsultuppdrag, innan jag blev produktchef, var de flesta av de projekt som jag gjorde under de senaste två åren före det företagsponsorerade, där det verkligen var företaget som driver det och dataarkitterna och modellerare var inte en del av IT. Vi var en del av en företagssponserad grupp och vi var där som underlättare som arbetade med resten av projektgrupperna.

Malcolm Chisholm: Så jag tycker att det är en mycket intressant sak.Jag tror att vi börjar se en förändring i affärsvärlden där verksamheten frågar, eller kanske tänker, inte så mycket som vad jag gör, att processa, men de börjar också tänka på vad som är data att jag arbetar med, vilka är mina databehov, vad är de uppgifter jag har med som data och i vilken utsträckning kan vi få IDERA-produkter och -funktioner för att stödja den synvinkeln, och jag tror att företagets behov, till och med även om det är ganska fortfarande lite framtida.

Ron Huizenga: Jag håller med dig och jag tror att vi ser att det går mer och mer på det sättet. Vi har sett en uppvaknande och du berörde det tidigare när det gäller vikten av data. Vi såg vikten av data tidigt i IT eller i utvecklingen av databaser, då som du säger, vi gick in i hela denna processhanteringscykel - och processen är oerhört viktig, gör mig inte fel där - men nu vad som hände när det hände, data typ av förlorat fokus.

Och nu inser organisationer att data verkligen är samlingspunkten. Data representerar allt vi gör i vår verksamhet, så vi måste se till att vi har korrekt information, så att vi kan hitta rätt information som vi behöver för att fatta våra beslut. Eftersom inte allt kommer från en definierad process. En del av informationen är en biprodukt av andra saker och vi måste fortfarande kunna hitta den, veta vad den innebär och kunna översätta de uppgifter som vi ser där till slut till kunskap som vi kan använda för att driva våra företag bättre.

Malcolm Chisholm: Rätt, och nu ett annat område som jag har kämpat med är vad jag skulle kalla datan livscykel som är, du vet, om vi ser på vilken typ av dataförsörjningskedja som går igenom ett företag, skulle vi börja med datainsamling eller datafångst, vilket kan vara datainmatningen, men det kan också vara, jag får data utanför företaget från någon dataleverantör.

Och sedan från datafångst går vi till dataunderhåll där jag funderar på att standardisera denna data och skicka dem till platser där de behövs. Och sedan dataanvändning, de faktiska punkterna där data är, kommer du att få värde ur uppgifterna.

Och i gamla dagar görs allt i en enskild stil, men idag kan det vara, du vet, en analytisk miljö, till exempel, och sedan utöver det, ett arkiv, en butik, där vi lägger data när vi inte längre behöver det och slutligen en ren typ av process. Hur ser du datamodellering anpassas till hanteringen av hela datalivscykeln?

Ron Huizenga: Det är en väldigt bra fråga och en sak som jag verkligen inte hade tid att fördjupa mig i någon detalj här idag alls, är det vi verkligen börjar prata om är datalinjer. Så vad vi faktiskt kan göra är att vi har en datalinjefunktion i våra verktyg och som jag säger kan vi faktiskt extrahera en del av det från ETL-verktyg, men du kan också kartlägga det bara genom att rita linjen också. Några av dessa datamodeller eller databaser som vi har fångat in och tagit in modeller kan vi hänvisa till konstruktionerna från det i vårt datablad.

Vad vi kan göra är att dra ett dataflöde, som du säger, från källa till mål, och genom den övergripande livscykeln för hur informationen överförs genom de olika systemen och vad du kommer att hitta är, låt oss ta anställda data - det är en av mina favoriter baserat på ett projekt som jag gjorde för år sedan. Jag arbetade med en organisation som hade medarbetardata i 30 olika system. Vad vi slutade med att göra där - och Rebecca dök upp datastambilden - det här är en ganska förenklad datalina här, men vad vi kunde göra var att få in alla datastrukturer, hänvisa till dem i diagrammet och sedan vi kan faktiskt börja titta på vad är flödena mellan, och hur är de olika dataenheterna länkade samman i ett flöde? Och vi kan gå utöver det också. Detta är en del av ett dataflöde eller avstamningsdiagram som vi ser här. Om du vill gå längre än det har vi också affärsarkitekten som del av denna svit och samma sak gäller där.

Vilken som helst av datastrukturerna som vi har fångat i datamodelleringsmiljön, de kan hänvisas till i affärsmodelleringsverktyget så att även i dina affärsmodelldiagram eller dina affärsprocessdiagram kan du referera till enskilda datalagrar om du vill datamodelleringsmiljön, och medan du använder dem i mapparna i din affärsprocessmodell kan du till och med ange CRUD på dessa också, hur informationen antingen konsumeras eller produceras, och sedan kan vi börja generera saker som konsekvens- och analysrapporter och diagram ur det.

Vad vi syftar till att komma till, och vi har redan många kapaciteter, men en av de saker som vi typ har som en slags målpost som vi tittar på när vi fortsätter att utveckla våra verktyg framöver, kan kartlägga den slutgiltiga, organisatoriska datalinjen och datans hela livscykel.

Malcolm Chisholm: Okej. Rebecca, får jag tillåta en till?

Rebecca Jozwiak: Jag tillåter er en till, Malcolm, gå vidare.

Malcolm Chisholm: Tack så mycket. Tänker vi på datastyrning och tänker på datamodellering, hur får vi dessa två grupper att arbeta effektivt och förstå varandra?

Eric Little: Det är intressant, jag tror att det verkligen beror på organisationen, och det går tillbaka till mitt tidigare koncept är, i de organisationer där initiativen var affärsdrivna var vi bundna i. Till exempel ledde jag ett dataarkitekturteam men vi var bundna direkt med affärsanvändarna och vi hjälpte dem faktiskt att ställa upp deras dataprogram. Återigen mer av ett rådgivande tillvägagångssätt men det är verkligen mer en affärsfunktion.

Det du verkligen behöver för att kunna göra det är att du behöver datamodeller och arkitekter som verkligen förstår affärer, kan relatera till företagets användare och sedan har hjälpt dem att stå upp styrningsprocesserna kring det. Verksamheten vill göra det, men generellt sett har vi teknikkunskap för att kunna hjälpa dem att sticker ut de typer av program. Det måste verkligen vara ett samarbete, men det måste vara affärsägt.

Malcolm Chisholm: Okej, det är bra. Tack.

Dr. Eric Little: Okej.

Rebecca Jozwiak: Okej, tack så mycket. Publikmedlemmar, jag är rädd att vi inte har kommit till dina frågor, men jag kommer att se till att de kommer vidarebefordras till den lämpliga gäst vi hade på linjen idag. Jag vill tacka så mycket till Eric, Malcolm och Ron för att vi var våra gäster idag. Det här var bra grejer, folkens. Och om du gillade dagens IDERA-webbsändning kommer IDERA också att vara med på en Hot Technologies nästa onsdag om du vill vara med och diskutera utmaningarna med indexering och Oracle, så ett annat fascinerande ämne.

Tack så mycket, folk, se till, så ser vi er nästa gång. Hejdå.