Door Techopedia Staff, 28 september 2016
Takeaway: Host Rebecca Jozwiak bespreekt oplossingen voor gegevensarchitectuur met Eric Little van OSTHUS, Malcolm Chisholm van First San Francisco Partners en Ron Huizenga van IDERA.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Rebecca Jozwiak: Dames en heren, hallo en welkom bij Hot Technologies van 2016. Vandaag bespreken we "Een bedrijfsgestuurde gegevensarchitectuur bouwen", absoluut een hot topic. Mijn naam is Rebecca Jozwiak, ik zal uw gastheer zijn voor de webcast van vandaag. We tweeten met een hashtag van # HotTech16, dus als je al op Twitter bent, kun je dat ook doen. Als je op enig moment vragen hebt, stuur ze dan naar het Q & A-paneel rechts onderaan je scherm en wij zorgen ervoor dat ze worden beantwoord. Zo niet, dan zorgen wij ervoor dat onze gasten ze voor u krijgen.
Dus vandaag hebben we een echt fascinerende line-up. Veel zware slagmensen zijn vandaag bij ons. We hebben Eric Little, vice-president data science van OSTHUS. We hebben Malcolm Chisholm, chief innovation officer, wat een heel coole titel is voor First San Francisco Partners. En we hebben Ron Huizenga, senior productmanager van IDERA. En weet je, IDERA heeft een echt volledig pakket oplossingen voor gegevensbeheer en modellering. En vandaag gaat hij ons een demo geven over hoe zijn oplossing werkt. Maar voordat we daarop ingaan, Eric Little, ga ik de bal aan je doorgeven.
Eric Little: Oké, heel erg bedankt. Dus ik ga hier een paar onderwerpen doornemen waarvan ik denk dat ze een beetje betrekking zullen hebben op Ron's talk en hopelijk ook het podium voor sommige van deze onderwerpen, wat Q&A.
Dus het ding dat me interesseerde in wat IDERA doet, is dat ik denk dat ze er terecht op wijzen dat complexe omgevingen tegenwoordig echt veel zakelijke waarden aandrijven. En met complexe omgevingen bedoelen we complexe gegevensomgevingen. En technologie gaat echt snel en het is moeilijk om de huidige zakelijke omgeving bij te houden. Dus mensen die in technologische ruimtes werken, zullen vaak zien dat je klanten hebt die problemen oplossen met: “Hoe gebruik ik big data? Hoe neem ik semantiek op? Hoe koppel ik sommige van deze nieuwe dingen aan mijn oudere gegevens? 'Enzovoort, en dat leidt ons tegenwoordig naar deze vier v's met big data waar veel mensen behoorlijk bekend mee zijn, en ik begrijp dat er meer dan vier kunnen zijn soms - ik heb er maar liefst acht of negen gezien - maar normaal gesproken, wanneer mensen praten over dingen zoals big data of als je het hebt over big data, kijk je meestal naar iets dat op een soort bedrijfsschaal lijkt. En dus zullen mensen zeggen, oké, nou, denk na over het volume van uw gegevens, dat normaal gesproken de focus is - dat is precies hoeveel u hebt. De snelheid van de gegevens heeft te maken met hoe snel ik het kan verplaatsen of hoe snel ik het kan opvragen of de antwoorden kan krijgen, enzovoort. En persoonlijk denk ik dat de linkerkant daarvan iets is dat relatief snel wordt opgelost en afgehandeld door veel verschillende benaderingen. Maar aan de rechterkant zie ik veel mogelijkheden voor verbetering en veel nieuwe technologieën die echt op de voorgrond komen. En dat heeft echt te maken met de derde kolom, de gegevensvariëteit.
Met andere woorden, de meeste bedrijven kijken tegenwoordig naar gestructureerde, semi-gestructureerde en ongestructureerde gegevens. Beeldgegevens beginnen een hot topic te worden, dus als je computer vision kunt gebruiken, naar pixels kunt kijken, tekst kunt schrapen, NLP, entiteitsextractie, heb je grafiekinformatie die uit statistische modellen komt of die uit semantisch komt modellen, u hebt relationele gegevens die in tabellen bestaan, enzovoort. Dus het verzamelen van al die gegevens en al deze verschillende soorten is echt een grote uitdaging en je zult dit zien in, weet je, in Gartner en andere mensen die de trends in de industrie volgen.
En dan is het laatste waar mensen het in big data over hebben vaak deze notie van vraatzucht, wat eigenlijk de onzekerheid van uw gegevens is, de vaagheid ervan. Hoe goed weet u waar uw gegevens over gaan, hoe goed begrijpt u wat er in zit en weet u dat? De mogelijkheid om statistieken te gebruiken en de mogelijkheid om een bepaald soort informatie te gebruiken over wat u misschien kent of om een context te gebruiken, kan daar van waarde zijn. En dus de mogelijkheid om op deze manier naar gegevens te kijken in termen van hoeveel u hebt, hoe snel u het nodig hebt om het te verplaatsen of te krijgen, alle soorten gegevens die u mogelijk in uw onderneming heeft en hoe zeker u bent over waar het is, wat het is, in welke kwaliteit het is, enzovoort. Dit vereist nu echt een grote, gecoördineerde inspanning tussen veel mensen om hun gegevens effectief te beheren. Het modelleren van gegevens wordt daarom steeds belangrijker in de wereld van vandaag. Goede datamodellen zorgen dus echt voor veel succes in bedrijfstoepassingen.
Je hebt databronnen uit verschillende bronnen, zoals we al zeiden, die echt veel verschillende soorten integratie vereist. Het is dus erg handig om alles samen te voegen, bijvoorbeeld om vragen uit verschillende typen gegevensbronnen te kunnen uitvoeren en informatie terug te halen. Maar om dat te doen, heb je goede mappingstrategieën nodig en dus het in kaart brengen van dat soort gegevens en het bijhouden van die toewijzingen kan een echte uitdaging zijn. En dan heb je deze kwestie van, nou, hoe koppel ik mijn oude gegevens aan al deze nieuwe gegevensbronnen? Dus stel dat ik een grafiek heb, neem ik al mijn relationele gegevens en zet ik deze in een grafiek? Meestal is dat geen goed idee. Dus hoe komt het dat mensen al dat soort datamodellen kunnen beheren die aan de gang zijn? Analyse moet echt op veel van deze verschillende soorten gegevensbronnen en combinaties worden uitgevoerd. Dus de antwoorden die hieruit voortvloeien, de antwoorden die mensen nodig hebben om echt goede zakelijke beslissingen te nemen, is van cruciaal belang.
Dus dit gaat niet alleen over het bouwen van technologie omwille van technologie, het is echt, wat ga ik doen, wat kan ik ermee doen, wat voor soort analyse kan ik uitvoeren, en het vermogen daarom, zoals ik al heb gedaan waar ik het over heb gehad, om dit samen te brengen, om het te integreren is echt, echt belangrijk. En een van dit soort analyses wordt vervolgens uitgevoerd op zaken als federated search en query. Dat wordt echt een must. Uw vragen moeten normaal gesproken over meerdere soorten bronnen worden gerangschikt en informatie betrouwbaar terughalen.
Het enige belangrijke element dat vaak, vooral mensen, gaat kijken naar belangrijke dingen zoals semantische technologieën - en dit is iets waarvan ik hoop dat Ron erover gaat praten in de IDERA-benadering - is hoe je de modellaag van uw gegevens van de gegevenslaag zelf, van die onbewerkte gegevens? Dus bij de gegevenslaag kunt u databases hebben, u kunt documentgegevens hebben, u kunt spreadsheetgegevens hebben, u kunt beeldgegevens hebben. Als je in gebieden zoals de farmaceutische industrie bent, heb je enorme hoeveelheden wetenschappelijke gegevens. En bovendien zoeken mensen normaal gesproken naar een manier om een model te bouwen waarmee ze die gegevens snel kunnen integreren en echt wanneer u op zoek bent naar gegevens nu wilt u niet alle gegevens naar uw modellaag halen, kijk je naar de modellaag om je een mooie logische weergave te geven van wat dingen zijn, gemeenschappelijke vocabulaires, gemeenschappelijke soorten entiteiten en relaties, en de mogelijkheid om echt de gegevens te bereiken waar het is. Het moet dus zeggen wat het is, en het moet zeggen waar het is, en het moet zeggen hoe het moet worden opgehaald en teruggebracht.
Dus dit is een benadering geweest die behoorlijk succesvol is geweest in het voortstuwen van semantische technologieën, een gebied waar ik veel werk. Dus een vraag die ik wilde stellen voor Ron, en waarvan ik denk dat die nuttig zal zijn in de sectie Q&A, is om te zien hoe dit wordt bereikt door het IDERA-platform? Dus is de modellaag eigenlijk gescheiden van de gegevenslaag? Zijn ze meer geïntegreerd? Hoe werkt dat en wat zijn enkele van de resultaten en voordelen die ze van hun aanpak zien? Daarom worden referentiegegevens ook echt kritisch. Dus als je dit soort datamodellen hebt, als je dingen kunt bundelen en doorzoeken, moet je echt goede referentiegegevens hebben. Maar het probleem is dat referentiegegevens erg moeilijk te onderhouden kunnen zijn. Het is dus vaak een moeilijke uitdaging om normen op zichzelf te noemen. Eén groep zal iets X noemen en één groep zal iets Y noemen en nu heb je het probleem hoe iemand X en Y vindt wanneer ze op zoek zijn naar dit soort informatie? Omdat je ze niet gewoon een deel van de gegevens wilt geven, wil je ze alles geven wat met elkaar te maken heeft. Tegelijkertijd veranderen de voorwaarden, wordt software verouderd, enzovoort, hoe kunt u die referentiegegevens in de loop van de tijd bijhouden en onderhouden?
En nogmaals, semantische technologieën, met name het gebruik van dingen zoals taxonomieën en vocabulaires, gegevenswoordenboeken, hebben hiervoor een standaard manier geboden, die echt zeer robuust is, het gebruikt bepaalde soorten normen, maar de database-gemeenschap heeft dit gedaan voor een ook lang, alleen op verschillende manieren. Ik denk dat een van de sleutels hier is om na te denken over het gebruik van misschien entiteit-relatiemodellen, hoe je misschien grafiekmodellen kunt gebruiken of een soort aanpak hier die je hopelijk een standaard gespreide manier geeft om je referentiegegevens te verwerken. En als u eenmaal de referentiegegevens hebt, moeten de kaartstrategieën natuurlijk een breed scala aan namen en entiteiten beheren. Vakdeskundigen gebruiken dus vaak hun eigen termen.
Dus een uitdaging hierin is altijd, hoe geef je iemand informatie, maar maak je deze relevant voor de manier waarop ze erover praten? Dus één groep kan op één manier naar iets kijken, bijvoorbeeld, u kunt een chemicus zijn die aan een medicijn werkt, en u kunt een structurele bioloog zijn die aan hetzelfde medicijn werkt, en u kunt verschillende namen voor dezelfde soorten entiteiten hebben die betrekking hebben op uw vakgebied. Je moet manieren bedenken om die gepersonaliseerde terminologieën samen te brengen, want de andere benadering is dat je mensen moet dwingen hun termijn te laten vallen en die van iemand anders te gebruiken, die ze vaak niet leuk vinden. Een ander punt hier is dat het verwerken van grote aantallen synoniemen moeilijk wordt, dus er zijn veel verschillende woorden in de gegevens van veel mensen die naar hetzelfde kunnen verwijzen. Je hebt daar een referentieprobleem met behulp van een groot aantal relaties. Gespecialiseerde termen variëren van branche tot branche, dus als u een soort overkoepelende oplossing voor dit type gegevensbeheer gaat bedenken, hoe gemakkelijk is het draagbaar van het ene project of de ene applicatie naar de andere? Dat kan een andere uitdaging zijn.
Automatisering is belangrijk en het is ook een uitdaging. Het is duur om referentiegegevens handmatig te verwerken. Het is duur om handmatig in kaart te moeten blijven brengen en het is duur om materiedeskundigen te laten stoppen met hun dagelijkse taken en moeten gaan en constant data-woordenboeken repareren en definities opnieuw bijwerken, enzovoort, enzovoort. Repliceerbare vocabulaires tonen echt veel waarde. Dus dat zijn vaak woordenschat die je extern van je organisatie kunt vinden. Als u bijvoorbeeld in ruwe olie werkt, zijn er bepaalde soorten vocabulaires die u kunt lenen uit open-source ruimtes, hetzelfde met geneesmiddelen, hetzelfde met de banksector en financieel, hetzelfde met veel van dit soort gebieden. Mensen zetten herbruikbare, generieke, repliceerbare vocabulaires die mensen kunnen gebruiken.
En nogmaals, kijkend naar de IDERA-tool, ben ik benieuwd hoe ze hiermee omgaan in termen van het gebruik van soorten standaarden. In de semantiekwereld zie je vaak dingen zoals SKOS-modellen die normen bieden voor op zijn minst breder dan / smaller dan relaties en die dingen kunnen moeilijk zijn om te doen in ER-modellen, maar weet je, niet onmogelijk, het hangt er maar vanaf hoeveel machines en die koppeling die u in dat soort systemen aankan.
Dus ten slotte wilde ik gewoon een soort vergelijking maken met sommige semantische motoren die ik in de industrie zie, en Ron een beetje vragen en hem een beetje primeren om te praten over misschien hoe het systeem van IDERA is gebruikt in combinatie met semantische technologieën. Is het in staat om te worden geïntegreerd met driedubbele winkels, grafische databases? Hoe gemakkelijk is het om externe bronnen te gebruiken, omdat dat soort dingen in de semantische wereld vaak kunnen worden geleend met behulp van SPARQL Endpoints? U kunt RDF- of OWL-modellen rechtstreeks in uw model importeren - verwijs ernaar terug - dus bijvoorbeeld de genontologie of de eiwitontologie, die ergens in zijn eigen ruimte kan leven met zijn eigen bestuursstructuur en ik kan eenvoudig alles importeren of een deel daarvan omdat ik het nodig heb in mijn eigen modellen. En ik ben benieuwd hoe IDERA dit probleem aanpakt. Moet je alles intern onderhouden, of zijn er manieren om andere soorten gestandaardiseerde modellen te gebruiken en in te trekken en hoe werkt dat? En het laatste wat ik hier noemde, is hoeveel handmatig werk er echt bij betrokken is om de glossaria en de metagegevensrepository's te bouwen?
Dus ik weet dat Ron ons enkele demo's gaat tonen over dit soort dingen die echt interessant zullen zijn. Maar het probleem dat ik vaak met klanten zie, is dat er veel fouten optreden als mensen in hun eigen definities of eigen metadata schrijven. Dus je krijgt spelfouten, je krijgt vingerfouten, dat is één ding. Je krijgt ook mensen die iets kunnen nemen van, weet je, alleen Wikipedia of een bron die niet noodzakelijkerwijs van de kwaliteit is die je in je definitie wilt, of je definitie is alleen vanuit het perspectief van één persoon, dus het is niet compleet, en het is niet duidelijk dan hoe het governanceproces werkt. Governance is natuurlijk een heel, heel groot probleem wanneer je het hebt over referentiegegevens en wanneer je het hebt over hoe dit kan passen in iemands stamgegevens, hoe ze hun metadata gaan gebruiken, en spoedig.
Dus ik wilde gewoon enkele van deze onderwerpen daarbuiten plaatsen. Dit zijn items die ik in de bedrijfsruimte zie in veel verschillende soorten adviesopdrachten en veel verschillende ruimtes, en ik ben echt geïnteresseerd om te zien wat Ron ons gaat tonen met IDERA om enkele van deze onderwerpen aan te wijzen . Dus heel erg bedankt.
Rebecca Jozwiak: Heel erg bedankt Eric, en ik vind je opmerking erg leuk dat er veel fouten kunnen optreden als mensen hun eigen definities of metagegevens schrijven. Ik weet dat er in de journalistieke wereld een mantra is dat 'veel ogen weinig fouten maken', maar als het op praktische toepassingen aankomt, hebben teveel handen in de koekjestrommel de neiging om je met veel gebroken koekjes achter te laten, toch?
Eric Little: Ja, en ziektekiemen.
Rebecca Jozwiak: Ja. Daarmee ga ik door en geef het door aan Malcolm Chisholm. Malcolm, de vloer is van jou.
Malcolm Chisholm: Heel erg bedankt, Rebecca. Ik wil graag een beetje kijken naar waar Eric het over heeft gehad, en toevoegen aan een soort van observaties waarop, weet je, Ron misschien ook zou willen reageren door te praten over "Op weg naar bedrijfsgestuurde gegevensarchitectuur ”- wat betekent het om business driven te zijn en waarom is dat belangrijk? Of is het gewoon een vorm van hype? Ik denk het niet.
Als we kijken naar wat er sindsdien aan de hand is, weet je, mainframecomputers werden echt beschikbaar voor bedrijven - laten we zeggen rond 1964 - tot vandaag kunnen we zien dat er veel veranderingen zijn geweest. En deze veranderingen zou ik samenvatten als een verschuiving van procesgerichtheid naar gegevensgerichtheid. En dat maakt business-driven data-architecturen zo belangrijk en zo relevant voor vandaag. En ik denk, weet je, het is niet alleen een modewoord, het is iets dat absoluut echt is.
Maar we kunnen het een beetje meer waarderen als we de geschiedenis induiken, dus terug in de tijd, ver terug naar de jaren 1960 en enige tijd daarna domineerden mainframes. Deze maakten vervolgens plaats voor pc's waar je eigenlijk rebellie van de gebruikers had toen pc's binnenkwamen. Rebellie tegen gecentraliseerde IT, waarvan ze dachten dat ze niet aan hun behoeften voldeden, was niet behendig genoeg. Dat leidde al snel tot gedistribueerde computing, toen pc's aan elkaar werden gekoppeld. En toen begon het internet te gebeuren, waardoor de grenzen van de onderneming vervaagden - het kon nu communiceren met partijen buiten zichzelf op het gebied van gegevensuitwisseling, wat nog niet eerder was gebeurd. En nu zijn we het tijdperk van cloud en big data ingegaan waar de cloud platforms zijn die echt infrastructuur commoditiseren en dus laten we als het ware de IT weg van de noodzaak om big datacenters te runnen omdat, weet je, we Ik heb de cloudcapaciteit tot onze beschikking, en tegelijk met die big data waarover Eric zo welsprekend heeft gesproken. En over het algemeen, zoals we zien, is de verschuiving in technologie meer gegevensgericht geworden, we geven meer om gegevens. Net als bij internet, hoe gegevens worden uitgewisseld. Met big data, de vier of meer v's van de data zelf.
Tegelijkertijd, en misschien nog belangrijker, veranderde het gebruik van bedrijven. Toen computers voor het eerst werden geïntroduceerd, werden ze gebruikt om dingen zoals boeken en records te automatiseren. En alles dat een handmatig proces was, waarbij grootboeken of dergelijke betrokken waren, was in wezen in huis geprogrammeerd. Dat verschoof in de jaren 80 naar de beschikbaarheid van operationele pakketten. Je hoefde niet langer je eigen loonlijst te schrijven, je kon iets kopen dat het deed. Dat resulteerde destijds in een grote inkrimping of herstructurering in veel IT-afdelingen. Maar toen verscheen business intelligence, met dingen als datawarehouses, meestal in de jaren 90. Gevolgd door dotcom-bedrijfsmodellen die natuurlijk een grote razernij waren. Dan MDM. Met MDM begin je te zien dat we niet aan automatisering denken; we richten ons eigenlijk alleen op het cureren van data als data. En dan analyses, die de waarde vertegenwoordigen die u uit de gegevens kunt halen. En binnen de analyse ziet u bedrijven die zeer succesvol zijn en hun kernbedrijfsmodel draait om gegevens. Google, Twitter, Facebook zouden daar deel van uitmaken, maar je zou ook kunnen beweren dat Walmart dat is.
En dus denkt het bedrijf nu echt aan gegevens. Hoe kunnen we waarde uit data halen? Hoe data het bedrijf, de strategie en ons kunnen sturen in de gouden eeuw van data. Dus wat gebeurt er op het gebied van onze gegevensarchitectuur, als gegevens niet langer worden beschouwd als louter de uitlaatgassen die uit de back-end van applicaties komen, maar echt centraal staan in onze bedrijfsmodellen? Nou, een deel van het probleem dat we hebben om dat te bereiken, is dat IT echt vastzit in het verleden met de levenscyclus van systeemontwikkeling die een gevolg was van het snel moeten omgaan met die procesautomatiseringsfase in de vroege leeftijd van IT, en het werken in projecten is iets soortgelijks. Voor IT - en dit is een beetje een karikatuur - maar wat ik probeer te zeggen is dat sommige van de obstakels voor het krijgen van een bedrijfsgestuurde gegevensarchitectuur zijn omdat we een soort IT-cultuur als het ware kritiekloos hebben geaccepteerd die voortkomt uit een voorbije leeftijd.
Dus alles is een project. Vertel me je vereisten in detail. Als dingen niet werken, is het omdat je me je vereisten niet hebt verteld. Nou, dat werkt vandaag niet met gegevens, omdat we niet beginnen met niet-geautomatiseerde handmatige processen of, weet u, een technische conversie van bedrijfsprocessen, we beginnen heel vaak met reeds bestaande productiegegevens die we proberen om waarde uit te halen. Maar niemand die een gegevensgericht project sponsort, begrijpt die gegevens echt diepgaand. We moeten data ontdekken, we moeten brongegevens analyseren. En dat komt niet echt overeen met de systeemontwikkeling, weet je - waterval, SDLC-levenscyclus - waarvan Agile, zo zou ik beweren, een soort betere versie daarvan is.
En waar het om gaat is technologie en functionaliteit, geen gegevens. Als we bijvoorbeeld in een testfase testen, werkt mijn functionaliteit meestal, laten we zeggen mijn ETL, maar we testen de gegevens niet. We testen onze aannames over de binnenkomende brongegevens niet. Als we dat zouden doen, zouden we er misschien beter aan toe zijn en als iemand die datawarehouse-projecten heeft gedaan en last heeft gehad van upstream-veranderingen, mijn ETL's kapot, zou ik dat waarderen. En eigenlijk willen we testen als een eerste stap naar continue monitoring van de kwaliteit van productiegegevens. Dus we hebben hier veel houdingen waar het moeilijk is om de bedrijfsgestuurde gegevensarchitectuur te bereiken, omdat we worden bepaald door het tijdperk van procesgerichtheid. We moeten de overstap maken naar gegevensgerichtheid. En dit is geen totale overgang, weet je, er is nog steeds veel proceswerk te doen, maar we denken niet echt in data-centrische termen wanneer dat nodig is, en de omstandigheden die zich voordoen wanneer we echt verplicht om dat te doen.
Nu beseft het bedrijf de waarde van de gegevens, ze willen de gegevens ontgrendelen, dus hoe gaan we dat doen? Dus hoe doen we de overgang? Nou, we plaatsen data centraal in ontwikkelingsprocessen. En we laten het bedrijf leiden met informatie-eisen. En we begrijpen dat niemand de bestaande brongegevens aan het begin van het project begrijpt. Je zou kunnen beweren dat de datastructuur en de data zelf daar zijn aangekomen via respectievelijk IT en operaties, dus dat moeten we weten, maar echt niet. Dit is gegevensgerichte ontwikkeling. Dus we moeten, bij het nadenken over waar we zijn en hoe we datamodellering doen in een datacentrische wereld, moeten we feedbacklussen naar de gebruikers hebben in termen van het verfijnen van hun informatie-eisen, zoals we data-ontdekking en data-profilering doen, voorzien van analyse van brongegevens en naarmate we geleidelijk meer en meer zekerheid krijgen over onze gegevens. En nu heb ik het over een meer traditioneel project zoals een MDM-hub of een datawarehouse, niet noodzakelijkerwijs de big data-projecten, hoewel dit nog steeds redelijk dicht in de buurt blijft. En dus omvatten die feedbacklussen de datamodelers, weet je, geleidelijk hun datamodel voortschrijdend en interactie met de gebruikers om ervoor te zorgen dat de informatie-eisen worden verfijnd op basis van wat mogelijk is, wat beschikbaar is, van de brongegevens zoals ze het beter begrijpen, dus het is geen geval meer van het datamodel dat, weet je, in een staat die er niet is of helemaal klaar is, het geleidelijk aan onder de aandacht wordt gebracht.
Evenzo, meer stroomafwaarts daarvan, hebben we kwaliteitsborging waar we regels ontwikkelen voor het testen van gegevenskwaliteit om ervoor te zorgen dat de gegevens binnen de parameters vallen waarover we aannames doen. Toen hij binnenkwam, verwees Eric naar veranderingen in referentiegegevens, die kunnen gebeuren. U wilt als het ware geen downstream-slachtoffer zijn van een soort van onbeheerde verandering op dat gebied, dus de regels voor kwaliteitsborging kunnen worden gebruikt voor post-productie, continue monitoring van de gegevenskwaliteit. U kunt dus beginnen te kijken of we gegevensgericht zijn, hoe we gegevensgerichte ontwikkeling doen, is heel anders dan de op functionaliteit gebaseerde SDLC en Agile. En dan moeten we ook aandacht schenken aan zakelijke opvattingen. We hebben - en dit is ook een echo van wat Eric zei - we hebben een datamodel dat een blauwdruk voor een gegevensverhaal definieert voor onze database, maar tegelijkertijd hebben we die conceptuele modellen nodig, die zakelijke weergaven van gegevens die traditioneel niet zijn gedaan in het verleden. We hebben soms, denk ik, gedacht dat het datamodel het allemaal kan, maar we moeten de conceptuele weergave, de semantiek, en de gegevens bekijken, door een abstractielaag weergeven die het opslagmodel naar het bedrijf vertaalt visie. En nogmaals, alle dingen waar Eric het over had in termen van de semantiek, worden daarvoor belangrijk, dus we hebben eigenlijk extra modelleringstaken. Ik denk dat dat, weet je, interessant is als je in de gelederen bent gekomen als een datamodeler zoals ik, en nogmaals, iets nieuws.
En tot slot wil ik zeggen dat de grotere architectuur ook deze nieuwe realiteit moet weerspiegelen. Traditionele MDM voor klanten, bijvoorbeeld, is een soort van, oké, laten we onze klantgegevens in een hub brengen waar we, u weet wel, er zin aan kunnen geven in termen van echt alleen datakwaliteit voor backoffice-applicaties. Wat vanuit het oogpunt van een bedrijfsstrategie een beetje een geeuw is. Vandaag kijken we echter naar MDM-hubs van klanten met aanvullende klantprofielgegevens, niet alleen de statische gegevens, die dan echt een bidirectionele interface hebben met transactietoepassingen van de klant. Ja, ze ondersteunen nog steeds de backoffice, maar nu zijn we ook op de hoogte van dit gedrag van onze klanten. Dit is duurder om te bouwen. Dit is complexer om te bouwen. Maar het is zakelijk gestuurd op een manier waarop de traditionele MDM-klant dat niet is. U ruilt een oriëntatie op het bedrijf in tegen eenvoudigere ontwerpen die eenvoudiger te implementeren zijn, maar voor het bedrijf willen ze dit zien. We zitten echt in een nieuw tijdperk en ik denk dat er een aantal niveaus is waarop we moeten reageren op de zakelijke gegevensarchitectuur en ik vind het een heel spannende tijd om dingen te doen.
Dus bedankt, terug naar jou Rebecca.
Rebecca Jozwiak: Bedankt Malcolm, en ik heb echt genoten van wat je zei over datamodellen die de bedrijfsvisie moeten voeden, omdat, in tegenstelling tot wat je zei, IT zo lang de leiding had en het is gewoon niet meer dat geval en dat de cultuur moet verschuiven. En ik ben er vrij zeker van dat er een hond op de achtergrond was die het 100% met je eens was. En daarmee ga ik de bal doorgeven aan Ron. Ik ben erg enthousiast om je demo te zien. Ron, de vloer is van jou.
Ron Huizenga: Heel erg bedankt en voordat we daarop ingaan, zal ik een paar dia's doornemen en dan een beetje demo omdat, zoals Eric en Malcolm hebben opgemerkt, dit een zeer breed en diep onderwerp is, en met waar we het vandaag over hebben, schrapen we gewoon de oppervlakte ervan, omdat er zoveel aspecten en zoveel dingen zijn die we echt moeten overwegen en bekijken vanuit een bedrijfsgestuurde architectuur. En onze aanpak is om dat model echt te maken en echte waarde aan de modellen te ontlenen omdat u ze kunt gebruiken als communicatievoertuig en als een laag om andere systemen mogelijk te maken. Of u nu servicegeoriënteerde architectuur of andere dingen doet, het model wordt echt de levensader van wat er gaande is, met alle metagegevens eromheen en de gegevens die u in uw bedrijf hebt.
Waar ik het echter over wil hebben, is dit bijna een stap terug doen, omdat Malcolm een deel van de geschiedenis van de manier waarop oplossingen zijn geëvolueerd en dat soort dingen had aangeroerd. Een manier om echt aan te geven hoe belangrijk het is om een goede gegevensarchitectuur te hebben, is een use case die ik heel vaak tegenkwam toen ik aan het overleg was voordat ik in een productmanagementrol kwam, en dat was, ik zou in organisaties gaan of ze nu bezig waren met bedrijfstransformatie of slechts enkele bestaande systemen en dat soort dingen vervangen, en het werd al snel duidelijk hoe slecht organisaties hun eigen gegevens begrijpen. Als je een specifieke use case als deze gebruikt, of je nu een consultant bezoekt of misschien is het een persoon die net is begonnen met een organisatie, of je organisatie is door de jaren heen opgebouwd met het overnemen van verschillende bedrijven, wat je eindigt omhoog met is een zeer complexe omgeving zeer snel, met een aantal nieuwe verschillende technologieën, evenals legacy-technologie, ERP-oplossingen en al het andere.
Dus een van de dingen die we echt kunnen doen met onze modelleringsbenadering is de vraag te beantwoorden, hoe begrijp ik dit allemaal? We kunnen echt beginnen met het samenvoegen van de informatie, zodat het bedrijf de informatie waarover we beschikken, optimaal kan benutten. En het komt erop neer, wat hebben we daar in die omgevingen? Hoe kan ik de modellen gebruiken om de informatie die ik nodig heb te verdrijven en die informatie beter te begrijpen? En dan hebben we de traditionele soorten metagegevens voor alle verschillende dingen, zoals de relationele gegevensmodellen, en we zijn gewend om dingen te zien zoals definities en gegevenswoordenboeken, weet u, gegevenstypen en dat soort dingen. Maar hoe zit het met extra metadata die je wilt vastleggen om er echt nog meer betekenis aan te geven? Zoals welke entiteiten eigenlijk de kandidaten zijn die referentiegegevensobjecten moeten zijn, die hoofdgegevensbeheerobjecten en dat soort dingen moeten zijn en ze aan elkaar moeten koppelen. En hoe stroomt de informatie door de organisatie? Gegevens vloeien voort uit hoe ze worden verbruikt, zowel vanuit een procesperspectief, maar ook datalijn in termen van de reis van informatie door onze bedrijven en hoe het zijn weg vindt door de verschillende systemen, of door de gegevensopslag, dus we weten wanneer we de I-oplossingen, of dat soort dingen, bouwen dat we feitelijk de juiste informatie consumeren voor de taak die moet worden uitgevoerd.
En dan is het heel belangrijk, hoe kunnen we al die stakeholders laten samenwerken, en met name de zakelijke stakeholders, want zij zijn degenen die ons de ware betekenis geven van wat die gegevens zijn. Het bedrijf is uiteindelijk de eigenaar van de gegevens. Ze geven de definities voor de vocabulaires en dingen waar Eric het over had, dus we hebben een plek nodig om dat allemaal samen te voegen. En de manier waarop we dat doen, is via onze datamodellering en data repository-architecturen.
Ik ga een paar dingen bespreken. Ik ga het hebben over ER / Studio Enterprise Team Edition. Ik ga het in de eerste plaats hebben over het data-architectuurproduct waar we datamodellering en dat soort dingen doen, maar er zijn veel andere componenten van de suite die ik maar heel kort zal bespreken. U ziet een fragment van de Business Architect, waar we conceptuele modellen kunnen maken, maar we kunnen ook bedrijfsprocesmodellen maken en we kunnen die procesmodellen koppelen om de feitelijke gegevens die we in onze gegevensmodellen hebben te koppelen. Het helpt ons echt om die band samen te brengen. Met Software Architect kunnen we aanvullende constructies uitvoeren, zoals sommige UML-modellering en dat soort dingen om ondersteunende logica te geven aan sommige van die andere systemen en processen waar we het over hebben. Maar heel belangrijk als we naar beneden gaan, hebben we de repository en de teamserver, en ik zal daarover praten als een soort twee helften van hetzelfde. De repository is waar we alle gemodelleerde metadata opslaan, evenals alle zakelijke metadata in termen van de business glossaria en termen. En omdat we deze op repository gebaseerde omgeving hebben, kunnen we dan al deze verschillende dingen in diezelfde omgeving samenvoegen en dan kunnen we die daadwerkelijk beschikbaar stellen voor consumpties, niet alleen voor de technische mensen, maar ook voor de ondernemers. En zo beginnen we echt de samenwerking te stimuleren.
En dan is het laatste stuk waar ik het kort over zal hebben, wanneer je deze omgevingen binnenloopt, het niet alleen databases zijn die je hebt. Je gaat een aantal databases hebben, datastores, je zult ook veel, wat ik zou noemen, oude artefacten hebben. Misschien hebben mensen Visio of andere diagrammen gebruikt om sommige dingen in kaart te brengen. Misschien hebben ze andere modelleringstools en dat soort dingen gehad. Dus wat we met de MetaWizard kunnen doen, is eigenlijk een deel van die informatie extraheren en in onze modellen opnemen, actueel maken en in staat zijn om het opnieuw te gebruiken, op een actuele manier, in plaats van het gewoon daar te laten zitten. Het wordt nu een actief onderdeel van onze werkmodellen, wat erg belangrijk is.
Als je een organisatie binnenkomt, zoals ik al zei, zijn er veel ongelijksoortige systemen, veel ERP-oplossingen, niet-overeenkomende afdelingsoplossingen. Veel organisaties gebruiken ook SaaS-oplossingen, die ook extern worden beheerd en beheerd, dus we hebben geen controle over de databases en dat soort dingen in hosts op die, maar we moeten nog steeds weten hoe die gegevens eruit zien en, natuurlijk, de metadata daaromheen. Wat we ook vinden, zijn veel verouderde oudere systemen die niet zijn opgeruimd vanwege die projectmatige aanpak waarover Malcolm had gesproken. Het is verbazingwekkend hoe organisaties in de afgelopen jaren projecten zullen opdrijven, ze een systeem of een oplossing zullen vervangen, maar er is vaak niet genoeg projectbudget over om de verouderde oplossingen buiten gebruik te stellen, dus nu zitten ze gewoon in de weg. En we moeten uitzoeken wat we in onze omgeving eigenlijk kwijt kunnen raken, en wat nuttig is in de toekomst. En dat past in de slechte ontmantelingsstrategie. Dat hoort bij datzelfde.
Wat we ook vinden, omdat veel organisaties zijn opgebouwd uit al deze verschillende oplossingen, is dat we veel point-to-point-interfaces zien met veel gegevens die op een aantal plaatsen rondlopen. We moeten in staat zijn om dat te rationaliseren en dat datalijn uit te zoeken dat ik eerder heb genoemd, zodat we een meer samenhangende strategie kunnen hebben, zoals het gebruik van servicegeoriënteerde architectuur, enterprise service bussen en dat soort dingen, om de juiste informatie te leveren naar een model voor publiceren en abonneren dat we correct gebruiken in ons hele bedrijf. En dan moeten we natuurlijk nog steeds een soort analyse uitvoeren, of we nu datawarehouses, datamarts met traditionele ETL gebruiken of enkele van de nieuwe datameren gebruiken. Het komt allemaal op hetzelfde neer. Het is allemaal data, of het nu big data is, of het traditionele data zijn in relationele databases, we moeten al die data samenbrengen zodat we het kunnen beheren en weten waar we in onze modellen mee te maken hebben.
Nogmaals, de complexiteit die we gaan doen, is dat we een aantal stappen hebben die we willen kunnen doen. Allereerst loop je binnen en heb je misschien niet die blauwdrukken van hoe dat informatielandschap eruit ziet. In een datamodelleringstool zoals ER / Studio Data Architect ga je eerst veel reverse-engineering doen, laten we wijzen op de gegevensbronnen die er zijn, ze binnenbrengen en ze vervolgens samenvoegen tot een meer representatieve modellen die het hele bedrijf vertegenwoordigen. Het belangrijkste is dat we die modellen ook langs bedrijfslijnen willen kunnen ontleden, zodat we ons ermee kunnen verbinden in kleinere brokken, waar onze zakenmensen ook mee kunnen omgaan, en onze bedrijfsanalisten en andere belanghebbenden die werken ben ermee bezig.
Naamgevingsnormen zijn uiterst belangrijk en ik heb het hier op verschillende manieren over. Naamgevingsstandaarden in termen van hoe we dingen in onze modellen noemen. Het is vrij eenvoudig om te doen in logische modellen, waar we een goede naamgevingsconventie en een goed gegevenswoordenboek voor onze modellen hebben, maar dan zien we ook verschillende naamgevingsconventies voor veel van deze fysieke modellen die we introduceren. Wanneer we reverse engineer, vaak zien we afgekorte namen en dat soort dingen waar ik het over zal hebben. En we moeten die terug vertalen in betekenisvolle Engelse namen die betekenisvol zijn voor het bedrijf, zodat we kunnen begrijpen wat al deze gegevens in de omgeving zijn. En dan maken universele toewijzingen hoe we ze aan elkaar naaien.
Bovendien zouden we vervolgens documenteren en verder definiëren en dat is waar we onze gegevens verder kunnen classificeren met iets dat bijlagen wordt genoemd, waar ik u enkele dia's op laat zien. En dan de cirkel te sluiten, willen we die zakelijke betekenis toepassen, dat is waar we onze zakelijke woordenlijsten verbinden en ze kunnen koppelen aan onze verschillende modelartefacten, dus we weten, wanneer we het hebben over een bepaalde zakelijke term, waar dat is geïmplementeerd in onze gegevens door de hele organisatie. En tot slot heb ik het al gehad over het feit dat we dit allemaal nodig hebben om op een repository te zijn gebaseerd met veel samenwerkings- en publicatiemogelijkheden, zodat onze stakeholders het kunnen gebruiken. Ik ga vrij snel praten over reverse engineering. Ik heb je daar al een heel snel hoogtepunt van gegeven. Ik zal je dat in een echte demo laten zien, alleen om je enkele dingen te laten zien die we daar kunnen brengen.
En ik wil het hebben over enkele van de verschillende modeltypen en diagrammen die we in dit soort scenario's zouden produceren. Uiteraard doen we de conceptuele modellen in veel gevallen; Ik ga daar niet veel tijd aan besteden. Ik wil echt praten over logische modellen, fysieke modellen en de gespecialiseerde soorten modellen die we kunnen maken. En het is belangrijk dat we deze allemaal op hetzelfde platform kunnen maken, zodat we ze aan elkaar kunnen naaien. Dat omvat dimensionale modellen en ook modellen die enkele van de nieuwe gegevensbronnen gebruiken, zoals de NoSQL die ik je zal laten zien. En hoe ziet het datalijnmodel eruit? En hoe gaan we die gegevens in een bedrijfsprocesmodel steken, daar zullen we het nu over hebben.
Ik ga hier overschakelen naar een modelomgeving om je een zeer hoog en snel overzicht te geven. En ik geloof dat je nu mijn scherm zou moeten kunnen zien. Allereerst wil ik het hebben over alleen een traditioneel type datamodel. En de manier waarop we de modellen willen organiseren wanneer we ze binnenbrengen, is dat we ze willen kunnen ontleden. Dus wat u hier aan de linkerkant ziet, is dat we logische en fysieke modellen in dit specifieke modelbestand hebben. Het volgende is dat we het kunnen opsplitsen langs de zakelijke ontleding, dus daarom zie je de mappen. De lichtblauwe zijn logische modellen en de groene zijn fysieke modellen. En we kunnen ook dieper ingaan, dus binnen ER / Studio kunt u, als u een zakelijke ontleding hebt, zoveel niveaus diep of submodellen gaan als u wilt, en wijzigingen die u op de lagere niveaus aanbrengt, weerspiegelen automatisch op de hogere levels. Het wordt dus zeer snel een zeer krachtige modelomgeving.
Iets waarop ik ook wil wijzen dat erg belangrijk is om deze informatie samen te brengen, is dat we meerdere fysieke modellen kunnen hebben die ook overeenkomen met één logisch model. Heel vaak heb je een logisch model, maar je hebt misschien fysieke modellen op verschillende platforms en dat soort dingen. Misschien is iemand een SQL Server-exemplaar ervan, misschien is iemand anders een Oracle-exemplaar. We kunnen dat allemaal samenbrengen in dezelfde modelomgeving. En nogmaals, wat ik hier heb, is een echt datawarehouse-model dat, opnieuw, in dezelfde modelleringsomgeving kan zijn of we kunnen het in de repository hebben en het ook aan verschillende dingen koppelen.
Wat ik je hier echt wilde laten zien, zijn enkele andere dingen en andere varianten van de modellen waar we op ingaan. Dus als we in een traditioneel datamodel komen, zijn we gewend om de typische entiteiten met de kolommen en de metadata en dat soort dingen te zien, maar dat gezichtspunt varieert heel snel wanneer we beginnen met enkele van deze nieuwere NoSQL-technologieën, of zoals sommige mensen ze nog steeds graag noemen, de big data-technologieën.
Laten we nu zeggen dat we ook Hive in onze omgeving hebben. Als we reverse engineer vanuit een Hive-omgeving - en we kunnen forward en reverse engineer vanuit Hive met precies dezelfde modelleringstool - zien we iets dat een beetje anders is. We zien nog steeds alle gegevens als constructies daar, maar onze TDL is anders. Degenen onder u die gewend zijn om SQL te zien, wat u nu zou zien is Hive QL, dat erg SQL-achtig is, maar vanuit hetzelfde hulpprogramma kunt u nu beginnen met het werken met de verschillende scripttalen. Je kunt dus in deze omgeving modelleren, het genereren in de Hive-omgeving, maar net zo belangrijk, in het scenario dat ik heb beschreven, kun je het allemaal reverse-engineeren en begrijpen en beginnen met het ook samenvoegen .
Laten we er nog een nemen die een beetje anders is. MongoDB is een ander platform dat we native ondersteunen. En wanneer u de JSON-omgevingen begint waar u documentopslag hebt, is JSON een ander dier en zitten er constructies in die niet overeenkomen met relationele modellen. Je begint al snel te werken met concepten zoals ingebedde objecten en ingebedde arrays van objecten wanneer je de JSON begint te ondervragen en die concepten bestaan niet in de traditionele relationele notatie. Wat we hier hebben gedaan, is dat we de notatie en onze catalogus hebben uitgebreid om dat in dezelfde omgeving aan te kunnen.
Als je hier links kijkt, in plaats van dingen als entiteiten en tabellen te zien, noemen we ze objecten. En je ziet verschillende notaties. Je ziet hier nog steeds de typische soorten referentienotaties, maar deze blauwe entiteiten die ik in dit specifieke diagram laat zien, zijn eigenlijk ingebedde objecten. En we tonen verschillende kardinaliteiten. De diamanten kardinaliteit betekent dat het een object aan de ene kant is, maar de kardinaliteit van een betekent dat we binnen de uitgever een ingesloten adresobject hebben als we die relatie volgen. Bij het ondervragen van de JSON hebben we ontdekt dat het exact dezelfde structuur van objecten is die is ingebed in de gebruiker, maar die eigenlijk is ingebed als een reeks objecten. We zien dat, niet alleen via de connectoren zelf, maar als je naar de werkelijke entiteiten kijkt, zie je dat je adressen onder beschermheer ziet die het ook als een reeks objecten hebben geclassificeerd. Je krijgt een heel beschrijvend beeld van hoe je dat kunt binnenbrengen.
En nogmaals, wat we tot nu toe in slechts enkele seconden hebben gezien, zijn traditionele relationele modellen met meerdere niveaus, we kunnen hetzelfde doen met Hive, we kunnen hetzelfde doen met MongoDB en andere grote gegevensbronnen als goed. Wat we ook kunnen doen, en ik ga je dit heel snel laten zien, was dat ik het had over het brengen van dingen uit andere verschillende gebieden. Ik ga ervan uit dat ik een model uit een database ga importeren of reverse-engineeren, maar ik ga het uit externe metadata halen. Om je een snel overzicht te geven van alle verschillende soorten dingen die we kunnen beginnen aan te brengen.
Zoals u ziet, hebben we een groot aantal dingen waarmee we de metadata daadwerkelijk in onze modelleeromgeving kunnen brengen. Beginnend met dingen zoals zelfs Amazon Redshift, Cassandra, veel van de andere big data-platforms, dus je ziet veel van deze vermeld. Dit is in alfabetische volgorde. We zien veel big data-bronnen en dat soort dingen. We zien ook veel traditionele of oudere modelleringsomgevingen waar we die metadata daadwerkelijk door kunnen brengen. Als ik hier doorga - en ik ga er geen tijd aan besteden - zien we veel verschillende dingen waar we het uit kunnen halen, in termen van modelleringsplatforms en dataplatforms. En iets dat hier heel belangrijk is om te realiseren, is een ander onderdeel dat we kunnen doen als we over gegevensgesprek beginnen te praten, in de Enterprise Team Edition kunnen we ook ETL-bronnen ondervragen, of het nu dingen zijn als toewijzingen van Talend of SQL Server Information Services, we kunnen breng dat eigenlijk binnen om ook onze datalijndiagrammen te starten en een beeld te krijgen van wat er in die transformaties gebeurt. Al met al hebben we meer dan 130 van deze verschillende bruggen die eigenlijk deel uitmaken van het Enterprise Team Edition-product, dus het helpt ons echt om alle artefacten heel snel in één modelomgeving samen te brengen.
Last but not least wil ik het ook hebben over het feit dat we het feit dat we andere constructies nodig hebben niet uit het oog mogen verliezen als we data warehousing of enige vorm van analyse uitvoeren. We willen nog steeds de mogelijkheid hebben om dingen te doen zoals dimensionale modellen waar we feitentabellen hebben en we hebben dimensies en dat soort dingen. Een ding dat ik je ook wil laten zien, is dat we ook uitbreidingen van onze metadata kunnen hebben die ons helpen te categoriseren wat de soorten dimensies zijn en al het andere. Dus als ik hier naar het tabblad met dimensionale gegevens kijk, bijvoorbeeld, op een van deze, zal het eigenlijk automatisch detecteren, op basis van het modelpatroon dat het ziet, en je een beginpunt geven of het denkt dat het een dimensie of een feitentabel. Maar verder, wat we kunnen doen, is binnen de dimensies en dat soort dingen hebben we zelfs verschillende soorten dimensies die we kunnen gebruiken om de gegevens ook in een omgeving voor datawarehousing te classificeren. Dus zeer krachtige mogelijkheden waar we dit helemaal mee aan het borduren zijn.
Ik ga hier in springen omdat ik nu in de demo-omgeving ben en je een paar andere dingen laten zien voordat ik terug naar de dia's spring. Een van de dingen die we onlangs aan ER / Studio Data Architect hebben toegevoegd, is dat we situaties tegenkomen - en dit is een veel voorkomende use case wanneer u aan projecten werkt - ontwikkelaars denken in termen van objecten, terwijl onze gegevens Modelers hebben de neiging om te denken in termen van tabellen en entiteiten en dat soort dingen. Dit is een zeer simplistisch datamodel, maar het vertegenwoordigt een paar basisconcepten, waar de ontwikkelaars of zelfs bedrijfsanalisten of bedrijfsgebruikers ze als verschillende objecten of bedrijfsconcepten kunnen beschouwen. Het was tot nu toe heel moeilijk om deze te classificeren, maar wat we eigenlijk hebben gedaan in ER / Studio Enterprise Team Edition, in de release van 2016, is dat we nu een concept hebben met de naam Business Data Objects. En wat ons in staat stelt te doen, is dat het ons mogelijk maakt om groepen entiteiten of tabellen in echte bedrijfsobjecten in te sluiten.
Wat we hier in deze nieuwe weergave hebben, is bijvoorbeeld de kop van de inkooporder en de orderregel zijn nu samengevoegd, ze zijn ingekapseld als een object, we zouden ze als een eenheid van werk beschouwen als we de gegevens bewaren, en we brengen ze samen, zodat het nu heel gemakkelijk is om dat aan verschillende doelgroepen te relateren. Ze zijn herbruikbaar in de modelleeromgeving. Ze zijn een echt object, niet alleen een tekenconstructie, maar we hebben ook het extra voordeel dat wanneer we daadwerkelijk communiceren vanuit modelleringperspectief, we ze selectief kunnen samenvouwen of uitbreiden, zodat we een samenvattend beeld kunnen produceren voor dialogen met bepaalde doelgroepen, en we kunnen natuurlijk ook de meer gedetailleerde weergave behouden die we hier zien voor meer technisch publiek. Het geeft ons echt een heel goed communicatiemiddel. Wat we nu zien is het combineren van meerdere verschillende modeltypen, deze uitbreiden met het concept van zakelijke gegevensobjecten, en nu ga ik het hebben over hoe we eigenlijk wat meer betekenis aan dit soort dingen toevoegen en hoe we ze samenvoegen in onze algemene omgevingen.
Ik probeer gewoon mijn WebEx hier te vinden, zodat ik dat kan doen. En daar gaan we, terug naar de Hot Tech-slides. Ik ga hier gewoon een paar dia's vooruitspoelen omdat je deze al hebt gezien in de modeldemonstratie zelf. Ik wil heel snel praten over naamgevingsnormen. We willen verschillende naamgevingsnormen toepassen en handhaven. Wat we willen doen, is dat we de mogelijkheid hebben om naamgevingsstandaardsjablonen op te slaan in onze repositories om die betekenis in feite op te bouwen door middel van woorden of zinnen of zelfs afkortingen, en ze te koppelen aan een betekenisvolle Engelse woordsoort. We gaan zakelijke termen gebruiken, de afkortingen voor elke, en we kunnen de volgorde, de cases specificeren en voor- en achtervoegsels toevoegen. Het typische gebruik hiervan is meestal wanneer mensen een logisch model hebben gebouwd en vervolgens daadwerkelijk een fysiek model maken waarin ze mogelijk afkortingen en al het andere gebruiken.
Het mooie is dat het net zo krachtig is, nog krachtiger in omgekeerde volgorde, als we gewoon kunnen vertellen wat sommige van die naamgevingsnormen waren in enkele van die fysieke databases die we reverse-engineered hebben, kunnen we die afkortingen nemen, ze langer maken woorden, en breng ze achteruit in Engelse zinnen. We kunnen nu eigenlijk de juiste namen afleiden voor hoe onze gegevens eruit zien. Zoals ik al zei, de typische use case is dat we vooruit gaan, logisch naar fysiek, en de gegevensopslag en dat soort dingen in kaart brengen. Als je de screenshot aan de rechterkant bekijkt, zie je dat er afgekorte namen zijn van de bronnamen en wanneer we een sjabloon voor naamgevingsstandaarden hebben toegepast, hebben we eigenlijk meer volledige namen. En we zouden spaties en dergelijke in kunnen zetten als we dat willen, afhankelijk van de sjabloon voor naamgevingsnormen die we gebruikten. We kunnen het eruit laten zien zoals we het in onze modellen willen zien. Pas als we weten hoe iets wordt genoemd, kunnen we er daadwerkelijk definities aan toevoegen, want tenzij we weten wat het is, hoe kunnen we er een betekenis aan geven?
Het leuke is dat we dit daadwerkelijk kunnen inroepen als we allerlei dingen doen. Ik heb het gehad over reverse engineering, we kunnen feitelijk sjablonen voor naamgevingsnormen tegelijkertijd gebruiken als we reverse engineering doen. Dus in een set stappen via een wizard kunnen we, als we weten wat de conventies zijn, een reverse-engineering van een fysieke database uitvoeren, deze wordt teruggebracht als fysieke modellen in een modelleringsomgeving en het is ook die naamgevingsconventies gaan toepassen. We zullen dus zien wat de Engelsachtige namen van namen zijn in het overeenkomstige logische model in de omgeving. We kunnen het ook doen en combineren met het genereren van XML-schema's, zodat we een model kunnen nemen en het zelfs kunnen uitduwen met onze afkortingen, of we nu SOA-frameworks doen of dat soort dingen, zodat we dan ook verschillende naamgevingsconventies kunnen verwijderen die we eigenlijk in het model zelf hebben opgeslagen. Het geeft ons veel zeer krachtige mogelijkheden.
Nogmaals, hier is een voorbeeld van hoe het eruit zou zien als ik een sjabloon had. Deze laat eigenlijk zien dat ik EMP had voor 'werknemer', SAL voor 'salaris', PLN voor 'plan' in een conventie voor naamgevingsnormen. Ik kan ze ook toepassen om ze interactief te laten werken terwijl ik modellen aan het bouwen ben en dingen erin plaats. Als ik deze afkorting zou gebruiken en ik “Personeelsplan” op de naam van de entiteit zou typen, zou het werken met de sjabloon voor naamgevingsnormen Ik heb hier gedefinieerd, het zou me EMP_SAL_PLN hebben gegeven terwijl ik de entiteiten aan het creëren was en me meteen de bijbehorende fysieke namen zou geven.
Nogmaals, zeer goed voor wanneer we ook ontwerpen en vooruitstrevende engineering. We hebben een zeer uniek concept en dit is waar we echt beginnen om deze omgevingen samen te brengen. En het heet Universal Mappings. Zodra we al deze modellen in onze omgeving hebben gebracht, wat we kunnen doen, ervan uitgaande dat we nu deze naamgevingsconventies hebben toegepast en ze gemakkelijk te vinden zijn, kunnen we nu een construct genaamd Universal Mappings in ER gebruiken /Studio. We kunnen entiteiten aan verschillende modellen koppelen. Waar we 'klant' zien - we hebben waarschijnlijk 'klant' in veel verschillende systemen en veel verschillende databases - we kunnen beginnen deze allemaal aan elkaar te koppelen, zodat wanneer ik ermee in een model werk, ik kan zien waar de manifestaties van klanten in de andere modellen zijn. En omdat we de modellaag hebben die dat weergeeft, kunnen we het zelfs koppelen aan gegevensbronnen en terugbrengen naar onze waar gebruikte onderzoeken in welke databases deze zich ook bevinden. Het geeft ons echt de mogelijkheid om dit allemaal heel samenhangend samen te binden.
Ik heb je de zakelijke gegevensobjecten laten zien. Ik wil ook heel snel praten over de metadata-extensies, die we Bijlagen noemen. Wat dat doet, is dat het ons de mogelijkheid biedt om extra metagegevens voor onze modelobjecten te maken. Heel vaak zou ik dit soort eigenschappen instellen om veel verschillende dingen te verdrijven vanuit een perspectief van gegevensbeheer en gegevenskwaliteit, en ook om ons te helpen met hoofdgegevensbeheer en gegevensbewaarbeleid. Het basisidee is dat u deze classificaties maakt en dat u ze overal kunt koppelen, op tabelniveau, kolomniveau, dat soort dingen. Het meest gebruikelijke gebruik is natuurlijk dat entiteiten tabellen zijn en dat ik vervolgens kan definiëren: wat zijn mijn stamgegevensobjecten, wat zijn mijn referentietabellen, wat zijn mijn transactietabellen? Vanuit het oogpunt van gegevenskwaliteit kan ik classificaties doen in termen van belang voor het bedrijf, zodat we prioriteit kunnen geven aan inspanningen voor het opschonen van gegevens en dat soort dingen.
Iets dat vaak over het hoofd wordt gezien is: wat is het bewaarbeleid voor verschillende soorten gegevens in onze organisatie? We kunnen deze instellen en we kunnen ze zelfs koppelen aan de verschillende soorten informatie-artefacten in onze modelleringsomgeving en, natuurlijk, ook in onze repository. Het mooie is dat deze bijlagen live in ons gegevenswoordenboek staan, dus wanneer we enterprise data-woordenboeken in de omgeving gebruiken, kunnen we ze aan meerdere modellen koppelen. We hoeven ze maar één keer te definiëren en we kunnen ze steeds opnieuw gebruiken in de verschillende modellen in onze omgeving. Dit is slechts een korte schermafbeelding om aan te geven dat u daadwerkelijk kunt opgeven wanneer u een bijlage doet, aan welke stukjes u deze wilt koppelen. En dit voorbeeld hier is eigenlijk een lijst met waarden, dus wanneer ze naar binnen gaan, kun je kiezen uit een lijst met waarden, je hebt veel controle in de modelomgeving van wat er wordt gekozen, en je kunt zelfs instellen wat de standaardwaarde is waarde is als een waarde niet wordt gekozen. Dus veel kracht daar. Ze leven in het gegevenswoordenboek.
Iets wat ik je verderop op dit scherm wil laten zien, daarnaast zie je de bijlagen soort van verschijnen in het bovenste gedeelte, eronder zie je informatie over gegevensbeveiliging. We kunnen gegevensbeveiligingsbeleid ook toepassen op de verschillende soorten informatie in de omgeving. Voor verschillende compliancetoewijzingen, gegevensbeveiligingsclassificaties, verzenden we een aantal direct uit de doos die u zojuist kunt genereren en gebruiken, maar u kunt ook uw eigen compliancetoewijzingen en normen definiëren. Of je nu HIPAA doet of een van de andere initiatieven die er zijn. En u kunt echt beginnen met het opbouwen van deze zeer rijke set metagegevens in uw omgeving.
En dan de verklarende woordenlijst en termen - dit is waar de zakelijke betekenis is gekoppeld. We hebben heel vaak gegevenswoordenboeken die een organisatie vaak als uitgangspunt gebruikt om te beginnen met het wegwerken van woordenlijsten, maar de terminologie en het woordgebruik zijn vaak erg technisch. Dus wat we kunnen doen, is dat we ze, als we dat willen, als uitgangspunt gebruiken om woordenlijsten te verdrijven, maar we willen echt dat het bedrijf deze bezit. Wat we hebben gedaan in de teamserveromgeving, is dat we mensen de mogelijkheid hebben gegeven bedrijfsdefinities te maken en dat we ze vervolgens kunnen koppelen aan de verschillende modelartefacten waarmee ze overeenkomen in de modelleeromgeving. We erkennen ook het punt dat eerder is besproken, namelijk: hoe meer mensen je typt, hoe groter de kans op menselijke fouten. Wat we ook doen in onze verklarende woordenlijststructuur, is dat we een hiërarchie van verklarende woordenlijst ondersteunen, dus we kunnen verschillende soorten woordenlijsten of verschillende soorten dingen in de organisatie hebben, maar net zo belangrijk is dat als u al enkele van deze bronnen hebt daar met de voorwaarden en alles wat is gedefinieerd, kunnen we een CSV-import doen om deze in onze modelleringsomgeving en ook onze teamserver of onze woordenlijst op te nemen en vanaf daar te beginnen met linken. En elke keer dat er iets wordt gewijzigd, is er een volledig controlespoor van wat de voor en na afbeeldingen waren, in termen van de definities en al het andere, en wat u in de zeer nabije toekomst zult zien aankomen, is ook meer een autorisatieworkflow dus we kunnen echt bepalen wie de leiding heeft, goedkeuringen door commissies of individuen, en dat soort dingen, om het bestuursproces in de toekomst nog robuuster te maken.
Wat dit ook voor ons doet, is wanneer we deze begrippenlijst in onze teamserverwoordenlijst hebben, dit is een voorbeeld van bewerking in een entiteit in het model zelf die ik hier heb opgevoed. Het kan gekoppelde termen bevatten, maar wat we ook doen, is dat er woorden in die woordenlijst staan die voorkomen in de notities of beschrijvingen van wat we hier in onze entiteiten hebben, die automatisch worden weergegeven in een lichtere hyperlinkkleur en als we Als u er met uw muis overheen gaat, zien we de definitie ook uit de zakelijke woordenlijst. Het geeft ons zelfs rijkere informatie wanneer we de informatie zelf consumeren, met alle verklarende woordenlijst die er zijn. Het helpt echt om de ervaring te verrijken en de betekenis toe te passen op alles waarmee we werken.
Dus nogmaals, dat was een snelle vlucht. Uiteraard kunnen we hier dagen aan besteden als we de verschillende delen onderzoeken, maar dit is een zeer snelle vlucht over het oppervlak. We willen echt begrijpen hoe die complexe data-omgevingen eruit zien. We willen de zichtbaarheid van al die gegevensartefacten verbeteren en samenwerken om ze te verdrijven met ER / Studio. We willen efficiëntere en geautomatiseerde gegevensmodellering mogelijk maken. En dat zijn alle soorten gegevens waar we het over hebben, of het nu gaat om big data, traditionele relationele gegevens, documentopslag of iets anders. En nogmaals, we hebben dat bereikt omdat we krachtige voorwaartse en achterwaartse engineeringmogelijkheden hebben voor de verschillende platforms en de andere tools die je misschien hebt. En het draait allemaal om het delen en communiceren in de hele organisatie met alle betrokken stakeholders. Dat is waar we betekenis toepassen door middel van naamgevingsnormen. Vervolgens passen we definities toe via onze zakelijke woordenlijsten. En dan kunnen we verdere classificaties doen voor al onze andere bestuursmogelijkheden met de metadata-extensies zoals datakwaliteitsuitbreidingen, classificaties voor stamgegevensbeheer of andere soorten classificaties die u op die gegevens wilt toepassen. En dan kunnen we verder samenvatten en de communicatie nog meer verbeteren met de zakelijke gegevensobjecten, met de verschillende doelgroepen, met name tussen modelbouwers en ontwikkelaars.
En nogmaals, wat hier erg belangrijk aan is, is achter dit alles een geïntegreerde repository met zeer robuuste mogelijkheden voor verandermanagement. Ik had geen tijd om het vandaag te laten zien, omdat het vrij complex wordt, maar de repository heeft zeer robuuste verandermanagement-mogelijkheden en audit-trails. Je kunt releases met een naam doen, je kunt versies met een naam doen, en we hebben ook de mogelijkheid voor degenen onder jullie die verandermanagement doen, we kunnen dat recht aan je taken koppelen. We hebben vandaag de mogelijkheid om taken in te voeren en uw modelwijzigingen te koppelen aan taken, net zoals ontwikkelaars hun codewijzigingen zouden associëren met de taken of gebruikersverhalen waarmee ze ook werken.
Nogmaals, dat was een heel snel overzicht. Ik hoop dat het genoeg is geweest om je eetlust op te wekken, zodat we veel diepere gesprekken kunnen voeren over het splitsen van sommige van deze onderwerpen in de toekomst. Bedankt voor je tijd en tot ziens, Rebecca.
Rebecca Jozwiak: Bedankt, Ron, dat was fantastisch en ik heb nogal wat vragen van het publiek, maar ik wil onze analisten de kans geven om hun tanden te laten verzinken in wat je te zeggen had. Eric, ik ga door en misschien als je deze dia, of een andere, wilt adresseren, waarom ga je dan niet eerst door? Of een andere vraag.
Eric Little: Natuurlijk. Sorry, wat was de vraag, Rebecca? Wil je dat ik iets specifieks vraag of …?
Rebecca Jozwiak: Ik weet dat je aanvankelijk wat vragen had voor Ron. Als je nu aan hem wilt vragen om een van deze, of sommige van je dia of iets anders dat je interesse wekte, te adresseren? Over IDERA's modelleringsfunctionaliteiten.
Eric Little: Ja, dus een van de dingen, Ron, dus hoe zien jullie eruit dat de diagrammen die je toonde algemene soorten entiteitsrelatiediagrammen zijn zoals je normaal zou gebruiken in de databaseconstructie, correct?
Ron Huizenga: Ja, over het algemeen, maar natuurlijk hebben we de uitgebreide typen voor de documentwinkels en dat soort dingen ook. We hebben eigenlijk gevarieerd van alleen pure relationele notatie, we hebben eigenlijk ook extra notaties toegevoegd voor die andere winkels.
Eric Little: Is er een manier waarop jullie op grafische modellen gebaseerde modellen kunnen gebruiken, dus is er een manier om bijvoorbeeld te integreren, laten we aannemen dat ik zoiets heb als een topkwadrant, TopBraid componist of ik heb iets gedaan in Protégé of, weet je, net als de financiële jongens in FIBO, doen ze veel werk in semantiek, RDF-dingen - is er een manier om dat type entiteitsrelatie grafiektype modellering in deze tool te brengen en te gebruiken het?
Ron Huizenga: We kijken eigenlijk hoe we met grafieken kunnen omgaan. We behandelen tegenwoordig niet expliciet grafische databases en dat soort dingen, maar we kijken naar manieren waarop we dat kunnen doen om onze metadata uit te breiden. Ik bedoel, we kunnen dingen binnenbrengen via XML en dat soort dingen op dit moment, als we tenminste een soort van een weergave van XML kunnen doen om het als uitgangspunt te brengen. Maar we kijken naar elegantere manieren om dat binnen te brengen.
En ik heb je ook die lijst met reverse engineering-bruggen laten zien die we daar ook hebben, dus we zijn altijd op zoek naar uitbreidingen voor die bruggen voor specifieke platforms. Het is een voortdurende, voortdurende inspanning, als dat zinvol is, om veel van deze nieuwe constructies en de verschillende platforms te omarmen. Maar ik kan zeggen dat we daar absoluut voorop lopen. De dingen die ik bijvoorbeeld heb getoond op MongoDB en dat soort dingen, we zijn de eerste leverancier van datamodellering die dat daadwerkelijk in ons eigen product doet.
Eric Little: Oké, ja. De andere vraag die ik voor jou had, was dus het bestuur en het behoud van de - zoals wanneer je het voorbeeld gebruikte, toen je het voorbeeld liet zien van de persoon die een 'werknemer' is, ik geloof dat het een ' salaris 'en dan heb je een' plan ', is er een manier, hoe beheer je bijvoorbeeld verschillende soorten mensen die kunnen hebben - laten we aannemen dat je een grote architectuur hebt, juist, laten we aannemen dat je een grote onderneming hebt en mensen beginnen dingen samen te brengen in deze tool en je hebt een groep hier met het woord 'werknemer' en een groep hier met het woord 'werknemer'. En een persoon hier zegt 'salaris' en een andere persoon zegt "salaris."
Hoe verzoenen en beheren en beheren jullie dit soort onderscheidingen? Omdat ik weet hoe we het in de grafische wereld zouden doen, weet je, je zou synoniemenlijsten gebruiken of je zou zeggen dat er één concept is en het heeft verschillende attributen, of je zou kunnen zeggen in het SKOS-model dat ik een voorkeurslabel heb en ik heb verschillende alternatieve labels die ik kan gebruiken. Hoe doen jullie dat?
Ron Huizenga: We doen het op een aantal verschillende manieren, en laten we vooral eerst over de terminologie praten. Een van de dingen die we doen, is natuurlijk dat we de gedefinieerde of gesanctioneerde voorwaarden willen hebben en in de zakelijke woordenlijst is het duidelijk waar we ze willen hebben. En we staan ook links toe naar synoniemen in de zakelijke woordenlijst, dus wat je kunt doen is zeggen, hier is mijn term, maar je kunt ook definiëren wat alle synoniemen voor die zijn.
Het interessante is natuurlijk dat wanneer je door dit enorme gegevenslandschap begint te kijken met al die verschillende systemen die je hebt, je niet zomaar naar buiten kunt gaan en de bijbehorende tabellen en dat soort dingen kunt wijzigen in overeenkomen met die naamgevingsstandaard omdat het een pakket kan zijn dat u hebt gekocht, dus u hebt geen controle over het wijzigen van de database of wat dan ook.
Wat we daar kunnen doen, naast het kunnen associëren van de definities van de woordenlijst, is door die universele toewijzingen waar ik het over had, wat we zouden doen, en een soort aanbevolen aanpak, is om een overkoepelend logisch model te hebben dat aangeeft wat over deze verschillende bedrijfsconcepten heb je het. Koppel de termen van de zakelijke woordenlijst daaraan, en het leuke is dat nu je dit construct hebt dat als het ware een logische entiteit vertegenwoordigt, je vervolgens kunt beginnen met het koppelen van die logische entiteit aan alle implementaties van die logische entiteit in de verschillende systemen.
Waar dat nodig is, kunt u zien, oh, "persoon" hier wordt in dit systeem "werknemer" genoemd. "Salaris" hier wordt in dit andere systeem "loon" genoemd. Omdat je dat zult zien, zul je alle verschillende manifestaties ervan zien omdat je ze aan elkaar hebt gekoppeld.
Eric Little: Oke geweldig, ja, ik snap het. In die zin, is het veilig om te zeggen dat dat een beetje lijkt op sommige van de objectgerichte benaderingen?
Ron Huizenga: Enigszins. Het is een beetje intensiever dan dan, denk je dat je zou kunnen zeggen. Ik bedoel, je zou kunnen kiezen voor handmatig koppelen en doorlopen en inspecteren en ze allemaal ook doen. Het enige waar ik niet echt over kon praten - want we hebben weer veel mogelijkheden - we hebben ook een volledige automatiseringsinterface in de Data Architect-tool zelf. En een macrofunctie, die echt een programmeertaal in de tool is. Dus we kunnen dingen doen zoals macro's schrijven, laten uitgaan en dingen ondervragen en links voor u maken. We gebruiken het voor het importeren en exporteren van informatie, we kunnen het gebruiken om dingen te veranderen of attributen toe te voegen, op basis van gebeurtenissen in het model zelf, of we kunnen het gebruiken om in batches uit te voeren en dingen te ondervragen en verschillende constructies te vullen in de model. Er is dus een volledige automatiseringsinterface waar mensen ook van kunnen profiteren. En het gebruiken van de universele toewijzingen daarmee zou een zeer krachtige manier zijn om dat te doen.
Rebecca Jozwiak: Oké, bedankt Ron en bedankt Eric. Dat waren geweldige vragen. Ik weet dat we een beetje voorbij de top van het uur rennen, maar ik zou Malcolm de kans willen geven om Ron wat vragen te stellen. Malcolm?
Malcolm Chisholm: Bedankt, Rebecca. Dus Ron, het is heel interessant, ik zie dat hier veel mogelijkheden zijn. Een van de gebieden waar ik erg in geïnteresseerd ben, is, bijvoorbeeld, als we een ontwikkelingsproject hebben, hoe zie je de datamodeler deze mogelijkheden gebruiken en misschien meer samenwerken met bedrijfsanalisten, met een gegevensprofiler, met een gegevenskwaliteitsanalist?, en met de bedrijfssponsors die uiteindelijk verantwoordelijk zijn voor de feitelijke informatie-eisen in het project. Hoe maakt de datamodeler het project echt effectiever en efficiënter met de mogelijkheden waar we naar kijken?
Ron Huizenga: Ik denk dat een van de eerste dingen die je daar moet doen is als datamodeler - en ik bedoel niet om enkele van de modelleerders te kiezen, maar ik zal in ieder geval - hebben sommige mensen nog steeds de indruk dat de datamodeler is eigenlijk het type poortwachter van like, we definiëren hoe het werkt, wij zijn de bewakers die ervoor zorgen dat alles correct is.
Nu is daar een aspect van, dat u ervoor moet zorgen dat u een goede gegevensarchitectuur en al het andere definieert. Maar het allerbelangrijkste is als datamodeler - en ik vond dit vrij duidelijk toen ik aan het overleg was - dat je een facilitator moet worden, dus je moet deze mensen bij elkaar brengen.
Het wordt geen ontwerp van tevoren, genereert, bouwt geen databases meer - wat je moet kunnen doen is dat je moet kunnen werken met al deze verschillende stakeholdergroepen, dingen doen zoals reverse engineering, informatie importeren, hebben andere mensen werken samen, of het nu in de verklarende woordenlijsten of documentatie is, enzovoort - en zijn een facilitator om dit naar de repository te halen en de concepten in de repository te koppelen en met die mensen te werken.
Het is echt veel meer een soort samenwerkingsomgeving waarbij zelfs door het definiëren van taken of zelfs discussiethreads of dat soort dingen die we in de teamserver hebben, mensen daadwerkelijk kunnen samenwerken, vragen kunnen stellen en tot de uiteindelijke eindproducten kunnen komen die ze behoefte aan hun data-architectuur en hun organisatie. Heeft dat soort antwoord?
Malcolm Chisholm: Ja, ik ben het ermee eens. Weet je, ik denk dat de facilitatievaardigheid iets is dat zeer wenselijk is in datamodelers. Ik ben het ermee eens dat we dat niet altijd zien, maar ik denk dat dat nodig is en ik zou willen suggereren dat er soms een neiging is om in uw hoek te blijven om uw datamodellering te doen, maar u moet echt samen zijn met de andere stakeholdergroepen of u begrijpt gewoon niet de gegevensomgeving waarmee u te maken heeft en ik denk dat het model daaronder lijdt. Maar dat is slechts mijn mening.
Ron Huizenga: En het is interessant omdat je eerder in je dia over de geschiedenis hebt verteld over hoe bedrijven een beetje afkeren van IT omdat ze de oplossingen en dergelijke dingen niet op tijd leverden.
Het is heel interessant dat in mijn latere consultingopdrachten, voordat ik productmanager werd, de meeste projecten die ik de afgelopen twee jaar daarvoor heb gedaan, door bedrijven werden gesponsord, waar het echt de business was die het aanstuurde en de data-architecten en modelbouwers maakten geen deel uit van IT. We maakten deel uit van een door bedrijven gesponsorde groep en we waren er als facilitators die samenwerkten met de rest van de projectteams.
Malcolm Chisholm: Dus ik denk dat dat een heel interessant punt is. Ik denk dat we een verschuiving in de zakenwereld beginnen te zien waar het bedrijf vraagt, of misschien denkt, niet zozeer als wat ik doe, als proces, maar ze beginnen ook na te denken over wat de gegevens zijn waarmee ik werk, wat zijn mijn gegevensbehoeften, wat zijn de gegevens waarmee ik als gegevens te maken heb, en in hoeverre kunnen we IDERA-producten en -mogelijkheden krijgen om dat standpunt te ondersteunen, en ik denk dat de behoeften van het bedrijf, zelfs hoewel het nog steeds een beetje ontluikend is.
Ron Huizenga: Ik ben het met je eens en ik denk dat we het steeds meer op die manier zien gaan. We hebben een ontwaken gezien en je hebt het eerder al gehad over het belang van gegevens. We zagen het belang van gegevens al vroeg in IT of in de evolutie van databases, en zoals u zegt, zijn we een beetje in deze hele procesbeheerscyclus terechtgekomen - en het proces is uiterst belangrijk, begrijp me daar niet verkeerd - maar wat is er nu gebeurd is wanneer dat gebeurde, data soort focus verloren.
En nu realiseren organisaties zich dat data echt het middelpunt is. Gegevens vertegenwoordigen alles wat we in ons bedrijf doen, dus we moeten ervoor zorgen dat we over nauwkeurige gegevens beschikken, zodat we de juiste informatie kunnen vinden die we nodig hebben om onze beslissingen te nemen. Omdat niet alles uit een bepaald proces komt. Een deel van de informatie is een bijproduct van andere dingen en we moeten het nog steeds kunnen vinden, weten wat het betekent en de gegevens die we daar zien uiteindelijk kunnen vertalen in kennis die we kunnen gebruiken om onze bedrijven beter te sturen.
Malcolm Chisholm: Juist, en nu een ander gebied waar ik mee worstel, is wat ik de datalevenscyclus zou noemen, weet je, als we kijken naar het soort dataleveringsketen dat door een onderneming gaat, beginnen we met gegevensverzameling of gegevensverzameling, wat de invoer van gegevens kan zijn, maar het kan ook zijn dat ik gegevens van buiten de onderneming krijg van een of andere gegevensverkoper.
En dan van gegevensverzameling gaan we naar gegevensonderhoud, waar ik overweeg deze gegevens te standaardiseren en te verzenden naar plaatsen waar het nodig is. En dan gegevensgebruik, de feitelijke punten waar gegevens zijn, gaat u waarde uit de gegevens halen.
En vroeger gebeurde dit allemaal in één individuele stijl, maar vandaag is het bijvoorbeeld, weet u, een analyseomgeving, en daarna een archief, een winkel, waar we de gegevens plaatsen wanneer we niet langer hebben het nodig en uiteindelijk een zuiveringsproces. Hoe ziet u datamodellering passend in het beheer van deze hele gegevenslevenscyclus?
Ron Huizenga: Dat is een heel goede vraag en één ding waar ik hier echt helemaal geen tijd voor had om hier in detail op in te gaan, is waar we echt over beginnen te praten is datalijn. Dus wat we in feite kunnen doen, is dat we een gegevenslijnfunctie in onze tools hebben en, zoals ik al zei, we kunnen er zelfs een deel van extraheren uit ETL-tools, maar u kunt het ook in kaart brengen door alleen de lijn te tekenen. Elk van deze datamodellen of databases die we hebben vastgelegd en in modellen hebben gebracht, kunnen we verwijzen naar de constructen daarvan in ons datalinea-diagram.
Wat we kunnen doen, is een gegevensstroom tekenen, zoals u zegt, van bron tot doel, en gedurende de hele levenscyclus van hoe die gegevens door de verschillende systemen worden getransporteerd en wat u gaat vinden is, laten we werknemers nemen 'data - het is een van mijn favorieten op basis van een project dat ik jaren geleden deed. Ik werkte met een organisatie die werknemersgegevens in 30 verschillende systemen had. Wat we daar uiteindelijk deden - en Rebecca's dook de dia van de gegevenslijn op - dit is een vrij simplistische dia van de gegevenslijn hier, maar wat we konden doen was alle gegevensstructuren inbrengen, ernaar verwijzen in het diagram, en dan kunnen we eigenlijk beginnen te kijken naar wat de stromen tussen zijn, en hoe zijn die verschillende gegevensentiteiten met elkaar verbonden in een stroom? En we kunnen ook verder gaan. Dit maakt deel uit van een gegevensstroom of lijndiagram dat we hier zien. Als je verder wilt gaan, hebben we ook het business architect-gedeelte van deze suite en daar is hetzelfde van toepassing.
Elk van de datastructuren die we hebben vastgelegd in de datamodelleringomgeving, daarnaar kan worden verwezen in de business modeling tool, zodat u zelfs in uw businessmodeldiagrammen of uw bedrijfsprocesdiagrammen naar individuele datastores kunt verwijzen als u de gegevensmodelleringsomgeving, en terwijl u ze in de mappen in uw bedrijfsprocesmodel gebruikt, kunt u zelfs de CRUD daarop specificeren, hoe die informatie wordt verbruikt of geproduceerd, en dan kunnen we beginnen met het genereren van dingen als impact- en analyserapporten en diagrammen daaruit.
Wat we willen bereiken, en we hebben al veel mogelijkheden, maar een van de dingen waar we een soort doelpaal voor hebben, waar we naar kijken, terwijl we onze tools blijven ontwikkelen, is in staat om die end-to-end, organisatorische datalijn en de volledige levenscyclus van data in kaart te brengen.
Malcolm Chisholm: Oké. Rebecca, mag ik er nog een?
Rebecca Jozwiak: Ik zal je nog een toestaan, Malcolm, ga je gang.
Malcolm Chisholm: Heel erg bedankt. Als we nadenken over gegevensbeheer en nadenken over gegevensmodellering, hoe zorgen we ervoor dat die twee groepen effectief samenwerken en elkaar begrijpen?
Eric Little: Nou, het is interessant, ik denk dat het echt van de organisatie afhangt, en het gaat terug naar mijn eerdere concept: in die organisaties waar de initiatieven zakelijk waren, waren we er direct bij betrokken. Ik leidde bijvoorbeeld een gegevensarchitectuur team, maar we waren nauw verbonden met de zakelijke gebruikers en we hielpen hen daadwerkelijk om hun programma voor gegevensbeheer op te zetten. Nogmaals, meer een adviserende aanpak, maar het is echt meer een zakelijke functie.
Wat u echt moet kunnen doen, is dat u datamodelers en architecten nodig hebt die zaken goed begrijpen, zich tot de zakelijke gebruikers kunnen verhouden en hen vervolgens hebben geholpen om de governanceprocessen eromheen op te staan. Het bedrijf wil het doen, maar over het algemeen hebben we de technologische kennis om hen te helpen zich te onderscheiden van dat soort programma's. Het moet echt een samenwerking zijn, maar het moet wel een bedrijf zijn.
Malcolm Chisholm: Oké, dat is geweldig. Dank je.
Dr. Eric Little: Oké.
Rebecca Jozwiak: Oké, heel erg bedankt. Publieksleden, ik ben bang dat we uw vragen niet hebben beantwoord, maar ik zal ervoor zorgen dat ze worden doorgestuurd naar de juiste gast die we vandaag aan de lijn hadden. Ik wil Eric, Malcolm en Ron heel erg bedanken voor hun gasten vandaag. Dit was geweldig spul, mensen. En als je genoten hebt van de IDERA webcast van vandaag, zal IDERA ook aanstaande woensdag op Hot Technologies zijn als je mee wilt doen, over de uitdagingen van indexering en Oracles, dus een ander fascinerend onderwerp.
Heel erg bedankt, mensen, wees voorzichtig, en we zullen je de volgende keer zien. Tot ziens.
