Винос: Ведуча Ребекка Йозвяк обговорює рішення архітектури даних з Еріком Літлом з OSTHUS, Малкольмом Чисгольмом з партнерів з першого Сан-Франциско та Ронам Хуйзенгою з IDERA.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ребекка Йозвяк: Дами та панове, привіт, ласкаво просимо до Hot Technologies 2016. Сьогодні ми обговорюємо "Створення архітектури даних, керованої бізнесом", безумовно, гаряча тема. Мене звуть Ребекка Йозвяк, я буду вашим господарем сьогоднішньої трансляції. Ми робимо твіт із хештегом # HotTech16, тому якщо ви вже є, не соромтесь також приєднатися до цього. Якщо у вас є запитання в будь-який час, зверніться до них на панель запитань у нижній правій частині екрана, і ми обов’язково отримаємо відповідь. Якщо ні, ми переконаємось, що наші гості отримають їх за вас.
Тому сьогодні у нас дійсно захоплююча лінійка. Сьогодні у нас багато важких нападників. У нас Ерік Літл, віце-прем'єр-міністр науки OSTHUS. У нас є Малькольм Чісгольм, головний директор з питань інновацій, який є дуже класним званням, для перших партнерів у Сан-Франциско. У нас є Рон Хуйзенга, старший менеджер із продуктів IDERA. І, знаєте, IDERA має дійсно повний набір рішень для управління даними та моделювання. І сьогодні він збирається розповісти нам про те, як працює його рішення. Але перш ніж ми дістанемося до цього, Ерік Літл, я збираюся передати м'яч тобі.
Ерік Літл: Гаразд, велике спасибі Тому я перегляну кілька тем, які, на мою думку, трохи стосуватимуться розмови Рона, і, сподіваємось, також підставлюю деякі теми, а також питання Q&A.
Тож, що мене зацікавило, чим займається IDERA, це те, що я думаю, що вони правильно вказують на те, що складні середовища справді призводять до багатьох ділових цінностей. Під складними середовищами ми маємо на увазі складні середовища даних. І технології дійсно швидко просуваються, і важко бути в курсі сьогоднішнього ділового середовища. Тож ті люди, які працюють у технологічних просторах, часто бачать, що у вас є клієнти, які працюють із проблемами: «Як я можу використовувати великі дані? Як я включаю семантику? Як я пов’язую деякі з цих нових речей зі своїми старими даними? »І так далі, і такий вид призводить нас сьогодні до цих чотирьох великих даних, з якими багато людей добре знайомі, і я розумію, що їх може бути більше чотирьох іноді - я бачив цілих вісім чи дев'ять - але зазвичай, коли люди говорять про такі речі, як великі дані, або якщо ви говорите про великі дані, то зазвичай ви дивитесь на щось таке, що має масштаб корпоративного масштабу. І тому люди скажуть, гаразд, добре, подумайте про обсяг ваших даних, який, як правило, фокус - саме стільки у вас є. Швидкість даних пов’язана або з тим, наскільки швидко я можу їх переміщувати, або з швидкістю, коли я можу їх запитувати, або отримувати відповіді тощо. І особисто я думаю, що ліва сторона цього - це те, що досить швидко вирішується і вирішується багатьма різними підходами. Але з правого боку я бачу багато можливостей для вдосконалення та багато нових технологій, які справді виходять на перший план. І це стосується третього стовпця, різноманітності даних.
Іншими словами, сьогодні більшість компаній дивляться на структуровані, напівструктуровані та неструктуровані дані. Дані про зображення починають ставати гарячою темою, тому, використовуючи комп'ютерний зір, дивлячись на пікселі, можна прокручувати, NLP, видобуток сутності, у вас є інформація про графік, яка виходить із статистичної моделі або виходить із семантичних моделей , у вас є реляційні дані, які існують у таблицях тощо. І тому зведення всіх цих даних разом і всіх цих різних типів справді представляє велику проблему, і ви побачите це, знаєте, у Gartner та інших людей, які начебто слідують тенденціям у цій галузі.
І тоді останнє, про що люди говорять у великих даних, часто це поняття ненажерливості, яке насправді є невизначеністю ваших даних, нечіткістю їх. Наскільки добре ви знаєте, про що ваші дані, наскільки добре ви розумієте, що там, і, знаєте? Можливість використовувати статистику та можливість використовувати якийсь тип інформації навколо того, що ви можете знати, або використовувати певні підходи, може бути корисним для цього. Отже, можливість дивитися на дані таким чином з точки зору вашої кількості, як швидко потрібно переміщати їх чи отримувати на них, усіх типів даних, які ви можете мати на вашому підприємстві, і наскільки ви точно знаєте, де це, що це таке, яка якість в ньому тощо. Це дійсно вимагає великих координованих зусиль між великою кількістю людей для ефективного управління своїми даними. Отже, моделювання даних набуває все більшого значення в сучасному світі. Тож хороші моделі даних справді приносять великий успіх у корпоративних додатках.
У вас є джерела даних з різних джерел, як ми говорили, що насправді вимагає багато різних видів інтеграції. Тож об'єднання все це дійсно корисно, щоб можна було виконувати запити, наприклад, у багатьох типах джерел даних та повертати інформацію назад. Але для цього вам потрібні хороші стратегії картографування, і тому картографування таких типів даних та підтримка цих відображень може бути справжньою проблемою. І тоді ви маєте це питання про те, як я можу пов’язати застарілі дані з усіма цими новими джерелами даних? Отже, припустимо, у мене є графік, чи я беру всі свої реляційні дані і вкладаю їх у графік? Зазвичай це не дуже гарна ідея. То як же люди можуть керувати всіма цими типами даних, що діють? Аналіз дійсно повинен проводитися на багатьох таких різних джерелах даних та комбінаціях. Тож відповіді, які випливають з цього, відповіді, необхідні людям, щоб дійсно приймати хороші бізнес-рішення, є критичними.
Тож мова йде не лише про побудову технології заради технології, це справді, що я збираюся робити, що я можу зробити з нею, який аналіз можна запустити, і здатність, отже, як я вже мав говорили про те, щоб зібрати цей матеріал разом, інтегрувати його справді, дуже важливо. І один із цих типів аналізів потім працює на таких речах, як об'єднаний пошук і запит. Це справді стає обов'язковим. Ваші запити, як правило, мають передаватися через різні види джерел і повертати інформацію надійно.
Єдиний ключовий елемент, який часто, особливо люди збираються дивитись на ключові речі, такі як семантичні технології - і це те, про що я сподіваюся, що Рон трохи поговорить у підході IDERA - це як розділити або керувати модельний рівень ваших даних із самого рівня даних, із цих необроблених даних? Отже, на рівні даних у вас можуть бути бази даних, у вас можуть бути дані документа, у вас можуть бути дані електронних таблиць, ви можете мати дані зображення. Якщо ви знаходитесь у таких сферах, як фармацевтична галузь, ви отримаєте величезну кількість наукових даних. А потім, крім цього, люди зазвичай шукають спосіб побудувати модель, яка дозволяє їм швидко інтегрувати ці дані, і справді, коли ви шукаєте дані, тепер ви не хочете перетягувати всі дані в ваш модельний шар , що ви дивитесь на шар моделі, щоб зробити це гарне логічне уявлення про те, що таке речі, загальні словникові запаси, загальні типи сутностей і відносин, а також можливість дійсно потрапити в дані, де вони є. Отже, він повинен сказати, що це таке, і він повинен сказати, де він знаходиться, і він повинен сказати, як дістати його і повернути назад.
Таким чином, це був досить успішний підхід у просуванні семантичних технологій вперед, це сфера, де я багато працюю. Отже, питання, яке я хотів поставити перед Роном, і яке, на мою думку, буде корисним у розділі запитань та запитань, - це зрозуміти, як це здійснюється платформою IDERA? Отже, чи шар моделі насправді відокремлений від рівня даних? Вони більш інтегровані? Як це працює і які результати та переваги вони бачать від свого підходу? Тому референтні дані дійсно стають також критичними. Отже, якщо ви будете мати такі моделі даних, якщо ви зможете об'єднатись і шукати різні речі, ви дійсно повинні мати хороші довідкові дані. Але проблема в тому, що довідкові дані можуть бути дуже важкими в обслуговуванні. Тож часто називання самих стандартів є складним викликом. Одна група буде називати щось X, а одна група називатиме Y і тепер у вас виникає проблема, як хтось знаходить X і Y, коли вони шукають цей тип інформації? Оскільки ви не хочете просто надавати їм частину даних, ви хочете передати їм все, що стосується.У той же час змінюються умови, програмне забезпечення стає застарілим тощо. Як ви зберігаєте та підтримуєте ці довідкові дані протягом часу?
І, знову ж таки, семантичні технології, зокрема використання таких речей, як систематика та словникові запаси, словники даних, забезпечили стандартний космічний спосіб цього зробити, який є дуже надійним, він використовує певні види стандартів, але спільнота баз даних зробила це для тривалий час також просто по-різному. Я думаю, що одним із ключових моментів тут є подумати про те, як використовувати, можливо, моделі відношення сутності, як використовувати, можливо, графічні моделі або якийсь тип підходу, який справді дасть вам сподіватися стандартного способу обробки ваших довідкових даних. І тоді, звичайно, коли у вас є довідкові дані, стратегії відображення повинні управляти найрізноманітнішими іменами та сутностями. Тому експерти з предметів часто люблять використовувати власні умови.
Тож проблема в цьому завжди полягає в тому, як ви даєте комусь інформацію, але робите її відповідною до того, як вони про неї говорять? Таким чином, одна група може мати один спосіб дивитися на щось, наприклад, ви, можливо, хімік, який працює над наркотиками, і ви можете бути структурним біологом, який працює над тим самим препаратом, і у вас можуть бути різні назви для одних і тих же типів які стосуються вашого поля. Ви мусите розібратися, як поєднати ці персоналізовані термінології, оскільки інший підхід полягає в тому, що ви повинні змусити людей відмовитися від терміну і використовувати чужі, що їм часто не подобається. Ще один момент, коли обробляти велику кількість синонімів стає важко, тому в даних багатьох людей є багато різних слів, які можуть посилатися на одне і те ж. У вас там є проблема посилання, використовуючи множинні відносини один до одного. Спеціалізовані терміни відрізняються від галузі до галузі, тому якщо ви збираєтесь запропонувати своєрідне рішення для такого типу управління даними, наскільки легко це переносити з одного проекту чи однієї програми до іншої? Це може бути ще одним викликом.
Автоматизація важлива, і це також завдання. Обробляти довідкові дані вручну дорого. Довго зберігати карти вручну, і дорого заважати експертам з предметів переставати виконувати щоденні завдання, доводиться постійно вносити словники даних і поновлювати визначення та інше, і так далі. Реплікаційні лексики дійсно виявляють велику цінність. Тож це слова, які часто можна знайти зовнішніми для вашої організації. Наприклад, якщо ви займаєтесь сирою нафтою, існують певні типи словникових запасів, які ви можете запозичити з просторів з відкритим кодом, як і з фармацевтичними препаратами, з банківською галуззю та з фінансовими, як і з багатьма подібними сферами. Люди викладають лексики для багаторазового використання, загальні для повторного використання, які люди можуть використовувати.
І знову, дивлячись на інструмент IDERA, мені цікаво побачити, як вони справляються з цим з точки зору використання видів стандартів. У світі семантики ви часто бачите такі речі, як моделі SKOS, які забезпечують стандарти принаймні ширші / вужчі, ніж стосунки, і це може бути важко зробити в моделях ER, але, знаєте, це неможливо, це просто залежить від того, наскільки це буде машини та ті зв'язки, якими ви можете користуватися в таких системах.
Отже, нарешті, я просто хотів порівняти деякі семантичні двигуни, які я бачу в галузі, і начебто попросити Рона та трохи попросити його поговорити про можливо, як система IDERA використовується в поєднанні з будь-якими семантичними технологіями. Чи здатна вона інтегруватися з потрійними сховищами, базами даних графіків? Наскільки легко використовувати зовнішні джерела, оскільки такі речі в семантичному світі часто можна запозичити за допомогою кінцевих точок SPARQL? Ви можете імпортувати моделі RDF або OWL безпосередньо у вашу модель - зверніться до них - так, наприклад, онтологія генів або білка онтологія, які можуть жити десь у своєму просторі зі своєю власною структурою управління, і я можу просто імпортувати всі або частина цього, як мені потрібно, у власних моделях. Мені цікаво дізнатися, як IDERA підходить до цього питання. Чи потрібно все підтримувати внутрішньо, чи є способи використовувати інші типи стандартизованих моделей і втягувати їх, і як це працює? І останнє, що я згадав тут, - скільки ручної роботи реально задіяно для створення словників та сховищ метаданих?
Тож я знаю, що Рон покаже нам деякі демонстрації подібних речей, які будуть справді цікавими. Але проблеми, які я часто бачу в консультаціях із клієнтами, полягають у тому, що багато помилок трапляється, якщо люди пишуть у своїх власних визначеннях чи власних метаданих. Таким чином, ви отримуєте неправильні написання, ви отримуєте жирові помилки, це одне. Ви також отримуєте людей, які можуть взяти щось із, знаєте, просто Вікіпедії або джерела, яке не обов'язково має таку якість, яку ви хочете, щоб визначити, або ваше визначення є лише з точки зору однієї людини, тому воно не є повним, і це не ясно тоді як працює процес управління. Управління, звичайно, є дуже важливою проблемою кожного разу, коли ви говорите про довідкові дані та будь-коли, коли ви говорите про те, як це може вписуватися в чиїсь основні дані, як вони збираються використовувати їх метадані та так далі.
Тому я просто хотів викласти деякі з цих тем там. Це речі, які я бачу в бізнес-просторі в багатьох різних консультаційних заходах і в багатьох різних місцях, і мені дуже цікаво побачити, що Рон збирається показати нам із IDERA, щоб вказати на деякі з цих тем . Тож дуже дякую
Ребекка Йозвяк: Дякую, Ерік, і мені дуже подобається ваш коментар, що може виникнути багато помилок, якщо люди пишуть свої власні визначення чи метадані. Я знаю, що в світі журналістики існує мантра, що "багато очей роблять мало помилок", але коли справа доходить до практичних застосувань, занадто багато рук у банці з печивом, як правило, залишають тебе з великою кількістю зламаних печива, правда?
Ерік Літл: Так, і мікроби.
Ребекка Йозвяк: Так. З цим я йду вперед і передаю його Малкольму Чисгольму. Малькольм, підлога твоя.
Малькольм Чизгольм: Дуже дякую, Ребекка. Я хотів би трохи ознайомитись з тим, про що Ерік говорив, і додати до них, наприклад, кілька спостережень, на які, знаєте, Рон може також відповісти, розмовляючи про "На шляху до архітектури даних, керованої бізнесом". "- що означає керувати бізнесом і чому це важливо? Або це просто якась ажіотаж? Я не думаю, що це так.
Якщо ми подивимось, що відбувається з тих пір, як відомо, комп'ютери з мейнфреймом дійсно стали доступними компаніям - скажімо, близько 1964 року - до сьогоднішнього дня, ми можемо побачити, що відбулося багато змін. І ці зміни я б узагальнив як перехід від орієнтації на процес на орієнтацію на дані. Саме це робить архітектуру даних, керовану бізнесом, настільки важливою і настільки актуальною для сьогодні. І я думаю, ви знаєте, це не просто казкове слово, це щось справжнє.
Але ми можемо оцінити це трохи більше, якщо зануритися в історію, тож повертаючись у часи, назад до 1960-х років і деякий час після цього панували мейнфрейми. Потім вони поступилися місцем персональним ПК, де ви насправді бунтували користувачів, коли входили ПК. Повстання проти централізованих ІТ, які, на їхню думку, не задовольняли їхніх потреб, були недостатньо спритними. Це швидко породило розподілені обчислення, коли ПК були пов'язані між собою. І тоді почав відбуватися Інтернет, який розмив межі підприємства - тепер він міг взаємодіяти з сторонами поза межами себе з точки зору обміну даними, чого раніше не було. І тепер ми пішли в епоху хмарних і великих даних, де хмара - це платформи, які насправді комунізують інфраструктуру, і тому ми залишаємо, як би, ІТ про необхідність запускати великі центри обробки даних, тому що, знаєте, ми У нас є доступна ємність хмари, і ми супроводжуємося великими даними, які Ерік, ви знаєте, так красномовно обговорювали. І в цілому, як ми бачимо, в міру зміни технологій це стало більш орієнтованим на дані, ми більше дбаємо про дані. Як і в Інтернеті, як обмінюються даними. З великими даними, чотири або більше проти самих даних.
У той же час, і, можливо, що важливіше, випадки використання бізнесу зміщуються. Коли комп'ютери були вперше представлені, їх використовували для автоматизації таких речей, як книги та записи. І все, що було ручним процесом, що включало книги чи подібні речі, програмувалося, по суті, вдома. Це змінилося у 80-х роках на наявність оперативних пакетів. Вам більше не потрібно було писати свою зарплату, ви можете придбати щось, що зробило це. Це призвело до значного скорочення в той час або реструктуризації багатьох IT-відділів. Але тоді з'явилася бізнес-розвідка з такими речами, як сховища даних, переважно в 90-х. Далі йдуть бізнес-моделі dotcom, які, звичайно, були великим шаленством. Потім МДМ. З MDM ви починаєте бачити, що ми думаємо не про автоматизацію; ми фактично зосереджуємось на наданні даних у якості даних. А потім аналітика, що представляє цінність, яку ви можете отримати з даних. І всередині аналітики ви бачите дуже успішні компанії, чия основна модель бізнесу обертається навколо даних. Google,, буде частиною цього, але ви можете також стверджувати, що Walmart є.
І тому бізнес справді думає про дані. Як ми можемо отримати значення з даних? Як дані можуть керувати бізнесом, стратегією, і ми перебуваємо в золотому періоді даних. Отже, зважаючи на те, що відбувається з нашою архітектурою даних, якщо дані вже не розглядаються як просто вихлоп, який виходить із заднього кінця додатків, але насправді є центральним для наших бізнес-моделей? Ну, частина проблеми, яку ми маємо в досягненні - це ІТ, насправді застрягла в минулому з життєвим циклом розвитку систем, який був наслідком того, що в ранньому віці ІТ потрібно швидко боротися з цією фазою автоматизації процесів і працювати в проекти - це аналогічна річ. Для ІТ - і це трохи карикатура - але те, що я намагаюся сказати, - це те, що деякі бар'єри для отримання архітектури даних, керованої бізнесом, є тому, що ми як би некритично сприйняли культуру в ІТ що походить із минулого віку.
Отже, все є проектом. Детально розкажіть свої вимоги. Якщо щось не працює, це тому, що ви не сказали мені своїх вимог. Ну, це не працює сьогодні з даними, тому що ми не починаємо з автоматизованих ручних процесів або технічної конверсії бізнес-процесів, ми починаємо дуже часто з уже наявних виробничих даних, які ми намагаємося щоб отримати вартість. Але ніхто, хто спонсорує проект, орієнтований на дані, насправді не розуміє цих даних глибоко. Ми повинні зробити пошук даних, ми повинні зробити вихідні дані. І це зовсім не відповідає розвитку систем, ви знаєте - водоспад, життєвий цикл SDLC - з яких я б сказав, що Agile є кращою його версією.
А на чому зосереджується технологія та функціональність, а не дані. Наприклад, коли ми робимо тестування на етапі тестування, зазвичай це працює, чи працює моя функціональність, скажімо, моя ETL, але ми не тестуємо дані. Ми не перевіряємо наші припущення щодо вихідних даних, що надходять. Якщо ми це зробили, ми опинилися б у кращому стані, і як хтось, хто робив проекти сховища даних та зазнав змін у потоці, поривавши мої ETL, я би вдячний. Насправді те, що ми хочемо бачити, - це тестування як попередній крок до постійного моніторингу якості виробничих даних. Таким чином, ми маємо тут багато поглядів, коли складно досягти архітектури даних, керованої бізнесом, тому що ми зумовлені епохою зосередженості на процесах. Нам потрібно зробити перехід до орієнтованості на дані. І це не тотальний перехід, ви знаєте, ще належить зробити багато роботи над процесом, але ми насправді не думаємо, орієнтовані на дані, коли це потрібно, та обставини, що трапляються, коли ми насправді зобов’язаний це зробити.
Тепер бізнес усвідомлює цінність даних, вони хочуть розблокувати дані, то як нам це робити? То як нам зробити перехід? Ну, ми ставимо дані в основі процесів розвитку. І ми дозволяємо бізнесу вести з інформаційними вимогами. І ми розуміємо, що ніхто не розуміє існуючих вихідних даних на початку проекту. Ви можете стверджувати, що структура даних і самі дані потрапляли туди відповідно через ІТ та операції, тож ми повинні це знати, але насправді ми цього не робимо. Це розвиток, орієнтований на дані. Тож ми повинні, думаючи про те, де ми і як робимо моделювання даних у світі, орієнтованому на дані, ми повинні мати петлі зворотного зв’язку для користувачів з точки зору вдосконалення їхніх інформаційних вимог, як ми робимо виявлення даних та профілювання даних. , передбачають аналіз даних джерел, і по мірі того, як ми поступово отримуємо все більшу впевненість у своїх даних. І зараз я говорю про більш традиційний проект, наприклад, центр MDM або сховище даних, не обов'язково про проекти з великими даними, хоча це все ще, я вважаю, досить близький до цього. Отже, ці петлі зворотного зв’язку включають в себе моделяторів даних, поступово просуваючи свою модель даних та взаємодіючи з користувачами, щоб переконатися, що вимоги до інформації уточнюються на основі того, що можливо, що є в наявності, від вихідних даних, як вони краще їх розуміють, так це вже не випадок, коли модель даних перебуває, знаєте, в стані, який або не існує, або повністю зроблено, це поступове привернення до нього уваги.
Аналогічно, ми маємо гарантію якості, коли ми розробляємо правила тестування якості даних, щоб переконатися, що дані входять у параметри, про які ми робимо припущення. Ерік мав на увазі зміни у довідкових даних, які можуть статися. Ви не хочете бути жертвою подальшої, некерованої зміни в цій галузі, так що правила забезпечення якості можуть перейти в постпродукційний, постійний моніторинг якості даних. Таким чином, ви можете почати бачити, чи будемо ми орієнтовані на дані, як ми робимо розробку, орієнтовану на дані, сильно відрізняється від SDLC та Agile на основі функціональності. І тоді ми повинні також звертати увагу на погляди бізнесу. У нас - і це повторюється тим, що говорив Ерік, - у нас є модель даних, що визначає синю історію даних для нашої бази даних, але в той же час нам потрібні ті концептуальні моделі, ті бізнес-погляди на дані, які традиційно не робили в минуле. Ми часом думали, що ми думаємо, що модель даних може все це зробити, але нам потрібно мати концептуальне уявлення, семантику та заглянути в дані, зробити це через рівень абстракції, який переводить модель зберігання у бізнес вид. І, знову-таки, все те, про що Ерік говорив з точки зору семантики, стає для цього важливим, тому ми насправді маємо додаткові завдання з моделювання. Я думаю, що це, ви знаєте, цікаво, якщо ви прийшли в ряди як модельєр даних, як я, і знову щось нове.
І нарешті, я хотів би сказати, що більша архітектура також повинна відображати цю нову реальність. Наприклад, традиційний MDM для клієнтів - це начебто добре, давайте заносимо наші клієнтські дані в центр, де ми можемо, знаєте, мати сенс у сенсі справді просто якості даних для бек-офісних програм. Що з точки зору ділової стратегії, це свого роду позіхання. Однак сьогодні ми розглядаємо концентратори MDM клієнтів, які мають у них додаткові дані профілю клієнта, а не лише статичні дані, які дійсно мають двосторонній інтерфейс із заявками клієнта на транзакції. Так, вони все ще підтримують бек-офіс, але тепер ми знаємо про такі поведінки наших клієнтів. Це дорожче будувати. Це складніше будувати. Але це орієнтоване на бізнес таким чином, як традиційний клієнт MDM не є. Ви торгуєте орієнтацією на бізнес проти більш простих конструкцій, які легше здійснити, але для бізнесу це те, що вони хочуть бачити. Ми дійсно в новій епосі, і я думаю, що існує ряд рівнів, на які ми повинні відповідати архітектурі даних, що керують бізнесом, і я думаю, що це дуже захоплюючий час робити справи.
Тож дякую тобі, Ребекка.
Ребекка Йозвяк: Дякую Малкольм, і мені дуже сподобалось те, що ви сказали про моделі даних, повинно підживлювати бізнес-погляд, бо, на відміну від того, що ви говорили, де ІТ так довго тримав лейці, і це вже просто не такий вигляд, а культура чи потрібно зрушити. І я майже впевнений, що на задньому плані був собака, який погодився з вами на 100%. І з цим я збираюся передати м'яч Рону. Я дуже рада бачити вашу демонстрацію. Рон, підлога твоя.
Рон Хуйзенга: Дякую вам дуже багато, і перш ніж ми перейдемо до цього, я перегляну кілька слайдів, а потім трохи демонстрації, тому що, як зазначають Ерік і Малькольм, це дуже широка і глибока тема, і з тим, що ми Ми сьогодні говоримо про те, що ми просто обчищаємо його поверхню, тому що існує так багато аспектів і так багато речей, які нам дійсно потрібно розглянути та подивитися з архітектури, керованої бізнесом. І наш підхід полягає в тому, щоб реально зробити цю модель на основі моделей і отримати справжнє значення з моделей, тому що ви можете використовувати їх як комунікаційний засіб, а також шар для включення інших систем. Незалежно від того, чи займаєтесь ви сервісно-орієнтованою архітектурою чи іншими речами, модель дійсно стає життєвою основою того, що відбувається, з усіма метаданими навколо нього та даними, які є у вашому бізнесі.
Однак я хочу поговорити майже про крок назад, тому що Малькольм торкнувся певної історії розвитку еволюційного рішення та такого типу речей. Один із способів дійсно вказати на те, як важливо мати обґрунтовану архітектуру даних, - це випадок використання, з яким я стикався дуже часто, коли консультувався, перш ніж я вступив у роль управління продуктом, і це було, я б вдавався в організації чи вони роблять трансформацію бізнесу, чи просто замінюють деякі існуючі системи та подібний тип речей, і дуже швидко стало очевидним, як погано організації розуміють власні дані. Якщо ви користуєтесь конкретним випадком використання, як цей, будь то консультант, або, можливо, це людина, яка нещодавно почала роботу з організацією, або ваша організація була створена роками з придбання різних компаній, чим ви закінчите дуже складне середовище дуже швидко, з низкою нових різних технологій, а також застарілими технологіями, ERP-рішеннями та всім іншим.
Отже, одна з речей, яку ми можемо реально зробити за допомогою нашого підходу до моделювання, - це відповісти на питання, як я маю сенс у всьому цьому? Ми дійсно можемо почати обробляти інформацію разом, тому бізнес може використовувати ту інформацію, яку ми маємо належним чином. І виходить, що ми маємо там у тих середовищах? Як я можу використовувати моделі, щоб виганяти потрібну мені інформацію та краще розуміти цю інформацію? І тоді у нас є традиційні типи метаданих для всіх різних речей, таких як реляційні моделі даних, і ми звикли бачити такі речі, як визначення та словники даних, знаєте, типи даних та подібний тип речей. А як щодо додаткових метаданих, які ви хочете зафіксувати, щоб дійсно надати їй ще більше значення? Наприклад, які суб'єкти дійсно є кандидатами, які повинні бути посиланнями на об'єкти даних, які повинні бути майстрами об'єктів управління даними та типи речей і з'єднати їх між собою. І як інформація протікає через організацію? Дані протікають з того, як вони споживаються як з точки зору процесу, так і з лінії передачі даних з точки зору подорожі інформації через наш бізнес та того, як він пробивається через різні системи чи через сховища даних, тому ми знаємо коли ми будуємо I-рішення чи такі типи речей, що ми фактично споживаємо правильну інформацію для завдання.
І тоді дуже важливо, як ми можемо змусити всіх тих зацікавлених сторін співпрацювати, і особливо ділових зацікавлених сторін, оскільки саме вони надають нам справжній сенс того, що ці дані. Зрештою, бізнес належить даним. Вони надають визначення словника та речей, про які говорив Ерік, тому нам потрібно десь зв'язати все це разом. І ми це робимо через наше моделювання даних та архітектуру сховищ даних.
Я торкнуся кількох речей. Я буду говорити про ER / Studio Enterprise Team Edition. Перш за все, я буду говорити про продукт архітектури даних, де ми робимо моделювання даних та подібний тип речей, але є багато інших компонентів набору, до яких я просто торкнуся коротко. Ви побачите один фрагмент бізнес-архітектора, де ми можемо робити концептуальні моделі, але ми також можемо робити моделі бізнес-процесів, і ми можемо пов’язати ці моделі процесів, щоб зв’язати фактичні дані, які є у наших моделях даних. Це дійсно допомагає нам зблизити цю краватку. Програмний архітектор дозволяє нам робити додаткові конструкції, такі як моделювання UML та інші типи речей, щоб надавати підтримуючу логіку деяким іншим системам і процесам, про які ми говоримо. Але дуже важливо, коли ми рухаємось вниз, у нас є сервер сховища та команда, і я говорю про це як про дві половини одного і того ж. У сховищі ми зберігаємо всі модельовані метадані, а також усі бізнес-метадані з точки зору ділових словників та термінів. І оскільки у нас є таке середовище, що базується на сховищах, ми можемо зв'язати всі ці різні речі разом у тому самому середовищі, і тоді ми зможемо зробити їх доступними для споживання, не тільки для людей технічного характеру, але і для бізнесменів. І саме так ми починаємо розвивати співпрацю.
І тоді останній твір, про який я коротко розповім, - коли ви заходите в ці середовища, то це не просто бази даних, які ви маєте там. У вас буде багато баз даних, сховищ даних, у вас також буде багато, як я б назвав, спадкових артефактів. Можливо, люди використовували Visio або інші діаграми, щоб окреслити деякі речі. Можливо, у них були інші інструменти для моделювання та подібні речі. Тож, що ми можемо зробити з MetaWizard - це фактично витягнути частину цієї інформації та внести її до наших моделей, зробити її актуальною та мати можливість використовувати її, спожити її знову, а не просто просто сидіти там. Зараз це стає активною частиною наших працюючих моделей, що дуже важливо.
Коли ви заходите в організацію, як я вже сказав, там багато розрізнених систем, багато рішень ERP, невідповідних відомчих рішень. Багато організацій також використовують рішення SaaS, які також контролюються і керуються зовні, тому ми не контролюємо бази даних та типи речей у хостах на них, але нам все одно потрібно знати, як виглядають ці дані, і, звичайно, метадані навколо цього. Ми також знаходимо багато застарілих застарілих систем, які не були очищені через той проектний підхід, про який говорив Малькольм. Дивовижно, як в останні роки організації розповсюджують проекти, замінять систему чи рішення, але часто не вистачає бюджету проекту, щоб вивести з експлуатації застарілі рішення, тому тепер вони просто в дорозі. І ми повинні розібратися, чого насправді можна позбутися в нашому середовищі, а також, що корисно йде вперед. І це пов'язане з поганою стратегією виведення з експлуатації. Це частина того ж самого.
Ми також знаходимо, тому що багато організацій було створено з усіх цих різних рішень, - це ми бачимо безліч точкових інтерфейсів з великою кількістю даних, що переміщуються в багатьох місцях. Нам потрібно вміти раціоналізувати це і розібратися в тій лінії даних, про яку я коротко згадувався раніше, щоб ми могли мати більш згуртовану стратегію, таку як використання сервісно-орієнтованої архітектури, службових шин для підприємств та подібних речей для надання правильної інформації на модель публікації та підписки, якою ми правильно користуємось у своєму бізнесі. І тоді, звичайно, нам ще потрібно зробити якусь аналітику, чи ми використовуємо сховища даних, сховища даних із традиційним ETL, чи використовуємо деякі нові озера даних. Все зводиться до одного і того ж. Це всі дані, будь то великі дані, чи це традиційні дані у реляційних базах даних, нам потрібно об'єднати всі ці дані, щоб ми могли ними керувати і знати, з чим ми маємо справу в наших моделях.
Знову ж таки, складність, яку ми збираємось зробити, це те, що ми маємо зробити ряд кроків, які ми хочемо зробити. Перш за все, ви заходите, і у вас, можливо, немає блюз того, як виглядає цей інформаційний пейзаж. У такому інструменті для моделювання даних, як ER / Studio Data Architect, ви спочатку збираєтеся робити багато зворотних інженерій з точки зору давайте вкажемо на джерела даних, які знаходяться там, ввести їх, а потім насправді зшити їх у більш представницькі моделі, які представляють весь бізнес. Важливим є те, чи хочемо ми мати змогу розкласти ці моделі також за бізнес-напрямками, щоб ми могли співвідносити їх з меншими шматками, до яких також можуть відноситись наші ділові люди, а також наші бізнес-аналітики та інші зацікавлені сторони, які працюють на цьому.
Стандарти називання є надзвичайно важливими, і я говорю про нього декількома різними способами. Названня стандартів з точки зору того, як ми називаємо речі в наших моделях. Це досить легко зробити в логічних моделях, де у нас є хороша умова іменування та хороший словник даних для наших моделей, але потім ми також бачимо різні умови іменування для багатьох цих фізичних моделей, які ми вводимо. Коли ми реверс-інженер, досить часто ми бачимо скорочені назви та такий тип речей, про який я поговорю. І нам потрібно перекласти їх назад на значущі англійські імена, які мають значення для бізнесу, щоб ми могли зрозуміти, що це за ці дані, які ми маємо в оточенні. І тоді універсальні відображення - це те, як ми їх зшиваємо разом.
Крім того, ми б потім документували та визначали далі, і саме там ми можемо додатково класифікувати наші дані за допомогою того, що називається "Додатки", і я покажу вам кілька слайдів. А потім закриваючи цикл, ми хочемо застосувати той діловий сенс, який ми пов’язуємо у своїх ділових словниках і можемо пов’язати їх з нашими артефактами різних моделей, тому ми знаємо, коли ми говоримо про певний термін бізнесу, де це реалізовані в наших даних у всій організації. І, нарешті, я вже говорив про те, що нам потрібно все це бути сховищем на основі багато можливостей співпраці та публікації, щоб наші зацікавлені сторони могли використовувати це. Я буду говорити про реверсивну техніку досить швидко. Я вже наче дав вам дуже швидку увагу на цьому. Я покажу це вам у фактичній демонстрації просто для того, щоб показати вам деякі речі, які ми можемо внести туди.
І я хочу поговорити про деякі різні типи моделей та діаграми, які ми створили б у такому сценарії. Очевидно, що ми будемо робити концептуальні моделі у багатьох випадках; Я не збираюсь витрачати на це багато часу. Я дуже хочу поговорити про логічні моделі, фізичні моделі та спеціалізовані типи моделей, які ми можемо створити. І важливо, щоб ми могли створити все це в одній платформі для моделювання, щоб ми могли їх зшити. Це включає мірні моделі, а також моделі, які використовують деякі нові джерела даних, наприклад, NoSQL, який я вам покажу. А далі, як виглядає модель родової даних? І як ми зв'язати ці дані у моделі бізнес-процесів - це те, про що ми поговоримо далі.
Я перейду сюди до модельного середовища просто для того, щоб отримати дуже високий та швидкий огляд. І я вважаю, ви повинні мати можливість бачити мій екран зараз. Перш за все, я хочу поговорити лише про традиційний тип даних. І те, як ми хочемо впорядкувати моделі, коли ми їх вводимо, - це те, що ми хочемо їх розкласти. Отже, що ви бачите тут зліва, ми маємо логічні та фізичні моделі в цьому конкретному файлі моделі. Наступне - ми можемо розбити їх під час розкладу бізнесу, і тому ви бачите папки. Світло-сині - це логічні моделі, а зелені - фізичні. І ми також можемо розширити, тому в рамках ER / Studio, якщо у вас є декомпозиція бізнесу, ви можете пройти стільки рівнів, як глибокі або підмоделі, як вам подобається, і зміни, які ви робите на нижчих рівнях, автоматично відображаються на вищих рівні. Так це дуже швидко стає дуже потужним середовищем моделювання.
Я також хочу зазначити, що дуже важливо почати збирати цю інформацію, це те, що ми можемо мати кілька фізичних моделей, що відповідають також одній логічній моделі. Досить часто у вас може бути логічна модель, але у вас можуть бути фізичні моделі на різних платформах і подібний тип речей. Можливо, це один екземпляр SQL Server, а може бути інший екземпляр Oracle. Ми маємо можливість зв'язати все це разом в одному модельному середовищі. І знову, що у мене тут є фактична модель сховища даних, яка, знову ж таки, може бути в тому ж середовищі моделювання, або ми можемо мати її у сховищі та також пов’язувати в різних речах.
Те, що я дуже хотів вам показати на цьому, - це деякі інші речі та інші варіанти моделей, до яких ми потрапляємо. Отже, коли ми потрапляємо у традиційну модель даних, як ця, ми звикли бачити типові сутності зі стовпцями та метаданими та подібним типом речі, але ця точка зору змінюється дуже швидко, коли ми починаємо мати справу з деякими з цих нових технологій NoSQL або, як деякі люди все ще люблять їх називати, технології великих даних.
Тож скажімо, ми також отримали вулик у своєму оточенні.Якщо ми повернемо інженера з середовища вулика - і зможемо перемотати інженера з вулика за допомогою цього самого інструменту моделювання - ми побачимо щось дещо інше. Ми все ще бачимо всі дані там як конструкції, але наші TDL відрізняються. Тим із вас, хто звик бачити SQL, те, що ви бачили б зараз, є Hive QL, який дуже схожий на SQL, але з того самого інструменту, який ви тепер можете почати працювати з різними мовами сценаріїв. Таким чином, ви можете моделювати в цьому середовищі, генерувати його в середовищі вулика, але так само важливо, що в сценарії, який я описав, ви можете переробити інженер все це і зрозуміти це, а також почати зшивати його разом. .
Візьмемо ще один, який трохи відрізняється. MongoDB - це ще одна платформа, яку ми підтримуємо на самому світі. І коли ви починаєте потрапляти в типи середовищ JSON, де у вас є магазини документів, JSON - це інша тварина, і в ній є конструкції, які не відповідають реляційним моделям. Ви незабаром починаєте мати справу з такими поняттями, як вбудовані об'єкти та вбудовані масиви об'єктів, коли ви починаєте допитувати JSON, і ці поняття не існують у традиційній реляційній позначенні. Що ми тут зробили, це те, що ми фактично розширили позначення та наш каталог, щоб мати змогу впоратися з цим у тому самому середовищі.
Якщо ви заглянете сюди зліва, замість того, щоб бачити такі речі, як сутності та таблиці, ми називаємо їх об’єктами. І ви бачите різні позначення. Тут ви все ще бачите типові типи посилань, але ці блакитні сутності, які я показую на цій конкретній схемі, - це фактично вбудовані об'єкти. І ми проявляємо різні кардинальності. Кардинальність алмазу означає, що це об'єкт з одного боку, але кардинальність одного означає, що у нас в межах видавця, якщо ми будемо слідувати цим відносинам, ми вбудуємо об'єкт адреси. Допитуючи JSON, ми виявили, що це точно та сама структура об'єктів, яка вбудована в меценат, але насправді вбудована у масив об’єктів. Ми бачимо це не тільки через самі роз'єми, але якщо ви подивитесь на фактичні об'єкти, ви побачите, що ви бачите адреси під покровителем, які також класифікують його як масив об’єктів. Ви отримуєте дуже описовий погляд на те, як ви можете це зробити.
І знову: тепер, що ми бачили поки що за кілька секунд, це традиційні реляційні моделі, які є багаторівневими, ми можемо зробити те ж саме з Hive, ми можемо зробити те ж саме з MongoDB та іншими джерелами великих даних, як Ну. Що ми також можемо зробити, і я збираюся це швидко вам показати, я говорив про факт залучення речей з інших регіонів. Я припускаю, що я імпортую модель з бази даних або реверсую її, але я збираюся вносити її із зовнішніх метаданих. Просто для швидкого огляду всіх типів речей, які ми можемо почати представляти.
Як бачите, у нас є безліч речей, за допомогою яких ми можемо насправді внести метадані в наше моделювання. Починаючи з таких речей, як навіть Amazon Redshift, Cassandra, багато інших великих платформ даних, тому ви перераховуєте багато перерахованих. Це в алфавітному порядку. Ми бачимо багато великих джерел даних і подібного роду речі. Ми також бачимо багато традиційних чи старих середовищ моделювання, завдяки яким ми можемо реалізувати ці метадані. Якщо я пройдусь сюди - і не збираюсь витрачати час на кожну з них - ми побачимо багато різних речей, з яких ми зможемо запровадити це, з точки зору моделювання платформ та платформ даних. І ось що дуже важливо усвідомити - це ще одна частина, яку ми можемо зробити, коли ми починаємо говорити про лінію даних, в Enterprise Team Edition ми також можемо допитати джерела ETL, будь то такі речі, як Talend або відображення інформаційних служб SQL Server, ми можемо насправді це приводить і до того, щоб почати наші діаграми рядкових даних, і намалювати картину того, що відбувається в цих перетвореннях. Загалом у нас є понад 130 цих різних мостів, які насправді є частиною продукту Enterprise Team Edition, тому це дійсно допомагає нам дуже швидко зібрати всі артефакти в одне середовище моделювання.
І останнє, але не менш важливе, я також хочу поговорити про те, що ми не можемо втрачати з уваги той факт, що нам потрібні інші типи конструкцій, якщо ми робимо зберігання даних або будь-які види аналітики. Ми все ще хочемо мати можливість робити такі речі, як розмірні моделі, де у нас є таблиці фактів, а у нас розміри та такі речі. Я хочу вам також показати, що ми також можемо мати розширення до наших метаданих, які допомагають нам класифікувати, які типи вимірів та все інше. Отже, якщо я перегляну тут вкладку розмірних даних, наприклад, на одній із них, вона насправді автоматично виявить, виходячи з модельної моделі, яку вона бачить, і дасть тобі вихідний погляд на те, чи вважає він це розмірність чи таблиця фактів. Але крім того, що ми можемо зробити, це всередині розмірів і такого типу речей, у нас навіть є різні типи розмірів, які ми можемо використовувати для класифікації даних також у середовищі зберігання даних. Настільки потужні можливості, з якими ми цілком зшиваємо це.
Я збираюся перейти до цього, оскільки зараз перебуваю в демо-середовищі, і покажу вам кілька інших речей, перш ніж повернутися до слайдів. Одне з речей, які ми нещодавно додали до ER / Studio Data Architect, - це те, що ми стикаємося з ситуаціями - і це дуже поширений випадок використання, коли ви працюєте над проектами - розробники думають щодо об'єктів, тоді як наші дані Моделі, як правило, мислять за таблицями та сутностями та типом речі. Це дуже спрощена модель даних, але вона представляє кілька основних понять, де розробники або навіть бізнес-аналітики або бізнес-користувачі можуть вважати їх різними об'єктами чи бізнес-концепціями. Класифікувати їх до цього часу було дуже важко, але те, що ми насправді зробили в ER / Studio Enterprise Team Edition, у випуску 2016 року, чи є у нас тепер концепція під назвою «Бізнес-об’єкти даних». І що нам це дозволяє, це дозволяє нам інкапсулювати групи сутностей або таблиць у справжні бізнес-об’єкти.
Наприклад, те, що ми маємо тут у цьому новому представленні, - це заголовок замовлення на замовлення та рядок замовлень, зібрані разом, вони інкапсульовані як об'єкт, і ми вважатимемо їх одиницею роботи, коли збережемо дані , і ми об'єднуємо їх так, що зараз це дуже легко пов'язати з різними аудиторіями. Їх можна використовувати повторно у всьому середовищі моделювання. Вони є справжнім об'єктом, а не просто конструкцією малювання, але ми також маємо додаткову перевагу, що коли ми реально спілкуємось з точки зору моделювання, ми можемо вибірково їх згортати або розширювати, щоб ми могли створити узагальнену думку для діалогів з певною зацікавленою аудиторією, і ми, звичайно, можемо зберегти більш детальний вигляд, як ми бачимо тут для більшої кількості технічних аудиторій. Це насправді дає нам справді хороший засіб спілкування. Зараз ми бачимо комбінування декількох типів моделей, доповнення їх до поняття об’єктів бізнес-даних, а тепер я поговорю про те, як ми насправді застосовуємо ще певний сенс до цих типів речей і як ми з'єднуємо їх разом загальне середовище.
Я просто намагаюся знайти свій WebEx тут, щоб я міг це зробити. І ми їдемо назад до слайдів Hot Tech. Я збираюся просунути сюди кілька слайдів, тому що ви їх вже бачили на самій демонстрації моделі. Я хочу дуже швидко поговорити про найменування стандартів. Ми хочемо застосовувати та застосовувати різні стандарти іменування. Що ми хочемо зробити, ми маємо можливість насправді зберігати шаблони стандартів імен у наших сховищах, щоб в основному будувати це значення за допомогою слів або фраз або навіть абревіатур, а також прив'язувати їх до значущого англійського типу слова. Ми будемо використовувати бізнес-терміни, абревіатури для кожного, і ми можемо вказати порядок, регістри та додавати префікси та суфікси. Типовий випадок використання для цього, як правило, коли люди будують логічну модель, а потім фактично йдуть вперед, щоб створити фізичну модель, де вони могли б використовувати абревіатури та все інше.
Прекрасна річ у тому, що вона настільки ж потужна, ще більш потужна в зворотному напрямку, якщо ми можемо просто сказати, які деякі з цих стандартів іменування були в деяких із тих фізичних баз даних, які ми спроектували назад, ми можемо взяти ці скорочення, перетворити їх на довші слова, і поверніть їх назад в англійські фрази. Зараз ми можемо отримати власні імена для того, як виглядають наші дані. Як я кажу, типовим випадком використання є те, що ми рухатимемося вперед, логічно до фізичного, і відображаємо сховища даних і подібний тип речей. Якщо ви подивитесь на скріншот праворуч, ви побачите, що у назв джерел є скорочені імена, і коли ми застосували шаблон стандартних імен, ми отримали більш повні імена. І ми можемо помістити пробіли і все подібне, якщо хочемо, залежно від шаблону стандартів іменування, який ми використовували. Ми можемо зробити його схожим, однак ми хочемо, щоб це було втілено у наші моделі. Тільки коли ми знаємо, що щось називається, ми можемо насправді почати прикріплювати до нього визначення, бо якщо ми не знаємо, що це таке, як ми можемо застосувати до нього значення?
Приємно, що ми можемо насправді посилатися на це, коли робимо всілякі речі. Я говорив про реверсивну інженерію, ми можемо покликатись одночасно шаблони імен стандартів, коли ми робимо зворотну інженерію. Таким чином, за один набір кроків за допомогою майстра ми можемо зробити це, якщо ми знаємо, що таке конвенції, ми можемо повернути інженеру фізичну базу даних, вона поверне її як фізичну модель в середовище моделювання, і це також буде застосовано ці угоди про іменування. Тож ми побачимо, які англоподібні уявлення імен знаходяться у відповідній логічній моделі в оточенні. Ми також можемо це зробити і комбінувати його з генерацією XML Schema, щоб ми могли взяти модель і навіть висунути її за допомогою наших абревіатур, чи ми робимо рамки SOA, чи подібний тип речей, тож ми можемо також витіснити різні умови іменування що ми насправді зберігаємо в самій моделі. Це дає нам дуже багато потужних можливостей.
Знову ось приклад того, як це виглядало б, якби у мене був шаблон. Це насправді показує, що у мене було встановлено ПДП для «працівника», ПДВ для «зарплати», ПЛН для «плану» в конвенції про стандарти іменування. Я також можу застосувати їх, щоб вони працювали в інтерактивному режимі, коли я створював моделі та розміщував речі. Якщо я використовував цю абревіатуру і вводив "План заробітної плати працівника" на ім'я суб'єкта, він би діяв із шаблоном стандартів іменування Я тут визначив, це дало б мені EMP_SAL_PLN, коли я створював сутності і давав мені відповідні фізичні імена відразу.
Знову ж таки, дуже добре, коли ми також розробляємо та передаємо інжиніринг. У нас дуже унікальна концепція, і саме тут ми дійсно починаємо зближувати ці середовища. І це називається Universal mappings. Після того, як ми внесли всі ці моделі в наше середовище, що ми можемо зробити, припускаючи, що зараз ми застосували ці умови іменування і їх легко знайти, тепер ми можемо використовувати конструкцію під назвою Universal Mappings в ER / Студія. Ми можемо зв’язувати об'єкти в різних моделях. Де б ми не побачили "замовника" - напевно, у нас буде "замовник" у безлічі різних систем і в багатьох різних базах даних - ми можемо почати зв'язувати все це разом, щоб, коли я працюю з ним в одній моделі, я Ви можете побачити, де прояви клієнтів в інших моделях. А оскільки у нас є модельний шар, який це представляє, ми можемо навіть пов’язати його з джерелами даних і зменшити його до наших запитів, де використовуються, в яких базах даних також знаходиться. Це насправді дає нам можливість зв'язати все це разом згуртовано.
Я показав вам об’єкти бізнес-даних. Я також хочу дуже швидко поговорити про розширення метаданих, які ми називаємо додатками. Що це робить, це дає нам можливість створювати додаткові метадані для наших модельних об'єктів. Досить часто я налаштовував би такі типи властивостей, щоб виганяти багато різних речей з точки зору управління даними та якістю даних, а також для того, щоб допомогти нам в управлінні даними та політикою збереження даних. Основна ідея полягає в тому, щоб ви створили ці класифікації, і ви зможете додавати їх куди завгодно, на рівні таблиці, на рівні стовпців, тих типів речей. Звичайно, найчастішим випадком використання є те, що сутності є таблицями, і тоді я можу визначити: що таке мої об'єкти основних даних, які мої довідкові таблиці, які мої транзакційні таблиці? З точки зору якості даних я можу робити класифікації за важливістю для бізнесу, щоб ми могли визначити пріоритетні зусилля з очищення даних та такого типу речей.
Те, що часто не помічається, це те, яка політика збереження різних типів даних в нашій організації? Ми можемо їх налаштувати, і ми можемо фактично їх прикріпити до різних типів інформаційних артефактів у нашому середовищі моделювання та, звичайно, також у нашому сховищі. Краса полягає в тому, що ці вкладені файли містяться в нашому словнику даних, тому коли ми використовуємо словники корпоративних даних у навколишньому середовищі, ми можемо додавати їх до декількох моделей. Ми мусимо їх лише один раз визначити, і ми можемо використовувати їх знову і знову в різних моделях у нашому середовищі. Це лише швидкий скріншот, який показує, що ви можете фактично вказати, коли ви робите вкладення, які всі фрагменти, до яких ви хочете вкласти його. І цей приклад тут насправді є переліком значень, тож, коли вони збираються, ви можете вибрати зі списку значень, у вас є великий контроль у середовищі моделювання того, що вибирається, і ви навіть можете встановити, що за замовчуванням значення - якщо значення не вибрано. Так що багато сил там. Вони живуть у словнику даних.
Щось я хочу показати вам трохи нижче на цьому екрані, крім того, ви бачите, що вкладення відображаються у верхній частині, під ним ви бачите інформацію про безпеку даних. Ми можемо реально застосовувати політику безпеки даних і до різних відомостей у навколишньому середовищі. Для різних відображень відповідності, класифікацій безпеки даних ми доставляємо їх декілька з вікна, які ви можете просто створити та почати використовувати, але ви також можете визначити власні відображення та стандарти відповідності. Незалежно від того, чи займаєтесь ви HIPAA чи будь-якою з інших ініціатив там. І ви дійсно можете почати створювати цей дуже багатий набір метаданих у вашому оточенні.
І тоді Глосарій та терміни - саме тут пов’язано ділове значення. У нас досить часто є словники даних, які досить часто організація використовує як вихідну точку, щоб почати виганяти словники, але термінологія та словесність - це часто дуже технічні.Тож, що ми можемо зробити, ми можемо, якщо бажаємо, використати їх як вихідну точку, щоб вигнати глосарії, але ми дійсно хочемо, щоб бізнес володів цими. Те, що ми зробили в середовищі командного сервера, - це дано можливість людям створювати бізнес-визначення, а потім ми можемо пов’язати їх з різними артефактами моделі, яким вони відповідають і в середовищі моделювання. Ми також визнаємо тему, про яку йшлося раніше: чим більше людей ви набираєте, тим більше можливостей для людських помилок. Те, що ми також робимо в нашій структурі глосарію, - це одне, ми підтримуємо ієрархію словника, тому ми можемо мати різні типи словників чи різні типи речей в організації, але так само важливо, якщо ви вже маєте деякі з цих джерел з термінами та всім визначеним, ми можемо фактично імпортувати CSV, щоб перетягнути їх у наше моделювання, а також наш сервер команди чи наш глосарій, а потім почати посилатися звідти. І кожного разу, коли щось змінюється, є повний аудиторський слід того, якими були образи до та після, з точки зору визначень та всього іншого, і те, що ви збираєтеся побачити в найближчому майбутньому, також є більш робочим процесом авторизації. тож ми можемо реально контролювати того, хто це відповідає, затвердження комітетами чи особами та подібні речі, щоб зробити процес управління ще більш міцним у міру просування.
Це також робить для нас те, що ми маємо ці терміни в словниковому словнику нашого командного сервера, це приклад редагування сутності в самій моделі, яку я тут привів. У нього можуть бути пов'язані терміни, але те, що ми також робимо, - це якщо слова, що знаходяться в цьому словнику, відображаються в примітках або описах того, що ми маємо тут у наших сутностях, вони автоматично відображаються в більш світлому гіперпосилання, і якщо ми наведення миші на них, ми також можемо побачити визначення з ділового словника. Це навіть дає нам більш багату інформацію, коли ми споживаємо інформацію самі, з усіма термінами глосарію, які там є. Це дійсно допомагає збагатитися досвідом та застосувати значення до всього, з чим ми працюємо.
Отже, знову ж таки, це був дуже швидкий проліт. Очевидно, що ми могли б витратити дні на це, коли ми заглиблюємось у різні частини, але це дуже швидкий проліт над поверхнею. Ми дійсно прагнемо зробити це зрозуміти, як виглядають ці складні середовища передачі даних. Ми хочемо покращити видимість усіх цих артефактів даних та співпрацювати, щоб вигнати їх з ER / Studio. Ми хочемо забезпечити більш ефективне та автоматизоване моделювання даних. І це всі типи даних, про які ми говоримо, будь то великі дані, традиційні реляційні дані, сховища документів або щось інше. І знову ми це зробили, оскільки у нас є потужні можливості для прямого і зворотного проектування для різних платформ та інших інструментів, які у вас можуть бути там. І все стосується спільного використання та спілкування в організації з усіма зацікавленими сторонами. Ось де ми застосовуємо значення через стандарти іменування. Потім ми застосовуємо визначення через наші бізнес-словники. Тоді ми можемо зробити додаткові класифікації для всіх інших наших можливостей управління за допомогою розширень метаданих, таких як розширення якості даних, класифікацій для головного управління даними чи будь-яких інших типів класифікацій, які ви хочете застосувати до цих даних. І тоді ми можемо ще більше підсумувати та ще більше покращити спілкування з об’єктами бізнес-даних, з різною аудиторією зацікавлених сторін, особливо між моделерами та розробниками.
І знову ж таки, що в цьому дуже важливо, за цим стоїть інтегрований сховище з дуже надійними можливостями управління змінами. Я не мав часу показувати це сьогодні, оскільки він стає досить складним, але сховище має дуже надійні можливості управління змінами та аудиторські траси. Ви можете робити іменовані випуски, ви можете іменовані версії, і ми також маємо можливість для тих із вас, хто займається управлінням змінами, ми можемо вкласти це право у ваші завдання. Сьогодні ми маємо можливість ставити завдання та пов'язувати зміни вашої моделі із завданнями, подібно до того, як розробники пов'язували б зміни коду із завданнями чи історіями користувачів, з якими вони також працюють.
Знову, це був дуже швидкий огляд. Я сподіваюсь, що цього було достатньо, щоб розкрити апетит, щоб ми могли вести набагато глибші розмови щодо розбиття деяких з цих тем, коли ми будемо в майбутньому. Дякую за витрачений час і повертаємось, Ребекка.
Ребекка Йозвяк: Дякую, Рон, це було фантастично, і у мене є досить багато запитань від аудиторії, але я хочу дати шанс нашим аналітикам занурити зуби в те, що ти мав сказати. Еріку, я збираюся йти вперед і, можливо, якщо ти хочеш розібратися з цим слайдом чи іншим, чому ти не підеш спочатку? Або будь-яке інше питання.
Ерік Літл: Звичайно. Вибачте, в чому питання, Ребекка? Ви хочете, щоб я запитав щось конкретне або ...?
Ребекка Йозвяк: Я знаю, що у вас були кілька запитань до Рона. Якщо ви хочете зараз попросити його звернутися до будь-якого з них, або до якогось із ваших слайдів чи ще чогось, що викликало ваш інтерес, про який ви хочете запитати? Про функції моделювання IDERA
Ерік Літл: Так, одна з речей, Рон, так як ви, хлопці, схоже, діаграми, які ви показували, - це загальні типи діаграм відносин між сутностями, як ви зазвичай використовуєте при побудові бази даних, правда?
Рон Хуйзенга: Так, загалом кажучи, але, звичайно, ми маємо розширені типи для зберігання документів і такого типу речей. Ми насправді відрізняємося від чистого реляційного позначення, ми також додавали додаткові позначення і для інших магазинів.
Ерік Літл: Чи є спосіб, щоб ви, хлопці, могли використовувати типи моделювання на основі графіків, то є спосіб інтегрувати, наприклад, припустимо, що у мене є щось на зразок верхнього квадранта, інструмента композитора TopBraid або я щось зробив у Protégé або Ви знаєте, як фінансові хлопці FIBO, вони роблять багато роботи в семантиці, RDF - чи є спосіб залучити до цього інструменту моделювання типу графіків відносин між сутностями та використовувати його?
Рон Хуйзенга: Ми насправді дивимося, як ми можемо обробляти графіки. Сьогодні ми не обробляємо явно бази даних графіків та подібні речі, але ми розглядаємо способи, як це зробити для розширення наших метаданих. Я маю на увазі, ми можемо вносити речі через XML і цей тип речей прямо зараз, якщо ми можемо хоча б зробити якесь передання XML, щоб привести його як вихідну точку. Але ми розглядаємо більш елегантні способи залучити це.
І я також показав вам той список мостів зворотного проектування, який у нас також є, тому ми завжди шукаємо розширення до цих мостів для конкретних платформ. Постійно, постійно триваючи зусилля, якщо це має сенс, почати приймати багато цих нових конструкцій та різних платформ там. Але я можу сказати, що ми безумовно на перших очах цього. На речі, які я показав, наприклад, на MongoDB, і подібний тип речей, ми перший постачальник моделювання даних, який насправді робив це в нашому власному продукті.
Ерік Літл: Гаразд, так. Тож інше питання, яке у мене виникло до вас, стосувалось управління та підтримки - як, коли ви використовували приклад, коли ви показували приклад людини, яка є "працівником", я вважаю, що це " зарплата ", і тоді у вас є" план ", чи є спосіб, як ви керуєте, наприклад, різними типами людей, які можуть мати - припустимо, у вас є велика архітектура, правда, припустимо, у вас є велике підприємство і люди починають поєднувати речі разом із цим інструментом, і у вас тут є одна група, яка має слово «працівник», і одна група, яка має слово «працівник». І одна людина тут каже «зарплата», а інша каже "Заробітна плата".
Як ви, хлопці, погоджуєте та керуєте такими відмінностями? Тому що я знаю, як ми це зробили б у світі графів, ви знаєте, ви б використовували списки синонімів, або ви сказали б, що є одне поняття і воно має кілька атрибутів, або ви можете сказати, що у моделі SKOS я маю перевагу мітка, і у мене є численні альтернативні мітки, які я можу використовувати. Як ви це робите?
Рон Хуйзенга: Ми робимо це декількома різними способами, і перш за все давайте поговоримо про термінологію. Одним із речей, які ми робимо, звичайно, є те, що ми хочемо мати визначені або санкціоновані умови, і в словнику бізнесу, очевидно, є те, де ми їх хочемо. І ми дозволяємо посилання на синоніми у бізнес-словнику, і тому, що ви можете зробити, ви можете сказати, ось мій термін, але ви також можете визначити, що всі синоніми для них.
Цікавою річчю, звичайно, є те, що коли ти починаєш переглядати цей величезний пейзаж даних із усіма цими різними системами, які ви там вийшли, ви не можете просто вийти туди і змінити відповідні таблиці та типи речей на відповідають цьому стандарту іменування, оскільки це може бути пакет, який ви купили, тому ви не маєте контролю над зміною бази даних або взагалі будь-чим.
Те, що ми могли б зробити там, окрім того, щоб пов’язати визначення словника, - це через ті універсальні відображення, про які я говорив, що ми робимо, і такий тип рекомендованого підходу - це мати загальну логічну модель, яка визначає, що ці різні бізнес-концепції - це те, про що ви говорите. Зв’яжіть терміни бізнес-словника в ті, і приємно, що тепер у вас є ця конструкція, яка як би представляє логічну сутність, ви можете почати зв'язувати цю логічну сутність з усіма реалізаціями цього логічного об'єкта в різні системи.
Тоді, де вам це потрібно, ви можете побачити, о, "людина" тут називається "працівник" у цій системі. Тут у цій іншій системі "зарплата" називається "заробітна плата". Оскільки ви побачите це, ви побачите всі різні прояви тих, тому що ви пов’язали їх між собою.
Ерік Літл: Гаразд чудово, так, зрозумів. У цьому сенсі чи можна сказати, що це на зразок деяких об'єктно-орієнтованих підходів?
Рон Хуйзенга: Дещо. Це трохи інтенсивніше, ніж, я думаю, ви могли б сказати. Я маю на увазі, ви можете скористатися підходом до того, щоб вручну зв’язувати та проходити, а також перевіряти та робити все. Єдине, про що я не мав можливості поговорити - тому що ми знову маємо багато можливостей - у нас також є повний інтерфейс автоматизації в самому інструменті Data Architect. І макроспроможність, яка дійсно є мовою програмування в інструменті. Тож ми можемо насправді робити такі речі, як писати макроси, випускати їх і допитувати і створювати посилання для вас. Ми використовуємо його для імпорту та експорту інформації, ми можемо використовувати її для зміни речей або додавання атрибутів, подій, що базуються на самій моделі, або ми можемо використовувати її для запуску партіями, щоб насправді виходити і допитувати речі, а також фактично заселяти різні конструкції в модель. Отже, є повний інтерфейс автоматизації, яким користуються і люди. І використання універсальних відображень з ними було б дуже потужним способом зробити це.
Ребекка Йозвяк: Добре, дякую Рона, і дякую Еріку. Це були чудові запитання. Я знаю, що ми пробігаємо трохи пізніше вершини години, але я хотів би дати Малкольму шанс підкинути деякі питання Рону. Малькольм?
Малькольм Чизгольм: Спасибі, Ребекка. Отже, Рон, це дуже цікаво, я бачу, що тут дуже багато можливостей. Одним із напрямків, які мене дуже цікавлять, є, наприклад, якщо у нас є проект розвитку, як ви бачите моделяра даних, використовуючи ці можливості, і, можливо, співпрацюєте з бізнес-аналітиками, з профілером даних та аналітиком якості даних. , а також із бізнес-спонсорами, які в кінцевому рахунку будуть відповідати за фактичні вимоги до інформації в проекті. Наскільки насправді, відомо, моделер даних робить проект більш ефективним та ефективним завдяки можливостям, які ми розглядаємо?
Рон Хуйзенга: Я думаю, що одне з перших, що вам потрібно зробити там, - це як модельєр даних - і я не маю на увазі вибирати деяких моделерів, але все одно, - це у деяких людей все ще складається враження, що модельєр даних насправді такий тип ролі воротаря, ми визначаємо, як це працює, ми - охоронці, які впевнені, що все правильно.
Тепер є аспект цього, що ви повинні переконатися, що ви визначаєте здорову архітектуру даних та все інше. Але найважливіше - це модельєр даних - і це я виявив досить очевидно, коли консультувався - чи ти повинен стати фасилітатором, тож ти повинен зібрати цих людей разом.
Це вже не буде проектувати, створювати, створювати бази даних більше - те, що вам потрібно вміти, - вам потрібно вміти працювати з усіма цими різними групами зацікавлених сторін, роблячи такі речі, як зворотна інженерія, імпорт інформації, наявність інші люди співпрацюють, будь то в глосаріях чи документації, все подібне - і бути фасилітатором, щоб перетягнути це у сховище та зв’язати поняття разом у сховищі та працювати з цими людьми.
Насправді це набагато більше середовище спільного використання, коли навіть через визначення завдань чи навіть теми дискусій або те, що ми маємо на командному сервері, люди можуть насправді співпрацювати, задавати питання та дійти до кінцевих кінцевих продуктів, які вони потреба в їх архітектурі даних та їх організації. Це така відповідь?
Малькольм Чизгольм: Так, я згоден. Ви знаєте, я думаю, що навички полегшення - це те, що дуже бажано в моделях даних. Я погоджуюся, що ми не завжди бачимо це, але я вважаю, що це необхідно, і я б припустив, що іноді є схильність залишатися у своєму кутку, роблячи своє моделювання даних, але вам дійсно потрібно бути там, працюючи з іншими групами зацікавлених сторін. або ви просто не розумієте середовище даних, з яким ви маєте справу, і я думаю, що в результаті модель страждає. Але це лише моя думка.
Рон Хуйзенга: І це цікаво тим, що ви згадували щось раніше у своєму слайді про історію про те, як бізнес відбивається від ІТ, оскільки вони не вчасно постачали рішення та подібні речі.
Дуже цікаво, що в моїх наступних консультаційних заходах, перш ніж стати менеджером із продуктів, більшість проектів, які я робив за останні два роки до цього, були спонсоровані бізнесом, де саме це було саме тим, що саме керувало цим бізнесом та архітекторами даних і модельєри не були частиною ІТ. Ми були частиною спонсорованої бізнес-групи, і ми були там як фасилітатори, що працювали з рештою команд проекту.
Малькольм Чизгольм: Тож я думаю, що це дуже цікавий момент.Я думаю, що ми починаємо бачити зрушення в діловому світі, де бізнес запитує, або думає, може, не стільки, як я роблю, як процес, але вони також починають думати про те, які дані з якою я працюю, які потреби в моїх даних, які дані, з якими я маю справу, і в якій мірі ми можемо отримати продукти та можливості IDERA для підтримки цієї точки зору, і я думаю, що потреби бізнесу, навіть хоча це все-таки трохи зароджується.
Рон Хуйзенга: Я погоджуюся з вами, і я думаю, що ми бачимо, що це все більше і більше йде. Ми бачили пробудження, і ви торкнулися його раніше щодо важливості даних. Ми бачили важливість даних на початку ІТ або в еволюції баз даних, тоді, як ви кажете, ми наче ввійшли в цілий цикл управління процесами - і процес надзвичайно важливий, не зрозумійте мене там неправильно - але тепер, що сталося коли це сталося, дані втратили фокус.
І зараз організації усвідомлюють, що дані справді є основним центром. Дані являють собою все, що ми робимо у своєму бізнесі, тому нам потрібно переконатися, що ми маємо точні дані, щоб ми могли знайти правильну інформацію, необхідну для прийняття наших рішень. Тому що не все виходить із визначеного процесу. Частина інформації є побічним продуктом інших речей, і нам ще потрібно вміти її знаходити, знати, що це означає, і вміти переводити дані, які ми бачимо там, в кінцевому підсумку в знання, які ми можемо використовувати для кращого розвитку нашого бізнесу.
Малькольм Чизгольм: Так, а тепер інша сфера, з якою я боровся, - це те, що я би назвав життєвим циклом даних, це, ви знаєте, якщо ми подивимось на тип ланцюга подачі даних, що проходить через підприємство, ми б почали зі збору даних або збирання даних, що може бути введенням даних, але це може бути однаково, я отримую дані за межами підприємства від якогось постачальника даних.
А потім від збирання даних ми переходимо до обслуговування даних, де я думаю про стандартизацію цих даних і пересилання їх в місця, де це потрібно. А потім використовуйте дані, фактичні точки, де є дані, ви отримаєте значення з даних.
За старих часів це робиться в одному індивідуальному стилі, але сьогодні це, може бути, аналітичне середовище, наприклад, а потім, крім цього, архів, магазин, куди ми зберігаємо дані, коли нас більше немає. це потрібно і, нарешті, процес очищення. Яким ви бачите моделювання даних, яке вписується в управління цілим життєвим циклом даних?
Рон Хуйзенга: Це дуже гарне запитання, і одне, чого я сьогодні взагалі не встиг заглибитись у будь-яку деталь, це те, про що ми дійсно починаємо говорити, - це лінія даних. Тож, що ми насправді можемо зробити, це те, що ми маємо можливість передачі даних у наших інструментах, і, як я вже кажу, ми можемо фактично дістати частину з інструментів ETL, але ви також можете відобразити це, просто накресливши і рядки. Будь-яка з цих моделей даних або баз даних, які ми захопили та ввели у моделі, ми могли б посилатися на конструкції з цієї схеми в нашій діаграмі рядків даних.
Що ми можемо зробити, це зробити потік даних, як ви кажете, від джерела до цільового, і через загальний життєвий цикл того, як ці дані проходять через різні системи, і що ви збираєтеся знайти, візьмемо працівників 'дані - це одне з моїх улюблених на основі проекту, який я робив років тому. Я працював з організацією, яка мала дані про співробітників у 30 різних системах. Що ми в кінцевому підсумку робили там - і Ребекка вискочила слайд рядка даних - це досить спрощений слайд рядка даних тут, але те, що ми змогли зробити, це внести всі структури даних, посилати їх на діаграмі, а потім ми насправді можна почати розглядати, якими є потоки між собою, і як ці різні сукупності даних пов'язані між собою в потоці? І ми також можемо вийти за рамки цього. Це частина потоку даних або діаграма рядків, яку ми бачимо тут. Якщо ви хочете вийти за рамки цього, у нас також є бізнес-архітектор, частина цього набору - це те саме.
Будь-яка з структур даних, яку ми захопили в середовищі моделювання даних, на них можна посилатися в інструменті бізнес-моделювання, так що навіть у діаграмах вашої бізнес-моделі або діаграмах бізнес-процесів ви можете посилатися на окремі сховища даних, якщо ви хочете вийти з середовище моделювання даних, і, використовуючи їх у папках моделі бізнес-процесів, ви навіть можете вказати CRUD на них також щодо того, як ця інформація споживається або виробляється, і тоді ми можемо почати генерувати такі речі, як звіти про вплив та аналіз та діаграми.
На що ми прагнемо досягти, і ми вже маємо багато можливостей, але одна з речей, яку ми маємо, як такий собі стовп цілі, на який ми дивимось, коли ми продовжуємо розвивати наші інструменти вперед, в змозі відобразити цю організаційну лінійку даних в кінці до кінця та повний життєвий цикл даних.
Малькольм Чизгольм: Добре. Ребекка, мені дозволено ще одного?
Ребекка Йозвяк: Я дозволю вам ще один, Малькольм, йти вперед.
Малькольм Чизгольм: Дуже дякую. Розмірковуючи про управління даними та думаючи про моделювання даних, як ми змусимо ці дві групи ефективно працювати разом та розуміти одна одну?
Ерік Літл: Ну це цікаво, я думаю, що це дійсно залежить від організації, і це повертається до моєї попередньої концепції: в тих організаціях, де ініціативи керувались бізнесом, ми були зв'язані прямо. Наприклад, я очолював команду архітектури даних, але ми були пов'язані прямо з діловими користувачами, і ми фактично допомагали їм відстоювати свою програму управління даними. Знову ж таки, більше консультативного підходу, але це справді більше ділової функції.
Що вам справді потрібно зробити, це вам потрібні модельєри даних та архітектори, які справді розуміють бізнес, можуть стосуватися бізнес-користувачів, а потім допомогли їм відстояти процеси управління навколо нього. Бізнес хоче це зробити, але, загалом кажучи, у нас є знання технологій, щоб можна було допомогти їм виділити ці типи програм. Це дійсно має бути співпрацею, але це має бути власністю бізнесу.
Малькольм Чизгольм: Гаразд, це чудово. Дякую.
Доктор Ерік Літл: Добре.
Ребекка Йозвяк: Гаразд, велике спасибі Члени аудиторії, я боюся, що ми не дійшли до ваших питань, але я переконуюсь, що вони перейдуть до відповідного гостя, якого ми сьогодні мали на лінії. Хочеться подякувати тобі Еріку, Малкольму та Рону за те, що сьогодні були нашими гостями. Це були чудові речі, люди. І якщо вам сподобалася сьогоднішня трансляція IDERA, IDERA також буде наступною середою на Hot Technologies, якщо ви хочете приєднатися, обговоривши проблеми індексації та Oracles, тому ще одна захоплююча тема.
Дякую тобі, люди, будьте уважні, і ми побачимось наступного разу. Бувай.