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