Сотрудники Techopedia, 28 сентября 2016 г.
Вывод: Хозяин Ребекка Йозвиак обсуждает решения по архитектуре данных с Эриком Литтлом из OSTHUS, Малколмом Чисхолмом из First San Francisco Partners и Роном Хуизенга из IDERA.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Ребекка Йозвиак: Уважаемые дамы и господа, привет и добро пожаловать в Hot Technologies 2016 года. Сегодня мы обсуждаем «Построение архитектуры данных на основе бизнеса», безусловно, горячая тема. Меня зовут Ребекка Йозвиак, я буду вашим организатором сегодняшней веб-трансляции. Мы пишем в Твиттере с хэштегом # HotTech16, поэтому, если вы уже в Twitter, присоединяйтесь и к этому. Если у вас есть вопросы в любое время, отправьте их на панель вопросов и ответов в правом нижнем углу экрана, и мы обязательно ответим на них. Если нет, мы позаботимся о том, чтобы наши гости получили их для вас.
Итак, сегодня у нас действительно захватывающий состав. Сегодня у нас много сильных нападающих. У нас есть Эрик Литтл, вице-президент по науке данных из OSTHUS. У нас есть Малкольм Чизхолм, директор по инновациям, что действительно здорово, для First San Francisco Partners. И у нас есть Рон Хуэйзенга, старший менеджер по продукции из IDERA. И, знаете, IDERA - это действительно полный набор решений для управления данными и моделирования. И сегодня он собирается продемонстрировать нам, как работает его решение. Но прежде чем мы дойдем до этого, Эрик Литтл, я собираюсь передать тебе мяч.
Эрик Литтл: Хорошо, большое спасибо. Итак, я собираюсь пройтись по нескольким темам, которые, я думаю, будут немного связаны с выступлением Рона, и, надеюсь, подготовить почву для некоторых из этих тем, а также для некоторых вопросов и ответов.
То, что меня заинтересовало то, что делает IDERA, так это то, что, как мне кажется, они правильно указывают, что сложные среды сегодня действительно способствуют развитию многих бизнес-ценностей. И под сложными средами мы подразумеваем сложные среды данных. И технологии действительно быстро развиваются, и их трудно поддерживать в современной бизнес-среде. Поэтому те, кто работает в технологических областях, часто видят, что у вас есть клиенты, которые решают проблемы: «Как использовать большие данные? Как включить семантику? Как я могу связать некоторые из этих новых вещей с моими более старыми данными? »И так далее, и такого рода в настоящее время приводит нас к этим четырем v больших данных, с которыми многие люди хорошо знакомы, и я понимаю, что может быть больше четырех иногда - я видел целых восемь или девять - но обычно, когда люди говорят о таких вещах, как большие данные или если вы говорите о больших данных, вы обычно смотрите на что-то вроде масштаба предприятия. И поэтому люди скажут: «Хорошо, хорошо, подумайте об объеме ваших данных, который обычно находится в центре внимания - это только, сколько у вас есть». Скорость данных связана с тем, насколько быстро я могу перемещать их или как быстро я могу запрашивать их или получать ответы, и так далее. И лично я думаю, что левая сторона этого - то, что решается и обрабатывается относительно быстро многими различными подходами. Но с правой стороны я вижу много возможностей для улучшения и множество новых технологий, которые действительно выходят на первый план. И это действительно связано с третьим столбцом, разнообразием данных.
Другими словами, в настоящее время большинство компаний рассматривают структурированные, полуструктурированные и неструктурированные данные. Данные изображений начинают становиться горячей темой, поэтому, имея возможность использовать компьютерное зрение, смотреть на пиксели, иметь возможность очищать текст, НЛП, извлекать объекты, у вас есть графическая информация, которая поступает либо из статистических моделей, либо из семантической. модели, у вас есть реляционные данные, которые существуют в таблицах, и так далее. И поэтому объединение всех этих данных и всех этих различных типов действительно представляет большую проблему, и вы увидите это, как вы знаете, в Gartner и других людях, которые как бы следят за тенденциями в отрасли.
И, наконец, последнее, о чем люди говорят в больших данных, часто это понятие прожорливости, которое на самом деле является неопределенностью ваших данных, нечеткостью их. Насколько хорошо вы знаете, о чем ваши данные, насколько хорошо вы понимаете, что там, и вы знаете? Здесь может быть полезна возможность использовать статистику и возможность использовать некоторую информацию о том, что вы, возможно, знаете, или использовать некоторый контекст. И, таким образом, возможность смотреть на данные таким образом с точки зрения того, сколько у вас есть, как быстро вам нужно их перемещать или получать, все типы данных, которые вы можете иметь на своем предприятии, и насколько вы уверены в том, где это, что это такое, какое качество, и так далее. Это действительно требует больших скоординированных усилий многих людей для эффективного управления своими данными. Поэтому моделирование данных становится все более важным в современном мире. Таким образом, хорошие модели данных действительно приносят большой успех в корпоративных приложениях.
Как мы говорили, у вас есть источники данных из разных источников, которые действительно требуют много разных видов интеграции. Поэтому объединить все это очень полезно, чтобы иметь возможность выполнять запросы, например, к различным типам источников данных и извлекать информацию обратно. Но для того, чтобы сделать это, вам нужны хорошие стратегии сопоставления, поэтому сопоставление этих видов данных и отслеживание этих сопоставлений может быть реальной проблемой. И тогда у вас возникает проблема, ну как мне связать мои устаревшие данные со всеми этими новыми источниками данных? Итак, предположим, что у меня есть график, я беру все свои реляционные данные и помещаю их в график? Обычно это не очень хорошая идея. Так как же люди могут управлять всеми этими типами моделей данных, которые происходят? Анализ действительно должен проводиться на множестве этих различных типов источников данных и комбинаций. Таким образом, ответы, которые вытекают из этого, ответы, которые нужны людям для принятия правильных деловых решений, имеют решающее значение.
Так что это не просто создание технологии ради технологии, это действительно то, что я собираюсь делать, что я могу с ней делать, какой анализ я могу выполнить, и, следовательно, способность, как я уже говорить о том, чтобы собрать все это вместе, интегрировать это действительно, очень важно. И тогда один из этих видов анализа выполняется на таких вещах, как федеративный поиск и запрос. Это действительно становится обязательным. Ваши запросы, как правило, должны быть связаны с несколькими видами источников и возвращать информацию обратно в надежный.
Один ключевой элемент, который часто, особенно люди собираются смотреть на ключевые вещи, такие как семантические технологии - и это то, о чем я надеюсь, что Рон расскажет немного о подходе IDERA - это то, как вы разделяете или управляете Слой модели ваших данных из самого слоя данных, из этих необработанных данных? Таким образом, на уровне данных у вас могут быть базы данных, у вас могут быть данные документа, у вас могут быть данные электронной таблицы, у вас могут быть данные изображения. Если вы находитесь в таких областях, как фармацевтическая промышленность, у вас есть огромное количество научных данных. И, кроме того, люди обычно ищут способ построить модель, которая позволяет им быстро интегрировать эти данные, и в действительности, когда вы ищете данные, теперь вы не хотите втягивать все данные в слой модели. то, что вы смотрите на уровне модели, - это дает вам хорошее логическое представление о том, что есть вещи, общие словари, общие типы сущностей и отношений, а также возможность реально проникнуть в данные там, где они есть. Итак, он должен сказать, что это такое, и он должен сказать, где он находится, и он должен сказать, как пойти за ним и вернуть его.
Так что это был подход, который был довольно успешным в продвижении семантических технологий, и в этой области я много работаю. Итак, вопрос, который я хотел задать Рону и который, я думаю, будет полезен в разделе вопросов и ответов, заключается в том, чтобы увидеть, как это достигается платформой IDERA? Так действительно ли уровень модели отделен от уровня данных? Они более интегрированы? Как это работает и каковы некоторые результаты и преимущества, которые они видят в своем подходе? Поэтому справочные данные действительно становятся критическими. Поэтому, если у вас будут такие модели данных, если вы сможете объединяться и выполнять поиск по всем вещам, вам действительно нужны хорошие справочные данные. Но проблема в том, что справочные данные могут быть очень трудно поддерживать. Поэтому часто называть стандарты сами по себе - сложная задача. Одна группа назовет что-то X, а другая группа назовет что-то Y, и теперь у вас есть проблема, как кто-то находит X и Y, когда они ищут информацию такого типа? Поскольку вы не хотите просто предоставлять им часть данных, вы хотите дать им все, что связано. В то же время условия меняются, программное обеспечение становится устаревшим и так далее. Как вы сохраняете эти справочные данные с течением времени?
И, опять же, семантические технологии, в частности использующие такие вещи, как таксономии и словари, словари данных, обеспечивают стандартный пространственный способ сделать это, который действительно очень надежен, использует определенные виды стандартов, но сообщество баз данных сделало это для тоже долго, просто по разному. Я думаю, что один из ключевых моментов здесь - подумать о том, как использовать, возможно, модели сущностных отношений, как использовать, возможно, графовые модели или какой-то тип подхода, который действительно даст вам, как мы надеемся, стандартный интервальный способ обработки ваших справочных данных. И, конечно же, когда у вас есть справочные данные, стратегии отображения должны управлять широким спектром имен и сущностей. Поэтому эксперты в данной области часто любят использовать свои собственные термины.
Таким образом, проблема в этом всегда заключается в том, как вы даете кому-то информацию, но делаете ее релевантной тому, как они об этом говорят? Таким образом, одна группа может иметь один взгляд на что-то, например, вы можете быть химиком, работающим над лекарством, и вы можете быть структурным биологом, работающим над тем же лекарством, и у вас могут быть разные имена для одних и тех же типов организаций которые относятся к вашей области. Вы должны найти способы объединить эти персонализированные термины, потому что другой подход заключается в том, чтобы заставить людей отказаться от своего термина и использовать чужой, что им часто не нравится. Еще одним моментом здесь является трудность обработки большого количества синонимов, поэтому в данных многих людей содержится много разных слов, которые могут относиться к одной и той же вещи. У вас есть проблема ссылки с использованием набора отношений «многие к одному». Специальные условия варьируются от отрасли к отрасли, поэтому, если вы собираетесь найти какое-то всеобъемлющее решение для этого типа управления данными, насколько легко оно переносится из одного проекта или из одного приложения в другое? Это может быть еще одной проблемой.
Автоматизация важна, и это также вызов. Ручная обработка справочных данных обходится дорого. Это дорого для того, чтобы сохранять ручное отображение, и дорого обходиться без того, чтобы отраслевые эксперты перестали выполнять свою повседневную работу, и им приходилось постоянно исправлять словари данных, обновлять определения и так далее, и так далее, и так далее. Воспроизводимые словари действительно показывают большую ценность. Так что это часто словари, которые вы можете найти внешними по отношению к вашей организации. Например, если вы работаете с сырой нефтью, существуют определенные виды словарей, которые вы можете позаимствовать из открытых источников, такие же, как фармацевтика, банковская отрасль и финансы, а также множество других областей. Люди создают многоразовые, типовые, воспроизводимые словари для использования людьми.
И, опять же, глядя на инструмент IDERA, мне любопытно посмотреть, как они справляются с этим с точки зрения использования различных стандартов. В мире семантики вы часто видите такие вещи, как модели SKOS, которые предоставляют стандарты, по крайней мере, шире, чем узкие отношения, и эти вещи могут быть сложными в моделях ER, но, вы знаете, не невозможно, это просто зависит от того, насколько машины и связи, которые вы можете обрабатывать в этих типах систем.
Наконец, я просто хотел сравнить некоторые семантические движки, которые я вижу в отрасли, и попросить Рона и поболтать с ним, чтобы немного рассказать о том, как система IDERA использовалась в сочетании с любыми семантическими технологиями. Может ли он быть интегрирован с тройными хранилищами, графовыми базами данных? Насколько легко использовать внешние источники, потому что такие вещи в семантическом мире часто можно заимствовать с помощью конечных точек SPARQL? Вы можете импортировать модели RDF или OWL непосредственно в вашу модель - обратитесь к ним - например, генная онтология или белковая онтология, которые могут жить где-то в своем собственном пространстве со своей собственной структурой управления, и я могу просто импортировать все или часть этого, как мне нужно, в моих собственных моделях. И мне любопытно узнать, как IDERA подходит к этому вопросу. Нужно ли поддерживать все внутренне, или есть способы использовать другие виды стандартизированных моделей и использовать их, и как это работает? И последнее, что я упомянул здесь, это то, сколько ручной работы действительно требуется для создания глоссариев и хранилищ метаданных?
Так что я знаю, что Рон покажет нам несколько демонстраций о таких вещах, которые будут действительно интересными. Но проблемы, которые я часто вижу, консультируясь с клиентами, состоят в том, что возникает много ошибок, если люди пишут в своих собственных определениях или в своих собственных метаданных. Таким образом, вы получаете орфографические ошибки, вы получаете ошибки жирного пальца, это одна вещь. Вы также получаете людей, которые могут взять что-то из, вы знаете, просто Википедии или источника, который не обязательно соответствует качеству, которое вы можете хотеть в своем определении, или ваше определение только с точки зрения одного человека, поэтому оно не является полным, и тогда это не ясно. как работает процесс управления. Конечно, управление - очень и очень большая проблема, когда вы говорите о справочных данных и каждый раз, когда вы говорите о том, как это может вписаться в чьи-либо основные данные, как они собираются использовать свои метаданные, и скоро.
Так что я просто хотел поставить некоторые из этих тем. Это те вещи, которые я вижу в бизнес-пространстве в самых разных консультационных проектах и во многих других областях, и мне действительно интересно посмотреть, что Рон собирается показать нам с IDERA, чтобы указать на некоторые из этих тем., Так что большое спасибо.
Ребекка Йозвиак: Большое спасибо, Эрик, и мне очень нравится ваш комментарий, что может произойти много ошибок, если люди пишут свои собственные определения или метаданные. Я знаю, что в мире журналистики есть мантра, что «многие глаза делают мало ошибок», но когда дело доходит до практических применений, слишком много рук в баночке с печеньем приводит к тому, что у вас остается много сломанных печенек, верно?
Эрик Литтл: Да, и микробы.
Ребекка Йозвиак: Да. После этого я собираюсь передать это Малкольму Чизолму. Малькольм, вам слово.
Малкольм Чисхолм: Большое спасибо, Ребекка. Я хотел бы немного взглянуть на то, о чем говорил Эрик, и добавить несколько замечаний, на которые, вы знаете, Рон, возможно, тоже захочет ответить, говоря о «На пути к архитектуре, управляемой бизнесом» - что значит быть ориентированным на бизнес и почему это важно? Или это просто какая-то форма обмана? Я не думаю, что это так.
Если мы посмотрим на то, что происходит с тех пор, как вы знаете, мэйнфрейм-компьютеры действительно стали доступны для компаний - скажем, примерно в 1964 году - до сегодняшнего дня, мы видим, что произошло много изменений. И эти изменения я бы назвал переходом от центрированности к процессам к центру данных. И именно это делает бизнес-ориентированные архитектуры данных такими важными и актуальными на сегодняшний день. И я думаю, вы знаете, это не просто модное слово, это нечто абсолютно реальное.
Но мы можем оценить это немного больше, если погрузимся в историю, поэтому, возвращаясь назад во времени, к 1960-м годам и в течение некоторого времени после этого, доминировали мэйнфреймы. Затем они уступили место ПК, на которых вы фактически взбунтовали пользователей, когда вошли компьютеры. Восстание против централизованных ИТ, которые, по их мнению, не удовлетворяли их потребностям, были недостаточно гибкими. Это быстро привело к распределенным вычислениям, когда ПК были связаны друг с другом. А затем начал появляться Интернет, который размыл границы предприятия - теперь он мог взаимодействовать с внешними сторонами с точки зрения обмена данными, чего раньше не было. И теперь мы вступили в эру облачных и больших данных, где облако - это платформы, которые действительно превращают в товарную инфраструктуру, и поэтому мы как бы отстраняем ИТ-отдел от необходимости эксплуатировать большие центры обработки данных, потому что, вы знаете, мы у нас есть облачная емкость, доступная нам, и одновременно с этими большими данными, которые Эрик, как вы знаете, так красноречиво обсуждали. И в целом, как мы видим, по мере того, как произошел сдвиг в технологии, она стала более ориентированной на данные, мы больше заботимся о данных. Как и в Интернете, как происходит обмен данными. С большими данными, четыре или более V самих данных.
В то же время, и, возможно, что еще более важно, бизнес-прецеденты изменились. Когда компьютеры были впервые представлены, они использовались для автоматизации таких вещей, как книги и записи. И все, что было ручным процессом, которое включало бухгалтерские книги или тому подобное, было запрограммировано, по существу, в доме. Это сместилось в 80-х годах к доступности операционных пакетов. Вам больше не нужно было писать собственную платежную ведомость, вы можете купить что-то, что сделало это. Это привело к значительному сокращению или реструктуризации во многих ИТ-отделах. Но затем появилась бизнес-аналитика с такими вещами, как хранилища данных, в основном в 90-х годах. Вслед за бизнес-моделями доткомов, которые были, конечно, большое безумие. Тогда МДМ. С MDM вы начинаете понимать, что мы думаем не об автоматизации; мы просто фокусируемся на обработке данных как данных. А затем аналитика, представляющая ценность, которую вы можете получить из данных. А в аналитике вы видите очень успешные компании, основная бизнес-модель которых основана на данных. Google, Twitter, Facebook будут частью этого, но вы также можете поспорить, что 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, вы вначале проведете большой реверс-инжиниринг с точки зрения того, что давайте укажем на источники данных, которые там есть, приведем их, а затем фактически соединим их в более представительный модели, которые представляют весь бизнес. Важно то, что мы хотим иметь возможность разбивать эти модели также по бизнес-направлениям, чтобы мы могли относиться к ним более мелкими порциями, к которым могут относиться и наши деловые люди, и наши бизнес-аналитики и другие заинтересованные стороны, которые работают в теме.
Стандарты именования чрезвычайно важны, и я говорю об этом здесь несколькими способами. Стандарты именования с точки зрения того, как мы называем вещи в наших моделях. Это довольно легко сделать в логических моделях, где у нас есть хорошее соглашение об именах и хороший словарь данных для наших моделей, но также мы видим различные соглашения об именах для многих из этих физических моделей, которые мы вводим. Когда мы Обратный инженер, довольно часто мы видим сокращенные имена и такие вещи, о которых я поговорю. И нам нужно перевести их обратно в значимые английские имена, которые имеют значение для бизнеса, чтобы мы могли понять, что представляют собой все эти части данных, которые мы имеем в среде. И тогда универсальные отображения - это то, как мы их соединяем.
Вдобавок к этому мы затем документируем и определяем дальше, и именно здесь мы можем классифицировать наши данные с помощью приложения Attachments, на котором я покажу вам пару слайдов. И затем, закрывая цикл, мы хотим применить этот бизнес-смысл, в котором мы связываем наши бизнес-глоссарии и можем связать их с нашими различными модельными артефактами, поэтому мы знаем, когда мы говорим об определенном бизнес-термине, где это реализовано в наших данных во всей организации. И, наконец, я уже говорил о том, что нам нужно, чтобы все это было репозиторием, основанным на большом количестве возможностей для совместной работы и публикации, чтобы наши заинтересованные стороны могли его использовать. Я собираюсь говорить о реверс-инжиниринге довольно быстро. Я уже как бы очень быстро об этом рассказал. Я покажу вам это в реальной демонстрации, просто чтобы показать вам некоторые вещи, которые мы можем принести туда.
И я хочу поговорить о некоторых типах моделей и диаграммах, которые мы могли бы создать в сценарии этого типа. Очевидно, что мы будем делать концептуальные модели во многих случаях; Я не собираюсь тратить на это много времени. Я действительно хочу поговорить о логических моделях, физических моделях и специализированных типах моделей, которые мы можем создать. И важно, чтобы мы могли создавать их все на одной платформе моделирования, чтобы мы могли их объединить. Это включает в себя многомерные модели, а также модели, использующие некоторые новые источники данных, такие как NoSQL, который я вам покажу. И затем, как выглядит модель происхождения данных? И как мы будем встраивать эти данные в модель бизнес-процесса, о чем мы будем говорить дальше.
Я собираюсь переключиться на среду моделирования здесь, чтобы дать вам очень краткий обзор. И я верю, что вы должны увидеть мой экран сейчас. Прежде всего я хочу поговорить только о традиционном типе модели данных. И способ, которым мы хотим организовать модели, когда мы их вводим, заключается в том, что мы хотим иметь возможность разбивать их. Итак, с левой стороны мы видим, что у нас есть логические и физические модели в этом конкретном файле модели. Следующее, что мы можем разбить на части по разложению бизнеса, поэтому вы видите папки. Голубые - это логические модели, а зеленые - физические. И мы можем также углубиться, поэтому в ER / Studio, если у вас есть бизнес-декомпозиция, вы можете пройти столько уровней или подмоделей, сколько захотите, и изменения, которые вы делаете на более низких уровнях, автоматически отражаются на более высоких уровни. Так что очень быстро становится очень мощная среда моделирования.
Я также хотел бы отметить, что очень важно начать собирать эту информацию вместе - у нас может быть несколько физических моделей, которые также соответствуют одной логической модели. Довольно часто у вас может быть логическая модель, но у вас могут быть физические модели на разных платформах и тому подобное. Может быть, один экземпляр этого SQL Server, а другой экземпляр Oracle. У нас есть возможность связать все это в одной среде моделирования. И опять же, здесь у меня есть реальная модель хранилища данных, которая, опять же, может находиться в той же среде моделирования, или мы можем иметь ее в хранилище и связывать ее между собой.
То, что я действительно хотел показать вам на этом, это некоторые другие вещи и другие варианты моделей, в которые мы попадаем. Поэтому, когда мы попадаем в традиционную модель данных, подобную этой, мы привыкли видеть типичные объекты со столбцами, метаданными и тому подобным, но эта точка зрения очень быстро меняется, когда мы начинаем работать с некоторыми из этих более новых технологий NoSQL. или, как некоторые люди до сих пор называют их, технологии больших данных.
Итак, теперь давайте предположим, что у нас также есть Hive в нашей среде. Если мы проведем обратный инжиниринг из среды Hive - и мы сможем выполнить прямой и обратный инжиниринг из Hive с помощью точно такого же инструмента моделирования - мы увидим что-то немного другое. Мы все еще видим все данные как конструкции, но наш TDL другой. Те из вас, кто привык видеть SQL, теперь вы увидите Hive QL, который очень похож на SQL, но теперь из одного и того же инструмента вы можете начать работать с различными языками сценариев. Таким образом, вы можете моделировать в этой среде, генерировать ее в среде Hive, но, что не менее важно, в сценарии, который я описал, вы можете перепроектировать все это и разобраться в нем, а также начать объединять его вместе.,
Давайте возьмем другой, который немного отличается. MongoDB - это еще одна платформа, которую мы поддерживаем изначально. И когда вы начинаете входить в JSON-типы сред, в которых у вас есть хранилища документов, JSON - это другое животное, и в нем есть конструкции, которые не соответствуют реляционным моделям. Вскоре вы начинаете работать с такими понятиями, как встроенные объекты и встроенные массивы объектов, когда начинаете опрашивать JSON, и эти понятия не существуют в традиционной реляционной нотации. Здесь мы фактически расширили нотацию и наш каталог, чтобы иметь возможность обрабатывать это в одной и той же среде.
Если вы посмотрите здесь слева, вместо того, чтобы видеть такие вещи, как сущности и таблицы, мы называем их объектами. И вы видите разные обозначения. Вы все еще видите типичные типы ссылочных обозначений здесь, но эти синие объекты, которые я показываю на этой конкретной диаграмме, на самом деле являются встроенными объектами. И мы показываем разные мощности. Алмазная мощность означает, что это объект на одном конце, но мощность одного означает, что у нас, в издателе, если мы будем следовать этим отношениям, у нас есть встроенный адресный объект. При опросе JSON мы обнаружили, что это точно такая же структура объектов, которая встроена в покровителя, но на самом деле она встроена в массив объектов. Мы видим это не только через сами соединители, но и, если вы посмотрите на реальные сущности, вы увидите, что вы видите адреса под патроном, которые также классифицируют его как массив объектов. Вы получаете очень описательную точку зрения о том, как вы можете внести это.
И опять же, теперь то, что мы видели за несколько секунд, это традиционные многоуровневые реляционные модели, мы можем сделать то же самое с Hive, мы можем сделать то же самое с MongoDB и другими источниками больших данных, как Что ж. То, что мы также можем сделать, и я просто собираюсь показать вам это очень быстро, я говорил о факте привлечения вещей из других различных областей. Я предполагаю, что собираюсь импортировать модель из базы данных или перепроектировать ее, но я собираюсь извлечь ее из внешних метаданных. Просто чтобы дать вам очень быстрый взгляд на все виды вещей, которые мы можем начать вносить.
Как видите, у нас есть множество вещей, с помощью которых мы можем на самом деле перенести метаданные в нашу среду моделирования. Начиная с таких вещей, как Amazon Redshift, Cassandra, множество других платформ больших данных, так что вы видите множество перечисленных. Это в алфавитном порядке. Мы видим много больших источников данных и тому подобное. Мы также видим множество традиционных или более старых сред моделирования, через которые мы можем действительно передавать эти метаданные. Если я пройду здесь - и я не собираюсь тратить время на каждую из них - мы увидим много разных вещей, из которых мы можем это сделать, с точки зрения платформ моделирования и платформ данных. И здесь очень важно понять, что это еще одна часть, которую мы можем выполнить, когда начнем говорить о происхождении данных. В выпуске Enterprise Team Edition мы также можем опрашивать источники ETL, будь то такие вещи, как сопоставления Talend или SQL Server Information Services, мы можем на самом деле, привносим это, чтобы начать наши диаграммы происхождения данных и нарисовать картину того, что происходит в этих преобразованиях. В общей сложности у нас есть более 130 из этих различных мостов, которые фактически являются частью продукта Enterprise Team Edition, так что это действительно помогает нам быстро собрать все артефакты в одну среду моделирования.
И последнее, но не менее важное: я также хочу поговорить о том факте, что мы не можем упускать из виду тот факт, что нам нужны другие типы конструкций, если мы занимаемся хранилищем данных или любыми видами аналитики. Мы все еще хотим иметь возможность делать такие вещи, как модели измерений, где у нас есть таблицы фактов, и у нас есть измерения и тому подобное. Я также хочу показать вам одну вещь: у нас также могут быть расширения для наших метаданных, которые помогают нам классифицировать типы измерений и все остальное. Поэтому, если я посмотрю на вкладку размерных данных, например, на одну из них, она на самом деле автоматически обнаружит, основываясь на шаблоне модели, который видит, и даст вам отправную точку в том, считает ли она измерением или таблица фактов. Но помимо этого, то, что мы можем сделать, находится в пределах измерений и того, что у нас даже есть различные типы измерений, которые мы можем использовать для классификации данных в среде хранилищ данных. Очень мощные возможности, которыми мы сшиваем это вместе.
Я собираюсь перейти к этому, поскольку сейчас я нахожусь в демонстрационной среде, и покажу вам пару других вещей, прежде чем я вернусь к слайдам. Одна из вещей, которую мы недавно добавили в ER / Studio Data Architect, - это то, что мы столкнулись с ситуациями - и это очень распространенный случай, когда вы работаете над проектами - разработчики думают с точки зрения объектов, тогда как наши данные разработчики моделей склонны мыслить в терминах таблиц и сущностей и тому подобного. Это очень упрощенная модель данных, но она представляет несколько базовых концепций, в которых разработчики или даже бизнес-аналитики или бизнес-пользователи могут рассматривать их как различные объекты или бизнес-концепции. До сих пор было очень трудно их классифицировать, но то, что мы на самом деле сделали в ER / Studio Enterprise Team Edition в выпуске 2016 года, теперь у нас есть концепция, называемая объектами бизнес-данных. И что это позволяет нам делать, это позволяет нам инкапсулировать группы сущностей или таблиц в настоящие бизнес-объекты.
Например, в этом новом представлении мы получили заголовок «Заказ на покупку» и «Строка заказа», которые теперь объединены, они инкапсулированы как объект, и мы будем рассматривать их как единицу работы, когда сохраняем данные. и мы свели их вместе, так что теперь очень легко связать это с разными аудиториями. Их можно использовать в модельной среде. Они являются настоящим объектом, а не просто чертежной конструкцией, но у нас также есть дополнительное преимущество, заключающееся в том, что когда мы фактически общаемся с точки зрения моделирования, мы можем выборочно свернуть или развернуть их, чтобы мы могли создать обобщенный вид для диалогов с определенной аудиторией заинтересованных сторон, и мы также можем, конечно, сохранить более подробный обзор, как мы видим здесь для большей технической аудитории. Это действительно дает нам действительно хорошее средство общения. То, что мы видим сейчас, - это объединение нескольких различных типов моделей, дополнение их концепцией объектов бизнес-данных, и теперь я собираюсь поговорить о том, как мы на самом деле применяем больше смысла к этим типам вещей и как мы их объединяем в нашем общая среда.
Я просто пытаюсь найти свой WebEx здесь, чтобы я мог это сделать. И вот мы возвращаемся к слайдам Hot Tech. Я просто собираюсь перенести несколько слайдов сюда, потому что вы уже видели их в самой демонстрации модели. Я хочу говорить о стандартах именования очень быстро. Мы хотим применять и применять различные стандарты именования. Что мы хотим сделать, так это то, что у нас есть возможность хранить шаблоны стандартов именования в наших репозиториях, чтобы в основном строить это значение посредством слов или фраз или даже сокращений и связывать их со значимым английским типом слова. Мы собираемся использовать бизнес-термины, сокращения для каждого, и мы можем указать порядок, регистры и добавить префиксы и суффиксы. Типичный вариант использования этого, как правило, когда люди строят логическую модель и затем на самом деле идут вперед, чтобы создать физическую модель, где они могли бы использовать сокращения и все остальное.
Прекрасно то, что он такой же мощный, даже более мощный, наоборот, если мы можем просто сказать, какими были некоторые из этих стандартов именования для некоторых из тех физических баз данных, которые мы переработали, мы можем взять эти сокращения, превратить их в более длинные слова, и привести их обратно в английские фразы. Теперь мы можем получить собственные имена для того, как выглядят наши данные. Как я уже сказал, типичный вариант использования - это то, что мы будем двигаться вперед, логически к физическому, и отображать хранилища данных и тому подобное. Если вы посмотрите на скриншот с правой стороны, то увидите, что в именах источников есть сокращенные имена, и когда мы применили шаблон стандартов именования, у нас фактически появилось больше полных имен. И мы можем поместить пробелы и все такое, если захотим, в зависимости от шаблона стандартов именования, который мы использовали. Мы можем сделать так, чтобы это выглядело, но мы хотим, чтобы это выглядело в наших моделях Только когда мы знаем, что что-то называется, мы можем фактически начать прикреплять к нему определения, потому что, если мы не знаем, что это такое, как мы можем применить к нему значение?
Приятно то, что мы можем вызывать это, когда делаем разные вещи. Я говорил об обратном инжиниринге, мы можем одновременно вызывать шаблоны стандартов именования, когда занимаемся реверс-инжинирингом. Таким образом, за один шаг в мастере мы можем сделать следующее: если мы знаем, что такое соглашения, мы можем провести обратный инжиниринг физической базы данных, она вернет ее обратно в качестве физических моделей в среде моделирования, и это также собирается применить эти соглашения об именах. Итак, мы увидим, что такое англоязычные представления имен в соответствующей логической модели в среде. Мы также можем сделать это и объединить это с генерацией XML-схемы, чтобы мы могли взять модель и даже выдвинуть ее с нашими аббревиатурами, независимо от того, делаем ли мы SOA-фреймворки или что-то в этом роде, чтобы затем мы могли также выдвигать различные соглашения об именах что мы на самом деле сохранили в самой модели. Это дает нам много очень мощных возможностей.
Опять же, вот пример того, как бы это выглядело, если бы у меня был шаблон. Это на самом деле показывает, что у меня была EMP для «сотрудника», SAL для «зарплаты», PLN для «плана» в соглашении о стандартах именования. Я также могу применить их, чтобы они работали в интерактивном режиме, поскольку я строю модели и помещаю вещи. Если бы я использовал эту аббревиатуру и набрал «План зарплаты сотрудника» в имени сущности, он работал бы с шаблоном стандартов именования. Я определил здесь, это дало бы мне EMP_SAL_PLN, когда я создавал сущности, и сразу дало бы мне соответствующие физические имена.
Опять же, очень хорошо, когда мы занимаемся проектированием и разработкой. У нас очень уникальная концепция, и именно здесь мы действительно начинаем объединять эти среды. И это называется универсальным отображением. После того, как мы внедрили все эти модели в нашу среду, что мы можем сделать, предполагая, что теперь мы применили эти соглашения об именах, и их легко найти, мы можем теперь использовать конструкцию под названием Universal Mappings в ER / Studio. Мы можем связать сущности по моделям. Везде, где мы видим «клиента» - у нас, вероятно, будет «клиент» во многих различных системах и во многих различных базах данных - мы можем начать связывать все эти элементы вместе, чтобы при работе с ним в одной модели я Можно посмотреть, где находятся проявления покупателей в других моделях. И поскольку у нас есть уровень модели, представляющий это, мы можем даже связать его с источниками данных и включить его в наши используемые запросы, в которых базы данных также находятся. Это действительно дает нам возможность связать все это воедино.
Я показал вам объекты бизнес-данных. Я также хочу поговорить о расширениях метаданных, которые мы называем приложениями, очень быстро. Это дает нам возможность создавать дополнительные метаданные для объектов нашей модели. Довольно часто я настраивал эти типы свойств, чтобы вывести множество разных вещей с точки зрения управления данными и качества данных, а также чтобы помочь нам с управлением основными данными и политиками хранения данных. Основная идея заключается в том, что вы создаете эти классификации и можете прикреплять их в любом месте, на уровне таблицы, на уровне столбца, к таким типам вещей. Конечно, наиболее распространенный вариант использования состоит в том, что сущности являются таблицами, и тогда я могу определить: каковы мои объекты основных данных, каковы мои справочные таблицы, каковы мои транзакционные таблицы? С точки зрения качества данных я могу провести классификацию с точки зрения важности для бизнеса, чтобы мы могли расставить приоритеты по очистке данных и тому подобное.
Что часто упускается из виду, так это какая политика хранения для разных типов данных в нашей организации? Мы можем настроить их и фактически прикрепить их к различным типам информационных артефактов в нашей среде моделирования и, конечно же, в нашем хранилище. Прелесть в том, живут ли эти вложения в нашем словаре данных, поэтому, когда мы используем корпоративные словари данных в среде, мы можем прикрепить их к нескольким моделям. Нам нужно только определить их один раз, и мы можем использовать их снова и снова в различных моделях нашей среды. Это просто быстрый снимок экрана, показывающий, что вы можете указать, когда вы делаете вложение, к каким элементам вы хотите прикрепить его. И этот пример на самом деле представляет собой список значений, поэтому, когда они входят, вы можете выбирать из списка значений, у вас есть большой контроль в среде моделирования того, что выбирается, и вы даже можете установить, что по умолчанию Значение, если значение не выбрано. Так много сил там. Они живут в словаре данных.
Что-то, что я хочу показать вам немного дальше на этом экране, кроме того, вы видите вложения типа в верхней части, под ним вы видите информацию о безопасности данных. Мы также можем применить политики безопасности данных к различным частям информации в среде. Для различных сопоставлений соответствия, классификаций безопасности данных мы поставляем их несколько из коробки, которые вы можете просто создать и начать использовать, но вы также можете определить свои собственные соответствия соответствия и стандарты. Делаете ли вы HIPAA или какие-либо другие инициативы. И вы действительно можете начать создавать этот очень богатый набор метаданных в своей среде.
А затем Глоссарий и Термины - это то, где бизнес-смысл связан. У нас довольно часто есть словари данных, которые довольно часто организация использует в качестве отправной точки, чтобы начать выводить глоссарии, но терминология и словоблудие часто очень технический. Поэтому мы можем, если захотим, использовать их в качестве отправной точки для выпуска глоссариев, но мы действительно хотим, чтобы они принадлежали бизнесу. Что мы сделали в среде командного сервера, так это то, что мы дали людям возможность создавать бизнес-определения, а затем мы можем связать их с различными артефактами модели, которым они соответствуют также в среде моделирования. Мы также осознаем тот момент, который обсуждался ранее: чем больше людей печатает, тем больше вероятность человеческой ошибки. То, что мы также делаем в нашей структуре глоссария, это, во-первых, мы поддерживаем иерархию глоссария, поэтому у нас могут быть разные типы глоссария или разные типы вещей в организации, но не менее важно, если у вас уже есть некоторые из этих источников там с терминами и всем определенным, мы можем на самом деле сделать импорт CSV, чтобы перенести их в нашу среду моделирования, а также на наш командный сервер или в наш глоссарий, а затем начать ссылаться оттуда. И каждый раз, когда что-то меняется, есть полный контрольный журнал того, какими были изображения «до» и «после», с точки зрения определений и всего остального, и то, что вы увидите в ближайшем будущем, также является скорее процессом авторизации. поэтому мы можем реально контролировать, кто за это отвечает, одобрения комитетов или отдельных лиц и тому подобное, чтобы сделать процесс управления еще более устойчивым по мере нашего продвижения вперед.
Для нас это также важно, когда в глоссарии нашего командного сервера есть эти термины глоссария, это пример редактирования сущности в самой модели, которую я здесь привел. Возможно, это связанные термины, но мы также делаем, если в этом глоссарии есть слова, которые появляются в примечаниях или описаниях того, что есть в наших сущностях здесь, они автоматически отображаются более светлым цветом с гиперссылками, и если мы Наведите указатель мыши на них, мы также можем увидеть определение из бизнес-глоссария. Это даже дает нам более богатую информацию, когда мы потребляем саму информацию, со всеми глоссариевыми терминами, которые там есть. Это действительно помогает обогатить опыт и применить смысл ко всему, с чем мы работаем.
Итак, опять же, это был очень быстрый перелет. Очевидно, мы могли бы потратить на это дни, углубившись в разные части, но это очень быстрый перелет над поверхностью. Что мы действительно стремимся сделать, так это понять, как выглядят эти сложные среды данных. Мы хотим улучшить видимость всех этих артефактов данных и сотрудничать, чтобы вытеснить их с помощью ER / Studio. Мы хотим обеспечить более эффективное и автоматизированное моделирование данных. И это все типы данных, о которых мы говорим, будь то большие данные, традиционные реляционные данные, хранилища документов или что-то еще. И снова, мы достигли этого, потому что у нас есть мощные возможности прямого и обратного инжиниринга для различных платформ и других инструментов, которые могут у вас там быть. И все дело в том, чтобы делиться информацией и общаться в рамках всей организации со всеми заинтересованными сторонами. Вот где мы применяем значение через стандарты именования. Затем мы применяем определения через наши бизнес-глоссарии. И затем мы можем провести дальнейшую классификацию для всех других наших возможностей управления с помощью расширений метаданных, таких как расширения качества данных, классификации для управления основными данными или любые другие типы классификаций, которые вы хотите применить к этим данным. И затем мы можем обобщить и еще больше улучшить связь с объектами бизнес-данных, с различными заинтересованными сторонами, особенно между разработчиками моделей и разработчиками.
И снова, что очень важно об этом, за всем этим стоит интегрированный репозиторий с очень надежными возможностями управления изменениями. У меня не было времени показать его сегодня, потому что он становится довольно сложным, но репозиторий обладает очень надежными возможностями управления изменениями и контрольными журналами. Вы можете делать именованные выпуски, вы можете делать именованные версии, и у нас также есть возможность для тех из вас, кто занимается управлением изменениями, мы можем привязать это прямо к вашим задачам. Сегодня у нас есть возможность ставить задачи и связывать изменения вашей модели с задачами, точно так же, как разработчики связывают изменения своего кода с задачами или пользовательскими историями, с которыми они также работают.
Опять же, это был очень быстрый обзор. Я надеюсь, что этого было достаточно, чтобы разжечь ваш аппетит, чтобы мы могли вступить в более глубокие разговоры о разделении некоторых из этих тем в будущем. Спасибо, что уделили время и вернулись к вам, Ребекка.
Ребекка Джозвиак: Спасибо, Рон, это было здорово, и у меня есть немало вопросов от аудитории, но я хочу дать нашим аналитикам возможность погрузиться в то, что вы хотели сказать. Эрик, я собираюсь продолжить, и, возможно, если вы хотите рассмотреть этот слайд или другой, почему бы вам не пойти первым? Или любой другой вопрос.
Эрик Литтл: Конечно. Извини, что за вопрос, Ребекка? Вы хотите, чтобы я спросил что-то конкретное или …?
Ребекка Джозвиак: Я знаю, что у тебя изначально были вопросы к Рону. Если вы хотите попросить его, чтобы он обратился к любому из них, или к некоторым из них с вашего слайда, или к чему-то еще, что вызвало у вас интерес, о котором вы хотите спросить? О функциональности моделирования IDERA.
Эрик Литтл: Да, одна из вещей, Рон, так как вы, ребята, похоже, что диаграммы, которые вы демонстрировали, являются общими видами диаграмм отношений сущностей, которые вы обычно используете при построении базы данных, верно?
Рон Хуйзенга: Да, вообще говоря, но, конечно, у нас есть расширенные типы для хранилищ документов и тому подобное. На самом деле мы отличались от просто реляционной нотации, мы добавили дополнительные нотации и для других магазинов.
Эрик Литтл: Есть ли способ, как вы, ребята, можете использовать моделирование на основе графов, так есть ли способ интеграции, например, давайте предположим, что у меня есть что-то вроде верхнего квадранта, инструмента компоновки TopBraid или я что-то сделал в Protégé или, как вы знаете, подобно финансовым парням из FIBO, они много работают над семантикой, RDF - есть ли способ внедрить этот тип моделирования типов взаимосвязей сущностей в этот инструмент и использовать Это?
Рон Хуйзенга: На самом деле мы смотрим, как мы можем обрабатывать графики. Сегодня мы не работаем явно с графическими базами данных и тому подобным, но мы ищем способы, которыми мы можем сделать это, чтобы расширить наши метаданные. Я имею в виду, что мы можем внести вещи через XML и тому подобное прямо сейчас, если мы сможем хотя бы сделать какую-то разновидность XML, чтобы привести ее в качестве отправной точки. Но мы ищем более элегантные способы внести это.
И я также показал вам этот список мостов обратного инжиниринга, который у нас там есть, поэтому мы всегда ищем расширения для этих мостов и для конкретных платформ. Это постоянное, непрерывное усилие, если это имеет смысл, начать охватывать множество этих новых конструкций и различных платформ. Но я могу сказать, что мы определенно на переднем крае этого. Материал, который я показал, например, на MongoDB и тому подобное, мы являемся первым поставщиком моделирования данных, который фактически сделал это изначально в нашем собственном продукте.
Эрик Литтл: Хорошо, да. Таким образом, другой вопрос, который у меня был для вас, был связан с управлением и поддержанием - как, например, когда вы использовали пример, когда вы показали пример человека, который является «наемным работником», я считаю, что это было « зарплата », и тогда у вас есть« план », есть ли способ, как вы управляете, например, разными людьми, которые могут иметь - предположим, у вас большая архитектура, верно, давайте предположим, что у вас большое предприятие и люди начинают собирать вещи с помощью этого инструмента, и у вас есть одна группа со словом «работник» и одна группа со словом «работник». И один человек здесь говорит «зарплата», а другой человек говорит "заработная плата."
Как вы, ребята, примиряете, управляете и управляете такими различиями? Потому что я знаю, как мы будем это делать в мире графов, вы знаете, вы бы использовали списки синонимов или сказали бы, что есть одна концепция и у нее несколько атрибутов, или вы могли бы сказать, что в модели SKOS у меня есть предпочтительный ярлык, и многочисленные альтернативные метки, которые я могу использовать. Как вы, ребята, делаете это?
Рон Хуйзенга: Мы делаем это несколькими способами, и в первую очередь давайте сначала поговорим о терминологии. Конечно, мы хотим иметь определенные или санкционированные термины, и в деловом глоссарии, очевидно, мы их хотим. И мы также разрешаем ссылки на синонимы в бизнес-глоссарии, поэтому вы можете сказать, что это мой термин, но вы также можете определить, каковы все синонимы для них.
Теперь, конечно, интересно то, что когда вы начинаете просматривать обширный ландшафт данных со всеми этими различными системами, вы не можете просто пойти туда и изменить соответствующие таблицы и эти типы вещей на соответствуют этому стандарту именования, потому что это может быть пакет, который вы купили, поэтому вы не можете контролировать изменение базы данных или что-либо еще.
Что мы могли бы сделать там, в дополнение к возможности связать определения глоссария, через те универсальные отображения, о которых я говорил, что мы будем делать, и вид рекомендуемого подхода, так это получить всеобъемлющую логическую модель, которая излагает то, что Вы говорите о разных бизнес-концепциях. Свяжите с ними термины бизнес-глоссария, и теперь хорошо, что у вас есть эта конструкция, которая представляет логическую сущность как таковую, и вы можете начать связывать эту логическую сущность со всеми реализациями этой логической сущности в разные системы.
Тогда, где вам нужно на это, вы можете видеть, о-о, «человек» здесь называется «работник» в этой системе. «Зарплата» здесь называется «заработная плата» здесь, в этой другой системе. Потому что вы увидите это, вы увидите все различные проявления тех, потому что вы связали их вместе.
Эрик Литтл: Ладно, отлично, да, понял. В этом смысле можно ли сказать, что это похоже на некоторые объектно-ориентированные подходы?
Рон Хуйзенга: В некотором смысле . Это немного более интенсивно, чем, я думаю, вы могли бы сказать. Я имею в виду, что вы могли бы воспользоваться подходом ручного связывания, прохождения, проверки и выполнения всех этих действий. Единственная вещь, о которой у меня не было возможности поговорить, потому что у нас много возможностей, у нас также есть полностью автоматизированный интерфейс в самом инструменте Data Architect. И возможность макросов, которая действительно является языком программирования в инструменте. Таким образом, мы можем на самом деле делать такие вещи, как писать макросы, заставлять их выходить, опрашивать и создавать ссылки для вас. Мы используем его для импорта и экспорта информации, мы можем использовать его для изменения вещей или добавления атрибутов, событий, основанных на самой модели, или мы можем использовать его для запуска в пакетах, чтобы фактически выходить и опрашивать вещи и фактически заполнять различные конструкции в модель. Так что есть полный интерфейс автоматизации, которым люди могут воспользоваться. И использование универсальных отображений с ними было бы очень мощным способом сделать это.
Ребекка Джозвиак: Хорошо, спасибо, Рон, и спасибо Эрику. Это были замечательные вопросы. Я знаю, что мы бежим чуть-чуть дольше, но я хотел бы дать Малкольму шанс задать несколько вопросов Рону. Малькольм?
Малкольм Чисхолм: Спасибо, Ребекка. Итак, Рон, это очень интересно, я вижу, что здесь много возможностей. Одна из областей, которые меня очень интересуют, это, скажем, если у нас есть проект разработки, как вы видите, как разработчик моделей данных использует эти возможности и, возможно, более тесно сотрудничает с бизнес-аналитиками, с профилировщиком данных, с аналитиком качества данных и со спонсорами бизнеса, которые в конечном итоге будут нести ответственность за фактические информационные требования в проекте. Знаете, как разработчик моделей данных делает проект более эффективным и результативным с теми возможностями, которые мы рассматриваем?
Рон Хуйзенга: Я думаю, что одна из первых вещей, которые вы должны сделать, это как модельер данных - и я не хочу выбирать некоторых из них, но я все равно буду делать это - у некоторых людей все еще складывается впечатление, что модельер данных - это тип роли «привратника», мы определяем, как он работает, мы охранники, которые следят за тем, чтобы все было правильно.
Теперь есть аспект того, что вы должны убедиться, что вы определяете архитектуру звуковых данных и все остальное. Но что более важно, как разработчик модели данных - и я обнаружил, что это довольно очевидно, когда я консультировался, - это то, что вы должны стать фасилитатором, поэтому вы должны собрать этих людей вместе.
Это больше не будет проектирование, генерация, создание баз данных - вам нужно уметь работать со всеми этими различными группами заинтересованных сторон, заниматься реверс-инжинирингом, импортировать информацию, иметь другие люди сотрудничают, будь то в глоссариях или в документации, и тому подобное, - и помогите вытащить это в хранилище, связать концепции вместе в хранилище и работать с этими людьми.
На самом деле, это скорее среда для совместной работы, в которой даже благодаря определению задач или даже тем обсуждения или тому, что мы имеем в командном сервере, люди могут на самом деле сотрудничать, задавать вопросы и получать конечные конечные продукты, которые они необходимость их архитектуры данных и их организации. Разве такой ответ?
Малкольм Чисхолм: Да, я согласен. Вы знаете, я думаю, что навык фасилитации - это то, что действительно очень желательно в разработчиках данных. Я согласен, что мы не всегда видим это, но я думаю, что это необходимо, и я хотел бы предположить, что иногда есть склонность оставаться в своем углу, занимаясь моделированием данных, но вам действительно нужно работать с другими группами заинтересованных сторон. или вы просто не понимаете среду данных, с которой имеете дело, и я думаю, что в результате модель страдает. Но это только мое мнение.
Рон Хуйзенга: И это интересно, потому что вы упомянули ранее на слайде историю о том, как компании отошли от ИТ, потому что они не поставляли решения своевременно и тому подобное.
Очень интересно, что в моих последующих консультациях, до того, как я стал менеджером по продукту, большинство проектов, которые я выполнял в последние два года до этого, были спонсированы бизнесом, и это был действительно бизнес, который управлял им и архитекторами данных. и моделисты не были частью ИТ. Мы были частью спонсируемой бизнесом группы, и мы были там как фасилитаторы, работающие с остальными командами проекта.
Малкольм Чисхолм: Так что я думаю, что это очень интересный момент. Я думаю, что мы начинаем видеть сдвиг в деловом мире, когда бизнес спрашивает или думает, может быть, не столько как то, что я делаю, а как процесс, но они также начинают думать о том, что это за данные с которыми я работаю, каковы мои потребности в данных, с какими данными я обращаюсь как данные, и в какой степени мы можем получить продукты и возможности IDERA для поддержки этой точки зрения, и я думаю, что потребности бизнеса, даже хотя это все еще немного зарождается.
Рон Хуэйзенга: Я согласен с вами, и я думаю, что мы видим, как все идет дальше и дальше. Мы видели пробуждение, и вы затронули его ранее с точки зрения важности данных. Мы увидели важность данных на ранних этапах развития ИТ или развития баз данных, а затем, как вы говорите, мы как бы попали в этот весь цикл управления процессами - и процесс чрезвычайно важен, не поймите меня неправильно - но теперь то, что произошло когда это произошло, данные потеряли фокус.
И теперь организации осознают, что данные действительно являются центральным пунктом. Данные представляют собой все, что мы делаем в нашем бизнесе, поэтому нам нужно убедиться, что у нас есть точные данные, чтобы мы могли найти правильную информацию, которая нам нужна для принятия решений. Потому что не все исходит из определенного процесса. Некоторая информация является побочным продуктом других вещей, и нам все еще нужно уметь ее находить, знать, что это значит, и уметь переводить данные, которые мы видим в конечном итоге, в знания, которые мы можем использовать для улучшения нашего бизнеса.
Малкольм Чисхолм: Правильно, и теперь еще одна область, с которой я борюсь, это то, что я бы назвал жизненным циклом данных, который, вы знаете, если мы посмотрим на цепочку поставок данных, проходящую через предприятие, мы начнем с сбор данных или сбор данных, которые могут быть вводом данных, но в равной степени, я получаю данные извне предприятия от какого-либо поставщика данных.
И затем от сбора данных мы переходим к ведению данных, где я думаю о стандартизации этих данных и отправке их туда, где это необходимо. И затем использование данных, фактические точки, в которых находятся данные, вы получите ценность от данных.
И в прежние времена все это делалось в едином стиле, но сегодня это может быть, вы знаете, например, аналитическая среда, а затем - архив, хранилище, куда мы помещаем данные, когда мы больше не нужно это и, наконец, процесс очистки типа. Как, по вашему мнению, моделирование данных вписывается в управление всем этим жизненным циклом данных?
Рон Хуэйзенга: Это очень хороший вопрос, и одна вещь, которую у меня действительно не было времени углубляться в какие-либо подробности здесь сегодня, - это то, о чем мы действительно начинаем говорить, это происхождение данных. Итак, что мы на самом деле можем сделать, так это то, что у нас есть возможность передачи данных в наших инструментах, и, как я уже сказал, мы можем извлечь некоторые из них из инструментов ETL, но вы также можете отобразить их, просто нарисовав линию. Любая из этих моделей данных или баз данных, которые мы собрали и привели в модели, мы могли бы ссылаться на конструкции из этого на нашей диаграмме происхождения данных.
Что мы можем сделать, так это нарисовать поток данных, как вы говорите, от источника к цели, и в течение всего жизненного цикла того, как эти данные проходят через различные системы и что вы собираетесь найти, - давайте возьмем сотрудников «Данные - это один из моих любимых на основе проекта, который я сделал несколько лет назад. Я работал с организацией, в которой были данные о сотрудниках в 30 различных системах. То, что мы в конечном итоге сделали там - и Ребекка вытащила слайд линии данных - это довольно упрощенный слайд линии данных здесь, но мы смогли внести все структуры данных, сослаться на них на диаграмме, а затем мы Можно ли начать смотреть на то, что между потоками, и как эти разные объекты данных связаны друг с другом в потоке? И мы можем пойти дальше этого. Это часть схемы потока данных или линии, которую мы видим здесь. Если вы хотите выйти за рамки этого, у нас также есть часть бизнес-архитектора этого пакета, и то же самое применимо там.
Любая из структур данных, которые мы зафиксировали в среде моделирования данных, на них можно ссылаться в инструменте бизнес-моделирования, чтобы даже в диаграммах бизнес-моделей или диаграммах бизнес-процессов вы могли ссылаться на отдельные хранилища данных, если вы хотите выйти из среду моделирования данных, и пока вы используете их в папках в модели вашего бизнес-процесса, вы можете даже указать CRUD для них, а также то, как эта информация потребляется или производится, и затем мы можем начать генерировать такие вещи, как отчеты о влиянии и анализе и диаграммы из этого.
То, к чему мы стремимся, и у нас уже есть много возможностей, но одна из вещей, которая у нас вроде как своего рода стойка ворот, на которую мы смотрим, поскольку мы продолжаем развивать наши инструменты в будущем, возможность наметить эту сквозную, организационную линию данных и полный жизненный цикл данных.
Малкольм Чисхолм: Хорошо. Ребекка, мне разрешено еще один?
Ребекка Джозвиак: Я позволю тебе еще, Малкольм, продолжай
Малкольм Чисхолм: Большое спасибо. Размышляя об управлении данными и о моделировании данных, как мы можем заставить эти две группы эффективно работать вместе и понимать друг друга?
Эрик Литтл: Ну, это интересно, я думаю, что это действительно зависит от организации, и это восходит к моей более ранней концепции: в тех организациях, где инициативы были ориентированы на бизнес, мы были тесно связаны. Например, я руководил архитектурой данных команда, но мы были тесно связаны с бизнес-пользователями, и мы фактически помогали им поддержать их программу управления данными. Опять же, скорее консультативный подход, но на самом деле это больше бизнес-функция.
Что вам действительно нужно для этого, так это то, что вам нужны разработчики моделей данных и архитекторы, которые действительно понимают бизнес, могут общаться с бизнес-пользователями, а затем помогать им выстраивать процессы управления вокруг него. Бизнес хочет это делать, но в целом мы обладаем технологическими знаниями, чтобы помочь им выделять эти типы программ. Это действительно должно быть сотрудничество, но оно должно принадлежать бизнесу.
Малкольм Чисхолм: Хорошо, это здорово. Спасибо.
Доктор Эрик Литтл: Хорошо.
Ребекка Йозвиак: Хорошо, спасибо большое. Члены аудитории, я боюсь, что мы не ответили на ваши вопросы, но я позабочусь, чтобы они были перенаправлены соответствующему гостю, которого мы встретили сегодня. Я хочу поблагодарить вас за Эрика, Малкольма и Рона за то, что они наши гости сегодня. Это было здорово, ребята. И если вам понравилась сегодняшняя веб-трансляция IDERA, в следующую среду IDERA также будет участвовать в Hot Technologies, если вы хотите присоединиться, чтобы обсудить проблемы индексации и Oracle, так что это еще одна увлекательная тема.
Большое спасибо, ребята, берегите себя, и мы увидимся в следующий раз. Пока-пока.
