Одузети: Домаћин Ериц Каванагх говори о важности моделирања података у агилном развоју с Робином Блоор-ом, Дез Бланцхфиелд-ом и ИДОНА-иним Роном Хуизенгом.
Тренутно нисте пријављени. Пријавите се или пријавите да бисте видели видео.
Ериц Каванагх: У реду даме и господо. Добродошли још једном. Његова среда у 4:00 ЕСТ. То значи да је време за Хот Тецхнологиес. Да заиста. Моје име је Ериц Каванагх, бит ћу вам домаћин.
За данашњу тему, то је стара али добра ствар. Сваким даном је све боље јер његово обликовање свијета управљања подацима, „Моделирање података у окретном окружењу.“ Доиста је слајд о вашем, на @ериц_каванагх. Требали бисмо то заиста ставити на тобоган. Морам на то.
Тако су топле године. Моделирање података није било вечно. Стварно је било у срцу и души пословања с управљањем информацијама, дизајнирања модела података, покушавања разумијевања пословних модела и прилагођавања њиховим моделима података. То стварно покушаваш да урадиш, зар не?
Модел података представља посао на фундаментални начин, па како сви ти нови извори података мењају игру? Сазнаћемо о томе. Сазнаћемо како на агилни начин можете остати на врху ствари. И наравно, то је реч године.
Робин Блоорс са нама, наш главни аналитичар, Дез Бланцхфиелд који се јавља из Сиднеиа у Аустралији и Рон Хуизенга, старији менаџер производа из ИДЕРА-е - дугогодишњи пријатељ, одличан говорник у овом простору, зна што треба, па немојте бити стидљиви тешка питања, народе, она тврда. С тим ћу направити Робина као водитеља и одузети.
Др Робин Блоор: У реду. Па, хвала ти на томе, Ериц. О моделингу морам да кажем да мислим да сам заправо био у свету ИТ пре његовог постојања, у смислу да се сећам у осигуравајућој компанији за коју сам радио да смо имали момка да нам уступи све врсте радионице о начину моделирања података. Дакле, гледали смо око 30 година, да ли је то 30 година? Можда и дуже од тога, можда пре 35 година. Дуго и дуго времена моделирање је било део индустрије и, наравно, нема никакве везе са дамама на модним пистама.
Оно што сам хтео да кажем, јер оно што обично радимо, ја и Дез разговарамо о различитим стварима и само сам мислио да Ид пружим општи преглед моделирању, али реалност тога, то сада постаје очигледно.
Ми имамо, знате, стварност великих података, имамо више података, више извора података, добили смо токове података који су ушли у једначину у последње три или четири године и почиње да добија већи део тога, и ту је већа потреба за разумевањем података и повећање стопе промене која се више додаје и такође се користи више структура података.
То је тежак свет. Ево слике о томе, што је заправо нешто што смо нацртали пре три године, али у основи, једном када укључите стреаминг у микс и добијете ту идеју о рафинерији података, чворишту података, вези података или било чему другом, видећете да постоје подаци који истински у мировању, у смислу да се не креће превише. И тада су ти подаци, токови и ви добили сву трансакцијску апликацију, плус данас имате догађаје, токове података о догађајима који се дешавају у апликацијама и можда ће требати, а данас са ламбда архитектурама о којима сви причају, заиста имају утицаја на само читаво поље података.
И данас размишљамо у смислу постојања податковног слоја. Слој података постоји на неки виртуелни начин, у смислу да добар део тога може бити у облаку и може се ширити по центрима података, може постојати и на радним станицама. Слој података је, у одређеној мери, свуда и у том смислу, свугде постоје процеси који покушавају на један или други начин да обраде податке и померају податке. Али и знати шта је то када се крећете, велика је ствар.
Ако моделирање података посматрамо у најопћенитијем смислу, на дну ове врсте снопака имате датотеке и базе података. Имате елементе података који имају кључеве, дефиниције елемената, псеудонимере, синониме, специфичне физичке формате и тада имамо овај слој метаподатака.
Занимљивост код метаподатака је да метаподаци у потпуности добијају на значењу података. Ако заправо немате метаподатке, онда у најбољем случају можете погодити значење података, али имат ћете огромне потешкоће. Метаподаци морају бити тамо, али значење има структуру. Не желим да улазим у филозофију значења, али чак и у начину на који обрађујемо податке, постоји пуно софистицираности људске мисли и људског језика, што се лако не изражава у подацима. Али чак и у погледу података које ми заправо обрађујемо у свету, метаподаци имају значење и структуру метаподатака - један податак у односу на други и шта то значи када се саставе и шта то значи када су спојени са другим података, захтева да га моделирамо. То није довољно добро да бисте ствари забележили само метаподацима, заправо морате да забележите значење по структурама и однос између структура.
Затим имамо на горњем слоју пословне дефиниције, што је обично слој који покушава да пренесе значење између метаподатака, што је облик дефиниције података који одговара начину на који се подаци организују на рачунару и у људском значењу. Дакле, имате пословне изразе, дефиниције, односе, концепте на нивоу ентитета који постоје у том слоју. А ако би дошло до неусклађености између тих слојева, тада морамо имати моделирање података. То заиста није опционо. Што више можете то учинити у смислу аутоматизације, то боље. Али зато што има везе са значењем, заиста је тешко изменити. То је довољно лако да унесете метаподате у запис и будете у могућности да га добијете из низа значења, али не говори вам о структури записа или о томе шта записи значе или који су у питању.
Дакле, по мом мишљењу се ради о моделирању података. Напомена: што сложенији свемир података постаје, то вам је више потребно да га моделирате. Другим речима, помало је додавало не само више примерака ствари у свету, што би одговарало записима података, већ су у ствари додавало више значења свету, хватајући податке о све више и више ствари. Постаје све сложенији осећај који морамо да разумемо.
Теоретски је свемир података и потребан нам је приказ. У пракси су стварни метаподаци део свемира података. Дакле, то није једноставна ситуација. Моделирање на почетку је одоздо на доле и одоздо нагоре. Морате градити у оба смера, а разлог за то је да подаци имају значење за рачунар и процес који га морају обрадити, али сами по себи имају значење. Дакле, потребно вам је значење одоздо према горе, које задовољава софтвер који треба да приступи подацима и потребно вам је значење одоздо нагоре да би људска бића могла да га разумеју. Изградња модела метаподатака није и никада не може бити пројекат; његова стална активност - требала би бити континуирана активност у сваком окружењу у којем постоје. Срећом, постоји пуно окружења у којима то заправо није случај и ствари испадну изван контроле.
Како напредује напред, моделирање се повећава са важношћу како технологија напредује. То је моје мишљење. Али ако погледате ИоТ, мобилни можемо разумети више него што смо навикли, иако су његове нове димензије: димензија локације са мобилним уређајем. Једном када дођете до ИоТ-а, гледали смо изванредне проблеме са подацима које никада пре нисмо морали да радимо и морамо, на један или други начин, да правилно схватимо шта тачно имамо, тачно како то можемо да објединимо, шта можемо да урадимо у смислу добијања значења од здруживања и, наравно, шта са тим можемо да урадимо кад га обрадимо.
Мислим да сам то рекао довољно. Прећи ћу на Дез Бланцхфиелд, који ће у потпуности рећи нешто друго.
Дез Бланцхфиелд: Хвала вам. Увек тежак чин који треба следити, али ово је тема о којој смо се договорили и о томе смо кратко говорили у најави за предјављивање, а ако би рано бирали број, вероватно сте ухватили гомилу сјајних драгуља. Један од подухвата, а ја не желим да украдем гром овог конкретног, али један од одлазака са нашег престолонасловног списка који желим да поделим, у случају да га нисте ухватили, био је само око теме путовања података , и погодило ме је да то заправо напишем размишљајући о путовању које подаци заузимају у различитом трајању у генерацијском животном веку - години, месецима, недељи, дану, сату, минуту, секунди - а разлози око података су смештени унутар тог . Било да сам програмер који ради на шифри, или да ли ја специјалиста за податке и ја размишљам о структури и формату и метаподацима око сваког од елемената, или начину на који систем и посао комуницирају с њим.
Интересантан је мали потез само да напоменем, али свеједно, допустите ми да уђем. Конкретни дизајн података је фраза коју користим за разговор о свим стварима и конкретно развоју било које апликације или базе података. Мислим да је дизајн података израз који само све добро схвата у мом уму. Ових дана када говоримо о дизајну података, говоримо о модерном агилном дизајну података, и по мом мишљењу је да програмери и стручњаци за податке нису тако давно радили; били су у сопственим силосима, а делови дизајна прелазили су из једног у други силос. Али ја увелико гледам на ставове ових дана, да се није само случај променио, већ се мора променити; то је врста потребе и то је та апликација - програмери и било шта што се може учинити око развоја који се бави подацима, дизајнери који раде релевантне елементе дизајна шема и поља и записа и системе и инфраструктуре база података и база података, моделирање и целокупно управљање изазов око тога. То је сада тимски спорт и одатле моја слика гомиле људи који искачу из авиона који делује као тим који ће играти ту визуелно занимљиву слику људи који падају у небо.
Треће, шта се догодило да се ово деси? Па, постоји чланак из 1986. године који су написала двојица господе чија сам имена очајнички покушао да оправдем, Хиротака Такеуцхи и Икујиро Нонака, мислим да се то изговара, произвели чланак који су назвали "Помицање скреда доле". Увели су ова идеја о методологији добијања игре у рагбију произишла из ове активности сцрума, где се сви крећу на једном месту, а два тима у основи закључавају главе у нечему што се зове сцрум да би покушали да преузму контролу над лоптом и играју је низ терен да доћи до пробне линије и додирнути земљу лоптом и добити бод, зван трина, и поновите овај поступак и добићете више бодова за тим.
Овај је чланак објављен 1986. у Харвард Бусинесс Ревиев-у, а знатижељно је да је заправо добио велику пажњу. Привукла је велику пажњу јер је увела невероватне нове концепте и овде је снимак екрана фронте. Тако су овај концепт сцрумпа извукли из игре у рагбију и увели га у посао, посебно у игру дизајна и испоруке пројеката, тачније испоруку пројеката.
Оно што је Сцрум учинио било нам је давање нове методологије у поређењу са ПРИНЦЕ2 или ПМБОК-ом које смо претходно користили у ономе што смо звали методологија водопада, знате, радите ово и ово и ово и следите их у редоследу и повежите се све тачке около, што зависи од тога шта сте имали или не радите други део док нисте урадили први део, јер је зависило од првог дела. Оно што нам је пружило је нова методологија да будемо мало флексибилнији, одакле и потиче термин, о начину на који испоручујемо ствари, а посебно око дизајна и развоја широке испоруке пројеката.
Неки од кључних станара - управо тако и наставим с тим - су око кључних станара смећа.Увела је идеју о изградњи нестабилности, да ефективно ако размишљате о страху од хаоса, свет постоји у стању хаоса, али планета се формирала, што је интересантно, тако да градите нестабилност, способност да се мало поскочите и и даље раде ствари, самоорганизујући пројектне тимове, преклапајући се фаворитима кроз веома одговоран развој, различите врсте учења и контроле кроз пут реализације пројекта, организациони пренос учења. Па како узети податке из једног дела пословања и пренети их у други од људи који имају идеју, али не развијају код или не развијају базе података и инфраструктуру, већ податке тим људима? А посебно тачно утврђени исходи. Другим речима, учинимо то током одређеног времена, било на дан као у 24 сата или недељу или неколико недеља и видећемо шта можемо да учинимо, а затим се повучемо и погледамо.
И тако, ако опростите пунку, ово је заиста нова игра у испоруци пројеката и три главне компоненте које ће имати смисла док мало даље дођемо овде - ту је производ: сви ти људи имају идеју и имају потреба да се нешто заврши и прича која их окружује. Програмери који раде у окретном моделу приказивања својих прича и свакодневним стајлингом користећи сцрум методологију да би расправљали о њој и разумели шта треба да ураде, а онда само наставите и наставите то радити. Тада смо људи чули за мајсторе страха који ово целокупно надгледају и довољно добро разумију методологију да га покрену. Сви смо видели ове слике које сам добио са десне стране овде, зидова и беле табле пуне Пост-Ит белешки, а служиле су као Канбан зидови. Ако не знате ко је Канбан, позивам вас на Гоогле ко је био господин Канбан и зашто је то била промена у начину на који премештамо ствари са једне стране на другу у зиду буквално али у пројекту.
На први поглед ово ради: узима списак ствари које организација жели да уради, проведе их кроз низ ствари које називамо сс који су подељени у периоде од 24 сата, месеце и ми добити ову инкременталну серију резултата. Значајна је промена у начину на који се пројекти испоручују, доведени до те фазе, јер део тога тече попут америчке војске која је у великом делу развијала нешто што се зове ПМБОК, попут идеје да тенк не изведу у терен док не убацујете метке у ствар, јер ако тенк у пољу нема метака, то је бескорисно. Дакле, један део је ставио метке у тенк, други део је ставио тенк у поље. Нажалост, ипак, оно што се десило са програмерима у свету развоја некако је схватило ову агилну методологију и испало је с њом, ако се опростиш с пуном, на с.
Неизбежно се догодило што када помислимо на агилност обично мислимо на програмере, а не на базе података и било какве везе са светом база података. Био је то несретан исход, јер реалност је да окретност није ограничена на програмере. Заправо, по мом мишљењу појам агилни често је погрешно повезан искључиво са програмерима софтвера, а не дизајнерима база података и архитектима. Безброј истих изазова са којима се сусрећете у развоју софтвера и апликација суочени су у свему што се тиче дизајна и развоја, рада и одржавања, а самим тим и података, а нарочито база података. Актери у овом посебном преносу података укључују симпатије архитеката података, израђивача, администратора, менаџера инфраструктуре база података и самих база података све до пословних и аналитичара система и архитеката, људи који седе и размишљају о томе како систем и послују и како смо дошли до протока података кроз њих.
То је тема коју редовно постављам, јер је моја стална фрустрација у томе што сматрам да стручњаци за податке морају - не би требали - сада морају да буду интимно укључени у сваку компоненту пружања пројеката, заиста, посебно у развоју. Да то не бисмо урадили, ми заиста не дајемо себи најбољу шансу за добар исход. Често се морамо кружити уназад и размишљати о тим стварима јер постоји сценариј, стижемо до апликације која се гради и откривамо да програмери нису увек стручњаци за податке. За рад са базама података неопходне су веома специјализоване вештине, посебно око података, и граде искуство. Нећете одмах преко ноћи постати гуру базе података или стручњак за знање података; то је често нешто што долази из животног искуства и свакако са ликовима доктора Робина Блоор-а из емисије Цоде Тодаи, који је прилично богато написао књигу.
У многим случајевима - и то је несрећа, али то је реалност - да постоје два дела ове кованице, односно да програмери софтвера имају сопствену замјену стручњака за базе података и изградили су вештине које су вам потребне у моделирању дизајна база података, а развој модела је управо онај основно за инжењеринг гуруа о томе како подаци долазе и како организација путовања траје и како би требало да изгледа или не би требало да изгледа или је несумњиво то што су прогутали и разумевање да се обично стиче у домаћим вештинама које су постављене програмерима софтвера. А неки од уобичајених изазова са којима се суочавамо, само да то повежемо, обухватају само основно креирање и одржавање и управљање самим дизајном основних база података, документовање података и инфраструктуре базе података, а затим поновну употребу тих података, нацрте шема, генерације шеме, администрација и одржавање шеме и њихова употреба, дељење знања око тога зашто је ова шема дизајнирана на одређени начин, а снаге и слабости које долазе с тим током времена узрокују промене података у току времена, моделирање података и врсте модела које примењујемо на системе и податке које преносимо кроз њих. Генерирање кода базе података и иде на интеграцију, а затим се моделирају подаци око њих, а затим бржи приступ контроли сигурности око података, интегритет података. Ми се крећемо тим подацима док задржавамо њихов интегритет, има ли довољно метаподатака Да ли би продаја требало да види све записе у табели или би требало да виде само адресу, име, презиме које уносиш у пост? А онда је, наравно, највећи изазов све то моделирање платформи база података које је само по себи другачији разговор.
Веома сам мишљења да је, имајући све то у виду да би се омогућила било која од ових нирвана, апсолутно критично да и стручњаци за податке и програмери имају одговарајуће алате и да ти алати могу бити способни за тимски фокусирано пружање пројеката, дизајн, развој и текуће оперативно одржавање. Знате, ствари попут сурадње у пројектима између стручњака за податке и програмера, јединствена тачка истине или јединствени извор истине за све ствари око документације самих база података, података, шема одакле потјечу записи, власници тих записа . Мислим да је у данашње доба и то апсолутно критично, схватићемо ову нирвану података да смо краљ, да прави алати морају бити постављени јер је изазов превелик за нас да то сада радимо ручно и ако људи Улазак и излазак из једне организације, превише је лако да не следимо исти поступак или методологију које би једна особа могла поставити да су добри и не морају нужно да пренесу те вештине и способности напред.
Имајући то у виду, отићи ћу до нашег доброг пријатеља из ИДЕРА и чути о том алату и како се бави тим стварима.
Рон Хуизенга: Пуно вам хвала и хвала и Робину и Дезу што су заиста добро поставили бину, а ви ћете видети мало преклапање у неколико ствари о којима сам разговарао. Али они су заиста поставили врло чврст темељ за неке концепте о којима ћу говорити из перспективе моделирања података. И много тога што су рекли одјекује из мог искуства кад сам био консултант који се бавио моделирањем података и архитектуром података, заједно са тимовима - и водопад у раним данима и еволуирајући у модерније производе са пројектима где смо користили окретност методологије за испоруку решења.
Дакле, оно о чему ћу данас говорити темељи се на тим искуствима, као и на погледу алата и неких могућности у алатима које користимо да нам помогну на том путу. Оно што ћу описати врло кратко је да нећу улазити у детаље много детаља; управо смо имали заиста добар преглед онога што је то. Разговараћу о томе у смислу шта је модел података и шта нам то заиста значи? И како у нашим организацијама омогућити концепт агилног моделера података, у смислу, како ангажовати моделере података, какво је учешће моделара и архитеката током година, које су врсте активности којима би се требали бавити. , и, као позадина тога, које су неке од важних могућности алата за моделирање које користимо да заиста помогну да тај посао олакшамо? Онда ћу се упустити у заокруживање и само мало поразговарати о неким пословним вредностима и предностима укључивања моделера података, или о начину на који ћу заправо испричати причу, проблеми са недовољним ангажовањем моделара за податке у пројектима и показаћу вам то на основу искуства и графике недостатака пре и после слике стварног пројекта са којим сам учествовао пре много година. Затим ћемо сажети још неколико тачака, а затим ћемо имати питања и одговоре уз то.
Укратко, ЕР Студио је веома моћан пакет који садржи пуно различитих компоненти. Архитекта података, где моделирачи података и архитекти проводе већину свог времена радећи на моделирању података. Постоје и друге компоненте о којима данас уопште нећемо разговарати, попут Бусинесс Арцхитецт-а, где радимо моделирање процеса и Софтваре Арцхитецт, за неке од УМЛ моделирања. Затим је ту Репозиториј, где се пријављујемо и делимо моделе и дозвољавамо тимовима да сарађују на њима и објављују их на тимском серверу тако да више заинтересованих публика које су ангажоване на пројекту заиста могу видети артефакте које смо „ креирамо из перспективе података као и остале ствари које радимо у самој реализацији пројекта.
Оно на шта ћу се данас фокусирати биће неколико ствари које ћемо видети из Архитекта података и зато што је заиста важно да имамо сарадњу са аспектима складишта који се заснивају на Репозиторијуму. Нарочито када почнемо да говоримо о концептима попут управљања променама који су неопходни, не само окретни развојни пројекти, већ и било каква врста развоја која иде напред.
Дакле, разговарајмо на тренутак о Агиле Моделеру података. Као што смо већ упозоравали на презентацију, неопходно је да имамо моделере података и / или архитекте који су потпуно укључени у процесе агилног развоја. Сада, оно што се историјски догодило, да, заиста смо размишљали о окретном из перспективе развоја, а постоје пар ствари које су настале због тога су заиста и довеле до тога. Део је због природе природе начина на који се сам развој одвијао. Како је започео агилни развој и започели смо с тим концептом самоорганизацијских тимова, ако сте попили Коол-Аид мало превише чисто и били сте на екстремној програмској страни ствари, постојала је врло дословна интерпретација ствари попут тимови који се самоорганизују, што многи људи тумаче тако, све што нам треба је група програмера која може да изгради целокупно решење. Било да то значи развијање кода, базе података или базе података иза њега и све је пребачено програмерима. Али оно што се догоди с тим јесте да изгубите на посебним способностима које људи имају. Открио сам да су најјачи тимови они који су састављени од људи различитог порекла. Као што је комбинација снажних програмера софтвера, архитеката података, моделара података, пословних аналитичара и пословних заинтересованих страна, који сви заједно сарађују како би постигли крајње решење.
Оно о чему данас такође говорим јесте да ћу то учинити у оквиру развојног пројекта где развијамо апликацију којој ће очигледно такође бити придружена и компонента података. Морамо направити корак уназад прије него што то учинимо, јер морамо схватити да је вани мало развојних пројеката на Греенфиелд-у гдје смо потпуно фокусирани на стварање и потрошњу података који су ограничени само у оквиру самог тог развојног пројекта. . Морамо направити корак уназад и сагледати целокупно организационо гледиште из перспективе података и процесне перспективе. Јер оно што смо сазнали су информације које користимо можда већ постоје негде у организацијама. Као моделатори и архитекти то објављујемо како бисмо знали одакле да прикупљамо те информације из самих пројеката. Такође знамо структуре података које су укључене јер имамо моделе дизајна баш као што програмери имају моделе дизајна за свој код. И ми такође морамо да узмемо ту укупну организациону перспективу. Не можемо само да гледамо податке у кон апликацији коју правимо. Морамо да моделирамо податке и будемо сигурни да их документујемо јер живе дуго изван самих апликација. Те апликације долазе и одлазе, али морамо бити у могућности да погледамо податке и будемо сигурни да су робусни и добро структуирани, не само за апликацију, већ и за одлуке које пријављују активности, БИ извештавање и интеграцију у друге апликације, интерне и такође за наше организације. Зато морамо сагледати целу велику слику података и шта је животни циклус тих података и разумети путовање информација у целој организацији од колијевке до гроба.
Вратимо се стварним тимовима и како заправо треба да радимо, методологија водопада је схваћена као преспора за постизање резултата. Јер, као што је истакнуто примером тенка, био је корак за другим и често је трајало предуго да би се постигли изводљиви крајњи резултати. Оно што сада радимо је да морамо имати итеративни стил рада у којем поступно развијамо његове компоненте и разрађујемо га кроз време где израђујемо употребљив код или употребљиве артефакте, рећи ћу за сваки тренутак. Важна ствар је сарадња између техничких заинтересованих страна у тиму и пословних заинтересованих страна, јер ми сарађујемо како бисмо извукли те корисничке приче у видљиву визију кода и података који подржавају тај код. И сам Агиле Дата Моделер често ће утврдити да немамо довољно моделара у организацијама, тако да један моделар података или архитекта истовремено могу подржати више тимова.
А други аспект тога је, чак и ако имамо више моделара, морамо осигурати да имамо сет алата који користимо који омогућава сарадњу са више пројеката који су у лету истовремено и дељење тих артефакти података и могућности пријављивања и одјаве. Пребрисаћу ово врло брзо, јер смо то већ покрили у претходном одељку. Права премиса агилности је да ствари заснивате на заостатку, причама или захтевима. У оквиру понављања сарађујемо као група. Обично су двонедељни или једномесечни с, у зависности од организације, веома чести. Такође свакодневно прегледавајте и постављајте редовне састанке тако да елиминишемо блокаде и осигуравамо да померимо све аспекте напријед без заустављања у различитим областима док пролазимо. И у тим словима желимо да будемо сигурни да производимо корисне испоруке као део сваке секунде.
Само мало другачије схваћам то, проширујући га даље, сцрум је методологија о којој ћу овде конкретније говорити и управо смо претходну слику увећали са још неколико аспеката. Обично постоји заостатак за производ, а затим и заостатак за производом. Дакле, имамо свеукупни заостатак који се на почетку сваког поновног понављања кажњавамо: „Шта ћемо ово правити?“ И то је учињено на састанку планирања. Затим раздвајамо задатке који су повезани са тим и извршавамо их у тим једнонедељним прегледима са тим дневним прегледима. Док радимо то, пратимо свој напредак кроз сагоревање и прегореће карте да бисмо у основи пратили шта је све потребно за изградњу у односу на оно што градимо да бисмо успоставили ствари као што је наша брзина развоја, хоћемо ли направити наш распоред, све те врсте ствари. Сви они се разрађују континуирано током времена, а не да идете неколико месеци низ пут и сазнате да ћете ускоро изаћи на крај и требате продужити распоред пројекта. И врло је важно, као део тога, читави тимови, постоји преглед на крају и као ретроспектива, тако да пре него што започнете следећу итерацију, прегледавате шта сте урадили и тражите начине на које бисте могли да побољшате следећи пут.
Што се тиче резултата, ово је у основи слајд који сажима типичне врсте ствари које се дешавају у сс. И то је веома усмерено на развој, тако да много ствари које овде видимо, попут функционалних дизајна и случајева, радећи тестове дизајнерског кода, када погледамо ове кутије овде, и нећу да их пролазим у било којем нивоу детаља, врло су развојно оријентисани. И испод овога је покопана чињеница да такође морамо имати оне податке који нам иду на руку да бисмо подржали овај напор. Дакле, сваки пут када видимо ствари као што су заостаци, захтеви и корисничке приче, док пролазимо треба да погледамо који су развојни делови које морамо да урадимо, који су делови анализе које треба да урадимо, како са Дизајн података или модел података, шта је са стварима попут пословних појмовника како бисмо пословно значење могли повезати са свим артефактима које производимо? Зато што морамо да произведемо ове употребљиве резултате у свакој секунди.
Неки људи ће рећи да на крају сваког с морамо произвести корисни код. То није нужно случај, то је у најчистијој перспективи развоја, али прилично често - посебно на почетку - можемо имати нешто попут нуле на којој смо фокусирани чисто на стојеће ствари, радећи ствари попут увођења наших тестних стратегија у место.Дизајн на високом нивоу да бисмо га започели пре него што почнемо да испуњавамо детаље и будемо сигурни да имамо чист низ почетних прича или захтева пре него што започнемо ангажовање друге публике, а затим као тим идемо даље. Увек постоји мало времена за припремање, тако да ћемо често имати н, па чак и нулу и један. Може бити мало фаза покретања пре него што погодимо потпуно летење у пружању решења.
Хајде да о овом моделу података разговарамо укратко. Кад људи размишљају о моделима података, они често сматрају да је модел података слика слике повезивања различитих информација - то је само врх леденог бријега. Да бисте у потпуности утјеловио дух како заиста желите да приступите моделирању података - било да је у агилном развоју и другим стварима - да ли је потребно да схватите да ће модел података, ако се правилно изврши, постати ваша пуна спецификација шта ти подаци значе у организацији и како је распоређен у позадинским базама података. Када кажем базе података, мислим не само на релацијске базе података које можда користимо, већ на данашње архитектуре у којима имамо велике податке или НоСКЛ платформе, како их радије називам. Такође и оне велике продавнице података јер можда комбинирамо мноштво различитих складишта података у смислу потрошње информација и њиховог уношења у наша решења, као и начина на који упорно чувамо или чувамо те податке из наших решења.
Можда у оквиру одређене апликације истовремено радимо са више база података или извора података. Оно што је веома важно јесте да желимо да имамо потпуну спецификацију, па логична спецификација шта то значи као организациона перспектива, шта су физички конструкти у смислу како ми заправо дефинишемо податке, односе између њих у вашем базе података, ваша референтна ограничења интегритета, провјерите ограничења, све оне дијелове провјере ваљаности о којима обично размишљате. Описни метаподаци су изузетно важни. Како знате како користити податке у својим апликацијама? Ако га не можете дефинисати и знати шта значи или знати одакле су дошли да бисте били сигурни да трошите исправне податке у тим апликацијама - осигурајте да имамо исправне конвенције о именовању, пуне дефиниције, што значи и пун речник података за не само табеле, али ступци који садрже те табеле - и детаљне напомене о размештању о томе како то користимо, јер морамо да изградимо ову базу знања, јер чак и када се уради ова апликација, ове информације ће се користити за друге иницијативе, тако да морамо бити сигурни да имамо све то документовано за будуће имплементације.
Опет се сводимо на ствари као што су типови података, кључеви, индекси, сам модел података утјеловљује многа пословна правила која се примјењују. Односи нису само ограничења између различитих таблица; често нам помажу да опишемо која су права пословна правила око тога како се ти подаци понашају и како функционишу заједно као кохезивна јединица. И наравно, вредностна ограничења су врло важна. Наравно, једна од ствари са којом се стално бавимо, и која постаје све присутнија, јесу ствари попут управљања подацима. Дакле, из перспективе управљања подацима, такође морамо гледати, шта овде дефинишемо? Желимо да дефинишемо ствари попут безбедносних класификација. Којим врстама података имамо посла? Шта ће се сматрати главним управљањем подацима? Које трансакцијске продавнице стварамо? Које референтне податке користимо у овим апликацијама? Морамо да се уверимо да ли је правилно ухваћено у наше моделе. А такође, разматрање квалитета података, постоје одређени подаци који су важнији за организацију од осталих.
Укључио сам се у пројекте у којима смо преко десетина наслеђених система замењивали новим пословним процесима и дизајнирали нове апликације и складишта података који би их заменили. Морали смо знати одакле информације долазе. Што се тиче најважнијих информација, из пословне перспективе, ако погледате овај слајд модела података који сам добио овде, видећете да су доњи оквири у тим одређеним ентитетима, што је само мали подскуп, У ствари смо успели да ухватимо пословну вредност. Било да су високе, средње или ниске за ове врсте ствари за ове различите конструкције у организацији. Такође сам снимио ствари попут мастер класа података, да ли су то мастер табеле, да ли су референтне, ако су биле трансакционе. На тај начин можемо проширити своје метаподате у нашим моделима и дати нам пуно других карактеристика изван самих података, што нам је заиста помогло у другим иницијативама изван оригиналних пројеката и преношењу у њих. Сада је то било пуно у једном клизачу, проћи ћу кроз њих прилично брзо.
Сада ћу врло брзо разговарати о томе шта ради моделар података док пролазимо кроз ове различите сс. Пре свега, пуноправни учесник у сесијама планирања, где водимо корисничке приче, обавезујући се на оно што ћемо у том смислу испоручити и смишљамо како ћемо га структурирати и доставити. Оно што такође радим као моделар података је да знам да ћу радити у одвојеним областима са различитим програмерима или са различитим људима. Дакле, једна од важних карактеристика коју можемо имати је када радимо модел података, тај модел података можемо поделити на различите погледе, без обзира да ли их називате предметним областима или под-моделима, наша је терминологија. Као што градимо модел, приказујемо га и у тим различитим перспективама под-модела, тако да различита публика види само оно што је за њих важно како би се могли концентрисати на оно што развијају и развијају. Тако да можда имам некога ко ради на заказивању дела апликације, можда бих неко други радио на уносу налога где радимо све ове ствари у једном моменту, али могу да им дам ставове кроз оне под-моделе који само односе се на подручје на којем раде. А онда се ти делови своде на целокупни модел и целокупну структуру под-модела како би различити гледаоци могли да виде оно што требају да виде.
Основе из перспективе моделирања података које желимо имати су увијек основа која се можемо вратити јер једна од ствари коју требамо моћи учинити је да ли је на крају или на крају или неколико сс, желимо знати одакле смо започели и увијек имамо основну линију да знамо која је била делта или разлика онога што смо произвели у датом с. Такође морамо да осигурамо да можемо брзо да преокренемо. Ако у њу уђете као модератор података, али у традиционалној улози вратара да кажете "Не, не, не можете то да урадимо, прво морамо да урадимо све ове ствари", бићете искључени из тима када вам стварно требају бити активан учесник у свим тим окретним развојним тимовима. То значи да неке ствари падају с вагона радећи одређени с, а ви их покупите у каснијим сс.
Као пример, можете се усредсредити на структуре података само да би се ишло у развој, рецимо, оног дела за унос налога о коме сам говорио. У каснијим с документима можете се вратити и испунити податке попут неке документације за речник података око неких артефаката које сте створили. Нећете довршити ту дефиницију све у једном трену; наставит ћете постепено ићи на своје резултате јер ће постојати времена да те информације попуњавате радећи с пословним аналитичарима када су програмери заузети стварањем апликација и упорношћу око тих спремишта података. Желите да олакшате, а не да будете уско грло. Постоје различити начини на које сарађујемо са програмерима. За неке ствари имамо обрасце дизајна, тако да смо предњи део пуноправни учесници, тако да ћемо можда имати образац дизајна где ћемо рећи да ћемо га убацити у модел, избацићемо га у базе података програмера, а затим они могу започните да радите с тим и затражите измене у томе.
Можда постоје друге области на којима програмери раде, имају нешто на чему раде и прототипирају неке ствари тако да неке ствари испробавају у сопственом развојном окружењу. Узимамо ту базу података с којом су радили, уносимо је у наш алат за моделирање, упоређујемо с моделима које имамо, а затим их разрешимо и потискујемо промене натраг како би могли поново да деконструишу своје кодове тако да следе одговарајуће структуре података која нам је потребна. Зато што су можда створили неке ствари које смо већ имали негде другде, па се побринемо да раде са правим изворима података. Само настављамо понављати све до овога, тако да ћемо добити све податке о подацима, потпуну документацију и дефиницију свих тих структура података које стварамо.
Најуспешнији агилни пројекти са којима сам учествовао у погледу веома добрих испорука су у томе, имали смо филозофију, моделирали све промене у целој спецификацији физичке базе података. У суштини, модел података постаје распоређене базе података с којима радите за све ново што стварамо и има пуне референце о осталим спремиштима података ако их конзумирамо из других вањских база података. Као део тога стварамо инкременталне скрипте насупрот томе да сваки пут радимо пуну генерацију. И ми користимо своје обрасце дизајна да нам омогуће тако брзо побољшање у смислу да ствари идемо у сусрет са различитим развојним тимовима са којима радимо.
И у с активностима је опет та основна вриједност за упоређивање / спајање, па узмимо идеју о моделирању сваке промјене. Сваки пут када извршимо промену, оно што желимо је да моделирамо промене и оно што је веома важно, оно што је недостајало у моделирању података донедавно, заправо док је нисмо поново увели, јесте могућност повезивања моделирања задатака и ваших резултата са корисничким причама и задацима који заправо узрокују те промене. Желимо да можемо да проверимо промене у нашем моделу, на исти начин као што програмери провере у својим кодовима, референцирајући оне корисничке приче које имамо, тако да знамо зашто смо увели промене, то је нешто што радимо. Када то учинимо, генерирамо наше инкременталне ДДЛ скрипте и објављујемо их тако да се могу одабрати са осталим развојним резултатима и проверити у нашем састављању решења. Опет, можда имамо један модел или радимо са више тимова. И као што сам већ причао, неке ствари потичу од моделара података, друге ствари су створили програмери, а ми се срећемо у средини да смислимо најбољи најбољи дизајн и гурнемо га напријед и побринемо се да је правилно дизајниран у нашем укупне структуре података. Морамо одржати дисциплину осигуравања да имамо све одговарајуће конструкције у нашем моделу података док кренемо напријед, укључујући ствари попут нулту, а не нулту вредност, референтна ограничења, у основи провера ограничења, све оне ствари о којима обично размишљамо .
Сада ћемо разговарати о само неколико снимака екрана неких алата који нам помажу у томе. Оно што мислим да је важно јесте да имамо то заједничко спремиште, тако да оно што можемо урадити као моделирачи података - а ово је исјечак дела модела података у позадини - је када радимо на стварима за које желимо да будемо сигурни да можемо радимо само на објектима које требамо да можемо да мењамо, уносимо модификације, генеришемо наше ДДЛ скрипте за промене које смо извршили док ствари поново вршимо у обзир. Дакле, оно што можемо да урадимо је да у ЕР Студио-у буде пример, можемо да проверимо предмете или групе објеката на којима радимо, не морамо да проверимо цео модел или под-модел, можемо да проверимо само оне ствари које нас занимају. Оно што желимо након тога је или одјава или пријава - то радимо на оба начина јер различити развојни тимови раде на различите начине. Желимо да то повежемо са корисничком причом или задатком који покреће захтеве за то и да ће то бити иста корисничка прича или задатак који програмери развијају и проверавају свој код.
Дакле, овде је врло брз исечак неколико екрана једног од наших центара за управљање променама. Ово се догађа, нећу овде детаљно да објашњавам, али оно што ви видите је корисничка прича или задатак и одрезано испод сваког од оних код којих видите стварне записе о променама - направили смо аутоматизовани запис о променама када вршимо пријаву и одјаву и можемо додати више описа и на тај запис о променама. Повезана је са задатком, можемо имати више промена по задатку, као што бисте очекивали. А кад уђемо у записник о променама, можемо да га погледамо и што је још важније да видимо шта смо у ствари променили? За ову посебну, истакнуту причу тамо сам имао једну врсту промене која је извршена и када сам погледао стварни запис о промени, идентификовао је појединачне делове у моделу који се променио. Овде сам променио неколико атрибута, поново их одредио и то је за вожњу донело погледе које је требало променити, а који су зависили и од њих, тако да ће они бити генерисани у инкременталном ДЛЛ-у. То није само моделирање на основним објектима, већ и моћни алат за моделирање попут овог такође открива промене које морају бити искрцане кроз зависне објекте у бази података или моделу података.
Ако радимо са програмерима, а то радимо у неколико различитих ствари, ради нешто у њиховом песку и желимо да упоредимо и видимо где су разлике, користимо могућности упоређивања / спајања тамо где су са десне и леве стране страна. Можемо рећи, „Ево нашег модела на левој страни, овде је њихова база података на десној страни, покажите ми разлике.“ Затим можемо одабрати и изабрати на који начин решимо те разлике, било да угурамо ствари у базу података или ако постоје неке ствари које се налазе у бази података које враћамо у модел. Можемо ићи двосмерно, тако да можемо ићи у оба смера истовремено ажурирањем и извора и циља, а затим произвести инкременталне ДДЛ скрипте за распоређивање тих промена у самом окружењу базе података, што је изузетно важно. Оно што такође можемо да учинимо је да можемо да искористимо ову могућност упоређивања и спајања у било ком тренутку, ако радимо снимке на путу, увек можемо упоредити почетак једног с почетка или крај другог, тако да можемо видети потпуна инкрементална промена онога што је урађено у датом развоју или преко низа сс.
Ово је врло брз пример алтер скрипте, било ко од вас који ради са базама података ће видети ову врсту ствари, то је оно што можемо избацити из кода као алтер скрипту тако да будемо сигурни да задржите ствари овде. Оно што сам извукао одавде, само да бисмо смањили неред, је оно што радимо и са овим алтер скриптама, претпостављамо да постоје и подаци у тим табелама, па ћемо такође генерисати ДМЛ који ће извући информације о привременим таблицама и вратимо га поново у нове структуре података, тако да гледамо не само структуре, већ и податке које можда већ имамо у тим структурама.
Врло брзо ћемо разговарати о системима аутоматизоване градње јер када радимо агилни пројекат прилично често радимо са системима аутоматизованог састављања где морамо заједно да проверимо различите резултате како бисмо били сигурни да нећемо разбити свој посао. Што то значи је да синхронизујемо резултате, оне скрипте за промену о којима сам говорио са ДДЛ скрипту треба да се провере, да одговарајући апликативни код треба истовремено да се пријави, а пуно развоја програмера сада, наравно, није. се изводи са директним СКЛ-ом против база података и такве врсте ствари. Често користимо оквире упорности или градимо услуге података. Морамо да будемо сигурни да се промене тих оквира или услуга пријављују у исто време. Улазе у аутоматизовани систем састављања у неким организацијама и ако се конструкција поквари, по агилној методологији, све је ствар на поправљању палубе која се гради пре него што кренемо напријед, тако да знамо да имамо радно решење пре него што идемо даље. И један од пројеката у којима сам био укључен, то смо довели до крајности - ако се састав покварио, заправо смо прикључили на одређени број рачунара у нашем крају где смо били смештени са пословним корисницима, имали смо црвене трепереће лампице само попут врха полицијских аутомобила. А ако се конструкција покварила, она црвена треперећа светла почела су да се гасе и знали смо да је све на палуби: поправите склоп и наставите са оним што радимо.
Желим да причам о другим стварима, а ово је јединствена способност ЕР Студија, заиста помаже када покушавамо да направимо те артефакте као програмере за ове границе упорности, имамо концепт који се назива објектима пословних података и шта нам то омогућава Довољно је да ако посматрате овај врло поједностављени модел података као пример, омогућава нам да објединимо ентитете или групе ентитета где су границе постојаности. Тамо где ми као моделар података можемо да замислимо нешто попут заглавља налога за куповину и поравнања налога и других детаљних табела које би се уклопиле у начин на који га градимо и наши програмери података за податке морају да знају како ствари и даље постоје до тих различитих података структуре. Наши програмери размишљају о стварима попут налога за куповину као уопште о предмету и какав је њихов уговор са начином на који стварају те одређене објекте. Можемо изложити тај технички детаљ тако да људи који граде сервере података могу да виде шта се налази испод њега, а ми можемо да заштитимо другу публику од сложености, тако да само виде различите објекте вишег нивоа, што такође врло добро функционира за комуникацију са бизнисом аналитичари и пословни актери када говоримо о интеракцији различитих пословних концепата.
Лепа ствар у томе је и то што их конструктивно проширујемо и урушавамо тако да можемо одржавати односе између објеката вишег реда иако потичу од конструкција које су садржане у самим тим пословним подацима. Сада као манекенка, дођите до краја, на крају завршетака, имам пуно ствари које морам да урадим, а које следеће време називам својим домаћинством. Свако с којим креирам оно што зовем Намед Релеасе - то ми даје основну основу за оно што сада имам на крају издања. Дакле, то значи да је моја почетна линија напред, све ове основне линије или Намед Релеасе које креирам и спремим у своје складиште које могу да упоредим / спајам тако да увек могу да се упоредим са било којим датим крајем с било којег другог, што врло је важно знати које су ваше промене у моделу података на путу током његовог путовања.
Такође креирам делта ДДЛ скрипту користећи поново поређење / спајање од почетка до краја с. Можда сам проверио читаву гомилу инкременталних скрипти, али ако ми је потребна сада имам скрипту коју могу да применим да устанем на другим песковним сандучићима, па могу само да кажем да смо то имали на почетку једног, притисните кроз то, изградимо базу података као кутију за песак како бисмо започели са следећим с, а ми такође можемо да их искористимо да радимо ствари попут стандуп КА инстанци и на крају, наравно да желимо да своје промене избацимо из производње тако да имамо више ствари истовремено. Опет, у потпуности учествујемо у планирању и ретроспективама, ретроспективе су заиста научене лекције и то је изузетно важно, јер можете брзо да кренете током агилности, морате зауставити и прославити успехе, као и сада. Откријте шта није у реду, сљедећи пут вам буде боље, али такође прославите ствари које су кренуле како треба и надоградите се док наставите даље у наредним словима.
Сада ћу врло брзо разговарати о пословној вредности. Постојао је пројекат у који сам се укључио пре много година, а који је започео као агилни пројекат, и био је то екстремни пројекат, тако да је то био чисти самоорганизациони тим у коме су управо програмери радили све. Да скратим, овај пројекат је застао и открили су да све више и више времена троше на санирање и исправљање утврђених недостатака него што су наговарали више функционалности и, заправо, када су га гледали на основу на спалионим картама они су морали да продуже шест месеци уз велику цену. А кад смо га погледали, начин да се санира проблем био је коришћење одговарајућег алата за моделирање података са квалификованим моделом података који је укључен у сам пројекат.
Ако погледате ову вертикалну траку на овом одређеном графикону, то показује кумулативне недостатке насупрот кумулативним објектима, а ја говорим о објектима података или конструкцијама које су створене, попут табела са ограничењима и оних врста ствари, ако бисте погледали прије увођења модера података, број оштећења је заправо премашио и почео стварати јаз између стварног броја објеката који су произведени до тог тренутка. Након 21. недеље, тада је моделар података ушао у контакт са моделом података на основу онога што је требало да поправи низ ствари, а затим је почео да се моделира као део пројектног тима који напредује, промене које су тај пројекат гурале напред . И видели сте врло брзи заокрет да смо у року од отприлике и по дана видели огроман напредак у броју објеката и конструкција података који се генеришу и граде јер смо генерисали из алата за моделирање података, а не зграде за развојне палице њих у окружењу, и били су тачни јер су имали одговарајући референтни интегритет и остале конструкте које је требао имати. Степен недостатака на тим готово равним линијама. Подузимајући ту одговарајућу акцију и осигуравајући да је моделирање података у потпуности ангажовано, пројекат је достављен на време са много вишим нивоом квалитета, а у ствари уопште не би био испоручен да се ти кораци не би извели. Пуно је окретних неуспеха, има и доста окретних успеха ако бисте у своје улоге укључили праве људе. Ја сам велики заговорник агилности као оперативне дисциплине, али морате да будете сигурни да имате вештине свих правих група које су укључене у пројектне тимове док напредујете на агилном подухвату.
Укратко, архитекти података и модели који морају бити укључени у све развојне пројекте; они су заиста лепак који држи све заједно јер као моделери података и архитекти разумемо, не само конструкције података датог развојног пројекта, већ и где подаци постоје у организацији и одакле ми можемо да набављамо те податке и како их користиће се и користи изван одређене апликације на којој радимо. Разумијемо сложене односе података и најважније је бити у могућности да се кренемо напријед, а такође и из перспективе управљања како бисмо пресликали документ и схватили како изгледа ваш комплетан пејзаж података.
То је попут производње; Долазим из производње. На крају не можете да уверите квалитет у нешто - морате да уградите квалитет у свој дизајн унапред и на путу, а моделирање података је начин да се тај квалитет угради у дизајн на ефикасан и економичан начин све до краја . И опет, нешто за памћење - и то не треба бити безобразно, али истина је - апликације долазе и одлазе, подаци су витално корпоративно добро и прелазе све оне границе апликације. Сваки пут када постављате апликацију, вероватно се од вас тражи да сачувате податке из осталих апликација које су раније стигле, тако да само морамо запамтити да је то витално корпоративно средство које стално задржавамо.
И то је то! Одавде ћемо преузети више питања.
Ериц Каванагх: Добро, допусти да прво то пребацим Робину. А онда, Дез, сигуран сам да имаш пар питања. Однеси то, Робин.
Др Робин Блоор: У реду. Да будем искрен, никада нисам имао проблема са окретним методама развоја и чини ми се да ово што овде радите има еминентног смисла. Сећам се да сам гледао нешто из 1980-их што је, заиста, указивало на то да је проблем са којим се у ствари сусрећете у погледу пројекта који постаје изван контроле, обично ако допустите да грешка потраје и изван одређене фазе. Једноставно је све теже поправити ако ту фазу не уредите добро, тако да је једна од ствари која радите овде - и мислим да је то клизач - али једна од ствари које радите овде По мом мишљењу, нула је, по мом мишљењу, апсолутно важна, јер ви стварно покушавате да тамо прикачите резултате. А ако не желите да прикажете испоруке, тада производи мењају облик.
То је, некако, моје мишљење. То је такође моје мишљење - заиста немам аргументацију са идејом да морате да направите тачно моделирање података до одређеног нивоа детаља пре него што прођете. Оно што бих волео да покушате и урадите зато што нисам добио потпун осећај за то је само описати један од ових пројеката у смислу његове величине, у смислу како је текао, у смислу ког, знате где су проблеми искрсли, да ли су решени? Јер мислим да је овај слајд у основи његово срце и ако бисте могли мало више разрадити о томе, био бих вам захвалан.
Рон Хуизенга: Наравно, и користићу се неколико примера пројеката. Она која је, некако, сишла са трачница која је била враћена тако што смо заправо укључивали праве људе и радили моделирање података, и све је заиста био начин да се осигура да је дизајн боље разумљив и да очигледно имамо бољи дизајн имплементације на путу кроз његово моделирање. Јер кад га моделирате, знате, можете да генеришете свој ДДЛ и све из позадине и из алата, а не да морате да га правите, као што то обично раде људи идући директно у окружење базе података. А типичне ствари које ће се десити са програмерима јесу да ће они тамо ући и они ће рећи, у реду, требају ми ове таблице. Рецимо да радимо уносе налога. Тако би они могли креирати заглавље налога и табеле детаља о наруџбини и такве врсте ствари. Али они ће често заборавити или запоставити да би се уверили да постоје ограничења која представљају стране кључне односе. Можда нису исправни кључеви. Конвенције о именовању могу такође бити сумњиве. На пример, не знам колико пута сам упао у окружење, где видите гомилу различитих табела са различитим именима, али тада су називи ступаца у тим табелама попут ИД-а, имена или било чега другог, па Заиста сам изгубио превару без табеле тачно оног што је.
Дакле, обично када моделирамо податке, постараћемо се да применимо одговарајуће конвенције о именовању на све артефакте који се такође генеришу у ДДЛ-у. Али да будем прецизнији о природи самих пројеката је, генерално гледано, говорим о прилично великим иницијативама. Један од њих био је пројекат трансформације пословања у износу од 150 милиона долара где смо заменили преко десетак заостављених система. Имали смо пет различитих агилних екипа истовремено. Имао сам комплетан тим за архитектуру података, тако да сам моделе података из свог тима уграђивао у сваки други тим тимова апликације, а ми смо радили са комбинацијом интерних пословних стручњака који су знали тему, који су радили корисничке приче за саме захтеве. Имали смо пословне аналитичаре у сваком од тих тимова који су заправо моделирали пословни процес, са дијаграмима активности или дијаграмима пословних процеса, помажући у сношењу корисничких прича више са корисницима, пре него што их је појео и остатак тима.
И онда, наравно, програмери који су преко тога градили апликацијски код. И ми смо такође радили, мислим да су четири различита произвођача системске интеграције која су градила различите делове апликације, такође где је један тим градио дата сервисе, други је градио логику апликација у једној области, други је имао стручност у другом је пословном подручју изградња логике апликације у тој области. Тако да смо имали читаву сарадњу људи који су радили на овом пројекту. На том једном, у тиму смо имали 150 људи на обали и још 150 ресурса на мору у тиму који су сарађивали у трајању од две недеље како би испратили ову ствар. А да бисте то учинили, морате бити сигурни да пуцате на све цилиндре, и сви су добро синхронизовани у погледу испорука, а имали сте и те честе ресетовања да бисте били сигурни да смо довршили испоруку свих потребних артефаката на крају сваке с.
Др Робин Блоор: Па то је импресивно. И само мало више детаља о томе - да ли сте на крају тог пројекта завршили с комплетном, како бих назвао, МДМ мапом читавог подручја података?
Рон Хуизенга: Имали смо комплетан модел података који је разбијен декомпозицијом међу свим различитим пословним областима. Сам рјечник података у смислу пуних дефиниција мало је прекрао. Имали смо већину табела; имали смо већину стубова дефинисаних тачно шта они значе. Било их је неких и, што је занимљиво, пуно је било информација које су долазиле из наслеђених система где је, по завршетку самог пројекта, још увек документовано као преносни сет артефакти, како било, ван самог пројекта, јер је то нешто што је требало да подржи организација која иде напред. Тако да је истовремено организација заузела много веће становиште о важности управљања подацима, јер смо видели много недостатака у тим наслеђеним системима и оним изворним изворима података које смо покушавали да искористимо, јер нису документовани. У много случајева имали смо само базе података за које смо морали да извршимо обрнуто инжењерство и покушавамо да схватимо шта ту има и због чега информације.
Др Робин Блоор: Не изненађује ме, тај његов специфични аспект. Управљање подацима је, назовимо то, веома модерна брига и мислим да у ствари постоји много посла који би, рецимо, требало да се уради на историји управљања подацима. То никад није било зато што бисте се, некако, могли извући ако то не учините. Али како су ресурси података само расли и расли, на крају нисте могли.
У сваком случају, прећи ћу у Дез јер мислим да сам имао времена. Дез?
Дез Бланцхфиелд: Да, хвала. Кроз целу ову ствар гледам и размишљам о себи како говоримо о томе да видимо много окретног у љутњи. Иако то има негативне конотације; Мислио сам то на позитиван начин. Можете ли нам само дати сценарио, мислим, постоје два места за која видим да је ово савршен сет: једно су нови пројекти који једноставно треба да се раде од првог дана, али мислим да је, по мом искуству, често то често у случају да када пројекти постану довољно велики да је то потребно на више начина, постоји занимљив изазов између лепљења два света, зар не? Можете ли нам дати било какав увид у неке приче о успеху које сте видели где сте ушли у неку организацију, постало је јасно да су они имали мали сукоб два света и да сте успели да успешно поставите ово је на месту и спојити велике пројекте где би иначе могли да иду на шине? Знам да је то врло широко питање, али само ме занима да ли постоји одређена студија случаја коју можете, некако, указати на место где сте рекли, знате, ово смо све поставили на своје место и то је увео сав развојни тим заједно са тим за податке и ми смо се на неки начин позабавили нечим што би иначе могло потонути брод?
Рон Хуизенга: Свакако, и заправо један пројекат који се догодио као пројекат цевовода био је онај на који сам алудирао где сам показао тај графикон са недостацима пре и после укључивања модера података. Често постоје и унапред створени појмови, посебно ако се ствари покрећу тамо где је то направљено из чисто развојне перспективе, то су само програмери који су укључени у ове окретне пројекте за испоруку апликација. Дакле, оно што се тамо догодило, наравно је да су се сишли са шина и посебно својих артефаката података или су подаци који су произвели били испод ознаке у погледу квалитета и стварно бављења стварима у целини. И често постоји заблуда да ће модели дизајнера података успорити пројекте и они ће радити ако дата моделер нема прави став. Као што кажем, морате изгубити - понекад постоје моделирачи података који имају онај традиционални став вратара: „Овде смо да контролишемо како изгледају структуре података“, а тај менталитет мора нестати. Свако ко је укључен у агилни развој, а нарочито моделирачи података, морају преузети улогу модератора да би стварно помогли тимовима да напредују. А најбољи начин да се то илуструје је да се врло брзо покаже тимовима колико могу бити продуктивни, прво моделирајући измене. И опет, зато сам говорио о сарадњи.
Постоје неке ствари које можемо прво да моделирамо и генерирамо ДДЛ-у да бисмо га послали програмерима. Ми такође желимо да се уверимо да се не осећају као да су им ограничени. Дакле, ако постоје ствари на којима раде, пустите их да наставе да раде у својим развојним песковницима јер тамо програмери раде на својим радним површинама или другим базама података да би извршили неке промене на којима тестирају ствари. И сарађујте с њима и реците: „У реду, радите с тим.“ Унећемо га у алат, решићемо га, а затим ћемо га гурнути напријед и дати вам скрипте које можете да имплементирате да бисте ажурирали свој базе података да бисмо их надоградили до оног стварног санкционисаног стварног виђења производње о томе како ће бити, док настављамо даље. И то можете врло брзо преокренути. Открио сам да су ми се дани испунили тамо где сам се тек враћао и напредовао итератирајући са различитим развојним тимовима, гледајући промене, упоређујући, генерисујући скрипте, спроводећи их и успео сам да се лако одржавам са четири развојна тима прилично лако када једном постигао замах.
Дез Бланцхфиелд: Једна од ствари која ми пада на памет је да, знате, пуно разговора које водим свакодневно су око овог теретног воза који нам долази, некако, од машине до машине и машине ИоТ. И ако мислимо да сада имамо пуно података о нашем тренутном окружењу у предузећу, знате, ако одвојимо једнороге на тренутак, за које знамо да Гооглес и Уберс имају петабајт података, али у традиционалном предузећу говоримо о још стотинама терабајта и пуно података. Али, по мом мишљењу овај теретни воз долази у организације и др Робин Блоор је на то алудирао раније, од ИоТ-а. Знате, имамо пуно веб промета, имамо друштвени саобраћај, сада имамо мобилност и мобилне уређаје, облак је, некако, експлодирао, али сада имамо паметну инфраструктуру, паметне градове и ту је читав свет података који је управо експлодиран.
За свакодневну организацију, средњу до велику организацију која седи тамо и види како овај свет боли долази и нема непосредан план на уму, шта су неки од потеза, у само пар реченица, које бисте поставили за њих када и где треба да започну разговорно размишљање о постављању неких од ових методологија. Колико рано морају да почну да планирају да скоро седну и обрате пажњу и кажу да је право време да се нађу неки алати и да се тим обучи и да разговара са воцабом око овог изазова? Колико је касно у причи прекасно или када је прерано? Како то изгледа у неким организацијама које видите?
Рон Хуизенга: Рекао бих за већину организација да ако то већ нису учиниле и прилагодиле моделирање података и архитектуру података моћним алатима попут овог, време које су им потребне да то ураде је јуче. Зато што је занимљиво да чак и данас, када гледате податке у организацијама, имамо толико података у нашим организацијама и уопштено говорећи, на основу неких истраживања која смо видели, ефикасно користимо мање од пет процената тих података када погледамо преко организација. А с ИоТ или чак НоСКЛ-ом, великим подацима - чак и ако се не ради само о ИоТ-у, већ о великим подацима уопште - тамо где сада почињемо да користимо још више информација које потичу изван наших организација, тај изазов постаје све већи и већи све време. И једини начин на који имамо шансу да се боримо против тога јесте да нам помогнемо да схватимо о чему се ти подаци тичу.
Дакле, случај употребе је мало другачији. Оно што ми налазимо је да када погледамо те податке, снимамо их, морамо да их инжењеримо уназад, видимо шта је у њима, било да је то у нашим језерима података или чак у нашим интерним базама података, да синтетишемо шта подаци су, нанесите му значења и дефиниције да бисмо могли разумјети шта су подаци. Јер док не схватимо о чему се ради, не можемо осигурати да га исправно или адекватно користимо. Дакле, заиста морамо да схватимо шта су ти подаци.А други део тога је, немојте то радити јер можете, у погледу потрошње свих тих спољних података, да се уверите да имате случај употребе који подржава конзумирање тих спољних података. Усредсредите се на ствари које су вам потребне, а не на само покушавање да се повуку и искористе ствари које ће вам касније требати. Прво се усредсредите на важне ствари и док пролазите кроз њих, онда ћете доћи до конзумирања и покушавања да разумете остале информације споља.
Савршен пример за то је да знам да разговарамо о ИоТ-у и сензорима, али исти проблем је заправо био у многим организацијама већ дуги низ година, чак и пре ИоТ-а. Свако ко има систем контроле производње, било да је то компанија која се бави цевоводима, производњом, било којим компанијама које се баве процесима и које имају ствари у којима раде пуно аутоматизације са контролама и користе токове података и сличне ствари. ове скривене податке података које покушавају да пију како би схватили, који су догађаји који су се догодили у мојој производној опреми да сигнализирају - шта се догодило и када? А међу овим огромним низом података постоје само одређене информације или тагове који су заинтересовани да би их морали да пресеју, синтетишу, моделирају и разумеју. А они могу да игноришу остатак док не дође време да га заиста схвате, а затим могу проширити своје подручје да све више и више повуку у домет, ако то има смисла.
Дез Бланцхфиелд: Заиста. Постоји једно питање на које ћу ја поставити питање које је стигло од господина званог Ериц и приватно смо разговарали о томе. Само сам питао његово допуштење које је дао, да га питам од вас. Зато што то лепо води у ово, само да завршимо, јер сада помало идемо временом, а ја ћу се вратити Ерику. Али питање другог Ерица било је, да ли је разумно претпоставити да су власници стартупа упознати и разумеју јединствене изазове око моделирања терминологије и слично, или би је требало предати неком другом на тумачење? Другим речима, треба ли стартуп бити способан и спреман, вољан и способан да се фокусира и постигне ово? Или је то нешто што би вероватно требало да потраже у продавници и да приведу стручњаке?
Рон Хуизенга: Претпостављам да кратак одговор заиста зависи. Ако је то стартуп који нема некога ко је архитекта података или моделар који стварно разуме базу података, онда је најбржи начин за почетак довести некога са консултантском позадином која је врло добро упозната у овом простору и може добити они иду. Јер оно што ћете наћи - и у ствари, то сам учинио на многим ангажманима које сам радио пре него што сам дошао до мрачне стране у управљању производима - јесте да бих ишао у организације као консултант, водио њихове тимове за архитектуру података, како би се могли, на неки начин, преусмјерити на себе и оспособити своје људе како да раде ове врсте ствари тако да они то издрже и извршавају мисију напредујући. А онда бих наставио са својим наредним ангажманом, ако то има смисла. Много је људи који то раде и имају врло добро искуство у раду са подацима који их могу покренути.
Дез Бланцхфиелд: То је сјајна ствар преузимања и потпуно се слажем с тим и сигуран сам да би и др Робин Блоор. Посебно у стартупу, усредсређени сте на то да будете МСП на одређеној вредности понуде коју желите да изградите као део свог стартуп бизниса и вероватно вам не треба бити стручњак за све, тако да је сјајан савет. Али хвала пуно, фантастична презентација. Заиста сјајни одговори и питања. Ериц, предаћу ти се јер знам да смо вероватно прошли за десет минута и знам да волиш да се држиш близу наших временских прозора.
Ериц Каванагх: У реду је. Имамо бар пар добрих питања. Дозволите да вам пребацим један. Мислим да сте одговорили на неке друге. Али врло занимљиво запажање и питање једног полазника који пише, понекад окретни пројекти моделера података немају целу дугорочну слику па завршавају дизајнирање нечега у једном, а затим морају редизајнирати три или четири. Не изгледа ли то контрапродуктивно? Како можете избећи такве ствари?
Рон Хуизенга: То је само природа окретног што нећете добити све апсолутно како треба у датом тренутку. А то је заправо део окретног духа: радите с њим - направит ћете прототипирање тамо где радите шифру у датом с, а ви ћете је дорадити. И део тог процеса је док испоручујете ствари које крајњи корисник то види и каже, „Да, то је близу, али заиста морам то учинити и мало више.“ Тако да не утиче само на функционални дизајн самог кода, али врло често морамо модификовати или додавати више структуре података испод ових одређених ствари да бисмо испоручили оно што корисник жели. И то је све поштена игра и зато стварно желите да користите алате са великим погоном, јер врло брзо можете да моделирате и извршите ту промену у алату за моделирање, а затим да генеришете ДДЛ за базу података на којој програмери могу да раде са циљем да то испоруче промени се још брже. Спасавате их од тога да извршавају ручно кодирање података података и дозвољавају им да се концентришу на програмску или апликативну логику у којој су најискуснији.
Ериц Каванагх: То има потпуни смисао. Имали смо неколико других људи који су нам постављали само конкретна питања око тога како се све то везује за алат. Знам да сте провели неко време пролазећи кроз примере и показали сте неколико снимака екрана о томе како заправо извлачите неке од ових ствари. У односу на читав овај процес, колико често то видите у организацији у односу на то колико често видите традиционалније процесе у којима се ствари једноставно, на неки начин, крећу и одузимају више времена? Колико је из ваше перспективе распрострањен с-стиле приступ?
Рон Хуизенга: Мислим да то виђамо све више и више. Знам да бих, рекао бих, вероватно током последњих 15 година видео много више усвајања људи који признају да им заиста треба брже испоручивање. Тако сам видео све више и више организација како скачу по окретном појасу. Не нужно у потпуности; они могу започети с неколико пилот пројеката како би доказали да то функционира, али постоје неки који су још увијек врло традиционални и држе се методе водопада. Добра вест је, наравно, да алати делују врло добро и у тим организацијама, али и за оне врсте методологија, али ми имамо прилагодљивост у алату тако да они који скоче на брод имају алате у кутији алата на врховима прстију. Ствари попут поређења и спајања, ствари попут могућности обрнутог инжењеринга, тако да могу видети који су постојећи извори података, тако да заправо могу врло брзо да упореде и генеришу инкременталне ДДЛ скрипте. И како почињу да то прихватају и виде да могу имати продуктивност, њихова склоност прихватању окретности још више се повећава.
Ериц Каванагх: Па, то су сјајне ствари, народе. Управо сам објавио линк до слајдова тамо у прозору за ћаскање, па проверите то; то је мало помало ту за вас. Имамо све ове веб емисије за касније гледање. Слободно их поделите са пријатељима и колегама. И Рон, хвала вам пуно на вашем времену данас, увек сте пријатни на гостовању - прави стручњак за ту област и очигледно је да знате своје ствари. Дакле, хвала вама и хвала ИДЕРА и наравно Дезу и нашој Робин Блоор.
И с тим ћемо се опростити, људи. Хвала вам на вашем времену и пажњи. Ценимо да се стрпимо око 75 минута, то је прилично добар знак. Добри момци из емисије, разговараћемо са вама следећи пут. Ћао.