От персонала на Техопедия, 16 ноември 2016 г.
Отнемане: Домакинът Ерик Кавана обсъжда важността на моделирането на данни в пъргавото развитие с Робин Блор, Дез Бланчфийлд и Рон Хуйзенга на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, госпожи и господа. Добре дошли отново. Сряда е в 4:00 EST. Това означава, че е време за горещи технологии. Да, именно. Казвам се Ерик Кавана, ще ви бъда домакин.
За днешната тема това е старица, но хубавица. Всеки ден става все по-добър, защото оформя нашия свят за управление на данни, „Моделиране на данни в гъвкава среда.“ Има слайд за твоето наистина, удари ме в Twitter @eric_kavanagh. Наистина трябва да го поставим на този слайд. Ще трябва да се захвана с това.
Така че годината е гореща. Моделирането на данни съществува завинаги. Наистина е в основата и душата на бизнеса за управление на информация, проектира модели на данни, опитва се да разбере бизнес моделите и да ги приведе в съответствие с вашите модели данни. Това наистина се опитвате да направите, нали?
Моделът на данни представя бизнеса по фундаментален начин, така че как всички тези нови източници на данни променят играта? Ще разберем за това. Ще разберем как можете да останете на върха на нещата по пъргав начин. И разбира се, това е думата на годината.
Робин Блур е с нас, нашият главен анализатор, Дез Бланчфийлд, обаждащ се от Сидни, Австралия и Рон Хуйзенга, старши продуктов мениджър от IDERA - дългогодишен мой приятел, отличен оратор в това пространство, знае неговите неща, така че не се срамувайте, питайте му тежките въпроси, хора, тежките. С това ще направя Робин водещ и ще го отнема.
Д-р Робин Блур: Добре. Е, благодаря ти за това, Ерик. За моделирането трябва да кажа, че мисля, че всъщност бях в света на ИТ преди да съществува, в смисъл, че си спомням в застрахователната компания, за която работех, че имахме човек да влезе и да ни даде всички видове на семинар за това как да моделираме данни. Значи разглеждаме около 30 години, 30 години ли е? Може би дори по-дълго от това, може би преди 35 години. Дълго и дълго време моделирането всъщност е част от индустрията и разбира се няма нищо общо с дамите на модните подиуми.
Нещото, което исках да кажа, защото това, което обикновено правим, аз и Дез говорим за различни неща и просто мислех, че ще дам общия преглед на моделирането, но има реалност за това, това вече става очевидно.
Имаме, знаете, реалността с големи данни, имаме повече данни, повече източници на данни, имаме потоци от данни, които влязоха в уравнението през последните три или четири години и започва да получава по-голяма част от него, и има по-голяма нужда от разбиране на данните и увеличаване на скоростта на промяна, която се добавя повече данни и също така се използват повече структури от данни.
Това е труден свят. Ето една негова снимка, която всъщност е нещо, което нарисувахме преди около три години, но по принцип, след като включите поточно предаване в микса и получите тази идея за рафиниране на данни, център за данни, връзка за данни или каквото и да е друго, виждате, че има данни, които са истински в покой, в смисъл, че не се движи много. И тогава са налице данните, потоците и имате цялото приложение за транзакциите, както и в днешно време имате събития, потоци от данни за събития, които се случват в приложения и може да се наложи, и в наши дни с ламбда архитектурите, за които всички говорят, са истински оказва влияние върху само цялото поле от данни.
И в наши дни мислите, че има слой от данни. Слоят данни съществува по някакъв виртуален начин, в смисъл, че добро парче от него може да бъде в облака и да може да се разпространява в центрове за данни, може да съществува на работни станции. Слоят данни е до известна степен навсякъде и в този смисъл, навсякъде има процеси, които се опитват по един или друг начин да обработят данните и да преместват данните. Но също така да знаете какво е, когато го движите, е голяма работа.
Ако разгледаме моделирането на данни в най-общ смисъл, в дъното на този вид стек имате файлове и бази данни. Имате елементи от данни, които имат ключове, дефиниции на елементи, псевдоними, синоними, специфични физически формати и тогава имаме този слой метаданни.
Интересното при метаданните е, че метаданните са изцяло как данните придобиват своето значение. Ако всъщност нямате метаданни, тогава в най-добрия случай можете да гадаете значението на данните, но ще имате много трудности. Метаданните трябва да са там, но значението има структура. Не искам да навлизам във философията на смисъла, но дори и в начина, по който се справяме с данните, има много сложност в човешката мисъл и човешки език, което не се изразява лесно в данните. Но дори и по отношение на данните, които всъщност обработваме в света, метаданните имат значение и структурата на метаданните - една част от данни във връзка с друга и какво означава това, когато те са събрани и какво означава това, когато те отново се присъединява към други данни, изисква да го моделираме. Не е достатъчно да записвате само метаданни тагове към нещата, всъщност трябва да записвате смисъла на структурите и връзката между структурите.
Тогава имаме на най-горния слой дефинициите за бизнеса, което обикновено е слой, който се опитва да прехвърли смисъл между метаданни, което е форма на дефиниране на данни, която приспособява начина, по който се организират данните на компютъра и човешкия смисъл. Така че имате бизнес термини, дефиниции, взаимоотношения, концепции на ниво субект, които съществуват в този слой. И ако ще имаме несъответствие между тези слоеве, тогава трябва да имаме моделиране на данни. Всъщност не е задължително. Колкото повече всъщност можете да го направите по отношение на автоматизирането му, толкова по-добре. Но тъй като това е свързано със смисъл, наистина е трудно да се редуват. Достатъчно лесно е да хванете метаданните в даден запис и да можете да ги извлечете от поредица от значения, но не ви казва структурата на записите или какво означават записите или контекста на записа.
И така, според мен става въпрос за моделирането на данни. Основни моменти: колкото по-сложна става вселената на данните, толкова повече трябва да я моделирате. С други думи, това е малко като ние добавяме не само повече екземпляри от неща в света, което би съответствало на записи на данни, но всъщност добавяме повече смисъл към света, като улавяме данни за все повече неща. Става все по-сложно усещане, което трябва да разберем.
На теория има Вселена на данни и имаме нужда от оглед на нея. На практика действителните метаданни са част от Вселената на данните. Така че, това не е проста ситуация. Започващото моделиране е отгоре надолу и отдолу нагоре. Трябва да изградите в двете посоки и причината за това е, че данните имат значение за компютъра и процеса, които трябва да го обработват, но той има значение сам по себе си. Така че, имате нужда от смисъл отдолу нагоре, който удовлетворява софтуера, който се нуждае от достъп до данните и имате нужда от смисъл отгоре надолу, за да могат хората да го разберат. Изграждането на метаданни модели не е и никога не може да бъде проект; това е текуща дейност - трябва да бъде текуща дейност във всяка среда, в която съществува. За щастие има много среди, където това всъщност не е така и нещата съответно излизат извън контрол.
Продължавайки напред, моделирането се увеличава с важност с напредването на технологията. Това е моето мнение. Но ако погледнете IoT, ние можем да разберем мобилните повече, отколкото бяхме свикнали, въпреки че той въвежда нови измерения: измерението на местоположението с мобилния. След като стигнете до IoT, ние разглеждаме извънредни проблеми с данни, които всъщност никога не сме правили преди и трябва, по един или друг начин, да разберем правилно какво точно имаме, как точно да го съберем, какво можем да направим по отношение на получаването на смисъл от обобщаването и, разбира се, какво можем да направим с него, когато го обработим.
Мисля, че това съм казал достатъчно. Ще предам на Дез Бланчфийлд, който изцяло ще каже нещо друго.
Дез Бланчфийлд: Благодаря. Винаги трябва да се спазва труден акт, но това е тема, за която се съгласихме и говорихме за това накратко в лентата за предсказване и ако наберете по-рано, вероятно бихте хванали куп страхотни скъпоценни камъни. Едно от заведенията и не искам да открадна гръмотевицата на този конкретен, но едно от извлеченията от нашия предсказателен плакат, който искам да споделя, в случай че не сте го хванали, беше точно около темата на пътуването на данните и ми се стори, че всъщност го записвам, мислейки за пътуването, което данните предприемат в различен контекст около поколения живот - година, месеци, седмица, ден, час, минута, секунда - и контекста около данните са позициониран в този контекст. Независимо дали съм програмист, работещ с код, или дали съм специалист по данни и обмислям структурата и формата и метаданните около всеки от елементите или начина, по който системите и бизнесът взаимодействат с него.
Интересно малко занимание, само да отбележа, но така или иначе, позволете ми да се гмурна. По-специално, дизайнът на данни е фраза, която използвам, за да говоря за всички данни и конкретно за разработване на приложения или инфраструктура на база данни. Мисля, че дизайнът на данни е термин, който просто улавя всичко в съзнанието ми. В наши дни, когато говорим за дизайн на данни, говорим за съвременен гъвкав дизайн на данни и моето мнение е, че не толкова отдавна разработчиците и експертите по данни са работили самостоятелно; те бяха в собствените си силози и парчета дизайн преминаваха от един силоз в друг. Но аз съм много на мнението в наши дни, че не само случаят е променен, но и трябва да се промени; това е нещо като необходимост и това е, че приложението - разработчици и всичко, което трябва да се направи около разработката, която се занимава с данни, дизайнерите, които правят съответните дизайнерски елементи на схеми и полета и записи и системи и инфраструктури за локация и бази данни, моделиране и цялото управление предизвикателство около това. Това е отборен спорт сега и оттам идва моята снимка на куп хора, изскачащи от самолет, действащи като екип, които да играят този визуално интересен образ на хора, падащи в небето.
Трето, какво се случи, за да се случи това? Е, има една статия от 1986 г., написана от няколко господа, чиито имена отчаяно се опитах да направя правосъдие, Хиротака Такеучи и Икуджиро Нонака, мисля, че е произнесено, създадоха статия, която те озаглавиха „Преместване на Scrum Downfield.“ тази идея за методология за спечелване на игра в ръгби, тръгваща от тази дейност на скрам, при която всеки се движи на едно място и два отбора по същество заключват глави в нещо, наречено скрам, за да се опитат да получат контрол над топката и да я играят по терена стигнете до пробната линия и докоснете земята с топката и вземете точка, наречена тригон, и вие повтаряте този процес и получавате повече точки за отбора.
Тази статия е публикувана през 1986 г. в Harvard Business Review и любопитно всъщност получи много внимание. Той получи много внимание, защото въведе невероятни нови концепции и ето екранна снимка на предната част на него. И така, те извадиха тази концепция на скрам от ръгбито в играта и я внедриха в бизнес и по-специално в играта за проектиране и изпълнение на проекти, по-специално за изпълнение на проекти.
Това, което scrum направи, ни даде нова методология в сравнение с харесванията на PRINCE2 или PMBOK, които преди използвахме в това, което нарекохме методология на водопада, знаете, направете това и това нещо и това нещо и ги следвайте последователно и свържете всички точки наоколо, което зависи от това какво сте имали или не правете част втора, докато не сте направили част първа, защото това зависи от първа част. Това, което ни даде, е нова методология, за да бъдем малко по-гъвкави, откъдето идва и терминът, за това как ние доставяме нещата, и по-специално около проектирането и разработката на ниски проекти.
Някои от ключовите наематели - просто така се занимавам с това - са около ключовите наематели на скрума. Той въведе идеята за изграждане на нестабилност, че ефективно, ако се замислите за страха от хаоса, светът съществува в състояние на хаос, но планетата се формира, което е интересно, така че изграждането на нестабилност, способността да отскачате малко и все още всъщност правят нещата работещи, самоорганизиращи се екипи на проекти, припокриващи се услуги чрез много отговорно развитие, различни видове учене и контрол през пътя на изпълнение на проекта, организационен трансфер на обучение. И така, как да вземем информация от една част от бизнеса и да я прехвърлим в друга от хора, които имат идея, но не разработват код или не развиват бази данни и инфраструктури, а данни на тези хора? И по-конкретно заложени във времето резултати. С други думи, нека направим това за определен период от време, или на ден, като на 24 часа, или на седмица, или на две седмици и да видим какво можем да направим, а след това да отстъпим и да го погледнем.
И така, ако помилвате за каламбура, това наистина е нова игра в изпълнението на проекти и трите основни компонента към нея, което ще има смисъл, докато стигнем малко по-напред тук - има продукт: всички тези хора имат идеята и имат нужда да се свърши нещо и историята, която ги заобикаля. Разработчиците, които работят по гъвкавия модел за получаване на своите истории и чрез ежедневни стайпъпи, използвайки методологията на scrum, за да ги обсъдят и разберат какво трябва да направят, а след това просто отидете и се заемете с това. Тогава хора, чували сме за майстори на скрумовете, които контролират цялото това нещо и разбират методологията достатъчно добре, за да го управляват. Всички сме виждали тези изображения, които имам от дясната страна тук, на стени и бели дъски, пълни с бележки от Post-It и те са служили като стени на Kanban. Ако не знаете кой е Канбан, ви каня в Google кой беше г-н Канбан и защо това беше промяна в начина, по който преместваме нещата от едната страна на другата в стената, буквално, но в проект.
На пръв поглед работният процес на scrum прави това: взема списък с неща, които една организация иска да направи, изпълнява ги през поредица от неща, които наричаме спринти, които са разделени на 24-часови периоди, месечни периоди и ние вземете тази постепенна серия от изходи. Това е съществена промяна в начина на изпълнение на проектите, доставяни до този етап, защото част от това протича като американската армия, която имаше голяма част да разработи нещо, наречено PMBOK, като идеята, която не извежда танка в полето докато не вкарате куршуми в нещата, защото ако един резервоар в полето няма куршуми, това е безполезно. Следователно част първа е поставена куршуми в резервоара, друга част е поставена резервоара в полето. За съжаление обаче, това, което се случи с разработчиците в света на разработките, някак се овладее от тази пъргава методология и изтича с нея изравнено, ако помилвате за каламбура, в спринт.
Неизменно това, което се е случило е, когато мислим за пъргави обикновено мислим за разработчици, а не за бази данни и нещо общо със света на базите данни. Това беше жалко изход, защото реалността е, че пъргавото не е ограничено до разработчиците. Всъщност терминът пъргав според мен често е погрешно свързан изключително с разработчиците на софтуер, а не с дизайнери на бази данни и архитекти. Неизменно същите предизвикателства, пред които сте изправени при разработването на софтуер и приложения, се сблъскват във всичко, свързано с проектирането и разработването, експлоатацията и поддръжката, и следователно с инфраструктурата на данните и особено с базите данни. Актьорите в този конкретен набор от данни включват харесването на архитектите на данни, формовъците, администраторите, мениджърите на инфраструктурите на базата данни и самите реални бази данни до бизнес и системни анализатори и архитекти, хора, които седят и мислят как системите и бизнесът работи и как сме стигнали да предаваме данни през тях.
Това е тема, която редовно повдигам, защото това е моето постоянно неудовлетворение, тъй като аз съм много на мнение, че специалистите по данни трябва - не би трябвало - трябва интензивно да участват във всеки компонент на изпълнението на проекта, наистина, особено в развитието. За да не го направим, тогава всъщност не си даваме най-добрия шанс за добър резултат. Често се налага да се въртим назад и да помислим за тези неща, защото съществува сценарий, стигаме до създадено приложение и откриваме, че разработчиците не винаги са експерти по данни. Работата с бази данни изисква много специализирани умения, особено около данните, и изгражда опит. Вие не просто незабавно ставате гуру на базата данни или експерт за знания на данните за една нощ; това често е нещо, което идва от опит в живота и със сигурност с харесванията на д-р Робин Блур от „Кодекс Днес“, който доста богато написа книгата.
В много случаи - и това е жалко, но е реалност - че има две части на тази монета, тоест разработчиците на софтуер имат собствено затъмнение за специалист по бази данни и са изградили необходимите умения при моделиране на дизайн на базата данни, като разработката на модела е само основополагащ за проектирането на гурута за това как влизат данните и как организацията на пътуването отнема и какво трябва да изглежда или не трябва да изглежда, или несъмнено това, което е погълнато и разбирането, че обикновено се получава в родните умения, определени за софтуерните разработчици. И някои от често срещаните предизвикателства, с които се сблъскваме, само за да поставим това в контекст, включва харесването на само основното създаване и поддръжка и управление на самия дизайн на основна база данни, документиране на данните и инфраструктурата на базата данни и след това повторно използване на тези активи на данни, схеми, генериране на схеми, администриране и поддръжка на схемата и използването им, споделяне на знанията около това, защо тази схема е проектирана по определен начин, а силните и слабите страни, които идват с това с времето, причиняват промени в данните във времето, моделиране на данни и видовете от модели, които прилагаме към системите и данните, които предаваме през тях. Генериране на код на базата данни и той преминава към интегриране и след това моделиране на данни около тях и след това по-бърз достъп до контрол на сигурността около данните, целостта на данните, ние движим данните наоколо, докато запазваме нейната цялост, има ли достатъчно метаданни то, трябва ли продажбите да виждат всички записи в таблицата или трябва ли да виждат само адреса, името, фамилията, която ви изпраща неща в публикацията? И тогава, разбира се, най-голямото предизвикателство от всичко е онова моделиране на платформи за бази данни, което е изцяло различен разговор сам по себе си.
Силно съм на мнение, че като се има предвид всичко това, за да се направи каквато и да е тази нирвана, е изключително важно, както специалистите по данни, така и разработчиците да разполагат с подходящи инструменти и тези инструменти да могат да бъдат насочени към екип за изпълнение на проекти, проектиране, разработка и текуща оперативна поддръжка. Знаете, неща като сътрудничество между проекти между експерти по данни и разработчици на софтуер, единична точка на истината или единен източник на истина за всичко около документацията на самите бази данни, данните, схемите, откъдето идват записите, собственици на тези записи, Мисля, че в този ден и възраст това е абсолютно критично, ще вземем тази нирвана от данни да бъдем крал, че правилните инструменти трябва да бъдат налице, защото предизвикателството е твърде голямо сега, за да го направим ръчно и ако хората Придвижването и излизането от една организация е твърде лесно за нас да не следваме същия процес или методология, които може да създаде един човек, които са добри и не е задължително да прехвърлят тези умения и възможности напред.
Имайки това предвид, ще се свържа с нашия добър приятел от IDERA и ще чуя за този инструмент и как се справя с тези много неща.
Рон Хуйзенга: Благодаря ви много и благодаря и на Робин, и на Дез, че наистина добре поставиха сцената и ще видите малко припокриване в няколко неща, за които говорих. Но те наистина са поставили много солидна основа за някои от концепциите, за които ще говоря от гледна точка на моделиране на данни. И много от нещата, за които те казаха, отговарят на моя собствен опит, когато бях консултант, работещ в областта на моделирането на данни и архитектурата на данните, заедно с екипи - както водопад в първите дни, така и се развива в по-модерни продукти с проекти, в които използвахме пъргавост методологии за предоставяне на решения.
Така че това, за което ще говоря днес, се основава на тези преживявания, както и на преглед на инструментите и някои от възможностите в инструментите, които използваме, за да ни помогне в това пътуване. Това, което ще разгледам накратко, е, че няма да изпадам в подробности много подробно; просто имахме наистина добър преглед на това какво е това. Ще говоря за това по отношение на това, какво е модел на данни и какво всъщност означава това за нас? И как да дадем възможност на концепцията за пъргавия моделиер на данни в нашите организации по отношение на това, как да ангажираме моделарите на данни, какво е участието на моделиери и архитекти по време на спринта, какви са видовете дейности, с които трябва да се занимават и, като фон за това, кои са някои от важните възможности на инструмента за моделиране, които използваме, за да помогнем наистина да улесним тази работа? След това ще се спра на малко и ще говоря малко за някои бизнес стойности и ползи от включването на модела на данни или начина, по който всъщност ще разкажа историята, проблемите с липсата на пълномощник на данни да се ангажира изцяло с проектите и ще ви покажа, че на базата на опит и диаграма на дефекти на преди и след изображение на действителен проект, с който участвах преди много години. След това ще обобщим още няколко точки и след това ще имаме въпроси и отговори в допълнение.
Накратко, ER Studio е много мощен пакет, който има много различни компоненти към него. Архитектът на данни, където моделарите на данни и архитектите прекарват по-голямата част от времето си в моделиране на данни. Има и други компоненти, за които днес изобщо няма да говорим, като бизнес архитекта, където правим моделиране на процеси и софтуерния архитект, за някои от UML моделирането. След това е хранилището, където се регистрираме и споделяме моделите и позволяваме на екипите да си сътрудничат и да ги публикуваме на сървъра на екипа, така че множество заинтересовани аудитории, които са ангажирани в даден проект, всъщност да виждат артефактите, които „ създаваме от гледна точка на данните, както и другите неща, които правим при самото изпълнение на проекта.
Това, върху което ще се съсредоточа днес, ще бъдат няколко неща, които ще видим от Data Architect и защото наистина е важно да имаме съвместната работа на базирани в хранилищата аспекти на това. Особено когато започнем да говорим за концепции като управление на промените, които са наложителни, не само за гъвкави проекти за развитие, но и за всякакъв вид развитие, което върви напред.
Така че нека поговорим за Agile Data Modeler за момент. Както вече напомняхме по-рано в презентацията, е, че е наложително да имаме моделисти на данни и / или архитекти, изцяло ангажирани с процесите на гъвкава разработка. Това, което се е случило в исторически план, е, да, наистина сме мислили за гъвкавост от гледна точка на развитието и има няколко неща, които са продължили, което наистина е довело до това. Част от него се дължи само на естеството на начина, по който се развива самото развитие. Когато пъргавото развитие започна и ние започнахме с тази концепция за самоорганизиращи се екипи, ако сте пили Kool-Aid малко прекалено чисто и сте били от крайната програмна страна на нещата, имаше много буквално тълкуване на неща като самоорганизиращи се екипи, което много хора интерпретират да означават, всичко, от което се нуждаем, е група разработчици, които могат да създадат цялостно решение. Независимо дали означава разработването на кода, базите данни или магазините за данни зад него и всичко беше предадено на разработчиците. Но това, което се случва с това е, че губите от специалните способности, които хората имат. Открих, че най-силните екипи са тези, които са съставени от хора от различни среди. Като комбинация от силни разработчици на софтуер, архитекти на данни, моделисти на данни, бизнес анализатори и бизнес заинтересовани страни, всички заедно си сътрудничат за постигане на крайно решение.
Това, за което също говоря днес, е, че ще направя това в контекста на проект за разработка, в който разработваме приложение, което очевидно ще има и компонента от данни, свързан с него. Необходимо е да направим крачка назад, преди да го направим, защото трябва да осъзнаем, че има много малко проекти за развитие на „Грийнфийлд“ там, където сме насочени към създаването и консумацията на данни, които са ограничени само в рамките на самия проект за развитие., Трябва да направим крачка назад и да разгледаме цялостната организационна гледна точка от гледна точка на данните и процесите. Защото това, което откриваме, е информацията, която използваме, може вече да съществува някъде в организациите. Като моделисти и архитекти извеждаме това на светло, така че да знаем откъде да изпратим тази информация в самите проекти. Ние също така знаем структурите на данните, които участват, защото имаме дизайнерски модели, точно както разработчиците имат дизайнерски модели за техния код. И ние също трябва да приемем тази цялостна организационна перспектива. Не можем просто да разгледаме данните в контекста на приложението, което изграждаме. Трябва да моделираме данните и да се уверим, че ги документираме, тъй като те живеят далеч извън самите приложения. Тези приложения идват и си отиват, но ние трябва да можем да разгледаме данните и да се уверим, че са здрави и добре структурирани, не само за прилагане, но и за решения, които отчитат дейности, BI отчитане и интегриране към други приложения, вътрешни и външни за нашите организации. Затова трябва да разгледаме цялата обща картина на данните и какъв е жизненият цикъл на тези данни и да разберем пътуването на информацията в цялата организация от люлката до гроба.
Сега към самите екипи и как всъщност трябва да работим, методологията на водопада се възприема като твърде бавна, за да даде резултати. Защото, както беше посочено с примера на резервоара, това беше една стъпка след друга и често отне твърде много време, за да се постигне работещ краен резултат. Това, което правим сега е, че трябва да имаме итеративен стил на работа, в който постепенно разработваме компоненти от него и го усъвършенстваме във времето, където създаваме използваем код или използваеми артефакти, ще кажа, за всеки спринт. Важното е сътрудничеството между техническите заинтересовани страни в екипа и бизнес заинтересованите страни, тъй като ние си сътрудничим, за да пренесем тези потребителски истории в изпълнима визия на кода и данните, които поддържат и този код. А самият Agile Data Modeler често ще открие, че нямаме достатъчно моделисти в организациите, така че един моделиер на данни или архитект може едновременно да поддържа множество екипи.
И другият аспект на това е, че дори да имаме множество моделисти, трябва да сме сигурни, че имаме набор от инструменти, който използваме, който позволява съвместна работа на множество проекти, които са в полет по едно и също време и споделяне на тези артефакти на данни и възможностите за регистрация и напускане. Ще разгледам това много бързо, защото вече го разгледахме в предишния раздел. Истинската предпоставка за гъвкавостта е, че вие основавате нещата от изоставането, историите или изискванията. В рамките на итерациите ние си сътрудничим като група. Обикновено двуседмичен или едномесечен спринт, в зависимост от организацията, е много често. А също и ежедневни срещи за преглед и резервни работи, така че да премахваме блокерите и да се уверим, че движим всички аспекти напред, без да спираме в различни области, докато преминаваме. И в тези спринтове искаме да сме сигурни, че произвеждаме използваеми резултати като част от всеки спринт.
Просто малко по-различно възприемам това, разширявайки го допълнително, размисълът е методологията, за която ще говоря по-конкретно тук и ние просто по същество увеличихме тази предишна снимка с няколко други аспекта. Обикновено има изоставане на продукта, а след това има и спринт. Така че ние имаме цялостно изоставане, че в началото на всяко повторение на спринта, ние се представяме, за да кажем: „Какво ще създадем този спринт?“ И това се прави на среща за планиране на спринт. След това разбиваме задачите, които са свързани с това и изпълняваме в тези спринтове от една до четири седмици с тези ежедневни прегледи. Докато правим това, ние проследяваме напредъка си чрез графики за изгаряне и графики за горене, за да проследим основно какво е необходимо да изградим спрямо това, което изграждаме, за да установим неща като скоростта на нашето развитие, ще направим ли нашата график, всички тези видове неща. Всички те са разработени непрекъснато по време на спринта, а не да тръгнете няколко месеца надолу по пътя и да разберете, че ще излезете малко и трябва да удължите графика на проекта. И много важно, като част от него, целите екипи, има спринт преглед в края и спринт ретроспектива, така че преди да започнете следващата итерация, вие преглеждате какво сте направили и търсите начини, които можете да направите подобри следващия път.
По отношение на резултатите, това е основно слайд, който обобщава типичните видове неща, които продължават в спринтове. И това е много ориентирано към развитието, така че много от нещата, които виждаме тук, като, функционални дизайни и случаи, използвайки тестове за дизайн на кода, когато разглеждаме тези кутии тук, и няма да ги преглеждам във всяко ниво на детайл, те са много ориентирани към развитието. И тук е погребан фактът, че ние също трябва да имаме тези данни, които вървят ръка за ръка, за да подкрепим това усилие. Така че всеки път, когато виждаме неща като изоставането, изискванията и потребителските истории, докато преминаваме, трябва да разгледаме какви са разработките, които трябва да направим, какви са частите за анализ, които трябва да направим, какво ще кажете за дизайн на данни или модел на данни, какво ще кажете за неща като бизнес речниците, за да можем да свържем значението на бизнеса с всички артефакти, които произвеждаме? Защото трябва да произвеждаме тези използваеми резултати във всеки спринт.
Някои хора ще кажат, че трябва да произвеждаме използваем код в края на всеки спринт. Това не е задължително да е така, това е в най-чиста перспектива за развитие, но доста често - особено в началото - може да имаме нещо като нулата на спринта, където сме фокусирани чисто върху изправянето на нещата, като правим неща като получаване на нашите тестови стратегии в място. Дизайн на високо ниво, за да го стартираме, преди да започнем да попълваме детайлите и се уверяваме, че имаме чист набор от начални истории или изисквания, преди да започнем да ангажираме друга аудитория и след това да изграждаме напред като екип, като вървим напред. Винаги има малко време за подготовка, затова доста често ще имаме спринт нула или дори спринт нула и едно. Може да е малко фаза на стартиране, преди да постигнем пълен полет при предоставянето на решението.
Нека поговорим за моделите данни в този контекст много накратко. Когато хората мислят за модели на данни, те често мислят за модел на данни като за картина как различните части от информация се свързват заедно - това е само върхът на айсберга. За да въплътите напълно духа на това как наистина искате да подходите към моделиране на данни - независимо дали е в пъргаво развитие и други неща - трябва ли да осъзнаете, че моделът на данните, ако е направен правилно, се превръща във вашата пълна спецификация за това какво означават тези данни в организацията и как е внедрен в задните бази данни. Когато казвам бази данни, имам предвид не само релационните бази данни, които може да използваме, но в днешните архитектури, където имаме големи данни или NoSQL платформи, както предпочитам да ги наричам. Също и тези големи хранилища на данни, защото може да комбинираме много различни хранилища на данни по отношение на консумацията на информация и въвеждането им в нашите решения, както и как ние запазваме или съхраняваме тази информация извън нашите решения.
Възможно е да работим с множество бази данни или източници на данни едновременно в контекста на дадено приложение. Това, което е много важно, е, че искаме да можем да имаме пълна спецификация, така че логично уточнение какво означава това за спринтска организационна перспектива, какви са физическите конструкции по отношение на това как всъщност дефинираме данните, отношенията между тях в вашите бази данни, вашите референтни ограничения за интегритет, проверка на ограничения, всички онези части за проверка, които обикновено мислите. Описателните метаданни са изключително важни. Как знаете как да използвате данните във вашите приложения? Освен ако не можете да го дефинирате и знаете какво означава или знаете откъде са дошли, за да сте сигурни, че консумирате правилните данни в тези приложения - като се уверите, че имаме правилни конвенции за именуване, пълни дефиниции, което означава пълен речник на данни за не само таблиците, но колоните, които съдържат тези таблици - и подробни бележки за внедряване за това как го използваме, защото трябва да изградим тази база знания, защото дори когато това приложение е направено, тази информация ще бъде използвана за други инициативи, така че трябва да сме сигурни че имаме всичко това документирано за бъдещи реализации.
Отново стигаме до неща като типове данни, ключове, индекси, самият модел на данни въплъщава много от бизнес правилата, които влизат в игра. Връзките не са само ограничения между различни таблици; те често ни помагат да опишем какви са истинските бизнес правила около това как се държат тези данни и как работят заедно като сплотено звено. И разбира се, ценните ограничения са много важни. Сега, разбира се, едно от нещата, с които непрекъснато се занимаваме и става все по-разпространено, са неща като управление на данните. И така, от гледна точка на управлението на данните, ние също трябва да разгледаме какво определяме тук? Искаме да определим неща като класификации за сигурност. С какви видове данни имаме работа? Какво ще се счита за главно управление на данни? Какви са транзакционните магазини, които създаваме? Какви референтни данни използваме в тези приложения? Трябва да се уверим, че е правилно заснета в нашите модели. И също така съображения за качеството на данните, има някои информации, които са по-важни за една организация от другите.
Участвал съм в проекти, в които заменяме над дузина наследени системи с нови бизнес процеси и проектираме нови приложения и магазини за данни, които да ги заменят. Трябваше да знаем откъде идва информацията. Кой за най-важните сведения, от бизнес гледна точка, ако погледнете този слайд на конкретен модел на данни, който имам тук, ще видите, че долните полета в тези конкретни единици, което е само малък подмножество, аз всъщност успях да уловим стойността на бизнеса. Независимо дали са високи, средни или ниски за тези видове неща за тези различни конструкции в организацията. Освен това съм уловил неща като главните класове данни, независимо дали са главни таблици, дали са референтни, дали са транзакционни. Така че можем да разширим метаданните си в нашите модели, за да ни дадем много други характеристики извън самите данни, които наистина ни помогнаха с други инициативи извън първоначалните проекти и да ги пренесем напред. Сега това беше много в един слайд, ще разгледам останалите бързо.
Сега ще говоря много бързо за това какво прави модела на данни, докато преминаваме през тези различни спринтове. На първо място, пълен участник в сесиите за планиране на спринт, където ние вземаме потребителски истории, ангажирайки се с това, което ще предоставим в този спринт, и измисляме как ще го структурираме и доставим. Това, което правя също като моделиер на данни е, че знам, че ще работя в отделни области с различни разработчици или с различни хора. Така че една от важните характеристики, която можем да имаме, когато правим модел на данни, можем да разделим този модел на данни на различни гледни точки, независимо дали ги наричате предметни области или подмодели, е нашата терминология. Тъй като ние изграждаме модела, ние също го показваме в тези различни перспективи на подмодела, така че различните аудитории виждат само това, което е от значение за тях, за да могат да се концентрират върху това, което разработват и предлагат. Така че може би ще имам някой, който работи върху планирането на част от приложението, може би ще имам друг, който да работи върху запис за поръчка, където правим всички тези неща в един спринт, но мога да им дам гледните точки чрез онези подмодели, които само важат за зоната, върху която работят. И след това тези стигат до цялостния модел и цялата структура на подмоделите, за да дадат на различните зрители гледки какво трябва да видят.
Основи от гледна точка на моделирането на данни, които искаме да имаме, винаги трябва да имаме основна линия, към която можем да се върнем, защото едно от нещата, които трябва да можем да направим, е дали в края на спринта или в края от няколко спринта, искаме да знаем откъде сме започнали и винаги имаме основна линия, за да знаем каква е била делта или разликата от това, което сме произвели в даден спринт. Ние също трябва да сме сигурни, че можем да постигнем бърз обрат. Ако влезете в него като моделатор на данни, но в традиционната роля на вратаря, който казва „Не, не, не можете да го направите, първо трябва да направим всичко това“, ще бъдете изключени от екипа, когато наистина се нуждаете да бъде активен участник във всички онези гъвкави екипи за развитие. Това означава, че някои неща падат от вагона, изпълнявайки даден спринт и ги вдигате в по-късните спринтове.
Като пример, можете да се съсредоточите върху структурите от данни, само за да накарате развитието да се каже, онова парче за въвеждане на поръчка, за което говорих. В по-късен спринт може да се върнете и да попълните данните като част от документацията за речника на данните около някои от тези артефакти, които сте създали. Няма да завършите това определение всичко в един спринт; ще продължавате постепенно да постигате своите резултати, защото ще има моменти, в които можете да попълвате тази информация, работейки с бизнес анализатори, когато разработчиците са заети с изграждането на приложенията и постоянството около тези хранилища на данни. Искате да улесните, а не да сте тясното място. Има различни начини, по които работим с разработчиците. За някои неща имаме дизайнерски модели, така че ние сме пълен участник отпред, така че може да имаме модел на дизайн, където ще кажем, че ще го поставим в модела, ще го изтласкаме към базата данни на разработчиците на разработчиците и тогава те могат започнете да работите с него и да поискате промени в това.
Може да има други области, над които разработчиците работят, те имат нещо, върху което работят и прототират някои неща, така че да изпробват някои неща в собствената си среда за разработка. Взимаме тази база данни, с която са работили, въвеждаме я в нашия инструмент за моделиране, сравняваме с моделите, които имаме и след това разрешаваме и изтласкваме промените обратно към тях, за да могат да префабрикуват кодовете си, така че да следват правилните структури от данни че имаме нужда. Тъй като може би са създали някои неща, които вече сме имали другаде, затова се уверяваме, че работят с правилните източници на данни. Просто продължаваме да повтаряме през целия този път до нашия спринт, така че да получим пълните данни, пълна документация и определението за всички онези структури от данни, които произвеждаме.
Най-успешните гъвкави проекти, в които участвах по отношение на много добри доставки е, имахме философия, моделирахме всички промени в пълната спецификация на физическата база данни. По същество моделът на данни се превръща в разгърнатите бази данни, с които работите за всичко ново, което създаваме и има пълни референции на другите хранилища на данни, ако консумираме от други външни бази данни. Като част от това ние произвеждаме инкрементални скриптове срещу това да правим пълно поколение всеки път. И ние използваме нашите дизайнерски модели, за да ни дадем това бързо повдигане по отношение на това да вървим нещата в спринти с различните екипи за разработка, с които работим.
И в спринт дейностите отново е тази база за сравнение / сливане, така че нека вземем идеята за моделиране на всяка промяна. Всеки път, когато правим промяна, това, което искаме да направим, е да искаме да моделираме промяната и това, което е много важно, това, което липсваше от моделирането на данни доскоро, всъщност, докато не го въведем отново, е способността да се асоциира моделирането задачи и резултати от потребителските истории и задачи, които всъщност причиняват тези промени. Искаме да можем да проверим промените в модела си, по същия начин, по който разработчиците проверяват кодовете си, препращайки онези потребителски истории, които имаме, така че знаем защо на първо място направихме промени, това е нещо, което правим. Когато правим това, ние генерираме инкременталните си DDL скриптове и ги публикуваме, така че да могат да бъдат изтеглени с другите резултати от разработката и да бъдат проверени в нашето решение за изграждане. Отново може да имаме един модел или да работим с множество екипи. И както съм говорил, някои неща са създадени от модела на данни, други неща са създадени от разработчиците и ние се срещаме в средата, за да излезем с цялостния най-добър дизайн и да го прокараме напред и да се уверим, че е правилно проектиран в нашия цялостни структури от данни. Трябва да поддържаме дисциплината да гарантираме, че имаме всички правилни конструкции в нашия модел на данни, докато вървим напред, включително неща като нулеви и ненулеви стойности, референтни ограничения, основно проверка на ограничения, всички онези неща, за които обикновено мислим,
Нека сега да поговорим само за няколко скрийншота на някои от инструментите, които ни помагат да направим това. Това, което мисля, че е важно, е да имаме това хранилище за сътрудничество, така че това, което можем да направим като моделиер на данни - и това е фрагмент на част от модел на данни на заден план - е, когато работим върху неща, които искаме да сме сигурни, че можем работим само върху обектите, които трябва да можем да променим, да правим модификациите, да генерираме своите DDL скриптове за промените, които направихме, докато проверяваме нещата. Така че това, което можем да направим, е, че в ER Studio е пример, можем да проверим обекти или групи от обекти, върху които да работим, не е нужно да проверяваме цял модел или подмодел, можем да проверим само онези неща, които ни интересуват. Това, което искаме след това, е или при напускане, или при настаняване - ние го правим и по два начина, защото различните екипи за развитие работят по различни начини. Искаме да сме сигурни, че го свързваме с потребителската история или задача, която движи изискванията за това и това ще бъде същата потребителска история или задача, която разработчиците ще разработват и проверяват кода си.
Ето тук е много бърз фрагмент от няколко екрана на един от нашите центрове за управление на промени. Това, което прави това, няма да разглеждам подробно тук, но това, което виждате, е историята или задачата на потребителя и е отредено под всеки един от онези, които виждате действителните записи на промените - създадохме автоматичен запис за промяна, когато правим проверката и напускането и можем да добавим още описание и на този запис за промяна. Той е свързан със задачата, можем да имаме няколко промени на задача, както бихте очаквали. И когато влезем в този запис за промяна, можем да го разгледаме и по-важното - какво всъщност променихме? За тази конкретна, откроената история там имах един тип промяна, която беше направена и когато разгледах самия запис на действителните промени, той идентифицира отделните части в модела, който се е променил. Промених няколко атрибута тук, пренасочих ги и донесох за возенето гледките, които трябваше да бъдат променени, които зависеха и от тях, така че те да бъдат генерирани в инкременталната DLL. Това не е само моделиране на базовите обекти, но мощен инструмент за моделиране като този открива и промените, които трябва да бъдат пулсирани през зависимите обекти в базата данни или модела данни.
Ако работим с разработчици и правим това в няколко различни неща, това прави нещо в тяхната пясъчна кутия и искаме да сравним и да видим къде са разликите, използваме възможностите за сравнение / сливане, където отдясно и отляво страна. Можем да кажем: „Ето нашия модел вляво, тук е тяхната база данни от дясната страна, покажете ми разликите.“ След това можем да изберем и да изберем как да разрешим тези различия, независимо дали натискаме нещата в базата данни или ако има някои неща, които имат в базата данни, които ние връщаме обратно в модела. Можем да преминем двупосочно, така че можем да преминем и в двете посоки едновременно да актуализираме както източника, така и целта и след това да произведем инкременталните DDL скриптове, за да разгърнем тези промени в самата среда на базата данни, което е изключително важно. Това, което можем също да направим, е, че можем също да използваме тази възможност за сравнение и сливане във всеки даден момент, ако правим снимки на пътя, винаги можем да сравним началото на един спринт с началото или края на друг спринт, за да можем да видим пълната постепенна промяна на направеното в даден спринт на развитие или над серия спринти.
Това е много бърз пример за алтер скрипт, всеки от вас, който работи с бази данни, ще е виждал този тип неща, това е, което можем да изтласкаме от кода като алтер скрипт, така че да се уверим, че ние запазете нещата тук. Това, което извадих оттук, само за да намалим затрупаността, е това, което правим и с тези алтернативни скриптове, е да приемем, че има данни и в тези таблици, така че ще генерираме и DML, който ще изтегли информацията от временните таблици и връщаме го отново в новите структури от данни, така че ние разглеждаме не само структурите, но и данните, които може би вече имаме в тези структури.
Ще говорим много бързо за автоматизираните системи за изграждане, защото когато правим гъвкав проект доста често работим с автоматизирани системи за изграждане, където трябва да проверим в различните резултати заедно, за да сме сигурни, че няма да прекъснем нашите предимства. Това означава, че синхронизираме резултатите, трябва да се проверят онези скриптове за промяна, за които говорих с DDL скрипта, съответният код на приложение трябва да бъде проверен едновременно и сега много разработчици са разработили, разбира се, не се прави с директен SQL срещу базите данни и този тип неща. Доста често използваме устойчиви рамки или изграждаме услуги за данни. Трябва да сме сигурни, че промените за тези рамки или услуги са регистрирани точно по едно и също време. Те влизат в автоматизирана система за изграждане в някои организации и ако сглобяването се счупи, по гъвкава методология, всички ръце по фиксирането на палубата се изграждат преди да продължим напред, така че да знаем, че имаме работно решение, преди да продължим по-нататък. И един от проектите, с които участвах, ние стигнахме до крайност - ако сглобяването се счупи, ние всъщност бяхме прикачени към редица компютри в нашия район, където бяхме колокирани с бизнес потребителите, имахме червени мигащи светлини просто като върха на полицейските коли. И ако компилацията се счупи, тези червени мигащи светлини започнаха да угасват и знаехме, че всичко е на палубата: оправете изграждането и след това продължете с това, което правим.
Искам да говоря за други неща и това е уникална възможност за ER Studio, това наистина помага, когато се опитваме да изградим тези артефакти като разработчици за тези граници на постоянство, имаме концепция, наречена обекти на бизнес данни и това, което ни позволява да направете, ако разгледате този много опростен модел на данни като пример, той ни позволява да капсулираме образувания или групи от образувания, където са границите на постоянство. Когато ние като моделиер на данни може да мислим за нещо като заглавка на поръчка за покупка и подравняване на поръчките и други подробни таблици, които биха се обвързали с това по начина, по който го изграждаме, и нашите разработчици на услуги за данни трябва да знаят как продължават нещата към тези различни данни структури. Нашите разработчици мислят за неща като поръчката за покупка като обект като цяло и какъв е договорът им с това как създават тези конкретни обекти. Можем да изложим тази техническа подробност, така че хората, изграждащи сървърите за данни, да виждат какво се намира под нея и можем да предпазим другите аудитории от сложността, така че те просто да видят различните обекти от по-високо ниво, което също работи много добре за комуникация с бизнеса анализатори и бизнес заинтересовани страни, когато говорим и за взаимодействието на различни бизнес концепции.
Хубавото в това също е, че конструктивно ги разширяваме и свиваме, за да можем да поддържаме връзките между обектите от по-висок ред, въпреки че те произхождат от конструкции, които се съдържат в самите обекти на тези бизнес данни. Сега като моделиер, стигнете до края на спринта, в края на спринтното приключване, имам много неща, които трябва да направя, които наричам домакинството си за следващия спринт. Всеки спринт създавам това, което наричам Named Release - това ми дава моята основна линия за това, което сега имам в края на изданието. Така че това означава, че моята основна линия върви напред, всички тези базови линии или Named Releases, които създавам и записвам в моето хранилище, мога да използвам за сравняване / сливане, така че винаги мога да сравнявам с всеки даден край на спринта от всеки друг спринт, който е много важно да знаете какви са промените ви в модела на вашите данни по пътя му.
Също така създавам делта DDL скрипт, използвайки сравнението / сливането отново от началото до края на спринта. Може да съм проверил в цял куп инкрементален скрипт, но ако имам нужда, сега имам скрипт, който мога да разгърна, за да изправя други пясъчни кутии, така че мога просто да кажа, че това е, което имахме в началото на един спринт, push чрез него, изградете база данни като пясъчна кутия, за да започнете със следващия спринт и можем също да използваме тези неща, за да правим неща като резервни QA случаи и в крайна сметка, разбира се, искаме да изтласкаме промените си в производството, така че да имаме много неща по същото време. Отново участваме изцяло в планирането на спринта и ретроспективите, ретроспективите са наистина научените уроци и това е изключително важно, защото можете да вървите много бързо по време на пъргавост, трябва да спрете и да отпразнувате успехите, както сега. Отбележете какво не е наред, направете го по-добре следващия път, но също така отпразнувайте нещата, които се оправиха и надградете върху тях, докато продължавате напред в следващите спринтове, напредващи напред.
Сега много бързо ще говоря за стойността на бизнеса. Имаше проект, с който се включих преди много години, който започна като пъргав проект, и беше екстремен проект, така че беше чист самоорганизиращ се екип, в който просто разработчици правят всичко. За да направим кратка история, този проект беше забавен и те откриваха, че харчат все повече пъти за отстраняване и поправяне на дефектите, които бяха идентифицирани, отколкото за раздвижване на повече функционалност и в действителност, когато го погледнаха по графиките за изгаряне, те ще трябва да удължат проекта с шест месеца с огромна цена. И когато го разгледахме, начинът за отстраняване на проблема беше да се използва подходящ инструмент за моделиране на данни с квалифициран моделатор на данни, включен в самия проект.
Ако погледнете тази вертикална лента на тази конкретна диаграма, това показва кумулативни дефекти срещу кумулативни обекти, а аз говоря за обекти или конструкции на данни, които са създадени, като таблиците с ограниченията и тези типове неща, ако погледнете преди въвеждането на модела на данни, броят на дефектите всъщност надвишаваше и започваше да изгражда малко пропаст спрямо реалния брой обекти, които са били произведени до този момент. След 21-та седмица, когато модела на данни влезе, преработи отново модела на данни въз основа на онова, което трябваше да коригира редица неща и след това започна да моделира, като част от екипа на проекта напред, промените, тъй като този проект се изтласква напред, И видяхте много бърз обрат, че в рамките на спринт и половина видяхме огромна крачка в броя на обектите и конструкциите на данни, които се генерират и конструират, защото ние генерираме от инструмент за моделиране на данни, а не от разработчик изграждането им в среда и те са били правилни, защото са имали подходящата референтна цялост и другите конструкции, които тя трябва да има. Нивото на дефекти спрямо тези почти равни линии. Като предприемете съответните действия и се уверите, че моделирането на данни е изцяло ангажирано, проектът беше доставен навреме с много по-високо ниво на качество и всъщност изобщо нямаше да бъде изпълнен, ако тези стъпки не бяха извършени. Има много пъргави провали навън, има и много пъргави успехи, ако ще получите подходящи хора в правилните роли. Аз съм огромен привърженик на пъргавината като оперативна дисциплина, но трябва да сте сигурни, че имате уменията на всички правилни групи, участващи като ваши екипи по проекта, докато вървите напред в пъргаво начинание.
В обобщение, архитектите на данни и моделистите трябва да бъдат включени във всички проекти за развитие; те наистина са лепилото, което държи всичко заедно, защото като моделисти на данни и архитекти ние разбираме, не само конструктивите от данни на дадения проект за разработка, но и къде съществуват данните в организацията и откъде можем да изпратим тези данни, а също и как ще бъде използван и използван извън конкретното приложение, над което работим. Ние разбираме сложните връзки с данни и е от първостепенно значение да можете да се придвижите напред, а също така и от гледна точка на управлението, за да картографирате документ и да разберете как изглежда вашият пълен пейзаж на данни.
Това е като производство; Дойдох от произход. В крайна сметка не можете да проверите качеството в нещо - трябва да вградите качество в своя дизайн напред и по пътя си, а моделирането на данни е начин да се вгради това качество в дизайна по ефикасен и рентабилен начин през целия път, И отново, нещо, което да запомните - и това не трябва да бъде банално, но е истината - приложенията идват и си отиват, данните са жизненоважният корпоративен актив и надхвърлят всички тези граници на приложението. Всеки път, когато пускате приложение, вероятно ще бъдете помолени да запазите данните от други приложения, които са дошли преди това, така че просто трябва да помним, че това е жизненоважен корпоративен актив, който поддържаме във времето.
И това е! От тук ще вземем още въпроси.
Ерик Кавана: Добре, добре, нека първо да го прехвърля на Робин. И тогава, Дез, сигурен съм, че имаш няколко въпроса. Отнеси го, Робин.
Д-р Робин Блур: Добре. Честно казано, никога не съм имал проблем с гъвкавите методи на развитие и ми се струва, че това, което правите тук, има изтъкнато значение. Спомням си, че разгледах нещо през 80-те години, което всъщност показваше, че проблемът, с който всъщност се сблъсквате по отношение на проект, който излиза извън контрол, обикновено е, ако допуснете грешка да продължи извън определен етап. Просто става все по-трудно да се поправи, ако не се получи този етап правилно, така че едно от нещата, които правите тук - и мисля, че това е слайдът - но едно от нещата, които правите тук в спринт нулата, според мен, е абсолютно важно, защото наистина се опитвате да свържете резултатите там. И ако не получите фиксирани резултати, тогава резултатите променят формата си.
Това е нещо, според мен. Това също е моето мнение - аз наистина нямам спор с идеята, че трябва да получите правилното моделиране на данните до определено ниво на детайлност, преди да преминете през. Това, което бих искал да опитате и да направите, тъй като не получих пълна представа за това, е просто да опишете един от тези проекти по отношение на неговия размер, по отношение на начина, по който тече, по отношение на кой, знаете, къде проблемите бяха изречени, разрешени ли бяха? Понеже мисля, че този слайд е в основата на него и ако можете да разберете малко повече по въпроса, ще съм много благодарен.
Ron Huizenga: Разбира се, и ще използвам няколко примерни проекта. Този, който, като че ли, излезе от релсите, който беше върнат, като всъщност се включиха правилните хора и направиха моделиране на данни и всичко беше наистина начин да се гарантира, че дизайнът е разбран по-добре и очевидно имаме по-добър дизайн за изпълнение по пътя чрез моделирането му. Защото когато го моделирате, знаете, че можете да генерирате своя DDL и всичко от задната и външната страна на инструмента, а не да се налага да стискате това, както хората обикновено правят, като отидете направо в среда на база данни. И типични неща, които ще се случат с разработчиците, е, че те ще влязат там и ще кажат, добре, имам нужда от тези таблици. Да речем, че правим заявки за поръчки. Така че те могат да създадат заглавката на поръчката и таблиците с подробности за поръчката и тези типове неща. Но те често ще забравят или пренебрегват, за да се уверят, че ограниченията са налице, за да представят чуждите ключови връзки. Възможно е клавишите да не са правилни. Споразуменията за именуване също могат да бъдат подозрителни. Не знам колко пъти съм влизал в среда, например, където виждате куп различни таблици с различни имена, но тогава имената на колоните в тези таблици са като ID, Име или каквото и да е, така че те наистина изгубих контекста, без таблицата на точно какво е това.
Така че, обикновено когато моделираме данни, ще се уверим, че прилагаме правилни конвенции за именуване на всички артефакти, които се генерират и в DDL. Но за да бъда по-конкретен за същността на самите проекти, най-общо казано, говоря за доста големи инициативи. Един от тях беше проект за бизнес трансформация на стойност 150 милиона долара, при който сме заменили над дузина наследени системи. Имахме пет различни пъргави отбора едновременно. Имах пълен екип за архитектура на данни, така че имах моделисти на данни от моя екип, вградени във всеки един от другите екипи на областта на приложенията и работехме с комбинация от вътрешни бизнес експерти, които знаеха темата, които правеха потребителски истории за самите изисквания. Във всеки от екипите имахме бизнес анализатори, които всъщност моделираха бизнес процесите, с диаграмите за активност или диаграмите на бизнес процесите, помагащи да се изградят повече потребителските истории с потребителите, преди те да бъдат консумирани и от останалата част от екипа.
И тогава, разбира се, разработчиците, които изграждаха кода на приложението над това. И ние също работехме с, мисля, че четирима различни доставчици на системна интеграция изграждаха различни части на приложението, както и там, където единият екип изграждаше услугите за данни, другият изграждаше логика на приложението в една област, друг, който имаше опит в друга бизнес област изграждаше логиката на приложението в тази област. Така че имахме цяла колаборация от хора, които работеха по този проект. По-конкретно на този един бяхме 150 души на брега на екипа и още 150 ресурси в офшорки на екипа, които си сътрудничиха двуседмични спринтове, за да прогонят това нещо. За целта трябва да сте сигурни, че стреляте по всички цилиндри и всички са добре синхронизирани по отношение на това, какви са техните резултати, а вие сте имали онези чести нули, за да сте сигурни, че изпълняваме доставките на всички необходими артефакти в края на всеки спринт.
Д-р Робин Блур: Това е впечатляващо. И само за малко повече подробности по въпроса - завършихте ли с пълна, както бих нарекъл, MDM карта на цялата област от данни в края на този проект?
Рон Хуйзенга: Имахме цялостен модел на данни, който беше разбит с разлагането между всички различни области на бизнеса. Самият речник на данните от гледна точка на пълните дефиниции падна малко. Бяхме дефинирали повечето от таблиците; имахме по-голямата част от колоните, определени точно какво означават. Имаше някои, които не бяха там и, което е интересно, много от тях бяха части от информация, идваща от наследените системи, където след края на самия обхват на проекта, той все още беше документиран като преносен набор от артефакти, както изглежда, извън самия проект, защото това е нещо, което трябва да бъде поддържано от организацията, която върви напред. Така че в същото време организацията взе много по-голяма гледна точка върху важността на управлението на данните, защото видяхме много недостатъци в тези наследствени системи и онези наследени източници на данни, които се опитвахме да използваме, тъй като те не бяха документирани. В много случаи имахме само бази данни, които трябваше да направим обратно инженер и да се опитаме да разберем какво има и за какво е информацията.
Д-р Робин Блур: Не ме изненадва, точно този аспект от него. Управлението на данните е, така да го наречем, много модерно притеснение и мисля, че наистина има много работа, която, да речем, би трябвало да бъде извършена исторически по отношение на управлението на данните. Никога не е било, защото можеш да се измъкнеш, ако не го направиш. Но тъй като ресурсът на данни просто растеше и растеше, в крайна сметка не можахте.
Както и да е, ще се предам на Дез, защото смятам, че съм си отделил време. Дез?
Дез Бланчфийлд: Да, благодаря. През цялото това нещо аз гледам и си мисля, че говорим за това да виждаме пъргав, използван в гняв по много начини. Въпреки че това има отрицателни конотации; Имах предвид това по положителен начин. Може ли да ни дадете сценарий на това, имам предвид, че има две места, за които виждам, че това е перфектен комплект: едното са нови проекти, които просто трябва да бъдат направени от първия ден, но мисля, че неизменно според моя опит често се случва случаят, когато проектите станат достатъчно големи, че това е необходимо по много начини, има интересно предизвикателство между залепването на двата свята, нали? Можете ли да ни дадете някаква представа за някои истории за успех, които сте виждали къде сте влязоли в организация, става ясно, че те имат лек сблъсък на двата свята и сте успели да поставите успешно това на място и да обединят големи проекти, където може иначе да са тръгнали по релсите? Знам, че това е много широк въпрос, но просто се чудя дали има конкретен случай, който можете да посочите къде сте казали, знаете, ние поставяме всичко това на мястото си и това е събрало целия екип за разработка заедно с екипът за данни и ние някак се спряхме на нещо, което иначе би могло да потъне лодката?
Рон Huizenga: Разбира се, и всъщност един проект, който се оказа проект за тръбопровод, беше този, за който споделих, където показах тази диаграма с дефектите преди и след включването на модела на данни. Доста често има и предварително създадени идеи, особено ако нещата се завъртят там, където е направено от чисто перспектива за развитие, просто разработчиците участват в тези гъвкави проекти, за да доставят приложенията. Така че това, което се случи там, разбира се, е, че те са слезли от релсите и по-специално артефактите си от данни, или изведените данни, които те произвеждат, не достигат знака по отношение на качеството и наистина адресират нещата като цяло. И често има това погрешно схващане, че моделарите на данни ще забавят проектите си и ще се справят, ако моделаторът на данни няма правилното отношение. Както казвам, вие трябва да загубите - понякога има моделисти на данни, които имат това традиционно отношение към вратаря, където: „Ние сме тук, за да контролираме как изглеждат структурите на данните“ и този манталитет трябва да изчезне. Всеки, който участва в гъвкава разработка и по-специално моделатори на данни, трябва да поеме ролята на фасилитатор, за да помогне наистина на екипите да продължат напред. И най-добрият начин да се илюстрира това е много бързо да покажете на екипите колко продуктивни могат да бъдат, като първо моделират промените. И отново, затова говорих за колаборацията.
Има някои неща, които можем първо да моделираме и да генерираме DDL, за да избутаме към разработчиците. Ние също така искаме да се уверим, че те не се чувстват като ограничени. Така че, ако има неща, върху които работят, оставете ги да продължат да работят в своите разработчици, защото там разработчиците работят върху собствените си десктопи или други бази данни, за да направят някои промени, където тестват нещата. И си сътрудничете с тях и кажете: „Добре, работете с това.“ Ще го внесем в инструмента, ще го разрешим и след това ще го избутаме напред и ще ви дадем скриптове, които можете да го разгърнете, за да актуализирате вашия бази данни, за да ги надстроите до това, което е действително разрешената действителна представа за производството, тъй като ще продължим да вървим напред. И можете да го обърнете по много бърз начин. Открих, че дните ми се изпълниха там, където тъкмо се връщах напред и назад, повтаряйки се с различни екипи за развитие, разглеждайки промените, сравнявайки, генерирайки скриптове, задействайки ги и успях да поддържам себе си с четири екипа за развитие доста лесно, след като ние постигна инерция.
Дез Бланчфийлд: Едно от нещата, които ми хрумват от това, е, че знаете, че много от разговорите, които провеждам ежедневно, са за този товарен влак, който идва при нас, като нещо от машината до -машина и IoT. И ако мислим, че сега имаме много данни за настоящата ни среда в предприятието, знаете, ако за момент затворим еднорозите, където знаем, че Googles и Facebooks и Ubers имат петабайти от данни, но в традиционно предприятие говорим за все още стотици терабайти и много данни. Но според мен този товарен влак идва в организации и д-р Робин Блур му споменава по-рано, на IoT. Знаеш ли, имаме много уеб трафик, имаме социален трафик, сега имаме мобилност и мобилни устройства, облакът е, нещо като вид, експлодира, но сега имаме интелигентна инфраструктура, умни градове и има цял свят от данни, който просто е избухнал.
За ежедневна организация, средна до голяма организация, която седи там и вижда този свят на болка да ги сполети и да няма незабавен план, какви са някои от поеманията, само в няколко изречения, които бихте поставили за тях кога и къде трябва да започнат разговорно да мислят за въвеждането на някои от тези методологии. Колко рано трябва да започнат да планират почти да седнат и да обърнат внимание и да кажат, че това е най-подходящото време, за да намерят някои инструменти и да обучат екипа и да проведат разговор на vocab, заобикалящ това предизвикателство? Колко късно в историята е твърде късно или кога е твърде рано? Как изглежда това за някои от организациите, които виждате?
Рон Huizenga: Бих казал за повечето организации, че ако не са го направили вече и са адаптирали моделирането на данни и архитектурата на данни с мощни инструменти като този, времето, което им е необходимо да го направят, е вчера. Защото е интересно, че дори днес, когато разглеждате данни в организации, ние имаме толкова много данни в нашите организации и най-общо казано, въз основа на някои проучвания, които видяхме, ние използваме по-малко от пет процента от тези данни ефективно когато разглеждаме организации. И с IoT или дори NoSQL, големи данни - дори ако това не е само IoT, а общо взето просто големи данни - там, където сега започваме да консумираме още повече информация, която идва от нашите организации, това предизвикателство става все по-голямо и по-голямо през цялото време. И единственият начин да имаме възможност да се справим с това е да ни помогне да разберем за какво става въпрос.
И така, случаят на употреба е малко по-различен. Това, което намираме, е, че когато гледаме тези данни, ние ги улавяме, трябва да го обърнем обратно, да видим какво има в тях, независимо дали е в нашите данни или дори в нашите вътрешни бази данни, да синтезираме това, което data е, приложете значения към него и дефиниции към него, за да можем да разберем какви са данните. Защото докато не разберем какво е, не можем да гарантираме, че го използваме правилно или адекватно. Така че наистина трябва да се справим какво представляват тези данни. И другата част от това е, не го правете, защото можете, по отношение на консумацията на всички тези външни данни, да се уверите, че имате случай на употреба, който поддържа консумацията на тези външни данни. Съсредоточете се върху нещата, които ви трябват, а не просто да се опитвате да изтеглите и използвате неща, които може да се наложи по-късно. Първо се съсредоточете върху важните неща и докато работите по пътя си, след това ще стигнете до консумация и опит за разбиране на другата информация отвън.
Перфектен пример за това е, знам, че говорим за IoT и сензори, но един и същ проблем е в много организации в продължение на много години, дори преди IoT. Всеки, който има система за контрол на производството, независимо дали е компания за тръбопроводи, производство, всякакви компании, базирани на процеси, които имат неща, при които правят много автоматизация с контроли и използват потоци от данни и подобни неща, имат тези скривалища от данни, които те се опитват да изпият, за да разберат, какви са събитията, настъпили в моето производствено оборудване, за да сигнализират - какво се е случило и кога? И сред този огромен поток от данни има само конкретни части от информация или тагове, които се интересуват от това, че трябва да отсеят, синтезират, моделират и разбират. И те могат да игнорират останалото, докато не дойде време наистина да го разберат, и след това могат да разширят обхвата си, за да извлекат все повече и повече от това в обхвата, ако това има смисъл.
Дез Бланчфийлд: Всъщност наистина. Има един въпрос, който ще вляза в въпроса, дойде от джентълмен, наречен Ерик, и ние разговаряхме на частно с него. Току-що помолих неговото разрешение, което е дал, да го поискам от вас. Тъй като това води доста добре до това, просто да приключи, защото с времето вървим малко и ще се върна на Ерик. Но въпросът от друг Ерик беше, разумно ли е да се предполага, че собствениците на стартъп са запознати и разбират уникалните предизвикателства около моделирането на терминологията и така, или трябва да бъде предаден на някой друг за тълкуване? С други думи, трябва ли един стартиращ да бъде способен и готов и желаещ и способен да се съсредоточи върху това и да го постигне? Или е нещо, с което вероятно трябва да пазаруват и да привличат експерти?
Рон Хуйзенга: Предполагам, че краткият отговор е, че наистина зависи. Ако това е стартъп, който няма някой вътрешен служител, който е архитект на данни или моделиер, който наистина разбира базата данни, тогава най-бързият начин да започнете е да доведете някой с консултантски опит, който е много добре запознат в това пространство и може да получи те отиват. Защото това, което ще намерите - и всъщност аз го направих при много ангажименти, които правех, преди да стигна до тъмната страна в управлението на продуктите - е дали ще вляза в организации като консултант, ще ръководя екипите им за архитектура на данни, така че те биха могли да преориентират себе си и да обучат хората си как да правят тези видове неща, така че те да го поддържат и да изпълняват мисията напред. И тогава щях да продължа към следващия си годеж, ако това има смисъл. Има много хора, които правят това, които имат много добър опит с данни, който може да ги накара да продължат.
Дез Бланчфийлд: Това е чудесен момент за поемане и съм напълно съгласен с него и съм сигурен, че и д-р Робин Блур би. Особено при стартиране, вие сте съсредоточени върху това да бъдете МСП върху конкретната стойност на предложенията, които искате да изградите като част от вашия стартиращ бизнес, и вероятно не трябва да сте експерт по всичко, така че страхотен съвет. Но много благодаря, фантастично представяне. Наистина страхотни отговори и въпроси. Ерик, ще ви върна, защото знам, че сме минали вероятно десет минути с течение на времето и знам, че обичате да се придържате към нашите времеви прозорци.
Ерик Кавана: Това е добре. Имаме поне няколко добри въпроса. Позволете ми да го прехвърля. Мисля, че сте отговорили на някои от другите. Но много интересно наблюдение и въпрос от страна на един участник, който пише, че понякога при гъвкави проекти модела на данни не разполага с цялата дългосрочна картина и така завършват да проектират нещо в спринт едно и след това трябва да препроектират в спринт три или четири. Това не изглежда контрапродуктивно? Как можете да избегнете подобни неща?
Рон Хуйзенга: Просто природата на пъргавината няма да постигнете абсолютно всичко в даден спринт. И това всъщност е част от духа на пъргавото: работи с него - ще правите прототипиране там, където работите върху код в даден спринт и ще правите подобрения в него. И част от този процес е, когато доставяте неща, които крайният потребител го вижда и казва: „Да, това е близо, но наистина трябва да го накарам да направи и това малко повече.“ Така че не само влияе върху функционалния дизайн на самия код, но доста често трябва да модифицираме или добавяме повече структура от данни под тези определени неща, за да предоставим това, което потребителят иска. И това е всичко честна игра и затова наистина искате да използвате мощните инструменти, защото много бързо можете да моделирате и направите тази промяна в инструмент за моделиране и след това да генерирате DDL за базата данни, срещу която разработчиците могат да работят, за да доставят това променете се още по-бързо. Спестявате ги от това, че трябва да правят кодиране на ръцете, както би било, на структурите от данни и им позволявате да се концентрират върху логиката на програмиране или приложение, в която са най-опитните.
Ерик Кавана: Това има пълен смисъл. Имахме няколко души, които просто задаваха конкретни въпроси около това как всичко това се връзва към инструмента. Знам, че сте прекарали известно време в разглеждане на примери и сте показвали някои екрани за това как всъщност разгръщате някои от тези неща. По отношение на целия този спринтов процес, колко често виждате това в играта на организациите спрямо колко често виждате по-традиционни процеси, при които нещата просто, вид, се сплитат и отнемат повече време? Колко разпространен е подходът в стила на спринта от вашата гледна точка?
Рон Хуйзенга: Мисля, че го виждаме все повече и повече. Знам, че, бих казал, вероятно през последните 15 години по-често съм виждал осиновяване на хора, които признават, че наистина трябва да приемат по-бърза доставка. Затова видях все повече организации да скачат по пъргавия лента. Не е задължително изцяло; те може да започнат с няколко пилотни проекта, за да докажат, че работи, но има някои, които все още са много традиционни и се придържат към метода на водопада. Добрата новина е, разбира се, че инструментите работят много добре в тези организации, както и за този тип методологии, но ние имаме адаптивността в инструмента, така че тези, които скачат на борда, да имат инструментите в инструментариума на върховете на пръстите им. Неща като сравняване и сливане, неща като обратната инженерна способност, така че те могат да видят какви са съществуващите източници на данни, така че всъщност могат да сравняват и генерират инкременталните DDL скриптове много бързо. И тъй като те започват да възприемат това и виждат, че могат да имат продуктивност, склонността им да се възприемат пъргаво още повече се увеличава.
Ерик Кавана: Е, това са страхотни неща, хора. Току-що публикувах връзка към слайдовете там в прозореца за чат, така че проверете това; малко е малко за теб. Ние имаме всички тези излъчвания за по-късен преглед. Чувствайте се свободни да ги споделите с вашите приятели и колеги. И Рон, благодаря ти много за отделеното време днес, винаги ти е приятно да участваш в шоуто - истински експерт в тази област и е очевидно, че знаеш нещата си. И така, благодарение на вас и благодарение на IDERA и, разбира се, на Dez и нашият собствен Robin Bloor.
И с това ще се сбогуваме, хора. Благодаря отново за отделеното време и внимание. Оценяваме, че се придържате за 75 минути, това е доста добър знак. Добри момчета от шоуто, ще поговорим следващия път. Чао чао.
