Является ли хранилище данных хорошим решением для обмена данными о клиентах между технологиями?

Я хочу иметь возможность обмениваться данными во всех областях нашего бизнеса таким образом, чтобы снизить общую сложность нашей инфраструктуры.

Проблема

Наша проблема в том, что в настоящее время у нас есть 4 основных приложения, которые подключаются к нашему приложению CRM (Microsoft Dynamics 2011):

Лица, принимающие решения в нашей фирме, в настоящее время хотят обновить нашу CRM до самой последней версии, а затем оставаться в курсе по мере выпуска новых обновлений (каждые 2-3 года). Почти все наши приложения жестко интегрированы с Microsoft Dynamics, поэтому каждое обновление очень дорого и рискованно. Я хочу разработать другой подход, который уменьшит эти расходы и риск.

Исследования

В 2006 году Роджер Сешнс написал статью под названием A Better Path to Enterprise Architecture (здесь), в котором описаны способы улучшения ИТ-систем для бизнеса. Одной из центральных тем в его рассуждениях является снижение сложности, и, упорядочив кристаллы по-разному, он показывает, что можно экспоненциально уменьшить сложность систем, разбивая технологии на сегменты, а не позволяя какой-либо технологии соединяться с любой другой технологией. У Жанны Росс также есть отличная презентация на эту тему (здесь), и она говорит о наличии цифровой платформы для обмена основными данными и услугами между областями бизнеса, чтобы уменьшить сложность всей системы и повысить гибкость реагирования на текущие и будущие потребности бизнеса.

Выводы

Размышляя над уроками Сешнса и Росса, я уверен, что нам нужно вывести Microsoft Dynamics из центра нашей архитектуры, если мы хотим пересматривать технологию каждые 2-3 года. Нам просто нужно заменить его чем-то, что позволит совместно использовать наши основные данные (в основном данные клиентов) между приложениями. Я знаю, что хранилища данных часто используются для агрегирования данных по всей организации. Может ли это работать?

Я понимаю, что хранилища данных в основном используются для создания отчетов, поэтому я не знаю, было бы идеально прямое подключение к хранилищу данных. Однако каждому приложению не потребуется возможность обновлять какие-либо данные в хранилище данных. Им просто нужна возможность получить свои идентификаторы, чтобы установить отношения между глобальными сущностями хранилища данных (клиентами) и различными специфическими сущностями в базе данных каждого приложения.

Вопросы

Какой из этих трех вариантов удовлетворил бы мои потребности: (1) хранилище данных, к которому все приложения подключаются напрямую, (2) хранилище данных, которое передает данные в каждую базу данных конкретного приложения через ночные обновления или (3) что-то еще?

Спасибо

Zach Allen 03.08.2015 источник

Ответы (1)

arrow_upward
3
arrow_downward

То, что вам нужно, — это архитектура интеграции данных — это не обязательно означает хранилище данных. Шаблон, который вы описываете, называется «звезда и центр», и он очень распространен — я бы сказал, что вы определенно на правильном пути для решения проблемы интеграции, которую вы описываете.

Эта страница более подробно рассматривает эту проблему и шаблон, а также содержит раздел о различиях между хранилищем данных и интеграцией данных. Вы заметили, что вам известно, что хранилища данных обычно используются для отчетов — это правда, и они также активно используются для аналитики, как обсуждается по ссылке. Они традиционно являются источником данных для бизнес-аналитики. Это может означать, что они не всегда сосредоточены на тех данных, которые вас интересуют, т. е. на операционных данных, которые необходимы вашим системам для функционирования, но которые могут не представлять интереса для целей отчетности или анализа. Или они могут работать не так, как вам нужно — например, традиционная ночная загрузка ETL может быть не лучшим решением, если вам нужно, чтобы ваши приложения обновлялись быстрее.

Все это говорит о том, что хранилища данных определенно могут использоваться в качестве концентратора данных — EDW становится вашим источником «основных данных», любые необходимые процессы качества данных выполняются на данных EDW, а процессы ETL отправляют исправленные данные обратно в различные источники. - но вам, вероятно, будет лучше исследовать тему интеграции данных, чем тему хранилища данных, даже если они имеют много общего и могут пересекаться.

Если вы создаете хранилище данных без каких-либо требований к бизнес-аналитике, оно может не очень хорошо работать в качестве хранилища данных. Очень подходящее решение для интеграции данных/основных данных может не удовлетворить все ваши будущие требования к хранилищу данных. Точно так же, если вы создадите традиционное хранилище данных после изучения передовых методов хранения данных, оно может не соответствовать вашим требованиям к интеграции данных или выполнять их наилучшим образом. Как следует из ссылки, разделите две идеи: решите проблему с интеграцией данных, и если вам понадобится хранилище данных в будущем, вы можете использовать свое решение для интеграции данных, чтобы заполнить его.

Jo Douglass 03.08.2015