Przez Techopedia Staff, 28 września 2016 r
Na wynos: Host Rebecca Jozwiak omawia rozwiązania dotyczące architektury danych z Ericem Little z OSTHUS, Malcolmem Chisholmem z First San Francisco Partners i Ronem Huizengą z IDERA.
Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.
Rebecca Jóźwiak: Panie i panowie, witam i witamy w Hot Technologies 2016. Dzisiaj rozmawiamy o „Budowaniu architektury danych opartej na biznesie”, zdecydowanie gorący temat. Nazywam się Rebecca Jozwiak, będę gospodarzem dzisiejszego webcastu. Publikujemy tweety z hashtagiem # HotTech16, więc jeśli jesteś już na Twitterze, możesz również dołączyć do tego. Jeśli masz pytania w dowolnym momencie, wyślij je do okienka pytań i odpowiedzi w prawym dolnym rogu ekranu, a my upewnimy się, że na nie odpowiedzą. Jeśli nie, upewnimy się, że nasi goście je dla Ciebie zdobędą.
Więc dzisiaj mamy naprawdę fascynujący skład. Dzisiaj jest z nami wiele ciężkich uderzeń. Mamy Erica Little, wiceprezesa ds. Danych z OSTHUS. Mamy Malcolma Chisholma, dyrektora ds. Innowacji, który jest naprawdę fajnym tytułem dla First San Francisco Partners. I mamy Ron Huizenga, starszy menedżer produktu z IDERA. I wiesz, IDERA to naprawdę pełny pakiet rozwiązań do zarządzania danymi i modelowania. A dzisiaj przedstawi nam demo tego, jak działa jego rozwiązanie. Ale zanim do tego dojdziemy, Eric Little, przekażę ci piłkę.
Eric Little: Dobra, wielkie dzięki. Omówię tutaj kilka tematów, które, jak sądzę, będą miały trochę związek z przemową Rona i mam nadzieję, że przygotuję scenę dla niektórych z tych tematów, niektórych pytań i odpowiedzi.
Rzeczą, która zainteresowała mnie tym, co robi IDERA, jest to, że myślę, że słusznie wskazują, że złożone środowiska naprawdę przynoszą obecnie wiele wartości biznesowych. A przez złożone środowiska rozumiemy złożone środowiska danych. Technologia bardzo szybko się rozwija i trudno jest nadążyć za nią w dzisiejszym środowisku biznesowym. Dlatego osoby pracujące w przestrzeniach technologicznych często widzą, że masz klientów, którzy pracują z problemami: „Jak korzystać z dużych zbiorów danych? Jak włączyć semantykę? Jak połączyć niektóre z tych nowych rzeczy z moimi starszymi danymi? ”I tak dalej, i tego rodzaju prowadzi nas obecnie do tych czterech v dużych zbiorów danych, z którymi wiele osób się zna i rozumiem, że może być ich więcej niż cztery czasami - widziałem ich aż osiem lub dziewięć - ale normalnie, kiedy ludzie mówią o takich rzeczach jak duże zbiory danych lub jeśli mówimy o dużych danych, zwykle patrzysz na coś w rodzaju skali przedsiębiorstwa. I tak ludzie powiedzą: dobrze, dobrze, pomyśl o objętości twoich danych, która zwykle jest w centrum uwagi - tylko tyle masz. Prędkość danych ma związek z tym, jak szybko mogę je przenosić lub jak szybko mogę je wyszukiwać lub uzyskiwać odpowiedzi i tak dalej. I osobiście uważam, że lewa strona tego jest czymś, co jest rozwiązywane i obsługiwane stosunkowo szybko przez wiele różnych podejść. Ale po prawej stronie widzę wiele możliwości ulepszeń i wiele nowych technologii, które naprawdę pojawiają się na pierwszym planie. I to naprawdę ma związek z trzecią kolumną, różnorodnością danych.
Innymi słowy, większość firm obecnie szuka ustrukturyzowanych, częściowo ustrukturyzowanych i nieustrukturyzowanych danych. Dane obrazu stają się gorącym tematem, więc dzięki możliwości korzystania z wizji komputerowej, patrzenia na piksele, możliwości zeskrobywania tekstu, NLP, ekstrakcji encji, masz informacje na wykresie, które pochodzą z modeli statystycznych lub z semantycznych modele, masz dane relacyjne, które istnieją w tabelach i tak dalej. A zatem zebranie tych wszystkich danych razem i wszystkich tych różnych typów naprawdę stanowi duże wyzwanie, a zobaczysz to w Gartner i innych ludziach, którzy niejako podążają za trendami w branży.
A potem ostatnią rzeczą, o której ludzie mówią w dużych zbiorach danych, jest często pojęcie żarłoczności, które jest tak naprawdę niepewnością twoich danych, ich rozmytością. Jak dobrze wiesz, o czym są twoje dane, jak dobrze rozumiesz, co tam jest i wiesz? Umiejętność korzystania ze statystyk i możliwość korzystania z pewnego rodzaju informacji na temat tego, co możesz znać lub korzystania z jakiegoś kontekstu, mogą być tam cenne. A zatem możliwość spojrzenia na dane w ten sposób pod kątem tego, ile masz, jak szybko musisz je przenieść lub uzyskać, wszystkie rodzaje danych, które możesz mieć w swoim przedsiębiorstwie i jak jesteś pewien, gdzie jesteś jest, czym jest, w jakiej jakości i tak dalej. To naprawdę wymaga dużego, skoordynowanego wysiłku wielu osób w celu skutecznego zarządzania ich danymi. Dlatego modelowanie danych ma coraz większe znaczenie w dzisiejszym świecie. Tak więc dobre modele danych naprawdę przynoszą wiele sukcesów w aplikacjach dla przedsiębiorstw.
Masz źródła danych z różnych źródeł, jak mówiliśmy, co naprawdę wymaga wielu różnych rodzajów integracji. Więc połączenie tego wszystkiego jest naprawdę przydatne, aby móc uruchamiać zapytania, na przykład w wielu typach źródeł danych i pobierać informacje z powrotem. Ale aby to zrobić, potrzebujesz dobrych strategii mapowania, więc mapowanie tego rodzaju danych i nadążanie za tymi mapowaniami może być prawdziwym wyzwaniem. A potem pojawia się problem: jak połączyć moje starsze dane ze wszystkimi nowymi źródłami danych? Załóżmy, że mam wykres, czy biorę wszystkie moje dane relacyjne i umieszczam je na wykresie? Zwykle nie jest to dobry pomysł. Jak więc ludzie mogą zarządzać wszystkimi tego rodzaju modelami danych, które się toczą? Analiza naprawdę musi być przeprowadzona na wielu różnych źródłach danych i kombinacjach. Tak więc odpowiedzi, które z tego wynikają, są niezbędne, aby ludzie naprawdę podejmowali dobre decyzje biznesowe.
Nie chodzi więc tylko o budowanie technologii ze względu na technologię, ale o to, co mam zamiar zrobić, co mogę z tym zrobić, jaką analizę mogę przeprowadzić i dlatego, jak już to zrobiłem mówiłem, aby zebrać te rzeczy razem, ich integracja jest naprawdę, bardzo ważna. Jeden z analiz tego typu działa na takich rzeczach, jak wyszukiwanie stowarzyszone i zapytania. To naprawdę staje się koniecznością. Twoje zapytania muszą być zwykle podzielone na wiele rodzajów źródeł i wiarygodne.
Jednym kluczowym elementem, który często, szczególnie ludzie, będą patrzeć na kluczowe rzeczy, takie jak technologie semantyczne - i mam nadzieję, że Ron porozmawia o tym trochę w podejściu IDERA - jak oddzielić lub zarządzać modelować warstwę danych z samej warstwy danych, z tych surowych danych? Tak więc w warstwie danych możesz mieć bazy danych, możesz mieć dane dokumentu, możesz mieć dane arkusza kalkulacyjnego, możesz mieć dane obrazu. Jeśli jesteś w takich dziedzinach jak przemysł farmaceutyczny, masz ogromną ilość danych naukowych. Poza tym ludzie zwykle szukają sposobu na zbudowanie modelu, który pozwoli im szybko zintegrować te dane, a tak naprawdę, kiedy szukasz danych, nie chcesz wyciągać wszystkich danych do warstwy modelu, to, na co patrzysz, aby zrobić warstwę modelu, to dać ci logiczną reprezentację tego, czym są rzeczy, wspólne słowniki, wspólne typy bytów i relacji oraz zdolność do prawdziwego sięgania do danych tam, gdzie są. Musi więc powiedzieć, co to jest, i musi powiedzieć, gdzie to jest, i musi powiedzieć, jak iść po to, aby go odzyskać.
Jest to więc podejście, które odniosło duży sukces w napędzaniu technologii semantycznych do przodu, co jest obszarem, w którym dużo pracuję. Pytanie, które chciałem zadać Ronowi i które, jak sądzę, przyda się w sekcji pytań i odpowiedzi, brzmi: jak to osiągnąć dzięki platformie IDERA? Czy więc warstwa modelu faktycznie jest oddzielna od warstwy danych? Czy są bardziej zintegrowani? Jak to działa i jakie są niektóre wyniki i korzyści, które widzą dzięki swojemu podejściu? Dlatego dane referencyjne stają się naprawdę kluczowe. Więc jeśli będziesz mieć tego rodzaju modele danych, jeśli będziesz w stanie federować i przeszukiwać różne rzeczy, naprawdę musisz mieć dobre dane referencyjne. Problem w tym, że dane referencyjne mogą być naprawdę trudne do utrzymania. Często więc nazywanie standardów samo w sobie jest trudnym wyzwaniem. Jedna grupa nazywa coś X, a druga nazywa Y, a teraz masz problem ze znalezieniem X i Y, gdy szukają tego rodzaju informacji? Ponieważ nie chcesz po prostu podawać im części danych, chcesz dać im wszystko, co jest z nimi związane. W tym samym czasie zmieniają się warunki, oprogramowanie staje się przestarzałe i jak dalej utrzymujesz te dane referencyjne w czasie?
I znowu, technologie semantyczne, w szczególności wykorzystujące taksonomie i słowniki, słowniki danych, zapewniły standardowy sposób kosmicznego wykonywania tego, który jest naprawdę bardzo solidny, wykorzystuje pewne rodzaje standardów, ale społeczność baz danych zrobiła to dla również przez długi czas, tylko na różne sposoby. Myślę, że jednym z kluczy tutaj jest zastanowienie się, jak używać modeli relacji między bytami, jak być może modeli wykresów lub innego rodzaju podejścia, które naprawdę może dać ci standardowy sposób obsługi danych referencyjnych. A potem, oczywiście, kiedy masz dane referencyjne, strategie mapowania muszą zarządzać szeroką gamą nazw i encji. Dlatego eksperci merytoryczni często lubią używać własnych terminów.
Dlatego wyzwaniem jest zawsze to, w jaki sposób podajesz komuś informacje, ale dostosowujesz je do sposobu, w jaki o nich mówią? Tak więc jedna grupa może mieć jeden sposób patrzenia na coś, na przykład możesz być chemikiem pracującym nad lekiem i możesz być biologiem strukturalnym pracującym nad tym samym lekiem i możesz mieć różne nazwy dla tych samych rodzajów bytów które dotyczą twojego pola. Musisz wymyślić sposoby połączenia spersonalizowanych terminologii, ponieważ inne podejście polega na zmuszeniu ludzi do porzucenia terminu i korzystania z cudzych terminów, których często nie lubią. Inną kwestią jest to, że obsługa dużej liczby synonimów staje się trudna, więc w danych wielu ludzi istnieje wiele różnych słów, które mogą odnosić się do tej samej rzeczy. Występuje tam problem odniesienia przy użyciu zestawu relacji wiele do jednego. Specjalistyczne warunki różnią się w zależności od branży, więc jeśli masz zamiar znaleźć nadrzędne rozwiązanie dla tego rodzaju zarządzania danymi, jak łatwo jest je przenosić z jednego projektu lub z jednej aplikacji do drugiej? To może być kolejne wyzwanie.
Automatyzacja jest ważna i stanowi również wyzwanie. Ręczna obsługa danych referencyjnych jest kosztowna. Kosztowne jest utrzymywanie ręcznego mapowania i drogie jest, aby eksperci od tematów przestali wykonywać codzienne zadania i musieli wchodzić i stale naprawiać słowniki danych, aktualizować definicje itd. I tak dalej. Replikowalne słowniki naprawdę mają dużą wartość. Są to często słownictwo, które można znaleźć poza organizacją. Na przykład, jeśli wykonujesz pracę na ropie naftowej, pojawią się pewne słowniki, które możesz wypożyczyć z przestrzeni otwartego oprogramowania, tak samo z farmaceutykami, tak samo z branżą bankową i finansową, tak samo z wieloma tego rodzaju obszarami. Ludzie udostępniają ogólne, powtarzalne słowniki wielokrotnego użytku, z których mogą korzystać użytkownicy.
I znowu, patrząc na narzędzie IDERA, jestem ciekawy, jak sobie z tym radzą pod względem stosowania różnego rodzaju standardów. W świecie semantyki często widzisz takie rzeczy, jak modele SKOS, które zapewniają standardy co najmniej szersze niż / węższe niż relacje, a te rzeczy mogą być trudne do zrobienia w modelach ER, ale wiesz, nie niemożliwe, to zależy tylko od tego, ile maszyny i połączenia, które można obsługiwać w tego typu systemach.
Na koniec chciałem po prostu dokonać porównania z niektórymi silnikami semantycznymi, które widzę w branży, i poprosić Rona i przygotować go trochę do rozmowy o tym, jak system IDERA był używany w połączeniu z dowolnymi technologiami semantycznymi. Czy można go zintegrować z potrójnymi sklepami, bazami danych grafów? Jak łatwo jest korzystać ze źródeł zewnętrznych, ponieważ tego rodzaju rzeczy w świecie semantycznym można często wypożyczyć za pomocą punktów końcowych SPARQL? Możesz importować modele RDF lub OWL bezpośrednio do swojego modelu - odwołać się do nich - na przykład ontologia genów lub ontologia białek, które mogą żyć gdzieś we własnej przestrzeni z własną strukturą zarządzania, a ja mogę po prostu zaimportować wszystkie lub część tego, ponieważ potrzebuję tego do moich własnych modeli. I jestem ciekawy, jak IDERA podchodzi do tego problemu. Czy musisz utrzymywać wszystko wewnętrznie, czy są sposoby, aby skorzystać z innych rodzajów standardowych modeli i wciągnąć je i jak to działa? I ostatnią rzeczą, o której tu wspomniałem, jest to, ile pracy ręcznej jest naprawdę potrzebne do zbudowania glosariuszy i repozytoriów metadanych?
Więc wiem, że Ron pokaże nam kilka demonstracji tego rodzaju rzeczy, które będą naprawdę interesujące. Ale problemy, które często widzę podczas konsultacji z klientami, polegają na tym, że wiele błędów pojawia się, gdy ludzie piszą we własnych definicjach lub we własnych metadanych. Więc masz błędy ortograficzne, błędy grubego palca, to jedno. Dostajesz także ludzi, którzy mogą wziąć coś z, po prostu, Wikipedii lub źródła niekoniecznie takiej jakości, jakiej możesz chcieć w twojej definicji, lub twoja definicja jest tylko z perspektywy jednej osoby, więc nie jest kompletna i wtedy nie jest jasne jak działa proces zarządzania. Oczywiście zarządzanie jest bardzo, bardzo dużym problemem, za każdym razem, gdy mówisz o danych referencyjnych i za każdym razem, gdy mówisz o tym, jak to może pasować do czyichś danych podstawowych, w jaki sposób będą wykorzystywać swoje metadane, i wkrótce.
Chciałem tylko przedstawić niektóre z tych tematów. Są to przedmioty, które widzę w przestrzeni biznesowej w wielu różnych rodzajach zadań konsultingowych i w wielu różnych przestrzeniach. Bardzo mnie interesuje, co Ron pokaże nam z IDERA, aby wskazać niektóre z tych tematów . Dziękuję bardzo.
Rebecca Jóźwiak: Dziękuję bardzo, Eric i bardzo podoba mi się twój komentarz, że wiele błędów może wystąpić, jeśli ludzie piszą własne definicje lub metadane. Wiem, że w świecie dziennikarstwa istnieje mantra, że „wiele oczu popełnia niewiele błędów”, ale jeśli chodzi o praktyczne zastosowania, zbyt wiele rąk w słoiku z ciasteczkami zwykle powoduje, że masz dużo połamanych ciasteczek, prawda?
Eric Little: Tak i zarazki.
Rebecca Jóźwiak: Tak. Po tym zamierzam przekazać to Malcolmowi Chisholmowi. Malcolm, podłoga jest twoja.
Malcolm Chisholm: Dziękuję bardzo, Rebecca. Chciałbym trochę rzucić okiem na to, o czym mówił Eric, i dodać coś w rodzaju kilku spostrzeżeń, na które, jak wiecie, Ron może zechcieć odpowiedzieć, mówiąc o „W kierunku architektury danych opartej na biznesie ”- co to znaczy kierować się biznesem i dlaczego to takie ważne? Czy to tylko jakaś forma szumu? Nie wydaje mi się
Jeśli spojrzymy na to, co się dzieje od tego czasu, wiesz, że komputery mainframe naprawdę stały się dostępne dla firm - powiedzmy około 1964 roku - do dzisiaj, widzimy, że nastąpiło wiele zmian. Zmiany te podsumowałbym jako przejście od koncentracji na procesach do koncentracji na danych. I to sprawia, że architektury danych oparte na biznesie są tak ważne i tak aktualne na dzisiaj. I myślę, wiesz, to nie tylko modne słowo, to coś, co jest absolutnie prawdziwe.
Ale możemy to docenić nieco bardziej, jeśli zagłębimy się w historię, więc cofamy się w czasie, cofając się do lat sześćdziesiątych, a przez pewien czas dominowały komputery mainframe. Te następnie ustąpiły miejsca komputerom, na których rzeczywiście buntowali się użytkownicy, kiedy pojawiły się komputery PC. Rebelia przeciwko scentralizowanemu IT, które ich zdaniem nie spełniało ich potrzeb, nie było wystarczająco zwinne. To szybko dało początek przetwarzaniu rozproszonemu, gdy komputery zostały połączone ze sobą. I wtedy zaczął się internet, który zatarł granice przedsiębiorstwa - mógł teraz wchodzić w interakcje z podmiotami spoza siebie w zakresie wymiany danych, co nigdy wcześniej nie miało miejsca. A teraz wkroczyliśmy w erę chmury i dużych zbiorów danych, w której chmura to platformy, które naprawdę są utowarowującą infrastrukturą, dlatego zostawiamy niejako informatykę o potrzebie prowadzenia centrów dużych zbiorów danych, ponieważ, wiesz udostępniono nam pojemność chmury i jednocześnie z tymi dużymi danymi, o których Eric, jak wiecie, tak elokwentnie rozmawiał. I ogólnie, jak widzimy, kiedy nastąpiła zmiana technologii, stała się bardziej skoncentrowana na danych, bardziej dbamy o dane. Podobnie jak w przypadku Internetu, sposób wymiany danych. W przypadku dużych zbiorów danych cztery lub więcej v samych danych.
W tym samym czasie, a może przede wszystkim, sprawy biznesowe uległy zmianie. Kiedy po raz pierwszy wprowadzono komputery, były one wykorzystywane do automatyzacji takich rzeczy jak książki i akta. I wszystko, co było procesem ręcznym, obejmującym księgi rachunkowe itp., Zostało zaprogramowane zasadniczo w domu. W latach 80. zmieniło się to na dostępność pakietów operacyjnych. Nie musiałeś już pisać własnej listy płac, możesz kupić coś, co to zrobiło. Doprowadziło to do znacznej redukcji w tym czasie lub restrukturyzacji w wielu działach IT. Ale potem pojawiła się inteligencja biznesowa z takimi hurtowniami danych, głównie w latach 90. Następnie pojawiły się modele biznesowe dotcom, które były oczywiście wielkim szaleństwem. Następnie MDM. Dzięki MDM zaczynasz rozumieć, że nie myślimy o automatyzacji; koncentrujemy się na traktowaniu danych jako danych. A następnie analityka reprezentująca wartość, którą można uzyskać z danych. W ramach analizy widać firmy, które odnoszą sukcesy, których podstawowy model biznesowy opiera się na danych. Google, Twitter, Facebook byłyby tego częścią, ale można argumentować również, że Walmart jest.
I tak firma naprawdę myśli teraz o danych. Jak możemy uzyskać wartość z danych? W jaki sposób dane mogą napędzać biznes, strategię i jesteśmy w złotej erze danych. Biorąc to pod uwagę, co dzieje się w naszej architekturze danych, jeśli dane nie są już traktowane jako wyczerpanie pochodzące z zaplecza aplikacji, ale naprawdę ma kluczowe znaczenie dla naszych modeli biznesowych? Cóż, część problemu, który mamy do osiągnięcia, jakim jest IT, naprawdę utknęła w przeszłości z cyklem życia systemów, co było konsekwencją konieczności szybkiego radzenia sobie z tą fazą automatyzacji procesów we wczesnym wieku IT i pracy w projekty są podobne. Dla IT - a to trochę karykatura - ale próbuję powiedzieć, że niektóre bariery w uzyskaniu architektury danych opartej na biznesie są spowodowane tym, że w pewnym sensie bezkrytycznie zaakceptowaliśmy kulturę w IT który wywodzi się z minionego wieku.
Więc wszystko jest projektem. Opowiedz mi szczegółowo o swoich wymaganiach. Jeśli coś nie działa, to dlatego, że nie powiedziałeś mi o swoich wymaganiach. To nie działa dzisiaj z danymi, ponieważ nie zaczynamy od niezautomatyzowanych procesów manualnych lub, no wiesz, technicznej konwersji procesów biznesowych, zaczynamy bardzo często od już istniejących danych produkcyjnych, które próbujemy uzyskać wartość. Ale nikt, kto sponsoruje projekt skoncentrowany na danych, tak naprawdę nie rozumie tych danych dogłębnie. Musimy przeprowadzić wykrywanie danych, musimy przeprowadzić analizę danych źródłowych. I to tak naprawdę nie pasuje do rozwoju systemów, wiesz - wodospad, cykl życia SDLC - którego zwinność, powiedziałbym, jest rodzajem lepszej wersji tego.
Koncentruje się na technologii i funkcjonalności, a nie danych. Na przykład, kiedy przeprowadzamy testy w fazie testowej, zwykle tak jest, czy moja funkcjonalność działa, powiedzmy, moja ETL, ale nie testujemy danych. Nie testujemy naszych założeń dotyczących nadchodzących danych źródłowych. Gdybyśmy to zrobili, bylibyśmy być może w lepszej formie i jako ktoś, kto wykonał projekty hurtowni danych i cierpiał z powodu zmian w poprzedniej wersji, niszcząc moje ETL, byłbym wdzięczny. W rzeczywistości chcemy zobaczyć testy jako wstępny krok do ciągłego monitorowania jakości danych produkcyjnych. Mamy tutaj wiele postaw, w których trudno jest osiągnąć opartą na biznesie architekturę danych, ponieważ jesteśmy uwarunkowani erą ukierunkowania na procesy. Musimy przejść do centralizacji danych. I to nie jest całkowite przejście, wiesz, wciąż jest wiele pracy procesowej, ale naprawdę nie myślimy w kategoriach danych, kiedy jest to konieczne, i okoliczności, które występują, gdy naprawdę zobowiązany do tego.
Teraz firma zdaje sobie sprawę z wartości danych, chce je odblokować, więc jak to zrobimy? Jak więc wykonać przejście? Cóż, stawiamy dane w centrum procesów rozwojowych. I pozwalamy firmie przewodzić dzięki wymaganiom informacyjnym. Rozumiemy, że nikt nie rozumie istniejących danych źródłowych na początku projektu. Można argumentować, że struktura danych i same dane dotarły tam odpowiednio przez IT i operacje, więc powinniśmy to wiedzieć, ale tak naprawdę nie. Jest to rozwój skoncentrowany na danych. Musimy więc, zastanawiając się, gdzie jesteśmy i jak przeprowadzamy modelowanie danych w świecie skoncentrowanym na danych, musimy mieć dla użytkowników pętle zwrotne w zakresie dopracowywania ich wymagań dotyczących informacji, podobnie jak w przypadku wyszukiwania danych i profilowania danych, przewiduj analizę danych źródłowych, a gdy będziemy coraz bardziej pewni naszych danych. A teraz mówię o bardziej tradycyjnym projekcie, takim jak koncentrator MDM lub hurtownia danych, niekoniecznie projekty dużych zbiorów danych, chociaż, jak twierdzę, wciąż jest to dość zbliżone. Pętle te obejmują projektantów danych, wiesz, stopniowo ulepszając ich model danych i wchodząc w interakcje z użytkownikami, aby upewnić się, że wymagania informacyjne są udoskonalone w oparciu o to, co jest możliwe, co jest dostępne, z danych źródłowych, ponieważ lepiej je rozumieją, więc model danych nie jest już przypadkiem, ponieważ w stanie, który albo nie istnieje, albo jest całkowicie wykonany, stopniowo skupia się na nim.
Podobnie, w dalszej części procesu zapewniania jakości, w którym opracowujemy zasady testowania jakości danych, aby upewnić się, że dane mieszczą się w parametrach, o których zakładamy. Wchodząc, Eric mówił o zmianach danych referencyjnych, które mogą się zdarzyć. Nie chcesz być poniekąd ofiarą czegoś w rodzaju niezarządzanych zmian w tym obszarze, więc zasady zapewnienia jakości mogą przejść do postprodukcyjnego, ciągłego monitorowania jakości danych. Możesz więc zacząć sprawdzać, czy będziemy koncentrować się na danych, jak to się dzieje, że rozwój skoncentrowany na danych różni się od opartych na funkcjonalności SDLC i Agile. A potem musimy również zwrócić uwagę na poglądy biznesowe. Mamy - i ponownie to odzwierciedla to, co powiedział Eric - mamy model danych definiujący plan historii danych dla naszej bazy danych, ale jednocześnie potrzebujemy tych modeli koncepcyjnych, tych biznesowych poglądów na dane, które tradycyjnie nie były wykonywane w przeszłość. Myślę, że czasami myśleliśmy, że model danych może zrobić wszystko, ale musimy mieć widok koncepcyjny, semantykę i patrzeć na dane, renderować je przez warstwę abstrakcji, która przekłada model pamięci na biznes widok. I znowu, wszystkie rzeczy, o których mówił Eric w zakresie semantyki, stają się ważne, aby to zrobić, więc mamy dodatkowe zadania modelowania. Myślę, że to interesujące, jeśli wyszedłeś w szeregi jako modelarz danych, tak jak ja, i znowu coś nowego.
Na koniec chciałbym powiedzieć, że większa architektura musi odzwierciedlać tę nową rzeczywistość. Na przykład tradycyjny MDM dla klienta jest w pewnym sensie, okej, przenieśmy dane naszych klientów do centrum, w którym możemy, jak wiesz, zrozumieć je pod względem naprawdę tylko jakości danych dla aplikacji back office. Z punktu widzenia strategii biznesowej to ziewanie. Dziś jednak przyglądamy się koncentratorom MDM dla klientów, które zawierają dodatkowe dane profilu klienta, a nie tylko dane statyczne, które tak naprawdę mają dwukierunkowy interfejs z aplikacjami transakcyjnymi klienta. Tak, nadal obsługują back office, ale teraz wiemy również o zachowaniach naszych klientów. Jest to droższe w budowie. Jest to bardziej skomplikowane w budowie. Ale jest napędzany przez biznes w sposób, w jaki tradycyjny MDM klienta nie jest. Wymieniasz orientację na biznes na prostsze projekty, które są łatwiejsze do wdrożenia, ale dla biznesu właśnie to chcą zobaczyć. Jesteśmy naprawdę w nowej erze i myślę, że istnieje szereg poziomów, w których musimy reagować na architekturę danych napędzającą biznes i myślę, że to bardzo ekscytujący czas na robienie różnych rzeczy.
Dziękuję ci, Rebecca.
Rebecca Jozwiak: Dzięki Malcolm, i naprawdę podobało mi się to, co powiedziałeś o modelach danych, musi karmić widok biznesowy, ponieważ, w przeciwieństwie do tego, co mówiłeś, gdzie IT trzymało wodze tak długo, a to po prostu nie jest już taki przypadek i kultura musi się zmienić. I jestem prawie pewien, że w tle był pies, który zgodził się z tobą w 100%. I tym samym przekażę piłkę Ronowi. Jestem naprawdę podekscytowany widząc twoje demo. Ron, podłoga jest twoja.
Ron Huizenga: Dziękuję bardzo i zanim przejdziemy do tego, przejrzę kilka slajdów, a potem trochę demonstracji, ponieważ, jak zauważyli Eric i Malcolm, jest to bardzo szeroki i głęboki temat, i z tym, o czym dzisiaj mówimy, po prostu ocieramy się o to, ponieważ jest tak wiele aspektów i tak wiele rzeczy, które naprawdę musimy wziąć pod uwagę i spojrzeć z architektury biznesowej. Nasze podejście polega na tym, aby naprawdę uczynić tę opartą na modelu i czerpać prawdziwą wartość z modeli, ponieważ można ich używać jako nośnika komunikacji, a także jako warstwy umożliwiającej działanie innych systemów. Niezależnie od tego, czy robisz architekturę zorientowaną na usługi, czy inne rzeczy, model naprawdę staje się siłą napędową tego, co się dzieje, z wszystkimi otaczającymi go metadanymi i danymi, które masz w swojej firmie.
To, o czym chcę porozmawiać, to prawie cofnięcie się o krok, ponieważ Malcolm poruszył część historii ewolucji rozwiązań i tego typu rzeczy. Jednym ze sposobów, aby naprawdę wskazać, jak ważne jest posiadanie solidnej architektury danych, jest przypadek użycia, w którym często się spotykałem, kiedy konsultowałem się, zanim zacząłem pełnić funkcję zarządzania produktem, i to znaczy, że wchodziłem do organizacji niezależnie od tego, czy przeprowadzali transformację biznesu, czy tylko zastępowali niektóre istniejące systemy i tego typu rzeczy, i bardzo szybko stało się jasne, jak słabo organizacje rozumieją własne dane. Jeśli weźmiesz konkretny przypadek użycia, taki jak ten, niezależnie od tego, czy jesteś konsultantem, czy może jest to osoba, która właśnie rozpoczęła działalność w organizacji, lub twoja organizacja została rozbudowana przez lata dzięki przejmowaniu różnych firm, co kończysz bardzo szybko powstaje bardzo złożone środowisko z wieloma nowymi technologiami, a także starszymi technologiami, rozwiązaniami ERP i wszystkim innym.
Jedną z rzeczy, które możemy naprawdę zrobić dzięki naszemu podejściu do modelowania, jest odpowiedź na pytanie, jak mam to wszystko zrozumieć? Naprawdę możemy zacząć gromadzić informacje, aby firma mogła właściwie wykorzystać posiadane informacje. I wychodzi na to, co mamy w tych środowiskach? Jak mogę wykorzystać modele, aby uzyskać potrzebne informacje i lepiej je zrozumieć? A potem mamy tradycyjne typy metadanych dla wszystkich różnych rzeczy, takich jak relacyjne modele danych, i jesteśmy przyzwyczajeni do przeglądania rzeczy takich jak definicje i słowniki danych, no wiesz, typy danych i tego typu rzeczy. Ale co z dodatkowymi metadanymi, które chcesz przechwycić, aby naprawdę nadać im jeszcze więcej znaczenia? Na przykład, które jednostki są tak naprawdę kandydatami, które powinny być referencyjnymi obiektami danych, które powinny być głównymi obiektami zarządzania danymi i tego rodzaju rzeczami i powiązać je ze sobą. Jak przepływają informacje przez organizację? Dane płyną z tego, w jaki sposób są wykorzystywane zarówno z punktu widzenia procesu, jak i linii danych pod względem podróży informacji przez nasze firmy i sposobu, w jaki przechodzą one przez różne systemy lub przez magazyny danych, więc wiemy kiedy budujemy rozwiązania I lub tego typu rzeczy, to tak naprawdę zużywamy właściwe informacje do danego zadania.
A następnie bardzo ważne jest, w jaki sposób możemy zmusić wszystkie zainteresowane strony do współpracy, a szczególnie interesariuszy biznesowych, ponieważ to oni dają nam prawdziwe znaczenie tego, czym są te dane. Ostatecznie firma jest właścicielem danych. Podają definicje słowników i rzeczy, o których mówił Eric, więc potrzebujemy miejsca, żeby to wszystko połączyć. Sposób, w jaki to robimy, polega na modelowaniu danych i architekturze repozytorium danych.
Poruszę kilka rzeczy. Będę mówić o ER / Studio Enterprise Team Edition. Przede wszystkim zamierzam mówić o produkcie architektury danych, w którym wykonujemy modelowanie danych i tego typu rzeczy, ale istnieje wiele innych składników pakietu, o których zamierzam krótko się wspomnieć. Zobaczysz jeden fragment Architekta biznesowego, w którym możemy tworzyć modele koncepcyjne, ale możemy także tworzyć modele procesów biznesowych i możemy łączyć te modele procesów, aby połączyć rzeczywiste dane, które mamy w naszych modelach danych. Naprawdę pomaga nam to połączyć. Software Architect pozwala nam wykonywać dodatkowe konstrukcje, takie jak niektóre modelowanie UML i tego typu rzeczy, aby nadać logikę pomocniczą niektórym innym systemom i procesom, o których mówimy. Ale bardzo ważne, gdy schodzimy w dół, mamy repozytorium i serwer zespołu, i powiem o tym jako o dwóch połówkach tego samego. W repozytorium przechowujemy wszystkie modelowane metadane, a także wszystkie metadane biznesowe w zakresie glosariuszy biznesowych i terminów. A ponieważ mamy to środowisko oparte na repozytorium, możemy następnie połączyć wszystkie te różne rzeczy razem w tym samym środowisku, a następnie możemy faktycznie udostępnić je do konsumpcji, nie tylko pracownikom technicznym, ale także biznesmenom. I tak naprawdę zaczynamy napędzać współpracę.
A potem ostatni kawałek, o którym krótko porozmawiam, kiedy wchodzisz do tych środowisk, to nie tylko bazy danych, które tam masz. Będziesz miał wiele baz danych, magazynów danych, a także wiele, jak to nazwałbym, starszych artefaktów. Może ludzie używali Visio lub innych diagramów do mapowania niektórych rzeczy. Może mieli inne narzędzia do modelowania i tego typu rzeczy. Tak więc, co możemy zrobić z MetaWizard, to faktycznie wyodrębnić niektóre z tych informacji i wprowadzić je do naszych modeli, sprawić, by były aktualne i móc z nich korzystać, zużywać je ponownie w aktualny sposób, zamiast po prostu usiąść. Staje się teraz aktywną częścią naszych działających modeli, co jest bardzo ważne.
Kiedy wchodzisz do organizacji, jak powiedziałem, istnieje wiele różnych systemów, wiele rozwiązań ERP, niedopasowane rozwiązania departamentalne. Wiele organizacji korzysta również z rozwiązań SaaS, które są również zewnętrznie kontrolowane i zarządzane, więc nie kontrolujemy baz danych i tego typu rzeczy na hostach na nich, ale nadal musimy wiedzieć, jak te dane wyglądają i oczywiście otaczające go metadane. Odkryliśmy także wiele przestarzałych, starszych systemów, które nie zostały oczyszczone z powodu podejścia opartego na projektach, o którym mówił Malcolm. To zadziwiające, jak w ostatnich latach organizacje rozbijają projekty, zastępują system lub rozwiązanie, ale często nie ma wystarczającego budżetu projektu na wycofanie przestarzałych rozwiązań, więc teraz są po prostu przeszkodą. I musimy dowiedzieć się, czego właściwie możemy się pozbyć w naszym środowisku, a także co jest przydatne w przyszłości. I to wiąże się ze słabą strategią wycofania z eksploatacji. To nieodłączna część tej samej rzeczy.
Co więcej, odkrywamy, że wiele organizacji zbudowało się z tych różnych rozwiązań, to widzimy wiele interfejsów punkt-punkt z dużą ilością danych poruszających się w wielu miejscach. Musimy być w stanie to zracjonalizować i ustalić linię danych, o której krótko wspomniałem wcześniej, abyśmy mogli mieć bardziej spójną strategię, taką jak wykorzystanie architektury zorientowanej na usługi, magistrale usług dla przedsiębiorstw i tego typu rzeczy, w celu dostarczenia prawidłowych informacji do typu publikowania i subskrybowania modelu, którego używamy poprawnie w całej naszej działalności. A potem, oczywiście, nadal musimy przeprowadzić pewien rodzaj analizy, bez względu na to, czy korzystamy z hurtowni danych, centrów danych z tradycyjnym ETL, czy korzystamy z niektórych nowych jezior danych. Wszystko sprowadza się do tego samego. To wszystkie dane, czy to duże zbiory danych, czy tradycyjne dane w relacyjnych bazach danych, musimy zgromadzić wszystkie te dane, abyśmy mogli nimi zarządzać i wiedzieć, z czym mamy do czynienia w naszych modelach.
Ponownie, złożoność, którą będziemy robić, polega na tym, że musimy wykonać kilka kroków. Przede wszystkim wchodzisz i możesz nie mieć tych planów tego krajobrazu informacyjnego. W narzędziu do modelowania danych, takim jak ER / Studio Data Architect, najpierw będziesz robił dużo inżynierii odwrotnej, jeśli chodzi o wskazanie źródeł danych, które znajdują się tam, włączenie ich, a następnie połączenie ich w bardziej reprezentatywne modele reprezentujące cały biznes. Ważne jest to, że chcemy mieć możliwość dekomponowania tych modeli również zgodnie z liniami biznesowymi, abyśmy mogli odnosić się do nich w mniejszych częściach, do których nasi ludzie biznesu mogą się odnosić, oraz nasi analitycy biznesowi i inni interesariusze, którzy pracują na tym.
Standardy nazewnictwa są niezwykle ważne i mówię o tym na kilka różnych sposobów. Standardy nazewnictwa pod względem tego, jak nazywamy rzeczy w naszych modelach. Jest to dość łatwe w logicznych modelach, w których mamy dobrą konwencję nazewnictwa i dobry słownik danych dla naszych modeli, ale także widzimy różne konwencje nazewnictwa dla wielu modeli fizycznych, które wprowadzamy. Kiedy inżynier odwrotny, dość często widzimy skrócone nazwy i tego rodzaju rzeczy, o których będę mówić. Musimy przetłumaczyć je z powrotem na znaczące angielskie nazwy, które mają znaczenie dla firmy, abyśmy mogli zrozumieć, jakie są te wszystkie dane, które mamy w środowisku. A potem uniwersalne mapowania to sposób ich łączenia.
Ponadto dokumentujemy i definiujemy dalej, i tam możemy dalej klasyfikować nasze dane za pomocą czegoś o nazwie Załączniki, na których pokażę ci kilka slajdów. A następnie zamykając pętlę, chcemy zastosować to znaczenie biznesowe, czyli tam, gdzie łączymy nasze glosariusze biznesowe i możemy łączyć je z różnymi modelowymi artefaktami, więc wiemy, kiedy mówimy o pewnym znaczeniu biznesowym, gdzie to jest wdrożone w naszych danych w całej organizacji. I wreszcie, już mówiłem o tym, że wszystko to musi być repozytorium oparte na wielu możliwościach współpracy i publikowania, aby nasi interesariusze mogli z niego skorzystać. Opowiem o inżynierii odwrotnej dość szybko. Już w pewnym sensie bardzo szybko wam to podkreśliłem. Pokażę ci to w prawdziwym demo, aby pokazać ci niektóre rzeczy, które możemy tam wprowadzić.
I chcę porozmawiać o niektórych różnych typach modeli i diagramach, które stworzylibyśmy w tego typu scenariuszu. Oczywiście modele koncepcyjne będziemy robić w wielu przypadkach; Nie zamierzam poświęcać temu dużo czasu. Naprawdę chcę porozmawiać o modelach logicznych, modelach fizycznych i specjalistycznych typach modeli, które możemy stworzyć. Ważne jest, abyśmy mogli stworzyć je wszystkie na tej samej platformie do modelowania, abyśmy mogli połączyć je ze sobą. Dotyczy to modeli wymiarowych, a także modeli, które wykorzystują niektóre nowe źródła danych, takie jak NoSQL, które ci pokażę. A potem, jak wygląda model linii danych? I w jaki sposób połączymy te dane w model procesu biznesowego, o tym będziemy mówić w następnej kolejności.
Przejdę teraz do środowiska modelowania, aby dać ci bardzo szybki i szybki przegląd. I wierzę, że powinieneś teraz widzieć mój ekran. Przede wszystkim chcę porozmawiać o tradycyjnym modelu danych. Sposób, w jaki chcemy organizować modele, kiedy je wprowadzamy, polega na tym, że możemy je rozkładać. Więc po lewej stronie widzimy, że w tym konkretnym pliku modelu mamy modele logiczne i fizyczne. Następną rzeczą jest to, że możemy to rozbić wzdłuż dekompozycji biznesowych, dlatego właśnie widzisz foldery. Jasnoniebieskie to modele logiczne, a zielone to modele fizyczne. Możemy również przeprowadzić drążenie w dół, więc w ER / Studio, jeśli masz dekompozycję biznesową, możesz przejść tyle poziomów głębokich lub podmodeli, ile chcesz, a zmiany, które wprowadzasz na niższych poziomach, automatycznie odzwierciedlają się na wyższych poziomy. Dzięki temu staje się bardzo wydajnym środowiskiem modelowania bardzo szybko.
Chciałbym również podkreślić, że bardzo ważne jest, aby zacząć zbierać te informacje razem, ponieważ możemy mieć wiele modeli fizycznych, które odpowiadają również jednemu modelowi logicznemu. Dość często możesz mieć model logiczny, ale możesz mieć modele fizyczne na różnych platformach i tego typu rzeczy. Być może jest to instancja SQL Server, może inna to Oracle. Mamy możliwość powiązania tego wszystkiego w tym samym środowisku modelowania. I znowu to, co tu mam, to rzeczywisty model hurtowni danych, który znowu może być w tym samym środowisku modelowania lub możemy go mieć w repozytorium i łączyć w różne rzeczy.
To, co naprawdę chciałem wam pokazać, to niektóre inne rzeczy i inne warianty modeli, w które wchodzimy. Kiedy więc wchodzimy w tradycyjny model danych, taki jak ten, jesteśmy przyzwyczajeni do oglądania typowych bytów z kolumnami, metadanymi i tego typu rzeczami, ale ten punkt widzenia zmienia się bardzo szybko, kiedy zaczynamy zajmować się niektórymi z tych nowszych technologii NoSQL lub, jak niektórzy ludzie nadal nazywają je, technologie dużych zbiorów danych.
Powiedzmy teraz, że mamy również Hive w naszym środowisku. Jeśli odwrócimy inżynierię ze środowiska Hive - i będziemy mogli przesyłać dalej i wstecz inżynier z Hive za pomocą tego samego narzędzia do modelowania - zobaczymy coś nieco innego. Nadal widzimy tam wszystkie dane jako konstrukcje, ale nasz TDL jest inny. Ci z was, którzy są przyzwyczajeni do widzenia SQL, zobaczą Hive QL, który jest bardzo podobny do SQL, ale z tego samego narzędzia możesz teraz rozpocząć pracę z różnymi językami skryptowymi. Możesz więc modelować w tym środowisku, generować je w środowisku Hive, ale równie ważne jest to, że w opisanym przeze mnie scenariuszu możesz dokonać inżynierii wstecznej i zrozumieć to wszystko, a także rozpocząć łączenie .
Weźmy inny, który jest trochę inny. MongoDB to kolejna platforma, którą wspieramy natywnie. A kiedy zaczniesz wchodzić w środowiska typu JSON, w których masz magazyny dokumentów, JSON jest innym zwierzęciem i są w tym konstrukcje, które nie odpowiadają modelom relacyjnym. Wkrótce zaczniesz zajmować się pojęciami takimi jak obiekty osadzone i tablice obiektów, gdy zaczniesz przesłuchiwać JSON, a te pojęcia nie istnieją w tradycyjnej notacji relacyjnej. To, co zrobiliśmy tutaj, to faktyczne rozszerzenie notacji i naszego katalogu, aby móc obsłużyć to w tym samym środowisku.
Jeśli spojrzysz tutaj po lewej stronie, zamiast zobaczyć rzeczy takie jak encje i tabele, nazywamy je obiektami. I widzisz różne notacje. Nadal widać tutaj typowe oznaczenia referencyjne, ale te niebieskie elementy, które pokazuję na tym konkretnym diagramie, są w rzeczywistości obiektami osadzonymi. I pokazujemy różne liczności. Diamentowa liczność oznacza, że jest to obiekt z jednej strony, ale liczność z jednego oznacza, że mamy w wydawcy, jeśli podążamy za tą relacją, mamy osadzony obiekt adresu. Podczas przesłuchiwania JSON odkryliśmy, że dokładnie taka sama struktura obiektów jest osadzona w patronie, ale tak naprawdę jest osadzona jako tablica obiektów. Widzimy to, nie tylko przez same łączniki, ale jeśli spojrzysz na rzeczywiste byty, zobaczysz, że widzisz adresy pod patronem, co również klasyfikuje je jako tablicę obiektów. Otrzymujesz bardzo opisowy punkt widzenia, w jaki sposób możesz to wprowadzić.
I znowu, teraz, co widzieliśmy do tej pory w ciągu zaledwie kilku sekund, to tradycyjne modele relacyjne, które są wielopoziomowe, możemy zrobić to samo z Hive, możemy zrobić to samo z MongoDB i innymi źródłami dużych danych, jak dobrze. Co możemy również zrobić, i pokażę wam to bardzo szybko, mówiłem o tym, że sprowadziłem rzeczy z innych obszarów. Zakładam, że zaimportuję model z bazy danych lub poddam go inżynierii wstecznej, ale wprowadzę go z zewnętrznych metadanych. Po prostu, aby dać ci bardzo szybki pogląd na wszystkie rodzaje rzeczy, które możemy zacząć wprowadzać.
Jak widać, mamy niezliczoną ilość rzeczy, z którymi możemy przenieść metadane do naszego środowiska modelowania. Zaczynając od rzeczy takich jak Amazon Redshift, Cassandra, wiele innych platform big data, więc wiele z nich wymienionych. To jest w kolejności alfabetycznej. Widzimy wiele źródeł dużych zbiorów danych i tego typu rzeczy. Widzimy także wiele tradycyjnych lub starszych środowisk modelowania, w których możemy faktycznie przenosić te metadane. Jeśli przejdę tutaj - i nie zamierzam spędzać czasu na każdym z nich - widzimy wiele różnych rzeczy, z których możemy to sprowadzić, jeśli chodzi o platformy do modelowania i platformy danych. I coś, co jest bardzo ważne, aby to tutaj zrozumieć, to kolejna część, którą możemy zrobić, gdy zaczynamy mówić o linii danych, w Enterprise Team Edition możemy również przesłuchiwać źródła ETL, czy to na przykład mapowania Talend lub SQL Server Information Services, możemy faktycznie, włącz to, aby uruchomić również nasze diagramy linii danych i narysuj obraz tego, co dzieje się w tych transformacjach. Łącznie po wyjęciu z pudełka mamy ponad 130 różnych mostów, które faktycznie są częścią produktu Enterprise Team Edition, więc naprawdę pomaga nam bardzo szybko zebrać wszystkie artefakty w jedno środowisko modelowania.
Na koniec chcę również porozmawiać o tym, że nie możemy stracić z oczu faktu, że potrzebujemy innych typów konstrukcji, jeśli zajmujemy się hurtownią danych lub wszelkiego rodzaju analizami. Nadal chcemy mieć możliwość robienia takich rzeczy, jak modele wymiarowe, w których mamy tabele faktów, a także wymiary i tego rodzaju rzeczy. Chcę również pokazać, że możemy również rozszerzyć nasze metadane, które pomogą nam kategoryzować rodzaje wymiarów i wszystko inne. Więc jeśli spojrzę na kartę danych wymiarowych tutaj, na przykład na jednym z nich, faktycznie automatycznie wykryje, na podstawie wzorca modelu, który widzi, i poda punkt wyjścia, czy uważa, że jest to wymiar, czy tabela faktów. Ale poza tym, co możemy zrobić, mieści się w obrębie wymiarów i tego rodzaju rzeczy mamy nawet różne rodzaje wymiarów, których możemy użyć do klasyfikacji danych w środowisku typu hurtowni danych. Tak potężne możliwości, że łączymy to razem.
Wskoczę do tego, ponieważ jestem teraz w środowisku demonstracyjnym i pokażę ci kilka innych rzeczy, zanim wrócę do slajdów. Jedną z rzeczy, które ostatnio dodaliśmy do ER / Studio Data Architect jest to, że natrafiliśmy na sytuacje - i jest to bardzo częsty przypadek użycia podczas pracy nad projektami - programiści myślą w kategoriach obiektów, podczas gdy nasze dane modelerzy zwykle myślą w kategoriach tabel i encji oraz tego rodzaju rzeczy. Jest to bardzo uproszczony model danych, ale reprezentuje kilka podstawowych pojęć, w których programiści, a nawet analitycy biznesowi lub użytkownicy biznesowi, mogą myśleć o nich jako o różnych obiektach lub koncepcjach biznesowych. Do tej pory bardzo trudno było je sklasyfikować, ale to, co faktycznie zrobiliśmy w ER / Studio Enterprise Team Edition, w wersji 2016, to teraz mamy koncepcję o nazwie Business Data Objects. Pozwala nam to na enkapsulację grup jednostek lub tabel w prawdziwe obiekty biznesowe.
Na przykład w tym nowym widoku mamy nagłówek Zamówienia i Linia Zamówienia zostały teraz zebrane razem, są one enkapsulowane jako obiekt, myślimy o nich jako o jednostce pracy, gdy zachowamy dane i łączymy je ze sobą, więc teraz bardzo łatwo jest powiązać to z różnymi odbiorcami. Można je ponownie wykorzystywać w całym środowisku modelowania. To prawdziwy obiekt, nie tylko konstrukcja rysunkowa, ale mamy także tę dodatkową zaletę, że kiedy faktycznie komunikujemy się z perspektywy modelowania, możemy je selektywnie zwinąć lub rozwinąć, abyśmy mogli stworzyć podsumowany widok dialogów z niektórymi odbiorcami, i możemy oczywiście zachować bardziej szczegółowy widok, tak jakbyśmy widzieli więcej technicznych odbiorców. To naprawdę daje nam naprawdę dobry środek komunikacji. To, co widzimy teraz, łączy wiele różnych typów modeli, rozszerzając je o koncepcję obiektów danych biznesowych, a teraz zamierzam porozmawiać o tym, w jaki sposób rzeczywiście nadamy więcej znaczenia tym typom rzeczy i jak je łączymy w naszym ogólne środowiska.
Po prostu próbuję znaleźć moją WebEx tutaj, aby móc to zrobić. I wracamy do slajdów Hot Tech. Chciałbym tylko przewinąć kilka slajdów tutaj, ponieważ już je widzieliście w pokazie modelu. Chcę bardzo szybko porozmawiać o standardach nazewnictwa. Chcemy stosować i egzekwować różne standardy nazewnictwa. Chcemy, abyśmy mogli faktycznie przechowywać szablony standardów nazewnictwa w naszych repozytoriach, aby w zasadzie budować to znaczenie poprzez słowa, frazy, a nawet skróty i przywiązywać je do znaczącego angielskiego słowa. Użyjemy terminów biznesowych, skrótów dla każdego z nich, i możemy określić kolejność, przypadki oraz dodawać prefiksy i sufiksy. Typowy przypadek użycia tego jest zwykle wtedy, gdy ludzie budują model logiczny, a następnie faktycznie idą naprzód, aby stworzyć model fizyczny, w którym mogliby używać skrótów i wszystkiego innego.
Piękną rzeczą jest to, że jest tak samo potężny, jeszcze potężniejszy w odwrotnym kierunku, jeśli możemy po prostu powiedzieć, jakie były niektóre z tych standardów nazewnictwa w niektórych fizycznych bazach danych, które poddaliśmy inżynierii wstecznej, możemy wziąć te skróty, zmienić je w dłuższe słowa i przybliż je do angielskich zwrotów. W rzeczywistości możemy teraz uzyskać odpowiednie nazwy dla tego, jak wyglądają nasze dane. Jak mówię, typowym przypadkiem użycia jest przejście do przodu, logiczne do fizycznego i mapowanie magazynów danych i tego typu rzeczy. Jeśli spojrzysz na zrzut ekranu po prawej stronie, zobaczysz, że istnieją nazwy skrócone z nazw źródeł, a kiedy zastosowaliśmy szablon standardów nazewnictwa, w rzeczywistości mamy więcej pełnych nazw. I możemy wstawić spacje i tak dalej, jeśli chcemy, w zależności od użytego szablonu standardów nazewnictwa. Możemy sprawić, że będzie wyglądać, ale chcemy, aby wyglądał tak, jak w naszych modelach. Dopiero gdy wiemy, jak coś się nazywa, możemy zacząć do niego dołączać definicje, ponieważ jeśli nie wiemy, co to jest, jak możemy nadać temu sens?
Fajną rzeczą jest to, że możemy wywoływać to, kiedy robimy różne rzeczy. Mówiłem o inżynierii odwrotnej, możemy faktycznie przywoływać szablony standardów nazewnictwa podczas wykonywania inżynierii odwrotnej. Tak więc w jednym zestawie kroków kreatora jesteśmy w stanie zrobić, jeśli wiemy, jakie są konwencje, możemy odwrócić inżynierię fizycznej bazy danych, przywróci ją jako modele fizyczne w środowisku modelowania i jest to zastosuję również te konwencje nazewnictwa. Zobaczymy więc, jakie są angielskie reprezentacje nazw w odpowiednim modelu logicznym w środowisku. Możemy to również zrobić i połączyć z generowaniem schematu XML, abyśmy mogli wziąć model, a nawet wypchnąć go za pomocą naszych skrótów, niezależnie od tego, czy robimy frameworki SOA, czy tego typu rzeczy, dzięki czemu możemy również wypierać różne konwencje nazewnictwa które faktycznie zapisaliśmy w samym modelu. Daje nam wiele bardzo potężnych możliwości.
Ponownie, oto przykład, jak by to wyglądało, gdybym miał szablon. Ten faktycznie pokazuje, że miałem EMP dla „pracownika”, SAL dla „pensji”, PLN dla „planu” w konwencji standardów nazewnictwa. Mogę również zastosować je, aby działały interaktywnie, gdy buduję modele i wprowadzam różne elementy. Gdybym używał tego skrótu i wpisałbym „Plan wynagrodzeń pracowników” w nazwie jednostki, działałby z szablonem standardów nazewnictwa Zdefiniowałem tutaj, dałoby mi to EMP_SAL_PLN, ponieważ tworzyłem byty i nadało mi odpowiednie fizyczne nazwy od razu.
Ponownie, bardzo dobrze, gdy projektujemy i rozwijamy również inżynierię. Mamy bardzo unikalną koncepcję i właśnie tam zaczynamy naprawdę łączyć te środowiska. I nazywa się to Universal Mappings. Po wprowadzeniu wszystkich tych modeli do naszego środowiska, co jesteśmy w stanie zrobić, zakładając, że zastosowaliśmy te konwencje nazewnictwa i są łatwe do znalezienia, możemy teraz użyć konstrukcji o nazwie Universal Mappings w ER /Studio. Możemy łączyć jednostki między modelami. Gdziekolwiek widzimy „klienta” - prawdopodobnie będziemy mieli „klienta” w wielu różnych systemach i wielu różnych bazach danych - możemy zacząć łączyć je wszystkie, aby podczas pracy z nim w jednym modelu widać, gdzie są przejawy klientów w innych modelach. A ponieważ mamy reprezentującą to warstwę modelu, możemy nawet powiązać ją ze źródłami danych i sprowadzić do naszych zapytań, w których bazach danych te również się znajdują. To naprawdę daje nam możliwość bardzo spójnego powiązania tego wszystkiego.
Pokazałem ci obiekty danych biznesowych. Chcę też bardzo szybko porozmawiać o rozszerzeniach metadanych, które nazywamy załącznikami. Dzięki temu możemy tworzyć dodatkowe metadane dla naszych obiektów modelu. Dość często konfigurowałem tego rodzaju właściwości, aby wyprzeć wiele różnych rzeczy z punktu widzenia zarządzania danymi i jakości danych, a także aby pomóc nam w zarządzaniu danymi głównymi i zasadach przechowywania danych. Podstawową ideą jest tworzenie tych klasyfikacji i dołączanie ich w dowolnym miejscu, na poziomie tabeli, na poziomie kolumny, tego typu rzeczy. Najczęstszym przypadkiem użycia jest oczywiście to, że encje są tabelami, a następnie mogę zdefiniować: jakie są moje obiekty danych podstawowych, jakie są moje tabele referencyjne, jakie są moje tabele transakcyjne? Z punktu widzenia jakości danych mogę dokonywać klasyfikacji pod względem ważności dla firmy, abyśmy mogli nadać priorytet działaniom związanym z czyszczeniem danych i tego rodzaju rzeczami.
Często pomijane jest to, jakie są zasady przechowywania różnych typów danych w naszej organizacji? Możemy je skonfigurować i faktycznie dołączyć do różnego rodzaju artefaktów informacyjnych w naszym środowisku modelowania i oczywiście również w naszym repozytorium. Piękno polega na tym, że załączniki te znajdują się w naszym słowniku danych, więc kiedy korzystamy ze słowników danych przedsiębiorstwa w środowisku, możemy dołączyć je do wielu modeli. Musimy je zdefiniować tylko raz i możemy wykorzystywać je wielokrotnie w różnych modelach w naszym środowisku. To tylko krótki zrzut ekranu pokazujący, że możesz właściwie określić, kiedy robisz załącznik, do jakich elementów chcesz go dołączyć. A ten przykład tutaj jest w rzeczywistości listą wartości, więc kiedy wchodzą, możesz wybierać z listy wartości, masz dużą kontrolę w środowisku modelowania, co jest wybierane, a nawet możesz ustawić domyślne wartość jest, jeśli wartość nie zostanie wybrana. Jest tam więc dużo mocy. Żyją w słowniku danych.
Coś, co chcę pokazać nieco dalej na tym ekranie, dodatkowo w górnej części są wyświetlane załączniki, a pod nimi informacje o bezpieczeństwie danych. Możemy również zastosować zasady bezpieczeństwa danych do różnych informacji w środowisku. W przypadku różnych mapowań zgodności, klasyfikacji bezpieczeństwa danych, wysyłamy kilka z nich po wyjęciu z pudełka, które możesz po prostu wygenerować i rozpocząć korzystanie, ale możesz również zdefiniować własne mapowania zgodności i standardy. Niezależnie od tego, czy robisz HIPAA, czy jakąkolwiek inną inicjatywę. I naprawdę możesz zacząć budować ten bardzo bogaty zestaw metadanych w swoim środowisku.
A potem Glosariusz i Warunki - tutaj wiąże się znaczenie biznesu. Często mamy słowniki danych, które dość często są używane przez organizację jako punkt wyjścia do opracowania słowników, ale terminologia i słownictwo często bardzo techniczny. Możemy więc, jeśli chcemy, wykorzystać je jako punkt wyjścia do opracowania glosariuszy, ale naprawdę chcemy, aby firma była ich właścicielem. To, co zrobiliśmy w środowisku serwera zespołu, polega na tym, że daliśmy ludziom możliwość tworzenia definicji biznesowych, a następnie możemy połączyć je z różnymi artefaktami modelu, które odpowiadają również w środowisku modelowania. Zdajemy sobie również sprawę z tego, co zostało omówione wcześniej, a mianowicie, im więcej ludzi piszesz, tym większy jest potencjał błędu ludzkiego. To, co robimy również w naszej strukturze glosariusza, to po pierwsze, wspieramy hierarchię glosariusza, dzięki czemu możemy mieć różne typy glosariuszy lub różne rodzaje rzeczy w organizacji, ale równie ważne jest, jeśli masz już niektóre z tych źródeł tam, gdzie są zdefiniowane warunki i wszystko, możemy faktycznie zaimportować plik CSV, aby pobrać je do naszego środowiska modelowania oraz serwera naszego zespołu lub naszego glosariusza, a następnie rozpocząć łączenie. I za każdym razem, gdy coś się zmienia, jest pełna ścieżka audytu tego, co były przed i po zdjęciach, pod względem definicji i wszystkiego innego, a to, co zobaczysz w najbliższej przyszłości, jest również bardziej obiegiem autoryzacji dzięki czemu możemy naprawdę kontrolować, kto jest za to odpowiedzialny, zatwierdzenia przez komitety lub osoby fizyczne i tego rodzaju rzeczy, aby proces zarządzania był jeszcze bardziej niezawodny w miarę postępów.
To samo dotyczy nas, gdy mamy te terminy w słowniku w naszym glosariuszu serwera zespołu, jest to przykład edycji w encji w samym modelu, który tu przywołałem. Być może mają one powiązane terminy, ale to, co robimy, to także, jeśli w słowniku znajdują się słowa, które pojawiają się w notatkach lub opisach tego, co mamy tutaj, w naszych bytach, są one automatycznie wyświetlane w jaśniejszym, hiperłączonym kolorze, a jeśli najedź myszką na nich, możemy również zobaczyć definicję ze słownika biznesowego. Daje nam nawet bogatsze informacje, gdy konsumujemy same informacje, wraz ze wszystkimi dostępnymi terminami z glosariusza. To naprawdę pomaga wzbogacić doświadczenie i nadać znaczenie wszystkim, z którymi pracujemy.
To znowu był bardzo szybki przelot. Oczywiście moglibyśmy spędzać nad tym dni, zagłębiając się w różne części, ale jest to bardzo szybki przelot nad powierzchnią. Naprawdę staramy się zrozumieć, jak wyglądają te złożone środowiska danych. Chcemy poprawić widoczność wszystkich tych artefaktów danych i współpracować przy ich realizacji za pomocą ER / Studio. Chcemy umożliwić bardziej wydajne i zautomatyzowane modelowanie danych. I to są wszystkie rodzaje danych, o których mówimy, niezależnie od tego, czy są to duże zbiory danych, tradycyjne dane relacyjne, magazyny dokumentów czy cokolwiek innego. I znowu osiągnęliśmy to, ponieważ mamy potężne możliwości inżynierii do przodu i do tyłu dla różnych platform i innych narzędzi, które możesz tam mieć. Chodzi o dzielenie się i komunikowanie w całej organizacji ze wszystkimi zaangażowanymi interesariuszami. To tutaj stosujemy znaczenie poprzez standardy nazewnictwa. Następnie stosujemy definicje za pomocą naszych glosariuszy biznesowych. Następnie możemy przeprowadzić dalsze klasyfikacje dla wszystkich naszych innych możliwości zarządzania za pomocą rozszerzeń metadanych, takich jak rozszerzenia jakości danych, klasyfikacje do zarządzania danymi podstawowymi lub wszelkie inne rodzaje klasyfikacji, które chcesz zastosować do tych danych. Następnie możemy dalej podsumować i jeszcze bardziej usprawnić komunikację z obiektami danych biznesowych, z różnymi odbiorcami interesariuszy, szczególnie między projektantami i programistami.
I znowu, najważniejsze w tym wszystkim jest zintegrowane repozytorium z bardzo solidnymi możliwościami zarządzania zmianami. Nie miałem czasu tego dzisiaj pokazywać, ponieważ robi się dość skomplikowany, ale repozytorium ma bardzo solidne możliwości zarządzania zmianami i ścieżki audytu. Możesz robić nazwane wersje, możesz tworzyć nazwane wersje, a my mamy również możliwość dla tych z was, którzy wykonują zarządzanie zmianami, możemy powiązać to z twoimi zadaniami. Dzisiaj możemy wprowadzać zadania i kojarzyć zmiany modelu z zadaniami, tak jak programiści kojarzą zmiany kodu z zadaniami lub historiami użytkowników, z którymi również pracują.
To był bardzo szybki przegląd. Mam nadzieję, że to wystarczyło, aby pobudzić apetyt, abyśmy mogli podjąć o wiele głębsze rozmowy na temat podziału niektórych z tych tematów w przyszłości. Dziękuję za poświęcony czas i do ciebie, Rebecca.
Rebecca Jóźwiak: Dzięki, Ron, to było fantastyczne i mam sporo pytań od publiczności, ale chcę dać naszym analitykom szansę zatopienia zębów w tym, co powiedziałeś. Eric, zamierzam iść naprzód i być może, jeśli chcesz zająć się tym slajdem lub innym, dlaczego nie pierwszy? Lub jakiekolwiek inne pytanie.
Eric Little: Jasne. Przepraszam, jakie było pytanie, Rebecca? Chcesz, żebym zapytał o coś konkretnego lub…?
Rebecca Jóźwiak: Wiem, że początkowo miałeś pytania do Rona. Jeśli chcesz teraz poprosić go, aby zajął się którymkolwiek z nich, niektórymi z nich ze slajdu lub czymkolwiek innym, co wzbudziło twoje zainteresowanie, o które chcesz zapytać? O funkcjach modelowania IDERA.
Eric Little: Tak, więc jedną z rzeczy, Ron, więc jak się macie, wygląda na to, że diagramy, które pokazaliście, są ogólnymi rodzajami diagramów relacji między bytami, które normalnie używalibyście w konstrukcji bazy danych, prawda?
Ron Huizenga: Tak, ogólnie rzecz biorąc, ale oczywiście mamy rozszerzone typy dla magazynów dokumentów i tego typu rzeczy. Różniliśmy się od zwykłego zapisu relacyjnego, dodaliśmy także dodatkowe zapisy dla innych sklepów.
Eric Little: Czy istnieje sposób, w jaki możecie wykorzystać typy modelowania oparte na grafie, więc istnieje sposób na integrację, na przykład załóżmy, że mam coś w rodzaju najwyższej ćwiartki, narzędzia kompozytora TopBraid lub zrobiłem coś w Protégé lub, jak wiadomo, faceci finansowi w FIBO, wykonują dużo pracy w zakresie semantyki, rzeczy RDF - czy istnieje sposób na wprowadzenie tego typu modelowania wykresu relacji między bytami w tym narzędziu i wykorzystanie to?
Ron Huizenga: Tak naprawdę sprawdzamy, jak radzić sobie z wykresami. Dzisiaj nie zajmujemy się jawnie bazami danych grafów i tego typu rzeczami, ale szukamy sposobów, aby to zrobić, aby rozszerzyć nasze metadane. Chodzi mi o to, że możemy teraz wprowadzać różne rzeczy za pomocą XML i tego typu rzeczy, jeśli możemy przynajmniej dokonać jakiegoś tłumaczenia XML, aby wprowadzić je jako punkt wyjścia. Ale szukamy bardziej eleganckich sposobów, aby to wprowadzić.
Pokazałem ci również listę mostów inżynierii odwrotnej, które tam mamy, więc zawsze szukamy rozszerzeń tych mostów również dla określonych platform. Ciągłe, ciągłe starania, jeśli ma to sens, zaczynają obejmować wiele nowych konstrukcji i różnych platform. Ale mogę powiedzieć, że zdecydowanie jesteśmy na czele. Rzeczy, które pokazałem na przykład w MongoDB i tego typu rzeczach, jesteśmy pierwszym dostawcą modelowania danych, który faktycznie zrobił to natywnie w naszym własnym produkcie.
Eric Little: Dobra, tak. Tak więc inne pytanie, które miałem dla ciebie, dotyczyło zarządzania i utrzymania - jak wtedy, gdy użyłeś tego przykładu, kiedy pokazałeś przykład osoby, która jest „pracownikiem”, uważam, że to było „ wynagrodzenie ”, a następnie masz„ plan ”, czy istnieje sposób, w jaki sposób zarządzasz, na przykład, różnymi rodzajami ludzi, którzy mogą mieć - załóżmy, że masz dużą architekturę, załóżmy, że masz duże przedsiębiorstwo i ludzie zaczynają zbierać rzeczy w tym narzędziu i masz tutaj jedną grupę, która ma słowo „pracownik” i jedną grupę, która ma słowo „pracownik”. Jedna osoba tutaj mówi „pensja”, a inna osoba mówi "gaża."
Jak pogodzicie się, zarządzacie i zarządzacie tego rodzaju rozróżnieniami? Ponieważ wiem, jak byśmy to zrobili w świecie grafów, wiesz, że używałbyś list synonimów lub powiedziałbyś, że jest jedna koncepcja i ma kilka atrybutów, lub możesz powiedzieć w modelu SKOS, że mam preferowaną etykietę i mam liczne alternatywne etykiety, których mogę użyć. Jak to robicie?
Ron Huizenga: Robimy to na kilka różnych sposobów, a przede wszystkim porozmawiajmy najpierw o terminologii. Jedną z rzeczy, które robimy, jest oczywiście to, że chcemy mieć zdefiniowane lub usankcjonowane warunki, a w glosariuszu biznesowym oczywiście jest to, gdzie chcemy. I zezwalamy również na linki do synonimów w słowniku biznesowym, więc możesz powiedzieć, oto mój termin, ale możesz także zdefiniować, jakie są wszystkie synonimy dla tych synonimów.
Ciekawą rzeczą jest to, że kiedy zaczynasz patrzeć na ten rozległy krajobraz danych z tymi wszystkimi różnymi systemami, które tam masz, nie możesz tak po prostu wyjść i zmienić odpowiednich tabel i tego typu rzeczy na odpowiadają temu standardowi nazewnictwa, ponieważ może to być pakiet, który kupiłeś, więc nie masz kontroli nad zmianą bazy danych lub czymkolwiek.
Oprócz tego, że moglibyśmy powiązać definicje glosariusza, moglibyśmy tam osiągnąć dzięki tym uniwersalnym mapowaniom, o których mówiłem, co byśmy zrobili, i rodzaj zalecanego podejścia, to mieć nadrzędny model logiczny, który określa, co te różne koncepcje biznesowe są tym, o których mówisz. Wiąż z nimi słowniczek biznesowy, a miłą rzeczą jest to, że masz już taką konstrukcję, która reprezentuje logiczny byt, możesz wtedy zacząć łączyć z tego logicznego bytu do wszystkich implementacji tego logicznego bytu w różne systemy.
Następnie, tam gdzie trzeba, możesz zobaczyć, och, „osoba” tutaj nazywa się w tym systemie „pracownikiem”. „Wynagrodzenie” tutaj nazywa się tutaj „płacą” w tym innym systemie. Ponieważ to zobaczysz, zobaczysz wszystkie ich różne przejawy, ponieważ połączyłeś je ze sobą.
Eric Little: Dobra, tak, rozumiem. W tym sensie, czy można bezpiecznie powiedzieć, że przypomina to niektóre podejścia obiektowe?
Ron Huizenga: Trochę. To trochę bardziej intensywne niż, jak sądzę, można powiedzieć. Mam na myśli, że możesz zastosować podejście polegające na ręcznym łączeniu i przeglądaniu oraz sprawdzaniu i wykonywaniu ich wszystkich. Jedyną rzeczą, o której tak naprawdę nie miałem okazji rozmawiać - ponieważ znowu mamy wiele możliwości - mamy także pełny interfejs automatyzacji w samym narzędziu Data Architect. I możliwość makr, która tak naprawdę jest językiem programowania w narzędziu. Możemy więc robić takie rzeczy, jak pisanie makr, wypuszczać je, przesłuchiwać i tworzyć dla ciebie linki. Używamy go do importowania i eksportowania informacji, możemy go używać do zmiany rzeczy lub dodawania atrybutów, zdarzeń opartych na samym modelu, lub możemy użyć go do uruchamiania w partiach, aby faktycznie wyjść i przesłuchać rzeczy i faktycznie zapełnić różne konstrukcje w Model. Istnieje więc pełny interfejs automatyzacji, z którego ludzie mogą również korzystać. A użycie uniwersalnych mapowań z nimi byłoby bardzo potężnym sposobem na zrobienie tego.
Rebecca Jóźwiak: OK, dzięki Ron i dzięki Ericowi. To były świetne pytania. Wiem, że trochę się spóźniamy, ale chciałbym dać Malcolmowi okazję, by zadał kilka pytań na swój sposób. Malcolm?
Malcolm Chisholm: Dzięki, Rebecca. Ron jest bardzo interesujący. Widzę tu wiele możliwości. Jednym z obszarów, które mnie bardzo interesują, powiedzmy, jeśli mamy projekt rozwoju, w jaki sposób modelista danych korzysta z tych możliwości i może współpracuje z analitykami biznesowymi, z profilerem danych, z analitykiem jakości danych, a także ze sponsorami biznesowymi, którzy ostatecznie będą odpowiedzialni za rzeczywiste wymagania informacyjne w projekcie. W jaki sposób modelowanie danych naprawdę, jak wiesz, sprawia, że projekt jest bardziej wydajny i wydajny dzięki możliwościom, na które patrzymy?
Ron Huizenga: Myślę, że jedną z pierwszych rzeczy, które musisz tam zrobić, jest modelowanie danych - i nie mam zamiaru wybierać niektórych modelarzy, ale i tak to zrobię - niektórzy ludzie nadal mają wrażenie, że modelarz danych to tak naprawdę rola typu strażnika, określamy, jak to działa, jesteśmy strażnikami, którzy upewniają się, że wszystko jest w porządku.
Teraz jest aspekt tego, że musisz upewnić się, że definiujesz solidną architekturę danych i wszystko inne. Ale ważniejsze jest to, że jako modeler danych - i znalazłem to całkiem oczywiste, kiedy konsultowałem - to musisz zostać facylitatorem, więc musisz zebrać tych ludzi.
To nie będzie już projekt, generowanie, budowanie baz danych - musisz być w stanie pracować z tymi wszystkimi różnymi grupami interesariuszy, robić rzeczy takie jak inżynieria wsteczna, importować informacje, mieć inni ludzie współpracują, czy to w glosariuszach, czy dokumentacji, i wszystko w tym stylu - i ułatwiajcie przeciąganie tego do repozytorium, łączenie pojęć w repozytorium i pracę z tymi ludźmi.
Tak naprawdę jest to bardziej środowisko współpracy, w którym nawet poprzez zdefiniowanie zadań lub nawet wątków dyskusji lub tego rodzaju rzeczy, które mamy na serwerze zespołu, ludzie mogą faktycznie współpracować, zadawać pytania i docierać do końcowych produktów końcowych potrzeba ich architektury danych i organizacji. Czy taka odpowiedź?
Malcolm Chisholm: Tak, zgadzam się. Wiesz, myślę, że umiejętność ułatwiania jest czymś, co jest bardzo pożądane w modelarzach danych. Zgadzam się, że nie zawsze to widzimy, ale myślę, że jest to konieczne i sugerowałbym, że czasami istnieje skłonność do pozostawania w twoim kącie podczas modelowania danych, ale naprawdę musisz tam być, współpracując z innymi grupami zainteresowanych stron lub po prostu nie rozumiesz środowiska danych, z którym masz do czynienia, i myślę, że w rezultacie model cierpi. Ale to tylko moja opinia.
Ron Huizenga: I jest to interesujące, ponieważ wspomniałeś wcześniej w swoim slajdzie o historii, w jaki sposób firmy odwracają się od IT, ponieważ nie dostarczają rozwiązań w odpowiednim czasie i tego typu rzeczy.
To bardzo interesujące, że w moich późniejszych konsultacjach, zanim zostałem menedżerem produktu, większość projektów, które wykonałem w ciągu ostatnich dwóch lat wcześniej, były sponsorowane przez biznes, gdzie to naprawdę był biznes, który je napędzał i architekci danych a modelerzy nie byli częścią IT. Byliśmy częścią grupy sponsorowanej przez biznes i byliśmy tam jako facylitatorzy pracujący z resztą zespołów projektowych.
Malcolm Chisholm: Myślę, że to bardzo interesujący punkt. Myślę, że zaczynamy dostrzegać zmianę w świecie biznesu, w którym firma pyta lub może myśli nie tyle, co robię, będąc procesem, ale zaczynają też myśleć o tym, jakie są dane z którymi pracuję, jakie są moje potrzeby w zakresie danych, z jakimi danymi mam do czynienia jako danymi oraz w jakim stopniu możemy uzyskać produkty i możliwości IDERA wspierające ten punkt widzenia, i myślę, że potrzeby firmy, nawet choć to wciąż trochę rodzi się.
Ron Huizenga: Zgadzam się z tobą i myślę, że widzimy, że dzieje się to coraz bardziej. Widzieliśmy przebudzenie, a ty poruszyłeś go wcześniej pod względem znaczenia danych. Widzieliśmy znaczenie danych na wczesnym etapie w informatyce lub w ewolucji baz danych, a potem, jak pan mówi, w pewnym sensie weszliśmy w ten cały cykl zarządzania procesami - i proces jest niezwykle ważny, nie zrozumcie mnie źle - ale teraz, co się stało kiedy to się stało, rodzaj danych stracił koncentrację.
A teraz organizacje zdają sobie sprawę, że dane naprawdę są centralnym punktem. Dane reprezentują wszystko, co robimy w naszej firmie, dlatego musimy upewnić się, że dysponujemy dokładnymi danymi, że możemy znaleźć prawidłowe informacje potrzebne do podjęcia decyzji. Ponieważ nie wszystko pochodzi z określonego procesu. Niektóre informacje są produktem ubocznym innych rzeczy i nadal musimy być w stanie je znaleźć, wiedzieć, co to znaczy, i być w stanie przełożyć dane, które tam widzimy, na wiedzę, którą możemy wykorzystać do lepszego prowadzenia naszej firmy.
Malcolm Chisholm: Racja, a teraz innym obszarem, z którym borykam się, jest to, co nazwałbym cyklem życia danych, którym jest, wiesz, jeśli spojrzymy na rodzaj łańcucha dostaw danych przechodzącego przez przedsiębiorstwo, zaczniemy od pozyskiwanie danych lub przechwytywanie danych, co może być wprowadzeniem danych, ale może być również tak, otrzymuję dane spoza przedsiębiorstwa od niektórych dostawców danych.
Następnie od przechwytywania danych przechodzimy do konserwacji danych, gdzie myślę o standaryzacji tych danych i wysyłaniu ich do miejsc, w których są potrzebne. A potem wykorzystanie danych, rzeczywiste punkty, w których są dane, uzyskasz wartość z danych.
W dawnych czasach wszystko to odbywało się w jednym indywidualnym stylu, ale dziś może to być, na przykład, środowisko analityczne, na przykład, a następnie archiwum, sklep, w którym umieszczamy dane, kiedy już nie jesteśmy potrzebuję tego i na koniec procesu oczyszczania. W jaki sposób modelowanie danych pasuje do zarządzania całym cyklem życia danych?
Ron Huizenga: To bardzo dobre pytanie i jedną rzeczą, o której tak naprawdę nie miałem dzisiaj czasu wnikać w żadne szczegóły, jest to, o czym tak naprawdę zaczynamy mówić, to linia danych. Więc tak naprawdę jesteśmy w stanie zrobić, że mamy możliwość linii danych w naszych narzędziach i, jak mówię, możemy faktycznie wyodrębnić niektóre z nich z narzędzi ETL, ale możesz również zmapować to, rysując również linię. Każdy z tych modeli danych lub baz danych, które przechwyciliśmy i wprowadziliśmy do modeli, moglibyśmy odwoływać się do konstruktów z tego na naszym schemacie linii danych.
To, co możemy zrobić, to narysować przepływ danych, jak mówisz, od źródła do celu, a poprzez ogólny cykl życia, w jaki dane te przesyłane są przez różne systemy, i to, co znajdziesz, weźmy pracowników „dane - to jedno z moich ulubionych na podstawie projektu, który zrobiłem lata temu. Pracowałem z organizacją, która miała dane pracowników w 30 różnych systemach. To, co ostatecznie tam zrobiliśmy - i Rebecca wyświetliła slajd linii danych - jest to dość uproszczony slajd linii danych, ale mogliśmy wprowadzić wszystkie struktury danych, odwołać się do nich na diagramie, a następnie może faktycznie zacząć patrzeć na przepływy między nimi i w jaki sposób te różne podmioty danych są ze sobą połączone w przepływie? I możemy również wyjść poza to. Jest to część schematu przepływu danych lub diagramu pochodzenia, który widzimy tutaj. Jeśli chcesz wyjść poza to, mamy również część biznesową tego pakietu i dotyczy to również tego samego.
Dowolne struktury danych, które przechwyciliśmy w środowisku modelowania danych, można do nich odwoływać się w narzędziu do modelowania biznesowego, dzięki czemu nawet w diagramach modeli biznesowych lub diagramach procesów biznesowych można odwoływać się do poszczególnych magazynów danych, jeśli chcesz wyjść z w środowisku modelowania danych, a gdy używasz ich w folderach w modelu procesu biznesowego, możesz nawet określić CRUD również na nich, w jaki sposób te informacje są konsumowane lub wytwarzane, a następnie możemy zacząć generować na przykład raporty wpływu i analizy oraz diagramy.
Do czego dążymy, i mamy już wiele możliwości, ale jedną z rzeczy, które mamy, są pewnego rodzaju słupkiem bramkowym, na który patrzymy, gdy rozwijamy nasze narzędzia, jest w stanie odwzorować kompleksową linię danych organizacyjnych i pełny cykl życia danych.
Malcolm Chisholm: Dobra. Rebecca, czy mogę jeszcze jeden?
Rebecca Jóźwiak: Pozwolę ci jeszcze raz, Malcolm, śmiało.
Malcolm Chisholm: Dziękuję bardzo. Myśląc o zarządzaniu danymi i modelowaniu danych, jak sprawić, by te dwie grupy skutecznie ze sobą współpracowały i rozumiały się nawzajem?
Eric Little: Cóż, to interesujące, myślę, że to naprawdę zależy od organizacji, i wraca do mojej wcześniejszej koncepcji, w tych organizacjach, w których inicjatywy były napędzane przez biznes, w których byliśmy związani. Na przykład prowadziłem architekturę danych zespół, ale byliśmy ściśle związani z użytkownikami biznesowymi i faktycznie pomagaliśmy im w utrzymaniu programu zarządzania danymi. Ponownie, bardziej podejście konsultacyjne, ale tak naprawdę jest to bardziej funkcja biznesowa.
Aby naprawdę to zrobić, potrzebujesz projektantów danych i architektów, którzy naprawdę rozumieją biznes, mogą odnosić się do użytkowników biznesowych, a następnie pomagają im znieść procesy zarządzania wokół niego. Firma chce to zrobić, ale ogólnie rzecz biorąc, mamy wiedzę technologiczną, aby pomóc im wyróżnić się z tego rodzaju programów. To naprawdę musi być współpraca, ale musi być własnością firmy.
Malcolm Chisholm: Dobra, świetnie. Dziękuję Ci.
Dr Eric Little: Dobra.
Rebecca Jóźwiak: OK, wielkie dzięki. Członkowie widowni, obawiam się, że nie dotarliśmy do twoich pytań, ale upewnię się, że zostaną przekazani odpowiedniemu gościowi, którego mieliśmy dzisiaj na linii. Bardzo dziękuję Ericowi, Malcolmowi i Ronowi za to, że jesteście dzisiaj naszymi gośćmi. To było świetne rzeczy, ludzie. A jeśli podobała Ci się dzisiejsza transmisja internetowa IDERA, w najbliższą środę IDERA będzie na Hot Technologies, jeśli chcesz dołączyć, omawiając wyzwania związane z indeksowaniem i Oracle, co jest kolejnym fascynującym tematem.
Dziękuję bardzo, ludzie, trzymajcie się i do zobaczenia następnym razem. PA pa.
