Przez Techopedia Staff, 16 listopada 2016
Na wynos: gospodarz Eric Kavanagh omawia znaczenie modelowania danych w zwinnym rozwoju z Robin Bloor, Dez Blanchfield i Ron Huizenga z IDERA.
Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.
Eric Kavanagh: Dobra, panie i panowie. Witaj ponownie. Jest środa o 4:00 EST. Oznacza to, że nadszedł czas na Hot Technologies. W rzeczy samej. Nazywam się Eric Kavanagh, będę twoim gospodarzem.
W dzisiejszym temacie jest to staruszek, ale gadżet. Z każdym dniem jest coraz lepiej, ponieważ kształtuje nasz świat zarządzania danymi, „Modelowanie danych w zwinnym środowisku”. Naprawdę jest taki slajd, trafiłeś na Twittera @eric_kavanagh. Powinniśmy naprawdę umieścić to na tym slajdzie. Będę musiał się tym zająć.
Więc rok jest gorący. Modelowanie danych istnieje od zawsze. Naprawdę było to sedno działalności firmy zajmującej się zarządzaniem informacjami, projektowaniem modeli danych, próbą zrozumienia modeli biznesowych i dopasowania ich do modeli danych. To naprawdę próbujesz zrobić, prawda?
Model danych reprezentuje biznes w fundamentalny sposób, więc w jaki sposób wszystkie te nowe źródła danych zmieniają grę? Dowiemy się o tym. Dowiemy się, jak możesz być zwinny w zwinny sposób. I oczywiście to jest słowo roku.
Robin Bloor jest z nami, nasz główny analityk, Dez Blanchfield dzwoni z Sydney w Australii i Ron Huizenga, starszy menedżer produktu z IDERA - mój wieloletni przyjaciel, doskonały mówca w tej przestrzeni, zna się na swoich rzeczach, więc nie wstydź się, zapytaj mu trudne pytania, ludzie, trudne. Dzięki temu Robin zostanie prezenterem i zabiorę go.
Dr Robin Bloor: OK. Dziękuję ci za to, Eric. Muszę powiedzieć o modelowaniu, które, jak myślę, faktycznie znajdowałem się w świecie IT, zanim on istniał, w tym sensie, że pamiętam w firmie ubezpieczeniowej, w której pracowałem, że przyszedł facet i dał nam wszystkim warsztatów na temat modelowania danych. Patrzymy więc na około 30 lat, czy to 30 lat? Może nawet dłużej, może 35 lat temu. Modelowanie od dawna jest częścią branży i oczywiście nie ma nic wspólnego z kobietami na wybiegach.
To, co chciałem powiedzieć, ponieważ to, co zwykle robimy, to ja i Dez rozmawiamy o różnych rzeczach i pomyślałem, że dam ogólny przegląd modelowania, ale jest w tym rzeczywistość, która staje się teraz widoczna.
Mamy, wiesz, rzeczywistość dużych zbiorów danych, mamy więcej danych, więcej źródeł danych, mamy strumienie danych, które weszły do równania w ciągu ostatnich trzech lub czterech lat i zaczynają otrzymywać większą jego część, i istnieje większa potrzeba zrozumienia danych i wzrost szybkości zmian, im więcej danych jest dodawanych, tym więcej wykorzystywanych struktur danych.
To trudny świat. Oto jego zdjęcie, które właściwie narysowaliśmy około trzy lata temu, ale w zasadzie, po włączeniu przesyłania strumieniowego do miksu i otrzymaniu pomysłu rafinerii danych, centrum danych, łącza danych itp., Widać, że istnieją dane, które naprawdę w spoczynku, w tym sensie, że niewiele się porusza. A potem są dane, strumienie i masz całą aplikację transakcyjną, a teraz masz zdarzenia, przepływy danych zdarzeń, które zdarzają się w aplikacjach i być może będą musiały, a obecnie z architekturami lambda, o których wszyscy mówią, są naprawdę wpływające tylko na całe pole danych.
A obecnie myślę o istnieniu warstwy danych. Warstwa danych istnieje w pewien sposób wirtualny, w tym sensie, że spora część może znajdować się w chmurze i może być rozłożona na centra danych, może istnieć na stacjach roboczych. Warstwa danych jest do pewnego stopnia wszędzie i w tym sensie istnieją procesy, które próbują w taki czy inny sposób przetwarzać dane i przenosić je. Ale wiedza o tym, kiedy się poruszasz, to wielka sprawa.
Jeśli spojrzymy na modelowanie danych w najbardziej ogólnym sensie, u dołu tego rodzaju stosu znajdują się pliki i bazy danych. Masz elementy danych, które mają klucze, definicje elementów, aliasy, synonimy, określone formaty fizyczne, a następnie mamy tę warstwę metadanych.
Interesującą rzeczą w metadanych jest to, że metadane są całkowicie tym, jak dane zyskują swoje znaczenie. Jeśli tak naprawdę nie masz metadanych, w najlepszym razie możesz odgadnąć znaczenie danych, ale będziesz mieć ogromne trudności. Metadane muszą tam być, ale znaczenie ma strukturę. Nie chcę wchodzić w filozofię znaczenia, ale nawet w sposobie, w jaki mamy do czynienia z danymi, istnieje wiele wyrafinowania w ludzkiej myśli i ludzkim języku, który nie łatwo wyraża się w danych. Ale nawet jeśli chodzi o dane, które faktycznie przetwarzamy na świecie, metadane mają znaczenie i strukturę metadanych - jeden kawałek danych w stosunku do drugiego i co to znaczy, gdy są zebrane razem i co to znaczy, gdy „ ponownie połączone z innymi danymi, wymaga ich modelowania. Nie wystarczy po prostu rejestrować znaczniki metadanych do rzeczy, trzeba rejestrować znaczenie dla poszczególnych struktur i relacje między nimi.
Następnie mamy na górnej warstwie definicje biznesowe, które zwykle są warstwą, która próbuje przenieść znaczenie między metadanymi, która jest formą definicji danych, która uwzględnia sposób, w jaki dane są zorganizowane na komputerze i znaczenie ludzkie. Masz więc terminy biznesowe, definicje, relacje, pojęcia na poziomie jednostki, które istnieją w tej warstwie. A jeśli będziemy mieli niespójność między tymi warstwami, musimy mieć modelowanie danych. To nie jest tak naprawdę opcjonalne. Im więcej możesz to zrobić w zakresie automatyzacji, tym lepiej. Ale ponieważ ma to związek ze znaczeniem, naprawdę trudno jest na przemian. Łatwo jest złapać metadane w rekordzie i być w stanie uzyskać je z szeregu znaczeń, ale nie mówi to o strukturze rekordów ani o tym, co oznaczają i kontekst rekordu.
Na tym właśnie polega moim zdaniem modelowanie danych. Należy zwrócić uwagę: im bardziej złożony staje się wszechświat danych, tym bardziej trzeba go modelować. Innymi słowy, to trochę tak, jakbyśmy dodawali światu nie tylko więcej wystąpień rzeczy, które odpowiadałyby rekordom danych, ale w rzeczywistości dodaliśmy światu więcej znaczenia, przechwytując dane o coraz większej liczbie rzeczy. To staje się coraz bardziej złożone, że musimy zrozumieć.
Teoretycznie istnieje wszechświat danych i potrzebujemy jego widoku. W praktyce rzeczywiste metadane są częścią wszechświata danych. To nie jest prosta sytuacja. Rozpoczęcie modelowania odbywa się od góry do dołu i od dołu do góry. Musisz budować w obu kierunkach, a to dlatego, że dane mają znaczenie dla komputera i procesu, który musi je przetwarzać, ale ma znaczenie samo w sobie. Tak więc potrzebujesz oddolnego znaczenia, które zaspokoi oprogramowanie, które potrzebuje dostępu do danych, i potrzebujesz odgórnego znaczenia, aby ludzie mogli je zrozumieć. Budowanie modeli metadanych nie jest i nigdy nie może być projektem; to ciągłe działanie - powinno być ciągłym działaniem w każdym istniejącym środowisku. Na szczęście istnieje wiele środowisk, w których tak naprawdę nie jest i rzeczy wymykają się spod kontroli.
W przyszłości modelowanie rośnie wraz ze znaczeniem wraz z postępem technologii. To jest moja opinia. Ale jeśli spojrzysz na Internet Rzeczy, możemy zrozumieć telefon komórkowy bardziej niż kiedyś, chociaż wprowadzono nowe wymiary: wymiar lokalizacji z telefonem komórkowym. Po przejściu do Internetu Rzeczy przyglądamy się niezwykłym problemom z danymi, których tak naprawdę nigdy nie musieliśmy robić, i musimy w ten czy inny sposób właściwie zrozumieć, co dokładnie mamy, w jaki sposób możemy go agregować, co możemy zrobić, jeśli chodzi o uzyskanie sensu z agregacji, i oczywiście, co możemy z tym zrobić, kiedy go przetworzymy.
Myślę, że to ja powiedziałem już dość. Przekażę Dezowi Blanchfieldowi, który powie coś zupełnie innego.
Dez Blanchfield: Dziękuję. Zawsze trudny do naśladowania, ale jest to temat, który uzgodniliśmy i rozmawialiśmy o tym krótko w żartach na świeżym powietrzu, a jeśli zadzwonisz wcześniej, prawdopodobnie złapiesz całą masę wspaniałych klejnotów. Jeden z dań na wynos i nie chcę kraść grzmotów tego konkretnego, ale jeden z dań z naszego żartu, który chcę podzielić, na wypadek, gdybyś go nie złapał, dotyczył tylko tematu podróż danych i uderzyło mnie, że napisałem ją z myślą o podróży danych w innym kontekście życia pokoleniowego - rok, miesiące, tydzień, dzień, godzina, minuta, sekunda - a kontekst wokół danych jest umieszczony w tym kontekście. Niezależnie od tego, czy jestem programistą obsługującym kod, czy też jestem specjalistą od danych i myślę o strukturze i formacie oraz metadanych wokół każdego elementu lub o sposobie, w jaki systemy i firma współdziałają z nim.
Warto zauważyć, że jest to bardzo interesujące na wynos, ale i tak pozwolę sobie zanurkować. W szczególności projektowanie danych to fraza, której używam, aby mówić o wszystkich danych, a konkretnie o rozwoju aplikacji lub infrastruktury bazy danych. Myślę, że projektowanie danych to termin, który po prostu bardzo dobrze ujmuje to wszystko w mojej głowie. W dzisiejszych czasach, gdy mówimy o projektowaniu danych, mówimy o nowoczesnym zwinnym projektowaniu danych, i moim zdaniem jest to tak dawno, że programiści i eksperci od danych pracowali sam; znajdowali się we własnych silosach, a elementy projektu przechodziły z jednego silosu do drugiego. Ale w dzisiejszych czasach jestem bardzo przekonany, że nie tylko to się zmieniło, ale musi się zmienić; jest to w pewnym sensie konieczność i to jest ta aplikacja - programiści i cokolwiek do zrobienia w zakresie programowania, który zajmuje się danymi, projektanci, którzy wykonują odpowiednie elementy projektowe schematów i pól i zapisów oraz systemów i infrastruktur lokalizacji i baz danych, modelowania i całego zarządzania wyzwanie wokół tego. To teraz sport zespołowy, stąd moje zdjęcie grupy ludzi wyskakujących z samolotu, które działają jak drużyna, aby odtworzyć ten interesujący wizualnie obraz ludzi spadających z nieba.
Po trzecie, co się stało, aby to spowodować? Jest taki artykuł z 1986 roku napisany przez kilku dżentelmenów, których nazwiska desperacko starałem się wymierzyć sprawiedliwości, Hirotaka Takeuchi i Ikujiro Nonaka, myślę, że jest to wymawiane, stworzyli artykuł zatytułowany „Moving the Scrum Downfield”. ten pomysł na metodologię wygrania meczu rugby z tej scrumowej działalności, w której wszyscy poruszają się w jednym miejscu, a dwie drużyny zasadniczo blokują głowy w czymś zwanym scrum, aby spróbować przejąć kontrolę nad piłką i zagrać nią dotrzyj do linii próbnej i dotknij piłki ziemią, a następnie zdobądź punkt, zwany trynem, a następnie powtórz ten proces i zdobędziesz więcej punktów dla drużyny.
Ten artykuł został opublikowany w 1986 roku w Harvard Business Review i, co ciekawe, rzeczywiście zyskał wiele uwagi. Przyciągnęło to wiele uwagi, ponieważ wprowadziło niesamowite nowe koncepcje, a oto zrzut ekranu z przodu. Więc wzięli tę koncepcję scrum z gry w rugby i wprowadzili ją w biznes, a zwłaszcza w grę projektowania i realizacji projektów, w szczególności realizacji projektów.
To, co zrobił Scrum, dało nam nową metodologię w porównaniu z takimi jak PRINCE2 lub PMBOK, które wcześniej stosowaliśmy w tak zwanej metodologii wodospadu, wiesz, zrób to i to i to i to i wykonaj je kolejno i połącz wszystkie kropki, które zależą od tego, co miałeś, lub nie rób części drugiej, dopóki nie zrobisz części pierwszej, ponieważ zależało to od części pierwszej. To, co nam dało, to nowa metodologia, aby być nieco bardziej zwinnym, i stąd pochodzi ten termin, o tym, jak dostarczamy rzeczy, a konkretnie wokół realizacji projektów oddolnych.
Niektórzy z kluczowych najemców - po prostu zaczynam z tym - są wokół kluczowych najemców scrum. Wprowadził ideę budowania niestabilności, że skutecznie, jeśli myślisz o strachu przed chaosem, świat istnieje w stanie chaosu, ale planeta uformowała się, co jest interesujące, więc budowanie niestabilności, możliwość odbicia się trochę i wciąż faktycznie działają, samoorganizujące się zespoły projektowe, nakładające się korzyści poprzez bardzo odpowiedzialny rozwój, różne rodzaje uczenia się i kontroli poprzez drogę realizacji projektu, organizacyjny transfer uczenia się. Jak więc pobrać informacje z jednej części firmy i przenieść je do innej osoby, która ma pomysł, ale nie rozwija kodu lub nie rozwija baz danych i infrastruktur, ale dane dla tych osób? A konkretnie wyniki czasowe. Innymi słowy, zróbmy to przez pewien czas, albo dzień jak za 24 godziny, tydzień lub kilka tygodni i zobaczmy, co możemy zrobić, a następnie cofnij się i spójrz na to.
I tak, jeśli wybaczycie kalambur, jest to naprawdę nowa gra w dostarczaniu projektów i trzy podstawowe elementy, które będą miały sens, gdy będziemy się tu nieco dalej - jest produkt: wszyscy ci ludzie mają pomysł i mają potrzeba zrobienia czegoś i historia, która ich otacza. Deweloperzy, którzy działają w modelu zwinnym, zdobywając swoje historie i poprzez codzienne pojedynki, korzystając z metodologii scrum, aby omówić je i zrozumieć, co muszą zrobić, a następnie po prostu przejść i zacząć to robić. Potem ludzie, słyszeliśmy o mistrzach scrum, którzy nadzorują to wszystko i rozumieją metodologię wystarczająco dobrze, aby ją prowadzić. Wszyscy widzieliśmy te obrazy, które dostałem tutaj po prawej stronie ścian i tablic pełnych notatek Post-It i były one używane jako ściany Kanban. Jeśli nie wiesz, kim jest Kanban, zapraszam do Google, kim był Pan Kanban i dlaczego zmienił się sposób, w jaki przenosimy rzeczy z jednej strony na drugą dosłownie, ale w projekcie.
Na pierwszy rzut oka, scrum workflow robi to: bierze listę rzeczy, które organizacja chce zrobić, przegląda szereg rzeczy, które nazywamy sprintami, które są podzielone na okresy 24-godzinne, miesięczne, a my uzyskaj tę przyrostową serię wyników. To znacząca zmiana w sposobie dostarczania projektów, które zostały dostarczone do tego etapu, ponieważ część tego płynie, podobnie jak armia amerykańska, która miała dużą część rozwoju czegoś zwanego PMBOK, na przykład pomysł, który nie zabiera czołgu na pole dopóki nie włożysz pocisków w przedmiot, ponieważ jeśli czołg w polu nie ma pocisków, jest to bezużyteczne. Tak więc część pierwsza to pociski w zbiorniku, część druga to czołg w polu. Niestety, to, co stało się z programistami w świecie deweloperskim, w jakiś sposób opanowało tę zwinną metodologię i przebiegło z nią całkowicie, jeśli wybaczysz kalambur, w sprincie.
Niezmiennie to, co się stało, kiedy myślimy o zwinności, zwykle myślimy o programistach, a nie bazach danych i cokolwiek wspólnego ze światem baz danych. Był to niefortunny wynik, ponieważ w rzeczywistości zwinność nie ogranicza się do programistów. W rzeczywistości termin zwinny jest moim zdaniem często błędnie kojarzony wyłącznie z twórcami oprogramowania, a nie projektantami i architektami baz danych. Niezmiennie te same wyzwania, które napotykasz podczas opracowywania oprogramowania i aplikacji, napotykają wszystkie rzeczy związane z projektowaniem i rozwojem oraz działaniem i utrzymaniem, a zatem infrastrukturą danych, a zwłaszcza bazami danych. Aktorzy w tej konkretnej obsadzie danych to między innymi architekci danych, formatorzy, administratorzy, menedżerowie infrastruktur baz danych i samych baz danych, aż po analityków biznesowych i systemowych oraz architektów, osoby siedzące i myślące o tym, jak systemy i biznes działa, a także jak przepływaliśmy przez nie dane.
Jest to temat, który regularnie poruszam, ponieważ stale mnie frustruje, ponieważ jestem zdania, że specjaliści od danych muszą - a nie powinni - muszą teraz być ściśle zaangażowani w każdy element realizacji projektu, a szczególnie w rozwój. Jeśli nie, to naprawdę nie dajemy sobie najlepszej szansy na dobry wynik. Często musimy zawrócić i zastanowić się nad tymi rzeczami, ponieważ istnieje scenariusz, dochodzimy do budowy aplikacji i odkrywamy, że programiści nie zawsze są ekspertami w dziedzinie danych. Praca z bazami danych wymaga bardzo wyspecjalizowanych umiejętności, szczególnie w zakresie danych, i tworzy doświadczenie. Nie stajesz się od razu guru bazy danych lub ekspertem w dziedzinie danych z dnia na dzień; często jest to coś, co pochodzi z życiowego doświadczenia, a na pewno z udziałem doktora Robina Bloora z Code Today, który dość bogato napisał książkę.
W wielu przypadkach - i jest to niefortunne, ale jest to rzeczywistość - że dwie części tej monety, to znaczy, że programiści mają własne problemy z wyspecjalizowaniem się w bazach danych i zbudowali umiejętności potrzebne do modelowania projektowania baz danych, przy czym tworzenie modeli jest po prostu fundamentalne dla inżynierii guru, w jaki sposób dane przychodzą i jak organizuje podróż, i jak powinna ona wyglądać, a czego nie powinna, lub niewątpliwie pochłonęło i zrozumienie, że jest to zwykle natywna umiejętność dla programistów. A niektóre z typowych wyzwań, przed którymi stoimy, po prostu ujmując to w kontekście, obejmują takie jak proste tworzenie i utrzymanie i zarządzanie samym projektem podstawowej bazy danych, dokumentowanie danych i infrastruktury bazy danych, a następnie ponowne wykorzystywanie tych zasobów danych, projektów schematów, generowanie schematów, administrowanie i utrzymywanie schematu i ich stosowanie, dzielenie się wiedzą na temat tego, dlaczego ten schemat jest zaprojektowany w szczególny sposób, a mocne i słabe strony, które pojawiają się wraz z nim, powodują zmiany danych w czasie, modelowanie danych i typy modeli, które stosujemy do systemów i przepływających przez nie danych. Generowanie kodu bazy danych i integracja, a następnie modelowanie danych wokół nich, a następnie szybszy dostęp do kontroli bezpieczeństwa wokół danych, integralność danych, gdy przenosimy dane, zachowując ich integralność, czy jest wystarczająca ilość metadanych wokół to, czy sprzedaż powinna zobaczyć wszystkie rekordy w tabeli, czy powinny tylko widzieć adres, imię, nazwisko, które wysyła ci rzeczy na poczcie? A potem oczywiście największym wyzwaniem jest modelowanie platform baz danych, które samo w sobie jest zupełnie inną rozmową.
Jestem bardzo przekonany, że mając to wszystko na uwadze, aby uczynić tę nirwanę możliwą, absolutnie niezwykle ważne jest, aby zarówno specjaliści do spraw danych, jak i programiści dysponowali odpowiednimi narzędziami i aby narzędzia te mogły realizować projekty zorientowane na zespół, projektowanie, rozwój i bieżące utrzymanie operacyjne. Wiesz, takie rzeczy jak współpraca między projektami między ekspertami danych i twórcami oprogramowania, pojedynczy punkt prawdy lub pojedyncze źródło prawdy dla wszystkich rzeczy wokół dokumentacji samych baz danych, danych, schematów, skąd pochodzą rekordy, właściciele tych rekordów . Myślę, że w dzisiejszych czasach jest to absolutnie niezbędne, zdobędziemy tę nirwanę danych jako króla, że odpowiednie narzędzia muszą być na miejscu, ponieważ wyzwanie jest teraz zbyt duże, abyśmy mogli to zrobić ręcznie, a jeśli ludzie wchodząc i wychodząc z jednej organizacji, zbyt łatwo jest nam nie postępować zgodnie z tym samym procesem lub metodologią, które jedna osoba może skonfigurować, które są dobre i niekoniecznie przenoszą te umiejętności i możliwości w przyszłości.
Mając to na uwadze, zamierzam udać się do naszego dobrego przyjaciela z IDERA i usłyszeć o tym narzędziu i jego rozwiązaniu.
Ron Huizenga: Dziękuję bardzo i dziękuję zarówno Robinowi, jak i Dezowi za naprawdę dobre ustawienie sceny, a zobaczysz trochę nakładania się kilku rzeczy, o których mówiłem. Ale naprawdę stworzyły one solidne podstawy dla niektórych koncepcji, o których będę mówić z perspektywy modelowania danych. I wiele rzeczy, które powiedzieli, odzwierciedlają moje własne doświadczenia, gdy byłem konsultantem pracującym w zakresie modelowania danych i architektury danych, wraz z zespołami - zarówno wodospadem na początku, jak i ewoluującymi w kierunku bardziej nowoczesnych produktów z projektami, w których używaliśmy zwinnych metody dostarczania rozwiązań.
Zatem to, o czym dzisiaj powiem, opiera się na tych doświadczeniach, a także na widoku narzędzi i niektórych możliwościach narzędzi, które wykorzystujemy, aby pomóc nam w tej podróży. Krótko omówię to: nie będę wchodził w scrum w wielu szczegółach; właśnie mieliśmy naprawdę dobry przegląd tego, co to jest. Opowiem o tym, czym jest model danych i co tak naprawdę dla nas znaczy? I w jaki sposób możemy włączyć koncepcję zwinnego modelera danych w naszych organizacjach pod względem tego, w jaki sposób angażujemy modelerów danych, jaki jest udział modelarzy i architektów podczas sprintu, jakie rodzaje działań powinni oni zaangażować, a jako tło tego, jakie są niektóre ważne funkcje narzędzia do modelowania, które wykorzystujemy, aby naprawdę ułatwić tę pracę? Potem przejdę do podsumowania i porozmawiam trochę o niektórych wartościach biznesowych i korzyściach związanych z zaangażowaniem projektanta danych, lub o tym, w jaki sposób opowiem historię, problemy z tym, że modelarz danych nie jest w pełni zaangażowany w projekty, a pokażę wam to na podstawie doświadczenia i tabeli defektów obrazu przed i po rzeczywistym projektu, z którym byłem zaangażowany wiele lat temu. A następnie podsumujemy jeszcze kilka punktów, a następnie będziemy mieli dodatkowe pytania i odpowiedzi.
Krótko mówiąc, ER Studio to bardzo potężny pakiet, który ma wiele różnych składników. Architekt danych, w którym projektanci i architekci danych spędzają większość czasu na modelowaniu danych. Są też inne komponenty, o których dziś nie będziemy mówić, takie jak Business Architect, w którym zajmujemy się modelowaniem procesów i Software Architect, w przypadku niektórych modeli UML. Następnie jest repozytorium, w którym meldujemy się i udostępniamy modele oraz pozwalamy zespołom współpracować nad nimi i publikować je na serwerze zespołu, aby wielu zainteresowanych stron zaangażowanych w projekt mogło faktycznie zobaczyć artefakty, które „ tworzymy z perspektywy danych, a także innych rzeczy, które robimy w samej realizacji projektu.
To, na czym będę się dzisiaj koncentrować, to kilka rzeczy, które zobaczymy w Data Architect i ponieważ to naprawdę ważne, że współpracujemy z aspektami opartymi na repozytorium. Zwłaszcza, gdy zaczynamy mówić o koncepcjach takich jak zarządzanie zmianami, które są niezbędne nie tylko dla zwinnych projektów programistycznych, ale również dla każdego rodzaju rozwoju w przyszłości.
Porozmawiajmy więc o Agile Data Modeler. Jak już wspomnieliśmy wcześniej w prezentacji, konieczne jest, abyśmy mieli modelarzy danych i / lub architektów w pełni zaangażowanych w sprawne procesy programistyczne. Historycznie rzecz biorąc, tak naprawdę myśleliśmy o zwinności z perspektywy rozwoju, a stało się kilka rzeczy, które tak naprawdę sprawiły, że tak się stało. Częściowo było to spowodowane charakterem samego rozwoju. Gdy rozpoczął się zwinny rozwój i zaczęliśmy od koncepcji samoorganizujących się zespołów, jeśli wypiłeś Kool-Aid trochę zbyt czysto i byłeś po skrajnej stronie programowania, istniała bardzo dosłowna interpretacja takich rzeczy jak zespoły samoorganizujące się, co wiele osób interpretowało jako „wszystko”, potrzebujemy tylko grupy programistów, którzy mogą zbudować całe rozwiązanie. Niezależnie od tego, czy oznacza to opracowanie kodu, baz danych czy magazynów danych za nim i wszystko zostało przekazane deweloperom. Ale to, co się dzieje, polega na tym, że tracisz specjalne zdolności, które ludzie mają. Przekonałem się, że najsilniejsze zespoły to te, które składają się z ludzi z różnych środowisk. Na przykład połączenie silnych programistów, architektów danych, projektantów danych, analityków biznesowych i interesariuszy biznesowych, którzy współpracują ze sobą w celu wypracowania końcowego rozwiązania.
To, o czym dzisiaj mówię, to zamierzam to zrobić w kontekście projektu programistycznego, w którym opracowujemy aplikację, która oczywiście będzie miała również powiązany z nią komponent danych. Musimy jednak zrobić krok do tyłu, zanim to zrobimy, ponieważ musimy zdać sobie sprawę, że istnieje bardzo niewiele projektów rozwojowych Greenfield, w których skupiamy się na tworzeniu i zużyciu danych, które są ograniczone tylko w ramach samego projektu rozwojowego . Musimy cofnąć się o krok i spojrzeć na ogólny punkt widzenia organizacji z perspektywy danych i procesu. Ponieważ dowiadujemy się, że wykorzystywane przez nas informacje mogą już istnieć gdzieś w organizacji. Jako projektanci i architekci ujawniamy to, abyśmy wiedzieli, skąd czerpać te informacje w samych projektach. Znamy również zaangażowane struktury danych, ponieważ mamy wzorce projektowe, podobnie jak programiści wzorce projektowe dla swojego kodu. Musimy także przyjąć tę ogólną perspektywę organizacyjną. Nie możemy po prostu patrzeć na dane w kontekście aplikacji, którą tworzymy. Musimy modelować dane i upewnić się, że je udokumentujemy, ponieważ żyje ono znacznie dłużej niż same aplikacje. Te aplikacje przychodzą i znikają, ale musimy być w stanie spojrzeć na dane i upewnić się, że są one solidne i dobrze zorganizowane, nie tylko dla aplikacji, ale także dla decyzji, które zgłaszają działania, raportowanie BI i integrację z innymi aplikacjami, wewnętrznymi i również poza naszymi organizacjami. Musimy więc przyjrzeć się całemu dużemu obrazowi danych i cyklowi życia tych danych oraz zrozumieć podróż fragmentów informacji w całej organizacji, od kołyski aż po grób.
Teraz wracając do samych zespołów i tego, jak naprawdę musimy pracować, metodologia wodospadu była postrzegana jako zbyt wolna, aby zapewnić wyniki. Ponieważ, jak wskazano w przykładzie czołgu, było to krok po kroku i często trwało zbyt długo, aby zapewnić realny efekt końcowy. Teraz musimy mieć iteracyjny styl pracy, w którym stopniowo rozwijamy jego komponenty i opracowujemy je w czasie, w którym produkujemy użyteczny kod lub użyteczne artefakty, powiem, dla każdego sprintu. Ważną rzeczą jest współpraca między technicznymi interesariuszami w zespole i interesariuszami biznesowymi, ponieważ współpracujemy, aby wprowadzić te historie użytkowników do możliwej do wdrożenia wizji kodu i danych, które również obsługują ten kod. Sam Agile Data Modeler często stwierdza, że nie mamy wystarczającej liczby modelarzy w organizacjach, więc jeden modeler danych lub architekt może jednocześnie obsługiwać wiele zespołów.
Innym aspektem tego jest to, że nawet jeśli mamy wielu modelarzy, musimy upewnić się, że dysponujemy zestawem narzędzi, który wykorzystujemy, który umożliwia współpracę wielu projektów realizowanych w tym samym czasie i dzielenie się nimi artefakty danych oraz możliwości zameldowania i wymeldowania. Omówię to bardzo szybko, ponieważ omówiliśmy to już w poprzednim rozdziale. Prawdziwa przesłanka zwinności polega na tym, że opierasz się na zaległościach, historiach lub wymaganiach. W ramach iteracji współpracujemy jako grupa. Zwykle dwutygodniowy lub miesięczny sprint, w zależności od organizacji, jest bardzo powszechny. A także codzienne przeglądy i spotkania stand-up, dzięki czemu eliminujemy blokery i upewniamy się, że przesuwamy wszystkie aspekty do przodu bez zatrzymywania się w różnych obszarach podczas przechodzenia. W tych sprintach chcemy mieć pewność, że produkujemy przydatne przedmioty użytkowe jako część każdego sprintu.
Po prostu nieco inne podejście do tego, rozszerzając go dalej, scrum jest metodologią, o której powiem tutaj bardziej szczegółowo, i po prostu zasadniczo wzmocniliśmy to poprzednie zdjęcie o kilka innych aspektów. Zazwyczaj jest backlog produktu, a następnie backlog sprintu. Mamy więc ogólne zaległości, które na początku każdego powtórzenia sprintu ograniczają się do stwierdzenia: „Co będziemy budować w tym sprincie?” I odbywa się to na spotkaniu dotyczącym planowania sprintu. Następnie rozbijamy zadania z tym związane i wykonujemy je w tych trwających od jednego do czterech tygodni sprintach z codziennymi recenzjami. Robiąc to, śledzimy nasze postępy za pomocą wykresów wypalania i wykresów wypalania, aby w zasadzie śledzić, co pozostało do zbudowania w porównaniu do tego, co budujemy, aby ustalić takie rzeczy, jak nasza prędkość rozwoju, czy mamy zamiar harmonogram, wszystkie tego typu rzeczy. Wszystkie są opracowywane w sposób ciągły podczas sprintu, zamiast iść kilka miesięcy w dół i dowiedzieć się, że niedługo skończysz i musisz przedłużyć harmonogram projektu. I bardzo ważne, w ramach tego, całe zespoły, na końcu jest przegląd sprintu i retrospektywa sprintu, więc przed rozpoczęciem kolejnej iteracji przeglądasz to, co zrobiłeś i szukasz sposobów, które możesz poprawić za następnym razem.
Pod względem rezultatów jest to w zasadzie slajd, który podsumowuje typowe rzeczy, które dzieją się w sprintach. I jest bardzo zorientowany na rozwój, więc wiele rzeczy, które tu widzimy, takich jak projekty funkcjonalne i przypadki użycia, przeprowadzanie testów kodu projektu, kiedy patrzymy na te pola tutaj i nie zamierzam ich przeglądać pod każdym względem są one zorientowane na rozwój. Poniżej znajduje się fakt, że musimy również zapewnić te dane, które idą w parze z tym celem, aby wesprzeć ten wysiłek. Więc za każdym razem, gdy widzimy takie zaległości, wymagania i historie użytkowników, kiedy przechodzimy, musimy spojrzeć na to, jakie elementy rozwoju musimy wykonać, jakie elementy analizy musimy zrobić, a co z projekt danych lub model danych, co z glosariuszami biznesowymi, abyśmy mogli powiązać znaczenie biznesowe ze wszystkimi produkowanymi przez nas artefaktami? Ponieważ musimy produkować te przydatne przedmioty przy każdym sprincie.
Niektórzy powiedzą, że musimy stworzyć użyteczny kod na końcu każdego sprintu. Niekoniecznie tak jest, to znaczy w najczystszej perspektywie rozwoju, ale dość często - szczególnie na początku - możemy mieć coś w rodzaju sprintu zero, w którym skupiamy się wyłącznie na stawianiu czoła, robieniu rzeczy, takich jak wdrażanie naszych strategii testowych miejsce. Projekt na wysokim poziomie, aby rozpocząć, zanim zaczniemy wypełniać szczegóły i upewnić się, że mamy czysty zestaw początkowych historii lub wymagań, zanim zaczniemy angażować innych odbiorców, a następnie budować zespół jako zespół. Zawsze jest trochę czasu na przygotowanie, więc dość często będziemy mieli zero sprintu lub nawet zero sprintu i jeden. Może być trochę fazy początkowej, zanim osiągniemy pełny lot w dostarczaniu rozwiązania.
Porozmawiajmy o modelach danych w tym kontekście bardzo krótko. Kiedy ludzie myślą o modelach danych, często myślą o modelu danych jako o tym, jak różne informacje łączą się ze sobą - to tylko wierzchołek góry lodowej. Aby w pełni urzeczywistnić ducha tego, jak naprawdę chcesz podejść do modelowania danych - niezależnie od tego, czy chodzi o zwinne projektowanie i inne rzeczy - musisz zdać sobie sprawę z tego, że poprawnie wykonany model danych staje się pełną specyfikacją tego, co te dane oznaczają w organizacji i jak jest wdrażany w bazach danych zaplecza. Kiedy mówię o bazach danych, mam na myśli nie tylko relacyjne bazy danych, których możemy używać, ale także w dzisiejszych architekturach, w których mamy platformy Big Data lub NoSQL, jak wolę je nazywać. Także te duże magazyny danych, ponieważ możemy łączyć wiele różnych magazynów danych pod względem zużycia informacji i wprowadzania ich do naszych rozwiązań, a także sposobu, w jaki zachowujemy lub zapisujemy te informacje również w naszych rozwiązaniach.
Możemy współpracować z wieloma bazami danych lub źródłami danych jednocześnie w kontekście danej aplikacji. Bardzo ważne jest to, że chcemy mieć pełną specyfikację, więc logiczną specyfikację tego, co to oznacza dla perspektywy organizacyjnej sprintu, jakie są fizyczne konstrukcje pod względem tego, jak faktycznie definiujemy dane, relacje między nimi w twoje bazy danych, referencyjne ograniczenia integralności, ograniczenia sprawdzające, wszystkie te elementy walidacji, o których zwykle myślisz. Metadane opisowe są niezwykle ważne. Skąd wiesz, jak wykorzystywać dane w swoich aplikacjach? Chyba że możesz to zdefiniować i wiedzieć, co to znaczy, lub wiedzieć, skąd pochodzi, aby upewnić się, że konsumujesz prawidłowe dane w tych aplikacjach - upewniając się, że mamy prawidłowe konwencje nazewnictwa, pełne definicje, co oznacza pełny słownik danych nie tylko tabele, ale kolumny zawierające te tabele - oraz szczegółowe uwagi dotyczące wdrażania, w jaki sposób je wykorzystujemy, ponieważ musimy zbudować tę bazę wiedzy, ponieważ nawet po zakończeniu tej aplikacji informacje te zostaną wykorzystane do innych inicjatyw, dlatego musimy się upewnić że mamy wszystko, co udokumentowaliśmy na potrzeby przyszłych wdrożeń.
Ponownie przechodzimy do rzeczy takich jak typy danych, klucze, indeksy, sam model danych zawiera wiele reguł biznesowych, które wchodzą w grę. Relacje to nie tylko ograniczenia między różnymi tabelami; często pomagają nam opisać, jakie są prawdziwe reguły biznesowe wokół tego, jak zachowują się te dane i jak działają one jako spójna jednostka. I oczywiście ograniczenia wartości są bardzo ważne. Oczywiście, jedną z rzeczy, z którymi ciągle mamy do czynienia, a staje się coraz bardziej powszechne, są takie rzeczy jak zarządzanie danymi. Więc z punktu widzenia zarządzania danymi musimy również przyjrzeć się temu, co tutaj definiujemy? Chcemy zdefiniować takie rzeczy, jak klasyfikacje bezpieczeństwa. Z jakimi typami danych mamy do czynienia? Co będzie uważane za zarządzanie danymi podstawowymi? Jakie sklepy transakcyjne tworzymy? Jakie dane referencyjne wykorzystujemy w tych aplikacjach? Musimy upewnić się, że jest odpowiednio uchwycony w naszych modelach. A także względy jakości danych, istnieją pewne informacje, które są ważniejsze dla organizacji niż inne.
Brałem udział w projektach, w których zastępowaliśmy kilkanaście starszych systemów nowymi procesami biznesowymi oraz projektuję nowe aplikacje i magazyny danych, aby je zastąpić. Musieliśmy wiedzieć, skąd pochodzą informacje. Co do najważniejszych informacji, z perspektywy biznesowej, jeśli spojrzysz na ten konkretny slajd modelu danych, który tu mam, zobaczysz, że dolne pola w tych konkretnych jednostkach, które są tylko małym podzbiorem, ja faktycznie udało mi się uchwycić wartość biznesową. Niezależnie od tego, czy jest wysoka, średnia czy niska dla tego rodzaju rzeczy dla różnych konstrukcji w organizacji. Przechwyciłem także takie rzeczy, jak klasy danych podstawowych, czy są to tabele główne, czy są referencjami, czy były transakcyjne. Możemy więc rozszerzyć nasze metadane w naszych modelach, aby nadać nam wiele innych cech poza danymi, co naprawdę pomogło nam w podejmowaniu innych inicjatyw poza oryginalnymi projektami i je kontynuować. To było dużo na jednym slajdzie, przejrzę resztę dość szybko.
Teraz będę mówił bardzo szybko o tym, co robi modelarz danych, gdy przechodzimy przez te różne sprinty. Przede wszystkim, pełny uczestnik sesji planowania sprintu, w których bierzemy historie użytkowników, zobowiązujemy się do tego, co zamierzamy dostarczyć w tym sprincie, i zastanawiamy się, jak je ustrukturyzować i dostarczyć. Jako projektant danych robię też to, że wiem, że będę pracować w różnych obszarach z różnymi programistami lub różnymi ludźmi. Tak więc jedną z ważnych cech, którą możemy mieć, jest to, że kiedy wykonujemy model danych, możemy podzielić ten model danych na różne widoki, niezależnie od tego, czy nazywamy je obszarami tematycznymi, czy podmodami, to nasza terminologia. Tworząc model, pokazujemy go również w różnych perspektywach podmodelu, dzięki czemu różni odbiorcy widzą tylko to, co jest dla nich istotne, aby mogli skoncentrować się na tym, co rozwijają i przedstawiają. Mogę więc mieć kogoś, kto pracuje nad częścią aplikacji związaną z planowaniem, mogę mieć kogoś innego, który pracuje nad wpisem zamówienia, w którym robimy wszystkie te rzeczy w jednym sprincie, ale mogę dać im punkty widzenia poprzez te podmodele, które tylko odnoszą się do obszaru, nad którym pracują. Następnie łączą się one z ogólnym modelem i całą strukturą podmodeli, aby dać różnym widzom to, co powinni zobaczyć.
Podstawą z perspektywy modelowania danych, którą chcemy mieć, jest zawsze podstawa, do której możemy wrócić, ponieważ jedną z rzeczy, które musimy zrobić, jest to, czy jest to na końcu sprintu, czy na końcu z kilku sprintów, chcemy wiedzieć, od czego zaczęliśmy i zawsze mieć linię bazową, aby wiedzieć, jaka była delta lub różnica w tym, co wyprodukowaliśmy w danym sprincie. Musimy również upewnić się, że możemy mieć szybki zwrot. Jeśli wejdziesz w to jako modeler danych, ale w tradycyjnej roli strażnika, mówiąc: „Nie, nie, nie możesz tego zrobić, musimy to wszystko zrobić najpierw”, zostaniesz wykluczony z zespołu, kiedy naprawdę będziesz potrzebować być aktywnym uczestnikiem wszystkich zwinnych zespołów programistycznych. Oznacza to, że niektóre rzeczy spadają z wozu podczas danego sprintu, a ty zbierasz je w późniejszych sprintach.
Na przykład możesz skupić się na strukturach danych, aby rozpocząć rozwój, powiedzmy, tego wpisu zamówienia, o którym mówiłem. W późniejszym sprincie możesz wrócić i wypełnić dane, takie jak część dokumentacji słownika danych wokół niektórych utworzonych przez siebie artefaktów. Nie dokończycie tej definicji w jednym sprincie; zamierzasz stopniowo zwiększać swoje wyniki, ponieważ będą chwile, kiedy będziesz mógł uzupełnić te informacje pracując z analitykami biznesowymi, gdy programiści będą zajęci budowaniem aplikacji i utrzymaniem się wokół tych magazynów danych. Chcesz ułatwić, a nie być wąskim gardłem. Istnieją różne sposoby współpracy z programistami. W przypadku niektórych rzeczy mamy wzorce projektowe, więc jesteśmy pełnym uczestnikiem z góry, więc możemy mieć wzór projektowy, w którym powiemy, że umieścimy go w modelu, wypchniemy go do baz danych piaskownicy programistów, a następnie będą mogli zacznij z nim pracować i poproś o zmiany.
Mogą istnieć inne obszary, nad którymi pracują programiści, mają coś, nad czym pracują i prototypują pewne rzeczy, więc wypróbowują niektóre rzeczy we własnym środowisku programistycznym. Bierzemy bazę danych, z którą pracowali, wprowadzamy ją do naszego narzędzia do modelowania, porównujemy z modelami, które mamy, a następnie rozwiązujemy i wypychamy zmiany z powrotem do nich, aby mogli refaktoryzować swoje kody, aby postępowali zgodnie z odpowiednimi strukturami danych że potrzebujemy. Ponieważ mogli stworzyć pewne rzeczy, które już mieliśmy gdzie indziej, dlatego upewniamy się, że działają z odpowiednimi źródłami danych. Po prostu iterujemy przez całą drogę do naszego sprintu, abyśmy otrzymali pełne dane, pełną dokumentację i definicję wszystkich tworzonych przez nas struktur danych.
Najbardziej zwinne projekty, w które byłem zaangażowany pod względem bardzo dobrych dostaw, to filozofia, modelowanie wszystkich zmian w pełnej specyfikacji fizycznej bazy danych. Zasadniczo model danych staje się wdrożonymi bazami danych, z którymi pracujesz dla wszystkiego, co tworzymy, i ma pełne odniesienia do innych magazynów danych, jeśli korzystamy z innych zewnętrznych baz danych. W ramach tego produkujemy skrypty przyrostowe, a nie za każdym razem wykonujemy pełne pokolenie. I wykorzystujemy nasze wzorce projektowe, aby zapewnić nam szybkie przyspieszenie w zakresie sprintu z różnymi zespołami programistycznymi, z którymi współpracujemy.
Również w działaniach sprintu znów jest ta podstawa do porównania / scalenia, więc zastanówmy się nad modelowaniem każdej zmiany. Za każdym razem, gdy dokonujemy zmiany, chcemy modelować zmianę, a to, co bardzo ważne, czego brakowało w modelowaniu danych do niedawna, w rzeczywistości, dopóki go nie wprowadziliśmy, to możliwość skojarzenia modelowania zadania i twoje produkty wraz z historiami użytkowników i zadaniami, które faktycznie powodują te zmiany. Chcemy mieć możliwość sprawdzania zmian w naszym modelu, w taki sam sposób, w jaki programiści sprawdzają swoje kody, odwołując się do tych historii użytkowników, dzięki czemu wiemy, dlaczego wprowadziliśmy zmiany, to jest coś, co robimy. Gdy to robimy, generujemy nasze przyrostowe skrypty DDL i publikujemy je, aby można je było pobrać z innymi programami do dostarczenia i sprawdzić w naszym rozwiązaniu kompilacyjnym. Ponownie możemy mieć jeden model lub pracować z wieloma zespołami. I jak już mówiłem, niektóre rzeczy pochodzą od projektanta danych, inne pochodzą od programistów, a my spotykamy się w środku, aby wymyślić najlepszy najlepszy projekt i popchnąć go do przodu i upewnić się, że jest odpowiednio zaprojektowany w naszym ogólne struktury danych. Musimy utrzymać dyscyplinę polegającą na zapewnieniu, że mamy wszystkie odpowiednie konstrukcje w naszym modelu danych w miarę postępów, w tym rzeczy takie jak wartości zerowe i zerowe, ograniczenia referencyjne, w zasadzie sprawdzanie ograniczeń, wszystkie te rzeczy, o których zwykle myślimy .
Porozmawiajmy teraz o kilku zrzutach ekranu niektórych narzędzi, które nam w tym pomogą. Uważam, że ważne jest posiadanie tego repozytorium współpracy, więc to, co możemy zrobić jako modelerzy danych - i to jest fragment części modelu danych w tle - to wtedy, gdy pracujemy nad rzeczami, które chcemy mieć pewność, że możemy pracować tylko nad obiektami, które musimy zmienić, wprowadzać modyfikacje, generować nasze skrypty DDL dla zmian, które wprowadziliśmy podczas sprawdzania rzeczy. Więc możemy to zrobić, w ER Studio jest przykładem, możemy sprawdzać obiekty lub grupy obiektów do pracy, nie musimy sprawdzać całego modelu lub podmodelu, możemy sprawdzić tylko te rzeczy, które nas interesują. To, czego chcemy później, to albo przy kasie, albo przy odprawie - robimy to w obie strony, ponieważ różne zespoły programistyczne działają na różne sposoby. Chcemy mieć pewność, że skojarzymy to z historią użytkownika lub zadaniem, które określają wymagania w tym zakresie, i będzie to ta sama historia użytkownika lub zadanie, które opracują i sprawdzą kod.
Oto bardzo krótki fragment kilku ekranów jednego z naszych centrów zarządzania zmianami. To, co to robi, nie będę tutaj szczegółowo omawiać, ale to, co widzisz, to historia użytkownika lub zadanie i wcięte pod każdym z tych, które widzisz rzeczywiste rekordy zmian - utworzyliśmy automatyczny rekord zmian, gdy dokonujemy odprawy i wymeldowania, a także możemy umieścić więcej opisu w rejestrze zmian. Jest to związane z zadaniem, możemy wprowadzić wiele zmian na zadanie, tak jak można się spodziewać. A kiedy przejdziemy do tego zapisu zmian, możemy na niego spojrzeć i, co ważniejsze, zobaczyć, co właściwie zmieniliśmy? W przypadku tej konkretnej, wyróżnionej historii miałem jeden rodzaj zmiany, która została dokonana, a kiedy spojrzałem na sam faktyczny rekord zmian, zidentyfikował on poszczególne elementy w modelu, który się zmienił. Zmieniłem tutaj kilka atrybutów, zmieniłem ich kolejność i przyniosłem podczas jazdy widoki, które musiały zostać zmienione, które również były zależne od nich, aby były generowane w przyrostowej bibliotece DLL. To nie tylko modelowanie na obiektach bazowych, ale także narzędzie do modelowania o dużej mocy, takie jak ten, wykrywa również zmiany, które muszą zostać zgniecione przez obiekty zależne w bazie danych lub modelu danych.
Jeśli pracujemy z programistami i robimy to w kilku różnych rzeczach, to znaczy robimy coś w ich piaskownicy i chcemy porównać i zobaczyć, gdzie są różnice, korzystamy z funkcji porównywania / scalania po prawej i lewej stronie bok. Możemy powiedzieć: „Oto nasz model po lewej stronie, tutaj jest ich baza danych po prawej stronie, pokaż mi różnice”. Następnie możemy wybrać i wybrać sposób rozwiązania tych różnic, niezależnie od tego, czy wepchniemy rzeczy do bazy danych, czy są pewne rzeczy, które mają w bazie danych, które przywracamy do modelu. Możemy przejść w obie strony, więc możemy iść w obie strony jednocześnie aktualizując zarówno źródło, jak i cel, a następnie tworzyć przyrostowe skrypty DDL w celu wdrożenia tych zmian w samym środowisku bazy danych, co jest niezwykle ważne. Możemy również skorzystać z tej możliwości porównywania i scalania w dowolnym momencie, jeśli robimy migawki po drodze, zawsze możemy porównać początek jednego sprintu do początku lub końca innego sprintu, abyśmy mogli zobaczyć pełna przyrostowa zmiana tego, co zostało zrobione w danym sprincie rozwojowym lub w serii sprintów.
Jest to bardzo szybki przykład skryptu alter, każdy z was, który pracował z bazami danych, widział tego typu rzeczy, właśnie to możemy wypchnąć z kodu jako skrypt alter, aby upewnić się, że zachowaj rzeczy tutaj. To, co wyciągnąłem stąd, aby zredukować bałagan, to także to, co robimy z tymi skryptami alter. Zakładamy, że w tych tabelach są również dane, więc wygenerujemy również DML, który pobierze informacje z tabel tymczasowych i wepchnij go z powrotem również do nowych struktur danych, abyśmy oglądali nie tylko struktury, ale także dane, które mogliśmy już zawierać w tych strukturach.
Zamierzamy bardzo szybko mówić o automatycznych systemach kompilacji, ponieważ kiedy wykonujemy zwinny projekt, często pracujemy z automatycznymi systemami kompilacji, w których musimy wspólnie sprawdzać różne produkty, aby upewnić się, że nie zepsujemy naszych kompilacji. Oznacza to, że synchronizujemy wyniki, te skrypty zmian, o których mówiłem ze skryptem DDL, muszą być zalogowane, odpowiedni kod aplikacji musi zostać zarejestrowany w tym samym czasie, a wielu programistów teraz nie jest wykonywane bezpośrednio SQL na bazach danych i tego typu rzeczy. Dość często korzystamy z ram trwałości lub budujemy usługi danych. Musimy upewnić się, że zmiany tych ram lub usług są rejestrowane dokładnie w tym samym czasie. W niektórych organizacjach wchodzą do zautomatyzowanego systemu kompilacji, a jeśli kompilacja się zepsuje, zgodnie ze zwinną metodologią, wszystko zależy od tego, jak naprawić talię, zanim przejdziemy do przodu, abyśmy wiedzieli, że mamy działające rozwiązanie, zanim przejdziemy dalej. I w jednym z projektów, w które byłem zaangażowany, doprowadziliśmy to do skrajności - jeśli kompilacja się zepsuła, to faktycznie podłącziliśmy się do wielu komputerów w naszej okolicy, gdzie byliśmy kolokowani z użytkownikami biznesowymi, mieliśmy czerwone migające światła tylko jak góra radiowozów. A jeśli kompilacja się zepsuła, te czerwone migające światła zaczęły gasnąć i wiedzieliśmy, że to wszystko ręce na pokładzie: napraw kompilację, a następnie kontynuuj to, co robiliśmy.
Chcę porozmawiać o innych rzeczach, a jest to wyjątkowa funkcja dla ER Studio, to naprawdę pomaga, gdy próbujemy budować te artefakty jako programiści dla tych granic trwałości, mamy koncepcję zwaną obiektami danych biznesowych i tym, co pozwala nam zrobić, jeśli spojrzysz na ten bardzo uproszczony model danych jako przykład, pozwala on na enkapsulację encji lub grup encji, dla których są granice trwałości. Gdy my, jako modeler danych, możemy pomyśleć o czymś takim jak nagłówek zamówienia zakupu i wyrównywanie zamówienia oraz inne szczegółowe tabele, które by się z tym wiązały w sposób, w jaki go budujemy, a nasi programiści usług danych muszą wiedzieć, jak zachowują się te różne dane Struktury. Nasi programiści myślą o takich rzeczach jak zamówienie zakupu jako o ogólnym obiekcie i jaka jest ich umowa z tym, jak tworzą te konkretne obiekty. Możemy ujawnić ten szczegół techniczny, aby osoby budujące serwery danych mogły zobaczyć, co się pod nim znajduje, i możemy chronić innych odbiorców przed złożonością, aby po prostu zobaczyli różne obiekty wyższego poziomu, co również bardzo dobrze sprawdza się w komunikacji z biznesem analityków i interesariuszy biznesowych, gdy mówimy o interakcji różnych koncepcji biznesowych.
Przyjemną rzeczą jest również to, że konstruktywnie je rozwijamy i zwijamy, abyśmy mogli zachować relacje między obiektami wyższego rzędu, nawet jeśli pochodzą one z konstrukcji zawartych w samych obiektach danych biznesowych. Teraz, jako modelarz, dotrzyj do końca sprintu, na końcu podsumowania sprintu mam wiele rzeczy do zrobienia, które nazywam sprzątaniem na następny sprint. Przy każdym sprincie tworzę coś, co nazywam Nazwanym Wydaniem - to daje mi podstawę do tego, co mam teraz na końcu wydania. Oznacza to, że moja linia bazowa idzie naprzód, wszystkie te linie bazowe lub nazwane wersje, które tworzę i zapisuję w moim repozytorium, mogę użyć do porównania / scalenia, dzięki czemu zawsze mogę porównać do dowolnego końca sprintu z dowolnego innego sprintu, który bardzo ważne jest, aby wiedzieć, jakie były zmiany w modelu danych podczas jego podróży.
Tworzę również skrypt delta DDL przy użyciu porównania / scalania ponownie od początku do końca sprintu. Być może sprawdziłem całą masę skryptu przyrostowego, ale jeśli go potrzebuję, mam teraz skrypt, który mogę wdrożyć, aby postawić inne piaskownice, więc mogę powiedzieć, że to właśnie mieliśmy na początku jednego sprintu, push przez to, zbuduj bazę danych jako piaskownicę, aby rozpocząć od następnego sprintu, a my możemy również używać tych rzeczy do robienia rzeczy takich jak stand-owe instancje QA i ostatecznie chcemy oczywiście wypchnąć nasze zmiany do produkcji, więc mamy wiele rzeczy do zrobienia w tym samym czasie. Ponownie w pełni uczestniczymy w planowaniu sprintu i retrospekcjach, retrospektywy to tak naprawdę wyciągnięte wnioski i jest to niezwykle ważne, ponieważ możesz bardzo szybko zacząć sprawnie, musisz zatrzymać i świętować sukcesy, jak teraz. Dowiedz się, co jest nie tak, popraw go następnym razem, ale także świętuj rzeczy, które poszły dobrze i buduj na nich, idąc naprzód w kolejnych sprintach.
Teraz będę bardzo szybko mówił o wartości biznesowej. Był projekt, w który zaangażowałem się wiele lat temu, który rozpoczął się jako projekt zwinny, i był to projekt ekstremalny, więc był to czysty samoorganizujący się zespół, w którym tylko programiści robili wszystko. Krótko mówiąc, ten projekt był opóźniony i odkryli, że spędzają coraz więcej czasu na naprawianiu i naprawianiu zidentyfikowanych wad, niż na rozwijaniu większej funkcjonalności i, w rzeczywistości, kiedy spojrzeli na nią na podstawie na wykresach wypalenia musieliby przedłużyć projekt o sześć miesięcy ogromnym kosztem. A kiedy spojrzeliśmy na to, sposobem na rozwiązanie tego problemu było wykorzystanie odpowiedniego narzędzia do modelowania danych z wykwalifikowanym projektantem danych zaangażowanym w sam projekt.
Jeśli spojrzysz na ten pionowy pasek na tym konkretnym wykresie, pokazuje on skumulowane defekty w porównaniu z obiektami skumulowanymi, a ja mówię o obiektach danych lub konstrukcjach, które zostały utworzone, takie jak tabele z ograniczeniami i tego typu rzeczy, jeśli spojrzysz na zanim modeler danych został wprowadzony, liczba defektów faktycznie przekraczała i zaczęła się tworzyć luka w stosunku do faktycznej liczby obiektów, które zostały wyprodukowane do tego momentu. Po 21 tygodniu, kiedy to pojawił się modelarz danych, dokonał przebudowy modelu danych w oparciu o to, co było, aby naprawić wiele rzeczy, a następnie zaczął modelować w ramach zespołu projektowego idącego naprzód, zmiany w miarę postępu projektu . Widziałeś bardzo szybki zwrot, który w ciągu około półtora sprintu zaobserwowaliśmy ogromny wzrost liczby obiektów i konstrukcji danych, które były generowane i konstruowane, ponieważ generowaliśmy z narzędzia do modelowania danych, a nie z kija programisty budując je w środowisku, i były one poprawne, ponieważ miały odpowiednią integralność referencyjną i inne konstrukcje, które powinna mieć. Poziom wad w stosunku do tych prawie płaskich. Podejmując odpowiednie działanie i upewniając się, że modelowanie danych było w pełni zaangażowane, projekt został dostarczony na czas ze znacznie wyższym poziomem jakości, aw rzeczywistości nie zostałby zrealizowany, gdyby te kroki nie zostały wykonane. Istnieje wiele zwinnych niepowodzeń, jest też wiele zwinnych sukcesów, jeśli zaangażujesz odpowiednich ludzi na odpowiednich stanowiskach. Jestem wielkim zwolennikiem zwinności jako dyscypliny operacyjnej, ale musisz upewnić się, że masz umiejętności wszystkich odpowiednich grup zaangażowanych w zespoły projektowe, gdy postępujesz naprzód w zwinnym przedsięwzięciu.
Podsumowując, architekci danych i projektanci muszą być zaangażowani we wszystkie projekty rozwojowe; naprawdę są klejem, który trzyma wszystko razem, ponieważ jako projektanci danych i architekci rozumiemy, nie tylko konstrukcje danych danego projektu programistycznego, ale także to, gdzie dane istnieją w organizacji i skąd możemy je pozyskiwać, a także w jaki sposób będzie wykorzystywany i wykorzystywany poza konkretną aplikacją, nad którą pracujemy. Rozumiemy złożone relacje danych i niezwykle ważne jest, aby móc iść naprzód, a także z perspektywy zarządzania mapować dokument i rozumieć, jak wygląda Twój pełny krajobraz danych.
To jest jak produkcja; Pochodzę z zaplecza produkcyjnego. Na końcu nie można sprawdzić jakości czegoś - musisz z góry wbudować jakość w projekt i przejść przez niego, a modelowanie danych jest sposobem na włączenie tej jakości do projektu w sposób wydajny i opłacalny przez cały czas . I znowu, coś do zapamiętania - i to nie jest banalne, ale to prawda - aplikacje przychodzą i odchodzą, dane są istotnym zasobem korporacyjnym i przekraczają wszystkie granice aplikacji. Za każdym razem, gdy instalujesz aplikację, prawdopodobnie jesteś proszony o zachowanie danych w innych aplikacjach, które pojawiły się wcześniej, więc musimy tylko pamiętać, że jest to ważny zasób korporacyjny, który utrzymujemy z czasem.
I to wszystko! Odtąd zadamy więcej pytań.
Eric Kavanagh: Dobra, dobrze, pozwól mi najpierw przekazać Robin. A potem, Dez, jestem pewien, że masz kilka pytań. Zabierz to, Robin.
Dr Robin Bloor: OK. Szczerze mówiąc, nigdy nie miałem problemu ze zwinnymi metodami programowania i wydaje mi się, że to, co tu robisz, ma sens. Pamiętam, jak patrzyłem na coś z lat osiemdziesiątych, które naprawdę wskazywało, że problem, na który się natknąłeś, polegający na wymykaniu się spod kontroli projektu, zwykle polega na tym, że pozwalasz, aby błąd utrzymywał się poza określonym etapem. Staje się to coraz trudniejsze do naprawienia, jeśli nie uda Ci się uzyskać właściwego poziomu, więc jedną z rzeczy, które tutaj robisz - i myślę, że to jest slajd - ale jedną z rzeczy, które tutaj robisz w sprincie zero jest moim zdaniem absolutnie ważne, ponieważ naprawdę próbujesz przypiąć tam elementy dostawy. A jeśli nie dostaniesz wyników, wówczas zmieniają kształt.
To w pewnym sensie moja opinia. To także moja opinia - naprawdę nie mam żadnych argumentów na temat tego, że musisz przejść do modelowania danych na określonym poziomie szczegółowości, zanim przejdziesz dalej. Chciałbym, abyś spróbował to zrobić, ponieważ nie do końca go zrozumiałem, to po prostu opisz jeden z tych projektów pod względem jego wielkości, sposobu, w jaki przebiegło, pod względem tego, kto, wiesz, gdzie pojawiły się problemy, czy zostały rozwiązane? Ponieważ myślę, że ten slajd jest w zasadzie jego sercem i jeśli mógłbyś rozwinąć nieco więcej na ten temat, byłbym bardzo wdzięczny.
Ron Huizenga: Jasne, a ja skorzystam z kilku przykładowych projektów. Ten, który w pewnym sensie zszedł z toru, który został przywrócony przez faktyczne zaangażowanie właściwych ludzi i wykonanie modelowania danych, a wszystko było naprawdę sposobem upewnienia się, że projekt został lepiej zrozumiany i oczywiście mieliśmy lepszy projekt implementacji w drodze przez modelowanie. Ponieważ, gdy go modelujesz, wiesz, że możesz wygenerować swój DDL i wszystko z tyłu i z narzędzia, zamiast konieczności ciągłego budowania tego, jak to zwykle robią ludzie, przechodząc bezpośrednio do środowiska bazy danych. Typowe rzeczy, które mogą się wydarzyć programistom, to to, że tam wejdą i powiedzą: dobra, potrzebuję tych tabel. Powiedzmy, że dokonujemy wpisów zamówień. Mogą więc utworzyć nagłówek zamówienia i tabele szczegółów zamówienia oraz tego rodzaju rzeczy. Ale często zapominają lub zaniedbują, aby upewnić się, że istnieją ograniczenia reprezentujące relacje klucza obcego. Mogą nie mieć poprawnych kluczy. Konwencje nazewnictwa również mogą być podejrzane. Nie wiem, ile razy wchodziłem do środowiska, na przykład, gdzie widzisz kilka różnych tabel o różnych nazwach, ale wtedy nazwy kolumn w tych tabelach są jak ID, Nazwa lub cokolwiek innego, więc naprawdę straciłem kontekst bez tabeli dokładnie tego, co to jest.
Tak więc zazwyczaj podczas modelowania danych upewniamy się, że stosujemy odpowiednie konwencje nazewnictwa również do wszystkich artefaktów generowanych w DDL. Ale bardziej szczegółowo mówiąc o naturze samych projektów, ogólnie mówiąc, mówię o dość dużych inicjatywach. Jednym z nich był projekt transformacji biznesu o wartości 150 milionów dolarów, w którym wymieniliśmy kilkanaście starszych systemów. Równocześnie działało pięć różnych zwinnych zespołów. Miałem zespół ds. Architektury danych, więc miałem modelarzy danych z mojego zespołu osadzonych w każdym innym zespole obszaru aplikacji, i pracowaliśmy z kombinacją wewnętrznych ekspertów biznesowych, którzy znali temat, robiąc historie użytkowników dotyczące samych wymagań. W każdym z zespołów mieliśmy analityków biznesowych, którzy faktycznie modelowali proces biznesowy, wraz ze schematami aktywności lub diagramami procesów biznesowych, pomagając w dalszym rozwijaniu historii użytkowników wraz z użytkownikami, zanim zostaną pochłonięci przez resztę zespołu.
A potem oczywiście programiści, którzy budowali kod aplikacji ponad tym. Pracowaliśmy również z, myślę, że czterech różnych dostawców integracji systemów budowało różne części aplikacji, a także jeden zespół budował usługi danych, drugi budował logikę aplikacji w jednym obszarze, inny, który miał wiedzę specjalistyczną w innym obszarze biznesowym budowano logikę aplikacji w tym obszarze. Więc mieliśmy całą współpracę ludzi, którzy pracowali nad tym projektem. W tym konkretnym przypadku mieliśmy 150 osób na lądzie w zespole i kolejne 150 zasobów na morzu w zespole, którzy współpracowali dwutygodniowe sprinty, aby wyprzeć to. Aby to zrobić, musisz upewnić się, że strzelasz do wszystkich cylindrów, a wszyscy są dobrze zsynchronizowani pod względem tego, jakie są ich produkty dostawy, i miałeś te częste resetowania, aby upewnić się, że realizujemy dostawy wszystkich niezbędnych artefaktów na koniec każdego sprintu.
Dr Robin Bloor: Cóż, to imponujące. I po prostu trochę więcej szczegółów na ten temat - czy na końcu tego projektu powstała kompletna mapa MDM całego obszaru danych na końcu tego projektu?
Ron Huizenga: Mieliśmy kompletny model danych, który został rozbity wraz z rozkładem między różnymi obszarami biznesowymi. Sam słownik danych pod względem pełnych definicji był nieco za krótki. Zdefiniowaliśmy większość tabel; zdefiniowaliśmy większość kolumn pod kątem ich dokładnego znaczenia. Niektórych nie było i, co ciekawe, wiele z nich to informacje pochodzące ze starszych systemów, w których po zakończeniu samego zakresu projektu wciąż dokumentowano je jako zbiór artefakty, jak gdyby, poza samym projektem, ponieważ było to coś, co musiało być utrzymywane przez organizację idącą naprzód. Jednocześnie organizacja przyjęła znacznie większy punkt widzenia na znaczenie zarządzania danymi, ponieważ zauważyliśmy wiele niedociągnięć w tych starszych systemach i źródłach danych, które próbowaliśmy wykorzystać, ponieważ nie zostały one udokumentowane. W wielu przypadkach mieliśmy tylko bazy danych, które musieliśmy poddać inżynierii wstecznej i spróbować dowiedzieć się, co tam było i do czego służyły informacje.
Dr Robin Bloor: Nie dziwi mnie ten szczególny aspekt. Zarządzanie danymi jest, nazwijmy to, bardzo nowoczesnym problemem i myślę, że naprawdę jest wiele pracy, która, powiedzmy, powinna była zostać wykonana historycznie w zakresie zarządzania danymi. Nigdy nie było tak, ponieważ można było uniknąć tego. Ale ponieważ zasoby danych po prostu rosły i rosły, ostatecznie nie mogłeś.
W każdym razie przekażę Dezowi, bo myślę, że mam przydzielony czas. Dez?
Dez Blanchfield: Tak, dziękuję. Przez to wszystko obserwuję i myślę sobie, że mówimy o zwinności używanej w gniewie na wiele sposobów. Chociaż ma to negatywne skojarzenia; Miałem to na myśli pozytywnie. Czy mógłbyś po prostu podać nam scenariusz, mam na myśli, że są dwa miejsca, w których widzę, że jest to idealny zestaw: jeden to nowe projekty, które trzeba wykonać już od pierwszego dnia, ale myślę, że niezmiennie, z mojego doświadczenia, często na przykład, gdy projekty stają się na tyle duże, że jest to konieczne na wiele sposobów, istnieje ciekawe wyzwanie między sklejeniem dwóch światów, prawda? Czy możesz dać nam wgląd w historie sukcesu, które widziałeś, gdzie udałeś się do organizacji, stało się jasne, że mieli oni do czynienia z lekkim zderzeniem dwóch światów i udało ci się to miejsce i łączy duże projekty tam, gdzie mogłyby pójść na szyny? Wiem, że jest to bardzo szerokie pytanie, ale zastanawiam się tylko, czy istnieje jakieś studium przypadku, które może, w pewnym sensie, wskazać miejsce, w którym powiedziałeś, wiesz, umieściliśmy to wszystko na miejscu i zgromadził cały zespół programistów wraz z zespół danych, a my zajęliśmy się czymś, co mogłoby zatopić łódź?
Ron Huizenga: Jasne, i tak naprawdę, jednym projektem, który okazał się projektem rurociągowym, był ten, o którym wspomniałem, gdzie pokazałem tę tabelę z wadami przed i po zaangażowaniu modelarza danych. Dość często i istnieją z góry przyjęte koncepcje, szczególnie jeśli rzeczy są rozwiązywane tam, gdzie jest to robione z czysto programistycznej perspektywy, to tylko programiści są zaangażowani w te zwinne projekty dostarczania aplikacji. Tak więc to, co się tam wydarzyło, polegało na tym, że zjechali z szyn, a w szczególności ich artefakty danych, lub wytwarzane przez nich dane dostarczające dane, nie spełniły oczekiwań pod względem jakości i naprawdę zajęły się ogólnymi sprawami. I często zdarza się to błędne przekonanie, że projektanci danych spowolnią projekty, i zrobią to, jeśli projektant danych nie będzie miał właściwego podejścia. Tak jak mówię, musisz stracić - czasem są modelerzy danych, którzy mają tradycyjne podejście odźwiernego, gdy „Jesteśmy tutaj, aby kontrolować wygląd struktur danych” i ta mentalność musi zniknąć. Każdy, kto jest zaangażowany w sprawny rozwój, a zwłaszcza projektanci danych, musi wziąć udział w roli facylitatora, aby naprawdę pomóc zespołom w rozwoju. A najlepszym sposobem zilustrowania tego jest bardzo szybkie pokazanie zespołom, jak mogą być wydajne, najpierw modelując zmiany. I znowu dlatego mówiłem o współpracy.
Istnieje kilka rzeczy, które możemy najpierw wymodelować i wygenerować DDL, aby przekazać je programistom. Chcemy również upewnić się, że nie czują się ograniczeni. Jeśli więc istnieją rzeczy, nad którymi pracują, pozwól im dalej pracować w ich piaskownicach programistycznych, ponieważ tam programiści pracują nad własnymi komputerami stacjonarnymi lub innymi bazami danych, aby wprowadzić zmiany w miejscach, w których testują. I współpracuj z nimi i powiedz: „Dobra, pracuj z tym”. Wprowadzimy to do narzędzia, rozwiążemy go, a następnie popchniemy do przodu i podamy skrypty, które możesz wdrożyć, aby zaktualizować bazy danych, aby zaktualizować je do tego, jaki będzie rzeczywisty sankcjonowany rzeczywisty widok produkcji, gdy będziemy kontynuować prace. Możesz to szybko zmienić. Przekonałem się, że moje dni były wypełnione, gdy tylko chodziłem tam iz powrotem, iterując z różnymi zespołami programistów, patrząc na zmiany, porównując, generując skrypty, uruchamiając je, i byłem w stanie dość łatwo utrzymać się z czterema zespołami programistów, kiedy tylko osiągnął impet.
Dez Blanchfield: Jedną z rzeczy, które przychodzą mi na myśl, jest to, że, wiesz, wiele rozmów, które codziennie przeprowadzam, dotyczą tego pociągu towarowego, który przyjeżdża do nas w pewnym sensie -machine i IoT. A jeśli uważamy, że mamy teraz dużo danych na temat naszego obecnego środowiska w przedsiębiorstwie, wiesz, jeśli weźmiemy jednorożce na bok, gdy wiemy, że Googles, Facebook i Uber mają petabajty danych, ale w tradycyjnym przedsiębiorstwie mówimy o wciąż setkach terabajtów i dużej ilości danych. Ale moim zdaniem ten pociąg towarowy przyjeżdża do organizacji, a dr Robin Bloor nawiązywał do niego wcześniej o IoT. Wiesz, mamy duży ruch w sieci, mamy ruch społecznościowy, mamy teraz mobilność i urządzenia mobilne, chmura jakby eksplodowała, ale teraz mamy inteligentną infrastrukturę, inteligentne miasta i cały ten świat danych właśnie eksplodował.
W przypadku codziennej organizacji, od średniej do dużej organizacji, która tam siedzi i widzi ten świat bólu, przychodzi do nich i nie ma bezpośredniego planu, jakie są niektóre rzeczy, w zaledwie kilku zdaniach, które można by umieścić do nich, kiedy i gdzie powinni zacząć rozmawiać na temat wprowadzenia niektórych z tych metod. Jak wcześnie muszą zacząć planować, aby prawie usiąść i zwrócić uwagę i powiedzieć, że jest to właściwy czas, aby przygotować narzędzia i przeszkolić zespół i porozmawiać z wokalistą o tym wyzwaniu? Jak późno w historii jest za późno lub kiedy jest za wcześnie? Jak to wygląda dla niektórych organizacji, które widzisz?
Ron Huizenga: W przypadku większości organizacji powiedziałbym, że jeśli jeszcze tego nie zrobili i nie dostosowali modelowania danych i architektury danych za pomocą potężnych narzędzi takich jak ten, czas, który muszą to zrobić, to wczoraj. Ponieważ interesujące jest to, że nawet dzisiaj, kiedy patrzysz na dane w organizacjach, mamy tak dużo danych w naszych organizacjach i ogólnie mówiąc, w oparciu o niektóre ankiety, które widzieliśmy, skutecznie wykorzystujemy mniej niż pięć procent tych danych kiedy patrzymy na organizacje. Dzięki IoT, a nawet NoSQL, duże zbiory danych - nawet jeśli nie są to tylko Internet przedmiotów, ale ogólnie duże zbiory danych - gdzie zaczynamy teraz konsumować jeszcze więcej informacji pochodzących spoza naszej organizacji, wyzwanie staje się coraz większe cały czas. Jedynym sposobem, w jaki mamy szansę poradzić sobie z tym, jest pomoc w zrozumieniu, o co chodzi z tymi danymi.
Tak więc przypadek użycia jest nieco inny. To, co robimy, polega na tym, że kiedy patrzymy na te dane, przechwytujemy je, musimy je poddać inżynierii wstecznej, zobaczyć, co jest w nich, czy to w naszych jeziorach danych, czy nawet w naszych wewnętrznych bazach danych, syntezując to, co danych, zastosuj do nich znaczenie i definicje, abyśmy mogli zrozumieć, czym są dane. Ponieważ dopóki nie zrozumiemy, co to jest, nie możemy zagwarantować, że używamy go poprawnie lub odpowiednio. Więc naprawdę musimy zrozumieć, co to za dane. Inną częścią jest to, że nie rób tego, ponieważ możesz, jeśli chodzi o zużycie wszystkich tych danych zewnętrznych, upewnić się, że masz przypadek użycia, który obsługuje korzystanie z tych danych zewnętrznych. Skoncentruj się na rzeczach, których potrzebujesz, a nie tylko próbuj wyciągać i wykorzystywać rzeczy, które mogą być później potrzebne. Skoncentruj się najpierw na ważnych rzeczach, a gdy będziesz je przechodzić, zaczniesz konsumować i próbować zrozumieć inne informacje z zewnątrz.
Doskonałym przykładem tego jest to, że wiem, że mówimy o IoT i czujnikach, ale ten sam problem występuje w wielu organizacjach od wielu lat, nawet przed IoT. Każdy, kto ma system kontroli produkcji, bez względu na to, czy jest firmą zajmującą się produkcją rurociągów, produkcją, jak i firmami procesowymi, które mają automatyzację sterowania i używają strumieni danych itp. te węże ognia danych, z których próbują wypić, aby dowiedzieć się, jakie zdarzenia wystąpiły w moim sprzęcie produkcyjnym, aby zasygnalizować - co się stało i kiedy? A wśród tego ogromnego strumienia danych są tylko określone informacje lub tagi, którymi są zainteresowani, które muszą przesiać, syntezować, modelować i rozumieć. I mogą zignorować resztę, dopóki nie przyjdzie czas, aby naprawdę to zrozumieć, a następnie mogą rozszerzyć swój zakres, aby przyciągnąć coraz więcej tego zakresu, jeśli ma to sens.
Dez Blanchfield: Rzeczywiście. Chciałbym zadać jedno pytanie, które zadał dżentelmen o imieniu Eric i rozmawialiśmy o tym na osobności. Właśnie poprosiłem o pozwolenie, które mu dał, aby cię o to poprosić. Ponieważ to ładnie do tego prowadzi, po prostu podsumujmy, ponieważ teraz trochę się zmieniamy, a ja wrócę do Erica. Ale pytanie innego Erica brzmiało: czy uzasadnione jest założenie, że właściciele startupu znają i rozumieją wyjątkowe wyzwania związane z terminologią modelowania, czy też należy go przekazać komuś innemu do interpretacji? Innymi słowy, czy start-up powinien być zdolny i gotowy, chętny i zdolny do skupienia się na tym? Czy jest to coś, co prawdopodobnie powinni kupić i zabrać ze sobą ekspertów?
Ron Huizenga: Myślę, że krótka odpowiedź brzmi: to naprawdę zależy. Jeśli jest to startup, w którym nie ma kogoś, kto jest architektem lub projektantem danych, który naprawdę rozumie bazę danych, to najszybszym sposobem na rozpoczęcie jest przyniesienie kogoś z doświadczeniem w zakresie konsultacji, który jest bardzo dobrze zorientowany w tej przestrzeni i może uzyskać idą. Ponieważ to, co znajdziesz - i faktycznie zrobiłem to przy wielu zadaniach, które zrobiłem, zanim przeszedłem na ciemną stronę w zarządzaniu produktem - to bym poszedł do organizacji jako konsultant, kierował ich zespołami architektury danych, aby mogli, w pewnym sensie, ponownie skupić się na sobie i przeszkolić swoich ludzi, jak robić tego rodzaju rzeczy, aby podtrzymywali to i kontynuowali misję. A potem przejdę do następnego zaręczyn, jeśli ma to sens. Jest wielu ludzi, którzy to robią, którzy mają bardzo dobre doświadczenia z danymi, które mogą im pomóc.
Dez Blanchfield: To świetny punkt na wynos i całkowicie się z tym zgadzam i jestem pewien, że doktor Robin Bloor również by to zrobił. Zwłaszcza w startupie koncentrujesz się na byciu MŚP w zakresie szczególnej wartości oferty, którą chcesz zbudować w ramach samego biznesu startupowego i prawdopodobnie nie powinieneś być ekspertem od wszystkiego, więc świetna rada. Ale dziękuję bardzo, fantastyczna prezentacja. Naprawdę świetne odpowiedzi i pytania. Eric, oddam ci rękę, ponieważ wiem, że minęło już chyba dziesięć minut i wiem, że lubisz trzymać się blisko naszych okien czasowych.
Eric Kavanagh: W porządku. Mamy co najmniej kilka dobrych pytań. Pozwól, że ci je przekażę. Myślę, że odpowiedziałeś na kilka innych. Ale bardzo interesujące spostrzeżenie i pytanie jednego z uczestników, który pisze, czasem zwinne projekty, nie pozwalają modelarzowi danych na uzyskanie całego długoterminowego obrazu, więc kończą projektowanie czegoś w sprincie pierwszym, a następnie muszą przeprojektować w sprincie trzecim lub czwartym. Czy nie wydaje się, że przynosi to efekt przeciwny do zamierzonego? Jak możesz tego uniknąć?
Ron Huizenga: Charakter zwinności polega na tym, że nie uda ci się uzyskać wszystkiego absolutnie w danym sprincie. I to jest właściwie część ducha zwinności: praca z nim - będziesz robić prototypy, gdzie pracujesz nad kodem w danym sprincie i dokonasz udoskonaleń. Część tego procesu polega na tym, że dostarczasz rzeczy, które widzi użytkownik końcowy i mówi: „Tak, to jest blisko, ale naprawdę muszę to jeszcze zrobić.” Tak więc nie tylko wpływa to na funkcjonalny projekt samego kodu, ale dość często musimy modyfikować lub dodawać więcej struktur danych pod tymi niektórymi rzeczami, aby dostarczyć to, czego chce użytkownik. I to wszystko uczciwa gra i dlatego naprawdę chcesz korzystać z narzędzi o dużej mocy, ponieważ możesz bardzo szybko modelować i wprowadzać zmiany w narzędziu do modelowania, a następnie generować DDL dla bazy danych, z którą programiści mogą następnie pracować, aby dostarczyć to zmieniaj się jeszcze szybciej. Ratujesz ich przed koniecznym ręcznym kodowaniem struktur danych i pozwalasz im skoncentrować się na logice programowania lub aplikacji, w której są najbardziej biegli.
Eric Kavanagh: To ma sens. Kilka osób zadawało konkretne pytania dotyczące tego, jak to wszystko wiąże się z narzędziem. Wiem, że poświęciłeś trochę czasu na zapoznanie się z przykładami i pokazałeś zrzuty ekranu z tego, jak faktycznie wdrażasz niektóre z tych rzeczy. Jeśli chodzi o cały proces sprintu, jak często widzisz to w grze w organizacjach, a jak często widzisz bardziej tradycyjne procesy, w których rzeczy po prostu przebiegają i zabierają więcej czasu? Jak powszechne jest Twoje podejście do stylu sprintu?
Ron Huizenga: Myślę, że coraz częściej to widzimy. Wiem, że, powiedziałbym, prawdopodobnie w ciągu ostatnich 15 lat, widziałem znacznie więcej osób przyjmujących do wiadomości, że naprawdę potrzebują szybszej dostawy. Widziałem więc, jak coraz więcej organizacji skacze na zwinny modwagon. Niekoniecznie całkowicie; mogą zacząć od kilku projektów pilotażowych, aby udowodnić, że to działa, ale niektóre są nadal bardzo tradycyjne i trzymają się metody wodospadu. Dobra wiadomość jest taka, że narzędzia działają bardzo dobrze również w tych organizacjach w przypadku tego rodzaju metodologii, ale mamy możliwość dostosowania w narzędziu, aby ci, którzy wskakują na pokład, mieli narzędzia w zestawie narzędzi w opuszki palców. Rzeczy takie jak porównywanie i scalanie, takie jak funkcje inżynierii wstecznej, dzięki czemu mogą zobaczyć, jakie są istniejące źródła danych, dzięki czemu mogą bardzo szybko porównywać i generować przyrostowe skrypty DDL. A kiedy zaczynają to rozumieć i widzą, że mogą mieć produktywność, ich skłonność do przyjmowania zwinnych jeszcze większych wzrostów.
Eric Kavanagh: Cóż, to świetne rzeczy, ludzie. Właśnie opublikowałem link do slajdów tam w oknie czatu, więc sprawdź to; to trochę dla ciebie. Wszystkie te webcasty mamy do późniejszego obejrzenia. Podziel się nimi ze znajomymi i współpracownikami. I Ron, dziękuję bardzo za dzisiejszy czas, zawsze jesteś mile widziany w serialu - prawdziwy ekspert w tej dziedzinie i oczywiste jest, że znasz swoje rzeczy. Dzięki tobie i dzięki IDERA i, oczywiście, Dezowi i naszemu własnemu Robin Bloor.
I dzięki temu pożegnamy was, ludzie. Jeszcze raz dziękuję za poświęcony czas i uwagę. Rozumiemy, że trzymasz się przez 75 minut, to całkiem niezły znak. Dobry koncert, porozmawiamy z tobą następnym razem. PA pa.
