Співробітники компанії «Техопедія», 16 листопада 2016 року
Винос: Ведучий Ерік Кавана обговорює важливість моделювання даних у спритній розробці з Робіном Блором, Дез Бланчфілдом та Рона Хуйзенгою IDERA.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, панове. Ласкаво просимо ще раз. У середу о 4:00 за схід. Це означає, що настав час для гарячих технологій. Так, справді. Мене звуть Ерік Кавана, я буду твоїм господарем.
На сьогоднішню тему це старий, але добрий. З кожним днем він стає кращим, оскільки він формує наш світ управління даними, «Моделювання даних у спритному середовищі». Там справді є слайд про твій справді, зачепи мене на Twitter @eric_kavanagh. Ми дійсно повинні поставити це на слайді. Мені доведеться зайнятися цим.
Тож рік гарячий. Моделювання даних існує вічно. Це справді лежить в основі та роботі душі з управління інформацією, розробляючи моделі даних, намагаючись зрозуміти бізнес-моделі та привести їх у відповідність із вашими моделями даних. Це справді те, що ти намагаєшся робити, правда?
Модель даних представляє бізнес фундаментально, тож як усі ці нові джерела даних змінюють гру? Ми дізнаємось про це. Ми дізнаємось, як можна по-справжньому залишатися над речами. І звичайно, це слово року.
Робін Блур з нами, наш головний аналітик, Дез Бланчфілд, що телефонує із Сіднея, Австралія та Рон Хуйзенга, старший менеджер із продуктів IDERA - давній мій друг, відмінний диктор у цьому просторі, знає свої речі, тому не соромтеся, запитайте йому важкі запитання, люди, важкі. З цим я збираюся зробити Робін ведучим і відняти його.
Доктор Робін Блор: Гаразд. Добре дякую за це, Еріку. Я маю сказати про моделювання, що, на мою думку, я був насправді в світі ІТ до його існування, в тому сенсі, що я пам’ятаю в страховій компанії, над якою працював, що у нас був хлопець, який приїхав і подарував нам усілякий вид семінару щодо моделювання даних. Отже, ми дивимось приблизно на 30 років, це 30 років? Може, навіть довше за це, може, 35 років тому. Давно, тривалий час моделювання насправді було частиною індустрії, і, звичайно, це не має нічого спільного з дамами на подіумах.
Те, що я хотів сказати, тому що ми, як і Дез, розмовляємо про різні речі, і я просто думав, що я дам загальний огляд моделювання, але реальність цього є, це стає очевидним.
У нас, знаєте, реальність великих даних, ми маємо більше даних, більше джерел даних, у нас є потоки даних, які увійшли в рівняння за останні три-чотири роки і починають отримувати більшу його частину, і існує більша потреба в розумінні даних та збільшення швидкості зміни, що додає більше даних, а також використовується більше структур даних.
Це важкий світ. Ось його картина, яка насправді є те, що ми намалювали близько трьох років тому, але в основному, як тільки ви включаєте потокове передавання в суміш і отримуєте таке уявлення про переробку даних, центр даних, посилання на дані чи будь-що інше, ви бачите, що є дані, які є по-справжньому в спокої, в тому сенсі, що він не дуже рухається. А потім є дані, потоки і у вас є все транзакційне додаток, а також сьогодні ви маєте події, потоки даних про події, які трапляються в додатках і, можливо, знадобляться, і сьогодні з архітектурою лямбда, про яку всі говорять, справді впливаючи лише на все поле даних.
І сьогодні мислять з точки зору існування рівня даних. Шар даних існує на зразок віртуального способу, в тому сенсі, що хороший шматок його може бути в хмарі, і він може поширюватися по центрах обробки даних, він може існувати на робочих станціях. Рівень даних є певною мірою скрізь, і в цьому сенсі скрізь є процеси, які так чи інакше намагаються обробити дані і перемістити дані про них. Але також знати, що це таке, коли ти пересуваєшся, - велика справа.
Якщо ми розглянемо моделювання даних у найбільш загальному сенсі, внизу такого типу стека ви маєте файли та бази даних. У вас є елементи даних, у яких є ключі, визначення елементів, псевдоніми, синоніми, конкретні фізичні формати, і тоді у нас є цей шар метаданих.
Цікавим у метаданих є те, що метадані - це цілком те, як дані набувають свого значення. Якщо у вас фактично немає метаданих, то в кращому випадку ви можете здогадатися про значення даних, але у вас виникнуть дуже багато труднощів. Метадані повинні бути там, але значення має структуру. Я не хочу вникати у філософію смислу, але навіть у тому, як ми маємо справу з даними, є багато витонченості в людській думці та людській мові, що не дуже легко виражається в даних. Але навіть з точки зору даних, які ми насправді обробляємо у світі, метадані мають значення і структуру метаданих - один фрагмент даних по відношенню до іншого, і що це означає, коли вони збираються, і що це означає, коли вони ' знову приєднавшись до інших даних, вимагає, щоб ми їх моделювали. Недостатньо просто записувати теги метаданих до речей, ви насправді повинні записувати значення для структур та взаємозв'язок між структурами.
Тоді ми маємо на верхньому шарі бізнес-визначення, яке, як правило, є шаром, який намагається перенести значення між метаданими, що є формою визначення даних, яка відповідає способу організації даних на комп'ютері та людському значенні. Отже, у вас є бізнес-терміни, визначення, відносини, поняття на рівні сутності, які існують у цьому шарі. І якщо ми будемо мати невідповідність між цими шарами, тоді ми повинні мати моделювання даних. Це насправді необов’язково. Чим більше ви можете насправді зробити це в автоматизації, тим краще. Але оскільки це стосується сенсу, чергувати насправді важко. Досить просто зафіксувати метадані в записі і отримати можливість їх отримати з ряду значень, але це не говорить вам про структуру записів або про те, що означають записи або контекст запису.
Отже, саме це, на мій погляд, моделювання даних. Зауважимо: чим складнішим стає Всесвіт даних, тим більше потрібно моделювати його. Іншими словами, це трохи схоже на те, що ми додаємо не просто більше екземплярів речей у світ, що відповідало б записам даних, але ми насправді додаємо світові більше значення, захоплюючи дані про все більше і більше речей. Це стає все більш складним відчуттям, яке ми маємо зрозуміти.
Теоретично існує Всесвіт даних, і нам потрібен погляд на нього. На практиці фактичні метадані є частиною всесвіту даних. Отже, це не проста ситуація. Початок моделювання - зверху вниз та знизу вгору. Потрібно будувати в обох напрямках, і причина цього полягає в тому, що дані мають значення для комп'ютера та процесу, які повинні обробити його, але це має значення саме по собі. Отже, вам потрібне значення знизу вгору, яке задовольняє програмне забезпечення, яке потребує доступу до даних, і вам потрібно сенс зверху вниз, щоб люди могли це зрозуміти. Побудова моделей метаданих не є і ніколи не може бути проектом; це постійна діяльність - має бути постійною діяльністю у будь-якому середовищі, яке вони існують. На щастя, існує багато середовищ, де це насправді не так, і речі виходять з-під контролю.
Ідучи вперед, моделювання зростає з важливістю, коли технологія рухається вперед. Це моя думка. Але якщо подивитися на IoT, ми можемо зрозуміти мобільний більше, ніж ми звикли, хоча введено нові виміри: розмірність місця розташування з мобільним. Як тільки ви потрапили до IoT, ми розглядаємо надзвичайні проблеми з даними, які нам ніколи насправді не доводилося робити, і нам потрібно, так чи інакше, правильно зрозуміти, що ми маємо, як саме ми можемо їх об'єднати, що ми можемо зробити з точки зору отримання сенсу від сукупності, і, звичайно, що ми можемо зробити з ним, коли ми обробимо його.
Я думаю, що це я сказав достатньо. Я перейду до Деса Бланчфілда, який повністю скаже щось інше.
Дез Бланшфілд: Дякую. Завжди потрібно суворий вчинок, але це тема, про яку ми домовились, і про це коротко поговорили у рекламному доступі, і якщо ви набрали на початку, ви, мабуть, зловили цілу купу чудових дорогоцінних каменів. Один із виїздів, і я не хочу вкрасти грім цього конкретного, але один із вивіз з нашого довідника, яким я хочу поділитися, якщо ви цього не спіймали, був лише навколо теми подорож даних, і мене вразило, що я фактично записую її, думаючи про подорож, яку дані здійснюють в іншому контексті поколінь життя - рік, місяці, тиждень, день, година, хвилина, секунда - і контекст навколо цих даних розташований у цьому контексті. Чи я розробник коду, чи я фахівець з даних, і я думаю про структуру та формат і метадані навколо кожного з елементів, або про те, як системи та бізнес взаємодіють з ним.
Це цікавий невеликий випадок просто зазначити, але все одно, дозвольте мені зануритися. Дизайн даних, зокрема, є фразою, яку я використовую, щоб розповісти про всі дані даних, а саме про розробку програм або інфраструктури баз даних. Я думаю, що дизайн даних - це термін, який просто захоплює все це в моїй свідомості. У наші дні, коли ми говоримо про дизайн даних, ми говоримо про сучасний гнучкий дизайн даних, і, на мою думку, не так давно розробники та експерти з даних працювали на самоті; вони були у власних силосах і шматки дизайну переходили від одного силосу до іншого. Але я дуже переконаний у цих днях, що це не лише випадок, який змінився, але він повинен змінитися; це якась необхідність, і це те, що додаток - розробники і все, що можна зробити навколо розробки, що стосується даних, дизайнерів, які роблять відповідні елементи дизайну схем і полів і записів, систем та інфраструктури баз даних та баз даних, моделювання та всього управління виклик навколо цього. Це командний спорт зараз, і отже, моя картина з кулі людей, що вистрибують з літака, виступаючи командою, щоб розіграти цей візуально цікавий образ людей, що падають через небо.
По-третє, що сталося для цього? Що ж, є стаття 1986 року, написана парою джентльменів, імена яких я відчайдушно намагався зробити справедливі, Хіротака Такекучі та Ікуджіро Нонака, я вважаю, що це вимовляється, створив статтю, яку вони назвали "Переміщення Scrum Downfield." ця ідея методології виграти в гру в регбі, що виходить з цього виду діяльності, коли кожен об'їжджається в одному місці, а дві команди, по суті, замикають голови в чомусь, що називається scrum, щоб спробувати отримати контроль над м'ячем і грати вниз по полю дістаньтеся до лінії спробу і торкніться м'яча землею і отримайте очко, що називається трін, і ви повторите цей процес, і ви отримаєте більше очок для команди.
Ця стаття була опублікована в 1986 році в «Гарвардському огляді бізнесу», і цікаво, що насправді вона привернула багато уваги. Він привернув багато уваги, оскільки він представив дивовижні нові поняття, і ось скріншот передньої частини. Таким чином, вони взяли цю концепцію scrum з ігрового регбі, і вони ввели її в бізнес і, особливо, в грі дизайну та доставки проектів, зокрема доставки проектів.
Що робив scrum, це дало нам нову методологію порівняно з подібними PRINCE2 або PMBOK, які ми раніше використовували у тому, що ми називали методологією водоспаду, знаєте, зробіть цю справу та цю штуку та цю річ і дотримуйтесь їх у послідовності та з'єднайте всі точки навколо, що залежить від того, що ви мали, або не робіть частину другу, поки ви не зробите частину першу, оскільки це залежало від першої частини. Це дало нам нову методологію, щоб бути трохи більш гнучким, саме звідси походить цей термін, про те, як ми постачаємо речі, а саме навколо дизайну та розробці низових проектів.
Деякі з основних орендарів - просто так я і продовжую з цим - навколо ключових орендарів Scrum. Він запровадив ідею побудови нестабільності, що ефективно, якщо подумати про страх хаосу, світ існує в стані хаосу, але планета утворилася, що цікаво, тому будуючи нестабільність, здатність трохи відскакувати і все ще фактично змушують справи працювати, самоорганізовуючи проектні команди, перекриваючи переваги через дуже відповідальну розробку, різні типи навчання та контролю через шлях реалізації проекту, організаційну передачу навчання. Тож як ми можемо брати інформацію з однієї частини бізнесу і передавати її в іншу від людей, які мають ідею, але не розробляють код або не розробляють бази даних та інфраструктури, а дані для цих людей? І конкретно визначені за часом результати. Іншими словами, давайте зробимо це протягом певного періоду часу, або через день, як через 24 години, або тиждень, або пару тижнів, і подивимось, що ми можемо зробити, а потім відступимо і подивимось на це.
І тому, якщо ви пробачте за каламбур, це справді нова гра в поданні проекту та три основні компоненти до нього, які матимуть сенс, якщо ми трохи далі пройдемо тут - ось продукт: усі ці люди мають ідею і мають потреба щось зробити і історія, яка їх оточує. Розробники, які працюють в умовах гнучкої моделі отримання своїх історій і через щоденні складання, використовуючи методологію scrum, щоб обговорити це і зрозуміти, що їм потрібно зробити, а потім просто зайти і ввійти в життя і зробити це. Тоді люди, ми чули про майстрів скраму, які наглядають за цією справою і розуміють методологію досить добре, щоб керувати нею. Всі ми бачили ці зображення, які я отримав на правій стороні тут стін та дощок, наповнених примітками Post-It, і вони служили стінами Канбана. Якщо ви не знаєте, хто такий Канбан, я запрошую вас в Google, хто був пан Канбан, і чому це було зміною способу перенесення речей з однієї сторони на іншу в стіні буквально, але в проекті.
На перший погляд, робочий процес scrum робить це: він бере список речей, які організація хоче зробити, виконує їх через низку речей, які ми називаємо спринтами, які розбиваються на 24 години, місячні періоди, і ми отримати цей додатковий ряд результатів. Це суттєво змінило спосіб доставки проектів, доставляли до цього етапу, тому що частина цього потоку подібна американській армії, яка мала велику частину розробки чогось під назвою PMBOK, як ідея, що не вивозить танк у поле поки ти не вкладеш кулі в річ, тому що якщо в полі в баку немає куль, це марно. Отже, частина перша поміщена кулями в танк, частина друга - танк в поле. На жаль, те, що сталося з розробниками у світі розробок, якось засвоїло цю спритну методологію і вибігло з нею, якщо ви простите каламбур, у спринті.
Незмінно те, що сталося, коли ми думаємо про спритний, ми зазвичай думаємо про розробників, а не про бази даних і нічого спільного зі світом баз даних. Це був невдалий результат, адже реальність полягає в тому, що спритний не обмежується розробниками. Насправді, термін спритний, на мою думку, часто неправильно асоціюється виключно з розробниками програмного забезпечення, а не з розробниками баз даних та архітекторами. Незмінно ті самі виклики, з якими ви стикаєтесь у розробці програмного забезпечення та додатків, пов'язані з усім дизайном, розробкою, експлуатацією та технічним обслуговуванням, а отже, інфраструктурою даних і особливо базами даних. Діячі цього конкретного опису даних включають в себе подібні архітектори даних, формувачі, адміністратори, менеджери інфраструктури баз даних і самі фактичні бази даних аж до бізнес-систем і аналітиків та архітекторів, людей, які сидять і думають про те, як працюють системи і ділових операцій, і як ми отримали передачу даних через них.
Це тема, яку я регулярно піднімаю, тому що це моє постійне розчарування в тому, що я дуже вважаю, що спеціалісти з даних повинні - не повинні - тепер повинні активно брати участь у кожній складовій реалізації проекту, насправді, особливо в розвитку. Якщо ми цього не зробимо, то ми справді не даємо собі найкращих шансів на гарний результат. Нам часто доводиться кружляти назад і подумати над цими речами, тому що існує сценарій, ми переходимо до програми, яка будується, і ми виявляємо, що розробники не завжди є фахівцями з даних. Робота з базами даних вимагає дуже спеціалізованих навичок, особливо навколо даних, та створює досвід. Ви не просто моментально стаєте гуру бази даних або експертом із знань даних; це часто щось, що випливає з життєвого досвіду, і, звичайно, з подібними докторами Робіном Блором із програми «Кодекс сьогодні», який досить багато написав книгу.
У багатьох випадках - і це прикро, але це реальність - що є дві частини цієї монети, тобто розробники програмного забезпечення мають власне затемнення щодо спеціаліста по базі даних і вбудували необхідні навички моделювання дизайну баз даних, і розробка моделі була лише основоположне для інженерії гуру про те, як надходять дані та як відбувається організація подорожі, яку вона здійснює, і як вона повинна чи не повинна виглядати, або, безсумнівно, що вона поглинається і розуміння того, що це отримується зазвичай у вітчизняних навичках, визначених розробниками програмного забезпечення. І деякі спільні проблеми, з якими ми стикаємось, лише для того, щоб поставити це в контексті, включають в себе просто основне створення та обслуговування та управління базовим дизайном базової бази даних, документування даних та інфраструктури бази даних, а потім повторне використання цих даних, схеми, покоління схем, адміністрування та підтримка схеми та їх використання, обмін знаннями, чому ця схема розроблена певним чином, а сильні та слабкі сторони, які виникають із цим, з часом спричиняють зміни даних у часі, моделювання даних та типи моделей, які ми застосовуємо до систем та даних, які ми передаємо через них. Генерація коду бази даних, і вона продовжує інтегрувати, а потім моделювати дані навколо них, а потім швидше отримувати доступ до контролю безпеки навколо даних, цілісність даних - ми переміщуємо дані навколо, коли ми зберігаємо цілісність, чи достатньо метаданих навколо це, чи повинні продажі бачити всі записи в таблиці або вони повинні бачити лише адресу, ім'я та прізвище, які надсилають вам речі в пошті? І, звичайно, найбільшим викликом є те, що моделювання платформ баз даних - це сама по собі інша розмова.
Я дуже вважаю, що маючи на увазі, щоб зробити будь-яку з цих нірван можливою, абсолютно важливо, щоб і спеціалісти з даних, і розробники мали відповідні інструменти, і щоб ці інструменти могли бути спроможними для командної реалізації проектів, проектування, розробка та поточне експлуатаційне обслуговування. Знаєте, такі речі, як співпраця в проектах між експертами з даних та розробниками програмного забезпечення, єдина точка істини або єдине джерело істини для всіх речей навколо документації самих баз даних, даних, схем, звідки беруться записи, власники цих записів . Я думаю, що в цей день і вік це абсолютно критично, ми збираємося отримати цю нірвану даних, що є королем, що потрібні правильні інструменти, тому що зараз завдання надто велике для нас, щоб це робити вручну, і якщо люди переходити та виходити з однієї організації, нам занадто легко не дотримуватися того самого процесу чи методології, що одна людина може створити, які є хорошими, і не обов'язково передавати ті вміння та можливості, які рухаються вперед.
Зважаючи на це, я збираюся звернутися до нашого доброго друга в IDERA і почути про цей інструмент і про те, як він вирішує ці речі.
Рон Хуйзенга: Дякую вам велике і дякую і Робіну, і Дезу за те, що дійсно добре поставили сцену, і ви збираєтесь побачити трохи перекриття в парі, про яку я говорив. Але вони дійсно поставили дуже міцну основу для деяких концепцій, про які я буду говорити з точки зору моделювання даних. І багато речей, про які вони говорили, перегукуються з моїм власним досвідом, коли я був консультантом, який працював з моделювання даних та архітектури даних, разом з командами - як водоспад в перші дні, так і перетворювався на більш сучасні продукти з проектами, де ми використовували спритність методології надання рішень.
Тож, про що я сьогодні поговорю, ґрунтується на цьому досвіді, а також на погляді на інструменти та деякі можливості інструментів, які ми використовуємо, щоб допомогти нам у цій дорозі. Те, що я висвітлю дуже коротко, це те, що я не збираюся детально розбиратись у сутичках; у нас просто був справді хороший огляд того, що це таке. Я збираюся поговорити про це з точки зору, що таке модель даних і що вона насправді означає? І як ми вмикаємо концепцію спритного моделера даних в наших організаціях, з точки зору того, як ми залучаємо моделерів даних, яка участь моделерів та архітекторів під час спринту, якими видами діяльності слід займатися. і, як наслідок цього, які кілька важливих можливостей інструменту моделювання, які ми використовуємо, дійсно допомагають полегшити цю роботу? Тоді я збираюся трохи підвести підсумок і просто поговорять трохи про деякі ділові цінності та переваги участі у роботі з моделером даних, або про те, як я фактично збираюся розповісти історію, проблеми з тим, що модельєр даних не повністю залучається до проектів, і я покажу вам, що ґрунтується на досвіді та графіку дефектів до і після зображення фактичного проекту, з яким я брав участь багато років тому. І тоді ми підведемо підсумки ще кількох пунктів, а потім матимемо додаткові запитання та відповіді.
Коротше кажучи, ER Studio - це дуже потужний набір, який містить у собі безліч різних компонентів. Архітектор даних - саме тут моделювачі даних та архітектори проводять більшу частину свого часу, займаючись моделюванням даних. Також є інші компоненти, про які ми сьогодні не збираємося говорити, наприклад, Business Architect, де ми робимо моделювання процесів та Software Architect, для деяких моделей UML. Потім є Репозиторій, де ми реєструємось і ділимось моделями, і ми дозволяємо командам співпрацювати над ними та публікувати їх на командному сервері, щоб багато аудиторій зацікавлених сторін, які беруть участь у проекті, насправді бачили артефакти, які ми ' створити з точки зору даних, а також інші речі, які ми робимо в самій реалізації проекту.
Те, на що я буду сьогодні зосереджуватися, - це декілька речей, які ми побачимо з архітектора даних, і тому що це дуже важливо, щоб ми мали співпрацю з аспектами, що базуються на репозиторіях. Особливо, коли ми починаємо говорити про такі поняття, як управління змінами, які вкрай необхідні не тільки гнучким проектам розвитку, але й будь-якому типу розвитку, що йде вперед.
Тож поговоримо на хвилину про Agile Data Modeler. Як ми вже згадували раніше в презентації, це те, що нам важливо, щоб у нас були модельєри даних та / або архітектори, повністю задіяні в процесах гнучкої розробки. Тепер, що сталося історично, так, так, ми дійсно думали про спритний з точки зору розвитку, і є кілька речей, які продовжувались, що насправді спричинило це до виникнення. Частина його була обумовлена якраз характером того, як розгортався сам розвиток. Коли починалася спритна розробка, і ми починали цю концепцію команд, що самоорганізуються, якщо ви пили Kool-Aid трохи занадто чисто і ви були на стороні екстремальної програми, виникла дуже буквальна інтерпретація таких речей, як Команди, що самоорганізовуються, що багато людей трактували, означає, що все, що нам потрібно, - це група розробників, яка може створити ціле рішення. Чи це означає розробку коду, баз даних або сховищ даних за ним, і все було передано розробникам. Але що з цим трапляється, ви втрачаєте особливі здібності, якими володіють люди. Я виявив, що найсильніші команди - це люди, що складаються з людей різного походження. Такі як поєднання сильних розробників програмного забезпечення, архітекторів даних, моделерів даних, бізнес-аналітиків та бізнес-зацікавлених сторін, які працюють разом, щоб досягти кінцевого рішення.
Те, про що я сьогодні також говорю, - це я збираюся зробити це в контексті проекту розвитку, де ми розробляємо додаток, який, очевидно, також має пов'язаний з ним компонент даних. Нам потрібно зробити крок назад, перш ніж робити це, тому що нам потрібно усвідомити, що існує дуже мало проектів розвитку Грінфілда там, де ми зосереджуємось на створенні та споживанні даних, обмежених лише в рамках самого проекту розвитку. . Нам потрібно зробити крок назад і подивитися на загальну організаційну точку зору з точки зору даних та з точки зору процесу. Тому що, що ми з’ясуємо, це інформація, яку ми використовуємо, може вже існувати десь в організаціях. Як модельєри та архітектори ми доводимо це до світла, тому ми знаємо, звідки джерела цієї інформації в самих проектах. Ми також знаємо структури даних, які беруть участь, оскільки у нас є шаблони дизайну так само, як розробники мають шаблони дизайну свого коду. І нам також потрібно прийняти цю загальну організаційну точку зору. Ми не можемо просто розглядати дані в контексті програми, яку ми будуємо. Нам потрібно моделювати дані та переконуватись у тому, що ми їх документуємо, оскільки вони живуть далеко за межами самих програм. Ці програми надходять та йдуть, але нам потрібно вміти переглядати дані та переконатися, що вони надійні та добре структуровані не лише для застосування, але й для рішень, які звітують про діяльність, звітування про BI та інтеграцію до інших програм, внутрішніх та зовнішні для наших організацій. Тому нам потрібно переглянути всю цілу картину даних і те, що таке життєвий цикл цих даних, і зрозуміти подорож інформації по всій організації від колиски до могили.
Повернувшись до самих команд, і як нам насправді потрібно працювати, методологія водоспаду сприймалася як занадто повільна, щоб дати результати. Тому що, як вказувалося на прикладі танків, це робилося один крок за іншим, і це часто забирало занадто багато часу, щоб забезпечити справний кінцевий результат. Що ми робимо зараз, нам потрібно мати ітеративний стиль роботи, де ми поступово розробляємо його компоненти та розробляємо його протягом часу, коли ми виробляємо корисний код або корисні артефакти, я хочу сказати, для кожного спринту. Важливим є співпраця між технічними зацікавленими сторонами в команді та бізнес-зацікавленими сторонами, оскільки ми співпрацюємо, щоб вивести ці історії користувачів на бачення коду та даних, що також підтримують цей код. І сам Agile Data Modeler часто виявить, що у нас недостатньо моделерів в організаціях, тому один модельєр даних або архітектор можуть одночасно підтримувати кілька команд.
І інший аспект цього полягає в тому, що навіть якщо у нас є кілька моделей, ми повинні переконатися, що у нас є набір інструментів, який ми використовуємо, що дозволяє співпрацювати декілька проектів, які перебувають в польоті одночасно, і обмінюватися ними артефакти даних та можливості реєстрації та виїзду. Я перейду до цього дуже швидко, оскільки ми вже висвітлювали це в попередньому розділі. Справжня передумова гнучкості полягає в тому, що ви базуєте речі на відсталі, історії або вимоги. В рамках ітерацій ми співпрацюємо як група. Зазвичай двотижневий або одномісячний спринт, залежно від організації, дуже поширений. А також щоденні огляди та засідання, щоб ми усунули блокатори та переконалися, що ми рухаємо всі аспекти вперед, не зупиняючись у різних областях, коли ми проходимо. І в цих спринтах ми хочемо переконатися, що ми виробляємо корисні товари як частину кожного спринту.
Просто трохи по-іншому сприймати це, розширюючи його далі, scrum - це методологія, про яку я розповім тут більш конкретно, і ми в основному доповнили цю попередню картину ще кількома іншими аспектами. Зазвичай є відставання товару, а потім - спринт. Таким чином, ми маємо загальний відставання, що на початку кожного повторного спринту ми готові сказати: "Що ми будемо будувати цей спринт?", І це робиться на зустрічі планування спринту. Потім ми розбиваємо завдання, які пов'язані з цим, і ми виконуємо в цих одно-чотирьох тижневих спринтах з цими щоденними оглядами. Коли ми робимо це, ми відстежуємо наш прогрес за допомогою діаграм згоряння та діаграм згоряння, щоб відстежувати, що ще потрібно створити, порівняно з тим, що ми будуємо, щоб встановити такі речі, як швидкість нашого розвитку, чи будемо ми робити свій графік, усі ці речі. Все це розробляється постійно під час спринту, а не їхати кілька місяців вниз і з'ясувати, що ви збираєтесь прийти недовго і вам потрібно продовжити графік проекту. І дуже важливо, як частина його, всі команди, є огляд спринту в кінці та ретроспектива спринту, тому перед тим, як розпочати наступну ітерацію, ви переглядаєте, що зробили, і шукаєте шляхи, які зможете покращити в наступний раз.
Що стосується результатів, це в основному слайд, який підсумовує типові типи речей, які продовжуються у спринтах. І це дуже орієнтоване на розвиток, тому багато речей, які ми бачимо тут, як, наприклад, функціональні конструкції та випадки використання, роблячи тести кодового дизайну, коли ми дивимось ці скриньки тут, і я не збираюся їх проходити в будь-якому рівні деталізації вони дуже орієнтовані на розвиток. І тут поховано той факт, що нам також потрібно мати ці дані, які йдуть на руку, щоб підтримати ці зусилля. Тож кожен раз, коли ми бачимо такі речі, як відставання, вимоги та історії користувачів, під час перегляду нам потрібно переглянути, які розробки ми повинні зробити, які аналітичні матеріали нам потрібно зробити, як щодо дизайн даних або модель даних, що робити з такими речами, як бізнес-словники, щоб ми могли пов’язати діловий сенс з усіма артефактами, які ми виробляємо? Тому що нам потрібно виробляти ці корисні результати у кожному спринті.
Деякі люди скажуть, що нам потрібно створити корисний код в кінці кожного спринту. Це не обов'язково так, це є в найчистішій перспективі розвитку, але досить часто - особливо на початку - ми можемо мати щось на кшталт нуля спринту, де ми зосереджені суто на стоячих речах, роблячи такі речі, як отримання наших тестових стратегій місце. Дизайн високого рівня, щоб розпочати його, перш ніж ми почнемо заповнювати деталі та переконайтесь, що у нас є чистий набір початкових історій чи вимог, перш ніж ми розпочнемо залучати інші аудиторії, а потім будувати вперед як команда, коли ми йдемо вперед. Завжди небагато часу на підготовку, тому досить часто у нас буде спринт нуля або навіть нуля спринту та одиниці. Можливо, це буде трохи початковою фазою, перш ніж ми вдамося до повного польоту при наданні рішення.
Давайте поговоримо про моделі даних у цьому контексті дуже коротко. Коли люди думають про моделі даних, вони часто думають про модель даних як про картину того, як різні частини інформації з’єднуються разом - це лише верхівка айсберга. Щоб повністю втілити дух того, як ви дійсно хочете підходити до моделювання даних - чи то в гнучкому розвитку та інших речах - чи потрібно вам усвідомити, що модель даних, якщо вона зроблена правильно, стає вашою повною специфікацією того, що ці дані означають в організації та як вона розгорнута в задніх базах даних. Коли я кажу про бази даних, я маю на увазі не лише реляційні бази даних, якими ми можемо користуватися, але і в сучасних архітектурах, де у нас є великі платформи даних або NoSQL, як я вважаю за краще їх називати. Також ці великі сховища даних, тому що ми можемо поєднувати безліч різних сховищ даних з точки зору споживання інформації та залучення її до наших рішень, а також того, як ми зберігаємо та зберігаємо цю інформацію також із наших рішень.
Ми можемо працювати з декількома базами даних або джерелами даних одночасно в контексті даної програми. Що дуже важливо, ми хочемо мати повну специфікацію, тому логічна специфікація того, що це означає для спринтської організаційної точки зору, які фізичні конструкції є з точки зору того, як ми насправді визначаємо дані, зв’язки між ними ваших баз даних, ваших референтних обмежень цілісності, перевірки обмежень, усіх тих фрагментів перевірки, про які ти зазвичай думаєш. Описові метадані є надзвичайно важливими. Як ви знаєте, як використовувати дані у своїх програмах? Якщо ви не можете визначити це і не знати, що це означає, або знати, звідки воно з’явилося, щоб переконатися, що ви використовуєте правильні дані в цих додатках - переконайтеся, що у нас є правильні умови іменування, повні визначення, що означає повний словник даних не тільки таблиці, але стовпці, які містять ці таблиці, - і детальні примітки щодо розгортання того, як ми це використовуємо, тому що нам потрібно створити цю базу знань, тому що навіть коли ця програма буде виконана, ця інформація буде використана для інших ініціатив, тому нам потрібно переконатися що у нас є все це документально підтверджено для майбутніх втілень.
Знову ми переходимо до таких речей, як типи даних, ключі, індекси, сама модель даних уособлює безліч ділових правил. Відносини - це не просто обмеження між різними таблицями; вони часто допомагають нам описати, які справжні правила бізнесу полягають у тому, як вони ведуть себе та як вони працюють разом як згуртований підрозділ. І звичайно, ціннісні обмеження дуже важливі. Звичайно, одна з речей, з якими ми постійно маємо справу, і вона стає все більш поширеною, - це такі як управління даними. Отже, з точки зору управління даними, ми також повинні дивитися, що ми тут визначаємо? Ми хочемо визначити такі речі, як класифікації безпеки. З якими типами даних ми маємо справу? Що буде вважатися основним управлінням даними? Які транзакційні магазини ми створюємо? Які референтні дані ми використовуємо в цих додатках? Нам потрібно переконатися, що він належним чином відображений у наших моделях. А також щодо якості даних, є певні відомості, які важливіші для організації, ніж інші.
Я брав участь у проектах, де ми замінювали понад десяток застарілих систем на нові бізнес-процеси та розробляли нові програми та сховища даних для їх заміни. Нам потрібно було знати, звідки надходить інформація. Що стосується найважливіших відомостей, з точки зору бізнесу, якщо ви подивитеся на цей слайд конкретної моделі даних, який я отримав тут, ви побачите, що внизу в цих конкретних сутностях, що є лише невеликим підмножиною, я Ви насправді змогли визначити цінність бізнесу. Будь високий, середній чи низький для цих типів речей для цих різних конструкцій в організації. І я також захопив такі речі, як майстер-класи класів даних, чи це майстер-таблиці, чи вони є довідковими, чи були транзакційними. Таким чином, ми можемо розширити наші метадані в наших моделях, щоб дати нам безліч інших характеристик поза самими даними, що насправді допомогло нам з іншими ініціативами поза оригінальними проектами та перенести їх уперед. Тепер, коли в одному слайді було багато, я пройду решту цих досить швидко.
Зараз я дуже швидко поговорю про те, що робить модельєр даних, коли ми переживаємо ці різні спринти. Перш за все, повноправний учасник сеансів планування спринту, де ми беремо розповіді користувачів, беремося до того, що ми збираємося поставити у цьому спринті, і з'ясовуємо, як ми будемо його структурувати та доставляти. Те, що я також роблю як модельєр даних, - це я знаю, що буду працювати в окремих областях з різними розробниками або з різними людьми. Отже, однією з важливих характеристик, яку ми можемо мати, є те, що ми робимо модель даних, і ми можемо розділити цю модель даних на різні погляди, незалежно від того, називаєте ви їх предметними областями чи підмоделями, - це наша термінологія. Оскільки ми будуємо модель, ми також демонструємо її в цих різних перспективах субмоделі, тому різні аудиторії бачать лише те, що для них важливо, щоб вони могли сконцентруватися на тому, що вони розробляють та висувають. Тож у мене може бути хтось, хто працює над плануванням частини програми, я можу мати когось іншого, який працює над записом замовлення, де ми робимо всі ці речі в одному спринті, але я можу дати їм точки зору через ті підмоделі, які лише стосуються області, над якою вони працюють. А потім вони підходять до загальної моделі та всієї структури підмоделей, щоб дати різній аудиторії уявлення про те, що їм потрібно бачити.
Основи з точки зору моделювання даних, які ми хочемо мати, - це завжди мати базову лінію, до якої ми можемо повернутися, тому що одна з речей, яку нам потрібно вміти, - чи то в кінці спринту, чи в кінці з декількох спринтів, ми хочемо знати, з чого ми почали, і завжди є основна лінія, щоб знати, що було дельтою або різницею того, що ми виробляли в даному спринті. Нам також потрібно переконатися, що ми можемо мати швидкий поворот. Якщо ви ввійдете в нього як модельєр даних, але в традиційній ролі воротаря, кажучи: «Ні, ні, ви не можете цього зробити, ми повинні зробити це все спочатку», ви будете виключені з команди, коли вам справді потрібно бути активним учасником всіх цих спритних команд розвитку. Це означає, що деякі речі падають з вагона, роблячи даний спринт, і ви підбираєте їх у наступних спринтах.
Як приклад, ви можете зосередитись на структурах даних лише для того, щоб розробити, скажімо, ту частину введення замовлення, про яку я говорив. У наступному спринті ви можете повернутися і заповнити дані, як-от частина документації для словника даних навколо деяких артефактів, які ви створили. Ви не збираєтесь виконувати це визначення все в одному спринті; Ви збираєтесь продовжувати свою роботу поступово, тому що буде час, коли Ви зможете заповнити цю інформацію, працюючи з бізнес-аналітиками, коли розробники зайняті створенням програм та наполегливістю навколо цих сховищ даних. Ви хочете полегшити, а не бути вузьким місцем. Існують різні способи роботи з розробниками. Для деяких речей у нас є шаблони дизайну, тому ми є повноцінним учасником, тому ми можемо мати шаблон дизайну, де ми будемо говорити, що ми вкладемо його в модель, ми висунемо її до баз даних розробників, і тоді вони можуть почати працювати з ним і вимагати змін до цього.
Можливо, існують інші сфери, над якими розробники працювали, у них є щось над тим, над чим вони працюють, і вони прототипують деякі речі, щоб вони спробували деякі речі у власному середовищі розробки. Ми беремо цю базу даних, з якою вони працювали, вносимо її до нашого інструменту моделювання, порівнюємо з моделями, які ми маємо, а потім вирішуємо і висуваємо зміни до них, щоб вони могли переробити коди, щоб вони слідували правильній структурі даних що нам потрібно. Оскільки вони, можливо, створили деякі речі, які ми вже мали деінде, тому ми переконуємось, що вони працюють з правильними джерелами даних. Ми просто продовжуємо повторювати цей шлях до нашого спринту, щоб ми отримали повний доступ до даних, повну документацію та визначення всіх тих структур даних, які ми виробляємо.
Найуспішніші гнучкі проекти, до яких я брав участь в дуже хороших поставках, це те, що ми мали філософію, моделювали всі зміни до повної специфікації фізичної бази даних. По суті, модель даних стає розгорнутими базами даних, з якими ви працюєте, для чогось нового, що ми створюємо, і має повні посилання на інші сховища даних, якщо ми використовуємо їх з інших зовнішніх баз даних. В рамках цього ми виробляємо додаткові сценарії, а щоразу робимо повне покоління. І ми використовуємо наші дизайнерські шаблони, щоб зробити це швидким підйомом з точки зору того, щоб справи рухалися спринтами з різними командами розвитку, з якими ми працюємо.
У спринтерській діяльності також знову є базовою для порівняння / злиття, тому давайте взяти ідею моделювання кожної зміни. Кожен раз, коли ми робимо зміни, ми хочемо моделювати зміни, і що дуже важливо, чого не було в моделюванні даних до недавнього часу, насправді, поки ми не ввели її знову, це можливість асоціювати моделювання. завдання та результати роботи з історіями користувачів та завданнями, які фактично спричиняють ці зміни. Ми хочемо мати можливість перевіряти зміни в нашій моделі, так само, як розробники перевіряють свої коди, посилаючись на ті історії користувачів, які ми маємо, тому ми знаємо, чому ми вносили зміни в першу чергу, це те, що ми робимо. Коли ми це робимо, ми генеруємо наші додаткові сценарії DDL та розміщуємо їх, щоб їх можна було взяти за допомогою інших результатів розробки та перевірити в нашому рішенні збірки. Знову ж таки, ми можемо мати одну модель або працювати з декількома командами. І як я вже розповідав, деякі речі створені модельєром даних, інші - розробниками розробників, і ми зустрічаємось посередині, щоб придумати найкращий дизайн і підштовхнути його вперед та переконатися, що він правильно розроблений в нашому загальні структури даних. Ми повинні дотримуватися дисципліни щодо забезпечення у нас усіх належних конструкцій у нашій моделі даних під час руху вперед, включаючи такі речі, як нульові, а не нульові значення, референсні обмеження, в основному перевіряти обмеження, всі ті речі, про які ми зазвичай думаємо .
Давайте поговоримо про декілька скріншотів деяких інструментів, які допомагають нам це робити. Я думаю, що важливо - це спільне сховище, тому те, що ми можемо зробити як модельєри даних - а це фрагмент частини моделі даних на задньому плані - це коли ми працюємо над речами, які хочемо переконатися, що ми можемо працюємо лише над об’єктами, які нам потрібно мати можливість змінювати, вносити модифікації, генерувати наші сценарії DDL для змін, які ми внесли під час перевірки речей. Отже, що ми можемо зробити, це в ER Studio - це приклад, ми можемо перевірити об’єкти або групи об’єктів, над якими працювати, нам не потрібно перевіряти цілу модель чи підмодель, ми можемо перевірити лише ті речі, які нас цікавлять. Те, що ми хочемо після цього, є або після виїзду, або заїзду - ми робимо це обома способами, оскільки різні команди розвитку працюють по-різному. Ми хочемо переконатися, що ми пов’язуємо це з історією користувача або завданням, що визначає вимоги до цього, і це буде та сама історія користувача або завдання, яке розробники розроблять і перевіряють свій код.
Отже, ось дуже швидкий фрагмент пари екранів одного з наших центрів управління змінами. Що це робить, я не збираюсь детально описувати тут деталі, але те, що ви бачите, це історія користувача або завдання і з відступом під кожним із тих, кому ви бачите фактичні записи змін - ми створили автоматизований запис змін, коли ми робимо реєстрацію та виїзд, і ми можемо також додати більше опису щодо цієї зміни змін. Це пов'язано із завданням, ми можемо мати кілька змін на завдання, як ви очікували. І коли ми переходимо до цього запису змін, ми можемо переглянути його і, що ще важливіше, побачити, що ми насправді змінили? Для цієї конкретної, висвітленої історії там у мене відбувся один тип змін, і коли я переглянув сам фактичний запис про зміни, він визначив окремі фрагменти моделі, яка змінилася. Я змінив тут пару атрибутів, перевповнив їх, і це принесло для їзди погляди, які потрібно змінити, які залежать від них, щоб вони були породжені в додатковій DLL. Це не тільки моделювання на базових об'єктах, але і потужний інструмент моделювання, подібний до цього, також виявляє зміни, які повинні бути переплетені через залежні об'єкти в базі даних або моделі даних.
Якщо ми працюємо з розробниками, і робимо це в декількох різних речах, тобто робимо щось у їх пісочниці, і ми хочемо порівняти і побачити, де є відмінності, ми використовуємо можливості порівняння / об’єднання, де справа і зліва сторона. Ми можемо сказати: "Ось наша модель зліва, ось їх база даних з правого боку, покажіть мені відмінності". Потім ми можемо вибрати і вибрати спосіб вирішення цих відмінностей, чи засуваємо ми в базу даних, чи якщо У базі даних є деякі речі, які ми повертаємо до моделі. Ми можемо перейти в двонаправлену сторону, щоб ми могли рухатися в обох напрямках одночасно, оновлюючи джерело та ціль, а потім виробляти додаткові сценарії DDL для розгортання цих змін у самому середовищі бази даних, що є надзвичайно важливим. Що ми також можемо зробити, ми також можемо використовувати цю можливість порівняння та злиття в будь-який момент часу, якщо ми робимо знімки на шляху, ми завжди можемо порівняти початок одного спринту для початку або закінчення іншого спринту, щоб ми могли бачити повна інкрементальна зміна того, що було зроблено в заданому розвитку спринту або над серією спринтів.
Це дуже швидкий приклад альтер-скрипту, кожен із вас, хто працював з базами даних, побачив подібний тип речей. Це те, що ми можемо виштовхнути з коду як сценарій зміни, щоб ми переконалися, що ми зберегти тут речі. Те, що я витягнув звідси, щоб зменшити безлад, це те, що ми також робимо з цими сценаріями змін. Ми припускаємо, що в цих таблицях також є дані, тому ми також будемо генерувати DML, який витягуватиме інформацію з тимчасових таблиць і а також повернути його в нові структури даних, тому ми розглядаємо не тільки структури, але й дані, які, можливо, вже містяться в цих структурах.
Ми дуже швидко поговоримо про автоматизовані системи побудови, тому що, коли ми робимо гнучкий проект, досить часто ми працюємо з автоматизованими системами побудови, де нам потрібно перевіряти різні результати, щоб переконатися, що ми не порушуємо свої складання. Це означає, що ми синхронізуємо результати, ті скрипти змін, про які я говорив із сценарієм DDL, повинні бути зареєстровані, відповідний код програми потрібно перевірити одночасно, і багато розробників зараз, звичайно, ні. що робиться з прямим SQL проти баз даних і подібного типу. Досить часто ми використовуємо стійкі рамки або будуємо послуги передачі даних. Нам потрібно переконатися, що зміни для цих фреймворків чи послуг перевіряються точно в той самий час. Вони входять в автоматизовану систему збирання в деяких організаціях, і якщо збірка ламається, в умовах гнучкої методології, це все, що стосується виправлення колоди, що будується, перш ніж рухатися вперед, щоб ми знали, що у нас є робоче рішення, перш ніж йти далі. І одним із проектів, в якому я брав участь, ми довели це до крайності - якщо збірка зламалася, ми насправді приєднали до декількох комп'ютерів у нашому районі, де ми були розміщені з діловими користувачами, у нас були просто червоні миготливі ліхтарі як вершина поліцейських машин. І якщо збірка зламалася, ці червоні миготливі вогні почали згасати, і ми знали, що це все на палубі: виправити збірку, а потім продовжити те, що ми робимо.
Я хочу поговорити про інші речі, і це унікальна можливість ER Studio, це дійсно допомагає, коли ми намагаємось створити ці артефакти як розробники для цих меж постійності, у нас є концепція, що називається об'єктами бізнес-даних, і що дозволяє нам робити, якщо ви подивитеся на цю дуже спрощену модель даних як приклад, вона дозволяє нам інкапсулювати сутності або групи сутностей, де межі стійкості. Де ми, як модельєр даних, можемо придумати щось подібне до заголовка замовлення на купівлю та вирівнювання замовлення та інших детальних таблиць, які б зв'язали це з тим, як ми його розробляємо, і наші розробники служб передачі даних повинні знати, як все зберігається для цих різних даних споруди. Наші розробники думають про такі речі, як замовлення на купівлю як загальний об'єкт, і який їх договір з тим, як вони створюють саме ці об'єкти. Ми можемо розкрити цю технічну деталь, щоб люди, що будують сервери даних, бачили, що знаходиться під нею, і ми можемо захистити інших аудиторій від складності, щоб вони просто побачили різні об'єкти вищого рівня, що також дуже добре працює для спілкування з бізнесом аналітики та бізнес-зацікавлені сторони, коли ми говоримо також про взаємодію різних бізнес-концепцій.
Приємно в тому, що ми також конструктивно розширюємо та згортаємо їх, щоб ми могли підтримувати зв’язки між об'єктами вищого порядку, навіть якщо вони походять від конструкцій, які містяться в самих цих об'єктах бізнес-даних. Тепер, як модельєр, діставайся до кінця спринту, наприкінці завершення спринту, у мене є багато речей, які мені потрібно зробити, які я називаю домашнім господарством для наступного спринту. Кожен спринт, який я створюю, називаю Named Release, - це дає мені мою основу для того, що я маю в кінці релізу. Отже, це означає, що моя основна лінія рухається вперед, всі ці базові лінії або Named Releases, які я створюю і зберігаю у своєму сховищі, я можу використовувати для порівняння / об'єднання, щоб я міг завжди порівнювати з будь-яким заданим кінцем спринту з будь-якого іншого спринту, який дуже важливо знати, які зміни були у вашій моделі даних під час її подорожі.
Я також створюю дельта-сценарій DDL, використовуючи порівняння / злиття знову від початку до кінця спринту. Можливо, я перевірив цілу купу інкрементальних сценаріїв, але якщо мені це потрібно, тепер у мене є сценарій, який я можу розгорнути для встановлення інших пісочниць, тому я можу просто сказати, що це ми мали на початку одного спринту, push це через, створити базу даних як пісочницю, щоб почати з наступного спринту, і ми також можемо використовувати ці речі, щоб робити такі речі, як екземпляри резервного QA, і, зрештою, ми, звичайно, хочемо висунути наші зміни у виробництво, щоб у нас було багато речей. в той самий час. Знову ж таки, ми повністю беремо участь у спринтерському плануванні та ретроспективах, ретроспективи - це справді засвоєні уроки, і це надзвичайно важливо, адже ви можете швидко рухатися під час спритного, вам потрібно зупинитися та відсвяткувати успіхи, як зараз. З'ясуйте, що не так, зробіть краще наступного разу, але також відзначте те, що пішло правильно, і будуйте на них, коли ви продовжуєте рухатися вперед у наступних спринтах, що рухаються вперед.
Зараз я дуже швидко поговорю про цінність бізнесу. Був проект, до якого я долучився багато років тому, який розпочався як спритний проект, і це був екстремальний проект, тому це була чиста команда, що самоорганізовувалась, де саме займалися розробники. Якщо коротко сказати, цей проект затримувався, і вони виявляли, що витрачають все більше і більше разів на виправлення та виправлення виявлених дефектів, ніж на висунення більшої функціональності, і насправді, коли вони дивилися на це на основі на згорілих діаграмах вони повинні були продовжити проект на шість місяців величезною вартістю. І коли ми розглянули це, спосіб усунення проблеми полягав у використанні належного інструменту моделювання даних із кваліфікованим модельєром даних, залученим до самого проекту.
Якщо ви дивитесь на цю вертикальну смугу на цьому конкретному графіку, це відображає кумулятивні дефекти проти кумулятивних об’єктів, і я кажу про об’єкти даних або конструкції, які були створені, такі як таблиці з обмеженнями та ті типи речей, якщо ви подивилися до введення в дію моделера даних кількість дефектів фактично перевищувала і починала створювати трохи розриву над фактичною кількістю об'єктів, що були вироблені до цього моменту. Після 21 тижня, тобто коли з'явився моделер даних, відновив модель даних на основі того, що потрібно було виправити в ряді речей, а потім почав моделювати, як частина проектної команди, яка рухається вперед, зміни, які цей проект висуваються вперед . І ви побачили дуже швидкий поворот, що протягом приблизно півтора спринту ми побачили величезний зміст у кількості об'єктів та конструкцій даних, які створюються та будуються, тому що ми генерувались із інструменту моделювання даних, а не з палички розробника будуючи їх у середовищі, і вони були правильні, оскільки мали належну референтну цілісність та інші конструкції, які вона мала мати. Рівень дефектів відносно майже рівних. Вживши відповідних заходів і переконавшись, що моделювання даних було повністю задіяне, проект був здійснений вчасно з набагато вищим рівнем якості, і насправді він не був би виконаний, якби ці кроки не відбулися. Там дуже багато спритних невдач, також є багато спритних успіхів, якби ви залучили потрібних людей у правильних ролях. Я величезний прихильник спритності як оперативної дисципліни, але вам потрібно переконатися, що ви володієте навичками всіх правильних груп, які беруть участь як ваші команди проекту, коли ви рухаєтесь вперед по спритному напрямку.
Підводячи підсумок, архітектори даних та модельєри повинні бути залучені до всіх проектів розвитку; вони справді є тим клеєм, який поєднує все разом, тому що ми, як модельєри даних та архітектори, ми розуміємо не тільки конструкції даних даного проекту розвитку, але і те, де дані існують в організації, і де ми можемо джерело цих даних, а також як їх буде використовуватися і використовуватись поза конкретним додатком, над яким ми працюємо. Ми розуміємо складні взаємозв'язки даних, і першорядно, щоб можна було рухатись вперед, а також з точки зору управління, щоб відобразити документ і зрозуміти, як виглядає ваш повний пейзаж даних.
Це як виробництво; Я походив із виробництва. Ви не можете перевірити якість на щось в кінці - вам потрібно вдосконалити якість свого дизайну вперед та на шляху, а моделювання даних - це спосіб вбудувати цю якість в дизайн ефективно та економічно. . І знову, що слід пам’ятати - і це не варто банально, але це правда - програми надходять та йдуть, дані є найважливішим корпоративним активом, і це переходить усі ці межі програми. Кожен раз, коли ви вводите програму, вам, ймовірно, пропонується зберегти дані з інших програм, які були раніше, тому нам просто потрібно пам’ятати, що це життєво важливий корпоративний актив, який ми постійно підтримуємо.
І це все! Звідси ми візьмемо більше запитань.
Ерік Кавана: Добре, добре, дозвольте спочатку передати це Робіну. І тоді, Дез, я впевнений, у тебе є кілька питань. Забирай це, Робін.
Доктор Робін Блор: Гаразд. Якщо чесно, я ніколи не мав жодних проблем із спритними методами розвитку, і мені здається, що ви тут робите, має видатний сенс. Я пам’ятаю, що дивився на щось у 1980-х, що насправді вказувало на те, що проблема, з якою ви насправді стикаєтесь з тим, що проект виходить з-під контролю, як правило, якщо ви допускаєте, щоб помилка зберігалася поза певним етапом. Це просто стає важче виправити, якщо ти не виконаєш цю стадію правильно, тому одна з речей, яку ти тут робиш - і я думаю, що це слайд - але одна з речей, яку ти тут робиш нуль спринту, на мій погляд, абсолютно важливий, оскільки ви справді намагаєтеся зафіксувати результати. І якщо ви не отримаєте прив’язані вироби, то результати змінить форму.
Це, начебто, моя думка. Це також моя думка - я насправді не маю жодних аргументів з думкою про те, що ти маєш отримати правильне моделювання даних до певного рівня деталізації, перш ніж пройти. Те, що я хотів би, щоб ви спробували і зробили, оскільки я не зрозумів це, - це просто описати один із цих проектів з точки зору його розміру, з точки зору того, як він протікав, з точки зору того, хто, знаєте, де виникли проблеми, чи були вони вирішені? Тому що я думаю, що цей слайд - це серце його, і якщо ви могли б трохи детальніше розглянути це, я був би дуже вдячний.
Рон Хуйзенга: Звичайно, я використаю пару прикладних проектів. Той, який, начебто, зійшов з рейок, який був повернутий, фактично залучивши потрібних людей та зробивши моделювання даних, і все справді було способом переконатися, що дизайн зрозуміли краще, і ми, очевидно, мали кращий дизайн на шляху шляхом моделювання. Тому що, моделюючи його, ви знаєте, що ви можете генерувати свій DDL та все, що виходить із спинки та поза інструменту, а не з необхідності складати це, як це зазвичай роблять люди, переходячи прямо в середовище бази даних. І типові речі, які будуть статися з розробниками, - вони завітають туди, і вони скажуть, добре, мені потрібні ці таблиці. Скажімо, ми робимо записи на замовлення. Таким чином, вони можуть створити заголовок замовлення та таблиці деталей замовлення та такі типи речей. Але вони часто забувають або нехтують, щоб переконатися, що існують обмеження для представлення зовнішніх ключових відносин. У них можуть бути неправильні ключі. Конвенції про іменування також можуть бути підозрюваними. Я не знаю, скільки разів я потрапляв у середовище, наприклад, де ви бачите купу різних таблиць з різними іменами, але тоді назви стовпців у цих таблицях нагадують ідентифікатор, ім'я чи що завгодно, тож вони Я справді втратив контекст без таблиці саме того, що це таке.
Отже, зазвичай, коли ми моделюємо дані, ми переконаємось, що ми застосовуємо належні конвенції іменування до всіх артефактів, які також генеруються в DDL. Але якщо бути більш конкретним щодо природи самих проектів, це, взагалі кажучи, я кажу про досить великі ініціативи. Одним з них був проект трансформації бізнесу в розмірі 150 мільйонів доларів, де ми замінили більше десятка спадкових систем. У нас було одночасно п'ять різних спритних команд. У мене була повна команда архітектури даних, тому я мав моделерів даних своєї команди, вбудованих у кожну команду інших областей додатків, і ми працювали з комбінацією внутрішніх бізнес-експертів, які знали тему, які робили розповіді користувачів щодо самих вимог. У кожної з команд, які насправді моделювали бізнес-процес, у нас були бізнес-аналітики, з діаграмами діяльності або діаграмами бізнес-процесів, що допомагають більше розширювати історії користувачів з користувачами, перш ніж їх споживає і решта команди.
І тоді, звичайно, розробники, які будували код програми над цим. І ми також працювали, я думаю, що це було чотири різних постачальника системної інтеграції, які будували різні частини програми, а також там, де одна команда будувала послуги передачі даних, інша будувала логіку додатків в одній області, інша мала досвід в іншій області бізнесу було побудова логіки додатків у цій галузі. Тож у нас була ціла співпраця людей, які працювали над цим проектом. Зокрема, у нас було 150 людей на березі в команді та ще 150 ресурсів на березі в команді, які співпрацювали двотижневі спринти, щоб вигнати цю річ. І для цього вам потрібно переконатися, що ви стріляєте по всіх циліндрах, і всі добре синхронізовані з точки зору їх результатів, і у вас були ті часті перезавантаження, щоб переконатися, що ми виконували наші поставки всіх необхідних артефактів в кінці кожного спринту.
Доктор Робін Блор: Ну це вражає. І лише для трохи детальніше про це - чи закінчили ви повну, як я б назвав, карту MDM всієї області даних в кінці цього проекту?
Рон Хуйзенга: У нас була повна модель даних, яка була розбита з розкладанням між усіма різними сферами бізнесу. Сам словник даних з точки зору повних визначень трохи коротший. У нас було визначено більшість таблиць; у нас була більшість стовпців визначена, що саме вони означають. Були такі, яких там не було, і що цікаво, багато таких було інформацією, яка надходила із застарілих систем, де після закінчення самого масштабу проекту все ще було зафіксовано як переносний набір артефакти, як би, поза самим проектом, тому що це було щось, що потрібно підтримати організацією, яка рухається вперед. Тож в той же час організація сприйняла набагато більшу точку зору на важливість управління даними, оскільки ми побачили багато недоліків у тих застарілих системах та тих застарілих джерелах даних, які ми намагалися споживати, оскільки вони не були задокументовані. У багатьох випадках у нас були лише бази даних, які нам довелося повернути інженеру і спробувати розібратися, що там і для чого інформація.
Доктор Робін Блор: Мене це не дивує, саме його особливий аспект. Управління даними - це, назвемо це, дуже сучасне питання, і я думаю, що насправді є багато роботи, яку, скажімо, слід було зробити історично щодо управління даними. Це ніколи не було, тому що ти міг, схоже, піти, не зробивши цього. Але оскільки ресурс даних просто рос і рос, з часом ви не змогли.
У будь-якому випадку я переїду до Деса, тому що, думаю, у мене був відведений час. Дез?
Дез Бланчфілд: Так, дякую. Через все це я спостерігаю і думаю собі, що ми говоримо про те, що ми бачимо спритність, використану в гніві різними способами. Хоча це має негативні конотації; Я мав на увазі це позитивно. Чи можете ви, можливо, просто дати нам сценарій, я маю на увазі, є два місця, які я бачу, як це ідеальний набір: одне - це нові проекти, які просто потрібно робити з першого дня, але я думаю, що, як показує мій досвід, це часто випадок, що коли проекти набувають достатньо великих розмірів, що це необхідно багато в чому, виникає цікава проблема між склеюванням двох світів, правда? Чи можете ви дати нам якесь уявлення про деякі історії успіху, які ви бачили, де ви потрапили в організацію, стає зрозуміло, що у них невелике зіткнення двох світів, і ви змогли успішно поставити це на місці і об'єднувати великі проекти, де вони могли б інакше піти на рейки? Я знаю, що це дуже широке запитання, але мені просто цікаво, чи є конкретний випадок, який ви можете, начебто, вказувати на те, де ви сказали, знаєте, ми все це поставили на місце, і це об'єднало всю команду розробників разом з команда даних, і ми, начебто, вирішили щось, що могло б інакше потопити човен?
Рон Хуйзенга: Безумовно, і насправді єдиним проектом, який стався трубопровідним проектом, був той, на який я натякав, де я показав цю діаграму з дефектами до і після залучення моделера даних. Дуже часто, і є заздалегідь задумані уявлення, особливо якщо все розгортається там, де це робиться з точки зору суто розвитку, саме розробники беруть участь у цих спритних проектах для доставки програм. Тож, що там сталося, звичайно, це те, що вони зійшли з рейок, зокрема, артефакти даних, або дані, які вони виробляли, не вийшли за межі з точки зору якості та реального вирішення речей у цілому. І нерідко існує таке неправильне уявлення, що модельєри даних сповільнюватимуть проекти, і вони з'являться, якщо модельєр даних не має правильного ставлення. Як я кажу, вам доводиться втрачати - іноді є модельєри даних, які мають те традиційне ставлення до ворота, де: "Ми тут, щоб контролювати, як виглядають структури даних", і що менталітет повинен зникнути. Кожен, хто бере участь у спритній розробці, і особливо модельєри даних, повинен взяти на себе роль фасилітатора, щоб реально допомогти командам рухатися вперед. І найкращий спосіб проілюструвати це - дуже швидко показати командам наскільки продуктивними вони можуть бути, спочатку моделюючи зміни. І знову, тому я говорив про співпрацю.
Є кілька речей, які ми можемо спочатку моделювати та генерувати DDL, щоб висувати їх розробникам. Ми також хочемо переконатися, що вони не відчувають, що їх обмежують. Отже, якщо є речі, над якими вони працюють, нехай вони продовжують працювати у розробці пісочниць, оскільки там розробники працюють над власними настільними комп'ютерами чи іншими базами даних, щоб внести деякі зміни, де вони тестують речі. І співпрацюйте з ними і скажіть: «Гаразд, попрацюйте з цим». Ми введемо його в інструмент, вирішимо його, а потім висунемо його та надамо сценарії, які ви зможете розгорнути, щоб оновити свій баз даних, щоб оновити їх до того, що насправді бачить справжній виробничий погляд, коли ми продовжуємо рухатися вперед. І ви можете це дуже швидко перетворити. Я виявив, що мої дні були заповнені там, де я просто іду назад і назад ітераюючи з різними командами розвитку, дивлячись на зміни, порівнюючи, створюючи сценарії, запускаючи їх, і я міг досить легко йти в ногу з чотирма командами розвитку, як тільки ми досягли імпульсу.
Дез Бланчфілд: Одне з речей, яке мені спадає на думку, - це те, що, знаєте, багато розмов, які я щодня веду, стосуються цього вантажного поїзда, який приходить до нас, свого роду, до машини -машина та IoT. І якщо ми думаємо, що у нас зараз багато даних про наше сучасне середовище на підприємстві, ви знаєте, якщо ми на мить відведемо єдиноріг, де ми знаємо, що у Googles та Facebooks та Ubers є петабайти даних, але У традиційному підприємстві ми говоримо про ще сотні терабайт і безліч даних. Але, на мій погляд, цей вантажний потяг приїжджає до організацій, і доктор Робін Блур на це посилався раніше, на IoT. Ви знаєте, у нас багато веб-трафіку, у нас соціальний трафік, у нас зараз мобільність та мобільні пристрої, хмара, як-то, вибухнула, але тепер у нас є розумна інфраструктура, розумні міста і є весь цей світ даних, який щойно вибухнув.
Для повсякденної організації, середньої та великої організації, яка сидить там і бачить, як цей світ болю приходить у них і не має на увазі негайного плану, що таке кілька винятків у декількох пропозиціях їм про те, коли і де їм потрібно почати розмовно роздумувати над тим, щоб встановити деякі з цих методологій. Як рано їм потрібно почати планувати майже сісти і звернути увагу і сказати, що це самий час, щоб набрати якісь інструменти на місці та навчити команду та отримати розмову з vocab, що обійдеться з цим завданням? Як пізно в історії занадто пізно чи коли рано? Як це виглядає для деяких організацій, яких ви бачите?
Рон Хуйзенга: Я б сказав для більшості організацій, що якщо вони цього ще не зробили і адаптували моделювання даних та архітектуру даних за допомогою таких потужних інструментів, час, який їм потрібно зробити, це вчора. Тому що цікаво, що навіть сьогодні, коли ви дивитесь на дані в організаціях, ми маємо стільки даних у наших організаціях, і взагалі кажучи, на основі деяких опитувань, які ми бачили, ми ефективно використовуємо менше п'яти відсотків цих даних. коли ми переглядаємо організації. І якщо великі дані IoT або навіть NoSQL - навіть якщо це не лише IoT, а загалом великі дані - де ми зараз починаємо споживати ще більше інформації, що надходить поза нашими організаціями, ця проблема стає все більшою і більшою весь час. І єдиний спосіб, коли ми маємо змогу вирішити це питання - це допомогти нам зрозуміти, про що ці дані.
Отже, випадок використання дещо інший. Ми виявляємо, що ми дивимося на ці дані, ми їх забираємо, нам потрібно інженерувати їх, бачити, що в них, чи є вони в наших озерах даних чи навіть у власних власних базах даних, синтезуємо, що дані, застосуйте до нього значення та визначення, щоб ми могли зрозуміти, що це за дані. Тому що, поки ми не зрозуміємо, що це таке, ми не можемо забезпечити правильне чи адекватне використання. Тож нам дійсно потрібно зрозуміти, що це за дані. А інша частина цього - не робіть цього, тому що ви можете з точки зору споживання всіх цих зовнішніх даних переконатися, що у вас є випадок використання, який підтримує споживання цих зовнішніх даних. Зосередьтеся на речах, які вам потрібні, а не просто намагайтеся витягнути та використати речі, які вам можуть знадобитися згодом. Спершу зосередьтесь на важливих речах, і коли ви пропрацюєте це, потім перейдете до споживання та намагання зрозуміти іншу інформацію ззовні.
Прекрасним прикладом цього є те, що я знаю, що ми говоримо про IoT та сенсорах, але однаковий тип проблем був у багатьох організаціях вже багато років, ще до IoT. Усі, хто має систему управління виробництвом, будь то трубопровідна компанія, виробництво, будь-які компанії, що базуються на технологічних процесах, у яких є багато, де вони роблять багато автоматизації з управліннями, і вони використовують потоки даних і подібні речі, ці скриньки даних, які вони намагаються випити, щоб зрозуміти, про які події, що відбулися в моєму виробничому обладнанні, сигналізують - що сталося і коли? І серед цього величезного потоку даних є лише конкретні відомості або теги, які їх цікавлять, що їм потрібно відсівати, синтезувати, моделювати та розуміти. І вони можуть ігнорувати решту цього, поки не настане час реально зрозуміти це, і тоді вони можуть розширити свою сферу, щоб все більше і більше втягувати це в сферу, якщо це має сенс.
Дез Бланчфілд: Дійсно. Є одне питання, яке я хочу на те, щоб прийти від джентльмена на ім'я Ерік, і ми спілкувалися з ним приватно. Я щойно попросив його дозволу, який він дав, щоб попросити його у вас. Тому що це добре приводить до цього, просто завершити, тому що ми трохи підемо з часом, і я повернусь до Еріка. Але питання іншого Еріка полягало в тому, чи розумно припускати, що власники стартапу добре знайомі та розуміють унікальні проблеми навколо моделювання термінології тощо? Чи слід це передавати комусь іншому для тлумачення? Отже, іншими словами, чи повинен стартап бути спроможним і готовим і готовим і вміти зосередитися на цьому і досягти цього? Або це щось, напевно, вони повинні купувати магазини та привертати експертів?
Рон Хуйзенга: Я думаю, що від цього дійсно залежить коротка відповідь. Якщо це стартап, у якого немає когось, хто є архітектором даних або модельєром, який дійсно розуміє базу даних, то найшвидший спосіб почати - це залучити когось із консалтинговим досвідом, який дуже добре розбирається в цьому просторі і може отримати вони йдуть. Тому що те, що ти знайдеш - а насправді я зробив це на багатьох завданнях, які я робив перед тим, як перейти до темної сторони в управлінні продуктами - це я би вступив до організацій як консультант, очолюю їхні команди з архітектури даних, щоб вони могли переосмислити себе та навчити своїх людей, як робити такі речі, щоб вони підтримували їх та виконували місію вперед. І тоді я б продовжував свою наступну діяльність, якщо це має сенс. Там багато людей, які роблять це, які мають дуже хороший досвід передачі даних, який може змусити їх працювати.
Дез Бланчфілд: Це чудовий виносний момент, і я повністю згоден з цим, і я впевнений, що і доктор Робін Блер також. Ви особливо зосереджені на стартапі, ви зосереджені на тому, щоб бути малим та середнім бізнесом на конкретну цінність пропозиції, яку ви хочете створити як частину свого самого стартап-бізнесу, і вам, мабуть, не потрібно бути експертом у всьому, тому чудові поради. Але дуже дякую, фантастична презентація. Дійсно чудові відповіді та запитання. Еріку, я повернуся до тебе, бо знаю, що ми пішли, мабуть, за десять хвилин, і я знаю, що ти любиш триматися близько до наших вікон часу.
Ерік Кавана: Це нормально. У нас є хоча б пара хороших запитань. Дозвольте мені кинути один до вас. Я думаю, ти відповів на деякі інші. Але дуже цікаве спостереження та запитання одного учасника, який пише, що іноді у спритних проектів моделер даних не має всієї довгострокової картини, і тому вони завершують проектувати щось у спринті, а потім доводиться переробляти в спринті три-чотири. Це не здається контрпродуктивним? Як можна уникнути подібного?
Рон Хуйзенга: Це просто природа спритного, що ви не збираєтеся отримати все абсолютно правильно в даному спринті. І це насправді є частиною духу спритного, це: робота з ним - ви будете робити прототипування там, де працюєте над кодом у заданому спринті, і ви збираєтеся вдосконалювати його. І частина цього процесу полягає в тому, що ви доставляєте речі, які кінцевий користувач бачить, і каже: "Так, це близько, але мені дійсно потрібно, щоб він це робив ще й трохи додатково". Так що не тільки впливає на функціональний дизайн самого коду, але досить часто нам потрібно змінювати або додавати більше структур даних під ці певні речі, щоб доставити те, що користувач хоче. І це все в справедливій грі, і саме тому ви дійсно хочете використовувати потужні інструменти, тому що ви можете дуже швидко моделювати та вносити зміни в інструмент моделювання, а потім генерувати DDL для бази даних, над якою розробники можуть працювати, щоб доставити це зміниться ще швидше. Ви рятуєте їх від необхідності виконувати таке ручне кодування структур даних і дозволяєте їм зосередитись на логіці програмування або застосувань, які вони найбільш досвідчені.
Ерік Кавана: Це має повний сенс. У нас було кілька інших людей, які просто задавали конкретні запитання про те, як це все пов'язано з інструментом. Я знаю, що ви витратили деякий час, переглядаючи приклади, і ви показували кілька скріншотів про те, як ви насправді розгортаєте частину цього матеріалу. З точки зору всього цього спринтерського процесу, як часто ви бачите, що граєте в організаціях проти того, як часто ви бачите більш традиційні процеси, коли речі просто, начебто, збираються разом і займають більше часу? Наскільки поширений сприйняття спринт-стилю з вашого погляду?
Рон Хуйзенга: Я думаю, що ми спостерігаємо все більше і більше. Я знаю, що, я б сказав, напевно, за останні 15 років, зокрема, я бачив набагато більше людей, які усвідомлюють, що їм дійсно потрібно сприйняти більш швидку доставку. Тому я бачив, як все більше організацій стрибають на проворну смугу. Не обов'язково цілком; вони можуть почати з декількох пілотних проектів, щоб довести, що це працює, але є такі, які все ще дуже традиційні, і вони дотримуються методу водоспаду. Тепер, гарна новина, звичайно, полягає в тому, що інструменти працюють дуже добре в цих організаціях, а також для тих типів методологій, але ми маємо адаптованість у цьому інструменті, щоб ті, хто стрибає на борт, мали інструменти в панелі інструментів на їхні кінчики пальців. Такі речі, як порівняння та злиття, такі, як можливості зворотного проектування, тому вони можуть бачити, які існують джерела даних, тому вони можуть насправді порівняти та генерувати додаткові сценарії DDL дуже швидко. І коли вони починають сприймати це і бачити, що вони можуть мати продуктивність, їх схильність до спритного сприйняття ще більше зростає.
Ерік Кавана: Ну, це чудові речі, люди. Я щойно опублікував посилання на слайди там у вікні чату, тому перевірте це; це трохи трішки там для вас. У нас є всі ці трансляції для подальшого перегляду. Не соромтеся ділитися ними з друзями та колегами. І Рон, дуже дякую за ваш сьогоднішній час, вам завжди приємно брати участь у шоу - справжній експерт у цій галузі і очевидно, що ви знаєте свої речі. Тож, дякую вам і дякуємо IDERA та, звичайно, Дезу та нашій власній Robin Bloor.
І з цим ми попрощаємося, люди. Ще раз дякую за ваш час та увагу. Ми цінуємо, що ти тримаєшся протягом 75 хвилин, це досить хороший знак. Хороші хлопці шоу, ми поговоримо з вами наступного разу. Бувай.
