Zobrať: Hosť Eric Kavanagh diskutuje o dôležitosti modelovania údajov v agilnom vývoji s Robinom Bloorom, Dezom Blanchfieldom a Ronom IDizonom z IDERA.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Eric Kavanagh: Dobre, dámy a páni. Vitajte znova. Jeho stredu o 4:00 EST. To znamená, že je čas pre Hot Technologies. Ano, naozaj. Volám sa Eric Kavanagh, budem tvojím hostiteľom.
Pokiaľ ide o dnešnú tému, jedná sa o starú starú dobrotu. Zlepšuje sa každý deň, pretože jeho formovanie sveta správy údajov „Dátové modelovanie v agilnom prostredí.“ Naozaj je to snímka o vás, zasiahla ma na @eric_kavanagh. Mali by sme to naozaj dať na tú snímku. Musím sa k tomu dostať.
Takže horúce roky. Modelovanie údajov trvá donekonečna. Je to skutočne jadro a duša podnikania v oblasti správy informácií, navrhovanie dátových modelov, snaha porozumieť obchodným modelom a ich zosúladenie s vašimi dátovými modelmi. To je naozaj to, čo sa snažíte urobiť, však?
Dátový model predstavuje podnikanie zásadným spôsobom, ako teda menia všetky tieto nové zdroje údajov hru? Dozvedeli sme sa o tom viac. Chceli sme zistiť, ako môžete zostať na špičke agilným spôsobom. A to je samozrejme slovo roka.
Robin Bloors s nami, našim hlavným analytikom, Dez Blanchfieldom, ktorý volal zo Sydney, Austrálie a Ron Huizenga, senior produktovým manažérom z IDERA - dlhoročný môj priateľ, vynikajúci rečník v tomto priestore, pozná svoje veci, takže sa nemusíte hanbiť, opýtajte sa ho ťažké otázky, ľudia, tie ťažké. S tým urobím Robina moderátora a zoberiem ho preč.
Robin Bloor: Poriadku. Ďakujem ti za to, Eric. Musím povedať o modelovaní, ktoré si myslím, že som bol vo svete IT pred tým, ako existoval, v tom zmysle, že si v poisťovacej spoločnosti, pre ktorú som pracoval, pamätám, že sme prišli chlapa a dali nám všetkého druhu workshopu o tom, ako modelovať údaje. Pozerali sme sa teda na asi 30 rokov, je to 30 rokov? Možno ešte dlhšie, možno pred 35 rokmi. Dlhé, dlhodobé modelovanie bolo v skutočnosti súčasťou odvetvia a samozrejme nemá nič spoločné s dámami na móle.
To, čo som chcel povedať, pretože to, čo bežne robíme, je, že ja a Dez hovoríme o rôznych veciach a len som si myslel, že Id dáva všeobecný prehľad modelovaniu, ale je tu realita, ktorá sa teraz stáva zrejmejšou.
Máme, viete, veľkú dátovú realitu, máme viac údajov, viac zdrojov údajov, pretože sme dostali dátové toky, ktoré vstúpili do rovnice za posledné tri alebo štyri roky a začínajú ich získať väčšiu časť, a je tu väčšia potreba porozumieť údajom a zvýšená miera zmeny, čím viac údajov sa pridáva a tiež sa používa viac dátových štruktúr.
Je to zložitý svet. Tu je obrázok, čo je vlastne niečo, čo sme si vytvorili asi pred tromi rokmi, ale v podstate, akonáhle zahrniete streamovanie do mixu a získate predstavu o rafinérii údajov, dátovom centre, dátovom spojení alebo čokoľvek, uvidíte, že existujú údaje, ktoré sú skutočne v pokoji, v tom zmysle, že sa to príliš nepohybuje. A potom sú tu dáta, toky a všetky transakčné aplikácie a navyše v súčasnosti máte udalosti, dátové toky udalostí, ktoré sa vyskytujú v aplikáciách a možno budú musieť, a dnes, s architektúrami lambda, o ktorých sa hovorí všade, majú skutočne vplyv na iba celé pole údajov.
A dnes si myslíme, že existuje dátová vrstva. Dátová vrstva existuje nejakým virtuálnym spôsobom v tom zmysle, že jej dobrá časť by mohla byť v cloude a môže sa šíriť naprieč dátovými centrami, môže existovať na pracovných staniciach. Dátová vrstva je do určitej miery všade av tomto zmysle existujú procesy všade, ktoré sa takým alebo iným spôsobom pokúša spracovávať údaje a pohybovať nimi. Ale tiež vedieť, čo to je, keď sa pohybujete okolo, je veľká vec.
Ak sa pozrieme na modelovanie údajov v najobecnejšom zmysle, v spodnej časti tohto druhu zásobníka sú súbory a databázy. Máte dátové prvky, ktoré majú kľúče, definície prvkov, aliasy, synonymá, konkrétne fyzické formáty a potom máme túto vrstvu metadát.
Zaujímavé na metaúdajoch je to, že metaúdaje sú výlučne o tom, ako údaje získavajú svoj význam. Ak v skutočnosti nemáte metadáta, potom môžete prinajlepšom uhádnuť význam údajov, ale budete mať strašné množstvo problémov. Metadáta tam musia byť, ale význam má štruktúru. Nechcem ísť do filozofie významu, ale aj keď sa zaoberáme údajmi, v ľudskom myslení a ľudskom jazyku je veľa sofistikovanosti, ktorá sa v údajoch ľahko nevyjadruje. Ale aj pokiaľ ide o údaje, ktoré skutočne spracúvame vo svete, metadáta majú význam a štruktúru metadát - jeden údaj vo vzťahu k druhému a čo to znamená, keď sa dajú dokopy a čo to znamená, keď sa spoja s ostatnými údajov, vyžaduje, aby sme ich modelovali. Nie je to dosť dobré na zaznamenávanie značiek metadát k veciam, v skutočnosti musíte zaznamenať význam podľa štruktúr a vzťah medzi štruktúrami.
Potom máme v hornej vrstve podnikové definície, čo je zvyčajne vrstva, ktorá sa pokúša preniesť význam medzi metadátami, čo je forma definície údajov, ktorá prispôsobuje spôsob, akým sú údaje organizované v počítači a ľudskom význame. V tejto vrstve teda existujú obchodné podmienky, definície, vzťahy, koncepty na úrovni entít. Ak by medzi týmito vrstvami existovala nesúdržnosť, musíme mať modelovanie údajov. Nie je to naozaj voliteľné. Čím viac toho v skutočnosti môžete urobiť z hľadiska automatizácie, tým lepšie. Ale pretože to súvisí s významom, je skutočne ťažké ho striedať. Je to dosť ľahké na to, aby zachytilo metadáta v jednom zázname a bolo by možné získať ho z viacerých významov, ale nehovorí vám o štruktúre záznamov alebo o tom, čo záznamy znamenajú alebo nesúvisia so záznamom.
Podľa môjho názoru ide teda o modelovanie údajov. Upozorňujeme na vedomie: čím zložitejší sa vesmír údajov stáva, tým viac ho musíte modelovať. Inými slovami, je to trochu ako pridávať do sveta nielen viac vecí, ktoré by korešpondovali s dátovými záznamami, ale v skutočnosti zvyšovali svetu väčší význam zachytávaním údajov o stále viac a viac veciach. Je to čoraz komplexnejší pocit, ktorému musíme porozumieť.
Teoreticky existuje dátový vesmír a potrebujeme na to pohľad. V skutočnosti sú skutočné metaúdaje súčasťou dátového vesmíru. Takže to nie je jednoduchá situácia. Začiatok modelovania je zhora nadol a zdola nahor. Musíte vybudovať oboma smermi a dôvodom je to, že údaje majú význam pre počítač a proces, ktorý ich musí spracovať, ale má význam sám osebe. Potrebujete teda prístup zdola nahor, ktorý vyhovuje softvéru, ktorý potrebuje prístup k údajom, a potrebujete význam zhora nadol, aby to ľudia mohli pochopiť. Budovanie modelov metadát nie je a nikdy nemôže byť projektom; je to nepretržitá činnosť - mala by byť nepretržitou činnosťou v každom existujúcom prostredí. Našťastie existuje veľa prostredí, kde to tak nie je a veci sa vymknú spod kontroly.
V budúcnosti sa modelovanie zvyšuje s tým, ako sa technológia posúva ďalej. To je môj názor. Ak sa však pozriete na internet vecí, dokážeme mobil pochopiť viac, ako sme zvyknutí, aj keď jeho zavedené nové dimenzie: dimenzia umiestnenia v mobile. Keď ste sa dostali na internet vecí, pozerali ste sa na mimoriadne problémy s údajmi, ktoré sme nikdy predtým nemuseli robiť, a tak či onak musíme správne pochopiť, čo presne sme dostali, presne ako ich môžeme zhrnúť, čo môžeme urobiť. čo sa týka získania významu zo agregácie a samozrejme toho, čo s tým môžeme urobiť, keď sme ich spracovali.
Myslím si, že som toho povedal dosť. Idem ďalej na Dez Blanchfielda, povedzme niečo iné.
Dez Blanchfield: Ďakujem. Vždy je ťažké postupovať, ale toto je téma, na ktorej sme sa dohodli a krátko sme o tom hovorili v predsavzatí, a ak ste vytočili čoskoro, pravdepodobne ste chytili veľa skvelých skvostov. Jeden z obchodov so sebou a ja nechcem ukradnúť hrom tohto konkrétneho, ale jeden z obchodov so sebou z nášho prezidentského žartovania, o ktorý sa chcem podeliť, v prípade, že ste ho nezachytili, sa nachádzal len pri téme cesty údajov. a napadlo ma, aby som to skutočne napísal premýšľaním o ceste, ktorú údaje preberajú v rôznom období okolo generačného života - rok, mesiace, týždeň, deň, hodina, minúta, sekunda - a kontext okolo údajov sa umiestni do tohto stavu , Či už som vývojový kód pre vývojárov, alebo či som dátový špecialista a či premýšľam o štruktúre a formáte a metaúdajoch okolo každého z prvkov alebo o spôsobe, akým s nimi systémy a obchod interagujú.
Je to zaujímavý malý darček, len aby som si všimol, ale napriek tomu mi dovoľte ponoriť sa. Najmä návrh údajov je veta, ktorú používam na to, aby som hovoril o všetkých veciach a konkrétne o vývoji aplikácií alebo databázovej infraštruktúry. Myslím si, že návrh údajov je termín, ktorý podľa mňa všetko veľmi dobre vystihuje. V týchto dňoch, keď hovoríme o dátovom dizajne, hovoríme o modernom agilnom dátovom dizajne a podľa môjho názoru to tak dávno nebolo, že vývojári a odborníci na údaje pracovali sami; boli vo svojich vlastných silách a kúsky dizajnu prešli z jedného sila do druhého. Ale podľa mňa v dnešnej dobe to nie je len prípad, ktorý sa zmenil, ale musí sa tiež zmeniť; je to nevyhnutnosť a to je aplikácia - vývojári a všetko, čo sa týka vývoja, ktorý sa zaoberá údajmi, dizajnérmi, ktorí robia relevantné prvky návrhu schém a polí a záznamov a lokalizačných a databázových systémov a infraštruktúr, modelovania a celého riadenia. výzva okolo toho. Teraz je to tímový šport, a teda môj obraz skupiny ľudí, ktorí vyskočili z lietadla a vystupovali ako tím, aby odohrali vizuálne zaujímavý obraz ľudí padajúcich po oblohe.
Po tretie, čo sa to stalo? No, v roku 1986 existuje článok, ktorý napísali páni páni, ktorých mená som sa zúfalo snažil splniť, Hirotaka Takeuchi a Ikujiro Nonaka, myslím, že je to výrazné, že vyšli článok, ktorý nazvali „Moving the Scrum Downfield“. táto myšlienka metodológie na víťazstvo v hre ragby, ktorá sa odohráva z tejto scrum aktivity, kde sa každý dostane okolo na jednom mieste a dva tímy v podstate zamknú hlavy v tzv. scrum, aby sa pokúsili získať kontrolu nad loptou a zahrať ju po poli dostaňte sa na pokusnú čiaru a dotknite sa lopty loptou a získajte bod, ktorý sa nazýva línia, a tento proces opakujete a získate viac bodov pre tím.
Tento článok bol publikovaný v roku 1986 v Harvard Business Review a je zvláštne, že sa mu skutočne venovala veľká pozornosť. Dostalo sa to veľkej pozornosti, pretože priniesla úžasné nové koncepty a tu je snímka prednej strany. Vybrali teda tento koncept scrum z hry ragby a priniesli ho do podnikania, a to najmä do hry dizajnu a projektu, konkrétne projektu.
To, čo sme urobili, bolo, že sme dostali novú metodológiu v porovnaní s obdobím PRINCE2 alebo PMBOK, ktoré sme predtým používali v tom, čo sme nazvali vodopádovou metodológiou, viete, robte túto vec a túto vec a túto vec a sledujte ich postupne a spájajte ich. všetky bodky okolo, čo závisí od toho, čo ste mali, alebo nerobte druhú časť, kým neurobíte prvú časť, pretože to závisí od prvej časti. To, čo nám dalo, je nová metodika, ktorá má byť o niečo agilnejšia, z čoho tento pojem pochádza, o tom, ako dodávame veci, konkrétne o dodávkach projektov týkajúcich sa dizajnu a vývoja.
Niektorí kľúčoví nájomníci - len aby som s tým pokračoval - sa nachádzajú okolo kľúčových nájomcov scrumu.Zaviedla myšlienku budovania nestability, že ak premýšľate o strachu z chaosu, svet existuje v stave chaosu, ale vytvorila sa planéta, čo je zaujímavé, takže budovanie nestability, schopnosť trochu sa odraziť a v skutočnosti stále fungujú, samoorganizujú sa projektové tímy, prekrývajú sa zdvorilosti prostredníctvom veľmi zodpovedného rozvoja, rôznych druhov učenia a kontroly počas cesty realizácie projektu, organizačného prenosu učenia. Ako teda berieme informácie z jednej časti podniku a prenášame ich do druhej od ľudí, ktorí majú nápad, ale nevyvíjajú kód alebo nevyvíjajú databázy a infraštruktúry, ale údaje pre týchto ľudí? A konkrétne časovo ohraničené výsledky. Inými slovami, urobme to nejaký čas, buď deň ako za 24 hodín alebo týždeň alebo pár týždňov a uvidíme, čo môžeme urobiť, a potom ustúpime a pozeráme sa na to.
Ak teda odpustíte slovnú hračku, je to naozaj nová hra v realizácii projektu a jej tri základné komponenty, ktoré budú mať zmysel, keď sa dostaneme trochu ďalej - tu je produkt: všetci títo ľudia majú nápad a majú je potrebné niečo urobiť a príbeh, ktorý ich obklopuje. Vývojári, ktorí pôsobia v agilnom modeli získavania svojich príbehov a prostredníctvom každodenných standupov, používajú metódu scrum na prediskutovanie a pochopenie toho, čo musia urobiť, a potom jednoducho pokračujú a pokračujú v práci. Potom sme už počuli o majstrovi scrumov, ktorí dohliadajú na celú túto vec a dostatočne dobre rozumejú metodike, aby ju zvládli. Všetci sme videli tieto obrázky, ktoré som dostal na pravej strane stien a tabúľ plných poznámok Post-It a slúžili ako steny Kanban. Ak neviete, kto je Kanban, pozývam vás do spoločnosti Google, kto bol pán Kanban a prečo to bola zmena v spôsobe, akým veci presúvame z jednej strany na druhú v stene doslova, ale v projekte.
Na prvý pohľad to robí workflow scrumu: vyžaduje zoznam vecí, ktoré chce organizácia robiť, prevádza ich celým radom vecí, ktoré nazývame ss, ktoré sú rozdelené na 24-hodinové, mesačné obdobia a my získajte túto prírastkovú sériu výstupov. Je to významná zmena v spôsobe, akým sa projekty dodávajú, boli dodané až do tejto fázy, pretože časť týchto tokov, ako je americká armáda, ktorá mala veľkú časť vývoja niečoho, čo sa nazýva PMBOK, ako napríklad myšlienka, že nádrž sa nedostane na pole pokiaľ do toho nevložíte guľky, pretože ak nádrž na poli nemá guľky, je to zbytočné. Preto prvá časť je vložená do guľky, druhá časť je vložená do poľa. Bohužiaľ však to, čo sa stalo s vývojármi v rozvojovom svete, nejako chytilo túto agilnú metodológiu a narazilo s ňou na rovinu, ak odpustíte slovnú hračku.
Samozrejme, čo sa stalo, keď myslíme na agilnosť, zvyčajne myslíme na vývojárov a nie na databázy a na nič spoločné so svetom databáz. Bol to nešťastný výsledok, pretože realitou je, že agilnosť sa neobmedzuje iba na vývojárov. V skutočnosti je pojem agilný podľa môjho názoru často nesprávne spojený výlučne s vývojármi softvéru, a nie s návrhármi databáz a architektmi. Vždy rovnaké výzvy, ktorým čelíte pri vývoji softvéru a aplikácií, musia čeliť vo všetkých veciach týkajúcich sa návrhu a vývoja a prevádzky a údržby, a teda aj dátovej infraštruktúry a najmä databáz. Medzi aktérov v tomto konkrétnom obsadzovanom súbore patria napríklad architekti dát, formári, správcovia, manažéri databázových infraštruktúr a samotné databázy, až po obchodných a systémových analytikov a architektov, ľudia, ktorí sedia a premýšľajú o tom, ako systémy a firmy fungujú a ako sa cez ne dostávame údaje.
Je to téma, ktorú pravidelne predkladám, pretože je to moja neustála frustrácia v tom, že som veľmi toho názoru, že odborníci na údaje sa musia - nie by - musia teraz dôverne podieľať na každej zložke realizácie projektu, skutočne, najmä na vývoji. Aby sme to neurobili, potom si naozaj nedávame najlepšiu šancu na dobrý výsledok. Často sa musíme obracať späť a o týchto veciach znova premýšľať, pretože existuje scenár, dostávame sa k vytvorenej aplikácii a zistíme, že vývojári nie sú vždy odborníkmi na údaje. Práca s databázami si vyžaduje veľmi špecializované zručnosti, najmä okolo údajov, a vytvára si skúsenosti. Nestali ste sa okamžite okamžite databázovým guruom alebo expertom na znalosti údajov; toto je často niečo, čo vychádza z celoživotného zážitku a určite s podobnými témami ako Dr. Robin Bloor v The Code Today, ktorý knihu veľmi bohato napísal.
V mnohých prípadoch - a je to nešťastné, ale je to realita -, že existujú dve časti tejto mince, to znamená, že vývojári softvéru majú výpadok, pokiaľ ide o databázového špecialistu, a vybudovali si zručnosti, ktoré potrebujete pri modelovaní návrhu databázy, pričom vývoj modelu je len základným prvkom guruového inžinierstva o tom, ako prichádzajú údaje a ako organizuje cestu, po ktorej sa vydáva a čo by malo alebo nemalo vyzerať, alebo nepochybne prehltnuté a pochopenie, že sa zvyčajne získajú v natívnych zručnostiach určených pre vývojárov softvéru. A niektoré z bežných problémov, ktorým čelíme, len aby sme to dokázali, zahŕňajú napríklad základné vytváranie a údržbu a správu samotného návrhu základnej databázy, dokumentáciu údajov a databázovú infraštruktúru a následné opätovné použitie týchto dátových prostriedkov, návrhov schém, generovanie schém, správa a údržba schémy a ich využívanie, zdieľanie poznatkov o tom, prečo je táto schéma navrhnutá konkrétnym spôsobom, a silné a slabé stránky, ktoré s ňou súvisia, časom spôsobujú zmeny údajov, modelovanie údajov a typy modelov, ktoré aplikujeme na systémy a údaje, ktoré nimi prechádzajú. Generovanie databázového kódu a pokračuje v integrácii a následne modelovaní údajov okolo nich a rýchlejšom prístupe k riadeniu bezpečnosti údajov, integrita údajov údaje pohybujeme, pretože si zachovávame ich integritu, je tu dostatok metadát malo by predaj vidieť všetky záznamy v tabuľke alebo by mali vidieť iba adresu, krstné meno, priezvisko, ktoré máte v príspevku? A potom, samozrejme, najväčšou výzvou zo všetkých je to, že databázové platformy na modelovanie sú samy osebe úplne inou konverzáciou.
Veľmi sa domnievam, že so zreteľom na všetky tieto skutočnosti, aby bolo možné čo najviac z tejto nirvány, je absolútne nevyhnutné, aby odborníci na údaje a vývojári mali vhodné nástroje a aby tieto nástroje boli schopné tímovo zameraného poskytovania projektov, projektovanie, vývoj a nepretržitá prevádzková údržba. Viete, napríklad spolupráca medzi projektmi medzi odborníkmi na údaje a vývojármi softvéru, jediný bod pravdy alebo jediný zdroj pravdy o všetkých veciach týkajúcich sa dokumentácie samotných databáz, údajov, schém, z ktorých záznamy pochádzajú, vlastníkov týchto záznamov. , Myslím si, že v dnešnej dobe je absolútne rozhodujúce, dostaneme túto nirvánu údajov za kráľa, že musia byť zavedené správne nástroje, pretože teraz je príliš veľká výzva na to, aby sme to urobili manuálne, a ak ľudia presunúť sa z jednej organizácie do inej organizácie, je pre nás príliš ľahké nesledovať ten istý proces alebo metodiku, ktorú by mohol vytvoriť jeden človek, ktoré sú dobré a nemusia nevyhnutne prenášať tieto zručnosti a schopnosti do budúcnosti.
S týmto vedomím idem k nášmu dobrému priateľovi v spoločnosti IDERA a počujem o tomto nástroji a o tom, ako tieto veci rieši.
Ron Huizenga: Ďakujem vám veľmi pekne a ďakujem Robinovi aj Dezovi za to, že ste na pódiu naozaj dobre. Uvidíte trochu prekrývania v niekoľkých veciach, o ktorých som hovoril. Skutočne však vytvorili veľmi solídny základ pre niektoré koncepty, o ktorých budem hovoriť z pohľadu modelovania údajov. A veľa vecí, ktoré povedali, odráža moje vlastné skúsenosti, keď som bol konzultantom pracujúcim v oblasti modelovania údajov a architektúry údajov, spolu s tímami - vodopád v počiatočných dňoch a vývoj na modernejšie produkty s projektmi, v ktorých sme používali agilné metodiky poskytovania riešení.
To, o čom budem dnes hovoriť, je založené na týchto skúsenostiach, ako aj na pohľade na nástroje a niektoré z možností v nástrojoch, ktoré využívame na pomoc pri tejto ceste. Čo sa budem venovať veľmi stručne, nebudem chodiť do podrobností; Práve sme mali skutočne dobrý prehľad o tom, čo to je. Budem o tom hovoriť o tom, čo je to dátový model a čo to pre nás znamená? A ako umožníme koncepciu agilného údajového modelára v našich organizáciách, pokiaľ ide o to, ako zapojíme dátových modelárov, aká je účasť modelárov a architektov v priebehu rokov, aké druhy činností by sa mali vykonávať. a na pozadí toho, aké sú niektoré z dôležitých schopností modelovacích nástrojov, ktoré využívame, aby sme túto prácu skutočne uľahčili? Potom sa chystám trochu zabaliť a len sa trochu porozprávam o niektorých obchodných hodnotách a výhodách zapojenia dátového modelára alebo o tom, ako vlastne rozprávam príbeh, problémy s tým, že dátový modelár sa nebude plne angažovať v projektoch, a ukážem vám, že na základe skúseností a defektného diagramu pred a po obraze skutočného projektu, s ktorým som bol zapojený už pred mnohými rokmi. A potom zhrnieme niekoľko ďalších bodov a potom budeme mať otázky a odpovede.
Veľmi stručne, ER Studio je veľmi výkonný balík, ktorý má veľa rôznych komponentov. Dátový architekt, v ktorom dátoví tvorcovia a architekti trávia väčšinu času tvorbou dátových modelov. Existujú aj ďalšie komponenty, o ktorých dnes nebudeme vôbec hovoriť, ako napríklad Business Architect, kde robíme modelovanie procesov a Software Architect, pre niektoré z modelovania UML. Potom je tu úložisko, kde sa kontrolujeme a zdieľame modely a umožňujeme tímom spolupracovať na nich a zverejňovať ich na tímovom serveri, aby viacerí diváci zainteresovaných strán, ktorí sa podieľajú na projekte, mohli skutočne vidieť artefakty, ktoré „ znovu vytvárať z hľadiska údajov, ako aj ďalšie veci, ktoré robíme pri samotnom dodávaní projektu.
Na čo sa dnes zameriam, bude niekoľko vecí, ktoré uvidíme z nástroja Data Architect, a pretože je skutočne dôležité, aby sme na tom spolupracovali s aspektmi týkajúcimi sa úložiska. Najmä vtedy, keď začneme hovoriť o konceptoch ako je riadenie zmien, ktoré sú nevyhnutné nielen pre agilné rozvojové projekty, ale aj o akýkoľvek ďalší vývoj.
Poďme teda na chvíľu hovoriť o Agile Data Modeler. Ako sme už uviedli, v prezentácii sa spomína to, že je nevyhnutné, aby sme mali datových modelov a / alebo architektov plne zapojených do agilných vývojových procesov. Historicky sa to stalo, áno, skutočne sme premýšľali o agilnosti z hľadiska rozvoja a existuje niekoľko vecí, ktoré sa stali skutočnosťou, ktorá to spôsobila. Časť z toho bola spôsobená iba povahou spôsobu, akým sa vývoj vyvíjal. Keď sa začal agilný vývoj a začali sme s touto koncepciou samoorganizujúcich sa tímov, ak ste pili Kool-Aid príliš čisto a boli ste na extrémnej programovej strane vecí, došlo k veľmi doslovnému výkladu vecí, ako sú samoorganizujúce sa tímy, ktoré mnohí interpretovali tak, že znamenajú, všetko, čo potrebujeme, je skupina vývojárov, ktorí dokážu zostaviť celé riešenie. Či už to znamená vývoj kódu, databáz alebo databáz za nimi a všetko bolo vývojárom pridelené. Čo sa s tým však stane, stratíte o zvláštnych schopnostiach, ktoré majú ľudia. Zistil som, že najsilnejšie tímy sú také, ktoré sú zložené z ľudí z rôznych prostredí. Napríklad kombinácia silných vývojárov softvéru, dátových architektov, dátových modelov, obchodných analytikov a podnikových zainteresovaných strán, ktorí spolupracujú pri hľadaní konečného riešenia.
Dnes hovorím aj o tom, že to urobím v rámci vývojového projektu, v ktorom vyvíjame aplikáciu, ktorá bude mať samozrejme k dispozícii aj dátovú zložku. Musíme však urobiť krok späť, kým to neurobíme, pretože si musíme uvedomiť, že existuje len veľmi málo rozvojových projektov v oblasti Greenfield, kde sa úplne zameriavame na vytváranie a spotrebu údajov, ktorá je obmedzená iba v samotnom projekte rozvoja. , Musíme urobiť krok späť a pozrieť sa na celkové organizačné hľadisko z hľadiska údajov a procesov. Pretože zistíme, že informácie, ktoré využívame, môžu niekde v organizáciách existovať. Ako modelári a architekti to uvádzame na svetlo, takže vieme, odkiaľ majú tieto informácie pochádzať zo samotných projektov. Poznáme tiež dátové štruktúry, ktoré sú zapojené, pretože máme návrhové vzory rovnako ako vývojári majú návrhové vzory pre svoj kód. Musíme tiež vziať túto celkovú organizačnú perspektívu. Nemôžeme sa len pozrieť na údaje v kontexte aplikácie, ktorú vytvárame. Údaje musíme modelovať a zabezpečiť, aby sme ich zdokumentovali, pretože životnosť dlho prekračuje samotné aplikácie. Tieto aplikácie prichádzajú a odchádzajú, musíme sa však pozrieť na údaje a ubezpečiť sa, že sú robustné a dobre štruktúrované, a to nielen pre aplikáciu, ale aj pre rozhodnutia, ktoré vykazujú činnosti, podávanie správ BI a integráciu do iných aplikácií, interných a mimo našich organizácií. Preto sa musíme pozrieť na celý tento obraz údajov a aký je ich životný cyklus, a pochopiť cestu informácií v celej organizácii od kolísky po hrob.
Teraz späť k samotným tímom a tomu, ako skutočne potrebujeme pracovať, bola metodika vodopádu vnímaná ako príliš pomalá na to, aby priniesla výsledky. Pretože, ako bolo uvedené v príklade nádrže, bol to jeden krok za druhým a často trvalo príliš dlho, kým sa dosiahol konečný výsledok. Teraz robíme iteračný pracovný štýl, v ktorom postupne vyvíjame jeho komponenty a rozpracovávame ho v čase, keď vyrábame použiteľný kód alebo použiteľné artefakty, budem hovoriť pre všetky s. Dôležitá vec je spolupráca medzi technickými zúčastnenými stranami v tíme a obchodnými zúčastnenými stranami, pretože spolupracujeme na tom, aby sa tieto príbehy používateľov dostali do realizovateľnej vízie kódu a údajov, ktoré tento kód podporujú. Aj samotný Agile Data Modeler často zistí, že v organizáciách nemáme dostatok modelov, takže jeden dátový modelár alebo architekt môže súčasne podporovať viacero tímov.
A ďalším aspektom toho je, že aj keď máme viacerých modelárov, musíme sa ubezpečiť, že máme k dispozícii sadu nástrojov, ktorú využívame a ktorá umožňuje spoluprácu viacerých projektov, ktoré sú v rovnakom čase, a zdieľať ich. artefakty údajov a možnosti registrácie a odhlásenia. Idem to prejsť veľmi rýchlo, pretože sme to už pokryli v predchádzajúcej časti. Skutočným predpokladom agilnosti je, že veci vykladáte z nevybavených vecí, príbehov alebo požiadaviek. V rámci iterácií spolupracujeme ako skupina. Zvyčajne sú dva týždne alebo jeden mesiac v závislosti od organizácie veľmi bežné. A tiež denné kontroly a schôdzky, aby sme odstránili blokátory a zabezpečili, že posunieme všetky aspekty vpred bez zastavenia v rôznych oblastiach, keď prechádzame. A v týchto ss sa chceme uistiť, že vyrábame použiteľné výstupy ako súčasť každého z nich.
Len trochu odlišný názor na to, čo ďalej rozširujeme, je scrum metodika, o ktorej sa budem podrobnejšie baviť tu, a tento predchádzajúci obrázok sme v podstate rozšírili o niekoľko ďalších aspektov. Zvyčajne existuje nevybavený produkt a potom je nevybavený. Máme teda celkový počet nevybavených vecí, že na začiatku každého opakovania sa smierime a povieme: „Čo budeme stavať?“ A to sa uskutoční na plánovacej schôdzi. Potom rozdelíme úlohy, ktoré s tým súvisia, a vykonávame v týchto jedno až štvortýždňových sekundách s týmito dennými kontrolami. Keď to robíme, sledujeme náš pokrok pomocou grafov vyhorenia a grafov vyhorenia, aby sme v podstate sledovali to, čo zostáva stavať v porovnaní s tým, čo staviame, aby sme zistili veci, ako je to, čo je naša rýchlosť vývoja, rozvrh, všetky tieto typy vecí. Všetky tieto otázky sa spracúvajú priebežne, skôr ako pár mesiacov po ceste, a zisťujú, že prídete krátko a je potrebné predĺžiť časový harmonogram projektu. A veľmi dôležité, ako súčasť toho, celé tímy, sú na konci rovnako retrospektívne, takže skôr ako začnete ďalšiu iteráciu, preskúmate, čo ste urobili, a hľadáte spôsoby, ako by ste sa mohli zlepšiť nabudúce.
Pokiaľ ide o výstupy, ide v podstate o snímku, v ktorej sú zhrnuté typické typy vecí, ktoré sa vyskytujú v ss. A je to veľmi zamerané na vývoj, takže veľa vecí, ktoré tu vidíme, ako sú funkčné návrhy a prípady použitia, testovanie testovacích kódov, keď sa pozrieme na tieto políčka, nebudem ich prechádzať. v akejkoľvek miere podrobnosti sú veľmi zamerané na rozvoj. A pod týmto pohonom je skutočnosť, že na podporu tohto úsilia musíme mať aj tie dátové výstupy, ktoré s tým súvisia. Takže zakaždým, keď vidíme veci, ako sú nevybavené požiadavky, požiadavky a príbehy používateľov, keď prechádzame, musíme sa pozrieť na to, aké vývojové kúsky musíme urobiť, aké analytické kúsky musíme urobiť, a čo dátový model alebo dátový model, čo také ako obchodné glosáre, aby sme mohli priradiť obchodný význam ku všetkým artefaktom, ktoré vyrábame? Pretože musíme vyrábať tieto použiteľné výstupy vo všetkých s.
Niektorí ľudia povedia, že na konci každého z nich musíme vytvoriť použiteľný kód. Nie je to nevyhnutne tak, že je to z najčistejšej perspektívy rozvoja, ale dosť často - najmä na začiatku - môžeme mať niečo ako nulovú, kde sa zameriavame čisto na stojace veci, robíme veci ako napríklad získavanie testovacích stratégií miesto.Dizajn na vysokej úrovni, ako začať, skôr, ako začneme vyplňovať podrobnosti a uistiť sa, že máme čistú množinu úvodných príbehov alebo požiadaviek, predtým, ako začneme angažovať ďalšie publikum a potom sa budujeme vpred ako tím pri ďalšom postupovaní. Vždy je trochu času na prípravu, takže často budeme mať nulovú alebo dokonca nulovú a jednu. Môže to byť trochu fáza uvedenia do prevádzky skôr, ako sa nám podarí doručiť riešenie.
Poďme sa baviť o dátových modeloch v tejto súvislosti veľmi stručne. Keď si ľudia myslia o dátových modeloch, často si myslia, že dátový model je obrazom toho, ako sa rôzne informácie navzájom spájajú - to je len špičkou ľadovca. Ak chcete plne stelesniť ducha toho, ako skutočne chcete pristupovať k modelovaniu údajov - či už ide o agilný vývoj a iné veci -, musíte si uvedomiť, že dátový model, ak sa urobí správne, sa stane vašou úplnou špecifikáciou toho, čo tieto údaje znamenajú v organizácii a ako je nasadený v databázach typu back-end. Keď hovorím databázy, nemyslím to len relačné databázy, ktoré môžeme používať, ale v dnešných architektúrach, kde máme veľké dátové platformy alebo platformy NoSQL, ako ich radšej nazývam. Aj tie veľké dátové úložiská, pretože môžeme kombinovať množstvo rôznych dátových úložísk, pokiaľ ide o spotrebu informácií a ich uvádzanie do našich riešení, ako aj o to, ako tieto informácie pretrvávame alebo ich tiež ukladáme z našich riešení.
V rámci danej aplikácie môžeme pracovať súčasne s viacerými databázami alebo zdrojmi údajov súčasne. Čo je veľmi dôležité, chceme mať úplnú špecifikáciu, takže logickú špecifikáciu toho, čo to znamená ako organizačnú perspektívu, aké fyzické konštrukty sú z hľadiska toho, ako skutočne definujeme údaje, vzťahy medzi nimi vo vašom databázy, vaše obmedzenia referenčnej integrity, obmedzenia kontroly, všetky tie prvky validácie, o ktorých zvyčajne uvažujete. Opisné metaúdaje sú nesmierne dôležité. Ako viete využívať údaje vo svojich aplikáciách? Pokiaľ to nedefinujete a neviete, čo to znamená alebo viete, odkiaľ pochádza, aby ste sa uistili, že v týchto aplikáciách konzumujete správne údaje - ubezpečte sa, že máme správne pomenovacie konvencie, úplné definície, čo znamená úplný dátový slovník nielen pre tabuľky, ale stĺpce, ktoré tieto tabuľky obsahujú - a podrobné poznámky o nasadzovaní informácií o tom, ako ich využívame, pretože potrebujeme vybudovať túto vedomostnú základňu, pretože aj keď sa táto aplikácia vykoná, tieto informácie sa použijú pre ďalšie iniciatívy, takže sa musíme uistiť že máme všetko, čo bolo zdokumentované pre budúce implementácie.
Opäť sa dostávame k veciam, ako sú dátové typy, kľúče, indexy, samotný dátový model stelesňuje množstvo obchodných pravidiel, ktoré vstupujú do hry. Vzťahy nie sú iba obmedzeniami medzi rôznymi tabuľkami; Často nám pomáhajú opísať, aké sú skutočné obchodné pravidlá okolo toho, ako sa tieto údaje správajú a ako spolu fungujú ako súdržná jednotka. A samozrejme, obmedzenia hodnoty sú veľmi dôležité. Jednou z vecí, s ktorou sa neustále zaoberáme, je, samozrejme, stále viac a viac prevládajúca situácia, napríklad správa údajov. Z hľadiska správy údajov sa teda musíme zaoberať aj tým, čo tu definujeme? Chceme definovať veci ako bezpečnostné klasifikácie. S akým typom údajov pracujeme? Čo sa bude považovať za správu kmeňových údajov? Čo sú to transakčné obchody, ktoré vytvárame? Aké referenčné údaje využívame v týchto aplikáciách? Musíme sa ubezpečiť, že je v našich modeloch správne zachytený. A tiež z hľadiska kvality údajov existujú určité informácie, ktoré sú pre organizáciu dôležitejšie ako iné.
Zapojil som sa do projektov, kde sme nahradili viac ako tucet starých systémov novými obchodnými procesmi a navrhoval som nové aplikácie a dátové sklady, ktoré ich nahradia. Potrebovali sme vedieť, odkiaľ tieto informácie pochádzajú. Ktoré z najdôležitejších informácií z obchodného hľadiska, keď sa pozriete na tento konkrétny list údajového modelu, ktorý som tu dostal, uvidíte, že spodné polia v týchto konkrétnych entitách, ktoré sú iba malou podskupinou, V skutočnosti som bol schopný zachytiť obchodnú hodnotu. Či už ide o vysoké, stredné alebo nízke hodnoty týchto typov vecí pre rôzne konštrukty v organizácii. A tiež som zachytil veci, ako sú triedy kmeňových údajov, či sú to hlavné tabuľky, či sú referenčné, či boli transakčné. Môžeme teda rozšíriť naše metaúdaje v našich modeloch tak, aby nám poskytli množstvo ďalších charakteristík mimo samotných údajov, čo nám skutočne pomohlo s inými iniciatívami mimo pôvodných projektov a prenieslo ich ďalej. Teraz to bolo veľa na jednom diapozitíve, ostatné sa budem venovať pomerne rýchlo.
Teraz budem hovoriť veľmi rýchlo o tom, čo robí dátový modelár, keď prechádzame týmito rôznymi ss. Najskôr je to úplný účastník plánovacích relácií, kde berieme užívateľské príbehy, dopúšťame sa toho, čo v nich poskytneme, a zisťujeme, ako ho plánujeme usporiadať a doručiť. Ako údajový modelár tiež viem, že budem pracovať v samostatných oblastiach s rôznymi vývojármi alebo s rôznymi ľuďmi. Takže jednou z dôležitých charakteristík, ktorú môžeme mať, keď robíme dátový model, môžeme tento dátový model rozdeliť do rôznych pohľadov, či už ich nazývate predmetovými oblasťami alebo submodelmi, je naša terminológia. Keď vytvárame model, ukazujeme ho aj v týchto rôznych perspektívach ponoriek, takže rôzne publikum uvidí iba to, čo je pre nich relevantné, aby sa mohli sústrediť na to, čo vyvíjajú a predkladajú. Takže by som mohol mať niekoho, kto pracuje na plánovacej časti aplikácie, mohol by som mať niekoho iného, kto pracuje na zadaní objednávky, kde robíme všetky tieto veci v jednom, ale môžem im dať pohľady cez tie submodely, ktoré iba vzťahujú sa na oblasť, na ktorej pracujú. A potom sa tieto zhrnú do celkového modelu a celej štruktúry sub-modelov, aby poskytli rôznym názorom publika, čo potrebujú vidieť.
Základy z hľadiska modelovania údajov, ktoré chceme mať, sú vždy východiskové hodnoty, ku ktorým sa môžeme vrátiť, pretože jednou z vecí, ktoré musíme vedieť urobiť, je, či už je na konci alebo na konci niekoľko ss, chceme vedieť, kde sme začali a vždy máme východiskovú hodnotu, aby sme vedeli, čo bolo delta alebo rozdiel toho, čo sme v danom s. Musíme sa tiež ubezpečiť, že môžeme mať rýchly obrat. Ak k tomu prídete ako dátový modelár, ale v tradičnej úlohe strážcu povedania „Nie, nie, nemôžete to urobiť, musíme urobiť všetky tieto veci ako prvé,“ budete vylúčení z tímu, keď to skutočne potrebujete byť aktívnym účastníkom všetkých agilných vývojových tímov. To znamená, že niektoré veci spadnú z vagóna, ktorý robí daný, a vy ich vyzdvihnete v neskorších ss.
Ako príklad sa môžete zamerať na dátové štruktúry len preto, aby ste mohli hovoriť o vývoji tohto príkazu, o položke, ktorá sa týka objednávky, o ktorej som hovoril. Neskôr sa môžete vrátiť a vyplniť údaje, napríklad časť dokumentácie pre dátový slovník, okolo niektorých artefaktov, ktoré ste vytvorili. Túto definíciu nedokončíte naraz. budete pokračovať v dosahovaní vašich výstupov postupne, pretože nastanú chvíle, keď budete môcť vyplniť tieto informácie v spolupráci s obchodnými analytikmi, keď vývojári budú zaneprázdňovaní tvorbou aplikácií a vytrvalosťou okolo týchto úložísk údajov. Chcete to uľahčiť a nebyť prekážkou. S vývojármi spolupracujeme rôznymi spôsobmi. Pre niektoré veci máme dizajnové vzory, takže sme plnohodnotným účastníkom vopred, takže môžeme mať návrhový vzor, kde povieme, že ho vložíme do modelu, vytlačíme ho do databáz karantény vývojárov a potom môžu začnite s tým pracovať a požiadajte o zmeny.
Môžu existovať aj ďalšie oblasti, na ktorých vývojári pracovali, majú niečo, na čom pracujú a prototypujú niektoré veci, takže si môžu niektoré veci vyskúšať vo svojom vlastnom vývojovom prostredí. Berieme tú databázu, s ktorou pracovali, priniesli ju do nášho modelovacieho nástroja, porovnali s modelmi, ktoré máme, a potom ich rozlíšili a vytlačili späť späť, aby mohli zmeniť svoje kódy tak, aby sledovali správne štruktúry údajov. ktoré potrebujeme. Pretože mohli vytvoriť niektoré veci, ktoré sme už mali niekde inde, a preto sa ubezpečujeme, že pracujú so správnymi zdrojmi údajov. Stále to iterujeme celú cestu až k našim, aby sme dostali úplné výstupy údajov, úplnú dokumentáciu a definíciu všetkých tých dátových štruktúr, ktoré vyrábame.
Najúspešnejšie agilné projekty, s ktorými som sa zaoberal v súvislosti s veľmi dobrými dodávkami, sú filozofia, modelovanie všetkých zmien v úplnej špecifikácii fyzickej databázy. Dátový model sa v podstate stáva nasadenými databázami, s ktorými pracujete pre čokoľvek nové, čo vytvárame, a má úplné referencie na ostatné dátové úložiská, ak spotrebúvame z iných externých databáz. V rámci toho vyrábame prírastkové skripty verzus zakaždým, keď robíme plnú generáciu. A my využívame naše návrhové vzory, aby nám poskytli tento rýchly zdvih, pokiaľ ide o to, aby sa veci dali do ss s rôznymi vývojovými tímami, s ktorými pracujeme.
Aj v činnostiach je to opäť tá základná línia na porovnanie / zlúčenie, takže si vezmime predstavu modelovania každej zmeny. Vždy, keď robíme zmenu, chceme, aby sme túto zmenu modelovali a čo je veľmi dôležité, čo v nedávnom období chýbalo v modelovaní údajov, v skutočnosti až do ich opätovného zavedenia je schopnosť asociovať modelovanie. úlohy a vaše výstupy s používateľskými príbehmi a úlohami, ktoré skutočne spôsobujú tieto zmeny. Chceme byť schopní skontrolovať naše zmeny modelu, rovnako ako vývojári kontrolujú svoje kódy, odkazujúc na tie príbehy používateľov, ktoré máme, takže vieme, prečo sme v prvom rade urobili zmeny, to je niečo, čo robíme. Keď to urobíme, vygenerujeme naše prírastkové skripty DDL a zaúčtujeme ich, aby ich bolo možné vyzdvihnúť spolu s ostatnými vývojovými výstupmi a skontrolovať v našom zabudovanom riešení. Opäť môžeme mať jeden model alebo pracovať s viacerými tímami. A ako som už hovoril, niektoré veci pochádzajú od data modelera, iné veci pochádzajú od vývojárov a my sa stretávame uprostred, aby sme prišli s celkovo najlepším dizajnom a posunuli ho dopredu a ubezpečili sa, že je v našom dizajne správne navrhnutý celkové dátové štruktúry. Pri ďalšom postupe musíme zachovať disciplínu zabezpečenia toho, aby sme v našom dátovom modeli mali všetky správne konštrukty vrátane vecí, ako sú nulové a nie nulové hodnoty, referenčné obmedzenia, v zásade kontrolné obmedzenia, všetky tie veci, o ktorých by sme zvyčajne mysleli ,
Povedzme si teraz niekoľko snímok niektorých nástrojov, ktoré nám v tom pomáhajú. Myslím si, že je dôležité mať tento úložisko pre spoluprácu, takže to, čo môžeme urobiť ako tvorcovia údajov - a to je úryvok časti údajového modelu v pozadí - je, keď pracujeme na veciach, ktoré chceme zabezpečiť, aby sme mohli pracovať iba na objektoch, ktoré musíme zmeniť, vykonať zmeny, vygenerovať DDL skripty pre zmeny, ktoré sme vykonali pri kontrole vecí. Čo môžeme urobiť, je v ER Studio príklad, môžeme skontrolovať objekty alebo skupiny objektov, na ktorých musíme pracovať, nemusíme kontrolovať celý model alebo sub-model, môžeme skontrolovať len tie veci, ktoré nás zaujímajú. To, čo potom chceme, je buď check-out, alebo check-in - robíme to oboma spôsobmi, pretože rôzne vývojové tímy pracujú rôznymi spôsobmi. Chceme sa ubezpečiť, že to spájame s používateľským príbehom alebo úlohou, ktorá riadi požiadavky na tento účel, a to bude ten istý príbeh alebo úloha, ktoré vývojári budú vyvíjať a kontrolovať ich kód.
Tu je veľmi rýchly úryvok niekoľkých obrazoviek jedného z našich centier riadenia zmien. Čo to robí, nebudem sa tu podrobne zaoberať podrobne, ale vidíte to, čo sa týka príbehu alebo úlohy používateľa, a odsadené pod každú z tých, ktoré vidíte v skutočných záznamoch o zmene - vytvorili sme automatizovaný záznam o zmene, keď robíme check-in a check-out a môžeme dať ďalší popis na tento záznam zmien. Je priradená k úlohe, môžeme mať viac zmien v úlohe, ako by ste očakávali. A keď ideme do záznamu zmien, môžeme sa naň pozrieť a čo je dôležitejšie, čo sme sa vlastne zmenili? V tomto konkrétnom príbehu, v zvýraznenom príbehu, som mal jeden typ zmeny, ktorý sa vykonal, a keď som sa pozrel na samotný záznam o zmene, identifikoval jednotlivé kúsky v modeli, ktorý sa zmenil. Zmenil som tu niekoľko atribútov, znovu ich privlastnil a priniesol na cestu pohľady, ktoré bolo potrebné zmeniť, ktoré záviseli aj od tých, aby boli generované v prírastkovej DLL. Nielen modelovanie na základných objektoch, ale aj vysoko výkonný modelovací nástroj, ako je tento, zisťuje zmeny, ktoré je potrebné vlniť pomocou závislých objektov v databáze alebo aj v dátovom modeli.
Ak pracujeme s vývojármi a robíme to v niekoľkých rôznych veciach, robíme niečo v karanténe a chceme porovnať a zistiť, kde sú rozdiely, použijeme možnosti porovnávania / zlúčenia, ak sú na pravej strane a naľavo. side. Môžeme povedať: „Tu je náš model na ľavej strane, tu je ich databáza na pravej strane, ukážte mi rozdiely.“ Potom si môžeme vybrať a zvoliť, ako tieto rozdiely vyriešime, či už do databázy vložíme veci alebo či v databáze sú niektoré veci, ktoré prinášame späť do modelu. Môžeme ísť obojsmerne, takže môžeme ísť oboma smermi súčasne aktualizovať zdroj aj cieľ a potom vytvoriť prírastkové skripty DDL, aby sme tieto zmeny nasadili do samotného databázového prostredia, čo je nesmierne dôležité. Čo môžeme tiež urobiť, je, že môžeme použiť túto schopnosť porovnávania a zlúčenia kedykoľvek v danom okamihu, ak berieme snímky na ceste cez, vždy môžeme porovnať začiatok jednej s začiatkom alebo koncom iných s, aby sme videli úplná inkrementálna zmena toho, čo sa stalo v danom vývoji alebo v sérii ss.
Toto je veľmi rýchly príklad alternatívneho skriptu. Každý z vás, ktorý pracoval s databázami, videl tento typ vecí. Toto je to, čo môžeme vytlačiť z kódu ako alternatívny skript, aby sme sa ubezpečili, že tu si veci nechaj. Čo som odtiaľto odtiahol, len aby som znížil neporiadok, je to, čo robíme aj s týmito zmenenými skriptmi, že predpokladáme, že existujú aj údaje v týchto tabuľkách, takže vygenerujeme aj DML, ktorý vytiahne informácie z dočasných tabuliek a zasuňte ju späť aj do nových štruktúr údajov, takže sa pozeráme nielen na štruktúry, ale aj na údaje, ktoré sme už mohli v týchto štruktúrach obsahovať.
Chceme hovoriť veľmi rýchlo o automatizovaných zostavovacích systémoch, pretože keď robíme agilný projekt, často pracujeme s automatizovanými zostavovacími systémami, v ktorých musíme spoločne skontrolovať rôzne výstupy, aby sme sa uistili, že naše stavby nerozbíjame. Čo to znamená, že synchronizujeme výstupy, tie skripty na zmenu, o ktorých som hovoril so skriptom DDL, je potrebné skontrolovať, zodpovedajúci aplikačný kód sa musí skontrolovať súčasne a veľa vývojárov vývoja teraz samozrejme nie je robia sa priame SQL proti databázam a tomuto typu vecí. Pomerne často využívame perzistenčné rámce alebo stavebné dátové služby. Musíme zabezpečiť, aby sa zmeny týchto rámcov alebo služieb skontrolovali presne v rovnakom čase. V niektorých organizáciách prechádzajú do automatizovaného systému zostavovania a ak sa zostavenie rozpadne, v agilnej metodológii sú to všetko ruky, ktoré sa zostavujú na palube, skôr ako sa pohneme vpred, takže vieme, že pred ďalším krokom máme pracovné riešenie. A jeden z projektov, do ktorých som sa zapojil, sme to zobrali do extrému - ak by sa stavba rozpadla, ktorú sme vlastne pripojili k viacerým počítačom v našej oblasti, kde sme boli obarvení podnikovými používateľmi, mali sme iba červené blikajúce svetlá ako vrchol policajných automobilov. A ak sa stavba rozpadla, tie červené blikajúce svetlá začali zhasnúť a my sme vedeli, že sú všetky ruky na palube: opravte zostavenie a potom pokračujte v tom, čo robíme.
Chcem hovoriť o iných veciach, a toto je jedinečná schopnosť aplikácie ER Studio, naozaj to pomáha, keď sa snažíme stavať tieto artefakty ako vývojári pre tieto hranice vytrvalosti, máme koncept nazývaný objekty obchodných údajov a to, čo nám umožňuje urobíte, ak si pozriete tento veľmi zjednodušený dátový model ako príklad, umožňuje nám to zapuzdriť entity alebo skupiny entít, kde sú hranice pretrvávania. Tam, kde my ako dátový modelár môžeme myslieť na niečo, ako je záhlavie objednávky a zarovnanie objednávky a ďalšie podrobné tabuľky, ktoré by do toho zapadali tak, ako ho zostavujeme, a naši vývojári dátových služieb musia vedieť, ako veci pretrvávajú v týchto rôznych údajoch. štruktúry. Naši vývojári myslia na veci, ako je nákupná objednávka, celkovo ako na objekt a aká je ich zmluva s tým, ako tieto konkrétne objekty vytvárajú. Tento technický detail môžeme odhaliť, aby ľudia, ktorí zostavujú dátové servery, mohli vidieť, čo je pod ním, a aby sme mohli ostatné publikum chrániť pred zložitosťou, aby jednoducho videli rôzne objekty vyššej úrovne, ktoré tiež veľmi dobre fungujú pri komunikácii s obchodom. analytici a obchodné subjekty, keď hovoríme aj o interakcii rôznych obchodných konceptov.
Na tom je tiež pekné, že ich konštruktívne rozširujeme a zbalíme, aby sme si mohli zachovať vzťahy medzi objektmi vyššieho poriadku, aj keď pochádzajú z konštruktov, ktoré sú obsiahnuté v samotných objektoch obchodných údajov. Teraz ako modelka sa dostávam na koniec s, na koniec zabalenia, mám veľa vecí, ktoré musím urobiť, ktoré volám na ďalšie obdobie. Každým vytvorím to, čomu hovorím Pomenované vydanie - to mi dáva základ pre to, čo mám teraz na konci vydania. To znamená, že v budúcnosti budem mojou základnou líniou, všetky tieto základné línie alebo pomenované vydania, ktoré vytvorím a uložím vo svojom úložisku, ktoré môžem použiť na porovnanie / zlúčenie, takže vždy môžem porovnávať s akýmkoľvek daným koncom s z akýchkoľvek iných, je veľmi dôležité vedieť, aké boli vaše zmeny v údajovom modeli na jeho ceste.
Tiež vytváram skript delta DDL pomocou porovnania / zlúčenia znova od začiatku do konca. Možno som skontroloval celý zväzok inkrementálneho skriptu, ale ak to potrebujem, teraz mám skript, ktorý môžem nasadiť, aby som postavil ďalšie karantény, takže môžem len povedať, že toto je to, čo sme mali na začiatku jedného, cez to vytvorte databázu ako karanténu a začnite s nasledujúcimi. Môžeme tiež použiť tieto veci na vykonávanie vecí, ako sú napríklad situácie QA v pohotovostnom režime, a nakoniec, samozrejme, chceme presúvať naše zmeny do výroby, aby sme mohli pokračovať vo viacerých veciach. v rovnaký čas. Opäť sa plne zúčastňujeme na plánovaní a retrospektívach, retrospektívy sú skutočne poučenia a to je nesmierne dôležité, pretože počas agility môžete ísť veľmi rýchlo, musíte zastaviť a oslavovať úspechy, ako teraz. Zistite, čo je zlé, vylepšte to nabudúce, ale oslávte aj veci, ktoré sa ukázali správne, a stavajte na nich, keď sa budete ďalej pohybovať vpred.
Teraz budem veľmi rýchlo hovoriť o obchodnej hodnote. Bol to projekt, s ktorým som sa zapojil už pred mnohými rokmi a ktorý začal ako agilný projekt, a bol to extrémny projekt, takže to bol čisto samoorganizovaný tím, kde robili všetko iba vývojári. Aby sme to skrátili, tento projekt bol zastavený a zistili, že trávia stále viac a viac času odstraňovaním a odstraňovaním zistených nedostatkov, než tlačením ďalších funkcií a vlastne, keď sa na to pozerajú v grafoch vyhorenia museli projekt predĺžiť o šesť mesiacov za obrovské náklady. A keď sme sa na to pozreli, spôsob, ako napraviť problém, bolo použitie vhodného nástroja na modelovanie údajov so skúseným modelárom, ktorý je zapojený do samotného projektu.
Ak sa pozriete na tento zvislý pruh v tomto konkrétnom diagrame, ukazuje to kumulatívne chyby verzus kumulatívne objekty a ja hovorím o údajových objektoch alebo konštruktoch, ktoré boli vytvorené, ako sú tabuľky s obmedzeniami, a o tých typoch vecí, ak ste sa pozreli na pred zavedením dátového modelára počet defektov skutočne presahoval a začal budovať medzeru oproti skutočnému počtu objektov, ktoré boli až do tohto okamihu vyrobené. Po 21. týždni, teda po príchode dátového modelára, došlo k novému vylepšeniu dátového modelu na základe toho, čo bolo treba napraviť, a potom sa začalo s modelovaním ako súčasť projektového tímu, ktorý sa posunul vpred , A vy ste videli veľmi rýchly obrat, že približne za polovicu sme zaznamenali obrovský nárast počtu objektov a dátových konštruktov, ktoré sa generovali a konštruovali, pretože sme generovali skôr nástroj na modelovanie údajov, než budovu vývojových tyčí. boli v prostredí a mali pravdu, pretože mali správnu referenčnú integritu a ostatné konštrukty, ktoré by mali mať. Úroveň defektov proti týmto takmer rovným čiaram. Prijatím tohto primeraného opatrenia a zabezpečením úplného zapojenia modelovania údajov bol projekt dodaný včas s oveľa vyššou úrovňou kvality a v skutočnosti by sa nedosiahol vôbec, keby sa tieto kroky neuskutočnili. Existuje veľa agilných zlyhaní, existuje aj veľa agilných úspechov, ak by ste do správnych úloh zapojili tých správnych ľudí. Som obrovský zástanca agility ako operatívnej disciplíny, ale musíte sa uistiť, že máte zručnosti všetkých tých správnych skupín, ktoré sú zapojené ako vaše projektové tímy, ako postupujete v agilnom type úsilia.
Aby sme to zhrnuli, dátoví architekti a modelári musia byť zapojení do všetkých rozvojových projektov; sú to lepidlo, ktoré drží všetko pohromade, pretože ako dátoví modelári a architekti rozumieme nielen dátovým konštruktom daného vývojového projektu, ale aj tam, kde údaje existujú v organizácii a odkiaľ ich môžeme získavať a ako z nich sa bude používať a využívať mimo samotnej konkrétnej aplikácie, na ktorej pracujeme. Rozumieme komplexným vzťahom s údajmi a je nevyhnutné, aby sme sa mohli pohnúť vpred a tiež z hľadiska riadenia zmapovať dokument a porozumieť tomu, ako vyzerá vaše úplné dátové prostredie.
Je to ako výroba; Prišiel som z výrobného prostredia. Na konci nemôžete skontrolovať kvalitu - musíte do svojho návrhu zabudovať kvalitu vopred a na ceste cez ňu. Modelovanie údajov je spôsob, ako túto kvalitu do návrhu zabudovať efektívnym a nákladovo efektívnym spôsobom až do konca. , A opäť, niečo, na čo treba pamätať - a to nemá byť zrada, ale je to pravda - aplikácie prichádzajú a odchádzajú, údaje sú životne dôležitým firemným aktívom a presahujú všetky tieto hranice aplikácií. Vždy, keď vkladáte aplikáciu, pravdepodobne sa od vás požaduje, aby sa uchovali údaje z iných aplikácií, ktoré prišli predtým, takže si musíme len pamätať, že je to životne dôležité firemné aktívum, ktoré priebežne udržiavame.
A to je všetko! Odtiaľto položíme viac otázok.
Eric Kavanagh: Dobre, dovoľte mi to najskôr zahodiť Robinovi. A potom, Dez, som si istý, že máte pár otázok. Zober to preč, Robin.
Robin Bloor: Poriadku. Úprimne povedané, nikdy som nemal problém s agilnými vývojovými metódami a zdá sa mi, že to, čo tu robíte, má zmysel. Spomínam si, keď som sa pozrel na niečo z 80. rokov, ktoré skutočne naznačovalo, že problém, na ktorý ste sa skutočne dostali, pokiaľ ide o projekt, ktorý sa vymkol spod kontroly, je zvyčajne, ak necháte chybu pretrvávať aj po určitej etape. Oprava sa stáva čoraz zložitejšou, ak nechcete správne vyriešiť túto etapu, takže jedna z vecí, ktoré tu robíte - a myslím si, že toto je snímka -, ale jedna z vecí, ktoré tu robíte v nule, podľa môjho názoru, je absolútne dôležité, pretože sa naozaj snažíte získať výstupy tam. A ak nechcete, aby boli výstupy pripnuté, výstupy zmenia tvar.
To je druh môjho názoru. Je to aj môj názor - naozaj nemám nijaký argument s myšlienkou, že pred tým, ako budete prechádzať, musíte mať model na modelovanie údajov do určitej miery podrobností. Chcel by som, aby ste to vyskúšali, pretože som to nezískal úplne, len opíšte jeden z týchto projektov, pokiaľ ide o jeho veľkosť, o to, ako to plylo, o to, kto, ako viete, kde sa problémy objavili, boli vyriešené? Pretože si myslím, že táto snímka je do značnej miery jej srdcom a ak by ste o tom mohli viac rozpracovať, bol by som veľmi vďačný.
Ron Huizenga: Iste, použijem niekoľko príkladov. Ten, ktorý tak nejako odišiel z koľajníc, ktorý bol privedený späť tým, že v skutočnosti zapojil tých správnych ľudí a urobil modelovanie údajov a všetko bolo skutočne spôsobom, ako zabezpečiť, aby bol návrh pochopený lepšie a my sme samozrejme mali lepší návrh implementácie. na ceste cez jeho modelovanie. Pretože keď to budete modelovať, viete, môžete vygenerovať svoje DDL a všetko zo zadku a von z nástroja, namiesto toho, aby ste sa museli stavať tak, ako by to ľudia zvyčajne robili tak, že pôjdete priamo do databázového prostredia. Typickými vecami, ktoré sa stanú s vývojármi, je, že tam pôjdu a povedia: Áno, tieto tabuľky potrebujem. Povedzme, že robíme záznamy objednávok. Mohli by tak vytvoriť hlavičku objednávky a tabuľky podrobností objednávky a také typy vecí. Často však zabudnú alebo zanedbajú, aby sa ubezpečili, že existujú obmedzenia, ktoré predstavujú vzťahy cudzích kľúčov. Možno nemusia mať správne zadané kľúče. Podozrivé konvencie môžu byť tiež podozrivé. Neviem, koľkokrát som prešiel do prostredia, napríklad, kde vidíte veľa rôznych tabuliek s rôznymi názvami, ale potom názvy stĺpcov v týchto tabuľkách sú ako ID, meno alebo čokoľvek, takže sú Skutočne som stratil konvicu bez tabuľky presne toho, čo to je.
Spravidla sa teda pri modelovaní údajov uistíme, že na všetky artefakty, ktoré sa generujú aj v DDL, používame správne pomenovacie konvencie. Aby som bol konkrétnejší o charaktere samotných projektov, vo všeobecnosti hovorím o pomerne veľkých iniciatívach. Jedným z nich bol projekt transformácie podnikania vo výške 150 miliónov dolárov, kde sme nahradili viac ako tucet starých systémov. Mali sme spolu päť rôznych agilných tímov. Mal som tím úplnej architektúry údajov, takže som mal zabudovaných dátových modelárov z každého z ostatných tímov aplikačnej oblasti a pracovali sme s kombináciou interných podnikových odborníkov, ktorí poznali predmet, ktorý robili príbehy používateľov pre samotné požiadavky. V každom z tých tímov, ktoré skutočne modelovali obchodný proces, sme mali obchodných analytikov s diagramami aktivít alebo diagramami obchodných procesov, ktoré pomáhajú spresniť príbehy používateľov viac s používateľmi skôr, ako ich spotrebujú aj zvyšok tímu.
A potom samozrejme vývojári, ktorí stavali aplikačný kód. A my sme tiež pracovali, myslím si, že to boli štyria predajcovia systémovej integrácie, ktorí stavali rôzne časti aplikácie, pričom jeden tím budoval dátové služby, druhý budoval aplikačnú logiku v jednej oblasti, ďalší odborne spôsobilý. v inej oblasti podnikania budovala aplikačnú logiku v tejto oblasti. Mali sme teda celú spoluprácu ľudí, ktorí na tomto projekte pracovali. Najmä v tomto sme mali 150 ľudí na brehu v tíme a ďalších 150 zdrojov na mori v tíme, ktorí spolupracovali na dvojtýždňových ss, aby túto vec vyhnali. A aby ste to dosiahli, musíte sa ubezpečiť, že strieľate na všetky valce, a všetci sú dobre synchronizovaní, pokiaľ ide o to, čo sú ich výstupy, a vy ste mali tie časté resetovania, aby ste sa uistili, že sme dokončovali dodávky všetkých potrebných artefaktov. na konci každej s.
Robin Bloor: To je pôsobivé. A len o trochu podrobnejšie informácie - skončili ste na konci tohto projektu úplnou, čo by som nazval MDM mapu celej dátovej oblasti?
Ron Huizenga: Mali sme kompletný dátový model, ktorý bol rozdelený podľa rozkladu medzi všetky rôzne obchodné oblasti. Samotný dátový slovník z hľadiska úplných definícií bol trochu krátky. Mali sme definovanú väčšinu tabuliek; väčšinu stĺpcov sme definovali tak, ako presne znamenajú. Tam boli niektoré, ktoré tam neboli, a čo je dosť zaujímavé, veľa z nich boli informácie, ktoré pochádzali zo starých systémov, kde po ukončení samotného rozsahu projektu to bolo stále dokumentované ako súbor prenesených artefakty, ako to bolo, mimo samotného projektu, pretože to bolo niečo, čo musí organizácia ďalej udržiavať. Organizácia zároveň zaujala oveľa väčší pohľad na dôležitosť správy údajov, pretože v týchto starých systémoch a v tých starých zdrojoch údajov sme zaznamenali veľa nedostatkov, ktoré sme sa snažili spotrebovať, pretože neboli zdokumentované. V mnohých prípadoch sme mali iba databázy, ktoré sme museli spätne analyzovať a pokúsiť sa zistiť, čo tam je a na čo slúžili informácie.
Robin Bloor: Neprekvapuje ma ten konkrétny aspekt. Spravovanie údajov je, povedzme si, veľmi moderné, a myslím si, že v skutočnosti existuje veľa práce, ktorá by sa, povedzme, mala vykonať v oblasti správy údajov historicky. Nikdy to nebolo preto, že by ste sa mohli zbaviť toho, že ste to neurobili. Ale ako zdroj údajov práve rástol a rástol, nakoniec ste to nemohli.
Každopádne pôjdem do Dez, pretože si myslím, že som mal pridelený čas. Dez?
Dez Blanchfield: Áno, ďakujem. Cez celú túto vec sa pozerám a premýšľam si, že hovoríme o tom, ako sa agilnosť používa v hneve mnohými spôsobmi. Aj keď to má negatívne významy; Myslel som to pozitívne. Mohli by ste nám len dať scenár, myslím, že sú dve miesta, ktoré vidím, že ide o dokonalý súbor: jeden sú nové projekty, ktoré je potrebné urobiť iba od prvého dňa, ale podľa mojich skúseností je to podľa mňa vždy často v prípade, že keď sú projekty dostatočne veľké, že je to potrebné mnohými spôsobmi, je medzi lepením týchto dvoch svetov zaujímavá výzva, však? Môžete nám dať nahliadnuť do niektorých príbehov o úspechu, ktoré ste videli, kam ste prišli do organizácie, je zrejmé, že majú mierny súboj dvoch svetov a že ste boli schopní úspešne uviesť to na mieste a spájať veľké projekty, kde by sa inak mohli vydať po železnici? Viem, že je to veľmi široká otázka, ale zaujímalo by ma, či existuje konkrétna prípadová štúdia, ktorú by ste mohli, tak nejako poukázať na to, kde ste povedali, viete, všetko sme zaviedli a je to spojené s celým vývojovým tímom spolu s dátový tím a my sme nejako riešili niečo, čo by inak loď potopilo?
Ron Huizenga: Iste, a v skutočnosti jediný projekt, ktorý sa stal projektom potrubia, bol ten, na ktorý som spomínal, kde som ukázal graf s defektmi pred a po zapojení dátového modelára. Pomerne často a existujú predsudky, najmä ak sa veci roztočia tam, kde sa to robí z perspektívy čisto rozvoja, sú to práve vývojári, ktorí sú zapojení do týchto agilných projektov, aby dodávali aplikácie. Takže to, čo sa tam stalo, samozrejme je, že vystúpili z koľajníc a najmä ich dátové artefakty alebo výstupy údajov, ktoré vyrábali, nedosahovali kvalitatívnu úroveň a skutočne riešili veci celkovo. A často je táto mylná predstava o tom, že dátoví tvorcovia spomalia projekty, a ak nebudú mať správny prístup, budú tak robiť. Ako hovorím, musíte stratiť - niekedy existujú modelári údajov, ktorí majú tento tradičný postoj vrátnika, kde „Sme tu, aby sme kontrolovali, ako vyzerajú dátové štruktúry,“ a táto mentalita musí zmiznúť. Každý, kto sa podieľa na agilnom rozvoji, a najmä tvorcovia údajov, musí prevziať úlohu sprostredkovateľa, aby tímom skutočne pomohol napredovať. Najlepším spôsobom, ako to ilustrovať, je veľmi rýchlo ukázať tímom, ako produktívni môžu byť modelovaním zmien. A znova, preto som hovoril o spolupráci.
Existuje niekoľko vecí, ktoré môžeme najskôr modelovať a vygenerovať DDL, aby sme sa vyvíjali smerom k vývojárom. Chceme sa tiež uistiť, že sa necítia byť obmedzení. Ak teda existujú veci, na ktorých pracujú, nechajte ich pracovať vo svojich karanténach vývoja, pretože vývojári pracujú na svojich vlastných stolných počítačoch alebo iných databázach, aby vykonali určité zmeny tam, kde veci testujú. A spolupracujte s nimi a povedzte: „Dobre, pracujte s tým.“ Prinášame ho do nástroja, vyriešime ho a potom ho posunieme dopredu a poskytneme vám skripty, ktoré môžete nasadiť na aktualizáciu svojho databáz, ktoré ich inovujú na to, ako bude skutočný sankcionovaný skutočný pohľad na produkciu, keď budeme pokračovať vpred. A môžete to otočiť veľmi rýchlo. Zistil som, že moje dni sa naplnili tam, kde som práve chodil tam a späť iteráciou s rôznymi vývojovými tímami, pozeraním na zmeny, porovnávaním, generovaním skriptov, zabezpečovaním ich fungovania a po tom, čo sme boli schopní, som sa dokázal ľahko udržať so štyrmi vývojovými tímami dosiahol dynamiku.
Dez Blanchfield: Jedna z vecí, na ktorú z toho treba pamätať, je to, že viete, že veľa konverzácií, ktoré každý deň vediem, sa týka tohto nákladného vlaku prichádzajúceho k nám, typu stroj-stroj internet vecí. A ak si myslíme, že máme teraz veľa údajov o našich súčasných prostrediach v podniku, viete, že ak vezmeme jednorožce stranou na chvíľu, keď vieme, že údaje spoločnosti Google a tí a Ubers majú petabajty údajov, ale v tradičnom podniku hovoríme o stovkách terabajtov a množstve údajov. Podľa môjho názoru však tento nákladný vlak prichádza do organizácií a Dr. Robin Bloor sa k nemu zmienil už skôr z internetu vecí. Viete, máme veľa webového prenosu, máme sociálny prenos, teraz máme mobilitu a mobilné zariadenia, cloud má, nejaký, vybuchol, ale teraz máme inteligentnú infraštruktúru, inteligentné mestá a celý tento svet údajov je práve explodovaný.
Pre každodenné organizácie prichádza na nich stredná až veľká organizácia, ktorá tam sedí a vidí tento svet bolesti a nemá na mysli okamžitý plán. Aké sú niektoré možnosti jedenia, pár viet, ktoré by ste uviedli o tom, kedy a kde musia začať konverzovať o zavedení niektorých z týchto metodík. Ako skoro musia začať plánovať, aby sa takmer posadili a venovali pozornosť a hovorili, že je ten pravý čas na to, aby si zaviedli nejaké nástroje a vyškolili tím a dostali konverzáciu slovíčka okolo tejto výzvy? Ako neskoro v príbehu je príliš neskoro alebo kedy je príliš skoro? Ako to vyzerá pre niektoré z organizácií, ktoré vidíte?
Ron Huizenga: Pre väčšinu organizácií by som povedal, že ak tak ešte neurobili a prispôsobili modelovanie údajov a dátovú architektúru pomocou výkonných nástrojov, ako je tento, čas, ktorý potrebujú, je včera. Pretože je zaujímavé, že aj dnes, keď sa pozriete na údaje v organizáciách, máme v našich organizáciách toľko údajov a všeobecne povedané, na základe niektorých prieskumov, ktoré sme videli, efektívne využívame menej ako päť percent týchto údajov keď sa pozrieme naprieč organizáciami. A s IoT alebo dokonca NoSQL, veľké dáta - aj keď to nie je len IoT, ale všeobecne len veľké dáta - kde teraz začíname spotrebovávať ešte viac informácií, ktoré pochádzajú mimo našich organizácií, táto výzva sa stáva stále väčšou a väčšou celý čas. A jediný spôsob, ako máme šancu sa s tým vyrovnať, je pomôcť nám pochopiť, o čom sú tieto údaje.
Prípad použitia je teda trochu iný. Zistíme, že robíme, keď sa pozrieme na tieto údaje, zachytávame ich, musíme ich spätne analyzovať, zistiť, čo v nich je, či už je to v našich dátových jazerách alebo dokonca v našich interných databázach, syntetizovať, čo údaje sú, použite na ne významy a definície, aby sme pochopili, o aké údaje ide. Pretože kým nepochopíme, o čo ide, nemôžeme zaručiť, že ho používame správne alebo primerane. Preto skutočne potrebujeme získať informácie o tom, čo sú tieto údaje.A na druhej strane to nerobte, pretože v súvislosti so spotrebou všetkých týchto externých údajov môžete mať istotu, že máte prípad použitia, ktorý podporuje konzumáciu týchto externých údajov. Zamerajte sa skôr na veci, ktoré potrebujete, ako sa len snažte ťahať a využívať veci, ktoré by ste mohli potrebovať neskôr. Najprv sa zamerajte na dôležité veci a keď sa cez ne budete prepracovávať, prejdete na náročné a pokúsite sa porozumieť ostatným informáciám zvonka.
Dokonalým príkladom toho je, že viem, že hovoríme o IoT a senzoroch, ale rovnaký typ problému bol v mnohých organizáciách už mnoho rokov, dokonca aj pred IoT. Každý, kto má systém riadenia výroby, či už ide o potrubnú spoločnosť, výrobu, akékoľvek procesné spoločnosti, ktoré majú veci, v ktorých robia veľa automatizácie pomocou ovládacích prvkov a používajú dátové toky a podobné veci, majú tieto krby údajov, z ktorých sa snažia piť, aby zistili, aké sú udalosti, ktoré sa vyskytli v mojom produkčnom zariadení na signalizáciu - čo sa stalo a kedy? A medzi týmto obrovským tokom údajov existujú iba konkrétne informácie alebo značky, ktoré ich zaujímajú, ktoré potrebujú preosiať, syntetizovať, modelovať a porozumieť im. A môžu ignorovať zvyšok toho, kým nenastane čas, aby to skutočne pochopili, a potom môžu rozšíriť svoj rozsah pôsobnosti, aby ho stále viac rozširovali, ak to má zmysel.
Dez Blanchfield: Naozaj. Je tu jedna otázka, ku ktorej budem viesť, od pána Erica, o čom sme sa rozprávali súkromne. Práve som požiadal o jeho povolenie, ktoré vydal, aby som vás požiadal. Pretože to k tomu pekne vedie, stačí to zabaliť, pretože teraz ideme trochu časom a vrátim sa Ericovi. Otázka od iného Erica však bola, je rozumné predpokladať, že majitelia startupov sú oboznámení s jedinečnými výzvami okolo modelovania terminológie a tak im porozumieť, alebo by sa mali odovzdať niekomu inému na interpretáciu? Inými slovami, mal by byť startup schopný byť schopný a pripravený a ochotný a schopný sa naň zamerať a splniť ho? Alebo je to niečo, s čím by mali pravdepodobne nakupovať a priviesť odborníkov na palubu?
Ron Huizenga: Myslím, že krátka odpoveď je, že to naozaj záleží. Ak ide o startup, ktorý nemá niekoho interného, ktorý je dátovým architektom alebo modelárom, ktorý skutočne rozumie databáze, potom najrýchlejším spôsobom, ako začať, je priviesť niekoho s konzultačným zázemím, ktoré je v tomto priestore veľmi dobre oboznámené a môže získať idú. Pretože to, čo nájdete - av skutočnosti som to urobil pri mnohých zákazkách, ktoré som urobil predtým, ako som prišiel na temnú stránku v produktovom manažmente - je, že by som šiel do organizácií ako konzultant, vedel ich tímy architektúry dát, aby sa mohli nejakým spôsobom preorientovať a vyškoliť svojich ľudí o tom, ako robiť tieto druhy vecí, aby ich udržali a pokračovali v misii. A potom by som pokračoval k svojej ďalšej zákazke, ak to má zmysel. Existuje veľa ľudí, ktorí to robia, majú veľmi dobré skúsenosti s údajmi, ktoré ich môžu prinútiť ísť.
Dez Blanchfield: Je to skvelý bod na rozchod a ja s tým úplne súhlasím a som si istý, že by to urobil aj Dr. Robin Bloor. Najmä v začínajúcich podnikoch ste zameraní na to, aby ste boli MSP v konkrétnej hodnote ponuky, ktorú chcete vybudovať ako súčasť samotného začínajúceho podnikania, a pravdepodobne by ste nemuseli byť odborníkom na všetko, čo je výborná rada. Veľmi vám však ďakujem, fantastická prezentácia. Naozaj skvelé odpovede a otázky. Eric, vrátim sa ti, pretože viem, že sme za čas odišli asi desať minút a viem, že sa chceš držať blízko našich časových okien.
Eric Kavanagh: To je v poriadku. Máme aspoň pár dobrých otázok. Nechám vás jedno hodiť k vám. Myslím, že ste odpovedali na niektoré ďalšie. Ale veľmi zaujímavé pozorovanie a otázka od jedného účastníka, ktorý píše, niekedy agilné projekty majú dátový modelár, ktorý nemá celý dlhodobý obraz, a tak skončia navrhovaním niečoho v jednom a následným prepracovaním v troch alebo štyroch. Nezdá sa to kontraproduktívne? Ako sa tomu môžete vyhnúť?
Ron Huizenga: Je to len povaha agilnosti, že v danom prípade nedostanete všetko úplne v poriadku. A to je vlastne súčasť ducha agility: je s ním práca - budeš robiť prototypy, v ktorých budeš pracovať na kódech v danom, a budeš s tým robiť vylepšenia. Súčasťou tohto procesu je aj to, že dodávate veci, ktoré koncový používateľ vidí, a hovorí: „Áno, to je blízko, ale naozaj to musím urobiť aj trochu navyše.“ To nielenže ovplyvňuje funkčný dizajn. samotného kódu, ale často potrebujeme modifikovať alebo pridať viac dátových štruktúr pod tieto určité veci, aby sme dosiahli to, čo chce užívateľ. A to je všetko férová hra, a preto naozaj chcete používať vysoko výkonné nástroje, pretože môžete veľmi rýchlo modelovať a vykonať takúto zmenu v modelovacom nástroji a potom vygenerovať DDL pre databázu, s ktorou vývojári potom môžu pracovať, aby to dosiahli zmena ešte rýchlejšie. Zachránite ich tak, aby nemuseli robiť také ručné kódovanie dátových štruktúr a nechali sa sústrediť na programovaciu alebo aplikačnú logiku, ktorú najviac ovládajú.
Eric Kavanagh: To dáva zmysel. Mali sme niekoľko ďalších ľudí, ktorí sa pýtali len na konkrétne otázky týkajúce sa toho, ako sa to všetko spája s týmto nástrojom. Viem, že ste strávili nejaký čas prípravou príkladov a ukazovali ste niekoľko snímok obrazovky o tom, ako skutočne niektoré z týchto vecí zverejňujete. Ako často vidíte v rámci celého tohto procesu, že v hrách v organizáciách versus ako často vidíte tradičnejšie procesy, v ktorých sa veci spravidla líšia a zaberajú viac času? Aký prevládajúci je prístup v štýle s z vášho pohľadu?
Ron Huizenga: Myslím, že to vidíme stále viac. Viem, že by som povedal, že najmä v posledných 15 rokoch som videl oveľa viac adopcie ľudí, ktorí uznávajú, že skutočne potrebujú prijať rýchlejšie doručenie. Takže som videl, ako čoraz viac organizácií skočí na agilný rozbehový vagón. Nie nevyhnutne úplne; môžu začať s niekoľkými pilotnými projektmi, aby dokázali, že to funguje, ale niektoré sú stále veľmi tradičné a držia sa metódy vodopádu. Dobrou správou je, samozrejme, že nástroje fungujú v týchto organizáciách veľmi dobre, ako aj pri týchto typoch metodík, ale v nástroji máme prispôsobivosť, aby tí, ktorí skočia na palubu, mali nástroje v paneli nástrojov na ich končeky prstov. Veci, ako je porovnanie a zlúčenie, veci, ako sú funkcie spätného inžinierstva, takže môžu vidieť, aké sú existujúce zdroje údajov, takže môžu skutočne veľmi rýchlo porovnávať a generovať prírastkové skripty DDL. A keď to začnú objať a uvidia, že môžu mať produktivitu, ich náklonnosť prijať agilné ešte viac sa zvyšuje.
Eric Kavanagh: Toto je skvelé veci, ľudia. Práve som uverejnil odkaz na snímky v okne rozhovoru, takže si to skontrolujte; je to pre teba trochu bitly. Všetky tieto webové vysielania máme na neskoršie prezeranie. Neváhajte a podeľte sa o ne so svojimi priateľmi a kolegami. A Ron, ďakujem vám veľmi pekne za váš čas, že ste vždy radi, že ste na výstave - skutočný odborník v tejto oblasti a je zrejmé, že poznáte svoje veci. Vďaka vám a vďaka IDERA a samozrejme Dezovi a nášmu vlastnému Robinovi Bloorovi.
A s tým sa ti chceme rozlúčiť, ľudia. Ešte raz vám ďakujem za váš čas a pozornosť. Ceníme si, že ste sa držali 75 minút, čo je celkom dobré znamenie. Dobrý chlapci, ukážeme sa nabudúce. Zbohom.