вынос: Ведущая Ребекка Йозвиак обсуждает решения по архитектуре данных с Эриком Литтлом из OSTHUS, Малколмом Чисхолмом из First San Francisco Partners и Роном Хуизенга из IDERA.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Ребекка Йозвиак: Дамы и господа, привет и добро пожаловать в Hot Technologies 2016 года. Сегодня мы обсуждаем «Построение архитектуры данных на основе бизнеса», безусловно, горячая тема. Меня зовут Ребекка Йозвиак, я буду вашим организатором сегодняшней веб-трансляции. Мы пишем в Твиттере с хэштегом # HotTech16, поэтому, если вы уже зарегистрированы, присоединяйтесь и к этому. Если у вас есть вопросы в любое время, отправьте их на панель вопросов и ответов в правом нижнем углу экрана, и мы обязательно ответим на них. Если нет, мы позаботимся о том, чтобы наши гости получили их для вас.
Итак, сегодня у нас действительно захватывающий состав. Сегодня у нас много сильных нападающих. У нас есть Эрик Литтл, вице-президент по науке данных из 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, был бы частью этого, но вы могли бы также утверждать, что 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. или, как некоторые люди до сих пор называют их, технологии больших данных.
Итак, теперь давайте скажем, у нас также есть 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. После того, как мы внедрили все эти модели в нашу среду, что мы можем сделать, предполагая, что теперь мы применили эти соглашения об именах, и их легко найти, мы можем теперь использовать конструкцию под названием 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, так что это еще одна увлекательная тема.
Большое спасибо, ребята, берегите себя, и мы увидимся в следующий раз. Пока-пока.