Od zamestnancov Techopedia, 16. novembra 2016
Jedlo so sebou: Host Eric Kavanagh diskutuje o dôležitosti modelovania údajov v agilnom vývoji s Robinom Bloorom, Dezom Blanchfieldom a Ronom IDizinom od 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. Je streda o 4:00 EST. To znamená, že je čas na Hot Technologies. Ano, naozaj. Volám sa Eric Kavanagh, budem tvojím hostiteľom.
Pre dnešnú tému je to starec, ale dobrota. Zlepšuje sa každý deň, pretože to formuje náš svet pre správu údajov „Dátové modelovanie v agilnom prostredí“. Naozaj sa tu hovorí o vás, zasiahnite ma na Twitteri @eric_kavanagh. Mali by sme to naozaj dať na tú snímku. Budem sa tým musieť venovať.
Takže rok je horúci. 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 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? Dozvieme sa o tom. Dozvieme sa, ako môžete zostať na špičkách agilným spôsobom. A to je samozrejme slovo roka.
Robin Bloor je s nami, našim hlavným analytikom, Dez Blanchfieldom, ktorý volá zo Sydney, Austrálie a Ron Huizenga, senior produktovým manažérom spoločnosti 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 mu ťažké otázky, ľudia, tie ťažké. S tým urobím Robina moderátora a zoberiem ho preč.
Robin Bloor: Dobre. Ď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. Takže sa pozeráme 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 myslel som si, že dám všeobecný prehľad o modelovaní, ale je tu realita, ktorá sa teraz stáva zjavnou.
Máme, viete, veľká dátová realita, máme viac údajov, viac zdrojov údajov, máme dátové toky, ktoré vstúpili do rovnice za posledné tri alebo štyri roky a začínajú ich získavať väčšiu časť, a je potrebné lepšie porozumieť údajom a zvýšiť mieru zmeny, čím viac údajov sa pridáva a využíva sa aj viac dátových štruktúr.
Je to ťažký svet. Tu je obrázok toho, čo je vlastne niečo, čo sme si vytvorili asi pred tromi rokmi, ale v zásade, 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 skutočne v pokoji, v tom zmysle, že sa to moc nepohybuje. A potom sú tu dáta, streamy a máte všetky transakčné aplikácie, plus dnes máte udalosti, dátové toky udalostí, ktoré sa odohrávajú v aplikáciách a možno budú musieť, a dnes, s architektúrami lambda, o ktorých všetci hovoria, sú skutočne ktoré majú vplyv iba na celú oblasť ú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 čo ide, keď sa pohnem, 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ť obrovské problémy. 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ď sú zostavené a čo to znamená, keď sú „ znovu sa pripojil k iným údajom, požaduje, aby sme ich modelovali. Nestačí len zaznamenávať značky 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. A ak medzi týmito vrstvami budeme mať nesúlad, 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é striedať sa. Je dosť ľahké zachytiť metadáta v rámci záznamu a byť schopný ich získať z viacerých významov, ale nehovorí vám to o štruktúre záznamov alebo o tom, čo záznamy znamenajú alebo o súvislostiach záznamu.
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 keby sme do sveta nepridávali len viac vecí, ktoré by zodpovedali záznamom údajov, ale v skutočnosti pridávame svetu väčší význam zachytením údajov o čoraz väčšom počte vecí. Je to čoraz komplexnejší pocit, ktorému musíme porozumieť.
Teoreticky existuje dátový vesmír a my na to potrebujeme 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á aktivita - mala by byť nepretržitou aktivitou v každom prostredí, v ktorom existuje. Našťastie existuje veľa prostredí, kde tomu tak v skutočnosti nie je a veci sa vymknú spod kontroly.
V budúcnosti sa modelovanie zvyšuje s tým, ako sa technológia posúva vpred. To je môj názor. Ak sa však pozriete na internet vecí, dokážeme pochopiť mobil viac, ako sme zvyknutí, hoci sa ním zavádzajú nové dimenzie: dimenzia umiestnenia v mobile. Akonáhle sa dostanete na internet vecí, pozeráme 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 máme, presne ako ich môžeme agregovať, čo môžeme urobiť z hľadiska získania významu zo agregácie a samozrejme, čo s tým môžeme urobiť, keď sme ho spracovali.
Myslím, že som to už dosť povedal. Idem na Dez Blanchfielda, ktorý povie niečo úplne 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. Jedna z jedál s sebou a ja nechcem ukradnúť hrom tejto konkrétnej, ale jedna z jedál z našej bannery pre presvedčenie, ktorú chcem zdieľať, v prípade, že ste ju nezachytili, sa týkala iba témy cesta údajov, a prinútilo ma to skutočne napísať, premýšľať o ceste, ktorú údaje prechádzajú v inom kontexte okolo generačnej životnosti - rok, mesiace, týždeň, deň, hodina, minúta, sekunda - a kontext okolo údajov je umiestnené v tomto kontexte. Či už som vývojár, ktorý pracuje s kódom, alebo či som špecialista na údaje a 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ý predmet, 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 návrhu údajov, hovoríme o modernom agilnom návrhu údajov a podľa môjho názoru nie je to tak dávno, čo 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. Dnes som však veľmi presvedčený, že nielen to sa zmenilo, ale aj to sa musí 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. To je teraz tímový šport, a teda môj obraz skupiny ľudí, ktorí vyskočili z lietadla a pôsobili 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. 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 ľudia, už sme počuli o majstrovi scrumu, 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 sprinty, 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ľ, čo sa však stalo s vývojármi v rozvojovom svete, nejako chytilo túto agilnú metodológiu a bežalo s ňou rovno, ak odpustíte slovnú hračku, pri sprinte.
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 uvádzam, 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 úzko zapojiť do každej zložky poskytovania projektov, skutočne, najmä do rozvoja. Aby sme to neurobili, potom si naozaj nedávame najlepšiu šancu na dobrý výsledok. Často sa musíme obracať späť a premýšľať o týchto veciach, pretože existuje scenár, dostávame sa k vytvorenej aplikácii a zistíme, že vývojári nie sú vždy odborníci na údaje. Práca s databázami si vyžaduje veľmi špecializované zručnosti, najmä okolo údajov, a vytvára si skúsenosti. Nestanete 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ákladom pre guruové inžinierstvo o tom, ako prichádzajú údaje a ako organizuje cestu, po ktorej sa vydáva a ako by malo alebo nemalo vyzerať, alebo nepochybne to, že sa prehltlo a pochopilo, že sa zvyčajne získava 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 uviedli v kontexte, zahŕňajú napríklad základné vytváranie a údržbu a správu samotného návrhu základnej databázy, dokumentovanie ú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 sa predajom zobraziť všetky záznamy v tabuľke alebo by mali vidieť iba adresu, krstné meno, priezvisko, ktoré vám pošle veci 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 rieši tieto veci.
Ron Huizenga: Ďakujem vám veľmi pekne a ďakujem Robinovi aj Dezovi za to, že ste sa na javisku skutočne postavili dobre, a v niekoľkých veciach, o ktorých som hovoril, uvidíte trochu prekrývania. Skutočne však vytvorili veľmi solídny základ pre niektoré z konceptov, 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 chystám veľmi stručne venovať, je to, že sa nebudem podrobne venovať podrobnostiam; 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 počas sprintu, aké druhy činností by mali byť zapojené do 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 nebudeme dnes 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.
To, 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ž v úvode spomínali, je nevyhnutné, aby sme mali dátových modelov a / alebo architektov plne zapojených do agilných vývojových procesov. Historicky sa však stalo, že sme skutočne 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 kontexte vývojového projektu, v ktorom vyvíjame aplikáciu, ktorá s ňou samozrejme bude mať tiež spojenú 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 každý šprint. 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 agility je to, že veci zakladáte na nevybavených príbehoch alebo požiadavkách. V rámci iterácií spolupracujeme ako skupina. Zvyčajne je bežný dvojtýždňový alebo jednomesačný šprint v závislosti od organizácie. A tiež denné kontroly a standup stretnutia, aby sme eliminovali blokátory a zabezpečili, že ideme všetky aspekty vpred bez toho, aby sme sa zastavili v rôznych oblastiach, keď prechádzame. A v týchto sprintoch sa chceme uistiť, že vyrábame použiteľné výstupy ako súčasť každého sprintu.
Len trochu odlišný názor, ktorý sa ďalej rozširuje, 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é produkty a potom nevybavené sprinty. Máme teda celkový počet nevybavených vecí, ktoré sa na začiatku každého opakovania sprintu píšu: „Čo budeme stavať tento šprint?“ A to sa deje na stretnutí plánovacieho sprintu. Potom rozdelíme úlohy, ktoré s tým súvisia, a vykonávame v týchto jedno až štvortýždňových šprintoch 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 sú spracovávané nepretržite počas sprintu, namiesto toho, aby ste šli niekoľko mesiacov po ceste a zistili, že prídete málo a je potrebné predĺžiť harmonogram projektu. A veľmi dôležité, ako súčasť toho, celé tímy, je na konci kontrola sprintu a retrospektíva sprintu, takže predtým, ako odštartujete ďalšiu iteráciu, skúmate, čo ste urobili, a hľadáte spôsoby, ako môžete vylepšiť sa nabudúce.
Pokiaľ ide o výstupy, jedná sa v podstate o snímku, ktorý sumarizuje typické typy vecí, ktoré sa odohrávajú v sprintoch. 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 v každom sprinte.
Niektorí ľudia povedia, že na konci každého sprintu 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ú hodnotu sprintu, 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 budujeme vpred ako tím, keď ideme vpred. Vždy je trochu času na prípravu, takže často budeme mať sprintu nulu alebo dokonca nulu sprintu a jednu. Môže to byť trochu fáza uvedenia do prevádzky skôr, ako sa nám podarí doručiť riešenie.
V tejto súvislosti sa veľmi stručne bavíme o údajových modeloch. 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, mám na mysli nielen relačné databázy, ktoré môžeme používať, ale aj 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é sklady, 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 z toho, ako tieto informácie vytrváme alebo ich tiež ukladáme z našich riešení.
V kontexte danej aplikácie môžeme pracovať súčasne s viacerými databázami alebo zdrojmi údajov súčasne. Veľmi dôležité je, aby sme boli schopní mať úplnú špecifikáciu, takže logická špecifikácia toho, čo to znamená pre organizáciu sprintu, čo sú fyzické konštrukty z hľadiska toho, ako skutočne definujeme údaje, vzťahy medzi nimi v vaše 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 vec, 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é.
Podieľal som sa na projektoch, kde sme nahradili viac ako tucet starých systémov novými obchodnými procesmi a navrhoval som nové aplikácie a dátové úložiská, ktoré ich nahrádzajú. 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 dát, či sú to master 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, ja sa chystám prejsť zvyškom týchto pomerne rýchlo.
Teraz budem hovoriť veľmi rýchlo o tom, čo robí dátový modelár, keď prechádzame cez tieto rôzne sprinty. Najskôr je to úplný účastník relácií plánovania sprintu, kde berieme užívateľské príbehy, dopúšťame sa toho, čo v tomto sprinte 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 to 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 by pracoval na zadaní objednávky, kde robíme všetky tieto veci v jednom sprinte, 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 sprintu alebo na konci z niekoľkých sprintov, chceme vedieť, kde sme začali a vždy máme východiskovú hodnotu, aby sme vedeli, aká bola delta alebo rozdiel toho, čo sme v danom sprinte vyrobili. 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 vozu, ktorý robí daný sprintu, a vy ich vyzdvihnete v neskorších sprintoch.
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. Pri neskoršom sprinte 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 v jednom sprinte; 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 opakujeme celú cestu až k nášmu sprintu, 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 šprintu s rôznymi vývojovými tímami, s ktorými pracujeme.
Aj v aktivitách sprintu je to opäť tá základná línia na porovnanie / zlúčenie, takže sa pozrime na modelovanie 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é. Môžeme tiež použiť túto schopnosť porovnávania a zlúčenia v ktoromkoľvek danom čase. Ak na ceste robíme snímky, môžeme vždy porovnať začiatok jedného sprintu s začiatkom alebo koncom iného sprintu, aby sme videli úplná inkrementálna zmena toho, čo sa stalo v danom vývojovom sprinte alebo v sérii sprintov.
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ť.
Budeme 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 neprelomíme. Č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 videli iba rôzne objekty vyššej úrovne, čo tiež veľmi dobre funguje pri komunikácii s podnikaním. 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 dostanem na koniec sprintu, na konci zabalenia sprintu, mám veľa vecí, ktoré musím urobiť, ktoré nazývam upratovacou službou pre ďalší šprint. Každý šprint 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 sa v budúcnosti budem venovať všetkým základným líniám alebo pomenovaným vydaniam, ktoré vytvorím a uložím do svojho úložiska, ktoré môžem použiť na porovnanie / zlúčenie, takže vždy môžem porovnávať s akýmkoľvek daným koncom sprintu z akéhokoľvek iného sprintu, ktorý je veľmi dôležité vedieť, aké boli vaše zmeny v údajovom modeli na jeho ceste.
Vytvorím tiež skript delta DDL pomocou porovnania / zlúčenia znova od začiatku do konca sprintu. Možno som skontroloval celý zväzok inkrementálneho skriptu, ale ak to potrebujem, mám teraz skript, ktorý môžem nasadiť, aby som postavil ďalšie karantény, takže môžem len povedať, že toto sme mali na začiatku jedného sprintu, push cez to vytvorte databázu ako karanténu a začnite s ďalším šprintom. Tieto veci môžeme použiť aj na vykonávanie úloh, 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. zároveň. Opäť sa plne zúčastňujeme na plánovaní sprintu 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 oslavujte aj veci, ktoré sa ukázali správne, a stavajte na nich, keď sa v ďalších šprintoch budete 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. 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 v priebehu zhruba polovice sprintu 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ž vývojovú tyčinku. stavať ich 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ým zástancom 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, keď 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, dobre, dovoľte mi ho najskôr hodiť Robinovi. A potom, Dez, som si istý, že máte pár otázok. Zober to preč, Robin.
Robin Bloor: Dobre. Ú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 fáze. 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 sprinte nula je podľa môjho názoru absolútne dôležitá, pretože sa tam naozaj snažíte získať výsledky. A ak nechcete, aby boli výstupy pripnuté, výstupy zmenia tvar.
To je môj názor. Je to tiež môj názor - naozaj nemám nijaký argument s myšlienkou, že pred tým, ako prejdete, musíte modelovať údaje 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 projektov. 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, dobre, 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 kontext bez tabuľky presne toho, čo to je.
Zvyčajne sa 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, všeobecne 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 sprintoch, 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ždého sprintu.
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äčší názor na dôležitosť správy údajov, pretože v týchto pôvodný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 mala, povedzme, urobiť historicky v oblasti správy údajov. 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 vyhradený čas. Dez?
Dez Blanchfield: Áno, ďakujem. Cez celú túto vec sa dívam 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ívny význam; 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 chybami 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 čisto vývojového hľadiska, iba vývojári, ktorí sú zapojení do týchto agilných projektov, dodávajú 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, že dátoví tvorcovia spomaľujú 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 opäť, 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 pracovných plochách alebo iných databázach, aby urobili nejaké 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 príde, je, že viete, že veľa konverzácií, ktoré každodenne robím, je o tomto nákladnom vlaku, ktorý prichádza k nám, - stroj a IoT. 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 Facebook 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 ďalšou časťou je, že to nerobte, pretože v súvislosti so spotrebou všetkých týchto externých údajov sa môžete uistiť, ž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ď si cez ne budete postupovať, dostanete sa k spotrebovaniu a skúmaniu ďalších informácií zvonku.
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 ešte 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 naozaj závislá. Ak ide o startup, ktorý nemá niekoho interného, ktorý je dátovým architektom alebo modelárom, ktorý naozaj 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: To je skvelý štartovací bod 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 súvislosti s konkrétnou hodnotou ponuky, ktorú chcete vybudovať ako súčasť svojho začínajúceho podnikania, a pravdepodobne by ste nemuseli byť odborníkom na všetko, tak skvelú radu. 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 preš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 má agilné projekty, že dátový modelár nemá celý dlhodobý obraz, a tak skončia navrhovaním niečoho v sprinte jeden a potom musia prepracovať v sprinte tri alebo štyri. Nezdá sa to kontraproduktívne? Ako sa tomu môžete vyhnúť?
Ron Huizenga: Je to len povaha agility, že v danom sprinte nedostanete všetko úplne v poriadku. A to je vlastne súčasť ducha agility, je: pracovať s tým - budeš robiť prototypy, kde budeš pracovať na kóde v danom sprinte a budeš ho vylepšovať. 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 môžu vývojári pracovať, aby ju dosiahli. zmena ešte rýchlejšie. Šetríte ich tak, aby nemuseli robiť také kódovanie rúk, ako to bolo, 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 tým, že ste si prešli príkladmi, a ukazovali ste nejaké screenshoty o tom, ako skutočne niektoré z týchto vecí rozviniete. Ako často vidíte tento celý proces sprintu v organizáciách v porovnaní s tým, 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 sprintu 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 čoraz viac organizácií skočiť 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, aj pre tieto typy 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: No, toto sú 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 rozlúčime, ľ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é show chlapci, budeme sa s vami baviť nabudúce. Zbohom.
